Curs 9

Fire de executie
Interblocarea proceselor

Sisteme de operare
Lect. Dr. Ozten CHELAI

Facultatea de Matematica si Informatica

Universitatea Ovidius Constanta

Curs9 SO - lect. dr. Ozten Chelai, 2009-2010 1

 FIRE DE EXECUTIE

Firul de execuŃie este o abstractizare a sistemului de operare care
se referă la procesare.

Un fir de execuŃie este unitatea de execuŃie a unui proces
reprezentand elementul activ al unui proces.

Un proces va avea cel puŃin un fir de execuŃie, dar poate avea şi mai
multe.

Procesul reprezintă un spaŃiu de adresare comun pentru unul sau
mai multe fire de execuŃie. ExecuŃia instrucŃiunilor este realizată de
firele de execuŃie.

Un proces poate fi văzut ca un container pentru execuŃii format din
resurse de memorare şi de comunicare. Firele de execuŃie ale unui
proces partajează resursele comune de memorare şi comunicare,
dar posedă resurse proprii de procesare.

Firele de execuŃie se mai numesc şi procese uşoare (lightweight
processes).
Procese monofilare si multifilare
 FIRE DE EXECUTIE

Resurse - fiecare fir de execuŃie are asociate

o secvenŃă de instrucŃiuni,

un set de registre procesor şi

o stivă.

Comunicarea

La procese comunicarea este mai redusa, deoarece procesele sunt utilizate în
implementarea de activităŃi independente cu o relaŃie foarte slabă între ele.

La firele de execuŃie comunicarea este mare deoarece sunt utilizate în
implementarea de activităŃi ce cooperează şi comunică frecvent cantităŃi
importante de informaŃii- prin resursele comune de memorie. Această formă de
comunicare este mai eficientă deoarece se face în acelaşi spaŃiu de memorie,
fără intervenŃia sistemului de operare în transferul de informaŃii.

Stări. Ca şi procesele, firele de execuŃie pot fi într-una din starile activ,

ready sau blocat. De asemenea, există şi starea terminat, specifică
firelor şi gestionată la nivelul procesului.
Fire de executie

Planificarea

În general este de tip non-preemtiva (firul se va executa pâna la terminarea
sau blocarea sa).

Dar există şi sisteme în care se face o planificare preemtivă în baza
suportului oferit de SO. În acest caz avem de a face cu multitasking
controlat (ex. Windows începând cu WinNT).

Dacă execuŃiile sunt scurte se prefera planificarea fără cuanta de timp.

Planificarea se poate face pe bază de priorităŃi, dar la sistemele mai
sofisticate există primitive (apeluri sistem) ce permit adaptarea algoritmului
de planificare.

Probleme. Datorită spaŃiului comun de memorare apare necesitatea
asigurării consistenŃei acestuia în cazul acceselor concurente. Aceasta
se realizează cu mecanisme speciale pentru sincronizare a firelor de
execuŃie.

Crearea firelor de executie:

Static - toate firele de execuŃie ale unui proces sunt lansate odată cu
iniŃializarea procesului după care se vor bloca în aşteptarea evenimentului
pe care sunt destinate să-l trateze.

Dinamic - iniŃial se crează câte un fir pe proces, iar ulterior sunt lansate noi
fire odată cu apariŃia evenimentului corespunzător fiecăruia (pop-up
threads).
Fire de executie – Modele de organizare

Modelul dispecer / executanŃi

Acest model presupune existenŃa unui fir dispecer responsabil cu extragerea solicitărilor
din lista de aşteptare şi cu delegarea lor către un fir de execuŃie liber şi care are
implementată logica de soluŃionare a solicitării respective. Alegerea executantului se face
funcŃie de natura solicitării în raport cu codul specific executantului.

Listă de aşteptare cu solicitări execuŃii

Modelul echipă

În modelul echipă toate firele de execuŃie au acces la lista de aşteptare cu solicitari.
Fiecare fir este responsabil atât cu extragerea solicitării corespunzătoare logicii sale cât şi
cu soluŃionarea acesteia. După soluŃionarea unei solicitări un fir de execuŃie va inspecta
din nou lista de aşteptare pentru o nouă solicitare destinată tipului de execuŃie pe care o
implementează firul respectiv.

Listă de aşteptare cu solicitări execuŃii

Fire de executie – Modele de organizare

