Model Checking Concurrent Systems – An Example: Mutual Exclusion

Slides:



Advertisements
Similar presentations
1 Verification by Model Checking. 2 Part 1 : Motivation.
Advertisements

Operating Systems Part III: Process Management (Process Synchronization)
CS 267: Automated Verification Lecture 8: Automata Theoretic Model Checking Instructor: Tevfik Bultan.
并发模型的验证 ( 例子 ). 2 互斥协议模型:示意图 x==0||t==0 t0 x=1,t=0 t1 t2 y==0||t==1 t3 x=0 s0 y=1,t=1 s1 s2 s3 y=0 初始状态 s0 t0 x=0 y=0 t=0.
Introducing Formal Methods, Module 1, Version 1.1, Oct., Formal Specification and Analytical Verification L 5.
1 Model checking. 2 And now... the system How do we model a reactive system with an automaton ? It is convenient to model systems with Transition systems.
Automatic Verification Book: Chapter 6. What is verification? Traditionally, verification means proof of correctness automatic: model checking deductive:
An Introduction to the Model Verifier verds Wenhui Zhang September 15 th, 2010.
Program correctness The State-transition model A global state S  s 0 x s 1 x … x s m {s k = local state of process k} S0  S1  S2  … Each state transition.
1 MODULE name (parameters) “Ontology” “Program” “Properties” The NuSMV language A module can contain modules Top level: parameters less module Lower level.
Ch. 7 Process Synchronization (1/2) I Background F Producer - Consumer process :  Compiler, Assembler, Loader, · · · · · · F Bounded buffer.
Process Synchronization Continued 7.2 The Critical-Section Problem.
Concurrent Programming Problems OS Spring Concurrency pros and cons Concurrency is good for users –One of the reasons for multiprogramming Working.
Previously… Processes –Process States –Context Switching –Process Queues Threads –Thread Mappings Scheduling –FCFS –SJF –Priority scheduling –Round Robin.
Chapter 6 Process Synchronization Bernard Chen Spring 2007.
Silberschatz, Galvin and Gagne ©2013 Operating System Concepts – 9 th Edition Chapter 5: Process Synchronization.
5.1 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts with Java – 8 th Edition Chapter 5: CPU Scheduling.
Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition, Chapter 6: Process Synchronization.
Multiprocessor Synchronization Algorithms ( ) Lecturer: Danny Hendler The Mutual Exclusion problem.
Process Synchronization. Module 6: Process Synchronization Background The Critical-Section Problem Peterson’s Solution Synchronization Hardware Semaphores.
China’s Software Industry August 2006 Instructor: Hengming Zou, Ph.D.
Liveness Counter Abstraction Liveness with Counter Abstraction A mir P nueli, J essie X u and L enore Z uck.
On the Relationship Between Concurrent Separation Logic and Assume-Guarantee Reasoning Xinyu Feng Yale University Joint work with Rodrigo Ferreira and.
Synchronization in Distributed Systems. Mutual Exclusion To read or update shared data, a process should enter a critical region to ensure mutual exclusion.
Concurrency in Distributed Systems: Mutual exclusion.
Hardware solutions So far we have looked at software solutions for the critical section problem. –algorithms whose correctness does not rely on any other.
Transaction Based Modeling and Verification of Hardware Protocols Xiaofang Chen, Steven M. German and Ganesh Gopalakrishnan Supported in part by SRC Contract.
1 Race Conditions/Mutual Exclusion Segment of code of a process where a shared resource is accessed (changing global variables, writing files etc) is called.
Introduction to Software Testing Chapter 9.4 Model-Based Grammars Paul Ammann & Jeff Offutt
1 Thread Synchronization: Too Much Milk. 2 Implementing Critical Sections in Software Hard The following example will demonstrate the difficulty of providing.
Instructor: Rajeev Alur
The Critical Section Problem
CS6133 Software Specification and Verification
Concurrency. A process is a program executing on a virtual computer Processor speed and multiplexing of shared resources are ignored Order of thread execution.
Internet Software Development Controlling Threads Paul J Krause.
2/19/20031 Introduction to SMV. 2/19/20032 Useful Links CMU Model checking homepage SMV windows version
Development of Formally Verified Erlang Programs a case study Thomas Arts Clara Benac Earle Computer Science Lab Stockholm, Sweden.
Silberschatz, Galvin and Gagne  Operating System Concepts Chapter 7: Process Synchronization Background The Critical-Section Problem Synchronization.
Program correctness The State-transition model The set of global states = so x s1 x … x sm {sk is the set of local states of process k} S0 ---> S1 --->
CSE Winter 2008 Introduction to Program Verification January 31 proofs through simplification.
Program correctness The State-transition model A global states S  s 0 x s 1 x … x s m {s k = set of local states of process k} S0  S1  S2  Each state.
Hwajung Lee. The State-transition model The set of global states = s 0 x s 1 x … x s m {s k is the set of local states of process k} S0  S1  S2  Each.
CIS 842: Specification and Verification of Reactive Systems Lecture INTRO-Examples: Simple BIR-Lite Examples Copyright 2004, Matt Dwyer, John Hatcliff,
Hwajung Lee. The State-transition model The set of global states = s 0 x s 1 x … x s m {s k is the set of local states of process k} S0  S1  S2  Each.
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
Properties as Processes : FORTE slide Properties as Processes: their Specification and Verification Joel Kelso and George Milne School of Computer.
This Week Lecture on relational semantics Exercises on logic and relations Labs on using Isabelle to do proofs.
Model Checking C-Programs – An Example: Integer Square Root Wenhui Zhang
Lecture 4 Correctness and Fairness Verification and Assurance.
Program Correctness. The designer of a distributed system has the responsibility of certifying the correctness of the system before users start using.
Software Systems Verification and Validation Laboratory Assignment 4 Model checking Assignment date: Lab 4 Delivery date: Lab 4, 5.
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
Process Synchronization. Objectives To introduce the critical-section problem, whose solutions can be used to ensure the consistency of shared data To.
Development of Formally Verified Erlang Programs a case study
Modular verification of multithreaded shared-memory programs
Modeling Mutual Exclusion Algorithms
IS 2935: Developing Secure Systems
ITEC452 Distributed Computing Lecture 5 Program Correctness
The Critical-Section Problem
Lecture 19 Syed Mansoor Sarwar
Lecture 2 Part 2 Process Synchronization
Mutual Exclusion CS p0 CS p1 p2 CS CS p3.
Three Special Structures – Case, Do While, and Do Until
Chapter 6: Process Synchronization
Verification of mutual exclusion algorithms with EST
ITEC452 Distributed Computing Lecture 7 Mutual Exclusion
Chapter 6: Synchronization Tools
Foundations and Definitions
Don Porter Portions courtesy Emmett Witchel
Presentation transcript:

Model Checking Concurrent Systems – An Example: Mutual Exclusion Wenhui Zhang http://lcs.ios.ac.cn/~zwh

Contents Mutual Exclusion Model Checking Summary

Contents Mutual Exclusion Model Checking Summary

Example: Mutual Exclusion Process A Process B Non-Critical Region Non-Critical Region Critical Region Critical Region 4

Example: Mutual Exclusion Process A Process B Non-Critical Region Non-Critical Region Request for Entering Request for Entering Wait Wait Check for Entering Check for Entering Critical Region Critical Region Exit Exit 5

Design of Mutual Exclusion (Activity) initialization work in NCR work in NCR request request wait wait [else] [else] [condition 1] [condition 2] work in CR work in CR exit exit 6

Design of Mutual Exclusion Purpose: ensure that not both processes are working in the critical region (CR) Mechanism: use shared variables y=1: the first process is applying for entering CR or it is in CR x=1: the second process is applying for entering CR or it is in CR t=(i-1): the i-th process has priority for entering CR

Design of Mutual Exclusion (State) initialization x:=0;y:=0 work in NCR work in NCR y:=1;t:=1 x:=1;t:=0 wait wait [x=1 and t=1] [y=1 and t=0] [x=0 or t=0] [y=0 or t=1] work in CR work in CR y:=0 x:=0 8

