Scalable Read-mostly Synchronization Using Passive Reader-Writer Locks Ran Liu, Fudan University and Shanghai Jiao Tong University; Heng Zhang and Haibo Chen, Shanghai Jiao Tong University https://www.usenix.org/conference/atc14/technical-sessions/presentation/liu This paper is included in the Proceedings of USENIX ATC ’14: 2014 USENIX Annual Technical Conference. June 19–20, 2014 • Philadelphia, PA 978-1-931971-10-2 Open access to the Proceedings of USENIX ATC ’14: 2014 USENIX Annual Technical Conference is sponsored by USENIX. Scalable Read-mostly Synchronization Using Passive Reader-Writer Locks Ran Liu ‡ † , Heng Zhang †, Haibo Chen † ‡Software School, Fudan University †Institute of Parallel and Distributed Systems, Shanghai Jiao Tong University ABSTRACT tion (e.g., wait/signal) [12, 2]. Hence, researchers some- times relax semantic guarantees by allowing readers to Reader-writer locks (rwlocks) aim to maximize paral- see stale data (i.e., RCU [21]). While RCU has been lelism among readers, but many existing rwlocks either widely used in Linux kernel for some relatively simple cause readers to contend, or significantly extend writer data structures, it, however, would require non-trivial ef- latency, or both. Further, some scalable rwlocks can- fort for some complex kernel data structures and may be not cope with OS semantics like sleeping inside criti- incompatible with some existing kernel designs [10, 11]. cal sections, preemption and conditional wait. Though Hence, there are still thousands of usages or rwlocks in- truly scalable rwlocks exist, some of them cannot handle side Linux kernel [20]. preemption, sleeping inside critical sections, or other im- portant functions required inside OS kernels. This paper This paper describes the prwlock, a scalable rwlock describes a new rwlock called the passive reader-writer design for read-mostly synchronization for TSO (Total lock (prwlock) that provides scalable read-side perfor- Store Ordering) architectures. Like prior designs such as mance as well as small writer latency for TSO architec- brlock [12, 2], instead of letting readers actively maintain tures. The key of prwlock is a version-based consensus status regarding inflight readers, prwlock decentralizes protocol between multiple non-communicating readers such information to each reader and only makes a con- and a pending writer. Prwlock leverages bounded stale- sensus among readers when a writer explicitly enquires. ness of memory consistency to avoid atomic instructions By leveraging the ordered store property of TSO archi- and memory barriers in readers’ common paths, and uses tectures, such as x86 and x86-64, Prwlock achieves truly message-passing (e.g., IPI) for straggling readers so that scalable reader performance. On TSO, it not only re- writer lock acquisition latency can be bounded. Evalu- quires no atomic instructions or memory barriers on the ation on a 64-core machine shows that prwlock signifi- common path, but it also limits writer latency when there cantly boosts the performance of the Linux virtual mem- are concurrent readers. ory subsystem, a concurrent hashtable and an in-memory The key of prwlock is a version-based consensus pro- database. tocol between multiple non-communicating readers and a pending writer. A writer advances the lock version and 1INTRODUCTION waits other readers to see this version to ensure that they Reader-writer locking is an important synchronization have left their read-side critical sections. Unlike prior de- primitive that allows multiple threads with read accesses signs such as brlocks, this design is based on our obser- to a shared object when there is no writer, and blocks all vation that even without explicit memory barriers, most readers when there is an inflight writer [13]. While ide- readers are still able to see a most-recent update of the ally rwlock should provide scalable performance when lock version from the writer within a small number of there are infrequent writers, it is widely recognized cycles. We call this property bounded staleness. For that traditional centralized rwlocks have poor scalabil- straggling readers not seeing and reporting the version ity [9, 25, 10]. For example, it is explicitly recommended update, prwlock uses a message-based mechanism based to not use rwlocks unless readers hold their locks for a on inter-processor interrupts (IPIs) to explicitly achieve sufficiently long time [9]. consensus. Upon receiving the message, a reader will re- While there have been a number of efforts to to im- port to the writer whether it has left the critical section. prove the scalability of rwlocks, prior approaches either As currently message passing among cores using IPIs is require memory barriers and atomic instructions in read- not prohibitively high [4] and only very few straggling ers [22, 18], or significantly extend writer latency [5], readers require message-based consensus, a writer only or both [12, 2]. Further, many prior designs cannot needs to wait shortly to proceed. cope with OS semantics like sleeping inside critical sec- As a reader might sleep in the read-side critical sec- tion, preemption and supporting condition synchroniza- tion, it may not be able to receive messages from the USENIX Association 2014 USENIX Annual Technical Conference 219 writer. Hence, a sleeping reader might infinitely delay a writer. To address this issue, prwlock falls back to a shared counter to count sleeping readers. As sleeping in read-side critical sections is usually rare, the counter Traditional brlock1 brlock2 C-SNZI Cohort RMLock PRW Percpu-rwlock RCU No memory barrier in read is rarely used and contention on the shared counter will No atomic instruction in read not be a performance bottleneck even if there are a small No comm. among readers Sleep inside critical section number of sleeping readers. Condition wait - Prwlock is built with a parallel wakeup mechanism to Writer preference - Reader preference - improve performance when there are multiple sleeping Short writer latency w/ small #thread * - readers waiting for an outstanding writer. As traditional Unchanged rwlock semantic wakeup mechanisms (like Linux) usually use a shared *The writer latency of Percpu-rwlock is extremely long in most cases Table 1: A comparison of synchronization primitives. queue for multiple sleeping readers, a writer needs to wake up multiple readers sequentially, which becomes a scalability bottleneck with the increasing number of munication among readers. The next four rows depict readers. Based on the observation that multiple read- whether each design can support sleeping inside critical ers can be woken up in parallel with no priority viola- section (which also implies preemption) and condition tion in many cases, prwlock introduces a parallel wakeup wait (e.g., wait until a specific event such as queue is mechanism such that each reader is woken up by the core not empty), and whether the lock is writer or reader pref- where it slept from. erence. The last two rows indicate whether the writer We have implemented prwlock as a kernel mechanism in each design has short writer latency when there are a for Linux, which compromises around 300 lines of code small number of threads, and whether the design retains (LoC). To further benefit user-level code, we also created the original semantics of rwlock. a user-level prwlock library (comprising about 500 LoC) Big-reader Lock (brlock): The key design of brlock and added it to a user-level RCU library (about 100 LoC is trading write throughput for read throughput. There changes). Prwlock can be used in the complex Linux vir- are two implementations of brlock: 1) requiring each tual memory system (which currently uses rwlock), with thread to obtain a private mutex to acquire the lock in only around 30 LoC changes. The implementation is sta- read mode and to obtain all private mutexes to acquire the ble enough and has passed the Linux Test Project [1]. We lock in write mode (brlock1); 2) using an array of reader have also applied prwlock by substituting for a rwlock in flags shared by readers and writer (brlock2). However, the Kyoto Cabinet database [17]. brlock1 requires heavyweight operations for both reader Performance evaluation on a 64-core AMD machine and writer sections, as the cost of acquiring a mutex is shows that prwlock has extremely good performance still non-trivial and the cost for the writer is high for a scalability for read-mostly workloads and still good per- relatively large number of cores (i.e., readers). formance when there are quite a few writers. The per- Brlock2, like prwlock, uses per-core reader status and formance speedup of prwlock over stock Linux is 2.85X, forces writers to check each reader’s status, and thus 1.55X and 1.20X for three benchmarks on 64 cores and avoids atomic instructions in reader side. However, it prwlock performs closely to a recent effort in using RCU still requires memory barriers inside inside readers’ com- to scale Linux virtual memory [10]. Evaluation using mon paths. Further, both do not support sleeping inside micro-benchmarks and the in-memory database shows read-side critical sections as there is no centralized writer that prwlock consistently outperforms rwlock in Linux condition to sleep on and wake up. Finally, they are vul- (by 7.37X for the Kyoto Cabinet database). nerable to deadlock when a thread is preempted and mi- grated to another core. As a result, brlocks are most often 2BACKGROUND AND RELATED WORK used with preemption disabled. 2.1 Reader/Writer Lock Prwlock can be viewed as a type of brlock. However, The reader/writer problem was described by Courtois it uses a version-based consensus protocol instead of a et al. [13] and has been intensively studied afterwards. single flag to avoid memory barriers in readers’ common However, most prior rwlocks require sharing states paths and to shorten writer latency. Further, by lever- among readers and thus may result in poor critical sec- aging a hybrid design, prwlock can cope with complex tion efficiency on multicore.