11. Predavanje - VTS NS

Modeli pristupa deljenim resursimaU teoriji i praksi konkurentnog programiranja koristi senekoliko modela (test-primera) za ispitivanje idemonstraciju praktično svakog novopredloženog konceptaza sinhronizaciju i komunikaciju između procesaOvi modeli odslikavaju tipične situacije nadmetanjakonkurentnih procesa za pristup do deljenih resursa kojese sreću pri konstrukciji OS i konkurentnih programaStandardni modeli:• ograničeni bafer (bounded buffer) – već obrađen• čitaoci i pisci (readers-writers)• filozofi koji večeraju (dining philosophers)2/285

Čitaoci i pisciKoncept monitora obezbeđuje međusobno isključenjepristupa konkurentnih procesa do deljenog resursa, uzeventualnu uslovnu sinhronizaciju. Međutim, konceptpotpunog međusobnog isključenja kod monitora ponekadpredstavlja suviše restriktivnu politiku koja smanjujekonkurentnost programaČesto se operacije nad deljenim resursom mogu svrstati uoperacije koje:• samo čitaju deljene podatke, odnosno ne menjaju stanje resursa(operacije čitanja)• upisuju u deljene podatke, tj. menjaju stanje resursa (operacijeupisa)Koncept monitora ne dozvoljava nikakvu konkurentnost ovih operacija3/285

Čitaoci i pisciKonkurentnost se može povećati ukoliko se dozvoli da:• proizvoljno mnogo procesa izvršava operacije čitanja (čitaoci,readers)• najviše jedan proces izvršava operaciju upisa (pisac, writer),međusobno isključivo sa drugim piscima, ali i sa čitaocimaNa taj način, deljenom resursu u datom trenutku možepristupati ili samo jedan pisac, ili jedan ili više čitalaca, aline istovremeno i jedni i drugi – više čitalaca-jedan pisac(multiple readers-single writer)Postoje različite varijante ove šeme koje se razlikuju upogledu prioriteta koji se daje procesima koji čekaju napristup resursu:• prioritet imaju pisci koji čekaju, tj. čim postoji pisac koji čeka, svinovi čitaoci biće blokirani sve dok svi pisci ne završe• prioritet imaju čitaoci, tj. piscu se ne dozvoljava pristup sve dok svičitaoci ne završe, a novi čitaoci se puštaju pre pisaca4/285

Čitaoci i pisciImplementacija korišćenjem monitora: monitor poseduječetiri operacije, startRead, stopRead, startWrite istopWrite. Čitaoci i pisci moraju da budu strukturirani nasledeći način:Reader:Writer:startRead();startWrite();...// Read data structure ...// Write data structstopRead();stopWrite();5/285

Čitaoci i pisciclass ReadersWriters {public:ReadersWriters ();void startRead ();void stopRead ();void startWrite ();void stopWrite ();private:Semaphore mutex, wrt;int readcount;};ReadersWriters::ReadersWriters (): mutex(1), wrt(1), readcount(0) {}void ReadersWriters::startWrite () {wrt.wait();}void ReadersWriters::stopWrite () {wrt.signal();}6/285

Čitaoci i piscivoid ReadersWriters::startRead () {mutex.wait();readcount++;if (readcount==1) wrt.wait();mutex.signal();}void ReadersWriters::stopRead () {mutex.wait();readcount--;if (readcount==0) wrt.signal();mutex.signal();}Problem?7/285

Filozofi koji večerajuProblem filozofa koji večeraju (dining philosophers, Dijkstra 1965.):Pet filozofa sedi za okruglim stolom na kome senalazi posuda sa špagetima, jedu i razmišljaju.Svaki filozof ima svoj tanjir, a između svaka dvasusedna tanjira stoji po jedna viljuška.Pretpostavlja se da su svakom filozofu, da bi seposlužio, potrebne dve viljuške, kao i da može dakoristi samo one koje se nalaze levo i desno odnjegovog tanjira. Ako je jedna od njih zauzeta,on mora da čeka. Svaki filozof ciklično jede, parazmišlja. Kad završi sa jelom, filozof spušta obeviljuške na sto i nastavlja da razmišlja. Poslenekog vremena, filozof ogladni i ponovopokušava da jede. Potrebno je definisati protokol(pravila ponašanja, algoritam) koji će obezbeditiovakvo ponašanje filozofa i pristup do viljušaka8/285

