problema del consenso affrontato nel seminario per il corso Modelli concorrenti e sistemi distribuiti

1. Altri problemi del Consenso
• Introduzione al problema del consenso
Gianvito Siciliano
Lorenzo Valente
• Problema del K-Agreement
• Problema del Commit

2. 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

3. 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.

4. 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

5. 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.

6. 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)

7. 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

8. 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.

9. 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

10. 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.

11. 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)

12. 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)

13. 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!

14. 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

15. 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)

16. Ambiente
• Distribuito
• Sincrono
• Link della rete sicuri (nessuna possibilità di perdita
di messaggi)
• Nodi della rete insicuri (possibilità di fallimenti nei
processi)

17. 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

18. 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

19. 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

20. 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

21. L’algoritmo del Commit a due fasi
7.3. THE COMMIT PROBLEM 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

22. Esempio: Fase 1
2 3
1
4 5

23. Esempio: Fase 1
2 3
1
4 5
✔
✔
✔
✗

24. Esempio: Fase 1
1
2 3 4
5

25. Esempio: Fase 1
1
1
1
0
v[i]
!=
null
&&
v[i]
==
1
?
4 5
2 3
1

26. Esempio: Fase 1
1 1
1
1
0
v[i]
!=
null
&&
v[i]
==
1
?
4 5
2 3

27. Esempio: Fase 2
1
2 3 4 5

28. Esempio: Fase 2
2 3
1
4 5

29. 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

30. L’algoritmo del Commit a tre fasi
• 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

31. 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

32. L’algoritmo del Commit a tre fasi
7.3. THE COMMIT PROBLEM 187
. . . . . . . . . . . . . . . . . . . . . . .
2 ~ . .....
3
4
1 2 3
F i g u r e 7.5- Communication pattern in ThreePhaseCommit.
2. If any process's state is in decO, then no process is in dec1, and no non-failed

33. Esempio: Fase 1
2 3
1
4 5

34. Esempio: Fase 1
2 3
1
4 5
✔
✔
✔
✔
✔

35. Esempio: Fase 1
1
2 3 4
5

36. Esempio: Fase 1
1
1
1
1
1
v[i]
!=
null
&&
v[i]
==
1
?
2 3
1
4 5

37. Esempio: Fase 1
1
1
1
1
1
1
v[i]
!=
null
&&
v[i]
==
1
?
2 3 4 5

38. Esempio: Fase 2
1
2 3 4 5

39. Esempio: Fase 2
1
2 3 4 5

40. Esempio: Fase 2
1
2 3 4 5

41. Esempio: Fase 3
1
2 3 4 5

42. Esempio: Fase 3
1
2 3 4 5

43. 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

44. 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

45. Esempio: Round 4
1
2 3 4 5

46. Esempio: Round 4
1 2
3 4 5

47. Esempio: Round 4
1 2
3 4 5

48. Esempio: Round 4
1 2 ?
r
?
?
3 4 5

49. Esempio: Round 4
1 2 ?
r
?
?
3 4 5

50. Esempio: Round 5
1 2
3 4 5

51. Esempio: Round 5
1 2
3 4 5

52. Esempio: Round 5
1 2
3 4 5

53. Esempio: Round 6
1 2
3 4 5

54. Esempio: Round 6
1 2
3 4 5

55. 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

56. 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.