Controlled Interleaving for Transactions Jim Sukha Work with Kunal Agrawal CSAIL Student Workshop September 25, 2006

Summary work in progress… We are investigating possible loopholes for transactional memory (TM) that provide weaker guarantees than the traditional guarantees of TM, i.e., that transactions are serializable. One loophole we are exploring is what we refer to as controlled interleaving of transactions. work in progress…

Outline Multithreaded Programs and Locks Overview of Transactional Memory Loopholes for Transactional Memory

Parallel Code using Locks int x[1000]; lockVar *xLock[1000]; void swap(void) { int i, j, temp; i = rand() % 1000; j = rand() % 1000; acquire(xLock[i]); acquire(xLock[j]); temp = x[i]; x[i] = x[j]; x[j] = temp; release(xLock[j]); release(xLock[i]); } int main(void) { spawn swap(); sync; return 0; } This multithreaded program creates two threads that each access array x[1000], stored in shared memory. Each thread swaps two random elements in the array. This code uses fine-grained locks to guarantee mutual exclusion, i.e., to ensure that the swaps on each thread do not interfere with each other.

Problems with Locks int x[1000]; lockVar *xLock[1000]; void swap(void) { int i, j, temp; i = rand() % 1000; j = rand() % 1000; acquire(xLock[i]); acquire(xLock[j]); temp = x[i]; x[i] = x[j]; x[j] = temp; release(xLock[j]); release(xLock[i]); } int main(void) { spawn swap(); sync; return 0; } This program can deadlock! One might encounter some problems using fine-grained locks: Locking may introduce unnecessary overhead if conflicts between threads are rare. Locks must be acquired in a a canonical order to avoid deadlock. Fine-grained, deadlock-free locking protocols for complex data structures are difficult to get right.

Outline Multithreaded Programs and Locks Overview of Transactional Memory Loopholes for Transactional Memory

A Solution:Transactional Memory Transactional memory [HerlihyMoss93] allows programmers to specify a section of code as a transaction. A transaction executes atomically, i.e., either it appears to happen all at once, or not at all. A transaction that completes successfully is said to commit. Otherwise the transaction aborts (its changes to memory are discarded), and can be retried until it commits. int x[1000]; void swap(void) { int i, j, temp; i = rand() % 1000; j = rand() % 1000; xbegin; temp = x[i]; x[i] = x[j]; x[j] = temp; xend; } Idea: Use transactions instead of locks to guarantee mutual exclusion.

How does TM work? A TM system (in hardware or software) maintains a readset and writeset for each transaction as it executes. The system aborts transactions as necessary when it detects a conflict. // Transaction A void swap1(void) { xbegin; R1 = x; x = y; y = R1; xend; } // Transaction B void swap2(void) { xbegin; R2 = y; y = z; z = R2; xend; } Conflict: If two transactions access the same memory location y, and at least one of those accesses is a write. // Transaction A Readset = { } Writeset = { } // Transaction B Readset = { } Writeset = { }

How does TM work? A TM system (in hardware or software) maintains a readset and writeset for each transaction as it executes. The system aborts transactions as necessary when it detects a conflict. // Transaction A void swap1(void) { xbegin; R1 = x; x = y; y = R1; xend; } // Transaction B void swap2(void) { xbegin; R2 = y; y = z; z = R2; xend; } Conflict: If two transactions access the same memory location y, and at least one of those accesses is a write. // Transaction A Readset = {x} Writeset = { } // Transaction B Readset = { } Writeset = { }

How does TM work? A TM system (in hardware or software) maintains a readset and writeset for each transaction as it executes. The system aborts transactions as necessary when it detects a conflict. // Transaction A void swap1(void) { xbegin; R1 = x; x = y; y = R1; xend; } // Transaction B void swap2(void) { xbegin; R2 = y; y = z; z = R2; xend; } Conflict: If two transactions access the same memory location y, and at least one of those accesses is a write. // Transaction A Readset = {x} Writeset = { } // Transaction B Readset = {y} Writeset = { }

How does TM work? A TM system (in hardware or software) maintains a readset and writeset for each transaction as it executes. The system aborts transactions as necessary when it detects a conflict. // Transaction A void swap1(void) { xbegin; R1 = x; x = y; y = R1; xend; } // Transaction B void swap2(void) { xbegin; R2 = y; y = z; z = R2; xend; } Conflict: If two transactions access the same memory location y, and at least one of those accesses is a write. // Transaction A Readset = {x, y} Writeset = {x} // Transaction B Readset = {y} Writeset = { }

