Type and proof structures for concurrency

Type and Proof Structures
for Concurrency
Universidad Complutense de Madrid

April 19, 2022
Aleksandar Nanevski

IMDEA Software Institute, Madrid
In collaboration with Ruy-Ley Wild, Ilya Sergey, Anindya Banerjee,

German Delbianco, Ignacio Fabregas,

Frantishek Farka, Joakim Ohman and Jesus Dominguez
1
Concurrent programs & their formal proofs
In programs
2
In formal proofs
Proofs overwhelmingly detailed
Proof of component depends
on state of another
Code reuse
Must redo proofs for every new
use context
Code abstraction
Information hiding
2
Applying programming ideas to proofs
Most approaches: automate spurious proof obligations.
Our approach: avoid proof obligations by hiding, abstraction & reuse.
Curry-Howard isomorphism: proofs = programs
- for purely-functional programs
3
Goal: new foundations for concurrent progs, specs & proofs
• Linguistic & math concepts that make proofs scale

• Do for proofs what structured programming did for programming
3
1. Subjective state
2. Specifying ADTs
3. State transition systems as types
4. Function types
Outline
4
complu.key - 19 April 2022

5
{x = 0}
{x = 2}
⌦
x := x + 1
↵
k
⌦
x := x + 1
↵
Starting point: Owicki-Gries auxiliary (ghost) state
Notation: < e > - lock; execute e; unlock.
Prove without enumerating all thread interleaving
5
Resource invariant: V = x ↦ a+b
{x = 0}
⌧
x := x + 1;
a := a + 1
k
⌧
x := x + 1;
b := b + 1
{x = 2}
Type-theoretic move
6
Starting point: Owicki-Gries auxiliary (ghost) state
6
Say we want to show that a 3-way increment adds 3 to x.
Requires a new resource invariant: V = x ↦ a+b+c.
Problem: The two-thread subproof can’t be reused because it relies
on V = x ↦ a+b.
Proofs depend on thread topology
⌧
x := x + 1;
a := a + 1
k
⌧
x := x + 1;
b := b + 1
k
⌧
x := x + 1;
c := c + 1
7
7
Proofs depend on thread topology
8
incr 0 = skip
incr (n+1) = <x:=x+1> || incr n
8

V ⊨ {P} e {Q}
9
How to hide thread topology?
Idea: let’s turn Hoare triples into types
- dependent monads

- not a mere syntactic change
e : [x1,…,xn]. ST {P}{Q}@V
e : ST {P}{Q}@V
“logical” variables
9
⟨x := x+1; a := a+1⟩: ST {a=0}{a=1}@(x ↦a+b)
⟨x := x+1; b := b+1⟩: ST {b=0}{b=1}@(x ↦a+b)
What is Hoare type for increment?
10
10
⟨x := x+1; a := a+1⟩: ST {a=0}{a=1}@(x ↦a+b)
⟨x := x+1; b := b+1⟩: ST {b=0}{b=1}@(x ↦a+b)
11
∀a.
∀b.
𝝀
a.
𝝀
b.
11
⟨x := x+1; a := a+1⟩: ST {a=0}{a=1}@(x ↦a+b)
⟨x := x+1; b := b+1⟩: ST {b=0}{b=1}@(x ↦a+b)
12
∀ab.
∀ba.
𝝀
ab.
𝝀
ba.
12

Subjective ghost variables
Each thread and type should have two local variables.
- as - how much ”we” added to x

- ao - how much ”others” added to x (novel kind of variable)
13
13
In 3-way increment:
Relating to old ghosts
| left thread | middle thread | right thread |
as | a | b | c |
ao | b + c | c + a | a + b |
14
Resource invariant V = x ↦ (as + ao) is same in all threads
The variables as and ao are local but not independent.
14
child1 child2
||
parent
{ as = b1+b2, ao = c }
parent′
15
Remodeling parallel composition
15
{ as = b1+b2, ao = c }
child1 child2
||
parent
parent′
16
{ as = b1, ao = b2+c } { as = b2, ao = c+b1 }
Once forked, child1 is part of child2’s environment, and vice-versa.
16

{ as = b2′, ao = c2′ }
{ as = b1′, ao = c1′ }
{ as = b1+b2, ao = c }
{ as = b1, ao = b2+c } { as = b2, ao = c+b1 }
child1 child2
||
parent
parent′
17
Once forked, child1 is part of child2’s environment, and vice-versa.
{ as = b1′+b2′, ao = c1′-b2′ = c2′-b1′ }
17
Subjective conjunction
e1 : ST {P1} {Q1} e2 : ST {P2} {Q2}
e1 k e2 : ST {P1 ~ P2} {Q1 ~ Q2}
18
18
(as, ao) ⊨ P1 ⊛ P2 iff
∃a1 a2. as = a1+a2 and
(a1, a2+ao) ⊨ P1 and (a2, a1+ao) ⊨ P2
e1 : ST {P1} {Q1} e2 : ST {P2} {Q2}
e1 k e2 : ST {P1 ~ P2} {Q1 ~ Q2}
19
19
(as, ao) ⊨ P1 ⊛ P2 iff
∃a1 a2. as = a1+a2 and
(a1, a2+ao) ⊨ P1 and (a2, a1+ao) ⊨ P2
e1 : ST {P1} {Q1} e2 : ST {P2} {Q2}
e1 k e2 : ST {P1 ~ P2} {Q1 ~ Q2}
20
Works for every (partial) commutative, associative
operation with unit (PCM)
20

as ⊨ P1 * P2 iff
∃a1 a2. as = a1 ⨃!a2 and
a1 ⊨ P1 and a2 ⊨ P2
21
Relationship to separation logic
<latexit sha1_base64="sQOrDzMfcFhQjaTsu04+cQ62YzA=">AAAC3nicdZJNb9NAEIbXLh/FfDSUYzmsqCohVEV2hIBjCxeOqUTaSN4orNeTZNX12t0dIyLLh144tCCu/VUcuPFDuLN2IgFtMpLlV/PuPDszdlIoaTEMf3n+xq3bd+5u3gvuP3j4aKvzePvY5qURMBC5ys0w4RaU1DBAiQqGhQGeJQpOktN3jX/yCYyVuf6A8wJGGZ9qOZGCo0uNO79ZAlOpK24Mn9eVqAOG8BlbcJWoEuqKVf1xxOqa7YN776/wj1qfsrOzkqd0NaG3JPTWEFqfsVkzyJoe6Av6lxOxghuuFCi6HtqULNABA50upwyCcWc37IZt0JsiWordg8OvP54O9+L+uPOTpbkoM9AoFLc2jsICR46HUihw9NJCwcUpn0LspOYZ2FHVtlPTPZdJ6SQ37tFI2+y/FRXPrJ1niTuZcZzZ616TXOXFJU7ejCqpixJBi8VFk1JRzGnzrWkqDQhUcye4MNL1SsXMbU2g+yOaJUTXR74pjnvd6FX35ZHbxluyiE2yQ56R5yQir8kBeU/6ZECEF3vn3oV36X/0v/jf/O+Lo763rHlC/gv/6g+2ne2K</latexit>
{P1} e1 {Q1} {P2} e2 {Q2}
{P1 ⇤ P2} e1 k e2 {Q1 ⇤ Q2}
Where as is a heap variable and ⨃is disjoint heap union.
21
Framing in separation logic
if
e : ST {P} {Q}
then
e : ST {P *R} {Q *R}
22
22
Framing in our system
if
e : ST {as = a ∧ ao = c} {as = b ∧ ao = d}
then
e : ST {as = a+r ∧ ao = c-r} {as = b+r ∧ ao = d-r}
23
23
Fault avoidance
In separation logic:
Veri
fi
ed programs don’t fault
if starting state satis
fi
es precondition
24
In our setting:
Well-typed programs don’t go wrong
Conclusion: separation logic = type theory of state
24

One program/ghost state/proof for all contexts
25
{as = 0, ao = }
⌧
x := x + 1;
as := as + 1
{as = 1, ao = }
{as = 0, ao = }
⌧
x := x + 1;
as := as + 1
{as = 1, ao = }
25
26
{as = 0, ao = }
⌧
x := x + 1;
as := as + 1
{as = 1, ao = }
{as = 0, ao = }
⌧
x := x + 1;
as := as + 1
{as = 1, ao = }
{as = 0, ao = }
k
{as = 2, ao = }
Code/proof reuse
Same code, ghost code, proof on both sides of ||.
26
Code/proof reuse
27
incr 0 = {as = 0, ao = } skip {as = 0, ao = }
incr (n + 1) = {as = 0, ao = }
k
{as = n + 1, ao = }
{as = 0, ao = }
⌧
x := x + 1;
as := as + 1
{as = 1, ao = }
{as = 0, ao = }
incr n
{as = n, ao = }
Same code/proof can be substituted into any context
27
28
incr n
{as = 0, ao = }
{as = n, ao = }
Abstraction and information hiding
28

29
:
incr n
{as = 0, ao = }
{as = n, ao = }
ST
29
30
:
⌧
x := x + n;
as := as + n
{as = 0, ao = }
{as = n, ao = }
ST
30
1. Subjective state
2. Specifying ADTs
4. Function types
Outline
31
push(x): [xs]. ST {as = xs} {as = x :: xs}
pop():
Suitable for sequential case, but useless in concurrency
How to specify stacks?
[xs]. ST {as = xs}

