4. Prosessit ja säikeet

Transkriptio

1 74 Sulautettu ohjelmointi 4. Prosessit ja säikeet Yksi käyttöjärjestelmien tärkeimpiä abstraktioita on prosessi. Myös sulautetuissa järjestelmissä on aivan pienimpiä laitteita lukuunottamatta aina jonkinlainen käyttöjärjestelmä ja myös prosessikäsite. Luvussa 7 sivulla 120 käsitellään tarkemmin pienten sulautettujen järjestelmien toteutustapoja. Tässä luvussa tutustutaan ensin prosesseihin ja säikeisiin ja kuinka ne pyytävät ytímeltä palveluita sekä ytimen tapaan käsitellä keskeytyksiä. 4.1 Prosessit Prosessi on suorituksessa oleva ohjelma. Jokaista prosessia kohti on käyttöjärjestelmän ytimessä prosessielementti (process control block, PCB), johon kerätään (lähes) kaikki prosessikohtaiset tiedot. Erityisesti sinne on talletettu tieto siitä, onko prosessi otettavissa ajoon, odottaako se jotain tapahtumaa vai onko se ajossa. Prosessielementtiin palataan kohdassa Prosessien tilamalli Käyttöjärjestelmän kannalta tarkasteltuna prosessi on kunakin hetkenä jossain tiloista ready, run tai wait (kuva 4.1). Tilassa run ovat parhaillaan suoritettavina olevat prosessit yksisuoritinjärjestelmässä siis korkeintaan yksi prosessi kerrallaan. Ready-tilassa ovat prosessit, joilla on kaikki muut niiden tarvitsemat resurssit lukuun ottamatta suoritinta itseään. Ne siis odottavat run-tilaan pääsyä. Vuorontajan tehtävänä on valita jokin ready-tilan prosesseista run-tilaan suoritettavaksi. Wait-tilassa ovat prosessit, jotka odottavat jotain tapahtumaa, esimerkiksi I/Ooperaation päättymistä tai jonkin resurssin vapautumista. Tästä tilasta käytetään myös termiä blocked. Erityisen hämäävää on se, että joissain yhteyksissä tilat ovat ready, waiting (tai suspended) ja blocked, jotka siis vastaavat tiloja run, ready ja wait, tässä järjestyksessä. On siis syytä

2 Prosessit ja säikeet 75 RUN Vuorontaja READY Prosessi odottaa Uusi prosessi Odotus päättyy WAIT Prosessi poistuu Kuva 4.1 Prosessien tilakaavio. aina tarkistaa, millaisia nimiä tiloista käytetään. Uudet prosessit ilmestyvät tässä käytetyssä termistössä ready-tilaan. Vuorontaja valitsee ready-tilasta suoritukseen (run-tilaan) jonkin prosessin, tavallisesti sen, jonka prioriteetti on korkein. Run-tilasta prosessi siirtyy wait-tilaan omasta pyynnöstään; esimerkiksi pyytäessään jotain käyttöjärjestelmäpalvelua (SVC 12, supervisor call), jonka toteutukseen liittyy odotusta. Siirtyminen wait-tilasta ready-tilaan tapahtuu luonnollisesti kyseisen odotuksen päättyessä esimerkiksi laitteen keskeyttäessä I/O-toiminnan valmistumisen merkiksi. Prosessi voi joutua run-tilasta takaisin ready-tilaan, kun vuorontaja vaihtaa suoritettavan prosessin jonkin keskeytyskäsittelyn päätteeksi. Tätä tapahtumaa, jossa prosessi joutuu luovuttamaan keskusyksikön vasten tahtoaan, kutsutaan irrottavaksi skeduloinniksi (pre-emptive scheduling). Päättyvien prosessien voidaan ajatella poistuvan järjestelmästä vaikkapa wait-tilan kautta. Ytimen tehtävänä on ohjata prosessien etenemistä tilamallin edellyttämällä tavalla Lisätiloja Vaikka edellä kuvattu kolmen tilan järjestelmä periaatteessa kattaa kaiken, käytännössä tiloja on enemmän. Tällaisia lisätiloja syntyy esimerkiksi prosessin hetkellisestä pysäyttämisestä tai heittovaihdosta. Pysäytyspyynnön syynä on tavallisesti käyttäjän pyyntö. Esimerkiksi lähes kaikki Unix-järjestelmät sisältävät mahdollisuuden tähän (job control): tavallisesti control-z pysäyttää ajossa olevan prosessin, jol- 12. SVC on konekäsky, joka siirtyy käyttäjän tilasta etuoikeutettuun tilaan keskeytyspalvelun tapaan. Käskyn nimi vaihtelee tietokonearkkitehtuurista toiseen.

