Specifying and Verifying Concurrent Algorithms Histories...

Histories and Subjectivity

ESOP 2015

Ilya Sergey Aleks Nanevski Anindya Banerjee

biennial report2008-09

madrid institute for advanced studies

memoria software v3.qxd 13/8/10 10:48 Página 1

Specifying and Verifying Concurrent Algorithms

A logic-based approach for

Specifying and Verifying Concurrent Algorithms

An approach, which is

• Natural- captures intuition behind realistic algorithms

• Powerful- enables compositional verification of concurrency

• Lightweight- does not require to engineer a new logical framework

Key ideas

• Subjectivity

• Partial Commutative Monoids (PCMs)

• Histories

Key ideas

• Subjectivity

• HistoriesNanevski et al. [ESOP’14]

Key ideas

• Subjectivity

• Histories

Hoare-style program specifications

{ P } { Q }c

{ P } { Q }

precondition

{ P } { Q }

precondition postcondition

If the initial state satisfies P, then, after c terminates,

the final state satisfies Q.

{ P } { Q }

precondition postcondition

push(x)

Abstract specifications for a stack

push(x)

push(x){ S = xs } { S′= x :: xs }

pop(){ S = xs } { res = None ⋀ S = Nil ⋁ ∃x, xs′. res = Some x ⋀ xs = x :: xs′ ⋀ S′ = xs′ }

push(x){ S = xs } { S′= x :: xs }

pop(){ S = xs }

Suitable for sequential case

{ res = None ⋀ S = Nil ⋁ ∃x, xs′. res = Some x ⋀ xs = x :: xs′ ⋀ S′ = xs′ }

push(x){ S = xs } { S′= x :: xs }

pop(){ S = xs }

Not so good for concurrent use: useless in the presence of interference

{ res = None ⋀ S = Nil ⋁ ∃x, xs′. res = Some x ⋀ xs = x :: xs′ ⋀ S′ = xs′ }

y := pop();

{ S = Nil }

y := pop();

{ y = ??? }

{ S = Nil }

y := pop();

��

push(1);

push(2);

{ S = Nil }

y := pop();

{ y = 1 ⋁ y = 2 ⋁ y = None }

��

push(1);

push(2);

{ S = Nil }

y := pop();

{ S = Nil }��

��

push(1);

push(2);

��

push(3);

y := pop();

{ S = Nil }

{ y = 1 ⋁ y = 2 ⋁ y = 3 ⋁ y = None }

��

push(1);

push(2);

��

push(3);

y := pop();

{ y = ??? }

{ S = Nil }

Thread-modular spec for pop?

Capture the effect of self, abstract over the others.

(subjective specification)

y := pop();

Subjective stack specifications

y := pop();

• Hs — pushes/pops to the stack by this thread

y := pop();

• Ho — pushes/pops by all other threads

y := pop();

{ Hs = ∅ }

y := pop();

{ y = None ⋁ y = Some(v), where v ∈ Ho }

{ Hs = ∅ }

y := pop();

{ Hs = ∅ }

| {z }

what I popped dependson what the others have pushed

Valid only if the stack is changed only by push/pops.

| {z }

what I popped dependson what the others have pushed

y := pop();

{ Hs = ∅ }

{ P } { Q }y := pop();

{ P } { Q }C ⊢ y := pop();

{ P } { Q }C ⊢

Specifies expectedthread interference

y := pop();

Concurrent Resources

Shared state

Concurrent Resources

Auxiliary state

Shared state

Owicki, Gries [CACM’77]

Subjective Concurrent Resources

Shared state

Ley-Wild, Nanevski [POPL’13]

Auxiliary state, controlled by this thread

Shared state

Auxiliary state, controlled by this thread

Auxiliary state, controlled by others

Shared state

Subjective Concurrent ResourcesJones [TOPLAS’83]

Changes (transitions) allowed to myself

(Guarantee)

Transitions, allowed to the others (Rely)

(Guarantee)

Transitions, allowed to the others (Rely)

(Guarantee)

What I have = what I can do and what I have done.

State Transition Systemswith

Subjective Auxiliary State

Concurrent Resources =

Nanevski, Ley-Wild, Sergey, Delbianco [ESOP’14]

State Transition Systemswith

Subjective Auxiliary State

Concurrent Resources =

(Concurroids)

Specifications with concurroids

• Self — state controlled by me

• Other — state controlled by all other threads

• Joint — modified by everyone, as allowed by transitions

{ P } c { Q }C ⊢

{ P } c { Q }@ C

{ P } c { Q }| {z }

defines resources, touched by c, their transitions and invariants

{ P } c { Q }@ C

specify self/other/joint parts

FCSL: Fine-grained Concurrent Separation Logic

• Logic for reasoning with concurroids