{res = None ∧ as = xs = nil

∨ ∃x xs′. res = Some x ∧
 
xs = x :: xs′ ∧ as = xs′}
32
Need PCM for stack effects
32

x :: xs
Histories of abstract ops
xs
“timestamp”
tk →
abstract push
33
33
tk →
tk+1 →
tk+2 →
tk+3 →
…
…
tk+n →
|
{z
}
time increased at
 
every abstract operation
tk+4 →
Timestamps capture real time
34
34
as :AbsOps by “us” ao :AbsOps by “others”
tk+4 →
tk+1 →
tk+3 →
tk+n →
tk →
tk+2 →
…
…
Subjectivity with histories
35
35
tk →
tk+1 →
tk+2 →
tk+3 →
…
…
tk+n →
tk+4 →
Subjectivity with histories
36
as + ao :AbsOps “total”
disjoint union
36

Histories = Heaps as PCM
37
ℍ
𝕚
𝕤
𝕥
= (timestamps ⇀ n AbsOp, +, ∅)
ℍ
𝕖
𝕒
𝕡
= (pointers ⇀ n Values, +, ∅)
time
space
Separation logic = type theory of time as well
37
ST { }

{ }
Method specs
push(x) :
38
as = ∅
∃t xs. as = t ↦ (xs, x::xs)
38
ST { ⋀ ao = k}

{ ⋀

t > last k}
Method specs
push(x) :
39
as = ∅
∃t xs. as = t ↦ (xs, x::xs)
Similar to linearizability, but at user level
Non-local condition
39
[k]. ST {as = ∅ ⋀ ao = k}

{if res is Some x then

∃t xs. as = t ↦ (x::xs, xs) ⋀ t > last k

else as = ∅ ∧ ∃g. k ⊆ g ⊆ ao ∧ empty g}
Method specs
pop :
40
Recording unsuccessful pop is optional
- specifying histories at user level may be useful for relaxing
linearizability and implementing other correctness conditions
40

1. Subjective state
2. Specifying ADTs
4. Function types
Outline
41
How to specify lock-free programs?
42
Owicki-Gries = Resource Invariant (i.e., set of states)
- must lock whole stack before modi
fi
cation
For lock-free programs, add transitions:
- atomic moves allowed to the programs

- variant of Rely-Guarantee [Jones 83,
Dinsdale-Young et al. 2010]

- only programs of equal resource type
compose

Also relevant:
- Abadi+Lamport’s re
fi
nement mappings

- Lamport’s TLA
V
e : {P}{Q} @
42
Example: spin locks
Program lock :=

do

x ⟵ CAS (r, U, L)

while ¬x
Program unlock :=

r := U

43
SPIN resource and ghost histories
SPIN lock_t
unlock_t
id_t
lock_tr: ¬locked(as+ao) ∧ as’ = as + fresh(as+ao) ↦ L
unlock_tr: locked(as+ao) ∧ as’ = as + fresh(as+ao) ↦ U
State space (aka. invariant)
r = last_op (as+ao) ⋀

alternate (as+ao)
Transitions:
44

Ghost code chooses transitions
Program lock :=

do

x ⟵ CAS (r, U, L)

while ¬x
45
Program lock :=

do

⟨x ⟵ CAS (r, U, L);

if x then lock_tr else id_tr⟩

while ¬x
log successful locking
to history
46
Program unlock :=

r := U

47
Program unlock :=

⟨x ⟵ !r;

r := U;

if x = L then unlock_tr else id_tr⟩

If called when lock is
free, no change to history
48

Specs for lock and unlock
[k]. ST {as = ∅ ⋀ ao = k }

{∃t. as = t ↦ L ⋀ t > last k}@SPIN
lock :
[k]. ST {as = ∅ ⋀ ao = k }

{∃t. as = t ↦ U ⋀ t > last k ∨

as = ∅ ⋀ ∃g. k ⊆ g ⊆ ao ∧ locked g}@SPIN
unlock :
49
1. Subjective state
2. Specifying ADTs
4. Function types
Outline
50
Extending SPIN with new ghost state/
code
SPIN
Xclusive
./
<latexit sha1_base64="+oyDRQgndKL7ns1RU8PIBBY0fjY=">AAAB7nicbVDLSgNBEJyNrxhfUY9eBoPgKeyKoMegF48RzAOSJcxOOsmQ2ZllplcJSz7CiwdFvPo93vwbJ8keNLGgoajqprsrSqSw6PvfXmFtfWNzq7hd2tnd2z8oHx41rU4NhwbXUpt2xCxIoaCBAiW0EwMsjiS0ovHtzG89grFCqwecJBDGbKjEQHCGTmp1I/2EAnrlil/156CrJMhJheSo98pf3b7maQwKuWTWdgI/wTBjBgWXMC11UwsJ42M2hI6jisVgw2x+7pSeOaVPB9q4Ukjn6u+JjMXWTuLIdcYMR3bZm4n/eZ0UB9dhJlSSIii+WDRIJUVNZ7/TvjDAUU4cYdwIdyvlI2YYR5dQyYUQLL+8SpoX1cCvBveXldpNHkeRnJBTck4CckVq5I7USYNwMibP5JW8eYn34r17H4vWgpfPHJM/8D5/AHs2j6Y=</latexit>
SPIN
./
g
RW
./
SPIN
./
h
lock:
unlock:
51
Need functions to coerce programs
between resources
SPIN
Xclusive
./
SPIN
./
g
RW
./
SPIN
./
h
g^lock:
g^unlock:
h^lock:
h^unlock:
lock:
unlock:
52

