Formal Methods for Software Engineering

Formal Methods for

Software Engineering

Lecture 6, Part II: Deadlock & Safety Analysis

Ed Brinksma FMSE, Lecture 6

Contents Deadlock analysis

Distributed deadlocks Dining philosophers Searching by deadlock analysis

Safety analysis Safety properties Single-lane bridge problem


Basic DeadlockA deadlock state is a state with no outgoing transitionsIn FSP such states can be directly represented as a STOP process

Trace to DEADLOCK:

northnorth

We can use LTSA to find the shortest trace to such deadlock states.

MOVE = (north-> (south->MOVE |north->STOP)).

MOVE north north

south0 1 2

Deadlock state


Distributed DeadlockDeadlock may arise from the parallel composition of processes without deadlock states.

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).

printer:RESOURCEgetput

SYS

scanner:RESOURCEgetput

p:Pprinter

scanner

q:Qprinter

scanner

Deadlock Trace? Avoidance?


Wait-for Cycle

A

B

CD

E

Has A awaits B

Has B awaits C

Has C awaits DHas D awaits E

Has E awaits A


Deadlock Avoidance1. acquire resources in the same order,

or2. 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?


Dining PhilosophersFive 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.

0

1

23

40

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.


Model Structure Diagram

phil[4]:PHIL

phil[1]:PHIL

phil[3]:PHIL

phil[0]:PHIL

phil[2]:PHIL

FORK FORK

FORK

FORK FORK

leftright

right

right

right

left

left

right

left

left

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.


The FSP Model

FORK = (get -> put -> FORK).PHIL = (sitdown -> right.get -> left.get

-> eat -> right.put -> left.put -> arise -> PHIL).

Can this system deadlock?

Table of philosophers:||DINERS(N=5)= forall [i:0..N-1] (phil[i]:PHIL || {phil[i].left,phil[((i-1)+N)%N].right}::FORK ).


Dining Philosophers AnalysisTrace to DEADLOCK: phil.0.sitdown

phil.0.right.getphil.1.sitdownphil.1.right.getphil.2.sitdownphil.2.right.getphil.3.sitdownphil.3.right.getphil.4.sitdownphil.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!


Dining Philosophers

Deadlock is easily detected in our model. How easy is it to detect a potential deadlock in an implementation?


Deadlock-free PhilosophersDeadlock 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 ->eat

->left.put->right.put->arise->PHIL

).

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?


0 1 2

3 4 5

6 7 8

STOP

north

south

west east

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!

We must first model the MAZE. Each position can be modelled by the moves that it permits. The MAZE parameter gives the starting position.

MAZE(Start=8) = P[Start], P[0] = (north->STOP |east->P[1]), P[1] = (east->P[2] |south->P[4] |west->P[0]), … .

Searching by Deadlock Analysis


0 1 2

3 4 5

6 7 8

STOP

north

south

west east

Searching by Deadlock Analysis

Shortest path escape trace from position

7 ?

Run deadlock analysis onprocess MAZE(7)

Trace to DEADLOCK:

eastnorthnorthwestwestnorth


Hippies Problem

Germany

Holland

<=2 pers

<= 60 min?

holes

5

.

.

10

.

.

20

.

.

25

.

. coffeeshop

“stoned” hippies


Modelling the Hippiesrange 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.


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


Modelling Timerange 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 least

stoned hippie going to NL


Testing the ResultTESTOVER = (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).

Test whether all hippies are in NL

Still hippies in D

Loop on loop to avoid a deadlock that is no solution


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.


The SolutionTrace to DEADLOCK:

hippie.1.to.1hippie.2.to.1time.10hippie.1.to.0time.15hippie.3.to.1hippie.4.to.1time.40hippie.2.to.0time.50hippie.1.to.1hippie.2.to.1time.60


Safety Properties

ACTUATOR =(command->ACTION),ACTION =(respond->ACTUATOR |command->ERROR).

Trace to ERROR:commandcommand

analysis using LTSA:(shortest trace)

A safety property asserts that nothing bad happens, i.e. no deadlocked state (e.g. STOP or ERROR) is reachable.

command

command

respond

0 1-1respond


Safety-property SpecificationERROR 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.

property SAFE_ACTUATOR = (command -> respond -> SAFE_ACTUATOR).

Analysis using LTSA as before.

command

command

respond

-1 0 1

All non-specified traces with actions in {command, respond}

lead to ERROR


Safety properties

property POLITE =

Property that it is polite to knock before entering a room.Traces: knockenter enter

knockknock

(knock->enter->POLITE).

In all states, all the actions in the alphabet of a property are eligible choices.

knock

enter

knock

enter

-1 0 1


TransparencySafety property P defines a deterministic process that asserts that any trace including actions in the alphabet of P, is accepted by P.

Thus, if P is composed with S, then traces of actions in the alphabet of S alphabet of P must also be valid traces of P, otherwise ERROR is reachable.

Transparency of safety properties: Since all actions in the alphabet of a property are eligible choices, composing a property with a set of processes does not affect their correct behaviour. However, if a behaviour can occur which violates the safety property, then ERROR is reachable. Properties must be deterministic to be transparent.


QuestionHow can we specify that some action, disaster, never occurs?

property CALM = STOP + {disaster}.

disaster

-1 0


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.


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).

red[ID].{enter,exit}

blue[ID].{enter,exit}

BRIDGE

propertyONEWAY

CARS

SingleLaneBridge


Modelling the Carsconst N = 3 // number of each type of carrange T = 0..N // type of car countrange 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).


Modelling Car ConvoysNOPASS1 = C[1], //preserves entry orderC[i:ID] = ([i].enter -> C[i%N+1]).NOPASS2 = C[1], //preserves exit orderC[i:ID] = ([i].exit -> C[i%N+1]).

||CONVOY = ([ID]:CAR||NOPASS1||NOPASS2).

Permits 1.enter 2.enter 1.exit 2.exitbut not 1.enter 2.enter 2.exit 1.exit

ie. no overtaking.

1.enter 2.enter

3.enter

0 1 21.exit 2.exit

3.exit

0 1 2


Modelling the Bridge

BRIDGE = BRIDGE[0][0], // initially emptyBRIDGE[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]

).

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 red count is zero and vice-versa.

Even when 0, exit actions permit the car counts to be decremented. LTSA maps these undefined states to ERROR.


The Oneway Property

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

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.


Single Lane Bridge model analysis

Is the safety property ONEWAY violated?

||SingleLaneBridge = (CARS|| BRIDGE||ONEWAY).

No deadlocks/errors

Trace to property violation in ONEWAY:

red.1.enterblue.1.enter

Without the BRIDGE contraints, is the safety property ONEWAY violated?

||SingleLaneBridge = (CARS||ONEWAY).

Date post:	13-Feb-2016
Category:	Documents
Upload:	reina
View:	32 times
Download:	5 times

Formal Methods for Software Engineering

Documents