Mutual Exclusion Linear Temporal Logic CDP #2 -...

CDP #2Mutual Exclusion &Linear Temporal Logic

Concurrent and Distributed Programminghttp://fmt.cs.utwente.nl/courses/cdp/

HC 2 - Tuesday, 22 November 2011

Marieke Huisman, Jaco van de Polhttp://fmt.cs.utwente.nl/~vdpol/

Lecture 2: Mutual Exclusion & Linear Temporal Logic

Overview of Lecture 2

Ch. 3 - The Critical Section Problemdefinition of the problem

several attempts

proving correctness with state diagrams

Dekker’s algorithm

Ch. 4 - Verification of Concurrent Programslogical specification of correctness properties

inductive proofs of invariants

linear temporal logic (LTL)

deductive proofs with LTL

2

Edsger W. Dijkstra (1930–2002) 3

1971: Member of the Royal Netherlands Academy of Arts and Sciences

1971: Distinguished Fellow of the British Computer Society

1972: ACM Turing Award

1975: Foreign Honorary Member of the American Academy of Arts and Sciences

1976: Honorary doctorate from Queen's University Belfast

1982: Computer Pioneer Charter Recipient from IEEE Computer Society

2001: Honorary doctorate from Athens University of Economics & Business, Greece.

2002: Computer and Communications Prize (NEC Foundation), Japan

Critical Section Problem 4


Critical Section Problem

Each of N processes is executing in an infinite loop a sequence of statements that can be divided into two subsequences: the critical section and the non-critical section.

Correctness specifications required for any solution:mutual exclusion: statements from the critical sections of two or more processes must not be interleaved

freedom from deadlock: if some processes are trying to enter their critical sections, then one of them must eventually succeed

freedom from (individual) starvation: if any process tries to enter its critical section, then that process must eventually succeed.

5


Template for solution 6

Alg. 3.1 (p. 46)

global variablesglobal variables

p q

local variables loop forever non-critical section preprotocol critical section postprotocol

local variables loop forever non-critical section preprotocol critical section postprotocol

critical section must progress

non-critical section need not progress

solution = synchronization mechanism in preprotocol and postprotocol

The solution should also be efficient: pre- and postprotocols should take as little time and memory as possible.

No variables used by the protocol are used in the (non)

critical sections.


First attempt

Idea: each process gets its turn to enter the critical section.

7

Alg. 3.2 (p. 48)

integer turn integer turn ← 1

p q

loop foreverp1: non-critical sectionp2: await turn = 1p3: critical sectionp4: turn ← 2

loop foreverq1: non-critical sectionq2: await turn = 2q3: critical sectionq4: turn ← 1

await p = statement that waits until the condition p becomes true


Correctness using State Diagram

To check correctness properties, it is ‘only’ necessary to examine the set of reachable states and the transitions among them: the state diagram.

Drawback: state diagram can get very, very large.N processes with ni statements in process i

M variables where variable j has mj possible values

upper bound for the number of states:n1 x n2 x n3 x ... x nN x m1 x m2 x m3 x ... x mM

First attempt for critical section:# max. states = n1 x n2 x m1 = 4 x 4 x 2 = 32

8

CDP - 2

9

integer turn ← 1

p loop foreverp1: non-critical sectionp2: await turn = 1p3: critical sectionp4: turn ← 2

q


await self-loop

Mutual exclusion: state diagram does not contain a state (p3,q3,*).

What about deadlock freedom?

What about freedom from starvation?

State diagrams can be constructed incrementally: on-the-fly.

p1,q1,1

p2,q1,1

p3,q1,1

p4,q1,1

p1,q1,2

p2,q1,2

p2,q2,2

p2,q3,2

p2,q4,2

p1,q2,1

p2,q2,1

p3,q2,1

p4,q2,1

p1,q2,2

p1,q3,2

p1,q4,2

First attempt - deadlock 10


p q loop foreverp1: non-critical sectionp2: await turn = 1p3: critical sectionp4: turn ← 2


Alg. 3.5 (p. 53)


p q

loop foreverp2: await turn = 1p4: turn ← 2

loop foreverq2: await turn = 2q4: turn ← 1(non)critical sections are not relevant

for the correctness of the protocol

p2,q2,1

p4,q2,1

p2,q2,2

p2,q4,2

Freedom from deadlock: if some processes are trying to enter their critical sections, then one of them

must eventually succeed.

Yes, due to• critical section must progress• assignment statement will be

executed, eventually


First attempt - starvation 11

Freedom from starvation: if any process is about to execute its

preprotocol, then eventually it will succeed in entering its critical section.

integer turn ← 1


q


Remember: a non-critical section need not progress.

