PÁRHUZAMOS ARCHITEKTÚRÁK – 8 MULTIPROCESSZOROS RENDSZEREK OPERÁCIÓS RENDSZEREI Németh Gábor.

Az előadások a következő témára: "PÁRHUZAMOS ARCHITEKTÚRÁK – 8 MULTIPROCESSZOROS RENDSZEREK OPERÁCIÓS RENDSZEREI Németh Gábor."— Előadás másolata:

1 PÁRHUZAMOS ARCHITEKTÚRÁK – 8 MULTIPROCESSZOROS RENDSZEREK OPERÁCIÓS RENDSZEREI Németh Gábor

2 2015Németh Gábor: Párhuzamos architektúrák2 MULTIPROCESSZOROS RENDSZEREK OPERÁCIÓS RENDSZEREI - 1 Általános esetben több taszkot kell futtatni. Vannak együttműködő és egymástól független taszkok. A taszk szerkezetét elméletileg egy irányított gráf írja le, ahol a taszk moduljai a csomópontok, az adat vagy vezérlés kapcsolatok az élek. Mivel a kód és a végrehajtási történet különböznek, ütemezéshez a szoftver gráfot kellene tekinteni (csomópontjai a modulok megjelenési példányai, élei a köztük lévő tényleges kapcsolatok).

3 2015Németh Gábor: Párhuzamos architektúrák3 MULTIPROCESSZOROS RENDSZEREK OPERÁCIÓS RENDSZEREI - 2 A multiprocesszoros rendszer struktúrája is elméletileg egy irányított gráffal írható le (hardver gráf). Csomópontjai: (az operációs rendszer által jelenleg aktívnak látott) erőforrások; élei: átviteli csatornák. Nagy rendszer esetén mind a hardver, mind a szoftver gráf szerkezete tetszőleges és dinamikusan változó lehet, melyet a tervező nem ismer előre pontosan!

4 2015Németh Gábor: Párhuzamos architektúrák4 MULTIPROCESSZOROS RENDSZEREK OPERÁCIÓS RENDSZEREI - 3 Erőforrás hozzárendelés (az operációs rendszer lényege): a szoftver (rész)gráf(ok) leképzése a hardver gráfra. ”Optimális” leképzés: a hardver gráf éleivel egybeeső szoftver gráf élek számának maximalizálása. Ez a gráfelméletből jól ismert (NP-teljes) gráf izomorfizmus probléma. DE: a probléma ilyen megközelítése értelmetlen. Egy nem pontosan ismert gráfot kellene ”optimálisan” leképezni egy nem pontosan ismert gráfra.

5 2015Németh Gábor: Párhuzamos architektúrák5 MULTIPROCESSZOROS RENDSZEREK OPERÁCIÓS RENDSZEREI - 4  A hardver gráf két fő problémát jelent: 1. Hány processzor kell? 2. Nem ismerjük pontosan.

6 2015Németh Gábor: Párhuzamos architektúrák6 MULTIPROCESSZOROS RENDSZEREK OPERÁCIÓS RENDSZEREI - 5 1.Tervezéskor: a megoldandó feladatosztályok esetén mekkora legyen a processzorok (és logikai és fizikai összeköttetéseik) optimális száma? Taszk szerkezete: (modulok) csak sorosan futtathatók párhuzamosan futtathatók

7 2015Németh Gábor: Párhuzamos architektúrák7 MULTIPROCESSZOROS RENDSZEREK OPERÁCIÓS RENDSZEREI - 6 Amdahl törvénye: P azonos processzor esetén elérhető átbocsátóképesség növekedés, ha a taszk f hányadát sorosan kell végrehajtani Erre szoktak hivatkozni, mint korlátozó tényezőre, azonban sok, gyakorlatban fontos feladatosztály esetén f = f(P) a P csökkenő függvénye!

