RIO S01

Luku 5

Vastauksia
 

1.  On mahdollista,  että kaikki filosofit aloitavat haarukoiden keräämisen samaan aikaan, jolloin kukin saa vasemman haarukan eikä muuta.  "Samaan aikaan": kukin filosofi suorittaa P(fork[i]) -operaation ennen kuin hänen vasen naapurinsa saa suoritettua P(fork[i+1]) -operaation.

2.  Tässä tapauksessa on suhteellisen helppo keksiä toimiva ratkaisu, joten ei ole mitään syytä olla varautumatta.  Yleisesti voi todeta, että lukkiutumiseen varautumisella on hintansa (varauduttava
palautumaan johonkin aiempaan tilaan tms).  Lukkiutuminen on kuitenkin käytännössä varsin ikävä tilanne: järjestelmän tietyt osat lakkaavat toimimasta (lukkiutuneet prosessit sekä ne prosessit, jotka haluavat varata lukkiutuneiden varaamia resursseja, jotka voivat joskus olla vaikkapa tärkeitä käyttöjärjestelmän kontrollitietorakenteita) eikä järjestelmä ilmoita tilanteesta millään tavalla.  Jos lukkiutumisesta aiheutuva haitta on suuri, niin suhteellisen kalliidenkin menetelmien käyttö on perusteltua.

3.  F1 syö, F2 varaa vuoron,  F3 haluaisi syödä (ja voisi, mutta F2 pitää vuoroa varattuna).  Ratkaisu rajoittaa tarpeettomasti muuten mahdollista rinnakkaisuutta.

4.  F1 ja F3 eivät voi tappaa F2:a nälkään  (F1 ja F3 voivat olla vuorotahtisesti toimiva sovellus,  noudattavat esimerkiksi  asiakas-palvelija -toimintamallia.

5.  Resurssimanageri varmistaa ennen resurssiyksikön myöntämistä, että vielä myöntämisen jälkeen on olemassa ainakin yksi tapa saada kaikki prosessit vietyä loppuun asti (vaikka kaikki tarvitsisivat ilmoittamansa maksimimäärän resursseja loppuun päästäkseen).
HUOM.  Prosessit voivat haluta yhteensä enemmän resursseja kuin mitä järjestelmässä on;  pankkiiri päättää, missä järjestyksessä asiakkaita lopulta palvellaan (eli koska kukakin pyyntöönsä saa vastauksen).

6.  Pyytäjä jää odottamaan.  Kun resurssienvaraustilanne muuttuu, niin manageri harkitsee pyynnöt uudelleen.  Pyytäjä saa varmasti  lopulta pyytämänsä resurssit (pankkiirin algoritmi takaa, että järjestelmä pysyy koko ajan turvallisessa tilassa eli kaikki olemassa olevat työt saadaan loppuun).

7.  Hyvällä onnella kaikki sujuu hyvin, huonolla onnella järjestelmä lukkiutuu.  Pankkiirin algoritmi takaa, että lukkiutumista ei tapahdu edes "worst case" -tapauksessa eli tilanteessa, jossa kaikki aktiiviset prosessit vaativat ilmoittamansa maksimimäärän resursseja.  Tämä ei välttämättä ole ihan tavallista, joten lukkiutumisen todennäköisyys voi olla aika pieni.

8.  Tuottaja-kuluttajassa tiedon prosessointi etenee yhteen suuntaan, joten kehäodotusta ei ihan luonnostaan pitäisi syntyä.  Asiakas-palvelijan perusmallissa (joukko yksittäisiä toimenpidepyyntöjä) ei taas "hold while waiting" tilanteita pitäisi syntyä (paitsi ehkä palvelimen sisällä).

Huolellisuutta vaativia arkkitehtuureja ovat:

Lukkiutumisen riski on verraten pieni tilanteissa, joissa kaikki prosessit ovat toiminnoissaan toisistaan täysin riippumattomia.  Riski on suurempi, jos käytettävissä olevia resurssiyksiköitä on vähän tai jos käyttäjien käynnistämät toimenpiteet tietyissä tilanteissa käyttävät muutamaa yhteistä resurssia.  Esimerkiksi pankkisiirto tarvitsee tyypillisesti kaksi resurssia (tili, jolta siirretään, tili, jolle siirretään),  jotka voidaan varata yksi kerrallaan; tilisiirroissa yksityishenkilöiden väliset pankkisiirrot harvoin kohtaavat; laskunmaksut kohtaavat, mutta niissä kehäodotusta ei synny; monimutkaisemmat pankkisiirrot on syytä miettiä huolellisesti.

9.  Käyttöjärjestelmän jokaisesta resurssityypistä huolehtii oma resurssimanageri, ja nämä ovat toisistaan varsin riippumattomia. Kun siis sovellus käynnistyy, niin sille varataan sen tarvitsemia resursseja yksi resurssityyppi kerrallaan. Sovellus voi myös elinaikanaan tarvita lisää erilaisia resursseja voidakseen jatkaa (tiedostoja tms).  Periaatteessa siis kaikki edellytykset lukkiutumisen syntymiselle ovat olemassa pöytäkoneessa, jonka käyttäjällä on monta sovellusta samaan aikaan auki. Käytännössä lukkiutumisvaara on kuitenkin suhteellisen pieni. Perusresursseja (muistia, levyä jne) on yleensä käyttäjän tarpeiden kannalta "äärettömän paljon" eli niitä ei jouduta odottamaan.  Käyttäjä suhteellisen harvoin käyttää samaa resurssia (esim tiedostoa) eri sovelluksissa rinnakkain. Tähänkin käyttöjärjestelmä on yleensä varautunut: sovellus ei jää odottamaan resurssin vapautumista vaan antaa siitä (rajoitettuun) käyttöön kopiokappaleen (varoituksella: tiedosto on auki toisella käyttäjällä).
Toisaalta: kaikki lienevät törmänneet tilanteeseen, jossa järjestelmä ei reagoi enää mihinkään - tällöin syynä saattaa hyvinkin olla jokin lukkiutumisen eri muodoista.