4.1. A feladat egysége: a munka

OS04V06.RTF,2ki.4.16,ZSP

4. MŰVELETI FÁZISOK

Ebben a fejezetben megvizsgáljuk, hogyan oldható meg egy feladat a számítógépes rendszerben, és hogyan viselkedik ezalatt az operációs rendszer. Meghatározzuk a feladat egységét, a munkát, majd elemezzük a jellemző műveleti fázisokat. Megjegyezzük, hogy egy-egy konkrét munka kapcsán nem minden műveleti fázis merül fel.

4.1. A feladat egysége: a munka Az operációs rendszereket alaposan felkészítik arra, hogy szét tudják választani az egyes felhasználók feladatait. Sőt arra is, hogy az egyes felhasználóknak is lehetővé tegyék a különálló feladatok elhatárolását, hogy azok ne keveredhessenek össze. Azt a feladategységet, amelyet a felhasználó különállóan akar kezelni, munkának (angol szóval: job) nevezzük. A kötegelt operációs rendszerekben a korábban már tárgyalt munkavezérlő nyelvek alkalmasak arra, hogy kijelöljék egy munka elejét és végét, valamint a munka végrehajtási lépéseit. Minthogy a korai számítógépeken a kötegelés széleskörűen elterjedt, a számítógépes rendszerekben a munka egységének fogalmát a kötegelt rendszerekben kialakult gyakorlatnak megfelelően alakították ki. A munkát az operációs rendszernek valahogy azonosítania kell. A kötegelt rendszerekben ez a munka elejét jelző munkavezérlő utasításban megadott névvel (job-név, munkanév) történik. Az interaktív környezetben a felhasználók szétválasztását (elvileg) automatikusan biztosítja, hogy minden terminálon más felhasználó jelentkezik be. Így a felhasználó azonosítható azzal a terminállal, amelyen bejelentkezett. Ez viszont olyan megkötéssel járna, hogy egy felhasználó több terminálon nem jelentkezhet be. Emiatt az interaktív rendszerekben a felhasználók azonosítása két adattal történik: egyrészt a terminálszámmal, másrészt a bejelentkezési-, más néven számlázási (account) névvel, amelyet a számítóközpont üzemeltető személyzete ad a felhasználónak akkor, amikor gépidőt vásárol. Az interaktív környezetben a munkák kezdetét nem kell kijelölni. A felhasználó maga határozza meg, hogy mikor kezd új munkába, és azt milyen lépésekre bontja. Így a munkáknak interaktív környezetben nincsen azonosítója sem. Ez akkor is igaz, ha egyes operációs rendszerekben létezik a háttérmunka, a multitasking lehetősége, ami megengedi egy terminálnál ülő felhasználónak, hogy elindítson egy programot, és ne várja ki annak végrehajtódását. Ilyenkor az operációs rendszernek egyidejűleg kell vezérelnie a terminálnál ülő felhasználó több programját, ami ismét azonosítási problémát okoz. Ezért az ilyen interaktív környezetekben szükség van valamilyen más azonosítóra is, amelyet rendszerint sorszámozással szoktak megoldani. Az operációs rendszer a programok indításakor a következő sorszámot jelöli ki azonosítónak. Ezt nevezzük folyamatazonosítónak vagy folyamatsorszámnak. A folyamatsorszám azonban nem egy egész munkát, hanem csak egy munkalépést azonosít. Interaktív környezetben tehát a munka egységét végül is egyedül a felhasználó határozza meg. Emellett a parancsnyelvek rendszerint lehetővé teszik, hogy több munkalépést egyetlen paranccsal is tudjunk aktivizálni. Ennek módja a parancsállományok készítése, amelyekben egy munkához tartozó tipikus lépések