How does TM work? A TM system (in hardware or software) maintains a readset and writeset for each transaction as it executes. The system aborts transactions as necessary when it detects a conflict. // Transaction A void swap1(void) { xbegin; R1 = x; x = y; y = R1; xend; } // Transaction B void swap2(void) { xbegin; R2 = y; y = z; z = R2; xend; } Conflict: If two transactions access the same memory location y, and at least one of those accesses is a write. // Transaction A Readset = {x, y} Writeset = {x} // Transaction B Readset = {y, z} Writeset = {y}

How does TM work? A TM system (in hardware or software) maintains a readset and writeset for each transaction as it executes. The system aborts transactions as necessary when it detects a conflict. // Transaction A void swap1(void) { xbegin; R1 = x; x = y; y = R1; xend; } // Transaction B void swap2(void) { xbegin; R2 = y; y = z; z = R2; xend; } Conflict: If two transactions access the same memory location y, and at least one of those accesses is a write. Conflict on location y between A and B. Abort one of the transactions, restore memory to its original state, and try again. // Transaction A Readset = {x, y} Writeset = {x} // Transaction B Readset = {y, z} Writeset = {y}

Why Use Transactional Memory? Using transactions is as easy as using coarse-grained locks. Transactions potentially allow as much concurrency as fine-grained locks; two transactions only interfere with each other if they actually share memory. And there are many other reasons given in transactional memory literature…

Outline Overview of Transactional Memory Loopholes for Transactional Memory Ordinary TM Semantics -- Serializability Open-Nested Transactions Controlled Interleaving

Serializability TM typically guarantees that transactions are serializable. For every program execution, there exists an order of all operations in the program that will (1) correctly “explains” every read and write operation, and (2) has all transactions appearing contiguous in the order. Execution orders 1 and 2 are serializable: xbegin read a read b c ← a + b write c xend xbegin read d read e 10 a ← d + e 11 write a 12 xend Order 1 (A < B ): 1, 2, 3, 7, 8, 9, 4, 5, 6, 10, 11, 12 A B Order 2 (B < A): 4, 5, 6, 10, 11, 12, 1, 2, 3, 7, 8, 9 Order 3 is still serializable because it is equivalent to Order 1. Order 3 (A < B): 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12

A Serializable Execution? xbegin read a Hash-Insert(a) read b Hash-Insert(b) c ← a + b write c xend B xbegin read d Hash-Insert(d) read e Hash-Insert(e) f ← d + e write f xend B1 B2 B3 J1 J2 A1 I1 A2 A I2 A3 In this example, we might expect that A and B do not conflict with each other. Then, the following interleaved execution order would be serializable: Execution order: A1, B1, I1, J1, A2, I2, B2, J2, B3, A3

Maybe Not… xbegin read a Hash-Insert(a) read b Hash-Insert(b) c ← a + b write c xend xbegin read d Hash-Insert(d) read e Hash-Insert(e) f ← d + e write f xend A1 B1 I1 J1 A2 B2 A B I2 J2 A3 B3 All calls to Hash-Insert conflict on the size field of the hash table however. Thus the following execution order is actually not serializable. Ideally, a TM loophole would let us specify this order as being valid! Hash-Insert(a) { H.insert(a); H.size++; } Execution order: A1, B1, I1, J1, A2, I2, B2, J2, B3, A3

Example of Open Nesting xbegin read a xbegin_open Hash-Insert(a) xend_open read b Hash-Insert(b) c ← a + b write c xend A1 A2 A3 I1 I2 B xbegin read d xbegin_open Hash-Insert(d) xend_open read e Hash-Insert(e) f ← d + e write f xend B1 B2 B3 J1 J2 Open nesting has been proposed as one loophole for transactional memory [MossHosking05]. Informally, the outer transactions (A and B) “ignore” the memory accessed by its open-nested subtransactions (I’s and J’s). When an open-nested subtransaction commits, its changes are committed to memory immediately. Thus, the interleaved order is allowed: Execution order: A1, B1, I1, J1, A2, I2, B2, J2, B3, A3