Problemi nadmetanja za deljene resurseDa bi konkurentni program bio korektan, mora da zadovoljisledeće uslove:• logičku korektnost rezultata bez obzira na redosled preplitanjaizvršavanja delova konkurentnog programa• živost (liveness) ili napredak (progress): sve što je programompredviđeno da se desi, treba da se desi u konačnom vremenu;procesi moraju da napreduju, ne smeju večno da čekajuGreške koji dovode do narušavanja ovih uslova:• utrkivanje (race condition): nije obezbeđena logička ispravnostrezultata u svim situacijama; primer je izostanak međusobnogisključenja kritične sekcije• izgladnjivanje (starvation): nije obezbeđena živost• živo blokiranje (livelock): nije obezbeđena živost• mrtvo blokiranje (deadlock): nije obezbeđena živost9/285

UtrkivanjePrimer (nekorektne) uslovne sinhronizacije:• suspend: bezuslovno suspenduje pozivajući proces• resume: bezuslovno deblokira imenovani proces, ako je blokiranflag : Boolean := false;Process P1: Process P2:... ...if not flag then suspend; flag := true;flag := false;P1.resume;... ...Problem: P1 ispita flag (=false), dođe do promenekonteksta, P2 postavi flag na true i izvrši resume P1(bez efekta), potom P1 izvrši suspend – gubitaksinhronizacije!Opšti primer: neobezbeđeno međusobno isključenjekritične sekcije10/285

UtrkivanjeOvakav neispravan uslov naziva se utrkivanje (racecondition). Nastaje zbog preplitanja delova koji bi moralibiti izvršeni neprekidivoTipično nastaje kao posledica toga što se odluka o promenistanja procesa (suspenziji) donosi na osnovu ispitivanjavrednosti deljene promenljive, pri čemu ta dva koraka nisunedeljiva, pa može doći do preuzimanja, tj. "utrkivanja" odstrane drugog procesa koji pristupa istoj deljenojpromenljivoj11/285

Mrtvo blokiranjeAlgoritam ponašanja filozofa:var forks : array 0..4 of semaphore = 1;task type Philosopher(i:int)var left, right : 0..4;beginleft := i; right:=(i+1) mod 5;loopthink;forks[left].wait; // take left forkforks[right].wait; // take right forkeat;forks[left].signal; // release left fork;forks[right].signal; // release right fork;end;end;Scenario: svaki filozof uzme svoju levu viljušku i čeka nadesnu?!12/285

Mrtvo blokiranjeOvakav neregularan uslov nastaje tako što se grupaprocesa koji konkurišu za deljene resurse međusobnokružno blokiraju - mrtvo (ili kružno) blokiranje (deadlock)U opštem slučaju, mrtvo blokiranje nastaje tako što segrupa procesa nadmeće za ograničene resurse, pri čemuproces P1 drži ekskluzivan pristup do resursa R1 i pri tomčeka blokiran da se oslobodi resurs R2, proces P2 držiekskluzivan pristup do resursa R2 i pri tom čeka blokiranda se oslobodi resurs R3, itd., proces Pn drži ekskluzivanpristup do resursa Rn i pri tom čeka blokiran da se oslobodiresurs R1. Tako procesi ostaju neograničeno suspendovaniu cikličnom lancu blokiranjaJedan od najtežih problema koji mogu da nastanu ukonkurentnim programima, multiprogramskim sistemima isamim operativnim sistemima13/285

Živo blokiranjeAlgoritam ponašanja filozofa koji izbegava mrtvo blokiranje:task type Philosopherloopthink;looptake_left_fork;if can_take_right_fork thentake_right_fork;exit loop;elserelease_left_fork;end if;end;eat;release_left_fork;release_right_fork;end;end;Scenario: svi filozofi uzmu svoju levu viljušku, ne mogu da uzmu desnu,pa spuste levu, i tako ciklično!?14/285

