Pessimistic Software Lock-Elision

Afek, Yehuda; Matveev, Alexander; Shavit, Nir

doi:10.1007/978-3-642-33651-5_21

Cited by 23 publications

(21 citation statements)

References 12 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…This has two disadvantages: (1) wasting time when arriving while the lock is taken (as our experiments on STAMP show, this is significant), and (2) the lock no longer guarantees starvation-freedom and loses its fairness. 1 shared variable: Roy et al [23] and Afek et al [5] implement lock elision completely in software, using specialized software transactional memory algorithms. These implementations instrument the critical sections to track read and written memory locations.…”

Section: Related Workmentioning

confidence: 99%

Software-improved hardware lock elision

Afek

Levy

Morrison

2014

Proceedings of the 2014 ACM Symposium on Principles of Distributed Computing

Self Cite

View full text Add to dashboard Cite

With hardware transactional memory (HTM) becoming available in mainstream processors, lock-based critical sections may now initiate a hardware transaction instead of taking the lock, enabling their concurrent execution unless a real data conflict occurs. However, just a few transactional aborts can cause the lock to be acquired non-transactionally resulting in the serialization of all the threads, severely degrading the amount of speedup obtained.In this paper we provide two software extension mechanisms that considerably improve the concurrency and speedup levels attained by lock based programs using HTM-based lock elision. The first sacrifices opacity to achieve higher levels of concurrency, and the second retains opacity while reaching slightly lower levels of concurrency.Evaluation on STAMP and on data structure benchmarks on an Intel Haswell processor shows that these techniques improve the speedup by up to 3.5 times and 10 times respectively, compared to using Haswell's hardware lock elision as is.

show abstract

Section: Related Workmentioning

confidence: 99%

Software-improved hardware lock elision

Afek

Levy

Morrison

2014

Proceedings of the 2014 ACM Symposium on Principles of Distributed Computing

Self Cite

View full text Add to dashboard Cite

show abstract

“…In a nutshell, RLU works as follows. We keep the overall RCU barrier mechanism with updaters waiting until all pre-existing readers have finished their operations, but replace the hand-crafted copy creation and installation with a clock-based logging mechanism inspired by the ones used in software transactional memory systems [1,8,33]. The biggest limitation of RCU is that it cannot support multiple updates to the data structure because it critically relies on a single atomic pointer swing.…”

Section: Introductionmentioning

confidence: 99%

Read-log-update

Matveev

Shavit

Felber

et al. 2015

Proceedings of the 25th Symposium on Operating Systems Principles

Self Cite

View full text Add to dashboard Cite

This paper introduces read-log-update (RLU), a novel extension of the popular read-copy-update (RCU) synchronization mechanism that supports scalability of concurrent code by allowing unsynchronized sequences of reads to execute concurrently with updates. RLU overcomes the major limitations of RCU by allowing, for the first time, concurrency of reads with multiple writers, and providing automation that eliminates most of the programming difficulty associated with RCU programming. At the core of the RLU design is a logging and coordination mechanism inspired by software transactional memory algorithms. In a collection of microbenchmarks in both the kernel and user space, we show that RLU both simplifies the code and matches or improves on the performance of RCU. As an example of its power, we show how it readily scales the performance of a real-world application, Kyoto Cabinet, a truly difficult concurrent programming feat to attempt in general, and in particular with classic RCU.

show abstract

“…It is therefore not surprising that many approaches do not allow write-write concurrency; these include the readcopy-update (RCU) approach [18], flat-combining [12], coarse-grained readerswriter locking [8], and pessimistic software lock-elision [1]. It has been shown that such methodologies can perform better than ones that allow write-write concurrency, both when there are very few updates relative to queries [18] and when writes contend heavily [12].…”

Section: Introductionmentioning

confidence: 99%

“…The implementation itself may rely on known techniques such as locking, RCU [18], pessimistic lock-elision [1], or any combinations of those, such as RCU combined with fine-grained locking [2]. There are several techniques, such as flat-combining [12] and read-write locking [8], that can naturally expand such an implementation to support also write-write concurrency by adding synchronization among update operations.…”

Section: Introductionmentioning

confidence: 99%

On Correctness of Data Structures under Reads-Write Concurrency

Lev-Ari

Chockler

Keidar

2014

Lecture Notes in Computer Science

View full text Add to dashboard Cite

Abstract. We study the correctness of shared data structures under reads-write concurrency. A popular approach to ensuring correctness of read-only operations in the presence of concurrent update, is read-set validation, which checks that all read variables have not changed since they were first read. In practice, this approach is often too conservative, which adversely affects performance. In this paper, we introduce a new framework for reasoning about correctness of data structures under reads-write concurrency, which replaces validation of the entire read-set with more general criteria. Namely, instead of verifying that all read shared variables still hold the values read from them, we verify abstract conditions over the shared variables, which we call base conditions. We show that reading values that satisfy some base condition at every point in time implies correctness of read-only operations executing in parallel with updates. Somewhat surprisingly, the resulting correctness guarantee is not equivalent to linearizability, and is instead captured through two new conditions: validity and regularity. Roughly speaking, the former requires that a read-only operation never reaches a state unreachable in a sequential execution; the latter generalizes Lamport's notion of regularity for arbitrary data structures, and is weaker than linearizability. We further extend our framework to capture also linearizability. We illustrate how our framework can be applied for reasoning about correctness of a variety of implementations of data structures such as linked lists.

show abstract

Pessimistic Software Lock-Elision

Cited by 23 publications

References 12 publications

Software-improved hardware lock elision

Software-improved hardware lock elision

Read-log-update

On Correctness of Data Structures under Reads-Write Concurrency

Contact Info

Product

Resources

About