Ugrás a tartalomhoz

Operációs rendszerek mérnöki megközelítésben

Benyó Balázs, Fék Márk, Kiss István, Kóczy Annamária, Kondorosi Károly, Mészáros Tamás, Román Gyula, Szeberényi Imre, Sziray József

Panem Kiadó

1.3. Rendszermodell és rendszerarchitektúra

1.3. Rendszermodell és rendszerarchitektúra

Miután megismerkedtünk az operációs rendszerek rövid történetével, most – megmaradva a bevezetőhöz illő áttekintő szinten – váltsunk nézőpontot.

Közelítsünk az operációs rendszerhez a szoftverrendszerek szokásos tervezési szemléletével. Először húzzuk meg a rendszer határait, vizsgáljuk meg a tipikus környezeti kapcsolatokat, és a rendszer viselkedését a környezet szereplőivel való kapcsolatban (rendszermodell). Ezt követően pedig foglalkozzunk azzal a kérdéssel, hogy a modell milyen belső szerkezetekkel valósítható meg (rendszerarchitektúra).

1.3.1. Az operációs rendszer és környezete

A rendszermodell felállításához az 1.6. ábra legyen kiindulási alapunk, amelyik az operációs rendszer ún. kontextdiagramját mutatja be.

A kontextdiagram alapján az operációs rendszer fő környezeti kapcsolatai:

  • a kezelők (operátorok),

  • az alkalmazói programok,

  • a számítógéphardver.

Az operációs rendszernek működése során ezek felé kell csatlakozási felületet nyújtania, és alapvető funkcióit a környezeti kapcsolatokban mutatott viselkedésével jellemezhetjük.

1.6. ábra. ábra - Az operációs rendszer kontextdiagramja

Az operációs rendszer kontextdiagramja


1.3.2. Funkciók

Mint korábban megállapítottuk, az operációs rendszernek két alapvető feladata van:

  • kényelmesen használható virtuális gép megvalósítása a kezelők és az alkalmazások felé,

  • a számítógéphardver hatékony és biztonságos működtetése.

A kényelmesen használható virtuális gép azt jelenti, hogy a hardver részleteit el kell fedni, a felhasználók számára áttekinthető modelleket kell kínálni, és azokat meg kell valósítani a fizikai rendszeren. Másként fogalmazva a fizikai rendszer kényelmes és célszerű absztrakcióit kell implementálni az adott számítógép-konfiguráción. Ilyen absztrakciók például az önálló logikai processzorral és tárterülettel rendelkező, egymástól védett, de egymással kommunikálni tudó, párhuzamosan végrehajtódó folyamatok, a fizikai címtartomány méretét meghaladó címezhető tártartomány (virtuális tár), a fájl és a katalogizált fájlrendszer, ahol megoldott a biztonságos és védett adattárolás stb.

A számítógéphardver hatékony működtetése azt jelenti, hogy az alkalmazások futtatását úgy kell koordinálni, hogy a fizikai eszközök kihasználtsága minél jobb legyen, és a felhasználó által előírt prioritások teljesüljenek. A hatékonyság követelményét ugyanis elméletileg megfogalmazhatjuk egy optimumkritériumként, ahol a célfüggvényben különböző minőségi paraméterek szerepelhetnek (például processzorkihasználás, válaszidő, átfutási idő, áteresztőképesség stb., illetve ezen paraméterek statisztikai jellemzői). Az egyes paraméterek jelentősége rendszerenként különböző lehet, illetve egyéb, speciális szempontok is megjelenhetnek.

A biztonságos működtetés pedig azt jelenti, hogy az operációs rendszer korrekt megoldásokat tartalmaz a megosztott erőforrás-használatból eredő problémákra (például közös fizikai processzor használata, a fizikai tár kiosztása, ugyanazon készülékre indított több, egyidejű be-kiviteli művelet végrehajtása), valamint elfedi a tranziens hardverhibákat (például hibatűrő, hibajavító kódolás adattárolások, adatátvitelek esetén).

1.3.3. Csatlakozási felületek

A következőkben az operációs rendszer kapcsolódási felületeit jellemezzük.

1.3.3.1. Kezelői (operátori) felület (Operator Interface, User Interface)

A kezelői felület ember–gép kapcsolat. Arra szolgál, hogy az operációs rendszer ezen keresztül működtethető legyen, illetve működéséről a felhasználó tájékoztatást kapjon. A kezelői felület kialakításának tipikus fizikai eszköze a képernyőt, billentyűzetet és esetleg egeret (grafikus pozicionáló eszköz) tartalmazó munkahely. Kevésbé elterjedten – egyelőre főként speciális rendszerekben – már az operációs rendszerek kezelői felületén is találunk egyéb eszközöket, például hang be- és kimeneteket.

A rendszert kezelő felhasználók a következő jellegzetes csoportokra oszthatók: egyszerű felhasználókra, alkalmazásfejlesztőkre, és rendszermenedzserekre.

Az egyszerű felhasználók jellegzetes tevékenysége, hogy programokat (alkalmazásokat) futtatnak, amelyek segítségével szokásos napi feladataikat látják el (például irodában dokumentumkezelés, táblázatszerkesztés; automatizált üzemben diszpécser-feladatok stb.). Az egyszerű felhasználók jelentős része elsősorban az alkalmazásokat és azok kezelői felületét használja, az operációs rendszerrel közvetlenül alig kerül kapcsolatba. Számukra az operációs rendszerben a főszerepet a katalogizáltan nyilvántartott fájlok játsszák, amelyek között vannak futtatható programokat tartalmazó, végrehajtható fájlok, továbbá vannak az alkalmazások által kezelt, adatokat tároló fájlok. Érdekli őket, hogy tudnak-e futtatni egyidejűleg több alkalmazást, és ezek az alkalmazások tudnak-e információt cserélni egymással. Az egyszerű felhasználó elvár bizonyos megbízhatóságot, védelmet és biztonságot a rendszertől, ennek érdekében tudomásul veszi, hogy bejelentkezés, azonosítás, és néhány egyéb rendszabály betartása szükséges. A rendszabályokat azonban hajlamos lazán és fegyelmezetlenül kezelni, amint azok számára a legkisebb kényelmetlenséget okozzák.

Az egyszerű felhasználó számára tehát az operációs rendszer olyan gép, amelyik egy felhasználói körnek lehetőséget ad adat- és programfájlok védett és rendezett tárolására, valamint alkalmazások futtatására. A rendszer legfontosabb szolgáltatásai: bejelentkezés, a rendelkezésre álló alkalmazások áttekintése, alkalmazások indítása, esetleges együttműködése és leállítása, fájlműveletek (másolás, mozgatás, törlés, tartalomfüggő feldolgozás).

Az alkalmazásfejlesztők részletes ismeretekkel rendelkeznek az operációs rendszer alkalmazói programok számára nyújtott szolgáltatásairól és bizonyos mélységig ismerik az operációs rendszer belső működését. Ezeket az ismereteiket a programkészítésben használják fel. Mint kezelők, az általuk készített alkalmazások tesztelésével, teljesítményelemzésével is foglalkoznak. Egyes operációs rendszerek nyújtanak ehhez eszközöket (például debug módú futtatás), gyakoribb eset azonban, hogy a fejlesztést támogató speciális alkalmazás (például PASCAL, C, C++ nyelvek integrált fejlesztői környezete) tartalmazza a megfelelő szolgáltatásokat. Mindenképpen szükségesek azonban olyan eszközök, amelyek az egyes programok és a hozzájuk tartozó erőforrások (memóriaterület, processzor, perifériák) aktuális állapotát, az erőforrás-használatok időtartamát, az ezekre vonatkozó statisztikákat láthatóvá teszik. Ezek akkor is az operációs rendszer szolgáltatásaira támaszkodnak, ha a fejlesztést támogató alkalmazás teszi őket elérhetővé az alkalmazásfejlesztő számára.

Az alkalmazásfejlesztő számára tehát az operációs rendszer olyan gép, amelyik a programok számára meghívható eljárásokat biztosít, amivel

  • leveszi a válláról a hardver pontos és részletes ismeretének és programozásának terhét,

  • lehetőséget ad arra, hogy együttműködő programokkal oldjon meg egy feladatot,

  • a programok együttműködéséhez ellenőrzött eszközöket ad,

  • megszervezi a programok együttfutását és erőforrás-használatát,

  • megfigyelhetővé teszi a programok futása közben kialakuló rendszerállapotokat.

