Design Tradeoffs in Modern Software Transactional Memory Systems

1
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

Presented by Armand R. Burks Fall 2008
2
Background info.

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

3
Background info. Contd.

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

4
Definition...

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

5
Outline

• 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
Intro Software Transactional Memory

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

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

9
Purpose of Paper

• 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
Dynamic Software Transactional Memory (DSTM)

• 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
DSTM Contd.
Committed Transaction
Start
Transaction
X
New Object
Old Object
TMObject
Locator
Old Locator
Shared Object-Old Version
Atomic Compare Swap (CAS)
CAS FAILURE
Other transaction has acquired object
Opening a TMObject (in write mode) recently
modified by a committed transaction
13
DSTM Contention

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

14
DSTM- What about read-only?

• 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
DSTM Read-only contd...

• 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
Frasers Software Transactional Memory (FSTM)
17
FSTM

• 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
FSTM Recursive helping

• When transaction detects conflict with another,
  it uses the conflicting transactions descriptor
  to make updates, then aborts/restarts itself.
• Example follows

19
FSTM- Recursive helping contd...
B
A
A
Concurrent Object
Abort Restart
A
COMMITTED
COMMITTED
20
Basic Transactional Memory structure
New data
Next handle
Object ref
Old data
UNDECIDED
Status
Read-only
Read-write
Object Handles
Concurrent Object
Shadow Copy
Unlike DSTM, multiple transactions can open the
same object in write mode because each has its
own shadow copy.
21
FSTM- Transaction states

• UNDECIDED
• ABORTED
• COMMITTED
• READ-CHECKING

22
FSTM- Transaction states contd...

• 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
Commit phase

• 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 headers pointer to
  transaction descriptor
• If pointer already points to another
  transactions descriptor, conflict is detected
• Example follows

24
CAS Conflict discovery
Object ref
Old data
UNDECIDED
Status
Read-only
Read-write
Object Handles
Concurrent Object
Shadow Copy
CAS
Object Header
Recursively help competitor
25
Recursive helping

• 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
REAd-checking state

• 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
Comparative evaluation

• 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
Experimental environment

• 16-processor SunFire 6800
• Cache-coherent multiprocessor
• 1.2 GHz Processors
• Environment Suns Java 1.5 beta 1 HotSpot JVM
• Augmented with JSR166 update from Doug Lea

30
Testing benchmarks

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

31
Testing benchmarks contd...

• 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
Object acquire semantics

• 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
Object acquire semantics

• 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
Object acquire semantics performance results
Red-black Tree Performance Results
35
Object acquire semantics performance results

• FSTM outperforms due to lazy acquire semantics

36
Object acquire semantics performance results
Number of Contention Instances
37
Object acquire semantics performance results

• FSTM outperformed again
• Difference remained more or less constant

38
Bookkeeping and indirection

• 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
Bookkeeping and indirection

• 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
Bookkeeping and indirection Performance

• Testing Benchmarks
• Stack,
• IntSet,
• IntSetRelease

41
Bookkeeping and indirection Performance Results
Stack Performance Results
42
Bookkeeping and indirection Performance Results

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

43
Bookkeeping and indirection intset

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

44
Bookkeeping and indirection Performance Results
IntSet Performance Results
45
Bookkeeping and indirection Performance Results

• Higher throughput for DSTM
• FSTM suffers extra bookkeeping overhead, sorting
  overhead, and extra CASes

46
Bookkeeping and indirection intsetrelease

• 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
Bookkeeping and indirection Performance Results
IntSetRelease Performance Results
48
Bookkeeping and indirection Performance Results

• FSTM more than a factor of 2 better
• DSTMs indirection is to blame

49
Transaction validation

• 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
Transaction validation - fstm

• 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
Transaction validation intsetupgrade

• 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
Transaction validation performance results
IntSetUpgrade Performance Results
53
Transaction validation performance results

• 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
Related Work

• 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
conclusions

• 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

57
Questions? Preguntas?