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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Question How can we specify that some action, disaster, never occurs? disaster -1 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). CARS property ONEWAY Single red[ID]. blue[ID]. {enter,exit} {enter,exit} Lane Bridge BRIDGE Ed Brinksma FMSE, Lecture 6

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

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

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

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

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