A folyamat kontextus, processz menedzsment, processz állapotok

Az előadások a következő témára: "A folyamat kontextus, processz menedzsment, processz állapotok"— Előadás másolata:

1 A folyamat kontextus, processz menedzsment, processz állapotok
OPERÁCIÓS RENDSZEREK A folyamat kontextus, processz menedzsment, processz állapotok

2 A mai program A processz és a processz kontextus fogalmak
Kontextus váltás (processz – rendszer – processz kontextus) Processz kontroll, rendszerhívásai Processz állapotok, állapotátmenetek, futási mód A taszk, processz, fonál fogalmak Vadász

3 A CPU által végrehajtott instrukciófolyam
Hogyan működik a számítógép: a CPU veszi a soron következő instrukciót és végrehajtja … Van képzetünk az instrukciófolyamról. Ez struktúrálatlan. A HW ad egy struktúráltságot: felhasználói módban/kernel módban végrehajtott instrukciófolyam szakaszok vannak. Köztük a trap és a visszaállítás. A processz fogalom alapvető fogalom az OS-ek tárgyalásakor… Közelítsük meg! Vadász

4 Az instrukciófolyam másik struktúrálása
Logikailag szakaszoljuk az instrukciófolyamot Egy adott program futásához tartozó instrukciófolyam a kezdetétől a végéig egy szakasz Ez a job/taszk/processz Ez a szakaszolás nem következik a hardverből Ezt a szakaszolást az OS végzi A processzhez persze az instrukciófolyamon kívül az adatai (és még további információk) is hozzátartoznak ... A processz fogalom nem következik a HW-ből. Direkt futtatás a HW-en (tárgyalásmódban) esetben nincs processz fogalom. Akkor csak instrukció folyam van … Vadász

5 A folyamat fogalma 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: processzben fut a program. A processzhez dedikált PC tartozik, ami egyetlen helyre tud mutatni a program szövegben Itt a klasszikus processz fogalmat definiáljuk. Lesz, lehet gond a terminológiában. Taszk-processz-fonál, hol így, hol úgy nevezik … Vadász

6 Folyamat tartalom (Process Context)
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 (állapotokat leíró, számlázási, hozzáférési stb. információk, erőforrás leírók) Regisztertartalmak. Ez sem „egyszerű” fogalom, a processz kontextus fogalma … Olyan kifejezések tisztázandók, mint címtartomány (processz címtartomány, ennek user, ill. rendszer szintű része; a futási mód, a kontextus). A dián a legáltalánosabb definíció … A tartalom szerinti csoportosítása igen fontos, gondoljuk át … mi minden kell, hogy a processz futhasson … Vadász

7 Egy másik szemléletmód:
A processz kontextus Egy szemléletmód: hardver kontextus: HW regiszterek, MMU regiszterek stb. (volatile context/environment) szoftver kontextus (Address space) Egy másik szemléletmód: felhasználói szintű kontextus, amit a felhasználói címtartomány (User Level Address Space) címez rendszer szintű kontextus (System Address Space) A felhasználói címtartományhoz tartoznak a kód, adatszegmensek, a felhasználói verem (és heap), beleértve a felhasználói szintű osztott memóriaszegmenseket is. A rendszer szintű statikus kontextus tartalom szerint az adminisztrációs információkból (processz tábla belépési pont és processz leíró, bennük tulajdonossági információk, korlátok és engedélyek, az environment tábla stb.) áll. Felfogás kérdése, de a processz javára futó kernel szolgáltatások kódját, adatait általában nem szoktuk a processz kontextushoz tartozónak venni … A dinamikus/volatile kontextus a hardver kontextus. Beleértjük az általános regisztereket is (pedig ezek nemcsak kernel módban elérhetők!), és természetesen a speciális regisztereket: PC és PSW, SP; az MMU regisztereket (a virtuális címek leképzési tábláinak címeivel), a FPU (Floating Point Unit) regisztereit stb. Vadász

8 Futási mód - kontextus - címtartomány
Emlékezz: módváltás=trap/kivételes esemény/IT User mód User Address Space Processz kontextus (program, adat, verem) Kernel mód Kernel Address Space Admin. adatok Kivétel kezelők, szolgáltató rutinok stb. System Stacks, IT handlerek, ütemező stb. A processz javára Vadász

9 Futási mód - kontextus -címtartomány
A processz címtartományának Egy része a felhasználói címtartomány. Processzenként szétválasztott memóriaterületet címez. Egy része kernel szintű címtartomány. Minden processz ugyanazt a kernel memóriarészt címezi Fontosak az MMU regiszterek (VM címleképzéshez). Ezek is részei a processz kontextusnak. Fontos fogalom a futó processz (kurrens) MMU regiszterei segítik a címleképzést Később tárgyaljuk a processz állapotokat, benne a futó állapotot … Vadász

