Reasoning with Promela

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

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 -gt 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 -gt sema?v

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 -gt
• progress sema?v
• od
• Check for non-progress is passed. (You will
  always pass progress.)
• proctype Loop()
• byte count1
• do countcount1
• break

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 -gt
• 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 count1
• accept do (countlt10)-gt countcount1
• (count10) -gtbreak
• 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 lt progress lt 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)
ltgt (eventually) !
(negation) bop
(conjunction)
(disjunction) -gt
(implication) U
(strong until) p U q strong iff
ltgtq (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 -gt ltgtq)
• every state satisfying p is eventually
  followed by one which
• satisfies q.
• E.g. (device off) -gt ltgt (device on)
• Precedence (p -gt 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

13
LTL

• A formula is interpreted with respect to a
  computation path and a state. Note the difference
  between , ltgt and ltgt.

• p
• Consider computation path s0 s1 s2 s3 ..
  sn sn1 and current state s0.
• p has to hold at every si.
• ltgtp
• Consider computation path s0 s1 s2 s3 .. sn
  sn1 and current state s0.
• p has to hold at some sj, jgt0.
• ltgtp
• Consider computation path s0 s1 s2 s3 .. sn
  sn1 and current state s0.
• for every state si, there is a state sj, jgti,
  s.t. p holds at sj.