1. An Introduction to Software Transactional Memory
Alessia Milani
Labri, Bordeaux

2. Popularizing Concurrent Programming
A multi-core revolution is underway
Exploit the power of concurrent computing, by restructuring applications
Devise scalable concurrent programs is hard…unless good abstractions :
Transaction

3. Transaction
A transaction is a sequence of operations by a single process on a set of shared data items (transactional objects) that ends
Either by committing : all of its updates take effect atomically
or by aborting : has no effect (typically restarted)

4. Transactional Memory (TM)
To simplify : Just wrap (sequential) code in begin / end transaction
TM synchronizes memory accesses so that each transaction seems to execute sequentially and in isolation
begin-transaction
end-transaction

5. Implementing Transactional Memory
TM was originally suggested as hardware platform [Herlihy and Moss 1993]
HTM is in today hardware platforms, e.g. Intel, IBM, Sun
Purely in software :
First Software Transactional Memory (STM) only for static transactions [Shavit & Touitou 1995]
First dynamic STM [Herlihy, Luchnagco, Moir and Schrer 2003]
Hybrid schemes (HyTM) that combine hardware and software [Moir et al. 2006]
The data set of a transaction
“bounded” and “best-effort” hardware TM proposals
impose unreasonable constraints on programmers, while more flexible software TM implementations are considered too slow.
Software is more flexible than hardware
and permits the implementation of a wider variety of more sophisticated algorithms.
Software is easier to modify and evolve than hardware
HTM vs
STM •
HTM systems can typically execute applications with lower
overheads than STM systems.
Less reliant than STM systems on compiler optimizations to achieve performance.
Herlihy and Moss [11] introduced
hard-
ware transactional memory
(HTM) and showed that bounded-size
atomic transactions that are short enough to be completed with-
out context switching could be supported using simple additions
to the cache mechanisms of existing processors.
IBM Blue Gene® and IBM z/OS®, then recently with IBM AIX® support of hardware transactional memory on the POWER8™ platform.
Intel® Transactional Synchronization Extensions (TSX) for the future multicore processor code-named “Haswell”
IBM Blue Gene® and IBM z/OS®, then recently with IBM AIX®

6. Implementing Transactional Memory in Software (STM)
Data representation for transactions and data items using base objects
Algorithms for operations on data items, applying primitives to base objects
registers, CAS, DCAS
Asynchronous processes execute these algorithms to execute the operations of the transactions
begin-transaction
read
base objects
read
Algorithms …
write
TryCommit
end-transaction
Lead to interleaved executions, in the standard sense
cas(o,exp,new) (compare&swap) writes the value new to base object o if its value is equal to exp, and returns a success or failure indication
Software transactional memory allows composing transactions, no changes in hw

7. 3 levels of abstractions77
3 levels of abstractions
Transaction
Operations
on data items: E.g., read and write
tryCommit / tryAbort
Primitives on base objects (registers, CAS…)
read
write
tryC

8. STM algorithms
Main Techniques

9. Back to TM Consistency
Serializability: committed transactions appear to execute sequentially
begin-Tx
read
write
TryC
Commit
Opacity improves serializability stating that the transaction itself should operate on a consistent state.
Definition of snapshot isolation
Read operations in a transaction return the value at transaction start
Write sets of concurrent transactions are disjoint.

10. strict serializability
Back to TM Consistency
Serializability: committed transactions appear to execute sequentially
Strict serializability: also preserves the order of non-overlapping transactions [Papadimitriou 1979]
Opacity: even transactions that later abort are (strictly) serializable [Guerraoui, Kapalka POPL 2008]
Much more …
serializability
strict serializability
opacity
Opacity improves serializability stating that the transaction itself should operate on a consistent state.
Definition of snapshot isolation
Read operations in a transaction return the value at transaction start
Write sets of concurrent transactions are disjoint.

11. Conflicts
begin-Tx
Commit
begin-Tx
Commit p1
Read(x)0
Write(x)1 p1
Read(x)0
Write(y)1
begin-Tx
Commit
begin-Tx
Commit p2
Read(x)0
Write(x)2 p2
Read(y)0
Write(x)1
Two concurrent transactions have a conflict if they access the same data item and at least one of these accesses is a Write operation.
Two transactions that cannot be serialized have a conflict. (The converse is not true)

