Program Analysis and Verification 0368-4479

Slides:



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

PZ03D Programming Language design and Implementation -4th Edition Copyright©Prentice Hall, PZ03D - Program verification Programming Language Design.
Program Analysis and Verification
50.530: Software Engineering Sun Jun SUTD. Week 13: Rely-Guarantee Reasoning.
Hoare’s Correctness Triplets Dijkstra’s Predicate Transformers
Rigorous Software Development CSCI-GA Instructor: Thomas Wies Spring 2012 Lecture 11.
Formal Semantics of Programming Languages 虞慧群 Topic 5: Axiomatic Semantics.
This Week Finish relational semantics Hoare logic Interlude on one-point rule Building formulas from programs.
Axiomatic Verification I Prepared by Stephen M. Thebaut, Ph.D. University of Florida Software Testing and Verification Lecture 17.
Copyright © 2006 Addison-Wesley. All rights reserved.1-1 ICS 410: Programming Languages Chapter 3 : Describing Syntax and Semantics Axiomatic Semantics.
ISBN Chapter 3 Describing Syntax and Semantics.
Dynamic semantics Precisely specify the meanings of programs. Why? –programmers need to understand the meanings of programs they read –programmers need.
Predicate Transformers
1 Semantic Description of Programming languages. 2 Static versus Dynamic Semantics n Static Semantics represents legal forms of programs that cannot be.
1/22 Programs : Semantics and Verification Charngki PSWLAB Programs: Semantics and Verification Mordechai Ben-Ari Mathematical Logic for Computer.
A Survey of Rely-Guarantee Approaches in Compositional Verification Murat Demirbas OSU.
Formal Methods of Systems Specification Logical Specification of Hard- and Software Prof. Dr. Holger Schlingloff Institut für Informatik der.
Programming Language Semantics Rely/Guarantee Reasoning Parallel Programs Tal Lev-Ami Viktor Vafeiadis Mooly Sagiv.
1 Operational Semantics Mooly Sagiv Tel Aviv University Textbook: Semantics with Applications.
Axiomatic Semantics Dr. M Al-Mulhem ICS
Programming Language Semantics Mooly SagivEran Yahav Schrirber 317Open space html://
PSUCS322 HM 1 Languages and Compiler Design II Formal Semantics Material provided by Prof. Jingke Li Stolen with pride and modified by Herb Mayer PSU Spring.
Dr. Muhammed Al-Mulhem 1ICS ICS 535 Design and Implementation of Programming Languages Part 1 Fundamentals (Chapter 4) Axiomatic Semantics ICS 535.
Semantics with Applications Mooly Sagiv Schrirber html:// Textbooks:Winskel The.
Software Verification Bertrand Meyer Chair of Software Engineering Lecture 2: Axiomatic semantics.
Operational Semantics Semantics with Applications Chapter 2 H. Nielson and F. Nielson
Programming Language Semantics Axiomatic Semantics of Parallel Programs.
Describing Syntax and Semantics
Proving Program Correctness The Axiomatic Approach.
Program Analysis and Verification Noam Rinetzky Lecture 3: Axiomatic Semantics 1 Slides credit: Roman Manevich, Mooly Sagiv, Eran Yahav.
Program Analysis and Verification
Proofs of Correctness: An Introduction to Axiomatic Verification Prepared by Stephen M. Thebaut, Ph.D. University of Florida CEN 5035 Software Engineering.
CSI 3125, Axiomatic Semantics, page 1 Axiomatic semantics The assignment statement Statement composition The "if-then-else" statement The "while" statement.
1 Formal Semantics of Programming Languages “Program testing can be used to show the presence of bugs, but never to show their absence!” --Dijkstra.
Concurrency Verification. Why concurrency verification Concurrent programs show in many systems –Multi-task support in OS kernels –Handling interrupts.
Program Correctness. 2 Program Verification An object is a finite state machine: –Its attribute values are its state. –Its methods optionally: Transition.
Eran Yahav 1. Previously…  An algorithmic view  Abstract data types (ADT)  Correctness Conditions  Sequential consistency  Linearizability  Treiber’s.
Program Analysis and Verification Spring 2014 Program Analysis and Verification Lecture 4: Axiomatic Semantics I Roman Manevich Ben-Gurion University.
Chapter 3 Part II Describing Syntax and Semantics.
COP4020 Programming Languages Introduction to Axiomatic Semantics Prof. Robert van Engelen.
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.
Program Logic for Concurrency Refinement Verification Xinyu Feng University of Science and Technology of China Joint work with Hongjin Liang (USTC) and.
Program Analysis and Verification Spring 2015 Program Analysis and Verification Lecture 4: Axiomatic Semantics I Roman Manevich Ben-Gurion University.
Cs7100(Prasad)L18-9WP1 Axiomatic Semantics Predicate Transformers.
CSC3315 (Spring 2009)1 CSC 3315 Languages & Compilers Hamid Harroud School of Science and Engineering, Akhawayn University
Program Analysis and Verification
Operational Semantics Mooly Sagiv Tel Aviv University Sunday Scrieber 8 Monday Schrieber.
Program Analysis and Verification Spring 2015 Program Analysis and Verification Lecture 8: Static Analysis II Roman Manevich Ben-Gurion University.
Program Analysis and Verification Noam Rinetzky Lecture 2: Operational Semantics 1 Slides credit: Tom Ball, Dawson Engler, Roman Manevich, Erik.
Spring 2017 Program Analysis and Verification
Formal methods: Lecture
Spring 2017 Program Analysis and Verification
Formal Methods in Software Engineering 1
Verification of Concurrent Programs
Program Analysis and Verification
Hongjin Liang, Xinyu Feng & Ming Fu
Lecture 5 Floyd-Hoare Style Verification
Axiomatic semantics Points to discuss: The assignment statement
Programming Languages and Compilers (CS 421)
Axiomatic Verification I
Formal Methods in software development
Predicate Transformers
Formal Methods in software development
Axiomatic Verification I
Program correctness Axiomatic semantics
Program Verification with Hoare Logic
Programming Languages and Compilers (CS 421)
COP4020 Programming Languages
Program Analysis and Verification
Presentation transcript:

Program Analysis and Verification Noam Rinetzky Lecture 8: Axiomatic Semantics – Rely/Guarantee (Take II * ) Slides credit: Roman Manevich, Mooly Sagiv, Eran Yahav

We begin … Mobiles Scribe

Programming Language Syntax: … S 1 ‖ … ‖ S n | c | await b then c – In our case: c = case | x:=a Operational Semantics: – States – Commands – Traces S 1, s ⇒ S’ 1, s’ S 1 ‖ S 2, s ⇒ S’ 1 ‖ S 2, s [Par 1 ] s ∈ ∑ S 0, s 0 ⇒ S 1, s 1 ⇒ … ⇒ s k c0c0 c1c1 ckck

Programming Language Syntax: … S 1 ‖ … ‖ S n | c | await b then c – In our case: c = case | x:=a Operational Semantics: – States – Commands – Traces S 1, s ⇒ S’ 1, s’ S 1 ‖ S 2, s ⇒ S’ 1 ‖ S 2, s [Par 1 ] s ∈ ∑ S 0, s 0 ⇒ S 1, s 1 ⇒ … ⇒ … c0c0 c1c1 ckck

Axiomatic Semantics (Hoare Logic) Disjoint parallelism Global invariant Owicky – Gries [PhD. ‘76] { P } S 1 ‖ S 2 { Q } … …

Rely / Guarantee Aka Assume/Guarantee Cliff Jones [IFIP ‘83] Main idea: Modular capture of interference – Compositional proofs

Meaning of (atomic) Commands A relation between pre-states and post-states c ⊆ ∑ × ∑ S 0, s 0 ⇒ S 1, s 1 ⇒ … ⇒ s k+1 c0c0 c1c1 ckck

Meaning of (atomic) Commands A relation between pre-states and post-states c ⊆ ∑ × ∑ S 0, s 0 ⇒ S 1, s 1 ⇒ … ⇒ s k+1 c0c0 c1c1 ckck

Meaning of (atomic) Commands A relation between pre-states and post-states S 0, s 0 ⇒ s 1 ⇒ … ⇒ s k+1 ⇒ s k+2 ⇒ s k+3 ⇒ s k+3 ⇒ s k+4 … ⇒ s n+1 ⇒ ⇒ ⇒ ⇒ ⇒ ⇒ … c0c0 c1c1 ckck c k+1 c k+2 c k+3 cncn c0c0 c1c1 ckck c k+1 c k+2 c k+3 cncn