Živo blokiranjeOvakva neregularna situacija u konkurentnom programu,kod koje se grupa procesa izvršava, ali nijedan ne može danapreduje jer u petlji čeka na neki uslov, naziva se živoblokiranje (livelock)Treba razlikovati živo od mrtvog blokiranja. Iako se u obaslučaja procesi nalaze "zaglavljeni" čekajući na ispunjenjenekog uslova, kod mrtvog blokiranja su oni suspendovani,dok se kod živog izvršavaju, tj. uposleno čekajuObe situacije su neispravna stanja jer nije obezbeđenanjegova živost (liveness)15/285

IzgladnjivanjeAlgoritam ponašanja filozofa:task type Philosopherloopthink;take_both_forks;eat;release_both_forks;end;Scenario: Filozof X, njegov levi L, desni D; u jednom trenutku L možeda uzme obe svoje viljuške, što sprečava filozofa X da uzme svoju levuviljušku; pre nego što L spusti svoje viljuške, D može da uzme svoje,što opet sprečava filozofa X da počne da jede; teorijski, ovaj postupakse može beskonačno ponavljati, što znači da filozof X nikako ne uspevada zauzme svoje viljuške (resurse) i počne da jede, jer njegovi susedinaizmenično uzimaju njegovu levu, odnosno desnu viljušku!?16/285

IzgladnjivanjeOvakva neregularna situacija u konkurentnom programu,kod koje jedan proces ne može da dođe do željenogresursa jer ga drugi procesi neprekidno pretiču i zauzimajute resurse, naziva se izgladnjivanje (starvation), ilineograničeno odlaganje (indefinite postponement), ililockoutDrugi primer: prikazano rešenje čitalaca i pisaca; koizgladnjuje?17/285

Problemi nadmetanja za deljene resurseZaključak: da bi konkurentni program ili multiprogramski sistemobezbedio živost (progres), ne sme da poseduje probleme živogblokiranja, mrtvog blokiranja, ni izgladnjivanjaJedno korektno rešenje problema filozofa pomoću semafora:var forks : array 0..4 of semaphore = 1;deadlockPrevention : semaphore = 4;task type Philosopher(i:int) beginleft := i; right:=(i+1) mod 5;loopthink;deadlockPrevention.wait;forks[left].wait;forks[right].wait;eat;forks[left].signal;forks[right].signal;deadlockPrevention.signal;end;end;18/285

Mrtvo blokiranje - RešavanjeModel sistema:• deljeni resursi su grupisani u tipove; postoji n t (≥1)identičnih instanci resursa tipa t; resursi mogu biti fizički(I/O uređaj, CPU, memorija itd.) ili logički (fajl, semafor,monitor itd.)• kada neki proces traži resurs tipa t, bilo koja od n t instanciresursa tog tipa može da mu bude dodeljena, ukoliko jeslobodna• svaki proces mora da traži (request) resurs(e) tipa t prenego što ga (ih) upotrebi i da ga (ih) oslobodi (release)posle upotrebe; ukoliko ne postoji dovoljno slobodnihresursa datog tipa kada ih proces traži, proces se blokira;zahtev i oslobađanje resursa su sistemski pozivi• sistem vodi evidenciju o zauzetim i slobodnim resursima,kao i redovima procesa koji čekaju na resurse (blokirani)19/285

Mrtvo blokiranje - RešavanjeNeophodni uslovi za nastanak mrtvog blokiranja:• Međusobno isključenje (mutual exclusion): bar jedan resurs morabiti nedeljiv – samo ga jedan proces može koristiti u jednomtrenutku• Držanje i čekanje (hold and wait): mora postojati proces koji držibar jedan resurs i istovremeno čeka na neki drugi• Nema preotimanja (no preemption): resursi se ne mogu preotimati;resurs može dobrovoljno osloboditi samo proces koji ga je zauzeo• Kružno čekanje (circular wait): mora postojati cikličan lanacprocesa tako da svaki proces u lancu drži resurs koga traži naredniproces u lancuMrtvo blokiranje može nastati samo ako su sva četiri uslovaispunjena!20/285

