Design Tradeoffs in Modern Software Transactional Memory Systems

1. Design Tradeoffs in Modern Software Transactional Memory Systems Virendra J. Marathe, William N. Scherer III, and Michael L. Scott Department of Computer Science University of Rochester

2. OutLine of the Talk • Software Transactional Memory (STM) • Dynamic STM (DSTM) • Fraser’s STM (FSTM) • Comparative Analysis • Conclusions and Future Directions

3. Software Transactional Memory (STM) • Transaction – a sequence of instructions that atomically access/modify concurrent objects • STM - A “universal” nonblocking synchronization construct • Automatic conversion of sequential (or lock-based) code to nonblocking code • Constant base-case overhead, but strength of nonblocking semantics • Name coined by Shavit and Touitou (1995)

4. Dynamic STM (DSTM) by Herlihy et al. (PODC 2003) Transaction Descriptor (Active, Aborted, or Committed) Transaction Old Version Old Data Object Start New Version TMObject Locator New Data Object DSTM Object Structure

5. DSTM transaction’s operations • Transaction acquires a TMObject (while opening it) by placing its locator into the TMObject using a CAS operation • Objects opened in write mode are only acquired • Reads are essentially invisible • Incremental validation for consistency

6. Example Acquire Operation Transaction Descriptor Status: COMMITTED Transaction Old Version Old Data Object Start New Version CAS Locator TMObject New Data Object Copy Transaction Descriptor Status: ACTIVE Transaction Descriptor Status: COMMITTED Transaction Old Version New Version New Transaction Private Locator New Data Object

7. Commit Operation • Transaction commits by switching its state atomically to COMMITTED • Conflict is detected by checking the status of the owner transaction • Conflicts are handled by a Contention Manager (e.g. Polite Manager -exponential backoff with ABORT) • Contention Management is an independent system loosely coupled with DSTM • Choosing the right contention manager is crucial to system throughput

8. FSTM by Fraser (2004) • ObjectHeader points directly to the data object • Transaction acquires the target object during commit time during which ObjectHeader points to the transaction’s descriptor • Reads are invisible Data Object Start ObjectHeader FSTM Object Structure

9. Transaction Descriptor in FSTM Object Handle Status: ACTIVE Read-Write List Read-only List Next handle New data Transaction Descriptor Old data Object reference Start Data Object Shadow Copy ObjectHeader Copy FSTM Object

10. Open and Commit Operations Object Handle Status: COMMITTED Read-Write List Read-only List Status: ACTIVE Read-Write List Read-only List Next handle Open Operation New data Acquire Operation Commit Operation Transaction Descriptor Old data Object reference Start Data Object Shadow Copy ObjectHeader Copy

11. Commit Operation • It is a Multi-word CAS • Contention is detected when the ObjectHeader contains a pointer to another transaction • Contention is resolved by order based “helping” • Objects are acquired in some global total order to ensure lock-freedom

12. Comparison

13. Comparison (…continued)

14. Impact of Acquire Semantics FSTM outperforms DSTM. Reason on next slide. Red-Black Tree Performance Results

15. Impact of Acquire Semantics (…continued) Lazy acquire semantics in FSTM narrows down the window of contention significantly. Intuitively, eager acquire semantics will help detect contention earlier. Red-Black Tree Contention Instances

16. Lazy acquire and extra bookkeeping in FSTM Lazy acquire and extra bookkeeping in FSTM results in its poorer performance. DSTMs extra level of indirection and its Eager acquire semantics precludes the extra bookkeeping as required in FSTM Stack Performance Results

17. Bookkeeping and Ordering overhead in FSTM IntSet is an ordered list of integers with Insert and Delete operations. All objects are opened in write mode. Bookkeeping and Ordering literally kill FSTMs performance. There is no improvement even after removing incremental validation. IntSet Performance Results

18. Indirection Overhead in DSTM Variant of IntSet, where objects are released early to reduce contention. DSTMs extra indirection degrades its performance significantly due to the larger memory footprint of objects. IntSetRelease Performance Results

19. Incremental validation cost Variant of IntSet, where all objects are opened in read mode except for objects to be modified. DSTM pays the price of its extra indirection. Removing incremental Validation improves performance significantly. IntSetUpgrade Performance Results

20. Conclusions • DSTM performs better with writes, and FSTM with reads due to the indirection and corresponding bookkeeping • Acquire semantics are crucial - eager acquire helps detect contention early, whereas lazy acquire reduces the window of contention. Lazy acquire also permits ordering necessary for lock-freedom in FSTM • Incremental validation overhead identification is not trivial

21. Future Directions • Attack “indirection” based object access method to get the best of both worlds (DSTM and FSTM) • Further investigation of acquire semantics

22. Thank You!