[prev in list] [next in list] [prev in thread] [next in thread] 

List:       pypy-dev
Subject:    Re: [pypy-dev] Questions Re:  STM status
From:       Armin Rigo <arigo () tunes ! org>
Date:       2012-02-17 20:24:25
Message-ID: CAMSv6X38-xcHEo2Cqo=rbcOhm6Wie8a3pbRQwKUaGQuPHtAL4w () mail ! gmail ! com
[Download RAW message or body]

Hi Andrew,

On Fri, Feb 17, 2012 at 20:26, Andrew Francis <andrewfr_ice@yahoo.com> wrot=
e:
> 1) I have been looking at the transaction module and its dependent module=
s.
> In rstm.perform_transaction, I see a comment to a "custom GIL." So the GIL
> is still there? Or will it be eventually removed?

That's for tests.  It's protected under "if not we_are_translated()",
which means that this code is never translated into the final pypy
executable.

> I admit I am not comfortable with reading the code. However I see places
> where the code distinguishes between mutable and immutable, local and non
> local variables. I will assume mutable and non-local variables will be the
> subject of transactional memory.

Yes, exactly.  But note that distinguishing such variables only occurs
in RPython, where some fields of some objects are marked as
"immutable".  It is important because e.g. we don't want to track the
reads of the integer value out of the immutable "int" objects.  I
suspect that it is less important at the level of regular Python, but
see below.

As for the difference between "local" and "global", it's also visible
at RPython level only.  If a transaction allocates an object, it is
"local".  If it reads from an object that existed before, it reads
from a "global" object.  If it writes to an object that existed
before, the global object is first copied as a local object.  (The
global objects are immutable at this level.)  When the transaction
commits, we do a local GC and copy the surviving local objects to
become globals; then we atomically update the global objects that have
been copied and modified.

This is, of course, all invisible at the level of Python.

> can I assume that one can "help" the STM if a) somehow more
> variables can be marked as immutable?

This might maybe at some point later be exposed to Python level too,
where if you would declare some fields of some Python class as being
immutable; then you really couldn't change them but the implementation
could improve a bit performance.  But that's a language extension, so
a bit unlikely to occur.

> 2)"Threads of execution" do not share state.
> Essentially a more functional programming approach.

Well, multiple "threads of execution" do share state, in this
programming model.  It allows us to not have to completely change
everything in the programs we already wrote. :-)

> 3) Could the stackless module work with STM?

Yes: one transaction would be the time between two switch()es.  It
would probably just need some integration between the existing
modules, 'transaction' and '_continuation'.


A bient=F4t,

Armin.
_______________________________________________
pypy-dev mailing list
pypy-dev@python.org
http://mail.python.org/mailman/listinfo/pypy-dev
[prev in list] [next in list] [prev in thread] [next in thread]