Más néven rendszermag, az operációs rendszer funkcióit ténylegesen megvalósító része

Fogalom és struktúra Rövid fogalmak: 1. OS ISO fogalom(Erőforrás menedzselés szempont): Olyan programrendszer, amely a számítógépes rendszerben a programok végrehajtását vezérli: így például ütemezi a programok végrehajtását, elosztja az erőforrásokat, biztosítja a felhasználó és a számítógépes rendszer közötti kommunikációt.

2. Kernel fogalma Más néven rendszermag, az operációs rendszer funkcióit ténylegesen megvalósító része.

3. System call fogalma Rendszerhívás, a programozónak futásidejű könyvtár rutin hívásnak tűnik (Run Time Library, RTL) -Információ átadás a paraméterekkel és a visszatérési értékkel (mint normál rutin hívás) -Pl.: count=read(file_d, buffer, nbyte); Különbségek: Módváltással járnak (trap) -belépés a kernel diszpécserébe

4. SVID, POSIX fogalma SVID (SystemV Interface Definition) az AT&T által szabványosnak tekintett SystemV rendszerhívásainak és szubrutinjainak egységes felhasználói felületét és definícióit határozza meg. Posix(Portable Operating System Interface for UniX) kollektív neve azon szabványok családjának, melyeket az IEEE, a Unix operációs rendszerek API-jának meghatározásaként definiált.

5. Esemény fogalma Esemény: folyamatok (taszk, processz, fonál, rutin, utasítás, instrukció) futását befolyásoló, váratlan időpontban bekövetkező történés, amire reagálni kell (le kell kezelni).

6. Maszkolható, nem maszkolható megszakítás A legalacsonyabb szintű események a megszakítások. -maszkolható: kiszolgálását ideiglenesen az OS letilthatja (pl. maszkolja az éppen kiszolgálásban levő IT-től alacsonyabb prioritású IT-ket) -nem maszkolható: nem lehet megakadályozni a kiszolgálását (pl. hardver hibák)

Kidolgozta: Csatlós Balázs

-1-

Hosszabbak: 1. OS fogalma, OS osztályozása 1. Erőforrás menedzser. Hatékonnyá teszi a géphasználatot. -Erőforrások menedzselése -Erőforrások: hardver (processzor, tárak, stb.), szoftver (alkalmazások, adatbázisok, stb.), emberi (felhasználók, rendszergazdák, stb.) -Menedzselés: Elosztás, védelem, nyilvántartás 2. Kiterjesztett gép (Extended Machine). Kényelmessé teszi a géphasználatot. -magasabb absztrakciós szintű (kényelmesebb) kezelhetőséget biztosít (elrejtve a részleteket) -Egységességet kínál a hasonló eszközök kezeléséhez -Helyettesíthetőséget biztosít 3. ISO fogalom Osztályozása • • •

•

Hardver függőség szerint -Személyi, kis, nagy gépek OS-e, architektúra független Cél szerint -Általános, vagy speciális célú Processzorok, processzek, felhasználók száma szerint -multi processing -single, vagy multi tasking -single, vagy multi user Az egyes opr. feladatok megvalósítása szerint -Időkiosztás szerint -Memóriakezelés szerint -I/O és fájlrendszer megvalósítás szerint -stb.

2. Kernel struktúra (három nézőpont). Funkcionális struktúra, Interface struktúra, Implementációs struktúra. Kernel struktúra (belső felépítés) több nézőpontból: A.) Milyen szolgáltatásokat (funkciókat) biztosít? (Funkcionális struktúrák) B.) Milyen felületeket (interface) ad a programozóknak, felhasználóknak? C.) Implementációs struktúra. Komponenseit hogyan állítják elő, köztük milyen interfészek vannak? A.) Funkcionális struktúra • Processz (taszk, fonál) menedzsment komponensek • Memória menedzselő komponensek • I/O menedzsment komponensek • Fájl-rendszert megvalósító komponensek • Védelmi komponens(ek) Processz (taszk, fonál) menedzsment komponensek funkciói: a) Processzek kreációját és terminálódását biztosító funkciók b) Processz/task/fonál kontroll, ütemezés -Állapotok nyilvántartása, -CPU ütemezés, kiosztás; felfüggesztés, engedélyzés, Kidolgozta: Csatlós Balázs

-2-

-processz szinkronizációs mechanizmusok (beleértve a holtpont elkerülését biztosító és a kölcsönös kizárási mechanizmusokat), -processz közti kommunikációs mechanizmusok. Memória menedzselő komponensek funkciói: a) Memória használatának nyilvántartása b) Memória allokálás/felszabadítás a processzek számára c) Címleképzés: logikai (virtuális) címek leképzése valós (buszra kiadható) címekre -közben ki/be söprés, vagy -ki/be lapozás. -Utóbbiakhoz kapcsolat a másodlagos tároló menedzsmenttel. I/O menedzsment funkciói: a) Eszköz driverek biztosítása -blokkorientált eszközökhöz (diszkekhez), -karakterorientált eszközökhöz (terminálok, nyomtatók, portok stb), -speciális eszközökhöz (óra, hálózat(?)) b) Szabad blokk menedzselés (diszkeken) c) Blokk allokálás/deallokálás (fájlokhoz, virtuális memóriához területekhez) d) Diszk-blokk buffer cashing Fájl-rendszert megvalósító komponensek funkciói: a) Directory struktúra biztosítása -Jegyzék implementáció, fájl-attribútumok rögzítése -Blokkhozzárendelés módszerei b) Fájlok kreálása/törlése c) Jegyzékek kreálása/törlése d) Fájlok írása/olvasása e) Fájlrendszer létrehozásának, helyreállításának segédprogramjai f) Mentések és visszaállítások segédprogramjai Védelmi komponens(ek) funkciói: Erőforrásokhoz való hozzáférésekkel kapcsolatos nyilvántartások kezelése. B.) Interface struktúra A programozók felülete: -Alkalmazásokból és processzekből: rendszerhívások(system call) és eseménykezelők: alkalmazás-programozási felület (Application Programming Interface, API) -Hardverből: megszakítás, hiba A felhasználók felülete: -Parancsnyelvi vagy grafikus kezelő felület (burok, GUI) -Segédprogramok készlete Nem a kernel része. API hívásokat használnak, tehát ráépülnek a kernel-re. API -Léteznek szabványok: A forrás szinten való átvihetőséget (portabilitás) biztosítják -klasszikus API-k: SVID, BSD -Posix szabvány Két ős UNIX: -a System V unix (AT&T), -BSD unix (Berkeley Software Distribution, Berkeley egyetem) Kidolgozta: Csatlós Balázs

-3-

UI Kezelő felületek típusai: -Lámpák, kapcsolók, dugaszoló táblák (csak múzeumban) -Job Control Card, vagy JCL script (ez is történelem) -Karakteres felhasználói felületek (UI): •

Parancssoros (pl. UNIX burok, VMS DCL, WIN cmd.exe, stb.)

•

Menü vezérelt (pl. IBM AS/400) (ez is történelem)

-Grafikus felhasználói felületek (GUI): •

1973: Xerox Alto az első GUI és „egér”

•

'80-as évek: Apple Macintosh, Microsoft Windows, X11 Window System

•

Napjainkban: Apple Aqua (Mac OS X), Windows NT, XP, VISTA, X11 (Xfree, X.Org) CDE, stb.

Parancssoros felület -Karakter alapú -Készenléti jelet ad -Parancssort dolgoz fel -Legsikeresebb parancsfeldolgozók: UNIX shell-ek Menü vezérelt felület: -Karakteres alapon menüpontokból választhatunk. Grafikus felhasználói felületek (GUI): Többféle van, de alapjaik közösek: -Ablak: bármely téglalap alakú része a képernyőnek -Asztal: a képernyő(kö)n megvalósuló munkaterület (ez is ablak) -Mutató: spec. beviteli eszközzel (egérrel) mozgatható kiválasztó -Ikon: négyzet alakú ablak, amely egy objektumot szimbolizál -Objektum: mappa, alkalmazás, állomány -Fókusz: billentyű leütések irányítását végzi, egyszerre csak egy objektum birtokolhatja -Parancs: kattintások, billentyű leütések C.) Implementációs struktúra • Monolitikus rendszer • Réteges struktúrák • Virtuális gépek • Kliens-szerver modell (mikrokernel) • Vegyes Monolitikus rendszer -Nincs strukturáltság -A kernel (mag): egy betölthető modulba összelinkelt, szolgáltató rutinok, megszakítást kiszolgáló rutinok, kivételes eseményt lekezelő rutinok összessége -A szolgáltató rutinok hívása: rendszerhívással (system call) -Futási mód váltás (user mód -kernel mód: trap) -Tipikus példa a korai UNIX-ok


-4-

Rétegezett stuktúra -A szolgáltató rutinok rétegekbe szervezettek. A rétegezés előnyei: Egy rétegben jól meghatározott, összetartozó funkciók Egy réteg elrejti az alatta lévő komponensek részleteit Magasabb absztrakciós szintű szolgáltatásokat biztosít: virtuális gépet -A rétegeket külön-külön betölthető fájlokba linkelikA betöltés akár dinamikusan is történhet (DLL) -Lehetséges: a rétegekhez egyre privilegizáltabb futási módok. -Tipikus példa: a The OS Virtuális gépek A Virtual Machine Monitor fut a puszta hardveren, ami több virtuális gépet emulál: pontos másolatait valódi gépeknek. Az emulált gépeken különböző operációs rendszerek futtathatók. A VM a hardver feletti réteg közvetlenül. Kliens-szerver modell -Igény a kisebb kernelre: Mikrokernel -Bizonyos rendszerszolgáltatások kiszolgálására önálló processzeket készítenek. -Ezek önállóan linkelhetők -Betöltődhetnek a rendszer egész életére (daemon processzek), vagy időlegesen -Futhatnak kernel-, vagy akár felhasználói módban -Processzek közti kommunikációval kérhetők a szolgáltatások. A kernel szinte csak a kommunikációt és az időosztást biztosítja. -Ebből fejlődtek ki a hálózati osztott rendszerek.

3.

Programtechnikai megvalósítások • • •

Szolgáltató eljárás, függvény kód; call hívással érhető el (trap) Kivételes eseményt, megszakítást kiszolgáló rutinok; elérésük: IT-vel, kivétellel Önálló processzek (felhasználói/rendszer processzek); elérhetők processz közti kommunikációs mechanizmusokkal. Ilyenek pl.: -swapper; a módosított lapok készletét kiíró processz; -ACP-k (Ancillary Control Process), melyek pl. a fájloknak az eszközökön való elhelyezéséért felelősek (a rekordformátumokért az RMS felelős!); -mentő/visszaállító processzek stb.

•

Statikusan betöltődő kernel rutinok (A rutinokat fordítják, összelinkelik egyetlen executable fájlba; boot során betöltődik és megkapja a vezérlést) -Call hívással elérhetőek (gyakran trap-pel) -IT-vel elérhetőek Dinamikusan betöltődő rutinok (regisztráció -load -inicializálás -szokásos hívások [call/IT] shutdown -regisztráció megszüntetés szekvenciák) Önálló processzek (user vagy kernel szinten)

• •

Hogyan juthat a vezérlés a kernelbe? • A felhasználói processzekből rendszerhívással (System Call). (Ez a programozónak RTL hívásnak tűnik.) • Hardverből megszakítással (Interrupt). Aszinkron. • Hardverből kivételes esemény (Exeption Condition) bekövetkezésével. Váratlan, de szinkron. (Némely esetben ezt nevezik trap-nek.)


-5-

4.

Események fogalma, fajtái és lekezelésük

