Preemption Adaptivity in Time-Published Queue-Based Spin Locks

He, Bijun; Scherer, William N.; Scott, Michael L.

doi:10.1007/11602569_6

Cited by 34 publications

(32 citation statements)

References 34 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…A global monitor controls how many threads must block, while the remaining threads use time-published MCS locks [34]. The background thread of GLK is similar to this global monitor.…”

Section: Related Work Lock Algorithmsmentioning

confidence: 99%

Locking Made Easy

Antić

Chatzopoulos

Guerraoui

et al. 2016

Proceedings of the 17th International Middleware Conference

View full text Add to dashboard Cite

A priori, locking seems easy: To protect shared data from concurrent accesses, it is sufficient to lock before accessing the data and unlock after. Nevertheless, making locking efficient requires finetuning (a) the granularity of locks and (b) the locking strategy for each lock and possibly each workload. As a result, locking can become very complicated to design and debug.We present GLS, a middleware that makes lock-based programming simple and effective. GLS offers the classic lock-unlock interface of locks. However, in contrast to classic lock libraries, GLS does not require any effort from the programmer for allocating and initializing locks, nor for selecting the appropriate locking strategy. With GLS, all these intricacies of locking are hidden from the programmer. GLS is based on GLK, a generic lock algorithm that dynamically adapts to the contention level on the lock object. GLK is able to deliver the best performance among simple spinlocks, scalable queue-based locks, and blocking locks. Furthermore, GLS offers several debugging options for easily detecting various lockrelated issues, such as deadlocks.We evaluate GLS and GLK on two modern hardware platforms, using several software systems (i.e., HamsterDB, Kyoto Cabinet, Memcached, MySQL, SQLite) and show how GLK improves their performance by 23% on average, compared to their default locking strategies. We illustrate the simplicity of using GLS and its debugging facilities by rewriting the synchronization code for Memcached and detecting two potential correctness issues. CCS Concepts•Computing methodologies → Shared memory algorithms; Concurrent algorithms; •Computer systems organization → Multicore architectures; Keywords Locking; Adaptive Locking; Locking Middleware; Locking Runtime; Synchronization; Multi-cores; Performance * Work done while the author was at EPFL. Currently at Google. † Author names appear in alphabetical order.Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than the author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from permissions@acm.org.

show abstract

“…A global monitor controls how many threads must block, while the remaining threads use time-published MCS locks [34]. The background thread of GLK is similar to this global monitor.…”

Section: Related Work Lock Algorithmsmentioning

confidence: 99%

Locking Made Easy

Antić

Chatzopoulos

Guerraoui

et al. 2016

Proceedings of the 17th International Middleware Conference

View full text Add to dashboard Cite

show abstract

“…The delete operation (Figure 8(a)) is the most complex operation of the OPTIK-based linked list, because it requires locking two nodes; the one being deleted and its predecessor node. Traversing the list (lines 11-15) keeps track of these two version numbers that are later used for locking with optik trylock version (lines [18][19][20][21][22][23]. If locking the predecessor node fails, the operation is restarted, otherwise the node to be deleted is locked.…”

Section: Optik-based Linked Listmentioning

confidence: 99%

Optimistic concurrency with OPTIK

Guerraoui

Trigonakis

2016

Proceedings of the 21st ACM SIGPLAN Symposium on Principles and Practice of Parallel Programming

View full text Add to dashboard Cite

We introduce OPTIK, a new practical design pattern for designing and implementing fast and scalable concurrent data structures. OPTIK relies on the commonly-used technique of version numbers for detecting conflicting concurrent operations. We show how to implement the OPTIK pattern using the novel concept of OPTIK locks. These locks enable the use of version numbers for implementing very efficient optimistic concurrent data structures. Existing state-of-the-art lock-based data structures acquire the lock and then check for conflicts. In contrast, with OPTIK locks, we merge the lock acquisition with the detection of conflicting concurrency in a single atomic step, similarly to lock-free algorithms. We illustrate the power of our OPTIK pattern and its implementation by introducing four new algorithms and by optimizing four state-of-the-art algorithms for linked lists, skip lists, hash tables, and queues. Our results show that concurrent data structures built using OPTIK are more scalable than the state of the art.

show abstract

“…Strict FIFO ordering and 10000x longer delays than the OS-supplied primitive combine to virtually freeze the system as it services a few tens of critical sections per second. Preemption-resistant variants [6] improve the situation by removing preempted threads from the FIFO queue, but can do little to prevent the lock holder from being preempted by its spinning successors. As we will see in Section 3, with preemption resistance performance only falls off rapidly instead of instantly once load exceeds 100%.…”

Section: Convoys and Preemption Resistancementioning

confidence: 99%

“…Other work suggests heuristics for optimizing the duration of spinning based on machine size and workload [3]. Recent research [6] has also addressed partially the negative interaction between spinning and thread preemptions due to OS activity. While these techniques are all helpful, however, they do not address the underlying sources of poor performance.…”

Section: Introductionmentioning

confidence: 99%

A new look at the roles of spinning and blocking

Johnson

Athanassoulis

Stoica

et al. 2009

Proceedings of the Fifth International Workshop on Data Management on New Hardware

View full text Add to dashboard Cite

Database engines face growing scalability challenges as core counts exponentially increase each processor generation, and the efficiency of synchronization primitives used to protect internal data structures is a crucial factor in overall database performance. The trade-offs between different implementation approaches for these primitives shift significantly with increasing degrees of available hardware parallelism. Blocking synchronization, which has long been the favored approach in database systems, becomes increasingly unattractive as growing core counts expose its bottlenecks. Spinning implementations improve peak system throughput by a factor of 2x or more for 64 hardware contexts, but suffer from poor performance under load.In this paper we analyze the shifting trade-off between spinning and blocking synchronization, and observe that the trade-off can be simplified by isolating the load control aspects of contention management and treating the two problems separately: spinning-based contention management and blocking-based load control. We then present a proof of concept implementation that, for high concurrency, matches or exceeds the performance of both user-level spinlocks and the pthread mutex under a wide range of load factors. INTRODUCTIONRecent shifts in computer architecture have resulted in systems containing multiple cores per chip, with core counts projected to double every two years for the foreseeable future. While multicore architectures make available an unprecedented degree of hardware parallelism, they also pose new challenges for database engine design. Increasing the number of concurrent threads puts pressure on internal database engine components and exposes new bottlenecks in the system [7]. Database systems have long depended on blocking synchronization primitives (supplied by the operating system) to manage contention because they are both effective and offer predictable performance over a wide range of system load factors. However, we find that the trade-offs between spinning and blocking primitives shift significantly with increasing degrees of available hardware parallelism. In particular, blocking primitives become unattractive because they result in low system utilization for the high core counts which now appear in commodity servers. By utilizing fully, the machine spinlocks improve performance by 2x or more, but suffer from unstable performance under load.The strengths and weaknesses of spinning and blocking as contention management strategies are well known, and several approaches have been proposed to address the weaknesses or balance their trade-offs. For example, mutex locks in certain operating systems make use of adaptive spinning to avoid the cost of context switches when the wait for a lock 1 is short, leading to performance competitive with spinlocks while avoiding most of the weaknesses of spinning. Other work suggests heuristics for optimizing the duration of spinning based on machine size and workload [3]. Recent research [6] has also addressed partially t...

show abstract

Preemption Adaptivity in Time-Published Queue-Based Spin Locks

Cited by 34 publications

References 34 publications

Locking Made Easy

Locking Made Easy

Optimistic concurrency with OPTIK

A new look at the roles of spinning and blocking

Contact Info

Product

Resources

About