On Thu, Jan 5, 2012 at 5:38 AM, Armin Rigo <[email protected]> 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. - David _______________________________________________ pypy-dev mailing list [email protected] http://mail.python.org/mailman/listinfo/pypy-dev