Esemény fogalma (lásd rövidebbek) Események fajtái Egy processz szemszögéből -belső esemény, a processzorban fellépő esemény, kivétel (exception) -külső esemény, nem a processzortól érkezik, megszakítás (interrupt) Előállítója szerint -HW által generált és detektált (IT, errors), -SW által generált és detektált: SWIT, SW által generált exceptions, szűkebb értelmű események. Lekezelés: -Az esemény bekövetkezésekor az éppen futó processzről a vezérlés ideiglenesen átadódik egy másik instrukciófolyam (rutin, szál, processz) számára, amely kiszolgálja a bekövetkezett eseményt. -A kiszolgáló lefutása után pedig eseménytől függően vagy folytatódik megszakított processz végrehajtása a következő utasításától vagy máshova adódik a vezérlés. Megszakítások -Aszinkron. A futó processztől független. -Külső esemény. Pl. I/O művelet befejezésének visszajelzése egy perifériától, a periféria generálja. -Előállítója rendszerint a HW, de létezik SW is (SWIT). -Lekezelésük: 1. Aktuális instrukció még befejeződik 2. lekezelő lefut 3. soron következő instrukcióra tér vissza -Megszakításkérő azonosítása: megszakítás vektor Megszakítások kiszolgálása: -prioritás -megszakítás megszakítása: magasabb prioritású megszakítás megszakítja a megszakítás kiszolgálását -várakozó sor Megszakítások fajtái: -maszkolható: kiszolgálását ideiglenesen az OS letilthatja (pl. maszkolja az éppen kiszolgálásban levő IT-től alacsonyabb prioritású IT-ket) -nem maszkolható: nem lehet megakadályozni a kiszolgálását (pl. hardver hibák) Kivételek -Szinkron jellegűek, de váratlanok. -Lehetnek alacsony szintűek: pl. túlcsordulás, osztás hiba -Lehetnek magas szintűek: pl. laphiba. Az alacsony, magas szint megmondja minek szól a jelzés (instrukciónak, processznek), mi a kezelés szintje. -A lekezelés utáni folytatás a lekezelés eredményességétől függ (túlcsordulás vs laphiba). Kivételek vs megszakítások -Az IT aszinkron. Két instrukció között kiszolgálódnak. Az exception váratlan, de szinkron (az adott instrukcióhoz tartozik). Tipikus a Page Fault. -Az IT nem kapcsolódik a futó processzhez, kiszolgálása nem a futó processz javára. Az exception kiszolgálása “kiegészítése“ a processz instrukciófolyamának. -Az IT kiszolgálásnál prioritási szintek. Maszkolás. Kiszolgálásuk is megszakítható. HW-es a sorképzés. Az exceptionok kiszolgálását más exception nem szakíthatja meg Kidolgozta: Csatlós Balázs

-6-

-IT kiszolgálásra lehet közös rendszer verem. Exception kiszolgálására rendszerint processzenkénti kernel verem. Alkalmazás által kezelt események Hasonló, bár nem OS-hez kötődő fogalom. -Bekövetkezésüket a programozó eleve várja (de váratlanok időben). -Tipikus példa: GUI. Alkalmazás eseményvezérelt programozása. Magas szintűek: -Fejlesztő eszközök kellenek (RTL rutinok), -programozó maszkolhatja őket, -lekezelő rutinjait ő írja meg, -az eseménysorokat figyelheti. -Kezelésükhöz használhatja az IT-és kivétel-kezelési technikákat.

Processz Rövid fogalmak: 1.

Processz fogalom •

• • • •

2.

A folyamat (processz, taszk) egy végrehajtási példánya egy párhuzamosságot nem tartalmazó végrehajtható programnak. Processz végrehajtható program Pongyolán: a processz egy futó program. A processzhez dedikált PC tartozik, ami egyetlen helyre tud mutatni a program szövegben Párhuzamossági fok (PS: Paralell Stack): egy CPU-ra eső folyamatok száma

Processz tábla fogalma Process Table A kernel által kezelt, adott méretű táblázat (array of structure), melynek egy-egy bejegyzése egyegy process table entry vagy más néven processz vezérlő blokk (Process Control Block, PCB). -kiindulási pont, minden processnek van benne bejegyzése

3.

PCB fogalma

Process Table Entry (kernel címtarományban) (PCB) -a processz kreáláskor keletkezik, -nem kisöpörhető: rezidens, -"statikus" adatokat tartalmaz (melyek a processz létezését jelzik, de nem elegendőek a futásához): folyamat azonosítási információi (pid, ppid, pname) folyamat számlázási információi (CPU használat stb.), időkiosztással kapcsolatos infók erőforrás használati határértékek (limitek, quoták) mutatók a kontextus további részeire (kód és adatszegmenseire)

4.

Zombi processz

Zombi állapot: a process befejeződött, de még nem törlődött. A process befejeződése közben -Elengedi a foglalt erőforrásokat -Szignáloz a szülőjének, hogy exitál; • Ettől kezdve ő egy „zombi” process (már nem fut, de még létezik) • Még adminisztrációs munka van a törlődésig Kidolgozta: Csatlós Balázs

-7-

5.

Context switch

A Process Context Switch A CPU "kapcsolása" két processz között. Az egyik "elveszti" a CPU-t, a másik megkapja. Mindig két processz vesz részt benne, a) az egyiknél -wait (maga "mond le" a CPU-ról) vagy -preempt (elveszik tőle a CPU-t, bár még használná) állapotátmenet történik vagy -exit (befejeződik) b) a másiknál a schedule átmenet (megkapja a CPU-t).

6.

I/O lázas, CPU lázas szakasz

Egy process a CPU lázas időszakában a CPU-t kívánja használni. Egy process az I/O lázas szakaszában elsősorban az I/O csatornákat használná, ilyenkor a CPU szempontjából blokkolt.

7.

Kiéhezés (starvation)

Kiéhezés (starvation): Amikor egy process hosszú ideig nem jut hozzá egy igényelt erőforráshoz.

8.

Prioritás

A processzek rendelkeznek egy fontossági értékkel (prioritás). -statikus prioritás: a process élete során állandó (csak speciális esetekben használatos) -dinamikus prioritás: szükséges esetekben újra számolódik (időközönként, döntések előtt, sorokba bekerüléskor). Prioritás számító képlet van.

9.

Task, szál fogalmak

Fonál (szál, thread, lightweight process: LWP): a CPU használat alapegysége, egy szekvenciálisan futó instrukciósorozat, van dinamikus kontextusa (regiszterkészlete, verme). Osztozik más fonalakkal egy taszk statikus kontextusán (címkészlet: adat, kód; stb.). A fonalak valódi vagy pszeudó párhuzamosságban futhatnak. Taszk: van statikus kontextusa (címkészlete, erőforrásai: nyitott I/O-k, adminisztrációs információk, szignálok stb.). Fonál nélkül egy taszk passzív entitás. Egy taszk egyetlen fonállal: a klasszikus processz.

10.

IPC fogalma, célja

Inter Process Communication (IPC):Processzek közötti kommunikáció • Kommunikáció célja -információ csere -szinkronizáció • Maga a kommunikáció is igényelhet szinkronizációt


-8-

Hosszabbak: 1.

Processz kontextus fogalma, tartalma, osztályozása

