1. 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

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

3.  Increased interest in nonblocking synchronization algorithms  Failure of a thread can never prevent the system from making forward progress

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

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

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.

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

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

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...

12. 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

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

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

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

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

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

19. B BA COMMITTED A Abort & Restart A Concurrent Object A COMMITTED

20. 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.

21.  UNDECIDED  ABORTED  COMMITTED  READ-CHECKING

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

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

24. Concurrent Object Shadow Copy Object Header Transaction Descriptor UNDECIDED Status Read-only Read-writeObject Handles Object ref Old data CAS 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)

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

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

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

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

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

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)

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

34. Red-black Tree Performance Results

35.  FSTM outperforms due to lazy acquire semantics

36. Number of Contention Instances

37.  FSTM outperformed again  Difference remained more or less constant

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)

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

40.  Testing Benchmarks  Stack,  IntSet,  IntSetRelease

41. Stack Performance Results

42.  Stack illustrates very high contention ( top-of-stack pointer )  DSTM outperformance  Due to FSTM extra bookkeeping in write mode

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

44. IntSet Performance Results

45.  Higher throughput for DSTM  FSTM suffers extra bookkeeping overhead, sorting overhead, and extra CASes

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

47. IntSetRelease Performance Results

48.  FSTM more than a factor of 2 better  DSTM’s indirection is to blame

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 )

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

51.  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

52. IntSetUpgrade Performance Results

53.  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

54. Related Work & Conclusions

55.  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

56.  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