Az alkalmazásfejlesztőknek nyújtott szolgáltatások tehát már bizonyos mértékű bepillantást engednek az operációs rendszer belső szerkezetébe, a futó programokhoz rendelt fizikai eszközök állapotát is láthatóvá, esetleg közvetlenül módosíthatóvá teszik.

A rendszermenedzser feladata az operációs rendszer üzemeltetése, valamennyi ezzel kapcsolatos probléma megoldása. Ez magában foglalja egyrészt a rendszergenerálás feladatát, ami azt jelenti, hogy a rendszert a rendelkezésre álló hardverhez és az ellátandó feladatokhoz illesztett kiépítésben kell telepíteni. Másrészt adminisztrációs feladatokat, ami a rendszer felhasználói­nak, a rendszerhez kapcsolódó alkalmazásoknak a nyilvántartását, jogosultságaik kiosztását, a rendszer üzemeltetési szabályainak, biztonsági előírásai­nak meghatározását, azok betartásának felügyeletét jelenti. Harmadrészt hangolási feladatokat, ami a hardver lehetőségeit, a tipikus alkalmazásokat és a rendszer statisztikáit figyelembe véve azoknak a rendszerparamétereknek beállítását jelenti, amelyek az üzemeltetés hatékonyságát befolyásolják (pufferméretek, ütemezési és kiosztási algoritmusok stb.). Negyedrészt rendszerfelügyeletet takar, ami a zavartalan, folyamatos működés biztosítását, az esetleges rendellenességek észlelését, elhárítását, az ennek érdekében szükséges időszakos feladatok ellátását (karbantartások, mentések stb.) jelenti.

A rendszermenedzser számára tehát az operációs rendszer olyan gép, amelyik a hardver adott célú hatékony alkalmazását segíti, és amelynek a hardverhez és a feladatokhoz illeszkedő, megfelelő telepítése, behangolása, használatának adminisztrációs és általános üzemeltetési feladatai rá hárulnak.

A rendszermenedzser részletes és alapos ismeretekkel rendelkezik mind az operációs rendszerről, mind a környezetről, és a feladatok ellátásához olyan beavatkozási lehetőségekre van szüksége, amilyen a többi felhasználónak nincs. Ezért a rendszermenedzser számára gyakran külön fizikai eszköz (rendszerkonzol) áll rendelkezésre.

A kezelői felület lehet szöveges vagy grafikus. A grafikus felületek köny-nyebben áttekinthetők, inkább nevezhetők felhasználóbarát megoldásnak. A szöveges felület előnye ezzel szemben, hogy a kezelő távoli terminálról, kis sávszélességű összeköttetésen keresztül is működtetni tudja a rendszert, és könnyebben megvalósítható a készülékfüggetlenség.

A szöveges kezelői felület lehet parancsnyelvű (és általában egyben parancssor-orientált), vagy menürendszerű (és általában egyben képernyő-orien­tált). A menürendszer felhasználóbarát, amennyiben mentesíti a kezelőt a parancskészlet és a gyakran igen bonyolult paraméterezés megtanulása alól. A parancsnyelv előnye ismét csak a készülékfüggetlenség könnyebb megvalósítása, továbbá a parancsok összefűzésének lehetősége (lásd batch üzemmód).

A kezelői felületek általában interaktív működtetésre adnak lehetőséget. A kezelő egy beavatkozását a rendszer azonnali reakciója követi. Rákattintunk egy ikonra, kiválasztunk egy menüpontot, vagy begépelünk egy parancsot, mire a rendszer a megfelelő művelet végrehajtásával reagál. Általában a végrehajtás befejezését követően fogad el a rendszer újabb kezelői beavatkozást vagy parancsot (szinkron működés). Vannak rendszerek (a multi­prog­ra­mozott, vagy multitaszk rendszerek általában ilyenek), amelyek megengedik, hogy az előző parancs befejeződése előtt újabb parancsot indíthassunk (aszinkron működés).

Gyakran hasznos, ha az operációs rendszernek szóló parancsokat egy parancssorozattá fűzhetjük össze. Ezt a parancssorozatot tárolhatjuk például egy fájlban (batch file, shell script), és bármikor egyetlen parancsként végrehajtathatjuk a rendszerrel. Ily módon tulajdonképpen az operációs rendszernek szóló programot állítottunk össze. Úgy is fogalmazhatunk, hogy az operációs rendszer a kezelő számára ugyanúgy egy programozható gépnek látszik, mint a processzor a programozó számára.

Ugyanazon operációs rendszernek többféle kezelői felülete is lehet. Általában a parancsnyelvű felület az alap, amire ráépülhetnek menürendszerű, illetve grafikus felületek. A batch, illetve script készítésének lehetősége a parancsnyelvű felületen van meg. Az interaktív, illetve a grafikus felületen ilyen „programok” például a WinWord-ből ismert tanítási (makrorögzítés) technikával lennének létrehozhatók, az operációs rendszereknél azonban ez nem terjedt el.

1.3.3.2. Alkalmazási (programozói) felület (Application Interface, Program Interface)

A számítógéprendszeren futó, adott feladatokat megoldó programok valamilyen programozási nyelven (pl. FORTRAN, PASCAL, C, C++ stb.) íródnak. Előkészítési időben (fordítás, szerkesztés) történik meg a program átalakítása a processzor által végrehajtható formára (gépi kód). A program készítője általában feltételezi, hogy a program valamilyen operációs rendszer felügyelete alatt fut, az operációs rendszer pedig kész, előre programozott megoldásokat tartalmaz például a be-/kiviteli műveletekre, az időkezelésre, a dinamikus tárigények kielégítésére, a programok együttműködésének és információcseréjének megoldására. Ezek a műveletek a szubrutinhíváshoz hasonló, de attól néhány tekintetben különböző módon, rendszerhívásokkal hajthatók végre. A futtatható program tehát nem zárt abban a tekintetben, hogy saját maga tartalmazza valamennyi, a futása során végrehajtódó gépi utasítását, hanem rendszerhívó utasításokat is tartalmaz, amelyek hatására az operációs rendszer lép működésbe, az operációs rendszer részét képező program kezd futni. Az operációs rendszer által végrehajtott műveletet követően – előbb-utóbb, esetenként jelentős kitérőkkel – általában a hívást követő utasítással folytatódik a hívó program végrehajtása.

Maga a rendszerhívás a legtöbb operációs rendszer és a legtöbb processzor esetén egy programozott megszakítás előidézésével történik meg. A szubrutinhívástól – amelyre a legtöbb processzor külön gépi utasítást tartalmaz – abban tér el, hogy végrehajtásakor a visszatérési cím mentése és vezérlésátadás mellett a processzor működési módját (védelmi állapotát) is meg kell változtatni, felhasználói (user) módból a privilegizált utasítások végrehajtását is megengedő rendszer (system) módba kell átkapcsolni.

A rendszerhívás programozott megszakítással történő megoldása amellett, hogy megoldja a működési mód átváltását, a lehető legnagyobb mértékben függetleníti is egymástól a hívó programot és az operációs rendszert. Az ope­rációs rendszerből a hívó csak egyetlen belépési pontot ismer. Információcsere a hívó és az operációs rendszer között csak paraméterátadással történik (általában még a végrehajtandó műveletet is átadott paraméter jelöli ki).

Az alkalmazások számára az operációs rendszer egy olyan gép, amelyik kiterjeszti a processzor utasításkészletét. A számítógép és az operációs rendszer együtt egy kiterjesztett utasításkészletű, új gépet alkot, amelyik a processzor utasításkészletén kívül tartalmazza az operációs rendszer műveleteit is. Ez a kiterjesztett gép a futtatható programok rendelkezésére áll.

Természetesen a programok írásakor és fordításakor is számíthatunk erre a kiterjesztett utasításkészletre, noha a használt programnyelv az operációs rendszer felületét gyakran elfedi. A programozó számára a programozási nyelv – hacsak nem assembly nyelvű programozásra gondolunk – eleve ma­ga­sabb szintű műveleteket enged meg, mint a processzorok gépi nyelve. Ezek a műveletek vagy fordításkor fejtődnek ki gépi utasítássorozattá, vagy a nyelv ún. futtató rendszere tartalmazza a komplex műveleteket megvalósító eljáráskönyvtárat, és a fordító a komplex műveletet megfelelően paraméterezett szubrutinhívássá fordítja. Az operációs rendszert tehát a nyelvi szint elfedi a programozó elől. A rendszerhívások nem közvetlen nyelvi utasítások formájában használhatók, hanem a nyelv által megengedett – általában eljáráskönyvtárakkal megvalósított – komplex műveletekbe épülnek be. A rendszerhívást még akkor is be kell illeszteni a nyelv szintaxisába, ha a nyelvi utasítás pontosan az adott rendszerhívás megfelelő paraméterekkel történő meghívását eredményezi, és semmivel sem többet. Ezt a szintet ragadja meg például a POSIX-szabvány, amelyik az operációs rendszer programozói felületét a C nyelvi elérés megadásával definiálja.

