Transaction Safe Nonblocking Data Structures

1. Transaction Safe Nonblocking Data Structures Virendra J. Marathe, Michael F. Spear, and Michael L. Scott University of Rochester

2. Motivation • Transactional Memory • Simplifies concurrent programming • Promising for programming multi-cores • However, • Incompatible with legacy concurrent software (e.g. Java concurrency library) • Performance (with STMs) and semantic issues (e.g. I/O) • Nonblocking concurrent data structures • Can sometimes outperform lock-based code • Avoid scheduler-based performance anomalies

3. Our Work • Ensure interoperability of transactions with ad hoc nonblocking algorithms • Operation invocations • can happen inside and outside transactions, • external uses serialize with transactions, and • internal uses succeed iff transactions commit

4. Transaction Safety of Nonblocking Objects • Key • Memory accesses by a transaction occur iff surrounding transaction commits • Make memory accesses speculative • Writes are marked as speculative • Reads are logged for commit time validation • Non-transactional invocations • Behave as the original algorithm • But abort conflicting transactions if necessary

5. Transaction Aware Primitives • Primitive types, e.g. references, integers, etc. • Get(), Set(), Compare&Swap() are transaction-aware • e.g. AtomicReference (a Java concurrent library class) Owner Transaction Data Object Old Version Old Object New Version Txnal-Safe AtomicReference Txnal-Safe AtomicReference Locator New Object Reference after Txnal Write “Clean” Reference

6. Examples • Michael and Scott’s lock-free queue • Make Head, Tail, and Next (of each node) transaction safe • Harris’ lock-free linked list • Make Next (of each node) transaction safe • Prototype implementation in ASTM library

7. Performance

8. Ongoing work • Transforming more diverse algorithms • Formalization • Safe optimizations in our approach

9. Thank You! Questions?