1 / 46

A Qualitative Survey of Modern Software Transactional Memory Systems

Virendra J. Marathe Michael L. Scott. A Qualitative Survey of Modern Software Transactional Memory Systems. Introduction. Software Transactional Memory. Introduction. Herlihy and Moss proposed STM as a novel architectural support mechanism for nonblocking synchronization. Introduction.

tress
Download Presentation

A Qualitative Survey of Modern Software Transactional Memory Systems

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. Virendra J. Marathe Michael L. Scott A Qualitative Survey of Modern Software Transactional Memory Systems

  2. Introduction Software Transactional Memory

  3. Introduction • Herlihy and Moss proposed STM as a novel architectural support mechanism for nonblocking synchronization

  4. Introduction • Herlihy and Moss proposed STM as a novel architectural support mechanism for nonblocking synchronization • implemented a transactional memory by extending multiprocessor cache coherency protocols • provided an instruction set for accessing shared memory

  5. Introduction • We will see • Software Transactional Memory (Shavit 95) • Hash Table Based STM (Harris 03) • Dynamic Software Transactional Memory (DSTM) • a Lock Free Object Based STM (FSTM) [Fraser 03] • We will make a qualitative comparison of these implementations

  6. The STM Algorithm STM, by Shavit and Toitou[1995]

  7. STM, by Shavit and Toitou[1995] • The Transaction lists the memory it needs • The Transaction attempts to take “ownership” of the needed memory • If any ownerships cannot be taken, the transaction fails and retries • Change the state to COMITTED atomically • Make updates • Release all ownerships

  8. STM, by Shavit and Toitou[1995] • A memory word is used as the concurrent object • Each memory word has a corresponding ownership Record (orec) • The orec may be NULL (no transaction owns the orec) • The orec may be a reference to a transaction record

  9. STM, by Shavit and Toitou[1995] Memory Ownership Records Transaction Record Null

  10. STM, by Shavit and Toitou[1995] • Helping • used to avoid livelocks • Ownerships are acquired in some global order • if A finds that process B owns a record, A will make B's updates on B's behalf. • helping is done non-recursively

  11. STM, by Shavit and Toitou[1995] • Drawbacks • To ensure ordered access, one must know all memory words one will access before one starts • each shared memory word requires an orec of equal size. This doubles the memory requirement of STM • There is an efficiency drawback, due to contention overhead during helping.

  12. Hash Table Based STM • Word based STM • Uses a hash table for the orecs • provides an interface to the STM

  13. Hash Table Based STM • Data Structures • The Application Heap • The Hash Table of orecs • transaction descriptors

  14. Hash Table Based STM • Application Heap is the shared memory that holds the data the concurrent processes use • Uses a hash table for the orecs • The shared memory locations hash into the orecs hash table. • Each orec has a version number or a reference to the transaction descriptor of the transaction that currently owns the orec • When a transaction owns an orec it also owns all other memory hashing into that orec!

  15. Application Heap Ownership Record Transaction Descriptor

  16. Hash Table Based STM • The Interface • void STMStart() • stm_word STMRead( addr a ) • void STMWrite( addr am stm_word w ) • void STMAbort() • boolean STMCommit() • boolean STMValidate() • void STMWait()

  17. Application Heap Ownership Record Transaction Descriptor Before

  18. Application Heap Ownership Record Transaction Descriptor New Transaction Entry : The Address being accessed Old Value and Version num. New Value and Version num STMRead or STMWrite

  19. Application Heap Ownership Record Transaction Descriptor Address being accessed Old Value and Version num. New Value and Version num STMCommit

  20. Application Heap Ownership Record Transaction Descriptor transaction 2 Address being accessed Old Value and Version num. New Value and Version num transaction 2 Read Conflict !

  21. Application Heap Ownership Record Transaction Descriptor transaction 2 Address being accessed Old Value and Version num. New Value and Version num transaction 2 Acquire Conflict !

  22. Hash Table Based STM • Acquire Conflict : • If the conflicting transaction is ACTIVE the current transaction aborts it. • Then the current transaction verifies the consistency of the version number of the orec under conflict with the latest valid version number in the conflicting transaction's descriptor. If an inconsistency is detected, Abort and release all acquired ownerships • next help or steal

  23. Hash Table Based STM • Stealing vs Helping • Helping is expensive due to contention • To Steal, the transaction merges the transaction entries corresponding to the orec under conflict into its own transaction descriptor using atomic CAS.

  24. Hash Table Based STM • Design and Efficiency Issues • Contention management, or polite vs aggressive : polite algorithms perform better • Bounded Memory Blow-Up Problem : When a stealer merges descriptors, the stealer may end up possessing several records it doesn't care about

  25. Hash Table Based STM • An LL/SC based approach may reduce the effects of the Bounded Memory Blow-Up problem.

  26. Object-based Software Transactional Memory Systems

  27. Dynamic Software Transaction Memory (DSTM) Object-based Software Transactional Memory Systems

  28. DSTM • a Transactional Memory object is a wrapper around the concurrent data object. This contains a pointer to • a Locator object stores a pointer to a descriptor of the most recent modifying transaction, and to the old and new versions of the data object.

  29. Committed Transaction Transaction New Obj Old Obj TM Obj. Shared Obj. New Ver. Shared Obj, Old Ver. New Active Transaction Transaction New Obj Old Obj Shared Obj, new Vers. Copy

  30. DSTM • A Transaction Descriptor may be in one of 3 states. These determine the most recent valid version of the data object • ACTIVE : the old version is correct • ABORTED : the old version is correct • COMMITTED : the new version is correct

  31. DSTM • The locator is not an orec • The locator is referenced by the TM object, the orec is found by a hash function • The locator points to old and new versions of the data, the orec stores a version number or points to a descriptor with the old and new versions of the data • The locator does not require a version number

  32. Lock-Free Object Based STM (FSTM) Object-based Software Transactional Memory Systems

  33. Lock-Free Object Based STM (FSTM) • Data Structures • Object Header wraps the concurrent object • Transaction Descriptor is used by each transaction to maintain the list of in-use concurrent objects. This object maintains two lists (read only and read write) • Object Handles consist of references to an object header, the concurrent object referenced bu the object header and a shadow copy of the concurrent object.

  34. List of object handles Object Ref, old and new data, next handle UNDECIDED Object Header Concurrent Obj. Shadow Copy

  35. Lock-Free Object Based STM (FSTM) • To access an object • Open the object using that object header • This creates an object handle in that object's descriptor

  36. Lock-Free Object Based STM (FSTM) • Committing a change • Acquire phase • Decision Point • Release Phase

  37. Lock-Free Object Based STM (FSTM) • Acquire Phase • Acquire each concurrent object in read-write object handle list. Do so in global total order using atomic CAS • on fail, if the conflict is with a modified object, abort • on fail, if conflict is with an uncommitted transaction, help the conflicting transaction • decide whether to commit or abort

  38. Lock-Free Object Based STM (FSTM) • READ-CHECKING state • Decide whether the transactions committed or aborted • Begin the read phase, and walk through the descriptor's read-only list • If there is a conflict, verify the data's consistency • if the conflict is with an UNDECIDED transaction, verify the old data in the conflicting object handle. If the data object is different, ABORT

  39. The Qualitative Comparison • Object Acquire Semantics • Indirection Overhead • Space Usage • Search Overhead • Contention Management vs Helping • Transaction Validation

  40. The Qualitative Comparison • Object Acquire Semantics • Eager Acquire vs Lazy Acquire

  41. The Qualitative Comparison • Indirection Overhead • DSTM requires n+1 CAS to commit • FSTM and Hash Table require 2N+2 CAS

  42. The Qualitative Comparison • Space Usage • The space requirement of DSTM is more than twice that of FSTM usually

  43. The Qualitative Comparison • Search Overhead • FSTM and Hash Table require a search for the concurrent object under conflict • DSTM does not

  44. The Qualitative Comparison • Contention Management vs Helping • need empirical testing of this

  45. The Qualitative Comparison • Transaction Validation

  46. Finis

More Related