1

Reasoning with Promela

Safety properties

• “bad things” do not happen

• can check by inspecting finite behaviours

Liveness properties

• “good things” do eventually happen

• need to check infinite behaviours– e.g. progression

Three types of reasoning in SPIN:

• assertions

• process and system invariants

• proctype monitor {assert (invariant)}

• run monitor, run process1, run process2; ...

• validation labels

• temporal claims (Linear Temporal Logic)

2

Validation Labels

End state labels

• Distinguish between valid and invalid endstates

• valid endstates are not just termination

• could be “acceptable” waiting state

a valid endstate is one where

• all processes reached end of code (i.e. “}”)

• all channels are empty

• it is indicated by a label beginning with “end”

e.g. end, end_1, endhere, …

In SPIN you check for invalid endstates.

Checking for invalid endstates (deadlock) is a SAFETY PROPERTY.

3

End state label: Example

If you check the semaphores example for invalid endstates (deadlock), i.e. with

chan sema = [0] of byte;

proctype Semaphore()

{ do

:: sema!p -> sema?v

od

}

Then an error will be reported because the system will terminate but the process Semaphore will not.

However, if you check the semaphores example for invalid endstates (deadlock), i.e. with

chan sema = [0] of byte;

proctype Semaphore()

{ do

end :: sema!p -> sema?v

od

}

Then no error will be reported because when the system terminates the process Semaphore will be at end.

.

4

Validation Labels

Progress state labels

• Allow you to distinguish between valid and invalid execution cycles.

• Allow you to state that a finite sequence should not be repeated infinitely often through the concept of progress - a process should always be able to make progress.

• The modeller defines what constitutes progress with a progress label.

• progress labels: progress, progress_1, progresshere, ...

In SPIN you check for non-progress (i.e. you might not reach a progress label). SPIN will report an error if there is an execution that does not visit infinitely often a progress state.

Checking for non-progress (livelock) is a LIVENESS PROPERTY.

5

Validation Labels

Progress state label: Examples

chan sema = [0] of byte;

proctype Semaphore()

{end: do

:: sema!p ->

progress: sema?v

od

}

Check for non-progress is passed. (You will always pass progress.)

proctype Loop()

{byte count=1;

do :: count=count+1

:: break

od

progress: skip

}

Contains a non-progress loop. Check for non-progress is not passed An error will be reported because there is a cycle where progress is never reached.

6

Validation Labels

Acceptance state labels

• Distinguish between states that cannot be repeated

infinitely often.

• Converse of progress.

• Acceptance labels: accept1, accept2, etc.

In SPIN you check for acceptance cycles. SPIN will report an error if there is an execution that visits infinitely often an acceptance state.

Checking for acceptance cycles is a LIVENESS PROPERTY.

(Recall: LIVENESS involves consideration of infinite execution sequences.)

7

Validation Labels

Acceptance state labels: Example

chan sema = [0] of byte;

proctype Semaphore()

{end: do

:: sema!p ->

accept: sema?v

od

}

Check that it is impossible to cycle through p and v infinitely often. i.e., check accept is not passed infinitely often.

SPIN would report no acceptance cycles, if this semaphore is used properly.

8

Validation Labels

Acceptance state labels: Example

proctype Loop()

{byte count=1;

accept do :: (count<10)-> count=count+1

:: (count==10) ->break

od

progress: skip

}

SPIN would report no acceptance cycles.

SPIN would report no non-progress cycles.

9

Complexity

Size of state space (worst case) is exponential in no. of processes. E.g. 10n, for n processes.

assertions & end states < progress < accept

assertions & end states

• linear in no. of states (both CPU time and memory)

progress & acceptance

• 2 x CPU time

• no additional memory

10

LTL - Linear Temporal Logic

Propositional logic + temporal operators.

form ::= prop | true | false | (form) | form bop form | uop form

uop ::= [] (always)

| <> (eventually)

| ! (negation)

bop ::= && (conjunction)

| || (disjunction)

| -> (implication)

| U (strong until)

p U q strong iff <>q ****(implemented in SPIN)

weak if []p is a possibility

11

LTL - Linear Temporal Logic

Quantification

When you express an LTL formula, which execution paths does it pertain to?

ALL (or indeed, none).

There is an implicit universal quantification for all formulae

12

LTL - Examples

• Invariance: []p

all states arising in a computation satisfy p.

E.g. [](device == on)

• Response: [](p -> <>q)

every state satisfying p is eventually followed by one which

satisfies q.

E.g. [](device == off) -> <> (device == on)

• Precedence: [](p -> q U r)

every state satisfying p is followed by a sequence in which q is

satisfied and that sequence is terminated by a state in which r

is satisfied.

E.g. [](device == off) -> (device == off) U (event == toggle)

13

LTL

A formula is interpreted with respect to a computation path and a state. Note the difference between [], <> and []<>.

• []p

Consider computation path s0 s1 s2 s3 ….. sn sn+1 … and current state s0.

p has to hold at every si.

• <>p

Consider computation path s0 s1 s2 s3 ….. sn sn+1 …and current state s0.

p has to hold at some sj, j>=0.

• [] <>p

Consider computation path s0 s1 s2 s3 ….. sn sn+1 …and current state s0.

for every state si, there is a state sj, j>=i, s.t. p holds at sj.