p1,q2,2

p2,q2,2

p1,q1,2

p2,q1,2

q can stay forever in its NCS without progress!

So, the first attempt is not correct as processes can starve.

Fundamental problem: both processes set and test a single global variable.


Second attempt (1)

Idea: each process gets its own variable wanti that it can use to indicate that it wants to enter the critical section.

12

Alg. 3.6 (p. 56)

boolean wantp ← false, wantq false, wantq ← false

p q

loop foreverp1: non-critical sectionp2: await wantq = falsep3: wantp ← truep4: critical sectionp5: wantp ← false

loop foreverq1: non-critical sectionq2: await wantp = falseq3: wantq ← trueq4: critical sectionq5: wantq ← false

• No starvation!• No deadlock!


Second attempt (2)

Unfortunately we can get to a state where the mutual exclusion property is not satisfied: (p4,q4,true,true).

13


p q loop foreverp1: non-critical sectionp2: await wantq = falsep3: wantp ← truep4: critical sectionp5: wantp ← false

loop foreverq1: non-critical sectionq2: await wantp = falseq3: wantq ← trueq4: critical sectionq5: wantq ← false

pcp qcp wp wq

p1 q1 0 0

p2 q1 0 0

p2 q2 0 0

p3 q2 0 0

p3 q3 0 0

p4 q3 1 0

p4 q4 1 1

This scenario can be found in the state diagram of the (abbreviated version of the) second attempt.

Fundamental problem: once a process has successfully completed its await statement, it cannot be prevented from entering its critical section: the assignment to wantp is part of the critical section.


Third attempt 14

Alg. 3.8 (p. 57)


p q

loop foreverp1: non-critical sectionp2: wantp ← true p3: await wantq = falsep4: critical sectionp5: wantp ← false

loop foreverq1: non-critical sectionq2: wantq ← trueq3: await wantp = falseq4: critical sectionq5: wantq ← false

W.r.t. the second

attempt, p2 and p3 have been swapped.

Idea: first indicate that one wants to enter the critical section and then wait for the other process to finish.

p1,q1,0,0 p2,q1,0,0 p2,q2,0,0 p3,q2,1,0 p3,q3,1,1

So, this third attempt is not free from deadlock (or livelock).

Fundamental problem: not only does a process indicate its intention to enter the critical section, but it also insists on its right to do so.


Fourth attempt (1) 15

Alg. 3.9 (p. 59)


p q

loop foreverp1: non-critical sectionp2: wantp ← true p3: while wantqp4: wantp ← falsep5: wantp ← truep6: critical sectionp7: wantp ← false

loop foreverq1: non-critical sectionq2: wantq ← true q3: while wantpq4: wantq ← falseq5: wantq ← trueq6: critical sectionq7: wantp ← false

Idea: a process should (temporarily) give up its right to enter the critical section.

Is this fourth attempt finally correct?


Fourth attempt (2) 16

Unfortunately, both processes can get into a (livelock) cycle, by which they both will ‘starve’.

p loop foreverp1: non-critical sectionp2: wantp ← true p3: while wantqp4: wantp ← falsep5: wantp ← truep6: critical sectionp7: wantp ← false

q loop foreverq1: non-critical sectionq2: wantq ← true q3: while wantpq4: wantq ← falseq5: wantq ← trueq6: critical sectionq7: wantp ← false

p3,q3,1,1 p3,q4,1,1 p4,q4,1,1

p4,q5,1,0p5,q5,0,0p5,q3,0,1

This does not seem to be a very realistic scenario!However, unlikely scenarios have a nasty way of occurring precisely when a bug would have the

most dangerous and costly effects...


Idea: the right to insist on entering is passed between the processes.

Dekker’s algorithm 17

Alg. 3.10 (p. 60)

boolean wantp ← false, wantq integer turn ← 1

false, wantq ← false

p q

loop foreverp1: non-critical sectionp2: wantp ← true p3: while wantqp4: if turn = 2p5: wantp ← falsep6: await turn = 1p7: wantp ← truep8: critical sectionp9: turn ← 2p10: wantp ← false

loop foreverq1: non-critical sectionq2: wantq ← true q3: while wantpq4: if turn = 1q5: wantq ← falseq6: await turn = 2q7: wantq ← trueq8: critical sectionq9: turn ← 1q10: wantq ← false

Verification of Concurrent Programs 18

!((call ∧ "open) ⇒((¬atfloor ∧ ¬open) U

(open ∨ ((atfloor ∧ ¬open) U

(open ∨ ((¬atfloor ∧ ¬open) U

(open ∨ ((atfloor ∧ ¬open) U

(open ∨ (¬atfloor U open))))))))))


