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

Donovan Baarda abo at minkirri.apana.org.au
Tue Mar 14 15:58:58 CET 2006

On Mon, 2006-03-13 at 21:06 -0800, Guido van Rossum wrote:

Oh, no! Please!

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

Heh... that was me... I LOL'ed when I saw this... and no, I didn't put Raymond up to it :-)

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.

I didn't bother pursuing it because I'm not that attached to it... I'm not sure that a language like Python really needs it, and I don't do that kind of programming much any more.

When I did, I was programming in Ada. The Ada language has a global thread-lock used as a primitive to implement all other atomic operations and thread-synchronisation stuff... (it's been a while... this may have been a particular Ada compiler extension, though I think the Ada concurrency model pretty much required it). And before that it was in assembler; an atomic section was done by disabling all interrupts. At that low-level, atomic sections were the building-block for all the other higher level synchronisation tools. I believe the original semaphore relied on an atomic test-and-set operation.

The main place where something like this would be useful in Python is in writing thread-safe code that uses non-thread safe resources. Examples are; a chunk of code that redirects then restores sys.stdout, something that changes then restores TZ using time.settz(), etc.

I think the deadlock risk argument is bogus... any locking has deadlock risks. The "danger in the wrong hands" I'm also unconvinced about; non-threadsafe resource use worries me far more than a strong lock. I'd rather debug a deadlock than a race condition any day. But the hard to implement for other VMs is a breaker, and suggests there a damn good reasons those VMs disallow it that I haven't thought of :-)

So I'm +0, probably -0.5...

--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/) _________________________ 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/abo%40minkirri.apana.org.au

Donovan Baarda <abo at minkirri.apana.org.au> http://minkirri.apana.org.au/~abo/

More information about the Python-Dev mailing list