72 OPERÁCIÓS RENDSZEREK ---------------------------------------------------------------------parancshívásai találhatók (lényegében ez teszi lehetővé a kötegelést az interaktív környezetekben). A parancsállomány neve az összefüggő feladatrészeknek konkrét azonosító nevet ad, ami felfogható munkanévként, de ilyenkor is a felhasználó dönt arról, hogy mit tesz a parancsállományokba, és hány parancsállományra bontja a teljes feladatot. Többcélú operációs rendszerekben az egyedi alkalmazásokhoz úgynevezett alrendszereket (pl. OS/TSO) hoznak létre. Ezekben az alrendszerekben a munka fogalma elég változó lehet, és eltérhet az alapoperációs rendszerben értelmezettől. Ugyanakkor az alrendszeri szolgáltatások az alaprendszer szolgáltatásaira épülnek. Következő fejtegetéseinkben, tipikus programozási szituációból kiindulva, a munka egységeként tekintjük egy feladat megoldását a forrásprogram lefordításától az eredmények kiszámításáig.

4.2. Munkafogadási fázis Munkafogadási fázisnak nevezzük azt, amikor a munka számítógépre kerül. Ez kötegelt feldolgozás esetén más időpont a felhasználónak, más az operációs rendszernek, minthogy a kötegelt feldolgozásnál a feladat gépre vitelét az üzemeltető személyzet manuálisan ütemezi. Ezt nevezik off- line ütemezésnek, ami jókora veszteségidőt okozhat a felhasználó szempontjából. A távoli munkabeviteli (RJE) támogatás és interaktív környezet esetén ilyen veszteségidők nincsenek. A kötegelt környezetek munkafogadási fázisában a munka egy bemeneti várakozó sorba kerül. Ha az operációs rendszer több bemeneti sort tud kezelni egyszerre, akkor a felhasználónak kell megadni, hogy melyik bemenő áramba akarja helyezni a munkáját. A munkák felvételét a várakozó sor(ok)ba a beolvasó és/vagy parancsértelmező program(ok) végzi(k). A beolvasók bemenetét a bemenő áramonként feladott munkák (jobok), kimenetét pedig a bemenő várakozó sorok képezik. Funkciójuk lényegéből kiindulva a beolvasókat vezérlőáram-olvasóknak, az operációs rendszerben játszott fontos szerepük miatt pedig rendszerolvasóknak is nevezik. Programozó

Operátor

Beolvasó

JOB --------> Off-line -------> ütemezés > RJE-JOB ---------------------->

Bemenő sor

Beolvas, értelmez ---> Sorba állít

4.1. ábra. Munkafogadás A beolvasók a bemenő áramokból érkező munkákat azért helyezik el a bemenő várakozó sorokba, mert ritkán fordul elő, hogy a számítógépes rendszer azonnal képes őket kiszolgálni. Rendszerint sok munka összetorlódik, amit valamilyen módon kézben kell tartani. A már emlegetett szoftver spooling technika alkalmazásával az operációs rendszerek háttértáron eltárolják a várakozó munkák adatait, és azok legfontosabb jellemzőit az operatív tárban is nyilvántartják. Ezt az adatszerkezetet, mint nyilvántartási eszközt hívják bemenő sornak. A rendszerolvasó parancsnyelven érti meg, hogy mit akarunk kérni a számítógépes rendszertől. Kötegelésnél ez a már korábban említett munkavezérlő nyelv (angolul: JCL), amellyel megadható: * a munka azonosítója (munkanév, job-név), és esetleg a munka egyes lépéseinek azonosítója, amiről a 4.1.-ben a munka definíciója kapcsán már volt szó; * a program(ok) végrehajtását kérő neve és munkaszáma; * a hívott program neve és helye az adattárakban;

4. MŰVELETI FÁZISOK ----------------------------------------------------------------------

73

* az adatok vagy azok helye; * a szükséges perifériák adatai; * futásidő-korlát; * tárkorlát; * prioritás, határidő stb. A vezérlőnyelven írt munkát a beolvasó szintaktikusan kielemzi, és ha formai hibákat nem talál benne, akkor helyezi el a spooling bemenő sorában. A spooling állományban elfoglalt helyet feljegyzi a megfelelő sort nyilvántartó adatszerkezetekben. Ez biztosítja, hogy a későbbi munkafázisok hozzá tudjanak férni a munka eredeti adataihoz.

