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

Transkriptio

1 Semaforit Semaforit public public alkuarvo P(S) V(S) private private semafori S S.arvo S.joukko - P() aka WAIT() aka Down() jos kriittinen alue vapaa, lukitse se ja jatka eteenpäin jos kriittinen alue varattu, odota V() aka SIGNAL() aka Up() jos joku odottamassa, päästä joku odottajista etenemään, Jos odottajajoukko on tyhjä, vapauta kriittinen alue P ja V atomisia: samanaikaisesti vain yksi prosessi voi suorittaa niitä - Yleistä semaforeista Alkuperäinen idea: Dijkstra (6-luvun puoliväli) binäärisemaforit: vain arvot ja käytössä Operaatiot Alustus sem S=; sem forks[5] = ([5] ); P(S) (= passeren) V(S) (= vrijgeven) S.arvo vapaa / avoinna / etenemislupa varattu / suljettu / eteneminen kielletty S.joukko Etenemislupaa Blocked (Wait) -tilassa odottavat prosessit Toteutus: esim. PCB:t linkitetyssä listassa (=> jono) Yleiset semaforit: S.arvo ~ resurssilaskuri S.arvo > vapaiden yksiköiden lkm, etenemislupien määrä kuinka monta prosessia voi tehdä P()-operaation joutumatta Blocked tilaan ja semaforin jonoon S.arvo = ei vapaita [ jotkut toteutukset: S.arvo < ] jonossa odottavien prosessien lkm Ei operaatiota jonon käsittelyyn / pituuden kyselyyn! semaforin arvon kyselemiseen! jos tarve tietää, ylläpidä ko. tieto omassa muuttujassa - - P/V:n toteutus KJ:n ytimessä (Andrews Fig 6.5) P(S) V(S) if (S.arvo > ) S.arvo = S.arvo - else aseta prosessin tilaksi Blocked, lisää prosessi jonoon S.jono call Vuorottaja() if (isempty(s.jono)) S.arvo = S.arvo + else siirrä S.jonon ensimmäinen prosessi Ready-jonoon (tilaksi Ready) call Vuorottaja() -5 P/V:n toteutus (toinen tapa, Stallings Fig. 5.6 ja 5.7) P(S) V(S) S.arvo = S.arvo - if (S.arvo < ) aseta prosessin tilaksi Blocked, lisää prosessi jonoon S.jono call Vuorottaja() S.arvo = S.arvo + if (S.arvo >= ) siirrä S.jonon ensimmäinen prosessi Ready-jonoon call Vuorottaja() Miten ohjelmoijan huomioitava tämä toteutusero? -6

2 Poissulkeminen semaforia käyttäen sem mutex=; # vain perinteinen muuttujan nimi P(lock) process CS [i= to N] { # rinnakkaisuus! while (true){ ei kriittistä koodia; # varaa < critical section > # käytä (exclusive!) # vapauta V(lock) P(lock) P(lock) ei kriittistä koodia; V(lock) yksi semafori kullekin erilliselle kriittiselle alueelle huomaa oikea alkuarvo V(lock) -7-8 Esimerkki: Muistinhallinta () prosessi GET... REL GET... REL --- prosessi c c --- GET... REL --- koodi GET REL Muistinhallinta pagepool count addr pagepool[:max]; int count=max; addr function GET() { addr memaddr; memaddr = pagepool[count]; count = count-; return memaddr ; procedure REL(addr freepage) { count = count+; pagepool[count] = freepage; # vapaita muistitiloja ; käyttö pinona pagepool,7,,8,5,6,,9,.. count koodi -9 - Toimiikos tuo? addr pagepool[:max]; int count=max; framepool pagepool,7,,8,5,6,,9,.. 6 count addr function GET: addr function GET: { get memaddr = pagepool[count]; = { get memaddr = pagepool[count]; = pagepool[count]; pagepool[count]; count = count- count = count- GET==6 GET==6 Muistinhallinta (): poissulkeminen addr pagepool[:max]; int count=max; sem mutex=; addr function GET() { addr memaddr; memaddr = pagepool[count]; count = count-; return memaddr; procedure REL(addr freepage) { count = count+; pagepool[count] = freepage; pagepool,7,,8,5,6,,9,.. count mutex: - -

