Axioms for concurrent objects

Specification and verification techniques for abstract data types that have been successful for sequential programs can be extended in a natural way to provide the same benefits for concurrent programs. We propose an approach to specifying and verifying concurrent objects based on a novel correctness condition, which we call “linearizability.” Linearizability provides the illusion that each operation takes effect instantaneously at some point between its invocation and its response, implying that the meaning of a concurrent object's operations can still be given by pre- and post-conditions. In this paper, we will define and discuss linearizability, and then give examples of how to reason about concurrent objects and verify their implementations based on their (sequential) axiomatic specifications.

suggests registers with read and write operations, we use the term concurrent object to suggest a richer semantics.Each object has a type, which defines a set of possible values and a set of primitive operations that provide the only means to create and manipulate that object.We can give an axiomatic specification for a typed object to define the meaning of its operations when they are invoked one at a time by a single process.
In a concurrent system, however, an object's operations can be invoked by concurrent processes, and it is necessary to give a meaning to possible interleavings of operation invocations.
Our approach to specifying and verifying concurrent objects is based on the notion of linearizability.A concurrent computation is linearizable if it is "equivalent," in a Sense formally defined in Section 3, to a legal sequential computation.
We interpret a data type's (sequential) Permission to copy without fee aI1 or part of this material is granted provided that the copies are not made or distributed for direct commercial advantage, the ACM copyright notice and the title of the publication and its date appear, and notice is given that copying is by permission of the Association for Computing Machinery.To copy otherwise, or to republish, requires a fee and/or specific permission.
a number of correctness conditions both implicit and explicit in the literature.
Using axiomatic specifications and our notion of linearizability, we show that we can perform two kinds of reasoning: l We reason about concurrent computations by transforming assertions about concurrent computations into simpler assertions about sequential computations.
Familiar axiomatic techniques help prove these transformed assertions.l Implementations of concurrent objects are necessarily more complex then their sequential counterparts.We reason about the correctness of linearizable implementations using new techniques that generalize the notions of representation invariant and abstraction function to the concurrent domain.
Section 2 presents our model of a concurrent system and specification technique; Section 3 defines and discusses linearizability, including its locality property; Section 4 illustrates reasoning about concurrent registers and queues; Section 5 illustrates reasoning about an implementation of a concurrent queue; Sections 6 and 7 contain discussions on related work and the significance of linearizability.

Histories
An execution of a concurrent system is modeled by a history, which is a finite sequence of operation invocation and response events.An operation invocation is written as x opfargs') A, where x is an object name, op is an operation name, args* denotes a sequence of argument values, and A is a process name.The response to an operation invocation is written as x rerm(res*) A, where term is a termination condition, and res* is a sequence of resutts.We use "Ok" for normal termination.A response marches an invocation if their object names agree and their process names agree.An invocation is pending in a history if no matching response follows the invocation.If H is a history, complete(H) is the longest subhistory of H consisting only of invocations and matching responses.
A history H is sequential if: 1.The first event of H is an invocation.
2. Each invocation, except possibly the last, is immediately followed by a matching response.
3. Each response, except possibly the last, is immediately followed by an invocation.
A ~KXXJSS subhistory, HjP (H at P), of a history H is the subsequence of events in H whose process names are P.An object s&history Hjx is similarly defined for an object X. TWO histories H and H' are equivalent if for every process P, HIP * H'(P.A history H is we//-formed if each process subhistory Hjp of H is sequential.All histories considered in this paper are assumed to be well-formed.Notice that whereas Process subhistories of a well-formed history are necessarily sequential, object subhistories are not.An operafion, e, in a history is a pair COnSiStin Of an invocation, inv(e), and the next matching response, res(e).
An operation eo lies within another operation e, in H if inv(e,) precedes inv(eo) and res(eo) precedes res(e,) in H.
For example, let H, be the following history: q End A q End B (History H,) qW)B qW)A q Des0 B q Wx) B q DeqO A q WY) A q End A H, is a well-formed history for a FIFO queue q providing Enq and Deq operations.The first event is an invocation of Enq with argument x by process A, and the fourth event is the matching response with termination condition Ok and no results.The "q Enq(y) B/q Ok() B" operation lies within the "q Enq(x) A/q Ok() A" operation.
The subhistory, complete(H,), is H, with the last (pending) invocation of Enq removed.Reordering the first two events yields one of many histories equivalent to H,.

