Informatika | Operációs rendszerek » Veres József - Operációs rendszerek

OPERÁCIÓS RENDSZEREK HIBA- ÉS ESEMÉNYKEZELÉS FOLYAMATOK KÖZÖTTI INFORMÁCIÓCSERE KÖLCSÖNÖS KIZÁRÁS, KRITIKUS SZAKASZ (MUTUAL EXCLUSION, CRITICAL SECTION) MEMÓRIAMENEDZSELÉS AZ I/O RENDSZER, ESZKÖZÖK, MÁSODLAGOS TÁROLÓK, FÁJLRENDSZEREK RENDSZERMENEDZSERI FELADATOK AZ X/OPEN ÉS AZ XPG VÉDJEGYEK A MACH OPERÁCIÓS RENDSZER AZ MS DOS OPERÁCIÓS RENDSZER 1. Operációs rendszerek A legtöbb számítógép felhasználó használja az operációs rendszereket, azok szolgáltatásait, anélkül, hogy pontosan meg tudná fogalmazni, mi is az operációs rendszer. Tudják, hogy egy rendszer szoftver, ami kezeli a gépet, parancsokat tud fogadni, tartoznak hozzá eszközök, állományok, katalógusok, ezekben lehet manipulálni, stb. De ha definiálni kell az operációs rendszert, akkor gondban vannak. Ennek a bizonytalanságnak az az oka, hogy az operációs rendszerek alapvetõen két, egymástól független funkciót (funkciócsoportot) valósítanak meg, két,

egymástól független nézõpontból szemlélhetõk, két szempontból definiálható a lényegük, és rendszerint nem tisztázzák a definíció során, hogy melyik nézõpontból történik a definíció, vagy az operációs rendszer fogalom meghatározásakor éppen keveredik a két nézõpont. Tanulmányaink során találkoztunk már hasonló problémával. Példaként említhetem a shell illetve az architektúra fogalmat. A shell szó kimondásakor is két dologra gondolhatunk A shell egyik értelemben egy parancsértelmezõ, egy folyamat (process), ami készenléti jelet (prompt) ad a felhasználó termináljára (v. terminálemulációs ablakában), jelezve, hogy kész parancsot fogadni a standard input-on, azt elemzi, és vagy ugyanebben a folyamatban vagy újabb folyamatot indítva valamint csinál. A shell szó másik értelmében egy programnyelv, amiben vannak vezérlõ szerkezetek (soros végrehajtás, elágazások, ciklusok) és adatszerkezetek (shell változók és

szöveglánc konstansok). A shell script kifejezés használatakor erre a második definícióra gondolunk Az összefüggés a két nézõpont definíciója között tiszta: a shell értelmezõ képes feldolgozni a shell programot - akár interaktív akár kötegelt (batch) módon, de a két értelmezés különbözõségét tisztán kell látnunk. A másik példán az architektúra fogalom. Elsõ értelmezésünkben az architektúra egy digitális számítógép általános specifikációja, beleértve az utasításkészletét (instruction set), társzervezését (memory organization), címzési módokat, a B/K mûveleteket, sin struktúrákat és vezérlésüket. Az ebbõl a szempontból nézett architektúra azonosság biztosítja pl a számítógépek helyettesíthetõségét (compatibility), csatlakoztathatóságát. Villamosmérnöki (hardvertervezési) szempontból az architektúra egy számítógép fõ elemei kapcsolódásának leírása, blokkdiagram v. áramköri rajzok, stb

formájában Az architektúra itt a konfigurációt írja le. Térjünk vissza az operációs rendszerekhez. Az operációs rendszer hasonlít egy kormányhoz, azaz maga nem teljesít valódi funkciót, de lehetõséget ad az alkalmazások hasznos tevékenységéhez. Van erõforrás kiosztó (resoruce allocator) és vezérlõ (control program) szerepköre. Néha úgy szemléljük az operációs rendszert, hogy az azon programok gyûjteménye, amit a számítógéprendszer szállító a géphez szállított. Máskor: azon programok, amik mindig futnak a számítógépünkön. Egy jó módszer az operációs rendszer definiálására, ha megragadjuk kettõs természetét: az operációs rendszer egyrészt virtuális gép, másrészt erõforrás menedzser. (Néha így definiálják: válaszoló gép). 1.1 Az OS mint kiterjesztett gép (Extended Machine, Virtual Machine) A legtöbb számítógép gépi nyelvû programozása - különösen a B/K mûveletekre gondoljunk bonyolult, sok

odafigyelést igénylõ munka. Jól kell ismerni az architektúrát (az elsõ értelemben vett módon!), a hardver részleteket. Gondoljuk végig például egy floppy diszk blokk behozatal forgatókönyvet! A legtöbb programozás (nem is beszélve az általános felhasználóról) nincs olyan intim kapcsolatba az architektúrával, hogy ezt le tudná programozni! Az operációs rendszer - mint kiterjesztett gép - magasabb absztrakciós szintet biztosít a felhasználó számára. Az eszközöket és állományokat szimbolikus neveken engedi kezelni, ezekben magasabb szintû operációkat biztosít (pl. open, read, write rendszerhívásokat (system calls, lásd késõbb részletesebben)), sõt, az operációs rendekhez kötõdõ parancsértelmezõkkel még magasabb szintû parancsokat (pl. copy, move, stb) Úgy is mondhatjuk, ebbõl a szempontból nézve az operációs rendszer elrejti a részleteket a felhasználó elõl, levesz bizonyos felelõsséget a felhasználó válláról,

akár különbözõ architektúrákon is biztosítja helyettesíthetõségét, egységességet biztosít a hasonló de részleteikben nagyban különbözõ eszközök (pl.: floppy diszkek és hard diszkek) kezelésére Ez egy felülrõl-lefelé (top-down) megközelítése a problémának. A virtuális gépet, amit az operációs rendszer biztosít, könnyebb programozni, mint az alatta létezõ hardvert. Persze, hogy ezt hogyan biztosítja, ez egy hosszú történet, az Operációs rendszerek tárgy egyik célja, hogy ezt is megismerjük. Ha úgy tetszik, ebbõl a szempontból kényelmessé teszi (convenience for the users) az operációs rendszer a hardver használatot. 1.2 Az OS mint erõforrás menedzser (Resource Manager) Egy másik - valójában alulról-felfelé való (bottom-up) megközelítésben az operációs rendszer azért van, hogy egy összetett rendszer részeit menedzselje. Egy korszerû számítógép processzorokból, tárakból, óraeszközökbõl,

diszkekbõl, mágnesszalagos tárolókból terminálokból, nyomtatókból, hálózati eszközökbõl, stb. tevõdik össze. Az operációs rendszer feladata, hogy ezeket az erõforrásokat a gépen futó különbözõ, az erõforrásokért tulajdonképpen vetélkedõ programok számára. (Példa lehet itt is: forgatókönyv arra az esetre, amikor két processz ugyanarra a nyomtatóra akar nyomtatni.) Milyen erõforrásokat kell menedzselnie az operációs rendszereknek? • A hardver erõforrásokat (processzorok, elsõdleges és másodlagos tárak, eszközök stb.), • a szoftver erõforrásokat (alkalmazások, adatbázisok stb.) és • az emberi erõforrást )felhasználók, operátorok, rendszermenedzserek stb.) A menedzselési feladatkörbe az erõforrás kiosztás mellett természetesen beleértjük az erõforrás védelmet (kölcsönös kizárást kritikus esetekben) a konfliktusok feloldását az erõforrások használatának számbavételét (statisztikák

készítését, számlázásokat is). Olyan fogalmak merülnek itt fel, mint a hatékonyság, a teljesítmény, a védelem és biztonság, a megbízhatóság stb. Ha úgy tetszik, ebbõl a szempontból az operációs rendszer hatékonnyá teszi (efficiency) a hardver használatát. 1.3 Az operációs rendszerek története Miután az operációs rendszer elég szorosan kapcsolódik a hardver-struktúrákhoz, történeti fejlõdésüket, generációikat a hardver fejlõdési generációkhoz köthetjük. Ez az összekapcsolás meglehetõs erõltetett, de ad egy bizonyos strukturáltságot. Persze nem kezdjük a kezdet kezdetén - elegendõnek látszik, ha a századunk közepe táján épített, a Neumann elvnek megfelelõ csöves számítógépeket tekintjük az elsõ generációnak. A történeti áttekintés során a számítógép használók munkaköri specializálódásának alakulására, a munkamegosztásbeli fejlõdésre is kitérünk, illetve megemlítjük a programozási

módszerek fejlõdési fokozatait is. Durva felosztás szerint megkülönböztethetünk • hardvereseket, számítógép-építõ villamosmérnököket, (HW kezelése, tesztelése, stb.); • rendszerprogramozókat, rendszer menedzsereket (OS kezelése, fenntartása); • operátorokat (OS kezelés, eszköz kezelés, foglakozás a felhasználókkal); • programozókat, beleértve szervezõket is (alkalmazások készítése, stb.); • mezei felhasználókat (alkalmazások futtatása, stb.) 1.31 Az elsõ generáció (1945-1955): Csövek és dugaszoló táblák (Vacuum Tubes and Plugboards) (Prelingual Stage) H.Aiken ( Harward), N euman J ( Princeton), J P E ckert é s W Manchelty ( Univ o Pennsylvania) és K.Zuse (Németország) - többek között - a 40-es évek közepén már épitettek csöves s zámítógépeket. E zek s zobákat t öltöttek m eg, na gy áramfelvételük vol t - számolási teljesitményük sokkal kisebb, mint a mai legolcsóbb házi

számítógépeké. Ebben a z i dõben m ég ne m vol t m unkamegosztás: ug yan a zok a z e mberek t ervezték és épitették, programozták a g épeket, kezelték, futtatták a p rogramokat, elemezték értékelték az eredményeket. Az " épitõ-programozó-felhasználó" - ha m ár l étezett a g ép - dugasztáblákat k észitett e lõ, "irta" a p rogramot é s r ögzitette a z a datokat, r emélve, hog y e gyetlen c sõ s em r obbant l e, berakta a dugasztáblát a számítógépbe és órákat várt, mig néhány kijelzõ lámpán megjelentek az eredmények. Az 5 0-es év ek el ején an nyit f ejlõdött a d olog, h ogy a d ugasztáblák h elyett l yukkártyákat i s lehetett használni a programozáshoz, adatbevitelhez. A pogramozás gépi nyelven történik, operációs rendszer még nincs. 1.32 Második generáció (1955-1965) Tranzisztorok és kötegelt rendszerek (Exploiting Machine Power) A tr anzisztorok me gjelenése r adikális v áltozást hoz

ott. E gyrészt ki sebbek l ettek a számítógépek és alacsonyabb lett a villanyszámla is, másrészt megjelent a munkamegosztás a számítógépes e mberek kör ében. M egkülönböztethetjük a t ervezõket é s é pitõket, a z operátorokat, a pr ogramozókat é s a ka rbantartókat. A z e lsõ é s ut olsó c soport vi llamos mérnökökbõl verbuválódik, akár lehetnek ugyanazon személyek is. Az operátor szerepkör az idõszak elején m ég nem l étezik, de köz ben kalakul: gyakorlott perifériakezelõk veszik át az eszközök ke zelését a pr ogramozótól. N agyobb intézmények, kor mányszervek, e gyetemek engedhetik meg, hogy számítógépeket beszerezzenek (nemcsak számítógépgyártóknál vannak már s zámítógépek) géptermeket be rendezzenek, a hol a ka rbantartók é s ope rátorok (gépkezelõk) dolgoznak. Nem vált szét még a programozói és felhasználói szerepkör A programozó lyukkártyára lyukasztja a futtatandó programjait, amit

assembly nyelven vagy FORTRAN-ban irt. Lyukkártyára kerülnek az adatok is Ezeket kártyakötegekbe rakják és az igy ö sszeállított jo b-ot át adják az ope rátornak ( Eleinte, a míg ni ncs operátor s zerepkör, operátorként tevékenykedik a programozó-felhasználó). Az operátor elõbb beolvastatja (load) a FORTRAN fordító programját (ez is kártyaköteg) és elindítja (használja ehhez a Front Panel Switch-eket). Maga a forrásprogaram "adat" a fordítónak, amit lefordít (translate), eredménye lyukkártya ( esetleg l yuk-szalag). E zt b etölti ( load), és el indítja ( execute), b eolvasva az adatokat. A z er edmények l yukkártyára l yukasztva, es etleg n yomtatóval t áblákba l istázva jelenhetnek m eg. M egfigyelhetjük a "load-translate-load-execute" t evékenység s orozatot A job-ok e gy konzolról futtahatók. H a a f utó pr ogram " lerobbant", vi zsgálhatták a memóriatartalmakat, b eállíthatták a zokat, to

vábbfuttathattak, min dezt a konzolról le hetett elvégezni. V égül az er edményeket n yomtatták, l yukszalagra, k ártyákra l yukasztották E hhez fejlõdött a ha rdver köz ben: e gyre á ltalánosdabbak l ettek a k ártyaolvasók, s ornyomtatók, az évtized v égére a m ágnes-szalag o lvasók-írók. F ejlõdés vol t a s zoftverekben i s: as sablerek, loaderek, linkerek alakultak ki, többszörösen használható rutinokat másoltak a programokba. Fontosak l ettek a z I/O r utinok, a z új abb é s új abb e szközökhöz ú jabb " device dr iver" programok ké szültek. K ialakultak a f ordítók i s: F ORTRAN é s COBOL ( Increasing t he Expressive Power) Az i dõveszteségek c sökkentésére ki alakul a köve tkezõ s zámítógép f ajták köz ötti munkamegosztás: e gyszerübb é s ol csóbb gépet használnak a rra, ho gy a job ká rtyakötegeket mágnesszalagra t egyék, el õkészitendõ az i gazi futtatást. E gy má sik, r elative d rágább

számítógép v égzi a z " igazi" s zámításokat - ez a s zalagról - gyorsabban be tölti a j ob-hoz szükséges p rogramokat, az er edményeket i smét s zalagra r ögziti. A z o utput s zalag u tána áttehetõ a z ol csóbb - ún. ka rakterorientált - gépre: az e redményeket az l yukasztja i ll nyomtatja ki. Ez a munkamódszer volt az ún k lasszikus kötegelt feldolgozás (batch system), ahol a z ope rációs r endszer t ulajdonképpen a " load-translate-load-execute" t evékenység sorozatot automatizálta. Tipikus off line elõkészitõ, é s n yomtató gép vol t a z IMB 1401, m ig a feldolgozó: a z IBM 7094 ebben az idõben. Megnõtt az operátorok szerepe: õk gyûjtötték össze kötegekben a jobokat, vitték át a szalagot a másik gépre, stb Az évtized végére oda fejlõdött a dolog, hogy fordítók programjait már nem kellett a kötegbe kártyaformában be illeszteni, e legendõ vol t c sak egy vezérlõkártya beillesztés: a f

eldolgozó számítógép a z in put s zalag me llett a f ordítót ( FORTRAN v olt e kkor!) e gy má sik s zalagról betöltötte, a köt eg futtatása me gtörténthetett. E zzel e gyidõben e gyre n övekedett a f ordítás mellett a k önyvtári függvények ( library rutines) s zerepe: a fordítót ta rtalmazó s zalagon könyvtári r utinokat i s e lhelyeztek, a miket a programok hí vhattak, a miket a f uttatható programhoz hoz áillesztettek. M ég ké sõbb a fordítót, kön yvtárakat t artalmazó s zalagokra segédprogramokat ( utilities) i s h elyeztek, és ez eket vezérlõkártyákkal lehetett b etöltetni, aktivizálni: ez így már egy mûködtetõ rendszer volt, "egy-job-egy-idõben" feldolgozással. A mûködtetõ rendszerek - az ope rációs r endszerek õs ei, a z e gy kon zolról ha sználható memóriarezidens monitorok voltak. Fõ részeik: a Job Control Card értelmezõ; a job ütemezõ; és a betöltõ (loader). 1.33 Harmadik generáció

(1965-1980): Integrált áramkörök, multiprogramozás A 6 0-as é vekre ké t, m eglehetõsen kül önbözõ s zámítógépfajta a lakult ki. E gyik a z ún szószervezésû, na gy, t udományos s zámításokra a lkalmas gépcsalád v olt ( mint a 7094) , elsõsorban a num erikus s zámításokban j eleskedett. A m ásik c salád a k arakterorientált gépcsalád, ki sebb, és drágább gépek vol tak ezek, j ól a lkalmazhatták a dat-átalakításra (lyukkártya -> s zalag konve rzió), r endezésre, n yomtatásra, s tb. Elõbbieket f õleg a tudományos és m érnöki s zámításokra, ut óbbiakat a z üz leti é letben ( bankok, bi ztosítók, kereskedelmi társaságok) használták elsõsorban. Elõ-elõfordult, ho gy egy c ég ke zdett dol gozni a z ol csóbb, a datfeldolgozó gé pen, é s i génye támadt a na gyobb, s zámításigényesebb m unkákat i s ki szolgáló gé pre, m ialatt a ké t vona l meglehetõsen kül önbözött , m eg ke llett vol na ve nniük m

indkét gé pfajtát. M i l ett a z eredménye ennek a kihívásnak? A két gépfajta "integrálása". Az IBM vá lasza a S ystem/360 r endszer vol t. E z t ulajdonképpen e gy gépsorozat, m elyek szoftver kom patibilisek vol tak, t eljesítményükben ( maximális me mória, C PU s ebesség, I/O eszközellátás) kül önböztek. Lehetett 360 -as r endszert vá sárolni adatfeldolgozáshoz, va gy tudományos számításokhoz is. Mellesleg ez volt az egyik elsõ gép, ami IC-ket (igaz, alacsony sûrûséggel) is tartalmazott. És mellesleg azt is megjegyzem, hogy a 360-as leszármazottai a késõbbi (egyre fejlettebb technológiákat használó - 370, 4300, 3080 és 3090-es rendszerek. A 360-as gé p ope rációs r endszer a z O S/360 ne vet vi selte. Ó riási m éretének, kom plexitásának oka: na gyon s zéles i gényeket ( adatfeldolgozás, t udományos s zámítások, s ok, vá ltozatos perifériakezelés, a HW fejlõdés mellett a kompatibilitás tartása) kellett

kielégíteni. Itt jelent me g a multiprogramozás. M íg a 7094 CPU-je, h a b efejezett eg y számítást, v árt az eredmény kivitelre, az újabb job betöltésre - ami tudományos számításoknál még elment, de adatfeldolgozásnál a engedhették meg. gyakori I/O m iatt v eszteséges l ett v olna -, a 3 60-asnál ez t n em A m egoldás a m emóriát partíciókra osztották, és a p artíciók m indegyikébe be töltöttek e gyegy j ob-ot. M ikor e gyikkel vé gzett, C PU-veszteség n élkül át kapcsolhatott eg y m ásik feldolgozásra: 1.1 ábra Memória partíciók Természetesen, m egoldották, hog y a pa rtíciókba be töltött j ob-ok n e zavarják e gymást hardveres védelem volt, hogy át ne címezhessenek. A másik alapfogalom is megjelent: a spooling (Simultaneous Peripheral Operation On Line). Ennek lényege: a job kötegek kártyaolvasói a rendszer diszkjeire kerültek (nem szalagra), és egy partíció ki ürülése esetén gyorsan be töltõdhettek a pa

rtícióra, k evesebb vol t a C PU veszteségidõ, ne m vol t s zükség m ár a s zalagokon va ló j ob-kötegek gyûjtésére, a s zalagok szállítására. Kialakult egy új adatstruktúra: a job pool A job pool job-jaiból választhat az az operátor, vagy az operációs rendszer egy-egy job-ot futásra. Persze, g ondok m aradtak: hog y ké szítsék e lõ a job-ok pr ogramjait: a zok m elyik pa rtícióba fussanak? F ix m éretû p artícióknál h a n em f érnek be, m égis cs ak v an veszteségidõ. H a az operátor nem jól szervez, kiürülhetnek a várakozó sorok. Válaszként h amarosan kialakult az idõosztásos multiprogramozása és a változó méretû partíciókkal mûködõ m emóriagazdálkodás. A z e lõbbiek: i dõszeleteket ka pnak az eg yes partíciókba b etöltött jo b-ok, l átszólag pá rhuzamosan f uthatnak (Time S haring, C PU-Switch, idõ ki osztás). E zzel e gy pa rtíciót f enntarthatunk a rra, ho gy v égezze a s pooling-ot U tóbbi nagy s

egítség: n em k ell e lõre e ldönteni a p artíciót. E gyre k ritikusabbá v ált az erõforrás kiosztás (resource allocation) és a védelem (protection). Újabb igény merült fel: az interaktivitás igénye. Kényelmetlen a b atch feldolgozás: várni az eredményekre, kis hiba nem javítható azonnal, stb. Legyen több száz felhasználót egyidejűleg kiszolgáló ké nyelmes r endszer! A ha rdver f ejlõdik: t erminál vona lnyalábolók (multiplexers) lehetõvé t eszik, hog y a pr ogramozók t ermináljairól ( eleinte í rógépszer ű eszközök, késõbb katódsugaras t erminálok) a dhatják m eg a J CL ut asításokat. E zekbõl f ejlõdtek ki a parancsnyelv-értelmezõk. A pr ogramozó-felhasználóknak on -line f ájl-rendszereket biztosíthatnak, a fájlok csoportokba (cluster, directory) rendezhetõk. Biztosítható a fájlokhoz a többszörös hozzáférés. De ne feledjük, ugyanekkor a szokásos kötegelt feldolgozás is megy, az is fontos.

Megjelenik a processz fogalom, kialakul a virtuális memória koncepció Fejlõdött a hardver: kialakulnak a "kis"gépek (DEC, PDP-1(1961), VAX-780(1978). Fejlõdtek az o perációs r endszerek: a M ULTICS ( ez e gy n agy gépre s ok i nteraktív felhasználót szolgált volna) és UNIX (a PDP-7-en!) ekkor alakul ki, ezek már álalános célú, multiprogramozású, idõosztásos rendszerek voltak. A m unkamegosztás i s f ejlõdött: va nnak f ejlesztõk ( elektromérnökök), ka rbantartók, hardveresek (elektromérnökök), rendszerprogramozók (az operációs rendszerrel foglalkoznak, fejlesztik, i llesztik s tb.), ope rátorok ( kezelik a r endszert), pr ogramozók é s f elhasználók ( az idõszak vé gére). A z ún na gygépeken köt egelt f eldolgozás f olyik: m unka ve zérlõ kártyaköteget ( Job C ontrol L anguage ká rtyák) á llít ö ssze é s a d á t az ope rátornak a programozó-felhasználó, a f orrásprogramokat m ár d iszken t árolják. A k

isgépeken t erminál elõtt ülnek, interaktív parancsnyelvet használnak. A p rogramozás-történethez m egjegyzzük: e gy s or imperatív és funkcionális programnyelv alakul ki ( Algol, P L/1, A PL, Lisp, Basic, P rolog , C s tb.), megjelenik a z e lsõ objektumorientált n yelv ( Smalltalk, 1972) , j ellemzi a z i dõszakot a z ún. szoftver krízis (Reducing the Machine Dependency, Increasing Program Correctness). 1.34 Negyedik generáció (1980-1990): Személyi számítógépek, LSI, VLSI (Reducing the Complexity) A t echnológia gyorsan f ejlõdött. A z LSI ( Large S cale Integration), k ésõbb a V LSI (Very Large S cale Integration) le hetõvé te tte, ho gy nagy m ennyiségben é s vi szonylag ol csón állítsanak elõ számítógépeket. Ez volt a személyi számítógépek (Personal Computer) hajnala A P C a rchitektúrája ol yan, m int a P DP11 ki sszámítógépé, á ra vi szont c sak a t öredéke! Nemcsak v állalatok, d e magánszemélyek i s vá sárolják.

M unkahelyeken: mindenki s zámára saját PC biztosítható. Következmény: • Visszaesés a védelemben, hiszen mindenki csak a saját rendszeréért felel! • Óriási az interaktivitás: mindenki parancsnyelveket tanul. • Felhasználóbarát felhasználói kapcsolattartók kellenek: ne kelljen "guru"-nak lennie a felhasználónak. • A PC játékokra is jó. Mindenki használja, mindenki "szakértõvé" válik Gond: • A gyenge védelem hozza a "vírusokat". • Óriási kavalkád. Hogy lesz itt egység? • Tévedések: C64 játékgép professzionális felhasználása. A s zemélyi s zámítógépek m ûködtetõ r endszerei el einte e gyfelhasználós és e gytaszkos jellegûek. Céljuk nem a teljesítménynövelés (a CPU és a perifériahasználatra vonatkoztatva), hanem a k ényelmes h asználat ( convenience) és a válaszképesség. E leinte e gy monitor és a BASIC értelmezõ volt csupán a PC mûködtetõ rendszere.

Az évtized végére: megjelenik a munkaállomás (Workstation), ami tulajdonképpen erõforrásgazdag s zemélyi gé p (Sun, H P/Apollo, I BM R S6000, D EC m unkaállomások, S GI munkaállomások s tb.), hálózatra köt ve, j ó grafikával, növe kvõ s zerepûek a hálózatok (networks) és a párhuzamos rendszerek (paralell systems). (Hermes, Linda, paralell C, Java) Ezek m iatt m ár f elmerült a s zükség i gazi o perációs r endszer f unkciókra: a m egnövelt védelemre ( a ví rusok, worms-ok e llen, a h álózatba k apcsolás mia tt); mu ltitasking-ra ( a grafikus felhasználói felülethez, a kényelemhez). (OOP: C++, Java) Az operációs rendszerek: • MS-DOS különbözõ verziói, igen nagy számban értékesítik. • Macintosh Apple operációs rendszere: az elsõ "ablakozó" felhasználói felülettel. • Unix s zármazékok ( SUN O S, S olaris, H P U nix, A IX, O SF, D EC U nix, I rix s tb.), Windows NT a munkaállomásokra. • OS2 és a Win

95 PC-kre. Végül: • Hálózati operációs rendszerek, • Osztott operációs rendszerek is jelentõsek. És lassan itt vagyunk a mában! Fontos évszámok, események 1941 Zuse Elketromechanikus kalkulátora, 64 szavas memória, 3 sec a szorzás 1944 MARK I, Elektromechanikus számítógép, Aiken 1945 ENIAC, Electrical Numerical Inegrator and Computer, Mauchly, Eckert 1948 Az elsõ tranzisztor, Bell Lab 1949 EDSAC, Turing, az elsõ szubrutinkönyvtár; UNIVAC I., az elsõ assambly nyelv 1951 EDVAC, Neumann csoportja 1952 1. kereskedelmi fordító (compiler); mikroprogramozás elõszür, Wilkes 1954 US Defense Dep. vásárol számítógépet: UNIVAC I-et (Harvard); FORTRAN, IBM; IBM Assembler; IBM 650, az 1. tömegben gyártott gép 1955 TRIDAC, az 1. Tranzisztort használó gép 1957 Megalakul a DEC; IPL (Information Processing Language) 1958 ALGOL58, ALGOrithmic Language; LISP, LIStProcessing Language 1959 COBOL, Common Business Oriented Language

1960 ALGOL60, Európában népszerû 1962 CTSS, Compatible Time Sharing System 1964 LAN, az 1. helyi hálózat; PL/1 és APL, IBM 1965 Control Data 6600, az 1. sikeres kereskedelmi forgalmú gép BASIC, Beginners All-purpose Symbolic instruction Code MULTICS, MIT: Simula: ARPANet 1966 1968 OS/360 THE, D ijkstra: B urroughs B 2500/3500 a z 1. k ereskedelmi f orgalomú g ép, a mi IC lapkat használ 1969 Laser printer 1970 Pascal; RC4000 kernel 1971 Intel mikroprocesszor lapka 1972 C nyelv; Smalltalk 1973 A Unix használata általános 1974 Xerox Alto, az 1. munkaállomás 1975 Az 1. PC, Apple, Radio Shack, Commodore PET 1976 MCP, multi-processing rendszer; SCOPE, multi-processing rendszer 1978 VAX 1979 3BSD Unix; Ada 1981 IBM PC 1982 Compaq, az 1. hordozható számítógép; Turbo Pascal, Modula2 1984 Apple Macintosh, grafikus felület; TrueBASIC; SunOS; PostScript 1986 C++ 1987 OS/2; X11 1988 NeXT, Unix munkaállomás, objektumorientált

grafikus felhasználói felület 1989 Motif szabvány 1990 MS Windows 3.0 1992 Solaris; Modula3 1993 Winows NT 1.4 Direkt futtatás a hardveren - működtető rendszer Használható a s zámítógép m ûködtetõ r endszer né lkül? E zt a ha sználati m ódot ne vezzük a hardveren való direkt futtatásnak. A válasz: tulajdonképpen igen, de csak a kis bit-szélességû mikrokontrollereknél szokásos ma már. Régebben természetesen ez a futtatási mód is megvolt Ekkor p ersze m inden f elelõsség a p rogramozóé! T eljes r észletességben i smernie k ell a hardvert, az utasításkészletet stb. És felmerül a további kérdés: hogyan programozható a gép? Hogyan " juttatjuk" be a pr ogramot a m emóriába? H ogyan i ndul e l a pr ogram? ( Rövid válaszok erre: külön berendezéseken programozzuk, "beégetjük" a programokat a memóriába, bekapcsolással indulhatnak a beégetett programok.) Egy ál talános cél ú s

zámítógéprendszer persze működtet õ s zoftver né lkül ne migen használható. Legalább egy monitor program kell hozzá A monitor kifejezés meglehetõsen túlterhelt. Használjuk mûködtetõ rendszer neveként, néha egy megjelenítõ neveként, a V AX/VMS e gy segédprogramjának is ez a n eve, és az e gyik processzek közötti kommunikációnak, processzek szinkronizációját biztosító mechanizmusnak is ez a neve. Ügyeljünk arra, hogy a monitor szó használatánál mindig a megfelelõ kategóriára gondoljunk! A monitor működtetõ program A monitor futtatható szubrutinok gyűjteménye, melyeket rendszerint a ROM-ban t árolnak (nehogy a felhasználó megsértse azokat). A m onitor r utinjai ké pesek karaktersorokat fogadni e gy konzol terminál billentyûzetérõl, ezeket a s orokat e gyszerû parancsként értelmezni, a p arancsokhoz r endelt e gyszerû funkciókat végrehajtani, és természetesen képesek a konzol terminál megjelenítõjére küldeni

karaktersorozatokat. A m onitort a gé p gyártója bi ztosítja. N éha ké pes ke zelni e gy-egy m ágneses há ttértárolón (diszken, kor ábban dob tárolón) k ialakított p rimitív f ájl r endszert. P éldául g yakori, h ogy jegyzék fogalom nélküli, ebbõl következõen hierarchia nélküli - egyszintû - folyamatos blokk elhelyezésû fájlrendszert: ebben a fájloknak van nevük, hosszuk. A nevet, hosszt a fájl kezdõ mezõiben t árolják. A f ájlokat a m onitor s zekvenciális vé gigolvasással betöltheti ( load) a memória a dott c ímétõl k ezdõdõen, e setleg a f ájlt a k onzol k épernyõjére ír hatja ( text dokumentum fájlokat), vagy irányíthatja egy nyomtató eszközre. A m onitor pa rancsai ha llatlanul eg yszerûek. R endszerint v annak m emória cel la t eszt és beállító pa rancsok ( examine mem-cím, set érték mem-cím), f ájl be töltõ, ki írató pa rancsok (load filenév mem-kezd-cím, type filenév stb.), és természetesen

"futtató" parancsok (go memcím, run mem-cím stb) Beláthatjuk, hogy már az examine/set/go parancshármassal is "programozható" a számítógép. Egy s or set-tel be írunk e gy p rogramrészletet ( persze t udni ke ll a g épi i nstrukciók bináris/oktális/hexa kódjait!), majd a go kezdõ-cím paranccsal lefuttatjuk a kis programot. Az eredményeket az examine paranccsal meg is nézhetjük. Még jobb az eset, ha van load/run parancspár is! Ekkor - rendszerint t esztprogramot - betölthetünk, ut ána e lindíthatjuk. S zerencsés e setben a betöltött p rogram ír ja a z e redményeit a konz olra, r osszabb e setben a z examine paranccsal nézegethetjük a teszt-eredményeket (már ha tudjuk, hova teszi azokat a program). Néha a mo nitor a z e ddig e mlített p arancsértelmezõ/végrehajtó r utinjai me llet ta rtalmaz néhány I/O r utint i s. E zek a nyomtatókezelést, a k onzol megjelenítõ é s a b illentyûzet kezelését, e setleg a dott me

mória ta rtomány le mentését e gy f ájlba ( adott f ájlnévvel a z egyszintû fájlrendszer elejére/végére) tehetik lehetõvé. A primitív I/O rutinok adott speciális címeken va nnak, és a " felhasználói" pr ogramokból hí vhatók e gy "ugrás a dott c ímre" instrukcióval. Ha úgy tetszik, ez már majdnem egy "I/O rendszer hívás" Minden modern operációs rendszer ebbõl a primitív monitor mûködtetõ rendszerbõl nõtt ki. Kérdés lehet: vannak-e manapság még monitorok? A válasz: igen. A gyártók e lsõsorban a ha rdveres m érnököknek s zánva a m onitort m a i s gyárt í gy számítógépeket. Sokszor a gép bekapcsolásakor nem egy operációs rendszer töltõdik, hanem egy monitor i ndul. Esetleg ka pcsolókkal (CMOS R AM-ban b eállított é rtékekkel) szabályozzák, O S t öltõdjön, va gy m onitor i nduljon. A m onitort ki zárólag t esztelésre használják, a normális üzemmódhoz manapság biztos egy valódi

operációs rendszert fognak betölteni. 1.5 Operációs rendszerek osztályozása Több s zempont s zerint i s os ztályozhatjuk a z ope rációs r endszereket. A l egfontosabb osztályozási szempontok: • az operációs rendszer alatti hardver "mérete" szerinti osztályozás szerint: • mikroszámítógépek operációs rendszerei; • • kisszámítógépek (esetleg munkaállomások) operációs rendszerei ; • nagygépek (Main Frame Computers, Super Computers) operációs rendszerei. A kapcsolattartás típusa szerinti osztályozás szerint: • kötegelt feldolgozású operációs rendszerek, vezérlõkártyás kapcsolattartással; • interaktív operációs rendszerek. A következõ osztályozási szempontok még fontosabbak, ezeket ezért részletezzük is: • cél szerinti osztályozás; • a p rocessz k ezelés, a f elhasználók s záma s zerinti, a C PU i dõ k iosztása s zerinti osztályozás; • a memóriakezelés megoldása

szerinti osztályozás; • az I/O koncepciók, a fájl rendszer kialakítása szerinti osztályozás. 1.51 Operációs rendszerek osztályai cél szerint Megkülönböztethetünk általános célú és speciális célú operációs rendszereket. Az ál talános cél ú o perációs r endszerek t öbb c élúak: egyidejûleg használjuk a zokat programfejlesztésre, al kalmazások f uttatására, adatbázisok l ekérdezésére, k ommunikációra stb. A speciális célú rendszerek osztálya igen gazdag lehet: vannak folyamatvezérlésre beállított, vannak t ranzakció f eldolgozásra i mplementált s tb. r endszerek, küz üs j ellemzõjük, hogy egyetlen célt szolgálnak. 1.52 Processz kezelés, idõkiosztás, felhasználó szám szerinti osztályok A t öbb, vá ltozó f eladatszétosztású CPU-val r endelkezõ g épeket a z ope rációs r endszerükkel együtt multi processing rendszereknek szokás nevezni. Az egy processzoros gépek mûködtetõ rendszere lehet single

tasking (egyidõben egy processz lehetséges), vagy multi tasking rendszer (kvázi párhuzamosságban több processz fut). Az e gyidejû f elhasználók s záma s zerint be szélhetünk egyfelhasználós (single user) rendszerekrõl és többfelhasználós (multi user) rendszerekrõl. Az utóbbiak mindenképp multi tasking vagy multi processing rendszerek k ellenek, h ogy legyenek, az egyfelhasználós rendszer lehet single tasking is. A C PU i dõkiosztása l ehet szekvenciális (egy p rocessz t eljes f eldolgozása u tán k apcsol a másikra), kooperatív-event polling rendszerû, megszakítás vezérelt (interrupt driven), va gy beavatkozó-megszakításvezérelt (preemptiv-interrupt driven). Az event polling rendszer m ár l ehet t öbbfelhasználós/többfeladatos r endszer. A pr ocesszek között e lõre be állított, k örkörös s orrend v an. A z a pr ocessz l esz a ktív, a melyik eseményt (billentyû lenyomás, ablakba belépés stb.) kap, és addig aktív, amíg új

esemény aktívvá nem tesz egy másik processzt. A kooperatív rendszerekben egy-egy processz saját elhatározásából is lemondhat a CPU-ról, átadhatja a vezérlést a soron következõ processznek. A megszakítás vezérelt rendszerekben m inden I/O m egszakítás be következésekor újraértékelik a processzek prioritási állapotait, és a legmagasabb prioritású kapja a CPU-t. Ha nincs I/O megszakítás, a futó processz nem mond le önszántából a CPU-ról. A beavatkozó rendszerû idõkiosztásnál n emcsak a z I/O me gszakításoknál é rtékelik ú jra a prioritási á llapotokat, ha nem bi zonyos ór a m egszakításoknál i s. E lveszik a C PU-t a f utó processztõl akkor is, ha az továbbra is futásra kész állapotban van, ha találnak nála magasabb prioritásút. A z id õkiosztási a lgoritmus s zerint e r endszeren b elül me gkülönböztethetünk klasszikus idõosztásos (time sharing) és valós idejû (real time) rendszereket, az ut óbbiak az

igéretvezérelt idõosztású rendszerek egy alrendszerét képezik. Jellemezzünk néhány ismert operációs rendszert! MS DOS: s zemélyi s zámítógépekre ál talános c élú, eg yfelhasználós, e gyfeladatos ( a T SRTerminate a nd S tay R esident pr ogramokkal, i lletve a system rendszerhívással t öbbfeladatos ugyan, d e e gyidõben csak e gy pr ocessz l ehet a ktív), e bbõl köve tkezõen s zekvenciális idõosztású operációs rendszer. MS Windows: általános célú, egyfelhasználós, többfeladatos rendszer. Sokan, köztük magam is, ne m s zívesen ne vezik i gazi ope rációs rendszernek. Az M S D OS f ölé é pülõ f elhasználói kapcsolattartó igazán, igaz, kooperatív-event polling-gal többfeladatossá teszi a DOS-t. OS/2: á ltalános c élú, e gyfelhasználós, t öbbfeladatos r endszer. Igazi ope rációs r endszer: idõkiosztása be avatkozó-megszakításvezérelt, s õt, ha ngolható é s h asználható va lós i dejû rendszernek. ( Irodalom

itt, ha még megvan) Windows NT: általános célú (kliens és s zerver i s), t öbbfelhasználós, t öbbfeladatos rendszer (multi-processing). Preemptive-interrupt driven az idõkiosztása Minden taszk védett Win 95: e gyprocesszoros, á ltalános c élú ( Home, P ersonal), Intel pl atformú, t öbbfeladatos, beavatkozó-megszakításvezérelt, 32 bites alkalmazásokat is kezelõ rendszer. VAX/VMS: k is- és mikrogépek ál talános cél ú ( de s peciális cél ra h angolható), többfelhasználós, t öbbfeladatos, s õt, m ulti pr ocessing rendszere. Idõkiosztása ha ngolható beavatkozó i dõosztásos r endszernek, v agy va lós i dejû r endszernek i s. T anszékünkön c sak egyprocesszoros V AX-ok va nnak, é s k lasszikus id õosztásos V MS imp lementációkat használunk. Unix rendszerek: á ltalános c élú, t öbbfelhasználós, t öbbfeladatos r endszerek. A kor szerû Unix-ok képesek t öbbproceszoros rendszereket mûködtetni, t ehát m ulti processing j

ellegûek (nálunk pl . a r égi zeus 4 por ocesszoros, ope rációs r endszere a z Irix multiprocessingben mûködik, de ugyanaz az Irix a kis Indigókat pusztán multi taskinggal is tudja mûködtetni). A klasszikus Unix-ok preemtive time sharing idõkiosztásúak. Fejlesztik a valós idejû Unix alapú rendszereket ( ilyen pl . a z O S9, a Q NX) A m ikro- és ki sgépek, a m unkaállomások, s õt, a nagygépek (szerverek) is m ûködtethetõk U nix s zármazékokkal. K apcsolattartóik s zerint minden vá ltozat ( interaktív pa rancsnyelvi, i nteraktív G UI, köt egelt pa rancs-feldolgozásos kapcsolattartás) elõfordul. 1.53 Memória menedzselés szerinti osztályozás Alapvetõen megkülönböztetünk valós címzésû és virtuális címzésû rendszereket. A v alós címzésû r endszereken b elül a fix, v agy változó partíciókra osztott me móriakezelés lehetséges (ezeknek további aleseteit lásd majd késõbb). A v irtuális cí mzésû r endszerk al osztályai a

klasszikus ki/be söprõ (swapping in/out) rendszerek, a kl asszikus igény szerinti ki/be lapozó (demand paging) rendszerek és a ki/be söprõ és lapozó (swapping and paging) rendszerek. MS DOS: valós címzésû, változó partíciókra osztó rendszer. Windows NT: virtuális címzésû lapozó rendszer. VAX/VMS: virtuális címzésû, lapozó és söprõ rendszer. Unix: vi rtuális címzésû rendszer. Az e gyszerûbb (és kor ai) Unix-ok ki /be s öprõ r endszerek, ma már ki/be söprõ és lapozó a memóriakezelés. 1.54 Az I/O koncepciók, a fájlrendszer megvalósítása szerinti osztályozás Az os ztályozási s zempont ne m e lég pont os, s okféle m egoldást t alálunk a z e gyes O S-ek implementációiban. M ondhatjuk, va nnak ope rációs r endszerek, m elyek e gy s ajátos fájlrendszert képesek kezelni (pl. az MS-DOS a FAT-os fájlrendszert), és vannak, melyekhez tartozik ugyan saját fájlrendszer, de más koncepciójú fájlrendszereket is kezelnek (pl. a

Linux meglehetõsen s ok fájlrendszert i smer). M egjegyezzük, hogy a m ai ope rációs r endszerek a fájlrendszerük kül sõ m egjelenítési f ormáiban mind hi erarchikus f aszerkezetû s truktúrát biztosítanak a jegyzékfogalom szülõ-gyermek reláció megvalósításával. Szûkíthetjük i s a s zempontokat: c sakis a f ájlrendszer i mplementációjában i gen f ontos ké t megoldandó feladat koncepciója szerint osztályozzuk magukat a fájlrendszereket. A megoldandó feladatok (amik lehetõséget adnak az osztályozásra): 1. Hogyan rendelik az OS-ek a fájlnévhez a fájl blokkjait Már n em h asznált m egoldás a folyamatos allokáció. H asználatos vi szont a z indextáblás hozzárendelés. A Un ix-ok j ellegzetes m ódszere a z ún i-listás hozzárendelés. E gyes fájlrendszerekben kiterjedéseket (extents) - amik f olyamatos a llokációjú b lokkok e gysége rendelnek a fájlnevekhez. 2. Hogyan kezelik az OS-ek a szabad blokkokat Használatos m

egoldás a bit-térképek vagy foglaltsági térképek alkalmazása. A t érkép az eszközön lehet egyetlen folyamatos terület, de lehet megosztott, több darabból álló is. Másik, szintén gyakori implementációban láncolt listán tartják nyilván a szabad blokkokat. MS DOS: Jellegzetes a D OS FAT (File Allocation Table) táblás megoldása, ami a f enti két feladatot egyben megoldja. A FAT tábla egyszerre foglaltsági térkép és indextábla Windows NT: ismeri a FAT fájlrendszert, van saját NTFS és CDFS fájlrendszere. VAX/VMS: A f ájl b lokkok a llokációja in dextábla s egítségével, a f oglatság b it té rképpel megoldott. Unix: A fájl blokkok hozzárendelés az említett i-listán található i-bögök segítségével történik, a s zabad bl okkok m enedzselése a superblock-ból ki induló szabad blokkok láncolt listája segítségével me goldott. Az e gyes U nix me gvalósításoknak le het s aját fájlrendszere is , és ismerhetnek m ás f

ájlrendszereket i s ( Pl. a Linux s aját f ájlrendszere az e xt2 f ájlrendszer, d e kezelni tudja a FAT-os, a klasszikus Unix-os stb. fájlrendszereket is 1.6 OS struktúrák Már láttuk, mi az operációs rendszer. Az korábban is láttuk, kívülrõl hogy látszik: biztosít a felhasználónak egy szimbolikus nevekkel kezelhetõ eszköz- és fájlrendszert, láthatunk benne processzeket, l átunk f elhasználókat, va n e gy p rogramozható bur ok, va gy egy könn yen kezelhetõ grafikus felhasználói kapcsolattartónk, kapcsolatot és ül ést kell l étesítenünk, hog y használhassuk. Az az illúziónk, hogy a fájloknak a fájlrendszerben helyük és méretük van, a processzeknek pedig életük van. Milyen az operációs rendszer belülrõl? Milyen szempontok szerint nézhetjük a struktúrákat? A nézõpontok: 1. Milyen szolgáltatásokat biztosít az OS? Milyen funkcionális részei vannak? 2. Milyen felületeket (interface) ad a felhasználóknak, a

programozóknak? 3. Komponenseit hogy állítják elõ, köztük milyen interfészek vannak? ad 1. A szolgáltatások szerinti komponensek (funkcionális struktúra) • Processz (taszk, fonál) menedzsment komponensek; • A kreációt és terminálódást biztosító funkciók, • processz kontroll és ütemezési funkciók • állapotnyilvántartás, • CPU ütemezés, • szinkronizációs m echanizmusok, be leértve e köl csönös ki zárási mechanizmusokat is, • • Memória menedzselõ komponensek; • Memóriahasználat nyilvántartása, • Memória allokálás/felszabadítás, • Címleképzés (mapping) segítése, • • processzközti kommunikációs mechanizmusok. közben ki/besöprés vagy lapozás. Másodlagos tároló menedzsmentje, • szabad terület menedzselése, • blokk allokáció, • diszk blokk scheduling; • • I/O menedzsment komponensei, • bufferezés, • device driver interface elemek, • speciális

driver-ek; Fájlrendszert megvalósító és menedzselõ komponensek • Jegyzékstruktúra me gvalósítás ( directory imp lementáció, f ájl a ttribútumok rögzítése), • • Blokkhozzárendelési módszerek, • Fájlok/jegyzékek kreálása, törlése, írása, olvasása, • Fájlrendszert létrehozó, használatbavevõ, helyreállító segédprogramok, • mentések és visszaállítások segédprogramjai. Védelmi kom ponensek ( néha "beépítve" a ze gyébb f unkciókba, né ha megkülönböztethetõ komponensként szerepel) • Networking, hálózatkezelõ komponensek (néha beleértik az I/O menedzsmentbe) • Felhasználói k apcsolattartó r endszer ( CLIs) (némely es etben n em i s r észe a kernelnek), • parancsértelmezõ, • GUI. ad 2. Interfészek a felhasználóknak, programozóknak Ez a s truktúra a funkcionális s truktúrához k özeli. Itt is azt n ézzük, mil yen s zolgáltatásokat biztosít a ke rnel, d e o ly

m ódon, ho gy m ilyen a f elület a s zolgáltatás ké relemhez. A szolgáltatási felületeknek három nagy csoportja van: • Rendszerhívások osztályai, rendszerhívások • A pr ogramozó f elhasználó m ilyen A PI hí vásokat pr ogramozhat. ( Unix-oknál lehet SVID, BSD vagy POSIX szabvány) • Rendszerprogramok, segédprogramok (utilities) osztályai • "Szabványosított" a z ö sszetettebb s zolgáltatásokat b iztosító s egédprogramok készlete is. • Kapcsolattartók (CLIs). ad 3. Implementációs struktúrák: • Egyszerû, monolitikus rendszer; • Réteges rendszer; • Virtuális gépek; • Kliens-szerver modell; • Vegyes szerkezetek. Nézzünk m eg né hány l ehetséges s truktúrát! A zt i s l áttuk m ár, ho gy a z operációs rendszer mint egy réteg, elválaszt a hardver részletektõl. Valóban, az operációs rendszer rendszemagja (kernel) elválasztó réteg. Mi most éppen arra vagyunk kíváncsiak, milyen

szerkezetû lehet a rendszermag. 1.61 Monolitikus rendszer Az a struktúra, mikor nincs is struktúra (1.2 ábra) 1.2 ábra Monolitikus struktúra A mo nolitikus r endszer ma gja n évvel e llátott szolgáltató eljárások (service rutins) gyüjteménye, melyek hívhatók • a f elhasználói pr ogramból ( processzbõl) úg ynevezett rendszer hívással (kernel call, system call), vagy • egy másik szolgáltató rutinból (call). A két hívási mód megkülönböztetésének vannak okai: • A kernel call kívülrõl e gyszerû függvény- vagy el járáshívásnak t ûnik: m egadjuk a szolgltató r utin n evét és ak tuális p aramétereit. V alójában ez n emcsak e gyszerû függvény- vagy eljáráshívás p araméter át adással, h anem e gyben trap: a pr ocesszor felhasználói módból kernel módra vált. (A trap fogalmat késõbb részletezzük) • Monolitikus r endszerben a ke rnel s zolgáltató r utinjai e gymást kor látlanul hí vhatják. Ekkor m

ár ne m s zükséges a m ódváltás, hi szen a ke rnelen b elõli kódot a pr ocesszor kernel módban hajtja végre. Paraméterátadás természetesen szükséges lehet A szolgáltató rutinok természetesen adnak valamilyen szolgáltatást: kezelik a hardvert. A s zolgáltató r utinokból a vi sszatérések c sak a bban kül önböznek, hog y felhasználói programba való visszatérésnél megtörténik a futási mód visszaváltása felhasználói módra. A m onolitikus r endszer r utinjait a ssembly, e setleg m agas s zintû n yelven í rják. E zeket lefordítják ( compilálják) é s ö sszeszerkesztik ( linkelik) e gyetlen b etölthetõ p rogramba, lementik egy fájlba. Ez a fájl a rendszerindításkor betöltõdik és a kernel ott áll szolgáltatásra készen. Ha na gyon a karjuk, a m onolitikus r endszerek is s trukturálhatók, r étegezhetõk. A l egfelsõ réteg lehet egy diszpécser rutin, ami a trap-et végrehajtja, a hívás paraméterit átveszi, esetleg

ellenõrzi, v égül át adja a v ezérlést és a p araméterket az al atta l évõ rétegbe s zervezett szolgáltató e ljárásnak. Ebbe a r étegbe a z ö sszes k ernelhívással me gszólítható s zolgáltató rutint képzeljük: ez a második rétege a kernelnek. A szolgáltató rutin elvégzi a szolgáltatást, szükség esetén egy, harmadik rétegbe szervezett segéd-eljárást is hívhat. A harmadik rétegbe szervezett s egéd-eljárások s egítik a s zolgáltatás b iztosítását. T ermészetesen, a r étegek programjait meg kell írni, le kell fordítani, és össze kell szerkeszteni: itt lehet választani, hogy egy betölthetõ p rogram fájlba s zerkesztjük a z ös szes r éteg rutinjait, va gy külön be tölthetõ fájlba az elsõ és második, illetve másik fájlba a harmadik réteg rutinjait. Ezzel eljutottunk a réteges struktúrájú OS kernelekhez. 1.62 Réteges struktúrájú OS-ek Tipikus pé lda e rre a D ijkstra pr ofesszor é s ha llgatói á ltal ké

szített T HE ne vû ope rációs rendszer (1968). A THE egyszerû kötegelt feldolgozási rendszerû operációs rendszer volt A rendszernek 6 rétege volt: 5 Operátor Operátor 4 Felhasználói programok Független processzek 3 I/O menedzsment Virtuális I/O eszközök 2 Operátor-processz kommunikáció Virtuális operátor konzolok 1 Memória-dob menedzsment Virtuális szegmentált memória 0 Processzor allokálás, multiprogramozás, szinkronizáció Virtuális CPU-k 1.3 ábra A THE rétegei Mi is a rétegezés lényeges elõnye? • Egy réteg magasabb szintû operációkat biztosít a felette lévõ számára és • elrejti az alatta lévõ részleteket. Ugyanakkor jól meghatározott interfészek vannak közöttük. A 0. réteg kiosztja a CPU-t a processzeknek, kapcsolja a CPU-t köztük E réteg felett egy-egy processz elõl el van rejtve, hogy más processzek is vannak. Az 1. réteg feladata: e gy-egy p rocessz s zámára h elyet b iztosít r észben

a f õ m emóriában, részben a dobtáron. Igény esetén lapokat mozgat a dobtár és a fõ memória között E r éteg f elett e gy pr ocessz ne m ke ll t örõdjön, va jon kódj a-adata a m emóriában van-e, kezelheti teljes címtartományát. A 2. réteg feladata: kommunikációt biztosít egy-egy processz és az operátor konzol terminál között. Felette: minden processz úgy képzeli, van saját konzolja. A 3. réteg feladata: I/0 kezelés, bufferezés minden processz számára Felette: e gy pr ocessz a bsztrakt I/O e szközöket ké pzel m agának, ne m ke ll t örõdjön a különbözõségekkel. A 4. rétegben találhatók a felhasználói programok Nem nem kell aggódniuk a CPU kiosztás, a m emóriakezelés, a k onzollal v aló k ommunikáció és a I/O eszközök menedzselése m iatt. Több program is lehet e rétegben. Az 5. r étegben va n a z e gyetlen ope rátor p rocessz Látja m aga al att a f elhasználói programokat. Indíthatja, lelõheti õket A rétegek

közötti interfészek explicit-, illetve könyvtár függvény hívások. A THE rétegezettsége csak egy tervezési cél volt: végül is összelinkelték egyetlen betülthetõ program fájlba. A THE oktatási célú volt. Hasonló réteges felépítésû, és már nemcsak oktatási célú rendszer volt a MULTICS (Tannenbaum, AT&T, MIT). A M ULTICS-ban a r étegek konc entrikus kö röknek ké pzelhetõk. A rétegek köz ötti i nterfész explcit-, vagy könyvtár függvényhívások; mindegyike egy trap egyben: szigorú ellenõrzéssel, vajon j ogos-e a h ívás. A p rogramtechnikailag is r éteges a M ULTICS: mindegyik gyûrûje önállóan betölthetõ program. A r étegezési k oncepciót a k orszerû o perációs r endszerek m a m ár t ermészetszerûleg használják. E gyik n yilvánvaló m egvalósítása a V irtuális F ájlrendszer konc epció, va gy a dinamikusan l inkelt f utásideji kön yvtári r utinok ( DLLs) konc epciója. E nnél e gy-egy szolgáltatási f

unkciót bi ztosító r utin ne mcsak e gyszerûen öná llóan be tölthetõ kom ponens, hanem dinamikus a betöltés: nem feltétlenül a rendszer startup során töltõdik a rutin, hanem csak akkor, amikor szükség van rá, azaz dinamikusan. 1.63 Virtuális gépek (Virtual Machines) Tipikus pé lda e rre a z o perációs rendszer s truktúrára i s v an, ez az IBM V M/370 r endszere (1970). (Wagner György dolgozott ilyenen hallgató korában!) A ha tvanas é vekben ki bocsátott O S/360 r endszer köt egelt f eldolgozási r endszer vol t. A felhasználói i gényelték volna a z i dõosztást, de a hi vatalosan fejlesztett IBM i dõosztásos rendszer, a T SS/360 ki bocsátása ké sett, a mikor ké sz l ett, ki derült, hogy t úl na gy é s l assú. Közben e gy f ejlesztõ c soport, IBMs S cientific C enter, C ambridge, M A, e gy r adikálisan különbözõ m egoldással r ukkolt e lõ, a mit a z I BM e l i s f ogadott. E z v olt a V irtual 3 70 koncepció: a VM/370. Azon az

egyszerû elgondoláson alapult, hogy egy idõosztásos rendszertõl elvárjuk: (1) biztosítsa a multiprogramozást, (2) b iztosítson e gy k iterjesztett g épet, a minek kényelmesebb a k ezelés, min t e gy valós gépnek. A két követelményt a VM/370 rendszer teljesen szétválasztva biztosítja. A r endszer l elke a V irtual M achine M onitor, e z f ut a pus zta ha rdveren, úg y bi ztosítja a multiprogramozást, hogy több virtuális gépet emulál a felette lévõ réteg számára. Az emulált gépek azonban nem e gyszerû ki terjesztett gépek, hanem pont os m ásolatuk valódi gépeknek, beleértve a k ernel/user módváltási mechanizmust, az I/O eszközöket, a megszakításrendszert stb., s zóval mindent, a mi e gy va lódi gé pen va n M inden e mulált g ép bi t szinten a zonos a z igazi h ardverrel, ez ért a ztán f uttatható r ajta b ármely o lyan o perációs r endszer, am i az i gazi gépen f uttaható. Így is volt, a V MM á ltal e mulált g épen f

uttattak O S/360 r endszert, C MS rendszert stb. (14 ábra) Hogy m egértsük: a z O S/360 f ix, va gy v áltozó m emóriapartíciókkal dol gozó, köt gelt rendszerû O S, a z IBM 360 g épre f ejlesztették J CL ( Job C ontrol L anguage) n yelvvel vezérelhetõ. A C MS ( Conversational M onitor S ystem) e gy egyfelhasználós i nteraktív r endszer, f uthatott 360-as, 370-es gépeken, kezelte ennek memóriáját, háttértárolóit. Az eredmény í gy é rtékelhetjük: a multiprogramozás megvalósult, de teljesen szeparáltan! A VM/370 nem a s zokásos operációs rendszer funkciókat adja, hanem gépeket emulál. Valódi operációs rendszer is kell a VM/370 fölé egy magasabb rétegben. 1.4 ábra A VM/370 rendszer Virtuális gép szerkezetû a MACH mikrokernele is (lásd késõbb!) A mikrokernel koncepció is egyfajta vi rtuális gé p k oncepció: a ha rdver kül önbségeket "elrejtõ" m ikrokernel vi rtuális gépként szerepel az OS "szokásos"

kernele számára. A virtuális gép koncepció természetszerûleg vezet át kliens-szerver modellhez: mikrokernel, a "virtuális gép" szolgáltatást biztosít a kliensekként szereplõ funkcionális elemek számára. 1.64 A kliens-szerver modell Modern operációs rendszerek fejlesztési trendje, hogy minél kisebb legyen a kernel, hogy az operációs r endszer m inél t öbb f unkcióját t együk magasabb r étegekbe. Lehetõleg m inél t öbb OS f unkció ke rüljön a f elhasználói m ódú, l egfelsõ r étegbe. A t örekvés a kl iens-szerver architektúrával közelíthetõ. Az e lgondolás l ényege, hog y a f elhasználói pr ocesszek - mint kliens processzek üzenetküldéssel i gényeljenek s zolgáltatást a szolgáltató processzektõl. A s zolgáltató processzek pr ogramjai ö nállóan l inkelhetõk, be töltõdhetnek a r endszer egész é letére, va gy idõlegesen ( daemon pr ocesszek), f uthatnak ke rnel, de a kár f elhasználói m ódban i s. A

szolgáltatók, m iután elkészültek a m unkájukkal, üzenetküldéssel válaszoljanak. A m odell az alábbi ábrán látható. 1.5 ábra A kliens szerver modell Itt a kernel csak a kommunikációt ( és az idõosztást) biztosítja. Tisztán i lyet s ohasem va lósítottak m eg ( legalábbis ne m t udok róla!), d e bi zonyos szolgáltatásokat tübb operációs rendszerben ezzel a struktúrával valósítanak meg, és ebbõl a gondolatból fejlõdött "distributed system" fogalom: hálózati operációs rendszer-szolgáltatások természetes szerkezete ez. 1.6 ábra Osztott rendszer 1.7 A VAX/VMS, a Unix és a Windows NT struktúrája Esettanulmányként n ézzük m eg h árom -elterjedt - operációs r endszer s truktúráját. H árom ábrán három, különbözõ ábrázolási móddal mutatjuk be a struktúrákat. 1.71 A VAX/VMS réteges struktúrája Jellegzetes a V AX/VMS g yûrûs, r éteges f elépitése. T udni ke ll ho zzá, ho gy a V AX C PU 4,

különbözõ pr ivilegizálságú m ódban f uthat, m elybõl l egmagasabb pr ivilegizáltságú, legmagasabb rangú a kernel mód. A futási módok növekvõ ranggal az 17 ábrán láthatók Az át térés a m agasabb r angú f utási m ódra e gy-egy trap mechanizmussal s zabályozottan történhet. A z e gyre m agasabb r angú futási m ódokban e gyre n agyobb a végrehajtható gépi utasításhalmax, és egyre szélesebb a címtartomány. Jel Futási mód neve Rang U User mode 4 S Supervisor mode 3 E Executive mode 2 K Kernel mode 1 1.7 ábra A VAX processzor futási módjai Gyakorló f eladatként i smerkedjenek m eg a V AX/VMS M ONITOR s egédprogramjával. A MONITOR s egédprogram az o perációs r endszer t eljesítményérõl, állapotairól k észít statisztikákat. ( A M ONITOR h asználatára lá sd a V AX/VMS M onitor U tility R eference Manual dokumentumot.) Meglehetõsen sok teljesítményosztály mintavételezhetõ, figyelhetõ a segédprogrammal,

többek között az egyes processzor futási módokban eltöltött idõ is. Hívják a MONITOR-t a következõ parancssorral: $ MONITOR MODES A s egédprogram ad ott g yüjtési és m egjelenítési f rekvenciával ( az al apértelmezések megváltoztathatók a / INTERVAL= seconds. é s a / VIEWING TIME= seconds opc iókkal) százalékos m egosztásban mutatja m eg a p rocesszor á ltal a kül önbözõ f utási m ódokban eltöltött idõt. A megjelenített sorok értelmezése: Interrupt Stack A m egszakítási ve remben e ltöltött i dõ. E z va lójában ke rnel m ódú futás Fõleg a bufferelt I/O kérések kiszolgálását jellemzi. MP Synchronisation Az a z i dõ, a mit a pr ocesszorok s zinkronizálására f ordítanak. C sak többprocesszoros rendszeren van értelme. Kernel Mode A k ernel módban e ltöltött id õ, le számítva a me gszakítási v eremben eltöltött idõt, hiszen azt már elõbb kimutattuk. Executive Mode Executive m ódban eltöltött i dõ. J

egyezzük m eg, ho gy executive m ódban fõleg az RMS rutinok futnak, tehát ezt jellemzi ez a sor. Supervisor Mode A s upervisor m ódban e ltöltött i dõ. A D CL parancsértelmezõ kódj a f ut ebben a módban. Compatibility Mode A V MS ope rációs r endszerhez m egvásárolható s zoftvertermék segítségével V MS al att f uttathatók a D EC cé g k orábbi o perációs r endszerére, az R SX-11-re kifejlesztett pr ogramok. A c ompatiblity m ód t ulajdonképpen t ehát ne m pr ocesszor f utási módra ut al, h anem azt m utatja, hog y az ún. C ompatiblity M ode Image (RSX-11 f uttatható program) instrukcióival mennyi idõt tölt el a CPU. Idle Time A processzor üres ideje. A VAX/VMS struktúráját az 1.8 ábrán mutajuk be Elemezzük az ábrát! Az ábrán fel vannak tüntetve az egyes rétegekbe tartozó komponensek és a r éteghez t arozó f utási m ódok. A g yûrûs r étegek kom ponensei ha sználhatják a be lsõbb rétegek szolgáltatásait, futási mód váltó

trap instrukciókat tartalmazó hívásokkal. A U-val jelölt felhasználói módú, legkülsõbb rétegben futnak a programfejlesztõ eszközök, a segédprogramok és az alkalmazások (a hozzájuk szerkesztett futásideji könyvtári rutinokkal együtt). Az S-sel jelölt supervisor módú rétegben a DCL (Digital Command Language Interpreter) kódja fut. Emlékezzünk arra, hogy a VAX/VMS-hez a DCL értelmezõ szorosan kapcsolódik, s bá r ha sználhatnánk m ás bur ok-programot i s ( ami U m ódban f uthat), ne m ha gyható ki a DCL, nem hagyható el ez a réteg. 18 ábra A VAX/VMS struktúrája: Executive módban futnak az RMS (Record M anagement Services) rutinjai. Ezek segítik az alkalmazásokat a f ájlok és a f ájlok t artalmának kezelésében. Bár k ezelik a k arakterorientált eszközöket i s, a z e lõnyük f õleg a t ömegtárolókra s zervezett f ájlok ke zelésében érvényesíthetõ. V áltozatos diszk f ájl s zervezési m ódokat, r ekord formátumokat

é s r ekord elérési m ódokat b iztosít: t ámogatja a s oros, r elatív és i ndexelt s zervezést, a f ix és v áltozó hosszú rekordformátumokat, és lehetõvé teszi bármelyik szervezési módnál a soros elérést, a megfelelõ s zervezéseknél a d irekt el érést ( kulcs s zerinti el érést az i ndexelet s zervezésnél, relatív r ekord s zám s zerinti el érést a r elatív s zervezésnél. A z R MS i nterpretálja a rekordstruktúrát, m íg a f ájlok t ömegtárolókon v aló e lhelyezkedéséért a z a datmenedzsment egy másik szintjéhez tartozó komponensek felelnek: a szolgáltató processzek (ACP: Ancillary Control P rocesses), v agy az X QP ( Extended Q IO P rocessor) pr ocesszor. A z R MS r utinok hívásai mind a futási idejû könyvtárakban található szokásos I/O függvényekkel, eljárásokkal történhet (ekkor a trap-et a könyvtári rutin kiváltja), mind pedig közvetlen RMS rutin hívással (lásd a VMS Record Management Services Manual

dokumentumot!). A K jelû réteg az interfész a k ernelhez (System Services), a réteg rutinjai és a r étegen belüli operációs rendszer komponensek kernel módú futást igényelnek. E réteg "szolgáltatása" csak annyi, ho gy i nterakciókat va lósít m eg a l ényegi ke rnel kom ponenseivel ( kivéve a tulajdonképpen a kernelhez tartozó I/O alrendszernek az eszközfüggetlen szolgáltatásait, mert azok tényleg szolgáltatnak is). A lényegi kernelben az ábra szerint négy, valójában öt elem található. Legbelül lá thatjuk a z operációs rendszer adattábláit (Systemwide P rotected D ata Structures). E zek t ermészetesen n em s zolgáltató r utinok E zeket a t ovábbi kom ponensek közösen használják, ezek egy bizonyos interfészt már biztosítanak közöttük. Az I/O alrendszer (I/O S ubsystem) t artalmazza az es zközmeghajtó s zoftvereket ( Device Drivers) és a hoz zájuktartozó a datsruktúrákat. T ulajdonképpen az I /O al rendszerhez

tartoznak, de az E rétegben vannak az eszközfüggetlen rutinok (legfontosabb közülük a $QIO rutin). A memória menedzselõ alrendszer (Memory Management) l egfontosabb r észe a laphiba kezelõ (Pager, vagy Page Fault Handler), ami a VMS virtuális memória-rendszer támogatását valósítja meg. Másik fontos eleme a ki/be söprõ (Swapper), ami a fizikai memória még jobb kihasználását b iztosítja. A h asznált ad atstruktúrák: a Laptáblák ( Page M ap T ables) és a lapkeret adatbázis ( Page F rame Number Database). A z al rendszer h ez az i nterfész az executive r éteg s zolgáltató r utinjai, a mik le hetõvé te szik e gy-egy processz vi rtuális címtartományának n övelését, cs ökkentését, i lletve a cí mtartomány egy r észének l eképzését egy fájlba. A folyamatkezelõ és idõzítõ alrendszer (Process an d T ime M enegement) e gyik el eme (Scheduler) választja ki futásra a "legjobb" processzt, mialatt elveszi a CPU-t az éppen

futó processztõl. U gyanez k ezeli az i dõszolgáltatásokat, az i dõzítési r endszer s zolgáltatásait A processz v ezérlõ r észe ( Process C ontrol) s egíti a p rocesszek k reálását, a p rocesszek szinkronizációját, b izonyos pr ocesszek köz ti k ommunikációkat. E z a z a lrendszer f elelõ elsõsorban az idõzítési adattáblákért. Az 1.8 á brán ne m l átható a k ernel t ovábbi a lrendszere, a vegyes szolgáltatások (Miscellaneous S ervices) r utinjainak csoportja. Nem t eljes a f elsorolás, d e i de t artozik a logikai név kezelés, a szöveglánc feldolgozó szolgáltatások, am iket az al kalmazások igényelhetnek, és i de tartoznak o lyan s zolgáltatások i s, pl. bi zonyos szinkronizációs technikák, a rendszer pool manipulálás, amiket a rendszer egyébb rutinjai kérhetnek. Mind az alkalmazások és segédprogramok, mind a rendszer rutinok használják a minden "objektumra" kieterjedõ lock management védelmi mechanizmust.

Láttuk t ehát a V AX/VMS k ernel és k örnyezete s truktúráját, és k érdés m erülhet f el, h ogy i s vannak a komponensek programtechnikailag megvalósítva? Gyakorlatilag háromféle módon. Egy r észük eljárás/függvény jellegû kód, a mi szinkron call hívással, pa raméterátadással aktiválható. R étegek át lépésekor t ermészetesen m egvalósított az el lenõrzött trap is A hí vás lehet beágyazva futás idejû könyvtári rutinokba, vagy lehet közvetlen rendszerhívás (system call), r utinhívás ( RMS cal l). A v isszatérések i s a s zokásos e ljárásból/függvénybõl va lo visszatérési technikák ez esetben. Egy m ásik r észük kivételes eseményt vagy megszakítást kiszolgáló rutin. A m egszakítások aszinkron j ellegûek, bi zonyos ki vételes események s zintén a szinkron j ellegûek, m ások szinkron jellegûek, bár váratlanok, a futó processzek szempontjából. Bármilyen is az esemény jellege, a kiszolgáló rutinba való

belépés más, mint a call-lal való belépés. A futó processzhez tartozó regiszterállapotok lementése után az esemény elemzéstõl függõen kerül a végrehajtás fonala a kiszolgáló rutinhoz. A s zolgáltatások ha rmadik c soportja önálló processzként megvalósított. E zek a rendszer processzeknek is n evezett f olyamatok p rivilegizáltak, a mi a zt je lenti, h ogy r észben v agy egészben magas rangú módban futnak. Ezek egy része végigéli a r endszer életét, egy részük pedig s zükség es etén m egszületik, el végzi f eladatát és m eghal. A z al kalmazások a r endszer proceszek e gy r észének s zolgáltatásait k özvetlenül n em k érik: a r endszer p rocesszek az alklamazások s zámára t ranszparensen, a " háttérben", i génybejelentés n élkül i s v égzik a szolgáltatásokat. M ás r észüktõl az al kalmazások i gényelhetnek s zolgáltatást, ek ikor ez processzek közti kommunikációs mechanizmusokkal (Inter Process

Communication) töténik. Szeparált p rocesszként megvalósított p éldául a swapper (a m emória m enedzselõ al rendszer része), vagy a szintén a memóriamenedzsmenthez tartozó módosított lapok készletét kiíró, de eddig nem említett processz. Mindkettõ teljes egészében kernel futási módú, igénybejelentést nélkül is szolgáltat. Szeparált p rocesszekként m egvalósítottak az ACP-k ( Ancillary C ontrol P rocess), am iket az I/O alrendszernél már említettünk. Ezek az adatmenedzsment egyik szintjét segítõ processzek, szintén p rivilegizáltak. M int e mlítettük, a f ájlok e szközökön va ló e lhelyezéséért f elelõsek Lehetnek d iszkeket, m ágnesszalagokat k ezelõ A CP-k ( hacsak n incsenek ez ekhez s peciális processzorok), de vannak hálózati eszközöket, terminálvonalakat kezelõ ACP-k is. Az ACP-k sajátos i nterfésszel r endelkeznek a k ernelhez, hi szen s zorosan e gyütt ke ll dol gozniuk. A kernel a m ûködésüket a z R MS r

utinokkal i s ös szehangolja ( emlékezzünk, a z R MS r utinok felelõsségére a r ekordformátumokér, v agyis a f ájlok t artalmáért). A z al kalmazások igénybejelentésére szolgáltatnak. 1.72 A Unix kernel funkcionális felépítése A U nix k ernel imp lementációjához le galább k ét f utási mó d k ell: a f elhasználói mó d é s a kernel m ód. A z á brán, a mi m ás á brázolási t echnikával ké szült, m int a z e lõzõ, a f utási szinteket (User level, Kernel level) tüntettünk f el, am ik ér telemszerûen m egfelelnek a f utási módoknak. Természetesen nincs akadálya annak, hogy több futási móddal rendelkezõ CPU-ra Unixot valósítsunk meg. Nézzük m ost a z 1.9 á brát! E z a ké t f utási m ódú ha rdverre i mplementálható U nix ke rnel legalapvetõbb s truktúrája. Láthatunk h asonlóságokat é s kül önbözõségeket a V MS ke rnelhez viszonyítva: me gfigyelhetõ a z itt is ö nálló I/O alrendszer, l átható, hog y a

memória menedzsment, a scheduler és a folyamatközi kommunikáció szolgáltatás a folyamatvezérlõ alrendszer (Process C ontrol S ubsystem) részeként f eltüntetett. A z a lrendszerek f unkcióit i tt nem részletezzük, ezek hasonlóak a VMS funkciókkal, késõbb még lesz róluk szó. Az ábrán néhol látszik a réteges felépités (lásd az I/O system-et). Az viszont nem látszik az ábrán, hogy vannak kernel szintû adatbázisok, adattáblák is. 1.9 ábra A Unix kernel funkcionális felépítése A VM S-hez h asonlóan, a k ernel itt is s zolgáltatásokat b iztosít a f elhasználói f olyamatok számára. Gyakorló feladatként elemezzünk egy read (fp, buffer, size) rendszerhívási forgatókönyvet. Bizonyos s zolgáltatások itt is eljárás jellegû rutinok (call je lleggel h ívhatók), itt is v annak eseménykezelõ rutinok (esemény bekövetkezésre, akár aszinkron jeleggel hívódnak), és itt is vannak öná lló f olyamatként m egvalósított s

zolgáltatások ( pl. a swapper és a pagedaemon) Bármelyen is a z imp lementáció, a f elhasználói f olyamatból a s zolgáltatás ú n. rendszerhívással (system call) igényelhetõ. 1.73 A Windows NT 40 struktúrája Az 1 .10 á brán j ól l átható a z N T m oduláris f elépítése J ól é szrevehetõ a m ikrokernel architektúra. A HAL modul t ulajdonképpen c satoló a h ardver é s a m ikrokernel köz ött, c élja a ha rdver különbözõségeket ( processzorok a rchitektúrája, pr ocesszorok s záma, e lrendezése s tb.) elrejteni a m agasabb r étegek el õl. B ár az o perációs r endszer r észe, s zokás s zerint a hardvergyártók készítik és szállítják a géppel együtt. A HAL-nak köszönhetõ, hogy az NT sok platformon (pl. Intel, DEC Alpha stb) használható A mikrokernel látja el az al apvetõ rendszerfunkciókat: a m egszakításkezelést, a fonalak (szálak) ütemezését, szinkronizálásokat. Az E xecutive s zolgáltatások m oduljait

ha sználhatják a z a lklamazások (és a z ún. kör nyezeti rendszerk. Az Objektum menedzser egységes s zabályrendszer s egítségével v ezérli az o bjektumok létrehozását, elnevezését, biztonsági tényezõit. A Folyamat menedzser hozza l étre és t örli a taszkokat, a s zálakat ( fonalakat), s zorosan együttmûködve a memória menedzserrel és a biztonsági rendszerrel. A Helyi eljáráshívás alrendszer (hasonlít a z R PC-hez) k ezeli az al kalmazások h ívásait, melyekkel a k örnyezeti al rendszeren ( vagy k iszolgáló al rendszer, n em l átszik az áb rán!) át szolgáltatásokat igényel. Az I/O alrendszer biztosítja a fájlrendszereket (FAT, NTFS, CDFS), a cache buffer (átmenti gyorsító tároló a központi memória és a háttértárak között) funkciókat, az eszköz drivereket. A Virtuális memóriamenedzser értelemszerûen a memóragazdákodást segíti. A megjelenítõ rendszerbõl a konzol rendszer nem a kernel része (az felhasználói

módban fut). Kernel kom ponens vi szont a Win32K ablakmenedzser: k ezeli az ab lakokat, a k épernyõt, eljuttatja a z i nputokat a z a lkalmazásokhoz. A GDI (Graphics D evice Interface) gr afikus eszköz c satoló pe dig ké pernyõ r ajzoló pr imitívek gyűjteménye. Végül, a megjelenít õ alrendszerhez t artoznak a grafikus e szközmeghajtók ( driver) i s. 110 á bra A W indows N T 4.0 kernel szerkezete: 1.8 Hogyan juthat a vezérlés a kernelbe? Tulajdonképpen háromféle módon: 1. A f elhasználó pr ocesszekbõl rendszerhívással (system c all) V alójában e z e gy f utásideji könyvtári függvény hívása, aminek a p araméterei a felhasználói címtartományban vannak. A hívó folyamatra nézve szinkron. Implicite trap (futási módváltás) van benne 2. Megszakítás (IT: interrupt) generálásaval a hardverbõl Aszinkron, és ritkán kapcsolatos az éppen futó processzel, a processznek "nincs is tudatában", hogy mi okozza a problémét. 3.

Kivételes esemény (Exeption Condition), hiba (error) elõállása esetén a hardverbõl Szintén váratlan, de általában az éppen futó processzel kapcsolatos. Szinkron olyan értelemben, hogy a processznek "tudatában van" a felmerült probléma. Bizonyos irodalom ezt a belépési módot egyszerûen trap-nek nevezi. (Más szerzõk a három belépési módot közös trap névvel illetik, ismét mások a trap kifejezést a rendszerhívásbeli futási mód váltásra értik.) 1.81 A kernelbe való belépés eseményei Miután a k lasszikus Unix-ok a legegyszerûbb operációs rendszerek, a kernelbe való belépés és ki lépés f orgatókönyvet U nix-os pé ldán m utatjuk be . N yilvánvaló, hog y m ás ope rációs rendszereknél ha sonló f orgatókönyvek s zerint t örténik a be /kilépés. E zek ut án a ke rnelbe lépés "története": • A hardver átkapcsol kernel módba. A memória-elérés kernel privilégiummal történik ezután, a verem

mutató átáll a kernel szintû veremre, minden privilegizált instrukció végrehajtása engedélyezett. • A PC és a PSW (programszámláló és program státus szó regiszterek) a processz kernel szintû veremére töltõdnek (push). Ez hardveres letöltés • A rendszerhívás/trap kódja (system call száma/signal kódja) is rátöltõdik a veremre. • Egy assembly rutin l ementi az ál talános cél ú r egisztereket i s. E zek u tán m ár m agas szintû nyelven írt rutinok is hívhatók. Így is történik, C-ben írt rutin hívódik, a belépés fajtájától függõen. • Hívódik • syscall() rendszerhíváshoz. Ez egy diszpécser, elosztja a vezérlést • trap() a kivételes esemény belépés esetén, ami szintén eloszt, a kódtól függõen. • a megfelelõ device driver IT kiszolgálója, megszakítás belépés esetén. A diszpécser feladatait tovább részletezhetjük: • Kiveszi a rendszerhívás paramétereinek számát. •

Ellenõrzi a p aramétereket, v ajon a f elhasználói cí mtartományban va nnak -e, m ajd bemásolja a zokat a ke rnel c ímtartományába. E z a zért f ontos, hogy a ki szolgálás mellékhatása (side effect) semmiképp ne rontsa el a processz felhasználói területét. • Felkészül arra, hogy interrupt-tal, trap-pel megszakíthatják. • Meghívja a megfelelõ rutint. 1.82 Visszatérés a kernelből A visszatérés a megfelelõ szolgáltatásból függ a belépéstõl. A k lasszikus r endszerhívás s zolgáltatásból el õször a d iszpécserhez t ér v issza a v ezérlés, méghozzá azzal a jelzéssel, hogy a szolgáltatás sikeres volt, vagy nem. Mielõtt a diszpécser a hívójának adná az eredményt, megvizsgálódik, kapott-e közben signal-t a folyamat. Ha igen, a signal handler mûködik, de végül a vezérlés mindenképp visszatér a diszpécserhez. Ekkor az esetleges hibás szolgáltatás hibakódját a globális errno változóba írja, majd egy

assembly rutin vi sszaveszi a z á ltalános r egiszterek t artalmát ( pop). A vi sszatérési é rtéket hor dozó regiszter a s zolgáltatási hiba esetén -1 értéket kap, különben 0-t, vagyis a hívó a system call visszatérési ér tékeként c sak j elzést k ap, v olt-e hiba v agy s em, a h iba jellegére az er rno vizsgálatával következtethet). Ezután végrehajtanak egy return-from-interrupt instrukciót Ez visszaállítja a P C é s P SW ta rtalmat, é s v isszaállítja a f elhasználói mó dot. U gyanezzel visszaáll az S P i s, és a p rocessz u ser s zintû v ermére m utat. E zzel f olytatódik a p rocessz felhasználói módú futása. Kérdés merülhet fel, jó-e ez így? Mi van, ha IT kiszolgálás rutinja fut (kernel módban) és erre jön egy magasabb szintû megszakítás, hogy történik ekkor a "belépés" és a "visszatérés"? A válasz: kernel módú futásban viszonylag kevés az "elõvételi jog", a preemption. Ilyen

kérés esetén • belépéskor nincs módváltás, • kilépéskor sincs módváltás. Nincs t ehát v erem-mutató vá ltás s em, ugy anazt a ke rnel s zintû ve rmet h asználják. A t öbbi esemény hasonló a fentiekhez. Kérdés m erülhet f el, m elyek a l eggyakoribb t rap-ek? ( Most t rap al att m indhárom b elépésre gondolunk.) • Leggyakoribb a z ór aeszköz m egszakítása, a c lolck pr ocessing. E z á llítja a na pi i dõt számontartó m ezõket, támogatja a i dõkiosztás ve zérlését, a r endszer i dõtúllépés (timeout) funkciók végrehajtásását. • Második leggyakoribb trap a szokásos rendszerhívások trap-je. • Ezután jönnek a további trap-ek. 1.9 A system call-ok osztályai Processz menendzsment • end, abort • load, execute • create, terminate processes • get,set process atributes • wait for time/termination • wait for event, signal event • allocate free memories fork() exec?() exit()

sigaction() kill() residual() [signal()] pause() Fájlokkal, jegyzékekkel kapcsolatos rendszerhívások • create, delete files • open, close files • read, write, reposition • get,set file attributes • ugyanezek jegyzékekre is creat() open() close() read() write() lseek() stat() mkdir() rmdir() link() ulink() chdir() chmod() Eszköz manipulációk • request device, release device • read, write, reposition • get, set device attributes • logically attach, detach devices Informálódó, beállító get, set, time, date etc. 1.10 Irodalom Tannenbaum: Modern Operating Systems, Prentice Hall, 1992 Bach: The Unix System, Prentice Hall, 1985 Silberschatz, Galvin: Operating Systems Concepts, Addison-Wesley, 1994 Babócsy, Füzessy: Windows NT 4.0 hálózatok, NeTen, 1998 3. Hiba- és eseménykezelés 3.1 Alapfogalmak: események, kivételek, megszakítások Az esemény legáltalánosabban: folyamatok ( taszkok, pr ocesszek, f onalak, rutinok,

utasítások, i nstrukciók) futását be folyásoló, vá ratlan i dõpontban be következõ t örténés. A z esemény bekövetkezése esetén reagálni kell rá: le kell kezelni. A lekezelés megváltoztatja az instrukció-folyam normális menetét. Az eseményt a hardver vagy szoftver generálja és detektálja. Az es emény v áltozás v alamilyen entitás állapotán. E gy i nformációs á llapot e lõállása: e gy állapottér állapotvektora. Fogalmazhatunk úgy, hogy egy esemény bekövetkezése azt jelenti, hogy elõáll a neki megfelelõ állapot, vagy fordítva, ha elõállt az állapot, akkor bekövetkezett az esemény. Ezért az állapotot sokszor feltétel állapotnak (condition, error condition, exeption condition), vagy röviden feltételnek szokták nevezni. Ha a f eltétel el õáll ( bekövetkezett az es emény), akkor az v alahogyan jelzõdik. M ás fogalmazással: jelzés keletkezik. Ismét m ás f ogalmazással: v alamilyen e ntitás jelzést küld valamilyen

en titásnak. A j elzõdés al apja a l ekezelhetõségnek, am i k apja a j elzést, az lekezelheti az eseményt. A lekezelés megváltoztatja a futás menetét: • a normális futás menetét abba kell hagyni. (Kérdés: a gépi instrukciót? Az utasítást? A rutint? A fonalat (thread)? A processzt? A taszkot?) • Reagálni, kezelni a helyzetet: kezelõ instrukciófolyammal, rutinnal, processzel. • Dönteni ke ll a rról, hog y l ekezelés ut án vi sszaadhatjuk-e a f utást az abbahagyott entitásra (instrukcióra, vagy utána; utasításra vagy utána; rutinba, vagy annak elejére, vagy utána; stb.), vagy az operációs rendszernek adjuk a vezérlést Az eseményt és lekezelését eddig általánosan tárgyaltuk. Kíséreljük meg a pontosbítást és az osztályozást! Az események osztályai Egy processz szemszögébõl lehet • belsõ esemény: amit a processz állít elõ; • külsõ e semény: v alami, a p rocesszen k ívüli e ntitás á llítja e lõ ( pl.

p erifériavezérlõ interrupt). Az elõállító entitás szerint lehet • hardver által generált és detektált (megszakítások, hibák, anomáliák); • szoftver által generált és detektált (szoftver által generált megszakítások, szoftver által generált és emulált kivételes feltétel állapotok, a szûkebb értelemben vett események). A megszakítások A legalacsonyabb szintû események a megszakítások (interrupts). A processz szemszögébõl nézve külsõ esemény. (Ha a processz saját magának küld szoftver megszakítást, a kkor te kinthetõ b elsõ e seménynek is .) E lõállítója r endszerint a h ardver (eszközvezérlõk), de l ehet s zoftver is. J elzése a C PU-nak s zól Lekezelõi az o perációs rendszer kernelének IT kezelõ (IT hadler) rutinjai. Kezelésének módja: az aktuális instrukció befejezõdik, a kont extus di namikus r észe l ementõdik ( rendszerint r észben ha rdveresen!), a lekezelõ r utin f ut, vi sszatérve a di

namikus k ontextus f elvevõdik é s a s oron köve tkezõ instrukció f uthat. A z I T p rioritási s zinteknek me gfelelõen IT k ezelést me gszakíthat megszakítás. A bekövetkezett, de még le nem kezelt megszakítások hardveres sorokon várnak lekezelésre. Jól installált operációs rendszer kernel esetén minden IT lekezelhetõ. A kivételek (exeption), hibaesemények A ne vükbõl köve tkezõen va lamilyen a bnormális he lyzetet j elentenek. N éha a zt m ondjuk, olyan események, am elyek a n ormális f utás s orán n em j elentkeznek, k ivételesek, v agy valamilyen hibára utalnak, gondot jelent jelentkezésük. Lehetnek alacsony s zintûek ( pl. t úlcsordulás bekövetkezése a C PU-ban), de l ehetnek magasabb s zintûek i s ( pl. l aphiba ( page f ault), ami - bár ne vében ot t a hi ba s zó - egész normális jelenség; vagy pl. fájlnév tévesztés miatti nyitási hiba stb) Alacsony va gy m agas s zint? E z a zt j elenti, hog y a ki vétel j elzése i

nstrukciónak, r utinnak, fonálnak stb. szól? Vagy a kezelés szintjét jelenti? Mindkettõt! A kl asszikus ki vétel be következése esetén az ép pen f utó entitás ( instrukció, u tasítás, r utin, fonál, p rocessz) n em fejezhetõ b e! Fel k ell f üggeszteni, l e k ell k ezelni a k ivételt, és - ha egyáltalán l ehetséges - a f elfüggesztett e ntitást e lõlrõl k ezdve ú jra kell f uttani ( pl. az instrukciót laphiba esetén); vagy folytatni kell (pl. rutint onnan, ahol felfüggesztésre került) Az operációs rendszerek - felhasználva persze az IT kezelés amúgy is meglévõ adottságait képesek alapértelmezés s zerinti m ódon ( default ha ndler-ekkel) k ezelni a k ivételeket. Többnyire bi ztosítanak a pr ogramozó s zámára is pr ogramozási e szközöket, m elyekkel a kivételkezelés részbeni felelõssége, a kivételkezelés lehetõsége (legalább részben) biztosított. Itt a magasabb szint értelmet nyer tehát, veszíti jelentését

viszont a "hiba" jelzõ: hiszen nem feltétlenül je lentenek - akár az o perációs r endszer, ak ár a m i ál talunk l ekezelt - kivételek hibákat, legfeljebb csak gondot. A szűkebb értelemben vett esemény Ezek be következését a p rogramozó e lõre l átja, v ár a be következésükre, bár a b ekövetkezés idejét ne m t udja: vá ratlanok é s a szinkron j ellegûek. T ipikus pé lda e rre a z X 11 eseményvezérelt p rogramozása ( event d riven programing): p l. az e gér e gy gombjának lenyomása, egy ablak feltárulása esemény az alkalmazás számára, neki jelzõdik, õ reagál rá. Jellegzetesen magas szintek az események, feltétlenül kellenek hozzá magas szintű fejlesztő eszközök, a pr ogramozó ha táskörébe t artozik m aszkolásuk, l ekezelésük s tb. J elzéseik legtöbbször egy eseménysorba kerülnek, lekezelésük e sor figyelésével történhet. Miután a szűkebb értelemben vett események kezelése magas szint û feladat, a

továbbiakban nem f oglakozunk ve lük kül ön. M egemlítjük, hog y ke zelésükben i génybe ve hetõk a ke rnel megszakítás-kezelési, vagy kivételkezelési technikái is. A további fogalmak már csak a megszakításokra és a kivételekre vonatkoznak. A feltétel (condition) fogalom: az a z in formációs á llapot, a mi elõáll, mikor e gy esemény bekövetkezik. Lehet hardver feltétel (hardware condition), vagy szoftver feltételrõl (software condition) beszélni. Ha a z i nformációs á llapot hi bára, a nomáliára ut al s zoktuk hiba feltételnek (condition), va gy kivételnek (exeption condition) is nevezni. 3.1 ábra A feltételek osztályai A megszakítások és a hibaállapotok hasonlósága, különbségei Midkettõ á tadja a v ezérlést e gy ki szolgáló r utinra ( handler). A ki szolgálások m egszakítás, vagy hibaállapot specifikusak, bár nagyon sokban hasonlóak. • A m egszakítás ( IT) aszinkron a kur rens instrukciófolyam v

égrehajtásában. Kiszolgálása két instrukció között (vagy egy adott instrukció végrehajtásában egy jól definiált ponton történik. • Az exeption condition - bár v áratlan - szinkron j elleggel fordul elõ mint direkt hatás egy i nstrukció vé grehajtása s orán. K iszolgálása a z i nstrukció vé grehajtása köz ben történik, a zaz a ké rdéses i nstrukció vé grehajtása f olytatódik, va gy é ppen megismétlõdik. T ipikus példa a l aphiba ki vétel (page fault e xeption c ondition): e gy instrukció a címleképzés során generál laphibát. Ez azt jelenti, hogy az adott című laphoz nincs lapkeret rendelve a f izikai tárban. Lekezelése behozza a k érdéses lapot a fizikai tár egy lapkeretébe, ezután az instrukció sikeresen megismételhetõ (vagy annak címleképzési része sikeresen folytatható). • A m egszakítás r endszerint ne m ka pcsolódik a f utó pr ocesszhez. K iszolgálása u gyan történhet a kurrens processz kontextusa

fölött, de nem valószínû, hogy a futó processz javára. • Az e xeption c ondition á ltalában a kur rens, futó processz r észe: ki szolgálása a f utó processz instrukciófolyamának kiterjesztése, kapcsolódik a kurrens processzhez, a futó processz javára történik. • A megszakítások kiszolgálásának rendje összefügg a megszakítási prioritási szintekkel (Interrupt P riorty Level). K iszolgálásuk l etiltható ( lemaszkolható) a z IPL (Interrupt Priority Level) szint állításával, de egy megszakítás kiszolgálását magasabb prioritású megszakítás bl okkolhatja. B efutott, de n em ki szolgálható m egszakítások s orba állva várnak kiszolgálásra (pending interrupts). Rendszerint hardveres a sorképzés • A k ivételes események k iszolgálása nem bl okkolódhat. A ki vételes e semények kiszolgálási rendje rendszerint független az IPL s zintektõl, kivételes eseményt másik kivételes esemény "nem szakíthat meg".

• Némely rendszernél a megszakítások kiszolgálására közös rendszer vermet használnak (system w ide s tack), miv el a me gszakítások " system w ide" je llegûek. A k ivételes események k iszolgálására m inden r endszernél p rocesszenkenti k ernel v erem használatos. A szignál fogalom A s zignál k ifejezés me glehetõsen tú lterhelt, tö bb é rtelemben is h asználjuk. P róbáljuk m eg tisztázni az értelmezéseket. Jelzés (signal): es emény bekövetkezésekor - vagyis a f eltétel ál lapot elõállásakor - jelzés (signal) k eletkezik, s zoktuk m ondani. Jelzések k eletkeznek nor mál f utás közben e semények hatására. J elzések ér tesítik a C PU-t, va gy egy-egy p rocesszt az es eményekrõl Ú gy i s fogalmazhatunk: a C PU, va gy e gy p rocessz j elzést ka p, ké zbesítenek ne ki e gy j elzést. A z események jelzõdnek. Ebben az értelemben az esemény és a j elzése lehet még szinkron vagy aszinkron is. Ezzel a

terminológiával egyszerûsíthetjük a tárgyalást: • van egy jelzés készlet; • jelzés keletkezhet hardver vagy szoftver eredetbõl; • a keletkezett jelzés kikézbesítõdik egy processznek. vagy a CPU-nak A kikézbesített jelzések sorokba rendezõdhetnek, várva, hogy lekezeljék õket. • A kikézbesített jelzéseket a lekezelõ rutin (handler) lekezeli. A jelzéseknek van egy készlete. Minden jelzéshez hozzárendelt egy kezelõ (handler) Jelzést kézbesít ki a rendszer, amikor detektál egy hardver eseményt (pl. exeption condition-t, amikor detektál e gy szoftver f eltételt ( pl. s top k érelmet terminálról), ille tve p rocesszek k üldhetnek szignált m ás p rocesszeknek ( Unixban a kill (), killpg(), sigsend() rendszerhívásokkal, VMSben az AST mechanizmuson keresztül.) Ez a szingnál fogalom tágabb értelmezése, azt hangsúlyozza, hogy az események jelzõdnek. Szignálozás, aszinkron események kezelése processzekben A szignál fogalom

ebben a szûkebb értelmezésben az elõzõ szignál fogalomból levezethetõ: aszinkron e seményeket j elzünk pr ocesszek s zámára. Jelzések keletkezhetnek (signal generation), k eletkezett jelzések kézbesíthetõk (delivering o f s ignals) k i p rocesszek s zámára. A pr ocesszek e lõzõleg rendelkezhetnek a szignálokról (signal di spozitio), hog y mi l egyen a rendszerakció a ki kézbesített s zignálokra. A s zignálok k eletkezésének és k ézbesítésének megkülönböztetése m agával hoz za a felfüggesztett szignálok (pending s ignals) fogalmat. A processzek a szignálokat blokkolhatják is ( blocked or m asked s ignals), a mi va lójában a kikézbesítés m egakadályozása. M iután a b lokkolás n em a k eletkezés, h anem a k ézbesítés akadályozása, a blokkolás hatással van a felfüggesztéssel, továbbá kapcsolat van a ignorációs kezelési rendelkezéssel (ignored signals, blocked pending signals). A szignálkezeléshez az OS kernelek

biztosítanak programozói felhasználói felületeket (APIs). A s zignálozó r endszerhívásokkal a lkalmazásainkban r endelkezhetünk e gyes s zignálok kezelésérõl, bl okkolhatunk é s m egszüntethetjük a bl okkolását egyes s zignáloknak, generálhatunk m agának a hasznosak l ehetnek a processznek v agy m ás pr ocessznek s zignálokat. M indezek pr ocesszek köz ötti s zinkronizációban, a z e seményvezérelt programozásban. M i e zekbõl U nix A PI-kat f ogunk né zni E mlíthetõ e zekbõl a B SD szignálkezelõ API, az SVID szignálkezelõ API és a POSIX API. A legtöbb Unix mindhárom felületet i smeri. E z a nnyiban g ondot j elent, ho gy a z e gyes r endszerhívás családok ke verten korlátozottan ha sználhatók: e lsõsorban a s zignálok bl okkolásának, a di szpozíciónak e ltérõ adatstruktúrákban va ló nyilvántartása m iatt. K ülön g ondot j elent an nak " felfedése", m ely szignálokat t udja é s milyen kor látok köz ött,

" kezelni" a pr ogramozó a s zignálozó rendszerhívásokkal. Mielõtt "szignálozni" kezdenénk, tisztázzuk az ide kapcsolódó fogalmakat! Jelzés keletkezés (szignál generálás, szignál postázás) A j elzés ( ebben az ér telemben) e gy p rocessz s zámára aszinkron es emény bekövetkezésekor keletkezik A generálódás oka lehet éppen egy hardver esemény/hiba, egy kivételes esemény pl. a ritmetikai h iba, k ontroll te rminál v onal m egszakadás ( hangup), kont roll t erminálon "megszakítás" ( ctrl/break) e lõidézés s tb. - a pr ocesszben E kkor e gyszerûen azt m ondjuk, jelzés keletkezett. D e az i s l ehet, h ogy e gy m ás p rocessz k üld j elzést az " áldozat" processzünknek. E kkor a j elzés g enerálódás he lyett m ondhatjuk: jelzést postáztak a processznek ( sending s ignal, s ignal t o pos t). E gy pr ocessz kül dhet s zignált e xplicit rendszerhívással (kill, sigsend), de rejtettebb módon is:

pl. gyermek processz exitálása során mindig kül d e gy megszûntem ( SIGCLD v agy S IGCHLD s orszámú) j elzést a s zülõjének. A küldõ processz számára a küldés ugyan szinkron, de a célzott processz számára nyilvánvalóan aszinkron ez a fajta jelzés generáció. Rendelkezés a jelzésrõl (signal dispozitio) Az eseményeket kezelni kell, léteznek tehát szignálkezelõk is. A rendelkezés a szignálokról, vagy s zignál di szpozíció a nnak s pecifikálása, ho gy milyen rendszerakció menjen végbe, ha szignált ka p e gy pr ocessz. A rról r endelkezünk, hog y m i l egyen a s zignálkezelõ, hog yan történjen a kezelés. Nyilvánvaló, hogy diszponálni "elõre kell": mielõtt a szignált a processz megkapja, elõtte kell megmondani a k ezelés módját. A diszpozíció megváltoztat(hat)ja a k ezelést, ez a v áltoztatás addig é l, amíg új ra n em di szponálunk. U gyanazon a s zignál ké t diszpozíciója köz ött l ehet, hogy nem is

kézbesítik ki ezt a szignált. Nyilvánvaló a z is , h ogy minden s zignálnak k ell le gyen alapértelmezés s zerinti k ezelõje (default ha ndler), a mi ke zel, ha m ásként ne m r endelkeztünk e lõre. A de fault ha ndler-ek általában "gorombák": nem a dják v issza a v ezérlést, te rminálják az "áldozat" p rocesszt. Természetes, h ogy az alapértelmezési kezelés explicite be is állítható (diszponálható, visszaállítható). Rendelkezéssel (diszponálással) beállíthatjuk, hogy egy szignálnak saját kezelõje legyen: egy saját magunk által írt függvény legyen a kezelõ. Nem minden szignálra írhatjuk ez elõ, de elég sokra. Külön megfontolásokat igényel a saját kezelõ írása: befolyásol a szignálok blokkolása és a z e bbõl f akadó s zignál-felfüggesztés, b efolyásol a z a té ny, h ogy mi tö rténjen e gy rendszerhívás ki szolgálással, ha é ppen a zt " függeszti f e" e gy s aját ke zelõ, a

nnak e ldöntése, hogy a kezelõnek saját verme legyen vagy sem, megfontolandó, hogy a saját kezelõ lefutása után visszaálljon-e a default kezelés vagy sem stb. Rendelkezéssel ( diszpozíció) be állíthatjuk a zt i s, hog y hagyjuk figyelmen kívül (ignoratio) a szignált. A Unixokban a "szignálozásban kezelhetõ" szignálok diszpozíciója processzek keletkezésekor (forkoláskor) a s zülõ d iszpozíciókból i nicializálódik. Ö röklõdnek di szpozíciók A f üggõ szignálok ( lásd ké sõbb) e lvesznek. A z e xec?() r endszerhívás a s zignál di szpozíciókat a z alapértelmezési kezelõre (SIG DFL) állítja. A SIGKILL és SIGSTOP szignálok diszpozíciója nem változtatható (nem ignorálható, saját kezelés sem írható elõ). Jelzés kézbesítése (delivering of signal), függõ szignálok (pending signals) Akkor m ondjuk a s zignált kikézbesítettnek (delivered s ignal), amikor a diszponált akció beindult. A szignál keletkezésekor

az még csak generált szignál (generated or posted signal) Amikor az akció indul, akkor már kézbesített a szignál. A keletkezés és kézbesítés között idõ telik el, ezt az idõt szokásosan nem is detektálhatja a kérdéses "áldozat" processz. Ez idõ alatt a szignált függõben lévõnek (pending signal) mondjuk. Általában minden keletkezett szignál függõ egy rövid ideig. Az ún blokkolt szignálok hosszabb ideig is függõek lehetnek Jelzések blokkolása, a blokkolás megszüntetése A szignálok blokkolhatók is. A blokkolással megakadályozhatjuk, hogy kikézbesítsék azokat a processznek. A blokkolás megszüntetés azt jelenti, hogy engedélyezzük a kikézbesítést A blokkolás persze nem a keletkezést, hanem a kézbesítést akadályozza meg. Nyilvánvaló, hogy a bl okkolást é s a bl okkolás m egszüntetését i s " elõre" m eg k ell m ondani a k érdéses processzben (bár van "automatikus" blokkolás és

megszüntetése is: saját kezelõre diszponált szignál kezelése során, vagyis míg a kezelõ fut, többnyire blokkokolt és normális return-jére megszûnik bl okkolása). E gyes r endszerekben a b lokkolás és m egszüntetése k ifejezések helyett a szignálok maszkolása-maszkolás megszüntetése kifejezéseket használják. Tegyünk különbséget az ignorált és a blokkolt szignál között! Egy bl okkolt és i gnorált s zignál ke letkezésekor "elszáll", megszűnik. Egy blokkolt és nem ignorált s zignál keletkezésekor függõ s zignál l esz, addig, m íg m egszüntetik a bl okkolást (és ekkor kézbesül, megszûnik függõsége), vagy amíg mégis diszponálják neki az ignorációt, és ekkor a blokkolás megszûnése nélkül "elszáll", megszûnik (megszûnik függõsége is ezzel). A Unix-ok szignálkezelése A Un ix-okban a s zignálokat á ltalában a kkor ké zbesítik ki , mikor a pr ocessz ke rnel m ódból visszatér

felhasználói módba. Ez minden rendszerhívásból való visszatéréskor, illetve minden IT kezelésbõl való visszatéréskor megvalósul. Miután az óra IT gyakorisága "megszerezhetõ" információ, a s zignálok f elfüggesztési id ejére s zámítható f elsõ k orlát. ( Vigyázz p ersze a blokkolt szignálokra!) Szignál maszk a Unix-okban Minden pr ocessznek v an s aját s zignál ma szkja, a mi r ögzíti, h ogy p illanatnyilag me ly szignálok bl okkoltak ( megakadályozott ké zbesítésük). M int e mlítettük, a m aszkot a s zülõ processztõl öröklik (pontosabban abból inicializálódik a maszk). Általában e gy di szponált ha ndler f utása alatt a z a dott s zignál a utomatikusan bl okkolt, ne m kell explicit hívás a blokkolásra, megszüntetésre). Ugyanazon szignál keletkezése esetén tehát az új s zignál f üggõ l esz, m ajd a z e lsõ k ezelõ l efutása ut án ki kézbesítõdik e z i s. Ü gyeljünk viszont arra, ho gy h a a

handlert l ongjmp családhoz t artozó hí vással ha gyjuk el, akkor ni ncs "automatikus" blokkolás megszüntetés: a blokkolást explicit hívással meg kell szüntetni. 3.2 Unix szignálozással kapcsolatos API (Application Program Interface) A C nyelvi programfejlesztési környezetben a szignálozással kapcsolatos makro definíciók, prototype deklarációk a signal.h beleértett fájlban tekinthetõk meg Tanulmányozzuk ezt a fájlt, ami rendszerint a /usr/include/signal.h vagy /usr/include/sys/signal.h elérési útvonalon található. Megtaláljuk ebben a lehetséges (kezelhetõ) szignálkészletet definiáló makrókat. Az Irix-ben például pillanatnyilag a következõ szignálok definiáltak (és az alapértelmezési diszpozíciójuk a következõ): Name Value Default Event SIGHUP 1 Exit Hangup (terminál vonal hangup) [see termio(7)] SIGINT 2 Exit Interrupt (Ctrl/break a terminálon) [see termio(7)]

SIGQUIT 3 Core Quit [see termio(7)] SIGILL 4 Core Illegal Instruction SIGTRAP 5 Core Trace/Breakpoint Trap SIGABRT 6 Core Abort SIGEMT 7 Core Emulation Trap SIGFPE 8 Core Arithmetic Exception SIGKILL 9 Exit Killed SIGBUS 10 Core Bus Error SIGSEGV 11 Core Segmentation Fault SIGSYS 12 Core Bad System Call SIGPIPE 13 Exit Broken Pipe SIGALRM 14 Exit Alarm Clock (A real-time óra szignáloz) SIGTERM 15 Exit Terminated SIGUSR1 16 Exit User Signal 1 (Ezt szabadon használhatja a user) SIGUSR2 17 Exit User Signal 2 (Ezt szabadon használhatja a user) SIGCHLD 18 Ignore Child Status Changed (pl. exitál a gyermek) SIGCLD 18 Ignore Child Status Changed SIGPWR 19 Ignore Power Fail/Restart SIGWINCH 20 Ignore Window Size Change SIGURG 21 Ignore Urgent Socket Condition SIGPOLL 22 Exit Pollable Event [see streamio(7)] SIGIO 22 Exit input/output possible signal SIGSTOP 23 Stop Stopped (signal) SIGTSTP 24 Stop SIGCONT 25 Ignore SIGTTIN 26 Stop SIGTTOU 27 Stop SIGVTALRM 28 Exit SIGPROF 29 Exit

SIGXCPU 30 Core getrlimit(2)] SIGXFSZ 31 Core getrlimit(2)] SIGRTMIN 49 Exit SIGRTMAX 64 Exit Stopped (user) [see termio(7)] Continued Stopped (tty input) [see termio(7)] Stopped (tty output) [see termio(7)] Virtual Timer Expired Profiling Timer Expired CPU time limit exceeded [see File size limit exceeded [see POSIX 1003.1b SIGRTMIN POSIX 1003.1b SIGRTMAX A signal.h fájlban vannak definiált makrók a szignálkezelés akcióinak definiálására: SIG DFL ( void (*) () ) 0 default kezelés, SIG IGN ( void (*) () ) 1 ignorlás kérése. Vannak típus és struktúra definíciók, melyekre szükség lehet; megvannak azon rendszerhívások prototype-jai, melyek a szignálozáshos kellenek: A szignál dispozíció: hogyan állítsuk be egy szignál kezelőjét Már a legõsibb Unix-okban is használható volt erre a signal() rendszerhívás. A signal() hívás egyszerû és szinte "korlátlanul" használhatjuk diszponálásra. Az SVID-ben a sigset() rendszerhívás szintén

diszpozícióra való, és hasonlóan egyszerû a használata. A két rendszerhívási függvény prototípusa void (*signal (int sig, void (func)()))(); void (*sigset (int sig, void (disp)()))(); Ahol sig a szignál száma (használhatjuk a makrókat), a func illetve a disp a kezelõ függvény címe. Használhatjuk itt a SIG DFL makrót, ami default kezelést, vagy a SIG IGN makrót, ami ignorálást kér a sig szignálra. Illegális szignálra, vagy beállíthatatlan akcióra a két rendszerhívás SIG ERR értékkel tér vissza (és az errno változó figyelhetõ). Normálisan visszaadja a korábbi kezelési címet. Jegyezzük meg: ignorált szignál kezelése így is marad, amíg újra nem állítjuk. SVID rendszerben a signal() hívással diszponált saját függvénnyel lekezelt szignál esetén mielõtt a vezérlés belép a saját kezelõ függvényre, visszaállítódik a SIG DFL: Ez azt jelenti, mielõtt a kezelõbõl kilépünk, szükség esetén signal() hívással újra

állítsuk be a saját kezelõt! A signal() hívás törli a még le nem kezelt sig sorszámú függõ (pending) szignálokat! Az on-line manuelbõl nézük meg, mely szignálok kezelése vehetõ át, melyek ignorálhatók! Kimondottan BSD Unix-okban a diszpozícióra használhatjuk a sigvec() rendszerhívást. Ennek prototípusa (és a hozzátartozó sigvec struktúra definíciója): int sigvec(int sig, struct sigvec *vec, struct sigvec ovec); struct sigvec { int (*sv handler)(int, int); int sv mask; int sv flags; Használatához deklarálnunk kell saját vec struktúraváltozót, ebben be kell állítanunk a vec.sv handler tagot (SIG DFL, SIG IGN vagy saját kezelõ címére) Nullázni kell a vec.sv flags tagot (a vecsv mask-ot is, ha nem akarunk blokkolni), majd hívható a sigvec() függvény a sig szignál diszpozíciójára. Hibátlan futás megcsinálja a diszpozíciót és az ovec változóban visszaadja a korábbi beállításokat (ne feledjünk tehát ekkor ovec-et sem

deklarálni). A vec, illetve ovec lehet NULL pointer is: nem akarunk változtatni, csak lekérdezni (vec=NULL), változtatunk, de nem érdekel a régi beállítás (ovec=NULL), csak a kezelhetõséget akarjuk ellenõrizni (mindkettõ NULL, és kezelhetetlen sig esetén a sigvec() hibázik). Végül nézzük a POSIX szabványnak megfelelõ diszpozíciót! Ehhez a sigaction() rendszerhivás szükséges. A rendszerhívás prototípusa és a hozzátartozó struktúra: int sigaction(int sig, struct sigaction *act, struct sigaction *oact); struct sigaction { int sa flags; void (*sa handler)(); sigset t sa mask; void (*sa sigaction)(int, siginfo t , void ); } A "módszer" hasonlít az elõzõkhöz: deklarálnunk kell saját act és oact struktúraváltozókat. Az act megfelelõ tagjait be kell állítani. Mindenképp beállítandó az sa handler tag (SIG DFL, SIG IGN vagy saját kezelõ címe), és az sa flags tag (nullára, de nézd még a man-ban a lehetõségeket). (Az sa mask

tagot csak blokkolás esetén állítjuk, de erre vannak más rendszerhívások, pl. sigemtyset() sigaddset(), sigprocmask() stb) Ezek után hívható a sigaction(). Normális lefutás esetén megtörténik a diszpozíció, és az oact-ban visszajön a korábbi beállítás. Természetesen, itt is használhatók a az act és oact paraméternek a null pointerek. Szignál generálás, postázás; a kill() és a sigsend() Szignálokat "hardveresen" is generálhatunk, vagy hardveresen is generálódhatnak, de szükségünk lehet szignálok küldésére is. Egy processz kontrol terminálján kiadott ctrl/break generálja neki a SIGINT szignált, a terminál vonal megszakadása a SIGHUP szignált, gyermekének megszûnése (vagy "stoppolás") a SIGCLG szignált. A SIGALRM elõidézhetõ az alarm() rendszerhívással. A szignál "postázás" legegyszerûbben a kill burok paranccsal, vagy a kill() rendszerhívással valósíthtó meg. A kill parancs

használatát tanuljuk meg (pl a manual-ból) A kill() rendszerhívás prototípusa (a szükséges a types.h include fájl is): #include <sys/types.h> #include <signal.h> int kill(pid t pid, int sig); Feladata (bár a neve "öld meg"): a pid azonosítójú processznek (vagy processz csoportnak) küldj sig sorszámú szignált. Természetesen a SIGKILL sig is küldhetõ: az valóban megöli a címzettet, mert az nem kezelhetõ le csak default módon. Alapvetõen tehát a kill a processzek közti kommunikáció, a szinkronizáció eszköze, hiszen a küldött szignálok egy részét a címzett lekezelheti. Jegyezzük meg: a processzek valós vagy effektív tulajdonosainak meg kell egyezniük (kivéve: szuperuser bármelyik processznek küldhet szignált). Ha a pid==-1, akkor a minden processz megkapja a szignált, melyeknek valós tulajdonosa egyezik a küldõ effektív tulajdonosával. Visszatérési értéke: Sikeres végrehajtása esetén 0 értékkel tér

vissza. Különben a visszatérése -1, és az errno változó beállítódik. A sigsend() rendszerhívás prototípusa: int sigsend(idtype t idtype, id t id, int sig); Az idtype és id paraméterektõl függõen kiválasztott processz(ek)nek küldi a sig szignált. Ha az idtype == P PID; az id azonosítójú processznek; idtype == P PGID; az id csoportjába tartozó valamennyi processznek; idtype == P PUID; az effektív uid-û processznek; idtype == P GID; az effektív gid-û processzeknek; idtype == P ALL; az id-tõl függetlenül valamennyi processzek (nézd még a manual-t!). A pause (), sleep(), usleep() és alarm () rendszerhívások Ha szignálozással akarunk processzeket szinkronizálni, hasznosak ezek a rendszerhívások. int pause (void); Feladata: blokkolja a hívó processzt, amíg az nem kap valamilyen szignált. Miután megkapja a szignált, a pause -1-gyel, errno=EINTR-rel tér vissza. Ha egy szignált saját kezelõre (lehet az pl. egy ne csinalj semmit() )

diszponáltunk, a pause()-val való blokkolásból egy neki küldött megfelelõ szignál kibillenti, továbbengedi . A sleep() rendszerhívás az argumentumában adott másodpercig, az usleep() argumentumában adott másodpercnél kisebb egységig (mivel rendszerfüggõ az idõkezelés, nézd meg a manualban a sleep() családot) blokkol. Tulajdonképpen nem a szignálozáshoz tartoznak a sleep-ek, de hasznosak a szinkronizációs ütemezésekben, azért említjük meg õket. Végül megemlítjük az alarm() rendszerhívást is. #include <unistd.h> unsigned alarm (unsigned sec); Feladata: a hívó processz számára sec másodperc múlva SIGALRM sorszámú szignált generál. Ha a sec 0, a megelõzõleg kért alarm kívánság törlõdik Természetesen a befutó SIGALRM lekezelésérõl gondoskodni kell. A sigprocmask(), sigsuspend(), sigemptyset(), sigaddset(), sigismember() stb. rendszerhívások A szignál kézbesítés a POSIX-ban hasonlít az IT kézbesítéshez oly módon

is, hogy bizonyos szignálok blokkolhatók (hasonlóan az IT letiltáshoz). Létezik egy globális szignál maszk, ez definiálja, mely szignálok blokkoltak pillanatnyilag. Ez a maszk beállítható és lekérdezhetõ, a sigprocmask rendszerhívással. A maszk paramétere a sigprocmask, sigsuspend és sigaction rendszerhívásoknak. Tanulmányozzuk ezeket! Tanulmányozzuk a sigsetop rendszerhívás családot is (tagjai: sigemptyset, sigaddset, sigdelset, sigfillset, sigismemberset). Különböztessük meg a szignál készletet és a szignál maszkot! Jó példa található a www.iituni-miskolchu/~vadasz/cikkek/it06 os/03/stevens/apue/signals/criticalc fájlban. Az SVID-ban is lehet "blokkolni-elereszetni" szignálokat (de sohase keverjük a BSD vagy POSIX blokkolásokkal!). Itt használható a sighold(int sig) hívás blokkolásra, sigrelse(int sig) az eleresztésre. Hasznáható egy speciális diszpozíciós hívás is: a sigignore(int sig) is Általános szabály, hogy egy

szignál "automatikusan" blokkolt, mialatt éppen a kezelõje fut, és megszünik blokkolása, miután abból visszatérés van. 3.3 Esettanulmányok, példák, feladatok Lásd a /public/users/gi93/os/signals/*.c fájlok között a példákat Példa a s ignal(), al arm()és ap ause() r endszerhívásokra www.iituni- miskolc.hu/~vadasz/cikkek/it06 os/peldak/signals/criticalc Az. alarm adoc és alarmra varc párban haszánlható programok www.iituni-miskolchu/~vadasz/cikkek/it06 os/peldak/alarm adoc Gyakorló feladatok • Írjon programot, melyben a SIGINT szignált lekezeli. A SIGINT bekövetkezésekor a terminálról ( stdin) ké rjen be s h pa rancsot, a zt ha jtsa vé gre, m ajd a dja vi ssza a vezérlést. Gondoskodjon a programja terminálódásáról is • Szignál kezelõje SIGALRM-re írja ki az idõt. Példaprogramjában 10 másodpercenként keletkezzen SIGALRM. • Processz családon belül szinkronizáljon szignál kezeléssel. Szülõ processz

küldjön pl 10 m ásodpercenként j elzést ( pl. S IGALRM, S IGINT, S IGUSR1, S IGUSR2) gyermekének. A gyermek a s zignált f utásának m egváltoztatására h asználja. Specifikáljon erre feladatokat, programokon ezt mutassa is be! • Vizsgálja, derítse fel a SIGFPE (floating point exeption) állapotot! Hogyan állhat elõ? Mi a default kezelése? Átvehetõ-e a kezelése? • Tanulmányozza az Irix manualban a wait, waitpid, wait3 rendszerhívásokat! Talál ott a S IGCLD s zignálok k ezelésére érdekes p éldákat ( SVID, BSD és P OSIX k ezelésre: több gyermek processz exitje során el ne vesszenek a SIGCLD szignálok) • Vizsgálja é s d erítse fel a s zignál k ezelés és a v édelmi r endszer ö sszefüggéseit. M i a processz c soport? M ik a va lós és effektív f elhasználói a zonosítók? H ogy l ehet processz csoprortnak jelzést küldeni? • Írjon p rogramot f elhasználva a s igsetjmp é s a s iglongjmp r endszerhívásokat is. A

programnak legyen A jelû és B jelû ciklusa. S IGALRM szignálok hatására kezdje el felváltva az A, illetve a B jelû ciklusát végrehajtani! Vagyis, ha éppen az A cikluson dolgozik, S IGALRM h atására h agyja azt ab ba, kezdje el a B-t. A B ciklust h ajtsa végre mindaddig, amíg újabb SIGALRM érkezik s.ít (SIGALRM keltésére használja a kill parancsot!) A megoldás algoritmusa: • var: verema,veremb,futott; main () { signal(SIGALRM,kezel); while(1) { while(sigsetjmp(verema,1) == 0) futott=a; fut A; } while(sigsetjmp(veremb,1) == 0 futott=b; fut B; } } kezel() { { { signal(SIGALRM, kezel); if(futott == a) siglongjmp(verema,1); else siglongjmp(veremb,1); } És még egy összefoglalás, a POSIX szignálkezelõ rendszerhívások a következõk: sigaction (2) sigaddset (3) sigdelset (3) sigemptyset (3) sigfillset (3) sigismember (3) sigpending (2) sigprocmask (2) blocked signals. sigsetops (3) sigsuspend (2) interrupt. - POSIX signal handling functions. - POSIX

signal set operations. - POSIX signal set operations. - POSIX signal set operations. - POSIX signal set operations. - POSIX signal set operations. - Return set of signals pending for process. - Alter and return previous state of the set of - POSIX signal set operations. - Atomically release blocked signals and wait for 5. Folyamatok közötti információcsere (Inter Process Communication) 5.1 Alapfogalmak, elvek Több f olyamatból ös szetevõdõ a lkalmazás e setén a lapvetõ m echanizmus a z IPC. Multiprogramozású r endszerekben a bszolút t ermészetes e szköz. K ooperáló pr ocesszek kommunikálnak, s zinkronizálják f utásukat. T öbb kom munikációs m echanizmus l étezik, ezeket akár együttesen is alkalmazhatjuk. Az a bsztrakt pr obléma ki indulási m egfogalmazása a köve tkezõ: pr ocessz l egyen ké pes üzenetet küldeni processznek, processz legyen képes üzenetet fogadni más processztõl. A k iindulási me goldás: le gyen send(message) és

receive(message) rendszerhívás. A processzek között épüljön fel kommunikációs kapcsolat (link). Kérdések jelentkezhetnek azonnal: • Hogy lehet kommunikációs kapcsolatot létesíteni? • Az összeköttetés (link) több mint két processz között is lehetséges? • Hány kommunikációs kapcsolat lehet egy processz-pár között? • Mi a link kapacitása? Változó vagy fix méretûek lehetnek az üzenetek? • A k apcsolat egy, v agy k étirányú? É s ez az i rányitottság ho gy va n, h a t öbb m int ké t processz van a kapcsolaton? Az elvi megoldások, ezzel a típusok a következõk: 1. Direkt vagy undirekt kommunikáció Ki a közvetitõ entitás tulajdonosa (kihez kötõdik az entitás)? 2. Szimmetrikus vagy asszimmetrikus kommunikáció 3. automatikus vagy explicit bufferelés 4. Adatküldés (send by copy) vagy adathivatkozás küldés (send by reference) 5. Fix vagy változó méretû üzenetek 5.11 Direkt kommunikáció Alapeset Az i lyen t

ípusú IPC-ben a kom munikálni kí vánó pr ocesszek e xplicite is merik e gymás azonosítóit (pl. neveit) A szükséges rendszerhívások ekkor: send(receiver-name, message) receive(sender-name, message) vagy ehhez hasonlók. A kommunikációs kapcsolat jellemzői: A l ink a utomatikusan m egvalósul m inden kom munikációs pá r köz ött.A pr ocesszeknek csak egymás azonosítóit kell ismerni a kapcsolat létesítéshez. Mindíg ké t pr ocesz köz ött va lósul m eg a ka pcsolat, é s r endszerint csakis e gy l ink l étezik köztük. Általában egyirányú, de lehet kétirányú is a kapcsolat (a kapcsolat szimmetrikus). Asszimmetrikus direkt kommunikáció is l ehetséges. e kkor a köve tkezõkhöz ha sonló rendszerhívások kellenek: send(receiver-name, message) receive(id,message) Itt a receive hívás fogad üzenetet bármely processztõl, a küldõ azonosítója az id-be kerül. A kapcsolat jellemzõje: több küldõ és egy fogadó processz lehet. 5.12

Indirekt kommunkáció Az ü zeneteket mailbox, va gy port mechanizmusokon ke resztül köz vetetik. A m ailbox (postaláda) absztrakt objektum, amibe a p rocessz üzeneteket tehet, processz abból üzeneteket vehet ki . A m ailbox-oknak va n a zonosítójuk Ha ké t pr ocessz os ztozik köz ös pos taládán (mailbox-on, port-on) akkor azon át válthatnak üzeneteket. A szükséges rendszerhívások: create(mailbox) destroy(mailbox) share(mailbox) send(mailbox, message) receive(mailbox, message) vagy ehhez hasonlók. Jellemzõk: • Link valósul meg processzek között, ha van közös postaládájuk • A link több mint kér processz között is lehetséges. Változatok: • csak egy fogadó kapja meg a betett üzenetet, az, aki a versenyben elõbb éri el; • akár több fogadó is megkaphat egy üzenetet; • címezhetõ, melyik fogadónak szól az üzenet. • Több link is lehet processzek között. • A link lehet egyirányú, vagy kétirányú is. Változatok a

postaláda kötődésére (binding): 1. A mailbox egy processzhez kötõdik, úgy is mondhatjuk, a processz tulajdona Ilyenkor r endszerint a tulajdonos processz a f ogadó p rocessz, az ad ja ki a create, destroy hívásokatt, a receive hívásokat. A feladó processzek a postaláda használói A share hívással v álnak h asználóvá, send hívásokkal t esznek ü zeneteket a l ádába. A legfontosabb je llemzõ: ha a tulajdonos exitál, a postaláda megszûnik. E rrõl a használóknak értesülniük kell. 2. A mailbox az operációs rendszer tulajdonában van, az operációs rendszerhez kötõdik Ilyenkor a create hívást ki adó pr ocessz ( kreátor pr ocessz) ne m vá lik t ulajdonossá (exitálásával n em s zünik m eg a p ostaláda), d e destroy+receive+send hozzáférési jogokat (privilégiumokat) kaphat. J ó vol na, ha volna pass-priv(mailbox,proc-name) rendszerhívás i s, es etleg demand-priv(mailbox) hívás: ek kor a k reátor át adhatja privilégiumait, e

kkor a k reátor exitálása u tán me gmaradó ma ilbox-ra i gényt jelenthetne b e e gy processz. A lapértelmezés s zerint u gyanis a k reátor p rocessz beállíthatja a p rivilégiumait. H a e zt a jo got á tadhatja, a kár n em k izárólagossággal, akkor az ilyen postaládán keresztül szimmetrikus kétirányú kommunikáció lehetséges több m int ké t pr ocessz között i s! B ármelyik t ehet be üz enetet, bá rmelyik ki olvashat üzenetet ( a k üldõ ak ár v isszaolvashatja az elõzõleg b etett ü zenetét). M iután történhetnek pr ogramozási hi bák, s zükség l ehet garbage-collection(mailbox) rendszerhívásra is, megszüntetni a használatlan postaláda objektumokat. 5.13 A bufferezés kérdései A kom munikációs ka pcsolat, a l ink ka pacitását vi zsgáljuk i tt. A s zemléletmódunk a következõ: a linkhez üzenetek sora (queue) kapcsolódik. Alapvetõen három mód lehet: 1. Zéró k apacitású s or: a s or 0 hos szú l ehet Nem várakozhat a

s orban üz enet, a kül dõ csak a kkor kül dhet, h a a f ogadó e gyuttal veszi i s a z üz enetet. " Randevú" szinkronizációnak nevezzük ezt az esetet. 2. Korlátozott k apacitású a s or, ma ximum n ü zenetet tá rolhat átmenetileg a lin khez tartozó s or. Ha t eli van a s or, a kül dõnek várakoznia kell Ha üres, a fogadónak kell várakoznia. 3. Végtelen kapacitású sor: a küldõnek sohasem kell várakoznia Vegyük é szre, a z ut óbbi ké t e setben a kül dõ ne m t udja, va jon ü zenete m egérkezett-e. Szüksége l ehet n yugtázás v álaszüzenetre. A z i lyen k ommunikációt ne vezzük a sszinkron kommunikációnak. 5.14 Speciális esetek Az eddigi kategóriákba tisztán nem besorolható esetek is lehetségesek. • A kül dõ elküldi az üz enetet, erre ni ncs korlátozás. Ha azonban fogadó n em veszi az üzenet, miközben a küldö újabb üzenetet küld, az elõzõ üzenet elvész. E séma elõnye: mivel nincs korlátozás a

küldésre, hosszú üzeneteket nem kell megismételni. Hátrány viszont, hogy a biztos üzenetmegérkezéshez szinkronizáció szükséges. • A a z üz enetküdés h alasztódik, a míg a z e lõzõre vá lasz ne m érkezik. P l a T hoth operációs r endszerben e zt a s émát v alósítottk m eg: a P p rocessz ü zenete k üldve blokkolódik, amíg egy rövid nyugtázás választ nem kap. 5.2 IPC mechanizmusok felsorolása, összevetése Elõször felsorolunk néhány mechanizmust, rövid ismertetéssel, majd összevetjük õket. 5.21 A klasszikus message rendszer A Unix megvalósítással külön fejezetben foglakozunk. A V AX/VMS i smeri a névnélküli ( idõleges) és a p ermanens mailbox koncepciót. E zekre példákat a mailado.c és a mailvevoc programokban láthatunk 5.22 Csõvezeték Alapvetõ, kor ai Unix konc epció ez. E lsõ m egvalósításai fájlokon k eresztül t örtént, a kommunikáló pr ocesszek s zekvenciális vé grehajtásával. A m ai c sõvezeték

m egvalósítás jellemzõi: • Az imp lementáció le het fájlokon keresztül, m emórián át s tb., a felhasználó s zámára transzparens módon megvalósítva. • FIFO jellegû, azaz • mindkét irányba mehetnek üzenetek; • amit be ír e gy processz, a zt ki i s ol vashatja, ki olvasva a z üz enet ki kerül a csõbõl. • A né v né lküli c sõ c sak s zármazás s zerint eg y p rocessz cs aládba t artozó p rocesszek között le hetséges. A n yitott c sõ n yitott a datfolyamnak ( stream) s zámít, a g yermek processzek ö röklik a le íróját ( descriptor). A felhasználói f elület a steram I/O függvényei. A névnélküli csõ (pipe) koncepciót mind a Unix, mind a VMS processzek használhatják. A Un ix-ban m egvalósított a n evezett cs õ ( named p ipe) i s ( általában a f ájl k oncepciót i s használva), erre példaprogramokat látunk az ado.c és a vevoc programokban A c sõvezetékeken ke resztüli kom munikáció s zimmetrikus, a

szinkron, a datküldéses, vá ltozó üzenetméretû j ellegû. A né vnélküli pi pe-ok di rekt, a n evezett pi pe-ok i ndirekt, ope rációs rendszer tulajdon jellegûek. 5.23 Fájlokon keresztüli kommunikáció Szekvenciális pr ocesszek köz ötti, r égi, természetes m ódszer. T emészetesem p árhuzamos processzek között is lehet fájlokon, adatbázisokon keresztüli kommunikáció. Jellmezõi: indirekt, o perációs r endszerhez köt õdõ (operációs r endszer tulajdonú), szimmetrikus, aszinkron, adatküldéses, változó üzenetméretú kommunikáció. Az e ddig t árgyalt kom munikációs m ódszerek ké zenfekvõek vol tak. T ermészetesen va nnak további módszerek is, melyek talán nem tûnnek olyan természetesnek. 5.24 Osztott memória (Shared Memory) • Az operációs rendszerek természetszerûleg használják az osztott memóra koncepciót: gyakori, hog y a pr ocessz kont extusok kód r észe os ztott m emóriában va n, ne m ismétlõdik

processzenként. • Az a lkalmazások i s ha sználhatják! M ind a kód, m ind a z a dat m egosztás megvalósítható! Unix megvalósítással részletesebben is foglakozunk majd. Jelemzés: i ndirekt, s zimetrikus, a datküldéses, f ix hos szú ü zenetes, z éró buf ferelt ( randevút mégsem kívánó, mert többnyire operációs rendszerhez kötõdõ!) 5.25 A VAX/VMS logikai név rendszere Miután a logikai nevek kifejtése a processzeken belül történik, alkalmasak kommunikációra. Itt n em a f ájlokon k eresztüli kom munikációra g ondolunk, ha nem a rra, ho gy l ehetséges informálni e gy pr ocesszt va lamilyen t ény fennállásáról, va gy é ppen a f ennálás hi ányáról, azzal, hogy létezik-e, vagy sem egy logikai név. Indirekt, ope rációs r endszer t ulajdonú, a sszimmetrikus, f ix ü zenethosszos, r andevú né lküli zéró bufferelt. 5.26 Kommunkiáció a burok környezete (shell environment) segítségével Bár a bur ok vá ltozók (

szimbólumok) a pa rancsértelmezõ s zintjén k ifejtõdnek ( ezzel n em jutnak be a pr ocesszbe), a z ör öklõdõ kö rnyezet a pr ocesszek f eldolgozhatják ( emlékezzünk arra, ho gy a fõ pr ogram a ne ki adott argumentumok mellett a z environment-et is lekérdezhetik. Lásd: getenv rendszerhívás) Ez is egy lehetséges módszer tehát Direkt, aszimmetrikus, zéró bufferelt, adatküldéses, változó üzenethosszos. 5.27 Esemény jelzõk, szemaforok Alapvetõen a szinkronizáció és a kölcsönös kizárás mechanizmusai ezek, de a felhasználó is használhatja ezeket kommunikációs célokra. A VAX/VMS esemény jelzõirõl már volt szó, a szemafor mechanizmust késõbb részletesebben tárgyaljuk. Indirekt és operációs rendszerhez kötõdõ, vagy direkt, szimmetrikus vagy aszimmetrikus, zéró bufferelt, fix üzenet-hosszú. 5.28 Szignálozás, szignálkezelés Bár a s zignál r endszer is a f eltételek ( condition ex eptions) k ezelésére, a s

zinkronizációra implementált rendszer, alkalmas processzek közötti kommunikációra. A lekezelhetõ szignálok kiküldése, a zok l ekezelése i nformáló ha tású l ehet. T ovábbiakban ne m r észletezzük, de a zt hiszem, érthetõ a dolog. Direkt, egyirányú, végtelen kapacitású soros. Két további kommunikációs mechanizmust csak megemlítünk: ezek a számítógépes hálózatok tárgyalásakor részletezhetõk. 5.29 A BSD socket koncepció A N etworking által " kikényszerített" konc epció, de e gyetlen hos t-on ( a U nix dom ain) i s alkalmas IPC mechanizmus. 5.210 A Remote Procedure Call mechanizmusok A Networking és a Distributed Processing következménye, ma nagyon divatos koncepció. 5.211 Az IPC mechanizmusok összevetése Az ös szehasonlítás s orán ké t s zempontot vi zsgálunk, e sszerint m inõsítjük a z e gyes mechanizmusokat. A z e gyik s zempont a g yorsaság (speed), a mi l ehet l assú, köz epes va gy gyors ( slow, m

oderate, f ast), a m ásik, az á tvihetõ i nformációmennyiség (amount of information), ami kicsi, közepes vagy nagy (small, medium, large) lehet (vegyük észre ezek fuzzy jellegét). 5.1 táblázat Ssz. Mechanizmus 1. Messages 2. Csõ 3. Fájlok 4. Osztott memória 5. Logikai nevek 6. Environments 7. Flags, semaphores 8. Signals 9. Sockets 10. RPC * A hálózattól függõ Speed Fast Moderate/Slow Slow Fastest Fast Fast Fastest Fast Moderate* Moderate* Amount of inf. Medium Medium (Large) Large Medium Small Small Very Small Small Medium Medium 5.3 A Unix üzenetsor (message queue) és osztott memória (shared memory) rendszere 5.31 IPC - messages Az SVID Unixokban a processzek tudnak ugyanazon a gazdagépen (hoston) • készíteni üzenetsorokat (message-queue) (msgget() rendszerhívással), • küldeni üzeneteket a sorokba (msgsnd() rendszerhívással), • kiolvasni üzeneteket a sorokból (msgrcv() rendszerhívással), • vezérelni a sorokat

(msgctl()rendszerhívással). A message-queue mailbox jellegû, az OS által ismert, az OS-hez kötõdõ objektum. Az $ ipcs paranccsal jellemzõi lekérdezhetõk. (Az ipcs parancs a n emcsak az üzenetsorokról, hanem az osztott memória- és a szemafor objektumokról is ad jelentést. Kérdések merülhetnek fel bennünk: 1. Hogyan ké szíthetünk üz enet s ort? E zt c sak a ké szítõ pr ocessz i smeri, va gy m ás processzek is? Hogyan azonosítják a processzek a sorokat, ha már vannak? Meddig él egy üzenet sor? Megszüntethetõ? A védelmi problémákat hogy kezelik? 2. Hogyan írhatunk üzeneteket már ismert, azonosított sorba? Csak a készítõ írhat bele? Ha ne mcsak a z, a kkor m ás pr ocessz hogy an azonosíthatja? Í rásengedélyek, hozzáférések hogyan állnak? Milyen üzenettípusok lehetnek? 3. Hogyan i nformálódhatunk üz enet s orokról? Létezik m ár? H ány üz enet va n b enne? Kezelhetjük? 4. Egy processzben üzeneteket akarok olvasni Ehhez

azonosítanám Mi legyen, ha nincs benne üzenet? Várjak, exitáljak? Általános tudnivalók: • msgget() üzenetsor készítés, azonosítás (msgid az azonosító), • msgctl() létezõ msgid-jû sort lekérdez, átállít, megszüntet, kontrollál, • msgsnd() azonosított sorba adott típusú, adott méretû üzenetet tesz, • msgrcv() azonosított sorból adott típusú üzenetet vesz. Amit kivett, azt más már nem érheti el! Tanulmányozzák a m an s egítségével a f ent r endszerhívásokat! S zükséges b eleértett állományok (tanulmányozzák ezeket is! : • #include <sys>/types.h> • #include <sys/ipc.h> • #include <sys/msg.h> Üzenetsor készítés, azonosítás • Minden üz enetsornak v an a zonosítója é s kul csa ( ID|msgid, k ey). Ú j üz enetsor készítése során kell választania kulcsot, meglévõ üzenetsor azonosítására (asszociálás) használni kell a kulcsát. • Az üz enetsoroknak va n t

ulajdonosa, c soporttulajdonosa ( uid/gid t artozik hoz zá): annak a pr ocessznek a z ui d/gid-je, a melyik k észítette. A k ontrolláló ms gctl() rendszerhívással a t ulajdonosságok (a v édelmi kor látozásokat f igyelembe vé ve) átállíthatók. ( Figyelem! Az üz enetsor a z ope rációs r endszerhez köt õdik, de a z i tteni tulajdonosság a U nix-ok s zokásos f ájl-tulajdonossági kategóriával egyezik! A hozzáférések is a fájlhozzáférési kategóriáknak megfelelõ.) • Vannak írás/olvasás engedélyezések is a tulajdonossági kategóriákra, és vannak • korlátai (max méret, max üzenetszám, üzenet max méret stb), továbbá • paraméterei. Mielõtt t ovábbmegyünk, né zzünk e gy egyszerû e setet. T ételezzük f el, hogy ké szítek e gy üzenetsort, és teszek bele két üzenetet az alábbi programocskával: msgcreate.c Ezután a $ ipcs valami ilyet ad: indvd 12% ipcs IPC status from /dev/kmem as of Wed Sep 7 18:11:04 1994 T ID KEY

MODE OWNER GROUP Message Queues: q 50 0x0009fbf1 --rw-rw-rwvadasz staff Shared Memory: m 0 0x000009a4 --rw-rw-rwroot sys Semaphores: indvd 13% Az ipcs eredménytáblázatán a T oszlop a processzközti kommunikációs mechanizmus típusát mutatja: a q az ü zenetsorokat j elzi ( fenti p éldában cs ak eg y ü zenetsor v an), az m az o sztott memória obj ektumokat (ebbõl i s c sak egy va n i tt). A T os zlopban l ehetne m ég s i s: e z szemafort jelezne. Az ID oszlop a megfelelõ objektum (üzenetsor, osztott memória, szemafor) azonosítóját, a K EY os zlop a kul csát, a M ODE os zlop a f ájlrendszerbeli s zokásoknak megfelelõ hozzáféréseket, az OWNER ill. GROUP oszlopok a tulajdonosságokat mutatja Ha lefuttatjuk a msgcreate.c-bõl készült processzt, megnézhetjük a párját: msgrcvc Futtassuk ezt is. Ha most újból kérek $ ipcs -t, azt kell kapjam, mint amit fönt is kaptam Az egyszerû esettanulmányhoz tartozik még egy kis program: msgctl.c Ez megszünteti az

üzenetsort, "takarít". Ha t udom, ho gy l étezik 50-es azonosítójú, és 0x 009fbf1-es kul csú üz enetsor, akkor azt m ás progamból is megszüntethetem beírva az alábbi rendszerhívásokat: msgid = msgget(0x0009fbf1,NULL); msgctl(50,IPC RMID, NULL); Vagy az alábbi két rendszerhívással: msgid = msgget(0x0009fbf1,NULL); msgctl(msgid,IPC RMID, NULL); Takarítani l ehet m ég az i pcrm b urokparanccsal i s. M iután en nek p araméterezése rendszerfüggõ, tanulmányozzák a parancsot az adott rendszer on-line manuel-jében! A renszerhívások prototípusai #include <sys/types.h> #include <sys/ipc.h> #include <sys/msg.h> int msgget(key t key, int flag); int msgsnd(int msqid, const void *msgp, size t msgsz, int msgflg); int msgrcv(int msqid, void *msgp, size t msgsz, long msgtyp, msgflg); int msgctl(int msqid, int cmd, ./* struct msqid ds buf /); int A kreáló/asszociáló hívás: id=msgget(key, flag); A r endszerhívás c élja:

kreáljon üz enetsort, v agy azonosítson ( asszociáljon r á) m eglévõ üzenetsort, hogy azt késõbb használhassok. Az üzenesorhasználat elsõ rendszerhívása tehát ez kell legyen. Az msgget() hívás a key kulccsal azonosított üzenetsor azonosítójával tér vissza Ezt az azonosítót használhatjuk majd a késõbbi üzenetsorkezelõ rendszerhívásokban. Ha új üz enetsort a karunk kr eálni, a k ey k ulcsnak v álasszunk e gy olyan ér téket, am ilyen kulcsú üz enetsor ne m l étezik a r endszeren. Legyen t ehát e gyedi H a asszociálni a karunk, akkor pedig éppen a kívánt kulcsot állítsuk be!. A flag-be beírhatjuk a "hozzáféréseket". A flag=0664 pl azt jelenti, hogy mind a tulajdonos, mind a c soporttulajdonos pr orocesszel í rhatják é s ol vashatják a z üz enetsort, a t öbbiek c sak olvashatják. A sszociáláskor ne m a dhatunk m eg "nagyobb" j ogokat, m int a mit a ké szítéskor elõírtunk. A f lag-be bi tenkénti va ggyal

beírhatjuk a z IPC CREATE m akrót i s: flag= 0666 | IPC CREATE; E kkor, ha ne m vol t m ég m eg e z a z üz enetsor, e lkészül, ha megvolt, asszociálunk rá. Az msgget() rendszerhívás hiba esetén negatív értékkel tér vissza (legtöbb rendszeren -1-gyel) és a z e rrno vá ltozót vi zgálhatjuk, m i i s vol t a hi ba oka . H a a f lag-be ne m í rtuk be a z IPC CREATE-ot, ak kor cs ak asszociálunk, a v kideríthetjük, létezik-e adott kulcsú üzenetsor. isszatérési é rték v izsgálatával í gy Az üzenetsorba író rendszerhívás int msgsnd(int msqid, const void *msgp, size t msgsz, int msgflg); Itt az msqid az msgget()-tel kapott azonosító. Az msgp pointer az üzenetet tartalmazó msgbuf struktúrára kell mutasson. Deklaráljunk tehát (és foglaljunk memóriát) struct msgbuf változót (pointert), amibe az üzenet elküldése elõtt azt "összeállíthatjuk". Ennek a struktúrának tagjait a s ys/msg.h fájlból ki vehetjük, va n e gy l ong m

type és e gy char m text[] t agja A z m type pozitív egész lehet, az üzenet típusát jelzi, és az üzenetet vevõ processz használhatja majd az üzenetek "válogatására". Be kell állítanunk a típust Az mtext tömbbe írhatjuk az üzenet-testet (legyen elegendõ hely itt!) az msgsz által meghatározott hosszon (írjuk be az üzenetet, utána állítsuk be a z m sgsz vá ltozót a hos szának m egfelelõen. V égül a z m sgflg-be b eírhatjuk az IPC NOWAIT makrót, vagy 0-t. IPC NOWAIT-tel nem blokkolódik a hívó, ha az üzenetsor "megtelt" ( akár m ert m eghaladtuk a l ehetséges ü zenetszámot, ak ár m ert m eghaladtuk az üzenetsor hosszot), hanem rögtön visszatér a hívás (persze, nem küldi az aktuális üzenetet). Az üzenetvétel int msgrcv(int msqid, void *msgp, size t msgsz, long msgtyp, int msgflg); Az ms qid-vel az onosított s orról v eszi az el sõ ü zenetet és el helyezi az m sgp p ointer ál tal mutatott felhasználó

által deklarált struktúrába. Az üzenet ezzel "kikerül" az üzenetsorból a sor " átrendezõdik". A z msgp poi nter a z üz enetet f ogadó m sgbuf s truktúrára ke ll m utasson Deklaráljunk neki struktúraváltozót (pointert és helyet). Az msgsz csonkolja a vett üzenetet, állítsuk tehát elegendõ hosszra. Az msgtyp szerepe a következõ: ha 0, a kkor az elsõ üzenetet veszi. Ha pozitív érték, az elsõ ilyen típussal elküldött üzenete veszi Ha negatív, az abszolut értékével e gyezõ va gy k isebb t ípusúakból a l egkisebb t ípusú elsõ üzenetet veszi. Az msgflg specifikálja, m i t örténjen, ha kí vánt t ípusú üz enet ni ncs a s orban. H a IPC NOWAIT-et állítunk, a hívás azonnal visszatér (negativ értékkel persze), különben a hívó blokkolódik, míg a megfelelõ üzenet meg nem érkezik a sorba (vagy mig a sor meg nem szünik). (Lehetséges processzek szinkronizálása: várakozás míg üzenet nem érkezik).

Normális visszatérés esetén a visszaadott érték az üzenettestbõl átvett bájtok száma (tehát nem negatív érték). Az üzenetsor kontroll int msgctl(int msqid, int cmd, ./* struct msqid ds buf /); Változatos kont rollálási l ehetõséget bi ztosító hí vás a z m sqid üz enetsorra. A c md kül önbözõ "parancsokat" tartalmazhat, az elmaradható, vagy NULL pointerrel helyettesithetõ buf pedig a felhasználói címtartományban lévõ (felhasználó által deklarált változó) struktúra pointere. Ez a struktúra a következõképpen deklarált (vö. s ys/msgh, illetve a struct ipc perm deklráció a sys/ipc.h-ban található): struct msqid ds { struct ipc perm struct msg struct msg ulong t ulong t ulong t pid t pid t time t long time t long time t long long }; msg perm; *msg first; *msg last; msg cbytes; msg qnum; msg qbytes; msg lspid; msg lrpid; msg stime; msg pad1; msg rtime; msg pad2; msg ctime; msg pad3; msg pad4[4]; /* /* /* /* /* /* /* /* /*

/* /* /* /* /* /* operation permission struct */ ptr to first message on q */ ptr to last message on q */ current # bytes on q */ # of messages on q */ max # of bytes on q */ pid of last msgsnd */ pid of last msgrcv */ last msgsnd time */ reserved for time t expansion */ last msgrcv time */ time t expansion */ last change time */ last change time */ reserve area */ Tulajdonképpen a rról va n s zó, hogy e gy üz enetsor l étrehozása e setén a r endszer a ke rnel címtartományában felépíti ugyan a sor attribútumait tartalmazó struct msqid ds struktúrát, de mivel az kernel terület, a felhasználó közvetlenül nem láthatja: nem olvashatja, nem írhatja. Az IPC STAT paranccsal viszont a kernel struktúra elemeit átmásolhatjuk a felhasználó által már ol vasható buf -fal m utatott s truktúrába. A z IPC SET p aranccsal p edig a f elhasználói bufferbõl bizonyos elemeket átmásolhatunk a rendszer struktúrába: átállíthatjuk a tulajdonost, csoporttulajdonost,

a ho zzáféréseket, a s zuperuser m ég a s or teljes h osszát i s ( nézd a m anban!). A legfontosabb cmd parancs azonban az IPC RMID. Ekkor nem szükséges a buf paraméter (vagy legyen az NULL): megszünteti az üzenetsort. A POSIX üzenetsorkezelés Ediddigiekben a z S VID üz enetsorkezeléssel ka pcsolatos r endszerhívásokkal i smerkedtünk meg. E gyes rendszerek a P OSIX üz enetsorkezelõ r endszerhívásokat i s i smerik. Tanulmányozzuk e zeket i s! Látni f ogjuk, ho gy t ulajdonképpen a s zokásos f ájlkezelõ rendszerhívások (write(), r ead()) m ellet üz enetsor n yitó-záró r endszerhívásokat ke ll megismernünk. Az érintett hívások a következõk: mq open(), mq close() és mq unlink() Feladatok: Tanulmányozzák a szükséges rendszerhívásokat, header állományokat! Egy ki választott g épen készítsenek üz enetsort, amit a t anulócsoport ol vashat, a t ulajdonos írhat. K ulcsnak vá lasszanak e gy ke llemes he xadecimális s zámot, a

mit közöljenek né hány társukkal. A társaik számára tegyenek be üzeneteket a s orba, mindenkinek más-más üzenettípus-számot adva. A tipus számát is közöljék a társakkal Ez lehet pl a névsorbeli sorszám! A t ársak f uttassanak az ad ott g épen ü zenet-kiolvasó pr ogramot. Önkorlátozást ké rünk, mindenki csak a saját típusát vegye ki! A s or k reátora n éha n ézze m eg, k iolvasták-e m ár az ü zeneteket. H a i gen, m egszünteteheti a sort. Készítsünk csak magunknak üzenetsort, tegyünk bele néhány üzenetet, és egy másik process fordított s orrenben ol vassa ki a z ü zeneteket! ( Játszani ke ll a t ípusokkal! Nézd a m anuel-t!) Végül töröljük s sort, hogy ne maradjon szemét magunk után. Találjanak k i t ovábbi f eladatokat, a mikkel a z üz entesorok ha sználatát gy akorolják! A z üzenetsorok, ha l ogout-tal ki lépünk, m egmaradnak, a be nnük l évõ üz enetekkel együtt. M it gondolnak, ha a rendszer újra

boot-olják, elvesznek-e a sorok? 5.32 IPC - shared memory (osztott memória) A pr ocesszek u gyanazon g azdagépen os ztott m emória s zegmenseket készíthetnek/azonosíthatnak ( shmget() r endszerhívás), a z os ztott memória s zegmenseket kontrollálhatják (attributumait lekérdezhetik, megszüntethetik, shmctl() rendszerhívás), illetve a p rocessz v irtuális c ímtartományára le képezhetik a z o sztott s zegmenst ( shmat() rendszerhívás), megszüntethetik a leképzést (shmdt() hívás). A prototípusok #include <sys/types.h> #include <sys/ipc.h> #include <sys/shm.h> int shmget(key t key, size t size, int shmflg); void *shmat(int shmid, void shmaddr, int shmflg); int shmdt (void *shmaddr); int shmctl (int shmid, int cmd, ./* struct shmid ds buf /); A kreáció, asszociáció Az s hmget() r endszerhívás kr eál/asszociál a dott ke y ku lcsú o sztott m emória s zegmenst, aminek a bájtokban mért hossza size. Az shmflg szerepe nagyon

hasonlít az msgget()-beli flag szerephez: rendelkezik a h ozzáférésekrõl és a kreálás/asszociálás szétválastást oldhatjuk meg vele. E gy n em ne gatív s hmid a zonosítót a d vi ssza s iker e setén ( amit a t ovábbi hí vásokban használhatunk). S ikertelenség e setén ne gatív é rtékkel ( többnyire -1-gyel) t ér v issya ( és az errno vizsgálható). A leképzésés megszüntetése A leképzésben (shmat() hívás) a szegmenst "rákapcsoljuk" a processz címtartományára. Egy általunk vá lasztott t ípusú poi nterváltozó a hí vás vi sszatérési é rtékét m egkapja, é s e zután a z adott t ípusú a datszerkezet a poi nterváltozó s egítségével ha sználható, a t ípusra vona tkozó korlátozásokkal. H a ka rakter poi nternek a djuk a v isszatérési ér téket, ak kor az o szott szegmenst ka rakerek t ömbjének l áthatjuk, ha i nteger poi nternek, akkor i nteger t ömbnek, h a egy struktúra mutatónak: a truktúrát képezzül

az osztott szegmensre . Az shmat hívásban az elsõ argumentum nyilvánvalóan érthetõ (az shmget visszatérési értéke). A má sodik a rgumentum ( shmaddr) a zt s zabja me g, mil yen c ímtartományra k épezzük a szegmenst. H a s hmaddr= = NULL, ak kor a rendszer ál tal v álasztott el sõ l ehetséges címtartományra t örténik a l eképzés ( magyarul, a r endszerre b ízzuk a cí meket, és a címtartományunk bõvül ni f og). H a a z ne m N ULL, a kkor a z s hmaddr á ltal a dott c ím é s a z shmflg-ben S HM RMD-t b eállítás v agy éppen n em b eállítás e gyütt s zabja me g a címtartományt (nézd a man-ban pontosan hogy is van). Az shmdt() megszünteti a leképzést. Kiadása után az osztott szegmens nem "látható" tovább ügyeljünk a rra, ho gy argumentumának ne m a s zegmens a zonosítót, ha nem a vá lasztott pointert (amin az attach után "látjuk" a szegmenst) kell írni. Siker esetén 0-val, hinóba esetén -1-gyel tér

vissza. A kontroll Szerepe h asonlít az m sgctl() s zerepéhez, el sõsorban az IPC RMID p aranccsal a s zegmens megszüntetésére fogjuk használni. Nem részeletezzük, de itt is lekérdezhetõk az attribútumok (kernel területrõl átmásolás a felhsználói területen lévõ struct shmid ds típusú buf-ba) illetve néhány attribútum (uid, gid, mode) "változtatható" (nézd a man-ban). Gyakorló feladatok Az osztott memória szegmensek az OS szempontjából IPC mechanizmusok. Azonosításuk a message ill. semaphore mechanizmusokéhoz h asonló, a z ipcs shell p aranccsal ez ek i s lekerdezhetõek s tb., ez ért a m intaprogramocskákban ez eket a p rogramrészeket n em i s magyarázzuk. Nézzék a man segítségével a rendszerhívásokat, tanulmányozzák az include fájlokat. • #include <sys/ipc.h> • #include <sys/shm.h> Három példaprogramot ismertetunk az osztott memória használatra: • shmcreate.c egy v álasztott k ulccsal k

reál/azonosít o sztott me mória s zegmenst Azonosítója: shmid, amit kiiratunk. • shmctl.c az s hmcreatec-vel k észitett o sztott me mória s zegmens s tátusanak lekérdezésére, a IPC STAT p s zegmens m arancs egszüntetésére as alkalmazható p tátus l rogram. ekérdezést, IPC RMID p arancs a megszüntetést k éri. A s tátusbol cs ak a s zegmens m éretét és annak a processznek azonosítóját irja ki, amelyik utóljára operált a szegmensen. • shmop.c shmid-del a zonosít os ztott m emória szegmenst E zután a s egm ne vû pointerváltozót h asználva a p rocessz v irtuális c ímtartomanyába k apcsolja ( attach) a szegmest (shmat() rendszerhívás). Olvassa, irja ezt a címtartományt, végül lekapcsolja (detach) a shmdt() rendszerhívással). 6. Kölcsönös kizárás, kritikus szakasz (Mutual Exclusion, Critical Section) 6.1 Alapfogalmak, elvek, kívánalmak A pr ocesszek köz ötti k apcsolat l ehet e gyüttmûködés j ellegû ( kooperatio),

e z pr ocessközti kommunikációs ka pcsolatokat ( IPCs) kí ván. H a a ka pcsolat k onfliktusmentes erõforrásmegosztás, a kkor a z e rõforrásra ol vashatóság j ellegû hoz záférést ( reentrans kód , olvasható fájl stb.) kell biztosítani A vetélkedés erõforrás kizárólagos használatára kölcsönös kizárást, a szinkronizálás ütemezést kíván. Most az utóbbiakkal foglakozunk Arról va n s zó, hogy köz ös e rõforrásokért ve télkedõ, e gyüttmûködõ pr ocesszeknek l ehetnek kódrészei, me lyek f utása a latt k izárólagosságot k ell b iztosítani, v agy amikre ü temezést k ell megvalósítani. A kölcsönös kizárás (Mutual E xclusion) f ogalma: a köz ös e rõforrásokért v etélkedõ processzek k özül eg y é s cs akis e gy k apja m eg a j ogot az er õforrás h asználatra, en nek a hozzárendelésnek módszerei, eszközei, technikái. A kritikus szakasz (Critical Section) a folyamaton belüli kódrész, melyen belül a

kölcsönös kizárást meg kell valósítani, vagy amire az ütemezést meg kell valósítani. Belépési szakasz (entry s ection) a folyamaton b elül az a k ódrész, ah ol kéri az en gedélyt a kritikus s zakaszba való belépésre, m íg a kilépési szakasz (leave section) az a kódrész, ahol elhagyja a p rocessz a kritikus s zakaszt. A f olyamatoknak t ermészetesen l ehetnek nem kritikus szakaszaik is. A holtpont (deadlock) az a z á llapot, a mely akkor köve tkezhet b e, amikor ké t (vagy t öbb) folyamat egyidejûleg verseng erõforrásokért, és egymást kölcsönösen blokkolják. Tegyük fel, hogy P f olyamat k izárólagos h asználatra k éri a z X és Y e rõforrásokat, és az okat eb bena sorrendben kívánja használni. Ugyanakkor Q folyamat kéri az Y és X erõforrásokat, ebben a sorrendben. Ha P folyamat megszerezte az X erõforrást, Q folyamat pedig az Y-t, akkor egyi sem tud továbblépni. hiszen mindkettõnek éppen arra volna szüksége, amit a másik

foglal: ez a holtpont helyzet. Kívánalmak a probléma megoldásához 1. Biztonsági (safety) kívánalom: Valósuljon meg a kölcsönös kizárás: ha egy processz kritikus s zakaszában f ut, m ás pr ocessz ne léphessen be kr itikus szakaszába. (Egyidõben cs akis e gy k ritikus s zakasz f uthat.) T ermészetesen, e zalatt m ás processzek a b elépési s zakaszukat v égrehajthatják ( éppen a z a f ontos, ho gy azon ne jussanak túl). 2. Elõrehaladási (progress) kí vánalom: á ltalában ne m kr itikus s zakaszban é s ne m belépési s zakaszban f utó p rocessz n e b efolyásolja m ások b elépését. H a e gyetlen folyamat s incs kr itikus s zakaszában é s va nnak p rocesszek a b elépési s zakaszukban, akkor csakis ezek vegyenek részt abban a döntésben, hogy melyik fog végül belépni. Ráadásul ez a döntés nem halasztható végtelenségig. 3. Korlátozott várakozási (bounded w aiting) kí vánalom: ha e gy p rocessz be jelentette igényét a

belépésre, de még nem léphet be, korlátozzuk ésszerûen azt, hogy egy másik processz há nyszor l éphet be . E gy p rocessz s e v árakozzon a vé gtelenségig be lépésre azért, mert egy másik újból bejelentve az igényét megint megelõzi. 4. Hardver és platform kívánalom: ne l egyenek el õfeltételeink a h ardverre ( sem a CPU-k t ípusára, s zámára, s em a s ebességükre), a p rocesszek s zámára, r elatív sebességükre, az operációs rendszer ütemezésére stb. Az absztrakt probléma felfogható min t e gy termelõ-fogyasztó (producer-consumer) probléma: • Vannak t ermelõ ( producer) folyamatok, m elyek t erméket ( item, m essage et c.) állítanak elõ és behelyezik egy raktárba. • Vannak f ogyasztó f olyamatok, m elyet a t ermékeket k iveszik a r aktárból és felhasználják. • Van e gy k orlátozott t ermék-raktár ( item poo l, m essage buf fer). A kor látozás vonatkozhat a r aktár m éretére ( teli r aktárba t ermelõ n

em r akodhat, ü res r aktárból fogyasztó ne m ve het ki terméket: e z s zinkronizációs pr obléma, üt emezést kí ván). A korlátozás vona tkozhat a r aktár ha sználatára ( pl. e gyidõben t öbb t ermelõ ne m használhatja a r aktárt: e gyetlen "berakó gép" van, vagy egyidõben csak eg y f olymat, akár t ermelõ, ak ár fogyasztó h asználhatja a r aktárt: e gyetelen "be-kirakó gé p" va n stb.) A korlátozás a raktárhoz való hozzáférésre kölcsönös kizárási probléma A termelõ-fogyasztó problémának ismertek a v áltozatai, a k laszikus probléma, az író-olvasó probléma s tb. E zek különbözõ vá ltozatait f ogjuk p éldaként b emutatni a z e gyes megoldásokban. Az alap sémák Összefoglahatjuk most már a kölcsönös kizárás és a szinkronizáció alapvetõ programsémáit. A kölcsönös kizárást megvalósító procesz(ek) struktúrája az alábbi: 6.1ábra A szinkronizáció/ütemezés processzpárjainak

az alap struktúráit is bemutatjuk: 6.2 ábra 6.2 Egy kevésbé absztrakt probléma: nyomtatás kimeneti munkaterületrõl Multiprogramozási környezetben szokásos megoldás szerint a processzek, melyek nyomtatni akarnak, a nyomtatandó állományt (vagy annak nevét) egy kimeneti munkaterületre (spooler directory) helyezik. Egy szolgáltató processz - a printer daemon - ebbõl veszi a nyomtatandó anyagokat (vagy nevüket) és kezeli a nyomtató eszközt. Tételezzük fel, hogy van {A, B, C, .} processz készletünk, melyek n yomtatni akarnak Van egy P printer daemon processzünk is. Van egy spooler-directory-nk is, n számú "fiókkal" , a nyomtatandó f ájlok n evei ke rülhetnek e gy-egy fiókba ( legyen n e lég na gy, ettõl a kor láttól most eltekintünk.) Szükségünk van még két globális váltózóra: egyik az out, ami a következõ nyomtatandó f ájl n evét ta rtalmazó f iókra mu tat a s pooler d irectory-ban, másik az in, a mi a következõ szaban

fiókra mutat. Tételezzük f el a köve tkezõ he lyzetet, m ikor i s pr oc A é s pr oc B e gyidõben " nyomtatni szeretne" (6.1 ábra): 6.3 ábra Két processz egyidõben nyomtatna Tegyük f el, h ogy p roc A " elkapja" az in-t, a zt me gjegyzi, d e mie lõtt b eírná a fájl n evét és növelné az in-t, elveszik tõle a CPU-t, odaadva azt proc B-nek. Proc B v eszi az i n-t, a mi p illantnyilag 7 . B eírja a 7 s orszámú fiókba a s aját n yomtatandó fájlja nevét, növeli az in-t. Ezek után csinálja a saját dolgait Valamikor p roc A v isszakapja a v ezérlést, f olytatja, ah ol abbahagyta: b eírja a s aját nyomtatandó fájlja nevét a 7. f iókba (felülírva ezzel a proc B nyomtatandóját!), majd növeli az i n-t: e z m ár í gy 9 l esz. L áthatjuk, a 8 f iókba ne m i s ke rült f ájlnév! E zzel a pr oc A i s végzett a nyomtatásával, folytathatja saját dolgait. Beláthatjuk: a proc B outputja sohasem jelenik meg így, ugyanakkor a

8. fiókban határozatlan kérés v an a da emonhoz, hog y nyomtasson va lamit. A kr itikus s zakaszok vé delme n élkül gondok jelentekeztek, megsértettük a biztonsági kívánalmat. 6.3 Megoldások 6.31 Megszakítás letiltás (Disabling Interruts) A m egoldás l ényege: a b elépési s zakaszban letiltunk min den me gszakítást, a k ilépési szakaszban engedélyezük azokat. A m egoldás h átránya: c sak eg yetlen C PU es etére j ó ( 4. s zámú k ívánalom m egsértve) és a kritikus szakaszban bekövetkezõ hiba esetén elõáll a holtpont (dead-lock) helyzet. Ez a m egoldás nagyon veszélyes. Néha a kernel kódban használják, de csak nagyon rövid és nagyon jól letesztelt kritikus szakaszokra. 6.32 Váltogatás Ehhez a m egoldáshoz s zükséges e gy osztott turn változó. E z a vá ltozó nyomonköveti, a zt mutatja, ki következik. Két processzen bemutatjuk a v áltogatás lényegét Íme a két processz pszeudókódja (6.4ábra): Vegyük észre a

kritikus szakaszba való belépés while ciklusát! Amíg teljesül a while feltétele, 6.4ábra a vezérlés menete tevékeny várakozásban (busy waiting) a ciklusban marad! A nop() azt jelzi, ne csináljon semmit, azaz a ciklus magja egy no-operation instrukció. A me goldás m egsérti a 2 . s zámú k övetelményt: a s zigorú a lternálás miatt e gy processz egymás ut án ké tszer csak a kkor l éphet a kr itikus s zekciójába, ha k özben a má sik is á tfutott rajta. Azaz akkor is vár a belépésre, mikor a másik nincs a kritikus szakaszban: nem követi, hogy egy processz érdekelt-e vagy sem. A példában persze, sérül a 4 követelmény (csak két procsszre érvényes), bár a váltogatás kiegészíthetõ több processzre is. 6.33 Az érdekeltség nyomonkövetése A m egoldásban az osztott erd tömb je lzi, k i érdekelt a k ritikus s zakasz ( a k izárólagos erõforrás) elérésében. Alább láthatók (65ábra) a pszeudókódok (ismét 2 processzre, ami a 4

követelmény s érülését er edményezi, d e a t öbb p rocesszre v aló k iterjesztés i tt i s m egoldható lenne. 6.5ábra Sajnos, a m egoldás ne m m egoldás: a köl csönös ki zárás ug yan m egvalósul, de könn yen kialakulhat hol tpont ( 2. követelmény) H a u gyanis m indkét pr ocessz kör ülbelül e gyidõben bejelenti érdekeltségét, mindkettõ tevékeny várakozásban marad a while ciklusában. Pusztán az érdekeltség figyelembe vétele semmiképp sem nem elegendõ! 6.34 Egymás váltogatás az érdekeltség figyelembevételével A " ki köve tkezik" ( turn vá ltozó) é s a "lock vá ltozó" (lásd k ésõbb) konc epciók kombinációjaként D ekker ( holland ma tematikus) a jánlott e lõször jó megoldást: e z a z irodalomban Dekker algoritmusaként ismert. Peterson még egyszerûbb módszert ajánlott 1981-ben, ami elavulttá tette Dekker algoritmusát. Nézzük P eterson m egoldását, am i l ényegében e gymás v

áltogatása az ér dekeltség figyelembevételével. Az érdekeltség figyelembevétele javítja a puszta váltogatás hibáját Most már csak a 4. követelmény sérül (csak 2 processzre érvényes a bemutatott példa, de belátható a k iterjeszthetõség s ok p rocesszre, és s zámít a m egoldás a p rocesszek k orrekt ü temezésére). Nézzük a kódokat (6.6ábra) 6.6ábra Képzeljük el azt a helyzetet, amikor egyik processz sincs kritikus szakaszában és az i-edik be akar l épni. Beállítja s aját ér dekeltségét, és a m ásik k övetkezõségét U tána r áfut a t evékeny várakozás w hile ci klusára ( itt a N OP-ot ü res u tasítás k épviseli h elyszûke mia tt), é s miv el a másik ne m é rdekelt, t ovábbjutva be léphet a kr itikus s zakaszába. H a m ost a j -edik s zeretne belépni, a while-jában meg kell várnia, míg az elsõ a kritikus szakaszából kilépve megszünteti az érdekeltségét. Ha m indkét pr ocess kb. e gyidõben l épne be ,

akkor m indkettõ be jelnti é rdekeltségét, m ajd mindkettõ bejegyzi a turn-be a másik számát. Amelyiknek ez utoljára sikerült, az vesztett! A másiknak ug yanis a while-ja " sikertelen" l esz, azaz t ovább l éphet. A t urn-be ut oljára í ró viszont a while tevékeny várakozó ciklusában marad. Nem jelent gondot az sem, ha az egyik processznek cs ak az ér dekeltség b eírás s ikerül, utána p edig el veszik t õle a C PU-t. E kkor ugyan a másik "blokkolódik" a tevékeny várakozása ciklusában, de elõbb utóbb visszakapja a CPU-t a z e gyik (4. K övetelmény s zerint e rre bi ztosan ne m s zabadna s zámítanunk), és beállítva a turn-öt továbbengedi a másikat. 6.35 A Bakery algoritmus: a sorszámosztás Az a lgoritmus a ne vét e gy vá sárlókkal z súfolt pé kségben a s orszámosztásos ki szolgálás rendjétõl ka pta ( hogy m iért pont pé kség? K i t udja?) K ésõbb l átni f ogjuk a so rszámosztóeseményszámláló

mechanizmust, annak az alapgondolatát valósítja meg a b akery algoritmus, meglehetõsen e gyszerû e szközökkel. ( Kedves ol vasó! V ajon é szreveszi-e b akery al goritmus és a sorszámosztó-eseményszámláló különbségét?). Az e lgondolás szerint b elépve a bol tba m inden vásárló k ap egy s orszámot, é s a l egkisebb sorszámmal rendelkezõt szolgálják ki elõször. Az a lábbi ps zeudókód (6.7ábra) a z i -edik p rocesszt m utatja V együk és zre az o sztott adatstruktúrákat ( erd, s ), a zt, hog y az é rdekeltség i tt ne m a kr itikus s zakaszra, ha nem a sorszámhúzásra vonatkozik, valamit ezek inicializálását! 6.7ábra A k ritikus s zakasza el õtt a p rocessz b ejelenti ér dekeltségét a s orszámhúzásban, m ajd sorszámot húz . Sajnos, miután a z s [i] é rtékadás ni ncs " védve", ne m garantált, ho gy ké t processz ne kaphassa ugyanazt a sorszámot. Ha ez elõfordulna, akkor az algoritmus szerint a "kisebb ne

vû" ( kisebb pi d-û) le sz a k iszolgált ( lásd a má sodik w hile-ban a j < i r elációt). Miután a pr ocessz ne vek, a pi d-ek egyediek és köz tük a ki sebb m int r endezési r eláció egyértelmû, az algoritmusunk determinisztikus lesz. A sorszámhúzás után a processz törli az érdekeltségét a s orszámhúzásra. E zután a f or c iklusban m inden pr ocesszt vi zsgál! A z e lsõ while-ban s aját ma ga miatt n em v árakozik, d e t alálhat m ás p rocesszeket, ak ár m agánál "kisebbet" i s, a kik éppen s orszámot húz nak, e kkor vá rakozik.Ha a z üt emezés kor rekt ( 4 követelmény?), elõbb-utóbb túljut ezen. A második busy waiting while ciklus "megfogja", ha van ná la ki sebb s orszámú pr ocessz ( persze a 0 s orszám ne m s zámít, m árpedig m ind a kiszolgáltak, mind a boltba be sem lépõk ilyenek), vagy ha az azonos sorszámú nála kisebb pid-del r endelkezik. A kritikus s zakaszból va ló ki lépés e

gyszerûen a s orszám nul lázásával jelezhetõ. 6.36 Zárolásváltozó használata Adott egy osztott lock változó, kezdeti értéke false, ami tesztelhetõ és beállítható (false és true értékeket v ehet f el). H a eg y p rocessz b e ak ar l épni k ritikus s zakaszába, t eszteli a l ock változót. H a az f alse, b eálítja true-ra, é s be lép a kr itikus s zakaszba H a az be állított, a kkor ciklusban t esztelve a v áltozót ( busy waiting), m egvárja, m íg va laki l enullázza. F ontos követelmény, h ogy a t esztelés és b eállítás k özött a v ezérlést n e v ehessék el a p rocessztõl, különben megsértjük az 1. számú követelményt (mint a spooler példában is) A TSL instrukció Sok pr ocesszornál, kül önösen a zokon, m elyeket e leve t öbbprocesszoros r endeszerkhez terveztek, lé tezik e gy a tomi test-and-set-lock (TSL) i nstrukció, a mi a köve tkezõképpen dolgozik. B ehoz egy m emóriacímen l évõ értéket e gy r egiszterbe,

és e gy t rue értéket t esz a memória r ekeszbe, m ajd a b ehozott ér tékkel visszatér. A r egiszterbe h ozás, a l etárolás müveletére és visszatérésre garantált, hogy "oszthatatlan", egyetlen más processzor sem érheti el a me mória r ekeszt, a míg a z in strukció v égre nem h ajtódik. Á ltalában a T SL-t v égrehajtó CPU bl okkolja a bus zt, amíg a T SL-t v égrehajtja. A 68á brán m egadjuk a kr itikus s zakasz védelmét biztosító kódrészletet és a TSL instrukció "forgatókönyvét" is. Figyeljük a kritikus szakasz végét: a zárolásváltozó szokásos értékadással (MOVE instrukcióval) "tisztítható". 6.8ábra Ha a z árolásváltozó ér téke t rue, v alamelyik p rocessz a k ritikus s zakaszában v an. E gy m ásik processz t evékeny v árakozás w hile T SL-je u gyan r endre át írja a t rue értéket, d e n em t ud továbblépni, egészen addig, míg a kritikus szakaszból ki nem lép az érintett

processz A hátrány: m egsértettük a 4. köve telményt, ki kötésünk van a hardverre v onatkozólag (nincs minden C PU-nak T SL instrukciója). É s mé g e gy p robléma: n em f eltétlenül te ljesül a 3 követelmény: i gaz, e xtrém üt emezésnél, de e lõfordulhat, hog y e gy p rocessz a ki lépési szakaszát ( lock= false;) végrehajtva, ú jból n agyon g yorsan el jutva a b elépési s zakaszába többször megelõz egy másikat. A SWAP instrukció Némely p rocesszornak van o szthatatlan " cserélõ" ( swap) i nstrukciója. A z árolásváltozó használat ezzel is megoldható (lásd a 6.9ábrán a pszeudókódot, benne a swap forgatókönyvét is). 6.9ábra Látható, h ogy itt a b eállítás ( swap) u gyan elválik a te szteléstõl ( until), közben e lvehetik a CPU-t a pr ocessztõl, de e z ne m j elent g ondot. Figyeljünk f el a rra, ho gy a m ehet m inden processznek saját v áltozója, a s wap-ben k ap i gazán ér téket ( a t esztelés e

lõtt), u gyanakkor a közös l ock is ka p é rtéket. A kr itikus s zakasz vé gén a l ock a s zokásos é rtékadással ka pja a false-t, e zzel e setleg t ovábbenged m ás pr ocesszt a do unt il c iklusából. Itt i s s érül a 4 követelmény ( nincs m inden C PU-nak at omi s wap-je), és s érülhet a k orlátozott v árakozási követelmény is. Korlátozott várakozási követelményt is kielégítõ zárolásváltozóhasználat A fent b emutatott z árolásváltozót használó algoritmusok j avíthatók, hog y a 3 . k övetelményt teljesítsék. A T SL in strukciós v áltozatot e gészítjük k i, e zen mu tatjuk b e az e lgondolást A z elgondolás lényege az, hogy nemcsak az operációs rendszer ütemezõje ütemez, hanem maguk a belépési és kilépési szakaszok is, azaz a kritikus szakaszokért vetélkedõ processzek is. Az os ztott l ock zárolásváltozón kí vül ha sználjuk a z e rd t ömböt i s, f alse é rtékekkel inicializálva. Az erd elemei itt a

zt jelzik, hogy egy-egy processz a b elépési szakaszában van Tekintsük meg az algoritmust (6.10ábra) 6.10ábra A p rocessz cs akis ak kor l éphet b e k ritikus s zakaszába, h a er d[i]= = false, v agy h a megy==false. Belépési szakaszában az erd[i]-t true-ra állítja, az elsõ igénybejelentésekor tehát valószínûleg a megy dönt. A megy-et pedig csak a tsl állíthatja false-ra A megy garantálja a kölcsönös ki zárást. A z e lõrehaladás i s bi ztosított, hi szen a ki lépési s zakaszában e gy m ásik procesz v agy a z árolásváltozót, v agy a mi p rocesszünk e rd e lemét tis ztítja. B ármelyiket is billenti, a m i pr ocesszünk t ovábblép a kr itikus s zakasza f elé, é s m ár nem bl okkolja s aját magát. A kor látozott vá rakozás pe dig a köve tkezõképp bi ztosított: a ki lépési s zakaszában mindenprocessz ciklikus rendben (i+1, i+2, ., n-1, 0, 1, ,i -1) keres belépésre várakozó más processzt ( amelyikeknek az er d el eme t rue),

és az el sõt eb ben a r endben kiválasztva az er d elemének billentésével "továbbengedi" ezt és csakis ezt a b elépési szakaszából. Ha nem talál várakozót, akkor zárolásváltozó false-ra állításával engedélyezi (akár saját magának az újbóli) belépést. A ciklikus vé gignézés p ersze vé ges, h a a z i tteni w hile-ban j = = i, a kkor m ár ne m érdemes nézni, van-e belépésre várakozó processz. 6.37 A tevékeny várakozás (busy waiting) hátrányai A me gszakítás le tiltást k ivéve min den e ddigi me goldásnál a b elépési s zakaszban eg y-egy processz ciklusban várakozott, hogy végre beléphessen. Sokszor csak egy NOP-ot hajt végre, majd újra tesztel, mindenesetre használja a CPU-t, hátráltatva más processzeket. Felléphet a priority inversion probléma is: képzeljük el, hogy van két processzünk, processz H magas p rioritással, p rocessz L al acsonnyal. A z ü temezési s zabályok s zerint a m agasabb

prioritású processz mindíg megkapja a CPU-t, ha igényli. Egy bizonyos pillanatban legyen L a kr itikus s zakaszban, e zalatt H vá ljon f utásra ké sz á llapotúvá, a busy waiting ciklusa e lõtt kevéssel. Megkapva H a CPU-t, tesztel és vár ciklusban, és mivel magasabb a prioritása, nem engedi szóhoz jutni L-t, hogy az kijusson a kritikus szakaszából, felszabadítva H-t a várakozó ciklusból. N yilvánvaló holtponthelyzet alakult ki M egoldás pe rsze a dinamikus pr ioritás állítás, de pl valós idejû processzeknél az nem valósítható meg. Más megoldás is kell! A C PU i dõ v esztegetése h elyett al kalmazhatunk sleep és wakeup rendszerhívás pá rokat! A busy waiting helyett a várakozó processz sleep hívással blokkolt állapotba megy, ott is marad, míg egy másik processz a wakup hívással fel nem ébreszti. Ekkor persze újra kell ellenõriznie a kr itikus s zakaszba va ló be lépés l ehetõségét, d e a ddig i s ne m vesztegeti a C PU i dõt.

Ilyen megoldásnál persze ügyelni kell arra, hogy valaki kiadja a wakup-ot, és a wakup szignál ne vesszen el! Ismerkedjünk m eg m ég egy fogalommal! S zakirodalomban ha sználhatják a spinlock kifejezést. E z va lójában bus y w aiting-et ( spin) h asználó s zemafor ( a s zemafort l ásd al ább!) Elõnye az, ho gy ne m k ell c ontecxt s witch, m ikor e gy pr ocessz vá rakozik e gy l ock-on. H a rövidek a várakozások, többprocesszoros rendszeren elõnyös lehet. 6.38 A szemaforok 1965 kör ül D ijkstra j avasolta a szemafor ( semaphore) m echanizmust a k ölcsönös k izárások megoldására [ E.W D ijkstra: C ooperating S equential P rocesses i n F G enuys e d Programming Languages, academic Press, NY, 1968, pp43-112.] A klasszikus szemafor egy pozitív egészt tartalmazó változó és egy hozzá tartozó várakozási sor (melyen processzek blokkolódhatnak). A szemaforon - kivéve az inicializációját - két operáció hajtható végre. Az operációk

atomiak Ez két dolgot jelent. Egyik: garantált, hogyha egy operáció elindult, más processz nem férhet a szemaforhoz, míg az operáció be nem fejezõdõtt, vagy a hívója blokkolódott. A másik: a szemaforra várakozó, blokkolódott processz "felébredve" végre kell tudja hajtani azt az operációt, amelyikre blokkolódott. A két operáció: DOWN operáció (P: passeren), ezen blokkolódhat a hívója, UP operáció (V: vrijgeven [vrejhéfen]), ez s zignáloz, ho gy felébredjen e gy bl okkolódott processz (6.11ábra) 6.11 ábra Megjegyzés: ha S == 0, akkor biztos, hogy egy processz a kritikus szakaszban van. A s zemaforral a kr itikus s zakasz vé delme, i lletve a s zinkronizáció a köve tkezõ l ehet (6.12ábra): 6.12ábra Dijkstra professzor a szemafor megvalósításáról (implementációjáról) nem rendelkezett. Nem mondta ki, hogyan kell megvalósítani a várakozási sort, mit jelent a blokkolódás stb. Így az várakozás l ehet t evékeny

várakozás i s, a s zignálozás a z e bbõl va ló ki billentés ( spinlock szemafor), de a v árakozás l ehet a z ope rációs rendszer á ltal bi ztosított va lódi bl okkolódás i s (sleep r endszerszolgáltatással), a s zignálozás a k ernel á ltal b iztosított w akeup h ívással (blokkoló szemafor). A D ijkstra f éle s zemafor ú gynevezett s zámlálós ( counting) s zemafor, d e imle mentálhatunk bináris szemafort is. Nézzük ezeknek a változatoknak a lehetséges implementációit! 6.381 Bináris spinlock szemafor megvalósítás Ez a szemafor false és true értékeket vehet csak fel (azaz nem pozitív egészeket), és tevékeny várakozással oldja meg a "blokkoklódást". Íme a lehetséges implementációja (613ábra), ahol is a k ét o peráció atomiságát az el õzõekben t árgyalt és m inden k övetelményt k ielégító megoldások valamelyikével biztosítjuk (ez persze csak jelezve van megvalósítás kódjában): 6.13ábra 6.382

Tevékeny várakozású számlálós szemafor Implementációját ennek is bemutatjuk a 6.14ábrán: 6.383 Blokkolós számláló szemafor Ennek is megadjuk egy implementációját, méghozzá a Dijkstra féle két operációt kiegészítve egy harmadikkal, az nc ount ope rációval ( 6.15ábra) E z na gyon ha sznos ope ráció a szemaforhoz rendelt várakozási soron blokkolt processzek pillanatnyi számát adja vissza. 6.15ábra 6.384 Termelõ/fogyasztó probléma megoldása szemaforokkal Tételezzük fel a következõket: • Több termelõ folyamat lehet, számukat nem korlátozzuk. • Szintén nem korlátozott a fogyasztók száma. • Korlátozott a raktár mérete: N számú hely van benne. • Korlátozott a raktárhoz való hozzáférés: csak egy "ki-berakó gép" van. Természetes k orlátozási követelmény: b etelt r aktár es etén a t ermelõk b lokkolódjanak, ü res raktár esetén a fogyasztók blokkolódjanak. A pszeudókódok a 6.16 és

617ábrákon láthatók: 6.16ábra 6.17ábra 6.39 Sorszámosztó és eseményszámláló (Sequencer & Eventcounter) [Reed , 1979] 6.391 Alapfogalmak Az alapgondolat szerint egy sorszámosztó automata segíti egy szolgáltatás igénybevételének sorrendjét: a f ogyasztó " tép" e gy s orszámot és v ár a s zolgáltatásra, am íg a s or r ákerül ( a bakery a lgoritmusban me gismertük e zt a mó dszert). A s zolgáltató e gy veremben ta rtja a kiszolgált f ogyasztó s orszámát: a nnak t etején van a z ut óljára ( vagy az é ppen)kiszolgált fogyasztó sorszáma. A szükséges objektumok és a rajtuk végezhetõ operációk: S: sequencer nem csökkenthetõ integer változó, 0-ra inicializálva. E: eventcounter sorszámok veremtára. Operáció S-re: ticket(S); visszatér a következõ sorszámmal. Operációk E-re: read(E); visszaadja az E pillanatnyi értékét. advance(E); növeli az E pillanatnyi értékét. await(E,v: integer); várakoztat,

amíg E eléri v-t. Az utóbbi két operációt részletezzük: advance(E) begin E := E + 1; Kelts fel a várakozó sorból azt a processzt, aminek sorszáma a most igazított E- elérte; end await(E, v: int) begin if E < v then Helyezd a hívó processzt az E-hez tartozó várakozási sorba (és hívd a schedulert); endif end A használatuk (legáltalánosabban) shared var E: eventcounter := 1; S: sequencer := 0; process i begin . await(E, ticket(S)); critical section(); advance(E); . end 6.392 A termelõ-fogyasztó probléma megoldása ezzel a mechanizmussal A pr oblémában f eltesszük, hog y v an e gy b erakó- és e gy ki rakógép, a zaz korlátozzuk, hogy egy idõben csak egy termelõ, illetve egy idõben csak egy fogyasztó használhatja a r aktárt, de egy t ermelõvel p árhozamosan dol gozhat e gy f ogyasztó ( persze, e gy másik cel lában l évõ termékkel.) T ermészetesen t ermelõ cs ak ak kor használhatja a r aktárt, ha v an ü res c ella, fogyasztó

pedig akkor, ha van töltött cella. Figyeljük meg az advance(in) és az advance(out) kettõs szerepeit! Az advance(in) jelzi, hogy töltõdött e gy c ella: t ovábbengedhet e gy f ogyasztót a z õ a wait(in, u+ 1) vá rakozásából, é s továbbengedhet egy másik termelõt az õ await(in, t) várakozásából. Hasonló az advance(out) kettõs szerepe is. És most lássuk az algoritmusokat: shared const N; // a raktár mérete shared var Pticket: sequencer := 0; // termelõ sorszámosztó Cticket: sequencer := 0; // fogyasztó sorszámosztó in: eventconter := 0; out: eventcounter :=0; buffer: array[0.N-1] of items; // a raktár producer i var t: integer; m: item; begin . loop m := produce item(); t := ticket(Pticket); // Egy termelõ egy idõben, await(in,t); // ez biztosítva await(out, t-N+1); // Vár üres cellára put item(m, buffer[t mod N]); // m-et egy cellába tesz advance(in); // raktárfoglatság nõ, // és engedély másik termelõnek endloop . end consumer j var

u: integer; m: item; begin . loop u := ticket(Cticket); // egy fogyasztó egy idõben, await(out,u); // ez biztosítva await(in, u + 1); // vár termékre m := buffer[u mod N]; // kivesz terméket advance(out); // jelzi egy cella kiürülését, // engedélyez más fogyasztót consume item(m); // felhasználja a terméket . endloop . end Nézzék m eg a producer consumer.eventcounter fájlt! E bben C s zintaktikával a dottak az algoritmusok. Mik a különbségek? 6.310 A monitor mechanizmus [Hoare, 1974, Hansen, 1975] A monitor magasabb szintû szinkronizációs mechanizmus: eljárások, változók, adatstruktúrák speciális formájú gyüjteménye. A proceszek hívhatják a monitor eljárásait, de nem f érnek a monitor be lsõ a datstruktúráihoz ( information hi ding), t ovábbá bi ztosított a z i s, hogy e gy idõben c sak egy pr ocessz ha sználhat e gy m onitort. A f ordító bi ztosítja a m onitorba v aló belépésre a kölcsönös kizárást (szokásosan egy bináris

szemaforral), és így a programozónak ezzel m ár n em k ell foglakoznia. H a egy p rocesz h ív e gy m onitorban l évõ el járást, az el sõ néhány instrukció ellenõrzi, vajon más processz pillanatnyilag aktív-e a monitorban. Ha igen, a hívó blokkolódik, míg a másik elhagyja a monitort. A termelõ-fogyasztó problémához például az alábbi monitor-vázlat jó lehet: monitor example var i: integer; c: condition; procedure producer (x); . . end; procedure consumer (x); . . end; end monitor; A m egoldáshoz ke ll a conditon típusú vá ltozó, a min ké t ope ráció ha jtható vé gre: a wait(c: condition), és a signal(c: condition). A wait(c) blokkolja a hívóját, amíg ugyanezen a c-n valaki signal(c) hívással jelzést nem ad ki. Ezek ut án a köv etkezõ ol dalon l áthatjuk a t ermelõ-fogyasztó probléma teljesebb m onitoros megoldását monitor ProducerConsumer const N; var full,empty: condition; count: integer; procedure enter; begin if count = N

then wait(full); enter item; count := count + 1; if count = 1 then signal(empty); end; procedure remove; begin if count = 0 then wait(empty); remove item; count := count - 1; if count = N - 1 then signal(full); end; count := 0; end monitor; procedure producer; begin while true do begin produce item; ProducerConsumer.enter; end; end; procedure consumer; begin while true do begin ProducerConsumer,remove; consume item; end; end; 6.311 További klasszikus problémák 6.3111 Az ebédelõ filozófusok problémája 1965-ben D ijkstra b emutatott é s me goldott e gy s zinkronizációs p roblémát, az az óta klasszikussá vá lt Ebédelõ filozófusok problémáját. E z a hol tpont ki alakulásának é s az ekerülésének klasszikus példája. A probléma a következõ: öt filozófus ül egy aztal körül, mindegyiknek van egy soha ki nem ürülõ tá nyér s pagettije és min degyik t ányér me llett - valójában a t ányérok köz ött - van e gy villa. S pagettit e nni vi szont

c sak ké t vi llával l ehet A f ilozófusok f elváltva e sznek va gy gondolkodnak. Amikor e gy filozófus me géhezik, me gpróbálja megszerezni a tá nyérja melletti b al é s jo bb villát, bármilyen sorrenben, de egymás után. Ha sikerül két villát szereznie, akkor eszik egy darabig, majd leteszi a villákat és folytatja a gondolkodást. A kulcskérdés: tudnánk-e írni olyan programot - minden filozófus számára -, ami megoldja a problémát é s s ohasem o koz hol tpontot, e gik s em ha l é hen, m indegyik tud g ondolkodni i s (mert azt is szeretnek a filozófusok, nemcsak enni! Nézzuk elõször a kézenfekvõnek tûnõ megoldást! (dining.philrossz) Ebben a takefork() vár, amíg a specifikált villa elérhetõ, aztán megragadja azt Sajnos, ez a kézenfekvõ megoldás r ossz. T ételezzük f el, ho gy m ind az öt f ilozófus e gyszerre f elveszi a ba loldali villáját, ezután egyik sem vehet jobboldali villát: bekövetkezik a holtpont helyzet. Ha úgy

módosítunk a programon, hogy miután felvette a filozófus a bal villát, ellenõrzi, vajon elérhetõ-e a jo bb v illa, s h a n em le teszi a b al v illát, mé g min díg n em jó a p rogram! M iért? Mert s zimultán v illafelvétel e setén - ami n em z árható k i - minden f ilozófus f elvesz, m ajd letesz bal villákat. Éhen fognak halni! Az sem jó, ha a jobboldali villafelvételeket késleltetjük pl. vé letlenszerû, va gy a kár egy a lgoritmus s zerinti i dõvel, m ert ne m s zabad i dõzítési feltételekkel megkötötten megoldani a feladatot! Jó megoldást közlünk a dining.philjo programocskában (szerzõ: Tannenbaum) Ebben a mutex szemafor vé di a vi llákkal va ló m anipulációkat: e gyszerre c sak egy filozófus ve het- tehet v illákat! M ásrészt s zámontartjuk a f ilozófusok á llapotát: É HES, E SZIK, GONDOLKODIK á llapotokat. A z a lgoritmus 5 filozófus e setén m egengedi, hog y egyszerre két filozófus egyen! Tetszik? /* Ebedlo

filozofusok problema. ROSSZ MEGOLDAS!!!!!!! File: dinig.philrossz */ #include " prototypes.h " #define N 5 /* number of philosophers / . /* i: which philosopher (0 to N-1) / void philosopher(int i) { while (TRUE) { think(); /* philosopher is thinking / take fork(i); /* take left fork / take fork((i+1) % N); /* take right fork; % is modulo operator */ eat(); /* yum-yum,spaghetti / put fork(i); /* put left fork back on the table / put fork((i+1) % N); /* put right fork back on the table / } } /* Ebedlo filozofusok jo megoldasa. File: diningphiljo */ #define N 5 /* number of philosophers / #define LEFT (i-1)%N /* number of is left neighbor / #define RIGHT (i+1)%N /* number of is right neighbor / #define THINKING 0 /* philosopher is thinking / #define HUNGRY 1 /* philosopher is trying to get forks / #define EATING 2 /* philosopher is eating / typedef int semaphore /* semaphores are a special kind of int % int state[N); /* array to keep track of ones state / semaphore mutex = 1;

/* mutual exclusion for critical regions / semaphore s[N]; /* one semaphore per philosopher / void philosopher(int i) /* i: which philosopher / { while (TRUE) { /* repeat forever / think(); /* philosopher is thinking / take forks(i); /* acquire two forks or block / eat(); /* yum-yum,spaghetti / put forks(i); /* put both forks back on table / } } void take forks(int i) /* i: which philosopher / { down(&mutex); /* enter critical region / state[i] = HUNGRY; /* record fact that philosopher i is hungry / test(i); /* try to acquire 2 forks / up(&mutex); /* exit critical region / down(&s[i]); /* block if forks were not acquired / } void put forks(int i) /* i: which philosopher / { down(&mutex); /* enter critical region / state[i] = THINKING; /* philosophers finished eating/ test(LEFT); /* see if left neighbor can now eat / test(RIGHT); /* see if right neighbor can now eat / up(&mutex); /* exit critical region / } void test(int i) /* i: which philosopher / { if

(state[i] == HUNGRY && state[LEFT] != EATING && state[RIGHT] != EATING) { state[i] = EATING; up(&s[i]); } } 6.3112 Az alvó borbély probléma Borbélyüzlet, egy vagy több borbély és ugyanannyi borbélyszék van benne. Ezen kívül van N szék a várakozó vendégeknek. Ha nincs vendég, a borbély alszik a borbélyszékében. Ha jön egy vendég, felkelt egy borbélyt, az hajat vág. Ha vendég jön, de minden borbélyszék (ezzel borbély) foglalt, akkor • ha va n ür es vá rakozószék, a kkor l eül és vá rakozik. ( Nem f eltétlenül é rkezési s orban szolgálják majd ki.) • Ha a várakozószékek is foglaltak, akkor azonnal elhagyja a borbélyüzletet. Lássuk Tannembaum megoldását! /* Alvo borbely File: sleeping.barb */ #define CHAIRS 5 /* # chairs for waiting customers / typedef int semaphore; /* use your imagination / semaphore customers = 0; /* # of customers waiting for service / semaphore barbers = 0; /* # of barbers waiting for

customers / semaphore mutex = 1; /* for mutual exclusion / int waiting = 0; /* customers are waiting (not being cut) / void Barber(void) { while (TRUE) { down(customers); /* go to sleep if no customers / down(mutex); /* acquire access to waiting / waiting = waiting - 1; /* decrement count of waiting customers / up(barbers); /* one barber is now ready to cut hair / up(mutex); /* release waiting / cut hair(); /* cut hair (outside critical region) / } } void Customer(void) { down(mutex); /* enter critical region / if (waiting < CHAIRS) { /* if there are no free chairs,leave / waiting = waiting + 1; /* increment count of waiting customers / up(customers); /* wake up barber if necessary / up(mutex); /* release access to waiting / down(barbers); /* go to sleep if # of free barbers is 0/ get haircut(); /* be seated and be serviced / ; } else up(mutex); /* shop is full; do not wait / } 6.4 A Unix szemafor mechanizmusa A U nix s zemafor m echanizmusa bl okkoló j ellegû, s zámlálós

i mplementáció. D e t ovábbi jellegzetességek i s v annak a U nix szemafor i mplementációban. F oglaljuk ez eket ö ssze röviden, még akkor is, ha most ezeket nem valószínû, hogy értjük: • Szemafor készlet lehet egyetlen Unix szemaforban. • Operáció készlet hajtható végre egyetelen szemafor operációban (de azért az operáció atomi). • A elemi operációk lehetnek blokkolók, de lehet nem blokkolók is. • Az elemi oerációk nencsak 1 értékkel csökkenthetnek, növelhetnek (non-unitary-k). • Lehetséges 0 ellenõrzés is. • Blokkolódás esetén t ermészetes, h ogy a s zemafor el emei az o peráció el õtti ér téküket visszaveszik (automatikus undo az elemi operációkra). • Eredeti s zemafor-elem ér ték v isszaállítás ( undo) s pecifikálható a p rocessz terminálódásához is. Foglaljuk össze röviden a Unix szemaforokkal kapcsolatos rendszerhívásokat is: • semget() r endszerhívással l ehet s zemafort ( benne el

emi s zemaforok k észletét) készíteni, vagy meglévõ szemaforra asszociálni. • semop() rendszrhívás a szemafor operáció. Ezzel operáció készlet hajtható végre akár vegyesen down és up, vagy 0 ellenõrzés, akár vegyesen a szemafor készlet elemein. • semctl() r endszerhívás s zolgál a s zemafor k ontrollálására: i nicializálásra, megszüntetésre, pillanatnyi értékek, belsõ adatok lekérdezésére. • Bizonyos hasonlóságokat fedezhetünk fel az üzenetsor (message queue) és az osztott memóriahasználat (shared memory) redndszerhívásaival. Mielõtt megpróbáljuk részletezni a Unix szemaforhasználatot, tanácsoljuk a nyájas olvasónak, hogy tanulmányozza a példaprogramokat, a man lapjait, ezekbõl sokat tanulhat. 6.41 A Unix szemafor elemi szemaforok készlete Egy egyedi ( single) s zemafor egy poz itív e gész l ehetne ( 0 é s 32767 t artományban). A korszerû Unix-ok nem egyedi szemaforokat kezelnek, hanem szemafor

készleteket (semaphor set). E gy szemafor k észlet k ötött s zámú e lemi s zemafort ta rtalmaz P éldáinkban a z n sem változóval adtuk meg a készletekben az elemi szemaforok számát. Semaphor s et k észíthetõ ( kreálható) a s emget() r endszerhívással. U gyancsak a s emget() rendszerhívás alkalmas l étezõ szemafor készlet azonosítására, hacsak explicite nem tudjuk a szemafor készlet azonosítóját (példáinkban sid, semid, vagy empty az azonosító). Az a p rocessz, amelyik semget() hívással készített szemafort, az lesz a s zemafor tulajdonosa. Õ határozza meg a key kulcsot, ami a szemafor külsõ azonosítására szolgál, õ határozza meg a készletben a szemaforok számát, (az nsem értékkel), és õ állít be használati engedélyeket (rw) a s zemafor k észletre (a f lags-szel). M ás p rocesszek a s emget() h ívással as szociálhatnak a szemaforra. Ismerniük ke ll a ke y kul csot, a z ns ems é rtéket, é s a f lags-szel v

izsgáltathatják, vajon létezett-e már a szemafor. A semget() hívás szintaxisa: sid=semget(key,nsems,flags); A s emget n sems s zámú e lemi s zemaforból á lló s zemafort k reál k ey k ulccsal, b eállítva a hozzáféréseket is, vagy asszociál a k ey kulcsú szemaforra. Visszaadott értéke a s id ezek után a pr ocesszben ha sználható be lsõ s zemaforazonosító, va gy pe dig a kreáció/asszociáció sikertelenségét jelzõ érték. Az elemi szemaforok rendre 0, 1, ., nsems-1 index-szel azonosítottak A sid szemafor, és egy elemi szemafor adatstruktúráját is láthatjuk az alábbi ábrán.: 6.18 ábra 6.42 A Unix szemafor operációja elemi operációk készlete elemi szemaforok készletén Az e ngedélyekkel r endelkezõ pr ocesszek ope rációkat ha jthatnak vé gre a s zemaforokon (semop()). A rendszerhívás szintaxisa: semop(sid,ops,nops); A s emop a s id s zemaforon ns ops s zámú op erációt ha jt vé gre ( atomo m ódon). A z ops -ban definiáltak

az operációk, az is, hogy melyik elemi szemaforon hajtódjanak végre, és még az ops-ban flag-ek is befolyásolhatják az operációkat. Egy elemi operáció és az operációkészlet adatstruktúráját látjuk a következõ (6.19) ábrán Az elemi operációk indexe is 0 és nops-1 között lehet. A struct sembuf elsõ tagja a num: ez fogja indexelni, hogy melyik elem szemaforon kell az elemi operációt végrehajtani. Második tagj az op: ez maga az operáció. Harmadik tagja a flag, ami az elemi operációt módosíthatja A flag beállítható pl. IPC NOWAIT makróval: ez azt jelenti, hogy ha blokkolódnia kellene az elemi operáción a s emop-nak, a kkor s e bl okkolódjon ( ilyenkor p ersze, a z e lemi ope ráció ne m hajtható vé gre, de e rrõl a s emop visszatérési é rtékével m eggyõzõdhetünk, ke zelhetjük a z esetet.) A flag beállítható SEM UNDO makróval: terminálódáskor álljon vissza minden ilyen operáció eredménye). Nézzünk ezután egy

példát! A 3 elemi szemaforból álló készleten 4 elemi mûveletet hajtunk végre. A 620á brán b alra l áthatók a s id s zemafor e lemi s zemaforainak ki ndulási é rtékei, középen az ops, jobbra a sid végeredménye. 6.20ábra Alapvetõen háromféle elemi operáció lehetséges: • inkrementálás (up), (V), ha az op > 0, • dekrementálás (down), (P), ha az op < 0, • 0 ellenõrzés, ha az op = 0. Az up operáció során a megfelelõ elemi szemafor értéke az op értékével növekszik. Ha az op < 0, akkor szükség esetén blokklódik a hívó, amíg a megfelelõ semval >= |op| lesz, és a semval értékéhez hozzáadódik az op (azaz levonódik az abszolút értéke). Ha az op = 0, blokkolódik a hívó, míg a kijelölt semval 0 nem lesz. Látjuk, az up operációban poz itív a rgumentummal, a down operációban n egatív argumentummal hívjuk a semop() system call-t. Ezek az operációk atomiak A down operáció n emcsak e gyszerû d

ekrementáció, h anem egyben tesztelés, v ajon a szemafor-elem p illanatnyi ér téke n agyobb-e a d ekremnetációs ér téknél. ( Az i s t esztelhetõ, hogy egy szemafor érték éppen 0-e, vagy sem!) Ez a tesztelés sikeres, vagy nem. A down operáció l ehet un. " blocking" va gy "non bl ocking" j ellegû, az IPC NOWAITflag beállítástól f üggõen. H a ne m s ikerül a de krementáció i lyen e setben, a bortál a s emop, de továbbfuthat a hívó. Non-blocking jellegû down esetén ( IPC NOWAIT b eállítva) s ikeres te szt u tán n ormális a dekrementáció és n ormális a v isszatérés a s emop()-ból, s ikertelen t eszt u tán a s emop() visszatérési ér téke v iszont -1 é s ne m de krementál. A non -blocking down ha szna a kkor jelentkezhet, h a s zemaforral v édett er õforráshasználat s orán ah elyett, h ogy v árakoznánk a foglalt erõforrásra, valamilyen més hasznos feladatot akarunk megoldani. Maga a tény, hogy az e

rõforrás ne m á ll r endelkezésre, ki derül, a pr ocessz a zonban f uthat t ovább m ás ve zérlési szálon, mint az erõforráshasználat kritikus szakasza. Blocking jellegû down esetén s ikeres t eszt u tán n ormális d ekrementáció és v issztérés következik, s ikertelenség e setén vi szont a hí vó processz bl okkolódik a szemaforon, a míg a szemafor ér ték m eg n em en gedi az o perációt, v agyis amíg egy m ásik p rocessz n em inkrementálja a szemafort oly mértékben, hogy a dekrementáció megtörténhessen. A processz tehát a kkor ke rül l e a s zemafor vá rakozó s oráról, ha m ás pr ocesszek i nkrementlják a szemafort, vagy megszüntetik azt. Egyetlen s emop() h ívásban a s zemafor k észlet el emeire b lokkolt/nem-blokkolt ope rációk nsops s zámú a kciója ( operáció ké szlet) h ajtódhat v égre. A z o perációk k észlete ak ármelyik szemafor-elemre v agy a kár az ö sszes el emre k érhetõ! M indazonáltal n em h ajtódik v

égre operáció, amíg a z ös szes vé gre n em t ud ha jtódni! E z a zt j elenti, hog y bl okkolt s zemafor operációknál ha az ös szes op eráció-elem n em h ajtódhat v égre s ikeresen ( vagyis h a p rocessz blokkolódik), a z ös szes m egelõzõ e lemi ope ráció e redménye vi sszaáll, hog y ne l egyen változás, amíg minden végre nem hajtódhat! Pl: ha 10 s zemaforos ké szleten 6 ope rációt h ajtanánk vé gre e gyetlen s emop() hí vással (mondjuk m ind a ha tot m inden s zemafor-elemre), és a 6 o peráció-elembõl 3 s ikerül, de a negyedik ne m, t ovábbá e z é ppen blokkoló, a kkor a a hí vó pr ocessz blokkolódik, de a megelõzõ 3 ope ráció e redményei vi sszaállítódnak, a míg a m aradék ope rációk i s sikerülhetnek. Ez egy automatikus undo akció Tovább is bonyolíthatjuk! Bármely operáció, ami megelõzi vagy követi a blokkoló operációt, beleértve m agát a bl okkoló ope rációt i s, s pecifikálható S EM UNDO flag-gel. E z

a flag azt kéri, hogy ha a hívó processz terminálódik, a sikeres semop()-ok erdeményei álljanak vissza. (Az o k n yilvánvaló: h a s zemafor s egítségével lefoglalunk v almilyen erõforrást é s mie lõtt felszabadítjuk a p rocessz terminálódik, ne maradjon foglalt az erõforrás! Általában kivételes különleges események miatti terminálódásra igen hasznos lehetõség ez.) A Un ix-ok bi ztosítják a szemaforokhoz a z un. undo (csináld v issza) me chanizmust Létezik egy undo struktúra, m elyekben f eljegyzõdnek a blocking operációk, ha a S EM UNDO beállított (és nincs IPC NOWAIT). 6.43 A semctl rendszerhívás A s zemafort a zonosító processzek - az e ngedélyektõl i s f üggõen - semctl() r endszerhívással átállíthatják az en gedélyeket, b eállíthatják és l ekérdezhetik a s zemafor p illanatnyi ér tékeit, megkérdezhetik, melyik processz operált utoljára a szemaforon, mely processzek várakoznak a szemafor várakozó sorában

stb. A szintaxis: semctl(sid, snum,cmd,arg); Ez a hí vás a s id s zemafor s num i ndexû e lemi s zemaforán cmd pa rancsot ha jt vé gre. H a a parancsnak operandusa van, akkor az az arg. A lehetséges parancsokból néhány: IPC RMID makró adja a sid szemafor megszüntetését. A SETVAL makró kifejtve a beállításhoz jó, kell neki a z a rn. P l e zzel i nicializálhatunk e lemi s zemafort A G ETVAL pe dig éppen l ekérdez pillanatnyi értékeket. A s emctl h asználatát a p éldaprogramokból, a m anual l apból elsajátíthatjuk. A példaprogramocskák: • semset.c Kreál/azonosít szemafor készletet, benne egyetlen szemafort Figyeljük az azonosítás technikáját! Bekéri stdin-rõl a kezdõ értéket, és ezt beállítja. (Megjegyzem, a t öbbi pr ogramocska ug yanezen s zemafor ké szletet a zonosítja, ha sonló s emget() hívásokkal.) • semval.c Lekérdi és kiírja a pillanatnyi szemafor értéket • semkill.c Megszünteti a példácskák szemafor

készletét • semup.c Ez i s f uttatható p rogram, a s embufsem op= 1 ér tékkel i nkrementálja a szemafort. • semdown.c Ez is futtatható, a sembufsem op=-2, tehát 2-vel dekrementál Próbáljuk ki S EM UNDO-val i s, é s a nélkül i s! P rocesszként f elfüggesztõdik, ha a s zemafor pillanatnyi értéke nem engedi a dekrementációt, de SEM UNDO beállítással - miután sikeresen t ovábbjutott, a kár vá rakozás ut án, a kár a nélkül - exitnél " visszacsinálja" a dekrementációt. Ha valóban dekrementálni akarunk, vegyük ki a SEM UNDO-t • downup.c Három f üggvény, hoz zá ke ll l inkelni a p roducer és a c onsumer programokhoz! Figyelem! A down-ját írjuk át SEM UNDO beállítás nélkülire is, így is próbáljuk ki! • downup uj.c Öt függvény, más technikával, mint a downupc • consumer.c Futtatható S zemafor a zonosító a z e mpty v áltozó ( bár a s zemafor maga u gyanaz, m int a z e lõzõ pr ogramocskákban). V

égrehajt e gy up -ot, és k iirja a pillanatnyi értéket. Tulajdonképpen a producer párjának szántam • producer.c Main program ez is, hívja a down és a val függvényeket N-szer akar down-olni, é s pe rsze, bl okkolódik, ha ne m e lég na gy az " üres r ekeszek" s záma: a z empty szemafor! Továbbfut, ha egy consumer "kivesz" egy terméket: növeli 1-gyel az empty szemafor értéket. Javasolt játékok a fenti programocskákkal és az ipcs, ill. ps parancsokkal: 1. semset-tel készíts szemafort Adj neki pl 5 értéket ipcs-szel nézd meg, semval-lal kérdezd le. semup-pal növe ld a z é rtéket, semval-lal m égegyszer gyõzõdj m eg a növe lt é rtékrõl. semdown-nal c sökkentsd a z é rtékét. S ikerült? H ogy va n semdown-ban a S EM UNDO beállítva? ps-sel nézheted, felfüggesztõdött-e a semdown. Próbálj ki e zekkel t ovábbi f orgatókönyveket! A vé gén semkill-lel megszüntetheted a szemafort! 2. Compiláld, linkeld össze a

producer-t és a consumer-t, az downupc két változatával is! (Egyikben a down-ra SEM UNDO legyen!) Utána semset-tel ké szíts s zemafort, m ondjuk 4 kezdõ é rtékkel. ( Ne felejtsd, a producerconsumer ugyanazt a szemafort h asználja, m int az el õzõ p rogramocskák h asználtak!) Háttérben indíts el a producer-t. Mit csinál ez? ps-sel nezd, blokkolt-e semval-lal nézheted a pillanatnyi értéket! Most in dítd a consumer-t! M i le sz ekkor a producer-rel? p s-sel i s n ézd! semval is kipróbálható! Mi l enne, ha semset-tel e gy na gyobb, pl . 8 é rtéket a dunk a s zemafornak? B lokkolódik a producer? Mi a szemafor érték, ha downup.c-ben SEM UNDO beállított? Próbálj további játékokat! Végén a semkill-lel itt is törölhetsz. 7. Memóriamenedzselés A m emória i gen f ontos e rõforrás. B ár a gé pek e gyre na gyobb köz ponti m emóriával rendelkeznek, a m emóriával m indenképp ga zdálkodni ke ll. m ert a z a lkalmazások i s e gyre

nagyobb memóriát igényelnek. Érvényes itt Parkinson törvénye: "Programs expand to fill the memory aviable to hold them." A m emória c ímekkel r endelkezõ bá jtok, s zavak ké szlete. A gépi i nstrukciók a m emóriából vevõdnek a programszámláló regiszter (PC) pillanatnyi értéke szerint, másrészt az instrukciók címrésze hivatkozhat a memóriára (az instrukció operandusa a memóriában van). Lássuk be: az instrukciókban a memória cellák címei szerepelnek, és az instrukció "nem tudja", hogyan generálódik az a cí m am i v égül i s a b uszra k erül, h ogy a m emória c ella t artalma a C PU-ba jusson (vagy fordítva). A címkötõdés (Address Binding) Programjaink t öbb l épcsõn m ennek á t f ejlesztésük s orám, e bbõl köve tkezõen t öbb címkötõdési e set l ehetséges. A l épcsõk: a f ordítás ( compilation), a t aszképítés ( link), a betöltés (load) és a végrehajtás (run), bármelyikben történhet a

címkötõdés. • Kötõdés a fordítás során: a bszolút c ím generálódik m ár a t árgymodulokban. H a i tt nincs kötõdés, akkor a tárgymodulokban relatív címek generálódnak. • Kötõdés a taszképítés során: a bszolút c ímek ge nerálódnak a végrehajtható modulokban ( executable f iles), kül önben azokban r elatív c ímek v annak. H a r elatív címek va nnak, a kkor a program á thelyezhetõ ( rellokálható). E gy fajta r elatív c ím a virtuális cím (lásd késõbb). • Kötõdés a betöltés során: a vé grehajtható p rogramfájlban r elokálható c ímek a betöltés s orán " átíródnak", é s a bszolút c ímekké vá lnak. H a ni ncs köt õdés a be töltés során, a kkor a pr ocessz kóds zegmensének címei m ég m indíg r elatív c ímek ( pl. virtuális címek). • Kötõdés a futás során, dinamikus a kötõdés. A processz kódjában az instrukciók ún logikai címeket tartalmaznak. A lo gikai cím le het

r elatív c ím, v irtuális cím A C PU tehát logikai címet kap feldolgozásra, ezeket átképzi fizikai címekké és ez adható ki a buszra. Az i nstrukciókban s zereplõ c ímek ké szlete a l ogikai c ímtartomány. M eg k ell je gyeznünk, hogy ez nem feltétlenül folytonos, még ha egy dimenziós is! A fizikai tárnak is van valós címtartománya. Ez sem folytonos feltétlenül, olyan értelemben, hogy lehetnek olyan címek, amik mögött nincs memória-cella! Ráadásul itt még átfedések is lehetnek: ugyanazon címhez több memória rekesz is tartozhat (tipikus példa az IBM PC, lásd késõbb), ilyenkor persze meghatározott, hogy melyik cellát szólítja meg a buszra kiadott cím. Az ope rációs rendszerek m agjának fontos r észe a memória menedzselõ al rendszer, am elyik szorosan együttmûködik a hardverrel: az MMU-val (Memory Management Unit). Különbözõ m emóriamenedzselõ s émák l ehetségesek, e zek e gyütt f ejlõdtek a ha rdver é s szoftver

fejlõdéssel. 7.1 A memóriamendzsment osztályai Több szempont szerint is osztályozhatunk. Egyik osztályozás szerint vannak olyam memórai menedzselõ rendszerek, melyek • mozgatják a p rocesszek k ontextusát ( vagy an nak eg y r észét) a f õ m emória és a másodlagos memória (háttértérak: diszkek, régebben dobok) között: • ki-belapozó rendszerek; • ki-besöprõ rendszerek; nem mozgatják a kontextusokat. További osztályozás szerint lehetnek: 1. valós címzésû rendszerek, ezen belül 1. monoprogramozású, 2. multiprogramozású rendszerek, ezen belül 1. fix partíciós, 2. változó partíciós rendszerek; 2. virtuális címzésû rendszerek, ezen belül 1. lapozós (paging) rendszerek, 2. szegmens-leképzõ, ki-besöprõ rendszerek, 3. szegmentáló, ki-besöprõ és ugyanakkor lapozó rendszerek Nézzünk ezekre tipikus példákat, közben magyarázva a lényeget is. 7.11 Valós címzésû monoprogramozás A l egegyszerûbb s éma ez, m ely s

zerint e gy i dõben e gy pr ocessz ( vagy taszk, j ob) va n a memóriában és az el foglalhatja az o perációs r endszer m ellett a t eljes m emóriát. A p rogram fejlesztése s orán a f ordító-taszképítõ ( compiler-linker) v alós cí meket generál, a cí m és memóriakötõdés történhet bármelyik fázisban. 7.1 ábra Valós címzésû monoprogramozás Tipikus pé lda e rre a r endszerre a ná lunk na gyon e lterjedt P C a z M S D OS ope rációs rendszerrel. Miután nagyon elterjedt, errõl késõbb részletesen is beszélünk, ott említve, hogy az MS-DOS-ban ugyan létezhet több processz egyidõben a memóriában, de mindíg csak egy aktív belõlük. Megemlítjük azt is, hogy a COM fájloknál a kötõdés a beltöltés során, az EXE fájloknál futás során történik. 7.12 Valós címzésû multiprogramozás A fo rdító-taszképítõ itt is v alós c ímeket á llít e lõ, a f uttatható p rogramokba v alós c ímek vannak t ehát. A t aszképítést

és a m emóriamenedzselést i s b efolyásolja a k ét l ehetséges alosztály: fix, vagy változó partíciós lehet ez a r endszer. Tipikus példa volt erre a r endszerre az IBM S ystem 3 60-as r endszere. E z köz ös i nput s orokkal dol gozott, de könn yen elképzelhetjük a szeparált bemeneti sorokkal dolgozó rendszereket is. Multiprogramozás fix méretû partíciókban, szeparált input sorokkal A me móriának az o perációs r endszer ál tal el n em f oglalt r észét fix m éretû részekre, osztották. M partíciókra indegyik partíciónak s aját i nput s ora vol t, a programokat ( job-okat) az eg yes partíciókba k ellett f ordítani-linkelni. A programozó t ehát t udta, ho gy m ilyen címen ke zdõdik é s m eddig t art e gy-egy partíció, a c ompiler-linker cs akis a partícióba tartozó címeket generál. Cím és memória kötõdés a link során történik. A memória kezelés sémája a 72 ábrán látható Valós címzés fix

partíciókkal, közös input sorral 7.2 ábra Valós címzés, fix partíciók A s zeparált i nput s orokat ha sználó r endszer há tránya vol t, hogy m aradhattak ür es pa rtíciók, noha vol tak j obok, c sak é ppen ne m a z ür es partícióba f ordították, l inkelték a zokat. E zt kiszübölendõ, a f ejlõdés köve tkezõ l épcsõje a 7. 3 á brán l átható s éma v olt: a pa rtíciók f ix méretûek, d e e gyetlen k özös i nput s orral. B ármelyik pa rtíció ki ürülve a zonnal f ogadhatta a következõ jobot, ami még belefért. Megoldandó pr obléma vol t e nnél a r endszernél a z áthelyezés (relocation): miu tán a programozó ne m t udhatta, pr ogramja m elyik pa rtícióba f og ke rülni, ne m l inkelhette programját a partíciókhoz tartozõ címhatárok közé. A megoldás a következõ volt: a fordítótaszképítõ eltolás címeket (offset) generált, melyek a program 0 kezdõ címétõl számítódtak A végleges címet elõállíthatták

ezek után két módon is: egyik szerint a program betöltése (load) során minden címet átírtak az eltolás értékhez hozzáadva a p artíció kezdõcímét, így elõálltak a betöltött programban a partícióhoz tartozó címek. Másik megoldás szerint - mikor is minden címzés eg y s zegmensregiszter és egy el tolás értékbõl adódik -, a b etöltés s orán n em változtatták meg a címeket, hanem a p artíció k ezdõcímét betöltötték a s zegmensregiszterbe. Futás során így is a partícióhoz tartozõ címek keletkezhettek. 7.3 ábra Fix partíciók közös input sorral A másik megoldandó probléma a védelem volt: hogyan ellenõrizzék, hogy egy-egy program ki ne címezzen a p artíciójából. Nos, a load során a címeket átíró módszer esetén az átírással egyidõben lehetett ellenõrizni minden címzést. A szegmensregiszteres címzéses megoldáshoz más ellenõrzés kellett. Kétféle ellenõrzési módszer is bevált Egyik szerint a

partícióhatárok címeit r egiszterekben ta rtva min den c ímzés e llenõrzõdött, v ajon e k ét h atár k özé e sik-e. Vegyük észre, hogy ez dinamikus jellegû, a gépi instrukciók végrehajtása közben történik az ellenõrzés. Másik megoldás szerint - ilyen volt a híres 360-as rendszer - a memória minden 2 blokkja kapott 4 bites védelmi kódot, ugyanakkor a PSW-neb is volt 4 bites védelmi kód. Ha a címzés során e két kód nem egyezett, bekövetkezett a címzés védelem megsértése kivételes esemény, egy trap. Multiprogramozás változó méretû partíciókkal Erre is van tipikus példa: a CDC Cyber rendszere. A lé nyeg itt is a z, h ogy a f ordító-taszképító v alós, e ltolás c ímeket g enerál ( kötõdés itt mé g nincs), a rendszer memóriáját azonban nem osztjuk fel elõre partíciókra. Az input sorba került munkák a s zabad t erületrõl, v agy a m ár k orábban k ialakult, a rendszer él ete s orán dinamikusan vá lltozó m

éretû p artíciókból i gényelnek m emória pa rtíciókat. V annak t ehát "szabad" pa rtíciók, és v annak f oglaltak. A 74 ábrán a zt m utatjuk be , hogy A , B, C s tb különbözõ m éretû m unkák i lyen s orrendben " belépve", a z á brán l áthatóan be fejezõdve hogyan partícionálják a memóriát (kötõdés a betöltés vagy a futás során történhet). A m egoldandó f eladatok en nél a r endszernél a relocation és a védelem feladatain ( amit az elõzõekhez hasonlóan kellett végezni) kívül: • A munkák helyigényét elõre meg kell mondani, hogy ellenõrizhetõ legyen, befér-e egy -egy nem használt "partícióba." • Valamilyen stratégia kell az elhelyezésre, ha több üres helyre is befér a munka. • Idõvel s zegmentálódik a m emória. S zükség va n a z ür es s zomszédos s zegmensek összevonására, i dõnként pe dig a z ös szes ür es t erület e gyetlen t erületre va ló összevonására: a

Memory Compaction-ra. Az elhelyezés stratégiák a következõk lehetnek: • First Fit (Next Fit) stratégia. • Best Fit stratégia. • Worts Fit startégia. A s tartégiák min õsítése f ügg attól, h ogy mil yen mó dszerekkel ta rtják nyilván a m emória foglatságot. Elvileg ez lehet bit térképes, vagy láncolt listás Az utóbbi volt az elterjedt A best fit stratégia l ényege a z, ho gy a s oron következõ m unka a bba a s zabad m emória partícióba ke rül, amibe a l egkisebb v eszteséggel befér. Az elgondolás m ögötte az, hog y í gy lesz a legkisebb a veszteség. Érdekes tapasztalat volt azonban, hogy az elgondolás nem ad jó eredményeket. K ikesresni a s zabad t erületek l áncolt l istáján a l egjobban p asszoló t erületet idõigényes, u gyanakkor a m emória s zegmentálódik, ke letkeznek be nne ki sméretû s zabad partíciók, a mikbe k ésõbb ne m i s l ehet s emmit t ölteni, c sakis m emóra ös szevonás ut án

használhatók: éppen az ellenkezõjét érjük el, mint amit akartunk, lesz veszteség. A worst fit startégia szerint szintén végig kell keresni az összes szabad területet, és abba kell betölteni a m unkát, amiben a "legtágasabban" fér el. Idõigényes ugyan a keresés, de kevésbé szegmentálódik a memória, nem lesznek nagyon kicsi üres szegmensek. Egész j ó er edményeket s zolgáltat a first fit, és még j obb a next fit stratégia: az el sõ ( vagy a következõ) szabad területre töltsük a munkát, amibe belefér. Elmarad az idõigényes keresés és tapasztalatok szerint nem szegmentálódik túlságosan a memória. Ennél a m emóriamenedzselési s émánál m ár f elmerült a k i-besöprés m egvalósítása! Ezzel alkalmassá vált a rendszer az idõosztásra (time sharing). Azok a munkák, amik blokkolódtak (vagy a z op erátor bl okkolta õke t), ki söprõdhettek m ásodlagos t árolóterületre: na gyon gyors dobtárakra, e setleg di

szkekre. P ersze, e kkor a zonnal f elmerült a ké rdés, m ekkora l egyen a kisöprési t erület, m inden j ob s zámára kül ön s zervezzék, va gy egy kö zös, de e lég n agy területet biztosítsanak erre. Különbözõ megoldások voltak erre a különbözõ rendszerekben 7.2 A virtuális címzés koncepció A konc epció ki alakításának ki váltó oka a z vol t, hog y e gyre n agyobb p rogramokat í rtak a programozók, nagyobbakat, mint a rendelkezésre álló fizikai memória. Eleinte a megoldás az overlay technika vol t. Átfedésekkel a v alós cí mzésû r endszerekben i s l ehetett n agy programokat futtani. Az overlay lényege A pr ogramokat r endszerint s zubrutinokból ( eljárásokból, f üggvényekbõl) á llítjuk ös sze, é s valószínû, hogy egy-egy adott idõben nem hívunk meg minden lehetséges rutint. Azaz, elõre összeállíthatjuk a rutinok hívási fáját: ezen ágak az egy idõben egymást hívó rutinok. Nézzül pl. a 75 ábrát! 7.5

ábra Az overlay magyarázata A hí vási fa s zerint egy i dõben - legrosszabb esetben - meg l ehet h ívva a main-c-a-a1 rutinsorozat, de sohasem lesz egyidõben meghívva a b rutin az a rutinnal, vagy a c-vel. Ugyanígy látható a z i s, hog y az a1 rutin s ohasem l esz egyidõben m eghívva az a2 rutinnal, e zek ugyanarra a kezdõcímre is betölthetõk, ha dinamikusan tudjuk õket hívásuk elõtt betölteni. Az ábrán a ( b) ábrarészen bemutatjuk, hog y m ennyi l enne a he lyfoglalás, ha m inden r utin egyidõben be lenne töltve a memóriába. A (c) jelû ábrarészen viszont azt mutatjuk, hogy az egész p rogramnak az él ete s orán en nél k isebb m emóriaterület i s el ég l enne, h iszen s ohasem hívódhat m eg egyszerre m inden r utin. A z o verlay t echika alkalmazása során u gy linkelték össze a pr ogramokat, hogy s zükség e setén a r utionok be töltõdhettek, f elülírva a ne m szükséges rutinok m emória t erületét. R áadásul, a l inkerek k

épesek voltak a b etültést "atomatizálni", azaz, a ha a lin kernek m egmondta a pr ogramozó a hí vási fát, a kkor a l inker beírta a programba a "load"-olási utasításokat. Ma, a virtuális címzések kialakulásával nincs szükség az overlay-ezésre. A virtuális memória lényege A koncepció szerint minden processznek igen nagy címtartománya van, a processzhez tartozó memória v agy a k özponti me móriára, v agy valamilyen má sodlagos me móriára, tá rterületre van l eképezve. A l eképzés t ranszparens, o lyan ér telemben, h ogy a p rocessznek n em k ell törõdnie a m emóriával, a m ásodlagos m emóriára l eképzett r észe f utás s orán, s zükség es etén bekerül a központi memóriába. Van tehát adatmozgatás a központi memória és a h áttártárak között, de ezt a processzek számára a memóriamenedzser biztosítja. A virtuális címzés koncepció szerint mûködõ rendszerekben a fordító-linker virtuális

címeket generál. Az elõállítható címek tartománya a virtuális címtartomány: V Az egyes gépeken a fizikai memória mérete kötött. A fizikai címtartomány az R Igaz az, hogy V >> R (V jóval nagyobb, mint R). A f utó pr ocesszek s zövegében s zintén a vi rtuális c ímek s zerepelnek. A mikor a C PU e gy instrukciót végrehajt, annak címrészében virtuális címet kap. Az instrukció végrehajtása során a V -beli virtuális címet le kell k épeznie R -beli fizikai címre, és a leképzett cím adható ki a buszra. E z a c ímleképzés di namikus! M inden egyes gé pi i nstrukció f eldolgozása köz ben történik. F ontos, hog y gyors l egyen e zért a l eképzés vé grehajtásában a memóriamenedzselõ kernel szoftvert segíti a hardver: az MMU. Vaddress Dynamic Map Raddress Lássuk b e, n em el ég a leképzés. M ivel a V >> R m ég e gy p rocesszre i s, r áadásul t öbb processzt i s ke zelhet a rendszer, e lõfordulhat, ho gy a l eképzett

R -beli címen ép pen n em az adott processz kontextusához tartozó információk vannak. Ugy szokták mondani, a leképzett cím nem érvényes (not valid). A V -beli címhez tartozó információ ez es etben a m ásodlagos tárolón va n. Gondoskodni ke ll t ehát arról, ho gy a m ásodlagos t árolóról a z i nformáció bekerüljön a f õ m emóriába. H ogy b eférjen, esetleg onna n valamit ki i s k ell í rni T ehát va n adatmozgatás is a dinamikus leképzésen kívül, a szükségnek megfelelõen. Két d olog s zerencsére segít. A z egyik: a p rogramok l okalitása (Emlékezzünk a t avaly tanultakra!) Nem szükséges, hogy a teljes címtartományhoz tarozó kontextus egy idõben benn legyen, a kkor i s t ud f utni a pr ocessz. A m ásik: bár a lehetséges címtartomány igen nagy, valójában a pr ocesszek virtuális c ímtartománya e nnél ki sebb s zokott l enni. N em könn yû olyan programot írni, aminek a kódrésze pl. óriási, sok-sok programsort kell ahhoz

leírni Az adatrészek i s a kkor l esznek na gyok, ha pl . ór iási m áretû t áblázatokkal dol gozunk, kül önben nagyon sok egyedi változót kellene deklarálnunk. Valójában tehát három dologról beszélünk: • egyik a lehetséges virtuális címtartomány. Ez valóban nagy l ehet, hiszen pl 32 bi tes címzésnél ez 4 Gbyte. • A másik a processz tényleges virtuális címtartománya. Bár ez is nagy, biztos kisebb az elõzõnél. A na gysága a m ásodlagos m emória ( a pa ge t erület, va gy a s wap t erület) becsléséhez s zükséges, l ássuk be , hog y v alahol mégiscsak ke ll t árolni a pr ocesszek kontextusát! A processz tényleges virtuális címtartománya n em feltétlenól folytonos. Másrészt a pr ocesszek é letük s orán növe lhetik, va gy csökkenthetik vi rtuális címtartományukat is. • A h armadik a fizikai c ímtartomány. E z s ajnos, kicsi s zokott le nni, mé g h a ma e gy munkaállomás köz ponti m emóriája s zokás s

zerint l egalább 32K byte, va gy t öbb. Szuperszámítógépek kö zponti m emóriája l ehet 1 -2 G byte i s! E bbõl va lamennyi permanens, azaz nem lapozható/söpörhetõ ki: pl. a kernel részei, amik mondjuk éppen a m emóriamenedzseléshez k ellenek. M indenképp k icsi ez a m emória, hiszen ez en osztozik a kernel permanens részén kívül minden processz. Attól függõen, hogy a dinamikus címleképzésben a leképzett memóriablokk mérete fix, vagy változó, beszélhetünk lapozós (paging), vagy szegmentálós rendszerekrõl. 7.3 A lapozó rendszerek (Paging Systems) A lapozós rendszerekben a virtuális címtartomány "egydimenziós". A V egyforma méretû lapokra (page) van felosztva. Egy virtuális cím v = (p,o) formájú, ahol p a lap címe, o (offset) eltolás a lapon belül. Az R ugyanolyan méretû lapkeretekre (page frame) van felosztva. A valós cím r = (p,o) formájú, ahol p a lapkeret címe. 7.31 A laptáblák (Page Map Table) Minden

processz számára biztosítandó egy laptábla. Ennek kezdõ címét a processz dinamikus kontextusában e gy r egiszter t artalmazza ( Base A ddress o f P age T able R egister). A l aptábla egy -egy b ejegyzést t artalmaz eg y-egy l aphoz: t ehát ol yan hos szú, hog y a pr ocessz m inden lapjához lesz egy bejegyzése. A hossza tehát a processz tényleges vituális címtartományából és a lapok méretébõl kiszámítható. A laptábla egy bejegyzése rögzít • egy j elzést, h ogy v an-e a l aphoz l apkeret r ögzítve, a l ap be nn va n-e a f izikai memóriában, érvényes-e (valid/present-absent bit). • Védelmi m aszkot, az az a l ap í rható, v agy cs ak o lvasható. A b ejegyzés a v édelem mellett a k ilapzásnál is h asználható: n em ír t l apokat u gyanis n em k ell f eltétlenül kilapozni, egyszerûen elereszthetõ, hiszen nincs rajta változás. • Módosítás j elzõt. Az í rható l apoknál l ehet j elentõsége: ha n em m ódosították,

s zintén nem kell kilapozni, csak elereszteni. • Végül a lapkeret címét. Az érvényes lapoknál ebbõl a mezõbõl vehetjük a címet Ezek után a dinamikus címleképzést lapozás esetén a 7.6 ábra mutatja be 7.6ábra Címleképzés lapozós rendszerben 7.32 A laphiba (Page Fault) Ha a d inamikus címleképzés során a l aptábla p-edik bejegyzésében a valid/present-absent bit azt j elzi, hogy a ké rdéses l aphoz ni ncs l apkeret hozzárendelve, k ivételes es emény, laphiba következik be. Emlékezzünk a ki vételes e seményekre ( exeption c ondition)! E zek e gy gépi i nstrukció s orán következnek be, lekezelésük után a kérdéses instrukció újból végrehajtódik. Nos, így van ez laphiba es etén i s. A l aphiba l ekezelõ rutin a m ásodlagos t árolóról "belapozza" (paging i n) a kérdéses l apot. E hhez k eres e gy s zabad l apkeretet, és o da l apozza b e H a n em t alaál s zabad lapkeretet, ak kor k iválasz v alamilyen, k

ülönben érvényes l apkeretet, az kilapozza ( ezzel a benne l évõ l apot not va lid á llapotúvá t eszi), é s a felszabadult l apkeretbe m ost m ár belapozhatja a l apot, eg yben é rvényessé i s t eszi. A l aphiba k ezelõ ez után v isszatérhet: a laphibát okozó instrukció most újból végrehajtva már hiba nélkül leképezheti a címet. Lássuk be, bár a megnevezés laphiba, egészen normális dologról van szó, természetes dolog, hogy laphibák keletkeznek. Legfeljebb az lehet baj, ha igen gyakori egy processz számára a laphiba, mert akkor a vezérlés menete nagyon lassan halad elõre, szinte csak ki-belapozással foglakozik a rendszer! Most már minden alpkonstrukciót ismerünk. Kérdések illetve követelmények fogalmazódnak meg bennünk: 1. 1 A processzenkénti laptábla mérete gond lehet Hogy lehetne azt csökkenteni, vagy kezelni? 2. 2 A címleképzést segíti a hardver, de mégis jó lenne azt gyorsítani Lehetséges ez? 3. 3 A laphiba kezelõ is

gyors kell legyen Itt jó kilapazási algoritmusokat kell találni 4. 4 V égül e gy p rocessznél a l aphiba g yakoriság i s g ond l ehet H ogy t udnánk a processzek szükséges l apjait benntartani a memóriaban, hogy ne legyen nagy a Page Fault ráta? 7.33 Laptábla méret kezelés A l aptábla m éretét a p rocessz m érete és a l apméret m eghatározza. T ermészetesen í rhatnánk kisebb programokat is, de most ne így keressülk a megoldást. A j ól m egválasztott l apméret t ermészetesen egy j ó l ehetõség. S ajnos, n éha eb ben a h ardver korlátoz: e mlékszünk, h ogy a m emóriamenedzseléshez e rõs ha rdver t ánmogatásunk i s va n, néha a ha rdver ne m e ngedi, hog y a r endszergazda na gyobb l apméretet válassazon, ezzel a laptábla méretét csökkentse. Tipikusan ilyen a helyzet a VAX processzoroknál: ott 512 bá jtosak lehetnek a lapok, ezzel a 32 bi ten ké pezhetõ 4 Gbájtos c ímtartományt 8 M byte be jegyzésszámú l aptáblával l ehet

átfogni. A VAX megoldás erre a g ondra a k övetkezõ: M inden p rocessz a laptábláját a s aját címtartományának 2 G byte és 3 G byte k özötti r észbében ( ez az ú n. S ystem cí mtartomány) tartja, és maga a laptábla is kilapozható. A System címtartomány laptáblája permanens (maga a terület azonban nem permanens!), és ennek címét minden processz egy MMU regiszterben tartja. A s aját la ptáblájának a c ímét egy má sik M MU r egiszterben f eljegyzi M ikor e gy procesz egy virtuális címét le kell képezni, veszik a címbõl a virtuális lapszámot (ez itt 21 bit hosszú), a p-t, és eltolják 2 bittel (mert a laptábla bejegyzés 4 byte hosszú). A kapott érték és a processz laptábla kezdõcím (MMU regiszterbõl) összege egy A virtuális cím, valahová a 2 G és a 3 G közé mutat: ahol is a processz laptáblája kezdõdik. Ezt az A virtuális címet megnézik, vajon ér vényes -e, a l apja b ennvan-e. H a ni ncs, e lõbb a l aptáblát be

ke ll l apozni Feljegyezhetõ ez a cí m a m ásik MMU regiszterbe, és az igazi címleképzés végre is hajtható. (Összegezve, a VAX egy címlepzés során kétszer is lapozhat, elõbb a saját laptábláját lapozza be, majd a tényleges lapot, amire a hivatkozás történt.) Más processzorok más megoldásokat kínálnak. Többszintû laptáblák. Képezzük a 32 bi tes vi rtuális c ím l apcímrészét k ét 10 bi tes m ezõbõl, é s 12 bi tes e ltolásból (7.7 ábra) A p1 mezõ index az elsõ szintû laptáblában, aminek a mérete most már csak 1024 bejegyzés. 7.7 ábra Többszintû laptáblák Egy be jegyzésében m utató va n a m ásodik s zintû l aptáblák ke zdõcímére. A m ásodik s zintû laptáblákat a p 2 c ímmezõ in dexeli: a p 2 é s a z elsõ s zintû l aptábla poi nterének ös szege a második s zintû l aptábla egy b ejegyzésére m utat. A m ásodik szintû laptáblák b ejegyzéseiben vannak a l apkeret címek: ezek összeadva az eredeti

virtuális cím 12 bites offset mezejével a valós cí met ad ják. V együk és zre, hog y a l aptáblák ös szmérete ki sebb l ehet! A dott e setben nincs i s s zükség 1024 da rab m ásodikk s zintû l aptáblára, hi szen a pr ocessz vi rtulis memóriájának valószínûleg kisebb a mérete, miont a lehetséges címtartomány! Többszintû l aptáblákkal dol gozik pl . a SUN S PARC pr ocesszora Itt há romszintû l aptáblák vannak, 8,8,6 bi tes l apcím m ezõkkel, 12 b ites e ltolás m ezõvel. A Motorola 68030 -as processzora n égyszintes l aptáblájú ( Next g épeink!). K étszintes l aptáblákat t ámogatnak az Intel processzorok. Az invertált laptáblák A H ewlett P ackard és a z I BM S ystem 3 8-as r endszerek i lyen m egoldással " csökkentik" a laptáblák méretét. Az el gondolás az, h ogy a cí mzés b itszélesség növekedésével n em t ud v ersenyt t artani a laptábla csökkentés, hiszen már vannak 64 bi tes címszélességû, sõt, 128

bites címszélességû rendszerek: Hiába "többszintesítünk", óriási méretûek lesznek a laptáblák. A fizikai memória mérete viszont nem növekszik ilyen gyorsan (sajnos), ezért jobb kiindulni a lapkertektõl. Az invertált laptáblákban lapkeretenként vannak bejegyzések: méretük akkora, hogy minden lapkeretnek legyen egy bejegyzése. Egy bejegyzés itt a védelmi maszkon kívül tartalmazza, hogy mely process (pid) mely lapja (p) va n pi llanatnyilag a l apkeretben. A l eképzéshez m eg k ell né zni a z i nvertált tá bal bejegyzéseit, hogy az adott processz adott lapja benn van-e egy lapkeretben. Ez a "megnézés" természetesen n em l ineáris k eresést j elent, a k eresés gyorsítására h ash ( hasításos)eljárást alkalmaznak. Ha az adott processz adott lapja egy lapkeretben megtalálható, a címleképzés sikeres. Ha nem, laphiba következett be, az kiszolgálandó, valami kilapozandó, a kért lap belapozandó. Az ol yan r

endszerek, amelyek i nvertált l aptáblával dol goznak, m indíg r endelkeznek a z MMU-ban as szociatív gyorsító t árral is. E zzel e l i s j utottunk a köve tkezõ ké rdéskörhöz: hogyan lehet tovább gyorsítani a címleképzést. 7.34 Címleképzés gyorsítása asszociatív tárral (Translation Lookaside Buffer: TLB) Az i lyen r endszerek M MU-jában l étezik e gy k isméretû as szociatív t ár, egy t ábla ( TLB), a következõ bejegyzésekkel: • virtuális lapcím, • valid bit, • módosítás bit, • védelmi maszk (rw bitek), • lapkeret cím. Láthatólag e zek u gyanazok a z i nformációk, amelyel egy s zokásos l aptáblában i s r ögzítettek szoktak l enni. V alóban a zok, de most eg y asszociatív t árbeli b ejegyzésben, m ely t árra jellemzõ a ta rtalom s zerint - a be jegyzéseiben pá rhuzamos - keresés. V agyis m ikor j ön e gy gépi i nstrukció, abban egy vi rtuális c ím, a nnak virtuális l apcímét pá rhuzamosan, e

gyszerre minden bejegyzésben keresi az MMU. Egyben nézi, érvényes-e (valid), mi a v édelme, és ha talál, azonnal adódik a lapkeret címe! Nincs tehát hosszadalmas leképzés, azonnali a találat! A p rogramok lo kalitása v alószínûsíti a találatot. H a a zonban n incs ta lálat a z a sszociatív tárban, akkor m egy a s zokásos l aptábla ke resés: kikeresi a l aptábla be jegyzését, ot t n ézi a z érvényességet, l aphibát g enerál, h a s zükséges. H a a s zokásos laptáblában m egtalálja a leképzést, azonnal be is teszi azt az asszociatív tár egy bejegyzésébe; arra gondolva, hogy a lokalitás miatt hamarosan újra szükség lesz a lapra. H a itt, az asszociatív tárban nincs hely, akkor va lmit i nnen "kivág", i lyenkor pe rsze n éznie ke ll a m ódosítás bi tet, s zükség e setén a rendes maptábla bejegyzésébe is be kell írnia a módosítás tényét. Gondot j elent pe rsze, hog y a s zokásos l aptábla felkeresés s orán be

következõ l aphiba e setén szükséges a k ilapozás. A kilapozás esetleg az asszociatív tárban is igazítást igényel Ilyenkor szokás szerint teljesen újratöltik az asszociatív tárat a közönséges laptáblák adataiból. Lássuk b e, az as szociatív t ár n em h elyettesíti a s zokásos r endes laptáblákat k ezelõ mechanizmusokat! Azok tehát megvannak, akár invertált formában, akár normál formában, az asszociatív tár alakalmazása csak további gyorsítást eredményezhet, elsõsorban a p rogramok lokalitására építve. Asszociatív tárral rendelkeznek a M IPS cég R2000, R3000 stb. processzorai, í gy mûködnek tehát a mi Indigóink is. Van egy kisméretû asszociatív tára az Intel processzoroknak is 7.35 Kilapozási algoritmusok (Page Replacement Algorithms) A l aphibakezelõ g yorsítás i s s zerepelt, m int a megoldandó f eladat. T ulajdonképpen i tt ké t problémával kellene foglalkozni: • meg lehetne-e mondani elõre, mely lapokra

lesz a közeljövõben szükség; • mely lapokat lapozzuk ki, ha a lapkeretek "elfogytak". Sajnos, a z e lsõ pr obléma m egoldhatatlan. V oltak ug yan kí sérletek, m elyekben p róbafuttatás során f eljegyezték a l apigénybevételi s orrendeket, és s oron k övetkezõ f uttatásoknál ez t a sorrendet használták az elõre való belapozás verérlésére, de használható megoldás ebbõl nem születhetett. Á ltalános célú r endszereknél az i lyen o ptimálás t eljességgel l ehetetlen A probléma m egoldását h agyták a z i gény s zerinti l apozási, m ajd a w orking s et konc epció stratégiákra, ezeknél jobbat nem sikerült eddig csinálni (e két problémakörre visszatérünk). Azon vi szont é rdemes g ondolkodni, m ik l egyenek a ki lapozandó l apkertek. Itt t alálhatók reális, megvalósítható algoritmusok. Mielõtt e zekre r átérnénk, á ltalános m egfontolások i s ho zhatók. O lyan fogalmakat f ogunk használni ( és m

egkülönböztetni), m int a l apok be lapozási i deje ( vagy s orrendje), a l apok hivatkozási i deje ( vagy sorrendje), a l apok hi vatkozási g yakorisága ( hivatkozások s záma). Azok a lapok, melyek nem írhatók, vagy ha írhatók is, nem módosítottak, kezelhetõk külön a kilapozás s orán. E zeket va lójában ne m s zükséges ki lapozni, mert t artalmuk ne m vá ltozott, elegendõ õ ket " elereszteni". A k övetkezõkben i smertetett al goritmusokat ez ek a t ények határozzák meg. A FIFO algoritmus A belapozási sorrend a meghatározó; minél régebben lapoztak be egy lapot, annál esélyesebb a kilapozásra. Az operációs rendszer ehhez az algoritmushoz a lapokat láncolt listán tartja, a lista e lején a r égebben b elapozott l apokat, a vé gén a l egutoljára be lapozott l apot. K ilapozni mindíg a lis ta e lejérõl v álaszt la pot. A mö göttes e lgondolás az, h ogy a "régi" la pokra má r nincs szükség. Amellett, h ogy a l

ista t árolás el ég er õforrásigényes, az el gondolás i s t éves. E gyáltalán n em biztos az, hogy a régen belapozott lapra nincs a következõkben szükség. (Igaz ugyan, hogy ha szükség va n, a kkor be lapozódva, a l ista vé gére kerülve s okáig ne m f og kilapozódni, a ddig, míg újra a lista elejére nem kerül, de lehet hátrányos az elgondolás.) Második esélyes FIFO Tartsuk a lapokat körkörösen láncolt listán, az egyszerû soros lista helyett, és tarsunk nyilván a lapokra egy hivatkozás bitet, valamint egy "óramutatót", ami a listán körbejárhat. A hi vatkozás bi t i tt ne m m inden ór amegszakításnál bi llen, ha nem csak akkor, ha t ényleges hivatkozás volt a lapra. Amikor kilapozásra van szükség, vizsgáljuk azt a lapot, amire a körkörös litán az óramutató éppen mutat. Ha ennek a lapnak a hivatkozás bitje bebillentett állapotú, ne lapozzuk ki, hanem töröljük a hi vatkozás bi tjét. E zzel t ulajdonképpen

a dtunk ne ki e gy m ásodik e sélyt: ha a z óramutató a körön körbejárva újra rámutat, és közben nem volt hivatkozás a lapra, akkor ki fog l apozódni. H a a m utatott l ap hi vatkozás bi tje t örölt, a kkor vi szont ki fog l apozódni A z óramutató mindenképp továbblép a körön. (Ezt az algoritmust szokás óra (clock) algoritmusnak nevezni, nem véletlenül.) Mostanában nem használatos lapok (Not Recently Used pages) NRU (Least Recently Used) LRU A pr ogramok l okalitásának e lvébõl ki indulva a zok a l apok l ehetnek k ilapozásra es élyesek, melyeket m ostanában ne m ha sználtak. A ké rdés a z, hogy an t udjuk e zt a t ényt r ögzíteni? Valamilyen m ódon n yilván kell t artani, hogy m ikor használták ut óljára a lapot. Vagyis nem azt rögzítjük, mikor lapozódott be, azt sem, hogy milyen gyakran hivatkoztak rá, hanem azt, hogy mikor hivatkoztak utóljára, esetleg azt is, mikor módosítottak a lapon utóljára. Az NRU lapok ki

lapozódhatnak, az L RU l apok l ehetõleg ne m: a z N RU é s L RU a lgoritmusok i gen közeli rokonok, majdhohgynem ugyanazok. Nem egyszerû és nem is olcsó a m egvalósítás! Minden lap használatának (és módosításának) idõbélyege t árterületigényes, a "rendezés", v agyis a r égen h asznált l apok k ikeresése n em könnyû! Az ig azi me goldáshoz k étszeresen lá ncolt lis tán ta rtják n yilván a la pokat, a l ista el ején a legutóljára ha sználtat. A l ista vé gérõl l apoznak ki s zükség e setén A l ista köz epén s zereplõ lapot, ha hivatkoznak rá, mozdítani kell a lista elejére. Közelítõ és sokkal "olcsóbb" megoldás a következõ: Legyen minden lapra nyilvántartva 2 biten a • R - referenced - hivatkozott jelzés, • M -modified - módosított jelzés. Az M bit bebillen, ha módosítás történt a lapon. Az R bit minden óramegszakításnál billenjen: R <- 1, ha az elõzõ idõquantum alatt hivatkoztak

a lapra, R <- 0, ha nem hivatkoztak. Ezzel a lapok 4 osztályba eshetnek: Osztály R M 0 0 0 1 0 1 2 1 0 3 1 1 Az NRU algoritmus szerint a legalacsontabb nem üres osztályból véletlenszerûen (vagy FIFO sorrend szerint) kiválasztva lapozzuk ki a lapokat. Ebben implicite benne van az, hogy a nem módosítottak " lapozódnak ki " i nkább. A m ódszer l egnagyobb e lõnye, hog y e gyszerû, könnyen megvalósítható, nem foglal sok helyet a nyilvántartás. A fenti közelítõ megoldást javíthajuk: a hivatkozásokat nemcsak az utolsó óraintervallumban, hanem e gy a dott - nem hos szú - visszamenõleges i dõintervallumban n yilvántartva t ovábbi "rendezést" vihetünk be. Például 8 bi ten ( 1 b ájton) t artsuk n yilván a hi vatkozásokat m inden l aphoz. A dott idõintervallumban m inden l ap r eferencia-bájtját lé ptetjük 1 b ittel jo bbra ( jobb s zélsõ b it kicsordulva elvész), a hi vatkozott lapoknál 1-et, a nem

hivatkozott lapoknál 0-t beléptetve a bal szélsõ bitre. Ezzel tulajdonképpen n yilvántartódik az utolsó 8 idõintervallumban a lapok "hivatkozási hi stóriája", e gy r endezés a m ostanában (az ut olsó 8 i dõintervallumoban) legkevésbé, vagy leginkább használt lapokra. A kisebb bájt érték a kilapozásra esélyes lapokat (mostanában nem használt l apok), a nagyobb bá jt-érték m ostanában i nkább használt lapokat jelez. Mostanában legkevésbé használt (Least FrequentlyUsed) LFU algoritmus (Not Frequently Used) NFU Az alapgondolat: az utóbbi idõkben gyakrabban használt lapoknak legyen nagyobb esélyük a bennmaradásra. N em a l apok hi vatkozási i deje, s orrendje, h anem a hivatkozási frekvencia a rendezõelv. Nagyon jó a gondolat, csak elég drága lehet a megvalósítása Lehetne pl láncolt listán tartani a lapokat, elején (vagy éppen a végén) azt, amire leggyakrabban hivatkoztak, de nagyon i dõigényes v olna a l ista k

arbantartása! Nem i s a f elfûzés a l istára, h anem a l ista közepérõl a levétel, egyáltalán a lap megtalálása a listán gondot jelent. Más megoldás is szóba jöhet persze, pl. minden lapra nyilvántartunk egy számlálómezõt, ami t növelünk, ha a lapra hivatkozás történt. A kilapozásra esélyesek azok a lapok, melyeknél a számlálómezõ k icsi. R ögtön je lentkezik k ét g ond E gyik: e lég n agy s zámlálómezõt k ell biztosítani, p l. a l aptábla b ejegyzésében, ami n öveli a l aptábla m éretét ( emlékszünk, ez probléma volt már). A másik a processzek idõszerûségenek változásával függ össze: lehetnek lapok, m elyeket gyakran ha sználtunk a m ultban, m ostanában vi szont ne m ha sználatosak. Amíg a t öbbi l ap s zámlálója "felnövekszik" e rre a s zintre, a ddig n em t udnak be csületesen versenyezni! Ha ki lapozódnak, belapozódnak, új ra kezdik a s zámlálást. Lehetnek anomáliák ebbõl. A tiszta LFU, NFU

ezért nem is használatos. A s zámlálómezõs m egoldást l ehet az onban al kalmazni, h a r áteszünk m ég e gy "öregedés" (aging) algoritmust. N övekszik a s zámlálómezõ min den la phivatkozással, a z óraintervallumokban azonban c élszerû aging konstanssal be szorozva ör egbítjük. Így az idõszerûségüket e lvesztõ l apok s zámlálómezeje c sökken, e sélyt adva a frissebb l apoknak a versenyre. 7.36 Igény szerinti lapozás és a Working Set modell A hivatkozási lánc fogalama (Reference String) A pr ocesszek f utásuk köz ben m emóriahivatkozási s orozatot g enerálnak. M inden memóriahivatkozásnak me gfelel e gy s pecifikus v irtuális la pcím. A p rocesszek memóriahivatkozásai te hát je llemezhetõk v irtuális l apcímek s orozatával: ez t a l apcím sorozatot nevezzük a processz hivatkozási láncának, azaz reference string-nek. A hivatkozási lánc tehát lapcím lista, a processz a futása közben e lista szerinti

sorrendben igényli a lapokat. A lapozó rendszerek jellemezhetõk a • a processzek hivatkozási láncával; • a kilapozási algoritmussal; • a lapkeretek számával. Gondot jelent persze, hogy a processzek hivatkozási láncát nehéz elõre megjósolni (pedig jó lenne elõre belapozni a közeljövõben szükséges lapokat, vagy nem engedni kilapozni azokat, még ha a ki lapozó a lgoritmusunk i lyen dönt ést i s hoz na); é s g ondot j elent a z i s, hogy t öbb processz élhet egy idõben. Az igény szerinti lapozás (Demand Paging) A lapozás legegyszerûbb és legtisztább formája szerint, amikor eg y p rocessz indul, eg yetlen egy lapja sincs a memóriában. Amint a CPU be akarja hozni az elsõ instrukciót, bekövetkezik a l aphiba, a minek ha tására a k ernel be hozza a z e lsõ l apot a hi vatkozási l áncból. T ovábbi laphibák ge nerálódnak ( pl. a g lobális vá ltozók m iatt, a v erem m iatt), melyek h atására a hivatkozási l ánc egyre t

öbb l apja belapozódik. Egy i dõ ut án a processz elegendõ l apja benn van a m emóriában, a l aphiba g yakorisága c sökken. E zt a s tratégiát ne vezik igény szerinti lapozásnak (Demand Paging), hiszen egy lap csak akkor kerül be, ha igény merül fel rá, elõre nem lapozunk a stratégia szerint. A stratégia kidolgozói remélik, hogy di namikus egyensúly állhat be a processzek bennlévõ lapjai és a felmerülõ igények között. A Working Set fogalom Egy processz azon lapjainak összessége, melyeket egy adott "pillanatban" használ a p rocessz munka-lapkészlete. ( Working S et) H a m inden l apja a munkakészlethez tartozik, ne m következik b e r á l aphiba. H a a f izikai m emória k icsi, a m unkakészlethez k evesebb l ap tartozhat, e kkor b e fog köve tkezni e lõbb-utóbb l aphiba. A pr ocesszek f utásuk köz ben jellemezhetõk a "pillanatnyi" laphiba-gyakorisággal, a P age Fault r átával. A fent említett igény s zerinti l

apozásnál kezdetben nagy a l aphiba g yakoriság, és r emény szerint késõbb ez csökken. Lássuk be , e z a "pillanatnyi" fogalom m eglehetõsen ködös ( fuzzy) fogalom. A l aphiba gyakoriság nem egy pillanatnyi helyzetet jellemez, hanem egy idõ intervallumot, a pillanatnyi (current) id õtõl v iszaszámítva v alamennyi ó rajelnyi id õt, egy id õ-ablakot. E setleg a munkakészlet úg y is megadható, ho gy a p rocessz hi vatkozási l áncának egy r észe e z, visszamenve a l áncon v alameddig. N em n ehéz megoldani, h ogy a r endszer t artsa n yilván a processzek m unkakészletét, a hi vatkozási láncukat va lameddig vi sszamenve. ( Persze, eh hez megfelelõ kilapozási algoritmus is tartozik!) A Working Set modell (Dennis, 1970) Tartsuk n yilván a pr ocesszek m unkakészletét. B iztosítsuk, hogy ez a m emóriában l egyen, mielõtt a processzt futni hagyjuk. Ez a konc epció csökkenteni fogja a l aphiba g yakoriságot Elõre va ló be lapozás (

prepaging) i s m egvalósítható: l apokat e lõre be lapozunk, m ielõtt a processzt futni engedjük. Kérdések s ora m erül f el be nnünk pe rsze, m i is va lójában a m unkakészlet ( lapok va gy lapkeretek k észlete), m ekkora l egyen egy-egy pr ocessz m unkakészlete, m ilyen l egyen a kilapozási stratégia ekkor stb. Lokális és globális startégiák. Elõzõekben be széltünk a ki lapozási s tartégiáknál. A m unkakészlet m odell ka pcsán felmerül bennünk, hogy ha egy processz egy új lapját kell belapozni, és emiatt kilapozásra is szükség van, a kkor a ki lapozás ug yanennek a p rocessznek a m unkakészletébõl t örténjen ( lokális startégia), vagy más processzek munkakészlete is figyelembe vevõdjön (globális startégia). A lokális stratégia annak az elgondolásnak felel meg, hogy minden processz kap valamennyi (rögzített s zámú) l apkeretet, am ivel gazdálkodhat. Itt, h a a p rocessz l apkeret-készlet n õ, a laphiba gyakorisága

csökkenni fog és fordítva. A globális startégiában a processzeknek nincs rögzített lapkeret számuk, az mindíg változik. Egészítsük ki a l okális s tratégiát a köv etkezõképpen: a pr ocesszek ne r ögzített s zámú lapkeretet ka pjanak, h anem a zt vá ltoztassuk bi zonyos ha tárok kö zött. A vá ltoztatás szabályozásához ha sználjuk a l aphibagyakoriságot, a mi m érhetõ. H a n agy a l aphiba ráta, növeljük a l apkeretek s zámát, ha a lacsony a l aphiba, a kkor c sökkentsük. Ú jradefiniáljuk a Working Set fogalamat is: a pillanatnyilag processzhez rendelt lapkeretek készletét, nevezzük ezentúl m unkakészletnek. A " pillanatnyilag" be nn l évõ l apok t eljesen ki töltik a mukakészletet. A l aphiba gyakorisággal t ehát bizonyos l apkeret e gységekkel növe ljük a munkakészletet, pe rsze c sak e gy adott ha tárig, i lletve c sökkentjük bi zonyos l apkeret számokkal, m egint cs ak eg y al só h atárig. A p rocesszek m

unkakészletei k özött így b eállhat egyensúly, egymás rovására növelik, csökkentik a készleteiket, attól függõen, hogy milyen a laphiba rátájuk. Tulajdonképpen a laphiba rátákat tartjuk határok között Még egy gondolatot vessünk fel: ha sok processz él egy idõben, midegyiknek magas lehet a laphiba rátája, mert a m unkakészletek összessége (a Balance Set) nem n övekedhet. Ilyenkor legjobb l enne e gyes processzeket t eljesen ki söpörni a m emóriából, helyet adva a t öbbinek a racionális f utásra. A köve tkeztetésünk t ehát a z, hogy a l apozás m ellet i s j ó vol na a szegmentálás és ki-besöprési koncepció! 7.4 A szegmentálás A virtuális memória - ahogy eddig t árgyaltuk - "egydimenziós" volt: a v irtuális címek 0-tól mehettek v alameddig, a cí mtartományban a cí mek követték egymást (lehettek u gyan a címtartományban "hézagok"). Sokszor jó lenne valamilyen "többdimenziós"

címzési rendszer: • külön címtartomány, 0 - valameddig, a program kódnak; • kölön címtartomány, 0 - valameddig, az adatoknak; • külön címtartomány, 0 - valameddig, a veremneké • külön címtartomány, 0 - valameddig, az osztott könyvtári rutinoknak stb. Szegmenseket k épzelünk e l, e zeknek kül ön c ímtartományaik v annak, m indegyik 0 -tól kezdõdik, é s pe rsze ne m e gyforma m éretûek. A vé delmük i s kül önbözõ l ehet M inden szegmnes a c ímek lin áris s orozata, 0 -tól kül önbözõ m éretekig. A s zegmensek hos sza a kár változhat is, növekedésük, csökkenésük azonban egymástól független. A tiszta szegmensenkénti címleképzés Ez v alamelyest h asonlít a l aponkénti cí mleképzéshez. A l aptábla h elyett itt s zegmenstábla van, és a leképzés során nem egyforma méretû blokkokban képzünk le, ezért a szegmenstábla soraiban a szegmens hossza is szerepel (7.8 ábra ) 7.8 ábra Szegmensenkénti

címleképzés A leképzés itt is dinamikus, instrukciónként történik, és az MMU itt is támogatja a leképzést. Ha a s zegmens ni ncs a memóriában, b e ke ll s öpörni ( swapping i n). E hhez s zükség e setén helyet ke ll csinálni: m ás s zegmensek ki söprõdnek ( swapping out ). Belátható a z i s, ho gy a szegmentálós rendszerknél ki sebb gond a s zegmenstábla m éret. V alószínûtlen, hog y túl s ok szegmensbõl álljon egy processz. Milyen rendszerek lehetnek? Vannak tiszta lapozó (pure paging)rendszerek. Vannak tiszta szegmentáló, ezzel ki-besöprõ rendszerek. Vannak s zegmentáló-ki-besöprõ é s ug yanakkor l apozó r endszerek i s. E kkor a ki -besöprés során g yakori, ho gy a teljes kont extus k i-besöprõdik, he lyet bi ztosítva a t öbbi pr ocessz számára a lapozáshoz, moderálandó azok laphiba gyakoriságát. A kombinált rendszerekben a s zegmenstábla bejegyzésében nem a szegmens címre mutat az s, hanem hanem a szegmenshez

tartozó laptábla kezdetére: itt tehát szegmensenként vannak a laptáblák. Általában a f elfüggesztett ( suspended) pr ocesszek e sélyesek a ki söprésre, va gy a zok, amelyeknek hosszú idõ óta nincs aktivitásuk. Lehetnek ilyenek bizonyos daemon processzek, melyekhez hos szú i dõ ót a ne m j ött ké relem, d e l ehetnel t erminálhoz köt ött pr ocesszek i s, melyek m ár hos szú i dõ ót a bl okkoltak t erminál i nputon ( pl. e lment a f elhasználó vacsorázni.) 7.5 Szegmentáció és lapozás a 386/486/stb proceszornál A híres 386/486/stb. processzoroknál 16K független szegmens lehetséges Ennyire ritkán van szükség. Még egy elõnyös tulajdonsága: egy-egy szegmens 10 9 32 bites szót tartalmazhat, ez már ki is használható. A címszámításhoz a 386-os két táblát tart fenn: • LDT - Local Descriptor Table, processzenkénti tábla; • GDT - Global Descriptor Table, egy van belõle, a rendszer címtartományhoz. Az LDT segíti a processzek

kód, adat, verem stb leírását. A GDT a rendszert, a kernelt magát írja le. A processzornak van 6 s zegmens regisztere. Ismerõs a CS, DS, SS, ES stb Ezek 16 bi tesek, és egy -egy szegmens kiválasztóját (selector) tartalmazhatják. A selector felépítése az alábbi ábrán látható: 7.9 ábra A szelektor felépítése A szelektor 13 bites indexe belépési pont az LDT/GDT-be. (Ebbõk következõen a ?DT táblák sorainak s záma 2 13, és m ivel eg y-egy s orban 8 bá jtos de szkriptor t alálható, ki számíthatjuk maximális méretüket.) Az instrukciókban a címek formája: szelektor, eltolás párok: cím = (selector,offset) A d inamikus cí mleképzés s orán a s elector ér ték b etöltõdik v alamelyik, a m egfelelõ szegmensregiszterbe ( pl. in strukció c ímzésnél a C S r egiszterbe) U gyanakkor a m egfelelõ leíró t áblából (Descriptor Table) az i ndexelt l eíró betöltõdik a CPU m ikroprogramjának e gy regiszterébe ( ezek u tán a descriptor

gyorsan el érhetõ). ( Most n em t árgyaljuk az t az es etet, amikor a s zegmens ki v an " lapozva", m indenesetre e kkor " trap" köve tkezik be , a s zegmens belapozódik.) A 710 ábrán látható címleképzés történik ekkor 7.10 ábra A lineáris cím kiszámítása A 8 bájtos descriptor szerkezete elég bonyolult. Benne a • bázis c ím 32 bi t l ehet, d e a f elülrõl va ló kom patibilitás mia tt 1 6, ill. 2 4 biten is tu d dolgozni. • A l imit m ezõ max 2 0 b ites. V agy t énylegesen a s zegmens m éretét t artalmazza bájtokban, va gy 4K -s lapjainak s zámát ( ebbõl: a s zegmens m aximális mé rete kiszámítható). • Az egyéb mezõket nem részletezzük. Amit nagyon fontos megjegyezni: az eddigi címszámítás eredménye egy 32 bites lineáris cím. A p rocesszornál l ehet e ngedélyezett, v agy l ehet l etiltott a l apozás. E zt a t ényt 1 b iten a globális kont roll r egiszterben t árolják. A l apozás a 286 -oshoz

va ló kom patibilitáshoz használják. Ha a lapozás letiltott, a kiszámított lineáris cím a fizikai cím, kiadható a buszra. Ha a l apozás e ngedélyezett, a l ineáris c ím vi rtuális c ímnek ve võdik, e kkor f olytatódik a címleképzés, méghozzá kétszintû virtuális cím - fizikai címleképzéssel (7.11 ábra) 7.11 ábra A fizikai címszámítás Megjegyezzük még, hogy a processzornak van egy kisméretû asszociatív tára is (a Dir-Page kombinációkra), ami a virtuális-fizikai címleképzést gyorsítja. Lássuk be a következõket: • Megõrizték a felülrõl való kompatibilitást (Paging disabled). • Lehetséges a t iszta l apozás ( Minden s zegmensregiszter u gyanazt a s zelektort k apja. Engedélyezett a lapozás, mindíg ugyanarra a laptáblára, múködhet az associatív tár). • Lehetséges a t iszta s zegmentálás ( Különbözõ é rtéket ka pnak a s zegmensregiszterek, de letiltott a lapozás). • lehetséges a s

zegmentálás-lapozás kom bináció ( Külön s zegmensregiszterek, engedélyezett lapozás, asszociatív tár kihasználva). 7.6 A Windows NT memóriamenedzselése 7.61 Általános jellemzés Az N T me móriamenedzselése v irtuális, T LB-t i s ha sználó ké tszintû l aptáblás l apozós (ugyanekkor i nvertált l aptáblához ha sonló l aptábla a datbázist i s ha sználó), m unkakészletetet kezelõ ( azt i gazító), l okális m ásodesélyes FIFO k ilapozásos algoritmussal rendelkezõ, i gény szerinti belapozó. 7.62 Memória allokáció Az N T t aszkok ( többfonalas pr ocesszek) 32 bi t s zélességen 4G B l ineáris c ímtartományt látnak. Ennek f elsõ 2G B-ja rendszercímtartomány (kernel m ódban elérhetõ), alsó 2 G B-ja a felhasználói mó dú c ímtartomány. A c ímtarományt 4 K B-os l apokra os ztják: e z 12 b it szélességû el tolás ( offset) ér tékkel l efedhetõ. A 4 G B cí mtartományt p ersze n em h asználja tejesen: vannak

"lefoglalt" címtartomány szakaszok, melyeket a Virtual Address Descriptorok tartanak n yilván. Memória allokáció során éppen új címtartomány szakaszt vesz fel egy-egy taszk: új de szkriptor bejegyzéssel ( kezdõ-vég-címmel), és cs ak a mikor t énylegesen használnánk is e zt a z ú j c ímtartományt ( comitting), a kkor in icializálják a la ptábla bejegyzéseket (kétszintû memóriaallkoció). Különleges m emóriallkoáció a " leképzett f ájl" (Mapped F ile) obj ektum. A z obj ektumot beillesztik a létrehozó taszk virtuális címtartományába (ez a nézet: view), ezután a taszk úgy látja fájlt, mintha teljes egészében a memóriában lenne, betöltésérõl és a módosítások lemezre írásáról a memóriamenedzser gondoskodik. Egy taszk több nézetet is létesíthet ugyanahhoz az objektumhoz, t öbb t aszk i s ké szíthet s aját né zetet m egosztott obj ektumhoz. A " klasszikus" közös memória p edig

felfogható a le képzett f ájl s peciális esetének: a z objektum mö gött a lapozófájl van. Most j egyezzük m eg a következõket i s: a di namikus c ímleképzés s orán e lõször é ppen a deszkriptorok segítségével az ellenõrzõdik, hogy cím lefoglalt memóriaterületre esik-e, vagy sem. H a n em, azonnal k eletkezik az ér vénytelen cí mre h ivatkozás k ivételes es emény, n em kell végignézni a T LB-t, a laptáblázatokat a címleképzéshez. Úgy is mondhatjuk, a laptáblák már csak a lefoglalt címtartományokat tartják nyilván. 7.63 A címleképzés elsõ szintje: TLB A 3 2 b ites lin eáris c ím v irtuális c ím. L eképzése a p rocesszorban megvalósított, e zért processzorfüggõ "címleképzés m egkerül t áblázat" ( Translation Lookaside B uffer) vizsgálatával kezdõdik. A TLB, mint tudjuk, asszociatív áramkör, úgy képzelhetjük el, mint egy ké toszlopos t áblázatot. e gyik os zlopa m aga a vi rtuális c ím (

annak 20 l egnagyobb helyiértékû bitje), a másik pedig a hozzájuk tarozó laptábla bejegyzések. A címképzés során a processzor a cí m l egnagyobb h elyiértékû 20 bi tjét pá rhuzamosan ös szeveti a z e lsõ os zlop bejegyzéseivel, és t alálat es etén az onnal k apja a l aptáblabejegyzéseket. H a n incs t aálata a TLB-ben, akkor indítja a szokásos laptáblakeresési eljárást. 7.64 Kétszintû laptáblák, prototípus laptábla A l ineáris c ím s zokásosan 2 s zintû l aptáblás m egoldással ké pezhetõ va lós c ímre. A z e lsõ szintû la ptábla n eve itt: laptábla katalógus (page directory). A v irtuális c ím e lsõ 1 0 b itje indexeli: m érete t ehát 1024 be jegyzés, e gy b ejegyzés 4 bá jt. M inden t aszknak i lyen m éretû saját l aptábla k atalógusa v an. E gy-egy be jegyzése e gy-egy m ásodik s zintû la ptábla kezdõcímét tartalmazza. A második 10 bi t indexeli a második szintû laptáblákat, ezek a neve egyszerûen:

laptábla. M éretûk 1024 be jegyzés, é s c sak a nnyi l aptábla t artozik eg y-egy taszkhoz, a mennyi s zükséges. E gy-egy b ejegyzés t árolja a l ap s tátusz-védelmi b itjeit é s lapkeretet, vagy pedig prototípus laptáblát (Prototype Page Table), vagy másodlagos tárolót indexel. A védelmi bitek: • Érvényes (valid) l ap ( érvényes l ap b ejegyzése l apkeretet v agy p rototípus l aptáblát indexel, érvénytelené a lap helyét a másodlagos tárolón); • Csak olvasható (read only) lap; • Teljes jogú (read/write) lap; • Csak futtatható (execute only) lap (csak speciális processzoroknál van értelme); • Figyelt (guarded) lap (Elérésük kivételes eseményt generál. Pl verem vége figyelhetõ így.); • Tiltott (no access) lap (elérésük eseményt generál); • Zárolt (locked) lap (Nem lehet kilapozni ezeket); • Módosításkor másolt (copy on write) lap. A st átusz-védelmi b itek é rtelezésébõl a z u tolsót k ell

to vább ma gyarázni. E z a v édelmi módszer a z os ztott m emóriahasználatban a "halogató t echnika" egy formája. V együnk e gy példát. Az NT tejesíti a POSIX taszk-kreáció elõírást: a gyermek taszk kontextusa majdnem teljesen e gyezik a s zülõjével ( v.ö U nix f ork), a zaz a g yermek kód é s adatszegmenseit l átni kell a gy ermek c ímtarományához r endelve i s. H a a g yermek ne m m ódosítja kont extusát (kódját valószínûleg egyáltalán, s okszor az adatait s em), akkor a "másolás" fölösleges. J obb megoldás, h a e gyáltalán ne m m ásolunk, ha nem m indkét t aszkban m ódosításkor m ásolt státusszal el látott b ejegyzésekkel a l aptáblákban k özös l apkeretekre h ivatkozunk. H a ez ek után b ármelyik ta szk mé gis mó dosít v alamely megosztott la pon, a me móriamenedzser lemásolja s zámára a k érdéses l apot ú j l apkeretbe, és a l aptáblázat b ejegyzéseket f elfrissíti, kitörölve a

módosításkor másolt bejegyzést, a másik taszkban meghagyva az eredeti lapkeret hivatkozást, a módosító taszkban feljegyezve a másolatra történõ hivatkozást. Szintén a z o sztott me móriakezelés p roblémaköréhez ta rtozik a n em h alogatott me mória megosztás: akár a leképzett fájl objektum, akár a klasszikus osztott memória objektum esete. Ez az NT a prototípus laptábla segítségével kezeli. Ha ú gy t etszik, a prototípus laptábla egy t ovábbi s zint a l aptábla r endszerben. T öbb t aszk által h asznált l apoknál ( shared p ages: e gy l apkeretre t öbb l aptábla b ejegyzés i s m utatna) a laptáblák ne m köz vetlenül m utatnak a l apkeretre, ha nem a pr ototípus l aptáblán ke resztül: ilyenkor e z a tá bla tá rolja a v édelmi b iteket, a s tátuszt. A f ent má r e mlített " leképzett f ájl" objektumok, e zek s peciális e seteként v ehetõ kl asszikus m emóriaosztás kezelése t örténik a prototípus laptábla

segítségével, szerencsére a programozó számára transzparensen. 7.65 A lapkeret adatbázis A fizikai memória nyilvántatartására (pl. a szabad lapkeretekkel való gazdálkodásra), a ki- és belapozás s egítésére az N T m emóriamenedzsere az i nvertált l aptábla k oncepció s zerinti laptáblát, lapkeret adatbázist (Page Frame Database) is fenntart. A l apkeret ad atbázis i s egy t áblázat: l apkeretenkénti b ejegyzésekkel. M érete t ehát a f izikai memóriától f ügg. E gy-egy b ejegyzése i nformációkat t árol a k eretek ál lapotáról, v alamint "visszamutatót" la ptábla b ejegyzésre ( amibõl kiderül, m elyik t aszk h asználja a l apkeretet, melyik lapját tárolva benne. Az állapotinformációk: • Érvényes (valid) keret: használatban lévõ keret, van benne leképzett lap; • Szabad (free) keret: egy taszk sem használja, kiosztható. jegyezzük meg: ha egy taszk terminálódik, az ál tala használt k eretek s zabaddá v

álnak és ez f el i s jegyzõdik a lapkeret adatbázisban. • Nullázott (zeroed) keret: szabad keret, kitöltve 0-kkal. (A C2 biztonsági szabványnak megfelelõ m emóriakezelést t esz l ehetõvé: n e l ehessen s zabaddá v ált l apokrõl információkat szerezni); • Készenléti (standby) keret: tulajdonképpen felszabadított keret, de még megtalálhatók rajta a l apot-lapkeretet k orábban h asználó t aszk ad atai. A z i lyen k ereteket m ég "visszakérhetik" vi szonylag ol csón: ha úg y t etszik m ásodik es élyt ad va a k eretneklapnak. • Módosított (modified) keret: a készenlétihez hasonlóan már felszabadított (lemondott róla a t aszk, v agy erõszakkal el vették t õle) k eret, d e ú jrafelhasználása el õtt az ta lemezre kell írni. • Hibás (bad) k eret: m egbízhatatlanul m ûködõ ke retekre ( vagy keretekre, melyeket ki akar vonni a gazdálkodásból) a memóriamenedzser ráírhatja ezt a bejegyzést. A l apkeret ad

atbázisban a k eretek s tátuszának f eljegyzése m ellett 5 láncolt listán is va nnak nyilvántatartások. Létezik a: • szabad keretek láncolt listája; • nullázott keretek láncolt listája; • készenléti keretek láncolt litája; • módosított keretek listája; • hibás keretek listája. Az N T m emóriamenedzsere folyamatosan figyeli a s zabad, a n ullázott és a k észenléti l istán található el emek s zámát, és h a ez b izonyos ér ték al á cs ökken, a m ásodlagos t árolóra í rja a módosított k ereteket é s a k észenléti lis tára á tteszi a zokat. A mó dosított keretek me ntését a módosított-lap-író (Modified Page Writer) rendszertaszk végzi. Ha még így is kevés a szabadnullázott-készenléti k eretszám, t ovábbi t evékenységek i st örténnek ( taszkok munkakészletének cs ökkentése: t rimmelés, k eretek er õszakos f elszabadítása s tb., l ásd késõbb). M ost m égegyszer l eszögezve, ho gy a

fizikai m emória n yilvántartásának ku lcsa a lapketet adatbázis, többprocesszoros rendszereknél külön gondoskodni kell ennek védelmérõl. Forgózár ( spinlock) vé di a z a datbázist a kr itikus s zakaszokra, s orbaállás köve tkezhet be (hiába v an t öbb p rocesszor), ez ért m emóriamenedzser ez zel k apcsolatos kr itikus s zakaszait nagyon hatékonyra kellet írni. 7.66 A címleképzés a kétszintû laptáblákkal Tételezzük fel, hogy a processzor a TLB-ben való keresésben sikertelen volt, ekkor indítja a szokásos laptábla-rendszer szerinti leképzést. A taszkhoz tartozó lapkatalógust a cím elsõ 10 bitje tartalmával indexelve kikeresi a m egfelelõ laptáble kezdõcímet, ezt a t áblát indexelve a második 10 bittel kikeresi a laptábla bejegyzést. Itt a státuszt vizsgálva, ha az érvényes, veszi a mutatót a l apkeretre (vagy prototípus laptábla bejegyzésre). A lapkeret címbõl és az eredeti virtuális cím eltolás értékébõl

adódik a valós cím, kiadható a buszra. Közben a védelmek is kezelhetõk, szükség esetén a lapkeret adatbázis módosítható. Amennyiben a l aptábla b ejegyzés ér vénytelen s tátuszú, k ielelhetõ b elõle a k érdéses l ap másodlagos tárolón való helyére utaló mutató és laphiba következik be. 7.67 A laphibák kezelése, kilapozás, munkakészlet kezelés A l aphiba k ezelõ eg y-egy t aszk s zámára v égzi m unkáját, n em n agy h iba t ehát, ha a szóhasználatunkban nem a kezelõt, hanem a taszkot fogjuk rendre említeni. Az N T me móriamenedzser min den ta szk s zámára mu nkakészletet ( working s et) b iztosít, minden ta szk b izonyos s zámú la pkeretet k ap. A k észletnek v an ma ximális é s min imális értéke. A rendszerállapottól függgõen a készlet csökkenthet (automatic workig set trimming), növekedhet ( magas l aphiba r áta a t aszkon é s va n e legendõ s zabad ke ret). E gy-egy t aszk lokális F IFO ki lapozási a

lgoritmussal " gazdálkodik" a m unkakészletével: s züksége e setén a legrégebben b etöltött la pját " szabadítja" f el. A "felszabadítás" v alójában a k észenléti v agy módosított listára való áttétel: ez azt jelenti, hogy a gyakran használt lapokat a "felszabadítás" után a zonnal vi ssza i s kérheti, va gyis a l apok ka pnak e gy m ásodik e sélyt i lyen m ódon. ( Az igazi f elszabadítást va lójában a m ódosított l apíró pr ocessz vé gzi, s zükség e setén.) M iután a taszk " felszabadított" k ertet, a n ullázott-szabad-készenléti lis táról p ótolja mu nkakészletét: választ keretet és abba belapoztahatja lapját. A virtuális memória kezelõ tehát, ha úgy érzi, aktiválja a módosított lapíró processzt, ami a módosított s tátuszú k ereteket k ilapozza, u tána azo kat át teszi a k észenléti listára. H a ez s em segít, átnézi, v an-e ol yan t aszk, m elynek m

unkakészlete na gyobb, m int a t aszkhoz t artozó minimális é rték. H a va nnak i lyenek, e zeknek a m unkészletét c sökkenti ha e zután s incs elegendõ me mória, v alamennyi ta szkra e lvégzi a k urtítást: k ényszeríti a ta szkokat a "felszabadításra". H a a memóriakrízis m egszûnik, az e gyes t aszkok l aphibarátáját figyelve kezdi növe lni a zok m unkakészlet m éretét. T aszkok t erminálódása e setén a zok munkakészleteit m egszünteti, a k ereteiket s zabad l istára t eszi. T aszkok s zületése es etén biztosít számukra munkakészletet. 7.68 Laphibakezelés, belapozási algoritmus Alapvetõen szükség szerinti (demand paging) algoritmus szerint történik a belapozás, azzal a kis m ódosítással, hog y a l okalitás e lvét i s figyelembe vé ve a s zükséges l apokat köz refogó (néhány) lapot is belapozzák egyúttal. 8. Az I/O rendszer, eszközök, másodlagos tárolók, fájlrendszerek Az ope rációs r endszer I/O

a lrendszerének e gyik f eladata, ho gy a felhasználók (alkalmazásfuttató, pr ogramozók s tb.) e lõl elrejtse a ha rdver eszközök kül önbségeit, specialitásait, k ényelmesen l ehessen a z e szközöket f orrásként va gy n yelõként ha sználni, a z eszközökre, e szközökrõl a datokat t ovábbítani. M ásik f eladata a z e szközök m enedzselése, a processzek s zámára erõforrásként b iztosítani az es zközöket, az ok s zolgáltatásait, es etleg ütemeznie kell az eszközökhöz való hozzáférést, védeni kell az eszközöket, konkurrens vagy kizárólagos hoz záféréseket m egkülönböztetve, vé delmi t artományokat n yilvántartva. Az I/O eszközök köz ött ki tüntettettek a bl okkorientált ( struktúrált, di szkes) e szközök. E zek ugyanis m ásodlagos t árolóként ha sználhatók, a kár vi rtuális m emória ki söprési, ki lapozási területeként, akár fájlrendszer hordozójaként. Nézzük elõször, hogyan is

"látjuk" különbözõ szemszögekbõl az eszközöket, a fájlrendszert. 8.1 Az I/O, eszközök, fájlrendszer különbözõ szemszögekbõl 8.11 A felhasználó látásmódja A f elhasználó az es zközöket és a f ájlokat szimbolikus neveiken ismeri. A f elhasználói kapcsolattartó r endszerben e zeket a s zimbolikus ne veket ha sználja. Korszerû ope rációs rendszerekben a hierarchikus fájlrendszert lát. Ehhez ismeri a jegyzék (katalógus, direectory) fogalmat, az ösvény (path) f ogalamat, a gyökér jegyzék (root d irectory) fogalamat, munkajegyzék (working di rectory) f ogalmat s tb. A f ájlrendszer "látásához" há rom dol got ismer: • fájlok együttesét; • jegyzék struktúrát, ami információkat ad a fájlok csoportosítására; • logikai eszközt (partíciót, diszket), amin a fájlrendszer elhelyezkedik. A f elhasználó s zámára a f ájl a l egkisebb eg ység a m ásodlagos t árolón, a mit k ezelni s zokott

(ritka, hogy a diszk struktúrát, a blokkokat, még ritkább, hogy oldalakta, sávokat, szektorokat kezeljen). A kapcsolattartó felület segítségével képes kezelni az eszközöket, a fájlokat: másolhat (copy), mozgathat (move), törölhet (delete, r emove) f ájlokat, elõállíthatja a zokat v alamilyen segédprogrammal, fejlesztõvel stb. A kapcsolattartó parancsai magasszintû "utasításkészletet" biztosítanak az eszközök, fájlok kezeléséhez. A felhasználó az eszközök, fájlok kezelésében ismeri az eszköz-és fájvédelmi koncepciókat, a tulajdonossági- és védelmi kategóriákat, ez eket h asználja, b eállítja s tb. L át e gyéb attribútumokat is: pl. készítési, utolsó elérési, vagy módosítási dátumokat stb Bizonyos operációs rendszerekben a felhasználó lát fájlszervezési módokat (file organisation) is: a zaz ne mcsak a f ájlneveket, a ne vekhez ka pcsolódó a ttribútumokat, a né vhez t artozó adatokat, ha nem a f

ájl s truktúráját i s. E zekrõl a z ope rációs r endszer né zõpontja t árgyalása során kicsit többet is szólunk. Ez a látásmód a felhasználói látásmód. 8.12 A programozó látásmódja A f olyamat ( process) s zemszögébõl m inden I/O e szköz va gy fájl e gy csatorna (stream). A csatornát a f olyamat megnyitja (open, fopen, create s tb. r endszerhívások): e zzel be lsõ azonosítót rendel hozzá. Ez az azonosító lehet egy egész: fájl-leíró, lehet egy fájlpointer stb A megnyitás az azonosító definiálása, egyben a csatorna leképzése egy az operációs rendszer számára i s i smert es zköznévre, f ájnévre. A cs atorna " megszüntethetõ" a lezárásával: az explicit close, fclose stb. r endszerhívásokkal A l egtöbb ope rációs r endszerben a n yitott csatornák lezáródnak a folyamat terminálódásával. A f olyamatok s zámára a n yitott cs atornák b yte-, va gy r ekord-források, -nyelõk. A csatornákba, a cs

atornákból byte-ok, rekordok mozgathatók, szekvenciálisan, vagy közvetlen eléréssel. A m ozgatott a datmennyiség f ügg a c satornához t artozó ( a l eképzett) f ájl, va gy eszköz szervezettségétõl (organisation), az elérés módját is befolyásolhatja a szervezettség. A leggyakoribb adatátvivõ rendszerhívások a read és a write rendszerhívások, de ismerünk más rendszerhívásokat i s: put, get, putchar stb. A l egtöbb ope rációs r endszer a c satornákhoz biztosít e gy fájl pozíció indikátor mechanizmust is , a mi a n yitott c satornán a z a dategység pozícióját j elzi. E nnek "mozgatása" ( seek) a s oros s zervezésû f ájlokon i s l ehetõvé t eszi a direkt elérést. A U nix o perációs r endszerek f ájlszervezése hallatlanul e gyszerû: i tt a f ájlok b ájtok sorozataként m egvalósítottak. N incs kül önösebb szervezettség, az elérés soros, i ll a p ozíció indikátor mo zgatása s egítségével d irekt le het. Az

I/O-val k apcsolatos r endszerhívások a következõk: Nyitó, záró redszerhívások: open(), pipe(), socket() descriptor köti ös sze a stream-et, ami l eképzõdik e gy fájlra, eszközre. close(), shutdown() Adatátvivõ redszerhívások: read(), write() transfer egy descriptor-ral azonosítottstream-bõl/be, egy user address space-beli címrõl/címre seek() pozíció indikátor beállítása System call-ok jegyzékekre: mkdir(), rmdir() és társai descriptor tartozik ezekhez is. System call-ok a file system kezeléshez: mknod() és társai descriptor tartozik ezekhez is. Végül egy ábrán bemutatjuk az adatstruktúrákat, melyek azt a helyzetet mutatják, amikor két Unix processz fájlokat nyitott (az ábrán a processz szemszögébõl indulunk ki). 8.1 ábra Adatstruktúrák, miután két processz megnyitott fájlokat 8.13 Az operációs rendszer látásmódja Az OS-ek egyik legfontosabb feladata az összes I/O eszköz • vezérlése, • könnyen

kezelhetõ interfész biztosítás ezekhez, • védelem, menedzsment biztosítása ezekhez. Az oprerációs rendszer "látásmódja" ezért meglehetõsen bonyolult. Tárgyalni fogjuk a kernel I/O-val foglalkozó részének szerkezetét, az eszközök kezelését, a f ájlrendszer kialakításának lehetõségeit. Az általános tárgyalás mellett a Unix implementációt kicsit részletezni is fogjuk 8.2 Alapelvek • Az I/O szoftver rétegekbe szervezett (Egy felsõbb réteg magasabb szintû absztrakciót biztosít, az alacsonyabb réteg pedig szolgáltatást a felsõ réteg számára). • Biztosítani kell az eszközfüggetlenséget (Eszköz változtatásnál ne kelljen módosítani a programot). • A hi bakezelés c élszerûen l egyen e losztva ( A h ibákat ke zeljük m inék közelebb a hardverhez. Tranziens hibákkal ne foglalkozzanak a felsõbb rétegek) • Szinkronitás - asszinkronitás ö sszeillesztése ( A f elhasználó p rocessze s zinkron

ír/olvas, míg maga a transzfer aszinkron, interrupt vezérelt). • Osztható ( sharable) é s de dikált e szközök i s ke zelhetõk l egyenek. A de ad-lock problémák kerülendõk! 8.21 Az I/O szoftverek szokásos rétegzõdése 8.2 ábra Az I/O szoftverek rétegzõdése Emlékezzünk az architekturákra! Az eszközök a buszra csatlakozó • controller/adapterbõl, és az ezekhez csatlakozó • fizikai eszközökbõl állnak. Ezekkel a device driver-eknek és b ennük a z interrupt handler-eknek va n köz vetlen kapcsolatuk. Az eszközmeghajtók (Device drivers) Az I/O alrendszer l agalsó r észét, a z e szköz dr ivereket egy r utinkészlet ( set of r outines) és táblázatok, puf ferek (tables, buf fers) a lkotják M iután a ke rnel részei: a r endszer címtartományához t artoznak ( Systen V irtual A ddress S pace). Legfontosabb f eladatuk a z adatmozgatás (mozgattatás) a központi memória (rendszerint a központi memóriában képzett buffer) é s

a kont roller (a kont roller bu ffere) k özött, t ovábbá pa rancskiadás a kont roller számára, hog y a z m ûködjön. T ovábbi f ontos f eladatuk ol yan e semények ke zelése, m elyeket egy-egy kontroller kelt, amivel jelzi, hogy kész van a kapott feladatával. Az e szköz dr iver-ek r utingyüjteményt k épeznek, jó l me ghatározott s ztruktúrával. Alapvetõen három részbõl állnak: 1. Autokonfigurációs é s i nicializáló r utinokból melyek e gyszer hí vódnak, a dr iver betöltésekor, i ndulásakor. E gy m onolitikus r endszernél e z a r endszerindításkort történik, di namikusan be töltõdõ dr iver-ek a l oad u tán. F eladatuk: tesztelik az eszközöket, vi zsgálják a zok j elenlétét, i nicializálják a z e szközöket ( pl. f elpörgetik stb.) Felülrõl, call jelleggel hívódnak 2. Második r utincsoportot a z I/O ké relmeket ki szolgáló r utinok a lkotják P l ol vass valamennyi bájtot és tedd a memóriába, olvass blokkot, vagy írj

blokkot stb. Felülrõl, call jelleggel hívódnak (Ezek jelentik a driver felsõ rétegét). 3. A ha rmadik csoportot a z i nterrupt ki szolgáló r utinok a lkotják, E zek " alulról" hívódnak, aszinkron módon. (Ezek az alsó réteghez tartoznak) Az O S I/O al rendszere t ehát feltétlenül t artalmaz d evice-driver kom ponenseket, m inden konkrét e szközfajtához s aját dr ivert. A r endszergazdáknak ke ll gondoskodnia a rról, ho gy minden konkr ét e szköznek m eglegyen a d rivere ( monolitikus r endszernél a r endszerképbe linkeltek legyenek a driverek), mindegyik inicializálódjon a normál használat elõtt. Viszonylag egyszerû a szerkezete a Unix I/O alrendszerének, ezért azt elemezzük tovább. 8.22 A UNIX kernel I/O struktúrája Emlékezzünk a k ernel f unkcionális s zerkezetére! E bbõl k iemelve a z I /O alrendszer a következõ ábrán látható. (83 ábra A Unix kernel I/O szerkezete ) Az eszközöket, természetesen, szokták

osztályozni, csoportosítani. Vannak ka rakterorientált, va gy m ás n éven s truktúrálatlan es zközök ( character o riented devices). Ilyenek a terminálok, soros vonalak, nyomtató portok, analóg/digital átalakítók stb Struktúrálatlannak m ondjuk e zeket, a mi t ulajdonképpen azt j elenti, hog y e zek a z e szközök képesek fogadni/adni egy struktúrálatlan karakter/bájt sorozatot. Ha jobban meggondoljuk, ezen a byte-stream-en lehet azért struktúráltság! Például eg y k arakteres terminálból(ba) j övõ ( menõ) k arakter-sorozat l ehet s orokra ( lines) tördelt. A karaktersorozatban a sorvég karakterek struktúrálnak Bevitel esetén a terminál egy sor p ufferbe g yüjtheti a k araktereket, és a s orvég l eütése u tán k üldheti a t eljes s ort a rendszerbe. Hiába van azonban ez a struktúráltság, az adatelérés itt csakis szekvenciális lehet, azaz át k ell j utni az el õzõ karaktereken ( bájtokon), hog y bi zonyos ka raktereket ( bájtokat)

elérjünk. Maga az adattovábbítás pedig változó hosszúságú sorokban (blokkokban) történhet, határesetben 1 ka rakter ( bájt) t ovábbítása i s l ehetséges. S or ( blokk) továbbítása e setén elképzelhetõ, hog y a t ovábbított s ort m ég e gy - az e szköz dr iver f ölötti - rutinkészlet ( line disciplines) is feldolgozza: ez vezérlõ karaktereket, karakterszekvenciákat kezelhet (pl. TAB karakter k iterjesztése h elyköz k arakterekre, D EL k arakter k ezelés s tb). E zt a k ezelést igényelhetjük, de el is kerülhetjük: ha igény van az eredeti, "raw" bájtfolyamra, megkaphatjuk azt, és majd feldolgozza azt a felhasználói programunk. Az eszközök másik nagy csoportját a blokkorientált (block oriented devices), vagy struktúrált eszközök ké pezik. T ipikus pé ldájuk a di szk e szközök M it j elent i tt a blokkorientáltság? Az ilyen eszközöknél blokknyi egységekben történik az adattovábbítás (azaz pl. 1 bájtért

is be kell hoz ni a t eljes bl okkot), bl okk e gységben t örténik a z a datrögzítés. E gy-egy bl okk feldolgozása "random" jellegû is lehet. Minden blokknak van címe (diszk eszköznél pl a fejcilinder-szektor c ímhármas a dhatja) E z a dja a bl okk s truktúrát, e zért m ondjuk e zeket struktúrált eszközöknek. Vessünk most egy pillantást a Unix I/O ábrára! Látjuk a "legalsó", hardver közeli komponenszeket, a két eszközosztály driver-eit. És mi v an felettük? M ilyen funkciókat bi ztosítanak a dr iverek f ölötti t églalapokhoz t artozó komponensek? Nézzük ezeket jobbról. 8.23 Az eszközök kezelése A ch aracter d evice dr ivers f eletti l ine di ciplines + cooked t ty komponensek a ka rakteres eszközökre ( tipikusan t erminálokra, s oros vo nalakra) s truktúrált e lérést bi ztosítanak. A line disciplines rutinkészlet • sorokba (line) rendezi az inputot, • feldolgozza a DEL és KILL karaktereket, • echózik

(hacsak a terminál nem teszi ezt), • TAB-ot kiterjeszti helyközökké, • jelzéseket (signals) generál (pl. terminál vonal hangup), • u.n "raw " módban szûri a karaktereket • stb. A c ooked t ty n yitó/záró, í ró/olvasó é s kont rolláló ( ioctl) r utinokból á ll, t ipikusan e zek hívhatók - persze, a diszpécseren át - a felhasználói programokból. A r aw t ty i nterface r utinkészlet s zintén a ka rakter or ientált e szközöket ( tipikusan s oros vonalak, t erminálok s tb.) ke zeli, c sak é ppen ne m s zûrik a z i nputot, m inden bá jtot, ka raktert eljuttatnak a felhasználói programhoz. Az ábrából nem feltétlenül jön a következtetés, de vegyük tudomásul, akár ugyanaz az eszköz váltakozva kezelhetõ a "durva" felületen át és a "finom" (cooked) felületen át. Tovább az áb rán l áthatjuk a "raw d isk i nterface" t églalapot a ch aracter device d river f elett. Ámbár a diszk

tipikusan blokk orientált eszköz, mégis lehetséges hozzá karakter driveren át hozzáférés. E lképzelhetjük ui a di szket i s bá jtok s truktúrálatlan f olyamának, és l ehet o lyan alkalmazás (felhasználói program), ami szekvenciálisan akarja olvasni/írni ezt a b ájtfolyamot (pl. e gy di szkmentõ/visszatöltõ s egédprogram, a mi t eles di szképet m ent) K étségtelen, ho gy mikor e gy d iszket b yte s team-ként ke zelünk, ugyanakkor n em ke zelhetjük bl okkorientált módon is . El i s é rkeztünk a z á brán a bl ock de vice dr ivers f ölötti kom ponensekhez. E zekrõl ké sõbb részletesebben fogunk szólni, most csak annyit, hogy a block buffer cache mechanizmus egy gyorsítótár a d iszkek és a m emória köz ött. L átjuk a zt i s, hogy a bl okkorientált e szközökre képezhetünk f ájlrendszert ( fájlrendszereket), é s a zon á t i s e lérhetjük a di szk ( blokkorientált eszköz) bl okkjait, e mellet - és ak ár f elváltva i s -

elérhetjül a bl okkokat ki mondottan a blokkcímeik szerint (cooked disk interface komponensen át). 8.3 Diszkek, blokk orientált eszközök Pillanatnyira félretéve a buffer cache komponenst, azt látjuk, hogy a felhasználói processzek a diszkek bl okkjaihoz ké t út on i s ho zzáférhetnek. E gyik út a fájlrendszer kezeléshez t artozó rendszerhívás c soport. Mikor a f elhasználói pr ocessz f ájlból va ló ol vasást ké r, a z va lójában "átalakul" egy diszk blokk behozatalra, diszk blokk igényre. A felhasználói processz a cooked disk i nterface-en ke resztül kö zvetlenebbül is ké rhet a dott c ímû di szk bl okkot. A di szk dr iverhez a ké relem f elülrõl m indenképp úg y jön, ho gy adott di szk a dott bl okkjára van igény. A logikai diszk (Logical Disk) fogalma Sokféle di szk va n, kül önbözõ ol vasófejszámmal, s áv ( track) s zámmal, szektor s zámmal, különbözõ méretekben, különbözõ gyártók, interfészek

vannak stb. Bonyolulttá válik a driver írók f eladat, ha m inden vá ltozathoz i lleszteniük ke ll a dr ivereket. E gyszerûbbek l esznek a driverek, ha a logikai diszk modellt használhatják. A kontroller/adpter-ek a driver szoftverrel e gyütt b iztosíthatnak e gy k onzisztens mo dellt, a logical disk modelt. E s zerint a logical disk blokkok s ora 0-tól n-ig s orszámozva. A l ogikai bl okkcímet a kontroller "fordítja le" fej-cilinder-szektor címhármasra, a d river szemszögébõl nézve a diszk blokkok sorának látható. Szinte minden fizikai diszk konvertálható egy ilyen ideális modellre. A g ondolat t ovább f olytatható. E gy fizikai di szk l ogikailag e gymásutáni bl okkjai összefoghatók, a diszk partíciók alakíthatók ki rajtuk. A diszk partíciók Egy fizikai di szk konve rtálható pa rtíciókra. E gy pa rtíció a di szk va lahanyadik bl okkjátók kezdõdõen va lahány egymásutáni bl okk. T udnunk ke ll, hol ke zdõdik a pa

rtíció, é s ho gy milyen hos szú. A partíció elsõ bl okkja a 0 l ogikai címet kaphatja, a k övetkezõ a 1 -es cí met s.ít Ezután a partíció egy blokkjára a relatív logikai címével hivatkozhatunk, a partíció nem más, min t e gy lo gikai d iszk, a mi 0 - n-ig s orszámozott bl okkokból á ll. E gy partíció egy logikai diszk-eszköz, kell legyen szimbolikus neve, kell, hogy tartozzon hozzá eszköz driver, ami kezelni tudja. A partíciók az OS-ben ugy kezelhetõk, mint a diszkek, A partíciókra: • file system-et szervezhetünk, • kijelölhetjük kilapozási/kisöprési (swap) területnek (lásd: memory management), • kijelölhetjük boot loader-nek, innen töltõdhet a rendszer, • kijelölhetjük alternate block area-nak ( hibás blokk he lyett i nnen a llokálhatunk blokkot). 8.4 ábra Partíciókra osztás Unixban Ahogy említettük, m inden pa rtíciónak ke ll l egyen szimbolikus ne ve é s k ell hoz zá t artozzon eszköz dr iver, a mi k

ezelni t udja. E gyes ope rációs r endeszerekben a z e szköz s zibolikus neveket m egszokhattuk, l ehetnek a zok a z a bc b etûi, konve ncionálisan a z A : é s a B : ne vû eszközök floppy diszkeket, a C:, D: s.ít szimbolikus nevek további diszkeket - akár logikai diszkeket, pa rtíciókat - jelölhetnek. de m i a he lyzet a U nixban? Itt ne m ismerünk ha sonló szimbilokus neveket! A U nixban a z e szközök s zimbolikus ne veit a z ún. s peciális f ájlok hor dozzák! A s peciális fájlok s zokásosan a / dev j egyzékben ( vagy e bbõl ki induló a ljegyzékekben) va nnak bejegyezve. E gy-egy s peciális f ájlra v aló h ivatkozáskor v alójában a h ozzá t artozó es zközre hivatkozunk. M aga a s peciális f ájl n em h osszú, cs ak 2 s zámot t artalmaz: a major device number-t, a mi az e szközt ve zérlõ kont rollert (adaptert), és a minor device number-t, a mi a konroller á ltal ve zérelt e szközt ( akár pa rtíciót) a zonosítja. A ké t a zonosító

s zám e gyütt nemcsak az eszközt azonosítja, hanem az eszköz kezeléséhez szükséges eszköz driver kernel komponenst is! A pa rtíciókra os ztáshoz a lacsony s zintû s zoftverek k ellenek, a melyeket a g yártóktól ke ll beszerezni! A di szk formattálása u tán l ehet partícionálni. A pa rtíciókra os ztáskor megmondjuk, hol kezdõdnek és milyen hosszúak a partíciók. A partícionálási információk az u.n partition table-ban vannak, ez p edig a fizikai di szk 0 sorszámú bl okkján t alálható E gy partícionált d iszk ú jra p artícionálható, d e a p artíció h atárok me gváltoztatása tö nkretehet file system-eket! Egyes operációs rendszerek (pl. Unix) megengedik a partíciók átlapolódását Egy Unix-os példa: Beginning Size Purpose --------------------------------------------------------/dev/dsk/0s0 0 16002 Root file system /dev/dsk/0s1 16002 16002 Swap area /dev/dsk/0s2 32004 25002 /usr file system /dev/dsk/0s3 57006 25002

First user file system /dev/dsk/0s4 82008 64566 Remainder Ökölszabályok a partíció méretek kiválasztása • A root file system-hez: a legfontosabb dolgok itt elférjenek. • A swap area-hoz: ökölszabály: 2 * a központi memória mérete. • A /usr-hez: elférjenek a közös dolgok, pl a man pages is! • kezdetben a /dev/dsk/0s3-at és /dev/dsk/0s/0s4-et nem is használjuk. Innen akár át is partícionálhatunk. Nota bene! Vannak partíció név konveciók a Unix-okban! Pl. a System V: /dev/dsk/c0d0s0 | | | | | partíció száma | | | device száma | driver-adapter/controller azonosító Foglaljunk össze Az eg yes special fájlokhoz va gy di szkazonosítókhoz t artoznak logikai diszkek, partíciók. Mind 0 - n-ig számozott blokkokat tartalmaznak. A partíciók mérete adott a bennük szereplõ blokkok számával. Sokszor m ár a ne vükbõl, de m indenképp a t artalmukból t udjuk ( a ke rnel a t artalmukból tudja), milyen

driver-adapter/controller-partíció-eszköz-rõl van szó. Láttuk: átlapolás lehetséges. Láttuk továbbá, hogy partícióváltoztatás csak korlátozottan lehetséges. A fizikai eszköz 0. sorszámú blokkjában van a partíció tábla A partíciók szerepe különbözõ lehet (file system, swap, boot, alternate). A block address a bl okkok c íme a pa rtícióban: a bl okkok s orszáma. 0 és n közötti ( block number = block address). 8.4 A fájlrendszerek A fájl: valamilyen szempontból összetartozó adatok névvel ellátva. Vannak névkonvenciók 8.41 Fájl struktúrák, fájl organizáció Három általános struktúra lehetséges: • A f ájl bá jtok s ora. Tulajdonképpen nincs struktúráltság, i ll a p struktúrálhatnak, ha akarnak. rocesszek • A fájl rekordok s ora. A rekordok l ehetnek állandó, vagy v áltozó hos szúságúak, ezen belül un. bl okkoltak A rekord struktúráltság a diszken, partíción, szalagon rögzített, nem a processzek

struktúrálnak, hanem az OS I/O alrendszere. • Indexelt szervezésû rekordokból áll a f ájl. A rekordok n em feltétlenül e gyforma hosszúságúak, v an be nnük e gy va gy t öbb kul csmezõ - rögzített p ozíción -, a mik segítségével gyors kikeresésük lehetséges. Unix-ban a z e lsõ, M S-DOS-ban az e lsõ é s a má sodik, V AX/VMS a latt min dhárom organizáció lehetséges. 8.42 A fájl elérések Általánosan kétféle lehet: • szekvenciális vagyis soros elérés, ami m indhárom o rganizációnál l ehetséges. E z tulajdonképpen a zt j elenti, hog y ha e gy byte-ot, va gy rekordot el a karunk é rni, a z elõtte álló byte-oket, rekordokat végig kell olvasni, vagy legalább is át kell lépni. • random, vagyis véletlenszerû elérés, ami azt jelenti, hogy egy byte vagy rekord elérése független a t öbbi b yte-tól, r ekordtól. A U nix e zt a seek rendszerhívással b iztosítja Más ope rációs r endszerek a f ix hos szúságu s

zekvenciálisan s zervezett r ekordokhoz, ill. az indexelt szervezésû rekordokhoz a közvetlen - random - elérést biztosítják 8.43 Fájl típusok Osztályozhatjuk a fájlokat a tartalmuk szerint is. Így lehetnek: • közönséges (regular) fájlok, amik tovább is osztályozhatók (text fájlok, binary fájlok stb) • jegyzékek (directories), amik bejegyzéseket tartalmaznak további fájlokról. • bizonyos OS-ekben FIFO jellegû fájlok, mailbox-ok, • a Unix-ban un. special fájlok, amik tulajdonképpen eszközöket azonosítanak • könyvtárak (libraries), melyek tagokat (members) tartalmaznak, amik maguk lehetnek text-ek, object modulok, végrehajtható programok stb. 8.44 Fájl attribútumok A fájloknak nemcsak ne vük és adataik vannak, hanem t ovábbi kapcsolódó i nformációik: pl . készítési dá tumuk, ut olsó m ódosítási va gy elérési d átumuk, t ulajdonosuk, csoporttulajdonosuk, vé delmi m aszkjuk, í rás/olvasási e

ngedélyük s tb. i s j ellemzik õke t Ezeket nevezhetjük az attribútumaiknak. 8.5 Fájlrendszer implementációk Blokk-struktúrált eszközökre (logikai diszkekre - partíciókra) szervezhetünk fájlrendszert. Tulajdonképpen három dolgot kell megoldani: • hogyan r ögzítsük, hog y e gy a dott fájlhoz m ely bl okkok és m ilyen sorrendben tartoznak, • hogyan t artsuk n yilván a l ogikai di szken a s zabad bl okkokat, hog yan ke ressünk ezekbõl, ha foglalni akarunk, vagyis hogyan menedzseljük a blokkokat a partíción, • végül, ho gyan rögzitsük a f ájl a ttributumokat, fõképpen m ilyen l egyen a j egyzék szerkezet. 8.51 Blokkhozzárendelés fájlokhoz 8.511 Folyamatos allokáció Egyszerû s éma, egymásutáni b lokkokat f oglalunk a f ájl s zámára, an nyit, am ennyit az el f og foglalni. A fájl tartalom keresése során csak a kezdõ blokk címét kell megadni pl a fájl nevét tartalmazó jegyzékben. Nyilvántartartják ilyenkor a hosszat,

vagyis az utolsó blokk címét is Gond: fájl allokáció s orán elegendõ ös szefüggõ t erületet kell t alálni, fregmentálódik a di szk (compaction kell, a gap-ek ne m ha sználhatók ki ), ne hézkes az append. Korszerû ope rációs rendszerekben nem használják már. 8.512 Láncolt lista allokáció Minden fájl "tartalma" a diszk blokkok láncolt listája. Így nem lesz fregmentáció A fájl nevét tartalmazó jegyzék bejegyzésébe az elsõ blokk mutatója, esetleg a fájl hossza bejegyzendõ, az elsõ bl okkban m egtalálható a köve tkezõ bl okk c íme ( mutatója) s .ít, a z ut olsó bl okkban a mutató NULL pointerként jelzi, hogy nincs tovább. 8.5 ábra Láncolt lista allokáció Gond: s oros ol vasás még e lfogadható, d e r andom k eresés n agyon l assú l ehet, m ert mindenképp végig kell menni a láncolt listán. Másrészt a blokkokból elvesznek egy kicsit a pointerek, márpedig mi szeretjük a kettõ hatványai méretû adat

blokkokat. Nem szokásos ez a módszer. 8.513 Láncolt lista allokáció index-táblával Emeljük ki a bl okk m utatókat e gy i ndextábla m ezõibe. A z i ndextábla a p artíció köt ött (megegyezés szerinti) helyén található tábla, annyi bejegyzéssel, ahány blokk van a partíción. Egy az e gy m egfeleltetés v an a t áblamezõk ( pointermezõk) é s a bl okkok köz ött: a z i -edik táblabejegyzés az i-edik blokkhoz tartozik. Ha egy fájl kezdõdik az i blokkon, folytatódik a j, k. s tb bl okkokon, a kkor: a j egyzékben a ne ve mellett s zerepeljen i , a z i poi ntermezõben szerepeljen j, a j. pointermezõben a k, stb Az indextábla egy bejegyzése (pl. az i mezõbe írt j érték) kettõs információt hordoz: maga az index ( i) azt mondja, hogy a z i -edik bl okk a f ájl bl okkja. A mezõ t artalaom ( a k) pe dig a zt mondja, hogy asoron következõ blokk a k-adik blokk. 8.6 ábra Indextábla Jó, h a az indextábla eg észérõl, v agy l egalább r

észletérõl in-core másolat van a m emóriában (gyorsítás). Tulajdonképpen az MS-DOS és végsõ soron a VAX/VMS is ezt a módszert használja. Gond: na gy bl okkszámú di szkek igen na gy i ndextáblát i gényelnek. J avítható e z, ha né hány blokkot c soportba ( un. cluster-ba) f oglalunk, és a cluster-ek l áncolt l istájával dol gozunk Ilyenkor persze romlik a diszk blokkok kihasználtsága, mivel nem valószínû, hogy a fájljaink mérete cluster-ek szorzata. 8.514 I-bögök, f-bögök alkalmazása A Unix fájlrendszer tervezésénél kialakított koncepció - késõbb részletezzük - szerint minden fájlhoz tartozik egy bög (node), egy adatstruktúra, ami a különbözõ fájlattribútumok mellett a fájl e gymásutáni bl okkjainak e lhelyezkedését i s r ögzíti. A U nix i-bögök a pa rtíció meghatározott h elyén ta lálhatók, e gyüttesen a lkotják a z i -listát. A j egyzék b ejegyzésben megadva az i -bög i ndexét ( az i indexet) m

egragadható az i -bög, ez zel az eg ész f ájl. M ás operációs rendszerekben kissé hasonló koncepcióval f-bögök segítségével kezelhetõk a fájlok blokkjai (HPFS és NTFS fájlrendszerek). 8.515 Jegyzék implementációk Emlékszünk, a je gyzék ma ga is e gy f ájl, a mi b ejegyzéseket ta rtalmaz má s f ájlokról. A bejegyzésekben a fájlok attribútumait tárolhatjuk. Miután a jegyzék is fájl, blokkok tartoznak hozzá is. Blokkjain belül vannak a bejegyzések, ezek l ehetnek á llandó, va gy v áltozó hos szúságúak, a z i mplementációtól f üggõen. A bejegyzésekben az a ttribútumok köz ött a l egfontosabb a f ájlnév. S okszor va n ke resés a né v alapján. A bejegyzések struktúrája befolyásolja a keresést Ez lehet: • lineáris, • nem rendezett bejegyzéseken, amik között nem foglalt bejegyzések is lehetnek (a törölt fájlokra); • rendezett, " hézagok" n élküli b ejegyzéseken, ahol i s g yorsabb k eresési

módszerek is megvalósíthatók; • hash t áblás: a s zokásos s zekvenciális b ejegyzések m ellett eg y h ash t áblát i s imlementálnak, ami a gyorsabb keresést segíti. Az esettanulmányok során különbözõ jegyzék imlementációkkal fogunk megismerkedni. 8.52 A szabad diszkterület menedzselési lehetõségei A f ájlrendszer i mplementációkat t ervezõk m ásik g ondja, ho gyan m enedzseljék a s zabad diszkterületet, hog yan t artsák n yilván a s zabad é s a f oglalt bl okkokat, hog yan i gényelhet rendszerhívás blokkokat, fájl törlésnél hogy adható vissza blokk a szabad blokkok mezejébe. Alapvetõen két megoldás szokásos. 8.521 Bit vagy mezõ térkép a szabad, ill foglalt blokkokról A pa rtíció m eghatározott ( konvencionális he lyén t alálható) t erülete a b it/mezõ-térkép. Bit/mezõ bejegyzések vannak a térképen, éppen annyi, ahány blokk található a partíción. Egy az eg y m egfeleltetés v an a b itek/mezõk és a d

iszk b lokkjai k özött: az i -edik bl okkhoz a z i edik bit/mezõ tartozik. A szabadság vagy foglaltság jelzésére a megfelelõ bit 0 vagy 1 értékû, a me gfelelõ me zõ 0 , v agy a foglaltságot je lzõ egész b ejegyzésû. A b it-térkép - gyorsítási célokból - in-core m emórai m ásolattal k ezelhetõ. N agy diszkeken e gy-egy b ithez/mezõhöz cluster rendelhetõ. Gyakorlatilag ezt a m ódszert használja a V AX/VMS, a H PFS, az NTFS és az MS-DOS FAT fájlrendszere is. Az M S-DOS u n. FAT ( File A llocation T able) t áblája az i ndex t ábla és a m ezõtérkép összevonása. Egy-egy bejegyzése három információelemet is hordozhat: • az i -edik b ejegyzés i i ndexe az t mutathatja, h ogy az i -edik bl okk ( cluster) a f ájl blokkja (már amennyiben a bejegyzés tartalom nem nulla); • a bejegyzés k értéke megmondja, hogy a soron következõ blokk a k-ik blokk (vagy ha az EOF jelzés, akkor itt a vége); • a nem nulla k érték egyben azt is

monja, hogy az i-edik blokk foglalt, speciális nem nulla k érték azt mondhatja, hogy ez egy hibás blokk. Egy 0 bejegyzés pedig éppen azt mondja, hogy az i-edik blokk szabad. 8.522 Láncolt lista a szabad blokkokról Fix h elyen l évõ blokk t artalmaz bejegyzéseket s zabad bl okkokról, annyiról, amennyit képes egy bl okk n yilvántartani, t ovábbá ug yanez a bl okk e gy köv etkezõ bl okk poi nterét i s tartalmazza, ami további szabadblokkokat tart nyilván s.ít Például 1K méretû blokkok és 16 bites diszk blokk szám esetén egy blokk 511 szabad blokkot és még egy blokk számát - ami a következo el em a l istán - nyilvántarthat. 20M -ás di szk e setén 40 bl okk elegendõ a z ös szes szabad blokk nyilvántartására. Gyakorlatilag ezt a módszert használja a Unix, azzal a k iegészítéssel, hogy m aguk a szabad blokkok használatosak a láncolt lista tárolására. 8.6 Unix fájlrendszer implementáció 8.61 Összefoglalás, alapok Foglaljuk össze,

mit tudtunk meg eddig: 1. A user lát eg y hierarchikus file system-et, be nne j egyzékeket, fájlokat ( fájl ne veket), attribútumokat stb. 2. Tudjuk, hogy va nnak eszközök, amiket speciális fájlok reprezentálnak és l áttuk ez ek kezelését. 3. A pr ocesszek l átnak a n yitott a datfolyamaikat a zonosító l eírókat ( descriptor), a mik valamilyen m ódon ös szekötõdnek a z i -bögökkel, e zen ke resztül f ájlnevekkel, e szköz azonsítókkal. 4. A kernel lát i-bögöket, eszközöket és buffer-eket Ezekbõl különösen érdekes a block devices buffer cache. Eléggé egységes interface-nek tûnik ez. Nem tudjuk azonban: • Mi az az i-bög ( inode)? Hogyan kötõdik a file system elemeihez, a fájlokhoz? • Mi a szerepe a buffer cache-nek? Továbbá: • A descriptor fogalom azt súgja: a UNIX-ban minden fájl. Ha ez igaz (Igaz!), akkor a file system-be vannak integrálva az eszközök, ugyanakkor a blokk orientált eszközökre van szervezve a file

system. Lehetséges ez? És hogyan? 8.62 A UNIX-ban minden fájl A UNIX-ban minden fájl és egy file systembe rendezett. Vannak • közönséges fájlok, • jegyzékek, • speciális fájlok (eszközöket takarnak), • fifo-k (pipe-ok) stb. A /dev jegyzék tartalma E jegyzékben a speciális fájlok vannak feljegyezve. Kapcsolatokat biztosítanak az eszközökhöz. Lehetnek aljegyzékek is: /dev/dsk/* Általában a nevük már mutatja, milyen eszközökrõl van szó. Tartalmuk (elég rövidek!): • major device number azonosítja a c ontroller/adapter-t, és e gyben a device drivert a kernelben. • minor device number azonosítja az eszközt, ami a controller/adapter-hez kapcsolódik (ne feledjük, egy controller/adapter több fizikai eszközt is kezelhet). Általános szabály: 1. Process-bõl hí vott system call, am inek descriptor-a speciális fájlhoz köt ödik, a megfelelõ eszközt kezeli. (Ez egyszerû és érthetõ a karakter orientált eszközökre)

2. Blokk orientált eszközre file system szervezhetõ A logical disk model itt is megvan. E szerint a logical disk blokkok sora 0-tól n-ig sorszámozva. Minden fizikai diszk konvertálható egy ilyen ideális modellre. Tartozik hozzá egy special fájl (pl.: /dev/dsk/0s0 ) Ez megoldja a driver-adpter/controller-device azonosítást. 8.63 Inode (Information node) (i-node) (i-bög) Az i-bög (i-node) eg y bejegyzés eg y információs táblában (i-list), fájlok fontos jellemzõit többek között az elhelyezkedésükre vonatkozó információkat tartalmaz. Az i-bög (i-node) leír egy fájlt. A UNIX rendszerben minden fájlnak egyedi i-böge van Az i-bög-tábla (i-list) i-bögök tömbje. Az i-bög-tábla a logikai diszken található, de a k ernel beolvassa ezt a táblát a memóriába (in-core i-node list) és azon manipulál. Az i index ehhez a táblához. (Néha az i-bög kifejezésen is ezt az indexet értjük, azonban ez nem zavaró, mert az i index az i-bög-táblában

(i-list-ben) az i-böghöz.) Az i indexek értéktartománya: i = 1 - valameddig; Történelmi okokból: • i = 1 : bad blocks • i = 2 : root i-node Ma már: a superblock-ba van bejegyezve a root i-node. Egy logikai diszk struktúrája a 8.7 ábrán látható 8.7 ábra Egy logikai diszk struktúrája Az i-bögök (i-node-k) tartalma (Az i -bög e gy részét a <sys/stat.h> -ban de finiált stat struktúra ír ja le A me zõk többségének ér telmezése a m egjegyzésekben m egtalálható. Ismeretlen t ípusok ( pl ino t, dev t) d efiníciói a <sys/types.h>-ban t alálhatók E gy f ájl i-bögét a stat() és az fstat() rendszerhívásokkal lehet lekérdezni.) • mode és védelmi maszk (a mode a fájl típusára jellmezó kód: szokásos fájl, jegyzék, FIFO fájl, speciális fájl-e az adott i-böghöz tartozó fájl; a védelmi maszk a különbözõ védelmi ta rtományokban v aló f ájlelérést r ögzíti. A mikor ls -l p aranccsal l istát

készítünk, az elsö mezõ -rwxr-x--- mintája ebbõl a bejegyzésbõl adódik). • linkek száma (vajon ez mi?) • a t ulajdonos ui d-ja ( Minden f ájlnak v an t ulajdonosa, e gy f elhasználó " belsõ" azonosítójával rögzítve. ez is megjelenik az ls -l parancsnál) • a tulajdonos gid-je (a fájl "csoport tulajdonosságát" rögzíti.) • a fájl mérete. • 10 db. direkt pointer (a fájl elsõ blokkjait mutatja) • 3 db. s ingle-double-triple i ndirekt poi nter ( nagyobb f ájlok bl okkjainak köz vetett tárolásához). • 3 db dátum/idõ (utolsó hozzáférés, utolsó módosítás, készítés dátuma/ideje) (Lásd: 8.8 ábra) 8.8 ábra A Unix i-bög szerkezete Figyelem! Special-fájlhoz tartozó i-bögök (hogy speciális fájl tartozik egy i-böghöz, az kiderül a mode mezõbõl), nem adatblokkokra mutatnak, hanem • az elsõ blokkcím tartalam az un. major-minor device numbers, • a maradék 12 mezõt nem

használják. 8.64 A jegyzékek tartalma A jegyzékek bejegyzései: i-index - név párok SVID-ben 16 byte hosszú rekeszek, ami max. 14 karakteres neveket enged meg (89 ábra) 8.9 ábra SVID jegyzék szerkezet BSD-ben un. chunk-ok, amik max255 karakteres neveket engednek meg (810 ábra) 8. 10 ábra BSD jegyzék szerkezet A j egyzék i mplementációból köve tkezik, hogy a j egyzékek be jegyzései ne m r endezettek, lehetnek bennük üres bejegyzések, bennük a keresés szokásosan szekvenciális. Minden név lefordítható i-bögre. Lásd: namei algoritmus algorithm namei /*osveny nevet inode-va alakit / /* Elemzi az "osveny" egy-egy komponenset, minden nevet az osvenybol inodeva konvertal, az inode segitsegevel megnezi, hogy az directory-e, vagy sem, ha nem az, visszater jelezve ezt a tenyt, ha az jegyzek, veszi inode-jat, es vegul visszater az input osveny inode-javal. Beirtam a "mount point" keresztezes algoritmusat eloszor nem fontos

nezni! */ input: osveny /*path name/ output: locked inode, vagy no inode hibajelzes { if(osveny a gyokerbol indul) working inode = root inode /*algorithm iget/; else working inode = current directory inode /*iget/; while( van az osvenyben tovabbi nev) { komponens = a kovetkezo nev az inputbol; ellenorizd, hogy a working inode jegyzek-e es a hozzáférés engedélyezett-e; if(working inode a gyoker es a komponens ".") continue; /* vissza while-ba / component search: olvasd a working inode-val azonositott directory-t! Keresd a "komponens"-t benne!; if(komponens megfelel egy bejegyzesnek a directory-ban) { vedd az inode-t directory bejegyzesbol; if(found inode of root and working inode is root and component name is ".") { /* crossing mount point / get mount table entry for working inode; release working inode /* iput /; working inode = mounted on inode; lock monted on inode; increment reference count of working inode; goto component search for

"."; } ereszd el a working inode-t /*alg. iput*/; working inode = az elobb vett inode /*iget/; } is amit else /* a komponens nem directory / return (no inode); } /* while vege / return( working inode); } Hogyan érhetõk el fájlok? (Mindegy, milyen fájl) • root-i-node-t veszed a superblockból, míg a többi fájlra: • jegyzékben kikeresed nevét, és veszed a hozzátartozá i-index-et. • az i-node-t kiemeled -- ezzel minden adata megvan A gyors keresés technikái • in-core -i-node-list mindíg a memóriában van! • memóriában van az aktuális jegyzék i-node-ja. (processzenként!) • memóriában van az aktuális jegyzék szülõ jegyzékének i-node-ja is.(processzenként!) Elõnyök ennél az implementációnál • áttekinthetõ, egyszerû, megérthetõ • kis méretû fájlok gyorsan elérhetõek a közvetlen adat blokk címzés miatt • nagyon nagy méretû fájlok is kezelhetõk • fontos információk az i-bögben vannak,

gyorsan megszerezhetõk • a fájl "mozgatás" (move) (mv) igen gyors lehet: csak a jegyzékekben kell változtatni, az i-bög marad! • könnyû megvalósítani a fájl "link"-et. 8.65 A fájl link (ln) Elõfordulhat, hogy már egy létezõ fájlt - aminek a neve be van jegyezve egy jegyzékbe, van iböge - szeretnénk egy másik névvel is elérni. Ezt a más nevet lehet, hogy nem is ugyanabban a j egyzékbe s zeretnénk bejegyeztetni. M ásolhatnánk a f ájlt, d e ebben az es etben az ú j fájl tartalma csak pillanatnyilag egyezik az eredetivel, akár a régit, akár az újat változtajuk, máris nem e gyeznek m eg a fájlok. T ovábbá, a m ásolással dupl ázzuk a he lyfoglalást M i a zt szeretnénk, ho gy a k ét ( vagy több) n év t ényleg ugyanarra a f ájlra hi vatkozzon, bá rmelyik névvel elérve a fájlt azt módosítjuk, a m ásik neveiken vi zsgálva i s l ássuk a változtatást. Ha úgy tetszik, az eddigi tisztán hierarchikus

fájlrendszert szeretnénk hálóssá tenni. Nos, a a Unix fájlrendszer implementáció erre lehetõséget ad a linkelés segítségével. Az un. hard link esetén egy új directory bejegyzés készül a m egfelelõ jegyzékben Az új dirbejegyzésben a z i i ndex e gy m ár m eglévõ f ájlhoz t artozó i-bögre m utat U gyanakkor a z i bögben növe kszik a l inkszámláló: a zt j elzi, h ogy ezen i -böggel a zonosított f ájlra t öbb direktory b ejegyzés is h ivatkozik. M inden má s a ttribútum v áltozatlan M arad a v édelmi maszk, a t ulajdonosi é s c soporttulajdonosi be jegyzés, ezért a z e lérési j ogok kor látozhatnak! (Még e gy m ásik kor lát i s l ehet: c sakis u gyanazon a f ile s ystemen l évõ fájlok ka pcsolhatók össze hard linkkel!) Fájl törlés esetén csak a linkek száma csökken, és egy directory bejegyzés tûnik el, ha a linkszám még nem 0, az i-bög továbbra is foglalt. (811 ábra) 8.11 ábra A fájl link A soft, va gy symbolic

link során ké szül e gy új fájlnév be jegyzés, új i -böggel. A z új i -bög hozáférési m aszkja új , a t ulajdonossági i nformációk i s új ak, a bl okkpointer me zõk ta rtalma azonban ne m a s zokásos. A poi nterek h elyett i tt a m ásik f ájl a bszolut ös vényneve v an feljegyezve, e nnek s zimbolikos l inknek s egítségével m egkereshetõ az " eredeti" f ájl. H a a z eredeti f ájlt tö rlik, a s zimbolikus lin k " sehova s e mu tat", h ibajelzést ka punk hi vatkozáskor. Szimbolikus linkkel különbözõ fájlrendszerek fájljai is összefûzhetõk. 8.66 A superblock tartalma A szuperblokk információkat tartalmaz az egész fájlrendszerrõl. Minden logikai diszknek az 1. blokkja Ma is 512 byte Némelyik Unix rendszer másolatokat is õriz a szuperblokkról. Többek között tartalmazza: • a fájlrendszer méretét, • a szabad blokkok számát, • a szabad blokkok listáját (pontosabban a lista elejét), • indexet a

következõ szabad blokkhoz a szabad blokkok listáján, • az i-bög-tábla (i-list) méretét, • a szabad i-bögök számát, • a szabad i-bögök listáját (pontosabban valamennyi szabad i-bögrõl egy listát), • indexet a következõ szabad i-böghöz a szabad i-bögök listáján, • lock mezõt a két szabad listához, • egy jelzõt (flag), ami jelzi, hogy történt-e módosítás a szuperblokkban. Figyelem! Az u.n mounted file system szuperblokkja benn van a memóriában is (in-core superblock), ez gyorsítást eredményez. A sync parancs s egítségével i dõnként ki írjuk a l emezre i s a szuperblokkot. Most megérthetjük, miért nem szabad csak úgy kikapcsolni a Unix-os gépeket: széteshet a f ájlrendszer, h a n incs k iírva az ak tuális s zuperblokk. ( Szétesett f ájlrendszert a superuser az fsck parancs segítségével rendbehozhat, de fájlok veszhetnek el!). 8.67 Algoritmusok fájlkészítéshez, törléshez 8.671 Fájlkészítéshez

a következõt kell tenni: (Lásd: ialloc,alloc algoritmusok, és a 8.12 ábra) 1. Allokálni k ell e gy i -bögöt ( ialloc), a zt ki ke ll t ölteni, a j egyzék be jegyzést ki ke ll tölteni. 2. Allokálni k ell a f ájl s zámára s zabad b lokkokat ( alloc), b e k ell j egyezni ez eket az i bögbe, és tölthetjük a blokkokat az adatokkal A 8.12 ábra (a) része azt mutatja, hogy a szabad i-bög listárol vesszük a következõ, a 48-as ibögöt, az index ezután a következõ szabad i-bögre mutat A ( b) á brán a s zuperblokk s zabad i -bög l istája kiinduláskor ür es ( index a 0 -ra m utat). E z persze n em j elenti f eltétlenül az t, h ogy egyáltalán n incs s zabad i -bög! L ássuk b e, hog y a szuperblokk s zabad i -bög lis tája n em je gyezheti f öl a z ös szes s zabad i -bögöt, c sak valamennyit ezekbõl. A ténylegesen szabad i-bögök a diszk i-listája vizsgálatával deríthetõk ki: szabadok azok, melyeknek a linkszámlálója 0. H a tehát a

szuperblokk szabad i-bög litája üres, a ke rnel ol vasva a diszket, a nnyi s zabad i -bögöt he lyez e l a s zuperblokk s zabad i -bög listáján, am ennyit cs ak t ud. E zt a k eresést az u n remembered inode-tól ke zdi, ne m pe dig elõlrõl. A f eltöltés u tán az i ndexet át helyezi, és a remembered inode értéknek f eljegyzi a legnagyobb ta lált i -bög s zámot. ( Kérdés, mié rt íg y c sinálja? V álasz: n em v eszt id õt a valószínûleg foglalt i-bögök vizsgálatával, amik az i-bög lista elején vannak.) algorithm ialloc input: /* inode-t allokal / file system output: locked inode { while(not done) { if(super block locked) { sleep(amig super block szabad nem lesz); continue /* vissza a while ciklushoz / } if(inode lista a super block-ban ures) { lock super block; vedd az un. "remembered inode"-t a szabad inode kereseshez; keress a diszken szabad inode-kat, amig a super block teli nem lesz, vagy amig nincs tobb szabad inode; unlock a super

block-ra; wake up signal (super block szabad lett); if(nem talalt szabad inode-t a diszken) return(no inode); allitsd be a "remembered inode"-t a kov. kereseshez; } /* vannak inode-k a super block inode listajan / vegy inode-t a super block inode listajarol. (Az iget algoritmus, ami lock-olja is az inode-t!) if(egyaltalan nincs szabad inode) /* !!! / { ird az inode-t a diszkre; ereszd el az inode-t (iput algoritmus) continue /* vissza while ciklusra / } /* van szabad inode / inicializald az inode-t; ird ki a diszkre az inode-t; csokkentsd a file system szabad inode szamlalojat; return(inode); }/* while ciklus vege / } algorithm ifree input: /* inode felszabaditas / file system inode szam output: semmi { noveld a file system szabad inode szamlalojat; if(super block locked) return; if(inode lista teli van) { if(inode kissebb, mint a "remembered inode") {remembered inode = input inode; tedd az inode-t a lista elejere; } } else /* nincs teli a lista, sot,

lehet, hogy ures / tedd az inode-t az inode listara, az index-szel jelolt helyre; return; } 8.12 ábra Szabad i-bög igénylés 8.13 ábra I-bögök számok elhelyezése az i-bög listára algorithm alloc /* file system block allokacio / input: file system number output: buffer az uj blokk szamara { while(super block locked) sleep(amig a super blokk szabad nem lesz); vegy egy blokkot a super blokk szabad listajarol; if(az utolso blokkot vetted) { lockold a super blockot; olvasd azt a blokkot, amit a szabad listarol eppen vettel (algorithm bread); masold az e blokkban levo blokk szamokat a super blokkba; ereszd el a blokk buffert (alg. brelse); unlock a super blokkra; wake up signal azoknak a processzeknek, akik a super blokk unlock-ra varnak; } vegy buffer-t annak a blokknak, amit elobb vettel a super blokk listajarol (algorithm getblk); nullazd a buffer tartalmat; csokkentsd a szabad blokkok szamlalojat; jelezd, hogy modositottad a super blokkot; return(buffer); } 8.14

ábra A szabad blokkok láncolt listája A fálj törlés lépései (miután a linkszámláló elérte a 0-t) 1. Az adatblokkjait szabad listára kell tenni a szuperblokkban 2. A fájl i-bögjét szabad listára kell tenni (ifree algoritmus) A fájltörlés lépései még egyszerûbbek. Az elsõ lépést késõbb tárgyaljuk, a második lépés az ibög szabad listára tétele A szabad lista közepére kerül az i-bög száma, ha a lista nincs tele Errõl ábrát nem is mutatok. Ha a szabad i-bög lista teli van (813 ábra), akkor nem is biztos, hogy ve sztegeti a z i dõt a f elszabadított i -bög m egjegyzésével ( 8.13 á bra ( c) ) A z á bra (a) része mutatja a k iindulási helyzetet, majd feltételezés szerint elõször a 4 99. számú i-bög (b), mjd rögtön utána a 601-es i-bög (c) felszabadul. A 499 -es a lista elejére kerül, mert kisebb, mint a "remembered inode". 8.672 Blokkok allokálása, felszabadítása A s zuperblokk e gy l istáján t artalmaz

va lamennyi s zabad bl okk be jegyzést, t ovábbá e gy láncolt listán nyilvántartja az összes szabad blokkot (8.14 ábra) Az ábra szerint szabadok a 100, 103, 106 é s 109 -es bl okkok, t ovábbá a zok, a mik a 109 -esen i s szabadnak va nnak nyilvánítva (112, .211), továbba 211-es blokkon szabadnak jelöltek, és így tovább Ha blokkokra van szükség, az alloc algoritmus szerint jár el a kernel. algorithm alloc /* file system block allokacio / input: file system number output: buffer az uj blokk szamara { while(super block locked) sleep(amig a szuperblokk szabad nem lesz); vegy egy blokkot a szuperblokk szabad listajarol; if(az utolso blokkot vetted) { lockold a szuperblokkot; olvasd azt a blokkot, amit a szabad listarol eppen vettel (algorithm bread); masold az e blokkban levo blokk szamokat a szuperblokkba; ereszd el a blokk buffert (alg. brelse); unlock a szuperblokkra; wake up signal azoknak a processzeknek, akik a szuperblokk unlock-ra varnak; } vegy buffer-t

annak a blokknak, amit elobb vettel a szuperkblock listajarol (algorithm getblk); nullazd a buffer tartalmat; csokkentsd a szabad blokkok szamlalojat; jelezd, hogy modositottad a szuperblokkot; return(buffer); } Elemezzük a 8.15 á brát! K iinduláskor a z ut olsó s zabad bl okkra m utat a z i ndex ( a 109 -re) Elõször felszabadítjuk a 499-es bl okkot: beíródik a l istába, i ndex eggyel j obbra m ozdul (b). Most blokk allokálás következik (c), az elõbb felszabadított 499-es blokk az áldozat, és elõállt az eredeti helyzet. Következzen megint blokk allokálás: ekkor a 109 bl okk listáját behozza a szuperblokkba, és a 109-es blokkot felajánlja, hogy használjuk, a szuperblokk indexét egészen jobbra tolja. Láttuk, e gyszerû a bl okk f elszabadítás, ha a s zuperblokk l ista ni ncs t eli (8.15 ( a) á bra) H a teli van, az újonnan felszabadított blokk link block lesz, ebbe beíródik a szuperblokk listája, ennek száma kerül a szuperblokk lista jobb

szélsõ elemébe, index ide mozdul (egyetlen eleme van a listának!). 8.15 ábra Blokk felszabadítás, blokkok igénylése 8.68 Fájlrendszer kialakítása, használatba vétele A superuser (rendszer adminisztrátor) a logikai diszkeken kialakíthat fájl rendszereket. # mkfs diskname size Megadhatja a fájlrendszer méretét, az i-bög-tábla (i-list) méretét stb. Szétesett fájlrendszert az fsck paranccsal rendbeszedhet. Ilyenkor elveszhetnek fájlok Mindezeket csak nem mount-olt eszközökre végezheti! A rendszer boot során egy root file system valamelyik logikai diszkrõl felépül. Lehetnek mé g más lo gikai diszkek, rajtuk l étrehozott fájlrendszerek, d e ezen a pont on azok nem ke zelhetõk. ( Pontosabban csak a c ooked di sk i nterface-en át , v agy karakterorientáltan kezelhetõk, a rajtuk lévõ fájlrendszer nem érhetõ el!) Ez az állapot (8.16 ábra): 8.16 ábra Fájlrendszerek mount elõtt és után Fájlrendszer mount-olása A szuperuser teheti csak.

#/etc/mount logical-disk üres-directory Hatása: az üres-directory ezután a logical-disk gyökér j egyzékének s zámít. A logical-disk, pontosabban az azon lévõ fájlrendszer "hozzáadódik" a hi erarchikus f ájlrendszerhez! A z új fájlrendszer "használhatóvá válik". Ezután pl. kiadható a következõ parancs: # cd /usr/lib A mount-olás ténye a /etc/mnttab (mount table)-ba bejegyzõdik! Ez az u.n mount point A mount point-okat bárki lekérdezheti az argumentum nélküli > mount paranccsal. A szuperuser dismount-olhat, ha nem foglalt a mount point. A mount tábla (/etc/mnttab) egy bejegyzése A tárgyaláshoz fogalmakat tisztázunk: Az eredeti fájlrendszer root f ile s ystem, o riginal f ile s ystem, mo unted o nf ile s ystem Ennek egy üres jegyzékére mountolhatunk. Ez elérhetõ kell legyen Mountolt eszköz mounted device, mounted file system A mountolt eszköz speciális fájlneve (a partíció spec. fájlneve ) Ez a f

ájlnév - és a h ozzá t artozó i -bög i ndex - az er edeti f ájlrendszerben a / dev j egyzékben van valahol. Ebbõl vehetõ a mountolt eszköz logikai száma logical device number = major + minor device number A mountolt eszköz gyökér jegyzéke, ennek i-böge root directory of mounted device (file system), i-node of it Ez az mkfs hívással elkészült szuperblokkba be van írva, ott van a fájlrendszeren. A mount jegyzék mounted on directory Ez az eredeti fájlrendszer egy üres jegyzéke. Úgy is hívjuk, hogy mount point. A mount jegyzék i-böge mounted on i-node Ez az eredeti fájlrendszer i-böge, az i-bög-táblába be van jegyezve. Emlékezzünk arra is, hogy az i-bög-tábla másolata az in-core memóriában van! A buffer cache Ezt a f ogalmat ké sõbb t árgyaljuk. M indenesetre a nnyit m ost e rrõl, hogy pointerekkel mutathatunk buf ferekre, a buf ferekben a dat bl okkok l ehetnek, t öbbek köz ött lehetnek eszközök superblokk másolatai is. Ezek után

egy bejegyzés a mount táblába a következõ elemeket tartalmazza: • a mountolt eszköz logikai száma (logical device number of mounted file system) • buffer poi nter, a mi a mountolt e szköz s zuperblokkjára m utat ( pointer t o a buf fer containing the file system super block) • a mountolt eszköz gyökér jegyzék i-bögére mutató pointer (pointer to the root inode of the mounted file system) • a m ount j egyzék i -bögére m utató poi nter ( pointer t o t he i node of t he mounted on directory) Fontos! A mount rendszerhívás nemcsak a /etc/mnttab-ot tölti, hanem a mount jegyzékbe (mounted on directory-ba) bejegyzi, hogy ez egy mount point. Lásd a 8.17 ábrát, a namei algoritmust, a mount algoritmust, unmount algoritmust! 8.17 ábra Adatstruktúrák mount után algorithm mount inputs: block special file neve "mount point" jegyzek neve opcio: (read only) output: semmi { if(not supert user) return(error); get inode for block special file

(algorithm namei); make legality checks; get inode for "mounted on" directory name (namei); if(not directory, or reference count > 1) { release inodes (algorithm iput); return(error); } find empty slot in mount table; invoke device driver open routine; get free buffer from buffer cache; read super block into free buffer; initialize super block fields; get inode of mounted device (iget), save into mount table; mark inode of "mounted on" directory as mount point; release special file inode /* iput /; unlock inode of mount point directory; } algorithm umount input: special file name of file system to be unmounted output: none { if(not super user) return(error); get inode of special file (namei); extract major,minor number of device being unmounted; get mount table entry, based on major,minor number for unmounting file system; release inode of special file (iput); remove shared text entries from region table for files belonging to file system; [Bach: Chapter

7.] update super block, inodes, flush buffers; if(files from file system still in use) return(error); get root inode of mounted file system from mount table; lock inode; release inode (algorithm iput)/*iget was in mount/; invoke close routine for special device; invalidate buffers in pool from unmounted file system; get inode of mount point from mount table; lock inode; clear flag marking it as mount point; release inode (iput) /* iget in mount /; free buffer used for super block; free mount table slot; } 8.69 A Unix buffer cache és kapcsolódó algoritmusok A Unix kernel funkcionális felépítését mutató ábrán felfedezhetjük a blokkorientált eszközök device driver-e és a file system között elhelyezkedõ buffer cache-t. Minimalizálni ak arják a t ényleges d iszk hozzáféréseket, ez ért a U nix k ernelben megvalósítottak eg y b elsõ p ufferezést: ez a b uffer cach e. ( Különböztessük m eg a C PU és a központi memória közötti hardveres cache

memóriától! Annak szerepe a CPU és a memória közötti ad atelérés gyorsítás, en nek s zerepe a diszk és a f elhasználói m emória k özötti adatmozgatás g yorsítása!) Más o perációs r endszerekben i s s zokásos ez a f ajta gyorsító t ár al kalmazás a cach e-elés, mivel a Unix buffer cache elég egszerû, ezen mutajuk be a buffer cache lényegét. 8.691 Általános leírás, alapfogalmak A buffer cache-ben vannak bufferek, ezek adatrészében diszk blokkok találhatók. A kernel a diszkes I/O es etén elõször a cach e-ben k eresi a b lokkokat. H a o tt m egtalálja a k eresett blokkot, nem is fordul a diszkhez, onnan szolgáltatja a blokk tartalmát, oda írja az output-ot. Miután va n e sély a rra, hogy e gy di szk bl okk megtalálható a buf fer c ache-ben is ( lokalitás elv!), teljesítmény növelés lehet az eredmény. A kernel a rendszer inicializálásakor allokál helyet a b uffer cache-nek, a memória méretétõl és teljesítmény

korlátoktól függõ nagyságút. Úgy mondhatjuk, a buffer pool-ban van x számú buffer. Valamely buffer két részbõl áll: • a buffer fejbõl (buffer header), és • a buf fer a dattároló r észébõl. E z é ppen a kkora, mint e gy di szk bl okk: t artalma e gy diszk blokk lehet. Valójában a buffer adattároló részében a tartalom egy az egy leképzése egy diszk blokknak. Jegyezzük meg, hogy valamely diszk blokk csakis egy buffferbe lehet leképezve! A leképzés persze idõleges, valamely buffer egyszer ezt, mászor azt a diszk blokkot tartalmazza. Nézzük ezek után a buffer szerkezetét, ebbõl a buffer fej az érdekes, hiszen az adatterület az egy blokknyi összefüggõ memóriaterület (8.18 ábra) 8.18 ábra A buffer fej szerkezete Az eszköz logikai szám és a blokkszám mezõk azonosítják, m elyik bl okk va n l eképezve a bufferbe. A s tátus m ezõ a buffer állapotát j elzi. Ebbõl a szabad - nem s zabad ál lapot l ehet ér dekes: a szabad

buffer természetesen tartalmazhat érvényes (valid) adatokat, de ha kell ez a b uffer, a kernel veheti, és valamilyen c élra, pl. másik blokk tartalom betöltésére használhatja A nem szabad (lock-olt, not free, busy) jelzésû buffert viszont a kernel más célra nem használhatja. Késõbb magyarázzuk a halasztott írású buffer állapotot és azt az állapotjelzést, hogy a buffer felszabadulására van legalább egy várakozó processz. A b uffer f ej tö bbi me zõje mu tatókat ( pointer) ta rtalmaz. É rthetõ a z a dattrerületre mu tató pointer szerepe: ez a kapcsolat a fej és a tényleges adatterület között. A további mutatók viszont magyarázandók. A buf fer pool -ban l évõ buf ferek f el va nnak, fel l ehetnek f ûzve k ét kétszeresen kapcsolt körkörös listára (doubly linked circular list). Ez a két lista: • a bufferek szabad listája; • a hash listák. A b uffer fejben k ét mu tatópár mu tatja a lis tákon a köve tkezõ é a a z e

lõzõ buf fert. N ézzük elõször a szabad listát (8.19 ábra) 8.19 ábra A bufferek szabad listája A boot-oláskor minden buffer ezen a listán van. Ne felejtsük, bár az ábra csak egy téglalppal jelöl egy-egy buffert, az valójában mindíg a buffer fejbõl és a hozzá tartozó adatterületbõl áll. Ha a rendszernek egy szabad bufferre van szülsége, két eset lehetséges: • akármelyik szabad buffer megfelel: ekkor a a szabad lista elejérõl veszi az elsõ buffert, és persze leveszi a szabad listáról; • azonosított szabad bufferre van szüksége: ekkor leveszi azt a lista közepérõl. Ha e gy buf fer f elszabadul ( persze e ttõl f üggetlenül m ég l ehet be nne " valid" a dat), a kkor általában a s zabad l ista végére illeszti a b uffert. N éha az elejére (látjuk m ajd m ikor), d e sohasem a köz epére. E z t ulajdonképpen e gy l egkevésbé a z ut óljára ha sznált ( least r ecently used) algoritmus: ha a rendszer egy buffert

allokált egy diszk blokkhoz, akkor nem használja ezt a buffert, amíg más bufferek nem voltak utóbb használva. Amikor a kernel egy diszk blokkot keres, elõször megnézi, hogy benn van-e a buffer mezõben (buffer pool). A keresés alapja az eszköz logikai szám és a blokkszám kombinációja Hogy a keresés gyors l egyen, hog y ne ke lljen a t eljes buffer m ezõt vé gignézni, a di szk b lokkokat tartalmazó buffereket úgynevezett hash listákon[1] (hash queues) tartja. A 8.20 á brán e gyszerûsítve be mutatjuk, ho gy n éhány di szk-blokk ho gyan h elyezkedik el a hash listákon: a hash függvény a blokkszám moduló 4. Egyszerûsítés, hogy az eszköz logikai számával nem foglakozunk. A blkno mod 4 függvény egy-egy hash lista fejét címezi, maga a blokk a f ejtõl i nduló ké tszeresen k apcsolt k örkörös l istán v an, az áb rán a k étszeres pointerezést a pont vonal c sak j elzi. A z á brán a blokkokba a bl okkszámot í rtuk be , ne m a buffer

va lamilyen a zonosítóját, de e z t alán é rthetõ: í gy e gyszerûbb az á brázolás. 820 á bra Bufferek a hash listákon: A s orokban a buf ferek s záma di namikusan vá ltozik. A ha sh f üggvény a zért i lyen egyszerû, hogy gyorsan ki számítható l egyen. Azt, hog y hány sor l egyen, a r endszeradminisztrátor beállíthatja. Leszögezhetjük: a buffer cache-ben lévõ diszk blokkok bufferei mindíg rajta vannak egy és csakis egy hash listán. Nem számít, hogy a listán hol, csakis az, hogy melyik listán Hozzáfûzzük: valamely hash soron lévõ buffer lehet a szabad listán is ugyanekkor, ha az állpota szabad! (A buffer fejek megfelelõ pointerei ezt lehetõvé teszik.) 8.692 Buffer allokálása a buffer mezõbõl Képzeljük el, hogy olvasni akarunk a diszkrõl egy blokkot. Ekkor adott a diszk logikai száma és a bl okkszám. ( Honnan a dódik? A z i -bögbõl pé ldául!) E kkor a ke rnel m egnézi, hog y a z blkno-nak megfelelõ buffer a buffer pool-ban

van-e: végignézi a megfelelõ hash listát. Ha ott megtalálja, megnézi még azt is, "valid"-e, és g yorsan v isszatér a b uffer cí mével. H a n incs a blokk a buf fer a pool -ban, a llokálni ke ll ne ki e gy szabad buf fert, é s e bbe be ke ll ol vasni a blokkot. Ha írni akarunk (ekkor is a diszk-szám és blokkszám a kiinduló adat), akkor allokálni kell egy buffert, abba már lehet írni,, és idõvel ez majd ki is kerül a diszkre. Fontos algiritmus tehát az ún. buffer allokáló algoritmus (getblk) Az algoritmus 5 tipikus forgatókönyvet (scenario) mutat. 1. A kernel megtalálja a blokkot a hash listán és ennek buffere szabad 2. Nem találja a blokkot a hash listáján, így allokál egy buffert a szabad listáról 3. Nem találja a blokkot a hash listáján és megkísérel allokálni neki egy buffert Talál is ilyet, d e a z "delayed write" - halasztott ír ás á llapotú. E kkor e lindítja e nnek a z aszinkron írását, és allokál

egy másik buffert. 4. Nem t alálja a bl okkot a ha sh l istáján, ugy anakkor a s zabad l ista üres E kkor blokkolódik (sleep), amíg egy buffer szabaddá nem válik. 5. A kernel megtalálja a blokkot a hash listáján, de ennek buffere pillanatnyilag foglalt Ekkor is blokkolódik (sleep), míg a buffer szabaddá nem válik. algorithm getblk input: file system number block number output: locked buffer that can now be used for block { while(buffer not found) { if(block in hash queue) { if(buffer busy) /* scenario 5 / { sleep(event buffer becomes free); continue; /* back to while loop / } mark buffer busy; /* scenario 1 / remove buffer from free list; return(buffer); } else /* block not on hash queue / { if(there are no buffers on free list) { /* scenario 4 / sleep(event any buffer becomes free); continue; /* back to while loop / } remove buffer from free list; if(buffer marked for delayed write) { /* scenario 3 / asyncronous write buffer to disk; mark it to be old;

continue; /* back to while loop / } /* scenario 2 - found a free buffer / remove buffer from old hash queue; put buffer onto new hash queue; return(buffer); } } } algorithm brelse input: locked buffer output: none { wakeup all procs: event waiting for any buffer to become free; wakeup all procs: event waiting for this buffer to become free; raise processor execution level to block interrupts; if(buffer contents valid and buffer not old) enqueue buffer at end of free list; else enqueue buffer at beginning of free list; lower processor execution level to allow interrupts; unlock buffer; } Mielõtt f olytatnánk a getblk elemzését, té rjünk k i r öviden a rra, mi tö rténhet a getblk u tán, amikor az visszad egy lock-olt buffer címet: • a kernel olvashat blokkot a diszkrõl az adott bufferba, • írhat adatot a bufferba, esetleg a bufferbõl a diszkre. Mindkét es etben k ell l ock-olni a buf fert, a míg vele f oglakozik. A buf fer ha sználata ut án viszont a

brelse algoritmussal " elereszti" a b uffert. A brelse algoritmusban l áthatjuk a megszakítás letiltást (block interrupt). Ennek oka, hogy nemcsak direkt hívása lehet a brelse- nek, ha nem a zt hí vhatja a z aszinkron I/O interrupt handler is. E l k ell k erülni a z e gymásba ágyazott brelese-ket. Nézzük m ost vé gig a getblk algoritmus e gyes f orgatókönyveit. A s oron következõ á brák a bufferek in dexeit n em mu tatják, h elyettük mindenütt a b ufferek ta rtalmát mu tató blokkszámokat írtuk be. A 8.21 á brán kinduláskor (a), 12 buf fer van a p ool-ban, ezekbõl 6 a szabad listán Szükség van a 4. számú blokkra (és az szabad is: 1 forgatókönyv) Az eredmény a (b) ábrán látható, a getblk visszatér a 4. blokkot tartalmazó buffer címével A 4 blokk természetesen rajta maradt a hash listáján, de most nem szabad (locked). A 2. forgatókönyv követhetõ nyomon a 822 ábrán Itt is az (a) ábrarész a kiindulás, és a 18 számú

blokkra volna szükségünk, ami nincs benn a buffer cache-ben. Ekkor a kernel leveszi a szabad listáról az elsõ buffert (ami most a 3. blokkot tartalmazza éppen), áthelyezi a 18 blokk hash l istájára: a 3 -as listára. U tána a getblk visszatér en nek a b uffernek a cí mével. Azeredményt a (b) ábrarészen láthatjuk. A 3. forgatókönyv nyomonkövethetõ a 823 ábrán Tételezzük fel, hogy a 3 és az 5 bl okk a szabad listán van, de mindkettõ állapota halasztott írású (dlayed write), azaz a tartalmuk még nem került ki a diszkre (a. ábrarész) Ugyanekkor a 18 blokkra szükségünk van, ami viszont nincs a h ash l istáján. Ekkor a getblk leveszi elõször a 3 bl okk, m ajd az 5 bl okk bufferét a szabad l istáról, é s e lindít r ájuk e gy aszinkron ki íratást a di szkre. Folytatásként a 4 bl okk bufferét l evéve a s zabad l istáról át helyezi az ú j hash l istára. Láthatjuk a z er edményt i s az ábrán. A 8.24 á bra a 4 forgatókönyvhöz

tartozik Tegyük fel, hogy az A processz számára keres a kernel buf fert, a kármelyik j ó l enne. A s zabad l ista vi szont ür es E kkor a z A pr ocessz blokkolódik, amíg szignált nem kap, ami jelzi, hogy szabadult fel buffer. A brelse kézbesítteti majd ki ezt a szignált, akár közvetlen hívással, akár a megszakítás kezelõbõl történõ hívással. Jegyezzük m eg, h ogy a "felébredt" A p rocessz ú jra k ell k eressen s zabad b uffert, n em allokálhat közvetlenül a szabad listáról, mert más processzek is várhatnak szabad bufferre, a versenyhelyzet kialakulhat. Végül az 5 f orgatókönyvet magyarázza a 825 ábra Tételezzük fel, A processznek kell a 99. bl okk Látható, van is buffere, de az foglalt (locked) Mit jelent az, hogy locked? Például egy másik, a B processz olvastat bele, és az olvasás befejésére vár: ezen blokkolt (ezen "alszik"). Ilyenkor tilos másik buffer keresni a blokknak, hiszen sohasem lehet 8.21 ábra 1

forgatókönyv 8.22 ábra 2 forgatókönyv 8.23 ábra A 3 forgatókönyv 8.24 ábra A 4 forgatókönyv 8.25 ábra Az 5 forgatókönyv 8.693 Írás, olvasás a diszkre, a diszkrõl Miután a buf fer a llokáló é s e leresztõ a lgoritmusokat ( getblk, br else) vé gignéztük, könn yen megérthetjük az í rás/olvasás ki szolgálását. A diszkrõl va ló ol vasás algoritmusa a bread algoritmus. algorithm bread /* block read / input: file system block number output: buffer containing data { get buffer for block; /* algorithm getblk / if(buffer data valid) /* valoban az a blokk van benne? */ return(buffer); initiate disk read; sleep (event disk read complete); return (buffer); } /* Ne feledjuk: a szinkron olvaso interrupt handler nem ad brelse-t! Azt a processz kell adja, amikor a buffer-bol atvette az adatokat! */ algorithm breada input: /* block read and read ahead / (1) file system block number for immediate read (2) file system block number for

asynchronous read output: buffer containing data for immediate read { if(first block not in cache) { get buffer for first block /* alg. getblk */; if(buffer data not valid) initiate disk read: } if (second block not in cache) { get buffer for second block) /* getblk /; if(buffer data valid) release buffer /* algorithm brelse /; else initiate disk read; } if(first block was originally in cache) { read first block /* algorithm bread /; return (buffer); } sleep(event first buffer contains valid data); return(buffer); } /* Gyorsitasi celok miatt elore olvas. Ebben az elso olvasas szinkron -nem ad brelse-t -, a masodik asszinkron: ad brelse-t! */ A bread algoritmusban l átható, hog y ha a ké rt bl okk be nn va n a buf fer c ache-ben, a buf fer azonosítójával a zonnal visszatér a z a lgoritmus. H a vi szont ni ncs a buffer c ache-ben, kezdeményezõdik a diszk olvasás. Sokszor e lõfordul - pl. mikor s zelvenciálisan ol vasunk e gy f ájlt -, ho gy egymásután t öbb

blokkot akarunk beolvasni. A teljesítmény növelhet breada algoritmus (read-ehead) Ebben az elsõ blokk olvasás - ha nincs a b ufferban - szinkron, a második blokk olvasás aszinkron. (Ne felejtsük, az aszinkron olvasás brelse-t ad.) Nézzük most a diszkre való írás agoritmusát! (bwrite). algorithm bwrite input: /* block write / buffer output: none { initiate disk write; if(I/O synchronous) { sleep(event I/O complete); release buffer /*algorithm brelse /; } else if (buffer marked for delayed write) mark buffer to put at head of free list; } A felhasználói processz szemszögébõl nézve write getblk buffert tölts bwrite szekvenciát kell végrehajtani. Ha a write szinkron, a hívó processz blokkolódik, amíg az I/O végre nem hajtódik. Ha a write aszinkron, a ke rnel e lindítja a z í rást, de ne m vá rja m eg annak t eljesítését. A buf fert vi szont csak ak kor er eszti el , amikor az I/O befejezõdött. Külön eset az ún halasztott írás (delayed

write). K ülönböztessük m eg az aszinkron írástól! A h alasztott í rás es etén a b uffer állapot (state) bejegyzést kap errõl a tényrõl, és utána a brelse-vel "eleresztõdik", a tényleges kiíratás nem ke zdõdik m eg. A ke rnel c sak akkor f ogja a buf fert t énylegesen ki írni, ha a 3 forgatókönyv szerint a buffert reallokálni kellene másik blokk számára. Ez elõnyös lesz olyan esetekben, am ikor a b uffer t artalmát eg ymásután t öbbször v áltoztatják: n incs köz ben idõigényes d iszkre v aló k iíratás. A zaz h alasztott í rás es etén a t ényleges k iíratás ad díg halasztódik, amíg csak lehet. 8.694 A buffer cache elõnyei, hátrányai A bufferezésnek sok elõnye van, sajnos, vannak hátrányai is. • Egyik l egfontosabb elõny, h ogy a b ufferezés e gységes k ezelést t esz l ehetõvé. N em számít, hogy a bl okk i -bögöt, s zuper bl okkot va gy adat bl okkot t artalmaz, e gyetlen felület van a diszkekhez,

és ez egyszerûsíthet sokmindent. • Másik e lõny, hog y ni ncs elrendezés korlátozás (alignment r estrictio). A ha rdver megvalósítások s okszor m ás e lrendezést kí vánnak a di szken é s a m emóriában: i lyen lehet pl . 2 bá jtos va gy 4 bá jtos ha tárra i llesztés A z e lrendezést a ke rnel be lsõleg elintézi, n em jelent t ehát ma jd g ondot a z á tvitel ( portability) más h ardver implementációkra. • Nagy el õny a t ényleges d iszk-átvitelek r edukálása, ez zel a t ényleges t eljesítmény növelése. A p rocesszek olvasáskor s okszor m egtalálják a bl okkokat a bu ffer cacheben, e lkerülhetõ í gy t ényleges é s l assú di szk á tvitelek A halasztott ír ás le hetõség elõnye könn yen be látható. P ersze, j ól m eg ke ll s zabni a buf fer m ezõ ( buffer pool ) méretét! • Elõnynek m ondható a z i s, hogy az e gységes i nterfész s egít e lkerülni a hol tpont helyzeteket. És most nézzük a hátrányokat is. •

A h alasztott í rás konc epció há tránya, ho gy m eghibásodás e setén i nkonzisztenciát okozhat. Elõfordulhat adatvesztés: a felhasználói processzek flush rendszerhívása sem jelenti f eltétlenül a zt, h ogy a di szkre i s ki kerülnek a z a datok, l ehet, hog y c sak a felhasználói c ímtartományból a ke rnel c ímtartományához t artozó buf ferbe ke rülnek, ekkor egy rendszerösszeomlás adatvesztést fog okozni. • A buf ferezés s orán m indíg m egtörténik a felhasználói c ímtartományból a ke rnel címtartományba m ásolás, onna n a di szkre va ló í rás, va gy f ordítva ugyanez az olvasásnál. N agy adatforgalom es etén az ex tra m ásolás cs ökkenti a t eljesítményt, akkor j obb l enne köz vetlenül a f elhasználói c ímekre í rni. M egbontaná a zonban a z egységes f elületet, h a e zt m eg s zeretnénk o ldani. K is ad atforgalom es etén v iszont nagyon va lószínû, hog y a buf ferezés gyorsít. ( És ki t udja a zt

de finiálni, hog y m i a nagy és mi a kicsi adatforgalom?) 9. Rendszermenedzseri feladatok Ezzel a t émakörrel - részletesebben - két vá lasztható t árgyuk i s f oglalkozik m ajd. E gyik a z IT15 jelû Operációs rendszerek menedzsere (VI7) 31v t antárgy, másik az IT16 Biztonság és védelem a s zámítástechnikában ( VI8) 31v t antárgy. M iután e zek vá laszthatók, ne m bi ztos, hogy m inden i nformatikus ha llgató f elveszi a zokat. A l egalapvetõbb r endszermenedzseri feladatokat azonban illik minden informatikusnak ismerni, ezért leröviditve összefoglaljuk és megimerjük azokat e t árgyban is. Az érintett rendszermenedzseri feladatokat Unix operációs rendszerbeli feladatakon mutatjuk be, azon gyakoroltatjuk. 9.1 Összefoglalás A rendszermenedzser legfontosabb feladatai: • a r endszer i nstallálása, h angolása ( setting u p), m éretre al akítása, k arbantartása (updating), e rõforrás ke zelés, kont rol: új abb e szközök, pe

rifériák f elvétele, l evétele (connecting devices) [ezt most nem részletezzük]. • A rendszer indítása, leállítása (startup-shutdown) [röviden foglalkozunk vele]. • Konfigurációs f ájlok ka rbantartása, da emonok i ndítása, a dott i dõben f utttandó parancsok indítása (crontab), kommunikációs beállítások stb. • A f elhasználók m enedzselése ( felvétel, t örlés, j ogosultságok ki osztása s tb.) [ röviden foglalkozunk vele, majd a NIS rendszer koncepcióval is]. • A f ájlrendszer m entése, v isszaállítása ( backup, r estore, r ecovery) [ röviden foglalkozunk vele]. • A fájlrendszer integritás biztosítása (fsck) [röviden foglalkozunk vele], szabad terület (free space) karbantartás. • Naplózások, események figyelése (monitoring), statisztikák készítése, számlázás. Szinte m indegyik t evékenység ka pcsolatos a bi ztonsággal. N agy rendszereknél a rendszermenedzser m ellett kül ön bi ztonsági m

enedzsert ( security m anager) foglalkoztatnak. A f ontossága mia tt a k ockázati é s b iztonsági kérdéseket i s összefoglaljuk a rendszermenedzseri feladatok érintése elõtt. 9.2 Kockázatok és védelem Általános szabály: a biztonságossá tételnek ára van. Ezért figyelembe kell venni • a gép (rendszer) fontosságát, • a biztonsági munkák mennyiségét, • a biztonsági komponensek hatását a felhasználókra. Egyensúlyt k ell ke resni, hog y a bi ztonsági komponensek ne l egyenek bos szantóak, hátráltatóak. A fenyegetések osztályai I. Fizikai fenyegetések • Természeti csapások (tûz, földrengés stb.) • Jogosulatlan hoz záférések l aboratóriumokhoz, gé pekhez, be rendezésekhez ( betörés, kulcsmásolat készítés, beléptetõ rendszer kijátszása stb.) II. Logikai fegyegetések • Felhasználók felelõtlensége, tévedése (pl. meggondolatlan törlések: del *.*). • Jogosult szolgáltatás megtagadás

valamilyen probléma miatt. (Pl garantált válaszidõt meghalad a s zolgáltatás, és en nek j ogi, gazdasági k övetkezményei v annak, eszköztönkremenetel miatt adatvesztés és biztonsági másolatok nincsenek stb.) • Jogosulatlan hoz záférések e rõforrásokhoz, i nformációkhoz, s zolgáltatásokhoz. E zen belül érdemes külön kezelni a következõ osztályokat: • * felhasználók kí váncsisága, j ogosultsági határainak ki próbálása, a bi ztonsági háló lyukainak keresésére tett próbálkozások; • * be hatolás ká rokozási s zándékkal, a bi ztonsági há ló l yukainak felhasználása kártevõ m ódon: c opyright s értés, i nformáció e ltulajdonítás, ké mkedés, személyiségi j ogok s értése, " gépi i dõ" l opás, i nformációk t örlése, ba ktériumvírus-worms programok készítése stb. A f elhasználók t évedései el len a lig s zoktak k özpontilag s zervezetten vé dekezni, bá r a rendszeres, k özpontilag

szervezett m entések i tt i s s egíthetnek (ezek c élja az onban m ás). Vegye m indenki f igyelembe a r égi köz mondást: D ont put a ll your e ggs i n one ba sket! Célszerû biztonsági másolatokat készíteni és azokat "más " helyen õrizni! A következõkben a védelemmel kapcsolatos koncepciókat, alapfogalmakat tekintjük át. 9.21 A hivatkozás figyelés (Reference Monitor) koncepció A Reference Monitor koncepció a 60-as években kidolgozott koncepció, a többbfelhasználós számítógéprendszerek " hozzáféréses" t ípusú vé delmi pr oblémáinak m egoldására. A koncepció lényege az alábbi (9.1) ábrán foglalható össze 9.1 ábra A hivatkozás figyelés koncepció Subjects: ( szubjektumok): a ktív e ntitások, m elyek obj ektumokat t udnak "elérni". Ide tartoznak a felhasználók, a processzek, task-ok, job-ok. Objects (objektumok): pa sszív e ntitások, e rõforrások, s zolgáltatások. Ilyenek pl a

számítógépek, CPU-k, a memóriák, eszközök, fájlok, programok stb. Reference Monitor Data Base: d efiniált b iztonsági k övetelmények, a zaz me ly szubjektumok, kinek az érdekében, mely objektumokhoz, hogyan férhetnek hozzá. Security Audit (biztonsági figyelõ, w atchdog): a h ozzáférési k ísérletek (sikertelen/sikeres) naplózása, riasztás. Reference Monitor: a rendszer központi eleme. Bármilyen szubjektum, ha egy objektumhoz akar f érni, cs akis a R eference M onitor-on keresztül f érhet hoz zá. E z a zonosítja a szubjektumot (authentication), és leellenõrzi a Reference Monitor Data Base-n át a hozzáférés jogosultságot (authorisation). A hi vatkozás f igyelés k oncepció - egyetlen köz ös a datbázissal - sohasem va lósult m eg, de részei szinte minden rendszerben megtalálhatók. 9.22 További alapfogalmak Az azonosítás (authentication) fogalma A szubjektumok (a felhasználók és a felhasználók nevében eljáró processzek)

azonosítandók. Az azonosítás célja m egmondani, hogy a szubjektum mely védelmi tartományba (protection domain) tartozik. A f elhasználók a zonosítására va nnak külsõ és belsõ azonosítási technikák. Pl kül sõ azonosítási lehetõség mágneskártyás vagy vonalkódos engedélyeztetõ rendszer, gépet, szobát lezáró kul cs s tb. B elsõ a zonosítási t echnika pl a jelszós (password) vé delem, va gy né hány, csakis a felhasználó által ismert információ (pl. gyermekkori betegség neve stb) lekérdezése egy rövid dialógusban. Jellegzetes problémakör a j elszós azonosítás problémaköre, ez ug yan egy kiváló azonosítási lehetõség, de egyben egy lehetséges lyuk a biztonsági hálón. A hozzáférési jogosultságok (authorisation) fogalomköre Objektumok (erõforrások) elérése, ezekhez való hozzáférések privilégiumainak gyüjtõneve az authorisation. Példákon keresztül talán könnyebb megérteni Fájlokat (ezek objektumok) lehet

• olvasni r (read), • írni, újraírni w, rw (write, rewrite), lehet tartalmukhoz • hozzáfûzni a (append), lehet azokat • törölni d (delete), • végrehajtani x (exec). Számítógépeken, CPU-n lehet alkalmazásokat, rendszerprogramokat futtatni. Eszközökhöz is lehetnek hozzáférések, nagyrészt hasonlóak a fájlokhoz való hozzáférésekhez (r, w, rw, a, d). Üzenetsorokba lehet üzeneteket elhelyezni, onnan kiolvasni, lehet üzenetsort megszüntetni: ezek is jelezhetõk a w, r, d betûkkel. A védelmi tartomány (Protection Domain) Ax Oxford számítástechnikai értelmezõ szótár [Novotrade, 1988] - további magyarázatokkal az al ábbi d efiníciót adja: a v édelmi t artomány a v édett er õforrások h ozzáférési privilégiumainak összesége. Meglehetõsen absztrakt fogalom, ezért körüljárjuk. MS-DOS védelmi tartomány Nézzünk egy egészen konkrét példát: az MS-DOS command.com programja fut Különösebb autentikáció ne m

vol t, az M S-DOS e lindításával " beléptünk" a v édelmi ta rtományába. A command.com védelmi ta rtománya a le gtöbb fájlhoz tö rlési jo got a d d e a z IOSYS és az MSDOS.SYS fájlokhoz ebben a t artományban ni ncs t örlési j og A del paranccsal ( ez r észe a command.com-nak) nem lehet ezeket törölni Ugyanebben a tartományban a PRN eszközhöz sincs delete jog, írás jog viszont van hozzá! Unix példa a védelmi tartományokra Az uid és gid - melyek meghatározzák (authentication) ki vagy te és mely csoportba tartozol védelmi tartományokat is meghatároznak. Tulajdonképpen két tartományt • az uid-dal azonosított tartományt (veled azonosított védelmi tartományt), • a gid-del azonosított tartományt (a csoportod védelmi tartománya). Hány védelmi tartomány van a Unix-ban? Elég sok, ahogy ez az eddigiekbõl következik: • ahány felhasználói számlaszám létezik, • ahány csoport létezik, legalább annyi védelmi

tartomány van. Lehetségesek az uid/gid párokkal meghatározott védelmi tartományokon kívûli tartományok? Igen! A védelmi tartomány általánosabb fogalom, ha valahogy azonosítható és a hozzáférési jogok va lahogy rögzíthetõk, a kkor m áris va n vé delmi t artomány. P l a zeus dialup jelszava külön védelmi tartományt biztosít a zeus CPU-i elérése számára. Egy CPU felhasználói módkernel mód váltása is védelmi tartomány váltás: itt az authentikáció a szabályozott módváltás (trap f ogalom), az au thorizáció p edig a s zélesebb cí mtartomány el érési, a n agyobb instrukciókészlet használati jogosultság biztosítás. A pr ocesszek e gy vagy t öbb vé delmi t artományba futnak. A z authentikáció célja ép pen megmondani, mely védelmi tartomány(ok)ban fut egy folyamat. Az e rõforrások ( objektumok)egy vagy t öbb v édelmi t artományhoz t artoznak. A vé delmi tartomány megmondja a hozzáférési jogokat. 9.23

Hozzáférési jogok listája, jogosultsági listák A vé delmi há lók l eírásának ké t, kül önbözõ s zervezettségû formája l ehetséges. A z e gyik a hozzáférési jogok listája (Access C ontrol List, A CL), r övidebben hozzáférési lista (Access List), a másik a jogosultsági listák (Capatibility List, CL) formája. Analógiát ke resve a j ogosultság ú gy t ekinthetõ, m int e gy m eghívó e gy bá lra, a m eghívót bemutatva beléphetünk, míg a h ozzáférési lista egy bál meghívottainak névsora, a belépéskor azt ellenõrzik, rajta vagyunk-e a listán. Hozzáférési lista A forma lényege, hogy maga az objektum - hozzákapcsolt attribútumokkal - tárolja védelmi taromány azonosítási lehetõséget és az objektumhoz való hozzáférési jogokat. Ha úgy tetszik, a l ista " sorokból" á ll. S orai a z obj ektumok, ho zzá f elsorolva, m ely vé delmi t artományban milyen hozzáférési jogok vannak: CPU1: (PD1: x, PD2: x, . PDi:

x, . PDn: x) PD2: rw, . PDi: r, PDn: r) . mem1: (PD1:rwx) . file1: (PD1:rwx, PD2: rw) file2: (PD1: r, . A hozzáférések ellenõrzéséhez a folyamatokról csak annyit kell tudni, hogy az melyik védelmi tartományban fut. Ennek a formának elõnye, hogy az ACL viszonylag rövid lista, többnyire könnyen kezelhetõ. Hátránya, hogy a lista sorok változó hosszúságúak lehetnek, fájl rendszerre nagyon hosszúak és itt már nehezen kezelhetõek. ACL jellegû a • Unix (fájl) védelmi rendszere (késõbb látjuk, hogy egyszerûsített a forma), • a Windows NT védelmi hálója, • a VAX/VMS fájl- és eszköz védelmi rendszere (ez is egyszerûsített), • a bitmintákkal védett valós címzésû memória partíciókkal dolgozó memória menedzsment memóriavédelme (IBM 360) stb. A jogosultsági lista Ez a forma - meglehetõsen régi - egyre nagyobb jelentõségû: osztott rendszerekben, hálózatokban lehetetlen a

védelmi tartományokat (akár a szegregációval egyszerûsített ACL-eket is) tárolni. Az Oxford szótár definíciója: a jogosultsági lista az engedélyezett mûveletek jegyzéke. A forma: sorok az egyes védelmi tartományokhoz, bennük felsorolva az objektumok és a hozzáférési jogok: PD1: (CPU1: x, mem1: rwx, file1: rwx, file2: r, . ) PD2: (CPU1: x, file1: r, file2: rw, .) . PDi: (CPU1: x, file2: r, .) . PDn: (CPU1: x, file2: r, .) A jogosultság (capatibility) fogalmat kell megértenünk, ez azt jelenti, hogy egy processz mit csinálhat az objektummal. Ha nincs jogosultsága, akkor nem érheti el. A processzhez kapcsolódnak a jogosultságok, a processznek van jogosultsági listája (hiszen a processz egy vagy több védelmi tartományban fut, azok jogosultságai vannak a processzhez rendelve). Tehát nem az objektumok attribútumai tárolják a hozzáférési kódokat, hanem a processzekhez rendelik a jogosultságokat. Tipikus példa erre a

felhasználói mód-kernel mód váltás: a processzhez más váltással. Másik jogosultság tipikus (capatibility) példa a valós kapcsolódik címzésû, a memória partíciókkal gazdálkodó rendszerek esetén a partíció határokat regiszterekben tároló regiszterértékek processzhez a memória procesz kapcsolódik védelmi rendszer: kontextusához a miután tartoznak, "jogosultság" a a ellenõrzési információ. Egy processz átadhatja a "jogosultságát" egy másik processznek, ekkor a másik processznek is lesz jogosultsága a objektumhoz, a jogosultság felíródik a processz jogosultsági listájára. (rwx, d, Természetesen a) kívül ekkor további a szokásos jogosultságokon "jogosultságokkal" (jogosultság átadási jog: grant, jogosultság átvételi jog: take) is kell foglakozni, ezek explicite vagy implicite benne kell legyenek a rendszerben. A Unix egyszerûsített

fájl-hozzáférési modellje A Unix-ban minden fájl, mondhatjuk, a fájlvédelemmel általánosan megoldanak egy sor védelmi problémát. Az eszközök a speciális fájljaik segítségével kezelhetõk, a csövek - bármilyen is az implementációjuk - szintén a fájlrendszeren keresztül védettek. A Unixban a szubjektumok mindíg processzek. Minden fájlhoz az ibögben (i-node), egyébb objektumokhoz, pl. üzenetsorokhoz (msg), szemaforokhoz (semaphores) stb. valahol tárolják • az objektum tulajdonosát (uid), • a csoporttulajdonost (gid), és imlpicite ezzel a többieket (others), akiknek nincs tulajdonosi relációja az objektumhoz. Ezzel tulajdonképpen a védelmi tartományokat szegregálják. Az így szegregált védelmi tartományokhoz tartozó hozzáférési jogokat (rwx) is az objektumhoz rendelve tárolják: a fájloknál az ibögben, egyébb objektumoknál valahol. Ez a hozzáférési lista tehát nem hosszú,

könnyen elfér az ibögben. Hátránya viszont, hogy nem olyan flexibilis, mint a teljes ACL rendszer, egy fájlnál nem lehet különbözõ csoportokat - ezzel védelmi tartományokat - azonosítani, egy fájl csakis egy csoporthoz tartozhat. A lényeg tulajdonképpen az, hogy a védelmi tartományok tulajdonossági kategóriákon keresztül azonosítottak: file1: PD1 PD2 PD3 owner Group-ownership no-ownership uid Gid others a rwx Ebbõl az r-- látható, hogy --egy fájl három védelmi tartományba tartozik. Mint láthajuk, a hozzáféréseknek csak három kategóriája van: rwx. A szokásos fájloknál, eszközöknél, csöveknél nem nehéz a hozzáférések értelmezése: • r read: olvasható a fájl, de nem változtatható, nem is törölhetõ, nem futtatható, még akkor sem, ha ez különben futtatható program, vagy burok program. • w write: engedély a változtatásra. beleírhatsz akár az elejétõl kezdve törölheted.

csak w (ezzel Jegyezzük meg, engedélyünk átírhatod, hogy van egy nem hozzáfûzhetsz, szövegfájl, tölthetõ amire be egy szövegszerkesztõbe: hiányzik az r jog, de hozzáfûzhetünk adatokat. • x execute: engedély a futtatásra. Bináris fájloknál ez elegendõ is a futtatásra. Burokprogramoknál a futtatáshoz szükséges az r jog is, mert a burok olvasni is akarja a fájlt. A jegyzékekre vonatkozó rwx jogosultságok értelmezése: • r olvashatja a jegyzéket, ezzel listázhatja a tartalmát, pl. ls paranccsal. használathoz) Fájlnév szükséges behelyettesítéshez jog. A jegyzékbe (dzsóker bejegyzett fájlokhoz azonban a puszta r jog nem enged hozzáférni. • w írhatja a jegyzéket, azaz "betehet és kivehet" fájlokat e jegyzékbe, jegyzékbõl. Cserélhet a fájlneveket • x itt nem futtatást engedélyez, hanem hozzáférést magukhoz a fájlokhoz, amik ebben a jegyzékben vannak. A cd parancshoz

szükséges. Csak x joggal r nélkül hozzáférhetünk a bejegyzett fájlokhoz, ha tudjuk a teljes nevüket. A védelmi rendszer mûködéséhez tudni kell, hogy a hozzáférni akaró processz milyen védelmi tartományokban fut. A Unix-ban a processzeknek is van • valós és effektív tulajdonosa (uid-dal azonosítva), • valós és effektív tulajdonos csoportja (gid-del azonosítva). A valós és effektív tulajdonosok többnyire egybeesnek, de setuid koncepció (lásd késõbb) szerint különbözhetnek is. A védelmi tartományokat, melyben egy processz fut, az effektív tulajdonosságok határozzák meg, ezzel a processz két védelmi tartományban fut. A védelmi politika: 1. Elõször a hozzáférni akaró processz effektív tulajdonosági kódja és egyezés a fájl van, tulajdonossági akkor a kódja összevetõdik. fájltulajdonoshoz rendelt Ha itt jogosultság (rwx bitminta) szerint biztosított a hozzáférés. 2. Ha az

elõzõ összevetésben nincs egyezés, akkor a csoport tulajdonosságok tulajdonos vetõdnek kódja!). össze Egyezés (a processz esetén a effektív fájl csoport i-bögjébõl a csoporthoz tartozó bitminta szerinti a hozzáférés. 3. Ha az elõzõ két összevetés "sikertelen", akkor az others bitminta szabja meg a hozzáférést. Ez azt jelenti, hogy tulajdonos hozzáférését a fájlvédelmi minta tulajdonos része határozza meg, hiába van nagyobb jog akár a csoport, akár az others bitmintában. Egy fájl, aminek védelmi mintája a következõ ---r--rwx nem elérhetõ a tulajdonos számára, a csoport tagjai ugyan olvashatják, de nem írhatják, mialatt mindenki más, aki nem tartozik a csoporthoz teljes hozzáféréssel rendelkezik. Ezért ez a hozzáférési lista nem valami hasznos! A setuid koncepció (D. Ritchie) Minden processz rendelkezik A • valós tulajdonosi, csoporttulajdonosi azonosítóval, és •

effektív tulajdonosi, csoporttulajdonosi azonosítóval. legtöbb esetben a valós és az effektív tulajdonosságok ugyanazok. A valós tulajdonosságot a processz a szülõjétõl örökli, vagy a szülõje állítja be neki. Gyakran szükség biztosítsunk van arra, hogy processzeknek különleges valmilyen többlet-jogokat szabályozott módon. Például, ha jelszót változtatunk a passwd segédprogrammal, be kell írnunk a jelszavakat tartalmazó fájlba, amire persze nekünk nem lehet írási jogunk, mert akkor bárkinek a jelszavát átírhatnánk, kitörölhetnénk stb. Hogy megoldják ezt a problémát, Ritchie javaslatára, a kernel megengedi, hogy olyan processzeket kreáljunk, amelyeknek többletjoguk van. Bizonyos végrehajtható fájlok Identification/Set Group ún. ID) setuid/setgid engedéllyel (Set User rendelkeznek (lásd man ls). Amikor egy ilyen programot futtatunk, a keletkezett processz valós tulajdonosa

indítottuk, a tulajdonosa mi mi csoportunk), annak leszünk hiszen tulajdonosságait tulajdonosa/csoport-tulajdonosa viszont a (valós mi örökli. az az csoport shell-ünkbõl Az effektív uid/gid lesz, ami a betöltendõ program fájlhoz tartozik. A fenti példában passwd futtatható program tulajdonosa a root (superuser), ez egyben setuid program. Ha futtatjuk, a processz valós tulajdonosa mi vagyunk, effektív tulajdonosa viszont a root. Mivel a jelszavakat tartalmazó fájl tulajdonosa szintén root, a processz kicserélhet jelszavunkat, írhatja a fájlt. Gyakorló feladatok 1. Tanulmányozzák az on-line manual-ban az umask, chmod, chown parancsokat! 2. Gyûjtsenek ki setuid engedéllyel rendelkezõ programokat a 3. Állítsanak be fájljaikra különbözõ, célszerû védelmi mintákat, ellenõrizzék a hozzáféréseket. Összefoglalás Léteznek védelmi tartományok (Protection Domains). Ezek valamilyen módon

azonosítottak. A processzek - tulajdonképpeni szubjektumok - védelmi tartományokban futnak. Az objektumok (passzív elemek, fájlok, jegyzékek, eszközök stb.) különbözõ elérésekkel (rwx stb.) kezelhetõk. A védelmi tartományok és az elérési jogok vagy hozzáférési lista (ACL) jelleggel (objektumokhoz kötött hozzáférési jogok védelmi tartományonként), jelleggel vagy jogosultsági (processzekhez jogosultságok) kötött rögzítettek. A két lista (CL) tartományokkénti forma ugyanazt az információtartalmat biztosítja. A védelmi tartomány nagyon általános fogalom. Védelmi tartomány váltás van felhasználói mód - kernel mód váltásnál. Védelmi tartományok vannak egy számítógéprendszer eléréséhez, a kapcsolatépítéshez, az ülés létesítéséhez: a "belépéshez" stb. Általános szabály: szabályozott módon egy védelmi lehet. tartományba Legtöbbször az bejutni

csak azonosító/jelszó mechanizmuson keresztül, de vannak más mechanizmusok is. Sok rendszerben a szokásos (ordinary) védelmi tartományok azonosítása a tulajdonossági kategóriákon keresztül történik, de vannak más módszerek is, melyek kiegészítik az elõzõt. 9.3 Rendszerindítás, leállítás Egy t öbbtaszkos, e setleg t öbbfelhasználós operációs rendszer i ndítása r endszerint bonyolultabb f eladat, m int e gy e gyszerû gép be kapcsolás. P ersze, ha j ól i nstallálták, j ók a z alapbeállítások (setup), jó indító (startup) konfigurációs burok programokat írtak hozzá, akkor lehet, hog y egszerû a z i ndítás. N ézzük á t, mi is tö rténik a startup során, m iket ke llhet a rendszermenedzsernek csinálni! A gé p be kapcsolása ut án a z ope rációs r endszer i ndulása t öbb f ázisban t örténik. a f ázisok durván: 1. 1 A hardver ROM rutinok futnak 2. 2 Az ún boot loader fut 3. 3 Az operációs rendszer kernel

inicializálódik 4. 4 A "kézbõl" induló processzek keletkeznek A ROM rutinok teszteléseket v égeznek, ellenõrzik a m emóriát, eg yéb h ardver komponenseket. Lehetséges, ho gy i nteraktív m enüt kí nálnak, e setleg a z i ntelligens kontrollerek f elprogramozását s egítik. E zeket a g ép s zállítója ad ja a g éphez V égül kezdeményezik a boot-olást. Maga a boot-olás rendszerint két fázisban történik: first stage boot és second stage boot. A first stage boot során a k ijelölt partíció 0. bl okkjáról be töltõdik a kezdeti betöltõ (initial boot) pr ogram, é s e lindul. ( Nem boot -olható pa rtíció, e szköz ke zdeti be töltõ pr ogramja e gy üzenetet í r ki , ho gy nem r endszer di szkrõl akartunk boot -olni.) A ke zdeti be töltõ pr ogram akármilyen operációs rendszer betöltését kezdeményezheti, azzal, hogy indítja a second stage boot programot. Néha "be van drótozva" a second stage boot neve, helye a first

stage boot-ba, néha bekéri a nevet a kozolról (ekkor már a konzol eszköz is ismert). A second stage boot program l ehet r észe egy o perációs r endszer f ájl-rendszerének: ot t e gy fájl, adott névvel, de speciális helyen van, hogy a kezdeti boot program - ami rövid program, elfér egy bl okkon - felismerhesse. Lássuk be , ho gy a ké t boot pr ogram e gyüttmûködõ ke ll legyen. A second stage boot-ba "be lehet drótozva" az operációs rendszer kerneljének neve, de az is lehet, hogy adhat készenléti jelet (prompt) a konzolra (rendszerint ez a kettõspont (colon :)), kérve a kernel nevét, helyét stb. Ezek természetesen operációs rendszertõl függõ dolgok Ha kéri, akkor m eg kell adni a diszkvezérlõ nevét (a driver program része a second satge boot nak), a pa rtíciót, e gy eltolás ( offset) bl okkszámot ( az á tvizsgálandó pa rtíció ke zdetétõl számítva honnan keressen) és a kernel nevét. Egy példa erre: : rm (0,0) unix

ahol rm: a kontroller azonosító (driver-t azonosítja), 0: elsõ partíció (a drive száma), 0: kezdetétõl keress, unix: ez a kernel neve, töltsd be. A kernel - miután betöltõdött -indul: inicializálódik. Ezzel tulajdonképpen használatra. felkészíti Pl. rendelkezésére ellenõrzi álló a hardvert és belsõ memóriát a és a tábláiba virtuális szoftvert feljegyzi a memóriakezeléshez, inicializálja az eszköz driver-eket. Az inicializált kernel végül kreál processzeket. "Kézbõl" készül a 0. pid-û processz, SVID Unixnál ez a swapper, más, újabb Unix-oknál a sched. Nem találunk swapper, vagy sched futtatható program-fájlt a része. swapper/sched feladata A fájl-rendszerben, lesz az az a kernel ütemezés. Most azonban elsõ tevékenységeként elkészíti az 1. pid-û processzt, az init processzt. Az init processz lesz általában minden más processz szülõje. Állapotai (states): boot,

normál, powerfail. Konfigurációs fájlja a /etc/inittab (SVID rendszerekben), vagy a /etc/ttys (BSD rendszerekben). konfigurációs fájljához Szignálok hatására fordul, abban az az init a meghatározottaknak megfelelõen cselekszik. Boot állapotban • dátum/idõ/idõzóna ellenõrzést, beállítást végeztethet; • megkérdezheti, akarunk-e fájlrendszer ellenõrzést (fsck) végeztetni; • feldolgozza az rc (run command) szkript(ek)et. Ez készít mount táblát (ha még nincs), és mount-olja a fájlrendszereket; letisztítja a /tmp jegyzéket; daemonokat indít (pl. daemonokat stb.) a cron daemont, hálózati, számlázási • A boot állapothoz a single user level tartozik (lásd késõbb). Normál állapotban hatására gyermek futtatható programot, a processzt programot, a login terminál ez pedig vonalon kreál, késõbb a jövõ "jelentkezés" abba betölti a getty magára tölti

a login felhasználó kezdeti programját: rendszerint egy burkot (ezért lesz az ülésünk kezdeti burkának szülõ processze az init). A normál állapothoz a multi user level tartozik. Az init powerfail állapotába lép olyan rendszereken, melyek képesek az áramkimaradást észlelni. Ilyenkor veszélyhelyzeti eljárásokat (emergency procedures) hajthat végre az init. (Pl a sync parancsot a fájl-rendszer integritás megõrzésére.) A Unix futási szintek (Run Levels) Az init mûködése és a /etc/inittab szerkezetének megértéséhez meg kell ismerkednünk a Unix System III-ban bevezetett, az SVID-ben továbbfejlesztett futási szint koncepcióval (a BSD Unix-ok kicsit különböznek). Az SVID-ben a futási szint két értelemben is használatos. Az egyik értelemben létezik: • egyfelhasználós szint (single user level), jele: s, S. Az init boot állapotához ez a szint tartozik. • többfelhasználós szint (multi user level), jele: 2. Ez tartozik az

init normál állapotához. Az egyfelhasználós szint startup során érdekes, ezen a szinten történhet a fájl-rendszer integritás ellenõrzés, a fájl- rendszerek mountolása (jóllehet, átléphet a startup során a rendszer ezen a szinten). Egyfelhasználós szintre válthat a rendszermenedzser, ha karbantartási feladatokat akar végezni. A futási szintek a másik értelemben 0-6 numerikus szintjelzést kapnak: ez a szint értelem csakis az inittab bejegyzéseinek kiválasztására valók. A numerikus szint koncepciót hasznáhatja a rendszermenedzser a vonalak (portok) elérésének kontrollálására. Az inittab szerkezete, az init mûködése Az init mûködését három dolog vezérli: a pillanatnyi állapota (state), a pillanatnyi futási szint (run level) és az esemény jelzése (signal), információ szerint, ami bekövetkezett. beolvasva az Az init inittab-ba, e három kiválasztja a megfelelõ sort, és aszerint cselekszik. Az

inittab egy tipikus sora a következõ szerkezetû: label:run level:action: program to start Példa: co:2:respawn:/etc/getty console co 9600 A cimke (label) mezõ szerepe a számlázásnál, monitorozásnál jön elõ: programok indításánál feljegyzõdik, melyik inittab sorral történt az indítás. A run level mezõ szerepe az ellenõrzés: ha a pillanatnyi szintnek megfelel a mezõ, akkor a sor negyedik mezejében lévõ program indulhat (vagy folytatódhat, ha létezik). Ha nem felel meg: a sorhoz kapcsolódó processz 20 másodpercen belül hangup szignált kap, hogy terminálódjon; ha nem létezik, nem is indul. Itt számítanak a numerikus szintek is A mezõ lehet üres (ugyanaz, mintha minden szintet felsorolnánk), lehet szint-jelek felsorolása. Az action mezõ reprezentálja az akciót. 11 különbözõ akció lehetséges, néhányat ismertetünk: • sysinit: Boot állapothoz tartozik. Indítja a programot amikor az init

elõször olvassa az inittab-ot. • respawn: (Normal state akció.) Indítsd a programot, és indítsd újra mindenkor, ha befejezõdött. A getty-hoz használjuk. • wait: (Normal state.) Inditsd a programot és várd meg a befejezõdését, mielõtt a következõ sort feldolgoznád. • off: (normal state.) Ha a program (vagy leszármazottja) él, akkor termináld. • once: (Normal.) Indítsd el a programot egyszer, és addig ne indíts újra, míg az (vagy leszármazottja) él. Tanulmányozzák a /etc/inittab fájlt különbözõ rendszerekben! Nézzék a maual lapot is! Az init-tel való kommunikáció A rendszermenedzser (superuser) küldhet szignált az init-nek akár a telinit, akár az init paranccsal. Tanulmányozzák a /etc/shutdown a manuel-ben. A rendszer leállítása A szokásos végzi a legyen rendszerzárást rendszermenedzser az aktuális felhasználói (kiadása jegyzék, felületnél az elõtt unmont-ok toolchest

burokprogrammal a gyökér miatt). menüelemmel jegyzék Grafikus is zárhat rendszert. A shutdown • figyelmezteti a felhasználókat a rendszerzárásra; • leállítja a daemon processzeket; • terminálja az aktív processzeket; • umount-olja a fájlrendszereket; • single user futási módba állítja a rendszert (init s); • kiad sync parancsot Tanulmányozzák a manualben! Fájlrendszer konzisztencia ellenõrzés (fsck) Nem megfelelõ esetén a eszközkezelés, fájl-rendszer nem "széteshet". megfelelõ A szétesés rendszerzárás leggyakoribb okai: • áramkimaradás miatti nem normális rendszerzárás; • kivehetõ médium (pl. floppy) kivétele umount elõtt A szétesett fájl-rendszerben a hibák: • A superblock módosított, de csak az in-core változatában (a diszkre nem íródott ki). • Vannak blokkok, melyek nem tartoznak fájlokhoz, de nincsenek a szabad listán sem. • Vannak blokkok, melyek

a szabad listán is, és valamelyik fájl i-bögben is be vannak jegyezve. • Vannak jegyzék (directory) bejegyzések, melyekben az i nem mutat érvényes i-bögre. • Vannak i-bögök, melyekben a link számok nagyobbak, mint ahány jegyzékbõl van az i-bögre utalás. Mi jelzi a szétesést? A superblock egy mezõje. Vagy az a tény, hogy a szuperblokkba bejegyzett egyezik. rendszer elõtt i lista méret és Segédprogramokkal szétesett-e az fsck vagy a valódi i lekérdezhetõ, sem, de segédprogrammal lista méret vajon legjobb egy minden ellenõrizni, és nem fájl- mountolás megpróbálni rendbehozni a fájl-rendszert. Az fsck indítása (csak superuser, és csakis nem mountolt állapotban): # fsck special-file Az fsck 6 fázisban fut. 1. fázis: az i-bögök ellenõrzése, adatgyûjtés fázisokhoz. Minden i-bögben • érvényes fájl típus bejegyzés kell legyen; • nem nulla linkszám kell legyen; •

érvényes blokk mutatók kellenek; • jó fájl-méret bejegyzés kell legyen. Feljegyzõdnek • az érvényes blokk címek, • a linkek száma, • az i-bög állapotok, az érvényes i-bögök. 2. fázis: az ösvények ellenõrzése a további Minden jegyzék bejegyzés ellenõrzõdik a gyökértõl kezdve! Egy directory bejegyzés • érvényes i-bögre kell mutasson (adatok az 1. fázisból) • Az 1. fázisban gyûjtött hivatkozások és link számok jóke? (Minden fájl szerepel valamelyik jegyzékben? Megfelelõ számú jegyzékben?) 3. fázis: kapcsolat ellenõrzés Ha valamelyik dir típusú i-bögnek nincs dir-beli bejegyzése (ezt a 2. fázisban felfedeztük), akkor készüljön dir bejegyzés neki! 4. fázis: hivatkozások ellenõrzése Nem dir típusú i-bögnél is elõfordulhat, hogy nincs megfelelõ számú dir bejegyzés összszámának (2. hozzá. fázisban Márpedig rögzítettük) a dir meg bejegyzések kell egyezni a linkek

számával, továbbá az összes i-bögök számának egyezni kell a szuperblokkba bejegyzett számmal. Szükség esetén a nem dir típusú i-bögöknek is készül dir bejegyzés. 5. fázis: a szabad lista ellenõrzése Végignézzük, hogy a szabad listán érvényes blokk címek vannake, ezekbõl szerepel-e valamelyik i-bögben is (egy blokk vagy a szabad listán, vagy egy i-bög bejegyzésben szerepelhet csak). 6. fázis: szabad lista helyreállítás Levehetõ a szabad listáról egy helyes i-bögben címzett, érvényes blokk. Felvehetõ a szabad listára az, amire nincs érvényes i-bögben hivatkozás (ne felejtsük, itt már a dir bejegyzések kiegészítettek!). Gyakorló feladat: Floppy lemezt mountoljunk, írjunk rá, vagy töröljünk róla valamit, és mielõtt umountolnánk, vegyük ki a lemezt! Ekkor nagy valószínûséggel nem lesz konzisztens a fájl-rendszer a floppyn. Most umontolhatunk, majd visszatéve a floppyt, fsckval

próbáljuk meg rendbetenni! Fájl-rendszer készítés, használatba vétel Tételezzük fel, létezik logikai diszk a rendszerünkben (van partíció, vagy diszk, pl. floppy, és van hozzá speciális fájl, driver program). Ekkor az mkfs segédprogram segítségével fájlrendszert készíthet a szuperuser a logikai diszken Az mkfs elõször elkészíti a fájl-rendszer két részét: a szuperblokkot és az i-listát. Utána az adat blokkokat a szabad listára összegyûjti. Végül elkészíti a gyökér jegyzéket (i-bög = 2), ennek blokkját le is veszi a szabad listáról. Tanulmányozzuk a man-ban az mkfs-t! Használatához minimálisan a logikai diszk nevét (speciális fájlja nevét), esetleg a méretét (blokkban) kell megadni. # mkfs diskname size Figyelem! Az mkfs felülírja a diszket! Ami volt rajta, elvész. További argumentumok is adhatók az mkfs-nek: pl. az i-lista mérete megszabható. számítódik, hogy Az 4K-ként alapértelmezési

lesz i-bög. i-lista azaz méret átlagosan úgy 4K-s fájlokra számítunk. Ha kevesebbel is beérjük vagy többre van szükségünk, használjuk az mkfs-t így: # mkfs diskname size:inode Az /etc/labelit segédprogrammal címkét adhatunk a diszknek. A címke használata a mountolásnál ellenõrzésre jó: a mount figyelmeztet, ha a fájl-rendszer címkéje és a mount-pont neve nem egyezik. A lost+found jegyzék Az új fájl-rendszer elkészítése után célszerû készíteni lost+found jegyzéket, ugyanis az fsck használja ezt! Persze, ezt csak mountolás után tehetjük. A következõ parancsok pl elkészítik és jó engedélyeket adnak e jegyzéknek: # mkdir /ures-dir # mount diskname /ures-dir # cd /ures-dir # mkdir lost+found # chmod 777 lost+found Most megvan a lost+found a célszerû engedélyekkel. Van benne két bejegyzés is, a . és a . jegyzék. Van benne hely valamennyi további bejegyzésre ( 62, feltéve, hogy 1024-esek a

blokkok). Miután az fsck több bejegyzési helyet is kívánhat, célszerû a lost+found méretét megnövelni, mielõtt tényleg használatba vennénk a diszket! Ezt úgy szokták csinálni, hogy ciklusban fájlokat készítenek (méretük nem számít!), amiket a lost+found-ba jegyeztetnek be, majd letörlik ezeket a fájlokat. Az eredmény az lesz, hogy a lost+found mérete (a hozzátartozó adat blokk szám megnövekszik. (Az egész játék arra jó, hogy egy késõbbi fsck müködés közben ne kelljen a lost+found számára blokkokat foglalni, hiszen akkor gond lehet az érvényes-nem érvényes blokkokkal.) (Némely rendszerben az mkfs készít megfelelõ lost+found-ot is.) Gyakorlat: Floppy lemezen használhatóvá készítsék el alakítsanak mountolással! a megfelelõ ki fájl-rendszert! Ellenõrizzék, lost+found-ot. Végül ha Tegyék szükséges használják a fájlrendszert. Gyakorolják az umount-ot is 9.4 A felhasználók

menedzselése Számlaszámrendszer, ennek menedzselése A számlaszám (account) egy azonosító, nevébõl következõen • erõforrás felhasználás számlázására, nyilvántartására stb. szolgál, de ezen belül jó • tulajdonossági ka tegóriák r ögzítésére ( ezzel vé delmi t artományok a zonosítására), a védelmi háló kialakítására. Osztályai I. használat szerint • Bejelentkezésre (kapcsolat + ü lés l étesítésre) s zolgáló s zemélyes h asználatú számlaszámok. Ezek a szokásos (ordinary) felhasználói számlaszámok • Bejelentkezésre n em s zolgáló, d e a tulajdonosságot jelölõ számlaszámok ( bizonyos system account-ok). II. A védelmi háló szerint • Korlártozott jogokat biztosító (restricted) s zámlaszámok, min t p l. e gy titk árnõi számlaszám. • Szokásos (ordinary) számlaszámok, pl. fejlesztõ munkára, általános használatra • Privilegizált számlaszámok, m elyeket a r

endszermenedzserek, b iztonsági menedzserek, programrendszer felelõsök stb. kaphatnak Egy számlaszám komponensei • A l ogin né v: lname, am it a r endszermenedzser és a f elhasználó közösen, megegyezéssel választ, hogy egyedi legyen. • A hoz zátartozó, vá ltoztatható jelszó (password), né ha t öbb j elszó. K ezdeti é rtékét a rendszergazda ad ja, k özli a f elhasználóval, ak i u tána m egváltoztathatja. N éha kötelezik is a változtatásra. • Belsõ azonosító: uid, UIC. Ezt a r endszergazda választja, rendszerint egy egész szám Feltétlenül egyedi. Konvenciók lehetnek a kiválasztásánál • Csoport név: groupname (rendszergazda és f elhasználó megegyezve v álasztják, vagy csoport nevek. • Csoport a zonosító: gid, GUI. R endszergazda vá lasztja N éha t öbb c soport a zonosító kell. Konvenciók lehetnek a választásához • A HOME/default eszköz/jegyzék a bejelentkezési számlaszámokhoz. A rendszergazda

választja. Néhol a felhasználó átállíthatja • A b ejelentkezéskor induló processz p rogram f ájljának n eve a b ejelentkezési számlaszámokhoz. r endszerint e z e gy bu rok, de l ehet egy a lkalmazás i s ( pl titkárnõnek). Limitek és quoták a számlaszámhoz. Capatibility list jellegû! A Unixban ilyen csak közvetve van. • Általános adatok a felhasználóról: teljes név, szoba szám stb., kommentár jelleggû A Unix számlaszám rendszerhez tartozó fájlok Ezeket a bejelentkezéskor használja a rendszer: /etc/passwd su tulajdonú, de mindenki által olvasható ASCII fájl. /etc/group su tulajdonú, de mindenki által olvasható ASCII fájl. /etc/init az in it p rocessz p rogram f ájlja. E z "f igyeli a v onalakat", h ogy egyébb processzek segítségével a fenti két fájlt használva ellenõrzött ülés létesítést biztosítson. Sikeres k apcsolat+ülés l étesítés u tán a k apcsolattartó pr ocessz f ut, m elynek t ulajdonosa a

z lname/uid/gid-del jelölt személy. Védelmi tartományai a az uid/gid-del azonosítottak Ennek gyermek p rocesszei i s ezekben a protection domain-ekben f utnak, ha csak ni ncs va lami korlátozó/kiterjesztõ mechanizmus (setuid/setgid). /bin/passwd a je lszó á llítására a lkalmas p rogram. Lehet "proactive": olyan je lszóállító, ami megkövetel bizonyos szabályokat. Pl: • legalább x karakter hosszú legyen a jelszó; • változatos karakterekbõl álljon; • password aging: le járati idõvel r endelkezik, r égi j elszavakra emlékszik, a zokat ne m engedi újra; • jelszó generátor lehetõséget ad; • stb. A Unix /etc/passwd fájl sorainak mezõi (: a mezõelválasztó): (A fájlban egy egy sor egy egy számlaszám.) • lname • pwd titkosított, vagy "shadow" (nem itt tá rolt) jelszó. Lehet üres: ekkor nincs jelszó, ami t ipikus vé delmi l yuk, ke rülendõ, ellenõrizendõ. Lehet l etiltást, l ejáratot j elzõ

bejegyzés is. • uid • gid • teljes név (kommentár) • HOME jegyzék • startup program fájl Az uid nem feltétlenül egyedi. Vannak konvenciók a kiválasztáshoz: 0 a root, vagyis a supeuser; -1 invalid accounthoz; -2 az NFS nobody számlaszám; 1 - 10 rendszer számlaszámok; 11 - 99 fontos, kitüntetett személyek, a uucp számlaszámai; 100-60000 szokásos felhasználók számlaszámai. A gid-re vonatkozóan is vannak konvenciók: 0 a rendszer csoportja. A Unix /etc/group fájl sorainak mezõi (egy sor egy csoport): • gname • pwd (csoport jelszó, a csoport PD elérésére volna, de nam használják) • gid • lname-k listája, vesszõ szeparátorral elválasztva a nevek Lássuk be, összefügggés kell legyen e két fájl között. Továbbá létezõ jegyzékekre, futtaható programokra v aló ut alások va nnak be nnük. E zérta superuser (rendszermenedzser) e k ét f ájl karbantartását er re a cé lra í rt s hell p rogramokkal v

égzi, a mik ös szehangoltan ke zelik a dolgokat. M iután a zonban e zek e gyszerû s zövegfájlok, a s uperuser e gy s zokásos szövegszerkesztõvel i s ka rbantarthatja õke t, üg yelnie ke ll a zonban e kkor a z összehangolásukra. A login program használhat még két fájlt: /etc/dialups # az "õrzött" eszközök speciális fájlnevei; /etc/d passwd # a hozzájuk tartozó jelszók. Rendszermenedzseri gyakorló feladat Vegyünk fel új felhasználót. • Válasszunk neki egyedi lname/uid párt. • Válasszunk neki gname/gid párt. Mi van, ha nem létezik? • Válassz neki HOME directory nevet. Ha ez a dir nemlétezik? • Válassz neki startup programot. • vi editorral írd be sorát a /etc/passwd fájlba. Jó, ha biztonsági másolaton dolgozol, és a végén átnevezed! • vi editorral írd be. editáld meg a sorát a /etc/group fájlba Itt is biztonsági másolattal célszerû dolgozni. • Készítsd e l H OME j egyzékét. Írd á t e nnek

t ulajdonosát ui d/gid-re Tegyél b ele "startup" fájlokat (.login, profile stb) • Próbáld ki, jó-e. Hogyan oldod ezt meg célszerû shell script segítségével? 9.5 A NIS (Network Information Services) (Korábban Yellow Pages elnevezésû rendszer). A NIS központosított adatbázis, ami a hálózat használatát hatékonyabbá teszi. Tipikus pé lda l ehet a hálózati né vfeloldás: a há lózati c somópontok ne veihez s okszor szükséges hozzárendelni az IP címet. Az egyedi gépeken a /etc/hosts fájl tartalmaz névIP cím párokat, amibõl a névfeloldás megoldható Ha nincs NIS rendszer, akkor ezt a fájlt az egyedi c somópontokon karban k ell t artani, á llandóad na prakész á llapotba ke ll hoz ni. H a viszont telepítünk NIS rendszert, a karbantartást csak egy gépen kell végezni, ez a gép a többi számára szolgáltathatja a karbantartott táblázatot. Általános keresési szabály fogalmazható m eg a N IS r endszer es etén: v

alamilyen k eresett inbformáció ál talában e lõbb a N IS ad atbázisban k eresendõ, az tán a h elyi ad atok k özött. Persze vannak fordított keresési sorrendek is, és lehet olyan keresés, amikor a hely adatbázist meg sem nézik. Mindezt majd látni fogjuk A NIS kliens-szerver koncepciója A szokásos kliens szerver koncepcióval dolgozik a NIS. Mégis, amikor NIS kliens kifejezést mondunk, az lehet, hogy egy csomópontot (egy host-ot) jelent a hálózaton, vagy lehet, hogy egy ilyen gépen f utó p rocesszt. U gyanígy, a NIS s zerver j elenthet e gy gépet, v agy egy szolgáltató processzt ezen a gépen. Egy NIS kl iens gépen futó pr ocessz ( ez i s N IS kl iens) kül dhet e gy kérelmet egy N IS szervernek (szerver gépen futó processznek). A kérelemben valamilyen információt igényel a NIS adatbázisból. A szerver processz kezeli az adatbázist, kiveszi a k ért információt, és egy válaszban elküldi a kliens processznak. A szerverek hierarchiája

Létezik a NIS rendszerben egy master server, és létezhetnek slave server-ek. A master server gépen tartják karban a NIS adatbázist. A slave gépek duplikátumokat tartanak az adatbázisból: szerpük t ulajdonképpen a kkor va n, ha va lamilyen okból a m aster ne m t udja ki szolgálni a klienstõl jövõ kérelmet. Ilyenkor a kérelmet valamelyik slave kapja meg, és az szolgál ki A NIS képek (maps) A N IS ad atbázis képekbõl á ll. E gy kép (map) fájlok c soportja A m ap-ekben dbm adatbázis formában t alálhatók a z a datok, ne m A SCII f ormában: e nnek oka a gyorsabb ke resés, a hatékonyabb tárolás. (Segédprogram konvertálhatja az ASCII fájlokat dbm formába) Minden képnek van neve. A kliens gépeken futó alkalmazásoknak tudniuk kell ezeket a neveket, mert a k érelmeiket a m ap-ek ne veivel a dják ki , t ovábbá t udniuk ke ll a m ap-ekben t árolt információk formáját. A map-ekben keys és values formában szokták az információkat

tárolni. Pl. a hostsbyname képben a ke ys egyedi gépek ( host-ok)nevei; a v alues ez ek IP címei lehetnek. A NIS tartományok (domain) Egy NIS t artomány gépek cs oportja, m elyek ugyanazt a N IS ad atbázist h asználják. A tartományoknak v an ne vük. A tartományhoz ta rtozik e gy master server gép, és t artozhat néhány slave server. Ezen kívül a tartományhoz tartozhat valamennyi kliens gép J egyezzük már most meg, hogy a szerver gépek egyben kliens gépek is. A N IS t artomány e gybeeshet az Internet t arománnyal, d e ez n em k ötelezõ. S õt, a N IS tartományba tartozó gépek lehetnek különbözõ hálózatokon is. A NIS adatbnázis "home" jegyzéke a /usr/etc/yp vagy a /usr/etc/yp/domain name jegyzék. A NIS daemon processzek Három daemon processz segíti a NIS rendszert. Ezek az ypbind, ypserv és feladatukat az rpc.passwd tárgyalnánk, processzek. foglajuk össze, Mielõtt hol szerepüket, kell ezek a daemonok: daemon Kliens

gép Slave gép Master gép ypbind x x x x x ypserv fussanak rpc.passwd x Az összekötés (binding) fogalama Az ö sszekötéssel "emlékszik" e gy p rocessz ar ra, hogy m elyik s zerver f igyeli és s zolgálja k i kérelmét. Az ypbind daemonnak futnia kell a k ilens gépeken és a s zerver gépeken is, mert az a lkalmazások, a mik i nformációkat ké rnek a NIS ad atbázisból, a t artomány a kármelyik gépén futhatnak. Az ypbind felelõs azért, hogy az alkalmazások "emlékezzenek" arra, melyik ypserv daemont szólíthatják meg kérelmekkel. Ha e gy alkalmazás k ér valamilyen i nformációt, am i s zokásosan h elyi adatbázisban l enne, akkor az a laklmazásból hí vott futásideji könyvtári (RTL) fü ggvény a binding koncepció segítségével f olyamodhat a N IS adatbázis i nformációért. A z ypbind daemon s egíti a z alkalmazást, hog y m egkapja, m elyik szerver gép melyik portján folyamodhat az információért. Az

ypserv daemon kezeli a N IS adatbázist. Futnia kell a s zervereken Az ypserv fogadja a k éréseket, k iveszi az i nformációt az ad atbázisból és v isszaküldi v álaszüzenetben az alkalmazásnak. A master szerveren futnia kell a /usr/etc/rpc.passwd daemonnak is Ez engedi meg, hogy a "távoli" f elhasználók a z yppasswd paranccsal m ódosíthassák j elszavaikat. a N IS adatbázisban, ypchpass paranccsal módosíthassanak egyébb adatokat ugyanott. A NIS adatbázis Mint e mlítettük, a z a datbázis k épei dbm formájúak. A s zokásos A SCII f ormából a rendszermenedzser a makedbm segédprogrammal al akíthat f ájlokat er re a f ormára. A N IS adatbázisban va nnak s tandard é s l ehetnek ne m standard ké pek ( map-ek). A l eggyakoribb standard, alapértelmezés szerinti képek a "becenevükkel" együtt a következõk: Becenév (nick-name) Teljes név passwd passwd.byname group group.byname network network.byaddress hosts hosts.bynumbers

protocols protocols.bynumbers services services.byname rpc rpc.bynumbers aliases mail.aliases ethers ethers.byname Tartalmukat r emélhetõleg a n evük s egítségével m egérthetjük: p l. a p asswd k ép a N IS-beli passwd fájl, a group a csoport fájl stb. A kliensek Ha egy gép kliens (fut rajta az ypbind), akkor a rajta futó alkalmazások bizonyos fájlok esetén nemcsak a m egfelelõ h elyi f ájlokat, v agy a h elyi f ájlokat eg yáltalán n em k eresik f el. N em mindent felsorolva és nem teljes magyarázatot adva, néhány példán bemutatom a kereséseket. Ha egy kliensen futó processznek (pl. a login processznek) szüksége van információkra a /etc/passwd, vagy a /etc/group fájlból, a kkor a kön yvtári r utin e lõször a he lyi f ájlt né zi e lõször. H a a he lyi fájlban + (vagy -) karaktert talál, akkor a NIS passwd, ill. group képért is folyamodik A /etc/host hely fájlt csak a boot-olás során keresi. Utána az RTL rutinok mindíg a

NIStõl kérnek információt Segédprogramok Általános N IS ad atbázis l ekérdezõ p rogram az ypcat. A rgumentumaként N IS k ép ne vét adhatjuk m eg, elegendõ csak a b ecenevet m egadni, és a z ypcat k ilistázza a z N IS a datbázis megfelelõ map-jének tartalmát. $ ypcat mapnév NIS j elszó cs erélhetõ a z yppasswd s egédprogrammal. H a N IS t artományhoz t artozik a gépünk, ezt a parancsot kell használnunk a passwd helyett. $ yppasswd Ha a N IS p asswd f ájlban e gyéb a datmezõinket a karjuk c serélni, pl . a t eljes ne vünket, a bejelentkezési jegyzékünket stb., akkot az ypchpass parancsot használjuk Egyéb s egédprogramok i s va nnak, m elyek kö zól t öbbet c sak a s zuperuser ha sználhat. Részletesebb információkat kaphatnak az SGI insight könyveibõl. Backup - restore 9.6 Archiválás, backup,restore Fájlok, f ájl-rendszerek t önkremehetnek, l etörölhetjük õke t vé letlenül, é s ha ne m ké sztettünk rendszeresen

mentéseket, rengeteg munkánk veszhet el. A mentés (backup) duplikált másolata fájloknak, f ájl-rendszer r észleteknek, f ájl-rendszereknek., amikrõl vi sszatölthetünk ( restore, recovery), újra elõállítva valamilyen korábbi állapotot. A m entési eszközök l ehetnek s zalagok, kazetták, di szkek, C D-k. a t ovábbiakban a / dev/tape eszköznév a mentési médiumot jelzi, akármi is lehet az. /dev/mt/tps0d4 tps0d4 tps0d4nr tps0d4ns tps0d4nrns Ha egy szalagra több backup file-t is szeretnénk írni : nr tape általában a byte-sorrend cserélõdik - ezt akadályozza meg az ns Standard eszközök : /dev/tape /dev/tapens /dev/tapenrns /dev/tapenr Linkeltek a /dev/mt/tpsXdY-ra ! A mentések fajtái lehetnek • fájlok szerinti (file-by-file) mentések; • diszk kép másolat (image copy). Az elõbbinél a mentés lassúbb, de könnyebb a visszaállítás (tar és cpio segédprogramok), az utóbbi gyorsabb, de több munka a visszaállítás (dd és volcopy

segédprogramok). Kategorizálhatjuk a mentéseket az archivált adatmennyiség szerint is, Így lehet • teljes mentés (full backup) a teljes fájlrendszer mentése; • részleges m entés (partial b ackup) e gy adott j egyzék al atti j egyzékrendszer m entése. Gyakran módosított jegyzékrendszer archiválására kisebb mentési területet igényelve, gyorsan is menthetünk. Készíthetünk növe kményes m entéseket ( incremental ba ckup) i s: e zek azon fájlok má solata, melyek egy adott i dõ óta (rendszerint a m egelõzõ m entés ót a) változtak (vagy éppen csak a változások feljegyzése). Ez is gyors, kis területet igényel, de egy idõ után nehéz a követése A r endszermenedzser, v agy a b iztonsági m enedzser f eladata, ho gy s tratégiát dol gozzon k i arra, • mikor mentsenek (pl. amikor nincs nagy terhelés), • milyen gyakran m entsenek ( ez a bi ztonsági k övetelményszinttõl f ügghet, n yilván gyakrabban m entenek e gy ba ni, va gy

k atonai kör nyezetben, m int m ondjuk e gy egyetemen), é s n yilvánvaló, hog y n em ke ll a z e gyes f ájlrendszereket a zonos gyakorisággal menteni; • milyenek l egyenek a mentési t echnikák, a m entés-ellenõrzések ( verification), nyilvántartások stb. A mentési segédprogramokból ismerkedjünk meg eggyel, a tar segédprogrammal. A tar (tape archive) segédprogram Tanulmányozzuk a manuel-ban. Kapcsolói: c új mentést készít (create a new tape); v bõveb információt ad (verbose=fecsegõ); f a követõ argumnetum a tape; t listázza a tape-n lévõ neveket; x extract; u update; Egy példa: $ tar cvf /dev/tape /usr2 $ tar tvf /dev/tape A tar egyetlen nagy fájlt készít, ebbe minden fájlt bemásol, rögzíti a fájl-struktúrát is. A mentésbõl visszaállíthatók az eredeti ösvénynevek. Minden lementett fájlnak 512 bájtos fejrésze van, ezt követik a fájl adatait tartalmazó blokkok (CRC ellenõrzéssel). Képes a tape határokon átlépni

(multivolume) A POSIX szabványnak megfelel (A POSIX-nak megfele a cpio is, ez is fájlonkénti mésolatkészítõ.) Gyakorlat: A gyakorlaton formattált floppyra készítsünk mentést, olyan jegyzékbõl kiindulva, ami ráfér egy lemezre. utána törüljük le az eredeti fájlokat, hogy meggyõzõdhessünk a visszaállításról, és állítsuk vissza a mentésrõl a fájl-rendszert. 10. Az X/Open és az XPG védjegyek (Kivonat a M iniszterelnöki H ivatal Informatikai K oordinációs Iroda á ltal ki adott, a z Informatikai T árcaközi B izottság A jánlásai s orozat 7. s zámú f üzetébõl ki dolgozók: M TA KFKI és MTA SZTAKI, 1994) 10.1 A nyílt rendszer elv Az X /Open s zervezet k üldetése, h ogy a nyílt rendszer elvet terjessze, és e lõsegítse a n yílt rendszerek gyakorlati megvalósítását. Az X /Open m eghatározása s zerint az t ekinthetõ nyílt információs rendszernek, a mi gyártófüggetlen számítástechnikai architektúrára épül, az

egyes komponensei között szabványosak a kapcsolatok. Ezzel biztosított a hordozhatóság (portability), a rendszerek közötti együttmûködés (interoperability) és a fokozatos bõvíthetõség (scalability). A g yártófüggetlenség a zt je lenti, at tól a g yártótól s zerezhetjük b e a t ermékeket, am elyik a legjobb á r/teljesítmény v iszonyt b iztosítja. T ovábbi e lõnyök s zármazhatnak a n yílt r endszer elvbõl: nagyobb megbízhatóság, nagyobb választék, nem évülnek el a felhasználói ismeretek olyan gyorsan, nyitottság más rendszerek felé stb. 10.2 Az X/Open szervezet Az X /Open C ompany e gy független, non -profit szervezet, am elyet 1 984-ben a lapított a z ö t legnagyobb e urópai s zámítógépgyártó c ég: a B ull, a z ICL, a z O livetti, a N ixdorf é s a Siemens. A konzorcium késõbb részvénytársasággá alakult át, és jelenleg 15 tulajdonosa van, köztük sok multinacionális számítógépgyártó óriaásvállalat: Amdahl,

Bull, DEC, Fujitsu, HP, Hitachi, IBM, ICL, N CR, N EC, O livetti, S iemens, S un M icrosystems, U nisys. A 15 tulajdonos 1993 okt óbere óta a Novell, amely egyidejûleg úgy döntött, hogy a Unix S ystem Laboratories tulajdonaosaként a UNIX védjeggyel kapcsolatos jogokat az X/Openre ruházza, ezzel a t ovabbiakban a U NIX r endszer i nterfész s pecifikációinak t ovábbfejlesztése i s az X/Open felügyelete mellett történik. Az X/Open Igazgatótanácsa a részvényesek képviselõibõl, a Felhasználói, a Rendszergyártói és a Szoftvergyártói Tanácsok elnökeibõl és vezérigazgatóiból áll. Három további tanács mûködik: a Felhasználói Tanács (User Council), aminek a feladata a nyílt rendszerkkel szemben támasztott követelmények kidolgozása. Ebben a tanácsban a világ legnagyobb ip ari é s államigazgatási f elhasználói me gtalálhatók, k ét ma gyar ta gja is v an: a Miniszterelnöki Hivatal és az MTA SZTAKI. A Független Szoftvergyártók

Tanácsa (Independent S oftware V endors C ouncil) a na gy szoftverházakat tömöríti, annak érdekében, hogy az X/Open patformon minél hamarabb sok, jó minõségû szoftver áljon rendelkezésre. A Rendszergyártók Tanácsa (System Vendors Concil) dolgozza ki a technikai programokat, a gyártósemleges s pecifikációkat, ho gy a gyártók ki dolgozhassák a s pecifikációkat ki elégítõ rendszereket. A t anácsok m ellett m unkacsoportok dol goznak, a dott pr ogram s zerint. E nnek l ényege: évenként ös szesítik a f elhasználók t apasztalatait, k övetelményeiket, év ente t artott rendezvényen egybevetik ezeket a munkacsoportokban folyó munkával, a folyó projektekrõl jelentéseket adnak közre az Open Systems Directive címû kiadványban. 10.3 A Közös Alkalmazási Környezet specifikálása Ez á tfogó g yüjteménye m ár e lfogadott s zabványoknak, m elyek f elölelik a z ope rációs rendszerektõl kezdve az alkalmazásokig a szinteket, beleértve a

hálózatokat is, ezzel a t eljes informatikai rendszereket lefedik. A s percifikációkat e gy folyamatosan f rissített X/Open P ortabilty Guide-ban (XPG) a dják közre, a mi l ényegében konszenzusnak t ekinthetõ, hog y m i i s a n yílt r endszer. A K özös Alkalmazási K örnyezet f ejlesztése, g ondozása v alójában n em s zabványisítási t evékenység, hanem inkább már létezõ szabványok elfogadása, ajánlása, bizonyos együttmûködés szabványkészítõkkel. Az ú.n "de facto" szabványokat is elfogadják, és h a n incs s zabvány, akkor s aját f ejlesztésû el õírásokat ( esetleg s zabvány b õvítéseket) fogalmaznak meg. Általában v an és j ó a kapcsolat a s zabványkészítõkkel, de de az X/Opent ne keverjük ös sze velük! ( Pl. a z ope rációs r endszerek hí vási s zabványainak ké szítõi az IEEE P OSIX munkacsoprotjai, s zbványkészítõk a z O bject M anagement G roup i llletve a z S QL A ccess Group munkacsoportok

stb.) Az X /Open m unkájában s zerepet ka p a hitelesítési eljárások kidolgozása i s. E nnek kidolgozták a szabályait. A hitelesítési eljárást végigfolytatva egy terméken XPG védjegyet kaphat a termék. A védjegy bizonyítja, hogy a termék megfelel az X/Open elvárásoknak Ez a hitelesítõ program nyitott, nemcsak a tagok hitelesíthetik termékeiket. Ha e gy cég v édjegyet i gényel t ermékeinek, a h ielesítési el járáshoz t artozóan al áír e gy szerzõdést, a melyben elkötelezi ma gát a n yílt r endszer e lv me llett, v állaja, h ogy ha a termékérõl kiderül, valamilyen ponton mégsem felel meg az X/Open specifikációknak, akkor ezt szoftverhibaként kezeli, és mindent megtesz a mielõbbi kijavítására. Vagyis a védjegyuek hosszabb idõre is biztosítják a nyílt rendszer elv betartását. 10.31 XPG dokomentumok Specifikációk: A z X /Open á ltal j avasolt t echnológiák l eírásai, az i nterfészek pont os definíciói. A lapulhatnak

t ényleges s zabványokon, " de f acto" s zbványok publ ikus l eírásain Rendszerint ezért csak hivatkozások specifikációkra. A komponensek leírásai. A komponens egy jól leválasztható feladat Ez a legkisebb egység, ami önállóan hitelesíthetõ. Pl a C nyelv, a grafikus felület, ezek lehetnek komponensek A profilok. A pr ofilok egyes t ipikus f elhasználásra a lkalmas kom ponens-csomagok P l a z Alap Profil tartalmazza a többnyelvûsített rendszerhívásokat és a könyvtárakat, a parancsokat és s egédprogramokat, v alamint a C n yelvet: a " tipikus" h asználat i tt az al ap o perációs rendszer ha sználat. A z alap pr ofilt ki egászíti a t öbbi pr ofil, t ovábbi k omponensekkel A profilok segítségével a vásárló egyszerûbben fogalmazhatja meg követelményeit. (A további profilokról késõbb még lesz szó.) További anyagok. Útmutató a hitelesítéshez, ami tartalmazza a védjegy-licensz egyezményt, kérdõíveket, a

hitelesített termékek jegyzéke, a kiadványok listái stb. 10.32 Az XPG3 1988-ban jelent meg, a fõ célja az alkalmazások és a rendszerek közötti hordozhatóság volt. Összesen 16 komponenst tartalmazott, hat profilban: Háttértárolás Forráskódátvitel (tar,cpio) Adatkezelés Felhasz(nálói felület Ablakkezelés (X11) Hálózati kommunikáció ISAM SQL Transzportszolgáltatások PC-s kapcsolódás Programnyelvek C Ada Operációs rendszer felület Többnyelvûsített rendszerhívások és könyvtárak Parancsok és segédprogramok Terminálcsatoló Folyamatok közötti kommunikáció COBOL FORTRAN Pascal Más csoportosításban: Forráskód átvitel Ablakkezelés ISAM COBOL Rendszrhívások és könyvtárak Folyamatok közötti kommunikáció Transzport szolgáltatások SQL FORTRAN Többnyelvûsítés Parancsok és segédprogramok Ada Választható profil PC-s kapcsolódás Terminálcsatoló Pascal Plusz profil C nyelv Alap profil Az operációs

rendszer felület profilt (ami tulajdonképpen az XSI: X/Open System Interface, nevet v iseli, al apja a P OSIX és az S VID), a programnyelvek profilt ( ISO va gy A NSI szabványok az alapok) nem kell magyarázni. Az adatkezelés profilban az ISAM i ndexszekvenciális h ozzáférést t esz l ehetõvé az alkalmazások számára, az SQL az ANSI SQL egy változata, C és COBOL nyelvi beágyazást tesz lehetõvé. A felhasználói felület profil ablakkezelése az X Windw System, C nyelvi csatolóval. A hálózati kommunikáció profilban X TI (X/Open T ransport Interface) f elületen -ami különbözõ, s zabványos há lózati pr otokollok f ölött m egvalósítható - összeköttetést valósíthatnak m eg az al kalmazások. A P C-s k apcsolódás cs ak t erminálemulációt és adatátvitelt biztosít egy nyílt rendszer és egy PC között. A háttértárolás profilban a forráskódátvitelhez hajlékony lemezen és 0.5"-s mágnesszalagon tar és cpio, hálózaton uucp

alkalmazható. 10.33 Az XPG4 1992-ben, az XPG negyedik kiadásában a hangsúly hordozhatóságról az összekapcsolódásra és együttmûködésre tolódott. 5 profilban 22 komponens szerepel benne Alap profil: Rendszerhívások és könyvtárak Parancsok és segédprogramok C nyelv Adatbázis platform profil: COBOL Relációs adatbázis Transzport szolgáltatások (XTI: OSI, TCP/IP, UPD/IP, NetBIOS felett) Munkaállomás profil: (Egyfelhasználós, hálózatra is csatolható környezet.) Terminálcsatoló Ablakrendszer-alkalamazás felület (X11) Ablakrendszer megjelenítõ (X11) Transzport szolgáltatások (XTI) Hálózati állományrendszer (NFS) OSI kommunikációs platform profil (A kommunikációs lehetõségekhez.) Transzport szolgáltatások (XTI) X.400 üzenetelérés X.400 átjáró Katalóguselérés (X.500) BSTF Alap szerver profil (Egy olyan rendszer, amihez többféle, grafikus és alfanumerikus terminál is csatlakoztatható, akár hálózaton is.)

Terminálcsatoló Ablakrendszer alkalmazás felület (X11) Transzport szolgáltatások (XTI) Hálózati állományrendszer (NFS) LMX szerver (PC)NFS szerver További komponensek: Programnyelvek (Ada, COBOL, FORTRAN, Pascal) Adatkezelés (SQL, ISAM) Adathordozók (elmaradt a floppy). 10.4 A Spec 1170 (Kivonat M. Funkenhauser: Single UNIX Specification, Unix Review, 1995 jun p41) A H P, az IBM, az O SF, a S unSoft és a N ovell an yagi t ámogatásával o perációs rendszergyártók, fejlesztõk és felhasználók a 90-es években közös munkát folytattak, melynek a c élja a U nix r endszerek köz ös f elhasználói i nterfészének de finiciója vol t. A m unka eredménye a Spec 1170 néven i smertté v ált s pecifikáció l ett: a s pecifikációban 1 170 A PI-t (Application Programming Interfaces) definiáltak (926 rendszerhívást, 70 beleértett fájlt, 174 parancsot, s egédprogramot). A definíciók kül önbözõ i pari szabványokból ( ISO C , P OSIX1, POSIX.2),

vagy "de facto" szabványokból (curses, BSD sockets, XTI, SVR4 osztott memória, BSD matematikai függvények) lettek kiválasztva (azaz nem szabványosítási munka foly itt). A "megosztást" az alábbi táblázatban láthatjuk: XPG4 parancsok, segédprogramok XPG4 rendszerhívások és header fájlok Novells System V Interface Definition (SVID), Edition3, Level 1 OSFs Application Environment Specification (AES) Full Use Interface Egyéb, általában használt interfész 14.9% 36.1% 31.9% 2.4% 14.7% A m unka 1994. j anuárjában f ejezõdött be , a z e redményeit ekkor a dták á t a z X /Open társaságnak. Az X/Open egész kis módosításokat tett (pl. a curses függvényeket külön specifikációba tette) és kiadta az eredményt: Single UNIX Specification címmel (ebben 896 A PI és 189 pa rancs, segédprogram definició van.) A jelentõsége ennek: a Unix a továbbiakban egyetlen cégnek sem "privilégiuma", különösen, ha f igyelembe v

esszük, h ogy a N ovell a U NIX m árkajegyet átadta az X /Open részvénytársaságnak. E zzel a U nix " de f acto" szabványa s zületett m eg, a S ingle U NIX Specification é s a z X /Open C urses, Issue 4 specifikáció e gyütt a dja a z X /Open U nix specifikációt. Persze, ez még csak specifikáció, nem jelenti azt, hogy minden Unix így is néz ki. De megvan az al ap, eb be az i rányba f ejlõdhetnek a r endszerek, és át vihetõ ( portable) al kalmazásokat készíthetnek a szoftvergyártók. 10.41 Miért nemcsak XPG? Kérdezhetjük, a z X /Open m unkacsoportjai, s pecifikációi m iért ne m voltak e legendõk? Vannak POSIX szabványok is, miért kellett a Spec 1170-et kidolgozni? Az ok m eglehetõsen pr agmatikus, ha szonelvû. A S pec 1170 ki dolgozása s orán kül önbözû Unix r endszereken t öbb m int 20 na gy s zoftvercég m integy 50 - a l egfrekventáltabb alkalmazását vizsgálták, az 50 a lkalmazás több mint 3500 kön ytári rutinját

analizálták, valós teszteléssel, a legkülönbözõbb hardver platformokon. Az analízis eredménye az volt, hogy az eddigi "szabványos" i nterfészekhez m ég d efiniálni ke ll m integy 130 t ovábbi A PI-t ( kissé leegyszerûsítve a zt mo ndhatjuk, h ogy nem a v ilág le ggyakoribb alkalmazásai ille sztik a meglévõ Unix s zabványokhoz, ha nem a U nixot a m eglévõ a lkalmazás-világhoz.) A z e ddigi szabványok ki egészítéséhez f õleg a B SD m ath é s m emória f üggvényei, TCP/IP f üggvények és a szimbolikus fájl link függvények kellettek. Az analízis eredménye volt természetesen az is, hog y u gyanahhoz a ( vagy na gyon ha sonló) f unkcióhoz kül önbözõ A PI-k vol tak a különbözõ r endszerekben. Á ltalában i lyenkor n em s zükséges ké t i mplementáció, é s e zt a problémát az egyik interfésznek a másikra való leképzésével oldották meg. Példát említhetünk erre: a B SD index() hívás a n evétõl el tekintve

megegyezik az A NSI C strch() hívásával. A leképzés, akár kölcsönösen, lehet a következõ: #define index(a,b) strch(a,b) 10.42 The Open Group 1996-ban a z X /Open s zervezet é s a z O SF ( Open S oftware F oundation) e gyesült, e z a z új szervezet l ett a z O pen G roup. A z e gyesülésbe további c soportokat i s be vontak ( pl O bject Management Group, W EB C onsortium s tb). M a a z O pen Group-nak 8 s zponzora ( platina tagok), 5 a rany t ámogatója, 104 e züst t ámogatója va n, t ovábbá konz orciumok ( pl. ba nkok csoportja, a z X O rganisation 14 i ntézménnyel, a P KI f órum 85 i ntézménnyel) i s t agok a szervezetben. Az ut óbbi é vekben á talakult a t erminológia é s a m inõsítési r endszer. A C AE s pecifikációk helett m a T echnical S tandards k ifejezésekkel e mlítik az el fogadott s zabványokat, az X PG minõsítés helyett az Open Brand márkajel megszerzés minõsíti a termékeket. Az XGG-kben használatos profil és komponens

terminológiát felváltotta a Product Standards kifejezés. A l egfontosabb m egszerezhetõ m inõsítések a U NIX 95 ( a S pec 1170 -bõl k ialakított S ingle Unix Specifikáció ma már ez), ennek továbbfejlesztett változata a UNIX 98, ez utóbbi alestei: UNIX 98 Workstation és Server minõsítés. Bõvebb leírásokat találhatunk a http://www.opengrouporg/ címrõl kiindulva 10. A MACH operációs rendszer Õse a CMU (Carnegie Mellon Univetsity) Accent operációs rendszere. Miután a 42 BSD-ben fejlesztették, a M ach release 2-ig kompatibilis volt a BSD-vel. A Mach Release 3 a B SD és egyéb op erációs r endszerek f unkcióit a M ach k ernelbõl " kimozdították", létrehozva a M ach microkernelt, a mi f ölé egy s or op erációs r endszer ( 4.3BSD, H PUX, OSF/1, O S2 s tb) szolgáltatásai tehetõk. Ez a koncepció hasonlít a virtuális gép (virtual machine) koncepcióhoz, de itt a virtuális gép a Mach mikrokernel, mint szoftver, nem pedig hardver.

10.1A fejlesztési elvek, célok • Egyszerû k ernel s truktúra, v iszonylag k evés s zámú ab sztrakcióval, ez zel s zemben ezek a z a bsztrakciók l ehetõvé t eszik, hog y a M ach f ölé m ás ope rációs r endszereket implementáljanak. • Különbözõ architektúrák támogatása, beleértve a különbözõ fokú osztott memóriával (Uniform M emory A ccess, N on-Uniform M emory A ccess, N o r emote M emory Access) rendelkezõ többprocesszoros rendszereket. • Különbözõ há lózati s ebességekhez v aló a lkalmazkodás ( a W AN-tól a LAN-on keresztül egészen a szorosan kapcsolt multiprocesszoros rendszerekig). • Elosztott ope rációk, há lózat t ranszparenciával, t ovábbá kül sõleg é s belsõleg i s objektumorientált szervezés. • Am emóriamenedzsment és ap rocesszközti k ommunikáció i negrálása (kommunikációbázisú m emóriakezelés). A k ommunikáció í gy ha tékony n agy adatmennyiségnél is, a

memóriamenedzselés pedig kommunikáció alapú. • Heterogén r endszerek t ámogatása. A M ach í gy s zéles k örben al kalmazható, a legkülönbözõbb s zámítógépgyártók gépei s zóbajöhetnek, a l egkülönbözõbb g épek együttmûködése is biztosítható. A BSD (általában Unix) örökségek, mint célok: • Egyszerû és konzisztens programozói interfésze legyen, amit a Unix-ban megszoktunk • Sok segédprogram, könyvtári rutin segítsen, amiket a Unix-ban már megszoktunk. • Segédprogramok együtmûködése csõvezetéken (pipe) keresztül biztosított legyen. • Könnyû legyen a telepítése egyprocesszoros rendszerekre is. 10.2 Alapfogalmak, rendszerkomponensek A f ejlesztési cél okat el érendõ, a f ejlesztõk a M ach k ernel funkcionalitását né hány a lapvetõ absztrakt kom ponensre " építették". E zekbõl a z é pítõkövekbõl l eszármaztathatók a t ovábbi funkciók. Elsõsorban a kommunikációs

lehetõségekre koncentráltak, erre ugyanis sokminden "építhetõ": p l. E gy k ernel s zolgáltatás k érés kommunikációs ké rés l ehet, pr ocesszek köz ti adatmozgatás szintén kommunikáció, s.ít Ezzel a védelem is egyszerûbb, a kommunikációs mechanizmusok vé delme e gyben rendszer-széles vé delmet a d. G ondoltak a kiterjeszthetõségre i s, s ok t radicionális ke rnel szolgáltatás f elhasználói s zintû s zolgáltató processzként m egvalósított. T ipikus pé lda e rre a lapozó (pager), m ég az al apértelmezés szerinti pager is "külsõleg" implementált, továbbá nem okoz gondot, hogy a felhasználók saját ki-belapozókat i mlementáljanak. A M ach az obj ektumorientáltság pé ldája i s O bjektumokba zártak az ad atok és az ad atmanipulációk, elrejtettek a r észletek, a megvalósítások. A programozó a z obj ektumok e xportált ope rációit ha sználhatják, a mi t ulajdonképpen e gy interfész de finíció.

R áadásul, a z obj ektumok - transzparensen a f elhasználó s zámára - a hálózaton a kárhol l ehetnek! M indezeket a port mechanizmus b iztosítja: a z o bjektumokat portjaik reprezentálják. Melyek a Mach primitív absztrakciói? A taszk: ami a v égrehajtási környezet, az erõforrás kiosztás (resorce allocation) alapegysége. A t aszkhoz t artozik a v irtuális c ímtartománya. Portokon ke resztül vé dett m ódon é rhet e l rendszer erõforrásokat. Egy taszk több fonalat (thread) tartalmazhat A fonál (thread): a v égrehajtás al apegysége ( basic u nit of e xecution). E gy f onál e gy t aszk kontextusában fut (a taszk biztosítja a címtartományt). Egy fonálnak saját regiszter-kontextusa és veremtára van. E gy t aszkon be lüli f onalak os ztoznak a t aszk e rõforrásain ( portokon, memórián s tb.) V agyis a ha gyományos p rocessz f ogalom itt n incs me g, az itt e gy ta szk egyetlen fonállal. A port: a z a lapvetõ obj ektum hi vatkozási m

echanizmus. K ernelvédelmû kom munikációs csatornaként van megvalósítva. A kommunikáció: üzenet küldése egy portra A cél-porton az üzenet sorban (queued) áll, amíg egy fonál kész nincs fogadására. Kernelmenedzselt védelmi mechanizmus a port right: egy taszknak kell legyen port joga, hogy az adott portra üzenetet küldhessen. A pr ogramozó ke zdeményezhet e gy operációt e gy obj ektumon, kül dve e gy üzenetet arra a p ortra, ami kapcsolatban van ezzel az objektummal (object assocaited to that port). Az az objektum, melynek reprezentációja ez a p ort, fogadja ezt az üzenetet (it receives message). Port készlet (port s et): portok c soportja köz ös ü zenetsorral. Egy f onál k aphat üz enetet por t készletrõl, e zzel többszörös por t ki szolgálást va lósít m eg. M inden m egkapott üz enet azonosítja az egyedi portot (a készleten belül), vagyis hogy honnan kapta az üzenetet, így az üzenetfogadó használhatja az azonosítást az objektum

referenciára. A üzenet (message):alapvetõ m ódszer a f onalak kom munikációjára. A z üz enet adatobjektumok g yüjteménye ( typed c ollection of da ta obj ects), t artalmazhatja a z a ktuális adatokat, v agy m utatót az a ktuális a datokra. A por t j ogok átadhatók üzenetekkel, ez az egyetlen mód létezik taszkok közötti portjog átadásra. Osztott memóriára portjog átadás nem létezik. A memória objektum (memory object): memória erõforrás. Egy taszk elérheti, ha leképzi azt (teljesen, v agy r észben) a s aját cí mtartományára. E gy m emória obj ektumot külsõ memória menedzser (external m emory m anager) i s m enedzselhet, n emcsak az al apértelmezésben megvalósított me nedzselõk. M emória o bjektum l ehet b ármely objektum, a minél a me mória leképzéses elérésnek van értelme. Például a cs õ (pipe) bufferbe való leképzés implementáció ilyen. Külsõ memória menedzser pl egy fájl szerver, ennél egy fájl is ilyen objektum

Az 1.10 ábra illusztrálja ezeket az absztrakciókat 1.10 ábra Mach absztrakciók Szokatlan l ehet a M ach memóriakezelésének és a k ommunikációs m echanizmusainak ez az összeépülése, a zaz ho gy egyik a m ásikkal m egvalósított, de ez a dja a a M ach kül önös hatékonyságát. A m emóriamenedzselés a memória objektumokra alapozott. A m emória obj ektumokat port (vagy por tok) r eprezentálja(ják). IPC üz enetet kell kül deni e rre a po rtra ( portokra), ha valamilyen operációt akarunk megvalósítani a memória objektumon (pl. ki- vagy belapozást) (És m iután IPC ü zenetet h asználunk a k érelemhez, a m emória o bjektum l ehet ak ár m ás csomóponton is el helyezve, ez t ranszparens m arad.) U gyanakkor az ü zenetváltások implementációjára m emória m enedzselési t echnikákat h asznál a M ach: ahol cs ak l ehet, az üzenetekben csak hivatkozások mozognak, hivatkozások az osztott memóriára, nem pedig az adatok maguk. Ha úgy tetszik:

az üzenet fogadás a fogadó taszk címtartományának átképzése (remapping), a f ogadó t aszk cí mtartományának o lyan m egváltoztatása, h ogy az ú j címtaromány a fogadott üzenetet is címezi (virtual copy technique). 10.3 A Mach processz-menedzselése A t aszk e lképzelhetõ e gy hagyományos pr ocesszként, a minek ni ncs r egiszterkészlete ( nincs PC/PSW). Azaz egy passzív entitás Nem csinál semmit, ha ni ncs fonál b enne V an vi szont virtuális címtartománya. Taszk egyetlen fonállal: ez a hagyományos Unix processz Taszk kreáció. Taszk fonala (fork hívással) kreálhat új taszkot A gyermek címtartománya a szülõ duplikátuma (ahogy ezt az öröklõdési attribútumok diktálják). A gyermekben egy fonál fut (a kreátor fonál), ugyanazon a ponton, azaz a fork-ból tér itt is vissza. Fonál kreáció. T aszkon b elül f onál k reáció is l ehetséges, v alamint f onál me gszüntetés is , természetesen. A f onál a bsztrakció kül önösen

ha sznos s zerver a lkalmazásokban: a fonáltöbbszörözés s zolgáltatás t öbbszörözést a dhat. A kül önbözõ f onalak különbözõ processzorokon futhatnak. Egy fonál laphibája csakis ezt a fonalat függeszti fel, a többi fonál tovább f uthat a t aszkon be lül. T ermészetesen, a f onalazásnak á ra i s v an: pl a z üt emezés bonyultabb többfonalas rendszerekben, így a Mach-ban is. A fonalak állapota. Felhasználói szinten a fonalaknak két állapota lehetséges: • futó (running) állapot, • és felfüggesztett (suspended) állapot. A futó állapotú fonál l ehet végrehajtás alatti (övé eg y C PU), l ehet CPU-ra várakozó (arra vár, ho gy C PU-t a llokáljanak ne ki), de l ehet, ho gy a kernelen belül blokkolt (azaz al lokált hozzá e gy C PU, de pl . é ppen l aphiba m iatt v árakozik) A zaz a f utó á llapot t ényleg a felhasználói s zintû né zõpont. A felfüggesztett állapotú f onál n em a rra vá r, ho gy C PU-t

allokáljanak neki, és nyilván nem is fut egy CPU-n. A fenti két állapot a taszkra is értelmezhetõ. Taszk felfüggesztése azt jelenti, minden fonala felfüggesztõdik. F utó t aszk e gyes f onalai pe rsze m ég l ehetnek f elfüggesztettek M iután a fonal és a t aszk f elfüggesztés-futtatás ( suspending-resuming) f üggetlen m echanizmusok, felfüggesztett taszk fonalának futtatható állapotba hozása (resuming a thread of a suspended task) nem jelenti a taszk futtathatóságát. A C Threads Package A rugalmas, de alacsony szintû fonálkezelõ rutinok mellet természetes, hogy a magas szintû nyelvekehez - pl a C -hez - készítettek f onálkezelõ i nterfészt: ez a C T hreads P ackage R TL készlet. B iztosítja a f onálkezelést, a s zinkronizálást, a kül csönös ki zárási m echanizmusokat Nagymértékben megfelela POSIX P Threads szabványnak. Segítségével megvalósítható: Egy új fonál készítése egy t aszkon belül, egy függvényt és a

rgumentumait m egadva a fonál számára. A kreátor fonál megkapja az új fonál azonosítóját, az új fonál a párhuzamosan fut a kreátorral. Egy fonál megszüntetése (destroy), és érték-visszaadás a kreátor fonálnak. 10.4 A kölcsönös kizárás mechanizmusai Általában spinlock-on át. • mutex-alloc() • mutex-free() • mutex-lock() • mutex-unlock() rendszerhívások vannak. Egy spinlock lehet feltételváltozó • condition-alloc() • condition-free() • condition-wait() • condition-signal () rendszrhívások vannak. 10.5 A CPU ütemezés • Bonyolultabb a fonalak miatt (sok fonál, sok CPU) • A fonalak ütemezhetõk. • 0-127 pr ioritásszintet ka phatnak, a C PU ha sználat e xponenciális át lagától függõen(aging a CPU használatra). • 32 globális futási sor van, • minden CPU-nak lokális sora is (CPU-hoz dedikált fonalaknak). • A "szûkebb" scheduler: • dinamikus prioritásokat számol és

• felfûz a globális/lokális sorokra. A CPU-k allokálása Nincs központi diszpécser. Minden CPU kéri a lokális sort (majd a globális sorokat), választ fonalat futtatásra. Van lista az üres (idle) processzorokról is. További érdekesség Az idõ-szelet (time-slice) nem fix érték. kevesebb fonál: nagyobb idõszeletek (ne kelljen lejárt idõszetenél ugyanazt a fonalat vizsgálni és visszadni neki a CPU-t). 10.6 A kivételkezelés Támogatott a default és a felhasználó által definiált kivételkezelés. A kezelõ (handler): egy fonál egy/a taszkban. Az "áldozat" fonál fogalom. IPC mechanizmussal társalog az áldozat és a kezelõ fonál. A kezelés granulatitása: taszkonkénti kezelés (a debuggerekhez kell). A kezelõ a szülõ taszktól örökölt Fonalankénti kezelés. Nincs örökölt kezelõ: lehet a default, lehet saját A kivételkezelés forgatókönyve Az áldozat fonál IPC üzenetet küld a handlernek. Utána vár, amíg lekezelik az

eseményt A handler üzenetben kapja a kivételrõl, a küldõ taszkról, fonálról az információkat. A handler kezel a kivételnek megfelelõen: "tisztítja"a kivételt és visszabillenti az áldozatot a várakozásból (szignáloz neki, ez is üzenet), vagy terminálja az áldozatot. 10.7 A MACH memóriakezelése Memória obj ektumok ( régiók, reprezentálhatnak a datokat, d e f ájlokat, c söveket i s) a t aszk címtartományára leképezve. Ebben azonosított a memória-menedzser (portjával), és a másodlagos tároló objektum (a portjával). Címtartomány l eképzése ( egy s ystem cal l-lal) l ehetséges ( megadni a m enedzser és a másodlagos tároló objektum portjait is). Futás során jöhet a címleképzés. Érvényes cím a régióban leképzõdik. És ha laphiba van? Laphiba Laphiba esetén üzenet a megfelelõ memóriamenedzsernek, tegye érvényessé. Közben a kilapozás: a memória menedzser üzeneteket küld a másodlagos tároló

objektumnak, kérve a ki/belapozást. És a fájlrendszer? I/O, fájlrendszer nincs a MACH-ban! Csak memóriamenedzselés! Az egyébb I/O-t, a fájlrendszert a MACH fölé telepített operációs rendszerek oldják meg! 11. Az MS DOS operációs rendszer Azért érdemes vetni egy pillantást rá, mert nagyon eltejedt (különösen eltejedt Középeurópában, így hazánkban is). 11.1 Használata A g ép be kapcsolásával be töltõdik a z M S D OS. Nincs e llenõrzött ülés létesítés, me rt s zemélyi használatra t ervezték. U gyanezért n incs f ájlvédelem s em, n incsenek t ulajdonossági és v édelmi kategóriák, általában a védelem hallatlanul gyenge az MS DOS-ban. Betöltõdése után a COMMAND.COM burokértelmezõ a legegyszerûbb felhasználói felülete Az 5.0 verziótól ke zdve l étezik a D OSKEY pr ogram, a mi buf ferezi a bi llentyûzet l enyomásokat, ezzel a kor ábban be gépelt pa rancsokat "elõhívhatóvá" t eszi. A D OSKEY u gyanakkor

billentyûkombinációkhoz p arancsmakrókat i s k épezhet l e, ez zel a p arancsnyelv a f elhasználó által átkonfigurálható. Létezik GUI is a DOS-hoz, ez a DOSSHELL. Újabb MS DOS-ok azonban nem támogatják, az MS W INDOWS új abban a z e lfogadott f elhasználói f elület ( ez azonban m ár kül ön megvásárolandó termék). 11.2 Implementációja, konfigurálása Az MS DOS három rétegbõl álló szerkezetû: 1. A BIOS (Basic Input Output System) 2. Maga a kernel 3. A burok A BIOS alacsony szintû eszközkezelõ rutinok összessége. Elválasztja az MS DOS-t a hardvertõl Általában a gépet eladó cég szállítja, ha úgy teszik a hardverhez tartozik. Szokás szerint az 1M címtartomány alatti 64K-s ROM-ban van. A rutinjai IT megszakításokkal hívhatók A rendszerlemezen két fájl (IO.SYS és MSDOSSYS) tartalmazza a kernelt Ezek be töltõdnek, a mint a s zámítógép " boot"-ol. Az IOSYS e ljáráshívás je llegû in terfészt biztosít a B IOS-hoz

( azaz s egítségével a B IOS el érhetõ h ívásokkal), esetleg k iegészítéseket, javításokat a BIOS rutinokhoz, illetve tartalmazza az sysinit modult, amit a bootoláskor használ a rendszer. K érdés m erülhet f el b ennünk: az I OSYS a B IOS k iegészítése, v agy m ár a k ernel része? N os, m indkét e lgondolás m ellett l ehet é rveket f elsorakoztatni!. H a a z e lsõ de finíciót vesszük, akkor az IO.SYS szerepe, hogy még jobban elszigetelje a k ernelt (ebben az esetben az MSDOS.SYS-t) a hardvertõl A második definícó szerint modhatjuk, hogy ez már a kernel gépfüggõ része. Az M SDOS . SYS t ényleg az o perációs r endszer g épfüggetlen r észét t artalmazza Itt t örténik a processz m enedzsment, a m emória m enedzsment, a f ájlrendszer m egvalósítás, és a rendszerhívások értelmezése is. Bootoláskor a sysinit modul in icializálja a h ardvert, o lvassa a C ONFIG.SYS f ájlt, h ogy konfigurélja a rendszert (allokáljon buffer c

ache-t, betöltsön driver programokat s tb.), végül ez tölti be a COMMAND.COM-ot A harmadik réteg - megint csak kérdés, része ez az operációs rendszernek, vagy sem - a burok értelmezõ, szokásosan a COMMAND.COM A standard COMMANDCOM két részbõl áll: egy rezidens r észbõl, a mi mindíg a m emóriában van, é s egy t ranziens r észbõl, a mi s zokásosan koncvencionális memória magasabb végére töltõdik., és a felhasználói processzek felülírhatják, ha s zükságük va n m emóriára. ( Amikor a ve zérlés vi sszajut a COMMANDCOM r ezidens részére, és az észreveszi, hogy felülírták a tranziens részét, újratölti azt. Meglehetõsen sok "technika" van arra, hogy a felhasználó konfigurálja a rendszert. A DOSKEY-t már említettük is. A r endszerbetöltéskor végigolvasott C ONFIG.SYS f ájl s oraiba kon figurációs pa rncsokat írhatunk: Eszköz drivereket i lleszthetünk a rendszerhez, akár nem s zabványos eszközöket i s

kezelhetünk ezután. Nemzeti nyelv támogatást konfigurálhatunk: * billentyûzet és karakter-kód le/átképzést, * karakter-kódokhoz különbözõ karakter bit térkép leképzést, * dátum és idõ formákat, Megszabhatjuk, hova tegyük a kernelt a memóriában, és hogy legyen-e buffer cache, mi legyen a burok stb. A r endszerbetöltés v égén az A UTOEXEC.BAT f ájlt - ami p arncssorokat t artalmazhat feldolgozza a bur ok, e zzel a konf igurálás ut olsó l épéseit i s m egtehetjük ( pl T SR pr ogramokat indíthatunk). 2 11.3 Processz koncepció az MS DOS-ban Az eddig kialakult processz fogalmat kicsit át kell értelmeznünk. Az M S D OS ne m i gazi m ulti pr ogrmming r endszer, de l átni f ogjuk, ne m i s igazi m ono programming, valahol a kettõ között jellemezhetõ. Mikor a rendszer elindult, a burok (COMMAND.COM) betöltõdik és mint processz fut Kiadja a promptját, beolvas parancsot, azt végrehajtja. Ha a parancs belsõ, akkor végrehajtja Ha a zonban

kül sõ p arancs, i ndít e gy gyermek pr ocesszt, a miben a p arancs v égrehajtható programját f uttaja: át adja en nek a v ezérlést, megvárja, am íg l efut. Ebben az i dõben t ehát legalább két processz van a memóriában, a szülõ burok és a gyermek, de csak a gyermek aktív. A szülõ és a gyermek nem párhuzamosan fut, csakis egy processz lehet aktív egy idõben. Látni f ogjuk, ki s c salással kor látozott f okú multiprogramozást va lósíthatunk m eg ( TSR programok), amihez kell az a tény, hogy nincs memóriavédelem az MS DOS-ban. 11.31 A COM és a EXE fájlok Az M S DOS -ban k étfajta v égrehajtható pr ogram f ájl f orma l ehetséges, é s e zek kül önbözõ processzeket eredményeznek. A .C OM f ájlok - a m odell a C P/M ope rációs r endszerbõl ör öklõdött - egyszerû v égrehajtható programok, ni ncs f ejük ( header), csakis e gy szegmensbõl á llhatnak, hos szuk 64K l ehet. Processzként betöltõdve a kontextusuk egy az egy

másolata a fájlnak, a text-data-stack szegmens hossza 64K alatti, mégis, mint processzek, allokálják a teljes lehetséges memóriatartományt. Ha egy i lyen pr ocessz ne m ké szít g yermeket, ni ncs i s g ond. Ha azonban szándékszik ké szíteni, elõtte az ál tala n em h asznált m emóriarészt v issza k ell ad ja az o perációs r endszernek (ezt megteheti egy rendszerhívással). Ha nem "szabadít" fel memóriát, a gyermekének nem lesz hely a futásra! A m ásik vé grehajtható pr ogram f ájl f orma az . EXE f orma A z e bbõl a f ájlból k észített processznek l ehet k ülön t ext, k ülön d ata és s tack s zegmense. A p rocessz k észítése ( betöltése) során relokáció történik. A z EXE f ájlnak v an f eje ( header) A k ernel n em a fájlnév kiterjesztésbõl, hanem a fájlok elsõ két bájtjából döntik el, melyik fájlformáról is van szó. Az e lsõ 256 bá jtja a pr ocesszeknek - akármelyik f ormából is k észültek - az ún.

P SP ( Program Segment P refix). E z a konc epció i s C P/M ha gyomány A P SP-t a k ernel k reálja, am ikor a processz készül. 3 .COM fájlokból készült processzeknél a PSP a processz címtartományának része, a processzbõl a 0-255 címekkel meg is címezhetõ. Ezért minden ilyen processz a 256-os (x80) címen kezdõdik Ezzel ellentétben, az .EXE processzek a P SP-jük fölé töltõdnek, a P SP nem tartozik a p rocessz címtartományába, kezdõ címük pedig a PSP-jüket követõ elsõ cím, saját címtartományukban a 0. A P SP t artalmazza a pr ogram m éretét, m utatót a kör nyezet ( environment) bl okkra, a C TRL-C handler címét, a parancssor szövegláncot, mutatót a szülö processz PSP-jére, a fájlleíró táblát és egyéb információkat. A k örnyezet b lokk eg y m emóriarész ( a p rocesz cí mtartomány al ján v alahol), am iben burokváltozó de finíciók va nnak vá ltozó= szöveg f ormában, m indegyik definíció 0 ka rakterrel

terminálva. Ez nagyon hasonlít a Unix megoldásához A C TRL-C h andler cí mét a p rogram l ecserélheti. A k ezelõ akkor l ép m ûködésbe, h a C TRL-C megszakítást adunk a processznek. A p arancsor s zöveglácban a p arancs n eve l e v an v ágva, a m aradék s zavak - akár o pciók, a kár fájlnevek megtalálható, és a p rocessz feldolgozhatja ezeket. Pl a d zsóker karaktereket kifejtheti stb. E bben va n kül önbség a U nix-hoz ké pest, h iszen ot t a bur ok e lõbb ki fejti a dz sókereket, azután adja át a parancssort a processznek. A gyermek processz normálisan örökli a nyitott fájlokat a szülõtõl (a PSP-ben lévõ leírótáblát). A gyermek által nyitott fájlokat a szülõ, amikor visszakapja a vezérlést, természetesen nem látja nyitottaknak: e gyrészt a gyermek má r te minálódott, a zaz n ormális e setben be i s z árta az ál tala nyitott fájlokat, másrészt a technika sem tenné ezt lehetõvé (normálisan), hiszen a leíróátbla nem

másolódik vissza a gyermektõl a szülõbe. Miután az M S D OS-ban ni ncs ki söprés va gy kilapozás, f ennáll a v eszély, ho gy gyermek készítése során n incs el egendõ m emória a gyermek s zámára. E zért az o lyan p rogramokat, melyek valószínûleg szülnek gyermekeket, gyakran két részbõl konstruálják. Képzeljük el, hogy használunk e gy s zövegszerkesztõt, a mi " kimenekülhetünk" pa rancsértelmezõhöz, pé ldául azért, hogy szerkesztés közben formattáljunk egy floppy lemezt. A kimenekülés után vissza is akarunk térni, a nélkül, ho gy e lvesztenénk a s zerkesztett s zöveget. A 111 árán l áthatjuk, a pr ocesszek hogyan foglalják el a memóriát, és láthatjuk az editor különös struktúráját. Az ábra (a) részén, kiinduláskor a COMMAND burok processz van a memóriában és fut. Indítja a gyermekét, az EDITOR-t (b), aminek van egy rezidens (a memóriában maradó és egy tranziens része. Az editorból i ndított új

abb burok m ár ne m férne a m emóriába, d e s zerencsére az ed itort úgy k észítették, h ogy a t ranziens r észét - miután v alahogy le menti a zt, p l. d iszkre, h ogy e l n e veszítse a s zerkesztett szöveget - felszabadítja tranziens részét, és erre a t erületre, gyermekeként 4 betölti az újabb burkot (c ábrarész). Az újabb burokból indítható a format processz (d ábrarész) Miután ez b efejezi a m unkáját, f elszabadulva a m emória, v isszadódik a v ezérlés a m ásodik buroknak. Ebbõl is visszalépve (rendszerint ennek a buroknak adott EXIT paranccsal), a vezérlés visszadódik a s zülõnek, i tt a z e ditor r esidens r észének. E nnek pi llanatnyi f eladata, ho gy visszakapott memóriába visszatültse a lementett tranziens részét, és akkor futhat tovább. 11.1 ábra Több processz a memóriában Normális e setben, a mikor e gy pr ocessz t erminálódik, a z á ltala f oglalt m emória vi sszadódik a rendszernek. Van azonban egy

másik módja is a terminálódásnak, amikor is a processz nem adja vissza az általa foglalt memóriát: aza processzként bennmarad a m emóriában. Ez a t echnika ad lehetõséget a TSR (Terminate and Stay Resident) programok írásának. Elsõ pillantásra haszontalannak tûnik a TSR processz, hiszen foglalja a memóriát, de nem látjuk, hogy i s k aphatja m eg a ve zérlést. T udjuk azonban, hog y bármely pr ocessz á tírhatja a rendszerterületeket i s, p éldául a m egszakítástáblát. A T SR p rogram ak tiválására a b illentyû megszakítást szokták átírni. A TSR-be beírnak egy kis kódrészt egy adott címre, ami billenntyû megszakítás k ezelõ k egészítés: v izsgálja, h ogy a le ütött b illentyû "hotkey"-e a T SR aktiválásához. Ha igen, a vezérlést a T SR megfelelõ pontjára adja, ha nem, meghívja az eredeti billentûmegszakítás r utint. V annak pe rsze gondok a z i lyen pr ogramozásnál H ivatalosan ne m dokumentáltak a z i de

t artozó r endszerhívások. Gond l ehet azéppen futó pr ocess f elhasználói felületének, a ké ppernyõje t artalmanák l ementése s tb., de e gy e gész i parág épült ki a T SR programok írására. 5 A pr ocesszekben a P SP-knek j elentõs s zerepe v an. E gy belsõ rendszerváltozó m indíg a z a ktív processz PSP-jére mutat. Ennek PSP-jében egy mutató a szülõje PSP-jére és így viszavezethetõ a lánc a z õs szülõ bur ok pr ocesszig. N incs t ehát p rocessz t ábla, m int a hogy a zt m egszoktuk m ás operációs rendszerekben. 11.4 Az MS DOS memóriamenedzselése Meglehetõsen komplikált. Ennek oka az alatta lévõ hardver A címtartomány 4 elkülönült területre oszlik, ezeknek különbözõ jellemzõik, méretük van. A c ímtartomány m ögött kül önbözõ konf igurációban ül önbözõ na gyságú e gységekbe l ehet memória. 11.2 ábra MS DOS memória területek A r égebbi P C-ken a 0 -640K cí mtartomány m ögé t ehettek az al

aplapra s zerelve m ondjuk 2*256K-s R AM l apkát: ekkor a z 512K és 640K c ímek m ögött n em vol t m emória. A 640K -n kezdõdõen a vi deokártyára s zerelt vi deo R AM vol t, u tána hé zagokkal e gyéb I /O kártya memóriák. Az 1M cim alatt az alaplapra szerelt ROM-ban vannak a BIOS rutinok Manapság már nagyobb kapacitású csipek az alaplapon lefedik a t eljes 1M címtartományt. Ettõl "függetlenül" a 640K fölött ott van a videokártya RAM-ja, és a R OM is: vagyi ugyanazon cím mögött két, sõt több memória is lehet. (Természetesen megvan szabva, melyik memóriát éri el a processzor, ha egy címe mögött több memóriarekesz is van). 6 Az MS DOS-ban a processzor - akármilyen is az - valós módban dolgozik, amikor is a 20 b ites címzés egy 16 bites szegmens regiszter és egy 16 bites eltolásérték speciális összege: a szegmens regiszter a 2 0 b ites cím ma gasabb r endû 1 6 b itnyi címrészét ta rtalmazza, a mihez a z eltolás

hozzáadódik m ég. 0 el tolásértékkel a s zegmensregiszter t artalma a 2 0 b ites cí m m agasabb helyiértékû bitjeire kerül, a kis helyiértékû 4 bi ten pedig 0 va n: ez azt jelenti, hogy pusztán a a szegmens r egiszterekkel a cí mtartomány és a m emória 1 6 b ájtos eg ységekben cí mezhetõ, n em pedig bá jtokban. E zeket a 16 bá jtos e gységeket sz okásos i s paragrafusoknak (paragraph) nevezni. A pr ocesszor a karmilyen c ímet, amit e lõ t ud állítani ki adhat a bus zra, de a z, ho gy e m ögött milyen k ontextus v an, az t már az o perációs r endszer m emóriamenedzselõjének k ell nyilvántartania. Az M S DOS memóriamenedzselésében - processzek l áncolásához h asonlóan - láncolási technikát a lkalmaznak. A m emória f el va n os ztva f olyamatosan ös szefüggõ bl okkokra, ún arénákra. M inden aréna pa ragrafus ha táron ke zdõdhet, é s e gész s zámú pa ragrafusnyi e gységet foghat össze. M inden a réna 16 bá jtos a

réna-fejjel ke zdõdik A z a réna-fejben - egy "m ágikus" szám (ha kell, ezzel ellenõrizhetõ, hogy valóban aréna fejrõl van szó) után van egy mutató arra a PSP-re, amelyiknek processze allokálta az arénát, vagy pedig 0 érték, ami azt jelzi, hogy az aréna szabad. U tána ot t va n a z a réna hos sza ( A f ej vé gén a z ol yan a rénknál, m elyekbe pr ocessz töltõdött be , ot t va n a vé grehajtható f ájl ne ve. A z alloc jellegû r endszerhívással a llokált arénáknál ez a mezõ üres.) Technikailag az a rénák nem l áncolt l isták, hi szen a következõ aránára n em m utató m utat, de a következõ aréna kezdete az aréna hosszából és kezdõcímábõl kiszámítható. Az M S DOS -ban ké t e setben a llokálhatunk m emóriát. E gyik e setben p rocessz kr eációkor, a másik esetben pedig egy processzbõl az alloc jellegû rendszerhívással. Mindkét esetben tudja a rendszer, hogy mekkora területre van igénye. Ilyenkor az

"aréna-láncot" elejétõl fogva végignézi, és az elsõ szabad és el ég nagy arénát lefoglalja: pontosabban kettéosztja, lehasítva a szükséges nagyságú ar énát, am it f oglaltnak i s j elez, l ecsökkentve a m aradék s zabad aréna m éretét. M ikor egy aréna f elszabadul, a f ejében egyszerûen j elzik e zt a t ényt. e bbõl köve tkezik, hog y a szomszédos s zabad a rénák ne m k apcsolódnak ös sze e gyetlen na gyobb a rénává, a mikor memóriafelszabadítás v an. E nnek l ogikus köv etkezménye, ho gy a z arénatér elõbb ut óbb szegmentálódik. Nos, a szomszédos szabad arénák összevonása a memória allkoálásnál történik Ez az aréna séma átfogja a konvencionális és a felsõ memóritarületet is. 7 11. 5 Fájlrendszer megvalósítás A diszkfelépítés - itt is megvan a logikai diszk koncepció - nagyon egszerû: a boot blokk után található a valamennyi blokknyi FAT (File Allocation Table), utána a gyökér jegyzék,

majd az adat blokkok. A FAT szerepét már tanultuk, itt nem ismételjük A jegyzék (directory)bejegyzések szerkezete a 11.3 ábrán látható: 11.3 ábra Directory bejegyzés Sikeres fájl nyitás után a nyitott fájl dir. bejegyzése a rendszer fájl táblájába másolódik, amit a processz PSP-jében lévõ leíró indexel. 8 11.6 A driver-ek szerkezete Az eszköz driver programok szerkezete a 11.4 ábrán látható 114 ábra Driverek láncolt listája A C ONFIG.SYS s oraiban a de finiált dr iverek be töltõdve a 11 4 áb ra s zerint eg ymás el é láncolódnak: a késõbben installált driver a lista elejére kerül. Amikor a driverek láncát véggnézi a rendszer, a lista elején kezdve keresi az elsõ megfelelõ drivert. Az attribútum szó jobb szélsõ bi tjeivel jelezve van, vajon a driver az s tdin, az s tdout, a nul l, a clock drivre-e (a keresés gyorsítására). 9