V W
f
f∑
f
Resource morphism
tv
t0
v
<latexit sha1_base64="pjuXPYhYKAQ2JTuPc6vADmHSTug=">AAACAXicbVDLSsNAFJ34rPVVdelmsIiuSlIFXRbduKxgH9CGMplM2qEzkzBzUwihK/du9RfciVu/xD/wM0zTLGzrgQuHc+7l3nu8SHADtv1tra1vbG5tl3bKu3v7B4eVo+O2CWNNWYuGItRdjxgmuGIt4CBYN9KMSE+wjje+n/mdCdOGh+oJkoi5kgwVDzglkEsXg8mgUrVrdg68SpyCVFGB5qDy0/dDGkumgApiTM+xI3BTooFTwablfmxYROiYDFkvo4pIZtw0v3WKzzPFx0Gos1KAc/XvREqkMYn0sk5JYGSWvZn4n9eLIbh1U66iGJii80VBLDCEePY49rlmFESSEUI1z27FdEQ0oZDFs7DFgCQ60f60nEXjLAexStr1mnNVqz9eVxt3RUgldIrO0CVy0A1qoAfURC1E0Qi9oFf0Zj1b79aH9TlvXbOKmRO0AOvrF4hwl4c=</latexit>
t00
v
<latexit sha1_base64="pFxayxQwWe/Q2TytO2/GhPVj1/E=">AAACAnicbVBNT8JAEN3iF+IX6tHLRmLwRFo00SPRi0dMLJBAQ7bbLWzYbpvdKQlpuHn3qn/Bm/HqH/Ef+DNcoAcBXzLJy3szmZnnJ4JrsO1vq7CxubW9U9wt7e0fHB6Vj09aOk4VZS6NRaw6PtFMcMlc4CBYJ1GMRL5gbX90P/PbY6Y0j+UTTBLmRWQgecgpASO5UK32x/1yxa7Zc+B14uSkgnI0++WfXhDTNGISqCBadx07AS8jCjgVbFrqpZolhI7IgHUNlSRi2svmx07xhVECHMbKlAQ8V/9OZCTSehL5pjMiMNSr3kz8z+umEN56GZdJCkzSxaIwFRhiPPscB1wxCmJiCKGKm1sxHRJFKJh8lrZoiIiaqGBaMtE4q0Gsk1a95lzV6o/XlcZdHlIRnaFzdIkcdIMa6AE1kYso4ugFvaI369l6tz6sz0VrwcpnTtESrK9f7M+XuA==</latexit>
tw
<latexit sha1_base64="9BFCCmHNBXg7Q/VJZjRzda7Lv84=">AAACAHicbVDLSgNBEJz1GeMr6tHLYBA8hd0o6DHoxWNE84BkCbOzk2TIzOwy06ssSy7eveoveBOv/ol/4Gc4SfZgEgsaiqpuuruCWHADrvvtrKyurW9sFraK2zu7e/ulg8OmiRJNWYNGItLtgBgmuGIN4CBYO9aMyECwVjC6mfitR6YNj9QDpDHzJRko3ueUgJXuoffUK5XdijsFXiZeTsooR71X+umGEU0kU0AFMabjuTH4GdHAqWDjYjcxLCZ0RAasY6kikhk/m546xqdWCXE/0rYU4Kn6dyIj0phUBrZTEhiaRW8i/ud1Euhf+RlXcQJM0dmifiIwRHjyNw65ZhREagmhmttbMR0STSjYdOa2GJBEpzocF2003mIQy6RZrXjnlerdRbl2nYdUQMfoBJ0hD12iGrpFddRAFA3QC3pFb86z8+58OJ+z1hUnnzlCc3C+fgEl1JdX</latexit>
t0
w
<latexit sha1_base64="sFXF/L1Jtkxhjt6PM+LsnVi9H1A=">AAACAXicbVDLSsNAFL3xWeur6tJNsIiuSlIFXRbduKxgH9CGMplM2qEzkzAzUULoyr1b/QV34tYv8Q/8DKdpFrb1wIXDOfdy7z1+zKjSjvNtrayurW9slrbK2zu7e/uVg8O2ihKJSQtHLJJdHynCqCAtTTUj3VgSxH1GOv74dup3HolUNBIPOo2Jx9FQ0JBipHPpbPA0qFSdmpPDXiZuQapQoDmo/PSDCCecCI0ZUqrnOrH2MiQ1xYxMyv1EkRjhMRqSnqECcaK8LL91Yp8aJbDDSJoS2s7VvxMZ4kql3DedHOmRWvSm4n9eL9HhtZdRESeaCDxbFCbM1pE9fdwOqCRYs9QQhCU1t9p4hCTC2sQzt0VpjmQqg0nZROMuBrFM2vWae1Gr319WGzdFSCU4hhM4BxeuoAF30IQWYBjBC7zCm/VsvVsf1uesdcUqZo5gDtbXL4oKl4g=</latexit>
sv
<latexit sha1_base64="ya0ZJimwI5djbAoJaNF7beklUu0=">AAAB6nicbVA9SwNBEJ2LXzF+RQUbm8UgWIU7Gy2DNpYJmg9Ijri32UuW7O0du3OBcOQn2FgoYusvsrPxt7j5KDTxwcDjvRlm5gWJFAZd98vJra1vbG7ltws7u3v7B8XDo4aJU814ncUy1q2AGi6F4nUUKHkr0ZxGgeTNYHg79Zsjro2I1QOOE+5HtK9EKBhFK92b7qhbLLlldwaySrwFKVVOat+PAFDtFj87vZilEVfIJDWm7bkJ+hnVKJjkk0InNTyhbEj7vG2pohE3fjY7dULOrdIjYaxtKSQz9fdERiNjxlFgOyOKA7PsTcX/vHaK4bWfCZWkyBWbLwpTSTAm079JT2jOUI4toUwLeythA6opQ5tOwYbgLb+8ShqXZc8tezWbxg3MkYdTOIML8OAKKnAHVagDgz48wQu8OtJ5dt6c93lrzlnMHMMfOB8/+f6PwQ==</latexit>
<latexit sha1_base64="C54JSxT7bMatskI+fbY3KYY307c=">AAAB6nicbVC7SgNBFL0bXzG+ooKNzWAQrMKujZYhNpYJmgckS5id3CRDZmeXmdlAWPIJNhaK2Nr6F36BnY3f4uRRaOKBC4dz7uXee4JYcG1c98vJrK1vbG5lt3M7u3v7B/nDo7qOEsWwxiIRqWZANQousWa4EdiMFdIwENgIhjdTvzFCpXkk7804Rj+kfcl7nFFjpTvdGXXyBbfozkBWibcghdJJ9Zu/lz8qnfxnuxuxJERpmKBatzw3Nn5KleFM4CTXTjTGlA1pH1uWShqi9tPZqRNybpUu6UXKljRkpv6eSGmo9TgMbGdIzUAve1PxP6+VmN61n3IZJwYlmy/qJYKYiEz/Jl2ukBkxtoQyxe2thA2ooszYdHI2BG/55VVSvyx6btGr2jTKMEcWTuEMLsCDKyjBLVSgBgz68ABP8OwI59F5cV7nrRlnMXMMf+C8/QBLTpF9</latexit>
<latexit sha1_base64="1sESruR9R4xY0KPADaMXaTChtUw=">AAAB6nicbVBNS8NAEJ3Ur1q/qh69LBbBU0m86LHoxWNF+wFtKJvtpF262YTdTaGE/gQvHhTx6i/y5r9xm+agrQ8GHu/NMDMvSATXxnW/ndLG5tb2Tnm3srd/cHhUPT5p6zhVDFssFrHqBlSj4BJbhhuB3UQhjQKBnWByt/A7U1Sax/LJzBL0IzqSPOSMGis96sF0UK25dTcHWSdeQWpQoDmofvWHMUsjlIYJqnXPcxPjZ1QZzgTOK/1UY0LZhI6wZ6mkEWo/y0+dkwurDEkYK1vSkFz9PZHRSOtZFNjOiJqxXvUW4n9eLzXhjZ9xmaQGJVsuClNBTEwWf5MhV8iMmFlCmeL2VsLGVFFmbDoVG4K3+vI6aV/VPbfuPbi1xm0RRxnO4BwuwYNraMA9NKEFDEbwDK/w5gjnxXl3PpatJaeYOYU/cD5/AGtmjdw=</latexit>
sw
<latexit sha1_base64="LVw1ddLD+whBkwpG2PAgGmPmZL0=">AAAB6nicbVBNS8NAEJ3Ur1q/qh69LBbBU0lEqMeiF48V7Qe0oWy2k3bpZhN2N0oJ/QlePCji1V/kzX/jts1BWx8MPN6bYWZekAiujet+O4W19Y3NreJ2aWd3b/+gfHjU0nGqGDZZLGLVCahGwSU2DTcCO4lCGgUC28H4Zua3H1FpHssHM0nQj+hQ8pAzaqx0r/tP/XLFrbpzkFXi5aQCORr98ldvELM0QmmYoFp3PTcxfkaV4UzgtNRLNSaUjekQu5ZKGqH2s/mpU3JmlQEJY2VLGjJXf09kNNJ6EgW2M6JmpJe9mfif101NeOVnXCapQckWi8JUEBOT2d9kwBUyIyaWUKa4vZWwEVWUGZtOyYbgLb+8SloXVc+teneXlfp1HkcRTuAUzsGDGtThFhrQBAZDeIZXeHOE8+K8Ox+L1oKTzxzDHzifP24qjeE=</latexit>
tv
<latexit sha1_base64="LkPF2o8PLhHXPtY+Twsxofmc+58=">AAAB6nicbVA9SwNBEJ2LXzF+RQUbm8UgWIU7Gy2DNpYJmg9Ijri32UuW7O0du3OBcOQn2FgoYusvsrPxt7j5KDTxwcDjvRlm5gWJFAZd98vJra1vbG7ltws7u3v7B8XDo4aJU814ncUy1q2AGi6F4nUUKHkr0ZxGgeTNYHg79Zsjro2I1QOOE+5HtK9EKBhFK91jd9QtltyyOwNZJd6ClConte9HAKh2i5+dXszSiCtkkhrT9twE/YxqFEzySaGTGp5QNqR93rZU0YgbP5udOiHnVumRMNa2FJKZ+nsio5Ex4yiwnRHFgVn2puJ/XjvF8NrPhEpS5IrNF4WpJBiT6d+kJzRnKMeWUKaFvZWwAdWUoU2nYEPwll9eJY3LsueWvZpN4wbmyMMpnMEFeHAFFbiDKtSBQR+e4AVeHek8O2/O+7w15yxmjuEPnI8f+4SPwg==</latexit>
<latexit sha1_base64="yogQ0sl9dLU6iEIaAxFDkrUMrD4=">AAAB6nicbVC7SgNBFL0bXzG+ooKNzWAQrMKujZYhNpYJmgckS5idTJIhs7PLzN1AWPIJNhaK2Nr6F36BnY3f4uRRaOKBC4dz7uXee4JYCoOu++Vk1tY3Nrey27md3b39g/zhUd1EiWa8xiIZ6WZADZdC8RoKlLwZa07DQPJGMLyZ+o0R10ZE6h7HMfdD2leiJxhFK91hZ9TJF9yiOwNZJd6CFEon1W/xXv6odPKf7W7EkpArZJIa0/LcGP2UahRM8kmunRgeUzakfd6yVNGQGz+dnToh51bpkl6kbSkkM/X3REpDY8ZhYDtDigOz7E3F/7xWgr1rPxUqTpArNl/USyTBiEz/Jl2hOUM5toQyLeythA2opgxtOjkbgrf88iqpXxY9t+hVbRplmCMLp3AGF+DBFZTgFipQAwZ9eIAneHak8+i8OK/z1oyzmDmGP3DefgBM1JF+</latexit>
<latexit sha1_base64="uTa+d8w/YEP+jomnI7Xlribyhfs=">AAAB6nicbVBNS8NAEJ3Ur1q/qh69LBbBU0m86LHoxWNF+wFtKJvtpl262YTdSaGE/gQvHhTx6i/y5r9xm+agrQ8GHu/NMDMvSKQw6LrfTmljc2t7p7xb2ds/ODyqHp+0TZxqxlsslrHuBtRwKRRvoUDJu4nmNAok7wSTu4XfmXJtRKyecJZwP6IjJULBKFrpEQfTQbXm1t0cZJ14BalBgeag+tUfxiyNuEImqTE9z03Qz6hGwSSfV/qp4QllEzriPUsVjbjxs/zUObmwypCEsbalkOTq74mMRsbMosB2RhTHZtVbiP95vRTDGz8TKkmRK7ZcFKaSYEwWf5Oh0JyhnFlCmRb2VsLGVFOGNp2KDcFbfXmdtK/qnlv3Htxa47aIowxncA6X4ME1NOAemtACBiN4hld4c6Tz4rw7H8vWklPMnMIfOJ8/bOyN3Q==</latexit>
tw
53
f⌃
<latexit sha1_base64="WDa7fwy4dOrgnQkpLxQ0EUdGpOg=">AAAB73icbVC7TgMxEFyHVwivACUUFhESVXRHA2UEDWUiyENKTpHP8SVWbN9h+5CiU36ChgKEaPkDvoOOjk/BeRSQMNJKo5ld7e6EieDGet4Xyq2srq1v5DcLW9s7u3vF/YOGiVNNWZ3GItatkBgmuGJ1y61grUQzIkPBmuHweuI3H5g2PFZ3dpSwQJK+4hGnxDqpFXU7t7wvSbdY8sreFHiZ+HNSqhx/1L4BoNotfnZ6MU0lU5YKYkzb9xIbZERbTgUbFzqpYQmhQ9JnbUcVkcwE2fTeMT51Sg9HsXalLJ6qvycyIo0ZydB1SmIHZtGbiP957dRGl0HGVZJapuhsUZQKbGM8eR73uGbUipEjhGrubsV0QDSh1kVUcCH4iy8vk8Z52ffKfs2lcQUz5OEITuAMfLiACtxAFepAQcAjPMMLukdP6BW9zVpzaD5zCH+A3n8A856SHQ==</latexit>
<latexit sha1_base64="N4jqze7aWg8MBo2QnVwwspltK78=">AAAB73icbVDLSgNBEOyNrxhfUY+KDAbBU9jNRY9BLx4TNA9IljA7mU2GzMyuM7NCWHL0B7x4UMSrf5Dv8OY3+BNOHgdNLGgoqrrp7gpizrRx3S8ns7K6tr6R3cxtbe/s7uX3D+o6ShShNRLxSDUDrClnktYMM5w2Y0WxCDhtBIPrid94oEqzSN6ZYUx9gXuShYxgY6Vm2Gnfsp7AnXzBLbpToGXizUmhfDyufj+ejCud/Ge7G5FEUGkIx1q3PDc2foqVYYTTUa6daBpjMsA92rJUYkG1n07vHaEzq3RRGClb0qCp+nsixULroQhsp8Cmrxe9ifif10pMeOmnTMaJoZLMFoUJRyZCk+dRlylKDB9agoli9lZE+lhhYmxEORuCt/jyMqmXip5b9Ko2jSuYIQtHcArn4MEFlOEGKlADAhye4AVenXvn2Xlz3metGWc+cwh/4Hz8ANHjk4M=</latexit>
<latexit sha1_base64="42Ig8SllIAzYYebSWTC1eGIDUGM=">AAAB73icbVA9SwNBEJ2LXzF+RS1tFoNgFe5stAzaWEY0H5AcYW6zlyzZ3Tt394QQ8idsLBSx9e/Y+W/cJFdo4oOBx3szzMyLUsGN9f1vr7C2vrG5Vdwu7ezu7R+UD4+aJsk0ZQ2aiES3IzRMcMUallvB2qlmKCPBWtHoZua3npg2PFEPdpyyUOJA8ZhTtE5qx73uPR9I7JUrftWfg6ySICcVyFHvlb+6/YRmkilLBRrTCfzUhhPUllPBpqVuZliKdIQD1nFUoWQmnMzvnZIzp/RJnGhXypK5+ntigtKYsYxcp0Q7NMveTPzP62Q2vgonXKWZZYouFsWZIDYhs+dJn2tGrRg7glRzdyuhQ9RIrYuo5EIIll9eJc2LauBXgzu/UrvO4yjCCZzCOQRwCTW4hTo0gIKAZ3iFN+/Re/HevY9Fa8HLZ47hD7zPH+Okj9g=</latexit>
f⌃
sv
s0
v
<latexit sha1_base64="m6bWvuoxmnnr4NU/LXZswNEa6d0=">AAAB63icbVA9SwNBEJ2LXzF+RS1tlgQxVbiz0TJoYxnBfEByhL3NXrJkd+/Y3QuEI3/BxkIRW/+QnWDhT3Evl0ITHww83pthZl4Qc6aN6346hY3Nre2d4m5pb//g8Kh8fNLWUaIIbZGIR6obYE05k7RlmOG0GyuKRcBpJ5jcZn5nSpVmkXwws5j6Ao8kCxnBJpP0xWA6KFfdursAWifeklQbldrXNwA0B+WP/jAiiaDSEI617nlubPwUK8MIp/NSP9E0xmSCR7RnqcSCaj9d3DpH51YZojBStqRBC/X3RIqF1jMR2E6BzVivepn4n9dLTHjtp0zGiaGS5IvChCMToexxNGSKEsNnlmCimL0VkTFWmBgbT8mG4K2+vE7al3XPrXv3No0byFGEM6hADTy4ggbcQRNaQGAMj/AML45wnpxX5y1vLTjLmVP4A+f9B9z6kFM=</latexit>
<latexit sha1_base64="g2nYCA2SXEDfxyjw5Joe7rFEZv4=">AAAB63icbVA9TwJBEJ3zE/ELtbTZQIxU5M4GS6KNJSbykcCF7C17sGF377K7R0Iu/AUbC43a+mNs7Yz+GPeAQsGXTPLy3kxm5gUxZ9q47qeztr6xubWd28nv7u0fHBaOjps6ShShDRLxSLUDrClnkjYMM5y2Y0WxCDhtBaPrzG+NqdIskndmElNf4IFkISPYZJI+7417hZJbcWdAq8RbkFKtWP7+qr6/1HuFj24/Iomg0hCOte54bmz8FCvDCKfTfDfRNMZkhAe0Y6nEgmo/nd06RWdW6aMwUrakQTP190SKhdYTEdhOgc1QL3uZ+J/XSUx46adMxomhkswXhQlHJkLZ46jPFCWGTyzBRDF7KyJDrDAxNp68DcFbfnmVNC8qnlvxbm0aVzBHDk6hCGXwoAo1uIE6NIDAEO7hEZ4c4Tw4z87rvHXNWcycwB84bz/7DpHp</latexit>
<latexit sha1_base64="ipC0or+yRQF29BTGmzLjzhGego8=">AAAB63icbVBNSwMxEJ2tX7V+VT16CRbRU8l60WPRi8cK9gPapWTTbBuaZJckWyhL/4IXD4p49Q9589+YbfegrQ8GHu/NMDMvTAQ3FuNvr7SxubW9U96t7O0fHB5Vj0/aJk41ZS0ai1h3Q2KY4Iq1LLeCdRPNiAwF64ST+9zvTJk2PFZPdpawQJKR4hGnxOaSuRxMB9UaruMF0DrxC1KDAs1B9as/jGkqmbJUEGN6Pk5skBFtORVsXumnhiWETsiI9RxVRDITZItb5+jCKUMUxdqVsmih/p7IiDRmJkPXKYkdm1UvF//zeqmNboOMqyS1TNHloigVyMYofxwNuWbUipkjhGrubkV0TDSh1sVTcSH4qy+vk/Z13cd1/xHXGndFHGU4g3O4Ah9uoAEP0IQWUBjDM7zCmye9F+/d+1i2lrxi5hT+wPv8Acwrjg0=</latexit>
tv
tw = f swtv
<latexit sha1_base64="kChzev0P34CZrltDdEW5NkuA1mI=">AAAB/nicbVDJSgNBEK1xjXGLiic9NAbBU5jxohchqAePCZgFkjD0dHqSJj0L3TUJYQj4K148KOI13+HNm59iZzlo4oOCx3tVVNXzYik02vaXtbK6tr6xmdnKbu/s7u3nDg6rOkoU4xUWyUjVPaq5FCGvoEDJ67HiNPAkr3m9u4lf63OlRRQ+4jDmrYB2QuELRtFIbu4Y3cEN8d3mPZdIiXYHBN2+m8vbBXsKskycOckXT8flbwAoubnPZjtiScBDZJJq3XDsGFspVSiY5KNsM9E8pqxHO7xhaEgDrlvp9PwROTdKm/iRMhUimaq/J1IaaD0MPNMZUOzqRW8i/uc1EvSvW6kI4wR5yGaL/EQSjMgkC9IWijOUQ0MoU8LcSliXKsrQJJY1ITiLLy+T6mXBsQtO2aRxCzNk4ATO4AIcuIIiPEAJKsAghWd4hTfryXqx3q2PWeuKNZ85gj+wxj9J6pdC</latexit>
<latexit sha1_base64="ryaZN6yc0cMDZ8K5YpLOvK3UPoM=">AAAB/nicbVDLSgNBEJyNrxhfq+JJkcEgeAq7XvQiBPXgMQHzgCQss5PZZMjs7DLTmxCWgBc/xIsHRbzmO7z5Df6Ek8dBowUNRVU33V1+LLgGx/m0MkvLK6tr2fXcxubW9o69u1fVUaIoq9BIRKruE80El6wCHASrx4qR0Bes5vduJn6tz5TmkbyHYcxaIelIHnBKwEiefQDe4AoHXvOWCSBYewMMXt+z807BmQL/Je6c5ItH4/LX4/G45NkfzXZEk5BJoIJo3XCdGFopUcCpYKNcM9EsJrRHOqxhqCQh0610ev4InxqljYNImZKAp+rPiZSEWg9D33SGBLp60ZuI/3mNBILLVsplnACTdLYoSASGCE+ywG2uGAUxNIRQxc2tmHaJIhRMYjkTgrv48l9SPS+4TsEtmzSu0QxZdIhO0Bly0QUqojtUQhVEUYqe0At6tR6sZ+vNep+1Zqz5zD76BWv8DSgvmKg=</latexit>
<latexit sha1_base64="yrwD0HXsBLQFM6tA7+yKgTFRcRg=">AAAB/nicbVA9SwNBEN2LXzF+nYqVzWIQrMKdjTZCUAvLCCYGknDsbeaSJXsf7M4lhCPgX7GxUMTW32Hnv3GTXKGJDwYe780wM89PpNDoON9WYWV1bX2juFna2t7Z3bP3Dxo6ThWHOo9lrJo+0yBFBHUUKKGZKGChL+HRH9xM/cchKC3i6AHHCXRC1otEIDhDI3n2EXqjKxp47VuQyKj2RhS9oWeXnYozA10mbk7KJEfNs7/a3ZinIUTIJdO65ToJdjKmUHAJk1I71ZAwPmA9aBkasRB0J5udP6GnRunSIFamIqQz9fdExkKtx6FvOkOGfb3oTcX/vFaKwWUnE1GSIkR8vihIJcWYTrOgXaGAoxwbwrgS5lbK+0wxjiaxkgnBXXx5mTTOK65Tce+dcvU6j6NIjskJOSMuuSBVckdqpE44ycgzeSVv1pP1Yr1bH/PWgpXPHJI/sD5/ADnwlP0=</latexit>
sw
s0
w
<latexit sha1_base64="sUHl2pLOSUez0q0xPKPGVhAr0Jw=">AAAB63icbVBNSwMxEJ3Ur1q/qh69BIvoqeyKoMeiF48VbC20S8mm2TY0yS5JVilL/4IXD4p49Q9589+YbfegrQ8GHu/NMDMvTAQ31vO+UWlldW19o7xZ2dre2d2r7h+0TZxqylo0FrHuhMQwwRVrWW4F6ySaERkK9hCOb3L/4ZFpw2N1bycJCyQZKh5xSmwumdP+U79a8+reDHiZ+AWpQYFmv/rVG8Q0lUxZKogxXd9LbJARbTkVbFrppYYlhI7JkHUdVUQyE2SzW6f4xCkDHMXalbJ4pv6eyIg0ZiJD1ymJHZlFLxf/87qpja6CjKsktUzR+aIoFdjGOH8cD7hm1IqJI4Rq7m7FdEQ0odbFU3Eh+IsvL5P2ed336v7dRa1xXcRRhiM4hjPw4RIacAtNaAGFETzDK7whiV7QO/qYt5ZQMXMIf4A+fwDO744S</latexit>
Action of morphism f on program e
e: f^e:
Program e::

