6. Skedulointi eli vuoronnus

100 Sulautettu ohjelmointi 6. Skedulointi eli vuoronnus Skeduloinnin eli vuoronnuksen (scheduling) tehtävä voidaan tiivistää kysymykseen, miten seuraavaksi suoritukseen otettava prosessi valitaan. Valintaperusteita on useita, ja mitkä niistä kannattaa huomioida on usein tilannekohtaista. Yleisesti käyttöjärjestelmissä optimoidaan vastausaika, kokonaissuoritusteho (yksikkönä valmiita töitä tai reaktioita aikayksikköä kohti) ja reiluus (eli ei kauan odottavia töitä). Vaikka reaaliaikakäyttöjärjestelmissäkin nämä ominaisuudet ovat tärkeitä, erityisesti reiluus on helposti ristiriidassa sen vaatimuksen kanssa, että vastausajan vaihteluväli (niin sanottu jitter, huojunta) voidaan laskea etukäteen. Reaaliaikajärjestelmissä päätavoite usein onkin mahdollistaa reaaliaikavaatimusten toteuttaminen, eli siis sen varmistaminen, että järjestelmä kykenee suorittamaan kaiken tarpeellisen laskennan tehtävien aikarajojen asettamissa puitteissa. 6.1 Lyhyesti reaaliajasta Reaaliajalle (real time) on useita määritelmiä, jotka hieman poikkeavat toisistaan. Pohjimmaisena ajatuksena on aina kuitenkin se, että tapahtuman on tapahduttava oikeaan aikaan. Tämä tarkoittaa käytännössä sitä, että reaaliaikajärjestelmissä on tärkeää ajoituksen ennustettavuus. Tehtävän laskennan valmistumiselle annetaan tällöin ensimmäinen ja viimeinen sallittu ajanhetki. Tämä aikaikkuna esitetään usein suhteellisena johonkin tapahtumaan, "aktioon", johon järjestelmä tuottaa vasteen ("reaktio"). Joskus aikaikkunan lisäksi määritellään ensimmäinen ajanhetki, jolloin laskennan saa aloittaa. Syynä voi olla laskennan tarvitsemat lähtötiedot tai että sen välituloksetkin jo vaikuttavat järjestelmän toimintaan. Usein ajatellaan reaaliajan tarkoittavan mahdollisimman nopeaa vasteaikaa, mutta tämä määritelmä on liian suppea. Käytännössä ajastuksien avulla ongelmat voidaan redusoida tähän tai tätä muistuttavaan

Skedulointi eli vuoronnus 101 muotoon pyritään siis siihen, että skeduleri saa tehtäviä malliin "tee tämä niin pian kuin mahdollista". 6.1.1 Pehmeät ja kovat reaaliaikajärjestelmät Teknisesti on syytä jakaa reaaliaikajärjestelmät pehmeisiin ja koviin reaaliaikajärjestelmiin. Pehmeä reaaliaikaominaisuus tarkoittaa sitä, että tehtävällä on haluttu aikaikkuna, jossa sen tulee valmistua, mutta epäonnistuminen tässä ehdossa johtaa vain hieman huonompaan tai hitaampaan lopputulokseen, ei varsinaiseen virheeseen. Kova reaaliaikaominaisuus taas on sellainen, jossa ajoitukset ovat yhtä tärkeitä kuin asioita kuin järjestelmän muutkin ominaisuudet. Toisin sanoen aikarajojen rikkominen on virhetoiminta, joka pahimmillaan estää koko laitteen toimimisen tai jopa rikkoo sen. Esimerkki pehmeästä reaaliajasta on tilisiirto tililtä toiselle. Vaikka siirto viipyisi matkalla päivän odotettua kauemmin, on tärkeämpää, että raha siirtyy edes myöhässä kuin ei ollenkaan. Kovaa reaaliaikaa edustaa esimerkiksi matkapuhelin, joka lähettää puheen aikajaetulla kanavalla tukiasemalle. Mikäli puhelimen ajastukset eivät toimi, viestiä ei saada vastaanotettua, ja lisäksi muidenkin puhelimien yhteydet voivat häiriintyä. Siksi jos viestiä ei voida lähettää juuri oikeaan aikaan, on parempi, että sitä ei lähetetä lainkaan, jotta muut verkossa olevat laitteet eivät häiriintyisi. Yksi kovan reaaliajan tavanomaisista tunnusmerkeistä ei tosin välttämätön onkin se, että mikäli toimintaa ei voida tehdä annetuissa rajoissa, on se parempi jättää kokonaan tekemättä. Pehmeällä reaaliajalla sen sijaan ei tätä ominaisuutta ole, vaan yleensä kaikki tehtävät tulee suorittaa loppuun saakka viime kädessä aikataulun kustannuksella. Kovalle reaaliajalle on myös tunnusomaista, että aikarajan määrää jokin järjestelmän ulkopuolinen asia. Kyseessä voi olla kuten yllä olevassa esimerkissä standardin määräys, laitteen fyysistä ominaisuuksista tuleva vaatimus, lainsäädäntö ja niin edelleen. 6.1.2 Reaaliaikaohjelmien tyypillisiä piirteitä Reaaliaikajärjestelmät ovat usein reaktiivisia, mikä tarkoittaa sitä, että ne reagoivat useista eri lähteistä tuleviin ärsykkeisiin ainakin näennäisesti yhtä aikaa. Lisäksi aikavaatimukset edellyttävät, että riippumatta siitä, mitä palvelupyyntöjä on kesken, niihin kaikkiin vastataan jokaisen pyynnön omien reaaliaikavaatimusten mukaisesti. Tyypillisesti useimmat sulautetut järjestelmät ovat sekä reaktiivisia että reaaliaikaisia.

