Concurrent and Distributed Programming SPIN Tutorial part I

1
Concurrent and Distributed ProgrammingSPIN
Tutorial part I
www.cs.utwente.nl/pieter/cdp/
2
CDP SPIN Lectures

• SPIN part I
• Introduction
• SPIN Background
• Promela processes
• Promela statements
• Promela communication
• Some demos SPIN and Xspin

• SPIN part II
• Some more Promela constructs
• Verification properties
• How does SPIN work?
• How to write efficient SPIN models?

• Programs in Ben-Ari are written in Ada.
• In this course we will use Promela, the modelling
  language of SPIN.
• CDPs website contains translations of all Ada
  programs to Promela.

Windows 2000/XP OK, but SPIN runs more smoothly
under Unix/Linux.
3
Common Design Flaws

• Deadlock
• Livelock, starvation
• Underspecification
• unexpected reception of messages
• Overspecification
• Dead code
• Violations of constraints
• Buffer overruns
• Array bounds violations
• Assumptions about speed
• Logical correctness vs. real-time performance

In designing distributed systems network
applications, data communication protocols,
multithreaded code, client-server applications.
Designing concurrent (software) systems is so
hard, that these flaws are mostly overlooked...
Fortunately, most of these design errors can be
detected using model checking techniques!
4
What is Model Checking?

• Clarke Emerson 1981
• Model checking is an automated technique that,
  given a finite-state model of a system and a
  logical property, systematically checks whether
  this property holds for (a given initial state
  in) that model.

• Model checking tools automatically verify
  whether holds, where M is a (finite-state)
  model of a system and property ? is stated in
  some formal notation.
• Problem state space explosion!
• SPIN Holzmann 1991 is one of the most
  powerful model checkers.

Although finite-state, the model of a system
typicallygrows exponentially.
Based on Vardi Wolper 1986.
5
What is Model Checking?
Model Checker
YES,property issatisfied
6
System Development
ClassicModel Checking
ModernModel Checking
Classic waterfall modelPressman 1996
7
Classic vs Modern Approach
Modern Approach
Classic Approach
(initial) Design
(manual)abstractions
ModelChecker
AbstractVerification Model
AbstractVerification Model
refinementtechniques
abstraction techniques
C, Java
Implementation
Implementation
Abstraction is the key activityin both
approaches.
To cope with the state space explosion.
8
Verification vs. Debugging

• Two (extreme) approaches with respect to the
  application of model checkers.
• verification approach tries to ascertain the
  correctness of a detailed model M of the system
  under validation.
• debugging approach tries to find errors in a
  model M.
• Model checking is most effective in combination
  with the debugging approach.

Automatic verification is not about proving
correctness, but about finding bugs much earlier
in the development of a system.
9
FMSE (1)

• FMSE Modelling and Analysis of System Behaviour
• FSP (finite state processes) textual
  representation
• LTS (labelled transition systems) graphical
  representation
• LTSA analysis of LTS/FSP models
• FSP is a process algebra
• operators
• stop, action prefix (a -gt B), choice (b -gt B c
  -gt C), indexed actions (to simulate integers),
  indexed processes (to simulate parameters),
  relabeling, hiding (relabeling with tau),
  parallel composition
• synchronization communication (on identical
  actions)
• bisimulation
• non-determinism

10
FMSE (2)

• Problems discussed
• Alternating bit protocol
• Dining Philosophers
• Readers/Writers model
• Hippies/Soldiers problem
• Properties
• A safety property asserts that nothing bad
  happens (e.g. no deadlocked states).
• A liveness property asserts that something good
  will eventually happen (e.g. always normal
  termination).

11
SPIN Introduction (1)
http//spinroot.com

• SPIN ( Simple Promela Interpreter)
• is a tool for analysing the logical conisistency
  of concurrent systems, specifically of data
  communication protocols.
• state-of-the-art model checker, used by gt2000
  users
• concurrent systems are described in the
  modelling language called Promela.

12
SPIN Introduction (2)

• Promela ( Protocol/Process Meta Language)
• specification language to model finite-state
  systems
• loosely based on CSP
• dynamic creation of concurrent processes
• communication via message channels can be
• synchronous (i.e. rendezvous), or
• asynchronous (i.e. buffered)
• features from Dijkstras guarded command language
• features from the programming language C

Promela is a modelling language, not a
programming language!
13
SPIN Introduction (3)

• Major versions

• Some success factors of SPIN
• press on the button verification (model
  checker)
• very efficient implementation (using C)
• nice graphical user interface (Xspin)
• not just a research tool, but well supported
• contains more than two decades research on
  advanced computer aided verification (many
  optimization algorithms)

