View
212
Download
0
Category
Preview:
Citation preview
A Rely-Guarantee-Based Simulation for Verifying Concurrent Program Transformations
Hongjin Liang, Xinyu Feng & Ming FuUniv. of Science and Technology of China
• Compilers for concurrent programs
Concurrent program transformations:
Target code
Source code
T
MultithreadedJava programs
Java bytecode
• Compilers for concurrent programs
• Fine-grained impl. of algorithms & objects
local d,t;
d = 0;
while(d==0){
t = x;
d = cas(&x, t, t+1);
}
Impl. of x++;
x++;
T
Concurrent program transformations:
• Compilers for concurrent programs
• Fine-grained impl. of algorithms & objects
• Impl. of software transactional memory (STM)
– Atomic block (transaction) fine-grained impl.
Concurrent program transformations:
• Compilers for concurrent programs
• Fine-grained impl. of algorithms & objects
• Impl. of software transactional memory (STM)
• Impl. of concurrent garbage collectors (GC)
How to verify such a transformation T ?
Concurrent program transformations:
How to define correctness of T ?
O
C
T
Print a rectangle.
Print a square
. Print a triangle
.
T: Source Target
O C: O has no more observable behaviors (e.g. I/O events by print(…)) than C.
OC
refinement
Correct(T):
C, O. O = T(C) O C
How to define correctness of T ? T: Source Target
O C: O has no more observable behaviors (e.g. I/O events by print(…)) than C.
(Compositionality)O1 || O2
Correct(T):
C, O. O = T(C) O C
C1 || C2
O1 C1 O2 C2
T(C) C
for trans. unit C
To verify a concurrent program transformation T :
is NOT compositional w.r.t. parallel composition:
O1 C1 O2 C2
O1 || O2 C1 || C2 O:local t;
t = x;
x = t + 1;
print( x );
C:x++;
print( x );
We have O C, since output(O) output(C) ;
but we do NOT have O||O C||C .
RGSim = Rely/Guarantee + Simulation
• Compositional w.r.t. parallel composition
• A proof theory for verifying T– Stronger than O C– Applications: optimizations, fine-grained
obj., concurrent GC, …
Our contribution:
Background: simulation in CompCert
(O, )
(C, ) (C’, ’)
(O’, ’)
* (C’’, ’’)
(O’’, ’’)e
e * …
…
[Leroy et al.]
Source state
Target stateobservable event (e.g. I/O)
O:local t;
t = x;
x = t + 1;
print( x );
C:x++;
print( x );
We have O C , but not O||O C||C
Simulation in CompCert [Leroy et al.]
Can verify T for sequential programs
NOT compositional w.r.t. parallel composition
Simulation in CompCert [Leroy et al.]
Can verify T for sequential programs
NOT compositional w.r.t. parallel composition Consider NO environments
Simulation in process calculus (e.g. CCS [Milner et al.])
• Assume arbitrary environments
Compositional
Too strong: limited applications
…(O’, ’’) (O’’, ’’’)
(C’, ’’) * (C’’, ’’’) …
’ ’e
e
Assuming arbitrary environments
env
env
Too strong to be satisfied, since env. can be arbitrarily bad.
(O, ) (O’, ’)
(C, ) (C’, ’)*
’ ’
In practice, T has assumptions about C & env.
T has assumptions about source code
• Compilers for concurrent programs– Prog. with data races has no semantics (e.g. concurrent C++)– Not guarantee correctness for racy programs
• Fine-grained objects– Accesses use same primitives (e.g. stack: push & pop)– Not guarantee correctness when env. can destroy obj.
• More examples are in the paper …
Env. of a thread cannot be arbitrarily bad !
[Boehm et al. PLDI’08]
Problems of existing simulations :
Our RGSim :
• Considers no env. in CompCert [Leroy et al.]
NOT compositional w.r.t. parallel composition
• Assumes arbitrary env. in process calculus (e.g. [Milner et al.])
Too strong: limited applications
• Parameterized with the interference with env.
Compositional
More applications
• Use rely/guarantee to specify the interference
What is rely/guarantee? [Jones'83]
• r: acceptable environment transitions• g: state transitions made by the thread
Thread1 Thread2
Nobody else would update x
I guarantee I would not touch y
Nobody else would update y
I guarantee I would not touch xCompatibility (Interference Constraints):
g2 r1 and g1 r2
r1: x = x’
’ r2: y = y’
’
g1: y = y’ ’ g2: x = x’ ’
(O, )
(C, ) (C’, ’)
(O’, ’)
* (C’’, ’’’)
(O’’, ’’’)e
e * …
…
*R
r
G
g
G
g
RGSim = Rely/Guarantee + Simulation
≲ ≲ ≲
(C’, ’’)
(O’, ’’)
≲
(O, r, g) ≲ (C, R, G)
Soundness theorem
(O, r, g) ≲ (C, R, G)
If we can find r, g, R and G such that
then we have: O C
Parallel compositionality
(O1||O2, r1r2, g1g2) ≲ (C1||C2, R1R2, G1G2)
(O2, r2, g2) ≲ (C2, R2, G2)
(O1, r1, g1) ≲ (C1, R1, G1)
g1 r2 g2 r1 G1 R2 G2 R1
(PAR)
More on compositionality
(O1, r, g) ≲ (C1, R, G) (O2, r, g) ≲ (C2, R, G)
(O1; O2, r, g) ≲ (C1; C2, R, G)
(O, r, g) ≲ (C, R, G) b B
(while b do O, r, g) ≲ (while B do C, R, G)
An axiomatic proof system for verifying T
…
We have applied RGSim to verify …
• Optimizations in parallel contexts– Loop invariant hoisting, strength reduction and induction
variable elimination, dead code elimination, …
• Fine-grained impl. & concurrent objects– Lock-coupling list, impl. of x++, Treiber’s non-blocking
stack, concurrent GCD algorithm, …
• Concurrent garbage collectors– A general GC verification framework– Hans Boehm’s concurrent GC [Boehm et al. 91]
Application: concurrent GC verification
read x … write x, v … alloc …
Programmer’s view of execution:
Real execution:
rB(x)
… wB(x, v) … aB() … || GC code
|| AbsGC
Turns garbage into reusable memory T
• Concurrent GC impl. = Barriers + GC code
• How to define Correct(GC) ?
C. T(C) || GC code C || AbsGC
Reduce to Correct(T) !
A concurrent GC verification framework
T(C) || GC code C || AbsGC
&
[Jones’83]
We have verified Hans Boehm’s concurrent GC algo [Boehm et al. 91]
(T(C) || GC code, r’’, g’’) ≲ (C || AbsGC, R’’, G’’)
(T(C), r’, g’) ≲ (C, R’, G’) (GC code, r, g) ≲ (AbsGC, R, G)
(rB(x), r’, g’) ≲ (read x, R’, G’)
(wB(x, v), r’, g’) ≲ ((write x, v), R’, G’)
(aB(), r’, g’) ≲ (alloc, R’, G’)
r, g ⊦ {p} GC code{q}
Compositionality
Compositionality
C.
g ≲ G
Conclusion
• RGSim = Rely/Guarantee + Simulation– Idea: parameterized with interference with env.– Compositional!
• A proof theory for verifying T– Optimizations, fine-grained obj., concurrent GC, …
http://kyhcs.ustcsz.edu.cn/relconcur/rgsim
Recommended