Design Tradeoffs in Modern Software Transactional Memory Systems
description
Transcript of Design Tradeoffs in Modern Software Transactional Memory Systems
![Page 1: Design Tradeoffs in Modern Software Transactional Memory Systems](https://reader034.fdocuments.in/reader034/viewer/2022051215/56814a18550346895db73fbc/html5/thumbnails/1.jpg)
Virendra J. Marathe, William N. Scherer III, and Michael L. ScottDepartment of Computer ScienceUniversity of Rochester
Presented by: Armand R. Burks Fall 2008
![Page 2: Design Tradeoffs in Modern Software Transactional Memory Systems](https://reader034.fdocuments.in/reader034/viewer/2022051215/56814a18550346895db73fbc/html5/thumbnails/2.jpg)
Classic lock-based implementations of concurrent objects suffer from several important drawbacks: Deadlocks Priority inversion Convoying Lack of fault tolerance
![Page 3: Design Tradeoffs in Modern Software Transactional Memory Systems](https://reader034.fdocuments.in/reader034/viewer/2022051215/56814a18550346895db73fbc/html5/thumbnails/3.jpg)
Increased interest in nonblocking synchronization algorithms Failure of a thread can never prevent the
system from making forward progress
![Page 4: Design Tradeoffs in Modern Software Transactional Memory Systems](https://reader034.fdocuments.in/reader034/viewer/2022051215/56814a18550346895db73fbc/html5/thumbnails/4.jpg)
A concurrent object is a data object shared by multiple threads of control within a concurrent system.
![Page 5: Design Tradeoffs in Modern Software Transactional Memory Systems](https://reader034.fdocuments.in/reader034/viewer/2022051215/56814a18550346895db73fbc/html5/thumbnails/5.jpg)
Section 1 – IntroductionSection 2 – DSTMSection 3 – FSTMSection 4 – Comparative Evaluation
Section 5 – Related WorkSection 6 - Conclusions
![Page 6: Design Tradeoffs in Modern Software Transactional Memory Systems](https://reader034.fdocuments.in/reader034/viewer/2022051215/56814a18550346895db73fbc/html5/thumbnails/6.jpg)
Section 1:
Introduction
![Page 7: Design Tradeoffs in Modern Software Transactional Memory Systems](https://reader034.fdocuments.in/reader034/viewer/2022051215/56814a18550346895db73fbc/html5/thumbnails/7.jpg)
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.
![Page 8: Design Tradeoffs in Modern Software Transactional Memory Systems](https://reader034.fdocuments.in/reader034/viewer/2022051215/56814a18550346895db73fbc/html5/thumbnails/8.jpg)
Transaction A finite sequence of instructions (satisfying
the linearizability and atomicity properties) that is used to access and modify concurrent objects
![Page 9: Design Tradeoffs in Modern Software Transactional Memory Systems](https://reader034.fdocuments.in/reader034/viewer/2022051215/56814a18550346895db73fbc/html5/thumbnails/9.jpg)
This paper focuses on discussing two approaches to STM
Compares and evaluates strengths and weaknesses of the approaches
![Page 10: Design Tradeoffs in Modern Software Transactional Memory Systems](https://reader034.fdocuments.in/reader034/viewer/2022051215/56814a18550346895db73fbc/html5/thumbnails/10.jpg)
Section 2:
Dynamic Software Transactional Memory
![Page 11: Design Tradeoffs in Modern Software Transactional Memory Systems](https://reader034.fdocuments.in/reader034/viewer/2022051215/56814a18550346895db73fbc/html5/thumbnails/11.jpg)
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...
![Page 12: Design Tradeoffs in Modern Software Transactional Memory Systems](https://reader034.fdocuments.in/reader034/viewer/2022051215/56814a18550346895db73fbc/html5/thumbnails/12.jpg)
Start
TMObject Locator
Committed Transaction
Shared Object-Old
Version
Shared Object-New
Version
Transaction
Old Object
New Object
Transaction
New Object
Old Object
New Locator
Old Locator
New Active Transaction
Shared Object-New
Version
Copy
Atomic Compare & Swap (CAS)CAS FAILURE
X
Other transaction
has acquired
object
Opening a TMObject (in write mode) recently modified by a committed transaction
![Page 13: Design Tradeoffs in Modern Software Transactional Memory Systems](https://reader034.fdocuments.in/reader034/viewer/2022051215/56814a18550346895db73fbc/html5/thumbnails/13.jpg)
Most recent previous transaction may still be ACTIVE Wait/retry, abort, or force competitor to
abort Ask contention manager to make decision
![Page 14: Design Tradeoffs in Modern Software Transactional Memory Systems](https://reader034.fdocuments.in/reader034/viewer/2022051215/56814a18550346895db73fbc/html5/thumbnails/14.jpg)
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
![Page 15: Design Tradeoffs in Modern Software Transactional Memory Systems](https://reader034.fdocuments.in/reader034/viewer/2022051215/56814a18550346895db73fbc/html5/thumbnails/15.jpg)
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
![Page 16: Design Tradeoffs in Modern Software Transactional Memory Systems](https://reader034.fdocuments.in/reader034/viewer/2022051215/56814a18550346895db73fbc/html5/thumbnails/16.jpg)
Section 3:
Fraser’s Software Transactional Memory
(FSTM)
![Page 17: Design Tradeoffs in Modern Software Transactional Memory Systems](https://reader034.fdocuments.in/reader034/viewer/2022051215/56814a18550346895db73fbc/html5/thumbnails/17.jpg)
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
![Page 18: Design Tradeoffs in Modern Software Transactional Memory Systems](https://reader034.fdocuments.in/reader034/viewer/2022051215/56814a18550346895db73fbc/html5/thumbnails/18.jpg)
When transaction detects conflict with another, it uses the conflicting transaction’s descriptor to make updates, then aborts/restarts itself. Example follows:
![Page 19: Design Tradeoffs in Modern Software Transactional Memory Systems](https://reader034.fdocuments.in/reader034/viewer/2022051215/56814a18550346895db73fbc/html5/thumbnails/19.jpg)
B
B A
COMMITTED
AAbort & Restart
A
Concurrent Object
A
COMMITTED
![Page 20: Design Tradeoffs in Modern Software Transactional Memory Systems](https://reader034.fdocuments.in/reader034/viewer/2022051215/56814a18550346895db73fbc/html5/thumbnails/20.jpg)
Concurrent Object
Shadow Copy
Object Header
Transaction Descriptor
UNDECIDED
Status
Read-onlyRead-write
Object Handles
Unlike DSTM, multiple transactions can open the same object in write mode because each has its own shadow copy.
![Page 21: Design Tradeoffs in Modern Software Transactional Memory Systems](https://reader034.fdocuments.in/reader034/viewer/2022051215/56814a18550346895db73fbc/html5/thumbnails/21.jpg)
UNDECIDED ABORTED COMMITTED READ-CHECKING
![Page 22: Design Tradeoffs in Modern Software Transactional Memory Systems](https://reader034.fdocuments.in/reader034/viewer/2022051215/56814a18550346895db73fbc/html5/thumbnails/22.jpg)
UNDECIDED Transaction opens object headers while in
this state Open is not visible to other transactions
COMMITTEDIf open by another transaction, will be detectedIf conflict is detected, the transaction uses
recursive helping
![Page 23: Design Tradeoffs in Modern Software Transactional Memory Systems](https://reader034.fdocuments.in/reader034/viewer/2022051215/56814a18550346895db73fbc/html5/thumbnails/23.jpg)
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
![Page 24: Design Tradeoffs in Modern Software Transactional Memory Systems](https://reader034.fdocuments.in/reader034/viewer/2022051215/56814a18550346895db73fbc/html5/thumbnails/24.jpg)
Concurrent Object
Shadow Copy
Object Header
Transaction Descriptor
UNDECIDED
Status
Read-onlyRead-write
Object Handles
CAS
Recursively help competitor
![Page 25: Design Tradeoffs in Modern Software Transactional Memory Systems](https://reader034.fdocuments.in/reader034/viewer/2022051215/56814a18550346895db73fbc/html5/thumbnails/25.jpg)
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)
![Page 26: Design Tradeoffs in Modern Software Transactional Memory Systems](https://reader034.fdocuments.in/reader034/viewer/2022051215/56814a18550346895db73fbc/html5/thumbnails/26.jpg)
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 COMMITTEDDone automatically by transactionRelease object by swinging handle to new version
![Page 27: Design Tradeoffs in Modern Software Transactional Memory Systems](https://reader034.fdocuments.in/reader034/viewer/2022051215/56814a18550346895db73fbc/html5/thumbnails/27.jpg)
Section 4:
Comparative Evaluation
![Page 28: Design Tradeoffs in Modern Software Transactional Memory Systems](https://reader034.fdocuments.in/reader034/viewer/2022051215/56814a18550346895db73fbc/html5/thumbnails/28.jpg)
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
![Page 29: Design Tradeoffs in Modern Software Transactional Memory Systems](https://reader034.fdocuments.in/reader034/viewer/2022051215/56814a18550346895db73fbc/html5/thumbnails/29.jpg)
16-processor SunFire 6800 Cache-coherent multiprocessor
1.2 GHz Processors Environment – Sun’s Java 1.5 beta 1
HotSpot JVMAugmented with JSR166 update from Doug Lea
![Page 30: Design Tradeoffs in Modern Software Transactional Memory Systems](https://reader034.fdocuments.in/reader034/viewer/2022051215/56814a18550346895db73fbc/html5/thumbnails/30.jpg)
Simple Benchmarks A stack 3 variants of a list-based set
More Complex Benchmark Red-black tree
![Page 31: Design Tradeoffs in Modern Software Transactional Memory Systems](https://reader034.fdocuments.in/reader034/viewer/2022051215/56814a18550346895db73fbc/html5/thumbnails/31.jpg)
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
![Page 32: Design Tradeoffs in Modern Software Transactional Memory Systems](https://reader034.fdocuments.in/reader034/viewer/2022051215/56814a18550346895db73fbc/html5/thumbnails/32.jpg)
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)
![Page 33: Design Tradeoffs in Modern Software Transactional Memory Systems](https://reader034.fdocuments.in/reader034/viewer/2022051215/56814a18550346895db73fbc/html5/thumbnails/33.jpg)
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
![Page 34: Design Tradeoffs in Modern Software Transactional Memory Systems](https://reader034.fdocuments.in/reader034/viewer/2022051215/56814a18550346895db73fbc/html5/thumbnails/34.jpg)
Red-black Tree Performance Results
![Page 35: Design Tradeoffs in Modern Software Transactional Memory Systems](https://reader034.fdocuments.in/reader034/viewer/2022051215/56814a18550346895db73fbc/html5/thumbnails/35.jpg)
FSTM outperforms due to lazy acquire semantics
![Page 36: Design Tradeoffs in Modern Software Transactional Memory Systems](https://reader034.fdocuments.in/reader034/viewer/2022051215/56814a18550346895db73fbc/html5/thumbnails/36.jpg)
Number of Contention Instances
![Page 37: Design Tradeoffs in Modern Software Transactional Memory Systems](https://reader034.fdocuments.in/reader034/viewer/2022051215/56814a18550346895db73fbc/html5/thumbnails/37.jpg)
FSTM outperformed again Difference remained more or less constant
![Page 38: Design Tradeoffs in Modern Software Transactional Memory Systems](https://reader034.fdocuments.in/reader034/viewer/2022051215/56814a18550346895db73fbc/html5/thumbnails/38.jpg)
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)
![Page 39: Design Tradeoffs in Modern Software Transactional Memory Systems](https://reader034.fdocuments.in/reader034/viewer/2022051215/56814a18550346895db73fbc/html5/thumbnails/39.jpg)
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
![Page 40: Design Tradeoffs in Modern Software Transactional Memory Systems](https://reader034.fdocuments.in/reader034/viewer/2022051215/56814a18550346895db73fbc/html5/thumbnails/40.jpg)
Testing Benchmarks Stack, IntSet, IntSetRelease
![Page 41: Design Tradeoffs in Modern Software Transactional Memory Systems](https://reader034.fdocuments.in/reader034/viewer/2022051215/56814a18550346895db73fbc/html5/thumbnails/41.jpg)
Stack Performance Results
![Page 42: Design Tradeoffs in Modern Software Transactional Memory Systems](https://reader034.fdocuments.in/reader034/viewer/2022051215/56814a18550346895db73fbc/html5/thumbnails/42.jpg)
Stack illustrates very high contention (top-of-stack pointer)
DSTM outperformance Due to FSTM extra bookkeeping in write
mode
![Page 43: Design Tradeoffs in Modern Software Transactional Memory Systems](https://reader034.fdocuments.in/reader034/viewer/2022051215/56814a18550346895db73fbc/html5/thumbnails/43.jpg)
IntSet maintains sorted list Every insert/delete opens (write mode) all
objects from beginning of list Successful transactions are serialized
![Page 44: Design Tradeoffs in Modern Software Transactional Memory Systems](https://reader034.fdocuments.in/reader034/viewer/2022051215/56814a18550346895db73fbc/html5/thumbnails/44.jpg)
IntSet Performance Results
![Page 45: Design Tradeoffs in Modern Software Transactional Memory Systems](https://reader034.fdocuments.in/reader034/viewer/2022051215/56814a18550346895db73fbc/html5/thumbnails/45.jpg)
Higher throughput for DSTM FSTM suffers extra bookkeeping
overhead, sorting overhead, and extra CASes
![Page 46: Design Tradeoffs in Modern Software Transactional Memory Systems](https://reader034.fdocuments.in/reader034/viewer/2022051215/56814a18550346895db73fbc/html5/thumbnails/46.jpg)
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
![Page 47: Design Tradeoffs in Modern Software Transactional Memory Systems](https://reader034.fdocuments.in/reader034/viewer/2022051215/56814a18550346895db73fbc/html5/thumbnails/47.jpg)
IntSetRelease Performance Results
![Page 48: Design Tradeoffs in Modern Software Transactional Memory Systems](https://reader034.fdocuments.in/reader034/viewer/2022051215/56814a18550346895db73fbc/html5/thumbnails/48.jpg)
FSTM more than a factor of 2 better DSTM’s indirection is to blame
![Page 49: Design Tradeoffs in Modern Software Transactional Memory Systems](https://reader034.fdocuments.in/reader034/viewer/2022051215/56814a18550346895db73fbc/html5/thumbnails/49.jpg)
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)
![Page 50: Design Tradeoffs in Modern Software Transactional Memory Systems](https://reader034.fdocuments.in/reader034/viewer/2022051215/56814a18550346895db73fbc/html5/thumbnails/50.jpg)
On a memory access violation, exception handler validates the transaction that caused the exception
Responsibility of detecting other inconsistencies is left to the programmer
![Page 51: Design Tradeoffs in Modern Software Transactional Memory Systems](https://reader034.fdocuments.in/reader034/viewer/2022051215/56814a18550346895db73fbc/html5/thumbnails/51.jpg)
IntSetUpgrade Similar to IntSetRelease
Opens in write mode only if object needs to be changed
The fact that most objects are read-only introduces some concurrency
![Page 52: Design Tradeoffs in Modern Software Transactional Memory Systems](https://reader034.fdocuments.in/reader034/viewer/2022051215/56814a18550346895db73fbc/html5/thumbnails/52.jpg)
IntSetUpgrade Performance Results
![Page 53: Design Tradeoffs in Modern Software Transactional Memory Systems](https://reader034.fdocuments.in/reader034/viewer/2022051215/56814a18550346895db73fbc/html5/thumbnails/53.jpg)
Incremental validation introduces dramatic overhead in both systems Results suggest potential benefits from
using application-specific reasoning to eliminate need (or at least frequency of) incremental validation
![Page 54: Design Tradeoffs in Modern Software Transactional Memory Systems](https://reader034.fdocuments.in/reader034/viewer/2022051215/56814a18550346895db73fbc/html5/thumbnails/54.jpg)
Related Work&
Conclusions
![Page 55: Design Tradeoffs in Modern Software Transactional Memory Systems](https://reader034.fdocuments.in/reader034/viewer/2022051215/56814a18550346895db73fbc/html5/thumbnails/55.jpg)
Harris & Fraser – word-based STM Hashes shared memory words into
ownership records Transaction acquires records before
updating Harris & Fraser – novel stealing mechanism
Avoids cache thrashing that might result from recursive helping
Cole & Herlihy – optimization to DSTM to reduce bookkeeping overhead in read mode
![Page 56: Design Tradeoffs in Modern Software Transactional Memory Systems](https://reader034.fdocuments.in/reader034/viewer/2022051215/56814a18550346895db73fbc/html5/thumbnails/56.jpg)
Paper evaluated tradeoffs in design of practical, object-based STM systems
DSTM tends to do better for transactions in write mode Early detection & avoidance of bookkeeping Both systems incur significant overhead for
read-only Acquire semantics play key role in
performance
![Page 57: Design Tradeoffs in Modern Software Transactional Memory Systems](https://reader034.fdocuments.in/reader034/viewer/2022051215/56814a18550346895db73fbc/html5/thumbnails/57.jpg)