Mutua esclusione e Coordinazione - the

COORDINAZIONE in ambito distribuito
MUTUA ESCLUSIONE & ALGORITMI
Discutere il problema della mutua esclusione in ambito distribuito ed in particolare:
• Elencare le proprietà richieste
• Indicare quali sono gli algoritmi adottati e le loro caratteristiche
• Discutere il confronto dei diversi algoritmi considerando fattori quali complessità, tolleranza
ai guasti, ritardo.
Introduzione alla mutua esclusione
Una premessa essenziale da fare è: in un sistema distribuito non esiste il concetto di tempo globale
ma bisogna stabile delle relazioni di ordinamento temporale fra eventi (scambio di messaggi).
I processi distribuiti devono spesso coordinare le loro attività. Se una collezione di processi
condivide una risorsa o un insieme di risorse è necessaria la mutua esclusione per prevenire
“interferenze” e assicurare la consistenza delle stesse.
Al fine di garantire la mutua esclusione devono essere affrontate 3 particolari condizioni. La prima
definita SAFETY determina il fatto che al più un processo per volta esegua la sezione critica
(condizione primaria, senza la quale non ci sarebbe mutua esclusione).Questo garantisce che non ci
possa essere stallo (no starvation). La seconda condizione è detta LIVENESS e determina il fatto
che chi (processo) chieda di entrare nella sezione critica alla fine ottiene il permesso e al termine la
rilascia. Terza ed ultima condizione è l’ORDERING cioè l’ingresso nella sezione critica deve
rispettare la relazione d’ordine causale (se A chiede una risorsa e B chiede la stessa risorsa ci si
aspetta che A entri prima nella sezione critica, tenendo presente che il tempo di richiesta può subire
un ritardo ad esempio perché un processo è più distante).
Da tener presente che non sempre gli algoritmi utilizzati per la sincronizzazione rispettano tutte e 3
le condizioni.
Algoritmi per ottenere mutua esclusione - confronti
1. Algoritmo centrale (centralizzato) Æ il più semplice
Il più semplice modo per ottenere la mutua esclusione è quello di utilizzare un processo
coordinatore che garantisca i permessi per entrare nella sezione critica (algoritmo centrale). Quindi
un processo che vuole entrare nella sezione critica invia un messaggio al processo server e aspetta la
risposta. La risposta è un “token” che garantisce il permesso ad entrare nella s.c. Quando esce
restituisce il token al processo server. Qualora al momento della richiesta il token sia in possesso di
un altro processo il server accoda la richiesta. Quando la coda non è vuota viene recuperata la
richiesta più vecchia. Vengono rispettate le prime 2 condizioni (non stallo in quanto il server
assegna n modo univoco il token – tutto dipende dal processo coordinatore) mentre non rispetta la
terza condizione. Un algoritmo piuttosto semplice ma rende il processo server un collo di bottiglia
(cosa succede se si guasta?). Per quanto riguarda le performances sono necessari 2 msg per entrare
nella s.c. (2 di ritardo) ed 1 solo msg per uscirne.
Da notare che il coordinatore dovrebbe essere in grado di capire se un processo è “caduto” oppure si
tratta di un’elaborazione più lunga.
Vantaggi: semplicità
Svantaggio: coordinatore collo di bottiglia
2. Algoritmo distribuito Ricart e Agrawala (basato sul multicast con timestamp)
Assunzioni: ord.globale eventi – trasm.affidabile)
Un secondo algoritmo per ottenere la mutua esclusione si basa sul multicast. Questo vuol dire che
un processo che voglia entrare nella sezione critica manda un messaggio a tutti in multicast con il
nome della s.c., proprio id e timestamp locale (per decidere chi entrerà per primo). Si pone quindi in
attesa di tutte le conferme da parte degli altri processi. Una volta ottenuti entra nella sezione critica,
una volta uscito invia un messaggio a tutti gli altri processi. Questo algoritmo può esser visto come
la condivisione di un token logico ed un processo può trovardi in uno dei 3 seguenti stati:
RELEASED (non ha il token)-WANTED (vuole entrare)-HELD(possiede il token).
Quando un processo riceve un messaggio di richiesta può non essere nella sezione critica (released)
e non volerci entrare quindi risponde immediatamente, essere nella sezione critica (held) quindi
accoda la richiesta oppure voler entrare nella sezione critica (wanted) quindi confronta il timestamp
(il più anziano ha la maggiore priorità …cioè un processo non risponde in questo caso se la richiesta
ha un valore di timestamp più alto).
Solo un processo per volta entra nella sezione critica (HELD status), se non ci sono guasti non si
verifica nemmeno stallo. In caso contrario nessun processo può più entrare nella s.c. in quanto
quello che fa la richiesta di entrare non riceverà tutte le risposte (soluzione parziale: richieste non
bloccanti che permettano ai processi di eseguire controlli e tollerare guasti comunque). La
condizione 3 viene garantita poiché si utilizza un timestamp.
Performances: N-1 messaggi per il multicast, N-1 messaggi per le risposte quindi 2(N-1) messaggi e
il ritardo è dato dal tempo di trasmissione come nell’algoritmo precedente.
3. Algoritmo ad anello
Questo algoritmo richiede solo che ogni processo abbia un canale di comunicazione diretto con il
processo successivo nell’anello.L’algoritmo si basa sul possesso di un token. Il processo che
possiede il token è abilitato ad entrare nella sezione critica. Se un processo non richiede di entrare
nella sezione critica immediatamente lo passa al successivo. Un processo che richiede di entrarvi lo
aspetta, mentre una volta lo passa al successivo processo nell’anello.
Le prime due condizioni sono rispettate (token), mentre la terza condizione non necessariamente è
garantita (ci sono processi prima nella catena).
Performances: il token gira sempre nell’anello anche se nessun processo richiede di entrare nella
sezione critica. Necessari [1,N-1] messaggi per entrare nella sezione critica e per sincronizzazione:
1 nel caso il token sia al processo precedente, N-1 sia successivo.
1 messaggio per uscire.
Svantaggi: consumo della banda continuo a meno che uno non abbia il token. In caso di guasti
(esempio il processo in possesso del token, è necessario sincronizzare l’anello logico).
Ritardo: [0,N-1]
4. Algoritmo di votazione – Maekawa
Per entrare in una sezione critica occorre sincronizzarsi solo con il sottoinsieme (subset) dei
processi interessati. I processi votano per stabilire chi è autorizzato ad entrare nella s.c. (algoritmi di
elezione all’interno del sottoinsieme).
Per entrare nella sezione critica un processo invia una richiesta a tutti gli altri membri di Vi (insieme
di votazione). Attende le risposte reply, ricevute tutte le risposte entra nella s.c., al rilascio invia un
release a tutti gli altri membri di Vi.
Un processo pj che riceve la richiesta se è nello stato HELD oppure ha già risposto (VOTED)
all’ultimo messaggio release ricevuto accoda la richiesta, altrimenti risponde subito con un reply.
Un processo che riceve un release estrae una richiesta dalla coda e invia un reply (un voto).
Se K è la cardinalità costante di Vi per equità le assunzioni sono che K è uguale alla radice quadrata
di N e M=K.
L’algoritmo è soggetto a stallo (ad esempio insiemi di processi sistemati secondo la proprietà
transitiva).
Performances: 2 per la radice di N per entrare nella sezione critica, radice di N per uscire.
Da notare che il guasto di un processo non partecipante non influenza l’algoritmo.
ALGORITMI di ELEZIONE
Descrivere gli algoritmi di elezione in un sistema distribuito
• Introduzione all’argomento
• Vantaggi, svantaggi, complessità
• Esempio di applicazione
Scopo di algoritmo di elezione è scegliere un processo che agisca come coordinatore (varaiante
dell’algoritmo del servente centrale). Un processo non può chiamare più di un’elezione per volta,
ma complessivamente N processi possono chiamare N concorrenti elezioni. Il più importatane
requisito è quello che il processo scelto sia unico. Il processo scelto sarà il processo con
l’identificatore più alto. Ogni procello ha una variabile electedi che conterrà l’identificatore del
processo eletto.
Condizioni :
SAFETY: un processo partecipante ha electedi = indefinito oppure electedi = P .
LIVENESS: tutti i processi pi partecipano ed eventualmente settano electedi diverso da indefinito oppure
crashano.
1. Algoritmo di elezione ad anello (Chang e Roberts)
Assunzione: comunicazione affidabile e processi soggetti a guasti
I processi non conoscono a priori gli id degli altri processi ma ciascun processo conosce solo come
comunicare con il suo vicino in senso orario.
Inizialmente ogni processo è marcato come non partecipante in un’elezione. Quando un processo
riceve un messaggio election confronta l’id nel messaggio con il proprio. Se l’id è il più grande,
allora fa il forward del messaggio al suo vicino. Altrimenti se l’id è più piccolo e il ricevente non è
un partecipante sostituisce il proprio id nel messaggio e fa il forward del messaggio e si marca come
partecipante. Mentre non fa il forward del messaggio se già partecipante. Tuttavia se l’id ricevuto è
quello del ricevente allora deve essere l’id più grande e diventa coordinatore.
Il coordinatore marca se stesso come non-partecipante e invia un msg elected al suo vicino.
Le condizioni SAFETY e LIVENESS sono rispettate. La prima in quanto un processo deve ricevere
il suo stesso id prima di inviare un messaggio elected, la seconda deriva dalla struttura intrinseca
dell’anello logico qualora non ci siano guasti.
Performances: N-1 messaggi nel caso peggiore (vicino in senso antiorario). Vicino che annuncerà
la sua elezione dopo un altro giro dell’anello (altri N messaggi). Il messaggio è spedito allora N
volte, quindi 3N-1 messaggi in tutto.
Svantaggio: non tollera guasti
2. Algoritmo Bully
Può essere usato quando i membri del gruppo conoscono le identità e gli indirizzi degli altri membri
(n2 messaggi). Si distinguono 3 tipi di messaggi:
a. Election: per annunciare un’elezione
b. Answer: in risposta ad un election
c. Coordinator: per annunciare l’identità del nuovo coordinatore
SISTEMA sincrono: usa i timeout per rilevare il guasto di un processo.
T= 2Ttransf + Tprocess
Ogni processo conosce i processi con gli id maggiori e può comunicare con questi.
Un processo indice l’elezione inviando il messaggio di elezione ai processi con id più alto e aspetta
le risposte. Se non arriva entro un timeout si nomina coordinatore (AUTOELEGGE) e lo comunica
agli altri inviando un messaggio coordinator a tutti i processi con id più basso. Altrimenti aspetta un
altro tempo per l’arrivo di un messaggio coordiantore e se non arriva indice un’altra elezione.
Riassumendo: elezione in quali casi?
• Processo riattivato con id più alto
• Quando un processo nota che un coordinatore non risponde
• Quando riceve un messaggio di elezione da un processo con id inferiore
SAFETY non garantita se i processi rimpiazzati da processi con id identici.
Difetto: problemi nell’accuratezza dei timeout
Performances: Se il secondo processo con id + alto notifica il guasto del coordiantore N-2
messaggi. Caso peggiore n2
Nota: Risultato: più di un processo può avviare l'algoritmo, ma un solo processo completa il
suo algoritmo di elezione: quello che ha il più alto numero di priorità fra quelli funzionanti.