12. Design approaches
Deferred/Direct updates : operate on local copies of the data items & install changes at commit/ Modify in place, roll back on abort
Detect conflicts
Commit time
Encountering time
Resolve a conflict either by aborting one of the conflicting transactions or by waiting/helping it to complete
This depends on the progress you want
Contention manager
A natural way to let read-only transaction to complete is to associate a read counter with each data item, tracking the number of pending transactions reading from the data item. Transactions that write to the data items respect the read counters;

13. Contention Manager Strategies
Priority to
Oldest?
Most work? …
None Dominates
Lots of empirical work but formal work in infancy

14. Progress for TM Lock-free TM Lock-Based TM
Wait-freedom : each non-faulty process completes (successfully) its transaction within a finite number of steps
Obstruction-freedom : a process running solo eventually commits its transaction
Lock-Based TM
Weakly progressive: a transaction aborts only if it has conflicts [Guerraoui, Kapalka POPL 2009]
Strongly progressive: at least one of the transactions involved in the conflict commits
Multi-version permissive: only writing transaction that conflicts with another writing transaction aborts [Perelman, Fan, Keidar PODC 2010]
Read-only transactions always commit
Minimally progressive: a transaction commits if it runs alone, with no pending transactions

15. STM algorithms
Two Case Studies

16. A lock-based STM : TL2 [Dice et al. DISC 2006]
Each data item is associated with a version number
TL2 relies on a global versioning clock
Transaction keeps
Read set: data items & values read
Write set: data items & values to be written
Deferred update
Changes installed at commit
Lazy conflict detection
Conflicts detected at commit
Read set read memory address
Write set address and values to be written

17. Read-Only Transactions
Mem
Locks
Copy version clock to local read version clock RV 12 32 56
100
Shared Version Clock
100
Associate a versioned write lock with every transactional (object) memory location. One bit is used to say that the lock is taken, the rest is used for a version number.
Each lock is a CAS where the CAS operation is used to acquire the lock and a store to release it 19 17
Private Read Version (RV) 17

18. Read-Only Transactions
Mem
Locks
Copy version clock to local read version clock 12
Each read operation is post-validated checking the lock and version # of the corresponding memory location 32 56
100
Shared Version Clock
100
Post validate : The lock should be free and the lock’s version field should be less or equal to the value in RV 19 17
Private Read Version (RV) 18 18

19. Read-Only Transactions
Mem
Locks
Copy version clock to local read version clock 12
Read lock, version #, and memory, check version # less than read clock 32
COMMIT if no post-validation fails. Otherwise ABORT as soon as one Read fails 56
100
Shared Version Clock
100
Souligner que les lectures sont invisibles 19 17
Private Read Version (RV) 19 19

20. Read-Only Transactions
Mem
Locks 12 32
We have taken a snapshot without keeping an explicit read set! 56
100
Shared Version Clock
100 19 17
Private Read Version (RV) 20 20

21. Example Execution: Read Only Trans
Mem Locks
100
Shared Version Clock V#
RV  Shared Version Clock
On Read: read lock, read mem, read lock: check unlocked, unchanged, and v# <= RV
Commit. V#
Reads form a snapshot of memory.
No read set! V#
100 RV

22. Writing Transactions Copy version clock to local read version clock RV
Mem
Locks
Copy version clock to local read version clock RV 12 32 56
100
Shared Version Clock
100 19 17
Private Read Version (RV) 22 22

23. Writing Transactions Copy version clock to local read version clock
Mem
Locks
Copy version clock to local read version clock 12
On read/write, check:
Unlocked & version # < RV
Add to R/W set 32 56
100
Shared Version Clock
100
Each read operation first check if the data item we are going to read is in the write set. If so, take the value of the write set. This avoids read-after-write hazards.
If the postvalidation fails the transaction is aborted 19 17
Private Read Version (RV) 23 23

24. Private Read Version (RV)
On Commit
Mem
Locks
Acquire write locks 12 32 56 19
100
100 17
Private Read Version (RV)
Shared Version Clock 24

25. On Commit Acquire write locks Increment Version Clock Mem Locks 10112
Increment Version Clock 32 56 19
100
101
100 17
Private Read Version (RV)
Shared Version Clock
Art of Multiprocessor Programming 25 25

26. On Commit Acquire write locks Increment Version Clock
Mem
Locks
Acquire write locks 12
Increment Version Clock
Check version numbers ≤ RV 32 56 19
101
100
100 17
Private Read Version (RV)
Shared Version Clock
Art of Multiprocessor Programming 26 26

