[Python-Dev] Software Transactional Memory for Python (original) (raw)

Charles-François Natali neologix at free.fr
Sat Aug 27 19:11:18 CEST 2011

Hi Armin,

This is basically dangerous, because it corresponds to taking lock "GIL" and lock L, in that order, whereas the thread B takes lock L and plays around with lock "GIL" in the opposite order.  I think a reasonable solution to avoid deadlocks is simply not to use explicit locks inside "with atomic" blocks.

The problem is that many locks are actually acquired implicitely. For example, print to a buffered stream will acquire the fileobject's mutex. Also, even if the code inside the "with atomic" block doesn't directly or indirectely acquire a lock, there's still the possibility of asynchronous code that acquire locks being executed in the middle of this block: for example, signal handlers are run on behalf of the main thread from the main eval loop and in certain other places, and the GC might kick in at any time.

Generally speaking it can be regarded as wrong to do any action that causes an unbounded wait in a "with atomic" block,

Indeed.

cf

More information about the Python-Dev mailing list