Defining Programs, Specifications, fault-tolerance, etc.
description
Transcript of Defining Programs, Specifications, fault-tolerance, etc.
![Page 1: Defining Programs, Specifications, fault-tolerance, etc.](https://reader035.fdocuments.in/reader035/viewer/2022070410/56814605550346895db31165/html5/thumbnails/1.jpg)
Defining Programs, Specifications, fault-tolerance,
etc.
![Page 2: Defining Programs, Specifications, fault-tolerance, etc.](https://reader035.fdocuments.in/reader035/viewer/2022070410/56814605550346895db31165/html5/thumbnails/2.jpg)
Recall
• Program – State space
• Program computation– Of the form
<s0, s1, s2, …>
• Specification consists of a set of infinite sequences of states
![Page 3: Defining Programs, Specifications, fault-tolerance, etc.](https://reader035.fdocuments.in/reader035/viewer/2022070410/56814605550346895db31165/html5/thumbnails/3.jpg)
• It turns out that the specification considered here are general. Often specifications in practice have some additional characteristics
![Page 4: Defining Programs, Specifications, fault-tolerance, etc.](https://reader035.fdocuments.in/reader035/viewer/2022070410/56814605550346895db31165/html5/thumbnails/4.jpg)
Fusion closure
• A spec is fusion closed for any finite sequences , and infinite sequences , and state x, the following condition is satisfied– if xspec xspec– Then xspec xspec
![Page 5: Defining Programs, Specifications, fault-tolerance, etc.](https://reader035.fdocuments.in/reader035/viewer/2022070410/56814605550346895db31165/html5/thumbnails/5.jpg)
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
![Page 6: Defining Programs, Specifications, fault-tolerance, etc.](https://reader035.fdocuments.in/reader035/viewer/2022070410/56814605550346895db31165/html5/thumbnails/6.jpg)
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
![Page 7: Defining Programs, Specifications, fault-tolerance, etc.](https://reader035.fdocuments.in/reader035/viewer/2022070410/56814605550346895db31165/html5/thumbnails/7.jpg)
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?
![Page 8: Defining Programs, Specifications, fault-tolerance, etc.](https://reader035.fdocuments.in/reader035/viewer/2022070410/56814605550346895db31165/html5/thumbnails/8.jpg)
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
![Page 9: Defining Programs, Specifications, fault-tolerance, etc.](https://reader035.fdocuments.in/reader035/viewer/2022070410/56814605550346895db31165/html5/thumbnails/9.jpg)
State Predicate
• State Space Sp 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 0..10– x > 5 is an example of state predicate– Corresponds to {6, 7, 8, 9, 10}
![Page 10: Defining Programs, Specifications, fault-tolerance, etc.](https://reader035.fdocuments.in/reader035/viewer/2022070410/56814605550346895db31165/html5/thumbnails/10.jpg)
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
![Page 11: Defining Programs, Specifications, fault-tolerance, etc.](https://reader035.fdocuments.in/reader035/viewer/2022070410/56814605550346895db31165/html5/thumbnails/11.jpg)
Example
• Consider Peterson’s mutual exclusion example– Variables
• st1, st2 : {n, t, c}
• turn : {0, 1}
![Page 12: Defining Programs, Specifications, fault-tolerance, etc.](https://reader035.fdocuments.in/reader035/viewer/2022070410/56814605550346895db31165/html5/thumbnails/12.jpg)
Example
• Climate control system– Variables
• dt, pt : {60 .. 90}
• sync : {0, 1}
– Action (example)• dt > 60 sync = 0 dt = dt – 1;
![Page 13: Defining Programs, Specifications, fault-tolerance, etc.](https://reader035.fdocuments.in/reader035/viewer/2022070410/56814605550346895db31165/html5/thumbnails/13.jpg)
Program Computation
• A sequence <s0, s1, … > is a computation of program p iff for each si, i > 0,
– si is obtained by executing some action of p that is enabled in si –1
• An action is enabled in a state iff its guard evaluates to true in that state
![Page 14: Defining Programs, Specifications, fault-tolerance, etc.](https://reader035.fdocuments.in/reader035/viewer/2022070410/56814605550346895db31165/html5/thumbnails/14.jpg)
Fairness
• Sometimes, we also introduce a fairness condition– A sequence <s0, s1, … > is a computation of
program p iff for each si, i > 0,
• si is obtained by executing some action of p that is enabled in si –1
• If an action of p is continuously enabled in this sequence then it will be eventually executed
![Page 15: Defining Programs, Specifications, fault-tolerance, etc.](https://reader035.fdocuments.in/reader035/viewer/2022070410/56814605550346895db31165/html5/thumbnails/15.jpg)
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)
![Page 16: Defining Programs, Specifications, fault-tolerance, etc.](https://reader035.fdocuments.in/reader035/viewer/2022070410/56814605550346895db31165/html5/thumbnails/16.jpg)
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?
![Page 17: Defining Programs, Specifications, fault-tolerance, etc.](https://reader035.fdocuments.in/reader035/viewer/2022070410/56814605550346895db31165/html5/thumbnails/17.jpg)
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
![Page 18: Defining Programs, Specifications, fault-tolerance, etc.](https://reader035.fdocuments.in/reader035/viewer/2022070410/56814605550346895db31165/html5/thumbnails/18.jpg)
Invariant
p
![Page 19: Defining Programs, Specifications, fault-tolerance, etc.](https://reader035.fdocuments.in/reader035/viewer/2022070410/56814605550346895db31165/html5/thumbnails/19.jpg)
Example of Invariant
• For climate control system, – sync = 1 dt = pt is an invariant
![Page 20: Defining Programs, Specifications, fault-tolerance, etc.](https://reader035.fdocuments.in/reader035/viewer/2022070410/56814605550346895db31165/html5/thumbnails/20.jpg)
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
![Page 21: Defining Programs, Specifications, fault-tolerance, etc.](https://reader035.fdocuments.in/reader035/viewer/2022070410/56814605550346895db31165/html5/thumbnails/21.jpg)
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
![Page 22: Defining Programs, Specifications, fault-tolerance, etc.](https://reader035.fdocuments.in/reader035/viewer/2022070410/56814605550346895db31165/html5/thumbnails/22.jpg)
Fault-Span
p/ff
p
Fault span is the boundary upto which faults can perturb the program
![Page 23: Defining Programs, Specifications, fault-tolerance, etc.](https://reader035.fdocuments.in/reader035/viewer/2022070410/56814605550346895db31165/html5/thumbnails/23.jpg)
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??
![Page 24: Defining Programs, Specifications, fault-tolerance, etc.](https://reader035.fdocuments.in/reader035/viewer/2022070410/56814605550346895db31165/html5/thumbnails/24.jpg)
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
![Page 25: Defining Programs, Specifications, fault-tolerance, etc.](https://reader035.fdocuments.in/reader035/viewer/2022070410/56814605550346895db31165/html5/thumbnails/25.jpg)
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.
![Page 26: Defining Programs, Specifications, fault-tolerance, etc.](https://reader035.fdocuments.in/reader035/viewer/2022070410/56814605550346895db31165/html5/thumbnails/26.jpg)
Failsafe Fault-Tolerance
p/ff
p
Computations here meet safety specification
![Page 27: Defining Programs, Specifications, fault-tolerance, etc.](https://reader035.fdocuments.in/reader035/viewer/2022070410/56814605550346895db31165/html5/thumbnails/27.jpg)
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
![Page 28: Defining Programs, Specifications, fault-tolerance, etc.](https://reader035.fdocuments.in/reader035/viewer/2022070410/56814605550346895db31165/html5/thumbnails/28.jpg)
Nonmasking Fault-Tolerance
p/ff
p
Computations here eventually reach S, safety may be violated before reaching S
S
![Page 29: Defining Programs, Specifications, fault-tolerance, etc.](https://reader035.fdocuments.in/reader035/viewer/2022070410/56814605550346895db31165/html5/thumbnails/29.jpg)
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
![Page 30: Defining Programs, Specifications, fault-tolerance, etc.](https://reader035.fdocuments.in/reader035/viewer/2022070410/56814605550346895db31165/html5/thumbnails/30.jpg)
Masking Fault-Tolerance
p/ff
p
Computations here meet safety specification and eventually reach S
S
![Page 31: Defining Programs, Specifications, fault-tolerance, etc.](https://reader035.fdocuments.in/reader035/viewer/2022070410/56814605550346895db31165/html5/thumbnails/31.jpg)
Design of Nonmasking Tree Algorithm
• Goal: design a tree construction protocol systematically by constructing its invariant and fault-span
![Page 32: Defining Programs, Specifications, fault-tolerance, etc.](https://reader035.fdocuments.in/reader035/viewer/2022070410/56814605550346895db31165/html5/thumbnails/32.jpg)
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
![Page 33: Defining Programs, Specifications, fault-tolerance, etc.](https://reader035.fdocuments.in/reader035/viewer/2022070410/56814605550346895db31165/html5/thumbnails/33.jpg)
Faults
• Can fail or repair a process– Goal: Reconstruct the tree with the available
processes
![Page 34: Defining Programs, Specifications, fault-tolerance, etc.](https://reader035.fdocuments.in/reader035/viewer/2022070410/56814605550346895db31165/html5/thumbnails/34.jpg)
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
![Page 35: Defining Programs, Specifications, fault-tolerance, etc.](https://reader035.fdocuments.in/reader035/viewer/2022070410/56814605550346895db31165/html5/thumbnails/35.jpg)
Predicates for Fault-Span (1)
• The graph imposed by the parent relation is a forest
![Page 36: Defining Programs, Specifications, fault-tolerance, etc.](https://reader035.fdocuments.in/reader035/viewer/2022070410/56814605550346895db31165/html5/thumbnails/36.jpg)
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
![Page 37: Defining Programs, Specifications, fault-tolerance, etc.](https://reader035.fdocuments.in/reader035/viewer/2022070410/56814605550346895db31165/html5/thumbnails/37.jpg)
Action (1)
col.j = green (P.j N.j col.(P.j) = red)
col.j = red
![Page 38: Defining Programs, Specifications, fault-tolerance, etc.](https://reader035.fdocuments.in/reader035/viewer/2022070410/56814605550346895db31165/html5/thumbnails/38.jpg)
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
![Page 39: Defining Programs, Specifications, fault-tolerance, etc.](https://reader035.fdocuments.in/reader035/viewer/2022070410/56814605550346895db31165/html5/thumbnails/39.jpg)
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)
![Page 40: Defining Programs, Specifications, fault-tolerance, etc.](https://reader035.fdocuments.in/reader035/viewer/2022070410/56814605550346895db31165/html5/thumbnails/40.jpg)
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
![Page 41: Defining Programs, Specifications, fault-tolerance, etc.](https://reader035.fdocuments.in/reader035/viewer/2022070410/56814605550346895db31165/html5/thumbnails/41.jpg)
Predicate in Invariant
• (P.j N.j col.(P.j) = red) col.j = red
• col.j = green
![Page 42: Defining Programs, Specifications, fault-tolerance, etc.](https://reader035.fdocuments.in/reader035/viewer/2022070410/56814605550346895db31165/html5/thumbnails/42.jpg)
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
![Page 43: Defining Programs, Specifications, fault-tolerance, etc.](https://reader035.fdocuments.in/reader035/viewer/2022070410/56814605550346895db31165/html5/thumbnails/43.jpg)
Action (2)
col.j = red (????)
col.j = green
Choose ???? so that this action does not affect fault-span predicate/previous predicates in invariant