4.3. Munkakiválasztás A kiválasztási fázisban az operációs rendszer eldönti, hogy be tud-e ütemezni egy feladott munkát végrehajtásra. A döntés lehet elutasító is, ha a döntés pillanatában az operációs rendszer nem tudja biztosítani a szükséges erőforrásokat. Az ütemezőnek dönteni kell arról is, hogy több várakozó esetén kit részesít előnyben. Ezt tipikusan a munkák prioritása, és az előírt terhelési politika határozza meg. A kötegelt rendszerekben a kiválasztó program a főütemező. (Azért nevezik főütemezőnek, hogy megkülönböztessék az operációs rendszerben használatos más (alacsony szintű, közbenső) ütemezőktől, amelyeket később tárgyalunk.) A főütemező bemeneti adatait a bemeneti várakozó sorok képezik, kimenete pedig egy munkavezérlő blokk, amely a munkát azonosítja az operációs rendszer számára. A munkavezérlő blokkok reprezentálják a végrehajtási sort, vagy rövidebb néven munkasort, amely az éppen végrehajtás alatt álló munkákat tartja nyilván. Interaktív rendszerekben kiválasztási fázis nincs. A többcélú operációs rendszerekben a kompatibilitás végett a terminálkapcsolatot egy végtelen hosszúságú munkának tekintik. Bemenő sor

Főütemező

Munkasor

JOB11 MVBxx JOB12 -----------> Kiválaszt ----------------> MVB12 JOB13 0 (láncvég) JOB14 0 (láncvég) 4.2. ábra. Munkakiválasztás

4.4. Programfordítás A fordítási fázisban a munka végrehajtásához szükséges forrásnyelvű programok lefordítása történik. A fordítást befolyásolni lehet opcionális paraméterek megadásával. A fordítóprogramok bemenetei a munkában megadott forrásnyelvű programok, -- amelyeket spooling esetén átmenetileg háttértáron a bemeneti adatok között tárolnak, -- kimenetei pedig a korábban említett tárgymodulok. Fordítási fázis csak akkor kell, ha a munkához forrásprogramot is használunk.

74 OPERÁCIÓS RENDSZEREK ---------------------------------------------------------------------+----------------+ | Forráskönyvtár | +-------+--------+ | +---------------+ +----+----+ +------------+ | Forrásprogram |--->| Fordító-|------->| Tárgymodul | +---------------+ | program | +------------+ +---------+ 4.3. ábra. Programfordítás

4.5. Programszerkesztés A programszerkesztési fázisban az egységes belső formátumú tárgymodulokból és a tárgymodul-könyvtárakból származó szubrutinokból végrehajtható program jön létre. Az összeszerkesztést a programszerkesztő (angolul: linkage editor) végzi, amelynek a működését opcionális paraméterekkel (szerkesztő utasítások) a fordítóprogramokhoz hasonlóan tudjuk befolyásolni (tárhelyek definiálása, működésmód-paraméterek: kell-e kereszthivatkozási lista, a kód újrabeléphető stb.). A szerkesztő bemenetei a fordítási fázisban keletkezett tárgymodulok, a bennük hivatkozott tárgymodul--könyvtári szubrutinok, és a szerkesztésvezérlő utasítások. Kimenete egy vagy több betölthető programmodul, amely az operatív tárba betöltve végrehajtható. Ez a munkafázis sem minden munkához szükséges. +-------------+ | Tárgymodul- | | könyvtár | +------+------+ | +--------------+ +------v------+ | Tárgymodulok +--->| Program| +------------+ |--------------+ | szerkesztő |----->| Betölthető | +--------------+ | (Linkage | | modul | | Szerkesztő |--->| editor) | +------------+ | utasítások | +-------------+ +--------------+ 4.4. ábra. Programszerkesztés A programszerkesztési fázis fő célja az, hogy a különböző programnyelveken megírt programokat is össze lehessen kapcsolni egyetlen programmá. Ennek feltétele, hogy a forrásprogramokat a fordítóprogramok egységes tárgymodul formátumra fordítsák. Az így lefordított rutinok könyvtárakban is tarthatók. A programszerkesztőket fel kell tehát készíteni szubrutinkönyvtárak kezelésére is. A programszerkesztés típusai: * fordítóprogram-szolgáltatás (vezérlőutasítások, paraméterek), * nyelvi támogatás (CALL szubrutinhívásokkal), * betöltőprogram-támogatás, * külön szerkesztőmenet szerkesztőprogrammal (ez a legelterjedtebb).


75