Mrtvo blokiranje - RešavanjeGraf zauzetosti resursa (resource-allocation graph):usmereni graf čiji su čvorovi aktivni procesi i tipovi resursa,a grane označavaju sledeće:• P i → R j : proces P i traži instancu tipa resursa R j i čeka na slobodnu• R j → P i : proces P i drži zauzetu instancu tipa resursa R j (granazapravo izlazi iz instance tipa resursa R j )Održavanje grafa:R 1R 3• kada P i traži resurs tipa R , j uvodise grana P i → R j• kada P i zauzme resurs tipa R , jbriše se grana P i → R j i uvodigrana R j → P i• kada P i oslobodi resurs tipa R , jbriše se grana R j → P iP 1P 2P 3R 2R 421/285

Mrtvo blokiranje - RešavanjeP 2RR 1R 13PP 1P 2P 13P 3R 2R 2R 4Ako graf ne sadrži petlju, onda sigurno nema mrtve blokadeAko graf sadrži petlju, onda možda postoji mrtva blokada:• Ako petlja uključuje samo resurse sa po jednom instancom, ondasigurno postoji mrtva blokada• Ako petlja uključuje i resurse sa više instanci, mrtva blokada može,ali ne mora da postojiP 422/285

Mrtvo blokiranje - RešavanjeNačini za rešavanje problema mrrtvog blokiranja:• sprečavanje (deadlock prevention): unapred obezbediti da barjedan od 4 neophodna uslova za nastanak ne važe• izbegavanje (deadlock avoidance): tokom izvršavanja izbegavatisituacije koje mogu da dovedu do nastanka mrtvog blokiranja• detekcija i oporavak (deadlock detection and recovery): tokomizvršavanja ne sprečavati niti izbegavati mrtvo blokiranje, većdetektovati slučaj kada ono nastane i oporaviti sistem iz te situacije• ignorisanje (ignoration): jednostavno ignorisati nastanak mrtvogblokiranja: većina današnjih sistema primenjuje ovo – mrtveblokade se retko dešavaju, pa je jednostavnije i jeftinije manuelnorešiti problem (gašenjem procesa ili celog sistema) nego ugrađivatisložene mehanizme za rešavanje23/285

Mrtvo blokiranje - SprečavanjeSprečavanje mrtvog blokiranja – unapred ukinuti jedanod neophodnih uslova:• međusobno isključenje: ako je resurs deljiv (ne zahtevameđusobno isključenje), sigurno ne može nastati mrtvoblokiranje; primer: fajl ili drugi resurs koji se samo čita (readonly)dozvoljava konkurentan pristup; za nedeljive resurseovo nije izvodljivo• držanje i čekanje: obezbediti da kad proces zahteva resurs,nijedan drugi već ne drži; protokoli:• proces traži sve resurse koje koristi odjednom, npr. na početku svogizvršavanja• kada traži resurs, proces ili ne drži druge resurse, ili ih pritomosloboađaproblemi: slabo iskorišćenje (dugo zadržavanje resursa) i izgladnjivanje24/285

Mrtvo blokiranje - Sprečavanje• preotimanje; protokoli:• kada proces traži resurs koji je zauzet, svi resursi koje već drži seoslobađaju i dodaju na spisak onih koje traži• ako proces traži resurs koji je zauzet, i ako taj resurs drži proces kojičeka neki drugi resurs, resurs se preotima i dodeljuje procesu koji gatražiprimenjivo samo na resurse čije se stanje može lako sačuvati i povratiti(CPU, OM)• kružno čekanje: uspostaviti totalno uređenje između (tipova)resursa i nametnuti da svaki proces zahteva resurse samo urastućem poretku:• svakom tipu resursa dodeliti funkciju F(R), npr. prirodan broj• ako proces već drži zauzet resurs R i , proces može da zahteva resursR j samo ako je F(R j ) > F(R i ), za svako koje R i drži; inače, mora daoslobodi druge resurse R i za koje je F(R j ) ≤ F(R i )Dokazati da tada ne može da nastane kružno čekanje! (Uputstvo: dokazkontradikcijom)25/285

