General and efficient locking without blocking

Abstract

Standard concurrency control mechanisms offer a trade-off: Transactional memory approaches maximize concurrency, but suffer high overheads and cost for retrying in the case of actual contention. Locking offers lower overheads, but typically reduces concurrency due to the difficulty of associating locks with the exact data that need to be accessed. Moreover, locking allows irreversible operations, is ubiquitous in legacy software, and seems unlikely to ever be completely supplanted.We believe that the trade-off between transactions and (blocking) locks has not been sufficiently exploited to obtain a "best of both worlds" mechanism, although the main components have been identified. Mechanisms for converting locks to atomic sections (which can abort and retry) have already been proposed in the literature: Rajwar and Goodman's "lock elision" (at the hardware level) and Welc et al.'s hybrid monitors (at the software level) are the best known representatives. Nevertheless, these approaches admit improvements on both the generality and the performance front. In this position paper we present two ideas. First, we discuss an adaptive criterion for switching from a locking to a transactional implementation, and back to a locking implementation if the transactional one appears to be introducing overhead for no gain in concurrency. Second, we discuss the issues arising when locks are nested. Contrary to assertions in past work, transforming locks into transactions can be incorrect in the presence of nesting. We explain the problem and provide a precise condition for safety.

Adaptive locks: Combining transactions and locks for efficient concurrency

“…The topic of the semantic differences between locks and transactions has been covered in significant detail in previous literature [11,14,[16][17][18]29], and we next discuss how the differences affect adaptive locks.…”

“…The programmer also has the obligation to ensure that the program is equally correct if all lock labels are dropped and all critical sections atomic(<lckLbl>)<stmt> execute as transactions, atomic <stmt>, in a conventional TM system (e.g., [13][14][15]). The reason is that transactions can have subtly different behavior from mutex locks [11,14,[16][17][18]. Nevertheless, the topic of adaptive locks is orthogonal to such differences.…”

“…For weaker back-end TM systems, the programmer can ensure correctness of adaptive locks code under either mode by employing static separation (i.e., ensuring that data that are ever shared are always accessed under a lock [11,19]) or dynamic separation [20] techniques. We will discuss this topic in Section 5, where we also offer a general condition for the semantic equivalence of transactions and mutexes.…”

“…Welc et al acknowledge the need for more adaptive solutions, which our work provides. Finally, the work in this paper is an evolution and realization of the non-blocking locks idea that we presented in an earlier position paper [11]. Overall, our concrete contributions are as follows:…”

Adaptive Locks: Combining Transactions and Locks for Efficient Concurrency

“…Welc et al acknowledge the need for more adaptive solutions, which our work provides. Finally, the work in this paper is an evolution and realization of the non-blocking locks idea that we presented in an earlier position paper [30]. Overall, our concrete contributions are as follows:…”