; …
tv
Program f^e::

;…
tw
54
Need invariant for the morphing loop
f⌃
f⌃
sv
s0
v
<latexit sha1_base64="m6bWvuoxmnnr4NU/LXZswNEa6d0=">AAAB63icbVA9SwNBEJ2LXzF+RS1tlgQxVbiz0TJoYxnBfEByhL3NXrJkd+/Y3QuEI3/BxkIRW/+QnWDhT3Evl0ITHww83pthZl4Qc6aN6346hY3Nre2d4m5pb//g8Kh8fNLWUaIIbZGIR6obYE05k7RlmOG0GyuKRcBpJ5jcZn5nSpVmkXwws5j6Ao8kCxnBJpP0xWA6KFfdursAWifeklQbldrXNwA0B+WP/jAiiaDSEI617nlubPwUK8MIp/NSP9E0xmSCR7RnqcSCaj9d3DpH51YZojBStqRBC/X3RIqF1jMR2E6BzVivepn4n9dLTHjtp0zGiaGS5IvChCMToexxNGSKEsNnlmCimL0VkTFWmBgbT8mG4K2+vE7al3XPrXv3No0byFGEM6hADTy4ggbcQRNaQGAMj/AML45wnpxX5y1vLTjLmVP4A+f9B9z6kFM=</latexit>
<latexit sha1_base64="ipC0or+yRQF29BTGmzLjzhGego8=">AAAB63icbVBNSwMxEJ2tX7V+VT16CRbRU8l60WPRi8cK9gPapWTTbBuaZJckWyhL/4IXD4p49Q9589+YbfegrQ8GHu/NMDMvTAQ3FuNvr7SxubW9U96t7O0fHB5Vj0/aJk41ZS0ai1h3Q2KY4Iq1LLeCdRPNiAwF64ST+9zvTJk2PFZPdpawQJKR4hGnxOaSuRxMB9UaruMF0DrxC1KDAs1B9as/jGkqmbJUEGN6Pk5skBFtORVsXumnhiWETsiI9RxVRDITZItb5+jCKUMUxdqVsmih/p7IiDRmJkPXKYkdm1UvF//zeqmNboOMqyS1TNHloigVyMYofxwNuWbUipkjhGrubkV0TDSh1sVTcSH4qy+vk/Z13cd1/xHXGndFHGU4g3O4Ah9uoAEP0IQWUBjDM7zCmye9F+/d+1i2lrxi5hT+wPv8Acwrjg0=</latexit>
tv
tw = f swtv
sw
s0
w
55
Need invariant for the morphing loop
• I is a simulation.
f⌃
f⌃
sv
<latexit sha1_base64="C54JSxT7bMatskI+fbY3KYY307c=">AAAB6nicbVC7SgNBFL0bXzG+ooKNzWAQrMKujZYhNpYJmgckS5id3CRDZmeXmdlAWPIJNhaK2Nr6F36BnY3f4uRRaOKBC4dz7uXee4JYcG1c98vJrK1vbG5lt3M7u3v7B/nDo7qOEsWwxiIRqWZANQousWa4EdiMFdIwENgIhjdTvzFCpXkk7804Rj+kfcl7nFFjpTvdGXXyBbfozkBWibcghdJJ9Zu/lz8qnfxnuxuxJERpmKBatzw3Nn5KleFM4CTXTjTGlA1pH1uWShqi9tPZqRNybpUu6UXKljRkpv6eSGmo9TgMbGdIzUAve1PxP6+VmN61n3IZJwYlmy/qJYKYiEz/Jl2ukBkxtoQyx
s0
v
tv tw = f swtv
sw
s0
w ∈ I
∈ I
56
comp u key - 19 Apr 2022

