Processzuskezelés Processzusok, alapfogalmak

Processzuskezelés Processzusok, alapfogalmak
Processzusok kommunikációja Klasszikus IPC problémák Processzusok ütemezése

Alapfogalmak (1) A processzus vagy folyamat (process, job, task) egy végrahajtás alatt levő program. A címtartomány memoriaregiszterek azon sorozata, amelybe egy adott processzus írhat vagy amelyből olvashat. A processzustáblázat olyan, az adott processzushoz kapcsolt vektor vagy láncolat, amely a címtartomány által nem tartalamazott, de a processzussal kapcsolatos egyébb információkat foglalja magában. Egy időosztásos rendszer processzusát tehát annak címtartománya (memóriatérképe) és processzustáblázatbeli tartalma alkotja.

Alapfogalmak (2) A parancsértelemző (shell) a számítógép operációs rendszerének kulcsfontosságú processzusa. Egy processzus (a szülőprocesszus) létrehozhat egy vagy több új processzust (gyermekprocesszusokat). Ez a hierarchikus processzusrendszer fastruktúraként ábrázolható. Az elengedhetetlen processzusok közötti kommunikációt például egy pszeudofájl vagy a csőrendszer (pipe) biztosítja. Egy többfelhasználós rendszerben a felhasználó által indított processzus azonosítójához mindenképpen kapcsolódik az őt indító felhasználó azonosítója (user id).

Alapfogalmak (3) Rendszerhívások és szignálok
A processzusok és az operációs rendszer közötti kapcsolatot a szignálok és a rendszerhívások biztosítják. A szignál a hardver-megszakítások szoftvermegfelelője. Az operációs rendszer és a felhasználói programok közös érintkezési területe (inbterface) egy kiterjesztett parancsokból álló halmaz, a rendszerhívások (system calls) halmaza. A többfeladatos operációs rendszer által kezelt rendszerhívásoknak mindenképpen szüksége van az időszerű processzek azonosítójára (process id vagy pid).

Alapfogalmak (4) Rendszerhivások és szignálok
A rendszerhívások általában a következő osztályokba sorolhatók processzuskezelő rendszerhívások szignálkezelő rendszerhívások fájlkezelő rendszerhívások katalóguskezelő rendszerhívások a védelem rendszerhívásai az időkezelés rendszerhívásai. A rendszerhívások végrehajtása erősen gépfüggő, és áltlában assembly nyelben fogalmazódik meg. A renszerhívásokat tartalmazó eljáráskönyvtár általában lehetővé teszi, hogy C nyelvű programokból rendszerhívásokat hívjunk meg.

Alapfogalmak (4) Processzuskezelő rendszerhívások a UNIX alapú rendszerekben

Alapfogalamak Párhuzamosságok a modern számitógépes rendszerekben
A harmadik generációs számítógépek jelentős technikai újítási voltak* a multiprogramozás (a memóriát szeletekre particionáljuk, és minden particióhoz egy-egy feladatot rendelünk) a háttértárolás (spooling - simultaneous peripheral operation on line) az időosztás (timesharing), a multiprogramozás olyan változata, amikor minden felhasználónak saját on-line terminálja van. A számítógépek negyedik generációjával bevezetett újítások* munkaállomások kialakítása és hálózatba kötése felhasználóbarát szoftverek hálózati operációs rendszerek és osztott operációs rendszerek kilalkulása. *természetesen az operácós rendszerek tekintetében.

Alapfogalamak Párhuzamosságok a modern számítógépes rendszerekben
Egy multiprogramozású rendszerben a központi egység egyik programról a másikra ugrik, ezeket a másodperc törtrészére indítja, majd megszakítja azokat. Annak ellenére, hogy minden időpillanatban a központi egység csak egy processzussal foglalkozik, egy másodpercen belül több folyamattal is előrehaladhat, és a felhasználó úgy érezi, ezek a folyamatok párhuzamosan hajtódnak végre. Ám ez, mint láttuk, csak egy látszólagos párhuzamosság. A valódi párhuzamosság azt jelenti, hogy egy többprocesszoros rendszerben több központi egység osztja ugyanazt a memóriaterületet. Az operációs rendszerek fejlesztői kidolgozták a szekvenciális processzusok modelljét, amely megkönnyíti a párhuzamosságok kezelését.

Bevezetés Processzus modell - egyprocesszoros rendszer
Minden futtatható szoftver a számítógépen, általában maga az operációs rendszer is, szekvenciális processzusok sorozata. A processzus, mint egy program futó példánya, a következő összetevőkből áll: utasításszámláló regisztrek változóinak értékei. Minden processzusnak saját virtuális központi egysége (CPU) van. A valóságban a CPU processzusról processzusra kapcsol - tehát multiprogramozásról van szó.

Bevezetés processzus modell (2)
Négy független, szekvenciális processzus elméleti modellje, processzusonkénti utasitásszámlálóval

Bevezetés processzus modell (3)
Négy program multiprogramozása, egy utasításszámlálóval

Bevezetés Processzus modell (4)
A processzusok nem állandó sebességgel haladnak előre a végrehajtásban, ezért egy esetleges újraindításkor nem ismételhető meg az időosztás. A processzusokba nem szabad belső időzítéseket beépiteni, de szükség van egy időosztásos (scheduling) algoritmusra, amely a megfelelő időpillanatban felfüggeszti a futó processzust és egy másikat indít, vagy intít újra. A processzus tehát egy tevékenység, amelynek van programja bemenő és kimenő adatai állapota.

Bevezetés Processzus modell
Példa A számítógépes szakember anyuka (CPU) süteményt készít (főprocesszus) a születésnapi ünnepségre. Rendelkezésére áll a recept (program), a hozzávalók (bemenetek), és hozzákezd a sütéshez (a főprocesszus futó állapotba kerül). Ebben a pillanatban a fia belép, és közli, hogy elesett. Az anyuka abbahagyja a sütést, és a fia segítségére siet (magasabb prioritású processzus adódott) folytatása következik...

Bevezetés Processzus modell
az anyuka abbahagyja a sütést (a főprocesszust felfüggeszti) feljegyzi, hol áll a recept lépéseiben (a pillanatnyilag futó processzus állapotát elmenti) ellátja a fia sebeit az elsősegélynyújtás szabályai alapján (a magasabb prioritású processzt hajtja végre annak programja alapján). Amikor a sebet ellátta (befejeződütt a magasabb proiritású processz) az anyuka (CPU) visszatér a sütéshez (főprocesszus), és folytatja azt ott ahol abbamarad (az elmenetett állapot alapján folytatódik a főprocesszus). A kész sütemény lesz a processzus kimenete.

Processzushieararchiák
A fölöttébb egyszerű rendszerekben, illetve az egy alkalmazás futtatásásra alkalmas rendszerekben nincs szükség processzushierarchiák létrehozására. Öszzetettebb rendszerek esetében a processzusok létrehozásának és megszüntetésének módszereit ki kell dolgozni, ezért az operációs rendszerek általában tartalmazzák a következő rendszerhívásokat processzuslétrehozás memóriába történő betöltés indítás. Meg kell határozni az új processzusok létrehozásának módját is, algoritmusok segitségével. A UNIX alapú rendszerekben általában a fork nevű rendszerhívás szolgál a processzek létrehozására.

Processzushieararchiák

