Sincronizzazione e coordinamento in sistemi distribuiti

Mutua esclusione
Sincronizzazione e coordinamento nel distribuito
Sincronizzazione interna: concordata fra un insieme di processi
esterna: forzata da un agente esterno
Sincronizzazione in sistemi centralizzati
uso di primitive basate implicitamente sull’esistenza della memoria condivisa
Mutua esclusione in ambito distribuito
Attività di coordinamento fra processi per realizzare la condivisione di risorse e
garantirne la consistenza in un sistema distribuito
Sincronizzazione in sistemi distribuiti
stabilire le relazioni di ordinamento temporale fra gli eventi
Es: accesso ad un file in scrittura
Sincronizzazione in sistemi distribuiti:
- sincronizzazione di orologi
- mutua esclusione
- algoritmi di elezione
- transazioni atomiche
- gestione dello stallo
Meccasismo indipendente dallo specifico metodo di gestione della risorsa
Accesso esclusivo (temporaneo)
Se un insieme di processi concorda chi ha il diritto -> algoritmi di elezione
Mutua esclusione distribuita di un insieme di risorse
Definizione di algoritmi distribuiti
- informazione distribuita sui nodi
- decisione dei processi basata su informazione disponibile localmente
- tolleranza ai guasti di singoli nodi
- mancanza di un orologio globale o tempo assoluto
1
1. Al più un processo per volta esegue la sezione critica
(safety)
2. Un processo che chiede di entrare in una sezione critica alla fine la ottiene e al
termine lo lascia (assenza di stallo e attesa infinita)
(liveness)
3. L’ingresso nella sezione critica deve rispettare la relazione d’ordine causale
(ordering)
SOD.2
Algoritmo del servente centrale
Mutua esclusione con gestione di token - algoritmo centralizzato
Più semplice: si simulano le primitive offerte dal sistema centralizzato tramite un
processo coordinatore
•
•
•
•
un processo chiede al coordinatore di entrare e se necessario si blocca
la risposta è un token di accesso
alla ricezione della risposta entra nella sezione critica
quando esce dalla critica lo comunica al coordinatore (restituisce il token)
4
2
Un insieme di richieste sono servite in ordine di arrivo
Non soddisfa il criterio 3
1. Richiesta
token
Processo coordinatore è un processo servente
elemento centrale
possibile collo di bottiglia
in caso di guasto il processe cliente bloccato può non rilevare l’evento
Vantaggi:
semplicità - assenza di stallo - assenza di attesa infinita
Server
Coda di
richieste
p
3. Conferma
token
2. Rillascio
token
p
4
1
p
SOD.3
p
2
3
SOD.4
Algoritmo distribuito
Algoritmo di Ricart e Agrawala’s
Assunzioni - esiste un ordinamento globale degli eventi - trasmissione affidabile
• un processo che vuole entrare nella sezione critica manda un messaggio a tutti in
multicast con
- nome della sezione critica
- proprio identificatore
- timestamp locale
• si pone in attesa della risposta da tutti
• ottenuti tutti gli OK entra nella sezione critica
• all’uscita dalla s.c. manda OK a tutti i processi in coda
• un processo che riceve può
- non essere nella s.c. richiesta e non vuole entrarvi-> manda OK al mittente
- essere nella s.c. -> non risponde e mette il messaggio in coda locale
- voler entrare nella s.c. -> confronta i timestamp e la più anziana ha
maggior priorità, se è l’altro invia OK, se è lui pone il messaggio in coda
Come una gestione di token logico condiviso
Ogni processo è in uno stato :
RELEASED - WANTED - HELD
SOD.5
Inizializzazione:
state := RELEASED;
Protocollo di ingresso nella sezione critica
state := WANTED;
Multicast request a tutti i processi;
elaborazione della request rinviata qui
T := timestamp della richiesta;
Wait until (numero di risposte ricevute = (N – 1));
state := HELD;
Alla ricezione del messaggio di richiesta <Ti, pi> a pj (i ≠ j)
if (state = HELD or (state = WANTED and (T, pj) < (Ti, pi)))
then
accoda request da pi senza rispondere;
else
rispondi subito a pi;
end if
Protocollo di uscita dalla sezione critica
state := RELEASED;
rispondi a tutte le richieste;
SOD.6
Esempio di sincronizzazione con multicast
41
Algoritmo distribuito - efficienza e correttezza
Assenza di stallo
Assenza di attesa infinita (ordinamento globale)
Garantisce le condizioni 1-2-3
41
p
Algoritmo totalmente distribuito - nessun elemento centrale
3
p
Reply
1
34
Reply
41
Limiti:
• dati N processi occorrono 2(N-1) messaggi (per richiesta multicast e risposte)
se è supportato il multicast eventualmente N
prestazioni e costo
• se un processo fallisce nessun altro potrà entrare nella s.c.
tolleranza ai guasti
soluzione: usare richieste non bloccanti
• tutti i processi possono essere collo di bottiglia
ogni processo partecipa ad ogni decisione
prestazioni
Reply
34
p
34
2
p1 e p2 chiedono di entrare nella s.c.
p3 non è interessato
Varianti e ottimizzazioni
SOD.7
SOD.8
Algoritmo ad anello
Mutua esclusione con gestione ad anello
Anello logico: ordinamento circolare dei processi
p
• all’inizio il processo 1 ha un token che poi passa al successivo
• Il processo che ha il token è abilitato all’accesso alla sezione crititca
Verifica delle condizioni 1 e 2
La condizione 3 non è necessariamente garantita
- Costo
numero di messaggi per ottenere il token:
[1,N-1]
“
per uscire dalla sezione critica: 1
“
per sincronizzazione sulla sezione critica: [1,N-1]
- Affidabilità
se un processo fallisce occorre riconfigurare l’anello logico
se fallisce il processo che possiede il token occorre eleggere il
prossimo processo che avrà il token
perdita di token anche per malfunzionamenti hw/sw
rischio e attenzione ai guasti temporanei che possono portare alla
creazione di token multipli
- Prestazioni
l’algoritmo usa sempre banda per trasmettere il token anche
quando nessuno chiede la s.c.
SOD.9
1
p
2
pn
p
3
p
4
Token
SOD.10
Algoritmo di votazione
Algoritmo di votazione - condizioni
Per entrare in una sezione critica occorre sincronizzarsi solo con il sottoinsieme
dei processi interessati
Algoritmi di elezione all’interno del sottoinsieme
I processi votano per stabilire chi è autorizzato ad entrare nella s.c.
• insieme di votazione Vi sottoinsieme di {p1,…, pN}, associato ad ogni processo pi
•
•
•
•
un processo per entrare in una s.c. invia una richiesta a tutti gli altri membri di Vi
attende le risposte reply
ricevute tutte le risposte di usa la s.c.
al rilascio della s.c. invia un relese a tutti gli altri membri di Vi
• un processo pj in Vi che riceve la richiesta
- se è nello statoHELD o ha già risposto dopo aver ricevuto l’ultimo
messaggio release non risponde e accoda la richiesta
- altrimenti risponde subito con un reply
• un processo che riceve un release estrae una richiesta dalla coda e invia un reply
SOD.11
Definizione dei Vi
- processo pi appartiene a Vi
- Vi e Vj hanno intersezione non vuota, almeno un membro comune
- cardinalità costante (K) di Vi per equità
- ogni processo pj appartiene ad M insiemi Vi
Assunzioni: K= √N e M=K
Definizione degli insiemi: non banale
Garantita la condizione 1
I processi pi e pj che competono per la stessa s.c. hanno intersezione non vuota di Vi e Vj
Possibilità di stallo - condizione di attesa circolare
Varianti per la rimozione dello stallo: elaborazione delle richieste in ordine causale
-> verifica anche della condizione 3
- Costo ingresso nella s.c. 2 √N messaggi , uscita dalla s.c. √N messaggi
rispetto all’algoritmo distribuito
3 √N < 2(N-1)
se N>4
- Affidabilità guasto di un processo non partecipante non influenza l’algoritmo
SOD.12
Algoritmo di Maekawa – parte 1
Algoritmo di Maekawa – parte 2
Inizializzazione
state := RELEASED;
voted := FALSE;
Protocollo di ingresso nella sezione critica per pi
state := WANTED;
Multicast request a tutti i processi in Vi – {pi};
Wait until (numero di risposte ricevute = (K – 1));
state := HELD;
Alla ricezione di una richiesta da pi a pj (i ≠ j)
if (state = HELD or voted = TRUE)
then
accoda request da pi senza rispondere;
else
invia reply a pi;
voted := TRUE;
end if
Protocollo di uscita dalla sezione per pi
state := RELEASED;
Multicast release a tutti i processi in Vi – {pi};
Alla ricezione di un messaggio release da pi a pj (i ≠ j)
if (coda di richieste non vuota)
then
estrai la prima richiesta in coda – da pk;
invia reply a pk;
voted := TRUE;
else
voted := FALSE;
end if
Continua
SOD.13
SOD.14
Confronti
Algoritmi di Elezione
Scegliere un processo che agisca come coordinatore
Algoritmi per la realizzazione della mutua esclusione in ambito distribuito
Algoritmo
messaggi per entrata
e uscita dalla s.c.
ritardo
problemi
Centralizzato
3
2
guasto del
coordinatore
Distribuito
2(N-1)
2(N-1)
crash di processo
Anello
[1,N]
[0,N-1]
perdita del token
crash di processo
Votazione
2 √N
√N
2 √N
√N
crash di processo del
gruppo votante
(entrata)
(uscita)
Varianti per maggiore tolleranza ai guasti
Centralizzato è il più semplice
SOD.15
Ipotesi
- tutti i processi sono numerati in modo univoco
- solitamente il coordinatore è il processo ‘vivo’ con numero più alto
- ogni processo conosce il numero di tutti gli altri
Obbiettivo: alla fine dell’algoritmo tutti i processi concordano su un processo eletto
Un processo chiama una elezione
Ogni processo può essere partecipante o no alla elezione
Il processo eletto è unico anche se più processi hanno chiamato l’elezione
Ogni processo ha un identificatore di processo eletto pi ha elettoi event. indefinito
Requisiti durante una esecuzione di un algoritmo di elezione
P è il processo eletto al termine del run dell’algoritmo, processo attivo con
identificatore max
1. ogni processo pi ha elettoi = P o indefinito
(safety)
2. Tutti i processi partecipano e al termine ogni pi che sia attivo ha elettoi non
indefinito
(liveness)
SOD.16
Algoritmi di Elezione - Ordinamento circolare
Algoritmo di elelzione basato su anello
Ipotesi: comunicazione affidabile - i processi sono soggetti a guasti
3
17
Ordinamento circolare [Chang e Roberts]
Anello logico : lista ordinata di processi vivi
Il messaggio di elezione viene inviato solo al processo successivo
Ogni processo aggiunge sé stesso alla lista dei processi vivi
Al termine il processo che riceve un messaggio di elezione dove il primo # è il suo si
riconosce come processo coordinatore e lo comunica in modo circolare
• Ogni processo inizialmente non partecipa all’elezione, diventa partecipe
aggiungendo il suo nome alla lista
• se l’id del messaggio di elezione è maggiore, lo passa e diventa partecipante
• se l’id del messaggio di elezione è minore, mette il proprio id e lo passa (se non è
già partecipante)
• se l’id del messaggio di elezione è uguale, allora è coordinatore e diventa non
partecipante, manda il messaggio eletto
• ogni altro processo che riceve messaggio eletto si marca non partecipante
SOD.17
4
24
9
1
15
28
24
Nota: Elezione iniziata dal processo 17.
L’id. di processo più alto finora incontrato è 24.
I processi che partecipano sono quelli scuri.
SOD.18
Ordinamento circolare - condizioni
Algoritmo bully
Seleziona il processo con il numero più alto
Verifica la condizione 2
Caso pessimo: una chiamata di elezione, (3N-1) messaggi necessari per completare
l‘elezione
Tempo di risposta: proporzionale a (3N-1)
Tolleranza ai guasti: scarsa
Migliorabile con identificazione di guasti e ricostruzione dell’anello
•
•
•
Algoritmo bully [Garcia Molina]
Ipotesi: processi non affidabili, soggetti a guasti, comunicazione affidabile
sistema sincrono: uso di timeout per riconoscere i guasti
ogni processo consce i processi con gli identificatori maggiori
e può comunicare con questi
Tre tipi di messaggi
elezione
risposta
coordinatore
SOD.19
un processo indice l’elezione inviando il messaggio di elezione ai processi con id
più alto, e aspetta le risposte
se la risposta non arriva entro un timeout si nomina coordinatore (si autoelegge!)
e lo comunica agli altri inviando un messaggio coordinatore a tutti i processi con
id più basso
altrimenti aspetta una altro tempo per l’arrivo di un messaggio coordinatore, e se
non arriva, indice un’altra elezione
•
un processo che riceve un messaggio coordinatore registra il # e lo considera
coordinatore
•
un processo che riceve un messaggio elezione, invia una risposta al mittente ed
indice a sua volta una elezione se già non lo ha fatto, anche se esiste un altro
coordinatore
SOD.20
Algoritmo bully - esempio
Algoritmo bully - condizioni
election
Elezione del
coordinatore p2,
dopo il guasto di p4
e poi di p3
Quando viene indetta una elezione?
- quando un processo viene riattivato dopo un guasto e se ha l’id più alto diventa
coordinatore e lo annuncia (anche se esiste già un altro coordinatore)
- quando un processo nota che il coordinatore non risponde
- quando riceve un messaggio di elezione da un processo con numero inferiore
C
election
Stage 1
p
answer
1
p
p
2
p
3
4
answer
election
election
election
C
Stage 2
p1
p
answer
2
p
3
Costo
p
4
caso pessimo O(n2) messaggi
caso ottimo O(n-2) messaggi
timeout
Garantisce la condizione 2 (liveness) ma non la 1 (safety) nel caso di guasti in cui un
processo viene rimpiazzato da un altro con lo stesso id
Stage 3
p
p
1
2
p
3
p
4
Problema della accuratezza del timeout
Eventually.....
coordinator
C
Stage 4
p
1
p
2
p
3
p
4
SOD.21
SOD.22
Gestione dello stallo
Stallo - condizioni
Effetto collaterale della mutua esclusione (accesso esclusivo ad una risorsa da
parte di un processo)
se sono vere anche le condizioni di
- allocazione di risorse senza prelazione - il sistema non può forzare il rilascio della
risorsa da un processo
- hold and wait - un processo che ha assegnata una risorsa non la rilascia (la
blocca) e si può porre in attesa di un’altra risorsa
- attesa circolare - esiste un cammino chiuso nel grafo di allocazione
P1
P2
Esempio senza mutua esclusione
P1
R1
P1
P2
Esempio con prelazione
P1
R2
R1
P2
P2
R2
assegnamenti di risorse
assegnamenti di risorse
Esempio senza
attesa circolare
R1
R2
richieste di risorse
R1
SOD.23
R2
richieste di risorse
SOD.24
Tecniche di gestione dello stallo
Tecniche: prevenzione lo stallo
Se la risorsa è un buffer si parla di stallo della comunicazione
Se coinvolge due nodi stallo diretto store and forward
Se coinvolge più nodi stallo indiretto store and forward
Si agisce su una condizione - m.e. e prelazione spesso non si possono eliminare
Alternative:
Tecniche (PAID)
- prevenire
- evitare
- ignorare
- rilevare
• preallocazione di risorse
ogni processo ottiene le risorse prima dell’esecuzione
inefficienza (basso utilizzo delle risorse se i tempi di esec. sono lunghi)
• permettere una sola allocazione di risorsa -> evita il ciclo
ma a volte dei processi devono usare accessi simultanei
Avoidance (Evitare)
come in sistemi centralizzati: determinare lo stato stabile in base alle esigenze dei
processi
Svantaggi:
- i processi spesso non possono specificare le ‘esigenze’ in termini di allocazione di
risorse
- algoritmo inefficiente già in sistemi centralizzati , NP
SOD.25
• rilascio forzato delle risorse -> evita il ciclo
ogni processo è forzato a liberare le risorse prima di un’altra richiesta
così altri processi possono continuare
• ordinamento di acquisizione delle risorse -> evita il ciclo
risorse numerate e accesso/acquisizione solo in ordine crescente
si alloca solo se tutte le risorse già allocate hanno un numero inferiore
• regole di anzianità
timestamp unico per ogni processo
un processo deve lasciare le risorse se sono richieste da un processo più
anziano
SOD.26
Tecniche: ignorare e rilevare
Algoritmo di rilevazione dello stallo
Ignorare
Spesso usato - Es. Unix
Intervento del sistemista o notifica dell’utente
Rimozione eliminando la condizione di attesa ciclica, es. terminando un processo
Rilevare
Più applicato
Algoritmo di Chandy-Misra-Haas
Basato su messaggio test inviato se un processo
- non riesce ad ottenere una risorsa o
- se scatta un timeout
Rimozione eliminando la condizione di attesa ciclica, es. terminando un processo
Test con tre campi:
- identificatore del processo bloccato
“
“
“ che invia il messaggio
“
“
“ destinatario del messaggio
• un processo P1 bloccato inizia un test e lo invia al processo P2 che ha la risorsa
P1
P2
• il processo P2 che riceve il messaggio test
se non vuole altre risorse finisce il test
altrimenti se è bloccato su P3 invia a P3 un messaggio modificato
• se un processo riceve un messaggio con primo e terzo campo uguale
-> rileva lo stallo
P1 P1
P1
P2
P1
P2
A
A
P2
P3
P3
B
B
A
stallo
SOD.27
P1
A
B
A
SOD.28
Rimozione dello stallo
Rilevato lo stallo occorre rimuoverlo
- segnalazione al sistema
- determinazione del processo da terminare
- terminazione del processo e rilascio delle risorse
- rollback ad uno stato consistente
- uso di checkpoint per il rollback
Problemi: determinazione della frequenza del checkpoint
Per evitare la attesa infinita: aumentare la priorità del processo terminato
SOD.29