Verifying Linearisability

Abstract

Linearizability is a key correctness criterion for concurrent data structures, ensuring that each history of the concurrent object under consideration is consistent with respect to a history of the corresponding abstract data structure. Linearizability allows concurrent (i.e., overlapping) operation calls take effect in any order, but requires the real-time order of non-overlapping to be preserved. The sophisticated nature of concurrent objects means that linearizability is difficult to judge, and hence, over the years, numerous techniques for verifying linearizability have been developed using a variety of formal foundations such as data refinement, shape analysis, reduction, etc. However, because the underlying framework, nomenclature and terminology for each method is different, it has become difficult for practitioners to evaluate the differences between each approach, and hence, evaluate the methodology most appropriate for verifying the data structure at hand. In this paper, we compare the major of methods for verifying linearizability, describe the main contribution of each method, and compare their advantages and limitations.

Verifying Correctness of Persistent Concurrent Data Structures

“…The operational model for durable linearizability is formalised in terms of an Input/Output automaton (IOA) [18]. This framework is often used for proving linearizability via refinement [9]. The set acts(A) is partitioned into internal actions, internal(A) and external actions, external(A).…”

“…Any step of the implementation that refines do(op) is a step that persists the corresponding operation op (i.e., a persistence point, see Section 5). Persistence points in durable linearizability are analogous to linearization points in linearizability [9]. Note that a thread may only invoke an operation if it is ready.…”

Pointer life cycle types for lock-free data structures with memory reclamation

“…(The work by Gotsman et al [2013] checks memory safety and discovers memory leaks as well.) For a more detailed overview of manual techniques, we refer to the survey by Dongol and Derrick [2015].…”

Towards linking correctness conditions for concurrent objects and contextual trace refinement

“…Many papers have been devoted to verifying linearizability of concurrent object implementations [1]; however, these typically only consider behaviours of the concurrent object at hand in isolation -they do not provide any guarantees to the client programs that use concurrent objects. Therefore, letting P[O] denote a client program P that uses object O, we consider the following question:…”

“…2 Concurrent objects and their clients Figure 1 presents a simplified version of a non-blocking stack example due to Treiber [10], which has become a standard case study from the literature. 1 The implementation has fine-grained atomicity, and each line of the push and pop operations corresponds to a single atomic step. Synchronisation is achieved using an atomic compare-and-swap (CAS) instruction, which takes as input a (shared) variable gv, an expected value lv and a new value nv: CAS(gv, lv, nv) = atomic { if gv = lv then gv := nv ; return true else return false } The Treiber stack implements the abstract stack specification in Figure 2, where ' ' and ' ' delimit sequences, ' ' denotes the empty sequence, and ' ' denotes sequence concatenation.…”