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.