• Emphasis on subjective specifications

Key ideas

• Subjectivity

• PCMs

• Histories

Key ideas

• Subjectivity — reasoning with self and other

• PCMs

• Histories

• PCMs

• Histories

Key ideas

Partial Commutative Monoids

• A set S of elements

• Join (⊕): commutative, associative, partial

• Unit element 0: ∀e ∈ S, e⊕0 = 0⊕e = e

(S, ⊕, 0)

Parallel composition

child1 child2||parent

• commutative• associative• unit — idle thread• partial

{ s1 ⊕ s2 }

Logical state split

child1 child2||s1 ⊕ s2

parent{ s1 ⊕ s2 }

Logical state split

parent

child1 ||

State that belongs to child1

child2||s1

{ s1 }

{ s1 ⊕ s2 }

Logical state splits2 ⊕ s3

child1 ||

State that belongs to child2

child2||s2

{ s1 } { s2 }

parent{ s1 ⊕ s2 }

Logical state splits1 ⊕ s3

||||z2

{ s2 }{ s1 }

{ z1 } { z2 }

{ s1 ⊕ s2 }

Logical state split

child1 child2

parentz1 ⊕ z3

z1 ⊕ z2

New state that belongs to parent′

||parent′

{ s2 }{ s1 }

{ z1 } { z2 }

{ s1 ⊕ s2 }

{ z1 ⊕ z2 }

Logical state split

child1 child2

parentz3

• PCMs

• Histories

Key ideas

• PCMs — uniform way to logically split state

• Histories

Key ideas

Familiar PCM: finite heaps

• Heaps are partial finite maps nat → Val

• Join operation ⊕ is disjoint union

• Unit element 0 is the empty heap ∅

Concurroid for thread-local state

• hs — heap, logically owned by this thread

• ho — heap, owned by others

Concurroid for thread-local stateConcurrent Separation Logic

O’Hearn [CONCUR’04]

*x := 5; *y := 7;

��

*x := 5; *y := 7;

{ hs = x ↦ - ⊕ y ↦ - ⋀ ho = h }��

��

*x := 5; *y := 7;

{ hs = x ↦ - ⊕ y ↦ - ⋀ ho = h }��

��

disjoint by resource definition

*x := 5; *y := 7;

{ hs = x ↦ - ⊕ y ↦ - ⋀ ho = h }

{ hs = x ↦ - ⋀ ho = y ↦ ? ⊕ h }

��

*x := 5; *y := 7;

{ hs = x ↦ - ⊕ y ↦ - ⋀ ho = h }

{ hs = x ↦ - ⋀ ho = y ↦ ? ⊕ h } { hs = y ↦ - ⋀ ho = x ↦ ? ⊕ h }

��

*x := 5; *y := 7;

{ hs = x ↦ - ⊕ y ↦ - ⋀ ho = h }

{ hs = x ↦ - ⋀ ho = y ↦ ? ⊕ h } { hs = y ↦ - ⋀ ho = x ↦ ? ⊕ h }

{ hs = x ↦ 5 ⋀ ho = y ↦ ? ⊕ h } { hs = y ↦ 7 ⋀ ho = x ↦ ? ⊕ h }

��

*x := 5; *y := 7;

{ hs = x ↦ - ⊕ y ↦ - ⋀ ho = h }

{ hs = x ↦ - ⋀ ho = y ↦ ? ⊕ h } { hs = y ↦ - ⋀ ho = x ↦ ? ⊕ h }

{ hs = x ↦ 5 ⋀ ho = y ↦ ? ⊕ h } { hs = y ↦ 7 ⋀ ho = x ↦ ? ⊕ h }

{ hs = x ↦ 5 ⊕ y ↦ 7 ⋀ ho = h }

��

• Histories

Key ideas

• Histories

Key ideas

• Histories

Key ideas

Sergey et al. [ESOP’15]

push(x)

Atomic stack specifications

push(x){ S = xs } { S′ = x :: xs }

x :: xsxstk →

x :: xsxs

“timestamp”

tk →

tk → tk+1 →

tk+2 → tk+3 →

……

tk+n →

tk+4 →

Changes by this thread Changes by other threads

tk+4 →

tk+1 →

tk+3 →

tk+n →

tk →

tk+2 →

……

tk+4 →

tk+1 →

tk+3 →

tk+n →

tk →

tk+2 →

……

tk+4 →

tk+1 →

tk+3 →

tk+n →

tk →

tk+2 →

……HsHo

Hs, Ho — self/other contributions to the resource history

Histories are like heaps!

• Histories are partial finite maps nat → AbsOp

• Unit element 0 is the empty history ∅

Specifying stacks with histories

Cstack =Hs

Cstack =

