View
33
Download
0
Category
Preview:
DESCRIPTION
Operációs Rendszerek II. 13. előadás 2007. május 7. Konkurencia. Csak nagyon röviden Szituációk Folyamatok közötti „direkt” együttműködés Folyamatok között „akaratlanul” kialakuló versenyhelyzetek Problémák, megoldási lehetőségek. Folyamatok együttműködése. - PowerPoint PPT Presentation
Citation preview
Operációs Rendszerek II.
13. előadás
2007. május 7.
Konkurencia
• Csak nagyon röviden
• Szituációk– Folyamatok közötti „direkt” együttműködés– Folyamatok között „akaratlanul” kialakuló
versenyhelyzetek
• Problémák, megoldási lehetőségek
Folyamatok együttműködése
• A folyamatoknak sokszor szükségük van arra, hogy más folyamatokkal kommunikáljanak– Folyamatok működésükhöz más folyamattól várnak adatot
• Adatok átadása (egyik folyamat a másiknak)• Adatok megosztása folyamatok között
– Közös erőforrásokért versengő folyamatok szinkronizációja– Különböző folyamatok által végzett műveletek megfelelő
sorrendben történő végrehajtásának biztosítása
• Sok operációs rendszer lehetővé teszi, hogy az együtt dolgozó folyamatok megosszanak bizonyos erőforrásokat egymás között – versenyhelyzet alakulhat ki
Versenyhelyzetek - alapprobléma
• Klasszikus probléma, egy print spooler rendszer– Ha egy folyamat ki szeretne nyomtatni egy fájlt, akkor a fájl nevét
elhelyezi a print spooler következő üres sorában. • Spooler betelésével most nem foglalkozunk (kellően nagy)
– A spooler bejegyzéseit természetes számokkal azonosítjuk (sorszám)– A rendszer továbbá két osztott változót használ
• out változó a következő nyomtatandó fájl helyét adja meg• in változó a következő szabad bejegyzés helyét mutatja.
• Az alábbi szituációban kíván az A és B folyamat többé-kevésbé egyszerre új bejegyzést átadni a rendszernek.
Versenyhelyzet folyt.worst case scenario
• ‘A’ folyamat– Kiolvassa az in változó értékét (6), majd eltárolja egy belső
változójában. – Mielőtt megnövelhetné az in változó értékét, az ütemező átadja a
vezérlést a B folyamatnak• ‘B’ folyamat
– Szintén 6-ot olvas ki az in változóból– Az általa nyomtatni kívánt fájl nevét eltárolja a spooler 6-os sorában– Utána megnöveli in értékét is– Vezérlés visszakerül az A folyamathoz
• ‘A’ folyamat– A sor számát nem az in változóból veszi, hanem a belső változójából, – A folyamat is a 6-es sorba fogja elhelyezni a fájlnevet
Versenyhelyzet folytatás,megállapítások
• A fenti problémához hasonló problémákat, ahol több folyamat szeretne közös adatokat használni, és a futás eredménye a folyamatok végrehajtásának egymáshoz képesti ütemezésétől is függ versenyhelyzetnek nevezzük. • Az átmeneti változó az előző példában a
processzor akkumulátor regisztere is lehet, tehát még egy gépi kódú program sem lenne elegendő a probléma feloldásához
Versenyhelyzet kialakulásának megakadályozása
• Megoldás az, ha biztosítani tudjuk, hogy az osztott erőforrásokat egy időben csak egy folyamat olvashassa ill. módosíthassa — tehát kizárólagos hozzáférésre van szükségünk.
– A kizárólagos hozzáférés biztosítása azonban nem csak egyetlen gépi utasítás erejéig szükséges, hanem egy kódrészlet végrehajtása alatt.
– A programok azon részét, amelynek megszakított végrehajtása problémákat okozhat kritikus régiónak hívjuk.
– Ha el tudjuk érni, hogy egyszerre csak egy folyamat hajtsa végre a kritikus régiójához tartozó kódrész utasításait, elkerülhetjük a versenyhelyzeteket.
• A teljes megoldáshoz négy feltétel egyidejű teljesülése szükséges:– Egy időben csak egy folyamat futtathat a kritikus régiójához tartozó kódot.– A processzorok sebessége vagy száma nem befolyásolhatja a működés
végeredményét.– A kritikus szekcióján kívül futó program nem blokkolhatja más folyamatok
végrehajtását– Egyetlen folyamatnak sem kell örökre várakoznia, hogy végrehajthassa a kritikus
szekcióhoz tartozó utasításait.
Kizárólagos hozzáférés megvalósítása (alapok)
• Megszakítások tiltása– A legegyszerűbb megoldást jelenti, ha a kritikus szekciójába
belépő folyamat által végrehajtott első utasítás a megszakítások tiltása.
• Ha a megszakításokat letiltjuk, a rendszeróra megszakítása sem jut érvényre, így az ütemező sem jut érvényre.
• Ez a megoldás a gyakorlatban használhatatlan, ugyanis egyetlen hibás felhasználói folyamat a teljes rendszert lebénítaná. Az operációs rendszer kódján belül azonban sokszor használják ezt a fajta megoldást (bár mára jelentőssége erősen lecsökkent).
• Üzenettovábbítás– Az üzenettovábbítás a folyamatok közötti kommunikáció egy
igen elterjedt módja. Két primitív műveletet használ, a SEND művelet segítségével egy üzenetet továbbíthatunk, míg a RECEIVE művelet üzenet vételét célozza.
Kizárólagos hozzáférés megvalósítása (alapok)
• Szemaforok– A szemaforok elméletét E. W. Dijkstra dolgozta ki 1965-ben – A megoldás lényege egy számláló változó, amelyet két művelet
segítségével változtathatunk• A Down művelet eggyel csökkenti a számláló értékét. Ha a számláló értéke
nulla volt, akkor a művelet mindaddig nem tér vissza, amíg a számláló értékét egy másik művelet nem növeli meg egyel. Ebben az esetben már a csökkentés végrehajtható
• Az Up művelet a számláló értékét egyel növeli, és ha az érték előzőleg nulla volt, akkor egy várakozó Down műveletet „felébreszt”
– A megoldás leglényegesebb eleme az, hogy az Up és a Down műveletek atomiak, tehát végrehajtásuk nem szakítható meg
• A mai processzorok többsége már rendelkezik olyan gépi kódú utasítással ami lehetővé teszi a fenti műveletek atomi szintű megvalósítását
– A szemaforokat a kizárólagos hozzáférés megvalósításán túl szinkronizációs célokra is felhasználhatjuk (pl. jelezzük, hogy egy puffer megtelt)
Folyamatok viszonya
• Folyamatok közötti viszony szintjei– Folyamatoknak nincs tudomásuk egymásról– Folyamatoknak indirekt módon tudomásuk
van egymásról– Folyamatok tudatosan együttműködnek
Folyamatok viszonya
• Folyamatok közötti viszony szintjei– Folyamatoknak nincs tudomásuk egymásról
• Egymástól teljesen független folyamatok (pl. multiprogramozott környezetben)
• Az erőforrásokért folyó küzdelem miatt felléphet verseny szituáció, ezt OS szinten kezelni kell!
– Folyamatoknak indirekt módon tudomásuk van egymásról
– Folyamatok tudatosan együttműködnek
Folyamatok viszonya
• Folyamatok közötti viszony szintjei– Folyamatoknak nincs tudomásuk egymásról– Folyamatoknak indirekt módon tudomásuk
van egymásról• A folyamatok közös objektumokon (pl. I/O puffer)
osztoznak• A közös objektumhoz való hozzáférés
együttműködést igényel
– Folyamatok tudatosan együttműködnek
Folyamatok viszonya
• Folyamatok közötti viszony szintjei– Folyamatoknak nincs tudomásuk egymásról– Folyamatoknak indirekt módon tudomásuk
van egymásról– Folyamatok tudatosan együttműködnek
• A folyamatok feladatuk kapcsán működnek együtt (tudatos tervezési döntés következményeképpen)
További fogalmak
• Holtpont (deadlock)– Folyamatok permanens blokkolódása– Elkerülésére nincsen általánosan jó megoldás
• Kiéheztetés (starvation)– Valamely folyamat nem jut hozzá az általa
igényelt erőforráshoz– Megfelelő (igazságos) erőforrás ütemezési
algoritmusokkal kivédhető
A közelmúlt (90-es évek) Unix fájlrendszerei
• Főbb mozzanatok– Fájlrendszer interfész és keretrendszer
változásai, több fájlrendszer egyidejű támogatása
– Többféle fájlrendszer megjelenése • Szolgáltatások (pl. hosszú fájlnevek)• Méret (fájlrendszer, fájlok)• Teljesítmény• Megbízhatóság• Speciális funkciók (pl. tmp terület)
Fájlrendszer keretek
• Fájlrendszer interfész (amely meghatározza az alapvető /rendszerközeli kódból hívható/ műveleteket) – hosszú ideje viszonylag stabilnak tekinthető– Újabb funkciók megjelentek, de cél volt a
kompatibilitás megőrzése
• A fájl keretrendszer az idők során jelentősen átalakult– Leglátványosabb: több fájlrendszer támogatása– Megoldás: vnode/vfs interfész
Több fájlrendszer – a kezdetek
• Többféle fájlrendszer használatának igényére nem volt megoldás (a kernel csak egyet támogatott)– s5fs és/vagy FFS– DOS (pl. Floppy-k)– Speciális fájlrendszerek
• Az 1980-as években a kommunikációs hálózatok elterjedésével a fájlmegosztás igénye is előtérbe került, egyebek mellett a transzparens hozzáférést kínáló Sun által fejlesztett NFS– NFS használata esetén a felhasználó ugyanolyan módon
láthatja a helyi fájlokat, mint a távoli gépen lévőket– Az NFS megoldáshoz a Sun teljesen átalakította a fájl
keretrendszert, később a megoldás (vnode/vfs) de facto szabvány lett (az SVR4 részévé is vált)
– Az NFS is az…
A vnode/vfs architektúra
• Tervezési szempontok– Többféle fájlrendszer egyidejű (Unix és nem Unix – pl.
MS-DOS) támogatása– Különféle fájlrendszereket tartalmazó diszk partíciók
csatolása (mount) után létrejövő kép konzisztens, a felhasználónak nem kell törődnie a különféle fájlrendszerek sajátosságaival
– Fájlok (távoli) megosztásának támogatása– Saját fájlrendszerek típusok létrehozásának
lehetősége
vnode/vfs koncepció
• Objektum szemléletű megközelítés:– Vnode: a fájlok absztrakciója, a– Vfs: pedig fájlrendszeré a Unix kernelben
• Absztrakt alaposztályok, minden tényleges fájlrendszer-implementáció ősei
• Az osztályok adatelemei és metódusai virtualizáltak, a funkciók két szintre oszthatók– alacsony szintű funkciók (pl. open, read) – ezeket
egyes fájlrendszer-implementációk implementálnak– magas szintű „utility” funkciók – alacsony szintű
funkcióra épülő funkciók, ezeket tipikusan a kernel egyéb részei használják
Fájlrendszer Implementációs elvárások
• Minden művelet végrehajtása a hívó folyamat nevében történik, a végrehajtás alatt a hívó blokkolódik/hat
• Bizonyos műveletek kizárólagos fájl hozzáférést igényelnek – ezek struktúrák zárolását igényelhetik
• Az interfésznek állapotmentensnek kell lennie, globális változókra nem támaszkodhat
• Reentráns interfész szükséges, ez tiltja a globális változók használatát
• Globális erőforrások (pl. buffer cache) használata megengedett
• Támogatnia kell a távoli fájlelérést szerver oldalát• Fix méretű, statikus táblák használata nem lehetséges
Fájlrendszerek
• SVR4 rendszerben támogatott fájlrendszerek– System V FS (s5fs) az „eredeti” Unix fájlrendszer– Berkeley Fast Filesystem (FFS, most ufs)– Veritas Journaling Filesystem (VxFS)– Eszközmeghajtók fájlrendszere, specfs– Hálózati fájlrendszer, NFS– Process fájlrendszer, /proc– Boot fájlrendszer, bfs
• További implemetációk– MS-DOS FAT (pl. Solaris esetén)– CD (pl. ISO 9660), DVD támogatás
Az s5fs
• A fájlrendszer egyetlen diszk partíciót foglal el, használatához más információ kell
• A partíció logikailag blokkok lineáris tömbjének tekinthető– A blokkok mérete 512 szorzata 2 egész számú hatványával– A diszk műveletek előtt a blokkok címét át kell fordítani a lemez
fizikai címadataira
• A partíció négy részből áll– Boot terület– Szuper blokk– i-node lista– adatterület
Fájlok tárolása
• Kb. fa struktúrájú szervezés, a struktúrát a könyvtár fájlok írják le. Felépítés:– Fájl neve 14 karakteren– i-node szám, 2 bájton (0 érték foglalt, törölt fájlt jelöl)– A ‘.’ és ‘..’ minden könyvtárban kötelező, root könyvtár
i-node értéke: 2
• Index node fájl adatait tárolja (kivétel név)– Fájl elhelyezkedésének magadása: indexelt, 13
bejegyzés, ebből 3 indirekt– Lyukak támogatása fájlokban (ilyenkor a blokkcím 0)
• Másoláskor gond lehet…
Szuperblokk
• A fájlrendszer metaadatait tartalmazza– Minden fájlrendszer tartalmaz egy ilyen blokkot– Csatoláskor a kernel memóriába tölti, leválasztásig ott
is marad
• Szuperblokkban tárolt adatok– Fájlrendszer mérete (blokkok)– I-node lista mérete (blokkok)– Szabad blokkok és i-node bejegyzések száma– Szabad blokkok listája– Szabad I-node bejegyzések listája
Szuperblokk, folyt.
• Szabad i-node blokkok nyilvántartása– Csak részleges lista van a szuperblokkban– Ha elfogy, a rendszer szabad blokkokat keres a
diszken
• Szabad diszk blokkok nyilvántartása– Az összes szabad blokkot nyilván kell tartani– Teljes lista szuperblokk-ban tartása nem lehetséges– A szuperblokkban csak a lista „eleje” van, a többi
tárolása adatblokkokban történik• Minél jobban telített a diszk, annál kisebb ez a lista!
Cache
• Korai megoldásokban különálló buffer cache• SVR4 esetén a fájlkezelés a virtuális memóriakezeléssel
integrált• Olvasási művelet (példa)
– Blokk diszk-beli címének meghatározása– Lap foglalás kernelben, megadva az előbb kiszámolt cím– Lap másolása felhasználói térbe – laphiba, adatterület
beolvasása
• Az írás is virtuális memórián át történik, de:– A fájl mérete változhat– Ha nem teljes blokkot ír, akkor visszaíráskor szükség van a
diszken található adatokra is
A fájlrendszer értékelése• Egyszerűsége kiemelkedő, de problémák több területen is
jelentkeznek:– Megbízhatóság– Teljesítmény– Szolgáltatások
• A szuperblokk sérülése a teljes fájlrendszert tönkreteszi• Teljesítmény szempontjából kritikus a teljes i-node tábla partíció
elején való elhelyezése• Az i-node foglalás véletlenszerű, nem ügyel kapcsolatokra (pl. egy
könyvtár fájljai)• A fájlrendszer létrehozásakor a szabad blokkok listája optimális (a
diszk műveletekre nézve), később azonban ezzel nem foglalkozik• A diszk blokkok mérete szintén nem optimális (nagyobb méret,
kevesebb művelet – jobb teljesítmény, de sok pazarlás)• A 14 karakteres fájlnév komoly funkcionális korlát
Berkeley FFS
• Az FFS célja az s5fs korlátainak túllépése volt• Teljesítmény-növelés
– Bár a fájlrendszer továbbra is blokkok tömbjének tekinthető, a műveleteknél figyelembe veszi a diszkek forgási késleltetését
– A fejmozgások csökkentése érdekében a partíciót tovább osztjuk, ún. cilinder csoportokat hozunk létre
• Cél az összetartozó adatok egy cilinder-csoportban tartása• A szuperblokk adatainak egy része is a cilinder-csoportokba
vándorol
• Biztonság növelés érdekében a szuperblokk több példányban „elszórtan” tárolódott
• A helykihasználás javítása (és a teljesítmény növelése) miatt a (s5fs-nél nagyobb méretű) blokkokat oszthatóvá tették
Fájlfoglalási politika
• Fájlfoglalás optimalizálása cilinder-csoportokon keresztül– Egy könyvtár fájljai egy csoportba kerülnek (lokalitás,
gyors könyvtárműveletek)– Új alkönyvtárat eltérő csoportba helyezi– A fájl blokkokat egy csoportba helyezi az i-node
blokkal– A nagy fájlokat „szétkeni” a blokkok között– Szekvenciális blokkok elhelyezése a diszk forgás
függvényében (késleltetések)• Az optimális működéshez legalább 10% szabad
diszk terület szükséges!
Új szolgáltatások
• Hosszú fájlnevek (255 karakter)– Tárolás változó hosszon a könyvtár fájlokban
(a fix 255 hossz túlzás lenne)
• Szimbolikus linkek
• Stb.
Blokkok osztása
• A nagy(obb) blokkméret jót tesz a teljesítménynek, de helyet fecsérelhet– 1 transzfer alatt átvihető adatmennyiség
• Az FFS egy fájlrendszeren belül csak egyféle blokkméretet támogat (ez általános)
• A blokkméret 2 hatványa, legalább 4096 byte– Ezzel a mérettel már elég a kétszeres indirekció
• Kis fájlok miatt az FFS támogatja blokk töredékek használatát– Csak a fájl utolsó blokkja lehet töredéken, a többi
csak teljes blokkot foglalhat (emiatt néha mozgatni is kell)
Értékelés
• S5fs-hez képes jelentős teljesítmény növekedés– 1983: olvasás ~8x, írás ~3x
• Fájlrendszer kihasználási hatékonyság hasonló– Több tényező, kiegyenlítik egymást
• Mai diszkek esetén a sávonkénti blokkok száma eltérő, így az FFS elhelyezési politikája többé-kevésbé elévült
• Összességében az FFS jelentős előrelépés a s5fs-hez képest, azonban innen van még hova fejlődni
Speciális fájlrendszerek, tmpfs
• Átmeneti adattárolás (tmp terület)– Sok alkalmazás intenzíven használ átmeneti fájlokat –
a teljesítmény fontos, a hosszú távú megőrzés szükségtelen
– Sokáig az ún. RAM diszkek használata volt a tipikus, ez viszont a központi memóriát statikusan foglalja
• A különféle speciális fájlrendszer megoldások (pl. Berkeley mfs, Sun tmpfs) dinamikusan használják a (virtuális) memóriát– a tmpfs akár nagyobb is lehet, mint a fizikai memória– a két megoldás közül a tmpfs a fejlettebb
Speciális fájlrendszerek, procfs
• Cél hatékony és elegáns hozzáférés biztosítása a folyamat-adatokhoz (kernel adatok)
• A folyamatok adatait fájlok reprezentálják, hozzáférés egyszerű fájl I/O műveletekkel
• Az adathozzáférés (pl. státusz, creditentals, címtér) mellett (olvasás, esetenként írás) vezérlés is lehetséges (stop, resume, signal)
Tradicionális fájlrendszerek korlátai
• Teljesítmény– Még az FFS sávszélessége is jelentősen elmarad a diszk
potenciális sávszélességétől
• Összeomlás esetén– A cache miatt adat és metaadat is elveszhet, helyreállás során
hosszadalmas konzisztencia ellenőrzés (fsck) szükséges– Minél nagyobb a diszk, annál tovább tart
• Biztonság– A klasszikus Unix hozzáférés kontroll sokszor nem elég finom,
ACL-re lenne szükség
• Méretek– A 32 bit korlátjai…
Naplózás (journaling)
• Alapkoncepció (jelentősen leegyszerűsítve)– Minden változást feljegyzünk egy szekvenciális fájlba
(is)– Hiba esetén csak a fájlt kell ellenőrizni (végrehajtatlan
tranzakciókat keresve)
• Megvalósítás– Jelentős számú tervezési kérdés– Valós referenciák (pl. már a standard Solaris
fájlrendszernek is része a naplózási opció)
Tervezési kérdések
• Naplózás köre: mindent v. metaadat változások• Műveletek vagy értékek naplózása• A napló kiegészíti vagy kiváltja a fájlrendszert• Redo vagy undo-redo logok• Szemétgyűjtés (naplófájl nem használt részei)• Írási szemcsézettség (egyedi, csoport)• Adatvisszanyerés teljesítménye (főleg a kiváltó
megoldásoknál)
Recommended