1. Formal Methods for Software Engineering
Lecture 6, Part II:
Deadlock & Safety Analysis

2. Contents Deadlock analysis Safety analysis Distributed deadlocks
Dining philosophers
Searching by deadlock analysis
Safety analysis
Safety properties
Single-lane bridge problem
Ed Brinksma
FMSE, Lecture 6

3. Basic Deadlock
A deadlock state is a state with no outgoing transitions
In FSP such states can be directly represented as a STOP process
MOVE = (north->
(south->MOVE
|north->STOP)).
MOVE
north
south 1 2
Deadlock state
We can use LTSA to find the shortest trace to such deadlock states.
Trace to DEADLOCK:
north
Ed Brinksma
FMSE, Lecture 6

4. Distributed Deadlock
Deadlock may arise from the parallel composition of processes without deadlock states.
printer:
RESOURCE
get
put
SYS
scanner:
p:P
printer
scanner
q:Q
RESOURCE = (get->put->RESOURCE).
P = (printer.get->scanner.get->copy
->printer.put->scanner.put->P).
Q = (scanner.get->printer.get->copy
->scanner.put->printer.put->Q).
||SYS = (p:P||q:Q
||{p,q}::printer:RESOURCE
||{p,q}::scanner:RESOURCE).
Deadlock Trace? Avoidance?
Ed Brinksma
FMSE, Lecture 6

5. Wait-for Cycle Has A awaits B A Has E awaits A E B Has B awaits C D C
Has C awaits D
Has D awaits E
Ed Brinksma
FMSE, Lecture 6

6. Deadlock Avoidance acquire resources in the same order, or
introduce a timeout:
P = (printer.get-> GETSCANNER),
GETSCANNER = (scanner.get->copy->printer.put
->scanner.put->P
|timeout -> printer.put->P).
Q = (scanner.get-> GETPRINTER),
GETPRINTER = (printer.get->copy->printer.put
->scanner.put->Q
|timeout -> scanner.put->Q).
Deadlock? Progress?
Ed Brinksma
FMSE, Lecture 6

7. Dining Philosophers
Five philosophers sit around a circular table. Each philosopher spends his life alternately thinking and eating. In the centre of the table is a large bowl of spaghetti. A philosopher needs two forks to eat a helping of spaghetti. 1 2 3 4
One fork is placed between each
pair of philosophers and they agree that each will only use the fork to his immediate right and left.
Ed Brinksma
FMSE, Lecture 6

8. Model Structure Diagram
phil[4]:
PHIL
phil[1]:
phil[3]:
phil[0]:
phil[2]:
FORK
left
right
Each FORK is a shared resource with actions get and put.
When hungry, each PHIL must first get his right and left forks before he can start eating.
Ed Brinksma
FMSE, Lecture 6

9. The FSP Model Table of philosophers: Can this system deadlock?
FORK = (get -> put -> FORK).
PHIL = (sitdown -> right.get -> left.get
-> eat -> right.put -> left.put
-> arise -> PHIL).
Table of philosophers:
||DINERS(N=5)= forall [i:0..N-1]
(phil[i]:PHIL ||
{phil[i].left,phil[((i-1)+N)%N].right}::FORK ).
Can this system deadlock?
Ed Brinksma
FMSE, Lecture 6

10. Dining Philosophers Analysis
Trace to DEADLOCK:
phil.0.sitdown
phil.0.right.get
phil.1.sitdown
phil.1.right.get
phil.2.sitdown
phil.2.right.get
phil.3.sitdown
phil.3.right.get
phil.4.sitdown
phil.4.right.get
This is the situation where all the philosophers become hungry at the same time, sit down at the table and each philosopher picks up the fork to his right.
The system can make no further progress since each philosopher is waiting for a fork held by his neighbour i.e. a wait-for cycle exists!
Ed Brinksma
FMSE, Lecture 6

11. Dining Philosophers Deadlock is easily detected in our model.
How easy is it to detect a potential deadlock in an implementation?
Ed Brinksma
FMSE, Lecture 6

12. Deadlock-free Philosophers
Deadlock can be avoided by ensuring that a wait-for cycle cannot exist. How?
PHIL(I=0)
= (when (I%2==0) sitdown
->left.get->right.get
->eat
->left.put->right.put
->arise->PHIL
|when (I%2==1) sitdown
->right.get->left.get ).
Introduce an asymmetry into our definition of philosophers.
Use the identity I of a philosopher to make even numbered philosophers get their left forks first, odd their right first.
Other strategies?
Ed Brinksma
FMSE, Lecture 6