Inference Rule
e: {P} {Q}@ V
fê: { } { }@ W
f⌃
f⌃
tv
tw = f swtv
sw
s0
w
sv
<latexit sha1_base64="DoasoK3vs4rKNAfKGsarvVIU6kY=">AAAB6nicbVBNS8NAEJ34WetX1aOXxSJ4KkkV9Fj04rGi/YA2lM120i7dbMLuplBCf4IXD4p49Rd589+4bXPQ1gcDj/dmmJkXJIJr47rfztr6xubWdmGnuLu3f3BYOjpu6jhVDBssFrFqB1Sj4BIbhhuB7UQhjQKBrWB0N/NbY1Sax/LJTBL0IzqQPOSMGis96t64Vyq7FXcOskq8nJQhR71X+ur2Y5ZGKA0TVOuO5ybGz6gynAmcFrupxoSyER1gx1JJI9R+Nj91Ss6t0idhrGxJQ+bq74mMRlpPosB2RtQM9bI3E//zOqkJb/yMyyQ1KNliUZgKYmIy+5v0uUJmxMQSyhS3txI2pIoyY9Mp2hC85ZdXSbNa8S4r1Yercu02j6MAp3AGF+DBNdTgHurQAAYDeIZXeHOE8+K8Ox+L1jUnnzmBP3A+fwBt9I3k</latexit>
s0
v
<latexit sha1_base64="pjISp7sWaFWMHzuGAqRGYUPVupA=">AAAB63icbVBNSwMxEJ2tX7V+VT16CRbRU9ltBT0WvXisYD+gXUo2zbahSXZJsoWy9C948aCIV/+QN/+N2XYP2vpg4PHeDDPzgpgzbVz32ylsbG5t7xR3S3v7B4dH5eOTto4SRWiLRDxS3QBrypmkLcMMp91YUSwCTjvB5D7zO1OqNIvkk5nF1Bd4JFnICDaZpC8H00G54lbdBdA68XJSgRzNQfmrP4xIIqg0hGOte54bGz/FyjDC6bzUTzSNMZngEe1ZKrGg2k8Xt87RhVWGKIyULWnQQv09kWKh9UwEtlNgM9arXib+5/USE976KZNxYqgky0VhwpGJUPY4GjJFieEzSzBRzN6KyBgrTIyNp2RD8FZfXiftWtWrV2uP15XGXR5HEc7gHK7AgxtowAM0oQUExvAMr/DmCOfFeXc+lq0FJ585hT9wPn8AzrmOFQ==</latexit>
∈
∈ I
I
I
I
57
Inference Rule
e: {P} {Q}@ V
fê: {I⋀…} {I⋀…}@ W
f⌃
f⌃
tv
tw = f swtv
sw
s0
w
sv
s0
v
P
∈ I
∈ I
58
Inference Rule
e: {P} {Q}@ V
f⌃
f⌃
tv
tw = f swtv
sw
s0
w
sv
s0
v
Q ∈ I
∈ I
fê: {I⋀ } {I⋀…}@ W
f 1
⌃ P
59
Inference Rule
e: {P} {Q}@ V
f⌃
f⌃
tv
tw = f swtv
sw
<latexit sha1_base64="LVw1ddLD+whBkwpG2PAgGmPmZL0=">AAAB6nicbVBNS8NAEJ3Ur1q/qh69LBbBU0lEqMeiF48V7Qe0oWy2k3bpZhN2N0oJ/QlePCji1V/kzX/jts1BWx8MPN6bYWZekAiujet+O4W19Y3NreJ2aWd3b/+gfHjU0nGqGDZZLGLVCahGwSU2DTcCO4lCGgUC28H4Zua3H1FpHssHM0nQj+hQ8pAzaqx0r/tP/XLFrbpzkFXi5aQCORr98ldvELM0QmmYoFp3PTcxfkaV4UzgtNRLNS
sw
sv
sv ∈ I
∈ I
fê: {I⋀ } {I⋀ }@ W
f 1
⌃ P f 1
⌃ Q
60
comp u key - 19 Apr 2022

