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

Slides:



Advertisements
Similar presentations
Enabling Speculative Parallelization via Merge Semantics in STMs Kaushik Ravichandran Santosh Pande College.
Advertisements

Principles of Transaction Management. Outline Transaction concepts & protocols Performance impact of concurrency control Performance tuning.
Concurrency Control II. General Overview Relational model - SQL  Formal & commercial query languages Functional Dependencies Normalization Physical Design.
1 ICS 214B: Transaction Processing and Distributed Data Management Lecture 5: Tree-based Concurrency Control and Validation Currency Control Professor.
Concurrency Control Part 2 R&G - Chapter 17 The sequel was far better than the original! -- Nobody.
© 2006 Mulitfacet ProjectUniversity of Wisconsin-Madison Supporting Nested Transactional Memory in LogTM Michelle J. Moravan, Jayaram Bobba, Kevin E. Moore,
U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science Rich Transactions on Reasonable Hardware J. Eliot B. Moss Univ. of Massachusetts,
McRT-Malloc: A Scalable Non-Blocking Transaction Aware Memory Allocator Ali Adl-Tabatabai Ben Hertzberg Rick Hudson Bratin Saha.
It’s the Software, Stupid James Larus Microsoft Research April 2005.
Pessimistic Software Lock-Elision Nir Shavit (Joint work with Yehuda Afek Alexander Matveev)
Lecture 11 Recoverability. 2 Serializability identifies schedules that maintain database consistency, assuming no transaction fails. Could also examine.
Database Systems, 8 th Edition Concurrency Control with Time Stamping Methods Assigns global unique time stamp to each transaction Produces explicit.
Transactional Memory Overview Olatunji Ruwase Fall 2007 Oct
Thread-Level Transactional Memory Decoupling Interface and Implementation UW Computer Architecture Affiliates Conference Kevin Moore October 21, 2004.
Sathya Peri, IIT Patna, India, K.Vidyasankar, Memorial University, St John’s, Canada, 1 Efficient Non-Blocking.
Nested Parallelism in Transactional Memory Kunal Agrawal, Jeremy T. Fineman and Jim Sukha MIT.
Transactional Memory (TM) Evan Jolley EE 6633 December 7, 2012.
CS444/CS544 Operating Systems Synchronization 2/16/2006 Prof. Searleman
Nested Transactional Memory: Model and Preliminary Architecture Sketches J. Eliot B. Moss Antony L. Hosking.
Distributed Systems Fall 2010 Transactions and concurrency control.
1 Lecture 7: Transactional Memory Intro Topics: introduction to transactional memory, “lazy” implementation.
CS 245Notes 101 CS 245: Database System Principles Notes 10: More TP Hector Garcia-Molina.
Transaction Management and Concurrency Control
CS444/CS544 Operating Systems Atomic Transactions 3/26/2007 Prof. Searleman
1 Lecture 24: Transactional Memory Topics: transactional memory implementations.
Supporting Nested Transactional Memory in LogTM Authors Michelle J Moravan Mark Hill Jayaram Bobba Ben Liblit Kevin Moore Michael Swift Luke Yen David.
Selfishness in Transactional Memory Raphael Eidenbenz, Roger Wattenhofer Distributed Computing Group Game Theory meets Multicore Architecture.
CS510 Concurrent Systems Class 13 Software Transactional Memory Should Not be Obstruction-Free.
Department of Computer Science Presenters Dennis Gove Matthew Marzilli The ATOMO ∑ Transactional Programming Language.
Operating Systems (CSCI2413) Lecture 3 Processes phones off (please)
Database Systems: Design, Implementation, and Management Eighth Edition Chapter 10 Transaction Management and Concurrency Control.
Transaction Management and Concurrency Control
Transactions and Reliability. File system components Disk management Naming Reliability  What are the reliability issues in file systems? Security.
Data Concurrency Control And Data Recovery
Cosc 4740 Chapter 6, Part 3 Process Synchronization.
BIS Database Systems School of Management, Business Information Systems, Assumption University A.Thanop Somprasong Chapter # 10 Transaction Management.
CS 245Notes 101 CS 245: Database System Principles Notes 10: More TP Hector Garcia-Molina.
CS5204 – Operating Systems Transactional Memory Part 2: Software-Based Approaches.
Concurrency and Transaction Processing. Concurrency models 1. Pessimistic –avoids conflicts by acquiring locks on data that is being read, so no other.
1 CS 430 Database Theory Winter 2005 Lecture 16: Inside a DBMS.
Lowering the Overhead of Software Transactional Memory Virendra J. Marathe, Michael F. Spear, Christopher Heriot, Athul Acharya, David Eisenstat, William.
Database structure and space Management. Segments The level of logical database storage above an extent is called a segment. A segment is a set of extents.
II.I Selected Database Issues: 2 - Transaction ManagementSlide 1/20 1 II. Selected Database Issues Part 2: Transaction Management Lecture 4 Lecturer: Chris.
Lecture 13 Advanced Transaction Models. 2 Protocols considered so far are suitable for types of transactions that arise in traditional business applications,
System Components ● There are three main protected modules of the System  The Hardware Abstraction Layer ● A virtual machine to configure all devices.
1 CSE232A: Database System Principles More Concurrency Control and Transaction Processing.
9 1 Chapter 9_B Concurrency Control Database Systems: Design, Implementation, and Management, Rob and Coronel.
Chapter 13 Managing Transactions and Concurrency Database Principles: Fundamentals of Design, Implementation, and Management Tenth Edition.
Transactions and Reliability
Process Management Process Concept Why only the global variables?
Speculative Lock Elision
Software Perspectives on Transactional Memory
Part 2: Software-Based Approaches
Threads Cannot Be Implemented As a Library
Why The Grass May Not Be Greener On The Other Side: A Comparison of Locking vs. Transactional Memory By McKenney, Michael, Triplett and Walpole.
Hardware Transactional Memory
CS 632 Lecture 6 Recovery Principles of Transaction-Oriented Database Recovery Theo Haerder, Andreas Reuter, 1983 ARIES: A Transaction Recovery Method.
Changing thread semantics
Lecture 6: Transactions
Printed on Monday, December 31, 2018 at 2:03 PM.
Ch 22: Databases Concurrency Control
Final Review Datalog (Ch 10) Rules and queries
Hybrid Transactional Memory
Introduction of Week 13 Return assignment 11-1 and 3-1-5
Software Transactional Memory Should Not be Obstruction-Free
Transactions with Nested Parallelism
Ranjeet Kumar K. Vidyasankar Memorial University St. John’s CANADA
Lecture 23: Transactional Memory
CONCURRENCY Concurrency is the tendency for different tasks to happen at the same time in a system ( mostly interacting with each other ) .   Parallel.
Concurrent Cache-Oblivious B-trees Using Transactional Memory
Presentation transcript:

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?