Vizsgatételek

Országok listájaHungaryMiskolci EgyetemGépészmérnöki és Informatikai KarProgramtervező informatikusOperációs RendszerekJegyzetekVizsgatételek

Operációs Rendszerek c. tárgyból
témakörök a szigorlathoz
2001/2002 tanév



OS struktúrák

Operációs rendszerek fogalma, történetük.
Direkt futtatás a hardveren, monitor programok, operációs rendszer-osztályozások.
Operációs rendszer struktúrák, nézQpontok a strukturáláshoz.
Monolitikus struktúrájú, réteges struktúrájú operációs rendszerek.
Virtuális gép struktúra. Kliens-szerver struktúrájú operációs rendszerek.
Window NT operációs rendszer struktúra.
Unix struktúra. OS2 struktúra.
A kernelbe való belépés, kilépés.

Processz koncepció

A folyamat (processz) koncepció. A processz kontextus.
UNIX processz kontextus adatstruktúrák.

Processz kontroll

A processz kontrol, a folyamatkészítés rendszerhívásai, folyamatkészítés Unix-ban.
Processz állapotok, állapotátmenetek, futási módok. Informálódás processz állapotokról.
Munka (job), feladat (taszk), folyamat (processz), fonál (thread), rutin, utasítás, instrukció fogalmak. Taszk- és fonál állapotok.
Processzek az MS-DOS-ban. Taszkok, fonalak az NT-ben.

Események, szignálozás

Hiba és eseménykezelés, alapfogalmak.
Megszakítások és kivételek összehasonlítása.
Szignálozás rendszerhívásai. Szignál diszpozíció, szignál-küldés, kezelés.

Ütemezés

Processz ütemezés (scheduling), CPU kiosztás (context switch). Elvárások, technikai alapok, stratégiák.
Az óraeszköz. Megszakítás-kezelQjének feladatai.
Ütemezési algoritmusok: FCFS, SJF, és a prioritásos algoritmusok.
Ütemezési algoritmusok: ígéretvezérelt, Round Robin, többszintes, visszacsatolásos.
Ütemezési algoritmus a Unixban.
A VAX/VMS és az NT ütemezési algoritmusa.
CPU allokálás, Process Context Switch fogalom, egy lehetséges algoritmusa.


IPC, msg, shmem

Folyamatok közötti információcsere. Alapfogalmak, elvek.
Indirekt kommunikáció jellemzQi.
IPC mechanizmusok, jellemzQik, összehasonlításuk.
Unix üzenetsor kezelés.
Unix osztott memóriakezelés.

Kölcsönös kizárás

Kölcsönös kizárás, kritikus szakasz, holtponthelyzet. Alapfogalmak, követelmények, problémák.
Mechanizmusok a kölcsönös kizárásra: IT letiltás, processzek váltogatása, érdekeltsége, a "bakery" algoritmus.
Mechanizmusok a kölcsönös kizárásra. Zárolásváltozó használata. A busy waiting hátránya.
Szemaforok: Dijkstra szemaformechanizmusa.
Szemafor implementációk (bináris és számlálós spinlock, blokkoló számláló).
Adott problémák megoldása szemaforokkal.
A sorszámosztó-eseményszámláló, a monitor. Problémamegoldások ezekkel a mechanizmusokkal.
A Unix szemafor mechanizmusa. Összevetés a klasszikus szemaforral.

Memóriamenedzselés

A memóriamenedzselés: alapok, a memóriamenedzselQ alrendszer feladatai (címtartományok - memória, allokáció, címleképzés)
Valós címzésq rendszerek. Memóriamenedzselés az MS-DOS-ban.
Virtuális címzés koncepció. Lapozás. Laptábla méret kezelés.
Kilapozási algoritmusok. FIFO, NRU-LRU, LFU-NFU algoritmusok.
Igény szerinti lapozás és a Working Set koncepció. A swap eszköz menedzselése.
Virtuális címzés koncepció: szegmensenkénti leképzés. Szegmentálás és lapozás.
Intel processzorok MMU-ja
Memóriamenedzselés az NT-ben. Virtuális címallokálás, címleképzés. A virtuális címleíró (VAD), a lapkatalógus, a laptábla, a prototípus laptábla szerepe.
Memóriamenedzselés az NT-ben. A fizikai memória nyilvántartása, keretállapotok és listák, a módosított lapíró. A munkakészlet.

I/O alrendszer

I/O egy felhasználó és egy programozó szemszögébQl
A Unix, az NT és a Linux I/O alrendszerei: funkcionális egységek
Eszközök osztályai. Eszköz-driverek, felépítésük, feladataik
Blokkorientált eszközök, logikai diszk, partíció, kötet
Unix eszközök szimbolikus nevei: a speciális fájlok, szerepük
A buffer cache (Unix esetén). Adatstruktúrák a buffer cache implementációban (bufferek listái)
A buffer cache (Unix esetén). A buffer allokálás (getblk) algoritmus. Az 5 tipikus forgatókönyv.
A buffer cache (Unix esetén). A bread és a breada algoritmusok, a brelse algoritmus.
FAT és VFAT fájlrendszer elérése DOS, DOS+Windows, W95 és NT alkalmazásokból



Fájlrendszerek

Fájlrendszer-implementálás alapvetQ feladatai
Fájlok és attribútumaik
Jegyzékimplementálási technikák. Szabad blokkmenedzselési technikák
Fájlokhoz való blokk-hozzárendelési technikák
Fájlrendszer-megvalósítás Unix-ban: partíciószerkezet, szuperblokk, i-lista, jegyzékek.
A Unix i-bög. Fájlkészítés forgatókönyv, fájltörlés forgatókönyv, i-bög allokálás-eleresztés, blokkallokálás-eleresztés.
Unix fájlrendszer létrehozás (mkfs), használatbavétel (mount, umount)
"Linkelés" a Unixban: hard link, soft link
A HPFS és az NTFS fájlrendszerek. Sávok, bittérképeik, jegyzékszerkezetük, f-bögük, kiterjesztéseik (extents)
Linux ext2 fájlrendszer. Blokkcsoportok, i-bög, jegyzékszerkezet.

Rendszermenedzselés

OS rendszermenedzser feladatai. Kockázatok és védelem
Kockázatok és védelem: azonosítás és hozzáférés. Védelmi tartományok. ACL és CL
A Unix védelmi rendszer. Tulajdonosságok és hozzáférések. A setuid koncepció
Felhasználók menedzselése. Számlaszámok, jelszóválasztás, kiosztás
A Unix számlaszám rendszer. Adatstruktúrák. Felhasználó felvétele és törlés Unix-ban
A NIS rendszer. A NIS adatbázisa, démonjai
Rendszerindítás (startup), leállítás. A Unix init processze
Unix fájlrendszer-készítés és használatbavétel. Fájlrendszer integritás helyreállítás (fsck)
Archiválás és visszatöltés. A tar a Unix-ban
A nyílt rendszer elv, az Open Group
Az Open Group UNIX95 és UNIX 98 specifikációi
A mach operációs rendszer




1.) Operációs rendszer fogalma, történetük


Az OS fogalma

Az operációs rendszer hasonlít egy kormányhoz, azaz maga nem teljesít valódi funkciót, de lehetQséget ad az alkalmazások hasznos tevékenységéhez. Van erQforrás kiosztó (Resource allocator) és vezérlQ (control program) szerepköre. Néha úgy szemléljük az operációs rendszert, hogy az azon programok gyqjtemé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. Az operációs rendszer egyrészt virtuális gép, másrészt erQforrás menedzser.

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 szintq operációkat biztosít. Az operációs rendszer elrejti a részleteket a felhasználó elQl, levesz bizonyos felelQsséget a felhasználó válláról, akár különbözQ architektúrákon is biztosítja helyettesíthetQségét, egységességet. Ha úgy tetszik, ebbQl a szempontból kényelmessé teszi (convenience for the users) az operációs rendszer a hardver használatot.

Az operációs rendszer  mint erQforrás menedzser - feladata, hogy elossza az erQforrásokat a gépen futó különbözQ, az erQforrásokért tulajdonképpen vetélkedQ programok számára.

Milyen erQforrásokat kell menedzselnie az operációs rendszereknek?
hardver erQforrásokat (processzorok, elsQdleges és másodlagos tárak, eszközök stb.),
szoftver erQforrásokat (AB, alkalmazások)
emberi erQforrást (felhasználók, operátorok, rendszermenedzserek stb.).

Ha úgy tetszik, ebbQl a szempontból az operációs rendszer hatékonnyá teszi (efficiency) a hardver használatát.



Az OS története

Az elsQ generáció (1945-1955): Csövek és dugaszoló táblák

Ezek szobákat töltöttek meg, nagy áramfelvételük volt -számolási teljesítményük sokkal kisebb, mint a mai legolcsóbb házi számítógépeké.
Ebben az idQben még nem volt munkamegosztás: ugyan azok az emberek tervezték és építették, programozták a gépeket, kezelték, futtatták a programokat, elemezték, értékelték az eredményeket. A programozás gépi nyelven történik, operációs rendszer még nincs.

Második generáció (1955-1965)Tranzisztorok és kötegelt rendszerek

A tranzisztorok megjelenése radikális változást hozott. Egyrészt kisebbek lettek 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 emberek körében. Megkülönböztethetjük a tervezQket és építQket, az operátorokat, a programozókat és a karbantartókat. Nagyobb intézmények, kormányszervek, egyetemek engedhetik meg, hogy számítógépeket beszerezzenek. A programozó lyukkártyára lyukasztja a futtatandó programjait, Lyukkártyára kerülnek az adatok is.

Harmadik generáció (1965-1980): Integrált áramkörök, multiprogramozás

A 60-as évekre két, meglehetQsen különbözQ számítógépfajta alakult ki. Egyik az ún. Szószervezésq, nagy, tudományos számításokra alkalmas gépcsalád volt, elsQsorban a numerikusszámításokban jeleskedett.

A másik család a karakterorientált gépcsalád, kisebb, és drágább gépek voltak ezek, jól alkalmazhatták adat-átalakításra (lyukkártya -> szalag konverzió), rendezésre, nyomtatásra, stb. ElQbbieket fQleg a tudományos és mérnöki számításokra, utóbbiakat az üzleti életben (bankok, biztosítók, kereskedelmi társaságok) használták elsQsorban. A két gépfajtát integrálták, mely következtében, az IBM válasza a System/360 rendszer volt.
Itt jelent meg a multiprogramozás, a memóriát partíciókra osztották, és a partíciók mindegyikébe betöltöttek egy-egy munkát. Mikor egyikkel végzett, CPU-veszteség nélkül átkapcsolhatott egy másik feldolgozásra.
FejlQdtek az operációs rendszerek: a MULTICS és UNIX ekkor alakul ki, ezek már általános célú, multiprogramozású, idQosztásos rendszerek voltak. A munkamegosztás is fejlQdött: vannak fejlesztQk (elektromérnökök), karbantartók, hardveresek (elektromérnökök), rendszerprogramozók (az operációs rendszerrel foglalkoznak, fejlesztik, illesztik stb.), operátorok (kezelik a rendszert), programozók és felhasználók (az idQszak végére). Egy sor imperatív és funkcionális programnyelv alakul ki (Algol, PL/1, APL, Lisp, Basic, Prolog, C stb.). Az idQszakot jellemzi az ún. szoftver krízis.

Negyedik generáció (1980-1990): Személyi számítógépek, LSI, VLSI

Az LSI (Large Scale Integration), késQbb a VLSI (Very Large Scale Integration) lehetQvé tette, hogy nagy mennyiségben és viszonylag olcsón állítsanak elQ számítógépeket. Ez volt a személyi számítógépek (Personal Computer) hajnala.

Következmény
visszaesés a védelemben
felhasználóbarát felhasználói kapcsolattartók kellenek
a PC játékokra is jó. Mindenki használja, mindenki "szakértQvé" válik.
A gyenge védelem hozza a "vírusokat". Óriási a kavalkád. Hogy lesz itt egység? Tévedések: C64 játékgép professzionális felhasználása.

Megjelenik a munkaállomás (Workstation), ami tulajdonképpen erQforrás-gazdag személyi gép. Ezek miatt már felmerült a szükség igazi operációs rendszer funkciókra.
Macintosh Apple operációs rendszere
Unix származékok
Windows NT a munkaállomásokra
OS2 és a Win95 PC-kre.
KésQbb a hálózati operációs rendszerek, és az osztott operációs rendszerek is jelentQsek.




2.) Direkt futtatás a hardveren, monitor programok, operációs rendszerosztályozások



Direkt futtatás a hardveren

Ha a számítógépet mqködtetQ rendszer nélkül használjuk, akkor direkt futtatásról beszélünk. Régebben természetesen ez a futtatási mód is megvolt. Ekkor persze minden felelQsség a programozóé! Teljes részletességben ismernie kell a hardvert, az utasításkészletet stb.

Egy általános célú számítógéprendszer persze mqködtetQ szoftver nélkül nemigen használható. Legalább egy monitor program kell hozzá, mely futtatható szubrutinok gyqjteménye. A szubrutinokat rendszerint a ROM-ban tárolnak. A monitor rutinjai képesek karaktersorozatokat fogadni egy konzol terminál billentyqzetérQl, ezeket a sorokat egyszerq parancsként értelmezni, a parancsokhoz rendelt egyszerq funkciókat végrehajtani, és természetesen képesek a konzol terminál megjelenítQjére küldeni karaktersorozatokat. A monitort a gép gyártója biztosítja.

A monitor parancsai hallatlanul egyszerqek. Rendszerint vannak memória cella teszt és beállító parancsok (examine mem-cím, set érték mem-cím), fájl betöltQ, kiírató parancsok (load filenév mem-kezd-cím, type filenév stb.), és természetesen "futtató" parancsok (go mem-cí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. Még jobb az eset, ha van load/run parancspár is! Ekkor rendszerint tesztprogramot tölthetünk be, utána elindíthatjuk.

Néha a monitor az eddig említett parancsértelmezQ/végrehajtó rutinjai mellet tartalmaz néhány I/O rutint is. Ezek a nyomtatókezelést, a konzol megjelenítQ és a billentyqzet kezelését, esetleg adott memória tartomány lementését egy fájlba tehetik lehetQvé.

Minden modern operációs rendszer ebbQl a primitív monitormqködtetQ rendszerbQl nQtt ki. A gyártók elsQsorban a hardveres mérnököknek szánva a monitort ma is gyártanak így számítógépeket. Sokszor a gép bekapcsolásakor nem egy operációs rendszer töltQdik, hanem egy monitor indul. A monitort kizárólag tesztelésre használják, a normális üzemmódhoz manapság biztos egy valódi operációs rendszert fognak betölteni.



Az OS-ek osztályozása

Az operációs rendszer alatti hardver "mérete" szerinti osztályozás szerint

o mikroszámítógépek operációs rendszerei;
o kisszámítógépek (esetleg munkaállomások) operációs rendszerei;
o nagygépek (Main Frame Computers, Super Computers) operációs rendszerei.

A kapcsolattartás típusa szerinti osztályozás szerint
o kötegelt feldolgozású operációs rendszerek, vezérlQkártyás kapcsolattartással;
o interaktív operációs rendszerek.

További fontos osztályozási szempont
cél szerinti osztályozás;
a processz kezelés,
a felhasználók száma szerinti,
a CPU idQ kiosztása szerinti osztályozás;
a memória kezelés megoldása szerinti osztályozás;
az I/O koncepciók, a fájl rendszer kialakítása szerinti osztályozás.


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 általános célú operációs rendszerek több célúak: egyidejqleg használjuk azokat programfejlesztésre, alkalmazások futtatására, adatbázisok lekérdezésére, kommunikációra stb.
A speciális célú rendszerek osztálya igen gazdag lehet: vannak folyamatvezérlésre beállított, vannak tranzakció feldolgozásra implementált stb. rendszerek, közös jellemzQjük, hogy egyetlen célt szolgálnak.



Processz kezelés, idQkiosztás, felhasználó szám szerinti osztályok

A több, változó feladatszétosztású processzorral rendelkezQ gépeket az operációs rendszerükkel együtt multi processing rendszereknek szokás nevezni.
Az egy processzoros gépek mqködtetQ rendszere lehet single tasking (egyidQben egy processz lehetséges), vagy multi tasking rendszer (kvázi párhuzamosságban több processz fut).

Az egyidejq felhasználók száma szerint beszélhetünk egyfelhasználós (single user) rendszerekrQl és többfelhasználós (multi user) rendszerekrQl.

A CPU idQkiosztása lehet szekvenciális (egy processz teljes feldolgozása után kapcsol a másikra), kooperatív-event polling rendszerq, megszakítás vezérelt (interrupt driven), vagy beavatkozó-megszakításvezérelt (preemptiv-interrupt driven).


Memóriamenedzselés szerinti osztályozás

AlapvetQen megkülönböztetünk valós címzésq és virtuális címzésq rendszereket. A valós címzésq rendszereken belül a fix, vagy változó partíciókra osztott memóriakezelés lehetséges.
A virtuális címzésq rendszerek alosztályai a klasszikus ki/besöprQ (swapping in/out) rendszerek, a klasszikus igény szerinti ki/belapozó (demand paging)(swapping and paging) rendszerek.


Az I/O koncepciók, a fájlrendszer megvalósítása szerinti osztályozás

A fájlrendszer implementációjában igen fontos két megoldandó feladat koncepciója szerint osztályozzuk magukat a fájlrendszereket.

1. Hogyan rendelik az OS-ek a fájlnévhez a fájl blokkjait

Már nem használt megoldás a folyamatos allokáció. Használatos viszont az indextáblás hozzárendelés. A Unix-ok jellegzetes módszere az i-listás hozzárendelés.

2. Hogyan kezelik az OS-ek a szabadblokkokat

Használatos megoldá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





3.) Operációs rendszer struktúrák, nézQpontok a strukturáláshoz



A nézQpontok az OS-ek szemléléséhez

Milyen szolgáltatásokat biztosít az OS? Milyen funkcionális részei vannak?
Milyen felületeket (interface) ad a felhasználóknak, a programozóknak?
Komponenseit hogy állítják elQ, köztük milyen interfészek vannak?


Szolgáltatások szerinti komponensek
processz menedzsment komponensek
MemóriamenedzselQ komponensek
másodlagos tárolók menedzsmentje
I/O menedzsment
védelmi komponensek
fájlrendszer komponensek
felhasználói kapcsolattartó komponensek
hálózatkezelQ komponensek


Interface-ek a felhasználónak, programozónak
rendszerhívások
rendszerprogramok, segédprogramok
kapcsolattartók


Implementációs struktúrák
egyszerq, monolitikus rendszer
réteges rendszer
virtuális gépek
kliens-szerver modell
vegyes szerkezetek



4.) Monolitikus struktúrájú, réteges struktúrájú operációs rendszerek


Monolitikus rendszer

Az a struktúra, mikor nincs is struktúra.
A monolitikus rendszer magja névvel ellátott szolgáltató eljárások (service rutins) gyqjteménye, melyek hívhatók
a felhasználói programból (processzbQl) úgynevezett rendszerhívással (kernel call,)
egy másik szolgáltató rutinból (call).


monolitikus struktúra

A szolgáltató rutinok természetesen adnak valamilyen szolgáltatást: kezelik a hardvert. A szolgáltató rutinokból a visszatérések csak abban különböznek, hogy 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 monolitikus rendszer rutinjait assembly, esetleg magas szintq nyelven írják. Ezeket lefordítják (compile) és összeszerkesztik (linkelik) egyetlen betölthetQ programba, lementik egy fájlba. Ez a fájl a rendszerindításkor betöltQdik és a kernel ott áll szolgáltatásra készen.
Ha nagyon akarjuk a monolitikus rendszerek is strukturálhatók, rétegezhetQk.


Réteges struktúra

A THE egyszerq kötegelt feldolgozási rendszerq operációs rendszer volt. A rendszernek 6 rétege volt:




Mi a rétegezettség elQnye?
egy réteg magasabb szintq operációkat biztosít a felette lévQnek
elrejti az alatta lévQ részleteket

A rétegezési koncepciót a korszerq operációs rendszerek ma már természetszerqleg használják. Egyik nyilvánvaló megvalósítása a Virtuális Fájlrendszer koncepció, vagy a dinamikusan linkelt futásidejq könyvtári rutinok (DLLs) koncepciója. Ennél egy-egy szolgáltatási funkciót biztosító rutin nemcsak egyszerqen önállóan betölthetQ komponens, hanem dinamikus a betöltés: nem feltétlenül a rendszer startup során töltQdik a rutin, hanem csak akkor, amikor szükség van rá, azaz dinamikusan.



5.) Virtuális gép struktúra. Kliens-szerver struktúrájú operációs rendszerek



Virtuális gép struktúra

A hatvanas években kibocsátott OS/360 rendszer kötegelt feldolgozási rendszer volt. A felhasználói igényelték volna az idQosztást, de a hivatalosan fejlesztett IBM idQosztásos rendszer kibocsátása késett, amikor kész lett, kiderült, hogy túl nagy és lassú. Közben egy fejlesztQ csoport egy radikálisan különbözQ megoldással rukkolt elQ, amit az IBM el is fogadott. Ez volt a Virtual 370 koncepció: a VM/370.

Azon az egyszerq elgondoláson alapult, hogy egy idQosztásos rendszertQl elvárjuk:
biztosítsa a multiprogramozást
biztosítson egy kiterjesztett gépet, aminek kényelmesebb a kezelés, mint egy valós gépnek.

A két követelményt a VM/370 rendszer teljesen szétválasztva biztosítja.

A rendszer lelke a Virtual Machine Monitor, ez fut a puszta hardveren, úgy biztosítja a multiprogramozást, hogy több virtuális gépet emulál a felette lévQ réteg számára. Az emulált gépek azonban nem egyszerq kiterjesztett gépek, hanem pontos másolatuk valódi gépeknek, beleértve a kernel/user módváltási mechanizmust, az I/O eszközöket, a megszakításrendszert stb., szóval mindent, ami egy valódi gépen van.
Minden emulált gép bit szinten azonos az igazi hardverrel, ezért aztán futtatható rajta bármely olyan operációs rendszer, ami az igazi gépen futtaható. Így is volt, a VMM által emulált gépen futtattak OS/360 rendszert, CMS rendszert stb.





A kliens-szerver modell

Modern operációs rendszerek fejlesztési trendje, hogy minél kisebb legyen a kernel, hogy az operációs rendszer minél több funkcióját tegyük magasabb rétegekbe.

LehetQleg minél több OS funkció kerüljön a felhasználói módú, legfelsQ rétegbe. A törekvés a kliens-szerver architektúrával közelíthetQ.

Az elgondolás lényege, hogy a felhasználói processzek -mint kliens processzek - üzenetküldéssel igényeljenek szolgáltatást a szolgáltató processzektQl.


A szolgáltató processzek programjai önállóan linkelhetQk, betöltQdhetnek a rendszer egész életére, vagy idQlegesen (daemon processzek), futhatnak kernel, de akár felhasználói módban is. A szolgáltatók, miután elkészültek a munkájukkal, üzenetküldéssel válaszoljanak. A modell az alábbi ábrán látható.


kliens-szerver modell

Tisztán ilyet sohasem valósítottak meg, de bizonyos szolgáltatásokat több operációs rendszerben ezzel a struktúrával valósítanak meg, és ebbQl a gondolatból fejlQdött ki a "distributed system" fogalom


osztott rendszer modell




6.) Windows NT operációs rendszer struktúra


A HAL modul tulajdonképpen csatoló a hardver és a mikrokernel között, célja a hardverkülönbözQségeket elrejteni a magasabb rétegek elQl. Bár az operációs rendszer része, szokás szerint a hardvergyártók készítik és szállítják a géppel együtt. A HAL-nak köszönhetQ, hogy az NT sok platformon használható.

A mikrokernel látja el az alapvetQ rendszerfunkciókat: a megszakításkezelést, ütemezést, szinkronizálásokat.

Az Objektum menedzser egységes szabályrendszer segítségével vezérli az objektumok létrehozását, elnevezését, biztonsági tényezQit.

A Folyamat menedzser hozza létre és törli a taszkokat, a szálakat (fonalakat), szorosan együttmqködve a memória menedzserrel és a biztonsági rendszerrel.

A Helyi eljáráshívás alrendszer kezeli az alkalmazások hívásait, melyekkel a környezeti alrendszeren át szolgáltatásokat igényel.
Az I/O alrendszer biztosítja a fájlrendszereket (FAT, NTFS, CDFS), a cache buffer funkciókat, az eszköz driver-eket.

A Virtuális memóriamenedzser értelemszerqen a memória-gazdálkodást segíti.

Kernel komponens a Win32K ablakmenedzser: kezeli az ablakokat, a képernyQt, eljuttatja az inputokat az alkalmazásokhoz.

A GDI (Graphics Device Interface) grafikus eszköz csatoló pedig képernyQ rajzoló primitívek gyqjteménye.

Végül, a megjelenítQ alrendszerhez tartoznak a grafikus eszközmeghajtók (driver) is.



a Windows NT 4.0 kernel szerkezete




7.) Unix struktúra. OS2 struktúra


A Unix kernel funkcionális felépítése

A Unix kernel implementációjához legalább két futási mód kell: a felhasználói mód és a kernel mód. Az ábrán, a futási szinteket (User level, Kernel level) tüntettünk fel, amik értelemszerqen megfelelnek a futási módoknak. Természetesen nincs akadálya annak, hogy több futási móddal rendelkezQ CPU-ra Unixot valósítsunk meg.

Nézzük most az ábrát! Ez a két futási módú hardverre implementálható Unix kernel legalapvetQbb struktúrája. Láthatunk hasonlóságokat és különbözQségeket a VMS kernelhez viszonyítva: megfigyelhetQ az itt is önálló I/O alrendszer, látható, hogy a memória menedzsment, a scheduler és a folyamatközi kommunikáció szolgáltatás a folyamatvezérlQ alrendszer (Process Control Subsystem) részeként feltüntetett. Az ábrán néhol látszik a réteges felépítés (Pl.: az I/O alrendszert). Az viszont nem látszik az, hogy vannak kernel szintq adatbázisok, adattáblák is.

A VMS-hez hasonlóan, a kernel itt is szolgáltatásokat biztosít a felhasználói folyamatok számára.
Bizonyos szolgáltatások itt is eljárás jellegq rutinok (call jelleggel hívhatók), itt is vannak eseménykezelQ rutinok (esemény bekövetkezésre, akár aszinkron jelleggel hívódnak), és itt is vannak önálló folyamatként megvalósított szolgáltatások (pl.: a swapper és a pagedaemon). Bármelyen is az implementáció, a felhasználói folyamatból a szolgáltatás ún. rendszerhívással (system call) igényelhetQ.


a UNIX kernel funkcionális felépítése






8.) A kernelbe való belépés, kilépés


Hogyan juthat a vezérlés a kernelbe?

Tulajdonképpen háromféle módon:

A felhasználói processzekbQl rendszerhívással (system call). Valójában ez egy futásidejq könyvtári függvény hívása, aminek a paramé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.

Megszakítás (IT: interrupt) generálásával a hardverbQl. Aszinkron, és ritkán kapcsolatos az éppen futó processzel, a processznek "nincs is tudatában", hogy mi okozza a problémát.

Kivételes esemény (Exeption Condition), hiba (error) elQállása esetén a hardverbQl. 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.

A kernelbe való belépés eseményei

A hardver átkapcsol kernel módba. A memória-elérés kernel módban történik ezután, a verem mutató áltál a kernel szintq 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 szintq veremére töltQdnek (push). Ez hardveres letöltés.
A rendszerhívás/trap kódja (system call száma/signal kódja) is rátöltQdik a veremre.
Egy assembly rutin lementi az általános célú regisztereket is. Ezek után már magas szintq 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üggQen.
Hívódik:
syscall() rendszerhíváshoz. Ez egy diszpécser, ami elosztja a vezérlést.
trap() a kivételes esemény belépés esetén, ami szintén elosztja a vezérlést, a kódtól függQen.
a megfelelQ device driver IT kiszolgálója, megszakítás belépés esetén.

A diszpécser feladatai

Kiveszi a rendszerhívás paramétereinek számát.
EllenQrzi a paramétereket, vajon a felhasználói címtartományban vannak-e, majd bemásolja azokat a kernel címtartományába. Ez azért fontos, hogy a kiszolgá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 megfelelQ rutint.


Visszatérés a kernelbQl

A visszatérés a megfelelQ szolgáltatásból függ a belépéstQl.
A klasszikus rendszerhívás szolgáltatásból elQször a diszpécserhez tér vissza a vezérlés, méghozzá azzal a jelzéssel, hogy a szolgáltatás sikeres volt, vagy nem. MielQtt a diszpécser a hívójának adná az eredményt, megvizsgálja, kapott -e közben szignált a folyamat. Ha igen, a signal handler mqkö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 visszaveszi az általános regiszterek tartalmát (pop). A visszatérési értéket hordozó regiszter a szolgáltatási hiba esetén -1 értéket kap, különben 0-t, vagyis a hívó a system call visszatérési értékeként csak jelzést kap, volt-e hiba vagy sem, a hiba jellegére az errno vizsgálatával következtethet). Ezután végrehajtanak egy return-from-interrupt instrukciót. Ez visszaállítja a PC és PSW tartalmat, és visszaállítja a felhasználói módot. Ugyanezzel visszaáll az SP is, és a processz user szintq vermére mutat. Ezzel folytatódik a processz felhasználói módú futása.



9.) A folyamat (processz) koncepció. A processz kontextus


A processz koncepció

A processz egy végrehajtási példánya egy párhuzamosságot nem tartalmazó végrehajtható programnak. A processz egy futó program-példány. A processz fogalmat megkülönböztetjük a végrehajtható program (executable program/image, loadable program/image) fogalomtól! A processz más entitás, mint a program!
Egy program lehet szövegszerkesztQvel készült forrás program. Lefordítva a forrás programot tárgyprogram-ot kapunk. Tárgyprogramokat futásra kész állapotba hozhatunk összeszerkesztQ (linker, task builder) eszközök segítségével. A programoknak helyfoglalásuk van, valamilyen tömegtárolón fájlok formájában tároljuk Qket, hosszméretük van, statikusak.

Egy processz születik. Születése során, vagy születése után egy végrehajtható program betöltQdik a memóriába és fut. A processz vetélkedik az erQforrásokért, él , idQt használ, viselkedése dinamikus. Végül a processz megszqnik (exitál, terminálódik). Másképpen teát a processzben fut a program.
A processzhez hozzátartozik a végrehajtható program, hozzátartoznak annak kód és adat szegmensei, de további információk is tartoznak a processzekhez, melyek a „program állapotban ”még nem létezhettek. A folyamathoz hozzátartoznak a CPU regiszterek pillanatnyi értékei is. Hozzátartoznak még bizonyos adminisztrációs információk is: vagyis mindazon információk, melyek szükségesek, hogy a processz futni tudjon.
Egy multiprogramozású rendszerben (multitasking, multiprocessing) egy idQben több folyamat él. Folyamatok születnek, vetélkednek, együttmqködnek, kommunikálnak, végül megszqnnek.
Kikötjük, hogy a folyamatok szekvenciálisak. Ez azt jelenti nekünk, hogy egy kijelölt processzoron futnak, egy processzhez egy dedikált programszámláló regiszter (PC, Program Counter) tartozik, ami egyetlen helyre tud mutatni a program szövegben.
A klasszikus elképzelésben a független processzekhez független processzorok, ezzel független programszámláló regiszterek tartoznak. Egy-egy processz vezérlési menete közvetlenül nem befolyásolja a többi menetét. Közvetetten persze a processzek az erQforrásokért való vetélkedéssel, a processzek közötti kommunikációs mechanizmusok segítségével befolyásolhatják egymást!
Az egyik legfontosabb erQforrás, amiért a processzek vetélkednek, éppen a processzor lehet! Multiprogramozott rendszerben több processz létezhet egyidQben mint ahány processzor van.
A klasszikus processz a dedikált logikai processzoron szekvenciálisan fut. A processz szemszögébQl tekintett szekvencialítás a valóságban nem az.

Miután a klasszikus processz koncepció szerint minden processznek van dedikált, saját processzora, e processzor futási módja nevezhetQ a processz futási módjának is. Nyilvánvaló, hogy a processzek a saját kódjukat felhasználói módban hajtják végre, az események kezelQinek (handlerek) kódjai viszont kernel módban futnak.

Folyamat tartalom (process context) fogalom

A folyamat tartalom, esetleg folyamat szövegkörnyezet használható kifejezések. A folyamat kontextus definíciója: adatstruktúrákba rendezve minden olyan információ, ami a folyamat futásához szükséges:
A program (image) kódszegmense(i), (szekciói);
A program adatszekciói;
A processz veremtára(i) (stack, heap),
A folyamatmenedzselési információk (néha nevezik attribútumoknak):
o a kód aktuális instrukciója, ami éppen fut, vagy következik (PC)
o azonosítási információk (pid, ppid, pname stb.)
o tulajdonossági, családtagi információk (uid, gid stb.)


o állapot információk
o prioritások, limitek, quóták
o I/O menedzsment információk
o mutatók a szekciókhoz stb.

Ezek az információk azonosítják a processz által használt erQforrásokat és azt az instrukciót, amelynél a processz éppen fut.

A processz kontextus többféle módon szemlélhetQ!

Egyik szemléletmódban beszélhetünk

hardver kontextus-ról (a regiszterek pillanatnyi értékeirQl, mint menedzselési információkról) és
szoftver kontextus-ról (kódszegmensek, adatszegmensek, egyéb menedzselési információk stb.).

Egy másik szemléletmódban ugyanaz a kontextus lehet

felhasználói szintq kontextus (user level context), ami a felhasználói címtartományban (user address space) van, vagy
rendszer szintq kontextus (system level context)
o statikus része fQleg menedzselési információkat tartalmaz
o lebegQ(dinamikus) része, amihez a regiszter állapotok tartoznak (register context). Dinamikusnak, lebegQnek (volatile) nevezzük ezt a részt, mert a regiszterek értékeit idQnként maguk a regiszterek hordozzák, idQnként azonban le vannak mentve valamilyen verembe.

Egy processznek az az elképzelése , hogy van egy meglehetQsen nagy virtuális címtartománya az MMU (Memory Management Unit) valamint az OS kernel együtt biztosít memória rekeszeket is. Az MMU bizonyos regiszter(ek)ben tárolja az éppen futó processz (current process) leképzési táblá(i)nak kezdQ címé(i)t. Amikor az éppen futó processz elveszti a processzort és egy másik processz megkapja azt (ezt nevezzük processz kontextus kapcsolásnak, Process Context Switch), a nyertes processz lebegQ (volatile) kontextusának a regiszterekbe való betöltésével Az MMU regiszterek a nyertes címleképzQ tábláinak címeit tartalmazza.

A processz kontextus adatstruktúrái

A folyamatok kezeléséhez az operációs rendszer magja adatstruktúrákba rendezve tartja nyilván minden processz kontextusát, annak pillanatnyi állapotát. Az adatstruktúrák elemei a processz tábla (Process Table), a processz tábla bejegyzés (Process Table Entry), a processz leíró (Process Descriptor), végül a processz tábla bejegyzésekbQl, illetve a processz leírókból készült, az állapotokat nyilvántartó láncolt listák.