102 Sulautettu ohjelmointi Tyypillistä on myös se, että prosessien lukumäärä ja tehtävät ovat vakioita ja suhteellisen hyvin tunnettuja. Samoin yksittäisten prosessien tarvitsema aika on suhteellisen hyvin tiedossa. Näistä johtuen sulautettujen järjestelmien suunnitteluvaiheessa voidaan normaalijärjestelmää todennäköisemmin arvioida tai jopa ääritapauksessa laskea se, täyttääkö järjestelmä sille annetut aikavaatimukset vai ei. 6.1.3 Milloin järjestelmä on reaaliaikainen? Järjestelmä on reaaliaikainen, mikäli sen vasteajat (minimi ja maksimi) voidaan aina laskea. Tämä lienee kuitenkin niin abstrakti määritelmä, että suunnittelun lähtökohdaksi se ei sovi hyvin. Siksi käytännön vastaus kysymykseen voisi olla vaikkapa seuraava: Järjestelmä on reaaliaikainen, jos ajossa olevan prosessin prioriteetti on suurempi tai yhtä suuri kuin minkään ajovuoroa odottavan prosessin. Käänteisprioriteettiongelman (alakohdassa 6.4.1 sivulla 112) takia tähän tulee lisätä vielä sellainen ehto, että prosessin ei pidä joutua odottamaan sitä, että sitä alhaisemmalla prioriteetilla oleva prosessi vapauttaa resurssin. Yksi tapa hoitaa tämä on muuttaa varaavan prosessin prioriteettia väliaikaisesti yhtä suureksi kuin mikä on korkeimmalla prioriteetilla olevalla odottajalla. Käytännössä täydellinen täsmällisen ennustettava reaaliaikaisuus on lähes mahdotonta. Esimerkiksi keskeytysten estäminen viivästyttää korkeaprioriteettista prosessia, jolloin edellä olevat ehdot eivät ihan aina päde. 6.2 Irrottamaton ja irrottava skedulointi Irrottamaton ja irrottava skedulointi kuvaavat periaatepäätöstä siitä, voiko parhaillaan suorituksessa olevan prosessin (tai säikeen) vaihtaa toiseksi ilman prosessin omaa pyyntöä. Näistä kahdesta skedulointiperiaatteesta irrottamaton on yleensä sekä skedulerin toteutuksen että sovelluksen ohjelmistosuunnittelun kannalta yksinkertaisempi muoto. Siinä ajossa olevaa prosessia ei koskaan vaihdeta toiseen, ellei prosessi itse anna siihen lupaa joko eksplisiittisesti (kutsu operaatiota yield() tai jotain vastaavaa) tai implisiittisesti (palvelupyyntö, jota jäädään odottamaan). Irrottavassa skeduloinnissa prosessi voidaan vaihtaa toiseen, mikäli skeduleri niin haluaa kesken prosessin suorituksen, eikä prosessi voi vaikuttaa asiaan välttämättä mitenkään. Kaikissa irrottavissa ympäristöissäkin vaihto kuitenkin liittyy oikeastaan aina johonkin lait-

Skedulointi eli vuoronnus 103 teiston tai ohjelmiston tapahtumaan, kuten keskeytykseen, jonka jälkeen joku toinen prosessi valitaan suoritukseen esimerkiksi siksi, että sen suoritus tuli mahdolliseksi keskeytyksen seurauksena, tai siksi, että parhaillaan suorituksessa oleva prosessi sai jo oman osansa suoritusaikaa ja on jonkin toisen prosessin vuoro. On lähes ilmiselvää, että irrottamattomalla skeduloinnilla on hyvin vaikea tehdä mielivaltaisia reaaliaikasovelluksia, ja vastaantulevat ongelmat lähestyvät nopeasti mahdottomia. Toisaalta irrottamaton skedulointi ratkaisee lähes automaattisesti poissulkemisongelman 17, kun prosessit eivät pääse käsittelemään samaa tietoa yhtä aikaa. Samaten irrottamaton skedulointi on yleensä helpompaa testata ja sen ongelmatilanteet on helpompi jäljittää ja jopa toistaa. Niinpä jopa reaaliaikajärjestelmissä on usein ainakin osittain käytössä myös irrottamaton skedulointi. Irrottava skedulointi on kuitenkin päävaihtoehto aivan harvinaisimpia järjestelmiä lukuunottamatta. Joskus kuitenkin joko ongelman tai toteutukseen valitun teknologian ominaisuudet voivat vaatia muunlaista lähestymistapaa. Jotkut toteutukset mahdollistavat sekä irroittamattoman että irroittavan skeduloinnin käytön, esimerkiksi siten, että säikeet skeduloidaan prosessin sisällä irroittamattomasti, mutta suorituksessa olevat prosessit irroittavasti. 6.3 Skedulointimenetelmiä Skeduloinnilla tai vuoronnonnuksella (scheduling) tarkoitetaan menetelmää (algoritmia), jolla valitaan seuraavaksi suoritettava säie, prosessi tai työ. Yleisesti skeduloinnin tavoitteena on järjestelmän suorituskyvyn optimointi. Tässä yhteydessä järjestelmän kokonaissuoritusteholla (throughput) tarkoitetaan tavallisesti suoritettuja tehtäviä aikayksikköä kohti. Tehtävä voi tässä tarkoittaa tilanteesta riippuen esimerkiksi yhtä interaktiota käyttäjän kanssa (ikkunoitu käyttöliittymä) tai tietokantaoperaatiota (suuret tietojärjestelmät). Koska nykykäytössä monet prosessit ovat pitkiä seinäkelloajaltaan ja sulautetuissa järjestelmissä ne usein eivät pysähdy ennen kuin koko laite sammutetaan, on järkevää valita sellainen tehokkuusindikaattori, joka on kyseisessä ympäristössä mielekäs. Tämä taas johtaa siihen, että erityyppisten järjestelmien keskinäisestä vertailusta tulee kovin vaikeaa. 17. Tyhmyyksien tekeminen on toki mahdollista, mutta koska ne kohdat, joissa prosessi voi vaihtua, tunnetaan, poissulkemisen hallinta yksinkertaistuu merkittävästi.

