SlideServe
Télécharger Obtenir Pro
Menu
Accueil Pro
Préférences
ApparenceLight Aide et commentaires
© SlideServe · v2026

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

torgny avatar
torgny
25 diapositives · 384 Views · Jul 10, 2014

Method for verifying concurrent program transformations from source code to Java bytecode, applying to multithreaded Java programs. The paper discusses fine-grained algorithm implementation, objects, software transactional memory, and concurrent garbage collectors, presenting a proof theory for verifying transformations. The Rely-Guarantee Simulation (RGSim) approach is compositional and stronger than existing methods, showcasing its applications in optimizations and more.

A Rely-Guarantee-Based Simulation for Verifying Concurrent Program Transformations - slide 1
01 / 25A Rely-Guarantee-Based Simulation for Verifying Concurrent Program Transformations
1 / 17

Télécharger la présentation

A Rely-Guarantee-Based Simulation for Verifying Concurrent Program Transformations
Une image / un lien ci-dessous est fourni (tel quel) pour télécharger la présentation

Politique de téléchargement : le contenu du site vous est fourni TEL QUEL pour votre information et votre usage personnel ; il ne peut être vendu, concédé sous licence ni partagé sur d’autres sites sans l’accord de son auteur.Le contenu vous est fourni TEL QUEL, pour votre information et votre usage personnel uniquement. Téléchargez la présentation en cliquant sur ce lien. Lors du téléchargement, si vous ne parvenez pas à télécharger une présentation, l’éditeur a peut-être supprimé le fichier de son serveur.Pendant le téléchargement, si vous ne parvenez pas à obtenir une présentation, le fichier a peut-être été supprimé par l’éditeur.

F I N

Plus de contenu associé

Transcription de la présentation

  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