Processzusállapotok Egy processzus egy adott pillanatban a következő három állapot egyikében lehet futó - az adott pillanatban éppen használja a CPU-t (running) futáskész - készen áll a futásra, mert időlegesen leállították, hogy egy másik processzus futhasson (ready) blokkolt - bizonyos külső esemény bekövetkezéséig nem képes futni (blocked). A futó és futáskész állapot csak abban különbözik, hogy a másodikban pillanatnyilag nem áll a processzus rendelkezésére szabad CPU kapacitás. A blokkolt állapot csak akkor szűnik meg, ha a külső, a blokkolást előidéző körülmény ezt újra megengedi. A processzusállapotok között négy különböző átmenet lehtséges:

Processzusállapotok közötti átmenetek
1. A processzus input miatt blokkoolt 2. Az ütemező másik processzust választott 3. Az ütemező ezt a processzust választotta 4. A bemenet elérhető lett

Processzusállapotok - ütemezés
Hogyan kezelhetők a processzus állapotváltásai, a megszakítások, a processz indítás és megszüntetés? A UNIX alapú renszerek alsó szintje, az ütemező, (scheduler) kezeli a megszakitásokat és az ütemezést. Az operációs rendszeren belül a további processzusszervezés szekvenciális jellegű. Az ütemező egyúttal a megszakításokat és a processzusok közötti kommunikációt is felügyeli.

Processzusállapotok - példák
1. Példa a UNIX rendszerekből cat file1 file2 | grep fontos A cat parancs összekapcsolja a file1 és a file2 fájlok tartalmát. A grep parancs a kapott fájlból kiválaszt minden olyan sort, amely tartalmazza a fontos szót. A processzusok végrehajtásának relatív sebességétől függően előfordulhat, hogy a grep parancsot végrehajtó processzus már futásra készen áll, de az összekapcsoló processzus még nem biztosította számára a bemenetet. Igy a grep blokkolt állapotba kerül. 2. Bármely processzussal előfordulhat, hogy futása közben az operációs rendszer más processzusnak osztja ki a CPU-t, es ezáltal futáskész állapotba kerül.

Processzusok megvalósitása
A processzusmodell lényege, hogy az opeációs rendszer processzusonként egy processzustáblázatot hoz létre és a processzus élettartama alatt azt kezeli. A processzustáblázat tartalma általában utal a processzus állapotára utasitásszámlálójára veremmutatójára memóriatérképére megnyitott fájljainak állapotára elszámolási és ütemezési információira egyéb olyan információkra, amelyeket a processzus esetleges felfüggesztésekor tárolunk azzal a céllal, hogy a processzust újraindíthassuk.

Processzusok megvalósitása Processzuskezelő mezők a processzustáblázatban
A legtöbb operációs rendszer a processzusokat, memóriát és fájlokat elkülönítve kezeli, ezért a processzustáblázat mezői is e három csoportba tagolódnak. A processzustáblázat memóriakezelő mezői általában a következő információkat tartalmazzák * regiszterek *utasitásszámláló * programállapot szó *veremmutató * processzusállapot *processzus inditási ideje *felhasznált CPU idő *gyermek CPU ideje * következő ébresztés ideje *mutató az üzenetsorra * függö jelző bitek *processzusazonosító * különböző jelző bitek

Processzusok megvalósitása Megszakítások
Hogyan működik egy, egy központi egységgel és több ki- és bemeneti egységgel rendelkező rendszer ütemezője? Minden egyes B/K eszközosztály kapcsolatban áll a memória alsó részében elhelyezkedő megszakításvektorral. Ez a vektor tartalmazza a megszakítást kiszolgáló eljárás címét. A következő sorrend mutatja hogyan cselekszik az operációs rendszer alsó szinje (az ütemező általábnan), amikor megszakítás következik be. Megjegyzés: Az 1. és 2. lépést általában hardvermegszakítások kezelik. A 3., 4. és 9. lépést assembly utasitások kezelik. Az 5-8. lépéseket általában C eljárások hajtják végre.

Processzusok megvalósitása Megszakítások vázlatos leirása
1. A hardver verembe teszi az utasításszámlálót és más információkat 2. A hardver a megszakításvektorból betölti az új utasításszámlálót 3. Az assembly eljárás elmenti a regiszterek tartalmát 4. Az assembly eljárás beállítja az új vermet 5. A C megszakitáskezelő bemenő adatokat olvas és tárol 6. Az ütemező a várakozó processzust futáskész állapotba helyezi 7. Az ütemező a futáskész várakozók közül kijelöl egyet futásra 8. A C eljárás visszatér assembly kódba és elindítja az új aktuális processzust

Pocesszusok megvalósitása Szálak
A hagyomámányos processzusszervezésben egy vezérlési szál és egy uatsításszámláló volt. A modern operációs rendszerek támogatják a processzuson belüli töbszörös vezérlési szálak kiszolgálását. Ezekt a szálakat nevezzük könnyűsúlyú processzusoknak vagy egyszerűen szálaknak.

Pocesszusok megvalósitása Szálak -példák
Fájlszerver processzus. A szerver az aktuális fájlba történő íráskor/olvasáskor hatékonyságnövelés céljából gyorsírótárat (cache) használ. Ha az OR blokkolja is processzust, több szálon fogadhat továbbra is kéréseket a fájllal kapcsolatban. Egyszálas rendszernél ez nem lehetséges, mert különböző processzek különálló szálai nem osztozhatnak ugyanazon a gyorsírótár-tartományon. A WEB oldalak több kis összetett képből állnak. Ezek letöltése különálló kapcsolatteremtést jelent, és különálló szálakon futó kapcsolatként lényegesen növelhető a letöltés teljesítménye.

Pocesszusok megvalósitása Szálak magvalósitása
Ha ugyanazon címtartományt több szál használja, akkor néhány processzkezelő mező szálanként értendő, és a különálló száltáblázat tartalmaz önálló utasításszámlálót (mert a szálak felfüggeszthetők és újraindíthatók), regisztereket (amelyeket szál-felfüggesztéskor ugyancsak elmentünk), állapotjelzőt (mert a szálak is lehetnek fuót, futáskész és blokkolt állapotban).

Pocesszusok megvalósitása Szálak kezelése
Ha az OR nem vesz tudomást a szálak létezéséről, akkor azok felhasználói hatáskörben vannak (azaz például egy blokkolásra készülő szál maga jelöli ki az utódját). Ilyen feléhasználói szintű szálkezelő csomag például a POSIX P-szálak csomagja. Ha az OR kezeli a szálakat, akkor a kezelés a kernel feladata, amely a szálak ütemezését a processzustáblázathoz hasonló, minden futó szálra vonatkozó száltáblázat segítségével végzi. A szálak közötti átkapcsolás a felhasználói szintű szálkezelésnél gyorsabb, viszont egy szál blokkolása ennél a módszernél a teljes processzus blokkolásához vezet. Ezért mindkét módszert (a felhasználói- és a kernel-kezelést is) alkalmazzák, illetve azok hibrid változataival kisérleteznek.

Pocesszusok megvalósitása Szálak kezelése - nyitott kérdések
A szálak alkalmazásakor felmerülő nyitott kérdések közül néhány: Milyen hatása van a többszálas szülőprocesszusban kiadott, gyermekprocesszust létrehozó rendszerhivásnak? A gyermekpocesszus megörökli a szálakat is? Ha a szülő- ás a gyermekprocesszus is többszálas, és egy B/K rendszerhívás blokkolja a szálat, csak a szülő-szál blokkolodik? Csak a gyermekszál, vagy mindkettő? Ha több szál osztozik ugyanazon adatsruktúrán, természetesen ugyanazon a processzuson belül, akkor előfordulhat hogy egyik szál lezár egy fájlt, egy másik szál pedig még olvas belőle? Ha egyazon processzus két különböző szála majdnem egyidőben igényel újabb memóriaterületet, mindkettő külön-külön kap új területeket? (Nem többszálas rendszereknél gyakran összeomlik az operációs rendszer, ha még kielégítetlen igénylés alatt újabb érkezik. )

