Informatika | Operációs rendszerek » Operációs rendszerek II. tananyag

Általában az operációs rendszerekről Az előadás eddig tartó része bizonyos mélységig betekintést adott a DOS és a WINDOWS 3.1, 311 operációs rendszerekről Ennyi "konkrét" információ elegendő ahhoz, hogy az operációs rendszerekről, azok tipikus feladatairól és általános szerveződési eleviről "általában", azaz egy konkrét operációs rendszer megjelölése nélkül is beszélhessünk. Az itt ismertetett általános elveknek egy-egy konkrét operációs rendszer általában cask részben tesz eleget vagy felel meg. A "maximális" elvárások ugyanis általában igen bonyolult és nehezen megvalósítható algoritmusokra vezetnének, így megvalósításuk a gyakorlatban nem mindig indokolt, amennyiban azoknál kevésbé cizellált vagy igényes megoldások is "beválhatnak". 1. Az "operációsendszerek" eredete, előzmények Az operációs rendszerek a számítástechnika "őskorában" nem

léteztek, kezdetben feladataikat emberi munkaerő (az "operátor") látta el. A későbbiekben világossá vált, hogy az "operátor" munkájának egy része "gépesíthető" vagy "automatizálható" egy számítógépes program segítségével, amely magán a gépen "fut". Az automatizált feladatok később lépésről lépésre "kibővültek", így az operációs rendszerek kialakulásának különböző nyomonkövethető fázisai vannak. 1.1 Az "őskor" Nem létezett még operációs rendszer, az operátor mint emberi erőforrás látta el az alábbi feladatokat: • • • • A programok írását nem támogatta gépesített hibakeresés. Hiba esetén a tártartalom (memória) "ömlesztve" ("dump") lett kiírva, ezeket az oprátor átadta a programozónak. A programozó "feladat-leírást" ("job") adott át az operátornak, amely a program futtatásása vonatkozó

információkat tartalmazott. Az oprátor maga csoportosította a különböző felhasználók által adott feladatokat ("batch", kötegelt adatfeldolgozás). A csoportosítás elve a hasonló munkafázisok szerinti rendszerezés volt (pl. érdemes lehetett a fordítási feladatokat egy közös kötegben elvégeztetni). Az operátor maga gazdálkodott a gép erőforrásaival, s maga kezelte a perifériákat is (nyomtató, kártyaolvasó, stb.) 1.2 Első "előrelépés": a "Monitor" program E program tekinthető az operációs rendszerek "ősének", amennyiben a gép belső erőforrásaival való gazdálkodás terhét levette az operátorról, értelmezve s végrehajtva a "job leírásokat". Az operátor feladata a perifériák kezelésére redukálódott Erre a célra megjelentek az ún. "job description languages", azaz munka leíró nyelvek, amelyekkel az alapvető fázisokat lehetett megadni a gépnek valamilyen szintaxis

szerint. (A tipikus szemantikai lépések, amelyekre utasításokat "munka kezdete", "munka vége", "FORTRAN fordító hívása", "ASSEMBLER hívása", "program betöltése", "programfutás indítása". Ezek a job vezérlő utasítások lyukkártyákra voltak lyukasztva, s e kártyák "tagolták" a köztük elhelyezett, sorba rendezett kártya kupacokat. 1.3 A perifériák kezelésének automatizálása Az operátor munkáját tovább könnyítette a perifériák saját vezérlő programjainak kialakulása. Ez CPU • • Puffertár Periféria "periféria-független" programozáshoz vezetett, a program írójának ezentúl nem kelett bajlódnia az adott partikuláris periféria kezelésének részleteivel, ezt helyette elvégezte a periféria saját vezérlése (a maga hardverével és saját proceszorával); kialakult a "pufferelés" gyakorlata: a "központi egység (Central

Processor Unit vagy CPU)" ezntúl csak "feladatokat adott ki a periféria" vezérlésének a pufferba kiadott adatok feldolgozására (pl. valamire való "ráírására"), s a periféria-vezérlővel párhuzamosan dolgozik (pl. a pufferből kiszedett adatokal, ha az előbb beolvasás történt), miközben a pufferba a pariféria vezérlő már töltheti be a következő adatokat, hiszen a processzor onnan már "kimentette" az adatokat ("soros perifériák",valamint "átlapolt feldolgozás"). 1. Ábra: A pufferelés ötlete • További fejlődés volt a pufferméret növelése ("blokkosítás"), megszakítások alklamazása és a közvetlen memória hozzáférés. A fenti ötletek akkor javítottak lényegesen a gép kihasználtságán, ha a CPU és a perifériák altal végzendő munkák időigénye gyemással "összemérhető" volt. A legtöbb programnál ez Mágneslemez Bemeneti Sor Memória Progr.

betöltés Perifériák 1. Periféria Monitor Rendszerprogramok Kimeneti Sor Felhasználói terület Eredmények kiírása 2. Periféria általábann nem állt fent, hanem valamelyik összetevő dominált, s ilymódon korlátozta a rendszer kihasználtságát. ("peripheral bound" vagy "CPU bound" feladatok) Ezen javított a • Nagy kapacitású, véletlen hozzáférésű ("random access") perifériák megjelenése, amelyek lehetővé tették a "SPOOLING = Simultaneous Peripheral Operations On-Line = Közvetlen Perifériaműveletek Szimultán Megvalósítása" ötletének megvalósítását: a lassú perifériák adatai memórai puffer helyett mágneslemezre íródnak. Ezáltal különböző munkák "felfdolgozási" és "perifériás" műveletei lapolódnak át: 2. Ábra: A SOOPLING ötlete A mágneslemez véletlen hozzáférése lehetővé teszi, hogy a monitor pillanatnyilag módosítsa az egyes munkák

("job"-ok) futási sorrendjét a pillanatnyi teljesítményviszonyokhoz igazodva. Ez elvezetett a "multiprogramozás" lehetőségéhez 1.4 Multiprogramozás A CPU teljesítménye annyira megnövekedett, hogy teljesen értelmetlenné vált várakoztatni azt a perifériás műveletek miatt. Érdemes volt szimultán több munkát ("job"-ot) futtatni A multiprogramozás főbb lépései: • • • szükséges egy nyilvántartást csinálni a futtatandó munkákról ("job pool") (Pool = közös alap, készlet); a futásra éppen kiválasztott munka folyamatosan fut mindaddig, amíg várakozni nem kényszerül (pl. valami lefoglalt erőforrásra kell várnia); az Op. R feljegyzi a várakozás okát s az egyéb szükséges infókat, majd elindít egy másik, pillanatnyilag várakozó munkát a "készletből", aemnnyiben arra nézve a várakozás oka már megszűnt; Mindez • • • • jókora tárat igényelt, anmelyben a futó

programoknak, azok adatainak és vermének el kellett férniük; valamilyen stratégia szerint kellett a várakozó programok közül az éppen futtatandót kiválasztani (CPU ütemezés); "védelmi mechanizmusok" kialakítása vált szükségessé ahhoz, hogy az egyes programok ne zavarják meg egymást, iletve az operációs rendszert magát; koordinálni kellett az erőforrások használatát, s el kellett kerülni a "holtpont (deadlock)" miatti lefagyásokat; Holtpont "Deadlock": Holtpont akkor áll elő, midőn több folyamat egy olyan eseményre várakozik, amelyet csak egy szintén várakozó folyamat tudna előidézni. A holtpont probléma kezelésére a ma általában használatos operációs rendszerek viszonylag kevés gondot fordítanak. A fenti lehtőségek megjelenésével nyílt mód azon szoftverek kifejlesztésére, amelyeket a mai értelemben operációs rendszereknek neveznek. 2. A ma használatos operációs rendszerekről

általában (1998) A mai korszerűnek mondható operációs rendszerek mind a multiprogramozás elvén működnek. A multiprogramozott rendszerek lehetnek • • • • Korszerű kötegelt rendszerek, Időosztásos rendszerek, Elosztott operációs rendszerek; Valós idejű (real time) rendszerek. 2.1 A mai rendszerek "alaptípusai" 2.11 Mai kötegelt rendszerek Korszerű kötegelt rendszerek: Ezek cs ak n evükben em lékeztetnek a r égi " kötegelt rendszerekre". Ezekben nem lényeges már az azonos munkafázisok szerinti rendezés A lényeg az, hogy a pr ogramok futásába nem lehet interaktív módon beavatkozni. Az ilyen rendszereken csak vezérlő információkkal előre ellátott munkák futnak. E rendszerek ma csak nagyon nagy számítási kapacitású gépeken futnak, amelyek nem programfejlesztésre valók, hanem megbízható, jól kifejlesztett programokkal nagy mennyiségben végzendő munkákat jelentő feladatok ellátására. A programfejlesztés

ezeken nagyon nehézkes és költséges, amunkák "átfutási ideje = turnaround time" nagyon hosszú. A kötegelt üzemmód megtalálható egyes időosztásos rendszereken is mint működési opció. 2.12 Időosztásos rendszerek ("timesharing, multitasking systems") Nagy teljesítményű, "szimultán" sok, különböző terminálok mögött "ülő" felhasználó kiszolgálására al kalmas rendszerek, interaktív k ommuniukációval mind a z O P. R és felhasználó, mindpedig a felhasználó és saját programjai között. Az OP. R minden felhasználó számára egy olyan illúziót nyújt, mintha az egyedül használna egy elfogadható kapacitású gépet, s a maga parancsaira elfogadható válaszidő (response time) alatt választ kell kapnia a géptől. Ehhez szükséges: • • • • • az egyes felhasználók számára dedikált "alkönyvtárakat" klétrehozni, amlyek tartalmához csak ők férhetnek hozzá, esetleg

publikus könyvtárakat létrehozni, amelyek tartalmához több felhasználó is hozzáfér, a felhasználói jogok és jogosítványok, jelszavak (password), preferenciák (pl. ki mekkora arányban részesülhet a felosztott időből átlagosan) bonyolult rendszerének létrehozása és kezelése; számlázási információk (témaszám vagy account) létrehozása és kezelése; gyakori kapcsolgatás a szimultán végrahajtásra váró programok között, hogy a válaszidő minden egyes felhasználó számára "elfogadhatónak" tűnjék. 2.13 Elosztott operációs rendszerek ("distributed operating systems") E r endszerek a z e gy va gy t öbb f elhasználó á ltal ki adott f eladatokon s zimultán t öbb CPU egyidejű működtetésével dolgoznak. A szervezés alapelve, hogy a számítási igények egyenletesen leyenek elosztva az egyes "központi" processzorok között. Az alapötletnek több változata terjedt el: Szorosan csatolt elosztott

operációs rendszer (tightly coupled system): ezekben az egyes processzorok a tár egy részéhez az egyes proceszoroknak közös hozáférése van (multiprocessing). Tipikus változatai: • szimmetrikus rendszer: nincs benne kitüntetett processzor; • aszimmetrikus rendszer: rendelkezik egy kitüntettet processzorral; • homogén rendszer: azonos típusú processzorokból áll; • inhomogén rendszer: különböző processzorokból áll. Tipikusan ilyenek például a képfeldolgozásra kifejlesztett célhardverek operációs rendszerei: az egész kép egyes "darabjain" szimultán dolgoznak az egyes processzorok, azonban a képen e darabok nem diszjunkt halmazok, a feldolgozás akkor lehetséges, ha a darabok "szélei" átfedik egymást. Lazán csatolt rendszer ("Loosely Coupled System"): Közösen hozzáférhető tárrész helyett az együttműködő processzorokat inkább valamilyen kommunikációs csatorna kapcsolja össze egymással. A lazán

csatolt rendszerek előnyei: • Erőforrás megosztás (resource sharing): az egyes gépekben lévő speciális eszközök (perifériák, adatállományok, stb.) hozzáférhetővé válnak a rendszer más gépeiről is • Terhelés megosztás (load sharing): a legtöbb programban vannak szimultán végrehajtható részek, amennyiben egyes részfeladatok nem egymástól kapják illetve egymásnak adják át a bemeneti illetve kimeneti adatokat (rész-erdményeket); ezek szétoszthatók az egyes processzorok között és ténylegesen "párhuzamosan" kerülnek végrehajtásra. • Megnövelt megbízhatóság (reliability): egyes processzorok meghibásodása esetén az egész rendszer nem áll le. • Felhasználók közti kommunikációt tesznek lehetővé (pl. elektronikus levelezést) 2.14 Valósidejű rendszerek (real-time systems) Tipikusan folyamatirányítási feladatok ellátására valók, ahol egy valós időben futó külső folyamat igényei "diktálnak",

az OP. R --nek nem áll módjában saját hatáskörben "beosztani" az elvégzendő feladatokat, a külső jelekre azonnal readgálnia kell. A környezeti változásokat valamilyen szenzorokhoz kötött hardware interrupt-ok (megszakítások) jelzik, s általában az egész rendszer interruptokra épül. 2.2 A mai OP R-ek strukturális sajátságai és feladatai 2.21 Rétegszerkezet (layers) Amint a DOS-BIOS példáján láttuk, abban két tipikus réteg, egy "funkcionális"-ként és egy "anatómiai"-ként azonosított, hierarchikusan egymás alá/fölé rendelt réteg működött együtt egymással az alábbi "szendvics szerkezet" szerint: Felhasználói Programok DOS BIOS Hardware 3. Ábra: A DOS-BIOS rendszer rétegződése Általában a két "középső réteget" összevonva szokás "operációs rendszernek" nevezni, mivel az a " hardver-független programozás" lehetőségét biztosítja. Ezen

összevonással a fenti 3 réteg v alamennyi r endszerben m egtalálható, v annak az onban f ínomabban r étegzett rendszerek, amelyekben a középső rész több rétegre (layer) bomlik. Pl: Felhasználói Programok Periféria meghajtók, ütemezők Virtuális tár kezelése I/O csatornák kezelése CPU ütemezés Hardware 4. Ábra: A Venus operációs rendszer rétegződése Tisztán rétegzett rendszerek esetében a hierarchia szigorú: egy réteg kizárólag az alatta lévő rétegtől kaphat "szolgáltatást", s kizárólag a közvetlenül felette lévő réteget "szolgálhatja ki". Tisztán rétegzett rendszerek esetében a hierarchia szigorú: egy réteg kizárólag az alatta lévő rétegtől kaphat "szolgáltatást", s kizárólag a közvetlenül felette lévő réteget "szolgálhatja ki". Egy rétegen belül modulok találhatók, amelyek konkrét feladat-csoportokat oldanak meg, s felhasználhatják egymás szolgáltatásait. Az egyes

modulok közti kommunikáció mechanizmusa többféle lehet, a legtisztább esetekben ez a kommunikáció is egységes. 2.22 Az OP R és a felhasználói programok közti csatlakozó felület: rendszerhívások (csapda, Trap) Jól szervezett rendszerekben a felhasználói programok a rendszerből kizárólag ezt a felületet látják, s annak mélyére "nem látnak be". A gépi nyelvű programok (pl ASSEMBLER) közvetlenül e rendszerhívásokra vannak "kihegyezve", lehetségesek azonban rendszerhívások magas szintű nyelvekből is, komfortosabb módon, a könyvtár függvényei által támogatva. A r endszerhívás m egtörténtével a vez érlés t eljesen a z O P. R kez ébe k erül, s cs ak a h ívott szolgáltatás befejeződésével kerül az vissza a felhasználói programhoz. A r endszer v édelme é rdekében b izonyos l épéseket csak az OP : R.-nek v an j ogosítványa megtenni (Rendszer Üzemmód = System Mode), m ás l épéseket a f elhasználói p

