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

4 November 2005CS 838 Presentation2 Outline Current Transactional Memory Model Current Transactional Memory Model Why nesting? Compositionality. Why nesting? Compositionality. Linear Nesting Linear Nesting Closed Transaction Semantics Closed Transaction Semantics Open Transaction Semantics Open Transaction Semantics Non-Linear Nesting Non-Linear Nesting Summary & Conclusions Summary & Conclusions

4 November 2005CS 838 Presentation3 Current TM Model One thread per processor One thread per processor –At a time One live transaction per thread One live transaction per thread –Live transaction: begun but not committed or aborted

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

4 November 2005CS 838 Presentation5 Versions & Conflicts Versions Versions –Global state –State per live transaction –Granularity? Conflicts Conflicts –One writer or multiple readers - Granularity? - Transaction = thread = processor

4 November 2005CS 838 Presentation6 Compositionality Should define and allow nesting Should define and allow nesting –Begin a new transaction within a live transaction Why? Why?

4 November 2005CS 838 Presentation7 Motivating Example atomic { a = init(); } foo(c); atomic { b++; } init() { atomic { d++; } return d; } User CodeLibrary Code

4 November 2005CS 838 Presentation8 Current HW Solution Current HTM’s subsume 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 Top-level transaction: one that’s not nested in any other transaction

4 November 2005CS 838 Presentation9 Linear Nesting Multiple transactions at same level Multiple transactions at same level Only one transaction per level live Only one transaction per level live Only one transaction running Only one transaction running –Can commit, abort, and do memory operations –Must be the deepest live transaction atomic { //x1 atomic { //x2 atomic { //x3 } atomic { //x4 }

4 November 2005CS 838 Presentation10 Terminology & Time Flow siblings descendant x4 x1 x3 x2 top-level parent child ancestor x4 x1 x3 x2 older younger

4 November 2005CS 838 Presentation11 Versions & Conflicts Versions Versions –Still have global version –Now additionally one version per live transaction per tree Conflicts Conflicts –Ancestors & descendants don’t conflict –Only conflict with other trees

4 November 2005CS 838 Presentation12 Semantics When are whose updates exposed to which other transactions? When are whose updates exposed to which other transactions? If there’s a conflict, how far to roll back? If there’s a conflict, how far to roll back?

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

4 November 2005CS 838 Presentation14 Closed Abort How far back to abort? How far back to abort? –Individual read and write sets –Roll back through oldest that conflicts Partial abort Partial abort –Roll back individual versions –Discard read and write sets

4 November 2005CS 838 Presentation15 Closed Commit 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

4 November 2005CS 838 Presentation16 Closed Data Visibility Updates made visible 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

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

4 November 2005CS 838 Presentation18 Applications Highly concurrent indexes & collections Highly concurrent indexes & collections Memory allocation & garbage collection Memory allocation & garbage collection Scheduler queue operations Scheduler queue operations “External” activities (I/O) “External” activities (I/O)

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

4 November 2005CS 838 Presentation20 Ancestor abort Parent executes the open’s compensating action Parent executes the open’s compensating action –As part of it’s rollback When? When? Atomically? Atomically? Hardware support? Hardware support? Open transaction should update some state so the parent knows what this is Open transaction should update some state so the parent knows what this is

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

4 November 2005CS 838 Presentation22 Intra-tree Overlap Running transaction’s write set overlaps ancestor read or write sets Running transaction’s write set overlaps ancestor read or write sets Bad: abstraction violation Bad: abstraction violation Open commit removes all written elements from read and write sets of all ancestors 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…

4 November 2005CS 838 Presentation23 Non-linear Nesting Within a single tree Within a single tree –Multiple transactions per level live –Multiple transactions running Execute single tree concurrently! Execute single tree concurrently! –Map to threads and processors?

4 November 2005CS 838 Presentation24 Versions & Conflicts Versions Versions –Still need one per live transactions, but now can have more live transactions Conflicts 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…) Can conflict with any transaction that’s not a direct ancestor (sibilings, uncles…)

4 November 2005CS 838 Presentation25 Summary & Conclusions Nested transactions Nested transactions –Linear nesting –Closed semantics –Open semantics –Non-linear nesting –Do we agree with these? Need hardware implementations Need hardware implementations –What subset to provide?