Pocesszusok megvalósitása Szálak kezelése
Az olyan hibajelzéseket, amelyeket a processzus egyik szála globális változóba ír (pl. UNIX-ban), felülírhatja ugyanazon processzus másik szála. A szignálok között vannak szálspecifikusak. Ha például a többszálas rendszer kernelje a processzus valamely száljától ALARM hivást kap, tudnia kell az eredményszignált a megfelelő szálon átadni. A felhasználói szintű szálkezelésnél viszont az a probléma áll elő, hogy a rendszer processzusonként csak egy riasztást képes kezelni, ugyanakkor a processzus több száljának akár egyidőben is szüsége lehet a riasztásra. Többszálas processzus szálankénti vermelést igényel. Verem-túlcsordulásnál a kernelnek érzkelnie kellene melyik szál verméről van szó, és csak azt autómatikusan növelnie. Ez nehezen oldható meg.

Processzusok kommunikációja
A többfeladatos rendszerek alapkövetelménye, hogy egy megszakítások nélküli, jól struktúrált módszert biztosítson a processzusok közötti kommunikációhoz, azaz az IPC (Interprocess Communication) feladatkörhöz. Az operációs rendszereket építő szakembereknek a következő feladatokat kell megoldaniuk hogyan továbbíthat egyik processzus információt egy másiknak biztosítani kell hogy két vagy több processzus ne keresztezze egymás útját ha kritikus tevékenységbe kezdenek ha a processzusok munkája között függőség áll fenn, akkor a sorrendiséget meg kell oldani.

Processzusok kommunikációja Versenyhelyzetek
Ha kettő vagy több processzus olvas vagy ír megosztott adatokat és a végeredmény attól függ, hogy ki és pontosan mikor fut, versenyhelyzet áll elő. A megosztott adatterület lehet a memóriaterület vagy közösen használt fájl. A versenyhelyzeteket tartalmazó programok nyomonkövetése (debugging) bonyolult feladat, és előfordulhatnak időnként furcsa és megmagyarázhatlan dolgok programfuttatás közben. Tanácsos elkerülni a versenyhelyzeteket. Kerüljük el a megosztott memória, megosztott fájlok, és egyéb megosztott erőforrások egyidejű elérését több processzus irányából.

Processzusok kommunikációja Versenyhelyzetek. Kritikus szekciók
A versenyhelyzetek megelőzésére szükségünk van a kölcsönös kizárásra, azaz arra, hogy más processzusokat távol tratsunk a közös erőforrásoktól, amig azokat egy futó processzus használja. Az operációs rendszerek tervezésének fontos szempontja, hogy jól megszerkesztett primitiv műveleteket alkalmazzanak a kölcsönös kizárás eléréséhez. A programnak azt a részét, amelyben megosztott memóriát használ, kritikus területnek, illetve kritikus szekciónak nevezzük. Ha megszervezhető, hogy két vagy több processzus ne legyen egyidejűleg kritikus szekcióban, akkor ezzel elkerülhető lesz a versenyhelyzet is.

Processzusok kommunikációja Kritikus szekciók
Párhuzamosan futó processzusok akkor oszthatják korrekten és hatékonyan a közös adatterületeket, ha: 1. két processzus nem lehet egyidejűleg a saját kritikus szekciójában, 2. nem szabunk előfeltételeket a sebeségekkel és a CPU-k számával kapcsolatban, 3. egy, a saját kritikus szekcióján kivül futó processzus sem blokkolhat más processusokat, 4. egy processusnak sem kell örökké várnia, hogy belépjen a saját kritikus szekciójába.. Lássunk néhány megközelítést, a problámafelvetéstől, a megoldás modján keresztül a felmerülő nyitott kérdésekig.

Processzusok kommunikációja Kölcsönös kizárás
A kölcsönös kizárás fogalma azt jelenti, hogy mialatt egy processzus a saját kritikus szekciójában a megosztott erőforrást aktualizálja, ne legyen más olyan processzus, amely saját kritikus szekciójába lép, agyanazt az erőforrást használná, és bajt okozhatna.

Processzusok kommunikációja Kölcsönös kizárás Magszakítások tiltása
A megoldás Minden processzus letiltja az összes megszakítást (az óramegszakitásokat is), mihelyt belép saját kritikus szekciójába, és újraengedélyezi, mielőtt elhagyja azt. (A CPU csak órajelre vagy megszakításra kapcsol processzusról processzusra.)

Nyitott kérdések -Problémák Felhasználói processzusoknak nem helyes olyan felhatalmazást adni, hogy kikapcsolhassák a megszakításokat. Többprocesszoros rendszereknél ez a tiltás csak egyik (a tiltást végrehajtó) CPU-ra vonatkozik. Gyakran a kernelnek is szüksége van letiltásokra (pl. a futáskész processzusok listájának változtatásakor). Ezt az állapotot egy másik processzustól érkező letiltás megzavarhatja, és versenyhelyzet alakulhat ki.

Tanulság A megszakítások tiltása hasznos lehet az operációs rendszereken belül, de mint kölcsönös kizárási mechanizmus nem ajánlható a felhasználói processzusok esetében.

Processzusok kommunikációja Kölcsönös kizárás Zárolásváltozók
Megoldás A zárolásváltozók alkalmazása egy szoftvermegoldás. Mielőtt egy processzus belép a saját kritikus szekciójába, először ellenőriz egy zárolásváltozót (lock variable), amely eredetileg 0 értéket vesz fel (például). Ha a zárolásváltozó értéke 0, akkor 1-re állitja azt, és belép a kritikus szekcióba. Ha zárolásváltozó értéke 1, akkor a processzus várakozik (futáskész állapotba kerül), amig a 0 értéket nem regisztrál. Tehát a fenti példában, a zárolásváltozó értéke 0, ha egy processzus sincs a saját kritikus szekciójában, és 1, ha valamely processzus kritikus szekcióban van.

Processzusok kommunikációja Kölcsönös kizárás Zárolásváltozók
Nyitott kérdések Mi történik, ha az egyik processzus 0 zárolásváltozót olvas, kritikus szekcióba lép, de még mielőtt a zárolásváltozót 1-re állitja, megteszi ezt egy másik processzus is? (A már korábban emlitett háttérkatalógus példa). Tanulság A fenti probléma akkor sem kerülhető el, ha először a processzus kiolvassa a zárolásváltozó értékét, és azt ellenőrzi az 1-re történő áírás előtt. Még ekkor is előfordulhat versenyhelyzet.

Processzusok kommunikációja Kölcsönös kizárás tevékeny várakozással Szigorú váltogatás
Bevezetünk egy 0 kezdőértékű turn egész változót, amely nyomon követi, mely processzus lép legközelebb a kritikus szekciójába, és vizsgálja vagy aktualizálja a megosztott memóriát. Azt a módszert, amikor folyamatosan tesztelünk egy változót egy bizonyos értékének bekövetkeztéig, tevékeny várakozásnak nevezzük.

