1. Adaptive Software Lock Elision
Amitabha Roy
Systems Research Group, Computer Laboratory, University of Cambridge
1. Introduction
4. Design Challenges
Seamless co-existence of threads that do not speculate past a lock
Basic idea : Log the version number of speculated locks
Speculative threads ensure the lock versions are unchanged at commit time
Non speculative threads check version numbers of objects before using them to
ensure no committed but unwritten changes
A rudimentary version of this multigranularity locking idea published [1]
Memory management (no write after free by speculative threads)
Should support a variable number of threads in the system – avoid epoch based
solutions
Use external metadata like TL2
For efficiency readers should not need to indirect outside objects
Solution: Version number in objects + external lock
Lock properties (preserve priority inheritance/fairness properties of locks)
Non-speculative threads should never be blocked by speculative threads
Should be able to copy out unwritten data from committed threads
Should be able to prevent failed threads from writing to version numbers of
freed objects
Can achieve this by using OS/scheduler support to revoke fine grained locks
Lock composition (make lock based programs easier to write)
Problem: Issues with Atomic Blocks + Optimistic STM
Inflexible concurrency control : Usually only optimistic concurrency control,
not suitable for critical sections with low contention or low disjoint access
parallelism, eg linux kernel[4]
Not compatible with legacy software : Need to specify atomic blocks.
Difficult to handle irrevocable actions such as call outs to legacy
code/system calls or IO
Solution: Software Lock Elision
Retain locks as the primary means for concurrency control
Enhance the locking API to support lock elision, that is executed
optimistically/speculatively
Coarse grained locks can now scale / used when the critical section does IO
Provide support for explicit lock composition
Dynamically elide locks for adaptive concurrency control
Consequences:
Easy retrofit to legacy software and elegant new applications
Minimal programmer effort
Allow multigranularity concurrency control on data structures
Retain properties of locks such as fairness and priority inheritance
compose(foo, foobar);
compose(bar, foobar);
2. Mechanics
lock(foo)
lock(bar)
lock(bar)
lock(foo)
Add metadata to locks
struct sle_lock { base_lock lock; int version_number; int readers;}
Elide locks dynamically
Independent of underlying lock implementation
Handle non-2PL nesting of locks in the program
/* count the number of speculative locks held if positive
* and the number of non-speculative locks held if negative */
speculation_level = 0
do_sle_lock(sle_lock)
(dynamic_elide() or speculation_level > 0) and speculation_level >= 0 :
speculation_level + +; log_elided_lock(sle_lock);
Else :
speculation_level- -; do_base_lock(sle_lock.base_lock);
If(exclusive_mode) sle_lock.version + +; else atomic_inc(sle_lock.readers);
do_sle_unlock(sle_lock)
speculation_level < 0 :
speculation_level + +;
If(exclusive_mode) sle_lock.version + +; else atomic_dec(sle_lock.readers);
speculation_level - -;
If(speculation_level == 0) commit_speculative_changes();
safe_lock(foo)/safe_lock(bar):
Acquire foobar in place of foo/bar
Ensure foo/bar is free before proceeding
Deadlock !!
5. Preliminary Results
Scalable Locking [1] : Allow locks to be acquired transactionally and non-transactionally. Illustrated key ideas in software lock elision
Test bed: Altix 4700, 38 NUMA nodes * 2 sockets * dual core = 152 Itanium2 cores, 456 GB overall shared memory
Benchmark: Skip lists and Red Black trees, scalable locks vs. OSTM[2]
→ Scalable locks scales as well as OSTM and provides better
performance by a constant factor (~2X)
Asymmetry: 2 threads, each on a different NUMA node, all memory local to first node
Benchmark: Increment a counter, compare OSTM, RSTM[2](all contention managers) and Scalable locks (with an MCS fairlock for conflict handling)
3. Speculation
→ Scalable locks provides
perfect thread fairness,
50% accesses by each
thread
Executing speculatively whenever (speculation_depth > 0)
Need to version reads and shadow changes to shared state
Programmer knows what lock protects what data. Must explicitly mark data protected by elidable locks
Option : object granularity using compiler extensions eg. with gcc style attributes
struct red_black_tree_node { … } __attribute__((__speculative__))
Pointer dereferences call into the runtime
struct red_black_tree_node *rbnode1, *rbnode2; ……
rbnode1->parent = rbnode2
6. Adaptive Concurrency Control
Measure the amount of contention (waiting threads) of a lock
Measure the amount of disjoint access parallelism behind a lock (conflicts
among speculating threads)
Elide the lock only if sufficient contention AND disjoint access parallelism
[decided by a call to dynamic_elide() ]
Adds a version number
Log read
Return shadow copy
Log dirty
7. References
[1] Amitabha Roy, Keir Fraser and Steven Hand. A Transactional Approach to Lock Scalability. Proceedings of the 20th ACM Symposium on Parallelism in Algorithms and Architectures (SPAA08), Munich, Germany, June 2008
[2] Keir Fraser. Practical lock freedom. PhD thesis, Cambridge University Computer Laboratory, Also available as Technical Report UCAM-CL-TR-579.
[3] Virendra J. Marathe et al. Lowering the overhead of software transactional memory. Technical Report, Condensed version appeared in TRANSACT 2006.
[4] Christopher J. Rossbach et al. Txlinux: using and managing hardware transactional memory in an operating system. In SOSP ’07: Proceedings of twenty-first ACM SIGOPS symposium on Operating systems principles, pages 87–102. ACM, 2007.
Read Log
rbnode
version
Snapshot state
Write Log
Dirty
Commit time 2PL fine grained write locks + verify read versions