• Hs, Ho = { tk ↦ (xs, x::xs), tn ↦ (x::xs, xs), … }

Cstack =

• Joint part is specific for each implementation

Cstack =

• Joint part is specific for each implementation

• Adjacent history entries agree on overlapping abstract states

push(x)

{ ∃t, xs. Hs = t ↦ (xs, x::xs) ⋀ H ⊆ Ho ⋀ H < t }@Cstack

Stack specification

{ Hs = ∅ ⋀ H ⊆ Ho }

push(x)

Stack specification

{ Hs = ∅ ⋀ H ⊆ Ho }

self-contribution is a single entry

push(x)

Stack specification

{ Hs = ∅ ⋀ H ⊆ Ho }

t allocated during the call

{ res. if (res = Some x) then ∃t, xs. H ⊆ Ho ⋀ H < t ⋀ Hs = t ↦ (x::xs, xs)) else ∃t. H ⊆ Ho ⋀ H ≤ t ⋀ Hs = ∅ ⋀ t ↦ (_, Nil) ⊆ Ho }@Cstack

Stack specification

{ Hs = ∅ ⋀ H ⊆ Ho }

Stack specification

{ Hs = ∅ ⋀ H ⊆ Ho }

• pop has hit Nil during its execution at the moment t

Stack specification

{ Hs = ∅ ⋀ H ⊆ Ho }

no self-contributions initially?

Framing in FCSL

my_program

Framing in FCSL

{ }my_program

Framing in FCSL

{ }my_program

Framing in FCSL

{ }my_program

Framing in FCSL

{ }my_program

Works for any PCM, not just heaps!

push(x)

{ ∃t, xs. H ⊆ Ho ⋀ H < t ⋀ Hs = t ↦ (xs, x::xs) }@Cstack

{ Hs = ∅ ⋀ H ⊆ Ho }

Framing histories

push(x)

{ ∃t, xs. H2 ⊆ Ho ⋀ H1 ⊕ H2 < t ⋀ Hs = H1 ⊕ t ↦ (xs, x::xs) }@Cstack

{ Hs = H1 ⋀ H2 ⊆ Ho }

Framing histories

push(x)

{ Hs = H1 ⋀ H2 ⊆ Ho }

Framing histories

initial self-contribution

push(x)

{ Hs = H1 ⋀ H2 ⊆ Ho }

Framing histories

final self-contribution

• Histories

Key ideas

• Histories — logical updates via auxiliary state

Key ideas

How useful are histories for clients?

A stack client program

• Two threads: producer and consumer

• Ap — an n-element producer array

• Ac — an n-element consumer array

• A shared concurrent stack S is used as a buffer

• The goal: prove the exchange correct

• Pushed H E iff E is a multiset of elements, pushed in H

• Popped H E iff E is a multiset of elements, popped in H

Auxiliary Predicates

letrec produce(i : nat) = { if (i == n) then return; else { S.push(Ap[i]); produce(i+1); }}

{ Ap ↦ L ⋀ Pushed Hs L[< i] ⋀ Popped Hs ∅ }

{ Ap ↦ L ⋀ Pushed Hs L[< n] ⋀ Popped Hs ∅ }

letrec produce(i : nat) = { if (i == n) then return; else { S.push(Ap[i]); produce(i+1); }}

{ Ap ↦ L ⋀ Pushed Hs L[< i] ⋀ Popped Hs ∅ }

{ Ap ↦ L ⋀ Pushed Hs L[< n] ⋀ Popped Hs ∅ }

letrec consume(i : nat) = { if (i == n) then return; else { t ← S.pop(); if t == Some v then { Ac[i] := v; consume(i+1); } else consume(i); }}

{∃L, Ac ↦ L ⋀ Pushed Hs ∅ ⋀ Popped Hs L[< i] }

{∃L, Ac ↦ L ⋀ Pushed Hs ∅ ⋀ Popped Hs L[< n] }

letrec consume(i : nat) = { if (i == n) then return; else { t ← S.pop(); if t == Some v then { Ac[i] := v; consume(i+1); } else consume(i); }}

{∃L, Ac ↦ L ⋀ Pushed Hs ∅ ⋀ Popped Hs L[< i] }

{∃L, Ac ↦ L ⋀ Pushed Hs ∅ ⋀ Popped Hs L[< n] }

consume(0)produce(0)

��

hide Cstack(hS) in

��

No other threadscan interfere on S

hide Cstack(hS) in

��

{ Ap ↦ L ⊕ Ac ↦ L′ ⊕ hS }

hide Cstack(hS) in

��

{ Ap ↦ L ⊕ Ac ↦ L′ ⊕ hS }

