Privatization Techniques for Software Transactional Memory Michael F. Spear, Virendra J. Marathe, Luke Dalessandro, and Michael L. Scott University of Rochester

2 Motivation for Privatization Limitations of Memory Transactions Semantic limitations (cannot permit I/O in txns) Performance Overheads (software txns still too slow) Solution: Move objects from transactional (shared)  non-transactional (local) space, and then Non-transactional (local)  transactional (shared) space

3 Privatization Privatization is a simple (natural?) programming idiom // Object “O” is usually shared among transactions, but may // occasionally be privatized using the “shared” flag // privatizing thread// concurrent txn 1:transaction {transaction { 2: // privatizes “O” if (shared == true) { 3: shared = false;// txnal processing 4:}shared_foo(O); 5:// non-transactional code } 6:private_foo(O);} Semantically simple, not so simple implementations  Why? Implementations use optimistic concurrency control (OCC) techniques Does not interoperate with privatization correctly

4 Privatization Problem 1: Transactions cause incorrect private ops T1’s write to O privatizes O’ T2 continues to execute optimistically Problem: T2 commits, but privatizer reads old version, OR: T2 aborts, but privatizer read T2’s intermediate updates Thrd 2 Thrd 1 (privatizer) read Obegin T2 begin T1write O (commit / abort) T2 commit T1 write O’ read/write O’ TIME

5 Privatization Problem 1: Transactions cause incorrect private ops T1’s write to O privatizes O’ T2 continues to execute optimistically Problem: T2 commits, but privatizer reads old version, OR: T2 aborts, but privatizer read T2’s intermediate updates Thrd 2 Thrd 1 (privatizer) read Obegin T2 begin T1write O commit T2 commit T1 write O’ read/write O’ TIME

6 Privatization Problem 1: Transactions cause incorrect private ops T1’s write to O privatizes O’ T2 continues to execute optimistically Problem: T2 commits, but privatizer reads old version, OR: T2 aborts, but privatizer read T2’s intermediate updates Thrd 2 Thrd 1 (privatizer) read Obegin T2 begin T1write O abort T2 commit T1 write O’ read/write O’ TIME

7 Privatization Problem 2: Private writes cause incorrect transaction ops T1’s write to O privatizes O’ T2 is doomed to abort But, T2 optimistically reads T1’s update to O’ States of O and O’ accessed by T2 are mutually inconsistent – may cause arbitrary failures read Obegin T2 begin T1write O abort T2 commit T1 read O’ write O’ TIME Inconsistency window Thrd 2 Thrd 1 (privatizer)

8 Privatization Techniques/ Solutions Strong Isolation: Transactions are isolated from non-transactional memory accesses as well Seems impractical without extensive hardware support Runtime Techniques we explored Fences: Force privatizer to wait for concurrent transactions to reach a safe point Nonblocking Privatization: Instrument non- transactional code to check for conflicts with transactions

9 Privatization: Challenges and Opportunities Challenge: Performance, performance, performance!!! All existing solutions pose significant overheads Opened opportunities for exploring a new dimension of runtime systems program analysis based solutions Important criterion for programming models for Transactional Memory

10 Thank You! Questions?