Modelul bandă de asamblare

Modelul bandă de asamblare presupune că fiecare fir este responsabil cu o
parte a soluŃionării unei solicitări de execuŃie. După încheierea acestei părŃi,
solicitarea este trimisă următorului fir pentru a continua soluŃionarea pe baza
logicii sale specifice.

Listă de aşteptare cu solicitări execuŃii

Este important de reŃinut că selecŃia modelului care va fi utilizat se face

de către programatorul aplicaŃiei funcŃie de logica acesteia.
Apeluri sistem – UNIX (Posix)

Creare/terminare fir de execuŃie
pthread_creat
pthread_exit

Sincronizarea firelor de execuŃie se face la nivelul logici procesului
prin utilizarea diferitelor mecanisme de sincronizare oferite sub forma
apelurilor de sistem ale SO (semafoare, monitoare, blocare LOCK,
send/receive).

Protejare acces la resursa partajată cu mutex, apeluri utilizate pentru
sincronizări cu aşteptare activă, când resursa este ocupată pentru
scurtă durată.
pthread_mutex_init
pthread_mutex_destroy
pthread_mutex_lock
pthread_mutex_unlock

Protejare acces la resursa partajată cu lock (variabila de blocare),
apeluri utilizate pentru sincronizări fără aşteptare activă, cu trecerea
firului în starea blocat, când resursa este ocupată pentru lungă durată.
pthread_cond_init
pthread_cond_destroy
pthread_cond_lock
pthread_cond_unlock

Sincronizarea firelor multiple dupa modelul barieră. Acest model
este utilizat atunci când logica aplicaŃiei impune ca fiecare fir trebuie să
ajungă la o instrucŃiune specifică din codul său pentru ca întreg
ansamblul de fire să poată continua execuŃia.
pthread_join
Apeluri sistem – Windows (Win32x)

Creare/terminare fir de execuŃie
Thread
endThread

Gestionare obiect de tip CriticalSection, ce reprezintă o zonă
partajată
CreateCriticalSection
EnterCriticalSection
LeaveCriticalSection

Protejare acces la resursa partajată cu mutex (obiect de
sincronizare care poate fi utilizat de un singur proces), apeluri utilizate
pentru sincronizări cu asteptare activă, când resursa este ocupată
pentru scurtă durată.
CreateMutex
ReleaseMutex – utilizat la eliberarea resursei (unlock)
WaitForSingleObject – utilizat la ocuparea resursei (lock)

Protejare acces la resursa partajată cu lock (variabila de blocare),
apeluri utilizate pentru sincronizări fără aşteptare activă, cu trecerea
firului în starea blocat, când resursa este ocupată pentru lungă durată.
CreateSemaphore
ReleaseSemaphore – utilizat la eliberarea resursei (UP)
WaitForSingleObject – utilizat la ocuparea resursei (DOWN)
Sincronizarea firelor multiple dupa modelul barieră.
WaitForMultipleObjectsexecuŃia.
Fire de executie – Exemple - Windows

SO Windows implementează Win32API.

AplicaŃiile Windows sunt procese independente ce pot avea fire multiple de
execuŃie.

Componentele de bază ale unui fir de execuŃie sunt:

identificator unic,

set de regiştrii ce reprezintă starea procesorului,

o stivă pentru execuŃiile firului în mod utilizator şi una pentru cele în mod nucleu.

O zonă de memorie proprie firului utilizată de bibliotecile de timp real şi de cele cu
legare dinamică (DLL).

Setul de regiştrii, stivele şi zona privată de memorie formează contextul firului şi
au o arhitectură specifică hardware-lui pe care este instalat sistemul de operare.
-in general dispecer-executant;
- fiecarui fir i se atribuie o coada de mesaje cu solicitare de execuŃie;
- multitasking controlat cu regim de time sharing;
- implementeaza un spatiu de adresă (stocare a variabilelor) proprii firului TLS;
- mecanismul de sincronizare - sunt implementate cu obiecte de tip:
nucleu: secŃiuni critice (modul de sincronizare); utilizator (semafor, excluderea mutuala);

modul de sincronizare:
declarare critica section -> structura de date interna a SO la care au acces controlat toate
firele;
apelurile – InitializedCriticalSection -> se observa pointeri la aceeaşi structura;
EnterCritical Section -> solicita execuŃia codului, daca este blocat firul se deblochează la
acceptarea accesului;
la terminare va executa LeaveCriticalSection;
daca nu mai foloseşte zona va executa DeleteCriticalSection;
Fire de executie – Java (JMV)