{ Ap ↦ L { Ac ↦ L′

hide Cstack(hS) in

��

{ Ap ↦ L ⊕ Ac ↦ L′ ⊕ hS }

{ Ap ↦ L { Ac ↦ L′ ⋀ Pushed Hs ∅ ⋀ Popped Hs ∅ } ⋀ Pushed Hs ∅ ⋀ Popped Hs ∅ }

hide Cstack(hS) in

��

{ Ap ↦ L ⊕ Ac ↦ L′ ⊕ hS }

{ Ap ↦ L ⋀ Pushed Hs L[< n] ⋀

Popped Hs ∅ }

{ Ac ↦ L′′ ⋀ Pushed Hs ∅ ⋀

Popped Hs L′′[<n] }

hide Cstack(hS) in

��

{ Ap ↦ L ⊕ Ac ↦ L′ ⊕ hS }

Popped Hs ∅ }

These are the only changes in the stack’s history

hide Cstack(hS) in

��

{ Ap ↦ L ⊕ Ac ↦ L′ ⊕ hS }

Popped Hs ∅ }

{ Ap ↦ L ⊕ Ac ↦ L′′ ⊕ hS′ ⋀ L =set L′′}

hide Cstack(hS) in

��

{ Ap ↦ L ⊕ Ac ↦ L′ ⊕ hS }

Popped Hs ∅ }

{ Ap ↦ L ⊕ Ac ↦ L′′ ⊕ hS′ ⋀ L =set L′′}

hide Cstack(hS) in

More use for histories(see the paper)

More use for histories

• Verifying atomic snapshots

(see the paper)

• Instantiating higher-order concurrent structures

(see the paper)

• Deriving sequential specifications via hiding

(see the paper)

• Deriving sequential specifications via hiding

(see the paper)

To take away

• Histories as auxiliary state- Expressive abstraction for concurrent specs

To take away

• Histories are a PCM-They are subject of the same rules as heaps

To take away

• Historical reasoning requires subjectivity- History-based specs often talk about the effect of other threads

To take away

software.imdea.org/fcsl

To take away

Thanks!

software.imdea.org/fcsl

Q&A slides

Owicki-Gries (1976)

CSL (2004)Rely-Guarantee (1983)

SAGL (2007) RGSep (2007)

Deny-Guarantee (2009)

CAP (2010) Jacobs-Piessens (2011)

Liang-Feng (2013)

LRG (2009)

SCSL (2013)HOCAP (2013)

iCAP (2014)

Iris (2015)

CaReSL (2013)

FCSL (2014)

TaDA (2014)

CoLoSL (2015)

Gotsman-al (2007)

HLRG (2010)

Bornat-al (2005)

RGSim (2012)

How is your stuff different from other existing concurrent logics?

• [Owicki-Gries:CACM76] - reasoning about parallel composition is not compositional; subjectivity fixes that;

• [OHearn:CONCUR04] - only one type of resources — critical sections; FCSL allows one to define arbitrary resources;

• [Feng-al:ESOP07,Vafeiadis-Parkinson:CONCUR07] - framing over Rely/Guarantee, but only one shared resource: FCSL allows multiple ones;

• [Feng:POPL09] - introduced local Rely/Guarantee; FCSL improves on it by introducing a subjective state and explicitly identifying resources as STS;

• [DinsdaleYoung-al:ECOOP10] - first introduced concurred protocols;FCSL generalises permissions - self-state defines what a thread is allowed to do with a resource;

• [DinsdaleYoung-al:POPL13] - general framework for concurrency logic;FCSL is a particular logic, not clear whether it is an instance of Views;

• [Turon-al:ICFP13] - CaReSL and reasoning about contextual refinement;FCSL doesn’t address CR, in our experience it’s never required for Hoare-style reasoning;

• [Svendsen-al:ESOP13,ESOP14] - use much richer semantic domain, FCSL uses transitions and communication instead of view-shifts for changes in state and composition of resources;

• [Raad-al:ESOP15] - different notion of subjectivity, no self/other dichotomy, no observation made about PCMs.

FCSL’s assertions work explicitly with state variables.

How is your stuff different from Iris?

• Iris makes the same observations as FCSL did in 2014 (PCMs, Invariants);

• Iris doesn’t have hiding and self/other dichotomy;

• It considers more primitive “building blocks” and encodes protocols as STSs + interpretation;

• This encoding is made default in FCSL, and so far it suffices;

• Currently, FCSL doesn’t support abstract atomicity in Iris/iCAP sense (however, it can recover most of it through the choice of PCMs).

Jung-al [POPL’15]

Encoding verification in FCSL

Encoding verification in FCSLProgram Definition my_prog: STSep (p, q) :=

• Program c’s weakest pre- and strongest postconditions (p*, q*) wrt. safety, inferred from the types of basic commands (ret, par, bind);

has type STSep (p*, q*)

