Lukkiutuminen. Taustaa Aterioivat Filosofit Ennaltaehkäisy Havaitseminen Välttely. Andrews 4.3 Stallings (tai mikä tahansa KJ-kirja)

Samankaltaiset tiedostot
Lukkiutuminen. Taustaa

4-13. Ratkaisu 4: OK, mutta... vrt. 2. Ratkaisu 3: OK. Ratkaisu 5: OK? Nälkiintyminen?

Taustaa. Lukkiutuminen. Seuraukset. Määritelmiä Lukkiuma (deadlock) päättymätön odotus BLOCKED-tilassa. prosessi P. prosessi Q. pyydä A? OK.

Ongelmakenttä. Yhteenvetoa. Mekanismit. Ratkottava. Lukkomuuttujat, Spin Locks. Lukkomuuttujat. Rinnakkaisohjelmistot 2004 / Auvo Häkkinen 9-1

Käyttöjärjestelmät: poissulkeminen ja synkronointi

OSA I: Yhteisten muuttujien käyttö Prosessit samassa koneessa. Sisältöä. Poissulkeminen. Halutut ominaisuudet 2-1. Rinnakkaiset, atomiset operaatiot

Semaforit Liisa Marttinen 2-1

alkuarvo P(S) public V(S) public jos kriittinen alue vapaa, lukitse se ja jatka eteenpäin jos kriittinen alue varattu, odota

OSA II: Hajautettu ympäristö. Sisältö, osa II. Ei yhteistä muistia. Sanomanvälitys. Etäproseduurikutsu. Rendezvous. Rio 2004 / Auvo Häkkinen

Monitorit. Monitori Synkronointimenetelmiä Esimerkkejä. Andrews , Stallings 5.5

Monitorit. Tavoite. Monitori Synkronointimenetelmiä Esimerkkejä. Andrews , Stallings 5.5. Minimoi virhemahdollisuuksia

OSA I: Sisältöä. Atomisuus (atomic action) v Poissulkeminen ja synkronointi. Kriittinen (koodi)alue (critical section)

OSA I: Yhteisten muuttujien käyttö. Prosessit samassa koneessa. Rio 2004 / Auvo Häkkinen 2-1

OSA I: Yhteisten muuttujien käyttö. Sisältöä. Prosessit samassa koneessa. Poissulkeminen ja synkronointi. Semaforit ja rinnakkaisuuden hallinta

5. Luento: Rinnakkaisuus ja reaaliaika. Tommi Mikkonen,

Ongelmakenttä. Rinnakkaisuuden tarve. Kommunikointiin tarvitaan. Ympäristö Suunnittelun yksinkertaistaminen Suorituskyky Luotettavuus

Semaforit. Semaforit. semafori S S.arvo. alkuarvo P(S) S.joukko V(S)

Ongelmakenttä. Yhteenvetoa. Ratkottava. Mekanismit. Lukkomuuttujat. Lukkomuuttujat, Spin Locks. Rinnakkaisuuden tarve. Kommunikointiin tarvitaan

Yhteenvetoa. Ongelmakenttä

Semaforit ja rinnakkaisuuden hallinta. Tuottajat ja kuluttajat. Lukijat ja kirjoittajat. Andrews 4.2, Rio 2004 / Auvo Häkkinen

Semaforit Javassa. Mari Kononow, Eveliina Mattila, Sindi Poikolainen HELSINGIN YLIOPISTO

Syitä siirtoon. Hajautettu prosessien hallinta. Stallings, Luku 15. Sisältöä luento 20. Kuka/mikä päättää siirrosta? Esimerkki.

Hajautettu prosessien hallinta. Stallings, Luku 15. Sisältöä luento 20

Semaforit ja rinnakkaisuuden hallinta

Semaforit ja rinnakkaisuuden hallinta

Liite 1. Projektin tulokset (Semaforit Javassa) Jukka Hyvärinen Aleksanteri Aaltonen

Sisältöä luento 20. Hajautettu prosessien hallinta. Stallings, Luku 15. Prosessin siirto. Syitä siirtoon. Esimerkki. Kuka/mikä päättää siirrosta?

Transaktiot - kertausta

OSA II: Hajautettu ympäristö. Ei yhteistä muistia. Rio 2004 / Auvo Häkkinen

OSA II: Hajautettu ympäristö. Sisältö, osa II. Sanomanvälitys. Käsitteistöä. Sanomanvälitys. Kommunikointi. Sanomanvälitys. Etäproseduurikutsu

