Operációs rendszerek be és kivitelkezelése, holtpont fogalma, kialakulásának feltételei, holtpontkezelési stratégiák, bankár algoritmus.



Hasonló dokumentumok
Tartalom. Operációs rendszerek. 4.1 Holtpont definíciója. Bevezetés helyett... Rendszermodell 1. A klasszikus példa...

Operációs rendszerek

Operációs rendszerek. Holtpont

Dr. Illés Zoltán

Operációs rendszerek II. Holtpont

Előadás_#06. Előadás_06-1 -

Nyíregyházi Főiskola Matematika és Informatika Intézete. Holtpont (Deadlock) Alapfogalmak, példák, ábrázolás. Biztonságos és nem biztonságos állapot

Bevitel-Kivitel. Eddig a számítógép agyáról volt szó. Szükség van eszközökre. Processzusok, memória, stb

OPERÁCIÓS RENDSZEREK. Elmélet

Bevitel-Kivitel. Bevitel-Kivitel és Perifériák. Algoritmusok és Alkalmazásaik Tanszék Budapest december 16.

Operációs rendszerek. Folyamatok ütemezése

Előadás_#02. Előadás_02-1 -

Processzusok (Processes), Szálak (Threads), Kommunikáció (IPC, Inter-Process Communication)

Léteznek nagyon jó integrált szoftver termékek a feladatra. Ezek többnyire drágák, és az üzemeltetésük sem túl egyszerű.

Processzusok (Processes), Szálak (Threads), Kommunikáció (IPC, Inter-Process Communication)

... S n. A párhuzamos programszerkezet két vagy több folyamatot tartalmaz, melyek egymással közös változó segítségével kommunikálnak.

Termelő-fogyaszt. fogyasztó modell

UNIX ütemezése. Operációs rendszerek MINB240 UNIX, Windows NT ütemezése Holtpontkezelés. Algoritmus követelményei. UNIX ütemezés jellemzése

Uniprogramozás. várakozás. várakozás. Program A. Idő. A programnak várakoznia kell az I/Outasítások végrehajtására mielőtt továbbfuthatna

Operációs rendszerek MINB240 UNIX, Windows NT ütemezése Holtpontkezelés. UNIX ütemezése. Algoritmus követelményei. 4.

Az operációs rendszer szerkezete, szolgáltatásai

Operációs rendszerek

5 HOZZÁFÉRÉS-VÉDELEM. A fejezet VIDEOTON fejlesztési dokumentációk felhasználásával készült

Nyíregyházi Egyetem Matematika és Informatika Intézete. Input/Output

Előadás_#03. Előadás_03-1 -

Autóipari beágyazott rendszerek. Komponens és rendszer integráció

Operációs rendszerek. UNIX fájlrendszer

Miskolci Egyetem Gépészmérnöki és Informatikai Kar Informatikai Intézet Alkalmazott Informatikai Intézeti Tanszék

Operációs rendszerek II. Folyamatok ütemezése

2. fejezet Hálózati szoftver

Verifikáció és validáció Általános bevezető

Windows ütemezési példa

Optimista konkurenciavezérlés

Utolsó módosítás:

Nem biztos, hogy mindenhol helytáll, helyenként hiányos, de az eddigi kérdések össze vannak gyűjtve őszi félév első zhval bezárólag.

5/1. tétel: Optimalis feszítőfák, Prim és Kruskal algorithmusa. Legrövidebb utak graphokban, negatív súlyú élek, Dijkstra és Bellman Ford algorithmus.

Mátrixjátékok tiszta nyeregponttal

Operációs rendszerek MINB240. Bevitel-Kivitel. 6. előadás Input és Output. Perifériák csoportosításá, használat szerint

A számítástudomány alapjai

Software project management Áttekintés

Operációkutatás vizsga

12. Másodlagos tár szerkezet

C++ programozási nyelv

Párhuzamos programozási platformok

Mennyit termelhetünk a felszín alatti vízkészletekbıl? DR. VÖLGYESI ISTVÁN

Dr. Kulcsár Gyula. Virtuális vállalat félév. Projektütemezés. Virtuális vállalat félév 5. gyakorlat Dr.

Párhuzamos programozási platformok

2. Folyamatok. Operációs rendszerek. Folyamatok. Bevezetés Folyamatkezelés multiprogramozott rendszerekben. Folyamatok modellezése

26. MINIMÁLIS KÖLTSÉGŰ UTAK MINDEN CSÚCSPÁRRA