• Do encodes the application of the rule of consequence (p*, q*) ⊑ (p, q);

Notation for do (_ : (p*, q*) ⊑ (p, q)) c

• The client constructs the proof of (p*, q*) ⊑ (p, q) interactively;

• The obligations are reduced via structural lemmas (inference rules).

Program Libs Conc Acts Stab Main Total Build

CAS-lock 63 291 509 358 27 1248 1m 1s

Ticketed lock 58 310 706 457 116 1647 2m 46s

Increment 26 - - - 44 70 8s

Allocator 82 - - - 192 274 14s

Pair snapshot 167 233 107 80 51 638 4m 7s

Treiber stack 56 323 313 133 155 980 2m 41s

Spanning tree 348 215 162 217 305 1247 1m 11s

Flat combiner 92 442 672 538 281 2025 10m 55s

Seq. stack 65 - - - 125 190 1m 21s

FC-stack 50 - - - 114 164 44s

Prod/Cons 365 - - - 243 608 2m 43s

Table 1: Statistics for implemented programs: lines of codefor program-specific libraries (Libs), definitions of concur-roids and decorations (Conc), actions (Acts), stability lem-mas (Stab), spec and proof sizes of the main functions(Main), total LOC count (Total), and build times (Build).

CAS-lock Ticketed lock

Abstract lock

CG incrementor

CG Allocator

Flat combiner

FC stackTreiber stack

Sequential stack Producer/Consumer

Figure 5: Dependencies between concurrent libraries.

given specs via a PCM of time-stamped action histories inthe spirit of linearizability [Herlihy and Wing 1990], as wellas several client programs: a sequential stack (obtained fromTreiber stack via hiding), FC-based stack, and a Treiberstack-based concurrent Producer/Consumer.

Table 1 presents some statistics wrt. implemented pro-grams in terms of LOCs and build times. The program suitewas compiled on a 2.7 GHz Intel Core i7 OS X machine with8 Gb RAM, using Coq 8.4pl4 and Ssreflect 1.4. We didn’trely on any advanced proof automation in the proof scripts,which would, probably, decrease line counts at the expenseof increased compilation times. Notably, for those programsthat required implementing new primitive concurroids (e.g.,locks or Treiber stack), a large fraction of an implementa-tion is due to proofs of properties of transitions and actions,as well as stability-related lemmas, while the sizes of proofsof the main programs’ specs are always relatively small.

Our development is inherently compositional, as illus-trated by the dependency diagram on Figure 5. For exam-ple, both lock implementations are instances of the abstractlock interface, which is used to implement and verify theallocator, which is then employed by a Treiber stack, usedas a basis for sequential stack and producer/consumer im-plementations. In principle, we could implement an abstractinterface for stacks, too, to unify the Treiber stack and theFC-stack, although, we didn’t carry out this exercise.

Program P

CAS-lock 3 3Ticketed lock 3 3CG increment 3 3L 3LCG allocator 3 3L 3LPair snapshot 3Treiber stack 3 3L 3L 3Spanning tree 3 3Flat combiner 3 3L 3L 3Seq. stack 3 3L 3L 3FC-stack 3 3L 3L 3Prod/Cons 3 3L 3L 3

Table 2: Primitive concurroids (in column headings) em-ployed by different programs. Two lock concurroids, forCAS-based and ticketed locks, are interchangeable, as theyimplement the same abstract interface (indicated by 3L).

As hinted by Table 1, not every concurrent program re-quires implementing a new primitive concurroid: typicallythis is done only for libraries, so library clients can reasonout of the specifications. Table 2 shows that the reuse of con-curroids is quite high, and most of the programs make con-sistent use of the concurroid for thread-local state and locks(abstracted through the corresponding interface), as well asof those required by the used libraries (e.g., Treiber or FC).

7. Related and future workUsing the Coq proof assistant as a uniform platform for im-plementation of logic-based program verification tools is awell-established approach, which by now has been success-fully employed in a number of projects on certified com-pilers [Leroy 2006; Appel et al. 2014] and verified low-level code [Shao 2010; Chlipala 2011; Jensen et al. 2013],although, with no specific focus on abstractions for fine-grained concurrency, such as protocols and auxiliary state.Related program logics. The FCSL logic has been designedas a generalization of the classical Concurrent SeparationLogic by O’Hearn [2007], combining the ideas of local con-current protocols with arbitrary interference [Jones 1983;Feng 2009] and compositional auxiliary state [Ley-Wildand Nanevski 2013] with the possibility to compose pro-tocols. Other concurrency logics, close to FCSL in theirexpressive power, are iCAP [Svendsen and Birkedal 2014],CoLoSL [Raad et al. 2014], and CaReSL [Turon et al. 2013].