rogram i s megtehet (Felhasználói Üzemmód User Mode). A k étféle ü zemmód e gymástól v aló elkülönítését a H ARDVER tá mogatja, ma gát a p rocesszort le het il yen üzemmódokra átkapcsolni. A rendszerhívások tipikus teendői: • • • • • • • Paraméter ér tékek á tadása (vagy a v eremben, v agy a p rocesszor ál talános cél ú regisztereiben, köz vetlenül a datot, va gy n agyobb a datmannyiség esetén a t ár e gyes részeinek címét lehet átadni, amelyek alapján a hívott szolgáltatás dolgozhat a tárban. A processzor átkapcsolása User Mode-ból System Mode-ra; Az átadott paraméterek átmásolása a rendszer saját területére, ha ez szükséges; A hívott solgáltatás tényleges végrehajtása; A ka pott eredmények, es etleg hibaüzenetek visszaadása (a hí váshoz h asonló m ódok valamelyikével, esetleg kombinációjával); A processzor átkapcsolása System Mode-ról User Mode-ra; A vezérlés visszaadása a

felhasználói programnak. 2.23 Tipikus, fontosabb rendszermodulok Egy modernnek mondható operációs rendszer általában az alábbi modulokkal rendelkezik (1998): 1. 2. 3. 4. 5. 6. 7. Folyamatkezelő modul; Központi tár kezelése; Perifériák kezelése; Állományok (adatok) kezelése; Védelmi mechanizmusok; Hálózatok kezelése; Kommunikációs felület a felhasználó felé; 2.231 Folyamatok Folyamat: Szemben a " programmal", amely egy "halott", nem élő entitás, a folyamatnak egy ép pen v égrehajtás al att ál ló p rogramrész v agy p rogram. ( Egy program e gyszere tö bb, s zimultán v égrehajtás a latt á lló f olyamatként is " életre kelhet".) (Egy program egyszerre több folyamatként is létezhet, végrehajtásánk különböző fázisaiban.) A felhasználói programokból eredő folyamatokat "felhasználói folyamatoknak", míg az OP. R. egyes részeinek futását "rendszerfolyamatoknak" nevezik

Valamennyi folyamatnak erőforrásokra van szüksége (CPU, perifériák, stb.) A folyamatok "osztoznak" a rendszer erőforrásain. A folyamatok számára létrejöttükkor az OP. rendszer allokál erőforrásokat Egyes folyamatok "szülőként" létrehozhatnak "gyermek" folyamatokat, amelyek egy ideig egymással párhuzamosan léteznek, s osztoznak a rendszer erőforrásain. A "gyermek" folyamatok · vagy a szülőktől kapják erőforrásaikat, · vagy közvetlenül az OP. R-től Egy folyamat részére vagy · létrejöttekor, · vagy csak akkor kell erőforrásokat biztosítani, amikor azokra az adott folyamatnak szüksége van. A CPU idejét fel kell osztani a folyamatok között, s ellenőrizni kellene a holtpontok kialakulását. 2.232 A központi memória kezelése Egy folyamat létrejöttekor memóriát kell kapjon • • • a saját kódjának, (pl. Intel 80286: CS) vermének, (SS) adatainak. (DS) Egy folyamat futása közben

esetleg további memória allokálását igényelheti (“dinamikus memória allokáció”). Mivel egy programnak általában egyszerre nem az egész része fut, az operatív tárban elegendő bent lennie egy időben csak az egyes programok futó részeinek, a többi rész kiszorulhat onnan. E "kiszorítások" is kezelendők Példák: · (pl. a DOS C OMMANDCOM p rogramjának egy része r endszeresen " kiszorult" az operatív tárból.) · OVERLAY típusú fordítás: egy C-ben írt program széttagolásáról rendelkezhetünk a fordító számára. Emiatt okszor szükség lehet "virtuális memória" (azaz diszk-területek) igénybevételére, ilyenkor meg kell oldani a "fizikai memóriacímek" és a "virtuális címek" egy-egy értelmű egymáshoz rendelését: ha egy program éppen futó része egy olyan címre hívatkozik, amely éppen nem ül bent a tárban, a HARDWARE okoz egy megszakítást, s azt mint ellátandó feladatot az

OP.R számára adja ki Ennek hatására az OP.R helyet csinál a tárban, a háttérbe menti annak bizonyos részét, a helyre beviszi az egyelőre háttértárban nyugvó programrészt, s dolgozik vele. 2.233 A perifériák kezelése Az OP. R-nek biztosítania kell a "periféria-független programozás" lehetőségét, nem terhelve a felhasználót az egyes perifériák sajátságainak ismereteivel. Ehhez általános periféria meghajtókat” érdemes definiálni. Meg kell oldani a "pufferelést" a CPU jobb kihasználása érdekében, az egyes folyamatok szimultán fennálló periféria-átviteli igényeit valamilyen ütemezéssel ki kell elégítenie. 2.234 A háttértár, állományok kezelése Feladatként ide tartozik a könyvtárak és alkönyvtárak rendszerének kialakítása, valamint az információ tárolás konkrét módjának meghatározása (pl. a FAT táblák karbantartása a DOS és a WINDOWS jellegű rendszerekben). Ide tartozik az állományok

mentésének feladata is ("backup"). 2.235 Védelmi mechanizmusok ("Protection System") Védelem a hardver- és programhibák szerteágazó következményeivel szemben. (Maga a hardver is bírhat valamilyen védelmi mechanizmussal.) 2.236 Hálózatkezelés Az OP. R-nek lehetővé kell tennie a távoli erőforrásokhoz való kényelmes hozzáférést, lehetőleg olyan formában, mintha a távoli erőforrás a lokális rendszer szerves része lenne. Biztosítani kell a felhasználók egymásal való kommunikációjának lehetőségét. 2.237 Felhasználói felület Ma már a nyelvi szintaxis helyett a grafikus ablakokra, menükre és egérre alapozott felhasználói interfészre van szükség. A programok futása folyamán azoknak a felhasználóval való kommunikációját is támogatnia kell az OP. R-nek Szükség van általában egy parancs-értelmezőre. Szükséges továbbá a felhasználói programok közti kommunikáció, lehetőleg egységesített

formában. 2.24 Az OP R-ek rendszerhívásokkal elérhető tipikus szolgáltatásai Folyamatvezérlés: • • • • • programok betöltése és futtatása, e közben folyamatok létrehozása és megszüntetése, tulajdonságaik beállítása. a folyamatok által igényelt tár "kiigénylése" illetve felszabadítása. folyamatok közötti i nformációcsere bi ztosítása, azok egymáshoz vagy külső órához való szinkronizálása. hibakeresést megkönnyítő nyomkövetés végzése. Állománykezelés: • • • állományok létrehozása és törlése., attribútumok beállításaé a könyvtárszerkezet létrehozása, módosítása. állományok n yitása és z árása, s zekvenciális v agy v életlen í rás b iztosítása az állományokba. Periféria kezelés: • • igénylés, lefoglalás, felszabadítás magának az átvitelnek a biztosítása a program és a perifériák között. Rendszerinformációk kezelése: • • folyamatok,

állományok, perifériák, lekérdezése, módosítása, nyilvántartása statisztikák készítése, számlázás. felhasználók, rendszeridők állapotának Kommunikáció • • • kommunikációs csatornák létrehozása és megszüntetése. üzenetek, állapotinformációk küldése és fogadása a távoli erőforrásokon végzendő műveletek biztosítása. A "Folyamatok--Process" kezelésének alapjai A multiprogreamozott rendszerek "alapfogalma" a folyamat (az éppen végrehajtás alatt álló vagy életre keltett program rész, program). A folyamat szónak különbözõ "szinonímáit" szokás használni a különbözõ típusú rendszerekben: • • • Kötegelt Rendszerek: Egyszerre több "munka" ("job") futhat bennük; Valósidejû Rendszerek: Egyszerre több "feladaton" ("task") dolgozhatnak; Idõosztásos Rendszerek (Time Sharing): itt nevezik eredetileg "process"-nek vagy

folyamatnak az életre kelett programrészeket. Sok multiprogramozott rendszer egyetlen CPU-val bír, ilyenkor ez kitüntetett erõforrás, amelyet egyszerre csak egy folyamat használ, így e rendszerekben a folyamatok szimultán együtt futása csak látszólagos. (A többi folyamat ilyenkor "fel van függesztve") Az ilyen rendszerekben a folyamat dinamikáját a folyamat állapot átmeneti gráfja jellemzi: Folyamat létrehozás "ProcessCreation" FutásraKész "Ready" Avárt esemény Várakozik bekövetkezik "Blocked" Futáselindul Futásmegszakad Fut "Running" Eseményrevár Folyamat megszûnik "ProcessTermination" Egy folyamat "Állapot Átmenetei Gráfja" • • • Több processzoros (CPU-s) rendszerben processzoronként csak egyetlen folyamat lehet a "Fut" állapotban. A "Blocked" állapotba kerülés oka lehet külsõ vagy belsõ eseményre való várakozás (pl. egy

perifériára átvitelt indít a folyamat, s amíg az be nem fejezõdik, nem tud továbblépni); A "Futásra kész" állapotba akkor kerül vissza a folyamat, ha annak futásához az összes feltétel fennáll, azonban az OP.R attól pillanatnyilag elvette a CPU-t, hogy az egy másik folyamaton dolgozhassék egy darabig. Az "állapot átmeneti gráf" fõbb részeivel kapcsolatos teendõk az OP.R számára: • "Process Creation": Egy folyamatot általáben egy már futó folyamat "szülõ" hozhat létre, emiatt a folyamatok között fennáll egy hierarchikus leszármazási reláció, amelyet az OP.R-nek követnie kell: * erõforrások kijelölése a gyermek folyamat számára (vagy a szülõ folyamattól, vagy az OP.R-tõ); * paraméterek átadása a gyermek számára a szülõtõl, amely paraméterek a gyermek futását szabályozzák, befolyásolják; * a szülõ folyamat vagy párhuzamosan futhat a gyermek folyamattal, vagy be kell várnia

annak futását, attól függõen, hogy a "gyermek folyamat" eredményeire mikor és miképp van szüksége a szülõnek. • "Process Termination": ebbe az állapotba több okból juthat egy folyamat: * * * * • A folyamat "önszántából" befejezõdik, azaz annak utolsó utasítása is végre lett hajtva; Egy folyamatot leállíthat az OP.R, vagy az azt létrehozó szülõ folyamat, esetleg valami másik folyamat; Ennek több oka lehet: a folyamat hibás mûködése, vagy fölöslegessé válása, vagy mert több erõforrást használ, mint amennyit engedélyeztek számára, stb.; A "befejezett folyamat" "elhalálozik": erõforrás igényei megszûnnek, a lekötött erõforrások visszaadódnak a folyamatot létrehozó folyamat (szülõ vagy OP.R) számára; A befejezett folyamat megszínésekor információt ad az út létrehozó szülõnek a megszûnés tényérõl, okáról. A "FutVárakozik" átmenet esetében

az OP.R teendõi: * A "Várakozik" állapitba kerülésnek többféle oka lehet: - a folyamat olyan tevékenységet kezdeményezett, amelynek a végét meg kell várnia; - meg kell várnia egy másik folyamattól érkezõ jelzést; - csak olyan erõforrás felhasználásával tudna "folytatódni", amelyet éppen egy másii folyamat használ. * Az OP.R-nek egy nyilvántartást kell vezetnie a folyamatokról, s abba be kell jegyeznia az adott folyamat pillnatnyi állapotát: - hogy az éppen várakozik; - mi a várakozás oka; - milyen esemény bekövetkeztée vár. (Általában ugyanazon eseményre több folyamat is várakozhat egyszerre, pl. egy periféria felszabadulására. Egy felszabaduló erõforrásnak így egyszerre több folyamat is "nekiesne", ezért célszerû a "blocked" állapotból nem a "Fut" állapotba jutni vissza, hanem a "Futásra kész" állapotba, így a futásra kész események listája alapján az OP.R

logikusan tudja ütemezni a CPU-t, azaz gazdákodik annak idejével) • • • A "VárakozikFutásra kész" átmenet: ekkor az OP.R a maga nyilvántartásában csak a folyamat állapotát kódoló bejegyzést válktaoztatja meg, amennyiben bekövetkezett az az esemény, amelyre a folyamat várt. A "Futásra készFut" átmenet teendõi: Az éppen futó folyamatot az OP.R leblokkolja, majd kiválaszt egyet a "Futásra Kész" állapotban lévõ folyamatok listájáról, s annak futása folytatódik. (A választást külöönbözõ tényezõk befolyásolják: a folyamatok prioritásai, a várakozásban eltöltött idõ, stb.) A "FutFutásra kész" mátmenet okai és teendõi: * Maga az OP.R idézheti elõ ezt az átmenetet, mert a folyamat már elég idõt kapott a futásra, s más folyamatokat is "hagynia kell érvényesülni", vagy * Maga a folyamat "önként" is "átmenetileg" lemondhat a futás jogáról,

attól függöen, hogy mi a folyamato "ffeladata". (Pl egy rendszer-statisztikát gyûjtõ folyamat nem szüntetheti meg magát, miután a statisztikai adatokat felfrissítette, de miutáz egy darabig ezután "nincs dolga", átmenetileg visszatetetheti magát a futásra kész állapotba.) A fenti szervezési elvbõl látható, hogy a szimultán élõ folyamatok állapotlistájának bõvülése egyre több munkával terheli az OP.R-t, elsõsorban az erõforrásokon való osztozás problémája miatt. Egy létezõ folyamatnak --akár az elektronikus, akár a diszken létrehozott virtuális tárban-- megszûntéig pl. véges mennyiségû memóriát kell biztosítani annak adatai, kódja, verme számára. Ha az erõforrások már kimerültek, azaz pl nem lehet már elegendõ memóriát kiosztani egy újabb, létrejövõ folyamat számára, az OP.R eredendõen két dolgot tehetne: * vagy megtagadja az új folyamat létrehozását, * vagy meg kellene

"öline" ("Process Termination") egy még élõ folyamatot, hogy a felszbaduló memóriába be tudja illeszteni az új folyamatot. A felhasználó szemszögébõl nézve mindkét megoldás elég "balkáni" jellegûnek tûnne. Ennek elkerülése érdekében az állapot átmeneti gráfot érdemes kiterjeszteni egy "tetszhalott" vagy "felfüggesztett" "Suspended" állapottall, illetve az ilyen állapotban való várakozást jelentõ "Felfüggesztve várakozik" állapottal, valamint a lehetséges újabb átmenetekkel, az alábbi Folyamat létrehozás FutásraKész "Ready" "ProcessCreation" bekövetkezik "Blocked" Eseményrevár Futáselindul "Activate" Aktiválódik "Suspended" Várakozik Futásmegszakad Felfüggesztõdik "Suspend" Felfüggesztett Avárt esemény Fut "Running" Eseménybekövetkezik "Suspend" Folyamat

megszûnik "ProcessTermination" Felfüggesztve várakozik módon: A"Felfüggesztett" folyamatot az OP.R nem öli meg, de kivonja azt az erõforrásokon éppen osztozó folyamatok listájáról (ez egyfajta "hibernálás"). A felfüggesztés praktikus okai lehetnek: * túlterheltség, pl. nincs már több felosztható memória; * vészhelyzet alakul ki, pl. tápfeszültség kimaradás, vagy a felfüggesztett program mûködése gyanús; * maga a felhasználó is dönthet úgy, hogy egyik folyamatát felfüggeszti. A felfüggesztett folyamatok bármikor újra folytathatók, azaz visszakerülhetnek a "Futásra kész" állapotú folyamatok közé, ahonnan az OP.R már erõforrásokat adhat nekik "Tisztességes" rendszreben csak ez az egy átmenet lehet a felfüggesztésbõl való visszatérésbe az alábbi, kibõvíttet gráf szerint, amelynek két alsó álapotát "passzív állapotoknak" is nevezik. Szofisztikáltabb

"Állapot Átmeneti Gráf", amely a felfüggesztés lehetõségét is tartalmazza A "Felfüggesztett" állapotba való kerülésnek azonban többféle oka lehet, s ezekhez érdemes többféle "szabványos felfüggesztési átmenetet" is biztosítani: vagy közvetlenül a "Futásra kész", vagypedig --amennyiben a folyamat valamilyen erõforrás tartós hozzáférhetetlensége miatt nagyon sokáig, vagy valamilyen esemény be nem következése miatt akár ∞ sokáig "Várakozik", akkor ebbõl az állapotból egy ilyen célokból létrehozott "Felfüggesztve várakozik" állapoton keresztül a "Várakozik" állapotból. Megjegyzések: * Elviléeg lehetne a "Fut" állapotból is lehetõvé tenni felfüggesztést, ez azonban gyakorlatilag nem elõnyös, mert elbonyolítaná az OP.R könyvelését; * A "Felfüggesztett" állapotú folyamattól nem kell az összes erõforrást megvonnia az

OP.R-nek, csak a kritikusakat (pl a nyomtatóhoz való hozzáférés maradhat, de az elektronikus memóriához való hozzáférés megvonandó); ugyan a felfüggesztett folyamat továbbra sem fog nyomtatni, de az OP.R könyvelési teendõi ezzel egyszerûsödnek. * A "Felfüggesztve várakozik" állapot annyiban különbözik a "Várakozik" állapottól, hogy bizonyos erõforrásokat nem köt le, míg az utóbbi leköti azokat, miközben várakozása miatt nem használja a lekötött erõforrásokat. * A "Felfüggesztve várakozik" állapotból közvetlenül aktiválni (azaz rögtön a "Fut" állapotba vinni a folyamatot) sok esetben értelmetlen lenne: fölösleges aktiválni egy olyan folyamatot, amelynek nagy esélye van arra, hogy aktiválás után hamarosan megint felfüggeszttetik. Folyamatok közti átkapcsolás: "Környezetváltás" Ez nyilván igényli: a folyamat pillanatnyi állapotának elmentését, a gép pillanatnyi

állapotának elmentését • • annak érdekében, hogy a folyamat visszakapcsoláskor folytatható legyen ott, ahol környezetváltáskor tartott. A folyamat állapotjellemzõi: * A hozzá tartozó programkód (annak helye a memóriában); * A programszámláló tatalmának elmentése (hogy éppen hol tartott a program végrehajtásánál átkapcsoláskor); * a változók aktuális értéke (adatok), beleértve a folyamat saját vermét és annak pillanatnyi tartalmát; A "gép" pillanatnyi állapotának jellemzõi: (amilyenben az volt a megszakított folyamat végrehajtásakor). * * * Itt megjegyzendõ, hogy a "Folyamat" és "Gép" határvonal nem adható meg egzakt módon általánosan, az függ a tekintett konkrét OP.R rétegszerkezetétõl is; E "határvonal" lehet hardver és szoftver közti felület is; Sok esetben az OP.R úgy jelentkezik a folyamat számára, mint valami "virtuális gép", amely alapszolgáltatásokat

kínál; Emiatt a "gépi állapot jellemzõinek mentéséhez tartozik: • a CPU összes regiszter tartalmának elmentése, • az OP.R pillanatnyi állapotának (rendszer táblázatok, memória-kezelési információk, periféria hozzárendelések, stb.) elmentése Egyszerû paradigma: MS DOS esete, Intel 80286 processzor mellett, ASSEMBLER-ben: A programozónak magának kellett biztosítania a korrekt : megszakítás hívást szoftverbõl • INT hívott interrupt száma; Mit csinál ez az utasítás; * PUSHF; elmenti a processzor állapotát leíró 16 bites regiszter tartalmát, amelyet "flag"-eknek neveznek, egy erre dedikált verembe; * IF ← 0, azaz az "Interrupt Flag" bit-et 0-ra állítja: ezzel letilt minden letiltható HW megszakítást, azaz félreteszi azokat, amíg a most hívott megszakításból vissza nem kerül, (ha a bit értéke egy, nem tiltja le azokat, hanem hagyja magát megszakítani általuk); * TF← 0, azaz a "Trap

Flag" értéke 0-ra áll, jelezve, hogy egy megszakítás végrehajtásába kezdett --ez programból nem átírható bit-, viszatérés után automatikusan 1-re áll majd vissza, emiatt az utasításokat lépésrõl lépésre kezdi el végrehajtani újra a processzor, ez az alapállapota; * PUSH CS; majd * PUSH IP elmenti a "Code Segment Register" és az "Instruction Pointer" tartalmát, így a híváskor aktuális CS:IP segment-offset címet, ahol épp a hívó program tartott; * IP← 0000:[4hívott interrupt szám]; CS← 0000:[4*hívott interrupt szám+2], azaz "Code Segment" regiszterbe és az "Instruction Pointer"-be az inerrupt vektorok táblájából kivett SEGMENT:OFFSET címek kerülnek, ahonnan megint lépésrõl lépésre végre kell hajtani a hívott megszakítás utasításait. Visszatérést megszakításból: • IRET; az e célra dedikált verembõl -a lerakás sorrendjével ellentétesen- visszateszi azt a címet, ahol a

programot folytatni kell, vaalmint a processzor állapotát leíró "Status Flag"-eket (a hívott megszakítás utolsó utasítása ez kell legyen): * POP IP; * POP CS; * POPF; Midõn a hívott interrupt "dolgozni kezd", az összes többi regiszter tatalma is megváltozhat. Ezeket azonban a DOS önmagában nem veszi figyelembe, így interrupt hívása elõtt azokat a hívó programban "kézzel" kell meteni: pl. PUSH AX, etc módon, illetve az interrupt-ból való visszatérés után a program saját vermébõl visszaszedni POS AX módon. Ennek oka, hogy egy interrupt hívás akkor hatékony, ha a mentendõ aadtmennyiség "minimális". A gép állapotát leíró fenti adatok mentése minden esetben szükséges, ezért azokat a DOS interrupt hívása elintézi. Az egyéb regiszrek tartalmára azonban nem mindig van szükség: azok szükségessége attól függ, hogy az interrupt-ot hívó program mit akar csinálni. A "kézzel való

gondoskodás" módszerével így általában fölösleges mûveletek takaríthatók meg. Megjegyzés: A végrehajtó gép állapotainak összességét szokás kontextusnak nevezni, az állapotváltást pedig kotextus kapcsolásnak. (Innen a környezetváltás Context Swithing fordítás). Folyamatleírók: a folyamatok kezeléséhez szükséges információk adatszerkezete (Process Control Block) A folyamatleíró adatszerkezet tartalma: • • • • • • • • • a folyamat állapota (az állapot átmeneti gráf lehetséges csomópontjainak valamelyike); a folyamat azonosítója; a folyamat szülõjének és gyermekeinek azonosítója; a folyamathoz tartozó összes tárterület leírása, mutatók, iletve a virtuális tár kezeléséhez tartozó összes adat (címtranszformációs táblák, lemez blokkok, stb. leírása); a folyamat által a processzoron kívül használt egyéb erõforrások leírása, beleértve a nyitott fájlokat (állományokat) is, amelyeket

a folyamat használ; a processzor regiszterek tartalma; várakozó állapotú folyanmatoknál a várt esemény leírása; a CPU ütemezéséhez kellõ információk: prioritás, eltelt várakozási idõ); számlázási információk és statisztikák adatainak frissen tartása a Process Control Block-ban; Ez az általános lista messze meghaladja azt a tartalmat, amit az egyszerû, itt paradigmának tekintett DOS hajlandó kezelni. Speciális folyamatok: Szálak (Threads) A szál a folyamatokhoz hasonló aktív entitás, de kevesebb önálló adattal rendelkezik, mint egy fentebb tárgyalt általános folyamat. Ezzel a folyamatleírók kezelésével járó munka, s így a környezetváltás kapcsán végzendõ munka is csökkenthetõ az OP.R számára Többféle változata van, az alap paradigma a pehelysúlyú folyamat vagy Lightweight Process: Saját verme és saját regiszterei vannak csak. A kód és adat terület, valamint az egyéb erõforrások tekintetében több más szállal

osztozik. Egy pehelysúlyû folyamat önmagában nyilvánvalóan nem létezhet. Természetes futási környezete egy tadícionális folyamat (ezt szokás Heavyweight Process-nek vagy task-nak is nevezni), amely a közös erõforrások birtokosa. Elõnyei: • nagyon gyors "környezetváltás" a szálak között; • a közös tárterület miatt gyorsított információ csere a szálak között: könnyedén hívatkozhatnak közös tárterületre. A szálak kezelése: különbözõ megoldások vannak rá. • Az újabb OP.R-ek (pl Mach, OS/2) külön rendszerszolgáltatásokkal segítik a szálak használatát; Régebbi megoldás a felhasználói szintû könyvtárak kínálta lehetõség (pl. UNIX-ban, ANSI C-ben). • Megszakítások--Interruptok Az egyszerû DOS paradigmán belül egy folyamat hívása (környezetváltás) lényegében megfelelt egy megszakításnak. A fejlettebb operációs rendszerek a folyamatokról a fentiek szerint sokkal több adatot tartanak

nyilván, azokban az interrupt már nem tekinthetõ a folyamat paradigmájának. Az interrupt-ok általában olyan események, jelzések, amelyek befolyásolják az egyes folyamatok mûködését. Az interrupt-ok kezelése ezért némileg eltér az OP.R által generált szokásos környezetváltástól. Tipikus megszakítás osztályok: • Perifériák megszakításai (vagy a periféri állapotáról, vagy a periférián folyamatban lévõ adatátvitel állapotáról adnak jelzést); • Belsõ hardver megszakítások, pl. az óra által generált megszakítások (pl DOS timer megszakítása); • Utasítás-végrehajtási hibák által generált megszakítások (pl. zéróval való osztás, vagy a virtuális tár kezelésével kapcsolatos védelmi mechanizmusok válthatják ki); • Jelentõs hardver hibák válthatják ki (pl. tápfesz kimaradásÖ; • Szoftverbõl keletkezõ megszakítások (pl. trap, rendszerhívások), ami a folymatok normális szervezésével jár); • • •

A megszakítások kiszolgálásához általában a számítógépek valamilyen hardvert használnak, amelyek valamilyen prioritást rendelnek a megszakításokhoz. Egy alacsonyabb priorítású megszakítás végrehajtása megszakítható egy magasabb priorítású megszakítással; Vannak olyan megszakítások, amlyek átmenetileg "letilthatók" (láttunk rá példát az interrupt vektor táblázat átírásánál a DOS esetében); A megszakítások kiszolgálásának tipikus változatai: • "Standard" változat: elkerüli a komplett környezetváltást, csak azokat a regiszter tartalmakat kell visszaállítani, amelyeket a kiszolgáló rutin használ; az éppen futó folyamat felfüggesztõdik; elindul az OP.R megfelelõ kiszolgáló rutinja; ennek végeztével a felfüggesztett folyamat aktiválódik. • Komplett környezetváltással járó megszakítás: amennyiben a megszakítással jelzett eseményre valamelyik processz várakozott, az OP.R az egyik,

éppen ezen interrupt-ra várakozó folyamatot várakozóból rögtön futóvá tehet. A megszakítások kiszolgálásának lépései: • • • A futó folyamat végrehajtása megszakad, a vezérlés átmegy az OP.R kezébe; A megszakított folyamat állapotának elmentése; (ezt a hardver is segíti; általában nem szükséges a teljes állapot elmentése, mivel a megszakításokat kiszolgáló rutinok primitív, rövid programrészek, amelyek általában csak vermet és regisztereket használnak, elég lehet tehát ezek elmentése, lásd a DOS-ból adott példát); az OP.R átadja a vezérlést a hívott rutinnak; a hívot rutin futása után - ha a mgeszakított folyamat aktiválódik megint, akkor annak az állapotát vissza kell menteni, s átadni neki a vezésrlést (azaz a FLAG-eket, CS:IP, SS:Sp értékeket visszaállítani a DOS-ra adott példában az IRET utasítás); - vagy egy másik, a megszakítás által jelzett eseményre várakozó processz indulahet el. A

megszakítást kiszolgáló rutinnak "hivatalból" ismernie kell az OP.R által használt adatszerkezeteket, azokhoz hozzáférhet, iletve azokba bejegyzéseket tehet, így marad meg a folyamatok kezelésének rendje. • Folyamatokból álló bonyolultabb rendszerek szervezése Ez a szervezési elv a "kötött irodai hierachia" használata helyett inkább bizonyos célfeladatok végrehajtására szerzõdtetett ügynökök alkalmazására hasonlít. Ezek vagy egymástól függetlenül, vagy egymással együttmûködve, "párhuzamosan" dolgoznak abban az értelemben, hogy egyszerre élnek (esetleg aktív, várakozó, vagy hibernált állapotban). A nagyobb rendszer által képviselt feladat-csoport végrehajtása közben ügynöki megbízások születnek, illetve szûnnek meg, ami folyamatok (esetleg szálak) születésének ill. halálának fele meg. A folyamatok közti esetleges függõségek okai: • egymástól egyébként logikailag független