A folyamat kontextus: adatstruktúrákba rendezve minden olyan információ, ami a folyamat futásához szükséges. Minden olyan információ, ami a rendszer számára szükséges, hogy a CPU-t a folyamatok között kapcsolja, a folyamatok szekvencialitásának illúzióját biztosítva. “Tartalom“ szerint: -a program kódszegmensei (instrukciók sorozatai), -a program adatszekciói (inicializált adatszekciók, konstans szekciók stb), -a processz veremtárai, -a processz menedzselési információi (azonosítási, állapotokat leíró, számlázási, hozzáférési stb. infók. Egy szemléletmód: -hardver kontextus: HW regiszterek, MMU regiszterek stb. (volatile context/environment) -szoftver kontextus Egy másik szemléletmód: -felhasználói szintű kontextus (User Level Address Space) -rendszer szintű kontextus (System Address Space)statikus részdinamikus rész (volatile context)

2.

• • •

Processz kontextus adatstruktúrái A processz tábla (Process Table) Processz tábla bejegyzés (Process Table Entry), másnéven Process Control Block Process Descriptor

Process Tábla (lásd rövidek) Process Table Entry (kernel címtarományban) (PCB) (lásd rövidek) Processz leíró (Process Descriptor) -a processz futtathatóvá válásakor keletkezik, -esetleg kisöpörhető: nem feltétlenül rezidens, -"dinamikus" adatokat tartalmaz (melyek a processz futásához is kellenek): volatile kontextus (regisztertartalmak: PC, PSW stb), ütemezési, számlázási, állapot infók, vermek pointerei stb.

3.

Processz kontroll. Processz születése, befejeződése, élete

Folyamatok vezérlése (Process Control, Process Management) A folyamatok -születnek, -élnek, versenyeznek erőforrásokért, osztoznak erőforrásokon, kommunikálnak, együttműködnek, szinkronizáció van köztük. -exitálnak.


-9-

Születés -Általában processzt csak processz kreálhat. Így: szülő-gyermek kapcsolat lehet közöttük. -Van ősszülő processz. -A létrehozás adminisztrációs munkával jár Kreáció műveletei -A kernel elkészíti a PT Entry-t, -memóriát biztosít a kód és adatszegmenseknek, inicializál; -elkészíti a PD-t, memóriát a vermeknek, -volatile kontextus készül (a PC értéket kap!), -futtatható állapotba kerül a processz. Kreáció rendszerhívásai -exec család adott futtatható file elindítása új processben pl. a.out ”alma” futtatása: execl(”a.out”, ”a.out”, ”alma”, (char *)0); vagy char *args[] = {”a.out”, ”alma”, (char *)0}; execv(”a.out”, args); -fork saját maga elindítása (elágaztatás) új processben -egyéb (create/run/load/system) fork(), join()(vagy wait()) rendszerhívások -A fork rendszerhívás: a processz instrukció folyamát úgy ágaztatja ketté, hogy az egyik ág a hívó processz instrukció folyama marad, a másik ág számára pedig gyermek processzt kreál -A párja a join(pid) (vagy wait()) rendszerhívás: a szülőben "összeolvasztja" a fork-kal szétválasztott ágakat: a szülő megvárja gyermekének terminálódását. Fork működése: Készít gyermek folyamatot, melynek kontextusa majdnem ugyanaz, mint a készítőjé (eltér pl. a pid, menedzselési infok) Lépései: -Ellenőrzi, készíthető-e a gyermek. -Bejegyzést készít a Process Table-ba a gyermek számára.Meghatározza a gyermek pid-jét. -A szülő kontextusának logikai másolatát elkészíti. (olyanná teszi az új processzt, mintha ugyanott tartana a futásban, mint készítője, pl. hardver kontextus-t is másolja) -Mindkét processzben visszatér:szülőben a gyermek pid-jével (negatív értékkel, ha hiba van), gyermekben 0 értékkel. Process befejeződés -normális termináció: exit/returnrendszerhívás család egyik tagjának meghívása, vagy a main függvény befejeződése -kierőszakolt termináció más processből: az abort()(vagy kill()) rendszerhívással (közvetetten szignállal), vagy közvetlenül a megfelelő szignálokkal • A process befejeződése közben -Elengedi a foglalt erőforrásokat -Szignáloz a szülőjének, hogy exitál; • Ettől kezdve ő egy „zombi” process (már nem fut, de még létezik) • Még adminisztrációs munka van a törlődésig A termináció adminisztrációs munkái: -Gondoskodni kell a gyermekeiről: vagy lelőni őket, vagy átadni más processzeknek, hogy azok legyenek a szülők, vagy megvárni míg befejeződnek; -Ki kell takarítani utána (pl. processz táblából) Kidolgozta: Csatlós Balázs

- 10 -

Process élete problémái -versenyeznek erőforrásokért, CPU-ért: ért: ütemezés, processz állapotok Egyéb erőforrásokért: erőforrás forrás kezelés, holtpont probléma -kommunikálnak: kommunikálnak: IPC mechanizmusok -együttműködnek: ködnek: szinkronizáció megoldása, versenyhelyzet (konkurencia) probléma

4.

Processz állapotok, állapotátmenetek, állapotok nyilvántartása

Az OS szempontjából nézve -több több processz (futó program) létezik a rendszerben, -ezeknek szükségük van a CPU-ra, ra, versengenek érte. Az alapján, hogy a cpu-ért ért versenyzésben éppen hogyan állnak különböző különböz állapotokat különböztetünk meg. Az állapotának megváltozása, átmenet egy másik állapotba. á Az OS-nek nek nyomon kell követnie a processz állapotokat, állapotváltozásokat, nyilván kell tartania az állapotokat, sőtt vezérelni kell, lebonyolítani kell az állapotátmeneteket. A "global system state" a létező processzek állapotainak összessége.

A legalapvetőbb állapotok: -Futó Futó állapot (running, current stb.). A processzé a CPU. -Futásra Futásra kész állapot (ready, computable stb.). A processz számára minden erőforrás erőforrás rendelkezésre áll, áll kivéve a CPU-t. t. A process tudna tovább futni, ha övé lenne a cpu. -Blokkolt Blokkolt állapot (blocked, sleeping stb.) A processz valamilyen egyéb erőforrást er forrást igényel még. A process nem tud tovább futni, amíg meg nem kapja ezt az erőforrást. er A wait (sleep, request) állapotátmenetet maga a processz "okozza", azzal, hogy bejelenti igényét valamilyen -a CPU-tól különböző -erőforrásra forrásra (pl. bufferre, diszk blokkra, eseményre stb.) és ez nem áll azonnal a rendelkezésére. Ezért, hogy ne foglalja feleslegesen a CPU-t CPU blokkolódik. A signal (assign) állapotátmenetet egy szignál érkezése okozza, amely jelzi, hogy megszűnt megsz a blokkolódást kiváltó ok. Rendszerint egy IT kezelő (handler) rutin küldi a jelzést, hogy már rendelkezésre áll a kívánt erőforrás. Ilyenkor blokkolódásból nem juthat közvetlenül futó állapotba hiszen a cpu valószínűleg valószín foglalt. A elvétel (preempt) és a kioszt (schedule/run) állapotátmeneteket az ütemező ütemez (scheduler) okozza, "hajtja végre". Zombi állapot: a process befejeződött, ődött, de még nem törlődött. törl Nem létező állapot: a process nem létezik Felfüggesztett állapotok: a process időlegesen idő ki van zárva a cpu-ért ért való versengésből versengésb Exit állapotátmenet: a process terminálódott (befejeződött (befejez vagy terminálták) Kidolgozta: Csatlós Balázs

- 11 -

Delete állapotátmenet: az opr. elvégezte a szükséges adminisztrációs munkát, a process törlődött, megszünt. Create állapotátmenet: a process létrejön, az opr. elvégezte a szükséges adminisztrációs munkát. Nem kerül azonnal futó állapotba, bár elég nagy esélye lesz, hogy ő legyen a következő futó, lásd ütemezés. Suspend, Resume állapotátmenet: a középtávú ütemező feladata, lásd ütemezés Process állapotok nyilvántartása: -A kontextusban (rendszerint a PCB-ben) rögzítettek az állapotok, de -láncolt lista adatszerkezeteken, sorokon (queues) is. Pl. külön láncolt listán vannak a Ready processzek, külön láncolt listán vannak az egyes erőforrásra várók. Ennek előnye, hogy láncolt listát könnyebb, gyorsabb kezelnie az ütemezőnek, illetve az erőforrás kezelő rutinoknak, mintha mindig végig kellene néznie az összes PCB-t. Ennek hátránya, hogy állapot változáskor több helyen kell módosítani.

5. Processz ütemezés szintjei. Elvárások az ütemezővel szemben. Ellentmondások az elvárások között. Ütemezés (scheduling), mint az erőforrás kezelés egyik lehetséges módja. (A többi lehetséges megoldást majd az erőforrás kezelés témakörnél) -Lényege: az erőforrás használatát teljes egészében egy operációs rendszer komponens vezérli: az ütemező (scheduler). Az ütemező felelős az erőforrás kiosztásáért, elvételéért, nyilvántartásért. (Döntés, végrehajtás.) -Költségigényes megoldás (teljesítmény) -Az operációs rendszer CPU erőforrás esetén ezt a megoldást használja. Ütemezési szintek -Long-term-scheduling (hosszútávú):A create állapotátmenetért felelős. JOB ütemezés: JOB/taszk pool-ból melyiket válasszuk ki futásra. Használata csak a régi időkben. (Mai rendszerekben ha a rendszer annyira leterhelt, hogy nem képes elindítani egy processzt, akkor visszautasítja.) -Medium-term-scheduling (középtávú):A suspend, resume állapotátmenetekért felelős. Milyen erőforrás használat (és erőforrás terheltség) esetén érdemes a processzt felfüggeszteni, illetve engedélyezni. -Short-term-scheduling (rövidtávú)A preemt, schedule állapotátmenetekért felelős. Mikor vegye el a cpu-t a processtől, illetve a futásra kész processzek közül melyik kapja a CPU-t. Elvárások a process ütemezéssel szemben -Pártatlanság: minden processz (taszk) korrekt módon, de nem feltétlenül egyenrangúan kapja meg a CPU-t. (Lehetnek fontosabb processzek, amelyeknek több jár, de minden processz kell hogy kapjon cpu időt.) -Hatékonyság: a CPU lehetőleg legnagyobb százalékban legyen kihasználva (Ne legyen felesleges üresjárata) -Válaszidő: elfogadható legyen. (interaktív felhasználó számára egy parancs (felhasználói esemény) kiadása és a válaszakció beindulása között eltelt idő elfogadhatóan rövid legyen) -Fordulási idő: elfogadható legyen (kötegelt munkák indulása és befejeződése között eltelt idő) Kidolgozta: Csatlós Balázs

- 12 -

-Teljesítmény: időegységre eső JOB, taszk, processz feldolgozás jó legyen (más, mint a CPU kihasználás!) (A teljesítménybe nem számít bele az opr. saját munkája: pl. döntési algoritmusok végrehajtási munkája, context switch végrehajtása, stb., tehát ezek rontják a teljesítményt.) Ellentmondások, tények az elvárásokkal kapcsolatban -Az alacsony válaszidő gyakori Context Switch-et igényel -A Context Switch előtt, alatt az ütemező dolgozik (döntési algoritmusok, tényleges CS) -A több CS, rosszabb teljesítmény -Alacsony válaszidő vs. kis fordulási idő-valós idejű munkák ütemezésénél plusz elvárás:garantált válaszidő: a válaszidő nem lehet nagyobb egy bizonyos értéknél

6.

Ütemező döntési stratégiái. Összefüggés az állapotokkal. Ütemező feladatai.


- 13 -

Ütemező feladatai: 1. Döntés a beavatkozásról 2. Döntés a kiosztásról 3. Context Switch elvégzése Az 1. , 2. tartalmaz egy döntési algoritmust és a hozzá szükséges nyilvántartások kezelését.

7. Ütemező beavatkozásának technikai alapjai. Beavatkozási algoritmusok fajtái, jellemzésük. Beavatkozás technikai alapja: Az óra eszköz periódikusan megszakítást generál. Ez lehetőséget ad, hogy lefusson egy „döntési algoritmus”. Beavatkozást nem ismerő rendszerekben nem teljesülhet az összes elvárás. Beavatkozás (preempt) lehetséges döntési algoritmusai 1. Időszeleten alapuló (időosztásos, time-sharing)A process csak meghatározott időszeletnyit futhat egyhuzamban. Ha ez időn belül nem blokkolódik, akkor az időszelet lejártával, beavatkozás. 2. Prioritáson alapulóA processzek rendelkeznek egy fontossági értékkel (prioritás). Ha a „ready” állapotban levő processzek közül egynek „magasabb” lesz a prioritása, mint a „running” processz prioritása, beavatkozás. 3. Vegyes Lehetséges döntési algoritmusok összevetése: -A pusztán prioritáson alapuló algoritmus esetén a statikus prioritás szóba sem jöhet (kiéhezés veszély). Dinamikus prioritásnál is jól behangolt, cpu időt is figyelembe vevő prioritás képletet kell használni (különben szintén kiéhezés veszély). -Pusztán időosztáson alapuló algoritmus nagyon kis költségű, minden elvárásnak megfelel, de hátrány lehet, hogy a processzek prioritását csak a kiosztásnál tudjuk figyelembe venni.

8. Ütemező kiosztási algoritmusainak feladata. FCFS, SJF, RR algoritmusok ismertetése. Kiosztás (schedule) -Ha bármilyen okból felszabadult a cpu valamelyik ready állapotúnak meg kell kapnia. -Mikor szabadul fel a cpu: wait, exit, preempt -az algoritmus költsége meghatározó a teljesítmény szempontjából, tehát ez is szempont 1. FCFS(First come – First served) -A ready állapotban levő processzek a beérkezési sorrendjük szerint kapnak CPU-t. -A régi nem beavatkozó jellegű ütemezőknél volt használatos (illetve hosszú távú ütemezéseknél), a beavatkozással együtt már más a neve -Egyszerű a megvalósítás. (Egy sor.) -Mivel nincs beavatkozás kialakulhat a convoy effect: korábban érkezett CPU lázas szakaszú processz lefogja a CPU-t. Nem garantált a megfelelő fordulási idő, válaszidő.


- 14 -

2. SJF (Shortest Job First) -A ready állapotúak közül azt választja ki, amelyiknek várhatólag a legkisebb lesz a futási ideje. Matematikailag bizonyítható, hogy az átlagos fordulási idő ennél az algoritmusnál lenne a legkisebb. De. Processzek esetén az opr. nem tudja megbecsülni. Régi készrefuttató rendszerekben a programozónak kellett várható futási időt megadni. -Más feladatokra pl. printer spooling kiszolgálásra később is használták. -Idősorozatokkal jellemezhető feladatoknál az „aging” algoritmust használta becslésre. 3. Round-Robin -FCFS + időszeletes beavatkozás -Tehát a ready processzek egy soron nyilvántartottak és mindig a legelső kapja meg a cpu-t és az újonnan érkezettek a sor végére kerülnek (mint az FCFS-nél). De ha egy process megkapja a cpu-t akkor az addig futhat amíg le nem jár az időszelet és utána beavatkozás. Tehát vagy még az időszeleten belül wait, vagy időszelet lejártával preempt. -Előnye: egyszerű, kis költségű, garantáltan szóhoz jut minden processz. -Hátránya: nem vesz figyelembe fontosságot. (!!!) -Érdekesség: a válaszidő csökkenthető, ha kisebb időszeletet használ az operációs rendszer, dekisebb időszelet -> több contect switch -> romló teljesítmény -Mai napig is gyakran használt algoritmus, de csak azonos prioritású processzek közötti döntésre.

9.

Klasszikus algoritmus működése egy konkrét számpéldával.


- 15 -

10. Ütemező kiosztási algoritmusok: Ígéret vezérelt, sorsjegyes algoritmus ismertetése. 4. Igéretvezérelt (Policy Driven) -Elv: n számú processz esetén 1/n-ed részét kapja egy processz a CPU-nak. -Megvalósítás: Mérni kell az életIdő-t (a rendszerben eddig eltöltött idejét), cpuIdő-t (eddig felhasznált CPU időt), továbbá a jogosultságiIdő = életIdő / n; prioritás = jogosultságiIdő / cpuIdő. -Hátránya: Nem vesz figyelembe fontosságot. -Az igéretvezérelt időkiosztás speciális esete a valós idejű (Real Time) időkiosztás. 5. Sorsjegyes -A processzek sorsjegyeket kapnak, döntéskor sorshúzás, a nyertesé a cpu. -Figyelembe vehető a fontosság: több sorsjegyet kap, nagyobb esélye van. -Kisebb fontosságú processznek is van esélye. -Csak „hosszabb” távon érvényesül a fontosság -Process átadhat sorsjegyet, pl gyereknek

11. Ütemező kiosztási algoritmusok: Általános prioritásos, többszintes prioritás soros ismertetése. 6. Általános prioritásos -A ready processzek közül a legmagasabb prioritású kapja meg a cpu-t. -prioritásról már tudjuk: statikus, dinamikus -némelyik algoritmusnál az alacsonyabb prioritás szám jelent magasabb prioritást -technikai értelemben a korábbi algoritmusok is felfoghatók prioritásos algoritmusnak -a helyesen megválasztott prioritás számító képlettől függ, hogy teljesülnek-e az elvárások -A prioritás függhet: eddigi CPU használati idejétől (legfontosabb), a processz memóriaigényétől, erőforrás használati szokásaitól, a várható összes CPU használati idejétől, a rendszerben eddig eltöltött idejétől, külső prioritás értéktől,időszerűségétől (timeliness), a rendszer terhelésétől. 7. Többszintes prioritás-sorokon alapuló (Multilevel Queue Scheduling és Multilevel Feedback Queue Scheduling) -A prioritás számító képlet véges számú diszkrét értéket ad (pl. 1-15 közötti egész a prioritás). Ezeket prioritás szinteknek nevezzük. -Több azonos prioritású processz is létezhet (azonos szinten vannak), emiatt másodlagos döntési algoritmus szükséges. (Az elsődleges most is a prioritás, tehát magasabb prioritású process hamarabb kap cpu időt) A másodlagos algoritmus lehet szintenként különböző is, de többnyire egy egyszerű (kis költségű) algoritmus (pl. FCFS, Round-Robin) -A prioritás most is dinamikus kell legyen. Kell alap prioritás Kell csökkenni tudni a prioritásnak (többnyire a cpu idő növekedésével arányosan.) Kell növekedni tudni a prioritásnak (feedback)


- 16 -

12. Ütemező kiosztási algoritmusok: VAX/VMS, UNIX kiosztási algoritmusok ismertetése. 8. VAX/VMS ütemezési algoritmusa -Multilevel feedback jellegű,, alkalmas real time-ra time is. -32 32 prioritási szint. Nagyobb szám: nagyobb prioritás. 16-32: a valós idejű processzek számára. Nem dinamikus! 0-15: 15: reguláris processzeknek, dinamikusan számítódik. Prioritás számítás: -A processz bázis-prioritása: prioritása: minimális prioritása. -Rendszerhívásokhoz Rendszerhívásokhoz rögzített prioritás növekmény: Mikor a processz futásra késszé válik (signal ( állapotátmenettel), a növekmény hozzáadódik a prioritáshoz, és a megfelelő megfelel sorra kerül processz. -Scheduled Scheduled processz prioritása egy szinttel csökken (határ a bázis-prioritás). bázis prioritás). Ha elveszik tőle t a CPU-t, erre az új sorra kerül. -Sokáig várakozókat eggyel följebb emelik (no starvation). -A A scheduler a legmagasabb prioritás sor elejéről elejér választ. 9. UNIX időkiosztás -Multilevel feedback jellegű -A processzeknek user-mode mode vagy kernel-mode kernel prioritásértéke lehet. A user-mode mode prioritás szintekre sorolódnak nak a felhasználói processzek, ezek a szintek dinamikusak és van beavatkozás.A kernel-mode kernel prioritás szintekre sorolódnak a rendszer funkciók, ezeken a szinteken statikus a prioritás. Ezek közül vannak szintek amelyekre nincs beavatkozás. (A statikus prioritás prioritás és a nem beavatkozás nem okoz problémát hiszen ezek a funkciók pontosan ismert működésűek, m ek, ismerten rövidek). Prioritás számítás (kisebb érték jelenti a nagyobb prioritást!): p-usrpri=PUSER+p-cpu cpu /const2 + const3 * p-nice;(Rendszerint p const2=const3=2;). ;). -A p-usrpri usrpri a küszöb érték alá, egy beállított érték fölé nem mehet. -A A PUSER a processz bázisprioritása, külső küls prioritás. -A p-nice nice a nice() rendszerhívással ( felhasználói kontrollt lehetővé lehet tevő)) beállított érték. -A p-cpu mező a futó processznél a CPU használattal arányosan nő. n -A p-cpu mezőtt quantumonkként öregbítik (aging): p-cpu p = p-cpu cpu / const1; (rendszerint const1 = 2)