iCAP leverages the idea, originated by Jacobs and Piessens[2011], of parametrizing specs for fine-grained concurrentdata types by client-provided auxiliary code, which can beseen as a “callback”. A form of composition of concurrentresources can be encoded in iCAP using fractional permis-sions [Bornat et al. 2005] and view-shifts [Dinsdale-Younget al. 2013]. Since iCAP doesn’t have explicit subjective di-chotomy of the auxiliary state, encoding of thread-specificcontributions in it is less direct comparing to FCSL.

Implementation and evaluation

Proof of push specification

Proof of push specification Next Obligation.apply: gh=>i [h hS][B][v] X C.case: C (C) X=>_ [_][xa][->{i}][_][xp][xt][->] Cp Ct Ca C [P S H].rewrite (getC Cp C) !(getC Ct C) /= in P S H. rewrite -!joinA joinCA in C *. apply: step; apply: val_extend=>//;apply: (gh_ex h); apply: val_do=>//.move=>p' {xt S H C Ct Ca} xt [t][K] S H _ Ct s C M. case: {M} (menvs_coh M) (M) C=>_ [_][xp1][xa1][->{s}] Cp1 Ca M C.case/(menvs_split (injLE _ (erefl _)) Cp Cp1): M=>/= M _.have {M P} P : pv_self xp1 = p :-> v \+ hS by rewrite -(menvs_loc M).rewrite -joinCA in C *.apply: step; apply: val_extend=>//.apply: (gh_ex hS); apply: val_do; first by exists B, v. case=>{xp xp1 xa C Cp Cp1 Ca P} xp P Cp s /= C M.case: {M} (menvs_coh M) (M) C=>_ [_][xt1][xa][->{s}] Ct1 Ca M C.case/(menvs_split (injLA _ (erefl _)) Ct Ct1): M=>/= {xa1} M _.have {S} S : tb_self xt1 = Unit by rewrite -(menvs_loc M).have {xt Ct M H} H : [h <<= tb_other xt1] by apply: hist_trans H (hist_other M).rewrite joinA in C *.apply: step; apply: val_extend; first by apply/(star_coh_prec C).apply: (gh_ex h); apply: (gh_ex hS); apply: val_do.- by move=>C'; rewrite (getC Cp C') !(getC Ct1 C'). move=>b s X Y; case: Y (Y) X=>_ [xp1][xt][->{s}] {Cp} Cp1 Ct Y X.move=>xa1 /= {C} C M; case: (menvs_coh M)=>_ {M xa Ca} Ca1.rewrite (getC Cp1 Y) !(getC Ct Y) in X. case: b X; last first.- case=>{P S H} P S H. apply: (gh_ex h); apply: (gh_ex hS); apply: val_do=>//. move=>{C} C; exists (prod A ptr), (e, p'). by rewrite (getC Cp1 C) !(getC Ct C).case=>{xp xt1 Ct1 P K S H} t' [ls][P K S H]. apply: val_ret=>//= m M; rewrite -(menvs_loc M).rewrite (getC Cp1 C) (getC Ct C).exists t', ls; split=>//.case: {M} (menvs_coh M) (M)=>_ /= X'.case: X' (X')=>_ [s][xa][->{m}] Y'; case: Y' (Y')=>_ [xp][xt1][->].move=>Cp Ct1 Y' {Ca1} Ca {C} C. case/(menvs_split (injLE _ (erefl _)) Y Y').case/(menvs_split (injLE _ (erefl _)) Cp1 Cp)=> _ M _.by rewrite (getC Ct1 C); apply: hist_trans H (hist_other M).

apply: gh=>i [h hS] X C.case: C (C) X =>_ [_][xa][->][_][xp][xt][->] Cp Ct Ca C /= [P Ps H].rewrite !(getC Ct C) !(getC Cp C) /= in P Ps H.rewrite joinAC /V /= starAC in C *.apply: step; apply: val_extend; first by apply/(star_coh_prec C). apply: (gh_ex (pv_self xp)); apply: val_do. - by move=>Cpa; rewrite (getC Cp Cpa).move=>x m [B][v] Y X {Cp Ca C}.case: X (X) Y=>_ [xp1][xa1][->{m}] /= Cp Ca X S xt1 C M.rewrite {X} (getC Cp X) in S.case: (menvs_coh M)=>_ /= {Ct} Ct.have {P} P : tb_self xt1 = Unit by rewrite -(menvs_loc M).have {H M} H : [h <<= tb_other xt1] by apply: hist_trans H (hist_o M).apply: (gh_ex h); apply: (gh_ex (pv_self xp)).apply: val_do=>[_|]; first by exists B, v; rewrite!(getC Ct C).case=>m [t][ls][P2 S2 H2 K2]; exists t, ls; rewrite P2; split=>//.Qed.

