Defining Programs, Specifications, fault-tolerance, etc.

Slides:



Advertisements
Similar presentations
Modeling issues Book: chapters 4.12, 5.4, 8.4, 10.1.
Advertisements

Tintu David Joy. Agenda Motivation Better Verification Through Symmetry-basic idea Structural Symmetry and Multiprocessor Systems Mur ϕ verification system.
Models of Concurrency Manna, Pnueli.
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:
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.
Hybrid Systems Presented by: Arnab De Anand S. An Intuitive Introduction to Hybrid Systems Discrete program with an analog environment. What does it mean?
Timed Automata.
Self Stabilizing Algorithms for Topology Management Presentation: Deniz Çokuslu.
Rigorous Software Development CSCI-GA Instructor: Thomas Wies Spring 2012 Lecture 13.
Safety and Liveness. Defining Programs Variables with respective domain –State space of the program Program actions –Guarded commands Program computation.
Lecture 2: Reasoning with Distributed Programs Anish Arora CSE 6333.
Termination Detection. Goal Study the development of a protocol for termination detection with the help of invariants.
Termination Detection Part 1. Goal Study the development of a protocol for termination detection with the help of invariants.
© Katz, 2007CS Formal SpecificationsLecture - Temporal logic 1 Temporal Logic Formal Specifications CS Shmuel Katz The Technion.
Ordering and Consistent Cuts Presented By Biswanath Panda.
Synthesis of Fault-Tolerant Distributed Programs Ali Ebnenasir Department of Computer Science and Engineering Michigan State University East Lansing MI.
Enhancing The Fault-Tolerance of Nonmasking Programs Sandeep S. Kulkarni and Ali Ebnenasir Software Engineering and Network Systems Laboratory Computer.
Modeling Software Systems Lecture 2 Book: Chapter 4.
The Complexity of Adding Failsafe Fault-tolerance Sandeep S. Kulkarni Ali Ebnenasir.
Automatic Synthesis of Fault-Tolerance Ali Ebnenasir Software Engineering and Network Systems Laboratory Computer Science and Engineering Department Michigan.
CS 603 Communication and Distributed Systems April 15, 2002.
1 Formal Engineering of Reliable Software LASER 2004 school Tutorial, Lecture1 Natasha Sharygina Carnegie Mellon University.
R R R Fault Tolerant Computing. R R R Acknowledgements The following lectures are based on materials from the following sources; –S. Kulkarni –J. Rushby.
Antoine Girard VAL-AMS Project Meeting April 2007 Behavioral Metrics for Simulation-based Circuit Validation.
Minimum Spanning Trees. Subgraph A graph G is a subgraph of graph H if –The vertices of G are a subset of the vertices of H, and –The edges of G are a.
Software Testing Sudipto Ghosh CS 406 Fall 99 November 9, 1999.
Regular Model Checking Ahmed Bouajjani,Benget Jonsson, Marcus Nillson and Tayssir Touili Moran Ben Tulila
Linear and Branching Time Safety, Liveness, and Fairness
UPPAAL Ghaith Haddad. Introduction UPPAAL is a tool for modeling, validation and verification of real-time systems. Appropriate for systems that can be.
Selected topics in distributed computing Shmuel Zaks
Fault-containment in Weakly Stabilizing Systems Anurag Dasgupta Sukumar Ghosh Xin Xiao University of Iowa.
CS4231 Parallel and Distributed Algorithms AY 2006/2007 Semester 2 Lecture 10 Instructor: Haifeng YU.
Centralized mutual exclusion Problem : What if the coordinator fails? Solution : Elect a new one.
CIS 842: Specification and Verification of Reactive Systems Lecture Specifications: Sequencing Properties Copyright , Matt Dwyer, John Hatcliff,
Diffusing Computation. Using Spanning Tree Construction for Solving Leader Election Root is the leader In the presence of faults, –There may be multiple.
Review for Exam 2. Topics included Deadlock detection Resource and communication deadlock Graph algorithms: Routing, spanning tree, MST, leader election.
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
Fault-containment in Weakly Stabilizing Systems Anurag Dasgupta Sukumar Ghosh Xin Xiao University of Iowa.
Markov Chains and Random Walks. Def: A stochastic process X={X(t),t ∈ T} is a collection of random variables. If T is a countable set, say T={0,1,2, …
CS 395T Game-Based Verification of Contract Signing Protocols.
CSE 812. Outline Defining Programs, specifications, faults, etc. Safety and Liveness based on the work of Alpern and Schneider Defining fault-tolerance.
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 --->
Autonomic distributed systems. 2 Think about this Human population x10 9 computer population.
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.
Diffusing Computation. Using Spanning Tree Construction for Solving Leader Election Root is the leader In the presence of faults, –There may be multiple.
Hwajung Lee. One of the selling points of a distributed system is that the system will continue to perform even if some components / processes fail.
Stabilization Presented by Xiaozhou David Zhu. Contents What-is Motivation 3 Definitions An Example Refinements Reference.
CIS 842: Specification and Verification of Reactive Systems Lecture INTRO-Examples: Simple BIR-Lite Examples Copyright 2004, Matt Dwyer, John Hatcliff,
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
Safety and Liveness. Recall Program –State space Program computation –Of the form Consider the set of all program computations.
Chapter 8 Asynchronous System Model by Mikhail Nesterenko “Distributed Algorithms” by Nancy A. Lynch.
CS 542: Topics in Distributed Systems Self-Stabilization.
1 Fault tolerance in distributed systems n Motivation n robust and stabilizing algorithms n failure models n robust algorithms u decision problems u impossibility.
Hwajung Lee.  Technique for spontaneous healing.  Forward error recovery.  Guarantees eventual safety following failures. Feasibility demonstrated.
Program Correctness. The designer of a distributed system has the responsibility of certifying the correctness of the system before users start using.
Presented by: Belgi Amir Seminar in Distributed Algorithms Designing correct concurrent algorithms Spring 2013.
Superstabilizing Protocols for Dynamic Distributed Systems Authors: Shlomi Dolev, Ted Herman Presented by: Vikas Motwani CSE 291: Wireless Sensor Networks.
ITEC452 Distributed Computing Lecture 15 Self-stabilization Hwajung Lee.
1 Chapter 11 Global Properties (Distributed Termination)
Design of Nonmasking Tree Algorithm Goal: design a tree construction protocol systematically by constructing its invariant and fault-span.
Design of Tree Algorithm Objectives –Learning about satisfying safety and liveness of a distributed program –Apply the method of utilizing invariants and.
Introduction to distributed systems description relation to practice variables and communication primitives instructions states, actions and programs synchrony.
Fundamentals of Fault-Tolerant Distributed Computing In Asynchronous Environments Paper by Felix C. Gartner Graeme Coakley COEN 317 November 23, 2003.
Distributed Systems Lecture 6 Global states and snapshots 1.
“Designing Masking Fault Tolerance via Nonmasking Fault Tolerance“ Oğuzhan YILDIRIM – Erkin GÜVEL Boğaziçi University Computer Engineering Department
Automatic Verification
Presented By: Raquel Whittlesey-Harris 12/04/02
Presentation transcript:

Defining Programs, Specifications, fault-tolerance, etc.

Recall Program –State space Program computation –Of the form Specification consists of a set of infinite sequences of states

It turns out that the specification considered here are general. Often specifications in practice have some additional characteristics

Fusion closure A spec is fusion closed for any finite sequences ,  and infinite sequences ,  and state x, the following condition is satisfied –if  x  spec   x  spec –Then  x  spec   x  spec

Suffix Closure A spec is suffix closed for any finite sequence  and infinite sequence  –if  spec –Then  spec For subsequent discussion, we will assume that specification is suffix closed & fusion closed

Safety Specification  :  SafetySpec : (  :  is a prefix of    ::   SafetySpec) Safety specification can be modeled in terms of the set of `bad prefixes’ –Intuition: Consider a computation  that violates safety. Identify the prefix . –Do this for each computation that violates safety –Collection of these prefixes can be used to model safety

Safety Specification While the safety specification we considered is general, often more concise specifications suffice –Example 1: safety modeled as a set of bad states E.g., the value of x should never be greater than 3 –How can such a safety specification be modeled as a set of bad prefixes?

Safety Specification Example 2: –Safety is modeled as a set of bad transitions E,g., the value of x should never increase We will use this representation for subsequent work –More compact –General enough for many applications –If specification is fusion closed and suffix closed then safety can always be represented as a set of bad transitions

State Predicate State Space S p identifies the set of all states of a program –A state predicate is a subset of the state space For example, consider a program with one variable x, say with domain –x > 5 is an example of state predicate –Corresponds to {6, 7, 8, 9, 10}

More concise program representation A program is modeled in terms of a set of variables and a set of guarded commands –The domain of variables can be used to determine state space –Each guarded command is of the form guard  statement –guard is a Boolean variable over program variables –I.e., guard is a state predicate –Statement updates program variables

Example Consider Peterson’s mutual exclusion example –Variables st 1, st 2 : {n, t, c} turn : {0, 1}

Example Climate control system –Variables dt, pt : { } sync : {0, 1} –Action (example) dt > 60  sync = 0  dt = dt – 1;

Program Computation A sequence is a computation of program p iff for each s i, i > 0, –s i is obtained by executing some action of p that is enabled in s i –1 An action is enabled in a state iff its guard evaluates to true in that state

Fairness Sometimes, we also introduce a fairness condition –A sequence is a computation of program p iff for each s i, i > 0, s i is obtained by executing some action of p that is enabled in s i –1 If an action of p is continuously enabled in this sequence then it will be eventually executed

Closure We say that a predicate S is closed in program p iff –Starting from any state where S is true execution of any enabled action results in a state in S Note that S is closed in p iff (p satisfies closed(S) from all states)

Program Correctness Typically, –A program is correct if all its computations starting from initial state are in the specification What if we want to talk about correctness of programs when we start observing it in the middle?

Invariant We say that state predicate S is an invariant of p iff the following condition is satisfied –S is closed in p –Every computation of p that starts from a state in p is in the specification (Alternatively, every computation of p that starts from a state in p satisfies its specification) –If the specification is suffix closed and fusion closed and the program is correct from some initial states, then the set of reachable states from initial states is an invariant of the program

Invariant p

Example of Invariant For climate control system, –sync = 1  dt = pt is an invariant

Faults Also modeled as a set of transitions –(or guarded commands) –Recall the example from first class of going from one location to another –Effect of faults

Fault Span Let T be a state predicate T is a f-span of p from S iff the following conditions are satisfied –S  T (same as S  T) –T is closed in p [] f

Fault-Span p/f f p Fault span is the boundary upto which faults can perturb the program

Computation in the presence of faults A computation of p –In every step, execute a transition of p A computation of p[]f –In every step, execute a transition of p or a transition of f –Number of fault transitions in any computation is finite –Fairness??

Levels of Fault-Tolerance Irrespective of level of fault-tolerance, the program satisfies its specification from its invariant Levels are determined based on behavior in fault span

Failsafe Fault-tolerance p is failsafe f-tolerant to spec from S iff –p satisfies spec from S –There exists T such that T is a f-span of p from S Every computation of p[]f that starts from T satisfies the safety of spec –Recall spec can be expressed as an intersection of safety and liveness. In the presence of faults, the failsafe program satisfies the safety part of it.

Failsafe Fault-Tolerance p/f f p Computations here meet safety specification

Nonmasking Fault-Tolerance p is failsafe f-tolerant to spec from S iff –p satisfies spec from S –There exists T such that T is a f-span of p from S Every computation of p[]f that starts from T satisfies the safety of spec Every computation of p[]f that starts from T eventually reaches a state in S

Nonmasking Fault-Tolerance p/f f p Computations here eventually reach S, safety may be violated before reaching S S

Masking Fault-Tolerance p is failsafe f-tolerant to spec from S iff –p satisfies spec from S –There exists T such that T is a f-span of p from S Every computation of p[]f that starts from T eventually reaches a state in S –Thus, a computation of p has a suffix that satisfies its specification

Masking Fault-Tolerance p/f f p Computations here meet safety specification and eventually reach S S

Design of Nonmasking Tree Algorithm Goal: design a tree construction protocol systematically by constructing its invariant and fault-span

Ideal State Each process j maintains a variable P.j. P.j denotes the parent of j in the tree. Each process also has a unique ID In an ideal state the graph imposed by the parent relation forms a tree

Faults Can fail or repair a process –Goal: Reconstruct the tree with the available processes

Due to faults, we may have Unrooted trees –Because some node’s parent has failed Multiple (rooted) trees –For example, when a node is repaired, it may form a tree by itself Observe that there are no cycles. In other words, in the presence of faults, a cycle is not created. –We may want to preserve this during reconstruction. –I.e., this constraint should be in the fault-span

Predicates for Fault-Span (1) The graph imposed by the parent relation is a forest

Approach for Reconstruction Dealing with unrooted trees –Somehow the nodes in unrooted trees should be informed so that they know that they are in an unrooted tree –Approach: Introduce a variable color (col) Green = node thinks it is in rooted tree Red = node thinks it is in unrooted tree

Action (1) col.j = green  (P.j  N.j  col.(P.j) = red)  col.j = red

Predicate in Invariant What is it that we would like to have true if this action is executed (P.j  N.j  col.(P.j) = red)  col.j = red

Predicate in Fault-Span (2) The graph imposed by the parent relation is a forest  col.j = red  (P.j  N.j  col.(P.j) = red)

Note Observe that Action (1) is aimed at correcting a predicate in the invariant –Must ensure that during correction, the fault- span constraints are not violated

Predicate in Invariant (P.j  N.j  col.(P.j) = red)  col.j = red col.j = green

Action (2) When should a node set its color to green –Need to ensure that constraints of fault-span are not violated –Need to ensure that constraints of previous predicates in invariant are not violated

Action (2) col.j = red  (????)  col.j = green Choose ???? so that this action does not affect fault-span predicate/previous predicates in invariant