Chapter 3: Linear-Time Properties

Chapter 3: Linear-Time Properties Prof. Ali Movaghar Verification of Reactive Systems

Outline n n To verify the transition system model of the system under consideration, we need to specify the property of interest. We introduce how the linear-time properties can be specified and then model-checked in an automated manner. 2

Deadlock n Sequential programs that are not subject to divergence (i.e., endless loops) have a terminal state. n A terminal state is a state without any outgoing transition. 3

Deadlock(Con.) n In contrast for parallel systems, computations typically do not terminate. n In theses systems, terminal states are undesirable and mostly represent a design error. n Or these terminal states may indicate a deadlock! 4

Deadlock(Con.) n n A deadlock occurs if the complete system is in a terminal state, although at least one component is in a (local) non-terminal state. In other words, the entire system has come to a halt, whereas at least one component has the possibility to continue. n A typical deadlock scenario occurs when components mutually waits for each other to progress. 5

Deadlock(Con.) n Example 3.1: consider the parallel composition of two transition systems TrLight 1 TrLight 2 modeling the traffic lights of two intersecting roads: 6

Deadlock(Con.) n Traffic lights are modeled by following transition systems: n They are synchronized by means of the actions α and β that indicate the change of light. 7

Deadlock(Con.) n One trivial error is to let both traffic lights start with a red light which results in a deadlock: n While the first traffic light is waiting to be synchronized on action α, the second light is waiting to be synchronized with action β. 8

Deadlock(Con.) n Example 3.2: Dining philosophers : n The philosophers life consists of thinking and eating. n To eat, a philosopher needs two chopsticks. 9

Deadlock(Con.) n At any time only one of two neighboring philosophers can eat. n A deadlock occurs when all philosophers posses a single chopstick. n The problem is to design a protocol such that the complete system is deadlock-free. 10

Deadlock(Con.) n Deadlock-free means At least one philosopher can eat and think infinitely often. n Additionally, a fair solution may be required with each philosopher being able to think and eat infinitely often. n This characteristic is called freedom of individual starvation. 11

Deadlock(Con.) n The following obvious design cannot ensure deadlock freedom. n Assume the philosophers and the chopsticks are numbered from 0 to 4. n Assume the minus operation be modulo 5, e.g. i-1 for i=0 denotes 4, and so on. 12

Deadlock(Con.) n Philosopher i has stick i on his left and stick i-1 on his right side. n Action request i,i express that stick i is picked up by philosopher i. n Accordingly request i-1,i denotes the action by means of which philosopher i picks up the (i-1)th stick. n The actions release i,i and release i-1,i have a corresponding meaning. 13

Deadlock(Con.) n The behavior of philosopher i and sticks are modeled by : 14

Deadlock(Con.) n In these LTSs, the solid arrows depict the synchronizations can occur between the i- th stick (called Stick i ) and philosopher i (called Phil i ), while dashed arrows refer to communications between phil i and i-1th stick. n The complete system is : Phil 4 Stick 3 Phil 3 Stick 2 Phil 2 Stick 1 Phil 1 Stick 0 Phil 0 Stick 4 15

Deadlock(Con.) n This design leads to a deadlock situation if all philosophers pick up their left stick at the same time. n The corresponding execution leads from the initial state : <think 4,avail 3,think 3,avail 2,think 2,avail 1,think 1,avail 0,think 0,avail 4 > by action sequence request 4, request 3, request 2, request 1, request 0 to the terminal state: <wait 4,0,occ 4,4,wait 3,4,occ 3,3,wait 2,3,occ 2,2,wait 1,2,occ 1,1,wait 0,1,occ 0,0 > 16

Deadlock(Con.) n A possible solution to this problem is to make sticks available for only one philosopher at a time by changing stick model as follows: n Why? 17

Linear-Time Behavior n To analyze a computer system represented by a transition system two approaches can be followed: n State-based approach: abstracts from actions and only state labels in sequences are considered. n Action-based approach: abstracts from states and refers only to the action labels of the transitions. 18

Linear-Time Behavior (Con.) n In this chapter, we mainly focus on the state-based approach. n Action labels of transitions are only necessary for modeling communication. n Therefore, the verification algorithms operate on the state graphs of a LTS: n The digraph originating from a LTS by abstracting from action labels. 19

Linear-Time Behavior: Paths and State Graph n Let TS=(S,Act,,I,AP,L) be a TS. n Definition: The state graph of TS, notation G(TS), is the digraph (V,E) with vertices V=S and edges E={(s,s )ÎS S s ÎPost(s)} n It should be noted that multiple transitions (with different labels) are represented by a single edge. 20

Linear-Time Behavior: Paths and State Graph (Con.) n Let Post*(s) denote the states that are reachable in state graph G(ST) from s. n This notation is generalized for sets of states in usual way: for let : sîc n The notations Pre*(s) and Pre*(C) have analogous meaning. C * * Post (C) = U Post (s) Í S 21