8 2015Németh Gábor: Párhuzamos architektúrák8 MULTIPROCESSZOROS RENDSZEREK OPERÁCIÓS RENDSZEREI - 7 Nagy és/vagy gyors rendszerek esetén a meghibásodá- sok és módosítások inkoherens megfigyelhetősége miatt a hardver gráfot nem ismerjük pontosan.  Nincs abszolút tér-idő referencia, csak közelítést vagy helyi referenciákat használhatunk. ”Kemény” real-time rendszerekben néhány előre meghatározott eredményt meghatározott határidőig elő kell állítani.  Általában dedikált rendszerek, így interaktív ”finom- hangolás” alkalmazható.

9 2015Németh Gábor: Párhuzamos architektúrák9 MULTIPROCESSZOROS RENDSZEREK OPERÁCIÓS RENDSZEREI - 8 Ha nagy rendelkezésreállóság kell, akkor a processzo- roknak valamilyen diagnosztikai taszkokat is végre kell hajtaniuk (lehetőleg normális működés közben). Az operációs rendszer által megfigyelt hardver gráf egy adott pillanatban G(V, E). V csomópontok: processzorok, E élek: processzorok közötti összeköttetések. Egy meghatározott pillanatban egy csomópont felhasználói folyamatot vagy egy operációs rendszer folyamatot futtathat, így a diagnosztika szempontjából foglalt.

10 2015Németh Gábor: Párhuzamos architektúrák10 MULTIPROCESSZOROS RENDSZEREK OPERÁCIÓS RENDSZEREI - 9 A diagnosztika alatt valamennyi foglalt csomópontot és összeköttetéseiket ki kell venni a diagnosztikai gráfból, így a diagnosztikai gráf: D(V’, E’), V’  V, E’  E. Hatékony diagnosztikához azonban D = D 1,k kell, azaz ha egy lépésben max. k hibát kívánunk diagnosztizálni, úgy diagnosztikai él kell legyen v i és v j csomópontok között akkor és csak akkor, ha j - i = a(modulo n), a = 1, 2, …, k.

11 2015Németh Gábor: Párhuzamos architektúrák11 MULTIPROCESSZOROS RENDSZEREK OPERÁCIÓS RENDSZEREI - 10  A diagnosztizálhatóság követelménye azt jelenti, hogy egy, a rendszer különböző részeinek diagnosztizálása szerint változó szerkezetű részgráfot félre kell tenni a hardver gráfból és csak a megmaradó rész használható felhasználói és operációs rendszer folyamatok futtatására. HOZZÁRENDELÉSI PROBLÉMA MULTIPROCESZ- SZOROS RENDSZEREKBEN: pontatlanul ismert szoftver gráf leképzése pontatlanul ismert hardver gráfra, pontatlanul ismert időzítési korlátozások mellett.

12 2015Németh Gábor: Párhuzamos architektúrák12 ÚTVONAL-IRÁNYÍTÁS, ÜTEMEZÉS - 1 Taszk feldolgozás kérés betehető: 1.Közös átmeneti tárolóba, ahonnan átküldjük valamelyik processzornak (útvonal-irányítás). 2.A belépési hely saját várakozási sorába.

13 2015Németh Gábor: Párhuzamos architektúrák13 ÚTVONAL-IRÁNYÍTÁS, ÜTEMEZÉS - 2 Ha a futásra kész taszkok egyetlen ponton léphetnek be a rendszerbe: útvonal- irányítás taszk kimenet ütemezés... P1P1 P2P2 Egy teljes taszkot rendelünk egy meghatározott processzorhoz, de végrehajtása felfüggeszthető. (Előnyös, ha a taszk szerkezete főleg szekvenciális és a folyamatok közötti kommunikáció jelentős.)

14 2015Németh Gábor: Párhuzamos architektúrák14 ÚTVONAL-IRÁNYÍTÁS, ÜTEMEZÉS - 3 ÚTVONAL-IRÁNYÍTÁSI STRATÉGIÁK: 1. FIX:a taszk kérést egy meghatározott procesz- szor várakozási sorába irányítjuk, függet- lenül annak jelenlegi tartalmától (pl. vélet- lenszerűen választjuk ki a processzort). 2. ADAPTÍV: a taszk kérést a rendszer jelenlegi állapota alapján kiválasztott processzor várakozási sorába írjuk be (pl. a legrö- videbb várakozási sorba).

