Software Transactional Memory

1
Software Transactional Memory

• Robert T. Bauer

2
Overview

• Background
• Transactional Memory
• Software Transactional Memory
• Composable Transaction Memory (Haskell)
• RCU vs. STM
• Concluding remarks

3
Background

• What is a transaction?
• Finite sequence of machine instructions executed
  by a single process, satisfying
• Serializability Transaction appear to execute
  serially (steps of one transaction are not
  interleaved with steps of another). Committed
  transactions are observed by all processors in
  the same order.
• Atomicity Each transaction makes a sequence of
  tentative changes to shared memory. Transaction
  ends with either
• Commit changes are (instantly) available to all
  processors
• Abort changes are discarded

4
Transactional Memory (TM)

• Transactional Cache (small fully associative)
• Tentative writes, not propagated, unless commit
• On abort, cache lines are dropped
• Abort, Commit in single cache cycle
• Hardware/Software Interface
• Load_Linked (LL) copies value of shared
  variable to local memory (e.g., ld.acquire)
• Store_Conditional updates value of a shared
  variable only if no other processor modified that
  variable since it was loaded (using LL).

5
Kinds of TM

• Non-blocking
• Some process will complete an operation in a
  finite number of steps
• Wait-free
• Every process will complete an operation in a
  finite number of steps

6
Basic Idea of TM

• Basic Idea of TM
• Read pointer using load_linked
• Copy version into new block and modify copy
• Update pointer using store_conditional
• If store_conditional fails, repeat starting with
  read

7
Non-Blocking Implementation

• However, implementation of TM differs slightly
  from the basic idea they copied the new block
  over the original data.
• A process can observe an object in an
  inconsistent state
• If one process is copying the data while the
  other is updating the data in place, the copying
  process may see an invalid object.
• The store_conditional will fail, but the copying
  process may do something bad first.
• Software consistency check
• Modifying process increments check_0 before
  modifying and increments check_1 after modifying
• Copying process reads check_1 before copying and
  then reads check_0

8
Wait-Free Implementation

• Each process registers its transaction in an
  array
• The array is processed linearly (for i 0 )
• Results of transaction are saved
• A process detects the completion of its
  transaction before registering a new one

9
TM Issues

• Size of LL/SC lock region limits applicability
• On Alpha, max region is size of block
• Large (size greater than lock region size)
  objects require a different approach Herlihy
  offers a block containing pointers.

10
TM Performance

• Can perform better than Test-and-Test-and-Set
• Lies within a factor of two best implementation
  of efficient spin-locks (using exponential
  backoff)
• In general, though, at least an order of
  magnitude worse.
• Adding hardware support (Transactional Cache)
  dramatically improves performance.

11
TM References

• Herlihy, M. A Methodology for Implementing
  Highly Concurrent Data Objects, ACM Trans. on
  Programming Languages and Systems, 15(9)
  745-770, November 1993.
• Herlihy, M. and Moss, J., Transactional Memory
  Architectural Support for Lock-Fee Data
  Structures, 20th Annual Symposium on Computer
  Architecture, pages 289-300, May 1993.

12
Software Transactional Memory

• Based on implementing a k-word compare/swap using
  LL/SC instructions
• Transactions access a pre-determined sequence of
  locations (static transaction)

13
Implementation
Address Array
Old Values
Memory
LL(old) SC(old, mem)
j
i
j
LL(mem) SC(mem, new)
new F(old)
Ownership
LL( j ) SC( j ,trans)
New Values
j
transaction data
TCB
14
STM Performance

• STM shows relatively constant performance as the
  of processors increase.
• Resource allocation test a few processes share
  a set of resources and from time to time a
  process tries to atomically allocate a subset of
  those resources -- STM very good at this
  benchmark.
• STM is generally worse than TM therefore worse
  than efficient lock-based implementations.

15
Not Obstruction Free STM

• Previous STM versions didnt use locks because
  they wanted to guarantee progress
• What if we use locks on non-distributed systems?
• Revocable two-phase lock for writes lock all
  objects that it writes, dont release lock until
  transaction terminates. Deadlock detection then
  abort and transaction restart.
• Optimistic concurrency control for reads reads
  log versions read when transaction commits, it
  verifies that these are still the current
  versions of the objects.

16
STM References

• N. Shavit and D. Touitou, Software Transactional
  Memory, 1995.
• R. Ennals, Software Transactional Memory Should
  Not Be Obstruction-Free, 2005

17
Composable Memory Transactions

• Concurrent Haskell implementation of STM
• Uniprocessor, not multiprocessor
• Haskell threads suspended at safe points
• Thread-local transaction log on heap tracks reads
  and writes
• Commits check that the read variables havent
  changed and then updates the heap in place

18
Haskell Implementation
Tentative value value to be written on commit
Tvar
Transaction Log
Old value value read when first accessed
19
Haskell Examples
// wait for multiple resource getR r i do v
lt- readTVar r if (v lt i
) then retry else
writeTVar r (v i) // get 2 units of one
resource, and 3 of another // more general than
and semantics atomic (do getR r1 2 getR r2
3) f x if x 0 then true else f(x-1) foo
atomic ( do x lt- readTVar v
y lt- readTVar v if f
(x y) then else)
20
Composable Memory Transactions References

• T. Harris, S. Marlow, S.P. Jones, and Maurice
  Herlihy, Composable Memory Transactions, PPoPP
  05, June 15-17, 2005.

21
RCU vs. STM

• RCU basic idea to modify a copy of the data and
  then update a global pointer. Then, RCU must
  free the original data.
• STM does the update in place.
• Implementing RCU as a transaction is trivial, but
  it wont be RCU it will just be a transaction.
• STM can be implemented using RCU
• RCU is fast. STM is slow. STM performance is
  improving.

22
Concludng Remarks

• Haskell Paper really went towards pragmatics
• Procedural Perspective
• ..
• ..
• Begin Transaction
• ..
• ..
• if() then Commit() Else Abort()
• End Transaction
• Contributions from Formal Methods community are
  needed