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

2. 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 The problem

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 T1T2T3 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 T1T2T3 Shared memory

8. Conflicting Transactions: Example Bestseller book Buy

9. Serializability Client 1Client 2 read b read b write bwrite 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 bwrite 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