Introduction 19

What did we learn so far?Concurrent programs can have subtle errors.

These errors cannot easily be discovered by debugging.

Corrections cannot easily be checked by testing.

All states (i.e., the state diagram) can be generated to check the correctness properties.

Most importantly: formal specification and verification of correctness properties are far more important for concurrent programs than they are for sequential programs.

Linear Temporal Logic= effective formalism for specifying and verifying correctness properties+ specify correctness properties for model checkers (e.g., SPIN)


Logical specification of correctness

We will use propositional logic (see test in lecture 1).

Atomic propositions will be propositions about the values of the variables and control pointers during an execution of a concurrent program.

Examples:p1 ∧ q1 ∧ ¬wantp ∧ ¬wantq(initial state)

p6 ∧ q6(both processes in CS)

¬(p6 ∧ q6)(mutual exclusion property)

20

p q

loop foreverp1: non-critical sectionp2: wantp ← true p3: while wantqp4: wantp ← falsep5: wantp ← truep6: critical sectionp7: wantp ← false

loop foreverq1: non-critical sectionq2: wantq ← true q3: while wantpq4: wantq ← falseq5: wantq ← trueq6: critical sectionq7: wantp ← false

This formula is called invariant, because it must be invariably be true at any point of any computation.


Inductive proofs of invariants

Invariant Φ (e.g ¬(p6 ∧ q6))

Proof by inductionBase case: proof that holds Φ in the initial state.

Induction step: assume that Φ holds in the current state and all previous states, and prove that Φ holds in the next state.

Given the invariant Φ (which may be hard to find), the proof is not that difficult.

one only has to consider the statements that can potentially change the truth values of the atomic propositions in Φmany invariants are implications, where the premise is a control pointer (e.g. p4 ⇒ wantp) — which can be falsified in one way

21

CDP - 2

22

Alg. 4.1 (p. 70)


p q loop foreverp1: non-critical sectionp2: wantp ← true p3: await wantq = falsep4: critical sectionp5: wantp ← false

loop foreverq1: non-critical sectionq2: wantq ← trueq3: await wantp = falseq4: critical sectionq5: wantq ← false

What was wrong with this attempt?

Lemma 4.1: The formula A ≡ p3..5 ⇒ wantp is invariant.

Proof

Base case: trivial, because in the initial state p1 is true.

Induction step:

Induction hypothesis: assume the truth of A.

The only statements that can possibly falsify A are p2 and p5.

p2 makes p3..5 true, but it also makes wantp true.

p5 makes p3..5 false, so A will remain true, regardless what happens to wantp.

p3..5 is an abbreviation for p3 ∨ p4 ∨ p5


23Mutex proving by induction

Lemma 4.1: The formula A ≡ p3..5 ⇒ wantp is invariant.

Lemma 4.2: The formula B ≡ wantp ⇒ p3..5 is invariant.

Lemma 4.3: p3..5 ⇔ wantp and q3..5 ⇔ wantq are invariant.

Lemma 4.4: The formula C ≡ ¬(p4 ∧ q4) is invariant.

Proof

We show that D ≡ (p4 ∧ q4) is false in every state.

Base case: initial state is trivial.

Induction step:

What statements make D true?

(successfully) executing p3 when q4 is true (& q3 when p4 is true)

p3 can only be executed when wantq is false, but — due to Lemma 4.3 — this not possible when q4 is true.

p loop foreverp1: non-critical sectionp2: wantp ← true p3: await wantq = falsep4: critical sectionp5: wantp ← false


Amir Pnueli (1941–2009) 24

1977: The temporal logic of programs. Proceedings of the 18th Annual Symposium on Foundations of Computer Science (FOCS), pp. 46–57.

1996: ACM Turing Award

1999: Foreign Associate of the National Academy of Engineering

2000: Israel Prize for computer science

2007: Fellow of the Association for Computing Machinery (ACM)


Linear Temporal Logic (LTL)

LTL = propositional logic + temporal operators

Syntax of LTL:

25

Φ := p atomic proposition

| ¬Φ| Φ ∨ Φ| Φ ∧ Φ| Φ ⇒ Φ| #Φ neXt

| Φ U Φ Until

| "Φ eventually (Finally)

| !Φ always (Globally)

wantp = trueturn = 2pcp = p1

an atomic proposition p is either true or false in a state

temporal operators⎨⎧⎩

! (turn≤2)" (x≥10)! (x≥0 ∧ x<10)x=10 ⇒ #(x≥10 U x=0)"! (x=0 U y=0)

Some examples

Booleanconnectives⎨⎧⎩


LTL - Semantics (1)

