[Stackless] the "atomic" flag

Andrew Francis andrewfr_ice at yahoo.com
Mon Jan 28 18:46:04 CET 2013


Hi Kristjan:


________________________________
 
Message: 1
Date: Sun, 27 Jan 2013 16:26:13 +0000
From: Kristj?n Valur J?nsson <kristjan at ccpgames.com>
To: "The Stackless Python Mailing List (stackless at stackless.com)"
    <stackless at stackless.com>
Subject: [Stackless] the "atomic" flag
Message-ID:
    <EFE3877620384242A686D52278B7CCD329E7399A at RKV-IT-EXCH103.ccp.ad.local>
Content-Type: text/plain; charset="iso-8859-1"

Interesting post. I haven't played with tasklet.atomic and read just enough about STM to be dangerous so here goes ....
 
>I'd like to add the the new behavior of tasklet.atomic, to inhibit thread switching, is really only possible in our GIL based ?>cpython world.  But I actually view this as a benefit.  Given that the cpython implementation, the only current stackless >implemantaion, is GIL based, this makes ensuring local critical sections a breeze.

In keeping with the definition of atomic (and thinking about Armin Rigo's STM work), perhaps xxxx.atomic 
is not so much  about inhibiting threading switch but rather guaranteeing:  an operation is all-or-nothing ; looks like a single operation from external threads of execution. 

(I say thread-of-execution rather than thread because it may be desirable to distinguish between OS threads,
tasklets, and some other threading system. I haven't followed Armin's work lately but I was never sure how to make
that system distinguish between a tasklet and a thread).

>In fact, so much so, that I would recommend this to the CPython crowd.  There is every so often the discussion here and >there whether this or that operation is 'atomic" or not.  Can list.appen() be considere atomic?  What about ordered >dictionary inserts?  Etc. etc. People discuss this back and forth and certain guarantees are made and not made.

I think list.append() should be atomic. As an interesting side-note, in the paper "Scalable Join Patterns," I believe
stuff like lock-free *bags*  (where order doesn't matter) are used to more efficiently implement concurrency.

>I'd argue that the stackless.atomic flag should be moved to be sys.atomic, and be per thread.  It should mean that there will >be no involountary gil based thread switches while it is in effect.
>It would solve a number of synchronization problems with thread based python.


>Unfortunately, I see the counter arguments already:

>1)      It will not be truly atomic when there are blocking calls that truly do yield the GIL

It could still be truly atomic if the state of the "transaction" has not changed when control has been returned. However to handle this, I think one starts to head into STM land. 

>2)      It is not portable to the versions of python that don't have a GIL.

I don't know enough about JPython and IronPython but "atomic" itself is a pretty general idea..

Cheers,
Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.stackless.com/pipermail/stackless/attachments/20130128/2558e31d/attachment.html>


More information about the Stackless mailing list