7.

Algoritmi pentru sincronizarea ceasurilor

Scop şi presupuneri
- presupunem
1: o maşină are un receptor UTC,
scop: menţinerea maşinilor din sistem sincronizate;
1’: maşinile au receptoare UTC, fiecare maşină ţine evidenţa propriului timp
scop: menţinerea ceasurilor individuale cât mai apropiate;
2: se presupune că fiecare maşină are un timer care cauzează H întreruperi pe
secundă; cand acest timer ajunge la zero, handlerul de întrerupere adaugă 1 la ceasul
software care menţine evidenţa numărului de întreruperi de la momentul unei
sincronizări anterioare. Această valoare a ceasului este notată C. Cand valoarea
timpului UTC este t, valoarea ceasului maşinii p este Cp(t). Intr-o lume perfectă, ar
avea loc egalitatea Cp(t) = t pentru toate p şi toţi t; cu alte cuvinte, dC/dt ideal ar
trebui să fie 1.
Rata de derivaţie
Timerele reale nu reuşesc să realizeze întreruperile exact de H ori pe secundă.
Teoretic, un timer cu H = 60 ar trebui să genereze 216 000 ticuri pe ora. In practica,
eroarea relativa obtinuta de cipurile timer curente poate fi în domeniul 215 998 pană
la 216 002 ticuri pe ora. Dacă există o anume constantă astfel încat 1-r<=dC/dt<1+r
se spune că timerul lucrează conform specificaţiei. Constanta r este specificată de
producător şi este cunoscută drept rata maximă de deviere.

Sincronizare
Dacă două ceasuri au deviat de la timpul UTC în direcţii opuse, la un timp dt
dupa ce au fost sincronizate, pot fi depărtate cu 2r dt. Daca designerii sistemului
distribuit doresc sa garanteze ca oricare doua ceasuri nu se indeparteaza mai mult de
d, ceasurile trebuie resincronizate (prin software) la cel putin fiecare d/2r secunde.
Algoritmii diferă în precizia cu care este realizată resincronizarea.

1. Algoritmul lui Cristian

Fie un SD în care o maşină are un receiver UTC. Numim server de timp
maşina care are acest receptor. Scopul este acela de a sincroniza maşinile cu acesta.
Periodic, nu mai târziu de fiecare d/2r secunde, fiecare maşină expediază un mesaj
1
cerându-i timpul curent. Serverul de timp răspunde cât de repede poate cu un mesaj
care conţine timpul său curent CUTC. Când expeditorul primeşte răspunsul, el îşi
setează ceasul pe CUTC.

Algoritmul are două probleme:

- problemă majoră: timpul nu trebuie să fie dat înapoi. Dacă ceasul expeditorului este
rapid, va fi setat la o valoare mai mică decat valoarea curentă a expeditorului.
Consecinţă: un cod obiect compilat după schimbarea ceasului va avea un timp
înaintea celui a sursei care a fost modificată înainte de schimbarea ceasului.
- soluţie: - schimbarea trebuie introdusă gradual
- o modalitate este următoarea: presupunem că timer-ul este setat
pentru a genera 100 întreruperi pe secundă. Normal, fiecare întrerupere
va adăuga 10 msec la timp. Când se doreşte încetinirea, rutina de
întrerupere adaugă numai 9 msec de fiecare dată, până când a fost făcută
corecţia. Similar, ceasul poate fi avansat gradual prin adăugarea a 11
msec la fiecare întrerupere în loc de un salt dintr-o dată.
- problemă minoră: este necesar un timp pentru ca răspunsul serverului să ajungă la
expeditor. Această întârziere poate fi destul de mare şi să varieze în funcţie de
încărcarea reţelei.
- soluţie, modalitatea lui Cristian de tratare: se încearcă măsurarea întârzierii
reţelei. Expeditorul înregistrează cu acurateţe intervalul între expedierea cererii de
timp către server şi sosirea răspunsului. Timpul de start, T0 şi timpul final, T1, sunt
măsurate utilizand acelaşi ceas. Intervalul va avea o acurateţe relativă, chiar dacă
ceasul expeditorului este deplasat de la timpul UTC cu o anumite cantitate. In absenţa
unei alte estimări mai bune a timpului de propagare a mesajului, acesta este (T1-
T0)/2. Cand soseşte răspunsul, valoarea din mesaj poate fi incrementată cu această
cantitate pentru a oferi o estimare a timpului curent a serverului. Dacă timpul de
propagare minim şi teoretic este cunoscut, o estimare a timpului este mai uşor de
calculat. Estimarea poate fi îmbunătăţită dacă este cunoscut timpul necesar serverului
de timp să trateze o întrerupere şi să proceseze mesajul sosit. Fie timpul de tratare a
întreruperii I. O măsură a intervalului de timp dintre T0 şi T1 care este dedicat
propagării mesajului este (T1- T0)/2 astfel ca o estimare bună a timpului de propagare
este jumatate din aceasta. Dar există sisteme în care mesajele de la A la B în mod
sistematic au o rută diferită de mesajele de la B la A, şi astfel au timpi de propagare
diferiţi. Pentru a îmbunătăţi acurateţea estimării, Cristian a sugerat să nu se facă
numai o măsurătoare, ci o serie de măsurători. Fiecare măsurătoare în care T1- T0
2
depăşeşte o anumită valoare de prag este ignorată ca fiind victima congestiilor de
reţea şi de aceea de neîncredere. Estimările derivate din probele rămase pot fi folosite
la o mediere pentru a obţine o valoare mai bună. Alternativ, mesajul care vine înapoi
mai repede poate fi considerat cel mai bun deoarece a întâlnit un trafic redus şi este
cel mai reprezentativ pentru timpul de propagare pur.
2. Algoritmul lui Berkeley
In algoritmul lui Cristian timpul serverului este pasiv. Fiecare maşină îl solicita
periodic, tot ceea ce face este să răspundă la solicitări. Algoritmul Berkeley consideră
o abordare opusă. Serverul de timp este activ (de fapt este un proces demon),
întrebând fiecare maşină periodic ce valoare a timpului cunoaşte. Bazându-se pe
răspunsuri, calculează un timp mediu şi spune celorlalte maşini să avanseze sau
încetinească ceasurile lor la timpul nou până când a fost realizată o anumită reducere
a diferenţei. Această metodă este adecvată pentru un sistem în care nici o maşină nu
are un receptor UTC. Timpul demonului trebuie setat manual de către operator
periodic.

a) La 3:00, demonul de timp spune celorlalte maşini timpul său şi le cere

celorlalte.
b) Acestea răspund cât de departe sunt faţă de timpul demonului
c) Inarmat cu aceste numere, demonul de timp calculează media şi spune
fiecărei maşini cum să ajusteze ceasul său.
3. Algoritmi de mediere.
Ambele metode descrise mai sus sunt centralizate, cu avantajele uzuale.
Algoritmii descentralizaţi sunt cunoscuţi!
O clasă de algoritmi de sincronizare descentralizată a ceasurilor lucrează prin
divizarea timpului în intervale de resincronizare de lungime fixă. Intervalul al i-lea
porneste la T0+iR si ruleaza pana la T0+ (i+1)R unde T0 este un moment agreat in
trecut, iar R este un parametru de sistem. La începutul fiecărui interval, fiecare
maşină difuzează timpul curent conform ceasului său. Deoarece ceasurile de pe
maşini diferite nu rulează la exact aceeaşi viteză, aceste difuzări nu se întâmplă exact
simultan. După ce o maşină a difuzat timpul său, porneşte un timer local pentru a
colecta toate celelalte difuzări care sosesc într-un anumit interval S.
Când toate difuzarile au sosit, este rulat un algoritm care calculează noul timp.

3
 1. Cel mai simplu algoritm face media valorilor de la toate celelalte
maşini
2. O variaţie pe această temă este aceea de a înlătura înainte m cele mai
mari şi m cele mai mici valori şi a face media restului. Eliminarea valorilor
extreme poate fi privită ca o apărare contra a m ceasuri eronate care trimit
valori fără sens.
3. O altă variaţie este aceea de a încerca corectarea fiecărui mesaj prin
adăugarea la acesta a unei estimări a timpului de propagare de la sursă. Această
estimare poate fi realizată cunoscând topologia reţelei sau timpul necesar unei
probe mesaj care este recepţionată în ecou
Surse multiple de timp extern
Pentru sistemele în care sincronizarea cu acurateţe extremă cu UTC este
necesară, este posibilă echiparea sistemului cu receptori multipli. Datorită
inacurateţei inerente în sursa de timp în sine + fluctuaţiile în drumul semnalului, ceea
ce poate un SD să realizeze este să stabilească un domeniu (interval de timp) în care
se află UTC. In general, sursele variate de timp vor produce diferite domenii, ceea ce
implica faptul că maşinile ataşate la aceastea trebuie să ajungă la un acord. Pentru a
ajunge la acest acord, fiecare procesor cu o sursa UTC poate difuza domeniul sau
periodic, de exemplu la începutul fiecărui minut UTC. Nici un procesor nu va primi
aceasta informaţie instantaneu. Mai mult, intarzierea intre expediere si receptionare
depinde de distanţa pe cablu şi numărul de gateways pe care pachetele trebuie să le
traverseze, ceea ce este diferit pentru fiecare pereche (sursa UTC, procesor). Fiecare
factor joacă de asemenea un rol, precum întârzierile datorate coliziunilor când maşini
multiple încearcă să transmită pe reţea în acelaşi timp. Dacă un procesor este ocupat
cu tratarea unui pachet anterior, e posibil să nu urmărească un pachet de timp pentru
un numar considerabil de miliseunde, introducând o incertitudine adiţională la timp.

