Modeling

and Analyzing
Concurrent Systems

Robert B. France

1
 Overview
Why model and analyze concurrent systems?
How are concurrent systems modeled?
How are concurrent systems analyzed?

2
 References

Principles of Model Checking

Christel Baier and Joost-Pieter Katoen, MIT
Press
Some of the slides use diagrams and text
extracted from the above book

3
 Overview
Why model and analyze concurrent systems?
How are concurrent systems modeled?
How are concurrent systems analyzed?

4
 Why model concurrent systems?
Distributed, concurrent systems are becoming
commonplace, but they are notoriously dicult to
develop
network applicaOons, data communicaOon protocols, mulOthreaded code,
client-server applicaOons
Concurrency-specic errors: deadlock, livelock
A deadlock occurs when the system cannot has reached a
state in which no work is done but at least one process in the
system needs to complete its tasks
A livelock occurs when the processes in a system are stuck in
a repeOOve task and make no progress towards their
funcOonal goals.
These types of behavioral errors can be mechanically
detected if the systems are properly modeled and
analyzed 5
 Common aws in concurrent systems
UnderspecicaOon: Model is incomplete, imprecise or allows behavior
that should not be allowed (i.e., model is too permissive).
OverspecicaOon: Model disallows behavior that should be allowed, that
is, model is to restricOve
ViolaOons of safety properOes: A safety property is a property that must
not be violated
nothing bad should happen; a bad behavior should never occurs
An invariant is an example of a safety property
Example 1: Mutual exclusion property at most one process is in its criOcal secOon
at any given Ome
Example 2: Absence of deadlocks:
ViolaOons of liveness properOes: Set of properOes that a system must
saOsfy, i.e., properOes that require desired events eventually occur
something good eventually happens
Example 1: StarvaOon freedom (e.g., each process waiOng to enter its criOcal
secOon will eventually enter its criOcal secOon.
Example 2: Progress: A process will eventually perform a non-skip step

6
 What is Model Checking?
Model checking is an automated technique that,
given a nite-state model of a system and a
logical property, systemaOcally checks whether
this property holds for (a given iniOal state in)
that model. [Clarke & Emerson 1981]:
Model checking tools automaOcally verify
whether M=, holds, where M is a (nite-state)
model of a system and property (phi)
characterizes a set of allowed behaviors.
M has behavior that is allowed by
Check that M is a model of

7
 Model Checking process
1. Construct a model of the system (M)
2. Formalize the properOes that will be evaluated
in the model (P)
3. Use a model checker to determine if M saOses
P. Three results are possible:
1. The model M saOses the property P, i.e. M |= P
2. M does not saOsfy P; in this case a counterexample is
produced
3. No conclusive result is produced by the model
checker (model checker ran out of space or Ome)

8
 What is meant by model in model
checker?
The term model as used in model checker is an
assignment of values to variables in a logical formula
that makes the formula true. AlternaOvely, a formula
denes a family of models or instances (where an
instance saOses the formula)
For example, a model of a proposiOon is an assignment of
truth values to the proposiOon variables that makes the
proposiOon true (e.g., a line in a truth table is a model)
A model checker checks whether a system model, M, is
an instance of the property,
That is, it checks if the system model is an assignment of
values to variables in the property that makes the property
true.

9
Is the Alloy Analyzer a Model Checker?

No! It is a Model Finder

The Analyzer generates an instance that
saOses the constraints in signatures,
facts and the condiOon in the predicates
or asserOons.

10
 Overview
Why model and analyze concurrent systems?
How are concurrent systems modeled?
How are concurrent systems analyzed?

11
How can we describe a system so that it
can be mechanically model-checked?
First we focus on linear temporal behavioral properOes
Linear model of Ome; no branching in the Omeline over
which behaviors are observed
Behaviors expressed in terms of TransiOon Systems
that describe the eect of operaOons on the systems
state.
A linear temporal (LT) property characterizes a set of
state transiOons
A model saOses a linear temporal property if the state
transiOons it denes are all included in the transiOons
characterized by the LT property.

12
TransiOon systems

13
 Using TransiOon Systems to model
system behavior
A Transi7on System (TS) is a directed graph
where nodes represent states and edges
represent transiOons between states
A state describes informaOon about a system at a
parOcular point in Ome (cf. state in Alloy)
E.g., the state of a trac light indicates the color of
the light that is illuminated at a point in Ome
A transi7on describes the condiOons under which
a system moves from one state to another.

14
 A (toy) example of a simple TS

Transitions are associated with action labels that indicate the actions
that cause the transition.
insert_coin is a user action

get_soda, get_beer are actions performed by the machine

denotes an activity that is not of interest to the modeler (e.g.,

it represents an internal activity of the vending machine)
15
 Transi7on System (TS): Formal Deni7on

A transi7on system TS is a tuple (S, Act,, I,AP, L) where

S is a set of states,
Act is a set of acOons,
-> S Act S is a transiOon relaOon (the rst element in the triplet is the source state,
the second element is an acOon and the third element is the target state of the transiOon)
I S is a set of iniOal states,
AP is a set of atomic proposiOons, and
L : S 2AP is a labeling funcOon (2AP is the power set of AP)

TS is called nite if S, Act, and AP are nite.

(s, act, s) in -> is wrimen as s -a-> s

L(s) are the atomic proposiOons in AP that are saOsed in state s.

Given a formula, f,, a state s saOses f (i.e., is a model of f) if and only if f
can be derived from the atomic proposiOons associated with state s
via the labeling funcOon L, that is:
s |= f i L(s) |= f
16
 Toy example again

S = {pay, select, soda, beer}

I = {pay}
Act = {insert_coin, get_soda, get_beer, T}
-> = {(pay, insert_coin, select), (beer, get_beer,
pay), (soda, get_soda, ay), (select, , soda),
(select, , beer)} 17
 Atomic proposi7ons in the toy Example

The atomic proposiOons in a

transiOon system are chosen
based on the properOes the
modeler wants to check.

Example property to verify: The vending machine only delivers

a drink arer the user pays (inserts a coin).
Relevant atomic proposiOons: AP = {paid, delivered}
Appropriate Labeling funcOon:
L(pay) = empty set
L(soda)=L(beer)={paid, delivered}
L(select)={paid}
18
 Using non-determinism to under-
specify a problem
The toy model is non-determinisOc: When the system
enters the select state, the transiOon system non-
determinisOcally chooses to dispense beer or soda (i.e., it
makes a choice that cannot be determined beforehand by
examining the model).
In this case the model deliberately abstracts over the
mechanism a vending machine customer uses to select
soda or beer
In other words, the modeler is leaving open the choice of how
this is done; someone implemenOng the model needs to resolve
this non-determinism to make the system determinisOc
Non-determinisOc choice is also used to model concurrent
(parallel) behavior as we will see later.

19
 AcOon-DeterminisOc TS
Post(s,act) are all the target states associated
with s via transiOons labeled with act; i.e.,
Post(s,act) = {s: State | s act-> s}
TS = (S, Act, ->, I, AP, L) is acOon-determinisOc
if
#(I) <= 1 (# returns the number of elements in its
set argument)
For all states s in S and acOons act in Act, #(Post
(s,act)) <= 1, where

