OPERÁCIÓS RENDSZEREK A folyamat kontextus, processz menedzsment, processz állapotok 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 2 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. Vadász 3 1
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... Vadász 4 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 Vadász 5 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. Vadász 6 2
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) Vadász 7 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 Kernel mód Kernel Address Space Processz kontextus (program, adat, verem) Admin. adatok Kivétel kezelők, szolgáltató rutinok stb. A processz javára System Stacks, IT handlerek, ütemező stb. Vadász 8 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 Vadász 9 3
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. Vadász 10 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 Vadász 11 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 Vadász 12 4
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. Vadász 13 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) Vadász 14 Unix processz kontextus adatstruktúrái u-area Processzenkénti region table Közös region table Process Table proc-structure Memória Vadász 15 5
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. Vadász 16 Unix processz kontextus komponensek A kontextus statikus része Felhasználói szintű kontextus Program szöveg Adatok Veremtár Osztott adatok Rendszer szintű kontextus statikus része Process Table bejegyzése U Area Processzenkénti Region Table A kontextus dinamikus (volatile)része Keret a 3. rétegnek Keret a 2. rétegnek Keret az 1. rétegnek Felhasználói szint Vadász 17 Ö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? Vadász 18 6
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.) Vadász 19 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 20 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 Vadász 21 7
A kooperáció A kooperáció kiváltó oka 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. Vadász 22 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. Vadász 23 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. Vadász 24 8
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. Vadász 25 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 26 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()... Vadász 27 9
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! Vadász 28 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. Vadász 29 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 */ } Vadász 30 10
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). main() { int i; És itt? for (i=0; i<3; i++) fork(); } Vadász 31 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. Vadász 32 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); Vadász 33 11
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) Vadász 34 Esettanulmányok Nézzék a http://www.iit.uni-miskolc.hu/~vadasz/geial202/peldaprogramok/ 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 35 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 36 12
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. Vadász 37 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 CPUn 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. Vadász 38 Processz állapotok, állapotátmenetek futó sleep/wait/request preempt schedule/run blokkolt signal/assign várakozó kész 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 Vadász 39 13
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". Vadász 40 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! Vadász 41 Egy bővebb - de általános - állapot diagramm running exit zombie wait preempt-schedule delete signal create blocked ready non existent suspend resume suspend suspend resume suspended blocked signal suspended ready Vadász 42 14
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! Ready queue Sorfej head tail PCB PCB NULL MT1 head queue tail NULL Disk1 head queue tail PCB PCB NULL Blokkolt processzek sorai Terminal queue head tail PCB NULL Vadász 43 A láncolt listák és a Context Switch Run queue Ready queue Sorfej head tail Sorfej head tail PCB1 PCB2 NULL PCB6 NULL A PCB1 processz időszelete letelt, preempcióval elveszik tőle a CPU-t Run queue Ready queue Sorfej head tail Sorfej head tail PCB2 PCB6 NULL PCB1 NULL Vadász 44 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! Vadász 45 15
Futási mód - kontextus Emlékezz: módváltás=trap/kivételes esemény/it User mód User Address Space Kernel mód Kernel Address Space Processz kontextus Program, adat, verem Admin. adatok Kivétel kezelők, szolgáltató rutinok stb. A processz javára System Stacks, IT handlerek, ütemező stb. Vadász 46 Processz állapotok (Bach szerint) U Run syscall, it, trap trap, it, iret (i)ret/ exec ret Zombie exit K Run preempt Preem -ted wait schedule Sleep signal Ready fork Vadász 47 Processz állapotok trap, it, iret syscall, it, trap U Run (i)ret/ exec Zombie exit wait K Run schedule preempt Sleep signal Ready fork Vadász 48 16
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 Vadász 49 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 Vadász 50 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 Vadász 51 17
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) Vadász 52 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) Vadász 53 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 54 18
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 Vadász 55 Taszk, K kontrollált fonalakkal Taszk 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 56 Taszk, U fonalak 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. Blokkolt Run fut fut bl kesz bl kesz Ready A kernel nem is tud a fonalakról. Vadász 57 19
OPERÁCIÓS RENDSZEREK A folyamat kontextus, processz menedzsment, processz állapotok Vége 20