A programszerkesztő bemenetei: * Szerkesztésvezérlő utasítások (direktívák), amelyek érkezhetnek a szabványos bemenetről vagy -- főleg interaktív üzemmódban -- a programhívás paramétereiből; * Átcímezhető programmodulok, amelyek az előző fordítási menetekből származnak; * Áthelyezhető (szubrutin)könyvtári modulok, rendszerint nyelvspecifikus, esetenként több, különféle tárgymodul-könyvtárból. A programszerkesztő kimenete(i): * Működőképes, de esetleg még mindig átcímezhető programmodul(ok) (szegmentált, átfedési {overlay} technikát alkalmazó programoknál mindig több modul keletkezik). A programszerkesztés eredménye háttértárba kerül: * vagy szekvenciális állományként, * vagy egy bináris programkönyvtár elemeként. A programszerkesztési művelet részletei: * A lineáris modulcím-tartományokat, amelyek mindegyikének a kezdőcíme rendszerint nulla (0) (a fix helyre címzett rendszerprogramok esetét kivéve), le kell képezni egy vagy néhány összefüggő, esetleg előírt átfedést mutató címtartományra. * A függetlenül fordított modulok más modulok belsejében szereplő belépési pontokra vagy külső címkékre történő külső címhivatkozásokat használhatnak. Ezeket a kereszthivatkozásokat a szerkesztőprogramnak fel kell oldania a modulokban szereplő belépési pontok és a külső hivatkozások összepárosításával (ilyenkor hiba is felléphet, ha a párosítást nem lehet teljes körűen és ellentmondásmentesen elvégezni: feloldatlan külső hivatkozási hiba, angolul: unresolved address, external error stb.). * Az átfedő modulok közötti közlekedést többnyire a programozónak kell megoldania. Megjegyezzük, hogy az átfedési (overlay) technika abból az időből származik, amikor a hardverben az operatív tár igen szűk kapacitás volt (a drágaság miatt kis méretű tárakat szereltek a gépekbe). Manapság a RAM áramkörök olcsósága és a virtuális tárkezelés miatt egyre kevésbé gazdaságos a programfejlesztőket arra ösztökélni, hogy átfedési technikával korlátozzák a kifejlesztendő program címtartományát. Az átfedő szegmensek közötti közlekedés elbonyolítja az algoritmust, és rendkívül sok, kifejezetten l'art pour l'art számítástechnikai elemet kever a programba. Gondolni kell arra, hogy a programozóknak ezeket a programrészeket is be kell lőni, ráadásul ez igen mély operációs rendszeri ismereteket igényelhet, ami az alkalmazói programozóktól tömeges méretekben nem várható el. Más a helyzet, ha valaki rendszerprogramot ír, vagy nincs virtuális címzési lehetőség, vagy az adott hardveren címkorlátok vannak (az ilyen hardverek szerencsére rohamosan kihalnak -- így a jó nekünk, programozóknak!). Vegyük észre továbbá, hogy a szerkesztőprogramok működési elveinek megalkotásakor a strukturált és moduláris programozás támogatását tűzték ki fő célul. A külön fordítható kis méretű programmodulokat külön-külön is be lehet lőni, majd a végén a szerkesztőprogram segítségével integrálni lehet egyetlen monolit programmá. Megjegyezzük azonban, hogy ma már a monstre programok írásának kora is lejáróban van. Jóval gyorsabban dolgozhatunk, ha kis méretű, de rafináltan paraméterezhető segédprogram-készletre alapozzuk feladatunk megoldását. A konkrét feladatot bináris programkönyvtári rutinokra alapozva próbáljuk megoldani, és csak akkor írunk új programot, ha egy probléma a meglévő könyvtári elemekkel egyáltalán nem, vagy gazdaságosan nem oldható meg. Várható, hogy ilyen esetben is csak kis méretű programokat kell írni.

