Exploring Transactions and Transactional Memory in Parallel Programming

1. ECE 1747: Parallel Programming Short Introduction to Transactions and Transactional Memory (a.k.a. Speculative Synchronization)

2. The problem • Writing correct high-performance software is difficult • Lock-based critical sections source of difficulty • Limit performance and scalability • Fine-grained locking is difficult and error-prone

3. The questions • Can we use speculation to • Achieve high-performance? • Eliminate unnecessary serialization • Eliminate locking overhead completely • Do so transparently • Make it easier to write correct and reliable code? • Write lock-free programs

4. Trends • Hardware – more hardware threads • More user-visible hardware parallelism • Major implications for software developers • Software – more complexity • Richer functionality • Reliability increasingly important • Writing correct high-performance & stable code is hard

5. Managing complexity with transactions • Transactions: a way to manage complexity of coordinating access to shared objects

6. Managing complexity with transactions • Transactions • Fundamental in concurrent systems • Atomic sequence of reads, writes and computation T1 T2 T3 Shared memory

7. Managing complexity with transactions • Two formal properties of transactions • Serializability • appear as if one-at-a-time • precise order not fixed a priori • Failure atomicity  all-or-nothing T1 T2 T3 Shared memory

8. Bestseller book Conflicting Transactions: Example Buy Buy

9. Serializability Client 1Client 2 read b read b write b write b either client 1 buys the book or client 2 buys the book

10. ACID: Atomicity Client 1 read b write b Either: client buys the book (commit) – book stock is decremented and his credit card charged or he fails to buy it (abort) - no effects

11. ACID: Consistency Client 1 read b write b A transaction always leaves the database in a consistent state whether it is successful or not

12. ACID: Isolation Client 1Client 2 read b read b write b write b No interleaving of operations of Client 1 and Client 2: each transaction’s execution proceeds as if it were executing alone on the system

13. ACID: Durability Client 1 read b write b If a transaction is successful (committed), then effects are persistent

14. Processor support for transactions today • Processors have very restricted transaction support • Single word (compare&swap, load-linked/store-conditional) • Used to implement locks, fetch&add

15. Processor support for transactions today Critical sections provide some transactional functionality • One thread at-a-time operation on shared object • Trivially satisfy serializability • No failure-atomicity • Commonly implemented using locks Critical sections are popular

16. Critical section limitations • Lock acquisitions limit performance & scalability • Serialization • Memory/network traffic • Long latency access • Using fine-grain locks is difficult & error-prone • Interact poorly with thread scheduling & failures

17. Addressing limitations of critical • Use speculation to eliminate unnecessary serialization • Critical sections treated as lock-free transactions • Critical sections executed/committed without lock acquires • If no conflicts, locks never acquired or written to! • If conflicts, acquire lock as underlying scheme

18. Work in this Area • Seminal work by Rajwar and Goodman on speculating that a synch operation itself is unnecessary • Speculative Lock Elision (SLE), MICRO 2001 • Transactional Lock Removal (TLR), ASPLOS 2002 • Thread-level speculation (Martinez and Torrellas, Steffan et al.) • Transactional Memory: Moir et al.

19. Advantages • High performance in the absence of conflicts (SLE) and in the presence of conflicts (TLR) • Concurrency automatically extracted from program • (Still) correct programs