Linear-Time Behavior: Paths and State Graph (Con.) n The set of states that are reachable from some initial state, notation Reach(TS), equals Post*(I). n Since actions are abstracted, the resulting runs of a transition system are called paths. 22

Linear-Time Behavior: Paths and State Graph (Con.) n Definition: A finite path fragment ˆp of TS is a finite state sequence s 0 s 1 s n such that s i ÎPost(s i-1 ) for all 0<i n, where n 0. An infinite path fragment p is an infinite state sequence s 0 s 1 s 2 such that s i ÎPost(s i-1 ) for all i>0. 23

Linear-Time Behavior: Paths and State Graph (Con.) n Some notations: n p = s 0 s 1 : an infinite path fragment; n first( p ) : the initial state of p ; n p[j]=s j, j 0 : jth state of p ; n p[..j]: the jth prefix p,i.e, p [..j]=s 0 s 1 s j ; n p[j..]: the jth suffix of p, i.e, p [j..]= s j s j+1 ; n These notation are defined for finite paths: n ˆp = s 0 s 1 s n : an finite path fragment 24

Linear-Time Behavior: Paths and State Graph (Con.) ˆp ˆp ˆp ˆp p p n last( ) = sn : the last state of ; n len( )=n : the length of ; n For infinite path we have len( )= and last( p )= ^, where ^ denotes undefined. 25

Linear-Time Behavior: Paths and State Graph (Con.) n Definition: A maximal path fragment is either a finite path fragment that ends in a terminal state or an infinite path fragment. A path fragment is called initial if it starts in an initial state. n A maximal path fragment cannot be prolong: either it is infinite or finite but ends in a terminal state. 26

Linear-Time Behavior: Paths and State Graph (Con.) n Definition: A path of transition system TS is an initial, maximal path fragment. 27

Linear-Time Behavior: Paths and State Graph (Con.) n Some notations: n Paths(s) : the set of maximal path fragments π with first(π)=s; n Paths fin (s): the set of all finite path fragments with first( )=s; ˆp n Paths(TS): the set of all paths in TS; n Paths fin (TS): the set of all initial, finite path fragments of TS. ˆp 28

Linear-Time Behavior: Paths and State Graph (Con.) n Example 3.7: consider the beverage vending machine of Example 2.2. get_coffee pay insert_coin get_tea coffee t select t tea n Recall L(s)={s}. Example path fragments of this TS are: p = payselect tea payselect tea... 1 p = select tea pay select coffee... 2 p= ˆ pay select tea pay select tea. 29

Linear-Time Behavior: Paths and State Graph (Con.) n Only π 1 is a path. The infinite path fragment π 2 is maximal but not initial. ˆp is initial but not maximal. n We have last( ˆp )=tea, first(π 2 )=select, π 1 [0]=pay, π 1 [3]=pay, π 1 [..5]= ˆp, ˆp [..2]= ˆp [3..],len( ˆp )=5, and len(π 1 )=. 30

Linear-Time Behavior: Traces n We are going to focus on states visited during executions (i.e. paths) to analyze the behavior of a computer system. n In fact states themselves are not observable, but just their atomic propositions. 31

Linear-Time Behavior : Traces (Con.) n Thus instead of s 0 s 1 s 2 we consider sequences of the form L(s 0 ) L(s 1 ) L(s 2 ) that registers the atomic propositions that are valid along the execution. n Such sequences are called traces. n The traces of a transition system are thus words over the alphabet 2 AP. 32

Linear-Time Behavior : Traces (Con.) n In the following it is assumed that a transition system has no terminal state. n In this case, all traces are infinite words. n This assumption is made for simplicity and does not impose restriction! 33

Linear-Time Behavior : Traces (Con.) n Thus prior to checking any property, a reachability analysis is carried out to determine the set of terminal states: Ø A terminal state may be a deadlock and has to be repaired before any further analysis; 34

Linear-Time Behavior : Traces (Con.) Ø Or it is a valid terminal state, and the TS can be extended such that: n a new state s stop and transition s s stop and n s stop is equipped with a self loop, i.e. s stop s stop The resulting equivalent transition system obviously has no terminal state. 35

Linear-Time Behavior : Traces (Con.) n Definition: Let TS=(S,Act,,I,AP,L) be a TS without terminal states. The trace of the infinite path fragment π = s 0 s 1 is defined as trace( ˆp )=L(s 0 ) L(s 1 ). The trace of the finite path fragment ˆp = s 0 s 1 s n is defined as trace( ˆp )= L(s 0 ) L(s 1 ) L(s n ). 36

Linear-Time Behavior : Traces (Con.) n The trace of a path fragment is the sequence of sets of atomic propositions that are valid in the states of the path. n The set of traces of a set П of paths is defined by trace(п)={trace(π) πîп}. n Read Example 3.9. 37

Linear-Time Behavior : Traces (Con.) n Let Traces(s) denote the set of traces of s and Traces(TS) the set of traces of transition system TS: Traces(s) = trace(paths(s)), Traces(TS) = U Traces(s) sîi n Similarly, the finite traces of a state s and a transition system are defined: Traces (s) = trace(paths (s)), fin sîi fin Traces fin (TS) = U Traces fin (s) 38