Az alkalmazási felület nyelvi szintű megragadása abból a szempontból is előnyös, hogy a felület ezzel processzorfüggetlenné válik. Az elterjedt programnyelvek, különösen a C nyelv, fordítóprogramjai sokféle processzorra tudnak kódot generálni. A C nyelvű forrásprogram így hordozható, hiszen a rendszerhívásokat is a megfelelő processzor figyelembevételével generálja a fordító.

1.3.3.3. Hardverfelület (Hardware Interface)

A hardver fejlődésének köszönhetően egyre újabb, nagyobb teljesítményű processzorok, be-/kiviteli eszközök, továbbá összekapcsolási módok, architektúrák alakulnak ki. Az operációs rendszerek működtetik a hardvert, igyekeznek hatékonyan kihasználni a hardver lehetőségeit. Ebben a pontban csak a kapcsolódási felület jellegét tárgyaljuk, azonban az operációs rendszer és a hardver szoros és összetett kapcsolatrendszere miatt külön pontot szánunk a számítógép-architektúrák tárgyalására.

Az operációs rendszer és a hardver kapcsolódási felülete több ponton valósul meg.

  • Az operációs rendszer maga is program, ami az adott számítógéprendszeren fut, tehát a processzor és az architektúra lehetőségei (utasításkészlet, regiszterkészlet, a rendszerhívás megvalósítása, megszakítási rendszer, címzési módok, be-/kiviteli rendszer) azok, amiket az operációs rendszer felhasználhat.

  • Az operációs rendszer kezeli a hardvereszközöket és egyben gazdál­kodási feladatokat is ellát. Az alkalmazások számára tárat, pro­cesszor­használatot, lemezterületet biztosít, végrehajtja az alkalmazások által kezdeményezett be-/kiviteli műveleteket. Az architektúra ismerete beépül az operációs rendszert alkotó programokba, meghatározza, hogy az operációs rendszer milyen erőforrás-kezelési és -gazdálkodási feladatokkal foglalkozzon, és ezek során milyen megoldások használata célszerű. Hatékony géphasználat ugyanis nyilvánvalóan csak a működtetett hardver tulajdonságainak ismeretében érhető el.

  • Az operációs rendszernek kezelnie kell a rendszerhez kapcsolódó be-/kiviteli eszközöket, amelyek igen heterogén csoportokból kerülhetnek ki, és a rendszer élettartama során új eszközök beillesztésére is sor kerülhet.

Az elsőként említett kapcsolódási pont egyszerűen azt jelenti, hogy az operációs rendszernek az adott processzoron, illetve rendszerarchitektúrán kell futnia, ezekhez illeszkednie kell a működőképesség érdekében. Az elterjedten alkalmazott operációs rendszereknek ezért külön-külön verziójuk van a különböző processzorokra. Egy-egy géptípus különböző kiépítésű konfigurációihoz pedig telepítéskor illeszthetők az operációs rendszerek (telepítés, rendszergenerálás). A tervezők szokásos törekvése, hogy az operációs rendszer processzortól, illetve kiépítéstől függő kódrészeit lehetőleg külön modulokba helyezzék (ez a UNIX és a Windows NT esetén is megfigyelhető).

A második kapcsolódási pont tekintetében is a fenti alapelv érvényesül. Kialakult a kezelendő erőforrások egy egységes absztrakciója (például tár, processzoridő, lemezterületek, fájlok stb.), amelyek gyakorlatilag valamennyi rendszer esetén használhatók. Ezek kezelésének algoritmusai is jelentős részben közösek lehetnek. Az algoritmusoknak azonban vannak hardverfüggő részei (például tárallokáció a lehetséges címzési módokhoz igazítva, környezetváltás a konkrét regiszterkészlet figyelembevételével), amelyek ugyancsak a hardverfüggő modulokba kerülhetnek.

A harmadik kapcsolódási pont a be-/kiviteli eszközök csatlakoztatási felülete. Míg egy rendszer életében a processzor- és architektúra-váltás meglehetősen ritka, készülékcsere, vagy új készülék beiktatása sokkal gyakoribb. Egy új eszköz hozzákapcsolása a rendszerhez egyrészt megfelelő hardvercsatlakoztatás, másrészt megfelelő kezelő program (driver) segítségével történik. A készülékek választéka gyakorlatilag korlátlan, minden készülék rendelkezhet olyan specialitásokkal, amelyek csak rá jellemzőek. Az operációs rendszert gyakorlatilag lehetetlen felkészíteni arra, hogy minden elképzelhető készüléket tudjon kezelni. Ezért a készülékeknek is kialakult egy egységes absztrakciója, aminek lényege, hogy a rendszer a készülékeket azonosítani tudja, és egységes módon tud velük párbeszédet folytatni. A párbeszéd a készülékkezelő programokon (device driver) keresztül valósul meg. A készülékkezelő programok tehát az operációs rendszer többi részéhez egységes felületen csatlakoznak, de ismerik a készülék részletes működését, és az operációs rendszer egységes felületén kapott parancsokat a specialitások ismeretében hajtatják végre a konkrét eszközökön. (Például egy mágneslemez egység különböző módon, különböző vezérlőegységeken keresztül kapcsolódhat a rendszerhez. Az operációs rendszer számára ez az egység adatblokkok sorozatát tároló készülék, amire kiadható például egy „olvass blokkot” parancs. A készülékkezelő program ismeri a vezérlő és a lemezegység közötti munkamegosztást, tudja, hogy ha nincs bekapcsolva a lemezegység motorja, akkor azt először neki kell-e elindítania és aztán megvárnia a megfelelő fordulatszám elérését, majd elvégeztetnie az olvasást, avagy ezeket a vezérlőegység saját hatáskörében elintézi, és elég egyszerűen továbbadni az olvasás parancsot a vezérlőegységnek.)

Érdekes „munkamegosztás” van az operációs rendszerek szállítói és a készülékgyártók között. Az operációs rendszer szállítója általában mellékeli a nagyobb készülékgyártók tipikus eszközeihez a kezelőprogramokat. Természetesen nem tud felkészülni minden készülékre. Más oldalról a készülékszállítók mellékelik az eszközhöz tartozó kezelőprogramokat különböző operációs rendszerekhez.

Összességében tehát a be-/kiviteli készülékek csatlakoztatása kettős szabványosítást igényel, egyrészt egy szabványos hardvercsatlakoztatást, másrészt a készülékkezelő program számára egy szabványos szoftvercsatlakoztatást. Az operációs rendszer kezelői felülete pedig megfelelő eljárást kínál a rendszermenedzser számára a készülék és a kezelőprogram csatlakoztatására.

1.3.4. Számítógép-architektúrák

A mikrokontrollerektől a szuperszámítógépekig és elosztott számítási rendszerekig a különböző méretű, teljesítményű és szerkezetű hardverek széles skálája az, amit operációs rendszerrel kell működtetni. Meglehetősen nehéz megtalálni ezekben a rendszerekben azokat a közös vonásokat, amelyek meg­határozzák, hogy mit kell tennie az operációs rendszernek a hatékony mű­ködtetés érdekében.

Illusztrációként három jellegzetes hardverfelépítést mutatunk be, egy egyszerű mikrogépet, egy tipikus személyi számítógépet, valamint egy szuperszámítógépet.

1.3.4.1. Egyszerű mikrogép

Az egyszerű mikroszámítógép felépítését az 1.7. ábra mutatja.

Az egyszerű mikrogép egyetlen sínnel rendelkezik, amelyet mind a CPU-memória, mind a B/K (beviteli/kiviteli) forgalom terhel. A CPU egyben a sínvezérlő szerepét is betölti. Esetleges kezelőszervek a soros/párhuzamos portokra csatlakoztathatók. A DMA-vezérlő képes önállóan szervezni a lemez – memória közötti blokkátvitelt, az adatforgalom azonban a rendszersínt veszi igénybe. A rendszersín használatának szervezésére a DMA-vezérlő és a CPU között külön jelforgalom van. A sín lehetőséget ad megszakításkérések továbbítására is.