Egy javasolt, C nyelben iródott megoldás a turn változó használatára:
Processzusok kommunikációja Kölcsönös kizárás tevékeny várakozással Szigorú váltogatás Megoldás Egy javasolt, C nyelben iródott megoldás a turn változó használatára: while (TRUE) { while (turn!=0) /*várakozás*/; critical_region(); turn=1; noncritical_region(); } while (TRUE) { while (turn!=1) /* várakozás */; critical_region(); turn=0; noncritical_region(); }

Nyitott kérdések A tevékeny várakozás általában pazarolja a CPU időt, ezért csak akkor ajánlott, ha a várakozás várhatóan rövid lesz. Ha az egyik processzus lassúbb mint a másik, a szigorú váltogatás nem hatékony (egy processzus 1 értéken hagyhatja a turn értéket, pedig már befejezte a kritikus szekcióban a munkát, de még nem váltott) Ez a helyzet sérti a kritikus helyzetek elkerülésére szabott 3. feltételt (a lassúbb processzus blokkolt egy olyat, amely nincs kritikus szekcióban). A háttértaroló példa: a gyorsabb processzus nem tud nyomtatni, mert a lassúbb mással van elfoglalva.

Tanulság Ez a megoldás megköveteli, hogy két processus szigorúan váltakozva lépjen a saját kritikus szekciójába (például így adhatnak át egymásnak processzusok fájlokat a háttevékenységekhez, de ezt kétszer egyik processzus sem ismételheti közvezlen egymásutánban.) A módszer elkerüli a versenyhelyzeteket, egyszerű, de az említett 3. követelmény miatt nem komoly jelölt az alkalmzásokban.

Processzusok kommunikációja Kölcsönös kizárás tevékeny várakozással Peterson megoldása
A megoldás A váltogatás ötletét ötvözve a zárolás- és figyelmeztető-változók alkalmazásával T. Dekker szoftvermegoldást adott a kölcsönös kizárás problémájára, és eközben nem alkalmazott szigoró váltogatást (1965.). G.L. Peterson 1981-ben egy egyszerűbb algoritmussal oldotta meg azt a problémát. A következő algoritmus ANSI C-ben irodott. A definiált és használt függvényeket függvényprototipusokkal helyettesítjük.

#define FALSE 0 #define TRUE 1 #define N 2 int turn; int interested[N]; void enter_region(int process); { int other; other=1-process; interested[process]=TRUE; turn=process; while (turn = = process && interested[other]= = TRUE) } void leave_region(int process); interested[process]=FALSE; /*a processzusok szuáma*/ /*ki következik?*/ /*kezdetben minden érték 0 (FALSE)*/ /*a process vagy 0 vagy 1*/ /*a másik processzus sorszáma*/ /*a process ellenkezője*/ /*mutatja, hopgy érdekeltek vagyunk*/ /*’áll’ a zászló*/ /*üres utasitás*/ /*process: ki hagyja el*/ /*mutatja a kritikus szekció elhagyását*/

Nyitott kérdések Ha két processzus majdnem egyszerre hívja meg az enter_region-t, és mindkettő beírja a processzusszámát a turn-be, az leső elvész, a második megmarad. Ha az 1. processzus ír be utoljára, akkor a turn érétke 1. Amikor mindkét processzus elér a while utasitáshoz, a 0. processzus a várakozó ciklust nullászor hajtja végre és a kritikus szekciójába lép, az 1. processzus ismételget de nem lép a kritikus szekciójába.

Processzusok kommunikációja Kölcsönös kizárás tevékeny várakozással A TSL utasítás
A megoldás Az algoritmus hardversegítséggel működik. A legtöbb többprocesszoros rendszer rendelkezik egy TEST AND LOCK (TSL) utasítással. A TSL beolvassa a memóriaszó tartalmát egy regiszterbe, és egy nemnulla értéket ír erre a memóriacímre. A szó kiolvasása és a tárolási művelet nem választható szét, az akció befejezéséig ezt a memóriaszót más processzor nem érheti el. A CPU a TSL paranccsal zárolja a memóriabuszt és a művelet befejezéséig megtíltja, hogy más CPU hozzzáférjen a memóriaterülethez.

Processzusok kommunikációja Kölcsönös kizárás tevékeny várakozással A TSL utasítás
A TSL egy megosztott lock változót használ. Ha a lock értéke 0, bármely processzus 1-re állíthatja azt, és ezután olvashatja, vagy felülírhatja a megosztott memóriát. Ha végzett, a processzus a lock változót újra 1-re állítja (egy egyszerű MOVE utasítással) A következő két programmodul egy fiktív assembly nyelvben íródott. Az első beállítja a TSL segitségével a lock értéket (enter_region:), a másik ‘üriti’ azt, és visszaadja a vezérlést a hívónak (leave_region:).

Processzusok kommunikációja Kölcsönös kizárás tevékeny várakozással A TSL utasíitás
| /átmásolja a lock-t a regiszterbe és a lock legyen 1/ | /a lock nulla volt?/ | /ha nem volt nulla, akkor be van állitva, igy ciklus legyen/ | /vissza a hivóhoz, beléptünk a kritikus szekcióba/ | /a lock legyen 0/ | /visszatérés a hivóhoz / enter_region: tsl register,lock cmp register,#0 jne enter_region ret leave_region: move lock,#0

Processzusok kommunikációja Kölcsönös kizárás tevékeny várakozással Összefoglaló
Minden, a kritikus szekciókon alapuló megoldásnál a processzusoknak a megfelelő időben kell hívniuk az enter_region és a leave_region modulokat. Peterson megoldása, és a TSL-t használó módszer is helyes, de mindkettő hibája a tevékeny várakozás. Ezeknek a módszereknek a lényege: ha egy processzus be akar lépni a saját kritikus szekciójába, először ellenőrzi, hogy a belépés engedélyezett-e. Ha nem, egy ciklusba lép, és azt ismételgtve vár, amíg engedélyt nem kap.

Miért kell tovébblépnünk a fejlesztésben?
Processzusok kommunikációja Kölcsönös kizárás tevékeny várakozással Összefoglaló Miért kell tovébblépnünk a fejlesztésben? A kölcsönös kizárás tevékeny várakozással pazarolja a CPU időt, és lehetnek váratlan hatásai. Vizsgáljunk meg egy számítógépet, amelyen egy magas prioritású H és egy alacsonyabb prioritású L processzus fut. Ha az ütemezési szabályok olyanok, hogy H mindig futni fog, ha futásrakész, akkor elősfordulhat a következő: L a kritikus szekciójában van, H pedig futásrakész állapotba kerül. H tevékeny várakozásba kezd, de L nem tudja elhagyni a kritikus szekvióját, hiszen rá, H ‘árnyékában’ nem kerülhet sor. Igy L a kritikus szekciójában marad, H pedig végtelenségig ismételget. A fenti esetet nevezik fordított proioritású problémának..

Processzusok kommunikációja Sleep és Wakeup
Léteznek olyan processzusok közötti kommunikációt szolgáló primitíek, amelyek anélkül blokkolnak, hogy elvesztegetnék a CPU időt, miközben a processzus a kritikus szekcióba történő belépésre vár. Ilyen egyszerű primitiv-pár a SLEEP és WAKEUP. SLEEP rendszerhívás, amely a hívót blokkolja (felfüggeszti), amíg egy másik processzus őt fel nem ébreszti A WAKEUP rendszerhivás egyetlen paramétere az a processzus, amelyet fel kell ébresztenie. Lehetőség van arra is, hogy a SLEEP és WAKEUP is rendelkezzen egy-egy paraméterrel, és ezek megfeleő összepárosításának elvén működjön a két rendszerhívás.