- 17 -

13.

Taszk, fonál, fonálkezelés

Taszk, fonál fogalma (lásd rövidek) Fonál kezelés 1. Rendszer szintű (Kernel Level Threading) -Ezeket hívják (gyakran) könnyűsúlyú súlyú processzeknek -A A kernel „ismeri” a fonalakat, allokál nekik CPU-t, CPU ütemezi őket, ket, nyilvántartja állapotukat stb. -A A fonál kontrollhoz (kreálás, terminálás, stb.) rendszerhívások biztosítottak -Osztoznak a taszk kontextusán, erőforrásain őforrásain -Viszonylag drága a menedzselésük -Felhasználói Felhasználói taszkok ilyen fonalai felhasználói módban futnak 2. Felhasználói szintű (User Level Threading) -A A kernelnek nincs is tudomása a fonalakról. -A fejlesztő eszközhöz adott RTL rutinokkal rutinok ütemezzük őket. -Az Az RTL rutinok végzik a fonál kontrollt (kreáció, megszüntetés, stb). -Állapotukat Állapotukat is csak a taszk tartja nyilván. -Osztoznak a taszk kontextusán, erőforrásain őforrásain forrásain (a taszkhoz allokált processzoron is osztoznak, azaz csak pszeudó párhuzamosságban osságban futhatnak). -Menedzselésük Menedzselésük olcsó (nem kellenek rendszer-hívások, rendszer CS) -Természetesen Természetesen felhasználói módban futnak 3. Vegyes: a fonál támogatás funkcionalitása megoszlik


- 18 -

14.

Kommunikáció fajtái.

Kommunikáció fajtái -direkt kommunikáció, indirekt kommunikáció -egy-, kétirányú kommunikáció (aszimmetrikus, szimmetrikus) -zéró, korlátozott kapacitású, végtelen kapacitású pufferelt -fix üzenethosszúságú, változó üzenethosszúságú -szinkron, aszinkron Direkt kommunikáció -A direkt kommunikáció esetén a kommunikáló processzeknek ismerniük kell egymást. -Többnyire két processz közötti kommunikáció. -Műveletei: küldés, fogadás (send, receive) (közben kiépül egy egy-vagy kétirányú kapcsolat) -pl. signál Indirekt kommunikáció -Az indirekt kommunikáció esetén a processzeknek egy közvetítő entitást kell ismerniük (üzenetsor, postaláda, stb.). -A kommunikációban résztvevőknek a) létre kell hozni az entitást vagy csatlakozni hozzá, b) információ küldés, fogadás,

c) elpusztítani az entitást. -lehetnek különböző hozzáféréseik a kommunikáló processzeknek -pl. file-okon keresztüli komm, osztott mem., üzenetsor -Az entitás kötődhet a) processzhez: az egyik kommunikáló processz hozza létre, pusztítja el (processz megszünésével, megszűnik) b) OS-hez: nem a kommunikáló processzek hozzák létre, szüntetik meg Egy-, kétirányú kommunikáció (aszimmetrikus, szimmetrikus) -Egyirányú: az egyik csak ad a másik csak vesz -Kétirányú: mindkét fél küld is fogad is. Zéró, korlátozott kapacitású, végtelen kapacitású pufferelt -Zéró kapacitás (nincs puffer): a kapcsolatnak nincs puffere, azaz a küldéssel egyidejűleg fogadni kell (szinkronizációt igényel) -Van puffer: A küldés elválik a fogadástól. A küldéskor egy pufferbe kerül az információ. A fogadó innen veszik ki az elsőt.Korlátozott kapacitású puffer esetén csak akkor kell várakozni a küldőnek, ha betelt a puffer vagy a fogadónak ha üres a puffer.Végtelen kapacitású puffer esetén csak akkor kell várakozni a fogadónak, ha üres a puffer. Szinkron, aszinkron -Blokkolásos, nem blokkolásos (szinkron, aszinkron) küldés: Küldő processz megvárja-e, hogy a fogadó megkapja az üzenetet. -Blokkolásos, nem blokkolásos (szinkron, aszinkron) fogadás: Fogadó processz vár-e kiadott receive() híváson. -Ha mind a küldés, mind a fogadás blokkolásos, akkor a kommunikáció szinkron. Ha valamelyik (vagy mindkettő) nem blokkolásos, akkor aszinkron.


- 19 -

15.

IPC mechanizmusok jellemzése.

IPC mechanizmusok felsorolása: -Fájlokon keresztüli kommunikáció. -Az “environment“-en keresztüli komm. -Csővezeték (pipe) név nélküli, nevezett csövek. -A klasszikus message queue rendszer. -Osztott memórián keresztüli kommunikáció. -Szignálozáson keresztüli kommunikáció. -Szemaforok, mint kommunikációs mechanizmusok. -A BSD socket kommunikáció. -Remote Procedure Call. Fájlokon keresztüli kommunikáció -Több process ugyanabba a file-ba ír, file-ból olvas. -Lassú, nagy átvitt információtartalmú. -Indirekt, OS kötődésű, szimmetrikus, pufferelt, változó üzenethosszos kommunikáció. -Megvalósítás: a szokásos I/O rendszerhívásokkal. Az “environment“-en keresztüli komm. -Az operációs rendszer környezeti változóiba írás, illetve azok kiolvasása -Gyors, kis információtartalom mehet át. -Indirekt, zéró pufferelt, változó üzenethosszos, aszimetrikus. -Megvalósítás: A burok környezeti változóit a processzek lekérdezhetik (getenv() rendszerhívás). Csővezeték (pipe) -Egy létrehozott csőbe ír és a fogadó onnan olvas. A cső fifo jellegű és amit kiolvasnak az törlődik. (lehetséges két csővel szimmetrikus kapcsolat is) -Név nélküli és nevesített cső mechanizmusok. -Nevesített csövek megvalósítása file-okon keresztüli kommunikáció: lassú sebességű, nagy átvitt adatmennyiség, indirekt. -Névtelen csövek megvalósítása rendszerfüggő. Lehet file-okon keresztüli, lehet osztott memórián vagy egyéb módon. Ettől függően más és más a jellemzői. -Aszimmetrikus, változó üzenethosszos kommunikáció. Üzenet soros kommunikáció -Az egyik processz üzenetsor készít, más processzek kapcsolódnak rá, és a sorba betehető, kivehető információ. -Az üzenetsor processzektől függetlenül létezik, ha készült. -Tulajdonossági és hozzáférési jellemzőiket a fájl tulajdonossági, hozzáférési kategóriák segítségével szabályozzák -Gyors, közepes átvihető információmennyiség. -Indirekt, OS kötődésű, többirányú, végtelen puffer kapacitású, változó üzenethosszú. Osztott memórián keresztüli kommunikáció -A processzek egy közös memória területen keresztül kommunikálnak. -gyors, nagy átvihető információ mennyiség -Indirekt, szimmetrikus, zéró pufferelt -Megvalósítás: rendszerhívásokkal -Készíthetünk(asszociálhatunk) adott méretű osztott memória szegmenst. Ekkor hozzáférések állíthatók. -Ezt leképezzük a processz címtartományára (megadjuk, milyen címeken és milyen típusként lássa a processz a szegmens rekeszeit). (Pongyolán: mintha alloc-cal képeznénk le valamit, de itt nem a heap-ból, hanem az osztott memóriából!) Leképzés nélkül használhatatlan a szegmens: nem éri el a processz! -Használjuk az adott címekre való hivatkozásokkal a szegmens rekeszeit. -Végül lekapcsoljuk a címtartományt, esetleg töröljük a szegmenst. Kidolgozta: Csatlós Balázs

- 20 -

Szignálozáson keresztüli kommunikáció -Információ hivatkozás küldés. Az operációs rendszer komponensei között gyakori. Kivételes esemény (exception) jelzésére is használatos. -Gyors, nagyon kis információátvitellel. -Direkt, egyirányú, zéró pufferelt, fix hosszos, aszinkron. Szemaforok, mint kommunikációs mechanizmusok -A szinkronizáció alapvető eszköze. Két állapotú, vagy több állapotú szemafor. (hasonló a vonatokat vezérlő szemafor elgondoláshoz) -gyors, nagyon kicsi átvitt információ mennyiség -Indirekt, kétirányú, zéró pufferelt, fix hosszos. BSD socket kommunikáció, Remote Procedure Call -Elsősorban hálózati kommunikációs mechanizmusok, de szélső esetben egy hoston is!

Erőforrás kezelés Rövid fogalmak: 1.

Spooling

Nem megosztható erőforrások visszavezetése megosztható erőforrásokra.

2.

Atomi instrukció.

A szemaforon két atomi (! azaz nem megszakítható) operáció végezhető: P és V primitív vagy más néven Down és UP művelet.

3.

Tevékeny várakozás

A processzek várakozás közben foglalják a CPU-t.

4.

Tsl instrukció

Egy processzor utasítás, amely egy megszakíthatatlan lépésben leellenőrzi a zárolásváltozót és beállítja.

5.

Java synchronized utasítása

Magas szintű kölcsönös kizárást és szinkronizációt megvalósító mechanizmus Java nyelvi implementációja.

synchronized (refváltozó) { kritikus szakasz }

Hosszabbak: 1.

Erőforrások fajtái, kezelésük. Spooling technika.

A processzek életük során nem csak a CPU erőforrásért vetélkednek, hanem más erőforrásokért is. Erőforrások fajtái -megosztható: egy időben több processz is használhatja vagy bármikor elvehető a használótól és átadható más processznek majd gond nélkül vissza is adható -nem megoszható: egy időben csak egy processz használhatja és nem vehető el tőle amíg használja Nem megosztható erőforrásokra kezelés Kidolgozta: Csatlós Balázs

- 21 -

-Visszavezetni megosztható erőforrásra forrásra a használatot: Spooling. Pl. nyomtatásnál. Nem használható bármilyen erőforrásfajtánál. -biztosítani kell a kölcsönös kizárást Spooling: -A A nem megosztható eszköz kezelését kizárólag a spooler végzi, amely egy opr. processz. -Léteznek eszköz foglalás, oglalás, használat, elengedés rendszerhívások, de ezek a hívások nem az eszközkezelőhöz, hanem a spooler-hez hez futnak be. -A A spooler az egyes processzek kívánságait file-okba file okba menti. (A winchester megosztható eszköz) -A file-kba kba letárolt adatokkal dolgozva egyedül e a spooler kezeli az eszközt. A processz nem tud róla, hogy nem közvetlenül kezeli az eszközt.

2.

Kölcsönös kizárás fogalma, problémái.

