[PPT] - Modern Concurrent Separation Logics Philippa Gardner Thomas Pedro PowerPoint Presentation

SLIDE 1

Modern Concurrent Separation Logics

Pedro da Rocha Pinto Thomas Dinsdale-Young Philippa Gardner Resource Reasoning 2016

1 / 37

SLIDE 2

Counter Module

function read(x) { r := [x]; return r; } function incr(x) { do { r := [x]; b := CAS(x, r, r + 1); } while (b = 0); return r; } function wkincr(x) { r := [x]; [x] := r + 1; }

2 / 37

SLIDE 3

Ticket Lock Client

function lock(x) { t := incr(x.next); do { v := read(x.owner) } while (v = t); } function unlock(x) { wkincr(x.owner); }

3 / 37

SLIDE 4

Sequential Specification

Abstract predicate C(x, n) describes a counter with value n ∈ N at address x. {C(x, n)} read(x) {C(x, n) ∧ ret = n} {C(x, n)} incr(x) {C(x, n + 1) ∧ ret = n} {C(x, n)} wkincr(x) {C(x, n + 1)} Pros: The specification captures sequential behaviour. Cons: The specification does not support concurrency.

4 / 37

SLIDE 5

Specification of Concurrent Modules

Modular specifications of concurrent modules require:

◮ auxiliary state: Owicki, Gries ◮ interference abstraction: Jones ◮ resource ownership: O’Hearn ◮ atomicity: Herlithy

Susan Owicki David Gries Cliff Jones Peter O’Hearn Maurice Herlihy

5 / 37

SLIDE 6

Specification of Concurrent Modules

Modular specifications of concurrent modules require:

◮ auxiliary state ◮ interference abstraction ◮ resource ownership ◮ atomicity

6 / 37

SLIDE 7

Auxiliary State: Owicki-Gries

Parallel Rule {P1} C1 {Q1} {P2} C2 {Q2} non-interference {P1 ∧ P2} C1 C2 {Q1 ∧ Q2}

7 / 37

SLIDE 8

Auxiliary State: Owicki-Gries

Concurrent Specification using Invariants {∃n. C(x, n)} read(x) {∃n, m. C(x, n) ∧ ret = m} {∃n. C(x, n)} incr(x) {∃n, m. C(x, n) ∧ ret = m} {∃n. C(x, n)} wkincr(x) {∃n. C(x, n)} Pros: The specification captures concurrent behaviour. Cons: Using invariants leads to very weak specifications. No information about the actual value of the counter.

8 / 37

SLIDE 9

Auxiliary State: Owicki-Gries

Stronger specifications require auxiliary state:

C(x, 0)
y := 0; z := 0;
C(x, 0) ∧ y = 0 ∧ z = 0
C(x, y + z) ∧ y = 0
do {

r := [x]; b := CAS(x, r, r + 1); if (b) y++; } while (b = 0);

C(x, y + z) ∧ y = 1
C(x, y + z) ∧ z = 0
do {

r′ := [x]; b′ := CAS(x, r′, r′ + 1); if (b′) z++; } while (b′ = 0);

C(x, y + z) ∧ z = 1
C(x, 2) ∧ y = 1 ∧ z = 1
C(x, 2)
9 / 37

SLIDE 10

Auxiliary State: Owicki-Gries

Pros: The specification is strong. Cons: The proof method, introducing auxiliary code, is not modular.

10 / 37

SLIDE 11

Auxiliary State: Owicki-Gries

Auxiliary state, introduced in the Owicki-Gries method, is important for specifying concurrent modules.

11 / 37

SLIDE 12

Specification of Concurrent Modules

Modular specifications of concurrent modules require:

◮ auxiliary state ◮ interference abstraction ◮ resource ownership ◮ atomicity

12 / 37

SLIDE 13

Interference Abstraction: Rely/guarantee

Parallel Rule The Rs and Gs are called rely and guarantee relations respectively. R ∪ G2, G1 ⊢

P1
C1
Q1
R ∪ G1, G2 ⊢
P2
C2
Q2
R, G1 ∪ G2 ⊢
P1 ∧ P2
C1 C2
Q1 ∧ Q2
13 / 37

SLIDE 14

Interference Abstraction: Rely/guarantee