Processzusok kommunikációja Sleep és Wakeup A gyártó-fogyasztó probláma
A következő, gyártó-fogyasztó (összekötött tároló) probléma a SLEPP-WAKEUP pár alkalmazásának jó példája. Két processzus osztozik egy közös, rögzített méretű tárolón. A gyártó adatokat helyez el benne, a fogyasztó kiveszi azokat. A probléma akkor jelentkezik, ha a gyártó új adatot akar elhelyezni a telítődött tárolóba. A gyartó aludni megy, amig a fogyasztó egy vagy több elemet nem vesz ki, és a gyártót felébreszthetik. Ha a fogyasztó talál üres tárolót, ő megy aludni az ébresztésig, amikor is a gyártó elemekkel tölti fel a tárolót.

A SLEEP és WAKEUP hívásokat könyvtári rutinok hívásaként, C-ben mutatjuk. Az elemek tárolóba helyezését és kivevését általában az enter_item illetve remove_item eljárások végzik. Szükségünk van egy count nevű változóra, amely számon tartja az elemek számát a tárolóban. Az első modul a gyártó, a második a fogyasztó kódja.

#define N 100 int count = 0 void procedure(void) { while (TRUE) procedure_item(); if (count==N) sleep(); enter_item(); count=count+1; if (count==1) wakeup(consumer); } /*a rekeszek száma a tárolóban*/ /*az elemek száma a tárolóban*/ /*végtelen ciklus*/ /*a következő elem létrehozésa*/ /*ha a tároló tele van megyünk aludni*/ /*betesszük az elemet a tárolóba*/ /*növeljük az elemek számát a tárolóban*/ /*üres volt a tároló? */

void consumer(void) { while (TRUE) if (count==0) sleep(); remove_item(); count=count-1; if (count==N-1) wakeup(producer); consume _item() ; } /*végtelen ciklus*/ /*ha a tároló üres, megyünk aludni*/ /*kivesszük az elemet a tárolóból*/ /*csökken az elemek száma a tárolóban*/ /*tele van a tároló? */ /*kinyomtatjuk az elemet*/

Nyitott kérdések Előállhat a következő probléma: A fogyasztó a count-ban nullát talál. Az ütemező ebben a pillanatban felfüggeszti, a gyártót inítja, aki elemet tesz a tárolóba (count=1), a count előző nulla értéke miatt wakeup-pal ébreszti a fogyasztót. Az ébresztőjel elveszik, mert a fogyasztó logikailag nem alszik. Amikor a fogyasztó futásra kerül, az előző nulla miatt aludni megy. A gyártó eközben töltögeti a tárolót, és amikor az megtelik, ő is aludni megy. A gyártó és a fogyasztó is ettől kezdve örökre alszik.

Megoldási lehetőség Hogy az ébresztőjel ne veszhessen el, vezessünk be ébresztőt váró bitet. Az ébresztőt váró bit csak kiséri a az ébresztő jelet. (Ha több processzusról van szó, akkor előfordulhat, hogy az ébresztőt váró bitek számának növelésével sem tudunk megoldani problémákat.) A megoldás a szemaforok bevezetése, amelyekkel számolhatóak a függőben maradt ébresztések.

Processzusok kommunikációja Szemaforok
1965-ben E. W. Dijkstra javasolta a szemafor változótipus bevezetését, amely tipus nulla, ha nincs elmentett ébresztés, illetve pozitiv egész, utalva az elmentett ébresztések számára. A SLEEP és WAKEUP hívások általánositásai a DOWN és UP műveletek. A DOWN művelet például csökkenti a szemafor értékét, ha az pozitiv, tehát végrehajt egy tárolt ébresztést. Ha a szemafor 0, akkor a processzust altatja a DOWN meghívása nélkül. Az értékellenőrzés, az értékcsere, az altatás elemi műveletek, tehát a szemafort egyszerre nem érhetik el, és nem változtathatják (fontos szinkronizálási újítás). Az UP művelet hasonló módon működik (Az alvók közül általában véletlenszerűen válaszják ki az ébresztendőt).

Processzusok kommunikációja Szemaforok alkalmazása a gyártó-fogyasztó probléma esetében
Az UP és DOWN olyan rendszerhívásokként működik, amelyekben az OR tilt minden megszakítást, amig a szemafor értékét vizsálja. Több CPU esetében minden szemafort védeni kell zárolásváltozóval, TSL utasitás használatával. A példa három szemafort használ a full a teli rekeszeket számlálja az empty az üres rekeszeket számlálja a mutex biztosítja, hogy a gyártó és fogyasztó ne érje el egyidőben a tárolót. Bináris szemaforoknak nevezzük azokat, amelyek kezdőértéke 1, és azt biztosítják, hogy kettő vagy több processzus egyidejűleg ne lépjen kritikus szekcióba (jól szervezett szemaforokkal a kölcsönös kizárás biztosított).

#define N 100 typedef int semaphore; semaphore mutex = 1; semaphore empty = 1; semaphore full = 0; /*a rekeszek száma a tárolóban*/ /*a szemafor az int speciális fajtája*/ /*felügyeli a kritikus szekciók elérését*/ /*a tároló üres rekeszeinek a száma*/ /*a tároló tele rekeszeinek a száma*/

void producer(void) { int item; while (TRUE) procedure_item(&item); down(&empty); down(&mutex); enter_item(item); up(&mutex); up(&full); } /*a TRUE az 1 konstans*/ /*létrehoz valamit, amit a tárolóba lehet tenni*/ /*üres rekeszek száma csökken*/ /*belépés a kritikus szekcióba*/ /*betesszük az új elemet a tárolóba*/ /*elhagyjuk a kritikus szekciót */ /*tele rekeszek száma növekszik*/

void consumer(void) { int item; while (TRUE) down(&full); down(&mutex); remove_item(&item); up(&mutex); up(&empty); consume_item(item); } /*végtelen ciklus*/ /* tele rekeszek száma csökken*/ /* belépés a kritikus szekcióba */ /*kivesszük az elemet a tárolóból*/ /* elhagyjuk a kritikus szekciót */ /*üres rekeszek száma növekszik */ /*csinálunk valamit az elemmel*/

Processzusok kommunikációja Szemaforok alkalmazása
A szemaforok jól használhatók tehát a kölcsönös kizárás elérésére, a mutex segítségével, szinkronizációra, a full és empty segítségével. Ezek a szemaforok biztosítják, hogy bizonyos eseménysorozatok bekövetkezzenek, és hogy bizonyosak ne. A szemaforok széles körben elterjedtek, és ma is fejlesztik a velük kapcsolatos algoritmusokat. A szemaforok alkalmazásának buktatói: végtelenségig blokkolt állapotban maradhat mindegyik processzus - ezt nevezzük holtpontnak versenyhelyzetek és reprodukálhatatlan események következhetnek be. Ha nincsenek beépített szemaforok, akkor írhatunk azokat kezelő eljárásokat és kapcsolhatunk őket az eljáráskönyvtárakhoz.

Processzusok kommunikációja Monitorok
A szemaforok hiányosságait javítandó, magasabb szintű primitiveket vezettek be, és ezeket monitoroknak nevezték (Hoare, 1974-ben, Hansen, 1975-ben). A monitor eljárások, változók, adatszerkezetek együttese, amelyeket egy speciális modulba gyűjtenek egybe. A monitorok forrásnyelvi konstrukciók, a fordítóprogram pedig tudja, hogy a monitor eljárásait másképp kell kezelni, mint az egyszerű eljárásokat. (A monitor tehát programozási nyelvi fogalom, míg a szemaforok assembly nyelbe foglalt, DOWN és UP rendszerhívások által kezelt változók. )

