Efficient Condition-Based Consensus in Asynchronous Distributed - PowerPoint PPT Presentation

Efficient Condition-Based Consensus in Asynchronous Distributed Systems Achour Most´ efaoui, Sergio Rajsbaum Michel Raynal and Matthieu Roy mroy@irisa.fr Efficient Condition-Based Consensus – p.1/25

� � � � � � � � Summary Computation model and the Consensus Problem The Condition-Based approach Definitions, A simple protocol. Efficient protocol for consensus A hierarchy of conditions, A tailored read/write primitive, A generic formula for defining conditions. Efficient Condition-Based Consensus – p.2/25

� � � � � � � ✞ ✞ ✞ ☎ Computation Model An a priori known set of processes , ✁✄✂✆☎ ✁✄✝✆☎ ✁✠✟ Communication via Shared Memory (supposed to be reliable) Asynchronous Model of failures: Fail-stop. At most processes may crash, A correct process is a process that does not crash. Efficient Condition-Based Consensus – p.3/25

� � � The Consensus Problem Specification: Termination: Every correct process eventually decides some value, Validity: A decided value is a proposed value, Agreement: No two processes decide different values. Efficient Condition-Based Consensus – p.4/25

� � Impossibility Theorem Fischer-Lynch-Paterson’s Impossibility result (FLP 85) There is no deterministic protocol that solves the consensus problem is an asynchronous distributed system prone to even a single crash failure Efficient Condition-Based Consensus – p.5/25

Solving the Consensus How to circumvent FLP result ? Efficient Condition-Based Consensus – p.6/25

� � � Solving the Consensus How to circumvent FLP result ? Change specification -set agreement (Chaudhuri 90) Efficient Condition-Based Consensus – p.6/25

� � � � � � Solving the Consensus How to circumvent FLP result ? Change specification -set agreement (Chaudhuri 90) Add oracles Failure detectors (Chandra & Toueg 91) Random generator (Ben Or 83, Rabin 83) Efficient Condition-Based Consensus – p.6/25

� The Condition-Based Approach FLP says: “you can’t build a protocol that solves consensus for any input configuration” Efficient Condition-Based Consensus – p.7/25

� � The Condition-Based Approach FLP says: “you can’t build a protocol that solves consensus for any input configuration” We define a set of input configurations that for which the consensus problem is solvable despite up to crashes. 0011 1110 0100 1010 0001 1101 V ={0,1}, and n=4 0000 0010 V: set of proposable values 1100 0101 V^n: set of all possible input vectors 1111 0110 1011 1001 0111 1000 Efficient Condition-Based Consensus – p.7/25

� � The Condition-Based Approach FLP says: “you can’t build a protocol that solves consensus for any input configuration” We define a set of input configurations that for which the consensus problem is solvable despite up to crashes. 0011 1110 0100 1010 0001 1101 0000 Decide 0 0010 1100 0101 1111 0110 Decide 1 1011 1001 0111 1000 Efficient Condition-Based Consensus – p.7/25

� � � Previous Works on Conditions STOC’01: A characterization of Conditions that make the Consensus problem solvable. PODC’01: A hierarchy of conditions that shows a tradeoff between termination and communication load. SIROCCO’01: an early stopping protocol, an adaptative version of PODC protocol. Efficient Condition-Based Consensus – p.8/25

� � � The Condition-Based Approach We want to design protocols that: Are always safe (agreement and validity), Solve consensus when the inputs (proposed values) satisfy an a priori known pattern, Make the best effort to terminate,e.g. always terminate when no process crashes. Efficient Condition-Based Consensus – p.9/25

� � � � The Condition-Based Approach We want to design protocols that: Are always safe (agreement and validity), Solve consensus when the inputs (proposed values) satisfy an a priori known pattern, Make the best effort to terminate,e.g. always terminate when no process crashes. Let’s change the termination property: if the input pattern belongs to the condition and no more than processes crash, then every correct process decides. Efficient Condition-Based Consensus – p.9/25

✟ � ✄ � � ✄ ✠ ✡ ☛ � � ☞ � � � � ✟ ✞ Some notations is the set of proposable values, and denotes “no value”, an input vector is an -entry vector of : if proposes , then ☎✝✆ , ✁ ✂✁ denotes the number of occurrences of in . a Condition is a subset of . Efficient Condition-Based Consensus – p.10/25

