1 Randomized Concurrent Algorithms Based on slides by Dan Alistarh Giuliano Losa.

Slides:



Advertisements
Similar presentations
ON THE COMPLEXITY OF ASYNCHRONOUS GOSSIP Presented by: Tamar Aizikowitz, Spring 2009 C. Georgiou, S. Gilbert, R. Guerraoui, D. R. Kowalski.
Advertisements

The Contest between Simplicity and Efficiency in Asynchronous Byzantine Agreement Allison Lewko The University of Texas at Austin TexPoint fonts used in.
N-Consensus is the Second Strongest Object for N+1 Processes Eli Gafni UCLA Petr Kuznetsov Max Planck Institute for Software Systems.
A General Characterization of Indulgence R. Guerraoui EPFL joint work with N. Lynch (MIT)
Michael Alves, Patrick Dugan, Robert Daniels, Carlos Vicuna
Mutual Exclusion By Shiran Mizrahi. Critical Section class Counter { private int value = 1; //counter starts at one public Counter(int c) { //constructor.
CPSC 668Set 18: Wait-Free Simulations Beyond Registers1 CPSC 668 Distributed Algorithms and Systems Fall 2006 Prof. Jennifer Welch.
Announcements. Midterm Open book, open note, closed neighbor No other external sources No portable electronic devices other than medically necessary medical.
CSCE 668 DISTRIBUTED ALGORITHMS AND SYSTEMS Fall 2011 Prof. Jennifer Welch CSCE 668 Self Stabilization 1.
Deterministic Selection and Sorting Prepared by John Reif, Ph.D. Analysis of Algorithms.
Consensus problem Agreement. All processes that decide choose the same value. Termination. All non-faulty processes eventually decide. Validity. The common.
UMass Lowell Computer Science Analysis of Algorithms Spring, 2002 Chapter 5 Lecture Randomized Algorithms Sections 5.1 – 5.3 source: textbook.
1 © R. Guerraoui Implementing the Consensus Object with Timing Assumptions R. Guerraoui Distributed Programming Laboratory.
Planning under Uncertainty
CPSC 668Set 10: Consensus with Byzantine Failures1 CPSC 668 Distributed Algorithms and Systems Fall 2009 Prof. Jennifer Welch.
CPSC 668Set 5: Synchronous LE in Rings1 CPSC 668 Distributed Algorithms and Systems Spring 2008 Prof. Jennifer Welch.
Tirgul 10 Rehearsal about Universal Hashing Solving two problems from theoretical exercises: –T2 q. 1 –T3 q. 2.
 Idit Keidar, Principles of Reliable Distributed Systems, Technion EE, Spring Principles of Reliable Distributed Systems Lecture 7: Failure Detectors.
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.
Tirgul 8 Universal Hashing Remarks on Programming Exercise 1 Solution to question 2 in theoretical homework 2.
Idit Keidar, Principles of Reliable Distributed Systems, Technion EE, Spring Principles of Reliable Distributed Systems Lecture 5: Synchronous Uniform.
Randomized Protocols for Asynchronous Consensus James Aspnes Distributed Computing (2003) 16:
Wait-Free Consensus with Infinite Arrivals James Aspnes Gauri Shah Jatin Shah Yale University STOC 2002.
CPSC 668Set 11: Asynchronous Consensus1 CPSC 668 Distributed Algorithms and Systems Fall 2006 Prof. Jennifer Welch.
CPSC 668Set 11: Asynchronous Consensus1 CPSC 668 Distributed Algorithms and Systems Fall 2009 Prof. Jennifer Welch.
Randomness in Computation and Communication Part 1: Randomized algorithms Lap Chi Lau CSE CUHK.
Lecture 20: April 12 Introduction to Randomized Algorithms and the Probabilistic Method.
DAST 2005 Week 4 – Some Helpful Material Randomized Quick Sort & Lower bound & General remarks…
Ch. 8 & 9 – Linear Sorting and Order Statistics What do you trade for speed?
Distributed Consensus Reaching agreement is a fundamental problem in distributed computing. Some examples are Leader election / Mutual Exclusion Commit.
CSCE 668 DISTRIBUTED ALGORITHMS AND SYSTEMS Fall 2011 Prof. Jennifer Welch CSCE 668 Set 11: Asynchronous Consensus 1.
CSCE 668 DISTRIBUTED ALGORITHMS AND SYSTEMS Fall 2011 Prof. Jennifer Welch CSCE 668 Set 18: Wait-Free Simulations Beyond Registers 1.
Jessie Zhao Course page: 1.
Consensus and Its Impossibility in Asynchronous Systems.
Ch11 Distributed Agreement. Outline Distributed Agreement Adversaries Byzantine Agreement Impossibility of Consensus Randomized Distributed Agreement.
1 Lectures on Parallel and Distributed Algorithms COMP 523: Advanced Algorithmic Techniques Lecturer: Dariusz Kowalski Lectures on Parallel and Distributed.
CS4231 Parallel and Distributed Algorithms AY 2006/2007 Semester 2 Lecture 8 Instructor: Haifeng YU.
Distributed Algorithms Lecture 10b – by Ali Ghodsi Fault-Tolerance in Asynchronous Networks – Probabilistic Consensus.
1 Chapter 9 Synchronization Algorithms and Concurrent Programming Gadi Taubenfeld © 2014 Synchronization Algorithms and Concurrent Programming Synchronization.
CSC 211 Data Structures Lecture 13
DISTRIBUTED ALGORITHMS AND SYSTEMS Spring 2014 Prof. Jennifer Welch CSCE
CSCE 668 DISTRIBUTED ALGORITHMS AND SYSTEMS Fall 2011 Prof. Jennifer Welch CSCE 668 Set 5: Synchronous LE in Rings 1.
Distributed systems Consensus Prof R. Guerraoui Distributed Programming Laboratory.
Sliding window protocol The sender continues the send action without receiving the acknowledgements of at most w messages (w > 0), w is called the window.
Chap 15. Agreement. Problem Processes need to agree on a single bit No link failures A process can fail by crashing (no malicious behavior) Messages take.
The Stable Marriage Problem
ICS 353: Design and Analysis of Algorithms
Chapter 21 Asynchronous Network Computing with Process Failures By Sindhu Karthikeyan.
Alternating Bit Protocol S R ABP is a link layer protocol. Works on FIFO channels only. Guarantees reliable message delivery with a 1-bit sequence number.
Fault tolerance and related issues in distributed computing Shmuel Zaks GSSI - Feb
“Towards Self Stabilizing Wait Free Shared Memory Objects” By:  Hopeman  Tsigas  Paptriantafilou Presented By: Sumit Sukhramani Kent State University.
Searching CSE 103 Lecture 20 Wednesday, October 16, 2002 prepared by Doug Hogan.
CS4231 Parallel and Distributed Algorithms AY 2006/2007 Semester 2 Lecture 9 Instructor: Haifeng YU.
1 Fault-Tolerant Consensus. 2 Communication Model Complete graph Synchronous, network.
Distributed Algorithms (22903) Lecturer: Danny Hendler The Atomic Snapshot Object The Renaming Problem This presentation is based on the book “Distributed.
1 Chapter 11 Global Properties (Distributed Termination)
1 Distributed Vertex Coloring. 2 Vertex Coloring: each vertex is assigned a color.
CSE 486/586 CSE 486/586 Distributed Systems Leader Election Steve Ko Computer Sciences and Engineering University at Buffalo.
Approximation Algorithms based on linear programming.
1 © R. Guerraoui Set-Agreement (Generalizing Consensus) R. Guerraoui.
PROBABILITY AND COMPUTING RANDOMIZED ALGORITHMS AND PROBABILISTIC ANALYSIS CHAPTER 1 IWAMA and ITO Lab. M1 Sakaidani Hikaru 1.
The consensus problem in distributed systems
Probabilistic Algorithms
CSCE 668 DISTRIBUTED ALGORITHMS AND SYSTEMS
CSCE 668 DISTRIBUTED ALGORITHMS AND SYSTEMS
Richard Anderson Autumn 2006 Lecture 1
CSCE 668 DISTRIBUTED ALGORITHMS AND SYSTEMS
Distributed systems Consensus
Presentation transcript:

1 Randomized Concurrent Algorithms Based on slides by Dan Alistarh Giuliano Losa

2 A simple example Two students in a narrow hallway To proceed, one of them has to change direction! Let’s allow them to communicate (registers) – They will have to solve consensus for 2 processes! I want to go forward! Register 1 Register 2 I want to move!

3 A simple example [FLP] : there exists an execution in which processes get stuck forever, or they run into each other! Does this happen in real life?! Is this possible in real life? It is unlikely that two people will continue choosing exactly the same thing! What does unlikely mean? I want to go forward! Register 1 Register 2 I want to move!

4 Slightly modified example Two people in a narrow hallway In each “round”, – choose an option (go forward or move laterally) with probability 1 / 2 – write it to the register If they chose different options, they finish, otherwise continue Pr[ finish in round 1 ] = 1 / 2 Pr[continue after round r] = (1 / 2) r For example, Pr[ continue for > 10 rounds ] < I want to go forward! I want to move! Register 1 Register 2

5 Analysis Always finishes in practice! Does there still exist an execution in which they do not finish? – Do we contradict FLP? Yes, the infinite execution is still there – We do not contradict FLP! What is the probability of that infinite execution?

6 The problem has changed! By allowing processes to make random choices, we give probability to executions Bad executions (like in FLP) should happen with extremely low probability (in this case, 0) We ensure safety in all executions, but termination is ensured with probability 1

7 The plan for today Intro – Motivation The randomized model A Randomized Test-and-Set algorithm – From 2 to N processes Randomized Consensus – Shared Coins Randomized Renaming

8 Semantics of deterministic algorithms, correctness, limitations. An algorithm denotes a set of histories Solving consensus means solving it in all possible histories. FLP: consensus is impossible in an asynchronous systems if a single process may crash.

Solving problems with good probability We need to assign probabilities to histories – Probability distribution on scheduling? – Probability distribution on inputs? No, we don’t have control over these in practice Instead: – Processes make independent random choices (they flip coins). – Schedule and inputs determined by a deterministic adversary (a function of the history so far). – We look at the worst possible adversary 9

Semantics of randomized protocols A protocol and an adversary (P,A) denote a set of histories and an associated probability distribution. A pair (P,A) and a sequence of bits s uniquely determine a history of the algorithm P. The probability of a given execution is the probability of the sequence of bits that corresponds to it. 10

Correctness Properties for Randomized Algorithms We define the class of adversaries we consider. Usually, we keep the safety condition of the deterministic problem and relax liveness: “The algorithm should terminate with probability 1 for all adversary in the class” 11

12 Example: Consensus Validity: if all processes propose the same value v, then every correct process decides v. Integrity: every correct process decides at most one value, and if it decides some value v, then v must have been proposed by some process. Agreement: if a correct process decides v, then every correct process decides v. Termination: every correct process decides some value.

13 Randomized Consensus Adversary: any deterministic adversary. Validity: if all processes propose the same value v, then every correct process decides v. Integrity: every correct process decides at most one value, and if it decides some value v, then v must have been proposed by some process. Agreement: if a correct process decides v, then every correct process decides v. (Probabilistic) Termination: with probability 1, every correct process decides some value.

14 The simple example Two people in a narrow hallway In each “round”, – choose an option (go forward or move) with probability 1 / 2 – write it to the register If they chose different options, they finish, otherwise continue What is the worst case adversary? Arriving on the same side and scheduled in lock-steps. What is the probability of finishing in less than 2 rounds? ½ * ½ + ½ = ¾ I want to go forward! I want to move! Register 1 Register 2

Test-and-set specification Sequential specification: V, a binary register, initially 0 procedure Test-and-Set() if V = 0 then V ← 1 return winner else return loser T&S winner loser Test-and-set() winner loser Linearization: The winner always returns first!

16 2-process test-and-set Based on the previous “hallway” example Two SWMR registers R[1], R[2] – Each owned by a process A register R[p] can have one of 2 possible values: – Mine, Yours Processes express their choices through the registers Adapted from an algorithm by Tromp and Vitanyi (see references at the end).

17 2-process test-and-set Shared: Registers R[p], R[p’], initially Yours Local: Registers last_read[p], last_read[p’] procedure test-and-set p () //at process p 1.R[p] <- Mine 2.Loop 3. last_read[p] <- R[p’] 4. If (R[p] = last_read[p]) 5. R[p] <- Random(Yours,Mine) 6. Else break; 7.EndLoop 8.If R[p] = Mine then return 1 9.Else return 0

18 Correctness (rough sketch) Worst case adversary: lock-step scheduling. Unique Winner: Inductive invariants: – If both processes are at lines 4, 8, or 9, then one of them has a accurate last_read value. – If process p is at lines 8 or 9, then last_read[p] is different from R[p]. Termination: – Every time processes execute the coin flip in line 5, the probability that the while loop terminates in the next iteration is ½. Hence, the probability that the algorithm executes more than r coin flips is (1/2) r. Therefore, the probability that the algorithm goes on forever is 0.

19 Performance What is the expected number of steps that a process performs in an execution? We need to consider the worst case adversary: the lock-steps schedule. Consider the random var T counting the number of rounds before termination. T counts the number of trials before first success in a series of independent binary trials with probability p = ½. T has geometric distribution. The expected number of rounds is 1/p = 2!

20 From 2 to N processes We know how to decide a single “match” How do we get a single winner out of a set of N processes? T&S winner loser

21 The tournament T&S winner

22 Question T&S winner What if only one guy shows up? Since each T&S is wait-free, the single guy will win! What is the height of the tree?

23 Correctness Unique winner: Suppose there are two winners. Then both would have to win the root test-and-set, contradiction Termination (with probability 1!): Follows from the termination of 2-process test-and- set Winner: Either there exists a process that returns winner, or there is at least a failure Is this it?

24 How about this property? Test-and-set() 1 0 Linearization: T&S winner T&S

25 How about this? Test-and-set() 0 1 Linearization: T&S winner T&S Loser Winner Loser

26 Homework Fix the N-process test-and-set implementation so that it is linearizable Hint: you only need to add one register

27 Wrap up We have a test-and-set algorithm for N processes Always safe Terminates with probability 1 Worst-case local cost O( log N ) per process Expected total cost O( N )

28 The plan for today Intro – Motivation Some Basic Probability A Randomized Test-and-Set algorithm – From 2 to N processes Randomized Consensus – Shared Coins Randomized Renaming

29 Randomized Consensus Can we implement Consensus with the same properties?

30 Randomized Consensus Algorithms based on a Shared Coin A Shared coin with parameter ρ, SC(ρ) is an algorithm without inputs, which has probability ρ that all outputs are 0, and probability ρ that all outputs are 1. Example: – Every process flips a local coin, and returns 1 for Heads, 0 for Tails – ρ = Pr[ all outputs are 1 ] = Pr[ all outputs are 0 ] = (1/2) N – Usually, we look for higher output parameters The higher the parameter, the faster the algorithm

31 Shared Coin -> Binary Consensus The algorithm will progress in rounds Processes share a doubly-indexed vectors Proposed[r][i], Check[r][i] (r = round number, i = process id) Proposed[][] stores values, Check[][] indicates whether a process finished At each round r > 0, process p i places its vote (0 or 1) in Proposed[r][i]

32 Shared Coin->Binary Consensus Shared: Matrices Proposed[r][i]; Check[r][i], init. to null. procedure propose i ( v ) //at process i 1.decide = false, r = 0 2.While( decide == false ) 3. r = r Proposed[r][i] = v 5. view = Collect( Proposed[r] […]) 6. if (both 0 and 1 appear in view ) 7. Check[r][i] = disagree 8. else Check[r][i] = agree 9. check-view = Collect( Check[r] […]) 10. if( disagree appears in check-view ) 11. if (for some j, check-view[j] = agree) 12. v = Proposed[r][j] 13. else v = flip_coin() 14. else decide = true 15.return v In each round r, the process writes its value in Proposed[r][i] It then checks to see if there is disagreement, and marks it to Check[r][i] If there is disagreement, then processes flip a shared coin to agree, and post the results If no-one disagrees, then return!

33 Correctness Shared: Matrices Proposed[r][i]; Check[r][i] procedure propose i ( v ) //at process i 1.decide = false, r = 0 While( decide == false ) r = r + 1 Proposed[r][i] = v view = Collect( Proposed[r] […]) if (both 0 and 1 appear in view ) Check[r][i] = disagree else Check[r][i] = agree check-view = Collect( Check[r] […]) if( disagree appears in check-view ) coin = SharedCoin(r) if (for some j, check-view[j] = agree) v = Proposed[r][j] else v = coin else decide = true return v Validity: If everyone proposes the same v, then Check=agree, so they decide on v Agreement: If process p decides v, then either all processes wrote v, or slower processes will adopt v in line 13 Termination?

34 Termination Worst case adversary: lock-steps schedule. Processes have probability at least 2ρ of flipping the same value at every round r If all processes have the same value at round r then they decide in round r. What is the probability that they go on forever? (1 – 2p)x(1-2p)x(1-2p)x… = 0

35 What does this mean? We can implement consensus ensuring – safety in all executions – termination with probability 1. By the universal construction, we can implement anything with these properties So…are we done with this class? The limit is no longer impossibility, but performance!

36 Homework 2: Performance What is the expected number of rounds that the algorithm runs for, if the Shared coin has parameter ρ? In particular, what is the expected running time for the example shared coin, having ρ = (1/2) n ? – Termination time T is a random variable mapping a history to the number of steps before termination – Each round is akin to an independent binary trial with success probability ρ, hence T has geometric distribution. – The expectation of T is 1/ ρ = 2^n Can you come up with a better shared coin?

37 The plan for today Intro – Motivation Some Basic Probability A Randomized Test-and-Set algorithm – From 2 to N processes Randomized Consensus – Shared Coins Randomized Renaming

N processes, t < N might fail by crashing Huge initial ID’s (think IP Addresses) Need to get new unique ID’s from a small namespace ( e.g., from 1 to N ) The opposite of consensus The Renaming Problem Renaming

Why is this useful? Getting a small unique name is important – Smaller reads and writes/messages – Overall performance – Names are a natural prerequisite Renaming is related to: – Mutual exclusion – Test-and-set – Counting – Resource allocation Renaming

What is known Both Shared-Memory and Message-Passing Analogous to FLP, much more complicated Uses Algebraic Topology! Gödel Prize 2004 Theorem [HS, RC] In an asynchronous system with t < N crashes, Deterministic Renaming is impossible in N + t - 1 or less names.

41 How can randomization help? It will allow us to get a tight namespace (of N names), even in an asynchronous system It will give us better performance Idea: derive renaming from test-and-set We now know how to implement test-and-set in an asynchronous system

Shared: V, an infinite vector of randomized test-and-set objects procedure getName(i) j ← 1 while( true ) res ← V[j].Test-and-set i () if res = winner then return j else j ← j + 1 Renaming from Test-and-Set #1#2#3#4#5 … Name = 3 #N

Shared: V, an infinite vector of test-and-set objects procedure getName(i) j ← 1 while( true ) res ← V[j].Test-and-set i () if res = winner then return j else j ← j + 1 Performance What is the worst-case local complexity? O(N) What is the worst-case total complexity? O(N 2 ) #1#2#3#4#5 … #N Where is the randomization?

Shared: V, an infinite vector of test-and-set objects procedure getName(i) while( true ) j = Random(1, N) res ← V[j].Test-and-set i () if res = winner then return j Randomized Renaming #1#2#3#4#5 … Name = 3 #N

Shared: V, an infinite vector of test-and-set objects procedure getName(i) while( true ) j = Random(1, N) res ← V[j].Test-and-set i () if res = winner then return j Randomized Renaming 1.Claim: The expected total number of tries is O( N log N)! Sketch of Proof (not for the exam) : A process will win at most one test-and-set Hence it is enough to count the time until each test-and- set is accessed at least once! N items, we access one at random every time; how many accesses until we cover all N of them? Coupon collector: we need < 2N log N total accesses, with probability 1 – 1 / N 3 #1#2#3#4#5 … #N

46 Wrap-up Termination ensured with probability 1 Total complexity: O( N log N ) total operations in expectation

47 Conclusion Randomization “avoids” the deterministic impossibility results (FLP, HS) – The results still hold, the bad executions still exist – We give bad executions vanishing probability, ensuring termination with probability 1 The algorithms always preserve safety Usually we can get better performance by using randomization

48 References (use Google Scholar) For randomization in general: – Chapter 14 of “Distributed Computing: Fundamentals, Simulations, and Advanced Topics”, by Hagit Attiya and Jennifer Welch For the test-and-set example: – “Randomized two-process wait-free test-and-set” by John Tromp and Paul Vitányi. – “Wait-free test-and-set” by Afek et al. For the randomized consensus example: – “Optimal time randomized consensus”by Saks, Shavit, Woll. – “Randomized Protocols for Asynchronous Consensus” by Aspnes. For the renaming example: – “Fast Randomized Test-and-Set and Renaming” by Alistarh, Guerraoui et al.