Semantics of LTL is defined over a computation σ (“trace”), i.e., an infinite sequence of states { s0, s1, s2, ... }

σ |= Φ iff formula Φ holds over computation σ

σ |= pholds for a computation σ iff p holds for the first state

26

s0 s1 s2 s3 s4 s5 ...

s0 s1 s2 s3 s4 s5 ...

p


LTL - Semantics (2)

σ |= #Φholds for a computation σ iff Φ holds for the next state

σ |= Φ1 U Φ2

iff ∃j≥0 . (σj |= Φ2 ∧ ∀0≤k<j . σk |= Φ1)

27

s0 s1 s2 s3 s4 s5 ...

Φ1 Φ1 Φ1 Φ2

where σi is the suffix of σ obtaining by removing its first i states, i.e. σi = si si+1 si+2...

s0 s1 s2 s3 s4 s5 ...

Φ

σ |= ¬Φ iff not (σ |= Φ)

σ |= Φ1 ∨ Φ2 iff σ |= Φ1 or σ |= Φ2

σ |= Φ1 ∧ Φ2 iff σ |= Φ1 and σ |= Φ2

so here j=3


LTL - Semantics (3)

σ |= "Φiff ∃j≥0 . (σj |= Φ)

σ |= !Φiff ∀j≥0 . (σj |= Φ)

28

s0 s1 s2 s3 s4 s5 ...

Φ

s0 s1 s2 s3 s4 s5 ...

ΦΦ Φ Φ Φ Φwhere σi is the suffix of σ obtaining by removing its first i states, i.e. σi = si si+1 si+2...

safety property

liveness property


LTL - some examples

When now in state p4 and turn=2 then eventually we will reach p5

p4 ∧ (turn = 2) ⇒ "p5

Once green, the traffic light cannot become red immediately:

!(green ⇒ ¬#red)

Once red, the traffic light becomes green eventually:

!(red ⇒ "green)

Once green, the traffic light becomes red eventually, after being yellow for some time in between:

!(green ⇒ (green U yellow) U red)

29


LTL - some laws 30

Some laws of LTL

!p ⇒ #p!p ⇒ !"p!p ∧ !q ⇒ !( p ∧ q)"p ∧ "q ⇒⁄ "( p ∧ q)!!p ≡ !p""p ≡ "p

#(Φ1 U Φ2) ≡ (#Φ1) U (#Φ2)Φ1 U Φ2 ≡ Φ2 ∨ (Φ1 ∧ #(Φ1 U Φ2))"Φ ≡ Φ ∨ #"Φ!Φ ≡ Φ ∧ #!Φ

expansionrules⎨⎧⎩


LTL - exercise 31

An LTL-formula is valid in a state if and only if all computations starting in that state satisfy the formula.

Exercise: for each of the LTL-formula provide the set of states for which

these formulae are valid.

s1 s2 s3

s4

{a}

{b}

{a,c}

{d}

1. ## a2. d U c3. a U (b ∨ d)4. "b5. !"c6. d ⇒ "b7. (b ∨ c) ⇒ "d8. (a U b) ⇒ #d9. !"b ⇒ ! (a ∨ #a)10. !¬d ⇒ (b U c)


Using LTL to analyse Mutex 32

See §4.5 for a deductive proof of Dekker’s algorithm using Linear Temporal Logic!

Mutual Exclusion:We can now restate the invariant: !¬(p4 ∧ q4)

But we have proved this before (by induction)

What about starvation?This is similar to progress:

Whenever q enters the protocol, it will reach the critical sectionProgress in LTL: !(start ⇒ "critical) (next slide for details)

Proof will be discussed in more detail in lecture 3.

CDP - 3

33How to specify ‘freedom from

starvation’ in LTL?

Property: whenever q wants to enter the critical section, it will eventually enter the critical section.

In LTL: !(q2 ⇒ "q3)

Does this property hold?

p1,q1,1

p2,q1,1

p3,q1,1

p4,q1,1

p1,q1,2

p2,q1,2

p2,q2,2

p2,q3,2

p2,q4,2

p1,q2,1

p2,q2,1

p3,q2,1

p4,q2,1

p1,q2,2

p1,q3,2

p1,q4,2

p1,q1,1

p1,q2,1

No, this is a counterexample for a computation not satisfying !(q2 ⇒ "q3):

integer turn ← 1


q


s0 s1 s2 s3 s4 s5 ...q2q1 q2 q2 q2 q2

Note that this a fair computation, as process p is allowed to stay in its non-

critical section as long as it wants."!q2

Mutual Exclusion Linear Temporal Logic CDP #2 -...

Documents

Transcript of Mutual Exclusion Linear Temporal Logic CDP #2 -...