� ✆ ✆ � ✞ ✟ � ✆ ✄ ✞ ✟ � ☎ ☎ ✞ ☎ ☛ � � � ✞ ✟ ✡ � ✌ ✠ ✟ ✂ ☞ � � � � ✁ � � ☎ ✟ � ✆ � ✆ ✄ � ☎ � ✝ ✆ ✞ ✆ ✟ ✂ Local views a local view , denoted , is an -entry vector of that contains at most , dominates , denoted , if ☎✝✆ ☎✝✆ , if , let the uncertainty neighborhood of be . �☛✡ Efficient Condition-Based Consensus – p.11/25

☛ ☎ ✡ � ✆ � ☎ ✞ ☞ ✡ � ✆ ☛ ☞ ✡ � ☛ ✠ � ✂ ☎ � � ☛ ☎ ✡ � � ✟ ☛ ✆ � ✡ ✡ ✞ ✝ ☛ ✝ ✞ � ✡ ☎ � � ✞ � � ✡ � ☛ � � ✠ ☎ ✆ � ☎ ✆ � ✝ ✠ ✂ ✡ ☎ ✡ � ☛ � ✡ ✆ Acceptability of a Condition A condition is said to be -weak-acceptable iff there exist a predicate and a function s. t. : Property T : (Termination) ✁✄✂ Property A : (Agreement) Property V : (Validity) = a non- value of Efficient Condition-Based Consensus – p.12/25

� � � Acceptability of a Condition the predicate tells a process if it can decide based on its local view, the function calculates the decision value for a process that can terminate. Theorem : The set of -weak-acceptable conditions is exactly the set of conditions for which there exists a protocol. Efficient Condition-Based Consensus – p.13/25

� ✄ ☎ ☛ � ✡ � ✟ ✄ � ☛ � ✡ � � � � � � � � A simple protocol Each process writes its input value in a shared vector , reads using snapshot until it gets a view containing at least non- values, if holds, then it calculates , writes it into a decision vector and decides , else it writes in and repeats reading until it reads a non- value or until all processes have written a , then it decides. Efficient Condition-Based Consensus – p.14/25

� � � � � � � A simple protocol (2) The former protocol can be used with any acceptable condition uses a strong tool : snapshot generates an order on local views reduces the “entropy” of the global view but is costly can the read/write model be weakened ? Yes, if conditions are stronger Efficient Condition-Based Consensus – p.15/25

✡ � � � ☎ ☛ � ✡ ✆ ☛ ☛ ✟ � ✡ � ☎ ☞ ✆ � ✆ ☎ � � ☎ ✂ ✆ ✡ � � ✆ � ☎ ☛ ☞ ✡ ☛ A Hierarchy of Condition The acceptability properties can be made stronger: the previous definition of Property A was: : all views are ordered. Efficient Condition-Based Consensus – p.16/25

� � � � ✆ � ☎ ☛ � ☎ � � ✡ � ✆ ☎ ☎ ☛ ✡ ✡ ✡ � ✆ � ☎ ☛ ✌ ✡ ✌ ✡ � ☛ � ☛ ✡ � � ☛ ☎ ✂ ✆ ☛ ✡ � ✆ � ☎ ☛ ☞ � ✡ ✆ ☛ ☞ ✡ � ☎ ☛ � ✡ � ✆ ☛ ✟ � ✆ A Hierarchy of Condition The acceptability properties can be made stronger: the previous definition of Property A was: : all views are ordered. we define -Agreement by replacing by or processes are not ordered if they have enough information. Efficient Condition-Based Consensus – p.16/25

� ✡ ✌ ✡ ☞ � ✆ ☞ ☛ ✟ ✡ ☛ ✟ ✡ ☞ � � � � � � � � � � � � � � ✒ � � � � � � � � � � � � � � � � � � � � � � � � � � ✎ ✟✑ ✑ � � ✏ ✞ ✄ ✠ ✂ ✁ � ✄ ✠ ✂ ✂ ☞ � ✄ ✞ ✞ ✞ ✡ ✆ ☛ � ☎ ✡ ✌ ✠ ✂ ✁ � � ✞ ✞ � � � � � � � � � � � � ☞✓ � ✆ ✄ � ✒ � ☎ ✠ ✂ ✝ � ✄ ✠ ✂ ✂ � � A Hierarchy of conditions If is the set of acceptable conditions, then ✁✆☎ What is the interest of such a hierarchy ? a small gives bigger conditions, but requires a strong read/write model. ✞✠✟ ✆ ✍✌ when increases, conditions get smaller, but synchrony requirements are reduced. Efficient Condition-Based Consensus – p.17/25

� ✌ ☎ � ✡ ✌ ☛ ✆ ☛ ✡ ✡ � ☛ ☛ ☎ � ✆ � ✡ ✡ ☛ Reducing communication load How to implement a primitive that ensures ? or Efficient Condition-Based Consensus – p.18/25