1 / 25

A Rely-Guarantee-Based Simulation for Verifying Concurrent Program Transformations

A Rely-Guarantee-Based Simulation for Verifying Concurrent Program Transformations. Hongjin Liang , Xinyu Feng & Ming Fu Univ. of Science and Technology of China. Concurrent program transformations: . Source code. Multithreaded Java programs. T. Target code. Java bytecode.

torgny
Download Presentation

A Rely-Guarantee-Based Simulation for Verifying Concurrent Program Transformations

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. A Rely-Guarantee-Based Simulation for Verifying Concurrent Program Transformations Hongjin Liang, XinyuFeng & Ming Fu Univ. of Science and Technology of China

  2. Concurrent program transformations: Source code Multithreaded Java programs T Target code Java bytecode Compilers for concurrent programs

  3. local d,t; d = 0; while(d==0){ t = x; d = cas(&x, t, t+1); } Impl. of x++; Concurrent program transformations: T x++; Compilers for concurrent programs Fine-grained impl. of algorithms & objects

  4. 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.

  5. Concurrent program transformations: How to verifysuch a transformation T ? Compilers for concurrent programs Fine-grained impl. of algorithms & objects Impl. of software transactional memory (STM) Impl. of concurrent garbage collectors (GC)

  6. How to define correctness of T ? T: Source  Target C Print a rectangle. C O T O Print a square. Print a triangle.   refinement O  C: O has no more observable behaviors (e.g. I/O events by print(…)) than C.

  7. How to define correctness of T ? T: Source  Target Correct(T): C, O. O = T(C)  O  C O  C: O has no more observable behaviors (e.g. I/O events by print(…)) than C.

  8. To verify a concurrent program transformation T : O1  C1 O2  C2  (Compositionality)  O1 || O2 C1 || C2 Correct(T): C, O. O = T(C)  O  C • T(C)  C • for trans. unit C 

  9.  is NOT compositional w.r.t. parallel composition: O1  C1 O2  C2 O: local t; t = x; x = t + 1; print( x ); C: x++; print( x ); O1 ||O2  C1 || C2 We have O  C, since output(O)  output(C) ; but we do NOT have O||O  C||C .

  10. RGSim = Rely/Guarantee + Simulation Our contribution: • Compositional w.r.t. parallel composition • A proof theory for verifying T • Stronger than O  C • Applications: optimizations, fine-grained obj., concurrent GC, …

  11. Background: simulation in CompCert [Leroy et al.] • Source state e … (C, ) (C’, ’) (C’’, ’’) * * • observable event (e.g. I/O)  • Target state   e (O, ) … (O’, ’) (O’’, ’’)

  12. Simulation in CompCert[Leroy et al.]  Can verify T for sequential programs  NOT compositional w.r.t. parallel composition O: local t; t = x; x = t + 1; print( x ); C: x++; print( x ); We haveO  C , but notO||OC||C

  13. 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

  14. Assuming arbitrary environments (C, ) (C’, ’) e * ’ ’ * env … (C’, ’’) (C’’, ’’’) (O’, ’) (O, ) ’ ’ e (O’’, ’’’) env … (O’, ’’) • Too strong to be satisfied, since env. can be arbitrarily bad. • In practice, T has assumptions about C & env.

  15. 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 … [Boehm et al. PLDI’08] Env. of a thread cannot be arbitrarily bad !

  16. Problems of existing simulations : • Considers noenv. in CompCert[Leroy et al.]  NOT compositional w.r.t. parallel composition • Assumes arbitraryenv. in process calculus (e.g. [Milner et al.])  Too strong: limited applications Our RGSim : • Parameterized with the interference with env. •  Compositional • More applications • Use rely/guarantee to specify the interference

  17. What is rely/guarantee? [Jones'83] • r: acceptable environment transitions • g: state transitions made by the thread y = y’ x = x’ y = y’ x = x’     ’ ’ ’ ’ Thread1 Thread2 • g2: • g1: • r2: • r1: Nobody else would update y Nobody else would update x I guarantee I would not touch x I guarantee I would not touch y Compatibility (Interference Constraints): • g2  r1 and g1  r2

  18. RGSim = Rely/Guarantee + Simulation * (C’, ’’) R … (C, ) (C’, ’) (C’’, ’’’) e * * G G ≲ ≲ ≲ ≲ (O’, ’) (O’, ’’) r … e (O, ) g g (O’’, ’’’) (O, r, g) ≲(C, R, G)

  19. Soundness theorem If we can find r, g, R and G such that • (O, r, g) ≲ (C, R, G) then we have: O  C

  20. Parallel compositionality (O1, r1, g1) ≲(C1, R1, G1) (O2, r2, g2) ≲(C2, R2, G2) g1  r2 g2  r1 G1  R2 G2  R1 (PAR) (O1||O2, r1r2, g1g2) ≲(C1||C2, R1R2, G1G2)

  21. 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

  22. 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]

  23. rB(x) … wB(x, v) … aB() … Application: concurrent GC verification Programmer’s view of execution: ||AbsGC read x … write x, v … alloc … T Turns garbage into reusable memory Real execution: || GC code • Concurrent GC impl. = Barriers + GC code • How to defineCorrect(GC) ? Reduce to Correct(T) ! C. T(C) || GC code  C ||AbsGC

  24. A concurrent GC verification framework C. T(C) || GC code  C ||AbsGC  • (T(C) ||GC code, r’’, g’’) ≲(C ||AbsGC, R’’, G’’)  Compositionality • (T(C), r’, g’) ≲(C, R’, G’) • (GC code, r, g) ≲(AbsGC, R, G) & Compositionality   r, g ⊦{p} GC code{q} (rB(x), r’, g’) ≲(read x, R’, G’) (wB(x, v), r’, g’) ≲((write x, v), R’, G’) (aB(), r’, g’) ≲(alloc, R’, G’) [Jones’83] g ≲G We have verified Hans Boehm’s concurrent GC algo[Boehm et al. 91]

  25. 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

More Related