Utilizarea ceasurilor sincronizate

- Tichete de timp în autentificare
- Tratarea commit în tranzacţiile atomice
- Consistenţa cache bazată pe ceas
- Livrarea o singură dată a mesajelor

4
 8. Excludere mutuală distribuită

Problema: când un proces trebuie să citească sau actualizeze o anume

structură de date partajată, intră în secţiunea critică, iar excluderea mutuală asigură că
nici un alt proces nu va utiliza structura de date partajată în acelaşi timp. Intr-un
sistem cu un procesor secţiunile critice sunt protejate utilizând semafoare, monitoare
şi contructori similari. Cum pot fi implementate secţiunile critice şi excluderea
mutuală în sistemele distribuite?
Algoritmul centralizat simulează ceea ce se întamplă într-un sistem
monoprocesor. Un proces este ales ca fiind coordonator (de exemplu cel care rulează
pe maşina cu adresa de reţea cea mai mare). Când un proces doreşte să intre în
secţiunea critică, expediază un mesaj către coordonator afirmând care este regiunea
critică în care doreşte să intre şi cerând permisiunea. Dacă nici un proces nu este în
acel moment în secţiunea critică, coordonatorul expediază un răspuns care acordă
permisiunea. Când soseşte răspunsul, procesul solicitant intră în secţiunea critică.
Exemplu de algoritm centralizat:

- procesul 1 solicită coordonatorului permisiunea de a intra în secţiunea

critică şi permisiunea este acordată
- procesul 2 solicită să intre în aceeaşi secţiune critică
- coordonatorul ştie că un proces diferit este deja în secţiunea critică şi nu
acordă permisiunea
- metoda exactă pentru a respinge permisiunea este dependentă de sistem
- (b) coordonatorul doar refuză să răspundă, astfel blocând procesul 2
care este în aşteptarea răspunsului
- alternativ, poate trimite un răspuns cu "permisiune respinsă"
- în ambele cazuri, pune în coadă cererea de la 2
- când procesul 1 iese din secţiunea critică, trimite un mesaj coordonatorului
eliberând accesul său exclusiv - (c)
- coordonatorul ia primul articol din coada de cereri refuzate şi expediază
procesului corespunzător un mesaj de permis
- dacă procesul este blocat (adică acesta este primul mesaj către proces), se
deblochează şi intră în secţiunea critică
- dacă un mesaj explicit de refuz a fost deja expediat, procesul va trebui să
extragă mesajul nou din trafic sau să se blocheze mai târziu în aşteptarea
acestui mesaj
- în ambele cazuri, când vede mesajul de acceptare, intră în secţiunea
critică

5
 Algoritmul centralizat garantează excluderea mutuală (coordonatorul lasă doar
un proces la un momentan dat să intre în secţiunea critică). Este corect pentru că
cererile sunt acordate în ordinea în care au fost recepţionate. Nici un proces nu va
aştepta infinit (fără înfometare). Schema este uşor de implementat şi necesită numai
trei mesaje pentru o utilizare a secţiunii critice (cerere, permisiune, eliberare). Poate
fi utilizat şi în cazul mai general al alocării de resurse
Probleme ce pot să apară pentru algoritmi centralizaţi:
- coordonatorul este un punct singular de eşec: dacă este distrus, întregul
sistem cade
- dacă procesele în mod normal se blochează după o cerere, nu pot distinge
între un coordonator căzut şi permisiune respinsă deoarece în ambele
cazuri mesajul de răspuns nu este primit
- într-un sistem mare, un singur coordonator poate deveni gâtuire a
performanţei.

Algoritmul distribuit Ricart & Agrawala

Necesită o ordine totală a tuturor evenimentelor din sistem, adică pentru
oricare perechi de evenimente, precum tratarea mesajelor, trebuie să fie cunoscută
ordinea în care se întâmplă dinainte. Algoritmul lui Lamport este o modalitate de a
atinge această ordonare şi poate fi utilizat pentru a oferi mărci de timp.
Când un proces doreşte să intre într-o secţiune critică:
- construieşte un mesaj conţinând numele secţiunii critice în care vrea să
intre, numărul său de proces şi timpul curent
- expediază apoi mesajul la toate procesele, inclusiv el însuşi. Expedierea
mesajelor este considerată de încredere, adică un mesaj este confirmat.
Dacă este disponibilă, comunicarea de încredere în grup este de preferat
mesajelor individuale.
Când un proces recepţionează un mesaj de cerere de la alt proces, acţiunea sa
depinde de starea sa relativ la secţiunea critică numită în mesaj:
1. Dacă receptorul nu este în secţiunea critică şi nu doreşte să intre în aceasta
expediază înapoi un mesaj OK către expeditorul iniţial.
2. Dacă receptorul este deja în regiunea critică el nu răspunde şi pune în coadă
Cererea.
3. Dacă receptorul doreşte să intre în secţiunea critică, dar încă nu a făcut acest
Lucru, compară marca de timp din mesajul sosit cu cea conţinută în mesajul pe care l-
a trimis tuturor proceselor. Cea mai joasă marcă învinge: dacă marca mesajului sosit
este mai mică, receptorul trimite un mesaj de OK; dacă propriul mesaj are o marcă
mai mică, receptorul trece în coada mesajul sosit şi nu răspunde.
După expedierea cererilor de permisiune de a intra în secţiunea critică,
procesul aşteaptă ca toate celelalte să-i acorde permisiunea. De îndată ce toate
permisiunile sosesc, procesul poate intra în secţiunea critică. Când iese din secţiunea
critică, procesul expediază mesaje de OK la toate procesele din coada sa şi şterge
coada.

6
 Exemplu:

Dacă nu există nici un conflict, sigur funcţionează.

Să presupunem că două procese încearcă să intre în aceeaşi secţiune critică
simutan :
- procesul 0 expediază la toate procesele o cerere cu marca de timp 8
- în aproape acelaşi timp, procesul 2 expediază o cerere cu marca de timp 12
Procesul 1 nu este interesat să intre în secţiunea critică, aşa că trimite OK la
ambii expeditori. Procesele 0 şi 2 ambele văd conflictul şi compară mărcile de timp:
- procesul 2 vede că a pierdut şi acordă permisiunea expediind OK
- procesul 0:
- pune în coadă cererea de la 2 pentru procesare ulterioară
- intră în secţiunea critică – (b)
- când termină, elimină cererea de la 2 din coada sa
- expediează OK la procesul 2, permiţând acestuia să intre în secţiunea
critică - (c).
Pro şi contra algoritm distribuit
Excluderea mutuală este garantată fără impas sau înfometare. Numărul de
mesaje necesare per intrare este acum 2(n-1) dacă numărul de procese din sistem e n.
În acest caz nu există un punct singular de eşec, a fost înlocuit cu n puncte de eşec!
Dacă unul dintre procese este căzut, nu mai răspunde cererilor. Această tăcere este
interpretată (incorect) ca respingere a permisiunii, astfel blocându-se toate încercările
ulterioare ale altor procese de a intra în secţiunea critică. Probabilitatea ca una dintre
cele n procese să eşueze este de n ori mai mare decât cea a unui singur coordonator,
deci s-a înlocuit un algoritm slab cu unul şi mai slab care necesită un trafic şi mai
mare. O altă problemă care poate să apară este următoarea: fie se utilizează o
primitivă de comunicare în grup sau fiecare proces trebuie să menţină o listă a
proceselor, incluzand procesele care intra în grup, părăsesc grupul sau care eşuează,
deci metoda este funcţională în cazul unor grupuri mici de procese care nu-şi schimbă
apartenenţa la grup. Toate procesele sunt implicate în luarea deciziilor referitoare la
intrarea în secţiunile critice. Dacă un proces este incapabil să trateze încercarea, este
improbabil ca forţarea ca toate celelalte procese să facă acelaşi lucru în exact acelaşi
timp în paralel să ajute.
Un posibil remediu este următorul: când este primită o cerere, receptorul
trimite întotdeauna un răspuns, acordând sau respingând permisiunea. Dacă o cerere
sau un răspuns este pierdut, expeditorul foloseşte expirarea timpului pentru a
concluziona că destinatarul nu mai este funcţional. După respingerea unei permisiuni,
expeditorul ar trebui să fie blocat în aşteptarea unui mesaj de Ok ulterior.
7
 Obtinerea permisiunii de la fiecare pentru a intra în secţiunea critică este o
problemă mare, deci trebuie căutată altă metodă pentru a preveni ca două procese să
intre în secţiunea critică în acelaşi timp, de exemplu să se dea permisiunea către un
proces să intre în secţiunea critică dacă a colectat majoritatea simplă de la celelalte
procese, în loc de a o obţine de la toate.
Concluzie: algoritmul propus este mai lent, mai complicat, mai costisitor şi mai
puţin robust faţă de cel centralizat.
Algoritmul semnului in inel
Presupune o reţea bazată pe bus, fără o ordonare inerentă a proceselor. Este
construit un inel logic în care fiecărui proces îi este asignată o poziţie în cerc.
Poziţiile în inel pot fi alocate de exemplu în ordinea numerică a adreselor. Nu
conteaza cum este realizata ordonarea, tot ceea ce contează este ca fiecare proces să-
şi cunoască procesele vecine.

Când cercul este iniţializat, procesului 0 îi este acordat un semn. Semnul