But what about… xbegin read a xbegin_open read i i ← i + 1 write i xend_open read b c ← a + b write c xend xbegin read i i ← i + 1 write i xend b ← i write b Execution order: A1 I1 B C A2 A1 B I1 A C A2 At the level of memory semantics, the mechanisms that have been proposed to support open-nested transactions may also permit the above execution order. What memory model is the proposed hardware implementing? Shameless plug: In [ALS06], we answer this question.

Interleaved Transactions? xbegin read a xbegin_open read i i ← i + 1 write i xend_open read b c ← a + b write c xend xbegin read i i ← i + 1 write i xend b ← i write b Execution order: A1 I1 B C A2 A1 B Open nesting takes a program execution which has transactions that interleave, and relies on higher level semantics to explain why it is still abstractly “serializable”. I1 A C A2 If transactional loopholes are going to allow transactions to appear as though they executed in an interleaved fashion, instead of trying to explain why the execution is still “serializable”, why not make it part of the model?

Controlled Interleaving xbegin read a read i i ← i + 1 write i yield(Q); read b c ← a + b write c xend xbegin tag(Q); read i i ← i + 1 write i xend b ← i write b Execution order: A1 I1 B C A2 A1 B I1 A A2 C Instead of letting transactions interleave in possibly “unexpected” ways, the idea of controlled interleaving is to only allow transactions which have been appropriately tagged to interleave.

Memory Model for Interleaving Intuition: For every execution, there exists an order on all operations in the program that Correctly “explains” each read and write operation. For every transaction T, the only operations from a different transaction T’ that can interleave in between xbegin(T) and xend(T) in the order must satisfy: T’ must appear after a yield(Q) operation in T, for some passkey Q, and before the next operation of T. T’ must be tagged with Q.

Data Structure Rebalance? Search(A,x) { xbegin; tag(S); ... xend; } Insert(A, x) { tag(I); Rebalance(A) { xbegin; f1(A); yield(S); f2(A); yield(S, I); f3(A); xend; } After f1 completes, we allow a Search on A to interleave, but not Insert. After f2 completes, we allow both Search and Insert on A to interleave. Controlled interleaving could be useful for implementing data structures. Suppose a transaction T1 performs an expensive Rebalance operation that reorganizes the entire data structure. We might wish to allow a transaction T2 that performs a concurrent Search or Insert to interleave at certain points during the rebalance.

Open Questions Our proposal of controlled interleaving is still a work in progress: Can transactional loopholes be used in a composable fashion? Can one safely call a function f from inside a transaction T without needing to know that f calls a transaction T’ that uses a loophole? Can controlled interleaving using tags actually be implemented efficiently? Or is controlled interleaving merely an abstract concept useful for describing or reasoning about the semantics of other transactional loopholes?

More Questions What kinds of transactional memory loopholes do we need? How do we determine which ones are “easy to use”? Answer: Look at applications that use transactional memory. What real applications use transactional memory? Answer: None! (Hardware) transactional memory doesn’t exist yet.

Final Thoughts If you had access to transactional memory, what programs would you write? If you had a computer with 32 (or 256 or 1024) cores, what kinds of programs would you (want to) write? What kind of parallel programming model would you want to use? If you have answers to these questions, come talk to us!

Race-Free Passkey xbegin read a Hash-Insert(a) yield(Q, R) read b Hash-Insert(b) c ← a + b write c xend xbegin read d Hash-Insert(d) yield(Q, R) read e Hash-Insert(e) f ← d + e write f xend A1 B1 I1 J1 A2 B2 A I2 J2 B A3 B3 Execution order: A1, B1, I1, J1, A2, I2, B2, J2, B3, A3 Hash-Insert(a) { xbegin; tag(Q); H.insert(a) H.size++; xend; } Do we need a special “race-free” passkey R? If a transaction T yields to R, then any transaction T’ which does not “conflict” with T is allowed to interleave. With this construct, the interleaved execution order is allowed only when the only conflicts between A and B occur inside transactions tagged with Q.

The Easy Solution (?) How can most programmers avoid all the problems associated with using locks? Write serial code! Forget multithreading! Advantages: No deadlocks and simpler code for most programmers. More job security for the rest. But then what are we going to do with all those cores?