process-ek közös erõforrásokon osztoznak (pl. multiprogramozott rendszereken egymásról mit sem tudó felhasználók programjai szimultán futnak); • ha az egyes folyamatok egymással eleve valamilyen logikai kapcsolatban állnak: pl. közös változókat használnak, vagy kommunikálnak egymással, az egyik folyamat mûködésének eredményét egy másik folyamat használja fel a késõbbiekben, tipikus folyamatszabályozási szituáció); Az együttmûködõ folyamatokon alapuló rendszerszervezés elõnyei, indokai: • Az erõforrások kihasználtságának növelése, hiszen azokat "átlapoltan" egyeszerre többen is használhatják; • Több CPU-ból álló rendszer esetén a számítások érdemben felgyorsulnak, hiszen az egyszerre élõ folyamatok ténylegesen "szimultán" hajtódnak végre valós idõben; • Ugyanaz a felhasználó ugyanazon a gépen maga is egyszerre több folyamatot futtathat (ez pl. a WINDOWS óriási elõnye a DOS-szal

szemben, hozzávéve ehhez a vágólapon keresztüli kommunikáció lehetõségét is); • Általában ez a moduláris szervezés sok esetben maga is a legkézenfekvõbb megoldás, amely így közvetlenül realizálódhat a számítástechnikai eszközökön. Folyamatok szinkronizálása: egy adott folyamat végrehajtásának olyan idõbeli korlátozása, amelyet egy másik folyamat futása, vagy estleg vaalmi külsõ esemény bekövetkezése határoz meg. Tipikus alapestei vannak az oPR-ek gyakorlatában: • • • Precedencia: az egyik folyamat végrehajtása csak akkor kezdõdhet el, ha meghatározott másik folyamatok végrehajtása már befejezõdött (pl. mert szüksége van a megelõzõ folyamat eredményeire); Egyidejûség: két folyamatot egyidejûleg kell elkezdeni, a folyamatok bevárják egymást, mielõtt elkezdõdne mûködésük ("randevú"Ö; Kölcsönös kizásrás (Mutual Exclusion): az utasítások futási sorendjére nincs korlátozás, csupán

annyit kell biztosítani, hogy egyidejûleg nem futhat mindkét folyamat (vagy több folyamat), hanem csak az egyik (egyikük). A szinkronizáció problémájához kapcsolódó fogalmak: • Holtpont (deadlock): a rendszer egészére vonatkozó fogalom: a folyamatok egy csoportja olyan feltétel, esemény bekövetkezésére vár, amelyet csak a csoport egy másik várakozó folyamata tudna elõidézni. (Ebbe nem étendõ bele külsõ eseményre való várakozás, ennek bekövetkeztét az OP.R ugyanis nem képes befolyásolni, ennek esetleges soha be nem követezése nem az OP.R hibája); • Éhezés (Starvation) magy meghatározatlan ideig való elhalasztás (Indefinit Postponement): ez egyes folyamatokra vonatkozik: a tekintett folyamat hosszú ideig nem jut hozzá a futásához kellõ erõforrásokhoz, mert mindig megelõzi õt egy másik folyamat.; (tisztességtelen, unfair ütemezés, ami rögzített prioritások esetében fordulhat elõ). A szinkronizációs problémák

közül az OP.R-nek a kölcsönös kizárás esetével kell a leggyakrabban megküzdenie, ami amiatt fordul elõ, mert véges erõforrásokkal kell gazdálkodnia. Példa a kölcsönös kizárásra: Legyen egy közösen használt erõforrás egy globális változóban tárolt, több folyamat által közösen használt memórai cím, amelynek tartalmát közös számlálóként használják a folyamatok: pl. aktiválódás esetén mindegyik folyamat 1-gyel növeli a számláló tartalmát. A már használt DOS-os paradigmában gépi kódban a számláló tartalmának növelése a következõ 3 lépésben valósulhat meg: 1. MOV AX, Számláló (a Számláló tartalma beíratik az AX általános regiszterbe); 2. INC AX, az általános regiszter tartalma 1-gyel nõ; 3. MOV Számláló, AX, (a regiszter tartalma beíratik a Számláló által jelzett címre) A számláló növelési mûvelet hibásan fog mûködni, hogyha egy folyamat elkezdi csinálni azt, miután egy másii folyamat abba

már belekezdett, de még nem fejezte be azt. Ez a mûveletek egy kritikus szakasza (critical region), s ebben biztosítani kell, hogy egyszerre csak egy folyamat férhessen hozzá ehhez az erõforráshoz. A kritikus szakaszok megvalósításának az alábbi praktikus kritériumai vannak: • Biztosítani kell a kölcsönös idõbeli kizárást; • A kritikus szakasznak haladnia kell: ha a tekintett folyamat épp nincs a kritikus szakaszban, de több olyan folyamat is van, amelyik be akar lépni a kritikus szakaszba, akkor ezek közül az OP.R algoritmusának véges idõ alatt ki kell választania egyetlen folyamatot, s azt be kell engednie a kritikus szakaszba; • Biztosítani kell a folyamatok korlátozott idejû várakozását: amennyiben egy folyamat eljutott a kritikus szakaszhoz, s az abba való belpésre vár, akkor ezt a folyamatot csak véges sok alkalommal elõzhetik meg más folyamatok. (Ez az utóbbi kritérium nem mindig szükséges, vannak OP.R-ek, amelyek ezt nem

teljesítik) Módszerek a krtikus szakaszok megvalósításához kellõ kritériumok teljesítésére: A rendszernek módot kell adni a kritikus szakasz elejének (belépés, entry) illetve végének (kilépés, exit) megadására. Ezeket tekinthetjük szimbolikus utasításoknak Tisztán programozott megoldások: közösen használt változókon alapulnak, több processzoron párhuzamosan futó folyamatokat tételeznek fel, bonyolultak, s mindhárom kritérium teljesíthetõ velük; Hardver támogatás: olyan speciális, megszakíthatatlan gépi utasítások, amelyek egy utasítás alatt összevonva több elemi utasítást is elvégeznek; Például a ZÁR nevû memóriaváltozó logikai, s kétféle állapota lehet: zárt, ill. nyitott; A TestAndSet(ZÁR) utasítás megvizsgálja a rekesz tartalmát, s a viozsgálat eredményétõl függtelenül beállítja azt zárt álapotúra; Ezzel az alábbi algoritmus írható: entry: amíg TestAndSet(ZÁR) végezz {üres utasítás} (amíg

a rekesz zárt, tatsd zárva és ne ne lépj be a kritikus szakaszba) (ha a rekesz nyitott, zárd le és lépj a kritikus szakaszba) .kritikus szakasz utasításai exit: ZÁR:=nyitott (ha végeztél, engedd meg másnak a belépést) Speciális addattípus, szemafor használata: A szemafor olyan speciális adattípus, amely vagy 0 értéket, vagy pozitív egész számokat tartalmazhat; két, megszakíthatatlan mûvelet van értelmezve rajtuk: a vizsgálat, és a növelés. • vizsgálat: amíg s<=0 végezz {üres utasítás}; egyébként s:=s-1; • növelés: s:=s+1; Ezzel a ciklus: entry: vizsgálat . a kritikus szakasz utasításai exit: növelés. Az 1 kezdõértékû szemafor állás azt jelenti, hogy a kritikus szakaszba be lehet lépni, hiszen az a belépéssel lenullázódik (más processzek számára lezárul), be lehet lépni a kritikus szakaszba, amjd annak elvégzése után a szemfor értékét visszanövelhetjük 1-re, ami más processzek számára jelzi, hogy be

lehet lépni a kritikus szakaszba. Magas szintû programozási nyelvek által lehetõvé tett programszerkezetek, amelyek támogatják a kritikus szakaszok megbízható, automatikus létrehozását: • egy közös, valamilyen T típusú (v) változóhoz hozzárendelhetõ olyan összetett utasításokból álló kritikus szakasz (s) , amelynek végrehajtása közben v-hez más folyamat nem férhet hozzá: var v: shared T; (v egy T típusú közösen használt változó) region v do s; (amlyhez az s utasítással jelzett régió tartozik. Általában v-hez hozzá lehet még rendelni egy b logikai feltételt is: region v when b do s; Ha egy folyamat beléphet a kritikus szakaszba, kiértékelõdik a b feltétel, s s csak akkor hajtódik végre, ha b igaz. Ha b hamis, a folyamat fleszbadítja a kritikus szakaszt, s a feltétel teljesüléséig vár. "Monitor" típusú programszerkezet: Ebbe programrészeket és eljárásokat zárhat a programozó. Maga a programszerkezet

biztosítja, hogy az abba zárt folyamat-részletek közül egyszerre csak az egyik lehet aktív. Ha már van benne egy aktív részlet, atöbbinek automatikusan várakoznia kell A fenti "fogalmi keretekre alapozott megoldások" hátránya, hogy azok aktív várakozással állandóan használják a processzort, a belépési feltétel tesztelésével. Multiprogramozott rendszerek esetén hatékonyabb lenne, ha el lehetne venni a processzort ezektõl a "várakozó", üres utasítást végzõ folyamatoktól. Az OPRben való implementálásokban a szemafor változõkkal való mûveletek kibõvíthetõk a nem negatív egész értéken túl a processzek listájával. A vizsgálat utasítás kibõvíthetõ az {üres utasítás} helyett az adott processz suspended listára való felfûzésével, a növelés mûvelete pedig kibõvíthetõ azzal, hogy az OP.R vegye le a tekintett processzt a felfüggesztett listáról, s hozza azt futó álapotba. Folyamatok közti

információcsere (interprocess communication) Megvalósításának két, egymástól szemléletben lényegesen eltérõ alaptpusa van: • • közösen használt tárterület segítségével megvalósított, vagy kommunikációs csatorna kiépítésével megoldott kommunikáció. Az elsõ változat a már taglalt "kölcsönös kizárás" problémakörének felel meg, a második megoldási mód új, itt erre szánunk egy kis idõt: A folyamatok közti "csatorna" lehet fizikai vagy virtuális. Ezen keresztül az egyik folyamat üzenetet küld a másik folyamatnak, amely veszi azt. A csatorna fontos tulajdonságai: • • • • • az információ átvitelt biztosító közeg micsoda (lehet párhuzamos vagy soros felület, helyi hálózat, speciális hardver adatbusz, ill. virtuális csatorna, ami lényegében közös tárnak felel meg); letseéges egyirányú ill. kétirányú kapcsolat; egy kapcsolatot csak két vagy több folyamat is használhat (pl.

pont-pont összeköttetés két folyamat között, vagy ugyanazt a csatornát pl. idõmultiplexelésben vagy egyidejûleg több folyamat is használhatja; az összeköttetés tartalmazhat közbülsõ adattárolást vagy sem; az összeköttetés megbízhatósága. A folyamatok megnevezése Ahhoz, hogy a kommunikációban a folyamatok egymásra hívatkozhassanak, valamilyen megnevezést kell adni nekik. Ennek külön módszere van (naming) Ennek alappján az alábbi kommunikáció típusok használatosak: Közvetlen kommunikáció: E formában mindkét folyamat megnevezi a másik folyamatot. Két folyamat között pontosan egy kommunikációs csatorna létezik, s ezen keresztül más folyamatok nem kommunikálhatnak egymással. A két alapvetõ mûvelet ebben a formában: • send(P, üzenet); (a P folyamat számára üzenetet küldeni) • receive(Q, üzenet); (a Q folyamattól üzenetet fogadni). Közvetett kommunikáció: Ekkor a kommunikáció egy postaládának nevezett (mailbox)

közbülsõ adatszerkezeten át valósul meg. Ebben az esetben két folyamat több postaládát is használhat, és egy postaládát több folyamat is felhasználhat. A send és a receive utasításokban ekkor a postaládára kell hívatkozni. Kérdés, hogyan lehet elosztani az adott postaládában lévõ üzeneteket a venni kívánó folyamatok között? Használt módszerek: • eleve csak két folyamat használhat egy postaládát; • egy idõben csak egy folyamat lehet a "vevõ" állapotban, s akkor õ kap mindent a postaládából; • a rendszer választ arról, hogy melyik vevõnek küldi az üzenetet, s errõl értesíti az adót; Aszimmetrikus megnevezés: A kommunikálni kívánó folyamatok közül vagy az adó vagy a vevõ egy vagy több kaput (port) használ, amelyen/amelyeken keresztül több folyamattal is kommunikálhat. Aszimmetrikus megnevezés esetén az a fél, amelyik a kaput használja, információt kap arról, hogy a kommunikáció másik végén

melyik folyamat áll (ha minden folyamathoz csak egy kapu tartozhat, annak megnevezése szükségtelen). Tipikus eset, hogy a kapu a vevõ folyamathoz tartozik, s az adó folyamatnak kell megneveznie a vevõ folyamatot, illetve ha annak több kapuja van, annak egy konkrét kapuját. Üzenetszórás: Ekkor létezik egy több folyamatot összekötõ közeg (pl. lokális hálózat vag adatbusz), azon "szétterül" az üzenet, s azt e közeghez kötött több folyamat is veheti. A folyamtok közti kommunikáció szinkronizálása A kommunikációra használt átviteli közeg tulajdonságaitól függõen a folyamatok közti kommunikáció szinkronizálása különbözõ módokon történhet: Tárolás nélküli átvitel: A kommunikációs közeg nem rendelkezik tároló pufferrel, afolyamatok közti adásvétel egyidejûleg kell történjék (randevúzás); Véges kapacitású tárolóval bíró köezegek esetén: Az adó és a vevõ egyaránt hozzáférhet egy véges

tárkapactitású puffer tartalmához. A fufferbe való beírás és kiolvasás ekkor nem lehet egyidejû (pl. R232 esetén "öszvér karakter kiküldése", rövid távon biztosítani kell a kölcsönös kizárást: a vevõnek várnia kell, amíg az adó befejezi egy üzenet küldését, ill. az adónak várnia kell, amíg egy üzenet kiolvasása nem fejezõdött be; Ha a pufferbe több üzenet is fér, az adónak nem kell várakoznia addig, amíg van hely a pufferban. Az adó általában nem szerez arról tudomást, hogy a vevõ mikor olvassa el az üzenetét. Ha szükséges, a rendszer küldhet nyugtát az üzenet vételérõl. Egy másik megoldás, ha a vevõ fél egy másik csatornán visszajelzi az adónak az üzenet vételét. Végtelen kapacitású tároló: Erre akkor van szükség, ha az OP.R nem képes szbályozni az adó mûködését (pl az egy az OP.R-tõl független külsõ folyamat); Ekkor az adót nem lehet várakoztatni, s elvileg végtelen kapacitású

puffert kell a rendelkezésére bocsátani. Ekkor tipikus kommunikációs hibák fordulhatnak elõ: • túlcsordulás: a puffer tényleges betelése után küldött információ egyszerûen elvész; • már beírt információ sérülése: a pufferben (esetleg részlegesen) felülíródik egy méag abból ki nem olvasott (esetleg részlegesen kiolvasott) információ. Átviteli hibák kezelési módszerei A kommunikációs csatorna hibás mûködésén túl egyéb tipikus okokból is keletkezhetnek átviteli hibák: • Folyamat befejezõdése miatt: akár az adó, akár a vevõ folyamat váratlanul befejezõdik; - Az adó folyamat áll le: a vevõ hiába várakozik a következõ üzenetre; felodása egyszerû: az OP.R jelezheti a vevõnek az adó megszûntét, ill terminálhatja a vevõ folyamatot is. - A vevõ folyamat megszûnésekor: akármekkora is a puffer a közegben, az elõbb-utóbb betelik, s az adó folyamat várakozni kényszerül, s a vétel hiányát csak a

"nyugták" elmaradásából veheti észre; a helyzet feloldása a fenti esetéhez lehet hasonló. Folyamatok leállásának detektálása: idõkorlát (timeout) segítségével: ez egy tipikus idõtartam, amely alatt bizonyosan történnie kellene valami kommunikációnak. (Tényleges megállapítása negyon nehéz). Torzult üzenetek kezelése: • biznyos beépített redundanciákból (pl. checksum) a rendszer felismerheti a torzulást, s újra küldheti az üzenete; • az OP.R felimeri a hibát, értesíti róla az adót, s az üzenet megismétlését kéri tõle; • a vevõ is felismerheti a hibát, s kérheti az adótól az üzenet megismétlését. Általában az üzenetek torzulását könnyebb detektálni, mint azok eltûnését. Példa modern kommunikációra a MACH OP.R-bõl: Ebben az OP.R-ben valamennyi információ-csere üzenetekkel (message) történik: • • • • • Rendszerhívások: ∀ folyamat létrejöttekor automatikusan kap két kaput a

rendszerhívásokra: - Kernel kapu: a folyamat általi rendszerhívások lebonyolításának céljára; - Notify kapu: az OP.R ezen keresztül küld értesítést a folyamat számára a reá tartozó események bekövetkezésérõl; Távoli eljáráshívás: msg rpc: elküld egy üzenetet, s bevár egy darab válaszüzenetet; Normál kommunikáció: a nem rendszerhívásokra szolgáló kommunikációhoz: - port allocate hívás szolgál kapuk létrehozására; - a kapu tulajdonosa automatikusan az azt megrendelõ folyamat lesz, ez az egeydüli folyamat, amelynek olvasási joga van az adott kapuhoz; - a folyamat ezt az olvasási jogot átadhatja más folyamatnak - a kapuhoz véges tárkapacitás tartozik; - az OP.R biztosítja, hogy az azonos folyamattól egymás után érkezõ üzenetek a helyes sorrendben várakozzanak a kiolvasásra; Az üzenetek struktúrája: fix méretû fej és változó méretû "törzs"; - a fej két kapu megjelölését tartalmazza: azt a címet,

ahová az üzenetet küldték, s azt a címet, amelyre a küldõ folyamat választ vár; - a fej tartalmazza még a törzs hosszát; Üzenetek vétele: - az msg receive eljárással, amelyhez vagy egy kaput, vagy kapuk halmazát lehet megadni; - az eljárásnak meg kell adni azt is, mi a teendõ, ha nem talál kiolvasandó üzenetet; a lehetõségek: várakozás a következõ üzenetre; legfeljebb n msec várakozás a következõ üzenetre; nincs várakozás; • Adott kapun várakozó üzenetek számának lekérdezése: a port status eljárással; • Üzenetek küldése: msg send eljárással; a folyamatnak meg kell adnia, mi a teendõ, ha a küldött üzenet várakozni kényszerül (aza nincs elég hely a címzett pufferban, hogy azonnal beíródjon): lehetõségek: várakozás; legfeljebb n msec várakozás; nincs várakozás; meg lehet bízni az OP.R-t, hogy átmenetileg tárolja az üzenetet, igyekezzék azt leadni, s jelezzen vissza, ha sikerült (∀ kapuhoz csak egy

üzenet ideiglenes tárolására van mód; Az adatkommunikáció alapvetô változatai az RS232 interfész példáján A különbözô gépek közötti adatkommunikáció vagy párbeszéd szabályai az emberek közti kommunikációs szabályok átvételén alapul. A párbeszédben résztvevô partnerek azonban általában nem egyenrangúak egymással. A számítástechnikában elôforduló, egymással összekapcsolható, képernyôvel és billentyûzettel ellátott eszközök vagy más néven terminálok alapvetôen két fô típusba sorolhatók. Data Terminal Equipment, azaz "adatterminál eszköz", amely "csak nyeli" a részére kiküldött adatokat, de automatikusan nem szól vissza a küldô fél részére azzal kapcsolatban, hogy a beletöltött adatokat megfelelôen fel tudta-e dolgozni. (Erre a küldô félnél mûködô szoftverbôl kell tekintettel lenni.) Data Computer Equipment, azaz olyan viszonylag intelligensebb eszköz, amellyel szimultán

kétirányú adatforgalom valósítható meg, s így az a küldô fél felé folyamatosan képes visszajelezni az adatok vételével kapcsolatban. A fenti kétféle típus segítségével a következô ún. adatforgalmi típusok valósíthatók meg: "Duplex üzemmód": egyidôben kétirányú információforgalom. "Half-Duplex üzemmód":, idôben nem szimultán, hanem felváltva folyó "oda-vissza" adatforgalom. "Szimplex üzemmód": mindig csak egyirányban folyó üzemmód. Az adatok átvitele a kettes számrendszerre jellemzô legelemibb egységekben, azaz bitekben történik akkor is, amikor a küldô szoftverek "felhasználói szintjén" e felbontás "nem jelenik meg". A biteknek a jeladó oldalán két stabil feszültségértékbôl építkezô "négyszögjelek" felelnek meg, amelyek a vezeték szórt kapacitásain torzuló váltóáramok terjednek. Az egy byte információ bitekre való

"feldarabolásának", és bitenként egymás utáni kiküldésének módszere miatt nevezik az RS232 interfészt "soros" interfésznek. A két feszültségérték közti ingadozás bizonyos frekvenciával történik. Ahhoz, hogy az információ egyértelmûen "olvasható legyen" a fogadó oldalon, a "0" és "1" értékek között "billegõ" kiadott jelbõl a vevõ oldalán a küldô oldal jeleivel "idôben szinkronizált" módon kell "mintákat venni", ami megfelel a jel "betöltésének" egy alkalmi "pufferba". (A vevõ oldal számítógépének vagy termináljának külön szoftverbõl kell gondoskodnia ezen puffertartalom további elhasználásáról.) A szinkronizálásra alapvetôen két módszer létezik: Szinkron adatátvitel: ekkor a két eszközt összekötô vezetékkötegben egy szálat egy "ún." órajel átvitelére használnak fel, amelyet a küldô fél ad ki, s

amelynek segítségével az adatok küldése és fogadása pontosan szinkronizálva van egymással. Aszinkron adatátvitel: ebben az esetben nincs szükség külön drótszálra az órajel átvitelére. E módszer azon alapul, hogy gyárilag közelítôen biztosítható két különbözô óra azonos frekvenciája. Amennyiben az adatok küldôje a fogadó felé az adás kezdetét egy startjel; segítségével jelzi a fogadó fél felé. A két félen lévô óra közel azonos frekvenciája miatt a két óra járása rövid idô alatt nem sokat csúszik szét egymástól. A szinkronizáció módjai és a forgalmi típusok kombinációjával elvileg többféle módozat lenne kialakítható. A gyakorlatban kétféle fô típus terjedt el Ezek egymástól abban is különböznek, hogy a szabványos RS232 interface (csatlakozó) lábai közül különbözôeket és különbözô számúakat használnak fel az adatátvitelre. (A nem használt csatlakozó lábakra egyszerûen nem kell

huzalokat kötni) SOROS, ASZINKRON, EGYIRÁNYÚ ADATÁTVITEL Ez a módszer az alábbi elveken alapul: * Az adó fél nem ellenôrzi, hogy a vett jellel mi történik a vevô oldalon. Az adó a vevô állapotára való tekintet nélkül ömleszti az adatokat, s azok biztonságos beolvasásáról csak a vevô oldalon használt szoftver nagyon gyors mûködésével lehet gondoskodni. * Tudjuk, hogy a programozás szempontjából a legkisebb információegység az egy byte. Pl ASSEMBLER-ben való programozással legkevesebb 1 byte kiírására lehet utasítást adni. Honnan tudja a vevô oldalán lévô szoftver, hogy az átvitel folyamán bitekre bontott karakter adatvonalra való kiküldése már befejezôdött? Erre a célra az RS232 interfészt külön vezérlô processzor státusz (állapot) regiszterének bitjei, az ún. állapotbitek adnak felvilágosítást a kommunikációs szoftvernek. E regiszter tartalma egy egyszerû utasítással beolvasható az i8086, i808286, i80386

processzor valamelyik regiszterébe, s ott bitenként megvizsgálható. A megfelelô információt az ún. TX Ready nevezetû, (azaz a szöveg kiadására -T=Transzfer=átvitel-- vonatkozó) bit tartalma hordozza: ha ennek értéke "1", az adó "pufferében" lévô egy karakter bitenkénti kiadása már befejezôdött, a pufferbe betölthetô a következô karakter. Ha a "TX Ready" bit értéke "0", a karakter kiadása még nem fejezôdött be, azaz a következô karaktert még nem célszerû kiadni a pufferbe. (Az új byte beírása ekkor is lehetséges, de azzal a veszéllyel járhat, hogy az adatvonalra így végül is kiküldött byte "elsô része" a pufferben eredetileg bent ülô karakterbôl, "második része" az újonnan beírt karakterbôl tevôdik össze, tehát "öszvér" karakter keletkezik, a kiküldendô információ tehát sérül. * Az RS232 vezérlésével foglalkozó processzor "TX

Ready" állapotbitjén lévô feszültség közvetlenül galvanikusan is megjelenik egy IC lábon, így az adatkommunikáció jelentôsen gyorsítható, ha a státuszbiteket nem szoftverbôl vizsgáljuk, mint a fenti esetben, hanem errôl a lábról közvetlenül indítható egy hardver interrupt is. * A módszer mindössze két szál segédhuzal bekötését igényli: a közös "föld"-huzalét, valamint az adó oldal RS232 interfésze vezérlésével foglalkozó processzor "TX Ready" bitjének állapotát hordozó huzalét. * A vevô oldal a az adó "TX Ready" vezetéke jelének ugrásából tudja megállapítani, hogy mikor kezdôdik ill. végzôdik a 8 bitnyi információ leadása Amint a vezeték állapota az adás befejeztét jelzi, az egy byte információt azonnal be kell olvasni ebbôl a pufferbôl. Ennek leggyorsabb módja egy hardver interrupt, amelyet ezen vezetéknek az adatkiadás befejeztét jelzô állapotba való

"átbillenése" vált ki. * A fogadó oldalon az adat kiolvasására korlátozott idô (kb. 150 msec) áll rendelkezésre. Ennyi idô eltelte után az adó fél nekifog a következô byte bitekre való "felszeletelésének" és szeletekben való kiküldésének. Ennek eredményeképpen, amennyiben a vevô fél 150 msec alatt nem olvasta be a karaktert a fogadó pufferbôl, abban megintcsak "öszvér" karakter képzôdhet a fogadó pufferban már korábban bentlévô, illetve a részlegesen már beírt új adatokból. Ilyen esetekben szokott a "Timeout" (idôbôl való "kifutás") hibaüzenet elõfordulni. E jel figyelmeztet arra, hogy a vevô pufferbôl már nincs értelme kiolvasni a benne lévô adatot, hiszen annak sértetlensége eleve nem biztosított. * A "TX Ready" vezetéken való jelugrás közötti idôszakban kiadott és befogadott jelek olvasására érvényes a közelítô szinkronizáltság. * Az

adatátvitelben elôfordulhatnak hibák. Ezek egy részét a rendszer megkísérli figyelni, s egy speciális státusz bit segítségével a vevô oldalon a hibát jelezni. Az adatnak a vevôpufferbôl való kiolvasása elôtt érdemes ennek a bitnek az állapotát is megvizsgálni, azt eldöntendô, hogy egyáltalán van-e értelme ezt az adatot felhasználni. * Az fogadó RS232 processzor rendelkezik egy ún. "RX Ready" (azaz a vett jel -R=Receive=fogadni-- befogadását jelzô) státusz (állapot) bittel, amelynek értéke "1", hogyha a pufferben még egy érvényes, az imént befogadott karakter ül. A puffer kiolvasása után e bit értéke automatikusan "0"-ra vált, jelezve, hogy a processzor készen áll egy új jel befogadására. OPCIONÁLIS VISSZAKÉRDEZÉS LEHETÕSÉGÉVEL BÕVÍTETT ASZINKRON MÓDSZER Magától kínálkozik annak a lehetôsége, hogy a fenti szisztémába a fogadó processzor "RX Ready" jelét egy újabb

drótszál bekötésével visszavezetjük a küldô processzorhoz. Ezzel módunkban áll "lassúbb" fogadópartner felé adatot közölni, hiszen az újabb byte kiküldésével várni lehet a fogadó puffer kiürüléséig. SZOFISZTIKÁLTABB MÓDSZEREK A fenti egyszerû módszernél bonyolultabb eljárások a csatlakozók egyéb lábainak "behuzalozásával" érhetôk el. Ezek közül igen fontosak az alábbiak: "Data Set Ready Bit (DSR)", amelynek "1" értéke azt jelzi, hogy a partner készülék egyáltalán be van kapcsolva, míg "0" állapota arra utal, hogy a partnert be sem kapcsolták, tehát eleve fölösleges a kommunikációval kísérletezni. A "Request To Send (RTS)" láb jelentése: információ kérése. Ha ennek az értékét szoftverbôl "1"-re állítom, a partner felé ezzel jelzem, hogy tôle várok adatokat. A "Clear To Send (CTS) bit " "1" értéke azt jelzi, hogy az adott

interfész jeladásra készen áll. Miután az adatok fogadására felkészült fél beállította a maga RTS jelét, s meggyôzôdött róla, hogy a partner CTS vezetéke adási szándékot jelez, vételre kell állnia, s meg kell kezdenie a vételt. SZINKRON ÜZEMMÓD Kihasználva a közös órajel lehetôsége kínálta kényelmet, ilyenkor az adatvonalon a küldô részérôl vagy tényleges adat jelenik meg, vagy az érdemi információ küldésének szüneteiben "folyamatosan ömlik" rajta a "Break" karakter. A break karakternek a vevô félben meghatározott reakciót kell kiváltani, amelybôl eldönthetô, hogy szakadt-e az adatvezeték. Fôleg nagy távolságra történô információközlésnél az adatok viszonylag nagy valószínûséggel sérülhetnek. Ilyenkor elônyös a duplex üzemmód, amely felhasználható arra, hogy a fogadó fél pufferébe kiküldött adatot visszakérje a kiküldô fél, s amennyiben az a kiküldeni szándékozott adattól

eltér, a kiküldést addig ismételgesse, amíg a kiküldött értéket nem kapja vissza, s csak az ilyen adatok felhasználását engedélyezze a vevô félnek. Tipikus adatátviteli követelmények: 1. kategória: emberi hang átvitele: • kezdetben telefonon, analóg módon történt; • ma digitalizálva, adatcsomagok (packet files) formában; * • szükséges átviteli kapacitás: 64 kb /sec: az analóg hangból 8000 mintavétel/sec, 8 bit felbontással digitalizálva; (8×1000×8 bit /sec, azaz cca. 64000 bit/sec ≅ 64×1024 bit/sec); (szûkebb frekvencia sávszélességû eszközökön kompresszálva kisebb sávszélesség mellett is átvihetõ); • fõ probléma: a párbeszéd folyamatosságának fenntartása: néhányszor 10 msec késés széteséshez vezethet. 1 kb ≡ 1 kilobit a konvencionális jelölés, míg 1 K (nagy betûvel) 1 kilobyte információt jelöl. Továbbá, a nagy B betû szokott lenni a "byte" egység jelölése, így pl. 1 KB = 1 kilobyte,

1 Mb = 1 megabit, 1 MB = 1 megabyte * 2. Videoképek átvitele (kép és hang szimultán): • kábel televízión vagy drótmentes rendszerekben analóg átvitel használatos; (a VHS minõségû analóg átvitel 6 MHz frekvencia sávszélességet igényel); • digitalizált VHS minõségû átvitel: 100 Mb/sec kompresszálás nélkül, 1.56 Mb/s kompresszálással; (ma a valós idejû kompresszálás erre a célra túl drága, ezért átvitel elõtt elõbb külön kompresszálják a video felvételeket; bár ez a kompresszált átviteli igény nagyobb, mint a hang igénye, ma különösebb problémát sávszélesség szempontjából nem jelent); 3. Adatállomány (Data Files) átvitele: • Ezek lehetnek igen sokfélék: számítógépes programok, grafikus fájlok, tárolt video anyagok, stb.; • Az, hogy szükség van-e valósidejû adatátvitelre, s mekkora sávszéleségre, az a felhasználásuk módjától függ; • Példa: 1000×1000 pixeles CAD rajz 24 bit

színábrázolással kb. 24 Mb (3 MB) információt hordoz; Átvitele az ISDN (Integrated Digital service Network) hálózaton az arra érvényes 64 kb/s mellet több, mint 6 min idõt igényelne; Ugyanez FDDI (Fiber Distributed Data Interface)-en 100 Mb/s mellett ¼ sec lenne, ha a rendszer idõosztásban dolgozna; (egy 32 állomásos LAN esetén (Local Area Network) idõosztás mellet ez 8 sec idõbe kerülne); A fenti igényeket egyszerre kielégítõ kompromisszumnak látszikaz ATM (Asinchronous Transfer Mode, azaz aszinkron adatátviteli mód) technológia, emiatt az látszik terjedni.+ Míg az egyéb adatátviteli technikák az adatformát és az átviteli sebességet "szorosan összekötik egymással", az ATM szabvány mindössze 53-byte cella formát ír elõ, a "frame"-re, az adatátviteli sebességre és az átvitel fizikai közegére való megszorítás nélkül*. Ennek üzleti elõnyei vannak: míg más módszerek bérlõi, ha általában nagy

sávszélességre (pl. tipikus kategóriák 10 Mb/s, 1.544 Mb/s ill 100 Mb/s, 155 Mb/s) van szükségük, kénytelenek azt folyamatosan bérelni, a tényleges forgalomtól függetlenül. Az ATM használói a ténylegesen kiküldött cellák száma után fizetnek, s nem egy speciális eszközpark sebességéért. Adatfájlok átvitele Az adatfájlok kisebb egységekre, ún. "frame"-ekre feldarabolódva kerülnek átvitelre Ezek a darabok olyan méretûek, amelyeket a hálózat még kellemesen tud kezelni. Az egyes adagokhoz vag frame-ekhez kiegészítõ információk ("headers") adódnak hozzá, amelyek olyan segédinformációkat tartalmaznak, amelyek alapján a nagy adatfile darabjai a fogadó oldalon újra "összeilleszthetõk" egymással. A kiegészítõ információk nemzetközileg szabványosított módja az OSI (Open Systems Interconnections, azaz nyitott rendszerek összekapcsolása) szabvány, amely az adatátvitelt szabályozza. Alapelemei az

alábbiak: A kommunikációs protokollok OSI referencia modellje Réteg (Layer) + A megfelelõ réteg funkciója IEEE Spectrum, 1994. júniusi szám, 19-24 oldal, Arthur Miller: "From here to ATM" c cikke alapján IEEE Spectrum, 1994. februári szám, 42-45 oldal, Jim Lane: "ATM knits vioce, data on any net" c cikke nyomán. * Felhasználói (Application) Az átvitt információ feldolgozásához kellõ szolgáltatás-elemeket adja: erõforrások elosztása (sharing), file átvitel, adatbázis kezelés; Formázás (Presentation) A kicserélt adatok megfelelõ formába hozását, valamint az egyes szekciók közti dialógus menedzselését végzi; Szekció (Session) Átvitel (Transport) Hálózat (Network) Adatkapcsolás (Datalink) A kapcsolatok létrehozása és megszüntetése; a felhasználói jogok megadása a szolgáltatás folyamán; az adatátvitel szinkronizálása; A hibamentes adatátvitelt biztosítja: a folyam vezérlése, a hibák

kijavítása, visszaigazolás a küldõ félnek; Az adatátvitelt végzõ közegek egymással összekötve. Fizikai szint (Physical) Az adott fizikai közegen való adatátvitel szabályait bocsátja rendellkezésre: csomagformák, hozzáférési jogok, hibadetektálás és korrekciók; Az egyes állomások közti kapcsolat mechanikai és/vagy elektromos szintje. Az adatátvitelnél a küldõ oldalon az átviendõ információt jelentõ "információdarabra" mindegyik réteg "réteszi" a maga htáskörébe esõ járulékos információt, amelyet a fogadó oldalon a megfelelõ szint "leszed, továbbítva azt a következõ szintnek. • • • • • • A "fizikai" és az "adatkapcsolási" szinten az adatcsomag az alábbi részekbõl áll: "Flag"; "Frame Control Information": a "frame" típusát azonosítja; "Destination Address": rendeltetési cím, ahová az adag küldendõ; "Source

Address": a küldõ egység címe; "Payload": maga az elküldendõ hasznos információ; "CRC=Cyclical Redundancy Check": redundáns információ a hibák kiszûrésére. Az információ szállítására használt közegek: 1. Rézhuzal alapú galvanikus csatlakozások: • koaxiális kábel: a kezdeti években igen elterjedt volt a LAN és WAN (Local Area Network = helyi hálózat kb. 100 m huzalhosszig, Wide Area Network 100 m felett = Széles Területi hálózat) esetében az alábbi tipikus üzemmódokban: 1.544 Mb/s, 2048 Mb/s ill 10 Mb/s Ethernet hálózatokon; Hátránya, hogy vastag. merev, nehezen csapolhat/csatlakoztatható; • hang- ill. adatminõségû (voice- and data-grade) árnyékolatlan, csavart huzalpár (3 UTP, ill. 5 UTP = Unshielded Twisted Pair): 100 m távon vagy az alatt, az Ethernet igényeit kielégíti; az 5. kategória eladása 1992 folyamá duplája volt a hármasénak, igen terjed; • Árnyékolt, csavart huzalpár (STP =

Shielded Twisted Pair, IBM Type 1): szinte kizárólag az IEEE 82.5 hálózatok használják Olcsó (kb 70 US$/ 100 m installációs költséggel együtt); Várakozások szerint a 156 Mb/s átvitel is elérhetõ vele. 2. Száloptikák: • Nagy sávszéllességre és nagy távolságokra (több 10 km nagyságrend) elõnyösek; általában a száloptikák és a csatlakozó elemek drágák, s az installáció költsége is magas (kb. 400 US$/100 m); • Kétféle, kereskedelmi forgalomban is kapható fényforrás és "fénydetektor" kapható hozzájuk: λ=850 nm (olcsóbb, de a távolsággal erõsebben csillapodik), ill. λ=1300 nm (drágább, de kisebb csillapodású), midkettõ használható egy- ill. többmódusú üzemmódban; 3. Huzalmentes megoldások (rádióhullámok): • Sávszélessége korlátozott; • Szabványosítása nincs nagyon elõrehaladott állapotban, bár folyamatban van; • Forgalmazásában különbözõ sémákkal kísérleteznek (pl. telefon

MODEM csatlakozással). Holtpontkezelési problémák Holtpont: olyan szituáció, amelyben több folyamat olyan eseményre vár, amelyet csak egy szintén várakozó folyamat tudna elõidézni. A probléma jelentõsége a rendszerek bonyolultságának és kapacitásának növekedésével egyre nagyobb lesz a jövõben. Holtpont kialakulása: Az alábbi rendszermodell esetén tekintjük a holtpont problémát: • • • • véges számú erõforrást kell felosztani az ezekre igényt tartó folyamatok között: az erõforrások osztályokba sorolhatók: az azonos osztályokba tartozó erõforrások közül egy igénylõ folyamat bármelyiket igénybe veheti; az erõforrások használati módja lehet - osztottan használható erõforrás; - kizárólagosan használható erõforrások, ez utóbbiak lehetnek * elvehetõ (preemtable) * nem elvehetõ (non-preemptable) folyamatok (ez utóbbiak egészen addig tartoznak egyfolyamathoz, amíg az le nem mond róluk); az erõforrások

használatba vétele az alábbi lépéseken keresztül lehetséges: - igénylés: ha az igény nem teljesíthetõ, mert az igényelt erõforrás használt, a folyamat várakozni kényszerül: - felhasználás: a folyamat kizárólagosan használja az adott erõforrást; - felszabadítás: az adott folyamat felszabadítja az erõforrást, amelyet ezután igénybe vehet egy másik, arra váró folyamat; A holtpont kialakulásának szükséges feltételei: • • • • A folyamatok az erõforrások közül legalább egyet kizárólagosan használnak; Van olyan folyamat, amely lefoglalva tart valamilyen erõforrást, miközben egy másik erõforrásra (erõforrásokra) várakozik; vannak nem elvehetõ erõforrások a rendszerben; a rendszerben körkörös várakozás alakul ki: ez azt jelenti, hogy a folyamatok közül kiválasztható olyan {P0, P1,.,Pn} folyamat részhalmaz mint rendezett sorozat, amelyben P0 egy P1 által lefoglalt, P1 egy P2 által lefoglalt,., s Pn egy P0 által

lefogalt erõforrásra vár. A rendszer állapotát az irányított erõforrás használati gráf (resource allocation graph) segítségével lehet leírni, amelyben • a Pi csomópontok konkrát folymatokat jelölnek, • az Ri csomópontok erõforrás osztályokhoz tartoznak, • a PiRj átmenetek erõforás igénylést jelölnek, • az RjPi átmenetek erõforrás használatot kódolnak; A gráfban az igénylési ág azonnal átvált használati ággá, amint az igény kielégül. A holtpont a gráfban lévõ ciklusok figyelésével állapítható meg: egy ciklus léte nem okvetlenül elégséges feltétele a holtpont kialakulásának. Tipikus példák alább: R1 P1 R2 P2 P3 R3 Igénylés Használat Példa holtpont létezésére zárt ciklus mellett R1 P1 R2 P2 P3 R3 Igénylés Használat Amennyiben P3-nak R3 "felsõ gombócát" átadhatja a rendszer a holtpont feloldásaképp, P3 lefuthat: R1 P1 R2 P2 P3 R3 Igénylés Használat Utána P2 is

lefuthat, majd ezt követően P1 is; R1 P1 R2 P2 P3 R3 Igénylés Használat Ha P3 az R3 "bal oldali gombócát" adhatnáná a rendszer, P3 lefutása után P2 megkaphatná R2-t, majd ennek lefutása után P1 megkaphatná R1-et és R3-at. R1 P1 R2 P2 P3 R3 Igénylés Használat A következõ példában bár ciklus van jelen, holtpont azért nem alakul ki, mert mindkét erõforrás osztáyban, aelyekbõl a cilkus kialakul, valamelyik kigényelhetõ elem elõbb-utóbb felszabadul: P1 P2 R1 P3 R2 P4 Példa olyan ciklusra, amely nem jelent holtpontot. Ugyan az R1 és R2 osztály összes elemének pillanatnyi foglaltsága miatt P4 és P2 is várakozik, P1 végeztével pl. P4 lefuthat, s ezután P2 megkaphatja R2 P4 által lefoglalt részét, vagy P3 végeztével P2 futhat le, s R1 megfelelõ részének felszbadultával P4 is lefuthat. Általában az erõforráshasználati gráfban a ciklus szükséges feltétele a holtpontnak. Amennyiben valamennyi

erõforrás osztály csak egyetlen erõforrást tartalmaz, a ciklus elégséges feltétel is egyben. A holtpontkezelés lehetõségei: A holtpont kialakulásának elkerülése: • holtpont megelõzéssel (deadlock prevention); Mivel a kölcsönös kizárás feltétele általában nem kerülhetõ meg, avalamelyik ettõl eltérõ, a holtpont kialakulásához szükséges feltételt kell megszüntetni, például a foglalva várakozás állapot elkerülésével. Ennek módjai: - a folyamat indulásakor egyszerre kiigényli a neki kellõ összes erõforrást, s csak akkor futhat, ha valamennyi a rendelkezésre áll; vagy - a folyamat csak akkor igényelhet ki egy erõforrást, ha már más erõforrást nem használ. Hátrányok: nagy a kiéhezés veszélye, az erõforrások kihasználtsága pocsék; Másik módszer az erõforrások elvétele: - ha egy folyamatnak van nem kielégíthetõ erõforrás igénye, az OP.R elveheti tõle az összes lefoglalt erõforrást, vagy - ha egy folyamatnak

olyan erõforrásra van szüksége, amely pillanatnyilag foglalt, az OP.R megnézi, hogy ez a foglaltság egy szintén várakozó folyamattól ered-e; ha igen, az erõforrás e várakozótól vétetik el az éppen igénylõ javára; ha nincs ilyen várakozó folyamat, egyszerûen az igénylõ folyamat is várakozni kezd. Hátrányok: az erõforrások elvétele egy folyamattól sokszor azzal jár, hogy annak futási eredményei is elveszenk. Itt is elõfordulhat a kiéhezés Harmadik módszer a körkörös várakozás kiiktatása: a rendszer összes erõforrása megszámozható egy növekvõ számsorozattal. Ekkor például - biztosítjuk, hogy a folyamatok csak növekvõ sorrendben igényelnek erõforrásokat, vagy - vagy biztosítjuk, hogy egy folyamat csak akkor igényelhet ki egy erõforrást, ha nem használ egy annál magasabb sorszámút. Hátrány: a sorszámozás általában önkényes lesz, s nem felel meg a változékony gyakorlati igényeknek • holtpont elkerüléssel

(deadlock avoidance); A holtpont kialakulásának feltételei megmaradnak ugyan, de az erõforrások allokálása "óvatosan történik". Ez a módszer akkor használható, ha - biztos, hogy valamennyi olyan folyamat, amelynek erõforrás igényei maximálisan ki vannak elégítve, véges idõ alatt lefut, s ezután felszabadulnak az általa lefoglalt erõforrások; - valamennyi folyamatról elõre ismert, hogy milyen erõforrás típusból maximálisan mennyi igényel egyidejûleg lefoglalva, Ennek kapcsán Biztonságos állapot (safe state) egy olyan szituáció, amelyben a folyamatok igényei kielégítésre található olyan sorrend, hogy ezzel az összes folyamat le tud futni. Biztonságos sorrend (safe sequence) a folymatok olyan {P1, P2,.Pn} sorrendje, amennyiben bármelyik Pi igénye kielégíthetõ a még le nem foglalt, vagy a sorrendben az i. folyamat elõtt álló folymatok által használt, s majd felszabadított erõforrásokkal. Biztosnágos állapotban nem

alakul ki holtpont. Egy nem biztonságos állapot még nem garantálja holtpont kialakulását. A holtpontra vezetõ állpotok csupán a nem biztonságos állapotok halmazásnak részhalmazai. Egy stratégiai lehetõség a holtpont elkerülésére, ha csak biztonságos állapot létrejöttét engedjük meg ("banker algorithm"). Az algoritmusnak vannak hátrányai: idõigényes, bonyolult; a mûködéséhez kellõ alapfeltételek általában nem adottak a valóságban (a folyamatok száma ismerendõ elõre, azok maximális igényei, az egyes folyamatok biztos befejezõdése) inkább fiktív mint valós feltételezések; • nagy mértékben rontja az erõforrások kihasználtságát, a beépített "óvatosság" miatt túl sokáig várakoztat egyes folyamatokat. • • A holtpont kialakulása utáni beavatkozás módszere: ennek két lépése • holtpont felismerés (deadlock recognition) • holtpont megszüntetés (deadlock recovery); Holtpont felismerés:

Alapmódszer: nem fololdható hurkok keresése az erõforrás-foglalási gráfban. Egy algoritmikus megoldás a gráf-redukció módszere. Ez egy "optimista" pontosabban problémaelhalasztó alapstratégián alapul: a holtpont fennállásának szükséges feltételeibõl még nem következik, hogy a holtpont pillanatnyilag fennáll. A problémával elegendõ akkor foglalkozni, amikor az bekövetkezik. Ennek megfelelõen a módszer alapötlete: • • ha egy éppen vizsgált állapotban egy folyamat valamennyi igénye kielégíthetõ, akkor a hozzá tartozó összes igény és foglaltság ág törölhetõ a gráfból azzal a reménnyel, hogy a folymat elõbb utóbb úgyis visszaadja azokat, tehát foglaltságuk átmeneti, így a holtpont kialakulása szempontjából pillanatnyilag nem kell velük foglalkozni; ha ezek az erõforrások valami okból mégis sokáig lekötve maradnak, a holtpont majd a késõbbi idõpontban fedezhetõ fel; amennyiben a fenti redukció után

maradtak kielégítetlen igények, akkor az ezekel bíró folyamatok holtpontban vannak (vesznek részt); Problémák az algoritmussal: • idõigényes, • nehéz meghatározni, milyen gyakran kell futtatni: túl gyakori futtatás lassítja a rendszert a futás nagy idõigénye miatt; túl ritka futtatás esetén sokáig várakoznak a folyamatok a holtpontban, emiatt romlik a rendszer hatékonysága; • maga a holtpont akkor jön létre, amikor az egyik folyamat behívásával az erõforráshasználati gráfban elõször jelenik meg egy kritikus hurok; egy elvi lehetõség lenne az algoritmus lefuttatása minden egyes ilyen "igény-kielégítés" után; ez ugyan idõigényes, de azonnal meg lehet belõle tudni azt az információt, hogy melyik folyamat "zárta be" a hurkot, s ez az információ használható a holtpont felszámolásánál; Holtpont megszüntetés: A holtpont felszámolásának elvi lehetõségei: Folyamatok terminálásával: • Minden

olyan folyamat terminálása, amely a holtpontban résztvesz; ez a emgoldás rendkívül pazarló, primitív és barbár: a megszüntetett folyamatok eredményei elveszhetnek; más módszer: • elkezdjük egyenként megszüntetni a holtpontban résztvevõ folyamatokat, egészen addig, amíg a holtpont meg nem szûnik; ehhez célszerû valami prioritási kritériumok alapján kivlasztani a megszüntetendõ folyamatokat: az adott folyamat hány holtponti hurokban vesz részt; eleve mekkora volt a prioritása, nyilván magasabb prioritású folyamatokat csak "végszükség" esetén érdemes "agyonverni"; mennyi erõforrást tart lefoglalva: a túlzottan erõforrás-igényes folyamat kiiktatásától inkább várható, hogy a holtpontnak végére jutunk; mennyi egyéb erõforrást igényelne még a jövõben; "mennyire volt közel a maga végéhez": ez a mérlegelés csak akkor használható, ha egy folyamatról sejthetõ elõre, mennyi lenne a futási ideje,

s mérve van, hogy már mennyit futott: egy végéhez közel álló folyamat "agyonütése" sokkal gazdaságtalanabb, mint egy még alig futott folyamat kiiktatása, amelynek még nem volt módja erõforrást igénybe venni, s esetleg elveszthetõ eredményt produkálni.; a kiiktatásra kijelölt folyamat batch program -különösebb botrány nélkül újra indítható annélkül, hogy a terminálnál ülõ felhasználót ezzel idegesítenénk--, vagy interaktív program, amelynek kiiktatása illetlenség egy azzal dolgozó felhasználóval szemben. Erõforrások elvételével: • A holtpontban lévõ folyamatoktól egyesével kezdjük elvenni az erõforrásokat, addig, amíg a holtpont meg nem szûnik; Stratégiai kérdések: - - - Melyik folyamattól melyik erõforrást kell elvenni az adott lépésben? A kiválasztott folyamatot olyan állapotba célszerû visszajuttatni, amelybõl lehetõleg folytatni tudja a maga futását (elõfordulhat az is, hoy újból kell

kezdenie a futást az erõforrás elvétele miatt); Egyes OP.R-ek a folyamatokhoz ellenõrzési pontokat (checkpoint) rendelnek: ezeken a pontokon automatikusan elmentõdik a folyamat teljes álapota és eredményei; amennyiben a folyamnttól erõforrás vétetik el, s emiatt futását majd újra kell kezdeni, elég a legutóbbi ellenõrzési ponttól folytatni a futást (rollback); Vigyázni kell arra, hogy lehetõleg mindig másik folyamattól vegyünk el erõforrást, nehogy a kiéhezés esete forduljon elõ egyes folyamatoknál; Kombinált holtpont-kezelési módszerek: A holtpont kezelésére elmondott módszerek önmagukban túlságosan bonyolultak, s nagy mértékben rontják a rendszer hatékonyságát. Ez részben abból ered, hogy "bánásmód" tekintetében "egy kalap alaá veszik" azokat az erõforrásokat, amelyek foglaltsága a holtpont kialakulására vezethet. A helyzet javításának alapötlete abban áll, hogy észrevesszük: a holtpont

kialakításában szereplõ források jellegzetességeik szerint "csoportokba" sorolhatók, s e ellegüktõl rájuk másmás stratégia alkalmazása lehet elõnyösebb. Az aalpvetõ csoportok az alábbiak: • rendszertáblák és hasonló belsõ erõforrások: ezeket a folyamatok létrejöttükkor azonos sorrendben igénylik ki, ezekre könnyen alkalmazható a "rendezett erõforrás kiigénylés" startégiája; • opreatív tár háttértér birtokában: ez az erõforrás típus különösebb probléma nélkül elvehetõ, hiszen a az elektronikus tár tartalma menthetõ a háttértárba, eredményvesztés így nincs; • kötegelt rendszerek esetén (ahol elõre ismerhetõk az erõforrás igények, szemben egy interaktív rendszerrel), meg lehet próbálkozni holtpont elkerüléssel; • mivel az egyes programok tárcsere igénye (swap) elõre ismert, ezekre lehet elõzetes lefoglalást alkalmazni. Ütemezési feladatok (scheduling) Alapvetõ feladat a

multitask jellegû OP.R-ben: el kell dönteni, hoy egy adott erõforrás csoportot egy adott pillnatban melyik folyamat használhat. A legfontosabb ilyen erõforrás a CPU. A "CPU" ütemezése: E téren hosszútávú, középtávú és rövidtávú ütemezési szinteket érdemes egymástól megkülönböztetni. Nem minden operációs rendszer rendelkezik az összes lehetõséggel. Hosszútávú vagy munka (long term vagy job) ütemezés: Ez dönti el, hogy a még le nem indított, a háttértérban várakozó programok közül melyek kezdjenek futni. Jellegzetességei: - ritkán fut, általában egy job befejezõdése után kell futnia, annak érdekében, hogy kiválassza a helyette futtatandõ új job-ot; - célja az erõforrások egyenletes kihasználásának biztosítása, olyam job-mix indításával, amely nem enged rá egy újabb "felhasználót" egy már erõsen igénybe vett erõforrásra; biztosítsa a CPU-határolt illetve a periféria-határolt munkák

szerencsés keveredését; - a ritka futás miatt nem kell nagyon gyorsnak lennie. Középtávú (medium term) ütemezés: Célja az idõszakos terhelés-ingadozások "kisimítása" egyes folyamatok felfüggesztésével vagy újraaktiválásával; (e lpést "hibernálás" címén már tárgyaltuk az állapot átmeneti gráf kibõvítésekor); Rövidtávú (short term) ütemezés: Ez a folyamatok szintjén mûködik, a futásra kész folyamatok közül a fut állapotba billent némelyeket. Ez igen gyakran fut, nagyon gyorsnak kell lennie Az -temezõ az OP.R magjának része, mindig a tárban van Az ütemezési algoritmusok alapötlete Észrevétel: midõn egy folyamat fut, annak CPU-használati igénye és periféria-használati igényei eymástól elválasztható munkaszakaszokra esnek: • • CPU-löket (CPU burst): a folyamatból a CPU-val egy lépésben végrehajtható "darabka": ebben a szakaszban a folyamat csak magát a processzort, meg a tár egy

részét használhatja (gondoljunk pl. az alapvetõ Assembly utasításokra, amelyek vagy csak a processzorban zajlanak, vagy esetleg a proc. regiszterei és a tár közt ígényelnek adatmozgatást). Periféria löket (I/O burst): ekkor a folyamat valami perifériával dolgozva adatátvitelt hajt végre; a modren rendszerekben e mûveleteket külön HW elemek segítik, a CPUnak normálisan ezekben nincs dolga; e mûveletek alatt egy folyamat általában sokat kényszerül várakozni. Következmény: egy folyamat "I/O burst" szakaszai alatt a CPU-t használhatja egy másik folyamat is. A CPU löketek idõtartama csak "statisztikai eszközökkel" becsülhetõ, erõsen folyamat-függõ, de az eloszlásnak van egy "éles csúcsa" a tipikus átlagos lökethossznál, s egy kis valószínûségeket takaró, "hosszan elnyúló" "farka". A fentiek szerint az "ütemezés" a folyamatok állapotátmeneti lépéseinek alkalmával

végezhetõ, azaz a a) b) c) d) e) midõn a folyamat várakozni kényszerül (mindenképp környezetváltással történik); maga a futó folyamat befejezõdik (mindenképp környezetváltással történik); a folyamat maga mond le a processzorról; a folyamattól elveszik a processzort; egy folyamat a "futásra kész állapotba kerül". szakaszokban. Az elsõ két esetben "muszáj" az ütemezõt foglalkoztatni, hiszen a tekintett folyamat "lekerül arról a listáról", amely a pillanatnyilag kiszolgálandó folyamatokat tartalmazza, így helyette mindenképp egy másik folyamat választandó be a listába. A többi esetben az ütemezés vagy inkább "átütemezés" nem okvetlenül muszáj, lehet opcionális (a folyamat a kiszolgálandók listáján marad). Egy ütemezési algoritmus lehet: • • preemptív: lehetõvé teszi, hogy az OP.R elvegye a futás jogát egy folyamattól, azt visszabillentheti a "futásra kész"

