Principles of Reliable Distributed Systems Recitation 1: Introduction

1
Principles of Reliable Distributed Systems
Recitation 1 Introduction

• Spring 2009
• Alex Shraer

2
Topics for today

• Specifications
• Liveness and Safety
• Coordinated Attack

3
Safety and Liveness

• The properties are verifiable in an execution
• Safety a property always happens
• the program will never produce a wrong result
• In all prefixes of a given execution
• Even in the empty prefix (doing nothing doesn't
  violate safety)
• Liveness a property eventually happens
• the program will eventually produce a result

4
Safety and Liveness - Cont.
Safety those properties whose violation always
has a finite witness (finite refutation)
In other words if every
counter-example for a property p has a finite
prefix in which p does not hold, then p is
safety. A safety property cannot be fixed
after it is violated.
Liveness those properties whose violation
never has a finite witness (all
counter-example traces are infinite)

No mater what happens along a finite trace,
something good could still happen later -
you can always extend a trace to satisfy a
livenes property.
5
Examples

• If the driver pushes the brakes of the car, it
  will eventually stop
• if this is not true, how can we refute this?
• the counter example will have the following form
• driver pushes the breakes at some point, but the
  car never stops afterwards - an infinite
  execution
• this is a liveness property
• The program terminates within 31 computational
  steps
• a finite execution may violate this this is a
  safety property!
• The program eventually terminates
• only an infinite example can possibly refute this
  claim liveness!
• Each process will enter its critical section
  infinitely often
• This means at any point of the run, each process
  will eventually enter its critical section (at
  some future point) (infinitely often always
  eventually)
• liveness!

6
The meaning of livenessLamport 2000

• The question of whether a real system satisfies a
  liveness property is meaningless it can be
  answered only by observing the system for an
  infinite length of time, and real systems dont
  run forever.
• Liveness is always an approximation to the
  property we really care about. We want a program
  to terminate within 100 years, but proving that
  it does would require addition of distracting
  timing assumptions.
• So, we prove the weaker condition that the
  program eventually terminates. This doesnt prove
  that the program will terminate within our
  lifetimes, but it does demonstrate the absence of
  infinite loops.

7
A non-safety and non-liveness property

• The machine provides infinitely often beer
• after initially providing sprite three times in
  a row
• This property consists of two parts
• it requires beer to be provided infinitely often
• this is a liveness property
• the first three drinks it provides should all be
  sprite
• example of a bad prefix one of first three
  drinks is beer
• this is a safety property
• This property is a conjunction of a safety and a
  liveness property

8
Example - execution of an
elevator system
call from 3rd floor
open the doors
moving up 2 floors
make beep sound
events
states
floor doors buttons pushed
1st closed none
1st closed 3rd floor
3rd open none
3rd closed 3rd floor
(infinite execution)
What is the trace of this execution?
moving up 2 floors
open the doors
call from 3rd floor
make beep sound
,
,
,
9
Predicates

• The doors are always open
• False! Counter example the prefix of the
  execution consisting of its first state
• If someone summons the elevator to some floor,
  the doors eventually open
• True over our execution
• After doors open, the next action of the elevator
  is to make a beep sound
• True over our execution
• The elevator may break after the 1st year of use
• not a property! cannot be evaluated over an
  execution
• Suppose that we add time to our model
• If someone summons the elevator to some floor
• The elevator will eventually stop
• The elevator reaches that floor no later than 1
  minute later

10
Safety/Liveness/Both/None?

• ?????? ?????? ??? ????? ???? ?????
• ???? ???????? ?????? ?????? ????? ??? ????? 30.
• ?????? ?????? ????? ???? ?????
• ????? ?????? ???? ??????? ?????? ????.
• ??? ???? ???? ?????? ????? ?? ???? ???? ??????
  ???? ????? ?????.
• ?? ????? ???????? ?????.
• ?????? ???? ?? ????? ?????, ??? ?? ???? ?? ?????
  ??? ???.
• ?????? ???? ?? ????? ????? ??? ??? ??? ??? ?????.

11
Coordinated Attack

• Lets attack

• B

• A

12
The Model Synchronous with Message Loss

• Message loss can be detected
• Bounded delay, timeouts
• Message loss is unbounded
• In some runs, all the messages are lost

13
Properties of Coordinated Attack

• Agreement If both generals decide, they decide
  the same.
• Termination Every general eventually decides.
• Validity
• If both inputs are not ready then no general
  decides attack
• if both inputs are ready and no messages are
  lost then no general decides no-attack.

14
What happens if? (contd)

• Weak Termination If there are no message losses,
  then all processes eventually decide.
• We want an algorithm that solves the problem
  where Agreement, Weak Termination and Validity
  are required.
• Each general performs the following
• Send(inp)
• Upon Deliver(m) Decide(this.inp m.inp)
• Or any deterministic rule that matches validity
• halt

15
What happens if? (contd)

• Wheres the difference? Why couldnt we use the
  proof from class when only Weak Termination was
  used?
• The proof shown in the lecture relies on the fact
  that all processes terminate (decide), when we
  build the runs. Otherwise, the proof doesnt work

16
What happens if? (contd)

• Unanimous Termination If any process decides,
  then all processes eventually decide.
• We want an algorithm that solves the problem
  where Agreement, Weak Termination, Unanimous
  Termination and Validity are required.
• Homework

17
Stronger Models

• Bounded loss rate
• At most, 10 messages are lost on each channel
  (from general A to general B and vice versa).
• Is it enough?
• Each general performs the following
• Repeat 11 times
• Send(my_vote)
• Upon Deliver(other_vote) Decide(my_vote
  other_vote)
• Or any deterministic rule that matches validity
• halt.

18
Correctness of this Algorithm

• Agreement If both generals decide, they decide
  on the of their votes the same
• Validity
• if both votes are 0 (not attack), since 00 0,
  no general decides attack
• If both votes are 1 (attack), since 11 1, no
  general decides not attack
• Termination
• Each vote is sent 11 times. Since at most 10 can
  be lost, at least one message is delivered (to
  each general). Therefore, they both decide and
  halt.

19
To Summarize

• The exact model assumptions and the exact problem
  specification are critical
• Minor changes in either lead to different
  results.