[pypy-dev] STM
Randall Leeds
randall.leeds at gmail.com
Thu Jan 5 17:14:21 CET 2012
On Thu, Jan 5, 2012 at 11:10, David Edelsohn <dje.gcc at gmail.com> wrote:
> On Thu, Jan 5, 2012 at 5:38 AM, Armin Rigo <arigo at tunes.org> wrote:
>
>> Ah, I realized something else. When considering solutions for
>> CPython, if we go for the one-transaction-per-bytecode approach, like
>> the approach taken in the 2 papers so far about CPython+TM, then we
>> need non-lexically-nested transactions in the C language, i.e. more
>> than what GCC 4.7 offers. But if instead we go, as I propose, for the
>> coarse-grained-that-can-be-refined transaction approach, then it's not
>> true: in the C language we only need to implement an equivalent to the
>> run() function I pasted, and this function can use a lexically-nested
>> transaction keyword in C. So I guess my next goal suddently shifted
>> back to doing more experiments with CPython and GCC 4.7 :-)
>
> Hi, Armin
>
> Yes, transaction memory in programming languages has focused on
> lexical scoping. But hardware implementations of transaction memory
> have no concept of lexical scoping and implement something closer to
> your requirements:
>
> START TRANSACTION
> COMMIT TRANSACTION
>
> usually with additional facilities for suspending and aborting a transaction.
>
> A threaded interpreter or JIT is lower-level than the idealized target
> envisioned by programming languages designers adding high-level
> software transaction memory constructs.
>
> I suspect your design would work better with hardware transaction
> memory, where systems programming languages will expose the hardware
> instructions as builtins.
Although I've not a seen a hardware implementation that allows
overlapping transactions, though some allow nesting. Although it's
been two years now since I looked into it at all. I'm not sure how
that plays into lexical structure, but intuitively it seems like the
with-statement style plays nicely.
-Randall
More information about the pypy-dev
mailing list