The Rest of the Course More DFA and Model Checking

Transcription

1 The Rest of the Course More DFA and Model Checking Tuesday, Dec. 6: Guest Lecture Thursday, Dec. 8: Guest Lecture Final Exam Wednesday, Dec. 10:30-12:30 Prof. Leon Osterweil CS Fall Semester 2011 High- Level Architecture of FSV Systems System" System! Translator" System Model" Proerty" Proerty! Translator! Proerty Reresentation Reasoning Engine! Proerty Verified" Counter Examles for Model" System Model Deends on roerty being verified Eliminate informawon that does not imact the reasoning To kee the model as small as ossible AbstracWon techniues allow states in the model to be reduced/collased Only kee track of the variables that are imortant to the roerty Use slicing Abstract values whenever ossible x<0, x=0, x>0 But add in informawon when needed to imrove the recision of the reasoning Alhabet Refinement: Model reducwon based on relevant events foo foo bar Can remove a node from the grah if it does not have an event associated with it, AND does not affect the flow of events through the grah foo foo bar Results in ConservaWve Analysis If roerty verified, roerty holds for all ossible execuwons of the system If roerty not verified: An error found (in the system or in the roerty) OR A surious result System model abstracts informawon to be tractable ConservaWve abstracwons usually over- aroximate behavior If inconsistency relies uon over- aroximawons, then a surious result e.g. every counterexamle corresonds to an infeasible ath Page 1

2 Recall our Previous Examle Produced this Result 1: if 1 2: oen 3: if 3 5: move 3 With this Surious Defect 2: oen 1: if How to address these kinds of roblems abributable to Lack of recision? 3: if 5: move Imroving Precision Imroving Precision Use constraints to imrove recision Given a CFG G, a roerty P, Add constraints C 1,,C n that can be used to avoid roagawon down infeasible aths Then use DFA to determine whether (L(G) L(C 1 ) L(C n )) L(P) Alhabet refine G wrt (Σ P Σ C1 Σ Cn ) System" Proerty FSA Trace Flow Grah" System! Translator" Proerty" Secification" Proerty! Translator! State Proagation! Constraints"..." Proerty Verified" Counter Examle Trace through TFG" Page 2

3 System" Imroving Precision Proerty FSA Trace Flow Grah" System! Translator" Proerty" Secification" Proerty! Translator! State Proagation! Constraints" Can add constraints incrementally as needed..." Proerty Verified" Counter Examle Trace through TFG" Constraints Are reresented as FSAs Describe condiwons necessary for feasible execuwon Have a secial viola&on state that is entered when an infeasible ath is detected ViolaWon is a tra state; once it is entered, never leave that state Boolean Variable Constraint Boolean Variable Constraint t v How do constraints affect the data flow euawons IN and OUT are now sets of tules of FSA states Merge is swll union Transfer funcwon now has to look at each FSA state in the in- tule when comuwng the out- tule Proerty states not roagated when any constraint automaton is in the violawon state Result looks at aths that are feasible with resect to the constraints The roerty state is the same as before Every constraint must be in an accewng state Elevator Revisited 1: if 2: S==t 4: S==f Page 3

4 State ProagaWon State ProagaWon 1: if 4: S==f 5: if 6: S==t State ProagaWon 1 State ProagaWon 1 t f t f State ProagaWon 1 Model Checking: An AlternaWve to DFA t f ProerWes usually exressed in a temoral logic System reresented as a (ossibly abstracted ) reachability grah State based=>show the values of all the relevant variables Reasoning engine roagates valid subformulas through the grah Page 4

5 DFA Aroach Model Checking Aroach Proerty" Proerty" System" System! Translator" Flowgrah System Model" Proerty! Translator! Proerty Reresentation Reasoning Engine! Finite State Machine Or Quantified Regular Ex. Proerty Verified" System" System! Translator" Reachability Grah System Model" Proerty! Translator! Proerty Reresentation Reasoning Engine! Temoral Logic Secification Proerty Verified" Counter Examles for Model" Counter Examles for Model" Reachability- based Model Checking: some history Originally roosed for hardware Early 80 s: E. Clarke and Emerson; Quielle and Sifakis Late 80 s: Imroved algorithms and roerty notawons (E. Clarke, Emerson, Sistla) 90 s: Symbolic Model Checking (SMV) and other owmizawons (Burch, E. Clarke, Dill, Long, and McMillan) Current: Hybrid aroaches that combine model checking with Theorem roving techniues Symbolic execuwon OWmizaWon techniues (e.g., oints to analysis) A Biased View Model Checking starts by building a very large reresentawon, then reduces it in size DFA starts with a small reresentawon, then grows it larger as needed DFA is an older aroach overtaken by Model Checking To be fair model checking research has led to much smaller reresentawons The two aroaches are now uite similar But MODEL CHECKING is the term you will hear used in racwce The Reachability Grah Models enwre rogram state sace Each node reresents a ossible state in a system States reresent the values of all the variables, including the rogram counter and other relevant state informawon (can be uite sizeable, esecially for concurrent systems) Each edge reresents rogress down an execuwon ath Only contains states that are oten&ally reachable from the start state Reachability Grah Examle task control flow grahs T1 T2 b1 e1 T2.Q end b2 e2 Accet Q end waiting for? Need to distinguish before a rendezvous from after a rendezvous Reachability grah,b2 e1, b1,b2, e1,e2 b1,,e2 Page 5

