1 / 25

Nested Transactional Memory: Model and Preliminary Sketches

Nested Transactional Memory: Model and Preliminary Sketches. J. Eliot B. Moss and Antony L. Hosking Presented by: Michelle J. Moravan. Outline. Current Transactional Memory Model Why nesting? Compositionality. Linear Nesting Closed Transaction Semantics Open Transaction Semantics

Download Presentation

Nested Transactional Memory: Model and Preliminary Sketches

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related