3 76 Sulautettu ohjelmointi RUN Vuorontaja READY Prosessi odottaa Odotus päättyy Heittovaihtaja WAIT Heittovaihtaja Prosessi poistuu SWAPPED WAIT SWAPPED READY Kuva 4.2 Prosessien tilakaavio heittovaihtojärjestelmässä. loin siirrytään lisätilaan suspended. Koska tilaan suspended voidaan päätyä joko käyttöjärjestelmän tai prosessin itsensä haluamana, tila voidaan saavuttaa oikeastaan mistä tahansa tilasta, ja se jakaantuu alitiloihin ready ja wait riippuen siitä, mihin tilaan suspended-tilasta palataan. Heittovaihto (swapping) aiheuttaa hyvin samankaltaisen toiminnan (lisätilaksi tulee tila swapped), mutta yleensä pyritään siihen, että heittovaihto tehdään vain wait-tilassa oleville prosesseille. Prosessin tilamalli muuttuu heittovaihdossa kuvan 4.2 mukaiseksi. Virtuaalimuisti ei sinänsä lisää uusia päätiloja, sillä puuttuva sivu aiheuttaa vain tilasiirtymän tilaan wait. Koska varsinkin pieniä sulautettuja ohjelmistoja toteutettaessa heittovaihto tai virtuaalimuistin käyttö eivät tule kysymykseen, prosessin tilakaavio pysyy yksinkertaisimmassa muodossaan Säikeet Koska erityisesti ikkunoinnin mutta myös muidenkin ongelmakenttien yksinkertainen toteutus tarvitsee paljon prosesseja, on pyritty tekemään normaaliprosessia kevyempiä prosesseja. Näitä kutsutaan säikeiksi (threads, light weight processes, joskus jopa ultra light processes). Samassa järjestelmässä voi jopa olla useita erilaisia variaatioita kevyemmistä prosesseista, joiden resurssien kulutukseen, kuten esimerkiksi dynaamisesti varattavaan muistiin tai pinon kokoon, liittyvät ominaisuudet vaihtelevat.

4 Prosessit ja säikeet 77 Yleisesti ottaen säikeet ovat prosesseja kevyempiä ratkaisuja suoritusajan jakamiselle. Keveys saadaan aikaan siten, että samaan prosessiin kuuluvilla säikeillä on yhteinen osoiteavaruus, jolloin säikeen vaihtuessa prosessin sisällä ei tarvitse vaihtaa muistinhallinnan ohjausrakenteita, vaan ainoastaan rekisterit. Säikeillä on siis yhteinen osoiteavaruus, vain niiden pinot ovat erillisiä, ja nekin ovat muistinhallinnan kannalta yhteisellä muistialueella. Monissa käyttöjärjestelmissä säie on pienin skeduloitava yksikkö, ja jokaisessa prosessissa on vastaavasti ainakin yksi säie. Prosessin tehtävänä on tarjota yhteinen muisti ja muut resurssit joukolle säikeitä ja yhdistää ne loogisesti; skedulointiin prosessikäsite ei osallistu kuin poikkeustapauksessa (esimerkiksi koko prosessin siirtyessä tilaan suspended). Säikeet voidaan toteuttaa sekä käyttäjän tasolla että käyttöjärjestelmän tasolla. Käyttäjän tasolla toteuttaminen merkitsee kirjastorutiinia, joka toimii prosessin sisäisenä vuorontajana. Tämän ratkaisun ongelma on siinä, että prosessin minkä tahansa säikeen pyytäessä sellaista palvelua, joka vie prosessin wait-tilaan, kaikki säikeet pysähtyvät odottamaan palvelun päättymistä. Tämä taas käytännössä pilaa monet säiesovellukset. Käyttöjärjestelmän tasolla toteutettuna yhden säikeen joutuminen wait-tilaan ei pysäytä muita. Lisäksi voidaan väittää, että skedulointi on ainakin periaatteessa reilumpaa, kun prosessin jokainen säie saa erikseen aikaa. Monet nykyiset käyttöjärjestelmät tarjoavat säikeet käyttöjärjestelmätasolla. Lisäksi voidaan käyttää molempia järjestelmiä rinnan, jolloin osa skeduloinnista voidaan hoitaa kirjastorutiineilla ja osa ytimen säikeillä. Kirjastorutiiniversio on hieman kevyempi käytössä, koska skedulointia varten ei tarvitse tehdä käyttöjärjestelmäpyyntöä. Joissain käyttöjärjestelmissä ei ole erikseen säikeitä, vaan säikeet ja prosessit ovat sama asia (ainakin osa Linux-versioista). Vastaava ominaisuus saadaan aikaan siten, että kahdella prosessilla voi olla sama muistinhallinta, ja vuorontaja valitsee hieman mieluummin sellaisen prosessin, jolla on sama muistinhallinta kuin juuri ajossa olleella. Käytännössä ratkaisujen ero näkyy siinä, että prosesseihin liitettävät ominaisuudet, kuten resurssit ja signaalit, toimivat näissä ratkaisuissa eri tavalla.