Specifications
A sequential history for an object can be summarized by the object's value at the end of the history.We use axiomatic I-, isEmp(q)l DeSO/OW {q' = rest(q) A e = first(q)) for all q: Q, 8: E first(ins(emp), e)) = e first(ins(q, e)) = if isEmp(q) then e else first(q) rest(ins(q, e)) = if isEmp(q) then emp else ins(rest(q), e) isEmp(emp) = true isEmp(ins(q, e)) = false A history H induces an irreflexive partial order +" on operations: e, -$, e, if res(e,,) precedes inv(e,) in H. (Where appropriate, the subscript is omitted.)Informally, -$ captures the "real-time" precedence ordering of operations in H. Operations unrelated by -c,, are said to be concurrent.
If H is sequential, -$ is a total order.
A history H is linearizabie if can be extended (by appending zero or more events) to some history H' such that: Ll: complete(H') is equivalent to some legal sequential history S, and L2: -$&4s Ll states that processes act as if they were interleaved at the granularity of complete operations.L2 states that this apparent sequential interleaving respects the real-time precedence ordering of operations.We call S a linearization of H.
The history H, shown in Section 2 is linearizable, because HI' = H, l q Ok() A is equivalent to the following sequential history: q EnWA q Ok0 A q End EJ qWlB q f-10 B (History H,') ci ok(x) B q Des0 A q ok(Y) A q Endz) A qCWA The following history, H,, is not linearfzabfe: q Ew(x) A qOkOA q End B qOWB q Da10 A q WY) A (History H.-J because the Enq of x precedes the Enq of y, but y is dequeued before x. Linearizability does not rule out histories such as the following history, Ha, in which an operation "takes effect" before its return event occurs: q EnqC4 A (History Ha) q DeqO B 9 Wx) B H, can be extended to H,' = H, * q Ok() A, which can be shown equivalent to the sequential history in which the enqueue operation occurs before the dequeue.
Lamport's notion of sequential consistency [17] requires that a history be equivalent to a sequential history.
Sequential consistency is weaker than linearizability, because it does not require the precedence ordering 4 to be preserved.For example, H, is sequentially consistent, but not linearirable.Serializability [26] requires that a history be equivalent to a sequential history in which each process (usually called a transaction) runs to completion without interleaving with other processes.' Lamport [19] has proposed that the standard definition of serializability be strengthened to preserve the order of non-overlapping transactions.Both notions of serializability are incomparable to linearizability.For example, H, is linearizable, but not serializable (in either sense), and H, is serializable, but not linearizable.

Locality
Linearizability is a lo&/ property.Theorem 1: H is linearizable if and OniY if HiX is linearizable at each object x.
Proof: The "only if" part is obvious.
From the assumption that each object's history is finearizable, there exists for each object x an induced totat ' In dat&$$e$, &aliz&ility is often provided in cot'@nCtion with fa&re amm'city, ensuring that a transaction intempted by B fi%lUfe Will hEWe no effect.
order Cx on its own operations, and by the well-formedness criteria for histories, each process P induces a total order <,, on its operations.We claim that the transitive closure of the union of all <x and $, is a partial order, +. and hence can be extended to a total order, <.Notice that each <x and <,, is compatible with 4.
Suppose 4 is not a partial order.Then we can construct a cycle e, l . . .l e,, where e, = en, such that e, + es 4 . . .-C e,, where ei-, and ei, 1 < i 5 n, are related by some Cx or $ The contradiction is immediate if no pair is related by a <p, because then all relations are induced by the same $, which is assumed to be a total order.Otherwise, the cycle of operations can be relabeled so that e, $, e2, for some process P. Because processes are sequential, the response of 8, precedes the invocation of ea, and because all relations are consistent with 4, the invocation of es precedes the response of en, which is identical to the response of 8,.Hence the response of e, precedes itself, a contradiction.I Henceforth, we consider only histories involving single objects, omitting object names from events.
Locality is important because it allows concurrent systems to be designed and constructed in a modular fashion; linearizable objects can be implemented, verified, and executed independently.A concurrent system based On a non-local correctness property must either rely on a centralized scheduler for all objects, or else additional constraints must be placed on objects to ensure that they follow compatible scheduling protocols.
Locality should not be taken for granted: the literature includes proposals for both alternative correctness properties that are not local.For example, Lamport's notion of sequential consistency is not a local property.Consider the following sequential history H, in which processes A and B operate on queue obiects p and q.For brevity, matching responses are shown on the same lines as invocations.HIP P Enq(x)/Ok() A q EnqWOW B q EWWOkO A P Enq(y)/Ok() B P DeqO/Ok(y) A q Deq()/Ok(x) B and Hlq are not legal sequential histories, but they are sequentially consistent, although H itself is not.Also, serializability and Lamport's strengthened notion Of serializability are both non-local.In the example above, Hip and Hjq are each serializable in either sense, but H itseff is not.