Stabilointi. Marja Hassinen. p.1/48

Javan semaforit. Joel Rybicki, Aleksi Nur mi, Jara Uitto. Helsingin yliopisto

Itsestabilointi: perusmääritelmiä ja klassisia tuloksia

Rinnakkaisohjelmistot. Liisa Marttinen Tietojenkäsittelytieteen laitos Helsingin yliopisto Kevät 2004

Rinnakkaisohjelmointi, Syksy 2006

Etäproseduurikutsu, Remote Procedure Call (RPC) Etäproseduurikutsu. Poissulkeminen moduulin sisällä?

Etäproseduurikutsu. Etäproseduurikutsu, Remote Procedure Call (RPC)

Etäproseduurikutsu. RPC Toteutus Virhesemantiikka. Andrews 8.1, 10.3, Stallings 13.3

R 2 [0] ei ole likainen luku, sillä avaimelle 0 on jo palautettu sen alkuperäinen arvo.

Tavoite. Monitorit. Monitori Hoare Monitori. Minimoi virhemahdollisuuksia. Monitori Synkronointimenetelmiä Esimerkkejä

Jaana Diakite Projekti 1 JAVA-Monitorit 1(13) Rinnakkaisohjelmointi Anu Uusitalo

Ohjelmoinnin peruskurssien laaja oppimäärä

Ongelma(t): Miten tietokoneen käyttöjärjestelmä toimii sisäisesti, jotta resurssit saadaan tehokkaaseen käyttöön?

4. Luento: Prosessit ja säikeets. Tommi Mikkonen,

Seminaari: Keskusmuistitietokannat. Keskusmuistitietokantojen samanaikaisuuden hallinta Ilkka Pullinen

Tietojenkäsittelyn perusteet 2. Lisää käyttöjärjestelmistä

Algoritmit 2. Luento 13 Ti Timo Männikkö

Etäproseduurikutsu, Remote Procedure Call (RPC) Etäproseduurikutsu. Poissulkeminen moduulin sisällä?

11. Javan toistorakenteet 11.1

Sisällys. 11. Javan toistorakenteet. Laskurimuuttujat. Yleistä

käyttötapaukset mod. testaus

Ohjelmoinnin peruskurssien laaja oppimäärä

Algoritmit 2. Luento 10 To Timo Männikkö

Semaforit ja rinnakkaisuuden hallinta. Tuottajat ja kuluttajat. Halkaistu binäärisemafori (Split binary semaphore) semaforit empty ja full

Rinnakkaisohjelmointi

Rinnakkaisohjelmointi

Rinnakkaisohjelmointi

Algoritmit 2. Luento 10 To Timo Männikkö

2 Konekieli, aliohjelmat, keskeytykset

Osio 3: Prosessit, siirräntä ja tiedostojärjestelmä

» multiaccess channel» random access channel LAN (Ethernet) langaton. ongelma: käyttövuoron jakelu Yhteiskäyttöisen kanavan käyttö

4. MAC-alikerros. yleislähetys (broadcast) ongelma: käyttövuoron jakelu. » multiaccess channel» random access channel LAN (Ethernet) langaton

Samanaikaisuuden hallinta

Tietokoneen toiminta (Computer Organization I)

Algoritmit 2. Luento 9 Ti Timo Männikkö

Algoritmit 1. Demot Timo Männikkö

Palvelut. Sulautetut järjestelmät Luku 2 Sivu 1 (??) Sulautetut käyttöjärjestelmät

Tietokoneen toiminta (Computer Organization I)

Ohjelmoinnin perusteet Y Python

5. Luento: Rinnakkaisuus ja jako prosesseihin (+ lyhyesti reaaliajasta) Arto Salminen,

u vapaakäyntisyys (reentrancy) u Yhteinen koodialue u kullakin oma data-alue, pino, PCB u osoitteet suhteellisia prosessin alun suhteen

Luento 3: PROSESSIT JA NIIDEN HALLINTA

Sisältöä PROSESSIT JA NIIDEN HALLINTA. Prosessi. Prosessi virtuaalimuistissa. Prosessi. Prosessi virtuaalimuistissa. Käyttöjärjestelmät

Prosessi virtuaalimuistissa PROSESSIT JA NIIDEN HALLINTA. Sisältöä. Prosessi virtuaalimuistissa. Prosessi. Prosessi. Käyttöjärjestelmät, Luento 4

PROSESSIT JA NIIDEN HALLINTA

Käyttöjärjestelmät: prosessit

