dje.gcc at gmail.com
Thu Jan 5 17:10:31 CET 2012
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 :-)
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
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.
More information about the pypy-dev