1.7. ábra. ábra - Egyszerű mikrogép architektúrája

Egyszerű mikrogép architektúrája


1.3.4.2. Jellegzetes személyi számítógép

Egy jellegzetes személyi számítógép architektúráját mutatja be az 1.8. ábra. Az architektúra lényegesen bonyolultabb, és olyan megoldásokat tartalmaz, amelyeket korábban csak a nagyszámítógépekben alkalmaztak. A gyor­sí­tótár megfelelő találati arány esetén lehetővé teszi, hogy a memória a CPU-utasítás végrehajtásával egyidejűleg a B/K-adatforgalom számára is rendelkezésre álljon. A grafikus vezérlő saját videomemóriával és intelligens processzorral rendelkezhet, aminek hatása, hogy a grafikus műveletek nem vesznek igénybe nagy sávszélességet a PCI-sínen.

1.8. ábra. ábra - személyi számítógép architektúrája

személyi számítógép architektúrája


A bővítősín általában lassabb külső készülékek csatlakoztatására ad lehetőséget, külön vezérlő hajtja meg, biztosítva befelé a megfelelő hatékonyságú sínfoglalást. Természetesen a sín megszakításkéréseket is tud továbbítani. Két további vezérlő (IDE és SCSI) ad lehetőséget jellegzetesen lemezegységek csatlakoztatására, ugyancsak autonóm blokkátviteli képességekkel.

1.3.4.3. Szuperszámítógép

Az 1.9. ábra a Convex Exemplar számítógépcsalád belső felépítését mutatja, amelyik lehetővé teszi, hogy 128 processzor (HP PA-RISC típusúak) hatékony együttműködésével alakuljon ki igen nagy teljesítményű számítási rendszer. Az építkezés hierarchikus, kettős processzoregységekből négy építhető egy hipernódba. Minden CPU saját gyorsító utasítás- és adattárral (cache) rendelkezik. A hipernódhoz egy B/K-alrendszer is tartozik. A crossbar kapcsolóhálózat a processzorpárok, valamint a B/K-alrendszer hatékony és átlapolt kapcsolatát teszi lehetővé a négy memóriablokkal. A memóriablokkok tartalmazzák a hipernód saját adatterületét, a közös tár egy adatterületét, valamint a hipernódok kapcsolatának hatékonyságát fokozó belső hálózati gyor­sí­tótárak területét. A hipernódokat négy SCI (Scalable Coherent Interface) szabvány szerint kialakított gyűrű kapcsolja össze. A rendszerben valamennyi processzor számára rendelkezésre áll a memóriában egy közös címtartomány, amely valójában egy elosztott, koherens gyorsítótárral támogatott memóriá­val valósul meg.

1.9. ábra. ábra - Szuperszámítógép-architektúra

Szuperszámítógép-architektúra


Ha általános következtetéseket akarunk levonni a bemutatott architektúrákból, azt állapíthatjuk meg, hogy egy bizonyos számítási teljesítmény alatt az architektúrák megtartják a gépi utasításkészlet szintjén a Neumann-modell szerinti szekvenciális utasítás-végrehajtást, de legalábbis ennek a látszatát, és ennek, valamint az ezzel átlapolódó B/K-műveleteknek a támogatására adnak egyre hatékonyabb eszközöket. A valódi működés elosztottá és többszálúvá válik, azonban ez a programozó elől rejtve marad.

A nagyobb teljesítménykategóriákban már a gépi utasítások szekvenciális végrehajtásának látszata sem marad meg, a magasabb (nyelvi, operációs rendszer) szintű fogalmak hatékony megvalósítása a cél. A szuperszámítógépek egyik alkalmazási stílusa, hogy a magasszintű nyelveken íródott programokban a fordítók megkeresik a párhuzamosítható műveleteket (például vektor- és mátrixműveletek) és az adott hardverarchitektúrán hatékonyan futó kódot generálnak. A másik alkalmazási stílus a műveletvégrehajtás párhuzamosítását a programozó kezébe adja és speciális operációs rendszerekkel és programozási nyelvekkel támogatja.

1.3.5. Belső szerkezet

Az operációs rendszerek meglehetősen nagy és bonyolult rendszerek. Létrehozásuk során – mai szemmel – a nagy és bonyolult rendszerek valamilyen fejlesztési módszertanát célszerű alkalmazni, amelyek lényeges alapelve a rendszer részekre bontása (dekompozíció), és az általánosítás, azaz a részletek elrejtése (absztrakció). A módszeres fejlesztés eredményeként általában egy jól strukturált (áttekinthető, a feladat fogalomrendszeréhez igazodó) rendszer jön létre. Egy zavaró tényező azonban nem hagyható figyelmen kívül: az operációs rendszerek futási idejű hatékonysága (minél kisebb tár és minél kevesebb processzoridő felhasználása a feladatok teljesítéséhez) fontos szempont (még ma, a kissé indokolatlanul felfokozott teljesítmény- és tárigények korában is). A tiszta struktúra és az adott esetre vonatkozó maximális hatékonyság pedig általában ellentmondó követelmények.

Említésre méltó, hogy a fejlesztési módszertanokra vonatkozó igény (és a szoftverkrízis tudatosodása) jelentős részben a korai multiprogramozott operációs rendszerek fejlesztési problémáinak köszönhető. (Különösen nagy szerepe volt a legendás IBM 360 sorozatra készült, univerzális, OS 360 operációs rendszer hibáinak.) Ezek a rendszerek monolitikus szerkezetűek voltak, azaz egységes rendező elv szerinti belső struktúrájuk nem ismerhető fel.

A későbbi rendszerekben általában felismerhető a strukturált programozási szemlélet eredményeként kialakult rétegszerkezet, illetve a moduláris programozási elvek szerinti modulszerkezet. Napjainkra a hordozhatóság és a hardver lehetőségeinek hatékony kihasználása vált a belső szerkezet kialakításának fő szempontjává.

1.3.5.1. Rétegek és modulok

A strukturált programozás alapelveinek következetes betartása (eljárás­absztrakción alapuló lépésenkénti finomítás) rétegszerkezetű programrendszert eredményez. A rétegek hierarchikusan egymásra épülnek. Minden réteg úgy fogható fel, hogy az alatta lévő réteget – mint virtuális gépet – használva egy bonyolultabb virtuális gépet valósít meg a felette elhelyezkedő réteg számára. Ebből következik, hogy minden réteg csak a közvetlen alatta elhelyezkedő réteg „utasításkészletét” használhatja.

A moduláris programozás dekompozíción alapuló megközelítése szerint a nagy programokat szét kell vágni külön kezelhető részekre, modulokra. A mo­dulok belseje a külvilág (többi modul) számára rejtett, a modulból csak az ál­tala mutatott csatlakozási felület érhető el más modulok számára (interface). A modulokat lehetőleg úgy kell kialakítani, hogy a közöttük lévő csatolás minimális, a modul összetartó ereje (kohézió) pedig maximális legyen. Tapasztalatok szerint a maximális kohéziót és minimális csatolást egy-egy komplex adatszerkezetet és a rajta végezhető műveleteket összefogó modul eredményezi, amelyik eljárás-interfésszel és paraméterátadással tart kapcsolatot más modulokkal. Lényegében a ma legelterjedtebb objektumorientált dekompozíció is ezen az elven alapul. Mindemellett más, gyakorlati szempontok indokolhatják a modulok más elvek szerint történő kialakítását (például a rétegszerkezet mentén történő modularizálás, adatmodulok, vezérlőmodulok, interfészmodulok kialakítása stb.).

Illusztrációként bemutatjuk a THE és a VENUS operációs rendszerek rétegszerkezetét (1.10. ábra). A THE operációs rendszert (elsősorban kötegelt feldolgozásra) E. W. Dijkstra (a strukturált programozás és a szemafor atyja) és munkatársai fejlesztették ki és publikálták 1968-ban. 1970-ben Brinch Hansen javasolta elsők között a rendszermag (kernel, nucleus) kialakítását az operációs rendszer alapfunkcióinak megvalósítására. A két munka nyomán fejlesztették ki Liskov és munkatársai az inkább időosztásos üzemmódra szánt VENUS operációs rendszert, amelynek alsó öt rétegét mikroprogra­mo­zottan valósították meg (1972).

1.10.ábra. táblázat - Nevezetes operációs rendszerek rétegszerkezete

6. réteg

Felhasználói programok

5. réteg

