Dr. Galambos Gábor Operációs rendszerek általános elmélete 2013-2014
Tartalom 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14.
Bevezetés Az operációs rendszerek története Az operációs rendszerek szerkezete Az operációs rendszerek felületei Memóriaszervezés Virtuális memória-kezelés Folyamatok szervezése Ütemezés Folyamatok interakciói Megszakítások, I/O kezelés Készülékek kezelése Állományok kezelése Hibakezelés, megbízhatóság, védelem Rendszerszerkesztés, rendszerkönyvelés 2
1
1. Bevezetés OR nélküli számítógép olyan mint a vezető nélküli busz: Mi történik a buszon, ha nincs vezető, és a „nyers erő” dönti el a menetirányt? Mi történik a számítógépen, ha nincs OR, és mindenkinek önmagának kell gondoskodnia az erőforrások biztosításáról? Készíthető-e univerzális operációs rendszer? Funkciók tekintetében a szövegszerkesztő és az OR hasonló elvek alapján kezelhető. 3
Az operációs rendszer határai Probléma: a hardver elemek kódolt formában tárolják az adatokat, és ezek közvetlen felhasználása nehéz. Ezért a hardver elemeket el kell látni olyan szoftverekkel, amelyek az információ kinyerését megkönnyítik. hardver
+
erőforrás
szoftver
=
Számítógépes rendszer
fizikai logikai rendszerprogramok 4
2
A rendszerprogramok típusai: • • • •
Fordítók (compilerek, interpreterek) Szerkesztők (linkerek) A rendszer ellenőrzését végző programok Hibakezelő programok
5
Mit tekintsünk az OR részének? A teljes számítási környezetet (fordító, szerkesztő, stb…) Csak erősen korlátozott részét (ami mindvégig a memóriában helyezkedik el: Kernel) A mi szemléletünk szerint: az OR a hardver környezet és a felhasználói környezet között helyezkedik el. (két része van: hardver interface, felhasználói interface) Másik fajta közelítés: a „vas” a hardver a szoftver az OR Probléma: ha pl. a szorzás nem „huzalozott”, hanem program valósítja meg. Olcsó a hardver, ezért hardver úton valósítanak meg szoftver 6 funkciót. (pl. memória kiosztás)
3
Felhasználói környezet
Operációs rendszer
Számítógépes rendszer 7
Az operációs rendszerek feladatai Elsődleges feladata szervezni az erőforrásokat. Ez két fő céllal történik: Kényelmes használat (hatékonyság, alakíthatóság) Ellenőrzött kiosztás (hibás programok esetén, nem megengedett műveletek végrehajtása esetén, közös erőforrások kezelése esetén.) Emellett hatékony és igazságos legyen!
8
4
Számos kiegészítő feladat: • • •
A felhasználói interface (Parancsinterface, Programinterface) Memóriakezelés – cserélés (swapping) Programok szervezése (ha 1 CPU) • Egy program fut egy adott időben a memóriában a befejezésig • Több program futásáról kell gondoskodni
• • • • • •
Készülékkezelés + megszakítások Állománykezelés Elem- és csomagkezelés (Job and Session Managment) Hibakezelés (Hardver hibák , Szoftver hibák) Megbízhatóság és védelem Felügyelet és elszámolás 9
2. Az OR-k története Középpontban: a hardware fejlődése, és azok hatékony üzemeltetésére kidolgozott OR-k közötti kölcsönhatás áll. 1. Élet operációs rendszer nélkül Először egy induló címet adunk be az adatoknak Majd egy sor kapcsoló beállítása Egy gomb lenyomásával bejuttatjuk az adatokat a gépbe Ezt a műveletsort addig ismételjük, amíg az összes programlépést és az adatokat is be nem juttattuk a számítógép memóriájába. Az adatok kiolvasása is hasonló. Egy ilyen jellegű munka esetén a programozó teljes ellenőrzés alatt tartotta a gépet: egy időszakra igényelte a gépet, és egyedül használta ezidő alatt. Ezt nevezzük open shop rendszernek. 10
5
A helyzeten először az egyszerű I/O készülékek csatlakoztatása segített: írógép, lyukszalagos készülékek, lyukkártyás I/O-rendszer Közben a programozás is fejlődött. Következmény: Fordító programok (assembler) Szerkesztő (linker) programok
Első rendszerprogramok 11
Egy assembler program futtatásához szükséges lépések, egy kártya I/O-val rendelkező gépen:
1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.
Töltsük be a betöltő (loader) programot. Töltsük be az assembler programot. Olvassuk be a programot. Fordítsuk le a programot és készítsünk outputot kártyákra a lefordított gépi kódú utasítássorozatról. (célprogram) Töltsük be ismét a loadert. Olvassuk be a célprogramot. Olvassuk be a programkönyvtár megfelelő elemeit. Olvassuk be a szerkesztő programot. Szerkesszük össze a futtatható programot a célprogramból és a programkönyvtár szükséges elemeiből, majd készítsünk lyukkártyás outputot erről. Töltsük be újra a loadert. Töltsük be a futtatható programot. Futtassuk le a programot. 12
6
Jelentős javulás
Mágnesszalagos tárolók
Gyorsabb feldolgozás
Programok egész sora várakozott Operátor
Még mindig jelentős a holtidő
Automatizálni kellene az operátor munkáját 13
Supervisor programok és I/O-rendszerek Input/Output System supervisor program (1953-54 ) Az IBM alkalmazók a GM szakembereivel együtt dolgozták ki. (IBM 701) SHARE Operating System (SOS) SHARE felhasználói csoport specifikációja + IBM Több funkció: supervisori feladatok + I/O kezelés + assembly fordító. FORTRAN Monitor System (FMS) GM + North American Aviation (IBM 701). Alkalmas magasszintű programnyelven megírt programok feldolgozására. 14
7
A supervisor programok jó hatékonysággal működtek mindaddig, amíg valamilyen szabálytalan dolog be nem következett. Probléma: A programok – elsősorban méreteik miatt – nem voltak alkalmasak a hibák felfedezésére, azok elhárítására, vagy csak erősen korlátozott számban kezelték az ilyen eseteket.
15
Szalagos és lemezes operációs rendszerek Mágnesszalagok megjelenése
Egyre sűrűbben használták ezeket a háttértárolókat adatok tárolására
„fontos” szalagok
„kevésbé fontos” szalagok
(Állandóan a szg.-hez kötve)
(Csak ha szükség volt rájuk)
Szalagos operációs rendszerek (TOS) 16
8
Mágnesszalagot viszonylag rövid idő után felváltja a mágnesdob. A mágnesdob működési elve. A mágnesdob előnye: gyors elérés, nagyobb adattárolási kapacitás. Az új hardverelem új kezelési technikákat követelt: Megjelent a rezidens loader (ez tölti be az OR-t, a felhasználói programokat, és előkészíti azokat a futásra.) A fenti feladatok ellátása után átadta a vezérlést az OR egy másik részének. Ez csak akkor lehet, ha nagyobb mennyiségű operatív memória áll rendelkezésre. 17
Ahhoz, hogy az új programokat hatékonyan tudják használni, szükség volt olyan utasításokra, amelyek megmondták az ORnek, hogy a végrehajtás során milyen erőforrásokat alkalmaznak a progamok. A parancsokat a Job Vezérlő Nyelv (Job Control Language = JCL) segítségével írták le. A feldolgozás során egy új program futásának előkészítéséhez az OR először betöltött egy speciális rendszer-szubrutint, értelmezte a JCL utasításokat, megtette a szükséges lépéseket.
18
9
Az I/O készülékekk száma jelentősen megnőtt, ezért a DOS OR I/O Ellenőrző Rendszere (I/O Control System = IOCS) jelentősen feljavult: A különböző készülékek kezelésével, támogatásával szubrutinok egész sora foglalkozott.
A működés szempontjából fontos rutinok állandóan a memóriában maradtak. Ezek a működés szempontjából kritikus készülékeket támogatták. Ez az OR rezidens része. Más készülékek kezeléséhez a rutinokat csak akkor illesztették a programokhoz, ha azokra szükség volt. Ez az OR tranziens része.
19
A DOS OR-ket már a gyártó cégek készítették. Mindenki arra törekedett, hogy a saját maga által épített „vas” lehetőségeit a legjobban kihasználja.
Nem törekedtek olyan OR elemek kidolgozására, amelyek változtatás nélkül átvihetők lettek volna más gépekre. Géptípus
OR
Honeywell 1800
ADMIRAL
UNIVAC 1107
EXEC 1
Control Data
SCOPE
Burroughs 5000
Master Control
IBM 7090
IBSYS 20
10
Egy assembler program futtatásához szükséges lépések, egy DOS OR-rel rendelkező gépen:
1. A JCL feldolgozó program megvizsgálja a JCL-ben leírt 2. 3. 4. 5. 6.
parancsokat. A JCL parancsoknak megfelelően az OR betölti és elindítja az assembler fordító programot. Az assembler beolvassa az input programot. Előállít egy olyan célprogramot (object modul), amely még tartalmaz feloldatlan referenciákat, és ezt a „félkész” programot ideiglenesen mágneslemezre helyezi el. Követve a JCL parancsait a szerkesztő kerül betöltésre és végrehajtásra azért, hogy a megfelelő szubrutinokat a célprogrammal összeszerkessze. Az elkészült futtatható programot betölti az OR a memóriába, és a program – mint elkészült felhasználói program – végrehajtódik. 21
Multiprogramozás batchben Soros kötegelt feldolgozási rendszer Többprogramos kötegelt rendszer Az első ilyen OR a Master Control Program (MCP) volt. Két új elvet használ: Virtuális memóriakezelés elve Prioritások használata A többprogramos batch rendszerek legismertebb képviselői az OS/360 az IBM 360-as számítógépekre alkalmazott két változat: OS/MFT OS/MVT További újítás: a spool technika. 22
11
Időosztásos rendszerek (time sharing) A kötegelt feldolgozásnál: A közvetlen ellenőrzésre nincs lehetőség A holtidő is igen nagy Gyors mágneslemezegységek jobb kihasználása: nem csak spool technikára használták, hanem a rendszerprogramok nagy része is lemezen van.
A programok gyorsan aktiválhatók.
Ha csak néhány JCL utasítást kell javítani, akkor azt interaktív terminálról megteheti a programozó. (Interaktív feldolgozás) 23
Probléma: A kötegelt feldolgozás során egyszerre több program van a memóriában, de vezérlésátadás csak ún. „megállási pontokon” valósulhatott meg a programok között. Ennek az az eredménye, hogy egyes programok percekig (vagy akár órákig) is futottak megállás nélkül. Az interaktív technika ezt nem engedhette meg.
Kialakul az időosztásos (time sharing) üzemmód: egy óra méri a legutolsó vezérlésátadás óta eltelt időt, és azonnali vezérlésátadást hajt végre, ha az időszelet lejár. A vezérlés átadódik a várakozó programok egyikére, és az éppen megszakított program várakozni kényszerül.
24
12
Az ilyen rendszerek fénykora a 60-as 70-es évekre esett. Korai képviselői: Compatible Timesharing System (CTSS): DEC PDP-1 Darthmouth Timesharing System (DTSS): General Electric IBM TS/360-as rendszere Egyre több programozó akarta kihasználni az interaktivitás nyújtotta lehetőségeket. Ez azt eredményezte, hogy a rendszer egyre több időt töltött azzal, hogy a programok között ide-oda kapcsolt. A tényleges munkára egyre kevesebb idő jutott. Új, gondosabban kifejlesztett supervisor programra volt szükség: 25
MIT, AT&T, GE közös fejlesztése: MULTICS Több új gondolat: szegmentált virtuális memória hierarchikus filerendszer megalkották a készülékfüggetlen I/O fogalmát alkalmazták az I/O átirányítás módszerét hatékony felhasználói interface Legnagyobb előnye: magasszintű programnyelven íródott (PL/I), ezért könnyen fejleszthető.
26
13
A UNIX operációs rendszer MULTICS tapasztalatai – Thompson új, egyfelhasználós OR : UNIX.
és
Ritchie,
1970.
Felhasználói kényelem Egyszerű, hatékony hierarchikus felépítésű file-rendszer, amelyhez egy jól kezelhető parancsinterpreter kapcsolódott (shell). A filerendszer az I/O készülékeket speciális állományként kezelte, A shell a parancsai által gyártott outputokat képes volt átirányítani bármelyik állományba vagy készülékbe. Ugyanilyen rugalmasság az input kiválasztására is. Első változatai egyfelhasználós rendszerként működtek, de képesek voltak egyidejűleg több program futtatására is. (folyamatok vagy process-ek)
27
Az első változatot PL/I-ben írták, de ez nem volt implementálható PDP számítógépekre. Richie: fejlesszünk ki egy új nyelvet. Megalkották a C programnyelvet, majd az egész UNIX-ot átírták C-re. Javításra szokatlan megoldás: kiadták a kísérleti rendszert az egyetemeknek forrásprogramokkal együtt. A kutatók és a hallgatók között gyorsan népszerű lett a könnyen alakítható rendszer. Számos változat jött létre. A legnépszerűbb: Berkley UNIX. A UNIX lett az első olyan OR, amely a hardvertől függetlenül terjedhetett. Ezzel a UNIX lett az első hordozható OR. 28
14
Absztrakt és virtuális gépek ’60-as évek vége – Egyesült Államok – MULTICS fejlesztése Európa – Eindhoveni Egyetem – Edgar Dijsktra vezetésével kidolgozzák a T.H.E. OR-t. A T.H. E. újdonsága: Interaktív folyamatok kezelésében (holtpont, szinkronizáció) A rendszer hierarchikus felépítése (különböző szintek – az alsó két szint egy ún. absztrakt gépet szolgáltatott. Az absztrakt gépek megvalósítása úgy történt, hogy a rendszer komponenseit szintekre bontották. Az egyes szintek csak a velük szomszédos szintekkel tartották a kapcsolatot. 29
0.szint
Eljárás vezérlése, megszakítások kezelése
1.szint
Virtuális memóriakezelés
2.szint
Felhasználói konzol kezelése (user interface)
3.szint
I/O kezelése
4.szint
Felhasználói programok
5.szint
Az operátor
A T.H.E.-n definiált struktúra 30
15
A rendszer hierarchikus felépítését több OR alkalmazták. Legismertebbek:
fejlesztése során is
TENEX: olyan filerendszert is magába foglaló absztrakt gépet szolgáltatott, amely megengedte minden felhasználónak egyidőben több process futtatását, és biztosította a virtuális memóriát. IBM CP/CMS (Control Program / Conversational Monitor System): Olyan OR készítése, amely az IBM minden fejlesztési munkáját támogatja. Ehhez kellett a virtuális gép koncepciója.
31
OR-ek kis számítógépekre A hardware elemek ára (és mérete) rohamos csökken. Különböző kategóriák a számítógépek között: mini, mikro, személyi számítógépek. Kezdetben a „kisgépek” a nagyobb társaik felépítésének filozófiáját követték, majd fokozatosan önálló irányban fejlődtek tovább. Ugyanez figyelhető meg az OR-knél is: A kisgépek az egyfelhasználós rendszerek irányába indultak el. (Később alakultak ki ebben a kategóriában a többfelhasználós rendszerek.) DEC-PDP: megszakítások, közvetlen memóriacímzés a gyors I/O készülékek számára. IBM 1800: 16 bites CPU, gyűjtőregiszterek, indexregiszterek. 32
16
Ahogy csökkentek a méretek és az árak, úgy nőtt az igény a többfelhasználós rendszerek iránt: PDP-110 – TOPS OR: a time sharing szűkített változata. PDP-11 – RT-11 OR: speciális multiprogramozás két programmal. Megjelennek a nyomtatott áramkörök, a méretek és az árak további csökkenésével a mikroprocesszorok bonyolultsága is egyre nőtt. 60-as évek vége: zsebszámológépek megjelenése. Kalkulátorok fejlődése: bennük a chipek egyre bonyolultabbak, nehezen kezelhetőek: új elveken működő, általános célú processzorra volt szükség: INTEL: 4004, 8008, 8080, Zilog: Z-80, Motorola: 6800. 33
A memóriák méretének és árának csökkenése: Megszülettek a mikroszámítógépek (SINCLAIR, COMMODORE, APPLE II, WANG, …, IBM) A mikroszámítógépes hardver nagyon gyorsan fejlődött, de a rendszerszoftver ezekre a gépekre sokáig késett: Kezdetben egyszerű loadereket használtak, amelyet ROM-ban helyeztek el. Az első OR (Gary Kildall) – CP/M: egyfelhasználós OR (INTEL 8008) SCP-DOS (INTEL 8086-ra) MS-DOS (’90-es évek eleje, Microsoft Corporation) Megjelentek a Windows különböző generációi. (Ezek már több felhasználós rendszerek igényes felhasználói felülettel.) 34
17
A UNIX hosszú ideig nem volt alkalmazható mikroszámítógépes környezetbe, mégis erős hatást gyakorolt az OR-k fejlődésére: az MS-DOS változataiban egyre gyakrabban lehetett találkozniolyan elemekkel, amelyek először a UNIX-ban jelentek meg (pl. hierarchikus filerendszer, I/O átirányítás). Új irány: 1970-ben a Xerox Corporation új fejlesztő központot hozott létre (Palo Alto Research Center), amely új felhasználói felületet kínált az ALTO gépéhez: az ikonokat, amelyek kezelése az egérrel történt. Munkaállomásként használták. Ez a fejlesztési irány „szülte” az APPLE-Machintosht és a Sunt. Az egyfelhasználós munkaállomások - új típusú OR kifejlesztése megszületett a nyitott OR gondolata: a középpontban kényelem és nem az ellenőrzés áll. Az OR szolgáltatást nyújt. Eltűnik az éles határ az OR és a 35 felhasználói programok között.
Hálózatok és osztott rendszerek A különböző számítógépek összekapcsolásának gondolata nagyon régi. Már a ’60-as években is készítettek adattovábbításra alkalmas készülékeket, amelyekkel számítógépek váltak összekapcsolhatóvá. Az első hálózatot az USA Védelmi Minisztériumának megbízásából hozta létre a Department of Advanced Research Project ARPANET néven. Minden gépnek saját OR-e volt. A kommunikáció speciális I/O tevékenység. Az adatátvitelhez ismerni kellett a távoli gép adatformátumát Rendelkezni kellett speciális jogokkal Megengedte a távoli gépek interaktív felhasználását is. 36
18
Az első olyan OR-t, amely a hálózatot az erőforrások egységes rendszereként kezelte Millstein készítette 1977-ben. Ebből fejlődtek ki a hálózati operációs rendszerek, amelyek a következő elveken működnek: Az összekapcsolt gépek mindegyike önálló OR-rel rendelkezik. Minden számítógépnek van saját – lokális – felhasználója, de az egyes felhasználók számára a többi számítógép erőforrásai is rendelkezésre állnak. Ezért egy felhasználónak lehetősége van arra, hogy bejelentkezzen távoli gépekre is, és ott azok erőforrásait használja, ill. adatokat mozgasson gépek között. A fenti elvekre épülő OR-k alapfelépítésükben nem különböznek a klasszikus OR-ktől. (Novell-NetWare) 37
Más elveken működnek az un. osztott operációs rendszerek: Úgy látják, mintha egyetlen gép állna rendelkezésre, de a rendszer ténylegesen több processzort vagy gépet tartalmaz. A felhasználó az erőforrásokat úgy tudja kezelni, mint a saját gépének bármely erőforrását. (Sem a futó programok sem a felhasználó nem tudja, hogy fizikailag hol található az erőforrás.) Az ilyen OR egyik legnagyobb előnye a sebességnövekedés. Ebben van a probléma is: a különböző sebességű processzorok miatt az algoritmusokat párhuzamosítani kell, és a processzorok működésének ütemezése is bonyolult. 38
19
3. Az OR-k szerkezete Nincs olyan struktúra, amely egyértelműen jobb a többinél! De a főbb szempontok, amelyeket a legtöbb OR-nél figyelembe kell venni: 1. Forráskódok szervezése 2. Társzervezés 3. Végrehajtási struktúrák a) Klasszikus szervezés b) Rendszereljárások alkalmazása c) Nyitott környezetek 4. Komponensek interakciója a) Korlát nélküli interakció b) Modulok elkülönítése c) Absztrakt gépek d) Virtuális gépek 5. Adaptálhatóság 39
Forráskódok szervezése OR összeállítása forráskódú elemekből: az alkalmazott eljárás azonos az egyéb nagyméretű software rendszereknél használatos eljárásokkal: Forrásnyelvű modulokat készítünk, amelyekből egy fordító program segítségével gépi kódú (object) modulokat állítunk elő, Melyekből elemeket szerkesztünk úgy össze, hogy futtatható (load) modulokká álljanak össze Egy OR számos futtatható modult tartalmaz, melyek valamilyen másodlagos tárolón helyezkednek el. 40
20
Szempontok, melyeket egy OR tervezésekor mindenképpen érdemes figyelembe venni: Egy eljárás ne legyen két oldalnál hosszabb – áttekinthetőség Az egy egységbe tartozó forráskódot és adatot kezeljünk együtt. Egy modul a lehető legkevesebb más modullal kerüljön kapcsolatba – függetlenség elve. A modulok közötti kapcsolat tartásához egyszerű, áttekinthető interface-ket használjunk. Úgy készítsük el a modulokat, hogy egy szükséges változtatás a lehető legkevesebb modulra gyakoroljon hatást. A fenti szabályok nem OR specifikusak. Minden nagyobb felhasználói rendszernél is hasonló elveket kell követni. 41
Az OR-k esetén komolyan „egyensúlyoznunk” kell az összefogott kódolás és a hatékonyság között. Az OR hatékonyságát nagymértékben befolyásolja, hogy: milyen nyelven íródtak! Sokáig tartotta magát az a nézet, hogy jó OR-t csak assembly nyelven lehet írni. Okai: Egy OR-nek a fizikai erőforrásokat ellenőrzés alatt kell tartani. Regiszterek és más speciális memóriahelyek tartalmát ismerni kell. Probléma: mindezek egy magasszintű nyelven megírt program futtatható modulja számára tiltott elérésű helyen vannak. A helyzet a 90’-es évek során változott meg. 42
21
Okai: A hardver eszközök nagymértékű fejlődése: nagyobb memóriaterület, sokkal nagyobb sebesség. Így a hosszabb fordítási időés a redundáns fordítás nem akadály. Több olyan magasszintű programnyelv készült, amelyeket kifejezetten OR-k fejlesztésére kívántak használni. Ezek az un. Rendszer implementáló nyelvek (System Implementation Language: SIL) Egy magasszintű programnyelven megírt OR „plattformfüggetlen”: minden olyan gépen használható, amely rendelkezik a nyelvhez fordító programmal. Így az ilyen OR „hordozhatóvá” válik. A nagyobb hatékonyság elérése érdekében mégis jobb, ha bizonyos részeket továbbra is assemblyben írunk. 43
Rendszerpéldák I. Kis rendszerek Jól illusztrálható a CP/M-mel. Részei: Basic Disc Operation System (BDOS) végzi az ellenőrzéstés és a file-szervezést. Basic Input/Output System (BIOS) a készülékek kezelésért felelős. Consol Command Processor (CCP)feladata a kapcsolattartás a felhasználóval. Az alkotóelemek teljesen eltérő helyen vannak eltárolva, és eltérő módon használjuk ezeket: BDOS kb. 1000 soros és PL/M-ben íródott BIOS modulokra bontva kb. 2-3000 sor, assemblyben írták (Installáláskor változhat) CCP kb. 500 soros. 44
22
Rendszerpéldák II. Nagy rendszerek UNIX. A Berkley UNIX „törzsét” egy kb. 100 állományból álló forráskódú rendszer alkotja, amely közel 35 000 C-kódú sorból áll. Egy tipikus programállomány néhány száz sor hosszú, és néhány további eljárást alkalmaz. A UNIX forrásmodulok kb. 100 definíciót használnak. A megszakítások kezeléséhez a Berkley UNIX a VAX gép assembly prgramját használja: Egy ilyen modul kb. 1000 sor hosszú, és ez az egyetlen olyan rész, amely nem C-ben íródott.
45
Társzervezés OR Rezidens rész
Tranziens rész
Állandóan a főtárban van. (Fontos komponensek, szolgáltatások)
Elegendő akkor betölteni, ha szükség van rájuk. (Kevésbé fontos komponensek)
A legkritikusabb részeket tartalmazó részét nukleusnak vagy kernelnek nevezzük.
Ide tartoznak a parancsinterface elemei és a filekezelő rendszer egyes részei
A memória meghatározott részén helyezkedik el. (legalacsonyabb címzésű rész)
Azokra a területekre töltjük be, amelyek éppen rendelkezésre állnak. Sokszor áthelyezhetőknek kell lenniük (bázis cím, relatív cím) 46
23
Mind a rezidens mind a tranziens komponenseket több folyamat is használhatja (természetesen felváltva). A tranziens elemek un. dinamikus könyvtárakban helyezik el (DLL, SHL). Néhány esetben a memória címezhető részének egy tartománya un. memóriába ágyazott (memory mapped) I/O részére van fenntartva. A memóriának mindazon részeit, amelyeken az OR részei helyezkednek el, minden felhasználói programtól védeni kell. Amikor ez a terület összefüggő, a védelem egyszerűbb. Megadunk néhány memóriatérképet. Egyes esetekben két lehetőséget mutatunk be: A fizikai memória beosztását mutatjuk be. A virtuális memóriát adjuk meg. 47
Rendszerpéldák I. OS/MVT A rendszer az IBM S/360 architektúrájára épült. Ez a felépítés a memória felosztását a különböző funkciók (felhasználói program fut, vagy OR-beli program fut). Között nem támogatj, ezért a címzési területek azonosak. A maximálisan címezhető terület 16Mbyte, egy jellegzetes installáció kb. 2Mbyte-t foglal el. Az egy taskon belül futó program számára az egész munkaterület látható (16 Mbyte). Ha egy program a rendelkezésére álló területről „ki akar címezni”, akkor memóriavédelem működésbe lép. Az OS/MFT felépítése hasonló az MVT felépítéséhez, az egyetlen eltérés az, hogy a taskok mérete nem változtatható. 48
24
Tranziens terület
2M
Task 2.
Task 1. Rendszerkontroll Tranziens terület Nukleus
0M 49
Rendszerpéldák II. UNIX A UNIX a memória felosztását virtuális memória-technikák alkalmazásával oldja meg: mindig csak annyi információt tart a főtárban, amennyire szüksége van. Ezért a fizikailag rendelkezésre álló memória tartalma gyorsan változik. A felhasználói programok által elérhető (virtuális) címzési területet program-, adat- és veremterületekre oszthatjuk. Ilyenkor az OR és az általa kezelt adatok nem látszanak. A legtöbb UNIX verzióban nincs közös címezhető memóriaterület a különböző futó programok számára. Az OR parancskezelő programja a felhasználó programokkal azonos feltételekkel rendelkezik.
50
25
Veremterület
Adatterület
Programterület 0M Virtuális folyamatszervezés UNIX alatt
51
A UNIX alatt az OR rezidens része által látott memóriaterület akkora, mint maga a kernel. A kernelbe tartozó összes forrásmodul egy load modulba van szerkesztve. Mérete elérheti a 2-300 000 byte-t is. A load modul részei rezidensként helyezkednek el a virtuális memóriában. A kernelben található eljárások akkor aktivizálódnak, amikor egy felhasználó program meghívja a rendszernek ezt a részét, vagy valamilyen megszakítás következik be.
52
26
Rezidens OR területe 0M Virtuális rendszerkezelés UNIX alatt
53
Rendszerpéldák III. CP/M Nem használ speciális memóriatérképet, a CPU által címezhető terület (max. 64 Kbyte) mindig rendelkezésre ál, ezért a virtuális és a fizikai memória kezelése megegyezik. Két rezidens komponens helyezkedik el a memória felső részében: a BIOS és a BDOS. A BIOS mérete változhat, de a kettő együttes mérete < 10 Kbyte. Ehhez a részhez tartozik egy kisméretű veremterület, amelyet az OR használ fel. A legalsó 256 Kbyte-n találhatók a a rendszeradatok és a pufferterületek Itt helyezik el az aktuális parancssort, a visszatérési címeket, és az indítási címeket is. A CCP az OR tranziens része. Csak akkor töltődik be, ha szükség van rá. Helye a BDOS alatt van, helyigénye kb. 2Kbyte, legalacsonyabb betöltési címe 100.A felhasználói programok 256-tól töltődnek be. Ha egy felhasználói programnak szüksége van a tranziens 54 területre, akkor azt felhasználhatja.
27
BIOS
64Kbyte
BDOS CCP
54 Kbyte
Felhasználói programok és adatok
256 byte
Ellenőrzési terület
0
Virtuális rendszerkezelés CP/M alatt
55
Rendszerpéldák IV. MS-DOS Az első MS-DOS rendszerek a 64 Kbyte-s címzési lehetőséggel rendelkező INTEL 8086-os processzorára lettek fejlesztve. Mivel a maximálisan rendelkezésre álló memória 1Mbyte, ezért a processzor 64Kbyte-s blokkokra osztva kezeli a memóriát. Az IBM PC-k a magasabb memóriaterületen helyezik el a videomemóriát és a ROM-ban tárolt rendszerprogramokat. A rezidens területen van tárolva az OR a parancs interpreter egy részével. A parancskezelő tranziens része a rendelkezésre álló szabad terület legmagasabb címére kerül. (Ez a felhasználói programok által felülírható.) A felhasználói programok részére kb. 600 Kbyte áll rendelkezésre., amit 64Kbyte-s lapokra bontva lát a processzor. A programterület alsó 256 byte-n van a kommunikációs terület. 56
28
BIOS és egyéb ROM prgk
1 Mbyte
Video és grafikus memória Tranziens parancskezelő
640 Kbyte
Felhasználói veremterület Felhasználói adatok Felhasználói program Rezidens OR terület
1536 byte 0
Kommunikációs terület Fizikai tárfelosztás MS-DOS alatt
57
64 Kbyte Rezidens OR terület Tranziens parancskezelő 0 64 Kbyte Felhasználói veremterület 256 Kbyte Felhasználói adatok 0 Virtuális tárfelosztás MS-DOS alatt
58
29
Végrehajtási struktúrák
Az OR programjait végrehajtható egységekben tároljuk. Ezeket az egységeket speciális „kívánságok” aktivizálják. Ezek lehetnek rendszerhívások vagy megszakítások. Egy OR program rendelkezhet előjogokkal: rendszer regiszterekhez férhet hozzá vagy elérhet olyan memóriaterületeket, amelyekhez a felhasználói programok nem férhetnek hozzá.
Áttekintjük azokat a végrehajtási struktúrákat, amelyek a fejlődés során kialakultak.
59
Klasszikus szervezés Az OR-t úgy tekintjük, mint szubrutinoknak egy olyan gyűjteményét, amelyeket azért futtatunk le, hogy a rendszer különböző erőforrásait kezeljük. Magukat a szubrutinokat rendszerhívásokkal vagy egyéb speciális kívánságokkal (pl. megszakítás) aktivizálhatjuk. A legtöbb szubrutin teljesen befejezi a munkáját mielőtt visszaadja a vezérlést a hívó programnak. Néhány rutin azonban indíthat egy I/O - műveletet, amelyek aztán a felhasználói programok futása alatt hajtódnak végre. Az OR programok egy része csak akkor indítható el, ha a felhasználói programok futását felfüggesztjük, míg másokkal egyidejűleg futhatnak a felhasználói programok. Bizonyos feltételek mellett a számítógépben ún. megszakítások generálódnak (pl. túlcsordulás, IO művelet). 60
30
Rendszereljárások alkalmazása Azokat a rendszerprogramokat, amelyek akkor futnak, amikor felhasználói programok is végrehajtás alatt vannak, ugyanúgy kezelhetjük, mint magukat a felhasználói eljárásokat.(Ilyen pl. egy output küldése nyomtatóra.) Ezek nem igényelnek speciális technikát. Ugyanúgy kezelhetők, mint egy felhasználói program. Az ilyen eljárásokat rendszereljárásoknak nevezzük. Egy rendszereljárás OR szolgáltatásokat nyújt, de úgy kezeljük, mint egy felhasználói eljárást. Az azonosság mellett bizonyos eltérések is jelentkeznek: Magasabb prioritás Mentesülhetnek néhány szabályozás (pl.: swapping) alól. A rendszereljárások alkalmazása csökkentheti az OR tervezése során fellépő hibákat, így növelhető a megbízhatóság. Nincs szükségük felesleges előjogokra, és az esetlegesen fellépő hibák sem okozhatnak „rendszerroncsolást” (pl. UNIX, VMS) 61
Nyitott környezetek A legtöbb OR-t úgy tervezték, hogy tiszta és merev határokat húztak a felhasználói software és az OR közé. Ez az OR-beli programok számára egyrészt előjogokkal járt, másrészt az OR programok olyan helyen töltődtek be a memóriába, amelyek a felhasználói programok számára elérhetetlenek. Ez a fajta szétválasztás egy többfelhasználós rendszer esetén teljesen indokolt. ( hiba esetén helyrehozhatatlan károk keletkezhetnek az OR-ben vagy a többi futó programban is.) Egyfelhasználós rendszereknél azonban ez a szétválasztás nem szükségszerű. 62
31
Megszületett a nyitott OR gondolata. Egy ilyen rendszerben Az OR programjait úgy tekintjük, mint eljárások összességét. Nem különböztetjük meg ezeket egyéb felhasználói programoktól. A felhasználó szabadon ad hozzá – vagy vesz el – eljárásokat a rendszer elemeihez.
63
A nyitott rendszer egyik speciális formája a UNIX által is kezelt kliens-szerver kapcsolat. Egy ilyen rendszerben a az OR csak közvetít a felhasználói folyamatok között. A felhasználónak lehetősége van arra, hogy megírjon egy-egy programot mind a szerveren (szerver folyamat) mind a kliens gépen (kliens folyamat), majd rögzítse a két folyamat között az információcsere módját. Ez az un. protokoll, pl. TCP/IP. Az OR-nek csak az a feladata, hogy a két folyamat között vezérelje az információ cserét. A rendszer nagy előnye, hogy a két folyamatnak nem kell okvetlenül egy gépen futnia, és még az sem feltétel, hogy a két gépnek azonos OR-je legyen.
64
32
Komponensek interakciója Az OR-k esetében különböző eljárások hívhatók más eljárások által, adatokat kaphatnak más programoktól és adatokat adhatnak át. Ha ezt korlátozás nélkül tesszük, akkor ez a rendszer megbízhatatlanságához vezethet. (Nem lehet behatárolni a rendszer azon részeit, amelyekre a változás hatást gyakorolhat.) Ezért nagyobb rendszerekben szabályozzák az egyes részek interakcióját. Az interakció kezelésének leggyakoribb változatai: Korlát nélküli interakció Modulok elkülönítése Absztrakt gépek Virtuális gépek Kliens-szerver interakció. 65
Adaptálhatóság Amikor egy OR-t elkészítünk, akkor mindig gondolnunk kell arra, hogy a későbbiek során változtatnunk kell a rendszer egyes részein, vagy új modulokkal kell azt kiegészítenünk. Előfordulhat, hogy a számítógép konfigurációja változik meg, és az OR-t ehhez kell igazítani. Ilyenkor nagyon kellemetlen lenne, ha az egész rendszert újra kellene fordítani. Ezért a rendszert részrendszerekre bontjuk. Ehhez az OR-k egy részénél az ún. „blokk-építés” technikáját használják. Egy ilyen rendszernél a felhasználó válogatja ki, hogy mely komponenseket akarja beépíteni a rendszerbe. A modulokat különkülön fordítjuk le és ha valamelyikben változás van, csak azt a modult kell újrafordítani. 66
33
4. Az OR-k felületei Egy számítógépes rendszer hatékonyságát – és elfogadottságát – nagymértékben befolyásolja, hogy milyen módon tartja a kapcsolatot a felhasználókkal. A kommunikáció irányai: a felhasználó jelez a rendszernek, ha szolgáltatást igényel a rendszer küld információt, ha a teljesítésről. A kapcsolattartás módja: közvetlen (interaktív terminálon) közvetett (programokból adjuk a szolgáltatás igénylését) 67
Az OR-nek azt a komponensét, amely a felhasználóval történő kapcsolattartásért felelős felhasználói interface-nek nevezzük. Két fő része van: Parancs interface: magas szintű kommunikációt tesz lehetővé a felhasználó és az OR között, irányítja a programok futását. Program interface: kezeli a futó programokra, tartja a kapcsolatot a programok, a rendszer által ellenőrzött erőforrások és a szolgáltatások között. A felhasználói interface két komponense kapcsolatban áll egymással: a parancs interface is rendszerprogam által implementálható. a program interface „segítségül hívhatja” a parancs interface-t. programok előállíthatnak parancsokat, amelyeket aztán átadnak a parancs interface-nek további feldolgozásra. 68
34
A parancs interface Bármilyen formában is jelenik meg egy parancs interface, mindig szükség van a kommunikációhoz egy nyelvre. A felhasználói parancsokat a gépirányába a parancsnyelv (Command Language) közvetíti, Az OR által visszaadott információt a válasznyelv (Response Language) segítségével fordítjuk le.
A parancsnyelv típusai Job-control nyelv Interaktív parancsnyelv 69
// PROBA // COMP // SYSPRINT // SYSLIN
JOB
(1023,20,47),PRTY=3,MSGLEVEL=3, CLASS=A EXEC PGM=IEYFORT,PARM=‘SOURCE’ DD SYSOUT=A DD DSNAME=SYSL,DISP=OLD, DCB=(RECFM=FB,LRECL=80,BLKSIZE=1600) DD *
// SYSIN … itt jöttek a forrásprogram kártyái, amelyeket egy /* kártyával zárunk le. … // EDIT EXEC PGM=FORTLINK,COND=(4,LT,C) // SYSPRINT DD SYSOUT=A // SYSLIN DD DSNAME=*.SYSLIN,DISP=OLD // SYSLIB DD DSNAME=SYSLIB.FORTLIB,DISP=OLD // FT03F001 DD SYSOUT=A, DCB=(RECFM=FA,BLKSIZE=133) // FT05F001 DD DSNAME=SYSIN // EDIT.SYSIN DD * A program adatkártyái /*
Példa job-control nyelvre
70
35
Interaktív parancsnyelv Típusai: stream-orientált: parancsokat dolgotunk fel soronként (CP/M, MSDOS) menűvezérelt: a felhasználó a rendszer által felkínált lehetőségek közül választ. ikonvezérelt: az OR funkciói stilizált ábrák segítségével választhatók. A rendszertől függő szolgáltatások nagymértékben függnek a környezettől, mégis vannak olyan parancstípusok, amelyek minden parancsnyelvben szerepelnek: könyvtár elemeinek listázása állományok másolása, átnevezése, törlése szerkesztő programok futtatása információk listázása a rendszerről és a felhasználói környezetről. 71
IBM JCL: // RENAME // SYSPRINT // SYS1 // VOL1
EXEC DD DD DD
PGM=IEHPROGM SYSOUT=A UNIT=3330, VOLSER=SYS001 DISP=OLD, UNIT=3300, VOL=SER=SZALAG // SYSIN DD * RENAME DSNAME=réginév, VOL=SER=SZALAG NEWNAME=újnév /*
VMS: RENAME
/OLDNAME=réginév
/NEWNAME=újnév
MSDOS: RENAME
réginév újnév
UNIX: mv
réginév újnév
Példa az állományok átnevezésére különböző parancsnyelvekben72
36
Egy parancs felépítése: parancskód
<paraméter1> <paraméter2> …
A paraméterek típusai: pozícionális kulcsszavas Paraméterek kezelésének megkönnyítése: rövidítések parancskiegészítések szabad helykijelölések (wild card) „kierőszakolt” végrehajtás („Are you sure?”) parancsállományok szűrők 73
A válasznyelvek A válasznyelv segítségével az OR információt szolgáltat a felhasználó számára. Lehetséges információk: Promt üzenet Kisegítő (help) üzenetek Előrehaladási üzenetek Befejezést jelző üzenetek
74
37
Program interface (PI) Feladata: a futó programok számára nyújt szolgáltatásokat, és azokkal kommunikál. Végigkíséri a programokat a végrehajtásuk során: Felelős a programok betöltéséért (áthelyezhetőség) A program futása alatt fogadja a rendszer szolgáltatásaira és az erőforrások igénybevételére vonatkozó igényeket, és továbbítja az erőforrás kezelőhöz. A program befejezésekor figyeli, hogy azok szabályosan fejeződtek-e be, vagy hibakódot kell kiadni. Rendszerszolgáltatások, amelyeket rendszerhívások segítségével hajt végre.
75
A rendszerhívások típusai: bemenet-kimenet (read / write / open …) könyvtárkezelés (dir / rd / md / ln …) folyamatok kezelése (fork / kill …) készülékek kezelése (enable / disable …) memória kezelése ( swap / allocate / free …) megszakítások kezelése (IRQ kezelés) időkezelés (date / time / at / cron …) jogosultságok kezelése (owner / group / exe …)
76
38
Felhasználói interface Programinterface
Parancsinterface
Programok betöltése Erőforrások ellenőrzése
Parancsnyelv
Válasznyelv
Batch feldolgozás:
JCL
Interaktív parancsnyelv:
Streamorientált
rendszerszolgáltatások biztosítása
Menüvezérelt Ikonvezérelt
Összefoglaló táblázat a felhasználói interface felépítésére
77
5. Memóriaszervezés A fejlődésnek újabb lökést a többfelhasználós rendszerek megjelenése adott: a drága erőforrást meg kellett osztani a konkurens folyamatok között. Ezért külön részrendszert fejlesztettek ki az OR-n belül: memóriaszervező (Memory Management Unit = MMU). A memóriakezelés három részprobléma kezelését rejti magában: Memóriaallokáció Az igényelt memóriát gyorsan kell biztosítani Csak akkor allokálunk, ha az szükséges Ha nincs szükség a területre, akkor azt azonnal felszabadítjuk Áthelyezés (címrészek, címek módosítása) Memóriavédelem 78
39
5.1 Memóriaallokáció Memóriaallokációról akkor beszélünk, amikor egy folyamat számára a memória egy meghatározott, összefüggő részét lefoglaljuk. Külön kell vizsgálni az allokációt egyfelhasználós rendszereknél, többfelhasználós rendszereknél Egyfelhasználós rendszereknél az allokáció egyszerű, mert a memóriában elhelyezkedő egyetlen program a teljes memóriát igénybe veheti, kivéve azt a részt, amelyben az OR foglal el. A felhasználás korlátait jelentő határcímeket vagy a CPU meghatározott regisztereiben vagy az alsó memóriaterület előre definiált címein tároljuk. Az utasításokat – az összehasonlítás után – csak akkor hajtjuk végre, ha nem lép fel címzési hiba. 79
Allokáció többfelhasználós rendszerekben A fizikai memória felosztásának két módja van (az OR hajtja végre): •
•
Statikus memória definícióról akkor beszélünk, ha az allokálható blokkok méretét és számát akkor rögzítjük, amikor az OR-t generáljuk. (A blokkok száma soha sem változik.) Partíciók. Dinamikus memória definíció esetén az OR a blokkok számát és méretét akkor határozza meg, amikor egy igényt ki akar elégíteni. Régiók. Szétdaraboltság problémája!
Attól függően, hogy egy feldolgozás alatt álló folyamat futás közben foglalhat-e le újabb területeket, két stratégia lehetséges: Statikus allokáció (a program betöltéskor, indításakor) Dinamikus allokáció (futás közben is lehetőség újabb területek lefoglalására, ha szükséges) 80
40
A dinamikus allokáció hatékonyságát két tényező befolyásolhatja: a jól megválasztott adatstruktúra kevesebb helyigényű és gyorsabb adminisztrációt eredményez: bit térképet akkor használunk, ha a memória egyenlő méretű blokkokra van osztva. Egy blokkhoz egy bitet rendelünk a foglaltság jelzésére. Memóriaellenőrző blokkokkal változó hosszúságú blokkokat kezelünk. Ez lehetőséget ad több memóriablokk összekapcsolására is. (Mindig tartalmazza a típust, a hosszat és a pointert. Két típus: FMCB = Free Memory Control Block AMCB = Allocated Memory Control Block. az allokálást hatékonyan végző allokációs algoritmus jobb helykihasználást eredményez 81
Szabad terület 1. Folyamat Szabad terület Szabad terület 0110011100
2. Folyamat
Szabad terület Szabad terület Példa bit-térkép alkalmazására
82
41
FMCB Hossz Pointer AMCB Hossz Pointer FMCB Hossz Pointer FMCB Hossz Pointer AMCB Hossz Pointer FMCB Hossz Pointer AMCB Hossz Pointer AMCB Hossz Pointer FMCB Hossz Pointer AMCB Hossz NIL FMCB Hossz NIL Példa Memória ellenőrző blokkok alkalmazására
83
Allokációs stratégiák dinamikus allokáláshoz Első Illesztés (First Fit): Az első FMCB-től indulva megvizsgál minden szabad blokkot és az első olyan blokkot választja, amely megfelel az igényelt méretnek. Gyors, de egy idő után összegyűlnek a kicsi „maradvány” blokkok, amikkel már nem tudunk mit kezdeni. Következő Illesztés (Next Fit): Az előző egyszerűsített változata, csak itt új keresést mindig ott kezdünk az FMCB blokkok között, ahol az előzőt abbahagytuk. Egy kicsit rosszabbul viselkedik, mint az FF. Legjobb illesztés (Best Fit): Az előző kettő nem veszi figyelembe a blokk tényleges méretét. Ez az algoritmus bejárja az összes blokkot, megjegyzi azt, amelyikhez a legjobban illeszkedik az igény. (azaz a legkevesebb felhasználatlan terület marad) Legrosszabb illesztés (Worst Fit): Megfordítja az előző szabályt. Ha nagyobb szabad hely marad, nagyobb az esély, hogy később fel tudjuk használni. 84
42
Átrendezés, tömörítés Az előző algoritmusok alkalmazása során többször előfordulhat, hogy kisméretű blokkok maradnak a memóriában elszórtan elhelyezkedve. Célszerű lehet ezeket a jobb felhasználhatóság érdekében időszakonként „összegyűjteni” egy nagyobb blokkban. Azoknál a rendszereknél, amelyek a dinamikus áthelyezést támogatják, lehetőség van egy ilyenfajta tömörítésre. Ha tömörítést alkalmazunk, akkor periodikusan kell végrehajtani és a tömörítés alatt minden olyan folyamatot fel kell függeszteni, amely függ az adott folyamatokhoz tartozó programok relatív helyzetétől. (pl.: I/O-műveletek) 85
5.2 Áthelyezési módszerek A többfelhasználós rendszerek általában megengedik, hogy a programok különböző időpontokban történő végrehajtásakor azokat a memória különböző területeire töltsük be. Az ismételt betöltésekkor a helyes címrészek kialakítása alapvető követelmény. Azt az eljárást, amely a programot úgy módosítja, hogy az az új helyre betöltve is helyesen fut, áthelyezésnek nevezzük. Attól függően, hogy az áthelyezés a betöltéshez viszonyítva mikor történik, két típust különböztetünk meg: Statikus áthelyezés: ha a betöltéssel egyidőben vagy előtte történik. Dinamikus áthelyezés: a program futása közben is végrehajtható. 86
43
5.2.1. Áthelyezés software úton Akkor használjuk, ha meghatározható, hogy mely hivatkozásokat kell megváltoztatni, és megadható a változtatások módja is. A hivatkozások azonosítását az áthelyezési könyvtárban adjuk meg. Rendkívül időigényes, részletes kiegészítő információkat igényel. Az egyszer áthelyezett program többé nem mozdítható ugyanazon futás során. Ez az áthelyezési technika statikus áthelyezést eredményez.
87
… 870 872 874 …
LOAD MUL
3214 134
GOTO
2537 4000
Áthelyezhető tárgykód
… 4870 4872 4874 …
LOAD MUL
7214 4134
GOTO
6537
Áthelyezés software úton
88
44
5.2.2. Áthelyezés báziscímekkel Ennél a módszernél a báziscímek használata hardvertámogatás útján valósul. Az OR a betöltött program báziscímét elhelyezi egy bázisregiszterben, amely vonatkozási alapként szolgál majd. A tényleges címeket úgy számítjuk ki, hogy a bázisregiszter tartalmát az utasítás címrészéhez hozzáadjuk. A módszer lehetőséget ad dinamikus áthelyezésre, mert elegendő a program áthelyezése során a bázisregiszter tartalmát átírni. Először az IBM/360-nál használták. Mivel a legnagyobb címezhető cím 4K volt, ezért minden 4K nagyságrendű blokk külön bázisregiszterrel rendelkezett. 89
5.2.3. Áthelyezés relatív címzéssel A báziscímek alkalmazásának egy másik módja. Az utasítás számlálót (PC = Program Counter) használjuk fel bázis regiszterként. ( „lebegő bázis regiszter”) A tényleges címeket most úgy számoljuk ki, hogy az utasítás számláló tartalmát adjuk hozzá a végrehajtandó utasítás megfelelő címrészéhez. Lehetővé teszi az ún. helyfüggetlen kódok kialakítását. A PDP-11-n használták először.
90
45
5.2.4. Áthelyezés áthelyezési regiszterek használatával A bázisregiszter technika egyik lehetséges javítását kapjuk, ha áthelyezési regisztert alkalmazunk. Ekkor e regiszter tartalmát mindig hozzáadjuk a végrehajtás előtt az utasítás címrészéhez. A relatív címzéssel szemben itt az áthelyezési regiszter tartalma mindig állandó marad, amíg a programot ismét át nem helyeztük. Az áthelyezési regiszter alkalmazása leegyszerűsíti az áthelyezést: ha a programot úgy tervezzük, hogy a 0-s címre töltjük be, akkor minden áthelyezés egyszerűen végrehajtható, ha azzal egyidőben az áthelyezési regiszterbe a program új kezdőcímét töltjük. 91
A korai egyfelhasználós rendszerek központi memóriája viszonylag kicsi volt. Egy nagyobb program futtatása csak úgy volt lehetséges, ha a programot megkíséreltük kisebb egységekre bontani. overlay-ek A technika alapgondolata: daraboljuk szét a programot olyan részekre, amelyek nem interferálnak egymással, és az egymástól független programrészekhez rendeljük hozzá ugyanazt a memóriaszeletet. overlay szegmens Napjainkban a memóriák ára drasztikusan csökkent, így nagyobb operatív tárakat alkalmazhatunk, ami többnyire feleslegessé teszi ezt a technikát. 92
46
5.3. Memóriavédelem Az allokációnak a legtöbb esetben csak akkor van értelme, ha összekapcsoljuk valamilyen védelemmel. Védelemnek léteznie kell, hogy a programok ne érjék el azokat a területeket, amelyeket az allokáció során nem kaptak meg. Típusai: • •
Egyfelhasználós rendszerek Többfelhasználós rendszerek
93
Egyfelhasználós rendszerek Néhány OR nem tartalmaz semmilyen hardware biztosítékot a nem allokált területek elérésének védelmére. Itt a baj azonban nem lesz olyan nagy, mert csak egyetlen programra lesz kihatással. Mégis van egy program, amely kitüntetett szerepet játszik: ez az OR (vagy annak a memóriában lévő része). A védelmet határcím és/vagy határregiszter alkalmazásával oldják meg.
94
47
Többfelhasználós rendszerek:
Az egyfelhasználós rendszereknél alkalmazott határregiszterek jó irányt mutat ahhoz, hogy minden régió számára alkalmazzunk külön határregisztert vagy alsó- és felső regiszterpárt, amelyek egyértelműen kijelölik a régió aktuális határait. Egy másik lehetőség az, ha a regiszter párban bázis értéket és blokkszélességet adunk meg.
95
6. Virtuálismemória-kezelés A megoldandó probléma: A gépi kódra történő fordítás során a fordító (compiler) program olyan címeket generál az utasításoknak és az adatoknak, amelyeket a rendelkezésre álló hardware segítségével elvileg el tud érni. (Ha a CPU címregisztere 1 byte hosszú, akkor az elérhető legmagasabb cím 255.) Ha a fizikailag megcímezhető terület kisebb, mint a fordításkor elvileg rendelkezésre álló legmagasabb cím (azaz a virtuálisan rendelkezésünkre álló terület), akkor a programok futása során gondoskodni kell a fordítás során kialakított virtuális címek átalakításáról olyan fizikai címekké, amelyek ténylegesen rendelkezésre állnak a főtárban. A megvalósítás során a program egy része van csak a főtárban, - amelyre hivatkozunk - a többi háttértáron helyezkedik el. Az OR feladata az, hogy megoldja a programrészek automatikus cseréjét a kellő időpillanatban. 96
48
A virtuális memóriakezelés azt az illúziót nyújtja a felhasználónak, mintha a virtuálisan címezhető terület mindig a rendelkezésre állna fizikailag is. Ezért a programokban specifikált virtuális címeket az OR a hivatkozás pillanatában át tudja alakítani olyan fizikai címekké, amelyek a főtárban rendelkezésre állnak. Így a virtuális címeket a fordítás során úgy tudjuk megválasztani, ahogy az a fordítónak kényelmes, a fizikai címek pedig mindig az OR-hez illeszkednek. A módszer előnyei: A virtuális és a fizikai címek elkülönülnek egymástól: bárhogyan változnak meg a fizikai címezhetőség határai, a virtuális címek nem változnak. A memóriavédelem könnyebben szervezhető. 97
6.1. Memória áthelyezési technikák 6.1.1. Áthelyezési táblázat használata Inkább elvi jellegű. A módszer lényege: a virtuális címzési terület és a fizikai címzési terület közé egy transzformációs tábla kerül, amelynek segítségével az aktuális áthelyezéseket megoldjuk. Használjuk a következő jelöléseket: VKC: virtuális kezdőcím (a fordító adja a program első utasításának.) FKC: fizikai kezdőcím (a program aktuális futásakor a betöltési kezdőcím.) A VKC-t ill. a z FKC-t szokás báziscímeknek is nevezni. 98
49
A fordítás során a virtuális címzési területet a fordító blokkokra osztja, amelyek lehetnek változó hosszúságúak. Minden „virtuális” blokkhoz hozzárendelünk egy vele azonos méretű fizikai blokkot. A két blokk közötti transzformációs szabályt az Áthelyezési Táblázat segítségével írjuk le. Ebben minden blokkhoz hozzárendelünk egy blokk leíró vektort, amely tartalmazza a VKC-t, az FKC-t és a blokk méretét. A gyakorlati végrehajtás: Amikor a programban valamilyen virtuális címre történik hivatkozás, akkor a hardware először megkeresi azt a blokk leíró vektort, amely a szóban forgó virtuális címet tartalmazza. Ahhoz, hogy megkapjuk a cím relatív helyét a virtuális blokkon belül, ki kell vonni az értékéből a virtuális blokk bázis címét. Ezt a címet adjuk hozzá a fizikai blokk bázis címéhez és megkapjuk a keresett fizikai címet. 99
Virtuális Cím
Virtuális Címzési Terület
-
VKC
+
FKC Méret
Fizikai Cím
Fizikai Címzési Terület
Áthelyezési Táblázat
Virtuálismemória-kezelés áthelyezési táblázattal
100
50
Következmény: ha a fizikailag rendelkezésre álló memória egyik szelete nem szerepel egyetlen blokkleíró vektorban sem, akkor ez a terület fenntartható az OR számára. Az eljárás tovább finomítható akkor ha a program logikailag összetartozó részeit (főprogram, szubrutinok, adatstruktúrák) külön szegmensként kezeljük. A szegmenseken belüli területeknek összefüggőnek kell lenni. Ezért egy szegmens kezelhető egy virtuális blokknak, amely egy egységben vihető áll a fizikai címzési tartományba. A szegmentálás elve csak akkor alkalmazhatjuk, ha az OR támogatja a változó hosszúságú virtuális blokkok kezelését.
101
6.1.2. Leképezési regiszterek Ez az eljárás akkor használható jól, ha a virtuális címzési terület korlátozott számú blokkra osztható. Virtuális Címzési Terület
Méret
FKC
0
--
120
0
--
100
0
--
80
20
60
12
0
18
40
20
20
Fizikai Címzési Terület 200
80 60
60
40
40
20
20
0
0
Leképezési regiszterek
Virtuálismemória-kezelés leképezési regiszterekkel
102
51
Problémák a korábbi két módszernél: A változó hosszúságú blokkok mozgatása miatt a fizikai memóriában „maradék” blokkok keletkezhetnek, amelyeket nem lehet felhasználni. Ilyen speciális regiszter csak korlátozott számban áll rendelkezésre, ezért, ha a virtuálisan címezhető terület nagy, akkor a mozgatható blokkok is viszonylag nagyok. Így, ha az aktuális blokk mérete kicsi, akkor az elvesztett terület nagy lesz. Megoldás: mozgassunk kisméretű, fix hosszúságú blokkokat!
103
6.1.3. Lapozási technika A virtuális címzési terület fix hosszúságú, lapoknak nevezett blokkokra van bontva. Minden laphoz egy lapszámot rendelünk. Egy címet a virtuális memóriában lapszámmal és a lapon belüli eltolási címmel határozunk meg. A virtuális memóriacímek leképezése a főtárban tárolt lapozási tábla segítségével történik. A fizikai memória is blokkokra van osztva, és azok mérete megegyezik a lapok méretével. Ezeket a blokkokat képlapoknak nevezzük. A képlapokhoz is egy azonosítószám tartozik. A lapleíró blokk tovább egyszerűsödik: elegendő tárolni a lap azonosítóját és a laphoz rendelt képlap azonosítószámát.
104
52
A virtuális címek leképezése: Egy adott virtuális címet az OR lapszámra és eltolási címre bont. A CPU a lapleíró regiszterének segítségével megkeresi a lapozási táblát. A táblában megkeresi a lap azonosítóját. A képlap-azonosító és az eltolási cím segítségével kiszámítja a fizikai címet.
105
Virtuális Címzési Terület 18
19
20
15
16
17
12
13
14
9
10
11
6
7
8
3
4
5
0
1
2
Fizikai memória
13
18
19
20
6
8
15
16
17
5
17
4
9
12
13
14
3
8
9
10
11
2
0
1
5
6
7
8
0
19
3
4
5
0
1
2
7
Lapozási Tábla
Virtuálismemória-kezelés lapokra bontással
106
53
6.2 Virtuálismemória - kezelés A legtöbb OR esetében a rendelkezésre álló főtár nem elegendően nagy ahhoz, hogy az összes aktív folyamat egyidejűleg a memóriában tartózkodhasson. Ezért gondoskodnunk kell arról, hogy a megfelelő időben az inaktív folyamatokat a főtárból eltávolíthassuk és helyükbe újakat hozhassunk be. Az átmenetileg kipakolt folyamatokat háttértárolón helyezzük el. Egy nagyméretű program lehet, hogy egyedül sem fér el a memóriában és ezért kisebb részekre kell bontani. A lapozási technika ezeket a problémákat megoldja, ha kiegészítjük egy olyan swap eljárással, mely automatikusan elvégzi a programok cseréjét, gondoskodva a szükséges környezeti változók mentéséről is. 107
Ezt a feladatot végzi el a Virtuális Memória Rendszer (VMR). A ma használatos technikák alapvetően két részből állnak: Az első fázisban egy memóriaáthelyezést kísérelnek meg végrehajtani több lépcsőben, majd – ha a megfelelő blokk nem érhető el az operatív memórián belül, akkor – a VMR lapot cserél.
108
54
Első fázis: Memóriaáthelyezés Ha a keresett lap a főtárban van, akkor az algoritmus vége. Ellenkező esetben: a virtuális címet felbontjuk lapszámra és eltolási címre, megkeressük a lapleíró vektort. Ezt először a cache memóriában tesszük, majd a főtárban keresünk. A CPU regiszterei segítségével meghatározzuk a keresett virtuális cím helyét a memóriában. Ha a lap nincs a főtárban, akkor először meghatározzuk a lap helyét a háttértárolón, majd megkíséreljük betölteni a memória egy szabad lapjába. Sajnos előfordulhat, hogy nincs szabad lap és ekkor valamelyik lapot le kell cserélni. Ez általában software eszközökkel történik. 109
Második fázis: Laphiba. Ha az OR nem találja azt a lapot, amelyben a művelet végrehajtásához szükséges cím helyezkedik el, akkor vezérlésátadást előidéző laphiba megszakítás lép föl. Ez a megszakítás eltér az általános megszakításoktól. Itt ugyanis a megszakítás egy művelet közepén lép fel. Ezért speciális regisztereket kell használni! A laphiba megszakítást kezelő algoritmus nagyon bonyolult. Ezért – ha a laphiba sűrűn lép fel, akkor – az OR hatékonysága lecsökkenhet. A cél az, hogy ezt a jelenséget lehetőleg kerüljük el. Lényegében két célt tűzhetünk ki: Korlátozzuk a laphiba megszakítások előfordulásainak számát. Olyan lapkezelési technikát alkalmazunk, amely a lehető leggyorsabban adja vissza a vezérlést a megszakítás hívása után. 110
55
Regiszterek tartalmának elmentése Lap helyének meghatározása a másodlagos tárolón A lap képe a főtárban?
Lap kiválasztása lapcseréhez Módosított lap?
Írjuk vissza a lapot Töltsük be az új lapot Írjuk át a lapkezelő táblát Visszatérés a megszakításból
111
Virtuálismemória - kezelés technikái Négy alapprobléma megoldására koncentrálnak: Betöltési probléma (Mikor?) Elhelyezési probléma (Hová?) Helyettesítési probléma (Melyik lapot kell eltávolítani?) Stratégiák: Legrégebben használt lap (Least Recently Used) Legritkábban használt lapok (Least Frequently Used) FIFO Kombinált módszer Módosított lapok kezelése (Mikor kell visszaírni?) Lokalitás elve! (Belady 1966) 112
56
6.3 A másodlagos tárak kezelése Azokat a lapokat, amelyeknek nem kell állandóan a főtárban lenni háttértárolón helyezzük el. Az OR-nek kell gondoskodni arról, hogy a kellő időben a lehető leggyorsabban a lapok a főtárba kerüljenek Ezt kétféleképpen tudjuk elérni: Gyors hardware eszközöket használunk Megfelelő adatstruktúrát alkalmazunk
113
Hardver eszközök használata: Nagy rendszerek esetében gyakran alkalmazott hardware megoldás az, hogy külön író-olvasó fejeket működtetnek sávonként. Kisebb rendszereknél a lapok tárolására azokat a mágneslemezeket használják, amelyeken az állományokat egyébként is tároljuk. Különböző módszerek tárolási struktúrákra: A virtuális címzéssel egységesen kezelhető területeket a másodlagos tárolón is folytonosan elhelyezkedő területeken tároljuk. Csak a logikailag egybetartozó lapokat kezeljük egységesen.
114
57
6.4 Szegmentált virtuális memória A programok logikai egységeinek külön szegmensekbe osztása további lehetőségeket nyújt. Amikor egy eljárást vagy adatstruktúrát egy szegmensként kezelünk, akkor erre – egy adott időszakon belül – egységes egészként hivatkozhatunk. A lapokra bontást és a szegmentálást együttesen alkalmazzák: először a programokat logikailag szegmensekre bontják, majd az egyes szegmenseket osztják lapokra. Annak a rendszernek, amely egy ilyen vegyes eljárást használ, kétszintű átviteli technikát kell alkalmazni. Minden egyes folyamathoz a főtárban egy szegmenstáblát rendelünk hozzá. Ez egy vektor, amelynek minden sora egy szegmensleíró vektort tartalmaz. A hardware-t is általában kiegészítik egy szegmenstábla regiszterrel, amely a CPU-ban helyezkedik el és az aktuálisan használt szegmens kezdőcímét és méretét tartalmazza. 115
Virtuális Cím
Szegmens Tábla Sz.T.Báziscím
Sz.Sorszám
Sz.T. Méret
Lapsorszám
Eltolási cím
+ T.Báziscím
T. Méret
Hozzáférés
Jelenlét
Szegmensleíró Vektor
+ Lapképsorszám
Jelenlét
Módosítás
Hivatkozás
Lapleíró Vektor Fizikai Cím Sz.T.Báziscím
Sz.T. Méret
Fizikai cím kiszámítása szegmentált virtuális címzés esetében
116
58
7. Folyamatok szervezése Azokat a tevékenységeket, amelyeket egy program végrehajt, folyamatoknak (processzeknek) nevezünk. A folyamat egy aktív fogalom
(Program
Folyamat)
Egy CPU esetén a vezérlés mindig egy folyamat az aktív., ezért az ilyen vezérlés során szekvenciálisan szervezett folyamatokról beszélünk. Multiprogramozás esetében, az erőforrások EF-i egyidejűleg több folyamat között is felosztásra kerülhetnek. Ekkor közbeékelt folyamatokról beszélünk. Ahhoz, hogy a tevékenységek jól szervezhetők legyenek formálisan definiálni kell azokat. Ezért egy adatstruktúrát rendelünk a tevékenységhez: ez a folyamatellenőrző blokk (PCB) 117
Erőforrások Mindig szükség van rájuk (CPU, operatív memória)
Felhasználásuk időben dinamikusan változik
Az erőforrások nagy része olyan, hogy egy időben csak egy folyamat tudja ezeket használni. Ezért, ha egy használatban lévő erőforrásra egy másik tevékenységnek is szüksége van, akkor annak várakoznia kell. Ezért egy végrehajtás alatt lévő folyamat felváltva van futó ill. várakozó állapotban. A futó folyamat teljes egészében használja a CPU-t. Ezért a várokozó állapotba kerüléskor gondoskodni kell a felfüggesztendő folyamathoz tartozó információk megőrzéséről. Az elmentett információt környezetnek, a műveletet kapcsolásnak nevezzük. 118
59
7.1 A tevékenység leírása A folyamatok jellemzőinek leírására a PCB-t használjuk. tartalmazza a folyamat legfontosabb jellemzőit:
Ez
folyamat neve (külső név, belső név) folyamat állapota (vagy egy direkt kód, vagy pointer) folyamat környezete felhasznált memória folyamatprioritás szükséges erőforrások összefüggések leírása elszámolási információk
119
7.2 A tevékenységek és az erőforrások kapcsolata Ahhoz, hogy egy folyamat a számára kijelölt tevékenységeket végre tudja hajtani, szüksége van erőforrásokra. Az erőforrások típusai I.: Fizikai erőforrások (hardver elemek, állományok) Logikai erőforrások (szoftver elemek)
120
60
Az erőforrások típusai II.: Ismételten felhasználható: ezeket a folyamat nem rombolja le. Ide tartoznak általában az olyan erőforrások, amelyeket egy időpontban csak egy folyamat használhat (pl. a memória egy adott része, nyomtató). Ezeket az rőforrásokat sorosan újrafelhasználhatónak nevezzük. Másik csoportba tartoznak az állományok. Ezek megoszthatók esetenként több folyamat között is. Megszűnő (az OR lerombolja). Biztosítani kall azt, hogy azok a folyamatok, amelyek ilyen erőforrásokat használnak, kölcsönösen kizárják egymást.
121
Két speciális erőforrás: a CPU és a memória. Közvetlen érjük el őket, rendszerhívások nélkül. Minden tevékenységnek szükségük van rájuk. Más erőforrások: Nem rendelkeznek a fenti tulajdonságokkal Rendszerhívások segítségével hajtjuk végre Az ütemezés problémája itt is fennáll (holtpont, várakozási sor) 122
61
Ha egy erőforrás az igénybejelentés időpontjában nem áll rendelkezésre, akkor az igénylő folyamatnak várakoznia kell. A várakozás kezelését az OR úgy végzi, hogy a várakozó folyamat által igényelt erőforráshoz egy rekordot rendel, amelyet egy várakozási sorba helyez el. A várakozási sorból az un. ütemezési technika segítségével emeli ki a soron következő elemet. (Ez lehet egy egyszerű FIFO, vagy valamilyen más eljárás.) Egy folyamat hozzáfűzéssel kerül a sorba.
123
Várakozó sor Pointer
Pointer
Pointer
NIL
PCB1
PCB2
PCB3
PCBn
Várakozó sor előállítása PCB-n belüli mutatóval. 124
62
Várakozó sor
Pointer
Pointer
Pointer
Pointer
PCB1
PCB2
PCB3
PCBn
Várakozó sor előállítása elválasztott pointerekkel. 125
7.3. A folyamatok állapotai Egy aktív folyamatnak két elsődleges állapota van: végrehajtás alatt van, várakozik. A várakozó folyamat kétféle lehet: csak a CPU-ra vár (futáskész folyamatok), a CPU mellett más erőforrásra is várakozik (blokkolt folyamatok). Egy tevékenység az általános esetben a ready állapotból indul. Amikor rákerül a sor, akkor hozzárendeljük a CPU-t, így átkerül végrehajtási állapotba.
126
63
Folyamatok lehetséges alapállapotai
Ready
Running
Blokkolt
127
Folyamatok állapotdiagramja kiegészítő állapotokkal
Kezdet i
Ready
Felf. ready
Runnin g
Végállap .
Blokkolt
Felfügg. blokkolt
128
64
Tevékenység állapotok egyszerűsített időbeni lefutása egy multiprogramozási rendszerben
129
Tevékenység állapotok tényleges időbeni lefutása egy multiprogramozási rendszerben
130
65
7.4. Környezetátállítás Ha a tevékenységek multiprogramozható rendszerben futnak, akkor időről-időre át kell adniuk a CPU-t más folyamatok számára. Ilyenkor a különböző regiszterekben, státusz-flagekben, státuszszavakban, vermekben, címterületeken tárolt információkat meg kell őrizni, hogy később ismét felhasználhassuk azokat. A megőrzött információk jelentik a folyamat környezetét, az információk cseréje jelenti a környezetátállítást. Egyszerű esetekben a környezetátállítás a a folyamat egy meghatározott pontján következik be, bonyolult esetekben a program futását valamilyen előre nem látható okból fel kell függeszteni. Az átállítást végző eljárásnak gondoskodni kell arról, hogy az elmentett információk pontosan kerüljenek vissza akkor, amikor a hozzájuk tartozó folyamatot ismét aktivizáljuk. 131
7.5. Folyamatvezérlő műveletek Statikus folyamatkezelés: A korai multiprogramozású rendszerekben (T.H.E.) az egyidőben jelen lévő folyamatok számát maximalizálták. Ezért a PCB-k tárolására fix hosszúságú területre volt szükség, így azok mindig a memóriában helyezkedtek el. Az ilyen szervezésnél az egyszer aktivizált folyamatokat sosem szakították meg, és ezek új folyamatokat nem generáltak. Dinamikus folyamatkezelés: lehetővé teszi, hogy folyamatokat állítsunk elő és szüntessünk meg. Ilyenkor előfordulhat, hogy egy futó folyamat új folyamatot állít elő (UNIX). Az előállított folyamat vagy ugyanolyan jogokkal rendelkezik, mint az előállító vagy csak korlátozott lehetőségei vannak. A generált folyamatok általában hierarchiába rendezettek (”szülő-gyerek” kapcsolat). 132
66
Folyamatvezérlő műveletek: Folyamatok előállítása Folyamatok megszüntetése Attribútumok olvasása és megváltoztatása Folyamatok felfüggesztése és újraindítása
133
7.5.1. Folyamat előállítás Általában egy folyamat-előállító rendszerhívással aktivizálható, és szorosan illeszkedik a hierarchiába. A futtatásra előkészített folyamat előállítása során a következő műveleteket végezzük: A PCB előállítása. Memóriaterület allokálása a program és az adatok számára. A program betöltése a futtatáshoz. Kezdeti paramétereket, forráskorlátokat hozzárendeljük a folyamathoz Az indításhoz szükséges források allokálása. PCB beállítása az indításhoz. 134
67
7.5.2. Folyamatok megszüntetése Egy folyamat megszüntetésére különböző okokból kerülhet sor: Önmaga igényelt normális befejezést. Végrehajtása során valamilyen „nem azonosítható” hiba keletkezett. Operátori parancs megszakította a folyamatot. A létrehozó folyamat ért véget (normálisan vagy abnormálisan). Egy kitüntetett folyamat kényszerítette ki a befejezést. Maga a megszüntetés egy folyamatmegszüntetés rendszerhívással aktivizálható.
135
A folyamat megszüntetésének lépései: Távolítsuk el a PCB-t az aktuális állapotának megfelelő sorból és oldjuk fel azokat a kötéseket, amelyek őt valamelyik másik sorhoz láncolták (logikailag kiemeljük a sorból). Szüntessünk meg minden „gyermek” folyamatot, amelyet az aktuális tevékenység állított elő. Szabadítsuk fel az allokált memóriát és minden más lekötött erőforrást. Szabadítsuk fel a PCB-t.
136
68
7.5.3. Attribútumok olvasása és megváltoztatása Amikor műveleteket hajtunk végre egy folyamaton, akkor gyakran előfordulhat, hogy adatokat akarunk kiolvasni a PCBből, vagy bizonyos értékeket akarunk megváltoztatni. A kis rendszerekben a PCB a folyamat által elérhető címterületen belül helyezkedik el, ezért a változtatásokat közvetlenül végre lehet hajtani. Ha a PCB közvetlenül nem érhető el, akkor egy PCB-olvasás (read-PCB) rendszerhívást alkalmaz az OR. Ilyenkor a teljes PCB egy – a címterületen belüli – pufferba töltődik, és a változtatások így hajthatók végre. Más esetekben csak egyes mezők (információk) értéke kerül a címterületen belülre (aktuális állapot, prioritás, elhasznált CPU idő), és a változtatások végrehajtása után visszaírjuk az információt. 137
7.5.4. Felfüggesztés és újraindítás Egyes OR-k megengedik, hogy egy folyamat sajátmagát – vagy az általa ellenőrzött folyamatok valamelyikét – felfüggessze egy felfüggesztés (suspend) rendszerparancs segítségével. Ilyen igény akkor keletkezik, ha a folyamatnak várakoznia kell egy másik folyamat eredményére, valamilyen megszakítás következik be vagy egy időpontra várunk a folytatáshoz. Az így felfüggesztett folyamatot az OR figyeli, és az előírt feltételek teljesülésekor az ”alvó” folyamatot felébreszti egy újraindítási (wake up) rendszerutasítással.
138
69
8. Az ütemezés A számítógépnek meg kell osztania a korlátozottan rendelkezésre álló erőforrásait a folyamatok között. Az OR egyik legfontosabb feladata az, hogy korrekt és hatékony módon gondoskodjon az erőforrások kiosztásáról az igénylő folyamatok között. Azt a műveletet, amely meghatározza a sorrendet az újrafelhasználható erőforrások igénybevételére, és kiválasztja ezekből az aktuális folyamatot, ütemezésnek nevezzük. Az erőforrások között kiemelkedő helyet foglal el a CPU és az operatív memória. Az ezekért folytatott verseny rendkívül kiélezett, megszerzésüket nehezíti, hogy a folyamatok ismételten nem folyamodnak értük, futásuk alatt mindvégig feltételezik, hogy a rendelkezésükre állnak. 139
Az OR ütemezési stratégiája nagymértékben függ attól, hogy mikor szerez tudomást a folyamat várható EF igényeiről és hogyan kell azokat kiszolgálni. Ebből a szempontból a folyamatokat kategóriákra fogjuk osztani: A batch-folyamatok egy job-ban foglalnak helyet, amelyet mind a felhasználó, mind az OR egységes egészként kezel. Végrehajtásuk általában hosszú időt vesz igénybe, és ez idő alatt a felhasználó egyszer sem lép kapcsolatba a futó folyamatokkal. Interaktív folyamatok interaktív terminálról küldött felhasználói igényeket elégítenek ki. (rövid lefutás, felhasználói parancs) Real-time folyamatok esetében a folyamat a rendszeren kívül zajlik le, az OR ezt ellenőrzi és irányítja. A végrehajtásra erősen behatárolt idő áll rendelkezésre. 140
70
Az egyes kategóriákra vonatkozó ütemezési stratégiákat tovább oszthatjuk: A hosszútávú ütemezési stratégiák helyezkednek el a legmagasabb szinten. Ilyenkor a cél az, hogy az OR ellenőrizze azt a sorrendet, amelyben a folyamatok a rendszerbe jutnak. A középtávú ütemezési stratégiák az előállított folyamatok közül választják ki azokat, amelyek jelöltek lehetnek a CPU aktív használatához. A középtávú ütemezés során az operatív memória kiosztása a cél. A rövidtávú ütemezés helyezkedik el a legalacsonyabb szinten. Ez a művelet határozza meg, hogy hogyan rendeljük hozzá a CPU-hoz az aktív állományból a folyamatokat. 141
8.1. Ütemezési célok A felhasznált ütemezési stratégiák nagymértékben függnek attól, hogy milyen célt tűzünk ki elsődlegesen: Áteresztés: a lehető legtöbb munkát végezzük el adott idő alatt Átfutás: a lehető leggyorsabban befejezni a munkát Válasz: kiszolgálás a legrövidebb időn belül Korrektség: azonos jellemzőjű job-okat korrekt módon ütemezni Konzisztencia: kiszámítható módon Források kezelése: kiegyenlítetten, folyamatosan 142
71
Ahhoz, hogy „jó” stratégiát tudjunk a kitűzött célok megvalósításához szolgáltatni, a rendszerbe érkező folyamatokat kategóriákba sorolhatjuk. Ezt bizonyos alapadatok ismeretében tudjuk megtenni: A folyamat kategóriája. A folyamat prioritása. Becsült futási idő és a szükséges erőforrások. Kapcsolat egy interaktív terminállal. I/O - igények és azok gyakorisága. A kiszolgálásra mennyi ideje várakozik a folyamat. Az ütemezési stratégiák „jóságának” megítélésére különböző speciális paramétereket mérünk: Várakozási idő (W). Várakozási sor hossza (S). Várakozási hányadok (W / (W+S)). 143
Két lehetőség van a stratégia „jóságának” megítélésére: Legrosszabb- eset vizsgálat: azt határozzuk meg, hogy a lehető legrosszabb esetben milyen távol kerültünk az elméleti optimum értéktől. Hátránya, hogy nem adja meg a pontos értéket a futtatáshoz, csak egy olyan felső becslést szolgáltat, amely többnyire csak nagyon szélsőséges esetben következik be. Átlagos-eltérés vizsgálat: azt mondja meg, hogy a mért értékek statisztikai jellemzői mennyire térnek el az optimális értékek statisztikai mértékeitől. Ebben az esetben szükségünk van a mért paraméterek statisztikai eloszlásának ismeretére. A leggyakrabban mért jellemzők: várható érték, szórás, variancia. 144
72
8.2. Néhány fontos jellemző
2.
3.
1. Prioritások A folyamatokhoz rendelt mérőszám a többiekhez viszonyított relatív fontosságot adja meg. Statikus prioritás: ha a kezdetben kapott prioritási érték a folyamat élettartama alatt nem változik meg. Dinamikus prioritás: ha a prioritás aktuális értéke a státuszának alakulásával időben változik. Megszakíthatóság Az ütemezési stratégia olyan, hogy nem engedi meg a megszakítást. A stratégia olyan, hogy megengedi a megszakítást. Az önköltség Ilyenkor figyelembe vesszük a folyamatok kicserélésére használt időt. 145
8.3. Batch folyamatok ütemezése Amikor egy rendszer batch üzemmódban kezel egy jobot, akkor a felhasználó a job elküldésével egyidejűleg minden információt és végrehajtási utasítást a rendszer tudomására hoz. Attól a pillanattól kezdve, hogy a job a rendszerbe került, a felhasználónak nincs lehetősége kapcsolatba lépni vele. A batch jobok egyik fontos paramétere a job becsült futási ideje, amely egyben korlátként is szolgál a rendszer számára. A batch jobok esetében a felhasználók által leginkább elvárt cél az, hogy az általuk elküldött job a lehető leghamarabb átfusson a rendszeren. 146
73
8.3.1. Hosszútávú ütemezés A kezdeti prioritás, a felhasználó által adott becslések jó lehetőségeket adnak az OR számára, hogy szignifikáns döntéseket hozzon már ezen a szinten is. Az általános eljárás a következő: A jobokat egy közbülső tárolási területről (spool terület) input sorokba állítjuk a megadott paraméterek alapján. Minden job-osztálynak egy input sor áll rendelkezésére. A rendszer initiator elnevezésű folyamatai vizsgálják az input sorokat, és akkor választják ki végrehajtásra a jobot, ha az első stepje számára az összes igényelt erőforrás a rendelkezésre áll. Ekkor az erőforrásokat hozzárendeli a stephez, és megkezdődik a végrehajtás. Amikor a folyamat végrehajtása megindul, akkor egy időzítőt (timert) állít be a rendszer, ezzel biztosítva, hogy a tervezett futási időt ne lépje túl a job. 147
8.3.2. Középtávú ütemezés Általában nem tekintjük külön lépésnek, mivel a jobokat akkor rendeljük a memóriához, amikor minden erőforrás a rendelkezésünkre áll és a végrehajtás is azonnal megindul. Általában a jobok addig maradnak a memóriában, amíg be nem fejeződnek.
148
74
8.3.3. Rövidtávú ütemezés Ha az operatív memória felszabadul, akkor a készenlétben lévő folyamatok közül válogatunk. Ha egy folyamat beindult, akkor mindaddig folytatódik, amíg a következő események valamelyike be nem következik: A folyamat végetér. A folyamat önként felfüggeszti magát. I/O-utasításra van szüksége, vagy olyan szolgáltatást kér, amely várakozást igényel. Magasabb prioritású folyamat miatt megszakítás következik be.
149
A rövid távú ütemezés stratégiái: First-In First-Out (FIFO) stratégia: az egyik leggyakrabban használt batch vezérlő eljárás. Minden jobnak azonos prioritást biztosítunk. A beérkezés sorrendjében lesznek végrehajtva. Shortest Job Next (SJN): előnyben részesíti azokat a jobokat, amelyeknek rövidebb a becsült végrehajtási ideje. Hátránya: „éhenhalási” jelenség. Egyik legismertebb technika a statikus prioritással rendelkező eljárások közül. A dinamikus prioritási stratégiák: a jobok „öregedésével” egyidejűleg változtatják a prioritást. Így előbb-utóbb minden job végrehajtásra kerül. Shortest Remaining Time Next (SRTN): a megszakításos rendszerekben sűrűn használt technikák közül az egyik legismertebb. Mindig az a job kerül vissza, amelyiknek a legkevesebb megmaradt ideje van. 150
75
8.4 Interaktív folyamatok ütemezése Az interaktív folyamatok olyan tevékenységeket hajtanak végre, amelyeket interaktív terminál mellett ülő felhasználók követelnek meg. Az interaktív folyamatok esetében az a probléma, hogy a folyamat beindításakor általában semmit sem tudunk az igényelt forrásokról. Ennek az a következménye, hogy az ilyen típusú folyamatokat az indulás pillanatában azonosan kezeljük. Amennyiben a folyamat már fut, a múltbeli viselkedésükből próbálunk információhoz jutni ahhoz, hogy a jövőbeli igényeiket becsülni tudjuk. A legfontosabb cél: az interaktív felhasználó gyors és következetes választ vár az ütemezőtől minden egyes igényének teljesítésekor. A hosszútávú ütemezésnek itt nincs nagy jelentősége: egy újonnan létrehozott folyamatot ugyanis normális körülmények között azonnal elfogadunk. 151
Mivel a legfontosabb az, hogy az ütemező gyors választ tudjon adni a jelentkező igények kielégítésekor, ezért a diszpécser programnak biztosítania kell azt, hogy a CPU hozzáférhető legyen minden process számára és a váltásnak is olyan sűrűnek kell lennie, hogy egyetlen folyamat se várakozzon hosszú ideig a kiszolgálásra. Az ilyen típusú ütemezési feladatokat az ún. időszeletek elvének felhasználásával végzi az ütemező program. Ennek lényege az, hogy minden folyamat arra az időre, amikor aktívvá válik, kap egy időszeletet a kiszolgálásra. Ha felhasználta a rendelkezésre álló időt, akkor felfüggesztjük a futást és átadjuk a helyet a következő folyamatnak. Az, hogy mekkora időt biztosítunk egy folyamat számára, az függ a tekintett tevékenység jellemzőitől. 152
76
8.4.1.Középtávú ütemezés A központi tár időszeletének kiosztásáért a középtávú ütemezés a felelős. A rendelkezésre bocsátott idő általában néhány másodperc és 1-2 perc között változik. 8.4.2. Rövidtávú ütemezés A CPU időszeletének kiosztását a rövidtávú ütemezés segítségével végezzük. A biztosított időszelet nagyságrendje általában 100 millisecundumtól néhány másodpercig terjed. A folyamatokat vagy prioritás alapján választjuk vagy egyszerűen a készenléti sorban elfoglalt helyük határozza meg a belépések sorrendjét. 153
Rövidtávú ütemezési stratégiák Körkörös ütemezés esetén a készenléti állapotban lévő folyamatok PCB-it egy egyszerű sorba fűzzük fel. Minden folyamathoz egy rögzített időszelet tartozik. Amikor a CPU felszabadul, akkor a sor elején lévő folyamatot választjuk ki futásra. Amint az felhasználta a rendelkezésére bocsátott időt, megszakítjuk és a sor végére állítjuk. Prioritásos módszerek esetén a folyamatok prioritásuk szerint vannak csoportokba sorolva. A csoportokon belül általában körkörös ütemezést alkalmazunk. A prioritásos eljárások egyik jellemzője, hogy a különböző prioritásokhoz különböző időszeleteket rendelünk. Általános szabály, hogy az alacsonyabb prioritású folyamatokhoz nagyobb időszeletet rendelünk. („igazságosság elve”) 154
77
Néhány prioritási stratégia Öregítési technika alkalmazása: a folyamat-sorokat időszakonként felülvizsgáljuk. Megnöveljük a prioritását azoknak a folyamatoknak, amelyekre az elmúlt időszakban nem került vezérlés. Visszacsatolás: az éppen befejezett folyamat átkerül egy alacsonyabb prioritású szintre. Önző ütemezési technika: (Kleinrock) azokat a folyamatokat részesíti előnyben, amelyeket már elfogadtunk a feldolgozásra. „Tisztességes kiosztás” módszere: az egyes osztályokhoz rendelünk egyenlő mennyiségű CPU időt az osztályban elhelyezkedő folyamatok számától függetlenül. Ezután az eljárás úgy osztja a prioritásokat a csoportokhoz, hogy az alacsony CPU idővel rendelkező folyamatok magas prioritást kapjanak. 155
9. Konkurens folyamatok interakciói A CPU és az operatív memória csak két kitüntetett erőforrás. Az ütemezés során a többi rendelkezésre álló forrás felhasználhatósága limitálva van. Emellett a folyamatok sem függetlenek egymástól. Az interakció jelenségét általánosan vizsgálva két típust különböztetünk meg: Akaratlan: Az erőforrások osztott használata esetén Akaratlagos: a kommunikációból eredő interakció esetén A különböző típusú interakciók különböző problémákhoz vezethenek: Holtpont Kölcsönös kizárás 156
78
9.1. A holtpont Egyrészt akkor fordulhat elő az ütemezés során, ha a folyamatok egy adott halmazában minden egyes elem leköt néhány erőforrást és ugyanakkor várakozik is néhányra. Ha ilyen esetben a folyamatok egy része olyan erőforrásokra várakozik, amelyet mások lefoglalnak, akkor a tevékenységek „megmerevedhetnek”. („útkereszteződés”!) Holtpont keletkezhet kommunikáció esetén is: ha a folyamatok egymás információira várnak, miközben nem tudnak előrehaladni saját feldolgozásukban. Különösen nehéz felfedezni a holtpontot osztott környezetben. Nagyon kevés OR garantálja, hogy az ütemezés során holtpont nem fordulhat elő. A megbízható megoldás rendkívül drága. 157
9.1.1 A holtpont bekövetkezésének feltételei (Coffman, 1971): Kölcsönös kizárás Erőforrások lefoglalása Megszakítás nem megengedett Visszatérő igények Ezeknek a feltételeknek egyidejűleg kell fennállni! Így az egyik lehetséges módszer a holtpont elleni védelemhez, hogy ezt az egyidejűséget igyekszünk kiküszöbölni.
158
79
9.1.2. A holtpont megelőzésének lehetséges stratégiái Holtpont megelőzése: célja, hogy úgy ütemezzük a különböző erőforrásokat, hogy a holtpont bekövetkezésének feltételei közül legalább egy ne teljesüljön. (OR-k tervezésénél!) Holtpont elkerülése: megkíséreli azt biztosítani, hogy sohase allokáljuk a forrásokat oly módon, hogy a rendszer „bizonytalan” állapotba kerüljön. Holtpont érzékelése: a bekövetkezett holtpont detektálása nem könnyű feladat! Holtpont megszüntetése: ha a holtpontot valamilyen módon érzékeltük, akkor az OR egyik legfontosabb feladata a várakozási kör valamilyen módon történő lerombolása. 159
9.2. A kölcsönös kizárás Egyes erőforrások – természetüknél fogva – olyan tulajdonságúak, hogy egy adott időpillanatban csak egy tevékenység számára állnak rendelkezésre. Ha tehát egy ilyen EF éppen használatban van, akkor az érte jelentkező újabb folyamatoknak várakozni kell. Ha egyidőben több igény is érkezik, akkor az OR felelős azért , hogy a kiosztás korrekt és hatékony legyen. A konkurens folyamatok által igényelt forrásokat két csoportra osztjuk: A rendszer által ellenőrzött források (CPU, memória, I/O-készülékek és állományok) A felhasználó által ellenőrzött források (osztott elérés) 160
80
9.3 Folyamatok közötti kommunikáció (Interprocess communication IPC) Amennyiben egy folyamatban azt tervezzük, hogy kooperálni akarunk más folyamatokkal, akkor létre kell hozni egy közös területet (taskot), hogy az információcserét megkönnyítsük. A tevékenységek közötti kommunikáció egyre nagyobb szerepet kap. Az alábbi modellek közül valamelyiket be kell építeni: Többszörös hozzáférésű memóriakezelés Üzenetátadás technikája (lassabb, mégis szélesebb skálán használjuk.) 161
9.3.1. Az üzenetátadással kapcsolatos problémák. Szinkronizálás: a kommunikációnak a legegyszerűbb formája, amikor egyetlen bit információt cserél két folyamat. Esemény bekövetkezéséről tájékoztat, vagy tudatja, hogy a végrehajtásban egy bizonyos pontig eljutott A szinkronizációnak két típusát különböztetjük meg: A folyamat „alszik” A folyamat a felfüggesztés állapotában van, mert egy jelre várakozik. Közvetlen kommunikáció üzenetek küldésével és fogadásával (A folyamatok közötti közvetlen információcserének leggyakrabban alkalmazott módja. Üzenetküldő: send, üzenetfogadó: receive) Közvetlen kommunikáció csatorna használattal (write, read, pipe) Közvetett kommunikáció (mailbox) 162
81
10. Megszakítások, I/O - kezelés Megszakításokkal segíthetjük a készülékek kezelését, jobb kihasználásukat. Hardware megszakítás Software megszakítás (folyamat által vezérelt) Ahhoz, hogy vissza tudjunk térni a felfüggesztett folyamathoz, a környezetet meg kell jegyeznünk! Ha többféle megszakítás lehetséges egy időben, akkor a helyzet bonyolódik. Bármilyen megszakítás történik, az alapkoncepció változatlan: Mentsük el a végrehajtási címet. Mentsük el a státuszinformációkat. Adjuk át a vezérlést a megszakítás-kezelőnek 163
10.1 A megszakítások típusai A számítógépek nem mindig rendelkeznek az összes ilyen megszakítástípussal. A leggyakrabban előforduló megszakítások: Megszakítás I/O-művelet befejezése miatt Riadó-megszakítás Timer-megszakítás Programhiba-megszakítás Rendszer-megszakítás Készülékhiba-megszakítás
Minden rendszer szerves része.
164
82
Ha a megszakításokat más szempontok szerint osztályozzuk: Folyamatbefejezési (pl.: I/O, timer) Szolgáltatásigénylő (rendszer, riadó) Hibakezelési (program, hardware)
165
10.2 Megszakítások rendezése, maszkolás Minden olyan rendszer, amely megszakításokat kezel, egyes típusokat előnyben részesít. Erre akkor van szükség, ha két megszakításjel érkezik egyszerre. Egyiknek prioritással kell rendelkezni. Ilyenkor a megszakítások vagy sorosan vagy egymásba ágyazva hajtódnak végre Időnként előfordulhat, hogy bizonyos megszakításokat nem akarunk engedélyezni. Ilyenkor megszakítás maszkolást használunk.
166
83
A megszakítás-maszkolás technikái: Megszakítás-maszkolási regiszter: ilyenkor a regiszterben egy-egy bit van egy megszakításhoz (vagy egy megszakításcsoporthoz) rendelve. Prioritási szint beállítása a programstátusz-szóban. Ilyenkor csak azokat a megszakításokat fogadjuk el, amelyek e szint felett vannak. Ehhez a megszakításokhoz prioritási szinteket kell rendelni) Nem minden megszakítás maszkolható. Pl. rendszermegszakítások ilyenek.
167
10.3 Input és output készülékek kezelése A számítógépek rendelkeznek azzal a lehetőséggel, hogy képesek ellenőrizni és kommunikálni azokkal a készülékekkel, amelyekkel össze vannak kötve. A kezdeti időszakban: I/O–készülékekként „testreszabott” utasításokat építettek be a gépi kódú utasítások közé. Ez ma már a kapcsolható perifériák nagy száma miatt nem alkalmazható. Ma: I/O - interface technikát alkalmaznak. Ennél a technikánál a készülékeket regisztereken keresztül érik el. (Minden készülékregiszterhez egy egész számot rendelünk, amely címkeként használható. Ezt a számot csatornaszámnak (portszámnak) nevezzük.
168
84
Mivel a regiszterekben címeket tárolunk, ezért ezekkel címeket lehet elfoglalni a memóriában. Ez az I/O terület, amely általában különbözik az egyéb memóriaterületektől (De lehet velük közös is: ilyenkor beszélünk memóriába ágyazott – memory mapped – I/O-ról). Ebben az esetben nincs szükség külön I/O utasításokra, hanem memóriába író-olvasó utasításokat alkalmazunk a készülékregiszterekbe történő írásra-olvasásra. Fontos előnye ennek a technikának, hogy az adattranszfer műveletek mellett aritmetikai és logikai műveletek is végezhetők a tartalmakon. A módszer hátránya viszont az, hogy a terület nem élvezi a speciális utasítások védelmét, így a véletlen hibák valószínűsége megnő. 169
Attól függően, hogy milyen az I/O készülék típusa a készülékek kezelésére különböző stratégiákat alkalmazunk:
Egyszerű I/O – stratégia vagy programozott stratégia (kis- vagy közepes méretű számítógépekkel): az I/O műveleteket arra használjuk, hogy az átvinni szándékozott információ egy egységét a készülékre átvigyük (vagy onnan áthozzuk).
170
85
Blokk átvitel (kis- ill. közepes számítógépeknél): olyan készülékeknél használjuk, amelyek képesek blokkokat is fogadni nagy átviteli sebesség mellett. (Ilyenek a mágneslemezek.) Ilyenkor az I/O inteface szerepét egy I/O controller tölti be, amely elegendő tárterülettel és logikai áramkörrel rendelkezik ahhoz, hogy az egész átviendő blokk mozgását ellenőrizni tudja. Ilyenkor a controller közvetlen kapcsolatban van a memóriával. Ezt nevezik közvetlen elérési technikának (Direct Access Memory = DMA)
171
I/O – processzorok használata (nagy szg-ken): Ilyenkor a számítógé-pek egy speciális célú processzorral vannak felszerelve, amely alkalmas utasításokat adhat a közvetlen I/O műveletekhez. Általában készülékcsoportonként processzort.
használunk
egy
ilyen
A processzorok felépítése olyan, hogy csak korlátozott számú utasítást „értenek meg”, de azokat nagy sebességgel hajtják végre. Számos olyan készülék van, amely az átvitt adatok tárolására átmeneti területet használ fel, mielőtt azokat a memóriában véglegesen elhelyezi. Egy jellemző példa a billentyűzet kezelése: itt a készülékről érkező jel egy átmeneti pufferbe kerül, és a készülék azonnal készen áll a következő karakter fogadására. 172
86
Az I/O műveletek végrehajtásakor a rendszernek tudni kell, hogy egy új adatátvitel előtt a készülék rendelkezésre áll-e az adatátvitelre. Egyszerűbb készülékek esetén ezt a készülékválasztás technikájával példák meg (device polling). Ilyenkor a CPU időnként megvizsgálja a státuszértékeket annak eldöntésére, hogy az aktuális I/O művelet befejeződött-e. Ez az eljárás nem hatékony. A másik technika az I/O befejezési megszakítás, amikor a művelet befejezése után egy megszakítás jelet küldünk az OR számára.
173
10.4 Órák és időzítők Az órák és a különböző időzítők (timerek) lényegében hardware és software mechanizmusok az idő mérésére. A hardware órák legtöbbje: hálózati óra. A programozható órák: egy számláló regiszterrel rendelkeznek, amelynek tartalma meghatározott időközönként csökkenthető. Amikor a tartalma zérus lesz, akkor egy megszakítás generálódik. Az órák meghajtása az óra ütemek segítségével történik. Az óra ütem egy jel, amelyet vagy rögzített vagy változó időszakonként bocsát ki a hardware óra. Azt az időintervallumot, amely két egymást követő ütem között eltelik, az óra felbontásának nevezzük. 174
87
A timerek segítségével számos OR – felhasználó – igény kelégíthető: A napi idő kezelése (napi óra, dátum) Rendszerfolyamatok figyelése (időtúllépési intervallum) Folyamatok felfüggesztése egy megadott időszakra Folyamat indítása egy meghatározott időpont bekövetkezésekor Előfordulhat az, hogy az időzítőhöz rendelt szolgáltatást meg kell szakítani. (Aktív-e a folyamat? Ellenőrizni kell!) Mivel egy multiprogramozható környezetben egyidőben több megmegszakítás is érkezhet, – és ezeket a lehető leggyorsabban ki kell elégíteni – ezért nem lehetséges, hogy minden megszakításigényhez külön órát rendeljünk. 175
Ilyenkor a beérkező igényeket egy időzítő sorba (timer queue) helyezzük el. Egy ilyen elemnek tartalmaznia kell: Pointert a sor következő elemére. Időparaméter értéket. Az időponthoz rendelt folyamat PCB – jének címét. Pointert a megkívánt műveletet végző eljárás elejére. Az igény típusát.
176
88
A sorban az elemeket a megjelölt időparaméter szerint növekvő sorrendben helyezzük el. Minden olyan időpontban, amikor a valós időt továbbléptetjük, megvizsgáljuk a sorban elhelyezett elemeket, és minden olyan elemnél, ahol a beállított időt túlléptük, végrehajtjuk a kijelölt műveleteket. Mivel az igényelt időpontok mindig az aktuális időpontra vonatkoznak, ezért sarkalatos kérdés, hogy hogyan tudjuk megoldani – az aktuális időpont változásával egyidejűleg – az időzítő sor elemeiben elhelyezett időpontok aktualizálását. Ugyancsak érdekes kérdés, hogy egy már létező idő–sorhoz hogyan csatolunk új elemet, ill. hogyan törlünk abból elemet.
177
11. Készülékek kezelése Az OR szolgáltatásai közül az egyik legjelentősebb az a támogatás, amelyet a rendszer az I/O-készülékek kezelése során végez. A korai rendszereknél ez nem volt számottevő. A mai többfelhasználós OR-k esetében: minden készülék teljes ellenőrzése a rendszeren belül történik. Emellett az OR-nek kell figyelni: A I/O-készülékekre várakozó folyamatokat Az egyes befejezéseket Ütemeznie kell a soron következő I/O-műveletet Végre kell hajtania a különböző olyan változásokat, amelyeket az I/O-események okoznak. Ezt a feladatot – minden egyes I/O készülékre – a készülékmeghajtó program (device driver) végzi. 178
89
11.1. Az I/O - készülékek jellemzői Az I/O-készülékeket alapvetően három csoportba oszthatjuk: Tároló típusú készülékek Mágneses típusú készülékek kazetták, mágneslemezek ) Optikai tárolók
(mágnesszalagok,
mágnes-
Terminálok RS-232 soros interface-szel Memóriába beágyazott képernyő segítségével kapcsolódnak Billentyűzet, egér Nyomtatók Tűs Tintasugaras Lézer 179
11.2 Készülékmeghajtók Az OR-k legtöbbjében azok az utasítások, amelyek egy adott típusú I/O-készülék elérésével, annak ellenőrzésével foglalkoznak, egy programegységben vannak összegyűjtve, amelyet készülékmeghajtónak nevezünk. Az OR-nek azt a részét, amely a teljes I/O-kezelést tartalmazza I/O részrendszernek nevezzük. Az OR-k kétféleképpen kezelik a meghajtókat: A meghajtók a kernel részei A meghajtók független modulokként csatlakoznak a rendszerhez. Szabványos csatlakozási felület esetén használhatók az un. készülékfüggetlen meghajtók. (pl. UNIX, amely karaktertípusú és blokktípusú készülékeket ismer. 180
90
11.3 Interface-ek és jellemzőik A készülék és a számítógépes rendszer többi része között a kapcsolatot az I/O interface szolgáltatja. Típusai: Soros és párhuzamos interface, I/O controller Képes közvetlen memória (DMA) elérésű adatátvitelre. Támogatja azt, hogy egy logikai készülékhez több fizikai egység is tartozhat. Támogatja az átlapolt műveletek alkalmazását (lemezen keresés közben egy másik meghajtó adatokat ír nyomtatóra.) I/O processzorok (csatornák). (saját gépi kódú nyelve van. A csatornaprogram megnyitása egy start I/O – SIO – utasítással történik. A csatornaprogram csatorna-parancsokkal – channel command word – kommunikál) 181
11.4 Programozási technikák driverek írásához Bármilyen technikát használunk a meghajtók programozására a készülékekhez rendelt adatokat egy I/O control blokkba kell elhelyezni. A helyzetet az bonyolítja, hogy minél hatékonyabban akarjuk kezelni a készülékeket, annál több adatot kell tárolnunk a control blokkban. Ettől viszont az algoritmusok is bonyolultabbá válnak. Néhány lehetséges adatot sorolunk fel a következőkben a control blokkban tárolható adatok közül: készülék név, ~ cím, ~ típus, csatorna szám, ~ cím, megszakítási vektor cime, megszakítás kezelő címe, open, close, start, cancel szubrutin címe, puffer címek, ~ méretek… 182
91
Technikák A polling technika (egyszerű környezetben, egyfelhasználós OReknél) Az OR mindig megszólítja az adott készüléket mielőtt a következő I/O-utasítást kiadná! Megszakítási technika (többfelhasználós rendszerek is) Készülék megszakítás kezelőt kell beépíteni a meghajtó programba. Pufferek alkalmazása • Blokk-pufferelési technika (karakter típusú I/Okészülékeknél) • Körkörös lista („gyűrűpuffer”) • Kettős pufferezési technika (egy készülékkezelő szubrutinnak több optimalizálási feltételt kell kielégíteni.) Cache használata • Hardware-cache • Software-cache 183
11.5 A meghajtók részfeladatai Előkészület az I/O-műveletre
• Fel kell sorolni azokat a paramétereket, amelyekkel a meghajtót
működtetni akarjuk. (Ezek egy része az OR-hez, maásik része a készülékhez kapcsolódik.)
Az I/O-művelet megindítása
• Engedélyezzük a megszakítást az adott készülék számára. Innentől mindent a megszakítás kezelő végez el. • Speciális start input-output (SIO) utasítás kerül kiadásra. Ekkor az I/O parancs pontosan tartalmazza azokat a paramétereket, amelyekkel a SIO végre tudja hajtani az I/O-t. 184
92
Megszakítás szolgáltatások
• A megszakítás végrehajtásához az információk az I/O kontroll-
blokból kaphatók meg. Fontos, hogy a megszakításkezelőnek a vezérlés átvétele előtt a környezet megőrzéséről gondoskodnia kell.
Hibaérzékelés és – elhárítás
• Különböző készülékeknél különböző – tipikus – hibák
fordulhatnak elő. • A keletkezett hibák elhárítása is nagyon változatos lehet. (Csak hibajelzéstől a hiba teljes felgöngyölítéséig.)
185
I/O-művelet lezárása
• A vezérlés visszaadása előtt néhány tisztogatási feladatot el
kell végezni. (hibakód beállítás, készülék foglaltság átállítása, megszakítások feloldása, stb.)
I/O-művelet megszakítása • Sűrűn előforduló lehetőség (papír begyűrődése). • Karakter típusú műveletnél egyszerűen visszatérünk a hívó folyamathoz. • Blokktípusú műveleteknél megkíséreljük visszaállítani a művelet megkezdése előtti állapotot. • A környezet visszaállításáról mindkét esetben gondoskodni kell. 186
93
11.6 I/O - ütemezés Egyfelhasználós rendszereknél ez nagyon egyszerű. Többfelhasználós rendszereknél bonyolultabb: I/O-sorba állítjuk, mely strukturálisan lehet:
az
igényeket
Egyszerű I/O-sor Többszörös I/O-sor (készülékenként külön sor) A készülékütemezés technikái: FIFO (a legelterjedtebb technika) Prioritásokon alapuló stratégia (Real-time rendszerekben) A legrövidebb keresési idő alapján működő eljárás (mágneslemezek esetében) 187
12. Állományok kezelése A modern OR-ek egyik legfontosabb feladata a felhasználók által összegyűjtött információk megbízható tárolása. Azokat az összegyűjtött információkat, amelyeket hosszú ideig tárolunk és több felhasználó számára is hozzáférhetővé teszünk, információs rendszernek (file system) nevezzük. A filerendszerek egymástól elkülönülő információs egységeit állományoknak (file) nevezzük. Az állományok többnyire azonos tulajdonságú kisebb logikai egységekből – ún. rekordokból – állnak, amelyek mezőkből épülnek fel.
188
94
Az OR-en belül az állományok kezelésével az állománykezelő (file manager) foglalkozik. Fő feladata, hogy megfelelő műveleteket szolgáltasson a programoknak és a felhasználóknak ahhoz, hogy az állományokban tárolt információkat kényelmesen tudják feldolgozni. (információk kiolvasása, módosítás, bővítés, törlés) Fontos, hogy a tárolt adatokat milyen gyorsan tudjuk elérni. Ezért az OR-k lehetőségeket biztosítanak arra, hogy az állományok rekordjait meghatározott sorrendben lehessen elérni. Ezt az indexelés segítségével érik el. Fizikailag az információs rendszerek háttértárolókon helyezkednek el. Az állományok általában fizikailag több egységen helyezkednek el. Néha még az sem biztosított, hogy az egy állományhoz tartozó összes rekord ugyanazon az egységen található. 189
Egy információs rendszerhez hozzátartozik, hogy a benne elhelyezett állományokról ún. „leíró” információkat tartalmaz. Pl.: állomány neve, rekord hossza, blokkolási méret, tulajdonos, hozzáférési lehetőségek, verzió, history… Ezeket együttesen állományleíróknak (file descriptor) nevezzük. A descriptorokat a könyvtárakba gyűjtik.
modern
OR-k
speciális
állományokba,
190
95
12.1 A kötet fogalma és szerkezete Az állományokat háttértárolókon helyezzük el. Az egy fizikai egységen elhelyezkedő állományokat kötetnek (volume) nevezzük. Különbséget kell tenni logikai és fizikai kötet között: Az azonos típusú rekordok összessége alkotja a logikai kötetet. A logikai kötet egy tárolóegységen elhelyezkedő részét fizikai kötetnek nevezzük. Az egy fizikai egységen elhelyezkedő információk könyvtárakra és állományokra oszthatók. A könyvtárak „katalogizálják” az állományokat. Általában a fizikai kötet legalacsonyabb sorszámú sávjain helyezkedik el (mágneslemezről beszélünk). Az állományokat háttértárolókon helyezzük el. 191
Mivel a kötetek cserélhetők, ezért az azonosításukról gondoskodni kell. Az azonosításra szolgáló mezők a kötetleíró információk: A kötet neve Hozzáférési információk Az információs rendszerek kódja A könyvtár helye a köteten Az állományokat tartalmazó terület kezdőcíme Az allokációs információk helye a köteten
192
96
12.2 Állományok szervezése A köteteken található területek legnagyobb része a felhasználói állományok részére van fenntartva. Az állományok adatai a köteten blokkokban helyezkednek el. A blokkok helyének megválasztása döntően befolyásolja azt, hogy milyen gyorsan és kényelmesen érhetjük el adatainkat. Feladatok egy állomány tárolása során: Új állomány létrehozása Meglévő állomány kiterjesztése Tároló terület felszabadítása
193
Tárolási módszerek: Egyszerű, folytonos tárolás Folytonos tárolás kiterjesztési lehetőséggel Láncolt blokkolás Indexelt blokkolás
194
97
12.2.1. Egyszerű, folytonos tárolás A módszer lényege: az állományok elhelyezéséhez szükséges blokkok fizikailag folytonosan helyezkednek el. A módszer előnyei: Nagyon egyszerű kezelni. Két információra van szükségünk: a kezdő blokk címére és az állomány méretére. Az állomány rekordjainak véletlen elérése nagyon hatékony: az állomány rekordjai jól csoportosíthatók, ezért könnyen mozgathatók és egyszerűen címezhetők. A módszer hátrányai: Az állomány csak abban az esetben bővíthető, ha – valamilyen véletlen szerencse folytán – a bővítéshez rendelkezésre áll szomszédos szabad terület. A szétdaraboltság itt is felléphet. Időről időre újra kell szervezni az állományokat. 195
4. Állomány
Descr. 4. SZABAD
SZABAD 3. Állomány 2. Állomány
Állomány Állomány kezdete mérete
Descr. 3. Descr. 2. SZABAD Descr. 1.
SZABAD 1. Állomány
Állományleíró vektor
Egyszerű, folytonos tárolás 196
98
12.2.2. Folytonos elhelyezés, kiterjesztésekkel Az előző módszer kézenfekvő kiterjesztése egy olyan lehetőség, amikor a folytonosan elhelyezett állományhoz – abban az esetben, ha nem áll rendelkezésre megfelelő nagyságú terület – fizikailag különálló részeken csatolunk újabb elemeket. Ezeket kiterjesztéseknek nevezzük. A kiterjesztésekre akkor van szükség, ha a meglévő állományokat új rekordokkal bővítjük, vagy ha új állomány előállításakor – a szétdaraboltság – miatt nincs elegendő hely a folytonos allokálásra. A kiterjesztések különálló bejegyzésként szerepelnek a könyvtárakban.
197
12.2.3. Blokkolt szervezés Az állományok kezelésének egy másik alternatívája az, hogy a tároláshoz szükséges területet blokkokba szervezzük. Ez lehetőséget ad arra, hogy könnyen allokáljunk és szabadítsunk fel területet, de bonyolultabbá teszi az adminisztrációt, hiszen az állományhoz tartozó minden blokkot külön kell kezelni. A módszer nagy előnye, hogy a szétdaraboltság nem lép fel és nincs szükség speciális állománytömörítő programokra sem. Alapvetően két technikát használunk: Blokkolt láncolás: az azonos állományokhoz tartozó blokkok egy láncolt lista formájában vannak összefűzve. Indexelt szervezés: a blokkokban tárolt rekordokhoz indexeket rendelünk és ezeket módosítjuk az állományban bekövetkezett változásoknak megfelelően. 198
99
A blokkolt láncolás Az adatblokkokból leválasztunk egy láncolási információkat tartalmazó részt. (header blokk) Ebben kétirányú felfűzést tárolhatunk az állományhoz tartozó következő ill. megelőző blokkra. (Külön láncoljuk a szabad blokkokat.) Az állományok allokációs paramétereit egy tömbben helyezzük el. Amelynek egy eleméhez pointert rendelünk. Ez a pointer az állományt tartalmazó első blokkra mutat. A módszer előnye: az adatblokkok tartalma könnyen elemezhető a könyvtár ismerete nélkül is, hiszen egyetlen adatblokk megtalálása bejárhatóvá teszi az egész állományt. A módszer hátránya: egyedül a szekvenciális elérést támogatja hatékonyan. 199
Lemezes tárolás esetén az OR támogatja a véletlen elérést is, ezért más technikát használ ilyenkor az OR: Az MS-DOS a láncolási információkat kiemeli egy FAT (File Allocation Table) táblába. Ha egy adatblokk a láncolt állomány része, akkor a hozzá tartozó FAT elem a láncban egy pointert tartalmaz a következő blokkra. Az információk elérését meggyorsítja, ha a FAT a memóriában helyezhető el. A módszer előnye: blokkcsoportok mozgathatók egyszerre az állományok között. Egyszerű a könyvtári bejegyzés is. A módszer hátránya: a véletlenszerű elérés csak hosszú keresés után valósítható meg, és – abban az esetben, ha a FAT nincs a memóriában – nehézkes is. 200
100
Indexelt szervezés Ahhoz, hogy a blokkolt szervezés előnyeit mind a soros mind a véletlen elérés esetén élvezni tudjuk, szükség van arra, hogy az állományokat tartalmazó blokkok címeit – a blokkoktól teljesen különválasztva – egy rekordban tároljuk. Az indexet minden állomány esetében az állományleíró blokk részeként tároljuk. Kis állományok esetében az összes blokkot a könyvtárban helyezzük el. Mivel az állományleíró méretét korlátoznunk kell, ezért max. 12 blokknak a címét tárolhatjuk a könyvtárban. Ha további blokkokat kell az állományhoz rendelni, akkor egy közbülső blokkot lefoglalunk az alatta levő blokkok indexeinek a tárolására. (További néhány száz cím tárolására alkalmas.) 201
12.3 Könyvtárak szervezése Az állományok kezelése erősen támaszkodik egy speciális szerkezetű leíró állományra, amelyet könyvtárnak nevezünk. A könyvtárak a köteten található állományok jellemzőit írják le. Minden állományhoz hozzá kell rendelni egy nevet, amely az elérést megkönnyíti. Az OR a megadott név alapján keres, ezért a névnek olyannak kell lennie, hogy az alapján az azonosítás könnyen elvégezhető legyen. Az állományok nevével kapcsolatos tudnivalók: Egyszerű karaktersorozat (pl.: ASCII) Különböző OR-k, különböző szabályok A névnek rövidnek, informatívnak kell lennie Állománynevek hossza Az állománynevekben felhasználható karakterek (korlátozások!) 202
101
Az állományokat két részre osztjuk: Az egyik részben foglalnak helyet az un. leíró információk, a másik részben helyezkednek el az állomány rekordjai. A leíró információk az OR-től függően eltérőek lehetnek, azonban néhány alapinformációt mindenképpen tartalmazniuk kell. (pl. állomány neve, címe, mérete, szervezése, stb.) A leíró információk különálló könyvtárakban helyezik el. Ezek olyan egyszerű könyvtárak, amelyek számára összefüggően allokálunk fix hosszúságban lemezterületet. A könnyebb kezelhetőség kedvéért néhány OR szétbontja az állományleíró rekordokat: a UNIX esetében az állományleíró rekord csak az állomány nevét és egy pointert tartalmaz. A pointer egy un. információs csomópontra (i-node) mutat, ahol az állományra vonatkozó további információk találhatók. Ez – az ábrán is követhető módon – lehetőséget ad arra, hogy másmás névvel (alias név, link) is hivatkozhatunk ugyanarra a fizikai állományra. 203
A legelterjedtebb könyvtárkezelési technikák 12.3.1. Egyszerű könyvtárak Kötetenként egyetlen könyvtárat használunk, amely állományonként tartalmazza a leíró információkat. A könyvtárrendszer kezelése egyszerű, hiszen egyetlen könyvtárunk van csak. A módszer hátrányai: A leíró rekordok száma nagyon megnőhet, aminek az lesz a következménye, hogy megnövekszenek a keresési- és az elérésiidők is. Nehéz továbbá állománycsoportokat létrehozni felhasználók számára. Egy könyvtár magában rejti annak veszélyét, hogy hosszú állományneveket kell használnunk a külső azonosításhoz, amely ismét nehezebb helyzet elé állítja az OR-t. 204
102
12.3.2. Felhasználói könyvtárak Ha több felhasználó használhatja ugyanazt a kötetet, nem kívánatos, hogy egymás állományait korlátozás nélkül használhassák. A hozzáférések korlátozhatók azáltal, hogy tiltjuk az írást és / vagy olvasást más felhasználók számára. A másik probléma az, hogy több felhasználó esetén könnyebben fordulhat elő, hogy ugyanazt a nevet használja két különböző felhasználó. ún. minősített nevek használata (a nevek kiterjesztésébe kell beírni a felhasználó nevét vagy azonosítóját) Felhasználónként egy speciális állományt definiálása (katalógus), amely azokat az állományneveket tartalmazza, amelyek a megadott felhasználóhoz tartoznak.
205
Könyvtár-1
Könyvtár-2
i-csomópontok
Fizikai állományok 206
103
A többfelhasználós rendszerekben a leggyakrabban használt technika az, hogy a felhasználó definiálásával egy időben kijelölünk számára egy saját (home) könyvtárat, amely mintegy „vonatkoztatási pontként” szolgálhat az állományok eltárolásához.
207
12.3.3. Hierarchikus könyvtárak A saját könyvtárak rugalmassága nagymértékben kiterjeszthető, ha a felhasználónak lehetősége van szabadon definiálni könyvtárakat az állománycsoportjai számára. A technika lényege: Létezik egy állományok.
főkönyvtár,
amelynek
elemei
kezdetben
az
Amikor szükségünk van arra, hogy a felhasználókat szétválasszuk, akkor egy-egy új bejegyzést (al)könyvtárként nevezhetünk meg, amelyben elhelyezhetjük a felhasználó állományait. Ebben az alkönyvtárban ismét lehetőséget biztosítunk újabb (al)könyvtárak létrehozására, ezáltal kijelölve egy hierarchikus szerkezetet. A rendszerben egy állományt – a könyvtárak sorozatával definiált – úttal (path) érhetjük el. 208
104
A létrejött hierarchia nagyon mély lehet, ilyenkor előfordulhat, hogy az út megadása bonyolult. Ezért bevezették az un. aktuális könyvtár (current directory) fogalmát. (Ez az a könyvtár, amelyben a felhasználó a parancs kiadásakor „tartózkodik”.) Így lehetőség van arra, hogy az útvonalat az aktuális könyvtárhoz viszonyítva adjuk meg. Kialakult a teljes (abszolút) vagy a viszonylagos (relatív) út megadásának technikája.
209
12.4 Műveletek állományokon Állományok elérése: (megnyitás - open, keresés - seek, olvasás read, írás - write, lezárás - close) Területszervezés: (állományok előállítása - create, törlése - delete, meglévő állományok bővítése új rekordokkal - extend ill. rekordok törlése meglévő állományokból - truncate) Kiegészítő műveletek: (állománynév megváltoztatása – rename, megváltoztatni az állomány tulajdonosát, elérési korlátait és típusát, alias nevek) Kötetkezelés: (köteteket fizikailag eltávolítani, vagy helyettesíteni)
210
105
13. Hibakezelés, megbízhatóság, védelem Ha egy OR tervezésénél és elkészítésénél nem kellene ezekre a feladatokra is figyelemmel lenni, akkor az egész rendszer sokkal egyszerűbb lenne, mint a végső megoldás. E három feladat az OR-k méltánytalanul háttérbe szorul.
mindennapos
vizsgálatánál
Ha ezeket a feladatokat nem oldja meg jól egy OR, akkor a rendszer szolgáltatásai bizonytalanok lesznek, nem tudjuk biztosítani a hatékony és gyors kiszolgálást. Ennek az lesz a következménye, hogy elveszik a bizalom az OR iránt és a felhasználók elfordulnak a rendszertől.
211
13.1 Hibakezelés Amikor egy hiba keletkezik a rendszerben, akkor erről tudomást kell szereznie egyrészt az operátornak (vagy a felhasználónak), másrészt a futó tevékenységnek (programnak, folyamatnak) is. A hibák elsődleges jelzése a visszatérési (return) kóddal történik. Emellett hibaüzenetet is kel küldeni az operátori konzolra vagy a felhasználói terminálra. A hibaüzenetek formája, időzítése nagyon fontos a hiba elhárítása szempontjából. Szükség lehet további adminisztrációra is: az OR-k erre a célra egy hiba (error) log állományt használnak, amelybe bejegyzik a hiba időpontját, kódját, üzenetét és a process belső azonosítóját. Ha egyszerre több hiba lép fel, akkor egy hibaüzenet sorban helyezi el a rendszer az üzeneteket. 212
106
13.1.1. Készülékhibák kezelése Az I/O – készülékeken végrehajtott műveletek során fellépő tipikus hibák közé tartozik: Az ellenőrző összeg (control-summa) hibája a mágneses adathordozóknál A paritás hibák egyszerű átviteleknél Nyomtatásoknál fellépő különböző hibák
213
Az I/O – készülékeket kezelő meghajtóknak egyetlen feladata van: sikeresen végrehajtani a kitűzött műveletet. Következmény: a fellépő hibák kezelését teljes egészében áthárítják a felhasználóra. Az OR-nek ügyelnie kell arra, hogy az azonos típusú hibákat, azonos hibakóddal jelezze. (pl.: not ready.) Permanens készülék hiba esetén az OR fő feladata az, hogy beszüntesse a további munkát, és leállítsa a futó folyamatokat (shut down). Mágneses készülékeknél az adathordozó rétegen bekövetkezett hibák elhárításának két speciális technikája van: • Az adathordozóról felhasználási táblát (bad track table) készítünk. • „Rossz” állományokat allokálunk a hibás területre. (.BAD állomány) 214
107
13.1.2. Programhibák kezelése Felhasználói programok futása közben is előfordulhatnak hibák. Pl.: nullával való osztás, érvénytelen memóriacímre történő hivatkozás. Ilyenkor a hibákat kétféleképpen kezelhetjük le: Befejezzük a program futását. (Ilyenkor a rendszer közli a megszakítás okát) Hibakezelő szubrutint indítunk el. (Lásd a következő ábrát.)
215
13.1.3. A file-rendszer hibáinak kezelése Amennyiben valamilyen hiba keletkezik egy lemezegységen, akkor következményként hibák léphetnek fel a file-rendszerben vagy a könyvtárban. Mivel a file-rendszerek alapvető fontosságúak az OR-eknél, ezért az állománykezelő szubrutinoknak fel kell ismerni azokat a hibákat, amelyeknek ilyen – nem kívánatos – következményei lehetnek és el kell kerülni a file-rendszer „beszennyezését”. A file-rendszer egységének a megőrzése különösen fontos. (filerendszer ellenőrző program) Egy file-rendszer vizsgálatával kapcsolatban három feladatunk lehet: Ellenőrizzük a file-rendszer érvényességét Állítsuk helyre a rendszer integritását. Készítsünk a rendszerről backupot vagy töltsük vissza a rendszert. 217
108
13.2 Megbízhatóság Egy OR megbízható, ha használható és korrekt marad akkor is, ha hardware problémák és/vagy software hibák lépnek fel. Egy OR biztonságos, ha használható, korrekt és titkos marad akkor is, ha hardware problémák, software hibák lépnek fel és szándékos külső támadások érik a rendszert. Nincs olyan technika, amely minden körülmények között garantálná a tökéletes megbízhatóságot és biztonságot. A cél: olyan stratégiát tudjunk nyújtani, amely nagy valószínűséggel biztosítja számunkra a sikert. Probléma: minél nagyobb biztonságra törekszünk, annál magasabbak lesznek a hardware kiépítésének költségei és egyre drágább software-eket kell kifejlesztenünk az üzemeltetéshez 218
A megbízhatóságot veszélyeztető hibák A lehetséges hibák típusai: Tervezési hibák Konstrukciós hibák Működési hibák A hardware elemeknél mindhárom hiba felléphet: Az alkatrész elhasználódik – időszakos majd teljes meghibásodás Feszültség kiesés Azokat a rendszereket, amelyek az így fellépő hibák ellenére is biztonságosan működnek, hibatűrő rendszereknek nevezzük.
219
109
A software nem használódik el, de a tervezési és a konstrukciós hibák sokkal valószínűbbek. (pl.: egy program nem fogad el bizonyos input adatokat vagy nem ismer fel érvénytelen inputot. Legfontosabb feladat: egy hiba nem befolyásolhat más folyamatokat. (a hiba korlátozása) Ha a hiba fellépett, célszerű arra koncentrálni erőinket, hogy hogyan tudunk a leggyorsabban megszabadulni tőle. Egyes kutatók szerint (Wulf, 1975) e feladat sokszor fontosabb, mint a megelőzés.
220
Siewiorek (1984) tíz olyan fontos lépést definiált, amelyet el kell végezni egy hiba során: Korlátozás Érzékelés Kiszűrés Ismétlés Diagnózis Átkonfigurálás Visszaállítás Újraindítás Javítás Beillesztés 221
110
Hardware-megoldások a hibák megelőzésére: Memóriavédelem: egy folyamat csak használhassa, amelyekre engedélye van.
azokat
a
címeket
Timerek segítségével megszakíthatjuk azokat a folyamatokat, amelyek túllépték a számukra engedélyezett időkorlátokat. Adattorzulások kiszűrése: paritás bit, ellenőrző összeg. Szünetmentes tápegység (UPS) Hardware redundancia olyan rendszerek esetében, amelyek különösen megkövetelik a biztonságos működést. Software-megoldások a hibák megelőzésére : Defenzív programozás: egy programnak mindig ellenőriznie kell a fogadott adatokat, sohasem szabad megbízni azok helyességében. 222
13.3 Védelem Belső védelem: az OR részére Csak jogosult személy legyen képes belépni a rendszerbe. (azonosítás!) Több felhasználó által használt adatokat csak ellenőrzött módon lehessen elérni. (állományok teljes elkülönítése, olvasási-, írási- és végrehajtási engedélyezettség.) Kommunikációs adatvédelem (hálózatoknál) Külső védelem Fizikai védelem – külső hatások ellen Műveletekre vonatkozó védelem – teljes adatmentés Jogi védelem 224
111
14. Rendszerkezelés, rendszerkönyvelés Ez magába foglalja: az OR generálását egy rendelkezésre álló hardware konfigurációra, az OR betölthető formában történő installálását egy tetszőleges adathordozón, az OR betöltését egy tetszőleges típusú adathordozóról az elsődleges tárterületre, az OR leállítását (shut down), az OR „tuningolását” egy adott környezethez a nagyobb hatékonyság elérésének érdekében, az OR erőforrásai felhasználásának feldolgozását, adminisztrálását. 225
14.1 Rendszergenerálás Az OR egyik fontos feladat az, hogy támogassa a rendszer előállítást. Ennek során az adott OR egy olyan változatát készítjük el, amely a rendelkezésre álló hardware lehetőségeit a legjobban kihasználja. A rendszer előállítása mindig attól függ, hogy az OR-nek mely részei változtathatók. Ilyen például: CPU-k száma, típusa Memória mérete Standard készülékek típusai, logikai nevei, címei, paraméterei Rendszer Kontrol Blokk mérete Felhasználók max. száma Készülékek max. száma Alkalmazni kívánt karakter kód típusa 226
112
14.1.1. A telepítés típusai A. Ha a rendszer forrásnyelven áll rendelkezésre: Szükségünk van egy fordítóprogramra (assembler) Ennek segítségével le kell fordítani a forrásmodulokat A lefordított modulokat szerkeszteni kell Előnye: az így előállított OR pontosan a kívánt paramétereket tartalmazza. Hátránya: az OR generálása nagyon hosszú ideig tarthat.
227
B. Ha az OR-t leíró táblázatok valamilyen formában rendelkezésre állnak, akkor elkerülhetjük a fordítást. Ilyenkor a rendszer-specifikumokat leíró paramétereket táblázatban tároljuk Ezeket egy szerkesztési lépésben kell a már lefordítottan rendelkezésünkre álló többi modulhoz kapcsolni. Előnye: a telepítési idő alaposan lecsökken. Hátránya: romlik a rendszer alkalmazkodó képessége. C. Az előző tovább finomítható azáltal, hogy konfigurálási lehetőséget biztosítunk a telepítéshez.
dinamikus 228
113
14.1.2. A telepítés módszerei Az esetek legnagyobb részében az OR-t úgy szállítják, hogy leválasztanak róla egy betölthető változatot, ami lényegében független a hardvertől. Ha ezt a „szűkített” változatot betöltjük, akkor ennek segítségével felépíthetjük az OR-t. Eltérő módszereket alkalmazunk attól függően, hogy Batch eljárás keretében, vagy Interaktív eljárást használva telepítjük az OR-t.
229
OR telepítés batch eljárással Batch eljárás esetén: Az OR rendelkezik valamilyen kommunikációs lehetőséggel (nyelvvel), amelyet a telepítés során használ. Nincs általános szabály. UNIX esetében az eljárást a jegyzetben megtalálhatjuk.
230
114
OR telepítés interaktív eljárással Interaktív eljárás alkalmazásakor: Az OR egy interaktív nyelvvel rendelkezik, amely megköveteli, hogy a konzol képernyőre kiírt kérdést egyszerű formában megválaszoljuk. A megadott válaszok függvényében az OR egy batch állományt generál. Ez általában menüvezérelt módon történik. Így azok a felhasználók is telepíteni tudják a rendszert, akik nem olyan járatosak az ilyen munkában.
231
14.2 Rendszerbetöltés Hideg start: A kis rendszerek mindig így indulnak. Az OR ilyenkor mindent „elfelejt”, ami az újra betöltés előtt történt. Az inicializáló eljárás mindig ugyanazokat a lépéseket hajtja végre. Meleg start: a rendszer felhasználja azokat az információkat, amelyeket a korábbi állapotokból megőrzött. - A rendszer betöltés következő fontos fázisa: az önkonfiguráció. - Majd: a file-rendszer ellenőrzése. (Rendszerindítási diagnosztika)
232
115
14.3. Rendszerleállítás Abban az esetben, ha egy MS-DOS típusú OR áramkimaradás miatt leáll, akkor a felhasználókat nem éri nagyon nagy veszteség, hiszen csak annak veszik el adata, akinek a programja éppen a memóriában volt. A többfelhasználós rendszereknél a helyzet már sokkal kedvezőtlenebb: maga a file-rendszer is szennyeződhet, ha nem szabályos rendszerleépítést hajtottunk végre. Ezért figyelmeztet számos OR arra, hogy a shutdown parancs kiadása előtt a felhasználó egy logoff parancs segítségével lépjen ki a rendszerből. Szabályos leállás esetén a felhasználónak követni kell a rendszer üzeneteit. Szabálytalan befejezés esetén is a legtöbb rendszer képes arra, hogy adatok ás programok mentésével felkészüljön egy szabályos leállásra, de előfordulhat az is, hogy a hiba elhárítása az operátorra marad. 233
14.4. Rendszertuningolás Az egyfelhasználós rendszereknél hatékonysági problémákkal nem találkozunk. A rendszer kihasználtságát mindig az éppen futó egyetlen programmal kapcsolatos feladatok határozzák meg. Nagy, többfelhasználós rendszereket nagykapacitású számítógépeken futtatunk. Ha az ilyen gépek nincsenek jól kihasználva, akkor az általában az OR hibája. Amikor a rendszer hatékonyságát akarjuk megnövelni, akkor tunningolásról beszélünk.
234
116
Néhány ok, ami lelassíthatja a rendszert:
CPU kihasználtság Átfordulási idő Készülék kihasználtság
Várakozási idő különböző készülékekre
Válasz idő interaktív környezetben
Processz ütemezés Lapozás kezelése
I/O-készülékek kezelése
235
14.5. Rendszerkönyvelés
A többfelhasználós rendszereknek számos elszámolási, könyvelési feladata van. Az elszámolási információk kezelése az OR használatának fontos része. Információkat kell tárolnunk arról, hogy az egyes felhasználók a rendszer erőforrásait milyen mértékben veszik igénybe. (elszámolási információk) Mennyiségi korlátokat kell felállítanunk arra, hogy az egyes erőforrásokat mely felhasználók, meddig vehetik igénybe.
236
117
Korlátozható területek: Felhasználható mágneslemez terület. CPU idő igénybevétel jobonként. I/O-műveletek max. száma. Nyomtatható sorok max. száma. Futtatható jobok max. száma.
237
15. Osztott operációs rendszerek
A számítógépek kapacitásának talán legszűkebb keresztmetszete a központi vezérlő egység. Így kézenfekvő az a gondolat, hogy használjunk több processzort a rendszer hatékonyságának megnövelése érdekében. Kezdetben csak két processzort használtak és – a sok új probléma ellenére – a hatékonyság növekedése olyan mértékű volt, hogy a többprocesszoros rendszerek igen gyorsan terjedni kezdtek. Ma számos olyan többprocesszoros rendszert ismerünk, amelyben CPU-k tucatjai dolgoznak együtt. A processzorok a legkülönbözőbb módon kapcsolhatók össze. 238
118
A processzorok összekapcsolásának egyik módja az, hogy: független egyprocesszoros számítógépes rendszereket kötünk össze. Az összekötött gépeket hálózatnak (network) nevezzük. Attól függően, hogy mekkora a fizikai távolság a gépek között, beszélhetünk: Kis távolságú vagy lokális hálózatról (LAN) (néhány száz m) Nagy távolságú (WAN) hálózatról (akár az egész Földet is behálózhatják) Mind a többprocesszoros rendszereknél, mind a különböző hálózatoknál minden egyes processzor felelős a rendszerben futó egy folyamatért.
239
Ha bizonyos tevékenységek felügyeletét meg kell osztanunk processzorok egy csoportja között, akkor akár az egész rendszert előnyösebb egységes egészként kezelni. Az így létrejött rendszert osztott számítógépes rendszernek nevezzük. (közös feladatok) A források közös kezelésére alkalmas OR-t Osztott Operációs Rendszernek (OOR) nevezzük. Egy OOR telepítésének lehetőségei: Az OOR együttesen kezeli a rendszerben lévő összes processzort. Az OOR-t a „klasszikus” OR-k fölé helyezzük.
240
119
Az osztott számítógépes rendszer előnyei: Humán kommunikációra alkalmas rendszert tudunk kifejleszteni, amelyben az egyes felhasználók kényelmesen tudnak üzeneteket váltani egymással elektronikus levelezési rendszerek (e-mail) segítségével. Erőforrások megosztását tudjuk elérni oly módon, hogy a különböző helyszíneken rendelkezésre álló erőforrásokat át tudjuk csoportosítani egymás között. (fizikai-, logikai EF-k) Növelhetjük a rendszer megbízhatóságát azáltal, hogy a több processzor mellett az egyes hardware elemekből is több áll rendelkezésünkre. (meghibásodás!) Kiegyensúlyozott terhelést érhetünk el azáltal, hogy több CPU áll rendelkezésre, és így egy adott pillanatban azt a processzort tudjuk mindig megterhelni, amelynél a legkisebb a valószínűsége annak, hogy túl lesz terhelve a következő időszakban. 241
15.1. OR-ek többprocesszoros környezetben A többprocesszoros környezetben a számítógépes rendszerhez kettő vagy ennél több CPU tartozik. A rendszerben elhelyezkedő memóriaegységek különböző módon kapcsolódhatnak a processzorokhoz: vagy kizárólagos alapon egy memóriaegységet egy processzorhoz rendeljük hozzá (könnyen kezelhető, de költséges), vagy a memóriaegységet megosztjuk a processzorok között: előfordulhat, hogy a memóriát olyan folyamatok között kell felosztani, amelyek más-más processzorokhoz tartoznak.
242
120
Ezért a többprocesszoros folyamatok speciális kommunikációs lehetőségei az alábbiak: kapcsolattartás az osztott memóriákkal, üzenetek továbbítása, az első kettő kombinációja. Az ilyen rendszerek egyik legnagyobb problémája: az egyenletes terhelés biztosítása az egyes CPU-k számára.
243
15.2 OR-ek hálózatokon Hálózat akkor jön létre, ha két - vagy több – fizikailag különálló számítógépet kommunikációs vonallal összekötünk azzal a céllal, hogy üzeneteket, vagy adatokat továbbítsunk. A hálózatoknak azokat a helyeit, ahol az egyes számítógépek elhelyezkednek, helyszínnek nevezzük. A helyszínen elhelyezkedő számítógép neve host. A hálózati környezetben kétféle módon installálhatunk OR-t: Hálózati kommunikációra alkalmas OR-t telepítünk a már meglévő OR „fölé”. Ezt a rendszert szokásos hálózati OR-nek nevezni. Osztott OR-t installálunk a hálózat minden gépén. Ez az ún. osztott OR. Itt a fő kérdés az, hogy miképpen tudjuk biztosítani a kommunikációs helyszínek között a megbízható és gyors adatátvitelt. (szinte mindig szükséges, hogy a meglévő hardware elemek hatásfokát software elemekkel javítsuk) 244
121
Hálózati topológiák
Sugaras összekötés
Gyűrűs összekötés
Teljes összekötés
245
Az adatkommunikáció hét szintje: (ISO szabvány, 1983, OSI) Minden osztott OR-nek tartalmaznia kell a négy legalsó szintet:
1. FIZIKAI SZINT: az elektronikus és a fizikai összeköttetést alapozza meg ahhoz, hogy az átvitel végrehajtható legyen.
2. ADATÖSSZEKÖTTETÉSI SZINT: az adatok különálló bitjeit szervezi csomagokba. (általában hibakezelővel)
3. HÁLÓZATI SZINT: a csomagok számára biztosítja a célállomáshoz vezető utat.
4. ÁTVITELI SZINT: a kimenő üzeneteket csomagokba szervezi és feldolgozza a bejövő adatokat 246
122
Nem kötelező, inkább a felhasználó kényelmét szolgálják:
5. BEJELENTKEZÉSI SZINT: logikai kapcsolatot biztosít 6. ÁTADÁSI SZINT: az adatok szemantikáját kezeli 7. APPLIKÁCIÓS SZINT: specifikus felhasználói programok esetén gondoskodik a megfelelő hálózati interface-ekről.
247
15.3. Osztott OR-ek szervezése Ha egy hálózati OR rendelkezik a memória osztott felhasználásának lehetőségével, akkor az elsődleges probléma az, hogy hova helyezzük el magát az OR-t. Ennek három fő típusa létezik: KÖZPONTOSÍTOTT: a teljes memóriában helyezkedik el.
OR
egy
helyszínen
egy
OSZTOTT: az OR-t részekre bontjuk és az egyes részeket különböző helyszíneken tároljuk. MÁSOLAGOS: az OR teljes egészét – vagy annak csak egy részét – egy-egy példányban több helyen tároljuk. 248
123
Többprocesszoros környezetben: Kérdés: melyik processzoron kell futni a folyamatnak? Válasz: master-slave rendszer. Kérdés: hol tároljam?” (csak átjárható átjárható rendszereknél) Válasz: egy olyan osztott file-rendszert biztosítsunk a felhasználóknak, amely virtuális, egységes és amelyben az állományok elérhetők anélkül, hogy a felhasználó bármit tudna annak elhelyezéséről. (elhelyezéstől független neveket adni!) Az osztott file-rendszerek másik jellemző tulajdonsága, hogy a hatékonyság érdekében a rendszer esetenként több másolatot tárolhat a file-rendszer egyes részeiből a különböző helyszíneken. 249
A többfelhasználós rendszereknek támogatni kell azt a lehetőséget, hogy mozgatni tudják a folyamatokat a rendszer különböző helyszínei között. Erre a következő okok miatt lehet szükség: Hatékony erőforrás-elérés: Abban az esetben használjuk, amikor nincs lehetőség arra, hogy – a helyhez kötöttség miatt – a folyamathoz közeli erőforrást válasszunk. Ilyenkor a folyamatot mozgatjuk a helyszínek között az erőforrás közelébe. Terhelés kiegyensúlyozás: Ha a hálózatban lévő CPU-k közül néhány túlterhelt, míg mások kevésbé kihasználtak, akkor átirányíthatunk folyamatokat más CPU-hoz. Task-kényszer: Egy folyamat lehet egymással együttműködő folyamatok része. Ilyenkor előfordulhat, hogy a csoport tagjainak egyidőben kell futni. Ez csak úgy érhető el, ha különböző helyszíneken elhelyezkedő CPU-kon futtatjuk ezeket a folyamatokat. 250
124
VÉGE
251
125
