1 / 57

Design Tradeoffs in Modern Software Transactional Memory Systems

Virendra J. Marathe , William N. Scherer III, and Michael L. Scott Department of Computer Science University of Rochester. Design Tradeoffs in Modern Software Transactional Memory Systems. Presented by: Armand R. Burks Fall 2008.

badu
Download Presentation

Design Tradeoffs in 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, William N. Scherer III, and Michael L. Scott Department of Computer Science University of Rochester Design Tradeoffs in Modern Software Transactional Memory Systems Presented by: Armand R. Burks Fall 2008

  2. Classic lock-based implementations of concurrent objects suffer from several important drawbacks: • Deadlocks • Priority inversion • Convoying • Lack of fault tolerance Background info.

  3. Increased interest in nonblocking synchronization algorithms • Failure of a thread can never prevent the system from making forward progress Background info. Cont’d.

  4. A concurrent object is a data object shared by multiple threads of control within a concurrent system. Definition...

  5. Section 1 – Introduction Section 2 – DSTM Section 3 – FSTM Section 4 – Comparative Evaluation Section 5 – Related Work Section 6 - Conclusions Outline

  6. Section 1: Introduction

  7. STM – an approach to construct nonblocking objects • Simplifies task of implementing concurrent objects • Software Transactional Memory (STM) is a generic non-blocking synchronization construct that enables automatic conversion of correct sequential objects into correct concurrent objects. Intro: Software Transactional Memory

  8. Transaction • A finite sequence of instructions (satisfying the linearizability and atomicity properties) that is used to access and modify concurrent objects Definition...

  9. This paper focuses on discussing two approaches to STM • Compares and evaluates strengths and weaknesses of the approaches Purpose of Paper

  10. Section 2: Dynamic Software Transactional Memory

  11. Definition... • DSTM is a low-level application programming interface (API) for synchronizing shared data without using locks. (Herlihy) • Uses early release ( a transaction can drop a previously opened object) • Invisible reads • Example follows... Dynamic Software Transactional Memory (DSTM)

  12. DSTM Cont’d. Committed Transaction Start Transaction X New Object Shared Object-New Version Copy Old Object TMObject Old Locator Locator Atomic Compare & Swap (CAS) Shared Object-Old Version CAS FAILURE Other transaction has acquired object New Active Transaction Transaction New Object Old Object Shared Object-New Version New Locator Opening a TMObject (in write mode) recently modified by a committed transaction

  13. Most recent previous transaction may still be ACTIVE • Wait/retry, abort, or force competitor to abort • Ask contention manager to make decision DSTM Contention

  14. Full acquire operation • Unnecessary contention between transactions • How do we avoid this contentention? • Each transaction maintains private (read-list) of objects opened in read-only mode • Must recheck validity before committing DSTM- What about read-only?

  15. What about stale data (from a not yet committed transaction)? • May lead to unwanted behavior ( addressing errors, infinite loops, division by zero, etc.) • Transaction would have to revalidate all open read-only objects • Current version does this automatically when opening DSTM Read-only contd...

  16. Section 3: Fraser’s Software Transactional Memory (FSTM)

  17. Named after Keir Fraser (Cambridge) • Unlike DSTM, FSTM is lock-free • Guarantees forward progress for system (within a bounded number of steps, some thread is guaranteed to complete a transaction) • How? • Recursive helping FSTM

  18. When transaction detects conflict with another, it uses the conflicting transaction’s descriptor to make updates, then aborts/restarts itself. • Example follows: FSTM – Recursive helping

  19. FSTM- Recursive helping cont’d... A A B B A Concurrent Object Abort & Restart A COMMITTED COMMITTED

  20. Basic Transactional Memory structure New data Next handle Object ref Old data Status UNDECIDED Read-only Read-write Object Handles Transaction Descriptor Concurrent Object Shadow Copy Object Header Unlike DSTM, multiple transactions can open the same object in write mode because each has its own shadow copy.

  21. UNDECIDED • ABORTED • COMMITTED • READ-CHECKING FSTM- Transaction states

  22. UNDECIDED • Transaction opens object headers while in this state • Open is not visible to other transactions • COMMITTED • If open by another transaction, will be detected • If conflict is detected, the transaction uses recursive helping FSTM- Transaction states cont’d...

  23. Transaction acquires all objects it opened in write mode in some global total order (virtual address) • Uses atomic Compare and Swaps • Each CAS swings object header’s pointer to transaction descriptor • If pointer already points to another transaction’s descriptor, conflict is detected • Example follows Commit phase

  24. CAS Conflict discovery Object ref Old data Status UNDECIDED Read-only Read-write Object Handles Transaction Descriptor Concurrent Object Shadow Copy CAS Object Header Recursively help competitor

  25. Only proceeds if competitor precedes in in global total order (thread/transaction id) • If not, competitor will be aborted • Also, competitor must be in READ-CHECKING state (for validating) Recursive helping

  26. Validates objects in read-only list • Verify object header still points to version of object as when handle was created • If not, abort • If pointing to another transaction, recursively help • After successful validation, switch to COMMITTED • Done automatically by transaction • Release object by swinging handle to new version REAd-checking state

  27. Section 4: Comparative Evaluation

  28. Both DSTM and FSTM have significant overhead • Simpler than previous approaches • This section does the following • Highlight design tradeoffs between the two • Highlight impact on performance of various concurrent data structures Comparative evaluation

  29. 16-processor SunFire 6800 • Cache-coherent multiprocessor • 1.2 GHz Processors • Environment – Sun’s Java 1.5 beta 1 HotSpot JVM • Augmented with JSR166 update from Doug Lea Experimental environment

  30. Simple Benchmarks • A stack • 3 variants of a list-based set • More Complex Benchmark • Red-black tree Testing benchmarks

  31. In list and Red-black tree benchmarks • Repeatedly/Randomly insert/delete integers 0-255 • Keeping this range small increases probability of contention • Measured total throughput over 10 seconds • Vary number of worker threads between 1-48 • Six test runs Testing benchmarks cont’d...

  32. DSTM • Transaction acquires exclusive access when it first opens it for write access • Makes transaction visible to potential competitors early in its lifetime (eager acquire) • FSTM • Transaction acquires exclusive access only in commit phase • Makes transaction visible to potential competitors later in its lifetime (lazy acquire) Object acquire semantics

  33. Eager acquire • Enables earlier detection & resolution of conflicts • Lazy acquire • May cause transactions to waste computational resources on doomed transactions before detecting a conflict • Tends to reduce amount of transactions identified as competitors • If application semantics allow both transactions to commit, lazy acquire may result in higher concurrency Object acquire semantics

  34. Object acquire semantics – performance results Red-black Tree Performance Results

  35. FSTM outperforms due to lazy acquire semantics Object acquire semantics – performance results

  36. Object acquire semantics – performance results Number of Contention Instances

  37. FSTM outperformed again • Difference remained more or less constant Object acquire semantics – performance results

  38. DSTM has extra level of indirection (Fig 1. & 2) • TMObject points to Locator which points to object data • FSTM object header points directly to object data • Extra indirection may result in slower reads/writes • Slower transactions (particularly if most are read-only) Bookkeeping and indirection

  39. Indirection eliminates overhead of inserting object handles into descriptor chains • Transactions with large number of writes may be faster in DSTM • Lazy acquire requires extra bookkeeping Bookkeeping and indirection

  40. Testing Benchmarks • Stack, • IntSet, • IntSetRelease Bookkeeping and indirection Performance

  41. Bookkeeping and indirection Performance Results Stack Performance Results

  42. Stack illustrates very high contention (top-of-stack pointer) • DSTM outperformance • Due to FSTM extra bookkeeping in write mode Bookkeeping and indirection Performance Results

  43. IntSet maintains sorted list • Every insert/delete opens (write mode) all objects from beginning of list • Successful transactions are serialized Bookkeeping and indirection intset

  44. Bookkeeping and indirection Performance Results IntSet Performance Results

  45. Higher throughput for DSTM • FSTM suffers extra bookkeeping overhead, sorting overhead, and extra CASes Bookkeeping and indirection Performance Results

  46. IntSetRelease – variant of IntSet • Only the object to be modified is opened in write mode • All others opened temporarily in read mode • Then either released (moving on to next node in list) • Or upgraded to write mode Bookkeeping and indirection intsetrelease

  47. Bookkeeping and indirection Performance Results IntSetRelease Performance Results

  48. FSTM more than a factor of 2 better • DSTM’s indirection is to blame Bookkeeping and indirection Performance Results

  49. Invisible reads & lazy acquire (FSTM) may allow transaction to enter inconsistent state during execution • This may lead to memory access violations, infinite loops, arithmetic faults, etc. • DSTM- performs incremental validation at open time • FSTM- proposes mechanism based on exception handling (catch problems when they arise rather than prevent them) Transaction validation

  50. On a memory access violation, exception handler validates the transaction that caused the exception • Responsibility of detecting other inconsistencies is left to the programmer Transaction validation - fstm

More Related