5 78 Sulautettu ohjelmointi 4.2 Keskeytykset Käyttöjärjestelmä ei tee mitään, ellei keskeytystä tule vähintään tarvitaan kellokeskeytys tönäisemään laskentaa eteenpäin. Keskeytys voi tulla joko oheislaitteelta tai ohjelmalta. Riippumatta siitä, mistä syystä tai miltä laitteelta keskeytys tulee, tehdään keskeytyskäsittelyn alussa ja lopussa samat toimenpiteet Keskeytyskäsittelyn aloitus ja lopetus Keskeytysten käsittely on periaatteessa yksinkertaista: talletetaan ympäristö eli suorittimen rekisterit ja tilasana sekä muistinhallinnan tiedot ja haaraudutaan keskeytystä vastaavaan keskeytyskäsittelijään. Käyttöjärjestelmän ja laitteiston näitä toimintoja kutsutaan joskus nimellä ensitason keskeytyskäsittely (FLIH, first level interrupt handling). Ensitason keskeytyskäsittelyyn liittyvät ohjelmalliset toimenpiteet vaihtelevat hieman riippuen siitä, miten käytettävissä olevan laitteiston keskeytystoiminta on määritelty. Koska suurin osa ytimen koodista halutaan suorittaa keskeytykset sallittuina, tarvitaan ympäristön talletusta varten niin sanottu ympäristöpino (environment stack, kernel stack). Esimerkiksi ARMsuorittimissa ympäristöön (ilman muistinhallintaa) tulee 17 sanaa (suorittimen tilarekisteri, ohjelmalaskuri ja 15 yleisrekisteriä). Pinossa tulee olla tilaa niin paljon, ettei ylivuotoa voi koskaan tapahtua. Suorittimissa, jossa laitteisto tallettaa ympäristön automaattisesti ympäristöpinoon, ja keskeytysvektori ohjaa kunkin laitteen tai keskeytyksen syyn suoraan oikealle ytimen rutiinille, ei ohjelmistopuolen tehtäväksi jää ensitason käsittelijässä oikeastaan mitään, sillä muistinhallinnan rekisterien talletus ei yleensä ole tarpeen. Tavallisesti laitteisto ei ole näin ahkera, vaan rekisterien talletus tehdään ohjelmallisesti. Huomaa, että tilarekisterin ja ohjelmalaskurin talletus on kuitenkin aina oltava laitteiston vastuulla. Mikäli keskeytysvektorit ohjaavat toiminnan ytimen rutiineille, kutsutaan tätä rekisterientallennusohjelmaa joka rutiinin alussa. Eniten töitä ohjelmisto saa, mikäli yhdellä tai useammalla laitteella on yhteinen keskeytysvektori, jolloin ohjelmiston on selvitettävä myös keskeytyksen aiheuttaja kuten aiemmin esitettiin kohdassa 2.4 sivulla 34. Monissa suorittimissa on erillinen pino-osoitin etuoikeutetulle tilalle. Keskeytyksen tullessa pino-osoitin vaihtuu automaattisesti tilan mukaan.

