Reasoning about Optimistic Concurrency Using a Program Logic for History (Extended Version)

Size: px
Start display at page:

Download "Reasoning about Optimistic Concurrency Using a Program Logic for History (Extended Version)"

Transcription

1 Reasoning about Optimistic Concurrency Using a Program Logic for History (Extended Version) Ming Fu 1, Yong Li 1, Xinyu Feng 1,2, Zhong Shao 3, and Yu Zhang 1 1 University of Science and Technology of China 2 Toyota Technological nstitute at Chicago 3 Yale University Abstract. Optimistic concurrency algorithms provide good performance for parallel programs but they are extremely hard to reason about. Program logics such as concurrent separation logic and rely-guarantee reasoning can be used to verify these algorithms, but they make heavy uses of history variables which may obscure the high-level intuition underlying the design of these algorithms. n this paper, we propose a novel program logic that uses invariants on history traces to reason about optimistic concurrency algorithms. We use past tense temporal operators in our assertions to specify execution histories. Our logic supports modular program specifications with history information by providing separation over both space (program states) and time. We verify Michael s non-blocking stack algorithm and show that the intuition behind such algorithm can be naturally captured using trace invariants. 1 ntroduction Optimistic concurrency algorithms [5, 6] allow concurrent access to shared data and ensure data consistency by performing dynamic conflict detection. These algorithms can be more efficient than coarse-grained lock-based synchronization if there is sufficient data independence. However, the design of the algorithms has to consider many more thread-interleaving scenarios than coarse-grained synchronization. The algorithms are usually complex and error-prone. Their correctness is usually far from obvious and is hard to verify too. As an example, Fig. 1 shows a non-blocking stack algorithm, where a stack is implemented as a linked list pointed by the Top pointer. t allows simultaneous read (line 4 and 13) and write (7, 15) of Top, and the conflict detection is done by the CAS (compare-and-swap) command. This algorithm has two subtle bugs. One is that t might be a dangling pointer when the dereference occurs in line 6. The other is the notorious ABA problem: suppose the top three nodes on the stack are A, B and C; Thread 1 callspop and reaches the end of line6; sotpoints to A and next points to B; then Thread 2 comes, pops A and B, and pushes A onto the stack; Thread 1 continues to execute line 7, where the comparison succeeds and Top is set to point to B, which is no longer on the stack.