Morphing example
61
• Add n to a counter simultaneously with each locking.
Attaching behaviours to spin locks
SPIN
lock_tr
unlock_tr
id_tr
./
./
Counter
incr_tr n
id_tr
CSPIN
62
SPIN
f
f∑
(as ,
𝜿
s)
as
f
lock_tr incr_tr n
./
lock_tr
Morphism de
fi
nition
f
unlock_tr id_tr
./
unlock_tr
SPIN
./
./
Counter
63
Expected morphed spec
f^lock : {
𝜿
s = 0} {
𝜿
s = n} @ CSPIN
./
./
lock : {as = ∅ ∧ ao = h}

{∃t. as = t ⤇L ∧ t > last h}

@ SPIN
f^lock : {I⋀ P} {I⋀ Q} @CSPIN
f 1
⌃
f 1
⌃
64

./
./
lock : { }

{ }

@ SPIN
f^lock : {I⋀ P} {I⋀ Q} @CSPIN
f 1
⌃
f 1
⌃
I ≙
𝜿
s = n (♯L as)
as = ∅
∃t. as = t ⤇L
65
./
./
f^lock : { ⋀ ( )}

{ ⋀ ( )} @CSPIN
f 1
⌃
f 1
⌃
𝜿
s = n (♯L as)
𝜿
s = n (♯L as)
as = ∅
∃t. as = t ⤇L
66
./
./
f^lock : { ⋀ }

{ ⋀ } @CSPIN
𝜿
s = n (♯L as)
𝜿
s = n (♯L as)
as = ∅
∃t. as = t ⤇L
67
./
./
f^lock : { }

{ } @CSPIN
𝜿
s = 0
𝜿
s = n
68

Conclusions
1. Type theory very suitable for modelling concurrency
2. New foundations for concurrent reasoning
• new abstractions for type/code/specs, new rules for proofs
3. Many well-known concepts receive type-inspired modi
fi
cation
• similar to how structured programming changed programming
4. Separation logic = dependent type theory
• arises directly from Owicki-Gries approach via types
5. Hoare triples = dependent monads
69
Important technical ideas
1. Subjective variables (as and ao)
• local access to global state and global invariants
• give rise to novel algebra of PCMs (POPL20)
2. Subjective histories
• separation logic = temporal+spatial reasoning
• user-level encoding of linearizability
3. Algebra of resources and morphisms
• type-level ~ Abadi-Lamport re
fi
nements
• novel reasoning rule for morphism application
70
Implementation
1. Implementation as minimalistic system
• 9 Hoare-style rules + Coq (shallow embedding)
2. Veri
fi
ed number of benchmark programs
• locks, stacks, snapshots,
fl
at combiner, graph marking,…
71
Q&A slides
72
72