104 Sulautettu ohjelmointi Skeduloinnin liikkumavara on erilainen erätöiden 18, osituskäytön ja reaaliaikajärjestelmien tapauksissa: Erätöiden osalta järjestelmä voi suhteellisen vapaasti keskittyä optimoimaan järjestelmän kokonaissuoritustehoa. Osituskäytön yhteydessä (esimerkiksi ikkunoitu käyttöliittymä) on otettava huomioon käyttäjän kokemat odotusajat: skeduloinnin on tapahduttava siten, että kaikki käyttäjät tai saman käyttäjän kaikki sovellukseet saavat suunnilleen samantasoista palvelua optimoitavana suureena voi olla esimerkiksi keskimääräinen vasteaika. Reaaliaikajärjestelmissä suunnittelun pääpaino on siinä, että järjestelmän vasteajat pysyvät mahdollisimman ennustettavina. Käytännössä tämä rajaa pois ajonaikaiset prioriteetin vaihdokset ja vastaavat. Varsinaisen optimoinnin lisäksi usein suotava ominaisuus skedulointimenetelmälle on reiluus (fairness): mikään prosessi tai työ ei saisi jäädä odottamaan vuoroaan ikuisesti tai edes hyvin pitkäksi aikaa. Tarkastelemme seuraavaksi joitain prosessien ja säikeiden skedulointimenetelmiä. Seuraavassa sanalla säie tarkoitetaan pienintä skedulointavaa yksikköä, oli sen nimi käyttöjärjestelmässä mikä tahansa. Menetelmän kuvauksen lisäksi tarkastelemme neljää ominaisuutta: reiluutta, kokonaissuoritustehoa, vasteaikaa sekä reaaliaikaisuutta. Tarkastelussa siirräntäsidonnaisilla säikeillä tarkoitetaan sellaisia säikeitä, jotka tekevät suhteellisen usein siirräntäpyyntöjä käytettyyn suoritinaikaan nähden. Esimerkiksi editori on suurimman osan aikaa odottamassa käyttäjältä tulevaa syötettä. Suoritinsidonnaisia taas ovat sellaiset säikeet, jotka käyttävät runsaasti suoritinaikaa, kuten monet teknisen laskennan ongelmat. 6.3.1 FIFO eli jono FIFO-menetelmä (first in first out, myös FCFS, first come first served) on itse asiassa jono. Siinä säikeet otetaan suoritukseen siinä järjestyksessä, jossa ne saapuvat ready-tilaan (kuva 6.1). Menetelmän hyviä puolia ovat muun muassa periaatteellinen reiluus ja yksinkertainen toteutus. Haittapuolena on muun muassa se, että suoritinsidonnaiset säikeet viivyttävät tarpeettomasti siirräntäsidonnaisten säikeiden etene- 18. Erätyöt ovat nykyään harvinaisia, sulautetuissa järjestelmissä niitä ei käytännössä ole. Siksi aihe sivuutetaan maininnalla tässä yhteydessä.

Skedulointi eli vuoronnus 105 Wait-tilaan Wait-tilasta Run-tilassa Pros. 1 Kuva 6.1 mistä, mikä näkyy huonona vasteaikana interaktiivisilla säikeillä. Koska kokonaissuoritusteho on suurimmillaan, mikäli suoritetaan ensin kaikista pienimmät tehtävät, menetelmä ei tuota senkään suhteen optimaalista tulosta. Lisäksi ikuinen silmukka saa aikaan muiden säikeiden pysähtymisen, mikäli oletetaan yksinkertaisin mahdollinen irroittamaton toteutus. Siksi reaaliaikaominaisuuksen osalta menetelmä on käytännössä mahdoton. Varsinaisessa säikeiden skeduloinnissa puhdas jonoalgoritmi on harvinainen, mutta epäsuorasti se vaikuttaa usein skedulointiin. Esimerkkinä mainittakoon vaikkapa viestinvälitys tai oheislaitteelle annetut tehtävät, jotka usein palvellaan siinä järjestyksessä kuin ne on oheislaitteelle lähetetty. Jonomallia käytettäessä skeduleri voidaan pitää hyvin yksinkertaisena, sillä suoritukseen päästyään tehtävä suoritetaan loppuun asti. Tästä syystä irroittamaton skeduleri riittää toteutukseksi. Jos jonoperustaiseen skedulointiin lisätään irroittavuus ja tietty määrä reiluutta, muuttuu menetelmä kiertovuorotteluksi. 6.3.2 Kiertovuorottelu Pros. 2 Pros. 3 Pros. 4 FIFO, ensiksi jonoon, ensiksi palveluun. Kiertovuorottelu (round robin, RR) toimii kuin FIFO, mutta säie saa olla run-tilassa yhtäjaksoisesti korkeintaan sille annetun aikaviipaleen (time slice) määräämän ajan (kuva 6.2). Tosin sanoen FIFO on irrottamaton menetelmä ja kiertovuorottelu muilta ominaisuuksiltaan FIFOa vastaava irrottava skedulointimenetelmä. Tyypillinen aikaviipaleen koko voisi olla esimerkiksi 10 100 ms. Menetelmän hyvä puoli on sen reiluus: kaikki säikeet saavat vuorollaan aikaviipaleensa. Jos aikaviipale on suhteellisen lyhyt, siirräntäsidonnaiset prosessit eivät joudu kärsimään suoritinsidonnaisten töiden hitaasta etenemisestä run-tilassa. Ohjelmoijan kannalta kiertovuorottelu on melko yksinkertaista sikäli, että jokainen (saman prioriteetin omaava) prosessi saa suoritusai-

106 Sulautettu ohjelmointi kaa, kunhan se vain laitetaan ajoon. Sen sijaan ennustettavuuden kannalta menetelmässä on ilmeisiä ongelmia, jos prosessien määrä voi kasvaa suorituksen aikana jokainen niistä saa vuorollaan viipaleen suoritinaikaa, joten lukumäärän muuttuessa muuttuu myös se, miten usein oma viipale saadaan. Näin menetelmä ei sovi hyvin reaaliaikaratkaisuihin. Puhtaimmillaan kiertovuorottelussa ei käytetä lainkaan prioriteetteja, mutta monessa käytännön toteutuksessa sellaiset ovat mukana. Tämä johtaa seuraavana esiteltävän kiinteän prioriteetin ja kiertovuorottelun yhdistelmään, jossa suorituksessa on aina tehtävä, jonka prioriteetti on korkein, mutta jos usealla tehtävällä on sama prioriteetti, tehtäviä suoritetaan vuorotellen. 6.3.3 Kiinteä prioriteetti Kiinteä prioriteetti (fixed priority) tarkoittaa skedulointimenetelmää, jossa suoritukseen valitaan se säie, jolla on korkein prioriteetti (kuva 6.1), eikä skedulointimenetelmä muuta tätä prioriteettia 19. Vaikka menetelmää voidaan käyttää myös irrottamattomassa skeduloinnissa, käytännössä se yhdistetään irrottavaan skedulointiin. Tällöin siitä voidaan käyttää lyhennettä FPPE (fixed priority pre-emptive scheduling). Menetelmä on yksinkertainen toteuttaa, ja se mahdollistaa säikeiden tärkeysjärjestyksen määrittämisen. Järjestelmän kokonaissuoritustehon ja vasteaikojen minimoimiseksi siirräntäsidonnaisilla säikeillä tulee olla suoritinsidonnaisia korkeampi prioriteetti. Menetelmän haittapuolena on se, että se ei ole reilu. Alhaisen prioriteetin säikeet voivat nälkiintyä (starve), sillä korkeaprioriteettiset säikeet voivat aina ohittaa ne ready-tilassa. Pohjimmiltaan algoritmi siis takaa, Wait-tilaan Wait-tilasta Run-tilassa Aikaviipale loppui Säie1 Säie 2 Säie 3 Säie 4 Kuva 6.2 Kiertovuorottelu. 19. Ohjelman prioriteetti voi silti muuttua muista syistä.

