Top Banner
Midterm Revision Session CS 5414
33

Midterm Revision Session

Apr 18, 2022

Download

Documents

dariahiddleston
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: Midterm Revision Session

Midterm Revision SessionCS 5414

Page 2: Midterm Revision Session

● Midterm : Monday, in class, closed notes

● Be clear/concise○ Symbols used in class are better than words/handwaving

● Be careful about assumptions○ it’s easy to assume the solution○ Sentences like “it is obvious that” are dangerous

● Definitions, definitions, definitions

● Do the required reading! ○ (yes, even if its 42 pages … )

Page 3: Midterm Revision Session

Introductory Material

● Can you prove impossibility of two general problems?

● Can you prove that:○ All k muddy children will say “yes” at round k○ If father says nothing/says individually to children,

there is no solution to the problem?

● What is common knowledge?

● Can you draw the Kripke structures?

Page 4: Midterm Revision Session

System Model (Communication/Failure)

● Synchronous system● Asynchronous system

○ No upper bound on message delivery time/on relative process speed

● Properties that can be assumed of channels

Page 5: Midterm Revision Session

Terminology

● Event epi(ith event of p) / Local History (total order) /

History

● Space time diagrams

● Happens-Before relationship○ If ep

k,epl ∈ hi and k<l, then ep

k→epl

○ If ei=send(m) and ej=receive(m) then ei→ej○ If e →e’ and e’→e’’ then e’→e’’

Page 6: Midterm Revision Session

Terminology

● Run: total ordering of events in the history

● Consistent run: a run that respects →

● Cut: subset of the global history (prefix of each local history)○ Can also write it as (c1,c2,c3)

● Frontier: set of events at the prefix

Page 7: Midterm Revision Session

Terminology

● Local state: pi. Result of applying the first ith events to

state of p

● Global state: n-tuple of local states

● To each cut (c1, c2, cn) corresponds a global state ( p1

c1, p2c2, p3

cn)

Page 8: Midterm Revision Session

Terminology

● Consistent Cut

Can you detect consistent cuts on space time diagrams?

● Consistent global state: state for which the corresponding cut is consistent

Page 9: Midterm Revision Session

Snapshot Protocol ● Why did we want a snapshot protocol?

● Example question: Why is not necessary to listen on pj?

● Without this protocol, what is the weakest channel delivery property for external monitor to have consistent state?

Page 10: Midterm Revision Session

Reachability

● Lattice: every node represents a consistent state.

● Represents all possible orders (runs) for a particular computation

● What are the properties of s? Why do we care?○ a global state for

snapshot start○ f snapshot finishes○ then a → s → f

Page 11: Midterm Revision Session

Lamport Clocks

● Clock Condition: ○ e →e’ => LC(e) < LC(e’)

● How can Lamport clocks implement FIFO

● How can Lamport clocks implement Causal delivery?

● No gap detection

Page 12: Midterm Revision Session

Vector Clocks (you need to be very comfortable with this)

● Strong Clock Condition: ○ e →e’ <=> VC(e) < V(e’)

● Update Rules:● On send (pi) On receive (pi)

● Vector Ordering:

● Concurrency:

Page 13: Midterm Revision Session

Vector Clocks (Consistency)

Page 14: Midterm Revision Session

Causal Delivery

● Weak Gap Detection

● Strong Gap Detection

● Delivery Rule

● How would you prove that this guarantees causal del?● Could you derive a weaker condition assuming FIFO

channels?

Page 15: Midterm Revision Session

Safety/Liveness/Non-stable properties

● You should know how to define safety/liveness

● How can I compute on the lattice:○ Possibly( )○ Definitely( )

● When can local states be garbage collected when building the lattice?

Page 16: Midterm Revision Session

Atomic Commit

● Impossibility result on communication/ total failures

● No independent recovery possible

Page 17: Midterm Revision Session

Two phase locking

● Why can coordinator always vote abort?

Page 18: Midterm Revision Session

Two phase locking (Termination)

● Cooperative termination protocol

● If all processes are uncertain (ak voted yes) but coordinator is down, what happens?

● 2PC can block even for non-total failures and no communication failures

Page 19: Midterm Revision Session

Three-Phase Locking

● (Non-blocking property) If any process is uncertain, no process (including coordinator) can have decided to commit => it is therefore always safe to abort.

Page 20: Midterm Revision Session

Three-Phase Locking (Termination Protocol)

● Why must pi run termination protocol in Step 6? It knows that the decision is commit ...

Page 21: Midterm Revision Session

Three-Phase Locking (Termination/Recovery Protocol)

● Why can p not simply commit if it recovers from a failure after pre-commit ?

● (TR1) Why don’t we need to wait for all processes to reply?

● Does the upset tracking need to be accurate? (ex: pn failed first, just after voting abort. All other processes p0 to pn-1 fail in sequence but vote commit. What happens if pn recovers first?

Page 22: Midterm Revision Session

State Machine Replication

● Agreement: Every non-faulty state machine receives every command

● Order: Every non-faulty state machine processes the commands it receives in the same order

(Order Implementation/Logical Clocks/Replica-Generated Ids)

Page 23: Midterm Revision Session

Primary Backup / Chain Replication

● What are the benefits of primary backup vs chain replication?○ For queries○ For updates

● What are hot/cold backups?

Page 24: Midterm Revision Session

Rollback Recovery - Checkpointing

● What is the goal of rollback-recovery?

● Uncoordinated checkpointing○ Cheap but domino effect

● Coordinated checkpointing○ Always restart from most recent checkpoint but high

latency● Communication induced checkpointing

○ local/forced snapshots. Z-Paths

Page 25: Midterm Revision Session

Rollback Recovery - Logging

● Piecewise deterministic assumption: all nondeterministic events can be identified

● Log determinants

● Orphan process: includes delivery event but send event has been lost

● Pessimistic Logging / Sender Based Logging / Optimistic Logging / Causal Logging

Page 26: Midterm Revision Session

Rollback Recovery - Consistency

Page 27: Midterm Revision Session

Rollback Recovery - Consistency

● What are the pros/cons of each scheme? (Check table in paper)

Page 28: Midterm Revision Session

Reliable Broadcast● What happens if

the sender fails before sending any message?

● Is it ok for everyone to output m’ if the sender proposed m but is faulty?

Page 29: Midterm Revision Session

Terminating Reliable Broadcast

● If one process delivers SF, what must the other processes do?

Page 30: Midterm Revision Session

Terminating Reliable Broadcast

● If one process delivers SF, what must the other processes do?

Page 31: Midterm Revision Session

Consensus

● What happens if a faulty process proposes a value v’?

● What happens if a process does not propose?

Page 32: Midterm Revision Session

Consensus

● What happens if a faulty process proposes a value v’?

● What happens if a process does not propose?

Page 33: Midterm Revision Session

Properties of send/receive

● Validity● Uniform integrity● Integrity (for arbitrary failures)