Kölcsönös kizárás: A közös erőforrásokért forrásokért vetélkedő vetélked processzek közül egy és csakis egy kapja meg a jogot az erőforrás forrás használatára, ennek módszerei, eszközei, technikái. Kölcsönös kizárással kapcsolatos problémák -megvalósítás megvalósítás problémája:Hogyan lehet olyan megoldást készíteni, amely nem csak az operációs rendszer erőforrásaira forrásaira használható, hanem tetszőleges tetsző (pl. programozó által definiált) szoftvererőforrásra szoftverer is. Konkurencia probléma. -több kölcsönös kizárást igénylő erőforrás őforrás használatából felmerülő felmerül probléma: holtpont Konkurencia probléma Közösen használt erőforrások források esetén jelentkezik. Jelensége, hogy egy processz processz végrehajtási menete, eredménye függ a processz ütemezésétől. ütemezését l. A processz szempontjából tehát a véletlentől véletlent függ.

3.

Konkurencia probléma ismertetése részletesen.

Egy valós példa a konkurencia problémára: -Processzek Processzek a nyomtatandó állományok nevét kimeneti munkaterületre (spooler directory) helyezik. -A printer daemon (szolgáltató) ebből ől veszi az anyagokat és nyomtat. -Legyen Legyen spooler directory n számú fiókkal. Legyen az out változó a nyomtatandó fájl nevére nev mutató. Pillanatnyilag out=4. Legyen az in közös változó a következő következ szabad fiókra mutató. Pillanatnyilag in=7. Tegyük fel van két processz A és B. 1. „A” veszi in-t, t, megjegyzi, de mielőtt miel beírná a fájl nevét, a CPU-tt megkapja „B”. 2. „B” is veszi in-t (pillanatnyilag 7), beírja a 7. fiókba a saját fájlja nevét, növeli in-t. in Folytatja saját dolgait. 3. „A” visszakapja a CPU-t: CPU felülírja a 7. fiókot. Növeli in-tt (ez már 9 lesz!). Következmény: A 7. fiókból a B bejegyzése elvész: az outputja sohasem jelenik meg a nyomtatón. A 8. fiók tartalma meghatározatlan lesz. Ha amíg „A” használta in-t in „B” nem használhatta volna nem lett volna probléma. Tanulság: Kidolgozta: Csatlós Balázs

- 22 -

-A közösen használt erőforrás: in Az in használatát kölcsönös kizárással védeni kell. -Olyan Olyan kölcsönös kizárási mechanizmus kell, amelyet a programozó használhat.

4. Kölcsönös kizárás megvalósításával kapcsolatos fogalmak, megvalósítással szembeni követelmények. -Kritikus szakasz: A folyamaton belüli kódrész, melyen belül a kölcsönös kizárást meg kell valósítani. (Ahol a közös változót az „in”-t használjuk.) -Belépési szakasz: A folyamaton belül az a kódrész, ahol kéri az engedélyt a kritikus szakaszba való belépésre. -Kilépési szakasz: Az a kódrész, ahol elhagyja a processz a kritikus szakaszt. Kölcsönös kizárás megvalósításával szembeni követelmények: 1. Biztonsági (safety) kívánalom: Ha egy processz kritikus szakaszában fut, más processz ne léphessen be kritikus szakaszába. 2. Előrehaladási ehaladá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. Csak a belépési szakaszukban levő lev processzek vegyenek részt abban a döntésben, hogy melyik fog végül belépni. Ráadásul ul ez a döntés nem halasztható végtelenségig. 3. Korlátozott várakozási kívánalom: ha egy processz bejelentette igényét a belépésre, de még nem léphet be, korlátozzuk ésszerűen en 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 megelőzi. megel 4. Hardver és platform kívánalom: ne legyenek előfeltételeink el a hardverre (sem a CPU-kk típusára, számára, sem a sebességükre), az operációs rendszer ütemezésére stb. stb 5. Teljesítmény kívánalom: A processzek várakozás közben ne foglalják a CPU-t, CPU t, azaz ne legyen tevékeny várakozás.

5.

Kölcsönös kizárás megvalósításai: Peterson algoritmus, Tsl instrukció.

Peterson algoritmus Egymás váltogatása az érdekeltség figyelembevételével. figyelembevétel -osztott osztott turn, erd[N]={false,false,…}, de mégsem probléma -Sérül az 5. szabály

Tsl instrukció -Egy processzor utasítás, amely egy megszakíthatatlan lépésben leellenőrzi őrzi a zárolásváltozót és beállítja. -Sérül a 4. követelmény


- 23 -

6. Szemaforok fogalma, működési elve, várakoztatás megvalósításai, atomiság megvalósítása. Szemafor

-Dijkstra (1965) -Csak elvi alapokat adta, a megvalósításról nem rendelkezett -Alkalmas szinkronizáció megvalósítására is (lásd később) -Működési elve: A szemafor pozitív egészt tartalmazó közös változó és egy várakozási sor. A szemaforon két atomi (! azaz nem megszakítható) operáció végezhető: P és V primitív vagy más néven Down és UP művelet DOWN (P: Passeren): Ha a változó nagyobb, mint nulla a változó értékét csökkenti eggyel, ha nulla akkor a processz a várakozó sorba kerül (blokkolódik). Pszeudó kóddal:

UP (V: Vrijgeven [vrejhéfen]) A változó értéke növekszik eggyel és ha nulla volt akkor jelez egy blokkolódott processznek, hogy felébredhet. Várakozás lehetséges megvalósításai: 1. A várakozás tevékeny várakozás, ebből ébresztés signállal (spinlock szemafor). Az 5. követelmény sérülhet. Előnye lehet, hogy nincs kontextus váltás (Alkalmazás, ha a CS költsége nagyobb, mint a várakozásé) 2. A várakozás blokkolással (wait állapotátmenet), az ébresztés szignállal (signál állapotátmenet) (egy várakozót vagy az összeset?)Minden követelmény kielégít (legalábbis a 3. követelmény kielégítését átruházza a scheduler-re). Atomiság lehetséges megvalósításai: Bármelyik korábbi módszerrel. Lehetséges a megszakítás letiltással is, hisz ez opr. kód!

7.

Szinkronizációs problémák. Termelő-fogyasztó probléma ismertetése.

Klasszikus szinkronizációs problémák -Termelő, fogyasztó probléma -Alvó borbély esete -Író, olvasó probléma -Útszűkület probléma Termelő-fogyasztó (Producer-Consumer) probléma -Vannak termelő folyamatok, melyek terméket (item, message) állítanak elő és behelyezik egy raktárba. -Vannak fogyasztó folyamatok, melyek terméket kiveszik a raktárból és felhasználják. -Van egy termék-raktár. A raktárral kapcsolatban : a) korlátozás kell a raktár használatára, azaz egy időben csak egy folyamat, akár termelő, akár fogyasztó, használhatja a raktárt. Ez kölcsönös kizárási probléma. Megoldása bináris szemaforral.


- 24 -

b) korlátozás kell a raktár kezelésére, azaz teli raktárba termelő nem rakodhat, valamint üresből fogyasztó nem fogyaszthat. Ez szinkronizációs probléma. A megoldása lehet pl. szemaforral. Egy szemafor az üresség kezelésére és egy a teliség kezelésére.

8. Holtpont fogalma, keletkezése, klasszikus „Ebédlő filozófusok esete”, egyszerű két erőforrásos példa. Holtpont kialakulásának feltételei. Fogalma általánosan: Egy rendszer folyamatainak egy H részhalmaza holtponton van, ha a H halmazba tartozó valamennyi folyamat olyan eseményre vár, amelyet csak egy másik, H halmazbeli folyamat tudna előidézni. Következmény processzek esetén: a holtpontban levő processzek nem tudnak folytatódni. Az általuk foglalt erőforrások nem tudnak felszabadulni. Az ezeket igénylő processzek szintén holtpontba kerülnek. Keletkezése: Kialakulhat erőforrásért vetélkedés közben, szinkronizáció közben, eseményekre várakozáskor, vagyis olyan esetekben amikor kölcsönös kizárást használunk.

A holtpont kialakulásának szükséges feltételei: 1. Kölcsönös kizárás: legyenek olyan erőforrások a rendszerben, amelyeket a folyamatok csak kizárólagosan használhatnak. 2. Foglalva várakozás: legyen olyan folyamat, amelyik lefoglalva tart erőforrásokat, miközben más erőforrásokra várakozik. 3. Nincs erőszakos erőforrás-elvétel a rendszerben, azaz minden folyamat addig birtokolja a megkapott erőforrásokat, amíg saját jószántából fel nem szabadítja azokat. 4. Körkörös várakozás: a rendszerben lévő folyamatok közül létezik egy olyan {P0, P1, ... Pn} sorozat, amelyben P0 egy P1 által lefoglalva tartott erőforrásra vár, Pi egy Pi+1-re, végül Pn pedig P0-ra vár.

9.

Holtpont kezelése.

Kezelési fajták: 1. Strucc megoldás 2. Detektálás, megszüntetés 3. Megelőzés Strucc politika -Nem törődünk a problémával, hiszen igen kicsi az előfordulási esélye. -Előnye: 0 költségigény-Hátránya: ha mégis előfordul, akkor előbb utóbb „lefagy” a gép -Kritikus rendszerekben nem alkalmazható Detektálás és megszüntetés -Detektálás mikor: A minél hamarabbi detektálás fontos, mert majd láthatjuk, hogy a holtpontban levő processzeket valószínűleg fel kell áldozni, és az idővel növekszik a holtpontban levők száma. a) Rendszeres időközönként: Gyakran: hamarabb detektál, nagyobb költségigény Kidolgozta: Csatlós Balázs

- 25 -

Rikán: később detektál, kisebb költségigény b) Eseményhez kötötten Minden erőforrás foglalás után: túl nagy költségigény -Detektálás hogyan: a) Egypéldányos erőforrások esetén:Körkörösség figyelésével b) Többpéldányos erőforrások esetén: A kielégíthető processzeket megkereső algoritmussal. -Megszüntetés hogyan: 1. Erőforrás elvételével: következmény általában úgyis a processz maradandó sérülése. 2. Processz lelövésével a) Összes holtpontban levő processz lelövésével:Biztos, hogy elegendő, de túl drasztikus. b) Egyesével lelőni és újra detektálni:Költségigényes, plusz döntési algoritmust igényel (áldozat kiválasztás): Legkevesebbet futott, legtöbb erőforrást birtokló, stb.? -Kármentés: Nagyobb biztonságot igénylő rendszerek esetén lehetséges a processzekhez közbenső mentési pontokat tárolni. Nagy költségigény. Megelőzés a) Megelőzés valamelyik kialakulási feltétel kiiktatásával -Nincs teljes körű megoldás 1. feltétel: kölcsönös kizárás: Nem iktatható ki, de pl a spooling technikával csökkenthető a kölcsönös kizárást igénylő erőforrások száma. 2. feltétel: foglalva várakozás Egy processz egyszerre kell kérje az összes erőforrását: túl nagy hatékonyság romlás 3. feltétel: nincs erőszakos erőforrás elvétel: Csak menthető állapotú erőforrásokra oldható meg. 4. feltétel: körkörösség kialakulása:Sorrendi foglalás: csak bizonyos erőforrásokra és programozási szabályok betartásával oldható meg. b) Megelőzés állandó mérlegeléssel: Minden erőforrás kéréskor megvizsgálni, hogy a kérés teljesítésekor biztonságos állapotban marad-e a rendszer (azaz nem alakulhat ki holtpont) Bankár algoritmus. -Ez a megoldás sem használható minden erőforrás esetén

Memóriakezelés Rövid fogalmak: 1. Overlay technika Átfedő programrészek (overlay) technikája. A programok egy része „szétvágható” olyan részekre, amelyek időben elkülönülten dolgoznak. Ezeket szükség esetén egyesével töltjük be, majd használatuk után újra a háttértárba menthetjük, hogy a felszabaduló területre egy másik overlay részt tölthessünk. A módszer akár valós címzésű rendszerekben is használható hiszen az átfedő programrészek mindig ugyanarra az ismert kezdőcímre töltődnek be.A módszer nem igényel OS támogatást (csak linker), teljes egészében a programozó valósítja meg.

2. Belső töredezettség Belső töredezettség: amikor egy partíción belül kihasználatlan területek vannak Kidolgozta: Csatlós Balázs

- 26 -

3. Külső töredezettség Külső töredezettség: A kihasználhatatlanul kicsi partíciók.

4. Swapping Egy blokkolt processz memória területét teljes egészében kiírja a háttértárra, hogy a felszabaduló helyre el lehessen helyezni egy másik processzt, majd visszatölti mikor a processz sorra kerül (esetleg egy másikat kiírva). Jelentős időigény, de több processz futhat.

5. Lapkeret A processz memória területét (a virtuális memóriát) azonos méretű blokkokra, úgynevezett lapokra osztjuk. A fizikai memória ilyen méretű lapkereteket tartalmaz. (Tipikus lapméret 2-4kb)

6. Laphiba A hivatkozott lap nincs betöltve lapkeretbe.

