bool Account::withdraw(int val) { atomic { if(balance > val) { balance = balance val; return true; } else return false; } }

Transcription

1 Transac'onal Memory Acknowledgement: Slides in part adopted from: 1. a talk on Intel TSX from Intel Developer's Forum in the companion slides for the book "The Art of Mul'processor Programming" by Maurice Herlihy and Nir Shavit

2 Transac'onal Memory A high- level programming construct for op'mis'c concurrency control. The programmer denotes the cri'cal sec'on, and the underlying TM system ensure that the cri'cal sec'on executes atomically. bool Account::withdraw(int val) { atomic { if(balance > val) { balance = balance val; return true; } else return false; } }

3 Transac'onal Memory The execu'on of an atomic block cons'tutes a transac'on. The idea of transac'on came from the DB world [1]. The underlying system ensures atomicity and isola,on of concurrently execu'ng transac'ons. Atomicity: program state changes performed by a transac'on are indivisible from the perspec've of other transac'ons. Isola.on: a transac'on appears to execute serially one at a 'me (i.e., other concurrently execu'ng transac'ons do not affect its its result). Make lock- free synchroniza'on efficient and easy. First hardware TM design proposed by Herlihy and Moss (1993) [2].

4 Advantages of Transac'onal Memory Avoid common pizalls of locks: priority inversion convoying deadlock Provides be[er composability Poten'ally allows higher concurrency.

