Hi Kristjan:
________________________________
Message: 1
Date: Sun, 27 Jan 2013 16:26:13 +0000
From: Kristj?n Valur J?nsson <[email protected]>
To: "The Stackless Python Mailing List ([email protected])"
<[email protected]>
Subject: [Stackless] the "atomic" flag
Message-ID:
<efe3877620384242a686d52278b7ccd329e73...@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
_______________________________________________
Stackless mailing list
[email protected]
http://www.stackless.com/mailman/listinfo/stackless