A Processz tábla az operációs rendszer magja által kezelt, adott méretq táblázat. Egy-egy bejegyzés egy-egy processz vezérlQ blokk. A Process Table méretét a rendszergeneráláskor szabhatják meg. A táblának annyi bejegyzése kell legyen, hogy az egyszerre élQ processzek mind bejegyezhetQk legyenek. A processz tábla a kernel címtartományában van. Új bejegyzése (processz belépési pont) keletkezik egy processz kreálásakor, megszqnik a bejegyzése a hozzátartozó processz megszqntekor. A bejegyzése a hozzátartozó processzrQl "statikus" adatokat tartalmaz. A processz tábla rezidens, azaz nem söpörhetQ, nem lapozható ki.

A Processz leíró (Process Descriptor) a kernel által kezelt struktúra, a kernel címtartományában. A processz futtathatóvá válásakor keletkezik, terminálódása során szqnik meg. Nem feltétlenül rezidens, azaz kisöpörhetQ, kilapozható. "Dinamikus" adatokat tartalmaz a hozzátartozó processzrQl, olyanokat, melyek a processz futásához (is)kellenek.



10.) UNIX processz kontextus adatstruktúrák


Kiindulópont itt is a processz tábla egy bejegyzése, amit szokásos Unix terminológiával proc structure -nak nevezünk. A processz tábla permanens, nem lapozódhat, söprQdhet ki.

Proc structure (Process Table Entry)

Tartalma (nem teljesen)
pid, ppid, gpid (azonosításhoz)
uid (tulajdonság jelzésére, de csak a BSD rendszerekben)
program méret, memória igény (memória menedzsmenthez)
állapotjelzQ a memória menedzsmenthez
állapotjelzQk az idQkiosztáshoz és scheduling paraméterek, mutatók az állapotlistákhoz
signal mezQk (a kiosztott, de még nem kezelt szignálok értékelésére)
mutatók (u-area-ra, region table-kra)


U-area

KisöpörhetQ, kilapozható, nem permanens. Mérete 1K-4K rendszertQl függQen. Tartalma durván két részre osztható: a user structure-ra, és a processzhez tartozó kernel verem re.

A user structure tartalmazza azokat az információkat, melyek a rendszer számára akkor fontosak, amikor a processz nincs kisöpörve. A user structure szerkezetét megtalálhatjuk a user.h header fájlban.

Tartalma
visszamutató a Process Table Entry-re; valós és effektív felhasználói (uid)és csoport (guid)azonosítók állapotjelzQk, idQmezQk, szignálokra való reakciókat leíró tömb; nyitott I/O folyamok leírói, jellemzQi; default eszköz és katalógus, bejelentkezési terminál; a processzhez tartozó rendszer bufferek címei; pillanatnyi rendszerhívás paraméterek, visszatérési érték, hibakód; erQforrás limitek, quóták, privilégiumok.


Region tables (régiókat leíró táblák)

Ezek bejegyzései memória régiókat írnak le, melyekben megtalálhatók a processz kódja adatai. Közvetve vehetQ mi, hol. Van processzenkénti region table, így valósulhat meg az osztott memória (shared memory).


a UNIX processz kontextus adatstruktúrái



11.) A processz kontrol, a folyamatkészítés rendszerhívásai, folyamatkészítés Unix-ban


A folyamatok vezérlése (Process Control)


A folyamatok
élnek, van aktivitásuk, vannak kapcsolatok közöttük:
versenyeznek erQforrásokért (pl.: CPU, RAM, diszkek stb.)
konfliktusmentesen megosztoznak erQforrásokon (pl.: kernel kódon),
kommunikálnak, együttmqködnek,
szinkronizáció lehet köztük
végül exitálnak.


Egyszerq rendszerekben a rendszerbetöltés (startup) folyamán minden processz "kézbQl" készül és végig éli a rendszer életét. A szokásos operációs rendszerekben azonban általában: processzt csak processz kreálhat (processz kérhet kreációs szolgáltatást a kerneltQl). A kernel a kreációs kérésre elkészíti és tölti a processz tábla belépési pontot, memóriát biztosít a kód és adatszegmenseknek, elkészíti és kitölti a processz leírót, ekkor "elkészíti" a volatile kontextust (itt kap értéket a PC!), végül futtatható állapotba helyezi a processzt. Processz kreáló rendszerhívások lehetnek a create(), run(), load(), exec(), system(), illetve a fork(), vfork() rendszerhívások. Operációs rendszerfüggQ, hogy milyen kreáló rendszerhívásokat implementálnak.

Miután processzt csak processz kreálhat

" szülQ-gyermek reláció alakul ki (v.ö. jegyzék-aljegyzék reláció)
" processz hierarchia alakulhat ki (v.ö. fájlrendszer).

A gyermek processz készítése során a processzek élete szempontjából két eset lehetséges:

a szülQ folytatja futását a gyermekével párhuzamosan
a szülQ várakozik, amíg gyermeke(i) terminálódik(nak)

Két lehetQség van a szülQ-gyermek processzek viszonylatában a processz kontextusok, processz címtartományok szempontjából is:

a gyermek másolata (duplikátuma) a szülQnek, ugyanaz a program fut benne;
o de a címtartományaik különböznek, vagy
o osztoznak a címtartományuk legtöbb részén.
a gyermek új, más programot futtat.

A processzek felfüggeszthetik futásukat (blokkolódhatnak),"elaludhatnak", akár meghatározott ideig, akár elQre meghatározatlan idQre, meghatározatlan vagy meghatározott esemény bekövetkeztéig. A processzek menedzselési információi, az attribútumai jellegzetesen a kernel címtartományában vannak.

Befejezve futását egy processz az exit(), abort() rendszerhívással kérheti az operációs rendszert, hogy törölje Qt a létezQ processzek készletébQl (process pool-ból). Ekkor adhat vissza a szülQjének visszatérési értéket, szignálozhat a szülQjének. A terminálódás során a processzhez rendelt erQforrásokat az operációs rendszer visszaveszi. Ez az ún. szokásos, normális terminálódás. Lehet futó processzt "megölni", megfelelQ szignál kikézbesítésével is

Leggyakoribb kikényszerített terminálás azon eset, mikor a szülQ terminálja gyermekeit, mert
a gyermek valamilyen hozzárendelt erQforrás-korlátot túllép
már nincs szükség arra a feladatra, amit a gyermek végez
a szülQ terminálódna, de az operációs rendszer nem engedi, hogy a gyermek túlélje a szülQjét


Az operációs rendszer által futtatott, együtt élQ processzek lehetnek
független (independent) processzek: nincs hatásuk egymásra (valójában rejtett hatásuk persze van: erQforrásokért Qk is vetélkedhetnek)
kooperáló processzek: tervezett hatásuk van egymásra (pl.: felhasználják egymás eredményeit, szinkronizálják egymást stb.



UNIX subprocess system calls

Az érintett rendszerhívások: fork() exec?() system() exit()
A Unix-ban a processz kreálás alapvetQen a fork()-kal, vagy a fork()/exec() "villával" történik.



A fork() rendszerhívás

A fork() AlapvetQ módszer új processz készítésére. A fork a koncepciója szerint a processz instrukciófolyamát két, konkurens instrukciófolyammá osztja. A Unix-ban ezt gyermek processz kreálással valósítja meg.

Prototípus deklarációja: pid_t fork();

Szemantika

Készít egy új gyermek folyamatot (ha sikerül!), melynek kontextusa a pid-et és CPU idQfelhasználást kivéve (nézd a manual-ban a pontos különbségeket) ugyanaz, mint a készítQé. A legfontosabb talán az, hogy a szülQben és a gyermekben ugyanaz a programszöveg, ugyanott fut.

A forgatókönyve

1. EllenQrzi, készíthetQ-e a gyermek processz.
2. Bejegyzést készít a processz táblába a gyermek számára.
3. Meghatározza a gyermek pid-jét, tölti a PCB-t.
4. A szülQ kontextusának logikai másolatát elkészíti
5. A nyitott adatfolyamok i-bög (i-node) hivatkozásait inkrementálja.
6. Mindkét processzben visszatér, de a szülQben
o a gyermek pid-jével (hiba esetén negatív értékkel);
o gyermekben 0 (zéró)értékkel.



A processz kontextus (statikus rész) változtatása

Új programot töltök a kontextusba. Erre szolgál az exec?() rendszerhívás-család.

Prototípus deklarációja:

int execl(char *path,char *argO,char *arg1,...,char *argn,0);

Szemantika

A hívó processz felhasználói címtartományára rátölti a "path"-tal jelölt végrehajtható programot, vermeket állít neki, és a belépési címtQl kezdQen futásra kész állapotba teszi (futtatja). Átadja az aktuális argumentumokat neki (változó argumentumlistájú, az utolsó argumentum utáni nullával jelzQdik a lista vége).
Az exec?() függvények csak az argumentumaikban különböznek.



12.) Processz állapotok, állapotátmenetek, futási módok. Informálódás processz állapotokról


Két processz futásának relatív sebességétQl függQen elQfordulhat, hogy a második processznek várnia kell, amíg az elsQ az output-ját elkészíti. A második blokkolt, amíg az inputja elkészül. Kérdés merülhet fel, hogyan "billen" ki ebbQl az állapotból a blokkolt processz. Másrészt az is elQfordulhat, hogy egy processz ugyan nem vár semmire, tehát futhatna, de az operációs rendszer egy másik processznek adja át a CPU-t: ekkor is "vár" a processzünk, most a CPU-ra, ezt az állapotát feltétlenül meg akarjuk különböztetni az input-ra való várakozástól. Azt mondhatjuk, hogy a processzek -életük során -különbözQ állapotokban (state) lehetnek, az állapotok között különbözQ állapotátmenetek lehetségesek. A legegyszerqbb és legáltalánosabb állapot és állapotátmenet diagram a következQ:


Ahol az ellipszisekkel jelöltek az állapotok
running -futó állapot, a processzé a CPU;
blocked -blokkolt, alvó (sleeping) állapot, mikor a processz egy esemény bekövetkezésére vár;
ready -futásra kész (computable) állapot, mikor a processz futhatna, ha megkapná a CPU-t.

Az ábrán nyilakkal jelöltük az állapotátmeneteket
wait/sleep/request -várakozz (blokkolódj) eseményen állapotátmenet;
signal/respond -jelzés az esemény bekövetkezésére;
preempt -a CPU elvétele a processztQl;
schedule -A CPU kiosztása a processznek.

Egyedül a wait/request/sleep állapotátmenetet kezdeményezi maga a processz, az összes többi átmenetet a processz szemszögébQl nézve külsQ entitás váltja ki.
A folyamat környezet váltás tehát: egy-egy átmenet két processz számára, mikor is az egyiktQl elvevQdik (preempt/wait/sleep/request), a másiknak kiosztódik (schedule) a CPU.
Az egyes operációs rendszerekben az állapotok és állapotátmenetek elnevezése különbözQ lehet, különbözQ neveken tarthatja számon.


A zombie állapot: exitálódott processz állapota, amíg a szülQ processz tudomásul nem veszi az exitálódást.

Non-existent állapot: a processz még nem létezik.

Suspended állapotok: felfüggesztett állapotok. A processzek ebben az állapotban nem képesek az erQforrásokért vetélkedni, sem a memóriáért, sem a CPU-ért nem jelenthetnek be igényt. Az ilyen állapotú processzek esélyesek a "kisöprésre". Egy processzt csakis egy másik processz "függeszthet fel", természetesen a védelmi eszközöket figyelembe véve. Általában a rendszermenedzser függeszthet fel processzeket, ha azokat ki akarja zárni az erQforrásokért való vetélkedésbQl.

A processzek állapotáról a burok segítségével érdeklQdhetünk. Unix rendszerekben a >ps -l
parancs tájékoztat processz állapotokról.


VAX/VMS-ben

$SHOW SYTEM
$SHOW PROCESSES

A processz kontextusban, legtöbbször a PCB-ben rögzítettek az állapotok. De ha minden döntéshez innen kellene kikeresni, végigolvasva a processz tábla bejegyzéseit, a megfelelQ állapotú processzeket, nagy lenne a veszteségidQ. Ezért az operációs rendszerek többnyire láncolt lista adatszerkezeteken, sorokon (queue) is nyilvántartják a különbözQ állapotú processzeket. MeglehetQsen sok sor alakítható ki: READY sor, I/O várakozó sorok.


A futási módok alapvetQen a CPU jellemzQi

felhasználói mód (user, normál)
kernel mód (privilegizált, védett): szélesebb címtartomány, bQvebb utasításkészlet jellemzi

Mivel a CPU regiszterek is hozzátartoznak a processz kontextushoz, ezért mondhatjuk, hogy a processzeknek is van futási módjuk.

Futási mód váltása trap, IT, vagy kivételes esemény segítésével lehetséges.



13.) Munka (job), feladat (taszk), folyamat (processz), fonál (thread), rutin, utasítás, instrukció
fogalmak. Taszk- és fonál állapotok


A fonál (thread) a CPU használat alapegysége. Egyedileg tartozik hozzá a programszámláló regiszter (PC), a regiszterkészlet és veremtár címtartomány; osztozik más fonalakkal a kód-és adatszekciókon, egyéb erQforrásokon, a taszk címtartományon.

Egy taszk nem csinál semmit, ha nincs benne egyetlen fonál sem. A taszknak van dinamikus kontextusa.
A klasszikus processz tulajdonképpen taszk, egyetlen fonállal, egyetlen végrehajtási menettel.


Miután a fonálnak legtöbb erQforrása (osztottan) megvan a taszkjában, a fonalak közötti CPU kapcsolás, maga a fonál-kreáció "olcsóbb", mint a klasszikus taszk (processz) kontextus kapcsolás (Process Context Switch. A fonálkapcsolás például csak regiszterkészlet kapcsolás.

Némely rendszer megengedi a felhasználói szintq (user level) fonalakat, felhasználói szintq könyvtár-hívásokkal megvalósítva, azaz nem rendszerhívásokkal megvalósítva. Nincs ekkor kernelbe való belépés (trap) a fonálkapcsolásnál. Felhasználói szintq fonalakkal megvalósított szerver taszkban egy-egy fonál tartozhat pl.: egy-egy kliens kérelméhez, és egy fonál blokkolása, egy másik fonálra való CPU kapcsolás hatékony kiszolgálást biztosíthat több kérelemnek.
Hátránya is van persze a felhasználói szintq fonalaknak. Ha egy fonál request/wait rendszerhívást ad ki, az egész taszk blokkolt lesz, amíg a hívás ki nem szolgálódik.
A fonálnak lehetnek állapotai (futó, blokkolt, futásra kész), kreálhat gyermek fonalakat. Egy-egy fonál szekvenciálisan fut, de a fonalak mégsem annyira függetlenek egymástól, mint a processzek. Minden fonál elérheti a taszkja címtartományát, például a társtér fonalak vermét is! A taszkon belül nincs védelem! De nincs is rá feltétlenül szükség, ha volna, megoldható a gond a taszk, processz koncepcióval.

 EMBED Word.Picture.8 


A job fogalom: több processzbQl álló alkalmazásoknál a processzek összefoglaló neve.

További egységeket is láthatunk programozói szemmel: rutinokat (eljárásokat, függvényeket), utasításokat, végül instrukciókat. A rutinok közül egy aktív: amelyikben a vezérlés fut. A hívó rutin "le van fagyasztva", amíg a hívott vissza nem adja a vezérlést, vissza nem tér.

Vannak taszk és fonál állapotok. RUN állapotban egy fonál blokkolódik, a taszk kiválaszt egy másikat és annak adja a CPU-t. READY taszk állapotban legalább egy fonál futásra kész. Blokkolt taszkállapotban nincs futásra kész fonál.




14.) Processzek az MS-DOS-ban. Taszkok, fonalak az NT-ben


Az MS-DOS nem multi-taszking, de nem is igazán mono-taszking. AZ MS-DOS indulásakor betöltQdik a COMMAND.COM és processzként fut.

A parancsokat csoportosíthatjuk

belsQ parancs: a command.com-ban van a kódja, az hajtja végre
külsQ parancs: a command.com indít egy gyermek processzt, és annak adja át a vezérlést, majd megvárja míg az terminálódik

Az így kreált processzek további gyermek processzeket kreálhatnak, indíthatnak. A vezérlés mindig tovább adódik. Nincs Process Table és PCB.






15.) Hiba és eseménykezelés, alapfogalmak



Az esemény legáltalánosabban: folyamatok (taszkok, processzek, fonalak, rutinok, utasítások, instrukciók) futását befolyásoló, váratlan idQpontban bekövetkezQ történés. Az 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 esemény változás valamilyen entitás állapotán. Egy információs állapot elQállása: egy állapottér állapotvektora. Fogalmazhatunk úgy, hogy egy esemény bekövetkezése azt jelenti, hogy elQáll a neki megfelelQ állapot, vagy fordítva, ha elQá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 feltétel elQáll (bekövetkezett az esemény), akkor az valahogyan jelzQdik. Más fogalmazással: jelzés keletkezik. Ismét más fogalmazással: valamilyen entitás jelzést küld valamilyen entitásnak. A jelzQdés, alapja a lekezelhetQségnek, ami kapja a jelzé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
reagálni, kezelni a helyzetet: kezelQ instrukciófolyammal, rutinnal, processzel.
dönteni kell arról, hogy lekezelés után visszaadhatjuk-e a futást az abbahagyott vagy az operációs rendszernek adjuk a vezérlést.


Az események osztályai

Egy processz szemszögébQl lehet

belsQ esemény: amit a processz állít elQ;
külsQ esemény: valami, a processzen kívüli entitás állítja elQ (pl.: perifériavezérlQ interrupt).

Az elQá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 szqkebb értelemben vett események).

A legalacsonyabb szintq események a megszakítások (interrupts). A processz szemszögébQl nézve külsQ esemény.(Ha a processz saját magának küld szoftver megszakítást, akkor tekinthetQ belsQ eseménynek is). ElQállítója rendszerint a hardver (eszközvezérlQk), de lehet szoftver is. Jelzése a CPU-nak szól. LekezelQi az operációs rendszer kernel IT kezelQ (IT-handler) rutinjai. Kezelésének módja: az aktuális instrukció befejezQdik, a kontextus dinamikus része lementQdik (rendszerint részben hardveresen!), a lekezelQ rutin fut, visszatérve a dinamikus kontextus felvevQdik és a soron következQ instrukció futhat. Az IT prioritási szinteknek megfelelQen IT kezelést megszakíthat megszakítás. A bekövetkezett, de még le nem kezelt megszakítások hardveres sorokon várnak lekezelésre.






A kivételek (exeption), hibaesemények

A nevükbQl következQen valamilyen abnormális helyzetet jelentenek. Néha azt mondjuk, olyan események, amelyek a normális futás során nem jelentkeznek, kivételesek, vagy valamilyen hibára utalnak, gondot jelent jelentkezésük.

Lehetnek alacsony szintqek (pl.: túlcsordulás bekövetkezése a CPU-ban), de lehetnek magasabb szintqek is (pl.: laphiba (page fault) vagy fájlnév tévesztés miatti nyitási hiba stb.).
Alacsony vagy magas szint? Ez azt jelenti, hogy a kivétel jelzése instrukciónak, rutinnak, fonálnak stb. szól? Vagy a kezelés szintjét jelenti? MindkettQt!

A klasszikus kivétel bekövetkezése esetén az éppen futó entitás (instrukció, utasítás, rutin, fonál, processz) nem fejezhetQ be! Fel kell függeszteni, le kell kezelni a kivételt, és -ha egyáltalán lehetséges -a felfüggesztett entitást elölrQl kezdve újra kell futtatni (pl.: az instrukciót laphiba esetén); vagy folytatni kell (pl.: rutint onnan, ahol felfüggesztésre került).

Az operációs rendszerek képesek alapértelmezés szerinti módon (default handler-ekkel) kezelni a kivételeket. Többnyire biztosítanak a programozó számára is programozási eszközöket, melyekkel a kivételkezelés részbeni felelQssége, a kivételkezelés lehetQsége (legalább részben) biztosított. Itt a magasabb szint értelmet nyer tehát, veszíti jelentését viszont a "hiba" jelzQ: hiszen nem feltétlenül jelentenek -akár az operációs rendszer, akár a mi általunk lekezelt -kivételek hibákat, legfeljebb csak gondot.



A szqkebb értelemben vett esemény

Ezek bekövetkezését a programozó elQre látja, vár a bekövetkezésükre, bár a bekövetkezés idejét nem tudja: váratlanok és aszinkron jellegqek.

Jellegzetesen magas szintqek az események, feltétlenül kellenek hozzá magas szintq fejlesztQ eszközök, a programozó hatáskörébe tartozik maszkolásuk, lekezelésük stb. Jelzéseik legtöbbször egy eseménysorba kerülnek.
Lekezelésükben igénybe vehetQk a kernel megszakítás-kezelési, vagy kivétel-kezelési technikái is.




16.) Megszakítások és kivételek összehasonlítása


A megszakítások és a hibaállapotok hasonlósága, különbségei

MindkettQ átadja a vezérlést egy kiszolgáló rutinra (handler). A kiszolgálások megszakítás, vagy hibaállapot specifikusak, bár nagyon sokban hasonlóak.

A megszakítás (IT) aszinkron a kurrens instrukciófolyam végrehajtásában. Kiszolgálása két instrukció között történik.
Az exeption condition -bár váratlan -szinkron jelleggel fordul elQ, mint direkt hatás egy instrukció végrehajtása során. Kiszolgálása az instrukció végrehajtása közben történik, azaz a kérdéses instrukció végrehajtása folytatódik, vagy éppen megismétlQdik.
A megszakítás rendszerint nem kapcsolódik a futó processzhez. Kiszolgálása ugyan történhet a kurrens processz kontextusa fölött, de nem valószínq, hogy a futó processz javára.
Az exeption condition általában a kurrens, futó processz része: kiszolgálása a futó 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 Priority Level). Kiszolgálásuk letiltható (lemaszkolható) az IPL (Interrupt Priority Level) szint állításával, de egy megszakítás kiszolgálását magasabb prioritású megszakítás blokkolhatja. Befutott, de nem kiszolgálható megszakítások sorba állva várnak kiszolgálásra (pending interrupts). Rendszerint hardveres a sorképzés.
A kivételes események kiszolgálása nem blokkolódhat. A kivételes események kiszolgálási rendje rendszerint független az IPL szintektQl, 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 wide stack), mivel a megszakítások "system wide" jellegqek. A kivételes események kiszolgálására minden rendszernél processzenkénti kernel verem használatos.

Jelzés (signal): esemény bekövetkezésekor - vagyis a feltétel állapot elQállásakor - jelzés (signal) keletkezik, szoktuk mondani. Jelzések keletkeznek normál futás közben események hatására. Jelzések értesítik a CPU-t, vagy egy-egy processzt az eseményekrQl. Úgy is fogalmazhatunk: a CPU, vagy egy processz jelzést kap, kézbesítenek neki egy jelzést. Az események jelzQdnek. Ebben az értelemben az esemény és a jelzése lehet még szinkron vagy aszinkron is.

Egyszerqsítve

van egy jelzés készlet;
jelzés keletkezhet hardver vagy szoftver eredetbQl
a keletkezett jelzés kikézbesítQdik egy processznek, vagy a CPU-nak. A kikézbesített jelzések sorokba rendezQdhetnek, várva, hogy lekezeljék Qket.
A kikézbesített jelzéseket a lekezelQ rutin (handler) lekezeli.

A jelzéseknek van egy készlete. Minden jelzéshez hozzárendelt egy kezelQ (handler). Jelzést kézbesít ki a rendszer, amikor detektál egy hardver eseményt, illetve processzek küldhetnek szignált más processzeknek. Ez a szignál fogalom tágabb értelmezése, azt hangsúlyozza, hogy az események jelzQdnek.




17.) Szignálozás rendszerhívásai. Szignál diszpozíció, szignál-küldés, kezelés


Rendelkezés a jelzésrQl (signal dispositio)

Az eseményeket kezelni kell, léteznek tehát szignálkezelQk is. A rendelkezés a szignálokról, vagy szignál diszpozíció annak specifikálása, hogy milyen rendszerakció menjen végbe, ha szignált kap egy processz. Arról rendelkezünk, hogy mi legyen a szignálkezelQ, hogyan történjen a kezelés.
Nyilvánvaló, hogy diszponálni ( elQre kell": mielQtt a szignált a processz megkapja), elQtte kell megmondani a kezelés módját. A diszpozíció megváltoztat(hat)ja a kezelést, ez a változtatás addig él, amíg újra nem diszponálunk. Ugyanazon a szignál két diszpozíciója között lehet, hogy nem is kézbesítik ki ezt a szignált.
Nyilvánvaló az is, hogy minden szignálnak kell legyen alapértelmezés szerinti kezelQje (default handler), ami kezel, ha másként nem rendelkeztünk elQre. A default handler-ek általában "gorombák": nem adják vissza a vezérlést, terminálják az "áldozat" processzt. Természetes, hogy 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 kezelQje legyen: egy saját magunk által írt függvény legyen a kezelQ. Nem minden szignálra írhatjuk ez elQ, de elég sokra. Külön megfontolásokat igényel a saját kezelQ írása: befolyásol a szignálok blokkolása és az ebbQl fakadó szignál-felfüggesztés, befolyásol az a tény, hogy mi történjen egy rendszerhívás kiszolgálással, ha éppen azt "függeszti fel" egy saját kezelQ, annak eldöntése, hogy a kezelQnek saját verme legyen vagy sem, megfontolandó, hogy a saját kezelQ lefutása után visszaálljon-e a default kezelés vagy sem stb.
Rendelkezéssel (diszpozíció) beállíthatjuk azt is, hogy hagyjuk figyelmen kívül (ignoratio) a szignált.
ÖröklQdnek diszpozíciók. A függQ szignálok elvesznek. Az exec?()rendszerhívás a szignál diszpozíciókat az alapértelmezési kezelQre (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ó elQ).


Jelzés kézbesítése (delivering of signal), függQ szignálok (pending signals)

Akkor mondjuk a szignált kikézbesítettnek (delivered signal), amikor a diszponált akció beindult. A szignál keletkezésekor az még csak generált szignál. Amikor az akció indul, akkor már kézbesített a szignál. A keletkezés és kézbesítés között idQ telik el, ezt az idQt szokásosan nem is detektálhatja a kérdéses "áldozat" processz. Ez idQ alatt a szignált függQben lévQnek (pending signal) mondjuk. Általában minden keletkezett szignál függQ egy rövid ideig. Az ún. blokkolt szignálok hosszabb ideig is függQek lehetnek.


Jelzések blokkolása, a blokkolás megszqnteté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 blokkolást és a blokkolás megszüntetését is "elQre" meg kell mondani a kérdéses processzben (bár van "automatikus" blokkolás és megszüntetése is: saját kezelQre diszponált szignál kezelése során, vagyis míg a kezelQ fut, többnyire blokkokolt és normális return-jére megszqnik blokkolása). Egyes rendszerekben a blokkolás és megszüntetése kifejezé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 blokkolt és ignorált szignál keletkezésekor "elszáll", megszqnik. Egy blokkolt és nem ignorált szignál keletkezésekor függQ szignál lesz, addig, míg megszüntetik a blokkolást (és ekkor kézbesül, megszqnik függQsége), vagy amíg mégis diszponálják neki az ignorációt, és ekkor a blokkolás megszqnése nélkül "elszáll", megszqnik (megszqnik függQsége is ezzel).




A Unix-okban a szignálokat általában akkor kézbesítik ki, mikor a processz kernel módból visszatér felhasználói módba. Ez minden rendszerhívásból való visszatéréskor, illetve minden IT kezelésbQl való visszatéréskor megvalósul. Miután az óra IT gyakorisága "megszerezhetQ" információ, a szignálok felfüggesztési idejére számítható felsQ korlát.(Vigyázz persze a blokkolt szignálokra!)

A signal() hívás egyszerq és szinte "korlátlanul" használhatjuk diszponálásra. A sigset() rendszerhívás szintén diszpozícióra való, és hasonlóan egyszerq a használata.

A POSIX szabványnak megfelelQ diszpozíciót: a sigaction() rendszerhívás.

Szignál generálás, postázás a kill() és a sigsend() rendszerhívásokkal lehetséges.

A kill(pid_t pid, int sig) feladata: a pid azonositójú processznek küldj sig sorszámú szignált. AlapvetQen 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. Ha a pid==-1, akkor a minden processz megkapja a szignált. 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 pause (), sleep(), usleep() és alarm() rendszerhívások akkor hasznosak, ha szignálozással akarunk processzeket szinkronizálni.

A pause() 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.

A sleep() rendszerhívás az argumentumában adott másodpercig blokkol. Tulajdonképpen nem a szignálozáshoz tartoznak a sleep-ek, de hasznosak a szinkronizációs ütemezésekben.

Az alarm(sec) feladata: a hívó processz számára megadott másodperc(sec) múlva SIGLARM sorszámú szignált generál. Ha a sec 0, a megelQzQleg kért alarm kívánság törlQdik.




18.) Processz ütemezés (scheduling), CPU kiosztás (context switch). Elvárások, technikai alapok,
stratégiák


ErQforrásokért vetélkedQ processzeknél alapvetQ feladata az erQforrások igénybevételének ütemezése. El kell dönteni, melyik processz kapja meg az erQforrást.

Ilyenkor meg kell különböztetnünk e tématerületen belül három feladatot.
ErQforrás hosszú távú hozzárendelése (allocation),
ErQforrás ütemezés (scheduling)
ErQforrás kiosztása (dispatching), az ütemezés után az a technika, amivel az erQforrást hozzárendelik a processzhez

Valójában bármilyen erQforrás ütemezésérQl és kiosztásáról beszélhetünk az ütemezési algoritmusok, a módszerek és eljárások hasonlók lehetnek. Beszélhetünk így CPU ütemezésrQl, diszkütemezésrQl stb. KiemelkedQ fontosságú ezek közül a CPU ütemezés és kiosztás.

A hosszú távú hozzárendelés során történik döntés, hogy egy processz melyik CPU-n fusson egyáltalán. Tulajdonképpen csak többprocesszoros rendszeren értelmezhetQ ez a mozzanat. Egyprocesszoros rendszerekben nincs ez a feladat. A processzhez így hozzárendelt CPU-t maga a processz "pszeudo párhuzamosságban" használja más processzekkel. IdQnként ún. "döntési helyzetek" vannak, melyben el kell dönteni, hogy a következQkben melyik processz legyen a "nyertes", a CPU használó. Ez tulajdonképpen az ütemezés (scheduling). Az ütemezés valójában optimálás: a "legjobb" processz lesz a nyertes processz. Nyilvánvaló, hogy csakis a futásra kész állapotú processzek vesznek rész ebben az optimálásban.

A kernel egyik fQ feladata a futásra kész processzek közül egy számára a CPU kiosztása. El kell döntenie, melyik futásra kész állapotú processz kapja meg a CPU-t. Scheduler-nek, ütemezQnek hívják a kernelnek azt a részét, amelyik ezzel a döntéssel foglalkozik. A két különbözQ feladat tehát:
az ütemezés döntés arról, melyik processz kapja meg a CPU-t (scheduler algoritmusok, technikák)
a CPU kiosztás, ami maga a CPU átkapcsolása egyik processzrQl a másikra (Process Context Switch)
Be kell látnunk, hogy az idQkiosztás (és algoritmusa) független magától az átkapcsolási algoritmustól.

A régi, kötegelt rendszerekben az ütemezés és idQkiosztás egyszerq volt, legtöbbször a first come, first served (a munkák felmerülési sorrendjében szolgáljuk ki Qket) ütemezéssel a run-to-completion (fuss, míg befejezQdik) módszer volt az általános.


Mit várunk el a CPU ütemezQ (scheduling) algoritmusoktól?

A kielégítendQ kritériumok

Pártatlanság: minden folyamat (processz, taszk, job) korrekt módon (nem feltétlenül egyenrangúan) kapjon CPU-t.

Hatékonyság: a CPU lehetQleg a legnagyobb százalékban legyen kihasználva.

VálaszidQ: az interaktív felhasználóknak a válaszidQt minimalizálják

Fordulási idQ (turnaround time): a kötegelt munkák (job) fordulási idejét minimalizálni kell.

Teljesítmény: az idQegységre esQ job-feldolgozás, interaktív munka maximalizálása

Láthatók bizonyos ellentmondások a kritériumok között. A válaszidQ minimalizálása eredményezheti a fordulási idQ növekedését! Vagy: a számításigényes munkák korlátozás nélküli elQnyben részesítése javítja a hatékonyságot, de nem biztosítja a korrektséget, és az összevont teljesítmény is csorbulhat.


Komplikációt jelent, hogy a processzek, taszkok egyediek és nehezen jósolható viselkedésük. Mégis, van lehetQség elfogadható ütemezQ algoritmusokat találni, hiszen a processzek gyakran blokkoltak, várnak valamire, ez lehetQséget biztosít a többi futására. Technikai alapot nyújt, hogy a korszerq rendszerekben mindig van óraeszköz, ami periódikusan megszakítást generál, és ezzel lehetQséget biztosít, hogy
az idQt szeletekre (time slice, quantum) bontsuk
az erQforrás (pl.: CPU) felhasználás idejét (processzenként) mérjük
bizonyos idQnként az állapotokat kiértékeljük, és processzek közti kapcsolást valósítsunk meg.


Az ütemezQ (scheduler) döntési stratégiája -mely futásra kész processz kapja a CPU-t - alapvetQen a következQk egyike lehet:

Nem beavatkozó stratégia (non-preemptive). Ez továbbá lehet:
o run-to-completion jellegq: a processz, ha megkapta a CPU-t, addig használja, míg a
(rész) feladatát el nem végzi,
o együttmqködQ (cooperative) jellegq: a processz, ha megkapta a CPU-t, saját döntése szerint
lemondhat róla.

Szelektív beavatkozó (selective preemptive) stratégia: bizonyos processzek futásába nem lehet beavatkozni (rendszerint a rendszer processzeknél), más processzektQl elveszik a CPU-t, még ha nem is mondana le róla.

Beavatkozó (preemptive) stratégia: bár a folyamatok nem mondanának le a CPU használatáról, beavatkozva elveszik tQlük bizonyos körülmények között. Azokat az operációs rendszereket tartjuk valódi idQosztásos rendszereknek, melyeknél létezik a beavatkozás (preemption) lehetQség.


Ütemezési döntési helyzetek a következQ esetekben léphetnek fel

Amikor egy processz futó állapotból blokkolt állapotba megy (wait/sleep/request állapotátmenet), pl.: I/O kérés vagy gyermek processzre való várakozás miatt
Amikor egy processz futó állapotból futásra kész állapotba megy (preemption állapotátmenet), pl.: egy megszakítás bekövetkezés miatt.
Amikor egy processz blokkolt állapotból futásra kész állapotba megy (signal/respond állapotátmenet), pl.: egy I/O befejezQdése.
Amikor egy processz terminálódik
.
Az 1. és 4. esetekben az érintett processz szempontjából nincs is ütemezési döntési helyzet: másik processzt kell kiválasztani a futásra kész processzek sorából (ha az a sor nem üres).Van "helyzet" viszont a 2. és 3. esetben.

Ha ütemezési döntések csakis az 1. és 4. helyzetekben lépnek fel, akkor mondhatjuk, az ütemezés nem beavatkozó. Ha a 2. és 3. helyzetekben is lehet döntés, az ütemezés beavatkozó.

Az ütemezési algoritmusok vizsgálatához szükségünk van a processzek életének bizonyos szempontú jellemzésére. Megfigyelések szerint a processzek élete során vannak ún. CPU-lázas (CPU burst) és I/O-lázas (I/O burst) életszakaszok. Egy processz a CPU burst idQszakában a CPU-t kívánja használni, az I/O burst szakaszában elsQsorban az I/O csatornákat használná, ilyenkor a CPU szempontjából blokkolt. A processzek futása CPU-lázas szakasszal kezdQdik, azt követheti I/O igényes futási rész, majd újabb "számolásigényes" életszakasz. Az egyes processzek jellemezhetQk a "lázas" szakaszaik számával, hosszával.

