Nested Transactional Memory: Model and Preliminary Sketches

1. Nested Transactional Memory:Model and Preliminary Sketches J. Eliot B. Moss and Antony L. Hosking Presented by: Michelle J. Moravan CS 838 Presentation

2. Outline • Current Transactional Memory Model • Why nesting? Compositionality. • Linear Nesting • Closed Transaction Semantics • Open Transaction Semantics • Non-Linear Nesting • Summary & Conclusions CS 838 Presentation

3. Current TM Model • One thread per processor • At a time • One live transaction per thread • Live transaction: begun but not committed or aborted CS 838 Presentation

4. T1 T2 P1 P2 Illustration atomic { tmp = a; a = b; b = tmp; } atomic { a = init(); } foo(c); atomic { b++; } CS 838 Presentation

5. Versions & Conflicts • Versions • Global state • State per live transaction • Granularity? • Conflicts • One writer or multiple readers • Granularity? • Transaction = thread = processor CS 838 Presentation

6. Compositionality • Should define and allow nesting • Begin a new transaction within a live transaction • Why? CS 838 Presentation

7. Motivating Example User Code Library Code atomic { a = init(); } foo(c); atomic { b++; } init() { atomic { d++; } return d; } CS 838 Presentation

8. Current HW Solution • Current HTM’s subsume • Treat instructions of inner transactions as though they were explicitly part of the top-level transaction • Top-level transaction: one that’s not nested in any other transaction CS 838 Presentation

9. Linear Nesting atomic { //x1 atomic { //x2 atomic { //x3 } } atomic { //x4 } } • Multiple transactions at same level • Only one transaction per level live • Only one transaction running • Can commit, abort, and do memory operations • Must be the deepest live transaction CS 838 Presentation

10. x1 x2 x4 x3 Terminology & Time Flow ancestor top-level x1 older parent child x2 x4 siblings younger descendant x3 CS 838 Presentation

11. Versions & Conflicts • Versions • Still have global version • Now additionally one version per live transaction per tree • Conflicts • Ancestors & descendants don’t conflict • Only conflict with other trees CS 838 Presentation

12. Semantics • When are whose updates exposed to which other transactions? • If there’s a conflict, how far to roll back? CS 838 Presentation

13. Subsuming Abort atomic { … … … … atomic { } } Roll back Low contention Closed Abort High contention Conflict! Closed Transactions • Don’t redo more than needed • Partial roll back • Only as far as required to resolve the conflict • Performance enchancement CS 838 Presentation

14. Closed Abort • How far back to abort? • Individual read and write sets • Roll back through oldest that conflicts • Partial abort • Roll back individual versions • Discard read and write sets CS 838 Presentation

15. Closed Commit • Commit • After commit, looks as though was subsumed • If parent rolls back, it rolls back committed children’s effects too • Merge read and write sets and versions into parent’s on commit CS 838 Presentation

16. Closed Data Visibility • Updates made visible • To other transactions in the same tree, as soon as they occur • To other trees, only when the top-level transaction commits CS 838 Presentation

17. Open Transactions • Same as closed, but additionally… • On inner commit • Discard read and write sets • Push writes through to global state • Updates made visible • To other trees, as soon as the running transaction commits • Goal: increased concurrency CS 838 Presentation

18. Applications • Highly concurrent indexes & collections • Memory allocation & garbage collection • Scheduler queue operations • “External” activities (I/O) CS 838 Presentation

19. Intended Use • Open transaction represents a single logical operation at a higher level of abstraction • At that level, it should have a compensating action • A semantic undo, as opposed to undo by backing out the component low-level writes CS 838 Presentation

20. Ancestor abort • Parent executes the open’s compensating action • As part of it’s rollback • When? • Atomically? • Hardware support? • Open transaction should update some state so the parent knows what this is CS 838 Presentation

21. Inter-tree Dependences • How to compensate for effects on other trees? • Software should provide locking at the higher level of abstraction to proactively prevent • Still increasing concurrency? • Open transaction should also manipulate this state CS 838 Presentation

22. Intra-tree Overlap • Running transaction’s write set overlaps ancestor read or write sets • Bad: abstraction violation • Open commit removes all written elements from read and write sets of all ancestors • To break dependences • Programmer can always reinstate them at a higher level of abstraction… CS 838 Presentation

23. Non-linear Nesting • Within a single tree • Multiple transactions per level live • Multiple transactions running • Execute single tree concurrently! • Map to threads and processors? CS 838 Presentation

24. Versions & Conflicts • Versions • Still need one per live transactions, but now can have more live transactions • Conflicts • Still have conflicts among trees • Now additionally have within a tree: • Can conflict with any transaction that’s not a direct ancestor (sibilings, uncles…) CS 838 Presentation

25. Summary & Conclusions • Nested transactions • Linear nesting • Closed semantics • Open semantics • Non-linear nesting • Do we agree with these? • Need hardware implementations • What subset to provide? CS 838 Presentation