Transactional Memory: Architectural Support for Lock-Free Data Structures Maurice Herlihy and J. Eliot B. Moss ISCA 93

Transcription

1 Transactional Memory: Architectural Support for Lock-Free Data Structures Maurice Herlihy and J. Eliot B. Moss ISCA 93

2 What are lock-free data structures A shared data structure is lock-free if its operations do not require mutual exclusion.

3 Motivation Conventional locking has quite a few problems. Priority Inversion Convoying Deadlocks

4 A plausible solution? Transactional memory - intended to make lock-free synchronization easy and efficient. Can define customized read-modify-write operations that apply to multiple words.

5 Characteristics Serializability - Transactions appear to execute serially. Atomicity - All or nothing, i.e, when a transaction completes either all the changes are written to memory or none.

6 Instruction Interface Load-transactional (LT) :- read value from shared memory. Load-transactional-exclusive (LTX) :- LT + hinting that the location is likely to be updated. Store-transactional (ST) :- tentatively writes a value to shared memory.

7 Read-set and write-set Read-set :- The set of all locations read by LT. Write-set :- The set of all locations accessed by LTX and ST.

8 Instruction Interface - contd. Commit (COMMIT) :- attempt to make the tentative changes permanent. Abort (ABORT) :- discard all tentative changes. Validate (VALIDATE) :- tests the current transaction status.

9 Intended Use 1. use LT or LTX to read from a set of locations. 2. use VALIDATE to check that the values read are consistent. 3. use ST to modify a set of locations. 4. use COMMIT to make the changes permanent. 5. If either VALIDATE or COMMIT fails branch to (1), i.e re-try.

10 Implementation - Design criteria Non-transactional operations use the same cache and coherence protocols as before. Custom hardware support is restricted to primary caches only. Committing or aborting a transaction is an operation local to the cache.

11 Implementation - Idea Implemented by modifying standard multiprocessor cache coherence protocols. Conflict is detected when one transaction tries to revoke access of an entry in another active transaction. What happens after a conflict is detected can be handled in various ways and is up to the implementation.

12 Implementation 2 primary exclusive caches Regular cache for non-transactional operations. Transactional cache for transactional operations. Transactional cache holds all the tentative writes When the transaction commits these are made available. When it aborts, they are invalidated.

13 Cache line states and transactional tags

14 Bus Cycles T_READ and T_RFO request transactional cache lines. Transactional requests can be refused with a BUSY response.

15 Transactional Flags TACTIVE - Indicates whether a transaction is in progress. TSTATUS - Indicates whether a transaction is active or aborted.

16 Putting it all together - LT Probe for an XABORT entry and return its value if there is one. If there is a NORMAL entry, change it to XABORT and allocate another XCOMMIT entry with the same data.

17 Putting it all together - LT If no XABORT or NORMAL entry then issue T_READ cycle. If successful, set up two entries - on tagged XCOMMIT and the other XABORT. If BUSY, abort the transaction.

18 Putting it all together - LTX, ST LTX is same as LT, except that a T_RFO cycle is issued instead of a T_READ. Cache line is changed to RESERVED state. ST is the same as LTX, except that it updates XABORT entry s data.

19 Putting it all together - COMMIT Sets all XCOMMIT entries to EMPTY and XABORT entries to NORMAL. Returns TSTATUS flag and sets TACTIVE to false and TSTATUS to true.

20 Putting it all together - ABORT Sets all XCOMMIT entries to NORMAL and XABORT entries to EMPTY. Sets TACTIVE to false and TSTATUS to true.

21 Putting it all together - VALIDATE Returns the TSTATUS flag. If it is false sets TACTIVE to false and TSTATUS to true.

22 Simulations Used the Proteus simulator and augmented it with Transactional memory support. Each access to the regular and transactional cache takes a single cycle. Both caches are write-back caches; the regular cache is a direct mapped cache and the transactional cache is full associative.

23 Evaluation Was compared against 4 synchronization mechanisms. Software :- test-and-test-and-set spinlocks, software queuing. Hardware :- LL/SC, hardware queuing.

24 Counting Benchmark Each of the n processes increments a shared counter (2^16)/n times. Transactions and critical sections are short. Contention is high.

25 Counting Benchmark Results

26 Producer/Consumer benchmark Each of the n processes share a bounded FIFO buffer, initially empty. Half of the processes produce and half consume. Total of 2^16 operations.

27 Producer/Consumer Results

28 Doubly-Linked List benchmark Each of the n processes dequeues at the tail and enqueues at the head. A total of 2^16 operations are performed. This has potential concurrency that is is hard to exploit by conventional means.

29 Doubly-Linked List results

30 Limitations and conclusion The implementation relies on the assumption that transactions are small. The implementation does not guarantee forward progress. Transactional memory is an optimistic mechanism that can provide performance of fine grain locking on coarse grain transactions.