Linear-Time Behavior: Linear- Time Properties n Linear-time properties specify the traces that a transition system should exhibit. n Informally a linear-time property specifies the admissible behavior of the system under consideration. 39

Linear-Time Behavior : Linear- Time Properties (Con.) n A LT property is a requirement on the traces of a TS (all words over AP), and is defined as the set of words that are admissible: n Definition: A linear-time property (LT property) over the set of atomic proposition AP is a subset of (2 AP ) ω. 40

Linear-Time Behavior: Linear- Time Properties (Con.) n Definition: Let P be an LT property over AP and TS=(S,Act,,I,AP,L) a transition system without terminal state. Then TS=(S,Act,,I,AP,L) satisfies P, denoted TS = P, iff Traces(TS) Í P. States sîs satifies P, notation s = P, whenever Traces(s)ÍP. 41

Linear-Time Behavior: Linear- Time Properties (Con.) n Thus a transition system satisfies the LT property P if all its traces respect P, i.e., if all its behavior are admissible. n A state satisfies P whenever all traces starting in this state fulfill P. 42

Linear-Time Behavior: Linear- Time Properties (Con.) n Example 3.12: Consider two simplified traffic lights that only have two possible settings: red and green. Let the proposition of interest be AP={red 1,green 1,red 2,green 2 } 43

Linear-Time Behavior: Linear- Time Properties (Con.) n Consider property P that states The first traffic light is infinitely often green n P corresponds to the set of infinite words of the form A 0 A 1 A 2 over 2 AP, such that green 1 ÎA i holds for infinitely many i. n For example P contains the infinite words {red,green }{green, red }{red,green }{green, red }... 1 2 1 2 1 2 1 2 Æ{green } Æ{green } Æ{green } Æ{green } Æ... 1 1 1 1 {red,green }{red,green }{red,green }{red,green }... 1 1 1 1 1 1 1 1 n But {red,green }{red,green } ÆÆÆÆ... is not in P. 1 1 1 1 44

Linear-Time Behavior: Linear- Time Properties (Con.) n Consider property P that states The traffic lights are never both green simultaneously. n P is formalized by the set of infinite words of the form A 0 A 1 A 2 such that either green or 1ÏAi green 2ÏAi, for all i³0. n For example P contains: {red,green }{green, red }{red,green }{green, red }... 1 2 1 2 1 2 1 2 Æ{green } Æ{green } Æ{green } Æ{green } Æ... 1 1 1 1 {red,green }{red,green }{red,green }{red,green }... 1 1 1 1 1 1 1 1 n But {red,green }{green,green }... is not in P. 1 2 1 2 45

Linear-Time Behavior: Linear- Time Properties (Con.) n The traffic lights depicted below satisfies both P and P, since their switching is synchronized: n Traffic lights that switch completely autonomously with neither satisfy P nor P. 46

Linear-Time Behavior: Linear- Time Properties (Con.) n Often, an LT property does not refer to all atomic propositions occurring in a TS, but just to a small subset. n Let P be a property over AP Í AP such that only the labels in AP are relevant: ˆp ˆp n trace AP ( ) denotes the finite trace of where only propositions in AP are considered. 47

Linear-Time Behavior: Linear- Time Properties (Con.) n trace AP (π) denotes the trace of an infinite path fragment π by focusing on propositions in AP, defined as: trace AP (π)=l (s 0 ) L (s 1 ) =(L(s 0 )ÇAP ) (L(s 1 )ÇAP ). n Traces AP (TS) denote the set of traces trace AP (Paths(TS)). n Whenever the set AP is clear from the context, the subscript AP is omitted. 48

Linear-Time Behavior: Linear- Time Properties (Con.) n Example 3.13: For specifying the mutual exclusion, it suffices to only consider the atomic proposition crit 1 and crit 2. n Thus the formalization of mutual exclusion property is : P mutex = set of infinite words A 0 A 1 A 2 with { crit,crit } Í A for all i³0. 1 2 i 49

Linear-Time Behavior: Linear- Time Properties (Con.) n For example P mutex contains: {crit }{crit }{crit }{crit }{crit }{crit }... 1 2 1 2 1 2 {crit }{crit }{crit }{crit }{crit }{crit }... 1 1 1 1 1 1 ÆÆÆÆÆÆ... {crit } Æ crit,crit... { } n But is not in P mutex. 1 1 2 n The transition system TS Arb = (TS 1 TS 2 ) Arbiter in Example 2.28 fulfills the mutex property : TS Arb = P mutex. n Read Example 3.14 for starvation freedom! 50

Linear-Time Behavior: Trace Equivalence and Linear-Time Properties n LT properties specify the (infinite) traces that a TS should exhibit. n If TS and TS have the same traces, one would expect that they satisfy the same LT properties: n If TS = P and Traces(TS)=Traces(TS ), then TS = P, the traces of TS are also contained in P. 51

