Thread Modular Model Checking

1. Thread Modular Model Checking by Cormac Flanagan and Shaz Qadeer (published in Spin’03) Hong,Shin Thread Modular Model Checking

2. Contents • Introduction • Concurrent Finite-State Systems • Concurrent Pushdown Systems • Conclusion Thread Modular Model Checking

3. Introduction 1/8 • Designing multithreaded software system is difficult due to subtle interactions among threads operating concurrently on shared data. • Model checking is a promising technique for verifying correctness properties of multithreaded software system. • However, a multithreaded software system is difficult to model check due to its large state space. Approach Verify each thread separately using an environment assumption to model interleaved steps of the other threads. • The environment assumption of each thread is a binary relation over the set of global stores. • The environment assumption includes all global store updates that may be performed by other threads. Thread Modular Model Checking

4. Introduction 2/8 • Target multithreaded program. • There is a finite number of threads in a system. • There is a finite number of global store in a system. • There is a finite number of local store in each thread. • The multithreaded software system is loosely-coupled. • There is little co-relation among the local states of the various threads. • Requirement properties are safety properties. (e.g. assertion, global invariant) Thread Modular Model Checking

5. Introduction 3/8 Thread-modular model checking overview • Aguarantee models all global store updates performed by a thread. • For a thread, its environment assumption is the disjunction of the guarantees of all the other threads. • The guarantee of each thread is initially the empty relation, and is iteratively extended during the model checking process. • Each thread is verified using the standard algorithm for sequential model checking except that at each control point of the thread, the global state is allowed to mutate according to the guarantees of the other threads. • Whenever a thread modifies the global store, that transition on the global states is added to that thread’s guarantee. • The iteration continues until the reachable state space and guarantee of each thread converges. Thread Modular Model Checking