1983 Unix1986 TeX 1997 Tcl/Tk 2002 Java
14
Documentation on SPIN

• SPINs starting pagehttp//spinroot.com
• Basic SPIN manual
• Getting started with Xspin
• Getting started with SPIN
• Examples and Exercises
• Concise Promela Reference (by Rob Gerth)
• Proceedings of all ten SPIN Workshops
• Gerard J. HolzmannThe Spin Model Checker Primer
  and Reference Manual Addison Wesley ISBN
  0-32122-862-6, 608 pages, covers SPIN up to
  version 4.0.

15
Installation of SPIN
http//spinroot.com

• SPIN binarieshttp//spinroot.com/spin/Bin/index.h
  tml
• Windows 95/98/2000/NT/XPNeed to install
• C compiler (Visual C / DJGPP /
  Cygwin)http//www.cygwin.com
• Tcl/Tk 8.x interpreter (for XSpin)http//aspn.act
  ivestate.com/ASPN/Tcl
• Linux
• Solaris
• SPIN sourceshttp//spinroot.com/spin/Src/index.ht
  ml
• SPIN can be compiled on any UNIX system,
  including Apples Mac OS X.

16
Promela Model (1)

• A Promela model consist of
• type declarations
• channel declarations
• global variable declarations
• process declarations
• init process

mtype, constants,typedefs (records)
chan ch dim of type, asynchronous dim
gt 0 rendez-vous dim 0
- simple vars- structured vars- vars can be
accessed by all processes
behaviour of the processeslocal variables
statements
initialises variables andstarts processes
17
Promela Model (2)

• Promela model consist of
• type declarations
• channel declarations
• variable declarations
• process declarations
• init process
• A Promela model corresponds with a (usually very
  large, but) finite transition system, so
• no unbounded data
• no unbounded channels
• no unbounded processes
• no unbounded process creation

mtype MSG, ACK chan toS ... chan toR
... bool flag proctype Sender()
... proctype Receiver() ... init
...
process body
creates processes
18
Processes (1)

• A process
• is defined by a proctype definition
• executes concurrently with all other processes,
  independently of speed or behaviour
• communicates with other processes
• using global (shared) variables
• using channels
• There may be several processes of the same type.
• Each process has its own local state
• process counter (location within the proctype)
• contents of the local variables

19
Processes (2)

• A process type (proctype) consist of
• a name
• a list of formal parameters
• local variable declarations
• body

name
proctype Sender(chan in chan out) bit
sndB, rcvB do out ! MSG, sndB -gt
in ? ACK, rcvB if
sndB rcvB -gt sndB 1-sndB
else -gt skip fi od
local variables
The body consist of a sequence of statements.
20
Processes (3)
proctype Foo(byte x) ... init int
pid2 run Foo(2) run Foo(27) active3
proctype Bar() ...

• Process are created using the run statement
  (which returns the process id).
• Processes can be created at any point in the
  execution (within any process).
• Processes start executing after the run
  statement.
• Processes can also be created by adding active in
  front of the proctype declaration.

number of procs. (opt.)
parameters will be initialised to 0
21
Hello World!

