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.

Slides:



Advertisements
Similar presentations
Model Checking Lecture 1.
Advertisements

Modeling issues Book: chapters 4.12, 5.4, 8.4, 10.1.
Mutual Exclusion – SW & HW By Oded Regev. Outline: Short review on the Bakery algorithm Short review on the Bakery algorithm Black & White Algorithm Black.
CS 267: Automated Verification Lecture 8: Automata Theoretic Model Checking Instructor: Tevfik Bultan.
Partial Order Reduction: Main Idea
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
Part 3: Safety and liveness
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:
CSC321 Concurrent Programming: §3 The Mutual Exclusion Problem 1 Section 3 The Mutual Exclusion Problem.
PROTOCOL VERIFICATION & PROTOCOL VALIDATION. Protocol Verification Communication Protocols should be checked for correctness, robustness and performance,
Mutual Exclusion By Shiran Mizrahi. Critical Section class Counter { private int value = 1; //counter starts at one public Counter(int c) { //constructor.
Multiprocessor Synchronization Algorithms ( ) Lecturer: Danny Hendler The Mutual Exclusion problem.
Sept COMP60611 Fundamentals of Parallel and Distributed Systems Lecture 12 The Critical Section problem John Gurd, Graham Riley Centre for Novel.
Distributed Computing 8. Impossibility of consensus Shmuel Zaks ©
Lecture 2: Reasoning with Distributed Programs Anish Arora CSE 6333.
Global State Collection. Global state collection Some applications - computing network topology - termination detection - deadlock detection Chandy-Lamport.
Tele Design of Reactive Systems Summer 2001 Prof. Dr. Stefan Leue Institute for Computer Science Albert-Ludwigs-Universität Freiburg
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.
Concurrency in Distributed Systems: Mutual exclusion.
1 Formal Engineering of Reliable Software LASER 2004 school Tutorial, Lecture1 Natasha Sharygina Carnegie Mellon University.
Distributed Mutual Exclusion
Distributed Computing 5. Snapshot Shmuel Zaks ©
Representing distributed algorithms Why do we need these? Don’t we already know a lot about programming? Well, you need to capture the notions of atomicity,
Correctness requirements. Basic Types of Claims Basic assertions End-state labels Progress-state labels Accept-state labels Never claims Trace assertions.
Concurrency. A process is a program executing on a virtual computer Processor speed and multiplexing of shared resources are ignored Order of thread execution.
The Complexity of Distributed Algorithms. Common measures Space complexity How much space is needed per process to run an algorithm? (measured in terms.
Mutual Exclusion Using Atomic Registers Lecturer: Netanel Dahan Instructor: Prof. Yehuda Afek B.Sc. Seminar on Distributed Computation Tel-Aviv University.
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 --->
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.
Defining Liveness by Bowen Alpern and Fred B. Schneider Presented by Joe Melnyk.
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.
Physical clock synchronization Question 1. Why is physical clock synchronization important? Question 2. With the price of atomic clocks or GPS coming down,
Hwajung Lee. Well, you need to capture the notions of atomicity, non-determinism, fairness etc. These concepts are not built into languages like JAVA,
Hwajung Lee. Why do we need these? Don’t we already know a lot about programming? Well, you need to capture the notions of atomicity, non-determinism,
Several sets of slides by Prof. Jennifer Welch will be used in this course. The slides are mostly identical to her slides, with some minor changes. Set.
Hwajung Lee. Mutual Exclusion CS p0 p1 p2 p3 Some applications are:  Resource sharing  Avoiding concurrent update on shared data  Controlling the.
Hwajung Lee. Mutual Exclusion CS p0 p1 p2 p3 Some applications are: 1. Resource sharing 2. Avoiding concurrent update on shared data 3. Controlling the.
Global State Collection
CIS 720 Lecture 5. Techniques to avoid interference Disjoint variables –If the write set of each process is disjoint from the read and write set of other.
Fault tolerance and related issues in distributed computing Shmuel Zaks GSSI - Feb
Model Checking Lecture 1. Model checking, narrowly interpreted: Decision procedures for checking if a given Kripke structure is a model for a given formula.
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.
Software Systems Verification and Validation Laboratory Assignment 4 Model checking Assignment date: Lab 4 Delivery date: Lab 4, 5.
Presented by: Belgi Amir Seminar in Distributed Algorithms Designing correct concurrent algorithms Spring 2013.
CIS 725 Lecture 2. Finite State Machine Model FSM = (A, S, T, s 0 ) A = set of actions S = set of states s 0 = initial states T = transition relation.
Model Checking Lecture 1: Specification Tom Henzinger.
Hwajung Lee. Mutual Exclusion CS p0 p1 p2 p3 Some applications are:  Resource sharing  Avoiding concurrent update on shared data  Controlling the.
Agenda  Quick Review  Finish Introduction  Java Threads.
Semaphores Chapter 6. Semaphores are a simple, but successful and widely used, construct.
Introduction to distributed systems description relation to practice variables and communication primitives instructions states, actions and programs synchrony.
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
Termination detection
Model and complexity Many measures Space complexity Time complexity
Hwajung Lee ITEC452 Distributed Computing Lecture 8 Representing Distributed Algorithms.
ITEC452 Distributed Computing Lecture 9 Global State Collection
Atomicity, Non-determinism, Fairness
ITEC452 Distributed Computing Lecture 5 Program Correctness
Global state collection
Mutual Exclusion CS p0 CS p1 p2 CS CS p3.
Global State Collection
Semaphores Chapter 6.
Abstraction.
Physical clock synchronization
Linear Time Properties
ITEC452 Distributed Computing Lecture 7 Mutual Exclusion
CIS 720 Lecture 5.
CIS 720 Lecture 5.
Presentation transcript:

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 is caused by an action by an eligible process. action state Initial state transition We reason using interleaving semantics, and assume that concurrent actions are serialized in an arbitrary order A sample computation (or behavior) is ABGHIFL

Correctness criteria Safety properties Bad things never happen Liveness properties Good things eventually happen

Testing vs. Proof Testing: Apply inputs and observe if the outputs satisfy the specifications. Fool proof testing can be painfully slow, even for small systems. Most testing are partial. Proof: Has a mathematical foundation, and is a complete guarantee. Sometimes not scalable.

Testing vs. Proof To test this program, you have to test all possible interleavings. With n processes p 0, p 1, … p n-1, and m steps per process, the number of interleavings is (n.m)! (m!) n The state explosion problem p0p1p2p3 step1 step2 step3

Example: Mutual Exclusion Process 0Process 1 do true  Entry protocol Critical section Exit protocol od Safety properties (1) There is no deadlock (2) At most one process is in its critical section. Liveness property A process trying to enter the CS must eventually succeed. (This is also called the progress property ) CS

Exercise program mutex 1 {two process mutual exclusion algorithm: shared memory model} define busy : shared boolean (initially busy = false} { process 0 }{ process 1 } do true  do busy  skip od ; busy:= true; critical section;critical section busy := false;busy := false{remaining codes}od Does this mutual exclusion protocol satisfy liveness and safety properties?

Safety invariants Invariant means: something meaningful should always hold Example: Total no. of processes in CS ≤ 1 (mutual exclusion problem) Another safety property is Partial correctness. It implies that “If the program terminates then the postcondition will hold.” Consider the following : Safety invariant:  (G0  G1  G2  …  Gk)  postcondition It does not say if the program will terminate. (termination is a liveness property) Total correctness = partial correctness + termination. do G0  S1 [] G1  S1 [] … [] Gk  Sk od

Exercise Starting from the given initial state, devise an algorithm to color the nodes of the graph using the colors 0 and 1, so that no two adjacent nodes have the same color. program colorme {for process P i } define color c  {0, 1} Initially colors are arbitrary do  j : j  neighbor(i) :: (c[i] = c[j])  c[i] := 1 - c[i] od Is the program partially correct ? YES (why?) Does it terminate ? NO (why?) p1 p3p0 p

Liveness properties Eventuality is tricky. There is no need to guarantee when the desired thing will happen, as long as it happens.. Some examples  The message will eventually reach the receiver.  The process will eventually enter its critical section.  The faulty process will be eventually be diagnosed  Fairness (if an action will eventually be scheduled)  The program will eventually terminate.  The criminal will eventually be caught. Absence of liveness cannot be determined from finite prefix of the computation

Proving safety define c1, c2 : channel; { init c1 =  c2 =  } r, t : integer; { init r = 5, t = 5} {program for T } 1 do t > 0  send msg along c1; t := t -1 2[] ¬empty (c2)  rcv msg from c2; t := t + 1 od {program for R } 3 do ¬empty (c1)  rcv msg from c1; r := r+1 4[] r > 0  send msg along c2; r := r-1 od We want to prove the safety property P: P  n1 + n2 ≤ 10 transmitter receiver n1= # of messages in c1 n2= # of messages in c2

Proving safety n1, n2 = # of messages in c1 and c2 respectively. We will establish the following invariant: I  (t ≥ 0)  (r ≥ 0)  (n1 + t + n2 + r = 10) ( I ⇒ P ). Check if I holds after every action. {program for T } 1 do t > 0  send msg along c1; t := t -1 2[] ¬empty (c2)  rcv msg from c2; t := t+1 od {program for R } 3 do ¬empty (c1)  rcv msg from c1; r := r+1 4[] r > 0  send msg along c2; r := r-1 od Use the method of induction Show that I initially holds, and holds after each action.

Proving liveness S1  S2  S3  S4   f  f w1w2w3w4 o w1, w2, w3, w4  WF o WF is a well-founded set whose elements can be ordered by » If there is no infinite chain like w1 » w2 » w3 » w4.., i.e. f(s i ) » f(s i+1 ) » f(s i+2 ).. Global state then the computation will definitely terminate! f is called a variant functionExample?