állapotba, s helyette a "futás" állapotába hozhat egy másik folyamatot; A c)-e) kategóriák ütemezhetõk ilymódon; (e módszer többnyire az idõosztásos és a valós idejû rendszereknél tipikus); nem preemptív: ez nem teszi lehetõvé, hogy az OP.R egy folyamattól elvegye a CPUt, ha az azt már egyszer megkapta; az így ütemezett folyamat csak amaga által meghatározott módon (pl. erõforrásra, eseményre várakozás, befejezõdés, vagy a CPU-ról való önkéntes lemondás) esetén mondhat le a CPU-ról; Az ütemezés általában az egyes erõforrásokhoz rendelt várakozási sorok ("wait queue") karbantartásán alapul. Ezek olyan listák, amelyek elemei folyamatokra utalnak Az ütemezés feladata e listából választani "valakit". Az ütemezõk teljesítményének tipikus összevetési szempontjai: • • • • CPU kihasználtság (CPU Utilization): Az a százalékos arány, amely megmondja, hogy az eltel idõ alatt a CPU az

idõtartam mekkora hányadában foglalatoskodott a folyamatok kiszolgálásában (a maradék idõbena CPU "henyél" --"idle"--); áteresztõ képesség (throughput): Idõegység alatt hány munkát futtat le az OP.R; körülfordulási idõ (turnaround time): egy munka mennyi idõ alatt fejezõdik be azután, hogy az a rendszerbe került; (ez a várakozási idõ és a tényleges futási idõ összege, ez utóbbit az ütemezõ algoritmus nem képes befolyásolniÖû); várakozási idõ (waiting time): Mennyi idõt tölt egy munka várakozással; (beleértendõ az állapot-átmeneti gráf "várakozó", "futásra kész", "felfüggesztett-hibernált" • állapotokban eltöltött idõk összege, s a hosszútávú ütemezés miatti "elõzetes várakozás" ideje is); válaszidõ (response time): a felhasználó lelki világának szempontjából fontos: midõn akar valamit, az OP.R kezelõi felületén keresztül kiad valami