Hosszabbak: 1. Memória mint erőforrás Memória, mint erőforrás -a processz szemszögéből a memória egy erőforrás amire szüksége van -mint erőforrás a memória egy véges mennyiségű több példányos erőforrás, ahol egy cellát (egy példányt) egyszerre egy időben csak egy processz használhat (kivéve osztott mem), de elvehető a processztől (hiszen lementhető az állapota) és gond nélkül visszaadható Erőforrás kezelés egy külön operációs rendszer komponens segítségével: Memory Management Az MM feladata az erőforrás kezeléssel kapcsolatban: 1. Memória foglalások kezelése a) lefoglalni (allokálni) a processz számára szükséges memória területeket -statikus allokálás: A processz születésekor a kontextusa számára -dinamikus allokálás: A processz élete során felmerült újabb igények kielégítése b) Nyilvántartani a processz számára lefoglalt területeket, valamint a szabad területeket c) Biztosítani lehetőséget az extrém használatra is. Például olyan processzek is futhassanak, amelyek több memóriát igényelnek, mint az összes fizikai memória. 2. Memória területek védelme Egyik processz se férhessen hozzá egy másik processzhez rendelt memória területhez. 3. Osztott memória használat biztosítása A processzek használhassanak igény esetén közös memória területeket. Lehetséges legyen kódmegosztás, adatmegosztás.


- 27 -

2. Címkötődés probléma, címzés fajták Címkötődés probléma A program instrukcióiban a címek program készítés közben keletkeznek (fordításkor vagy linkeléskor), de a memória foglalás csak a processz létrejöttekor, azaz a program futtatásakor történik. Nem lehet tudni program készítés közben mely memória területek lesznek szabadok futtatáskor!! 1. Valós címzésű rendszerek A program készítéskor meghatározott címekre van szüksége a processznek (csak oda tud betöltődni), amíg az nem szabad nem tud futni. Csak single taszkos környezetben célszerű, bár létezett multi taszkos környezetben is. 2. Relatív címzésű rendszerek A program készítésekor relatív címek keletkeznek. A relatív címek egy bázis címhez képesti címek. A program betöltődésekor határozódik meg a bázis cím. Következmény: Minden címhivatkozás leképzésre szorul. Ehhez hardveres támogatás a CPU MMU egysége. (A processzek az egyik regiszterben tárolják a bázis címet. Minden címhez az MMU hozzáadja a báziscímet.) A módszer előnyei: -A processzek áthelyezhetők (relocatable), tehát tetszőleges szabad területre betölthető vagy szükség esetén más területre áthelyezhető. A módszer hátrányai: -A processz csak egybefüggő területen helyezkedhet el!! -A processz csak kevesebb memóriát használhat, mint a fizikai memória tartomány, hiszen a relatív címek tartománya a fizikai címtartomány egy résztartománya lehet. 3. Virtuális címzésű rendszerek A programok saját virtuális címtartománnyal rendelkeznek, virtuális címeket használnak. Az operációs rendszer minden virtuális címhez biztosít egy rekeszt (tárolót), ami nem feltétlenül a memóriában van, hanem bármilyen más tároló eszközön is lehet (persze csak kellően gyors tárolón) és nyilvántartja mely virtuális cím hol tárolódik. -Címleképzés: A virtuális címzésű rendszereknél, akár csak a relatív címzésűnél, minden címhivatkozás leképzésre szorul. A címleképzést most is támogatja a CPU MMU egysége. Problémát jelent viszont, hogy a) a leképzés sokkal bonyolultabb, mint a relatív címzésű rendszerek b) a címek csak memória címekre képezhetők le A processz számára a címképzés és minden ezzel járó művelet legyen láthatatlan. Előnye: -A processz memória területeinek elhelyezkedése sok darabban is lehet a memóriában vagy akár más tárolón -A programok tetszőleges méretű virtuális címtartományt használhatnak, akár a fizikai memória címtartománytól nagyobbat is. Hátrányai: -Bonyolultabb a címképzés. (Lassul egy utasítás végrehajtásának a sebessége) -A címképzésnél meg kell oldani, hogy a más tárolóra elhelyezett memóriaterületek betöltődhessenek. Így lesz olyan címleképzés, amely több nagyságrenddel lassabb, mint más címeké.


- 28 -

3. Fix partíciós memória kezelés. Fix partíciós -Az OS-en kívüli terület fix méretű és darabszámú partíciókra van felosztva. (bootoláskor meghatározott) -Egy processz, egy partíció !! -A korai rendszerekben valós címzésű, ilyenkor partíciónkénti várakozó sorok (hosszú távú ütemező) -Később relatív címzésű, ilyenkor közös várakozó sor, bár egy processz nem biztos, hogy bármelyik partícióban képes futni. 1. feladat: Egy processz egy teljes partíciót megkap. (még akkor is ha az igénye csak töredéke volt). A dinamikus allokáció addig nem okoz gondot, amíg a partíciót nem növi ki a processz, ha igen áthelyezés egy nagyobb partícióba. Nagy méretű (a legnagyobb partíció méretétől nagyobb) processzek nem futtathatók, a programozó használhat overlay technikát. 2. feladat: A védelem megoldása partíció határcímek figyelésével. (határcímek egy-egy regiszterbe, minden címhivatkozásnál ellenőrzés) 3. feladat: Osztott memóriát csak OS területen lehet biztosítani. A hivatkozás emiatt nem lehet a szokásos memória hivatkozás, hanem rendszerhívásokon keresztüli. Előnyök: -A single task-os modellel szemben ez multi task-os környezetben is használható. -Nagyon kis költségigény (allokációs idő, nyilvántartás mérete, stb) Hátrányok: -Nagyon rossz helykihasználtság, belső töredezettség van!!! -Korlátozott processz szám, méret

4. Változó partíciós memória kezelés. Továbbra is egy processz egy partíció, de nincsenek rögzített számú és méretű partíciók, a partíciók a processzek igényeinek megfelelően jönnek létre. Relatív címzésű módszer. 1. feladat: Elhelyezés az üres partíciók valamelyikébe. Az üres partícióból két partíció lesz az elfoglalt rész és egy új üres partíció.Elhelyezési stratégiák: -first fit (next fit) -worst fit -best fit Külső töredezettség vs. algoritmus költsége. A dinamikus allokáció gondot okoz. Ha a következő partíció szabad, akkor megnövelhető a partíció, ha nem szabad akkor át kell helyezni. A processz befejeződése szintén gondot okoz: össze kell vonni az egymást követő üres partíciókat (lyukakat), különben a külső töredezettség nagyon nagy lesz. A külső töredezettség megszüntetésére időnként teljes átrendezést is kellhet végezni. Partíció nyilvántartásra van szükség a szabad területek kereséséhez, a partíció határok nyilvántartásához. A nyilvántartás lehet (jól kereshető-e, könnyen módosítható-e?): -bittérképes: a memória blokkokra van osztva minden blokkról 1 bit info szabad-e. -láncolt listás: minden partíció egy láncolt listán bejegyezve (kezdete, hossza, szabad-e) -buddy rendszer: csak 2 hatványai méretű területek, minden mérethez külön lista (kezdete, szabad-e) Leterhelt rendszereknél swapping-re, tárcserére is szükség lehet. Kidolgozta: Csatlós Balázs

- 29 -

Nagy méretű processzek továbbra is csak az overlay technikát használva dolgozhatnak. 2. feladat: A védelem itt is a határcímek figyelésével oldható meg. A határcímek a processz kontextusba (valamelyik regiszterbe) letárolódnak. 3. feladat: Az osztott memória itt is csak OS területen képezhető, képezhet rendszerhívásokkal kezelhető. Előnyök: -Nincs (vagy kicsi) a belső töredezettség. -Nagyobb Nagyobb helykihasználtság, mint fix partíciós (kb. 50%-os, 50% os, függ a processzek átlagos memória igényétől) igényét Hátrányai: -A processzek továbbra is csak egyben helyezhetők helyezhet el. -Sokkal Sokkal több OS feladat, mint fix partíciós -Helykihasználtság erősen sen romlik ahogy a programok memória igénye nnő a fizikai mem-hez hez képest.

5. Lapozásos virtuális memória kezelés elve. Elhelyezés, nyilvántartás, címképzés, címképzé laphiba lekezelése, előnyei, nyei, hátrányai. Lapozásos virtuális memória kezelés 1. feladat: A processz memória területét (a virtuális memóriát) azonos méretű méret blokkokra, úgynevezett lapokra osztjuk. A fizikai memória ilyen méretű lapkereteket tartalmaz. (Ti (Tipikus lapméret 2-4kb) A lapokat bármelyik szabad lapkeretbe elhelyezhetjük vagy akár a háttértárolón kialakított területen is. (Ezt a háttértár területet (virtuális memória blokkok tárolására szolgáló terület) is szokás röviden virtuális memória területnek nevezni. Ne keverjük a virtuális memória fogalommal!)

Címképzés: Az os minden processzhez létrehoz egy laptáblát, amely tartalmazza a processz lapjainak tényleges elhelyezkedését. A laptábla kezdőcíme a processz kontextusából elérhető (regiszterbe betöltve). A laptáblának annyi bejegyzése van, mint ahány lapra felosztható a processz memória területe. Egy bejegyzés tartalmazza, hogy -a lap a memóriában van-ee vagy sem -aa helyét a memóriában (lapkeret cím: f) -a helyét a háttértáron -egyéb adatokat


- 30 -

1. A V címet átalakítja (p, o) alakúvá. 2. A laptábla kezdőcímébőll (b) és a lapcímből lapcímb (p) meghatározza a laptábla p-hez hez tartozó bejegyzését. 3. Ha a bejegyzésben azt látja, hogy a lap nincs a memóriában, akkor ezt nevezik laphibának, ezt az esetet külön tárgyaljuk. 4. Ha a memóriában ában van, akkor a bejegyzésből bejegyzésb megkapja a lap fizikai címét (f) 5. Az f-hez hez hozzáadja a lapon belüli eltolást (o) és megkapja R-t. A címképzés gyorsaságának növelése érdekében hardveres támogatást igényel!!! (CPU MMU egysége) Laphiba lekezelése 1. Laphiba esemény generálódik és a processz blokkolódik. Az esemény lekezelője lekezelője az os ezzel foglalkozó része a pager. 2. A pager betölti a kívánt lapot. Ha van a processznek üres lapkerete, akkor oda, ha nincs akkor helyet csinál, lásd kilapozási algoritmusok. 3. A processz rocessz visszakapja a futási jogot és ha futásra kerül, akkor a laphibát okozó utasítás ismételt végrehajtásával folytatja. A laphiba a lapozásos virtuális memória kezelés természetes velejárója. A laphiba kezelési mechanizmus teszi lehetővé, hogy nem szükséges kséges a processz teljes memória tartalmát ténylegesen a memóriában elhelyezni! DE! Az instrukció végrehajtásának ideje, ha laphiba is előfordul el fordul közben több ezerszerese is lehet, mint ha nem fordul elő laphiba. Fontos tehát a laphibák számának csökkentése. Ezenkívül fontos a laphiba lekezelés idejének csökkentése. 2. feladat: Külön védelemre nincs szükség, hiszen a leképzési mechanizmus biztosítja, hogy a processz csak saját területeihez tud hozzáférni. Igény merülhet fel arra is, hogy a saját területen belül belül lehessenek részek, amelyek csak olvashatók lennének. A megvalósítás a lapokhoz rendelt plusz bejegyzésekkel (laptábla egyéb adatok) lehetséges, de pusztán lapozásosnál nem nagyon használható, hiszen a laphatárok nem ott húzódnak, ahol mi szeretnénk. 3. feladat: Osztott memória kezelés közös lapokkal valósítható meg. Létrehozásakor, a processz laptáblájában egy közönséges bejegyzés jön létre a laphoz, de az os külön nyilvántartja. Egy másik processz csatlakozásakor az ő laptáblájába is kerül egy bejegyzés bejegyzé ugyanarra a lapra. A processz befejeződésekor ődésekor az ilyen lapok nem jegyződnek dnek be szabadnak, csak a megfelelő megfelel rendszerhívás hatására. Előnyök: -Nincs külső elaprózódás. -Nagyon kicsi belső elaprózódás. (csak a processz utolsó lapja lehet kisebb méretű, méret mint a lapkeret) -Könnyű elhelyezés. Bármelyik lap, bármelyik lapkeretbe. -Nagyon nagy memória igényű processzek is kezelhetők. kezelhet k. (a fizikai memóriánál nagyobb is) Nincs szükség sem overlay-re sem swapping-re.


- 31 -

Hátrányok: -A címképzés ideje jelentősen megnőtt. -A nyilvántartás mérete megnőtt. -A nyilvántartás kezelési ideje megnőtt. -A laphibák számának és kezelési idejének csökkentése érdekében újabb os funkciókra van szükség.

6. Munkakészlet koncepció, mennyiségi stratégiák, belapozási stratégiák, kilapozási stratégiák Munkakészlet koncepció, Working Set modell (Denis 1970) Working set: Azon lapok halmaza, amit a processz egy adott időintervallumban használ. Cél: a processzek munkakészletéből bármely időintervallumot is vizsgálunk a lehető legtöbb lap legyen a memóriában. A munkakészlethez tartozó lapokat és a munkakészlet nagyságát előre nem lehet tudni. Mennyiségi stratégia: Hány lapkerettel rendelkezzen egy processz? Munkakészlet másik jelentése: a lapkeretek halmaza amivel a processz jelenleg rendelkezik -Fix lapkeret szám: egyik processznek kevesebb, a másiknak több laphibája lenne. -Változó lapkeret szám:Mért laphiba ráta alapján. Belapozási stratégiák: -igényszerinti belapozás (demand paging): csak akkor lapozzuk be ha hivatkozás történt rá. Egyszerű megvalósítás. -előérző belapozás: A lokalitás elveket figyelembe véve (időbeli, térbeli) a hivatkozott lapon kívül még néhány lapot betölt. -mohó belapozás: betölt amennyit csak tud Kilapozási stratégiák: A pager, ha a processznek nincs már szabad lapkerete, helyet kell csináljon, azaz egy lapot ki kell lapozzon a memóriából. Lokális kilapozási stratégiák: csak a processz saját lapkeret készletéből lapozhat ki. Globális kilapozási stratégiák: más processzek lapkeret készletéből is kilapozhat. Ez utóbbi az egyszerűség kedvéért felfogható úgy, hogy a pager előbb módosítja a lapkeret számot (változó lapkeret szám, mennyiségi stratégia), majd egy lokális kilapozási stratégiát használ. Cél: azt a lapot kilapozni, amelyikre a legkésőbb lesz szükség. De előre nem ismert a lapok hivatkozási lánca. 1. FIFO: a legrégebben belapozott, belapozási sor, probléma: a régóta bennlévő, de gyakran használt lapok kilapozódnak 2. Második esélyes FIFO: belapozási sor plusz minden laphoz egy hivatkozás bit, ha hivatkoznak egy lapra 1-re áll. Kilapozáskor, ha a sor elején levő lapnak (legrégebbi lapnak) 0 a hivatkozás bitje akkor kilapozódik, ha 1, akkor 0 lesz és a sor végére rakja. 3. LRU (Least Recently Used): a legrégebben nem használt Használat ideje alapján sor. Ha egy lapot használnak (hivatkoznak rá) sor végére kerül. Viszonylag költséges algoritmus. 4. LFU (Least Frequently Used): a legritkábban használt Nyilvántartani a hivatkozások számát. Költséges. A korábban gyakran használt, de már nem használt is sokáig benn marad. Kidolgozta: Csatlós Balázs

- 32 -

5. NRU (Not Recently Used): nem túl gyakran használt. A kis költség a cél. Többféle megvalósítás. Pl. a) Az “utolsó 8 idő-intervallum intervallum históriája“: -referencia referencia bájt léptetés jobbra intervallumonként, -hivatkozott hivatkozott lapnál 1, nem hivatkozottnál 0 lép be. -A referencia encia bájtok egy rendezést adnak: kisebb a bájt a kilapozásra esélyes lapoknál. b) Módosítás bites -Minden laphoz egy R és egy M bit -M bit jelzi, hogy módosították-ee a lap tartalmát -R bit hivatkozáskor 1-re, re, bizonyos időnként idő 0-ra, azaz jelzi, hogy mostanában nában hivatkoztak-e hivatkoztak a lapra -A A nem módosult lapok kilapozása olcsóbb, ha van másolat a háttértáron-azaz háttértáron azaz sorrend (R M): (0 0), (1 0), (0 1), (1 1) További gyorsítás kilapozáskor: A pager szabad cpu időben id ben kiírja a módosult lapokat a háttértárra, így azokat már nem kell menteni ha kilapozásra kerülnek. Ez bármelyik kilapozási stratégia esetén használható csak egy módosítási bit kell hozzá.