• / A "Hello World" Promela model for SPIN. /
• active proctype Hello() printf("Hello
  process, my pid is d\n", _pid)
• init int lastpid printf("init
  process, my pid is d\n", _pid) lastpid
  run Hello() printf("last pid was d\n",
  lastpid)

automatic local variable process id
random seed
spin -n2 hello.pr init process, my pid is 1
last pid was 2 Hello process, my pid is 0
Hello process, my pid is 2 3
processes created
running SPIN in random simulation mode
22
Variables and Types (1)
Basic types bit turn1 0..1 bool
flag 0..1 byte counter 0..255 short
s -215.. 215 1 int msg -231.. 231
1 Arrays byte a27 bit flags4 Typedef
(records) typedef Record short f1 byte
f2 Record rr rr.f1 ..

• Five different (integer) basic types.
• Arrays
• Records (structs)
• Type conflicts are detectedat runtime ?.
• Default initial value of basic variables (local
  and global) is 0.

array indexing start at 0
variable declaration
23
Variables and Types (2)
int ii bit bb bb1 ii2 short
s-1 typedef Foo bit bb int ii Foo
f f.bb 0 f.ii -2 iis27
23 printf(value d, ss)

• Variables should be declared.
• Variables can be given a value by
• Initialisation
• assignment
• argument passing
• message passing(see communication)
• Variables can be used in expressions.

assignment
declaration initialisation
equality test
Most arithmetic, relational, and logical
operators of C/Java are supported, including
bitshift operators.
24
Statements (1)

• The body of a process consists of a sequence of
  statements. A statement is either
• executable the statement can be executed
  immediately.
• blocked the statement cannot be executed.
• An assignment is always executable.
• An expression is also a statement it is
  executable if it evaluates to non-zero.
• 2 lt 3 always executable
• x lt 27 only executable if value of x is smaller
  27
• 3 x executable if x is not equal to 3

executable/blocked depends on the global state of
the system.
25
Statements (2)
Statements are separated by a semi-colon .
or by the equivalent -gt

• The skip statement is always executable.
• does nothing, only changes process process
  counter
• A run statement is only executable if a new
  process can be created (remember the number of
  processes is bounded).
• A printf statement is always executable (but is
  not evaluated during verification, of course).

int x proctype Aap() int y1 skip run
Noot() x2 xgt2 y1 skip
Executable if Noot can be created
Can only become executable if some other process
makes x greater than 2.
26
Statements (3)

• assert(ltexprgt)
• The assert-statement is always executable.
• If ltexprgt evaluates to zero, SPIN will exit with
  an error, as the ltexprgt has been violated.
• The assert-statement is often used within Promela
  models, to check whether certain properties are
  valid in a state.

proctype monitor() assert(n lt
3) proctype receiver() ... toReceiver ?
msg assert(msg ! ERROR) ...
27
Interleaving Semantics

• Promela processes execute concurrently.
• Non-deterministic scheduling of the processes.
• Processes are interleaved (statements of
  different processes do not occur at the same
  time).
• exception rendez-vous communication.
• All statements are atomic each statement is
  executed without interleaving with other
  processes.
• Each process may have several different possible
  actions enabled at each point of execution.
• only one choice is made, non-deterministically.

? randomly
28
(random) Simulation Algorithm
deadlock ? allBlocked
while (!error !allBlocked) ActionList
menu getCurrentExecutableActions()
allBlocked (menu.size() 0) if (!
allBlocked) Action act
menu.chooseRandom() error
act.execute()
interactive simulation act is chosen by the user
act is executed and the system enters a new state
Visit all processes and collect all executable
actions .
29
Mutual Exclusion (1)

• Mutual Exclusion is a safety property among
  processes
• Two processes may not interleave certain
  (sub-)sequences of instructions (i.e. the
  critical section). Instead, one sequence must be
  completed before the other commences.
• Properties to be satisfied
• at most one process can be in the critical
  section at the same time
• no deadlocks
• no halting in the critical section
• no starvation of one of the processes
• Java has special construct to protect critical
  sections
• synchronized

30
Mutual Exclusion (2)
WRONG!

• bit flag / signals entering/leaving the
  section /byte mutex / procs in the
  critical section (CS). /
• proctype P(bit i) flag ! 1 flag 1
  mutex printf("MSC P(d) has entered
  section.\n", i) mutex-- flag 0
• proctype monitor() assert(mutex ! 2)
• init atomic run P(0) run P(1) run
  monitor()

models while (flag 1) / wait /
31
Mutual Exclusion (3)
WRONG!

• bit a, b / signal entering/leaving the
  section /byte mutex / of procs in the
  critical section. /
• active proctype A() a 1 b 0
  mutex mutex-- a 0
• active proctype monitor() assert(mutex !
  2)

active proctype B() b 1 a 0
mutex mutex-- b 0
32
Mutual Exclusion (4)

• bit a, b / signal entering/leaving the
  section /byte mutex / of procs in the
  critical section. /byte turn / who's turn
  is it? /
• active proctype A() a 1 turn B_TURN
  b 0 (turn A_TURN) mutex
  mutex-- a 0
• active proctype monitor() assert(mutex !
  2)

active proctype B() b 1 turn A_TURN
a 0 (turn B_TURN) mutex
mutex-- b 0
Either B does not yet want to enter, or A was
here first.
Can be generalisedto a single process.
33
(X)Spin Architecture

• deadlocks
• safety properties
• liveness properties

?
M
Promela

spin.exe
verifier generator
simulator
LTL translator
random guided interactive
ANSI C
34
Xspin in a nutshell

• Xspin allows the user to
• edit Promela models ( syntax check)
• simulate Promela models
• random
• interactive
• guided
• verify Promela models
• exhaustive
• bitstate hashing mode
• additional features
• Xspin suggest abstractions to a Promela model
  (slicing)
• Xspin can draw automata for each process
• LTL property manager
• Help system (with verification/simulation
  guidelines)

with dialog boxes to setvarious options and
directivesto tune the verification process