1. Safe Open-Nested Transactions Jim Sukha MIT CSAIL Supercomputing Technologies Group Kunal Agrawal, I-Ting Angelina Lee, Bradley C. Kuszmaul, Charles E. Leiserson

2. 3/5/20072 Loopholes for TM Ordinary transactional memory (TM) provides guarantees that transactions are serializable, which provides a simple programming model. For reasons of performance, etc., loophole mechanisms for TM which break serializability at the level of memory (e.g., open nesting in TM [Moss, Hosking 05]) have been proposed. These loopholes have more complicated semantics which appear to be more difficult for programmers to reason about. Can one make TM with open nesting safe enough for non-expert programmers to use?

3. 3/5/20073 Function Calls and Closed Nesting atomic { // A int a = x;... foo(); int b = y; z = x + y; } Advantage: Simple semantics. One can reason locally about the correctness of A, since TM detects a conflict if D tries to interleave. void foo() { atomic { w++;... } atomic { // D p++;... foo(); q += p; } Disadvantage: What if the programmer wishes to ignore a conflict because he/she has deemed that abstractly, the calls do not conflict? TM with closed nesting will still detect conflicts, even if the nested transactions are hidden inside function calls.

4. 3/5/20074 Open Nesting as a Loophole atomic { // A int a = x;... foo(); int b = y; z = x + y; } void foo() { open_atomic { w++;... } atomic { // D p++;... foo(); q += p; } Answer: Provide a loophole mechanism in TM that supports this operation. For example, open nesting in TM [Moss, Hosking 05]. TM with closed nesting will still detect conflicts, even if the nested transactions are hidden inside function calls. We refer to the memory-level semantics of TM mechanisms for open nesting as hardware open nesting.

5. 3/5/20075 Prefix Race-Free Execution 1 atomic { // A 2 int a = x; 3... 4 open_atomic { // B 5 w++; 6 } 11 int b = y; 12 z = x + y; 13 } 7 atomic { // C 8 w++; 9 y = w; 10 } Hardware open nesting admits odd behavior, even if all transactions commit. A does not appear to execute atomically because C can interleave. We call this schedule prefix race-free because C does not conflict with some prefix of A. [ALS06]. In fact, several transactions C 1, C 2, etc., might interleave.

6. 3/5/20076 Open Nesting & Local Reasoning? atomic { // A int a = x;... foo(); int b = y; z = x + y; } void foo() { open_atomic { w++; } atomic { // C foo(); y = val(); } int val() { return w; } The previous example suggests that if foo() uses open nesting, then one can not reason locally about the correctness of A. It also seems that the programmer needs to be aware of whether the implementation of foo() uses an open-nested transaction or not.

7. 3/5/20077 Higher-Level Abstractions atomic { // A int a = x;... open_atomic { w++; } int b = y; z = x + y; } atomic { // C w++; y = w; } atomic { // D p++;... open_atomic { w++; } q += p; } Without higher-level abstractions to control sharing of data, it is unclear how a TM system can allow Case 1 without also allowing Case 2. Case 1: D interleaves with A. Case 2: C interleaves with A. X

8. 3/5/20078 Our Interests We are interested in understanding how one might constrain the use of open nesting or some other TM loophole to simplify its semantics. The (ideal) programming model for TM with loopholes should impose unobtrusive restrictions on the programmer which are enforceable (e.g., using programming language constructs), or are at least easy to satisfy. Once restrictions are imposed, TM should provide an abstract model and provable guarantees that are easy to understand and which a programmer can use to reason about their code.

9. 3/5/20079 Other Desirable Properties The effect of open-nested transactions should be provably encapsulated so that application programmers do not need to know whether a library function uses open nesting. One should be able to generalize the use of open nesting to any generic library. Can one construct a programming language or programming model for transactional memory with loopholes which is simple enough for programmers who arent experts to use?