Beyond Simple Transactions and Atomic Blocks

Concurrent programming is notoriously difficult because actions by concurrent threads may be interleaved and result in unanticipated interactions, particularly on a shared-memory system. One mechanism proposed to address this difficulty is transactional memory (TM): programmers can group several operations into a transaction, which a TM implementation guarantees will appear to execute atomically,1 or not at all (i.e., the transaction is aborted). Thus, transactions reduce the possible interleavings and interactions that the programmer must consider. With transactional memory, it is easy to implement atomic blocks: one can simply execute the atomic block within a transaction, retrying in case the transaction aborts. Atomic blocks are typically implemented using locks to protect accessed data, in which the programmer must choose how to associate locks with data—trading simplicity against permissible concurrency—and manage the well known challenges of lock-based programming (e.g., the possibility of deadlock). Using transactions rather than locks, raises the level of abstraction, and shifts the responsibility of ensuring apparently atomic execution from the programmer to the system. Thus, programmers do not need to acquire the locks protecting the accessed data (and in such a way that avoids deadlock). Indeed, a TM implementation might not use locks to guarantee atomicity, but rather execute transactions optimistically, and abort those that will not appear atomic. However, transactional memory is not a panacea for concurrent programming: Many concurrent programs will require different kinds of synchronization, perhaps to avoid the overhead of implementing transactions or because another kind of synchronization is more “natural” in certain cases. For example, one thread may have to wait for another to compute a value (i.e., a producer-consumer pair). Or a thread may want to do some I/O (I/O is synchronization with the “user”). In addition, transactions may interact with other programming constructs even for a single thread, such as exceptions. For TM to be successful, its behavior with respect to these other kinds of synchronization and programming constructs must be well-defined, and preferably easy to understand. Some people suggest that transactional semantics should be defined in terms of locking semantics [13], and that TM should be considered a technique for implementing the semantics of a single global lock, but allowing greater concurrency than would be implied by actually having a single lock [3]. Although this may yield many of the performance benefits of TM, it gives up the conceptual benefits of TM, which I believe are ultimately more important. Key among these benefits is modularity: A transaction hides within itself the details of how it is implemented. The lack of this ability to hide implementation details is one of the chief reasons that lock-based programming is difficult: to avoid deadlock, a programmer must typically expose what locks may be acquired in a critical section, making the locks are part of the interface, not just the implementation. I hope that transactions can be to concurrent programming what functions are to sequential programming: the basic building blocks from which programs are constructed. This