15 2015Németh Gábor: Párhuzamos architektúrák15 ÚTVONAL-IRÁNYÍTÁS, ÜTEMEZÉS - 4 FIX ÚTVONAL-IRÁNYÍTÁS: Megvalósítása nagyon egyszerű. Kis overhead.  Nagy terhelés egyenlőtlenség lehet.  Rossz erőforrás kihasználás.  Hosszabb reagálási és/vagy átfutási idő.

16 2015Németh Gábor: Párhuzamos architektúrák16 ÚTVONAL-IRÁNYÍTÁS, ÜTEMEZÉS - 5 ADAPTÍV ÚTVONAL-IRÁNYÍTÁS:  Jobbnak tűnik, DE: a rendszer pillanatnyi globális állapotát ismerni kellene.  Nagy és/vagy gyors rendszerekben senki sem lát helyes képet a rendszer állapotáról. (Csak közelítő képünk van és ahhoz adaptálhatunk.)  A közelítő állapotot meg kell figyelni (a terheléseket be kell gyűjteni). Ez komoly overhead.  A helyzet a rendszer méretének növekedésével romlik!

17 2015Németh Gábor: Párhuzamos architektúrák17 ÚTVONAL-IRÁNYÍTÁS, ÜTEMEZÉS - 6 MULATSÁGOS KÖVETKEZMÉNY: AZ EGYÉBKÉNT IS EGYSZERŰBB FIX ÚTVONAL-IRÁNYÍTÁST KELL ALKALMAZNI, MERT AZ OVERHEAD FÜGGETLEN A RENDSZER MÉRETÉTŐL (LÉPTÉKEZHETŐSÉG)! A körbenforgó útvonal-irányítás rövidebb várakozási sort igényel, mint a véletlen hozzárendelés.

18 2015Németh Gábor: Párhuzamos architektúrák18 ÚTVONAL-IRÁNYÍTÁS, ÜTEMEZÉS - 7 ÜTEMEZÉSI STRATÉGIÁK: Taszk szintű granularitás esetén az ütemezést minden processzor egymástól függetlenül végzi. DE: az ütemezés idővesztesége nem szükségképpen független a rendszer méretétől! Fix útvonal-irányítás esetén a várakozási sorban lévő taszkok száma nő a rendszer méretével, mert a taszkok érkezési gyakoriságát növeljük a rendszer méretével (ellenkező esetben miért készítenénk nagyobb rendszert) és a beérkező taszkokat vakon rendeljük hozzá a processzorokhoz.

19 2015Németh Gábor: Párhuzamos architektúrák19 ÚTVONAL-IRÁNYÍTÁS, ÜTEMEZÉS - 8 Az ütemezési idő csak az FCFS (először-jött-először- kiszolgálva) stratégia esetén független a várakozási sor méretétől (és így a rendszer méretétől). Az ütemezési overhead is FCFS esetén a legkisebb. Adaptív útvonal-irányítás esetén a várakozási sorok hossza közel egyforma, így minden ütemezési stratégia overhead-je független lesz a rendszer méretétől, DE: az adaptív útvonal-irányítás overhead-je viszont nő a rendszer méretével.

20 2015Németh Gábor: Párhuzamos architektúrák20 ÚTVONAL-IRÁNYÍTÁS, ÜTEMEZÉS - 9 CÉL: léptékezhető rendszer. (A léptékezhető rendszer teljesítőképessége a rendszer méretével arányosan nő.) A multiprocesszoros rendszer csak fix útvonal-irányítás és FCFS ütemezés mellett léptékezhető! Az eredmény mulatságos: nagy multiprocesszoros rendszer operációs rendszere a lehető legegyszerűbb (egyszerűbb, mint a kis rendszereké).