Linearized Values
Non-determinism is inherent in the notion of linearizability: (1) For each H, there may be more than one extension H' satisfying the two conditions, Ll and L2, and (2) for each extension H', there may be more than one linearization S. We call the value of an object at the end of a linearization a linearized value.Since a given history may have more than one linearization, an object may have more than one linearized value at the end of a history.We let In any derivation showing H is linearizable, the order in which Axiom C is applied to pending invocations induces a valid linearization ordering on the operations of H. Informally, the following lemma states that an operation must appear to "take effect" at some instant between its invocation and its reSpOflSe.
Lemma 2: Let 'inv A' be the ith event of H, and let the matching response 'res A' be the jth event.Any derivation showing that H is linearizable must include an application of Axiom C to infer: <v, P> f Possk =+ <v', P -{inv A}> E Pass, forsomek.isk<j.showing that <q, P> E Pass, is in canonical form if each Enq inference for an item in q occurs "as late as possible," i.e., it does not commute with the next inference in the derivation.
Lemma 9 implies that if x is in q, the event following the Enq inference for x is either the return event for x, or the return event for an item that follows x in q.
Lemma 9: If 6 is a canonical derivation showing that <q, P> E Pass,, and x is an item in q, then the inference following the Enq inference for x is either the Enq inference for the item following x in q, or an application of Axiom R for the matching response to Enq(x).
Proof: We show that x's Enq inference commutes with all other inferences.
Similar arguments show that x's i&q inference cAmmutes with all applications of Axiom I, and with a)l applications of Axiom R for non-matching response events.
Finally, we observe that any Enq inference for an item in q must follow all Enq inferences for items whose Deq inferences appear in 6.I Lemma 10 states that we can consider equivalence classes of queues rather than individual queues.
Lemma 10: If <q, P> E Pass,, and q* is a queue value constructed by rearranging the items of q in an order consistent with the partial precedence order of their Enq operations, then <q*, P> E Pass,.
Proof: We argue inductively that if there exists a canonical n-step derivation that <q, P> E Pass,, there also exists a canonical n-step derivation that <q*, P> E Pass,.
Base step: Trivial for n = 0 where q = emp.Induction hypothesis: If <q, P> E Pass, has a canonical derivation of length less than n, <q*, P> E Pass,.,, has a canonical derivation of the same length.
Induction step: Given an n-step canonical derivation 6 that <q, P> E Pass,, we construct an n-step canonical derivation 6' that <q*, P> E Pass,.If the last step of S is an application of Axiom I or R, then q,., = qn, and we have an n-l step canonical derivation that <q,, P,,,) E Poss,.,,,.The induction hypothesis yields an n-l step canonical derivation that <q* , PJ E Poss,~, , and reapplying the last inference yields a derivation that (q', P,,) E Pass,.
Otherwise, the last step of 6 is an Enq or Deq inference, which can be discarded to yield an n-l Step CanOniCal derivation that <q,., , P,,,> E Pass,.Suppose the discarded inference is an Enq inference for x by A. Define q,., * to be q* with x deleted from the queue.By the induction hypothesis, there exists an n-1 step canonical derivation a,-, l that <qh-, l , P,-,> < Pass,.If x is the last element in q*, then we construct 6' using Axiom C to enqueue x to q,,,*.Otherwise, let y be the item immediately following x in q', let B be the process that enqueued y, and let the jth inference of 6 ,,, l be the Enq inference for y.By Lemma 9, the next event in the history is the return event for some item z that follows x in q'.Since z's Enq operation is concurrent with x's Enq operation, 'Enq(x) A' E Pi'.We construct 6' as follows: all inferences before j are unchanged, and the jth inference of 6' is x's Enq inference: <qi*, Pi'> E Pass, =3 <ins(qi',x), Pi* -(Enq(x) A}> < Pass, which is justified because 'Enq(x) A' is in Pi'.For j < k < n, the kth inference of 6' is the (k.l)st inference of 6, with ins(qi+,x) substituted for qi* and P,' for Pk.To show that 6* is sound, we must check that each axiom's pre-condition is still satisfied.The result is immediate for applications of Axioms I and R, as well as for Enq inferences, since it is always legal to append an Enq to a history.For Deq inferences, we observe that every daqueued item was enqueued before x, hence at each Deq inference, the value at the front of the queue is unchanged.Finally, 6' is canonical because the Enq inferences for x and y do not commute.
Let R be a complete history for a queue representation, and let items(R) be the set of items stored in the array, but not swapped out.Let -+ be the partial order suck that x +R y if the STORE operation for x precedes the INC operation for y in R. If r is a linearized value for R, items(r) = items(R) corresponds to the set of non-null items in the array, and 4r = -$ is their partial order.Finally, we extend the trait of Figure 2-2 by defining the total order, <q, and the operator, items, such that: first(q) <q first(rest(cj)) items(emp) = {} items(ins(q, e)) = {e) U items(q) The implementation has the following rep invariant: 3(r) = (r.back 2 1) A (i 2 r.back s r.items[i]I null) A (Ibound(r.items)= 1) and the following abstraction function: A(r) = {q I items(r) = items(q) A +r E <J In other words, a queue representation value corresponds to the set of queues whose items are the items in the array, sorted in some order consistent with the precedence order of their Enq operations.Thus, our implementation allows for an item with a higher index to be removed from the array before an item with a lower index, but only if the items were enqueued concurrently.Proof: Pick any q E (I, +), and any q' f (I U (x}, 4).Since <q, P U (Enq(x) A]> c Pass, <ins(q,x), P> E POSS by Axiom C. Since ins(q,x) is an element of (I U {x}, 4), <q', P> E Pass by Lemma 10.I Lemma 12: If <(I, +), P U (Deq() A}> C Pass, then for all x such that x is a minimal element of I, <(I -{x), -4 P> C Pass.
Proof: Pick any q E (I,+) such that first(q) = x, and any q' E (I -1x1, -4.Since <q, P U {Oeq() A}> E Pass, <rest(q), P> E Pass by Axiom C. Since rest(q) is an element of (I - Lemma 13: Enq enqueues an item x that is maximal with respect to + Proof: Suppose not.Then after the STORE there exists some non-null item y such that x +r y.By definition of -$, we have that the STORE for x precedes the INC for y.Thus, index(q.items,x) < index(q.items,y).Since index(q.items,x) = q.back, then q.back < index(q.items,y).By the rep invariant, for all i, i 2 q.back, q.items[i] = null so that q.items[index(q.items,y)] = null, i.e., y = null, a contradiction.I Lemma 14: Deq removes and returns an item x that is minimal with respect to -$.Proof: Suppose not.Then there exists non-null Y such that Y +r X.For x to be returned from within the for loop, the SWAP of x must happen before the STORE of y.The STORE of x must happen before the SWAP of x and the 1NC Of x before the STORE of x, so then the INC of x must Occur before the STORE of y, which implies that x and Y are incomparable, a contradiction, I Here is a proof of correctness.
I-Thus, it can be conjoined to the pre-and post-conditions of Figure 5-2 as justified by the Owicki-Gries proof method [23].
Axioms I and R give us the result for abstract invocation and response events.
INC and FET'CH leave the abstraction function the same.Thus, we are left with two cases, STORE and SWAP.By Lemma 13 we know that STORE adds a maximal item and thus, we can apply lemma Ii to show that the subset property is preserved.Similarly, by Lemma 14 we know that SWAP removes a minimal item and thus, we can apply Lemma 12 to show that the subset property is preserved.
Proofs The axiomatic approach to specifying sequential programs has its origins in Hoare's early work on verification [13] and later work on proofs of correctness of implementations of abstract data types [14], where first-order predicate logic pre-and post-conditions are used for the specification of each operation of the type.The algebraic approach, which defines data types to be heterogeneous Owicki and Gries extended Hoare's axiomatic approach to handle concurrent programs [24] by including axioms for general concurrent programming language constructs.Apt et al.
[2] use a similar approach for CSP [15] in particular, These approaches differ from ours by focusing on control structures such as the parallel operator, leaving data uninterpreted.
Lamport [la] has proposed a model and assertion language for specifying properties of concurrent objects.His approach is more general than ours, as it addresses liveness as well as safety properties, and non-linearizable as well as linearizable behavior.Our approach, however, focuses exclusively on a subset of concurrent computations that we believe to be the most interesting and useful.Our notion of linearizability generalizes and unifies similar Misra [22] has proposed an axiomatic treatment of concurrent hardware registers in which the register's value is expressed as a function of time.Restricted to registers, our axiomatic treatment is equivalent to his in the sense that both characterize the full sat of linearizable register histories.
Theorems 3 and 4 capture two properties of Misra's registers.
Misra's explicit use of time in axioms is appropriate for hardware, where reasoning in terms of the register's hypothetical value is useful as a guide to hardware designers.
Our approach, however, is also appropriate for objects implemented in software, as we have found that reasoning directly in terms of partial orders generalizes more effectively to data types having a richer set of operations.

Discussion
Without linearizability, the meaning of an operation may depend on how it is interleaved with concurrent operations.
Specifying such behavior would require a more complex specification language, as well as producing more complex specifications (e.g., Lamport's [18]).Linearizability provides the illusion that each operation takes effect instantaneously at some point between its invocation and its response, implying that the meaning of a concurrent object's operations can still be given by pre-and post-conditions.
The role of linearizability for concurrent objects Is of leaving data uninterpreted, linearizability exploits the semantics of abstract data types; it permits a high degree of concurrency, yet it permits programmers to specify and reason about concurrent objects using known techniques from the sequential domain.Unlike alternative correctness conditions such as sequential consistency [17] or serializability [26], linearizability is a local property: a system is linearizable if each individual object is linearizable.Locality enhances modularity and concurrency, since objects can be implemented and verified independently, and run-time scheduling can be completely decentralized.Linearizability is a simple and intuitively appealing correctness condition that generalizes and unifies specifications to reason about object values.A specification is a set of axioms of the form: {PI op(args*)/term(res*) 101 where P is a precondition on the object's value and the argument values that must be met before an invocation, and Q is a post-condition on the object's value and the result values that is guaranteed to hold upon return for the given termination condition.Identifiers in args* and res* denote values of arguments and results.A sequential history H is legal if for all object subhistories, Hlx, of H, each operation in Hlx satisfies its axiomatic specification.The axioms presented in this paper are essentially Larch interface specifications [lo, 1 l] for operations of abstract data types.For example, axioms for the Enq and Deq operations for FIFO queues are shown in Figure 2-1.The queue's value before the operation is denoted by q and the value after the operation by q'.The post-condition for Enq states that upon termination, the new queue value is the old queue value with e inserted.Notice that the specification for Deq is partial: Deq is undefined for the empty queue.The assertion language for the pre-and post-conditions is based on the Larch Shared Specification Language.It is akin to algebraic specification languages and is used to describe the set of values of a typed object.The set of operators and their signatures following introduces defines a vocabulary of terms to denote values.For example, emp and ins(emp, 5) denote two different queue values.The set of equations following the constrains clause defines a meaning for the terms, more precisely, an equivalence relation on the terms, and hence on the valu& they denote.For example, from QVals, we could prove that re.st(ins(ins(emp, 3), 5) = ins(emp, 5).The generated by clause of QVals asserts that emp and ins are sufficient operators to generate all values of queues.Formally, it introduces an inductive rule of inference that allows one to prove properties of all terms of sort 0. We use the vocabulaty of traits to write the assertions in the preand post-conditions of a type's operations; we use the meaning of equality to reason about its values.Hence, the meaning of "ins" and " =" in Axiom E's post-condition isgiven by the trait OVaIs.

Figure
Figure 2-2: Trait for Queue Values Figure 3-1: Linearized Values response to Enq(x), both x and y must have been enqueued, although their order remains ambiguous until x is dequeued.
Figure 2-2.We make use of the following fact about queues:Lemma 5: If Q is a sequential queue history where x is enqueued before y, then ,x is not dequeued after y.Proof: From Axioms E and D. I a verification methodology for implementations of linearizable concurrent objects.We propose a model for data type implementations and define a correctness condition in Section 5.1.We give an example of a queue implementation and prove its correctness in Section 5.2.As a first step, let us review how to verify a sequential data type implementation [14,9].An implementation consists of an abstract type A, the type being implemented, and a representation (or rep) type R, the type used to implement A. The subset of R values that are legal representations is characterized by a predicate called the rep invariant, 9: R + bool.The meaning of a legal rep is given by an a&fraction function, A: R -+ A, defined only for values that satisfy the invariant.An abstract operation u is implemented by a sequence, p, of rep operations that carries the rep from one legal value to another, perhaps passing through intermediate values where the abstraction function is undefined.The rep invariant is thus part of both the precondition and post-condition for each operation's implementation; it must be satisfied between abstract operations, although it may be temporarily violated while an operation is in progress.An implementation, p, of an abstract operation, a, is correct if there exists a rep invariant, f, and abstraction function, A, such that whenever p carries one legal rep value r to another r', a carries the abstract value from A(r) to J(r').For sequential objects, the rep invariant must hold at the start and finish of each abstract operation, but it may bs violated while an operation is in progress.For concurrent objects, however, it no longer makes sense to View the object's representation as assuming meaningful values Only between abstract operations.Instead, operations must be implemented to behave correctly for rep values that reflect the incomplete effects of concurrent operations.To capture the effects of interleaving, the notions of rep invariant and abstraction function must be extended to encompass transient representation values reflecting the incomplete effects of concurrent operations.5.1.Definitions An implementation is a set of histories in which events of two objects, a representation object r of type R and an abstract object a of type A, are interleaved in a constrained way: for each history H in the implementation, (1) the subhistories Hlr and H(a satisfy the usual well-formedness conditions; and (2) for each process P, each rep operation in HIP lies within an abstract operation.Informally, an abstract operation is implemented by the sequence of rep operations that occur within it.An implementation is correct if for every history H in the implementation, H]a is linearizable.The rep invariant f must be continually satisfied and the abstraction function continually defined not only between abstract operations, but also between each step in the sequence of rep operations implementing an abstract operation.The non-determinism inherent in a concurrent computation gives our abstraction functions a different flavor from their sequential counterparts.We redefine the abstraction function so that it maps each rep value to a (nonempty) set of abstract values: A:R-t2A To show correctness, the verification technique for sequential implementations is generalized as follows.Assume that the implementation of r is correct, hence Hir is iinearizable for all H in the implementation.Let Lin(H(x) be the set of linearized values for x in H.Our verification technique focuses on showing the following property: For all r in Lin(Hlr), 3(r) holds and A(r) E Lin(l-ila) This condition implies that Lin(H(a) is non-empty, hence that Hla is linearizable.Note that the set inclusion is necessary in one direction only; there may be linearized abstract values that have no corresponding representation values.Such a situation arises when the representation "chooses" to linearize concurrent operations in one of several permissible ways.5.2.Queue Example Consider the following concurrent queue implementation.The representation is a record with two components: ifems 1s an array having a low bound of 1 and a (conceptually) infinite high bound, and back is the (integer) index of the next unused position in items.rep = record {back: int, items: array [i tern]}Each element of items is initialized to a special null value, and back is initialized to 1.
if x -= null then return(x) end end end end deq An Enq execution occurs in two atomic steps: an array slot is reserved by atomically incrementing back, and the new item is stored in items.* Deq traverses the array in ascending order, starting at index 1.For each element, it atomiCallY swaps null with the current contents.If the value returned iS not equal to null, Deq returns that value, otherwise it tries the next slot.If the index reaches back-i without enCOUntering a non-null element, the operation is restarted.All atomic steps can be interleaved with steps of other operations.

Figure 5 -
Figure 5-l shows a sequence of abstract operations of Figure 3-l along with their implementing sequence of rep operations.Column two is the set of abstracted linearized rep values.Column three is the set of linearized abstract values.Our correctness criterion requires showing that each set in column two is a subset of the corresponding set in column three.
(x}, 4) <q', P> E Pass by Lemma IO.I Lemma 11 will allow us to show that the set of linearized queue values does not change over a STORE operation and similarly, Lemma 12, for a SWAP operation, by using 4, for + and by recalling that for each <v, P> E Pass, v is a linearized value.We use the next two lemmas to satisfy the conditions of the previous two lemmas.
of non-interference between pre-and postconditions and that the rep invariant holds are straightforward.I An Aside: Handling Critical Regions An implementation without critical regions, such as the previous queue example, can be verified by defining a rep invariant that is continually satisfied, and an abstraction function that is continually defined.That is, each step of the sequence of representation operations implementing an abstract operation must preserve the rep invariant, and exactly one such step causes the operation's effects to become visible to other operations.If an operation creates a temporary inconsistency, perhaps hidden from concurrent operations by some form of critical region, then it may not be possible to define a meaningful abstraction function directly in terms of the representation.Such inconsistencies can be eliminated by augmenting the representation with appropriate auxiliary data, and similar proof techniques as used in our queue example can be used for verification, 6. Related Work algebras [3], uses axioms to specify properties of programs and abstract data types, but the axioms are restricted to equations.Much work has been done on algebraic specifications for abstract data types [l ,6,8, 29,4,5,28, 161; we use more recent work on Larch specifications [lo, 1 l] for sequential program modules.
notions found in specific examples in the literature.Lamport gives a specification for a linearizabte concurrent queue permitting one enqueuing process and one dequeuing process.The queue's state is defined as a COlleCtiOn Of Stats functions mapping time to algebraic values.One State function takes on queue values; it may change only while operations ace in progress.The values of the other State functions are used as control flags to prevent operations from taking effect more than once.His queue-valued state function roughly corresponds to our abstraction function except that the state function maps to a single queue value, not a set of queue values.His technique, therefore, could not be used to prove our queue implementation correct because of the inherent nondeterminism in our example.
Gottlieb et al. [7] have investigated architectural support for implementing concurrent objects without critical regions, an approach illustrated by our linearizable implementation of a FIFO queue.They present a linearizable implementation of a concurrent queue (different from ours).The correctness condition asserted for their queue, however, is the property stated in Theorem 6, which by itself is incomplete as a concurrent queue specification since it does not prohibit implementations in which enqueued items spontaneously disappear from the queue, or new items spontaneously appear.As shown by Theorems 7 and 8, such anomalous behavior is easily ruled out by our queue axioms and the assumption of linearizability.
analogous to the rote of serializability for data base theory: it facilitates certain kinds of formal (and informal) reasoning by transforming assertions about complex concurrent behavior into assertions about simpler sequential behavior.Like serializability, linearizability is a safety property; it states that certain interleavings cannot occur, but makes no guarantees about what must occur.Other techniques, such as temporal logic {27,25, l&18,21], must be used to reaSOn about liveness properties like fairness or priority.An implementation of a concurrent object need nOt realize all interleavings permitted by linearizability,.but all interleavings it does realize must be linearizable.The actual set of interleavings permitted by a particular implementation may be quite difficult to specify at the abstract level, being the result of engineering trade-offs at lower levels.As long as the object's client relies only on linearizability to reason about safety properties, the object's implementor is free to support any level of concurrency that appears to be cost-effective.Linearizability provides benefits for specifying, implementing, and verifying concurrent objects in multiprocessor systems.Rather than introducing complex new formalisms to reason directly about concurrent computations, we feel it is more effective to transform problems in the concurrent domain into simpler problems in the sequential domain.