Design of Mutual Exclusion (State) initialization x:=0;y:=0 Process A Process B work in NCR work in NCR y:=1;t:=1 x:=1;t:=0 wait wait [x=1 and t=1] [y=1 and t=0] [x=0 or t=0] [y=0 or t=1] work in CR work in CR y:=0 x:=0 9

Correctness of the Design How do we know that the design is correct?

Combined States of the Two Processes Process A Process B Remark NCR wait CR Bad state

Correctness of the Design How do we know that the design is correct? We have to be sure that the bad state is not reachable in all possible executions of the algorithm We may use state exploration (model checking) techniques or deductive proof methods

Process States and Variable States Process A Process B x y t NCR 1 wait CR (a,b,x,y,t)

The Set of States: S {(a,b,x,y,t) | a,b{NCR,wait,CR} and x,y,t{0,1}}

Transition Relation: R (NCR,b,x,y,t)  (wait,b,x,1,1) (wait,b,0,y,t)  (CR,b,0,y,t) (wait,b,x,y,0)  (CR,b,x,y,0) (wait,b,1,y,1)  (wait,b,1,y,1) (CR,b,x,y,t)  (NCR,b,x,0,t) (a,NCR,x,y,t)  (a,wait,1,y,0) (a,wait,x,1,t)  (a,CR,x,1,t) (a,wait,x,y,1)  (a,CR,x,y,1) (a,wait,x,1,0)  (a,wait,x,1,0) (a,CR,x,y,t)  (a,NCR,0,y,t)

The Set of Initial States: I { (NCR,NCR,0,0,0), (NCR,NCR,0,0,1) }

Fairness F={ ((x=0t=0)a=wait), ((y=0t=1)b=wait), }

Safety Property  = (a=CRb=CR) Is  a safety property?

Expectancy Property  = (a=CRb=CR) Is  an expectancy property?

Contents Mutual Exclusion Model Checking Summary

Modeling and Model Checking Model Checking with VERDS http://lcs.ios.ac.cn/~zwh/verds Input to VERDS VVM (VERDS verification model) Modeling Language VML (VERDS modeling langauge)

State Transition Model Variables: SA: {NCR,wait,CR} SB: {NCR,wait,CR} x: {0,1} y: {0,1} t: {0,1} NCR NCR y=1,t=1 x=1,t=0 wait wait x==0||t==0 y==0||t==1 Initial States SA=NCR SB=NCR x=0 y=0 yes yes no no CR CR y=0 x=0 22

Without Fairness Specifications

Modeling in VML Safety: Mutual exclusion VVM VAR x: 0..1; y: 0..1; t: 0..1; INIT x=0; y=0; PROC p0: p0m(); p1: p1m(); SPEC AG(!(p0.a=c0&p1.b=c0)); Safety: Mutual exclusion

Modeling in VML MODULE p0m() MODULE p1m() VAR VAR b: {n0,w0,c0}; a: {n0,w0,c0}; INIT a=n0; TRANS a=n0: (y,t,a):=(1,1,w0); a=w0&(x=0|t=0): (a):=(c0); a=w0&!(x=0|t=0): (a):=(w0); a=c0: (y,a):=(0,n0);   MODULE p1m() VAR b: {n0,w0,c0}; INIT b=n0; TRANS b=n0: (x,t,b):=(1,0,w0); b=w0&(y=0|t=1): (b):=(c0); b=w0&!(y=0|t=1): (b):=(w0); b=c0: (x,b):=(0,n0);