3 Ehtosynkronointi Synkronointi semaforia käyttäen Prosessi P käskyjä kerro tapahtumasta käskyjä Tapahtuma: mikä tahansa kiinnostava puskuri_täynnä, io_valmis, laskenta valmis, kriittinen alue vapaa (Looginen) tapahtuma Prosessi P käskyjä odota tapahtumaa käskyjä... semaforimuuttuja Kumpi ehtii ensin synkronointikohtaan? tarvitsee paikan missä odottaa (~jonottaa) sem A_Ready = ; ei ole tapahtunut, on tapahtunut Tuottaja tuota A V(A_ready); Kumpi ehtii ensin? Oikea alkuarvo? Kuluttaja P(A_ready); kuluta A - - Muistinhallinta (): ehtosynkronointi addr pagepool[:max]; int count=max; sem mutex=, avail=max; addr function GET() { addr memaddr; P(avail); memaddr = pagepool[count]; count = count- return memaddr; procedure REL(addr freepage) { count = count+; pagepool[count] = freepage; V(avail); pagepool,7,,8,5,6,,9,.. count mutex avail 6-5 aika Puomisynkronointi (barrier) n prosessia työskentelee yhdessä Iteratiivinen käsittely, synkronointi tietyn välivaiheen jälkeen Prosessi A synkronoi Prosessi B synkronoi Prosessi C synkronoi I II - 6 aika Worker[] synkronoi odota process Worker [i = to N] { while ( ) { käsittele vaihe x:n alku ; toimita synkronointitieto kaikille muille; odota synkronoititietoa kaikilta muilta; käsittele vaihe x:n loppu; Worker[] synkronoi odota odota Worker[] synkronoi - 7 Puomisynkronointi sem arrive =, arrive = ; process Worker { käsittele alkuosa V(arrive); # lähetä synkronointitapahtuma P(arrive); # odota toista prosessia käsittele loppuosa process Worker { käsittele alkuosa V(arrive); # lähetä synkronointitapahtuma P(arrive); # odota toista prosessia käsittele loppuosa Huomaa järjestys! Entä, jos ensin P ja sitten V? - 8

4 Väärin toteutettu puomisynkronointi! Entä toimiiko näin? Onko mitään haittaa? sem arrive =, arrive = ; sem arrive =, arrive = ; process Worker { käsittele alkuosa P(arrive); # odota toista prosessia V(arrive); # lähetä synkronointitapahtuma käsittele loppuosa process Worker { käsittele alkuosa P(arrive); # odota toista prosessia V(arrive); # lähetä synkronointitapahtuma käsittele loppuosa process Worker { käsittele alkuosa P(arrive); # odota toista prosessia V(arrive); # lähetä synkronointitapahtuma käsittele loppuosa Johtaa lukkiutumiseen: kumpikin vain odottaa toista!! - 9 process Worker { käsittele alkuosa V(arrive); # lähetä synkronointitapahtuma P(arrive); # odota toista prosessia käsittele loppuosa - Puomisynkronointi, yleiset semaforit Virheellinen puomisynkronointi! Miksi näin? sem arrive=, continue[:n] = ( [N] ); process Worker [i= to N] { käsittele alkuosa i V(arrive); # synkronointitapahtuma koordinaattorille P(continue[i]); # odota toisia prosesseja käsittele loppuosa i process Coordinator { count = ; while (count < N) { # odota, kunnes N synkronointitapahtumaa P(arrive); count++; for [i = to N] V(continue[i]); # synkronointitapahtuma prosesseille Entä jos vain yksi continue-semafori? - sem arrive=, continue= ; process Worker [i= to N] { käsittele alkuosa i V(arrive); # synkronointitapahtuma koordinaattorille P(continue); # odota toisia prosesseja käsittele loppuosa i process Coordinator { count = ; while (count < N) { # odota, kunnes N synkronointitapahtumaa P(arrive); count++; for [i = to N] V(continue); # synkronointitapahtuma prosesseille - Kilpailutilanne V(arrive); P(continue); Mitä tässä voi tapahtua? V(arrive); P(continue); koordinaattori P(arrive) OK kertaa! V(continue) kertaa! Rinnakkaisuuden hallinta resurssien varaus get/rel muuttujat hallinnan toteutus P/V semafori P/V:n toteutus LOCK/UNLOCK lukkomuuttuja GET {P(mutex) V(mutex) REL {P(mutex) V(mutex) P( ) LOCK(lock) UNLOCK(lock) pagepool mutex avail V( ) LOCK(lock) UNLOCK(lock) LOCK/UNLOCK toteutus test-and-set-käsky lukkomuuttuja LOCK loop..ts(x)... UNLOCK x = - -

5 buf: Esimerkkejä semaforin käytöstä Tuottajat ja kuluttajat Lukijat ja kirjoittajat Resurssien hallinta, vuoron antaminen Andrews Fig..: Producers and consumers using semaphores. (split binary semaphores) Toimiiko oikein? Mitä pitääkään tarkistaa? Halkaistu binäärisemafori (Split binary semaphore) semaforit empty ja full binäärisemaforeja, koska voivat saada vain arvoja ja koska aina toisella niistä on arvona ja toisella, niin niiden voidaan katsoa olevan yhdestä semaforista halkaistuja osia voidaan halkaista myös useampaa osaan: N kappaletta semaforeja, joista aina yhdellä on arvona ja muilla halkaistu binäärisemafori huolehtii myös keskinäisestä poissulkemisesta: vain yksi kerrallaan pääsee suorittamaan sen suojaamaa kriittistä aluetta, jos yhdellä semaforilla alkuarvona, muilla kaikilla prosesseilla koodissaan ensin P-operaatio semaforiinsa Se prosessi (yksi niistä prosesseista) aloittaa, jonka P- operaation kohteen semaforin arvo on. Sem empty =, full = ; ; Tuottaja i P(empty); buf=data; V(full);... Onko aloitus kunnossa? Kuluttaja j P(full) result = buf; V(empty)... Säilyykö oikea järjestys (tahdistus)? - saa tuottaa, vain jos kuluttaja lukenut - saa kuluttaa, vain jos tuottaja jotain tuottanut Tuleeko sekaannusta, jos usea tuottaja tai kuluttaja yrittää samaan aikaan käyttää puskuria? Pääseekö kumpikaan etenemään (lukkiutuminen)? Odotetaanko turhaan? Nälkiintyykö jompikumpi? N:n alkion puskuri; yksi tuottaja, yksi kuluttaja front rear Toimiiko jos usea tuottaja ja kuluttaja? Tarvitaan keskinäistä poissulkemista! Andrews Fig..: Bounded buffer using semaphores Entä, jos vain yksi Liisa Marttinen mutex? Andrews Fig..5: Multiple producers and consumers using semaphores. - 5

6 Lukijat ja kirjoittajat Yhteinen tietokanta DB tai joku muu objekti, esim. tiedosto, lista, Kaksi tietokantaan pääsystä kilpailevaa käyttäjäluokkaa Lukijat (readers) lukevat useita lukijoita voi olla käsittelemässä yhtäaikaa Kirjoittajat (writers) lukevat ja muuttavat vain yksi kerrallaan saa olla muuttamassa tietokantaa Luokka aktiivinen vain, jos toinen luokka passiivinen - Ratkaisu : R/W-poissulkemisongelmana Yksinkertaistettu ongelma, yksink. ratkaisu Poissulkeminen kaikille muille => semafori rw Turhan rajoittava Salli lukijoiden toimia rinnakkain Luokan poissulkeminen => semafori rw Ensimmäinen lukija varaa tietokannan lukijaluokalle, viimeinen lukija vapauttaa DB:n Kuka on ensimäinen / viimeinen? => laskuri nr testaa, varaa / vapauta => atominen: < > - Tehokkaampi ratkaisu lukijoita voidaan tarkastella yhtenä joukkona kun yksi on päässyt lukemaan, muut voivat tulla vapaasti perässä vain ensimmäisen lukijan täytyy varmistaa, ettei kukaan kirjoittaja ole kirjoittamassa eli varata kriittinen alue kun lukijoita ei enää ole, niin vuoro voidaan luovuttaa kirjoittajille viimeinen lukija vapauttaa kriittisen alueen tarvitaan laskuri ja sen päivittämistä, jotta tiedetään, mikä prosessi on ensimmäinen ja mikä viimeinen int nr = ; # lukijoiden lukumäärä nr=nr+; # kasvatetaan, kun mennään lukemaan nr=nr-; # vähennetään, kun poistutaan lukemasta if (nr = =) P(rw); # ensimmäinen varaa alueen if (nr == ) V(rw); # viimeinen vapauttaa sen -. lukija varaa tietokannan ja viimeinen lukija vapauttaa sen sem rw = ; int nr = ; sem mutex =; process Reader [i= to M] {... < nr = nr + ; if (nr = =) P(rw); > read the database; # ensimmäinen lukija < nr = nr -; if (nr = = ) V(rw); > # viimeinen process Writer [i= to N] {... P(rw); write the database; V(rw); RATKAISUN REILUUS? - Ratkaisu : R/W-ehtosynkronointiongelmana Odota, kunnes sopiva ehto tulee todeksi Toiminnallisuus: < await (ehto) lauseet; > Ehdon testaus ja lauseosa atomiseksi Tila BAD: (nr > and nw > ) or nw > RW: (nr == or nw ==) and nw <= RW muuttumaton, oltava voimassa aina (invariantti) nr = number of readers, nw = number of writers Ohjelmoi s.e. ehto RW on aina true saa lukea nw == (ei kukaan kirjoittamassa) saa kirjoittaa nr== and nw== (ei muita kirjoittajia eikä lukijoita) - 5 Jokaiselle odotukselle oma semafori! Tässä yksi poissulkeminen ja synkronointiehtoa. Andrews Fig..: A coarse-grained readers/writers solution

7 Jaettu binääriarvoinen semafori Liitä kuhunkin vahtiin (ehtoon) semafori ja laskuri : sem e, r, w; Vain yksi semafori kerrallaan auki ( <= (e+r+w) <= ) alussa: sem e =, r=, w=; await (nw==) nr = nr+ semafori: r = waiting place for readers laskuri: dr number of delayed readers await (nr== and nw==) nw = nw+ semafori: w = waiting place for writers laskuri: dw number of delayed writers poissulkeminen < > semafori: e = waiting place for entry laskurit: nr, nw numbers of readers and writers Ratkaisu, laajennettu Ota huomioon käyttövuorot Lukijat ensin, tai Vuoro prioriteetin perusteella: Kirjoittajat ensin! (jos muutokset tärkeitä; nälkiintymisvaara) Onko, joku odottamassa vuoroa? Ei voi kysyä semafori-operaatioilla omat laskurit: dw,dr Vuorojen toteutus omassa rutiinissa SIGNALNEXT Kriittinen alue vapautuu joku muu saa jatkaa, kuka? odottava lukija, odottava kirjoittaja, kokonaan uusi tulija process Reader { # <await (nw == ) nr = nr + ;> read the database; # <nr = nr -;> P(e); #varmistaa atomisuuden if (nw > ){ #joudutaan odottamaan dr = dr + ; V(e); P(r); nr=nr+; SIGNALNEXT; P(e); #varmistaa atomisuuden nr=nr-; process Writer { # <await (nw == ) nw = nw + ;> write the database; # <nw = nw -;> P(e); #varmistaa atomisuuden if (nr> or nw > ){ #joudutaan odottamaan dw = dw + ; V(e); P(w); nw=nw+; SIGNALNEXT; P(e); #varmistaa atomisuuden nw=nw- SIGNALNEXT; SIGNALNEXT; SIGNALNEXT - vuoron antaminen: Lukijat ensin! if (nw == and dr > ) { dr = dr -; V(r); # herätä odottava lukija, tai else if (nr == and nw == and dw > ) { dw = dw -; V(w); # herätä odottava kirjoittaja, tai else V(e); # päästä joku uusi etenemään Menetelmä: Viestikapulan välitys (Baton passing) - Viestikapulan välitys (Baton passing) semafori ~ viestikapula; koska semaforit e, r ja w muodostavat jaetun binäärisemaforin, niin kulloinkin yhdellä niistä on arvo ja muilla arvo Vain yksi etenee kerrallaan kriittisillä alueilla pyydettävä etenemislupaa: P(e) se etenee, joka saa haltuunsa semaforin e Muiden odotettava täysin uusi lukija tai kirjoittaja: P(e) vuoroaan jonottamaan jääneet lukijat ja kirjoittajat: Jos etenijän pyyntöön ei voi suostua: Lukijat: V(e); P(r) (jää odottamaan lukijan vuoroaan) Kirjoittajat: V(e); P(w) (jää odottamaan kirjoittajan vuoroaan) - 7

8 Etenijä aktivoi itse seuraavan viestikapulan haltijan (kohdassa SIGNALNEXT) jos vuoroaan odottavia, herätä odottaja semaforista: joko V(r) tai V(w) jätä sille poissulkemissemafori valmiiksi kiinni: älä tee V(e) jos ei odottajia, jätä viestikapula vapaaksi uusille tulijoille: V(e) Herätetty välittää aikanaan kapulan seuraavalle ja se seuraavalle ja... Takaa ettei kukaan pääse etuilemaan! Ehdot taatusti voimassa, kun jonottaja saa prosessorin SIGNALNEXT aktivoi vain yhden prosessin, kun ehto tuli todeksi FCFS - SIGNALNEXT - vuoron antaminen: Lukijat ensin! if (nw == and dr > ) { dr = dr -; V(r); # herätä odottava lukija, tai else if (nr == and nw == and dw > ) { dw = dw -; V(w); # herätä odottava kirjoittaja, tai else V(e); # päästä joku uusi etenemään Osa ehdoista on jo tiedossa, kun ollaan lukijassa tai kirjoittajassa => voidaan jättää pois eikä tarvitse enää testata! - Semaforin r jonossa odottavat lukijat Semaforin w jonossa odottavat kirjoittajat Entrysemaforin e jonossa odottavat Voiko mennä lukemaan / kirjoittamaan? Jos jonoon, vapautetaan entry-semafori seuraavalle. Jos ei, niin valitaan seuraava tietokannan käsittely lopputoimet: poistutaan ja valitaan seuraava kriittiselle alueelle pääsijä. laskurit dr ja dw kertovat odottavien lukumäärän. Päästetäänkö lukija, kirjoittaja vai uusi tulija? Jos päästetään odottava lukija tai kirjoittaja, niin päivitetään myös laskurit valniiksi! Lukijat ensin Tarpeettomat osat annetusta SIGNALNEXT-koodista poistettu Andrews Fig..: A readers / writers solution using passing the baton SIGNALNEXT - vuoron antaminen: Kirjoittajat ensin! Resurssien hallinta ja vuoronantaminen Reader: uusi lukija odottamaan, jos kirjoittaja odottamassa if (nw> or dw>) # DELAY { dr=dr+; V(e); P(r); Writer: herätä lukija vain, jos kirjoittajia ei odottamassa if (dw>) { # SIGNALNEXT dw = dw-; V(w); # herätä kirjoittaja elseif (dr>) { # herätä lukija dr = dr-; V(r); else V(e); # herätä uusi * Resurssi hyvin laajasti ymmärrettynä: mitä tahansa mitä prosessi joutuu odottamaan: Pääsy kriittiselle alueelle tai tietokantaan puskuritilaa muistia tulostimen käyttö * Vuoronantamisessa halutaan tarkemmin määrätä, mikä prosessi pääsee etenemään! Semafori itse pitää odottajat FIFO-jonossa! V-operaatio vapauttaa jonon ensimmäisen etenemään! Lukijat/kirjoittajat: lupa luokkakohtainen

9 Toimivatko rutiinit oikein Poissulkeminen? Ei lukkiutumista (deadlock/livelock)? Ei tarpeettomia viipeitä? Lopulta onnistaa? sem avail ~ resurssin varaus yksi kerrallaan; jos ei heti onnistu, niin jonoon odottamaan (FCFS), josta vuorollaan saa resurssin varatuksi sem mutex ~ resurssin käyttöönotto yksi kerrallaan; jos ei heti onnistu, niin FCFS- jonoon odottamaan, josta vuorollaan kirjaa resurssin haltuunsa vapautettaessa ensin kirjataan vapaaksi ja sitten annetaan muiden varattavaksi Missä järjestyksessä prosessit päästetään jatkamaan? - 9 Palvelujärjestys Semaforin jonot aina FCFS Ongelma? Jäljellä sivutilaa, eka haluaa, toka 5! Voiko semaforiin liittää prioriteetin? Jonotusjärjestys? Baton passing- tekniikka: eri luokille omat jonot Montako erilaista? Dynaaminen vuorottelu? Kaikki mahdolliset varattavat sivutilakoot ( N) Ratkaisu: yksityiset semaforit + oma jono Kullekin prosessille oma semafori, jossa odottaa yksin Vuoron antamiseen käytettävä tietorakenne (jono) erikseen alkiossa semafori ja yleensä tietoa, jonka perusteella valitaan Vuoron antaja valitsee sopivan semaforin vuorojonosta, ja päästää liikkeelle semaforissa odottavan asiakkaan - 5 SJN: Lyhyin työ seuraavaksi request(time,id): # käyttöaika, prosessin tunnus P(e); if (!free) DELAY; # ei ole vapaa => odotus free = false; # nyt omaan käyttöön! SIGNAL; # release(): # resurssin vapautus P(e); free = true; SIGNAL; # pienin käyttöaika ensin! DELAY: Odottajan ID ja TIME (suoritusaika) suoritusajan mukaan järjestettyyn jonoon (PAIRS) oikeaan kohtaan V(e) eli vapauta kriittinen alue jää odottamaan vuoroasi P(b[ID]) Tässä tarvitaan kullekin oma semafori, jotta pystytään herättämään oikea prosessi: b[n] = ([n] ) PAIRS-jono määrää järjestyksen: herätetään aina jonon ensimmäinen prosessi SIGNALNEXT: Reguest-vaihe vapauta kriittinen alue V(e) eli päästä joku uusi Requestvaiheeseen Release-vaiheen lopussa Jos jonossa odottajia, niin ota jonon ensimmäisen alkiopari (time, ID) ja herätä prosessi ID: V(b[ID]; muuten V(e) PAIRS: P P5 P P prosessin ID käyttöaika jono järjestetty käyttöajan pituuden mukaan REQUEST (6, P) b[n] n- P P P Oma semafori jokaiselle prosessille (n kpl): ID:t..n-. Prosessin odotus riippuu sen sijainnista PAIRS-jonossa. (Kun resurssi vapautuu, niin jonon. saa resurssin ja pääsee etenemään. Jono elää ja muuttuu uusien pyyntöjen mukana. ) - 5 Andrews Fig..: Shortest job next allocation using semaphores

10 Entä, jos resurssia enemmän kuin yksikkö? amount = montako yksikköä prosessi tarvitsee tai palauttaa avail = montako yksikköä on vapaana (~free) request: testattava, onko vapaana tarvittu määrä yksiköitä amount <= avail. Jos on, niin varataan, muuten talletetaan myös amount myös tässä voidaan vapauttaa odottavia prosesseja, jos vapaita resursseja on tarpeeksi release: vapautetaan jonosta ensimmäinen prosessi, jonka tarpeet pystytään tyydyttämään POSIX-kirjasto, pthread # include <pthread.h> pthread_mutex_init(), _lock(), _trylock(), _unlock(), _destroy() _mutexatrr_*(), pthread_rwlock_init(), _rwlock_rdlock(),_rwlock_tryrdlock(), _rwlock_wrlock(), _rwlock _trywrlock(), _rwlock_unlock(), _rwlock_destroy(), _rwlockattr_*(), # include <semaphore.h> sem_init(), sem_wait(), sem_trywait(), sem_post(), sem_getvalue(), sem_destroy(), c Lue man- / opastussivut c Andrews ch.6, Java.5 Aterioivat Filosofit (Dijkstra) java.util.concurrent Lukkoja, atomisia muuttujia Säikeiden synkroinointiin on tarjolla neljä luokkaa: Semaphore, CyclicBarrier, CountDownLatch ja Exchanger. semaforilta pitää saada lupa lohkon käyttöön kutsumalla acquire()-metodia, johon säie jää odottamaan, mikäli lupaa ei heti saada. Vastaavasti synkroinoitavan osuuden jälkeen lupa pitää palauttaa semaforille release()-metodilla. Kurssi: Ohjelmointitekniikka (Java) - 57 Filosofi: aattelepa ite ota kaksi haarukkaa... yksi kummaltakin puolelta syö, syö, syö spagettia palauta haarukat Kuinka varata haarukat ilman - lukkiutumista - turhaa odottamista - nälkiintymistä s.e. kaikki saavat olla paikalla? - 58 Ratkaisu : kullekin haarukalle oma semafori sem fork[..] = (,,,, ) Ratkaisu : vain yksi voi yrittää kerrallaan sem turn = # säätelee yritysvuoroja process P[i]: repeat think() P(fork[i]) P(fork[(i + ) mod 5]) eat() V(fork[i]) V(fork[(i+) mod 5]) until false Voi lukkiutua! Kukin ehtii ottaa yhden haarukan ja jää odottamaan Ei OK! Miksei? toista Liisa eikä Marttinen kukaan pääse syömään! process P[i]: repeat think() P(turn) P(fork[i]) P(fork[(i+) mod 5]) V(turn) eat() V(fork[i]) V(fork[(i+) mod 5]) until false Turhaa odotusta! Ei ihanok! Miksei?

11 Turhaa odotusta! Oletetaan, että ensin kaikki ajattelevat ja sitten haluavat syömään esim. järjestyksessä fil, fil, fil, fil, fil fil saa haarukat ja pääsee syömään, fil varaa itselleen varausvuoron ja jää odottamaan haarukkaa ja muut sitten vain odottavat, ensin varausvuoroa ja haarukoita fil joutuu ihan turhaan odottamaan, haarukat olisivat vapaina, mutta niitä ei pääse varaamaan! Mutta kukin pääsee varaamaan ja aikanaan syömään => ei ole nälkiintymistä! varaussemafori turn pitää varaukset FIFO-jonossa - 6 Ratkaisu : OK Andrews Fig..7-6 Entä onko turhaa odotusta? Korkeintaan filosofia saa haarukan käteensä: fil haarukan, fil haarukan, fil haarukan ja joko fil tai fil haarukan riippuen siitä kumpi ensiksi ehtii. Haarukka jää aina vapaaksi ja sen saa fil, joka siis pääsee syömään ja aikanaan vapauttaa hallussaan olevat haarukat ja päästää muut syömään. Näin estetään lukkiutuminen! Ratkaisu ei myöskään aiheuta nälkiintymistä. Suosii tosin fil:aa, mutta vain tässä erikoistilanteessa. - 6 Ratkaisu : OK, mutta... vrt. sem fork[5] = ([5] ); sem room = ; process Philosopfer[i= to ] { think(); P(room); P(fork[i]); P(fork[(i+) mod 5]); eat(); V(fork[i]); V(fork[(i+) mod 5]); V(room); Estää lukkiutumisen! Ei turhaa odotusta. Saavatko kaikki olla paikalla? Stallings Fig Ratkaisu 5: OK? Nälkiintyminen? Tanenbaum Fig Huom: down() = P(), up() = V() Tanenbaum Fig

12 Ratkaisu 5: Tapettaisko filosofi? Ratkaisu 6: OK, ei yhteisiä resursseja EATING HUNGRY Ostakaa 5 haarukkaa lisää! Filosofi[i]: aatteleppa ite ota kaksi haarukkaa yksi molemmilta puolilta syö, syö, syö spagettia palauta haarukat