10 Egy kérdés, és a válasz … Van már fogalmunk a processz címtartományairól és a kontextusáról. Mi van a kernel kóddal? Az tartozik valamilyen kontextushoz? A válasz: Bizonyos kernel szolgáltatások kliens-szerver módban, önálló processzekként teljesítődnek. Saját processz kontextusuk van, IPC-vel kérhetők szolgáltatásaik. Mások: rutinok a kernelben Egyes rutinok a futó processz javára dolgoznak (sycall, kivételkezelők) Az IT kezelőknek (valószínűleg) nincs közük a futó processzhez. Lehet, nincs is futó processz. Kétségtelen, az önálló processz-szolgáltatótól a az IPC-t syscall-lal kérjük, de valójában nem ez a syscall szolgáltat … Hozzá tartoznak-e processzhez a kernel rutinok? Az IT kiszolgálók semmiképp! Lehet, nincs is futó processz! (Bár a mai OS-ek, ha nincs CPU-t igénylő processz, akkor egy idle processzt futtanak … ) Vadász 28

11 Tovább a válasz … A futó processz javára dolgozó kernel rutinok a processz kontextusán (fölötte) futnak Ekkor a kernel közvetlenül elérheti a futó processz kontextusának elemeit A független processz modellből levezethető tárgyalásban a kernel kódok, adatok nem is részei a processz kontextusnak (fölötte fut). De egy másik tárgyalásmód szerint részei (kontextusán fut) Az IT kezelők semmiképp nem részei egyetlen processz kontextusnak sem. Nem processz kontextusban futnak, minden processz kontextusa fölött: rendszer kontextusban Ha kisarkítottan „független processz modell” szerint nézelődünk, akkor a kernel rutin nem része a processznek… Vadász

12 Tovább a válasz … Tárgyaljuk így:
A CPU futhat egy processz kontextusán (kontextusában) Felhasználói módban: a program kódját futtaja Kernel módban: Sycall rutint, kivételkezelőt futtat. Ezek közvetlenül elérhetik a processz címtartományát A CPU futhat rendszer kontextusban Kernel módban: IT kezelést végez, tevékenysége nem köthető egy processzhez (sem) . Valamely processz kontextusa csak közvetetten érhető el. Van processz kontextus váltás (két processz közti akció), és van processz kontextusról rendszer kontextusra való váltás: egyszerű kontextus váltás (futó processz MMU regiszterei helyett rendszer MMU regiszterek betöltődnek, ez „olcsóbb”) fogalom Figyeljünk fel! A CPU fut valamilyen kontextusban (kontextuson) … Ez a tárgyalásmód most! A két kontextus váltás fogalomra hívom fel a figyelmet! A későbbi tárgyalásban ez „elkenődhet”. De tudjunk róla, lehet így is tárgyalni. Ha valaki a Valós idejű rendszereket választani fogja, ott rádöbben, fontos a distinkció (ott az időzítések fontosak, az „olcsóbb” egyszerű kontextus váltás és a „drágább” processz kontextus váltás különbség lényeges lesz. Most nekünk elég lesz a PCS. Később még részletezzük! Vadász

13 A processz kontextus adatstruktúrái
Process Table Entry (kernel címtartományban) 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): azonosítók (pid, pname, statikus kvóták, attributumok), kód és adatszegmens pointerek és hosszok, vermek hossza stb. 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 információk, vermek pointerei stb. Adatstruktúrákba rendezve minden információ, ami a processz futásához kell … Nézzük, az adatstruktúrákat! Processz tábla belépési pont, processz tábla bejegyzés … a „kályha”, ahonnan indulhatunk, ahonnan megragadhatjuk a kontextust … Vigyázz a „statikus” jelzőre! Processz leíró … értsd meg a „dinamikus” jelzőt … Vadász

14 A processz kontextus adatstruktúrái A kiinduló pont
A processz tábla (Process Table) A kernel által kezelt, adott méretű táblázat (array of structure), melynek egy-egy bejegyzése egy-egy processz vezérlő blokk (process table entry). A tábla mérete kritikus. Mi történne, ha betelne? Processz vezérlő blokk (Process Control Block) 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 (scheduling) kapcsolatos információk erőforrás használati határértékek (limitek, kvóták) mutatók a kontextus további részeire stb. next/prev pointerek láncolt listákhoz. ( Más elnevezések is lehetnek) A PT régebben tábla, ma láncolt struktúrák … A PCB név elég általános … Vadász

15 Unix processz kontextus adatstruktúrái
u-area proc-structure Process Table Processzenkénti region table Közös Memória Ez egyszerű … A klasszikus Unix struktúrái persze … Ma már ez is bonyolultabb … Mindenesetre, ha nincs klasszikus régió, címtartomány szakaszok lehetnek: ezek adják (részben) a tartalom szerinti kontextus címeit … Vadász

