Opre vizsga, 2008. június 11. megoldással forrásának megtekintése

==Beugró==

''Megjegyzés: ez az oldal jelenleg félkész, ha tudsz valamihez hozzáírni, akkor nyugodtan. Érdemes mindenhez forrást is írni (tankönyből, wikipédiából, diasorokból, stb.), hogy akit érdekel, hozzáolvashasson még az itt leírtakhoz.''

''Hiányzik még:''
* ''beugró 10. kicsit részletesebben, érthetőbben''
* ''nagykérdés 4.  c) rész magyarul''

'''1. Mi a virtuális gép koncepció lényege?'''

* A programok elől az operációs rendszer elfedi a hardver implementációs részleteit, és kibővíti azt plusz funkciókkal.
* Könyv 19. oldal

'''2. Definiálja a hosszútávú ütemezés fogalmát!'''

* A hosszútávú ütemező feladata az elindított feladatok rendszerbe, illetve a "futásra kész" várakozási sorba való beengedését szabályozni. Igyekszik a CPU-t és a perifériákat terhelő folyamatokat egyensúlyban tartani. Batch rendszerekre jellemző; a PC-k oprendszere általában azonnal indítja a folyamatokat, mikor azt a felhasználó kéri.
* [http://en.wikipedia.org/wiki/Scheduling_%28computing%29#Long-term_Scheduler Wikipédia: hosszútávú ütemező]
* Könyv 140. oldal

'''3. Mikor fut a rövidtávú ütemező és mikor jár környezetváltással?'''

* Ha a futó folyamatnak lejár az időszelete (csak preemptívnél), önként lemond a processzorról (együttműködő folyamatok), blokkoló rendszerhívást hajt végre (pl. I/O művelet), egy másik szál futásra kész állapotba kerül (bekövetkezik, amire várt, vagy újonnan elindítanak egy szálat), egy szál prioritása megváltozik, esetleg egy szál processzor-affinitása megváltozik.
* Környezetváltással akkor jár, ha másik szál választódik ki futásra, mint ami eddig futott. Pl. Windows NT alatt, ha a legmagasabb prioritási szinten pontosan egy folyamat van, akkor megtörténhet, hogy ugyanaz a szál fut tovább, és nem történik környezetváltás.
* [http://en.wikipedia.org/wiki/Scheduling_%28computing%29#Short-term_Scheduler Wikipédia: rövidtávú ütemező]
* Könyv 413. oldal

'''4. Hogyan lehet Test_and_Set utasítással kritikus szakaszba lépést (entry) és kilépés (exit) megvalósítani?'''

* Egy változót kijelölünk "lock object"-nek; ha ennek a tartalma 0, nincs senki a kritikus szakaszban. A kritikus szakasz elején egy ciklusban test-and-set-et hajtunk végre rá (az utasítást a ciklus feltételébe téve); ha valaki van a szakaszban már, a ciklusban fogunk keringeni, amíg ki nem lép belőle a másik. Amikor kilépett, a test-and-set következő végrehajtása beállítja a változót, és továbbengedi az egyik várakozó ciklust. A szakaszból kilépéskor pedig simán (nem test-and-set-tel) 0-ba állítjuk.
* [http://en.wikipedia.org/wiki/Test-and-set#Implementing_mutual_exclusion_with_TestAndSet Wikipédia: kölcsönös kizárás TestAndSet-tel]
* Könyv 73.-74. oldal

'''5. Mit nevezünk vergődésnek és hogy lehet védekezni ellene?'''

* Ha több memóriára lenne szüksége a folyamatoknak, mint amennyi rendelkezésre áll, ezért túl gyakran keletkezik laphiba, és a processzor idejének nagy része haszontalan lapcserékkel telik.
* Védekezni ellene például azzal lehet, ha a laphiba-gyakoriság függvényében az ütemező változtatja a multiprogramozás fokát: ha kevés a memória, folyamatokat függeszt fel, és swappel ki; ha van elég, akkor épp ellenkezőleg.
* [http://en.wikipedia.org/wiki/Thrash_%28computer_science%29 Wikipédia: vergődés]
* Könyv 182.-186. oldal

'''6. Milyen részidőkből áll össze a háttértáron levő lapokhoz való tényleges hozzáférési idő? Kis vagy nagy lapok használata esetén kapunk "jobb" byte hozzáférést?'''

* Először a laptáblából kell kikeresni a lap bejegyzését, és konstatálni, hogy nincs hozzá fizikai lap rendelve. Majd, ki kell választani egy szabad fizikai lapot (ha nincs, ki kell vinni egyet háttértárra), a szabad helyre beolvasni a lapot, majd újraindítani a laphibát okozó utasítást. Ezek közül a háttértárról olvasás nagyságrendekkel lassabbb a többinél, ezért lényegében ez határozza meg a teljes hozzáférési időt.
* Ha csak a háttértáron lévő lapokat nézzük, akkor, mivel kisebb lapot gyorsabban lehet beolvasni, ezért kisebb lapoknál gyorsabb a hozzáférés. Ha egy folyamat teljes munkahalmazát nézzük, akkor viszont a kisebb lapok több adminisztrációs költséggel járnak (gyakrabban kell háttértárhoz fordulni), és átlagban a nagyobb lapok adnak jobb eredményt.
* Könyv 175.-177. és 186. oldal

'''7. Az éppen futó taszkot megszakítja egy IT. Preemptív OS esetén mindig a megszakított taszk fogja-e visszakapni a futási jogot? Miért?'''

* Nem feltétlenül; például a preemptálás maga is úgy működik, hogy egy időzítő a szál quantumjának lejártakor megszakítást generál; ilyenkor értelemszerűen az ütemező általában nem ugyanazt a folyamatot választja ki futásra.
* [http://en.wikipedia.org/wiki/Preemption_%28computing%29#Time_slice Wikipédia: időszelet]
* Windows ütemezés diasor, 8. dia

'''8. Melyik az az alrendszere a Windowsnak, ami nélkül nem tud futni?'''

* A Windows alrendszer, avagy Client/Server Runtime SubSystem (csrss.exe). Ennek kilövése kékhalált eredményez.
* [http://en.wikipedia.org/wiki/Client/Server_Runtime_Subsystem Wikipédia: CSRSS]
* Windows bevezető diasor, 25. dia

'''9. Mely utasításokkal és miért történik a memóriafoglalás két lépésben Windows alatt?'''

* A két lépés: Reserve és Commit. Az első csak címtartományt foglal, amögött nem lesz ténylegesen használható memóriaterület; a másik a már lefoglalt címtartományhoz rendel fizikai memóriát.
* (MZ): "a már lefoglalt címtartományhoz rendel fizikai memóriát" --> virtuális memóriát. A lefoglalt lap lehet a fizikai memóriában vagy a lapozófájlban.
* A folyamatok címtartományának töredezettsége csökkenthető azzal, ha a címtartományt már akkor előre foglalja, mikor a memóriára még nincs szüksége, és ez nem jár olyan memóriapocsékolással, mintha fizikai memóriát is foglalna ugyanakkor.
* Windows memóriakezelés diasor, 9. dia

'''10. Milyen részekből áll az RPC technológia?'''

* RPC: Remote Procedure Call, távoli eljáráshívás. Magas szintű folyamatok közti kommunikációt tesz lehetővé. Részei:
* interfész leírás
* programgenerátor
* kommunikációs infrastruktúra
* Unix folyamatok kommunikációja diasor, 12. dia

'''11. UNIX alatt milyen rendszerhívásokra van szükség ha a user elindít egy programot ( folyamat létrehozása és programkód betöltése)?'''

* Folyamatot létrehozni a fork() hívással, majd betölteni a programkódot pedig az exec() hívással lehet

'''12. Soroljon fel legaláb 4 UNIX folyamatok között kommunikációs megoldást!'''

* System V IPC: szemafor, osztott memória, üzenetsor
* Csővezeték és nevesített csővezeték
* Jelzések
* Socketeken keresztüli kommunikáció
* RPC
* Folyamat-nyomkövetés
* Unix folyamatok kommunikációja diasor, 2. dia
* Könyv 312.-322. oldal

==Nagyfeladatok==

'''1. Ismertesse a multiprogramozott rendszerek működését. Vezesse le ebből a multiprogramozott operációs rendszerek fő feldatait. Mutassa be a legfontosabb különbségeket a SPOOLING rendszer és a multiprogramozott rendszer között.'''

* A multiprogramozott operációs rendszerek feladatai:
** Tárgazdálkodás: annak biztosítása, hogy több folyamat és a rendszer kódja és adatai megfelelően el legyenek helyezve a rendelkezésre álló memóriában illetve háttértáron.
** Ütemezés: a folyamatok állapotának nyilvántartása, és közülük bizonyos alkalmakkor a futtatandó kiválasztása; folyamatok indítása és leállítása.
** Védelem: annak biztosítása, hogy a folyamatok csak ellenőrzött módon befolyásolhassák egymás és a rendszer működését.
** Erőforrások adminisztrálása: az eszközök nyilvántartása, annak felügyelete, hogy mikor ki férhet hozzájuk. Bizonyos erőforrások esetén kölcsönös kizárás biztosítása, a holtpont kezelése vagy megelőzése.
** Kommunikáció: lehetőség nyújtása a folyamatoknak az egymással, a hardverrel, a felhasználóval, a hálózattal illetve más gépekkel való kommunikációra. Folyamatok közti szinkronizációs eszközök biztosítása.
** Felhasználóbarát környezet biztosítása.
* _FIXME_: különbségek
* Könyv 129. oldal

'''2. Ismertesse a holtpont (deadlock) kezelésénél alkalmazható ún. "elkerülés" módszerét. Térjen ki a módszer jellemzőire, az alkalmazásához szükséges feltételekre illetve a módszer megvalósításánál alkalmazott algoritmusokra.'''

* A holtpont problémájára négyféle megközelítés létezik:
** Nem veszünk róla tudomást (strucc algoritmus);
** Megpróbáljuk észrevenni, ha létrejön, és megszüntetjük (detektálás, feloldás);
** Magát a rendszert úgy tervezzük meg, hogy ne alakulhasson ki (megelőzés);
** Csak akkor teljesítjük az erőforráskérelmeket, ha biztosan nem vezet holtpontveszélyre (elkerülés).
* Elkerülés: a rendszer a folyamatok kéréseit csak akkor teljesíti, ha a teljesítés után kialakuló állapot biztonságos. Egy állapot akkor biztonságos, ha legrosszabb esetben (hirtelen mindenki a maximális igénnyel jelentkezik) sem alakul ki holtpont. 
* A biztonságosság eldöntéséhez folyamatoknak előre be kell jelenteniük a maximális erőforrásigényüket; valamint az algoritmus nincs felkészítve arra, hogy új folyamatok indulnak el.
* Megvalósítani a bankár-algoritmus segítségével lehet, amit minden kérésnél eldönti, biztonságos-e teljesíteni:
** Ellenőrizzük, hogy van-e annyi, amennyit kérnek; ha nem, leállunk.
** Ellenőrizzük, hogy nem kér-e többet, mint szabadna (az előzetes bejelentés alapján). Ha igen, hibával leállunk.
** Az aktuális erőforrás-foglaltsági táblázat alapján készítünk egy másikat: hogy milyen helyzet alakulna ki a kérés teljesítése esetén.
** Az új állapotról eldöntjük, biztonságos-e. Ha igen, a kérést teljesítjük, ha nem, elutasítjuk.
* A biztonságosságot a Coffman-algoritmushoz hasonlóan ellenőrizzük:
** Az adott állapotban megpróbálunk olyan folyamatot keresni, aki tovább futhat (mert kielégíthető az igénye), és frissítjük a táblázatot úgy, mintha lefutott volna, és felszabadította volna az erőforrásait.
** Ezt ismételgetjük; ha elfogynak a folyamatok, akkor a kiinduló állapot nem volt holtponton a maximális kérések ellenére sem, tehát az állapot biztonságos.
** Ha marad néhány folyamat, akik közül senki nem futhat tovább, akkor elég nagy kérés esetén az állapotból kialakulhat holtpont, tehát nem biztonságos.
* Ha minden erőforrásfajtából csak 1 van, akkor van egyszerűbb módszer is: az állapot akkor biztonságos, ha a foglaltsági gráfban nincs kör, még ha minden lehetséges kérés élét berajzoljuk, sem.
* [http://en.wikipedia.org/wiki/Banker%27s_algorithm Wikipédia: bankár-algoritmus]
* Könyv 87. és 94.-98. oldal


'''3. Magyarázza el a változó méretű memória partíciók lefoglalásánál használt'''
* '''a, first fit'''
* '''b, next fit'''
* '''c, best fit'''
* '''d, worst fit'''
*algoritmusokat. Egy rendszerben az adott pillanatban 300K, 650K, 100K, 600K, 200K és 1500K méretű szabad területek vannak. Hogyan fog a fenti négy algoritmus sorrendben 377K, 220K, 159K, 429K és 120K méretű partíciónak helyet foglalni?*

* First fit: az első olyan szabad blokkból foglal helyet, amelyikben elfér. Gyors, kb. 30% marad kihasználatlan.
** 377K foglalása: a 650-esben fér el, marad: 300, 273, 100, 600, 200, 1500.
** 220K foglalása: a 300-asban fér el, marad: 80, 273, 100, 600, 200, 1500.
** 159K foglalása: a 273-masban fér el, marad: 80, 114, 100, 600, 200, 1500.
** 429K foglalása: a 600-asban fér el, marad: 80, 114, 100, 171, 200, 1500.
** 120K foglalása: a 171-esben fér el, marad: 80, 114, 100, 51, 200, 1500.
* Next fit: az első olyan szabad blokkból foglal helyet, amelyikben elfér, de nem az elejétől, hanem a legutolsó lefoglalttól kezdi. Kb. 30% marad kihasználatlan.
** 377K foglalása: első foglalás, az elejétől kezdjük a keresést. A 650-esben fér el, marad: 300, 273, 100, 600, 200, 1500.
** 220K foglalása: az előzőleg használt második blokktól kezdjük a keresést, abban el is fér. Marad: 300, 53, 100, 600, 200, 1500.
** 159K foglalása: a második blokktól kezdjük a keresést, a 600-asban fér el, marad: 300, 53, 100, 441, 200, 1500.
** 429K foglalása: a negyediktől kezdjük a keresést, abban el is fér, marad: 300, 53, 100, 12, 200, 1500.
** 120K foglalása: a negyediktől kezdjük a keresést, a 200-asban fér el, marad: 300, 53, 100, 12, 80, 1500.
* Best fit: a legkisebb helyre teszi be, ahova még befér. 30%-nál több marad kihasználatlan.
** 377K foglalása: a 600-asben fér el, marad: 300, 650, 100, 223, 200, 1500.
** 220K foglalása: a 223-asban fér el, marad: 300, 650, 100, 3, 200, 1500.
** 159K foglalása: a 200-asban fér el, marad: 300, 650, 100, 3, 41, 1500.
** 429K foglalása: a 650-esben fér el, marad: 300, 221, 100, 3, 41, 1500.
** 120K foglalása: a 221-esben fér el, marad: 300, 101, 100, 3, 41, 1500.
* Worst fit: a legnagyobb helyre teszi be. Kb. 50% marad kihasználatlan.
** 377K foglalása: az 1500-as a legnagyobb, marad: 300, 650, 100, 600, 200, 1123.
** 220K foglalása: az 1123-as a legnagyobb, marad: 300, 650, 100, 600, 200, 903.
** 159K foglalása: a 903-as a legnagyobb, marad: 300, 650, 100, 600, 200, 744.
** 429K foglalása: a 744-es a legnagyobb, marad: 300, 650, 100, 600, 200, 315.
** 120K foglalása: a 650-es a legnagyobb, marad: 300, 530, 100, 600, 200, 315.
* Könyv 165.-166. oldal

'''4. A Windows memóriakezelése'''
* '''a) Milyen és mekkora részekből épül fel egy folyamat virtuális címtartománya 32 bites Windows operációs rendszeren? Mik tárolódnak az egyes részeken?'''
* '''b) Hol tárolhatja az operációs rendszer egy folyamat által lefoglalt virtuális memórialapokat? Mi alapján dönti el, hogy melyik lehetőséget válassza?'''
* '''c) Vázolja, hogy egy fizikai memórialapnak milyen állapotai lehetnek, milyen típusú memórialistán szerepelhet! Jellemezze az egyes állapotok közötti átmenetet!'''

* a) Alapból 2GB felhasználói módú és 2GB kernel címterület van, ezt a /3GB kapcsolóval 3GB felhasználói és 1GB kernelre lehet módosítani. A felhasználói rész minden folyamatnak különálló, itt tárolódik a folyamat kódja, adatai, és a (user módú) verme. A kernel terület csak kernel módból érhető el, és minden folyamat ugyanazt látja. Itt található az Executive, a kernel és a HAL kódja, a rendszerszintű adatok, a kernel módú driverek, és minden szál kernel módú verme.
* Windows memóriakezelés diasor 5.-8. dia

* b) A memóriakezelő kevés szabad fizikai memória esetén háttértárra mentheti az egyes lapokat. Ezt a műveletet nevezzük lapozásnak (paging). A folyamatok a memórialapokat foglalhatják a rendszer ún.
** lapozott memória tárából (paged memory pool) és a
** nem lapozott memória tárából (nonpaged memory pool).
* A két memóriatár közötti különbség a lapozásnál van. A nem lapozott memória tárából történt memóriafoglalás esetén a kért memórialapot a rendszer állandóan a fizikai memóriában tartja, sosem menti háttértárra. Ezzel lehet biztosítani, hogy valamilyen szempontból fontos (például driverek által használt) memóriaterületek akkor is a fizikai memóriában maradjanak, ha ritkán használják őket.
* (MZ): a paged és nonpaged memory pool kernel módú memóriafoglalásra való csak, ez a válasz nem jó. Ráadásul az első kérdés nincs is explicite megválaszolva.

* c) lásd Windows memóriakezelés diasor 12. dia

'''5. Rajzolja fel a UNIX NFS kliens és szerver megvalósításának vázlatos felépítését, majd a rajz alapján ismertesse a virtuális fájlrendszerek működését és előnyét!'''

* A virtuális fájlrendszerek lényege, hogy a sokféle módon, fájlrendszerben tárolt fájlokat ugyanúgy kezelhessem, ne kelljen mindegyiket máshogy. Ez úgy oldható meg, hogy a konkrét FS-eket kezelő eszközök fölé rakok egy közös interfészt, ez a vnode/vfs interfész. Ha fájlt akarok megnyitni, az interfésztől kérem, és ő továbbpasszolja annak a kezelőnek, akihez tartozik, majd a választ vissza nekem.
* NFS: Network File System. Lényege, hogy másik gépen lévő fájl is ugyanúgy megjelenhet a helyi fájlrendszerben, mint a fizikailag itt lévők. Ehhez kell egy olyan eszköz, amitől ha fájlt kér valaki, akkor a kérést közvetíti a másik gépnek.

[[Fájl:Opre_NFS_felepites.png]]

* A kliensben a vfs-től kérek egy másik gépen lévő fájlt. A vfs látja, hogy a kért fájl NFS fájlrendszeren van tárolva, ezért a NFS klienstől kéri. Ő a hálózati kapcsolaton keresztül RPC-vel kapcsolatba lép a másik gép NFS szerverével, és kéri tőle a fájlt. A szerver a saját gépe vfs-éhez fordul, aki a helyi fájlrendszertől (pl. ext2) kéri azt. A válasz ugyanezen az úton visszafele halad végig.
* [http://en.wikipedia.org/wiki/Virtual_file_system Wikipédia: virtuális fájlrendszer]
* UNIX fájlrendszerek diasor, 18. dia
* Könyv 339.-342., 366.-368., 372.-373. oldal

[[Category:Infoalap]]