21 2015Németh Gábor: Párhuzamos architektúrák21 DINAMIKUS TERHELÉS- KIEGYENLÍTÉS - 1 Elméletileg növelhető a rendszer teljesítőképessége, ha a processzorok ütemezői együttműködnek a terhelések újraelosztásában. (A futás során megjelenik a különböző feladat- végrehajtási idők hatása: ha egy feladat hosszú ideig fut, akkor ütemezője várakozási sorában várakozó feladatok száma megnő.) Ez elméletileg lehetetlenELMÉLETI PROBLÉMA: az optimális újraelosztás pontos rendszerállapot ismeretét igényli. Ez (nagy, elosztott rendszerekben) elméletileg lehetetlen.

22 2015Németh Gábor: Párhuzamos architektúrák22 DINAMIKUS TERHELÉS- KIEGYENLÍTÉS - 2 A közelítés jósága azonban a megfigyelési ciklustól függ, ez viszont (a pontossággal növekvő) időt igényel, ami viszont egy határon túl rontja a megfigyelés koherenciáját. –Az i. számítógép elküldi az összes többinek pillanatnyi (becsült) terhelés értékét. Ez valamennyi időt vesz igénybe [a becslés ideje a pontossággal, az elküldés ideje a rendszer méretével nő]. Ezután az i+1. küldi el terhelés értékét és í.t. De mire a k. elküldi terhelését, addigra az i. terhelése megváltozott!

23 2015Németh Gábor: Párhuzamos architektúrák23 DINAMIKUS TERHELÉS- KIEGYENLÍTÉS - 3 GYAKORLATI PROBLÉMA: a feladat átvitele egy másik processzorra időt igényel.  Így egy feladatot csak akkor adunk át, ha a forrás processzor várakozási sorában várakozó feladatok terhelése egy küszöbértéket meghalad.  Ha a processzorok közötti átviteli késleltetés eltérő, akkor a forrás-nyelő pártól függő küszöbértékeket kellene használni (túl nagy overhead).

24 2015Németh Gábor: Párhuzamos architektúrák24 DINAMIKUS TERHELÉS- KIEGYENLÍTÉS - 4 GRANULARITÁSI PROBLÉMA: mekkora legyen a hozzárendelési egység? Teljes taszkot rendelünk hozzá egy processzorhoz.  Nagy terhelés-egyenlőtlenséget okozhat. Nincs folyamatváltás miatti overhead. Kevés processzorközi kommunikáció kell.  Sok sorosan végrehajtandó részt, sok folyamatközi kommunikációt, kevés taszkok közötti kommunikációt tartalmazó taszk esetén előnyös.

25 2015Németh Gábor: Párhuzamos architektúrák25 DINAMIKUS TERHELÉS- KIEGYENLÍTÉS - 5 Egy vagy több szekvenciális folyamatból álló modult rendelünk hozzá egy processzorhoz. Elvileg jobban kiegyenlíthető a processzorok terhelése.  Nagy lehet a modulváltás miatti overhead.  Több processzorközi kommunikáció kell.

26 2015Németh Gábor: Párhuzamos architektúrák26 DINAMIKUS TERHELÉS- KIEGYENLÍTÉS - 6 útvonal-irányító ütemező újraelosztás P1P1 P2P2 összeköttetésekösszeköttetések futásra kész taszkok.............................. terhelési állapot üzenetek modulokat oszt szét

27 2015Németh Gábor: Párhuzamos architektúrák27 DINAMIKUS TERHELÉS- KIEGYENLÍTÉS - 7 A processzorok terhelési információját valamilyen T időközönként gyűjtjük össze. Ezt a koherencia javítása érdekében célszerű üzenetszórással eljuttatni minden csomópontnak. Az útvonal-irányítók a terhelések figyelembevételével küldik el a beérkező taszk moduljait a processzorok ütemezőinek. Az ütemezők továbbküldhetik egy vagy több moduljukat a terhelési viszonyok figyelembevételével.