circulă în inel: este pasat de la procesul k la procesul k+1 (modulo dimensiunea
inelului). Când un proces primeşte semnul de la vecinul său, verifică dacă este pe
punctul de a intra într-o secţiune critică. Daca da, au loc următoarele 4 acţiuni:
procesul intră în secţiune, îşi face treaba în secţiune, părăseşte secţiunea, pasează
semnul în inel. Dacă nu, pasează semnul în inel; dacă nici un proces nu doreşte să
intre în nici o secţiune critică, semnul circulă doar cu viteză mare în inel. Nu este
permisă intrarea într-o a doua secţiune critică prin utilizarea aceluiaşi semn.
Pro şi contra:
Corectitudine: numai un proces are semnul la un moment dat, astfel că numai
un proces poate intra în secţiunea critică. Deoarece semnul circulă între procese într-
o ordine bine definită, înfometarea nu poate interveni. Odată ce un proces decide dacă
doreşte să intre într-o secţiune critică, în cel mai rău caz va aştepta ca toate celelalte
procesele să intre în secţiunea critică respectivă şi s-o părăsească.
Probleme ce pot să apară:
- dacă semnul este pierdut, trebuie regenerat;
- detectarea dacă a fost pierdut este dificilă, deoarece cantitatea de timp
dintre apariţii succesive ale semnului în reţea este nemărginită: faptul că
semnul n-a fost recepţionat pentru o oră nu înseamnă că a fost pierdut;
unul dintre procese e posibil să-l utilizeze;
- algoritmul are probleme dacă un proces cedează, dar recuperarea este mai
uşoară decât în celelalte cazuri: dacă se solicită ca un proces care

8
 recepţionează un semn să confirme recepţionarea, un proces căzut va fi
detectat de vecinul care i-a trimis semnul; în acel moment procesul căzut
poate fi eliminat din grup şi deţinătorul semnului poate trece la următorul
membru din inel, sau mai departe dacă este necesar; fiecare menţine
configuraţia curentă a inelului.
O comparaţie între cei trei algoritmi
Algoritm Mesaje Intarziere inainte de intrare Probleme
Centralizat 3 2 Cădere coordonator
Distribuit R&A 2(n-1) 2(n-1) Căderea oricărui proces
Semnal în inel 1 to infinity 0 to n -1 Semn pierdut, proces căzut
Mesaje:
- algoritmul centralizat este cel mai simplu şi cel mai eficient, necesită numai
trei mesaje pentru a intra şi părăsi o secţiune critică: o cerere şi o
permisiune pentru a intra şi o eliberare la ieşire;
- algoritmul R&A necesita n -1 mesaje de cerere, unul la fiecare alt proces şi
în plus n -1 mesaje de permisiune;
- în algoritmul semnului, numărul este variabil. Dacă fiecare proces doreşte
în mod constant să intre într-o secţiune critică, atunci fiecare trecere a
semnului va rezulta într-o intrare şi o ieşire pentru, în medie, un mesaj per
secţiune critică. La cealaltă extremă, semnul poate circula ore întregi fără ca
vreun proces să fie interesat de acesta şi atunci numărul de mesaje per
intrare în secţiunea critică este nemărginit.
Intârzierea cu care un proces intră în secţiunea critică variază de asemenea la
cei 3 algoritmi:
- când secţiunile critice sunt scurte şi rar utilizare, factorul dominant in întârziere este
mecanismul curent de intrare în secţiunea critică;
- când sunt lungi şi des utilizate, factorul dominant este aşteptarea ca toţi ceilalţi să
ajungă la rând;
- sunt necesari, presupunând că reţeaua poate trata un singur mesaj la un moment dat
- 2 timpi pentru mesaje pentru a intra în secţiunea critică în cazul centralizat;
- 2(n -1) timpi în cazul distribuit;
- pentru semnul în inel, timpul variază de la 0 (semn de abia sosit) la n-1
(semnul tocmai a plecat).
Evenimente de eşec:
- algoritmii distribuiţi sunt mai sesnsibili la eşecuri decât cel centralizat
- într-un sistem tolerant la eşecuri, nici unul dintre cei 3 algoritmi nu este
adecvat, dar dacă eşecurile sunt nefrecvente, sunt acceptabili.

9
 9. Problema impasului

Impasurile în SD sunt similare cu impasurile din sistemele monoprocesor, însă

mai complicate. Sunt greu de evitat, prevenit sau chiar detectat şi mai greu de tratat la
depanare deoarece informaţia relevantă este împrăştiată pe mai multe maşini. In
sisteme de baze de date efectele sunt extrem de serioase.
Se poate face distincţia între două tipuri de impasuri distribuite:
1. Impas la comunicare: apare, de exemplu, cand procesul A încearcă să
trimită un mesaj procesului B, care la randul său încearcă să trimită un mesaj lui C,
care încearcă să trimită un mesaj lui A. Exista o serie de scenarii care pot conduce la
acest impas, de exemplu lipsa zonelor tampon.
2. Impas la resurse: apare cand procesele se luptă pentru acces exclusiv la
dispozitivele de I/O, fişiere sau alte resurse.
In general, se poate considera orice impas ca impas la resurse, deoarece
canalele de comunicaţie şi zonele tampon pot fi văzute ca resurse ale sistemului care
pot fi cerute sau eliberate de către procese. In plus, şabloanele de comunicare
circulară de tipul descries anterior sunt rare în majoritatea sistemelor. De exemplu, în
sistemele client-server, un client poate trimite un mesaj (sau efectua un RPC) la un
server de fişiere, care poate trimite un mesaj la un server de disk. Este puţin probabil
ca serverul de disk, comportandu-se ca şi client, să trimită un mesaj la clientul
original, asteptand să se comporte ca un server. Condiţia de aşteptare circulară este
improbabil să se producă ca rezultat numai a unei comunicări.
Strategii pentru tratarea impasului
1. Algoritmului struţului (ignorarea problemei): este popular în SD-uri ca şi în
sistemele mono-procesor. Nu există un mecanism de impas în întregul sistem utilizat
pentru programare, control a proceselor, automatizarea gen office şi alte aplicaţii.
2. Detectare: permite apariţia impasurilor, le detectează, încearca recuperarea.
Este de asemenea popular, deoarece prevenirea şi evitarea sunt dificile.
3. Prevenirea: asigură static faptul că structural impactul este imposibil. Este
mult mai dificil în cazul SD decat în cazul mono-procesor.
4. Evitarea: evită impasurile prin alocarea cu grija a resurselor. Nu este utilizat
în SD, problema fiind aceea că algoritmii propuşi trebuie să cunoasca în avans cat din
fiecare resursă îi este necesară fiecarui proces –asemenea informaţie este rară şi de
obicei nedisponibilă.
Detectarea impasului distribuit
Cand un impas este detectat intr-un sisteme de operare convenţional, o
modalitate de rezolvare este aceea de a omori unul sau mai multe procese. Facând
acest lucru invariabil, utilizatorii nu vor fi satisfăcuţi.
Când este detectat un impas într-un sistem bazat pe tranzacţii atomice, este
rezolvat prin abort al uneia sau mai multor tranzacţii. In acest caz tranzacţiile sunt
construite astfel încât să suporte abort. Când o tranzacţie este abortată deoarece
contribuie la un impas, sistemul este restaurat în starea dinaintea tranzacţiei, după
care trazacţia poate porni din nou; este probabil să fie cu succes a doua oară.

10
Diferenţa este aceea că, consecinţele omorîrii unui proces sunt mult mai puţin severe
când sunt utilizate tranzacţiile faţă de cazul când nu sunt.
Detectarea centralizată a impasului
Incearcă să imite un algoritm nedistribuit. Fiecare maşină menţine un graf al
resurselor pentru procesele şi resursele sale. Un coordonator central menţine un graf
al resurselor din întregul sistem (reunirea grafurilor individuale).
Variante:
1. Când un arc este adăugat sau şters din graful resurselor, este expediat un
mesaj la coordonator despre actualizare.
2. Periodic, fiecare proces poate expedia o lista de arce adăugate şi şterse de la
ultima actualizare (necesită mai puţine mesaje decât varianta anterioare)
3. Coordonatorul poate cere informaţia de care are nevoie.
Când coordontorul detecteaza un ciclu, omoară unul dintre procese pentru a
întrerupe impasul.
Impas fals
Se consideră un sistem cu procesele A şi B rulând pe maşina 0 şi procesul C pe
masina 1. Există trei procese, R, S şi T. Iniţial procesul A deţine resursa S şi doreşte
R, pe care nu-l poate avea deoarece B îl utilizează; procesul C are resursa T şi vrea
resursa S, de asemenea (imaginea pe care coordonatorul o are este prezentată în (c)).
Această configuraţie este sigură: odată ce procesul B termină, procesul A primeşte
resura R şi termină, eliberând resursa S pentru procesul C. După un timp: procesul B
eliberează resursa R şi cere resursa T, o schimbare legală şi sigură. Maşina 0 trimite
un mesaj la coordonator anunţând eliberarea resursei R; maşina 1 expediază un mesaj
la coordonator anunţând faptul că B aşteaptă să primească resursa T. Din păcate,
mesajul de la maşina 1 ajunge primul, ceea ce duce la construirea grafului (d) la
coordonator. Coordonatorul concluzionează incorect că există un impas şi omoară un
proces. Asemenea situaţie este numită impact fals.

Cale de ieşire din impas. Algoritmul lui Lamport