76 OPERÁCIÓS RENDSZEREK ---------------------------------------------------------------------Ezek belövése elég gyors, mert elmarad a monolit programoknál felmerülő, olykor igen keserves integrációs teszt. Ez a módszer igen jól támogatja a strukturált és a moduláris programozást, beleértve a programozói csoportmunkát is. Épp ezért választották a UNIX alapfilozófiájaként. A programszerkesztő direktívái sok operációs rendszerben bonyolult programozási nyelvet képeznek. A számítástechnika rohamos társadalmiasodása folytán egyre több az olyan programozó, akitől nem lehet elvárni ilyen bonyolult (és helytelen alkalmazás esetén nagy veszélyeket rejtő) ismeretek megtanulását. A szerkesztőmenet ezért az alkalmazók felé egyre szegényesebb arcot mutat, jobbára teljesen elfedi őket a fordítóprogram, amely automatikusan megszervezi a lefordított program összeszerkesztését. Nem is beszélve az igen magas szintű nyelvi rendszerekről (mesterséges intelligencia, szakértői rendszerek stb.)! A programszerkesztő profi használata megmarad szűk körű vájt fülűek (így 2000. tájékán: hackerek, guruk -ZSP/2K.9.21.) privilégiumának. Ezek erőfeszítéseit sem kíséri arányosan nagyobb eredmény. Az utóbbi három bekezdésből megítélheti az olvasó, milyen mértékben egyszerűsödik a programozói munka a hardver és a rendszerszoftver fejlődésével. Egyszerűen nem kell annyit erőlködni, mint régen. Nem is szabad! Ne dőljünk be az idősebb korosztályok izzadságszagot kedvelő munkastílusának! Biztonságos megoldásokra kell törekedni, de a szükségesnél bonyolultabbakra nem.

4.6. Programaktiválás és erőforrás hozzárendelés Az aktiválási, hozzárendelési fázis a munka egy lépésének elvégzéséhez szükséges program futási környezetét teremti meg a JCL-utasításokban jelzett erőforrásigények (perifériák, adatállományok, tármezők) alapján. Az aktiválást az operációs rendszermag moduljaira támaszkodó speciális program, az iniciátor, végzi. Fontos kérdés, hogy az erőforrások lekötése mikor történik. Egy operációs rendszert annál rugalmatlanabbnak tekinthetünk, minél korábban köti le -- a felhasználás időpontjához képest -- a szükséges erőforrásokat. A rugalmatlanság következménye az lehet, hogy a munka hosszú időre megfog egy perifériát, jóllehet csak egyetlen, apró bemenőadathoz használja mindjárt a futás kezdetén. Helyes, ha a lefoglalásra vonatkozó döntések minél későbbre lehet halaszthatók, vagy át lehet helyezni a végrehajtási fázisba. A dinamikusabb kezelés ára a nagyobb rendszeradminisztrációs erőforrásigény (overhead). Az iniciátor program készít egy bejegyzést az operációs rendszer nyilvántartásában, és esetleg adhat neki egy belső azonosítót: folyamatazonosítót, illetve folyamatsorszámot. A vonatkozó nyilvántartást folyamatsornak vagy taszksornak, a bejegyzést pedig folyamatvezérlő blokknak (angolul: Process Control Block -- PCB), vagy taszkvezérlő blokknak (angolul: Task Control Block -- TCB), szokták hívni. (Ha egy program a futása során egy másik programot (alprogramot) aktivizál, akkor ez új azonosítót és új bejegyzést kap. Ezeket gyermekfolyamatoknak vagy szubtaszkoknak hívjuk.) Munkasor

Iniciátor

MVBxx -------->

Taszksor

TCB(nnnnn) Erőforrás ---------------> TCB(nnnnn+1) lekötés 0 (láncvég)

4.5. ábra. Programaktiválás és erőforrás hozzárendelés

4.7. Programbetöltés A betöltési fázisban az operációs rendszer helyet biztosít az operatív tárban a munkalépés programjának (kivéve, ha az eleve fix címre akar töltődni), és betölti. A betöltést vagy külön betöltőprogram, vagy az


77

