Adaptive Software Lock Elision Amitabha Roy Systems Research Group, Computer Laboratory, University of Cambridge {amitabha.roy}@cl.cam.ac.uk 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, 2003. 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