Skip to main content
CSE 452: Distributed Systems

Lecture 6: Stability; Virtual Clocks — Whiteboard Descriptions

These are text descriptions of the whiteboard PDF from this lecture.

These materials were drafted by AI based on the live whiteboard PDF and audio transcript from the corresponding lecture and then reviewed and edited by course staff. They may contain errors. Please let us know if you spot any.

Time

  • When things are true
  • Happens before relation
  • Lamport clocks (virtual clocks)

When Things Are True

  • Invariant — always true
  • Stable — once true, true for rest of execution
  • Unstable — not stable
    • counterexample to stability

Diagram: A state graph showing an execution path from an initial state (labeled "init") winding through several states, arriving at a state S₀ where property P holds. From S₀ the execution continues through a circuitous route, eventually reaching a state S₁ where ¬P holds — demonstrating that P was true at S₀ but not stable, since a later state violates it.

Examples: Invariants

  • Running instructions means computer on
  • Client has ≤ 1 outstanding request
    • outstanding request: request sent, but reply not received
    • (using client, seq num as key)
  • Seq num saved by server for each client is monotonically increasing (per client)
  • Backup has all the state the primary has (after state transfer in that view)
    • (in every view)
    • (in the highest view)

Example Stable Properties

  • Once a client id is in the server's AMO app, it's always there
    • Client C is in server's AMO app
  • There is a primary in VS's highest view
  • Once a server dies, it doesn't come back
    • "server S is dead"
  • If view server is in view n+1, then primary of view n completed state transfer in view n (invariant)
  • Generally, many properties of monotonic counters (seqnums, version numbers, view numbers, round numbers, etc) are stable.

Unstable

  • The current view has a backup
  • View V has a backup
    • (depends on definition of "has a backup")

"False" stable

Simultaneity

e₁ happens before e₂:

  • They happen on one machine, and e₁ is first
  • e₂ receives a message that e₁ sent
  • Or any transitive combination

e₁ is concurrent with e₂ if:

  • e₁ did not happen before e₂
  • and e₂ did not happen before e₁