Safety properties. The proof of the safety properties of GWTS is analogous to the proof contained in Section 5.1.1. From the properties of reliable broadcast we have the following:
Safety properties. Observation 1. Given any correct process pj its SvS contains at most one value for each process in P. The above observation derives from the specification of reliable broadcast, and the fact that in the disclosure phase each participating process broadcasts a single value. We say that a message m containing a set of proposed values is “safe” for a process pi if such set of values is contained in SvS. It is immediate from function at Lines 35-39 that proposers (in state proposing) change their Proposed set only when they receive safe messages. The analogous holds for the Accepted set of acceptors. · We say that a value v receives m acks if it is contained in a Proposed set, that is in turn contained in ack messages in the form < ack, , ts > sent by m acceptors. The same meaning is intended when we say that Proposed set receives acks. Algorithm 1 WTS (Wait Till Safe) -Algorithm for Proposer process pi 1: proposed value = proi
Safety properties. To ensure the safe functioning of the Dwarf Signal system we need to impose a number of safety properties. These properties should at all times be preserved by the system. In CML we specify them as a collection of five functions which are enumerated in Table 3. NeverShowAll enforces that it should never be the case that all three lamps are on simultaneously. MaxOneLampChange requires that between any two states only one lamp can change from on to o↵, or o↵ to on. ForbidStopTo- Drive enforces that the signal cannot transition straight from the stop state to the drive state – it must go via the warning state. DarkOnlyToStop and DarkOn- lyFromStop together encode the requirement that a signal may only transition functions NeverShowAll: DwarfType -> bool NeverShowAll(d) == d.currentstate <> {<L1>,<L2>,<L3>} MaxOneLampChange: DwarfType -> bool MaxOneLampChange(d) == card ((d.currentstate \ d.laststate) union (d.laststate \ d.currentstate)) <= 1 ForbidStopToDrive : DwarfType -> bool ForbidStopToDrive(d) == (d.lastproperstate = stop => d.desiredproperstate <> drive) DarkOnlyToStop : DwarfType -> bool DarkOnlyToStop(d) == (d.lastproperstate = dark => d.desiredproperstate in set {dark,stop}) DarkOnlyFromStop: DwarfType -> bool DarkOnlyFromStop(d) == (d.desiredproperstate = dark => d.lastproperstate in set {dark,stop}) Table 3: Dwarf Signal: Safety Properties from dark to stop, and to dark from stop – a signal in warning or drive should not become stop directly. With our collection of safety properties which can describe the safe version of the Dwarf Signal state: types DwarfSignal = DwarfType inv d == NeverShowAll(d) and MaxOneLampChange(d) and ForbidStopToDrive(d) and DarkOnlyToStop(d) and DarkOnlyFromStop(d) 2.3 Reactive Behaviour Syntax Stop Skip a -> P a?v -> P a!v -> P P ; Q P [] Q P [|{a,b,c}|] Q [cond] & P Description Deadlocked process Null behaviour Communicate on a then behave like P Input value v over channel a then do P Output value v on channel a then do P Execute action P followed by Q Pick P or Q based on the first communication Execute P and Q in parallel, with synchronisation allowed on a, b and c allow execution of P only if cond holds Table 4: CML process combinator selection The Dwarf Signal is a reactive system; it waits for stimuli and behaves accordingly. To specify these sorts of aspects of a system we need to use a suitable formalism. In CML we support the specification of CSP processes. CSP (Communicating Sequential Processes) is a process...