Deoarece mesajul de la maşina 1 către coordonator este realizată la cererea
maşinii 0, mesajul de la maşina 1 către coordonator va avea o marcă de timp
ulterioară mesajului de la maşina 0 către coordonator. Când coordonatorul primeşte
mesajul de la maşină 1 care-l face să suspecteze un impas, expediază un mesaj către
toate maşinile din sistem spunând: “am primit un mesaj cu marca de timp T care
conduce la un impas. Dacă oricare are un mesaj pentru mine cu o marcă de timp mai
11
timpurie, trimite-mi-l imediat.“ Când fiecare maşină a replicat, pozitiv sau negativ,
coordonatorul va vedea arcul de la R la B dispărând, astfel încât sistemul este încă
sigur. Deşi această metodă elimină impasul fals, necesită menţinerea timpului global,
ceea ce este costisitor.
Detectare distribuţiei impasului. Algoritmul Chandy-Misra-Haas
Proceselor li se permite sa solicite mesaje multiple la un moment dat, astfel
rata de crestere a unei tranzactii poate fi accelerata considerabil. Un proces poate
asteapta mai mult pentru doua sau trei resurse simultan.
Exemplu: un graf al resurselor modificat; numai procesele sunt prezentate;
fiecare arc trece printr-o resursă; pentru simplitate resursele au fost omise din figura;
procesul 3 pe maşina 1 aşteaptă două resurse, una deţinută de procesul 4 şi alta de
procesul 5.

Anumite procese asteapta pentru resurse locale, precum procesul 1, altele,

precum procesul 2, aşteaptă pentru resursele localizate pe o maşină diferită. Aceste
arcuri între maşini fac ca ciclurile să pară dificile. Algoritmul este invocat cand un
proces asteaptaa anumite resurse, de exemplu procesul 0 care blocheaza procesul 1:
un mesaj special probă este generat şi trimis la procesul (procesele) care deţin
respectivele resurse; mesajul consta din trei numere: procesul care tocmai s-a blocat,
procesul care expediază mesajul şi procesul la care vrea să trimită mesajul. Mesajul
iniţial de la 1 conţine tripletul (0, 0, 1). Când mesajul soseşte, destinatarul verifică
dacă el însuşi aşteaptă după alte procese. Dacă da, mesajul este actualizat, ţinând
primul câmp, dar înlocuindu-l pe cel de-al doilea cu propriul său număr de proces şi
al treilea cu numărul de proces după care aşteaptă. Mesajul este apoi expediat la
procesul din cauza căruia este blocat. Dacă este blocat de mai multe procese, la
fiecare dintre ele este expediat un mesaj (diferit). Mesajele la distanţă sunt etichetate
(0, 2, 3), (0, 4, 6), (0, 5, 7), si (0, 8, 0). Dacă un mesaj trece peste tot şi vine înapoi la
expeditor, adică se auto-întâlneşte în primul câmp al mesajului, există un ciclu şi
sistemul este în impas.
Intreruperea impasului:
1. O modalitate este aceea ca proces care initiaza mesajul proba sa se auto-
intrerupa. Această metodă are probleme dacă mai multe procese invocă algoritmul
simultan. De exemplu, dacă atât procesul 0 cât şi 6 se blochează în acelaşi moment, şi
ambele iniţiază un mesaj probă. Fiecare va descoperi eventual impasul şi fiecare se va
auto-intrerupe.
2. Un algoritm alternativ este acela în care fiecare proces adaugă identitatea sa
la sfârşitul unui mesaj probă astfel încât este returnat la expeditorul iniţial, ciclul
complet este vizibil. Expeditorul poate vedea care proces are numărul mai mare şi

12
cere respectivului să se întrerupă. In orice caz, dacă procese multiple descoperă în
acelaşi timp acelaşi ciclu, aleg să considere aceeaşi victimă.
Prevenirea distribuită a impasului constă în designul cu atenţie a sistemului
astfel încât impasurile sunt structural imposibile. Se folosesc tehnici care:
- permit proceselor să deţină numai o resursă la un moment dat
- solicită proceselor să ceară toate resursele iniţial
- obligând procesele să elibereze toate resursele când solicită una nouă
- cel mai des: ordonarea tuturor resurselor şi solicitarea către procese să le
primească numai în ordine strict crescătoare
- un proces nu poate deţine o resursă cu număr mare şi să ceară una cu număr
mai mic (face ciclurile imposibile)
Intr-un SD cu timp global şi tranzacţii atomice, alti doi algoritmi practici
pentru prevenire sunt posibili:
- bazaţi pe ideea de a asigna fiecărei tranzacţii o marcă de timp la
momentul startării
- esenţial este ca fiecare două tranzacţii să nu aibă asignate exact aceeaşi
marcă de timp.
Algoritmi alternative. Idei
1. Când un proces urmează să se blocheze pentru o resursă pe care altul o
utilizează, o verificare este realizată pentru a vedea care are marca de
timp mai mare (adica este mai tânăr). Se poate astfel permite aşteptarea
numai dacă procesul în aşteptare are o marcă de timp mai mică (este mai
bătrân) decât procesul după care aşteaptă. In această manieră, urmărind
orice lanţ de procese în aşteptare, mărcile de timp întotdeauna cresc,
astfel încât ciclurile sunt imposibile.
2. Alternativ: permite proceselor să aştepte numai dacă procesul care
aşteaptă are o marcă de timp mai mare (este mai tânăr) decât procesul
după care aşteaptă, în care caz mărcile de timp descresc în lanţ.
3. Este mai adecvat să se acorde prioritate proceselor mai bătrâne. Acestea
au rulat de mai mult timp, astfel încât sistemul a investit mult în acestea şi
este probabil să deţină mai multe resurse. Un proces tânăr care este
omorît va îmbătrâni până când va ajunge cel mai bătrân în sistem, astfel
încât aceasta alegere elimină înfometarea.
4. Omorârea unui tranzacţii: este relativ inofensivă, deoaerce prin definiţie,
aceasta poate fi repornită mai târziu.
Exemplu pentru algoritmul “aşteaptă-mori”
(a): un proces bătrân doreşte o resursă deţinută de un proces mai tânăr.
(b): un proces tânăr doreşte o resursă deţinută de un proces mai bătrân
- într-un caz trebuie să permitem unui proces să aştepte, în celălalt caz să fie
omorât
- presupunem că considerăm (a) moare şi (b) aşteaptă; atunci este omorât un
proces bătrân care încearcă să utilizeze o resursă deţinută de un proces mai tânăr,
ceea ce este ineficient (astfel trebuie să procedăm pe dos, aşa cum este arătat în
figură)
13
 - în aceste condiţii, săgeţile indică întotdeauna direcţia de creştere a numerelor
de tranzacţie, făcând ciclurile imposibile

- acest algoritm este numit “aşteapta-mori”.

-observaţii: presupunând existenţa tranzacţiilor, este posibil ca resursele să fie
luate de la procesele în rulare. Când apare un conflict, în loc să fie ucis procesul care
efectuează cererea, se poate omorî proprietarul resursei. Fără tranzacţii, omorârea
unui proces poate avea consecinţe severe, deorece procesul e posibil să fi fost
modificat de fişiere, de exemplu. Cu tranzacţii, aceste efecte dispar când tranzacţiile
mor.
Exemplu pentru algoritmul rănit-aşteaptă
- o tranzacţie este rănită (omorâtă) şi alta aşteaptă
- daca un proces mai bătrân doreşte o resursă deţinută de un proces mai tânăr,
tranzacţia tânărului este omorâtă
- procesul mai tânăr reporneşte probabil imediat şi încearcă să obţină resursa,
ceea ce îl va determina să aştepte
- contrast cu “aşteaptă-mori” în care:
- dacă un bătrân doreşte o resursă deţinută de un tânăr, va trebui să
aştepte politicos
- dacă un tânăr doreşte o resursă deţinută de bătrân, cel tânăr este omorât
- va porni din nou şi va fi omorât din nou
- acest ciclu poate continua de atâtea ori de cât este necesar procesului
bătrân să elibereze resursa

Algoritmul “rănit-aşteaptă” nu are această proprietate neplăcută.

14
 10. Toleranţa la defecte
Un sistem are un defect dacă nu satisface specificaţiile sale.
Exemple:
- un sistem distribuit de emitere de ordine pentru un supermarket – un defect
poate rezulta in lipsa la un moment dat a conserve de fasole
- într-un sistem distribuit de control a traficului aerian, un defect poate fi
catastrofic
Tipuri:
- defecte de componente
- defecte ale sistemelor distribuite
Defectele componentelor
Se pot defecta datorită unor erori în procesor, memorie, dispozitiv, cablu, sau
software.
Un defect este o funcţionare proastă, posibil cauzată de
- erori de proiectare
- eroare de manufacturare
- eroare de programare
- stricăciune fizică
- deteriorare în timp
- condiţii proaste de mediu (a nins pe calculator)
- intrări neaşteptate
- eroare de operare
- rozătoarele au mâncat o parte etc.
Nu toate defectele duc (imediat) la defecte de sistem, dar unele da.
Clasificare
Defecte tranzitorii: apar o dată şi dispar
- daca operaţia este repetată defectul dispare
- o pasăre care trece prin dreptul unui transmitator poate cauza o pierdere de
biţi in anumite retele
- dacă timpul de transmitere expiră şi se reincearcă, probabil va fi funcţional a
doua oară.
Defect intermitent: apare neaşteptat, dispare, reapare etc.
- un contact care este pierdut va cauza adeasea un defect intermitent
- defectele intermitente cauzeaze probleme grave pentru ca sunt greu de
diagnosticat
- tipic, când apare doctorul, sistemul lucrează perfect
Defect permanent este unul care continua să existe pană când componenta este
reparată (de exemplu chip ars, bug de software, crash de hard disk).
Scopul proiectării sistemelor tolerante la defecte: asigurarea faptului că întregul
continuă să funcţioneze corect, chiar şi în prezenţa defectelor.
- abordare clasică: analiza statistica a defectelor componentelor electrice
- dacă o componentă are probabilitatea p de funcţionare proastă într-o
secundă, timpul mediu de defectare este = l/p.
15
 Defecte ale sistemului
