[pypy-dev] PyPy STM

[Ronny Pfannschmidt]

On 10/04/2012 06:14 PM, Andrew Francis wrote:
> Hi Ronny:
>
> ------------------------------------------------------------------------
> *From:* Ronny Pfannschmidt <Ronny.Pfannschmidt at gmx.de>
> *To:* Andrew Francis <andrewfr_ice at yahoo.com>
> *Cc:* Armin Rigo <arigo at tunes.org>; Sarah Mount <s.mount at wlv.ac.uk>;
> PyPy_Developers <pypy-dev at python.org>
> *Sent:* Monday, October 1, 2012 2:51 PM
> *Subject:* Re: [pypy-dev] PyPy STM
>
> On 10/01/2012 08:32 PM, Andrew Francis wrote:
>
> AF> That is why I use Stackless Python.... And I would love to try to
> AF> incorporate STM into Stackless.
>
>  >no point in pushing that into old stackless
>  >once continulet-jit-3 works as we hope to, "continuations"
>  >will have distinct stacks (Armin please correct if i missed )
>
> I view Stackless Python and its API as functioning at a higher level
> than continuelets or some other low
> level concurrency mechanism. As an example, look at the old stackless.py
> module that supported both greenlets
> and coroutines.
>
> Maybe Stackless a few years from now, will be Stackless in API only
> rather than under the hood
> mechanisms?
>
as far as i understood, that will be the state once the continulet-jit-3 
branch is done
it just gives each continuation a own stack, the rest is api
>
> AF> I'll admit, I don't understand all the ins-and-outs of the papers.
> AF> However my takeaway is that STM and STMish mechanisms are used in a very
> AF> small place: the message passing system's implementation. Given that
> AF> message passing systems typically share information through messages
> AF> :-), this ought to create a very small footprint for transaction
> conflicts.
>
>>stm will be everywhere in pypy because we need it everywhere
>  >to have it appear as if we still have the gil
>
> Yes the STM mechanism will be everywhere. However I would suspect that
> one would still want
> to write programmes that would result in fewer transaction conflicts and
> redo/undo work. It would be nice
> to have programming constructs to do this (I guess atomic is one of
> them).Message passing is another mechanism.
> Message passing is a fairly easy model to understand.

i think that some fundamentals (aka channels/queues) will be enough
the rest is a question of the programming models/patterns
it will be interesting to figure good/new ones

>
> Again, my point is that the literature points to using STM and STM like
> features to build more efficient
> message passing systems. It is this line of thinking that I feel is
> worth pursuing. I don't know how the PyCSP
> folks feel about this?
im under the impression that messages are to be used
to help with low conflict rates, but [[citation needed]]
i haven’t yet experimented with that enough
>
> If you want to see an example of the headaches of using fine-grained
> concurrency control to implement
> channels, look at Go source code (i.e, you will see stuff like sorting
> locks on channel data structures).


noted for in 2 months

-- Ronny

>
> Cheers,
> Andrew
>
>
>