A monitorok tulajdonságai: A processzusok bármikor hívhatják a monitorban levő eljárásokat, de nem érhetik el közvetlenül a monitor belső adatszekezeteit a monitoron kivül deklarált eljárásokból. Minden időpillanatban csak egy processzus lehet aktív egy monitorban, és ez lehetővé teszi a kölcsönös kizárást. A monitorok belépési pontjánál általában bináris szemaforok biztosítják a kölcsönös kizárást adó felfüggesztéseket. A blokkolásokat továbbá állapotváltozók biztosítják, valamint az őket kezelő WAIT és SIGNAL műveletek. Ezek hasonlítanak a SLEEP és WAKEUP műveletekhez, de velük nem fordul elő hogy az egyik processzus egy másik, aludni készülőt akar felébreszteni.

Hansen és Hoare megoldási eltérnek egymástól a SIGNÁLT követő eseménysorozatban (ez biztosítja, hogy ne legyen két aktív processzus a monitoron belül). Hoare szerint az egyiket függesszük fel, a másikat hagyjuk futni. Hansen szerint a SIGNAL-t végrehajtó processzust utasítsuk a monitor azonnali elhagyására - ezért a SIGNAL a monitor utolsó utasítása. Az állapotváltozók nem számlálnak és nem gyűjtik a szignálokat, mint a szemaforok. A példa a gyártó-fogyasztó probléma vázlata monitorokkal. Csak egy monitor eljárás aktív egyidőben, és a tárolónak most is N rekesze van. A kód egy fiktiv Pascal alapú nyelven írodott.

Processzusok kommunikációja Monitorok - gyártó-fogyasztó probláma(1)
monitor ProducerConsumer condition full, empty; integer count; procedure enter; begin if count=N then wait(full); enter_item; count:=count+1; if count=1 then signal(empty) end; procedure remove; if count=0 then wait(empty); remove_item; count:=count-1; if count=N-1 then signal(full) count:=0; end monitor;

Processzusok kommunikációja Monitorok - gyártó-fogyasztó probláma(2)
procedure producer; begin while true do produce_item; ProducesConsumer. enter end end; procedure consumer; ProducesConsumer. remove; consume_item;

Processzusok kommunikációja Monitorok, szemaforok - összefoglaló
A monitorokat és szemaforokat a kölcsönös kizárás problémájának megoldására tervezték. Egy vagy több CPU-ról van szó, amelyek mindegyike elérheti a közös memóriát. A szemaforkat a megosztottt memóriába helyezve, és TSL utasításokkal megvédve, elkerülhetőek a versenyhelyzetek. Ha olyan rendszerünk van, amelyben több, önálló memóriával rendelkező CPU van, és ezek például lokális hálózatra vannak kötve, az eddig ismertetett primitívek elvesztik jelentőségüket (használhatatlanok lesznek). A szemaforok alacsony szintűek, a monitorok pedig néhány programnyelvet kivéve, nem használhatók ebben az esetben. Hogyan oldjuk meg a gépek közötti információcserét?

Processzusok kommunikációja Üzeneztküldés
A processzorok kommunikációja üzenetküldássel a SEND és RECEIVE primitivek segítségével, renszerhívásokkal történik (úgy mint a szemaforok esetében). Beilleszthetők a könyvtári eljárások közé, például így: send(destination, &message); receive(source, &message); send üzenetet küld a célállomáshoz, receive üzenetet fogad a forrástól (vagy ANY-től, ha a fogadót nem érdekli a forrás).

Processzusok kommunikációja Üzeneztküldés. Tervezési szempontok
Az üzenetküldő rendszerek tervezési szempontjai Az üzenet elvesztése ellen nyugtázó üzenet bevezetésével védekeznek Ha az üzenet megérkezik, de a nyugta elveszik, a küldő újra küldi. Ezért az eredeti és újraküldött üzeneteket (esetlegesen sorszámozással) meg kell különböztetni. Az üzenetküldéskor a kommunikáló processzusok nevét is továbbítani kell. Be kell vezetni a hitelesítést, biztonsági okokból. Ha a küldő és a fogadó ugyanazon a gépen van, a hatékonyságra is gondolni kell. Összefoglalva: az üzenetküldő rendszereknél felmerülő tervezési kérdések megegyeznek az általában az adattovábbításkor felmerülőkkel, bármely kommunkációs csatotnában.

Processzusok kommunikációja Üzeneztküldés - gyártó- fogyasztó probléma
A gyártó és a fogyasztó most N üzenetet küld egymásnak (az N elemű közös tároló használata helyett). Az első N üzenet üres. Ha gyártó gyorsabb, akkor blokkolódik, amíg az összes eddig legyártott N üzenetsor át nem jut a fogyasztóhoz. Ha a fogyasztó gyorsabb, akkor ő vár blokkolt állapotban egy feltöltött üzenetsorra. Az üzenetet címezhetjük a processzushoz közvetlenül, közbeeső állomások nélkül. Ezt a stratégiát nevezzük randevúnak. Létrehozhatunk üzenetek ideiglenes tárolására szolgáló levelesládát, és címezhetünk erre is. Ha egy processzus tele levelesládába küld üzenetet, akkor felfüggesztik. A gyártó és fogyasztó legalább N üzenet tárolására alkalmas ládát használ. Ez a módszer rugalmasabb az előzőnél.

Processzusok kommunikációja Üzeneztküldés - gyártó fogyasztóprobléma
#define N 100 void producer(void) { int item; message m; while (TRUE) { procedure_item(&item); receive(consumer, &m); build _ message(&m, item); send(consumer, &m); } /*a rekeszek száma a tárolóban*/ /*az üzenetek tárolója*/ /*létrehoz valamit, amit a tárolóba lehet tenni*/ /*várjuk, hogy egy üres megérkezzen*/ /*elküldendő üzenet összeállitása*/ /*küldök egy elemet a fogyasztónak*/