Teljesítmény Mérés. Tóth Zsolt. Miskolci Egyetem. Tóth Zsolt (Miskolci Egyetem) Teljesítmény Mérés / 20

2. Számítógépek működési elve. Bevezetés az informatikába. Vezérlés elve. Külső programvezérlés... Memória. Belső programvezérlés

9. Fejezet: Input/Output

Operációs rendszerek Folyamatok 1.1

Villamos jelek mintavételezése, feldolgozása. Mérésadatgyűjtés, jelfeldolgozás 9. előadás

Bevezetés a számítástechnikába

VÁRPALOTA VÁROS TELEPÜLÉSRENDEZÉSI TERVÉNEK MÓDOSÍTÁSA

Programfejlesztési Modellek

30. ERŐSEN ÜSSZEFÜGGŐ KOMPONENSEK

Szenzorhálózatok programfejlesztési kérdései. Orosz György

Matematikai és Informatikai Intézet. 4. Folyamatok

Feladatok (task) kezelése multiprogramozott operációs rendszerekben

Osztott jáva programok automatikus tesztelése. Matkó Imre BBTE, Kolozsvár Informatika szak, IV. Év 2007 január





























Miskolci Egyetem Gépészmérnöki és Informatikai Kar Informatikai Intézet Alkalmazott Informatikai Intézeti Tanszék

Utolsó módosítás:

Tehetséggondozás a munkahelyen

14. óra op. rendszer ECDL alapok

A 2016/2017 tanévi Országos Középiskolai Tanulmányi Verseny második fordulójának feladatai. INFORMATIKA II. (programozás) kategória

5. tétel. A számítógép sematikus felépítése. (Ábra, buszok, CPU, Memória, IT, DMA, Periféria vezérlő)

A gyógyszerpiac szabályozásának versenypolitikai kérdései

Informatikai rendszerek alapjai (Informatika I.)

INFORMATIKA ZÁRÓSZIGORLAT TEMATIKA

Tantárgyfelvétel: problémamentesen

Átírás:

Operációs rendszerek be és kivitelkezelése, holtpont fogalma, kialakulásának feltételei, holtpontkezelési stratégiák, bankár algoritmus. Input/Output I/O Hardware I/O eszközök (kommunikációs portok szerint is lehet csoportosítani): Blokkos eszközök Karakteres eszközök Eszközvezérlők (I/O eszközök elektromos komponensét alkotják): IDE: Integrated Drive Electronics SCSI: Small Computer System Interface IRQ: Interrupt Request DMA: Direct Memory Access I/O Software Réteges szervezés Felhasználói szint Eszközfüggetlen Operációs rendszer Eszközmeghajtók Megszakításkezelés Holtpont Az erőforrás kezelésnek a köv. módszere végtelenül egyszerűnek tűnik: ha van szabad erőforrás kielégítjük, ha nincs, a folyamat várakozni kényszerül. Ez a probléma nagyvonalú megközelítése, azonban korlátai elég hamar megmutatkoznak. Veszélye: Több folyamat egy olyan erőforrás felszabadulására vár, amit csak egy ugyancsak várakozó folyamat tudna előidézni. Ez az állapot kapta a HOLTPONT (deadlock) nevet. Holtpont esetén a folyamatok körkörösen egymásra várakoznak. Ha megszüntetjük a párhuzamosságot a probléma megelőzhető. A holtpont kialakulásának feltételei Kölcsönös kizárás Vannak olyan erőforrások a rendszerben, melyeket a folyamatok csak kizárólagosan használhatnak. Foglalva várakozás legyen olyan folyamat mely lefoglalva tart erőforrásokat, miközben más erőforrásokra várakozik. Nincs erőszakos erőforrás-elvétel a folyamatok addig birtokolják az erőforrást, míg saját jószántukból fel nem szabadítják azokat. Körkörös várakozás Létezik a rendszerben egy olyan folyamatsorozat, melyben minden folyamat az utána következő folyamat által foglalt erőforrásra vár, a sorozat utolsó tagja pedig a sorozat első tagjára.

