Consensus Concurrent problem
-
Upload
gianvito-siciliano -
Category
Technology
-
view
76 -
download
0
description
Transcript of Consensus Concurrent problem
Gianvito Siciliano Lorenzo Valente
Altri problemi del Consenso
• Introduzione al problema del consenso
• Problema del K-Agreement
• Problema del Commit
Problema del consenso • Un gruppo di processi deve mettersi d’accordo su un valore: è
l‘astrazione di una classe di problemi in cui i processi partono con le loro opinioni (eventualmente divergenti) e devono accordarsi su un’opinione comune
• Validity: Se un processo decide per un valore, allora quel valore è stato proposto da qualche processo.
• Termination: Prima o poi ogni processo attivo prende una decisione
• Agreement: Nessuna coppia di processi attivi decide per due valori diversi
Un processo si definisce attivo se non è fallito alla fine del round corrente
Consenso: sistema sincrono • Il sistema comprende n processi comunicanti tramite scambio
di messaggi
• I canali di comunicazione sono affidabili
• Al più f processi sono soggetti a fallimenti (stopping failure)
• Il processo pi (i=1…n) possiede una propria variabile di decisione, e propone un proprio valore vi appartenente ad un insieme D.
• Ciascun processo parte da uno stato di indecisione e mira a raggiungere uno stato di decisione, in cui il valore di è immutabile.
Il problema del K-Agreement
È una generalizzazione del problema del consenso, nella quale viene chiesto ai processi di accordarsi, non sullo stesso valore, ma su un insieme k di valori. Utilizzi: • Frequenze di trasmissione in una rete di
comunicazione
Ambiente • Distribuito
• Sincrono
• Modello a grafo per la rete (completo e indiretto con n nodi)
• Link della rete sicuri (nessuna possibilità di perdita di messaggi)
• Nodi della rete insicuri (possibilità di fallimenti nei processi)
• Input e valori decisionali compresi in un insieme V finito e totalmente ordinato.
K-Agreement: requisiti • Validity: Se un processo decide per un valore allora
quel valore è il valore iniziale di qualche processo (Strong validity per 1-Agreement)
• Termination: Ogni processo attivo fino alla fine prende una decisione
• Agreement: 1. Tutti i valori di decisione appartengono ad un
insieme W sottoinsieme di V 2. Ci sono al più k valori decisionali differenti (|W| = k)
Algoritmo FloodMin Informalmente:
1. Ogni processo memorizza il valore minimo (min-val) del round precedente (inizialmente è il suo valore di input)
2. Per ogni round: • I processi inviano in broadcast il loro min-val • Ogni processo resetta il suo min-val in base ai
vecchi valori e a quelli ricevuti nei messaggi del round corrente
3. Alla fine il valore decisionale sarà il min-val
Round del FloodMin
Quanti round servono per garantire la soluzione? • 1-Agreement: f+1 round • K-Agreement: (f/k) + 1 round
Consentendo k valori decisionali, il numero di round totali viene diviso per k.
FloodMin: formale • Statesi:
• rounds ∈ N (inizialmente 0) • decision ∈ V ∪ {unknown} (inizialmente 0) • min-val ∈ V (inizialmente input)
• Msgsi: Se rounds <= (f/k) allora invia min-val a tutti gli altri processi
• Transi: rounds := rounds + 1; mj := messaggio ricevuto da ogni processo j min-val := min({min-val} ∪ {mj : j≠i}) se rounds = (f/k)+1 allora decision := min-val
FloodMin: prova di correttezza • Teorema:
FloodMin, per (f/k) + 1 round, risolve il problema del K-Agreement
• Lemma 1: M(r) = insieme dei min-val dei processi attivi dopo r round => l’insieme può solo decrescere => ogni min-val dopo r+1 è un min-val dopo r round
• Lemma 2: ∀d ∈ N, d ≤ f+1, se durante r con 1 ≤ r ≤ (f/k)/1, falliscono al più d-1 processi, allora |M(r)| ≤ d. … ci sono, cioè, al più d differenti min-val per i processi attivi dopo il ciclo r.
Dimostrazione Lemma 1 M(r) ⊆ M(r-1) per ogni r, 1 ≤ r ≤ (f/k) + 1
Dimostrazione: 1. Supponiamo che m∈M(r), allora min-val i = m per qualche
processo i, per definizione di M(r). 2. Esistono due possibili casi:
a) min-vali = m alla fine del round r – 1 b) min-valj = m per qualche j alla fine del round r – 1
3. Quindi: a) Se i era attivo al round r lo era anche dopo il round r-1 b) Se j ha inviato min-valj al round r, era attivo alla fine del
round r-1 In ogni caso, m∈M(r-1)
Dimostrazione Lemma 2 Se al più d-1 processi falliscono nel ciclo r,
allora |M(r)| ≤ d
Dimostrazione (per assurdo): 1. Supponiamo che |M(r)| > d (dimostrare che almeno d processi
falliscano in r) 2. Sia m = max(M(r)) e m’ ≠ m un qualsiasi elemento in M(r). 3. Allora m’∈M(r-1) per il Lemma 1 4. Sia pi t.c. m’=min-vali al round r-1. Se i non fallisse durante il
round r, ogni processo riceverebbe il valore m’ e quindi non esisterebbe un pj t.c. m=min-valj siccome m>m’. Segue che pi fallisce durante il round r.
5. Per ogni elemento m’∈M(r) t.c. m’ ≠ m, un processo fallisce durante il round r. Se |M(r)| > d, falliscono almeno d processi (che contraddice l’ipotesi)
Dimostrazione Teorema L’algoritmo FloodMin risolve il problema del K-Agreement per il
modello con stopping failure.
Dimostrazione: • Validity / Termination: facile
• Agreement: 1. Assumiamo un esecuzione con > k valori decisionali differenti. 2. Quindi il numero dei min-val per i processi attivi dopo i (f/k)+1
round è > k 3. Per il Lemma1, |M((f/k)+1)|>k => |M(r)|>k, per ogni 0≤r≤(f/k)
+1… 4. Per il Lemma2, almeno k processi falliscono in ogni round. 5. Quindi ci sono almeno ((f/k)+1)*k fallimenti totali, che è > f …Contraddizione!
FloodMin: Complessità
• Il numero di round (f/k)+1
• Sia n il numero di processi della rete; il numero di msg sarà al più ((f/k)+1)*n2
• Sia b un upper bound del numero di bit necessari per rappresentare un msg (ovvero un singolo elemento di V); il numero di bit inviati sarà ((f/k)+1)*n2*b
Il problema del Commit Un gruppo di processi partecipa per arrivare ad una decisione: approvare o meno una transazione (ad esempio, scrittura in un Database). Due possibili decisioni: • Commit (il risultato della transazione viene reso
permanente) • Abort (il risultato della transazione viene scartato)
Ambiente • Distribuito
• Sincrono
• Link della rete sicuri (nessuna possibilità di perdita di messaggi)
• Nodi della rete insicuri (possibilità di fallimenti nei processi)
Formulazione formale • Input e Output: {0, 1}
• Agreement: Tutti i processi prendono la stessa decisione
• Validity: 1. Se uno qualsiasi dei processi decide 0, allora 0 sarà l’unica
decisione finale possibile 2. Se tutti i processi decidono 1, allora 1 sarà l’unica decisione
finale possibile
• Termination: 1. Weak: In assenza di fallimenti, garantisce che tutti i processi
arrivino prima o poi ad una decisione 2. Strong: Garantisce che tutti i processi non fallimentari
arrivino prima o poi ad una decisione
Gli algoritmi del Commit
• Algoritmi bloccanti: Algoritmi che garantiscono la Weak termination ma non la Strong termination. Un unico fallimento può pregiudicare la corretta terminazione di ogni processo e potrebbero verificarsi condizioni di stallo.
• Algoritmi non bloccanti: Algoritmi che garantiscono sia la Weak termination che la Strong termination. Solo i processi fallimentari possono non giungere alla corretta terminazione
L’algoritmo del Commit a due fasi
• Pro: semplice ed intuitivo
• Contro: non garantisce la Strong termination
• Possibili stati dei processi:
1 (ha deciso Commit)
0 (ha deciso Abort)
Uncertain Failed
L’algoritmo del Commit a due fasi
Prima fase: Uno dei processi assume il ruolo di coordinatore, raccoglie le decisioni prese dal gruppo (0 o 1) e le inserisce in un vettore. Le decisioni non pervenute costituiscono un valore nullo nel vettore. • Se tutte le decisioni hanno valore 1, allora il coordinatore decide
1; • Se almeno una delle decisioni è nulla o 0, allora il coordinatore
decide 0.
Seconda fase: Il coordinatore invia la sua decisione a tutti gli altri processi, i quali la assumono come decisione finale
L’algoritmo del Commit a due fasi 7.3. THE C O M M I T P R O B L E M 185
processes
1 . . . . . . . . "l
2
3
4
1 2 rounds
F i g u r e 7.4: Communication pattern in TwoPhaseCommit.
messages. Then no other process ever learns process l ' s initial value, so, because of the validity condition, no process can decide 1. On the other hand, no process can decide 0, since as far as any other process can tell, it might be that process 1 has already decided 1 just before failing, and the inconsistency would violate the agreement condition.
C o m p l e x i t y a n a l y s i s . TwoPhaseCommit takes only two rounds. Recall that Theorem 6.33 gives a lower bound of f + 1 on the number of rounds for stopping agreement. The time bound for TwoPhaseCommit does not contradict this lower bound, because TwoPhaseCommit satisfies only the weak termination condition. The communication complexity, as measured by the worst-case number of non- null messages that are sent in any execution, is 2 n - 2; in particular, this number of messages is sent in a failure-free execution.
7 . 3 .3 T h r e e - P h a s e C o m m i t
Now we describe the ThreePhaseCommit algorithm; this is an embellishment of the TwoPhaseCommit algorithm that guarantees strong termination.
The key is simply that process 1 does not decide 1 unless every process that has not yet failed is "ready" to decide 1. Making sure they are ready requires an extra round. We first describe and analyze the first three rounds
Esempio: Fase 1
2 3
1
4 5
Esempio: Fase 1
2 3
1
4 5
✔
✗ ✔ ✔
Esempio: Fase 1
5 2 3
1
4
Esempio: Fase 1
4 5
1 1 1 0
v[i] != null && v[i] == 1 ?
2 3
1
Esempio: Fase 1
4 5
1 1 1 0 1
v[i] != null && v[i] == 1 ?
2 3
Esempio: Fase 2
1
4 5 2 3
Esempio: Fase 2
2 3
1
4 5
Terminazione
L’algoritmo a due fasi risolve il problema del Commit garantendo solamente la Weak condition.
Questo perché, nel caso in cui sia il processo 1 a fallire, non sarebbe garantito l’arrivo ad una decisione per gli altri processi. Un ulteriore fallimento di uno dei processi, inoltre, potrebbe portare a condizioni di stallo
1
• Pro: Introduce lo stato ready per evitare le ambiguità dell’algoritmo a due fasi. Introduce inoltre un protocollo di terminazione che garantisce la Strong termination.
• Contro: complessità computazionale e di progettazione maggiore
• Possibili stati dei processi:
1 (ha deciso Commit)
0 (ha deciso
Abort)
Ready Uncertain Failed
L’algoritmo del Commit a tre fasi
L’algoritmo del Commit a tre fasi Prima fase: Uno dei processi assume il ruolo di coordinatore, raccoglie le decisioni prese dal gruppo (0 o 1) e le inserisce in un vettore. Le decisioni non pervenute costituiscono un valore nullo nel vettore. • Se tutte le decisioni hanno valore 1, allora il coordinatore passa in stato
ready; • Se almeno una delle decisioni è nulla o 0, allora il coordinatore decide 0.
Seconda fase: • Se il coordinatore si trova in stato ready, quest’ultimo invita anche il resto del
gruppo a passare in stato ready. Al termine della comunicazione, il coordinatore decide 1.
• Se il coordinatore ha deciso 0, allora invia la sua decisione a tutti gli altri processi, i quali la assumono come decisione finale
Terza fase: • Se il coordinatore ha deciso 1, allora invia la sua decisione a tutti gli altri
processi, i quali la assumono come decisione finale
L’algoritmo del Commit a tre fasi 7.3. THE C O M M I T P R O B L E M 187
. . . . . . . . . . . . . . . . . . . . . . .
2 ~ . .....
3
4
1 2 3
F i g u r e 7.5- Communication pattern in ThreePhaseCommit.
2. I f any process's state is in decO, then no process is in dec1, and no non- failed process is in ready.
3. I f any process's state is in dec1, then no process is in decO, and no non- failed process is in uncertain.
P r o o f . Straightforward. The most interesting part of the proof is the proof of the third condition. For this, we note that process 1 can only decide 1 at the end of round 2, after it has already broadcast ready messages. This means that process 1 knows at the end of round 2 that each other process has either received and processed the ready, thereby entering the ready state, or else has failed. (The synchrony of the model is important here.) [S]
Now we can prove that most of the conditions of interest hold after the first three rounds.
L e m m a 7.23 After three rounds of ThreePhaseCommit, the following are true:
1. The agreement condition holds.
2. The validity condition holds.
3. I f process 1 has not failed, then all non-failed processes have decided.
Esempio: Fase 1
2 3
1
4 5
Esempio: Fase 1
2 3
1
4 5
✔
✔ ✔ ✔ ✔
Esempio: Fase 1
5 2 3
1
4
Esempio: Fase 1
1 1 1 1 1
v[i] != null && v[i] == 1 ?
2 3
1
5 4
Esempio: Fase 1
1
v[i] != null && v[i] == 1 ?
2 3 5 4
1 1 1 1 1
Esempio: Fase 2
2 3 5 4
1
Esempio: Fase 2
2 3 5 4
1
Esempio: Fase 2
2 3 5 4
1
Esempio: Fase 3
1
2 3 5 4
Esempio: Fase 3
2 3 5 4
1
Terminazione
I tre round dell’algoritmo a tre fasi non sono sufficienti a garantire la Strong termination.
Se il processo coordinatore non fallisce, allora tutti i processi non falliti giungeranno ad una decisione. Ma se il processo coordinatore fallisce, gli altri processi potrebbero essere lasciati in uno stato indefinito.
Per risolvere questo problema, I processi rimanenti devono eseguire un protocollo di terminazione al termine dei tre round
1
Protocollo di terminazione dell’algoritmo a tre fasi
Quarto round: Si nomina un nuovo coordinatore, il quale raccoglie le decisioni prese dal gruppo (0 o 1) e le inserisce in un vettore. Le decisioni non pervenute costituiscono un valore nullo nel vettore. • Se almeno una delle decisioni ha valore 1, allora il coordinatore decide 1; • Se almeno una delle decisioni ha valore 0, allora il coordinatore decide 0; • Se tutte le decisioni pervenute sono uncertain, allora il coordinatore decide 0; • Se almeno una delle decisioni è ready ed il restante è uncertain, allora il
coordinatore passa in stato ready
Quinto round: • Se il coordinatore si trova in fase ready, quest’ultimo invita anche il resto del
gruppo a passare in stato ready. Al termine della comunicazione, il coordinatore decide 1.
• Se il coordinatore ha già deciso 0 o 1, allora invia la sua decisione a tutti gli altri processi, i quali la assumono come decisione finale
Sesto round: • Se il coordinatore ha deciso 1, allora invia la sua decisione a tutti gli altri processi, i
quali la assumono come decisione finale
Esempio: Round 4
3 4 5 2
1
Esempio: Round 4
3 4 5
2 1
Esempio: Round 4
3 4 5
2 1
Esempio: Round 4
3 4 5
2 1 ? r ? ?
Esempio: Round 4
3 4 5
2 1 ? r ? ?
Esempio: Round 5
3 4 5
2 1
Esempio: Round 5
3 4 5
2 1
Esempio: Round 5
3 4 5
2 1
Esempio: Round 6
3 4 5
2 1
Esempio: Round 6
3 4 5
2 1
L’algoritmo a tre fasi completo
Nel caso in cui anche il secondo coordinatore fallisca, i tre round del protocollo di terminazione sono ripetuti nominando coordinatore il terzo processo e così via.
L’algoritmo a tre fasi, comprensivo del protocollo di terminazione, viene definito completo e garantisce la Strong termination.
La condizione di terminazione forte è garantita dal fatto che, nonostante eventuali fallimenti dei coordinatori, gli altri processi hanno la possibilità di essere nominati coordinatori nei round successivi e di terminare correttamente.
1
Complessità degli algoritmi del Commit
• Algoritmo a due fasi (2PC): L’algoritmo richiede sempre e solo 2 round. In assenza di fallimenti, se n è il numero di processi, il massimo numero di messaggi scambiati è 2n-2
• Algoritmo a tre fasi (3PC): Nel caso peggiore ovvero in cui ogni coordinatore fallisca, se n è il numero di processi, sarebbero necessari 3n round per completare l’algoritmo. Se si escludono dal protocollo di terminazione quei processi che sono già giunti ad una decisione, l’algoritmo termina in pochi round e con O(n) messaggi scambiati.