6 Reachability Grah Examle (clarified) task control flow grahs T1 T2 b1 e1 T2.Q end b2 e2 Accet Q end Reachability grah b_,b2 b1,b2 r(, ) b1,b_ Temoral Logic Path uanwfiers A, E Temoral uanwfiers Assume, are atomic roosiwons G - is globally true or always true F - holds somewme in the future or eventually X- holds in the next state U - holds unwl holds R - is released from being true if is true b_ means that a task is blocked at e1,,e2 r(, ) means that the rendezvous between and occurs e1,e2 Examles of Temoral ProosiWons That are True at the Root AG EG A(U) More Examles E(U) AF EF AX EX A(R), More examles R - is released from being true if is true ( is not reuired to become true) E(R) More Familiar Examles The variable defined here is eventually subseuently used It is globally true that door is closed on moving elevator If the elevator stos, the next event is always oen If a file is oened then it is always eventually closed Page 6

7 ProagaWng ProosiWons: AX and EX X - in the next state, is true ProagaWng ProosiWons: AF F - at some time in the future, is true Consider AX AX Consider EX EX EX AF AF AF AF To roagate AF : Mark nodes where is true with AF If all of a node s successors are marked with AF, mark that node Reeat Ste 2 until a fixed oint is reached Only need to look at the successors of the node of interest ProagaWng ProosiWons: EF F - at some time in the future, is true EF EF EF EF EF EF To roagate EF : Mark nodes where is true with EF If at least one of a node s successors are marked with EF, mark that node Reeat Ste 2 until a fixed oint is reached ProagaWon rules Different rule for each formula tye A roerty is true for a grah if it holds in the iniwal node(s) Need a reachability grah that shows the states (i.e., the values) of the relevant variables Examle: rocess 1 can be null, trying to obtain the lock, or in its criwcal region (n1, t1, c1) rocess 2 can be null, trying to obtain the lock, or in its criwcal region (n2, t2, c2) turn is a variable that indicates which rocess can obtain the lock (0,1,2) Power and Value of These Aroaches as Best Seen when Alied to Concurrent Systems Concurrent sooware is much harder, more comlicated Reuires very owerful analysis Model checking and DFA shine in this domain Concurrency fine grain Parallelism usually suorted by secial urose mulwrocessors massive arallelism ooen have shared memory secial urose languages- - Parallel FORTRAN Concurrent systems usually imlemented in a rogramming language that rovides constructs for synchronizawon and shared data (e.g., Ada, Java monitors) could be imlemented on a single rocessor or mulwle rocessors Distributed systems autonomous rocessors that do not share memory usually suorted by oerawng system commands RPC, RMI, message assing, event based nowficawon, etc. coarse grain tightly couled loosely couled Page 7

8 Why use concurrency? To imrove erformance because comutawon can occur in arallel N rocesses does not result in an N fold imrovement To rocess informawon concurrently Process different streams of informawon as each arrives To imrove availability No single oint of failure redundancy To increase flexibility Loose interacwon models allow different rocesses to be added and modified with minimal intrusion Shared data monitors InteracWon models TransacWons Remote rocedure call Rendezvous Message assing asynchronous and synchronous oint- to- oint, broadcast, mulwcast Event- based nowficawon/ublish- subscribe Monitor TransacWon model Process i 1 rocess at a time monitor Process j Start transacwon(s) Decide to commit transacwon or throw out results TransacWons aear to be atomic acwons- - all or nothing TransacWons are ooen used in data bases for very short comutawons E.g. udate saving account informawon Call foo. remote rocedure call foo return Task T1 is Task T2 is T2.A; rendezvous accet A; end T1; end T2; Rendezvous model Page 8

9 Non- determinism Select among waiting tasks non-deterministically Message assing P1 P2 select when NOT_FULL accet Put(C: inchar); end; or when NOT_EMPTY accet Get(C: out char); end; end select; if both guards are true, nondeterministically select a rendezvous send (2, info)... receive (1, info)... Asynchronous: P1 conwnues without waiwng for an acknowledgement P2 may block waiwng for a message from P1 P1 send (2, info)... Message assing ack P2 receive (1, info)... Synchronous- P1 waits for an acknowledgement (and erhas data) before conwnuing P1 may block waiwng for an ack P2 may block waiwng for a message from P1 Event based nowficawon/imlicit invocawon Sender does not indicate actual receivers Receivers register their interest in being nowfied about events Provides very loose couling between senders and receivers Registered for a, b, e Event e Registered for a, b, c Registered for e Point- to- Point, MulWcast, Broadcast Rendezvous Remote rocedure call Message assing Event based nowficawon Monitors Point- to- oint Point- to- oint Point- to- oint, MulWcast MulWcast Point- to- oint Concurrent systems are comlex Non- determinism means that the same inuts might roduce different oututs on different execuwons When reasoning about a system there are numerous alternawves to consider Usually more than a human can reasonably consider In addiwon to the roblems that can arise with seuenwal rograms, have roblems that are uniue to concurrent systems Data access roblems SynchronizaWon roblems Page 9