Készülékkezelés és ütemezés

4. réteg

Virtuális tár

3. réteg

B/K-csatornák

2. réteg

CPU-ütemezés

1. réteg

Parancsértelmező

0. réteg

Hardver


1.12.ábra. táblázat - A virtuális hardver megvalosító rendszer és közös kernel

5. réteg Felhasználói programok

4. réteg B/K-pufferelés

3. réteg Operátori konzol kezelése

2. réteg Tárkezelés

1. réteg CPU-ütemezés

0. réteg Hardver


A rétegszerkezet kialakítása messze nem egyértelmű, hiszen például a háttértárat kezelő program maga is hasonlóan működhet, mint egy felhasználói program, mivel működése során várakozásokra kerülhet sor. Ezért indokolt őt a CPU-ütemező réteg fölé helyezni. Ugyanakkor a CPU-ütemező bonyolultabb rendszerekben dönthet úgy, hogy egy programot kisöpör a memóriából háttértárra, amihez szüksége van a háttértár-kezelő szolgáltatásaira. Ez a szempont éppen fordított réteghierarchiát indokolna. Úgy is fogalmazhatnánk, hogy a réteghierarchia és az ésszerű, funkcionális modulszerkezet ortogonálisan alakul ki. A rétegszerkezet másik problémája, hogy a szigorú hierarchia betartása sok üresjáratot okoz. Egy mélyebb rétegben megvalósított szolgáltatás használata ugyanis több rétegen át érdemi funkció nélkül végrehajtott eljáráshívásokat és paraméterátadásokat eredményez, ami rossz hatékonyságra vezet.

A réteges szerkezet problémái miatt a későbbi operációs rendszerek már nem törekedtek tiszta rétegszerkezetre, hanem kevés réteget és inkább több funkcionális modult alakítottak ki.

1.3.5.2. Tipikus modulok

Az operációs rendszerek feladataiból adódóan számos rendszerben a tipikus funkcióknak megfelelő modulszerkezetet találunk. A szokásos alapvető funkciócsoportok a következők:

  • folyamatkezelés,

  • tárkezelés,

  • fájlkezelés,

  • be-/kivitel kezelése,

  • háttértár kezelése,

  • hálózatkezelés,

  • védelmi és biztonsági rendszer,

  • parancsértelmezés,

  • felhasználóbarát kezelői felületek.

A fenti funkcionális modulok megjelenése mellett a rétegszerkezet abban nyilvánul meg, hogy

  • a hardverfüggő részek egy alsó, hardverközeli rétegbe kerülnek;

  • az operációs rendszer alapfunkciói a rendszermagban (kernel) valósulnak meg, amely egyre inkább csak a minimálisan szükséges funkciókat tartalmazza (mikrokernel);

  • a feltétlen szükségest meghaladó kényelmi szolgáltatások a felhasználói programokhoz hasonló rendszerprogramokba (rendszerfolyamatokba, alrendszerekbe) kerülnek;

  • megjelenik a felhasználói programokból érkező rendszerhívások fogadó felületét megvalósító réteg.

1.11. ábra. ábra - A UNIX és az OS/2 rétegszerkezete

A UNIX és az OS/2 rétegszerkezete


Illusztrációként bemutatjuk a UNIX rendszerek és az OS/2 operációs rendszer belső szerkezetét, de a fentiekhez hasonló tendencia figyelhető meg a Windows NT rendszer egymást követő verzióin is (1.11. ábra).

1.3.5.3. Virtuális hardver

A kernelkoncepció lényege, hogy a felhasználói és a rendszerprogramok számára a processzor utasításkészletének kiterjesztésével a kernel egy virtuális gépet jelenít meg. Mind a felhasználói, mind a rendszerprogramok futásuk során tehát egyrészt a processzor utasításkészletét (eltekintve a privilegizált utasításoktól), másrészt a kernel által nyújtott, rendszerhívással elérhető műveleteket használhatják. A rendszerben egyetlen kernel és több aktív program van jelen, a programok tehát mind a valódi processzort, mind a kernelt közösen, megosztottan használják. Ez azt jelenti, hogy nem csak a valódi processzort, hanem a kernelt is multiprogramozottan kell használni, azaz a processzor állapotának elmentéséhez hasonlóan a kernel állapotát is menteni kell, amikor egyik programról a másik futtatására vált át a rendszer.

Az IBM kutatóinak ötlete volt, hogy a kernel alatt elhelyezkedő rétegbe olyan funkció kerüljön, amelyik egyszerűen a fizikai eszközök megosztott használatára ad lehetőséget, nem kiterjesztett, hanem pontosan a fizikai processzorral és eszközökkel azonos felületen. Így minden felhasználó egy saját virtuális hardvert lát, amelyen elvileg tetszőleges kernelt, operációs rendszert futtathat (általában egyfelhasználós, interaktív üzemmódban) (1.12. ábra). A megoldást először az IBM 360/67-es számítógépre dolgozták ki (1970), kereskedelmi forgalomba pedig az IBM VM/370 operációs rendszerben került (1979).

2.9.ábra. táblázat - Többpéldányos erőforrások pillanatnyi allokációja és igénylése

Alkalmazás

Alkalmazás

Alkalmazás

Kernel

Hardver

Alkalmazás

Alkalmazás

Alkalmazás

Kernel

Kernel

Kernel

Virtuális hardver

Hardver


Közös kernel Virtuális hardver privát kernelekkel

A virtuális hardver gondolatának továbbvitele napjainkban ismét népszerű. A felhalmozódott szoftverkincs felhasználásának egyik problémája a hardver-kompatibilitás hiánya. Ezen is segíthet a virtuális hardver vagy hardveremuláció. Jellegzetes példák a Sun és DEC processzorain futó operációs rendszerek virtuális Intel CPU-ja, az Apple Macintosh virtuális Motorola 68000 processzora. A JAVA-programok kompatibilitásának kulcsa ugyancsak a JVM (Java Virtual Machine) virtuális gép, amelyik bájtkód szinten definiált utasításkészletet képes végrehajtani.

Ebbe a sorba illeszkedik az MIT (Massachusetts Institute of Technology) kutatóinak exokernel koncepciója (1995), amelyik ugyancsak a legalsó szintre helyezi a hardver multiplexelésének feladatát, és az egyes felhasználóknak a kívánt hardver-erőforrásokhoz biztonságos, védett hozzáférést nyújt. Ez a szint azonban semmiféle további kiterjesztett funkciót nem valósít meg a hardverhez képest.

1.3.5.4. Kliens–szerver szerkezet

A kernel minimalizálása és a rendszerszolgáltatások rendszerprogramokkal történő megvalósítása a szerkezeti tisztaság és a hatékonyság jó kompromisszumának látszott. Találkozott ez a tendencia a hardver lehetőségeinek bő­vülésével, többek között azzal, hogy egyetlen rendszeren belül több processzor működik. Ez egyrészt több CPU-t jelenthet, másrészt speciális (aritmetikai, sínvezérlő, készülékvezérlő stb.) processzorokat. A multiprogra­mo­zás nyújtotta látszólagosan párhuzamos végrehajtással szemben a több procesz-szor lehetőséget ad a programok valóban párhuzamos végrehajtására. A hard­verfüggetlenségre való törekvés jegyében megnőtt azoknak a modelleknek a jelentősége, amelyeket követve olyan programokat hozhatunk létre, amelyek változtatás nélkül, hatékonyan futtathatók akár egyetlen processzoron multiprogramozottan, akár több processzoron, multiprocesszálással.

Ezeknek a követelményeknek megfelel a kliens–szerver-modell. Lényege, hogy adott funkciókért egy program felelős, amelyik a funkciók ellátásához szükséges erőforrásokat is kezeli. Ennek a programnak (szolgáltató, szerver) a szerepe a többiek (ügyfél, kliens) kiszolgálása az adott funkciók tekintetében. Az ügyfél üzenetet küld a szolgáltatónak, ami tartalmazza a kért műveletet és a szükséges paramétereket, és megvárja a szolgáltató válaszát. A szolgáltató fogadja az ügyfelek kéréseit, elvégzi a kért műveleteket és az eredményekről válaszüzenetben tájékoztatja az ügyfeleket.

Ragadjuk ki egy operációs rendszer néhány funkcióját, például a fájlkezelést, a folyamatkezelést és a felhasználóbarát kezelői felület nyújtását (például grafikus terminálon). Bízzuk ezeket a feladatokat egy-egy szolgálta­tó­prog­ramra! Szükség esetén a szolgáltatók természetesen egymás szolgálatait is igénybe vehetik. Az így kialakuló szerkezetet az 1.13. ábra mutatja. A rendszerben a kernel elsődleges szerepe az üzenetek pontos és biztonságos közvetítése. A szolgáltatók