SD critice: sistemul trebuie să supravieţuiască defectelor componentelor (în
particular, procesoarelor), decât să fie facă acest lucru improbabil. Defectele
procesoarelor sau căderile pot fi înţelese fie ca defecte de procesor sau bug-uri
software.
Deoarece protocoalele standard pot ajuta recuperarea din erori de linii în
modalităţi predictibile, vom examina numai defecte de procesor!
Tipuri de defecte de procesor
Defecte silenţioase: un procesor se opreşte şi nu răspunde la intrări succesive
sau nu produce alte ieşiri, exceptând posibil că nu mai produce. Sunt numite de
asemenea defecte-stop.
Defecte bizantine: procesorul care produce defect va continua sa ruleze,
transmiţând răspunsuri greşite la întrebări, posibil lucrând împreună maliţios cu alte
procesoare cu defect dând impresia că lucrează corect când nu este cazul. Bug-urile
software nedectare adesea produc defecte bizantine. Tratarea defectelor bizantine este
mult mai dificila decât cazul a defectelor silenţioase. Termenul “bizantin" se referă la
imperiul bizantin din perioada 330- 453 din Balcani în care conspiraţiile, intrigile şi
necredinţa erau comune în cercurile de conducere.
Sisteme “sincrone” vs. “asincrone”
Presupunem că avem un sistem în care dacă un procesor trimite un mesaj la
altul, se garantează faptul că se primeşte un răspuns în timpul T cunoscut in avans.
Timpul T include timp suficient pentru a trata pierderea mesajelor (transmiţându-le de
n ori).
Un sistem care are proprietatea că întotdeauna există un răspuns la un mesaj
într-un interval de timp cunoscut dacă este funcţional se spune că este sincron;
neavând aceasta proprietate se spune că este asincron.
Aceasta terminolgie intră în conflict cu utilizarea tradiţională a lor; este utilizat
în măsură mare în tolerarea defectelor. Sistemele asincrone sunt mai complicat de
tratat decât cele sincrone. Dacă un procesor poate trimite un mesaj şi cunoaşte
absenţa răspunsului în T secunde înseamnă ca recipientul s-a defectat deci poate lua o
măsură corectivă. Nu există o limita superioară pentru cât este necesar răspunsului să
fie recepţionat, deci determinarea faptului că a existat un defect va fi o problemă.
Utilizarea redundanţei ca abordare generală
1. Redundanţa informaţiei: sunt adăugaţi biţi suplimentari pentru a permite
recuperarea biţilor pierduţi. De exemplu, se poate adăuga un cod Hamming pentru
transmiterea datelor ce permite recuperarea din zgomotele de pe linia de transmitere.
2. Redundanţa în timp: este efectuată o acţiune, şi apoi, dacă este necesar, este
efectuată din nou. Exemple: utilizarea tranzacţiilor atomice – daca tranzacţia este
abortata, poate fi re-efectuata fara a produce probleme. Este utilă în mod special când
defectele sunt tranzitorii sau intermitente.
3. Redundanţa fizică: este adăugat echipament suplimentar pentru a face
posibil ca întregul sistem să tolereze pierderea sau funcţionarea proastă a anumitor

16
componente. De exemplu: procesoare suplimentare pot fi adăugate la sistem astfel
încât numai o parte din ele se defectează, sistemul poate încă funcţiona corect. Există
doua modalităţi de organizare acestor procesoare extra:
- replicare activă
- backup primar
Exemplu: cazul unui server. Când este utilizată replicarea activă, toate
procesoarele sunt utilizate tot timpul ca servere (în paralel) pentru a ascunde complet
defectele. Schema de backup primar utilizează doar un procesor, înlocuindu-l cu cel
de backup când se defectează.
Tolerarea defectelor utilizând replicarea activă: este utilizată în
- biologie (mamiferele au doi ochi, două urechi, doi plămâni, etc.),
- transporturi aeriene (Boing 747 are patru motoare, dar poate zbura cu trei)
- sport (referinte multiple în cazul pierderii unui eveniment).
Anumiti autori se refera la replicarea activa ca fiind abordarea starii masinii. Este
utilizată pentru tolerarea defectelor în circuite electrice:
- circuitul în (a): semnalul trece prin dispozitivele A, B şi C, în secvenţa

- presupunem ca elementul A2 se defectează:

- fiecare dintre votaţi, V1, V2 si V3 primesc două intrari bune (identice)
şi una greşită şi fiecare dintre ele scot valoarea corectă în etapa a doua
- în esenţă, efectul defectului lui A2 este complet mascat, a.î. intrările la
B1, B2 şi B3 sunt exact la fel ca şi când n-ar fi existat defect.
- să considerăm în plus că şi B3 şi C1, produc defect, în plus faţă de A2. Aceste
efecte sunt de asemenea mascate, a.i. cele trei ieşiri finale sunt corecte.
- la prima vedere nu este evident de ce sunt necesari trei votanti la fiecare
etapă. De fapt, un singur votant pote detecta şi pasa informaţia majoritară. Totuşi, un
votant este de asemenea o componentă care poate eşua. Pp., de exemplu, că V1
funcţioneaza prost. Intrarea B1 va fi greşită, însă B2 şi B3 vor produce aceeaşi ieşire
şi V4, V5 & V6 vor produce toate rezultatul corect în etapa 3. Un defect în V1 nu
este diferit de un defect in B1 care produce o ieşire greşită, dar în ambele caz nu este
votat mai târziu.
- TMR poate fi aplicat recursiv, de exemplu, pentru a face un cip de încredere
prin utilizarea TMR în acesta.

17
 Câta replicare este necesară?
Răspunsul depinde de cantitatea de tolerare a erorii. Un sistem se spune că este
k-tolerant la defecte dacă poate supravieţui defectelor în k componente şi încă să
corespundă specificaţiilor. Dacă componentele, fie procesoarele, eşuează silenţios,
atunci este suficient sa exista k + 1 procesoare pentru a oferi k-toleranţă la defecte.
Dacă k dintre ele se opresc atunci răspunsul poate fi obţinut de la cel rămas.
Dacă procesoarele au defecte bizantine, continuând să ruleze şi când sunt
defecte şi trimit răspunsuri eronate sau aleatoare. Un minim de 2k + 1 procesoare sunt
necesare pentru a atinge k-toleranţă la defecte. In cel mai rău caz, k procesoare
defecte pot genera accidental (sau chiar intenţionat) acelaşi răspuns. Totuşi, cele k + 1
rămase vor produce acelaşi rapsuns, a.i. clientul sau votantul se poate încrede in
majoritate.
Tolerarea defectelor utilizând backup primar
Ideea esenţială a metodei de backup primar este aceea că există un singur
server care este primar şi realizeaza ceea ce se cere. Dacă acest server primar se
defectează, backupul preia sarcinile. Ideal, această schimbare trebuie să se facă într-o
modalitate cât mai clară şi vizibilă numai sistemului de operare al clientului, nu
programelor aplicaţii. Această schemă este des utilizată în lumea reală: guvernare
(vice-preşedinte), aviaţie (co-pilot), automobil (roată de rezervă), generatoare de
rezervă în camerele de operaţii din spitale.
Toleranţa de defecte bazate pe primar-backup are două avantaje majore faţă de
replicarea activă: este mai simplă în timpul operaţiilor normale pentru că mesajele
merg înspre un server (cel primar) şi nu către întregul grup respectiv în practică este
necesar un număr mic de maşini, deoarece la un moment dat este necesar un primar şi
un secundar
Dezavantaje: lucrează slab în prezenţa defectelor bizantine în care primarul
declară în mod eronat că lucrează bine; recuperarea dintr-o defectare a primarului
poate fi complexă şi consumatoare de timp.
Exemplu- protocol simplu primar-backup pentru o operaţie de scriere

Un client expediază un mesaj către primar, care realizează sarcina şi apoi

expediază un mesaj de actualizare către backup. Când backupul primeşte mesajul,
efectuează sarcina şi expediază un mesaj de confirmare către primar. Când vine
confirmarea, primarul expediază mesaj de răspuns la client.
Care ar fi efectul căderii primarului în diferite momente ale RPC?
- dacă primarul cedează înainte să efectueze sarcina (pas 2), nu se strică
nimic; clientul va intra în time-out şi va reincerca; dacă încearcă destul,
şi eventual va reuşi să efectueze sarcina o singură dată;

18
 - dacă primarul cedează după ce efectuează sarcina, după expediere şi
