Program Logic for Concurrency Refinement Verification Xinyu Feng University of Science and Technology of China Joint work with Hongjin Liang (USTC) and.

Slides:



Advertisements
Similar presentations
Automated Theorem Proving Lecture 1. Program verification is undecidable! Given program P and specification S, does P satisfy S?
Advertisements

Modeling issues Book: chapters 4.12, 5.4, 8.4, 10.1.
Modular and Verified Automatic Program Repair Francesco Logozzo, Thomas Ball RiSE - Microsoft Research Redmond.
Hongjin Liang and Xinyu Feng
Refinement Verification of Concurrent Programs and Its Applications Hongjin Liang Univ. of Science and Technology of China Advisors: Xinyu Feng and Zhong.
50.530: Software Engineering Sun Jun SUTD. Week 13: Rely-Guarantee Reasoning.
Reduction, abstraction, and atomicity: How much can we prove about concurrent programs using them? Serdar Tasiran Koç University Istanbul, Turkey Tayfun.
A Rely-Guarantee-Based Simulation for Verifying Concurrent Program Transformations Hongjin Liang, Xinyu Feng & Ming Fu Univ. of Science and Technology.
Hoare’s Correctness Triplets Dijkstra’s Predicate Transformers
A simple sequential reasoning approach for sound modular verification of mainstream multithreaded programs Wolfram Schulte & Bart Jacobs Microsoft Research.
Program Analysis and Verification
ISBN Chapter 3 Describing Syntax and Semantics.
1 Semantic Description of Programming languages. 2 Static versus Dynamic Semantics n Static Semantics represents legal forms of programs that cannot be.
Programming Language Semantics Rely/Guarantee Reasoning Parallel Programs Tal Lev-Ami Viktor Vafeiadis Mooly Sagiv.
Spin Tutorial (some verification options). Assertion is always executable and has no other effect on the state of the system than to change the local.
Progress Guarantee for Parallel Programs via Bounded Lock-Freedom Erez Petrank – Technion Madanlal Musuvathi- Microsoft Bjarne Steensgaard - Microsoft.
Transaction Processing Lecture ACID 2 phase commit.
Certifying Low-Level Programs with Hardware Interrupts and Preemptive Threads Xinyu Feng Toyota Technological Institute at Chicago Joint work with Zhong.
An Open Framework for Foundational Proof-Carrying Code Xinyu Feng Yale University Joint work with Zhaozhong Ni (Yale, now at MSR), Zhong Shao (Yale) and.
Modular Verification of Assembly Code with Stack-Based Control Abstractions Xinyu Feng Yale University Joint work with Zhong Shao, Alexander Vaynberg,
On the Relationship Between Concurrent Separation Logic and Assume-Guarantee Reasoning Xinyu Feng Yale University Joint work with Rodrigo Ferreira and.
Copyright © 2006 The McGraw-Hill Companies, Inc. Programming Languages 2nd edition Tucker and Noonan Chapter 18 Program Correctness To treat programming.
Semantics with Applications Mooly Sagiv Schrirber html:// Textbooks:Winskel The.
Describing Syntax and Semantics
Comparison Under Abstraction for Verifying Linearizability Daphna Amit Noam Rinetzky Mooly Sagiv Tom RepsEran Yahav Tel Aviv UniversityUniversity of Wisconsin.
Compositional Verification of Termination-Preserving Refinement of Concurrent Programs Hongjin Liang Univ. of Science and Technology of China (USTC) Joint.
Distributed Computing 5. Snapshot Shmuel Zaks ©
Verifying Concurrent Objects under Fair Scheduling Hongjin Liang University of Science and Technology of China (USTC) Joint work with Xinyu Feng.
Runtime Refinement Checking of Concurrent Data Structures (the VYRD project) Serdar Tasiran Koç University, Istanbul, Turkey Shaz Qadeer Microsoft Research,
Concurrency, Mutual Exclusion and Synchronization.
CSI 3125, Axiomatic Semantics, page 1 Axiomatic semantics The assignment statement Statement composition The "if-then-else" statement The "while" statement.
Concurrency Verification. Why concurrency verification Concurrent programs show in many systems –Multi-task support in OS kernels –Handling interrupts.
Characterizing Progress Properties of Concurrent Objects via Contextual Refinements Hongjin Liang Univ. of Science and Technology of China (USTC) Joint.
Eran Yahav 1. Previously…  An algorithmic view  Abstract data types (ADT)  Correctness Conditions  Sequential consistency  Linearizability  Treiber’s.
Automated and Modular Refinement Reasoning for Concurrent Programs Shaz Qadeer.
Lecture 5 1 CSP tools for verification of Sec Prot Overview of the lecture The Casper interface Refinement checking and FDR Model checking Theorem proving.
Model Checking Linearizability via Refinement 1 ICFEM 2008 Model Checking Linearizability via Refinement Yang LIU, Wei CHEN, Yanhong A. LIU, and Jun SUN.
Software Transactional Memory Should Not Be Obstruction-Free Robert Ennals Presented by Abdulai Sei.
13 Aug 2013 Program Verification. Proofs about Programs Why make you study logic? Why make you do proofs? Because we want to prove properties of programs.
A Program Logic for Concurrent Objects under Fair Scheduling Hongjin Liang and Xinyu Feng University of Science and Technology of China (USTC) To appear.
Compositionality Entails Sequentializability Pranav Garg, P. Madhusudan University of Illinois at Urbana-Champaign.
Week 10: Loop Invariants, Code correctness Jimmy Voss Disclaimer: Some material may have been borrowed from both the Official Course slides as well as.
This Week Lecture on relational semantics Exercises on logic and relations Labs on using Isabelle to do proofs.
Ordering of Events in Distributed Systems UNIVERSITY of WISCONSIN-MADISON Computer Sciences Department CS 739 Distributed Systems Andrea C. Arpaci-Dusseau.
Program Correctness. The designer of a distributed system has the responsibility of certifying the correctness of the system before users start using.
Superstabilizing Protocols for Dynamic Distributed Systems Authors: Shlomi Dolev, Ted Herman Presented by: Vikas Motwani CSE 291: Wireless Sensor Networks.
A Calculus of Atomic Actions Tayfun Elmas, Shaz Qadeer and Serdar Tasiran POPL ‘ – Seminar in Distributed Algorithms Cynthia Disenfeld 27/05/2013.
CSC3315 (Spring 2009)1 CSC 3315 Languages & Compilers Hamid Harroud School of Science and Engineering, Akhawayn University
C HAPTER 3 Describing Syntax and Semantics. D YNAMIC S EMANTICS Describing syntax is relatively simple There is no single widely acceptable notation or.
Program Analysis and Verification
Simplifying Linearizability Proofs Using Reduction and Abstraction Serdar Tasiran Koc University, Istanbul, Turkey Tayfun Elmas, Ali Sezgin, Omer Subasi.
A Calculus of Atomic Actions Serdar Tasiran Koc University, Istanbul, Turkey Tayfun ElmasShaz Qadeer Koc University Microsoft Research.
A Program Logic for Concurrent Objects under Fair Scheduling Hongjin Liang and Xinyu Feng University of Science and Technology of China (USTC)
Spring 2017 Program Analysis and Verification
An Operational Approach to Relaxed Memory Models
Joint work with Yong Li, Xinyu Feng, Zhong Shao and Yu Zhang
Verification of Concurrent Programs
Concurrency Verification
Hongjin Liang, Xinyu Feng & Ming Fu
Relatively Complete Refinement Type System for Verification of Higher-Order Non-deterministic Programs Hiroshi Unno (University of Tsukuba) Yuki Satake.
Lecture 5 Floyd-Hoare Style Verification
Progress of Concurrent Objects with Partial Methods
Axiomatic semantics Points to discuss: The assignment statement
Programming Languages and Compilers (CS 421)
Programming Languages 2nd edition Tucker and Noonan
Non-preemptive Semantics for Data-race-free Programs
Program correctness Axiomatic semantics
Programming Languages and Compilers (CS 421)
Programming Languages 2nd edition Tucker and Noonan
Program Analysis and Verification
Presentation transcript:

