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 <[EMAIL PROTECTED]> 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@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@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 <[EMAIL PROTECTED]> http://minkirri.apana.org.au/~abo/ _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
