thread modular model checking n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Thread Modular Model Checking PowerPoint Presentation
Download Presentation
Thread Modular Model Checking

Loading in 2 Seconds...

play fullscreen
1 / 23

Thread Modular Model Checking - PowerPoint PPT Presentation


  • 124 Views
  • Uploaded on

Thread Modular Model Checking. by Cormac Flanagan and Shaz Qadeer (published in Spin’03) Hong,Shin. Contents. Introduction Concurrent Finite-State Systems Concurrent Pushdown Systems Conclusion. Introduction 1/8.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Thread Modular Model Checking' - jovita


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
thread modular model checking

Thread Modular Model Checking

by Cormac Flanagan and Shaz Qadeer

(published in Spin’03)

Hong,Shin

Thread Modular Model Checking

contents
Contents
  • Introduction
  • Concurrent Finite-State Systems
  • Concurrent Pushdown Systems
  • Conclusion

Thread Modular Model Checking

introduction 1 8
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

introduction 2 8
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

introduction 3 8
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

introduction 4 8
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

introduction 5 8
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

introduction 6 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

introduction 7 8
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

introduction 7 81
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

introduction 8 8
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

concurrent finite state systems 1 5
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

concurrent finite state systems 2 5
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

concurrent finite state systems 3 5
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

concurrent finite state systems 4 5
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

concurrent finite state systems 5 5
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

concurrent pushdown systems 1 6
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

concurrent pushdown systems 2 6
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

concurrent pushdown systems 3 6
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

concurrent pushdown systems 4 6
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

concurrent pushdown systems 5 6
Concurrent Pushdown Systems 5/6
  • The relation G, P, Q are defined as the least solution to the following rules.

Thread Modular Model Checking

concurrent pushdown systems 6 6
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

conclusion
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