Skedulointi eli vuoronnus 107 että suoritin suorittaa aina sitä säiettä, jolla on korkein prioriteetti niistä säikeistä, jotka ovat valmiina suoritettavaksi. Tästä syystä algoritmi soveltuu hyvin myös reaaliaikajärjestelmien toteuttamiseen. Skedulointi voi tapahtua kahdella eri tavalla. Jotkut toteutukset saattavat suorittaa skeduloinnin siinä yhteydessä, kun uusi säie tulee suoritettavien säikeiden joukkoon. Toinen algoritmin vaihtoehto on kellokeskeytyksen avulla toimiva aikaviipalointi (time slicing), jonka tarkoitus on taata, ettei mikään säie voi käyttää kaikkea suoritinaikaa. Toisin sanoen ajossa oleva säie saa maksimissaan yhden aikaviipaleen verran suoritusaikaa, jonka jälkeen suoritus pysäytetään, ja skedulointi suoritetaan uudelleen. Kumpikin menetelmistä on irrottava, mutta jälkimmäinen ei sovellu erittäin nopeaa vasteaikaa vaativiin reaaliaikajärjestelmiin. Ilman kellokeskeytystä ja ilman automaattista uudelleenskedulointia uusien tehtävien tullessa mahdolliseksi algoritmista voidaan rakentaa irroittamaton versio. Tällöin tehtävä suoritetaan aina loppuun saakka riippumatta siitä, onko muita prosesseja tullut suoritettavaksi. Mikäli uudet sovellukset saavat tarpeeksi matalan prioriteetin, algoritmi mahdollistaa myös uusien tehtävien lisäämisen järjestelmään ilman, että korkeaprioriteettisemmat tehtävät kärsivät. Tästä syystä toteutuksen eteneminen voi olla inkrementaalista kohtuullisen helposti. Toisaalta tämä voi olla jossain mielessä huono peruste valita algoritmi, Wait-tilaan Run-tilassa Säie 1 Wait-tilasta prioriteetin mukaiseen paikkaan Säie 2 Nouseva prioriteetti Säie 3 Säie 4 Kuva 6.3 Kiinteä prioriteetti.

108 Sulautettu ohjelmointi Wait-tilaan Run-tilassa Säie 1 Wait-tilasta (ehkä muuttuneen) prioriteetin mukaiseen paikkaan Säie 2 Nouseva prioriteetti Kuva 6.4 Säie 3 Säie. 4 Vaihteleva prioriteetti. Prosessien järjestys voi jonotusaikana muuttua: prioriteetti vaihtuu sillä sulautettuja järjestelmiä rakennettaessa pitäisi yleensä pyrkiä kokonaisuuden kannalta tehokkaimpaan ratkaisuun. 6.3.4 Vaihteleva prioriteetti Vaihteleva prioriteetti (dynamic priority) ei itse asiassa ole yksi ainoa menetelmä, vaan joukko erilaisia menetelmiä, jossa menetelmä muuttaa säikeen prioriteettia ajan funktiona. Itse säikeen valinta tapahtuu kuin kiinteässä prioriteetissa sitten, kun prioriteetit on laskettu (kuva 6.4). Yksi tunnetuimmista vaihtelevan prioriteetin menetelmistä on perinteinen Unixien skedulointimenetelmä. Menetelmä yrittää havaita I/O-sidonnaiset säikeet ja nostaa niiden prioriteettia. Vastaavasti suoritinsidonnaisten säikeiden prioriteettia voidaan pienentää. Tämä lisää yleensä järjestelmän kokonaissuoritustehoa, parantaa vasteaikaa ja poistaa nälkiintymismahdollisuuden: mikäli säie ei saa aikaa, sen prioriteettia nostetaan, mistä seuraa, että se ennen pitkää saa aikaa. Reaaliaikajärjestelmän skedulointimenetelmäksi tästä ei kuitenkaan ole, sillä ennustettavuus on heikko. Edellä kuvattu menetelmä voidaan toteuttaa seuraavasti. Perusmenetelmänä on irrottava vaihtelevan prioriteetin skedulointi, jossa pieni lukuarvo tarkoittaa suurta prioriteettia. Prioriteetin vaihtaminen tehdään siten, että kellokeskeytyskäsittelijä laskee kaikkien sovellusprosessien prioriteetit uudelleen kerran sekunnissa. Sovellusten prioriteet-

Skedulointi eli vuoronnus 109 tien määräämiseen liittyvät toimenpiteet kellokeskeytyksen yhteydessä ovat seuraavat: Kellokeskeytyksen tullessa kasvatetaan aktiivisena olleen prosessin kellokeskeytyslaskuria. Kellokeskeytyslaskuri ilmaisee siis sen, montako kertaa kello on keskeyttänyt tämän prosessin kuluvan sekunnin aikana. Kerran sekunnissa lasketaan uusi prioriteetin arvo lisäämällä perusprioriteettivakioon (esimerkiksi 100) prosessikohtainen kellokeskeytyslaskuri ja nollataan prosessin kellokeskeytyslaskuri. Toisin sanoen prosessi, joka on (todennäköisesti) kuluttanut eniten suoritinaikaa, saa pienimmän prioriteetin. Perusprioriteettia suuremmat prioriteetit (eli tässä 0 99) on varattu käyttöjärjestelmän prosesseille ja ytimen rutiineille. Monissa järjestelmissä prioriteetin määräytyminen on vieläkin dynaamisempaa: esimerkiksi Microsoft Windows NT -sukuisissa käyttöjärjestelmässä käyttäjäprosessien prioriteettia kasvatetaan wait-tilasta poistuttaessa ja pienennetään, jos säie on käyttänyt saamansa aikaviipaleen loppuun. Vaihtelevan prioriteetin menetelmistä käydään läpi vielä kaksi: lyhin ajoaika ensin- ja aikaisin määräaika ensin -menetelmät. 6.3.5 Lyhin ajoaika ensin Melko suoraviivainen vaihtelevan prioriteetin skedulointialgoritmi lyhin ajoaika ensin (shortest remaining time, SRT) käyttää lähtökohtana sitä, kuinka paljon aikaa on säikeen odotettuun valmistumisaikaan (kuva 6.5). Tämä algoritmi siis palvelee ensin ne säikeet, joiden oletettu valmistumisaika on lyhyt. Puhtaimmillaan menetelmä vaatii irroittavan skeduloinnin käyttöä, sillä on mahdollista, että järjestelmään tulee uusi säie, jonka oletettu kesto on vielä lyhyempi kuin parhaillaan käynnissä olevan säikeen. Tällöin käynnissä oleva säie keskeytetään, ja ryhdytään suorittamaan uutta säiettä. Normaalitilanteessa tämä on kuitenkin melko harvinainen tapahtuma sulautetussa ympäristössä, ja siksi säikeen vaihtaminen on tarpeellista yleensä vain silloin, kun suorituksessa oleva säie saadaan valmiiksi. Toisaalta ytimen ja järjestelmän kokonaisuuden kannalta on kuitenkin varauduttava myös monimutkaisempiin vaihtoehtoihin, jos uusien säikeiden esittely on mahdollista.