1.13. ábra. ábra - Kliens-szerver szerkezetű rendszer

Kliens-szerver szerkezetű rendszer


változtatás nélkül működnek akkor is, ha a szerverek külön-külön processzoron futnak. Természetesen a kernelnek ilyenkor ismernie kell a szereplők elhelyezkedését, és az üzenetközvetítés során használnia kell a processzorok közötti adatátvitel eszközeit.

1.3.6. Működés

Ez a pont az operációs rendszerek működését, azaz jellegzetes belső vezérlési szerkezetét tárgyalja. A programokkal kapcsolatban a vezérlési szerkezet az egyes utasítások végrehajtási sorrendjének előírását jelenti. Arra keressük tehát a választ, hogy mikor mit csinál a program.

A hagyományos programok esetén megszoktuk, hogy az utasítások végrehajtása a processzor működésének megfelelően, sorosan történik, azaz egy utasítás befejezése után kezdődik a következő utasítás végrehajtása. A programnak van kezdete, ahonnan a végrehajtás elkezdődik, és – esetleg adatfüg­gő útvonalon – halad a program végéig. A processzort a program végrehajtásának menetéből csak egy megszakításkérés elfogadása tudja kizökkenteni. Ilyenkor a processzor úgy tér át automatikusan a megszakításhoz rendelt kiszolgáló program végrehajtására, hogy a megszakított programot később folytatni tudja. A megszakítási rendszer célja és értelme az, hogy a rendszer valamilyen külső, esetleg belső történésre gyorsan tudjon reagálni.

Az operációs rendszer működésének vizsgálatakor legyen az a kiinduló állapotunk, hogy a CPU éppen egy felhasználói program utasításait hajtja végre. Az operációs rendszer ilyenkor nyugalomban van. Mi hozhatja működésbe?

  1. A futó program rendszerhívást hajt végre.

  2. A processzor külső megszakításkérést fogad el.

  3. Hibamegszakítás (exception) következik be.

Bár a rendszerhívás a hívó program szándéka szerinti vezérlésátadás, meg­valósítása a legtöbb rendszeren programozott megszakítással történik. Így mondhatjuk, hogy az operációs rendszert mindig megszakítás hozza működésbe, azaz működését a megszakítást kiváltó események vezérlik. Az egyes pontokban tárgyalt megszakítások azonban néhány fontos tulajdonságban különböznek, ezért indokolt a külön csoportba sorolásuk.

Az operációs rendszernek van néhány olyan alapfunkciója, amelyik látszólag elemi, de működése nem korlátozódik egyetlen rendszerhívás, vagy megszakítás hatására végrehajtott utasítássorozatra, hanem vezérlési szerkezetében bonyolultabb megoldást igényel. Ezek közül a B/K-műveletek és a kezelői parancsok végrehajtását, valamint az időmérést tárgyaljuk.

A működés két sajátos szakasza a rendszerindítás és rendszerleállás folyamata. Az operációs rendszer funkcióit általában „állandósult” állapotban tárgyaljuk, azonban mindennapi tapasztalatainkból is tudjuk, hogy mind az indítás, mind a korrekt leállítás olyan folyamat, amelynek során a rendszer speciális üzemállapotban működik, és ezek a műveletek elég időigényesek lehetnek. Röviden ezzel a kérdéssel is foglalkozunk.

1.3.6.1. Rendszerhívások kezelése

A rendszerhívás általában programozott megszakítást okoz. Hatására az adott processzor megszakítási rendszerének mechanizmusa szerint az operációs rendszer egy meghatározott belépési pontjára kerül a vezérlés. Az elvégzendő műveletet, valamint annak paramétereit a rendszer konvenciói szerint átadott paraméterekkel jelöli ki a hívó program. Az operációs rendszer a műveletet kijelölő paraméter szerint elágazva végrehajtja a műveletet, majd az esetek többségében visszatér a hívó programhoz.

Néhány esetben azonban nem a hívó programhoz való visszatérés történik. Ilyen esetek lehetnek:

  • a program befejeződését jelző rendszerhívás, amikor a program által használt erőforrások felszabadíthatók, esetleg új program (például a job következő lépése) betöltése és indítása következhet,

  • erőforrás-igénylés (például munkaterület a tárban vagy lemezen, kizárólagos periféria- vagy fájlhasználat stb.), amit a rendszer éppen nem tud kielégíteni, emiatt a hívónak várakoznia kell,

  • várakozás másik program jelzésére vagy üzenetére, ami még nem érkezett meg, emiatt a hívónak várakoznia kell,

  • adott időtartamú késleltetés vagy adott időpontra való várakozás,

  • újraütemezés kérése, azaz lemondás a futásról esetleges fontosabb feladatokat megoldó programok javára,

  • B/K-művelet indítása, aminek végrehajtása alatt a hívó várakozik.

Amikor egy rendszerhívás következtében a hívó program várakozásra kény­szerül, az operációs rendszer megőrzi a program állapotát, de a várakozás idejére más program végrehajtásáról intézkedik. A hívás helyére való visszatérés tehát késleltetve lesz mindaddig, amíg a várt feltétel nem teljesül, és a rendszer úgy nem dönt, hogy ismét az adott programot futtatja.

A hívó program számára a várakozás a legtöbb esetben nem jelent a szekvenciális végrehajtástól eltérő működést, számára logikailag a várakozás mindössze annyit jelent, hogy a rendszerhívás „lassan” hajtódik végre (szinkronművelet).

Néhány rendszer lehetővé tesz aszinkron rendszerhívásokat is, jellegzetesen a B/K-műveletek, valamint a programok együttműködését szervező mű­ve­letek esetén. Az aszinkron B/K-rendszerhívás a kért B/K-művelet elindítása után visszatér a hívóhoz, a hívó program a B/K-művelettel párhuzamosan folytatódhat, és külön rendszerhívás szolgál az átvitel befejeződésének lekérdezésére, illetve az arra való várakozásra.

Más rendszerek arra adnak lehetőséget, hogy egy program megadjon egy olyan belépési pontot a saját címterében, amelyikre a rendszer valamilyen esemény bekövetkezésekor (például B/K-művelet befejeződése, másik program jelzésének megérkezése) adja át a vezérlést. Így a felhasználói program tulajdonképpen egy külső eseményre induló ágat, azaz egy megszakításkezelés jellegű programrészt is tartalmaz, amelyik azonban természetesen felhasználói módban fog végrehajtódni.

A rendszerhívások hatására kialakuló jellegzetes vezérlési szálakat az 1.14. ábra szemlélteti.

1.14. ábra. ábra - Vezérlési szálak különböző típusú rendszerhívások esetén

Vezérlési szálak különböző típusú rendszerhívások esetén


1.3.6.2. Be-/kivitel végrehajtása

A multiprogramozás a CPU kihasználásának javítását úgy éri el, hogy egy program B/K-műveleteinek idején más programot futtat a processzoron. Természetesen a megvalósítás feltétele, hogy a hardverarchitektúra adjon lehetőséget a B/K-műveletek és a programutasítások valódi párhuzamos végrehajtására (B/K-vezérlőegységek, pufferelés, megszakítási rendszer).

A B/K-műveletekre rendszerhívások állnak rendelkezésre. Vizsgáljuk a szink­ron rendszerhívások esetét, tehát a hívó program akkor folytatódik (a rendszerhívást követő utasításon), amikor a B/K-művelet már befejeződött. A rend­szerhívás hatására működésbe lépő operációs rendszer a kapott paramétereknek megfelelően elindítja a B/K-műveletet, például úgy, hogy felprogramozza és elindítja a B/K-készülék vezérlőegységét. Ettől kezdve a B/K-művelet az illesztési módnak megfelelő szervezésben (megszakításosan, DMA-használattal stb.) megy a maga útján. Az operációs rendszer megjegyzi, hogy az átvitel befejeződésére a hívó program vár, majd választ egy másik futtatható programot, és a „visszatérés rendszerhívásból” műveletet úgy hajtja végre, hogy ez a kiválasztott program folytatódjon.

A B/K-művelet befejeződését a B/K-vezérlő megszakításkéréssel jelzi. A megszakításkérés hatására ismét az operációs rendszer lép működésbe, észleli, hogy a B/K-művelet befejeződött.

