Embed Size (px)
Citation preview
Safe Open-Nested Transactions
Jim Sukha
MIT CSAILSupercomputing Technologies GroupKunal Agrawal, I-Ting Angelina Lee, Bradley C. Kuszmaul, Charles E. Leiserson
3/5/2007 2
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/5/2007 3
Function Calls and Closed Nestingatomic { // 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.
3/5/2007 4
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.
3/5/2007 5
Prefix Race-Free Execution1 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 C1, C2, etc., might interleave.
3/5/2007 6
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.
3/5/2007 7
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
3/5/2007 8
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.
3/5/2007 9
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 aren’t “experts” to use?
