Presentation on theme: "Virendra J. Marathe, William N. Scherer III, and Michael L. Scott Department of Computer Science University of Rochester Presented by: Armand R. Burks."— Presentation transcript:
Virendra J. Marathe, William N. Scherer III, and Michael L. Scott Department of Computer Science University of Rochester Presented by: Armand R. Burks Fall 2008
Classic lock-based implementations of concurrent objects suffer from several important drawbacks: Deadlocks Priority inversion Convoying Lack of fault tolerance
Increased interest in nonblocking synchronization algorithms Failure of a thread can never prevent the system from making forward progress
A concurrent object is a data object shared by multiple threads of control within a concurrent system.
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.
Transaction A finite sequence of instructions (satisfying the linearizability and atomicity properties) that is used to access and modify concurrent objects
This paper focuses on discussing two approaches to STM Compares and evaluates strengths and weaknesses of the approaches
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...
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
Most recent previous transaction may still be ACTIVE Wait/retry, abort, or force competitor to abort Ask contention manager to make decision
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
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
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
When transaction detects conflict with another, it uses the conflicting transaction’s descriptor to make updates, then aborts/restarts itself. Example follows:
B BA COMMITTED A Abort & Restart A Concurrent Object A COMMITTED
Concurrent Object Shadow Copy Object Header Transaction Descriptor UNDECIDED Status Read-only Read-writeObject Handles Object ref Old data New data Next handle Unlike DSTM, multiple transactions can open the same object in write mode because each has its own shadow copy.
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
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
Concurrent Object Shadow Copy Object Header Transaction Descriptor UNDECIDED Status Read-only Read-writeObject Handles Object ref Old data CAS Recursively help competitor
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)
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
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
Simple Benchmarks A stack 3 variants of a list-based set More Complex Benchmark Red-black tree
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
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)
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
FSTM outperformed again Difference remained more or less constant
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)
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
Higher throughput for DSTM FSTM suffers extra bookkeeping overhead, sorting overhead, and extra CASes
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
FSTM more than a factor of 2 better DSTM’s indirection is to blame
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 )
On a memory access violation, exception handler validates the transaction that caused the exception Responsibility of detecting other inconsistencies is left to the programmer
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
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
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
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
Your consent to our cookies if you continue to use this website.