operációs rendszer betöltő-modulja végzi. A betöltőprogram bementét a betölthető programmodulok képezik, kimenete pedig az operatív tárba kerül. A betöltés során a modulok címeit a betöltőprogram -- ha szükséges -átcímezi úgy, hogy a program az adott helyen végrehajtható legyen. A betölthető programmodulok programszerkesztés eredményeként keletkeznek. A betöltőprogramnak ezeket többnyire újra át kell címeznie, mert multiprogramozott környezetben és valós tárak használata esetén előre nem lehet tudni, hol lesz szabad tármező, amikor a betöltő helyet foglal a programnak (ismét kivéve a fix helyre töltődőket). Az átcímzési műveletet programáthelyezésnek nevezzük. A programáthelyezést statikusnak nevezzük, ha az csak betöltéskor történhet, később már nem. A dinamikus programáthelyezés lehetővé teszi, hogy a program szükség esetén működés közben is áthelyezhető legyen az operatív tár más tartományába. Ez biztosíthatja a legrugalmasabb tárgazdálkodást. Amíg nem voltak hardver virtuális tárak, addig a programáthelyezés a betöltőkkel szoftver úton történt. Virtuális tárak esetén más a helyzet. Igazi virtuális címzést biztosító operációs rendszerek használatával ugyanis minden programnak rendelkezésre áll a hardverrel címezhető teljes címtartomány (nullától a maximumig!, ha nem kell kerülgetni rendszerprogramoknak lefoglalt címtartományokat vagy a hardver speciális működését kiváltó címeket). Virtuális tárkezelés esetén tehát átcímzésre a betöltéskor elvileg nincs szükség, de még mindig gondokat vethet fel a lapokra tördelt programrészek működésének biztosítása a fizikai lapokon. Emiatt a virtuális tár technika egyáltalán nem biztos, hogy egyszerűbb megoldást eredményez. (Mégis, ha a virtuális tárakat korábban felfedezték volna, talán másképpen alakult volna az operációs rendszerek egész tárkezelése.)

4.8. Programvégrehajtás A végrehajtási fázis jellemzője, hogy a munkalépés programja aktív a rendszerben, a multiprogramozott környezetben versenyez az erőforrásokért. Egyáramú rendszerben a munka folyamatosan fut, a számlázandó idő akár "faliórával" is mérhető. Multiprogramozott környezetben viszont a végrehajtási idő és a felhasznált idő szükségszerűen eltérő. A végrehajtási idő olykor lényegesen hosszabb lehet, mint multiprogramozás nélkül. Ez a felhasználó szempontjából veszteségidő. Ezalatt azonban a munka nem állandóan aktív, és a számlázórendszer feladata, hogy csak azokat az időket és erőforrásokat számítsa fel a felhasználónak, amit ténylegesen felhasznált. Előfordul, hogy két olyan munka kerül össze a multiprogramozott környezetben, amelyek "egymást ütik". Tipikus példa erre az olyan eset, amikor két program ugyanazt a mágneslemezes adatállományt olvassa aszinkron módon. Ilyenkor a lemezegység olvasófeje oda-vissza rángatódzik, ami igen nagy időveszteségeket okoz. Ha a két program eltérő időintervallumban futhat, akkor érthető okoknál fogva gyorsabban befejeződhetnek, sőt a hardver igénybevétele is kedvezőbb. Az adott szituációt elég nehéz programozottan kiszűrni, ezért még mindig sok függ az alkalmazók odafigyelésétől, és az üzemeltetés manuális ütemezési tevékenységétől. Jellemző, hogy az említett szituációban az operációs rendszer a rossz hatásfokú működésből eredő terheket könyörtelenül leszámlázza a két program indítójának, holott ők esetleg nem is tehetnek róla.

4.9. Záró fázis Amikor egy program lefut, az operációs rendszernek még egy sereg teendője marad. A program befejeződése után vissza kell venni tőle a lefoglalt erőforrásokat, és különféle adminisztratív műveleteket kell végrehajtani. Ezt vezérli a terminátor program. A további tipikus feladat a háttértárra vitt nyomtatókimenet átadása a nyomtató spooling rendszernek, azaz elhelyezés a kimeneti sorban. Ha a spooling rendszer végez a munka eredményének kilistázásával, akkor az operációs rendszer véglegesíti a munkára vonatkozó számlázási adatokat, és a munkához tartozó táblázatokat törli, hogy a már érdektelen információk ne terheljék a rendszer

78 OPERÁCIÓS RENDSZEREK ---------------------------------------------------------------------táblázatait.

4.10. Rendszerfolyamatok Az operációs rendszer saját feladatai szintén munkaként merülnek fel a számítógépes rendszerben. Ezeket a speciális feladatokat rendszerfolyamatoknak, rendszertaszkoknak nevezzük (több elnevezés is használatos). A tipikus rendszerfolyamatok: * * * * * * * *

