[Python-Dev] Threading idea -- exposing a global thread lock

[Guido van Rossum]

Oh, no! Please!

I just had to dissuade someone inside Google from the same idea.

IMO it's fatally flawed for several reasons: it doesn't translate
reasonably to Jython or IronPython, it's really tricky to implement,
and it's an invitation for deadlocks. The danger of this thing in the
wrong hands is too big to warrant the (rare) use case that can only be
solved elegantly using direct GIL access.

--Guido

On 3/13/06, Raymond Hettinger <raymond.hettinger at verizon.net> wrote:
> A user on comp.lang.python has twisted himself into knots writing multi-threaded
> code that avoids locks and queues but fails when running code with non-atomic
> access to a shared resource. While his specific design is somewhat flawed, it
> does suggest that we could offer an easy way to make a block of code atomic
> without the complexity of other synchronization tools:
>
>    gil.acquire()
>    try:
>       #do some transaction that needs to be atomic
>    finally:
>       gil.release()
>
> The idea is to temporarily suspend thread switches (either using the GIL or a
> global variable in the eval-loop).  Think of it as "non-cooperative"
> multi-threading. While this is a somewhat rough approach, it is dramatically
> simpler than the alternatives (i.e. wrapping locks around every access to a
> resource or feeding all resource requests to a separate thread via a Queue).
>
> While I haven't tried it yet, I think the implementation is likely to be
> trivial.
>
> FWIW, the new with-statement makes the above fragment even more readable:
>
>     with atomic_transaction():
>         # do a series of steps without interruption
>
>
> Raymond
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org
>


--
--Guido van Rossum (home page: http://www.python.org/~guido/)