6.852: Distributed Algorithms Spring, 2008 Class 25-1.

Slides:



Advertisements
Similar presentations
Chapter 5: Tree Constructions
Advertisements

CSCE 668 DISTRIBUTED ALGORITHMS AND SYSTEMS Fall 2011 Prof. Jennifer Welch CSCE 668 Set 14: Simulations 1.
Global States.
Impossibility of Distributed Consensus with One Faulty Process
Chapter 9 Code optimization Section 0 overview 1.Position of code optimizer 2.Purpose of code optimizer to get better efficiency –Run faster –Take less.
CSE 486/586, Spring 2012 CSE 486/586 Distributed Systems Consensus Steve Ko Computer Sciences and Engineering University at Buffalo.
Chapter 6 - Convergence in the Presence of Faults1-1 Chapter 6 Self-Stabilization Self-Stabilization Shlomi Dolev MIT Press, 2000 Shlomi Dolev, All Rights.
Lecture 8: Asynchronous Network Algorithms
D u k e S y s t e m s Time, clocks, and consistency and the JMM Jeff Chase Duke University.
Ch. 7 Process Synchronization (1/2) I Background F Producer - Consumer process :  Compiler, Assembler, Loader, · · · · · · F Bounded buffer.
Chapter 15 Basic Asynchronous Network Algorithms
6.852: Distributed Algorithms Spring, 2008 Class 7.
Distributed Computing 8. Impossibility of consensus Shmuel Zaks ©
6.852: Distributed Algorithms Spring, 2008 Class 12.
Self Stabilizing Algorithms for Topology Management Presentation: Deniz Çokuslu.
Synchronization Chapter clock synchronization * 5.2 logical clocks * 5.3 global state * 5.4 election algorithm * 5.5 mutual exclusion * 5.6 distributed.
6.852: Distributed Algorithms Spring, 2008 Class 24.
Announcements. Midterm Open book, open note, closed neighbor No other external sources No portable electronic devices other than medically necessary medical.
Lecture 7: Synchronous Network Algorithms
CSCE 668 DISTRIBUTED ALGORITHMS AND SYSTEMS Fall 2011 Prof. Jennifer Welch CSCE 668 Self Stabilization 1.
Lecture 4: Elections, Reset Anish Arora CSE 763 Notes include material from Dr. Jeff Brumfield.
Distributed Computing 8. Impossibility of consensus Shmuel Zaks ©
Byzantine Generals Problem: Solution using signed messages.
CPSC 668Set 14: Simulations1 CPSC 668 Distributed Algorithms and Systems Spring 2008 Prof. Jennifer Welch.
CPSC 668Set 10: Consensus with Byzantine Failures1 CPSC 668 Distributed Algorithms and Systems Fall 2009 Prof. Jennifer Welch.
1 Complexity of Network Synchronization Raeda Naamnieh.
Chapter 8 - Self-Stabilizing Computing1 Chapter 8 – Self-Stabilizing Computing Self-Stabilization Shlomi Dolev MIT Press, 2000 Draft of January 2004 Shlomi.
CPSC 668Set 3: Leader Election in Rings1 CPSC 668 Distributed Algorithms and Systems Spring 2008 Prof. Jennifer Welch.
Chapter 4 - Self-Stabilizing Algorithms for Model Conservation4-1 Chapter 4: roadmap 4.1 Token Passing: Converting a Central Daemon to read/write 4.2 Data-Link.
CPSC 668Set 10: Consensus with Byzantine Failures1 CPSC 668 Distributed Algorithms and Systems Fall 2006 Prof. Jennifer Welch.
1 Fault-Tolerant Consensus. 2 Failures in Distributed Systems Link failure: A link fails and remains inactive; the network may get partitioned Crash:
CPSC 668Self Stabilization1 CPSC 668 Distributed Algorithms and Systems Spring 2008 Prof. Jennifer Welch.
CPSC 668Set 8: More Mutex with Read/Write Variables1 CPSC 668 Distributed Algorithms and Systems Fall 2009 Prof. Jennifer Welch.
Chapter 4 - Self-Stabilizing Algorithms for Model Conversions iddistance 22 iddistance iddistance iddistance.
Impossibility of Distributed Consensus with One Faulty Process Michael J. Fischer Nancy A. Lynch Michael S. Paterson Presented by: Oren D. Rubin.
Concurrency in Distributed Systems: Mutual exclusion.
Distributed systems Module 2 -Distributed algorithms Teaching unit 1 – Basic techniques Ernesto Damiani University of Bozen Lesson 2 – Distributed Systems.
Chapter Resynchsonous Stabilizer Chapter 5.1 Resynchsonous Stabilizer Self-Stabilization Shlomi Dolev MIT Press, 2000 Draft of Jan 2004, Shlomi.
Chapter 4 Self-Stabilization Self-Stabilization Shlomi Dolev MIT Press, 2000 Draft of October 2003 Shlomi Dolev, All Rights Reserved ©
Election Algorithms and Distributed Processing Section 6.5.
On Probabilistic Snap-Stabilization Karine Altisen Stéphane Devismes University of Grenoble.
Selected topics in distributed computing Shmuel Zaks
Lecture #12 Distributed Algorithms (I) CS492 Special Topics in Computer Science: Distributed Algorithms and Systems.
On Probabilistic Snap-Stabilization Karine Altisen Stéphane Devismes University of Grenoble.
Distributed Algorithms – 2g1513 Lecture 9 – by Ali Ghodsi Fault-Tolerance in Distributed Systems.
CS4231 Parallel and Distributed Algorithms AY 2006/2007 Semester 2 Lecture 10 Instructor: Haifeng YU.
Review for Exam 2. Topics included Deadlock detection Resource and communication deadlock Graph algorithms: Routing, spanning tree, MST, leader election.
CS4231 Parallel and Distributed Algorithms AY 2006/2007 Semester 2 Lecture 8 Instructor: Haifeng YU.
6.852: Distributed Algorithms Spring, 2008 Class 13.
THIRD PART Algorithms for Concurrent Distributed Systems: The Mutual Exclusion problem.
The Complexity of Distributed Algorithms. Common measures Space complexity How much space is needed per process to run an algorithm? (measured in terms.
DISTRIBUTED ALGORITHMS AND SYSTEMS Spring 2014 Prof. Jennifer Welch CSCE
CSCE 668 DISTRIBUTED ALGORITHMS AND SYSTEMS Spring 2014 Prof. Jennifer Welch CSCE 668 Set 8: More Mutex with Read/Write Variables 1.
Hwajung Lee. Why do we need these? Don’t we already know a lot about programming? Well, you need to capture the notions of atomicity, non-determinism,
CS 542: Topics in Distributed Systems Self-Stabilization.
Chapter 21 Asynchronous Network Computing with Process Failures By Sindhu Karthikeyan.
CSCE 668 DISTRIBUTED ALGORITHMS AND SYSTEMS Spring 2014 Prof. Jennifer Welch CSCE 668 Set 3: Leader Election in Rings 1.
1 Fault tolerance in distributed systems n Motivation n robust and stabilizing algorithms n failure models n robust algorithms u decision problems u impossibility.
Fault tolerance and related issues in distributed computing Shmuel Zaks GSSI - Feb
Fault tolerance and related issues in distributed computing Shmuel Zaks GSSI - Feb
Superstabilizing Protocols for Dynamic Distributed Systems Authors: Shlomi Dolev, Ted Herman Presented by: Vikas Motwani CSE 291: Wireless Sensor Networks.
1 Chapter 11 Global Properties (Distributed Termination)
6.852: Distributed Algorithms Spring, 2008 Class 14.
Chapter 10 Mutual Exclusion Presented by Yisong Jiang.
TIRGUL 10 Dijkstra’s algorithm Bellman-Ford Algorithm 1.
Fundamentals of Fault-Tolerant Distributed Computing In Asynchronous Environments Paper by Felix C. Gartner Graeme Coakley COEN 317 November 23, 2003.
Lecture 9: Asynchronous Network Algorithms
Distributed Consensus
CS60002: Distributed Systems
Lecture 8: Synchronous Network Algorithms
Presentation transcript:

6.852: Distributed Algorithms Spring, 2008 Class 25-1

Today’s plan Self-stabilizing algorithms: –Breadth-first spanning tree (review) –Mutual exclusion Composing self-stabilizing algorithms Making non-self-stabilizing algorithms self- stabilizing Reading: –[ Dolev, Chapter 2 ]

Legal execution fragments Given a distributed algorithm A, define a set L of “legal” execution fragments of A. L can include both safety and liveness conditions. Example: Mutual exclusion –L might be the set of all fragments  such that: (Mutual exclusion) –No two processes are in the critical region, in any state in . (Progress) –If in some state of , someone is in T and no one is in C, then sometime thereafter, someone  C. –If in some state of , someone is in E, then sometime thereafter, someone  R.

Self-stabilization: Definition A global state of algorithm A is safe with respect to legal set L, provided that every fair execution fragment of A that starts with s is in L. Algorithm A is self-stabilizing for legal set L if every fair execution fragment  of A contains a state s that is safe with respect to L. –Implies that the suffix of  starting with s is in L. –Also, any other fair execution fragment starting with s is in L. Weaker definition: Algorithm A is self-stabilizing for legal set L if every fair execution fragment  has a suffix in L.

SS Algorithm 1: Breadth-first spanning tree Shared-memory model Connected, undirected graph G = (V,E). Processes P 1,…,P n, P 1 a designated root. Permanent knowledge: –P 1 always knows it’s the root. –Everyone always knows who their neighbors are. P1P1 P4P4 P3P3 P2P2 r 12 r 21 r 13 r 42 r 24 r 31 Neighboring processes in G share registers in both directions: –r ij written by P i, read by P j. Output: A breadth-first spanning tree, recorded in the r ij : –r ij.parent = 1 if j is i’s parent, 0 otherwise. –r ij.dist = distance from root to i in the BFS tree = smallest number of hops on any path from 1 to i in G. –Values in registers should remain constant from some point onward.

Breadth-first spanning tree In terms of legal sets: –Define execution fragment  to be legal if: The registers have correct BFS output values, in all states in . Registers never change. –L = set of legal execution fragments. Safe state s: –Global state from which all extensions have registers with correct, unchanging BFS output values. SS definition says: –Any fair execution fragment , starting from any state, contains some “safe” state s. –That is, one from which all extensions have registers with correct, unchanging BFS output values. –Implies that any fair execution fragment  has a suffix in which the register contents represent a fixed BFS tree.

Algorithm strategy The system can start in any state, with –Any values (of the allowed types) in registers, –Any values in local process variables, Processes can’t assume that their own states and output registers are initially correct. Repeatedly recalculate states and outputs based on inputs from neighbors. In case of tie, use default rule for selecting parent. We proved correctness, stabilization time, using induction on distance from root.

Self-stabilizing mutual exclusion [Dijkstra 73] Ring of processes, each with output variable x i. High granularity: In one atomic step, process P i can read both neighbors’ variables, compute its next value, and write it to variable x i. P 1 : do forever: if x 1 = x n then x 1 := x mod (n+1) P i, i  1: do forever: if x i  x i-1 then x i := x i-1 P1P1 PnPn P3P3 P2P2 x1x1 x2x2 x3x3 xnxn That is: –P 1 tries to make its variable unequal to its predecessor’s. –Each other tries to make its variable equal to its predecessor’s That’s (n+1), not n.

Mutual exclusion In what sense does this “solve mutual exclusion”? Definition: “P i is enabled” (or “P i can change its state”) in a configuration, if the variables are set so P i can take a step and change the value of its variable x i. Legal execution fragment  : –In any state in , exactly one process is enabled. –For each i,  contains infinitely many states in which P i is enabled. Use this to solve mutual exclusion: –Say P i interacts with requesting user U i. –P i grants U i the critical section when: U i has requested it, and P i is enabled. –When U i returns the resource, P i actually does its step, changing x i. –Guarantees mutual exclusion, progress. –Also lockout-freedom.

Lemma 1 Legal  : –In any state in , exactly one process is enabled. –For each i,  contains infinitely many states in which P i is enabled. Lemma 1: A configuration in which all the x variables have the same value is safe. –Meaning from such a config, any fair execution fragment is legal. Proof: Only P 1 can change its state, then P 2,…and so on around the ring (forever). Remains to show: Starting from any state, we actually reach a configuration in which all the x values are the same.

Lemma 2 Lemma 2: In every configuration, at least one of the potential x values, {0,…,n}, does not appear in any x i. Proof: Obviously. There are are only n variables and n+1 values.

Lemma 3 Lemma 3: In any fair execution fragment (from any configuration c), P 1 changes x 1 at least once every nl time. Proof: –Assume not---P 1 goes longer than nl without changing x 1 from some value v. –Then by time l, P 2 sets x 2 to v, –By time 2l, P 3 sets x 3 to v, –… –By (n-1)l, P n sets x n to v. –All these values remain = v, as long as x 1 doesn’t change. –But then by time nl, P 1 sees x n = x 1, and changes x 1.

Lemma 4 Lemma 4: In any fair execution fragment , a configuration in which all the x values are the same (and so, a safe configuration) occurs within time (n 2 + n)l. Proof: –Let c = initial configuration of . –Let v = some value that doesn’t appear in any x i, in c. –Then v doesn’t appear anywhere, in , unless/until P 1 sets x 1 := v. –Within time nl, P 1 increments x 1 (by 1, mod (n+1)). –Within another nl, P 1 increments x 1 again. –… –Within n 2 l, P 1 increments x 1 to v. –Still no other v’s anywhere else… –Then this v propagates all the way around the ring. –P 1 doesn’t change x 1 until v reaches x n. –Yields all x i = v, within time (n 2 + n)l.

Putting the pieces together Legal execution fragment  : –In any state in , exactly one process is enabled. –For each i,  contains infinitely many states in which P i is enabled. L = set of legal fragments. Theorem: Dijkstra’s algorithm is self-stabilizing with respect to legal set L. Remark: –This uses n+1 values for the x i variables. –Also works with n values, or even n-1. –But not with n-2 [Dolev, p. 20].

Reducing the atomicity Dijkstra’s algorithm requires atomic read of x i-1 and write of x i. Adapt for usual model, in which only individual read/write steps are atomic: –Consider Dijkstra’s algorithm on a 2n-process ring, with processes Q j, vars y j. j = 1, 2, …, 2n. Needs 2n+1 values for the variables. P1P1 PnPn P3P3 P2P2 x1x1 x2x2 x3x3 xnxn –Run this in an n-process ring, with processes P i, variables x i. P i emulates both Q 2i-1 and Q 2i. y 2i-1 is a local variable of P i. y 2i corresponds to x i. –To emulate a step of Q 2i-1, P i reads from x i-1, writes to its local variable y 2i-1. –To emulate a step of Q 2i, P i reads from its local variable y 2i-1, writes to x i. –Since in each case one variable is internal, can emulate these steps with just read or write.

Composing self-stabilizing algorithms Consider several algorithms, where –A 1 is self-stabilizing for legal set L 1, –A 2 is SS for legal set L 2, “assuming A 1 stabilizes for L 1 ” –A 3 is SS for legal set L 3, “assuming A 1 stabilizes for L 1 and A 2 stabilizes for L 2 ” –etc. Then we should be able to run all the algorithms together, and the combination should be self-stabilizing for L1  L2  L3  … Need composition theorems. Details depend on which model we consider. E.g., consider two shared memory algorithms, A 1 and A 2.

Composing SS algorithms Consider read/write shared memory algorithms, A 1 and A 2, where: –A 1 has no “unbound” input registers: All its registers are written, and read, only by A 1 processes. –A 2 has shared registers for its private use, plus some input registers that are outputs of A 1 : Written (possibly read) by processes of A 1, only read by processes of A 2. –A 1 makes sense in isolation, but A 2 depends on A 1 for some inputs. Definition: A 2 is self-stabilizing (for L 2 ) with respect to A 1 (and L 1 ) provided that: If  is any fair execution fragment of the combination of A 1 and A 2 whose projection on A 1 is in L 1, then  has a suffix in L 2. Theorem: If A 1 is SS for L 1 and A 2 is SS for L 2 with respect to A 1 and L 1, then the combination of A 1 and A 2 is SS for L 2.

Weaker definition of SS At this point, [Dolev] seems to be using the weaker definition for self-stabilization: Instead of: –Algorithm A is self-stabilizing for legal set L if every fair execution fragment  of A contains a state s that is safe with respect to L. Now using: –Algorithm A is self-stabilizing for legal set L if every fair execution fragment  has a suffix in L. So we’ll switch here.

Composing SS algorithms Def: A 2 is self-stabilizing (for L 2 ) with respect to A 1 (and L 1 ) provided that any fair execution fragment of the combination of A 1 and A 2 whose projection on A 1 is in L 1, has a suffix in L 2. Theorem: If A 1 is SS for L 1 and A 2 is SS for L 2 with respect to A 1 and L 1, then the combination of A 1 and A 2 is SS for L 2. Proof: –Let  be any fair exec fragment of the combination of A 1 and A 2. –We must show that  has a suffix in L 2 (weaker definition of SS). –Projection of  on A 1 is a fair execution fragment of A 1. –Since A 1 is SS for L 1, this projection has a suffix in L 1. –Therefore,  has a suffix  whose projection on A 1 is in L 1. –Since A 2 is self-stabilizing with respect to A 1,  has a suffix  in L 2. –So  has a suffix in L 2, as needed. Total stabilization time is the sum of the stabilization times of A 1 and A 2.

Applying the composition theorem Theorem supports modular construction of SS algorithms. Example: SS mutual exclusion in an arbitrary rooted undirected graph –A1:–A1: Constructs rooted spanning tree, using the SS BFS algorithm. The r ij registers contain all the tree info (parent and distance). –A2:–A2: Takes A 1 ’s r ij registers as input. Solves mutual exclusion using a Dijkstra- like algorithm, which runs on the stable tree in the r ij registers. –Q: But Dijkstra’s algorithm uses a ring--- how to run it on a tree? –A: Thread the ring through the nodes of the tree, e.g.: P1P1 P5P5 P4P4 P3P3 P2P2

Mutual exclusion in a rooted tree Use the read/write version of the Dijkstra ring algorithm, with local and shared variables. Each process P i emulates several processes of Dijkstra algorithm. Bookkeeping needed, see [Dolev, p ]. Initially, both the tree and the mutex algorithm behave badly. After a while (O(diam  l) time), the tree stabilizes (since the BFS algorithm is SS), but the mutex algorithm continues to behave badly. P1P1 P5P5 P4P4 P3P3 P2P2 After another while (O(n 2 l) time), the mutex algorithm also stabilizes (since it’s SS given that the tree is stable). Total time is the sum of the stabilization times of the two algorithms: O(diam  l) + O( n 2 l) = O( n 2 l).

Self-stabilizing emulations [Dolev, Chapter 4] Design a SS algorithm A 2 to solve a problem L 2, using a model that is more powerful then the “real” one. Design an algorithm A 1 using the real model, that “stabilizes to emulate” the powerful model Combine A 1 and A 2 to get a SS algorithm for L 2 using the real model. Example [Dolev, Section 4.1]: Scheduling daemon –Rooted undirected graph of processes. –Powerful model: Process can read several variables, change state, write several variables, all atomically. –Real model: just read/write steps. –Emulation algorithm A 1 : Uses Dijkstra-style mutex algorithm over BFS spanning tree algorithm Process performs steps of A 2 only when it has the critical section (global lock). Performs all steps that are performed atomically in the powerful model, before exiting the critical section. –Initially, both emulation A 1 and algorithm A 2 behave badly. –After a while, emulation begins behaving correctly, yielding mutual exclusion. –After another while, A 2 stabilizes for L 2.

Self-stabilizing emulations Example 2 [Nolte]: Virtual Node layer for mobile networks –Mobile ad hoc network: Collection of processes running on mobile nodes, communicating via local broadcast. –Powerful model: Also includes stationary Virtual Nodes at fixed geographical locations (e.g., grid points). –Real model: Just the mobile nodes. –Emulation algorithm A 1 : Mobile nodes in the vicinity of a Virtual Node’s location cooperate to emulate the VN. Uses Replicated State Machine strategy, coordinated by a leader. –Application algorithm A 2 running over the VN layer: Geocast, or point-to-point routing, or motion coordination,… –Initially, both the emulation A 1 and the application algorithm A 2 behave badly. –Then the emulation begins behaving correctly, yielding a VN Layer. –Then the application stabilizes.

Making non-self-stabilizing algorithms self-stabilizing [Dolev, Section 2.8]: Recomputation of floating outputs. –Method to convert certain non-SS distributed algorithms to SS algorithms. What kind of algorithms? –Algorithm A, computes a distributed function based on distributed inputs. –Assumes processes’ inputs are in special, individual input variables, I i, whose values never change (e.g., contain fixed information about local network topology). –Outputs placed in special, individual output variables O i. Main idea: Execute A repeatedly, from its initial state, with the fixed inputs, with two kinds of output variables: –Temporary output variables o i. –Floating output variables FO i. Use the temporary variables o i the same way A uses O i. Write to the floating variables FO i only at the end of function computation. When restarting A, reset all variables except the floating outputs FO i. Eventually, the floating outputs should stop changing.

Example: Consensus Consider synchronous, non-fault-tolerant network consensus algorithm. Undirected graph G = (V,E), known upper bound D on diameter. Non-SS consensus algorithm A: –Everyone starts with Boolean input in I i. –After D rounds, everyone agrees, and decision value = 1 iff someone’s input = 1. –At intermediate rounds, process i keeps current consensus proposal in O i. –At each round, send O i to neighbors, resets O i to “or” of its current value and received values. –Stop after D rounds. A works fine, in synchronous model, if it executes once, from initial states.

Example: Consensus To make this self-stabilizing: –Run algorithm A repeatedly, with the FO i as floating outputs. –While running A, use o i instead of O i. –Copy o i to FO i at the end of each execution of A. This is not quite right… –Assumes round numbers are synchronized. –Algorithm begins in an arbitrary global state, round numbers can be off. So, must also synchronize round numbers 1,2,…,D. –Needs a little subprotocol. –Each process, at each round, sets its round number to max of its own and all those of its neighbors. –When reach D, start over at 1. Eventually, the rounds become synchronized throughout the network. Thereafter, the next full execution of A succeeds, produces correct outputs in the FO i variables. Thereafter, the FO i will never change.

Extensions Can make this into a fairly general transformation, for synchronous algorithms. Using synchronizers, can extend to some asynchronous algorithms.

Making non-SS algorithms SS: Monitoring and resetting [Section 5.2] Also known as checking and correction. Assumes message-passing model. Basic idea: –Continually monitor the consistency of the underlying algorithm. –Repair the algorithm when inconsistency is detected. For example: –Use SS leader election service to choose a leader (if there isn’t already a distinguished process). –Leader, repeatedly: Conducts global snapshots, Checks consistency, Sends out corrections if necessary. Local monitoring and resetting: –For some algorithms, can check and restore local consistency predicates. –E.g., BFS: Can check that local distance is one more than parent’s distance, recalculate dist and parent if not. –[Varghese thesis]

Other stuff in the book Proof methods for showing SS. Stabilizing to an abstract specification. Practical motivations. Model conversions, for SS algorithms: –Shared memory  message-passing –Synchronous  asynchronous Converting non-SS algorithms to SS algorithms SS in presence of ongoing failures. –Stopping, Byzantine, message loss. Efficient “local” SS algorithms. More examples.