28 2015Németh Gábor: Párhuzamos architektúrák28 DINAMIKUS TERHELÉS- KIEGYENLÍTÉS - 8 Egy modul más processzorra küldése időt igényel, így csak akkor küldjük el, ha a forrás csomópont terhelése egy küszöbszinttel meghaladja az átlagos terhelést. Az átküldött modul valamilyen nagyságú többlet terhelést jelent, így olyan csomópontnak küldjük el, melynek terhelése egy küszöbszinttel az átlagos terhelés alatt van. Ugyanazt a modult legfeljebb p-szer irányíthatjuk át más processzorra, mert ellenkező esetben esetleg soha nem hajtódna végre.

29 2015Németh Gábor: Párhuzamos architektúrák29 DINAMIKUS TERHELÉS- KIEGYENLÍTÉS - 9  i ütemező át kíván küldeni egy modult, ha ahol a rendszer átlagos terhelése k = küszöbszint. hozzárendelési mátrix: ha M j modul az i processzorhoz van rendelve, egyébként 0.

30 2015Németh Gábor: Párhuzamos architektúrák30 DINAMIKUS TERHELÉS- KIEGYENLÍTÉS - 10  j egy jelölt rendeltetési processzor, ha  Logikusnak tűnik, hogy a jelöltek közül a j = min {L(j, X, nT)} processzort kellene választani. Egy elosztott rendszerben az egyes források döntésüket egymástól függetlenül hozzák meg, így több forrás processzor választhatná ugyanazt a cél processzort, JELENTŐS TERHELÉS-INGADOZÁSt eredményezve!

31 2015Németh Gábor: Párhuzamos architektúrák31 DINAMIKUS TERHELÉS- KIEGYENLÍTÉS - 11 GYAKORLATI PROBLÉMA: terhelések jellemzése. Elméletileg a terhelés a taszk érkezési gyakoriságtól, a taszkok szerkezetétől és a modulok végrehajtási ideitől függ. r processzor terhelése két részből áll: a hozzá rendelt modulok végrehajtási idejéből és az r processzor és az összes többi processzor közötti kommunikáció idejéből.

32 2015Németh Gábor: Párhuzamos architektúrák32 DINAMIKUS TERHELÉS- KIEGYENLÍTÉS - 12 Gyakorlatilag a várakozási sor hossza jó terhelés mérték (egységnyi végrehajtási idejű modulok), mert  egy adott várakozási sor hossza mind a tényleges érkezési gyakoriságtól, mind az adott processzor tényleges kiszolgálási idejétől függ.  (Ha egy modul futási ideje hosszabb, akkor azalatt több új igény kerül be a várakozási sorba.)  Ennek a terhelés jelzőnek a meghatározása nagyon egyszerű, kis overheadet jelent.

33 2015Németh Gábor: Párhuzamos architektúrák33 DINAMIKUS TERHELÉS- KIEGYENLÍTÉS - 13 A folyamatok közötti együttműködés különböző hozzá- rendelések esetén eltérő átfutási időket eredményezhet még ugyanolyan terheléselosztás esetén is! Illusztratív példa: ismétlődő futtatás, engedélyvezérelt együttműködés (egy modul egy meghatározott végrehajtásának eredményét egy másik modul egy meghatározott végrehajtása bemenő paramétereként használjuk).

34 2015Németh Gábor: Párhuzamos architektúrák34 DINAMIKUS TERHELÉS- KIEGYENLÍTÉS - 14 Legyen két processzor (P 1 és P 2 ), és az ismétlődő taszk álljon négy modulból (M 1 - M 4, az indexek végrehajtási sorrendet jelölnek), T 1 = T 3 és T 2 = T 4 végrehajtási időkkel. Két lehetséges hozzárendelés: A két hozzárendelés terhelési viszonyai egyformák, a feladatok átfutási idői azonban nem. A feladatok érkezési gyakorisága legyen egyforma.