13. Searching by Deadlock Analysis
We can exploit the shortest path trace produced by the deadlock detection mechanism of LTSA to find the shortest path out of a maze to the STOP process! 1 2 3 4 5 6 7 8
STOP
north
south
west
east
MAZE(Start=8) = P[Start],
P[0] = (north->STOP
|east->P[1]),
P[1] = (east->P[2]
|south->P[4]
|west->P[0]),
… .
We must first model the MAZE.
Each position can be modelled by the moves that it permits. The MAZE parameter gives the starting position.
Ed Brinksma
FMSE, Lecture 6

14. Searching by Deadlock Analysis
Shortest path escape trace from position 7 ?
Run deadlock analysis on
process MAZE(7) 1 2 3 4 5 6 7 8
STOP
north
south
west
east
Trace to DEADLOCK:
east
north
west
Ed Brinksma
FMSE, Lecture 6

15. Hippies Problem Germany Holland <= 60 min? POLIZEI 25 10 20 5.. 10 .. 20 .. 5 ..
coffee shop
holes
<= 2 pers
“stoned” hippies
Ed Brinksma
FMSE, Lecture 6

16. Modelling the Hippies range H = 1..4 // range of hippie ids.
GERMANY = SIDE[0],
SIDE[i:0..1] =
(at[i] -> SIDE[i] // at gives side id (0=D,1=NL)
|to[1-i] -> SIDE[1-i]). // to is moving to the other side.
||HIPPIES = (hippie[H]:GERMANY). // all hippies start in D.
Ed Brinksma
FMSE, Lecture 6

17. Modelling the Crossing
BRIDGE =
(to[1] -> to[1] -> to[0] -> BRIDGE). // 2 hippies to NL, 1 back
||CROSSING =
(HIPPIES || hippie[H]::BRIDGE). // hippies sharing bridge
Ed Brinksma
FMSE, Lecture 6

18. Modelling Time Add time to clock according to hippie id.
range T=0..200
CLOCK = CLOCK[0],
CLOCK[t:T] = (time[t] -> CLOCK[t]
|addtime[1] -> CLOCK[t+5]
|addtime[2] -> CLOCK[t+10]
|addtime[3] -> CLOCK[t+20]
|addtime[4] -> CLOCK[t+25] ).
TIME = (hippie[i:H].to[1] -> hippie[j:H].to[1] ->
if i<j then (addtime[j] -> TIME)
else (addtime[i] -> TIME)
|hippie[k:H].to[0] -> addtime[k] -> TIME).
Add time to clock according to hippie id.
Add only time of the most stoned hippie going to NL
Ed Brinksma
FMSE, Lecture 6

19. Testing the Result Test whether all hippies are in NL
TESTOVER = (hippie[i:H].to[1] ->
hippie[j:H].to[1] ->
time[t:T] ->
(hippie[1].at[0] -> AGAIN
|hippie[1].at[1] ->
(hippie[2].at[0] -> AGAIN
|hippie[2].at[1] ->
(hippie[3].at[0] -> AGAIN
|hippie[3].at[1] ->
(hippie[4].at[0] -> AGAIN
|hippie[4].at[1] ->
if t<=60 then STOP
else LATE
) ) ) ) ),
AGAIN = (hippie[i:H].to[0] -> time[t:T] -> TESTOVER),
LATE = (late -> LATE).
Still hippies in D
Loop on loop to avoid a deadlock that is no solution
Ed Brinksma
FMSE, Lecture 6

20. Searching the Solution
||SOLUTION = (CROSSING || TIME || CLOCK || TESTOVER)
<<{addtime[H]}
@{hippie[H].to[0..1],time[T],late}.
Priority operator: gives priority to addtime actions over others if there is a choice. Time must advance.
Ed Brinksma
FMSE, Lecture 6

21. The Solution Trace to DEADLOCK: hippie.1.to.1 hippie.2.to.1 time.10
Ed Brinksma
FMSE, Lecture 6

22. Safety Properties
A safety property asserts that nothing bad happens, i.e. no deadlocked state (e.g. STOP or ERROR) is reachable.
command
respond 1 -1
ACTUATOR
=(command->ACTION),
ACTION
=(respond->ACTUATOR
|command->ERROR).
Trace to ERROR:
command
analysis using LTSA:
(shortest trace)
Ed Brinksma
FMSE, Lecture 6

23. Safety-property Specification
ERROR conditions state what is not required (cf. exceptions).
In complex systems, it is usually better to specify safety properties by stating directly what is required.
command
respond 1 -1
property SAFE_ACTUATOR
= (command
-> respond
-> SAFE_ACTUATOR).
All non-specified traces with actions in {command, respond} lead to ERROR
Analysis using LTSA
as before.
Ed Brinksma
FMSE, Lecture 6