(Megjegyzés: Ha a B/K-művelet karakterenkénti, vagy bájtonkénti megszakítással zajlik, akkor az operációs rendszer – a készülékhez rendelt megszakítási rutin – karakterenként működésbe lép, és programozottan viszi át a következő karaktert a memória és a B/K-készülék adatregisztere között. Ilyenkor az átvitel közben egyszerű „visszatérés megszakításból” művelettel zárul az operációs rendszer aktuális futama. Ha a megszakítási rutin észleli, hogy vége az átvitelnek, azaz éppen az utolsó megszakításra reagált, akkor kell végrehajtani azokat a lépéseket, amelyeket például DMA-szervezés esetén az egyetlen, átvitel végét jelző megszakítás kiszolgálásakor.)

Ez egyben azt jelenti, hogy a befejeződött B/K-műveletre várakozó program folytatható, és ezt az operációs rendszer megjegyzi. Nem jelenti azonban azt, hogy a várakozó programot azonnal folytatni kell, hiszen a B/K-megszakítás egy másik, futó programot szakított meg, a CPU tehát nem volt tétlen. Az, hogy végül mikor folytatódik a várakozó program, az operációs rendszer további döntésétől függ.

Némi bonyodalmat okoz, hogy egy program, amelyik egy másik program B/K-műveletével párhuzamosan éppen fut, elindíthat egy újabb B/K-műveletet ugyanarra a készülékre. Ilyenkor a rendszerhívás végrehajtásakor az operációs rendszer nem tud azonnal intézkedni az átvitel indításáról, hiszen a készülék még foglalt, vezérlőjének regiszterei még az előző átvitel adatait tárolják, átírásuk hibát okozna. A megoldás az, hogy az átvitel paramétereit meg kell jegyezni, a hívót ugyanúgy várakoztatni kell, mintha az átvitel azonnal indítható lett volna, és új futtatható programot kell választani. Az átvitel a megjegyzett paraméterekkel akkor indítható el, amikor a készülék felszabadul (ezt az operációs rendszer észleli az előzőekben elmondottak szerint).

1.15. ábra. ábra - Be-/kivitel lefolyása multiprogramozott rendszerben

Be-/kivitel lefolyása multiprogramozott rendszerben


Továbbgondolva a lehetőségeket beláthatjuk, hogy a fenti ráindítás többszöröződhet. Egy adott pillanatban tehát nemcsak a CPU-ra várakozhat több program, hanem egy B/K-készülékre is több átviteli kérelem. Az operációs rendszernek ezért a B/K-készülékekre is várakozási sort kell szerveznie.

Egy B/K-rendszerhívás végrehajtásának menete a fentiek szerint a következőképpen foglalható össze:

  • az operációs rendszer működésbe lép a rendszerhívás hatására, és a kö­vet­kezőket teszi:

    • a B/K-kérelmet az indításhoz szükséges paraméterekkel a készülék várakozási sorába helyezi,

    • ha a készülék szabad, elindítja a B/K végrehajtását,

    • választ egy futtatható programot, és oda tér vissza,

  • az operációs rendszer B/K-megszakításokat fogad el, amelyekre reagál­va:

    • B/K végét jelző megszakítás esetén futtathatóvá teszi a befejeződött B/K-ra várakozó programot,

    • ha van várakozó B/K-művelet a készülékre, elindítja a következő B/K-műveletet,

    • ütemezési stratégiájától függően vagy új programot választ futásra, vagy visszatér a megszakított programra,

  • a B/K-rendszerhívást kiadó program akkor folytatódik, ha ismét futtathatóvá vált, és az operációs rendszer őt választotta futtatásra.

A folyamatot az 1.15. ábra szemlélteti.

1.3.6.3. Kezelői parancsok

A kezelői felületen az operációs rendszernek szóló parancsok érkezhetnek, valamint a kezelőnek szóló információk jelennek meg a rendszer állapotáról. A legegyszerűbb kezelői felületet a parancsértelmező nyújtja, jellegzetesen interaktív, karakteres eszközökön (terminálon). Egyfelhasználós, valamint interaktív, időosztásos rendszerekben az operációs rendszernek szóló parancsokat a felhasználó ugyanarról a terminálról adja, amelyik egyben az általa indított alkalmazásokkal való párbeszéd eszköze is. Ebben az esetben az operációs rendszerrel, illetve az alkalmazással folytatott dialógus elkülönítését meg kell oldani (időbeli elkülönítés, képernyő felosztása, ablakozás stb.).

Az egyszerű parancsértelmező felépítését és működését az 1.16. ábra mu­tatja.

1.16. ábra. ábra - A parancsértelmező szerkezete

A parancsértelmező szerkezete


Az operációs rendszer működése közben a terminál billentyűzetének meg­szakításkéréseit a terminálkezelő fogadja, leolvassa a leütött billentyű kódját, és átadja a parancssor-szerkesztőnek, amelyik egy belső tárban gyűjti és a képernyőn visszajelzi a beírt szöveget. A sorszerkesztő egyszerű javításokra (karakter visszatörlés, felülírás, beszúrás) lehetőséget ad. A parancs összeállítását követően egy érvényesítő végjel (szokásosan ENTER) leütésével jelzi a kezelő, hogy kéri a parancs végrehajtását. Ilyenkor a parancssor-szerkesztő átadja a belső tárat a parancsértelmezőnek, amelyik elemzi a sort (megkeresi és elkülöníti a paramétereket), és egy prioritási sorrend szerint megkísérli értelmezni és végrehajtatni a parancsot. A prioritás azt jelenti, hogy a parancsértelmező egy értelmezési sorrendet követ. Ha a parancs értelmes a rendszermag számára, akkor egy rendszerhívással elindítja a végrehajtást, ha nem, megkísérli rendszerprogramként értelmezni, ha így sem, akkor a parancsot egy alkalmazás nevének tekinti, és megpróbálja azt indítani.

A parancs végrehajtásának befejeződése után a tárolt parancssor törlődik és ismét a parancssor-szerkesztő kezd működni.

Ez a működés igen rugalmas abban a tekintetben, hogy az alkalmazások a rendszerparancsokkal azonos módon hajtathatók végre, azaz a kezelői felületen az operációs rendszer kiterjesztésének tűnnek.

A parancsvégrehajtás alapesetben szinkron szervezésű, azaz a parancs be­fe­jeződése előtt nem adható ki újabb parancs. Multitaszkos rendszerekben azonban lehetőség van aszinkron parancsindításra, amikor a kezelő egy parancs kiadását követően, annak befejeződése előtt újabb parancsokat adhat a rendszernek. Ilyenkor a parancsokat végrehajtó programok multi­progra­mo­zottan hajtódnak végre.

A bemutatott, legegyszerűbb kezelői felület sem része a kernelnek a legtöbb esetben, és egy operációs rendszerhez akár több kezelői felület is lehet használatban (lásd UNIX shell).

1.3.6.4. Külső megszakítások kezelése

A külső megszakítás egy számítógéprendszerben olyan eszköz, amelyik lehetővé teszi, hogy a rendszer gyorsan reagáljon egy előre nem látható időpontban bekövetkező külső jelzésre. A hardver a rendszerek nagy többségében prioritásos, vektoros megszakításkezelést biztosít.

Egy külső megszakítás elfogadásakor a processzor általában működési módot vált (rendszermódba kapcsol), és a megszakítási vektor által meghatározott címen folytatja a programvégrehajtást. Ezen a címen az operációs rendszer megfelelő része helyezkedik el és reagál a megszakításkérésre. A módváltás miatt fontos, hogy a teljes megszakítási rendszert – beleértve a vektortáblákat, a megszakítási programok címkiosztását is – az operációs rendszer kezelje, mert ellenkező esetben kijátszható lenne a védelmi rendszer. Ebből következik, hogy a megszakítási programok csak olyan reakciókat tartalmazhatnak, amelyek az operációs rendszer írásakor ismertek.

Sok esetben hasznos lehet, ha egyes felhasználói programokat, esetleg programrészleteket megszakítás hatására tudunk végrehajtatni. A rendszerek egy része ezért lehetőséget ad ilyen megoldásokra, azonban ezt áttételek beiktatásával teszi úgy, hogy a felhasználói programrészlet ne rendszer-módban fusson.

Külső megszakításkérések egy számítógéprendszerben jellegzetesen a B/K-készülékek működése során keletkeznek, amikor a készülék, vagy készülékvezérlő programozott kezelést igényel (például kész egy újabb adategység küldésére vagy fogadására, befejezte az átvitelt stb.).

