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

• T1s write to O privatizes O
• T2 continues to execute optimistically
• Problem
• T2 commits, but privatizer reads old version,
• OR T2 aborts, but privatizer read T2s
  intermediate updates

5
Privatization Problem 1 Transactions cause
incorrect private ops
begin T1
write O
commit T1
read/write O
Thrd 1 (privatizer)
read O
begin T2
commit T2
write O
Thrd 2
TIME

• T1s write to O privatizes O
• T2 continues to execute optimistically
• Problem
• T2 commits, but privatizer reads old version,
• OR T2 aborts, but privatizer read T2s
  intermediate updates

6
Privatization Problem 1 Transactions cause
incorrect private ops
begin T1
write O
commit T1
read/write O
Thrd 1 (privatizer)
read O
begin T2
abort T2
write O
Thrd 2
TIME

• T1s write to O privatizes O
• T2 continues to execute optimistically
• Problem
• T2 commits, but privatizer reads old version,
• OR T2 aborts, but privatizer read T2s
  intermediate updates

7
Privatization Problem 2 Private writes cause
incorrect transaction ops
begin T1
write O
commit T1
write O
Thrd 1 (privatizer)
read O
begin T2
abort T2
read O
Thrd 2
TIME

• T1s write to O privatizes O
• T2 is doomed to abort
• But, T2 optimistically reads T1s update to O
• States of O and O accessed by T2 are mutually
  inconsistent may cause arbitrary failures

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?