24. Safety properties
Property that it is polite to knock before entering a room.
Traces: knockenter enter
knockknock
property POLITE =
knock
enter -1 1
(knock->enter->POLITE).
In all states, all the actions in the alphabet of a property are eligible choices.
Ed Brinksma
FMSE, Lecture 6

25. Properties and Transparency
A safety property is a process:
With a certain alphabet
Showing what system actions are allowed:
Actions not in the alphabet can freely occur
Actions in the alphabet not occurring at a certain point in the property lead to an ERROR state (-1)
Actions occurring at a certain point in the property are allowed
Transparancy: in order not to affect normal functioning a property should be deterministic!
Ed Brinksma
FMSE, Lecture 6

26. Question
How can we specify that some action, disaster, never occurs?
disaster -1
property CALM = STOP + {disaster}.
Ed Brinksma
FMSE, Lecture 6

27. Single Lane Bridge problem
A bridge over a river is only wide enough to permit a single lane of traffic. Consequently, cars can only move concurrently if they are moving in the same direction. A safety violation occurs if two cars moving in different directions enter the bridge at the same time.
Ed Brinksma
FMSE, Lecture 6

28. Single Lane Bridge - model
Events or actions of interest?
enter and exit
Identify processes.
cars and bridge
Identify properties.
oneway
Define each process and
interactions (structure).
CARS
property
ONEWAY
Single
red[ID].
blue[ID].
{enter,exit}
{enter,exit}
Lane
Bridge
BRIDGE
Ed Brinksma
FMSE, Lecture 6

29. Modelling the Cars const N = 3 // number of each type of car
range T = 0..N // type of car count
range ID= 1..N // car identities
CAR = (enter->exit->CAR).
To model the fact that cars cannot pass each other on the bridge, we model a CONVOY of cars in the same direction. We will have a red and a blue convoy of up to N cars for each direction:
||CARS = (red:CONVOY || blue:CONVOY).
Ed Brinksma
FMSE, Lecture 6

30. Modelling Car Convoys 1 2 NOPASS1 = C[1], //preserves entry order
C[i:ID] = ([i].enter -> C[i%N+1]).
NOPASS2 = C[1], //preserves exit order
C[i:ID] = ([i].exit -> C[i%N+1]).
||CONVOY = ([ID]:CAR||NOPASS1||NOPASS2).
1.enter
2.enter
3.enter 1 2
1.exit
2.exit
3.exit
Permits 1.enter 2.enter 1.exit 2.exit
but not 1.enter 2.enter 2.exit 1.exit
ie. no overtaking.
Ed Brinksma
FMSE, Lecture 6

31. Modelling the Bridge BRIDGE = BRIDGE[0][0], // initially empty
Cars can move concurrently on the bridge only if in the same direction. The bridge maintains counts of blue and red cars on the bridge. Red cars are only allowed to enter when the blue count is zero and vice-versa.
BRIDGE = BRIDGE[0][0], // initially empty
BRIDGE[nr:T][nb:T] = // nr is the red count, nb the blue one (when(nb==0)
red[ID].enter -> BRIDGE[nr+1][nb] //nb==0
| red[ID].exit -> BRIDGE[nr-1][nb]
|when(nr==0)
blue[ID].enter-> BRIDGE[nr][nb+1] //nr==0
| blue[ID].exit -> BRIDGE[nr][nb-1] ).
Even when 0, exit actions permit the car counts to be decremented. LTSA maps these undefined states to ERROR.
Ed Brinksma
FMSE, Lecture 6

32. The Oneway Property property ONEWAY =(red[ID].enter -> RED[1]
We now specify a safety property to check that cars do not collide!
While red cars are on the bridge only red cars can enter; similarly for blue cars. When the bridge is empty, either a red or a blue car may enter.
property ONEWAY =(red[ID].enter -> RED[1]
|blue[ID].enter -> BLUE[1] ),
RED[i:ID] = (red[ID].enter -> RED[i+1]
|when(i==1)red[ID].exit -> ONEWAY
|when(i>1) red[ID].exit -> RED[i-1]
), //i is a count of red cars on the bridge
BLUE[i:ID]= (blue[ID].enter-> BLUE[i+1]
|when(i==1)blue[ID].exit -> ONEWAY
|when( i>1)blue[ID].exit -> BLUE[i-1]
). //i is a count of blue cars on the bridge
Ed Brinksma
FMSE, Lecture 6

33. Single Lane Bridge model analysis
||SingleLaneBridge = (CARS|| BRIDGE||ONEWAY).
Is the safety property ONEWAY violated?
No deadlocks/errors
||SingleLaneBridge = (CARS||ONEWAY).
Without the BRIDGE contraints, is the safety property ONEWAY violated?
Trace to property violation in ONEWAY:
red.1.enter
blue.1.enter
Ed Brinksma
FMSE, Lecture 6