2 pop(){ 01 local done, next, t; 02 done := false; 03 while (!done){ 04 t := Top; 05 if (t == null) return null; 06 next := t.next; 07 done := CAS(&Top, t, next); return t; push(x){ 10 local done, t; 11 done := false; 12 while (!done){ 13 t := Top; 14 x.next := t; 15 done := CAS(&Top, t, x); return true; Fig.1. A Buggy mplementation of Non-Blocking Stacks Here, we have to refer to the historical events to explain the problems above. t is not surprising that temporal reasoning is needed to argue for the correctness of such highly concurrent algorithms. Concurrent separation logic (CSL [12]) and rely-guarantee (R-G) based reasoning [7] are two well-studied approaches to concurrency verification. Previous work [13, 17] has shown that they can be used to verify fine-grained and optimistic algorithms. However, since assertions in these logics only specify program states (or state transitions in R-G reasoning), it is difficult to use them to express directly the temporal properties about the subtle interaction between threads. nstead, we have to introduce history variables to record the occurrence of certain events. This indirect approach to specifying historical events makes specifications and proofs complex, and in many cases fails to demonstrate the high-level intuition behind the design of the algorithms. n this paper, we propose a new program logic that uses invariants on historical execution traces to reason about optimistic concurrency algorithms. The logic extends previous work on R-G reasoning by introducing past tense temporal operators in the assertion language. t allows us to specify historical events directly without using history variables, which makes the verification process more modular and intuitive. Although it has also been observed before that past tense operators in temporal logic can be used to eliminate the need of history variables [9], developing a modular logic with temporal reasoning that is able to verify modern concurrent algorithms has so far been an open problem. Our logic inherits previous work on combining R-G reasoning with separation logic [3, 18, 2] to support modular verification. Separating conjunction in separation logic is now ined over assertions on execution histories instead of state assertions. The frame rule and the hide rule in the Local Rely-Guarantee (LRG) logic [2] the keys for modular verification are supported naturally in this new setting. We apply our new logic to reason about Michael s non-blocking stack algorithm [10] which uses hazard pointers to fix the buggy algorithm in Fig. 1.

3 (Expr) E ::= x n E+ E E-E... (Bexp) B ::= true false E=E E E... (Stmts) C ::= x:=e x:=[e] [E]:=E skip x:=cons(e,...,e) dispose(e) if B then C else C while B do C C C;C (Prog) W ::= t 1.C 1... t n.c n (ThrdD) t Nat Fig. 2. A Concurrent Programming Language (Store) s PVar fin nt (Heap) h Nat fin nt (State) σ Store Heap (Trace) T ::= (σ 0, t 0) :: (σ 1,t 1) :: :: (σ n,t n) (Trans) R, G P(Trace) Fig.3. Program States and Execution Traces We use trace invariants to capture the main intuition underlying the algorithm. The program specifications and proofs used in our logic are more intuitive than those from previous work [13]. They do not require history variables. Our logic also supports a new frame rule that further simplifies the proofs (e.g., for the retirenode function in Fig. 10) and makes the verification more modular. 2 A Concurrent Programming Language Figure 2 shows a simple concurrent language. The statements x := [E] and [E] := E are memory-load and store operations respectively; cons allocates fresh memory cells, and dispose frees a cell. The atomic block C executes C atomically. Other statements have standard meanings. A program W contains n parallel threads, each marked with a unique thread D (e.g., t i for C i ). Figure 3 ines program states and execution traces. The store s is a finite partial mapping from program variables to integers; the heap h maps memory locations (natural numbers) to integers. A program state σ is a pair (s, h). An execution trace T is a (nonempty) finite sequence (σ 0, t 0 ) :: (σ 1, t 1 ) :: :: (σ n, t n ). A pair (σ i, t i ) in a trace T means that a thread with D t i reached the state σ i after executing one step from the state σ i 1. Thread D t 0 can be any value. We use T.last to denote the last element in T. A trace (T ::(σ, t)) in the trace sets R and G is also used to model a single-step transition by the thread t that starts from T and reaches a new state σ. Figure 4 gives the rules modeling the operational semantics. The binary relation models a transition over states made by a primitive statement. The inition is standard and is omitted here. The relation lifts state transitions to transitions over traces. The thread D of the executing thread t is R recorded on the trace at the end of the transition. Finally, the relation

4 E s = l h(l) = n x dom(s) (x:=[e],(s, h)) (skip,(s{x n, h)) E 1 s = l E 2 s = n l dom(s) ([E 1]:=E 2,(s, h)) (skip, (s,h{l n)) E s unined or E s / dom(h) or x / dom(s) (x:=[e], (s,h)) abort E 1 s unined or E 2 s unined or E 1 s / dom(h) ([E 1]:=E 2,(s, h)) abort E s = n x dom(s) (x:=e,(s, h)) (skip,(s{x n, h)) E s unined or x / dom(s) (x:=e,(s, h)) abort {l,..., l + k 1 dom(h) = E 1 s = n 1... E k s = n k x dom(s) (x:=cons(e 1,..., E k ),(s, h)) (skip,(s{x l, h {l n 1,..., l+k 1 n k )) E j s unined (1 j k) or x / dom(s) (x:=cons(e 1,..., E k ),(s, h)) abort E s = l l dom(h) (dispose(e),(s, h)) (skip,(s, h/{l)) B σ.s = true (if B then C 1 else C 2, σ) (C 1, σ) E s unined or E s / dom(h) (dispose(e), (s, h)) abort B σ.s = false (if B then C 1 else C 2, σ) (C 2, σ) B σ.s unined (if B then C 1 else C 2, σ) abort B σ.s = true (while B do C, σ) (C;while B do C, σ) B σ.s = false (while B do C, σ) (skip, σ) (C, σ) (skip, σ ) ( C, σ) (skip, σ ) (skip;c, σ) (C, σ) T.last = (σ, ) (C, σ) (C, σ ) (t.c, T ) (t.c, T ::(σ,t)) B σ.s unined (while B do C, σ) abort (C, σ) abort ( C, σ) abort (C, σ) (C, σ ) (C;C, σ) (C ;C, σ ) T.last = (σ, ) (C, σ) abort (t.c, T ) abort (t 1.C 1... t i.c i... t n.c n, T ) (t i.c i, T ) abort (t 1.C 1... t i.c i... t n.c n, T ) (t i.c i, T ) (t i.c i, T ) R (t 1.C 1... t i.c i... t n.c n, T ) R abort (W, T ) (T ::(σ, t)) R R (W, T ::(σ,t)) Fig. 4. Operational Semantics

5 (StateAssert) P, Q ::= B emp h emp s own(x) E E P Q... (TraceAssert) p, q, R, G, ::= P d [p] t p q p p q X.p p p q... Fig. 5. The Assertion Language (s, h) = slemp s iff s = (s,h) = slemp h iff h = (s, h) = slown(x) iff dom(s) = {x (s, h) = sle 1 E 2 iff there exist l and n such that E 1 s = l, E 2 s = n,dom(h) = {l and h(l) = n σ = sl P Q iff there exist σ 1 and σ 2 such that σ 1 σ 2 = σ, σ 1 = SL P and σ 2 = SL Q x 1,..., x n, P O P emp = (own(x 1)... own(x n)) P = (own(x 1)... own(x n)) P where O = x 1,..., x n, = emp s emp h Fig.6. Semantics of Selected Separation Logic Assertions models the transitions over traces made by programs in an environment characterized by R. Here R contains all the possible transitions of the environment. 3 The Assertion Language Our assertion language is ined in Fig. 5. We use separation logic assertions (P and Q) to specify program states. Following Parkinson et al. [14], we also treat program variables as resources. Semantics of some separation logic assertions are shown in Fig. 6. We use σ 1 σ 2 to represent the union of the two disjoint states. Trace assertions. Trace assertions p, q, R, G and specify historical execution traces. Semantics of trace assertions are ined in Fig. 7. Here we use T to represent the length of T, and use T k to represent the subsequence resulting from truncating the last k elements from T (0 k < T ). A state assertion P is viewed as a trace assertion that specifies only the last state. Assertion d says that the last two states on the trace are the same (i.e. the last state transition is an identity transition). Assertion [p] t means that the trace satisfies p and the last state transition is made by the thread t. Assertion p q holds over T if and only if p holds over the trace T i for some i and q holds ever since. t is also represented as q S p (q since p) in the literature of temporal logic [9]. Assertion p holds if and only if the trace prior to the last transition satisfies p. p is the set of traces that satisfy p. Assertion p q lifts separating conjunction to traces; it specifies a program trace consisting of two disjoint parts: one satisfies p and another q. Traces T 1 and

6 T k = (σ 0,t 0):: ::(σ n k,t n k ) if T = (σ 0, t 0):: ::(σ n,t n) and 0 k n T =P iff there exists σ such that T.last = (σ, ) and σ = slp T =d iff there exist T and σ such that T = T ::(σ, )::(σ, ) T =[p] t T =p q iff iff T.last = (, t) and T =p there exists 0 < i < T such that T i =p and j < i. T j =q T = p iff 1 < T and T 1 =p p = {T T =p ((σ 0,t 0)::.. {.:: (σ n,t n)) ((σ 0,t 0)::...:: (σ m,t m)) ((σ0 σ 0,t 0)::...:: (σ n σ m,t n)) if n = m 0 i n.t i = t i = unined otherwise T =p q iff T =p q iff T =p or T =q there exist T 1 and T 2 such that T = T 1 T 2, T 1 =p and T 2 =q T =p q iff T =p and T =q p q p q = (p q) p p = p true p = ( p) = ( p q) p t q = p [q] t p q = t. p t q We assume unary operators ( and ) have higher precedence than other operators. Fig.7. Semantics of Trace Assertions T 2 are disjoint if they have the same length, and for each i such that 0 i < T the states in T 1 [i] and T 2 [i] are disjoint (see the inition of T 1 T 2 in Fig. 7). Other useful connectors can be ined using these primitive operators. Assertion p q is a weaker version of p q. Assertion p says that p was once true in the history. Assertion p holds if and only if p holds at every step in the history. Assertion p q says that p first came true in the history, and then q came true later. Assertion p t q means that the last transition is made by thread t, and assertion p holds prior to the transition, and q holds after it. This allows us to ine the built-in operator in LRG [2]. Example 3.1. n the TL2 transactional memory protocol [1], before updating a shared memory cell, we must first acquire the corresponding lock and then increase the global version clock. This requirement (among many others in the protocol) can be ined as the following guarantee: G tid(x) = D, D, T, T. ( ((x 0, D gt T) (x tid, D gt )) (x tid, D gt T ) (T > T) tid(x tid, D gt T ) Here x points to two fields, its lock and its value. The first line above says that, before the transition, the lock was acquired (it was changed from 0 to tid) when the global version clock gt was T. Then the lock and the value have been )

7 preserved ever since, but gt might have been changed. The second line says gt is greater than T right before the transition. The third line says the value of x is updated by the transition. This inition also implies that the increment of gt is done after the lock is acquired. The guarantee above refers to two events before the specified transition. n traditional R-G reasoning, the guarantee condition can only specify two states, so we have to introduce history variables to describe such historical events. As in separation logic, a class of trace assertions that are of special interest to us are those that are precise about the last state on the trace. Definition 3.2 (Last-State-Precise Trace Assertions). p is last state precise, i.e. LPrec(p) holds, if and only if for all T, t, s, h, s 1, s 2, h 1, h 2, if s 1 s, s 2 s, h 1 h, h 2 h, T ::((s 1, h 1 ), t) =p and T ::((s 2, h 2 ), t) =p, then s 1 = s 2 and h 1 = h 2. The example below shows a last-state-precise assertion p can specify a precise state domain that is determined dynamically by historical events. t is more powerful than a precise state assertion P in separation logic [16]. This can also be seen in our hazard-pointer-based stack example. Example 3.3. Let = X. (l X true) (l (X =0 r X 0 emp)) where r = x y, then is a last-state-precise trace assertion. t specifies traces where the domain of the last state depends on the historical value X of l. 4 A Program Logic for History Now we present our program logic for history, named HLRG, which extends the LRG logic [2] with trace assertions for reasoning about historical traces. f a statement C only accesses the private resource, it can be verified as sequential programs using a set of sequential rules, as shown in Fig. 8. The judgment for well-formed sequential programs is in the form of {P C{Q. Here P and Q are trace assertions which specify only the last state of the trace. Thus the rules are mostly standard separation logic rules except that program variables are treated as resources, following [14]. Note that, to prove {P C{Q, C cannot contain atomic statements. As in LRG, we use the judgments R; G {pw {q and R; G; t {pc{q for well-formed programs and well-formed thread t respectively. The rely condition R and the guarantee G specify the interference between the environment and the thread. The judgments say informally that starting from a trace satisfying both (R G) true and p, if the environment s transitions satisfy R, then W (or C) would not abort, its transitions satisfy G, and q holds at the end if W (or C) terminates. The invariant specifies the well-formedness of the shared resource. Unlike in the LRG logic, R, G,, p and q are all trace assertions now. Figure 9 gives the main inference rules. The prog rule allows us to verify the whole program by verifying the n parallel threads t 1.C 1,t 2.C 2,..., t n.c n

8 {x, O X = E emp h x:=e{x,o x = X emp h (assn) O E 1 E 2 = E 2 {O E 1 [E 1]:=E 2{O E 1 E 2 (st) {x, O x = X E Y x:=[e]{x, O x = Y [X/x]E Y (ld) {O E Y dispose(e){o emp h (disp) (x, O x = X emp h ) E 1 = E 1... E k = E k {x, O x = X emp h x:=cons(e 1,...,E k ) {x, O x = Y (Y [X/x]E 1... Y + k 1 [X/x]E k ) (cons) {P skip{p (skip) {P C 1{R {RC 2{Q {P C 1; C 2{Q (seq) {P C{Q {P RC{Q R (frm) P B = B {P BC 1{Q {P BC 2{Q {P if B then C 1 else C 2{Q (if) {P C{Q {P C{Q {P P C{Q Q (conj) P B = B {P BC{P {P while B do C{P B (while) P P {P C{Q Q Q {P C{Q (conseq) {P C{Q {P C{Q {P P C{Q Q disj {P C{Q { X.P C{ X.Q (exists) Fig.8. nference Rules of HLRG Program Logic (Sequential Rules) separately. Each thread t i has exclusive access to its own private resource specified by p i and q i. All threads can access the shared resource specified by r, r 1... r n. To verify each thread, we need to find an invariant specifying the basic well-formedness of the shared resource. The env rule says that if the shared resource is empty, i.e. all resources are thread-private, we can verify C following the sequential separation logic. The atom rule says that we can treat C in the atomic block as sequential code since its execution cannot be interrupted. Here the judgment {P C{Q can be derived following the standard sequential separation logic rules [16], which we do not show here. This rule allows us to strengthen P into a trace assertion p so that we can carry the historical information. The transition from p to Q needs to satisfy the guarantee G, which may have some constraints over the history traces (examples about G can be found in Fig. 11 in Sec. 5). The atom rule uses a strong rely condition about the environment, which is an identity transition preserving the invariant of the shared resource. To relax it, we can apply the next atom-r rule borrowed from RGSep [17]. t allows us

9 R G 1... G i 1 G i+1... G n; G i; ti {p i rc i{q i r i i {1,..., n r r 1... r n R;G 1... G n {p 1... p n rt 1.C 1... t n.c n{q 1... q n (r 1... r n) (prog) {P C{Q Emp;Emp;emp t {P C{Q (env) p P {P C{Q p t Q G true d ; G; t {p C {Q where Emp is ined as emp emp. (atom) where d is ined as d ( ). p p d ; G; t {p C {Q p Q q Sta({p,q, R d) R; G; t {p C {q (atom-r) R; G; t {pc{q Sta(r, R d) r true R R ; G G ; t {p rc{q r (frame) R; G; t {pc{q R; G; t {p rc{q r (framet) R; G; t {p ( true)c{q (R G) ( ) R; G; t {pc{q ( true) (inv) R R ; G G ; t {pc{q R; G; t {pc{q (hide) p (B=B) R;G; t {p BC{p R; G; t {pwhile B do C{p B (p-while) p (B = B) R; G; t {p BC 1{q R; G; t {p BC 2{q R;G; t {pif B then C 1 else C 2{q (p-if) R; G; t {pc 1{r R; G; t {rc 2{q R; G; t {pc 1;C 2{q (p-seq) Fig.9. nference Rules of HLRG Program Logic (Concurrency Rules) to adjust the pre- and post-conditions so that they are both stable with respect to the rely condition R. Definition 4.1 (Stability). We say a trace assertion p is stable with respect to a trace assertion q, i.e. Sta(p, q) holds, if and only if p q p. That is, if p holds before the most recent transition, and the transition satisfies q, then p holds after it. This is the standard requirement in R-G reasoning. With temporal operators, it can now be encoded as a temporal assertion. We use Sta({p, q, R) as a shorthand for Sta(p, R) Sta(q, R). The interesting (and new) part of this atom-r rule is the post condition q, which is weakened from the trace assertion p Q. This allows us to carry information about historical events happened before this atomic transition.

10 The frame rule comes from LRG. t supports local reasoning and allows us to write small specifications about resources that are indeed accessed in C. nvariants about other resources are preserved and can be added into the specifications later. We also introduce a new framet rule to show the frame property over time. Since historical traces would not affect the execution of programs, knowledge about history can be added when necessary. The new inv rule is also very useful. t is like the reverse of the standard consequence rule in Hoare logic, since it allows us to strengthen the pre-condition, and prove a post-condition weaker than we wanted. This rule is sound because the invariants and can be derived from the fact that each step of the transition satisfies R G, so that they can be used anywhere in the proof for free. We will demonstrate the use of frame, framet and inv in our example in Sec. 5. The rest of the rules are the same as those in LRG, and are not shown here. Note that in each rule we implicitly require the following properties hold. fence(, R) and fence(, G); p q true; where fence(, p) is ined below: fence(, p) = (d ( ) p) (p ) LPrec(). nformally, it requires that the most recent transition is confined in a precise domain enforced by the last-state-precise assertion. This constraint is inherited from LRG. nterested readers can refer to our previous work [2] to see the technical discussions about this requirement. Semantics and soundness. The semantics of our logic and its soundness proof are similar to those of LRG. The semantics for the judgement {P C{Q is shown in Definition 4.2, and and the soundness of sequential rules is formalized and proved following the standard way established in previous works on sequential Separation Logic[16]. Here we also can treat the trace assertions P and Q as state assertions, because they only specify the last state of the trace. Definition 4.2. = {P C{Q iff, for any T there exists t such that T = P, ((t.c, T ) abort), and, if (t.c, T ) (skip, T ), then T =Q. Lemma 4.3 (Seq-Soundness). f {P C{Q, then ={P C{Q Before we ine the semantics for the judgments R; G; t {pc{q and R; G {pw {q respectively, first we introduce the non-interference property. Definition 4.4 (Non-nterference). Let W = t 1.C 1... t n.c n. (W, T, R)= 0 G always holds. (W, T, R)= m+1 G holds iff (W, T ) and the following are true: R abort

11 1. for all t and σ, if (T ::(σ, t)) R, then for all k m, (W, T ::(σ, t), R)= k G; 2. for all σ and i {1,..., n, if (t i.c i, T ) (t i.c i, T ::(σ, t i )), then (T :: (σ, t i )) G and (t 1.C 1...t i.c i... t n.c n, T :: (σ, t i ), R) = k G holds for all k m. Then the semantics of R; G; t {pw {q is ined below. Theorem 4.10 shows the soundness theorem for well-formed threads. Definition 4.5. R; G; ={pw {q iff, for all T such that T =p ( (R G) true), the following are true (where R= R d and G = G true ): R 1. if (W, T ) (skip, T ), then T =q; 2. for all m, (W, T, R)= m G. The locality of sequential statements are shown by the following lemmas. Lemma 4.6 (Sequential Locality). f C has a thread D t and does not contain atomic blocks, and ((t.c, T 1 ) abort), then, for all T 2 and T = T 1 T 2, ((t.c, T ) abort) for all n and T, if (t.c, T ) n (t.c, T ), there exists T 1 such that T = T 1 T 2 and (t.c, T 1 ) n (t.c, T 1 ) Lemma 4.7 (Locality of atomic). f C = C,C has a thread D t and does not contain atomic blocks, and ((t.c, T 1 ) abort), then for all T 2 and T = T 1 T 2, ((t.c, T ) abort) for all T, if (t.c, T ) (skip, T ), there exists T 1 such that T = T 1 T 2 and (t.c, T 1 ) (skip, T 1 ) So (W, T, R)= n G means, starting from the trace T, W does not interfere with the environment s trace-based transitions in R up to n steps, and tracebased transitions made by W are in G. t also implies the parallel execution of W does not abort within n steps, as Lemma 4.8 shows. Lemma 4.8. f (W, T, R)= m G, there does not exist j such that j < m and (W, T ) R j abort. Proof: Suppose W = t 1.C 1... t n.c n, we do induction over m. t is trivial when m = 0. Suppose it is true when m = k, we prove it still holds when m = k+1. Suppose (W, T, R) = k+1 G, we need to prove there does not exists j k + 1 such that (W, T ) R j abort. Then we need to prove the following cases: 1. for all σ and t such that (T, (σ, t)) R, there does not exists j k such that (W, T ::(σ, t)) R j abort;

12 2. for all t {1,...n such that ((t.c, T ) abort); 3. for all σ and t {1,...n such that (t.c, T ) (t.c, T ::(σ, t)), there does not exists j k such that (W, T ::(σ, t))) R j abort We first prove 1. By (T, σ) R, (W, T, R)= k+1 G, and Def. 4.4, we know (W, T :: (σ, t), R) = k G. By the induction hypothesis we know there does not exists j k such that (W, T ::(σ, t)) R j abort; The proof of 2 trivially follows (W, T, R)= k+1 G and Def To prove 3, By (t.c, T ) (t.c, T ::(σ, t)), (W, T :: (σ, t), R) = k+1 G, and Def. 4.4, we know(w, T ::(σ, t), R)= k G. Then by the induction hypothesis we can prove there does not exists j k such that (W, T ::(σ, t)) R j abort. Then the semantics of R; G; t {pc{q is ined below. Theorem 4.10 shows the soundness theorem for well-formed threads. Definition 4.9. R; G; = t {pc{q iff, for all T such that T =p ( (R G) true), the following are true (where R= R d and G = G true ): R 1. if (t.c, T ) (skip, T ), then T =q; 2. for all m, (t.c, T, R)= m G. Theorem 4.10 (Thrd-Soundness). f R; G; t {pc{q then R; G; = t {pc{q. Theorem 4.10 is proved by induction over the derivation of the judgment R; G; t {pc{q. The whole proof consists of the soundness proof for each individual rules. Here we only present the proofs for soundness of the atomicr,atomic, frame-t and inv rules, the proof for the soundness of the other rules are similar to that in LRG. We omit them here. Soundness of the atomic-r, atomic, frame-t and inv rules Suppose the atomic-r, atomic rules are applied to derive R; G; t {p C {q We want to prove R; G; = t {p C {q. By inversion of the atomic-r rule we know p p, d ( ); G; t {p C {Q p Q q and Sta({p, q, R d). Lemma 4.11 (ATOMC-R-Sound). if p p, d ( ); G; = t {p C {Q p Q q and Sta({p, q, R d). then R; G; = t {p C {q. Proof: By Def. 4.4 we need to prove that, for all T, if the following is true: then we have T =p ( (R G 1 G 2 ) true) (1) if (t. C, T ) R (skip, T ), then T =q; (2) for all n, (t. C, T, R)= n G.

13 By (4) and p p, we know T =p ( (R G 1 G 2 ) true). By Def. 4.4 and (t. C, T ) R (skip, T ) we know T =Q and for all n, (t. C, T, d))= n G. By T = p and T ::(σ, t) = Q where σ = T.last we know T = p Q, thus we have T =q, (1) is proved. Because p and q are stable under R d, we know for all n, ( C, T, R)= n G, thus (2) is proved. Similarly, by inversion of the atomic rule we know p P, {P C{Q, p t Q G true. Lemma 4.12 shows the soundness proof for this rule. Lemma 4.12 (ATOMC-Sound). if p P, = {P C{Q and p t Q G true, then d ( ); G; ={p C {Q Proof: By Def. 4.4 we need to prove that, for all T, if the following is true: then we have T =p ( (R G 1 G 2 ) true) (1) if (t. C, T ) d (skip, T ), then T =Q; (2) for all n, (t. C, T, d)= n G. By Def. 4.4 and p P we know T = P, by the inition for the semantics of sequential rules, we know that T = Q, thus (1) is proved. By Def. 4.4 and p t Q G true, we can prove (2). Suppose the frame-t rule is applied to derive R; G; t {p rc{q r We want to prove R; G; = t {p rc{q r. By inversion of the frame-t rule, we know R; G; t {pc{q. We show the soundness proof of this rule in Lemma Lemma 4.13 (FRAME-T-Sound). if R; G; = t {pc{q then R; G; = t {p rc{q r. Proof: By Def. 4.4 we need to prove that, for all T, if the following is true: then we have T =p r ( (R G 1 G 2 ) true) (1) if (t.c, T ) R (skip, T ), then T =q r; (2) for all n, (t.c, T, R)= n G. By (4) we know T =p, then by Def. 4.4 we can get T =q, thus from T = r we know T = r, that is because history will never be changed. Then we know T =q r is true, (1) is proved. (2) trivially follows Def Suppose the inv rule is applied to derive R; G; t {pc{q ( true) We want to prove R; G; = t {pc{q ( true). By inversion of the inv rule, we know R; G; t {p ( true)c{q, (R G) ( ). We show the soundness proof of this rule in Lemma Lemma 4.14 (NV-Sound). if R; G; = t {p ( true)c{q and (R G) ( ) then R; G; = t {pc{q ( true)

14 Proof: By Def. 4.4 we need to prove that, for all T, if the following is true: then we have T =p ( (R G 1 G 2 ) true) (1) if (t.c, T ) R (skip, T ), then T =q ( true); (2) for all n, (t.c, T, R)= n G. By (4) we know T = p and T = ( (R G 1 G 2 ) true), we also have (R G) ( ), thus T =p ( true), by Def. 4.4 we have T =q. t is trivial to prove that T =( (R G 1 G 2 ) true), thus we know T = true, then we can prove (1). (2) trivially follows Def Then the semantics of R; G {pw {q is ined below. Theorem 4.16 shows the soundness theorem of the logic. Definition R; G ={pw {q iff, for all T such that T =p ( (R G) true), the following are true (where R= R d and G = G true ): R 1. if (W, T ) (skip, T ), then T =q; 2. for all m, (W, T, R)= m G. Theorem 4.16 (Soundness). f R; G {pw {q then R; G ={pw {q. By inversion of the prog rule we know for all i {1,..., n, R G 1... G i 1 G i+1... G n ; G i ; ti {p i rc i {q i r i, fence(, R) and r r 1... r n. By applying thread soundness Lemma 4.10, we know R G 1... G i 1 G i+1... G n ; G i ; = ti {p i rc i {q i r i, and fence(, R G 1... G i 1 G i+1... G n ) Let R i = R G 1... G i 1 G i+1... G n d,r= R d and G i = G i. Before we prove the soundness lemma, we can prove the following Lemmas 4.17,4.18 and Lemma For all i {1,...,n, m, t i.c i,t i and T r, if 1. (t i.c i, T i T r, R i )= m G i 2. (W, T 1... T n T r ) R m+1 (skip, T ) 3. T r = then there exists T 1, T 2,...,T n and T r, such that T = T 1 T 2... T n T T r =, for all i {1,..., n, (t i.c i, T i T r ) m Ri (skip, T i T r) Proof: Prove by induction over m. For the base case (m = 0), we know all C i are all skip. Then the proof is trivial. Suppose m = k + 1. Since (W, T 1... T n T r ) R m+1 (skip, T ) there are possible n + 1 cases: 1. (t i.c i, T 1 T 2... T n T r ) (t i.c i, T ) and (W, T ) R m (skip, T ) r,

15 2. T = T 1 T 2... T n T r ::(, σ ) and T R and (W, T ) R m (skip, T ) For case 1, by (t i.c i, T i T r, R i )= m G i we know ((t i.c i, T i T r ) abort). By Lemmas 4.6 and 4.7, we know there exists T x such that T = T x T 1... T i 1 T i+1... T n, and (t i.c i, T i T r ) (t i.c i, T x). By (t i.c i, T i T r, R i )= m G i we know T x G i and (t i.c i, T x, R i )= k G i. Since fence(g i, ), we know there exist T i and T r such that T x = T 1 T r for all j and j i we have T j T r R j and (t j.c j, T j T and T r =. Therefore r, R j )= k G j. By the hypothesis we know there exist T i and T r such that T = T 1... T n T r, T r =, we can conclude that for all i {1,...,n, (t i.c i, T i T r ) m Ri (skip, T i T r ) For Case 2, by T R, we know there exist T r such that T = T 1... T n T r and T r =, By (t i.c i, T i T r, R i ) = m G i we know (t i.c i, T i T r, R i ) = k G i. By the hypothesis we know there exist T i and T r such that T = T 1... T n T r, T r =, we can conclude that for all i {1,...,n, (t i.c i, T i T r ) m Ri (skip, T i T r ) Lemma For all m, i, t i.c i, T i, T r and T if 1. T = T 1... T n T r 2. (t i.c i, T i T r, R i )= m G i 3. T r = then (W, T, R)= m G Proof: Prove by induction over m. The base case (m = 0) is trivial. Suppose m = k+1. We can easily construct the proof based on Def. 4.4 Lemma 4.19 (Prog-sound). f for all i {1,...,n, R G 1... G i 1 G i+1... G n ; G i ; ={p i rc i {q i r i then R; G 1... G n = {p 1... p n rt 1.C 1... t n.c n {q 1... q n (r 1... r n ) Proof: By Definition 4.15, we need to prove that, for all trace T, if T = p 1... p n r we have R 1. if (W, T ) (skip, T ), then T =q 1... q n (r 1... r n ) 2. for all m, (W, T, R)= m G By T = p 1... p n r we know there exist T 1, T 2,..., T n and T r such that T = T 1 T 2... T n T r, T r =, for all i {1,...,n, T i =p i. By R G 1... G i 1 G i+1... G n ; G i ; ={p i rc i {q i r i we have: (a) for all T R, if (t i.c i, T i T r ) (skip, T ) then T =q i r i (b) for all m i, (t i.c i, T i T r, R i )= m G i By (b) and Lemma 4.17 we know there exist T 1, T 2,..., T n and T r such that T = T 1 T 2... T n T r, T r =, for all i {1,...,n, (t i.c i, T i T r ) m Ri (skip, T i T r ). By (a) we know T i T r =q i r i. Since r 1... r n and LPrec(), we have T 1 T 2... T n T r =q 1... q n (r 1... r n ). Thus 1 is proved. The proof of (2) follows (b) and Lemma 4.18.

16 pop(){ 01 local done, next, t, t1; 02 done := false; 03 while (!done){ 04 t := Top; 05 if (t == null) return null; 06 HP[tid] := t; 07 t1 := Top; 08 if (t == t1){ 09 next := t.next; 10 done := CAS(&Top, t, next); retirenode(t); 14 HP[tid] := null; 15 return t; retirenode(t){ 16 local i, t ; 17 i := 1; 18 while(i<=th_num){ 19 if (i!= tid){ 20 t := HP[i]; 21 if (t!= t){ 22 i:= i+1; else i:= i+1; 25 Fig.10. Optimistic Lock-Free Stacks with Hazard Pointers 5 Verification of Lock-Free Stacks with Hazard Pointers We now apply HLRG to verify Michael s lock-free stacks, which use hazard pointers [10] to address the problems with the algorithm in Fig. 1. n Fig. 10 we show the new pop function. The push function is the same as in Fig. 1 and is omitted here. We use stack(top, A) below to specify the shared stack, which is implemented as a linked list pointed by Top. The set A records the memory locations of the nodes on the list. t is kept to simplify our proofs. Below we use E E 1, E 2 as a shorthand for E E 1 E+1 E 2, and E for n. E n. List(l,, nil) = emp l = null List(l,A, n::l) = l A l.(l n, l ) List(l, A {l, L) stack(top, A) = l, L. (Top l) List(l, A,L) (1) The algorithm fixes the ABA problem by using a global array HP, which contains a hazard pointer for each thread. The array is specified by hp (HP). Here HP+tid is the location of HP[tid], and th num is the number of threads. hp (HP) = tid [1..th num].hp+tid (2) where x s.p(x) = s = emp z.(s = {z s ) ( x s.p(x)) p(z) and is the union of disjoint sets. Before a racy access to the top node on the stack, a thread stores the node s memory location into its HP entry (lines 06-08). This announces to other threads that the node is being accessed and should not be reclaimed. When a node is successfully removed from the stack (line 10), the remover thread calls retirenode (line 13) and waits till after this node is no longer being accessed by any other

17 threads (i.e., not pointed by their HP entries). Finally, it clears its own HP entry (line 14) before it obtains the full ownership of the node (line 15). We use remove(l,top,hp,tid) in (3) to specify that the thread tid is in the remove phase: it has popped the node at l from the stack, but has not reached line 14 yet. The part in front of says that there was a primitive operation in history, which popped the node from the stack. The operator and the assertion following it require that the removed node be pointed by the remover s own HP entry ever since. Here E 1 E 2 is a shorthand for (E 1 E 2 ) true. The predicate not rem(top,hp,tid) in (4) says that tid is currently not in the remove phase. remove(l,top,hp,tid) ( = (3) ((HP+tid l Top l) tid (HP+tid l l.top l l l )) HP+tid l ) l null not rem(top,hp,tid) = l. remove(l, Top, HP, tid) (4) n addition to the stack and thehp array, the popped nodes that are accessible from the hazard pointers should be viewed as shared resources as well. We use opset(top,hp, S, O) in (5) to iterate these shared nodes, where O is the set of pointers pointing to these nodes and S is the set of threads. opset(top,hp,, ) = true (5) opset(top,hp, {tid S, O) = ( l.remove(l,top,hp,tid) l O opset(top,hp, S, O {l)) (not rem(top,hp,tid) opset(top,hp, S, O)) The invariant below specifies all three parts of the shared resources. is a last-state-precise assertion. The domain of the shared resource depends on the historical information whether nodes are popped before or not. = O. opset(top,hp,[1..th num], O) ( hp (HP) A.stack(Top, A) ( l O. l, )) (6) Below we characterize the meaning of hazard pointers. ishazard(l, Top, HP, tid) says HP[tid] contains a confirmed hazard pointer l, i.e. l was once the top of the stack in history and the thread tid has not updated the Top pointer ever since (though Top might have been updated by other threads). When the remover thread invokes retirenode on the top node t, it scans the hazard pointers of all other threads and make sure that ishazard(t,top,hp,tid) does not hold for each non-remover thread tid. This is specified by hazfree(t, Top, HP, tid), which says that the node t has been popped by the thread tid and other threads no longer treat it as a hazard node. upd top(tid) = l,l.(top l tid Top l ) l l ishazard(l,top,hp,tid) = (7) (HP+tid l Top l) ( (HP+tid l) upd top(tid) ) hazfree(l,top,hp,tid) = (8) remove(l,top,hp,tid) tid [1..th num].tid =tid ishazard(l,top,hp,tid )

18 Pop tid = l,l. ((Top l) (HP+tid l) (l, l ) List(l,, )) ((Top l tid Top l ) d) (line 10) Retire tid = l. hazfree(l,top,hp,tid) (((HP+tid l l, ) tid HP+tid null) d) (line 14) Reset HP tid = not rem(top,hp,tid) ((HP+tid tid HP+tid ) d) (line 06) Push tid = (Top l tid (Top l l, l)) d (line 15 in Fig. 1) G tid = (Retire tid Pop tid Push tid Reset HP tid d) ( ) R tid = tid [1..th num] tid =tid Gtid Fig.11. Transitions over Shared Resources, and R-G Specifications Comparing with the proof in [13], they use auxiliary hazard-status array HP and corresponding codes highlighted by the shadow to identify confirmed hazard pointers. The segment of the modified algorithm are listed as below: pop(){ 03 while (!done){ <HP[tid] := t; HP [tid] := Req >; 07 <if (Top!= t) continue; else HP [tid] := Tail(t.Next) >; 08 <next := t.next; if (HP [tid]!= Tail(next)) HP [tid] := Left >; 09 <done := CAS(&Top, t, next)>; Four different states (Unset,Req,Tail(k),Left) are introduced to indicate the status of hazard pointers. The essential purpose of using the inserted auxiliary code is to identify confirmed hazard pointers which must be in Tail(k) or Left state. As we explained before, the temporal assertion ishazard(l,top,hp,tid) is able to achieve this in a direct way. The call to retirenode is crucial. As we will show below, it ensures that a confirmed hazard pointer cannot be a dangling pointer, and a popped node pointed by any confirmed hazard pointers cannot show up on the stack again (thus the ABA problem is avoided). Verification of the Algorithm. We first ine in Fig. 11 all the operations over the shared data structure, and show which line of the code makes the corresponding transition (read-only operations are simply d transitions and are omitted). Pop tid pops the top node from the stack. t requires that the hazard pointer point to the top of the stack. Retire tid sets the value of HP[tid] into null, knowing that the popped node is no longer a hazard node. Then the node

19 l is converted logically from shared resource to private. Reset HP tid resets the hazard pointer when the threadtid fails to pop a node. Push tid pushes a private node onto the stack. We also ine the rely (R tid ) and guarantee (G tid ) of the thread tid. Here (ined in (6)) is used to fence the domain of all possible actions. t is easy to see fence(, R tid ) and fence(, G tid ) are satisfied. Next we show some key trace invariants derivable from (R tid G tid ). They are used when the inv rule is applied. Also they show the key intuition of the algorithm. nvariant 1. This invariant ensures that a node pointed by a hazard pointer is either on the stack or in the set O, so it is safe to dereference a hazard pointer. l,tid, A,O. ishazard(l,top,hp,tid) opset(top,hp,[1..th num], O) (stack(top, A) true) l null l A l O nvariant 2. f a thread tid once held a hazard pointer pointing to the top of the stack, and the top node on the stack was popped by other threads, then the node will not be on the stack again as long as tid s HP entry is not changed. This invariant ensures that there are no ABA problems. l, A, A,tid. ( (ishazard(l,top,hp,tid) (stack(top, A) true)) HP+tid l ) (stack(top, A ) true) l null l A l A nvariant 3. This invariant justifies the retirenode procedure. f the thread tid popped a node l and its HP entry points to the node, then for all other thread tid its hazard pointer cannot point to the node and becomes a confirmed hazard pointer again if it was set to point to a different node (l ) in history. l, ( l,tid,tid. ) remove(l,top,hp,tid) (HP+tid l ) l l ishazard(l,top,hp,tid ) HP+tid l We show the proof sketch for pop in Fig. 12. Here p is used as a shorthand for (p true). The precondition of pop requires that the invariant hold over the shared resources, and that the calling thread s HP entry be initialized to null. The post-condition says holds at the end; the stack was either empty or the node t was popped out of the stack and is now part of the local resource of the calling thread. The proof sketch for retirenode is given in Fig. 13. Most part of the proof simply follows the rules of the logic. The interesting part is that the specification of retirenode does not mention the linked list and the nodes in opset. Neither does it need to know that the pop operation has been done ( n, l. POP tid(t, n, l )). The knowledge can be added back by applying the frame and framet rules respectively before we compose retirenode with pop (see Fig. 12). The push procedure has nothing to do with hazard pointers, thus the proof shown in Fig. 14 is trivial and we omit to explain it.

20 POP tid(l, n, l ) = ((Top l) (l n, l ) List(l,, )) ((Top l tid Top l ) d) pop(){ { HP+tid null 01 local done, next, t, t1; 02 done := false; { HP+tid null done { not rem(top,hp,tid) loop invariant: { not rem(top, HP, tid) done done n, l. POP tid(t, n, l ) (remove(t,top,hp,tid) (t n, l )) 03 while (!done){ { not rem(top, HP, tid) 04 <t := [Top]>; 05 if (t == null) return null; 06 <HP[tid] := t>; { l. not rem(top,hp,tid) HP+tid l 07 <t1 := [Top]>; Apply atom-r and atom t = l l null { l, l. not rem(top,hp,tid) (HP+tid l Top l ) { l, l. l = l ishazard(l,top,hp,tid) 08 if (t == t1){ { l. ishazard(l, Top, HP, tid) t = l l null Apply inv with nvariant 1 { l, n, l. ishazard(l,top,hp,tid) l n, l t = l 09 <next := t.next>; t = l l null t1 = l { l, n, l. ishazard(l,top,hp,tid) l n, l t = l next = l done t=l l null t1=l 10 <done := CAS(&Top, t, next)>; Apply inv with nvariant { n, l. POP tid(t, n, l ) (remove(t,top,hp,tid) (t n, l )) 13 retirenode(t); Apply frame and framet { n, l. POP tid(t, n, l ) (hazfree(t,top,hp,tid) (t n, l )) 14 <HP[tid] := null>; Apply atom-r and atom { n, l. POP tid(t, n, l ) 15 return t; { List(null, nil) (t n, l ) t = null n, l. POP tid(t, n, l ) Fig.12. Verification of pop (t n, l )

21 thp = (Top ) hp (HP) rn = remove(t,top,hp,tid) thp selfornothazard(i) = tid [1..i 1].tid =tid ishazard(t,top,hp,tid ) retirenode(t){ { rn 16 local i, t ; 17 i := 1; loop invariant: {i th num+1 selfornothazard(i-1) 18 while(i<=th_num){ 19 if (i!= tid){ 20 <t := HP[i]>; 21 if (t!= t) { { ( l.hp+i l (i tid l t)) selfornothazard(i-1) i th num Apply inv with nvariant 3 {selfornothazard(i) i th num 22 i := i+1; else i:= i+1; 25 {selfornothazard(th num+1) { hazfree(t, Top, HP, tid) thp rn Fig.13. Verification of retirenode 6 Related Work and Conclusions Assume-Guarantee (A-G) reasoning [11, 15] often views a concurrent program as an invariant maintainer instead of a predicate transformer [8], especially for safety verification. With this view, sequential composition of programs seems always trivial and is rarely discussed in previous work on A-G reasoning. R-G reasoning [7], on the other hand, decomposes specifications into program invariants (R and G) and Hoare-style pre- and post-conditions, which gives us a predicate transformer view of programs. With this view, sequential composition of programs (C 1 ; C 2 ) is no longer trivial. For instance, to use the post condition q of C 1 as the pre-condition of C 2 as in Hoare Logic, we need to ensure the stability of q. Our logic is an extension of R-G reasoning. We take this predicate transformer view of programs, and try to spell out the details of the verification step associated with each program construct. Also, our logic successfully combines separation logic and temporal reasoning, which gives us better modularity. The two different frame rules in our logic reflect the frame properties over space (program states) and time respectively. Gotsman et al. [4] introduced temporal operators in RGSep [18] to reason about liveness properties of non-blocking algorithms. They do not use any past tense operators. Their temporal operators were only used in their rely and guarantee conditions, but not in the pre- and post-conditions. Since the frame rule

22 PUSH tid(l,n, l ) = (Top l (Top l l n, l)) d stk = A.stack(Top, A) push(x){ { stk x,null 10 local done, t; 11 done := false; loop invariant: {( stk x,null done) ( l,v. PUSH tid(l,v,x) 12 while (!done){ { stk,null 13 <t := Top>; 14 x.next := t; stk ) done) { (Top t) x,t stk 15 <done := CAS(&Top, t, x)>; Apply atom-r and atom 16 { l,v. PUSH tid(l,v,x) 17 return true; stk Fig.14. Verification of push over R and G was not used there, the interoperability between temporal operators and separation logic operators was not discussed. Parkinson et al. [13] used CSL to verify safety of the same stack algorithm we verified here. The specifications makes heavy uses of history variables. We believe that our specifications reflect the intuition of the algorithm more directly. Vafeiadis [17] applied RGSep to verify several non-blocking stack algorithms, which all rely on garbage collectors to avoid the ABA problem. t is unclear how the specification of Michael s stacks would look like in RGSep. Conclusion. n this paper we have proposed a new program logic HLRG, which combines R-G reasoning with past tense temporal assertions to reason about optimistic concurrency algorithms. Our new logic supports modular verification, including the frame rules over both the separation logic and temporal operators. We have verified Michael s lock-free stack with hazard pointers and show that our history logic can directly capture the high-level intuition about the algorithm. Acknowledgments. We thank anonymous referees for their comments on this paper. Ming Fu and Yong Li are supported in part by China Scholarship Council and by National Natural Science Foundation of China under grant No Much of this work was done during their visits to Yale University in Zhong Shao is supported in part by NSF grants CNS , CNS ,

23 and CCF Xinyu Feng is supported in part by National Natural Science Foundation of China under grant No References [1] D. Dice, O. Shalev, and N. Shavit. Transactional locking. n Proc. 20th nt l Symp. on Distributed Computing (DSC 06), pages , [2] X. Feng. Local rely-guarantee reasoning. n Proc. 36th ACM Symp. on Principles of Prog. Lang., pages ACM Press, Jan [3] X. Feng, R. Ferreira, and Z. Shao. On the relationship between concurrent separation logic and assume-guarantee reasoning. n Proc. 16th European Symposium on Programming (ESOP 07), volume 4421 of LNCS, pages Springer-Verlag, March [4] A. Gotsman, B. Cook, M. J. Parkinson, and V. Vafeiadis. Proving that nonblocking algorithms don t block. n Proc. 36th ACM Symp. on Principles of Prog. Lang., pages ACM, [5] M. Herlihy. Wait-free synchronization. ACM Trans. Program. Lang. Syst., 13(1): , [6] M. Herlihy and J. E. B. Moss. Transactional memory: Architectural support for lock-free data structures. n Proc. 20th Annual nt l Symp. on Computer Architecture (SCA), pages , [7] C. B. Jones. Tentative steps toward a development method for interfering programs. ACM Trans. on Programming Languages and Systems, 5(4): , [8] L. Lamport and F. B. Schneider. The Hoare Logic of CSP, and all that. ACM Trans. Program. Lang. Syst., 6(2): , [9] O. Lichtenstein, A. Pnueli, and L. D. Zuck. The glory of the past. n Proc. Conf. on Logic of Programs, volume 193 of LNCS, pages Springer, [10] M. M. Michael. Hazard pointers: Safe memory reclamation for lock-free objects. EEE Trans. Parallel Distrib. Syst., 15(6): , [11] J. Misra and K. M. Chandy. Proofs of networks of processes. EEE Trans. Software Eng., 7(4): , [12] P. W. O Hearn. Resources, concurrency and local reasoning. n Proc. 15th nt l Conf. on Concurrency Theory (CONCUR 04), pages 49 67, [13] M. Parkinson, R. Bornat, and P. O Hearn. Modular verification of a non-blocking stack. n Proc. 34th ACM Symp. on Principles of Prog. Lang., pages ACM Press, Jan [14] M. J. Parkinson, R. Bornat, and C. Calcagno. Variables as resource in hoare logics. n Proc. 21st Annual EEE Symposium on Logic in Computer Science (LCS 06), pages EEE Computer Society, August [15] A. Pnueli. n transition from global to modular temporal resoning about programs. n K. R. Apt, editor, Logics and Models of Concurrent Systems, NATO AS Series, pages Springer-Verlag, [16] J. C. Reynolds. Separation logic: A logic for shared mutable data structures. n Proc. 17th Annual EEE Symposium on Logic in Computer Science (LCS 02), pages EEE Computer Society, July [17] V. Vafeiadis. Modular fine-grained concurrency verification. PhD thesis, Computer Laboratory, University of Cambridge, Cambridge, UK, July [18] V. Vafeiadis and M. Parkinson. A marriage of rely/guarantee and separation logic. n Proc. 18th nt l Conf. on Concurrency Theory, pages , 2007.

Local Rely-Guarantee Reasoning

Local Rely-Guarantee Reasoning Technical Report TTIC-TR-2008-1 October 2008 Local Rely-Guarantee Reasoning Xinyu Feng Toyota Technological Institute at Chicago feng@tti-c.org ABSTRACT Rely-Guarantee reasoning is a well-known method

More information

Local Rely-Guarantee Reasoning

Local Rely-Guarantee Reasoning Local Rely-Guarantee Reasoning Xinyu Feng Toyota Technological Institute at Chicago Chicago, IL 60637, U.S.A. feng@tti-c.org Abstract Rely-Guarantee reasoning is a well-known method for verification of

More information

Verifying Concurrent Memory Reclamation Algorithms with Grace

Verifying Concurrent Memory Reclamation Algorithms with Grace Verifying Concurrent Memory Reclamation Algorithms with Grace Alexey Gotsman, Noam Rinetzky, and Hongseok Yang 1 IMDEA Software Institute 2 Tel-Aviv University 3 University of Oxford Abstract. Memory management

More information

A Brief History of Shared memory C M U

A Brief History of Shared memory C M U A Brief History of Shared memory S t e p h e n B r o o k e s C M U 1 Outline Revisionist history Rational reconstruction of early models Evolution of recent models A unifying framework Fault-detecting

More information

Recent developments in concurrent program logics

Recent developments in concurrent program logics Recent developments in concurrent program logics Viktor Vafeiadis University of Cambridge PSPL 2010 Why program logic? Reasoning framework Capture common reasoning principles Reduce accidental proof complexity

More information

Program Verification Using Separation Logic

Program Verification Using Separation Logic Program Verification Using Separation Logic Cristiano Calcagno Adapted from material by Dino Distefano Lecture 1 Goal of the course Study Separation Logic having automatic verification in mind Learn how

More information

Compositional Verification of Termination-Preserving Refinement of Concurrent Programs (Technical Report)

Compositional Verification of Termination-Preserving Refinement of Concurrent Programs (Technical Report) Compositional Verification of Termination-Preserving Refinement of Concurrent Programs (Technical Report) Hongjin Liang 1, Xinyu Feng 1, and Zhong Shao 2 1 University of Science and Technology of China

More information

Concurrent separation logic and operational semantics

Concurrent separation logic and operational semantics MFPS 2011 Concurrent separation logic and operational semantics Viktor Vafeiadis Max Planck Institute for Software Systems (MPI-SWS), Germany Abstract This paper presents a new soundness proof for concurrent

More information

Lectures on Separation Logic. Lecture 2: Foundations

Lectures on Separation Logic. Lecture 2: Foundations Lectures on Separation Logic. Lecture 2: Foundations Peter O Hearn Queen Mary, University of London Marktoberdorf Summer School, 2011 Outline for this lecture Part I : Assertions and Their Semantics Part

More information

Technical Report. Deny-guarantee reasoning. Mike Dodds, Xinyu Feng, Matthew Parkinson, Viktor Vafeiadis. Number 736. January Computer Laboratory

Technical Report. Deny-guarantee reasoning. Mike Dodds, Xinyu Feng, Matthew Parkinson, Viktor Vafeiadis. Number 736. January Computer Laboratory Technical Report UCAM-CL-TR-736 ISSN 1476-2986 Number 736 Computer Laboratory Deny-guarantee reasoning Mike Dodds, Xinyu Feng, Matthew Parkinson, Viktor Vafeiadis January 2009 15 JJ Thomson Avenue Cambridge

More information

Theories of Programming Languages Assignment 5

Theories of Programming Languages Assignment 5 Theories of Programming Languages Assignment 5 December 17, 2012 1. Lambda-Calculus (see Fig. 1 for initions of = β, normal order evaluation and eager evaluation). (a) Let Ω = ((λx. x x) (λx. x x)), and

More information

Collecting garbage concurrently (but correctly)

Collecting garbage concurrently (but correctly) Collecting garbage concurrently (but correctly) Kamal Lodaya The Institute of Mathematical Sciences, Chennai Joint work with Kalpesh Kapoor (IIT, Guwahati) and Uday Reddy (U. Birmingham) 1 First order

More information

Separation Logic and the Mashup Isolation Problem

Separation Logic and the Mashup Isolation Problem Separation Logic and the Mashup Isolation Problem Dept. of Computer Science, Stanford University Phd Qualifier Exam Talk Outline 1 Background Hoare Logic Intuition behind Separation Logic 2 The Mashup

More information

A Marriage of Rely/Guarantee and Separation Logic

A Marriage of Rely/Guarantee and Separation Logic A Marriage of Rely/Guarantee and Separation Logic Viktor Vafeiadis and Matthew Parkinson University of Cambridge Abstract. In the quest for tractable methods for reasoning about concurrent algorithms both

More information

Lecture Notes: Axiomatic Semantics and Hoare-style Verification

Lecture Notes: Axiomatic Semantics and Hoare-style Verification Lecture Notes: Axiomatic Semantics and Hoare-style Verification 17-355/17-665/17-819O: Program Analysis (Spring 2018) Claire Le Goues and Jonathan Aldrich clegoues@cs.cmu.edu, aldrich@cs.cmu.edu It has

More information

Introduction to Permission-Based Program Logics Part II Concurrent Programs

Introduction to Permission-Based Program Logics Part II Concurrent Programs Introduction to Permission-Based Program Logics Part II Concurrent Programs Thomas Wies New York University Example: Lock-Coupling List 2 3 5 7 8 9 There is one lock per node; threads acquire locks in

More information

Bilateral Proofs of Safety and Progress Properties of Concurrent Programs (Working Draft)

Bilateral Proofs of Safety and Progress Properties of Concurrent Programs (Working Draft) Bilateral Proofs of Safety and Progress Properties of Concurrent Programs (Working Draft) Jayadev Misra December 18, 2015 Contents 1 Introduction 3 2 Program and Execution Model 4 2.1 Program Structure..........................

More information

A Short Introduction to Hoare Logic

A Short Introduction to Hoare Logic A Short Introduction to Hoare Logic Supratik Chakraborty I.I.T. Bombay June 23, 2008 Supratik Chakraborty (I.I.T. Bombay) A Short Introduction to Hoare Logic June 23, 2008 1 / 34 Motivation Assertion checking

More information

Program Analysis and Verification

Program Analysis and Verification Program Analysis and Verification 0368-4479 Noam Rinetzky Lecture 4: Axiomatic Semantics Slides credit: Tom Ball, Dawson Engler, Roman Manevich, Erik Poll, Mooly Sagiv, Jean Souyris, Eran Tromer, Avishai

More information

Views: Compositional Reasoning for Concurrent Programs

Views: Compositional Reasoning for Concurrent Programs Views: Compositional Reasoning for Concurrent Programs Thomas Dinsdale-Young Imperial College td202@doc.ic.ac.uk Lars Birkedal IT University of Copenhagen birkedal@itu.dk Philippa Gardner Imperial College

More information

A semantics for concurrent separation logic

A semantics for concurrent separation logic Theoretical Computer Science 375 (2007) 227 270 www.elsevier.com/locate/tcs A semantics for concurrent separation logic Stephen Brookes School of Computer Science, Carnegie Mellon University, 5000 Forbes

More information

Design of Distributed Systems Melinda Tóth, Zoltán Horváth

Design of Distributed Systems Melinda Tóth, Zoltán Horváth Design of Distributed Systems Melinda Tóth, Zoltán Horváth Design of Distributed Systems Melinda Tóth, Zoltán Horváth Publication date 2014 Copyright 2014 Melinda Tóth, Zoltán Horváth Supported by TÁMOP-412A/1-11/1-2011-0052

More information

Program Verification using Separation Logic Lecture 0 : Course Introduction and Assertion Language. Hongseok Yang (Queen Mary, Univ.

Program Verification using Separation Logic Lecture 0 : Course Introduction and Assertion Language. Hongseok Yang (Queen Mary, Univ. Program Verification using Separation Logic Lecture 0 : Course Introduction and Assertion Language Hongseok Yang (Queen Mary, Univ. of London) Dream Automatically verify the memory safety of systems software,

More information

Concurrency, Rely/Guarantee and Separation Logic

Concurrency, Rely/Guarantee and Separation Logic Concurrency, Rely/Guarantee and Separation Logic Cliff Jones Newcastle University Overture Workshop 2014-06-21 Concurrency, Rely/Guarantee and Separation Logic Cliff Jones [1] Expressive power must be

More information

Introduction to Kleene Algebra Lecture 14 CS786 Spring 2004 March 15, 2004

Introduction to Kleene Algebra Lecture 14 CS786 Spring 2004 March 15, 2004 Introduction to Kleene Algebra Lecture 14 CS786 Spring 2004 March 15, 2004 KAT and Hoare Logic In this lecture and the next we show that KAT subsumes propositional Hoare logic (PHL). Thus the specialized

More information

Control Predicates Are Better Than Dummy Variables For Reasoning About Program Control

Control Predicates Are Better Than Dummy Variables For Reasoning About Program Control Control Predicates Are Better Than Dummy Variables For Reasoning About Program Control LESLIE LAMPORT Digital Equipment Corporation When explicit control predicates rather than dummy variables are used,

More information

List reversal: back into the frying pan

List reversal: back into the frying pan List reversal: back into the frying pan Richard Bornat March 20, 2006 Abstract More than thirty years ago Rod Burstall showed how to do a proof of a neat little program, shown in a modern notation in figure

More information

Modular Termination Verification for Non-blocking Concurrency

Modular Termination Verification for Non-blocking Concurrency Modular Termination Verification for Non-blocking Concurrency Pedro da Rocha Pinto 1, Thomas Dinsdale-Young 2, Philippa Gardner 1, and Julian Sutherland 1 1 Imperial College London pmd09,pg,jhs110@doc.ic.ac.uk

More information

Hoare Logic (I): Axiomatic Semantics and Program Correctness

Hoare Logic (I): Axiomatic Semantics and Program Correctness Hoare Logic (I): Axiomatic Semantics and Program Correctness (Based on [Apt and Olderog 1991; Gries 1981; Hoare 1969; Kleymann 1999; Sethi 199]) Yih-Kuen Tsay Dept. of Information Management National Taiwan

More information

Flow Interfaces Compositional Abstractions of Concurrent Data Structures. Siddharth Krishna, Dennis Shasha, and Thomas Wies

Flow Interfaces Compositional Abstractions of Concurrent Data Structures. Siddharth Krishna, Dennis Shasha, and Thomas Wies Flow Interfaces Compositional Abstractions of Concurrent Data Structures Siddharth Krishna, Dennis Shasha, and Thomas Wies Background Verifying programs, separation logic, inductive predicates Verifying

More information

Combining Shared Coin Algorithms

Combining Shared Coin Algorithms Combining Shared Coin Algorithms James Aspnes Hagit Attiya Keren Censor Abstract This paper shows that shared coin algorithms can be combined to optimize several complexity measures, even in the presence

More information

Reasoning About Imperative Programs. COS 441 Slides 10b

Reasoning About Imperative Programs. COS 441 Slides 10b Reasoning About Imperative Programs COS 441 Slides 10b Last time Hoare Logic: { P } C { Q } Agenda If P is true in the initial state s. And C in state s evaluates to s. Then Q must be true in s. Program

More information

Completeness of Pointer Program Verification by Separation Logic

Completeness of Pointer Program Verification by Separation Logic ISSN 1346-5597 NII Technical Report Completeness of Pointer Program Verification by Separation Logic Makoto Tatsuta, Wei-Ngan Chin, and Mahmudul Faisal Al Ameen NII-2009-013E June 2009 Completeness of

More information

Hoare Logic: Part II

Hoare Logic: Part II Hoare Logic: Part II COMP2600 Formal Methods for Software Engineering Jinbo Huang Australian National University COMP 2600 Hoare Logic II 1 Factorial {n 0} fact := 1; i := n; while (i >0) do fact := fact

More information

Separation Logic and Graphical Models

Separation Logic and Graphical Models Separation Logic and Graphical Models John Wickerson and Tony Hoare Semantics Lunch, 25th October 2010 1 Trace composition Problem: Composition is non-deterministic. 2 Trace composition Problem: Composition

More information

Program verification. Hoare triples. Assertional semantics (cont) Example: Semantics of assignment. Assertional semantics of a program

Program verification. Hoare triples. Assertional semantics (cont) Example: Semantics of assignment. Assertional semantics of a program Program verification Assertional semantics of a program Meaning of a program: relation between its inputs and outputs; specified by input assertions (pre-conditions) and output assertions (post-conditions)

More information

Hoare Logic and Model Checking

Hoare Logic and Model Checking Hoare Logic and Model Checking Kasper Svendsen University of Cambridge CST Part II 2016/17 Acknowledgement: slides heavily based on previous versions by Mike Gordon and Alan Mycroft Introduction In the

More information

Hoare Calculus and Predicate Transformers

Hoare Calculus and Predicate Transformers Hoare Calculus and Predicate Transformers Wolfgang Schreiner Wolfgang.Schreiner@risc.uni-linz.ac.at Research Institute for Symbolic Computation (RISC) Johannes Kepler University, Linz, Austria http://www.risc.uni-linz.ac.at

More information

A Theory for Composing Distributed Components, Based on Temporary Interference

A Theory for Composing Distributed Components, Based on Temporary Interference A Theory for Composing Distributed Components, Based on Temporary Interference I.S.W.B. Prasetya T.E.J. Vos S.D. Swierstra B. Widjaja Abstract Compositionality provides the foundation of software modularity,

More information

THE AUSTRALIAN NATIONAL UNIVERSITY Second Semester COMP2600/COMP6260 (Formal Methods for Software Engineering)

THE AUSTRALIAN NATIONAL UNIVERSITY Second Semester COMP2600/COMP6260 (Formal Methods for Software Engineering) THE AUSTRALIAN NATIONAL UNIVERSITY Second Semester 2016 COMP2600/COMP6260 (Formal Methods for Software Engineering) Writing Period: 3 hours duration Study Period: 15 minutes duration Permitted Materials:

More information

Program Analysis Part I : Sequential Programs

Program Analysis Part I : Sequential Programs Program Analysis Part I : Sequential Programs IN5170/IN9170 Models of concurrency Program Analysis, lecture 5 Fall 2018 26. 9. 2018 2 / 44 Program correctness Is my program correct? Central question for

More information

Chapter 2. Assertions. An Introduction to Separation Logic c 2011 John C. Reynolds February 3, 2011

Chapter 2. Assertions. An Introduction to Separation Logic c 2011 John C. Reynolds February 3, 2011 Chapter 2 An Introduction to Separation Logic c 2011 John C. Reynolds February 3, 2011 Assertions In this chapter, we give a more detailed exposition of the assertions of separation logic: their meaning,

More information

Last Time. Inference Rules

Last Time. Inference Rules Last Time When program S executes it switches to a different state We need to express assertions on the states of the program S before and after its execution We can do it using a Hoare triple written

More information

The Underlying Semantics of Transition Systems

The Underlying Semantics of Transition Systems The Underlying Semantics of Transition Systems J. M. Crawford D. M. Goldschlag Technical Report 17 December 1987 Computational Logic Inc. 1717 W. 6th St. Suite 290 Austin, Texas 78703 (512) 322-9951 1

More information

Flow Interfaces Compositional Abstractions of Concurrent Data Structures. Siddharth Krishna, Dennis Shasha, and Thomas Wies

Flow Interfaces Compositional Abstractions of Concurrent Data Structures. Siddharth Krishna, Dennis Shasha, and Thomas Wies Flow Interfaces Compositional Abstractions of Concurrent Data Structures Siddharth Krishna, Dennis Shasha, and Thomas Wies Background Verifying programs, separation logic, inductive predicates Slides courtesy

More information

Axiomatic Semantics. Lecture 9 CS 565 2/12/08

Axiomatic Semantics. Lecture 9 CS 565 2/12/08 Axiomatic Semantics Lecture 9 CS 565 2/12/08 Axiomatic Semantics Operational semantics describes the meaning of programs in terms of the execution steps taken by an abstract machine Denotational semantics

More information

Technical Report. A safety proof of a lazy concurrent list-based set implementation. Viktor Vafeiadis, Maurice Herlihy, Tony Hoare, Marc Shapiro

Technical Report. A safety proof of a lazy concurrent list-based set implementation. Viktor Vafeiadis, Maurice Herlihy, Tony Hoare, Marc Shapiro Technical Report UCAM-CL-TR-659 ISSN 1476-2986 Number 659 Computer Laboratory A safety proof of a lazy concurrent list-based set implementation Viktor Vafeiadis, Maurice Herlihy, Tony Hoare, Marc Shapiro

More information

Trace semantics: towards a unification of parallel paradigms Stephen Brookes. Department of Computer Science Carnegie Mellon University

Trace semantics: towards a unification of parallel paradigms Stephen Brookes. Department of Computer Science Carnegie Mellon University Trace semantics: towards a unification of parallel paradigms Stephen Brookes Department of Computer Science Carnegie Mellon University MFCSIT 2002 1 PARALLEL PARADIGMS State-based Shared-memory global

More information

Abstraction and Refinement for Local Reasoning

Abstraction and Refinement for Local Reasoning Under consideration for publication in Math. Struct. in Comp. Science Abstraction and Refinement for Local Reasoning Thomas Dinsdale-Young, Philippa Gardner and Mark Wheelhouse Department of Computing,

More information

Spring 2015 Program Analysis and Verification. Lecture 6: Axiomatic Semantics III. Roman Manevich Ben-Gurion University

Spring 2015 Program Analysis and Verification. Lecture 6: Axiomatic Semantics III. Roman Manevich Ben-Gurion University Spring 2015 Program Analysis and Verification Lecture 6: Axiomatic Semantics III Roman Manevich Ben-Gurion University Tentative syllabus Semantics Static Analysis Abstract Interpretation fundamentals Analysis

More information

Axiomatic Semantics. Operational semantics. Good for. Not good for automatic reasoning about programs

Axiomatic Semantics. Operational semantics. Good for. Not good for automatic reasoning about programs Review Operational semantics relatively l simple many flavors (small vs. big) not compositional (rule for while) Good for describing language implementation reasoning about properties of the language eg.

More information

A Revisionist History of Concurrent Separation Logic

A Revisionist History of Concurrent Separation Logic Available online at www.sciencedirect.com Electronic Notes in Theoretical Computer Science 276 (2011) 5 28 www.elsevier.com/locate/entcs A Revisionist History of Concurrent Separation Logic Stephen Brookes

More information

CS 6112 (Fall 2011) Foundations of Concurrency

CS 6112 (Fall 2011) Foundations of Concurrency CS 6112 (Fall 2011) Foundations of Concurrency 29 November 2011 Scribe: Jean-Baptiste Jeannin 1 Readings The readings for today were: Eventually Consistent Transactions, by Sebastian Burckhardt, Manuel

More information

AN INTRODUCTION TO SEPARATION LOGIC. 2. Assertions

AN INTRODUCTION TO SEPARATION LOGIC. 2. Assertions AN INTRODUCTION TO SEPARATION LOGIC 2. Assertions John C. Reynolds Carnegie Mellon University January 7, 2011 c 2011 John C. Reynolds Pure Assertions An assertion p is pure iff, for all stores s and all

More information

Spring 2014 Program Analysis and Verification. Lecture 6: Axiomatic Semantics III. Roman Manevich Ben-Gurion University

Spring 2014 Program Analysis and Verification. Lecture 6: Axiomatic Semantics III. Roman Manevich Ben-Gurion University Spring 2014 Program Analysis and Verification Lecture 6: Axiomatic Semantics III Roman Manevich Ben-Gurion University Syllabus Semantics Static Analysis Abstract Interpretation fundamentals Analysis Techniques

More information

Lecture Notes on Software Model Checking

Lecture Notes on Software Model Checking 15-414: Bug Catching: Automated Program Verification Lecture Notes on Software Model Checking Matt Fredrikson André Platzer Carnegie Mellon University Lecture 19 1 Introduction So far we ve focused on

More information

COMP3151/9151 Foundations of Concurrency Lecture 4

COMP3151/9151 Foundations of Concurrency Lecture 4 1 COMP3151/9151 Foundations of Concurrency Lecture 4 and Kai Engelhardt CSE, UNSW (and data61) Revision: 1.5 of Date: 2017/08/14 00:35:24 UTC (Credits: parts may be borrowed from M. Ben-Ari, G Andrews,

More information

Lecture Notes on Inductive Definitions

Lecture Notes on Inductive Definitions Lecture Notes on Inductive Definitions 15-312: Foundations of Programming Languages Frank Pfenning Lecture 2 August 28, 2003 These supplementary notes review the notion of an inductive definition and give

More information

Automata-Theoretic Model Checking of Reactive Systems

Automata-Theoretic Model Checking of Reactive Systems Automata-Theoretic Model Checking of Reactive Systems Radu Iosif Verimag/CNRS (Grenoble, France) Thanks to Tom Henzinger (IST, Austria), Barbara Jobstmann (CNRS, Grenoble) and Doron Peled (Bar-Ilan University,

More information

A Decidable Fragment of Separation Logic

A Decidable Fragment of Separation Logic A Decidable Fragment of Separation Logic Josh Berdine 1, Cristiano Calcagno 2, and Peter W. O Hearn 1 1 Queen Mary, University of London {berdine,ohearn}@dcs.qmul.ac.uk 2 Imperial College, London ccris@doc.ic.ac.uk

More information

Classical Program Logics: Hoare Logic, Weakest Liberal Preconditions

Classical Program Logics: Hoare Logic, Weakest Liberal Preconditions Chapter 1 Classical Program Logics: Hoare Logic, Weakest Liberal Preconditions 1.1 The IMP Language IMP is a programming language with an extensible syntax that was developed in the late 1960s. We will

More information

Owicki-Gries Reasoning for Weak Memory Models

Owicki-Gries Reasoning for Weak Memory Models Owicki-Gries Reasoning for Weak Memory Models Ori Lahav and Viktor Vafeiadis Max Planck Institute for Software Systems (MPI-SWS) Abstract. We show that even in the absence of auxiliary variables, the wellknown

More information

Hoare Logic I. Introduction to Deductive Program Verification. Simple Imperative Programming Language. Hoare Logic. Meaning of Hoare Triples

Hoare Logic I. Introduction to Deductive Program Verification. Simple Imperative Programming Language. Hoare Logic. Meaning of Hoare Triples Hoare Logic I Introduction to Deductive Program Verification Işıl Dillig Program Spec Deductive verifier FOL formula Theorem prover valid contingent Example specs: safety (no crashes), absence of arithmetic

More information

Universität Augsburg

Universität Augsburg Universität Augsburg Algebraic Separation Logic H.-H. Dang P. Höfner B. Möller Report 2010-06 July 2010 Institut für Informatik D-86135 Augsburg Copyright c H.-H. Dang P. Höfner B. Möller Institut für

More information

Probabilistic Guarded Commands Mechanized in HOL

Probabilistic Guarded Commands Mechanized in HOL Probabilistic Guarded Commands Mechanized in HOL Joe Hurd joe.hurd@comlab.ox.ac.uk Oxford University Joint work with Annabelle McIver (Macquarie University) and Carroll Morgan (University of New South

More information

The L Machines are very high-level, in two senses:

The L Machines are very high-level, in two senses: What is a Computer? State of the machine. CMPSCI 630: Programming Languages An Abstract Machine for Control Spring 2009 (with thanks to Robert Harper) Internal registers, memory, etc. Initial and final

More information

Constraint Solving for Program Verification: Theory and Practice by Example

Constraint Solving for Program Verification: Theory and Practice by Example Constraint Solving for Program Verification: Theory and Practice by Example Andrey Rybalchenko Technische Universität München Abstract. Program verification relies on the construction of auxiliary assertions

More information

Dartmouth Computer Science Technical Report TR Efficient Wait-Free Implementation of Multiword LL/SC Variables

Dartmouth Computer Science Technical Report TR Efficient Wait-Free Implementation of Multiword LL/SC Variables Dartmouth Computer Science Technical Report TR2004-523 Efficient Wait-Free Implementation of Multiword LL/SC Variables Prasad Jayanti and Srdjan Petrovic Department of Computer Science Dartmouth College

More information

Safety and Liveness. Thread Synchronization: Too Much Milk. Critical Sections. A Really Cool Theorem

Safety and Liveness. Thread Synchronization: Too Much Milk. Critical Sections. A Really Cool Theorem Safety and Liveness Properties defined over an execution of a program Thread Synchronization: Too Much Milk Safety: nothing bad happens holds in every finite execution prefix Windows never crashes No patient

More information

Local Reasoning for Storable Locks and Threads

Local Reasoning for Storable Locks and Threads Local Reasoning for Storable Locks and Threads Alexey Gotsman Josh Berdine Byron Cook Noam Rinetzky Mooly Sagiv University of Cambridge Microsoft Research Tel-Aviv University April, revised September Technical

More information

Multicore Semantics and Programming

Multicore Semantics and Programming Multicore Semantics and Programming Peter Sewell Tim Harris University of Cambridge Oracle October November, 2015 p. 1 These Lectures Part 1: Multicore Semantics: the concurrency of multiprocessors and

More information

The Assignment Axiom (Hoare)

The Assignment Axiom (Hoare) The Assignment Axiom (Hoare) Syntax: V := E Semantics: value of V in final state is value of E in initial state Example: X:=X+ (adds one to the value of the variable X) The Assignment Axiom {Q[E/V ]} V

More information

arxiv: v1 [cs.dc] 9 Feb 2015

arxiv: v1 [cs.dc] 9 Feb 2015 Why Transactional Memory Should Not Be Obstruction-Free Petr Kuznetsov 1 Srivatsan Ravi 2 1 Télécom ParisTech 2 TU Berlin arxiv:1502.02725v1 [cs.dc] 9 Feb 2015 Abstract Transactional memory (TM) is an

More information

Clojure Concurrency Constructs, Part Two. CSCI 5828: Foundations of Software Engineering Lecture 13 10/07/2014

Clojure Concurrency Constructs, Part Two. CSCI 5828: Foundations of Software Engineering Lecture 13 10/07/2014 Clojure Concurrency Constructs, Part Two CSCI 5828: Foundations of Software Engineering Lecture 13 10/07/2014 1 Goals Cover the material presented in Chapter 4, of our concurrency textbook In particular,

More information

Tute 10. Liam O'Connor. May 23, 2017

Tute 10. Liam O'Connor. May 23, 2017 Tute 10 Liam O'Connor May 23, 2017 proc Search(value g : G, value s : V g, value k : K, result v : T, result f : B) Where a graph g : G is dened as a 4-tuple (V, Γ, κ, λ) containing a set of vertices V,

More information

Trace Refinement of π-calculus Processes

Trace Refinement of π-calculus Processes Trace Refinement of pi-calculus Processes Trace Refinement of π-calculus Processes Manuel Gieseking manuel.gieseking@informatik.uni-oldenburg.de) Correct System Design, Carl von Ossietzky University of

More information

Halting and Equivalence of Program Schemes in Models of Arbitrary Theories

Halting and Equivalence of Program Schemes in Models of Arbitrary Theories Halting and Equivalence of Program Schemes in Models of Arbitrary Theories Dexter Kozen Cornell University, Ithaca, New York 14853-7501, USA, kozen@cs.cornell.edu, http://www.cs.cornell.edu/~kozen In Honor

More information

From Separation Logic to Systems Software

From Separation Logic to Systems Software From Separation Logic to Systems Software Peter O Hearn, Queen Mary Based on work of the SpaceInvader team: Cristiano Calcagno, Dino Distefano, Hongseok Yang, and me Special thanks to our SLAyer colleagues

More information

Lecture Notes on Inductive Definitions

Lecture Notes on Inductive Definitions Lecture Notes on Inductive Definitions 15-312: Foundations of Programming Languages Frank Pfenning Lecture 2 September 2, 2004 These supplementary notes review the notion of an inductive definition and

More information

Programming Languages and Compilers (CS 421)

Programming Languages and Compilers (CS 421) Programming Languages and Compilers (CS 421) Sasa Misailovic 4110 SC, UIUC https://courses.engr.illinois.edu/cs421/fa2017/cs421a Based in part on slides by Mattox Beckman, as updated by Vikram Adve, Gul

More information

Separation and Information Hiding

Separation and Information Hiding Separation and Information Hiding PETER W. O HEARN and HONGSEOK YANG Queen Mary, University of London and JOHN C. REYNOLDS Carnegie Mellon University 11 We investigate proof rules for information hiding,

More information

COMP2111 Glossary. Kai Engelhardt. Contents. 1 Symbols. 1 Symbols 1. 2 Hoare Logic 3. 3 Refinement Calculus 5. rational numbers Q, real numbers R.

COMP2111 Glossary. Kai Engelhardt. Contents. 1 Symbols. 1 Symbols 1. 2 Hoare Logic 3. 3 Refinement Calculus 5. rational numbers Q, real numbers R. COMP2111 Glossary Kai Engelhardt Revision: 1.3, May 18, 2018 Contents 1 Symbols 1 2 Hoare Logic 3 3 Refinement Calculus 5 1 Symbols Booleans B = {false, true}, natural numbers N = {0, 1, 2,...}, integers

More information

Hoare Logic: Reasoning About Imperative Programs

Hoare Logic: Reasoning About Imperative Programs Hoare Logic: Reasoning About Imperative Programs COMP1600 / COMP6260 Dirk Pattinson Australian National University Semester 2, 2017 Catch Up / Drop in Lab When Fridays, 15.00-17.00 Where N335, CSIT Building

More information

Nontrivial and Universal Helping for Wait-Free Queues and Stacks

Nontrivial and Universal Helping for Wait-Free Queues and Stacks Nontrivial and Universal Helping for Wait-Free Queues and Stacks Hagit Attiya 1, Armando Castañeda 2, and Danny Hendler 3 1 Technion 2 UNAM 3 BGU Abstract This paper studies two approaches to formalize

More information

Inductive Data Flow Graphs

Inductive Data Flow Graphs Inductive Data Flow Graphs Azadeh Farzan University of Toronto Zachary Kincaid Andreas Podelski University of Freiburg Abstract The correctness of a sequential program can be shown by the annotation of

More information

Floyd-Hoare Style Program Verification

Floyd-Hoare Style Program Verification Floyd-Hoare Style Program Verification Deepak D Souza Department of Computer Science and Automation Indian Institute of Science, Bangalore. 9 Feb 2017 Outline of this talk 1 Overview 2 Hoare Triples 3

More information

Dynamic Semantics. Dynamic Semantics. Operational Semantics Axiomatic Semantics Denotational Semantic. Operational Semantics

Dynamic Semantics. Dynamic Semantics. Operational Semantics Axiomatic Semantics Denotational Semantic. Operational Semantics Dynamic Semantics Operational Semantics Denotational Semantic Dynamic Semantics Operational Semantics Operational Semantics Describe meaning by executing program on machine Machine can be actual or simulated

More information

Program verification using Hoare Logic¹

Program verification using Hoare Logic¹ Program verification using Hoare Logic¹ Automated Reasoning - Guest Lecture Petros Papapanagiotou Part 2 of 2 ¹Contains material from Mike Gordon s slides: Previously on Hoare Logic A simple while language

More information

Software Engineering

Software Engineering Software Engineering Lecture 07: Design by Contract Peter Thiemann University of Freiburg, Germany 02.06.2014 Table of Contents Design by Contract Contracts for Procedural Programs Contracts for Object-Oriented

More information

Verifying Randomized Distributed Algorithms with PRISM

Verifying Randomized Distributed Algorithms with PRISM Verifying Randomized Distributed Algorithms with PRISM Marta Kwiatkowska, Gethin Norman, and David Parker University of Birmingham, Birmingham B15 2TT, United Kingdom {M.Z.Kwiatkowska,G.Norman,D.A.Parker}@cs.bham.ac.uk

More information

arxiv: v1 [cs.pl] 5 Apr 2017

arxiv: v1 [cs.pl] 5 Apr 2017 arxiv:1704.01814v1 [cs.pl] 5 Apr 2017 Bilateral Proofs of Safety and Progress Properties of Concurrent Programs Jayadev Misra University of Texas at Austin, misra@utexas.edu April 5, 2017 Abstract This

More information

Abstractions and Decision Procedures for Effective Software Model Checking

Abstractions and Decision Procedures for Effective Software Model Checking Abstractions and Decision Procedures for Effective Software Model Checking Prof. Natasha Sharygina The University of Lugano, Carnegie Mellon University Microsoft Summer School, Moscow, July 2011 Lecture

More information

Separation Logic and the Mashup Isolation Problem

Separation Logic and the Mashup Isolation Problem Separation Logic and the Mashup Isolation Problem Ankur Taly Computer Science Department, Stanford University Abstract. This work was done as part of my PhD qualifier exam. My qualifier exam problem was

More information

Introduction to Model Checking. Debdeep Mukhopadhyay IIT Madras

Introduction to Model Checking. Debdeep Mukhopadhyay IIT Madras Introduction to Model Checking Debdeep Mukhopadhyay IIT Madras How good can you fight bugs? Comprising of three parts Formal Verification techniques consist of three parts: 1. A framework for modeling

More information

Structuring the verification of heap-manipulating programs

Structuring the verification of heap-manipulating programs Structuring the verification of heap-manipulating programs Aleksandar Nanevski (IMDEA Madrid) Viktor Vafeiadis (MSR / Univ. of Cambridge) Josh Berdine (MSR Cambridge) Hoare/Separation Logic Hoare logic

More information

Lecture Notes on Data Abstraction

Lecture Notes on Data Abstraction Lecture Notes on Data Abstraction 15-814: Types and Programming Languages Frank Pfenning Lecture 14 October 23, 2018 1 Introduction Since we have moved from the pure λ-calculus to functional programming

More information

Reconciling Situation Calculus and Fluent Calculus

Reconciling Situation Calculus and Fluent Calculus Reconciling Situation Calculus and Fluent Calculus Stephan Schiffel and Michael Thielscher Department of Computer Science Dresden University of Technology {stephan.schiffel,mit}@inf.tu-dresden.de Abstract

More information

Property Checking By Logic Relaxation

Property Checking By Logic Relaxation Property Checking By Logic Relaxation Eugene Goldberg eu.goldberg@gmail.com arxiv:1601.02742v1 [cs.lo] 12 Jan 2016 Abstract We introduce a new framework for Property Checking (PC) of sequential circuits.

More information

Softwaretechnik. Lecture 13: Design by Contract. Peter Thiemann University of Freiburg, Germany

Softwaretechnik. Lecture 13: Design by Contract. Peter Thiemann University of Freiburg, Germany Softwaretechnik Lecture 13: Design by Contract Peter Thiemann University of Freiburg, Germany 25.06.2012 Table of Contents Design by Contract Contracts for Procedural Programs Contracts for Object-Oriented

More information

Softwaretechnik. Lecture 13: Design by Contract. Peter Thiemann University of Freiburg, Germany

Softwaretechnik. Lecture 13: Design by Contract. Peter Thiemann University of Freiburg, Germany Softwaretechnik Lecture 13: Design by Contract Peter Thiemann University of Freiburg, Germany 25.06.2012 Table of Contents Design by Contract Contracts for Procedural Programs Contracts for Object-Oriented

More information