20
 AP-DeterminisOc TS
Post(s) consists of all the target states
associated with s via transiOons; i.e., Post(s) =
Uact in Act Post(s,act)
TS = (S, Act, ->, I, AP, L) is AP-determinisOc if
#(I) <= 1
For all states s in S, and A in 2AP, #(Post(s)
intersect {s:State | L(s) = A}) <= 1

21
 Observable behavior
Oren useful to have behavior that is observable
by external agents be determinisOc
Two observable views
AcOon-based view: only the acOons are observable
State-based view: only the states, via the proposiOons
associated with them, are observable
The two noOons of determinisOc behavior discussed
in the previous slides support these views.

22
 ExecuOons of a TS
TS ExecuOons formalize the noOon of behavior in a modeled
system
A nite execu7on fragment of a TS is a sequence of state
transiOons.
For example, s0-act1->s1, s1-act2->s3, is wrimen as an alternaOng
sequence of states and acOons that ends in a state, s0,act1,s1,act2,s3
An innite execu7on fragment is an innite sequence of
transiOons
A maximal execu7on fragment is either a nite execuOon
fragment that ends in a nal state, or an innite execuOon
fragment.
An execuOon fragment is called iniOal if it starts in an iniOal state.
An execuOon of a transiOon system is an iniOal maximal
execuOon fragment
23
 ExecuOons of the vending machine