7. Kilapozási algoritmusok számpélda.


- 33 -

8. Szegmentálásos virtuális memória kezelés. Elhelyezés, nyilvántartás, címképzés, szegmenshiba lekezelése, előnyei, elő hátrányai. Szegmensek: A virtuális címtartomány nem egydimenziós. Külön címtartományok:a kódnak, az adat szekcióknak, a veremnek, az osztott kódnak, kernel régiónak, stb. Ezek a szegmensek. Ez fordító támogatást igényel. Tisztán isztán szegmentálásos virtuális memória kezelés 1. feladat: A virtuális memória szegmensekre van osztva. A szegmenseket egyben lehet elhelyezni a memóriában vagy a háttértáron kialakított tárolón. Tehát nem egyforma méretűek méret a blokkok. A memóriában elhelyezés elhely problémái hasonlóak a változó partíciós memória kezelésnél tanultaknál, de a szegmensek mérete a memória összes méretéhez képest nem olyan nagy. Elhelyezés: -Szegmens elhelyezése lyukakba. -Elhelyezési Elhelyezési algoritmusok: first fit, next fit, best fit, worst wor fit. -Nyilvántartás Nyilvántartás szükséges a szabad területekről. területekr Címképzés: -virtuális cím: (s,d) Nyilvántartás kell a processzhez tartozó -Nyilvántartás szegmensek elhelyezkedéséről: szegmenstábla. Egy bejegyzés: szegmens memóriában-e vagy sem szegmens elhelyezkedése a memóriában szegmens elhelyezkedése a háttértáron szegmens hossz egyéb adatok (pl. r, rw) Szegmenshiba: ugyanaz a fogalom, mint laphiba Szegmenshiba kezelése ugyanúgy, mint lapozásos memória kezelésnél. 2. feladat: Védelem: szegmensen belüli eltolás és szegmenshossz összevetése. Belső védelem (védelem saját magától, hibáktól): szegmensekhez jogosultságok hozzárendelésével (pl. kódszegmensek csak olvashatóak) 3. feladat: Osztott szegmensek használatával, a lapozásoshoz hasonlóan. Előnyösebb, El nyösebb, mint osztott lapok, mert logikailag összetartozó adatok vannak egy szegmensen. Előnyök: -Kevesebb Kevesebb a szegmenshiba, hiszen a szegmensekre osztás igazodik a programok logikai szerkezetéhez (lokalitás elv)! -Kényelmesebb Kényelmesebb osztott memória használat. Hátrányok: -Sokkal több munkája unkája van az operációs rendszernek, mint a lapozásosnál: elhelyezési stratégia, bonyolultabb nyilvántartás -Van külső elaprózódás. A helykihasználás kisebb, mint a lapozásosnál. Kidolgozta: Csatlós Balázs

- 34 -

9. Szegmentálásos és lapozásos virtuális memória kezelés. Elhelyezés, nyilvántartás, nyilvántar címképzés, szegmenshiba lekezelése, előnyei, el hátrányai. Szegmentálásos és lapozásos virtuális memória kezelés A két módszer ötvözése.A processz memória területe szegmensekre van osztva. A szegmenseket kell elhelyezni vagy a memóriában vagy a háttértáron. Az elhelyezés nyilvántartása a processzhez tartozó szegmenstáblában. (szegmentálás előnyei: nyei: kevesebb szegmenshiba, osztott szegmensek) A szegmensek memóriában elhelyezésekor lapokra bontás. (lapozás előnyei: el nyei: nincs elhelyezési stratégia, bonyolult lyuk nyilvántartás, külsőő elaprózódás) Minden memóriában levő szegmenshez shez tartozik egy laptábla. Bonyolultabb címképzés: Előny és Hátrány a szegmentálásos és lapozásosból következik

IO kezelés, egyéb Rövid fogalmak: 1.

Eszközmeghajtó

Eszköz driver: -szerepe egy eszköz fajta kezelése -megszólítható: felülrőll call (hivás), alulról megszakítás -dinamikus betöltődés -eszközgyártó készíti, OS része?

2.

Logikai diszk

Logikai diszk -Egy fizikai diszken 0-n -ig ig számozott blokkok sora. -Mindegyiknek saját szimbolikus likus neve van. -Mindegyiknek saját driver-e van.

3.

Partíció, kötet

-Egy Egy fizikai diszken több partíció lehetséges -A partíciók (egyes OS-eknél) eknél) átlapolódhatnak. Partíciók –kötetek -Partícionálással Partícionálással egy nagy diszket részekre osztunk -Néha szükség lenne kisebb diszkeket (partíciókat) összevonva, egyetlen nagy diszkként "látni": ez a kötetesítés -Némely OS tudja ezt … pl. AIX Kidolgozta: Csatlós Balázs

- 35 -

-A kötet: logikai diszk, szervezhető rá fájlrendszer, van drivere ...

4.

Jegyzék (Directory)

A jegyzék is fájl, amely bejegyzéseket tartalmaz további fájlokról. Blokkhozzárendelés jegyzékhez akár a szokásos fájlhoz való blokkhozzárendeléssel, akár speciálisan történhet. -Tartalma: Kötött vagy változó hosszú lehet, tartalmazhat: bejegyzések neveit, i-node számot vagy egyéb adatokat (kezdő címet, hosszat, attribútumokat, stb.). -Gyakori a keresés a jegyzék file-n belül, ezért megfelelő szerkezet. (Hash tábla, b-fa)

5.

FAT(File Allocation Table)

-Láncolt listás allokáció indextáblával (FAT) mint fájlrendszer -File Allocation Table az indextábla, amely a partíció minden blokkjáról tartalmaz egy bejegyzést egy az egyes megfeleltetésben. Minden bejegyzés tartalmazza a neki megfelelő blokk folytatásának helyét. Az indextábla egyszerre szabad blokk nyilvántartás is.

6.

I-node

A file adatai, a blokkcímek főtáblázata valamint az egyéb adatok (dátumok, jogosultságok), egy i-node-ban találhatók.

7.

FCB

Az ismételt keresések elkerülése érdekében egy file megnyitásakor FCB (File Control Blokk) létrehozása

8.

Link, hard link, szoft link

Link: Célja: már meglévő fájlra más névvel is hivatkozhassunk. Hard link: -új dir-bejegyzés készül, a már létező fájl i-node-jára hivatkozva! -Csak ugyanazon a fájlrendszeren! -Törléskor a linkek száma csökken! Szoft link (symbolic link): -új fájl készül (új i-böggel), de az eredeti filera mutat (abszulut útvonal) -Mount-olt fájlrendszeren is!

9.

Mount

Mount: filerendszer használatbavételEgy filerendszer hozzácsatolása a root filerendszer egy üres jegyzékéhez.

10.

Authentication, authorization

Azonosítás (authentication), melynek célja: mely szubjektum mely védelmi tartományba léphet be. Különböző technikák (pl. jelszós, kártyás, ujjlenyomatos stb.) Jogosultságok (authorisations): erőforrás elérések gyűjtőneve


- 36 -

Hosszabbak: 1.

IO alrendszer felépítése.

Feladatok: -Elrejteni az eszközök specialitásait -Kényelmessé tenni az eszközhasználatot -Menedzselni az eszközöket, fájlokat Védeni azokat, ütemezni, konkurrens vagy kizárólagos hozzáféréseket biztosítani. Eszközök fajtái A) Karakteres eszközök (pl. billentyű, soros port, képernyő, analóg-digital átalakító stb). -Struktúrálatlanul (pl. karakter-folyamként) kezelhető, (Néha sor (line) strukturáltság van) -A driver fölött szűrés lehet. -Diszk is kezelhető karakteresen. B) Struktúrált (blokkos) eszközök (diszkek). -blokkos I/O-val is kezelhetők, -fájl-rendszer is alakíthatók ki rajtuk, -a buffer cache gyorsító mechanizmuson át kezelhetők I/O rendszer a felhasználó szemszögéből -Szimbolikus neveken látja az eszközöket, fájlokat a) Lát eszközöket (köztük logikai eszközöket), b) látja a fájlok halmazát (file pool), c) lát hierarchiát (ösvény, jegyzék stb. fogalmak) -A felhasználói felülettel (burok, v. GUI) kezeli ezeket (készít, töröl, másol, mozgat, eszközt kezel stb.) -Ismer tulajdonossági és hozzáférési kategóriákat (védelem), beállít ilyeneket. (-Bizonyos OS-ekben észlel fájl szervezési és fájl elérési módokat.) A programozó látásmódja -(Nyitott) csatornákat (stream) lát. Ezek azonosítója: fájl-leíró/pointer. -Nyithat/zárhat csatornákat (open, fopen, close, fclose). -Azonosított csatornákon adatokat (byte/karakter, rekord, blokk stb.) mozgat. (read, write,put,seek stb.) Az OS látásmódja Van külön I/O alrendszer. Ennek feladata: -vezérlés, -interfész biztosítás, -védelem és menedzsment biztosítás. Alapelvek: -Réteges struktúra, -eszközfüggetlenség biztosítása, -célszerűen elosztott a hibakezelés, -szinkronitás-aszinkronitás biztosítása, -osztható és dedikált eszközök, fájlok is kezelhetők. User szint -Rendszer hívások (system call) az eszközök kezeléséhez. (Lásd programozó látásmódja) -Az eszközök azonosítása szimbolikus neveken