Next Obligation.apply: gh=>i [h hS][B][v] X C.case: C (C) X=>_ [_][xa][->{i}][_][xp][xt][->] Cp Ct Ca C [P S H].rewrite (getC Cp C) !(getC Ct C) /= in P S H. rewrite -!joinA joinCA in C *. apply: step; apply: val_extend=>//;apply: (gh_ex h); apply: val_do=>//.move=>p' {xt S H C Ct Ca} xt [t][K] S H _ Ct s C M. case: {M} (menvs_coh M) (M) C=>_ [_][xp1][xa1][->{s}] Cp1 Ca M C.case/(menvs_split (injLE _ (erefl _)) Cp Cp1): M=>/= M _.have {M P} P : pv_self xp1 = p :-> v \+ hS by rewrite -(menvs_loc M).rewrite -joinCA in C *.apply: step; apply: val_extend=>//.apply: (gh_ex hS); apply: val_do; first by exists B, v. case=>{xp xp1 xa C Cp Cp1 Ca P} xp P Cp s /= C M.case: {M} (menvs_coh M) (M) C=>_ [_][xt1][xa][->{s}] Ct1 Ca M C.case/(menvs_split (injLA _ (erefl _)) Ct Ct1): M=>/= {xa1} M _.have {S} S : tb_self xt1 = Unit by rewrite -(menvs_loc M).have {xt Ct M H} H : [h <<= tb_other xt1] by apply: hist_trans H (hist_other M).rewrite joinA in C *.apply: step; apply: val_extend; first by apply/(star_coh_prec C).apply: (gh_ex h); apply: (gh_ex hS); apply: val_do.- by move=>C'; rewrite (getC Cp C') !(getC Ct1 C'). move=>b s X Y; case: Y (Y) X=>_ [xp1][xt][->{s}] {Cp} Cp1 Ct Y X.move=>xa1 /= {C} C M; case: (menvs_coh M)=>_ {M xa Ca} Ca1.rewrite (getC Cp1 Y) !(getC Ct Y) in X. case: b X; last first.- case=>{P S H} P S H. apply: (gh_ex h); apply: (gh_ex hS); apply: val_do=>//. move=>{C} C; exists (prod A ptr), (e, p'). by rewrite (getC Cp1 C) !(getC Ct C).case=>{xp xt1 Ct1 P K S H} t' [ls][P K S H]. apply: val_ret=>//= m M; rewrite -(menvs_loc M).rewrite (getC Cp1 C) (getC Ct C).exists t', ls; split=>//.case: {M} (menvs_coh M) (M)=>_ /= X'.case: X' (X')=>_ [s][xa][->{m}] Y'; case: Y' (Y')=>_ [xp][xt1][->].move=>Cp Ct1 Y' {Ca1} Ca {C} C. case/(menvs_split (injLE _ (erefl _)) Y Y').case/(menvs_split (injLE _ (erefl _)) Cp1 Cp)=> _ M _.by rewrite (getC Ct1 C); apply: hist_trans H (hist_other M).

seq seqfun_call

fun_call

return

Next Obligation.apply: gh=>i [h hS][B][v] X C.case: C (C) X=>_ [_][xa][->{i}][_][xp][xt][->] Cp Ct Ca C [P S H].rewrite (getC Cp C) !(getC Ct C) /= in P S H. rewrite -!joinA joinCA in C *. apply: step; apply: val_extend=>//;apply: (gh_ex h); apply: val_do=>//.move=>p' {xt S H C Ct Ca} xt [t][K] S H _ Ct s C M. case: {M} (menvs_coh M) (M) C=>_ [_][xp1][xa1][->{s}] Cp1 Ca M C.case/(menvs_split (injLE _ (erefl _)) Cp Cp1): M=>/= M _.have {M P} P : pv_self xp1 = p :-> v \+ hS by rewrite -(menvs_loc M).rewrite -joinCA in C *.apply: step; apply: val_extend=>//.apply: (gh_ex hS); apply: val_do; first by exists B, v. case=>{xp xp1 xa C Cp Cp1 Ca P} xp P Cp s /= C M.case: {M} (menvs_coh M) (M) C=>_ [_][xt1][xa][->{s}] Ct1 Ca M C.case/(menvs_split (injLA _ (erefl _)) Ct Ct1): M=>/= {xa1} M _.have {S} S : tb_self xt1 = Unit by rewrite -(menvs_loc M).have {xt Ct M H} H : [h <<= tb_other xt1] by apply: hist_trans H (hist_other M).rewrite joinA in C *.apply: step; apply: val_extend; first by apply/(star_coh_prec C).apply: (gh_ex h); apply: (gh_ex hS); apply: val_do.- by move=>C'; rewrite (getC Cp C') !(getC Ct1 C'). move=>b s X Y; case: Y (Y) X=>_ [xp1][xt][->{s}] {Cp} Cp1 Ct Y X.move=>xa1 /= {C} C M; case: (menvs_coh M)=>_ {M xa Ca} Ca1.rewrite (getC Cp1 Y) !(getC Ct Y) in X. case: b X; last first.- case=>{P S H} P S H. apply: (gh_ex h); apply: (gh_ex hS); apply: val_do=>//. move=>{C} C; exists (prod A ptr), (e, p'). by rewrite (getC Cp1 C) !(getC Ct C).case=>{xp xt1 Ct1 P K S H} t' [ls][P K S H]. apply: val_ret=>//= m M; rewrite -(menvs_loc M).rewrite (getC Cp1 C) (getC Ct C).exists t', ls; split=>//.case: {M} (menvs_coh M) (M)=>_ /= X'.case: X' (X')=>_ [s][xa][->{m}] Y'; case: Y' (Y')=>_ [xp][xt1][->].move=>Cp Ct1 Y' {Ca1} Ca {C} C. case/(menvs_split (injLE _ (erefl _)) Y Y').case/(menvs_split (injLE _ (erefl _)) Cp1 Cp)=> _ M _.by rewrite (getC Ct1 C); apply: hist_trans H (hist_other M).