Tietokoneen toiminta (Computer Organization I)

Algoritmit 2. Luento 11 Ti Timo Männikkö

HAAGA-HELIA Heti-09 1 (14) ICT05: Tiedonhallinta ja Tietokannnat O.Virkki Transaktionkäsittely

815338A Ohjelmointikielten periaatteet

(p j b (i, j) + p i b (j, i)) (p j b (i, j) + p i (1 b (i, j)) p i. tähän. Palaamme sanakirjaongelmaan vielä tasoitetun analyysin yhteydessä.

12. Javan toistorakenteet 12.1

Hajautettu ympäristö Ei yhteistä muistia Kommunikointi sanomien välityksellä

Hajautettu ympäristö Ei yhteistä muistia Kommunikointi sanomien välityksellä

Aikuisvalmennuksen paikkausjärjestelmän käyttöohje

Käyttöjärjestelmät II

Stabiloivat synkronoijat ja nimeäminen

12. Javan toistorakenteet 12.1

Tietokoneen toiminta (Computer Organization I)

Prosessi perinteisesti

Algoritmit 1. Luento 4 Ke Timo Männikkö

Stallings, Luku 4.1. KJ-I I S2005 / Tiina Niklander, kalvot Auvo HäkkinenH

Rinnakkaisuus. parallel tietokoneissa rinnakkaisia laskentayksiköitä concurrent asioita tapahtuu yhtaikaa. TTY Ohjelmistotekniikka

Yleiskuva. Käyttöjärjestelmät II. Tietokonejärjestelm. rjestelmä. KJ ja laitteistopiirteet. KJ ja laitteistopiirteitä.

Käyttöjärjestelmät II

Algoritmit 2. Luento 4 To Timo Männikkö

Oppimistavoitteet kurssilla Rinnakkaisohjelmointi

IT K 1 45 K ä yt t öj ä rj estelmät

Algoritmit 1. Luento 9 Ti Timo Männikkö

Johdantoa. Miksi rinnakkaisuutta? Laitteistoarkkitehtuureja. Rinnakkaisuus - Samanaikaisuus. Peräkkäisyyteen perustuvat sovellukset

Transkriptio:

Lukkiutuminen Taustaa Aterioivat Filosofit Ennaltaehkäisy Havaitseminen Välttely Andrews 4.3 Stallings 6.1-6.6 (tai mikä tahansa KJ-kirja)

prosessi P pyydä A? OK. pyydä B? Odota! Taustaa yksityiskäyttöiset objektit A B C prosessi Q pyydä B? OK. pyydä A? Odota! objekti: puskuri, sivu, skanneri, levyajuri, kriittinen vaihe,... 4-2

Kriittinen vaihe Suoritusjärjestys, ajoitus Stallings Fig 6.1 4-3

Seuraukset Prosessit eivät etene ja... niiden varaamat resurssit pysyvät varattuina CPU muisti, I/O-laitteet loogiset resurssit (semaforit, kriittiset alueet,...) Laskenta epäonnistuu suoritus ei pääty koskaan järjestelmä kaatua köllähtää tilanne ei kenties toistettavissa: suoritusjärjestys 4-4

Määritelmiä Lukkiuma (deadlock) päättymätön odotus BLOCKED-tilassa Livelock prosessi käyttää prosessoria odottamiseen (spinlock, busy loop) Ping-pong sinä ensin eikun sinä ensin -... kaksi prosessia vuorottelevat tarjoten vuoro toiselle, eivätkä tee mitään hyödyllistä Nälkiintyminen (starvation) prosessi READY-tilassa - mutta ei silti saa koskaan prosessoria 4-5

Mahdollinen suorituspolku Suoritusjärjestys, ajoitus Stallings Fig 6.2 orig Bacon Fig 17.1 4-6

Mahdollinen suorituspolku Stallings Fig 6.3 orig Bacon Fig 17.2 4-7

Syitä lukkiutumiseen Kolme staattista toimintapoihin liittyvää syytä S1 Poissulkemistarve (mutual exclusion) resurssilla yksi käyttäjä kerrallaan S2 Pidä ja odota (hold and wait) prosessi pitää saamansa resurssin samalla, kun jää odottamaan lisäresursseja S3 Kenelläkään ei etuoikeutta (no pre-emption) resurssia ei voi ottaa pois väkisin Yksi dynaaminen syy D1 Odotus kehässä (circular wait) on olemassa kehä prosesseista, jotka pitävät itsellään resurssia, jota kehän seuraava prosessi tarvitsee edetäkseen 4-8

Aterioivat Filosofit 4-9

Aterioivat Filosofit (Dijkstra) 3 4 0 Filosofi: aattelepa ite ota kaksi haarukkaa... yksi kummaltakin puolelta syö, syö, syö spagettia palauta haarukat 2 1 Kuinka varata haarukat ilman - lukkiutumista - nälkiintymistä s.e. kaikki saavat olla paikalla? 4-10

Ratkaisu 1: kullekin haarukalle oma semafori sem fork[0..4] = (1, 1, 1, 1, 1) 3 process P[i]: 4 0 1 2 repeat think() P(fork[i]) P(fork[(i + 1) mod 5]) eat() V(fork[i]) V(fork[(i+1) mod 5]) until false Ei OK! Miksei? 4-11

Ratkaisu 2: vain yksi voi yrittää kerrallaan sem turn = 1 # säätelee yritysvuoroja 3 process P[i]: 4 0 1 2 repeat think() P(turn) P(fork[i]) P(fork[(i+1) mod 5]) V(turn) eat() V(fork[i]) V(fork[(i+1) mod 5]) until false Ei OK! Miksei? 4-12

Ratkaisu 3: OK Andrews Fig. 4.7 4-13

Ratkaisu 4: OK, mutta... vrt. 2 sem fork[5] = ([5] 1); sem room = 4; process Philosopfer[i=0 to 4] { while (true) { think(); P(room); P(fork[i]); P(fork[(i+1) mod 5]); eat(); V(fork[i]); V(fork[(i+1) mod 5]); V(room); } } Stallings Fig. 6.12 4-14

Ratkaisu 5: OK? Nälkiintyminen? Tanenbaum Fig. 2.33

Huom: down() = P(), up() = V() Tanenbaum Fig. 2.33

Ratkaisu 5: Tapettaisko filosofi 1? EATING HUNGRY 4 2 0 1 3 2 0 3 0 0 2 1 3 4 1 2 4 1 3 4 3 4 0 3 4 0 4 2 0 1 3 2 1 2 1 3 4 0 3 4 0 3 4 0 2 1 2 1 2 1 4-17

Ratkaisu 6: OK, ei yhteisiä resursseja Ostakaa 5 haarukkaa lisää! 4 3 2 1 0 Filosofi[i]: aatteleppa ite ota kaksi haarukkaa yksi molemmilta puolilta syö, syö, syö spagettia palauta haarukat 4-18

Lukkiuman ennaltaehkäisy Stallings 6.2 4-19

Ennaltaehkäisy = Poista joku syistä S1, S2, S3 tai D1 Ehkäise S1 (poissulkemistarve)? = käytä yhteiskäyttöisiä resursseja yksittäiskäyttöisten sijasta, spooling (= hanki enemmän resursseja) poissulkemistarpeelle omat syynsä, mutta hienojakoisempi toteutus sallii paremmin rinnakkaisuutta pienemmät alueet, yhtäaikainen käyttö, enemmän lukkoja yleistä esim. tietokantojen yhteydessä, lyhyet transaktiot 4-20

Ehkäise S2 (pidä ja odota)? = pyydä kaikki resurssit yhdellä kertaa = odota, että saat kaikki kerralla tehotonta pitkät odotusajat: varaa nyt - käytä paljon paljon myöhemmin varautuminen pahimpaan: varaa resursseja, joita ei ehkä tarvitakaan vaikea / mahdoton toteuttaa? tiedettävä etukäteen mitä resursseja tarvitaan kaikilla mahdollisilla suorituspoluilla 4-21

Ehkäise S3 (ei etuoikeuksia)? = jos varaaminen ei onnistu, vapauta jo varatut resurssit, peruuta edelliseen tilanteeseen kokeile alustavasti varausta, tai tarkistuspisteet manageri? OK, jos järjestelmä suunniteltu tämä mielessä käytännöllinen, jos tilatiedon talletus helppoa ja lukkiutumisriski aidosti olemassa normaalia käytäntöä transaktioiden käsittelyssä 4-22

Ehkäise D1 (odottaminen kehässä)? = numeroi resurssit lineaarisesti, varaa numerojärjestyksessä etukäteistietoa resurssitarpeesta, varauduttu pahimpaan tapaukseen pessimistinen TAI varaa sitä mukaa kun tarve (järjestyksessä), tarvittaessa palaa aiempaan tilaan optimistinen 4-23

Ratkaisu 5: Ehkäise S2 (pidä ja odota) = varaa kaksi haarukkaa yhtäaikaa process P[i]: repeat think( ) take_ forks(i, (i+1) mod 5) eat( ) put_forks( i, (i+1) mod 5) until false take & put: resurssin hallinta tehtävät: vuorojen antaminen lukkiutuman ehkäisy nälkiintymisen ehkäisy 4-24

Vaarallisten kohtien metsästys P(turn) P(fork[i]) P(fork[(i+1) mod 5]) V(turn) 1: eat() 2: P(turn) 4: this is not fair! 4 3 0 1: eat() 1: eat() 2 1 2: this is not fair! 3: eat() 3: eat() 4-25

Lukkiuman havaitseminen Stallings 6.4 4-26

Lukkiuman havaitseminen Havaitseminen vaikeaa muodostaako ryhmä prosesseja lukkiuman, vai odottavatko ne ulkoista tapahtumaa? Jotta voisi toipua, pystyttävä havaitsemaan toipuminen: peruutus edeltävään tilanteeseen tapa yksi tai useampi lukkiumaan kuuluva prosessi KJ tarvitsee tietoa resurssien allokoinnista sellaisessa muodossa, että voi havaita lukkiuman! tutki aika-ajoin onko lukkiumaa 4-27

Resurssien (objektien) allokointi Prosessit P i i=1..m Resurssit R j j=1..n yhteensä R = (R 1,..., R n ) vapaana V = (V 1,..., V n ) Allokointimatriisi A [P i,r j ] montako resurssia Rj allokoitu prosessille Pi Pyyntömatriisi Q [P i,r j ] montako resurssia Rj prosessi Pi pyytänyt 4-28

Esim.: Alkutilanne Prosessilla 2 on resurssit 1 ja 2, ja se haluaa resurssit 3 ja 5. Kenellä on resurssi 4? Mitkä resurssit ovat vapaana? Onko tässä lukkiuma vai ei? Stallings Fig. 6.9 4-29

DDA: Deadlock Detection Algorithm (Dijkstra) DDA [Poista prosessit, joille ei ole allokoitu resursseja] Merkitse käsitellyiksi kaikki tyhjät rivit matriisissa A. DDA2 [Alusta vapaiden resurssien laskurit] Alusta työvektori W = V DDA3 [Etsi prosessi, jonka maksimipyyntöön voi suostua] Etsi merkitsemätön rivi Pi siten, että Q[Pi,Rj] W[Rj] j = 1..n Jos ei löydy, algoritmi on päättynyt. DDA4. [Oleta, että prosessi suoritettu, ja vapauta varaukset] Aseta W = W+A[Pi] ts.. W[Rj] = W[Rj]+A[Pi,Rj] j = 1..n Merkitse rivi Pi käsitellyksi ja palaa askeleeseen DL3. Kun algoritmi päättyy, merkitsemättömät rivit osoittavat lukkiumaan kuuluvat prosessit. Miksi?

Esim.: Vaihe 1 allokointi matriisi A 1 0 1 1 0 1 1 0 0 0 0 0 0 1 0 0 0 0 0 0 DDA1 merkitse pyyntömatriisi Q 0 1 0 0 1 0 0 1 0 1 0 0 0 0 1 1 0 1 0 1 DDA3 merkitse, voi suostua: Q[3,5] W[5] kaikki R: 2 1 1 2 1 vapaat V: työvektori W: + DDA4 -> uusi W: 0 0 0 0 1 0 0 0 0 1 0 0 0 1 1 DDA2 kopioi 4-31

Esim.: Vaihe 2 allokointi matriisi A pyyntömatriisi Q 1 0 1 1 0 1 1 0 0 0 0 0 0 1 0 0 0 0 0 0 kaikki R: 0 1 0 0 1 0 0 1 0 1 0 0 0 0 1 1 0 1 0 1 2 1 1 2 1 DDA3 ei prosessia Pi s.e. Q[Pi,Rj] W[Rj] j. Algoritmi päättyy prosessit 1 ja 2 lukkiutuneet vapaat V: 0 0 0 0 1 Mitä sitten? työvektori W: 0 0 0 1 1 Bacon Fig. 17.9: Graphs 4-32

Lukkiuman välttely Stallings 6.3 4-33

Pankkiirin algoritmi Alkujaan yhdelle resurssille (raha) Miksi Pankkiirin? varmistettava, että pankki ei koskaan uloslainaa niin paljon, ettei se pysty tyydyttämään kaikkien talletusasiakkaiden maksimitarpeita (Huom: pankilla myös omaa pääomaa) Varmista ensin, allokoi vasta sitten 4-34

Pankkiirin algoritmi useille resursseille (Dijkstra) Kerää tilatietoa Prosesseille jo allokoiduista resursseista Resursseista, joita kukin prosessi voisi edelleen pyytää Varmista pyynnön vaikutus etukäteen Allokoi vasta, kun varma ettei johda lukkiumaan pahimmassakaan tapauksessa Tarkista, että löytyy ainakin yksi vuorottelujärjestys, jossa kaikki prosessit voivat suoriutua loppuun vaikka muut pyytäisivät maksimitarpeensa "worst case analysis" 4-35

Allokointi- ja pyyntömatriisit kuten edellä LISÄKSI Resurssien maksimipyyntö C[Pi,Rj] montako resurssia Rj prosessi Pi voisi maksimissaan pyytää prosessien kerrottava etukäteen! Mahdollinen uusi allokointimatriisi montako resurssia Rj prosessilla Pi olisi, jos sille annettaisiin sen maksimitarpeen mukaan A [Pi,Rj] Mahdollinen uusi pyyntömatriisi Q [Pi,Rj] montako resurssia Rj prosessi Pi voisi vielä tämän jälkeen pyytää Q = C - A Alkuperäisiä ei voi vielä muuttaa! 4-36

Mieti allokoinnin seurauksia etukäteen: Oleta, että allokointi tehdään Laske uusi mahdollinen allokointimatriisi A Laske uusi mahdollinen pyyntömatriisi Q pahimmassa tapauksessa, ts. tilanteessa jossa kaikki pyytävät oman maksimimääränsä Sovella lukkiuman havaitsemisalgoritmia DDA matriiseille A ja Q Jos ei johda lukkiumaan, suostu pyyntöön muuten älä suostu pyyntöön jätä prosessi odottamaan kun joku vapauttaa, tarkista uudelleen 4-37

P1 P2 P3 P4 Allokointimatriisi A R1 R2 R3 R4 R5 0 1 0 0 0 1 1 0 0 0 0 0 1 0 1 0 0 1 1 0 Pyyntömatriisi Q Maksimipyyntö C R1 R2 R3 R4 R5 R1 R2 R3 R4 R5 1 0 0 0 0 2 1 0 1 0 0 0 0 0 1 1 1 0 0 1 0 0 0 1 0 1 0 1 1 1 0 0 0 0 1 0 2 1 1 1 Resurssivektori R 2 3 2 1 2 R1 R2 R3 R4 R5 Vapaana V 1 1 0 0 1 Voiko P1:n pyyntöön suostua? Voisiko lukkiutua? 4-38

Jos P1:n pyyntöön suostuttaisiin niin P1 P2 P3 P4 Allokointimatriisi A' R1 R2 R3 R4 R5 1 1 0 0 0 1 1 0 0 0 0 0 1 0 1 0 0 1 1 0 Pyyntömatriisi Q' Maksimipyyntö C R1 R2 R3 R4 R5 R1 R2 R3 R4 R5 1 0 0 1 0 2 1 0 1 0 0 0 0 0 1 1 1 0 0 1 1 0 0 1 0 1 0 1 1 1 0 2 0 0 1 0 2 1 1 1 Resurssivektori R 2 3 2 1 2 R1 R2 R3 R4 R5 Vapaana V 1 1 0 0 1 R1 R2 R3 R4 R5 Vapaana V' 0 1 0 0 1 4-39

R1 R2 R3 R4 R5 Työvektori W 0 1 0 0 1 Työvektori W 1 2 0 0 1 DDA4 merkkaa rivi 2 Työvektori W 1 2 1 1 1 DDA4 merkkaa rivi 4 Työvektori W 2 3 1 1 1 DDA4 merkkaa rivi 1 Työvektori W 2 3 2 1 2 DDA4 merkkaa rivi 3 Voi suostua! Mitä, jos ei voi? 4-40

Ongelmia Yleisrasite tutki jokaisella pyynnöllä... 20 prosessia ja 100 resurssia? Prosessin tiedettävä maksimitarve etukäteen viksu arvaus? pahin tapaus? dynaamisesti vieläkin rasittavampaa Aina ei löydy varmaa allokointijärjestystä ei-turvallinen tila ei aina johda lukkiumaa voiko ottaa riskin! 4-41

Kertauskysymyksiä? 4-42