10 Data Access Anomalies Tyically you want mutual exclusion shared resource (e.g., data) that should only have a single access at a Wme e.g., don t want two travel agents assigning the last seat on a lane Tyically you don t want race condiwons order of execuwon affects results undesirable nondeterminism task A!!task B! x := x + 1; write x;!!x := x - 1;!!write x;! if initially x =5, then could outut (6, 5), (4, 5), or (5, 5) Interleaved Model of ExecuWon; Examles task A! x := x + 1;! write x;!! task B! x := x - 1;! write x;! task B x := x - 1; task A x := x + 1; write x;!! write x;! task B! x := x - 1;! write x;! task A x := x + 1; write x;!! task A! task B! x := x + 1;! x := x - 1;! write x;!! write x;! SynchronizaWon Problems: Infinite wait anomalies StarvaWon At least one task does not make rogress on abaining a goal May conwnue to execute reeat select when not_ready or clean- u; when ready accet Goal; end select; unwl forever; Infinite wait anomalies (conwnued) Deadlock set of tasks mutually waiwng on each other; none can advance Ooen tasks hold resources that other tasks need Also called, deadly embrace dining hilosohers roblem Livelock execuwon does not come to a standswll but none of the tasks can advance Deadlock handling has been inveswgated extensively Deadlock revenwon techniues reassign all resources before ning a task if all resources are not available, then assign none less efficient use of resources since not all may be needed at once reemt a rocess that holds a needed resource But, not all resources can be reemted Deadlock (conwnued) deadlock avoidance only allocate a resource if there is a deadlock free ath through the system hard to determine deadlock free aths must maintain global resource informawon not freuently used because cost is so high deadlock detecwon use stawc analysis techniues to determine if there is a otenwal resource allocawon cycle may be comutawonally exensive and may return surious results Page 10

11 Analyzing concurrent systems Dynamic analysis StaWc analysis Dynamic analysis ReeaWng an execuwon with the same test cases may roduce different values execuwon order may deend on system load, Wme of day, rocessors selected for execuwon, etc. much harder to do debugging much harder to do regression teswng task A!!task B! x := x +1;!x := x - 1;! write x!!write x! Dynamic analysis aroaches for concurrent systems Monitor and relay Coverage criteria SecificaWon based result evaluawon Monitor and relay Monitor execuwon Provide an execuwon harness so that exactly the same decisions can be made on subseuent execuwons Try to minimize number of robes to reduce overhead Monitoring and forcing decisions somewmes erturbs rogram behavior Coverage criteria Coverage criteria All aths taking concurrency into account Exlodes: Must consider each interleaving All synchronizawons Execute each synch statement Included with all stmt coverage Execute each send with at least one receive Similar to all- defs Execute each send and receive air Similar to all- uses Extend deendence analysis to include synchronizawon control deendence informawon 1 T2.Q! 2 T2.Q! 3 end 4! 5 6 Accet Q! 7 end! 9 8 Accet Q! Page 11

12 Event- based monitoring Insert robes and monitor event seuences Comare event seuence to a secificawon of desired behavior (sec- based teswng) ush o o not_emty -o Imlied violation state SecificaWon- based teswng Event- based nowficawon makes monitoring relawvely easy Disatcher must send all events that occur in the roerty secificawon to the secificawon checker Other interacwon models usually reuire inserwng robes into the tasks or into the runwme system SecificaWon based monitoring SecificaWon based monitoring Secification violations Secification Disatcher Disatcher Sec checker NotaWons for secifying concurrent behavior QuanWfied Regular Exressions DeterminisWc Finite- State Automata Temoral Logics StaWc analysis Concurrent & distributed systems are inherently more difficult to analyze Alias resoluwon in addiwon to array references and ointers, can have dynamically allocated tasks e.g., Accet T.i Path feasibility inconsistent ath condiwons infeasible synchronizawon a" a " a" a " Page 12

13 StaWc analysis aroaches for concurrent systems SecificaWon aroaches QuanWfied regular exressions DeterminisWc Finite State Automata Temoral logics - - an extension to classical logic that suorts statements about seuences and Wme Reachability grahs and reachability analysis Petri nets and Petri net based analysis Finite- State VerificaWon Data- flow analysis Extended to distributed systems Model checking Flow euawons reresent necessary condiwons for all or some rogram execuwons Page 13