Intuition: Global Invariant Every (intermediate) state satisfies invariant I S 0, s 0 ⇒ s 1 ⇒ … ⇒ s k+1 ⇒ s k+2 ⇒ s k+3 ⇒ s k+3 ⇒ s k+4 … ⇒ s n+1 c0c0 c1c1 ckck c k+1 c k+2 c k+3 cncn ⇒ ⇒ ⇒ ⇒ ⇒ ⇒ … I=I= c0c0 c1c1 ckck c k+1 c k+2 c k+3 cncn

Intuition: Global Invariant Thread-view S 0, s 0 ⇒ s 1 ⇒ … ⇒ s k+1 ⇒ s k+2 ⇒ s k+3 ⇒ s k+3 ⇒ s k+4 … ⇒ s n+1 ⇒ ⇒ ⇒ ⇒ ⇒ … I=I= c0c0 c1c1 ckck c k+1 c k+2 c k+3 cncn ⇒

Intuition: Rely Guarantee Thread-view S 0, s 0 ⇒ s 1 ⇒ … ⇒ s k+1 ⇒ s k+2 ⇒ s k+3 ⇒ s k+3 ⇒ s k+4 … ⇒ s n+1 c0c0 c1c1 ckck c k+1 c k+2 c k+3 cncn ⇒ ⇒ ⇒ ⇒ … ⇒ …

Intuition: Rely Guarantee Thread-view S 0, s 0 ⇒ s 1 ⇒ … ⇒ s k+1 ⇒ s k+2 ⇒ s k+3 ⇒ s k+3 ⇒ s k+4 … ⇒ s n+1 c0c0 c1c1 ckck c k+1 c k+2 c k+3 cncn ⇒ ⇒ ⇒ ⇒ … ⇒ … G G G G RRRR R

Intuition: Rely Guarantee Thread-view S 0, s 0 ⇒ s 1 ⇒ … ⇒ s k+1 ⇒ s k+2 ⇒ s k+3 ⇒ s k+3 ⇒ s k+4 … ⇒ s n+1 c0c0 c1c1 ckck c k+1 c k+2 c k+3 cncn ⇒ ⇒ ⇒ ⇒ … ⇒ … G G G G R*R* R*R* R*R*

Relational Post-Conditions meaning of commands a relations between pre-states and post-states Option I: {P} C {Q} – P is a one state predicate – Q is a two-state predicate Example – {true} x := x + 1 {x= x + 1}

Relational Post-Conditions meaning of commands a relations between pre-states and post-states Option II: {P} C {Q} – P is a one state predicate – P is a one-state predicate Use logical variables to record pre-state Example – {x = X} x := x + 1 {x= X + 1}

Intuition (again) C G Hoare: { P } S { Q } ~ {P} ⇒⇒⇒⇒ {Q} C R/G: R,G ⊢ { P } S { Q } ~ {P} ⇒⇒⇒⇒⇒⇒⇒ {Q} G RRR GG

Goal: Parallel Composition R  G 2, G 1 ⊢ { P } S 1 ‖ S 2 { Q } R, G 1  G 2 ⊢ { P } S 1 ‖ S 2 { Q } (PAR) R  G 1, G 2 ⊢ { P } S 1 ‖ S 2 { Q }

Relational Post-Conditions meaning of commands a relations between pre-states and post-states Option I: {P} C {Q} – P is a one state predicate – Q is a two-state predicate Example – {true} x := x + 1 {x= x + 1}

Meaning of (atomic) Commands meaning of atomic commands is relations between pre-states and post-states C {Q} – P is a one state predicate – Q is a two-state predicate Example – {true} x := x + 1 {x= x + 1}

Meaning of (atomic) Commands meaning of atomic commands is relations between pre-states and post-states C {Q} – P is a one state predicate – Q is a two-state predicate Example – {true} x := x + 1 {x= x + 1}

From one- to two-state relations p( ,  ) =p(  ) A single state predicate p is preserved by a two-state relation R if – p  R  p – ,  : p(  )  R( ,  )  p(  ) – P is stable under R

Operations on Relations (P;Q)( ,  )=  :P( ,  )  Q( ,  ) ID( ,  )= (  =  ) R * = ID  R  (R;R)  (R;R;R)  …  – Reflexive transitive closure of R

Formulas ID(x) = (x = x) ID(p) =(p  p) Preserve (p)= p  p

Judgements c  (p, R, G, Q)