110 Sulautettu ohjelmointi Wait-tilaan Run-tilassa Säie 1 Jonoon oletetun keston mukaiseen paikkaan Säie 2 Nouseva prioriteetti Säie 3 Kuva 6.5 Säie 4 SRT, lyhin ajoaika ensin. Koska skeduloinnin laskemiseksi on tunnettava säikeiden ominaisuudet melko tarkasti, tätä skedulointia voidaan käyttää oikeastaan vain sellaisissa ympäristöissä, joissa tehtävien laskenta-ajat tunnetaan hyvin. Sulautettujen järjestelmien tapauksessa kyseeseen tulevat erityisesti pienehköt järjestelmät, joiden ohjelmisto on suljettu käyttäjän tekemiltä laajennoksilta. 6.3.6 Aikaisin määräaika ensin Kolmannen vaihtuvaprioriteettisen menetelmän, aikaisin määräaika ensin -skeduloinnin (earliest deadline first, EDF), ideana on valita ajoon se säie, jonka pitää valmistua ensimmäisenä. Algoritmi toimii melko hyvin silloin, kun säikeiden ajoajat ovat suunnilleen samansuuruisia, mutta voi johtaa ongelmiin silloin, kun tehtävien pituus vaihtelee voimakkaasti. Koska aikarajoihin perustuva skedulointi on helppo laskea (itse asiassa säikeitä voidaan pitää tietorakenteessa, joka on järjestetty aikarajojen mukaisesti), algoritmin suoritus toisin sanoen suoritukseen valittavan prosessin etsiminen on tyypillisesti melko nopea operaatio. Aikaisin määräaika ensin -algoritmi on ohjelmoijan kannalta sangen suoraviivainen, ja se soveltuu hyvin reaaliaikaisten järjestelmien to-

Skedulointi eli vuoronnus 111 teuttamiseen. Skeduloinnin varmistamiseksi joudutaan tosin usein tekemään tarkkoja analyysejä eri tehtävien kestoista, mutta tämä on välttämätöntä oikeastaan aina, kun halutaan ylipäätään olla varmoja järjestelmän skeduloituvuudesta. Algoritmi ei kuitenkaan vaadi niin tarkkaa ajoituksen tuntemista kuin edellinen SRT-algoritmi. Koska uusien säikeiden tai oikeastaan uusien määräaikojen lisääminen vaikuttaa skedulointiin merkittävästi, yleensä tämäntyyppiset järjestelmät ovat suljettuja, eli näihin ei voi lisätä jälkeen päin uusia säikeitä. 6.3.7 Skedulointialgoritmien vertailua Käytännön skedulointimenetelmät ovat yleensä yhdistelmiä eri menetelmistä, joskaan kahta jälkimmäistä ei juuri voi yhdistää muihin. Tavallinen yhdistelmä on käyttää käyttöjärjestelmän säikeille kiinteitä, yleensä korkeita, prioriteetteja. Käyttäjän säikeiden osalta sovelletaan vaihtelevaa prioriteettia Unixin tapaan ja lisäksi usein kiertovuorottelua samalla prioriteetilla olevien säikeiden kesken. Yhteenveto algoritmien ominaisuuksista on koottu taulukkoon 6.1. Säikeiden skedulointi on tavallisesti irrottavaa (pre-emptive), jolloin säie voi joutua run-tilasta takaisin ready-tilaan. Tämä ei tietenkään koske FIFO-menetelmää. Symbianin aktiivioliot ovat itse asiassa käyttäjätilan säikeitä, joihin sovelletaan irrottamatonta skedulointia. 6.4 Reaaliaikajärjestelmien skedulointi Käytännön reaaliaikajärjestelmissä skedulointi perustuu usein kiinteään prioriteettiin. Tämän skedulointimenetelmän oletuksena on, että työlle annettu prioriteetti on riittävä järjestelmän ajoittamiseksi. On siis vain suorittimesta kiinni, valmistuvatko työt ajoissa. Prioriteettiin siis kiteytetään tieto siitä, milloin prosessin pitää valmistua, paljonko laskentaan kuluu aikaa ja niin edelleen suhteutettuna muihin prosesseihin. Monissa käytännön tilanteissa tämä tieto saadaan riittämään, jos suorittimessa on tarpeeksi suoritustehoa (tarkoittaa reaaliaikajärjestelmien yhteydessä yleensä sitä, että suoritin tekee työtä korkeintaan 70 % ajasta).

112 Sulautettu ohjelmointi Taulukko 6.1: Skedulointialgoritmien ominaisuuksia Algoritmi Reilu Suoritusteho a Vasteaika Reaaliaika Nälkiintyy FIFO On Matala, jopa huono Pitkä Ei Ei Kiertovuorottelu, RR Kiinteä prioriteetti, FPPE Vaihtuva prioriteetti (Unix) Lyhin ajoaika ensin, SRT Aikaisin ensin, EDF On Matala Pitkä Ei Ei Ei Keskitasosta korkeaan Vaihtelee prioriteetin mukaan. On Korkea Interaktiivisilla töillä lyhyt. Kyllä Ei Kyllä On Korkea Keskitaso Ei Kyllä On Keskitaso Keskitaso Kyllä Kyllä b Ei a. Tarkoittaa valmistuneita operaatioita aikayksikköä kohti. b. EDF-algoritmin johtaessa nälkiintymiseen on kyseessä joko tällä algoritmilla skeduloitumaton tehtäväjoukko tai sitten mukana on tehtävä, jolle ei ole asetettu aikarajaa lainkaan. 6.4.1 Käänteisprioriteettiongelma Vaikka käytössä olisi periaatteessa kiinteän prioriteetin järjestelmä, on käänteisprioriteettiongelman (priority inversion) takia on prioriteetteja käytännössä vaihdettava. Käänteisprioriteettiongelmassa korkeaprioriteettinen säie joutuu odottamaan matalaprioriteettista, vaikka näin ei pitäisi koskaan olla irrottavassa kiinteän prioriteetin skeduloinnissa. Käänteisprioriteettiongelman syntymiseen tarvitaan vähintään kolme säiettä, joilla on matala, keskitaso ja suuri prioriteetti (jatkossa MP, KP, SP). Näiden lisäksi on olemassa jokin yhteinen resurssi, jota tarvitsee sekä SP että MP. Tällainen resurssi voi olla mikä tahansa poissulkemista vaativa asia kuten kriittinen alue. Ongelma syntyy seuraavasti:

Skedulointi eli vuoronnus 113 1. MP varaa kriittisen alueen ja alkaa suorittaa sitä. 2. KP aktivoituu, jolloin se irrottavan skeduloinnin takia pääsee ajoon ja estää MP:n etenemisen. MP siis pysähtyy keskelle kriittistä aluetta. 3. SP aktivoituu ja saa heti ajovuoron, mutta yrittää päästä kriittiselle alueelle. 4. Koska MP on kriittisellä alueella, SP jää odottamaan kriittisen alueen vapautumista. 5. KP saa ajovuoron, koska se on ready-tilassa olevista säikeistä korkein. Näin SP odottaa käytännössä KP:tä, joka ei varaa mitään yhteistä resurssia, eikä sen pitäisi estää SP:n etenemistä. Käytännön toteutuksissa toimitaan esimerkiksi siten, että resurssin varaamisen eli kriittiselle alueelle tulon yhteydessä nostetaan resurssin varanneen säikeen prioriteetti yhtä korkeaksi kuin mikä on korkeimman resurssia jonottavan säikeen prioriteetti. Menetelmää kutsutaan joskus nimellä prioriteettikatto (priority ceiling). 6.4.2 Kerran tehtävät ja toistuvat työt Skeduloinnin kannalta toistuva (periodic) työ on helpompi hallita kuin satunnaisesti ilmaantuva työ (sporadic). Toistuva työ toistuu säännöllisin väliajoin P. Sille pätee yleisesti, että edellinen työ on saatava valmiiksi, ennen kuin työ aktivoituu uudelleen. Eli vähän formaalimmin: Ai + 1 Di Di + 1 Ai + 1 + P missä A on saapumisaika järjestelmään (arrival time) ja D määräaika (deadline), eli aika, jolloin työn (joskus käytetään myös termiä tehtävä) pitää olla valmis. Mikäli järjestelmässä on vain säännöllisesti toistuvia töitä, on skeduloinnin laskeminen suhteellisen helppoa. Lisäksi tähän tarkoitukseen on olemassa myös useita työkaluja, joiden avulla järjestelmän skeduloituvuutta voidaan tarkastella. Tällaisesta skeduloinnista käytetään nimitystä rate monotonic scheduling, RMS. Satunnainen työ on reaaliaikaskeduloinnin kannalta ongelma, koska sen tuloaikaa ei tiedetä. Mitä useampia satunnaisia töitä järjestelmässä on, sitä vaikeampi on näyttää, että järjestelmän ajoitukset varmasti toimivat yleensä täysin riippumatta siitä onko järjestelmässä käytössä staattinen vai dynaaminen skedulointi.

114 Sulautettu ohjelmointi Joskus tilannetta pyritään yksinkertaistamaan siten, että satunnaiset työt skeduloidaan suoritettavaksi erityisen niille tarkoitetun, periodisesti skeduloidun tehtävän paikalla. Tällä tavoin skeduloituvuuden tarkasteluja voidaan yksinkertaistaa melkoisesti. Huono puoli on, että satunnaisten tehtävien suoritusaika voi vaihdella. Lisäksi se, milloin tehtävä skeduloidaan suoritukseen, voi olla huomattavasti myöhemmin kuin mitä se olisi valmis suoritettavaksi, sillä sitä ennen voidaan joutua suorittamaan muita satunnaisia tehtäviä. 6.4.3 Jitter Reaaliaikajärjestelmien kannalta usein käytetty termi on jitter (suomeksi vapina, huojunta, värinä tai muu sellainen). Termiä käytetään kuvaamaan ei-toivottua poikkeamaa esimerkiksi perättäisten pulssien aikaväleissä. Usein kyse on siitä, että tapahtumien taajuus on keskimäärin vakio, mutta yksittäisten tapahtumien ajallinen etäisyys esimerkiksi milloin eri työt skeduloidaan suoritukseen tai milloin niiden suoritus valmistuu vaihtelee hieman. Koska ajastuksiin liittyvät ongelmat ovat vaikeita ratkaistavia rinnakkaisissa järjestelmissä, joudutaan joskus ottamaan kantaa myös järjestelmän maksimijitterarvoihin. Tämä on luonnollisesti yleisempää silloin, kun ollaan tekemisissä kovien reaaliaikajärjestelmien kanssa, joissa pienetkin ajastusvirheet voivat olla merkittäviä. 6.4.4 Staattinen skedulointi Staattisen skeduloinnin idea on laskea skedulointi etukäteen. Tämän laskennan hyviksi puoliksi voidaan laskea muun muassa seuraavat asiat: prosessin valitseminen ajoaikana nopeaa, töiden jako eri suorittimille (hajautus) on staattisen skeduloinnin yleinen erikoistapaus, ja kun skedulointi on laskettu valmiiksi, voidaan taata järjestelmän reaaliaikaominaisuudet. Haittapuolena staattisessa skeduloinnissa on se itsestäänselvyys, että laskenta on suunniteltava kokonaisuudessaan etukäteen, joten tarvitaan tarkkaa tietoa prosesseista ja niiden tarvitsemista laskenta-ajoista. Toisaalta staattista skedulointia hyödyntäen voidaan yleensä suorittimen käyttöaste nostaa korkeammaksi kuin mitä muita menetelmiä käyttäen on mahdollista. Koska kaikki on etukäyteen laskettu, myös ennustettavuus ja toistettavuus on korkealla tasolla. Tämä puolestaan yksinkertaistaa testausta ja kokonaisjärjestelmän toiminnan verifiointia