beolvasó (spooling munkafogadó), főütemező (munkakiválasztó), iniciátor (aktivizáló), terminátor (befejező), nyomtató (spooling listázó), nyelvi fordító, programszerkesztő, betöltő stb.

Ezek a munkák többé-kevésbé szintén átmennek a fejezetben tárgyalt munkafázisokon. Ezeket is fogadni kell, ki kell választani végrehajtásra, aktivizálni kell stb. A rendszerfolyamatok esetében ez privilegizált módon, előnyök biztosításával, esetenként speciális üzemmódban történik. Egyes rendszerfolyamatok a rendszertöltéskor automatikusan elindulnak (például a főütemező), míg mások (például a beolvasók, a nyomtatók) csak operátori beavatkozásra indulnak. A kapcsolódó vezérlőblokkok (PCB, TCB stb.) állandóan megmaradnak az operációs rendszer nyilvántartásaiban, és rendszerint a táblázatok elején foglalnak helyet. A megfelelő programok munkahiány esetén elalszanak (de nem halnak meg), és amint valami történik, rögtön felébrednek. Ez tipikus real-time (eseményvezérelt) jelleg.

4.11. Mintapéldák Példa gyanánt elsősorban ismét az IBM kötegelt operációs rendszerei említhetők, amelyekről a 2. fejezetben részletesen volt szó. Így például az OS munkafogadási fázisát a READER beolvasóprogram valósítja meg. A kiválasztást az OS magas szintű ütemezője, a MASTER SCHEDULER főütemező program végzi. Az OS akkor indít egy programot, ha van olyan (szabad) INITIATOR (iniciátor) program, amely indítani képes. Az iniciátor lefoglalja az igényelt erőforrásokat, és az OS SUPERVISOR-ával betölteti a behívandó programot. A SUPERVISOR megfelelő tármezőt foglal le, betölti és elindítja a programot. Az OS a nyomtatóra szánt kimenetet félreteszi mágneslemezre. Amikor a program jelzi, hogy véget ért, akkor a TERMINATOR program intézi el a záróteendőket. Felszabadítja a még foglalt erőforrásokat, és gondoskodik a kinyomtatásra szánt adatok átadásáról a WRITER nyomtatóprogramnak. Miután a nyomtatóprogram sorra kerítette és kinyomtatta a munka eredményét, a munka teljesen törlődik a rendszer táblázataiból. A terminátor program behívja maga után az iniciátort (ez csak logikailag értendő, az OS-ben az iniciátor/terminátor fizikailag egyetlen program). Ilyenkor az iniciátor szabaddá válik újabb program indítására. A multiprogramozás fokát az OS-ben tehát elsősorban az határozza meg, hogy hány INITIATOR-t indítottak el az üzemkezdet óta. Az operátorok a multizás növelésére indíthatnak újabbakat, de le is állíthatnak egyeseket, ha túl nagy a rendszerterhelés. Az interaktív rendszerekről azt írtuk a főszövegben, hogy azoknál a felhasználónak magának kell megszerveznie a munkát. Így munkafogadó program nincs, az erőforrások lefoglalásáról, és a kiválasztásról a felhasználó maga dönt. A programindítást a parancsértelmező program végzi a felhasználó direkt utasítására. Az ilyen operációs rendszerekben a programszerkesztő és betöltő program tér el legkevésbé a kötegelt rendszerekben szokásosaktól. Az utóbbi időben azonban a számítástechnika erős társadalmiasodása olyan


79