Informal Semantics c  (p, R, G, Q) – For every state  such that   p: Every execution of c on state  with (potential) interventions which satisfy R results in a state  such that ( ,  )  Q The execution of every atomic sub-command of c on any possible intermediate state satisfies G

Informal Semantics c  (p, R, G, Q) – For every state  such that   p: Every execution of c on state  with (potential) interventions which satisfy R results in a state  such that ( ,  )  Q The execution of every atomic sub-command of c on any possible intermediate state satisfies G c  [p, R, G, Q] – For every state  such that   p: Every execution of c on state  with (potential) interventions which satisfy R must terminate in a state  such that ( ,  )  Q The execution of every atomic sub-command of c on any possible intermediate state satisfies G

A Formal Semantics Let  C  R denotes the set of quadruples s.t. that when c executes on  1 with potential interferences by R it yields an intermediate state  2 followed by an intermediate state  3 and a final state  4 –  4 =  when c does not terminate  C  R = { :   :  R  (  *  2   2 =  3 =  4    ’, C’:  *  ( (  2 =  1   2 =  )  (  3 =    3 =  ’)   4 =  )    C’  R ) c  (p, R, G, Q) – For every   C  R such that  1  p  G If  4   :  Q

A Formal Semantics Let  C  R denotes the set of quadruples s.t. that when c executes on  1 with potential interferences by R it yields an intermediate state  2 followed by an intermediate state  3 and a final state  4 –  4 =  when c does not terminate  C  R = { :   :  R  (  *  2   2 =  3 =  4 )  (   ’, C’:  *  ( (  2 =  1   2 =  )  (  3 =    3 =  ’)  (  4 =     C’  R ) ) c  (p, R, G, Q) – For every   C  R such that  1  p  G If  4   :  Q

A Formal Semantics Let  C  R denotes the set of quadruples s.t. that when c executes on  1 with potential interferences by R it yields an intermediate state  2 followed by an intermediate state  3 and a final state  4 –  4 =  when c does not terminate  C  R = { :   :  R  (  *  2   2 =  3 =  4 )  (   ’, C’:  *  ( (  2 =  1   2 =  )  (  3 =    3 =  ’)   4 =  )    C’  R )) c  (p, R, G, Q) – For every   C  R such that  1  p  G If  4   :  Q

Simple Examples X := X + 1  (true, X=X, X =X+1  X=X, X =X+1) X := X + 1  (X  0, X  X, X>0  X=X, X>0) X := X + 1 ; Y := Y + 1  (X  0  Y  0, X  X  Y  Y, G, X>0  Y>0)

Inference Rules Define c  (p, R, G, Q) by structural induction on c Soundness – If c  (p, R, G, Q) then c  (p, R, G, Q)

Atomic Command {p} c {Q} c  (p, preserve(p), Q  ID, Q) (Atomic)

Conditional Critical Section {p  b} c {Q} await b then c  (p, preserve(p), Q  ID, Q) (Critical)

Sequential Composition c 1  (p 1, R, G, Q 1 ) c 1 ; c 2  (p 1, R, G, (Q 1 ; R * ; Q 2 )) (SEQ) c 2  (p 2, R, G, Q 2 ) Q 1  p 2

Conditionals c 1  (b 1, R, G, Q) p  b  R *  b 1 if atomic {b} then c 1 else c 2  (p, R, G, Q) (IF) c 2  (b 2, R, G, Q) p   b  R*  b 2

Loops c  (j  b 1, R, G, j) j  b  R *  b 1 while atomic {b} do c  (j, R, G,  b  j) (WHILE) R  Preserve(j)

Refinement c  (p, R, G, Q) c  (p’, R’, G’, Q’) (REFINE) p’  p Q  Q’ R’  R G  G’

Parallel Composition c 1  (p 1, R 1, G 1, Q 1 ) c 1 || c 2  (p 1  p 1, (R 1  R2), (G 1  G 2 ), Q) where Q= (Q 1 ; (R 1  R 2 )*; Q 2 )  (Q 2 ; (R 1  R 2 )*; Q 1 ) (PAR) c 2  (p 2, R 2, G 2, Q 2 ) G 1  R 2 G 2  R 1

Issues in R/G Total correctness is trickier Restrict the structure of the proofs – Sometimes global proofs are preferable Many design choices – Transitivity and Reflexivity of Rely/Guarantee – No standard set of rules Suitable for designs