1 / 44

Safety and Liveness

Safety and Liveness. Defining Programs. Variables with respective domain State space of the program Program actions Guarded commands Program computation <s 0 , s 1 , s 2 , …> (s j-1 , s j ) is permitted by program actions Consider set of all program computations

connie
Download Presentation

Safety and Liveness

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Safety and Liveness

  2. Defining Programs • Variables with respective domain • State space of the program • Program actions • Guarded commands • Program computation • <s0, s1, s2, …> • (sj-1, sj) is permitted by program actions • Consider set of all program computations • Could depend upon the notion of fairness

  3. Program Correctness • How do we define that a program is correct with respect to its specification? • Intuition: A program is correct if all its computations are in the specification • For above intuition to work, the specification should be the set of acceptable sequences of program states • Note that the program does not have to exhibit all behaviors in the specification • It just should not exhibit anything that it is not permitted by the specification

  4. Hence, • From now on, let specification be a set of infinite sequences of states

  5. Example • Coke and Pepsi vending machine • Specification: pressing a button results in dispensation of a Coke or Pepsi

  6. Consider Programs Program 1 ButtonPressed  Dispense Coke Program 2 ButtonPressed  Dispense Pepsi Program 3 ButtonPressed  Dispense Coke ButtonPressed  Dispense Pepsi

  7. Consider Programs Program 4 ButtonPressed  Dispense Sprite

  8. Observations about Programs and Specifications • Suppose that you do not have access to code of program P. You can only observe its behavior. • Observed behavior is one state at a time • Observed behavior is finite • Looking at a finite prefix, we can neversay that the specification is satisfied • We may be able to say that the specification is NOT satisfied.

  9. Specification 1 • Vending machine only dispenses coke or pepsi • Consider the behavior • c,p,c,p,s,c,p, … • Suppose a program behavior violates a specification, will you always be able to detect it at some finite point? • What do we mean that we detected safety violation at a finite point? • It means that no matter what future states are the specification cannot be satisfied by that sequence. • This is the intuition behind safety specification.

  10. Specification 2 • Vending machine is guaranteed to dispense pepsi • Consider the finite behavior • c,c,c,c,s,s,7 • Given any finite behavior, can you say that the specification cannot be satisfied • This is the intuition behind liveness specification

  11. Specification 2 continued • Suppose the infinite sequence were • c,c,c,c,c, … • Even though this sequence does not satisfy specification 2, we cannot conclude this at any finite point.

  12. Specification 3 • Dispense only coke or pepsi and that eventually dispense pepsi • Is this safety, liveness, both or neither • This color is black • This color is white • This color is neither black nor white although it is a combination of the two

  13. Safety and Liveness • Safety • Intuition: Nothing bad happens • Intuition: If something bad happens, it cannot be fixed • Intuition: if a sequence violates specification then it does so at some finite point after which it cannot be fixed. •  : SafetySpec : ( :  is a prefix of    ::  SafetySpec)

  14. Safety and Liveness • Liveness • Intuition: Something good happens eventually • Intuition: No matter what has happened so far, the specification can be met •  :  is finite sequence of states:  ::   LivenessSpec

  15. Examples of Properties • Invariant (S) : Predicate S is true in every state • Closed (S) : If predicate S is true in some state, it will remain true in the next • P Leads to Q : If P is ever true in some state then Q will be true in that or some future state • P Converges to Q : Closed(P) and Closed(Q) and P leads to Q

  16. P Converges to Q : Closed(P) and Closed(Q) and P leads to Q • Consider sequenec • P, p, p, … • Violates specificatin • Cannot say that at any finite point • Not a safety specification • Is there any finite prefix alpha such that alpha cannot be extended to satisfy the specification?

  17. To show that P conv to Q is not a safety property • Create a sequence that violates P converges to Q such that • At finite point, you cannot say that spec is violated • (P&NotQ), (P&NotQ) …

  18. To show that P converges to Q is not a liveness property • Find some alpha such that it cannot be extended to satisfy the specification • P, NotP,

  19. Specification 3 • For vending machine: • For every 10 consecutive button pressed, dispense at least 4 coke and at least 4 pepsi • This is a safety specification

  20. c • Consider sequence • C, c, c, c, c, c, c

  21. Specification 4 • Pepsi must be dispensed at least once in 10 steps

  22. Specification 4 • After some point, the machine will only dispense pepsi • This is a liveness specification

  23. Sf1 & Sf2 • Given Sf1, Sf2 is a safety specificaiton • Show Sf1 & Sf2 is a safety specification • For all sigma : sigma not in Sf1 & Sf2 : • Take any sigma not in Sf1 and Sf2 • Case 1: sigma not in Sf1 • Case 2: sigma not in Sf2

  24. Given •  : Sf1 : ( :  is a prefix of    ::  Sf1) •  : Sf2 : ( :  is a prefix of    ::  Sf2) • To prove •  : Sf1 & Sf2 : ( :  is a prefix of    ::  Sf1 & Sf2)

  25. Case 1 • Sigma not in Sf1 • There exists alpha : for all beta : • Alpha beta is not in sf1 ==> there exists alpha : for all beta : alpha beta is not in sf1 & sf2 Same for Case 2 : Completes proof for showing that sf1 & sf2 is a safety property

  26. Observation • Some properties are neither safety properties nor liveness properties. They appear to be a combination of the two. • Goal: prove that any property can be expressed as an intersection of a safety property and a liveness property

  27. Spec1 = Always dispense coke or pepsi • Spec2 = always dispense coke • Spec3 = Always dispense coke and pepsi and eventually dispense pepsi • Spec4 = dispense coke and pepsi in an alternating manner • Spec4 subset of spec1 • Spec2 is not a subset of spec4 and vice versa • Spec2 is a subset of spec1 but not of spec3 • Spec3 is a subset of spec1

  28. Manipulation of Safety/Liveness Properties • Intersection of safety and liveness properties • Step 1: Intersection of any number of safety properties is a safety property • Step 2: Given a specification, spec, find the smallest safety specification sf such that spec  sf • Step 3: spec = sf  (spec  (Sw – sf)) • Step 4: (spec  (Sw – sf)) is a liveness specification

  29. Let sigma be some sequence • Suppose spec = { sigma }, spec only contains one sequence

  30. Towards Proving spec = safety  liveness • Sw denotes the set of all computations •  Sw denotes the set of all computations with prefix  • (Sw -  Sw) is a safety specification

  31. Towards Proving spec = safety  liveness • Consider (infinitely many) safety properties sf1, sf2, … • Is the union of them a safety specification? • Is the intersection of them a safety specification?

  32. Towards Proving spec = safety  liveness • Let spec be the given specification • Consider the set of safety properties sf1, sf2, … such that • spec  sfi • Consider the intersection of these safety properties • Let sf denote this intersection • Observe: spec  sf • sf is a safety specification

  33. Properties of sf • Consider a sequence   sf – spec • Let  be any prefix of  • There must exist  such that   spec • If not spec (sf  (Sw -  Sw)), which is a safety specification • This is a contradiction as sf is supposed to smallest safety specification containing spec

  34. Towards Proving spec = safety  liveness • spec = sf  (spec  (Sw – sf)) Safety specification Liveness specification

  35. To prove • sf  (spec  (Sw – sf)) = Sf  spec  ( sf  (Sw – sf)) = spec

  36. To show that (spec  (Sw – sf)) is a liveness specification: • For any , some extension of  is in (spec  (Sw – sf)) • Let  be any infinite extension of  • Case 1:  spec : trivial • Case 2:  (Sw – sf) : trivial • Case 3:  sf – spec: • Every prefix of  has an extension that satisfies spec • By construction  is a prefix of 

  37. (x > 0) converges to (x > 5) • (x > 0) is closed, i.e., if x is 1 or higher, x can never become 0 or negative • (x > 5) is closed • If (x > 0) is reached then eventually (x > 5) would be reached • Safety specification • x is always equal to 10 (not a superset of converges because • X is always greater than 0 (superset of converges) • Closed (x > 0) (superset of converges) • Closed (x > 5) (superset of converges) • Closed (x > 0) & Closed (x > 5) (superset of converges), … • This is the smallest safety specification for converges

  38. What happens if the sequence satisfies • Closed (x > 0) & Closed (x > 5) • But violates (x > 0) congerges to (x > 5) • For any such sequence, at a finite point, there is a hope of satisfying the (x > 0) congerges to (x > 5)

  39. Topology based explanation

  40. Use of Safety and Liveness in Designing Programs • Techniques for satisfying safety • Invariants • Closure We will discuss these next. • Techniques for satisfying liveness • Variant functions We will discuss these briefly

  41. Revisiting Fairness Properties • What observation can you make about • Weak fairness • Strong fairness

  42. Some Comments about this Framework • Safety liveness framework discussed here relies on certain assumptions • A computation is correct if is included in the specification • More specifically, correctness of one computation does not depend on other computations • In other words, whether a computation satisfies the specification or not can be deduced solely from the computation and the specification

  43. Comments (Continued) • In some situations, this does not work • Example: Average response time for a request is 10 steps

More Related