The Complete Model in VML VVM VAR x: 0..1; y: 0..1; t: 0..1; INIT x=0; y=0; PROC p0: p0m(); p1: p1m(); SPEC AG(!(p0.a=c0&p1.b=c0));  MODULE p0m() VAR a: {n0,w0,c0}; INIT a=n0; TRANS a=n0: (y,t,a):=(1,1,w0); a=w0&(x=0|t=0): (a):=(c0); a=w0&!(x=0|t=0): (a):=(w0); a=c0: (y,a):=(0,n0); MODULE p1m() b: {n0,w0,c0}; b=n0; b=n0: (x,t,b):=(1,0,w0); b=w0&(y=0|t=1): (b):=(c0); b=w0&!(y=0|t=1): (b):=(w0); b=c0: (x,b):=(0,n0);

Verification with VERDS ../verds -ck 1 mutex3.vvm VERSION: verds 1.43 - JAN 2013 FILE: mutex3.vvm PROPERTY: A G ! ((p0.a = 2 )& (p1.b = 2 )) bound = 1 time = 0 ---------- time = 0 bound = 2 time = 0 . bound = 6 time = 0 ---------- time = 0 CONCLUSION: TRUE (time=0)

Consider the Expectancy Property VVM VAR x: 0..1; y: 0..1; t: 0..1; INIT x=0; y=0; PROC p0: p0m(); p1: p1m(); SPEC AG(!(p0.a=c0&p1.b=c0)); AF((p0.a=c0)|(p1.b=c0)); Expectancy: Working in critical region

Verification with VERDS ../verds -ck 2 mutex3.vvm VERSION: verds 1.43 - JAN 2013 FILE: mutex3.vvm PROPERTY: A F ((p0.a = 2 )| (p1.b = 2 )) bound = 1 time = 1 ---------- time = 1 bound = 2 time = 1 bound = 3 time = 1 bound = 4 time = 1 CONCLUSION: FALSE (time=1)

Checking the Model Process A Process B initialization x:=0;y:=0 work in NCR work in NCR y:=1;t:=1 x:=1;t:=0 wait wait [x=1 and t=1] [y=1 and t=0] [x=0 or t=0] [y=0 or t=1] work in CR work in CR y:=0 x:=0 30

With Fairness Specifications

Modified Model (with Fairness)  MODULE p0m() VAR a: {n0,w0,c0}; INIT a=n0; TRANS a=n0: (y,t,a):=(1,1,w0); a=w0&(x=0|t=0): (a):=(c0); a=w0&!(x=0|t=0): (a):=(w0); a=c0: (y,a):=(0,n0); FAIRNESS !((x=0|t=0)&(a=w0)); MODULE p1m() VAR b: {n0,w0,c0}; INIT b=n0; TRANS b=n0: (x,t,b):=(1,0,w0); b=w0&(y=0|t=1): (b):=(c0); b=w0&!(y=0|t=1): (b):=(w0); b=c0: (x,b):=(0,n0); FAIRNESS !((y=0|t=1)&(b=w0));

Verification with VERDS ../verds -ck 1 mutex3a.vvm VERSION: verds 1.43 - JAN 2013 FILE: mutex3a.vvm PROPERTY: A G ! ((p0.a = 2 )& (p1.b = 2 )) bound = 1 time = 0 ---------- time = 0 bound = 2 time = 0 . bound = 17 time = 0 CONCLUSION: TRUE (time=0)

Verification with VERDS ../verds -ck 2 mutex3a.vvm VERSION: verds 1.43 - JAN 2013 FILE: mutex3a.vvm PROPERTY: A F ((p0.a = 2 )| (p1.b = 2 )) bound = 1 time = 1 ---------- time = 1 bound = 2 time = 1 . bound = 26 time = 1 ---------- time = 1 CONCLUSION: TRUE (time=1)

Correctness of the Design How do we know that the design is correct? We have to be sure that the bad state is not reachable in all possible executions of the algorithm We may apply the following techniques: Modeling (in a language with a formal semantics) Verification (by model checking) We have shown that the bad state is not reachable We have also shown an expectance property holds

Remarks on the Correctness Only verified against the given properties: The safety property The expectancy property Rely on: The model The verification tool The fairness assumption as a part of the model, for the verification of the response property

Contents Mutual Exclusion Model Checking Summary

Questions?