An Introduction to Software Transactional Memory Alessia Milani Labri, Bordeaux

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

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)

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

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®

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

3 levels of abstractions 77 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

STM algorithms Main Techniques

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.

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.

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)

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;

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

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

STM algorithms Two Case Studies

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

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

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

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

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

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

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

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

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

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

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

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

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

Example: Writing Transaction 100 120 121 100 Mem Locks Shared Version Clock 87 0 121 0 88 0 V# 0 44 0 50 0 87 0 87 0 87 0 87 0 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 121 0 34 1 34 0 34 0 34 0 88 0 Y Y 121 0 99 0 99 0 99 0 99 1 44 0 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. 50 0 50 0 50 0 50 0 V# 0 100 Commit RV

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

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

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

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

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.

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

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

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

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

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.