16 Unix processz kontextus adatstruktúrái
Proc structure (olyan adatok, melyek akkor is kellenek, ha kisöprött a processz) uid, gid, pid, ppid (azonosítók) program méret, memóriaigény állapotjelzők a memóriamenedzseléshez, a globális ütemezéshez szignál mezők stb. U area (1K-4K)(kisöpörhető, kilapozható; olyan információk, melyek akkor kellenek, ha a processz nincs kisöpörve) user structure + mutató a kernel veremre erőforrás limitek, kvóták, default eszköz, dir, terminál nyitott I/O folyamok leírói, idő, számlázási információk az ütemezéshez stb. Ez is a klasszikus Unix-hoz tartozó ismertetés. Doksikból lehet nézni, pontosan mi hol van … Vadász

17 Unix processz kontextus komponensek
A kontextus statikus része A kontextus dinamikus (volatile)része Felhasználói szintű kontextus Program szöveg Adatok Veremtár Osztott adatok Keret a 3. rétegnek Rendszer szintű kontextus statikus része Keret a 2. rétegnek Process Table bejegyzése U Area Processzenkénti Region Table Keret az 1. rétegnek Ez megint egy egyszerű ábra, Bach-tól … de szemléletes … Felhasználói szint Vadász

18 Összefoglalás Vettük a processz fogalmat, szétválasztva a program - processz fogalmakat. a processz kontextus fogalmat tartalom szerint, adatstruktúráival, címtartományok szerint. Kérdés: miért jó a processz koncepció? Milyen előnye van? A válasz: a processzekhez rendelhetjük az erőforrásokat, és így azokat könnyebb számon tartani, menedzselni, kiosztani, ütemezni. Vadász

19 Folyamatok vezérlése (Process Control, Process Management)
A folyamatok születnek, élnek, valamilyen feladatot végeznek, versenyeznek erőforrásokért, osztoznak erőforrásokon, kommunikálnak, együttműködnek, szinkronizáció köztük. Végül exitálnak. Általában processzt csak processz kreálhat. Így: szülő - gyermek kapcsolat lehet közöttük. Van ősszülő processz. (Lehetnek a rendszer betöltéskor keletkező processzek, amiknek nincs szülője.) Általános célú OS-ben rendszerint egy ősszülő processz van. Speciálisokban – pl Real Time- lehet több „kézből készült processz”. Amik a rendszer boot során keletkezik, nincs szülője. Oka: a processz kreáció drága, legyen minden szükséges processz élő … De tudok olyan RT rendszerről, aminél a processzeket kreálja egy ősszülő, még mielőtt a rendszer üzemszerűen dolgozna … tehát a boot után közvetlenül … Vadász

20 A processzek élete Szülő folytatja futását gyermekével párhuzamosan
Szülő megvárja, amíg gyermekei befejeződnek A szülő és gyermeke osztozik az erőforrásokon Részben, alig, vagy egyáltalán nem osztoznak Processzek együttműködése Független processzek (nincs hatásuk egymásra) Kooperáló/versenyző processzek Vadász

21 A független processz modell
A kernel saját virtuális gépet biztosít minden processznek. Ezen a processz szekvenciálisan fut. Saját időtere van, csak ezt látja … Egy rendszerhívás a virtuális gép egy virtuális instrukciója. Saját időterében megszakíthatatlan. A kivételes esemény, a megszakítás a virtuális gép számára esemény, le tudja kezelni. Nem szükségesek a processz állapot, állapotváltás, az ütemezés, módváltás fogalmak sem … Ez egy idealizált modell. Nem igaz, hogy a processzeknek nincs hatásuk egymásra … Egy alapvető szemléletmód, modell a „független processz modell”. Az a képzet, mintha minden processznek saját Neumann gépe lenne … (Hogy dolgozik a Neumann gép?) Vegyük észre a koncepció egyik kulcsát: a syscall egy virtuális instrukció: a processz saját időterében megszakíthatatlan … Éppen egy OS tudja biztosítani ezt az illúziót. Nincs hatásuk a processzeknek egymásra … Persze! Maga az a tény, hogy van szülő-gyermek kapcsolat: ez „bontja” a függetlenség koncepciót. Továbbá: sokszor ugyanazokért az erőforrásokért vetélkednek a processzek: hogy is lehetnének függetlenek! Ha viszont nem azok, akkor legjobb, ha ki is használjuk ezt: működjenek együtt a processzek! Vadász

22 A kooperáció A kooperáció kiváltó oka Mit kíván a kooperáció?
Információ osztás, pl. közös fájlok stb. Sebesség növelés. Feltétel: több CPU, vagy I/O csatorna Modularitás (bonyolult rendszerek dekompozíciója) Kényelem (pl. editál-fordít párhuzamosan a felhasználó) Mit kíván a kooperáció? Processzek közötti kommunikációs mechanizmusokat (IPC mechanizmusokat). Kölcsönös kizárási mechanizmusokat. Triviális az igény a kooperációra! A kizárási mechanizmusok a nem kooperáló, csak vetélkedő processzek miatt is kellenek! Vadász