A nagyon "számolásigényes"(CPU bound) processzeknek rendszerint kevés, de nagyon hosszú CPU burst periódusból állnak.

Az I/O igényes (I/O bound) processzeknél rendszerint rövidek a CPU-lázas szakaszok, ezek fQleg az I/O csatornákat használják.



19.) Az óraeszköz. Megszakítás-kezelQjének feladatai


Az óraeszköz periódikusan megszakításokat generál. Az idQt így szeletekre lehet bontani, mely lehetQvé teszi, hogy nyílván tartsuk a CPU felhasználás idejét, a processzek élet idejét stb. Bizonyos idQnként ki lehet értékelni az állapotokat, és CPU kapcsolást lehet megvalósítani.


A programozható óra 3 komponensbQl tevQdik össze

oszcillátor kristály: nagy pontossággal periodikus jeleket generál.
számláló: dekremetálást végez a kristály által generált jelekre. Mikor a számláló eléri a 0 értéket, IT generálódik.
tartó regiszter: az óra indulásakor, vagy a számláló 0-vá válásakor tartalma betöltQdik a számlálóba, ezzel szabályozható milyen gyakran keletkezzen IT.


Az óra-eszköz IT-handler-ének feladatai

napi idQkarbantartás
CPU felhasználás idejének mérése
processz idQkvantumának lejártának figyelése
alarm signal generálása
watchdog timer funkció
monitorozás, statisztika készítése


Egy számláló az idQt nyilvántartja óraütésekben, vagy két számláló másodpercekben és az aktuális ütésszámot:
egy fix idQhöz képest
a bootolási idQhöz képest
a rendszergazda által megadott idQponthoz képest.

Az óraeszköz ütemenként növeli a számlálót. A processzhez tartozó számláló ütésenként növelQdik.

LehetQség van arra, hogy külön mérje a kernel és a user szintq CPU felhasználást.

A quantum-ok nyilvántartásához feltöltünk egy számlálót, ütésekben mért értékkel, és ezt az értéket dekrementáljuk. A számláló 0-vá válása jelzi a quantum lejártát.

Adott idQk lejártát tehát a számlálók 0-vá válása jelezheti. Számlálók láncolt listáját tartjuk fenn, a számlálókban a következQ szignál ideje van.




20.) Ütemezési algoritmusok: FCFS, SJF, és a prioritásos algoritmusok



Igénybejelentési sorrend szerinti kiszolgálás (Fist Come -First Served)

Nagyon egyszerq, könnyen megvalósítható algoritmus. A processz készletben (process pool, job pool) létezQ processzek a beérkezésük sorrendjében kapnak kiszolgálást: ha egy elQbb érkezett processz futásra késszé válik (pl.: CPU-lázas szakaszában van), akkor Q kapja meg a CPU-t. Egyszerq, de nagy hátránya, hogy hosszú ideig várakozhatnak processzek, amíg egy CPU igényes processz a CPU lázas szakaszaival végez.



A legkisebb igényq elQször (Shortest Job First) algoritmus

Régi, nagyon egyszerq idQkiosztási algoritmus. Ma is használják ezt az algoritmust, pl. a printer spooling sorok kiszolgálására: itt persze könnyebb a dolog, a legrövidebb nyomtatandó fájl nyomtatása valószínqleg a legrövidebb idQigényq, azt pedig könnyq megállapítani. De a régebbi kötegelt feldolgozásoknál a CPU kiosztására is alkalmazták, miután bizonyítható, hogy az átlagos fordulási idQ (avarage turnaround time) így a legkisebb.

A CPU kiosztás vezérlésénél egyetlen gond, hogyan lehet megmondani elQre, hogy az egyes munkák mennyi idQt fognak igényelni. Erre a válasz.

A régi kötegelt rendszerekben tapasztalati adatokból jól lehetett ezt becsülni. A Job Control Language nyelven adott vezérlQ kártyákon fel is kellett tüntetni a várható, becsült fordulási idQ értéket. Az idQsorozatokkal jellemezhetQ munkák várható idejének becslésére jó szokott lenni az öregedés (aging) becslési algoritmus.

Aging lényege

Valamely munka (szakasz) várható ideje a korábbi idQibQl becsülhetQ, a korábbi idQk súlyozott összegébQl vett átlaggal. A súlyozással azt befolyásoljuk, hogy milyen arányban vegyük figyelembe az egyre régebbi értékeket. Az öregedés lényege: a régebbi idQk egyre kisebb súllyal befolyásoljanak, egyre jobban felejtse el a rendszer a régebbi értékeket, "korosodjon"



Prioritásos algoritmusok

Ha úgy tetszik, a FC-FS illetve a SJF algoritmus egy-egy speciális esete volt a prioritásos algoritmusoknak. Az elsQnél a "korábban érkezés", a másodiknál a "rövidebb becsült idQszakaszom következik" jelenti a magasabb prioritást.
A prioritás a processzek fontossága. Léteznie kell egy prioritási függvénynek, ami a processzek fontosságát jelzik. A prioritás -a fontosság - sok mindentQl függhet: a processz memóriaigényétQl, a processz eddigi CPU használati idejétQl, a processz (várható) összes CPU használati idejétQl, a processznek a rendszerben eltöltött idejétQl, külsQleg adott prioritási értéktQl, a processz idQszerqségétQl (timeliness), ða rendszer terhelésétQl (system load) stb.

A FC-FS algoritmusban a prioritás a processzek érkezési sorrendje volt. A SJF algoritmus prioritása a processzek várható futásideje. Másik, szintén egyszerq prioritás függvény lehet a külsQ prioritásérték, a processz életében ez statikus, nem változik: egy magas statikus prioritású processz megakadályozhatja, hogy más processzek CPU-t kapjanak. Ezért elvárjuk, hogy a prioritásértékek korrekt módon változzanak a processzek élete során.




21.) Ütemezési algoritmusok: ígéretvezérelt, Round Robin, többszintes, visszacsatolásos


Ígéretvezérelt idQkiosztás (Policy Driven Scheduling)

Interaktív rendszereknél jól használható algoritmus. Alapja, hogy mérhetQ a processzek rendszerben

eltöltött eddigi ideje: az élet-idQ, illetve
az ðeddig felhasznált CPU ideje: a cpu-idQ.

A filozófia: reális ígéret, hogy n számú processz esetén egy processz a CPU 1/n-ed részét kapja. Ehhez kiszámítandó az ún. jogosultsági-idQ :  EMBED Equation.3 
Amelyik processznél a cpu-idQ /jogosultsági-idQ arány a legkisebb, annak magasabb a prioritása, az kapja meg a CPU-t.

Az ígéret vezérelt idQosztás speciális esete a valós idejq (Real-Time) idQkiosztás. Itt az egyes processzek kapnak egy garanciát, melyen belül biztosan megkapják a CPU-t, ha igényt jelentenek be rá. A garantált idQ kiszámítása elQzetesen megtörténik, és persze, a garanciával rendelkezQ processzek száma korlátozott.



Roud-Robin scheduling

Egyszerq, korrekt, széles körben használható, könnyen megvalósítható, elég régi algoritmus. Alapja az óra eszköz: segítségével idQszeletekre való osztás.

Módszere: ha valamely processz megkapta a CPU-t, addig futhat, amíg a hozzá rendelt idQszelet (quantum) tart (Ha közben blokkolódik, akkor persze eddig sem). Ha letelik az ideje, a scheduler elveszi tQle a CPU-t (preempt), és átadja egy másik processznek: ez a processz kapcsolás (Context Switch). A scheduler a futásra kész processzeket egy listán tartja nyilván. CPU kapcsolás esetén a CPU-ról lekapcsolt (preempted process) a lista végére kerül, míg a lista elején álló processz megkapja a CPU-t (scheduled process). A listán a processzek "körben járnak". A lista elején álló processznek legmagasabb a prioritása.



Többszintes prioritás-sorokon alapuló scheduling (Multilevel Feedback Queue Scheduling)

A klasszikus Round Robin azt feltételezi, minden processz egyforma fontosságú. Ez persze nem egészen így van! Vannak fontosabb személyek, akiknek a processzei elQnyt kell élvezzenek, valahogy figyelembe kell venni a külsQ prioritásokat is. Persze, a nagy külsQ prioritású processzek nem akadályozhatják meg, hogy a kevésbé fontos processzek egyáltalán ne kapjanak CPU-t, a scheduler által biztosított, processzekhez rendelt belsQ prioritásoknak dinamikusan változniuk kell.

A belsQ prioritásokat a scheduler egy prioritási függvény szerint dinamikusan állítja elQ, amely függvénynek csak egyik paraméter a külsQ prioritás. Azzal, hogy a processzek belsQ prioritása dinamikusan állítandó, biztosítható a korrektség, és egyéb célok is elérhetQk. A dinamikus prioritásszámítással figyelembe vehetQ a processzek memóriaigénye is, a processzek eddig felhasznált CPU ideje, az élet idejük, az idQszerqségük stb. is.

Az elgondolás ezek után a következQ: ha a futó processz idQszelete lejárt, történjen meg a dinamikus prioritás értékek meghatározása, és a maximális dinamikus prioritással rendelkezQ processz kapja a CPU-t. EgyenlQ prioritások esetén képezzünk listákat, és a lista elején álló processz legyen a kiválasztott.




22.) Ütemezési algoritmus a UNIX-ban


A Unix rendszerek szokásos idQkiosztási algoritmusa Round Robin with Multilevel Feedback típusú: a kernel a lejáró idQszeletq processzt lekapcsolja (preempt) és elhelyezi valamelyik prioritási szinthez tartozó sorra.

Ami ebbQl rögtön látható, a processzeknek külön user-mode prioritási, külön kernel-mode prioritási értéke lehet, ezzel a prioritások tartománya is két résztartományból áll. A két tartomány több prioritási értéket foglal össze, mindegyik értékhez egy sor tartozik, amire a hozzátartozó processzek fel vannak fqzve. A user-mode prioritási listákon lévQ processzektQl el lehet venni a CPU-t (ezek lehetnek "preempted" processzek, amikor kernel-mode/user-mode visszaváltás történik). A két prioritási osztály között van a küszöb (treshold) prioritás.


A kernel szintq prioritások tovább osztályozhatók
nem megszakítható és
megszakítható prioritás osztályokra.


A prioritási értéket a Process Table belépési pont megfelelQ mezejében tartják nyilván.


A kernel a következQképpen számítja ki a prioritásértéket

A kernel prioritás egy fix érték, mely attól függ, mi az oka, és nem függ a futási karakterisztikától (pl.: attól, hogy CPU igényes, vagy I/O igényes-e a processz).

A kernel a user mód prioritást (p-usrpri) a kernel módból felhasználói módba váltáskor számítja ki, de az óra megszakítás kezelQ (clock handler) bizonyos idQközönként "igazítja" a prioritásértékeket.

a futó processz p-cpu mezejét az órakezelQ minden óramegszakításkor a CPU használattal arányosan növeli. Ezzel számon tartják, hogy mennyi CPU-t használt a processz.

a fenti p_cpu értéket quantumonként "öregítik" (aging): p_cpu =p-cpu/const1

ezután a prioritás így számítódik ki (a nagyobb érték alacsonyabb prioritást jelent!):
 EMBED Equation.3 
const2 = const3 = 2
PUSER a processz bázis prioritása: külsQ prioritásérték
p_cpu az öregített CPU használat
p-nice a felhasználó által kontrollált nice érték (-20 és +20 intervallumban).
a negatív érték növeli, a pozitív csökkenti a processz esélyét, alapértelmezés a 0.


A p-usrpri egy adott maximális érték fölé nem mehet.


A felhasználó kismértékben befolyásolhatja processzei idQkiosztását a nice() hívással. Ezzel saját processzei között bizonyos kontrollt valósíthat meg, de a processzének esélyeit más felhasználók processzeihez képest is rontja.
A felhasználó javíthatja helyzetét, ha az alkalmazásait több processzben írja meg. Egyes rendszerekben a felhasználó választhat ütemezési stratégiát.






 EMBED Word.Picture.8

prioritási szintek a UNIX-ban




23.) A VAX/VMS és az NT ütemezési algoritmusa



A VAX/VMS scheduling algoritmusa

Elegáns, több megfontolást is figyelembe vevQ megoldása van ennek a rendszernek. A VAX/VMS-ben 32 prioritási szint van, amit két, egyenként 16 szintbQl álló csoportra bontanak. A 31-tQl 16-ig tartozó szintek - minél nagyobb a szint száma, annál nagyobb a prioritás - foglaltak a valós idejq processzek számára. A többi reguláris processz a 0 -15 prioritási szinteken osztozik.

A valós idejq processzekhez rendelt prioritás érték a processz élete során nem változik: statikus az érték. A reguláris processzek prioritási értéke viszont dinamikusan alakul.

Minden processz a keletkezésekor kap egy alap (base) prioritási értéket, ez egyben a processz minimális prioritási szintje.(Az alap prioritás szintet a rendszergazda állítja be. A dinamikus prioritásérték kiszámítása a következQk szerint történik.

Minden rendszer eseményhez hozzárendelt egy prioritás növekmény, aminek a nagysága az esemény jellegétQl függ. Amikor a processz "felébred" valamelyik ilyen esemény bekövetkezésére, a növekmény hozzáadódik a pillanatnyi prioritási értékéhez, és a processz besorolódik a prioritási szinthez tartozó listára.

Természetesen, maximum 15 prioritást kaphat így a processz. A lekapcsolt processz (preempted process) pillanatnyi prioritása, miután elhasználta a rendelkezésére álló CPU idQszeletet, csökken 1 értékkel, és besorolódik az így meghatározott listára. A csökkentésnek is van korlátja, ez az alap prioritás-érték, ez alá a pillanatnyi prioritás nem mehet.

Ezzel a processz prioritása az alap prioritás és a 15-ös szint között változhat. A diszpécser mindig a legnagyobb prioritási szinthez tartozó lista elejérQl választ a CPU kapcsoláshoz.



Ütemezési algoritmus az NT-nél

Létezik egy standby állapot: a legnagyobb prioritású a futásra kész. 32 prioritási szint van. A 31-tQl 16-ig tartozó szintek - minél nagyobb a szint száma, annál nagyobb a prioritás - foglaltak a valós idejq processzek számára. A többi reguláris processz a 0 -15 prioritási szinteken osztozik. Lejárt quantum-ú fonál prioritása 1-gyel csökken (a bázisig), futásra kész állapotba jutó fonál prioritása nQ. A legmagasabb prioritású standby állapotba kerül. Ha nincs ilyen, akkor az idle fonál lesz standby állapotú



24.) CPU allokálás, Process Context Switch fogalom, egy lehetséges algoritmusa


CPU kapcsolás mechanizmusok

A processzek közötti CPU kapcsolás (Process Context Switch) tulajdonképpen azon operáció, mely során az éppen futó processztQl elvesszük a CPU-t és egy kiválasztott futásra kész processznek adjuk oda. Feltételezzük, hogy az ütemezés megtörtént, ki van jelölve a futásra kész processzek közül a nyertes processz..
Az éppen futó processz hardver kontextusát (dinamikus/volatile kontextust) lementjük valahová, a kiválasztottnak kontextusát pedig felvesszük. Legfontosabb a PC (Program Counter) regiszter lementés-felvétel! Szorosan véve, ez a kapcsolás.

Az ide tartozó processz állapotátmenetek

a lementés
o wait/reques/sleept (blokkolódás) állapotátmenetnél; vagy
o preemption (beavatkozás, elvétel) állapotátmenetnél történhet.

a felvétel /schedule/ futásra készbQl futó állapotra váltás állapotátmenetet okoz.

A CPU kapcsolás hardverfüggQ operáció. Egyes architektúrákon léteznek speciális gépi instrukciók, amik a kapcsolást megvalósítják: lementik, illetve felveszik a hardver kontextust. Ezek szigorúan kernel módban végrehajtható instrukciók természetesen.

Egyes processzoroknak több regiszterkészlete van, azok váltásával megtörténhet a kapcsolás, nem is szükséges lementés - felvétel. Igaz, hogy regiszterkészlet váltással nem a processzek közötti kapcsolást szokták megvalósítani – hiszen valószínqleg több processz van, mint ahány regiszterkészlet  hanem megszakítás kiszolgáláshoz a processz kontextusról a rendszer kontextusra való váltást

Ha óramegszakítás kiszolgálásról van szó, akkor elQfordulhat, hogy a megszakítás-kezelQ úgy dönt , szükséges a processz kontextus váltás: ekkor a processz volatile kontextust mégis lementik, a nyertes processz kontextust felveszik, majd a megszakítás kiszolgálásból való visszatéréskor visszaváltják a regiszterkészletet (máris futhat a nyertes processz).
Egyes architektúrákon nincsenek speciális instrukciók erre a célra, nincs több regiszterkészlet sem. Ilyenkor a "szokásos" gépi instrukciókkal kell megoldani a kapcsolást.
Le kell menteni a hardver kontextust. Kérdés merül fel: hova mentsünk le (honnan emeljünk fel)?

Lehetne
a Process Table sorába. Hátrány: nagy lesz a tábla. A lementés/felvétel hardveresen nem biztos, hogy támogatott.
a veremtárba. ElQny: hardveres push/pop is van, ezt kihasználhatjuk. Hátrány: kimerülhet a veremtár.

Az utóbbi az általános! Az biztos, hogy nem a processzenkénti felhasználói szintq verembe menti, de az már rendszerfüggQ, hogy processzenkénti kernel verembe mentenek-e, vagy egy, minden processz számára közös kernel verembe!


A Context Switch lépései

Döntsd el, lehetséges-e a Context Switch.
Mentsd le a kurrens processz dinamikus kontextusát a save_context() algoritmussal.
Találd meg a "legjobb" processzt, ami megkapja a CPU-t (scheduling algoritmusok végeredménye).
Vedd vissza ennek dinamikus kontextusát (a vermébQl a legfelsQ réteget) a resume_context() algoritmussal.



25.) Folyamatok közötti információcsere. Alapfogalmak, elvek


Több folyamatból összetevQdQ alkalmazás esetén alapvetQ mechanizmus az IPC. Multiprogramozású rendszerekben abszolút természetes eszköz. Kooperáló processzek kommunikálnak, szinkronizálják futásukat. Több kommunikációs mechanizmus létezik, ezeket akár együttesen is alkalmazhatjuk.
Az absztrakt probléma kiindulási megfogalmazása a következQ: processz legyen képes üzenetet küldeni processznek, processz legyen képes üzenetet fogadni más processztQl.
A kiindulási megoldás: legyen send(message) és receive(message) rendszerhívás. A processzek között épüljön fel kommunikációs kapcsolat (link).


Ezzel kapcsolatos kérdések

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éretqek lehetnek az üzenetek?
A kapcsolat egy, vagy kétirányú? És ez az irányítottság hogy van, ha több mint két processz van a kapcsolaton?


Az elvi megoldások a következQk

direkt vagy indirekt kommunikáció. Ki a közvetítQ entitás tulajdonosa (kihez kötQdik az entitás)?
szimmetrikus vagy aszimmetrikus kommunikáció
automatikus vagy explicit bufferelés
adatküldés (send by copy) vagy adathivatkozás küldés (send by reference)
fix vagy változó méretq üzenetek





26.) Indirekt kommunikáció jellemzQi


Indirekt kommunikáció

Az üzeneteket mailbox, vagy port mechanizmusokon keresztül közvetetik. A mailbox (postaláda) absztrakt objektum, amibe a processz üzeneteket tehet, processz abból üzeneteket vehet ki. A mailbox-oknak van azonosítójuk. Ha két processz osztozik közös postalá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)


Indirekt kommunikáció jellemzQi

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 elQbb éri el;
akár több fogadó is megkaphat egy üzenetet;
címezhetQ, 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ötQdésére (binding)

A mailbox egy processzhez kötQdik, úgy is mondhatjuk, a processz tulajdona. Ilyenkor rendszerint a tulajdonos processz a fogadó processz. A feladó processzek a postaláda használói. A share hívással válnak használóvá, send hívásokkal tesznek üzeneteket a ládába. Ha a tulajdonos exitál, a postaláda megszqnik. ErrQl a használóknak értesülniük kell.

A mailbox az operációs rendszer tulajdonában van, az operációs rendszerhez kötQdik. Ilyenkor a create hívást kiadó processz (kreátor processz) nem válik tulajdonossá (exitálásával nem szqnik meg a postaláda), de destroy+receive+send hozzáférési jogokat (privilégiumokat) kaphat. Alapértelmezés szerint a kreátor processz beállíthatja a privilégiumait. Bármelyik tehet be üzenetet, bármelyik kiolvashat üzenetet.



27.) IPC mechanizmusok, jellemzQik, összehasonlításuk


A klasszikus message rendszer
Létezik névnélküli és a permanens mailbox koncepció.

CsQvezeték
AlapvetQ, korai Unix koncepció ez. ElsQ megvalósításai fájlokon keresztül történt, a kommunikáló processzek szekvenciális végrehajtásával.

A mai csQvezeték megvalósítás jellemzQi

az implementáció lehet fájlokon keresztül, memórián át stb., a felhasználó számára transzparens módon megvalósítva
FIFO jellegq, azaz
mindkét irányba mehetnek üzenetek;
amit beír egy processz, azt ki is olvashatja, kiolvasva az üzenet kikerül a csQbQl.
a név nélküli csQ csak származás szerint egy processz családba tartozó processzek között lehetséges. A nyitott csQ nyitott adatfolyamnak (stream) számít, a gyermek processzek öröklik a leíróját (descriptor). A felhasználói felület a steram I/O függvényei.

A csQvezetékeken keresztüli kommunikáció szimmetrikus, aszinkron, adatküldéses, változó üzenetméretq jellegq. A névnélküli pipe-ok direkt, a nevezett pipe-ok indirekt, operációs rendszer tulajdon jellegqek.

Fájlokon keresztüli kommunikáció
Szekvenciális processzek közötti, régi, természetes módszer. Természetesem párhuzamos processzek között is lehet fájlokon, adatbázisokon keresztüli kommunikáció.
JellemzQi: indirekt, operációs rendszerhez kötQdQ (operációs rendszer tulajdonú), szimmetrikus, aszinkron, adatküldéses, változó üzenetméretq kommunikáció.

Osztott memória (Shared Memory)
Az operációs rendszerek természetszerqleg használják az osztott memória koncepciót: gyakori, hogy a processz kontextusok kód része osztott memóriában van, nem ismétlQdik processzenként.
Az alkalmazások is használhatják! Mind a kód, mind az adat megosztás megvalósítható! Jellemzés: indirekt, szimmetrikus, adatküldéses, fix hosszú üzenetes, randevú nélküli zéró bufferelt.

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 nem a fájlokon keresztüli kommunikációra gondolunk, hanem arra, hogy lehetséges informálni egy processzt valamilyen tény fennállásáról, vagy éppen a fennállás hiányáról, azzal, hogy létezik-e, vagy sem egy logikai név.
Indirekt, operációs rendszer tulajdonú, aszimmetrikus, fix üzenethosszos, randevú nélküli zéró bufferelt.

Kommunikáció a burok környezete (shell environment) segítségével
Az öröklQdQ környezetet a processzek feldolgozhatják. Ez is egy lehetséges módszer tehát. Direkt, aszimmetrikus, zéró bufferelt, adatküldéses, változó üzenethosszos.

EseményjelzQk, szemaforok
AlapvetQen 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. Indirekt és operációs rendszerhez kötQdQ, vagy direkt és szimmetrikus vagy aszimmetrikus és zéró bufferelt, fix üzenet-hosszú.


Szignálozás, szignálkezelés
A lekezelhetQ szignálok kiküldése, azok lekezelése informáló hatású lehet. Direkt, egyirányú, végtelen kapacitású soros.

Létezik még a BSD socket koncepció, és a Remote Procedure Call mechanizmus. Ezek hálózati kommunikációs mechanizmusok.


IPC mechanizmusok összevetése


* hálózat függQ





28.) UNIX üzenetsor kezelése

A message-queue mailbox jellegq, az OS által ismert, az OS-hez kötQdQ objektum. Az

$ipcs

paranccsal jellemzQi lekérdezhetQk (Az ipcs parancs nemcsak az üzenetsorokról, hanem az osztott memória-és a szemafor objektumokról is ad jelentést).

Általános tudnivalók

msgget()üzenetsor készítés, azonosítás (msgid az azonosító),
msgctl()létezQ msgid-jq sort lekérdez, átállít, megszüntet, kontrollál,
msgsnd()azonosított sorba adott típusú, adott méretq üzenetet tesz,
msgrcv()azonosított sorból adott típusú üzenetet vesz. Amit kivett, azt más már nem érheti el!


Üzenetsor készítés, azonosítás

Minden üzenetsornak van azonosítója és kulcsa. Új üzenetsor készítése során kell választania kulcsot, meglévQ üzenetsor azonosítására használni kell a kulcsát.
Az üzenetsoroknak van tulajdonosa, csoporttulajdonosa: annak a processznek az uid/gid-je, amelyik készítette. A kontrolláló msgctl() rendszerhívással a tulajdonosságok átállíthatók. Az üzenetsor az operációs rendszerhez kötQdik.
Vannak írás/olvasás engedélyezések is a tulajdonossági kategóriákra.
Vannak korlátai (max. méret, max. üzenetszám, stb.).
Vannak paraméterei.


A kreáló/asszociáló hívás: id = msgget(key, flag);

A rendszerhívás célja: kreáljon üzenetsort, vagy azonosítson (asszociáljon rá) meglévQ üzenetsort, hogy azt késQbb használhassuk. Az üzenetsor-használat elsQ 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ésQbbi üzenetsor-kezelQ rendszerhívásokban.
Ha új üzenetsort akarunk kreálni, a key kulcsnak válasszunk egy olyan értéket, amilyen kulcsú üzenetsor nem létezik a rendszeren. Legyen tehát egyedi.
A flag-be beírhatjuk a "hozzáféréseket". A flag=0664 pl.: azt jelenti, hogy mind a tulajdonos, mind a csoporttulajdonos processzel írhatják és olvashatják az üzenetsort, a többiek csak olvashatják. Az msgget() rendszerhívás hiba esetén negatív értékkel tér vissza és az errno változót vizsgálhatjuk, mi is volt a hiba oka.


Az üzenetvétel: int msgrcv(int msqid,void *msgp,size_t msgsz,long msgtyp,int msgflg);

Az msqid-vel azonosított sorról veszi az elsQ üzenetet és elhelyezi az msgp pointer által mutatott felhasználó által deklarált struktúrába. Az üzenet ezzel "kikerül" az üzenetsorból, a sor "átrendezQdik". Az msgsz csonkolja a vett üzenetet.


Az üzenetsor kontroll: int msgctl(int msqid,int cmd,...);

Változatos kontrollálási lehetQséget biztosító hívás az msqid üzenetsorra. A cmd különbözQ "parancsokat" tartalmazhat.



29.) UNIX osztott memória kezelése


A processzek ugyanazon gazdagépen osztott memória szegmenseket készíthetnek/azonosíthatnak (shmget() rendszerhívás), az osztott memória szegmenseket kontrollálhatják (attribútumait lekérdezhetik, megszüntethetik, shmctl() rendszerhívás), illetve a processz virtuális címtartományára leképezhetik az osztott szegmenst (shmat() rendszerhívás), megszüntethetik a leképzést (shmdt() hívás).


A kreáció, asszociáció

Az shmget() rendszerhívás kreál/asszociál adott key kulcsú osztott memória szegmenst, aminek a bájtokban mért hossza size. Az shmflg szerepe nagyon hasonlít az msgget()-beli flag szerephez: rendelkezik a hozzáférésekrQl és a kreálás/asszociálás szétválasztást oldhatjuk meg vele. Egy nem negatív shmid azonosítót ad vissza siker esetén (amit a további hívásokban használhatunk). Sikertelenség esetén negatív értékkel tér vissza (és az errno vizsgálható).


A leképzé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ú pointerváltozó a hívás visszatérési értékét megkapja, és ezután az adott típusú adatszerkezet a pointerváltozó segítségével használható, a típusra vonatkozó korlátozásokkal.
Az shmat hívásban az elsQ argumentum az shmget visszatérési értéke. A második argumentum (shmaddr) azt szabja meg, milyen címtartományra képezzük a szegmenst. Ha shmaddr==NULL, akkor a rendszer által választott elsQ lehetséges címtartományra történik a leképzés. Ha az nem NULL, akkor az shmaddr által adott cím és az shmflg-ben az SHM_RMD-t beállítás együtt szabja meg a címtartományt.
Az shmdt() megszünteti a leképzést. Kiadása után az osztott szegmens nem "látható" tovább. Siker esetén 0-val, hiba esetén -1-gyel tér vissza.


A kontroll

Szerepe hasonlít az msgctl() szerepéhez, elsQsorban az IPC_RMID paranccsal a szegmens megszüntetésére használjuk. Itt is lekérdezhetQk az attribútumok illetve néhány attribútum (uid, gid, mode) "változtatható".




30.) Kölcsönös kizárás, kritikus szakasz, holtponthelyzet. Alapfogalmak, követelmények,
problémák


A processzek közötti kapcsolat lehet együttmqködés jellegq, ez processzközti kommunikációs kapcsolatokat (IPCs) kíván. Ha a kapcsolat konfliktusmentes erQforrás-megosztás, akkor az erQforrásra olvashatóság jellegq hozzáférést kell biztosítani. A vetélkedés erQforrás kizárólagos használatára kölcsönös kizárást, a szinkronizálás ütemezést kíván.

Arról van szó, hogy közös erQforrásokért vetélkedQ, együttmqködQ processzeknek lehetnek kódrészei, melyek futása alatt kizárólagosságot kell biztosítani, vagy amikre ütemezést kell megvalósítani.


A kölcsönös kizárás (Mutual Exclusion) fogalma: a közös erQforrásokért vetélkedQ processzek közül egy és csakis egy kapja meg a jogot az erQforrás használatra.

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.

A belépési szakasz (entry section) a folyamaton belül az a kódrész, ahol kéri az engedélyt a kritikus szakaszba való belépésre, míg a kilépési szakasz (leave section) az a kódrész, ahol elhagyja a processz a kritikus szakaszt. A folyamatoknak természetesen lehetnek nem kritikus szakaszaik is.

A holtpont (deadlock) az az állapot, amely akkor következhet be, amikor két (vagy több) folyamat egyidejqleg verseng erQforrásokért, és egymást kölcsönösen blokkolják.


Kívánalmak a probléma megoldásához

Biztonsági (safety) kívánalom: Valósuljon meg a kölcsönös kizárás: ha egy processz kritikus szakaszában fut, más processz ne léphessen be kritikus szakaszába.(EgyidQben csakis egy kritikus szakasz futhat.). Természetesen, ezalatt más processzek a belépési szakaszukat végrehajthatják.

ElQrehaladási (progress) kívánalom: általában nem kritikus szakaszban és nem belépési szakaszban futó processz ne befolyásolja mások belépését. Ha egyetlen folyamat sincs kritikus szakaszában és vannak processzek a belépési szakaszukban, 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.

Korlátozott várakozási (bounded waiting) kívánalom: ha egy processz bejelentette igényét a belépésre, de még nem léphet be, korlátozzuk ésszerqen azt, hogy egy másik processz hányszor léphet be. Egy processz se várakozzon a végtelenségig belépésre azért, mert egy másik újból bejelentve az igényét megint megelQzi.

Hardver és platform kívánalom: ne legyenek elQfeltételeink a hardverre, a processzek számára, relatív sebességükre, az operációs rendszer ütemezésére stb.

Az absztrakt probléma felfogható, mint egy termelQ-fogyasztó (producer-consumer) probléma

Vannak termelQ folyamatok, melyek terméket állítanak elQ és behelyezik egy raktárba.
Vannak fogyasztó folyamatok, melyek a termékeket kiveszik a raktárból és felhasználják.
Van egy korlátozott termék-raktár. A korlátozás vonatkozhat a raktár méretére A korlátozás vonatkozhat a raktár használatára. A korlátozás a raktárhoz való hozzáférésre kölcsönös kizárási probléma.

A termelQ-fogyasztó problémának ismertek a változatai.



31.) Mechanizmusok a kölcsönös kizárásra: IT letiltás, processzek váltogatása, érdekeltsége,
a "bakery" algoritmus



Megszakítás letiltása (Disabling Interrupts)

A belépési szakaszban letiltunk minden megszakítást, a kilépési szakaszban engedélyezzük azokat.
A megoldás hátránya: csak egyetlen CPU esetére jó (4. számú kívánalom megsértve) és a kritikus szakaszban bekövetkezQ hiba esetén elQáll a holtpont (dead-lock) helyzet.
Ez a megoldá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.

Váltogatás

Ehhez a megoldáshoz szükséges egy osztott turn változó. Ez a változó nyomon követi, azt mutatja, ki következik.
A megoldás megsérti a 2. számú követelményt: a szigorú alternálás miatt egy processz egymás után kétszer csak akkor léphet a kritikus szekció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.

Az érdekeltség nyomon követése

A megoldásban egy osztott tömb jelzi, ki érdekelt a kritikus szakasz (a kizárólagos erQforrás) elérésében. Könnyen kialakulhat holtpont (2. követelmény). Ha ugyanis mindkét processz körülbelül egyidQben bejelenti érdekeltségét, mindkettQ tevékeny várakozásban marad. Pusztán az érdekeltség figyelembe vétele semmiképp sem elegendQ!

Egymás váltogatás az érdekeltség figyelembevételével

A "ki következik" (turn változó) és a "lock változó" koncepciók kombinációja. Dekker algoritmusaként ismert.
Peterson még egyszerqbb módszert ajánlott. Lényegében a processzek váltogatása az érdekeltség figyelembevételével. Az érdekeltség figyelembevétele javítja a puszta váltogatás hibáját. Ha mindkét processz kb. egyidQben lépne be, akkor mindkettQ bejelenti érdekeltségét, majd mindkettQ bejegyzi a turn-be a másik számát. Amelyiknek ez utoljára sikerült, az vesztett!

A Bakery algoritmus: a sorszámosztás
Az algoritmus a nevét egy vásárlókkal zsúfolt pékségben a sorszámosztásos kiszolgálás rendjétQl kapta. A sorszámosztó-eseményszámláló mechanizmus egy alapgondolatát valósítja meg a bakery algoritmus, meglehetQsen egyszerq eszközökkel.
Az elgondolás szerint belépve a boltba minden vásárló kap egy sorszámot, és a legkisebb sorszámmal rendelkezQt szolgálják ki elQször.
A kritikus szakasza elQtt a processz bejelenti érdekeltségét a sorszámhúzásban, majd sorszámot húz. Sajnos, nem garantált, hogy két processz ne kaphassa ugyanazt a sorszámot. Ha ez elQfordulna, akkor az algoritmus szerint a kisebb pid-q lesz a kiszolgált. Miután a processz pid-ek egyediek és köztük a kisebb, mint rendezési reláció egyértelmq, az algoritmusunk determinisztikus lesz. A sorszámhúzás után a processz törli az érdekeltségét a sorszámhúzásra.
A kritikus szakaszból való kilépés egyszerqen a sorszám nullázásával jelezhetQ.

Megjegyzés: Az utóbbi 4 megoldás kiterjeszthetQ több processzre is, így nem sérül a 4. követelmény.



