A programming language perspective on transactional memory consistency

Abstract

Transactional memory (TM) has been hailed as a paradigm for simplifying concurrent programming. While several consistency conditions have been suggested for TM, they fall short of formalizing the intuitive semantics of atomic blocks, the interface through which a TM is used in a programming language.To close this gap, we formalize the intuitive expectations of a programmer as observational refinement between TM implementations: a concrete TM observationally refines an abstract one if every user-observable behavior of a program using the former can be reproduced if the program uses the latter. This allows the programmer to reason about the behavior of a program using the intuitive semantics formalized by the abstract TM; the observational refinement relation implies that the conclusions will carry over to the case when the program uses the concrete TM. We show that, for a particular programming language and notions of observable behavior, a variant of the well-known consistency condition of opacity is sufficient for observational refinement, and its restriction to complete histories is furthermore necessary.Our results suggest a new approach to evaluating and comparing TM consistency conditions. They can also reduce the effort of proving that a TM implements its programming language interface correctly, by only requiring its developer to show that it satisfies the corresponding consistency condition.

Verifying Opacity of a Transactional Mutex Lock

“…There are numerous formalizations of opacity in the literature; our definition mainly follows Attiya et al [2]. We model shared memory by a set Addr of addresses or locations.…”

“…Several notions of correctness have been defined, e.g., strict serializability [17], opacity [8,2], TMS1 and TMS2 [6], and virtual world consistency [13]. A number of researchers have already considered methods for verifying correctness of transactional memory implementations; a comprehensive survey may be found in [14].…”

“…As correctness criterion we employ the recently given definition of opacity of Attiya et al [2]. It provides strong guarantees to programmers in the form of observational refinement allowing programmers to reason about programs using opaque STMs in terms of atomic transactions.…”

“…), but also further decompose these operations into several steps (accessing and manipulating so-called meta-data) as to allow for a maximum of concurrency. The former decomposition is accounted for in step (2), the latter in step (1).…”

Transaction Chopping for Parallel Snapshot Isolation

“…Recent years have seen a plethora of consistency model proposals that make different trade-offs between consistency and performance [6,7,20,22]. Unfortunately, whereas transactional consistency models have been well-studied in the settings of smaller-scale databases [2,13,21] and transactional memory [5,12,14,16], models for large-scale distributed databases are poorly understood. In particular, we currently lack a rich theory that would guide programmers in using such models correctly and efficiently.…”