clasa Thread -> extinsa;

avem la dispoziŃie apeluri:

setare prioritate, asigurare la grup - lansarea execuŃiei la întregul grup (suspend, stop,
…),

control stare (suspend, stop),

lansare (run);

sincronizare:

declaraŃia Synchronized pt. clasa, metoda prin implementarea modelului monitor;

se pot realiza planificări - priorităŃi:
fire ,round robin, cuanta de timp;

ObservaŃii:

La Posix avem semantici speciale pt. apeluri exec, fork (duplicare a firului curent
nu a întregului ansamblu);

Gestionarea:

a) semnale primite de proces de la alte procese:
 sincrone (excepŃii) sau
 asincrone (evenimente,întreruperi);

b) se poate face prin rutina de tratare implicita la nivelul procesului sau rutina de tratare
explicita de program;

Varianta pt. gestionarea a firelor de execuŃie:

distribuirea semnalului câtre firul la care se aplica, distribuirea semnalului tuturor
firelor de proces;

distribuŃia semnalului unor anumite fire;
Fire de executie – Java (JMV)

Firele Java sunt gestionate de JVM

Firele Java (threads) pot fi create:

Extinzand clasa Thread

Implementand interfata Runnable

Starile firelor de executie Java
INTERBLOCAREA PROCESELOR
– Resurse

Componente SO multitasking:

Procese cu executie paralela

Resurse utilizate de procese

Resursele sunt caracterizate de tip,

fiecare resursă fiind o instanŃă a unui anume tip.

Deşi pot fi diferite din punct de vedere fizic, resursele de un anume tip sunt identice din
punct de vedere logic (funcŃie de nivelul de abstractizare pe care este definit tipul de
resursă).

Utilizarea unei instanŃe de resursă de către un proces are loc în următoarea
secvenŃă de activităŃi:

solicitare – procesul solicită resursa şi aşteaptă alocarea acesteia dacă resursa nu
este disponibilă imediat

utilizare – procesul a obŃinut acces la resursă şi o poate exploata

eliberare – procesul eliberează resursa.

Odată alocată, instanŃa respectivă nu mai este disponibilă altor solicitări, până la
eliberarea sa.

Exemple de operaŃii tipice de solicitare/eliberare resursă sunt:

request/release pentru diferite dispozitive,

open/close pentru fişiere,

allocate/free pentru memorie.

De asemenea, solicitarea/eliberarea unei resurse se poate semnaliza prin operaŃii
wait/signal asupra semaforului ataşat acesteia.
INTERBLOCAREA PROCESELOR
– Definitie

Exemplu: procesul P1 deŃine o resursă R1 şi procesul P2 deŃine
o resursă R2. Dacă la un moment dat continuarea procesului P1
este condiŃionată de obŃinerea resursei R2 (în condiŃiile în care
necesită în continuare acces şi la resursa R1), iar continuarea
procesului P2 necesită şi obŃinerea resursei R1, atunci nici unul
din cele două procese nu mai poate continua, apărând astfel
fenomenul de interblocare a lor. Mai general, fenomenul de
interblocare a proceselor poate să apară şi pentru mai mult de
două procese.

DefiniŃie: Un set de procese se află în stare de interblocare
(blocaj permanent) dacă fiecare proces aşteaptă un eveniment
ce poate fi cauzat doar de un alt proces din set. Starea de
interblocare este caracterizată de faptul că resursele sistemului
sunt alocate astfel încât procesele respective nu-şi mai pot
continua execuŃia.

Majoritatea sistemelor de operare nu oferă facilităŃi de prevenire
a interblocării proceselor. Programatorul de aplicaŃii multifilare
este responsabil cu gestionarea corectă a acestei probleme.
Modelarea interblocării
proceselor. Conditii necesare
Pentru ca starea de interblocare să apară la nivelul unui set dat de
procese este necesară îndeplinirea simultană a următoarelor condiŃii:

Excludere mutuală: cel puŃin una din resurse trebuie deŃinută în mod
exclusiv de către un proces; în consecinŃă, dacă un alt proces solicită
acestă resursă atunci execuŃia lui va fi întârziată până la eliberarea ei.