Skedulointi eli vuoronnus 115 merkittävästi, sillä suorituksen toistaminen täysin samanlaisena on usein mahdollista. Staattista skedulointia kutsutaan optimaaliseksi, mikäli se pystyy skedulointiin aikarajojen puitteissa aina, kun jokin toinenkin staattinen algoritmi siihen pystyy. Mitään tarkempaa yleistä ehtoa optimiskeduloinnille ei pystytä esittämään. 6.4.5 Dynaaminen skedulointi Useimmat staattisen skeduloinnin optimiratkaisut eivät ole optimiratkaisuja dynaamisessa järjestelmässä. Lisäksi monisuoritinjärjestelmissä ei irrottavalle skeduloinnille ole optimiratkaisua, jos tehtävien saapumisaikoja ei tiedetä etukäteen. Koska dynaaminen skedulointi tehdään kokonaisuudessaan ajon aikana, kovin monimutkaista järjestelmää ei yleensä rakentaa skedulointia varten. Ei nimittäin ole mitään järkeä käyttää suurta osaa suoritinkapasiteetista skeduloinnin laskemiseen, minkä takia käytetään erilaisia heuristisia ratkaisuja. Yleisin menetelmä on jo aiemmin esitelty kiinteäprioriteettinen skedulointi, jossa prioriteetit määräävät seuraavaksi suoritukseen valittavan tehtävän. Yksi ratkaisumalli on käyttää vain tehtävän määräaikaa D seuraavan prosessin valitsemiseen siten, että mitä pienempi määräaika, sitä suurempi prioriteetti prosessilla on. Näin päädymme edellä kuvattuun määräaikaskedulointiin (EDF). Mikäli prosessin tarvitsema ajoaika tiedetään, voidaan skedulointi perustaa pelkän D:n asemesta arvoon D C, missä C on siis pahimman mahdollisen laskennan suorittamisessa tarvittava aika. Näin aikaan saatu menetelmä on aiemmin esiteltyjen SRT:n ja EDF:n välillä. Koska dynaamisen skeduloinnin perusajatus on antaa skedulerin valita suoritukseen se prosessi, joka skedulointialgoritmin mukaisesti on sopivin, käy usein niin, että skedulointiongelmia alkaa ilmetä, kun kuormitus kasvaa. Tästä syystä usein pidetään hyvänä peukalosääntönä sitä, että suorittimen kuormituksen kasvaessa yli 50 60 prosentin sekä reaaliaikaominaisuudet ja ohjelman suorituksen ennustettavuus heikentyvät merkittävästi. Dynaamista skedulointia kutsutaan optimaaliseksi, mikäli se pystyy skedulointiin annettujen rajojen puitteissa aina, kun jokin staattinen algoritmi olisi siihen pystynyt. Määritelmän tiukkuutta kuvaa se, että staattisella algoritmilla on enemmän lähtötietoja, mukaan lukien yksit-

116 Sulautettu ohjelmointi Prosessien aktivoituminen tehtävä 1 tehtävä 2 tehtävä 1 aika Irrottamaton skedulointi tehtävä 1 tehtävä 1 tehtävä 2 aika Irrottava skedulointi tehtävä 1 tehtävä 1 tehtävä 2 Kuva 6.6 Skedulointikaavio aika täisten tehtävien suorittamisessa tarvittava aika, jonka avulla skeduloinnin laskeminen on mahdollista. 6.5 Skedulointiesimerkki Kuvassa 6.6 on kuvattu skedulointikaavio, jossa ylin kaavio näyttää tehtävien aktivoitumisen ja niiden suorituksen, olettaen että kummallakin tehtävällä olisi oma suoritin. Näistä tehtävä 1 aktivoituu säännöllisin väliajoin, eli on periodinen. Tehtävä 2 on puolestaan sporadinen, ja se kestää kauemmin kuin mitä on kahden 1. tehtävän aktivoitumisen väli on. Keskimmäinen kuva esittää tehtävien skedulointia irrottamattoman skeduloinnin tapauksessa. Skedulointi on siis mahdollinen, mikäli tehtävän yksi määräaika sietää tehtävän kaksi aiheuttaman viivästyksen. Mikäli näin ei ole, irrottamaton skedulointi ei ole mahdollista. Alin kuva näyttää tilanteen, jossa käytetään irrottavaa skedulointia. Tämä tapaus ratkaisee yllä kuvatun ongelman, mutta se ei silti ole yleispätevä: jos tehtävän 2 pitää olla valmis niin nopeasti, ettei tehtävän 1 ajaminen kesken tehtävän 2 suoritusta ole mahdollista, on joko viivästettävä tehtävää 1 keskimmäisen kuvan malliin, tai jos tehtävää 1 ei voi viivästää, niin todeta, että reaaliaikainen skedulointi ei ole mahdollista.

Skedulointi eli vuoronnus 117 Jos skedulointi ei ole mahdollinen, on joko muutettava ajoitusvaatimuksia, lyhennettavä ohjelman vaatimaa suoritusaikaa optimoimalla tai keksittävä jotain muuta. Yksi tällainen "muuta" on kahden algoritmin järjestelmä. Mikäli tilanne on esimerkin mukainen siinä mielessä, että normaalisti aika riittää hyvin (tehtävä 1 ehditään aina ajamaan), mutta ongelmia tulee vain silloin, kun toinenkin tehtävä ilmaantuu, voidaan tehdä esimerkiksi siten, että silloin tällöin ajetaan nopeampi, mutta esimerkiksi lopputulokseltaan heikompi laskennan toteuttava algoritmi tehtävän yksi normaalin toiminnan asemesta. Yleisesti idea on siis seuraava: Mikäli hyvä ja hidas ei ole käytettävissä, käytetään nopeaa mutta vähän huonompaa algoritmia. Heikomman algoritmin valinnan tai ainakin hyväksynnän tekee skeduleri, mutta toistuvalle työlle ei saa aina valita huonoa vaihtoehtoa. Jotta tämä voitaisiin toteuttaa, skedulerin on tunnettava erilaiset vaihtoehdot, niiden suorittamiseksi tarvittava aika sekä yhteinen määräaika. Skeduleri voi siis ajaa nopeaa ja epätarkkaa algoritmia säännönmukaisesti laskennassa tai "yllättäen" jossakin huippukuormatilanteissa, mutta vaihdosta ei saa tehdä aina. Tämä vaihdantatekniikka sopii käytettäväksi staattisessa skeduloinnissa, jossa voidaan taata, että hidaskin suoritus saa joskus ajovuoron, vikasietoisissa järjestelmissä virheestätoipumisen aikana ja pienissä, hyvin tunnetuissa järjestelmissä. Tällaisenaan siis skedulerin ominaisuutena vaihto on harvinainen tosielämässä, sillä dynaamisen skeduloinnin tapauksessa useamman eri laskennan käyttö eri tilanteissa johtaa luonnollisesti monimutkaisempaan järjestelmätestaukseen, sillä siinä pitäisi kyetä varmentamaan kaikki (tai ainakin riittävän monta) vaihtoehdoista suoritusta eri tilanteissa. Toisaalta ohjelmakoodiin langoitettuna sama ilmiö on löydettävissä useammastakin järjestelmästä. 6.6 Skeduloituvuuden analysoinnista Koska skeduloituvuus on oikeastaan minkä tahansa reaaliaikajärjestelmän kannalta tärkeä ominaisuus, on skeduloituvuuden tarkastelua varten olemassa useita vaihtoehtoja. 6.6.1 Staattinen skeduloituvuus Staattisen skeduloituvuuden kannalta tilanne on yleensä melko suoraviivainen, sillä ohjelmoija pystyy useimmiten rakentamaan haluamansa