35 2015Németh Gábor: Párhuzamos architektúrák35 DINAMIKUS TERHELÉS- KIEGYENLÍTÉS - 15 A viszonyok a várakozási sorok elméletével kezelhetők. A reagálási idők pl. az a hozzárendelés esetén: ahol m 1 = T 2 /T 1 és w i (a, m k ) i modul várakozási ideje a sorban.

36 2015Németh Gábor: Párhuzamos architektúrák36 DINAMIKUS TERHELÉS- KIEGYENLÍTÉS - 16 Nagyon nagy és/vagy gyors rendszerek esetén nem érdemes dinamikus terhelés-kiegyenlítést alkalmazni. Közepes méretű és/vagy sebességű rendszer esetén alkalmaz- ni lehet, DE: az adaptív útvonal-irányítást célszerű használ- ni, az ütemezők közötti adaptív átirányítás csak felesleges bonyolultság növekedést eredményez, a hatékonyság nem javul. Két szekvenciálisan végrehajtandó modul esetén, ha az első modul végrehajtási ideje jóval hosszabb a másodiknál, akkor célszerű ugyanahhoz a processzorhoz rendelni őket (mert periodikusabbá teszi a második végrehajtásának elkezdését és így csökken a várakozási idő).

37 2015Németh Gábor: Párhuzamos architektúrák37 MULTITASKING - 1 Egy processzor ütemezőjének tulajdonképpen multitasking üzemmódban kell működnie.  (Csak taszkok helyett esetleg modulokat kell kezelnie.) virtuális processzorMinden modul számára látszólag egy saját processzort bocsátunk rendelkezésre (virtuális processzort). A fizikai processzort egy meghatározott fizikai időtartamra hozzárendeljük egy kiválasztott modulhoz.  Az ütemező minden időpillanatban egy meghatározott virtuális processzort képez le a fizikai processzorra.

38 2015Németh Gábor: Párhuzamos architektúrák38 MULTITASKING - 2 Ha az ütemező egy modul végrehajtását felfüggeszti (vagy a modul végrehajtása befejeződött), akkor átvált egy másik modul futtatására.  Egy adatszerkezetet rendelünk minden modulhoz, melyben a modul futtatásához szükséges informá- ciót tároljuk. (Például a regiszterek felfüggesztés- pillanatbeli értékeit itt mentjük el és a felfüggesztett modul futtatásának folytatásakor ezekből az adatokból töltjük fel a processzor regisztereit.)  TSS (Task State Segment) az Intel x86 családban.

39 2015Németh Gábor: Párhuzamos architektúrák39 MULTITASKING - 3 context switching  A rendszer átlátszóvá tételére ezt az elmentést és visszaállítást (context switching) a hardvernek és/vagy az operációs rendszernek automatikusan kell végrehajtania (de időt igényel).  Hardver segítség az Intel x86 családban.  Mivel a modul a processzort csak az operációs rendszer szolgáltatásai által meghatározott felületen keresztül látja, a fizikai processzor hardver regiszterei mellett az operációs rendszer jellemzőit is el kell menteni (pl. file leírókat).  De ezek függenek az operációs rendszertől, így az operációs rendszer menti el.

40 2015Németh Gábor: Párhuzamos architektúrák40 MULTITASKING - 4 Az ütemező valamilyen stratégia szerint veszi ki várakozási sorából (soraiból) végrehajtásra valamelyik futásra kész modult.  Az ütemező ez(eke)t a várakozási sor(oka)t bemenő adataiként tekinti és minden erőforráshoz kiválaszt egy-egy futtatandó modult (aktivizál egy-egy modult).  Az aktivizált modul ezekután használhatja az erőforrást.

41 2015Németh Gábor: Párhuzamos architektúrák41 MULTITASKING - 5 FCFS (First-Came-First-Served): ALAPVETŐ ÜTEMEZÉSI STRATÉGIÁK: nagyon egyszerű; kis overhead;  nem veszi figyelembe a modulok (taszkok) fontosságát;  egy modulnak esetleg nagyon sokáig kell várnia. új modul ERŐFORRÁS várakozási sor