23 Processz kontroll rendszerhívások
Processz kreáció hívásai fork(), vfork(), system(), clone()LINUX, ptrace() Statikus kontextus megváltoztatása execl(), execlp(), execle(), execv(), execvp() Processz terminációval kapcsolatos hívások exit(), _exit(), abort() (a szignálkezelők is terminálhatnak) atexit(), on_exit() // terminációt befolyásoló hívások wait(), waitpid() // terminációt kiváró hívások Segítő hívások sleep(), pause(), szignálkezelések, attribútum lekérdezések és beállítások stb. A kiemelt (arany színnel jelzett) rendszerhívásokra van példa. A többire nincs. Vadász

24 Processz kreáció A kernel elkészíti a processz tábla bejegyzést;
memóriát biztosít a kód és adatszegmenseknek, inicializál; elkészíti a processz leírót, memóriát biztosít a vermeknek; Elkészíti a regiszter kontextust (a PC értéket kap); futtatható állapotba teszi a processzt. Az biztos, hogy kreáló hívások kellenek … Figyeljünk fel a fogalmazásra! Processz kreál processzt: valójában a kernel kreál egy processz kérelmére … ennyi pongyolaság elmegy … Elvileg elképzelhető: rendszer kontextusban fut a CPU, kernel kódot hajt végre (egyetlen processz kontextusában, kontextusán sem fut), és ott van kreációs kérelem: ekkor nem processz „kreál” … De a „pongyola” fogalmazás” is elmegy …. Vadász

25 Processz befejeződés Az exit/return rendszerhívás család egyik tagjának meghívása, vagy a vezérlésnek a main függvény utolsó utasításának végrehajtása a normális termináció A termináció során „háztartási munka” folyik, Az atexit() és on_exit() hívásokkal befolyásolhatjuk ezt. Néhány mozzanat a háztartási munkából: Processz szignáloz a szülőjének, hogy exitál; Gyermekeit átadja más processznek, hogy azok legyenek s szülők; (Esetleg) leszármazottainak szignáloz (pl. üléslétesítő processz SIGHUP szignált küld). Az abort() rendszerhívás erőszakosan terminálja hívóját. A szignálok (az alapértelmezési szignálkezelők) többnyire szintén terminálnak. Nézzék meg a man-ban az atexit()-et és az on_exit()-et! Az abort()-ot is! Vadász

26 Processz kreáció: fork()
A fork és a join mechanizmus A fork az instrukciófolyamot két párhuzamos ágra osztja, elágaztatja, a join pedig a két ágat összeolvasztja. A fork()POSIX, Unix 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 szülőben a fork-kal szétválasztott ágakat a wait() v. waitpid()POSIX hívással lehet összeolvasztani: a szülő megvárja gyermekének terminálódását. Vadász

27 Gyermek processz készítés: fork()
Szintaxisa Prototípus deklarációja: pid_t fork(); Hívása: #include <sys/types.h> #include <unistd.h> ... pid = fork() A pid_t típus egy integer típus, ami pid-et tud fogadni. Vadász

28 A fork szemantikája Készít gyermek folyamatot, melynek kontextusa a pid-et és az időfelhasználást kivéve ugyanaz, mint a készítőjé (ugyanaz a szöveg, ugyanott fut!) A pontos egyezőségekért, különbözőségekért nézzék a man fork-ot! Elnagyolt definició. Nézzék a man lapokat, mik a különbségek a két processz kontextusban, állapotban … Itt azt hangsúlyozom, hogy nem sok … Mondjuk a pid és a ppid biztos különbözik … Vadász

29 A fork „tevékenysége” Ellenőrzi, készíthető-e a gyermek. Meghatározza a gyermek pid-jét. Előkészíti a VM kisöprési/kilapozási területét Bejegyzést készít a processz táblába a gyermek számára Bizonyos adatok a szülőtől jönnek (uid, gid, signal mask, ppid), mások 0-val, vagy a processzre jellemzően indulnak (idők) VM címleképző táblá(kat) allokál a gyermeknek Elkészíti a processz leírót (másolja a szűlőjét, majd a gyermek címleképzéséhez igazítja). Ezzel a szülő kontextusának logikai másolatát elkészíti. A nyitott adatfolyamok hivatkozásait inkrementálja. Inicializálja a gyermek HW kontextusát (a szülő regisztereit másolva), futtatható állapotba teszi a gyermeket. Mindkét processzben visszatér: szülőben a gyermek pid-jével (negatív értékkel, ha hiba van), gyermekben 0 értékkel. Lehet, nem értjük még a VM menedzseléshez tartozó fogalmakat: VM kisöprési terület, VM címleképző táblák, de mit tegyünk! Mai rendszerekben VMM van. A processzeknek V címtartománya(i) van(nak). Ez egy „illúzió”, hogy van elég memóriája. A kontextusa csak részben van a fizikai memóriában, van, amikor ki van lapozva/söpörve: ehhez kell a kilapozási/söprési terület valahol másodlagos tárolón … Annyi, amennyi szükséges neki … Ezt kell „előkészíteni”. Továbbá. Mikor fut, címhivatkozásai – amik V címekre való hivatkozás - leképzendők fizikai címekre … Ehhez kellenek a címleképző táblák … Pl. Laptábla … Vadász

