1 / 33

Formal Methods for Software Engineering

Formal Methods for Software Engineering. Lecture 6, Part II: Deadlock & Safety Analysis. Contents. Deadlock analysis Distributed deadlocks Dining philosophers Searching by deadlock analysis Safety analysis Safety properties Single-lane bridge problem. Deadlock state. north. north.

reina
Télécharger la présentation

Formal Methods for Software Engineering

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

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

  4. SYS p:P printer: RESOURCE printer get scanner put q:Q scanner: printer RESOURCE get scanner put Distributed Deadlock Deadlock 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). Deadlock Trace? Avoidance? FMSE, Lecture 6

  5. A E B C D Wait-for Cycle Has A awaits B Has E awaits A Has B awaits C Has C awaits D Has D awaits E 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? FMSE, Lecture 6

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

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

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

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

  13. Searching by Deadlock Analysis STOP north 0 1 2 west east 3 4 5 south 7 8 6 We can exploit the shortest path trace produced by the deadlock detection mechanism of LTSA to find the shortestpath out of a maze to the STOP process! 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. FMSE, Lecture 6

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

  15. .. .. .. .. holes POLIZEI coffeeshop 5 25 20 10 <=2 pers Hippies Problem Germany Holland <= 60 min? “stoned” hippies 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. 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 FMSE, Lecture 6

  18. Modelling Time 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 least stoned hippie going to NL 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 FMSE, Lecture 6

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

  21. 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 FMSE, Lecture 6

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

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

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

  25. Transparency • SafetypropertyP 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. FMSE, Lecture 6

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

  30. 1.enter 2.enter 1.exit 2.exit 0 1 2 0 1 2 3.enter 3.exit Modelling Car Convoys 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). Permits 1.enter 2.enter 1.exit 2.exit but not1.enter 2.enter 2.exit 1.exit ie. no overtaking. FMSE, Lecture 6

  31. 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, nbthe 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. FMSE, Lecture 6

  32. 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 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 FMSE, Lecture 6

More Related