6 Prosessit ja säikeet 79 FLIH FLIH keskeytys A: keskeytys B: keskeytyksen käsittely RETI Ympäristöpino: JMP vuorontaja RETI (tyhjä) A:n ympäristö B:n ympäristö A:n ympäristö Kuva 4.3 Keskeytyvä keskeytyskäsittely. Paluu keskeytyskäsittelystä voi periaatteessa tapahtua missä tahansa. Paluu tapahtuu siten, että ensin asetetaan muistinhallinnan rekisterit ja muut tietorakenteet, sitten palautetaan suorittimen rekisterit, ja lopuksi palataan keskeytyksestä esimerkiksi konekäskyllä RETI (return from interrupt). Jos laitteisto tallettaa keskeytyksessä rekisterit, se palauttaa ne poistuttaessa; jos taas keskeytys ei talleta rekistereitä, ei paluukäskykään sitä tee, vaan palautus tulee hoitaa ohjelmallisesti. Talletettavien rekisterien määrä on suoritinkohtainen ja yhdessäkin suorittimessa voi olla joitain erikoiskeskeytyksiä, jotka toimivat tässä suhteessa normaalista poikkeavasti. Jos paluu aiheuttaisi ympäristöpinon tyhjenemisen, kutsutaankin vuorontajaa, joka valitsee seuraavan suoritettavan prosessin. Reaaliaikaytimissä voidaan kutsua vuorontajaa aina, kun palataan keskeytyksestä, jotta reaaliaikavaste saataisiin tarpeeksi pieneksi. Kuvassa 4.3 on esimerkki ympäristöpinon käyttäytymisestä tapauksessa, jossa keskeytyskäsittely keskeytyy uuden keskeytyksen seurauksena. Ympäristöpinoa käytetään siis pinomaisesti ympäristön talletukseen. Tämän pinon lisäksi prosessiin liittyy luonnollisesti aktivaatiotietuepino, joka sijaitsee prosessille varatulla muistialueella. Laitteiston keskeytystoiminta olisi periaatteessa voitu määritellä myös siten, että

7 80 Sulautettu ohjelmointi ympäristö tallettuu aina aktivaatiotietuepinon huipulle. Tästä seuraisi kuitenkin ongelmia virtuaalimuistin toteutuksen yhteydessä, koska tällöin voisi olla mahdollista, että muistialue, jonne ympäristön talletus tapahtuu, ei ole parhaillaan keskusmuistissa. Jos ollaan toteuttamassa koko järjestelmää itse eikä virtuaalimuistia ole tarkoitus käyttää, voidaan usein hyödyntää myös säikeen aktivaatiopinoa jos ympäristöpinoa tai vastaavaa tietorakennetta ei ole käytettävissä Käyttöjärjestelmäkutsut Käyttöjärjestelmäkutsut tapahtuvat SVC-käskyllä edellä kuvatun keskeytysmenettelyn mukaisesti. Käyttöjärjestelmäpalveluita voi kutsua SVC-käskyllä myös käyttöjärjestelmän sisältä. Kuvassa 4.4 on esimerkki sleep-rutiinin toiminnasta. Sleep-rutiini nukuttaa prosessin ajanjaksoksi, jonka pituus annetaan parametrina. Rutiinin toteutus vaatii edelleen wait_event-rutiinin 13 kutsun, josta edelleen kutsutaan vuorontajaa. Nukkumisen aikana prosessin ympäristöpinossa on talletettuna kutakin SVC-kutsua vastaava ympäristö, eli pinossa on kolme päällekkäistä ympäristöä. Käyttöjärjestelmästä tapahtuvien SVC-kutsujen toimintaa voidaan hiukan nopeuttaa, jos kutsu on rutiinin viimeinen toimenpide. Tällaisessa tapauksessa kutsu voi tapahtua tavallisella hyppykäskyllä (JMP). Jos kuvan 4.4 SVC-kutsut ensimmäistä lukuun ottamatta vaihdettaisiin hyppykäskyiksi, tallettuisi pinoon vain yksi ympäristö, ja vuorontajan RETI-käsky palauttaisi kontrollin suoraan sovellukseen (tämä on piirretty kuvaan katkoviivoilla). Käyttöjärjestelmän sisältä tapahtuvat käyttöjärjestelmäkutsut voitaisiin hoitaa myös tavallisen aliohjelmakutsukäskyn avulla. Emme puutu kutsumekanismiin tämän tarkemmin, vaikka siihen paljon mielenkiintosia yksityiskohtia liittyykin esimerkiksi parametrien välitys voi olla hieman mutkikasta osoiteavaruudesta toiseen siirryttäessä. 4.3 Prosessien hallinnasta Käydään seuraavaksi läpi lyhyesti prosessinhallinnan alkeet sekä ehkä keskeisin prosesseihin liittyvä tietorakenne, prosessielementti. 13. Rutiini wait_event siirtää prosessin run-tilasta wait-tilaan odottamaan parametrina annettua tapahtumaa.