Linear-Time Behavior: Trace Equivalence and Linear-Time Properties (Con.) n Whenever TS ¹ P, then there is a trace in Traces(TS) that is prohibited by P. n If Traces(TS)=Traces(TS ), also TS exhibits this prohibited trace and thus TS ¹ P. n In this Section we define the relationship between trace equivalence, trace inclusion and satisfaction of LT properties. 52

Linear-Time Behavior: Trace Equivalence and Linear-Time Properties (Con.) n Trace inclusion between transition systems TS and TS requires that n all traces exhibited by TS can also be exhibited by TS : Traces(TS)Í Traces(TS ). n TS may exhibit more traces, i.e., may have some behavior that TS does not have. 53

Linear-Time Behavior: Trace Equivalence and Linear-Time Properties (Con.) n In stepwise design, where designs are successively refined, trace inclusion is viewed as implementation relation: n Traces(TS)Í Traces(TS ) means TS is a correct implementation of TS. n For example TS may be a design where parallel composition is modeled by interleaving and TS its realization where interleaving is resolved by some scheduling 54

Linear-Time Behavior: Trace Equivalence and Linear-Time Properties (Con.) n Theorem 3.15 (trace inclusion and LT properties): Let TS and TS be transition systems without terminal states and with the same set of AP. Then the following statements are equivalent: n Traces(TS)Í Traces(TS ). n For any LT property P: TS =P implies TS =P. 55

Linear-Time Behavior: Trace Equivalence and Linear-Time Properties (Con.) n This Theorem plays a decisive role for design by means of successive refinement: n If TS is the transition system representing a preliminary design and TS its refinement, it can immediately be concluded that any LT property that holds in TS also holds for TS. n Read Example 3.16. 56

Linear-Time Behavior: Trace Equivalence and Linear-Time Properties (Con.) n Definition: Transition systems TS and TS are trace-equivalent with respect to the set of propositions AP if Traces AP (TS)=Traces AP (TS ). n Corollary: Let TS and TS be transition systems without terminal state and with the same set of propositions. Then Traces(TS)=Traces(TS ) Û TS and TS satisfy the same LT properties. 57

Linear-Time Behavior: Trace Equivalence and Linear-Time Properties (Con.) n Thus there does not exist an LT property that can distinguish between trace-equivalent TSs. n So to establish TS and TS are not traceequivalent, it suffices to find one LT property that holds for one but not for the other. 58

Linear-Time Behavior: Trace Equivalence and Linear-Time Properties (Con.) n Example 3.19: Consider the two transition systems below: n Let AP={pay,soda,beer}. Thus they are trace-equivalent. 59

Safety Properties and Invariants n Safety properties are often characterized as nothing bad should happen : n Mutual exclusion property; n Deadlock freedom. 60

Safety Properties and Invariants: Invariants n The above safety properties are of a particular kind: they are invariants: n Invariants are LT properties that are given by a condition F for the states and requires that F holds for all reachable states. 61