42 2015Németh Gábor: Párhuzamos architektúrák42 MULTITASKING - 6 Körbenforgó (round robin): ERŐFORRÁS új modul  Minden modul meghatározott ideig használhatja az erőforrást, utána az ütemező felfüggeszti és visszateszi a várakozási sorba.  Egyforma időszelet = egyforma prioritás = egyforma reagálási idő.  Eltérő időszelet vagy nem a sor végére visszarakás = eltérő prioritás.

43 2015Németh Gábor: Párhuzamos architektúrák43 MULTITASKING - 7 preemptív ütemezés Nagyobb rugalmasság érhető el (valamilyen) preemptív ütemezéssel.  Egy nagyobb prioritású modul felfüggesztheti egy alacsonyabb prioritású modul végrehajtását.  Könnyebb a real time követelmények teljesítése.  Bonyolultabb az ütemező (véges automata, ahol a modul állapotai az erőforrás használatára vonatkozó készségének felelnek meg).  Nagyobb overhead.

44 2015Németh Gábor: Párhuzamos architektúrák44 MULTITASKING - 8 KÉSZ modul létrehozása AKTÍV idő lejárt vagy üzenet jött modul törlése másik modul engedélyezi másik modul felfüggeszti FELFÜGGESZTETT másik modul vagy saját maga felfüggeszti ALVÓ időzítésre vagy üzenetre vár Véges automata alapú preemptív ütemező blokksémája:

45 2015Németh Gábor: Párhuzamos architektúrák45 MULTITASKING - 9 holtpont  Az erőforrásokon osztozás holtpontra vezethet. LETILTJA Megfelelő holtpont elkerülési és holtpont feloldási módszereket kell alkalmazni. ÜTEMEZ LETILTJA P(S1) P(S2) V(S2) V(S1) PRE- EMPTÁL P(S2) V(S1) V(S2)P(S1) fontosabb folyamat jön

46 2015Németh Gábor: Párhuzamos architektúrák46 OPERÁCIÓS RENDSZER MAGOK - 1 Beépített alkalmazásoknál az operációs rendszert a konkrét követelményekhez kell szabni. (Egy meghatározott alkalmazás meghatározott operációs rendszer funkciókat igényel.)  Olyan operációs rendszer magot kell kidolgozni, melynek funkciói modulárisan használhatók és alkalmazásfüggő változatai ROM-ba tehetőek.

47 2015Németh Gábor: Párhuzamos architektúrák47 OPERÁCIÓS RENDSZER MAGOK - 2 MEGOLDÁS: elemi operációs rendszer funkciókat valósítunk meg az alábbi korlátozásokkal: a felhasználó a függvénynek csak a beviteli/kiviteli protokollját látja (belső megvalósítása el van rejtve); a függvény nem tételezhet fel semmilyen előre meghatározott környezetet; lehetővé kell tenni felhasználó által írt funkciók beillesztését.

48 2015Németh Gábor: Párhuzamos architektúrák48 OPERÁCIÓS RENDSZER MAGOK - 3 Hasonlítsuk össze azokkal a hardver elemekre vonatkozó követelményekkel, melyek lehetővé tették az univerzálisan alkalmazható integrált áramkörök bevezetését! A második követelmény nagyon problematikus! Az operációs rendszer a felhasználói programot és a számítógép hardverét bemenő adatként dolgozza fel (így néhány része nyilvánvalóan gépfüggő, pl. interrupt kezelés).

49 2015Németh Gábor: Párhuzamos architektúrák49 OPERÁCIÓS RENDSZER MAGOK - 4 FUNKCIONÁLIS ÉRTELMEZÉS: Az operációs rendszer mag a számítógép utasításkészletét szoftver szerkezeteket (pl. várakozási sorokat, táblázatokat) feldolgozó utasításokkal egészíti ki (a normál számítógép utasítások a regiszterek tartalmát dolgozzák fel).  A beépített alkalmazás írója egy virtuális gépet lát.