6. Introduction 4/8 Example Simple(n) : A multithreaded program with n threads executing procedure p concurrently. • Each thread is identified by unique integer value from Tid = {1,…, n}. • x : A shared integer variable. Its initial value is 1. • m : The mutex which protects the shared variable x. • The type is Mutex = {0} [Tid. • m is manipulated by two operations: acquire and release. • acquire blocks until m=0 and then automatically set m to the identifier of the current thread. • release sets m back to 0. • For each thread, there is an implicit local variable called pc, the program counter of the thread. • A pc takes values from the set Loc={1,…,6} of control location. • We denote the program counter of thread tid by pc[tid]. Thread Modular Model Checking

7. Introduction 5/8 • A simple multithreaded program int x := 1 ; Mutex m := 0 ; void p() { 1: acquire ; 2: x := 0 ; 3: x := 1 ; 4: assert x > 0 ; 5: release ; 6: } Simple(n) = p() | … | p() • Correctness properties (1) There should be no data race. Error set: 9i, j2Tid. ijÆpc[i]2{2, 3, 4} Æpc[j]2{2, 3, 4} (2) The assertion at control location 4 does not fail for any thread. Error set: 9i2Tid . pc[i] = 4 Æx· 0 (3) Every reachable state staisfies the invariant m=0  x = 1. Error set: m = 0 Æx 1 n times Thread Modular Model Checking

8. Introduction 6/8 • In this program, the domain of global store is (Mutex£int). • Thread-modular model checking algorithm computes the guarantee GµTid£ (Mutex£int) £ (Mutex£int). • If the thread whose identifier is tid ever takes a step where the global variables is modified from (m1,x1) to (m2,x2), then (tid, (m1, x1), (m2, x2)) 2G. • The thread-local reachable set is RµTid£ (Mutex£int) £Loc. • If there is a reachable state where its global store is (m,x), and the program counter of thread whose identifier is tid has the value pc, then (tid, (m,x),pc) 2 R. Thread Modular Model Checking

9. Introduction 7/8 • A simple multithreaded program int x := 1 ; Mutex m := 0 ; void p() { For thread 1 1: acquire ; 2: x := 0 ; 3: x := 1 ; 4: assert x > 0 ; 5: release ; 6: } <Guarantee> (tid, <m,x> , <m’,x’>) (1,<0,1>,<1,1>) (1,<1,1>,<1,0>) (1,<1,0>,<1,1>) (1,<1,1>,<0,1>) <Reachable set> (pc, <m,x>) (1,<0,1>) (2,<1,1>) (3,<1,0>) (4,<1,1>) (5,<1,1>) (6,<0,1>) Thread Modular Model Checking

10. Introduction 7/8 • A simple multithreaded program int x := 1 ; Mutex m := 0 ; void p() { For thread 2 1: acquire ; 2: x := 0 ; 3: x := 1 ; 4: assert x > 0 ; 5: release ; 6: } <Guarantee> (1,<0,1>,<1,1> ) (1,<1,1>,<1,0>) (1,<1,0>,<1,1>) (1,<1,1>,<0,1>) (2,<0,1>,<2,1>) (2,<2,1>,<2,0>) (2,<2,0>,<2,1>) (2,<2,1>,<0,1>) <Reachable> (1,<0,1>) (2,<2,1>) (3,<2,0>) (4,<2,1>) (5,<2,1>) (6,<0,1>) (1,<1,1>) (1,<1,0>) Thread Modular Model Checking

11. Introduction 8/8 • Limitation • Thread-modular model checking avoids the overhaed of correlating the local stores of the threads by checking each thread separately. • This approach works if the global store contains sufficient information about the overall system state. • If the global store does not contain sufficient information about the overall system state, it may yield false alarms. • In previous example, if the value of m is {0, 1}, it reports false alarms. • General approach to alleviate false alarms is to include a suitable abstraction of the local store of each thread in the global store. Ex. int x = 0 ; ThreadA() { ThreadB() { int i = 0 ; int i = 0 ; for i = 0 to 5 { for i = 0 to 6 { while(x==0) ; while (x == 1) ; x=0 ; } x=1 ; } } assert(x != 1) ; } Thread Modular Model Checking

12. Concurrent Finite-State Systems1/5 • A concurrent finite-state system consists of a finite number of concurrently executing threads. • The threads communicate through a global store. • Each thread has its own local store. • Each thread has its own thread identifier. • A state of the concurrent finite-state system consists of a global store g and a mapping ls from thread identifiers to local stores • ls[ t :=l ] denotes a mapping that is identical to ls except that it maps thread identifier t to local store l. • Domains Thread Modular Model Checking

13. Concurrent Finite-State Systems 2/5 • The behavior of the individual threads can be modeled as the transition relation T : TµTid £ (GlobalStore£LocalStore) £ (GlobalStore£LocalStore) • We assume that program execution starts in an initial state Σ0 = (g0 , l0 ). • The correctness condition for the program in a system is provided by an error set EµGlobalStore£LocalStores. • A state (g, ls) is erroneous if E(g, ls) is true. • The goal of model checking is to determine if, when started from the initial state Σ0 , the system can reach an erroneous state. Thread Modular Model Checking

14. Concurrent Finite-State Systems 3/5 Standard model checking • The least solution RµState to the following inference rules describes the set of reachable states. • Having computed R, it is straightforward to determine if any erroneous state is reachable. • - An erroneous state is reachable If there exist g and ls such that • R(g, ls) ÆE(g, ls) • The size of R(the space complexity) is O(|GlobalStore|£|LocalStore||Tid| ). • The time complexity is O(|Tid|£|GlobalStore|2£|LocalStore||Tid|+1 ). • - For an element R, (BASIC STEP) can be applied • |Tid|£|GlobalStore|£|LocalStore| times. Thread Modular Model Checking

15. Concurrent Finite-State Systems 4/5 Thread-modular model checking • Under thread-modular model checking, each thread is checked separately, using guarantees that abstract the behavior of interleaved steps of other threads. • This algorithm works by computing two relations: • R specifies the reachable states of each thread. RµTid£GlobalStore£LocalStore • G specifies the guarantee of each thread. GµTid£GlobalStore£GlobalStore • Inference rules Thread Modular Model Checking

16. Concurrent Finite-State Systems 5/5 • Lemma1. For all global store g and local store maps ls, if R(g, ls) then for all thread identifier t,R(t, g, ls(t)). If a software error causes an erroneous state to be reachable, then the thread-modular algorithm will catch that error. 9g,ls.(E(g,ls)ÆR(g,ls)) !9g,ls.(E(g,ls)Æ8t.R(t,g,ls(t))) • Space complexity O(|Tid|£|GlobalStore|£|GlobalStore|+|Tid|£|GlobalStore|£|LocalStore| ) • Time complexity O(|Tid|2£|GlobalStore|2£|LocalStore|+|Tid|£|GlobalStore|2£|LocalStore|2 ) Guarantee Reachable states Thread Modular Model Checking

17. Concurrent Pushdown Systems 1/6 • Realistic software systems are typically constructed using procedures and procedure calls. • For this reason, we extend the previous approach to handle concurrent pushdown systems. • A state of concurrent pushdown systems consists of a global store, a collection of local stores, and a collection of stacks(one for each thread). • Domains Thread Modular Model Checking

18. Concurrent Pushdown Systems 2/6 • We model the behavior of the individual threads using following three relations: - Tmodels thread steps that do not manipulate the stack. - T + models steps of thread t that push a frame onto the stack. - T - models steps of thread t that pop a frame from the stack • The correctness condition is specified by an error set • EµGlobalStore£LocalStores. Thread Modular Model Checking

19. Concurrent Pushdown Systems 3/6 • Assume that all stacks are empty in the initial state (ss0) • The set of reachable states is defined by the least relation RµState satisfying the following rules: Thread Modular Model Checking

20. Concurrent Pushdown Systems 4/6 • Although sound and complete model checking of concurrent pushdown systems is undecidable, thread-modular reasoning allows us to model check such systems an conservative yet useful manner. • The algorithm works by computing the guarantee relation G and the reachability relation P and Q. - P (t, g, l, g’, l’) holds if (1) (g, l) is reachable where l is a local store of t, (2) from any such state, the system can later reach a state with (g’,l’) where l’ is a local store of t. - Q (t,g,l,f,g’,l’) holds if (1) (g,l) is reachable where l is a local store of t, and (2) from any such state, the system can later reach a state with g’ and l’ where l’ is a local store of t, and where the stack is identical to that in first state except that the frame f has been added to it. Thread Modular Model Checking

21. Concurrent Pushdown Systems 5/6 • The relation G, P, Q are defined as the least solution to the following rules. Thread Modular Model Checking

22. Concurrent Pushdown Systems 6/6 • Lemma 2 For all global stores g and local store maps ls and stack maps ss, if R(g, ls, ss) then for all thread identifier t, there exists some g’ , l’ such that P(t, g’, l’, g, ls(t)).  If a software error causes an erroneous state to be reachable, then thread-modular algorithm will catch that error. 9g,ls,ss. (E(g,ls) ÆR(g, ls, ss)) ! 9g,ls.E(g,ls) Æ8t.9g’,l’. P ( t, g’, l’, g, ls(t) ) • Space complexity O(|Tid|£|GlobalStore|2£|LocalStore|2£|Frame|) • Time complexity O(|Tid|2£|GlobalStore|3£|LocalStore|3£|Frame|) Thread Modular Model Checking

23. Conclusion • This work presents thread-modular model checking for verifying multithreaded software system. • The thread-modular model checking algorithm constructs an abstraction of multithreaded software system using environment assumptions. • This technique is particularly effective for the verification of loosely-coupled multithreaded software systems. Thread Modular Model Checking