Dr. Galambos Gábor. Operációs rendszerek általános elmélete

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. 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

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)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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 Kommunikációs terület Fizikai tárfelosztás MS-DOS alatt

1536 byte 0 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

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

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

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

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

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

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

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

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

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

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

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

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

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

Á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

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

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

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

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

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

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

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

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

Fizikai Címzési Terület 200

80 20

60

60

60

12

0

40

40 18

40

20

20 20

20

0

0

Leképezési regiszterek

Virtuálismemória-kezelés leképezési regiszterekkel

102

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

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

12

13

Fizikai memória

7

13

18

19

20

17

6

8

15

16

17

14

5

17

4

9

12

13

14

3

8

9

10

11

6

7

8

3

4

5

0

1

2

9

10

11

6

7

8

2

0

3

4

5

1

5

0

1

2

0

19

Lapozási Tábla

Virtuálismemória-kezelés lapokra bontással

106

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

8.2. Néhány fontos jellemző

1. Prioritások

2.

3.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

VÉGE

251