Realtime
A HupWiki-ből...
Realtime - "valós idejű"
Bár a "realtime" szó szerint kb. "valós idő" lenne, inkább melléknévként használjuk, tehát "valós idejű", vagy "valós időben". Ezt nem úgy kell érteni, hogy létezik "valótlan idő" is, hanem úgy, hogy a realtime jelzőt olyan rendszerekre használjuk, amelyeknek az interaktívitása elég egy bizonyos feladat azonnali elvégzéséhez, így beszélünk pl. realtime operációs rendszerről (RTOS - RealTime Operating System) is (ilyen operációs rendszer a QNX, RTLinux, RTAI)....
Példa:
Legyen mondjuk egy repülés szimulációja matematikai modell esetén. Ha egy öt perces szimulációt a gép két napig számol akkor az nem realtime. Persze attól meg lehet jó, és részletes számítás ami utólag megtekinthető, de nem lenne használható mondjuk egy valóságos repülő fedélzetén, mivel ott azonnal kell az eredmény és nem lehet két napot várni minden századmásodpercenként. Oda realtime rendszer kell, ami ezt a feladatot valós időben képes elvégezni.
"Azokat a rendszereket, amelyekkel szemben a környezeti, valós időskálához kötött idő-követelményeket támasztunk, valósidejű rendszereknek nevezzük. Előírhatjuk például, hogy a rendszer egy környezeti eseményre mennyi időn belül reagáljon, vagy milyen időzített akciókat hajtson végre. [..] A valósidejű rendszerek két alapvető fajtája: a szigorúbb feltételeket teljesítő kemény valósidejű rendszerek (hard real-time) biztosítják, hogy a kritikus munkák befejeződjenek időben, míg a lágy valósidejű (soft real-time) rendszerek csak azt garantálják, hogy a kritikus munkák prioritással futnak."
ISBN 963-545-250-0
A valósidejű működésnek sok definíciója létezik, a különböző alkalmazási területeken használatos eltérő követelmények miatt. Van, ahol az átlagos válaszidőre adnak korlátot, de van, ahol az összes határidő teljesítését megkövetelik a rendszertől. Egy applikáció válaszidején, az applikációt indító jeltől a számított eredmény megjelenéséig eltelt időt értjük. A rendszer válaszidejének pedig az érkező "trigger" jel érkezési időpontjától a kiszolgáló program indításáig eltelt időt tekintjük. Határidő teljesítésén értjük, amikor egy beérkező jelet a beérkezés időpillanatától számított, megadott időintervallumon belül elkezdünk feldolgozni. A megadott időintervallumon belül nem determinisztikus a kezdés időpontja. Minden olyan eset, amikor sérül a határidő, hibának számít.
Megkülönböztetünk "hard real-time" és "soft real-time" rendszereket.
- Hard real-time esetben minden határidősértés elfogadhatatlan, és megengedhetetlen.
- Soft real-time esetben meghatározott mértékben és gyakorisággal el lehet térni a határidőktől.
Ezen operációs környezetekkel szemben megköveteljük továbbá, hogy nyújtsanak megfelelő lehetőséget és elfogadható teljesítményt több, különböző alkalmazás egyidejű, konkurens futtatására a valósidejű alkalmazás mellett.
Az operációs rendszerek nem valósidejű működésének legfőbb oka az ütemezésben keresendő, hiszen a hagyományos operációs rendszereknél a soron következő processz kijelöléséhez a teljes processzlistát át kell tekintenie, ami O(n) nagyságrendű művelet, tehát függvénye a futó alkalmazásoknak. Így nincs garantált, konstans felső korlátja az algoritmus futási idejének. Ha egy eseményre való válasz függ egy alvó processz felébredésétől és futásra való kiválasztásától, és az algoritmus O(n) nagyságrendű, akkor a legrosszabb lehetőség (worst-case) paramétereit sem tudjuk meghatározni. Márpedig ez jellemző a régi (≤ 2.4) Linux és a legtöbb más operációs kernelre is.
A fentiekből is látszik, hogy "hard real-time" operációs rendszer esetén minden operációs algoritmusnak determinisztikus időben (létezzen konstans felső becslése) le kell futnia. A 2.5 fejlesztői kernelfában debütált egyik nagy újdonság a Molnár Ingo fejlesztette konstans idejű O(1) ütemező.
Beágyazott rendszerek esetén lényegesen egyszerűbb a probléma, hiszen a rendszer tervezője számára előre ismerhető, korlátozható a maximálisan futó alkalmazások száma, és azok működési karakterisztikája. Így ismertek az ütemezés időkorlátjai is.
Real-time applikációnak nevezzük azt az alkalmazást, amelynek idő függő követelményei vannak. A real-time operációs rendszer pedig képes teljesítményt garantálni a valósidejű alkalmazás számára.
Egy rendszer teljesítményének túlméretezésével, de nem valósidejű megoldást alkalmazva, az adott problémára még akkor sem adtunk valósidejűnek nevezhető megoldást, ha a tesztelés során a határidők mindig teljesültek, hiszen a rendszer továbbra is tartalmazhat olyan lineáris (vagy még rosszabb) algoritmusokat, amik a tesztelés során nem kerültek sorra, vagy még nem futottak le olyan paraméterekkel, amelyek következtében mégis sérülnek az előírások.
A versenyhelyzetekre is ügyelni kell. A real-time rendszereknek definíciószerűen szembe kell nézniük versenyhelyzetek kialakulásával. Egy jól megtervezett valósidejű rendszer esetén, csak a határidők környezetében keletkezhetnek versenyhelyzetek. Az önmagukban tesztelt részek tulajdonsága még nem bizonyítja a versenyhelyzetek kialakulásának sikeres elkerülését.
Kapcsolódó fogalmak
- RealTime Sub-kernel
- Preemptív ütemező
- Preemptív kernel ( Robert M. Love )