Specification: read(x) and incr(x) A, ∅ ⊢ {∃n. C(x, n)} read(x) {∃n. C(x, n) ∧ ret ≤ n} A, A ⊢ {∃n. C(x, n)} incr(x) {∃n. C(x, n) ∧ ret ≤ n} where A = {C(x, n) C(x, n + 1) | n ∈ N}. Pros: The behaviour that the environment might do is specified. Cons: This specification does not restrict the increment operation to perform a single increment.

14 / 37

SLIDE 15

Ticket Lock Client

function lock(x) { t := incr(x.next); do { v := read(x.owner) } while (v = t); } function unlock(x) { wkincr(x.owner); }

15 / 37

SLIDE 16

Interference Abstraction: Rely/guarantee

Specification: wkincr(x) R, G ⊢

C(x, n)
wkincr(x)
∃n′ ≥ n + 1. C(x, n′)
where R = {C(x, m) C(x, m + 1) | m > n} and G is as before.

Pros: This specification allows weak increments to occur concurrently. Cons: This specification is too weak to reason about the ticket lock.

16 / 37

SLIDE 17

Interference Abstraction: Rely/guarantee

Interference abstraction, introduced in the rely/guarantee method, is important for specifying concurrent modules.

17 / 37

SLIDE 18

Specification of Concurrent Modules

Modular specifications of concurrent modules require:

◮ auxiliary state ◮ interference abstraction ◮ resource ownership ◮ atomicity

18 / 37

SLIDE 19

Resource Ownership: Concurrent Separation Logics

Parallel Rule The disjoint concurrency rule from concurrent separation logic: {P1} C1 {Q1} {P2} C2 {Q2} {P1 ∗ P2} C1 C2 {Q1 ∗ Q2} Ownership embodies specialised notions of auxiliary state and interference abstraction. If a thread owns a resource, then the environment cannot manipulate it.

19 / 37

SLIDE 20

Resource Ownership: Concurrent Separation Logics

Fractional Permissions C(x, n1 + n2, π1 + π2) ⇐ ⇒ C(x, n1, π1) ∗ C(x, n2, π2) for n1, n2 ∈ N and π1, π2 ∈ (0, 1] and π1 + π2 ≤ 1. The abstract predicate C(x, n, π1) now means that this resource contributes value n to the counter at x with permission π1.

20 / 37

SLIDE 21

Resource Ownership: Concurrent Separation Logics

Specification using Fractional Permissions {C(x, n, π)} read(x) {C(x, n, π) ∧ ret ≥ n} {C(x, n, 1)} read(x) {C(x, n, 1) ∧ ret = n} {C(x, n, π)} incr(x) {C(x, n + 1, π) ∧ ret ≥ n} {C(x, n, 1)} wkincr(x) {C(x, n + 1, 1)} Pros: This specification allows concurrent reads and increments. Cons: The specification enforces sequential weak increments. The return values are no longer guaranteed to be the actual value of the counter.

21 / 37

SLIDE 22

Resource Ownership: Concurrent Separation Logics

C(x, 0, 1)
C(x, 0, 0.5) ∗ C(x, 0, 0.5)
C(x, 0, 0.5)
incr(x)
C(x, 1, 0.5)
C(x, 0, 0.5)
incr(x)
C(x, 1, 0.5)
C(x, 1, 0.5) ∗ C(x, 1, 0.5)
C(x, 2, 1)
22 / 37

SLIDE 23

Resource Ownership: Concurrent Separation Logics

Resource ownership, developed by concurrent separation logic and its successors, is important for specifying concurrent modules.

23 / 37

SLIDE 24

Specification of Concurrent Modules

Modular specifications of concurrent modules require:

◮ auxiliary state ◮ interference abstraction ◮ resource ownership ◮ atomicity

24 / 37

SLIDE 25

Atomicity

Atomicity provides a way to abstract interference. It gives the abstraction that an operation takes effect at a single, discrete instant in time.

25 / 37

SLIDE 26

Atomicity: Linearisability

Sequential Specification for read(x) and incr(x) {C(x, n)} read(x) {C(x, n) ∧ ret = n} {C(x, n)} incr(x) {C(x, n + 1) ∧ ret = n} Pros: Strong concurrent reasoning about read(x) and incr(x). Cons: Linearisability does not allow us to control the interference like rely-guarantee.

