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