1 / 94

Tools for Automated Verification of Concurrent Software

Tools for Automated Verification of Concurrent Software. Tevfik Bultan Department of Computer Science University of California, Santa Barbara bultan@cs.ucsb.edu http://www.cs.ucsb.edu/~bultan/ http://www.cs.ucsb.edu/~bultan/composite/. Summary. Goal: Reliable concurrent programming

justa
Download Presentation

Tools for Automated Verification of Concurrent Software

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. Tools for Automated Verification of Concurrent Software Tevfik Bultan Department of Computer Science University of California, Santa Barbara bultan@cs.ucsb.edu http://www.cs.ucsb.edu/~bultan/ http://www.cs.ucsb.edu/~bultan/composite/

  2. Summary • Goal: Reliable concurrent programming • Sub-goals: • Developing reliable concurrency controllers in Java • Developing reliable concurrent linked lists • Approach: Model Checking • Refined Approach: Composite Model Checking • Specification Language: Action Language • Tools: • Composite Symbolic Library • Action Language Verifier

  3. Students Joint work with my students: • Tuba Yavuz-Kahveci • Constantinos Bartzis • Xiang Fu (co-advised with Jianwen Su) • Aysu Betin-Can

  4. Outline • Difficulties in concurrent programming • A short history of model checking • 5 key ideas + 2 key tools • Action Language • Composite Symbolic Library • Application to concurrency controllers • Application to concurrent linked lists • Related work • Current and future work

  5. Difficulties in Concurrent Programming • Concurrent programming is difficult and error prone • In sequential programming you only worry about the states of the variables • In concurrent programming you also have to worry about the states of the threads • State space increases exponentially with the number of threads

  6. Concurrent Programming in Java • Java uses a variant of monitor programming • Synchronization using locks • Each object has a lock synchronized(o) { ... } • Coordination using condition variables • Objects can be used as condition variables synchronized (condVar){ while (!condExp) wait(condVar); ... notifyAll(condVar); }

  7. Dangers in Java Concurrency • Nested locks Thread1 Thread2 synchronized m(other) { other.m(); } Thread1: run() { o1.m(o2); } Thread2: run() { o2.m(o1); } o2 o1 lock lock

  8. Dangers in Java Concurrency • Missed notification notify(condVar); • Forgotten condition check if(!condExp) wait(condVar); • Dependency among multiple condition variables can be complicated • Conservative notification and condition check Inefficient • Optimizing the notification and condition checks Error prone

  9. Example: Airport Ground Traffic Control Simulation A simplified model of Seattle Tacoma International Airport from [Zhong 97]

  10. Control Logic • An airplane can land using 16R only if no airplane is using 16R at the moment • An airplane can takeoff using 16L only if no airplane is using 16L at the moment • An airplane taxiing on one of the exits C3-C8 can cross runway 16L only if no airplane is taking off at the moment • An airplane can start using 16L for taking off only if none of the crossing exits C3-C8 is occupied at the moment (arriving airplanes have higher priority) • Only one airplane can use a taxiway at a time

  11. Java Implementation • Simulate behavior of each airplane with a thread • Use a monitor (a Java class) • private variables for number of airplanes on each runway and each taxiway • methods of the monitor enforce the control logic • Each thread calls the methods of the monitor based on the airport layout to move from one point to the next

  12. Example Implementation public synchronized void C8_To_B11A() { while (!((numRW16L == 0) && (numB11A == 0))) wait(); numC8 = numC8 - 1; numB11A = numB11A + 1; notifyAll(); } • This code is not efficient since every thread wakes up every other thread • Using separate condition variables complicates the synchronization • nested locks

  13. Difficulties In Implementing Concurrent Linked Lists • Linked list manipulation is difficult and error prone • State of the heap: unbounded • State space: • Sequential programming • states of the variables • Concurrent programming • states of the variables • states of the threads • Concurrent linked lists • states of the variables • states of the threads • state of the heap

  14. Examples next • singly linked lists • doubly linked lists • stack • queue • single lock • double lock • allows concurrent inserts and deletes n1 n2 next next next prev n1 n2 prev next top n1 n2 next last first n1 n2 next next

  15. Outline of Our Approach • Specify concurrency controllers and concurrent linked lists in Action Language • Verify their properties using composite model checking • Generate Java classes from the specifications which preserve their properties

  16. Action Language Tool Set Action Language Verifier Action Language Specification Action Language Parser Composite Symbolic Library Code Generator Omega Library CUDD Package MONA Presburger Arithmetic Manipulator BDD Manipulator Automata Manipulator Verified code (Java monitor classes)

  17. Outline • Difficulties in concurrent programming • A short history of model checking in 7 slides • 5 key ideas + 2 key tools • Action Language • Composite Symbolic Library • Application to concurrency controllers • Application to concurrent linked lists • Related work • Current and future work

  18. Transformational systems get input; compute something; return result; Reactive systems while (true) { receive some input, send some output } For reactive systems termination is not relevant pre and post-conditions are not enough Temporal Logics Invariant p (G p, AG p, p) Eventually p (F p, AF p, p) Next p : (X p, AX p, p) p Until q : ( p U q, A(p U q) ) Idea 1: Temporal Logics for Reactive Systems[Pnueli FOCS 77, TCS 81] p p Branching vs. Linear Time p LTL CTL G(p) F(p) AF(p), EG(p) p p p p p p p p . . . . . . . . . . . . . . .

  19. Transition Systems S : Set of states (finite) I  S: Set of initial states R  S  S: Transition relation Model checking problem: Given a temporal logic property, does the transition system satisfy the property? Complexity: linear in the size of the transition system Verification vs. Falsification Verification: show: initial states  truth set of p Falsification: find: a state  initial states  truth set of p generate a counter-example starting from that state Idea 2: Automated Verification of Finite State Systems[Clarke and Emerson 81], [Queille and Sifakis 82]

  20. Idea 3: Temporal Properties  Fixpoints [Emerson and Clarke 80] EF(p)states that can reach p  p Pre(p)  Pre(Pre(p))  ... Initial states p • • • EF(p) initial states that satisfy EF(p) initial states that violate AG(p) EG(p) states that can avoid reaching pp Pre(p)  Pre(Pre(p))  ... Initial states • • • EG(p) initial states that satisfy EG(p) initial states that violate AF(p)

  21. Idea 4: Symbolic Model Checking[McMillan et al. LICS 90] • Represent sets of states and the transition relation as Boolean logic formulas • Fixpoint computation becomes formula manipulation • pre and post-condition computations: Existential variable elimination • conjunction (intersection), disjunction (union) and negation (set difference), and equivalence check • Use an efficient data structure • Binary Decision Diagrams (BDDs)

  22. Tool 1: SMV [McMillan 93] • BDD-based symbolic model checker • Finite state • Temporal logic: CTL • Focus: hardware verification • Later applied to software specifications, protocols, etc. • SMV has its own input specification language • concurrency: synchronous, asynchronous • shared variables • boolean and enumerated variables • bounded integer variables (binary encoding) • SMV is not efficient for integers, can be fixed

  23. Idea 5: LTL Properties  Büchi automata [Vardi and Wolper LICS 86] • Büchi automata: Finite state automata that accept infinite strings • A Büchi automaton accepts a string when the corresponding run visits an accepting state infinitely often • The size of the property automaton can be exponential in the size of the LTL formula true p p G p true p p F p true p G (F p) true

  24. Explicit state, finite state Temporal logic: LTL Input language: PROMELA Asynchronous processes Shared variables Message passing through (bounded) communication channels Variables: boolean, char, integer (bounded), arrays (fixed size) Property automaton from the negated LTL property Product of the property automaton and the transition system (on-the-fly) Show that there is no accepting cycle in the product automaton Nested depth first search to look for accepting cycles If there is a cycle, it corresponds to a counterexample behavior that demonstrates the bug Tool 2: SPIN [Holzmann 91, TSE 97]

  25. Model Checking Research • These 5 key ideas and 2 key tools inspired a lot of research [Clarke, Grumberg and Peled, 99] • efficient symbolic representations • partial order reductions • abstraction • compositional/modular verification • model checking infinite state systems (pushdown automata) • model checking real time systems • model checking hybrid systems • model checking programs • ...

  26. Outline • Difficulties in concurrent programming • A short history of model checking • 5 key ideas + 2 key tools • Action Language • Composite Symbolic Library • Application to concurrency controllers • Application to concurrent linked lists • Related work • Current and future work

  27. Action Language[Bultan, ICSE 00], [Bultan, Yavuz-Kahveci, ASE 01] • A state based language • Actions correspond to state changes • States correspond to valuations of variables • boolean • enumerated • integer (possibly unbounded) • heap variables (i.e., pointers) • Parameterized constants • specifications are verified for every possible value of the constant

  28. Action Language • Transition relation is defined using actions • Atomic actions: Predicates on current and next state variables • Action composition: • asynchronous (|) or synchronous (&) • Modular • Modules can have submodules • A modules is defined as asynchronous and/or synchronous compositions of its actions and submodules

  29. module main() integer nr; boolean busy; restrict: nr>=0; initial: nr=0 and !busy; module Reader() boolean reading; initial: !reading; rEnter: !reading and !busy and nr’=nr+1 and reading’; rExit: reading and !reading’ and nr’=nr-1; Reader: rEnter | rExit; endmodule module Writer() ... endmodule main: Reader() | Reader() | Writer() | Writer(); spec: invariant([busy => nr=0]) endmodule Readers Writers Example S :Cartesian product of variable domains defines the set of states I : Predicates defining the initial states R : Atomic actions of the Reader R : Transition relation of Reader defined as asynchronous composition of its atomic actions R : Transition relation of main defined as asynchronous composition of two Reader and two Writer processes

  30. Outline • Difficulties in concurrent programming • A short history of model checking • 5 key ideas + 2 key tools • Action Language • Composite Symbolic Library • Application to concurrency controllers • Application to concurrent linked lists • Related work • Current and future work

  31. BDDs canonical and efficient representation for Boolean logic formulas can only encode finite sets Linear Arithmetic Constraints can encode infinite sets two representations polyhedral representation automata representation not efficient for encoding boolean domains Which Symbolic Representation to Use? x  y  {(T,T), (T,F), (F,T)} x F a > 0  b = a+1 T y  {(1,2), (2,3), (3,4),...} F T F T

  32. Composite Model Checking[Bultan, Gerber, League ISSTA 98, TOSEM 00] • Map each variable type to a symbolic representation • Map boolean and enumerated types to BDD representation • Map integer type to a linear arithmetic constraint representation • Use a disjunctive representation to combine different symbolic representations: composite representation • Each disjunct is a conjunction of formulas represented by different symbolic representations • we call each disjunct a composite atom

  33. Composite Representation composite atom symbolic rep. 1 symbolic rep. 2 symbolic rep. t Example: x: integer, y: boolean x>0 and x´x-1andy´orx<=0 and x´xandy´y arithmetic constraint representation arithmetic constraint representation BDD BDD

  34. Composite Symbolic Library[Yavuz-Kahveci, Tuncer, Bultan TACAS01], [Yavuz-Kahveci, Bultan STTT] • Uses a common interface for each symbolic representation • Easy to extend with new symbolic representations • Enables polymorphic verification • Multiple symbolic representations: • As a BDD library we use Colorado University Decision Diagram Package (CUDD) [Somenzi et al] • As an integer constraint manipulator we use Omega Library [Pugh et al]

  35. Composite Symbolic Library Class Diagram BoolSym CompSym IntSym –representation: BDD –representation: Polyhedra –representation: list of comAtom +intersect() +union() • • • +intersect() +union() • • • +intersect() + union() • • • compAtom –atom: *Symbolic Symbolic +intersect() +union() +complement() +isSatisfiable() +isSubset() +pre() +post() CUDD Library OMEGA Library

  36. Composite Symbolic Representation x: integer, y:boolean x>0 and x´x-1andy´orx<=0 and x´xandy´y : CompSym representation : List<compAtom> : ListNode<compAtom> : ListNode<compAtom> data : compAtom data : compAtom 0 y´ b’ 0 y’=y 1 x>0 and x´=x-1 1 x<=0 and x’=x next :*ListNode<compAtom> next: *ListNode<compAtom>

  37. Pre and Post-condition Computation Variables: x: integer, y: boolean Transition relation: R:x>0 and x´x-1andy´orx<=0 and x´xandy´y Set of states: s:x=2and!yorx=0and!y Compute post(s,R)

  38. Pre and Post-condition Distribute R:x>0 and x´x-1andy´orx<=0 and x´xandy´y s:x=2and!yorx=0andy post(s,R) =post(x=2 , x>0 and x´x-1)  post(!y , y´) x=1 y • post(x=2 , x<=0 and x´x)  post (!y , y´y) false!y • post(x=0 , x>0 and x´x-1)  post(y , y´) falsey • post (x=0 , x<=0 and x´x)  post (y, y´y ) x=0y =x=1andy orx=0andy

  39. Polymorphic Verifier SymbolicTranSys::check(Node *f) { • • • Symbolics = check(f.left) caseEX: s.pre(transRelation) caseEF: do sold = s s.pre(transRelation) s.union(sold) while not sold.isEqual(s) • • • }  Action Language Verifier is polymorphic  It becomes a BDD based model checker when there or no integer variables

  40. Heuristics for Composite Representation[Yavuz-Kahveci, Bultan FroCos 02] • Masking • compute operations on BDDs first • avoid redundant computations on integer part • Incremental subset check • Exploit the disjunctive structure by computing subset checks incrementally • Interleaving pre-condition computation with the subset check in least-fixpoint computations • Simplification • Reduce the number of disjuncts in the composite representation by iteratively merging matching disjuncts

  41. Some Experiments Without the simplification for 15 out of 39 problem instances the verifier ran out of memory

  42. Outline • Difficulties in concurrent programming • A short history of model checking • 5 key ideas + 2 key tools • Action Language • Composite Symbolic Library • Application to concurrency controllers • Application to concurrent linked lists • Related work • Current and future work

  43. Application to Concurrency Controllers[Yavuz-Kahveci, Bultan ISTTA 02] [Betin-Can, Bultan SoftMC 03] Outline of our approach: • Specify concurrency controllers and concurrent linked lists in Action Language • Verify their properties using composite model checking • Generate Java classes from the specifications which preserve their properties

  44. module main() integer nr; boolean busy; restrict: nr>=0; initial: nr=0 and !busy; module Reader() boolean reading; initial: !reading; rEnter: !reading and !busy and nr’=nr+1 and reading’; rExit: reading and !reading’ and nr’=nr-1; Reader: rEnter | rExit; endmodule module Writer() boolean writing; initial: !writing; wEnter: !writing and nr=0 and !busy and busy’ and writing’; wExit: writing and !writing’ and !busy’; Writer: wEnter | wExit; endmodule main: Reader() | Reader() | Writer() | Writer(); spec: invariant([busy => nr=0]) endmodule Readers-Writers Controller

  45. Arbitrary Number of Threads • Counting abstraction • Create an integer variable for each local state of a thread • Each variable will count the number of threads in a particular state • Local states of the threads have to be finite • Specify only the thread behavior that relates to the correctness of the controller • Shared variables of the controller can be unbounded • Counting abstraction can be automated

  46. module main() integer nr; boolean busy; parameterized integer numReader, numWriter; restrict: nr>=0 and numReader>=0 and numWriter>=0; initial: nr=0 and !busy; module Reader() integer readingF, readingT; initial: readingF=numReader and readingT=0; rEnter: readingF>0 and !busy and nr’=nr+1 and readingF’=readingF-1 and readingT’=readingT+1; rExit: readingT>0 and nr’=nr-1 readingT’=readingT-1 and readingF’=readingF+1; Reader: rEnter | rExit; endmodule module Writer() ... endmodule main: Reader() | Writer(); spec: invariant([busy => nr=0]) endmodule Readers-Writers After Counting Abstraction Parameterized constants introduced by the counting abstractions Variables introduced by the counting abstractions

  47. Verification of Readers-Writers Controller SUN ULTRA 10 (768 Mbyte main memory)

  48. What about the Java Implementation? • We can automatically generate code from the controller specification • Generate a Java class • Make shared variables private variables • Use synchronization to restrict access • Is the generated code efficient? • Yes! • We can synthesize the condition variables automatically • There is no unnecessary thread notification

  49. public class ReadersWriters{ private int nr; private boolean busy; private Object rEnterCond, wEnterCond; private synchronized boolean Guard_rEnter() { if (!busy) { nr++; return true; } else return false; } public void rEnter() { synchronized(rEnterCond) { while(!Guard_rEnter()) rEnterCond.wait(); } public void rExit() { synchronized(this) { nr--; } synchronized(wEnterCond) { wEnterCond.notify(); } } ... } Specific Notification Pattern[Cargill 96] All condition variables and wait and signal operations are generated automatically rEnter: !reading and !busy and nr’=nr+1 and reading’;

  50. Example: Airport Ground Traffic Control A simplified model of Seattle Tacoma International Airport from [Zhong 97]

More Related