100 likes | 175 Views
Privatization Techniques for Software Transactional Memory. Michael F. Spear, Virendra J. Marathe , Luke Dalessandro, and Michael L. Scott University of Rochester. Motivation for Privatization. Limitations of Memory Transactions Semantic limitations (cannot permit I/O in txns)
E N D
Privatization Techniques for Software Transactional Memory Michael F. Spear, Virendra J. Marathe, Luke Dalessandro, and Michael L. Scott University of Rochester
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
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
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
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
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
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
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
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
Thank You! Questions?