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

[Donovan Baarda]

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 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/)
> _______________________________________________
> 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/