Mrtvo blokiranje - IzbegavanjeTehnike izbegavanja zahtevaju da sistem unapred zna nakoji način će proces zahtevati resurse tokom izvršavanjaKada proces traži resurs, sistem analizira informacije ozauzeću resursa i potrebama za resursima i zaključuje da lipostoji mogućnost da u budućnosti uđe u mrtvu blokadu;ako zaključi da postoji, ne dozvoljava procesu zauzećeresursa čak i ako je resurs slobodan, pre nego što jeblokada nastala, izbegavajući mrtvu blokaduProces unapred deklariše maksimalni broj instanci resursasvakog tipa koje će potencijalno koristiti tokom izvršavanjaSistem prati stanje zauzeća resursa koje je definisanobrojem zauzetih i slobodnih resursa svakog tipa26/285

Mrtvo blokiranje - IzbegavanjeStanje je sigurno (safe state) ako sistem može da dodeliresurse svakom procesu (do maksimuma njegove potražnje)u nekom poretku, a da ipak izbegne mrtvu blokaduStanje je sigurno akko postoji sigurna sekvenca. Sekvencaprocesa P 1 , P 2 , ..., P n je sigurna za dato stanje alokacijeresursa, ako za svaki P i sistem može da zadovolji zahteve P iza resursima koje P i još može da postavi, uzimajući u obzirtrenutno slobodne resurse, kao i sve resurse koje su zauzeliprocesi P j , j < i; ako trenutno nema dovoljno slobodnihresursa, onda P i može da sačeka da se završe svi P j , j

Mrtvo blokiranje - IzbegavanjePrimer: ukupno postoji 12 identičnih resursadeadlockunsafeMaksimum potražnje Trenutno zauzimaP 0 10 5P 1 4 2P 2 9 2Sigurna sekvenca: P 1 , P 0 , P 2 ⇒ prikazano stanje je sigurnoAko P 2 sada zauzme još jedan resurs, sistem prelazi u nesigurno stanje imoguća je mrtva blokadaAko je stanje sigurno, onda ne postoji mrtva blokadaStanje mrtve blokade je nesigurno stanjeAko je sistem u nesigurnom stanju, može (ali ne mora)nastati mrtva blokadaIdeja: ne dozvoliti alokaciju resursa ako ona vodi sistem unesigurno stanje, čak i ako ima slobodnih resursa – stalnodržati sistem u sigurnom stanjusafe28/285

Mrtvo blokiranje - IzbegavanjeAlgoritam zasnovan na grafu alokacije:• primenjiv samo za slučajeve sa po jednom instancomsvakog tipa resursa• pored grana zauzetosti i potražnje resursa, uvode se igrane najave tražnje: P i → R j znači da proces P i možetražiti instancu tipa resursa R j u nekom trenutku ubudućnosti• kada proces P i zatraži instancu tipa resursa R j , grananajave pretvara se u granu potražnje• kada proces P i oslobodi instancu tipa resursa R j , granazauzeća pretvara se u granu najave• sve grane najave moraju biti inicijalno unesene u grafprilikom pokretanja procesa; relaksiranije: kada procestraži prvi resurs, mora prethodno definisati sve svojegrane najave29/285

Mrtvo blokiranje - Izbegavanje• kada proces P i zatraži instancu tipa resursa R j , resursmu se dodeljuje samo ako novonastala grana zauzeća R j→ P i ne bi forumirala petlju u grafu – zadržava sistem usigurnom stanju; inače, proces mora da čeka na resursR 1P 2 traži R 1 ?R1P 2 traži R 2 ?R 1P 1P 2P 1P 2P 1P 2R 2Sigurno stanjeR 2Sigurno stanjeR 2Nesigurno stanje30/285

Mrtvo blokiranje - IzbegavanjeBankarev algoritam:• primenjiv na slučajeve tipova resursa sa više instanci• manje efikasan nego algoritam zasnovan na grafu• naziv dobio po tome što pokazuje kako banka da alocirasvoj raspoloživi keš tako da uvek može da ispunipotrebe svih svojih klijenata• osnovna ideja: kada proces traži nove resurse,algoritam proverava da li bi njihova alokacija, čak i akosu slobodni, zadržala sistem u sigurnom stanju,ispitujući da li postoji sigurna sekvenca; ako ne bi,resursi se ne alociraju, već proces mora da čeka31/285