27. On Commit x y Acquire write locks Increment Version Clock
Mem
Locks
Acquire write locks 12
Increment Version Clock
Check version numbers ≤ RV x 32
Update memory 56 19
100
101
100 y 17
Private Read Version (RV)
Shared Version Clock 27 27

28. On Commit x y Acquire write locks Increment Version Clock
Mem
Locks
Acquire write locks 12
Increment Version Clock
Check version numbers ≤ RV x
101 32
Update memory
Update write version #s 56 19
100
101
100 y
101 17
Private Read Version (RV)
Shared Version Clock 28 28

29. Example: Writing Transaction
100
120
121
100
Mem Locks
Shared Version Clock V#
RV  Shared Version Clock
On Read/Write: check unlocked and v# <= RV then add to Read/Write-Set
Acquire Locks
WV = F&I(VClock)
Validate each v# <= RV
Release locks with v#  WV X X Y Y
We maintain thread lo- cal read- and write-sets as linked lists. Each read-set entries contains the address of the lock that “covers” the variable being read, and unlike former algorithms, does not need to contain the observed version number of the lock. The write-set entries contain the address of the variable, the value to be written to the vari- able, and the address of its associated lock. In many cases the lock and location address are related and so we need to keep only one of them in the read-set. The write-set is kept in chronological order to avoid write-after-write hazards. V#
100
Commit RV

30. A lock-free STM : Dynamic Software Transactional Memory
Proposed in [Herlihy et al. DISC 2003]
Opacity & obstruction freedom
Transaction keeps
Read set: data items & values read
Direct update
Changes installed when the corresponding Write is executed
Eager conflict detection
Conflicts detected at encountering time

31. DSTM : transaction and transactional object representation
A transaction has
a status field that is initialized to be ACTIVE, and it is later COMMITED or ABORTED using a CAS primitive
a readlist to store the data items read together with the values read
Each transactional object has the following structure
Status of the transaction that most recently accessed the object to write it
start
TMObject
transaction
new object
old object
status
Data
Locator
Start is a CAS object. CAS(a,e,n) takes three parameters : an address a, an expected value e and a new value n. If the value currently stored at address a matches the expected value e, then CAS store the new value n at address a and returns true, otherwise it returns false

32. Current object version
The current object version is determined by the status of the transaction that most recently accessed the object to WRITE :
committed: the new object is the current
aborted: the old object is the current
active: the old object is the current, and the new is tentative
The actual version only changes when a commit is successful

33. Write operation : example
Transaction A tries to write object o. Let B be the transaction that most recently accessed o to WRITE it
committed
transaction
Data
new object
start
old object o
Data
B’s Locator
copy 4
Use CAS in order to replace locator
transaction
active
new object
If the status of B is aborted, the old object is the current one. So we repeat the scenario but we consider the old object data.
Data
If CAS fails, A restarts from the beginning
old object
A’s Locator 1 3
A sets old object to the previous new
A creates a new Locator 2
A copies the previous new object, and sets new

34. Which is the current version of the object if B is active?
A and B are conflicting transactions, that run at the same time
Use Contention Manager to decide which should continue and which should abort
If B needs to abort, try to change its status to aborted (using CAS)
To guarantee obstruction freedom a transaction that requests to abort another transaction to abort several times, is eventually granted.

35. Read operation To read object o by a transaction A
Fetch the current version v just as before
Add the pair (o, v) to the read set of A

36. Validating a transaction
Before returning the value either read or written, check consistency
For each pair (o,v) in the read set, verify that v is still the most recently committed version of the transactional object o.
Check that the status of the transaction is still ACTIVE

37. Committing a transaction
The commit needs to do the following:
Validate the transaction
Change the transaction’s status from active to committed (using CAS)

38. That’s it? You are here Elastic Txs Multiversioning Irrevocable
transactions
Privatization
Nested
transactions
Distributed STM
Lower bounds

39. More references and credits
Many of these slides are (largely inspired) from
The slides of “The Art of Multiprocessor Programming” by Maurice Herlihy and Nir Shavit
A PODC 2010 talk by Hagit Attiya
Teaching slides by Danny Hendler
Other reference :
Transactional Memory,Foundations, Algorithms, Tools, and Applications. COST Action Euro-TM IC1001. Lecture Notes in Computer Science, Springer 2014.