[Python-Dev] Software Transactional Memory for Python

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