We introduce obstruction-freedom, a new nonblocking property for shared data structure implementations. This property is strong enough to avoid the problems associated with locks, but it is weaker than previous nonblocking properties—specifically lock-freedom and wait-freedom— allowing greater flexibility in the design of efficient implementations. Obstruction-freedom admits substantially simpler implementations, and we believe that in practice it provides the benefits of wait-free and lock-free implementations. To illustrate the benefits of obstruction-freedom, we present two obstruction-free CAS-based implementations of double-ended queues (deques); the first is implemented on a linear array, the second on a circular array. To our knowledge, all previous nonblocking deque implementations are based on unrealistic assumptions about hardware support for synchronization, have restricted functionality, or have operations that interfere with operations at the opposite end of the deque even when the deque has many elements in it. Our obstruction-free implementations have none of these drawbacks, and thus suggest that it is much easier to design obstruction-free implementations than lock-free and waitfree ones. We also briefly discuss other obstruction-free data structures and operations that we have implemented. 1.

Transactional memory (TM) promises to substantially reduce the difficulty of writing correct, efficient, and scalable concurrent programs. But previous “bounded ” and “best-effort” hardware TM implementations impose unreasonable constraints on programmers, while more flexible software TM implementations are considered too slow. Recent novel proposals suggest supporting “large ” and even “unbounded ” transactions in hardware. These proposals entail substantially more complexity and risk than best-effort designs. We fear that the perceived need to provide “all or nothing ” in hardware will result in designers of mainstream commercial processors opting for “nothing ” for the forseeable future. We describe Hybrid Transactional Memory, an approach to implementing TM so that it uses best-effort hardware TM if it is available to boost performance, but does not expose programmers to any of its limitatons (or even whether it exists). We also describe several other uses of TM for which a best-effort hardware implementation would provide significant value. We hope to convince designers of commerical processors that they can provide considerable value with a best-effort hardware TM implementation, without taking on the formidable challenge of supporting all transactions in hardware. 1

The current state of the art seems to favour blocking software transactional memory (STM) implementations over nonblocking ones, and a common belief is that nonblocking STMs fundamentally cannot be made to perform as well as blocking ones. But this belief is based on experience, intuition, and anecdote, not on rigorous analysis. We believe there is still plenty of room for improvement in the performance of nonblocking STMs and that, regardless of performance, blocking is unacceptable in some contexts. It is therefore important to continue improving nonblocking STMs, both as a goal in its own right, as well as to inform research aimed at determining whether a fundamental gap exists between blocking and nonblocking STMs. We describe a novel nonblocking copyback mechanism for a word-based software transactional memory (STM), which closely follows simple and efficient blocking mechanisms in the common case. Previous nonblocking copyback mechanisms impose significant overhead on the common case. Our performance experiments show that this approach yields significant performance improvement over the previous best nonblocking word-based STM. Our design approach can be applied to some other blocking STMs to achieve nonblocking counterparts that perform similarly in the common case.

Abstract — Arguably, one of the biggest deterrants for software developers who might otherwise choose to write parallel code is that parallelism makes their lives more complicated. Perhaps the most basic problem inherent in the coordination of concurrent tasks is the enforcing of atomicity so that the partial results of one task do not inadvertently corrupt another task. Atomicity is typically enforced through locking protocols, but these protocols can introduce other complications, such as deadlock, unless restrictive methodologies in their use are adopted. We have recently begun a research project focusing on transactional memory [18] as an alternative mechanism for enforcing atomicity, since it allows the user to avoid many of the complications inherent in locking protocols. Rather than viewing transactions as infrequent occurrences in a program, as has generally been done in the past, we have adopted the point of view that all user code should execute in the context of some transaction. To make this viewpoint viable requires the development of two key technologies: effective hardware support for scalable transactional memory, and linguistic and compiler support. This paper describes our preliminary research results on making “transactions everywhere ” a practical reality. I.

Certified by

Concurrent programming is notoriously di#cult. Current abstractions are intricate to use and make it hard to design computer systems that are reliable and scalable. We argue in favour of a practical declarative style of concurrency control in which programmers directly indicate the safety properties that they require. In essence, the programmer demarks sections of code which execute within lightweight software-based transactions which commit atomically and exactly once.