32.) Mechanizmusok a kölcsönös kizárásra. Zárolásváltozó használata. A busy waiting hátránya



Zárolásváltozó használata

Adott egy osztott lock változó, kezdeti értéke false, ami tesztelhetQ és beállítható (false és true értékeket vehet fel). Ha egy processz be akar lépni kritikus szakaszába, teszteli a lock változót. Ha az false, beállítja true-ra, és belép a kritikus szakaszba. Fontos követelmény, hogy a tesztelés és beállítás között a vezérlést ne vehessék el a processztQl, különben megsértjük az 1. számú követelményt.



A TSL instrukció

Sok processzornál létezik egy atomi test-and-set-lock (TSL) instrukció. Behoz egy memóriacímen lévQ értéket egy regiszterbe, és egy true értéket tesz bele, majd a behozott értékkel visszatér. Más processzor nem érheti el a memória rekeszt, amíg az instrukció végre nem hajtódik. Általában a TSL-t végrehajtó CPU blokkolja a buszt, amíg a TSL-t végrehajtja.
A zárolásváltozó a MOVE instrukcióval „tisztítható”. Ha a zárolásváltozó értéke true, valamelyik processz a kritikus szakaszában van. Egy másik processz nem tud továbblépni, egészen addig, míg a kritikus szakaszból ki nem lép az érintett processz.
A hátrány: megsértettük a 4. követelményt, kikötésünk van a hardverre vonatkozólag (nincs minden CPU-nak TSL instrukciója). És még egy probléma: nem feltétlenül teljesül a 3. követelmény: elQfordulhat, hogy egy processz többször megelQz egy másikat.



A SWAP instrukció

Némely processzornak van oszthatatlan "cserélQ" (swap) instrukciója. A zárolásváltozó használat ezzel is megoldható. Itt közben elvehetik a CPU-t a processztQl, de ez nem jelent gondot. Minden processz saját változója a swap-ben kap értéket, ugyanakkor a közös lock is kap értéket. A kritikus szakasz végén a lock a szokásos értékadással kapja a false-t. Itt is sérül a 4. követelmény (nincs minden CPU-nak atomi swap-je), és sérülhet a korlátozott várakozási követelmény is.



A tevékeny várakozás (busy waiting) hátrányai

A megszakítás letiltást kivéve minden eddigi megoldásnál a belépési szakaszban egy-egy processz ciklusban várakozott, hogy végre beléphessen. Mindenesetre használja a CPU-t, hátráltatva más processzeket.
Az ütemezési szabályok szerint a magasabb prioritású processz mindig megkapja a CPU-t, ha igényli. Megkapva a CPU-t, tesztel és vár, és mivel magasabb a prioritása, nem engedi szóhoz jutni az alacsonyabb prioritásút. Nyilvánvaló holtponthelyzet alakult ki. Megoldás persze a dinamikus prioritásállítás, de pl.: valós idejq processzeknél az nem valósítható meg. Más megoldás is kell!
A CPU idQ vesztegetése helyett alkalmazhatunk 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 ellenQriznie a kritikus szakaszba való belépés lehetQségét, de addig is nem vesztegeti a CPU idQt. Ügyelni kell arra, hogy valaki kiadja a wakup-ot.




33.) Szemaforok: Dijkstra szemaformechanizmusa



1965 körül Dijkstra javasolta a szemafor mechanizmust a kölcsönös kizárások megoldására.
kifejezést.

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 fejezQdött, vagy a hívója blokkolódott.

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ó: ezen blokkolódhat a hívója,
UP operáció: ez szignáloz, hogy felébredjen egy blokkolódott

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 lehet tevékeny várakozás is, a szignálozás az ebbQl való kibillentés (spinlock szemafor), de a várakozás lehet az operációs rendszer által biztosított valódi blokkolódás is (sleep rendszerszolgáltatással), a szignálozás a kernel által biztosított wakeup hívással (blokkoló szemafor).
A Dijkstra féle szemafor úgynevezett számlálós (counting) szemafor, de implementálhatunk bináris szemafort is.




34.) Szemafor implementációk (bináris és számlálós spinlock, blokkoló számláló)

Bináris spinlock szemafor megvalósítás

Ez a szemafor false és true értékeket vehet csak fel, és tevékeny várakozással oldja meg a "blokkolódást".

typedef enum{true, false} binaris_szemafor;
binaris_szemafor szemafor1;
_____________________________________________________________________________________________________________________________________________



DOWN( binaris_szemafor szemafor1 )
{
while( szemafor1 = = false );
szemafor1 = false;
}

UP( binaris_szemafor szemafor1)
{
szemafor1 = true;
}




****************************************************************************

Tevékeny várakozású számlálós szemafor
A számlálós szemafor jól használható szinkronizációra.

typedef unsigned szemafor;
szemafor szemafor1;
____________________________________________________________________________________________________



DOWN( szemafor szemafor1 )
{
while( szemafor1 = = 0 );
szemafor1--;
}
UP( szemafor szemafor1)
{
szemafor1++;
}


***********************************************************************************

Blokkolós számláló szemafor

A Dijkstra féle két operációt egy harmadikkal van kiegészítve, az ncount operációval. Ez nagyon hasznos operáció, a szemaforhoz rendelt várakozási soron blokkolt processzek pillanatnyi számát adja vissza.

typedef struct
{
int ertek;
list_of_procs lista;
} szemafor;

szemafor szemafor1;
____________________________________________________________________ .
.


DOWN( szemafor szemafor1 )
{
if( --szemafor1.ertek < 0 )
{
add a processzt a
szemafor1.lista-hoz
blokkolodj, de felébredve
folytasd
}
szemafor1--;
}

UP( szemafor szemafor1 )
{
if( ++szemafor1.ertek < 1 )
{
vedd le a processzt a
szemafor1.lista-ról
ébredj fel
}
}

_____________________________________________________________________________________

int ncount( szemafor szemafor1 )
{
if ( szemafor1.ertek < 0 )
{ return abs(szemafor1.ertek); }
}


35.) Adott problémák megoldása szemaforokkal



TermelQ/fogyasztó probléma megoldása szemaforokkal

Tételezzük fel a következQket

Több termelQfolyamat lehet, számukat nem korlátozzuk.
Több fogyasztó van.
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 korlátozási követelmény: betelt raktár esetén a termelQk blokkolódjanak, üres raktár esetén a fogyasztók blokkolódjanak.

Belátható, hogy legalább 3 szemafor szükséges a megvalósításhoz:

Egy a ki-berakó gép védelmére
Egy az üresség jelzésére
Egy a telítettség jelzésére





36.) A sorszámosztó-eseményszámláló, a monitor. Problémamegoldások ezekkel a
mechanizmusokkal


Sorszámosztó és eseményszámláló (Sequencer &Eventcounter)

Az alapgondolat szerint egy sorszámosztó automata segíti egy szolgáltatás igénybevételének sorrendjét: a fogyasztó "tép" egy sorszámot és vár a szolgáltatásra, amíg a sor rákerül. A szolgáltató egy veremben tartja a kiszolgált fogyasztó sorszámát: annak tetején van az utoljára (vagy az éppen) kiszolgált fogyasztó sorszáma.

A szükséges objektumok és a rajtuk végezhetQ operációk

S: sequencer nem csökkenthetQ integer változó, 0-ra inicializálva.
E: eventcounter sorszámok veremtára.

Operáció S-re:
ticket(S); visszatér a következQ 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.


A termelQ-fogyasztó probléma megoldása ezzel a mechanizmussal

A problémában feltesszük, hogy van egy berakó-és egy kirakógép, azaz korlátozzuk, hogy egy idQben csak egy termelQ, illetve egy idQben csak egy fogyasztó használhatja a raktárt, de egy termelQvel párhozamosan dolgozhat egy fogyasztó (persze, egy másik cellában lévQ termékkel.)
Természetesen termelQ csak akkor használhatja a raktárt, ha van üres cella, fogyasztó pedig akkor, ha van töltött cella.
Az advance(in) és az advance(out) kettQs szereppel bír! Az advance(in) jelzi, hogy töltQdött egy cella: továbbengedhet egy fogyasztót az Q await(in,u+1) várakozásából, és továbbengedhet egy másik termelQt az Q await(in,t) várakozásából. Hasonló az advance(out) kettQs szerepe is.



A monitor mechanizmus [Hoare, Hansen]

A monitor magasabb szintq szinkronizációs mechanizmus: eljárások, változók, adatstruktúrák speciális formájú gyqjteménye. A processzek hívhatják a monitor eljárásait, de nem férnek a monitor belsQ adatstruktúráihoz (információ-rejtés), továbbá biztosított az is, hogy egy idQben csak egy processz használhat egy monitort. A fordító biztosítja a monitorba való 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 nem kell foglakoznia. Ha egy processz hív egy monitorban lévQ eljárást, az elsQ néhány instrukció ellenQrzi, 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 termelQ-fogyasztó problémához például kell a conditon típusú változó, amin két operáció hajtható végre: 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.




37.) A Unix szemafor mechanizmusa. Összevetés a klasszikus szemaforral


A Unix szemafor mechanizmusa blokkoló jellegq, számlálós implementáció. De további jellegzetességek is vannak a Unix szemafor implementációban.

Szemafor készlet lehet egyetlen Unix szemaforban.
Operáció készlet hajtható végre egyetlen 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 operációk nemcsak 1 értékkel csökkenthetnek, növelhetnek (non-unitary-k).
Lehetséges 0 ellenQrzés is.
Blokkolódás esetén természetes, hogy a szemafor elemei az operáció elQtti értéküket visszaveszik (automatikus undo az elemi operációkra).
Eredeti szemafor-elem érték visszaállítás (undo) specifikálható a processz terminálódásához is.


A Unix szemaforokkal kapcsolatos rendszerhívások

semget() szemafor-készítés, vagy meglévQ szemaforra való asszociálás
semop() szemafor operáció.
semctl() szemafor-kontrollálására: inicializálásra, megszüntetésre, pillanatnyi értékek, belsQ
adatok lekérdezésére.

A Unix szemafor elemi szemaforok készlete
Egy egyedi (single) szemafor egy pozitív egész lehetne (0 és 32767 tartományban). A korszerq Unix-ok nem egyedi szemaforokat kezelnek, hanem szemafor készleteket (semaphor set). Egy szemafor készlet kötött számú elemi szemafort tartalmaz.
Az a processz, amelyik semget() hívással készített szemafort, az lesz a szemafor tulajdonosa. P határozza meg a key kulcsot, ami a szemafor külsQ azonosítására szolgál, Q határozza meg a készletben a szemaforok számát, és Q állít be használati engedélyeket (rw) a szemafor készletre (a flags-szel).
Más processzek a semget() hívással asszociálhatnak a szemaforra.

Az engedélyekkel rendelkezQ processzek operációkat hajthatnak végre a szemaforokon (semop()). A rendszerhívás szintaxisa: semop(sid,ops,nops);
A semop a sid szemaforon nsops számú operációt hajt végre (atomi módon). Az 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.
Az elemi operációk indexe is 0 és nops-1 között lehet.

AlapvetQen háromféle elemi operáció lehetséges

inkrementálás (up), ha az op >0,
dekrementálás (down), ha az op <0,
0 ellenQrzés, ha az op =0.

Az up operáció során a megfelelQ elemi szemafor értéke az op értékével növekszik.
Ha az op <0, akkor szükség esetén blokkolódik a hívó.
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 pozitív argumentummal, a down operációban negatív argumentummal hívjuk a semop() system call -t. Ezek az operációk atomiak.
A down operáció nemcsak egyszerq dekrementáció, hanem egyben tesztelés, vajon a szemafor- elem pillanatnyi értéke nagyobb-e a dekrementációs értéknél.
A down operáció lehet ún. "blocking" vagy " non blocking" jellegq, az IPC_NOWAIT flag beállítástól függQen.

Non-blocking jellegq down esetén sikeres teszt után normális a dekrementáció és normális a visszatérés a semop()-ból, sikertelen teszt után a semop() visszatérési értéke viszont -1 és nem dekrementál. A non-blocking down haszna akkor jelentkezhet, ha szemaforral védett erQforrás-használat során ahelyett, hogy várakoznánk a foglalt erQforrásra, valamilyen más hasznos feladatot akarunk megoldani.

Blocking jellegq down esetén sikeres teszt után normális dekrementáció és visszatérés következik, sikertelenség esetén viszont a hívó processz blokkolódik a szemaforon, amíg a szemafor érték meg nem engedi az operációt, vagyis amíg egy másik processz nem inkrementálja a szemafort oly mértékben, hogy a dekrementáció megtörténhessen. A processz tehát akkor kerül le a szemafor várakozó soráról, ha más processzek inkrementálják a szemafort, vagy megszüntetik azt.

A Unix-ok biztosítják a szemaforokhoz az ún. undo (csináld vissza) mechanizmust. Létezik egy undo struktúra, melyekben feljegyzQdnek a blocking operációk, ha a SEM_UNDO beállított (és nincs IPC_NOWAIT).




38.) A memóriamenedzselés: alapok, a memóriamenedzselQ alrendszer feladatai
(címtartományok - memória, allokáció, címleképzés)

A memória igen fontos erQforrás. Bár a gépek egyre nagyobb központi memóriával rendelkeznek, a memóriával mindenképp gazdálkodni kell, mert az alkalmazások is egyre nagyobb memóriát igényelnek.
A memória címekkel rendelkezQ bájtok, szavak készlete. A gépi instrukciók a memóriából vevQdnek 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 ami végül is a buszra kerül, hogy a memória cella tartalma a processzorba jusson (vagy fordítva).

Programjaink több lépcsQn mennek át fejlesztésük során, ebbQl következQen több címkötQdési eset lehetséges. A lépcsQk: a fordítás (compilation), a taszképítés (link), a betöltés (load) és a végrehajtás (run), bármelyikben történhet a címkötQdés.

KötQdés a fordítás során: abszolút cím generálódik már a tárgymodulokban. Ha itt nincs kötQdés, akkor a tárgymodulokban relatív címek generálódnak.
KötQdés a taszképítés során: abszolút címek generálódnak a végrehajtható modulokban, különben azokban relatív címek vannak. Ha relatív címek vannak, akkor a program áthelyezhetQ (relokálható).
KötQdés a betöltés során: a végrehajtható programfájlban relokálható címek a betöltés során "átíródnak", és abszolút címekké válnak. Ha nincs kötQdés a betöltés során, akkor a processz kódszegmensének címei még mindig relatív címek (pl.: virtuális címek).
KötQdés a futás során, dinamikus a kötQdés: A processz kódjában az instrukciók ún. logikai címeket tartalmaznak. A logikai cím lehet relatív cím, virtuális cím.

Az instrukciókban szereplQ címek készlete a logikai címtartomány. 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.
Az operációs rendszerek magjának fontos része a memóriamenedzselQ alrendszer, amelyik szorosan együttmqködik a hardverrel: az MMU -val (Memory Management Unit).
KülönbözQ memóriamenedzselQ sémák lehetségesek, ezek együtt fejlQdtek a hardver és szoftver fejlQdéssel.

Egyik osztályozás szerint vannak olyam memóriamenedzselQ rendszerek, melyek
mozgatják a processzek kontextusát (vagy annak egy részét) a fQ memória és a másodlagos memória között: o ki-belapozó rendszerek;
o ki-besöprQ rendszerek;

nem mozgatják a kontextusokat.

További osztályozás szerint lehetnek:
valós címzésq rendszerek, ezen belül
monoprogramozású,
multiprogramozású rendszerek, ezen belül
fix partíciós,
változó partíciós rendszerek;

virtuális címzésq rendszerek, ezen belül
lapozós (paging) rendszerek,
szegmens-leképzQ, ki-besöprQ rendszerek,
szegmentáló, ki-besöprQ és ugyanakkor lapozó rendszerek.



39.) Valós címzésq rendszerek. Memóriamenedzselés az MS-DOS-ban


Valós címzésq monoprogramozás

A legegyszerqbb séma ez, mely szerint egy idQben egy processz (vagy taszk, job) van a memóriában és az elfoglalhatja az operációs rendszer mellett a teljes memóriát. A program fejlesztése során a fordító-taszképítQ (compiler-linker) valós címeket generál, a cím és memóriakötQdés történhet bármelyik fázisban.

valós címzésq monoprogramozás

Tipikus példa erre a rendszerre a nagyon elterjedt PC az MS DOS operációs rendszerrel. Az MS-DOS-ban ugyan létezhet több processz egyidQben a memóriában, de mindig csak egy aktív belQlük. A .COM fájloknál a kötQdés a betöltés során, az .EXE fájloknál futás során történik.



Multiprogramozás fix méretq partíciókban, szeparált input sorokkal

A memóriának az operációs rendszer által el nem foglalt részét fix méretq részekre, partíciókra osztották. Mindegyik partíciónak saját input sora volt, a programokat (job-okat) az egyes partíciókba kellett fordítani-linkelni. A programozó tehát tudta, hogy milyen címen kezdQdik, és meddig tart egy-egy partíció, a compiler-linker csakis a partícióba tartozó címeket generál. Cím és memória kötQdés a link során történik. A memória kezelés sémája az alábbi ábrán látható.


valós címzés, fix partíciók


Valós címzés fix partíciókkal, közös input sorral

A szeparált input sorokat használó rendszer hátránya volt, hogy maradhattak üres partíciók, noha voltak munkák, csak éppen nem az üres partícióba fordították, linkelték azokat. Ezt kiküszöbölendQ, a fejlQdés következQ lépcsQje a következQ ábrán látható séma volt: a partíciók fix méretqek, de egyetlen közös input sorral. Bármelyik partíció kiürülve azonnal fogadhatta a következQ munkát, ami még belefért.




valós címzés, fix partíció, közös input

Megoldandó probléma volt ennél a rendszernél az áthelyezés (relocation): miután a programozó nem tudhatta, programja melyik partícióba fog kerülni, nem linkelhette programját a partíciókhoz tartozó címhatárok közé. A megoldás a következQ volt: a fordító-taszképítQ eltolás címeket (offset) generált, melyek a program 0 kezdQ címétQl számítódtak. A végleges címet elQá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 partíció kezdQcímét, így elQálltak a betöltött programban a partícióhoz tartozó címek. Másik megoldás szerint a betöltés során nem változtatták meg a címeket, hanem a partíció kezdQcímét betöltötték a szegmensregiszterbe.



Multiprogramozás változó méretq partíciókkal

A lényeg itt is az, hogy a fordító-taszképítQ valós, eltolás címeket generál, a rendszer memóriáját azonban nem osztjuk fel elQre partíciókra. Az input sorba került munkák a szabad területrQl, vagy a már korábban kialakult, a rendszer élete során dinamikusan változó méretq partíciókból igényelnek memória partíciókat. Vannak tehát "szabad" partíciók, és vannak foglaltak. A, B, C munka hogy particionálják a memóriát:



A megoldandó feladatok ennél a rendszernél a relocation és a védelem feladatain kívül az alábbiak.
A munkák helyigényét elQre meg kell mondani, hogy ellenQrizhetQ 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. IdQvel szegmentálódik a memória. Szükség van az üres szomszédos szegmensek összevonására| ¢¤¾ÀÂ



&

'

