Formal Methods for Software Engineering Lecture 6 Part

Formal Methods for Software Engineering Lecture 6, Part II: Deadlock & Safety Analysis Ed Brinksma FMSE, Lecture 6

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

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

Distributed Deadlock may arise from the parallel composition of processes without deadlock states. SYS p: P printer scanner q: Q printer scanner RESOURCE = (get->put->RESOURCE). printer: RESOURCE get put scanner: RESOURCE get put 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? Ed Brinksma Avoidance? FMSE, Lecture 6

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

Deadlock Avoidance 1. acquire resources in the same order, or 2. 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

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. 3 FMSE, Lecture 6 1 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 2 2 1 4 0 0

Model Structure Diagram 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 FORK right phil[0]: PHIL left right left phil[4]: PHIL phil[1]: PHIL left right FORK right left phil[2]: PHIL FMSE, Lecture 6 FORK right FORK left phil[3]: PHIL

The FSP Model 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

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 Ed Brinksma 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! FMSE, Lecture 6

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

Deadlock-free Philosophers Deadlock can be avoided by ensuring that a wait-for cycle cannot exist. How? 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 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 ). FMSE, Lecture 6

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! STOP 0 1 2 3 4 5 6 7 8 Ed Brinksma MAZE(Start=8) = P[Start], We must first model the MAZE. P[0] = (north->STOP north |east->P[1]), Each position can be modelled by the P[1] = (east->P[2] west east moves that it permits. |south->P[4] The MAZE parameter south |west->P[0]), starting gives the …. position. FMSE, Lecture 6

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

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

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

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

Modelling Time range T=0. . 200 CLOCK = CLOCK[0], CLOCK[t: T] = (time[t] -> CLOCK[t] Add time to clock according to hippie id. |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 TIME) else (addtime[i] -> TIME) |hippie[k: H]. to[0] -> addtime[k] -> TIME). Ed Brinksma FMSE, Lecture 6 Add only time of the least stoned hippie going to NL

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] -> Still hippies (hippie[4]. at[0] -> AGAIN in D |hippie[4]. at[1] -> if t<=60 then STOP else LATE ) ) ), AGAIN = (hippie[i: H]. to[0] -> time[t: T] -> TESTOVER), LATE = (late -> LATE). Loop on loop to avoid a deadlock that is no solution Ed Brinksma FMSE, Lecture 6

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

The Solution Trace to DEADLOCK: hippie. 1. to. 1 hippie. 2. to. 1 time. 10 hippie. 1. to. 0 time. 15 hippie. 3. to. 1 hippie. 4. to. 1 time. 40 hippie. 2. to. 0 time. 50 hippie. 1. to. 1 hippie. 2. to. 1 time. 60 Ed Brinksma FMSE, Lecture 6

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

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 -1 0 1 respond property SAFE_ACTUATOR = (command -> respond -> SAFE_ACTUATOR). command Analysis using LTSA as before. Ed Brinksma All non-specified traces with actions in {command, respond} lead to ERROR FMSE, Lecture 6

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

Transparency Safety 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. Ed Brinksma FMSE, Lecture 6

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

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

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). Ed Brinksma property ONEWAY CARS Single Lane Bridge FMSE, Lecture 6 red[ID]. {enter, exit} blue[ID]. {enter, exit} BRIDGE

Modelling the Cars const N = 3 range T = 0. . N range ID= 1. . N // number of each type of car // type of car count // 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

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

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

The Oneway Property 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

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