actualizare, când backupul preia şi cerinţele vin din nou; lucrul va fi
realizat de două ori – dacă acesta are efecte secundare, poate fi o
problemă
- daca primarul cedează după pasul 4, dar inainte de pasul 6, lucrul se
poate termina efectuându-se de trei ori, o dată la primar, o dată la
backup ca rezultat al pasului 3, şi o dată ce backupul devine primar
- dacă cerinţele poartă identificatori atunci este posibil să fie asigurat că
sarcina este realizată numai de două ori; asigurarea că este realizată
numai o singură dată este imposibilă.
Când să se treacă de la primar la backup? Backupul poate sa trimita mesaje
“Esti viu?" periodic către primar. Dacă primarul nu răspunde într-un anumit timp,
backupul poate prelua. Ce se întâmplă dacă primarul nu s-a defectat, dar e mai încet?
Intr-un sistem asincron nu exista nici o modalitate de a distinge între un primar încet
şi unul care s-a defectat. Soluţia cea mai bună este un mecanism hardware în care
backupul poate opri sau reboota primarul. Toate schemele primar-backup necesită un
acord, care este greu de atins, pe când replicarea activă nu cere întotdeauna un
protocol pentru acord (ex. TMR). O altă soluţie este utilizarea un disk cu port dual
între primar şi secundar: când primarul obţine o cerere, scrie cererea pe disk înainte
de a efectua sarcina şi de asemenea scrie rezultatele pe disk.
Acord în sistemele cu defecte
In numeroase SD-uri există necesitatea de a ajunge la un acord asupra unui
lucru. De exemplu: alegerea unui coordonator, decizia de a efectua o tranzacţie sau
nu, împărţirea sarcinilor între lucrători, sincronizare, etc. Scopul algoritmilor de acord
distribuit este de a face ca toate procesoarele defectuoase să ajungă la consens pe
anumite teme, după un număr finit de paşi. Sunt posibile cazuri diferite, depinzând
de parametrii sistemului:
1. Sunt mesajele livrate cu încredere tot timpul?
2. Pot procesele să cedeze, şi în acest caz, se defectează silenţios sau bizantin?
3. Este sistemul sincron sau asincron?
Cazul 1: considerăm procesoarele ca fiind perfecte, dar liniile de comunicare
pot pierde mesaje. O problema faimoasă, cunoscută ca problema celor doua armate,
ilustrează dificultatea de a pune două procesoare perfecte de acord asupra unui singur
bit de informaţie.
Problema celor două armate: armata roşie, cu 5000 de ostaşi, este campată
într-o vale. Două armate albastre, fiecare cu 3000 de ostaşi, sunt campate în jurul
dealurilor înconjurătoare care domină valea. Dacă cele două armate albastre pot să-şi
coordoneze atacul aupra armatei roşii, vor fi victorioase. Totuşi, dacă atacă singure,
vor fi măcelărite. Armatele albastre vor să-şi sincronizeze atacul. Totuşi singura lor
posibilitate de comunicaţieeste să trimită un mesager care să străbată valea.
Mesagerul poate fi capturat de armata roşie şi mesajul poate fi pierdut (adică vor
trebui să utilizeze un canal de comunicaţie nesigur). Problema este următoarea: există
vreun protocol care să permită armatelor albastre să învingă? Să presupunem că
comandantul primei armate albastre trimite un mesaj: „Propun să atacam pe 29
19
martie", mesajul ajunge la armata 2 al cărei comandant răspunde: „De acord", iar
răspunsul ajunge înapoi la armata 1. Va avea loc atacul în acest caz? Probabil că nu,
deoarece comandantul armatei 2 nu ştie dacă răspunsul său a ajuns sau nu la
destinaţie. Să încercăm să îmbunătăţim protocolul adăugându-i încă un pas: iniţiatorul
propunerii de atac trebuie să confirme răspunsul. Presupunând că nici un mesaj nu
este pierdut, armata 2 va avea confirmarea, dar comandantul armatei 1 va ezita acum:
înainte de orice, el nu ştie dacă confirmarea sa a ajuns la destinaţie şi este sigur că
dacă aceasta nu a ajuns, armata 2 nu va ataca. Am putea să încercăm un protocol cu
confirmare în patru timpi, dar ne-am lovi de aceleaşi probleme.
Concluzie: Chiar cu procesoare ne-defectuoase (generali), acordul între chiar
şi numai două procese nu este posibil în cazul unei comunicări care nu este de
încredere !!!
Cazul 2: comunicarea este perfectă, dar procesoarele nu. Problema clasică şi în
acest caz apare dintr-o perspectiva militară şi este numită problema generalilor
bizantini. Armata roşie este şi în acest caz campată în vale, dar există n generali
albaştri care conduc armate aflate pe dealurile apropriate. Comunicarea este realizată
prin telefon şi este perfectă, dar m generali sunt trădători (defectuoşi) şi încearcă activ
să împiedice generalii loiali să ajungă la un acord prin furnizarea de informaţii
contradictorii şi incorecte (modelează proceduri care funcţioneaza prost). Intrebare:
pot generalii loiali să ajungă la un acord? Fiecare general ştie numărul de soldaţi pe
care îi are. Scopul problemei: pentru generali să schimbe numarul de soldaţi, a.i. la
sfarsitul algoritmului, fiecare general are un vector de lungime n corespunzând
tuturor trupelor albastre. Dacă generalul i est loial, atunci elementul i este valoare
corecta a trupei sale, altfel este nedefinit.
Algoritmul recursiv a lui Lamport (1982)
Exemplu 1: pentru n = 4 si m = 1 => 4 pasi
1. Fiecare general expediaza un mesaj (de incredere) la toti generalilor
anunţând numărul soldaţilor săi. Generalii loiali spun adevărul; trădătorii pot spune
fiecărui general o minciuna diferită. Vedem (a) că generalul 1 raportează 1K,
generalul 2 raporteză 2K, generalul 3 minte pe fiecare, dând x, y, si z, iar generalul 4
raportează 4K.
2. Rezultatele anunţurilor din pasul 1 sunt colectate împreuna în vectorul (b)
3. Pasul 3 consta în pasarea de către fiecare general a vectorului său de la (b) la
fiecare alt general.
- generalul 3 minte, inventand 12 valori noi,
- rezultatele pasului 3 sunt arătate in (c).
4. Fiecare general examinează elementul al i-lea pentru fiecare dintre vectorii
noi primiţi.
- dacă valoare are o majoritate, valoarea este pusa in vectorul rezultat
- dacă nici o valoare nu are majoritatea, elementul corespunzător este
marcat ca UNKNOWN.
- (c): generalii 1, 2, si 4 ajung la acord asupra (1, 2, UNKNOWN, 4), rezultatul
corect
- trădătorul n-a fost capabil să saboteze decizia.

20
 Exemplu 2: pentru n = 3 şi m = 1, adică 2 generali loiali şi un trădător,
In (c): nici un general loial nu vede o majoritate pentru elementul 1, elementul
2, sau elementul 3, a.i. toate sunt marcate UNKNOWN. Algoritmul a eşuat să
producă un acord.

Cazul general: Lamport a demonstrat că într-un sistem cu m procesoare

defectuoase, acordul poate fi atins numai dacă 2m + 1 procesoare corect funcţionale
sunt prezente, dintr-un total de 3m + 1. Acordul este posibil numai dacă mai mult
decât două treimi din procesoare lucrează corect.
Fischer a demonstrat că într-un SD cu procesoare asincrone şi întârzieri
nemărginite în transmitere, nu este posibil un acord chiar dacă numai un procesor este
defectuos (chiar dacă procesorul se defectează silenţios). Problema sistemelor
asincrone este aceea că procesoarele arbitrar încete nu se disting de cele care sunt
oprite. Numeroase rezultate teoretice sunt cunoscute pentru cazuri în care acordul este
posibil şi pentru cazuri când nu este posibil.

21
 11. Modele de calcul distribuit

Procesoarele dintr-un sistem de calcul distribuit pot fi organizate în mai multe

moduri.
Modele de bază
1. Modelul staţiilor de lucru
2. Modelul grupării de procesoare
3. Modelul hibrid oferind facilităţi ale celor două de mai sus.

1. Modelul staţiilor de lucru

Sistemul constă din staţii de lucru (PCuri) împrăştiate într-o clădire sau campus
şi conectate printr-o reţea LAN de viteza mare. Anumite staţii pot fi în birouri şi
astfel sunt dedicate implicit unui singur utilizator, pe când altele pot fi în domenii
publice şi pot avea mai mulţi utilizatori în cursul unei zile. In ambele cazuri, la orice
moment de timp, o staţie are un singur utilizator care este logat, şi astfel are un
“proprietar" (temporar), sau este neutilizat.
Avantajele modelului statiilor de lucru:
- modelul este uşor de înţeles
- utilizatorii au o cantitate specifică de putere de calcul şi astfel se
garantează timpul de răspuns
- programe grafice complicate pot fi foarte rapide deoarece au acces
direct la ecran
- fiecare utilizator are un grad mare de libertate şi poate aloca resursele
staţiei sale aşa cum doreşte
- discurile locale contribuie la aceasta independenţă şi fac posibilă
continuarea lucrului chiar dacă apar erori.
Modelul are două probleme majore:
1. In măsura în care cipurile procesor devin din ce în ce mai ieftine, va fi în
curand posibil ca fiecare utilizator să dispună de exemplu de 100 CPU-uri.
2. O mare parte a timpului utilizatorii nu folosesc staţiile lor de lucru, care sunt
astfel neutilizate, pe când alţi utilizatori necesită capacitate suplimentară de calcul şi
nu o obţin. Dintr-o perspectivă a sistemelor, alocarea resurselor astfel încât anumiţi
utilizatori au resurse de care nu au nevoie pe când alţi utilizatori au nevoie de
asemenea resurse, este ineficient.
Prima problemă poate fi rezolvată realizând dintr-o staţie de lucru un multi-
procesor individual. Această situaţie poate conduce la o utilizare ineficientă a
resurselor, dar cu cât tehnologia devine din ce în ce mai ieftină, irosirea lor devine un
păcat mai redus.
Problema a doua, cea a staţiilor de lucru neocupate, este subiect pentru
numeroase cercetări, în mod primar pentru ca numeroase universităţi au număr mare
de staţii de lucru individuale din care multe sunt inactive. Măsurătorile arată că, chiar
şi în perioade maxime de utilizare în decursul unei zile, adesea peste 30 % din staţiile
de lucru sunt neocupate. In timpul nopţii, cu atât mai mult.

22
 Utilizarea staţiilor neocupate: încercarea cea mai timpurie pentru a permite
