Privatization Techniques for Software Transactional Memory

1. 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 begin T1 write O commit T1 read/write O’ Thrd 1 (privatizer) begin T2 read O write O’ (commit / abort) T2 Thrd 2 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 begin T1 write O commit T1 read/write O’ Thrd 1 (privatizer) begin T2 read O write O’ commit T2 Thrd 2 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 begin T1 write O commit T1 read/write O’ Thrd 1 (privatizer) begin T2 read O write O’ abort T2 Thrd 2 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 begin T1 write O commit T1 write O’ Thrd 1 (privatizer) begin T2 read O read O’ abort T2 Thrd 2 TIME Inconsistency window

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?