Safety and Liveness Defining Programs Variables with respective - - PowerPoint PPT Presentation

Safety and Liveness

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

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

Hence,

• From now on, let specification be a set
• f infinite sequences of states

Example

• Coke and Pepsi vending machine

– Specification: pressing a button results in dispensation of a Coke or Pepsi

Consider Programs

Program 1 ButtonPressed  Dispense Coke Program 2 ButtonPressed  Dispense Pepsi Program 3 ButtonPressed  Dispense Coke ButtonPressed  Dispense Pepsi

Consider Programs

Program 4 ButtonPressed  Dispense Sprite

Observations about Programs and Specifications

• Suppose that you do not have access to code
• f 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 never say

that the specification is satisfied

• We may be able to say that the specification

is NOT satisfied.

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.

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

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.

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

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)

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

Recalling weak fairness and strong fairness

• Are these safety properties?
• Are these liveness properties?
• What is a good fairness property?

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

• 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?

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) …

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,

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

Specification 3

• Consider sequence

– C, c, c, c, c, c, c

Specification 4

• Pepsi must be dispensed at least once

in 10 steps

Specification 4

• After some point, the machine will only

dispense pepsi

• This is a liveness specification

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

• Given

– ∀σ : σ∉Sf1 : (∃α : α is a prefix of σ ∧ ∀β :: αβ ∉Sf1) – ∀σ : σ∉Sf2 : (∃α : α is a prefix of σ ∧ ∀β :: αβ ∉Sf2)

• To prove

– ∀σ : σ∉Sf1 & Sf2 : (∃α : α is a prefix of σ ∧ ∀β :: αβ ∉Sf1 & Sf2)

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

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

• 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

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

• Let sigma be some sequence
• Suppose spec = { sigma }, spec only

contains one sequence

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

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?

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

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

Towards Proving spec = safety ∧ liveness

• spec = sf ∩

(spec ∪ (Sw – sf))

Safety specification Liveness specification

• To prove
• sf ∩

(spec ∪ (Sw – sf)) = Sf ∩ spec ∪ ( sf ∩ (Sw – sf)) = spec

• 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 σ

• (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

• 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)

Topology based explanation

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

Revisiting Fairness Properties

• What observation can you make about

– Weak fairness – Strong fairness

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

Comments (Continued)

• In some situations, this does not work

– Example: Average response time for a request is 10 steps