utasítást, s ettõl számítva az elsõ, a felhasználó számára érzékelhetõ reakcióig eltelõ idõ a válaszidõ); Tipikus (ellentmondásos) gyakorlati igények az ütemezési algoritmusokkal szemben: - valami olyan "célfüggvény" optimumát találja meg, amelyet a fenti jellemzõkbõl "kotyvasztottak össze"; - korrekt mûködés: azonos módon kezeljen azonos típusú folyamatokat; - az "ésszerûség határain belül" legyen tekintettel a folyamatokhoz rendelt prioritásokra; - ha kell, akár a prioritási elõírásokat is áthágva, részesítsen elõnyben olyan folyamatokat, amelyek fontos és bõséges erõforrásokat foglalnak le, hiszen ezek miatt nagyon sok folyamat várakozni kényszerülhet, ezér jobb ezektõl minél gyorsabban megszabadulni; - egyetlen folyamatot se "éheztessen ki"; - viselkedése legyen "megjósolható", aza tegye becsülhetõvé a "maximális körülfordulási idõt", s a futtatás

költségeit; (kérdés, hogy ez mennyire lehet a terheléstõl független adat; ehhez valószínûleg az kell, hogy a rendszer el is tudjon utasítani bizonyos "rendeléseket"); - minimalizálja a rezsi idõt, azaz azt az idõt, amit az ütemezési algoritmus maga tölt el (vigyázat, ennek "preferálása" öngól lehet: kis többletidõ ráfordítás egy értelmesebb ütemezésre gazdagon megtérülhet a rendszerteljesítmény egészének javulásával); - ha lehet, részesítse elõnyben azokat a folyamatokat, amelyek az éppen kihasználatlan erõforrásokat igénylik (real-time rendszerekben ez nem mindig tehetõ meg, azt kell elõbb kiszolgálni, ami jellegébõl adódóan a legsürgõsebb); - "graceful degradation": a terhelés növekedése ne okozzon "összeomlást" a endszer mûködéséban, hanem "alattomosan, alig észlelhetõen, folyamatosan" rontsa le annak összteljesítményét. Ütemezési algoritmusok: Ezek közt vannak

"egyszerûek", amelyek néhány kézenfekvõ ökölszabályra támaszkodnak, és szofisztikáltak, amelyek jobban megkísérlik kielégíteni az ellentmondásos elvárásokat. Egyszerû megoldások: • "a legrégebben várakozó folyamat mielõbbi kiszolgálása" (First Come, First Served -FCFS) --nem preemptív algoritmus--: az új "bejelentkezõk", azaz a "futásra kész" mindig a kiszolgálandó lista aljára íródnak rá, míg az OP.R "felülrõl", azaz a lista tetejérõl választ futtatandó folyamatot, azaz fogyasztja a listát. elõnye: egyszerûen megvalósítható; hátránya: a folyamatok átlagos várakozási ideje elég nagy lehet, ha a listán van olyan folyamat, amely hosszú átlagos CPU löketeket használ: "konvoly hatás": pl. olyan határátkelõ, ahol egy csatornán lehet csak átjutni, s nem külön vámolják a kamionokat és a gépkocsikat, hanem szigorúan érkezési sorrendben); • körbeforgó

ütemezés (Round-Robin, RR) --preemptív algoritmus--, az idõosztásos rendszerek alap-algoritmusa: Futtatása kezdetén valamennyi folyamat kap egy számára kijelölt "idõszeletet --time slice--"; ezzel a következõk történhetnek: ha afolyamat eegy adott "CPU-lökete" belefér ebbe az idõszeletbe, a maradék idõt nincs értelme "kivárni": a löket végén érdemes újraütemezni a folyamatokat, s újra indítani a folyamat idõszeletét; ha a CPU löket nem fér bele a rendelkezésre álló idõszeletbe, a szelet végén az OP.R elveszi a processzort a folyamattól, visszabillenti azt a "futásra kész" állapotba, s az bekerül a várólista aljára; jellemzõi: Nehéz megtalálni az alkalmas "idõszelet méretet"; ha 〈 CPU-löket〉 << idõszelet, ez gyakorlatilag azonos az FCFS algoritmussal, hiszen statisztikailag elenyészõek azok az esetek, amikor a CPU-t "löket közben" kell elvenni a

folyamattól; ha 〈 CPU-löket〉 >> idõszelet, ez azzal jár, hogy szinte valamennyi folyamat CPU löketei megszakíttatnak, mindegyikük azonos hosszú idõszeleteket kap; a megszakítások miatti gyakori adatmentések (nagy környezetváltási gyakoriság) nagyon leronthatja a rendszer hasznos teljesítményét; elõnyei akkor domborodnak ki, ha valamennyi folyamathoz (statisztikai megfigyelések alapján) alkalmas méretû idõszeletet tud kiosztani; Gyakorlati "ökölszabály": jó a mûködés, ha idõszelet>a CPU l0ketek 80%-a, ekkor a löketek nagy része lefut a proceszor elvétele nélkül. Prioritásokat (priority) is figyelembe vevõ algoritmusok: Ezek valamilyen szám-hozzárendeléssel valamennyi folyamathoz "prioritás értéket" rendelnek. A "futásra kész" folyamatok közül a legnagyobb prioritású fog a "futás" állapotába kerülni. A folyamatok prioritását meghatározhatja: • • maga az OP.R (ún belsõ

prioritás), vagy valamilyen külsõ folyamat, amelyre az OP.R-nek nincs ráhatása (külsõ prioritás) Továbbá egy folyamat lehet • • statikus prioritású, azaz prioritása állandó éerték egész furtása alatt, vagy dinamikus prioritású, azaz a futása idõszaka alatt változó prioritású. Általában valamennyi prioritásos algoritmus kiéhezhet. Ennek elkerüélése érdekében az OPR "öregítheti" a folyamatokat, azaz prioritásukat az idõ múlásával folyamatosan emelheti (aging). A prioritásokat sok tényezõ befolyásolhatja. Az itt példának tekintett módszerek esetén a prioritást a várakozó folyamat CPU-löket-idõ szükséglete szabja meg: 1.) "A legrövidebb löketidejû fusson elõször" (Shortest Job First, SJF): Ez nem engedi meg a folyamattól a processzor elvételét (nem preemptív): a "futásra kész" állapotú folyamatok közül elõször a legrövidebb löketidejût indítja el, s kivárja ennek a

löketnek a végét a CPU közbeni elvétele nélkül. Jellemzõi: • A "First Come, First Served" algoritmust meghaladja abban, hogy itt nem alakul ki konvolyhatás: a gyorsan futó folyamatok elõre kerülnek, a lassúak a vége felé "helmozódnak"; • Bizonyítható, hogy vele a folyamatok átlagos várakozási ideje és a körülfordulási idõ optimális. 2.) "A legrövidebb hátralévõ löketidejû fusson elõbb" (Shortest Remaining Time First -SRTF): Az elõzõ módszer tovább fejlesztett preemtív változta: amint egy újabb folyamat kerül a "futásra kész" állapotba, az OP.R megnézi az éppen futó, valamint a "futásra kész" listán várakozó folyamatok hátralévõ löketidejét, s azt futtatja tovább, emlyikre nézve ez a legrövidebb. • • alkalmazása elõnyös lehet, mivel méginkább segítheti a várakozó folyamatok közül a leggyorsabban lefuttathatóak "preferált" kiválasztását,

alkalamzása nem okvetlenül biztosan térül meg: az épp, futó folyamat megszakítása jelentõs idõszükséglettel is bírhat a környezetváltáshoz tartozó mentési munkák miatt. 3.) "A legjobb válaszarányú folyamat fusson elõbb" (Highest Response Ratio -- HRR): Ez megint a Shortest Job First megoldás egy olyan változata, amely "öregíti a folyamatokat": ResponseRatio:= (löketidõ+k*várakozási idõ)/löketidõ. ahol "k" egy alkalmas konstans. Mindhárom fenti esetben kruciális kérdés, honnan lehet tudni egy adott folyamat következõ lépésben szükséges löketidejét? • • a folyamatot elindító felhasználó "deklarációja " alapján, vagy az oprendszer a folyamat futása közben karbantarthat egy statisztikát a egyes igényelt löketidõk figyelembevételével, s abból extrapolálhat. Többszintû algoritmusok: A futásra kész folyamatok nem egyetlen "homogén" sorban, hanem e sor "rétegekre