30 Egy egyszerű példa … main() { int pid, gpid; pid = getpid();
if((gpid = fork()) == 0) { /* Itt a gyermek fut */ gpid = getpid(); exit(0); /* Gyermek befejeződik */ } /* itt a szulo fut */ exit(1); /* Szulo befejeződik */ Figyeljük meg! Szülő-gyermek ugyanott fut, éppen a forkból tér vissza mindkettő. A visszaadott értékkel „szétválaaszthatjuk” a szülőt és a gyermeket! Itt a szülőben nincs wait(). A gyermek, ha előbb exitál, zombie lesz. Vadász

31 Két kérdés … main() { if (fork() /*1*/) exit(1); else if (fork() /*2*/) exit(2); else fork() /*3*/; exit(3); } Hány processz fut, ha a fenti programot futtatjuk? (Feltesszük, minden fork() sikeres). És itt? main() { int i; for (i=0; i<3; i++) fork(); } Elsőre a válasz: 4 processz. A másodikra: 8 processz Az 1. számú processznek lesz 3 gyermeke (2., 3., 4. számmal). A 2.számúnak még kettő (5. és 6.), a 3. számúnak már csak egy 7.), a 4iknek egy se. De az 5. processznek még szintén jut egy gyerek, ez lesz a 8. processz. Vadász

32 A 2-es példa magyarázata
main() { if (fork() /*1*/) exit(); else if (fork() /*2*/) exit(); else fork() /*3*/; exit(); } Az első processzben végrehajtódik az /*1*/ fork, készül a második processz. Mindkettőben visszatér: az első exitál, a másodikban ráfut a /*2*/-es forkra. A másodikban végrehajtódik a /*2*/ fork, készül a harmadik processz. A /*2*/ fork a másodikban nem nullával tér vissza: exitál a második. A harmadikban nullával tér vissza: ráfut a /*3*/-as forkra. Ez elkészíti a negyedik processzt is. A harmadik és a negyedik az utolsó exit-en exitál. Hasonló zh példa lehet! Vadász

33 Statikus processz kontextus megváltoztatása
Új programot tölt a kontextusra. Az exec* család Egyikük deklarációjának szintaxisa: int execl(char *path, char *arg0[, char *arg1,…](char *) 0); Visszaad: státust. Hívása: #include <unistd.h> int status; ... status=execl(”/public/myname/myexec_file”,”pname”,”elso”,”masodik”,NULL); Tudunk processzt kreálni, de majdnem ugyanaz a program fut benne … Szeretnénk mást futtatni. Vadász

34 Az exec? lépései Elemzi a path-ot, ellenőrzi, hogy futtatható-e (permissions, executable, SUID, SGID) Másolja az argumentumokat és beállítja a lörnyezetet (environment) VM-hez swap területet allokál, a régit elereszti VM-hez címleképző táblá(kat) allokál, felállítja az új címtartományokat Default szignálkezelést állít be (a blokkolt vagy ignorált szignálokat megtartja) Inicializálja a HW kontextust (PC felveszi a belépési pont címet, többi regiszter nullázódik) SUID, SGID: setuid koncepció. A félév végén részletezzük. Most annyit, hogy „védelmi”, engedélyezési koncepció … Emlékezz: environment: exportált shell változók definíciói … öröklődik a szülőtől. Ismételten előjön a VMM. A szignálozásról is később beszélünk, most csak jegyezzük meg … Vadász

35 Esettanulmányok Nézzék a helyet. Itt a …/proc jegyzékben a következő fájlok: system-syscall-pelda.c // system() rendszerhívások szulo-gyermek-egyutt-fut.c // fork() hívás fork-exec-villak.c & echoall.c // fork után execle és execlp A következő fájlok processz terminálódási példák: processz-terminalodasok.c // különböző terminálódások processz-terminalodas-2.c // terminálódó processz gyermekei esete zombie-processz.c // zombie előállítás Vadász

