[pypy-dev] PyPy STM

[Ronny Pfannschmidt]

On 09/30/2012 04:22 PM, Armin Rigo wrote:
> Hi Ronny,
>
> On Sun, Sep 30, 2012 at 3:50 PM, Ronny Pfannschmidt
> <Ronny.Pfannschmidt at gmx.de>  wrote:
>> after my thesis i'll be experimenting with a relaxed csp-ish model
>> based on python native generator based continuations as well as
>> the new continulet-jit-3 based greenlets.
>>
>> my basic assumption is that having limited amount
>> of shared memory is acceptable.
>
> What you are thinking about is to start from the naturally multicore
> model of separate address spaces, and add some amount of shared
> memory.  You would use STM to handle the result.  It is the opposite
> of what I'm thinking about, which is to start with a non-multithread,
> non-tasklet-based program and add multicore capability to it.  I would
> be using STM to "create" multicore capability, whereas you would be
> using it to "create" shared memory.  I am more interested in the first
> approach than the second because I think it is closer to what
> untrained programmers start with, but both approaches are potentially
> valid.
>

i think both approaches are valid,
they lend themselves to help and reason about different kinds of 
problems that make different kinds of serial programs concurrent and 
parallel.

i think for most purposes simple sequential communicating programs
are way more easy to reason about than anything else.

the transaction module approach already seems to require to chunk up 
programs in semi-small transactions,
that may cause other transactions to be scheduled

which seems more and more like twisted's defereds.
to my eyes twisted style code is a kind of spaghetti
that is very hard to reason about.

which is why i want to experiment executing multiple longer sequential 
programs in chunks that may be interleaved and/or parallel

the reason why i start with generators instead of green-lets is simply 
cause they cannot ever be nested.

this will allow more simple reasoning.


> Russel: STM is a powerful tool that makes sense of shared memory in
> multicore situations.  I fail to understand why you are looking at it
> in the absence of shared memory...

Im under the impression the intent is to have non-shared application 
state while the interpreter states are still shared
(i might be using the wrong words here)

>
>
> A bientôt,
>
> Armin.

-- Ronny