2 Modell: Irányított gráf A Processzus A Processzus használja R erőforrást R Erőforrás B Processzus B Processzus igényli S erőforrást S Erőforrás A R S Körkörös várakozás B Holtpontkezelési stratégiák Nem veszünk tudomást a holtpontról (strucc algoritmus) Ha a holtpont kialakulásának valószínűsége kicsi, a rendszer újraindításának nincsenek kritikus következményei, akkor megérheti ezt a megoldást választani. Észrevesszük, ha a holtpont kialakult és megpróbáljuk feloldani Vagy az erőforrást vesszük el a folyamatoktól, vagy kilőjük a folyamatokat. Mindkettő nagy kárt okozhat, mert a kilőtt folyamatokhoz tartozhatnak megnyitott fájlok, stb. Védekezünk a holtpont kialakulása ellen: Megelőzzük a holtpont kialakulását: olyan rendszert tervezünk, ahol nem teljesülnek a holtpont feltételei, így elvileg sem lehet holtpont. Ahhoz, hogy a rendszerben holtpont kialakulhasson, négy feltétel egyidejű teljesülése szükséges: Kölcsönös kizárás minimálisra csökkentése: lehetőleg többpéldányos erőforrásokat alkalmazunk, ahol ez nem lehetséges, ott a hozzáférést megpróbáljuk oszthatatlan műveletté tenni. Foglalva várakoztatás megszüntetése: Ha minden folyamat betartja a szabályt, miszerint az egyidejűleg szükséges valamennyi erőforrását egyetlen rendszerhívással kéri el, akkor elkerülhető a foglalva várakoztatás. Ennek ára van: az erőforrás-kihasználtság romlása.

3 Nincs erőszakos erőforrás-elvétel kiküszöbölése: Ha menthető állapotú erőforrásaink vannak, akkor megtehetjük, hogy elvesszük egy adott folyamat erőforrását és egy másiknak adjuk, majd annak lefutása után visszaadjuk a régi állapotában az erőforrást az első folyamatnak. Körkörös várakozás megakadályozása: A folyamatok megegyeznek az erőforrások sorszámozásában, minden folyamat csak nagyobb sorszámú erőforrást igényelhet azoknál az erőforrásoknál melyeket birtokol. Ekkor biztosan nem alakulhat ki kör. Ha a négy feltétel legalább egyikének a kialakulását megakadályozzuk, nem alakul ki holtpont! Az első és a harmadik feltétellel nem tudunk mit kezdeni, hiszen a rendszerünkben vagy vannak kölcsönös kizárást igénylő ill. erőszakkal el nem vehető erőforrások, vagy nincsenek. Tehát csak a várakozás közbeni foglalásra és a körkörös várakozásra érdemes koncentrálni. Az egyetlen foglalási lehetőség stratégia a várakozás közbeni erőforrás lekötést tiltja meg. A folyamat csak egy lépésben (célszerű induláskor) foglalhatja le az összes szükséges erőforrást. Ha bármelyik erőforrás is hiányzik a folyamat várakozó listára kerül. Az a folyamat, amelyik már rendelkezik erőforrással, többletigényt nem nyújthat be, a további kéréseket az operációs rendszer elutasítja. Holtpont nem alakulhat ki, mivel a futó folyamatok nem kényszerülnek várakozni, mindenük megvan, a várakozó folyamatok pedig nem rendelkeznek erőforrásokkal.. Előnye: egy folyamat, ha már megszerezte az összes erőforrást, soha többé nem kell, hogy erőforrásra várakozzon, azaz gyorsan lefuthat. Hátrányai: a folyamatok olyankor is kénytelenek foglalva tartani erőforrásokat, ha pillanatnyilag nincs rá szükségük. Nem mindig mérhető fel előre egy folyamat erőforrás igénye. Ha egy folyamat sok és népszerű erőforrást igényel, előfordulhat, hogy soha nem jön el az a pillanat, amikor mindegyik egyidejűleg áll rendelkezésre, így a folyamat bizonytalan ideig várakozni kényszerül, éhezik. A rangsor szerinti foglalás a ciklikus várakozás lehetőségének kiküszöbölésével alkalmas a holtponthelyzetek megelőzésére. Lényege, hogy az erőforrások osztályaihoz egy-egy növekvő sorszámot rendelünk úgy, hogy a leggyakrabban használt erőforrások kapják a legkisebb sorszámot. Ha egy folyamatnak egy osztályon belül több erőforrásra van szüksége, azokat csak egyszerre igényelheti. Egy folyamat csak olyan osztályból igényelhet erőforrást, melynek sorszáma magasabb, mint a már birtokolt erőforrások sorszáma. Ha egy folyamatnak a meglévőknél alacsonyabb sorszámú erőforrásra van szüksége, fel kell szabadítania erőforrásokat egészen addig a szintig, míg az igénylési feltételek nem teljesülnek. A bankár algoritmus a rendszert mindig ún. biztonságos állapotban tartja. Egy állapotot akkor tekintünk biztonságosnak, ha létezik legalább egy olyan sorozat, amely szerint az összes folyamat erőforrás igénye kielégíthető. Sose elégítsünk ki egy igényt, ha az nem biztonságos állapotot eredményez. Az algoritmus csak akkor működik, ha a folyamatok indulásukkor tudják, hogy a különböző erőforrásokból egyszerre maximálisan hányat fognak igényelni, és ezt az op. rendszernek egy rendszerhívás által be is jelentik. Ez a módszer legnagyobb hátránya, hogy vannak olyan folyamatok, amelyek erőforrás igénye előre nem tudható. Meg kell jegyezni, hogy ha egy rendszer állapota nem biztonságos, nem jelenti azt, hogy a holtpont kialakul, hanem mindössze azt, hogy lehet hogy kialakul! Azaz az algoritmus úgy