Differences with separation logic
73
x ↦ 3 * y ↦ 42 as = x ↦ 3 + y ↦ 42
[x ↦ 3]heap * [1]ghost as = (x ↦ 3, 1)
∃n. [x ↦ n+2]heap * [n]ghost fst as = x ↦ (snd as +2)
as = x ↦ 3 ∧ ao = y ↦ 42
x ↦ 3 * y ↦ 42 ✗
In separation logic In our system
fst as = x ↦ 3 ∧ snd as = 1
(leads to theory of PCM
functions and relations)
73
Rules
161:16 Aleksandar Nanevski, Anindya Banerjee, Germán Andrés Delbianco, and Ignacio Fábregas
are the only Hoare-related rules of the system. In the rules we assume that e : STV A, ei : STV Ai ,
a is a V -action, f : V → W is a morphism, I is an f -simulation, s ∈ Σ (V ), and sw ∈ Σ (W ).
vrf_post : (∀v s. J s → Q1 v s → Q2 v s) → J s → vrf e Q1 s → vrf e Q2 s
vrf_ret : (Q v)• s → vrf (ret v) Q s
vrf_bnd : vrf e1 (λx. vrf (e2 x) Q) s → vrf (x ← e1; (e2 x)) Q s
vrf_par : ((vrf e1 Q1) ∗ (vrf e2 Q2)) s → vrf (e1 % e2) (λv:A1×A2. (Q1 v.1) ∗ (Q2 v.2)) s
where (P ∗ Q)s !
= ∃s1 s2.s = s1 ∗ s2 ∧ P s1 ∧ Q s2
vrf_frame : ((vrf e Q1) ∗Q•
2) s → vrf e (λv. (Q1 v) ∗Q2) s
vrf_act : (λs*. ∃s** v. [a] s* = (s**,v) ∧ (Q v)• s**)• s → vrf +a, Q s
vrf_morph : f ˆ(vrf e Q) sw → I sw → vrf (morph f e) (λv s*
w . f ˆ(Q v) s*
w ∧ I s*
w ) sw
where f ˆR sw !
= ∃sv .sv = fΣ sw ∧ R sv
In English:
• The vrf_post rule weakens the postcondition, similar to the well-known rule of Consequence
in Hoare logic. The rule allows assuming a property J when establishing a postcondition
Q2 out of Q1. Here J is an invariant, i.e., a property preserved by the transitions of V ; an
id-simulation. Thus, invariants can be elided from program specs, and invoked by vrf_post
when needed.
• The vrf_ret rule applies to an idle program returning v. When we want an idle program
that returns no value, we simply take v to be of unit type. The rule explicitly stabilizes
the postcondition Q to allow for the state s to be changed by interference of other threads
in between the invocation of the idle program and its termination. Here, stabilization of a
predicate Q is Q• (s) !
= ∀s*.s −→∗
V
s* → Q (s*). The predicate Q is stable if Q = Q•, and it is
easy to see that Q• is stable for every Q.
• The vrf_bnd rule is a Dijkstra-style rule for sequential composition. In order to show that
the sequential composition x ← e1; (e2 x) has a postcondition Q, it suffices to show that e1
has a postcondition λx. vrf (e2 x) Q. In other words, e1 terminates with a value x and in a
state satisfying vrf (e2 x) Q, so that running e2 x in that state yields Q.
• The vrf_par and vrf_frame rules are predicate transformer variants of the rules for parallel
composition and framing from separation logic. The separating conjunction P ∗Q is defined
as customary in separation logic, except that we use the subjective splitting of state, as
explained in Section 3.1.3 and Figure 6. The vrf_frame rule can be seen as an instance of
vrf_par, where e2 is taken to be the idle programs returning no value. Thus, Q2 is explicitly
stabilized in vrf_frame, to match the precondition of the vrf_ret rule for idle programs.
• The vrf_act rule says that Q holds after executing action a in state s, if s steps to s* by
interfering threads, and then [a] s* returns the pair (s**,v) of output state and value. The
latter satisfy the stabilization of Q, to allow for interference on s** after the termination of a.
• The vrf_morph rule is a straightforward casting of the Morph rule from Section 1 into a
predicate transformer style.
Finally, we also inherit all the CiC logical and programming constructs as well, which has
important consequences for Hoare-style reasoning. For example, in CiC one can form conditionals
over any type, including propositions and STV A types. Thus, given a Boolean b and e1,e2 : STV A,
the following rule, derivable by case analysis on b, allows us to write programs that use conditionals,
and verify them in the usual Hoare-logic style.
vrf_cond : (if b then vrf e1 Q s else vrf e2 Q s) → vrf (if b then e1 else e2) Q s
All the other customary rules of Hoare logic also become derivable. For example, if e : {P} {Q}
and ∀s ∈ Σ (V ). P* s → P s, then also e : {P*} {Q}. Similarly, if e depends on a logical variable x : A
Proc. ACM Program. Lang., Vol. 3, No. OOPSLA, Article 161. Publication date: October 2019.
vrf, as follows.
[ ]. {P} A {Q}@V = {e : STV A | 8 . 8s 2 (V ). P s ! vrf e Q s} (3)
We formulate the system using both vrf and the Hoare types. The former is useful, as it leads to
compact presentation, avoiding a number of structural rules of Hoare logic. The latter is useful
because it lets us easily combine Hoare reasoning with higher-order concepts. For example, having
inherited higher-order functions from C�C, we can immediately give the following type to the
�xed-point combinator, where T is the dependent type T = x:A. [ ]. {P} B {Q}@V :
fix : (T ! T) ! T F��
Here,T serves as a loop invariant; in fix ( f .e) we assume thatT holds of f , but then have to prove
that it holds of e as well, i.e., it is preserved upon the end of the iteration.
In reasoning about programs, we keep the transformer vrf abstract, and only rely on the following
minimal set of rules. These, together with the above de�nition of Hoare types and typing for fix,
12Appendix D de�nes the denotational semantics, in C�C, for these notions, and states a theorem, proved in Coq, that the
inference rules are sound wrt. the denotational semantics.
13Thus ensuring fault avoidance.
We present the system using the Calculus of Inductive Constructions (CiC) as an environment logic,
hence as a shallow embedding in Coq. We inherit from CiC the useful concepts of higher-order
functions and substitution principles, and only present the notions specific to Hoare logic12.
We differentiate between two different notions of program types: STV A and [Γ]. {P} A {Q}@V .
The first type circumscribes programs that respect the transitions of the resource V , and return
a value of type A if they terminate. The second, Hoare type, is a subset of STV A, selecting only
those programs that satisfy the precondition P and postcondition Q, under the context Γ of logical
variables. To accommodate for the return values, the postcondition Q is now a predicate over values
of type A and states (if A = unit, we elide it from the Hoare type, as we did in Section 2).
The key concept in the inference rules is the predicate transformer vrf e Q, which takes a program
e : STV A, and a postcondition Q, and returns the set of V -states from which e is safe to run13 and
produces a result v and ending state s! such that Q v s!. Hoare types are then defined in terms of
vrf, as follows.
[Γ]. {P} A {Q}@V = {e : STV A | ∀Γ. ∀s ∈ Σ (V ). P s → vrf e Q s} (3)
We formulate the system using both vrf and the Hoare types. The former is useful, as it leads to
compact presentation, avoiding a number of structural rules of Hoare logic. The latter is useful
because it lets us easily combine Hoare reasoning with higher-order concepts. For example, having
inherited higher-order functions from CiC, we can immediately give the following type to the
fixed-point combinator, where T is the dependent type T = Πx:A. [Γ]. {P} B {Q}@V :
fix : (T → T) → T Fix
Here,T serves as a loop invariant; in fix (λf .e) we assume thatT holds of f , but then have to prove
that it holds of e as well, i.e., it is preserved upon the end of the iteration.
In reasoning about programs, we keep the transformer vrf abstract, and only rely on the following
minimal set of rules. These, together with the above definition of Hoare types and typing for fix,
12The extended version of the paper [Nanevski et al. 2019b, Appendix D] defines the denotational semantics, in CiC, for
these notions, and states a theorem, proved in Coq, that the inference rules are sound wrt. the denotational semantics.
13Thus ensuring fault avoidance.
74
Specifying Concurrent Programs in Separation Logic: Morphisms and Simulations 161:13
we must impose that incr_tr won’t allocate the pointer r, already taken by Spin. For simplicity, we
here present the theory with only footprint-preserving transitions, but have added non-preserving
(aka. external) transitions as well [Nanevski et al. 2019a]. External transitions encode transfer of
data in and out of a resource [de Alfaro and Henzinger 2001], of which allocation and deallocation
are an instance. When a resource requires allocation or deallocation, it can be tensored with an
allocator resource to exchange pointers through ownership transfer [Filipović et al. 2010b; Nanevski
et al. 2014] via external transitions. We elide further discussion, but refer to the Coq files for the
implementation of an allocator resource and example programs that use it.
Definition 3.7. A resource is a tuple V = (M,T, Σ, ∆), where Σ is a space of (M,T)-states, and ∆
a set of footprint preserving Σ transitions. We refer to V ’s components as projections, e.g. Σ (V ) for
the state space, ∆ (V ) for the transitions, M (V ) for the PCM, etc. A state s is V -state iff s ∈ Σ (V ).
We close the discussion on resources by defining actions—atomic operations on (combined real
and ghost) state, which are the basic building blocks of programs.
Definition 3.8. An action of type A in a resource V is a partial function a : Σ (V ) ! ∆ (V ) × A,
mapping input state to output transition and value, which is local, in the sense that it is invariant
under framing. Formally, if a (s ! p) = (t,v) then a (s " p) = (t,v); that is, if a is performed by a
child thread, it behaves the same when viewed by the parent.
The effect of a is the partial function [a] : Σ (V ) ! Σ (V ) × A mapping input state to output state
and value, defined as [a] s = (s#,v) iff ∃t. a s = (t,v) ∧ t s s#. Note that [a] is a (partial) function
because a and t are.
For example, we model the bracketed code used in the lock loop in Section 2, as the following
action of type bool:
trylock_act s !
=
"
(lock_tr, true) if ¬ω (τ̂ s)
(id_tr, false) otherwise
(1)
The action is local, as it depends only on τ̂ s, which is invariant under framing.
We say that a erases to an atomic read-modify-write (RMW) command c [Herlihy and Shavit
2008], if [a] behaves like c when the states are erased to heaps. In other words, if [a] s = (s#,v),
then c !s" = (!s#",v). One may check that trylock_act erases to CAS(r, false, true), as expected.11
Similarly,
unlock_act s !
=
"
(unlock_tr, ()) if ω (τ̂ s)
(id_tr, ()) otherwise
(2)
is an action of unit type, which erases to r := false.
3.3 Morphisms
Definition 3.9. A resource morphism f : V → W consists of two partial functions fΣ : Σ (W ) !
Σ (V ) (note the contravariance), and f∆ : Σ (W ) ! ∆ (V ) ! ∆ (W ), such that:
(1) (locality of fΣ) there exists a function ϕ : M (W ) → M (V ) such that if fΣ (sw ! p) = sv , then
there exists s#
v such that sv = s#
v ! ϕ (p), and fΣ (sw " p) = s#
v " ϕ (p).
(2) (locality of f∆) if f∆ (sw ! p)(tv ) = tw , then f∆ (sw " p)(tv ) = tw .
(3) (other-fixity) if ao (sw ) = ao (s#
w ) and fΣ (sw ), fΣ (s#
w ) exist, then ao (fΣ (sw )) = ao (fΣ (s#
w )).
11All the actions we use in this paper and in the Coq code erase to some RMW command. However, we proved this only by
hand, as our formalism and the Coq implementation don’t currently issue proof obligations to check this. In general, we
currently treat code and ghost code equally, and, as customary in type theory, equally to proofs. Differentiating between
these formally is an orthogonal issue that we plan to address in the future by making a type distinction between them, such
as in the work on proof irrelevance in type theory [Barras and Bernardo 2008; Gilbert et al. 2019; Pfenning 2001].
De
fi
nitions
75
De
fi
nitions
161:14 Aleksandar Nanevski, Anindya Banerjee, Germán Andrés Delbianco, and Ignacio Fábregas
A morphism f transforms a V -program e into a W -program, as follows. When morph f e is in a
W -state sw , it has to determine aW -transition to take. It does so by obtaining a V -state sv = fΣ (sw ).
Next, out of sv , e can determine the transition tv to take. The morphed W -program then takes the
W -transition f∆ (sw )(tv ).
The properties (1) and (2) of Definition 3.9 provide basic technical conditions for this process
to be invariant under framing. Property (1) is a form of “simulation of framing”, i.e., a frame p in
W can be matched with a frame ϕ (p) in V . Thus, framing a morphed program can be viewed as
framing the original program. Property (2) says that framing doesn’t change the transition that f∆
produces; thus it doesn’t influence the behavior of morphed programs. The property (3) restricts
the choice of s!
v in (1) so that ao (s!
v ) is uniquely determined by ao (sw ), much as how ϕ (p) in (1) is
uniquely determined by p. This is a technical condition which we required to prove the soundness
of the frame rule.
Example. Properties (1)-(3) are all satisfied by the morphisms fn : Spin → SC from Section 2.
Indeed, M (SC) = M (Spin) × M (Counter) = Hist × N. Thus, a frame in SC is a pair of a history
and a nat; it is transformed into a frame in Spin just by taking the history component. We thus
instantiate ϕ in (1) with the first projection function, and it is easy to see that it satisfies the rest
of (1). Property (2) holds because (fn)∆ doesn’t depend on the state argument, hence framing this
state doesn’t change the output. Finally, in (3), the values ao (sw ) and ao (s!
w ) are also pairs of a
history and a nat. If the pairs are equal, then their history components are equal too, deriving (3).
Finally, resources and their morphisms support a basic categorical structure, under the following
notions of morphism identity and composition. We have proved in the Coq files that morphism
composition is associative, with the identity morphism as the unit, where two morphisms are equal
if their Σ and ∆ components are equal as partial functions.
Definition 3.10. The identity morphism id : V → V is defined by idΣ s = s and id∆ s t = t. The
composition of morphisms f : U → V and д : V → W is the morphism д ◦ f : U → W defined by:
(д ◦ f )Σ sw !
= fΣ (дΣ sw )
(д ◦ f )∆ sw tu !
= д∆ sw (f∆ (дΣ sw ) tu )
3.4 Simulations
Because fΣ and f∆ are partial, a program lifted by a morphism isn’t immediately guaranteed to
be safe (i.e., doesn’t get stuck). For example, the state sv = fΣ sw , whose computation is the first
step of morphing, needn’t exist. Even if sv does exist, and the original program takes the transition
tv in sv , then tw = f∆ sw tv needn’t exist. Even if tw does exist, there is no guarantee that sw is
safe for tw . An f -simulation is a condition that guarantees the existence of these entities, and their
mutual agreement (e.g., that sw is safe for tw ), so that a morphed program that typechecks against
the Morph rule doesn’t get stuck.
Definition 3.11. Given a morphism f : V → W , an f -simulation is a predicate I on W -states
such that:
(1) if I sw , and sv = fΣ (sw ) exists, and tv sv s!
v , then there exist tw = f∆ sw tv and s!
w such that
I s!
w and s!
v = fΣ (s!
w ), and tw sw s!
w .
(2) if I sw , and sv = fΣ (sw ) exists, and sw −→∗
W
s!
w , then I s!
w , and s!
v = fΣ (s!
w ) exists, and
sv −→∗
V
s!
v . Here, the relation s −→
W
s! denotes that s other-steps by W to s!, i.e., that there
exists a transition t ∈ ∆ (W ) such that t s(
s!(
. The transposition s( = (ao s,aj s,as s) swaps
the subjective components of s, to obtain the view of other threads. The relation −→∗
W
is the
reflexive-transitive closure of −→
W
, allowing for an arbitrary number of steps.
76

De
fi
nitions
sketch. Let x, and z be three histories such that x ? and (x • ) ? z, and let the timestamps
of their last entries be tx , t , and tz, respectively. The interesting case is when x or end with a
locking entry. Without loss of generality, let x hold, and thus last_opx = L. Then, by x ? , the
last entry of must be U, and t < tx . Similarly, by (x • ) ? z, the last entry of z must be U and
tz < tx . But then, trivially, ? z, because both and z end with an U entry. Similarly, x ? ( •z),
because • z also ends with an U entry, and its last timestamp is max(t ,tz)  t ,tz < tx .
The clauses (4) and (5) in Section 4 also arise as instances of compatibility relations, in a similar
way. Thus, ultimately, the invariant In = (4) ^ (5) ^ (6) can be de�ned as a compatibility relation
on the PCM M (CSL0
).
PCM morphisms. Now we can de�ne morphisms between PCMs as follows:
De�nition B.2. A PCM morphism : A ! B with a compatibility relation ? is a partial
function from A to B such that:
(1) 1A = 1B
(2) if x ? , then x, exist, and x ?B , and (x • ) = x •
The morphism is total if ? equals ?A.
In Section 4 we have silently used many PCM morphisms, as the special symbols that we used
to name the components such as , , µ, , etc., are all PCM morphisms. For example, and
in Figure 9 are projections out of the PCM M (Spin) into the PCM of histories and permissions,
respectively (and projections out of tuples are morphisms). Then, s s and o s are abbreviations for
(as s) and (ao s) respectively, and similarly for .
sub-PCMs. We can now de�ne the notion of sub-PCMs as follows:
De�nition B.3. PCM A is a sub-PCM of a PCM B if there exists a total PCM morphism : A ! B
(injection) and a morphism : B ! A (retraction), such that:
(1) ( a) = a
(2) if b ? 1B then ( b) = b
(3) if ( x) ?A ( ) then x ?
Property (1) says that is injective, i.e., if we coerce a 2 A into a, we can recover a back by ,
since no other element of A maps by into a. The dual property (2) allows the same for a subset
of B’s elements, that are related by ? to 1B. Hence, intuitively, A is in 1-1 correspondence with
that subset of B. Property (3) extends the correspondence to compatibility relations, i.e., ?A, when
considered on images under , implies (and hence, by properties of morphisms, equals) ? .
De�nition B.3 says what it means for A to be a sub-PCM of B. The following lemma shows how
to construct a sub-PCM of B given a compatibility relation R on B. We used this construction in
Section 4 to obtain the PCM for the resource CSL out of the PCM M (CSL0
).
L�� B.4. Given PCM A and compatibility relation R on A, the set A/R = {x 2 A | x R 1A} forms
a PCM under unit 1A, and join operation de�ned as x •A/R = x •A if x R and unde�ned otherwise.
The clauses (4) and (5) in Section 4 also arise as instances of compatibility relations, in a similar
way. Thus, ultimately, the invariant In = (4) ^ (5) ^ (6) can be de�ned as a compatibility relation
on the PCM M (CSL0
).
PCM morphisms. Now we can de�ne morphisms between PCMs as follows:
De�nition B.2. A PCM morphism : A ! B with a compatibility relation ? is a partial
function from A to B such that:
(1) 1A = 1B
(2) if x ? , then x, exist, and x ?B , and (x • ) = x •
The morphism is total if ? equals ?A.
In Section 4 we have silently used many PCM morphisms, as the special symbols that we used
to name the components such as , , µ, , etc., are all PCM morphisms. For example, and
in Figure 9 are projections out of the PCM M (Spin) into the PCM of histories and permissions,
respectively (and projections out of tuples are morphisms). Then, s s and o s are abbreviations for
(as s) and (ao s) respectively, and similarly for .
sub-PCMs. We can now de�ne the notion of sub-PCMs as follows:
De�nition B.3. PCM A is a sub-PCM of a PCM B if there exists a total PCM morphism : A ! B
(injection) and a morphism : B ! A (retraction), such that:
(1) ( a) = a
(2) if b ? 1B then ( b) = b
(3) if ( x) ?A ( ) then x ?
Property (1) says that is injective, i.e., if we coerce a 2 A into a, we can recover a back by ,
since no other element of A maps by into a. The dual property (2) allows the same for a subset
of B’s elements, that are related by ? to 1B. Hence, intuitively, A is in 1-1 correspondence with
that subset of B. Property (3) extends the correspondence to compatibility relations, i.e., ?A, when
considered on images under , implies (and hence, by properties of morphisms, equals) ? .
De�nition B.3 says what it means for A to be a sub-PCM of B. The following lemma shows how
to construct a sub-PCM of B given a compatibility relation R on B. We used this construction in
Section 4 to obtain the PCM for the resource CSL out of the PCM M (CSL0
).
L�� B.4. Given PCM A and compatibility relation R on A, the set A/R = {x 2 A | x R 1A} forms
a PCM under unit 1A, and join operation de�ned as x •A/R = x •A if x R and unde�ned otherwise.
77
De
fi
nitions
Specifying Concurrent Programs in Separation Logic: Morphisms and Simulations 33
The PCM A/R is a sub-PCM of A under the injection and retraction de�ned as 8x 2 A/R. (x) = x
and 8a 2 A. (a) = a if a R 1A, and (a) unde�ned otherwise. Moreover, R = ? = ?A/R.
Using the above notation, the PCM of the resource CSL can be de�ned formally as M (CSL0
)/In .
We now have all the ingredients to formalizing the construction for restricting a resource that
we set out to de�ne.
De�nition B.5. Let R be an invariant compatibility relation on M (V ). The sub-resource V /R is
de�ned with the same type, transitions and erasure as V , but with the PCM and the state space
de�ned as
(1) M (V /R) = M (V )/R
(2) s 2 (V /R) i� s 2 (V ) ^ (as s) R (ao s)
There is a generic resource morphism : V ! V /R that is inclusion on states and identity on
transitions.
For example, the resource CSL from Section 4 is the sub-resource of CSL0
taken under the
invariant In , and the resource morphism : CSL0
! CSL from Section 4 (page 20), is the generic
morphism de�ned above.
Algebraic properties. We �nish this section by providing some additional evidence that compat-
ibility relations and PCM morphisms compose, and have pleasant mathematical properties. For
example, the operations of morphism composition and join come with the compatibility relations
as follows.
(f ) (x) b
= f ( x) x ?f b
= x ? ^ x ?f
(f • ) (x) b
= f x • x x ?f • b
= x ?f ^ x ? ^ f (x • ) ? (x • )
Or, given PCM morphisms f and , we can de�ne compatibility relation that implements the PCM
versions of the algebraic notions of kernel (preimages of unit) and equalizer (values on which two
morphisms agree), as follows.
x (ker f ) b
= x ?f ^ f x = f = 1
x (eql f ) b
= x ?f ^ x ? ^ f x = x ^ f =
Importantly, the above are all compatibility relations, as we have proved in the Coq �les. Similarly,
we can restrict a morphism to a compatibility relation R, to de�ne another PCM morphism.
(f /R) (x) b
=
⇢
f x, if x R 1
unde�ned, otherwise
with x ?f /R b
= x ?f ^ x R
The import of the above abstract constructions is in the reduction of proof burden. For example,
a morphism equalizer is a compatibility relation by construction, so the user need not bother
proving compatibility for equalizers. The constructions also combine to concisely state invariants
and assertions. For example, the compatibility relation that gives rise to In , and is thus used
to construct the sub-resource CSL, may be de�ned as the equalizer eql ( • ) ( 0 ), where
0 : hist ! O is the morphism de�ned on a history h as 0 h = if h then own else own.
C INDEXED MORPHISM FAMILIES
In this appendix, we show how the de�nitions of morphism and f -simulations generalize to indexed
families. When X is the unit type, we recover the morphism-related de�nitions from Section 3.
De�nition C.1. An indexed family of morphisms f : V
X
! W (or just family), consists of
partial functions f : X ! (W ) * (V ) (note the contravariance), and f : X ! (V ) * (W )
on transitions, such that:
78
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)
79
79

Type and proof structures for concurrency

More Related Content

Similar to Type and proof structures for concurrency

More from Facultad de Informática UCM

Recently uploaded

Type and proof structures for concurrency