Safety Properties and Invariants (Con.) n Definition: An LT property P inv over AP is an invariant if there is a propositional logic formula F over AP such that P inv ={A 0 A 1 A 2 Î(2 AP ) ω "j³0.a j = F}. F is called an invariant condition (or state condition) of P inv. 62

Safety Properties and Invariants: Invariants (Con.) n Note that TS = P inv n iff trace(π)îp inv for all paths π in TS; n iff L(s) =F for all states s that belong to a path of TS; n iff L(s) =F for all states sîreach(ts). n The condition F has to be fulfilled by all initial states and satisfaction of F is invariant under all transitions: a s¾¾ s n If s =F and, then s =F. 63

Safety Properties and Invariants: Invariants (Con.) n The mutual property can be described by an invariant using the propositional logic formula F= crit 1 Ú crit 2. n For deadlock freedom of the dining philosophers, the invariant ensures that at least one of the philosophers is not waiting to pick up the chopstick: F= wait 0 Ú wait 1 Ú wait 2 Ú wait 3 Ú wait 4. 64

Safety Properties and Invariants: Invariants (Con.) n Checking an invariant for the propositional formula F in a TS amounts to checking the validity of F in every reachable state: n A slight modification of standard graph traversal algorithms like depth-first search (DFS) or breath-first search (BFS), provided that the TS is finite. 65

Safety Properties and Invariants: Invariants (Con.) n The algorithm below checks the invariant condition F by means of a forward DFS in the state graph G(TS): 66

Safety Properties and Invariants: Invariants (Con.) n Forward search means that we start from the initial state and investigates all states that are reachable from them. n R stores all visited states, so when the algorithm terminates R=Reach(TS). n U is a stack that organized all states that still have to be visited, provided that they are not yet in R. 67

Safety Properties and Invariants: Invariants (Con.) n This algorithm could be improved by n aborting the computation once a state s is encountered that does not fulfill F. n While a counterexample is returned on encountering a state that violates F. 68

Safety Properties and Invariants: Invariants (Con.) n The resulting algorithm is shown: n Examine the time complexity of algorithm! 69

Time Complexity of Invariant Checking n Theorem: The time complexity of Algorithm 4 is O(N*(1+ Φ ) + M) where N denotes the number of reachable states, and M the number of transitions in the reachable fragment of TS. 70

Safety Properties and Invariants: Invariants (Con.) n Alternate to a forward search, a backward search could have been applied that starts with all states where F does not hold and calculates (by a * DFS or BFS) the set Pre (s). U sî S,s ¹F 71

Safety Properties and Invariants: Safety Properties n Invariants can be viewed as state properties and can be checked by considering the reachable states. n Some safety properties may impose requirement on finite path fragment and cannot be verified by considering the reachable states only. 72

Safety Properties and Invariants: Safety Properties (Con.) n A requirement for an automated teller machine (ATM) is that money can be withdrawn from the dispenser once a correct PIN has been provided. n This property is not an invariant, since it is not a state property. n It is a safety property as any infinite run violating the requirement has a finite prefix that is bad money is withdrawn without PIN. 73

Safety Properties and Invariants: Safety Properties (Con.) n Formally, a safety property P is defined as an LT property over AP such that any infinite word s where P does not hold contains a bad prefix. 74

Safety Properties and Invariants: Safety Properties (Con.) n Definition: An LT property P safe over AP is called a safety property if for all words sî(2 AP ) ω \P safe there exists a finite path ŝ of s such that ŝ P safe Ç{s Î(2 AP ) ω is a finite prefix of s } = Æ 75

Safety Properties and Invariants: Safety Properties (Con.) n Any such finite word ŝ is called a bad prefix for P safe. A minimal bad prefix P safe denotes a bad prefix ŝ for P safe for which no proper prefix of ŝ is a bad prefix for P safe. n n In other words, minimal bad prefixes are bad prefixes of minimal length. BadPref(P safe ) denotes the set of all bad prefixes for P safe and MinBadPref(P safe ) the set of all minimal bad prefiex. 76

Safety Properties and Invariants: Safety Properties (Con.) n Any invariant is a safety property. n For propositional formula F over AP and its invariant P inv, all finite words of the form A 0 A 1 A n Î(2 AP ) + with A 0 =F,, An-1 = F and A n ¹F constitute the minimal bad prefixes for P inv. 77

Safety Properties and Invariants: Safety Properties (Con.) n Example 3.23: We consider a specification of a traffic light with the usual three phases red, green, and yellow. n The requirement that each red phase should be immediately preceded by a yellow phase is a safety property but not an invariant. 78

Safety Properties and Invariants: Safety Properties (Con.) n Let AP={red,green,yellow}. n The property always at least one of the lights is on is specified as {s = A 0 A 1 A n A j Í AP and A j Æ} n The bad prefixes are finite words that contain Æ. A minimal bad prefix ends with Æ. 79

Safety Properties and Invariants: Safety Properties (Con.) n The property it is never the case that two lights are switched on at the same time is specified by {s = A 0 A 1 A n A j Í AP and A j 1} n Bad prefix for this property are words containing sets such as {red, green}, {red, yellow}, and so on. Minimal bad prefixes end with such sets. 80

Safety Properties and Invariants: Safety Properties (Con.) n Now, let AP ={red,yellow}. n The property a red phase must be preceded immediately by a yellow phase is specified by the set of infinite words s=a 0 A 1 with A i Í{red,yellow} such that for all i³0 we have that n redîa i implies i>0 and yellowîai-1. n The bad prefixes are finite words that violates this condition. 81

Safety Properties and Invariants: Safety Properties (Con.) n The bad prefixes are finite words that violate this condition. An example of bad prefixes that are minimal is: ÆÆ{red} and Æ{red} n The following bad prefixes is not minimal: {yellow}{yellow}{red}{red}æ{red} 82

Safety Properties and Invariants: Safety Properties (Con.) n The minimal bad prefixes of this property constitute a regular language accepted by the automaton below: n See also Example 3.24. 83

Safety Properties and Invariants: Safety Properties (Con.) n Lemma (Satisfaction Relation for Safety Properties): For transition system TS without terminal state and safety property P safe : n TS = P safe if and only if Traces fin (TS)ÇBadPref(P safe )=Æ. 84

Safety Properties and Invariants: Safety Properties (Con.) n Definition: For trace sî(2 AP ) ω, let pref(s) denote the set of finite prefixes of s: ŝ n pref(s)={ Î(2 AP ) * is a finite prefix of s}. n If s =A 0 A 1 then pref(s) = {e, A 0, A 0 A 1, A 0 A 1 A 2, } is an infinite set of finite words. n This notion is lifted to sets of traces in usual way. For property P: pref(p) = Ès P perf(s) ŝ 85

Safety Properties and Invariants: Safety Properties (Con.) n The closure of LT P is defined by closure(p)={sî(2 AP ) ω pref(s)ípref(p)}. n The closure of a LT property P is the set of infinite traces whose finite prefix are also prefixes of P. n Stated differently, infinite traces in the closure of P do not have a prefix that is not a prefix of P itself. 86

Safety Properties and Invariants: Safety Properties (Con.) n Lemma (Alternative Characterization of Safety Properties): Let P be an LT property over AP. Then, P is a safety property iff closure(p)=p. 87

Safety Properties and Invariants: Trace Equivalence and Safety Properties n Theorem (Finite Trace Inclusion and Safety Properties): Let TS and TS be transition systems without terminal states and with a same AP. Then the following statements are equivalent: n Traces fin (TS)ÍTraces fin (TS ); n For any safety property P safe : TS =P safe implies TS =P safe. 88

Safety Properties and Invariants: Trace Equivalence and Safety Properties (Con.) n Thus if a preliminary design TS is refined to a design TS such that n Traces(TS) ÍTraces(TS ) then the LT properties of TS do not hold for TS. n Traces fin (TS)ÍTraces fin (TS ) (which is a weaker requirement than full trace inclusion of TS and TS ) then all safety properties of TS also hold for TS. 89

Safety Properties and Invariants: Trace Equivalence and Safety Properties (Con.) n Corollary: Let TS and TS be transition systems without terminal states and with a same AP. Then the following statements are equivalent: n Traces fin (TS)=Traces fin (TS ); n For any safety property P safe over AP: TS =P safe ÛTS =P safe. 90

Safety Properties and Invariants: Trace Equivalence and Safety Properties (Con.) n Since we assume transition systems without terminal states, there is only a slight difference between trace inclusion and finite state inclusion. n For finite transition systems TS and TS without terminal states, trace inclusion and finite trace inclusion coincide. 91

Safety Properties and Invariants: Trace Equivalence and Safety Properties (Con.) n Theorem (Relating Finite Trace and Trace Inclusion): Let TS and TS be transition systems with the same set AP of atomic propositions such that TS has no terminal states and TS is finite. Then n Traces(TS)ÍTraces(TS ) Û Traces fin (TS)ÍTraces fin (TS ); 92

Safety Properties and Invariants: Trace Equivalence and Safety Properties (Con.) n Remark: The result of previous Theorem also holds under weaker conditions: TS has no terminal states and TS is AP image-finite. n TS is called AP image-finite if n For all AÍAP, the set {s 0 ÎI L(s 0 )=A} is finite n For all state s in TS and AÍAP, the set of successors {s ÎPost(s) L(s )=A} is finite. 93

Liveness Properties n Liveness properties state that something good will happen in the future. n Whereas safety properties are violated in finite time, i.e., by a finite system run, liveness properties are violated in infinite time, i.e., by infinite system runs. 94

Liveness Properties (Con.) n Definition: LT property P live over AP is a liveness property whenever pref(p live )=(2 AP ) *. n Thus a liveness property is an LT property P such that each finite word can be extended to an infinite word that satisfies P. 95

Liveness Properties (Con.) n Example 3.34: In the context of mutual exclusion, typical liveness properties are n (eventually) each process will eventually enter its critical section; n (repeated eventually) each process will enter its critical section infinitely often; n (starvation freedom) each waiting process will eventually enter its critical section. n Formalize above properties! 96

Liveness Properties: Safety vs. Liveness Properties n We examine following questions : n Are safety and liveness properties disjoint? n Is any linear-time property a safety or liveness property? 97

Liveness Properties: Safety vs. Liveness Properties (Con.) n Safety and liveness properties are indeed disjoint: n Lemma 3.35 (Intersection of Safty and Liveness Properties): The only LT property over AP that is both a safety and a liveness property is (2 AP ) ω. 98

Liveness Properties: Safety vs. Liveness Properties (Con.) n For any LT property P an equivalent LT property P does exist which is a combination (i.e., intersection) of a safety and a liveness property. n Lemma 3.36 (Distributivity of Union over Closure): for any LT properties P and P : closure(p)èclosure(p )=closure(pèp ) 99

Liveness Properties: Safety vs. Liveness Properties (Con.) n Theorem 3.37 (Decomposition Theorem): For any LT property P over AP there exists a safety property P safe and a liveness property P live (both over AP) such that P=P safe ÇP live. n The proof of this theorem shows that P safe =closure(p) and P live =PÈ((2 AP ) ω \closure(p)). 100

Liveness Properties: Safety vs. Liveness Properties (Con.) n This decomposition is the sharpest since P safe is the strongest safety property and P live the weakest liveness proptry. n Lemma 3.38 (Sharpest Decomp.): Let P be a LT property and P=P safe ÇP live where P safe is a safety property and P live a liveness property. We have n closure(p)íp safe ; n P live ÍPÈ((2 AP ) ω \closure(p)). 101

Liveness Properties: Safety vs. Liveness Properties (Con.) n A summary of the classification of LT properties is depicted as a Venn diagram in below: 102

Fairness n Fairness assumptions rule out infinite behaviors that are considered unrealistic, and are often necessary to establish liveness property. n When verifying concurrent systems we are interested in paths in which enabled transitions are executed in some fair manner. 103

Fairness (Con.) n In order to prove starvation freedom, we want to exclude those paths in which the competitor process is always being selected for execution. n This type of fairness is also known as process fairness, since it concerns the fair scheduling of the execution of processes. 104

Fairness (Con.) n In general, fairness assumptions are needed to prove livenss or other properties stating that the system makes some progress. n Besides it is important if the TS contains nondeterminism. n Fairness is used to resolve nondeterminism in modeling concurrent processes by means of interleaving. 105

Fairness (Con.) n Example 3.42: Consider the transition system TS = TrLight 1 TrLight 2 for the two independent traffic lights. n The liveness property both traffic lights are infinitely often green is not satisfied, since {red1,red2} {green1,red2} {red1,red2} {green1,red2} is a trace of TS. 106

Fairness (Con.) n The problem is that the information that each light switches color infinitely often is lost by means of interleaving. n Thus the trace in which only the first light is acting while the second seems to be stopped is formally a trace of TS. n However, it does not represent a realistic behavior as in practice no light is infinitely faster than another. 107

Fairness: Fairness Constraints n To obtain a realistic picture of the behavior of a parallel system modeled by a TS, we need to resolve nondeterministic decisions in a TS. n In order to rule out the unrealistic computations, fairness constraints are imposed. 108

Fairness: Fairness Constraints (Con.) n A fair execution is characterized by the fact that certain fairness constraints are fulfilled. n Fairness constraints are used to rule out computations that are considered to be unreasonable. 109

Fairness: Fairness Constraints (Con.) n Let is enabled mean TS is ready to execute (a transition) and gets its turn stand for the execution of an arbitrary transition. 110

Fairness: Fairness Constraints (Con.) n Fairness constrains are of three types: n Unconditional fairness: e.g., every process gets its turn infinitely often. n An execution fragment is unconditionally fair with respect to e.g. a process enters its critical section or a process gets its turn, if these properties hold infinitely often. 111

Fairness: Fairness Constraints (Con.) n Strong fairness: e.g., every process that is enabled infinitely often gets its turn infinitely often. n An execution fragment is strongly fair with respect to activity a if it is not the case that a is infinitely enabled without being taken beyond a certain point. 112

Fairness: Fairness Constraints (Con.) n Weak fairness: e.g., every process that is continuously enabled from a certain time instant on gets its gets its turn infinitely often. n An execution fragment is weakly fair with respect to some activity, say a, if it is not the case that a is always enabled beyond some point without being taken beyond this point. 113

Fairness: Fairness Constraints (Con.) n There are different ways to formulate fairness requirements. n In following, we adopt the action-based view and define fairness for sets of actions. n In order to formulate fairness notions formally, the following auxiliary notion is used: n Act(s) denotes the set of actions that are executable in state s, that is, a {aîact $s ÎS. s¾¾ s } 114

Fairness: Fairness Constraints (Con.) n Definition: For TS= (S,Act,,I,AP,L) without terminal states, AÍAct, and infinite a0 a1 execution fragment r= s ¾¾ s ¾¾... of TS: 0 1 1. r is unconditionally A-fair whenever $ j.a j ÎA. 2. r is strongly A-fair whenever ($ j.act(s j )ÇA¹Æ)Þ($ j.a j ÎA) 3. r is weakly A-fair whenever (" j.act(s j )ÇA¹Æ)Þ($ j.a j ÎA). 115

Fairness: Fairness Constraints (Con.) n Here $ j stands for there are infinitely many j and " j for for nearly all j in the sense of for all, except for finitely many j. The variable j ranges over the natural numbers. 116

Fairness: Fairness Constraints (Con.) n To check whether a run is unconditionally A-fair it suffices to consider the actions that occur along the execution. n However to check whether a given execution is strongly or weakly A-fair, we should also consider the enabled actions in all visited states. 117

Fairness: Fairness Constraints (Con.) n Example 3.44. Consider the following two processes that run in parallel and share variable x: n Proc Inc=while áx³0 do x:=x+1ñ od where the pair of á ñ embraces an atomic action. n Proc Reset= x:= -1 n The termination is not guaranteed for this parallel program. If, however, we require unconditional process fairness, termination is guaranteed. 118

Fairness: Fairness Constraints (Con.) n The relationship between different fairness notions: n Each unconditionally A-fair execution fragment is strongly A-fair; n Each strongly A-fair execution fragment is weakly A-fair. n Read Example 3.45. 119

Fairness: Fairness Constraints (Con.) n A fairness constraint imposes a requirement on all actions in a set A. n We can use fairness assumptions to have fairness constraints on different, possibly nondisjoint, sets of actions. 120

Fairness: Fairness Constraints (Con.) n Definition: A fairness assumption for Act is a triple F=(F uncond,f strong,f weak ) with F uncond,f strong,f weak Í 2 Act. Execution r is F-fair if : n It is unconditionally A-fair for all AÎF uncond, n It is strongly A-fair for all AÎF strong, and n It is weakly A-fair for all AÎF weak. n If the set F is clear from the context, we use the term fair instead of F-fair. 121

Fairness: Fairness Constraints (Con.) n The notion of F-fairness as defined on execution fragments is lifted to traces and paths: n An infinite trace s is F-fair if there is an F- fair execution r with trace(r)=s. n F-fair path fragments and F-fair paths are defined analogously. 122

Fairness: Fairness Constraints (Con.) n Let FairPaths F (s) denote the set of F-fair paths of s and FairPaths F (TS) the set of F- fair paths that start in some initial state of TS. n Let FairTraces F (s) denote the set of F-fair traces of s and FairTraces F (TS) the set of F-fair traces of the initial states of TS: FairTraces F (s) = trace(fairpaths F (s)) and FairTraces F (TS)= FairTraces (s). U sîi F 123

Fairness: Fairness Constraints (Con.) n Example 3.47: consider the following fairness requirement for two-process mutual exclusion algorithm: process Pi acquires access to its critical section (CR) infinitely often for any iî{1,2}. n Assume P i has three states: n i (noncritical), w i (waiting), and c i (critical). n Actions req i, enter i, and rel to model request to enter CR, entering CR and release of the CR. 124

Fairness: Fairness Constraints (Con.) n The strong-fairness assumption {{enter 1,enter 2 }} ensures that one of the actions enter 1 or enter 2 is executed infinitely often. n A behavior in which one of the processes gets access to the CR infinitely often while the other gets access only finitely many times is strongly fair with respect to this assumption! 125

Fairness: Fairness Constraints (Con.) n This is, however, not intended. n The strong-fairness assumption {{enter1},{enter2}} indeed realizes the earlier. 126

Fairness: Fairness Constraints (Con.) n It should be noted that fairness assumptions can be verifiable properties whenever all infinite execution fragments are fair. n But in many cases it is necessary to assume the validity of the fairness to verify liveness properties. n Read Examples 3.49 and 3.50. 127

Fairness: Fairness Constraints (Con.) n Definition (Fair Satisfaction Relation for LT properties): Let P be an LT property over AP and F a fairness assumption over Act. TS=(S,Act,,I,AP,L) fairly satisfies P, notation TS = F P, if and only if FairTraces F (TS)ÍP. 128

Fairness: Fairness Strategies n In order to rule out unrealistic computations, fairness assumptions are imposed on the traces of TS and it is checked whether TS = F P as opposed to checking TS = P. n What fairness assumption is suitable for synchronizing concurrent systems? 129

Fairness: Fairness Strategies (Con.) n To have fair communication mechanism between various processes, by rule of thumb : n Strong fairness is needed to obtain an adequate resolution of contention. n Weak fairness suffices for sets of actions that represent the concurrent execution of independent actions (i.e. interleaving). n Read Example 3.51. 130

Fairness: Fairness and Safety n While fairness assumptions may be necessary to verify liveness properties, they are irrelevant for verifying safety properties. n However, it is required fairness assumptions always be ensured by means of an scheduling strategy. n Such fairness assumptions are called realizable fairness assumptions. 131

Fairness: Fairness and Safety (Con.) n Definition: Let TS be a transition system with the set of actions Act and F a fairness assumption for Act. F is called realizable for TS if for every reachable state s: FairPaths F (s)¹æ. n A fairness assumption is realizable in a TS whenever in any reachable state at least one fair execution is possible. 132

Fairness: Fairness and Safety (Con.) n Theorem 3.55 (Realizable Fairness is Irrelevant for Safety Properties) Let TS be a transition system with set of propositions AP, F a realizable fairness assumption for TS, and P safe a safety property over AP. Then: TS = P safe iff TS = F P safe. n Theorem does not hold if arbitrary fairness assumptions are permitted (Example 3.56). 133

Summary n The set of reachable states of a TS can be determined by a search algorithm on the state graph of TS. n A trace is a sequence of sets (!) of atomic propositions. The traces of a TS are obtained from projecting the paths to the sequence of state labels. n A linear-time property is a set of infinite words over the alphabet 2 AP. 134

Summary n Two TSs are trace-equivalent iff they satisfy the same LT properties. n An invariant is an LT property that is purely state-based and requires a propositional logic formula Φ to hold for all reachable states. Invariants can be checked using a DFS where the DFS stack can be used to provide a counterexample in case an invariant is refuted. 135

Summary n Safety properties are generalizations of invariants. They constrain the finite behaviors. The formal definition of safety properties can be provided by means of their bad prefixes in the sense that each trace that refutes a safety property has a finite prefix, the bad prefix, that causes this. 136

Summary n Two TSs exhibit the same finite traces iff they satisfy the same safety properties. n A liveness property is an LT property if it does not rule out any finite behavior. It constrains infinite behavior. n Any LT property is equivalent to an LT property that is a conjunction of a safety and aliveness property. 137

Summary n Fairness assumptions serve to rule out traces that are considered to be unrealistic. They consist of unconditional, strong, and weak fairness constraints, i.e., constraints on the actions that occur along infinite executions. 138

Summary n Fairness assumptions are often necessary to establish liveness properties, but they are -provided they are realizable -irrelevant for safety properties. 139