Monday October 18, 2010 Jeremy Green

1. Parameterization as Abstraction: A Tractable Approach to the Dataflow Analysis of Concurrent Programs- VineetKahlon Monday October 18, 2010 Jeremy Green

2. Outline • Problem Statement / Motivation • System Model and Definitions • UndecidabilityResults • Procedure for Analyzing a Parameterized System • Model Checking • Conclusions

3. Parameterization and Claim • Pairwise reachability of two threads is undecidablewith constraints of most synchronization primitives • Parameterization: parameter , for copies of a some template thread • Claim: If you increase the number of copies of interacting threads to some arbitrary number, the problem becomes efficiently decidable

4. Motivation • Model Checking is an effective technique for analyzing sequential programs. • Can model checking be used for Concurrent Programs? • Example: Detecting data race bug • For our group: Can we use this technique(or similar variant) for analyzing distributed algorithms? • For example, can we use model checking to verify safety properties of a distributed algorithm? • Processes in distributed algorithms are inherently parameterized

5. System Model & Pushdown systems (PDS) • Systems of form: • copies of template thread • For rest of discussion will only consider system with single template thread that has copies • Many distributed algorithms implemented this way • modeled as a Pushdown System: a 5-tuple

6. Synchronization Primitives • PDSs communicate via shared variables and synchronize with following primitives: 1. Locks 2. Rendezvous (Wait, notify) • Pairwise: synchronous • ! Send • ? Receive • Asynchronous: non-blocking • ↑ Send • ↓ Receive 3. Broadcast

7. c! b! b? a? a! c?

8. Reachability • Pairwise Reachability: Are two control locations for two threads simultaneously reachable? • Parameterized Reachable: For a control state c with template process , global state s of , for some n with a process in control state c • Parameterized Pairwise Reachability: Consider two threads P1 , P2 with control states c1 , c2 respectively

9. LTL and the Parameterized Model Checking Problem (PMCP) • LTL naming convention: • F – “eventually” • U – “until” • G – “always” • X – “next” • With boolean connectives: • For finitely many PDSs and temporal property , the PMCP is to decide whether: For , where is a double-indexed LTL \ X formula

10. Undecidability Barriers • L(F, G) and L(U) is undecidable • Only need to consider formulas of sub-logic L(F) or L(G) • L(F), PMCP decidable for PDSs interacting with: • Pairwise, asynchronous rendezvous • Nested locks • L(G), PMCP decidable for PDSs interacting with: • Pairwise, asynchronous rendezvous • Nested, non-nested locks • Note: can’t use broadcast with this model

11. Application to Processes Synchronizing via Rendezvous 1.) Set up template process • Determine control states and transitions 2.) Determine parameterized reachable control states • Algorithm 2 from paper 3.) Apply Model Checking procedure for L(F) or L(G) to verify desired property

12. Algorithm 2 Parameterized Control State Reachability for Rendezvous 1: Initialize and 2: repeat3: 4: Construct PDS by replacing each pairwise send(receive) transition s.t. a matching transition where , by the internal transition 5: Set 6:until 7:return

13. Template Process ? c! b! b? a? a! c?

14. a? a!

16. b! b?

18. c! c?

20. Model Checking • Need to use: Proposition 3 (Unbounded Multiplicity). Let be set of all parameterized reachable configurations of and let be a finite subset of . Then given , for some , there exists a finite computation of leading to a global state with at least copies of each configuration in Corollary 4: is parameterized reachable

21. Model Checking L(F) • Template • Define • : Set of parameterized reachable control states • : transitions of between states of with pairwise send or receive transitions changed to internal transition. • PMCP for L(F) is reduced to model checking two non-communicating processes • From an earlier paper, model checking two non-interacting PDSs is known to be efficiently decidable: polynomial time in the size of

22. Model Checking L(F) Formula has a finite computation of length , then at most pairwise send or receive transitions are fired along . Use unbounded multiplicity: for some , there exists a finite computation that leads to a state of with copies of each control state in Consider system with , first let processes execute to flood all control states of with multiplicity at least Guaranteed that for any computation of of length each rendezvous transition can always be fired.

23. Model Checking L(F) Theorem 6 (Binary Reduction Result): For any finite computation of , where , a finite computation of that is stuttering equivalent to Corollary 7: For any formula of L(F), for some , What about L(G)? This is harder to show • Can’t use flooding argument, cannot suggest a finite computation

24. Conclusions Main question: How can we use this? Want to model check properties of distributed algorithms. • safety, liveness L(G), L(F) Differences with our problem: • Many distributed algorithms don’t consider synchronization • Need to model as PDSs? • Perhaps use simpler model: transition systems • Could lead to fewer undecidability barriers… Procedure for constructing a template process from an algorithm and specification.

25. Coloring Algorithm