1. Concurrent programming for dummies (and smart people too) Tim Harris & Keir Fraser

2. Example: hashtable Hashtable object Array of buckets Chains of key,value pairs  Where should the locking be done?

3. 17 13 115 3 27 { int result; if (!this.full) wait(); result = this.val; this.full = false; notify(); return result; } { if (this.full) wait(); this.full = true; this.val = val; notify(); } Example: single-cell buffer void put(int val)int get()  Methods should be marked as synchronized  ‘ wait() ’ can wake up spuriously so must be in a loop  ‘ notifyAll() ’ should be used in place of ‘ notify() ’ for liveness

4. Conditional critical regions in Java void put(int val) { atomic (!this.full) { this.full = true; this.val = val; } int get() { int result; atomic (this.full) { this.full = false; return this.val; }  Basic syntax: ‘ atomic (cond) { statements; } ’  Execute the statements exactly once…  …starting in a state where the condition is true  The statements can access fields & local variables, invoke methods, instantiate objects etc.

5. Implementation overview Source code Bytecode + extended attributes Software transactional memory operations Machine code instructions

6. Implementation overview (ii)  Native STM interface:  Transaction management  void STMStartTransaction(void)  boolean STMCommitTransaction(void)  void STMAbortTransaction(void)  Blocking  void STMWait(void)  Data access  word_t STMReadValue(addr_t a)  void STMWriteValue(addr_t a, word_t w) Exposed as static methods Called from interpreter / JIT’d code

7. Data storage 100 200 a5: a1: Ownership records (orecs) version 42 version 17 Proposed updates Status: ACTIVE a1: (100,42) -> (777,43) a5: (200,17) -> (888,18) Heap structure

8.  Acquire exclusive access to each ownership record needed  Check that they hold the correct versions  Set status to committed/aborted  Make updates to the heap (if needed)  Release ownership records, updating the versions 100 200 a5: a1:version 42 version 17 Status: ACTIVE a1: (100,42) -> (777,43) a5: (200,17) -> (888,18) t1: CAS: 42 → t1 CAS: 17 → t1 CAS: active → committed Status: COMMITTED777 888 CAS: t1 → 43 CAS: t1 → 18 version 43 version 18 Non-contended updates

9.  Simple option:  Spin waiting for the owner to make its updates and release  Obstruction-free option:  Make updates on owner’s behalf and then releases ownership  Intricate: first thread may make updates at a later stage. Introduces ‘active updaters’ count into each orec – details in the paper  Hacky option:  Suspend the current owning thread  Make their updates  Revoke their ownership  Change their PC to be outside the commit operation  Resume the thread Contended updates

10. Compound swaps atomic {…} util.concurrent java.util #CPUs (1 thread per CPU) μs per operation 2737 17

11. Compound swaps (ii) #CPUs (1 thread per CPU) μs per operation atomic {…} util.concurrent java.util

12. Memory management a5: a1:  Two problems: management of transaction descriptors & management of shared data structures reachable from them  So-called ‘A-B-A’ problems occur in most CAS-based systems  We’ve looked at a number of schemes:  Safe memory re-use (Michael)  Repeat offender problem (Herlihy et al)  Reference counting  Epoch-based schemes  In many cases we’re really allocating fresh pointers rather than needing ‘more’ memory

13. Memory management (II) a5: a1:  Our more recent STM introduces a Hold/Release abstraction:  A Hold operation acquires a revocable lock on a specified location  A Release operation relinquishes such a lock  A lock is revoked by a competing hold or by another thread writing to a held location  Revocation is exposed by displacing the previous owner to a specified PC  This lets us ensure only one thread at a time is working on a given transaction descriptor – MM much simplified  Software implementation using mprotect or /proc

14.  Evaluation beyond synthetic benchmarks  Try the C STM interface yourself: download under a BSD- style license from http://www.cl.cam.ac.uk/netos/lock-free  Reflective exposure of a transactional API  Create, enter, leave transactions  Possibly enables better I/O handling  Opportunities for new hardware instructions Future directions