[Python-Dev] Threading idea -- exposing a global thread lock (original) (raw)

Guido van Rossum guido at python.org
Tue Mar 14 06:06:00 CET 2006

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 atomictransaction(): # 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/)

More information about the Python-Dev mailing list