staţiilor de lucru neocupate să fie utilizate a fost programul care vine de la Berkeley
Unix: rsh. Primul argument numeşte maşina şi a doua comandă care să fie rulată.
Rulează comanda specificată pe o maşină specificată. Deşi este des utilizată, acest
program are mai multe probleme:
- utilizatorul trebuie sa spuna care masina sa fie utilizata, punand astfel
întreaga povară de a ţine evidenţa maşinilor neocupate asupra
utilizatorului;
- programul se executa în mediul maşinii la distanţă, care este în mod uzual
diferite de mediul local;
- dacă cineva trebuie să se logheze pe maşina pe care procesul rulează,
procesul va continua să ruleze şi utilizatorul nou logat trebuie să accepte
performanţa scăzută sau să găsească altă maşină.
Intrebările cheie sunt:
1. Cum sunt găsite staţiile de lucru inactive?
2. Cum poate rula transparent un proces la distanţă?
3. Ce se întâmplă dacă proprietarul maşinii se întoarce?
1. Cum sunt găsite staţiile de lucru inactive?
La o prima privire, poate apărea că o staţie de lucru pe care nu este nimeni
logat de la consolă este o staţie de lucru inactivă, dar în numeroase sisteme, deşi nu
este nimeni logat exista o mulţime de procese care rulează, precum procese demoni
pentru timp, mail, ştiri etc. Pe de altă parte, un utilizator care se loghează când vine
dimineaţa la servici poate să atingă calculatorul pentru ore sau nu foloseşte toate
resursele. Sisteme diferite iau decizii diferite a ceea ce înseamnă “inactiv”. Uzual se
consideră că dacă nimeni n-a atins tastatura sau mouse-ul pentru mai multe minute şi
nu există nici un proces în rulare care a fost iniţiat de utilizator, staţia de lucru este
considerată inactivă. In consecinţă, este posibil să existe diferenţe substanţiale în
încărcările dintre o staţie de lucru şi alta, datorate, de exemplu, volumului de mail-uri
care ajunge la primul şi nu şi la al doilea.
Localizarea staţiilor de lucru inactive
Algoritmii utilizaţi pentru localizarea staţiilor libere pot fi divizate în două
categorii:
a) Conduse de server: când o staţie de lucru devine inactivă, şi devine astfel
un server potenţial pentru calcule, anunţă disponibilitatea sa. Poate să facă acest lucru
anunţând numele său, adresa de reţea, şi proprietăţile de exemplu la un registru (fişier
sau bază de date). Când un utilizator doreşte să execute o comandă la o staţie
inactivă, introduce comanda şi are loc o căutare în registru (pe bază de program)
pentru a găsi o staţie de lucru inactivă adecvată. Din motive de încredere este posibil
să existe mai multe copii ale registrului.

23
 O modalitate alternativă pentru staţiile de lucru care devin inactive este să
anunţe faptul că sunt neutilizate este aceea de a difuza un mesaj în reţea:
- toate celelalte staţii de lucru înregistrează acest fapt.
- de fapt, fiecare maşină menţine propria sa copie privată a registrului
- avantaj: surplus mai mic în găsirea unei staţii de lucru inactive şi o
redundanţă mai mare
- dezavantajul este necesitatea lucrului pentru menţinerea registrului.
Indiferent dacă este un registru sau mai multe, există un pericol potenţial
datorat condiţiilor de tratare concurentă.
- dacă doi utilizatori invocă o metodă la distanţă simultan şi amândoi
descoperă aceeaşi maşină care este inactivă, amândoi pot porni procese în
acelaşi timp pe aceasta
- pentru a detecta si evita aceasta situatie, sistemul la distanţă poate verifica
dacă staţia la distanţă este încă liberă şi marca dacă nu este cazul
- apelantul poate trimite indicaţii de mediu de execuţie şi poate starta
procesele conform figurii.
b) Conduse de client: când o staţie de lucru devine inactivă şi devine astfel un
server potenţial pentru calcule, anunţă disponibilitatea sa. Când se invoca un program
la distanta, se difuzeaza o cerere indicand care program se doreste a fi rulat, câtă
memorie este necesară, etc. Aceste detalii nu sunt necesare dacă toate statiile de lucru
sunt identice, dar dacă sistemul este eterogen şi nu orice program poate rula pe orice
statie, acestea sunt esenţiale. Când replicile vin înapoi, se consideră unul dintre ele şi
se setează corespunzător. O facilitate adecvată este aceea de a solicita staţiilor de
lucru inactive să întârzie răspunsurile proporţional cu încărcarea pe care o au (astfel
răspunsul de la cea mai puţin încărcată staţie va ajunge primul şi va putea fi selectat).
2. Cum poate rula transparent un proces la distanţă?
Mutarea codului este simplă. Pentru a rula trebuie setat mediul la distanţă pentru
a se asemăna cu cel dorit pentru rulare, astfel încât: să fie executat ca şi cum ar fi
executat local; este necesară aceeaşi imagine asupra sistemului de fişiere, acelaşi
director de lucru, aceleaşi variabile de sistem (dacă sunt necesare). Probleme pot să
apară când primul apel de sistem, de exemplu un READ, este executat. Ce trebuie să
facă nucleul? Răspunsul depinde în mare măsura de arhitectura sistemului. Dacă toate

24
fişierele sunt localizate pe servere de fişiere, nucleul poate emite o cerere către
serverul de fişiere adecvat în aceeaşi modalitate în care o face pentru un proces local.
Dacă sistemul are discuri locale, fiecare cu un sistem de fişiere complet, cererea
trebuie înaintată la maşina gazdă pentru execuţie.
Apeluri de sistem la distanţă
Anumite apeluri de sistem trebuie înaintate la maşina gazdă (de exemplu,
citirile de la tastatură şi afişarea pe ecran nu pot fi realizate la maşina la distanţă).
Alte apeluri de sistem trebuie realizate la distanţă (de exmplu, toate apelurile sistem
care interoghează starea maşinii trebuie să fie executate pe maşina pe care procesul
rulează, acestea includ interogări precum numele maşinii şi adresa de reţea, câtă
memorie este disponibilă, etc). Apelurile de sistem ce implică timp sunt o problemă
pentru că ceasurile diferitelor maşini pot să nu fie sincronizate. Forwardarea
apelurilor legate de timp către maşina gazdă introduce de asemenea întârzieri.
Anumite apeluri precum crearea şi scrierea de fişiere temporare pot fi realizate mai
eficient pe maşina la distanţă. A face programele să ruleze pe maşini la distanţă ca şi
cum ar rula pe maşina localş este o afacere complexă şi delicată.

3. Ce se întâmplă când proprietarul maşinii se intoarce?

1. Varianta cea mai simplă este aceea de a nu face nimic, dar aceasta abordare
este împotriva ideii de staţie de lucru "personală". Dacă alte persoane pot rula
programe pe staţia ta de lucru în acelaşi timp în care încerci s-o utilizezi, se pierde
timpul garantat de răspuns.
2. O altă posibilitate este de a omorî toate procesele intruse. Modalitatea cea
mai simplă este aceea de a o face abrupt şi fără avertizare. Dezavantajul este acela că
lucrul este pierdut şi sistemul de fişiere poate fi într-o stare haotică. O modalitate mai
bună este de a oferi procesului o avertizare prin expedierea unui semnal pentru a-l
opri “cu graţie” (scrierea bufferelor pe disc, închidere fişiere etc). Dacă nu s-a oprit în
câteva secunde, este terminat. Desigur, programul trebuie scris astfel încât să aştepte
şi să trateze acest semnal, ceea ce nu fac majoritatea programelor.
3. O abordare complet diferită este migrarea procesului către o altă maşină, fie la
maşina locală, fie la o altă staţie de lucru inactivă. Partea grea nu este mutarea
codului şi datelor utilizatorului, ci găsirea şi strângerea tuturor datelor legate de
procesul care părăseşte sistemul. De exemplu, poate avea fişiere deschise, contoare,
mesaje de primit în coadă şi o serie de alte informatii împrăştiate în nucleu. Toate
aceastea trebuie înlăturate cu atenţie din maşina şi reinstalate cu succes la noua
maşină destinaţie. Deşi nu există probleme teorerice dificile, dificultăţile practice
inginereşti sunt substanţiale. Când procesul pleacă, trebuie să lase maşina în aceeaşi
stare în care a găsit-o, pentru a evita disturbarea proprietarului. Această cerinţă
înseamnă că nu numai procesul în sine trebuie să plece, dar şi toate procesele fii
precum şi fii acestora. Conexiunile de reţea şi alte structuri de date legate de sistem
pot fi şterse şi trebuie ignorate replicile la RPC sau alte mesaje care sosesc pentru
proces după ce acesta a plecat. Fişierele temporare trebuie şterse, şi dacă este posibil,
să se restaureze cache-ul.

25
 Caz particular: calcul voluntar
BOINC – standard
- standard open-source pentru volunteer computing
- utilizează timpul de inactivitate a calculatoarelor (Windows, Mac sau
Linux) pentru numeroase tipuri de cercetări ştiintifice
- aplicaţii: studii asupra bolilor, incalzirea globala, descoperirea pulsarilor…
- aplicatii curente:
- Astronomie/ Fizica/ Chimie: Einstein@home, Milkyway@home,
Quantum Monte Carlo@Home, Spinhenge@home,LHC@home,
SETI@home, Cosmology@Home,uFluids@home
- biologie, medicină: Rosetta@home, GPUGrid.net, Superlink@Technion,
POEM@HOME, Malariacontrol.net, Docking@Home
- Matematica, calcul, si jocuri: Rectilinear Crossing Number, NFS@home,
VTU@home, SHA-1 Collision Search, ABC@home, AQUA@home,
PrimeGrid, Chess960@home, NQueens@home
Altele:
- XtreemWeb
- Desktop Grid
- GridRepublic + Intel programme Progress Thru Processors

Modelul grupării de procesoare (Cluster)