8 Prosessit ja säikeet 81 FLIH FLIH SVC SLEEP SLEEP: wait_event: FLIH SVC wait_event JMP vuorontaja vuorontaja: : : SVC vuorontaja RETI vuorontaja: : : RETI RETI Kuva 4.4 Käyttöjärjestelmää kutsuva käyttöjärjestelmäkutsu. Katkoviivalla optimoitu (hyppykäskyillä toteutettu) kutsusekvenssi Prosessielementti Prosessien hallinnan kannalta tärkein rakenne on prosessielementti (process control block, PCB). Kullakin prosessilla on oma prosessielementtinsä, jossa prosessin tietoja ylläpidetään. Prosessielementit on voitu koota prosessitauluksi, jonka koko asettaa ylärajan järjestelmässä olevien prosessien määrälle. Prosessielementistä löytyy muun muassa seuraavia tietoja: prosessin nimi (käytännössä kokonaisluku) prosessin tila: wait, ready tai run (tai vapaa prosessielementti free) prosessin sen hetkinen prioriteetti ja sen perusprioriteetti tilaa prosessin ympäristöjen talletusta varten (ympäristöpino) tulleen signaalin numero sekä signaalinkäsittelijöiden osoitteet (tarkemmin kohdassa 4.2.6). Jatkossa voimme olettaa, että käytössä on kuvan 4.5 mukainen yksinkertainen prosessielementti.