osztott" szintjein helyezkedjenek el. Mindegyik "réteghez" tartozik egy prioritás • • A kisebb prioritású rétegben várakozók közül csak akkor indulhet el fiolyamat, ha az összes magasabb prioritású téteg már "kiürült"; Az egyes rétegeken belül különbözõ kiválasztási algoritmusok alkalmazhatók. Példa különbözõ lehetséges rétegekre: • • • • a rendszerfolyamatok rétege; interaktív folyamatok rétege, kötegelt feldolgozású folyamatok rétege, rendszerstatisztikákat gyújtõ folyamatok. Variánsai: Statikus többszintû sosrok módszrere (Static Multilevel Queues): a folyamatok indulásokkor besorolódnak egy rétegbe, s további életükben végig abban maradnak. • Visszacsatolt többszintû sorok (Multilevel Feedback Queues): futásuk közben a folyamatok átkerülhetnek egy másik prioritású sorba - csökkenõ prioritásba kerülõ folyamatok módszre: A folyamatok mindig a legmagasabb prioritású

rétegben kezdenek élni; a rétegekhez csökkenõ prioritással növekvõ idõszlet tatozik; amennyiben az adott folyamatnak nem elegendõ a rendelkezésre álló idõszelet, azt le lehet fokozni egy kisebb prioritású sorba való besorolással. Veszélye: ha ezt mereven alklamazzuk, a folyamat prioritása --ahogy egyre hosszabb idejú CPU löketek jelennek meg benne--, folyamatosan csökken; - célszerû lehet e monoton lefokozódást megállítani, úgy, hogy egyes folyamatok egy alacsonyabb prioritású sorból magasabba is kerülhessenek: pl. az átlagos löketidõ monitorozása alapján idõnként átrendezni a sorokat, illetve - lehetõvé tenni az öregítést a már nagyon régóta váró folyamatok részére. • Többprocesszoros ütemezés: Ebben az esetben nem egy darab, hanem több processzor közt lehet elosztani a folyamatokat (heterogén rendszer esetén a lehetséges kiosztást korlátozza, hogy az adott folyamat melyik processzor gépi kódjában lett

megírva/gépi kódjára lett fordítva. Homogén rendszerekben a futásra kész folyamatok közös sorokban tárolandók. Szimmetrikus multiprocesszoros rendszerek: Valamennyi processzor saját ütemezõt futtat, ez a közös sorokból választ --a kölcsönös kizárás biztosításával. Aszimmetrikus multiprocesszoros rendszerek: ezekben az egyik processzor szerepe kiemelt, ez futtatja az ütemezõ algoritmust, azaz osztja szét a folyamatokat a többi processzor között. Értékelési módszerek az ütemezõ algoritmusokra: • • • Analitikus értékelés: - determinisztikus modelezés esetén: az algoritmust elõre elkészített számokkal jellemezzük (folyamatok száma, egymást követõ löketek hossza) limitált módszer - stochasztikus modellezés -- sorbanállások elmélete (queuing theory) Szimuláció: - számítógépes modell dolgozható ki az ütemezési algoritmusokra, s ez vizsgálahtó fiktív teszteken szimulációval. Tényleges implementálás, a

valóság mérése alapján. Tár- (memória-) kezelés Az általában használt tár típusok: Cache AzOP.R-tõl független Tisztahardver kapcsolat Operatívmemória AzOP.R szabályozza Háttértár A modern számítógépektártípusai (cahhe=gyorsítótár) Az aktuális (azaz végrehajtandó) kód és annak operanduszai vagy az operatív memóriában, vagy a gyorsító tárban kell legyenek. (A cache-hez való hozzáférés igen gyors, de kpacitása általában kicsi.) A tárgazdálkodás megkövetelei, hogy a programozó által írt forrásnyelvû programból végül konkrét memóriahelyeket lefoglaló végrehajtható kód legyen. E konkrét memóriacímek az alábbi lépésekben keletkezhetnek: Forrásnyelvûprogram Compiler - Fordító Máshonnaneredõ, használt tárgykódok Tárgykód(OBJ). Linker -- Kapcsolat szerkesztõ Rendszerkönyvtárak Betölthetõkód Dinamikusanbetölthetõ könyvtárak Betöltõ Konkrét memóriakiosztás A konkrét memóriakiosztás

megvalósulásának fázisai A forrásnyelvû program írója egy egyszeresen összefüggõ ún. logikai memóriatartományban gondolkodhat, amely végül leképezõdik egy valóságos memóriatartományra. • • • • Fordítás közbeni címkiosztás (compile time): ez a merev fizikai címkiosztás csak akkor végleges, ha ez az egyetlen tárgykód van.; általában a ROM-ba kerülõ programokra használják. Linkelés közben (link time): a linkernek össze kell rendeznie a különbözõ modulok tárgykódjait, s összhengba kell hoznia azok egymásra való hívatkozását konkrét fizikai címek szerint. Betöltés közben (load time): A fenti lépésekben létrehozott címeket módosítani kell az aktuális lehetõségek szerint (áthelyezhetõ kódok --relocatable code ideája: egy báziscímhez képesti offset értékekben való gondolkodás, a bázis aztán valami bázisregiszter tratalma szerint tologatható a valóságos címben) . Futás közben (run time): Bizonyos

logikai címek maradnak még, amelyek csak futás közben, közvetlen végrehajtás elõtt konkretizálhatók fizikailag. A fenti rendszerben az elsõ két lehetõség statikus megoldás. Tártakarékosság céljából vezettéák be a dinamikus megoldásokat: nem az egész program kerül egyszerre a tárba, hanem annak egyes részei csak akoor töltõdnek be, amikor tényleg szükség lesz rájuk, futás közben. • • • Dinamikus betöltés (Dynamic Loading): Az éppen nem használt programrészek a háttértárban áthelyezhetõ kód formában ülnek. Egy speciális programrészlet gondoskodik eról, hogy a kellõ darabok szükség esetén be legyenek töltve. (Ilyen részek lehetnek a ritkán használt részek, például a hibaüzeneteket kiadó, kezelõ részek.) Az egész rendszer megszervezése kizárólag a programozó dolga, az OPR ehhez semmiféle speciális támogatást nem ad. Dinamikusan betöltött könyvtárak (Dynamic Linking): Az elõbbi módszer

intelligensebb, továbbfejlesztett változata, amelyet már az OP.R támogat: linkeléskor eredetileg nem másolódnak be a könyvtárakból teljes részletek, hanem csak azokra hivatkozó csonkok (stubs). A hívatkozott rész a tárba futás közben kerül be akkor, amikor arrra elõször van szükség, s a továbbiakban már benne is marad (a késõbbi hívatkozások már nem szenvedik el a betöltés okozta idõveszteséget). Fejlesztési elõnye, hogy egy adott könyvtári részben elõforduló hibák csak ezt a részt érintik, nem kell miattuk újra fordítani az egész programot. Átfedõ programrészek: (Ovrlays): A program úgy van megszervezve, hogy a tárban egyszerre csak egy aktív programrész dolgozik, meg olyan átfedési területek vanak benne, amelyekre több programrész hivatkozik. Az ettõl eltérõ adat- és programrészek egyesével tölthetõk be. Ezt a programozó tudja így szervezni, az OPR részérõl ez amódszer semmiféle speciális támogatást nem

igényel. (Pl a C compiler erre tartalmaz utasításokat). Társzervezési elvek: A tár felosztása: partíciós rendszerek. Egy partíciós rendszer (a multiprogramozás elõtti idõkbõl származik): • A speciális tárterület által lefoglalt részeken kívül (pl. interrupt vektorok helye, speciális periféria címtartományok, az OP.R által használt részek) kívül van egy folytonos címtartomány, amelyet a program használhat. A betöltõ progranm ilyenkor az elsõ szabad címtõl kezdõdõen írja be a programot. • Ha az OP.R tárigénye futás közben megnõ, a partíció szabad részeirõl --a tár másik végérõl-- próbálhat "lopni" magának memóriát, vagy az egész futó programot "át kell helyeznie" (ez utóbi általában HW támogatás esetén lesz eléggé gyors). • Az OP.R saját területeit egy regiszter tartalmával védheti, ami a legkisebb programcímet tartalmazza. A programnak nem engedi meg, hogy az alá címezzen

Rendszerhíváskor (trap) az OP.R kerül múködésbe, õ akárhová címezhet, ránézve ez a korlátozás kikapcsolódik. Több partíciós rendszer (a multiprogramozás igénye hozta létre): • Kezdetben merev partícionálást használtak, ezek határa futás közben nem változhatott (rögzített partíciók): A partíciók mérete azonban nem volt okvetlenül azonos, azt különbözõ hipotetikusprogramok igényeihez szabták többé-kevésbé: a tárkihasználás mértéke rossz volt, minden partícióban maradtak "ráhagyások", azaz az adott partícióba dugott program által ki nem használt részek ("belsõ tártöredezés -- internal fragmentation"); • • Késõbb megjelent a folyamatok igényeihez szabott változó méretû partícionálás. Ez mentes volt a belsõ töredezettségtõl, de a folyamatok kihaltával a nekik kiosztott tárrészek sajtlyuk szerûen szbadultak fel ("külsõ töredezettség -- external fragmentation"). Ez

végül is rontja a memóriakihasználást, s a kelõ méretû összefüggõ tartományok eltûntével lehetelenné teheti újabb folyamatok elindítását. Gyógyszer: A szabad terület tömörítése (garbage collection, compaction): ez a szabad részeknek a tár egyik végére való rendezést igényli: - idõigényes, nem biztos, hogy érdemes futtatni, lehet, hogy érdemesebb egyéb folyamatok kihaltát is kivárni. - futtatásuk szükségessége nem számítható ki elõre: az interaktív rendszerek válaszidejében ezért hirtelen romlást okoznak - a betöltéskor adott áthelyezési információkkal összhangban kell maradni. Praktikus lehetõségek betöltés közbeni tárterület lefoglalásra: • A legjobban megfelelõ tár kiválasztása (best fit): a legkisebb, de még elegendõ méret lefoglalása; • Az elsõ megfelelõ méretû terület lefoglalása (first fit): a tár elejérõl indulva megállunk az elsõ partíciónál, amelybe a betölteni kívánt programrész

befér. • A következõ megfelelõ (next fit) stratégia: a keresés az utoljára lefoglalt tartomány végétõl indul, s az innen számított elsõ megfelelõ területet foglalja le. • A legrosszabban illeszkedõ rész kiválasztása (worst fi): a legnagyobb szabad darabból foglaljuk le azt, ami kell, abban bízva, hogy még elég nagy darab marad belõle a következõ folyamat számára. • Védelem multiprogramozásnál: itt nemcsak az OP.R védendõ a folyamatoktól, hanem a folyamatok is vbédendõk egymástól: ehhez 2 regiszter kell: ezek az éppen a proc. által futtatott folyamat alsó és felsõ címhatárát tartalmazzák A tartományból való kicímzést HW figyeli. A szimulációs tapasztalatok szerint az elsõ három algoritmus közel azonos hatékonyságú (a lefoglalt területek összegének fele kihasználatlan --50%-os szabály--), az utóbbi határozottan gyengébb. Tárcsere (swap) módszere: Az OP.R ilyenkor egy folyamat teljes tárterületét diszkre

másolja, felszabadítva az operatív memóriát más folyamatok számára. Ez speciális hardver támogatás mellet is igen idõigényes, sokkal több adatot kell menteni, mint egy közönséges környezetváltásnál. Megfontolandó szempontok: • mikor és kit érdemes a háttértárba kitenni (prioritások)? • mikor és kit érdemes onnan az operatív tárba bevinni (kiéheztetés)? • kerülni kell a fölösleges tárcsere mûveleteket. Társzervezési lehetõségek: • mesterséges folytonosság: lehetõség van arra, hogy a virtuális tartományban folytonos címtartomány a valóságban ne legyen az. • ma már lehetséges az, hogy az éppen futó folyamatnak ne az egésze, hanem csak egy része legyen az operatív tárban, a másik része a háttértárban legyen; • a futás közben címleképezéseket kell csinálni, ezt érdemes úgy szervezni, hogy összefüggõ tartomány összefüggõ tartományra képezõdjék (blokk elv); ez csak HW • támogatással

elviselhetõen gyors. A címek ekkor <blokkcím, dispalement> alakúak lesznek, a transzformáció a blokkok leképezést jelenti (blokktábla -- block map). A valós címtartomány el kell különüljön az eltérõ folyamatokra, a virtuális címtartományban viszont lehetnek átfedések: --> valamennyi folyamat más-más blokktáblát használ a címtranszformációhoz. A társzervezés három módszren alapulhat: szegmens-szervezés, lapszervezés, illetve ezek kombinációja. A szegmensszervezés módszere: Szegmensek: önmagukban folytonos blokkok. A program memóriája a logikai címtatományban sem egyetlen egybefüggõ terület, hanem szegmensek halmaza. Blokkok lehetnek: • • pl. Code, Stack, Data standard szegmensek a programozásban, nagyobb tömbök tárolására szolgáló memória részek. Szegmensvédelem a címtranszformáció esetében: • • • Biztosítani kell, hogy egyetlen szegmensbõl se tudjon a folyamat "kicímezni". A

szegmenseket egy "szegmenstábla" tartja nyilván az egyes szegmensek hosszát. A hardver feladata a szegmens területérõl való kicímzést figyelni, s hiba esetén megszakítást indítani "segment overflow fault" címmel. Ellenõrizni kell, hogy mely folyamatok mely szegmensekhez férhessenek hozzá (protection control). Ennek érdekében valamennyi folyamatnak szegmens hozzáférési jogok adhatók. Tipikus hozzáférési jogok: - olvasási jog (read access) - írási jog (write access) - végrehajtási jog (execute access): olyan szegmensekhez, amelyek a processzor által végrehajtható utasításokat tartalmaznak, a folyamat azokat végrehajthatja (utasításelõvétel, fetch) A hozzáférési jogok betartását a HW ellenõrzi, a sértés itt is azonal megszakítást kell okozzon (segment protection fault) címmel. Osztott szegmenshasználat (segment sharing): ebben az esetben több folyamat közös, fizikailag azonos tárterületet használ. Ez elõnyös

lehet, ha - több folyamat közös utasításokat használ, pl. azonos programokat futtat (pl teljes programokat vagy rendszerkönyvtárakat lehet így kezelni, helytakarékosan). - A folyamatok használhatnak közös adatterületet is, amelynek segítségével az OP.R megkerülésével is kommunikálhatnak egymással, tipikusan az egymással szülõ-gyermek viszonyban álló folyamatokra elõnyös mindez, a szülõ adataihoz a gyermek hozzáférhet. (Egyébként lehet kommunikálni az OPR területein keresztül a standard módokon). Ebben a módszerben - ugyanazt a szegmenst a folyamatok különbözõ típusú jogosultság mellett is használhatják, - a megfelelõ átfedéseknek a szegmenstábléákban kell megjelenniük, - az írási folyamatok idejére biztosítani kell a "kölcsönös kizárást", ezt a hardver nem támogatja, ez programozási feladat. • Multiprogramozott rendszerekben egy futó folyamat nem minden szegmense van az operatív tárban. Egy részük

lehet a háttértárban a virtuális memóriában Erre az esetre a szegmens táblának minden szegmens mellett kell tartalmaznia - egy "residency bit"-et, amely megmondja, hogy az adott szegmens az elektronikus tárban van-e éppen, vagy a háttértérban, - valamint helyet annak az információnak, hogy a háttértárban hol heleyzkedik el a szegmens, amennyiben az oda szorult ki. Ha kiszorult blokkra való hívatkozás történik, akkor a tárkezelõ hardver dolga egy "missing segment fault" jellegû megszakítás generálása. A megszakítás kezelése teljes mértékben az OP.R dolga Lapszervezés: a • külsõ töredezés elkerülhetõ, ha azonos méretû blokkok (page, lap) szervezõdnek; • a belsõ töredezés nem kerülhetõ el, de káros hatása annál kisebb, minél kisebbek a lapok (az esetleg fel nem használt maradékuk így elég kicsi lesz, szintén). A lapméret praktikusan mindig 2 hatványa lehet. • Címtranszformációs lehetõségek: Ezzel

a módszerrel a lapon belül nem kell külön "displacement"-tel foglalkozni, a lapon belüli címek a kettes számrendszerben adott kisebb helyiértékû bitek lehetnek. Lehetõségek: - közvetlen leképezés: a folyamathoz tartozó valamennyi lap fizikai címét tárolni kell egy laptérkép táblában, s a fizikai címek mindig innen nézhetõk ki (kis méretû lapok esetében sok ilyen bejegyzés van a laptérkép táblában, ezért az nagy méretû lesz, nem tartható speciális, gyors hozzáférésû memóriában: lassulás) - asszociatív leképezés: Speciális szervezésû gyors asszociatív tár, amely a logikai és a fizikai címeket egymáshoz aszociálva tartalmazza: bemenete a logikai cím, kimenete a hozzá tartozó fizikai cím. Hátránya: az asszociatív tár magas ára. - kombinált közvetlen és asszociatív leképezés: az információ egy része a speciális asszociatív tárban, az onnan kiszorulók a direkt tárban vannak, a keresés mindig az

asszociatív tárban kezdõdik, a direkt tárba csak akkor megy át, ha a másiikban nem találtatott meg a kersett információ. Mivel a folyamatoknek egyszerre általában egy kisebb része (darabja) fut, az asszociatív tár sokat segíthet ebben is. Védelmi szükséglet lapszervezés esetében: • A lapból való kicímzés eleve nem fordulhat elõ az alacsonyabb bitek filozófiája miatt, erre nem kell külön védelem; • a kis méretû lapokból sok van, emiatt a hozzáférések ellenõrzése extrém nagy addicionális memóriát igényelne, emiatt errõl általában lemondanak. • Az osztott laphasználat megengedése célszerû, de kerülni kell, hogy az osztottan használt lapokon maradjanak nem osztottan használt részek. • A háttértárba szorult lap címzésével hasonló módon kell eljárni, mint a háttértárba szorult blokkok címzésével. Itt a lapok nyilvántarását a "residency bit" megfelelõjekébnt szolgáló "valid, érvényes"

bittel, illetve a háttértárban való elhelyezkedési információval kell kiegészíteni. Kombinált szegmens és lapszervezés: A két fenti technika elõnyeit egyesíti: • • • • • a szegmenseket lapokra lehet tördelni., a tárban nem kell az egész szegmensnek bent ülnie, hanem csak az éppen használt lapjának; elkerüli a külsõ tördelõdést; a szegmens szervezés megtartása miatt a folyamat logikai társzervezése átláthatóbb marad, az osztott használat nyilvántartási igénye kisebb, mint lapszervezésnél, az osztott használat eleve egyszerûbb, így megvalósítható a hozzáférési jogok rendszere is a szegmensekre kidolgozott módon. A címtranszformáció szempontjából a logikai cím három részre oszlik: szegmenscím, lapcím, lapon belüli eltolás. A szegmenscím most a szegmenshez tartozó laptábal kezdõcíme, a fizikai cím a lapszervezési módszerekkel számítható. A hozzáférési jogok ellenõrzése (osztott laphasználat

esetén) a szegmens-szervezésnek megfelelõen történik. A virtuális tár kezelése Ennek feladata biztosítani, hogy • a rendszer folyamatai logikai címtartományának csak egy része legyen a központi tárban (amely rész épp a folyamat futásához az adott pillanatban szükséges), • a folyamatok többi része a "virtuális tárban" legyen, de úgy, hogy • a központi tárban lévõ folyamatrész mkorlátozás nélkül hívatkozhasson a virtuális tárban lévõ folyamatrészekre is. Ezt szervezési elvek és algoritmusok alkalmazásával lehet elérni. 9.1 A virtuális tárkezelés szervezési elvei: Mi teszi lehetõvé vagy értelmessé a virtuális társzervezést? A programok alig használják ki a teljes címtartományukat, mert - vannak ritkán szükséges küdrészek (pl. hibakezelés); - a statikus adatszerkezetek (pl. egy szokványos programban jó elõre deklarált tömb, amit csak pl. a programfutás végén kezdenénk az eredménnyel

feltölteni) sokszor a futásidõ nagy része alatt ténylergesen nincsene k kihasználva; - a program futásához egyidõben nem kell az összes részlet (ezt használta ki az egyszerûbb DOS-os világban az overlay technika is); • • Ha nincs a tárban egyszerre az egész program, egyrészt nagyobb programok is futtathatók, mint az egész tár, másrészt a multiprogramozás mértéke növelhetõ; Ha eleve a folyamatoknak csak kis része van a tárban, a háttértérba mentéssel járó adatátvitel eleve kevesebb lesz (a többi rész amúgy is a háttértérban van); A megvalõsítás módszere: Midõn egy folyamat olyan címre hívatkozik, amely nincs benne a tárban, keletkezik egy megszakítás, amelyet az operációs rendszer kezel, s amelynek lényege, hogy a háttértárból a valódi tárba viszi a hivatkozott blokkot. Ilyenkor a következõk történnek: - Az megszakításokatt kiszolgáló kódrészlet kapja meg a vezérlést az OP.R részérõl; * elmenti a

folyamat környezetét; * elmegy a megfelelõ kiszolgáló rutinra; * ellenõrzi, hogy a megszakítás oka nem programhiba-e; - Behozza a kívánt blokkot a tárba: * helyet keres számára a tárban; ha nincs erre szabad hely, valamilyen másik folyamatrészt visz ki a háttértárba; * behozza a kívánt blokkot a központi tárba; - Mivel ezek "lassú" perifériás mûveletek (fõleg ha még helyet is fel kell szabadítania), hiszen: + meg kell várni., amíg a perifériás eszköz felszbadul; + ki kell várnia a diszken szükséges fejmozgásokat ahhoz, hogy az általa kívánt mûvelet egyáltalán elkezdõdhessen; + ténylegesen végre kell hajtania a blokk átvitelét a tár és a periféria között; a megszakított folyamatot érdemes "várakozó" állapotba helyezni, s helyette egy másik folyamatot elindítani, majd a blokk átvitele után az igénylõ folyamatot "futásra kész" állapotba billenteni; - majd amikor a mgeszakított folyamat

újra futási jogot kap, újra végre kell hajtani a megkezedett utasítást. • Hardver feltételek: a hardvernek úgy kell mûködnie, hogy a nem érvényes címre való hívatkozás eleve megszakítást okozzon; - biztosítania kell, hogy a megszakított utsaítást újra lehessen indítani (ez lehet nagyon bonyolult, tkintettel arra, hogy megszakíthatunk olyan utasítást, amely eleve több címet használ, pl. blokkokat mozgat, vagy automatikus címnöveléssel/címcsökkentéssel címez); címez; - A hardver ezen felül támogathatja a lapcsere algoritmusait pjl. blokkokhoz rendelt jezõbitekkel, amelyeket minden tárhoz-fordulási esetben kezel. A modern hardverek eleve lapszervezésûek vagy kombinált szervezésûek, emiatt a virtuális tár kezelése többnyire lapok mozgatásával megoldható (egytelen ismert kivétel az OS/2 I80286 processzoron), ezért praktikusan elegendõ a lapszervezésû rendszerekkel foglalkozni. • A virtuális tár használatának hatása

a folyamatok futási sebességére: a folyamatok futási sebességét eredendõen a tárhoz való hozzáférés ideje határozza meg: [effektív hozzáférési idõ]=(1-p)x(valós hozzáférési idõ)+px(laphiba idõ). Itt "p" a laphiba gyakorisága vagy inkább valószínõsége. A valós hozzáférési idõ lehet 100 ns, míg a laphiba ezelése akár 50-100 ms idõt is igénybe vehet. Emiatt p-nek 10-8 10-7 nagyságrendûnek kell lennie ahhoz, hogy a folyamat ne lassuljo le elviselhetetlen mértékben; • Eldöntendõ (stratégiai) kérdések a virtuális tár használatának megvalósításakor: hogyan keresse meg a betöltendõ blokk-lapot (fetch strategy); hogyan helyezze el a valódi tárban a betültendõ blokko (placement strategy); ez lapszervezés esetén nem gond, ha szegmenseket kell mozgatni, a választás nem triviális, valamelyik stratégiát kell alkalmazni a "multipartíciós valós tárkezelési stratégiák" közül; ha nincs szbad blokk,

valamelyiket le kell cserélni a behozottal (replacement strategy); a fizikai tár használatát hogy oldjuk meg gazdaságosan, aza melyik folyamat számára hány lapot biztosítsunk a tárban? 9.2 Hogyan legyen kiválasztva a betöltendõ lap? Az "igény szerinti lapozás elve (Demand Paging)": Csak azt a lapot hozzuk be, amelyree hivatkozás történt a laphibánál; ez egyszerû, nem igényel "további gondokodást"; garantáltan nem hoz be fölösleges lapot; • • Az "elõretekintõ lapozás elve (Anticipatory Paging):" az OP.R megkísérli megbecsülni, hogy a jövõben mely lapokra lehet szüksége, s azokat a lapcseréhez hasznáélt háttértár "szabd idejében", lehetõleg egyszerre, betölti az elektronikus tárba; ezzel redukálódhat a háttértárban ülõ folyamatrészekre való hivatkozások, s az ezekkel járó hercehurcák száma. pontos és gyors becslés esetén jelentõsen növelheti a futási sebességet; -

hibás becslés vagy jóslás esetén fölösleges lapok fogják lefoglalni a tár egy részét; ennek jelentõsége a memória árcsökkenésével egyre kisebb, így egyre inkább érdemes alaklamazni az "elõretekintõ lapozás módszerét." 9.3 Lapcsere stratégiák (replacement strategies) Optimális esetben azt a lapot lehetne "kinyomni a háttértérba", amelyikre a legtovább nem lesz szükség. Ezt természetesen nem lehet elõre ismerni, ehelyet "ökölmódszerek" vannak: • "Véletlen kiválasztás": véletlenszerû döntés, nagyon primitív, egyszerû, de a gyakorlatban nem használják, inkább csak elvi lehetõség; • "A legrégebbi lap kiválasztása (FIFO)": ez megvalósítható egy egyszerû lista karbantartásával, de nem túl hatékony: több folyamat is gyakran használhat a valódi tárban huzamosabb ideje bentlévõ lapot, amelynek változatlanul bent kellene maradnia, de ki lesz dobva csupán azért, mert

már régóta bent van, így hamarosan újra be kell majd hozni; megfigyelt jelenség a "FIFO anomália" annak a várakozásnak ellenére, amely szerint a folyamatokhoz tartozó lapok számának növelése a laphibák csökkenését eredményezi, a tapasztalat szerint járhat ez a laphibák számának növekedésével is bizonyos esetekben; • A "Legrégeben nem használt (Least Recently Used, LRU)" lap kidobása a háttértárba; Ez a közelmúlt tapasztalatainak extrapolációja a közeljövõre, általában jó eredményt ad, de megvalósítása nehéz, két alap-változata van számlálóval való megvalósítás: az adott lapra való hívatkozáskor feljegyezzük egy számláló állását (ez azonosítható a hivatkozás idõpontjával), s választáskor a legkisebb számláló-értéket (a legkorábbi idõpontot) keressük egy ilyen listában; láncolt listával: e megoldásban a lapok egy láncolt listába vannak felfûzve; egy hívatkozáskor az új lapot

a lista aljára tesszük, illteve ha már rajta van a listán, a korábbi helyérõl kivesszük és letesszük a lista aljára; ilyenkor a lista tetején álló lap a legrégebben hivatkozott lap. Mindkét megoldás meglepõen bonyolul hardver támogatást igényelne, inkább szimálációs eredmények léteznek rájuk. Referencia-bitet (Reference Bit) igénylõ megoldások: ezek a tárkezelõ hardvertõl igénylik, hogy minden laphoz tartozzon benne egy bit, amely azt jelzi, hogy hivatkoztak-e már a lap akármelyik címére. •• Az "Újabb esély (Second Chance)" algoritmus: a FIFO javított változata: a lista tetején lévõ lapot csak akkor tolja a háttértárba, ha arra a referenecia-bit szerint még nem történt hívatkozás. Egyébként leteszi azt a lista aljára, s referencia-bitet átallítja Ezzel törli a hívtakozás emlékét, s az adott lap csak akkor nyomódik ki a háttértérba, ha a lista elejére csúszik annélkül, hogy közben hivatkoztak volna

rá; ezzel ki lehet kerülni, hogy a viszonylag gyakran használt lapok kikerüljenek az elektronikus tárból; •• Az "Legkevésbé használt lap (Least Frequently used, LFU)" kiválasztása: ez garantálja, hogy a legygyakrabban használt lapok --lehetsõség szerint-- a memóriában maradjanak. Megvalósítása: A hivatkozási bitek figyelésével és "visszanullázásával" az idõintervallumonkénti laphasználatkoat tudja statisztikailag begyûjteni (pl. valamennyi laphoz rendelhet egy számlálót, s annak tartalmát növeli, ha az adott lapra történt hivatkozás az adott idõintervallumban); Gyengéi: - a valaha sokat használt lapok, amelyekhez jó ideje nem nyúlt a rendszer, csak "lassan kopnak ki" a listából, túl sokáig bentmaradhatnak; • - a frissen betöltött lapok csak nehezen tudnak "stabilizálódni" a listán, egy frissen betöltött lap hamarosan újra kikerülhet az elektronikus tárból. •• A

"Mostanában nem használt (Not Used Recently)" lap kirakása: Ez a referencia-bit-en kívül (ami csak a lap használatára ad felvilágosítást) egy újabb biten (Modified vagy Dirty Bit) azt is nyilvántartja, hogy az adottt lap tartalma változott-e a legutóbbi betöltés óta (pl. ha az adott lapon adatok vannak, vagy verem, ez megeshet igen könnyen); Ha egy változatlan lapot akarunk "lecserélni", azt fölösleges visszaírni a hattértárba, hiszen ugyanolyan állapotában úgyis rjta van már. Ez az algoritmus: - idõnként az összes lap "referencia bit"-jét törli azon megfontolásból, hogy hosszú idõ alatt elõbb-utóbb úgyis minden lapra sor kerül egyszer (ez ad értelmet a 2. kategóriának alább); - a "referencia bit" és a modified bit" tartalma alapján a lapokat különbözõ prioritású osztályokba rendezi, úgymint 1. nem hivatkozott, nem módosult; 2. nem hivatkozott, módosult; 3. hivatkozott, nem módosult;

4. hivatkozott, módosult - a háttérbe írandó lapot a legkisebb prioritású kategória tagjai közül véletlenszerûen választja ki a módszer. A fenti módszerek kombinálhatók "Szabad lapok fenntartásával" operáló módszerekkel. Ezek lényege: lehetõség szerint igyekeznek elkerülni vagy elodázni a lecserélendõ lapok tényleges háttértárba írását. Ezek az alábbiak lehetnek: - Ha a fenti algoritmusok valamelyikével lecserélésre kijelölt lap módosult, az igénylõ folyamat azonnal kap egy szabad lapot, a lecserélt lap kiírása után pedig "felszabadul"; - a lecserélendõ lapok kiírása akkor történik meg, amikor az arra szolgáló eszközt épp senki nem akarja használni, azaz az "henyél" v. "idle"; - további lehetõség, ha fenntaratunk egy speciális laphalmazt, amelyek között "szabad" ill. módosult lapok lehetnek; ha van benne szabad lap, a háttértárból behozandó lapok számára ezeket

allokáljuk; a módosult lapokat csak akkor írjuk ki, ha a helyükre ténylegesen szükség van; Ha egy korábban lecserélt lap még nem került bele a hattértárba, ebbõl a halmazból is kivehetõ diszkmúveletek nélkül is. 9.4 A folyamatok lapigényének jellemzõi A fent említett algoritmusok hatásfoka limitált abban az értelemben, hogy látókörükbe csak nem fért bele globális lapgazdálkodás: az egyes folyamatok számára történõ lap-allokálás cizelláltabb módját nem vizsgálták, csak azt, mikápp érdemes eljárni, ha a háttértárba kitett lapok valamelyikére történik hivatkozás. A lapkiosztás hatékonysága nyilvánvalóan növelhetõ lehet globális lapgazdálkodás bevezetésével, amely az egyes folyamatok lap-igényét statisztikai módszerekkel igyekszik "megfogni", hasonló módon ahhoz, ahogyan pl. a CPU löketek statisztika elemzése is javíthatott a CPU ütemezés hatékonyságán. Ez az alábbi kompromisszumokat veszi

figyelembe: • • Az az egyéni folyamat szempontjából az az elõnyös, ha annak minél több lapot adunk kezdetben a tárban, hiszen annál ksebb az esélye, hogy laphiba interrupt keletkezik; A folyamatok számára "fix lapszámot kiosztó" algoritmus túl primitív, s nem lenne hatékon; • • Egy adott folyamat minimális lapigénye (azaz hogy egy gépi utasítás végrehajtásához hány lapra lehet szükség) annak kódjából elvileg kideríthetõ --legalábbis a dinamikus memória-allokálás igénye nélkül dolgozó folyamatok esetén, ahol pl. a programok "fejében" lévõ deklarációs részek illetve az ezekkel a változókkal kapcsolatos utasításokezeket az informciókat tatalmazzák--; Az optimális lapigény nagyon nehezen lenne meghatározható; Egy véges kapacitású rendszerben a CPU kihasználtságának fokát a multiprogramozás mértékének függvényéban az alábbi sematikus ábra szemlélteti; ezzel kapcsoltaban a

következõ fogalmak megismerése szükséges: ACPUihasználtságánakfoka Multiprogramozásfoka 1. Vergõdés (Trashing): ez az állapot akkor fordul elõ, ha az egész rendszer a laphibák kiszolgálásáva több idõt tölt el, mint az érdemi futással; - Egyes folyamatra vonatkoztatva ez akkor fordul elõ, ha annk túl kevés lapot allokáltunk, emiatt állandóan a háttértárra kell hivatkoznia; - A rendszer egészére vonatkoztatva a rendszer túlterhelése okozza, amikoris a rengeteg futó folyamat darabonként kevés lapot kap, így környezetváltáskor a folyamatok rendre egymást passzírozzák bele a háttértárba; Elkerülni úgy lehet, hogy az aktív tárba csak annyi folyamatot enged a rendszer, amennyinek az optimális lapigényét biztosítani tudja. 2. Lokalitás (Locality): a folyamatok statisztikailag megfigyelt tulajdonsága, hogy egy adott szûk idõ-intervallumban azok a teljes címtartományuknak csak egy kis részét használják. A lokalitásnak

idõbeli, és térbeli oka lehet: - idõbeli lokalitás: ciklusok, verem-mûveletek és globális változók használatakor nagyon valószínû, hogy egy adott mûveletnél használt cím a következõ mûvelet esetében is szükséges lehet; - térbeli lokalitás: hacsak nincsenek a programban drasztikus címugrások, a programkód nagy része szekvenciális darabokban kerül végrehajtásra, azaz az egymás után végrehajtandó utasítások egymáshoz közeli címen vannak elhelyezve; ugyanez áll fent, amikor egy nagyobb tömb-változóI elemeinek kiolvasása vagy beírása történik. 3. A lokalitás fogalma alapján bevezethetõ az egyes folyamatokra vonatkozóan a munkahalmaz fogalma: Egy adott folyamat munkahalmaza egy adott [t0,t1] id[intervallumban az az ezen intervallum alatt hivatkozott lapokból áll. - A loklaitás tulajdonsága miatt egy ilyen munkahalmaz az idõben csak lassan, és kis mértékben változik (azaz a következõ utasítások is nagy valószínûséggel e

halmaz lapjaira fognak hivatkozni); Ez megfelel egy idõban mozgó ablaknak, amelynek nyilvántartása bonyolult hardvert igényelne (a Least Recently Used lap monitorozása), emiatt nyilvántartás helyett erre idõbeli extrapolációs becsléseket használnak; - További gond, hogy egy munkahalmaz mérete futásközben is változik az egyes folyamatok esetében; 4. Laphiba gyakoriság (Page Fault Frequency): Az egyes folyamatok esetén elõforduló laphibák gyakoriságának figyelésével tapasztalatilag ki lehet deríteni, hogy az adott folyamat számára túl sok vagy túl kevés lap lett allokálva a többi folyamat kárára/elõnyére. Helyes beállításnál a két laphiba közt eltelt idõ átlaga nagyobb, mint a szükséges lapcserék lebonyolításához kellõ idõ. - Az operációs rendszer a folyamatok laphiba gyakoriságát (vagy ami ezzel ekvivalens, a a két laphiba közt eltelt átlagos idõt --interfault time--) vizsgálja. - - - Ha egy folyamat jó sok lapot

kap, a laphiba elõfordulási gyakorisága nyilván kicsi; ekkor érdemesebb lehet azt kevesebb lappal ellátni a tárban, s a laphiba gyakoriság kis növekedése ellenében más folyamatoknak adni a fleszabadult lapokat; Ha az adott folyamat laphiba gyakorisága elér egy limitet, vagy növelni kell a neki kiadott lapok számát, vagy ha erre már nincs mód, célszerû az egész folyamatot felfüggeszteni és kiosztani a lapjait a többi folyamatnak; a folyamatot akkor érdemes a "felfüggesztett" állapotból kihozni, ha azt elegendõ lappal lehet elindítani az elektronikus tárban. A CPU kihasználása szempontjából nagyon fontos jól beállítani a folyamatoknak való megfelelõ lapszámokat. 5. Elõrelapozás (prepaging): A folyamat indításakor vagy a "felfüggesztett állapotból" való visszahozás elõtt még nem rendelkezik lapokkal az elektronikus tárben; - Nem triviális, hogy hány lappal kell elindítani; ha túl kevés lappal indítja az OP.R,

futása laphibák sokaságát okozza; - mindenképp érdemes több lappal behozni, hogy gyûljön össze a kezdeti munkahalmaza; - ha lehet, felfüggesztés után érdemes az összes lapját behozni. 9.5 A lapmérettel kapcsolatos megfontolások: • • • • A lapméretet általában a hardver köti meg, tipikus értéke 512 byte-tól 16 kByte közt lehet; Egyes processzorok esetén a lapméret állítható (pl. M68030); A lap méretének növelése elõnyös lenne az alábbi szempontok miatt: - csökkenõ méret és adminisztráció a laptáblákkal; - nagy blokkot egyszerre gyorsabban lehet kilökni a perifériára, mint sok kicsit, mivel a drive beállítása tetemes elõkészítési idõt igényel; A lapméret csökkenése azért lenne elõnyös, mert - csökken vele a belsõ töredezettség; - jobban kihasználható vele a "lokalitás" elõnyei. A megfelelõ méret a fenti szempontok szerinti nemtriviális kompromisszum szerint választható meg. • •

• Programok írásakor érdemes ügyelni a lokaitás elvére, ez gyorsítja a futást (ehhez ismerni kell a fordítóprogram és a tárkezelõ múködését); pl. - a sokdimenziós tömbök elemeire érdemes a tárbeli elhelyezkedéssel összhangban, és nem a tárbeli "bakugrások" szerint hivatkozni, ez nyilván támogatja a lokalitást; - a deklarációs szakaszban érdemes a memóriában egymás mellé rakatni azokat a változókat, amelyek tratalmát a program szimultán használja; - ha vannak egymást hívó eljárások, azok kódjai lehetõleg egymás mellé kerüljenek a tárban; - megfelelõ adatszerkezetek definiálása, a mi a tömörséget és a lokalitást javítja. Fordításkor: - érdemes a kód- és adatterületeket jól szétválasztani: a kódterület tartalma nem változik, az adatterükleteké igen; lapcsere esetén a kódterület tartalmát nem kell újra kiírni a diszkre, csak az adatokét; - az eljárások egymás mellé helyezését a fordítási

fázisban is lehet befolyásolni. lapok befgyasztása a tárba (page locking): - Bizonyos lapokat nem szabad a lapcsere mûveletének "prédájává tenni", azokat a tárba érdemes befagyasztani; Ilyen például + elindított perifériás mûvelet címtartománya az átvitel végéig maradjon a tárban, ha az átvitel nincs teljes mértékben a rendszerpuffereken keresztül megoldva; + a frissen behozott lapokat az elsõ reájuk való hivatkozásig érdemes befagyasztani, nehogy "ellopja a helyüket" egy nagyobb prioritású folyamat a "futásra kész listából"; A háttértár kezelésének kérdései A témakörhöz tartozó alapfogalmak (diszk, sáv, fejmozgás, elfordulás, a fájlok, könyvtárak, hozzáférési jogok) kérdése az elõadás korábbi részeibõl legalábbis nagy vonalakban ismert az MS DOS példáján. Itt csak olyan megfontolásokat említünk, amelyek ezekhez képest újak, vagy általánosabbak. A fejmozgás

optimalizálásának stratégiái: a lemezmûveletek ütemezése Multiprogramozott rendszerekben az egyes processzek "diszkmûveleteket" rendelnek meg, azaz kiigénylik a diszket mint erõforrást. Track Cilinder Forgástengely Fejek Fejmozgás Egy merev lemez tipikus szervezõdése A merev diszk mûködésének jellemzõ idõadatai: • • • fejmozgási idõ (seek time): a kívánt sávra (cilinderre) való ráállás ideje (ez a leghosszabb); elfordulási idõ (latency time): az az idõ, ami alatt a kívánt szektor a fej alá fordul; az információ tényleges átvitelének ideje(transfer time); A sorban álló igények kielégítésének számos módja lehet. A legyakoribb megoldások az alábbiak: • Sorrendi kiszolgálás --Fisrt Come First Served, SCFS--: az egyes megrendelések érkezésük sorrendjében vannak kielégítve; - egyszerû; - az átbocsátó képessége (=az idõegység alatt lebonyolított átvitelek száma) kicsi; - átlagos válaszideje

(az átvitel kérésétõl a végrehajtásáig eltelt idõ) hosszú; - a válasidõ szórása kicsi, azaz az átvitel végrehajtásának idõszükséglete elõre becsülhetõ; • Legrövidebb fejmozgási idõ --Shortest Seek Tinme First, SSTF--: a következõ kiszolgált kérés az, amelyik az aktuálishoz legközelebb esõ cilinderre hívatkozik, ez ugyanis minimális fejmozgási idõt igényel az átváltásnál; - átbocsátó képessége jobb az FCFS-nél, - a válaszidõ szórása elég nagy lehet, nem becsülhetõ megbízhatóan az átvitel idõtartama; - fennáll a kiéhezés veszélye egyes igények szempontjából, mivel a befutó újabb igények kiszolgálás sokszor elõbbre kerülhet; • Pásztázás (SCAN): Csak az aktuális fejmozgás irányának megfelelõ kéréseket szolgálja ki a listából, addig, amíg azok ki nem fogynak, majd utána a megfordított irányba esõ kéréseket; - átbocsátó képessége jobb az SSTF-nél; - a válaszidõ szórása is

kisebb, mint az SSTF-nél, - a középsõ cilinderek gyakrabban "látogatottak", mint a szélsõk; • N lépéses pásztázás --N SCAN--: a SCAN módszer módosítása: egy iránybe mozogva csak a pásztázás kezdetekeor már meglévõ megerndelések közül mindössze N-et szolgál ki a megfelelõ irányú fejmozgást igénylõkbõl, utána megfordul; a pásztázás közben "beesõ" megrendelésekkel csak a megfordulás után foglalkozik; - a válaszidõ szórását csökkenti a SCAN módszerhez képest; • Egyirányú --körbeforgó-- pásztázás (Circular Scan): a kiszolgálás mindig csak az egyik irányba esõ fejmozgásnál történik, míg a másik irányban ugrás történik a legtávolabbi cilinderre; azonnal figyelembe veheti a pásztázás közben beérkezõ kréseket, vagy csak ugrás után, mint az elõbbi példában; - javítja a sima SCAN módszer azon hibáját, hogy a szélsõ cilinderekre vonatkozó megrendelések "háttérbe

szorulnak"; Terheléstõl függõ "kevert" módszerek: - a drive alacsony terhelése esetén a sima SCAN módszert alkalmazza; - közepes terhelésnél a Circular Scan módszerel szolgál ki; - nagy terhelésnél az elfordulási idõ optimalizálását is figyelembve vevõ C-SCAN módszerrel dolgozik; • Kiegészítõ teljesítménynövelõ módszerek: • • • • Elfordulási idõ optimalizálás: a cilinderen belüli szektor-kiírási rend optimalizálása (sector interleave--szektor közbeékelõdés); Diszktömörítés (disk compaction): hasonló megfontoláson alapul, mint az elektromos memóriában a "lokalitás elve": az egymásutáni kérések vonatkozzanak lehetõleg egymáshoz közeli diszk-helyekre, akkor minimális fejmozgási idõ kell; multiprogramozott rendszerben nem nagyon lehet megvalósítani, mert egymástól független programok futnak, emiatt nem szervezhetõ át az egész rendszerük; külön programmal is beállítható, mint

a DEFRAG a Windowsban; Ha SCAN típusú ütemezést használ az OP.R, akkor neki célszerû az adatállományokat a "középsõ", gyakran látogatott cilinderekre rátennie, amíg ott van erre hely; Fontos és gyakorta kellõ adatokat érdemes többszöri másolatban a széleken és középen is tárolni, hogy a rájuk való hivatkozás esetén minden fejpozícióhoz tartozzon egy viszonylag rövid keresési idejû fej-állás; • • Ha van egy fejbeállásunk, érdemes abból több blokot is memóriába vinni, hogy nek kelljen miaytuk külön-külön pozicionálni a fejet; Mind a központi tár, mindpedig a periféria-illesztõ rendelkezhet gyors hozzáférésû elektronikus tárral (disk cahce); a gyakran kellõ blokkokat inkább tároljuk ebben, a szekrtorok változását is tároljuk itt; a lemezre való tényleges kiírás történhet - mindig a cache tartalmának a diszkre írásával (write through cache), ekkor a CPU-nak erre már nem kell várnia (neki elég

kivárni a cache-be való beírást, a többi a drive belügye); - vagy nem írjuk ki a diszkre a tárat, csak akkor, ha arra más céból ténylegesen szükség lesz (ez hatékonyabb); Állományok tárolása a lemezen A DOS és a WINDOWS kapcsán csak egyféle tátolási módot (boot sector -- directory -- FAT tábla) tekintettünk. Nem minden rendszer ezt használja, vannak alternatív módszereek is Általános szervezési elv, hogy a lemezen való adatnyilvántartás néhány szektort tartalmazó blokkokra vonatkozik, azaz blokkok allokálhatók fájlokhoz, vagy szabadíthatók fel egyben. A gyakorlatban szükséges • a szabad blokkok nyilvántartása, és • az egy állománhoz (file) tartozó blokkok értelmes rendezése. Az alábbi módszerek terjedtek el a szabad blokkok nyilvántartására: A szabad blokkok nyilvántartása: • • • • bittérkép: Valamennyi blokkhoz hozzárendelõdik egy bitnyi információ egy adott helyre tett "bittérképen"; a

bit állása jelzi, hogy az adott blokk éppen szabad vagy foglalt; (ezzel nagyon könnyen lehet egymás mellett álló szabad blokokat kikeresni késõbbi lefoglalás céljára); láncolt lista: Valamennyi blokkból egy bizonyos rész a következõ blokkra való hivatkozási információ tárolására van lefoglalva; ez a módszer nagyon sok lemezmûveletet igényel ahhoz, hogy áttekinthetõ legyen; szabad blokkcsoportok listája: egy-egy szabad blokk "n" db szabad blokkra hivatkozik úgy, hogy ezekbõl (n-1) blokk ténylegesen szabad (azaz tárolhat érdemi információt), egy blokk, az utolsó pedig egy következõ blokk n-esre hivatkozik; (ez az elõzõ módszer kisfokú javítása); egybefüggõ szabad területek nyilvántartása: egy táblázatot használ, amely az egymás mellett lévõ szabad blokkok közül az elsõ sorszámát, illetve a terület hoszát tárolja; (akkor elõnyös, ha sok blokkból álló szabad terület van; jól támogatja a szabad blokkok

összevonását); File allokálási módszerek: Az áloományok számára valahogy szabad blokkokat kell kiosztani a diszken, s tárolni kell az azok "összerendezéséhez" kellõ információkat is. Az elterjedt módszerek az alábbiak: • • Folytonos blokkok allokációja: a rendszer csak az lesõ blokk sorszámát, és az összetratozó blokkok számát tárolja; - hajlamos a töredezésre, rosszul használja ki a diszket; hasonló algoritmusokkal valósítható meg, mint az elektronikus memória kiosztása; extra töredezésmentesítést igényel; - igen könnyû vele soros és véletlen elérést elérni a tárolt információt illetõen; - jól támogatja a lapcseréket fõleg azok fix mérete esetén; Láncolt tárolás: A blokkok egyesével vannak fájlokhoz kiosztva, mindegyik blokkban fenntartott hely van a következõ blokkra való hivatkozáshoz; az OP.R-nek az állományok nyilvántartásában az elsõ és az utolsõ blokk sorszámát kell tárolnia; -

eleve mentes a külsõ töredezettségtõl, a hely maximálisan kihasználható blokkméretekben gondolkodva; - az állomány méretének változását tekintve nagyon rugalmas; - jól támogatja a soros elérést: a szomszédos blokkok megtalálása egyeszrû; - • • rosszul támogatja a közvetlen hozzáférést: az egész láncot végig kell nézni hozzá; a rendszer automatikusan nem tudja, hogy az utolsó érdemi blokkban mennyi érdemi információ van az állományból, s mennyi benne a szemét; ennek az információnak a kódolásáról külön kell gondoskodni; sérülékeny: ha a lánc valahol diszk hiba miatt "elszakad", a lánc nem göngyölhetõ fel, sok információ veszhet el kis hiba miatt; A File Allocation Table és biztonsági másolatainak bevezetésével a láncolt tárolás biztonsága növelhetõ; Indexelt tárolás: az adott állományhoz tartozó blokkok mutatóit külün adatterület, az index tábla tárolja. Az "állomány"

tárolása a nyers adatok leírásán kívül az indextábla karbantartásával és címének tárolásával együtt történik; - igen jól támogatja a közvetlen hozzáférést; - olyan állományok tárolására is használható, amelyben vannak érdemi információt nem tartalmazó, "üres blokkok"; az üres blokkoknak ténylegesen nem kell diszk területet lefoglalni; - általában mégis helypazarló: kevés blokkból álló állomány tárolásához az indextábla minimum egy blokknyi helyet lefoglal; - az indextábla mérete az állomány alakulásával csökkenhet vagy nõhet, ezt követhetõvé kell tenni; lehetséges módszerek: + láncolt indexblokkok; + többszintes indextáblák használatával: az "alsó szint"-en lévõ tábla indexe nem magának az állománynak, hanem csak az index-tábla következõ szintje blokkjára mutat; + vegyes módszerrel (pl. mint a UNIX teszi): kis file-hoz közvetlen indextábla, nagy állományhoz egyre több szintû

indexblokkok hozzárendelésével; Kombinált tárolási mód: - soros hozzáférésû állományt láncolt módon tárol, - közvetlen hozzáférésû file-t folytonos blokkban tárol (ezeket programozáskor deklaráltan kell megnyitni ilyennek vagy olyannak) ill. méret szerint is változóan: - kis állományt folytonosan tárol; - nagy állományt indexelten. Az állományok belsõ logikai szervezésének kapcsolata az OP.R-rel A felhasználó az adatálloányt illetõen általában valami • • mezõkbõl (field), azaz adatkategóriákat leíró információ, ill. rekordokból (mezõcsoportok konkrét tartalmából) építi fel az állományait. Az állomány állhat • • azonos szerkezetû rekordokból, vagy különbözõ, de azonosítható szerkezetû rekordokból. A mezõk és a rekordok hossza lehet azonos, vagy változó (ez utóbbi esetben vagy a rekord hosszára vonatkozó információt kell tárolni, vagy valami "végjelet" a rekordok szeparálására).

Az OP.R két dolgot tehet: • • az állomány logikai strukturáltságát a feéhasználó belügyének tekinti, s nem foglalkozik vele, "nem is tud róla" pl. DOS; az OP.R támogatja ezeket a tipikus lehetõségeket a rekordonkénti illteve mezõnkénti adat-hozzáféréshez. A tipikus hozzáférési módok: • • • • soros (sequentuial): a régi mágnesszalagos idõkben használt módszer mintájára szervezett; közvetlen (direct) elérés: a byte--mezõ--rekord elemek mindegyikének közvetlen elérését lehetõvé teszi; Indexelt, index szekvenciális (index sequential access method ISAM): Ez a állományok soros tárolását jelenti rekordonként, de úgy, hogy a rekordokhoz hozzárendelünk egy "kulcs" értéket is, ami nem egyéb, mint a rekord kijelölt mezõ tartalma szerinti sorbarendezésének sorszáma. Az index-tábla a rekordok állományon belüli címét és a kulcs-értékekettárolja, a s bejegyzései a kulcs szerint vannak

sorbarendezve. A keresés a kisméretû indextáblában történik Nagy állományra ennek karbantartása elég munkaigényes lehet. Partícionált allokáció: - Az állomány soros részállományokból épül fel; - az állomány eleje tárolja, hogy az egyes partíciók hol kezdõdnek az állományon belül; Könyvtárkezelés Az MS DOS, WINDOWS példáján látottakkal összhangban láthatóan bármilyen megoldást is használ az OP.R a fájlok fizikai elhelyezésére a diszken, minden esetben szükség van egy "nyilvántartási bejegyzések" ("Directory Entry") rész fenntartására, amely tartalmazza: - - - az állomány nevét (ez könyvtáron belülegyedi kell legyen); (pl. a UNIX esetében a név lehet "nyomtatható karakterekből álló homogén karakter sor, megkülönböztetve egymástól a kis és nagy betűket", a DOS esetében NAME.EXTENSION formátumú, max 8 ill 3 karakterből álló kötött név (a kis -és nagybetűk

megkülönböztetése nélkül), a VMS-ben "név+kiterjesztés+verziószám" bontású, kötött szitaxisú karaktersorozat, stb. az állomány fizikai elhelyezkedésének leírásához kellő információk (ezek egy része lehet máshol is, pl. a FAT használata esetén elég a kezdő cluster), azaz általában: az állomány hossza (egzakt, byte-ban); az állományhoz tartozó háttértári blokkok leírása; az állományhoz való hozzáférés módja. Az állomány kezelését leíró logikai információk: Típus (ha van); Tulajdonos ("owner") azonosítója; Időpont adatok (létrehozás, utolsó módosítás, utolsó hozzáférés, az argumentumok utolsó módosítása, meddig kell tárolni) Hozzáférési jogosultságok; "hivatkozás számláló" (pl. UNIX-ban ugyanarra a file-ra több felhasználó különböző neveken hivatkozhat; ha "X" felhasználó a maga részéről törölni akarja az állományt, "Y" felhasználó pedig

még használni akarja azt, a tényleges törlést nem szabad végrehajtani: az állomány hivatkozásszámlálójának értékét kell csökkenteni; törölni csak olyan file-t szabad, amelyre senki sem akar már hivatkozni; ehelyett az állományt csak "X" felhasználó látóköréből kell kiszedni. Bizonyos OP.R-ek a nyilvántartás-bejegyzésekben célszerűen elkülönítik egymástól a "Volume Directory" és a "File Directory" részeket, amelyek közül - a "Volume Directory" tartalmazza a "Kötet" összes állományának leírásához kellő fizikai információkat, és egyes logikai információkat, míg a "File Directory" az egyes fájlok alkönyvtárakba való szervezését, s egyéb, állomány-leíró logikai információkat tárolnak. Az állományok kezelését gyorsítja, ha azon állományok egyes adatait, amelyekkel az OP.R ténylegesen foglalkozik, az operatív tárban tartják. Ezek az alábbiak: - -

Az adatátvitel pillanatnyi állapota (a soros hozzáférés pozíciója, legális műveletek, annak rögzítése, hogy egy adott folyamat az adott állománnyal mit tehet meg --ennek maximuma az állományhoz rendelt maximális jogosultság lehet, de egyéb korlátozó tényezők is szűkíthetik); Osztott adatkezeléssel kapcsolatos információk: az állományt egyidejűleg használó folyamatok száma, a "kölcsönös kizárás" biztosításának módja és tartománya, valamint az állomány használatára várakozó folyamatok nyilvántartása. Biztosítandó továbbá egy "Könyvtári Hierarchia" az állományok jobb átláthatósága érdekében. Erre több megoldás van: - "Kétszintű könyvtárak" alkalmazása: egy-egy könyvtárba kerülnek az egyes felhasználók állományai; mivel a különböző felhasználók egymás állományait is akarhatják használni, az OP.R számára a "felhasználó neve+állomány neve" együttes

hordoz "definit" információt; (az OP.R mindenki által használni akart szolgáltatásait az ún. "Rendszerkönyvtár" tartalmazza) - "Többszintű könyvtárak": lehetővé kell tenni, hogy egy könyvtárban ne cas állományok, hanem más könyvtárak nevei is betehetők legyenek DOS, WINDOWS fa -szerkezete); Ehhez a következő fogalmak bevezetése szükséges általában: - - "aktuális könyvtár -Current Directory" ez minden folyamatra más-és más lehet az adott pillanatban, tehát folyamatonként kell nyilvántartani; "gyökérkönyvtár --Root Directory" a hierarchia kiinduló pontja; "elérési út --Path--" a gyökérből, vagy az adott alkönyvtárból valúó elérés melty könyvtárakon keresztül vezet; "keresési utak --Search Path--": ha az aktuáléis könyvtárban nincs benne a hivatkozott állomány, hol keresse azt az OP.R? (Pl a DOS esetében ez egy OP.R-hez rendelt memóriaváltozó

volt); egyes rendszerekben ez a beállítás az összes felhasználóra érvényes, másokban a felhasználók külön-külön megadhatják ezt maguknak; Biztosítandó a "Körmentes Irányított Gráf " szerkezet: ez garantálja, hogy az OP.R ne fusson bele végtelen ciklusba, miközben egy állományt keres; ha az elérési út egyértelmű, akkor ez megfelel egy Fa gráf-nak, ha egy állomány többféle úton is elérhető egy adott könyvtárból, a gráfszerkezet a Fa-gráfnál általánosabb; A fentieknél általánosabb, azaz hurkokat is megengedő gráf-szerkezet használatának nincs értelme. Az egyes felhasználók az állományokra a könyvtárszerkezet elérési útjain keresztül tudnak kényelmesen hivatkozni, míg az OP.R-nek közvetlenül a hivatkozott fizikai állománnyal van dolga. Biztosítani kell ezek egymáshozrendelését ("Link") Erre a következő lehetőségek vannak: - "Fizikailag", azaz az állományt leíró fizikai

információk megismétlésével, iletve a pl. UNIX esetében a "Volume Directory"-ra való hivatkozással; "Szimbolikusan", azaz az egyik lehetséges elérési úton át; Ez utóbbi bonyolultabb, mert míg ugyaz az egyes felhasználók számára jól átlátható, az OP.R számára nem az: ugyanazon fizikai állományra több szimultán hivatkozás is élhet a rendszerben, de - pl. a rendszerstatisztikák elkészítéséhez elég csak az egyiket használni (azaz ki kell deríteni, hogy több hivatkozás ugyanazon állományra vonatkozik-e, vagy sokszorozni kell a statisztikákat); - nehézségek adódnak e törlésnél, mert számon kell tartani, hogy egy konkrét állományra hány szimultán, különböző utakon keresztüli hivatkozás történik --törölni csak akkor lehet, ha ezek száma az adott időpontban zérus). Tipikus file-műveletek: - - - - átvitel, azaz írás vagy olvasás, lehet soros, vagy közvetlen (random) hozzáférésű; egy

állomány estében megengedhető lehet szimultán írás és olvasás is; hozzáírás (Append): ez igényelheti újabb blokkok allokálását is; pozicionálás (azaz hol vagyunk az állományon belül?); megnyitás (Open): nem célszerű minden file-művelethez a szükséges információkat mindig a diszk-ről beszerezni; azokra a fájlokra, amelyekkel az OP.R tényleg dolgozik, a kurrens indormációk egy részét érdemes a memóriában tárolni; a megnyitás ezt teszi lehetővé. Így számos műveletet nem kell többször megismételni sem: elvégzi az állomány megkeresését, fizikai helyének megtalálását; ellenőrzi a hozzáférési jogosultságot; ellenőrzi, hogy az adott állományon mely műveletek engedélyezettek az adott folyamat számára; szabályozza az osztott file-kezelést (pl. kölcsönös kizárás); pozícionálást soros keresésnél; lezárás (Close): az adott felhasználó részéről felszabadítja az állományt (ha azt többen is használják); a

tényleges használat befejeztekor (amikortól már senki sem akarja használni), a diszkre kell írni az addig pufferelt módosításokat); végehajtás (Execution): ha programfile-ról van szó, létre kell hozni egy folyamatot, az állomány egy (részét legalább) be kell tölteni az elektronikus tárba, más részét esetleg a háttértárba, majd be kell írni az új folyamatot a "Futásra Kész" folyamatok listájába; Az állományok kezelésén kívül a könyvtárszerkezet módosítását is okozhatják az alábbi műveletek: - állomány létrehozása (Create): új bejegyzés a "Directory"-ban, esetleg a könyvtárszerkezetet tároló részen, új blokkkok allokálása a lemezen; - állomány törlése (Delete): a lefoglalt blokkok felszabadítása, esetleg átvitel a "Szemétládába" (lomtár). A könytárakkal végezhető műveletek: - attribútumok módosítása (magának az állománynak a fizikai részét nem érintyi, csak a

vejegyzéseinek egy részét); - új könyvtár létrehozása; - könyvtár törlése, tekintettel annak tartalmára (töröljük a teljes tartalommal együtt, beleértve a kiágazó könyvtárakat is, vagy csak akkor, ha már üres?); - állományok keresése a könyvtárakon belül, (azaz a állomány nevéhez hozzá kell rendelni annak fizikai helyét) (lehet rendezetlenül, teljes bejárással, vagy gyorsított kereséssel, pl. rendezett állományon "intevallum felezéssel"), ill a tágabb könyvtár-szerkesetben is; (lehet lassú, sok lemez-műveletet igénylő); - új állomány bejegyzése; - bejegyzés törlése (azaz általában nem az állományé, csak a bejegyzéséé, csökkentendő a véletlen törlés okozta károkat); - véletlenül törölt állomány (esetleg részleges) visszaállítása; Osztott állományok kezelése Állomány="Osztott Erőforrás", azaz egyszerre több processz is hozzáférhet; ha ezek közül valamelyik írni akar,

biztosítani kell a kölcsönös kizárást. Ennek hatóköre különböző lehet: - - - Teljes állományra való szabályozás ("File Lock"): az állományt legelőször megnyitó processznek definiálnia kell, mi legyen az azt később megnyitó processzek hozzáférési joga: Kizárólagos használat: további processzek meg sem nyithatják az állományt, várniuk kell addig, amíg ez a processz "bezárja" azt; A többi folyamat csak olvashatja az állományt: írási joga legfeljebb csak az első processznek lehet; További processzek is megnyithatják írási joggal; Ha van legalább egy folyamat, amelyik írást végez, definiálandó, hogy ennek eredményét a mikor láthatja a többi processz: Azonnal, Csak azután, hogy az író folyamat az állományt lezárta, addig a többí az írás előtti állapotot látja. Azány egyes részeire érvényes kizárás: ekkor nem a teljes állomány, hanem annak rekordjai (bizonyos rekord-csoportjai)

szerepeltetendők önálló erőforrásként, amelyen a hozzáférni akaró folyamatok osztoznak; így a kölcsönös kizárás az író folyamatok által érintett rekordokra vonatkozik csak, nem az egész állományra; a többi folyamat számára az írás után felszabaduló rekordok azonnal láthatóvá válnak. Itt felléphet a kiéhezés ill. a holtpont veszélye is! Osztott állományon dolgozó felhasználók jogainak szabályozása: Miután az egyes felhasználók az állományokat könyvtárszerkezet segítségével érik el, e jogokat célszerű részben a könyvtárakra, részban az állományokra kiróni. E műveletek egymással analóg módon tárgyalhatók: Állományokra vonatkozó jogok Írás Olvasás Végrehajtás Hozzáírás (append) Törlés Könyvtárakra vonatkozó jogok Módosítás Listázás Keresés Új állomány kreálása Könyvtár törlése Minden felhasználó által elindított folyamat-hoz hozzárendelhetők a felhasználó megfelelő

jogosítványai, ezek "élete végéig" "reá ragadnak". Az "állományi jogok" hozzárendelhetők: - Az állományokhoz közvetlenül, vagy - Az elérési útjukhoz is. A "felhasználói jogok" az egyes konkrét felhasználókhoz, vagy --hogy a rendszer átteklinthetőbb legyen--, tipikus felhasználói csoportokhoz rendelhetők hozzá. Ilyenek pl - Maga az OP.R - Az állomány tulajdonosa; - Speciális csoportok tagjai; - Akárki. 1 Az elosztott OP.R- (Distributed Operating Systems)-ek típusai Az adatátvitel részleteitől hálózati topológiák részletezésétől eltekintve az alábbi fő "szolgáltatástípusok" léteznek: Hálózati Op.R-ek (Network operating Systems) szolgáltatásai: - - Távoli terminál (Remote Terminal, Remote Login): a helyi gépet különösebben nem, csak annak terminálját használja, mintha az közvetlenül a távoli gépre lenne kötve; Állományok átvitele (File Transfer): teljes

állományok átmásolása mindkét irányban; Valódi elosztott OP.R-ek: A felhasználó úgy kezelheti a távoli erőforrásokat is, mintha azok a lokális gépén lennének. Az ehhez kellő információ-cserét többféleképp lehet megoldani: - - - - - Adatvándorlás (Data Migratiuon): a teljes vagy részleges távoli állomány helyi gépre való másolása, ideiglenesen a helyi gépen való használata/módosítása, majd visszamásolása; A feldolgozás vándorlása (Computation Migration): ha nagy tömegű adatot fölösleges átmásolni, a feldolgozó programot érdemes a távoli gépre áttelepíteni, s ott használni; módozatai: Üzenetküldés (Message Passing): a feldolgozás igénye adatik meg a távoli gépnek, a közeli gépen futó program tovább fut helyben, a feldolgozás eredményét, ha megjött, felhasználja; Távoli eljáráshívás (Remote Procedure Call): szintén üzenetküldéssel valósítható meg, de ekkor csupán egy távoli procedúra hívatik

meg, s ekkor be kell várni a választ a továbblépéshez, mint egy egyszerű szekvenciális programban; Folyamatvándorlás (Process Migration): egy folyamat, vagy annak parallel végrehajtható részei futhatnak a távoli gépen, annélkül, hogy a felhasználó arról tudna. 2