Reachability of states: A state in a transition

system is reachable if there is an initial finite
execution fragment that ends in s.

24
 Modeling concurrent systems that
manipulate data
In sorware the transiOon from one state to
another oren depends on condiOons expressed
in terms of data
Condi7onal transi7ons are higher-level constructs
used to describe acOons that are performed only
under certain condiOons
Models with condiOonal transiOons are called
program graphs
Program graphs are higher-level in that they can be
transformed into TSs (Note: TSs do not have
condi7onal transi7ons) via a process called unfolding

25
 Extended vending machine example
Vending machine extended to:
to maintain informaOon on number of beers and
soda in machine
nsoda: variable that stores number of soda in vending
machine at a parOcular Ome
nbeer: variable that stores number of beer in vending
machine at a parOcular Ome
return coins entered by user if product is not
available
ret_coin: represents the return coin acOon

26
 Program graph of the extended vending machine

select and start are called loca7ons

nsoda, and nbeer are variables
coin, rell, sget, bget, ret_coin are ac7ons 27
 A simple text representaOon of the
vending machine PG
start:
coin; go to select
rell{nsoda := max; nbeer := max}; go to start
select:
nsoda > 0:: sget{nsoda := nsoda -1}; go to start
nbeer > 0:: bget{nbeer := nbeer-1}; go to start
nsoda = 0 and nbeer = 0:: ret_coin; go to start

28
Unfolding the vending machine PG

bget sget

29
 Program Graphs
A program graph over a set of typed variables,
Var, consists of nodes represenOng locaOons
and edges represenOng condiOonal transiOons
In the vending machine example Var = {nsoda,
nbeer}
A program graph also denes eects of acOons
on the variables
An eect is a funcOon that takes an acOon and an
assignment of values to variables and returns a
new assignment of values to variables (the new
assignment is the eect of the acOon)

30
 Program Graph (PG): Formal Deni7on
A program graph PG over set Var of typed variables is a tuple
(Loc, Act, Eect,->, Loc0, g0) where
Loc is a set of locaOons and Act is a set of acOons,
Eect : Act Eval(Var) --> Eval(Var) is the eect funcOon,
Eval(Var) is the set of assignments of values to variables in Var,
e.g.,{ <nbeer:= 10, nsoda:=20>, <nbeer:= 1, nsoda:=20>,
<nbeer:=0, nsoda:=4>, } is the set of assignments when Var =
{nbeer, nsoda}
-> Loc Cond(Var) Act Loc is the condiOonal
transiOon relaOon,
Cond(Var) is the set of all Boolean condiOons (proposiOons) over
Var
Loc0 Loc is a set of iniOal locaOons,
g0 Cond(Var) is the iniOal condiOon.

31
 Vending machine program graph
Loc={start, select}
Var={nsoda, nbeer}
Act={bget, sget, coin, ret_coin, refill}
Effect(coin, ) =
Effect(ret_coin, ) =
Effect(sget, ) = [nsoda = nsoda - 1]
Effect(bget, ) = [nbeer = nbeer - 1]
Effect(refill, ) = [nsoda=max, nbeer=max]
In the above is an assignment of values to variables in Var
[v=f(v)] means that the new assignment to variable v is a
function, f, of the previous assignment of v and all other
variable assignments are unchanged
Loc0 = start 32

g0 = nsoda = max and nbeer = max

 TS semanOcs of program graphs
The TS is produced by unfolding the program graph
You can think of unfolding as a representaOon of the
execuOon of a program described by a PG
A state consists of a locaOon (a point in the program)
and an assignment of values to variables: <l,>
An iniOal state consists of an iniOal locaOon and an
assignment that saOses the condiOon g0 dened in the
PG
<l0,> is an iniOal state if l0 is an iniOal locaOon and |= g0
The proposiOons consists of the locaOons together
with Cond(Var)
The proposiOon loc is true in any state of the form <loc,
>, and false otherwise

