Upload
frank-watts
View
219
Download
0
Tags:
Embed Size (px)
Citation preview
Thread-modularThread-modularAbstraction RefinementAbstraction Refinement
Thomas A. Henzinger, et al.CAV 2003
Seonggun KimKAIST CS750b
2/28
Abstract of this paperAbstract of this paperWe present an algorithm called Tar (“Thread-modular Abstraction Refinement") for model checking safety properties of concurrent software. The Tar algorithm uses thread-modular assume-guarantee reasoning to overcome the exponential complexity in the control state of multithreaded programs. Thread modularity means that Tar explores the state space of one thread at a time, making assumptions about how the environment can interfere. The Tar algorithm uses counterexample guided predicate-abstraction refinement to overcome the usually infinite complexity in the data state of C programs. A successive approximation scheme automatically infers the necessary precision on data variables as well as suitable environment assumptions. The scheme is novel in that transition relations are approximated from above, while at the same time environment assumptions are approximated from below. In our software verification tool Blast we have implemented a fully automatic race checker for multithreaded C programs which is based on the Tar algorithm. This tool has verified a wide variety of commonly used locking idioms, including locking schemes that are not amenable to existing dynamic and static race checkers such as Eraser or Warlock.
Assume-guarantee reasoning
Thread-modularity(one thread at a time)
The exponential complexityin the control state of mt-programs
Needs assumptions aboutthe behavior of other threads
Due tointerleaving
Iteratively weakeningthe assumptions until fix-point
Assumption Inference
3/28
Multithreaded ProgramsMultithreaded Programs
Why multithreading? Performance (esp, response time) Conceptual simplicity
Why not multithreading? Race hazard Deadlock
ThreadThreadSharedMemory
x Thread
Thread
4/28
Race HazardRace Hazard
A thread can be interfered by others
1: bal = getBalance();2: bal += deposit;3: setBalance(bal);
2: bal += deposit;
1: bal = getBalance();
3: setBalance(bal);
2: bal += deposit;
1: bal = getBalance();
3: setBalance(bal);
balance = 100deposit = 20
bal = 100
bal = 120
bal = 100
bal = 120
bal = 120
bal = 120
balance = 120
5/28
Detecting Race HazardDetecting Race Hazard
Critical Section A piece of code that must not be concurrently a
ccessed by more than one thread Can be detected by safety checking
“Is (T1||T2) reachable to states satisfying (pc1 Crit pc2 Crit) ?” No safe, Yes unsafe
But, it may be intractable
6/28
Curse of InterleavingCurse of Interleaving
Need to abstract away other threads Divide and Conquer (one thread at a time) Can we do the abstraction a priori?
B3
A2
B1
A3
B2
A1
B3
A2
B1
A3
B2
A1
B3
A2
B1
A3
B2
A1
B3
A2
B1
A3
B2
A1
B3
A2
B1
A3
B2
A1
B3
A2
B1
A3
B2
A1
…State
Explosionnk
(n statements, k threads)
7/28
Naïve Thread-modular Naïve Thread-modular AnalysisAnalysis
Conservative (pessimistic) Assumption “Others can access shared resources
anytime”
safe
safe
safe
Simple,But rarely happens
8/28
Assume-Guarantee Assume-Guarantee ReasoningReasoning
Assume-Guarantee reasoning1. Make an assumption2. Use the assumption to prove required properties3. Ensure the assumption is correct
S1, S2: sub-systemsP1, P2: sub-properties
S1vP1 S2vP2
S1uS2 v P1uP2
S1vP1 P1uS2vP2
S1uS2 v P1uP2
P2uS1vP1 P1uS2vP2
S1uS2 v P1uP2
Prove: S1uS2 v P1uP2
Divide and Conquer Assume-Guarantee
9/28
Circular Assume-Circular Assume-GuaranteeGuarantee
Cyclic Guarantee To guarantee assuming P2 is correct, we need to
guarantee assuming P1 is correct, vice versa Cycle-breaking condition is needed (beyond this paper)
Is it sound? Is it complete? Not sound, not complete for general cases Sound, but not complete for safety properties (beyond this
paper)
P2uS1vP1 P1uS2vP2
S1uS2 v P1uP2
Circular Assume-Guarantee
u S1 v u S2 v
S1 u S2 v u
10/28
Thread-modular AG Thread-modular AG ReasoningReasoning
A form of assume-guarantee reasoning P = S1 | S2 | … | Sn
For each thread Si, specify two actions Ai: an environment assumption of Si
Transitions that may be performed by other threads Gi: a guarantee of Si
Transitions of Si under Ai that can be seen by other threads
Ensuring the assumption Check whether Gi is stronger than Aj for all j, j i
11/28
safe
Use Summaries Use Summaries (“Assume”)(“Assume”)
safe
A
12/28
safe
Verify Summaries Verify Summaries (“Guarantee”)(“Guarantee”)
µ µ
safe
G
13/28
Assume-Guarantee Assume-Guarantee ReasoningReasoning
µ
safe
µ
safe
safe
14/28
T-M Abstraction T-M Abstraction RefinementRefinement
Step0: Seed Assumption Set the assumption for each thread to false ()
Step1: Reachability Analysis (same as LA) Compute an abstraction Ri of the reachable states of each thread i , b
ased on the current assumptions about the behavior of the other threads
Step2: Counterexample Analysis (same as LA) Check if Ri contains error states
Yes: do trace analysis and abstraction refinement; goto step0 No: goto step3
Step3: Guarantee Assumptions Check if the assumptions are sound
Yes: report “safe” No: update the assumptions w.r.t. the Ri ; goto step1
allows no transitionto other threads
allows transitions Ri
to other threads
15/28
Iter1: Build SummaryIter1: Build Summary
A
Reach
Graph
G
; µ ;Summariz
e
A
Reach
Graph
No Race
Race
Trace
Local Predicate - Cuts locally infeasible paths - Invisible to other threads - Quantified away
16/28
Iter1: Trace AnalysisIter1: Trace Analysis
Trace
FeasibleInfeasible
Refine using Trace
Add new predicates
Report Trace
Interleaved sequenceof threads’ ops
17/28
Iter2: Build SummaryIter2: Build Summary
A
Reach
Graph
G
µ ;Summariz
e
A
Reach
Graph
G
µSummariz
e
A
Reach
Graph
G
µSummariz
e
;
18/28
Context arrives at Fix-Context arrives at Fix-pointpoint
A
Reach
Graph
G
µSummariz
e
Shared Memory
Assume-
Guarantee
No Race
19/28
Example: Producer-Example: Producer-ConsumerConsumer
Shared Variables: data, flag Error State: pcp = 3 pcc = 3
Initial State: pcp = 1 pcc = 1 flag = 0
Implicit Local Predicate: pcp, pcc
Thread Producer1: while(1) {2: while(flag != 0) {};3: data = produce_data();4: flag = 1; }
Thread Consumer1: while(1) {2: while(flag != 1) {};3: copy = data;4: flag = 0; }
P C, P, C
!P !C
20/28
Iteration 1-1Iteration 1-1
Thread Producer1: while(1) {2: while(flag != 0) {};3: data = produce_data();4: flag = 1; }
Reac
h Grap
h
!P
!P
P
!P
Sum. µ
Thread Consumer1: while(1) {2: while(flag != 1) {};3: copy = data;4: flag = 0; }
Reac
h Grap
h
!C
!C
C
!C
Sum. µ
!P
P
!C
C
21/28
Iteration 1-2Iteration 1-2
Thread Producer1: while(1) {2: while(flag != 0) {};3: data = produce_data();4: flag = 1; }
R.G.
Thread Consumer1: while(1) {2: while(flag != 1) {};3: copy = data;4: flag = 0; }
R.G.
!C
C
!P
P
!P!C !PC
PCP!C
!P!C !PC
!P!C !PC
!C!P !CP
CPC!P
!C!P !CP
!C!P !CP
Trace Analysi
s
Trace Analysi
s
Add flag
22/28
Iteration 2-1Iteration 2-1
Thread Producer1: while(1) {2: while(flag != 0) {};3: data = produce_data();4: flag = 1; }
R.G.
Thread Consumer1: while(1) {2: while(flag != 1) {};3: copy = data;4: flag = 0; }
R.G.
S.
!P
P!F
!P
!PF
!C
CF
!C
!C!F
S.
!P
P!F
!PF
!C
CF
!C!F
µ
µ
23/28
Iteration 2-2Iteration 2-2
Thread Producer1: while(1) {2: while(flag != 0) {};3: data = produce_data();4: flag = 1; }
R.G.
Sum
!P
P!F
!PF
!C
CF
!C!F
!P !C !P CF !P !C!F
!P !C !P CF !P !C!F
P!F!C
!PF!C !PCF !P!C!F
!P !C !P CF !P !C!F
P!F!C
!PF!C !PCF !P!C!F
Same
for Consumer
24/28
Experimental ResultExperimental Result
25/28
NO (trace)
Thread-modular AnalysisThread-modular Analysis
Init. Abstraction Preds: P0 Ctr: k0
Init. Summary Summary: ;
A
Reach Graph
YES SummarizeSafe?
G
µ ?
YES
NO
Update Summary
Refine using Trace
Feasible?
YES
NO Output SAFENo Data Races
OutputData Race
TRACE ANALYSIS
BUILD SUMMARY
26/28
ConclusionConclusion
Thread-Modular Abstraction Refinement Overcome the exponential complexity in
the control state of multithreaded programs Race Detection
Verified a wide variety of commonly used locking idioms Including locking schemes that are not
amenable to existing race checkers such as Eraser or Warlock
27/28
Pros & ConsPros & Cons
Pros Annotation-free thread-modular analysis Extends BLAST to concurrent programs
Cons It still needs to compute an interleaving
To check if the trace is feasible Does it really reduce the burden of
interleaving?
28/28
ReferencesReferences
Some figures and slides come from Ranjit Jhala’s slides “Three lectures on Lazy Abstraction” #2
http://www.cse.ucsd.edu/~rjhala/blast.html p.2, pp. 12~16
osq.cs.berkeley.edu/retreat03/Jhala-TAR.ppt p6, pp. 8~10