(

‡

ˆ

™

š

›

¼ ½ Æ Ç Ž’²´ - 1 2 : h{CJ
h{CJ
h{CJ
OJQJ h{OJQJh{h{5CJ\h{5CJ,\hàHÚh{CJ,hàHÚhàHÚCJ, ¼
P
¢
à




'

(

_

‡

ˆ

úúúøóóóøñøñøææææææææññøææñ

Æ hЄÐ^„Ð$a$gdàHڈ

š

›

ï

H
Ì
C q ¼ ½ Æ Ç 00¶`¢öŽ’²´(lýûððððýýûðððýýûðððððððûûýûðð

Æ hЄÐ^„ÐlÒ - 1 2 ‘ [‡Ôþ²:
Æ hЄÐ^„ÐÉÊ0²,œ

kÌ"-o-p-q-r--‚-( X â @!ð!q"·"â"P#“#”#¨#©#ýòòòòòòòòòýýððýòòòòòòòòòòððý

Æ hЄÐ^„Щ#ß#/$|$¿$ %?%{%Ø%&)&W&q&r&t& &¡&¢&°&±&R+T+œ/ž/11ôôôôôôôôôôôôîåàÞÞÜÞ××××××$a$
&
F
&
F„h^„h„h^„h

Æ hЄÐ^„Ðy&Ÿ& &¢&¯&°&±&Ô&ß&:(T(ø*&+(+N+„+°+l,”,<-h-°-Ê-T.ž.æ.
/Î/þ/11ˆ133Œ3¬3ü344’4”4™6š6Ó6Ô6777:õìèßÔÎèÇèÇèÇèÇèÀèÇèÇèÇèÇèÇèÀè·ÇèÎèÇ诩žÎè˜è¯…|¯h{5CJ\h{CJOJQJh{5CJ\
h{NH h{6OJQJ]
h{CJ h{OJQJh{6CJ]

h{5\

h{6]
h{CJ
h{>*CJ
OJQJh{>*OJQJh{h{5CJ\h{5>*CJ\01ˆ122†233ö3ø3ú3ü344’4”4¦5Ó6Ô677::¨:ª:B &
Fa$$a$::¦:¨:ª:=
=Ä?è?þ?@4A6A¶DÊDÐDêD´EÔEÖEØEÚEXFZF\FÄGðG*H,HFH~J€JšJ´JVM^MüMNN:NNºNÞNTPVP(Q8QˆR¨RSSØSøSžT TtU’U–UúòèâÞØÞÑÞÑÞØÞÑÞÑÞÑÞúÊÀ´«ÞÑÞ¥òÞâÞÑÞʝÊÞòè“ÞÀÞâÞÑÞÑÞÑÞÑÞâÞÑÞh{5>*CJ
\h{5>*\
h{CJh{5CJ
\h{56CJ
\]h{56\]

h{5\

h{6]
h{NHh{
h{CJ
h{CJ
OJQJ h{OJQJ
h{CJ:JAÖEØEZF\F*H,HFHvHäHrI~J€JÆK L2LnLœLPMRMVMþMNNN
$
&
F7$8$H$a$

$
&
F7$8$H$a$$a$NTPVPžT TsVCWDWZZœ\\ž\Ÿ\µ\¶\]],]m]¸]¹]ï]€^Æ^È^úúúúúúúúøúøúúúöðððæææðäææð
„Ä7$8$H$^„Ä7$8$H$$a$–UºUVVV(VUV_VaVmVŒV›VæVïVCWXZZœ\Ÿ\µ\¶\]]¸]¹]ï]Æ^È^_z`{`¦`§`¨`½`Ì`Ï`Þ`ù`a6cRcÎdÔdXeZe\e(fJfîf

g`g|gægègPhphrhŠh®hÐhùõùõùõùõùõùõùõïçïçáç×ÒÌõÆçõÆçõ½ç³ïõùõùõ©õ©õ¢ç³ïõùõùõùõœõùõùõù
h{CJ

h{5\h{56\]h{CJ
OJQJh{5CJ\
h{CJ
h{CJ h{>*h{5>*CJ \
h{CJ h{OJQJ
h{CJ
h{

h{6]=È^_H_p_®_`5`z`{`|`§`¨`2cÎdÐdÒdÔdZe\e†fægèg
i

iîjðjýõõõõõõïííëââïïïíëâÝÝâââÝ$a$ $7$8$H$a$7$8$H$$
&
Fa$ÐhÒhi
i

i>iZiÐijjBjDjfjtj²j´jêjîjòj@kBkDk~kšk kÄk*llflm2m4mjmˆm¾mÀmÜmÞm nnnVnWnXnÚnÛnoo2oSo_oxoœo¥oµo¶oãoäoüõüïüõüõüõüõüõüõüéá×ÍüõüõüõüõüõüõüõüõüõüéĹ³üª šüõüõüõü” š
h{CJ
h{CJh{56\]h{5CJ\
h{CJ
h{>*CJ
OJQJh{>*OJQJh{5>*CJ
\h{CJ
OJQJ h{OJQJ
h{CJ
h{CJ

h{6]h{:ðjòjBkDk¬lnnnWnXnÚnÛnooµo¶oãoäoípîpïpñpdrfrhrjrúõìììúúçúìììúÞúúúÞúúúúúúú$„Ä^„Äa$ $a$ $7$8$H$a$$a$$a$äo»pïpñpöpbrdrfrjr°r²r´r`t¨tjvÄvLw€w+x0xqxrxtxˆx‰xŠx´xáx÷xøx&zJz²zÔzÖzôz {{B{D{üõüîæîüæÞÔÊüÞüÞüÞüÁ·ÁüÞÔ±«£˜£˜£ŽŽŽuŽkh{CJOJQJh{CJNHOJQJh{6CJOJQJ]h{CJOJQJ h{6OJQJ] h{OJQJ
h{CJ
h{CJ
h{5>*CJ\h{5CJ\h{5>*CJ
\h{CJ
OJQJ h{OJQJh{5>*\

h{5\

h{6]h{'jr²r´rJsØs\t^t`t¨têt&uhuˆu°uâu2vfvhvjvÄväv(wHwJwLw€wýøîîæøøäÜÜÜÜÜÜÜÜøøäÜÜÜøøä$
&
Fa$$
&
Fa$
&
F7$8$H$$a$€w¾wàwxx)x+xrxsxtx‰xŠx´xJzòzB{D{H{t{v{~}¦B€÷÷÷÷÷òíííëéíãÞÞãÕÕÌÌƾ$
&
Fa$7$8$H$ $7$8$H$a$ $7$8$H$a$
&
F7$8$H$
&
F$a$$
&
Fa$D{F{H{t{v{} }~}¦B€h€l€68:<>v@‚††*†¨†ª†®†°†Þ†à†â†€ˆ‚ˆŠ÷óêäóÞóÖÌÖÆóÀ¸®¢¸—óւvn‚Ö¸óÀ`¸V¸h{NHOJQJh{5>*CJ
OJQJ\h{5>*\h{5>*OJQJ\ h{5OJQJ\h{56\] h{6OJQJ]jåIh{OJQJUh{CJOJQJ h{OJQJ
h{CJ

h{CJh{NHOJQJ h{OJQJ
h{NH
h{CJh{6CJ ]h{jh{U!B€D€F€j€l€68<>@vø>‚@‚

††ª†¬†®†°†à†â†Š ŠúúøöððçßööÚÚöØØØØØÏÉÏÏð7$8$H$ $7$8$H$a$
&
F$
&
Fa$ $7$8$H$a$7$8$H$
&
FŠ ŠtŠ´Š¬‹®‹>Œ@Œ¨©¬­ÅÆÎÐâ‘ä‘\’€’Þ’“’”“”»”¼”½”Ô”<—>—@—p—r—v—€—Зҗؗޗ2š4šöîåîÛ×Ñ×É×Á¹öîöîÑ×®×®×¨× ×—××—×Á„|uîgîöh{56OJQJ\]

h{5\h{5>*\ h{5OJQJ\jÂûh{Uh{6CJ ]jîÒh{U
h{NH h{6OJQJ] h{OJQJ h{OJQJjZŸh{U
h{CJ
h{h{CJ OJQJh{>*OJQJ h{OJQJh{CJ
OJQJ( Š¸ŠöŠ¬‹®‹>Œ@Œ¹Ž§¨ª«¬­ÅÆÎÐâ‘ä‘“““º”»”½”Ó”ùïïùíííííèèèèæùùùùííííííèè$a$
&
F7$8$H$7$8$H$ӔԔ:—<—@—p—r—v—Зҗԗ2š4š ››œœLNRž<Ÿ>ŸÔŸÖŸÈ Ê ž¡ ¡úøøúúøøøøïïïïïïïïïïøïïïïïïï $7$8$H$a$$a$4š8šNš ›››:›<›œœœ@œBœLNRŒŽìîRž<Ÿ>ŸBŸxŸüŸ
 ’ È Ê Î Ô Ö ž¡ ¡'¢(¢)¢L¢O¢R¢T¢q¢r¢t¢™¢øêøàøÒÇøàøÒÇøàøÒÇø½ø¹àøÇøÒÇø½øàøÒÇøàø­ø ø•Ž†Ž¹~ h{OJQJh{5>*\

h{5\ h{5OJQJ\h{6CJ OJQJ]jh{OJQJUh{h{NHOJQJ h{6OJQJ]h{56OJQJ\]h{CJ
OJQJh{56OJQJ\] h{OJQJ/ ¡%¢&¢'¢)¢L¢M¢O¢r¢s¢t¢š¢›¢¾¥À¥ ªªÚªú­ü­®L®N®P®R®V®¢®öööíííççççåçööööööíííööööö7$8$H$ $7$8$H$a$ $7$8$H$a$™¢š¢›¢ž¥ ¥¾¥À¥j§†§ª§Ò§Ø§ì§ö§*¨H¨~¨¶©¸© ªª«H«š«Æ«Ô¬ä¬î¬­¢­Ä­ü­þ­®L®V®`® ®¢®¤®¦®î®ð®öèäÞäØäÑäÑäÑäÑäÑäÞäØäÑäÑäÑäÑäÑäÉä¼´©©“„znh{CJ
OJQJaJh{OJQJaJh{5CJ OJQJ\aJh{CJ OJQJh{5>*OJQJ\ h{5OJQJ\ h{OJQJh{6CJ OJQJ]jxVh{U

h{6]
h{CJ
h{NHh{h{5>*CJ
OJQJ\h{CJ
OJQJ*¢®¤®¦®ð®ò®2¯4¯2±4±š²œ²x´z´¾´À´:¶X·¸Œ¹ž¹öðêöä×Ê×Ê×ÊðÈð»»»»±
&
F7$8$H$

$
&
F7$8$H$a$

$
&
F7$8$H$a$
$„h7$8$H$^„ha$7$8$H$7$8$H$7$8$H$ $7$8$H$a$ð®ò®2¯4¯n¯Ž¯¯¤°¦°ì°ö°2±4±J±L±l±ˆ±š²œ²®²°²¾²À²³³6´8´x´z´¼´¾´À´:¶<¶V·X·¬·®·¸¸Ò¸Ô¸Š¹Œ¹œ¹óèâÞÔÍÞÇÞÍÞâÔÍÞÍÞâÔÍÔÍÞÍÞÇÞ¼´ªœ”Œ”Œ”‚”Œ”‚”Œyh{>*OJQJh{NHOJQJ h{OJQJ h{OJQJh{5>*CJ
OJQJ\h{CJ
OJQJ h{OJQJ h{5OJQJ\
h{NH

h{6]h{56\]h{
h{CJ
h{6OJQJ]h{5>*CJ
\aJ,œ¹ž¹»"»|»~»ª»¬»®» ½¢½

¾ ¾®¾°¾¶¾à¾â¾ä¾úÀüÀHÁZÁˆÁ¦ÁRÂWÂX‰ÎÒÓÃÇÃÝÃpÅtÅ~Åôìáì×ÒËÅì»ì»ì®¤œ’„ì»ìáìáìváìhì»ìáìd]

h{5\h{h{56OJQJ\]h{56OJQJ\]h{5>*CJ
OJQJ\h{CJ
OJQJ h{OJQJh{CJ OJQJh{5CJ OJQJ\h{NHOJQJ
h{CJ
h{5CJ
h{5h{CJ OJQJ h{6OJQJ] h{OJQJh{>*OJ QJ ^J $ž¹0ºîº|»~»¬»®» ¼ö½t¾®¾°¾²¾â¾ä¾^¿pÅtÅêÅìÅîÅ

Æ
Æ9ÇõõõïíëÞÞÞÔïííïËËËËËËíËË $7$8$H$a$
&
F7$8$H$

$
&
F7$8$H$a$7$8$H$
&
F7$8$H$~ÅèÅêÅ

Æ
ÆÆƼÆÒÆÓÆÇ\ÈxȸÈÒÈæÉ
ʀʚÊ:ÌLÌ'ÏEÏ5Ò6ÒòÔ^ւׄזØÈØÚ Ú2Ú3Ú4Ú¨Ú©Ú¡Û¢Û¯Û±ÛòÛôÛ$Ü&Ü]ÜaÜvÜxܖܘܴܶÜÑÜÒ܄Þ÷ðìâÚÏÚÏÚÏÚÏÚÏÚÏÚÏÚÏÚÏÚÅÚìÚâÚÏÚ¿·­§ÚÅÚÅڝڝڝڝڝڝڝړÚh{CJ OJQJh{OJ QJ ^J
h{CJ
h{CJ
OJQJ h{OJQJ
h{CJ(h{NHOJQJ h{6OJQJ] h{OJQJh{CJ
OJQJh{

h{5\h{5>*\89Ç¼Ê¾Ê Í#ÏÖÐbÒòÔ^ւׄ×Ú Ú3Ú4ÚüÚ,ÛEÛlÛ¯ÛòÛ$Ü]Ü^Ü_ÜöööööööðööööîìæÜÜÜÜÒÒÒÒÒ
„ˆ7$8$H$^„ˆ
&
F7$8$H$7$8$H$7$8$H$ $7$8$H$a$_ÜvܖܴÜÑÜÒ܄ކÞèÞêÞ0ß2ßøß²à´àáá

ânâæâøäõõõõïïïïííãÙÙÎíãÄÄõ·
$„ˆ7$8$H$^„ˆa$
&
F7$8$H$

Ƹp#7$8$H$
&
F7$8$H$
„h7$8$H$^„h7$8$H$
„ˆ7$8$H$^„ˆ „Þ†ÞŠÞ°ÞèÞêÞ0ß2ß@ßBßTßVßøßà
àà²à´àáá6á8áDáFáXá

âââ*â,â>ânârâæâêâøäúääéæéêêêËêÚêíêöëÝë×ÓÉݾݾ¶Ý¾Ý¶öÓɨ¨¨¶¨¨¨¶“¶“¶Óƒ{q×Ó¾Óh{CJ
OJQJ h{OJQJh{CJ$OJQJ
h{CJ h{OJ QJ ^J h{6OJQJ]h{56OJQJ\] h{OJQJ h{6OJQJ]h{CJ
OJQJh{
h{CJ
h{56OJQJ\] h{5OJQJ\h{CJOJQJ,øäúääéæéêê¬ì®ì„ñ†ñ:ô>ô˜ôšôœôüõþõHöJözöºö,÷ùùðêèðâð×ððððâðââÍÍ··$
&
F
Æ Ð,„,7$8$H$^„,a$
„h7$8$H$`„h

Ƹp#7$8$H$7$8$H$7$8$H$ $7$8$H$a$7$8$H$íêë-ë.ëZìªì¬ì®ì²ìÐì†í¶í¢î¤î–ð˜ð„ñ†ñˆñ¦ñ>ôJô–ô˜ôLõjõüõþõöHöJöZözöø’øùù.ù:ùDù\ùfùhùlùõñõñõñëãØãõãÎãÎãÄãØãظØãõã­¡˜vãñãñãõãõãñã h{6OJQJ]h{6>*OJQJ]h{>*CJ
OJQJh{>*OJQJh{5>*OJQJ\ h{5OJQJ\h{5>*OJQJ\h{CJ
OJQJh{NHOJQJ h{5OJQJ\ h{OJQJ
h{CJ
h{ h{6OJQJ]+,÷˜÷ä÷’øùhùjùlùzù|ùÚúÜúlünüˆüÎÿÐÿÒÿ ¾ÀÄéééééÜÜÚÔËËÔÔÉÇÔÔÔÔ˾¾ $7$8$H$a$ $7$8$H$a$7$8$H$
$„\7$8$H$^„\a$$
&
F
Æ Ð,„,7$8$H$^„,a$lùxùzù|ù`ú|ú¸úÒúàúüúþúÀûÞûæûü>üLülünüvüˆü”ÿ–ÿÎÿÒÿîÿ 4P¾øîãÛÐÛÐÛÁ³ÛÐÛ¥ÛÐۚ’‹‡‡vjaãWÛÐÛh{CJ
OJQJh{>*OJQJh{5>*OJQJ\ h{5OJQJ\
h{NHh{

h{6]h{6>*]h{>*CJOJQJh{56OJQJ\]h{56OJQJ\]h{56>*OJQJ\] h{6OJQJ] h{OJQJh{>*CJ
OJQJh{CJ
OJQJ h{OJQJ-¾ÀÂÄ"&ÊÌ "$>:>­®p
r
Š
Œ
Ú
Ü
Þ
â

h
¨
Ô
Ö


B

ˆ

öêâÕâÊûʱ«¡™•«ƒƒypy•Ã•Ã•jâ_â h{6OJQJ]
h{CJ h{>*OJQJh{CJOJQJh{NHOJQJ h{OJQJh{h{6>*]h{6>*CJ]
h{CJ
h{5>*\aJh{5>*\

h{5\ h{5OJQJ\h{6CJ OJQJ] h{OJQJjA’h{OJQJUh{CJ OJQJ!ÄÊÌÎ "$>¨¢à:<>Š
Œ
Ü
Þ
öëåååååÛÛÈÈÈÈÈÈååÂÂÂÂ7$8$H$
&
F
Æ Ð8„87$8$H$^„8
„h7$8$H$^„h7$8$H$

Ƹp#7$8$H$ $7$8$H$a$Þ
d
Ô
Ö
ˆ

Š

ô

`
b
^ ` ô F¢êì>@Ê̆þõõïïåÛÛïïåÛÍÍÛïÄÄÄÄÄ·

$
&
F7$8$H$a$ $7$8$H$a$ „h„Ä7$8$H$^„h`„Ä
&
F7$8$H$
„h7$8$H$^„h7$8$H$
„Ä7$8$H$`„Ĉ

Š

.
0
`
b
^ ` ô ø FJ ¢êì02>@*€’¢ÊÌ*,.º¼ÐÊÞÂþ:~FröîäîÚîöîÐîÐîÈî¾îäî¾î³î³î©žî³î•‰³î³îsîÐîoh{h{5>*CJOJQJ\ h{OJQJh{6>*OJQJ]h{>*OJQJ h{5OJQJ\h{CJ
OJQJ h{6OJQJ]h{CJOJQJ h{OJQJh{OJ QJ ^J h{CJ OJQJh{NHOJQJ h{OJQJh{CJOJQJ)þp,.0¼Ê¾ÀÂÄþ~@BDFtvjlòòéééßßÙÙ××ÙÙÙÙÙÙ×ÙÙÙÙÌ

Ƹp#7$8$H$7$8$H$
&
F7$8$H$ $7$8$H$a$

$
&
F7$8$H$a$rtvz†
JLNhjl‚„ - -¤ ¦ Æ È Ð!Ö!ž"ª"ü"8#V#Z#Â#Æ#$$$úìäÕäËäÁ·®ä¤˜ä·”Áä‰ä·”úä‰ä‰ä{ä¤ä¤äpdh{5>*OJQJ\ h{5OJQJ\h{56OJQJ\] h{6OJQJ]h{h{CJ OJ QJ ^J h{OJ QJ ^J h{>*OJQJh{CJ
OJQJh{CJOJQJh{NHOJQJh{5CJOJ QJ \^J h{OJQJh{5>*CJOJQJ\
h{CJ$l‚„¤ ¦ Æ È &!œ!"j"ö"V#Â#$$$$5$6$ˆ$‰$£$ýòòòðîäääÚääÌÌÆÆÆÄÆÆÆÆ7$8$H$ „Ä„Ä7$8$H$^„Ä`„Ä
„Ä7$8$H$^„Ä
„Ä7$8$H$`„Ä

Ƹp#7$8$H$$5$6$ˆ$‰$ $¡$£$¤$â$ã$î$ï$”&–&â'ê'î'œ( (Ô)ä)f-€-à-.d.˜.Â.Ä.Æ. / /"/2/øîêãÞêÔȼ¶ê¬¤š¤ˆ€¤u¤u¤u¤u¤f¤W¤uh{56>*OJQJ\]jYÃh{5OJQJU\ h{6OJQJ]h{5>*\

h{5\ h{5OJQJ\h{NHOJQJ h{OJQJh{CJOJQJ
h{CJ
h{CJOJ QJ ^J h{CJOJ QJ ^J h{OJ QJ ^J h{>*
h{>*CJ
h{h{CJOJQJ h{OJQJ"£$¤$â$ã$î$ï$f'Þ'â'œ(ž( (Â.Æ.È."/x/0u0v0¨0í0!1
2õõïíïäïïïïïäÛïïÑÑÑïïÇÇÇ
&
F7$8$H$
&
F 7$8$H$ $7$8$H$a$ $7$8$H$a$7$8$H$
„Ä7$8$H$`„Ä2/x/ˆ/0!0[0\0•0§0»0í0ü0!1)1
22r2–2˜2ô4ø5ü56

6 6Ò6Ô6Ú6Ü6ì6î687:7L7N7Ì8Í8B:D:z:†:ð:þ:V;n;p;¨;ª;Â=øíøíøãøÔíøíøíøíøÆíø¸øÆíø¨ÆíÆíø¨Æíøãø¸øíøžø’†zøh{CJ OJ QJ ^J h{CJOJ QJ ^J h{CJ
OJ QJ ^J h{OJ QJ ^J h{56CJOJQJ\]h{CJ
OJQJh{h{56OJQJ\]h{56>*OJQJ\]h{NHOJQJ h{6OJQJ] h{OJQJ0
2\2^2˜3ô4ø5ú5ü5Ò6Ô687:7B:D:þ:R;T;V;n;p;Š;ª;¬; ?õïææàïïïïïïææææææÞÔÔÇææ
$„Ä7$8$H$`„Äa$
„Ä7$8$H$`„Ä7$8$H$ $7$8$H$a$7$8$H$
&
F7$8$H$Â=>> >?j?n?jAlA’AšAžA¢A°AÒAB
BŽBBB’B—B˜BDJDTD^D EEÔEÖEØEúG"J2JŽJœJ NNNFNõíõíáÓíɾ²í²í²í¾ª¦›íõíõííõ¦uo¦íõíõíug¦jh{U
h{CJ
h{CJ OJQJh{56OJQJ\]h{56OJQJ\] h{5OJQJ\h{h{5>*\h{CJOJ QJ ^J h{5OJQJ\h{CJ
OJQJh{5>*CJOJQJ\h{5>*OJQJ\ h{OJQJ h{6OJQJ]( ???l?n?®?f@h@jAlABBjBŽBBBJDLDEÔEÖEØEúGüG–KööööééööööööÜöÖöööÐöÐÐöö7$8$H$7$8$H$
$„Ä7$8$H$`„Äa$

$
&
F7$8$H$a$ $7$8$H$a$–KsL NNNNPNRNüNþN‘P’PyQzQ|Q·Q¸Q¹QxRzRºR¼R8STT¥TöööíööööççççÞçççççççÔÔçç
&
F7$8$H$ $7$8$H$a$7$8$H$ $7$8$H$a$ $7$8$H$a$FNHNJNLNNNRNVN\N^NþN³P¶P QQ|Q‚Q·Q¹QzRºR¼RŽT›TŸT¢T£T¦T§TªT°TÔTÕTØTöTòV

W–WðèàØÎØÀµØ­Ÿ­Ÿ­”Œ…Œwmm…­”Œ…bØbØ h{5OJQJ\h{56\]h{5>*CJ
\h{

h{5\h{5>*\ h{5OJQJ\h{56OJQJ\] h{OJQJ h{6OJQJ]h{56OJQJ\]h{CJOJQJ h{OJQJjh{Uj¬þh{UjZ¡é@
h{CJ UVaJ $¥T¦T§T©TªTÕTÖT×TØT–W˜WX Xj[l[ª]¬]®]^^\^_`ùùùùùùùùðððððððêêêàÖÉÉ

$
&
F7$8$H$a$
&
F7$8$H$
„h7$8$H$^„h7$8$H$ $7$8$H$a$7$8$H$–W˜WX XRXbXªY¬YŠZ²Z0[H[j[l[ö[
\2\T\°\Ê\]]ª]¬]^^º_¼_Ô_Ö_``6`8`x`z`”a–aÜaÞaBcDcÖcØc d:dXd ee°höîöîãîÙîãîãîöîãîãîãîÙîÌÁöîÙîÙ¡–ööîÙ~ˆîÙîh{56\]h{h{CJOJQJ h{6OJQJ]h{5CJ OJQJ\ h{OJQJ h{5OJQJ\ h{5OJQJ\h{5CJ
OJQJ\h{NHOJQJ h{6OJQJ] h{OJQJh{CJ
OJQJ1```6`8`x`z`Ð`”a–aÜaÞanbÖcØcðiòiôiôîìîÝÓÀÀ¶ÝÓ î——î $7$8$H$a$$
&
F

Æ Ð8„87$8$H$^„8a$
„h7$8$H$^„h
&
F
Æ Ð8„87$8$H$^„8
„Ð7$8$H$^„Ð
Ƹp#„h7$8$H$^„h7$8$H$

Ƹp#7$8$H$°h²hzi|iìiòiúiHjJj

l lzm²n´n¦q¨q¤u¨uìuîuðu wwÀx†yŠy”yêyìyðyhzjzš{œ{h|j|D~F~rtò€ó€L†l†¸ˆºˆà‰â‰þ‰Š Ž¬Žöîöîêß×ÊêÀîêÀêÀîß׶¨îÀêîꡙ¡êדîÀîöîöîöîöîßîöî“êî‚ h{5OJQJ\
h{CJ
h{CJ
h{5>*\

h{5\h{5>*CJ
OJQJ\h{CJ
OJQJh{CJOJQJh{5CJ
OJQJ\ h{OJQJ h{5OJQJ\h{ h{OJQJh{NHOJQJ3ôiöiøiúiüiHjJj

l lzm²n´n¦q¨q¤u¦u¨uªuîuðu wwÀx„y†yŠyìyùùù÷÷ùñèèñèñèèèèââèèèñèèèù7$8$H$ $7$8$H$a$7$8$H$7$8$H$ìyîyðyhzjzš{œ{Š|Œ~ȂZ„L†N†à‰â‰þ‰Š2Š˜ŠÀ‹@Œùù÷õììßßßßßßßÔìÏÏʽ½½½

$
&
F
7$8$H$a$$a$$a$

Ƹp#7$8$H$

$
&
F
7$8$H$a$ $7$8$H$a$7$8$H$@ŒBŒšŽœŽ Ž@BDœžà‘d”B—ú›ÊœÖžØžÚžtŸvŸˆ£Š£Œ£ê£ì£™¨×¨‚¬ööööööööööööööööööööööðöêöö7$8$H$7$8$H$ $7$8$H$a$¬Ž>@Dœž¾‘š–þ–È—æ—jœšœÔžÚž8Ÿ:ŸtŸvŸ¨ŸÊŸòŸ: ê¡ì¡,¢`¢Œ£ê£ì£¥¦™¨ ¬¬ˆ¬Œ¯’¯¢¯0°@°B°>±T±÷ðìàÒÊ¿Ê¿Ê¿Ê¿Ê´à¦àÒʿʿʜʿʔ‡ììʜÊìÊrÊr¿Êrh{5CJOJ QJ \^J
h{NHh{5CJ
OJQJ\ h{OJQJh{NHOJQJh{5>*OJQJ\o( h{5OJQJ\ h{6OJQJ] h{OJQJh{5>*CJ
OJQJ\h{5>*OJQJ\h{

h{5\h{5>*\,‚¬„¬†¬ˆ¬Š¬Œ¯Ž¯à°â°t±v±²²«´¬´-µ.µÍµÎµ{¶|¶L¸N¸R¸¹öööððöööööðööööööööâöööö
$
Ƹp#7$8$H$a$7$8$H$ $7$8$H$a$T±v±²² ²"²R²d²l²t²Š²Œ²®²¸²³ ³´´´:´¬´å´÷´-µ.µ/µ0µ7µ8µ@µÐµ×µ¶‰¶´¶µ¶¿¶Â¶ç¶è¶ò¶ö¶R¸^¸,¹.¹øðåÝÒÃÒøÒÝÒÝÒøÒøÒøÝøåðøÒÝÒµÒÝø§ø§øÒøœø’øÒø‡x

h{5\h{5>*\ h{5OJQJ\h{NHOJQJ h{6OJQJ]h{56OJQJ\]h{56OJQJ\]h{5CJOJ QJ \^J h{6OJQJ] h{OJQJ h{5OJQJ\ h{OJQJ h{OJQJ-¹.¹0¹2¹nºpº»j»ª»’¼”¼œ¾ž¾ÃÃHÆÇÊǘȚȎʐʒÊòéééééÜÜÜÖÖÖéééÉÉéééÃÃ7$8$H$

$
&
F
7$8$H$a$7$8$H$

$
&
F

7$8$H$a$ $7$8$H$a$
$„Ä7$8$H$`„Äa$.¹2¹nºpºàºúº»L»’¼”¼ž¾\¿^¿ìÀîÀ|Â}ÂÃÄÈÄÊÄFÅXÅdÅzŘȚÈHÉzÉÊ(ʒÊËË>Ë@ËXË Ì"Ì8̶̸ÌÊÌBÍDÍVÍXÍ^ÍÎÎΦΨβѴÑÔ Ô4ÔÕÜÕüôêôÞôÓôÍüôÃôÃôÃô¹ôÃôÓôÓô¹ôÓôÓô«êÞ¡–ô¹–ô¹–ô¹–ô–ô¹–ôêôÃôÃôüô h{5OJQJ\h{CJOJQJh{56OJQJ\]h{CJOJQJh{NHOJQJ
h{CJ
h{6OJQJ]h{5>*OJQJ\h{CJ OJQJ h{OJQJh{;’ÊËË>Ë@Ë Ì"̶̸ÌBÍDÍÎΦΨÎÑÑÑ4ԖÔÕùùùïâÕâÕâÕâÕâùÌÌÌÌ¿¿


&
F 7$8$H$gd{ $7$8$H$a$
$„87$8$H$^„8a$

$
&
F7$8$H$a$
„87$8$H$^„87$8$H$ ÕÜÕÞÕàÕÚÖÜÖV×ØBØþØ Ù"ÙÎÚÐÚþÜÝ݂݄ÝòìììâÕ˽¯¡âÕâÕììŸì „Ä„Ä7$8$H$^„Ä`„Ä „Ä„¤7$8$H$^„Ä`„¤ „h„ 7$8$H$^„h`„
„h7$8$H$^„h


&
F7$8$H$gd{
„¤7$8$H$^„¤7$8$H$


&
F 7$8$H$gd{ÜÕàÕæÕ

Ö4Ö6ÖÚÖÜÖúÖ

× ×V×Z׌×BØFØ`Ø Ù"ÙJÙLÙÎÚÐÚäÚæÚþÜ݂݄Ý`ÞTà

â
âÁâÂâjãtãƒãã¼æ¾æªç¬ç¬è¸èöîâÓÈî¾°¢Èî˜Èî˜Èî¾¢Èî¾¢Èîö”†””¾îÈîÈ€”y

h{5\
h{CJh{5>*CJOJQJ\h{h{OJ QJ ^J h{56OJQJ\]h{56OJQJ\]h{CJOJQJ h{6OJQJ]h{56>*OJQJ\]h{5>*OJQJ\ h{OJQJh{CJOJQJ,„Ý`ÞæÞ àPàTà

â
âÁâÂâ¼æ¾æªç¬ç¨è¬èéééNëPëRë´ë¶ëëÛÛÛÕÏÆÏÆÆÆÏÏÏÏÏÏÏÏÏÏÏÏ $7$8$H$a$7$8$H$7$8$H$$
&
F7$8$H$a$gd{ $
&
F
Ƹp#7$8$H$a$gd{¸èéRë´ë¶ë^î®î°îvï€ï¦ïÂï‚ò„ò(ó*ó¨õ´õ4ö6ö:öÌöÎö&ù(ùú

ú‚ú„ú8ûfûNýPýlý˜ýîýðýÿ
ÿ–˜´¶”Æ÷ó÷éó÷éóßóßóÙóÙóÒ÷ÒóƸó²óª¢œó‘ó²ó‘󇪁óÙßuó¢h{56CJ\]
h{CJh{CJOJQJ h{6OJQJ]
h{CJ h{OJQJ h{OJQJ
h{NHh{5>*CJOJQJ\h{5>*OJQJ\

h{5\
h{CJ
h{56\]h{5>*CJ
\h{h{5>*\,¶ë>ì(íZî\î^î®î°îÚîïvï¦ïÔïðððøð$ñXñ¼ñ¾ñ‚ò„ò(ó*óvôxô¢õõõõïïïïõõõõõõïïïõõõïïïïïïïï7$8$H$
&
F7$8$H$¢õ¤õ¨õ6ö8ö:ö<öÌöÎöúú
ú

ú‚ú„úîýðýÿ
ÿ–˜´¶Ž’”ùùùùùðððùðððêèùððùùùùùùùùù7$8$H$ $7$8$H$a$7$8$H$”ÆȖ,
.
Ï

Ð

Ò

+
,
-
l n 68”êì8$& ¢ ý÷ñèèñññññ÷÷÷èÛËËèèèèè÷$
&
F7$8$H$a$gd{
$„h7$8$H$^„ha$ $7$8$H$a$7$8$H$7$8$H$ÆȖš® 0 Ô Ö à â ,
.




Ò

Ø

*
+
,
l n 68n€˜šØèêì.2â
0ñíåÚåÚåÐåÈåÐå¾í¸í±©±íž’…å{åÚåÈåÚå{åÚåÚåoåjh{OJQJUh{CJOJQJh{5CJ
OJQJ\h{5>*OJQJ\ h{5OJQJ\h{5>*\

h{5\
h{NHh{CJ
OJQJ h{OJQJh{NHOJQJ h{6OJQJ] h{OJQJh{h{5>*CJ
OJQJ\)0246dtv˜$&„œ &¸Ô6 d ¤ Ò Ô Œ˜
ÈØtˆ
1;[b‘œ²¸ÌÒqÉðâÖÎÃÎÃιήÎÃÎÃÎÃή¦ ΔΊ”ÎÃÎÃÎÃÎÃÎÃÎÃÎÃÎÃÎ~h{5>*OJQJ\h{CJOJQJh{6>*OJQJ]
h{CJ
h{OJQJ h{5OJQJ\h{CJOJQJ h{6OJQJ] h{OJQJjh{OJQJUjh{EHêÿOJQJUj2åê@
h{CJ UVaJ ,¢ ¤ ¦ Ò Ô
nopqÉÊHJ² ´ # #$#p#r#t#&%(%p)ù÷÷õììììììùùìììììììùáùììì

Ƹp#7$8$H$ $7$8$H$a$7$8$H$ÉÊDlØÚä HJ$ Z d z „ ˆ Š ² ´ $#0#n#p#Ü#&$&%(%ˆ%°%À%î% 'Ê'))4)B)X)j)p)r)Ø)ô)ö)P*R*Ð*Ò*++|+ñéÞéÔéÞéÊéÞéÞéÞ½ÞéÊ鲦²éÞéœéÞéÞéÞéÔéÞéÞ閒éÔ霒Œ’é’
h{NHh{
h{CJh{CJOJQJh{5>*OJQJ\ h{5OJQJ\h{6NHOJQJ]h{CJOJQJh{NHOJQJ h{6OJQJ] h{OJQJh{5>*CJ
OJQJ\3p)r)t)Ø)*P*R*T*+++|+~+È,Ê,Z.\.¨/ª/D0úúúêêáÛÛááÙÓƼƲ¥²¥


&
F7$8$H$gd{
„87$8$H$^„8
„h7$8$H$^„h


&
F7$8$H$gd{7$8$H$ 7$8$H$ $7$8$H$a$$
&
F7$8$H$a$gd{$a$|+~+‚+¤+È,Ê,à,-Z.\.¨/ª/D0F011*1,1.10121>1F1R1^1h1Î1Ø12 2Â5Ä5C6I6J6a6b6c6e6f6ƒ6îæÛæÑæÛæÑæÑæÑæÅ涨Åææææææ“揇xp‡gh{6CJ ]jöh{Ujþê@
h{CJ UVaJ jh{Uh{h{NHOJQJ h{5OJQJ\jxh{EHêÿOJQJUj©éê@
h{CJ UVaJ jh{OJQJUh{CJOJQJ h{6OJQJ] h{OJQJ!h{56>*CJ
OJQJ\](D0F0ø021^1Î12X2¬2­2®2ã2ä2å2Z5C6D6E6F6G6H6õèÚÌÌÌ»»²²²²²²²²²²²² $7$8$H$a$$„ˆ„Ä7$8$H$^„ˆ`„Äa$ „ˆ„Ä7$8$H$^„ˆ`„Ä „Ä„Ä7$8$H$^„Ä`„Ä


&
F7$8$H$gd{
„87$8$H$^„8 H6I6d6e6„6†6‡6¶6·6¸6¹6Ú6Û6š:œ:þ;<ð=ò=Z@\@BB>D@DöíííööööççáöööÛöööÛÛÛÛÛç7$8$H$7$8$H$7$8$H$ $7$8$H$a$ $7$8$H$a$ƒ6‡6‹66µ6¶6·6¹6Ú6Û6š:œ:þ;DDD‚D„DœDªD@EàGîG"H&H2H9HCHEHIHKH”H•H—H³H´HøíæÞíøÓ˽ø³¯³ø¤ø¤øšø³¯”¯”¯ø¯Ž¯„¯øyøíøyø¯íæÞíøˎ h{6OJQJ]h{56\]
h{CJ

h{CJh{NHOJQJ h{6OJQJ]h{h{CJOJQJh{5>*CJ
OJQJ\ h{OJQJ h{5OJQJ\h{5>*\

h{5\ h{5OJQJ\ h{OJQJ/@DBDDD‚D„DCHEH•H–H—H³H´H€K¯L°LÙLÚLåL MbMcMôôîìãÝôôôÛìãããÖɹ¬¬É
$„Ä7$8$H$`„Äa$$
&
F7$8$H$a$gd{
$„h7$8$H$^„ha$$a$7$8$H$ $7$8$H$a$7$8$H$

Ƹp#7$8$H$ ´HÉH×H
LLCLML¯L°LÙLÚLÜLäLåLçLúL M"M-MbMcMeMmMoMyM`NbNîN"O,P-P(S*SúT VVV VÎWÐWjYlYšYÌYøíøíøíøãßãøÑøÇíøÇíøãøÑøíø½øíø³ß³ßø¥–‹ø…ßßw h{OJQJ
h{NH
h{CJ h{6OJQJ]h{56>*OJQJ\]h{5>*CJOJQJ\h{CJOJQJh{CJ

OJQJh{OJ QJ ^J h{56OJQJ\]h{h{CJOJQJ h{6OJQJ] h{OJQJ+cM`NbN,P-P(S*SúT¦U VV VWÎWÐW–Y˜YšYÌYÎYïæææàæàæÒÒÒïïææÌÁ»æ7$8$H$

Ƹp#7$8$H$7$8$H$
$
Ƹp#7$8$H$a$7$8$H$ $7$8$H$a$$
&
F7$8$H$a$gd{ÌYÎYŒZªZ\<\X\^\j\Ø\Ú\Ü\l^n^¸_Ú_ `B` `º`Â`ä`Bara‚a¼a¾a‚b„bØbÚbJcLc˜dØdÚdg&g*ghgjgngšgœg¸gÆgÔgÞgúhûh ii+iñéÞéÞéÚÓËÓÚéÚéÞéÞéÞéÞéÞéÚ½é³é³é³éÚ½é¨ÓËÓÚ ”éÞéÞé³éŠÚh{CJOJQJh{5>*OJQJ\ h{OJQJ h{5OJQJ\h{NHOJQJh{5>*CJ
OJQJ\h{5>*\

h{5\h{ h{6OJQJ] h{OJQJh{5>*CJOJQJ\4ÎY"ZÈZ†[Z\^\Ú\Ü\Þ\_d`‚a„a†a¼a¾a"b®b(c¶c”d–d˜dØdïïïïæææàæææÞÜÞàÌÌÌÌÌààÞ$
&
F7$8$H$a$gd{7$8$H$ $7$8$H$a$$
&
F 7$8$H$a$gd{ØdÚdžeøeBfÔfggggjglgngšgœg ii+i;iLi[iri‹iŒiiùéééééùàààààÞùùùÜÒÒÒÒÒùù
„Ä7$8$H$^„Ä $7$8$H$a$$
&
F7$8$H$a$gd{7$8$H$+i‹iijjúlþlXmZm^mœmvnxnÈnÒn

o oäoæop pptpÒpÞps sLsRs^s¾sÀsÂsÄstDtTtjtöìèÚÒÇ»ìҰҦҘҘҦҏҰҘҦÒ舀ˆèxmÒbÒ h{6OJQJ] h{6OJQJ] h{OJQJh{5>*\

h{5\h{5CJ \h{56OJQJ\]h{NHOJQJ h{5OJQJ\h{5>*OJQJ\ h{5OJQJ\ h{OJQJh{6>*CJ
OJQJ]h{h{CJ OJQJh{CJOJ QJ %ijj†jk¦kþkXlúlülþlmXmZmp pNsRsÀsÂsÄsý÷êêÝÝÝê÷÷÷÷ÐÀÐÀ···±7$8$H$ $7$8$H$a$$
&
F7$8$H$a$gd{
$„h7$8$H$^„ha$


&
F7$8$H$gd{


&
F7$8$H$gd{7$8$H$ Ästjtlt‚tšuœuìuîuÔvúv@wêwêyìyŠ{Œ{Î{}J~L~ùððêðååàÐÀÀÀÐððððºð´7$8$H$7$8$H$$
&
F7$8$H$a$gd{$
&
F7$8$H$a$gd{$a$$a$7$8$H$ $7$8$H$a$7$8$H$ jtlt‚tšuœuìuîuyyêyìyŠ{Œ{Ì{Î{}J~L~Œ~€U€^€»€¼€Ü€ƒƒ„ƒÐ„Ò„…‡ ‡L‡>ˆ@ˆVˆ†ˆˆØˆ,‰2‰n‰p‰r‰t‰”‰¨‰öòêäòäêòêÚêöÌÁòêöÌòêµêöªêöÌêÌêÁÌêÁ•Á•Á•Á•€ÁÌÁj`h{5OJQJU\
h{CJ h{OJQJh{5CJ OJQJ\ h{6OJQJ]h{6>*OJQJ] h{5OJQJ\h{56OJQJ\]h{CJ
OJQJ
h{CJ
h{OJQJh{h{CJ OJQJ/L~Œ~€»€¼€Ü€,‚ƒƒ„ƒÐ„Ò„…‡‡ ‡L‡>ˆ@ˆ.‰0‰2‰n‰p‰t‰”‰öðööêööööööööäääääöÛÛÙ×Ûä $7$8$H$a$7$8$H$7$8$H$7$8$H$ $7$8$H$a$”‰–‰˜‰œ‰Ø‰Ú‰€Š‚ŠŽŠŠ¼‹¾‹è‹ê‹fŒøŒ‚@ŽBŽDŽ‚Ž„ŽÆ‘’ùùùùùùïïïùùíùààààùùíÞÎÎÎ$
&
F7$8$H$a$gd{


&
F7$8$H$gd{
„Ä7$8$H$`„Ä7$8$H$¨‰Ö‰Ú‰Þ‰ú‰€Š‚ŠŽŠŠ¼‹¾‹è‹ê‹ú‹fŒvŒ¨ŒªŒøŒ‚’@ŽDŽ‚Ž„ŽB‘D‘J’L’²’ä’è’““¦”¶”ȔΔz•|•óèàÕàËÁËà蹫ŸàŸà•àŸàŸà荇ƒ}ƒ}ƒèàsËàhàhà• h{6OJQJ]h{CJ OJ QJ
h{NHh{
h{CJ
h{OJQJh{NHOJQJh{CJOJ QJ ^J h{5>*CJ
OJQJ\ h{OJQJh{CJOJ QJ h{CJ
OJ QJ h{6OJQJ] h{OJQJ h{5OJQJ\h{5>*OJQJ\(’†’®’°’²’““ì•Ž–Ò—Ó—Ô—X˜Z˜>š@šBš¶š¸š¦›ª›ð›ò›ô›}ïïéÞééÕÕÏÕÕÕÕÕÕÕÕÕÏÕÕÕÏÏ7$8$H$ $7$8$H$a$

Ƹp#7$8$H$7$8$H$$
&
F7$8$H$a$gd{|•––Ž––”–W—`—œ—¡—Ò—æ—V˜Z˜`˜j˜è˜ð˜ú™š>špš¶š¸š¦›ª›´›î›ð›ò›¸œ¹œ'(}–—’Ÿ”Ÿ0 1 ^ y z ¡ú¤ ¥¥B§D§T§^§øíøéâéâéâé×ÍÃøíøíøíø×ÍÃéø¸¬¸øé¦é¦éøיøøøיéøיé¦éˆ

h{5\h{NHOJQJh{5CJ
OJQJ\
h{NHh{5>*OJQJ\ h{5OJQJ\h{CJ
OJ QJ h{CJ OJ QJ h{5OJQJ\

h{6]h{ h{6OJQJ] h{OJQJ4}~–—^ _ ` y z ¡k¤ú¤û¤ü¤ ¥¥N§P§T§¨¨¨¨ÔªÖª^¬öööööööööðööêêêêððððàðöööö
„Ä7$8$H$`„Ä7$8$H$7$8$H$ $7$8$H$a$^§

¨ ¨¨¨fª€ª‚ªŠª°ªÄªÔªÖªŽ««f¬Š¬¢­¤­¨­Ê­y®z®{®®¯¯„¯œ¯ ¯¡¯£¯¬¯’°–°Ü°Þ°ô°l²n²³³6³µµµ~·€·º·¶¸÷í÷éáÖÉÖáÖá¿áµáªá áªá“‹ªáªáªá áªáª‹ªáµá¿ªá¿ªá¿ªáh{CJ
OJQJ h{OJQJh{5CJ OJQJ\h{CJ OJQJ h{5OJQJ\h{NHOJQJh{CJOJQJh{6NHOJQJ] h{6OJQJ] h{OJQJh{h{5>*NH\h{5>*\1^¬`¬b¬¢­¤­y®z® ¯¡¯’°”°–°Ü°Þ°³³µµ~·€·¶¸¸¸l¹n¹öööööööööööðãÓãÓãÓãÓööö$
&
F7$8$H$a$gd{
$„h7$8$H$^„ha$7$8$H$ $7$8$H$a$¶¸¸¸ä¸ ¹2¹l¹n¹ »»,»¼r¼z¼~¼\½`½b½¼½¾½€¾–¿¨¿nÀoÀzÀ{ÀÀªÀàÀáÀ@ÂB€‚ÂÅņňÅdÆóëæëæßÛÕÛËø±ëÛ¦˜ˆÛ€u€h˜ˆÛuÛÕÛb˜ˆÛb˜ˆ€
h{CJ$h{5CJ$OJQJ\ h{6OJQJ] h{OJQJh{56CJ
OJQJ\]h{56OJQJ\] h{5OJQJ\

h{5\ h{5OJQJ\ h{OJQJh{CJOJQJ
h{NHh{
h{>*CJ
h{>*h{5>*\h{5CJ OJQJ\&n¹
ºfº,»-»n¼r¼0½\½^½`½b½¼½¾½€¾Ò¿nÀoÀzÀ{ÀëÀ@ÂB€‚ÂïïïééééßééÙÙÙéÐÐÙÙÙéééÙÙ $7$8$H$a$7$8$H$
„Ä7$8$H$`„Ä7$8$H$$
&
F7$8$H$a$gd{‚ÂÅņňÅdÆ>É@ɊÉ`ËlÌРТÐjÑnÑ*Ò,Ò.Ò0ÒdÒfҔՖ՘՚ռվÕDØùùóóóùùóùùùùùùùùùùùùùùùùùóóù7$8$H$7$8$H$dÆÈÈÊÈ@ɊÉ*Ì,ÌÐТжкÐfÑhÑnÑzÑ(Ò*Ò0ÒdÒfÒzҔÒðÔòԚռվÕÖ*ÖJ×L×

Ø
ØyØÆÚÌÚðÚòÚ@ÝBÝHÞIÞXކއÞâüöüèüöüöü×˼Ëüµ­µüè¤ü™üöüè‰ü™üöüöüvè‰üöüöüè‰ü h{5OJQJ\ h{OJQJh{56CJ
OJQJ\] h{6OJQJ]h{6CJ
]h{5>*\

h{5\h{6]ehrÊÿh{ehrÊÿ h{5>*\ehrÊÿh{56OJQJ\]
h{NHh{.DØ<ÙÆÚÈÚÊÚÌÚðÚòÚUÞVÞWÞXކއÞSߤáÜäÞäâäBåDåFåHåüå
æ
ææ‘æ çùùùùùùùóóóóùùóóóóóóóóóóùùùùù7$8$H$7$8$H$â

ââ âRâlâ¤â°â¸äºäâäîä@åBåüå
æ
æ
æ!æ%ækææ‘æçæîæ çç
çPèRè\è\ézé|éšéÒéìéîéòêóêqîwîÁîÂîÃîêîëîWïõñõñõñõñëñäÜäñÔÊÔ¿ÔõÔÊÔõÔ²§Ô²§Ôñš¿Ô¿’ÔˆÔ§Ü俒xñh{56CJ
OJQJ\]h{NHOJQJ h{OJQJh{5CJ
OJQJ\ h{5OJQJ\h{5CJ
OJQJ\ h{5OJQJ\h{CJ OJQJ h{OJQJh{5>*\

h{5\
h{NHh{ h{6OJQJ]/ ççPèRèZé\ézé|éÒé&ê'êþínîoîqîÂîÃîêîëîWïXï„ï ï.ðõõõõêèÞÞõõÕÕÕÕÕÏÍÏÇÇÇÇÇ7$8$H$ 7$8$H$ $7$8$H$a$
„Ä7$8$H$`„Ä

Ƹp#7$8$H$
„Ä7$8$H$^„ÄWïXïŸï ï/ðŠð‹ðÂðññpñqñ ñòòyòzòÎòÏòëòìòVóWó¹óºóùóúó ô™ôœôôžô9õ:õ±õ²õööÔöØöàöäöôèâÜèâèÐƾôèâôè³è³¾¦¢œ¢ôèôè}wkèâè¢èô袳¢h{CJ

OJ QJ ^J
h{CJ

"h{>*B*CJ

OJ QJ ^J phÿÿÿh{>*CJ

OJ QJ ^J
h{NHh{h{5CJ
OJQJ\ h{5OJQJ\ h{OJQJh{CJ
OJQJh{CJOJ QJ ^J
h{CJ
h{CJ h{CJ OJ QJ ^J h{CJ OJ QJ ^J ).ð/ð0ðSðUðtðˆðŠð‹ð«ð­ðÀðÂðÃðÄðññ9ñpñqñŒñ ñòò ò"ò$ò?òMòùùùùùùùùùùùùùùù÷÷ñùùùùùùùùùù7$8$H$ 7$8$H$MòOògòiòwòyòzòÎòÏòëòìò¹óºóÉóËó×óíóùóúó ô›ôôžô¹ô»ôØôùùùùùóèóæóùùùùùùùùùùùùùùù

Ƹp#7$8$H$7$8$H$7$8$H$ØôÚôíôõõ'õ)õ7õ9õ:õSõUõsõuõõ¡õ®õ°õ²õööTöõëëõÝõ×××ÑÑÑÇǹÑÇÑÑÑÑ „ˆ„Ä7$8$H$^„ˆ`„Ä
„Ä7$8$H$`„Ä7$8$H$7$8$H$ „ˆ„Ä7$8$H$^„ˆ`„Ä
„ˆ7$8$H$^„ˆ
„Ä7$8$H$`„ÄTöXööÒöØö4÷6÷8÷:÷ ÷¢÷Þ÷à÷Nøxøäø>ú?ú€úúŸú¸úÔúùùïùùùùùùùùùââââÜÜÒÅÅÅ


&
F7$8$H$gd{
„h7$8$H$^„h7$8$H$


&
F7$8$H$gd{
„Ä7$8$H$`„Ä7$8$H$äö2÷¢÷Þ÷à÷?ú€úúØúÝú2û3û7û9ûsûtû’û“ûŒüŽübýdýrýtýâýäýlþ¶þÖþêþ4ÿ6ÿVÿfÿ¶ÿÌÿ÷ìáÔÐÆÀй÷¯÷С‘‰‰‰‰uÐjЉì^‰uì^‰^‰h{CJOJ QJ ^J h{>*CJOJQJh{CJ OJQJh{NHOJQJ h{OJQJh{56CJ
OJQJ\]h{56OJQJ\]h{5>*NH\

h{5\
h{CJ
h{56\]h{h{5CJ
OJQJ\ h{6OJQJ] h{5OJQJ\h{5>*\$ÔúÕúÖúØú&û7û8û9ûsûtûrýtýâýäýlþ¶þ¸þÖþ4ÿ6ÿVÿ¶ÿvxùùùùïùùææææáæïÔææÔÔæÔÔïù
$„Ä7$8$H$`„Äa$$a$ $7$8$H$a$
„Ä7$8$H$`„Ä7$8$H$8xzöø$2@VŒ¢ÜÞ,F¢¤ºÐ˜šž¬ž

n
p
ü
þ
\

n

Ô

ú


2
6
þ
Š Œ Ž  DF°²7ôðåðÕðÍðÆðÆðÆðÀðÆðÀðÆðÆðºð°ðÀðÀðºð¥ðôðôºðž–žðÍðÀðŒÍh{CJ
OJQJh{5>*\

h{5\ h{6OJQJ]h{56\]
h{CJ

h{NH

h{6] h{OJQJh{56CJ
OJQJ\] h{5OJQJ\h{h{CJOJ QJ ^J 3xzöø$FHJL˜šü
þ

2
4
6
ø
ú
þ
Œ Ž  öðöêöêêêêðêêêêÝêêêê××Ìö

Ƹp#7$8$H$7$8$H$
$„Ä7$8$H$`„Äa$7$8$H$7$8$H$ $7$8$H$a$ °²

i«ÿ6L

r t þ 6ö"$xVùðàààààààÚÏÍÚÀÀÀ²ÚÚð „ð„\7$8$H$^„ð`„\


&
F7$8$H$gd{

Ƹp#7$8$H$7$8$H$$
&
F7$8$H$a$gd{ $7$8$H$a$7$8$H$ 78’” r t „ þ

6F

"xV2 (+036BG÷ø

^`z¤¾êìî-"-g j  ” Æ Ó ô ù

##–#öîöîöîêÜÐîÐîÐîöîÅîêî»î­î­î­îöîꡘ‘ê‘ê‘ê‘êî†î†î†î†î†î h{6OJQJ]

h{5\h{5CJ
\h{6>*OJQJ]h{56OJQJ\]h{CJOJ QJ h{5OJQJ\h{CJOJ QJ ^J h{6>*CJ
OJQJ]h{ h{OJQJh{NHOJQJ4V¬02)

DE^`¤ê -"-Æ- \ ò #ä#æ#''S)T)¼*¾*ùùùððùùðææææùððððððððððððð
„Ä7$8$H$^„Ä $7$8$H$a$7$8$H$–#¬#¶#Ô#Ö#ä#$$$Ò&Ô&''('2')†)±)¶)4*F*Â*Î*À+Â+Ä+<->-?/@/…/0ì1î123N3œ4Ì4 6"6ž6ö6D7d7à7â7,9.9º;Â;<Ò<Ô>öëãÙãëãëãÙãëãëãëãëãëãÎÆ¿»ãÙã»ã®ã¤™ã™ã™ãÙã™ãëã¤ã»ã™ã»ããh{6>*OJQJ] h{5OJQJ\h{CJ
OJQJh{5CJ OJQJ\h{

h{5\h{5>*\ h{5OJQJ\h{NHOJQJ h{OJQJ h{6OJQJ]h{OJ QJ ^J 7¾*Â*\+Â+Ä+J-…/†/ì1î13œ4ž6à7â7Ô8¾:<Ò<ÔööéööööööÙÙÙÙööööÓööÃ$
&
F 7$8$H$a$gd{7$8$H$$
&
F-7$8$H$a$gd{
$„Ä7$8$H$`„Äa$ $7$8$H$a$>>B>r>v>¤>¦>ä>æ>2?L@N@¢A¬A B"B$BbBdBÒDÔDÖDEFšFîFöF8GGÄGÆGnHöîöîäîÚÎîäîÇ¿´î¬žš’š‰î{î{îqd¬Wîh{5CJ
OJQJ\h{5CJ OJQJ\h{CJ OJQJh{56OJQJ\]h{6CJ ]juzh{Uh{h{5>*CJ
OJQJ\ h{OJQJ h{5OJQJ\h{5>*\

h{5\h{6>*OJQJ]h{CJOJQJh{CJ
OJQJ h{OJQJh{OJ QJ ^J -r>¤>¦>ä>æ>2?|? ?ò?@L@N@ @Ú@,AžA¢AîáÑÈȸ¨¨˜˜‹¸¨¨¨È
$„87$8$H$^„8a$$
&
F 7$8$H$a$gd{$
&
F 7$8$H$a$gd{$
&
F 7$8$H$a$gd{ $7$8$H$a$$
&
F 7$8$H$a$gd{
$„h7$8$H$^„ha$$„L„Ä7$8$H$^„L`„Äa$¢A"B$B&BbBdBÒDÖDE E8G:GGÄGÆGvKxK|K´K¶K¸KLLLONOööôôîéççöööööâöööÙÙöââööö $7$8$H$a$$a$$a$7$8$H$ $7$8$H$a$nH†HH’HKKxKzK|K´K¶KLL–N˜NNOPOROTOVO¦O¨OPP®S°S8U:URUXU²U´UüXþX\YrY|YŒY\XFXHX XþXYžYõíãíãí×íÊí´íãíªížíʪíõíãíãí”´íˆíõíõí†íãí‚tíh{5>*CJ
OJQJ\h{Ujì³h{OJQJUh{CJ OJQJjҝh{OJQJUh{CJ OJQJh{5>*CJ
OJQJ\ h{OJQJh{6CJ OJQJ]jS‰h{OJQJUh{NHOJQJ h{OJQJ h{6OJQJ]-NOPOROVO¦O¨ORUTUVUXU²U´UúXüXYYÈY®ZžX XþXYBYlY–YööööíííííèííööíííííâíÒÒÒ$
&
F 7$8$H$a$gd{7$8$H$$a$ $7$8$H$a$ $7$8$H$a$, idQnként pedig az összes üres terület egyetlen területre való összevonására.

Az elhelyezés stratégiák a következQk lehetnek

First Fit (Next Fit) stratégia.
Best Fit stratégia.
Worts Fit stratégia.


A best fit stratégia lényege az, hogy a soron következQ munka abba a szabad memória partícióba kerül, amibe a legkisebb veszteséggel befér. Ezen elgondolás nem ad jó eredményeket. Kikeresni a szabad területek láncolt listáján a legjobban passzoló területet idQigényes, ugyanakkor a memória szegmentálódik, keletkeznek benne kisméretq szabad partíciók, amikbe késQbb nem is lehet semmit tölteni, csakis memória összevonás után használhatók: éppen az ellenkezQjét érjük el, mint amit akartunk, lesz veszteség.

A worst fit stratégia szerint szintén végig kell keresni az összes szabad területet, és abba kell betölteni a munkát, amiben a "legtágasabban" fér el. IdQigényes ugyan a keresés, de kevésbé szegmentálódik a memória, nem lesznek nagyon kicsi üres szegmensek.

Egész jó eredményeket szolgáltat a first fit, és még jobb a next fit stratégia: az elsQ (vagy a következQ) szabad területre töltsük a munkát, amibe belefér. Elmarad az idQigényes keresés és tapasztalatok szerint nem szegmentálódik túlságosan a memória.
Felmerült a ki-besöprés megvalósítása, ezzel alkalmassá vált a rendszer az idQosztásra. Azok a munkák, amik blokkolódtak, kisöprQdhettek másodlagos tárolóterületre. Persze, ekkor azonnal felmerült a kérdés, mekkora legyen a kisöprési terület, minden munka (job) számára külön szervezzék, vagy egy közös, de elég nagy területet biztosítsanak erre. KülönbözQ megoldások voltak erre a különbözQ rendszerekben.




40.) Virtuális címzés koncepció. Lapozás. Laptábla méret kezelés


A virtuális címzés koncepció

A koncepció kialakításának kiváltó oka az volt, hogy egyre nagyobb programokat írtak a programozók, nagyobbakat, mint a rendelkezésre álló fizikai memória. Eleinte a megoldás az átfedés (overlay) technika volt. Átfedésekkel a valós címzésq rendszerekben is lehetett nagy programokat futtatni.

Az overlay lényege
A programokat rendszerint szubrutinokból (eljárásokból, függvényekbQl) állítjuk össze, és valószínq, hogy egy-egy adott idQben nem hívunk meg minden lehetséges rutint. Azaz, elQre összeállíthatjuk a rutinok hívási fáját: ezen ágak az egy idQben egymást hívó rutinok.

Ma, a virtuális címzések kialakulásával nincs szükség az overlay-ezésre. A koncepció szerint minden processznek igen nagy címtartománya van, a processzhez tartozó memória vagy a központi memóriára, vagy valamilyen másodlagos memóriára, tárterületre van leképezve. A processz szükség eseté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 mqködQ rendszerekben a fordító-linker virtuális címeket generál. Az elQá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. Így igaz az, hogy V >>R (V jóval nagyobb, mint R).

A futó processzek szövegében szintén a virtuális címek szerepelnek. 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. Ez a címleképzés dinamikus! Fontos, hogy gyors legyen a leképzés, végrehajtásában a memóriamenedzselQ kernel szoftvert segíti a hardver: az MMU (Memory Management Modul).

Mivel a V >>R még egy processzre is, ráadásul több processzt is kezelhet a rendszer, elQfordulhat, hogy a leképzett R-beli címen éppen nem az adott processz kontextusához tartozó információk vannak. A V-beli címhez tartozó információ ez esetben a másodlagos tárolón van. Gondoskodni kell tehát arról, hogy a másodlagos tárolóról az információ bekerüljön a fQ memóriába. Hogy beférjen, esetleg onnan valamit ki is kell írni. Tehát van adatmozgatás is a dinamikus leképzésen kívül.

Két dolog segíti ezt. Az egyik: a programok lokalítása. Nem szükséges, hogy a teljes címtartományhoz tarozó kontextus egy idQben benn legyen, akkor is tud futni a processz. A másik: bár a lehetséges címtartomány igen nagy, valójában a processzek virtuális címtartománya ennél kisebb szokott lenni.



A lapozó rendszerek (Paging Systems)

A lapozós rendszerekben a virtuális címtartomány "egydimenziós". A V egyforma méretq 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éretq lapkeretekre (page frame) van felosztva.

A valós cím: r =(p',o) formájú, ahol p'a lapkeret címe/.

Minden processz számára biztosítandó egy laptábla. Ennek kezdQ címét a processz dinamikus kontextusában egy regiszter tartalmazza. A laptábla egy-egy bejegyzést tartalmaz egy-egy laphoz: tehát olyan hosszú, hogy a processz minden lapjához lesz egy bejegyzése.

A laptábla egy bejegyzése rögzít: egy jelzést (hogy a laphoz van-e lapkeret rögzítve), védelmi maszkot, módosítás jelzQt, a lapkeret címét.


A laphiba (Page Fault)

A dinamikus címleképzés során a laptábla p-edik bejegyzésében a valid/present-absent bit azt jelzi, hogy a kérdéses laphoz nincs lapkeret hozzárendelve, azaz kivételes esemény, laphiba következik be.

A laphiba lekezelQ rutin a másodlagos tárolóról "belapozza" (paging in) a kérdéses lapot. Ehhez keres egy szabad lapkeretet, és oda lapozza be. Ha nem talál szabad lapkeretet, akkor kiválaszt valamilyen, különben érvényes lapkeretet, az kilapozza és a felszabadult lapkeretbe most már belapozhatja a lapot, egyben érvényessé is teszi. A laphiba kezelQ ezután visszatérhet: a laphibát okozó instrukció most újból végrehajtva már hiba nélkül leképezheti a címet.



Laptábla méret kezelés

A laptábla méretét a processz mérete és a lapméret meghatározza. Természetesen írhatnánk kisebb programokat is, de most nem ez a fontos.

A jól megválasztott lapméret természetesen egy jó lehetQség. Sajnos, néha ebben a hardver korlátoz, néha a hardver nem engedi, hogy a rendszergazda nagyobb lapméretet válasszon, ezzel a laptábla méretét csökkentse.

Egy megoldás lehet a többszintq laptáblák alkalmazása.

Képezzük a 32 bites virtuális cím lapcímrészét két 10 bites mezQbQl, és 12 bites eltolásból. Egy bejegyzésében mutató van a második szintq laptáblák kezdQcímére. A második szintq laptáblákat a p2 cím-mezQ indexeli: a p2 és az elsQ szintq laptábla pointerének összege a második szintq laptábla egy bejegyzésére mutat. A második szintq laptáblák bejegyzéseiben vannak a lapkeret címek: ezek összeadva az eredeti virtuális cím 12 bites offset mezejével a valós címet adják.

Másik megoldás az invertált laptáblák alkalmazása a laptábla-méret csökkentésére.

Az elgondolás az, hogy a címzés bitszélesség növekedésével nem tud versenyt tartani a laptábla csökkentés, hiszen már vannak 64 bites címszélességq, sQt, 128 bites címszélességq rendszerek. A fizikai memória mérete viszont nem növekszik ilyen gyorsan (sajnos), ezért jobb kiindulni a lapkertektQl.

Az invertált laptáblákban lapkeretenként vannak bejegyzések: méretük akkora, hogy minden lapkeretnek legyen egy bejegyzése.




41.) Kilapozási algoritmusok. FIFO, NRU-LRU, LFU-NFU algoritmusok


Kilapozási algoritmusok (Page Replacement Algorithms)

Tulajdonképpen két problémával kellene foglalkozni:
meg lehetne-e mondani elQre, mely lapokra lesz a közeljövQben szükség;
mely lapokat lapozzuk ki, ha a lapkeretek "elfogytak".
Sajnos, az elsQ probléma megoldhatatlan. Voltak ugyan kísérletek, de használható megoldás nem születhetett. Általános célú rendszereknél az optimálás teljesség lehetetlen. A probléma megoldását hagyták az igény szerinti lapozási, majd a munkakészlet koncepció stratégiákra.
Azon viszont érdemes gondolkodni, mik legyenek a kilapozandó lapkertek.
Azok a lapok, melyek nem írhatók, vagy ha írhatók is, nem módosítottak, kezelhetQk külön a kilapozás során. Ezeket valójában nem szükséges kilapozni, mert tartalmuk nem változott, elegendQ Qket "elereszteni".


A FIFO kilapozási 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 elején a régebben belapozott lapokat, a végén a legfrissebben belapozott lapot. Kilapozni mindig a lista elejérQl választ lapot. A mögöttes elgondolás az, hogy a "régi" lapokra már nincs szükség.
Amellett, hogy a listatárolás elég erQforrás-igényes, az elgondolás is téves. Egyáltalán nem biztos az, hogy a régen belapozott lapra nincs a következQkben szükség.


Második esélyes FIFO

Tartsuk a lapokat körkörösen láncolt listán, az egyszerq soros lista helyett, és tartsunk nyilván a lapokra egy hivatkozás bitet, valamint egy "óramutatót", ami a listán körbejárhat.
A hivatkozás bit billen, 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 listán az óramutató éppen mutat. Ha ennek a lapnak a hivatkozás bitje bebillentett állapotú, ne lapozzuk ki, hanem töröljük a hivatkozás bitjét. Ezzel tulajdonképpen adtunk neki egy második esélyt: ha az óramutató a körön körbejárva újra rámutat, és közben nem volt hivatkozás a lapra, akkor ki fog lapozódni. Ha a mutatott lap hivatkozás bitje törölt, akkor viszont ki fog lapozódni. Az óramutató mindenképp továbblép a körön.


Mostanában nem használatos lapok (Not Recently Used pages) NRU (Least Recently Used) LRU

A programok lokalításának elvébQl kiindulva azok a lapok lehetnek kilapozásra esélyesek, melyeket mostanában nem használtak. Valamilyen módon nyilván kell tartani, hogy mikor használták legutóbb a lapot. Azt rögzítjük tehát, hogy mikor hivatkoztak rá, esetleg azt is, mikor módosítottak a lapon legutóbb. Az NRU lapok kilapozódhatnak, az LRU lapok lehetQleg nem: az NRU és LRU algoritmusok igen közeli rokonok, majdhogynem ugyanazok.
Nem egyszerq és nem is olcsó a megvalósítás! Minden lap használatának (és módosításának) idQbélyege tárterület-igényes, a "rendezés", vagyis a régen használt lapok kikeresése nem könnyq!
Az igazi megoldáshoz kétszeresen láncolt listán tartják nyilván a lapokat, a lista elején a legutóbb használtat. A lista végérQl lapoznak ki szükség esetén. A lista közepén szereplQ lapot, ha hivatkoznak rá, mozdítani kell a lista elejére.

KözelítQ és sokkal "olcsóbb" megoldás a következQ: Legyen minden lapra nyilvántartva 2 biten a
R -referenced -hivatkozott jelzés és az 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 elQzQ idQszelet 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 legalacsonyabb nem üres osztályból véletlenszerqen kiválasztva lapozzuk ki a lapokat. Ebben implicite benne van az, hogy a nem módosítottak "lapozódnak ki" inkább. A módszer legnagyobb elQnye, hogy egyszerq, könnyen megvalósítható, nem foglal sok helyet a nyilvántartás.

Ezt a közelítQ megoldást javíthatjuk: a hivatkozásokat nemcsak az utolsó óraintervallumban, hanem egy adott, visszamenQleges idQintervallumban nyilvántartva további "rendezést" vihetünk be.


Mostanában legkevésbé használt (Least Frequently Used) LFU algoritmus (Not Frequently Used) NFU

Az alapgondolat: az utóbbi idQkben gyakrabban használt lapoknak legyen nagyobb esélyük a bennmaradásra. Nem a lapok hivatkozási ideje, sorrendje, hanem a hivatkozási frekvencia a rendezQelv. 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 azt, amire leggyakrabban hivatkoztak, de nagyon idQigényes volna a lista karbantartása!
Más megoldás is szóba jöhet persze, pl.: minden lapra nyilvántartunk egy számlálómezQt, amit 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ómezQ kicsi.

Rögtön jelentkezik két gond
Egyik: elég nagy számlálómezQt kell biztosítani.
A másik a processzek idQszerqségének változásával függ össze: lehetnek lapok, melyeket gyakran használtunk a múltban, mostanában viszont nem használatosak. Amíg a többi lap számlálója "felnövekszik" erre a szintre, addig nem tudnak becsületesen versenyezni! Ha kilapozódnak, belapozódnak, újra kezdik a számlálást. Lehetnek anomáliák ebbQl.

A tiszta LFU, NFU ezért nem is használatos.

A számlálómezQs megoldást lehet azonban alkalmazni, ha ráteszünk még egy "öregedés" (aging) algoritmust. Növekszik a számlálómezQ minden laphivatkozással, az óraintervallumokban azonban célszerq aging konstanssal beszorozva öregbítjük. Így az idQszerqségüket elvesztQ lapok számlálómezeje csökken, esélyt adva a frissebb lapoknak a versenyre.




42.) Igény szerinti lapozás és a Working Set koncepció. A swap eszköz menedzselése


A hivatkozási lánc fogalma (Reference String)

A processzek futásuk közben memóriahivatkozási sorozatot generálnak. Minden memóriahivatkozásnak megfelel egy specifikus virtuális lapcím. A processzek memóriahivatkozásai tehát jellemezhetQk virtuális lapcímek sorozatával: ezt a lapcím sorozatot nevezzük a processz hivatkozási láncának. 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 jellemezhetQk 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 elQre megjósolni
több processz élhet egy idQben.

Az igény szerinti lapozás (Demand Paging)

A lapozás legegyszerqbb és legtisztább formája szerint, amikor egy processz indul, egyetlen egy lapja sincs a memóriában. Amint a CPU be akarja hozni az elsQ instrukciót, bekövetkezik a laphiba, aminek hatására a kernel behozza az elsQ lapot a hivatkozási láncból. További laphibák generálódnak, melyek hatására a hivatkozási lánc egyre több lapja belapozódik. Egy idQ után a processz elegendQ lapja benn van a memóriában, a laphiba gyakorisága csökken. Ezt a stratégiát nevezik igény szerinti lapozásnak (Demand Paging), hiszen egy lap csak akkor kerül be, ha igény merül fel rá, elQre nem lapozunk a stratégia szerint.


A Working Set fogalom

Egy processz azon lapjainak összessége, melyeket egy adott "pillanatban" használ a processz munka-lapkészlete (Working Set). Ha minden lapja a munkakészlethez tartozik, nem következik be rá laphiba. Ha a fizikai memória kicsi, a munkakészlethez kevesebb lap tartozhat, ekkor be fog következni elQbb-utóbb a laphiba. A processzek futásuk közben jellemezhetQk a "pillanatnyi" laphiba-gyakorisággal, a Page Fault rátával. A fent említett igény szerinti lapozásnál kezdetben nagy a laphiba gyakoriság, és remény szerint késQbb ez csökken.
A laphiba gyakoriság nem egy pillanatnyi helyzetet jellemez, hanem egy idQ intervallumot. Esetleg a Working Set úgy is megadható, hogy a processz hivatkozási láncának egy része ez, visszamenve a láncon valameddig.


A Working Set modell (Dennis, 1970)

Tartsuk nyilván és menedzseljük a processzek munkakészletét. Biztosítsuk, hogy ez a memóriában legyen, mielQtt a processzt futni hagyjuk. Ez a koncepció csökkenteni fogja a laphiba gyakoriságot. ElQre való belapozás (Prepaging) is megvalósítható: a lapokat elQre belapozunk, mielQtt a processzt futni engedjük.

Lokális és globális stratégiák

A munkakészlet modell kapcsán felmerül bennünk, hogy ha egy processz egy új lapját kell belapozni, és emiatt kilapozásra is szükség van, akkor a kilapozás ugyanennek a processznek a munkakészletébQl történjen (lokális stratégia), vagy más processzek munkakészlete is figyelembe vevQdjön (globális stratégia).




A lokális stratégia annak az elgondolásnak felel meg, hogy minden processz kap valamennyi (rögzített számú) lapkeretet, amivel gazdálkodhat. Itt, ha a processz lapkeret-készlete nQ, a laphiba gyakorisága csökkenni fog és fordítva. A globális stratégiában a processzeknek nincs rögzített lapkeret számuk, az mindig változik.
Egészítsük ki a lokális stratégiát a következQképpen: a processzek ne rögzített számú lapkeretet kapjanak, hanem azt változtassuk bizonyos határok között. A változtatáshoz használjuk a laphiba gyakoriságot, ami mérhetQ. Ha nagy a laphiba ráta, növeljük a lapkeretek számát, ha alacsony a laphiba, akkor csökkentsük.

A processzek munkakészletei között így beállhat egyensúly, egymás rovására növelik, csökkentik a készleteiket, attól függQen, hogy milyen a laphiba rátájuk. Tulajdonképpen a laphiba rátákat tartjuk határok között.
Ha sok processz él egy idQben, mindegyiknek magas lehet a laphiba rátája, mert a munkakészletek összessége nem növekedhet. Ilyenkor legjobb lenne egyes processzeket teljesen kisöpörni a memóriából, helyet adva a többinek a racionális futásra. A következtetésünk tehát az, hogy a lapozás mellet is jó volna a szegmentálás és ki-besöprési koncepció!


A swap eszköz/fájl struktúra

A mai rendszerekben lehet
swap/paging device; a másodlagos tároló a partíció
swap/paging file; a másodlagos tároló a fájl

MindkettQ lapméretq blokkok sora.

Unix esetén adott a swap partíció és a szabad területek térképe. Foglalás first-fit stratégiával, felszabadítás szomszédos szabad területek összevonásával történik.





43.) Virtuális címzés koncepció: szegmensenkénti leképzés. Szegmentálás és lapozás


A virtuális memória eddigi tárgyalásunkban "egydimenziós" volt: a virtuális címek 0-tól mehettek valameddig, a címtartományban a címek követték egymást.

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 vermeknek;
külön címtartomány, 0 - valameddig, az osztott könyvtári rutinoknak stb.

Szegmenseket képzelünk el, ezeknek külön címtartományaik vannak, mindegyik 0-tól kezdQdik, és persze nem egyforma méretqek. A védelmük is különbözQ lehet. Minden szegmens a címek lineáris sorozata, 0-tól különbözQ méretekig. A szegmensek hossza aká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 valamelyest hasonlít a laponkénti címleképzéshez. A laptábla helyett itt szegmenstábla van, és a leképzés során nem egyforma méretq blokkokban képzünk le, ezért a szegmenstábla soraiban a szegmens hossza is szerepel.
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 szegmens nincs a memóriában, be kell söpörni (swapping in). Ehhez szükség esetén helyet kell csinálni: más szegmensek kisöprQdnek (swapping out). Belátható az is, hogy a szegmentálós rendszereknél kisebb gond a szegmenstábla méret. Valószínqtlen, hogy túl sok szegmensbQl álljon egy processz.

Milyen rendszerek lehetnek?
Vannak tiszta lapozó (pure paging) rendszerek.
Vannak tiszta szegmentáló, ezzel ki-besöprQ rendszerek.
Vannak szegmentáló-ki-besöprQ és ugyanakkor lapozó rendszerek is.

Az utóbbi esetén a ki-besöprés során gyakori, hogy a teljes kontextus ki-besöprQdik, helyet biztosítva a többi processz számára a lapozáshoz.
Általában a felfüggesztett (suspended) processzek esélyesek a kisöprésre, vagy azok, amelyeknek hosszú idQ óta nincs aktivitásuk. Lehetnek ilyenek bizonyos démon processzek, melyekhez hosszú idQ óta nem jött kérelem, de lehetnek terminálhoz kötött processzek is, melyek már hosszú idQ óta blokkoltak terminál inputon (pl.: elment a felhasználó vacsorázni...).

A híres 386/486-stb.-os processzornál 16K független szegmens lehetséges.




45.) Memóriamenedzselés az NT-ben. Virtuális címallokálás, címleképzés. A virtuális címleíró
(VAD), a lapkatalógus, a laptábla, a prototípus laptábla szerepe

Az NT memóriamenedzselése virtuális, TLB-t is használó kétszintq laptáblás lapozós, munkakészletet kezelQ, lokális másodesélyes FIFO kilapozásos algoritmussal rendelkezQ, igény szerinti belapozó.

Memória allokáció

Az NT taszkok (többfonalas processzek) 32 bit szélességen, 4GB lineáris címtartományt látnak. Ennek felsQ 2GB-ja rendszer címtartomány (kernel módban elérhetQ), alsó 2 GB- ja a felhasználói módú címtartomány. A címtartományt 4 KB-os lapokra osztják. A 4 GB címtartományt persze nem használja tejesen: vannak "lefoglalt" címtartomány szakaszok, melyeket a Virtual Address Descriptorok tartanak nyilván. Memória allokáció során éppen új címtartomány szakaszt vesz fel egy-egy taszk: új deszkriptor bejegyzéssel (kezdQ-vég címmel), és csak amikor ténylegesen használnánk is ezt az új címtartományt, akkor inicializálják a laptábla bejegyzéseket (kétszintq memória allokáció).
Különleges memória allokáció a "leképzett fájl" (Mapped File) objektum. Az objektumot 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érQl é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 taszk is készíthet saját nézetet megosztott objektumhoz.

A címleképzés elsQ szintje: TLB

A 32 bites lineáris cím virtuális cím. Leképzése a processzorban megvalósított, ezért processzorfüggQ. A címleképzés a TLB vizsgálatával kezdQdik. A TLB asszociatív áramkört, úgy képzelhetjük el, mint egy kétoszlopos táblázatot: egyik oszlopa maga a virtuális cím, a másik pedig a hozzájuk tarozó laptábla bejegyzések.
A címképzés során a processzor a cím legnagyobb helyiértékq 20 bitjét párhuzamosan összeveti az elsQ oszlop bejegyzéseivel, és találat esetén azonnal kapja a laptábla bejegyzéseket. Ha nincs találata a TLB-ben, akkor indítja a szokásos laptábla keresési eljárást.

A lineáris cím szokásosan 2 szintq laptáblás megoldással képezhetQ valós címre. Az elsQ szintq laptábla neve itt: laptábla katalógus (page directory).
Minden taszknak saját laptábla katalógusa van. Egy-egy bejegyzése egy-egy második szintq laptábla kezdQcímét tartalmazza.
A második szintq laptábla neve egyszerqen: laptábla. Csak annyi laptábla tartozik egy-egy taszkhoz, amennyi szükséges. Egy-egy bejegyzés tárolja a lap státusz-védelmi bitjeit és lapkeretet,

Az osztott memóriakezelés problémaköréhez tartozik: a nem halogatott memória megosztás. Ezt az NT a prototípus laptábla segítségével kezeli.
A prototípus tábla egy további szint a laptábla rendszerben. Több taszk által használt lapoknál a laptáblák nem közvetlenül mutatnak a lapkeretre, hanem a prototípus laptáblán keresztül: ilyenkor ez a tábla tárolja a védelmi biteket, a státuszt.




46.) Memóriamenedzselés az NT-ben. A fizikai memória nyilvántartása, keretállapotok és listák,
a módosított lapíró. A munkakészlet

A lapkeret adatbázis

A fizikai memória nyilvántartására a ki- és belapozás segítésére az NT memóriamenedzsere az invertált laptábla koncepció szerinti laptáblát, lapkeret adatbázist (Page Frame Database) is fenntart.
Ha egy taszk terminálódik, az általa használt keretek szabaddá válnak és ez fel is jegyzQdik a lapkeret adatbázisban.
A lapkeret adatbázis is egy táblázat: lapkeretenkénti bejegyzésekkel. Mérete tehát a fizikai memóriától függ. Egy-egy bejegyzése információkat tárol a keretek állapotáról, valamint "visszamutatót" laptábla bejegyzésre. Az állapotinformációk:

Érvényes (valid) keret: használatban lévQ keret, van benne leképzett lap;
Szabad (free) keret: egy taszk sem használja, kiosztható
Nullázott (zeroed) keret: szabad keret, kitöltve 0-kkal.
Készenléti (standby) keret: tulajdonképpen felszabadított keret, de még megtalálhatók rajta a lapot-lapkeretet korábban használó taszk adatai. Az ilyen kereteket még "visszakérhetik" viszonylag olcsón: ha úgy tetszik második esélyt adva a keretnek-lapnak.
Módosított (modified) keret: a készenlétihez hasonlóan már felszabadított keret, de újrafelhasználása elQtt azt a lemezre kell írni.
Hibás (bad) keret: megbízhatatlanul mqködQ keretekre a memóriamenedzser ráírhatja ezt a bejegyzést.

A lapkeret adatbázisban a keretek státuszának feljegyzése mellett 5 láncolt listán is vannak nyilvántartások.

Az NT memóriamenedzsere folyamatosan figyeli a szabad, a nullázott és a készenléti listán található elemek számát, és ha ez bizonyos érték alá csökken, a másodlagos tárolóra írja a módosított kereteket és a készenléti listára átteszi azokat. A módosított keretek mentését a módosított lapíró (Modified Page Writer) rendszertaszk végzi. Ha még így is kevés a szabad-, nullázott-, készenléti keretszám, további tevékenységek is történnek. Miután a fizikai memória nyilvántartásának kulcsa a lapkeret adatbázis, többprocesszoros rendszereknél külön gondoskodni kell ennek védelmérQl. Forgózár (spinlock) védi az adatbázist a kritikus szakaszokra, sorbaállás következhet be, ezért a memóriamenedzser ezzel kapcsolatos kritikus szakaszait nagyon hatékonyra kellett írni.

A laphibák kezelése, kilapozás, munkakészlet kezelés

A laphiba kezelQ egy-egy taszk számára végzi munkáját, nem nagy hiba tehát, ha a szóhasználatunkban nem a kezelQt, hanem a taszkot fogjuk rendre említeni.
Az NT memóriamenedzser minden taszk számára munkakészletet (working set) biztosít, minden taszk bizonyos számú lapkeretet kap. A készletnek van maximális és minimális értéke. A rendszerállapottól függQen a készlet csökkenthet, növekedhet.
Egy-egy taszk lokális FIFO kilapozási algoritmussal "gazdálkodik" a munkakészletével: szüksége esetén a legrégebben betöltött lapját "szabadítja" fel.
A virtuális memóriakezelQ tehát, ha úgy érzi, aktiválja a módosított lapíró processzt, ami a módosított státuszú kereteket kilapozza, utána azokat átteszi a készenléti listára. Ha ez sem segít, átnézi, van-e olyan taszk, melynek munkakészlete nagyobb, mint a taszkhoz tartozó minimális érték. Ha vannak ilyenek, ezeknek a munkakészletét csökkenti. Ha ezután sincs elegendQ memória, valamennyi taszkra elvégzi a kurtítást: kényszeríti a taszkokat a "felszabadításra". Ha a memóriakrízis megszqnik, az egyes taszkok laphiba gyakoriságát figyelve kezdi növelni azok munkakészlet méretét. Taszkok terminálódása esetén azok munkakészleteit megszünteti, a kereteiket szabad listára teszi. Taszkok születése esetén biztosít számukra munkakészletet.



47.) I/O egy felhasználó és egy programozó szemszögébQl


Az operációs rendszer I/O alrendszerének egyik feladata, hogy a felhasználók elQl elrejtse a hardver eszközök különbségeit, kényelmesen lehessen az eszközöket forrásként vagy nyelQként használni, az eszközökre, eszközökrQl adatokat továbbítani. Másik feladata az eszközök menedzselése, a processzek számára erQforrásként biztosítani az eszközöket, azok szolgáltatásait, esetleg ütemeznie kell az eszközökhöz való hozzáférést, védeni kell az eszközöket, konkurens vagy kizárólagos hozzáféréseket megkülönböztetve, védelmi tartományokat nyilvántartva.

A felhasználó látásmódja

A felhasználó az eszközöket és a fájlokat szimbolikus neveiken ismeri. A felhasználói kapcsolattartó rendszerben ezeket a szimbolikus neveket használja. Korszerq operációs rendszerekben hierarchikus fájlrendszert lát. Ehhez ismeri a jegyzék (katalógus, directory), az ösvény (path), a gyökér jegyzék (root directory), munkajegyzék (working directory) fogalmat stb.
A fájlrendszer "látásához" három dolgot 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, amin a fájlrendszer elhelyezkedik.

A felhasználó számára a fájl a legkisebb egység a másodlagos tárolón, amit kezelni szokott. A kapcsolattartó felület segítségével képes kezelni az eszközöket, fájlokat: másolhat (copy), mozgathat (move), törölhet (delete, remove), elQállíthatja azokat valamilyen segédprogrammal, fejlesztQvel stb. A kapcsolattartó parancsai magas szintq "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ájlvédelmi koncepciókat, a tulajdonossági- és védelmi kategóriákat, ezeket használja, beállítja stb.
Lát egyé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 is: azaz nemcsak a fájlneveket, a nevekhez kapcsolódó attribútumokat, a névhez tartozó adatokat, hanem a fájl struktúráját is.


A programozó látásmódja

A folyamat (process) szemszögébQl minden I/O eszköz vagy fájl egy csatorna (stream). A csatornát a folyamat megnyitja, ezzel belsQ 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 is ismert eszköznévre, fájlnévre. A csatorna "megszüntethetQ" a lezárásával: az explicit close, fclose stb. rendszerhívásokkal. A legtöbb operációs rendszerben a nyitott csatornák lezáródnak a folyamat terminálódásával.
A folyamatok számára a nyitott csatornák byte-, vagy rekord-források, -nyelQk. A csatornákba, a csatornákból byte-ok, rekordok mozgathatók, szekvenciálisan, vagy közvetlen eléréssel. A mozgatott adatmennyiség függ a csatornához tartozó (a leképzett) fájl, vagy eszköz szervezettségétQl, az elérés módját is befolyásolhatja a szervezettség. A leggyakoribb adatátvivQ rendszerhívások a read é s a write
rendszerhívások. A legtöbb operációs rendszer a csatornákhoz biztosít egy fájl pozíció indikátor mechanizmust is, ami a nyitott csatornán az adategység pozícióját jelzi. Ennek "mozgatása"(seek) a soros
szervezésq fájlokon is lehetQvé teszi a direkt elérést.
A Unix operációs rendszerek fájlszervezése hallatlanul egyszerq: itt a fájlok bájtok sorozataként megvalósítottak. Nincs különösebb szervezettség, az elérés soros, illetve a pozíció indikátor mozgatása segítségével direkt lehet.



48.) A Unix, az NT és a Linux I/O alrendszerei: funkcionális egységek


Az OS-ek egyik legfontosabb feladata az összes I/O eszköz

vezérlése,
könnyen kezelhetQ interfész biztosítása ezekhez,
védelem, menedzsment biztosítása ezekhez.

Az operációs rendszer "látásmódja" ezért meglehetQsen bonyolult.


Eszközök, másodlagos tárolók, fájlrendszer




I/O rétegezettség





A UNIX kernel I/O struktúrája


A character device drivers feletti line diciplines+cooked tty komponensek a karakteres eszközökre (tipikusan terminálokra, soros vonalakra) strukturált elérést biztosítanak.

A line disciplines rutinkészlet sorokba rendezi az inputot, feldolgozza a DEL és KILL karaktereket, echózik, a TAB-ot kiterjeszti helyközökké, jelzéseket generál, ún. "raw" módban szqri a karaktereket.

A cooked tty nyitó/záró, író/olvasó és kontrolláló (ioctl) rutinokból áll, ezek hívhatók a felhasználói programokból.

A raw tty interface rutinkészlet szintén a karakter orientált eszközöket kezeli, csak éppen nem szqrik az inputot, minden bájtot, karaktert eljuttatnak a felhasználói programhoz.

Tovább az ábrán láthatjuk a "raw disk interface" részt, a character device driver felett. Ámbár a diszk tipikusan blokk orientált eszköz, mégis lehetséges hozzá karakter driveren át hozzáférés.

A block buffer cache mechanizmus egy gyorsítótár a diszkek és a memória között. Látjuk azt is, hogy a blokkorientált eszközökre képezhetünk fájlrendszert (fájlrendszereket), és azon át is elérhetjük a diszk
blokkjait, emellett elérhetjük a blokkokat kimondottan a blokkcímeik szerint (cooked disk interface komponensen át).




49.) Eszközök osztályai. Eszköz-driverek, felépítésük, feladataik


Az eszközök a buszra csatlakozó

vezérlQbQl, és az ezekhez csatlakozó
fizikai eszközökbQl állnak.

Ezekkel a device driver-eknek és bennük az interrupt handler-eknek van közvetlen kapcsolatuk.


Az eszközöket csoportosítása, osztályozása

Karakterorientált, vagy más néven strukturálatlan eszközök. Ilyenek a terminálok, soros vonalak, nyomtató portok, analog/digital átalakítók stb. Strukturálatlannak mondjuk ezeket, ami tulajdonképpen azt jelenti, hogy ezek az eszközök képesek fogadni/adni egy strukturálatlan karakter/bájt sorozatot.

Blokkorientált, vagy strukturált eszközök képezik. Tipikus példájuk a diszk eszközök. Mit jelent itt a blokkorientáltság? Az ilyen eszközöknél blokknyi egységekben történik az adattovábbítás, blokk egységben történik az adatrögzítés. Egy-egy blokk feldolgozása "random" jellegq is lehet. Minden blokknak van címe. Ez adja a blokk-struktúrát, ezért mondjuk ezeket strukturált eszközöknek.


Az eszközmeghajtók (Device drivers)

Az I/O alrendszer legalsó részét, az eszköz drivereket egy rutinkészlet, táblázatok és pufferek alkotják. Mivel a kernel részei: a rendszer címtartományához tartoznak.

Legfontosabb feladatuk az adatmozgatás a központi memória és a vezérlQ buffere között, továbbá parancskiadás a kontroller számára, hogy az mqködjön. További fontos feladatuk olyan események kezelése, melyeket egy-egy kontroller kelt, amivel jelzi, hogy kész van a kapott feladatával. Az eszköz driver-ek rutingyqjteményt képeznek, jól meghatározott struktúrával.

AlapvetQen három részbQl állnak

Autókonfigurációs és inicializáló rutinokból, melyek egyszer hívódnak, a driver
betöltésekor, indulásakor. FelülrQl, call jelleggel hívódnak
Második rutincsoportot az I/O kérelmeket kiszolgáló rutinok alkotják. FelülrQl, call jelleggel hívódnak 3. A harmadik csoportot a megszakítás kiszolgáló rutinok alkotják, Ezek "alulról" hívódnak, aszinkron módon.(Ezek az alsó réteghez tartoznak).

Az OS I/O alrendszere tehát feltétlenül tartalmaz device-driver komponenseket, minden konkrét eszközfajtához saját drivert. A rendszergazdáknak kell gondoskodnia arról, hogy minden konkrét eszköznek meglegyen a drivere, mindegyik inicializálódjon a normál használat elQtt.




50.) Blokkorientált eszközök, logikai diszk, partíció, kötet


A felhasználói processz a cooked disk interface-en keresztül közvetlenül is kérhet adott címq diszk blokkot. A diszk driver-hez a kérelem felülrQl mindenképp úgy jön, hogy adott diszk adott blokkjára van igény.


A logikai diszk (Logical Disk) fogalma

Sokféle diszk van, különbözQ olvasófej számmal, sáv (track) számmal, szektor számmal, különbözQ méretekben, különbözQ gyártók, interfészek vannak stb. Bonyolulttá válik a driver írók feladat, ha minden változathoz illeszteniük kell a driver-eket.
Egyszerqbbek lesznek a driver-ek, ha a logikai diszk modellt használhatják. A vezérlQk a driver szoftverrel együtt biztosíthatnak egy konzisztens modellt, a logical disk modellt.
E szerint a logical disk: blokkok sora 0 -tól n -ig sorszámozva. A logikai blokkcímet a vezérlQ "fordítja le" fej-cilinder-szektor címhármasra, a driver szemszögébQl nézve a diszk blokkok sorának látható.
Szinte minden fizikai diszk konvertálható egy ilyen ideális modellre. A gondolat tovább folytatható. Egy fizikai diszk logikailag egymás utáni blokkjai összefoghatók, a diszk partíciók alakíthatók ki rajtuk.


A diszk partíciók

Egy fizikai diszk konvertálható partíciókra. Egy partíció a diszk valahányadik blokkjától kezdQdQen valahány egymás utáni blokk. Tudnunk kell, hol kezdQdik a partíció, és hogy milyen hosszú. A partíció elsQ blokkja a 0 logikai címet kaphatja, a következQ a 1-es címet és így tovább. Ezután a partíció egy blokkjára a relatív logikai címével hivatkozhatunk. A partíció nem más, mint egy logikai diszk, ami 0 - n -ig sorszámozott blokkokból áll.
Egy partíció egy logikai diszk-eszköz, kell legyen szimbolikus neve, kell, hogy tartozzon hozzá eszköz driver, ami kezelni tudja.

file system-et szervezhetünk,
kijelölhetjük kilapozási/kisöprési (swap) területnek
kijelölhetjük boot loader-nek, innen töltQdhet a rendszer,
kijelölhetjük alternate block area -nak (hibás blokk helyett innen allokálhatunk blokkot)

Ahogy említettük, minden partíciónak kell legyen szimbolikus neve és kell hozzá tartozzon eszköz driver, ami kezelni tudja. Egyes operációs rendszerekben az eszköz szimbolikus neveket megszokhattuk, lehetnek azok az ABC betqi. A szimbolikus nevek további diszkeket - akár logikai diszkeket, partíciókat -jelölhetnek.

Több kisebb partíciót összevonva beszélhetünk kötetrQl. Ez is egy logikai diszk, melyre fájlrendszer szervezhetQ.




51.) Unix eszközök szimbolikus nevei: a speciális fájlok, szerepük


A Unixban az eszközök szimbolikus neveit az ún. speciális fájlok hordozzák! A speciális fájlok szokásosan a /dev jegyzékben (vagy ebbQl kiinduló aljegyzékekben) vannak bejegyezve. E jegyzékben a speciális fájl ok 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ökrQl van szó.

Egy-egy speciális fájlra való hivatkozáskor valójában a hozzá tartozó eszközre hivatkozunk. Maga a speciális fájl nem hosszú, csak 2 számot tartalmaz:

a major device number -t, ami az eszközt vezérlQ kontrollert (adaptert),
és a minor device number -t, ami a kontroller által vezérelt eszközt (akár partíciót) azonosítja.

A két azonosító szám együtt nemcsak az eszközt azonosítja, hanem az eszköz kezeléséhez szükséges eszköz driver kernel komponenst is!


A partíciókra osztáshoz alacsony szintq szoftverek kellenek, amelyeket a gyártóktól kell beszerezni! A diszkformattálás után lehet particionálni. A partíciókra osztáskor megmondjuk, hol kezdQdnek és milyen hosszúak a partíciók. A particionálási információk az ún. partition table-ben vannak, ez pedig a fizikai diszk 0 sorszámú blokkján található. Egy particionált diszk újra particionálható, de a partíció határok
megváltoztatása tönkretehet fájlrendszereket!


Egyes operációs rendszerek (pl.: Unix) megengedik a partíciók átlapolódását.


Ökölszabályok a partíció méretek kiválasztására

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
Kezdetben a /dev/dsk/0s3-at és /dev/dsk/0s/0s4-et nem is használjuk. Innen akár át is particionálhatunk.


Tehát partíció név-konvenciók vannak a Unix-okban!

A Unixban minden fájl és egy fájl-rendszerbe rendezett. Vannak:

közönséges fájlok,
jegyzékek
speciális fájlok (eszközöket takarnak),
fifo-k (pipe-ok) stb.

Egy rendszerhívás, aminek argumentuma speciális fájlhoz kötQdQ leíró, a megfelelQ eszközt kezeli.

Blokk orientált eszközre fájl-rendszer szervezhetQ.




52.) A buffer cache (Unix esetén). Adatstruktúrák a buffer cache implementációban (bufferek
listái)


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 elhelyezkedQ buffer cache -t.
Minimalizálni akarják a tényleges diszk hozzáféréseket, ezért a Unix kernelben megvalósítottak egy belsQ pufferezést: ez a buffer cache. Ennek szerepe a diszk és a felhasználói memória közötti adatmozgatás-gyorsítása! Más operációs rendszerekben is szokásos ez a fajta gyorsító tár alkalmazás a cache-elés.

A buffer cache-ben vannak bufferek, ezek adatrészében diszk blokkok találhatók. A kernel a diszkes I/O esetén elQször a cache-ben keresi a blokkokat. Ha ott megtalálja a keresett blokkot, nem is fordul a diszkhez, onnan szolgáltatja a blokk tartalmát, oda írja az output-ot. Miután van esély arra, hogy egy diszk blokk megtalálható a buffer cache-ben is (lokalítás elv!), teljesítménynövelés lehet az eredmény.
A kernel a rendszer inicializálásakor allokál helyet a buffer cache-nek, a memória méretétQl és teljesítmény korlátoktól függQ nagyságút. Úgy mondhatjuk, a buffer pool-ban van x számú buffer.


Valamely buffer két részbQl áll

a buffer fejbQl (buffer header),
és a buffer adattároló részébQl. Ez éppen akkora, mint egy diszk blokk


Valójában a buffer adattároló részében a tartalom egy az egy leképzése egy diszk blokknak. Valamely diszk blokk csakis egy bufferbe lehet leképezve! A leképzés persze idQleges, valamely buffer egyszer ezt, másszor azt a diszk blokkot tartalmazza.



a buffer fej szerkezete


Az eszköz logikai szám és a blokkszám mezQk azonosítják, melyik blokk van leképezve a bufferbe.
A státus mezQ a buffer állapotát jelzi. EbbQl a szabad-nem szabad állapot lehet érdekes: a szabad buffer természetesen tartalmazhat érvényes (valid) adatokat, de ha kell ez a buffer, a kernel elveheti, és valamilyen célra felhasználhatja.


A nem szabad jelzésq buffert viszont a kernel más célra nem használhatja. A buffer fej többi mezQje mutatókat (pointer) tartalmaz. ÉrthetQ az adatterületre mutató pointer szerepe: ez a kapcsolat a fej és a tényleges adatterület között.
A buffer pool-ban lévQ bufferek fel vannak, fel lehetnek fqzve két kétszeresen kapcsolt körkörös listára.

Ez a két lista

a bufferek szabad listája;
a hash listák.

A buffer fejben két mutató-pár mutatja a listákon a következQ és az elQzQ buffert.
a hash listák. A boot-oláskor minden buffer ezen a listán van. A buffer mindig fejbQl és a hozzá tartozó
adatterületbQl áll.





53.) A buffer cache (Unix esetén). A buffer allokálás (getblk) algoritmus. Az 5 tipikus forgat-
könyv


Ha a rendszernek egy szabad bufferre van szüksége, két eset lehetséges

akármelyik szabad buffer megfelel: ekkor a szabad lista elejérQl veszi az elsQ buffert, és persze leveszi a szabad listáról
azonosított szabad bufferre van szüksége: ekkor leveszi azt a lista közepérQl

Ha egy buffer felszabadul, akkor általában a szabad lista végére illeszti a buffert. Néha az elejére, de soha sem a közepére. Ez tulajdonképpen egy legkevésbé az utoljára használt 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, elQször megnézi, hogy benn van-e a buffer mezQben (buffer pool). A keresés alapja az eszköz logikai szám és a blokkszám kombinációja. Hogy a keresés gyors legyen, hogy ne kelljen a teljes buffer mezQt végignézni, a diszk blokkokat tartalmazó buffereket úgynevezett hash listákon tartja.
A sorokban a bufferek száma dinamikusan változik. A hash függvény azért egyszerq, hogy gyorsan kiszámítható legyen. Azt, hogy hány sor legyen, a rendszeradminisztrátor beállíthatja.


Buffer allokálása a buffer mezQbQl

Képzeljük el, hogy olvasni akarunk a diszkrQl egy blokkot. Ekkor adott a diszk logikai száma és a blokkszám. Ekkor a kernel megnézi, hogy az blkno-nak megfelelQ buffer a buffer pool-ban van-e: végignézi a megfelelQ hash listát. Ha ott megtalálja, megnézi még azt is, "valid"-e, és gyorsan visszatér a buffer címével. Ha nincs a blokk a buffer a pool-ban, allokálni kell neki egy szabad buffert, és ebbe be kell olvasni 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 idQvel ez majd ki is kerül a diszkre. Fontos algoritmus tehát az ún. buffer allokáló algoritmus (getblk).

Az algoritmus 5 tipikus forgatókönyve

A kernel megtalálja a blokkot a hash listán és ennek buffere szabad.
Nem találja a blokkot a hash listáján, így allokál egy buffert a szabad listáról.
Nem találja a blokkot a hash listáján és megkísérel allokálni neki egy buffert.
Nem találja a blokkot a hash listáján, ugyanakkor a szabad lista üres. Blokkolódik (sleep), amíg egy buffer szabaddá nem válik.
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.





54.) A buffer cache (Unix esetén). A bread és a breada algoritmusok, a brelse algoritmus



A diszkrQl való olvasás algoritmusa a bread algoritmus. A bread algoritmusban látható, hogy ha a kért blokk benn van a buffer cache-ben, a buffer azonosítójával azonnal visszatér az algoritmus. Ha viszont nincs a buffer cache-ben, kezdeményezQdik a diszk-olvasás.

Sokszor elQfordul, hogy egymásután több blokkot akarunk beolvasni. A teljesítmény növelheti a breada algoritmus (read-ehead).
Ebben az elsQ blokk-olvasás -ha nincs a bufferban - szinkron, a második blokk-olvasás aszinkron.

A brelse algoritmust kezdeményezheti magas szintq algoritmus (breada, bwrite). Nem csak direkt hívása lehet, hanem aszinkron I/O-handler is hívhatja. E kettQség miatt van IT-letiltás. A brelse algoritmus ereszti el a buffert.

Az egymásba ágyazott brelse-ket kerülni kell.




55.) FAT és VFAT fájlrendszer elérése DOS, DOS+Windows, W95 és NT alkalmazásokból


A partíció meghatározott (konvencionális helyén található) területe a bit/mezQ térkép. Bit/mezQ bejegyzések vannak a térképen, éppen annyi, ahány blokk található a partíción. Egy az egy megfeleltetés van a bitek/mezQk és a diszk blokkjai között: az i-edik blokkhoz az i-edik bit/mezQ tartozik. A szabadság vagy foglaltság jelzésére a megfelelQ bit 0 vagy 1 értékq, a megfelelQ mezQ 0, vagy a foglaltságot jelzQ egész bejegyzésq. A bit-térkép, gyorsítási célokból in-core memória másolattal kezelhetQ. Nagy diszkeken egy-egy bithez/mezQhöz cluster rendelhetQ. Gyakorlatilag ezt a módszert használja a VAX/VMS, a HPFS, az NTFS és az MS-DOS FAT fájlrendszere is.

Az MS-DOS FAT fájlrendszere

12 vagy 16 bites bejegyzések (korlátozott kötetméret)
FAT tábla a kötet elején, az indextábla és a mezQtérkép összevontja
a jegyzék-szerkezet lineáris-lista formájú (( lassú)
8.3 FAT fájlnevek (rövid)


VFAT (WIN95, OS/2, Linux, NT, stb.)

Hosszú fájlnevek használatát engedélyezi
Nagyobb kötetméret (de még kötött)


FAT/VFAT

Kötött attribútum-készletq
Az NT fájlrendszerei






Az NT által használt fájlrendszerek

FAT
VFAT
HPFS
nagy partíciók, fájlok
nem egy helyen vannak a driver információk
a directory B-fa forma
hibatqrQ
8 MB-os sávok
NTFS
még nagyobb partíciók
még hibatqrQbb
16 MB-os sávok

HPFS/NTFS: bittérképes szabad blokk-menedzselés.


DOS+WINDOWS alatt az ún. 32 bites elérés, az NT alatt egy alternatív 32 bites elérés a jellemzQ.

Linux-nál az implementált fájlrendszerekhez a VFS(Virtual File System)-en keresztül juthatunk el.



56.) Fájlrendszer-implementálás alapvetQ feladatai



Blokk-strukturált eszközökre (logikai diszkekre - partíciókra) szervezhetünk fájlrendszer-t.

Tulajdonképpen három dolgot kell megoldani

hogyan rögzítsük, hogy egy adott fájlhoz mely blokkok és milyen sorrendben tartoznak,
hogyan tartsuk nyilván a logikai diszken a szabad blokkokat, hogyan keressünk ezekbQl, ha foglalni akarunk, vagyis hogyan menedzseljük a blokkokat a partíción,
végül, hogyan rögzítsük a fájl-attribútumokat, fQképpen milyen legyen a jegyzék szerkezet.







57.) Fájlok és attribútumaik


A fájl: valamilyen szempontból összetartozó adatok névvel ellátva. Vannak névkonvenciók.


Fájl struktúrák, fájl-organizáció

Három általános struktúra lehetséges:
A fájl bájtok sora. Tulajdonképpen nincs strukturáltság, illetve a processzek strukturálhatnak, ha akarnak.
A fájl rekordok sora. A rekordok lehetnek állandó, vagy változó hosszúságúak, ezen belül ún. blokkoltak. A rekord-strukturáltság a diszken, partíción, szalagon rögzített, nem a processzek strukturálnak, hanem az OS I/O alrendszere.
Indexelt szervezésq rekordokból áll a fájl. A rekordok nem feltétlenül egyforma hosszúságúak, van bennük egy vagy több kulcsmezQ -rögzített pozíción -, amik segítségével gyors kikeresésük lehetséges.

Unix-ban az elsQ, MS-DOS-ban az elsQ és a második, VAX/VMS alatt mindhárom organizáció lehetséges.


A fájl elérések

Általánosan kétféle lehet
szekvenciális vagyis soros elérés, ami mindhárom organizációnál lehetséges. Ez tulajdonképpen azt jelenti, hogy ha egy bájtot, vagy rekordot el akarunk érni, az elQtte álló bájtokat, rekordokat végig kell olvasni, vagy legalább is át kell lépni.
Random, vagyis véletlenszerq elérés, ami azt jelenti, hogy egy byte vagy rekord elérése független a többi bájttól, rekordtól. A Unix ezt a seek rendszerhívással biztosítja. Más operációs rendszerek a fix hosszúságú szekvenciálisan szervezett rekordokhoz, ill. az indexelt szervezésq rekordokhoz a közvetlen -random- elérést biztosítják.


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 operációs rendszerekben FIFO jellegq fájlok, mailbox-ok,
a Unix-ban ún. speciális fájlok, amik tulajdonképpen eszközöket azonosítanak.
könyvtárak (libraries), melyek tagokat (members) tartalmaznak, amik maguk lehetnek szövegek, tárgy-modulok, végrehajtható programok stb.


Fájl attribútumok

A fájloknak nemcsak nevük és adataik vannak, hanem további kapcsolódó információik: pl.: készítési dátumuk, utolsó módosítási vagy elérési dátumuk, tulajdonosuk, csoporttulajdonosuk, védelmi maszkjuk, írás/olvasási engedélyük stb. is jellemzik Qket. Ezeket nevezhetjük az attribútumaiknak.



58.) Jegyzékimplementálási technikák. Szabad blokkmenedzselési technikák



Jegyzék implementációk

A jegyzék maga is egy fájl, ami bejegyzéseket tartalmaz 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 lehetnek állandó, vagy változó hosszúságúak, az implementációtól függQen. A bejegyzésekben az attribútumok között a legfontosabb a fájlnév. Sokszor van keresé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 bejegyzéseken, ahol is gyorsabb keresési módszerek is megvalósíthatók;
hash táblás: a szokásos szekvenciális bejegyzések mellett egy hash táblát is implementálnak, ami a gyorsabb keresést segíti.



A szabad diszkterület menedzselési lehetQségei

A fájlrendszer implementációkat tervezQk másik gondja, hogyan menedzseljék a szabad diszkterületet, hogyan tartsák nyilván a szabad és a foglalt blokkokat, hogyan igényelhet rendszerhívás blokkokat, fájltörlésnél hogyan adható vissza blokk a szabad blokkok mezejébe.

AlapvetQen két megoldás szokásos!

Bit vagy mezQ térkép a szabad, illetve foglalt blokkokról

A partíció meghatározott (konvencionális helyén található) területe a bit/mezQ térkép. Bit/mezQ bejegyzések vannak a térképen, éppen annyi, ahány blokk található a partíción. Egy az egy megfeleltetés van a bitek/mezQk és a diszk blokkjai között: az i-edik blokkhoz az i-edik bit/mezQ tartozik. A szabadság vagy foglaltság jelzésére a megfelelQ bit 0 vagy 1 értékq, a megfelelQ mezQ 0, vagy a foglaltságot jelzQ egész bejegyzésq. A bit-térkép -gyorsítási célokból- in-core memória másolattal kezelhetQ. Nagy diszkeken egy-egy bithez/mezQhöz cluster rendelhetQ. Gyakorlatilag ezt a módszert használja a VAX/VMS, a HPFS, az NTFS és az MS-DOS FAT fájlrendszere is.

Láncolt lista a szabad blokkokról

Fix helyen lévQ blokk tartalmaz bejegyzéseket szabad blokkokról, annyiról, amennyit képes egy blokk nyilvántartani, továbbá ugyanez a blokk egy következQ blokk pointerét is tartalmazza, ami további szabadblokkokat tart nyilván és így tovább.
Gyakorlatilag ezt a módszert használja a Unix, azzal a kiegészítéssel, hogy maguk a szabad blokkok használatosak a láncolt lista tárolására.




59.) Fájlokhoz való blokk-hozzárendelési technikák



Folyamatos allokáció

Egyszerq séma, egymás utáni blokkokat foglalunk a fájl számára, annyit, amennyit az el fog foglalni. A fájl tartalom keresése során csak a kezdQ blokk címét kell megadni pl.: a fájl nevét tartalmazó jegyzékben. Nyilvántartják ilyenkor a hosszat, vagyis az utolsó blokk címét is.
Gond: fájl allokáció során elegendQ összefüggQ területet kell találni, fregmentálódik a diszk (compaction kell, a gap-ek nem használhatók ki), nehézkes a hozzáfqzés (append). Korszerq operációs rendszerekben nem használják már.


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 elsQ blokk mutatója, esetleg a fájl hossza bejegyzendQ, az elsQ blokkban megtalálható a következQ blokk címe (mutatója) és így tovább, az utolsó blokkban a mutató NULL pointerként jelzi, hogy nincs tovább.
Gond: soros olvasás még elfogadható, de random keresés nagyon lassú lehet, mert 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 kettQ hatványai méretq adat blokkokat.
Nem szokásos ez a módszer.


Láncolt lista allokáció index-táblával

Emeljük ki a blokk-mutatókat egy indextábla mezQibe. Az indextábla a partí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 egy megfeleltetés van a táblamezQk (pointermezQk) és a blokkok között: az i-edik táblabejegyzés az i-edik blokkhoz tartozik. Ha egy fájl kezdQdik az i. blokkon, folytatódik a j.,k.stb. blokkokon, akkor: a jegyzékben a neve mellett szerepeljen i, az i. pointermezQben szerepeljen j, a j. pointermezQben a k, stb.
Az indextábla egy bejegyzése (pl.: az i. mezQbe írt j érték) kettQs információt hordoz:

maga az index (i) azt mondja, hogy az i-edik blokk a fájl blokkja.
a mezQ tartalom (a k) pedig azt mondja, hogy a soron következQ blokk a k-adik blokk.

Jó, ha az indextábla egészérQl, vagy legalább részletérQl in-core másolat van a memóriában (gyorsítás).
Tulajdonképpen az MS-DOS és végsQ soron a VAX/VMS is ezt a módszert használja.
Gond: nagy blokkszámú diszkek igen nagy indextáblát igényelnek. Javítható ez, ha néhány blokkot csoportba (ún. cluster-ba) foglalunk, és a cluster-ek láncolt listájával dolgozunk. Ilyenkor persze romlik a diszk blokkok kihasználtsága, mivel nem valószínq, hogy a fájljaink mérete cluster-ek szorzata.


I-bögök, f-bögök alkalmazása

A Unix fájlrendszer tervezésénél kialakított koncepció szerint minden fájlhoz tartozik egy bög (node), egy adatstruktúra, ami a különbözQ fájl attribútumok mellett a fájl egymás utáni blokkjainak elhelyezkedését is rögzíti. A Unix i-bögök a partíció meghatározott helyén találhatók, együttesen alkotják az i-listát. A jegyzék bejegyzésben megadva az i-bög indexét (az i indexet) megragadható az i-bög, ezzel az egész fájl. Más operációs rendszerekben kissé hasonló koncepcióval f-bögök segítségével kezelhetQk a fájlok blokkjai (HPFS és NTFS fájlrendszerek).




60.) Fájlrendszer-megvalósítás Unix-ban: partíciószerkezet, szuperblokk, i-lista, jegyzékek


Partíciószerkezet

A /dev 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ökrQl van szó.
Tartalmuk (elég rövidek!):
major device number azonosítja a controller/adapter-t ,és egyben a device drivert a kernelben.
minor device number azonosítja az eszközt, ami a controller/adapter-hez kapcsolódik

A logical disk modell UNIX-ban 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 speciális fájl (pl.:/dev/dsk/0s0). Ez megoldja a driver-adpter/controller-device azonosítást.

i-lista

Az i-bög (i-node) egy bejegyzés egy információs táblában (i-list), fájlok fontos jellemzQit, 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ög 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 kernel 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.(az i, index az i-bög táblában (i-list-ben) az i-bög-höz)
Az i indexek értéktartománya: i =1  valameddig. A szuperblokkba (superblock) van bejegyezve a gyökér i-bög.

A jegyzékek tartalma

A jegyzékek bejegyzései: i-index -név párok. A jegyzék implementációból következik, hogy a jegyzékek bejegyzései nem rendezettek, lehetnek bennük üres bejegyzések, bennük a keresés szokásosan szekvenciális.

A szuperblokk tartalma

A szuperblokk információkat tartalmaz az egész fájlrendszerrQl. Minden logikai diszknek az 1. blokkja. Ma is 512 byte. Némelyik Unix rendszer másolatokat is Qriz 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övetkezQ 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
indexet a következQ szabad i-böghöz a szabad i-bögök listáján,
lock mezQt a két szabad listához,
egy jelzQt (flag), ami jelzi, hogy történt-e módosítás a szuperblokkban.

Az ún. mounted file system szuperblokkja benn van a memóriában is (in-core superblock), ez gyorsítást eredményez. A sync parancs segítségével idQnként kiírjuk a lemezre is a szuperblokkot. Csak úgy kikapcsolva a Unix-os gépeket széteshet a fájlrendszer, ha nincs kiírva az aktuális szuperblokk.



61.) A Unix i-bög. Fájlkészítés forgatókönyv, fájltörlés forgatókönyv, i-bög allokálás-eleresztés,
blokkallokálás-eleresztés



I-node (Information node (i-bög) )

Az i-bög (i-node) egy bejegyzés egy információs táblában (i-list), fájlok fontos jellemzQit, 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ög 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 kernel beolvassa ezt a táblát a memóriába (in-core i-node list) és azon manipulál.


Az i-bög-ök (i-node -k) tartalma

mode és védelmi maszk
linkek száma (vajon ez mi?)
a tulajdonos uid-ja
a tulajdonos gid-je
a fájl mérete
10 db direkt pointer
3 db single-double-triple indirekt pointer
3 db dátum/idQ (utolsó hozzáférés, utolsó módosítás, készítés dátuma/ideje)



Fájlkészítéshez a következQt kell tenni

Allokálni kell egy i-bögöt (ialloc), azt ki kell tölteni, a jegyzék bejegyzést ki kell tölteni.
Allokálni kell a fájl számára szabad blokkokat (alloc), be kell jegyezni ezeket az i-bögbe, és tölthetjük a blokkokat az adatokkal.


A fájl törlés lépései (miután a linkszámláló elérte a 0-t)

Az adatblokkjait szabad listára kell tenni a szuperblokkban.
A fájl i-bögjét szabad listára kell tenni (ifree algoritmus).


Blokkok allokálása, felszabadítása

A szuperblokk egy listáján tartalmaz valamennyi szabad blokk bejegyzést, továbbá egy láncolt listán nyilvántartja az összes szabad blokkot.





62.) Unix fájlrendszer létrehozás (mkfs), használatbavétel (mount, umount)


Fájlrendszer létrehozása

A rendszer adminisztrátor (superuser) 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 rendbe szedhet. 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 diszkrQl felépül. Lehetnek még más logikai diszkek, rajtuk létrehozott fájlrendszerek, de ezen a ponton azok nem kezelhetQk.


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 jegyzékének számít. A logical-disk, pontosabban az azon lévQ fájlrendszer "hozzáadódik" a hierarchikus fájlrendszerhez! Az új fájlrendszer "használhatóvá válik".
Ezután pl.: kiadható a következQ parancs:
#cd /usr/lib
A mount-olás ténye a /etc/mnttab (mount table)-ba bejegyzQdik! Ez az ú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.

Az eredeti fájlrendszer: root file system, original file system, mounted on file system. Ennek egy üres jegyzékére mount-olhatunk. Ez elérhetQ kell legyen.

Mountolt eszköz: mounted device, mounted file system. A mountolt eszköz speciális fájlneve. Ez a fájlnév az eredeti fájlrendszerben a /dev jegyzékben van valahol.

EbbQl vehetQ 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. Az i-bög tábla másolata az in-core memóriában van!

A buffer cache: Pointerekkel mutathatunk bufferekre, a bufferekben adatblokkok lehetnek, többek között lehetnek eszközök szuperblokk másolatai is.


Ezek után egy bejegyzés a mount táblába a következQ elemeket tartalmazza

a mountolt eszköz logikai száma (logical device number of mounted file system)
buffer pointer, ami a mountolt eszköz szuperblokkjára mutat
a mountolt eszköz gyökér jegyzék i-bögére mutató pointer
a mount jegyzék i-bögére mutató pointer




63.) "Linkelés" a Unixban: hard link, soft link



ElQfordulhat, hogy már egy létezQ fájlt - aminek a neve be van jegyezve egy jegyzékbe, van i-böge - szeretnénk egy másik névvel is elérni. Ezt a más nevet lehet, hogy nem is ugyanabban a jegyzékbe szeretnénk bejegyeztetni. Másolhatnánk a fájlt, de ebben az esetben az új fájl tartalma csak pillanatnyilag egyezik az eredetivel, akár a régit, akár az újat változtatjuk, máris nem egyeznek meg a fájlok. Továbbá, a másolással duplázzuk a helyfoglalást. Mi azt szeretnénk, hogy a két (vagy több) név tényleg ugyanarra a fájlra hivatkozzon, bármelyik névvel elérve a fájlt azt módosítjuk, a másik neveiken vizsgálva is lássuk a változtatást. Ha úgy tetszik, az eddigi tisztán hierarchikus fájlrendszert szeretnénk hálóssá tenni. Nos, a Unix fájlrendszer implementáció erre lehetQséget ad a linkelés segítségével.

Az ún. hard link esetén egy új directory bejegyzés készül a megfelelQ jegyzékben. Az új jegyzék-bejegyzésben az i index egy már meglévQ fájlhoz tartozó i-bögre mutat.
Ugyanakkor az i-bögben növekszik a linkszámláló: azt jelzi, hogy ezen i-böggel azonosított fájlra több jegyzék bejegyzés is hivatkozik. Minden más attribútum változatlan. Marad a védelmi maszk, a tulajdonosi és csoporttulajdonosi bejegyzés, ezért az elérési jogok korlátozhatnak. Fájl törlés esetén csak a linkek száma csökken, és egy directory bejegyzés tqnik el, ha a linkszám még nem 0, az i-bög továbbra is foglalt.

A soft, vagy symbolic link során készül egy új fájlnév bejegyzés, új i-böggel. Az új i-bög hozzáférési maszkja új, a tulajdonossági információk is újak, a blokkpointer mezQk tartalma azonban nem a szokásos. A pointerek helyett itt a másik fájl abszolút ösvényneve van feljegyezve, ennek szimbolikus linknek segítségével megkereshetQ az "eredeti" fájl. Ha az eredeti fájlt törlik, a szimbolikus link "sehova se mutat", hibajelzést kapunk hivatkozáskor. Szimbolikus linkkel különbözQ fájlrendszerek fájljai is összefqzhetQk.




64.) A HPFS és az NTFS fájlrendszerek. Sávok, bittérképeik, jegyzékszerkezetük, f-bögük,
kiterjesztéseik (extents)


A partíció meghatározott (konvencionális helyén található) területe a bit/mezQ térkép. Bit/mezQ bejegyzések vannak a térképen, éppen annyi, ahány blokk található a partíción. Egy az egy megfeleltetés van a bitek/mezQk és a diszk blokkjai között: az i-edik blokkhoz az i-edik bit/mezQ tartozik. A szabadság vagy foglaltság jelzésére a megfelelQ bit 0 vagy 1 értékq, a megfelelQ mezQ 0, vagy a foglaltságot jelzQ egész bejegyzésq. A bit-térkép, gyorsítási célokból in-core memória másolattal kezelhetQ. Nagy diszkeken egy-egy bithez/mezQhöz cluster rendelhetQ. Gyakorlatilag ezt a módszert használja a VAX/VMS, a HPFS, az NTFS és az MS-DOS FAT fájlrendszere is.



Az NT által használt fájlrendszerek

FAT
VFAT
HPFS
nagy partíciók, fájlok
nem egy helyen vannak a driver információk
a directory B-fa forma
hibatqrQ
8 MB-os sávok, majdnem 16 MB-os folyamatos területek
2 KB-os könyvtárblokkok jellemzik a jegyzékszerkezetet (középsQ sávon)
NTFS
még nagyobb partíciók
még hibatqrQbb
16 MB-os sávok, majdnem 32 MB-os folyamatos területek
a könyvtárblokkok közel vannak a fájlokhoz



HPFS/NTFS

A szabad-blokkmenedzselés bittérképes, de a bittérkép el van osztva.


bit-térkép elosztva

A bit-trékép elosztásának elQnyei

közel van a térképezendQhöz a térkép
így lehetnek elég nagy folyamatos területek




A jegyzékek bejegyzései (név + f-node) B-fa formába vannak szervezve, mely gyors keresést tesz lehetQvé. A név max. 254 karakter hosszú lehet.


Az f-node tartalmazhat

kiterjesztett tulajdonságokat
hozzáférési jogosultsági listákat (ACL)
a név elsQ 15 karakterét
az elsQ 8 kiterjesztés (extent) adatait


EXTENT: folyamatos, maximum 16 | 32 MB hosszú bittérkép. A kezdet | hossz van feljegyezve. Fájlhoz történQ blokk-allokálás esetén igyekszik olyan új sávon allokálni, ahol nagyobb extent alakítható ki.

Ha a 8 extent nem elég, akkor alkalmazható az indirekció.


Hátrány a FAT-hoz képest

nagy diszk-kapacitás szükséges
16 MB-nál nagyobb memória szükséges








65.) Linux ext2 fájlrendszer. Blokkcsoportok, i-bög, jegyzékszerkezet


A LINUX-nak többrétegq fájl-rendszere van.

Fájlrendszere lehet

NTFS
HPFS
Minix
MS DOS: VFAT
Second Extent (ext2)  a LINUX sajátja
proc

Mindegyik implementált fájlrendszerhez a Virtual File System (VFS) en juthatunk el. Ezen a VFS szinten minden fájlhoz i-bög tartozik.




Blokk-csoport leíró (Group Descriptor): 32 byte

Block bitmap: blokk-térkép mérete blokkokban
Inode bitmap: i-bög-térkép mérete blokkokban
I-node table: az i-list mérete blokkokban
No. of free blocks: szabad blokkok száma
No. of free inodes: szabad i-bögök száma
No. of dirs: jegyzékek száma



I-bög
fájl i-böge közel van a jegyzékhez, lehetQleg ugyanabban a blokkcsoportban
jegyzék i-böge olyan blokkcsoportban van, ahol kicsi a jegyzékek száma
további fájl-attribútumok lehetnek a standard UNIX attribútumok mellett

Jegyzék-szerkezet
nem valódi láncolt lista
törléskor az elQzQ bejegyzés hosszát növelik
beíráskor egy bejegyzést megoszthatnak






66.) OS rendszermenedzser feladatai. Kockázatok és védelem


A rendszermenedzser legfontosabb feladatai

a rendszer installálása, hangolása (setting up), méretre alakítása, karbantartása (updating), erQforrás kezelés, kontrol: újabb eszközök, perifériák felvétele, levétele (connecting devices
a rendszer indítása, leállítása (startup-shutdown)
konfigurációs fájlok karbantartása, daemonok indítása, adott idQben futtatandó parancsok indítása (crontab), kommunikációs beállítások stb.
a felhasználók menedzselése (felvétel, törlés, jogosultságok kiosztása stb.)
a fájlrendszer mentése, visszaállítása (backup, restore, recovery)
a fájlrendszer integritás biztosítása (fsck), szabad terület karbantartás.
naplózások, események figyelése (monitoring), statisztikák készítése, számlázás.

Szinte mindegyik tevékenység kapcsolatos a biztonsággal. Nagy rendszereknél a rendszermenedzser mellett külön biztonsági menedzsert (security manager) foglalkoztatnak.


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 kell keresni, hogy a biztonsági komponensek ne legyenek bosszantóak, hátráltatóak.


A fenyegetések osztályai

I. Fizikai fenyegetések

Természeti csapások (tqz, földrengés stb.)
Jogosulatlan hozzáférések laboratóriumokhoz, gépekhez, berendezésekhez (betörés, kulcsmásolat készítés, beléptetQ rendszer kijátszása stb.).

II. Logikai fenyegetések

Felhasználók felelQtlensége, tévedése (pl.: meggondolatlan törlések: del *.*).
Jogosult szolgáltatás megtagadás valamilyen probléma miatt.(pl.: garantált válaszidQt meghalad a szolgáltatás, és ennek jogi, gazdasági következményei vannak, eszköz-tönkremenetel miatt adatvesztés és biztonsági másolatok nincsenek stb.).
Jogosulatlan hozzáférések erQforrásokhoz, információkhoz, szolgáltatásokhoz. Ezen belül érdemes külön kezelni a következQ osztályokat:
felhasználók kíváncsisága, jogosultsági határainak kipróbálása, a biztonsági háló lyukainak keresésére tett próbálkozások;
behatolás károkozási szándékkal, a biztonsági háló lyukainak felhasználása kártevQ módon: copyright sértés, információ eltulajdonítás, kémkedés, személyiségi jogok sértése, "gépi idQ" lopás, információk törlése, baktérium-vírus-worms programok készítése stb.

A felhasználók tévedései ellen alig szoktak központilag szervezetten védekezni, bár a rendszeres, központilag szervezett mentések itt is segíthetnek. Célszerq biztonsági másolatokat készíteni és azokat "más "helyen Qrizni!




67.) Kockázatok és védelem: azonosítás és hozzáférés. Védelmi tartományok. ACL és CL


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 megmondani, hogy a szubjektum mely védelmi tartományba (protection domain) tartozik. A felhasználók azonosítására vannak külsQ és belsQ azonosítási technikák. Pl.: külsQ azonosítási lehetQség mágneskártyás vagy vonalkódos engedélyeztetQ rendszer, gépet, szobát lezáró kulcs stb. BelsQ azonosítási technika pl.: a jelszós (password) védelem, vagy 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 jelszós azonosítás problémaköre, ez ugyan egy kiváló azonosítási lehetQség, de egyben egy lehetséges lyuk a biztonsági hálón.

A hozzáférési jogosultságok (authorisation) fogalomköre

Objektumok (erQforrások) elérése, ezekhez való hozzáférések privilégiumainak gyqjtQneve az authorisation. Fájlokat (ezek objektumok) lehet
olvasni r (read),
írni, újraírni w, rw (write, rewrite),
lehet tartalmukhoz hozzáfqzni a (append),
lehet törölni d (delete)
végrehajtani e (execute)

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 jelezhetQk a w, r ,d betqkkel.

A védelmi tartomány (Protection Domain)

A védelmi tartomány a védett erQforrások hozzáférési privilégiumainak összessége.

A védelmi hálók leírásának két, különbözQ szervezettségq formája lehetséges. Az egyik a hozzáférési jogok listája (Access Control List, ACL), rövidebben hozzáférési lista (Access List), a másik a jogosultsági listák (Capatibility List, CL) formája. A hozzáférési listán azt ellenQrzik belépéskor, hogy 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 a védelmi tartomány-azonosítási lehetQséget és az objektumhoz való hozzáférési jogokat. Ha úgy tetszik, a lista "sorokból" áll. Sorai az objektumok, hozzá felsorolva, mely védelmi tartományban milyen hozzáférési jogok vannak:
A hozzáférések ellenQrzéséhez a folyamatokról csak annyit kell tudni, hogy az melyik védelmi tartományban fut.
Ennek a formának elQnye, hogy az ACL viszonylag rövid lista, többnyire könnyen kezelhetQ. 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 kezelhetQek.

A jogosultsági lista

Ez a forma - meglehetQsen régi - egyre nagyobb jelentQségq: osztott rendszerekben, hálózatokban lehetetlen a védelmi tartományokat tárolni. A jogosultsági lista az engedélyezett mqveletek jegyzéke.
A forma: sorok az egyes védelmi tartományokhoz, bennük felsorolva az objektumok és a hozzáférési jogok.



68.) A Unix védelmi rendszer. Tulajdonosságok és hozzáférések. A setuid koncepció


A Unix (fájl) védelmi rendszere ACL jellegq. 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 kezelhetQk, a csövek szintén a fájlrendszeren keresztül védettek. A Unixban a szubjektumok mindig processzek.

Minden fájlhoz az i-bögben (i-node) tárolják

az objektum tulajdonosát (uid),
a csoporttulajdonost (gid),
és imlpicite ezzel a többieket (others)

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 i-bögben.
Ez a hozzáférési lista tehát nem hosszú, könnyen elfér az i-bögben. Hátránya viszont, hogy nem olyan flexibilis, mint a teljes ACL rendszer, egy fájlnál nem lehet különbözQ csoportokat azonosítani, egy fájl csakis egy csoporthoz tartozhat.

A lényeg tulajdonképpen az, hogy a védelmi tartományok a tulajdonossági kategóriákon keresztül azonosítottak:


EbbQl az látható, hogy egy fájl három védelmi tartományba tartozik. Mint láthatjuk, 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ölhetQ, nem futtatható
w write: engedély a változtatásra, beleírhatsz, átírhatod, hozzáfqzhetsz, törölheted. Egy szövegfájl, amire csak w engedélyünk van, nem tölthetQ be egy szövegszerkesztQbe: hiányzik az r jog, de hozzáfqzhetünk adatokat.
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 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 a setuid koncepció 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.


Védelmi politika

1. ElQször a hozzáférni akaró processz effektív tulajdonosági kódja és a fájl tulajdonossági kódja összevetQdik. Ha itt egyezés van, akkor a fájltulajdonoshoz rendelt jogosultság (rwx bitminta) szerint biztosított a hozzáférés.

2. Ha az elQzQ összevetésben nincs egyezés, akkor a csoport tulajdonosságok vetQdnek össze. Egyezés esetén a fájl i-bögjébQl a csoporthoz tartozó bitminta szerinti a hozzáférés.

3. Ha az elQzQ két összevetés "sikertelen", akkor az others bitminta szabja meg a hozzáférést.


Ez azt jelenti, hogy a 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.


A setuid koncepció (D.Ritchie)

Minden processz rendelkezik valós tulajdonosi, csoporttulajdonosi azonosítóval, és effektív tulajdonosi, csoporttulajdonosi azonosítóval. A legtöbb esetben a valós és az effektív tulajdonosságok ugyanazok.
A valós tulajdonosságot a processz a szülQjétQl örökli, vagy a szülQje állítja be neki. Gyakran szükség van arra, hogy különleges többlet-jogokat biztosítsunk processzeknek valamilyen szabályozott módon. 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 ún. setuid/setgid engedéllyel rendelkeznek. Amikor egy ilyen programot futtatunk, a keletkezett processz valós tulajdonosa mi leszünk, hiszen a mi shell-ünkbQl indítottuk, annak tulajdonosságait örökli. Az effektív tulajdonosa/csoport-tulajdonosa viszont az az uid/gid lesz, ami a betöltendQ program fájlhoz tartozik.




69.) Felhasználók menedzselése. Számlaszámok, jelszóválasztás, kiosztás


Számlaszámrendszer, ennek menedzselése

A számlaszám (account) egy azonosító, nevébQl következQen

erQforrás felhasználás számlázására, nyilvántartására stb. szolgál, de ezen belül jó
tulajdonossági kategóriák rögzítésére (ezzel védelmi tartományok azonosí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) szolgáló személyes használatú számlaszámok. Ezek a szokásos (ordinary) felhasználói számlaszámok.
Bejelentkezésre nem szolgáló, de a tulajdonosságot jelölQ számlaszámok (bizonyos system account-ok).

II. A védelmi háló szerint
Korlátozott jogokat biztosító (restricted) számlaszámok, mint pl.: egy titkárnQi számlaszám.
Szokásos (ordinary) számlaszámok, pl.: fejlesztQ munkára, általános használatra.
Privilegizált számlaszámok, melyeket a rendszermenedzserek, biztonsági menedzserek, programrendszer felelQsök stb. kaphatnak.


Egy számlaszám komponensei

A login név: lname, amit a rendszermenedzser és a felhasználó közösen, megegyezéssel választ, hogy egyedi legyen.
A hozzátartozó, változtatható jelszó (password), néha több jelszó. Kezdeti értékét a rendszergazda adja, közli a felhasználóval, aki utána megváltoztathatja. Néha kötelezik is a változtatásra.
BelsQ azonosító: uid, UIC. Ezt a rendszergazda 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 felhasználó megegyezve választják, vagy csoport nevek.
Csoport azonosító: gid, GUI. Rendszergazda választja. Néha több csoport-azonosí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 bejelentkezéskor induló processz program fájljának neve a bejelentkezési számlaszámokhoz. Rendszerint ez egy burok, de lehet egy alkalmazás is (pl.: titkárnQnek).
Limitek és quoták a számlaszámhoz. Capatibility list jellegq! A Unixban ilyen csak közvetve van.
Általános adatok a felhasználóról: teljes név, szoba szám stb., kommentár jellegq.




70.) A Unix számlaszám rendszer. Adatstruktúrák. Felhasználó felvétele és törlés Unix-ban


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 init processz program fájlja.

/bin/passwd ami megkövetel bizonyos szabályokat. Pl.:
legalább x karakter hosszú legyen a jelszó
változatos karakterekbQl álljon
régi jelszavakat nem engedni újra
jelszó generátor lehetQséget ad, stb.

A Unix /etc/passwd fájl sorainak mezQi ( : a mezQelválasztó)
lname
pwd
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 superuser;
-1 invalid accounthoz;
-2 az NFS nobody számlaszám;
1 -10 rendszer számlaszámok;
11 -99 fontos, kitüntetett személyek;
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 mezQi (egy sor egy csoport)

gname
pwd
gid
lname-k listája, vesszQ szeparátorral elválasztva a nevek

A superuser (rendszermenedzser) e két fájl karbantartását erre a célra írt shell programokkal végzi,
amik összehangoltan kezelik a dolgokat. Miután azonban ezek egyszerq szövegfájlok, a superuser egy szokásos szövegszerkesztQvel is karbantarthatja Qket, ügyelnie kell azonban ekkor az összehangolásukra.


A login program használhat még két fájlt

/etc/dialups # az "Qrzött" eszközök speciális fájlnevei;
/etc/d_passwd # a hozzájuk tartozó jelszók.



71.) A NIS rendszer. A NIS adatbázisa, démonjai


A NIS központosított adatbázis, ami a hálózat használatát hatékonyabbá teszi. Tipikus példa lehet a hálózati névfeloldás: a hálózati csomópontok neveihez sokszor szükséges hozzárendelni az IP címet. Ha nincs NIS rendszer, akkor ezt a fájlt az egyedi csomópontokon karban kell tartani, állandóad naprakész állapotba kell hozni. Ha 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.

A szokásos kliens szerver koncepcióval dolgozik a NIS. Egy NIS kliens gépen futó processz küldhet egy kérelmet egy NIS 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.

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: szerepük tulajdonképpen akkor van, ha valamilyen okból a master nem tudja kiszolgálni a klienstQl jövQ kérelmet. Ilyenkor a kérelmet valamelyik slave kapja meg, és az szolgál ki.

A NIS képek (maps)

A NIS adatbázis képekbQl áll. Egy kép (map) fájlok csoportja. A map-ekben dbm adatbázis formában találhatók az adatok, nem ASCII formában: ennek oka a gyorsabb keresés, a hatékonyabb tárolás. Minden képnek van neve. A kliens gépeken futó alkalmazásoknak tudniuk kell ezeket a neveket, mert a kérelmeiket a map-ek neveivel adják ki, továbbá tudniuk kell a map-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.

A NIS tartományok (domain)

Egy NIS tartomány gépek csoportja, melyek ugyanazt a NIS adatbázist használják. A tartományoknak van nevük. A tartományhoz tartozik egy master server gép, és tartozhat néhány slave server. Ezen kívül a tartományhoz tartozhat valamennyi kliens gép. A szerver gépek egyben kliens gépek is.
A NIS tartomány egybeeshet az Internet tartománnyal, de ez nem kötelezQ.

A NIS daemon processzek

Három daemon processz segíti a NIS rendszert. Ezek az ypbind, ypserv és az rpc.passwd processzek.




A NIS adatbázis

Az adatbázis képei dbm formájúak. A szokásos ASCII formából a rendszermenedzser a makedbm segédprogrammal alakíthat fájlokat erre a formára. A NIS adatbázisban vannak standard és lehetnek nem standard képek (map-ek).




72.) Rendszerindítás (startup), leállítás. A Unix init processze


Rendszerindítás

Egy többtaszkos, esetleg többfelhasználós operációs rendszer indítása rendszerint bonyolultabb feladat, mint egy egyszerq gép bekapcsolás. Persze, ha jól installálták, jók az alapbeállítások (setup), jó indító (startup) konfigurációs burok programokat írtak hozzá, akkor lehet, hogy egyszerq az indítás.

A gép bekapcsolása után az operációs rendszer indulása több fázisban történik; a fázisok durván:

1. A hardver ROM rutinok futnak.
2. Az ún. boot loader fut.
3. Az operációs rendszer kernel inicializálódik.
4. A "kézbQl" induló processzek keletkeznek.

A ROM rutinok teszteléseket végeznek, ellenQrzik a memóriát, egyéb hardver komponenseket. Lehetséges, hogy interaktív menüt kínálnak, esetleg az intelligens kontrollerek felprogramozását segítik. Ezeket a gép szállítója adja 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 kijelölt partíció 0. blokkjáról betöltQdik a kezdeti betöltQ (initial boot) program, és elindul. (Nem boot-olható partíció, eszköz kezdeti betöltQ programja egy üzenetet ír ki, hogy nem rendszer diszkrQl akartunk boot-olni.). A kezdeti betöltQ program 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 konzolról.

A second stage boot program lehet része egy operációs rendszer fájl-rendszerének: ott egy fájl, adott névvel, de speciális helyen van, hogy a kezdeti boot program -ami rövid program, elfér egy blokkon -felismerhesse. Lássuk be, hogy a két boot program együttmqködQ kell 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, kérve a kernel nevét, helyét stb. Ezek természetesen operációs rendszertQl függQ dolgok.

A kernel -miután betöltQdött -indul: inicializálódik. Ezzel tulajdonképpen felkészíti a hardvert és a szoftvert használatra.

Az inicializált kernel végül kreál processzeket. "KézbQl" készül a 0. pid-q processz, SVID Unixnál ez a swapper, más, újabb Unix-oknál a sched. A swapper/sched feladata lesz az ütemezés. Most azonban elsQ tevékenységeként elkészíti az 1. pid-q processzt, az init processzt.
Az init processz lesz általában minden más processz szülQje. Állapotai (states): boot, normál, powerfail. Konfigurációs fájlja a /etc/inittab, vagy a /etc/ttys. Szignálok hatására az init a konfigurációs fájljához fordul, az abban meghatározottaknak megfelelQen cselekszik.

Boot állapotban
dátum/idQ/idQzóna ellenQrzést, beállítást végeztethet;
megkérdezheti, akarunk-e fájlrendszer ellenQrzé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;
daemon-okat indít


A boot állapothoz a single user level tartozik. 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 hajthat végre az init.

A Unix futási szintek (Run Levels)

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 init mqkö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), ami bekövetkezett. Az init e három információ szerint, beolvasva az inittab-ba, kiválasztja a megfelelQ sort, és a szerint cselekszik. Programok indításánál feljegyzQdik, melyik inittab sorral történt az indítás. Az inittab egy tipikus sora a következQ szerkezetq:

label:run level:action:program to start

A címke (label) mezQ szerepe a számlázásnál, monitorozásnál jön elQ. A run level mezQ szerepe az ellenQrzés. Az action mezQ reprezentálja az akciót.


A rendszer leállítása

A szokásos rendszerzárást a /etc/shutdown burokprogrammal végzi a rendszermenedzser (kiadása elQtt a gyökér jegyzék legyen az aktuális jegyzék, az unmont-ok miatt). Grafikus felhasználói felületnél toolchest menüelemmel 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





73.) Unix fájlrendszer-készítés és használatbavétel. Fájlrendszer integritás helyreállítás (fsck)


Tételezzük fel, létezik logikai diszk a rendszerünkben. Ekkor az mkfs segédprogram segítségével fájl-rendszert készíthet a szuperuser a logikai diszken. Az mkfs elQszö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 összegyqjti. 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.

#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ó. Az alapértelmezési i-lista méret úgy számítódik, hogy 4K-ként lesz i-bög, azaz átlagosan 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 ellenQrzé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élszerq készíteni lost+found jegyzéket, ugyanis az fsck használja ezt! Persze, ezt csak mountolás után tehetjük. A következQ 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élszerq engedélyekkel. Van benne két bejegyzés is, a . és a ..jegyzék. Van benne hely valamennyi további bejegyzésre. Miután az fsck több bejegyzési helyet is kívánhat, célszerq a lost+found méretét megnövelni, mielQtt 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.


Fájlrendszer konzisztencia ellenQrzés (fsck)

Nem megfelelQ eszközkezelés, nem megfelelQ rendszerzárás esetén a fájl-rendszer "széteshet". A szétesés leggyakoribb okai: áramkimaradás miatti nem normális rendszerzárás; kivehetQ médium (pl.: floppy) kivétele umount elQtt.


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ékbQl van az i-bögre utalás.











Mi jelzi a szétesést?

A superblock egy mezQje. Vagy az a tény, hogy a szuperblokkba bejegyzett i lista méret és a valódi i lista méret nem egyezik. Segédprogramokkal lekérdezhetQ, vajon egy fájl-rendszer szétesett-e vagy sem, de legjobb minden mountolás elQtt az fsck segédprogrammal ellenQrizni, és megpróbálni rendbe hozni 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
fázis: az i-bögök ellenQrzése, adatgyqjtés a további fázisokhoz.
fázis: az ösvények ellenQrzése.
fázis: kapcsolat ellenQrzés.
fázis: hivatkozások ellenQrzése.
fázis: a szabad lista ellenQrzése.
fázis: szabad lista helyreállítás.




74.) Archiválás és visszatöltés. A tar a Unix-ban


Fájlok, fájl-rendszerek tönkremehetnek, letörölhetjük Qket véletlenül, és ha nem 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, amikrQl visszatölthetünk (restore, recovery), újra elQállítva valamilyen korábbi állapotot. A mentési eszközök lehetnek szalagok, kazetták, diszkek, CD-k. a továbbiakban a
/dev/tape eszköznév a mentési médiumot jelzi, akármi is lehet az.

A mentések fajtái lehetnek
fájlok szerinti (file-by-file) mentések;
diszk kép másolat (image copy).
Az elQbbiné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
teljes mentés (full backup) a teljes fájlrendszer mentése;
részleges mentés (partial backup) egy adott jegyzék alatti jegyzékrendszer menté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övekményes mentéseket (incremental backup) is: ezek azon fájlok másolata, melyek egy adott idQ óta (rendszerint a megelQzQ mentés óta) változtak (vagy éppen csak a változások feljegyzése). Ez is gyors, kis területet igényel, de egy idQ után nehéz a követése.

A rendszermenedzser, vagy a biztonsági menedzser feladata, hogy stratégiát dolgozzon ki arra,
mikor mentsenek (pl. amikor nincs nagy terhelés)
milyen gyakran mentsenek
milyenek legyenek a mentési technikák, a mentés-ellenQrzések (verification), nyilvántartások stb.



A tar (tape archive) segédprogram

Kapcsolói
c új mentést készít (create a new tape);
v bQvebb információt ad (verbose=fecsegQ);
f a követQ argumentum a tape;
t listázza a tape-n lévQ neveket;
x extract;
u update;

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ésbQl 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 ellenQrzéssel). Képes a tape határokon átlépni (multi-volume). A POSIX szabványnak megfelel.




75.) A nyílt rendszer elv, az Open Group


A nyílt rendszer elv

Az X/Open szervezet küldetése, hogy a nyílt rendszer elvet terjessze, és elQsegítse a nyílt rendszerek gyakorlati megvalósítását.

Az X/Open meghatározása szerint az tekinthetQ nyílt információs rendszernek, ami 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üttmqködés (interoperability) és
a fokozatos bQvíthetQség (scalability).

A gyártófüggetlenség azt jelenti, attól a gyártótól szerezhetjük be a termékeket, amelyik a legjobb ár/teljesítmény viszonyt biztosítja. További elQnyök származhatnak a nyílt rendszer elvbQl:

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.

Az X/Open Company egy független, non-profit szervezet, amelyet 1984-ben alapított az öt legnagyobb európai számítógépgyártó cég. A konzorcium késQbb részvénytársasággá alakult át, és jelenleg 15 tulajdonosa van. A Novell, a Unix System Laboratories tulajdonosaként úgy döntött, hogy a UNIX védjeggyel kapcsolatos jogokat az X/Openre ruházza, ezzel a továbbiakban a UNIX rendszer interfész specifikációinak továbbfejlesztése is az X/Open felügyelete mellett történik.


The Open Group

1996-ban az X/Open szervezet és az OSF (Open Software Foundation) egyesült, ez az új szervezet lett az Open Group. Az egyesülésbe további csoportokat is bevontak

Az utóbbi években átalakult a terminológia és a minQsítési rendszer. A CAE specifikációk helyett ma Technical Standards kifejezésekkel említik az elfogadott szabványokat, az XPG minQsítés helyett az Open Brand márkajel megszerzés minQsíti a termékeket. Az XPG-kben használatos profil és komponens terminológiát felváltotta a Product Standards kifejezés.

A legfontosabb megszerezhetQ minQsítések a UNIX 95, és ennek továbbfejlesztett változata a UNIX 98, ez utóbbi alesetei: UNIX 98 Workstation és Server minQsítés.




76.) Az Open Group UNIX95 és UNIX 98 specifikációi


Operációs rendszergyártók, fejlesztQk és felhasználók a 90-es években közös munkát folytattak, melynek a célja a Unix rendszerek közös felhasználói interfészének definíciója volt. A munka eredménye a Spec 1170 néven ismertté vált specifikáció lett: a specifikációban 1170 API-t definiáltak. A definíciók különbözQ ipari szabványokból (ISO C, POSIX.1, POSIX.2), vagy "de facto" szabványokból lettek kiválasztva (azaz nem szabványosítási munka folyt itt).
Az X/Open egész kis módosításokat tett és kiadta az eredményt: Single UNIX Specification címmel
A jelentQsége ennek: a Unix a továbbiakban egyetlen cégnek sem "privilégiuma", különösen, ha figyelembe vesszük, hogy a Novell a UNIX márkajegyet átadta az X/Open részvénytársaságnak. Ezzel a Unix "de facto" szabványa született meg, a Single UNIX Specification és az X/Open Curses, Issue 4 specifikáció együtt adja az X/Open Unix specifikációt.
Persze, ez még csak specifikáció, nem jelenti azt, hogy minden Unix így is néz ki. De megvan az alap, ebbe az irányba fejlQdhetnek a rendszerek, és átvihetQ (portable) alkalmazásokat készíthetnek a szoftvergyártók.

Kérdezhetjük, az X/Open munkacsoportjai, specifikációi miért nem voltak elegendQk? Vannak POSIX szabványok is, miért kellett a Spec 1170-et kidolgozni?
Az ok meglehetQsen pragmatikus, haszonelvq. A Spec 1170 kidolgozása során különbözQ Unix rendszereken több mint 20 nagy szoftvercég mintegy 50 alkalmazását vizsgálták, az 50 alkalmazás több mint 3500 könyvtári rutinját analizálták, valós teszteléssel, a legkülönbözQbb hardver platformokon. Az analízis eredménye az volt, hogy az eddigi "szabványos" interfészekhez még definiálni kell mintegy 130 további API-t. Azt mondhatjuk, hogy nem a világ leggyakoribb alkalmazásait illesztik a meglévQ Unix szabványokhoz, hanem a Unixot a meglévQ alkalmazás-világhoz.
Az eddigi szabványok kiegészítéséhez fQleg a BSD math és memó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, hogy ugyanahhoz a funkcióhoz különbözQ API-k voltak a különbözQ rendszerekben. Általában ilyenkor nem szükséges két implementáció, és ezt a problémát az egyik interfésznek a másikra való leképzésével oldották meg.





77.) A mach operációs rendszer


Miután a 4.2 BSD-ben fejlesztették, a Mach release 2-ig kompatibilis volt a BSD-vel!

A fejlesztési elvek, célok

Egyszerq kernel struktúra
KülönbözQ architektúrák támogatása
KülönbözQ hálózati sebességekhez való alkalmazkodás
Elosztott operációk, hálózat transzparenciával, továbbá külsQleg és belsQleg is objektumorientált szervezés.
A memóriamenedzsment és a processzközti kommunikáció integrálása
Heterogén rendszerek támogatása.

A BSD (általában Unix) örökségek, mint célok

Egyszerq és konzisztens programozói interfésze legyen
Sok segédprogram, könyvtári rutin segítsen
Segédprogramok együttmqködése csQvezetéken (pipe) keresztül biztosított legyen.
Könnyq legyen a telepítése egyprocesszoros rendszerekre is.

EzekbQl az építQkövekbQl leszármaztathatók a további funkciók. ElsQsorban a kommunikációs lehetQségekre koncentráltak, erre ugyanis sok minden "építhetQ". Ezzel a védelem is egyszerqbb, a kommunikációs mechanizmusok védelme egyben rendszer-széles védelmet ad. Sok tradicionális kernelszolgáltatás felhasználói szintq szolgáltató processzként megvalósított.

A Mach az objektumorientáltság példája is. Objektumokba zártak az adatok és az adatmanipulációk, elrejtettek a részletek, a megvalósítások. Ráadásul, az objektumok a hálózaton akárhol lehetnek! Mindezeket a port mechanizmus biztosítja: az objektumokat portjaik reprezentálják.

Melyek a Mach primitív absztrakciói?

A taszk: ami a végrehajtási környezet, az erQforrás kiosztás (resorce allocation) alapegysége.

A fonál (thread): a végrehajtás alapegysége (basic unit of execution).

A port: az alapvetQ objektum-hivatkozási mechanizmus.

A port-készlet (port set): portok csoportja közös üzenetsorral.

A üzenet (message): alapvetQ módszer a fonalak kommunikációjára.

A memória objektum (memory object): memória erQforrás. Egy taszk elérheti, ha leképzi azt (teljesen, vagy részben) a saját címtartományára.

A MACH memóriakezelése

A memória-objektumok a taszk címtartományára vannak leképezve. Ebben azonosított a memória-menedzser (portjával), és a másodlagos tároló objektum (a portjával). Laphiba esetén üzenet a megfelelQ 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.

Érdekességek

CPU allokálásnál nincs központi diszpécser; az idQ-szelet nem fix érték. Támogatott a default és a felhasználó által definiált kivételkezelés. I/O, fájlrendszer nincs a MACH-ban! Csak memóriamenedzselés! Az egyéb I/O-t, a fájlrendszert a MACH fölé telepített operációs rendszerek oldják meg!








PAGE 


Számítástechnika Szigorlat Operációs Rendszerek

-PAGE 2-

Hasonló témájú dokumentumok

Címzett rendszerek

- 2008-01-07 14:33:38

anyagi rendszerek (órai jegyzet)

- 2008-12-15 18:51:29

beugró kérdések

- 2008-06-12 08:47:21

politikai rendszerek

- 2008-05-14 17:20:36

beugró kérdések

- 2008-06-12 08:47:21

OS

- 2008-06-14 10:21:06

Operációs rendszerek vizsgakérdések

- 2008-09-20 15:45:58

A mások által feltöltött dokumentumokat értékelheted. Ha úgy ítéled meg, hogy a vizsgára való felkészülés szempontjából hasznos volt egy dokumentum, akkor adj rá sokcsillagos értékelést.
Ha hibákat tartalmaz, vagy egyéb probléma van vele, akkor keveset.
A dokumentumok sorrendje az értékelések alapján adódik. Ami fentebb van a listában, azt hasznosabbnak ítélték társaid. Az új dokumentumok pedig (értékelések hiányában) szintén a lista tetején kezdenek.

Hozzászólások

Ha észrevételed van egy dokumentummal kapcsolatban (például hibát találtál benne), akkor a Hozzászólások részben jelezheted. Az olyan jellegű kérdéseket mint pl.: A 2. feladat 4. sorából milyen átalakítással jutottunk az 5. sorban szereplő képlethez? - szintén ide érdemes írni

Egy tipp az oldalhoz! - Sikeres vizsga után írd meg tapasztalataid a tantárggyal, vizsgával kapcsolatban. Miből érdemes tanulni, mennyi készülés kell, milyen volt a vizsga... Ha mindenki így tesz, sokkal egyszerűbb lesz elkezdeni a tanulást egy olyan ember tapasztalatainak a birtokában, aki már elvégezte a tantárgyat. Ehhez kattints a tantárgyra a Tanulmányaimban, majd a Véleményem a tárgyról linkre a jobb felső részen.

00 2 eloadas 2.előadás algebra analízis dolgozat megoldás ásványok bakteriólógia barokk baudelaire biztonságpolitika dosztojevszkij emission trade eredménykimutatás eu agrárpolitikája fenntartható feudalizmus fotoszintézis függvényelemzés halál halász gábor juhász kisebbség kivitel konjunktúrakutatás környezeti számvitel lemezszegélyek lézer mechanika3 zh médiakutatás minden munka művészet növényrendszertan összefoglaló polgári jog pricing strategies sejttan szigorlat szociológia tétel szocioógia társadalom történet utazás váll. pü. vallás valós érték világirodalom 2. vízép xls vizsgapéldák vörösmarty zsidó