36 Foglaljunk össze! Tudunk processzt kreálni, statikus kontextust váltani a fork-exec "villával". Az exec*() hívásnál argumentumokat adhatunk át a main()-nek! Érdemes megnézni a wait()SVID, waitpid()POSIX, wait3()BSD hívásokat, ezekkel a szülő megvárhatja a gyermeke lefutását! Processzek terminálódását elérhetjük az exit() rendszerhívásokkal. Az exit során „háztartási munkát” végeztethetünk. Most újabb téma jön: processz állapotok Vadász

37 Processz állapotok Az OS szempontjából nézve
több processz (futó program) létezik a rendszerben, ezeknek aktivitása van, futásuk közben különböző állapotokat vehetnek fel. Az operációs rendszernek nyomon kell követni az állapotokat, állapotváltozásokat, hogy erőforrásokat és szolgáltatásokat biztosítson a processzek számára. A "global system state" a létező processzek állapotainak összessége. Volt szó a futó processzről, kurrens processzről … Ezek „állapotok”. Figyeljünk majd fel: egy egy processznek vannak állapotai, és az összes processz állapota is fontos … Vadász

38 Egy processz állapotai
A legalapvetőbb állapotok: Futó állapot (running, current stb.). A processzé a CPU. Futásra kész állapot (ready, computable etc.). A processz számára minden erőforrás rendelkezésre áll, kivéve a CPU-t. A CPU-t igényli a processz. Blokkolt állapot (blocked, sleeping stb.) A processz a CPU-n kívül valamilyen erőforrást igényel még. Előbb ezt kell megkapja, csak utána vehet részt a CPU-ért való versengésben. A futásra kész és a blokkolt állapotokat együtt szokás várakozó (waiting) állapotoknak is nevezni. Általában az állapot elnevezésekben sok változat van. Futó processz volatile kotextusa a HW regiszterekben van … Vadász

39 Processz állapotok, állapotátmenetek
futó schedule/run sleep/wait/request preempt signal/assign blokkolt kész várakozó Ellipszisek az állapotok, nyilak az állapotátmenetek Más elnevezések is szokásosak (pl. ready=computable=on, blocked=sleeping=suspended, running=current=active stb.) Mi válthatja ki az átmeneteket? Látható a Process Context Switch jelenség Ez a legegyszerűbb, legáltalánosabb modell. A PCS-ben mindig két processz vesz részt! Vadász

40 Az állapot átmenetek A wait/sleep/request állapotátmenetet maga a processz "okozza", azzal, hogy bejelenti igényét valamilyen -a processzortól különböző - erőforrásra (pl. bufferre, diszk blokkra, eseményre stb.) A signal/assign állapotátmenetet rendszerint egy IT kezelő (handler) rutin "okozza", jelzés, hogy már rendelkezésre áll az a más erőforrás. A elvétel (preempt) és a kioszt (schedule/run) állapotátmeneteket az ütemező (scheduler/dispatcher) "hajtja végre". Szokás a preempt-shedule/run állapotátmenteket egyszerűen switch-nek (kapcsolásnak) is nevezni Vadász