5 TM Provides Be[er Composability Example: Implement transfers between accounts void transfer(account *from, Account *to, int amount) { if( from->withdraw(amount) ) { to->deposit(amount); } }

6 TM Provides Be[er Composability Example: Implement transfers between accounts Lock *global = new Lock(); void transfer(account *from, Account *to, int amount) { global->lock(); } if( from->withdraw(amount) ) { } to->deposit(amount); global->unlock(); Global lock limits concurrency.

7 TM Provides Be[er Composability Example: Implement transfers between accounts void transfer(account *from, Account *to, int amount) { from->lock(); to->lock(); } if( from->withdraw(amount) ) { } to->deposit(amount); to->unlock(); from->unlock(); Fine- grained locking breaks abstrac'on. And, the code may deadlock.

8 TM Provides Be[er Composability Example: Implement transfers between accounts void transfer(account *from, Account *to, int amount) { atomic { } } if( from->withdraw(amount) ) { } to->deposit(amount); to->unlock(); from->unlock(); Transac'onal interface allows the two method calls to execute atomically without these issues.

9 TM Poten'ally Allows Higher Concurrency Example: concurrent search and insert in a chained hash table Example: concurrent search and insert in a balanced binary search tree

10 How Does TM Work? Each transac'on maintains a read set and a write set. Two transac'ons conflict when they access the same memory loca'on in a conflic'ng way (i.e., at least one is a write). The underlying TM system performs conflict detec'on during execu'on, and a transac'on commits if it executes to comple'on without a conflict; otherwise, it aborts.

11 Implementa'on Alterna'ves Hardware transac'onal memory: Intel s Haswell TSX IBM s Blue Gene/Q & System Z & Power8 Soiware transac'onal memory Hybrid transac'onal memory

12 Different Implementa'on Strategies Deferred update vs Direct Update system Direct update: keep old values off to the side Deferred update: keep new values off to the side Early vs lazy conflict detec'on Early conflict detec'on: detect conflict as soon as it occurs Lazy conflict detec'on: detect conflict when transac'on is about to complete

13 Lecture Today TSX features in Intel Haswell TLS2 (an implementa'on of STM) Limita'ons / Open Issues of TM

14 Architectural Support for HTM The L1 Data cache serves as a write buffer writes within a transac'on is not visible to others un'l commit. Each cache line has addi'onal bits*: RS: the cache line is brought in for a transac'onal load WS: the cache line is brought in for a transac'onal store Piggyback on the underlying cache coherence protocol for conflict detec'on (so granularity is at cache line level) Abort and commit are local to the L1 cache: Upon a conflict, abort the transac'on: invalidate dirty transac'onal and revert back the register state. When transac'on completes, commit if no conflict occurred: clear the RS and WS bits (the cache coherence takes care of the rest). Deferred update and Eager conflict detec'on Best effort HTM * This is just a guess; Intel did not reveal the architectural details of how TM is supported but should be similar to architectural support proposed by Herlihy and Moss [2].

15 Intel Transac'onal Synchroniza'on Extension (TSX) Hardware Lock Elision (HLE) XACQUIRE/XRELEASE Soiware uses legacy compa'ble hints to iden'fy cri'cal sec'on. Hints ignored on hardware without TSX Hardware support to execute transac'onally without acquiring lock Abort causes a re- execu'on without elision Hardware manages all architectural state Restricted Transac'onal Memory (RTM) XBEGIN/XEND Soiware uses new instruc'ons to specify cri'cal sec'ons Cri'cal sec'on executes transac'onally Abort transfers control to target specified by XBEGIN operand Abort informa'on returned in a general purpose register (EAX) Addi'onal instruc'ons: XTEST and XABORT slides from

16 Hardware Lock Elision HLE is backward compa'ble and allows locking code to execute transac'onally on hardware that supports TM. slides from

17 Intel TSX Interface: HLE mov eax, 1 Try: lock xchg mutex, eax cmp eax, 0 jz Success Spin: pause cmp mutex, 1 jz Spin jmp Try mov eax, 1 Try: xacquire lock xchg mutex, eax cmp eax, 0 jz Success Spin: pause cmp mutex, 1 jz Spin jmp Try Library Application acquire_lock (mutex) ; do critical section ; function calls, ; memory operations, release_lock (mutex) Enter HLE execution If lock not free, execution will abort either early (if pause used) or when lock gets free Commit HLE execution mov mutex, 0 xrelease mov mutex, 0 slides from

18 Hardware Lock Elision Identify and Elide: HLE xacquire lock cmpxchg mutex, ebx mutex: 0 Hardware executes XACQUIRE hint Hardware elides acquire write to mutex Hardware starts transactional execution mov ecx, mutex mutex: 1 Reading mutex in critical section sees last value written (1) Other threads reading see free value (0) mutex value self others 0 0 xrelease mov mutex, 0 Hardware executes XRELEASE hint Hardware elides release write to mutex Hardware commits transactional execution mutex: 1 mutex: slides from

19 Hardware Lock Elision Hardware support to elide multiple locks Hardware elision buffer manages actively elided locks XACQUIRE/XRELEASE allocate/free elision buffer entries Skips elision without aborting if no free entry available Hardware treats XACQUIRE/XRELEASE as hints Functionally correct even if hints used improperly Hardware checks if locks meet requirements for elision May expose latent bugs and incorrect timing assumptions slides from

20 Intel TSX Interface: RTM Retry: xbegin Abort cmp mutex, 0 jz Success xabort $0xff Abort: check EAX and do retry policy actually acquire lock or wait to retry. Enter RTM execution, Abort is fallback path Check to see if mutex is free Abort transactional execution if mutex busy Fallback path in software Retry RTM or explicitly acquire mutex acquire_lock (mutex) ; do critical section ; function calls, ; memory operations, release_lock (mutex) cmp mutex, 0 jnz release_lock xend Mutex not free was not an RTM execution Commit RTM execution slides from

21 Intel TSX Interface: RTM Intel TSX Interface: RTM Retry: xbegin Abort cmp mutex, 0 jz Success xabort $0xff Abort: check EAX and do retry policy actually acquire lock or wait to retry. Try: mov eax, 1 lock xchg mutex, eax cmp eax, 0 jz Success Spin: pause cmp mutex, 1 jz Spin jmp Try acquire_lock (mutex) acquire_lock (mutex) ; do critical section ; function calls, ; memory operations, release_lock (mutex) cmp mutex, 0 jnz release_lock xend mov mutex, 0 release_lock (mutex) slides from

22 Haswell: Best Effort HTM Transac'onal execu'on can abort due to: data conflicts cache overflow cache evic'on of a transac'onal write (ran out of associa'vity) system ac'vity: context switch, interrupt, page fault use of special instruc'on (e.g. pause, cpuid) transac'on nes'ng depth exceeds maximum limit A bug was discovered in TSX (2014), so Intel issued a soiware "microcode update" to turn TSX off rather than fixing it.

23 A Simple Lock- Based STM STMs come in different forms Lock- based Lock- free First, a simple lock- based STM: Deferred update: changes installed at commit Lazy conflict detec'on: conflicts detected at commit

24 STM: Transac'onal Locking [3] Map Application Memory V# V# V# Array of version #s & locks companion slides from the Art Mul'processor Programming

25 Commit Time Locking (Write Buff) Mem X Y Locks V# 0 V# 0 V#+1 0 V#+1 10 V# 0 V# 0 V#+1 0 V# V# 0 V# 0 V# 0 V# 0 Read In write set? unlocked? add value to read set Write add value to write set, Validate acquire locks check version #s unchanged install changes, increment vesion #s, unlock companion slides from the Art Mul'processor Programming

26 Commit Time Locking (Write Buff) Mem Locks X Y V# 0 V# 0 V#+1 0 V#+1 10 V# 0 V# 0 V#+1 0 V# V# 0 V# 0 V# 0 V# 0 1. To Read: load lock + location 2. Location in write-set? (Bloom Filter) 3. Check unlocked add to Read-Set 4. To Write: add value to write set 5. Acquire Locks 6. Validate read/write v# s unchanged 7. Release each lock with v#+1 Hold locks for very short duration companion slides from the Art Mul'processor Programming

27 Problem: Internal Inconsistency A Zombie is an ac've transac'on des'ned to abort. If Zombies see inconsistent states bad things can happen companion slides from the Art Mul'processor Programming

28 Internal Consistency x y Invariant: x = 2y Transaction A: reads x = 4 Transaction B: writes 8 to x, 16 to y, aborts A ) Transaction A: (zombie) reads y = 4 computes 1/(x-y) Divide by zero FAIL! companion slides from the Art Mul'processor Programming

29 Solu'on: The Global Clock The TL2 Algorithm [4] Have one shared global clock Incremented by (small subset of) wri'ng transac'ons Read by all transac'ons Used to validate that state worked on is always consistent companion slides from the Art Mul'processor Programming

30 Example Mem Locks Shared Version Clock X X Y Y V# V# V# RV ß Shared Version Clock 2. On Read/Write: check unlocked and v# <= RV then add to Read/Write-Set 3. Acquire Locks 4. WV = F&I(VClock) 5. Validate each v# <= RV 6. Release locks with v# ß WV Commit 100 RV Reads+Inc+Writes =serializable companion slides from the Art Mul'processor Programming

31 Open Issues of TM Lack of performance model: Difficult to guarantee forward progress Conten'on management is s'll an ac've research area Irrevocable ac'ons within a transac'on Seman'c Issues: interac'ons with excep'ons nested transac'ons strong atomicity versus weak atomicity does not support certain synchroniza'on pa[erns

32 References [1] Lomet, D.B. Process structuring, synchroniza'on, and recovery using atomic ac'ons. In Proceedings of the ACM Conference on Language Design for Reliable So:ware (Raleigh, NC, 1977). ACM, NY, [2] Herlihy, M. and Moss, J.E.B. Transac'onal memory: Architectural support for lock- free data structures. In Proceedings of the 20th Interna?onal Symposium on Computer Architecture. ACM, 1993, [3] Dice, D., Shavit, N., What really makes transac'ons fast? In: TRANSACT06 ACM Workshop. (2006) [4] Dice D., Shavit, O., and Shavit, N., Transac'onal locking II. In Proceedings of the 20 th interna'onal conference on Distributed Compu'ng (DISC'06). Shlomi Dolev (Ed.). Springer- Verlag, Berlin, Heidelberg, 2006,