Mrtvo blokiranje - IzbegavanjeBankarev algoritam - primer:Allocation Max AvailableA B C A B C A B CP 0 0 1 0 7 5 3 3 3 2P 1 2 0 0 3 2 2P 2 3 0 2 9 0 2P 3 2 1 1 2 2 2P 4 0 0 2 4 3 3Da li je ovo stanje sigurno? Pronaći sigurnu sekvencu!Postupak: pronaći proces koji sa raspoloživim slobodnim resursima može dazadovolji svoj maksimum tražnje, završi svoj posao i oslobodi sve resursekoje drži; zatim pronaći sledeći takav itd.Need i := Max i – Allocation iUslov: Need i ≤ AvailableAvailable := Available + Allocation i32/285

Mrtvo blokiranje - IzbegavanjeBankarev algoritam – primer (nastavak):Allocation Max AvailableA B C A B C A B CP 0 0 1 0 7 5 3 3 3 2P 1 2 0 0 3 2 2P 2 3 0 2 9 0 2P 3 2 1 1 2 2 2P 4 0 0 2 4 3 3Sigurna sekvenca: P 1 ,33/285

Mrtvo blokiranje - IzbegavanjeBankarev algoritam – primer (nastavak):Allocation Max AvailableA B C A B C A B CP 0 0 1 0 7 5 3 5 3 2P 1 2 0 0 3 2 2P 2 3 0 2 9 0 2P 3 2 1 1 2 2 2P 4 0 0 2 4 3 3Sigurna sekvenca: P 1 , P 3 ,34/285

Mrtvo blokiranje - IzbegavanjeBankarev algoritam – primer (nastavak):Allocation Max AvailableA B C A B C A B CP 0 0 1 0 7 5 3 7 4 3P 1 2 0 0 3 2 2P 2 3 0 2 9 0 2P 3 2 1 1 2 2 2P 4 0 0 2 4 3 3Sigurna sekvenca: P 1 , P 3 , P 4 ,35/285

Mrtvo blokiranje - IzbegavanjeBankarev algoritam – primer (nastavak):Allocation Max AvailableA B C A B C A B CP 0 0 1 0 7 5 3 7 4 5P 1 2 0 0 3 2 2P 2 3 0 2 9 0 2P 3 2 1 1 2 2 2P 4 0 0 2 4 3 3Sigurna sekvenca: P 1 , P 3 , P 4 , P 2 ,36/285

Mrtvo blokiranje - IzbegavanjeBankarev algoritam – primer (nastavak):Allocation Max AvailableA B C A B C A B CP 0 0 1 0 7 5 3 10 4 7P 1 2 0 0 3 2 2P 2 3 0 2 9 0 2P 3 2 1 1 2 2 2P 4 0 0 2 4 3 3Sigurna sekvenca: P 1 , P 3 , P 4 , P 2 , P 0Allocation Max AvailableA B C A B C A B CP 00 1 0 7 5 3 10 5 7P 12 0 0 3 2 2P 23 0 2 9 0 2P 32 1 1 2 2 2P 40 0 2 4 3 337/285

Mrtvo blokiranje - IzbegavanjeBankarev algoritam – primer (nastavak):Allocation Max AvailableA B C A B C A B CP 0 0 1 0 7 5 3 3 3 2P 1 2 0 0 3 2 2P 2 3 0 2 9 0 2P 3 2 1 1 2 2 2P 4 0 0 2 4 3 3Šta ako u ovom (sigurnom) stanju P 1 traži resurse Request 1 = (1, 0, 2)?Postupak: Ispitati uslov Request 1 ≤ AvailableZatim pretpostaviti da mu se ovi resursi dodele:Available := Available – Request 1Allocation 1 := Allocation 1 + Request 1Ispitati da li je dobijeno stanje sigurno; ako jeste, dozvoliti alokaciju;ako nije, blokirati proces38/285

Mrtvo blokiranje - IzbegavanjeBankarev algoritam – primer (nastavak):Allocation Max AvailableA B C A B C A B CP 0 0 1 0 7 5 3 2 3 0P 1 3 0 2 3 2 2P 2 3 0 2 9 0 2P 3 2 1 1 2 2 2P 4 0 0 2 4 3 3Sigurna sekvenca: P 1 , P 3 , P 4 , P 0 , P 2 , stanje je sigurno, dozvoliti alokacijuŠta ako sada P 0 traži (0, 2, 0)?Dobijeno stanje bi bilo nesigurno, ne dozvoliti alokaciju!Zadatak: Precizno formulisati bankarev algoritam i implementirati ga!39/285