DeŃine şi aşteaptă: un proces deŃine cel puŃin o resursă şi totodată
aşteaptă obŃinerea de resurse suplimentare, deŃinute de alte procese.

Nu există drepturi de preempŃiune: orice resursă este eliberată doar
în mod voluntar de procesul care o deŃine, în momentul în care aceasta
nu-i mai este necesară.

Aşteptare circulară: există un set de procese {P0, P1,…, Pn} aflate în
următorul regim de aşteptare a accesului la resurse: Pi aşteaptă o
resursă deŃinută de Pi+1, unde i=0,…,n-1, iar Pn aşteaptă o resursă
deŃinută de P0.

De remarcat că aceste condiŃii nu sunt complet independente. Astfel,
condiŃia 4 implică 2.
Modelarea interblocării proceselor.
Graful alocarii resurselor

O descriere riguroasă a interblocării proceselor se face utilizând o
reprezentare de tip graf direct, care conŃine setul de noduri N şi setul
de arce A.

Setul N conŃine elemente de două tipuri: procese şi tipuri de resurse.

Subsetul P={P1, P2,…, Pn} reprezintă procesele active din sistem iar

subsetul R={R1, R2,…, Rm} reprezintă tipurile de resurse(un tip de resursă
poate avea mai multe instanŃe la nivelul unui sistem dat).

Setul A contine

Un arc de la Pi la Rk se notează cu Pi → Rk, se numeşte arc de solicitare
(Request edge) şi semnifică faptul că procesul Pi a lansat o solicitare pentru
o resursă de tip Rk şi se află în aşteptarea soluŃionării ei.