33
Transi7on System Seman7cs of a Program Graph

34
 Structured OperaOonal SemanOcs
The semanOcs dened previously is an
example of SOS
The semanOcs uses inference rules of the form

35
Using transiOon systems to
model concurrent behavior

36
 Concurrent systems
A concurrent (parallel) system consists of
mulOple processes execuOng concurrently (in
parallel).
If a concurrent system consists of n processes,
in which each process, proci, is modeled by a
transiOon system TSi, the concurrent system
can be modeled by a transiOon system
TS = TS1 || TS2 || || Tsn
where || is a parallel composiOon operator

37
Types of parallel composiOon operators
Interleaving
AcOons of concurrent processes are interleaved in a non-determinisOc
manner
Used to model processes whose behaviors are completely
independent (asynchronous system of processes)
Communica7on via shared variables
A process can inuence the behavior of another process by changing
the value of a variable that is shared with the process
Handshaking
Two processes that want to interact must synchronize their acOons
such that they take part in the interacOon at the same Ome
Channel systems
In a channel system processes interact by reading from and wriOng to
channels connecOng them

38
Interleaving

39
 Interleaving of processes
When processes can execute in a completely
independent manner (with no interacOons) one
can view the system of processes as one system
consisOng of the acOons of each process merged
(interleaved) in an arbitrary manner
In this system concurrency means that the order in
which the acOons are performed does not aect the
nal result; i.e., P1.act1;P2.act2 produces the same
result as P2.act2;P1.act1, where Pi.ac7 is an acOon
performed by process Pi (i=1 or i =2)
The interleaving view is an abstracOon in which
only one processor is assumed available to
execute the processes
40
 Interleaving of Trac Light Transi7on Systems

Consider a system with two traffic

lights, each modeled by a transition
system

Interleaved System
Interleaving operator: |||

41
Eect of an interleaving operator

The above states that the order in which the

actions , are performed does not matter.
||| is the interleaving operator
; is sequential composition
+ represents non-deterministic choice

42
Eect of an interleaving operator: An
example
Note that
variables are not
shared across
processes

43
Formal deniOon of interleaving
operator

44
CommunicaOon via Shared
Variables

45
 Modeling non-asynchronous systems
Interleaving operator requires that processes
are completely independent
What happens if processes access data that is
globally accessible (global data)?
See example on next slide

46
 Interleaving in the presence of shared
variables
Consider the program graph describing 2 actions from 2
processes, PG1, PG2, that access a global variable x
(locations are omitted to simplify the presentations)
: x := 2 * x
: x := x + 1
( ||| ) = (x := 2 * x ||| x := y + 1)

TS(PG1) TS(PG2) TS(PG1)|||TS(PG2)

47
Modeling processes that access global
variables
An interleaving operator, |||, on program
graphs (rather than transiOon systems) is used
PG1 ||| PG2
TS(PG1 ||| PG2) describes a TS that treats
shared variables appropriately
In general,
TS(PG1 ||| PG2) TS(PG1) ||| TS(PG2)

48
Interleaving of Program Graphs

49
 Interleaving of Two Example Program Graphs

location
conditional
transition with
assignment action

Transition
system for
Interleaved interleaved
PG PG

50
 Non-determinism
Non-determinism in a state of a TS produced by a
interleaved PG can be interpreted in 3 ways:
1. As an internal non-determinisOc choice made in the
PG
2. As an interleaving of acOons that access variables
that are not shared (referred to as non-cri7cal
ac7ons)
3. As the resoluOon of a contenOon between acOons of
PG1 and PG2 that access global variables (referred to
as cri7cal ac7ons)

51
 Accessing global variables
CriOcal acOons are those that access global
variables
Access to global variables needs to be
controlled
Only one criOcal acOon can access a global
variable at any Ome
How do we ensure this? The mutual exclusion
problem

52
 Mutual exclusion using semaphores