4 garantálja a holtpont mentességet, hogy már egy, a holtpontnál tágabb szituáció a nem biztonságos állapot kialakulását is megakadályozza. Bankár: op. rendszer Ügyfél: processzus Hitelegység:erőforrás Birtok Max x 0 6 y 0 5 z 0 4 w 0 7 Szabad: 10 Biztonságos állapot Birtok Max x 1 6 y 1 5 z 2 4 w 4 7 Szabad: 2 Nem biztonságos állapot Birtok Max x 1 6 y 2 5 z 2 4 w 4 7 Szabad: 1 Holtpont felszámolása Sajnos a holtpontmegelőző stratégiák mindegyikének komoly elvi és/vagy gyakorlati problémái vannak, tehát ezek csak speciális körülmények között alkalmazhatóak. Holtpont detektálása Először is képesnek kell lennünk észrevenni, detektálni, ha egy holtpont kialakult. Ehhez az op. rendszernek folyamatosan nyílván kell tartania az erőforrások szétosztását és a ki nem elégített igényeket. Ezen adatokból kiindulva időnként egy ún. holtpont detektáló algoritmust kell lefuttatnia. Mi az az időnként, amikor a holtpont detektáló algoritmust futtatni célszerű: - Minden olyan esetben futtassuk le ezt, amikor egy erőforrásigényt nem tudunk azonnal kielégíteni. Mivel ilyen eset nagyon gyakran történik, ezért ez a megoldás nagyon lelassítaná

5 rendszerünk működését. - Áldozunk a biztonságból. Futtassuk a holtpont detektáló algoritmusunkat viszonylag ritkán, időnként periodikusan. Ezzel az a baj, hogy ez alatt az idő alatt, több holtpont is kialakulhat és akkor elég régóta blokkolhatja is a folyamataink működését. Holtpont megszüntetése Az első gondolatunk a holtpont megszüntetésére az lehet, hogy az összes, a holtpontban lévő folyamatot szüntessük meg. Ez tagadhatatlanul elég egyszerű megoldás, de hatalmas veszteséggel jár. Valamilyen szempont alapján válasszunk ki először egyet a holtpontban résztvevő folyamatok közül, szüntessük meg azt, majd ellenőrizzük, hogy a maradék még mindig holtpontban van-e. Áldozat kijelölési szempontok: - melyikkel hány erőforrást nyerek; - hány további erőforrást igényel; - mennyi mér elhasznált CPU időt ill. I/O munkát vesztek a megszüntetéssel; - mennyi idő van még hátra a futásból; - ismételhető / nem ismételhető folyamat-e; - a folyamat prioritása / célszerű kis prioritású folyamatot választani; - megszüntetése hány további folyamatot érint. Tovább finomítva. Lehet, hogy nincs is szükség a folyamat teljes megszüntetésére, elég ha néhány erőforrást elveszünk tőle. (Sok esetben egy nem elvehető erőforrás elrablása a folyamat működésében helyrehozhatatlan hibát okoz, míg máskor ez nem okoz problémát.) Akármilyen módszer szerint is járunk el a holtpont megszüntetésénél, figyelembe kell vennünk azt is, hogy ugyanazt a folyamatot nem választhatjuk akárhányszor áldozatul, hiszen ez a folyamat kiéheztetését okozná. A holtpontkezelés két legnagyobb veszélye: - egyik az ún. alul szabályozás, vagyis az, ha olyan túlbiztosításra törekszünk, hogy holtpont ugyan nem lesz, de a rendszer lehetőségeit sem tudjuk kihasználni. - a másik probléma az ún. túlszabályozás, azaz olyan bonyolult algoritmust választunk, hogy maga az algoritmus futtatása lassítja le a rendszert.