118 Sulautettu ohjelmointi skeduloinnin etukäteen lähes ilman rajoituksia, jotka olisivat peräisin skedulerin toiminnasta tai prosessien dynaamisesta vaihtamisesta. Koska skeduloinnin kannalta ei ongelmia ole, voidaan keskittyä oikeastaan kokonaan siihen, miten paljon aikaa mikäkin tehtävä vie. Apuna on mahdollista käyttää erilaisia analyysityökaluja, jotka kykenevät rakentamaan ohjelman ajoaikaisia suorituspolkuja ja laskemaan niiden suoritusaikoja. Tällaisen ohjelman avulla on melko helppoa saada selville se, miten kauan jonkun algoritmin pisin mahdollinen suoritus kestää, ja sitä kautta on edelleen mahdollista käyttää tietoa osana skeduloituvuuden analyysia. Koska kyseessä on täysin staattinen skedulointi, kaikki voidaan laskea etukäteen valmiiksi suunnittelun aikana. Staattisuudesta voidaan usein johtaa myös muita analyysia yksinkertaistavia ominaisuuksia, kuten vaikkapa suurin mahdollinen määrä muistia, jonka järjestelmä voi normaalitilanteessa varata. Yhdessä staattisen skeduloinnin kanssa tämä yleensä yksinkertaistaa virheiden jäljittämistä merkittävästi. 6.6.2 Dynaaminen skeduloituvuus Dynaamista skedulointia käytettäessä tilanne on lähes aina melko tavalla monimutkaisempi skeduloituvuuden kannalta. Yleensä ensimmäinen pikatesti on rakentaa versio järjestelmästä, jossa jokaista tehtävää edustaa varjotehtävä, joka kuormittaa suoritinta likimäärin yhtä paljon kuin mitä todellinen tehtävä oletettavasti tulee tekemään. Mikäli suorittimella vaikuttaa olevan ongelmia, voidaan melko luotettavasti päätellä, että näin tulee käymään myös todellisen järjestelmän tapauksessa. Pikatestiä luotettavampia arvoja skeduloituvuuden tarkastelua varten on mahdollista saada käyttämällä analyysityökaluja, joita voidaan hyödyntää samaan tapaan kuin staattisen skeduloinninkin yhteydessä. Näin järjestelmän ominaisuuksista saadaan usein lisätietoa, mikä puolestaan johtaa lähes aina tarkempaan arvioon järjestelmän skeduloituvuudesta. Dynaamisen skeduloinnin yhteydessä voidaan skeduloituvuutta analysoida myös matemaattisesti. Moniin skedulointialgoritmeihin on liitetty kaavoja, joihin syötetään tunnetut lähtöarvot, kuten määräajat, suoritusajat, periodit, ja niin edelleen. Kaavaan sijoitusten jälkeen tuloksena saadaan tieto siitä, pystyykö kaavaan liittyvä algoritmi suorittamaan skeduloinnin vai ei. Jos vastaus on kyllä, algoritmia voidaan käyttää olettaen, että lähtötiedot ja -oletukset olivat oikeat. Toisaalta vaikka vastaukseksi tulisikin ei, ei tämä kuitenkaan takaa sitä, etteikö olisi olemassa skedulointialgoritmia, joka ongelman voisi ratkaista

Skedulointi eli vuoronnus 119 voi kuitenkin olla, että tällaista algoritmia ei ole vielä keksitty ja kaikki tunnetut algoritmit johtavat yhtä huonoon tulokseen. Skeduloitavuuteen liittyviin malleihin liittyy myös muita ongelmia. Ensimmäiseksi pitää tietää kuinka paljon prosessit oikeasti vaativat suoritusaikaa samaan tapaan kuin staattisen skeduloinnin yhteydessä, mikä lienee kohtuullinen oletus skeduloituvuutta arvioitaessa. Tilannetta kuitenkin monimutkaistaa se, että toisin kuin staattisessa skeduloinnissa, missä suunnittelija laskee skeduloinnin kokonaisuudessaan, dynaamista skedulointia käytettäessä skeduleri valitsee kulloinkin suoritettavan prosessin jonkin algoritmin mukaisesti. Tästä syystä tulos on oikeastaan aina pessimistisempi kuin staattisen skeduloinnin tapauksessa. Usein tilanne on sellainen, että jos liikutaan äärirajoilla dynaamista skedulointia käytettäessä, kannattaa varautua skeduloituvuuteen liittyviin ongelmiin jatkossa tai jopa suosiolla todeta, että pitää kokeilla jotakin kokonaan toista lähestymistapaa. Yksi tällainen vaihtoehto on esimerkiksi staattinen skedulointi, jossa joku prosessi voi dynaamisesti valita suorittamansa tehtävän, ja siten lisätä järjestelmään jonkin verran dynaamisia ominaisuuksia. Toinen ongelma skeduloituvuuteen liittyen on, että skeduleri voi myös vaihtaa suorituksessa olevan prosessin, kun suurempiprioriteettinen prosessi tulee suoritusvalmiiksi. Koska prosessin vaihtamisen kustannukset ja vaihtokertojen lukumäärä on vaikeaa arvioida käytännön syistä, usein ajoituslaskennan vaatimat arvot joudutaan osittain arvioimaan, tai jopa toteamaan, että prosessin vaihto on niin nopeaa, että siihen liittyvää aikaa ei tarvitse huomioida lainkaan. Kuten jo aiemmin todettiin, jotkut laitteiston ominaisuudet, kuten erityisesti välimuistin käyttö ja esimerkiksi levyoperaatioiden puskurointi, voivat monimutkaistaa realististen arvioiden tekemistä. 6.7 Yhteenveto Reaaliaikapiirteet vaativat ohjelman toiminnan oikea-aikaisuutta ja ennustettavuutta. Useita erilaisia vaatimuksia: 1. pehmeä reaaliaika: ajoituksen epäonnistuminen ei ole vakava virhe 2. kova reaaliaika: ajoitus ei saa epäonnistua 3. ennustettavuus: vasteajat voidaan laskea ja taata 4. reaktiivisuus: reagoi ärsykkeisiin aikarajojen sisällä riippumatta siitä, mitä muita tehtäviä on aktiivisena.