26 / 37

SLIDE 27

Atomicity: Linearisability

Sequential Specification with wkincr(x) not possible {C(x, n)} read(x) {C(x, n) ∧ ret = n} {C(x, n)} incr(x) {C(x, n + 1) ∧ ret = n} {C(x, n)} wkincr(x) {C(x, n + 1)} Cons: The wkincr is not atomic when other increments occur.

27 / 37

SLIDE 28

Atomicity: Linearisability

Atomicity, put forward by linearisability, is important for specifying concurrent modules.

28 / 37

SLIDE 29

Synthesis

Now we combine auxiliary state, interference abstraction, resource reasoning and atomicity to provide expressive specifications for concurrent modules.

29 / 37

SLIDE 30

Synthesis

◮ higher-order: Birkedal, Dreyer, Jacobs, Turon ◮ history-based: Nanevski, Sergey ◮ first-order: da Rocha Pinto, Dinsdale-Young, Gardner

Lars Birkedal Derek Dreyer Bart Jacobs Aleks Nanevski Ilya Sergey Aaron Turon

30 / 37

SLIDE 31

Synthesis: First-order Approach

A simple atomic triple has the form A x ∈ X. P(x) C Q(x)

31 / 37

SLIDE 32

Synthesis: First-order Approach

Specification using Atomic Triples A

n. C(s, x, n) read(x) C(s, x, n) ∧ ret = n

A

n. C(s, x, n) incr(x) C(s, x, n + 1) ∧ ret = n

C(s, x, n) wkincr(x) C(s, x, n + 1) Pros: Atomic triples specify operations with respect to an abstraction; each operation can be verified independently. The specification is strong. It allows concurrent reads and concurrent increments, and concurrent reads and one weak increment.

32 / 37

SLIDE 33

Verfication of Implementations and Clients

Verification of the counter implementation. Specification and verification of the ticket-lock client. Pros: A specification of ticket lock whose implementation is based

n the atomic counter commands.

Cons: The specification of ticket lock is not atomic. It requires helping (on-going).

33 / 37

SLIDE 34

Total Correctness using Ordinals

∀α. ⊢τ

emp
makeCounter()
∃s.C(s, ret, 0, α)
⊢τ

A n ∈ N, α.

C(s, x, n, α)
read(x)
C(s, x, n, α) ∧ ret = n
∀β. ⊢τ

A n ∈ N, α.

C(s, x, n, α) ∧ α > β(α)
incr(x)
C(s, x, n + 1, β(α))
∀α > β. C(s, x, n, α) =

⇒ C(s, x, n, β)

34 / 37

SLIDE 35

Total Correctness using Ordinals

∀α. ⊢τ

emp
makeCounter()
∃s.C(s, ret, 0, α)
⊢τ

A n ∈ N, α.

C(s, x, n, α)
read(x)
C(s, x, n, α) ∧ ret = n
∀β. ⊢τ

A n ∈ N, α.

C(s, x, n, α) ∧ α > β(α)
incr(x)
C(s, x, n + 1, β(α))
∀α > β. C(s, x, n, α) =

⇒ C(s, x, n, β) Non-impedance relationship in the counter module: incr read

34 / 37

SLIDE 36

Total Correctnesss: Example

emp
x := makeCounter();
∃s. C(s, x, 0, ω ⊕ ω)
n := random();

i := 0; while (i < n) { incr(x); i := i + 1; } m := random(); j := 0; while (j < m) { incr(x); j := j + 1; }

C(s, x, n + m, 0)
35 / 37

SLIDE 37

A Personal History with Thomas and Pedro (and others)

◮ RGSep specification of concurrent B-trees ◮ Introduction of CAP to give abstraction: concurrent set/index

module specified; B-tree implementation verified

◮ Specification not applicable to clients from e.g.

java.util.concurrent!

◮ Introduction of TaDA to give abstract atomic, general

specifications

◮ B-tree implementation and skip lists in

java.util.concurrent verified

◮ Introduction of Total-TaDA for total correctness.

36 / 37

SLIDE 38

Pedro and Thomas

37 / 37