9 82 Sulautettu ohjelmointi Kenttä process_id on prosessin nimi esimerkiksi vaikkapa kokonaisluku. Prosessin tila (ready, run, wait) selviää state-kentästä. Prosessin siirtyminen tilasta toiseen vastaa state-kentän arvon muuttamista. Vapaa prosessielementti tunnistetaan state-kentän arvosta FREE. Vuorontaja tekee seuraavaksi suoritettavan prosessin valinnan priority-kentän perusteella. Koska prosessin prioriteetti voi tilapäisesti kasvaa kriittisen alueen suorituksen aikana käänteisprioriteettiongelman ratkaisemiseksi, tarvitaan lisäksi kenttä native_priority, jossa säilytetään prosessin omaa prioriteettia. Poistuttaessa kriittiseltä alueelta palautetaan kentän priority arvo sijoittamalla siihen kentän native_priority arvo. Käänteisprioriteettiongelma esitellään kohdassa sivulla Prosessin luominen Prosessin luonnin voi ajatella tapahtuvan seuraavasti. Linkittäjä (linker) muodostaa kooditiedoston, joka vastaa ohjelmalle varattavan muistialueen sisältöä ohjelman käynnistyessä (prosessin kuva, image). Voidaan sopia, että ensimmäinen suoritettava käsky on alueen ensimmäisessä sanassa; toinen mahdollisuus on, että prosessin kuva levyllä sisältää tiedon siitä, mistä prosessi aloitetaan, ja latauksen yhteydessä ydin alustaa ohjelmalaskurin oikeaan arvoon. Käyttöjärjestelmän ytimessä on prosessin käynnistämistä varten palvelurutiini execute (tai vastaava), jolle annetaan parametrina kooditiedoston nimi. Rutiini muodostaa prosessielementin prosessitauluun ja varaa prosessille alueen keskusmuistista. Kooditiedoston sisältö luetaan varatulle muistialueelle. Prosessielementin kentät alustetaan sopiviin arvoihin, jonka jälkeen prosessin suoritus voi alkaa. Esimerkiksi state-kenttään viedään arvo ready ja ympäristöpinoon konstruoidaan yksi talletettu ympäristö, jossa ohjelmalaskurin arvona on ohjelman ensimmäisen suoritettavan struct PCB { int process_id; // prosessin identiteetti enum { FREE, READY, RUN, WAIT } state; int priority, native_priority; // käyttö- ja perusprioriteetti int signal_number; // tulleen signaalin numero void (*signals) () [NUM_SIGNALS]; // signaalinkäsittelijät address saved_environment; // ympäristöpinon osoite }; Kuva 4.5 Prosessielementin kentät.

10 Prosessit ja säikeet 83 käskyn osoite ja jossa muistinhallintarekisterien arvot viittaavat prosessin muistialueeseen. Luonnollisin tapa prosessin käynnistämiseksi on määritellä käyttöjärjestelmäkutsu start, jonka parametrina annetaan käynnistettävän prosessin kuvan sisältävän tiedoston nimi. Toiminta on siis sellainen, että kutsu luo uuden prosessin (lapsiprosessin, child process), varaa sille oman muistialueen ja prosessin luonut prosessi (isäprosessi, parent process) jatkaa toimintaansa. Muitakin mahdollisuuksia on. Tietyissä tilanteissa on luonnollista, että isäprosessi jää odottamaan lapsiprosessin päättymistä; esimerkiksi komentotulkit tekevät yleensä näin. Toinen mahdollinen variaatio on sellainen, jossa lapsiprosessi jatkaakin isäprosessin ohjelmakoodin suoritusta. Osittain näiden vaihtoehtoisten tarpeiden takia liittyy Unix-maailmassa prosessien luomiseen kolme kutsua: fork, exec ja wait. Ensimmäinen näistä, fork, luo uuden prosessin ja kopioi sille isäprosessin muistin. Uusi prosessi jatkaa isäprosessin ohjelmakoodin suoritusta. Ainoa ero isän ja lapsen välillä on se, että kutsu fork palauttaa isäprosessille luodun lapsiprosessin numeron (joka on aina nollasta poikkeava luku) ja lapselle numeron nolla. Erityisesti on huomattava, että auki olevat tiedostot periytyvät lapselle. Luomisensa jälkeen uusi prosessi jatkaa siis isänsä ohjelmakoodin suoritusta. Tavallisesti fork-kutsu on ehtolauseessa, joten lapsiprosessi suorittaa tästä huolimatta eri osaa ohjelmakoodista kuin isä. Yleensä tämä lapsiprosessin koodi suorittaa kutsun exec, jolla vaihdetaan suoritettava ohjelmakoodi toiseksi. Edelleenkään prosessin avoimet tiedostot eivät muutu. Kolmas kutsu, wait, on isäprosessia varten. Jos isäprosessin tulee odottaa lapsiprosessin päättymistä, se käyttää tätä kutsua. Parametrina voi olla odotettavan lapsiprosessin numero, mutta parametrilla 1 odotetaan mitä tahansa lapsiprosessia. Kutsu palauttaa päättyneen lapsiprosessin statuksen eli exit-kutsun parametrin arvon. Haarautuminen tekevä ohjelmanpätkä voi näyttää esimerkiksi seuraavalta:

11 84 Sulautettu ohjelmointi int status, pid; if (!(pid = fork())) { // tämä suoritetaan, jos kyseessä on lapsiprosessi exec ("komento"); // komennon kutsu meni pieleen, tähän ei pitäisi koskaan päätyä; exit (EXIT_FAILURE); } status = wait (pid); // isä odottaa lapsiprosessin päättymistä Kolme erillistä kutsua mahdollistaa siis yhtä kutsua monipuolisemmat vaihtoehdot toiminnalle, joskin hieman monimutkaistaen normaalitoimintoa. Kolmen kutsun avulla on mahdollista toteuttaa helposti Unixeista tuttu tulostuksen ohjaus. Ottakaamme esimerkiksi Unix-komento who >kayttajat, joka tulostaa koneen sen hetkiset käyttäjät tiedostoon kayttajat. Toiminta tapahtuu seuraavasti: 1. Komentotulkki tunnistaa komennon sellaiseksi, että sen tulee herättää prosessi sitä käsittelemään. 2. Komentotulkki tekee itsestään kopion (fork-kutsulla) ja jää odottamaan lapsiprosessin päättymistä kutsulla wait. 3. Lapsikomentotulkki sulkee oletustulostustiedoston (stdout, cout, standard output), jonka se peri isältään, ja avaa tilalle tiedoston kayttajat. Nyt sen oletustulostus menee tiedostoon kayttajat. 4. Lapsikomentotulkki vaihtaa ohjemakoodinsa tilalle komennon who ohjelmakoodin kutsulla exec. 5. Komento who suoritetaan, ja tulostus menee tiedostoon kayttajat. Ohjelman päättyessä sen palauttama status menee isäkomentotulkille wait-kutsun paluuarvona. Unixien komentotulkeilla voidaan prosessi laittaa suoritukseen myös niin, että komentotulkki ei jää odottamaan käynnistetyn ohjelman suoritusta. Tämä tehdään laittamalla komennon loppuun &-merkki. Nyt komento who >kayttajat & toteutetaan muuten samalla tavalla kuin edellä on kuvattu, mutta kohdassa kaksi isäprosessi ei jää odottamaan herätettyä lasta Prosessin päättäminen Prosessin päättäminen ei periaatteessa ole kovin monimutkaista: suljetaan avoinna olevat tiedostot, vapautetaan resurssit ja viimeiseksi prosessielementti. Monimutkaisuutta tuo, jos käyttöjärjestelmässä pros-

12 Prosessit ja säikeet 85 essin päättymisstatus välitetään isäprosessille (edellä kutsut exit ja wait). Tämä ominaisuus aiheuttaa sen, että kuoleva prosessi ei voi täysin kuolla, ennen kuin se saa kerrottua isäprosessilleen lopetustilansa. Tämän takia lapsen prosessielementti jää varatuksi tilassa zombie 14, kunnes isäprosessi tekee kutsun wait. Jos isäprosessi itse päättyy ennen kuin se on lukenut lapsiprosessin statuksen, paluustatus kerrotaan isoisälle ja niin edelleen, kunnes päädytään siihen prosessiin, joka on kaikkien prosessien esi-isä (Unixissa init, prosessi numero 1, jonka päättyminen kaataa käyttöjärjestelmän). Tällaisessa ratkaisussa ei ole sellaista kutsua, jolla toinen prosessi voisi väkivaltaisesti päättää toisen prosessin. Koska tätä ominaisuutta kuitenkin tarvitaan, se on toteutettu signaalin KILL avulla (signaaleihin palataan kohdassa 4.2.6). Prosessin lopetustila voidaan välittää myös muulla tavalla: esimerkiksi Windows NT:ssä on säiekohtainen sanomakanava, jonka avulla tieto säikeen päättymisestä välitetään kiinnostuneille Ohjelmallisesti aiheutetut keskeytykset Joissain tilanteissa prosessi on pystyttävä keskeyttämään prosessin ulkopuolelta ohjelmallisesti. Prosessin välitön keskeyttäminen voi kuitenkin olla ongelmallista, sillä se voi olla parhaillaan suorittamassa jotain käyttöjärjestelmäkutsua tai muuta sellaista toimenpidettä, jota ei voi jättää kesken. Prosessia ei siis aina voida heti keskeyttää. Yksi ratkaisu on lähettää prosessille eräänlainen ohjelmallisesti aiheutettu keskeytys eli signaali (signal). Prosessi havaitsee signaalin seuraavan kerran run-tilaan päästessään tarkkaan ottaen havainnon tekee vuorontaja. Jos prosessi on kuitenkin suorittamassa ytimen koodia, voi vuorontaja viivästyttää signaalin aiheuttamista, kunnes prosessi poistuu ytimestä. Vastaavia tilanteita syntyy muissakin yhteyksissä. Esimerkiksi ohjelman suorituksessa tapahtuviin virhetilanteisiin voitaisiin liittää signaaleita (divide_by_zero, integer_overflow ja niin edelleen). Tällöin olisi hyödyllistä, että ohjelmoija voisi itse määritellä virheen tapahtuessa tapahtuvan toiminnon ohjelmassa voisi esimerkiksi olla kyseisestä virheestä toipumisen suorittava rutiini. Tämä voidaan toteuttaa siten, 14. Zombi (zombie) on voodoo-uskomuksissa esiintyvä elävä kuollut, eli taikuudella henkiinherätetty vainaja, joka tottelee tahdottomana herättäjäänsä. Carl Barksin (Aku Ankan piirtäjä) mukaan: Zombi on sellainen, jota ei ole, ja jos on, niin ei pitäisi olla.

13 86 Sulautettu ohjelmointi että kuhunkin signaaliin liittyy oletusarvoinen toiminta, mutta tarvittaessa voidaan määritellä myös oletusarvosta poikkeavia signaalinkäsittelyrutiineita (tämä on tosin syytä rajoittaa vain tiettyihin signaaleihin). Signaalin käsittelytapaan voidaan vaikuttaa kutsumalla rutiinia signal, jolle annetaan parametrina signaalin numero ja tieto siitä, miten signaali käsitellään. Arvoja voisivat olla esimerkiksi KILL: signaali aiheuttaa prosessin lopettavan rutiinin kutsun IGNORE: signaalilla ei ole mitään vaikutusta osoite: signaalin saapuessa kutsutaan osoitteesta alkavaa rutiinia. Signaali lähetetään toiselle prosessille rutiinilla kill. Tämä rutiini vie kohdeprosessin signal_number-kenttään aiheutettavan signaalin numeron. Signaalin käsittelyn aiheuttaa varsinaisesti vuorontaja, kun prosessi seuraavan kerran saa suoritinvuoron ja on suorittamassa sovellusohjelman koodia. Havaittuaan signal_number-kentässä signaalin numeron vuorontaja tarkastaa vielä signaalia vastaavan signals-taulukon alkion. Erikoisarvot 0 ja 1 tulkitaan toiminnoiksi kill ja ignore, muut arvot käsitellään muuttamalla prosessin talletettua ympäristöä siten, että RETI-käsky aiheuttaa siirtymisen signals-taulukosta saatuun osoitteeseen. Näin toteutettuna keskeytyksen vaikutus ei aina ole välitön, mutta kuitenkin useimmissa tapauksissa riittävän nopea. Aina mekanismi ei toimi, sillä joissain tilanteissa prosessi on voinut jäädä jonkin virheen takia ytimeen odottamaan jotain tapahtumaa, jota ei ikinä tule, jolloin signaaliakaan ei koskaan havaita. Signaalit ovat prosessikohtaisia. Mikäli järjestelmä skeduloi säikeitä eikä prosesseja, signaali voi mennä mille tahansa prosessin säikeistä. Tällöin suositellaan, että vain yhdellä säikeistä sallittaisiin signaalien vastaanotto, ja muut säikeet jäävät silloin rauhaan. Ongelmana tässä on, että signaali voi tulla esimerkiksi virheellisestä osoitteesta, jolloin voi olla melkoisen hankalaa selvittää, mikä säikeistä teki virheen. Joissain käyttöjärjestelmissä omaksuttu käytäntö pitää prosesseja ja säikeitä samoina asioina luonnollisesti ratkaisee tämän ongelman. 4.7 Suunnittelunäkökohtia Jokaiseen prosessiin ja säikeeseen liittyy käyttöjärjestelmän ytimen tietorakenteita. Lisäksi tarvitaan muistia aktivaatiopinoille ja ohjelman muuhun käyttöön. Siksi varsinkin kaikkein pienimpiä sulautettuja järjestelmiä toteutettaessa kannattaa yleensä pohtia huolellisesti, onko

14 Prosessit ja säikeet 87 uusi säie tai prosessi välttämätön, vai voisiko järjestelmä selvitä ilmankin. Joskus jopa ydin itse voi rajoittaa sallittujen säikeiden ja prosessien lukumäärää esimerkiksi pysyäkseen luvattujen muistirajojen puitteissa. Usein käytetty keino välttää ylenmääräistä säikeiden käyttöä on sarjallistaa tietyt tapahtumat, eli toisin sanoen pyrkiä toteuttamaan järjestelmä siten, että suoritus perustuu säikeiden ja niiden suoran kommunikoinnin sijaan eri tehtävien sarjalliseen suoritukseen. Tekniikkaa käytetään yleisesti käyttöliittymien ohjelmoinnin yhteydessä, jolloin kaikkia käyttöliittymän toimintoja voidaan palvella yhdellä säikeellä, ei siten, että jokainen elementti vaatisi oman palvelevan säikeensä, mutta sitä voidaan käyttää myös muihin tarkoituksiin. Tällöin säie toimii eräänlaisena sarjallistettujen tapahtumien vuorontajana. Toinen keskeinen näkökohta on, että prosessit ja säikeet voivat vaikuttaa toisiinsa sekä suoraan että epäsuorasti. Suora vaikuttaminen on yleensä ohjelmoijan kannalta selkeää, sillä se perustuu normaaleihin kommunikointimekanismeihin, kuten viestinvälitykseen ja jaettuun muistiin. Sen sijaan epäsuoran vaikutuksen kilpailu samoista resursseista, kuten muistista tai suoritusajasta huomiointi voi olla vaikeaa, sillä oireet vaihtelevat tilanteen mukaan melkoisesti. Virheiden jäljittämisen yksinkertaistamiseksi kannattaa usein toteuttaa omia rutiineja, joiden avulla ongelmia voidaan löytää mahdollisimman tehokkaasti. Rutiinit voidaan toteuttaa joko omana säikeenään, mikä luonnollisesti voi johtaa uusiin ongelmiin, tai sitten sisällyttää ne osaksi säiettä, jonka prioriteetti on matalin ja joka muutenkin yleensä ainoastaan kerää tietoa ohjelman suorituksesta. Se, voidaanko tällaisia rutiineja jättää tuoteversioon, vaihtelee järjestelmän tarkoituksesta, oletetusta loppukäyttäjästä ja monesta muusta yksityiskohdasta riippuen. 4.8 Yhteenveto Prosessit sisältää yhden tai useampia säikeitä saman osoiteavaruuden sisällä. Säie on pienin skeduloitava yksikkö, ja sillä on tilat run, ready ja wait. Näillä tiloilla voi olla alitiloja. Keskeytyksessä säikeen (prosessin) ympäristö (rekisterit ja tilasana) talletetaan ympäristöpinoon. Ajettava säie vaihdetaan vaihtamalla ympäristö toiseksi. Keskeytyksestä palattaessa palautetaan ympäristö.

15 88 Sulautettu ohjelmointi Keskeytyskäsittely voidaan keskeyttää. Käyttöjärjestelmäpyynnöt tehdään keskeytysmekanismin avulla. Säikeiden ja prosessien määrä voi olla rajoitettu järjestelmän toimesta. Erilaiset ohjelmakohtaiset virheenjäljitysrutiinit tavallisia.