Two processes with criOcal acOons use a shared
variable, y, called a semaphore to determine
when they can perform their criOcal acOons, i.e.,
enter their criOcal secOons.
y = 0 indicates that one process is execuOng its criOcal
acOons (i.e., is in its criOcal secOon), and thus the
other cannot execute its criOcal acOons; The process
that is execuOng its criOcal secOon in essence locks
access to the global variables.
y = 1 indicates that none of the processes are in their
criOcal secOons (access to the global variables is
unlocked)

53
CriOcal vs. non-criOcal secOons

54
Program graphs for semaphore-based
mutual exclusion

55
Reachable states

56
TS(PG1|||PG2)

57
 Petersons mutual exclusion algorithm
In the semaphore approach the choice of which
process enters its criOcal secOon is made non-
determinisOcally
That is, it is up to the implementer of the model to
determine how the next process to enter its criOcal secOon
is determined
Petersons algorithm makes an explicit choice
Uses variables b1, b2, and x
b1:Boolean - true if P1 is waiOng to enter its criOcal secOon
or is in its criOcal secOon (i.e., b1 = wait1 or crit1)
b2:Boolean - true if P2 is waiOng to enter its criOcal secOon
x:{1,2} - if x = 1 then P1 can enter its criOcal secOon; else (x
= 2) P2 can enter its criOcal secOon
58
59
TransiOon System

60
 Atomicity
The assignment group (bi:=true; x:=i), where i = 1
or 2, are atomic, i.e., together they are treated as
a single acOon; the individual assignments cannot
be interleaved with other acOons
This is not essenOal for Petersens algorithm to
work
Mutual exclusion can also be ensured when the
processes perform these acOons in the given order
Mutual exclusion is NOT guaranteed if the operaOons
are performed in reverse order, i.e., (x:=i,; bi:=true)

61
Example of violaOon of mutual
exclusion

62
Handshaking

63
 Synchronous interacOons
Processes can also interact through a set of
synchronizing acOons, H, called handshake
ac7ons
Processes interact only if they all can perform the
same handshake acOon at the same Ome
i.e., the models must shake hands for the
interacOon to take place
These acOons may involve the transfer of data
This transfer will be ignored in the models we
consider, i.e., we are interested only in the occurrence
of the handshake and not in the data that is
exchanged

64
Handshaking (Synchronous Message Passing)

65
 Handshaking forms

Empty set of handshake actions reduces to interleaving

Models broadcasting communication

66
 Mutual exclusion using an Arbiter
process
Model the semaphore as a separate process,
called an Arbiter
Example: TS1 and TS2 are the transiOon
systems of the parallel processes and Arbiter is
the semaphore process

67
68
 Railroad crossing example
Three processes in the system: Train, Gate,
Controller.
When the Controller receives a signal that a
train is approaching it closes the gate
The gate is opened only arer the train has
sent a signal to the Controller indicaOng it has
crossed the road.

69
70
71
Channel Systems

72
 Asynchronous message passing
Processes interact by passing informaOon to each
other via channels of nite or innite capacity
A channel is like a buer
System thus consists of processes and channels
If channel capacity > 0 the processes do not need
to wait for a response from receiver when
sending a message
If channel capacity is 0 then this form of
interacOon reduces to handshaking
Each channel can accept messages of a specied
type only

73
 CommunicaOon acOons
Processes can perform the following communication
actions:

74
Formal deniOon

75
Enabling communicaOon acOons

76
77
 Example: AlternaOng Bit Protocol
System consists of two processes, S (sender), R (receiver) that
communicate over two channels, c, d
Channel c is unreliable (lossy) in that it can lose messages during
transmission; channel d is perfect
The goal of the design is to ensure that data units (datums) transmimed by
S are received by R
S sends data of the form <m,b>, where m is a message and b is a control bit
that cab be either 0 or 1
S transmits a message and waits for R to acknowledge receipt; if an
acknowledgement is not received within a given Ome S retransmits the
message
If R receives the message then it sends an acknowledgement consisOng of the
control bit it received

78
PG for Sender

79
PG for Receiver, Timer

80
TS SemanOcs

81
82
 Coming up
Why model and analyze concurrent systems?
How can concurrent systems be modeled?
How can concurrent systems be analyzed?
What tools are available for modeling and
analyzing concurrent systems?
IntroducOon to Promela/Spin

83