Un arc de la Rk la Pi, notat prin Rk → Pi reprezintă faptul că o instanŃă a
resursei de tip Rk este deŃinută de procesul Pi şi de numeşte arc de
atribuire[(Assignment edge).

Nodurile de tip P sunt reprezentate prin cercuri iar cele de tip R prin
dreptunghiuri conŃinând un număr de puncte egal cu numărul
instanŃelor tipului de resursă.
Modelarea interblocării proceselor.
Graful alocarii resurselor
P1
Exemplu de graf
P2
de alocare resurse
R3

R2
P3
R1

Se observă că un arc de solicitare se adresează unui tip de resursă, pe când un arc de

atribuire este conectat la o instanŃă. La alocarea unei resurse un arc de solicitare este
transformat în arcul de alocare corespunzător.

Graful de alocare din figura este format din seturile:

P={P1,P2,P3} set de procese

R={R1,R2, R3} set de tipuri de resurse

E = Es∪Ea set de arce, cu

Es={P2→R2} setul arcelor de solicitare

Ea={R1→P1, R1→P2, R3→P2, R2→P3} setul arcelor de alocare.

Se observă că resursele R1, R2, R3, au respectiv 2, 1 şi 1 instanŃe. De asemenea, din
punct de vedere a accesului la resurse, procesele se află în următoarele stări:

P1 deŃine o instanŃă de resursă de tip R1 şi nu solicită alocarea altei resurse3,

P2 deŃine câte o instanŃă de resursă de tip R1 şi R3 şi solicită alocarea unei resurse de tip R2,

P3 deŃine o instanŃă de resursă de tip R2 şi nu solicită alocarea altei resurse.
Modelarea interblocării proceselor.
Graful alocarii resurselor

Se arată că dacă un graf de alocare resurse nu conŃine cicluri atunci sistemul este liber de
interblocări.

Dacă există un ciclu atunci o interblocare este posibilă, dar nu există în mod necesar.

Pentru a preciza dacă interblocarea există într-adevăr, este necesară analiza suplimentară
a grafului. CondiŃia de existenŃă a ciclului este necesară şi suficientă doar dacă fiecare
resursă are exact o singură instanŃă. Altfel, ea este doar condiŃie necesară.

Să analizăm cazul în care, dată fiind starea din figura, procesul P3 lansează o solicitare
pentru o resursă de tip R1. R3

P1 R3
P2 Graf de alocare resurse, fără
interblocare

R2
P3
R1


Se observă apariŃia unui ciclu în graful de alocare resurse. Analizând ciclul P2→ R2→
P3→ R1→ P2 se observă că resursa R1 are două instanŃe, una din ele aparŃinând
procesului P1 ce ar putea să o elibereze. Odată eliberată, acestă instanŃă poate fi alocată
procesului P3. În acest caz, deşi sunt implicate într-un ciclu, procesele P2 şi P3 nu sunt
interblocate.
Modelarea interblocării proceselor.
Graful alocarii resurselor

Dacă însă, sistemul fiind în acestă nouă stare, apare şi o
solicitare din partea lui P1 pentru alocarea unei resurse de tip
R3, atunci în graf apare ciclul P2→ R2→ P3→ R1 → P1 → R3 →
P2.

De data acesta avem de a face cu o interblocare a ansamblului
proceselor P1, P2 şi P3 deoarece P1 aşteaptă eliberarea unei
resurse deŃinută de P2, P2 aşteaptă eliberarea unei resurse
deŃinută de P3 iar P3 aşteaptă eliberarea unei resurse cu două
instanŃe, ambele deŃinute de P2, respectiv de P1

P1 R3
P2 Graf de alocare resurse, cu
interblocare

R2
P3
R1

.
Tratarea interblocarii
proceselor

În general, prevenirea interblocării proceselor se
face impunând restricŃii asupra solicitării şi alocării
resurselor. Acest lucru conduce la o scădere a
coeficientului de utilizare a resurselor şi la reducerea
generalităŃii sistemului.

Există trei metode fundamentale pentru tratarea
interblocării proceselor.

Prevenirea sau evitarea interblocărilor prin proiectarea
sistemului astfel încât să nu fie posibilă apariŃia acestora.

Detectarea interblocărilor şi refacerea sistemului.

Ignorarea, bazată pe premiza că în sistem nu apar
interblocări.
Tratarea interblocarii
proceselor

Prevenirea interblocărilor, se bazează pe o serie de metode prin care
se asigură faptul că cele patru condiŃii necesare apariŃiei unei
interblocări nu vor fi îndeplinite simultan. Acest lucru se realizează prin
impunerea unei discipline de solicitare a resurselor bazată pe un set de
restricŃii.

Pentru evitarea interblocărilor sistemul de operare necesită în avans
informaŃiile referitoare la solicitările de resurse ce vor fi făcute de
fiecare proces. Pe baza lor se decide dacă o resursă liberă va fi alocată
procesului solicitant imediat sau cu o întârziere ce va permite evitarea
unei posibile interblocări ulterioare.

Detectarea interblocărilor şi refacerea sistemului se realizează prin
utilizarea unui algoritm care examinează starea sistemului pentru a
detecta apariŃia unei interblocări şi a unui algoritm pentru eliminarea
acesteia.

Ignorarea, bazată pe premiza că în sistem nu apar interblocări.

Majoritatea sistemelor de operare nu oferă facilităŃi de prevenire,
evitare sau detectare a interblocării proceselor, deci abordează metoda
tratării acestora prin ignorare. Această abordare este totuşi răspândită
fiind cea mai eficientă în ansamblu, deoarece tratarea interblocărilor
este costisitoare iar probabilitatea apariŃiei acestora este mică dacă
programele sunt bine realizate.
Prevenirea interblocarii
proceselor

Prevenirea interblocării proceselor se realizează în principiu prin
evitarea apariŃiei la un moment dat a cel puŃin uneia din condiŃiile
precizate.

Referitor la excluderea mutuală, resursele partajabile (cum ar fi de
exemplu un fişier accesibil doar pentru citire) nu necesită acces
exclusiv, deci nu pot fi implicate în blocaje permanente. Pe de altă
parte, excluderea mutuală este o condiŃie obligatorie de acces la
resursele nepartajabile, deci în acest caz nu poate fi evitată.

O metodă simplă de evitare a condiŃiei “deŃine şi aşteaptă” este

implementarea unui algoritm care permite fiecărui proces să obŃină
simultan toate resursele de care are nevoie, la lansarea sa.

O variantă mai generală a acestui protocol impune ca procesul să
lanseze o solicitare de resurse doar atunci când nu deŃine nici o
resursă, o astfel de solicitare putând fi însă făcută de oricâte ori în
cursul execuŃiei procesului, funcŃie de resursa sau grupul de resurse
necesare la un moment dat în logica acestuia. Dezavantajele acestui
protocol sunt legate de faptul că resurse din cele alocate într-un grup
sunt neutilizate pe perioade destul de lungi şi de posibilitatea apariŃiei
fenomenului de “înfometare”, când un proces ar putea aştepta un timp
nedefinit alocarea resurselor necesare.
Prevenirea interblocarii proceselor

Pentru a evita îndeplinirea celei de a treia condiŃii se
poate utiliza un protocol în care un proces care
deŃine un grup de resurse şi solicită resurse
suplimentare pe care nu le poate obŃine imediat, va
elibera resursele deŃinute deja.

Resursele eliberate astfel sunt adăugate la lista de
resurse solicitate de proces, împreună cu cele
cerute suplimentar.

Procesul va fi repornit în momentul în care poate
avea acces la toate resursele din această listă.

Alternativ, la o solicitare de resurse din partea unui
proces, ele îi sunt alocate dacă sunt disponibile sau
dacă nu sunt disponibile dar sunt alocate unui
proces care aşteaptă, la rândul lui, alte resurse. În
acest caz un proces este repornit atunci când
primeşte toate resursele solicitate şi toate resursele
pe care le-a cedat în timp ce aştepta.
Prevenirea interblocarii proceselor

În fine, pentru a preveni aşteptarea circulară, se realizează o
ordonare totală a tuturor tipurilor de resurse iar procesele
trebuie să lanseze solicitări pe baza acestei ordonări, în
ordine ascendentă.

Formal, fie R={R1, R2,…, Rm} setul tipurilor de resurse.

Se defineşte funcŃia injectivă F : R→IN care ataşază fiecărui tip
de resursă un număr natural unic.

Un protocol pentru prevenirea interblocării proceselor impune
regula prin care fiecare proces poate solicita resurse doar în
ordinea ascendentă a numerotării acestora.

IniŃial un proces poate solicita instanŃe ale oricărui tip de resursă
Ri.

Ulterior el poate solicita doar instanŃe ale tipurilor Rk pentru care
F(Rk)> F(Ri).

Solicitarea de instanŃe multiple ale aceluiaşi tip se face simultan,
cu o singură cerere.

Alternativ se poate folosi regula prin care, dacă un proces solicită
o instanŃă de resursă de tip Rk el trebuie mai întâi să elibereze
toate resursele de tip Ri pentru care F(Ri)≥ F(Rk). Se poate
demonstra, prin reducere la absurd, că utilizarea acestor
protocoale evită apariŃia aşteptării circulare.
Evitarea interblocarii
proceselor

Evitarea interblocării proceselor se face utilizând informaŃii
suplimentare despre modul în care urmează a fi solicitate
resursele, adică secvenŃele complete de operaŃii request/release
pentru fiecare proces din sistem.

Decizia de alocare a unei resurse la un moment dat se face pe
baza cunoaşterii setului de resurse disponibile, setului de resurse
alocate şi secvenŃelor de alocare ale fiecărui proces, astfel încât
să se evite o posibilă interblocare ulterioară.

Un algoritm simplu şi util cere fiecărui proces să declare numărul
maxim de resurse de fiecare tip necesare.

Algoritmii utilizaŃi diferă prin cantitatea şi tipul informaŃiilor
solicitate. Ei examinează dinamic starea alocării resurselor,
definită de numărul de resurse disponibile şi alocate şi de
numărul maxim de solicitări din partea proceselor, şi realizează
alocarea resurselor astfel încât sistemul nu se va bloca.
Evitarea interblocarii
proceselor. Stare de siguranta

Sistemul este în stare de siguranŃă dacă poate aloca resurse
fiecărui proces, conform solicitărilor maxime ale acestuia, într-o
anumită ordine, în condiŃiile evitării interblocărilor.

Formal sistemul se află în stare de siguranŃă dacă există o
secvenŃă de siguranŃă.

DefiniŃie. SecvenŃa de procese <P0, P1,…, Pn> este o secvenŃă
de siguranŃă pentru starea curentă a alocării resurselor dacă
pentru orice proces Pi, solicitările de resurse pe care acesta le
mai poate lansa pot fi satisfăcute de resursele curent disponibile
şi de cele deŃinute de toate procesele Pk cu k<i.

Dacă nu sunt disponibile imediat toate resursele solicitate de Pi,
atunci Pi poate să aştepte terminarea tuturor proceselor Pk după
care va obŃine toate resursele necesare, le va utiliza şi apoi le va
elibera astfel încât orice proces Pm cu m>i să poată obŃine la
rândul lui toate resursele solicitate.
Evitarea interblocarii proceselor.
Stare de nesiguranta

Dacă nu există o secvenŃă de siguranŃă atunci spunem că
sistemul este în stare de nesiguranŃă.

MulŃimea stărilor de blocaj permanent este o submulŃime a
stărilor de nesiguranŃă; starea de blocaj permanent este o stare
de nesiguranŃă.

O stare de nesiguranŃă nu este în mod necesar stare de blocaj
permanent, dar poate conduce la o astfel de stare deoarece
sistemul nu poate să prevină solicitări care să genereze
interblocarea proceselor.

Starea de siguranŃă şi starea de blocaj permanent sunt
exclusive.

Pe baza conceptului de stare de siguranŃă se pot defini algoritmi
care nu permit sistemului să treacă în stări de nesiguranŃă,
realizând astfel evitarea interblocărilor. IniŃial sistemul se află în
stare de siguranŃă, iar un astfel de algoritm va decide în fiecare
moment acea alocare de resurse care păstrează sistemul în
stare de siguranŃă. E posibil ca, deşi este liberă, o resursă să nu
fie alocată imediat, ceea ce conduce la o subutilizare a
resurselor.
Evitarea interblocarii proceselor. Algoritm pe
graful de alocare a resurselor

Dacă fiecare tip de resursă are o singură instanŃă, în vederea
evitării interblocărilor se utilizează un graf special de alocare a
resurselor.

Acesta este derivat din cel descris, la care se adaugă un nou tip
de arc numit arc de revendicare (Claim edge).

Un arc de revendicare Pi→Rk indică faptul că procesul Pi poate
solicita în viitor resursa Rk şi este marcat cu linie punctată.

Atunci când are loc solicitarea propriu-zisă, arcul de revendicare
se transformă în arc de solicitare, iar când resursa ele eliberată
arcul devine din nou de revendicare.

Arcele de revendicare trebuie reprezentate pe graf înainte de
lansarea procesului.

O condiŃie mai puŃin restrictivă spune că un arc de revendicare
poate fi adăugat unui proces doar dacă toate arcele asociate
procesului sunt de revendicare.
Evitarea interblocarii proceselor. Algoritm pe
graful de alocare a resurselor

O cerere pentru o resursă reprezentată de un arc de solicitare Pi→Rk este
servită doar în cazul în care convertirea arcului de solicitare în arc de atribuire
nu conduce la apariŃia unui ciclu în graful de alocare resurse.

Verificarea faptului că sistemul rămâne în stare de siguranŃă se face utilizând un
algoritm pentru detectarea ciclurilor în graf.

Dacă acesta nu detectează nici un ciclu atunci sistemul este în stare de
siguranŃă. Altfel sistemul este pus în stare de nesiguranŃă iar procesul solicitant,
Pi, nu va primi resursa imediat ci va fi pus în aşteptare.

Fie următorul graf (figura (a)) reprezentând faptul că P1 deŃine R1 iar P2 solicită
R1. De asemenea, atât P1 cât şi P2 revendică R2, adică urmează să o solicite
în viitor.
R1 R1

P2 P2
P1 P1

R2 (a) R2 (b)

Figura. Graf de alocare pentru evitarea interblocării; stare sigură (a); stare nesigură (b)

Dacă P2 solicită R2 resursa nu îi este alocată deşi este liberă, deoarece

această acŃiune ar conduce la apariŃia unui ciclu în graf şi la trecerea sistemului
în stare de nesiguranŃă.
Evitarea interblocarii proceselor. Algoritmul
bancherului

Acest algoritm se aplică cazurilor în care un tipurile
de resurse au instanŃe multiple.

La lansarea sa în sistem fiecare proces trebuie să
declare numărul maxim de instanŃe necesare din
fiecare tip de resursă (evident nu trebuie să
depăşească numărul instanŃelor resurselor existente
în sistem).

La apariŃia unei solicitări resursa este atribuită doar
dacă această acŃiune lasă sistemul în stare de
siguranŃă. Altfel se aşteaptă eliberarea altor resurse
din sistem astfel încât se formează un nou context
în care atribuirea resursei lasă sistemul în stare de
siguranŃă.

Algoritmul bancherului utilizează o serie de structuri
de date cu care se defineşte starea sistemului de
alocare resurse.
Detectarea interblocării proceselor

În cazul sistemelor care nu oferă facilităŃi de prevenire sau evitare a apariŃiei
interblocărilor se poate oferi o schemă de soluŃionare a problemei prin
detectarea acestora, formată din:

algoritm de examinare a stării sistemului în vederea depistării unei
interblocări,

algoritm pentru refacerea sistemului.

De remarcat faptul că acestă schemă induce în sistem atât costuri legate de
executarea algoritmului de detecŃie cât şi costurile posibilelor pierderi în cazul
refacerii sistemului după blocaj.

FrecvenŃa de invocarea a unui algoritm pentru detectarea interblocărilor este
corelată cu frecveŃa apariŃiei interblocărilor în sistem.

Resursele alocate proceselor aflate într-o interblocare vor fi neutilizate până la
eliminarea blocajului şi tot în acest interval e posibil ca numărul proceselor
implicate în interblocare să crească.

In extremis, se poate invoca acest algoritm ori de câte ori nu se poate realiza
imediat o alocare solicitată, în acest caz putându-se identifica nu numai
procesele implicate în interblocare ci şi procesul care a generat acest fenomen.

E posibil ca o anumită solicitare să producă mai multe cicluri în graf, deci mai
multe interblocări simultane.

O variantă mai puŃin costisitoare este invocarea algoritmului cu o frecvenŃă mai
mică definită fie de un interval prestabilit (ex. O oră), fie de o scădere la un
anumit procent (ex. 40%) a utilizării timpului procesor (ApariŃia interblocărilor
degradează treptat performanŃele sistemului, lucru vizibil în coeficientul de
utilizare a timpului procesor).
Recuperarea din blocaj permanent

În urma detectării unui blocaj permenent recuperarea poate fi trecută în sarcina
operatorului sau se poate executa automat.

Recuperarea automată se poate face fie prin anularea fie prin deposedarea de resurse
a unuia sau mai multor procese aflate pe traiectoria unei interblocări.

În cel de al doilea caz resursele devenite astfel disponibile vor fi realocate într-o altă
secvenŃă.

Anularea proceselor

Există două variante de anulare a proceselor implicate într-o interblocare.

În varianta grosolană sunt anulate toate procesele respective.

Într-o variantă mai puŃin agresivă procesele sunt anulate unul câte unul, fiind invocat
de fiecare dată un algoritm de detectare a interblocărilor pentru a sesiza momentul
eliminării interblocării.

Toate resursele alocate proceselor anulate revin la dispoziŃia sistemului.
Anularea unui proces poate induce alte probleme în sistem legate de operaŃii
neterminate ale acestuia.

Cea de a doua variantă permite şi alegerea proceselor ce vor fi anulate, acestă
alegere făcându-se pe criterii cum ar fi:

prioritatea procesului,

cât a durat procesul şi cât va mai dura până la terminarea sa,

câte şi ce tip de resurse utilizează procesul,

câte resurse mai sunt necesare pentru continuarea sa,

câte proceset trebuie anulate,

gradul de interactivitatea al procesului.
Deposedarea de resurse

Această metodă presupune redistribuirea unor resurse (luarea
de resurse de la anumite procese şi alocarea acestora pentru
alte procese) până la eliminarea interblocării.

Pentru acesta sistemul trebuie mai întâi să să selecteze
procesele victimă ce vor fi deposedate de resurse, conform unor
criterii de minimizare cost.

Un proces deposedar de resurse nu mai poate continua în starea
actuală deci va trebui relută activitatea sa dintr-o stare anterioară
de siguranŃă.

Cea mai simplă soluŃie este restartarea procesului, dar este mai
eficient ca, pe baza unor informaŃii suplimentare gestionate de
sistem, acesta să fie pus într-o stare anterioară suficientă pentru
eliminarea interblocării.

În cursul alocării de resurse este posibilă apariŃia fenomenului de
“înfometare” în sensul că anumitor procese li se vor lua resurse
în mod sistematic fiind astfel împiedicate să-şi termine
activitatea. Pentru eliminarea acestui fenomen, formula de calcul
a costului va include şi numărul de victimizări ale unui proces.
BIBLIOGRAFIE

Cristina Mindruta, Sisteme de operare –
suport de curs, www.univ-ovidius.ro/math