Deşi utilizarea staţiilor de lucru inactive adaugă putere de calcul la sistem, nu
abordează o temă fundamentală mai importantă: ce se întâmplă când este fezabil, să
se ofere de 10 sau 100 de ori mai mult CPUs decât utilizatori activi?
1. O soluţie, indicată anterior, este de a oferi fiecăruia un multiprocesor
personal - totuşi acesta este un design ineficient.
2. O abordare alternativă este aceea de a construi o grupare de procesoare
(processor pool), un rack plin de CPUuri dintr-o sală a serverelor, care este alocată
dinamic utilizatorilor la cerere. In locul ofertei de staţii de lucru invididuale pentru
utilizatori, în acest model utilizatorii au terminale pentru facilităţi de calcul de
performanţă înaltă.
Conceptual, acest model este mai apropiat de modelul traditional de partajare a
timpului decât de modelul staţiilor de lucru, deşi este construit pe baza tehnologiilor
moderne.
Motivare. Dacă sistemul de fişiere poate fi centralizat într-un număr mic de
servere de fişiere pentru a face economii în ceea ce priveste scara, este posibil să se
facă acest lucru şi cu serverele de calcul. Prin punerea mai multor CPU-uri într-un
singur rack mare în sala serverelor, se fac reduceri în ceea ce priveşte consumul de
energie. Modelul permite de asemenea creştere incrementală. Dacă încărcarea de
calcul creşte cu 10 procente, se pot cumpăra cu 10% mai multe procesoare care să fie
introduse în grupare. Puterea de calcul este transformată în “staţii de lucru inactive”
care sunt accesate dinamic. Utilizatorii pot fi asignaţi la numeroase CPU-uri pentru
perioade scurte după care returnează controlul asupra acestora. Nu există un concept
de proprietate: toate procesoarele aparţin în mod egal la fiecare.

26
 Natura încărcării: dacă utilizatorul realizează o simplă editare şi ocazional
expedează mesaje electronice atunci o staţie de lucru individuală este suficientă.
Dacă, pe de alta parte, utilizatorii sunt angajati într-un proiect mare de dezvoltare,
ruland frecvent sau pe directoare mari sau încearcă să facă calcule numerice pe
structuri de date foarte mari sau fac simulări sau rulează programe mari de inteligenţă
artificiala sau programe de rutare VLSI atunci sunt în permanenţă în căutare de
calculatoare inactive. In aceste situaţii, ideea grupului de procesoare este
fundamental simplă şi atractivă.
Sisteme de cozi
Un sistem de cozi tratează o situaţie în care utilizatorii generează cereri într-un
mod aleator pentru lucru către un server. Când serverul este ocupat, utilizatorii sunt
pusi in coada pentru procesare si servicii. Exemple comune şi în viaţa de zi cu zi sunt:
cozile la supermarket-uri, la înregistrarea la aeroport, etc. Sistemele de cozi pot fi
modelate analitic.
Exemple de sisteme de cozi pentru clustere
1. Condor
Este un sistem de administrare a incarcarii specilaizat pentru sarcini de
calcul intensiv. Ofera un mecanism al cozilor de sarcini, politici de planificare,
scheme de prioritate, monitorizarea resurselor şi administrarea resurselor. Este utilizat
pentru sisteme batch. Utilizatorii submit sarcinile la Condor, care: le plaseaza într-o
coada; alege când şi unde să ruleze sarcinile şi cu ce prioritate; monitorizează cu
atenţie progresul acestoral; informează utilizatorul asupra terminării.
2. LSF
JobScheduler este parte a unei solutii de administrare a încărcării. Oferă o
imagine singulară pentru o reţea eterogenă de calculatoare; mapare dinamică şi
inteligentă a resurselor şi balans al încărcării; monitorizare centralizată a resurselor;
informare asupra încărcării şi sarcinilor; planificare bazată pe calendar/ eveniment/
sarcină.
3. PBS: operează în medii multi-platforme Unix.

Model hibrid

Un compromis posibil între cele două modele analizate este acela de a avea un
PC şi acces la un cluster. Deşi aceasta soluţie este mai costisitoare decât celelalte
două, combină avantajelor lor. Lucrul interactiv poate fi realizat pe staţii de lucru,
oferind un timp de răspuns garantat. Staţiile de lucru inactive rămân inactive. Toate
procesele ne-interactive rulează în cluster, deoarece presupun în general calcule
complicate. Acest model oferă un timp de răspuns rapid şi o utilizare eficientă a
resurselor. Referinţe: Grid computing, Cloud computing.

27
 12. Algoritmi de alegere
Numeroşi algoritmi distribuiţi necesită un proces care se comportă ca şi
coordonator, iniţiator, secvenţiator sau realizeaza alte sarcini speciale (de exemplu:
coordonatorul din algoritmul centralizat pentru excluderi mutuale). Problema care
apare se referă la analiza algoritmilor pentru selectarea coordonatorului. Algoritmii
diferă prin modul în care fac localizarea (dacă toate procesele sunt la fel, fără nici o
caracteristică care să le distingă, nu există nici un mod de a alege unul dintre ele).
Presupunerea 1: fiecare proces are un număr unic, de exemplu adresa de reţea
(pentru simplitate, vom presupune un proces per maşină). In general, algoritmii de
alegere încearcă să localizeze procesul cu cel mai mare număr şi îl desemnează
coordonator.
Presupunerea 2: fiecare proces cunoaşte numărul de proces pentru fiecare alt
proces.
Presupunerea 3: ceea ce procesele nu ştiu este care dintre ele sunt defecte şi care
nu la un moment dat.
Scopul unui algoritm de alegere: a se asigura că alegerea porneşte şi termină cu
un acord între toate procesele asupra coordonatorului.

Algoritmul terorist (Garcia-Molina)

Când un proces afla că coordonatorul nu mai răspunde la cereri, iniţiază o

alegere. Un proces P care efectuează o alegere, procedează astfel:
1. P expediează un mesaj ELECTION la toate procesele cu numere mai mari.
2. Dacă nici unul nu răspunde, P câştigă alegerea şi devine coordonator.
3. Dacă unul dintre cele cu un număr mai mare răspunde, se aşteaptă ca acesta
să preia coordonarea şi sarcina lui P este gata
- dacă un proces primeşte un mesaj ELECTION de la unul dintre colegii săi cu
număr mai mic, trimite un mesaj OK înapoi la expeditor pentru a indica că este viu şi
preia alegerea, apoi susţine o alegere, dacă nu este.
- eventual, toate procesele renunţă în afara unuia, acela fiind noul coordonator.
Anunţă victoria prin expedierea către toate procesele a unui mesaj care le spune că
este noul coordonator.
- dacă un proces care a fost defect o perioadă revine, iniţiaza o alegere. Dacă
are numărul cel mai mare, câştigă alegerea şi reia jobul coordonatorului.
- astfel cel mai “puternic” învinge, de aici numele de “algoritmul terorist."
Exemplu: grupul constă din 8 procese. Procesul 7 a fost coordonator, dar s-a
defectat. Procesul 4 este primul care sesizează acest fapt şi trimite mesaje
ELECTION către toate procesele cu numere mai mari, respectiv procesele 5 şi 6 care
amândouă răspund cu OK. Când primeşte unul dintre cele două răspunsuri, 4
cunoaşte faptul că sarcina lui a fost terminată. Atât 5 cât si 6 preiau alegerea, fiecare
trimitand mesaje la toate procesele cu numar mai mare decat el. Procesul 6 spune lui
5 ca preia alegerea. Procesul 6 stie ca 7 este defect si de aceea este câştigător.
Procesul 6 anunţă acest lucru expediind mesajul COORDONATOR la toate
28
procesele. Când procesul 4 primeşte mesajul, poate continua cu operaţia pe care
încerca s-o realizeze când 7 a căzut, dar utilizând procesul 6 ca şi coordonator de
această dată. Dacă procesul 7 este restartat, expediază la ceilalţi un mesaj
COORDONATOR şi le terorizează să participe.

Algoritmul inelului

Este bazat pe utilizarea unui inel. Presupune că procesele sunt ordonate fizic
sau logic, astfel încât fiecare proces cunoaşte doar pe succesorul sau. Când un proces
sesizează că coordonatorul nu funcţionează, construieşte un mesaj ELECTION
conţinând numărul său de proces şi expediază mesajul la unul dintre succesorii săi.
Dacă succesorul este căzut, expeditorul sare peste succesor şi trece la următorul
membru din inel sau chiar şi peste acesta, până când este depistat un procesor care
rulează. La fiecare pas, expeditorul adaugă numărul său de proces la lista din mesaj.
Eventual, mesajul ajunge din nou la procesul care l-a iniţiat. Procesul recunoaşte
acest eveniment când recepţionează un mesaj care conţine propriul număr. La acest
moment, tipul mesajului este schimbat în COORDONATOR şi circulă încă o dată, de
data aceasta informând pe fiecare cine este coordonatorul (membrul din lista cu cel
mai mare număr) şi care sunt membrii din noul inel. Când mesajul a circulat o dată,
fiecare trece înapoi la lucru.
Exemplu: două procese, 2 si 5, descoperă simultan că coordonatorul anterior,
procesul 7, a căzut. Fiecare dintre acestea construieşte un mesaj ELECTION şi
porneşte să-l circule. Eventual, ambele mesaje se vor reîntoarce şi amabele (2 şi 5) le
vor converti în mesaje COORDONATOR, cu exact aceiaşi membri şi în aceeaşi
ordine. Când ajung din nou înapoi algoritmul este oprit. Extra mesaje circulă în
sistem, dar nu consumă o lungime de bandă mare.

29
30