Automatic Linearizability Proofs of Concurrent Objects with Cooperating Updates

Abstract

Abstract. An execution containing operations performing queries or updating a concurrent object is linearizable w.r.t an abstract implementation (called specification) iff for each operation, one can associate a point in time, called linearization point, such that the execution of the operations in the order of their linearization points can be reproduced by the specification. Finding linearization points is particularly difficult when they do not belong to the operations's actions. This paper addresses this challenge by introducing a new technique for rewriting the implementation of the concurrent object and its specification such that the new implementation preserves all executions of the original one, and its linearizability (w.r.t. the new specification) implies the linearizability of the original implementation (w.r.t. the original specification). The rewriting introduces additional combined methods to obtain a library with a simpler linearizability proof, i.e., a library whose operations contain their linearization points. We have implemented this technique in a prototype, which has been successfully applied to examples beyond the reach of current techniques, e.g., Stack Elimination and Fetch&Add.

Aspect-oriented linearizability proofs

“…As a result, most work on automatically verifying linearizability (e.g. [2,18,19,1,6]) and some manual verification efforts (e.g., [4,3]) have relied on the simpler technique of forward simulations, even though it is known to be incomplete. The programmer is typically required to annotate each method with its linearization points and then the verifier uses some kind of shape analysis that automatically constructs the simulation relation.…”

Hoare-style specifications as correctness conditions for non-linearizable concurrent objects

“…We next explain how this desired property follows for hide e, from the two inequalities in e's postcondition zip ts 1 res.1 vs 1 ⊆ zip ts 2 vs 2 res.2 · ∪ χ O · ∪ ||m J ||, (14) zip ts 2 res.2 vs 2 ⊆ zip ts 1 vs 1 res.1 · ∪ χ O · ∪ ||m J ||. (15) Notice that (14) and (15) are ultimately instances of the conjunct η ⊆ χ O · ∪ ||m J || that was part of the specification (10), thereby justifying the use of subjective other variables.…”

“…We know that dom m J = π S · ∪ π O (from Section 2), that π S = ∅ (from e's postcondition), and that by hiding, π O = χ O = ∅. Thus, towards deriving the postcondition of hide e, we simplify (14) and (15) into:…”

“…At the moment, our goal was not to optimize the proof sizes, but to demonstrate that FCSL as a tool is suitable off-the-shelf for machine-checked verification of properties in the spirit of novel correctness conditions [3,23,29]. Therefore, we didn't invest into building advanced tactics [35] for specific classes of programs [53] or properties [5,6,14,52], and we leave developing such automation for future work.…”

Monitoring refinement via symbolic reasoning

“…Several semi-automated verification approaches rely on annotating method bodies with linearization points [1,3,8,14,17,20,23] to reduce the otherwise-exponential number of possible linearizations to one single linearization. These methods typically rely on programmer annotation, and do not admit conclusive evidence of a violation in the case of a failed proof.…”