seq seqfun_call

fun_call

return

proving stability

Why do you need the explicit other?Other logics don’t have it!

• Other makes it possible to state open-world assumptions in a straightforward way (e.g., in push);

• It allows us to use hiding for uniformly cancelling the interference;

• Some algorithms are given more natural specs via other-contributions (e.g., stack’s pop and atomic snapshots).

Composing concurrent resources

Connect ownership-transferring transitions with right polarity

acqacq rel

• Some channels might be left loose

• Some channels might be shut down

• Same channels might be connected several times

Can you extract the verified programfrom your Coq implementation and run it?

Not yet.

Can you extract the verified programfrom your Coq implementation and run it?

Not yet.

• Imperative programs are composed and verified (i.e., type-checked) by means of Coq;

• They cannot be run by means of Gallina’s operational semantics;

• The reason for that is the necessity to reason about concurrent computations and potentially diverging programs;

• Extraction will require proving operationally of arbitrary atomic actions.

Specifying and Verifying Concurrent Algorithms Histories...

Documents

Transcript of Specifying and Verifying Concurrent Algorithms Histories...

Monday 3 August 2020...0810-0825 0825-0835 0835-1010 Chair: 0835-0920 0920-0925 Chair 0925-1010 1010-1020 1020-1150 Concurrent 1A Concurrent 1B Concurrent 1C Concurrent 1D Concurrent

Concurrent Programming

Erlang - Concurrent Language for Concurrent World

FCSL College Instruction Flyer

Concurrency: concurrent execution1 ©Magee/Kramer Chapter 3 Concurrent Execution.

Introducing Concurrent Functional Programming in the ... · Introducing Concurrent Functional Programming in the Telecommunications Industry Bjarne Dacker ... Introducing Concurrent

Session 3: Case Histories. General Report.materias.fi.uba.ar/6408/general report on case histories.pdf · Jet grouting was extensively employed to improve soil conditions in the passive

Concurrent Monitoring

Concurrent & Distributed Systems 2017 Concurrency... · Concurrent & Distributed Systems 2017. ... Principles of Concurrent and Distributed Programming ... “Concurrent programming

ANNUAL REPORT ON CONCURRENT … Concurrent Enrollment...Accelerating Students through Concurrent ENrollmenT ... Concurrent Enrollment Credit Hours Attempted and Passed ... (C.R.S.

Concurrent Prog

Designer-Authored Histories: Graphic Design at the ...faculty.design.umn.edu/mccarthy/designer-authored-histories.pdf · Designer-Authored Histories: Graphic Design at the Goldstein

Concurrent Disorders; Pharmacotherapy - AddictionDay.ca 1/Concurrent Disorder Kinjo.pdfSubstance Abuse and Concurrent Disorders. February 2015. Health Canada Best Practices; Concurrent

Concurrent Programme

Concurrent programming1

Concurrent Software Testing: A Systematic Review and an ... · extensive use of concurrent systems warrants more attention to the concurrent software testing. For testing concurrent

Introduction: Concurrent Programming - Concurrent …Every concurrent programming model must answer two questions: 1. How to express that two executions are concurrent? ... The second

Zagorin - Carl Becker on History Professor Becker's Two Histories.pdf

FCSL Ethics Curriculum

IGDS Concurrent Engineering Module, 25 th February 2003 Concurrent Teams Concurrent Teams Teams IGDS Concurrent Engineering Module, 25 th February 2003.