1.3.6.5. Időmérés

Gyakorlatilag minden operációs rendszer tartalmaz időkezelési, időmérési funkciókat. Különösen fontos ez a lehetőség a valósidejű rendszerekben.

Szokásosan a rendszer vezet egy naptárat, amely kezelői paranccsal, vagy programmal lekérdezhető, illetve beállítható, és legalább másodperc felbontású. A további időkezelési feladatok között szerepelhet az egyes felhasználók processzoridő-felhasználásának nyilvántartása, késleltetett, illetve adott időpontra időzített programindítás, időzített jelzések, valamint egyes műveletekhez, eseményekhez rendelt időkorlát előírása a végtelen várakozások kiküszöbölésére.

Korrekt időmérés egy rendszerben csak hardverórával valósítható meg. Fizikailag az óra szorosan integrálódik a processzorhoz, rendszertechnikailag azonban általában egy speciális B/K-készülékként kezelhetjük. Az óra általá­ban egy pontos frekvenciájú kvarc-oszcillátor impulzusait számolja és felprogramozással beállítható, hogy hány impulzusonként kérjen megszakítást. Így egy igen pontos periódusidejű megszakításkérő egységhez jutunk, amely-lyel szemben elvárás, hogy megszakításait a periódusidőn belül lekezelje a rendszer. Ezeknek a megszakításoknak a számlálására építhető fel a további, szoftveres időkezelés. A megszakítás periódusideje meghatározza az operációs rendszer időkezelésének felbontását. Speciális esetekben, ha egyes funkciók finomabb felbontású időkezelést igényelnek, a rendszer lekérdezhetővé teheti a fizikai óra számlálóját, vagy B/K-készülékként további programozható órák iktathatók a rendszerbe.

Minden időmérés elvi problémája, hogy az időpontot jelentő szám folyton növekszik, és előbb-utóbb minden tároló túlcsordul (lásd 2000. év probléma). A felbontás és az átfogás megválasztása egy-egy rendszerben több szempontot mérlegelő tervezői kompromisszum eredménye.

1.3.6.6. Hibamegszakítások kezelése (kivételkezelés)

A számítógéprendszer működése során előfordulhatnak olyan hibák, amelyeket a hardver észlelni képes, de amelyek nem okozzák feltétlen a teljes rendszer működésképtelenségét. Ilyenek lehetnek egyrészt azok a tranziens hibák, amelyek esetleg a művelet ismétlésével javíthatók, illetve a programok olyan hibái, amelyek csak futási időben fedhetők fel, és végrehajthatatlan műveletet eredményeznek (például nemlétező memóriacímre való hivatkozás, nullával osztás, privilegizált utasítás végrehajtásának kísérlete felhasználói módban stb.). Ezekben az esetekben a hardver nem vált működésképtelenné, de a program továbbfuttatása feltehetőleg értelmetlen. A processzorok ezért ilyen esetekben hibamegszakítást (trap, exception) generálnak, aminek hatására a program folytatása helyett egy megszakítási program in­dul el, ami az operációs rendszer része.

Az operációs rendszer a hibamegszakítás feldolgozása során

  • visszaléphet a megszakított utasításra, ha tranziens hiba valószínűsíthető,

  • hibajelzést küldhet a kezelői konzolra,

  • abortálhatja a hibát okozó programot,

  • elindíthatja a felhasználói program hibakezelő részét (kivételkezelő, exception-handler),

  • diagnosztizáló programot indíthat.

Bizonyos esetekben a hibamegszakítás rendszerére komplex rendszerszolgáltatások építhetők. Ilyen például a későbbiekben részletezett virtuális tárkezelés, ahol a nemlétező címre való hivatkozás által okozott hibamegszakítás indítja el a keresett információ memóriából való betöltésének folyamatát.

A hibamegszakítások és a külső megszakítások között fontos különbség, hogy a hibamegszakítás utasítás közben keletkezik, és az aktuális utasítás nem tud befejeződni, míg külső megszakítást a processzor mindig két utasítás között fogad el, amikor a processzor az utasítás-végrehajtási ciklus kez­dő­pontján van. Ha az operációs rendszer a hibamegszakítást okozó program folytatása mellett dönt, a program tehát vagy a megszakítást okozó utasítás egy közbülső fázisától folytatható (ehhez meg kell őrizni az utasításon belüli processzorállapotot), vagy az utasítás ismétlésével, amihez nyomtalanul törölni kell az előző, félbemaradt végrehajtási kísérlet hatását (utasítás visszaállítás, rollback).

A kezelői konzolra küldött hibajelzések is okozhatnak problémákat. Sok esetben ugyanis a futó alkalmazás kezelőeszköze és az operációs rendszer kezelőeszköze ugyanaz a terminál. Különösen valósidejű, illetve beágyazott rendszerek esetén az alkalmazás kezelői felületén a felhasználó – esetleg például egy technológiát irányító diszpécser – az alkalmazás saját gondolatkörében mozog és dolgozik – például éppen technológiai folyamatábrán követ egy gyártási folyamatot. Az operációs rendszer – miután írója nem készülhetett fel minden lehetséges alkalmazásra – csak uniformizált, szűkszavú, többnyire csak kézikönyvek és részletes szakismeret birtokában értelmezhető hibaüzeneteket tud előállítani és kiírni. Egy ilyen üzenet a diszpécsernek nem igazán informatív, és könnyen pánikhelyzetet okozhat. Hasonló rendszereknél ezért előnyös, ha a felhasználói programban megadható az a pont (kivételkezelés, exception), ahova az operációs rendszer a hibamegszakítás során visszalép, és ahol az alkalmazásfüggő hibakezelés a saját állapot- és változótérben programozható. A folyamat hasonló az 1.14. ábrán bemutatott eseménykezelés-átvételhez.

1.3.6.7. Rendszerindítás és leállás

Az operációs rendszer két sajátos működési állapota a rendszerindítás (boot) és a rendszerleállítás (shut-down) folyamata. Aki kapcsolt már be UNIX vagy Windows NT operációs rendszert futtató számítógépet, tudja, hogy bizony mind az indítás, mind a leállítás folyamán az amúgy villámgyors rendszer jócskán „molyol” valamin, mire végre feláll a rendszer, vagy mire kikapcsolhatjuk a gépet.

A bajok egyik forrása az, hogy a számítógépek memóriái ma általában felejtő memóriák, azaz kikapcsoláskor, vagy tápkimaradáskor tartalmuk törlődik. A rendszerben tápkimaradásokat és egyéb katasztrófákat leginkább „túlélő” (perzisztens) tároló a mágneslemez. Bekapcsoláskor tehát az üres memóriában fel kell építeni a rendszert, és ehhez igen sok lemezműveletre van szükség. Kikapcsoláskor ennek a fordítottja játszódik le. A memória és a háttértár (lemez) kezelésében ugyanis a rendszerek igen sokféle hatékonyságnövelő trükköt alkalmaznak (pufferelés, virtuális tár, swapping stb.), aminek következménye azonban az, hogy a lemezen tárolt fájlrendszer és a memóriakép sem lesz minden pillanatban konzisztens. Ha lehetőség van a „rendezett” visszavonulásra (kikapcsolási folyamat), akkor a lemez konzisztenciája és az üzemállapot lemezre írása biztosítható, így a következő indítás várhatóan problémamentes lesz. Ugyanakkor egy váratlan tápkimaradás egy nagyobb rendszert igen kellemetlenül érint, a szünetmentes tápegységek ezért ilyenkor nélkülözhetetlenek.

A másik időigényes bekapcsolási műveletsorozat tulajdonképpen biztonsági és kényelmi okok miatt szükséges. A korszerű operációs rendszerek ugyanis az indítás során feltérképezik a rendelkezésre álló hardvert és ellenőrzik annak működőképességét. Ezzel jelentős adaptivitás érhető el (plug and play), és megelőzhetők a futás közbeni kellemetlen meglepetések. Ebben a fázisban építi fel a rendszer a konfigurációnak megfelelően a készülékkezelőket és a fizikai készülékeket összekapcsoló rendszertáblákat, a megszakítási vektortáblát, amelynek bejegyzései a külső megszakítások kezelését a megfelelő készülékkezelő rutinra irányítják. A rendszer – ahol lehetséges – ki is próbálja a beállításokat, megszólítja a kapcsolódó eszközöket, és ellenőrzi a reakciókat.