Program Logic for Concurrency Refinement Verification Xinyu Feng University of Science and Technology of China Joint work with Hongjin Liang (USTC) and Zhong Shao (Yale) 1IFIP WG 2.3 Meeting, Orlando, May 21, 2014

Refinement ObsBeh(C )  ObsBeh(C' ) Set of observable behaviors (e.g., I/O event traces) C : ImplC' : Spec C  C' iff 2

Refinement Verification – Applications Correctness of objects/abstract data types Linearizability for concurrent objects Correctness of program transformations Compilers, program optimization, parallelization Runtime systems and OS kernels garbage collectors, STM algorithms, interrupt handlers 3

Example – TASLock vs. TTASLock TTASLockTASLock 4 lock() { local b, b'; b := true; while (b) { b' := l; while (b') { b' := l; } b := getAndSet(&l, true); } LOCK() { local B; B := getAndSet(&L, true); while (B) { B := getAndSet(&L, true); } lock is acquired Much cheaper read How to prove TTASLock refines TASLock ? [Herlihy and Shavit 2008]

Example – Concurrent Counter Fine-grained impl.Atomic spec. 5 inc(){ local done, tmp; done = false; while (!done) { tmp = cnt; done = cas(cnt, tmp, tmp+1); } INC(){ } Will be our running example. atomic block Take a snapshot Compare and swap

Our work: Rely-Guarantee-based program logic for refinement verification Also supports reasoning about progress properties Lock-freedom & wait-freedom Good locality Ongoing: Reasoning about deadlock-freedom & starvation-freedom? 6 Can we have a Hoare-style program logic to verify refinement of concurrent programs?

Development of the program logic Step 1: partial correctness logic for refinement Step 2: termination-preserving refinement 7

Program Logic – 1 st attempt Relational Hoare Logic / Separation Logic 8 {p} C1, C2 {q} Relational assertion Starting from related states satisfying p, the final states satisfy q (if both C1 and C2 terminate). [ p ] = {( ,  ) | … } [Benton’04, Yang’07]

Program Logic – 1 st attempt Relational Hoare Logic / Separation Logic 9 {p} C1, C2 {q} Inc_S(){ local tmp; tmp = cnt; tmp ++; cnt = tmp; } INC(){ } {cnt=CNT} Inc_S(), INC() {cnt = CNT} [Benton’04, Yang’07]

Program Logic – 1 st attempt Relational Hoare Logic / Separation Logic 10 {p} C1, C2 {q} {cnt=CNT} Inc_S(), INC() {cnt = CNT} However, not work for concurrency: {cnt=CNT} Inc_S() ǁ Inc_S(), INC() ǁ INC() {cnt = CNT}  [Benton’04, Yang’07]

Rely-Guarantee-Based Logic – 2 nd Attempt 11

One Slide Overview of Rely/Guarantee [Jones'83] r: acceptable environment transitions g: state transitions made by the thread Thread1Thread2 Nobody else would update x I guarantee I would not touch y Nobody else would update y I guarantee I would not touch x Compatibility (Interference Constraints): g2  r1 and g1  r2 r1:  x = x’ ’’ r2:  y = y’ ’’ g1:  y = y’ ’’ g2:  x = x’ ’’ [ r ] = {( ,  ’) | … } 12

Rely-Guarantee-Based Logic – 2 nd Attempt Relational rely/guarantee reasoning 13 {p} C1, C2 {q}R, G Lift R/G to a binary setting C2: ’’ C1:C1: ’’ [ r ] = {( ,  ’) | … } Traditional unary logic: [ R ] = {( ( ,  ), (  ’,  ’) ) | … } Binary setting: Related state pair [Jones'83]

Rely-Guarantee-Based Relational Logic – 2 nd Attempt Relational rely/guarantee reasoning 14 {p} C1, C2 {q}R, G (x = X = N  x’ = X’ = N’)  N  N’ Example: C2: ’’ C1:C1: ’’ (( ,  ), (  ’,  ’)) pqpq iff ( ,  ) p (  ’,  ’) q and p q

Compositional Rules 15 {p1} C1, C1’ {q1} R  G2, G1 {p2} C2, C2’ {q2} R  G1, G2 {p1  p2} C1ǁC2, C1’ǁC2’ {q1  q2}R, G1  G2 Just like standard unary Rely/Guarantee rules, e.g., {p} C1, C1’ {r}R, G{r} C2, C2’ {q}R, G {p} C1; C2, C1’; C2’ {q}R, G

Problem 16 {p} C1;C2;C3, C1’;C2’ {q}R, G Sometimes cannot be statically determined. To prove: {p} C1, C1’ {r}R, G{r} C2;C3, C2’ {q}R, G Should we do: {p} C1;C2, C1’ {r}R, G{r} C3, C2’ {q}R, G or:

Example inc(){ 2. local done, tmp; 3. done = false; 4. while (!done) { 5. tmp = cnt; 6. done = cas(cnt, tmp, tmp+1); 7. } } INC(){ } {p} inc, INC {q}R, G Should line 6 refine skip or INC ? Depends on the runtime value of done. How to prove ?

Example inc(){ 2. local done, tmp; 3. done = false; 4. while (!done) { 5. tmp = cnt; 6. done = cas(cnt, tmp, tmp+1); 7. } } INC(){ } {p} inc, INC {q}R, G Should line 6 refine skip or INC ? Depends on the runtime value of done. How to prove ? Cannot be handled in the binary form!

Disjunction rule? 19 { cnt = CNT = tmp } { cnt = CNT  done} done = cas(cnt, tmp, tmp+1), INC { cnt =CNT  tmp } { cnt = CNT   done } done = cas(cnt, tmp, tmp+1), skip Not stable

Combining Unary and Binary Rules – 3 rd Attempt Unary rules for conditional refinement 20 {P} C {Q}R, G [ R ] = {( ( ,  ), (  ’,  ’) ) | … } R/G: same as binary rules P: state assertion with auxiliary (ghost) state and code [ P ] = {( , ( , C’) ) | … } Low-level state Hi-level state

Combining Unary and Binary Rules – 3 rd Attempt Unary rules for conditional refinement 21 {P} C {Q}R, G [ R ] = {( ( ,  ), (  ’,  ’) ) | … } R/G: same as binary rules P: state assertion with auxiliary (ghost) state and code [ P ] = {( , ( , C’) ) | … } Low-level state Hi-level state Hi-level code (to be refined)

Unary judgments – example 22 {P} C {Q}R, G R, G: x = X  x = X P: { x = X  rem(X++) } Q: { x = X  rem(skip) } C: x++;

Unary judgments – example (2) inc(){ 2. local done, tmp; 3. done = false; 4. while (!done) { 5. tmp = cnt; 6. done = cas(cnt, tmp, tmp+1); 7. } } INC(){ } { cnt = CNT  rem(INC) } { cnt = CNT  (  done  rem(INC))  (done  rem(skip)) } done = cas(cnt, tmp, tmp+1); R, G: cnt=CNT  cnt = CNT

Combining Unary and Binary Rules The whole logic consists of both binary and unary rules binary rules for compositionality. unary rules for refinement of basic program units 24 Converting unary judgments to binary ones: {p  rem(C’)} C {q  rem(skip)} R, G {p} C, C’ {q}R, G (U2B)

A new consequence rule 25 {P’} C {Q’}R, G {P} C {Q}R, G P  P’Q’  Q P  P’ iff  ( , ( , C)) P.  (  ’, C’). (C,  )  * (C’,  ’)  ( , (  ’, C’)) P’ Ex: X = N  rem(X++; X++)  X=N+2  rem(skip) Make 0 or multiple steps

A new consequence rule 26 {P’} C {Q’}R, G {P} C {Q}R, G P  P’Q’  Q P  P’ iff  ( , ( , C)) P.  (  ’, C’). (C,  )  * (C’,  ’)  ( , (  ’, C’)) P’ This rule allows the high-level code to make moves (and we change rem(C) accordingly).

Soundness 27 {p} C, C’ {q}R, G ensures that C is (weakly) simulated by C’, which ensures C is a refinement of C’. However, this refinement allows: while(true) do skip  C for any C. Just like partial correctness in Hoare logic. …… C C’ [Liang et al. POPL’12]

Development of the program logic Step 1: partial correctness logic for refinement Step 2: termination-preserving refinement 28

Problem 29 {p} C, C’ {q}R, G allows n steps of C to correspond to 0 step of C’, and n could be  (infinite) ! while(true) do skip  C Therefore we could prove for any C. …… n step C C’

Problem 30 {p} C, C’ {q}R, G allows n steps of C to correspond to 0 step of C’, and n could be  (infinite) ! Idea: We must find some well-founded metric that decreases for each C step that corresponds to 0 step of C’. …… n step C C’

Assigning tokens for loops 31 inc(){ local done, tmp; done = false; while (!done) { … } INC(){ } Cannot loop forever while correspond to zero step of high-level code. (1) Each round of loop consumes 1 token. (2) The loop must refine at least one step of high- level code before it consumes all tokens or it ends. (3) The num. of tokens could be reset when one high-level step is refined.

While rule 32 {P’} C {P}R, G {P} while B do C {P}R, G P  P’ * wf(1) wf(i + j)  wf(i) * wf(j) { wf( i ) } while (i > 0){ { wf (i -1) } i -- ; { wf ( i ) } } Number of tokens Consumes 1 token

How is progress affected by environment? Cannot be affected Wait-freedom E.g., contains() method in concurrent Set Can be affected But when the thread executes in isolation, it’ll terminate Obstruction-freedom Can be affected only if the env. refines a high-level step (thus the system as a whole progresses) Lock-freedom 33 [Herlihy & Shavit 2008]

Lock-freedom – Example inc(){ 2. local done, tmp; 3.done = false; { wf(1) * ((done  rem(skip))  (  done  rem(INC)))} 4. while (!done) { {wf(0) * … } 5. tmp = cnt; {tmp=cnt * wf(0)  tmp  cnt * wf(1) …} 6. done = cas(cnt, tmp, tmp+1); 7. } } Environment may update cnt, which may delay termination of the current thrd However, the failure of one thread must be caused by the success of another. So the system as a whole progresses. Idea: if we know the environment progresses, we could reset the token.

Lock-freedom – Example inc(){ 2. local done, tmp; 3.done = false; { wf(1) * ((done  rem(skip))  (  done  rem(INC)))} 4. while (!done) { {wf(0) * … } 5. tmp = cnt; {tmp=cnt * wf(0)  tmp  cnt * wf(1) …} 6. done = cas(cnt, tmp, tmp+1); 7. } }

Lock-freedom – Example inc(){ 2. local done, tmp; 3.done = false; { wf(1) * ( (done  rem(skip))  (  done  rem(INC)) )} 4. while (!done) { {wf(0) * … } 5. tmp = cnt; {tmp=cnt * wf(0)  tmp  cnt * wf(1) …} 6. done = cas(cnt, tmp, tmp+1); 7. } } Loop invariant

Lock-freedom – Example inc(){ 2. local done, tmp; 3.done = false; { wf(1) * ( (done  rem(skip))  (  done  rem(INC)) )} 4. while (!done) { {wf(0) * rem(INC) … } 5. tmp = cnt; {tmp=cnt * wf(0)  tmp  cnt * wf(1) …} 6. done = cas(cnt, tmp, tmp+1); 7. } } Loop consumes one token

Lock-freedom – Example inc(){ 2. local done, tmp; 3.done = false; { wf(1) * ( (done  rem(skip))  (  done  rem(INC)) )} 4. while (!done) { {wf(0) * rem(INC) … } 5. tmp = cnt; {(tmp=cnt * wf(0)  tmp  cnt * wf(1) ) * rem(INC) …} 6. done = cas(cnt, tmp, tmp+1); 7. } } Env. progresses. Reset the token. Idea: if we know the environment progresses, we could reset the token.

Lock-freedom – Example inc(){ 2. local done, tmp; 3.done = false; { wf(1) * ( (done  rem(skip))  (  done  rem(INC)) )} 4. while (!done) { {wf(0) * rem(INC) … } 5. tmp = cnt; {(tmp=cnt * wf(0)  tmp  cnt * wf(1) ) * rem(INC) …} 6. done = cas(cnt, tmp, tmp+1); {(wf(1) * (done  rem(skip))  (wf(1) * (  done  rem(INC)) )} 7. } } CAS succeeds. Reset tokens. CAS fails. Follows 2 nd branch of precondition

Lock-freedom – Example inc(){ 2. local done, tmp; 3.done = false; { wf(1) * ( (done  rem(skip))  (  done  rem(INC)) )} 4. while (!done) { {wf(0) * rem(INC) … } 5. tmp = cnt; {(tmp=cnt * wf(0)  tmp  cnt * wf(1) ) * rem(INC) …} 6. done = cas(cnt, tmp, tmp+1); {(wf(1) * (done  rem(skip))  (wf(1) * (  done  rem(INC)) )} 7. } }

The termination-preserving program logic 41 {P} C {Q}R, G Judgments are the same: unary: {p} C, C’ {q}R, Gbinary: New formulation of R/G: [ R ] = {(( ,  ), (  ’,  ’), b) | … } Takes an extra Boolean tag b, to record whether this step corresponds to a high-level move.

The termination-preserving program logic 42 {P} C {Q}R, G Judgments are the same: unary: {p} C, C’ {q}R, Gbinary: New formulation of R/G: [ R ] = {(( ,  ), (  ’,  ’), b) | … } and P/Q: [ P ] = {( , ( , C’), w ) | … } Explicit number of tokens in assertions

The termination-preserving program logic (2) 43 {P’} C {P}R, G {P} while B do C {P}R, G P  P’ * wf(1) P  P’ iff  ( , ( , C), w) P.  n, (  ’, C’), w’. (C,  )  n (C’,  ’)  ( , (  ’, C’), w’) P’  ( n=0  w’  w) If n>0, no constraints for w’ {P’} C {Q’}R, G {P} C {Q}R, G P  P’Q’  Q (while) (conseq)

The termination-preserving program logic (3) Stability in traditional rely/guarantee reasoning: 44 Sta(p, R) iff if  p and ( ,  ’) R, then  ’ p

The termination-preserving program logic (3) Stability w.r.t. rely conditions 45 Sta(P, R) iff  ( , ( , C), w) P,  (( , ( , C)), (  ’, (  ’, C’)), b) R.  w’. (  ’, (  ’, C’), w’) P  ( b=false  w’  w) If b=true, no constraints for w’

Infinite non-determinism 46 x = 0; while (y > 0){ y-- } R: x  0  y’ = N  x = 0  y = y’ Arbitrary update of y What would be the pre-condition if we have to specify the number of tokens? {P} C {Q}R, G {|P| w } C {|Q| w }R, G

47

More on termination- preservation NOT a total correctness logic! Ensures low-level preserves termination of high-level Not ensure termination of low-level/high-level code 48 local tmp; while (true) { tmp = cnt; cas(cnt, tmp, tmp+1); } while (true) { ; }  Example:

Applications of the logic 49

Summary Relational logic for termination-preserving refinement Rely/Guarantee based Combination of binary and unary rules Introduce “rem(C)”, expressive for conditional correspondence Use tokens for termination-preservation Supports lock-freedom Can be easily adapted for wait-freedom Read our CSL-LICS 2014 paper! Ongoing Deadlock-freedom and starvation-freedom Similar to lock-freedom and wait-freedom Assumes fairness – How to encode the assumption in logic? 50

Thank you! 51