- 37 -

Eszköz független réteg Szerepe: -Elrejti az eszközök közötti különbségeket, cserélhetőséget biztosít -magasabb szintű kezelhetőséget biztosít az eszközökhöz, blokkos eszközökhöz filerendszert biztosít Feladata: -feloldja a szimbolikus neveket, meghívja a megfelelő eszközkezelőt -Leírókat hoz létre és kezel -Filerendszert kezel Eszközfüggő réteg Eszköz meghajtókat (driver-eket) tartalmaz. Hierarchikus filerendszer -több lehetséges filerendszer -van filerendszer kezelő a rendszerhívásokat átalakítja az adott fájlrendszerre nézve specifikus hívássá, felületet biztosít a különböző filerendszerekhez ( VFS (Virtual File System, LINUX), IFS manager (Installable File System, NT)) -Ismertebb file rendszerek:FAT (DOS), VFAT, HPFS (OS/2), NTFS (NT), ext2 (linux) Diszkek, blokk orientált eszközök • Blokknyi egységben történik az adatáramlás. • Oldal-sáv-(cilinder)-szektor (blokk) fogalmak-adattárolási egység a szektor (blokk),-oldal-sávszektor címek léteznek, • Az oldal-sáv-szektor címek leképezhetők folyamatos logikai blokkcímekre (ezt a kontroller végezheti): felülről 0-n-ig számozott blokkok sorának láthatjuk. • Logical Disk képezhető a fizikai diszkre. Oka: egységesítés, egyszerűbb driverek.

2.

File fogalma, file szervezési módok, file elérési módok, file típusok, file attribútumok.

Fájl: Valamilyen szempontból összetartozó adatok halmaza névvel ellátva. Fájl szervezettség (organisation) lehet: -Byte-ok sora (nincs szervezettség), csakis a processzek struktúrálhatnak. -Rekordok sora (szekvenciális). A rekordokban mezők. Fix, változó rekordhossz, rekordok blokkokba csoportosítva stb., mindezek a fájlban (fájlrendszeren) rögzítettek. Nem minden OS biztosítja. -Index-szekvenciális szervezettségű rekordok: egyes mezők a rekordokban kulcsmezők, ezek rendezettek, a rekordok gyors keresését teszik lehetővé. Nem minden OS biztosítja. A fájl elérés: -soros elérés: egy adatelem (byte, rekord) eléréséhez az előzőeken “át kell jutni“. -direkt (random) elérés: egy adatelem eléréséhez nem kell a többiekkel foglakozni, közvetlenül elérhető bármelyik adatelem. (A Unix seek hívással lehetővé teszi. ) File típusok -közönséges file-k -jegyzékek (directory-k) -speciális file-ok: eszköz azonosító, mailbox, pipe


- 38 -

Fájl attribútumok: -név, -készítési, módosítási, elérési dátumok/idők, -tulajdonossági és védelmi információk, -szervezettségi adatok (hossz, rekordhossz, blokkolási tényezők stb), néha a -tartalom szerinti típusukra vonatkozó adatok, -a logikai diszken való elhelyezkedésükre vonatkozó információk.

3.

Filerendszer megvalósítás feladatai. Megvalósítás fajták felsorolása. A folytonos allokáció ismertetése.

3 dolgot kell megoldani valahogy: 1. Adott file-hoz blokkok hozzárendelése (Keresni, hozzáfűzni, elengedni blokkokat), 2. A partíción a szabad blokkok menedzselése (Keresni szabad blokkokat, elengedni (szabaddá tenni) blokkokat.) 3. A file egyéb attribútumainak tárolása. Valamint jegyzékstruktúra kialakítása. 1. Blokk allokációs módszerek -folytonos allokáció -láncolt listás allokáció -láncolt listás allokáció index táblával -i-node módszer 2. Szabad blokkok kezelése -Bittérképes -Láncolt listás Folytonos allokáció -A fájl blokkjai egymás után, folyamatosan -Csak a kezdő blokk cím és hossz tárolására van szükség: jegyzékben a név mellett -Ma már nem használják -Előnye: Egyszerű a nyilvántartás, a blokkok visszakeresése -Hátránya: A változó partíciós memória kezelésnél tanult problémákhoz hasonlók vannak itt is:Elhelyezés lyukakba (first fit, next fit, worst fit, best fit) Nagy a töredezettség, a kihasználhatatlan terület. Problémát jelenthet a hozzáfűzés (append) meglévő fájlhoz.

4.

Láncolt listás allokáció index táblával (FAT) ismertetése.

Láncolt listás allokáció indextáblával (FAT) -A file-t blokkokra osztva helyezzük el a partíció blokkjaiba, nem feltétlenül folytonosan -Az első blokk címe a jegyzékben -A mutató a következő blokkra nem a blokkba kerül, hanem indextáblába kerül -Indextábla: a partíció egy fix helyén található. Benne a partíció minden blokkjához tartozik egy bejegyzés egy az egyes megfeleltetésben. A bejegyzés tartalmazza a neki megfelelő blokk folytatásának helyét. -A file egyéb adatai is a jegyzékben találhatók. -A file X blokkjának vissza keresése: 1. megfelelő jegyzék megtalálása 2. jegyzékből az első blokk címének kiolvasása 3. az index táblából kiolvasni a blokkok címeit, végig követve a láncolást, amig meg nem találjuk az X blokk címét, azaz X-1 index bejegyzést kell elolvasni.


- 39 -

Előnye: -Nincs fregmentáció -Egy blokk megkereséséhez nem kell a megelőző megel blokkokat kiolvasni, csak az indextáblán kell végig követni Hátránya: -Nagy partíciókon, nagy index tábla -Egy file X-dik dik blokkjának megtalálásához X-1 X 1 indextábla bejegyzést kell kiolvasni. -Sérülékenység -Nagy index tábla megoldása: Cluster-ek: ek: több blokk együtt, csak cluster-eket cluster eket lehet foglalni, clusterenként bejegyzés az indextáblában. Hátránya nő a kihasználhatatlan terület. (minimum egy cluster foglalható még a kisebbnek is.) -Sérülékenység megoldása: Dupla indexx tábla. Hátránya: minden változást két helyen kell átvezetni.

5.

I-node-os os file allokáció ismertetése.

I-node-s allokáció -Elhelyezés Elhelyezés blokkokra osztva a partíció tetszőleges tetsz blokkjaiba. -Minden file-hoz hoz egy táblázat arról, hogy mely blokkja, mely blokkba van elhelyezve. -A táblázat célszerűen többszintű pl.0-9 sora: tartalmazza a file 0-99 blokkjának címét 10-12 12 sora: indirekt filemutatókat tartalmaz, azaz egy-egy egy egy 10 soros táblázatra mutatnak, amely tartalmazza a következő 10 blokk címét (10-39) 13-15 sora:: kétszeresen indirekt filemutatókat tartalmaz (40-339) (40 -A file adatai, a blokkcímek főtáblázata táblázata valamint az egyéb adatok (dátumok, jogosultságok), egy i-node-ban i találhatók. A jegyzékben csak a file neve és i-node i száma van. Az i-node-kk a partíció egy elkülönített területén vannak elhelyezve. Az indirekt blokkok táblázatai szintén egy elkülönített területen. -A A file X. blokkjának vissza keresése: 1. megtalálni a megfelelő jegyzéket 2. Kiolvasni az i-node node számát, majd betölteni a megfelelő megfelel i-node-t. 3. Haa X<10, akkor közvetlenül kiolvasni a táblázatból a keresett címet. Ha X>10, akkor betölteni az indirekt blokkok táblázatait, majd végig követve a hivatkozásokat megtalálni a megfelelő megfelelő címet. (pl 1000 esetén: a főtáblázat táblázat 16. sora (340-1339), (340 majd a hiv. táblázat 6. sora (940--1039), majd a hiv. táblázat 6. sora (1000-1009), 1009), majd a hiv. táblázat 0. sora (1000))


- 40 -

Előnyök: -Nincs fregmentáció -Egy Egy blokk megtalálásához kevesebbet kell olvasni mint bármelyik megelőző megel módszernél. -A file elhelyezési információk ók egy helyről helyr elérhetőkk (nem pedig jegyzék + indextábla) -Kevésbé sérülékeny Hátránya: -A A szabad blokkok külön nyilvántartás igényelnek (index tábla egyben szabad blokk nyilvántartás is)

6.

Reference Monitor modell. ACL, CL.

Reference Monitor koncepció -minden hozzáférés RM-en keresztül--kell legyen egy RM adatbázis, ami alapján dönt a RM a hozzáférés engedélyezéséről RM adatbázis 1. szubjektumokhoz kötött (CL: Capability List) Szubjektumonként megadva, hogy mely védelmi tartományokban mihez, milyen jogai vannak Báli meghívó hasonlat. 2. objektumokhoz kötött (ACL: Access Control List)Objektumokhoz megadva, hogy mely védelmi tartományokban milyen hozzáférések vannak hozzá. Bál meghívottak névsora hasonlat. (Egyszerűbb a megvalósítás, hiszen az objektumok többnyire töb file-kk és ahhoz könnyebb újabb adatokat tárolni) Security Audit: figyelés, naplózás, watch-dog watch -Szubjektumok: Szubjektumok: aktív entitások, a processzek (taszkok), amik valakinek a nevében (user) valamihez (objektumok) hozzá akarnak férni zá szeretnénk férni, passzív entitások, erőforrások, er források, szolgáltatások -Objektumok: amihez hozzá Kidolgozta: Csatlós Balázs

- 41 -

-Védelmi tartományok (Protection Domain): a védett erőforrások és a hozzáférési jogosultságok összessége. A szubjektumok a védelmi tartományokba „beléphetnek” (behatolhatnak). Nyilvántartás csökkentés szerepe van.

7.

Unix egyszerűsített file védelmi rendszere. Setuid koncepció.

Unix egyszerűsített védelmi rendszere: -ACL alapú-Itt minden fájl, minden a fájl-védelmen keresztül védett. -Az i-bögben tárolt: a tulajdonos (uid), csoporttulajdonos (gid). Ezekkel a védelmi tartományok szegregáltak (egy fájlhoz három védelmi tartomány tartozik). Ugyanitt tároltak a tulajdonossági kategóriákhoz az rwx jogok. r olvasási jog (ls-hez, dzsókerekhez kell). w engedély változtatásra (mv, rm, ln-hez kell). x engedély futtatásra, jegyzéknél hozzáférés magukhoz a fájlokhoz (cd-hez kell). -A szubjektumok a processzek. -Van valós és effektív tulajdonosuk (uid-dal azonosítva). -Van valós és effektív csoport-tulajdosuk (gid). -A valós és effektív tulajdonlást az öröklődés és a setuid koncepció határozza meg. -Az effektív tulajdonosság határozza meg a védelmi tartományt. -A processz effektív tulajdonosság és a fájl tulajdonosság összevetődik. Ha egyezés van, a fájl i-bögébe írt, a tulajdonoshoz tartozó rwx hozzáférések szabják meg a hozzáférést vagy elutasítást. -Ha nem volt egyezés: a csoport-tulajdonosságok vetődnek össze. Egyezés esetén a hozzáférést/elutasítást a csoporthoz rendelt rwx minta szabja meg. -Ha nem volt egyezés: az i-bög others rwx-e szabályoz. SETUID koncepció: -A valós és effektív tulajdonosságok sokszor egybeesnek. -A valós tulajdonosságot a szülő processztől örökli a processz, vagy a szülő állítja be neki. -A setuid/setgid bejegyzésű végrehajtható fájlokból készült processz effektív tulajdonosa a végrehajtható fájl tulajdonosa lesz (valós tulajdonos a szülő processz tulajdonosa). -Példa: passwd futtatható fájl tulajdonosa a root, és setuid-os. A /etc/passwd fájl tulajdonosa a root, én csak olvashatom. Általam indított passwdprocessz mégis írhatja.


- 42 -

Más néven rendszermag, az operációs rendszer funkcióit ténylegesen megvalósító része

Recommend Documents