100 likes | 119 Views
Explore the limitations, solutions, challenges, and opportunities in implementing privatization techniques for efficient software transactional memory. Learn about techniques, problems, and solutions. Dive into the world of privatization in transactional memory systems.
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?