Mrtvo blokiranje – Detekcija i oporavakIdeja: ako se mrtvo blokiranje ne sprečava i ne izbegava,onda se može dogoditi; upotrebiti algoritme koji:• detektuju da je došlo do mrtve blokade• vrše oporavak iz ovog stanjaOvakav pristup ima svoju cenu:• potrebno je tokom izvršavanja trošiti vreme na režije: održavanjepotrebnih struktura podataka i izvršavanje algoritma detekcije• oporavak po pravilu dovodi do gubitkaAlgoritmi detekcije mrtve blokade:• zasnovan na grafu alokacije (samo za tipove resursa sa po jednominstancom)• zasnovan na varijaciji bankarevog algoritma (za tipove resursa saviše instanci)40/285

Mrtvo blokiranje – Detekcija i oporavakAlgoritam detekcije zasnovan na grafu alokacije:• upotrebljiv samo za tipove resursa sa po jednom instancom• graf alokacije se može pojednostaviti pretvaranjem u graf čiji sučvorovi samo procesi, a grane predstavljaju relaciju “čeka na”: graneP i → R q i R q → P j stapaju se u jednu granu P i → P j• mrtva blokada postoji ako i samo ako u ovom grafu postoji petlja• kompleksnost algoritma detekcije petlje je O(n 2 ), gde je n broj granaR 1R 3R 4P 1P 2P 3R 5P 4P 1P 2P 3P 441/285

Mrtvo blokiranje – Detekcija i oporavakAlgoritam za više instanci istog tipa resursa (varijacijabankarevog algoritma):• na isti način kao i bankarev algoritam, traži sigurnu sekvencu, takošto fiktivno “završava” jedan po jedan proces koji može da dobijeresurse koje traži, a koji su slobodni• varijacija onog dela bankarevog algoritma koji proverava da li jestanje sigurno (tj. traži sigurnu sekvencu): umesto da se proveravauslov Need i ≤ Available, već uslov Request i ≤ Available• ako takvu sekvencu nađe, mrtva blokada ne postoji• ako takvu sekvencu ne nađe, mrtva blokada postoji, i ona uključujeproces P i za koji ovaj uslov nije bio ispunjen• kompleksnost O(m × n 2 ), m – broj tipova resursa, n – broj procesa42/285

Mrtvo blokiranje – Detekcija i oporavakKada pozivati algoritam detekcije mrtve blokade? Odgovorzavisi od toga:• koliko često nastaje mrtva blokada: ako nastaje često, i detekcijutreba vršiti često• koliko procesa je ugroženo mrtvom blokadom: što duže traje mrtvablokada, sve više procesa može biti ugroženoJedna krajnost: vršiti detekciju prilikom svakog zahteva zaresursom koji ne može biti dodeljen – veoma veliki režijskitroškoviMnogo jeftinije rešenje: detekciju vršiti ređe, npr. kadaiskorišćenje procesora padne ispod neke granice (mrtvablokada utiče na to da je sve manje procesa aktivno, paiskorišćenje procesora vremenom pada)43/285

Mrtvo blokiranje – Detekcija i oporavakOporavak od mrtve blokade:• obavestiti operatera koji treba manuelno da reši problem (gašenjemspornih procesa)• automatski izvršiti oporavakAutomatski oporavak od mrtve blokade:• ugasiti jedan ili više procesa:• ugasiti sve procese koji učestvuju u blokadi• gasiti jedan po jedan proces, sve dok se blokada ne raskine• izvršiti preotimanje resursa dok se ne raskine blokadaNasilno gašenje procesa nije jednostavno: šta ako je procesu sred pisanja u fajl ili slično?Preotimanje resursa nije jednostavno: šta raditi sa procesomkome je resurs preotet, kako izbeći izgladnjivanje, ...Izbor “žrtve” - procesa za gašenje ili resursa za preotimanje –je prvenstveno ekonomsko pitanje (postići minimalnu cenu/štetu od oporavka)44/285