helyzetet teremtett, hogy egyre több olyan interaktív felhasználó jelentkezik, akire nem lehet rábízni a munka megszervezését az interaktív környezetben. A szoftvergyártók ezért foolproof (bolondbiztos) ún. dedikált szoftverek létrehozására törekednek, amelyek a felhasználónak természetesebb -- nem túl "komputerszagú" -kapcsolattartási nyelvet biztosítanak: menüből választható, előre megszervezett, munkameneteket támogatnak. Ezekben a programokban persze sok hasonló elem van. Ha ezeket jól kielemezzük, akkor készíthetünk általános menüvezérlő szoftvereket, amelyeket már számítástechnikailag kevésbé kvalifikált alkalmazók is felhasználhatnak interaktív feladataik racionális megszervezésére. Érdekes, hogy ilyen szoftverek előszeretettel éppen a PC-k körében terjednek. Ennek az az oka, hogy a mai nagy teljesítményű személyi számítógépeknél sem annyira magánügy már, hogy milyen a gép kihasználtsága. Itt is cél, hogy a lehető legtöbbet hozzuk ki belőlük (ebből a szemszögből nézve az OS/2 ugyan csak egy kicsi, de fontos lépés lehet előre a multitaskingjával!). Tipikus PC-s munkaszervezők: PathMinder, XTREE, FRAMEWORK, GEM Desktop, WINDOWS, valamint a sokáig várva várt Presentation Manager az OS/2-ben, és az MS--DOS 4.0-s változata, hogy csak néhányat említsünk. (Azóta jött a tisztességesen multiprogramozható W9x, WNT és W2K -- anno 1995-2000-ig, ZSP.2K.9.25. 2001: WXP.) A PC-ken továbbá még egy "kór" terjed, az ún. integrált szoftverek filozófiája. Ezek nemcsak a munkafogadást és indítást, hanem egy típusfeladat teljes lépéshalmazát igyekeznek magukba integrálni és támogatni. Az alkalmazókat a maximális mértékben mentesítik a munkaszervezés viszontagságaitól, amiért a nem számítógépes alkalmazók igen hálásnak mutatkoznak. Ilyen típusú szoftverek (a fentiekkel átlapolva): a TURBO PASCAL, a LOTUS 1-2-3, a SYMPHONY, a DBASE az ASSIST-tal, a FRAMEWORK, a GEM moduljai, a WINDOWS, de a felsorolás persze nem teljes. Már a segédprogramokat is ilyen stílusban szervezik. Ez látható a PCTOOLS-nál, ami a hajdani nagygépes IBM DITTO segédprogram filozófiájának jól elkapott interaktív, menüvezérelt, bár karaktergrafikás és billentyűzetről kezelhető megfelelője (legalább a MICROSOFT egerét ismerhetné, mint annyi más jó szoftver, pl. a NORTON programok). Megjegyezzük, hogy az integrált szoftverkörnyezet egyáltalán nem mai ötlet. A UNIX már 1969-ben ezen az elven alapult. Az IBM TSO továbbfejlesztett változatai (SPF stb.) szintén ezt a filozófiát igyekeztek megvalósítani még a 70-es években.

80 OPERÁCIÓS RENDSZEREK ----------------------------------------------------------------------

4.12. Gyakorlatok 4.12.1.

Mi a feladatok egysége a számítástechnikában?

4.12.2.

Van-e tipikusan megkülönböztetett feladategység interaktív környezetben?

4.12.3.

Mi történik a munkafeladási fázisban?

4.12.4.

Mi van a bemenő sorban?

4.12.5.

Mi az off-line ütemezés?

4.12.6.

Van-e veszteségidő az RJE-JOB-oknál?

4.12.7.

Mi a munkavezérlő blokk?

4.12.8.

Hogyan történik a munkakiválasztás?

4.12.9.

Mit csinál a főütemező?

4.12.10.

Hogyan történik a programok fordítása?

4.12.11.

Mi a tárgymodul?

4.12.12.

Milyen bemenő adatokkal dolgozik a szerkesztőprogram?

4.12.13.

Mi a betölthető modul?

4.12.14.

Hogyan teremtjük meg a program futtatási környezetét?

4.12.15.

Mi az iniciátor?

4.12.16.

Mi az előnye és hátránya a rugalmas erőforrás kezelésnek?

4.12.17.

Hogyan vesszük nyilvántartásba az elindított programokat?

4.12.18.

Mi történik a programbetöltéskor?

4.12.19.

A futtatási időben támadhat-e veszteségidő? Mikor? Miért? Kell-e érte fizetni a felhasználónak?

4.12.20.

Mi történik egy program lefutása után?

4.12.21.

Mit nevezünk rendszerfolyamatnak?

4.12.22.

Milyen kezelésmódot igényelnek a rendszerfolyamatok?

4.1. A feladat egysége: a munka

Recommend Documents