41 A Process Context Switch
A CPU "kapcsolása" két processz között. Egyik "elveszti" a CPU-t, a másik megkapja. Mindig két processz vesz részt benne, az egyiknél wait/sleep/request (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, a másiknál a schedule/run átmenet (megkapja a CPU-t). Figyeljük meg: blokkolt processz állapotból előbb kész állapotba kell jutni, hogy a „kapcsolásban” részt vehessen processz! Emlékezz az ábrára! Vadász

42 Egy bővebb - de általános - állapot diagramm
exit running zombie wait preempt-schedule delete signal create blocked ready non existent suspend suspend resume suspend resume Tannenbaum ábrája ez. BSD- terminológia. A suspend felfüggesztés „kiváltó oka” az, hogy valamilyen erőforrásra „hosszabban” várakozó processzel ne kelljen a rövid távú ütemezésnek foglakozni … Nemcsak maga a processz függesztheti föl magát, sőt, ez a ritkábbb. Pl. memóriahiánya van … kisöprődik és felfüggesztődik … Tehát középtávú ütemezési kérdés ez .. suspended signal suspended blocked ready Vadász

43 A processz állapotok nyilvántartása
A kontextusban (rendszerint a PCB-ben) rögzítettek az állapotok, de láncolt lista adatszerkezeteken, sorokon (queues) is! Sorfej head tail PCB PCB NULL Ready queue head tail NULL MT1 queue Blokkolt processzek sorai head tail PCB PCB NULL Disk1 queue Mielőtt az egyes processz állapotokat tovább tisztáznánk, egy pillantást vetünk a global state-ra! Sorok kezelése jól megoldott, pointerek a PCB-ben a P descriptorban jól segítik … Már most megemlítem, egyes mai rendszerek futó processz sorokat is tartanak … Terminal queue head tail PCB NULL Vadász

44 A láncolt listák és a Context Switch
Sorfej Ready queue NULL head tail PCB2 PCB6 Run PCB1 A PCB1 processz időszelete letelt, preempcióval elveszik tőle a CPU-t Sorfej Ready queue NULL head tail PCB6 PCB1 Run PCB2 Round Robin! Ütemezésnél emlékezzenek erre! Vadász

45 Processz állapot - processz futási mód
A futási módok alapvetően a CPU jellemzői: felhasználói (normál, user) mód, kernel (privilegizált, védett) mód: ebben szélesebb címtartomány, bővebb utasításkészlet. Mivel a a CPU regiszterek is hozzátartoznak processz kontextushoz (dinamikus/volatile kontextus), mondhatjuk: a processzeknek is van futási módjuk. Különböztessük meg az állapotot a futási módtól! Van-e értelme processz futási módról beszélni? Szoktunk! Így magyarázzuk! Vadász

46 Futási mód - kontextus Emlékezz: módváltás=trap/kivételes esemény/IT
User mód User Address Space Processz kontextus Program, adat, verem Kernel mód Kernel Address Space Admin. adatok Kivétel kezelők, szolgáltató rutinok stb. System Stacks, IT handlerek, ütemező stb. Az előbbi állapot-állapotváltozás ábrák nem jelezték a futási módokat. A processz kapcsolás megfigyelhető rajtuk, de a processz kontextusról rendszer kontextusra váltás nem! Emlékezz: processz kontextusban (kontextuson) fut a CPU, mikor felhasználói módban felhasználói kód instrukciókat futtat kernel módban syscall/kivétel kiszolgáló rutin instrukcióit futtaja; Ekkor a futó processz tejes címtartományát kezeli. Rendszer kontextusban fut a CPU – ekkor mindig kernel módban – ha IT kiszolgálás instrukcióit futtaja. Ekkor egy-egy processz kontextusát csak közvetve érheti el. A processz javára Vadász

47 Processz állapotok (Bach szerint)
U Run K Run Ready Sleep Preem-ted Zombie fork ret exit wait signal schedule preempt (i)ret/exec syscall, it, trap trap, it, iret Nincs a jegyzetben! Ez az állapot diagramm jobb, a futási módokat is mutatja Sokminden magyarázható rajta. Kérdés, hogy szükség van-e a Preempted állapotra? Vadász

48 Processz állapotok U Run K Run Ready Sleep Zombie fork trap, it, iret
exit wait signal schedule preempt (i)ret/exec syscall, it, trap Mint az előző, de a Preempted állapot nélkül. Magyarázható rajta az egyszerű kontextus kapcsolás IT kiszolgálás, amit nem követ processz kontextus kapcsolás: Urun-it-Krun–iret-Urun A processz kapcsolások (persze, csak az egyik processz szemszögéből) 1. Urun-syscall-wait-Sleep (lemond a CPU-ról) 2. Urun-it-Krun-preempt-Ready (elveszik tőle a CPU-t) 3. Ready-shhedule-Krun-iret-Urun (megkapja a CPU-t) Látható, az IT-t, syscall-t megszakító IT …. Krun-it-Krun-iret-Krun … Látható a Sleep-signal-Ready átmenet … Látható a processz születés, terminálódás … Vadász

49 Taszk, processz, fonál Ismerjük a klasszikus processz fogalmat.
A modern OS-ek (és alkalmazásfejlesztők) támogatják a konkurens programozást, a párhuzamosságot … Fonál (thread): 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. További egységek programozói szemmel: rutinok, utasítások, instrukciók Vegyünk nagy lélegzetet! A klasszikus processz fogalommal is értelmeztünk multiprocesszálást … Párhuzamosságokat … Még egy CPU-s rendszeren is … De ennél a helyzet ma már bonyolultabb … A modern OS-ek (és alkalmazásfejlesztők) támogatják a konkurens programozást, a párhuzamosságot … Újabb fogalom a fonál (szál). Egy olyan entitás, amiben egy végrehajtási menet van, amit egy PC nyomon tud követni, amiben már nincs párhuzamosság … Amit lehet ütemezni (lehet számára CPU időt ütemezni). A fonalak valódi (ha van több CPU) vagy pszeudó párhuzamosságban futhatnak. Itt a taszk olyan futó program példány, amiben akár párhuzamosan futó fonalak lehetnek … Itt a taszk a „nagyobb egység” … A rutinok, utasítások, instrukciókra osztás most nem kell, de az eseménykezelésnél előjönnek … Vadász

50 Párhuzamosság A valódi párhuzamosság attól függ, hány processzor van … hány processzort használhat egy alkalmazás A klasszikus processz koncepciójú multitasking vagy multiprocessing rendszereken is van párhuzamosság Előzőn pszeudó Másodikon már valódi A fonál koncepció (többprocesszoros rendszeren) kiterjeszti a párhuzamosságot, de konkurens programozási módszereket igényel … Mielőtt ezeket tisztáznánk, alapfogalmakat … párhuzamosság - konkurencia … Vadász

51 Konkurencia Az alkalmazás fejlesztéséhez kapcsolódó fogalom
A konkurens programozás lehet rendszer szintű, vagy felhasználói szintű, vagy vegyes … Rendszer szinten a fonál kontrollhoz (kreálás, terminálás, attribútum lekérdezés-beállítás stb.) rendszerhívások biztosítottak A kernel „ismeri” a fonalakat, allokál nekik CPU-t, ütemezi őket, nyilvántartja állapotukat stb. Felhasználói szinten a fejlesztőhöz adott RTL rutinok végzik a fonál kontrollt (kreáció, megszüntetés, állapot nyilvántartás, ütemezés). Olcsóbb. A kernelnek nincs is tudomása a fonalakról. Miután felhasználói szintről a CPU allokálás védelmi problémákhoz vezetne, nem biztos, hogy valódi párhuzamosságot ad. De teljesítménynövelést azért adhat (a saját fonalak szinkronizációjával, ütemezésével) Dual konkurencia: a fonál támogatás funkcionalitása megoszlik … Ez saját terminológia. Nem biztos, hogy minden szakember átveszi … A konkurrencia: olyan programozási lehetőségek, melyek lehetővé teszik a későbbi párhuzamosságot. Ez az, ami meghatározza a lehetséges legnagyobb párhuzamosságot. Vadász

52 Taszk, processz, fonál Ellentmondásos a terminológia
Taszk vagy processz? (task, process) Fonál, szál, könnyűsúlyú processz (thread , lightweight process: LWP) Felhasználói szintű fonál (user thread) Kernel fonál (kernel thread) Kernel támogatott felhasználói fonál (kernel supported user thread) Taszk- processz, melyik „nagyobb”? Most a taszk, de a Real Time OS-ben pont fordítva lesz … Az irodalom mindezeket használja … Vadász

53 A kernel fonalai Nem tartozik felhasználói taszkokhoz
Kernel kontextusuk van A kernel menedzseli őket (kreáció, megszüntetés, állapot nyilvántartás, ütemezés, CPU allokálás és kapcsolás stb.) Viszonylag olcsó a menedzselésük Kernel funkciókat látnak el Ide tartoznak a kernel szintű taszkok kernel kontrollált fonalai is (ezeknek már taszk kontextusuk van) Eddig így tárgyaltuk: egy fonál egy taszkhoz tartozik … De … Tudjuk, mi a kernel kontextus! Az olcsóbb kontextus-váltásnál erre a váltás … Vadász

54 Kernel támogatott fonalak
Ezeket hívják (gyakran) könnyűsúlyú processzeknek (LWP) is Taszkhoz rendeltek, de a kernel ismeri őket Rendszerhívások kellenek a kontrolljukhoz (kreáció, megszüntetés, attribútum kezelés) A kernel nyilvántartja állapotukat, allokál nekik CPU-t, ütemezi és kapcsolja őket Viszonylag drága a menedzselésük Osztoznak a taszk kontextusán, erőforrásain Felhasználói taszkok ilyen fonalai felhasználói módban futnak Vadász

55 Felhasználó kontrollált fonalak
A fejlesztő RTL rutinjait használva programozzuk őket (POSIX pthreads) A kernel nem is tud róluk A RTL rutinokkal kreáljuk, szinkronizáljuk, ütemezzük, kapcsoljuk őket. Állapotukat is csak a taszk tartja nyilván. Menedzselésük olcsó (nem kellenek rendszer-hívások) Osztoznak a taszk kontextusán (erőforrásain) A taszkhoz allokált processzoron is osztoznak, azaz csak pszeudó párhuzamosságban futhatnak. Természetesen felhasználói módban futnak Kérdés: lehetséges-e taszk, amiben vannak kernel támogatott fonalak, ugyanakkor felhasználó kontrollált fonalak is? A válasz: igen. Vadász

56 Taszk, K kontrollált fonalakkal
Fut Fut fonál1 fonál2 Blokkolt Ready Blokkolt Ready A taszknak nincsenek állapotai. A fonalaknak viszont vannak. A fonalak (LWP) ütemezését - akár több CPU-ra - a scheduler végzi. Vadász

57 A kernel nem is tud a fonalakról.
Taszk, U fonalak Run Vannak taszk és fonál állapotok is. Run taszkállapotban mikor egy fonál blokkolódik, a taszk kiválaszt másikat és annak adja a CPU-ut. Ready taszkállapotban legalább egy fonál futásra-kész. Blokkolt taszkállapotban nincs kész fonál. fut fut bl kesz bl kesz Ready Blokkolt A kernel nem is tud a fonalakról. Vadász

58 A folyamat kontextus, processz menedzsment, processz állapotok Vége
OPERÁCIÓS RENDSZEREK A folyamat kontextus, processz menedzsment, processz állapotok Vége