Processzusok kommunikációja Üzeneztküldés - gyártó fogyasztóprobléma
void consumer(void) { int item, i; message m; for (i=0 ; i<N; i++ ) send(producer, &m); while (TRUE) { receive(producer, &m); extract _item(&m,& item); send(producer, &m); consume_item(item); } /*az üzenetek tárolója*/ /*N üres elem küldése*/ /*fogadjuk az üzenetet, amiben az elem van*/ /*kibontjuk az elemet az üzenetből*/ /*visszaküldjük az üres elemet*/ /*csinálunk valamit az elemmel*/

Processzusok kommunikációja Üzeneztküldés a UNIX alapú rendszerekben
A felhasználói processzusok kommunikációja a UNIX-ban pájpokon (pipe) keresztül valósul meg. Ezek a pájpok tulajdonképpen levelesládák. A pájpok nem őrzik meg az üzenetek határait (10 darab 100 bájtos elküldött üzenetet a fogadó processzus 1000 bájtként olvas), a klasszikus levelesládák viszont megőrzik ezeket. Vagy azonos hosszúságú üzeneteket továbbítunk, vagy egy speciális karakterrel zárjuk az üzenetet. Egy READ egy üzenettel tér vissza.

Processzusok kommunikációja Jellegzetes IPC problémák Az étkező filozófusok probléma
Dijkstra (1965-ben) vetette fel a problémát, és ma is gyakran tesztelik az új szinkronizációs primitiveket ezen a feladaton. A probléma: öt filozófus, öt tényér spagetti, öt villa enni csak két villával lehet egyszerre a filozófusok ‘kétállapotúak’: gondolkodnak vagy esznek. Ha egyikük megéhezik, egyenként megpróbálja felvenni a két villát és eszik, majd leteszi a villákat és újra gondolkodik.

Processzusok kommunikációja Jellegzetes IPC problémák Az étkező filozófusok probléma
Ha mind az öt filozófus egyszerre veszi kézbe mondjuk a bal oldali villáját - a másikat nem tudja megszerezni. Holtpont alakul ki. Ha csak a jobb oldali villa elérhető, tegye azt le és várjon, amíg a bal oldali is szabad lesz. Előfordulhat, hogy ezt az algoritmust mindegyik filozófus egyszerre hajtja végre, cselekszik, kivár. Mindig történik valami, de nincs előrehaladás. Az ilyen programproblémát éheztetésnek nevezzük. Ha nem azonos időközönként probálkoznak a filozófusok, akkor sem valószínű, hogy sokáig fenntartható az, hogy mindig egyen valaki. Gyakorlati hiba, hogy nem hatékony a módszer, amennyiben egyszerre csak egy filozófus eszik (hiszen akár kettő is megtehetné ezt).

Processzusok kommunikációja Jellegzetes IPC problémák Az olvasók és írók probléma
Az étkező filozófusok problémakör, és a megoldások jól hasznosíthatók, ha korlátozott számú erőforrás miatt alakul ki versenyhelyzet. Az író-olvasó probléma nem más, mint az adatbázisok hozzáférési problémáit modellező feladat (például repólőjegy-foglalás). Elfogadható, hogy több olvasó legyen a bázisban egyidejűjleg, de az írónak kizárólagos jogot kell adni a hozzáféréshez. Ha az olvasó mindig új olvasókat enged maga mellé, (mert teheti), akkor hatékony egyidejűséget kapnuk. Ugyanakkor a bázis előtt akár a végtelenségig is várakozhat egy iró, hogy az olvasók elfogyjanak, és egyedül maradjon a bázisban. Ezt elkerülendő, ha író várakozik, és újabb olvasó érkezik, azt az író maga mögé parancsolja. Csak azt kell megvárnia, hogy a bázisban tartózkodó olvasók elfogyjanak. Ez a módszer kevésbé hatékony, mert nem támogatja az egyidejű olvasást oly mértékben mint az előző.

Processzusok kommunikációja Jellegzetes IPC problémák Az alvó borbély probléma
A probléma a következő: egy processzus (a borbély) kiszolgál más processzusokat (vendégek). Reggel kinyit, ha nincs vendég aludni megy Érkező első vendég ébreszti Csak meghatározott számú (a székek száma szerinti) vendég tartózkodhat az üzletben. Ha nincs benn ülőhely, a vendég várakozni kényszerül az ajtó előtt.

Processzusok kommunikációja Jellegzetes IPC problémák Az alvó borbély probléma
A hajvágás egy eljárás. Amig tart, az üzletben levő többi vendégek nem kerülnek sora (nem léphetnek kritikus szekcióba, és ehhez mutex szemafort használunk). Ha a hajvágásnak, az eljárásnak, vége, a vendég elhagyja az üzletet, és a borbély megnézi várakozik-e valaki a székeken. Ha igen, új eljárást kezd, egy szék kiürül, új vendég jöhet be várakozni a sorára.. Az író-olvasó probléma és az alvó borbély probléma esetében nem töténik valódi adatátvitel, de IPC témakörbe tartoznak a szinkronizációs problémák miatt.

Processzusok ütemezése
Ha több processzus kerül egyidejűleg futásrakész állapotba, akkor az OR döntést hoz a futás sorrendjéről, ütemez. Sok ütemezési algoritmus létezik, és ma is fejlesztenek újabbakat. A régi kötegelt rendszereknél szekvenciális volt a végrehajtás módja, a mágnesszalagtároló miatt. A időosztásos mai rendszerek egyszerre több felhasználót szolgálnak ki, és kötegelt rendszereik is várhatnak a sorban. Egy gépen is versengés folyik a processzusok között a CPU eléréséért. Az ütemező az adott feltételek ismeretében, döntési elvek alapján dolgozik.

A jó ütemezési algoritmus néhány feltétele Pártatlanság Hatékonyság Válaszidő minimizálása az interaktiv felhasználóknál Áthaladási idő minimizálása a kötegelt felhasználóknál Áteresztőképesség, azaz maximalizálni az egy időegység alatt elvégzett munkák számát. A fenti elvárások gyakran ellentmondanak egymásnak (az interaktív és kötegelt felhasználók egyidejű hatékony kiszolgálása például). A processzusok futása egyedi, és nem jósolható előre, a CPU-idő viszont véges.

Hogy a processzusok csak behatárolt időintervallumon belül futhassanak, a számitógépes redszerek óraszerkezete rendszeres óramegszakításokat küld. Ha egy futásrakész processzus felfüggeszthető, akkor megszakító ütemezésről beszélünk. A kötegelt rendszerek nem megszakítható ütemezésűek, illetve készre futtatásos rendszerek. Az esetleges versenyhelyzeteket szemaforok, monitorok, üzenetek és más módszerek alkamazásával kerülhetjük el. Nem lehet általánosítani az ütemezés algoritmusának megítésélekor, mert mások a követelmények egy sokat számoló rendszernél, és mások egy báziskezelőnél például (itt egy főprocesszusnak kell alárendelni a többit.)

Processzusok ütemezése Round robin ütemezés
Az egyik legrégibb, legegyszerűbb, legelterjedtebb ütemezési algoritmus. Minden processzunak ki van osztva egy adott időintervallum, időszelet, amely alatt engedélyezett a futása. Ha az időszelet végén a processzus még fut, akkor felfüggesztik, és a CPU a következő kijelölttel folytatja. Ha az időszelet közben végez, a CPU új processzust választ. Feltételezzük, hogy a processzusok azonos prioritásúak. A legkomolyabb gond az időszelet hosszának meghatározása. A processzusátkapcsolás illetve környezetkapcsolás maga is időbe telik (regiszterek, memóriatérképrk elmentése, stb.). Nem mellékes, hogy időtartama hogyan aránylik az időszelethez.(minél kisebb legyen az időszelethez képest.) A túl hosszú időszelet nem hatékony (elsősorban az interaktív felhasználóknál szembetűnő ez.)

Processzusok ütemezése Round robin ütemezés
A futtatandó processzusok listája (current process=aktuális processzus, next process=a következő processzus) A futtatandó processzusok listája azután, hogy B elhasználta az időszeletét

Processzusok ütemezése Prioritásos ütemezés
Ha az ütemezéskor külső tényezőket is figyelembe veszünk, akkor prioritásos ütemezési algoritmust kell használnunk (a legmagasabb prioritású fut először). Hogy a magas prioritású ne futhasson a végtelenségig futás közben csökkenthető a prioritása vagy kiszabható a maximális időszelete. A prioritásokat tehát a processzusokhoz rendelhetjük statikusan, a külső tényezők alapján, előre megadottan (esetlegesen nice paranccsal módosíthatjuk a a UNIX-ban) dinamikusan, (például, hogy B/K processzusok ne várjanak, hiszen ha időben idulnak, más processzus is CPU-hoz juthat a B/K futása mellett). prioritási osztályokat létrehozva.

Processzusok ütemezése Prioritásos ütemezés
Ütemezési algoritmus négy prioritási osztállyal először a 4-es priritású osztály elemei futnak, amig van belőlük, a maguk időszeleteiben, round robin módon ha a magasabb oszályból az elemek elfogynak, az alacsonyabb szintűek kerülnek sorra.

Processzusok ütemezése Többszörös sorok
A különböző osztályban levő processzusok különböző számú időszeletig futnak (a magasabb osztálybeliek több időszeletet vehetnek igénybe közvetlen egymás után). Ha a processzus elhasználja a számára így előlátott időszeleteket egyszer, akkor ezután eggyel alacsonyabb prioritású osztályba kerülve várja az aktualizálást. Az eredetileg hosszú futási időt igénylő processzusoknak ez a módszer gyakran hátrányos, de ha interaktivvá tesszük őket (pl. enter-t ütünk le időnként futása közben), akkor a válaszidő lényegesen csökkenhet. Kidolgoztak több más, hasonló algortmust is, amely kifejezetten kedvez az interaktív felhasználóknak (a háttérben futókkal szemben).

Processzusok ütemezése A legrövidebb feladatot először
Speciálian olyan kötegelt rendszereknél használják, ahol a futási idő előre ismert. A sok egyformán fontos bemenő feladat közül az ütemező a legrövidebbet először hajtja végre. A legrövidebbet elöször algoritmus bizonyíthatóan optimális a leírt körülmények között. Az interaktív processzusoknál is alkalmazható a módszer, ha az összválaszidő minimizálását tekintjük célnak. Sajnos nehéz előre eldönteni, hogy az interaktív processzusok közül melyik lesz a legrövidebb. Hagyatkozhatunk a tapasztalatokra, vagy a számontartott, elhasznált CPU idő megfigyelésére például.

Processzusok ütemezése Sorsjáték- ütemezés
A sorsjátékütemzést Waldspurger és Weihl vezette be 1994-ben. Lényege a következő: A processzusok között másodpercenként meghatározott számú sorsjegyet (CPU időtegységet) oszt ki az ütemező. A magasabb prioritású processzusok több sorsjegyet kapnak, tehát nagyobbak a ‘nyerési lehetőségeik’. A prioritásos ütemezésekkel ellentétben, ahol nehéz előre korrekten lekötni a prioritásokat, itt egyértelműen az a processzus jár jól, amelyiknél a sorsjegyek nagyobb hányada van. Együttműködő processzusok átadhatják egymásnak a sorsjegyeiket, növelve ezzel a hatákonyságot (pl. kliensek nélküli szervernek nem kell sorsjegy). Különösen jól alkalmazható videószervereknél (a képlebontásnak megfelelő számú sorsjegyet adunk a képkezelő processzunak.)

Processzusok ütemezése Valós idejű ütemezés
A valós idejű rendszerekben az idő nagyon fontos tényező. Ezeknek a rendszereknek aktuális fizikai mennyiségek alapján valós időn belül kell eredményt adniuk (CD lejátszó bitjeiből zenét produkálni, a korházi intenziv betegágynál, a robotpilóták, az atomreaktorok biztonsági rendszerei esetében.) Léteznek szigorú valós idejű rendszerek, abszolút határidőkkel, és lágy valós idejű rendszerek, ahol a határidő elmulasztása tolerálható. A programokat rövid, megjósolható időtartamú processzusokra osztjuk. A valós idejű rendszerek programozható eseményei lehetnek periódikusak illetve aperiódikusak.. Ezekhez igazíthatjuk a megfelelő processzusütemezéseket.

Legyen m periódikus eseményünk, az i-dik esemény periódusa Pi, az egyes események kezelésének ideje Ci. Ha akkor kezelhetőek és ütemezhetőek ezek a periódusos valós idejű rendszerek. A valós idejű ütemező algoritmusok is lehetnek statikusak (a rendszerindítás előtt adjuk meg) dinamikusak (futás közben változtathatóak). Ismert valós idejű algoritmusok: állandó arány algoritmus legkorábbi határidő először lazaságon (processzus felesleges időmennyiségén) alapuló algoritmus.

Tipikusan a valós idejű operációs rendszerekre jellemző tulajdonságok: kis méret rövid megszakitási idő gyors környezetcsere rövid ideig tartó megszakítás többszörös időzítőkezelés, ezred- és mikromásodperces nagyságrendben.

Processzusok ütemezése Kétszintű ütemezés
Ha a futtatandó processzusoknak nem elegendő a főmemória, hanem lemezkapacitást is igényelnek, akkor a hatékonyság érdekében kétszintű ütemezést kell alkalmaznunk. A processzusok egy része betöltődik a főmemóriába, az ütemező ezekkel fogalakozik. A többi lemezen marad, majd idővel ezek kerülnek a főmemóriába, egy magasabb szintű ütemező hatására.. Az alacsonabb szintű ütemező a főmemóriabeli processzusokat kezeli, a magasabb szintű ütemező pedig a lemez és a főmemória között ingázik. Az ütemezők használhatják a round robin, a prioritásos, vagy más ütemezési módszert, mégpedig nem kötelezően ugyanazt mindkettő.

A kétszintű ütemezés egyrészt a processzusokat mozgatja lemez és memória között, másrészt ütemezi a memóribeli processzusokat. Az ábra három különböző (a), (b), (c) időpillanatot mutat be.

A magasabb szintű ütemező a következő kritériumok alapján dönthet: Mennyi idő telt el a processzusok kicserélése óta? Mennyi CPU időt használt fel a processzus ezidáig, és mennyit legutoljára? Milyen nagy a processzus, mert a kicsik nem zavaróak a főmemóriában sem. Milyen magas a processzus prioritása?

Processzusok ütemezése Cél és megvalósitás
Az eddigi algoritmusok esetében feltételeztük, hogy a processzusok különböző felhasználókhoz tartoznak, és CPU-ért versengenek. Az adatbáziskezelő rendszereknél a főprocesszusnak több gyermeke van, és ezek a gyermekek különböző feladatokért felelősek. A főprocesszusnak lehetnek ugyan elképzelései arról, melyik gyermeke a fontos, de az eddig említett módszerek nem teszik lehetővé ennek beiktatását az ütemezésbe. Bevezethetünk ütemezési célokat, ami azt jelenti, hogy az ütemezési algoritmust parametrizáljuk, a paraméterek megadását más processzusokra bizzuk, és a paraméterek ismeretében alakítjuk az ütemezési algoritmust (prioritásokat, rendszerhívásokat).

Processzuskezelés a WINDOWS NT-ben Kitekintés
A Windows NT többszálas, modern operációs rendszer. Külön alrendszere létezik a kliens-szerver kapcsolat kezelésére Az üzenetküldés módszerét alkalmazza, a Local Procedure Call Facility (LPC) segitségével. IPC létrejöhet még kernel-objektumok segitségével is. A processzus létrehozása a CreateProces hivással indul, létrejön a megfelelő processzus-objektum. A WIN32 később visszatér a processzushoz, hogy a szálakat is létrehozza, és ezután tovább kezeli a processzust szálaival együtt.

Processzuskezelés Processzusok, alapfogalmak

Hasonló előadás

Az előadások a következő témára: "Processzuskezelés Processzusok, alapfogalmak"— Előadás másolata:

Hasonló előadás

Projectumról

Visszajelzés

Bejelentkezés

A társadalmi hálózaton keresztül belépni:

Processzuskezelés Processzusok, alapfogalmak

Hasonló előadás

Az előadások a következő témára: "Processzuskezelés Processzusok, alapfogalmak"— Előadás másolata:

Hasonló előadás

Projectumról

Visszajelzés