Informatika | Operációs rendszerek » Dr. Galambos Gábor - Operációs rendszerek, 1995

Dr. Galambos Gábor OPERÁCIÓS RENDSZEREK jegyzet Szeged, 1995. Irodalomjegyzék 1. Bobrow, DG et al[1972], TENEX, a Paged Time Sharing System for the PDP10 Communication of ACM, 15[1972], pp 135-143 2. Bölcsföldi ??? Az OS Job Control Nyelve 3. Coffman, E G and Denning, P J [1973], Operating System Theory, Prentice Hall, Englewood Cliffs, NJ, 1973. 4. Dijkstra, EW[1968], The Structure ofthe THE Multiprogamming System Communication of ACM, 11[1968], pp. 341-346 5. Kemény, JG and Kurtz, TE [1968], Darthmouth Time Sharing, Science, 162[1968], pp. 223-228 6. Kernighan, B, Pike, R [1984], The Unix Programming Enviroment, PrenticeHall, Englewood Cliffs, NJ, 1984 7. Kernighan, B, Ritchie, D [1978], The C Programming Language, PrenticeHall, Englewood, NJ, 1978 8. Kildall, G[1981], CP/M: A Family of 8- and 16-bit Operating Systems Byte, 6[1981], pp. 216-232 9. Lane, M G and Mooney, J D [1989], A Practical Approach to Operating Systems, PWS-KENT Publishing Company, Boston, 1989. 10.

Leffler, SJ and Joy, WM [1983], Installing and Operating 42BSD on the VAX, Department of Engeneering and Computer Science, University of California at Berkeley, 1983. 11. Liu [1988] Parallel Sorting and Matching????? 12. Millstein,R E [1977], The National Software Works: A Distributed Processing System. ACM, 1977, pp 42-52 13. Organick, EI [1972], The Multics System: An Examination of its Structure M.IT Press, Cambridge, Communication of ACM, 23[1980] pp 240-246 14. Parmelee, R P et al [1972], Virtual Storage and Virtual Machine Concepts, IBM System Journal, 11[1972], pp. 99-130 15. Patterson, T [1983], An Inside Look at MS-DOS Byte, 8[1983], pp 230-252 16. Ritchie, DM , Thompson, K [1974], The Unix Timesharing System Communication of ACM, 17[1974], pp. 365 17. Siewiorek, D P [1984], Architecture of Fault-Tolerant Computers, COMPUTER, 17(1984) pp. 9-18 18. Tannenbaum, A S , van Renesse, R [1985], Distributed Operating Systems ACM Computer Surveys, 17(1985), 419-470. 19. Tannenbaum, A

S [1987], Operating Systems: Design and Implementation Prentice Hall, Englewood Cliffs, NJ. 1987 20. Wulf, W [1975], Overview of the Hydra Orerating System Development SOSP5, 1975 pp 122-131 Elõszó Az operációs rendszerekrõl nagyon sok irodalom olvasható. Ez azért van, mert a számítógépek fejlõdésének különbözõ szakaszaiban szinte minden géptípushoz egyedi operációs rendszert készítettek, és a hardware fejlõdése mindig megkövetelte új elvek alkalmazását az ”vas” üzemeletéséhez használt alapsoftwarek készítésénél. Annak ellenére, hogy a magyar nyelvû irodalom is bõséges, nehezen tudtam találni egy olyan könyvet, amely alkalmas arra, hogy a fõiskolai oktatás követelményeinek megfelelõ terjedelemben tárgyalva megismertesse a hallgatókat az operációs rendszerek fejlõdésének történetével, felépítésük általános elveivel, kötelezõen elõírt feladataikkal. Ebben a jegyzetben ezt a feladatot igyekszem megoldani. Az

általam legfontosabbnak ítélt anyagot válogattam csak össze. Kimaradtak olyan nem elhanyagolható részek, mint a real-time rendszerek, amelyeknek részletes tárgyalására azért nem vállalkoztam, mert kevés esélyt látok arra, hogy a közeljövõben az ilyen operációs rendszereket általános vagy középfokú iskolákban széles körben oktatni kell. Ugyanakkor ki kell majd térnünk számos olyan problémára, amelyek nem tartoznak szorosan az OR-hez, de ismeretük segít megérteni az OR-k tervezését, felépítését, használatát. Így például hivatkozni fogok a számítógépek eltérô architektúrájára, amely alapvetô befolyással bír az OR-k kialakítására, hiszen azok egyik legfôbb feladata az, hogy áthidalják a hézagot a hardware és az alkalmazói software között. Szó esik olyan hardware részrendszerekrôl, amelyek kifejezetten azért születtek, hogy az OR-ket támogassák (pl. lapozási technika, szegmentálás, cache) A jegyzetet

elsõsorban tanárszakos hallgatóknak írtam azzal az igénnyel, hogy átfogó képet kapjanak az alapsoftware legfontosabb tulajdonságairól, megismerjék alkotó részeiket, feladatatikat. A célom az volt, hogy megmutassam azokat az általános elveket, amelyeken minden operációs rendszer alapul. A jegyzet tehát nem egy rendszer bemutatása, hanem általános elveké, amelyeket minden operációs rendszernek teljesíteni kell. Ahol lehetett, ott konkrét példákra hívatkoztam. Ezek a hívatkozások ott részletesebbek egy 1 kicsit, ahol az MS-DOS-ra vagy a UNIX-ra utalok, mert ezek azok a rendszerek, amelyek ma a legszélesebb körben elterjedtek. Mindemellett vitán felüli az a tény, hogy az OR-k tanulmányozása alapvetô fontosságú minden számítástudománnyal foglalkozó hallgató számára. Fontos ugyanis megtanulni azt, hogyan kommunikálhatunk a számítógéppel éles helyzetekben: állományok gyors feldolgozása, input-, output eszközök hatékony

kezelése, szolgáltatások megfontolt igénybe vétele csak az OR feladatainak megismerésével, a megoldásukhoz vezetõ algoritmusok megértésével lehetséges. Bizom benne, hogy a jegyzet hasznos lehet azok számára is, akik nem oktatni akarják ezt a tárgyat, hanem egyszerûen csak érdeklõdnek az OR-k iránt. A jegyzetben feltételeztem, hogy az olvasó ismeri a számítógépek felépítését, tisztában van az egyes hardware elemek mûködésével, ismeri a logikai kapcsolatokat a számítógépek különbözô egységei között, és hallott az adatátvitel eltérô módjairól is. Úgy gondolom, hogy a jegyzet két féléves oktatáshoz elegendõ anyagot tartalmaz. Fontos azonban megjegyezni, hogy könyvbõl számítástechnikát tanulni nem lehet. Ezért egyrészt elengedhetetlenül szükséges az, hogy az elõadás anyagát kiegészítsük megfelelõ gyakorlatokkal. Egy lehetséges út az, ha két féléven keresztül (heti 2 órában) valamilyen konkrét operációs

rendszert ismernek meg a hallgatók. A JGYTF-n mi az MS-DOS és a UNIX rendszereket választottuk. A megfelelõ tapasztalat, és a biztonság megszerzéséhez másrészt ugyancsak nagyon fontos az, hogy az érdeklõdõ hallgató töltsön minél több idõt konkrét operációs rendszerek tanulmányozásával azért, hogy lássa, miként lehet az általános elveket konkrét formába önteni. Mindezek mellett kifejezeten elõnyös, ha az olvasó legalább alapszinten ismeri az angol nyelvet. A tárgyalás során igyekszünk a magyar megnevezéseket használni, de a szövegben sokszor használom zárójelben a megfelelõ angol kifejezést, esetleg még a rövidítést is. Ez azért van, mert a számítástechnikában rendkívüli mértékben elterjedtek az angol szakkifejezések, és úgy gondoltam, hogy a további könyvek olvasását esetleg megkönnyítheti ezek ismerete. Ahol lehetett és ismertem is ott használtam a magyar megfelelõket, kerestem a magyar kifejezéseket, de

néhány esetben jobbnak láttam, ha az angol eredetetit használom (pl. job, session) Szeged, 1995 március 13. 2 1. Bevezetés Ma már szinte közhelynek számít az a megállapítás, hogy a számítógépek robbanásszerûen terjednek. Napjainkban alig lehet megnevezni az életnek olyan területét, ahol a számítógépeket nem alaklmazzák. Mivel a felhasználók legnagyobb része nem ír programokat, hanem csak eszköznek tekinti a gépet, többnyire nem is foglalkozik az általa használt rendszer müködtetését ellátó, kiemelkedô fontosságú alkotóelemmel az operációs rendszerrel (OR). Pedig ezek nélkül a számítógépek hatékonysága rendkívül alacsony lenne. Azt mondhatjuk, hogy ez a fajta ellenôrzô software alapvetô szerepet játszik abban, hogy a különbözô hardware elemeket egységes egésszé kovácsoljuk. Az OR nélküli számítógépet egy vezetô nélküli buszhoz lehet hasonlítani: egy ilyen busz még közlekedik annak ellenére, hogy

mindazok az utasok, akik használni akarják a buszt számos nehézséggel találják szembe magukat. Az emberek eltérõ tulajdonságai miatt állandó veszekedés lesz a buszon arról, hogy mikor fékezzenek, milyen sebességgel haladjanak, és milyen menetirányt válasszanak az egyéni célok eléréséhez. Ilyen helyzetben hibák könnyen keletkeznek és súlyos következménnyel járhatnak: az utasoknak állandóan harcban kell állni egymással azért, hogy ki vezesse a buszt, és az hol álljon meg. Könnyen lehet, hogy a busz útvonalát nem egy átfogó vizsgálat alapján meghatározott, mindenki számára elfogadott kompromisszumokat is tartalmazó döntés alapján határozzák meg az utasok, hanem a nyers erõ dönti el a menetirányt Ha azonban van egy vezetô a buszon, akkor bizonyos dolgok egy része már eleve ellenôrzés alá kerül. Bár az utasoknak lehetnek kívánságaik, de nem szükséges nekik gondoskodni a sebességváltásról, a fékezésrôl vagy a

kormányzásáról. Ezeket a feladatokat mind átveszi a vezetô, és így az utazás lényegesen kényelmesebb. Annak ellenére, hogy az utasok nem vezethetik a buszt közvetlenül a céljukhoz, a busz kijelölt útvonalát használva mégis oda fognak érni, és általában nem fognak panaszkodni. (Hacsak nem késik a busz) A számítógép esetében a helyzet szinte teljesen azonos: egyidejûleg több program fut a gépen. (Mint azt késõbb tapasztalni fogjuk, ez akkor is igaz, ha mi ezt nem mindig így látjuk.) Az OR nélkül mindenkinek önmagának kell 3 gondoskodni olyan programokról, amelyek kezelik az erôforrásokat. Egy ilyen helyzetben nagyon nehéz az erôforrások hatékony kiosztása. Azonban, ha egy számítógépes rendszeren van OR, akkor az erôforrások ellenôrizhetôk, és sokkal hatékonyabban felhasználhatók. Néhány esetben persze a felhasználók elégedetlenkedni fognak, egészében véve azonban mindenki munkája gyorsabban fejezôdik be, és

sokkal nyugodtabb lesz. Különbözô számítógépeken napjainkban az OR-k százai üzemelnek. Könnyen megjósolható, hogy ezek közül csak a legjobbak fogják túlélni ezt a "burjánzást". Annak ellenére, hogy az OR-k számos olyan komponenst tartalmaznak, amelyeknek nemcsak a mûködési elve azonos, hanem a megjelenési formája is, az univerzális OR éppoly elérhetetlennek tûnik, mint az univerzális programnyelv. 1.1 Az operációs rendszer határai Mielôtt áttekintenénk azokat a fô feladatokat, amelyeket egy OR-nek el kell látni, mindenekelôtt tisztázni kell azt, hogy mit értünk OR alatt. Azt tudjuk, hogy azok az alapvetô hardware elemek, amelyek az információk tárolására és feldolgozására szolgálnak, minden számítógépben a rendelkezésünkre állnak. A probléma az, hogy ezek az elemek olyan egyszerû formában nyújtják az információkat, hogy azok közvetlen felhasználása nagyon nehéz. Ezért a számítógépek fizikai

komponenseit (hardware) mindig ellátják olyan programokkal, adatokkal (software), amelyek ezen információk elérését megkönnyítik. Ezt a két alkotóelemet együtt számítógépes r endszernek nevezzük. Egy számítógépes rendszer egy komponensét - tartozzon az akár a softwarehez akár a hardwarehez - erôforrásnak nevezzük, ha azt a felhasználó vagy az általa készített programok valamelyike használja. Az erôforrások két nagy csoportba sorolhatók: fizikai erôforrások (vagy másnéven hardware eszközök) és logikai erôforrások (ezek a software eszközök). Fontosabb fizikai erôforrások: • Központi vezérlô egység (CPU = Central Process Unit), • Operatív memória, • Háttér tárolók (lemezek, szalagok), • Belsô kiszolgáló eszközök (pl. belsô óra, különbözô idôzítôk) 4 A logikai erôforrások az információk olyan gyûjteményét szolgáltatják, mint az adatok és a programok. Logikai erôforrásokat mindig fizikai

erôforrásokon tárolunk. Néhány példa ezekre az elemekre: • Végrehajtás alatt levô programok (processek). • Állományok (file-k, file rendszerek). • Közösen használt programok és adatok. • Eljárások, amelyek hasznos szolgáltatásokat nyújtanak. A számítógépes rendszer software része speciális programok egy gyüjteményét is tartalmazza az un. rendszerprogramokat, amelyek abban különböznek a felhasználói programoktól, hogy olyan eljárásokat hajtanak végre, amelyekre a rendszer minden felhasználójának szüksége lehet. A rendszerprogramok egy része jól ismert a programozók között. Ezek a fordítók (compilerek, interpreterek), amelyek lehetôvé teszik azt, hogy magas szintû nyelveken (Pascal, C, stb.) írjunk programokat Más rendszerprogramok a számítógépes rendszer teljes ellenôrzéséért felelôsek, beleértve a felhasználókkal történô kommunikációt, azok programjainak végrehajtását. Ismét mások felelôsek az

esetlegesen fellépô hibák felism eréséért, azok kijavításáért valamint a teljes számítógépes rendszer biztonságos mûködéséért. Elsõ közelítésben azt mondhatjuk, hogy a fenti feladatokat ellátó programokat együttesen nevezzük OR-nek. Ha azonban mélyebben vizsgálni kezdünk egy OR-t, akkor az elsô felmerülô kérdés az, hogy a rendszerben található softwareek között melyeket tekintsük az OR részének? A . B . Egy lehetséges szemlélet szerint az OR-hez tartozónak tekintjük a teljes számítási környezetet. Így az editorok, compilerek, interpreterek és minden egyéb software segédeszköz is az OR része. Ez a szemlélet azért terjedt el, mert számos OR esetén nagy mennyiségû rendszersoftwaret szállítanak a géppel egyidejûleg. Ezek a softwarek gyakran egységes tárgyalást igényelnek, nemcsak azért, mert azokat együtt alkalmazzuk, hanem azért is mert ezeknek jól kell együttmûködni egymással az adott OR környezetben. (Egy

UNIX környezetben kiválóan használható fordító nagyon rossz hatásfokkal mûködni egy Apple Macintosh ORén.) A másik szélsôséges szemlélet az, hogy az OR-hez a különbözô szervezési eljárásoknak csak erôsen korlátozott részét soroljuk: azokat, amelyek mindvégig a memóriában maradnak és rendelkeznek mindazokkal az elôjogokkal, amelyeket a hardware révén szolgáltatni tudunk. ( Ezeket az eljárásokat gyakran nevezik az OR kernel-jének.) 5 A mi szemléletünk szerint az OR ez utóbbihoz áll közelebb, de nem fedi teljesen azt. E szerint az OR-t úgy kell elképzelni, mint egy olyan felületet, amely a hardware környezet és a felhasználói környezet között helyezkedik el. A hardware környezet irányában az OR egy hardware in terface-t szolgáltat, míg a felhasználói környezethez a felhasználói interface-szel csatlakozik. Szemléletünk szerint az OR elvégez minden olyan feladatot, amely a fenti két környezettel történô

kapcsolattartást elôsegíti. Így az OR a felhasználóval való kapcsolattartáson túl elôsegíti a számítógép kapacitásainak jobb kihasználását azáltal, hogy szervezi a fizikai erôforrásokat. Ezt a szervezést úgy kell megvalósítani, hogy egyidejûleg rendelkezzen a szükséges ellenôrzéssel és kényelemmel, de a lehetô legrugalmasabb maradjon. A szerepe az, hogy a hatékony szervezést megvalósító mechanikus munkát összhangba hozza annak a számítógépes rendszernek a politikájával, amelyre ôt implementálni akarjuk. Ebben az értelemben tehát az OR csak része a kernelnek, de számos olyan erôforrás szervezô programmal rendelkezik, amely vagy csak akkor töltôdik be a memóriába, ha éppen végrehajtás alatt van, vagy lényegesen kevesebb elôjoggal rendelkezik, mint a kernel. A könnyen áttekinthetô ellenôrzési és szervezési feladatok mellett az OR feladatai közé fogjuk sorolni a file rendszerek kezelését is, sõt magát a file

rendszert is az OR részének tekintjük. A file rendszerek nem fizikai erôforrások. Fontos kategóriát alkotnak a többszörös hozzáférésû logikai erôforrások között. A modern OR-k - különösen azok, amelyek hálózatokban összekapcsolt számítógépeket üzemeltetnek - a file rendszert független komponensként kezelik (pl. UNIX) A mi szemléletünk szerint a file-k olyan fontos rendszer erôforrások, amelyekre a legtöbb számítógépes felhasználónak szüksége van, és így ezt együtt kell tárgyalni az OR-rel. Miként azt már említettük a számítógépes rendszer két részbôl áll: a hardwarebôl és a softwarebôl. Legegyszerûbb megközelítésként azt mondhatjuk, hogy a "vas" a hardware és az operációs rendszer a software. Ha azonban pontosabban akarjuk megfogalmazni ezt a két fogalmat, akkor nagyon nehéz meghúzni a határvonalat a két terület között. Arról van szó, hogy az egyszerû számítógépeknél olyan funkciók is

software úton vannak megoldva, amelyeket a hardwaretôl várunk el. (pl: a szorzás alapmûvelete nem "zsinórozott", hanem program valósítja meg). Másrészrôl a hardware egyre csökkenô ára a software növekvô elôállítási költségével szemben olyan tendenciákat eredményezett, hogy számos software funkciót valósítanak meg hardware úton (pl. memória kiosztás, közvetlen mûvelet adatstruktúrákon) Felmerülhet az a kérdés, hogy hol helyezkedik el (logikailag) az OR egy számítógépes rendszeren belül? Az OR-k interface-ként szolgálnak a felhasználók és a számítógépes rendszer között. A legtöbb felhasználó az OR segítségével vagy annak 6 ellenôrzésein keresztül érintkezik a számítógéppel. Így kézenfekvô úgy gondolni az OR-re, mint a hardware egyfajta kiterjesztésére. Ilyenkor úgy kell elképzelni az OR-t mint egy olyan felületet, amely a számítógép tetején van, és elválasztja a számítógépet a

felhasználótól. Felhasználói környezet Operációs rendszer Számítógépes rendszer 1.1 Ábra Az OR helye a számítógépes rendszerben A legtöbb felhasználó nem tudja - és talán nem is akarja megkülönböztetni az OR-t a hardwaretôl: ha a számítógép nem megy, akkor a felhasználó csak a tényt észleli és nagyon ritkán igyekszik megtudni azt, hogy a hiba software vagy hardware eredetû. A másik ok arra, hogy az OR-t a hardware egy kiterjesztésének tekintjük abban rejlik, hogy az OR egy része ténylegesen hardware elemeken van implementálva, vagy egy ROM-ban van elhelyezve. (Gondoljunk a személyi számítógépek BIOS részrendszerére) 1.2 Az operációs rendszerek feladatai Az OR elsôdleges feladata szervezni az erôforrásokat. Az erôforrások szervezése alapvetôen két fô céllal történik: az elsô cél az, hogy támogassuk a kényelmes h asználatot. A kezdeti idôkben minden felhasználó önmaga írta meg azokat a programokat, amelyek

képesek voltak kezelni az I/O készülékeket és egyéb közösen használt erôforrásokat. Ma a felhasználók legnagyobb többsége nem programozó. Õk úgy tekintik a számítógépet, mint egy olyan eszközt, amely a saját értékes idejük egy részét megtakarítja és így méltán várnak el kényelmes használatot. Mivel nem akarnak gondoskodni semmilyen részletrôl, ezért a mai OR-k által nyújtott szolgáltatásoknak könnyen kezelhetônek kell lenni. Emellett persze a hatékonyság és az alakíthatóság is természetes felhasználói igény. 7 Az erôforrások szervezésének másik fô célja az, hogy támogassa és elôsegítse az ellenôrzött kiosztást. Abban az esetben, ha egy számítógépet több felhasználó vesz igénybe egyidejûleg, akkor azok programjai a legkülönbözôbb módokon érintkezhetnek egymással. Egy általános célú számítógépen bármilyen program futhat. Ezek a programok tartalmazhatnak hibákat, vagy nem megengedett

dolgokat akarnak végrehajtani. Ha megengednénk egy programnak, hogy közvetlenül kezelje a közös erôforrásokat az OR felügyelete nélkül, akkor átírhatna más programokat, leblokkolhatna erôforrásokat. Az erôforrások ellenôrzött kiosztása nagyon összetett feladat. Amellett, hogy ténylegesen ellenôrzöttnek kell lennie, a kiosztástól elvárjuk, hogy hatékony és igazságos legyen. Ez azt jelenti, hogy egy erôforrás csak ritkán várakozhat akkor, ha valamelyik programnak igénye van rá. Másrészrôl ha egy erôforrásra egyidejûleg több program vár, akkor ezek valamelyikét igazságosan kell kiválasztani következôként. Azért, hogy az OR ki tudja elégíteni ezeket az elvárásokat, számos kiegészítõ feladatot kell megoldania. Ezek közül néhány egyszerû szervezési feladat, mások szolgáltatások ill. hibakezelések vagy biztonsági ellenôrzések Itt most csak felsoroljuk - és röviden ismertetjük - ezeket a feladatokat. A jegyzet

késôbbi részében részletesen kitérünk ezek tárgyalására. 1.21 A felhasználói interface Egy OR-nek alkalmasnak kell lenni arra, hogy kommunikálni tudjon a felhasználókkal és azok programjaival. Ezt a feladatot végzi el a felhasználói interface, amely alapvetôen két részbôl áll: - parancs interface, amely biztosítja a felhasználónak, hogy parancsokat adjon közvetlenül a számítógépnek. Az OR-nek ez a része alapozza meg a "felhasználó barátságot". Ha a parancsok könnyen használhatók, akkor azt eredményezik, hogy a felhasználó gyorsabban fogadja el a számítógépes rendszerét, míg a nehezen értelmezhetô, bonyolultan paraméterezett parancsok gyakran arra kényszerítik a felhasználót, hogy átmenjen egy másik - jobb parancs-interface-szel rendelkezô - gépre. - program interface , amely biztosítja azokat a szolgáltatásokat, amelyekre az éppen futó programoknak szükségük van. (Gondoljunk az eljárások hívására,

input-, output mûveletekre, file hozzáférésekre és a program megállítására vonatkozó parancsokra). 1.22 Programok szervezése 8 A jegyzetben a program fogalmát két - egymásnak nem ellentmondó, de mégsem azonos - jelentésben használjuk: programokról beszélünk akkor, amikor egy felhasználó által megírt eljárásról beszélünk, és programnak nevezzük az éppen végrehajtás alatt lévô eljárást is (ez utóbbit gyakran folyamatként (process) fogjuk említeni). Reméljük, hogy a szövegkörnyezetbôl mindig világos lesz, melyik értelmezést használjuk. A (futó) programok szervezése az OR egyik legfontosabb feladata. Ha az OR részére csak egy CPU áll rendelkezésre, akkor két lehetôség közül választhat: vagy egy program fut egy adott idôben a memóriában a befejezésig, vagy ha több program futásáról kell gondoskodni, akkor ezek sorban kapnak lehetôséget egy-egy rövid idôre a CPU használatára. Azokat a programokat, amelyek ilyen

módon osztoznak a memórián konkurens programoknak nevezzük, és azokat az OR-ket, amelyek konkurens programokat futtathatnak többprogramos (multiprogramming) rendszereknek nevezzük. Ahhoz, hogy érzékeltessük ennek a feladatnak a bonyolultságát elegendô a következôt megemlíteni: A konkurens programok interakcióba léphetnek egymással, amely abban nyilvánul meg, hogy ugyanazt az erôforrást igénylik egyidejûleg (ezáltal akadályozhatják egymás munkáját) vagy információt akarnak cserélni egymással.( Ez az információcsere persze nem mindig korlátozható két futó programra!) 1.23 Készülék kezelés A számítógépek az I/O készülékek széles választékával rendelkeznek. Nyomtatók, terminálok, plotterek, mágneslemezek, mágnesszalagok és egyéb kommunikációs készülékek találhatók az ilyen rendszerekben. Ezeket a készülékeket a legkülönbözôbb parancsokkal lehet vezérelni, ellenôrizni. Nem várható el egy felhasználótól, hogy

olyan softwareket írjon, amely ezeket a készülékeket közvetlenül kezeli. Ha ehhez hozzávesszük azt, hogy a többprogramos rendszereknél ezen készülékek kiosztása, felhasználása hatványozottan bonyolultabbá válik, megértjük, hogy miért fontos a készülékek kezelését, ellenôrzését egy jól szervezett rendszerre (ti. az OR-re) bízni A készülékek kezeléséhez szorosan hozzátartoznak a megszakítások. Sok esetben ugyanis az adatátvitel a készülékek között akkor is folytatódik, ha a CPU mással van elfoglalva. Ha egy I/O egység készen áll adatok továbbítására vagy fogadására, akkor egy megszakítás jellel ezt közli az OR-rel. Ha van az adatmozgatásra igény, akkor az OR felfüggeszti az éppen futó programot, és beindítja az adattranszfert. Az adatátvitel befejezését a készülék egy megszakítás jellel közli az OR-rel, ezzel hozva a tudomására, hogy azt a munkát, amelyet az adatátvitel miatt felfüggesztett, tovább lehet

folytatni. 9 1.24 Memória kezelés A központi tár egy számítógép legkritikusabb erôforrása. Mivel a másodlagos tárolókészülékek (ti. lemezek, szalagok) egyik legfôbb feladata az, hogy a központi tárban rendelkezésre álló területet kiterjesszék, ezért a memóriakezelés fogalmába ezen készülékek vizsgálatát is beleértjük. Egy OR hatékonysága nagymértékben függ a memórikezelés hatékonyságától. A korai OR-k esetében a memória kezelés viszonylag egyszerû volt: Az OR elfoglalta a memória egy részét, és az éppen futó program rendelkezett a memória megmaradt részével. Ilyenkor az OR egyetlen feladata az volt, hogy védje a saját maga által elfoglalt területet a beírás ellen. A többprogramos rendszerek megjelenése alaposan megnehezítette a memória kezelést. Ezeknél a rendszereknél ugyanis a memória egyidejûleg több program között kerül felosztásra és ezek védelme egymás ellen már sokkal összetettebb feladat.

Az új stratégiák már azon alapulnak, hogy a programok, azok egyes részei vagy a programokhoz tartozó adatok közül csak azok vannak a memóriában, amelyekre szükség van a folyamatos munkánál, és azonnal kikerülnek, ha nem használjuk ôket. Ez az un cserélés (swapping) Ennek a technikának egyfajta továbbfejlesztése a virtuális memóriakezelés: ekkor hardware és software technikák együttes alkalmazásával érjük el a hatékony memória kezelést. 1.25 Állomány kezelés Egy számítógépes rendszeren az információk tárolását többnyire állományokba (file-okba) szervezéssel oldjuk meg. Az állományok kezelésén értjük azok olvasását, írását, szervezését és a tárolt információk elérésének ellenôrzését is. Az információ védelme szintén ide tartozik Itt jegyezzük meg, hogy az információk titkosságának megõrzése sok OR egyik leggyengébb pontja. 1.26 Elem és csomag kezelés (Job and Session Management) Néha elôfordul,

hogy egy feladat teljeskörû végrehajtásához programok sorozatát kell végrehajtani. A sorozat egy tagját elemnek (jobnak) nevezzük Az elemek összekapcsolt sorozata a csomag (session). Néha kívánatos, hogy az elemeket ill. a csoportokat egy komplett egységként kezeljük Ilyen lehet az a helyzet, amikor az OR-nek azt kell eldönteni, hogy az új elem (v. csomag) futása megkezdôdött, és az innen felhasznált idôt vagy egy igénybe vett erôforrást a kiválasztott felhasználóhoz kell rendelni, hogy egy késôbbi elszámolást végre tudjunk hajtani. 10 1.27 Hiba kezelés Az OR-nek kell foglalkozni minden olyan hibával, amely a számítógépes rendszerben elôfordulhat. A hibák lehetnek hardware hibák (készülékekben, memóriában, átviteli vonalakban) és software hibák (rendszerprogramokban vagy felhasználói programokban). A hiba kezelésének az a feladata, hogy érzékelje és felfedje ezeket a hibákat. A hatékony hibakezelésnek és

elhárításnak olyannak kell lenni, hogy a lehetô legkevésbé szabad befolyásolni a teljes rendszer mûködését. Ez azt eredményezi, hogy nagyon sok esetben a hiba kezelése szinte láthatatlan marad a felhasználó elôtt. Néhány esetben azonban a hibát tudatni kell a felhasználói programmal, hogy a megfelelô közbeavatkozást meg tudja tenni. 1.28 Megbízhatóság és védelem Az OR kiemelt feladatai közé tartozik az, hogy biztosítsa a számítógépes rendszer korrekt mûködését, továbbá az, hogy védje mind az adatokat mind a programokat a sérüléstôl és az illetéktelen hozzáféréstôl. A feladatot csak nehezíti. hogy akkor is teljesíteni kell, ha bármilyen hiba lépett fel a rendszer mûködésében. A rendszer megbízható mûködésének fontossága kézenfekvô, az információ védelmérôl már korábban beszéltünk. A védelem kérdése többprogramos rendszereknél azonban nehéz feladat: ekkor ugyanis az éppen futó programokat nem csak az

OR-tôl kell védeni (és viszont), hanem egymástól is. Ugyanakkor arra is ügyelnünk kell, hogy az OR egyes részei ne okozzanak kárt más komponensekben vagy azok adataiban. 1.29 Felügyelet és elszámolás A legjobban felkészített OR-k rendelkeznek egy olyan lehetôséggel, amelynek segítségével a felhasználók által igénybe vett erôforrások felhasználása mérhetô. Erre azért van szükség, mert a rendszer egyes részei olyan költségekkel rendelkezhetnek, amelyeket a felhasználókra kívánunk terhelni. Egy ilyen rendszerkomponens segítségével elszámolást tudunk készíteni. A felügyelet egy másik fontos célja az, hogy a rendszer vagy egyes készülékek mûködésének hatékonyságát mérjük. A hatékonyság rendszeres elemzésével beavatkozhatunk az egyes erôforrások felhasználásába, ezáltal befolyásolva a teljes rendszer kihasználtságát. 11 2. Az Operációs rendszerek története Ebben a fejezetben - a teljesség igénye

nélkül - áttekintjük az OR-k fejlôdését. Az áttekintés középpontjába azt a kölcsönhatást állítjuk, amely a számítógépek (ti. a hardware) fejlôdése és azok hatékony üzemeltetésére kidolgozott OR-k között fennáll. Így jól megfigyelhetô lesz az a spirál, amely mentén a fejlôdés történt. Vizsgálatainkban három fô irányzatot különböztetünk meg. Végig követjük azt a folyamatot, amely a nagy teljesítményû un. mainframe számítógépekre készített OR-k fejlôdésében mutatkozott, külön foglalkozunk a minicomputerek OR-eivel, és a mikroprocesszoros számítógépekre készített OR-kel is. A fejlôdési folyamatot követve látni fogjuk, hogyan váltak az OR-k mind bonyolultabbá, hogyan voltak képesek kielégíteni az egyre növekvô elvárásokat. Megfigyelhetjük, hogy miként gyorsult fel a fejlôdés, és összehasonlítást tehetünk a mai legmodernebbnek ítélt, nagyteljesítményû gépekre készült OR-k teljesítménye

között. 2.1 Élet operációs rendszer nélkül Sok fiatal számítástechnikai szakember el sem tudja képzelni, hogy hogyan dolgoztak a korai számítógépek OR nélkül. Mások - akikre a fentebb említett "fiatal" jelzô már nem használható többé (köztük a jegyzet szerzôje is) - jól emlékeznek azokra az idôkre, amikor órákat töltöttek azzal, hogy bináris formában kódolt utasításokat vezérlôpulton át juttattak a központi memóriába, a számítógép elôlapján állított kapcsolókkal szabályozták a program futását, és villámgyorsan voltak képesek dekódolni a nyolccsatornás lyukszalagon outputra juttatott információkat. Ebben a számítógépes környezetben elôször egy induló címet adtunk be az adatoknak, majd egy sor kapcsoló beállítása után egy gomb lenyomásával bejuttattuk az adatokat a gépbe. Ezt a mûveletsort ismételtük aztán mindaddig, amíg az összes programlépést és az adatokat is a számítógép

memóriájába juttattuk. Az adatok kiolvasása is hasonló módon történt, csak most felvillanó lámpák jelezték a megfelelô bit 0/1 értékét. Ha a program futásában hibát észleltünk, akkor egy-egy új utasítás beillesztéséhez a mûveletek tucatjait kellett végrehajtani. 12 Az ilyen programrögzítéshez és hibakereséshez arra volt szükség, hogy a gépen dolgozó programozó teljesen az ellenõrzése alatt tarthassa a gépet. A számítógépes igények beosztása is ennek megfelelôen történt: a programozó igényelte a gépet egy idôszakra, és azt egyedül használta ezen idô alatt. (Ezt nevezik open shop rendszernek.) Bármennyi idôt is töltött gondolkodással nem tudva azt, hogy mit kell tennie, senki más nem használhatta a gépet a közbeesô idôben. A helyzeten elôször az segített, amikor egyszerû I/O készüléket csatlakoztathattunk a géphez. Írógépek és lyukszalagos készülékek könnyítették meg az adat-és programbevitelt. A

lyukkártyás I/O rendszer pedig már "forradalmasította" a hibakeresést is. Közben a programozás is fejlôdött: az assembly szintû programnyelvekkel már olvasható formában írhattuk a programjainkat. Szükség volt egy fordító programra, amely az assembly nyelven megírt programokat lefordította gépi kódú utasítások sorozatára. Ahogy nôtt a felhasználók és a alkalmazások köre, úgy szaporodtak a közös célú szubrutinok, amelyeket minden felhasználó szabadon beleszerkeszthetett a programjaiba. Ezen szerkesztô lépés automatizálását lehetett késõbb elvégezni egy szerkesztô (linker) programmal. Az assembler fordítókkal és a szerkesztôkkel megszülettek az elsô rendszer programok. A következôkben az egy assembler program futásához szükséges lépéseket követhetjük nyomon egy kártya I/O-val rendelkezô gépen: 1. Töltsük be a betöltô (loader) programot 2. Töltsük be az assembler programot 3. Olvassuk be a programot (ezt a

lépést esetenként meg kellett ismételni, hogy meggyôzödjünk a hibamentes olvasásról.) 4. 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). 5. Töltsük be ismét a loadert 6. Olvassuk be a célprogramot 7. Olvassuk be a programkönyvtár megfelelô elemeit 8. Olvassuk be a szerkesztõ programot 9. Szerkesszük össze a futtatható programot és készítsünk lyukkártyás outputot errôl. 10.Töltsük be újra a loadert 11.Töltsük be a futtatható programot 12.Futtassuk le a programot (VÉGRE!) Megjegyzés: a fenti leírásban a "töltsük be" kifejezést használtuk, ha egyszerû bevitelrôl volt szó, míg az "olvassuk be" mûveletet akkor használtuk, ha egy program segítségével (ti. a loader) történt a bevitel 13 Az eddigiekbôl világosan látszik, hogy az 1950-es években (figyelembe véve hazánk közel húsz éves lemaradását ezen a területen, ez nálunk a

70-es éveknek felelt meg ) a számítógép nagyon drága volt, és a használata korántsem volt hatékony. Jelentôs javulást eredményezett a hatékonyságban a mágnesszalagos tárolók megjelenése. Ennek eredménye az lett, hogy a kártyáról az adatokat mágnesszalagra rögzítették, a szalagról történô feldolgozás pedig már lényegesen gyorsabb volt. Ez a gondolat vezetett aztán ahhoz, hogy az eredeti számítógépeknél sokkal egyszerûbb és így olcsóbb gépek segítségével végezték el a beolvasást, majd az egészet a feldolgozó számítógéphez kapcsolva (mount) elvégezték a kívánt feldolgozást. Ennek az lett a következménye, hogy programok egész sora várakozott mágnesszalagon a feldolgozásra. Szükség volt egy olyan szakemberre, aki a szükséges elôkészületeket nagy hozzáértéssel, gyorsan el tudta végezni. Ô lett az operátor. Az ô jelenléte megjavította a számítógépek hatásfokát, azonban még mindig jelentôs

mennyiségû holtidô maradt kihasználatlanul. Ekkor kezdtek el gondolkodni azon, hogy hogyan lehetne automatizálni az operátor munkáját. Egy ilyen felügyelô (supervisor) program az elképzelések szerint a memória "egy félreesô sarkában" foglalt helyet. Amint egy program befejezõdött átvette a vezérlést, betöltötte a soron következõ programot és a vezérlést átadva az új programnak folytatta a munkát. A supervisor programok alkalmazásával megteremtôdött a lehetôség az elsô operációs rendszerek elkészítéséhez. 2.2 Supervisor programok és I/O rendszerek A supervisorok elsô telepítésének gondolata egy felhasználói csoporttól származott: az IBM számítógépeket alkalmazó vállalatok programozóinak egy csoportja a General Motors szakembereivel karöltve 1953-54-ben kifejlesztette a Input/Output S ystem supervisor programot, amely a fenti elveknek megfelelôen mûködött egy IBM 701-es számítógépen. Az itt keletkezett

tapasztalatokat használta fel egy SHARE nevû felhasználói csoport, amelynek specifikációi alapján az IBM implementált (számítógépre fejlesztett) egy új operációs rendszert, amelynek a SHARE Operating System (SOS) nevet adta. Ez az operációs rendszer ellátta a supervisori feladatokat, az I/O kezelést elvégezte, és támogatta az assemblerben írt programozást is. A SHARE csoporttól függetlenül a General Motors és a North American Aviation szakemberei is hozzákezdtek egy supervisor kidolgozásához az IBM701-re. Az általuk kiépített program neve FORTRAN Monitor S ystem (FMS), amely az elsô olyan OR volt, amely magasszintû programnyelven megírt programok feldolgozását támogatta. Ezek a rendszerek már jó hatékonysággal mûködtették a számítógépeket, amíg nem történt valami szabálytalan dolog. A supervisor programok ugyanis 14 elsôsorban méretük miatt - vagy egyáltalán nem voltak alkalmasak a hibák felfedezésére, azok

elhárítására, vagy csak igen korlátozott számban voltak képesek elvégezni ilyen feladatokat. 2.3 Szalagos és lemezes operációs rendszerek A mágnesszalagok megjelenése azt eredményezte, hogy egyre sûrûbben használták ezeket a háttértárolókat adatok tárolására, és ide kerültek a közös érdeklôdésre számot tartó rendszerprogramok is. Kialakul a "fontos", és a "kevésbé fontos" szalagok fogalma. A fontos szalagok állandóan a számítógéphez lettek kötve, míg a kevésbé fontosak csak akkor, amikor szükség volt rájuk. Ez a stratégia vezetett el a szalagos operációs rendszerek családjához (Tape Operating System = TOS). Ilyen OR volt pl a TOS/360 az elsô IBM-360-hoz. A mágnesszalagos rendszerek viszonylag rövid ideig "uralkodtak" az OR-k között. Ennek az volt az oka, hogy egy új típusú mágneses adattároló jelent meg a hardware elemek között: a mágnes lemez. Ennek a készüléknek két nagy elônye

volt elôdjével szemben: lényegesen több adatot lehetett tárolni rajta, és az adatok sokkal gyorsabban voltak elérhetôk. Így a szalagos operációs rendszerek átadták helyüket a lemezes operációs rendszereknek (Disk Operating System = DOS). Az új tipusú hardware-elem új kezelési technikákat követelt. Az elsô ilyen rendszerelem volt a rezidens load er, amelynek be kellett tölteni az OR-t és a felhasználói programokat a memóriába, elô kellett készíteni azokat a futásra. E feladatok ellátása után át kellett adnia a vezérlést az operációs rendszer egy másik részének, hogy azok folytassák a munkát tovább. Az új programoknak (job) szükségük volt olyan utasításokra, amelyek megmondták az OR-nek, hogy a végrehajtás során milyen erôforrásokra lesz szüksége a programnak. Ezeket a parancsokat egy speciális nyelv segítségével írták le. Ez volt a Job Vezérlô Nyelv (Job Control Language = JCL) 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, és megtette a szükséges lépéseket. Egy ilyen DOS OR-ben az Input/Output Ellenôrzô Rendszert (Input/Output Control System = IOCS) is jelentôsen megjavították. A különbözô erôforrások, készülékek kezelésével, támogatásával a szubrutinok egy egész csoportja foglalkozott. A mûködés szempontjából kritikusnak ítélt készülékeket támogató rutinok permanens módon a memóriában maradtak, míg más készülékek kezeléséhez a rutinokat csak akkor szerkesztették a felhasználói programokhoz a rendszer szerkesztôje (linker) segítségével ha annak szüksége volt rá. (Más változatokban ezeket a rutinokat a loader töltötte be). Kialakult az OR két 15 speciális része: a rezidens, amely állandóan a központi memóriában van, és a tranziens, amely csak a felhasználása idején kerül a CPU-ba. Ezeket az OR-ket már a

hardwaret gyártó cégek készítették, és a géppel együtt szállították. A következô táblázat néhány ilyen OR-Hardware párosítást mutat be: Géptípus OR Honeywell ADMIRAL UNIVAC 1107 EXEC 1 Control Data SCOPE Burroghs 5000 Master Control IBM 7090 IBSYS 2.1 Ábra Néhány DOS OR Az alfejezet lezárása elôtt vizsgáljuk meg, hogyan történt egy DOS OR-ben egy assembler program feldolgozása. (Hasonlítsuk össze a korábbi kártyás rendszerrel!) 1. A JCL feldolgozó program megvizsgálja a JCL-ben leírt parancsokat 2. A JCL parancsoknak megfelelôen az OR betölti és elindítja az assembler fordító programot, amely beolvassa az input programot és elôállít egy olyan object modult, amelyet ideiglenesen mágneslemezre helyez el. 3. Most ismét a JCL parancsait követve, a szerkesztô kerül betöltésre és végrehajtásra, hogy a megfelelô szubrutinokat az object modullal összeszerkessze. 4. Végül az elkészült load modul kerül a

memóriába, és mint elkészült felhasználói program, végrehajtódik. 2.4 Multiprogramozás batchben A korai operációs rendszerek arra törekedtek, hogy a programok vezérlését teljes egészében kivegyék a programozó kezébôl, és átadják azt az operátornak ill. a rendszerprogramozónak A futtatandó programokat a programozóknak össze kellett állítani egy "csomagba", amely minden segédinformációt tartalmazott. A feldolgozást ezeken a csomagokon végezték el oly módon, hogy 16 egyidejûleg egy ilyen "köteg" foglalta el a memóriát, majd annak befejezése után az új csomag került beolvasásra. Ez volt az un soros kötegelt feldolgozási rendszer (Serial batch processing system). Idôközben azonban a számítógépek központi memóriái egyre nagyobbak és egyre gyorsabbak lettek. A sebességeltérés a központi tár és a különbözô I/O készülékek között is tovább nôtt. Ennek az lett a következménye,hogy egy I/O

készülék használata során mind gyakrabban fordult elô, hogy a CPU-nak várnia kellett az I/O mûvelet befejezésére. Kézenfekvô volt az az ötlet: egyidejûleg töltsünk be több felhasználói programot a központi tárba, és ha egy futó programnak várni kell valamilyen I/O mûveletre, akkor ebben az idôben a CPU tud dolgozni a másikon. Így született meg a többprogramos kötegelt rendszer (Batch Multiprogramming System). Az elsô ilyen OR a Master Control Program (MCP) volt a Burroughs 5000 számára. Ez az OR két új elvet használt fel a hatékonyság érdekében • Virtuális m emória. A módszer lényege az, hogy a programok fordítása során kihasználjuk a CPU címezhetõsége által biztosított összes lehetõséget. Amikor a lefordított programot betöltjük a futtatáshoz, akkor nem biztos, hogy akkora memória a rendelkezésünkre áll, amekkorát elméletileg megcímezhetünk. Mivel a program így olyan címeket is tartalmazhat, amelyek fizikailag

nem állnak rendelkezésre, ezért az OR-nek úgy kell viselkednie mintha ezeket a címeket is látná: látszólag (virtuálisan) tehát a rendelkezésére áll olyan memória cím is, amely fizikailag nem létezik. (A virtuális memóriakezelésnek az elmúlt években egész elmélete alakult ki, amelyet a jegyzet egy késõbbi fejezeteében részletesen tárgyalunk.) • Prioritások h asználata. A programokhoz hozzárendelt prioritás (pozitív egész szám) határozta meg a program "sürgôsségét". Egy nagyobb prioritású program sûrûbben kapta meg a vezérlést. A többprogramos batch rendszerek legismertebb képviselôje az IBM 360as számítógépek részére készített OS/360. Népszerûségét az alapozta meg, hogy a hardwaret és a softwaret közös koncepció alapján fejlesztették. A hardware moduláris felépítése lehetôvé tette, hogy a felhasználók egy kis rendszerbôl kiindulva fokozatosan építsék ki a szükséges konfigurációt. Ugyanakkor a

softwaret úgy fejlesztették tovább, hogy a régebbi rendszerekben írt programok legnagyobb része futtatható legyen az új verzió felügyelete alatt is. Két egymást követô változatot dolgoztak ki az IBM360 -as gépekre: • OS/MFT (Multiprogramming with Fix Tasks). • OS/MVT (Multiprogramming with Variable Tasks). 17 A két OR között az alapvetô különbség az, hogy az utóbbi a programok számára az igényelt memóriának megfelelôen biztosít területet. Az OR hatékonyságát nagy mértékben javította az a vezérlô nyelv, amely a batch feldolgozás szerves része volt. Ennek a JCL-nek azonban komoly hátránya volt, hogy viszonylag egyszerû programok vezérléséhez is esetenként bonyolult volt a kisérôkártyák összeállítása. Ennek a rendszernek egy további újítása volt az un. spool technika: egy speciális program olvasta be az inputról a programokat, és helyezte el egy lemezen. A programot ezután a megfelelô idôben most már egy gyors

háttértárolóról kellett beolvasni. Az output hasonló elven mûködött: nem nyomtatóra írta ki a kívánt adatokat, hanem mágneslemezre. A "spooling" program ezután a lemezrôl másolta a nyomtatóra vagy más output készülékre az adatokat anélkül, hogy a központi memóriában éppen futó programokat várakozásra kényszerítettek volna. 2.5 Idôosztásos rendszerek (Timesharing) Annak ellenére, hogy a kötegelt feldolgozás sokkal hatékonyabban mûködtette a számítógépet, mint bármely elôdje, a programozók öröme nem volt mindig felhôtlen. Az operátori munka ugyanis megfosztotta ôket a közvetlen ellenôrzés lehetôségétôl. Emellett az a holtidô is igen nagy volt, amely az operátornak leadott kártyacsomag és a lefuttatott program kézhezvétele között eltelt. Ez különösen akkor volt kellemetlen, amikor a progamok tesztelése folyt. A megoldást a gyors mágneslemezegységek jobb kihasználása szolgálta. Ebben az idôben már nem

csak a spool technikára használták ezeket, hanem a rendszerprogramok nagy részét is mágneslemezen tárolták. Ezeket a programokat gyorsan lehetett aktiválni. Így, ha a felhasználónak csak néhány JCL utasítást kellett javítani vagy beszúrni, akkor megkapta a lehetôséget, hogy ezt egy terminálról vagy más interaktív I/O eszközrôl elvégezze. Hasonlóan lehetôséget biztosítottak arra, hogy az output listákat is ezeken a készülékeken kinyomtassák. Ez vezetett el egy új tipusú interaktív feldolgozáshoz Az új technika az elônyök mellett azonban hátrányokat is hozott magával: a kötegelt programozásban már kifejlôdött az a technika, hogy egyidejûleg több program volt a memóriában, azonban vezérlésátadás a programok között csak akkor történt, ha az éppen futó program egy un. megállási ponthoz ért Ez néha azt eredményezte, hogy programok percekig vagy akár órákig is futhattak megállás nélkül. Az interaktív technika ezt

nem engedhette meg Az új idôosztásos (time slice, time sharing) üzemmódban egy óra (timer) mérte a legutolsó vezérlésátadás óta eltelt idôt, és azonnali megszakítást eredményezett, ha az "idôszelet" lejárt. Ekkor a vezérlés átadódott a várakozó programok egyikének, és az éppen megszakított program várakozni kényszerült. Az ilyen 18 típusú rendszerek fénykora az 60-as, 70-es évekre esett. Egyik korai képviselôje volt a DEC PDP-1 számítógépre kifejlesztett Compatible Timesharing System (CTSS) volt. A Kemény és Kurtz által Darthmouthban a General Electirc számára kifejlesztett Darthmouth Timesharing System (DTSS) mellett az IBM TSS/360-as rendszere volt a legsikeresebb ebben az idôszakban. A kezdeti sikerek nyomán egyre több felhasználó akarta egyidôben használni az interaktív lehetôséget. Ez a gyakorlat hamar a felszínre hozta a rendszer gyengeségét: az OR az idô legnagyobb részét azzal töltötte, hogy ideoda

kapcsolt a programok között, és adminisztrált. A tényleges munkára egyre kevesebb idô jutott. Emellett az állandó beavatkozások miatt megnôtt annak a veszélye, hogy az egyik programban bekövetkezett hiba esetleg tönkretesz más programokat vagy adatokat is. Új, gondosabban kifejlesztett supervisor programra volt szükség. Az ilyen irányú fejlesztést három nagy kutatóintézet együtt kezdte meg. A Massachusets Institute of Technology (MIT), az AT&T/Bell Laboratories és a General Electric közös erôfeszítésének eredménye volt a MULTICS rendszer. Ez az OR számos új gondolatot tartalmazott. Itt használták elôször a szegmentált virtuális memóriát, az erôforrás-védelem új módszereit dolgozták ki ("gyûrûs védelem"), hierarchikus file-rendszert építettek fel, megalkották a készülék-független I/O fogalmát, elôször alkalmazták az I/O átirányítását más készülékre. Mindezt egy nagyon hatékony felhasználói-interface

tette "barátságossá". A MULTICS egyik legnagyobb elônye az volt, hogy magas szintû programnyelven (PL/I) íródott, és így könnyen fejleszthetô volt. Mindezek azt eredményezték, hogy az OR-k egy teljesen új korszaka következett be. A UNIX 1970-ben a MULTICS program két kutatója, Ken Thompson és Dennis Ritchie átkerült egy másik software csoportba, ahol belekezdtek egy olyan egyfelhasználós OR kifejlesztéséhez, amely a kutatásaikat jobban segítette. A fejlesztés nagymértékben a MULTICS tapasztalatain alapult. A két kutató által UNIX-nak keresztelt OR teljesen eltért a korábbi rendszerektôl. A PDP-en telepített rendszer olyan felhasználói kényelmet biztosított, amely következtében egyre népszerûbb lett a Bell Laboratóriumban. A Unix környezet kulcsfontosságú része egy egyszerû, de mégis hatékony hierarchikus felépítésû file-rendszer volt, amelyhez egy jól kezelhetô shell-nek nevezett parancs interpreter csatlakozott. A

file-rendszer az I/O készülékeket speciális állományként kezelte, és a shell képes volt a parancsai által gyártott outputokat átirányítani bármely kiválasztott állományba vagy készülékre. Az input kiválasztására hasonló rugalmasságot biztosított a rendszer. Így lehetôvé 19 vált, hogy egy parancs által elôállított output lista egy ôt követô parancs inputjaként szolgáljon. Annak ellenére, hogy a UNIX elsô változatai egyfelhasználós rendszerként mûködtek, képes volt egyidejûleg több program futtatására is (ezeket processeknek vagy folyamatoknak nevezték). Az elsô UNIX rendszerprogramokat assembler nyelven írták. A késôbbiek során át akartak térni a PL/I-re, azonban ez a magas szintû programnyelv nem volt implementálható a PDP számítógépekre. Ritchie úgy oldotta meg a problémát, hogy kifejlesztett egy új nyelvet, a "C"-t (A név onnan ered, hogy a fejlesztés során nagyon sokat felhasznált egy

"B"-nek nevezett kisérleti nyelvbôl.) A C fordítót PDP-11-re fejlesztette ki, és a Unix rendszert teljesen átírták C-re. A Unix-t az AT&T Laboratoriumában már széles körben használták, amikor még mindig nem volt hivatalosan megvásárolható. Következô lépésként a fejlesztôk kiadtákt a kisérleti rendszert egyetemeknek, (a forrásprogramokkal együtt.), ahol egymástól független fejlesztôk százai foglalkoztak a rendszer javításával, bôvítésével. A kutatók és a hallgatók között hamar népszerû lett a könnyen alakítható rendszer. Számos változatot hoztak létre, amelyek közül az egyik legsikeresebb a californiai Berkely egyetem által kifejlesztett UNIX rendszer lett. A UNIX lett az elsô olyan OR, amely a hardwaretôl függetlenül terjedhetett. Így egy sor különbözô számítógépre implementálhatták ezzel a világon elôször készült hordozható OR. Abstrakt és virtuális gépek Térjünk vissza a 60-as évek

végére. Miközben a MULTICS fejlesztése teljes erôvel folyt az Egyesült Államokban, Európában az Eindhoveni Egyetemen Edgar Dijsktra vezetésével egy új többfelhasználós rendszert dolgoztak ki. A THE-nek nevezett rendszer olyan új elvek alapján épült fel, amelyek nagy hatással voltak az OR-k késôbbi fejlesztésére. (Az elnevezés az egyetem holland nevének rövidítésébôl származik: Technische Hoogesschool Eindhoven.) A THE újdonsága elsôsorban az interaktív folyamatok kezelésében, és a rendszer hierarchikus felépítésében rejlett. Az elôbbi problémák megoldására olyan új módszereket vezetett be elsôsorban a holtpont és a szinkronizáció kezelése, amelyek közül jó néhányat még a mai napig is alkalmaznak. Az utóbbi, (ti a hierarchikus struktura) megvalósítása úgy történt, hogy a rendszer komponenseit különbözô szintekre sorolták be. Ezek a szintek csak a közvetlen szomszédjaikkal álltak kapcsolatban. Így az elsô

szinten helyezkedtek el az idôzítôk (timerek), a megszakítások és a virtuális memória kezelés. Ezeknek a szinteknek a segítségével minden magasabb szint - így a felhasználói programok szintje is - fel tudott építeni egy 20 olyan gépet, amelyre szüksége volt. Az alsó két szint egy un absztrakt gépet szolgáltatott, amelyet mindenki szabadon használt fel. A rendszer hierarchikus felépítése a fejlesztése során is kamatozott: az alsó szintek a teljes kifejlesztés után megbízhatóan támogatták a további szintek fejlesztését. A THE rendszert számos hierarchikus struktúrájú OR követte A TENEX ( 1972) a PDP-10, PDP-11 gépeken lett felépítve. Ez a rendszer egy olyan absztrakt gépet szolgáltatott, amely magába foglalta a file-rendszert, minden felhasználónak megengedte egyidôben több process futását, virtuális memóriát lehetett használni. Így egy fajta "virtuális gépet" szolgáltatott, bár kétségtelen, hogy ez a

megközelítés az IBM által kifejlesztett CP/CMS rendszer révén vált ismertté (CP = Control Program, CMS = Cambridge Monitor System). A rendszer fejlesztôinek célkitûzései között szerepelt, hogy olyan ORt készítsenek, amely az IBM minden kutatási és fejlesztési munkáját támogatja (beleértve természetesen magát az OR-k fejlesztését is.) Ehhez alakították ki a virtuális gép koncepcióját. Ez a virtuális m emória illúziójához hasonlóan minden felhasználó számára azt a képzetet keltette, hogy saját CPU-val és saját erôforrásokkal rendelkezik. A CP/CMS legsikeresebb változata az FBM/370-re kifejlesztett VM/370-es OR volt. OR-k kis számítógépekre Az 1960-as évek kezdetéig a számítógépek hardware elemei többnyire egységesen fejlôdtek. Ennek az volt a következménye, hogy az OR-k fejlôdése is egységes elvek alapján történt. A hardware elemek árának (és méretének) rohamos csökkenése azonban azt eredményezte, hogy

fokozatosan különbözô kategóriák keltkeztek a számítógépek között. Kialakultak a mini-mikro -, ill személyi-számítógépek (PC = Personal Computer). Ebben az alfejezetben bemutatjuk azokat az OR-ket, amelyek ezekre a számítógépekre készültek. Az ár és a méret csökkentésében élenjárt a DEC és az IBM. 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. A DEC által kifejlesztett PDP sorozat olyan hardware-rel rendelkezett (megszakítások, közvetlen memória címzés a gyors I/O készülékek számára), amely alkalmassá tette ezeket a gépeket a real-time rendszerek laboratóriumi és egyéb ellenôrzô rendszerek irányítására is. Az IBM 1800 és 1130-as modellje 16 bites CPU-val rendelkezett. Hardware újdonságai között találhattuk a többcélú akkumulátorokat és az indexregisztereket is. A fenti gépekre fejlesztett OR-k egy darabig a

"nagygépes" irányt követték. Amikor a méretekbôl adódó korlátok ezt szükségessé tették, akkor az utak szétváltak: a mikroszámítógépek operációs rendszerei egyre inkább az egyfelhasználós rendszerek irányába tolódtak el. Késôbb az idô múlásával, a technika fejlôdésével itt is felvetôdött a többfelhasználós rendszerek igénye is. 21 Érdekes, hogy ezeken a gépeken a többfelhasználós rendszerek legfeljebb korlátozott változatai jelentek meg. A TOPS-10 (PDP-10-es gépre) a timesharing egy szûkített változatát szolgáltatta, míg az RT-11 (PDP-11-re) egy speciális multiprogramozást tett lehetôvé: két program futhatott egyidejûleg a rendszerben. Az egyik interaktív vezérléssel, a felhasználó által elérhetô helyen (az "elôtérben"), míg a másik "takarva", megfosztva minden kommunikációs lehetôségtôl a "háttérben". A nyomtatott áramkörök megjelenése újabb fordulatot

hozott a számítógépek fejlôdésében. A mikroprocesszorokban egyre nagyobb bonyolultságú áramköröket lehetett elhelyezni, miközben az árak is tovább csökkentek. A 60-as évek végén megjelentek a zsebszámológépek, a melyek számos elemet tartalmaztak a számítógépek alkotórészeibôl: bonyolult mûveletsorokat (néha egész programokat) lehetett velük végrehajtani, és adatokat is tárolhattunk bennük. Mivel az áraik néhány száz dollár körül mozogtak, ezért rendkívül népszerûek voltak, és hamar elterjedtek. Ahogy fejlôdtek a kalkulátorok, úgy lettek a bennük felhasznált chipek egyre bonyolultabbak, és váltak egyre kevésbé kezelhetôvé. Új elveken mûködô, általános célú processzorra volt szükség. 1971-ben jelent meg az Intel Corporation egy ilyen hardware elemmel: az INTEL 4004-be egy teljes 4-bites CPU volt elhelyezve néhány áramkörben. Ezt követte a 8008-as változat, amely már 8-bites szervezésû volt. (A bitek

számának a címezhetôségnél volt elsôsorban szerepe). Újabb két év elteltével az INTEL piacra dobta a 8080-as processzort. Más cégek is fokozatosan mutatták be új processzoraikat: a Zilog Z-80-asa, a Motorola 6800-asa ugyanolyan népszerû volt, mint az INTEL processzorok. Annak ellenére, hogy azok a cégek, amelyek a mikroprocesszorok fejlesztésével foglalkoztak nem voltak érdekeltek a számítógépek fejlesztésében is, egyre nyilvánvalóbbá vált, hogy ezek a hardware elemek jól lennének használhatók egy új számítógéptípusban. Amikor sikerült megoldani a memóriák méretének és árának a csökkentését is, akkor megszülettek a mikroszámítógépek. Ezek a különbözô mikroproceszorokra épülô gépek aztán gomba mód szaporodtak el. Hazánkban közismert volt a SINCLAIR, a különbözô COMMODORE típusok, az APPLE II, a WANG stb. A nagy számítógép gyártó cégek sokáig vártak. Amikor azonban az IBM megjelent a személyi

számítógépével, azonnal háttérbe szorította a többieket. Annak ellenére, hogy a mikroszámítógépes hardware hihetelen gyorsasággal fejlôdött, a rendszersoftware ezekre a gépekre sokáig késett. Egyszerû loadereket használtak hosszú ideig. (Ezeket csak olvasásra szolgáló memóriákban tárolták). Az elsô OR-t Gary Kildall készítette az INTEL 8008-as processzorra: kifejlesztett egy compilert, ami a PL/I egyszerûsített változatát tudta kezelni. Az új nyelv neve PL/M (Programming Langnage for Microcomputer) lett. A nyelvet azért fejlesztette ki, hogy operácós rendszert 22 írhasson. Az új OR neve CP/M lett (Control Program for Microprocessors) Ez az egyfelhasználós rendszer magában foglalt egy egyszerû, interaktív parancs interface-t, alap I/O készülék-kezelést, és egy hajlékony mágneslemezen elhelyezett file-rendszert is. (Ez a floppy rendszer) A fenti fejlesztésnek az ad különös érdekességet, hogy az INTEL nem támogatta Kildall

fejlesztési törekvéseit. Ezért kilépett, és feleségével megalakította a Digital Research-t, amelynek a CP/M lett aztán az elsô és legsikeresebb terméke. A legtöbb mikroszámítógépes cég CP/M verziót ajánlott gépéhez. Annak ellenére, hogy a CP/M nagyon népszerû volt, számos hiányossággal is rendelkezett: kezdetleges volt a felhasználói interface, gyenge a file-rendszer kezelés, és teljesen hiányoztak olyan OR képességek, mint a memória kezelés, vagy a multiprogramozás. A CP/M-en túlmutató elsô OR-t a Seattle Computer Products mutatta be: az SCP-DOS az INTEL új processzorára, a 8086-ra lett kifejlesztve és számos javítást tartalmazott: idôzítôk kezelése, megszakítások támogatása stb. Késôbb a Microsoft Corporation ez alapján fejlesztette ki a ma legjobban elterjedt MSDOS OR-t. Bár maga a UNIX OR elsôsorban méretei miatt nem volt alkalmazható a mikroszámítógépes környezetben, mégis erôs hatást gyakorolt az itteni OR-k

fejlôdésére. Az MS-DOS különbözô változataiban egyre gyakrabban találkozhatunk olyan elemekkel, amelyek elõször a UNIX-ban jelentek meg (hierarchikus file rendszer I/O átirányítás stb.) 1970-ben a Xerox Corporation létrehozott Californiában egy fejlesztô részleget, a Palo Research Centert (PARC). Ennek a kis gyárnak az volt a fô feladata, hogy a technológia élvonalába tartozó kutatásokat folytassa. A PARC egyik legjobb fejlesztése az ALTO nevû számítógép volt. Ez a gép új tipusú kommunikációt folytatott a felhasználóval: a billentyûzet használata mellett az ALTO felhasználóinak lehetôségük volt a képernyôn megjelentetett grafikai szimbólumok (un. ikonok) között válogatni A kiválasztást egy könnyen mozdítható un. "egér" (mouse) segítségével végezhették el Az ilyen tipusú funkcióválasztás nagymértékben megnövelte a gép hatékonyságát. Az ALTO drága volt és nem is volt igazi mikroszámítógép. Az

INTEL8008 még fejlesztés alatt volt, amikor az ALTO már megjelent Mivel ez a gép kifejezetten professzionális felhasználásra készült, néhány jellemzôjében eltért a késôbbi mikroszámítógépektôl. Úgy kezelték, mint egy munkaállomást (workstation), és számos késôbbi tipus modelljéül szolgált. Ez alapján fejlesztette ki a Xerox a STAR-t. Ez egy nagy képernyôvel rendelkezô olyan munkaállomás volt, amely ALTO tipusú ikonos felhasználói interface-szel rendelkezett. Az igazi sikert a fenti tipusú rendszerek között az APPLEMachintosh ért el Titka elsôsorban az operációs rendszer hatékonyságában és abban rejlett, hogy a teljes munkaállomás funkciót nyújtott alig 2000 dollárért. 23 Az egyfelhasználós munkaállomások egy új tipusú OR kifejlesztésének az alapjául szolgáltak. Az OR-t sokáig úgy tekintették, mint a számítógépes rendszer irányítóját. Az új koncepció szerint az OR a felhasználó kiszolgálója lett. Az

ilyen tipusú OR középpontjában a kényelem és nem az ellenôrzés áll: az OR szolgáltatásokat nyújt, de nem lép kapcsolatba a felhasználói programokkal, úgy tekinthetô mint egy szubrutin gyûjtemény. Így eltünt az éles határ a felhasználói programok és az OR között, megszületett a nyitott OR gondolata. Egy ilyen rendszer nem korlátozza a felhasználót, bár ha valmilyen hiba lép fel, akkor a programok sokkal sebezhetôbbekké válnak. Közben a mikroprocesszorok is rohamléptekkel fejlõdtek. A ‘80-as években az INTEL gyors egymásutánban dobta piacra az új 16 bites (8088) és 32 bites processzorait, és ezzel párhuzamosan alakították az MS-DOS különbözõ változatait is. Ezek az új verziók azonban már nem hoztak forradalmi változást. Az újabb lökést a fejlõdésnek az adta, amikor a ‘90-es évek elején felismerve az ikonos rendszerek elõnyeit a Microsoft kifejlesztette az Intel processzorokra alapozva a Windows operációs

rendszert, amely fokozatosan szorítja ki a korábbi OR változatokat a mikrogépek vilgából. Hálózatok és osztott rendszerek A különbözô számítógépek összekapcsolásának gondolata nagyon régi. Egy ilyen kapcsolat gyors és hibamentes információcserét biztosíthat rendszerek között. Adattovábbításra alkalmas készülékeket már a 60-as években készítettek, így lehetôvé téve egymástól nagy távolságban lévô számítógépek összekapcsolását. A nagy távolság azonban rengeteg hibalehetôséggel járt együtt, ezért kifinomult technikákra volt szükség, hogy megbízható adatátvitel jöjjön létre. Az elsô ilyen hálózatot az Egyesült Államok Védelmi Minisztériumának megbízásából hozta létre a Department of Advenced Research Project (DARPA), és a hálózat neve ARPANET volt. Ebben a hálózatban minden gépnek saját OR-e volt. A kommunikáció egy speciális I/O tevékenység volt. Ha egy felhasználó adatokat akart átvinni

(vagy áthozni), akkor mindenekelôtt ismernie kellett a távoli gép adatformátumát, másrészt rendelkeznie kellett olyan jogokkal, amelyekkel az adattovábbítást végrehajthatta. Az ARPANET megengedte a távoli gépek közvetlen interaktív felhasználását is, de az elszámolás és egyéb tevékenységek a felhasználó felelôsségei közé tartoztak. Az elsô olyan OR-t, amelyben a felhasználó a hálózatot az erôforrások egységes rendszereként kezelhette a National Software Works készítette. Itt egy központi adatbázis támogatta a felhasználókat, és a rendszer erôforrásait egy 24 központ segítségével lehetett elérni. Ez alapján születtek meg a különbözô hálózati operációs rendszerek. A Xerox PARC-nál folyó fejlesztések egy olyan hálózat létrehozását sürgették, amelyben egymáshoz viszonylag közel kis számítógépek helyezkednek. Itt a közelség miatt lehetôség volt nagy gyorsaságú adatátvitelre Kialakították a Local

Area Network (LAN) rendszert. Azt a speciális rendszert amely a LAN hálózatokat támogatta, ethernet-nek nevezték. Egy ilyen rendszer számos kisszámítógépet és néhány nagyot tartalmaz, és esetenként egyéb kommunikációs eszközök is tartoznak a rendszerhez (pl. távoli összeköttetést lehetôvé tevô telefon vonalak). A LAN rendszerek legelterjedtebb típusainak egyike a hazánkban is széles körben használt NOVELL rendszer. Az, hogy a hálózatba kapcsolt gépeket egységes elvek alapján kezeljék, egy újszerû OR kifejlesztését tette szükségessé. A cél a LAN rendszerekhez hasonlóan az volt, hogy a hálózatban rendelkezésre álló erôforrásokat úgy tudjuk kezelni, mint a saját gép bármely erôforrását. Egy ilyen osztott operációs r endszeren a szélsôséges esetben a programok (és így a felhasználók sem) nem tudják megmondani, hogy hol van az az erôforrás a rendszerben amelyet éppen használnak. Utószó E rövid történeti

áttekintésben nem törekedhettünk teljességre. Igyekeztünk azokat az irányokat fölvázolni, amelyek a fejlôdés fô vonalába estek. Amikor példákat mutattunk, a helyszûke miatt nem beszélhettünk részletekrôl, és a felsorolásunk szinte sehol sem teljes. Nem beszéltünk olyan jelentôs rendszerekrôl, mint az IBM PS/2 vagy a CRAY különleges struktúrája. Felsorolásunkból hiányoznak a UNIX különbözô változatai. Nem beszélhettünk a hálózati protokollok széles családjáról sem. Mégis abban bízunk, hogy az áttekintés, amelyet ebben a fejezetben adtunk hasznos. Segít megismerni az OR-k fejlôdését, és hozzájárul ahhoz, hogy megfelelô rálátással kezeljük azt a bonyolult feladatkört, amelyet egy jó ORnek el kell látnia. 25 3. Az operációs rendszerek szerkezete Amint azt láttuk, az OR nem más, mint programok gyûjteménye (rendszere). Amiért meg kell különböztetnünk más (felhasználói) programrendszerektôl ez azért van,

mert az OR speciális szerepet játszik a számítógép irányításában. Azért, hogy az OR-t a leghatékonyabbá tegyük, már a rendszer szervezésénél számos szempontot kell figyelembe vennünk. Az eltérô hardware környezet mellett a felhasználók tervezett száma, a tervezett I/O készülékek tipusai mind olyan összetevôk, amelyek egy OR-rel szemben teljesen egyedi követelményrendszert támasztanak. Ennek az a következménye, hogy nem nevezhetünk meg olyan struktúrát, amely egyértelmûen jobb a többinél. Ebben a fejezetben néhány olyan jellegzetes szempontot mutatunk be, amelyet a legtöbb jól szervezett OR tervezésnél figyelembe kell venni. 3.1 Forráskódok szervezése Amikor egy OR-t összeállítunk a forráskódú elemekbôl, akkor az alkalmazott eljárás teljesen azonos azokkal a módszerekkel, amelyeket egyéb nagyméretû software rendszereknél használunk: elsô lépésként forrásnyelvû modulokat készítünk, amelyekbôl egy fordító

program segítségével un. gépikódú (object) m odulokat állítunk elô. (Elôfordulhat, hogy a fordítási eljárás során programkönyvtárakban tárolt további forrásnyelvû modulokat is felhasználunk.) Ezután - második lépésként az object modulok halmazából elemeket szerkesztünk össze olyan módon, hogy azok futtatható (load) modulokká álljanak össze. (Hasonlóan az elsô lépéshez, itt is felhasználhatunk forrássszintû modulokat egy erre kijelölt könyvtárból.) Egy OR számos futtatható modult tartalmaz. Ezek a modulok valamilyen másodlagos tárolón helyezkednek el, és vagy akkor töltjük be ôket, amikor "inicializáljuk" a rendszert, vagy akkor, amikor olyan mûveletet hajtunk végre, amely elvégzéséhez az adott modulra szükségünk van. A következôkben felsorolunk néhány olyan szempontot, amelyeket mindenképpen érdemes figyelembe vennünk akkor, amikor OR-t tervezünk: • Egy eljárás, vagy adatoknak egy halmaza lehetôleg

ne legyen két listázott oldalnál hosszabb, mert ellenkezô esetben elveszítjük az áttekinthetôséget. 25 • Minden olyan forráskódot és adatot, amelyek egy egységbe tartoznak, kezeljük együtt. Egy modul csak azokat az információkat igényelje, amelyekre valóban szüksége van. • 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. Ezek a fenti szabályok nem "OR specifikusak": Minden nagy méretû rendszert ilyen elvek alapján építünk fel. Ami az OR-k esetén mégis egyedi, az az, hogy itt komolyan "egyensúlyoznunk" kell az összefogott kódolás és a hatékonyság között. A kis OR-k általában csak néhány modulból épülnek fel. Ezeket a modulokat lehet úgy választani,

hogy megfeleljenek az OR azon részeinek, amelyeket elkülönítve tudunk tárolni és futtatni. Ezzel szemben a nagyobb OR-k egy sor olyan modult tartalmaznak, amelyek kapcsolatban állnak egymással. Ennek az a következménye, hogy esetenként egy belsô eljárás több forrásnyelvû modulból épül fel, míg máskor ugyanazt a forrásmodult több eljárásba is beépítjük. Egy OR hatékonyságát nagy mértékben befolyásolja, hogy a forrásprogramok milyen nyelven íródtak. Nagyon sokáig tartotta magát az a hit, hogy a jó OR-t csak assembler nyelven lehet írni. Ez abból táplálkozik, hogy sokan úgy gondolják, hogy egy OR-nek a fizikai erôforrásokat közvetlen ellenôrzés alatt kell tartani, a regiszterek és más speciális memória helyek tartalmát ismernie kell, ugyanekkor ezek normális keretek között tiltottak egy magas szintû nyelven írt program számára. Így egészen az utóbbi idôkig szinte minden OR assembler nyelven íródott. Ez a helyzet az

utolsó évtizedben változott meg. Ennek számos oka volt: • Jó néhány olyan magasszintû programnyelv készült el az elmúlt években, amelyet 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 minden olyan gépen használható, amely rendelkezik a nyelvhez fordító programmal, így az OR-k hordozhatóvá válhattak. A magas szintû programnyelvek alkalmazásakor nem szabad megfeledkezni arról, hogy az OR-k azon részeit, amelyek elsôdlegesen felelôsek a hatékonyságért assemblerben nagyobb hatásfokkal írhatjuk meg. Ilyenkor érdemes azt az eljárást követni, hogy elôször megírjuk ezeket a részeket magasszintû programnyelven, teszteljük a funkciókat, majd a hibátlanul mûködô részt újra írjuk a nagyobb hatékonyság elérése érdekében. Rendszer példák 26 A kis rendszerek forráskódjának struktúrája jól

illusztrálható a CP/M OR-rel. Ez az OR három jól elkülöníthetô részbôl áll, amelyek más-más szervezési feladatot látnak el: A BDOS (Basic Disk Operation System) végzi az ellenôrzést és a file-szervezést. A BIOS (Basic Input/Output System) a készülékek kezeléséért felelôs, míg a CCP (Console Command Processor) feladata a felhasználóval való kapcsolattartás (user interface). Ezek a rendszer alkotóelemek teljesen eltérô helyen vannak tárolva és eltérô módon használjuk ôket. A BDOS egy összefüggô modul, amely kb 1000 soros és PL/M-ben íródott. A CCP kb 500 sor terjedelmû. A BIOS az egyetlen olyan része az OR-nek, amely az installáláskor változhat. Ennek az az oka, hogy alacsony szintû kódokat is tartalmaz a készülékek kezeléséhez. Így a BIOS-t modulokra osztották, terjedelme 2-3000 sor, és többnyire assemblert használnak a megírásához. A nagy rendszerek bemutatására a UNIX OR-t használjuk. A Berkeley UNIX törzsét egy

kb. 100 file-ból álló forráskódú rendszer alkotja, amely közel 35.000 C-kódú sorból áll. Egy tipikus file néhány száz sor hosszú, és néhány további eljárást használ. A UNIX forrás modulok kb 100 definiciót használnak fel. Ezeket szokás header-nek nevezni. Egy tipikus header file pl a rendszer egy adatstruktúráját írja le A megszakítások kezeléséhez, az I/O regiszterek kezeléséhez a Berkeley UNIX a VAX gép assembler-jét használja. Egy ilyen assembler modul hossza 1000 sor körül mozog, és ez az OR egyetlen olyan része, amelyet nem C-ben írtak meg. 3.2 Társzervezés Az OR mûködése során annak egy része állandóan a fôtárban van. Ezt a részt rezidens-nek nevezik A rezidens komponensei felelôsek azokért a szolgáltatásokért, amelyeknek rendelkezésre kell állni akkor, amikor egy program fut a számítógépen. (Ilyen szolgáltatások a hibakezelés, process vezérlés, végrehajtás ellenôrzés stb.) A rezidensnek azt a részét,

amely a legkritikusabb részeket tartalmazza szokás nukleusnak vagy kernel-nek is nevezni. A rendszer rezidens része a memória meghatározott részén helyezkedik el. Általában ez a memória legalacsonyabb címzésû része. A felhasználói programokat gyakran egy adott címtôl töltjük a memóriába, és a rezidens további részeit úgy olvassuk be, hogy azok a memória legmagasabb részére kerülnek. Néhány OR-ben a 27 rezidens ROM-okban van elhelyezve, hogy mindenképpen elkerüljük a rendszer ezen részének szétesését. A rendszer azon komponenseit, amelyek kevésbé fontosak, elegendô akkor betölteni, amikor szükség van rájuk. Ezek a részek alkotják együtt az un. tranziens részt Ide tartoznak a parancs interface elemei, és a file-kezelô rendszer egyes részei. A tranziens részeit azokra a területekre töltjük be, amelyek éppen rendelkezésre állnak. Számos számítógépben a tranziens elemeknek áthelyezhetôknek (relocated) kell lenniük.

Ezen azt értjük, hogy ezek a programok mindig rendelkeznek egy un. bázis címmel, és az összes utasítást és adatot ehhez a báziscímhez viszonyítva un. relatív címes formátumban ôrizzük egy háttértárolón. Betöltéskor mindig e bázis címet adjuk meg, és a modul betöltése a relatív címek segítségével vagy software vagy hardware úton (esetleg ezek kombinált alkalmazásával) valósul meg. Néhány számítógép felépítésében a memória címezhetô részének egy tartománya un. memória függô (memory mapped) I/O részére van fenntartva. (Ez a fajta I/O kezelés azt jelenti, hogy a készülékek számára az információt a központi memória meghatározott területén tároljuk, és innen tudjuk azt kiolvasni.) 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ô, akkor ez a védelem viszonylag egyszerû. Amikor a memória bonyolultabban van

felosztva, akkor ez a védelem is sokkal összetettebb. Rendszer példák A következôkben néhány "memória térképet" adunk meg a fentiek illusztrálására. Ez a memóriakép úgy adható meg, hogy vagy a ténylegesen rendelkezésre álló fizikai memória beosztását adjuk meg, vagy a virtuális memóriát mutatjuk be. Ezeket is általában három idôpontban vizsgálhatjuk Megadjuk • a virtuálisan címezhetô terület tartalmát akkor, amikor egy felhasználói program fut, • a virtuálisan címezhetô terület tartalmát, amikor az OR fut, • a fizikailag rendelkezésre álló memória felosztását. CP/M Mivel a CP/M nem használ speciális memória térképet, a CPU által címezhetõ terület mindig rendelkezésre áll az operatív memóriában, ezért a virtuális és a fizikai 28 memória kezelés azonos. A CP/M által kezelhetô memória mérete maximum 64K byte. 64 Kbyte BIOS BDOS 54 Kbyte CCP Felhasználói programok és adatok 256 byte

Ellenőrzési terület 0 3.1 Ábra A fizikai memória kiosztása CP/M alatt Két rezidens komponens helyezkedik el a memória felsô részében: a BIOS a legfelsô részben, közvetlen alatta a BDOS. A BIOS mérete változhat, de e kettô együttesen kb 10 Kbyte-t foglal le. Ehhez a részhez tartozik még egy kisméretû verem (stack) terület, amelyet az OR használ fel. (Ha egy felhasználói programnak szüksége van nagyobb verem-területre, akkor ezt a rendelkezésére álló területen önmagának kell biztosítania.) A fenti területek mellett a legalsó 256 Kbyte az a terület, amely a rendszeradatok és a különbözô pufferek rendelkezésére áll. Ide tartozik az aktuális parancs sor, a különbözô visszatérési címek, az indítási címek stb. A CCP tranziens része az OR-nek, és így csak akkor töltôdik be, ha szükség van rá. Helye a BDOS alatt van, helyigénye 2Kbyte, legalacsonyabb betöltési címe 100.A legtöbb felhasználói programot a tranziens

terület alsó felére töltjük be a 256-os címtôl kezdôdôen. Elvileg a teljes tranziens terület a felhasználói programok rendelkezésére áll. Ha egy felhasználói programnak szüksége van a CCP által elfoglalt területre, akkor azt felhasználhatja. Ebben az esetben a lerombolt CCP-t ismét be kell tölteni. MS-DOS Az elsô MS-DOS rendszerek az INTEL 8086-os mikroprocesszorára épültek. Ennek a processzornak olyan a felépítése, hogy 64Kbyte-t tud megcímezni. Mivel a maximálisan rendelkezésre álló memória 1 Mbyte lehet, ezért a processzor 64K-s blokkokra osztva kezeli a 29 memóriát. Így a vizsgálatunknál két állapotot kell ismernünk: a.) A fizikailag rendelkezésre álló memória felosztása: Az IBM PC-n a magasabb memóritarületeket a video memória és a ROM-ban tárolt rendszerprogramok foglalják el. Az OR a parancs interpreter egy részével együtt rezidensként a memóriában marad. A parancs kezelô (command hander) tranziens része a

rendelkezésre álló szabad terület legmagasabb címére kerül betöltésre. Mivel ez tranziens rész, azért a felhasználói programokkal bármikor felülírható. A felhasználói programok részére kb 600 Kbyte áll rendelkezésre. A 8086-os felépítése miatt egy adott idôpontban a rendszer csak 64 Kbyte-t "lát" külön-külön a programból, az adatokból és a felhasználói veremmemóriából. (A gyakorlatban az adatokat és a veremmemóriát a rendszer egy közös területen kezeli.) A programterület elsô 256 byte-ja a kommunikációs terület számára tartja fönn a rendszer, ezért a programok 256-tól kezdôdnek. Ez a meggondolás azt eredményezi, hogy a legtöbb MS-DOS rendszerben megírt program kompatibilis a CP/M rendszer gépeivel. 64 K BIOS és egyéb ROM Felhasználói veremterület k Video & grafikus memória 640 K Tranziens parancs kezelő Felhasználói adatok Felhasználói veremterület 0 Felhasználói adatok 64 K

Felhasználói program Felhasználói program Rezidens OR. terület 1536 256 Kommunikációs terület 0 Kommunikációs terület 0 Fizikai tárfelosztás 3.2 Ábra Virtuális tárfelosztás A memória kiosztás MS-DOS OR-alatt UNIX A UNIX OR esetében nincs értelme annak, hogy a fizikai memória felosztását szemléltessük. A rendszer ugyanis a memória címzést swapping és egyéb virtuális memória 30 technikák felhasználásával oldja meg. Ennek az a lényege, hogy mindig csak annyi információt tart a fôtárban, amennyire szüksége van, minden mást háttértárolókon ôriz. Így a fizikailag rendelkezésre álló memória tartalma gyorsan változik. A felhasználói programok által elérhetô (virtuális) memóriát program-, adat- és veremterületekre oszthatjuk. Veremterület Adatterület Rezidens OR Programterület 0 0 Virtuális folyamatkezelés Virtuális rendszerkezelés 3.3 ábra Virtuális tárkezelés UNIX OR-ben Ilyenkor az OR és az

általa kezelt adatok egyáltalán nem látszanak. Annak ellenére, hogy a UNIX támogatja a többprogramos felhasználást, a legtöbb UNIX verzióban nincs közös memóriterület a különbözô futó folyamatok száma. Ez azt jelenti, hogy az elkülönített futó programoknak nincs közös kommunikációs területük. A rendszer parancskezelô programja ugyanolyan feltételek között mûködik, mint bármely másik felhasználói program. Az OR rezidens része által látott memóriaterület olyan nagy, amilyen maga a kernel. A kernelbe tartozó összes forrásmodult ugyanis egy monolitikus tömbbe szerkesztjük és így kerül betöltésre. (A mérete gyakran 2-300000 byte is lehet.) A kernelben található eljárások akkor aktivizálódnak, amikor a felhasználói programok hívják a rendszernek ezt a részét, vagy ha valamilyen megszakítás történik. VAX/VMS Hasonlóan a UNIX rendszerhez a dinamikusan változó fizikai memóriafelosztás bemutatásának itt sincs

értelme. A memóriakezelés a VAX/VMS esetében is swapping és virtuális memóriakezelô technikákkal történik. A VAX gépek felépítésében 4 Gigabyte áll rendelkezésre, amelyet az OR 4 olyan részre oszt be, amelyeket teljesen függetlenül kezel: egy részt a felhasználói programok és az azokhoz 31 tartozó adatok foglalnak le, egy rész a rendszer ellenôrzô adatainak és az azokhoz tartozó adatst ruktúráknak van fenntartva, egy részt pedig maga az OR használ. Normális körülmények között a negyedik részt a rendszer nem használja. Az OR számára az egész címezhetô terület elérhetô, míg egy felhasználói program csak a maga területén levô címekre hivatkozhat. Felh. program és adatok Kontrol terület Operációs rendszer 3.5Ábra Virtuális memória felosztás VAX/VMS-ben OS/MVT Ez 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 között nem támogatja, amelynek

az a következménye, hogy a címzési területek azonosak. A maximálisan címezhetô terület 16 Mbyte, egy jellegzetes installáló azonban kb. 2Mbyte-t foglal el. Tranziens terület Task 2. Task 1. Rendszer kontroll Tranziens terület Nuclues 3.6 Ábra Memória felosztás OS/MVT-ben Az egy taskon belül futó program számára az egész memória terület (2 Mbyte) látszik, azonban abban az esetben, amikor a rendelkezésére álló területen kívül akar írni (vagy olvasni), akkor egy egyszerû memóriavédelem elôzi meg a nem kívánt memóriamûveleteket. 32 Az OS/MFT felépítése teljesen hasonló felépítéséhez, az egyetlen eltérés az, hogy méretét nem lehet változtatni. az MVT a taskok 3.3 Végrehejtá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 vagy egyszerû programhívások (rendszerhívások) vagy megszakítások. Egy OR rendszerbeli program vagy

úgy fejezôdik be, hogy teljesen végrehajtja a feladatát, vagy bizonyos részfeladatok végrehjatására visszatér késôbb. Az is elôfordulhat, hogy önmaga vezérel más egységeket. Az OR programjainak legnagyobb része olyan elôjogokkal rendelkezik, amelyektôl az egyszerû felhasználói programok el vannak tiltva: rendszer regiszterekbe férhetnek hozzá, elérhetnek olyan memóriterületeket, amelybe más programok nem. Ebben a részben áttekintjük azokat a végrehajtási struktúrákat, amelyek a fejlôdés során kialakultak. 3.31 Klasszikus szervezés Az OR-k tradicionális szervezésében 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 un. rendszerhívásokkal vagy egyéb speciális kívánságokkal (pl. megszakítás) aktivizáljuk. Egy rendszerhívás abban különbözik egy "normális" szubrutinhívástól, hogy az

elôjogok szintjét megemeli, és a program a futás idejére áthelyezôdik a memória elôre meghatározott részére, ahol teljes kontroll alatt fut. Az elôjogok megnövelése lehetôséget ad az OR rutinok számára arra, hogy regisztereket érjenek el, és memóriterületekhez férjenek hozzá. A legtöbb OR 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ûveltet, 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 un. megszakítások generálódnak (I/O, túlcsordulás stb.) 33 Ilyenkor a CPU megállítja azt a programot, amelyet éppen futtat, és beindít egy olyan programot, amely kezeli a fellépett megszakítást. A megszakítás

kezelô program feladata az, hogy ha szükséges megváltoztasson néhány adatstruktúrát, majd eldöntse azt, hogy a felfüggesztett program futása folytatható vagy sem. A klasszikus OR-k nagy része használja a fenti struktúra valamilyen változatát a szubrutinjainak végrehajtására. Az olyan egyszerû OR-k, mint pl a CP/M azonban nem használnak megszakítást mielôtt visszaadják a vezérlést a felhasználói programnak. Ez számos elônnyel jár, azonban nehézségek léphetnek fel a konkurens kívánságok kezelésekor. 3.32 Rendszer eljárások alkalmazása Az OR-k egy részénél 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 eljárás lehet egy output küldése nyomtatóra, a képernyô kommunikációs sorának figyelése vagy többtaskos rendszerek esetén a taskok idôszakos átvizsgálása. Ezeknek a tevékenységeknek a

nagy része semmilyen speciális technikát nem igényel, és így ugyanúgy kezelhetô, mint egy felhasználói program. Az ilyen eljárásokat rendszer eljárásoknak nevezzük. Egy rendszer eljárás OR szolgáltatásokat nyújt, de úgy kezeljük, mint egy felhasználói eljárást. Az együttes kezelés mellett azonban bizonyos eltérések is jelentkeznek. A rendszer eljárásoknak ugyanis magasabb prioritása lehet, védve lehet a swappingtôl. A rendszer eljárások alkalmazása csökkentheti az OR tervezése során fellépô hibákat azáltal, hogy a sok OR tevékenység szisztematikusabban kezelhetô, és így növelhetô a megbízhatóság. Az ilyen eljárásoknak ugyanis nincs szükségük felesleges elôjogokra, és az esetleg fellépô hibák nem okozhatnak "rendszerroncsolást". A UNIX és a VMS jó példák az ilyen OR-ekre. 3.33 Nyitott környezetek Amint azt az elôzô pontokban láttuk, 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 nem csak a különbözô elôjogokban mutatkozik meg, hanem abban is, hogy az OR programok olyan helyen töltôdnek be a memóriába, amelyek a felhasználói programok számára elérhetetlenek. 34 Ez a fajta szétválasztás egy többfelhasználós rendszer esetén teljesen indokolt: egy hibásan mûködô felhasználói program nem csak az OR-t rombolná le, hanem helyrehozhatatlan károkat idézne elô a többi futó programban is. Egyfelhasználós rendszereknél azonban nem szükségszerû Ezért született meg egy alternatív kezelési mód, amelyben az OR programjait úgy tekintjük, mint eljárások összességét, és nem különböztetjük meg ezeket az egyéb felhasználói programoktól. Egy ilyen rendszer kezelése nagyon egyszerû: a felhasználó szabadon ad hozzá illetve vesz el eljárásokat a rendszer elemeibôl attól függôen, hogy milyen részeket tart szükségesnek arra, hogy azokat a rendszer

részeként kezelje. Ezt a közelítést nyitott rendszernek nevezzük. Az eljárást a leggyakrabban egyszerû miniszámítógépeken használják. Az utóbbi idôben erôteljesen terjed a munkaállomásokon is. (pl: Apple Macintosh). 3.4 Komponensek interakciója Az OR-k esetében a különbözô eljárások hívhatók más eljárások által, adatokat kaphatnak másik programoktól és adatokat is adhatnak át. Egy korlátok nélküli megközelítés a legtöbb esetben a legegyszerûbb OR-tôl eltekintve a rendszer megbízhatatlanságához vezethet. Ilyenkor ugyanis nagyon nehéz egy módosítás hatásait megjósolni, hiszen szinte lehetetlen behatárolni a rendszer azon részeit, amelyre a módosítást hatást gyakorolhat. Ezért a nagyobb rendszereknél az egyes részek interakcióját szabályozzák. Ez megkezdôdik a dokumentáció kidolgozásakor és nagyon sok esetben maga a számítógép is támogatja ezt. (Magas szintû programnyel-vek esetében a részekre bontás

egyszerûbb, mert maga a compiler is szûkíti a hozzáféréseket.) A következôkben az interakció kezelésének leggyakrabban elterjedt változatait mutatjuk be. a,) Korlát nélküli interakció. A korai OR-k épültek ilyen elvekre. Ezeket a rendszereket többnyire assemblerben írták és a tárterület együttes kezelése még megoldható volt. Kis rendszereknél ez a módszer ma is használatos (pl: CP/M). b,) Modulok elkülönítése. Ez a módszer akkor vált népszerûvé, amikor az elsô magas szintû nyelveken megírt OR-k megjelentek. A MULTICS vagy a VAX/VMS esetében a 35 modulokat aszerint osztották csoportokba, hogy milyen fô funkciót támogatnak. Az egyes funkciókhoz tartozó adatstruktúrákat aztán csak azok a modulok érhették el, amelyek ehhez a csoporthoz tartoztak. c,) Absztrakt gépek. Ezzel a technikával az OR-t különbözô szintekre osztják. Minden szintet úgy építenek fel, hogy csak az elôzô szint "eredményeit" használhassa.

Így minden szint új lehetôségeket biztosít egy nagyobb hatékonyságú absztrakt gép definiálásával. A koncepciót gyakran ábrázolják egy un. "hagyma -diagrammal", ahol az új szintek kör-körösen veszik körül a központi pozicióban elhelyezkedô kernelt. Az egyes szintekhez tartozó függvények kijelölése nagyon változó lehet. Nincs általános szabály, azonban az világos, hogy olyan kritikus pontok, mint a processzok vezérlése, a memória kezelése, a tárvédelem mindenképpen olyan magasabb szintû eljárások alá kell, hogy kerüljenek, mint a file-szervezés vagy a felhasználói-interface. A következô ábrán egy lehetséges közelitést mutatunk be: 0. szint: 1. szint: 2. szint: 3. szint: 4. szint: 5. szint: Eljárások vezérlése, megszakítások kezelése Virtuális memória kezelés Felhasználói konzol (User interface) I/O kezelés kezelése Felhasználói programok Az operátor 3.8 Ábra A THE-n definiált struktúra d,)

Virtuális gépek. Az absztrakt gépek egy speciális tipusa olyan számítógép architektúrán készíthetô el, amelyben a kiinduló lehetôségeket a rendelkezésre álló számítógép hardware-bôl nyerjük. Ezt a rendszert aztán time-sharing technika felhasználásával biztosítjuk minden felhasználó számára. A kiinduló absztrakt gépet szokás ebben az esetben virtuális gépnek is nevezni. Ha a környezet egy virtuális gép, akkor a felhasználó mindig egy "csupasz" géppel indul, és erre installálja a saját operációs rendszerét. Egy többfelhasználós rendszeren így 36 egyidejûleg különbözô operációs rendszerek futhatnak. Egy ilyen közelítés hasznos lehet abban az esetben, ha egy OR-t fejlesztünk, miközben a mûködô verzió alatt már felhasználói programokat futtathatunk. A virtuális gépek alkalmazásának hátránya, hogy az egyes felhasználók teljesen el vannak szigetelve egymástól. Virtuális gépeket implementálunk

az VM/370-es OR-rel az IBM/S370-es gépeken. 3.5 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észeit, 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 kell ehhez igazítani. Egy ilyen esetben nagyon kellemetlen lenne, ha az egész rendszert újra kellene fordítani, ha egy egészen apró módosítást hajtottunk végre egy részrendszeren belül. Ezt elkerülendô, a rendszert részrendszerekre bontjuk. Az OR-k egy részénél az un. "blokk-építés" technikáját használjuk, amelynek során a felhasználó válogatja ki, hogy mely komponenseket akarja beépíteni a rendszerbe. A modulokat aztán külön-külön fordítjuk le, és ha valamelyikben változás van, akkor csak azt a modult kell újrafordítani. 37 4. A felhasználói interface Egy számítógépes rendszer

hatékonyságát nagy mértékben meghatározza, hogy hogyan képes kapcsolatot tartani a felhasználókkal. A kommunikáció két irányban valósul meg: egyrészt a felhasználó jelez a rendszernek, ha valamilyen szolgáltatást igényel, másrészt a rendszer küld információt a kért szolgáltatások teljesítésérôl. A kapcsolattartásnak is két módja ismert: • közvetlen kapcsolattartás során egy interaktív terminálon gépeljük le a parancsot, • közvetett igény során a programokból adjuk ki a szolgáltatást igénylô utasítást. Az OR-nek azt a komponensét, amely a kommunikáció kezeléséért felelôs felhasználói interface-nek nevezzük, és két fô részre osztható: • A parancs interface azáltal, hogy magasszintû kommunikációt biztosít a felhasználó és az OR között, irányítja a programok futását. (A név onnan ered, hogy a felhasználó parancsok sorozatával mondja meg az OR-nek, hogy milyen rendszer "cselekvést" vár

el.) • A program interface kezeli a futó programokat. Az OR ezen a részrendszeren keresztül tartja a kapcsolatot a programok és a rendszer által ellenôrzött erôforrások és szolgáltatások között. A felhasználói interface két komponense kapcsolatban van egymással. Így például magát a parancs interface-t is egy rendszerprogram segítségével implementáljuk. Ugyanakkor számos olyan OR létezik, amelyben a program interface rendelkezik azzal a lehetôséggel, hogy segítségül hívja a parancs interface-t. Ez lehetôséget ad a programoknak arra, hogy elôállítsanak egy parancsot, és azt átadják a parancs interface-nek további feldolgozásra. 38 4.1 A parancs interface Bármilyen formában is jelenik meg egy parancs interface, a gép-ember kapcsolat lebonyolításához mindig szükség van egy nyelvre. A felhasználói parancsokat a gép irányába egy Parancs Nyelv (Operating System Command Language = OSCL) közvetíti. Az OR által visszaadott

információt a Válasz Nyelv (Operating System Response Language = OSRL) segítségével fordítjuk le a felhasználó számára elfogadható formába. (Gyakran elôfordul, hogy ezt a két komponenst összevonják egyetlen nyelvvé). 4.11 A parancs nyelv A parancs interface-nek két tipusát különböztetjük meg. A.) Amennyiben az OR batch feldolgozást végez, akkor a parancs interface-t job-control nyelvként (JCL) implementáljuk. Egy ilyen nyelv segítségével a felhasználó programlépések sorozatát határozza meg egy teljes munka feldolgozásához. Egy job-control nyelv tipusú utasítás mindig arra koncentrál, hogy a teljes munka egy részére a szükséges erôforrások jellemzôit pontosan leírja. Az elsô job-control tipusú nyelvet az ATLAS parancs értelmezôjében használták fel, de a legismertebb ilyen nyelv az IBM 360-as sorozat OR-ében használt IBL JCL. A 4.1 ábrán egy olyan JCL részletet mutatunk be, amely egy FORTRAN program fordításához,

szerkesztéséhez és futtatásához igényelt erôforrások biztosítását igényli: // PROBA JOB (1023,20,47),LANE, // MSGLEVEL=2, PRTY=6, CLASS=B // COMP EXEC PGM=IEYFORT,PARM =SOURCE // DD SYSOUT=A SYSPRINT // SYSLIN DD DSNAME=SYSL,UT4,DISP=OLD // DCB=(RECFM=FB,LRECL=80, BLKSIZE=800) // SYSIN DD * . Forrásprogram kártyái . // GO // SYSPRINT EXEC DD PGM=FORTLINK,COND=(4,LT,C) SYSOUT=A 39 // SYSLIN DD DSNAME =*.COMPSYSLIN, DISP=OLD // SYSLIB DD DSNAME=SYSLIB.FORTLIB, DISP=OLD // DD SYSOUT=A, DCB= (RECFM=FA,BLKSIZE=133) FT03F001 // DD DSNAME=SYSIN FT05F001 // DD SYSOUT=A,DCB=(RECFM=A, BLKSIZE=133) FT06F001 // DD UNIT=SYSCP FT07F001 // DD * GO.SYSIN . A program adatkártyái . /* 4.1 Ábra Példa az IBM JCL utasításokra A parancsokat kártyákra lyukasztották, és a kártyacsomag feldolgozását végezték a parancs értelmezô segítségével. A példa JCL-t jól láthatóan részekre bontottuk. Minden olyan kártya, amely a // karakterpárral kezdôdik egy JCL

parancsot (vagy annak folytatását) jelenti. A programutasítások és az adatkártyák sohasem kezdôdhettek ezzel a két karakterrel. - A JOB utasítás paramétereket tartalmaz az egész munkára vonatkozóan. (pld: PRTY=6 a sürgôsséget jelenti a batch feldolgozás során). - A két EXEC utasítás a fordítás két fázisát végzi (ti: a fordítást és a szerkesztést). Ezeknél az utasításoknál a PGM= paraméterrel az indítandó programot nevezzük meg. - A DD utasítások a különbözô felhasználni kívánt adatállományokat specifikálja. Így pld a SYSPRINT mindig a rendszer outputját írja le, a SYSIN a program inputjára ad meg paramétereket (a "*" azt jelenti, hogy közvetlen a leíró kártya után következnek az input adatok), míg az FT-filek a FORTRAN program által felhasznált állományokat írja le. - a /* kártya mindig a JCL kártyasorozat végét jelzi. B.) Az interaktív feldolgozásban használt parancs interface-ket közösen

interaktív parancs nyelvnek nevezzük. Ezeknek különbözô tipusait ismerjük: - A stream-orientált nyelv a legelôször alkalmazott parancs nyelv. Itt parancsokat és üzeneteket dolgozunk fel soronként. Az ilyen tipusú nyelv jólismert, hiszen 40 mind a CP/M, mind az MS-DOS ilyen tipusú. A 42 egy MSDOS tipusú "beszélgetést" mutat be (Az ábrán a "$" jelöli az un. "promt" jelet, amelynek megjelenése a képernyôn azt jelenti, hogy az OR kész a parancsok fogadására.) $ DIR CICA LINUX [DIR] [DIR] $ CD CICA $ DIR [.] 93-11-09 18.2 93-12-01 7 18.2 1 [.] INDEXED 4.2 Ábra Egy stream orientált parancsnyelv dialógusa A parancs nyelvek erôsen kötött szintaktikus szabályokat elégítenek ki. A stream-orientált nyelvek esetében a parancsot parancs sorban írjuk le. Minden parancs sor egy egyszavas paranccsal kezdôdik, amely azonosítja az alkalmazni kívánt mûveletet. A parancs szavait parancs argumentumok követhetik, amelyek

a végrehajtatni kívánt mûvelet pontosítására szolgálnak. Néhány esetben a parancs sor RUN programnév (argumentumok) alakú, míg máskor a "rövidített" formát használjuk, amikor elhagyjuk a RUN kulcsszót, és maga a programnév helyettesíti a "klasszikus" szubrutinhívó utasítást. - A képernyô orientált parancs interface-k másik - nem túl gyakran használt - csoportját képezik a menü vezérelt rendszerek. Ilyenkor a felhasználó a rendszer által felkínált lehetôségek közül választhat. A módszer kezdô felhasználók esetén lehet hasznos, hiszen ilyenkor a felhasználónak nem kell emlékezni kulcsszavakra. Hátránya az, hogy a korlátozott lehetôségek miatt túl gyakran kell menüpontot a képernyôn megjeleníteni, és a felhasználható paraméterek száma is korlátozott. A 43 ábra egy tipikus menü-vezérelt rendszer egy lehetséges képernyôjét mutatja. 41 VÁLASZTHATÓ FUNKCIÓK 1. FORTRAN program fordítása

2. Pascal program fordítása 3. C program fordítása 4. File kezelések 5. Terminál emuláció 6. Nyomtatás 7. Felhasználói programok Válasszon egy számot (? = HELP) 4.3 Ábra Menü vezérelt parancsnyelv - A munkaállomások elterjedésével egyre népszerûbbé váltak a nagy felbontású grafikus képernyôt igénylô ikonvezérelt rendszerek (ikonnak nevezünk minden stilizált ábrát, amelynek segítségével az OR egyes funkciói kiválaszthatók). Ez a tipus a menüvezérlés egy speciális formája. A rendszert a Xerox Altonál használták elôször Ma egyre inkább terjed és véleményünk szerint hamarosan felváltja az egyéb parancs nyelveket. Egyik legelterjedtebb formája ma a Windows rendszer. Annak ellenére, hogy a rendszertôl megkívánt szolgáltatások nagymértékben függenek a környezettôl, vannak olyan parancstipusok, amelyek minden parancs nyelvben szerepelnek. Ezek a következôk: • • • • Egy könyvtár elemeinek képernyôre írása.

Állományok másolása, átnevezése, törlése. Szövegszerkesztô programok futtatása. Különbözô nyelveken megírt programok fordítása, szerkesztése. • Információk kiírása a rendszerrôl és a felhasználói környezettôl. A fentiek bemutatására nézzük meg, hogy miképpen lehet átnevezni egy állományt különbözô OR-kben: 42 IBM JCL: // RENAME EXEC PGM=IEHPROGM // SYSPRINT DD SYSOUT=A // SYS1 DD UNIT=3330, VOL=SER=SYS001 // VOL1 DD DISP =OLD, UNIT=3300, VOL=SER=ABC123 // SYSIN DD * RENAME DSNAME=réginév, VOL=SER=ABC123, NEWNAME=újnév / * VMS: RENAME /OLDNAME=réginév /NEWNAME=újnév CP/M: REN újnév MS/DOS: RENAME UNIX : mv réginév réginév újnév réginév újnév Miként azt fentebb jeleztük, azért, hogy egy parancsot a megfelelô módon hajtsunk végre, ki lehet egészíteni különbözô paraméterekkel (argumentumokkal). Ezeknek két tipusát különböztetjük meg: - pozicionális paraméterekrôl akkor beszélünk, ha azokat

úgy soroljuk fel egymás után, hogy a jelentésüket egyértelmûen meghatározza a sorban elfoglalt helyük. (Lásd az átnevezési parancs a CP/M-ben, az MS-DOS-ban vagy a UNIX-ban. kulcsszavas paraméterek esetében a paramétert a speciális név segítségével határozzuk meg. Ilyen esetben a kulcsszót vagy követi egy szöveges információ vagy nem. (Lásd az átnevezési parancs a VMS vagy az IBM JCL nyelvekben.) Ha egy parancsot pontosan akarunk leírni, elôfordulhat, hogy hosszú szavakat kell használnunk. Ez megnehezítheti az OR hatékony használatát. Ezért számos OR megengedi, hogy rövidítéseket használjunk a parancs-szavakra. Erre két lehetôség állhat rendelkezésre: vagy elôírja az OR, hogy milyen rövidítést fogad el (pl. ed az edit helyett) vagy elfogad minden rövidítést amelybôl a parancs kezelô (command handler) egyértelmûen meg tudja határozni a végrehajtandó parancsot. (A VAX/VMS OR elfogadja a dir, 44 dire vagy a direct

rövidítéséket is, de a di rövidítés már nem egyértelmû.) A rövidített parancsok megengedése azt feltételezi, hogy a felhasználó ismeri a rendelkezésére álló parancsok döntô többségét. Így gyakran elôfordulhat, hogy hosszan tartó keresés elôzi meg, egy parancs helyes leírását. Egy másik technika, amelyet a rövidítés mellett használnak az un. parancs kiegészítés Ennek az a lényege, hogy néhány karakter leírása után egy speciális karakter lenyomásával jelezzük az OR számára, hogy befejeztük a parancsszó begépelését (Ez a kontrol karakter lehet pl. az ESC) Válaszként a számítógép kiírja a szóba jöhetô parancsokat, ha a beírt karaktersorozat nem egyértelmû. Ezt a fajta parancs kezelést a TENEX OR-rel vezették be , és ma sok UNIX shell használja. A rövidítések néhány fajtája az állomány nevekre vonatkozik. Ezt a fajta technikát szabad hely (wild card) kijelölésnek nevezzük. Tipikusan használt karakter

erre a feladatra a *. Ebben a jelentésben a speciális karakter helyébe helyettesít a rendszer minden karaktersorozatot, amely ide "illik" (beleértve az üres sorozatot is). Ha egy könyvtár elemei között megtaláljuk a prog1.exe prog2.exe par1.exe prot1exe pexe par2.exe prot2exe állományokat, akkor MS-DOS-ban a dir p*.exe utasítás hatására az összes listázásra kerül, míg a dir fent felsorolt állomány prog*.exe hatására csak az elsô oszlop elemei kerülnek a képernyôre. Egyes utasítások elhamarkodott végrehajtása visszafordíthatatlan hibát eredményezhet a tárolt állományokban. Néhány OR ezért ezeket az utasításokat csak kikényszerítve (force) hajtja végre másoknál a hiba könnyen elkövethetô: a CP/M OR-ben az ERA *.* 45 utasítás hatására egy könyvtár minden állománya azonnal kitörölhetô, míg a hasonló MS-DOS utasításnál a del *.* csak az "ARE YOU SURE?(Y/N)" visszaigazolása után lesz

végrehajtva. (Megjegyezzük, hogy az MS-DOS-ban egyetlen állomány kitörlését nem elôzi meg ilyen kérdés.) 4.12 Válasz nyelvek Miként azt a bevezetôben leírtuk a rendszer válasz nyelve egy olyan nyelv, amelynek segítségével az OR információt szolgáltat a felhasználó számára. Ezek az információk a legkülönfélébbek lehetnek. A következôkben felsoroljuk a leggyakrabban használtakat: • Promt üzenet. Ez jelzi a felhasználónak azt, hogy az OR utasításra vagy információra várakozik. Egy ilyen üzenet híján a felhasználó nem tudná ellenôrizni a rendszer pillanatnyi állapotát. • Kisegítô (help) üzenetek látják el olyan információkkal a felhasználót, hogy mit kell tennie egy adott helyzetben. • Elôrehaladási üzenetek. Ha egy hosszan tartó munkafolyamatot végez a gép, akkor idôszakonként tudatnia kell a felhasználóval, hogy hol tart a munkában. Egy ilyen üzenet nem csak az elôrehaladást mutatja, hanem lehetôséget

nyújt arra is, hogy a felhasználó megkerülje a folyamat teljes befejezéséhez szükséges idôt is. • Befejezést jelzô üzenetek egy futó rendszer aktivitás végét közlik a felhasználókkal. Ha egy folyamat hibásan ér véget, akkor hibaüzenetet kaphatunk, így ezeket is ebbe a csoportba soroljuk. 4.13 Parancs állományok Számos parancs interface rendelkezik azzal a lehetôséggel, hogy képes parancsokat olvasni állományokból is. Az állományok elnevezése változó: pl a CP/M-ben "submit-file"-nak, UNIX-ban "shell"-nek nevezzük ezeket. Általánosan parancs-állomány-ként fogunk rájuk hivatkozni. 46 Ennek a technikának az a lényege, hogy annak az állománynak a nevét, amelyben a parancsokat tároltuk, úgy használhatjuk, mint egy parancs-nevet. Az egyszerûség kedvéért kezelhetjük ezeket az állományokat úgy, mint egy batch-file-t, azonban egy jól tervezett parancs-inteface esetén egy ilyen állomány sokkal hatékonyabb

eszköz lehet a programozó kezében: az állományban elhelyezkedô parancsok képesek arra, hogy az inputjukat vagy egy terminálról vagy magából az állományból olvassák be. A parancsok outputjai ugyanígy szabadon irányíthatók. A teljesség igénye nélkül még megemlítünk néhány olyan további lehetôséget, amellyel egy hatékony parancsállománynak rendelkeznie kell: • A standard parancsokhoz hasonlóan argumentumokkal kell rendelkeznünk. • Meg kell engedni a lehetôséget arra, hogy egymásba ágyazva újabb parancsállomá-nyokat hívhassunk az állomámányon belül. • Dokumentációs céllal szöveget lehessen írni az állományon belül. • Hiba esetén biztosítani kell a lehetôséget arra, hogy a felhasználó közbeavat-kozhasson, és ennek eredményeként a parancs állomány "utasításait" egy megha-tározott ponttól ismét feldolgozhassuk. 4.14 Szûrôk Néhány OR-ben egyes parancsok bizonyos argumentumok hatására úgy

mûködnek, hogy képesek egy adatállományt beolvasni és egy olyan állományt létrehozni, amely a beolvasott rekordoknak csak egy részét tartalmazza. ezeket a parancsokat szokták szûrônek is nevezni. A szûrôk fontos szerepet játszanak a UNIX filozófiájában. Ez a technika hatékonyan illeszkedik az összefûzés részben ismert kommunikációs struktúrához. (Ez a módszer megengedi azt, hogy egy parancs outputja közvetlen inputként szolgáljon egy következô parancs számára anélkül, hogy külön megneveznénk és eltárolnánk azt.) A fenti elônyök mellett a szûrôk használatának megvannak a hátrányaik is: ezek a parancsok az inputot egy egyszerû input-streambôl várják, és a létrehozott output is nélkülöz minden "extra" információt. Így a filtereket nem célszerû önmagukban futtatni egy terminálon. 4.2 A program interface 47 A program interface (PI) feladata az, hogy egy futó program számára szolgáltatásokat nyújtson,

és kommunikáljon velük. Nem csak a felhasználói programok használják, hanem gyakran maga az OR is igénybe veszi az általa nyújtott szolgáltatásokat. A PI végigkíséri a programokat a végrehajtásuk során, hiszen: • Felelôs a programok betöltéséért. • A program futása alatt a PI fogadja a rendszer különbözô szolgáltatásaira és az erôforrások igénybevételére vonatkozó igényeket, és a megfelelô helyre (ti. az erôforrás kezelôhöz) továbbítja azokat. • A programok befejezésekor figyeli, hogy azok szabályosan fejezôdtek-e be, vagy hibakódot kell kiadnia. A fejezet hátrelévô részében tárgyaljuk részletesebben. ezeket a feladatokat 4.21 A programok betöltése Az egyfelhasználós rendszereknél ennek a feladatnak a megoldása a loader-ra vár. A legegyszerûbb OR-k esetében a loader rezidensként állandóan a memóriában tartózkodik, a futtatandó programot egy háttértárolóból tölti be a memória egy rögzített

részébe, amely a programok tárolására van fenntartva. Ilyenkor a háttértárban lévô program pontos másolata kerül a memóriába. (azaz a program már "futáskész" állapotba kerül a fordítás során. Általánosabban használt megoldás az, amikor a betöltendô program nem változtatás nélkül kerül a memóriába, és memóriába kerülés helye is változik. Ebben az esetben a loader hajtja végre az "áthelyezést" (relocation), és az ô feladatai közé tartozik az adatterület beállítása is. Ebben az esetben elôfordulhat, hogy maga a loader is bonyolultabb, a tranziens területen helyezkedik el, és csak akkor kerül a memóriába, amikor szükség van rá. A felsorolt feladatokat a loader nem egyedül hajtja végre, hanem együttmûködik az OR más részeivel: a job szervezôvel és a társzervezôvel. Ezek a modulok azonosítják a futtatásra kijelölt programot, hozzárendelik a szükséges memóriát, és meghívják a betöltô

programot, hogy hajtsa végre az inicializálást. Az OR társzervezô része felelôs a futás alatt bekövetkezô mozgatások és felfüggesztések kezeléséért. 48 4.22 Rendszer szolgáltatások Ha egy programnak szüksége van valamilyen rendszerszolgáltatásra a futásideje alatt, akkor azokat rendszerhívások segítségével oldja meg. Ez az eljáráshívásnak egy olyan speciális fajtája, amelyet egy különálló gépi utasítással oldanak meg. Ennek az utasításnak az a különlegessége, hogy amellett, hogy az OR alprogramjainak hatékony hívását teszi lehetôvé egy speciális kapcsolót is beállít. Ezáltal a program a rendszer hívásokat másként kezeli, mint az egyszerû szubrutin hívásokat. (Mivel a rendszer hívások végrehajtása speciális gépi kódú utasítással történik, azért ezek kizárólag csak assembly nyelven írt programokból érhetô el. Ez magas szintû nyelven írt programok esetében gondot okozhat. Ilyenkor a

rendszerhívásokat könyvtári szubrutinok segítségével oldják meg. A futó program által igényelt rendszer szolgáltatások egy része az erôforrások igénybevételére irányul. (I/O mûvelet különbözô készülékekben, állományok elérése vagy feldolgozása.) Más rendszerhívások arra szolgálnak, hogy elôkészítsék az erôforrás késôbbi felhasználását. Ilyen lehet egy állomány megnyitása vagy egy memória terület igénylése késôbbi felhasználásra. A rendszer hívások maradék része felvilágosítást kér a rendszer állapotáról. (dátum, idôpont, vagy egy-egy végrehajtás alatt álló mûvelet aktuális állapota) A program futása alatt igénybe vehetô rendszer szolgáltatások fôbb tipusait az alábbiakban soroljuk fel. Részletes leírást csak a felhasználói interface-rôl adunk itt, mert a jegyzet további fejezetei éppen az itt felsorolt funkciókat tárgyalják. • Felhasználói interface. Ez a funkció biztosítja a program

számára a környezetrôl szóló információkat: a forrásokat a korlátaikkal, a standard I/O csatornákat, a parancsnyelv változóinak aktuális értékét stb. Néhány OR megengedi azt, hogy a programba beépítsünk parancs sorokat, amelyeket majd a parancs interpreterrel fogunk feldolgozni. (RT-11) Bár a UNIX nem engedi meg a shell közvetlen hívását, ez mégis megoldható azáltal, hogy lehetôsége van minden felhasználónak "saját" shellprogram elôállítására, amelyek az "eredetivel" egyenrangúak, és amelyek hívása már egyszerûen elvégezhetô. 49 • Programok szervezése. Az OR-nek ez a szolgáltatása végzi többfelhasználós rendszerek esetében az egyidôben futó programok menedzselését, az azok közötti információcsere szervezését. • Készülékek szervezése. Elsôdleges feladata az I/O készülékek fizikai kezelése figyelembe véve azok strukturáját. Az OR-nek ez a része felelôs az esetleges távoli

rendszerekkel való kapcsolattartásért is. • Idô szervezés. Az aktuális idôparamétereket biztosítja, a timerek munkáját szervezi és kézben tartja az ezekkel kapcsolatos tevékenységeket. • Memória szervezés. A memória dinamikus kiosztását végzi, és hozzáférhetôvé teszi a memória statusz információkat. • File szervezés. Az állományok elérését biztosítja Néhány rendszernél, ahol az I/O készülékeket is állományként kezeljük, ezek elérését is ez a funkció látja el. • Rendszer szervezés. Az OR teljes ellenôrzésére vonatkozó rendszer tevékenységet ellenôrzi és az ehhez rendelt rendszerkonstansok beállítását végzi el. Néhány példa az ide tartozó tevékenységek közül: ütemezések ellenôrzése, a belsô óra beállítása, új erôforrások hozzácsatolása a rendszerhez, erôforrások eltávolítása a rendszerbôl, hatékonyság felügyelet, felhasználói rekordok kezelésének segítése. • Egyéb

kategóriák. A fenti kategóriákba nem sorolható rendszerhívásokkal soroljuk ide. Néhány példa: felhasználói programok kezdeti értékeinek beállítása, befejezésekor a megfelelô "visszatérési értékek" feltöltése, I/O készülékek tipusainak kezelése, stb. 50 5. Folyamatok szervezése Egy számítógépes rendszer legfôbb feladata az, hogy hatékony munkát biztosítson a rendszer használói számára. Ezt azáltal teheti meg, hogy végrehajtja a felhasználói programokat. Azokat a tevékenységeket, amelyeket egy program végrehajt folyamatoknak (processzeknek) nevezzük. Ha egy program szubrutinjait, rendszerhívásait önálló programoknak képzeljük el, akkor egy folyamat nem más, mint egy végrehajtás alatt lévô program. (Megjegyezzük, hogy a folyamat egy aktív fogalom; attól, hogy egy programot betöltünk a memóriába, az még nem válik folyamattá.) A program beindításával keletkezô folyamat azonban nincs állandóan

végrehajtás alatt, gyakran várakoznia kell, mert a számítógép egy másik tevékenységet hajt végre. Amikor a számítógépnek egy CPU-ja van, akkor a folyamatok egymás után hajtódnak végre. Ilyenkor szekvenciális foly amatokról beszélünk Ez a technika legjobban az egyfelhasználós rendszereknél figyelhetô meg: a folyamat úgy kezelhetô, mint tevékenységeknek egy olyan sorozata, amelyek egyesével kerülnek végrehajtásra. Multiprogramozás esetében azonban a számítógép erôforrásai egyidejûleg több folyamat között is felosztásra kerülhetnek, így elôfordulhat, hogy egy meghatározott idôpontban több folyamat is végrehajtás alatt van. Ilyenkor a folyamatokat közbeékeltnek nevezzük Ahhoz, hogy egy tevékenységet végrehajtsunk, mindig el kell indítani egy programot. Az azonban már nem igaz, hogy egy programnak mindig egyértelmûen egy tevékenység feleltethetô meg. Néhány OR esetén (pl VMS) egy folyamat egy egész sor programot

indíthat el, míg más esetekben (pl.UNIX) teljesen általános, hogy egyetlen program azonos idôben futó különbözô feladatok végrehajtására alkalmas folyamatot mûködtet. Ahhoz, hogy a tevékenységek jól szervezhetôk legyenek, azokat formálisan definiálni kell, és az OR-ben valamilyen módon reprezentálni kell. Bár a tevékenység fogalma nem adatjellegû, mégis az OR-ben egy adatstruktúrát rendelünk a tevékenységhez. Ezáltal könnyebben nyomon tudjuk követni a tevékenység státusát, és jobban tudjuk szervezni az egyes résztevékenységeit. A folyamathoz rendelt adsatstruktúrát folyamat ellen õrzõ blokk nak (process control block (PCB)-nek) nevezzük. Miközben végrehajtunk egy tevékenységet, az mindig felhasznál valamilyen erôforrást. Ezek egy része olyan, hogy mindig szükség van rájuk (CPU, központi memória), mások felhasználása 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 levô erôforrásra egy másik tevékenységnek is szüksége van, akkor annak várakoznia kell. (A fejezetben külön fogalkozunk a tevékenységek és az erôforrások egymásra hatásával.) Ennek az a következménye, hogy egy végrehajtás alatt lévô 46 tevékenység felváltva van futási ill. várakozási állapotba A várakozás különbözô okokból következhet be, és ez erôsen befolyásolja azt, hogy hogyan kezeljük a folyamatot. A fejezetben tárgyalni fogjuk azokat az állapotokat, amelyeket egy várakozó tevékenység kerülhet. Egy futó folyamat teljes egészében felhasználja a CPU regisztereit és más fizikai elemeit. Amikor várakozni kényszerül, akkor gondoskodni kell arról, hogy az itt elhelyezkedô információkat eltároljuk, majd az ismét aktívvá váló tevékenységhez tartozó - elôzôleg elmentett - adatokat vissza kell tölteni, hogy folytatni tudjuk a megszakított végrehajtást. Az

elmentett információt környezetnek (context) nevezzük, magát a mûveletet pedig kapcsolásnak. A kapcsolással az 54 pontban foglalkozunk A korai OR-k a folyamatoknak csak igen kis részét támogatták, így a ténylegesen fellépô interakciók kezelése nem okozott problémát. A mai rendszerekben a folyamatok csaknem teljesen szabadon állíthatók elô és szüntethetôk meg, így a kapcsolatoknak igen széles körét kell kezelni. A fejezet zárórészében azokkal a mûveletekkel foglakozunk, amelyeket az egyes tevékenységek elôállításakor ill. ellenôrzésekor végezhetünk. 5.1 A tevékenység leírása Amint azt már a bevezetôben említettük, a folyamatok jellemzôinek leírására a PCB-t használjuk. Ez tartalmaz minden olyan információt, amelyre szükségünk lehet a process követése során. A PCB mérete OR-enként változó lehet Bizonyos OR-k 80 byte-ban rögzítik a hosszát, míg másoknál (UNIX, VMS) ez néhány száz byte-ra is megnövekedhet. A

különbözôségek ellenére van néhány olyan információ, amelyet megtalálhatunk a legtöbb PCB-ben. Ezek közül a legjellemzôbbeket az alábbiakban soroljuk fel: • A folyamat neve, amelyet azonosításra használunk. Néhány rendszer megkülönböztet külsô nevet , amely karakteresen tárolt, és a felhasználókat segíti, valamint belsô nevet, amely többnyire egy egész, és az OR általi azonosítást könnyíti meg. • A foly amat állap ota, amely vagy egy direkt kód az állapot leírására, vagy pointer egy olyan struktúrára, amely az állapotot írja le. • A folyamat környezet egy olyan terület, amely a regiszterek tartalmának és egyéb információknak a tárolására szolgál. • A felh asznált m emória azt mondja meg, hogy mennyi helyet allokálhatunk a tevékenység számára, hol helyezkednek el a programkódok és az adatok. • A foly amat prioroitás azt írja le, hogy milyen relatív fontossága van a tevékenységnek a többiekhez

viszonyítva. Ezt akkor használja az OR, ha több folyamat várakozik egy erôforrásra, illetôleg, ha ütemeznie kell a folyamatokat. • A szükséges erôforrások leírása arról tájékoztat, hogy melyek azok az erôforrások, amelyeket éppen használunk, és bizonyos esetekben a jövôbeli igények megjelölésére is szolgál. 47 • Az összefüggések leírása olyan információk tárolására szolgál, amelyek a folyamatok közötti viszonyt írják le. Ezek az összefüggések többnyire azokra a tevékenységekre vonatkoznak, amelyeket a szóban forgó folyamat létrehozott. • Az elszám olási in formációk rögzítik az idôparamétereket, a felhasznált erôforrásokat, a folyamat "tulajdonosának" nevét, és minden olyan információt, amelyet egy késôbbi analízis során felhasználhatunk. 5.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. Ezeket különbözô szempontok szerint osztályozhatjuk Egy lehetséges bontás szerint megkülönböztetünk fizikai és logikai erôforrásokat. A fizikai erôforrások közé soroljuk a számítógép erôforrásként rendelkezésre álló olyan komponenseit, mint a központi tár, a különbözô háttértárolók, az I/O készülékek. Annak ellenére, hogy az állományok nem fizikailag létezô erôforrások, általában mégis ebbe a kategóriába soroljuk ôket, mert hosszú ideig állhatnak rendelkezésre, és megoszthatók a tevékenységek között, aminek az a következménye, hogy az OR-nek ellenôrizni kell a felhasználásukat. A logikai erôforrások közé azokat az információkat soroljuk, amelyek állományokban vagy a központi tárban helyezünk el. Ezeknek a közös tulajdonsága az, hogy sokkal rövidebb életûek, mint a fizikai erôforrások, és többnyire nem esnek az OR ellenôrzése alá. Ezeket csak akkor tekintjük erôforrásnak, ha a

folyamatok meg akarják ôket osztani egymás között. Egy másik szempont szerint megkülönböztethetünk ismételten felh asználható és megszûnô erôforrásokat . Az ismételten felhasználható erôforrásokat a felhasználó folyamat nem rombolja le, így azok továbbra is rendelkezésre állnak. Ugyanakkor az esetek legnagyobb részében ezek az erôforrások csak egy folyamat által használhatók egy adott idôpontban: a memória egy meghatározott része nem használható különbözô célokra ugyanabban az idôpontban, és ugyanazt a nyomtatót nem használhatjuk két lista kinyomtatására egyidejûleg. Az ilyen tipusú erôforrásokat sorosan ûjra felhasználhatónak nevezzü k. Ahhoz, hogy az erôforrásokat össze tudja hangolni, az OR mindig hozzárendeli azokat ahhoz a tevékenységhez, amely éppen igényli ôket. Ezt úgy végzi el, hogy minden erôforráshoz hozzárendel egy rekordot, amelyben többek között tárolja annak aktuális státusát is. (ti

"felhasználható" vagy "éppen hozzá van rendelve az X folyamathoz"), majd ennek a státusnak az állandó figyelésével egy olyan stratégiát kell kidolgoznia, amely a megfelelô idôben hozzárendeli ill. felszabadítja az erôforrásokat. Az ismételten felhasználható erôforrások másik csoportjába tartoznak az állományok. Ezek megoszthatók több tevékenység között is, ha azok ezt igénylik Ezek kezelése azonban teljesen megegyezik a korábbiakkal. Az újra fel nem használható erôforrásokat megszûnôknek nevezzük. Ezeket általában egy tevékenység hozza létre, majd miután egy másik tevékenység felhasználta ôket az OR lerombolja ezeket. Amikor ezeket az erôforrásokat 48 használni akarjuk, akkor az alkalmazandó stratégiának biztosítani kell azt, hogy a különbözô tevékenységek kölcsönösen kizárják ugyanannak az erôforrásnak a használatát. (Errôl a problémáról a jegyzet késôbbi fejezetben részletesen

beszélünk) Két olyan erôforrás van minden számítógépes rendszerben, amelyeket speciálisan kell kezelnünk: a CPU és a memória. Erre azért van szükség, mert az "általános" erôforrás tulajdonságoktól eltérõ jellemzôkkel rendelkeznek: • Közvetlen érjük el ôket, rendszerhívások nélkül. • Minden tevékenységnek szükségük van rájuk. Az elsô megfigyelés azért igaz mert a tevékenységek a CPU-t és a megcímzett memóriát használják fel a gépi utasítások végrehajtására. Az OR általában nem felügyel minden egyes használatot. Ahhoz, hogy a hibás felhasználást megelôzzük, olyan hatékony ellenôrzésre van szükség, amely magába foglaljaa a memória védelmét és a különbözô megszakításokat is. A második megfigyelés következménye az, hogy minden olyan tevékenység, amely nem tudja használni a CPU-t vagy nem áll a rendelkezésére megfelelô allokálható memória, kénytelen várakozni mindaddig, amíg ezek

felszabadulnak. A várakozó tevékenységek sorban állnak. Ha néhány közülük megkezdhetô, akkor el kell dönteni, hogy melyikük kerül elôször végrehajtásra. Ez az ütemezés feladata Számos ütemezési stratégia létezik, ezek közül néhány vizsgálatát a 6. fejezetben fogjuk elvégezni. A rendszerhez tartozó más erôforrások nem rendelkeznek a fenti tulajdonságokkal. Ezeket rendszerhívások segítségével hajtjuk végre. Néhány esetben az OR megkövetelheti, hogy az erôforrás használatát egy igénybejelentés elôzze meg. Ilyenkor az OR allokálja az erôforrást. Ha az allokáció elmarad, akkor az OR nem engedélyezi az erõforrás használatát, és a tevékenység várakozni kényszerül. Jellemzô ilyen a rendszer által ellenôrzött erôforrások a különbözô állományok (file) és az I/O készülékek. Ezeknek az erôforrásoknak a használata esetleges, ezért, amikor használatban vannak, akkor mindig hozzárendeli az OR ahhoz a

tevékenységhez, amely az allokációt igényelte. Az ütemezés problémája ezeknél az erôforrásoknál is fennáll. Ha csak néhány tevékenység várakozik az erôforrásokra, akkor az ütemezés viszonylag egyszerû. Ha a várakozó tevékenységek száma nagy és sok erôforrásunk van, akkor a hatékony kiosztás sokkal bonyolultabbá válik. Szélsôséges esetben felléphet az un. holtpont (deadlock) problémája, amikor egy erôforrás amelyre néhány tevékenység várakozik nem szabadítható fel, mert a tevékenység, amely ôt használja nem fejezhetô be, várakozik másik erôforrásra, amely szintén nem szabadítható fel. Ezzel a problémával részletesen foglalkozunk a 7 fejezetben A fentiekbôl kitûnik, hogy az OR egy rekordot állít elô egy várakozó (vagy aktív) tevékenység által kezelt minden egyes erôforrás számára. Egy ilyen rekord általában egy un. várakozási sorban (queue) helyezkedik el A sor az adatstruktúrák között az egyik

legfontosabb: a legtöbb esetben a legtermészetesebb formája a kapcsolt lista, de más elôállítási formák is léteznek: táblázatok vagy tömbök formájában is tárolhatók az elemei. Ha sorban tároljuk az elemeket, akkor a legelterjedtebb tipus az un "first in first out" (FIFO), de az OR-nél alkalmazott sorok esetében egyéb rendezések is 49 lehetségesek. Ez különösen igaz az ütemezéseknél használatos sorok esetében: egy tevékenység hozzáfûzéssel (linking) kerül a sorba. Az ütemezésnél használatos sorok esetében a PCB-ben egy mezôt tartunk fent, amely a hozzáfûzést biztosítja. Ilyenkor ebben a mezôben egy mutatót (pointer) helyezzük el, amely a sorban következô PCBre mutat: 0 PCB1 PCB2 5.1 Ábra Példa a PCB-n belüli mutatókra Fontos megjegyeznünk, hogy ilyen lista készül minden erôforráshoz és a végrehajtható tevékenységekre egyaránt. Ezt a technikát olyan esetekben használják, amikor a belépô elemek

viszonylag gyorsan cserélôdnek. A módszer hátránya az, hogy külön kulcsmezôt kell fenntartani a PCB-n belül. Abban az esetben, ha a sor elemei ritkábban cserélôdnek, akkor külön elemként tároljuk a mutatókat: 0 PCB1 PCB2 5.2 Ábra Példa a mutatók külön kezelésére 5.3 A tevékenységek állapotai A tevékenység állapotokat arra használjuk, hogy nyomon kövessük az egyes folyamatok aktuális státusát. Minden egyes idôpillanatban a tevékenység olyan 50 állapotok halmazának tekinthetô, amely az éppen folyó tevékenységet vagy a szükséges erôforrásokat reprezentálja. Egy aktív tevékenységnek két elsôdleges állapota lehetséges: vagy éppen végrehajtás alatt van vagy várakozik valamelyik erôforrásra. (A várakozás oka különbözô lehet: elôfordulhat, hogy egyszerûen csak egy jelre várunk valamelyik másik tevékenységtôl vagy egy I/O tevékenység befejezése miatt várakozunk) A fenti egyszerû osztályozást tovább

kell finomítanunk: láttuk, hogy a CPU kitüntetett helyzetben van az erôforrások között, hiszen használata minden tevékenység számára kötelezô. Ennek az a következménye, hogy a CPU-t "nem illik" kiosztani egyetlen olyan tevékenység számára sem, amely valamely másik erôforrásra is várakozik. Ezért meg kell különböztetnünk azokat a várakozó tevékenységeket, amelyek csak a CPU-t igénylik (ezek az un. felkészült (ready) folyamatok), és azokat amelyek más erôforrásokra vagy egyéb visszajelzésekre várnak. Ez utóbbiakra azt mondjuk, hogy blokkolt állapotban vannak. A fenti állapotok egymásba történô átmenetét az alábbiakban egy diagramm segítségével szemléltetjük. Az ábrán a körök jelentik az állapotokat, a nyilak a megengedett átmeneteket reprezentálják. 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 (running)

állapotba. Mindaddig ebben az állapotban marad, amíg a szükséges erôforrásokat a számára biztosítani tudjuk. Ha egy erôforrás nem áll a rendelkezésre vagy egy speciális tevékenységre kell várnia, akkor a folyamat átkerül a blokkolt állapotba, amelyikbôl akkor kerül ismét készenléti állapotba amikor az igényelt erôforrást a rendelkezésekre tudjuk bocsájtani. Az ábrán jelöltünk egy "pontozott" nyilat is, amely a timesharing rendszerek esetében felléphetô állapotváltást reprezentál: az ilyen rendszereknél a végrehajtás alatt lévô tevékenység felfüggeszthetô, ha a rendelkezésére bocsájtott "idôszelet" lejárt, vagy egy nagyobb prioritású tevékenység készenléti állapotba került. Ready Runnig Blokkolt 5.3 Ábra Folyamatok lehetséges alapállapotai Gyakori az az eset, hogy a blokkolt tevékenységekrôl leválasztunk egy csoportot: felfüggesztett-nek fogunk nevezni minden olyan folyamatot, amely hosszú

ideig tartó tevékenységre várakozik. Ezeket a tevékenységeket többnyire eltávolíthatjuk a memóriából és egy háttértárolón "parkoltatjuk" ôket. Amikor az igényelt erôforrás felszabadul, akkor a felfüggesztett tevékenység készenléti állapotba kerül, de 51 elôfordulhat, hogy nem hajtható végre, mert várnia kell a memóriaterület felszabadulására. Így az állapotdiagram tovább bonyolódik Ha a kezdeti állapotot külön állapotként fogjuk fel, és a végrehajtott tevékenységek számára is külön állapotot képzelünk el (végállapot), akkor egy részletesebb állapot-diagrammot kaphatunk. (Bár az ábrán nem tüntettük fel, azt mégis meg kell jegyeznünk, hogy a végállapotba egy folyamat bármely állapotból kerülhet.) Felfüggesztett ready Kezdeti Ready Running Blokkolt Felfüggesztett blokkolt Végállapot 5.4 Ábra Folyamatok állapotdiagrammja kiegészítõ állapotokkal Ezek után vizsgáljuk meg azt, hogy

miként hajtódnak végre idôrendben a tevékenységek. Vizsgáljunk egy multiprogramozható rendszert Itt miközben egy folyamat használja a CPU-t más tevékenységek I/O mûveleteket hajthatnak végre, ismét mások speciális tevékenységeket végezhetnek. A következô ábra azokat az egymást követô fázisokat mutatja be, amelyen egy multiprogramozható OR esetében a végrehajtásban részt vevô folyamatok tipikusan átmehetnek. Fontos megfigyelnünk, hogy egy adott pillanatban mindig csak egyetlen folyamat kerül végrehajtási állapotban, a többiek vagy készenléti vagy blokkolt állappotban vannak. A folyamatban résztvevô nagyszámú folyamat miatt azonban mindig van futás alatt lévô folyamat. P1 P2 P3 P4 Blokkolt Készenléti Végrehajtási 5.5 Ábra Tevékenység állapotok egyszerûsített idôbeni lefutása egy multiprogramozási rendszerben. 52 A fenti ábra két szempontból sem reális: nem nehéz elképzelni egy olyan állapotot, amikor a

folyamatban részt vevô tevékenységek mindegyike vagy blokkolt vagy felfüggesztett, így az adott idôpillanatban nincs végrehajtás alatt levô tevékenység. Ezt az idôszakot üresjáratnak (idle) nevezzük. Egy-egy ilyen idôszakban az OR saját programjait futtatja. Az érdekesség az, hogy ezek a programok (idle folyamatok) nem mindig hasznos munkát végeznek. A szerepük az, hogy egyszerûsítsék az ütemezési algoritmusokat. (Ilyen üresjárati eljárás lehet egy prímszámkeresô algoritmus, vagy az Euler féle szám értékének kiszámítása több ezer tizedes jegyre stb.) A másik probléma a fenti ábrázolásnál az, hogy teljesen figyelmen kívül hagyja azt a tényt, hogy az OR-nek szüksége van idôre, a folyamatok közötti átálláskor: amikor egy folyamat futása valamilyen okból leáll, az OR-nek ki kell választani a következô tevékenységet, és a rendszert át kell állítania az új tevékenységre (contex switching). Hosszabb távon a rendszer

átállítására szükséges idôk tetemessé nôhetnek, különösen akkor, ha a tevékenységek váltása túl gyakori, vagy ha az ütemezési stratégia túl bonyolult. A fentiek alapján egy sokkal reálisabb állapotábrát készíthetünk: P1 P2 P3 P4 OR Körny.átállítás Készenléti Blokkolt Végrehajtási 5.6 Ábra Tevékenységi állapotok tényleges idôbeni lefutása egy multiprogramozási rendszerben. 5.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-flag-ekben, státusz-szavakban, vermekben, cím-terü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 képezik a tevékenység környezetét, ezért ezek cseréjét szokás környezet átállításnak nevezni. 53 A legegyszerûbb esetekben a környezet átállítás a

programok meghatározott pontjain következik be. Gyakran elôfordul azonban, hogy a program futását valamilyen elôre nem látható okból pl. egy megszakítás következtében kell felfüggeszteni A környezet átállítását végzô eljárásnak ilyenkor gondoskodni kell arról, hogy az elmentett információk pontosan kerüljenek vissza amikor a hozzájuk tartozó folyamatot ismét aktivizáljuk. Az egész rendszer hatékonysága szempontjából nagyon fontos, hogy a környezet átállítását végzô eljárás a lehetô leghatékonyabb legyen. Ez nagy mértékben függ a számítógépes rendszerhez tartozó CPU architektúrájától: minél több az elmentendô információ, annál nagyobb az átállítás költsége. Számos architektúra speciális parancsokkal rendelkezik a gyors mentéshez, míg más esetekben a számítógépek minden regiszterbôl több példányt tartalmaznak, így nincs szükség az elmentésre, mindössze a regiszterek használatát kell

változtatni. Mivel az a tipikus, hogy az OR-t aktivizáljuk legtöbbször, ezért hasznos az az elképzelés is, amely az OR számára külön regisztereket tart fent. 5.5 Folyamat vezérlô mûveletek A korai multiprogramozású rendszereknél az egyidôben jelen lévô folyamatok számát rögzítették. (A THE rendszer 15 folyamat egyidejû jelenlétét engedte meg Ezek közül ötöt a felhasználók részére, míg a maradékot a rendszer számára tartott fent.) Az ilyen rendszerekben a PCB-k állandóan a memóriában helyezkedik el, és az egyszer aktivizált proceszeket sohasem szakítottuk meg, új folyamatokat sohasem generáltunk. Az ilyen alapon mûködô OR-rôl azt mondjuk, hogy statikusan kezeli a folyamatokat. Ilyen környezetben a folyamatok kezelése viszonylag egyszerû, de ennek természetesen ára van: a hatékonyság nagymértékben korlátozott. A dinamikus folyamat kezelés már lehetôvé teszi azt, hogy folyamatokat állítsunk elô és szüntessük meg a

rendszer mûködése során. A legegyszerûbb esetekben a beindított folyamatok száma a rendszerben lévô "aktiv" felhasználók számához igazodik: minden felhasználóhoz egy folyamat tartozik. A modernebb OR-k (pl UNIX) már lehetôvé teszik azt, hogy a rendszer hívásoknál egy futó folyamat számára egy másikat állítsunk elô. Az újonnan elôállítottak vagy ugyanazon jogokkal rendelkeznek, mint a generáló folyamat, vagy korlátozott lehetôségekkel bírnak csak. Ez utóbbiakat alárendelt folyamatoknak (subprocess) nevezzük. Azt már láttuk, hogy a folyamatok hatékony kezelése a PCB-ken keresztül történik. Néhány OR esetén a PCB-k mérete, a meglévôkhöz való csatlakoztatása (felfûzése ill. leemelése) bonyolult. Ilyen az MVT és az VMS Az újabb többfelhasználós rendszerek (TENEX, MULTICS, UNIX) egyenértékûként kezelnek minden beindított folyamatot, és hatékonyabb algoritmusokat használnak azok kezeléséhez. Ilyen

rendszereknél a generált folyamatokat egy hierarchiába rendezzük: azt mondjuk, hogy a generáló és a generált folyamat szülô-gyermek kapcsolatban van egymással, és a hiarerchiát a gráfelméletbôl jól ismert fa-struktúrával ábrázoljuk. Normális esetekben egy folyamat 54 rendelkezik az általa elôállított folyamatok felett, de a másik ágon elhelyezkedôkhöz nem férhet hozzá. A fejezet további részében megvizsgáljuk, hogy melyek azok a folyamatokon végezhetõ mûveletek, amelyeket egy rendszer használ a hatékony mûködtetéshez. 5.51 Folyamat elôállítás Ez a mûvelet azoknál az OR-nél fordul elô, amelyek megengedik a folyamatok dinamikus kezelését. Általában egy folyamat elôállító (create processz) rendszerhívással aktivizálható a mûvelet, amelyet vagy egy rendszerprogram vagy a felhasználó indít el. Az újonnan generált folyamat szorosan illeszkedik a fent említett hierarchiába. A futtatásra elôkészített folyamat

elôállítása során a következô mûveleteket végezzük el: • • • • • • A PCB elôállítása Memória terü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. Vegyük sorra a fenti mûveleteket. 5.511 A PCB-k elõállítása különbözô OR-k esetén alapvetôen eltérhet Egyes rendszerek rögzített területet tartanak fent a PCB-k számára, amelyben meghatározott számú PCB helyezkedik el. Ezek között aztán vagy pointerekkel mutatnak elôre a szabad blokkok vagy egyszerûen flagekkel jelölik az egyes blokkok állapotát. 0 1 0 1 0 0 1 0 0 1 1 5.8 Ábra Szabad blokkok kezelése a PCB-ket tartalmazó tömbben A dinamikus folyamatkezelést lehetôvé tevô rendszerek közül egyesek külön kulcsolási területet (system queue area) tartanak fent a PCB-k

számára (lásd MVT), míg mások (mint a UNIX) keverik a fenti két módszert: a PCB-t két részre osztják; a PCB-bôl kiemelik a legfontosabb adatokat és azokat egy folyamat (p rocessz) táblában helyezik el. Innen aztán egy pointer mutat a PCB "maradék" részére, amelyet szokás felhasználói területnek nevezni. Ez utóbbit mindig csak akkor allokáljuk, ha szükség van rá. 5.512 A PCB allokálása után a rendszer megvizsgálja, hogy van-e elegendô terület a PCB-hez tartozó program futtatáshoz. Ha van, akkor allokálja a területet, ezzel 55 biztosítva azt, hogy a program betölthetô legyen. Ha nincs, akkor a folyamat elôállítását felfüggeszti. 5.513 A program betöltését általában egy betöltô (relocating loader) végzi Ez az eljárás un. végrehajtható formában tárolt állományokat olvas be az allokált területre Maga az eljárás lehet nagyon bonyolult is, hiszen csak arra kell gondolnunk, hogy a kezdôcímek csak akkor válnak

ismertté, amikor a betöltés megkezdôdik, és így a különbözô ugrási címeket, az adatok pontos helyét az aktuális betöltéshez kell igazítani. 5.514 A folyamat indítása elôtt a kezdeti paramétereket (attributumokat) és a forráskorlátokat be kell állítani Abban az esetben, ha a memória mellett más forrásokat is igényel a folyamat, akkor azok beállításáról is gondoskodni kell. Erre különbözô stratégiákat fejlesztettek ki, melyek közül itt felsorolunk néhányat. • Az attributumokat az éppen futó batch tulajdonságai alapján határozzuk meg (MVT) • A default attributumokat az interkatív felhasználó jellemzôire alapozzuk (VMS). • Megengedjük, hogy az elôállító folyamat specifikálja (adott korlátok között) az általa létrehozott "gyermek" tulajdonságait (VMS). • A "gyermek" folyamat örökli a "szülô" tulajdonságait (UNIX). A legtöbb esetben egy új folyamat nem automatikusan allokálja a

szükséges erôforrásokat. (Ez alól csak a memória-allokálása kivétel) Érdemes megjegyeznünk, hogy a UNIX alatt a létrehozott "gyermek" folyamatok mindig öröklik a létrehozó folyamat már allokált eszközeit. Bár a legkézenfekvôbbnek az tûnik, hogy a frissen elôállított folyamatot azonnal ready-állapotba helyezzük, néhány OR ezt a folyamatot lépésekre bontja. A UNIX esetében ez két egymást követô mûveletet eredményez: • Az elágazási lépés elôállít ugyan egy új folyamatot, készenléti állapotba is helyezi azt, de ahelyett, hogy betöltene egy új programot a "gyermek" folyamat a szülôhöz tartozó programot futtatja kezdetben. (Erre az ad lehetôséget, hogy a UNIX-ban minden program többször indítható és megosztható a folyamatok között.) Az azonban rendkívül lényeges, hogy az adatterületek már ebben a fázisban is elkülönülnek egymástól. • Az elágazási lépést követô ellenôrzések után a

gyermek folyamat egy exec rendszer hívást hajt végre. Ez a lépés betölt a hívó folyamat számára egy új programot, és megkezdôdik annak végrehjatása. 1. ADAT PCB1 PR.A kezdeti állapot 2. ADAT 56 PCB1 PR.A PCB2 ADAT Elágazás-hívás utáni állapot 3. ADAT PCB1 PR.A ADAT PCB2 PR.B Exec-hívás utáni állapot 5.52 Folyamatok megszüntetése Egy folyamat megszüntetésére különbözô okokból kerülhet sor. Ezek közül a legfontosabbakat az alábbiakban soroljuk fel: • • • • • Ö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 folyamat m egszüntetés (destory process) rendszerhívással aktivizálható. Ahogy a folyamat elôállításnál láttuk, hogy jól meghatározott

lépések sorozataként állíthatunk elô egy tevékenységet, most is kézenfekvô, hogy ezeket a mûveleteket "visszafelé" el kell végeznünk. A végrehajtandó lépések tehát a következôk. • 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. • 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. A fenti mûveletek végrehajtása két módon történhet: a folyamatot megszüntetô mûvelet vagy azonnal végrehajtja a fenti lépéseket, vagy elôször un. befejezett állapotba helyezi a folyamatot. Ez utóbbi esetben a teljes megszakítás mindaddig nem 57 hajtódik végre, amíg a "tisztogatási" mûveleteket az OR vagy a hívó eljárás teljes egészében be nem fejezi. Az

egész megszüntetési procedura egyik legizgalmasabb kérdése az, hogy mi történjen egy megszüntetendô folyamat "gyermekeivel"? A legtermészetesebb válasz az, hogy ezeket is meg kell szüntetni. A kérdést azonban bonyolítja az a tény, hogy ezek között elôfordulhatnak olyanok, amelyeket kifejezetten azért hoztunk létre, hogy "túléljék" a hívó folyamatot. (Gondoljunk arra az esetre, amikor egy folyamat aktivizál egy nyomtatást. Nagy hiba lenne a megszüntetésekor a félig kinyomtatott listát vezérlô folyamatot is megszüntetni.) Ezeket természetes, hogy nem szüntethetjük meg Ilyenkor (ismét) két megoldás közül választhatunk: vagy hozzárendeljük ôket egy másikhoz, (ami egy nagyon bonyolult mûvelet) vagy "árvának" tekintjük és leválasztjuk az elôállító folyamatról ôket. Mind a UNIX mind a VMS OR megengedi a túlélést. 5.53 Attributumok olvasása és megváltoztatása Amikor mûveleteket hajtunk végre egy

folyamat végrehajtása során, akkor gyakran elôfordulhat, hogy adatokat akarunk kiolvasni a PCB-bôl vagy bizonyos értékeket meg akarunk változtatni. A legtöbb "kis" rendszerben a PCB a folyamat által elérhetô címterületen belül helyezkedik el, így a folyamat ezeket a változásokat közvetlenül végre tudja hajtani. Abban az esetben, ha a PCB közvetlenül nem érhetô el, akkor egy PCB-olvasás (readPCB) parancs végrehajtásával a teljes PCB-t a címterületen belüli pufferbe töltjük, és ott kezeljük a paramétereket. Egy másik lehetôség az, hogy különbözô hívásokkal csak egyes információkat hívunk le. (pld aktuális állapot, prioritás, elhasznált CPU idô stb) 5.54 Felfüggesztés és újraindítás Egyes OR-k megengedhetik, hogy egy folyamat vagy sajátmagát vagy az általa ellenörzött folyamatok valamelyikét felfüggessze egy felfüggesztés (slepp) parancs segítségével. Egy ilyen igény akkor keletkezhet, ha a folyamatnak

várni kell más folyamatok eredményére, valamilyen megszakítás történt vagy egyszerûen csak egy idôpontra várunk a folytatáshoz. Az ilyen folyamatokat aztán az OR figyeli. Amikor eljön az idô, akkor az "alvó" folyamatot felébreszti egy újraindítási mûvelettel (wake up) . 58 6. 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. Ezt a munkát is OR végzi: egyik legfontosabb feladata az, hogy korrekt és hatékony módon gondoskodjon az erôforrások kiosztásáról az azokért jelentkezô 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 processt, ütemezésnek nevezzük. Mivel a legtöbb ütemezési művelet a folyamatokra vonatkozik, szokás folyamat-ütemezésrôl is beszélni. A rendelkezésre álló erôforrások között is kiemelkedô helyet foglal el

a CPU és az operatív memória. Tekintettel arra, hogy a memória mérete erôsen korlátozott és általában csak egyetlen CPU áll rendelkezésünkre, az ezekért folyatott verseny rendkívül kiélezett. Elosztásukat nehezíti az is, hogy a folyamatok sohasem folyamodnak ezekért az erôforrásokért; működésük alatt azt feltételezik, hogy ezek mindvégig a rendelkezésükre állnak. Ebben a fejezetben azokkal a módszerekkel foglalkozunk, amelyek e két erôforrás elosztását végzik. A fejezet során mindvégig azt feltételezzük, hogy egyetelen CPU áll rendelkezésünkre. Az operációs rendszer ütemezési stratégiája nagymértékben függ attól, hogy mikor szerez tudomást a folyamat várható erôforrás-igényeirôl, és attól is, hogy hogyan kell azokat kiegészíteni. Ebbôl a szempontból a folyamatokat kategóriákra fogjuk osztani: • A batch -processzek alkotják az elsô osztályt. Ezek egy job-ban foglalnak helyet, amelyet a felhasználó egységes

egészként kezel. Jellemzôjük, hogy a végrehajtásuk általában hosszú idôt vesz igénybe, és ez idô alatt a felhasználó nem lép kapcsolatba a futó folyamatokkal. • Interaktívnak nevezzük azokat a folyamatokat, amelyek egy interkatív terminálról elküldött felhasználói igényeket elégítenek ki. Ezek általában rövid lefutású tevékenységek, amelyeket befolyásolhat a végrehajtás ideje alatt küldött felhasználói parancs. • Real-time folyamatokról beszélünk abban az esetben, ha a tevékenység a rendszeren kívül lezajló műveleteket figyel, ellenôriz és irányít. Ezekre a folyamatokra az a jellemzô, hogy rendkívül erôsen behatárolt idô állt rendelekzésükre a válaszadáshoz, és többnyire szoros kapcsolatban állnak valamelyik I/O készülékkel. Ebben a fejezetben csak az elsô két tipusú folyamatokkal foglalkozunk, mivel az utóbbi rendkívül speciális, és az oktatási gyakorlatban ritkán fordul elô. Az egyes

kategóriákra vonatkozó ütemezési strtégiákat tovább osztjuk: 59 • A hosszútávú ütemezési stratégiák helyezkednek a legmagasabb szinten. Az ilyen tipusú ütemezésnek az a célja, hogy ellenôrizze azt a sorrendet, amelyben a folyamatok a rendszerbe jutnak. Erre azért van szükség, mert amikor egy jobot a rendszerhez csatolunk, akkor egy folyamatot is létrehozunk és az ehhez tartozó PCB-t is elkészítjük. Az így keletkezett új folyamat aztán igényt nyújt be a kezdeti erôforrásokra, mielôtt a végrehajtás megkezdôdne. • 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. (Szokás az így kiválasztott folyamatokat egy aktív h almazba sorolni.) Ahhoz, hogy a rendelkezésre álló helyet jól ki tudjuk használni, folyamatokat el kell távolítani a memóriából. Ez a korábban már tárgyalt swapping (kitakarítás) művelete A

háttértárolón elhelyezett folyamatok aztán mindaddig várakoznak egy inaktív állományban, amíg a CPU fel nem szabadul. Néhány rendszerben az elsô két lépés nem különül el egymástól: egy folyamatot akkor veszünk a rendszerhez, ha az általa igényelt memória a rendelekzésünkre áll. Ilyenkor a job mindaddig a memóriában van, amíg be nem fejezôdik. Ezt a műveletet a hosszú-távú ütemzési eljárás végzi. • Az ütemezések között a legalacsonyabb szinten az un. rövidtávú ü temezés található. Ez a művelet azt határozza meg, hogy hogyan rendeljük hozzá a CPU-hoz az aktív állományból a folyamatokat. A kiválasztás és az elôkészítés gyakran két különálló lépésben történik: • - Az aktív halmaz felügyelete és a megfelelô folyamat kiválasztása az ütemezô (scheduler) feladata. • - A folyamatok elôkészítését a felügyelô (dispatcher) modul végzi el. A fenti két fázis során általában az ütemezô végzi a

bonyolultabb feladatot, a diszpécserre már csak a legegyszerűbb hozzárendelések maradnak. 6.1 Ütemezési célok és eszközök Mielôtt részletesen megvizsgálnánk, hogy az egyes ütemezési fázisok hogyan realizálódnak a különbözô tipusú folyamatok esetében, foglalkoznunk kell a különbözô ütemezési célokkal és az ütemezések "jóságának" eldöntésével is. 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. A teljesség igénye nélkül felsoroljuk azokat a legfontosabbakat, amelyek optimaéizálása lehet a cél: Áteresztés: Átfutás: Válasz: Korrektség: A lehetô legtöbb munkát végezzük el egy adott idôszak alatt. A rendszerbe bejutott munkákat a lehetô leggyorsabban fejezzük be. Szolgáljuk ki az egyes lépéseket a lehetô legrövidebb idôn belül. Az azonos jellemzôkkel rendelkezô jobokat korrekt módon 60 Korrektség: Források kezelése: ütemezzük.

Konzisztencia: kiszámítható módon kezeljük az adott jellemzôk alapján a processzeket. A források minden csoportját kiegyenlítetten, folyamatosan használjuk, kerüljük a várakozást. Jól látható, hogy a fenti célok részben ellentmondanak egymásnak, együttes kezelésük csak kompromisszum árán lehetséges. 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 megtenni akkor tudjuk, ha rendelkezünk azokkal az alapadatokkal, amelyek alapján az osztályozást elvégezhetjük. ezek a következôk lehetnek: • • • • • • 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" paramétereket mérünk. Ilyenek a

megítélésére különbözô speciális • Várakozási idô (ezt szokás wait időnek is nevezni és W-vel jelőljük), amely a folyamat az igénybejelentés és a kiszolgálás között eltöltött. • Várakozási sor hossza. • Várakozási hányadok, amely a várakozási idô (W) és a teljes kiszolgálási idô (W+S) hányadosa. 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ülhetünk az elméleti optimum értékétôl Itt hiányzik egy képlet !!!!!!!! Hátránya, hogy nem adja meg a pontos értéket a futtatáshoz, csak egy olyan felsô becslést szolgáltat, amely "patológikus" esetekben 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ékszórás, variancia. 61 6.2 Néhány fontos jellemzô Ebben a szakaszban három olyan tulajdonságot vizsgálunk, amelyek erôsen befolyásolják a kiválasztott stratégiát és annak hatékonyságát. 6.21 Prioritások A folyamatokhoz rendelt mérôszám a többiekhez viszonyított relatív fontosságot adja meg. A prioritás koncepciója lehetôséget ad arra, hogy a döntéseket különbözô szintekre oszthassuk. Az MVT csökkenô prioritást használ 0 és 15 közötti értékekkel, a VMS felhasználó 0-31 között választhat növekvô prioritást jobjaihoz. A UNIX prioritási értékei még szélesebb skálán mozoghatnak: negatív és pozitív értékek egyaránt megengedettek. Kétféle prioritást különböztetünk meg: • statikus prioritásról akkor beszélünk, ha a kezdetben kapott prioritási érték a folyamat élettartama alatt nem változik meg. • dinamikus

prioritással akkor rendelkezik egy folyamat, ha a prioritás aktuális értéke a státuszának alakulásával idôben változik. 6.22 Megszakíthatóság Ha egy ütemezési stratégia olyan, hogy nem engedi meg a megszakítást, akkor az a folyamat, amelyet egyszer a CPU-hoz hozzárendeltünk mindaddig foglalja azt, amíg ”önként” el nem hagyja a memóriát. Ennek az a következménye, hogy egyetlen folyamat akár órákon át is futhat. Az a stratégia, amely megengedi a megszakítást, lehetővé teszi, hogy annak ellenére, hogy egy alacsonyabb prioritású folyamat éppen fut a rendszerben amikor egy magasabb prioritású job ready állapotba kerül, akkor azonnal hozzájusson a CPUhoz. Megszakítási stratégiát mind a rövidtávú mind a középtávú ütemezési stratégiáknál használhatunk. 6.23 Az önköltség Gyakran előforul, hogy a könnyebb kezelhetőség kedvéért az egyes ütemezési stratégiákat elemző eljárások figyelmen kívül hagyják a

folyamatok kicserélésére használt időt. A valóságban ez azonban sokszor jelentős időket is igénybe vehet, ezért a pontos analízisekben bevezetik ezekre a tevékenységekre az önköltség fogalmát. A rövid távú ütemezéseknél az önköltségnek két forrása van: vagy az OR döntést előkészítő eljárása fut, vagy környezet átállítás történik. A középtávú ütemezés esetén az önköltség legnagyobbrészt a memória tartalmának kicseréléséből (swaping) adódik. 62 6.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. A fejezet bevezetésében leírtakon túl ezek az információk tartalmazzák az input adatokat, a file azonosítókat és a használni kívánt I/O készülékeket is. 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. (Az egyetlen amit tehet az az, hogy megszakítja a futását) A batch jobok egyik fontos paramétere a job becsült futási ideje, amelyet szintén a felhasználó ad meg. Mivel ezt az időt az OR felső korlátként kezeli, ezért ez arra ösztönözheti a felhasználót, hogy hosszabbra becsülje azt. A batch jobok esetében a felhasználók által a leginkább elvárt cél az, hogy az általuk elküldött job a lehető leghamarabb átfusson a renszeren. 6.31 Hosszú távú ütemezés A kezdeti prioritás, a felhasználók á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 (input queu) állítjuk a megadott paraméterek alapján. Minden job-osztálynak egy input sor áll a rendelkezésére. • A rendszer initator 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 timert beállít a rendszer, ezzel biztosítva azt, hogy a tervezett futási időt a job ne lépje túl. 6.32 Középtávú ütemezés Batch környezetben a középtávú ütemezést általában nem tekintjük külön lépésnek. Ennek az az oka, hogy 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. 6.33 Rövidtávú ütemezés A batch jobok rövid távú ütemezésének a következő jellemzői vannak: 63 • Ha a CPU felszabadul, akkor a készenlétben levő folyamatok közül válogatunk • Ha egy folyamat beindult,

akkor mindaddig folytatódik, amíg a követkző 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. Megjegyezzük, hogy a megszakítások a batch környezetben kevésbé fontosak, mert csak a végrehajtás összideje korlátozott, nincs előírva a folyamat végső befejezésének az időpontja. Mivel az ilyen típusú megszakításokkal ”csak bajok vannak” (bonyolult környezet átállítás, növekszik az önköltség stb.), ezért általában nem is használatosak ebben a környezetben. 6.34 Stratégiák A First-In First -Out (FIFO) stratégia az egyik leggyakrabban használt batch vezérlő eljárás. Itt minden jobnak azonos prioritást biztosítunk, és abban a sorrendben lesznek végrehajtva, amelyben beérkeztek a sorba. A Shortest Job Next

(SJN) algoritmus előnyben részesíti azokat a jobokat, amelyeknek rövidebb a becsült végrehajtási ideje. E módszer hátránya az, hogy abban az esetben, ha mindig van ”rövid” job, akkor a hosszú futási időt igénylő jobok sohasem hajtódnak végre. (Ezt nevezik éhenhalási jelenségnek) Az SJN technika az egyik legismertebb 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, ezzel biztosítva azt, hogy előbb-utóbb minden job végrehajtásra kerüljön. Ezek a stratégiák néha megszakításos környezetben is használatosak. A Shortest Remaining Time Next (SRTN) stratégia a megszakításos rendszerekben sűrűn használt technikák közül az egyik legismertebb. Itt mindig az a job kerül vissza, amelyiknek a legkevesebb megmaradt ideje van. 6.4Interaktí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. Bár néhány tevékenység igen hosszú lehet, mégis a legtöbb szolgáltatás mint a könyvtárak listázása vagy egy szöveg megadott sorának szerkesztése általában rövid ideig tart. Az interaktív folyamatok esetében az a probléma, hogy a kérés beindításakor általában semmit sem 64 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, akkor a múltbeli viselkedésükbôl próbálunk meg információhoz jutni ahhoz, hogy a jövôbeli igényeiket becsülni tudjuk. Minden ilyen jellegű probléma eltörpül a legfontosabb cél mellett: 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. Az világosnak látszik, hogy a hosszútávú ütemezésnek az interaktív folyamatok esetében nincs nagy

jelentôsége: egy újonnan létrehozott folyamatot ugyanis normális körülmények között azonnal elfogadunk. Kivétel csak egyrészt az lehet, ha a rendszer túlságosan leterhelt, vagy ha az azonos idôben futtatható tevékenységek számára esetlegesen elôírt korlátokat túllépnénk a folyamat beindításával. Ez utóbbi esetben az igényt a rendszer elutasítja,és egy késôbbi idôpontban kiséreli meg a folyamat újraindítását. Miként arra már korábban is utaltunk a legfontosabb az, hogy az ütemezô gyors választ tudjon adni a jelentkezô igények kielégítésekor. A diszpécser programnak ezért biztosítania kell azt, hogy a CPU hozzáférhetô legyen minden processz számára, és a váltásnak olyan sűrűnek kell lennie, hogy egyetlen folyamat se várakozzon hosszú ideig a kiszolgálásra. Ha a fôtár ütemezésére is szükség van, akkor ennek kiosztását hasonló szabályok szerint kell elvégezni. Az ilyen típusú ütemezési feladatokat az un

idôszeletek elvének a 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ésére álló idôt, akkor felfüggesztjük a futását, é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. 6.41 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. Minden olyan esetben, amikor egy folyamat az aktív állományba kerül, akkor a PCB-jében egy számlálót állít be az ütemezô, amely a rendelkezésére álló CPU idôszeletet mutatja. Amikor a folyamat a CPU-hoz fordul, a számláló értékét a felhasznált idô mennyiségével csökkentik. Általában ez akkor is bekövetkezik, ha a folyamat I/O tevékenységet végez. Abban az esetben, ha a rendelkezésre álló idôt

elhasználta, akkor a processz kikerül az aktív tevékenységek halmazából. Az inaktív állapotban levô tevékenységek kikerülnek a diszpécser program figyelési körébôl, és az általuk elfoglalt területet a "swap" számára hozzáférhetôvé tesszük. (Fontos, hogy fizikailag akkor fogjuk kimásolni az un."swap-készülékre", ha az általa elfoglalt területre valamilyen más célból szükség van.) A központi tár felhasználására rendelkezésre bocsájtott idô általában néhány másodperc és 1-2 perc között változik. 6.42Rö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. Abban az esetben, ha a rendelkezésére álló idô lejár azelôtt mielôtt a folyamat elvégezné a kijelölt feladatot, a belsô óra (timer) egy megszakítást hoz létre, a CPU-t 65 kiürítjük, és átadjuk a helyet a következô tevékenységnek. A CPU használatára biztosított idôszelet

nagyságrendje általában 100 millisecundumtól néhány másodpercig terjed. Az interaktív környezetben történô rövid távú ütemezésnél a folyamatokat vagy prioritások alapján választjuk vagy egyszerűen a készenléti sorban elfoglalt helyük határozza meg a belépések sorrendjét. Elôfordulhat, hogy az alacsonyabb prioritású folyamat félbeszakítható a magasabb prioritású igénye miatt, de ez nem általános szabály. Egy futó interaktív folyamat megállítására mindazok a feltételek felsorolhatók, amelyeket a batch típusúaknál megemlítettünk. Egy kivétel van csak: a teljes futási idô túllépésérôl itt nem beszélhetünk, mivel az általában nem ismert. A fentiek ismeretében természetes az, hogy egy további ok is fennáll a felfüggesztéshez: egy folyamatot megszakítunk, ha az túllépte a CPU felhasználására biztosított idôszelet értékét. A rövidtávú ütemezési stratégiákra az alábbiakban mutatunk be néhány példát.

• Körkörös ütemezés esetén a készenléti állapotban levô 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 levô folyamatot választjuk ki a futásra. Amint az felhasználta a rendelkezésére bocsájtott idôt, megszakítjuk és a sor végére állítjuk. Így a készenléti sorban elhelyezkedô folyamatok "körkörös" sorrendben lesznek kiszolgálva. Az újonnan készenléti állapotba kerülôk mindig a sor végére kerülnek. • Prioritásos mószerek esetén a folyamatok prioritásuk szerint vannak csoportokba sorolva. A csoportokon belül általában körkörös ütemezést alkalmazunk Ha a különbözô prioritási értékek száma viszonylag alacsony, akkor minden prioritási osztályt külön sorban kezelünk. Ellenkezô esetben egy sort tartunk csak fenn, és a folyamatokat úgy illesztjük be a sorba, hogy a prioritás szerinti sorrend megmaradjon.

Elôfordulhat, hogy a prioritást több faktorból számítjuk ki, és az is lehetséges, hogy a prioritási értékek az idôben változnak. Egy ilyen lehetôség az, hogy a sor végére kerülô tevékenység alacsonyabb prioritást kap. A prioritásos eljárások egyik jellemzôje az, hogy a különbözô prioritásokhoz különbözô idôszeleteket rendelünk. Általános szabályként ilyenkor azt fogadhatjuk el, hogy az alacsonyabb prioritású folyamatokhoz nagyobb idôszeleteket rendelünk. (Ilyenkor abból indulunk ki, hogy az alacsony prioritású tevékenységekre ritkábban kerül a vezérlés, és így az "igazságosság elve" alapján hosszabb ideig kell futniuk.) Néhány jellemzô variációt a következôkben sorolunk fel: • Az öregítési tech nika alkalmazásakor a folyamat-sorokat időszakonként felülvizsgáljuk. Minden olyan folyamatnál, amelyre az elmúlt iőszakban nem került vezérlés, megnöveljük a prioritást a következő szintre, így

azok előbbre kerülnek a sorban. • Visszacsatolás esetén az éppen befejezett folyamat átkerül egy alacsonyabb prioritású szintre. Mivel az ezen a szinten elhelyezkedő tevékenységek hosszabb szeletet kapnak a CPU idejéből, ezért a legközelebbi végrehajtáskor ez a folyamat 66 is tovább foglalja a CPU idejét. A legalsó szinten elhelyezkedő tevékenységeket körkörös módszerrel ütemezzük. • A Kleinrock által javasolt önző ütemezési technika azokat a folyamatokat részesíti előnyben, amelyeket már elfogadtunk a feldolgozásra. A készenléti állapotba került folyamatokat ez az eljárás egy különálló sorban helyezi el. Minden itt elhelyezkedő folyamat egy speciális prioritás értéket kap, amely független a "normál" prioritási értékektől. (Tegyük fel, hogy az új folyamat prioritási értékei 0-ról indulnak) Mind az új mind az ütemezésre elfogadott tevékenységek prioritását valamilyen (pl. öregítési)

technikával periódikusan növeljük oly módon, hogy az újonnan érkezettek prioritása gyorsabb ütemben növekszik. Ha valamelyik "új" folyamat prioritása eléri az elfogadott folyamatok prioritási szintjét, akkor ez a tevékenység átkerül a végrehajthatóak sorába és az ütemezése az itt elfogaott szabályok szerint folytatódik. • A VM/370-nél alkalmazott "tisztességes kiosztás" módszere egy olyan technikát követ, amelyben 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. 67 7. Konkurrens 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 is limitálva van. (Gondoljunk a nyomtatókra, a kommunikációs

vonalakra vagy a különböző háttétárolókra). Emellett a folyamatok egymástól sem függetlenek: valahányszor két tevékenység ugyanazt az állományt akarja használni, vagy jelzést kíván adni más folyamatoknak saját előrehaladásáról, a két tevékenység interakcióba lép egymással. Ha tehát az interakció jelenségét általánosan vizsgáljuk, két típust különböztetünk meg: • Erőforrások osztott használata esetén az interakcióban levő folyamatok a korlátozott mennyiségben rendelkezésre álló erőforrások birtoklásáért versenyeznek. Az ilyenfajta interakció akaratlan és az interakcióból nem okvetlenül profitálnak a benne résztvevő tevékenységek. • A kommunikációból eredő interakció esetén a folyamatok információt osztanak meg egymással. Ez az interakció akaratlagos és az interakcóból a résztvevők többnyire hasznot húznak. A különböző típusú interakciók különböző problémákhoz vezethetnek. Mindkét

esetben a legnagyobb probléma a holtpont előfordulása, illetve a kölcsönös kizárás. A következőkben ezekkel a jelenségekkel foglalkozunk. 7.1 A holtpont Holtpont egyrészt akkor fordulhat elő a vezérlé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ásra várakozik, amelyet mások lefoglaltak, akkor a tevékenységek "megmerevedhetnek". Holtpont keletkezhet ugyanakkor kommunikáció esetén, ha folyamatok egymás információira várnak, miközben nem tudnak előrehaladni a saját feldolgozásukban. Nagyon érdekes az a tény, hogy annak ellenére, hogy a holtpont problémáját nagyon széles körben vizsgálták, korántsem tekinthető megoldottnak. Különösen nehéz felfedezni a holtpontot osztott környezetben. Nagyon kevés az az operációs rendszer, amely garantálja azt, hogy az ütemezés során holtpont nem

fordulhat elő.A megbízható megoldás ugyanis rendkívűl drága. 68 Először azt vizsgáljuk meg, hogy milyen feltételeknek kell fennállni ahhoz, hogy holtpont következhessen be. Erre a kérdésre Coffman (1971) adott kimerítő választ megmutatva, hogy a szükséges feltételek a következők: • Kölcsönös kizárás, azaz a folyamatoknak olyan erőforrásokat kell "fogva"tartani ill. igényelni, amelyeket csak egy folyamat használhat egyidejűleg. • Erőforrások lefoglalása, azaz folyamatoknak erőforrásokat kell foglalkoztatni, miközben mások igénylik ezeket. Ha egy folyamatot úgy szerkesztünk meg, hogy az elengedi az összes lefoglalt erőforrást akkor, ha újat igényel, akkor holtpont nem léphet fel. • Megszakítás nem megengedett, ami azt jelenti, hogy a rendszer nem függesztheti fel egy erőforrás hozzárendelését egy folyamatokhoz azért, hogy egy másik számára hozzáférhetővé tegye a forrást. (Gondoljunk egy nyomtató

használatára) • Visszatérő igényeknek kell jelentkezni a processzek részéről, ellenkező esetben (pl. ha az igényeket szorosan rendezett módon kell kielégíteni.) a holtpont keletkezése megelőzhető. Mivel a fenti fenti feltételeknek egyidejüleg kell fennállni, ezért ez nagymértékben növeli azt az reményt, hogy az ütemezés során a holtpont nem forul elő. Ezért az egyik lehetséges módszer a holtpont elleni védelemhez, hogy igyekszünk kiküszöbölni azt az esetet, hogy egyidejűleg az összes feltétel fennálljon. A következőkben a holtpont megelőzésére mutatunk néhány lehetséges stratégiát. A. Holtpont megelőzés A holtpont megelőzés célja az, hogy úgy ütemezzük a különböző erőforrásokat, hogy a holtpont bekövetkezésének feltételeli közül legalább egy ne teljesüljön. Ez a feladat az operációs rendszerek tervezésének a témakörébe tartozik. A kölcsönös kizárás néhány forrás esetében - mint például a CPU

vagy egyes I/O készülékek - elkerülhetetlen, ugyanakkor másoknál - pl. csak olvasásra használt állományoknál - könnyen elkerülhető. Az egyik leggyakrabban használt technika az I/O készülékek esetében az un. spoolingolás Ilyenkor a direkt készülékhasználat helyett egy átmeneti pufferben helyezzük el a nyomtatandó anyagot és ezek egy batch process segítségével használják fel az erőforrást. (Jelen esetben a nyomtatót) Az erőforrások lefoglalása úgy kerülhető el, hogy a folyamatokat szervezzük úgy, hogy egy időben csak egy erőforrást foglaljanak le. Ez a fajta szervezési technika jól követhető a memória kiosztás esetében. A legegyszerűbb úgy eljárni, hogy a folyamat előállításának pillanatában allokáljuk a maximálisan szükséges a memóriát. Ennek persze az a következménye, hogy nem lesz hatékony a memória kihasználás, és ez rontja az OS hatékonyságát. (Jellemző példa erre az OS/360 fix taskos operácós

rendszere.) A megszakíthatóságról néhány erőforrás esetében azonnal eldönthetjük, hogy nem köthető ki. A legjellemzőbb példáknak a nyomtatás és az olvasásra használt állományok tünnek. Mégis meglepő, hogy a THE OS-ben a nyomtatásnál megengedik a megszakíthatóságot. Ezt úgy érik el, hogy lapokra bontják az outputot 69 és az operátor feladatának tekintik a kinyomtatott anyag rendezését. Memória típusú erőforrások esetében a swap technika szolgáltatja a megszakítást. A visszatérő igények elkerülésére a Havender által kifejlesztett hierarchikus rendezést használhatjuk. Ennek az a lényege, hogy a forrásokat kategóriákba osztjuk, és ezekhez a kategóriákhoz prioritásokat rendelünk. Ezután a folyamatokat úgy vezéreljük, hogy egy adott prioritási szinten levő forrás csak akkor kaphatja meg a vezérlést, ha vele azonos vagy nála magasabb szinten nem használ forrást. B. Holtpont elkerülés A holtpont elkerülésének

a stratégiája egy olyan dinamikus módszer, amely megkiséreli azt biztosítani, hogy sohase allokáljuk a forrásokat oly módon, hogy a rendszer "bizonytalan" állapotba kerüljön. Egy ilyen állapotban ugyanis nagyon megnő a holtpont bekövetkezésének a veszélye. Általános stratégiát mondani erre nagyon nehéz. Az bizonyos, hogy a holtpont csak akkor kerülhető el, ha az egymással interakcióba került folyamatok valamilyen módon segítik egymást. C. Holtpont érzékelés A folyamatok vezérlése során bekövetkezett holtpont detektálása nem könnyű feladat. Egy holtpont kialakátásában ugyanis előforulhat, hogy igen nagyszámú folyamat vesz részt, ugyanakkor viszont más ebbe a halmazba nem tartozó tevékenységek "normálisan" haladnak tovább. Egy lehetséges stratégiát mutatunk be az alábbiakban: 1. Válasszuk ki a futó folyamatok közül azokat, amelyeknek van erőforrás igényükEzek lesznek ugyanis azok a tevékenységek,

amelyek a holtpont kialakításában részt vehetnek. 2. Keressünk egy olyan tevékenységet, amely olyan erőforrás igénnyel rendelkezik, amely kielégíthető a pillanatnyilag rendelkezésre álló szabad forrásokból. Jelöljük meg ezt a tevékenységet. 3. Minden olyan forrást, amelyet a most éppen kijelölt tevékenységünk használ, tekintsünk szabadnak. 4. Ismételjük meg az eljárást a 2 ponttól mindaddig, amíg nem jutunk el egy olyan állapotba, amikor már nincs kiszolgálható tevékenység. Ha az eljárás végén marad olyan nem kiszolgálható folyamat, akkor a rendszerben van holtpont, és a megmaradt folyamatok éppen azok, amelyek a holtpont kialakításában részt vesznek. (Könnyen belátható, hogy a fenti "mohó" stratégia végén kapott halmaz nem függ az elsőként választott folyamattól.) Megmaradt még annak a kérdésnek a vizsgálata, hogy mikor kell a fenti algoritmust aktivizálni, hiszen a gyakori futás erősen csökkentheti a

rendszer hatékonyságát. Itt csak egy lehetséges stratégiát említünk, amelyet VMS OS-nél használnak: az algoritmus akkor indul be, ha egy erőforrásra olyan sokáig várakozik egy folyamat, hogy az túllép egy előre meghatározott időlimitet. 70 D. Holtpont megszüntetése Ha a holtpontot valamilyen módon detektáltuk, akkor az OS egyik legfontosabb feladata a várakozási kör valamilyen módon történő lerombolása. A legdrasztikusabb módszer az, ha a kör kialakításában résztvevő összes folyamatot megszakítjuk (ami persze együtt jár az eredmények elvesztésével is). Sok esetben azonban elegendő néhány tevékenységet kiemelni a körből, és ezeket sem szükséges megszakítani, hanem elegendő "visszállítai" egy megelőző állapotba. Az alábbiakban néhány módszert mutatunk ilyen kiválasztásra: • Keressük meg, hogy melyik az a tevékenység, amely a legaktívabban vesz részt a holtpont kialakításában. Nagyon gyakran

elegenő ugyanis egyetlen ilyen tulajdonságú folyamat eltávolítása. • Keressünk olyan folyamatot, amely újrainítható. Egy update "közepén" levő tevékenység nem tekinthető ilyennek, mert az újraindítésa biztosan nem szolgáltat korrekt eredményt. • Keressük meg azokat a folyamatokat, amelyek újrainítása a legkevesebb munkával jár. Válasszuk tehát azokat, amelyek vagy éppen megkezdődtek, vagy olyan ellenőrzési pontokkal rendelkeznek, amelyeken megőrizték az állapotukat és így azok könnyen visszállíthatók. • Vizsgáljuk meg a folyamatokat prioritásuk szerint. Az alacsony prioritású folyamatok kevesebb rizikó árán távolíthatók el a futó folyamatok sorából. Fontos megjegyezni, hogy a holtpont megszüntetésében az automatikus választás mindig komoly veszéllyel jár. A legtöbb OS (mint pl a VMS) igen erősen támogatja azt, hogy az operátor legyen az, aki a végső döntést meghozza ilyen esetekben. 7.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 állhatnak rendelkezésre. Ha tehát egy ilyen erőforrás éppen használatban van , akkor az érte jelentkező ujabb folyamatoknak várakozni kell. Ha egyidőben több igény is érkezik, akkor az operációs rendszer a felelős azért, hogy a kiosztás korrekt és hatékony legyen. A konkurens folyamatokat két csoportra osztjuk: Az egyik csoportba az olyan források tartoznak, mint a CPU, a memória, a különböző I/O készülékek és állományok. Ezeket a rendszer által ellenőrzött forrásoknak nevezzük Az ilyen források a felhasználók számára a legtöbbször nem érhetők el közvetlenül, hanem rendszerhívások útján kezelik őket. Így a kölcsönös kizárás kezelése a OS feladata Ha egy folyamat kizárólagosan akar kezelni egy készüléket, akkor először allokálni kell az erőforrást. Ezt egy

open müvelettel lehet elérni (Ez a rendszerhívás engedélyezi a 71 folyamatok számára az erőforrások használatát.) Ha az erőforrás mások által foglalt, akkor a folyamatot felfüggesztjük mindaddig, amíg az erőforrás fel nem szabadul. Fontos megjegyezni, hogy az ilyen típusú allokációk esetében a teljes felelősséget az OS viseli, és a megszakítás - user által generált - folyamattal soha nem érhető el. A források másik csoportjába azok tartoznak, amelyek osztott elérést tesznek lehetővé. Az ilyen erőforrásokat a felhasználók által ellenőrzött forrásoknak nevezzük. Mivel az ilyen típusú erőforrások bármely folyamat által fizikailag is elérhetők, ezért a kölcsönös kizárásról most maguknak a résztvevő folyamatoknak kell gondoskodniuk. A leggyakrabban használt példa az ilyen típusú forrásokra egy olyan állomány, amelyet két felhasználó nevezzük Öket A-nak ill. B-nek egy időben akar elérni.(Az ilyen

erőforrásokat osztottan elérhetőnek nevezzük) Ha mindkét felhasználó az állomány egy rekordját azonos időben olvassa be, és némi változtatás után visszaírja, akkor az a változtatás marad meg, amelyiket később írtunk vissza. Ez akkor következhet be, ha a folyamatok nem biztosítják a kölcsönös kizárást. Ahhoz, hogy ezt el tudjuk érni, először ki kell jelölnünk a folyamat utasításainak azt csoportját, amelyben az erőforrások elérése történik, és amelyet nem szabad megszakítani. Az utasításoknak ezt a csoportját kritikus résznek nevezzük. A fenti példában bekövetkezett interferenciát úgy tudjuk elkerülni, hogy a kritikus részt kijelöljük: belépéskor ill. kilépéskor speciális utsítássorozatokat adunk ki Ezeket entry protokolnak ill. exit protok olnak fogjuk nevezni Ezek lesznek tehát azok az utasítássorozatok, amelyek biztosítják a kölcsönös kizárást. Arra az esetre, ha a kölcsönös kizárást két folyamat

esetében akarjuk elérni, egy lehetséges megoldás a Peterson által javasolt következő megoldás: ENTRY PROTOKOL: • Állítsuk a saját flag-et IGAZ állapotba. • Adjuk át a vezérlést a másik folyamatnak. • Várjunk mindaddig, amíg a másik folyamatnál van a vazérlés, és a flag-je IGAZ állapotban van. EXIT PROTOKOL: • Állítsuk a saját flag-et HAMIS állapotba. Ha a fenti két protokolt mindkét folyamatban elhelyezzük, akkor könnyen ellenőrizhető, hogy a kívánt kölcsönös kizárás elérhető. Ha a halmaz több folyamatból áll, akkor az eljárás természetesen bonyolultabb. Abban az esetben, ha a rendszer hardware vagy az operációs rendszer rendelkezik egy olyan utasítással, amely bizonyos kitüntetett változók értékeit úgy tudja megváltoztatni, hogy a végrehajtás közben a művelet nem szakítható meg, akkor az ilyen un. bináris szemaforral a kölcsönös kizárás szintén elérhető( A szemaforok két állapotát angolból

kölcsönözve wait ill. signal állapotnak fogjuk nevezni) Tételezzük fel, hogy egy S szemafor rendelhető minden osztottan is igénybe vehető erőforráshoz. 72 Legyen S = 1, ha az erőforrás szabad. Legyen a két támogatott művelet a nyitás (N) és a zárás (Z): N(S): WHILE (S=0) ne csinálj semmit. S := 0. Z(S): S := 1. Amennyiben a fenti két műveletet a kritikus rész elején ill. végén helyezzük el, akkor a kölcsönös kizárás elérhető. (Itt azért még felléphetnek egyéb problémák is, de az már kívül esik e jegyzet mélységén.) 7.3 Folyamatok közötti kommunikáció 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. Mivel az egyre bonyolultabb OR-k világában a tevékenységek közötti kommunikáció egyre nagyobb szerepet kap, ezért az interprocess com munication (IPC) egyre fontosabb lesz.

Bárhogyan is választjuk meg az IPC algoritmust, az alábbi modellek közül valamelyiket be kell építeni: • Többszörös hozzáférésű memória kezelés esetében share típusú változókat és adat-strukturákat helyezünk el olyan területen, amely közvetlenül elérhető több folyamat számára is. Ezt a módszert gyakran úgy tökéletesítik, hogy memória áthelyezési lehetőségeket biztosítanak. Ez utóbbi módszer leképezi a folyamatokhoz tartozó memóriák egy részét egy közös fizikai területre. Abban az esetben, ha a rendelkezésre álló memória terület kevés, akkor a share típúsú állományok használata is megengedett. • Az üzenetátadás techn ikája azt jelenti, hogy egy folyamat közvetlenül küld információt, és egy másik pedig fogadja azt. Az itt használt művelet - az előzőekkel szemben - egy I/O típusú művelet. Az információ egységét - függetlenül a mennyiségtől - üzenetnek fogjuk nevezni. A fenti két alapmodell

összehasnonlításakor megállapíthatjuk, hogy az első gyorsabb és egyszerűbb kommunikációt biztosít, ha a share memória a rendelkezésünkre áll. Ugyanakkor a share memória alkalmazása olyan problémákat generál, mint a kölcsönös kizárás, amelyet kezelni kell a résztvevő folyamatoknál, és időzítési problémák is felléphenek: a beíró folyamatnak tudnia kell, hogy az információ ténylegesen bekerült-e a shared memóriába, és ehhez újabb információra van szükség. Bár az üzenetátadás lassabb, mégis szélesebb skálán használják. Gyakran előfordul ugyanis, hogy a folyamatok nem használhatnak közös területeket. (Ez különösen 73 nyílván-való abban az esetben, ha különböző fizikai készülékeken helyezkednek el.) A következőkben az üzenetátadással kapcsolatos problémákkal foglalkozunk . 7.31 Szinkronizálás A kommunikációnak a legegyszerűbb formája az, amikor egyetlen bit információt cserél két folyamat. Ez

olyankor következik be, amikor egy folyamat valamilyen esemény bekövetkezéséről kívánja tájékoztatni a többieket, vagy egyszerűen csak azt akarja tudatni, hogy a végrehaktás során egy bizonyos pontig eljutott. Ezt az egyszerű folyamatot szinkronizációnak nevezzük. A szinkronizációnak két típusát különböztetjük meg: Előfordulhat, hogy egy folyamat alszik vagy a felfüggesztés állapotában van, mert egy jelre (signal) várakozik. Ha ez a jel nem érkezik meg, akkor a várakozó folyamat sohasem fog folytatódni. Mivel ez a folyamat nem rendelkezik külön memóriával, ez különösen akkor kellemetlen, ha a signal már korábban létrejött. Jól javítható az eljárás akkor, ha minden egyes signal rendelkezik egy 1-bites pufferral (flag). Ekkor ugyanis az információ tárolható, és bármikor kiolvasható. Itt jegyezzük meg, hogy a szemafor technika jól alkalmazható erre az esetre: Tegyük fel, hogy egy szemafor kezdeti értéke nulla. Egy folyamat

jelezheti egy esemény bekövetkezését egy Z típusú művelettel, ugyanakkor egy másik folyamat várakozhat az esemény bekövetkezésére egy N típusú művelettel. A végrehajtás során a várakozó folyamat az N végrehajtása után mindadig várakozik, amíg az esemény be nem követezik. Amint az esemény bekövetkezik, a Z művelet a szemafort 1-re állítja, és a várakozó folyamat tovább folytatódhat. 7.32 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 az, hogy a folyamatok üzenetküldő (send) és üzenetfogadó (receive) rendszerhívásokat használnak. Üzenetek továbbításakor fizikailag nem mindig az üzenetet küljük el. Ha az üzenet túl nagy, akkor az üzenetet tartalmazó puffer kezdőcímének átadásával a ”mozgó” információ mennyisége lecsökkenthető. Az információcsere úgy zajlódik le, hogy a fogadó folyamat egy receive

rendszerhívás segítségével jelzi, hogy kész fogadni üzenetet. Ha az üzenetátadás szimmetrikus, akkor a fogadónak meg kell neveznie azt a folyamatot, amelytől az üzenetet várja, és csak a megnevezett folyamattól fogad el üzenetet. Asszimetrikus üzenetváltás esetében a send rendszerhívás név nélküli, és a legközelebb érkező üzenetet le is fogja függetlenül attól, hogy kitől érkezett az. 7.33Közvetlen kommunikáció csatorna használattal A kommunikációs csatornát úgy kell elképzelni, mint egy speciális tulajdonságú állományt. Az üzeneteket egy írási (write) rendszerhívással küldjük el ebbe az állományba, és egy olvasási (read) művelettel fogadjuk őket. Ez a fajta megközelítés a 74 csatorna (pipe) alkalmazásával először a UNIX-ban jelent meg. Itt az eljárás úgy működik, hogy két folyamat között - átmenetileg - egy információs csatornát hozunk létre, amelybe az egyik folyamat beleír és a másik a beírt

információt kiolvassa. Érdemes megjegyezni, hogy a UNIX nem csak két folyamat között engedi meg a pipe alkalmazását, de az egész mechanizmus akkor igazán hatékony ha a csatorna két végén egy-egy folyamat áll csak. 7.34 Közvetett kommunikáció Abban az esetben ha sem az üzenetküldő folyamatot sem peig a fogadót nem akarjuk megnevezni, akkor a közvetlen információcsere mellett (vagy helyett) más módszereket is használhatunk. Ha az üzeneteket közös elérésű pufferben tároljuk, akkor ez tekinthető egy hétköznapi értelemben vett levelesládának (mailbox). Ekkor az üzenetküldő folyamat egy send műveletet használ, de kommunikációs partnerként a levelesládát jelöli meg. Ez a név vagy állandó és minden folyamat által ismert, vagy dinamikusan deklarálódik. A fogadó folyamat most a mailbox-t tekinti az üzenet forrásának és innen olvassa be az üzenetet függetlenül az eredet üzenetkülőtől. 75 8. Megszakítások, I/O kezelés

A különböző készülékek kezelése az OR-k egyik legfontosabb feladata. Ennek megértése érdekében nagyon fontos, hpgy megértsük a megszakításokat mind a hardware mind a szoftware szemszögéből. A mindennapos számítógéparchitekturák egyik legfontosabb tulajdonsága a hardware m egszakítás alkalmazása, amely lehetővé teszi, hogy felfüggesszünk egy éppen futó programot, ha egy speciális esemény bekövetkezett és ezzel egyidőben esetleg egy másik folyamatot indítsunk el. Megszakításokkal segíthetjük a készülékek kezelését, ha pld. megengedjük, hogy egy I/O készülék szolgáltatást fogadjon el a CPU-tól anélkül, hogy a készülék állandó szoftver összeköttetést igényelne. Tételezzük fel, hogy egy folyamat elfoglalja a CPU-t, miközben a nyomtató befejez egy nyomtatást. Ha most egy megszakítás érkezik az OR-hez, jelezve a nyomtatás befejezését, akkor az OR megszakítja az éppen futó folyamatot, munkát oszt ki valamilyen

módon a nyomtatónak, és visszaadja a vezérlést az imént megszakított folyamatnak. (A végső eredmény az, hogy a nyomtatót jobban ki tudjuk használni) Ahhoz, hogy vissza tudjunk térni a felfüggesztett folyamathoz, szükséges az, hogy a felfüggesztés pillanatában a környezetet megjegyezzük, és azt a megfelelő pillanatban vissza tudjuk állítani. Világos, hogy ha több megszakítás van folyamatban, akkor a helyzet bonyolódik, de még mindig kezelhető marad. Bárhogy is következzen be a megszakítás, az alapkoncepció változatlan marad: • Mentsük le a végrehajtási címet. • Mentsük le a státusz információkat. (Ezeket általában egy státusz szóban tároljuk) • Adjuk át a vezérlést a megszakítás kezelőnek. 8.1 A megszakítások típusai Természetesen nem minden megszakítás I/O művelet következménye. A következő fejezetben felsorolunk néhányat a leggyakrabban előforduló megszakításokból. A számítógépek nem mindig

rendelkeznek az összes ilyen megszakítástipussal, de az I/O befejezés, a timer és a rendszer megszakítások minden rendszer szerves részét képezik. 76 Megszakítás I/O művelet befejezése miatt. Ez a fajta megszakítás akkor generálódik, ha valamely I/O készülék szolgáltatást kér a készülékhez tartozó megszakítás kezelő (interrupt handler) rendszerprogramtól. A szolgáltatás különböző lehet: ha a szolgáltató készülék un. karakter-karakter típusú, akkor új karakter továbbítását igényelhetjük, ha blokk típusú készülékről van szó, akkor kérhetjük a következő adatcsoport írását vagy olvasását, és hiba fellépése esetén a hiba kezelése lehet a megkívánt művelet. Riadó m egszakításról akkor bezélünk, ha a megszakítás a rendszeren kívűlről érkezik. Majdnem minden számítógép rendelkezik egy megszakítási gombbal (gondoljunk a PC-k ALT+X vagy ALT+CTL kombinációira.), amellyel az operátor

aktivizálhatja a parancs interpretert. A timer megszakítás úgy kezelhető, mint egy normális I/O megszakítás, csak itt nincs fizikailag jelen egyetlen készülék sem. (Ez az oka annak, hogy külön kategoriaként kezeljük.) Egy intervallum-óra által kibocsájtott megszakítás azt jelenti, hogy az órán legutóljára beállított idő lejárt. Hasonló megszakítás keletkezhet a hardver-óra által kibocsájtott jeltől is. E megszakítás eredménye lehet egy vezérlés átadás egy másik folyamatnak. Programhiba m egszakítás akkor következhet be, ha a futó program valamilyen okból ”abnormálisan” viselkedik. Ilyenkor a legtöbbször egy hibaüzenet is megjelenik a felhasználói terminálon vagy az output listán. Néhány lehetséges programhiba megszakítás: • • • • • Zérussal való osztás. Aritmetikai művelet ereményeként túlcsordulás vagy alulcsordulás. Hivatkozás érvénytelen memóriaterületre. Kisérlet tiltott készülék

elérésére. Nem megfelelő adattipussal végzett művelet. A fenti műveleteket a felhasználó kezelni tudja oly módon, hogy a hiba fellépése esetén előírja, hogy milyen szubrutinnak kell futni. Ennek elmaradása azt eredményezi, hogy az OR nem érzékeli a hibát. Rendszer m egszakítás akkor következik be, ha a folyamatok valamelyike valamilyen kívánsággal fordul az OR-hez. Az ide tartozó megszakítások egyik fontos típusa a rendszerhívásból adódó megszakítás. A kiváltó ok minden esetben az, hogy egy folyamat megszakítás után át akarja adni a vezérlést a rendszernek, mivel a folyamatnak valami-lyen új szolgáltatásra van szüksége. Ilyenkor az OR mindig elemzi a kívánságot, és ha a készülék rendelkezésre áll, akkor átadja azt, ellenkező esetben blokkolja a folyamatot mindaddig, amíg a készülék fel nem szabadul. Készülék hib a m egszakítás annak a következménye, hogy a hardver működése során valamilyen rendellenesség áll

elő. Egy ilyen megszakítás jelezhet memória 77 elérési hibát, I/O készülék hibát vagy valami hasonlót. Az egyszerűbb OR-k esetében csak egyszerű hibajelzés történik, és a müvelet befejezőik, míg bonyolultabb rendszer megkisérlik kiküszöbölni a hibát, és a folyamatot tovább igyekeznek befejezni valamelyik alternatív komponenessel. Ha a megszakításokat más szempontok szerint osztályozzuk, akkor egy módszer lehet ha folyamat befejezési (mint pld. I/O, timer), szolgáltatás igénylő ( rendszer megszakítások), hiba kezelési (program vagy harver) megszakításokat különböztetünk meg. 8.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 Ilyenkor ugyanis az egyiknek prioritással kell rendelkezni. Ilyenkor a megszakítások sorosan hajtódnak végre. Egy másik lehetőség az, ha a

megszakításokat egymásba ágyazva hajtjuk végre: ilyenkor az alacsonyabb prioritású interrupt-ot megszakíthatja egy magasabb rendű jel. Időnként előforulhat, hogy bizonyos megszakításokat nem akarunk engedélyezni vagy el akarjuk kerülni azt, hogy egy megszakításban futó folyamatot egy másik megszakítás felfüggesszen. Ilyenkor a rendszerekben un megszakítás maszkolást alkalmazunk. A gyakorlatban ezt úgy hajtjuk végre, hogy egy megszakítás maszkolási regisztert használunk, amelyben minden bit egy specifikus megszakítást vagy egy megszakítás csoportot jelől. Egy másik lehetőség a kezelésre, ha a program status szóban baállíthatunk egy egy prioritási szintet, és csak azokat a megszakításokat fogajuk el, amelyek e szint felett helyezkenek el. (Ehhez persze a prioritásokat mindenképpen rendeznünk kell.) A maszkolással letíltott megszakítások mindaddig felfüggesztve maradnak, amíg a letíltás érvényben marad. Nem minden

megszakítástípus maszkolható. Gondoljunk például a rendszerhívásokra, vagy egy olyan esetre, amikor egy készüléknek karaktereket kell továbbítani a CPU-hoz és és a soron következő karakter továbbítása előtt az utoljár elküldöttet fel kell dolgoztatni a készülékhez tartozó megszakítás kezelővel. Ha az OR túl hosszú ideig blokkolja az ilyen tipusú megszakítást, akkor az utoljára továbbított karakter elveszhet. 8.3 Input és output készülékek kezelése Mivel az OR egyik legfontosabb feladata az, hogy ellenőrizze az I/O készülékeket, ezért meg kell ismerni a készülékek vezérlésének módszereit. A számítógépek rendelkeznek azzal a lehetőséggel, hogy képesek ellenőrizni és kommunikálni azokkal 78 a készülékekkel, amelyekkel össze vannak kötve. A kezdeti időszakban ezt úgy oldották meg, hogy I/O készülékekként ”testreszabott ” utasításokat építettek be a gépi kódú utasítások közé. Ma ez a módszer

a kapcsolható perifériák nagy száma miatt nem követhető. Helyette az un I/O interface technikát alkalmazzák E módszernek az a lényege, hogy a készülékeket a regiszterek egy halmazán át érik el. (Ezeket nevezik készülékregisztereknek.) Minden készülékregiszterhez egy egész számot rendelnek hozzá, amely azonosítóként szolgál a rendszer hardver ill. szoftver elemei számára, címként használható az I/O készülékhez. Ezt a számot nevezzük csatorna sorszámnak vagy port sorszámnak. Mivel a készülék regiszterekben címeket tárolunk, ezért ezekkel címeket lehet elfoglalni a memóriában. Ez az un I/O terület Általában ez különbözik az egyéb memória területektől, de nem kizárt az sem, hogy ezekkel közös területet foglalnak el. (Ekkor beszélünk memória beágyazott memory mapped I/O-ról.) Ilyenkor nincs szükség már külön I/O utsításokra, egységes műveleteket használunk a készülék regiszterekbe történő írásra és

az olvasásra. A különbséget mindig a címek adják, amivel az egyes készülékekhez tartozó memóriaterületre hívatkozunk. Komoly nyeresége ennek a technikának, hogy itt az egyszerű adattranszfer-műveleteken túl aritmetika és logikai műveleteket végezhetünk a készülékregiszterek tartalmain. Az előnyök mellett jelentkező hátrány az, hogy mivel ezek az utasítások teljesen azonos elbírálás alá esnek a többivel, ezért a speciális utasítások védelmét nem élvezik, így a véletlen hibák lehetősége megnő. Három stratégiát különböztetünk meg a készülékek kezelésére attól függően, hogy milyen a tekintett I/O készülék típpusa, és milyen a rendelkezésre álló számítógép architekturája. A. Egyszerű I/O stratégiáról vagy programozott stratégiáról akkor beszélünk, ha kisvagy közepes méretű számítógépekkel olyan készülékeket vezérelünk, amelyek karakterenként képesek fogadni az átvitt információt.

Ilyenkor 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 azt B. Blokk átvitelről szintén kis ill közepes számítógépek esetében beszélünk, amikor olyan készülékekre akarunk adatot továbbítani, amelyek nagy blokkokat képesek fogadni nagy átviteli sebességek mellett is. (Ilyen készülékek például a mágnesszalagok vagy a mágneslemezek.) Ebben az esetben az I/O interface szerepét egy I/O controller tölti be, amely elegendő saját tárterülettel és ellenőrző logikai áramkörrel rendelkezik ahhoz, hogy az egész átviteli blokk mozgását ellenőrizni tudja. Az átvitel során a controller össze van kötve a memóriával Ezt nevezik közvetlen elérési tech nikának (direct access memory, DMA). Az átvitel során a CPU annyi információt küld a controllernek, amely elegendő ahhoz, hogy az a blokk-transzfert el tudja végezni. Ezután a CPU az átviteltől

független munkát végez, míg a controller végrehajtja az adattovábbítást a kijelölt készülékre. C. Nagyobb számítógépeken az I/O processzorok at használják az adatátvitelre Itt a készülékek egy-egy olyan speciális célú processzorral vannak összekötve, amely alkalmas utasításokkal rendelkezik a közvetlen I/O műveletekhez. Általában készülékcsoportonként használunk egy ilyen processzort. Maguk a processzorok 79 olyan felépítésűek, hogy csak korlátozott számú utasítást értenek meg, e azokat nagy sebességgel képesek végrehajtani. Amikor I/O adaátvitelt hajtunk végre, akkor nagyon oda kell figyelni a kommunikácóra. Minden egyes új átvitel előtt a CPU-nak tudnia kell, hogy a készülék készen áll-e az adatátvitelre. Az egyszerű készülékek esetében ezt a készülék választás technikájával oldják meg. (Ez az un device pollin g) Ilyenkor a státusz értékeket időszakonként megvizsgálja a CPU annak eldöntésére,

hogy az aktuális I/O művelet befejeződött-e. Mivel ez az eljárás nem hatékony, ma már egyre ritkábban használják. A másik lehetőség az, ha I/O befejezési megszakítást használunk annak a jelzésére, hogy a szóbanforgó I/O művelet befejeződött, és a készülék készen áll a további kommunikációra. Ennek a résznek a végén szólni kell egy további fontos technikáról, amely szorosan összefügg az I/O készülékek használatával: Sok 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. Gondoljunk például az olyan aszinkron típusú kommunikációs interface-re, mint a személyi számítógépek billentyűzet kezelése. Itt az adattranszfer úgy zajlik le, hogy a készülékről érkező jel egy pufferbe kerül, és a készülék azonnal készen áll a következő karakter fogadására anélkül, hogy vizsgálná azt, hogy a az előző karaktert a CPU

feldolgozta vagy sem. Ahhoz, hogy ne legyen smmilyen problémánk a CPU-nak fel kell dolgoznia az előző karaktereket mielőtt a puffer teljesen megtelne. A puffernek két fajtáját különböztethetjük meg: hardware pufferről beszélünk, ha az a készülék controller-jében foglal helyet, és software p uffert kell készítenünk, ha a hardver puffer a kontroller-ben nem áll rendelkezésünkre. 8.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 Az ilyen típusú készülékeknél a váltóáram frekvenciája szabályozza az óra működését. A programozható órák egy számláló regiszterrel rendelkeznek, amelynek tartalma meghatározott időközönként csökkenthető. Amikor a tartalom 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ájt 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. Az órák és a különböző időzítők kezelésével számos felhasználói igényt tudunk kielégíteni. A következőkben ezek közül felsoroljuk a leggyakrabban előfordulókat: 80 • A napi idő kezelése magába foglalja a napi időt mutató óra kezelését beleértve annak a képességét, hogy az óra ütemeket (ami 1/60 másodpercenként jelez) átalakítjuk másodpercekre, percekre és órákra. Ez a funkció használható fel a dátum kezelésére is. • Rendszer foly amatok figy elése is időzítők segítségével oldható meg bizonyos esetekben. Ha egy input készülékről akarunk beolvasni, és előfordulhat, hogy egy bizonyos ideig nem kapunk választ, akkor az OR számára be kell állítanunk egy időtúllépési intervallumot, amelynek letelte hibaüzenetet

indukálhat a készülék driver-jében. • Folyamatok felfüggesztése egy megadott időszakra gyakori feladat az OR számára. Ilyenkor a folyamat megszakításával egyidejűleg egy timer kerül beállításra, és a beállított időintervallum lejárta után a folyamat az un. ”alvó” állapotból visszakerül a készenléti állapotba. Ugyanez a felfüggesztési folyamat játszódhat le, ha egy adott napszakra akarjuk felfüggeszteni a futó folyamatot, csak ebben az esetben a valós időt figyeljük. • Számos OR támogatja azt a lehetőséget, hogy egy folyamatot ne azonnal a betöltés után indítsunk e l, hanem valamikor a jövőben egy meghatározott időpont bekövetkezésekor. A legelterjetebb technika az ilyen feladatok megoldására, ha egy ”indító” folyamatot rendelünk a később aktivizálandó tevékenységhez, és ezt felfüggesztett állapotban tartjuk mindaddig, amíg az indítási időpont be nem következik. Előfordulhat az, hogy az időzítőhöz

rendelt szolgáltatást meg kell szakítani. Egy felhasználói folyamat csak akkor engedi meg az időzítőkhöz kötött folyamatok megszakítását, ha az éppen aktív. Ezért ezt ellenőrizni kell Ahhoz, hogy az ellenőrzés folyamatát megértsük, szükségünk van annak megismerésére, hogy hogyan kezeljük a megjelenő időzítőkhöz rendelhető igényeket az OR-n belül. Mivel egy multiprogramozható környezetben egy időben több megszakí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. Ezért az ilyen igényeket egy időzítő-sorba (timer queue) helyezzük el, és ezt a sort a folyamatok kezeléséhez generált sorhoz hasonlóan feldolgozzuk. Egy ilyen elemnek tartalmaznia kell a következő információkat: • • • • • Pointer a sor következő elemére. Időparaméter értéke (lásd később). Az időponthoz rendelt folyamat PCB-jének címe.

Pointer a megkívánt műveletet végző eljárás elejére. Az igény típusa. A sorban az elemeket a megjelölt időparaméter szerint növekvő sorrendben rendezve 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. Ha csökkenteni akarjuk a tárolt értékeket, akkor csak azokat az értékeket tároljuk az 81 elemekben, amennyi időnek a két hívás között el kell telni. Ezek az un idő kvantumok. Mivel az igényelt időpontok mindig az aktuális időpontra vonatkoznak, ezért sarkalatos kéré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. Ha idő kvantumokat használunk, akkor elegendő a sor legelső elemének időparaméterét csökkenteni minden óra-ütemhez rendelt

megszakításkor. Ha ez az érték zérus lesz, akkor az elemhez rendelt folyamatot végrehajthatjuk. (Ha pontos algoritmust akarunk, akkor meg kell vizsgálnunk a sor következő elemét is, mert elvileg több igény is tartozhat ugyanahhoz az időponthoz.) Az elemet kitöröljük a sorból, és a pointereket átállítjuk. Ugyancsak érdekes kérdés, hogy egy már létező idő-sorhoz hogyan csatolunk új elemet, illetve abból hogyan törlünk eleme(ke)t. Mivel ezek kezelése az általános sorkezelési eljárásoktól semmiben sem különbözik, ezért itt nem tárgyaljuk e műveleteket részletesen, hanem ennek vizsgálatát az érdeklődő hallgatókra bizzuk. Ezek után visszatérhetünk annak az esetnek a vizsgálatához, hogy hogyan lehet megszakítani egy időpont által vezérelt, futó folyamatot: mivel a sor egy eleme tartalmaz pointert az igényelt folyamat PCB-jére, ezért az elem könnyen megtalálható, így az egyszerűen eltávolítható a sorból, miközben az

eltávolított elemet követő elemek tartalmát a törlés szabályainak megfelelően aktualizáljuk. 82 9. 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ő. Még a lemezes OR-k időszakában is kimerült abban, hogy a speciális készülékek kezeléséhez könyvtári szubrutinokat írtak, amelyeket akkor töltöttek a memóriába, ha azokra éppen szükség volt. A mai többfelhasználós OR-k esetében az I/O ilyenfajta közvetlen ellenőrzése nem megoldható. Ezért a szolgáltatások olyan irányba fejlődtek, hogy minden készülék teljes ellenőrzése ( az I/O parancsok kiadása, a megszakítások feldolgozása, a hibák érzékelése és megszümtetése stb.) a rendszeren belül történik. A felsoroltak mellett az OR-nek kell figyelni az I/O készülékekre várakozó folyamatokat, az egyes befejezéseket,

ütemeznie kell a soron következő I/O műveletet, és végre kell hajtania a különböző olyan változtatásokat, amelyeket az I/O események okoznak. A fenti rendkívül összetett feladatot minden egyes I/O készülékre egy elem végzi az OR-n belül: a készülék meghajtó program (device driver). Mivel az egyes számítógépes architekturákhoz csatlakoztatható perifériák száma renkívül magas, ezért a speciális meghajtó programokra az installációk során nagyon nagy szükség van. Ebben a fejezetben először a fizikai I/O készülékek típusait mutatjuk be, majd az I/O készülékekeket a számítógépes rendszerekkel összekapcsoló interface-k jellemzőit ismertetjük. Ezután a meghajtókkal szemben támasztott általános követelményeket tárgyaljuk. A fejezetet a különböző I/O készülékekre alkalmazható programozási technikákkal zárjuk. 9.1 Az I/O készülékek jellemzői Ahhoz, hogy egy meghajtót illeszteni tudjunk egy megadott I/O

készülékhez, ismernünk kell az adott perifériát. Mivel azt eddig is feltételeztük, hogy az olvasó az alapvető számítógépes icmeretekkel rendelkezik, ezért most csak röviden összefoglaljuk az egyes I/O készülék típusok főbb jellemzőit. Az I/O készülékeket alapvetően három csoportba oszthatjuk: • Tároló típusú készülékek. • Terminálok. • Nyomtatók 90 9.11Tároló típusú készülékek A ma működő számítógépes rendszerek gyakorlatilag csak ilyen típusú készülékeket használnak a file-rendszerek tárolására. A kezdeti időszakban a mágnesszalagok voltak a legelterjedtebbek, de a soros hozzáférés nagymértékben korlátozta a felhasználhatóságukat. Ma többnyire mentésre és archíválásra használjuk ezeket A mágnesszalagokat a gyorsabb, véletlen eléréssel rendelkező mágneslemezek váltották fel. Az utóbbi iőkben gyorsan terjedő optikai készülékek ötvözik a gyors, véletlenszerű elérést a nagy

kapacitással. Bár ma még többnyire csak olvasásra használható optikai lemezeket használnak, de már megjelentek a többször írható adathordozók is. Mágneses típusú készülékek alapja egy plasztik anyag, amelyre vékony rétegben mágneses felületet hordanak fel. E felület egy vékony sávjára (track) kerül a mágneses információ, amelyet iró fejjel elekromos úton rögzítenek meghatározott jelsűrűséggel. Az így rögzített információt olvasó fej jel lehet kiolvasni, ha az információt horozó réteg elhalad az olvasó fej előtt. A legtöbb ilyen típusú adathordozón maghatározott helyre ellenőrző információt kell elhelyezni, amely segíti az író/olvasó fej pozícionálását a kijelölt helyre. A kijelölt információk felírását formattálásnak nevezzük. Formattálni minden mágneses adathorozót kötelező az ”üzemszerű” használat előtt. Fontos tulajdonsága a mágneses adathordozóknak, hogy az információkat blokkokba

csoportosítva tároljuk. Ezeket a blokkokat egységes egészként mozgatjuk az adattranszfer során. Mágnesszalagok esetén az információt 9 sávban írják a szalagra. (8 sávra bitenként kerül 1 byte információ, míg a 9.-re elleneőrző un paritás bitet irhatnak.) Mágneskazettáknál egyetlen sávon sorosan helyezkenek el az információk Ezeknél a készülékeknél a mágnesszalag mozog a fej előtt, és egy olyan információt, amely az olvasó fej mögött van, csak úgy lehet elérni, hogy visszatekerjük a szalagot a kezdeti pozícióba, és újraindítjuk a keresést. Íráskor még nagyobb hátrányunk lehet: a legtöbb szalagos készüléknél adatok írásakor az írófej mögötti információt leromboljuk. Mágneslemezek esetében a vékony mágneses rétegre koncentrikus körökben visszük fel az adatokat többnyire a lemez mindkét oldalát kihasználva. A sávokat tovább osztjuk szektorokra. (Ezek többnyire 256 byte információt tartalmaznak) A

különböző lemezeken elhelyezkedő azonos sugarú koncentrikus körökön talaálható sávok összességét cilindernek nevezzük. A lemez nagy sebességgel forog a kombinált (író/olvasó) fejek között. Nagy mágneslemezek esetén a fej mozgatás típusa szerint megkülönböztetünk fix- ill. mozgófejes típusokat Ha a fejek rögzítve vannak, akkor minden sávhoz külön fej tartozik. Mozgatható fejek esetén lemezfelületenként található egy fej, amelyet az információ eléréséhez először a megfelelő sáv fölé kell mozgatni, és csak azután kereshető a kért információ. A hagyományos mágneslemez egységekben az író/olvasó mechanizmus fixen be van építve, de a lemezkötegek cserélhetők. Újabban két típus jelent meg a piacon A Winchester lemezek olyan nagy pontosságú, zárt egységben forgalomba hozott lemezek, amelyekben az író/olvasó mechanizmus egybe van építve a lemezekkel és az elektronikával. A gyártási 91 technológiának

köszönhetően igen nagy írássűrűség érhető el ezeken az adathorozókon. A hajlékony lem ez olyan technológiára épül, amely egyetlen hajlékony felület egy oldalát vonja be mágneses anyaggal. Vezérléstechnikai szempontból fontos, hogy a hajlékony lemezeknél fellép az un. szektor elhagy ás jelensége. Ennek az a lényege, hogy egy szektornyi adat átvitelének megkezésekor késedelem lép fel, ami meggátolja azt, hogy fizikailag egymás mögött elhelyezkedő szektorokat folyamatosan olvasni tudjunk. Ezért a szektorokat logikailag úgy sorszámozzák, hogy a folyamatos olvasás lehetővé váljék: ilyenkor az egymást követő sorszámmal rendelkező szektorok egymással szemben helyezkenek el a lemezen. Optikai tárolók az audio technikában jól ismert compact lemezekkel azonos felépítéssel rendelkeznek. Ezeknek az eszközöknek alapja üveg vagy valamilyen üvegszerű anyag, amely olyan anyaggal van vékonyan bevonva, amelynek optikai tulajdonságai

lézer sugár hatására megváltoznak. Amikor a felületet lézersugárral pásztázzuk, akkor az előírt módon megváltozik, buborékokat és gödröket alakítva ki. Ezek a felületek aztán másként verik vissza a fényt, mint az eredeti felület. Az optikai tárolók esetében az információ egy hosszú spirál mentén helyezkedik el. Ezen a spirális sávon minden blokk hasonló hosszúságú helyet foglal el. Ennek az az előnye, hogy nagy sűrűséggel írhatjuk az adatokat, de ugyanakkor bizonyos hátrányokat is hoz magával: bonyolulttá teszi a blokkok elhelyezését, és más forgási sebességet kíván meg belső ill. külső sávokon elhelyezkedő adatok átvitelére Az optikai tárolók legnagyobb előnye a nagy kapacitás, hátránya az, hogy többnyire csak egyszer írható adathordozókat használnak. Ez az un WORM technika (write once, read mostly). 9.12 Terminálok Készülékeknek széles választéka áll renelkezésünkre ahhoz, hogy megjelenítsünk

adatokat, és azokat a számítógépbe továbbítsuk. Ezeknél a készülékeknél az adattovábbítás lassúbb, mint a tároló típusúaknál, és gyakran speciális karaktersorozatokat használunk a készülékek ellenőrzéséhez. A terminálok rendelkeznek billentyűzettel az adatok beadásához, és valamilyen képernyővel az információ megjelenítéséhez. A terminálok a számítógépekhez a leggyakrabban vagy RS-232 soros in terface-szel vagy memóriába beágyazott képernyő segítségével kapcsolódnak. A. Az RS-232 soros interface Az RS-232 interface egy olyan szabvány, amely az Electronic Industries Association által lett kifejlesztve soros vonalon lefolytatott kommunikácóhoz. A lényege az, hogy azokat a nyolc bites kódokat, amelyeket karakterek kódolására fejleszettek ki, át kell alakítani bitsorozatokká, hogy speciális közegen (pld. csavart érpáron, telefon vonalon) továbbíthatók legyenek. Időközönként még további eszközökre is

szükség van a digitális jelek átváltoztatására. Ilyen lehet egy modem (modulator/demodulátor). Egy ilyen készülék 300 és 19200 bit/másoperc (bps) 92 sebességgel képes jeleket továbbítani. Az RS-232-es vonalon kommunikáló termináloknak két típusát különböztetjük meg: • A buta term inálok egy időben egy karaktert képesek fogadni a terminálon a számítógép irányából. Az ellenkező irányú kommunkáció során a billentyűzetről a terminálhoz érkező karaktert automatikusan kiírjuk a képernyőre (echo), majd a jelet továbbítjuk a számítógéphez. Egy fokkal bonyolultabb az a kommunikáció, amikor a ”beütött” karaktert először továbbítjuk a számítógéphez, azt visszaküldjük a terminálhoz, és ezt a jelet írjuk ki a képernyőre. Az ilyen típusú terminálokra ttyként hívatkoznak a modern OR-k • A pufferes term inálok belső memóriával rendelkeznek, amelyben egy vagy esetleg több képernyőhöz tartozó adatot

képesek tárolni. Ezt a nagymennyiségű információt egy üzenetközvetítő nyelv (protocol) segítségével továbbítják a számítógépről a terminálhoz. A gép és a terminál között egyszerre egy teljes képernyő adatai mozognak, ezért a párbeszéd is, és a hibák felderítése is sokkal összetettebb, ami jelentősen bonyolítja az ilyen típusú készülékekhez készült meghajtókat. B. Memória beágyazott terminálok Ezek a terminálok a címezhető memória egy részét használják fel a képernyőhöz tartozó adatok tárolására. A memóriának ezt részét video RAM-nak nevezikAz IBM PC-khez tartozó karakter típusú display minden karakteréhez két video RAM érték tartozik: az elsőben tárolják a karakter ASCII kódját, míg a második specifikálja a karkterhez tartozó attributumokat (fényességi fokozat, szín, típus, villogás stb.) Ha a képernyő grafikus (bit-mapped display), akkor a video RAM minden egyes bitje felel meg a képernyő

egy-egy pontjának (pixel). Fontos megjegyezni, hogy a grafikus képernyőnél a billentyűzet minden látszat ellenére nincs közvetlen összeköttetésben a képernyővel. Itt a billentyű leütése egy megszakítást eredményez, és a beütött adatot a billentyűzet input kezelő (handler) dolgozza fel. Mivel egy átlagos billentyűzeten számos speciális gomb ill gombkombinációt kell kezelni, ezért billentyűzethez rendelt meghajtó lényegesen bonyolultabb az itt vázoltaknál, de a technika megértéséhez az itt leírtak elegendőek. 9.13 Nyomtatók A ma használatos nyomtatókat három fő csoportra osztjuk a működési elvük alapján: • Tűs nyomtatók kalapáccsal ütik meg a nyomtatófejen elhelyezkedő apró tűket, és egy festékszalag segítségével írnak a papírra. Nagyobb teljesítményű nyomtatók sorokat állítanak be, és az így előkészített adatokat nyomtatják ki. • Tintasugaras n yomtatóknál egy mátrixfelület meghatározott pontjaira

festékanyagot juttatnak, és elektrosztatikus úton ezt festékponot ”átlövik” a papírra. • Lézernyomtatók esetében egy dobra egyenletesen festéket hordanak fel, amelyre lézersugárral pásztáznak a kiírandó adatoknak megfelelően. Az így elktrosztatikusan feltöltött porszemeket aztán átégetik a papírra. 93 A fenti típusú nyomtatók - a technikai eltéréseken túl - abban térnek el egymástól, hogy különböző felbontásban képesek jeleket írni a papírra. (A tűs nyomtatók 150-200 dot/inch (dtp) felbontása mellett az átlagos képességű tintasugaras nyomtató 300 dtp, míg a lézernyomtató 600 dtp felbontásra képes.) A változó nagyságú betűk, a különböző nagyítási technikák (true-type) a nyomtatókhoz tartozó meghajtókat egyre bonyolultabbá teszik. Annak ellenére, hogy a nyomtatók a soros interface-n is csatlakoztathatók a számítógépekhez, a legelterjedtebb az, hogy párhuzamos in terface-n tartják a kapcsolatot

egymással. 9.2 Készülék meghajtó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ék m eghajtónak (device drivernek) nevezünk. Az ORnek 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. Egyes rendszerekben a meghajtók a kernel részei, így nem csatolható dinamikusan egy új készülékhez tartozó meghajtó a rendszerhez. Ilyenkor a teljes OR-t újra kell installálni Más rendszereknél a meghajtók független modulokként csatlakoznak a rendszerhez, állományokként tárolják őket lemezeken, és akkor töltik be a memóriába, amikor az OR-nek szüksége van rájuk. Az ilyen rendszereknél a készülékekről külön táblázatot tartunk fenn, amelyben elemenként tároljuk a hozzájuk tartozó információkat (pld. a készülék

típusa, neve, a meghajtó neve, a meghajtó helye a lemezen stb.) Ha egy ilyen rendszerhez új készüléket akarunk illeszteni, akkor legtöbbszőr egy install utasítást kell használni, amely telepíti a meghajtót a kívánt helyre. Fontos megjegyezni, hogy ha azonos típusú készülékből többet csatlakoztatunk a számítógéphez, akkor általában elegendő egy készülék meghajtót installálni. Néhány meghajtó olyan készüléket kezel, amely nem áll fizikailsg rendelkezésre. Ezeket a készülékeket virtuális vagy software készülékeknek nevezzük. A legismertebb példák egyike az, amikor - PC-s környezetben jól ismert módon mágneslemez egységet szimulálunk a főtárban. A művelet célja az, hogy kis rendszerek esetében egy felhasználói software hatékonyságát megjavítsuk. A szimulált lemezegységet szokás RAM-disknek nevezni. A virtuális készülékekre egy másik példa a spooler használata. E virtuális készüléket nyomtatóként

használjuk a fizikailag ténylegesen létező output egység helyett. A cél itt is az, hogy megjavítsuk a rendszer hatékonyságát, mert a felhasználónak nem kell várnia arra, hogy a nyomtató befejezze az előző anyag listázását, és felkészüljön a következő fogadására. Azért, hogy a különböző meghajtókat egyszerűbb legyen megírni és installálni, kézenfekvő az az ötlet, hogy az OR-k olyan felülettel rendelkezzenek, amely azonos 94 szabályok alapján megírt meghajtókat könnyebben befogad. Néhány OR preferálja az un. készülék független meghajtókat, amely alapján többé-kevésbé azonos strukturájú meghajtók készíthetők tetszőleges készülékekre. A UNIX esetében például alapvetően két csoportra osztjuk a készülékeket: karakter típusúak (printerek és terminálok) illetve blokk típusúak (mágnes szalagok ás mágneslemezek). Ezekre az osztályokra az a jellemző, hogy annak ellenére, hogy a készülékek nagyon

különbözőek lehetnek, a hozzájuk rendelt meghajtók teljesen azonos szerkezetűek. Ez a felhasználó oldaláról azt jelenti, hogy ne kell foglalkoznia az I/O készülék konkrét típusával a programozás során, mert a beprogramozott művelet minden olyan készülék esetén aktivizálható, amely a műveletet támogatja. 9.3 Interface-k és jellemzőik A készülékek ellenőrzésének a mechanizmusa számítógép típusonként nagyon eltérő lehet. Ami mégis közös, az az, hogy egy I/O interface szolgáltatja a kapcsolatot a készülék és a rendszer maradék része között. A legegyszerűbb ilyen eszköz a mikroszámítógépeken alkalmazott soros és párhuzamos interf ace, amelyek segítségével adatokat továbbíthatunk nyomtatókra és terminálokra. Technikailag a különbség a két típus között az, hogy a soros interface-nél egy vezetéken bonyolódik az adatátvitel: egy bit egy időben, míg a párhuzamos interface-nek több vezeték áll a

rendelkezésére, és így mindegyiken képes egy bitet továbbítani egy adott időpillanatban. Az I/O interface-k egy bonyolultabb csoportjába tartoznak az I/O controller -k, amelyek többek között: • Képesek közvetlen memória elérésű (DMA = Direct Memory Access) adatátvitelre, azaz adatot továbbítanak a memória és egy készülék között anélkül, hogy a felhasználói programban ezt külön programozni kellett volna. • Támogatják annak a lehetőségét, hogy egy logikai készülék fizikailag több egységet tartalmazzon (multiple device). • Támogatják az átlapolt ellenőrző műveletek alkalmazását azáltal, hogy megengednek pl. egy keresést a lemezen miközben egy másik meghajtó adatokat ír ki egy nyomtatóra. A készülék kezelés nagyobb számítógépeken (mainframe-ken) támogatott mechanizmusa az I/O p rocesszorok alkalmazása. Az IBM gépek esetében a processzort csatornának (channel) nevezik. Egy csatornára több controller

kapcsolható, és minden csatorna saját gépi kódú nyelvvel rendelkezik a hatékony programozáshoz. Az I/O parancsokat egy csatorna programban fogjuk össze, amely az IBM 370-es architekturában rezidensként helyezkedik el a memóriában. Amikor egy csatorna programot aktivizálni akarunk, akkor a csatornán elküljük ennek a csatorna programnak a címét egy un. SIO (start I/O) paranccsal A végrehajtható csatorna parancs szavakat (channel command words = CCW) DMA technikával olvassuk be, majd a csatorna végrehajtja ezeket azáltal, hogy a kiválasztott controller-t felhasználja. 95 9.4 Programozási technikák Ha készülék meghajtót akarunk írni, akkor a programozás során különböző tecnikákat használunk fel a gazdaságos üzemeltetés érdekében. Ezek mindegyikét azért fejlesztették ki, hogy az átvitelt felgyorsítsák. A bemutatandó eljárások egy része csak egyfelhasználós környezetben használható míg mások univerzálisak abban az

értelemben, hogy többfelhasznás OR-k is alkalmazni tudják. 9.41 Adatstrukturák Mielőtt bemutatnánk a technikákat, érdemes megismerni azt, hogy milyen adatok tárolására van szükség ahhoz, hogy a meghajtók biztonságosan tudják kezelni a készülékeket. Azt az egységet, amelybe ezeket az adatokat elhelyezzük I/O control blokknak nevezzük. A következőkben a teljességre való törekvés nélkül felsoroljuk a legfontosabb adatokat. Teljességre azért sem törekedhetünk, mert a tárolt adatokat nagymértékben meghatározza az, hogy milyen környezetben használjuk a meghajtót, és az is, hogy milyen optimalizálási feltételeknek akarunk elsősorban megfelelni. Készülék név Csatorna szám Megszakítás kezelő ccíme Készülék cím Csatorna cím Open szubrutin címe Készülék típus Megszakítási vektor címe Close szubrutin címe Start szubrutin címe Puffer méretek Hiba kezelő blokk címe Cancel szubrutin címe Aktuális puffer pointer stb.

Puffer címek Aktuális I/O művelet A helyzetet az bonyolítja, hogy minél jobban akarjuk megoldani a készülék kezelését, annál több segédadatra van szükségünk a control blokkban, ami egyre nehézkesebbé teheti az algoritmusunkat. 9.42 A polling technika Ez a technika általában egyszerű környezetben, egy felhasználós operációs rendszereknél használatos. A technika lényege az, hogy az OR mindig megszólítja az adott készüléket mielőtt a következő I/O utasítást kiadná. Ha a parancsot kiküldtük a készüléknek, akkor a következő I/O utasítás kiadása előtt meg kell győződnünk arról, hogy az előző műveletet befejeztük. Ha az I/O készülék karakter típusú, akkor az esetek többségében egy pufferen át történik az adatátvitel, és ilyenkor a lekérdezést addig kell folytatni, amíg a puffer teljes tartalmát át nem küldtük a központi tárból a készülékre. Ha a készülék státuszát ciklusban kérdezzük le, akkor

beszélünk polling- 96 ról. A ciklus belsejében két alapvető ok lehet arra, hogy ne továbbítsunk karaktert: vagy készülék hiba áll fent vagy az egység nem áll készen az adattovábbításra. Egyszerű algoritmusok esetében a tényleges adattovábbítást csak az állapotlekérdezés előzi meg, míg bonyolultabb esetben további előkészítésre is szükség van. Egy mágneslemezes olvasás esetében például két lépcsőben hajtódik végre egy olvasás a mágneslemezről: először kiadunk egy read sector utasítást, amely a mágneslemezről az adatokat a lemezegységen elhelyezkedő lokális pufferba továbbítja, majd egy empty buffer utasítással a lokális pufferből az adatokat átrakjuk a központi tárba. Mivel minden egyes lépés során ellenőriznünk kell a végrehajtást, ezért egy kérdés-válasz sorozat zajlódik le az OR és az I/O készülék között. (Az ilyen ”társalgást” a számítástechnikában protokolnak nevezzük.) Azok a

rendszerek, amelyek polling technikát használnak a meghajtók programozása során, nem képesek kezelni a megszakításokat. Ennek az a következménye, hogy a CPU-t sokáig lefoglalja a polling ciklus annak vizsgálatára, hogy a készülék felszabadult-e. Mivel a többfelhasználós rendszereknek az egyik legfontosabb jellemzője az, hogy bizonyos programok akkor futhatnak, ha mások amiatt vannak blokkolva, mert egy I/O készülékre várnak, ezért a polling technika ilyen környezetben nem használható. (Hiszen a várakozási időben a polling program fut ahelyett, hogy átadná a lehetőséget más folyamatok számára.) 9.43 Megszakítási technika Ha egy készülék kezelése során megszakítási technikát használunk, akkor a meghajtónak megengedjük, hogy végrehajtson egy I/O műveletet és utána visszatérjen ahhoz a folyamathoz, amely az I/O műveletet igényelte. Ebben az esetben egy készülék megszakítás kezelőt (device interrupt handler) kell beépíteni a

meghajtó programba. A megszakítás kezelőre akkor kerül a vezérlés, ha valamelyik készülék megszakítás jelet ad ki. Egyszerű rendszerek esetében a megszakítást egy flag (az esemény flag) jelzi, míg bonyolultabb rendszerekben az esemény bekövetkezését egy leíró blokkban (esemény control blokk) rögzítjük. Ez utóbbi lehet a PCB része is Amikor egy I/O műveletet megszakítással hajtunk végre, akkor a rendszer először beállítja a flag-t (vagy a blokkot) és aztán átadja a vezérlést a megszakítás kezelőnek. Ha a rendszer egy iőben csak egy folyamatot kezel, akkor a megszakítás kezelő visszaadja a vezérést annak a programnak, amelyet megszakított, és folytatja annak végrehajtását. Többfelhasználós környezetben a megszakítás lehetőséget ad arra, hogy környezet átállítást végezzünk az I/O művelet végrehajtása után. Ekkor a vezérlés nem adódik vissza okvetlenül a hívó programnak, hanem átkerülhet az OR-hez, amely

meghívja az ütemezőt, és ez kijelöli a következő programot a CPU használatára. 9.44 Pufferek alkalmazása Az előzőek során már említést tettünk arról, hogy a készülékek holtidejének csökkentésére, az áteresztőképesség növelésére gyakran használnak a meghajtók programozása során puffereket az adatok átmeneti tárolására. Különböző pufferelési technikákat fejlesztettek ki. Ezek közül néhányat megemlítünk az alábbiakban 97 A. Blokk-pufferelési technikát használnak karakter típusú I/O készülékek esetében A legtöbbszőr logikai rekordok vannak összekapcsolva egy fizikai rekordban, és csak egy logikai rekordot mozgatunk a pufferből a végrehajtó folyamat által megkövetelt helyre ha azt használni akarjuk. Ez különösen hatásos szekvenciális rekord műveletek esetében. A rekordok elérése ekkor többnyire un FIFO technikával történik B. Körkörös lista esetén a fizikailag utolsó karakter (rekord) betöltése

után a soron következő karaktert a lista fizikailag első helyére töltjük (amennyiben az szabad). A beírás és a kiírás pontos helyének a jelölésére mutatókat használunk: nevezzük ezeket BEÍR és KIOLVAS pointereknek. A BEÍR tehát arra az első szabad pointerre mutat, amelybe a megszakítás kezelő a következő karaktert elhelyezheti, míg a KIOLVAS azt a helyet jelöli, ahonnan a soron következő karaktert kiolvashatjuk a folyamat számára. (A szemléletesség kedvéért az egész puffert úgy képzelhetjük el, mintha egy gyűrű forogna körbe, amelynek egyik oldalán egy megfelelő rekeszbe betöltjük a karaktert, majd a gyűrű elforulása után miután a rekesz egy megfelelő helyre ért a rekesz tartalmát kiolvassuk. Ezért szokták ezt a fajta tárolót gyűrű puffernek nevezni) A jó kezelhetőség kedvéért a pufferben lévő nem kiolvasott karakterek számát és a gyűrű méretét is tároljuk, hogy figyelni tudjuk azt, hogy mikor lesz a

puffer tele ill. üres C. Kettős pufferezési technikát használnak abban az esetben, amikor egy készülék kezelő szubrutinnak több optimalizálási feltételt kell kielégíteni. Ilyenkor az egyik puffert pl. a CPU használja fel, míg a másikba írhatunk vagy olvashatunk a készülékről. Ez a technika különösen hasznos lehet akkor, ha nem tudunk blokkolni vagy a felhasználható blokkméret túl kicsi. Ha ilyen technikát használunk, akkor lehetőség van az aszinkron I/O műveletek alkalmazására, ami azt jelenti, hogy egy rendszer hívás során a vezérlés a lehető leghamarabb visszakerül a hívó programhoz. Ez sokszor még azelőtt megtörténik mielőtt a művelet ténylegesen befejeződne. 9.45 Cache használata Megjavíthatjuk a készülékek hatékonyságát azáltal, hogy néhány írási vagy olvasási műveletet megtakarítunk un. cache memória használatával E technikának két típusát különböztetjük meg: - Hardware c ache-ről akkor beszélünk,

ha egy gyors memóriát helyezünk el a központi tár és a CPU regiszterek közé azért, hogy a CPU-ból az ezekben tárolt adatokat gyorsabban elérhessük. - Software cache -t gyakran használnak lokális hálózatoknál disk file szerverek esetében. Ilyenkor a gyors elérést azáltal biztosítjuk, hogy software eszközökkel szimuláljuk a hardware cache-t: puffereknek egy halmazát tartjuk fent azért, hogy az éppen beolvasott (vagy kiírt) rekordokat ezekben helyezzük el. A módszer alapgondolata az, hogy a rekordok olvasását nem közvetlenül a lemez egységről hajtjuk végre, hanem először megkíséreljük elérni ezeket valamelyik pufferben. Ha a rekordot nem tároljuk éppen egyikben sem, akkor végrehajtjuk a beolvasást, de nem a hívó program adatmezőjébe, hanem a pufferek egyikébe, és innen olvassuk be a felhaszná98 lói területre. Kiíráskor hasonlóan járunk el: nem közvetlenül a lemezterületre írunk, hanem egy szabad puffert használunk az

átmeneti tárolásra abban a reményben, hogy ezt a rekorot a közeljövőben ismét fel fogjuk használni. Kiíráskor előforulhat, hogy nincs éppen szabad puffer. Ekkor az algoritmus felszabadít egyet azáltal, hogy a tartalmat visszaírja a lemezre. A felszabadítanó puffer kikeresésére többféle algoritmus ismert. Az igazságosság elvének a betartása legtöbbször azt eredményezi, hogy azt a puffert fogjuk felszabaítani, amelynek tartalmát a legrégebben nem használtuk már. (Arra gondolva, hogy ezt talán nem is fogjuk már használni a közeljövőben.) A software cache használatának az egyik legnagyobb hátránya, hogy rendszer meghibásodás esetén a ki nem írt puffertartalmak elvesznek. Ez ellen a jobb rendszerek úgy védekeznek, hogy időszakonként automatikus mentést hajtanak végre a cache területről. Az ilyen típusú cache kezelésre az egyik legismertebb példa a UNIX rendszer, amely támogatja a software cache használatát, és ezért egy un.

shutdown rendszerhívást mindig végre kell hajtani a kikapcsolás előtt azért, hogy a cache tartalmakat a lemezterületre vissza tudjuk írni. 9.5 A meghajtók részfeladatai Annak ellenére, hogy a meghajtók a legkülönbözőek lehetnek, mégis van néhány olyan részfeladat, amelyet mindegyiknek meg kell oldania. Ebben a fejezetben ezeket a feladatokat tekintjük át abban a logikai sorrendben, ahogy a meghajtók aktivizálásakor végrehajtónak. A részletes ismertetés előtt meg kell jegyezni, hogy a meghajtók aktuvizálása többnyire rendszer hívásokkal történik. Az, hogy hogyan történik egy rendszerhívás, az nagymértékben függ egyrészt az OR-től, másrészt a rendszer architekturájától. 9.51 Előkészület az I/O műveletre Ha egy rendszerhívással egy meghajtót akarunk aktivizálni, akkor ez az első művelet, amelyet végre kell hajtanunk. Az előkészület lényegében két alapvető részből áll: 1. Fel kell sorolni azokat a paramétereket,

amelyekkel a meghajtót műkötetni akarjuk Ezek egy része az OR-hez kapcsolódik (pld. a végrehajtandó művelet típusa, a pufferterületek címei, az adatterület mérete stb.), más részük pedig készülék specifikus. 2. Időszakos puffereket kell allokálni, formattálni kell bizonyos adatokat és információkat kell elhelyezni az I/O control blokkban azért, hogy a megszakításkezelő és az OR ezeket el tudja érni. Miután ezeket az előkészületeket megtettük, ellenőrizni kell a készülék státuszát. Ha a készülék valamilyen oknál fogva nincs készenléti állapotban, akkor a meghajtó 99 valamilyen speciális tevékenységet hajt végre. Ez erősen függ az OR-től: bizonyos esetekben a meghívó eljárást is megszakíthatjuk, míg máskor mindössze egy hibakódot állítunk be, amelyet aztán a hívó programmal dolgoztatunk fel. 9.52 Az I/O művelet megindítása Az I/O művelet megindításának egyik módja az, hogy engedélyezzük a megszakítást

az adott készülék számára. Ebben az esetben minden további műveletet a megszakítás kezelő végez el. Az ilyen típusú kezelés elsősorban a karakter típusú készülékekre jellemző. Más esetekben a rendszer speciális start I/O paranccsal rendelkezik. (SIO) Ilyenkor az I/O parancs paraméterekkel rendelkezik, amelyek pontosan specifikálják azt, hogy a SIO parancsot hogyan kell végrehajtani. ( Egy lemez egységgel kapcsolatos start I/O utasítás például a következő paraméterekből állhat: műveleti kód, memória átviteli cím, mozgatni kívánt byte-k száma, track címe, szektor címe.) 9.53 Megszakítás szolgáltatások Amikor a vezérlést a megszakításkezelő átveszi, akkor az ellenőrzéshez szükséges információkat az I/O control blokkból nyerheti ki. Fontos, hogy a megszakításkezelőnek az összes regisztert és hardware státuszt jelző értéket meg kell őriznie mielőtt a megszakított programtól elvenné a vezérlést. 9.54 Hiba

érzékelés és elhárítás A megszakításkezelő szolgáltatásai közűl a legbonyolultabb feladat a hibák érzékelése. A különböző típusú készülékeknél a legkülönbözőbb hibák fordulhatnak elő. A következő táblázat néhány jellemző hibát mutat be: Lemezegység: Szalagegység: Nyomtató: Érvénytelen track vagy szektor. Hibás írássűrűség. Törölt szektor. Szalag vége (EOT). Olvasási hiba. Kifogyott a papír. Nincs nyomtató szalag. A nyomtató off-line-ban van. A hibák érzékelése mellett azok elhárítása is nagyon változatos lehet. A legegyszerűbb esetekben elegendő visszajelezni (pl. Kifogyott a papír), míg más hibáknál mint például egy mágneslemezes olvasásnál a hiba teljes felgöngyölítése már sokkal bonyolultabb algoritmust kíván. Ennek az a következménye, hogy egyszerűbb OR-k esetében nem kezelünk le minden hibát az OR-n belül. Ilyenkor az egyik legfontosabb dolog az, hogy a hibák fellépésekor 100

megőrizzük az adatok integritását, és jelezve a hiba fellépését, programokban gondoskodjunk a továbbhaladásról. a felhasználói 9.55 I/O művelet lezárása Ha az I/O műveletet befejeztük, akkor a vezérlés visszaadása előtt néhány ”tisztogatási” feladatot kell elvégeznünk. Ezek közül megemlítjük a hibakód beállítást, a készülék foglaltságát jelző állapotkód visszaállítását és bizonyos megszakítás tíltások feloldását is. Ha a feladatok között szerepel a maximáis áteresztés is, akkor megvizsgáhatjuk a sorbanálló igényeket ahhoz, hogy kikeressük a megfelelő szabad készüléket a továbbhaladáshoz. 9.56 I/O művelet megszakítása Nem nehéz magunk elé képzelni egy olyan esetet, amikor arra kényszerülünk, hogy valamiyen okból megszakítsunk egy éppen folyó I/O műveletet (pl. begyűrődött a papír a nyomtatónál vagy rossz maégneslemezre ketdtünk írni). Ilyenkor a készülék típusától függően másként

járunk el. Karakter átvitel esetén a megoldás egyszerű: a megszakítás során úgy kell tennünk, mintha a kérdéses műveletet szabályosan befejeztük volna, és visszatérünk a hivó folyamathoz. Mágneses adathordozók esetében a megoldás az, hogy amennyiben lehetséges visszaállítjuk a művelet megkezdése előtti állapotot. Ha ez nem lehetséges, akkor azt jeleznünk kell a felhasználóval vagy az OR-rel. A környezet visszaállításáról itt is gondoskodnunk kell 9.6 I/O ütemezés Abban az esetben, amikor egyfelhasználós rendszerünk van, az I/O készülékek ütemezése nagyon egyszerű: fel kell függeszteni azt a folyamatot, amely igényli az I/O műveletet, és végre kell hajtani a kívánt adatátvitelt. Többfelhasználós rendszereknél a helyzet bonyolultabb: az I/O igények tömegesen jelentkezhetnek, és előfordulhat, hogy a kért készülék nem áll rendelkezésünkre vagy az ellenőrző egység van elfoglalva másik folyamat igényének

feldolgozásával. Ilyenkor az igényeket egy I/O sorba (queue) állítjuk. Egy I/O sor kiszolgálásához a legkülönbözőbb funkciók tartozhatnak, de az biztos, hogy három alapvető lehetőséget mindig ki kell elégíteni: • tudnunk kell új elemet csatolni a sorhoz, • ezeket ki kell tudni törölni és • fel kell készülni arra, hogy egy I/O művelet befejezése után meg tudjuk találni a sorban a következő elemet a végrehajtáshoz. Strukturálisan két különböző típusú I/O sort különböztetünk meg: 101 • Az egyszerű I/O sor alkalmazása esetén minden ilyen készülékre vonatkozó igényt egyetlen láncba tárolunk, és az elemekhez tartozó kontroll blokkok tartalmazzák a készülékek típusait. Egy ilyen sorban való keresés sok igény esetén bonyolult és hosszadalmas lehet. • A többszörös I/O sor azt jelenti, hogy minden készülék számára külön láncot képezünk a jelentkező igényekből, ami kényelmesebb használatot

biztosít, de nem igazán helytakarékos megoldás. Miután a jelentkező igényeket sorba állítottuk, a következő kérdés az, hogy hogyan válasszuk ki a sorból a következő végrehajtandó I/O műveletet a felszabadult készüléken. A készülék ütemezésre is különböző technikák terjedtek el: • A legelterjedtebb technika a már többszöt említett FIFO eljárás. Érdekes az, hogy annak ellenére, hogy számos egyéb optimalizálási stratégia létezik, kimutatták, hogy sokszor nem lehetséges számottevő javulást elérni bonyolultabb eljárásokkal sem. • Real-time rendszerekben gyakran alkalmazzák a prioritásokon alapuló stratégiát. Ilyenkor a fő hangsúly azon van, hogy hogyan lehetséges jó prioritási startégiát választani. (Erről a korábbiakban már beszéltünk) A legrövidebb keresési idő alapján működő eljárást a mágneslemezek esetében használjuk. Itt ugyanis arról van szó, hogy a várakozó igények nagy száma mellett

rendkívül fontos az is, hogy gyorsan szolgáljuk ki az igényeket. Ez pedig a mágneslemezeknél erősen függ az író-olvasó fej helyzetétől. Mivel ez az eljárás mindig azokat az igényeket szolgálja ki, amelyekhez tartozó adatok közel esnek az olvasó fej aktuális helyzetéhez, ezért nagyon nehéz az ”esélyegyenlőséget” biztosítani. (Szélsőséges esetben előfordulhat az ütemezési eljárásoknál már említett ”éhenhalás” is.) Ezért nem ritka, hogy valamilyen kompromisszumos megoldást keresnek Egy ilyen lehetőség az, hogy a fejmozgást csak egy irányban engedik meg, és először kielégítenek minden olyan igényt, amely ebbe a mozgási irányba esik, majd megfordítják az irányt, és így dolgozzák fel a további igényeket. 102 10. Memória szervezés A memória kezelés szükségessége már a számítógépek fejlődésének kezdeti időszakában is élesen vetődött fel: a memóriák ára rendkívül magas, a sebesség viszonylag

alacsony volt és a memória elemek csak korlátozott mennyiségben voltak felhasználhatók. Újabb lökést a fejlődésnek a többfelhasználós rendszerek megjelenése adott: a drága erőforrást meg kellet osztani a konkurens folyamatok között. Ezért számítógépes rendszerek memória típusú erőforrásainak a kezelésére az OR-en belül külön modult fejlesztettek ki: ez a memória szervező részrendszer. Amikor memória kezelésről beszélünk, akkor a legtöbbször a számítógépek központi memóriájának szervezéséről, kezeléséről beszélünk. (Ha ettől eltérünk a vizsgálat során, akkor azt külön fogjuk jelezni.) A memória kezelés problémája alapvetően három részprobléma kezelését rejti magában: • Memória allokációt kell végrehajtanunk minden olyan esetben, amikor egy folyamatot végre aktivizálni akarunk. A hatékony memória allokáció azt jelenti, hogy • az igényelt memóriát a lehető leggyorsabban bocsájtjuk a folyamat

rendelkezésére, • csak akkor allokálunk memóriát, ha az szükséges, • felszabadítjuk a lekötött memóriát, ha a hozzá tartozó folyamat befejeződött. • Az allokált területhez való programillesztést áthelyezésnek nevezzük. Ennek során előfordulhat, hogy mind a gépi kódú utasítások mind az adatok címein módosításokat kell végrehajtani. • A memória védelem a többfelhasználós rendszerek egyik alapproblémája: egy felhasználói program csak azt a területet érheti el, amelyet a rendszer a számára allokált. Mivel az OR és a különböző alkalmazói programok rendkívül intenzíven használják a memóriát, ezért a hatékonyság növelésének érdekében - a software eszközök mellett - egyre inkább kihasználják a hardware adta lehetőségeket is. Napjainkban a legelterjedtebb technikák a lapozás, a szegmentálás és a virtuális memória használata. (Ezeket a technikákat a következő fejezetben tárgyaljuk részletesebben.)

Ebben a fejezetben azokat az eljárásokat mutatjuk be, amelyek a speciális hardware segítséget kevésbé veszik igénybe. Annak ellenére, hogy ezeknek a 103 rendszereknek a széleskörű felhasználása az elmúlt évtizedekben virágzott, ezeket a kisebb OR-k ma is kiterjedten alkalmazzák. 10.1 Memória allokáció Memória alloká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. Az összefüggőség azt jelenti, hogy a címzésnek folytonosnak kell lenni a logíkai címzési területen vagy a virtuális címzési területen.(Ez utóbbi azokat a címeket jelenti, amelyeket a programozó ”lát”) A korai stratégiák egyáltalán nem tartalmaztak allokációt. Egy ilyen rendszerben egy program futott a rendszerben úgy, hogy a fizikailag rendelkezésre álló memóriát a futás ideje alatt teljes egészében felhasználhatta. (Esetenként az is előfordult, hogy az OR egyetlen része sem

tartózkodott a memóriában.) Egy ilyen rendszer előnye és hátránya ugyanott gyökerezett: nem használt OR-t, ezért nagyon könnyű volt implementálni, de ez egyben azt is jelentette, hogy nem használhatott OR szolgáltatásokat. Ezt az un ”csupasz gép” technikát ma már csak olyan esetekben használják, amikor nincs szükség közvetlen OR támogatásra (pl. real-time rendszereknél). 10.11 Allokáció egy felhasználós rendszereknél Az OR-k legegyszerűbb típusa az, amikor egy felhasználói program fut egy adott időpillanatban a rendszerben. Ilyenkor a memória allokálása egyszerű: a program a teljes memóriát használlhatja, kivéve persze azt a részt, amelyben az OR rezidens része foglal helyet. Mint azt a korábbiakban már tárgyaltuk, az OR által lefoglalt terület akár a memória ”alsó” akár a ”felső” részén is lehet. Bizonyos OR-k esetén a vegyes helyfoglalás is előfordulhat. A VAX RT-11 esetén az OR ellenőrzésre szolgáló

részei az alacsony címzési területen helyezkednek el, míg maga az OR a magas cím területeket foglalja le. Hasonló helyfoglalási stratégiája van az MS-DOS rendszernek is. 10.12 Allokáció többfelhasználós rendszereknél Mivel a többfelhasználós rendszereknél a memóriát több folyamat között kell megosztani, ezért egy ilyen rendszer esetén szemben az előző pontban leírtakkal egy folyamat számára csak a memória egy része allokálható. Attól függően, hogy a futás közben foglalhat-e le újabb területeket egy feldolgozás alatt álló folyamat, két különböző stratégiát különböztetünk meg: A. Statik us allokáció esetén a folyamathoz akkor rendeljük hozzá a felhasználható memória területet, amikor a hozzá tartozó programot betöltjük és elindítjuk. Más szavakkal ez azt jelenti, hogy a program mindaddig nem tölthető be, amíg az általa igényelt terület a rendelkezésére nem áll. Az egyszer allokált terület mindaddig a

104 folyamat rendelkezésére áll, ameddig az be nem fejeződik. Az ilyen eljárás egyszerűen kezelhető, de könnyen belátható, hogy nem gazdaságos. A fizikai memória felosztásának két ismert módja van: A.1 Statikus m emória definició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. Ez egyben azt is jelenti, hogy a folyamatok betöltésekor a rendelkezésre álló blokkok száma soha sem változik. A statikus memória területeket szokás partícióknak nevezni A partícióknak nem kell mindig azonos méretűeknek lenni, sőt az a célszerű, ha ezeket különbözőekre definiáljuk. A korai rendszereknél úgy írták a programokat, hogy csak egy megadott partícióban futhattak, de az áthelyezhetőség bevezetésével ez a megkötés megszünt. Ha a memória kezelés során fix partíciókat definiálunk, akkor ez nagymértékben megkönnyíti az OR feladatát: mindössze annyit kell

megjegyezni, hogy egy partíció éppen foglalt vagy sem. A szabad partíciót aztán felhasználhatjuk, ha megfelelő program található a sorbanállók között. A módszer hátránya ezzel szemben az, hogy nagyobb méretű blokkba is betölthetünk kisebb programokat, és így a ki nem használt terület elveszhet. Ez ellen úgy védekezhetünk, hogy az input sorban levő programokhoz úgy választunk ütemezési stratégiát, hogy a rendelkezésre álló blokkot a lehető legjobban kitöltsük. A.2 Dinamikus m emória definició esetén az OR a blokkok számát és a méretét akkor határozza meg, amikor egy igényt ki akar elégíteni. Ilyenkor az allokálhatóságot a memória aktuális állapota dönti el. Az OR betöltése után a megmaradt terület mindig szabadon felhasználható. A dinamikus memória területeket régióknak fogjuk nevezni. A régiók definiálása egyfajta átmenetet képez a statikus és a dinamikus módszerek között: bár az egész rendszer

szempontjából az allokáció dinamikus, az egyes folyamatokhoz szempontjából a rendelkezésre álló terület statikus. A következő példa jól szemlélteti a régiók időbeli kiosztását, és egyben rámutat a módszer hátrányára is: mivel az allokáláshoz összefüggő területre van szükség, a szétdaraboltság miatt a hatékonyság lecsökkenhet. Tételezzük fel, hogy a rendszerben 4 program várakozik allokálásra. Legyenek ezek P1, P2, P3 és P4. Legyenek az igényelt memória területek rendre 120 K, 60 K, 120 k és 120 K. A különböző időpontokban történő allokálások után a memória kiosztásokat az a - e ábrákon láthatjuk. • • • • az a. ábra azt az időpillanatot mutatja, amikor a 360 K terület felhasználható a b. ábra a P1 Job allokálása utáni memória kiosztást jelzi a c. ábra a P2 Job allokálása utáni memóriakép a d. ábra a P3 Job allokálása után készült 105 • az e. ábrában - feltételezve, hogy a P2 Job

befejeződött, és így az általa lefoglalt terület felszabadult - a P4 Job mégsem volt allokálható, mert a futáshoz szükséges memória nem állt rendelkezésre összefüggően. Ez az un szétdaraboltság (fragmentation) probléma, amely a dinamikus allokáció esetén megszüntethető. a. b. OR Szabad 360 K c. OR 1. Régió 120 K JOB P1 d. OR 1. Régió 120 K JOB P1 2. Régió 60 K JOB P2 e. OR 1. Régió 120 K JOB P1 2. Régió 60 K JOB P2 3. Régió 120 K JOB P3 OR 1. Régió 120 K JOB P1 Szabad 60 K 3. Régió 120 K JOB P3 Szabad 60 K 10.1 Ábra Régió allokálás dinamikus memóriakiosztás esetén B. Dinam ikus allok áció esetén a memória felhasználás sokkal hatékonyabb Az ilyen közelítés során lehetőség van arra, hogy további területeket igényeljünk a futás közben, ha arra szükség van. Egy ilyen szerkezetben elvárható, hogy mindazokat a memória területeket, amelyekre már többé nincs szükségünk, a lehető leghamarabb

felszabadítsuk. Az OR általában az allocate és a free rendszerhívások segítségével végzi el ezeket a műveleteket. Az allocate utasítás meghívására akkor kerül sor, amikor igény jelentkezik meghatározott memória allokálására. Az esetek többségében az igény olyan, hogy a címzési terület nem meghatározott., de összefüggőnek kell lennie Az OR-nek az a feladata, hogy behatároljon egy megfelelő memória területet, és azt a megfelelő folyamat számára elérhetővé tegye. Ha nincs ilyen terület, akkor a folyamatnak várakoznia kell mindaddig, amíg a kérése nem teljesíthető. A free műveletet használjuk fel a azoknak a blokkoknak a felszabadítására, amelyekre a folyamatoknak nincs többé szüksége. Az algoritmusok legnagyobb része olyan, hogy az allokált blokkok egységesen szabadulnak fel. (A befejezett folyamatokhoz tartozó blokkok mindig felszabadulnak) A felszabadítás első pillanatra algoritmikusan egyszerűnek látszik: töröljük

a blokkot az allokálatak listájából és fűzzük hozzáa szabad blokkok listájához. Ez utóbbi lépésnek azonban vagy egy lényeges momentuma: a hozzáfűzést úgy kell végrehajtani, hogy a szomszédos 106 blokkokat ismerjük fel, fűzzük össze ezeket egy közös, nagyobb blokkba. A szomszédság felismerése akkor lesz egyszerűbb, ha a listát a memória címek növekvő sorrendjében láncoljuk. (A szomszédos blokkok összefűzése ezek után már standard programozási feladat.) 10.13 Adatstrukturák dinamikus allokációhoz A dinamikus allokáció egyik sarkalatos kérdése, hogy miként tudjuk nyilvántartani a memória pontos foglaltsági állapotát. (Ez szükséges ugyanis ahhoz, hogy az OR kellő információval rendelkezzen az allokáláshoz.) A következőkben két módszert fogunk bemutatni a nyilvántartásra: A bit térkép (bit map) akkor használható, ha a memória egyenlő méretű blokkokra van osztva. Minden blokkhoz egy bitet rendelünk, amelynek

értéke azt mutatja, hogy a blokk szabad (0) vagy allokált (1) állapotban van. A következő ábra egy memória állapotot, és a hozzá tartozó bit térképet mutatja: 1. Folyamat 11100110 0 0 0 . Bit térkép PCB1 Szabad Szabad 2. Folyamat PCB2 Szabad Szabad Szabad Szabad 10.2 Ábra Memória nyílvántartás bit térkép használatával Az ábra jobb oldalán feltüntettünk két PCB-t is. Ezekre azért van szükség, mert a bit térkép nem azonosítja azt, hogy a szóbanforgó blokkot mely folyamathoz rendeltük hozzá. Az összefüggően allokált blokkok kezdőcímét és a méretét a folyamathoz tartozó PCB-ben tároljuk, így amikor a folyamat végetér, akkor a bit térképben a megfelelő értékeket visszaállíthatjuk nullára. Memória Ellenőrző Blokkot (Memory Control Block = MCB) akkor használunk, ha az egyes blokkok hossza nem rögzített vagy ha össze akarunk fogni többet a nyílvántartásban. Egy blokk vagy szabad vagy foglalt állapotot jelöl A

blokk fej tartalmazza mindig a típust, a hosszat és egy pointert a következő azonos típusú blokkra. (Előfordulhat, hogy a jobb elérhetőség kedvéért kétirányú láncolást 107 alkalmaznak.) A szabad területeket reprezentáló blokkokat FMCB-vel (Free Memory Control Block) míg a foglaltakat AMCB-vel (Allocated Memory Control Block) fogjuk jelölni. 10.14 Allokációs stratégiák dinamikus allokáláshoz Ha a memória kezelési stratégiánk olyan, hogy változó hosszúságú blokkokat dinamikusan allokál, akkor mindig szükségünk van arra, hogy valamilyen hatékony stratégiát használjunk a soron következő program kiválasztása során. A következőkben néhány elterjedt algoritmust mutatunk be. 1. Első Illesztés (First Fit) A módszer az első FMCB-től indulva megvizsgál minden szabad blokkot, és az első olyan blokkot választja ki, amely megfelel az igényelt méretnek. Ilyenkor a kiválasztott FMCB két részre oszlik: a remény szerint nagyobbik

részben elhelyezzük a programot, és a kisebbik rész ismét FMCB lesz. (Abban az esetben, ha a maradék blokk mérete túl kicsi lenne, sokszor nem választjuk két részre az aktuális blokkot, hanem a blokk felszabadításáig ”magunkkal visszük” a fölösleges részt is, és a folyamat befejezésekor együtt szabadítjuk fel az egész allokált blokkot.) Az algoritmus gyors, könnyen implementálható. Hátránya az, hogy egy idő után összegyülhetnek a kicsi ”maradvány” blokkok, amikkel már nem tudunk mit kezdeni. Ilyenkor a Knuth-tól származó ötlet alapján célszerű ezeket a blokkokat a lista elején öszegyűjteni. 2. Következő Illesztés (Next Fit) Ez az algoritmus az FF algoritmus egyszerűsített változatának tekinthető azzal az eltéréssel, hogy új keresést mindig ott kezdünk az FMCB blokkok között, ahol az előzőt abbahagytuk. (Ezt úgy oldhatjuk meg, hogy egy pointerben megőrizzük az előző menetben vizsgált utolsó FMCB címét.) A

listát körkörös listaként kezeljük, tehát az utolsó elem vizsgálata után visszatérünk az első elem vizsgálatához. Az elemzések azt mutatják, hogy az NF algoritmust egy kissé rosszabbul viselkedik, mint az FF. 3. Legjobb Illesztés (Best Fit) Az előbbiekben tárgyalt két algoritmus hibája, hogy csak az illeszkedés tényét vizsgálja, nem veszi figyelembe a blokk tényleges méretét. A most tárgyalandó algoritmus bejárja az összes blokkot, megjegyzi azt, amelyhez a legjobban illeszkedik az igény (azaz amelyik allokálása esetén a legkevesebb felhasználatlan terület marad), és azt választja ki. Az algoritmus hibája az, hogy a keletkező - egészen apró blokkok - az idők folyamán ugyanúgy összegyűlnek, mint az FF esetén, és ezek még kevésbé lesznek használhatók. 4. Legrosszabb Illesztés (Worst Fit) Ez az eljárás a megfordítja a BF algoritmus gondolatmenetét: abból indul ki, hogy ha nagyobb szabad hely marad ki az allokáció után,

akkor nagyobb esély van arra, hogy azt a későbbiekben fel tudjuk használni. Ezért a teljes állomány végigolvasása után ahhoz a blokkhoz allokálja az igényt, amelyet a fentiek alapján választ ki. 108 Az algoritmusok bemutatása során láttuk, hogy minden algoritmusnak vannak előnyei és hátrányai. Ezért felmerül a kérdés: mikor, melyik algoritmust válasszuk ki? Azt gyorsan leszögezhetjük, hogy nincs olyan on-line stratégia, amely mindig jól fog működni. Az elemzések azt mutatják, hogy az FF és a BF algoritmusok viselkednek általában a legelőnyösebben. Mivel az FF implementálása látszik a legegyszerűbbnek, ezért ezt az algoritmust választják a leggyakrabban. 10.15 Átrendezés, tömörítés Láthattuk, hogy a fenti 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 ilyen fajta tömörítésre. Ez legegyszerűbben azoknál a rendszereknél, amelyek áthelyezési regiszterrel (lásd később) rendelkeznek. Ha tömörítést alkalmazunk, akkor azt periódikusan kell végrehajtani, és a tömörítés alatt minden olyan folyamatot fel kell függeszteni, amely függ a folyamatokhoz tartozó programok relatív helyzetétől. (Így például nem végezhetünk I/O műveleteket, mert az hatással lehet a programokhoz tartozó adatok értékére.) 10.2 Áthelyezési módszerek A többfelhasználós rendszerek általában megengedik azt, 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. Mivel a programokban mind az utasításokban mind pedig az adatok címeiben hívatkozunk azok helyére, ezért 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 (relocation) 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ésről akkor beszélünk, ha az a betöltéssel egyidőben vagy az előtt történik. • Dinamikus áthelyezés a program futása közben is végrehajtható. A következőkben azokat a módszereket mutatjuk be, amelyekkel az áthelyezés végrehajtható. 10.21 Áthelyezés software úton 109 A programok akkor helyezhetők át software úton, ha meghatározható, hogy melyik 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öny vtárban adjuk meg Ez fogja azonosítani a módosítandó címeket és a módosítás irányát is. Ezután egy speciális betőltő

program (relocating loader) a kívánt címre tölti a programot az áthelyezési könyvtár segítségével. Az áthelyezési eljárás követhető a 103 ábrán egy olyan esetben, amikor az object kód kezdő címe 0, és a betöltés a 3000-es címre történik. Mint az jól látható, a software útján történő áthelyezés rendkívül időigényes, és részletes kisegítő információt igényel. Mivel ez az információ nem kerül be a memóriába az áthelyezés után, ezért az egyszer áthelyezett program többé nem mozdítható ugyanazon futás során. Így ez a stratégia statikus áthelyezést eredeményez Áthelyezhető Objekt Kód: 1100: LOAD 1102: ADDI 1104: JMP Áthelyezési könyvtár: 1101 1105 4406 25 4150 3000: 4100: 4102: 4104: + + LOAD 7406 ADDI 25 JMP 7150 10.3 Ábra Program áthelyezés Ahhoz, hogy dinamikus áthelyezést hajtsunk végre, szükségünk van olyan hardware segítségre is, amelyet a következőkben írunk le. 10.22 Áthelyezés

bázis címekkel A hardware támogatás egyik módja az IBM/360-as sorozatnál bevezetett módszer, amely bázis címeket használ. A technika alapja az, hogy a betöltött program kezdőcímét elhelyezi egy bázis regiszterben , amely vonatkoztatási alapként szolgál majd. Ezután a program minden olyan utasításában, amely a bázis címet kívánja felhasználni, a végrehajtás előtt 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. (Érdemes megjegyezni, hogy az IBM/360 legnagyobb elérhető címe 4K volt, ezért a memória minden 4K nagyságú blokkja külön bázis regiszterel rendelkezett, ami némileg csökkentette a módszer hatékonyságát.) A módszer lehetővé teszi a dinamikus áthelyezést is, hiszen ehhez eelegendő áthelyezni a programot, és átírni a bázis regiszter tartalmát. 110 10.23 Áthelyezés relatív címzéssel A bázis címek alkalmazásának egy másik módja a PDP-11

számítógépnél bevezetett relatív cím zési technika. E módszerben az utasítás számlálót (PC = Program Counter) használjuk fel bázis regiszterként. (Mivel az utasítás számláló tartalma állandóan változik, ezért szokás a módszert ”lebegő bázis regiszteres” technikának is nevezni.) A tényleges címeket most úgy számítjuk ki, hogy az utasítás számláló tartalmát adjuk hozzá a végrehajtandó utasítás megfelelő címrészéhez. Ennek az eljárásnak az alkalmazása lehetővé teszi az un. helyfüggetlen kód ok kialakítását a fordítás során, amely kényelmesen biztosítja a dinamikus áthelyezést a memória kezelés során. 10.24 Áthelyezési regiszterek alkalmazása A bázis regiszter 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ési technikával szemben itt az áthelyezési

regiszter tartalma mindaddig állandó marad, amíg a programot ismét át nem helyeztük. Így a regiszter alkalmazása nagymértékben 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 egy időben a áthelyezési regiszter tartalmába a program új kezdő címét töltjük. 10.3 Egyéb technikák Mindezideig a memória kezelésnek csak azt a problémáját vizsgáltuk, amikor a konfliktusok abból keletkeznek, ha több programot akarunk a főtárban elhelyezni, és azok számára nincs elegendő hely. Ebben az alfejezetben két olyan technikát mutatunk be, amely egy felhasználós környezetben is előfordulhatnak. 10.31 Overlay struktura A korai egy felhasználós rendszerek központi memóriája viszonylag kicsi volt. Egy nagyobb program futtatása egy ilyen rendszerben csak úgy volt lehetságes, ha a programot megkíséreltük kisebb egységekre bontani. Ezeket az

egységeket nevezzük overlay-eknek. Az overlay technika alapgondolata a következő: ahogy beszélhetünk programok közötti interfernciáról, úgy létezik a programrészek közötti kapcsolat is. Egy programrésznek nem okvetlenül van szüksége arra, hogy a program teljes egészében a memóriában legyen akkor, amikor a programrészt végrehajtjuk. Daraboljuk tehát 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. Ezt 111 nevezzük overlay szegmensnek. Ha a memória elég nagy, akkor a program maradék részeit mindig a főtárban tartjuk. A megfelelő overlay struktura kiválasztása nem mindeg egyszerű, ezért a bonyolultabb programoknál komoly software támogatást igényel. Ezt az esetek legtöbbjében a fordítás során a compiler és a szerkesztő szolgáltatja. Ha egyszer megtaláltunk egy megfelelő strukturát, akkor a program futása során

gondoskodni kell arról, hogy a megfelelő programrész a megfelelő időben az overlay szegmensben tartózkodjon. Ezt a feladatot látja el az overlay supervisor program, amely rezidensként tartózkodik a főtárban. Annak ellenére, hogy ez a technika még napjainkban is megtalálható a különböző OR-k esetében, azonban már korántsem olyan népszerűek. Ennek elsősorban az az oka, hogy a memóriák ára drasztikusan csökkent. 10.4 Memória védelem Az allokációnak a legtöbb esetben csak akkor van értelme, ha összekapcsolódik valamilyen védelemmel. Védelemnek létezni kell, hogy a programok ne érjék el azokat a területeket, amelyeket az allokáció során nem kaptak meg. Néhány egy felhasználós OR nem tartalmaz semmilyen hardware biztosítékot a nem allokált területek elérésének a védelmére. A baj azonban nem olyan nagy: ha az OR rezidens része valamilyen módon megsérül, akkor ez mivel egyetlen program tartózkodik a memóriában csak egyetlen

programra lesz kihatással. Érdemes megjegyezni, hogy az MS-DOS korai változatai egyáltalán nem rendelkeztek memória védelemmel. 10.41 Egyfelhasználós rendszerek Az egy felhasználós rendszerek esetében mégis van egy program, amely kitüntetett szerepet játszik: ez az OR (vagy annak a memóriában lévő része). Mivel az OR az esetek többségében a memória jól meghatározott részében foglal helyet (vagy a legalacsonyabb címeken vagy a legmagasabbakon), ezért a védelme könnyebben oldható meg: egy un. határcím megadásával kijelölhetjük azt a legalacsonyabb (legmagasabb) memória címet, amelyet egy program elérhet. Ennek a címnek a korrekt meghatározása nem könnyű: (az egyszerűség kedvéért tegyük fel, hogy az OR a memória felső felében helyezkedik el) ha túl nagynak választjuk a határcímet, akkor kevés hely marad az OR számára. Ha túl kicsire választjuk, akkor fennáll annak veszélye, hogy kihasználatlan memóriánk marad az

applikáció betöltése után. Ezen segíthet, ha a határcím helyett határ regisztert alkalmazunk, ezzel elérve azt, hogy - a határ regiszter tartalmának változtatásával - dinamikusan kezeljük a határvonalat a felhasználói program és az OR között. 10.42 Többfelhasználós rendszerek 112 Az egyfelhasználós rendszereknél alkalmazott utóbbi módszer jó irányt mutat ahhoz, hogy minden régió számára alkalmazzunk külön határ regisztert vagy alsó- és felső-regiszterpárt, amelyek egyértelműen kijelölik a regió aktuális határait. Egy másik lehetőség az, ha a regiszterpárban bázis é rtéket és blokkszélességet adunk meg. A fenti példában a bázisregiszter értéke megegyezik az alsó korlát értékével és blokkszélesség 1120, amelyet a felső korlát helyén tárolunk. Felső korlát Alsó korlát 4736 3644 Szabad 4. Folyamat 3. Folyamat 2. Folyamat 1. Folyamat OS 4736 Regiszterpár 3644 Illegális terület Legális terület

Illegális terület 10.4 ábra Regiszterpár alkalmazása memória védelemre 113 11. Virtuális memória kezelés Az előző fejezetben a memória kezelés legfontosabb problémáit tekintettük át. A vizsgálat során kiderült, hogy a problémák egy része csak akkor oldható meg, ha a megoldást valamilyen hardware technika támogatja. Ebben a fejezetben ismét egy ilyen hardware technikát vizsgálunk meg. A megoldandó probléma a következő: A gépi kódra történő fordítás során a 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 pl a CPU címregisztere 1 byte hosszú, akkor az elérhető legmagasabb cím 255 ). Ha egy adott konfigurációnál fizikailag elég sok memória áll rendelkezésünkre a főtárban, akkor nincs szükség a programok darabolására. A futtatás során mindössze az áthelyezést kell megoldanunk, ha a rendszer több

felhasználós. Ilyenkor az OR gondoskodik arról, hogy a rendelkezésre álló fizikai memóriát a legjobban ki tudjuk használni. Ha azonban 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 (ti az, amelyikre éppen valamelyik címmel hivatkozunk), a többi rész pedig valamilyen háttértárolón helyezkedik el. Az OR feladata az, hogy megoldja a programrészek cseréjét a kellő időpillanatban. A programrészek cseréjének automatikussá tételével a virtuális memóriakezelés elve azt az illúziót nyújtja a felhasználónak, mintha a hardware által címezhető terület mindig a

rendelkezésére állna fizikailag is. A megoldás az, hogy a programokban specifikált virtuális címeket 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 programozás vagy a fordítás során úgy választhatjuk meg, ahogy az a fordítónak kényelmes, míg a fizikai címek mindig az OR-hez illeszkednek. Fontos, hogy az áthelyezés automatikusan történik, nincs szükség arra, hogy a program gépi kódú parancsokat tartalmazzon a végrehajtáshoz. A módszer nagy előnye az, hogy a virtuális és fizikai címek egymástól függetlenek, ezáltal az áthelyezés egyszerűbbé válik: akárhogyan is változnak meg a fizikai címezhetőség határai, a virtuális címek nem változnak, tehát az OR oldaláról jól követhetők maradnak. Ebből fakad a módszer másik előnye: a memória védelem könnyebben megszervezhető, az illegális hivatkozások egyszerűbben érzékelhetők

és kiküszöbölhetők. Mivel a technikát támogató hardware évtizedekig nagyon drága volt, ezért csak a nagyobb rendszereknél volt használható. Az utóbbi években azonban elsősorban a 114 hardware árának rohamos csökkenése miatt egyre kiterjedtebben alkalmazzák kisebb gépeken is. A virtuális memória kezelését két lépésben fogjuk bemutatni. Először megvizsgáljuk, hogy milyen eljárások léteznek arra, hogy a memória egy részét áthelyezzük egy másik területre, majd ezután térünk rá arra, hogy miként lehet kezelni azt az esetet, amikor a mozgatni kívánt memóriaterület részben vagy egészében nem található a főtárban. 11.1 Memória áthelyezési technikák Annak ellenére, hogy az áthelyezési technikák tényleges megvalósítása erőteljesen függ a rendelkezésre álló hardware tulajdoságaitól, mégis fel lehet állítani olyan ”alapmodelleket”, amelyekre a különböző megoldások ráépülnek. Ebben a részben ezeket

a technikákat mutatjuk be. 11.11 Áthelyezési táblázat Ez a model inkább elvi jellegű. Bemutatása azt célozza, hogy világosan megértsük az előzőekben felvázolt technikát. A módszer lényege az, hogy a virtuális címzési terület és a fizikai címzési terület közé egy transzfomációs tábla kerül , amelynek segítségével az aktuális áthelyezéseket megoldjuk. Vezessük be a következő jelöléseket: VKC: FKC: Virtiális kezdőcim. Az a cím, amelyet a fordító ad a program első utasításának. Fizikai kezdőcím. A program aktuális futásakor a betöltési kezdőcím, amelyre a program első utasítása kerül. A VKC-t ill. az FKC-t szokás bázis címenek is nevezni Virtuális Cím + VKC - FKC Virtuális Címzési Terület 115 Méret Fizikai Cím Fizikai Címzési Terület Áthelyezési Táblázat 11.1 Ábra Virtuális memória kezelés áthelyezési táblázattal A fordítás során a virtuális címzési területet a fordító

blokkokra osztja. Ezek 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 a következő: amikor a programban valamilyen virtuális címre hivatkozás történik, akkor a hardware először megkeresi azt a blokk leíró vektort, amely a szóbanforgó virtuális címet tartalmazza. (Ez egyszerű soros kereséssel megoldható: meg kell keresni azt a legnagyobb báziscímet, amely nem nagyobb az aktuális virtuális címnél.) 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. Láthatjuk, hogy a végrehajtás során mennyire fontos a gyorsaság. Ezért az Átviteli Táblát vagy gyors regiszterekben helyezzük el vagy ennek híján a főtárban kap helyet. A fenti erősen elméleti beállítottságú modellhez könnyen illeszthetünk memóriavédelmet is: egészítsük ki a a blokk leíró vektort három bittel. Értelmezzük az egyes biteket úgy, hogy ha a bit értéke 1, akkor • A blokkból megengedjük az olvasást. • A blokkba beleírhatunk. • A blokkban levő utasításokat végrehajthatjuk. Ez a fajta ”megengedési” struktura egy további lehetőséget rejt magában: amennyiben a fizikailag rendelkezésre álló memória egy szelete nem szerepel egyetlen blokk leíró vektorban sem, akkor ez a memóriarész a felhasználók számára nem lesz elérhető, így a memória egyes, jól definiált részei könnyen fenntarthatók az OR számára. A virtuális memóriakezelés fentiekben bemutatott modelljében a virtuális címzési

terület határait a hardware címzési tartománya szabta meg. Tovább finomítható az eljárás abban az esetben, ha figyelembe vesszük azt, hogy a felhasználók által írt programok könnyen felbonthatók logikai egységekre (főprogram, szubrutinok, adatstrukturák stb.), amelyek különálló szegmensekként kezelhetők Az egyes szegmenseken belül a virtuális címterületnek folytonosnak kell lenni, de ezt nem feltételezzük két különálló szegmens esetén. Ezért a szegmensek elvét jól alkalmazhatjuk a virtuális memóriakezelésben: egy szegmens gyakran választható egy virtuális blokknak, amely egészben átvihető a fizikai címzési tartományba. Megjegyezzük, hogy a szegmentálás elve akkor használható különösen jól, ha a hardware és az OR támogatja a változó hosszúságú virtuális blokkok kezelését. (A szegmentálás elvére később visszatérünk.) 116 A következőkben a fenti elvi séma néhány olyan gyakorlati megvalósítását

mutatjuk be, amely különböző hardware plattformokra épült. 11.12 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 bontható. Általában a blokkok számát a rendelkezésre álló speciális regiszterek száma határozza meg. A 112 Ábra a PDP-11-en történő megvalósítást mutatja be Méret FCA 0 --- 0 --- 20 60 12 0 Virtuális címzési terület 120 100 Fizikai címzési terület 80 80 60 60 40 200 40 18 40 20 20 20 20 0 0 Leképezési regiszterek 11.2 Ábra Virtuális memória kezelés leképezési regiszterekkel A virtuális cimzési terület minden blokkjához hozzárendelünk egy speciális regisztert. (A PDP-11 esetében a virtuálisan címezhető 64K byte 8 darab 20Kbyte-os blokkra van osztva, így 8 leképezési regisztert használunk.) Mivel a blokkok báziscímei rögzítettek, ezért könnyű megtalálni a ”virtuális blokkot” és a hozzá tartozó

leképezési regisztert is. Az általános technikához képest a helyzet annyiban egyszerűsödik, hogy a leíró blokkban nem kell tárolni a bázis címet. (Minden más információ szerepel a blokkban.) Az OR ezután a virtuális cím transzformálásához meghatározza a blokkon belüli címet és az eltolási értékeket (ezt szokás offset értéknek is nevezni.) Az átvitel előtt a blokkleíró vektor méret mezőjén egy ellenőrzést hajtunk végre: amennyiben az eltolási érték nagyobb, mint a méret, akkor a transzfomációt nem végezzük el, hanem hibajelzést adunk. Ha megengedési biteket is felhasználunk, akkor az ellenőrzést ezekre is elvégezzük. Ha a fenti összes ellenőrzést elvégeztük, akkor a fizikai blokk kezdőcímét hozzáadjuk az eltolási címhez, és így megkapjuk a tényleges fizikai címet. 117 11.13 Lapra bontás (Paging) A leképezési regiszterek alkalmazása - előnyei mellet - néhány problémát nem kezel megfelelően: A változó

hosszúságú blokkok mozgatása miatt a fizikai memóriában ”maradék” blokkok keletkezhetnek, amelyeket nem lehet felhasználni. A másik kellemetlenség az, hogy 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. Ezért, ha a blokk mérete kicsi, akkor az elvesztett terület nagy lesz. Ezt a problémát csak akkor tudjuk kiküszöbölni, ha kis méretű, fix hosszúságú blokkokat mozgatunk. Azt a technikát, amely ezt megvalósítja lapozásnak nevezzük Ezt a módszert általában összekötik valamilyen más technikával, de a jobb érthetőség kedvéért itt egy kissé ”idealizált”, tiszta lapra bontási eljárást mutatunk be. Virtuális címzési terület 18 19 Fizikai memória 20 15 16 17 12 13 14 9 10 11 6 7 8 3 4 5 0 1 2 13 8 17 9 8 0 5 19 7 6 5 4 3 2 1 0 18 19 20 15 16 17 12 13 14 9 10 11 6 7 8 3

4 5 0 1 2 Lapozási Tábla 11.3Ábra Virtuális memória kezelés lapokra bontással 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 a lapszámmal és a lapon belüli eltolási címmel határozunk meg. A virtuális memória címek leképezése a főtárban tárolt lapozási tábla segítségével történik. Ezt a táblát az OR dinamikusan deklarálja, kezdőcímét és méretét egy kijelölt CPU regiszterben tartja nyílván. A fizikai memória is blokkokra van osztva, és azok mérete megegyezik a lapok méretével. Ezeket a memória blokkokat képlapoknak (lap-frame) fogjuk nevezni 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.Ezen 118 kívül természetesen egyéb informácók (pl. az elérési bitek) is

elhelyezhetők a leíró blokkban, de ezek csak finomítják a technikát. A virtuális címek leképezése a következőképpen zajlik: Egy adott virtuális címet az OR lapszámra és eltolási címre bont. A CPU 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 Miután ezt megtalálja, akkor a képlap azonosító és az eltolási cím segítségével kiszámítja a fizikai címet. Mivel a lapozási táblázat a főtárban helyezkedik el, ezért minden memória művelethez egy további kiolvasási művelet is tartozik: ki kell olvasni a lapleíró vektort. Ez azt jelenti, hogy a műveletei sebesség közel a felére csökkenne. Ennek elkerülésére un. lap-cache technikát alkalmaznak Ennek az a lényege, hogy egy gyors elérésű memóriarészben, a cache memóriában * tároljuk a leíró vektorok egy részét, és először mindig itt keressük a tábla címét. Ha megtaláljuk, akkor a szokásos módon haladunk

tovább. Ha nem, akkor a lapleíró táblában folytatjuk a keresést A megtalált leíró vektort elhelyezzük a cache memóriában abban a reményben, hogy ismét szükségünk lesz rá. (Ha nincs hely a cache memóriában, akkor valamilyen szabály szerint kiválasztunk egy elemet, amelynek a helyére rakjuk az aktuális leíró vektort. A lapok mérete 512 byte és 4K byte között van rögzítve. Jó példa a lapozásra a VAX, amelynél az utasítások címei 32 bit hosszúak, így a virtuális címzési terület 512 Megabyte, amely így 1 millió lapra van felosztva. (Ha leképezési regisztereket akarnánk használni, akkor csak regiszterből lenne 1 millióra szükségünk!) 11.2 Virtuális memó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ér tárolón helyezzük el. Ugyanakkor azt sem nehéz elképzelni, hogy egy nagy méretű program nem fér el a memóriában, és ezért kisebb részekre kell bontani. Az előző szakaszban bemutatott lapozási technika ezeket a problémákat megoldja, ha kiegészítjük egy olyan swap eljárással, amely automatikusan elvégzi a programok cseréjét, gondoskodva a szükséges környezeti változók mentéséről is. Ezt az eljárás Virtuális Memória Ren dszernek nevezzük (VMR). Az első hatékonyan használt VMR-t az ATLASZ OR-nél használták. Az eljárás alapja az volt, hogy egy un egyszintű tárolási technikával a virtuális cimzési területet teljes egészében leképezték a főtárba és egy másodlagos tároló adathordozójára. A VMR-nek ezután csak arról kellett gondoskodnia, hogy a megfelelő programrészeket jól cserélje a két adattároló között. A cache

memória olyan tartalom szerint címezhető kisegítő memóriaterület, amelynek regisztereiben párhuzamosan lehet keresni egy adott taralomra. * 119 A ma használatos technikák alapvetően két részből épülnek fel: az első részben egy memória áthelyezést kisérelnek meg több lépcsőben végrehajtani, majd, ha a megfelelő blokk nem érhető el a memórián belül, akkor a VMR lapot cserél. A következőkben először ezt a két részt tárgyaljuk részletesen, majd külön foglalkozunk a virtuális memória kezelés során felmerülő legfontosabb problémákkal. 11.21 Memória áthelyezés Algoritmikusan a címek áthelyezése ugyanúgy kezdődik, mint a ”tiszta” memória áthelyezésnél. Ha a keresett lap a főtárban van, akkor az algoritmus véget is ér Ellenkező esetben először a virtuális címet felbontjuk lapszámra és eltolási címre, majd a lapleíró vektort keressük meg. Ezt először a a cache memóriában tesszük, majd ezután a

főtárban keresünk. Ezt követően a CPU regiszter segítségével meghatározzuk a keresett virtuális cím helyét a memóriában. (A helyzetet bonyolíthatja az, ha bizonyos lapokat rezidensként kell őrizni a memóriában: ekkor ugyanis ezt külön jelölnünk kell a leíró vektorban, és a cache cseréjénél nem mindig kerülnek ki a cacheből a cserére szánt lapok leíró vektorai.) Ha a lap nincs a főtárban, akkor először meghatározzuk a lap helyét a háttér tárolón, majd megkisé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. Mint az jól látható, az algoritmusnak ez a része igen bonyolult lehet. Ezért ezeket a feladatokat már nem a hardwareből vezéreljük, hanem az esetek legnagyobb részében egy megszakítást hajt végre az OR, és software eszközökkel hajtjuk végre a lapcserét. 11.22 Lapcsere A hiányzó lap esetén fellépő vezérlés átadást lap

hiba megszakításnak nevezzük. Ez a megszakítás némileg eltér az általános megszakításoktól. Itt ugyanis a megszakítás egy művelet közepén lép fel. (Az még tovább bonyolíthatja a végrehajtást, ha a megszakítás során nem egy lapot kell mozgatni, hanem többet.) Ennek az a következménye, hogy a lap hiba megszakítás kezelésekor speciális regisztereket kell használni, és körültekintően kell analizálni az utasításokat nehogy visszafordíthatatlan módosításokat hajtsunk végre a teljes lapcsere végrehajtása előtt. A lap hiba megszakítás egy lehetséges algoritmusát mutatja a 11.3 Ábra Az ábrából látható, hogy az algoritmus bonyolult. Ezért abban az esetben, ha a lap hiba megszakítás túl gyakran következik be, akkor az OR hatékonysága alaposan lecsökkenhet. Ilyenkor az OR az idő legnagyobb részét azzal tölti, hogy a lap hiba megszakításban a lapok cseréjét végzi. A gyakorlati rendszeeket úgy kell tervezni, 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 lap hiba megszakítások előfordulásainak a számát. • Olyan lapkezelési technikát alaklmazunk, amely a lehető leggyorsabban adja vissza a vezérlést a megszakítás hívása után. 120 A következőkben azokat a technikákat mutatjuk be, amelyek a fenti célok elérését segítik elő. 11.23 Virtuális memória kezelés technikái A virtuális memória kezelésére készült algoritmusok gyakorlatilag négy alapprobléma megoldására koncentrálnak: • Mikor kell egy lapot betölteni a főtárba? (Betöltési probléma) • Hova kell a lap képét betölteni? (Elhelyezési probléma) • Melyik lapot kell eltávolítani a főtárból, ha nincs hely a betöltéskor? (Helyettesítési probléma) • A helyettesítéskor eltávolított lap tartalmát mikor kell visszaírni a másodlagos tárolóra? (Módosított lapok kezelése) Lap hiba megszakítás Regiszterek

tartalmának elmentése Lap helyének meghatározása a másodlagos tárolón ALap lapképe képeaafőtárban? főtárban? Lap kiválasztása lapcseréhez Módosított a lap? Lap módosítva? Írjuk vissza a lapot Töltsük be az új lapot 121 Töltsük be az új lapot Írjuk át a lapkezelő táblát Visszatérés a megszakításból 11.3 Ábra A lap hiba megszakítás egy lehetséges algoritmusa A fenti három probléma megoldása nem egyforma nehézségi fokozatú. A megoldás során nagyon nehéz olyan általános stratégiát találni, amely széles körben felhasználható. Mégis van egy olyan elv, amelyet a gyakorlati algoritmusok tervezésénél jó hatékonysággal alkalmazhatunk. Ez a Belady (1966) által bevezetett lokalitás elve. Ennek az a lényege, hogy az aktuálisan hivatkozott - és az ezek közvetlen közelében elhelyezkedő - címekre a közeljövőben nagy valószínűséggel ismét hivatkozunk. A lokalitás elve a lapozási környezetben azt

jelenti, hogy az éppen hivatkozott lapra, és a környezetében elhelyezkedő lapokra hamarosan hivatkozhatunk. (Ezért ezeket érdemes megkülönböztetett figyelemmel kisérni.) Az igazsághoz tartozik az is, hogy nem mindig érvényesül ez az elv: ilyenek azok a programok, amelyek nagy adatbázisokat kezelnek, mesterséges inteligenciával foglalkoznak, vagy nagyobb méretű mátrixokon végeznek műveleteket. A. Betöltési probléma A problémára az elsődleges válasz nagyon egyszerű: akkor kell lapot tölteni a főtárba, ha a hivatkozott lap nincs ott. Finomíthatjuk a válaszunkat azzal, hogy azt mondjuk: amennyiben a lapra történő hivatkozás előre megjósolható, akkor egy másik betöltéssel együtt elvégezhetjük ennek a lapnak a mozgatását is. Ennek megfelelően beszélhetünk igények betöltéséről és előkészítésről. Azt mondhatjuk, hogy az előkészítés az mindig egy ”szívesség”, amelyik vagy kamatozik vagy nem. A tapasztalat azt mutatja,

hogy az esetek kb. felénél sikeres az előkészítés, a másik felénél nem, így számos gyakorlatban használt algoritmus nem is kisérletezik ennek alkalmazásával: csak az igények betöltését végzi el. A lokalitás elvét az un. clusterezés segítségével érvényesítik: Egy lap betöltésével egyidejűleg néhány szomszédos lapot is betöltenek. Ez a gondolat akkor különosen sikeres, ha a lapok mérete viszonylag kicsi. A clusterezés technikáját jój alkalmazták az IBM VMS operációs rendszerénél. 122 B. Elhelyezési probléma Ezt a problémát a legegyszerübb megoldani: egy lapra bontott környezetben jelenkező allokációs problémáról van ugyanis szó. Mivel minden lap képe azonos méretű, és a főtár véletlen eléréssel rendelkezik, ezért matematikailag minden kép terület azonos értékű. Nincs értelme annak, hogy a fizikai memória bármely részét kitüntessük. Ha egy lap a memóriában rendelkezésre áll, akkor azt ki lehet

választani C. Helyettesítési probléma A lapok helyettesítési stratégiájának megválasztása a legtöbb virtuális memória kezelő rendszer legfontosabb része. A nehézséget az szolgáltatja, hogy el kell kerülni azt, hogy az éppen eltávolított lapot rövid időn belül ismét vissza kelljen tölteni a memóriába. A legjobb persze az lenne, hogy azt a lapot távolítsuk el, amelyre többé nem lesz szükség. Ha ilyen lap nincs, akkor a következő legjobbat válasszuk ki (azaz azt a lapot, amelyre a legtovább nem lesz szükség.) Ez a fajta választás persze csak elméleti jelentőséggel bír, hiszen a jövőbeli igényeket sajnos nem ismerjük. Azt mondjuk, hogy ilyenkor on-line stratégiát kell választanunk. A következőkben néhány on-line algoritmust mutatunk be a helyettesítési probléma közelítő megoldására. Ezek mindegyikében a lokalitás elvét fogjuk felhasználni valamilyen formában. C.1 A legrégebb en használt lap (least recently used =

LRU) helyettesítése során azt a lapot távolítjuk el a memóriából, amelyet időben a legrégebben használtunk. Ez az algoritmus a gyakorlatban nagyon jól működik. A hátránya az, hogy a lapokra meg kell jegyezni a használat időpontját, és ehhez - a hatékonyság érdekében - valamilyen hardware segítségre van szükség. Az egyik legkézenfekvőbb technika az, hogy a lapleíró vektorban jegyezzük meg a legutolsó használat idejét. Ez rejti magában a módszer hátrányát is: az új mező miatt megnő a tárigény és a keresés is jelentős időt vehet igénybe. Ezért gyakran használják a hivatkozási biteket a leíró vektorokban. Ennek az a lényege, hogy amikor használunk egy lapot, akkor a referencia bitet átállítjuk a laphoz tartozó leíró vektorban. Időről időre megvizsgáljuk a lapokat, és a hivatkozási bit alapján valahogyan sorba állítjuk azokat. Ezután időszakonként minden referencia bitet törölünk Mivel ezek a módszerek nem

mindig a legrégebben használt lapot találja meg egy lapcsere során, ezért ezeket közelítő LRU szabályoknak nevezzük. Az algoritmusok megvalósítása során a leggyakrabban az un. ”használható listák” gondolatát alakalmazzák. Ennek az a lényege, hogy a sorbaállító algoritmusok kisebb listákat készítenek a prioritások felhasználásával, és a legkevésbé használt lapok listájából választ cserélhető lapot. C.2 A legritkábban használt lapok (least frequently used = LFU) algoritmusa azt a lapot távolítja el a memóriából, amelyet egy elmúlt időszak során a legkevesebbszer használtunk. Az algoritmus gyakorlati alkalmazásának az szab gátat, hogy nagyon nehéz olyan hardware támogatást találni, amely lehetővé tenné a hatékony 123 felhasználást. (Az algoritmusban valamilyen számlálót kell elhelyezni a leíró vektorokban, és ezek alapján kel sorba rendezni a lapokat.) C.3 FIFO stratégiát alkalmaztak a VAX gépeken Az

algoritmus azon a felismerésen alapul, hogy teljesen reménytelen a VAX gépeken elméletileg rendelkezésre álló összes lapra a fenti két stratégia bármelyikét hatékonyan alkalmazni, ezért az a legegyszerübb, ha a legrégebben a memóriában levő lapot választjuk ki cserére. Ez a stratégia messze nem olyan olyan hatékony, mint a az LRU , de sokkal gyorsabb. C.4 Kom binált m ódszerek k erültek megvalósításra a leggyakrabban A VMS környezetben pl. nagy használható listát alkalmaztak, a UNIX Berkeley változatában pedig a referencia bit helyett minden lapot időszakonként ”not-present”-nek (nincs jelen) deklaráltak. Ennek az lett a következménye, hogy amikor legközelebb erre a lapra hívatkoztak, akkor a lap hiba megszakítás lépett volna fel. Ezért, ha az időszak közben mégis használták a lapot, akkor megszüntették a not-present állapotot. Annak ellenére, hogy e megvalósítás során általában a lapok legnagyobb része not-present

állapotban van, mégis jól alkalmazható algoritmusról van szó, mert a gyakorlati tapasztalat azt mutatja, hogy a hardware-rel jól támogatható, és hatékonysága megközelíti az LRU hatákonyságát. D. A módosított lapok kezelése A lapcsere általában két lépésből áll: a memóriában lévő lap tartalmát kimentjük a háttértárolóra, és az új lapot behozzuk a helyére. E két lépés mindegyike időigényes, ezért célszerűnek látszik a mentést csak akkor végrehajtani, ha valmilyen módosítás történt a használat során. Ezt úgy érjük el, hogy egy lap módosítási bitet alkalmazunk a lapleíró vektorban. A használat során az OR ellenőrzi ezt a bitet, és csak azokat a lapokat írja vissza a háttértárra, amelyeknél ez be lett állítva. Jól használhatónak tünik az a gondolat, ha a használható lapok listáját két részlistára bontjuk külön kezelve a módosított és a nem módosított lapokat. Mivel a módosított lapok cseréje

mindig időigényesebb, ezért ebből a részlistából csak akkor választunk elemet, ha a másik üres. 11.3 A másodlagos tárolás 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ő adatstrukturákat alkalmazunk. 124 Nagy rendszerek esetében gyakran alkalmazott hardware megoldás az, hogy külön író-olvasó fejeket működtetnek sávonként, ezáltal jelentősen lecsökkentve az átlagos hozzáférési időt. Kisebb rendszereknél a lapok tárolására azokat a - mozgó fejekkel rendelkező - mágneslemezeket használják fel, amelyeken az állományokat egyébként is tároljuk. Ennek az a következménye, hogy a hatékonyság csökkenhet, hiszen a megosztás következtében a fejek két lap-transzfer

között elmozdulhatnak egy esetleges file-transzfer miatt. Mivel a legtöbb esetben az utóbbi kevert tárolási módszert alkalmazzuk, ezért különböző módszereket dolgoztak ki tárolási strukturákra: • Az egyik megoldás az, hogy a virtuális címzéssel egységesen kezelhető területeket a másodlagos tárolón is folytonosan elhelyezkedő területeken tároljuk. Ilyenkor az OR könnyen kezeli a lapokat a máodlagos területeken, hiszen egyszerű indexeléssel elérhetők az egyes címek. A módszert mégsem alkalmazzák gyakran, mivel a a virtuálisan címezhető terület viszonylag nagy, és a másodlagos tárolókon összefüggően lefoglalható terület pedig többnyire fizikailag erősen korlátozott. • A második módszer segítségével a logikailag egybe tartozó lapokat kezeljük csak egységesen, ezzel csökkentve a lap-transzferek számát. 11.4 Szegmentált virtuális memória Annak ellenére, hogy a lapokra bontott virtuális memória megkönnyíti a a

memória kezelés során felmerülő problémák megoldását, a programok logikai egységeinek külön szegmensekbe osztása további lehetőségeket nyújt.Amikor egy eljárást vagy adatstrukturát egy szegmensként kezelünk, akkor erre - egy adott időszakon belül egységes egészként hívatkozhatunk. Ennek több előnye lehet: a hozzáférések és tiltások könnyebben kezelhetők, és a lapozási tábla mérete is csökkenthető. Ennek az a következménye, hogy a legtöbb memória kezelő rendszerben a lapokra bontást és a szegmentálást együttesen alaklmazzák: először a programokat logikailag szegmensekre bontják, majd az egyes szegmenseket osztják lapokra. Annak a rendszernek, amely egy ilyen vegyes technikát használ két szintű átviteli technikát kell alkalmazni. Minden egyes folyamathoz a főtárban egy szegmens táblát rendelünk hozzá. Ez egy vektor, amelynek minden sora egy szegmens leíró vektort tartalmaz A hardware-t általában kiegészítik egy

szegmens tábla regiszterrel , amely a CPU-ban helyezkedik el, és az aktuálisan használt szegmens kezdőcímét és méretét tartalmazza. A szegmens leíró vektor szerepe hasonló a lapleíró vektor szerepéhez, ezért az egyes mezők is azonos jelentéssel bírnak azzal a különbséggel, hogy itt mindig a szegmensre - és nem a lapra - hívatkozunk. Beépíthetünk tehát a szegmens ”jelenlétét” jelző állapotjelzőt vagy a szegmens módosítását jelző módosítás flag-et is, amelyekkel a felesleges szegmens-transzfereket minimalizálhatjuk. A 114 ábra mutatja, hogy miként alakítható ki a szegmentált virtuális címzés esetében a fizikai cím. Szegmens Tábla Regiszter Virtuális Cím Sz.TBáziscím SzTMéret Sz.Sorszám 125 Lap Sorszám Eltolási cím + T.Báziscím T Méret Hozzáférés Jelenlét Szegmens Leíró Vektor + Lapkép Sorszám Jelenlét Módosítás Hivatkozás Lapleíró Vektor Fizikai Cím Lapkép Sorszám Eltolási Cím

11.4Ábra Fizikai cím kiszámítása szegmentált virtuális címzés esetében 12. Állományok kezelése A modern OR-k 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 r endszereknek (file system) nevezzük. A file rendszerek egymástól elkülönülő információs egységeit állományoknak (file) fogjuk nevezni. Az állományok többnyire azonos tulajdonságú kisebb logikai egységekből - un. rekordokból - állnak, amelyek mezőkből épülnek fel. Az OR-en belül az állományok kezelésével az állomány kezelő (file-manager) foglalkozik. Ennek a 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. Ezek a műveletek nagyon

kézenfekvőek: információk kiolvasását teszik lehetővé, biztosítják a lehetőséget ahhoz, hogy módosítani tudjuk a mezők tartalmát, lehetőséget adnak arra, hogy új rekordokkal bővíthessük az állományt és a feleslegeseket kitörölhessük. Az sem mellékes, hogy az állományokban levő információkat milyen gyorsan tudjuk elérni, összegyüjteni. Ezért 126 számos OR speciális lehetőségeket biztosít ahhoz, hogy az állományok rekordjait meghatározott sorrendben el tudjuk érni.Ezt indexelésnek nevezzük Fizikailag az információs rendszerek háttértárolókon helyezkednek el. Ezek az esetek legnagyobb részében vagy mágneslemezek vagy mágnesszalagok. A tipikus az, hogy az egy információs rendszerhez tartozó állományok fizikailag több egységen helyezkednek el úgy, hogy néha még az sem biztosított, hogy az egy állományhoz tartozó összes rekord ugyanazon az egységen található. A fejezet első részében azt vizsgáljuk, hogy

miként helyezhetők el az állományok egy tárolón. Ezután azt elemezzük, hogy milyen szerkezete lehet egy állománynak. Egy információs rendszerhez hozzátartozik, hogy a benne elhelyezett állományokról un. ”leíró” információkat (pl név, rekord hossz, blokkolási méret, tulajdonos, hozzáférési lehetőségek, a tartalom típusa, verzió, history stb.) tartalmaz Ezeket állomány leírókn ak (file descriptor) nevezzük. A descriptorokat a modern OR-k speciális állományokba, könyvtárakba (directory) tárolják. A következő alfejezet a könyvtárak felépítését tárgyalja. Az állományok kezelését tárgyaló fejezetet az állományokon végezhető alapműveletek bemutatásával folytatjuk, majd megvizsgáljuk, hogy milyen összefüggés található a készülékek kezelése és az állományok kezelése között. 12.1 A kötet fogalma és szerkezete Miként azt a bevezetőben már említettük az állományokat háttér tárolókon helyezzük el.

Ezeknek a készülékeknek egy része olyan, hogy állandóan a rendszerhez van kapcsolva, mások pedig fizikailag átmenetileg lekapcsolhatók rendszerről és helyükre új készülékek csatlakoztathatók. ( A mágnesszalagok és lemezek aaz utóbbi kategóriába tartoznak.) Mivel a tárolókat egységes egészként kezeljük az installálásnál és a helyettesítésnél, ezért a rajtuk elhelyezett állományokat is célszerű egységesen, a többi állománytól függetlenül kezelni. Az egy fizikai egységen elhelyezkedő állományokat kötetnek (volume) fogjuk nevezni. Egy tároló egység és a rajta tárolt állományok viszonya nagyon különböző lehet. A tipikus az, hogy az állományokhoz tartozó kötet megfelel egy fizikai készüléknek. Ha a fizikai készüléket valamilyen okból tovább osztjuk, (pl. különböző feladatokhoz vagy felhasználókhoz tartozó állományokat akarunk elhelyezni ugyanazon az egységen), akkor a kötetet particionálni lehet.

Amennyiben egy állomány mérete nagy, akkor az is előfordulhat, hogy egy kötet több tároló egységen helyezkedik el. Ezért különbséget kell tennünk logikai és fizik ai k ötet között: az előbbit használjuk a független állományok összességének megnevezésére, az utóbbi pedig nem más, mint egy tároló egység. Az egy köteten található informácók két fő csoportba oszthatók: állományok és könyvtárak. Ezek elhelyezését és szerkezetét a következő alfejezetekben vizsgáljuk A 127 könyvtárak szerkezetéről itt annyit jegyzünk meg, hogy mindig arra törekednek, hogy egymás utáni blokkokban helyezzék el a könyvtárhoz tartozó információkat. (Nyilván azért, hogy együtt lehessen mozgatni a hozzájuk tartozó adatokat a memória kezelés során.) Amennyiben lemezen tároljuk az állományokat, akkor a kötethez tartozó könyvtár számára elméletileg a legmegfelelőbb hely a lemez valamelyik középső sávja, mivel átlagosan ezt

lehet a legrövidebb időn belül elérni egy véletlenszerű kezdeti pozícióból. A gyakorlat mégis az, hogy a könyvtár a kötet legalacsonyabban sorszámozott blokkjain helyezkedik el. Ennek az lehet az oka, hogy a kötet közepén elhelyezett könyvtár feleslegesen szétbonthat állományokat, és a változó hossz miatt az adminisztrálás is bonyolultabb lehet. Külön terület van fenntartva az OR számára, hiszen olyan fontos műveletkre kell helyet biztosítani egy háttértárolón, mint a swap vagy a lapozás. Mivel ezek az OR más feladataival is összefüggő funkciók, ezért ezeket a területeket, és a területeken elhelyezett információkat nem lehet egyértelműen az információs rendszer részének tekinteni. Mivel a kötetek cserélhetők, ezért szükség van arra, hogy ezeket azonosítani tudjuk. Az azonosításhoz szükséges információkat a kötet leíró (volume descriptor) informácíók tartalmazzák. Ezeknek mindig meghatározott helyen kell

elhelyezkedni a köteten, és gyorsan elérhetőnek kell lenni, ezért többnyire a kötet első (vagy néhány első) blokkjában helyezkednek el. A kötet leíró információk közül sorolunk fel néhányat az alábbiakban: • • • • • • a kötet neve, hozzáférési információk, az információs rendszer 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. Az ismertebb OR-k közül a CP/M nem tartalmaz kötet leírást, az MS-DOS már igen. A UNIX esetében a kötet leíró csak részlegesen tartalmazza a fenti információkat. Az állomány neveket és további információt a rendszer speciális könyvtárakban a felhasználói állományok számára fenntartott területen tárol. Érdekes, hogy az OS/MVT kötetekhez nem tartozik rendszer terület. Ez az OR ugyanis külön köteteket foglal le az OR és az azt támogató programok számára. 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 a megválasztása döntően befolyásolja azt, hogy milyen gyorsan és kényelmesen érhetjük el az adatainkat. A blokkok szervezésének a módja erősen befolyásolja azt, hogy milyen ellenőrző információkra van szüksége az OR-nek ahhoz, 128 hogy a feladatait el tudja látni. Ebben a fejezetben azt vizsgáljuk meg, hogy miként lehet a blokkok és ezzel egyidőben a bennük tárolt rekordok fizikai elhelyezését megoldani, logikai kapcsolatait megszervezni ahhoz, hogy kényelmesen tudjuk kezelni ezeket. Ahhoz, hogy a különböző szervezési módszereket tárgyalni tudjuk, ismernünk kell azt, hogy milyen feladataink lehetnek egy állomány tárolása során. Ezek a feladatok az alábbiak lehetnek: • új állomány létrehozása, • meglévő állomány kiterjesztése • tároló

terület felszabadítása A fenti feladat megoldására a következő tárolási módszerek közül választhatunk: • • • • egyszerű, folytonos tárolás folytonos tárolás kiterjesztési lehetőségekkel láncolt blokkolás indexelt blokkolás 12.21 Egyszerű, folytonos tárolás A módszer lényege az, hogy az állományok elhelyezésre szükséges blokkok fizikailag folytonosan helyezkednek el. Ez az elhelyezési technika lényegében megegyezik azzal a módszerrel, amelyet memória szervezésnél láttunk abban az esetben, amikor a hardware semmilyen egyéb támogatásssal nem rendelkezik. A módszer legfontosabb előnye az, hogy 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. Ennek az a következménye, hogy a rendszerhez tartozó könyvtárak szerkezete is egyszerű lesz. A másik előny az, hogy 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. 4.Állomány SZABAD 3.Állomány 2.Állomány SZABAD 1.Állomány Descr.4 SZABAD Descr.3 Descr.2 SZABAD Descr. 1 Állomány kezdete Állomány mérete Állomány leíró vektor 12.1 Ábra Egyszerű, folytonos tárolás 129 A módszer hátránya az, hogy 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. Ez azt jelenti, hogy az állomány allokálásakor elegendő területet kell lefoglalni ahhoz, hogy a későbbi bővítésekhez legyen hely. A szétdaraboltság - a memória szervezéshez hasonlóan - itt is felléphet. Az ottani nehézségekkel szemben itt a probléma viszonylag egyszerűen kezelhető: időről időre újra kell szervezni az állományokat. Erre sz OR-k rendszerint külön programokkal rendelkeznek (az MS-DOS például compact parancsot használja). Arra azonban az OR-nek

ügyelnie kell, hogy az átrendezés alatt más programok nem használhatják az állományokat. 12.22 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 a részeket kiterjesztéseknek (extent) 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. Ebben a strukturában az állományok kezelése az előző fejezetben leírtakhoz hasonlóan történik oly módon, hogy a kiterjesztések különálló bejegyzésként szerepelnek a könyvtárakban. Az ismertebb OR-k közül a CP/M és az OS/360 használja ezt a technikát. 12.23 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, ha arra szükség van, de bonyolultabbá teszi az adminisztrációt, hiszen az állományhoz tartozó minden blokkot külön kell kezelni. Ugyanakkor 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álnak az ilyen típusú tárolás esetén. A blokkolt láncolás során az azonos állományhoz tartozó blokkok egy láncolt lista formájában vannak összefűzve. Az indexelt s zervezés esetében a blokkokban tárolt rekordokhoz indexeket rendelünk, és ezeket módosítjuk az állományban bekövetkezett változásoknak megfelelően. A. Blokkolt láncolás A módszert a következőképpen lehet leírni: az adatblokkokból leválasztunk egy láncolási információkat tartalmazó részt. Ezt szokták

header b lokknak nevezni 130 Ebben kétirányú felfűzést tárolhatunk az állományhoz tartozó kovetkező 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 egy pointer rendelünk. Ez a pointer az állományt tartalmazó első blokkra mutat. A módszer egyik nagy előnye az, hogy az adatblokkok tartalma könnyen analizálható a könyvtár ismerete nélkül is, hiszen egyetlen adatblokk megtalálása bejárhatóvá teszi az egész állományt. Ugyanakkor a hátránya az, hogy egyedül a szekvenciális elérést támogatja hatékonyan. Minden más elérési mód esetén túl sokszor kell a háttértárolóhoz fordulni. (Ezt a technikát alkalmazták a Commodore 64-nél ismertté vált CP/M esetében is.) Mivel a lemezes tárolás esetén a véletlen elérést is támogatja az OR, ezért más hatékonyabb telepítést kellett választani a technika megvalósítása során.

Az MS-DOS például a láncolási információkat kiemeli az adatblokkokból és egy un. FAT (file allocation table) táblában helyezi el. 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 állományban levő információk elérését meggyorsíthatja az, ha a FAT mérete lehetővé azt, hogy a táblát a memóriában tároljuk. (Érdemes megjegyezni, hogy a FAT nagyon fontos információkat tartalmaz. Ezért az MS-DOS a lemez egy meghatározott helyén egy másolatot is őriz az esetleges meghibásodás ”beláthatatlan” következményeinek elkerülésére. Mindkét változat kétségtelenül nagy előnye az, hogy egész blokk csoportok mozgathatók egyszerűen állományok között, és tehetők szabaddá, ha az szükséges. A könyvtári bejegyzés is nagyon egyszerű: mindössze az első adatblokk címét kell eltárolni. Hátránya - amint arra már korábban utaltunk - az, hogy a

véletlenszerű elérés csak hosszú keresés után valósítható meg, és abban az esetben, ha a FAT nem tartható a memóriában, még nehézkes is. Ezért számos OR választja a fenti módszer helyett a következő pontban leírt blokkolt indexelt szervezést. B.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ön választva - egy rekordban tároljuk. A UNIX egyes változataiban megvalósított 4 szintű strukturát mutat be a 12.2 Ábra 131 12.2 Ábra Négy szintű indexelt szervezés Az indexet minden állomány esetében az állomány leíró részeként tároljuk. Kis állományok esetében az összes blokkot a könyvtárban helyezzük el. Mivel az állomány leíró méretét korlátoznunk kell, ezért maximum 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. (Egy ilyen blokk további néhány száz cím tárolására alkalmas.) A fentiek mellett a UNIX azzal a további speciális szervezéssel rendelkezik, hogy az első néhány blokk címét az állomány leíró részben tárolja, amitől ezek elérése nagyon gyors lesz. Hasonlóan gyors lesz az egy további indexeléssel végrehajtható keresés vagy tárolás is. 12.3 Könyvtárak szervezése Amint azt az előzőekben jól láttuk az állományok kezelése erősen támaszkodik egy speciális szerkezetű leíró állományra, amelyet könyvtárnak neveztünk el. Azt mondtuk, hogy a könyvtárak a köteten található állományok jellemzőit írják le. Ebben a részben azt tárgyaljuk, hogy milyen információkat helyeznek el általában egy könyvtárban, a lemezeken hol helyezik el ezeket és milyen szerkezetűnek kell lenni ezeknek ahhoz, hogy jól tudja az OR

kezelni őket. 12.31 Az állományok neve Mivel az állományokhoz külső felhasználók és programok is hozzá akarnak férni, ezért 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 lenni, hogy az alapjén az azonosítás könnyen elvégezhető legyen. Az állományok neve általában egy egyszerű karaktersorozat, amely egy általánosan elfogadott kódrendszer segítségével adható meg. (Ilyen például az un ASCII = American Standard Code Information Interchange.) Különböző OR-k különböző szabályokat engednek meg agy állománynév megadásánál, néhány olyan elvárás azonban létezik, amelynek minden ”névkonvenciónak” meg kell felelni: a néven rövidnek kell lenni a jó tárolhatóság és a könnyü kereshetőség miatt és informatívnak kell lenni a felhasználó irányában. Az alábbiakban néhány rendszer példát mutatunk be. 132 CP/M:

UNIX: VMS: MS-DOS: OS/MVT: B:allkez.TXT /usr/gal/konyv/fej12.t vaxa:dk1:[gal.konyvfej]allkeztxt;9 C:/gal/konyv/fej/allkez.doc gal.konyvfejallkez A fenti példákban a ”fő” állománynév az allkez (állomány kezelés). Az ehhez csatlakozó komponensek egy része arra szolgál, hogy a név pontos helyét megtudjuk határozni a rendszeren belül. Ezek általában a név bal oldalára kerülnek Ilyen a csomópont név (node name), amely a hálózat egy logikai egységének a neve (pl. vaxa a VMS-nél), a készülék név vagy a kötet név (pl. B a CP/M esetében), a könyvtár neve. (A VMS példában a gal a konyvtárnév, a konyv és a fej alkönyvtárakat jelöl. Ugyanez a UNIX esetében úgy változik, hogy teljes névvel hívatkozunk a könyvtárra (/usr/gal/konyv/fej12.t), de a rendszer nem ismeri az alkönyvtárakat. A komponensek másik csoportja arra szolgál, hogy specifikálja az adott állományt, és általában az állománynév jobb oldalára írjuk ezeket. Ilyen

lehet az állomány típusának megjelölése (a txt kiterjesztés a VMS-nél vagy a doc kiterjesztés az MSDOS-nál egy speciális formátum megjelölésére szolgál), vagy a verziószám, amely több másolat esetében lehet hasznos (pl. a VMS esetén a definíció végén megadott 9) Fontos néhány szót szólni az állománynevek hosszáról: a felhasználó nyílván a lehető leghosszabb nevet akarja megadni azért, hogy könnyen fel tudja ismerni az állományt. Ugyanakkor a tetszőleges hosszúságban megadható nevek különböző nehézségekhez vezethetnek akkor, amikor az OR-rel akarjuk kezelni azokat. Ezért a legtöbb OR korlátozza a nevek hosszát. Néhány példa: MS-DOS=8, VMS=9, OS/MVT =44, RT-11=6. Ezek a korlátok általában csak az állománynévre vonatkoznak A kiterjesztések esetében a korlát legtöbbszöt mindössze 3 karakter. Ez nagy rendszerek esetében nehézségekhez vezethet. A később tárgyalandó hierarchikus könyvtárszerkezet segít kezelni

ezeket a problémákat azáltal, hogy megengedi azt, hogy az állományneveket könyvtárnevek esetleg nagyon rövid sorozatával azonosítsuk. Végezetül néhány szót az állománynevekben felhasználható karakterekről: az ORk általában korlátozzák a nevekban használható karakterek halmazát. Ennek egyik oka az, hogy minél több karaktert engedünk meg, annál több bitre van szükség egy karakter tárolásánál. Az RT-11 pl negyven karaktert enged használni, amely magába foglalja a nagybetűket, a számokat és nélhány speciális karaktert. (Így három karaktert el tud helyezni egy 16 bites szóban). A korlátozás másik oka az lehet, hogy nagy karkterhalmaz esetében olyan karakterek is bekerülhetnek egy névbe, amelyeket más esetekben határolójelként (pl. szóköz) vagy vezérlő karakterként használunk (pl a CTR kombinációk az MS-DOS esetében), és ez vagy nagyon megnehezítené a könyvtárak kezelését, vagy teljesen szét is rombolhatná ezeket

az állományokat. 12.32 Az állományok szerkezete 133 Az állományokat alapvetően két részre oszthatjuk. Az egyik részben foglalnak helyet az un. leíró információk, amelyek az állomány azonosításához szükséges adatokat tartalmazzák, míg a másik részben helyezkednek el az állomány rekordjai. A leíró információk OR-től függően nagyon eltérőek lehetnek. Általában az igaz, hogy fix hosszúságban helyezhetők el, és néhány alap információt (pl. állomány neve, címe, mérete, szervezése stb.) mindenképpen tartalmazniuk kell A leíró információkat kezdetben az állományokkal együtt tárolták, azonban a modern OR-k esetében ezeket már különálló könyvárakban helyezik el. Ezek a könyvtárak az OR szempontjából olyan ”egyszerű” állományoknak tekinthetők, amelyek számára összefüggően allokálunk fix hosszúságban lemezterületet. Ezt a helyfoglalást nagyon körültekintően kell elvégezni, mert ha feleslegesen nagy

területet foglalunk le, akkor pazaroljuk a tároló kapacitást, ellenkező esetben pedig nem tudunk megfelelő számú állományt a köteten eltárolni. Néhány OR megengedi az un többszintű könyvtár definálását is Ez lényegében megegyezik az indexelt állományok kezelésénél tárgyalt többszintű technikával, és a fent említett problémákat a dinamikus helyfoglalás segítségével megoldja. A könnyebb kezelhetőség kedvéért néhány OR szétbontja az állományleíró rekordokat: a UNIX esetében pl. a könyvtárak bejegyzése mindössze az állomány nevét és egy pointert tartalmaz. Ez utóbbi egy un információs csomópontra (i-node) mutat, ahol az állományra vonatkozó további információk találhatók. Egy ilyen szerkezetet mutat be a 12.3 Ábra Mint az az ábrából is jól kiolvasható, ez a fajta szerkezet nagyban hozzásegíti az OR-t ahhoz, hogy biztosítsa az állományok megoszthatóságát: a leíró információkat központilag tároljuk,

de lehetőség van arra, hogy különböző helyekről - esetleg másmás névvel - hívatkozzunk ugyanarra a fizikai állományra. Ezeket szokták alias neveknek hívni. A fejezet következő részében bemutatjuk a legelterjedtebb könyvtárkezelési technikákat. A. Egyszerű könyvtárak Kötetenként egyetlen könyvtárat használunk, amely állományonként tartalmazza a leíró információkat. Ebben az esetben az könyvtárrendszer kezelése egyszerű, hiszen egyetlen könyvtárunk van csak A módszer hátránya az, hogy a leíró rekordok száma nagyon megnőhet, aminek az a következménye, hogy megnövekszenek a keresési- és az elérési-idők is. Könyvtár 1. Könyvtár 2. 134 UNIX i-csomópontok Fizikai állományok 12.3Ábra Leíró állományok megosztása UNIX rendszer esetében Nehéz továbbá állomány csoportokat létrehozni felhasználók számára, és az egy könyvtár magában rejti annak a veszélyét is, hogy hosszú állományneveket kell

használnunk a külső azonosításhoz, amely ismét nehezebb helyzet elé állítja az OR-t. A korábban említett OR-k közül egyszerű könyvtárakat használ a CP/M és az OS/MVT is. B. Felhasználói k önyvtárak Abban az esetben, ha több felhasználó használhatja ugyanazt a kötetet, nem kivánatos az, 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 az olvasást más felhasználók számára. A másik probléma az, hogy több felhasználó esetében könnyebben fordulhat elő az, hogy ugyanazt a nevet használja két különböző felhasználó. Ezt néhány OR úgy kívánja elkerülni, hogy un minősített nevek használatát engedi meg. Ilyenkor a nevek kiterjesztésében lehet beírni a felhsználó nevét vagy azonosítóját. A másik lehetőség az, hogy felhasznnálónként egy speciális állomány definiálását engedjük meg, amely azokat az állományneveket

tartaémazza, amelyek a megadott felhasználókhoz tartoznak. Ezeket az állományokat katalógusnak nevezzük 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 a 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. A UNIX esetében ez a technika kombinálva van a hierarchikaus szervezésssel, amelyet a következő pontban ismertetünk. C. Hierarch ikus k önyvtárak A saját könyvtárak rugalmassága nagymértékben kiterjeszthető, ha megadjuk annak a lehetőségét, hogy a felhasználó szabadon definiálhasson könyvtárakat az állomány csoportjai számára. A technika lényege az, hogy létezik egy főkönyvtár, amelynek elemei (bejegyzései) kezdetben állományok. 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, amely

alkönyvtárban 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. 135 A rendszerben egy állományt a könyvtárak sorozatával definiált úttal (path) tudunk elérni. Ez időnként konfliktusokhoz vezethet, ha a hierarchia nagyon mély Ezért ezekben a rendszerekben bevezették az un. aktuális könyvtár (current directory) fogalmát. Ez azt a könyvtárat jelenti, amelyben a felhasználó pillanatnyilag ”tartózkodik”, és ehhez a könyvtárhoz viszonyítva adhatunk meg állományneveket az OR számára. Ennek megfelelően kialakult a teljes (vagy abszolut) út és a viszonylagos (vagy relatív) út megadásának a technikája. 12.4 Műveletek állományokon Akármilyen szervezést is alkalmazunk az állományok elérésére, a fő cél mindig az, hogy lehetőséget adjunk mind a felhasználóknak mind pedig a programoknak

arra, hogy műveleteket végezhessenek az állományok tartalmán. Amikor a felhasználó nyúl az adatbázishoz, akkor ezek a műveletek egy magasabb szinten játszódnak le: pl. kulcs szerint akarnak elérni rekordokat vagy le akarják kérdezni az adatbázis tartalmát. Ezeket az igényeket a program interface-nek kell végrehajtani, és a végrehajtás előtt egyszerű műveletek sorozatára kell lebontania. A program interface állomány kezelő része az, amely ezeket az alapműveleteket végrehajtja. A legalacsonyabb szinten ezek rendszerhívások formájában valósulnak meg. A rendszerhívások a legritkább esetben programozhatók direkt módon. Általában rendszer szubrutinokban vannak beépítve, amelyek egy szinttel magasabban helyezkednek el. Amikor egy állománnyal dolgozni akarunk, akkor a rendszerhívásokat különbözőképpen osztályozhatjuk. A. Állományok elérése Az első osztályba soroljuk az állományok elérésével kapcsolatos hívásokat. Ilyenkor a

legtermészetesebb sorrend a rendszerhívásokra a megnyitás(open), keresés (seek), olvasás (read), írás (write), lezárás (close). A modern OR-k szinte kivétel nélkül igénylik a rendszerhívást egy állomány megnyitásához. Ilyenkor a rendszer azonosítja az állományt, beállítja a kívánt hozzáférérsi módot, és előkészületeket hajthat végre ahhoz, hogy a későbbiek során a megkívánt módon használhassa az állományt. Ilyen előkészület lehet az, hogy helyet foglal egy időszakos puffer számára, létrehoz vagy bejegyzéseket hajt végre az állományhoz tartozó ellenőrző blokkban (FCB = file control block). Ilyenkor határozzuk meg az OR számára azt, hogy • • • • • az állomány írásra, olvasásra vagy mindkettőre akarjuk használni, az elérést sekvenciálisan vagy véletlenszerűen akarjuk elérni, milyen egységekben (blokkokban) óhajtjuk az átvitelt megvalósítani, mekkora pufferterületeket akarunk lefoglalni, a

megnyitott állományt más felhasználók is használhatják-e. 136 Ezután - a fenti ”paraméterek” ismeretében - a rendszer az óhajtott írási és/vagy olvasási műveleteket rendszerhívások útján végrehajtja. Ennek során az elérési módszerben meghatározott módon, a pufferek felhasznásával történik az átvitel. Annak ellenére, hogy ezek a rendszerhívások egyszerűek, az OR-nek nagyon is bonyolult, előrelátó stratégiát kell követnie ahhoz, hogy megbízhatóan, hatékonyan hajtsa végre ezeket a feladatokat. A stratégia fontos része a pufferek biztosítása, hiszen a rendszer általában - nagyobb egységekben mozgatja a rekordokat a háttértár és a központi tár között, és ezeket a blokkokat a puffer(ek)ben helyezi el. Amikor az utolsó I/O műveletet is végrehajtottuk, akkor agy close utasítással zárjuk az állományt. Ezzel a paranccsal az OR írásra megnyitott állományok esetében kimásolja a pufferekből az aktuális

tartalmat, felszabadítja az eddig lekötött puffereket. B. Terület szervezés Dinamikus file-rendszer esetében az OR-k alapvető szolgáltatásai közé tartozik az a lehetőség, hogy állományokat állít elő és állományokat töröl, továbbá meglévő állományokat bővít új rekordokkal, ill. rekordokat vág ki már meglévő állományokból Ezeket a műveleteket a rendszer rendre a create, delete és az extend ill. truncate rendszer hívásokkal végzi el. Amikor elő akarunk állítani egy állományt, akkor meg kell adni az új állomány nevét, a felépítését, szervezési módját és esetenként még néhány további paramétert rekordok hosszát, adatok szervezését a háttértáron stb.) Blokkolt szervezés esetében általában az előállításkor nem szükséges blokkokat allokálni; az első ilyen műveletre az első írási vagy olvasási parancs végrehajtásával egy időben kerül sor. (Ilyen szervezést végez a UNIX is) Ha a szervezés nem blokk

típusú, (mint pl. a CP/M és az MVT esetében), akkor a kezdeti méret allokáció mindig szükséges. Néhány OR nem teljesen logikai háttér nélkül kombinálja a create és az open rendszerhívásokat, hiszen e két müvelet összefüggése teljesen kézenfekvő: egy újonnan előállított állomány azonnal meg is nyit a rendszer, és/vagy nem létező állományt megnyitáskor elő kell állítani. Az extent rendszerhívásokat olyankor használjuk, amikor újabb területeket akarunk lefoglalni egy állomány számára. Ebben az esetben az előrelátó szervezés az állományok lezárásakor felszabadítja az adatokat nem tartalmazó allokált területeket. A truncate hívásnak olyankor van éretlme, ha az előző művelet nem történik meg automatikausan: ilyenkor az állományok lezárásakor a ”felesleges” területeket e parancs segítségével fel lehet szabadítani. C. Kiegészítő műveletek Az OR-k általában egy sor olyan művelettel rendelkeznek, amelyek

támogatják azt, hogy információkat kapjunk vagy megváltoztassuk a az állományok attributumait vagy az elérési lehetőségeket. Az egyik legismertebb ilyen művelet a rename , amely az 137 állománynév megváltoztatására szolgál. Az utasítások másik csoportja lehetőséget ad arra, hogy megváltoztassuk az állomány tulajdonosát, elérési korlátait és típusát. (A UNIX-ban ezek az utasítások a chmod, chown és a chgrp .) Abban az esetben, amikor az OR lehetőséget biztosít arra, hogy állományokat egyidőben több felhasználó is kezeljen, az OR rendelkezik egy link utasítással, amely lehetőséget arra, hogy egy állományra több névvel (alias) is hívatkozzunk. D. Kötet kezelés Azoknál a file-rendszereknél, amelyek lehetőséget adnak arra, hogy köteteket fizikailag eltávolítsunk vagy helyettesítsünk az OR-nek szüksége van arra, hogy felismerje a változtatás tényét. Abban az esetben, ha már a hardware érzékeli a változást,

akkor nincs szükség direkt műveletre, ellenkező esetben a rendszer rendelkezik egy mount ill. unmont műveletel, amellyel a szükséges módoításokat végre lehet hajtani.(Ezek az utasítások nélkülözhetetlenek pl a UNIX esetében) 138 13. Hibakezelés, megbízhatóság, védelem Mindezideig az OR-k olyan feladataival és a feladatokhoz tartozó megoldásokkal foglalkoztunk, amelyek egyrészt az üzemszerű használathoz taroztak, másrészt azt feltételezték, hogy a rendszer használata során minden hibátlanul működik és nincs szükség illetéktelenek elleni védelemre sem. Annak ellenére, hogy reményeink szerint jól követhető volt az, miként vált egyre bonyolultabbá az OR annak következtében, hogy mind összetettebb feladatokat kellett megoldania, mégis azt mondhatjuk, hogy 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. (Ha valaki készített már bonyolultabb felhasználói rendszert, akkor az jól tudja, hogy ez a megállapítás érvényes azokra a rendszerekre is.) Ebben a fejezetben három olyan feladattal foglalkozunk, amelyek az OR-k mindennapos vizsgálatánál méltánytalanul a háttérbe szorulnak. 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. 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, processznek) is. A hibák elsődleges jelzése a visszatérési (return) kóddal történik. Emellett egy OR filozófiája megkövetelheti azt, hogy hibaüzenetet is küldjünk az operátori konzolra

vagy a felhasználói terminálra. Ebben az esetben a hibaüzenetek formája és időzítése nagyon fontos a hiba elhárítása szempontjából. Mivel ilyenkor a hibaüzenet csak időszakosan jelenik meg a képernyőn, ezért szükség lehet további adminisztrációra is. Tételezzük fel ugyanis, hogy egy I/O művelet végrehajtása során a hardware valamilyen hibát jelez. Ilyenkor a készülék megpróbálja kiküszöbölni a hibát Ha a hiba megmarad, akkor hibakódot generál a tevékenység. Ezt a hibát a felhasználó érzékeli és valahogyan reagál rá, majd a hibakódot kitöröli és így az nem biztos, hogy az üzemeltető, a rendszergazda tudomására jut. Ezt a jobb OR-k úgy biztosítják, hogy adminisztrálják a hibát: egy un. hiba (error) log állományba bejegyzik a hiba 138 időpontját, kódját, üzenetét és annak a processnak a sorszámát, amelynek futása alatt a hiba keletkezett. Innen aztán bármely későbbi időpontban a keletkezett hibák

kigyüjthetők, feldolgozhatók és a hardware ill. software problémák megoldhatók Mivel nem kizárható, hogy több hiba lép fel egy időben, ezért a hibákat a rendszer egy hibaüzenet sorban helyezi el, és a megjelenítést valamint az adminiszrálást innen hajtja végre. Többfelhasználós rendszerek esetében a hibaüzenet az operátori konzol monitorra történik. (Nagy rendszereknél előfordul, hogy külön hiba konzolt illesztenek a rendszerhez, hogy könnyebben kezelhetővé tegyék az elhárítást.) A fenti feladatokat egyes OR-k un. hibakezelő szubrutin segítségével látják el, mások pedig külön processt futtatnak az üzemeltetési idő alatt. Az utóbbi technika a nyomtató spoolerhez hasonló módon működik: a rendszer üzeneteket rak le a sorba, és a hibakezelő process FIFO feldolgozást alkalmazva megjeleníti a sorban elhelyezett üzeneteket. Ha az üzeneteket tároló sor üres, akkor a feldolgozó process egyszerűen blokkolt állapotba kerül.

Bizonyos esetekben fontos lehet, hogy néhány ”kritikus” üzenet időben legyen feldolgozva, ezért előfordulhat, hogy az üzenetek mellé prioritást rendel az OR, és a feldolgozás ennek megfelelően történik. Tovább ”színesítheti” a feldolgozást, ha a hibaüzenethez egy lámpa kigyújtása és/vagy hangjelzés is párosulhat. Ezekben az esetekben az ilyen tevékenységek szükségességét flagek bebillentésével jelezzük, és kezelésük is a hibakezelő process feladatai közé tartozik. A következőkben néhány olyan hibatípus kezelését mutatjuk be, amelyekkel a felhasználók találkozhatnak. 13.11 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, vagy a nyomtatásoknál fellépő különböző hibák is. Az I/O készülékeket kezelő meghajtóknak (driverek)

egyetlen feladata van: sikeresen végrehajtani a kitűzött műveletet. Ennek az a következménye, hogy a fellépő hibák kezelését teljes egészében áthárítják a felhasználóra. A hibajelzés általános szabályai itt is érvényben vannak, tehát elháríthatatlan hiba esetén azon kívül, hogy a felhsználót értesíteni kell a hibáról a log állományba is megtörténik a bejegyzés. A hiba érzékelésnek van azonban egy másik szabálya is: annak ellenére, hogy a készülékek a műveletek jellemzőiben és az előforduló hibák típusaiban is erősen különböznek, az OR-nek mégis ügyelnie kell arra, hogy az azonos típusú hibákat azonos hibakóddal ás hibaüzenettel jelezze. Készülékek esetében a leggyakrabban előforduló ilyen hiba az un. not ready (nem felkészült) feltétel megjelenése, amely azt jelzi, hogy a használni kívánt készülék nem áll rendelkezésre a ”megszólítás” pillanatában. Ha egy ilyen hiba jelentkezik, akkor az

OR-t értesíteni kell erről, hiszen ez jelzi azt, hogy tényleges adattranszfer nem hajtható végre a készüléken. Abban az esetben, ha a készülék un ”kritikus” készülék, akkor az OR egyik fő feladatává lép elő, hogy beszüntesse a további munkát és megpróbálja leállítani a futó folyamatokat a lehető legkevesebb káros következmény nélkül. (Ezt nevezik shut down-nak) 139 A mágneses adatátviteli készülékeken keletkező hibák egyik speciális fajtája az, amikor magán az adathordozó rétegen következik be olyan károsodás, amely nem javítható sem újra formattálással sem pedig újra írással. Ezt a hibát permanens készülék hibának nevezzük. Egy ilyen hiba következménye az, hogy a mágneses adathordozó egyes területei (mágneslemez esetén pl. szektorok vagy egész sávok) nem használhatók többé biztonságos adattárolásra. Ezért ezekre írni többé nem szabad, a rendszert erről értesíteni kell. Két általánosan

elterjedt módszert alkalmaznak a hibás területre való írás elkerülésére: • Az adathordozóról felhaszálási táblát készítünk • ”Rossz” állományokat allokálunk a hibás területre. Az első módszer abból áll, hogy amikor az adathordozón hibás szektort vagy blokkot találunk, akkor azt egy a felhasználók elől elrejtett táblázatba (bad track table, bad sector tab le, b ad block table ) írjuk, amelyet allokálásnál az OR (ezen belül a készülék kezelő) mindig megvizsgál, és gondosan ügyel arra, hogy ezekre a területekre ne kerüljön információ. A második eljárásnál (ezt használja az RT-11 is) a rendszer azáltal kerüli el a hibás terület allokálását, hogy speciális állományokat un. ”rossz” állományokat (bad file) maga allokál a területre, ezáltal téve azokat foglalttá. Ilyenkor az egyszerű felismerhetőség kedvéért ezeket az állományokat speciális kiterjesztéssel látja el a rendszer (pl. BAD) 13.12

Programhibák kezelése A felhasználói programok futása közben is előfordulhatnak hibák. Ilyenek lehetnek a nullával való osztás vagy az érvénytelen memóriacímre történő hívatkozás. Ilyenkor programhiba megszakítás lép fel a rendszerben. Az ilyen hibákat kétféleképpen kezelhetjük le: • Befejezzük a program futását. • Egy hiba kezelő szubrutint indítunk el. Általában az első megoldás az elfogadott. Ilyenkor a megszakítás okát is közli a rendszer a hibaüzenetben. Amennyiben a hiba batch környezetben jelentkezik, akkor a hibaüzenet a nyomtatott listán jelenik meg. A második esetben a futó folyamat egy hiba kezelő szubrutint aktivizál, amely egy különálló folyamatként kerül a rendszerbe. A végrehajtás menetét mutatja be a 131 Ábra. A feltüntetett tevékenységek sorrendje a következő: 1. Programhiba jelentkezik a felhasználói program futása során 2. Az OR megszakításkezelő szubrutinja átadja a vezérlést a hibakezelő

eljárásnak 3. A hibakezelő lefut, és visszaadja a vezérlést a megszakítéskezelőnek 4. A megszakításkezelő visszaadja a vezérlést a megszakított folyamatnak 140 Itt hívjuk fel a figyelmet arra, hogy az a programozó, aki valamely programja során a programozási nyelv által megengedett ON ERROR parancsot használja, az pontosan az itt vázolt műveletsort aktivizálja az OR működésében. 1 OR megszakítás kezelő Program 4 2 Hibakezelő 3 13.1 Ábra Megszakító szubrutin alkalmazása programhiba kezelésre Külön kell szólni arról az esetről, amikor a hiba az OR-n belül keletkezik. Ez azért veszélyes, mert egy fordítóban vagy szerkesztőben jelentkező hiba a programok széles körére kihat, és súlyos problémákat okozhat, ugyanakkor nagyon nehéz detektálni ezeket. (Általában az ilyen programoknál észlelt hibákat az OR készítőinek kell jelezni.) 13.13 A file rendszer hibáinak kezelése Amennyiben valamilyen hiba keletkezik egy lemez

egysé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-knél, ezért az állomány kezelő 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. Elegendő csak a kimentésekre (backup) és a visszatöltésekre (restore) gondolni. Még az olyan egyszerű OR, mint az MS-DOS is rendelkezik file rendszer ellenőrző programmal (CHKDSK). A bonyolultab OR-k közöttük a UNIX is olyankor ellenőrzik a file rendszert, amikor a shut down-t hajtják végre. Ha ez nem történt meg, akkor hibák maradhatnak a rendszerben pl. azáltal, hogy állományok rekordjai memória rezidens pufferekben maradnak. Az ilyen hibák kiküszöbölésére a UNIX rendelkezik egy fsck nevű shell-programmal, amely megkíséreli

visszaállítani a megsérült állományokat és könyvtárakat. Az ilyen ”felderítés” során előfordulhat, hogy olyan ”árva” állományokat talál a program, amelyek allokálva lettek, de nem hivatkozunk rájuk sehol. Ezeket az állományokat a program ismét a rendszerhez csatolja azáltal, hogy elhelyezi azokat egy lost + found nevű könyvtárba. 141 Összegezve a fentieket: 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 rendszerrről backupot vagy töltsük vissza a rendszert. 13.2 Megbízhatóság Amikor egy OR kapcsán megbízhatóságról beszélünk, akkor tulajdonképpen két egymáshoz hasonló, de mégis egymástól eltérő fogalmat képzelünk magunk elé: • Egy OR megbízható akkor, ha használható és korrekt marad akkor is, ha hardware problémák és/vagy software hibák lépnek fel. • Biztonságos

az az OR, amely 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. Azt már a téma tárgyalásának elején leszögezhetjük, hogy nincs olyan technika, amely minden körülmények között garantálná a tökéletes megbízhatóságot és a biztonságot. A cél csak az lehet, hogy olyan stratégiát tudjunk nyújtani, amely nagy valószínűséggel biztosítja a számunkra a sikert. A probléma az, hogy 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 softwareket kell kifejlesztenünk az üzemeltetéshez. Ez eredményezte azt, hogy a 70-es évek közepéig a legtöbb OR kevés súlyt fektetett ezeknek a problémáknak a megoldására. Az idő múlásával azonban a kérdést nem lehetett megkerülni: a számítógépeket egyre szélesebb körben használták, és olyan a biztonságra rendkívül

érzékeny felhasználók jelentek meg, mint a bankok, a katonai alkalmazások, államigazgatási nyílvántartások és a különböző on-line rendszerek. Ebben a fejezetben először azokkal problémákkal foglalkozunk, amelyek a biztonságot veszélyeztető hibákhoz vezethetnek, majd néhány olyan stratégiát mutatunk be, amelyek ezeket a hibákat kezelik le. A befejező részekben megmutatjuk, hogy milyen hardware ill. software eljárásokkal növelhetjük egy OR megbízhatóságát Az OR-k megbízhatóságát befolyásoló hibákat három csoportba oszthatjuk: beszélhetünk tervezési, konstrukciós és működési hibákról. A hardware elemeknél mindhárom hiba felléphet. A gyakorlatban a legtöbbször ez úgy jelentkezik, hogy az idő múlásával az alkatrész elhasználódik, aminek időszakos majd teljes meghibásodás lehet az eredménye. A másik igen gyakran fellépő probléma a feszültség kiesés. Azokat a rendszereket, amelyek az így fellépő hibák

ellenére is biztonságosan működnek hiba tűrő rendszereknek nevezzük. A software nem használódik el, azonban a tervezési és a konstrukciós hibák sokkal valószínűbbek mind a felhasználói programoknál mind az OR-nél. A leggyakrabban 142 fellépő hiba az, hogy egy program nem fogad el bizonyos input adatokat, vagy nem ismer fel érvénytelen inputot, esetleg nem dolgozik korrekt módon ritkán előforduló feltételek mellett. Ha a fenti hibák közül bármelyik előfordul, akkor arra kell törekedni, hogy az OR az ebből fakadó hibákat ismerje fel, és a következményeket a minimálisra redukálja. A legfontosabb feladat ilyenkor az, hogy egy folyamat működése során fellépő hiba nem befolyásolhat más folyamatokat. Erre mondjuk azt, hogy az OR feladatai között szerepel a hiba korlátozása is. Mivel olyan rendszert tervezni, amelyben hibák nem lépnek fel egyszerüen nem lehet, ezért célszerű a gondos előkészítés és kivitelezés mellett

arra koncentrálni az erőinket, hogy ha a hiba fellépett, akkor hogyan tudunk a leggyorsabban megszabadulni attól. (Ez érvényes mind a hardware mind a software hibákra is) Egyes kutatók szerint (Wulf [1975]) ez utóbbi feladat sokszor fontosabb is mint a megelőzés. Siewiorek [1984] tíz olyan fontos lépést definiált, amelyet el kell végezni egy hiba felszámolása során: • Korlátozás: Tervezzük az OR-t úgy, hogy az előforduló hibák a legszélesebb körben felismerhetők legyenek még azelőtt mielőtt súlyosabb következményeik lehetnének. • Érzékelés: Használjunk mind hardware mind software technikákat az érvénytelen adatok kiszűrésére, és a hibás működés érzékelésére. • Kiszűrés: Az érzékelt hiba hatásait minél gyorsabban tüntessük el, és folytassuk a kitűzött feldolgozást. • Ismétlés: Ismételjük meg a hibás műveletet, hátha a fellépő hiba csak átmeneti volt. • Diagnózis: Azonosítsuk a hibás hardware vagy

software komponenst. • Átkonfigurálás: Alakítsuk át a rendszert úgy, hogy a meghibásodott egységet vonjuk ki az aktív használatból. • Visszaállítás: Próbáljuk meg ”visszafejteni” a hiba következményeit. Javítsuk ki a hibás adatokat vagy ismételjük meg a korábban hibás műveleteket. • Újraindítás: Ha nem tudjuk az összes adatot visszaállítani, akkor indítsuk újra a rendszert. • Javítás: Javítsuk meg vagy helyettesítsük a hibás elemet. • Beillesztés: A megjavított elemet vegyük ismét használatba. 13.21 Hardware megoldások Ebben az alfejezetben röviden tárgyaljuk azokat a hardware megoldásokat, amelyeket szélesebb körben alkalmaznak a hibák megelőzésére: • A memória védelem biztosítja azt, hogy egy folyamat csak azokat a címeket használhassa, amelyekre engedélye van. (Ezt nem csak többfelhasználós környezetben alkalmazzuk, hiszen egy felhasználó esetén is előfordulhat, hogy a memória egy részét

lefoglaljuk az OR számára. 143 • A timerek segítségével szakítjuk meg azokat a folyamatokat, amelyek túllépték a számukra engedélyezett időkorlátokat. • Hardware eszközöket kell alkalmaznunk adatátvitelnél annak biztosítására, hogy kiszürjük az adatátviteli csatornán bekövetkező adattorzulásokat. Ennek két legismertebb módja a paritás bit használata és az ellenőrző összeg alkalmazása. • A számítógépek legkritikusabb fizikai erőforrása az elektromos feszültség. Itt nem csak arra gondolunk, hogy az áram hiányában nem működik a gép, hanem arra is, hogy a frekvenciában és az áramerősségben bekövetkező változások is lehetnek a hibák forrásai. Mivel ezek olyan külső hatások, amelyek legtöbbször kívül esnek az ellenőrizhetőség határain, ezért a cél maximum az lehet, hogy egy erősebb áramingadozást kiszűrjünk vagy áramkimaradás esetén minimálisra csökkentsük annak a veszélyét, hogy

visszafordíthatatlan adatvesztés következzen be. Ehhez a leggyakrabban alkalmazott eszköz a szünetmentes tápegy ség (UPS = uninterruptible power source), amely elegendő tartalék árammal rendelkezik ahhoz, hogy a rendszer a rendelkezésére álló idő alatt leépítse a file rendszert, esetleg komplett folyamatokat is befejezzen, ha azok nem szakíthatók félbe. • A hardware redundancia olyan rendszerek esetében, amelyek különösen megkövetelik a biztonságos működést, gyakran alkalmazott megoldás. Ilyenkor arról van szó, hogy bizonyos hardware elemeket duplán építenek a rendszerbe, és automatikus vizsgálattal biztosítják hibás működés esetén azt, hogy a rendszer át tudjon térni a ”tartalék” hardware elem használatára. Az egyik legyakrabban alkalmazott megoldás a második CPU beépítése ill. a készülék kontrollerek megduplázása. Az egyik legismertebb a TANDEM cég által 1975-ben bevezetett architektura. 13.22 Software megoldások Az

világos, hogy olyan egyedi megoldások, mint a TANDEM rendszere teljesen egyedi OR-t követel meg. Ezekkel ebben a jegyzetben nem foglalkozunk Más hardware megoldások software támogatásával (mint pl. a paritásbit alkalmazása vagy a timerek ellenőrzése) már korábban foglalkoztunk. Itt egyetlen olyan általános elvet tárgyalunk, amely a hibák kezelését megkönnyíti. Ez a szakirodalomban defenzív programozás néven ismert. Ennek az a lényege, hogy egy programnak mindig ellenőriznie kell a fogadott adatokat, sohasem szabad megbízni azok helyességében. Ha azonban az adatainkat állandóan ellenőrizzük, akkor annak több következménye is lenne: alaposan lecsökkenne a hatékonyság, megnövekedne a programok bonyolultsága és redundánssá válnának a programok abban az értelemben, hogy számos ismétlődés fordulna elő bennük. Ezért néhány esetben eltekinthetünk az ellenőrzéstől. Ha biztosak vagyunk abban, hogy az adatot egyszer már ellenőriztük,

és azt nem módosítottuk az ellenőrzés óta, akkor nem szükséges az elővigyázatosság. A fenti elv alkalmazása felhasználói rendszerek esetében (is) kézenfekvő. Az ORk esetében a helyzet kissé eltérhet a mindennapos használattól: néhány OR ugyanis 144 olyan adatokat is használhat, amelyek azon túl, hogy nem az OR-n belül keletkeztek, a felhasználói programok által elérhető területen vannak tárolva, ami rendkívül veszélyes. (Ilyenek a file control blokkok, a process control blokkok, a rendszerhívásoknál használt paraméterblokkok stb.) Ha ezeket az adatokat felülírhatjuk az éppen futó felhasználói programokból, akkor az komoly hibaforrás lehet. Extrém esetben előfordulhat az is, hogy egy process aközben írja át az adatot, miközben azt éppen használja az OR. Ezek a problémák jelentkeznek mind az olyan kis rendszereknél mint a CP/M, mind pedig az olyan nagyobb rendszereknél, mint az OS/360-on használt MVT. A megoldás ilyenkor

az, hogy a rendszer adatokat mindig elkülönítjük a felhasználók által elérhető területtől. Ha egy adatot felhasználói programtól kap a rendszer, akkor azt még mielőtt a folyamat folytatná a feldolgozást kimásoljuk egy védett területre, és onnan végzi el az OR a feldolgozást. 13.3 Védelem A számítógépekben tárolt adatok védelmének a fontossága ma minden kétséget kizár. Az életnek szinte nincsen olyan területe, amelyben ne használnánk számítógépeket, és nagyon sok ember munkája, megélhetése, egzisztencája kötődik valamilyen módon a számítógépekhez: a különböző rendszerekben üzleti információkat tartanak nyílván, adóbevallásokat tárolnak, banki számlákat és hiteltartozásokat vezetnek, betegségek kórlapjait dolgozzák fel. Ezek mind olyan információk, amelyek illetéktelen birtoklása nem csak üzleti érdekeket, hanem személyi jogokat is sérthet. Az adatok számítógépen belüli védelméről tehát

gondoskodni kell. A védelmet nagymértékben nehezíti az, hogy ma már a nagyobb rendszerek esetében egy adatállomány adatai nagyon széles körben kerülnek feldolgozásra, és ezért azokat kommunikációs csatornákon keresztül számítógépes hálózatok segítségével el lehet érni, ki lehet olvasni, másutt fel lehet dolgozni, és a feldolgozott (megváltoztatott) adatokat vissza lehet írni az eredeti állományba. Ebben a fejezetben egyrészt azokkal a védelmi technikákkal foglalkozunk, amelyekkel egy számítógépet kell óvni a külső illetéktelen behatolástól, másrészt azokat az eljárásokat ismertetjük, amelyekkel az adatátvitel során el lehet rejteni az adatokat mások elől. 13.31 Belső védelem A belső védelmi mechanizmus általában az OR része. Kiépítése során arra kell figyelni, hogy • csak jogosult személy legyen képes belépni a számítógépes rendszerbe, • több felhasználó által használható adatokat csak ellenőrzött

módon lehessen elérni. 145 A jogosultság eldöntése azonosítással történik. Erre alkalmas lehet minden olyan eszköz, amellyel a felhasználó egyértelműen igazolhatja azt, hogy olyan információ birtokában van, amely lehetővé teszi a rendszer bizonyos részeihez való hozzáférést. Ez lehet egy azonosító kártya, vagy egyéb fizikai azonosító (pl. aláírás, ujjlenyomat), egy kulcsszó vagy más olyan ismeret, amely amely a személy kizárólagos ismeretanyagához tartozik (pl. zárkombináció vagy speciális dátum ismerete) Ezek közül a leggyakrabban a kulcsszó a használatos, de a mesterséges intelligencia fejlődésével egyre inkább előtérbe kerülnek olyan felismerési eljárások, amelyek a hangot, az ujjlenyomatot vagy egyéb más olyan nehezebben átruházható jellemzők alapján azonosítanak. A kulcsszavak alkalmazása során az egyes felhasználókhoz egy rekordot rendel az OR, és a nehezebb elérhetőség kedvéért kódolja azt. A

kódolási eljárás szemben az egyéb szöveg kódolásokkal rendelkezik egy speciális tulajdonsággal: a kódolt kulcszó dekódolására ugyanis sohasincs szükség, mert az azonosítás úgy történik, hogy a ”titkosan” beütött ellenőrző kulcsszót is kódolja a rendszer, és a két kódolt formát hasonlítja össze. Mivel a kulcsszó rendkívül fontos a rendszerhez történő hozzáférés során, ezért annak megválasztása is alapvető jelentőséggel bír. Itt nem csak arra gondolunk, hogy a könnyen megfejthető információ illetéktelenek számára is könnyen hozzáférhetővé tesz adatokat, hanem arra is, hogy a ”stabil”, hosszú ideig nem változtatott információ nagyobb lehetőségeket nyújt a megfejtésre. Ezért néhány OR kötelezi a felhasználókat arra, hogy időről időre új kulcsszót válasszon. Egy másik kézenfekvő védelem az, hogy korlátozzuk az illetéktelen bejelentkezések számát például azzal, hogy a harmadik inkorrekt

kulcsszó megadása után blokkoljuk a bejelentkezés lehetőségét. A belső védelem megvalósításának másik eszközéről már korábban is esett szó. Az adatok ellenőrzött elérésének legegyszerübb bár kétségkívül a legdrasztikusabb megoldása az állományok teljes elk ülönítése. Itt nem az OR számára elkülönített területek felhasználására gondolunk, hanem arra, hogy a felhasználók által használható közös memóriában hogyan lehet információt szeparálni. Így rögtön látszik, hogy a kérdés megoldása nem egyszerű. Az egyik leggyakrabban használt megoldást a virtuális gépeknél alkalmazzák. Ekkor a virtuális gépet úgy szervezik, hogy a gép különböző szintjeihez biztosítanak más-más hozzáférési lehetőséget, és az információkat ezekre a szintekre helyezik el attól függően, hogy kinek kívánnak hozzáférést biztosítani. A fenti elkülönítésnél sokkal kifinomultabb az az eljárás, amelyet pl. a UNIX

rendszer nyújt az olvasási, írási és végrehajtási engedélyezettség bizosításával külön a felhasználókra, arra a felhasználói munkacsoportra, amelybe a felhasználó tartozik és az egyéb felhasználókra is. Ez a fajta hozzáférési engedélyezettség, azonbann bonyolultab adatbázisoknál vagy nagyobb fejlesztéseknél nem eléggé ”árnyalt”. A hozzáférési m átrixok segítségével ki lehet jelölni engedélyezettségi célokat (objects) és területeket (domains). Az előbbi csoportba tartoznak azok a fizikai és logikai erőforrások, amelyeken az engedélyezettséget végre akarjuk hajtani (CPU, memória, mágneslemez ill. progamok, állományok), az utóbbiba pedig azokat a program egységeket, idő intervallumokat sorolhatjuk be, amelyekben a kívánt 146 hozzáférési módot érvényesíteni kívánjuk. Ezek segítségével egy mátrixot állíthatunk össze, amelynek soraiban az engedélyezettség céljait, oszlopaiban a területeket

ábrázoljuk, az elemek pedig a engedélyezettség típusát mutatják. Egy ilyen mátrixot mutat a 13.2 Ábra Eszköz No. 1 Eszköz No 2 Eszköz No3 Mágneslemez Read Tranzakciók Felhasználó No.1 Write Read, Write Végrehajt Read Write 13.2 Ábra Engedélyezettségi mátrix 13.32 Kommunikációs adatvédelem Amennyiban az adatok feldolgozása során szükség van arra, hogy azokat hálózatban továbbítsuk két számítógép között, akkor az adatok védelme nem ér véget a rendszeren belüli védelmnél. Ez a megállapítás annyira igaz, hogy abban az esetben, ha az adatok átvitele nem kódolt formában történne, akkor ”útközben” nagyon könnyen hozzáférhetőek lennének. Ezért az információs csatornákon küldött üzeneteket csaknem mindig kódolják. Az alkalmazott kódolási eljárás megválasztásánál figyelembe kell venni azt, hogy az elkódolt adatokat vissza kell tudni alakítani., azaz dekódolhatónak kell lenni. A visszaalakítás során

bizonyos adatoknál megengedhető bizonyos információ vesztés (pl. egy kép esetében), míg más esetekben teljesen vissza kell kapnunk a kódolás előtti információkat. Ezeknek az eljárásoknak a vizsgálata kívül esik e jegyzet témakörén, de az érdeklődő olvasóknak ajánljuk XYZ (1999)-ben megjelent könyvét, amelyben a szerző részletesen foglalkozik a kódoláselmélet fenti problémáival. 13.33 Külső védelem A számítógépekben őrzött, feldolgozott adatokat időnként külső mágneses adathordozóra másoljuk. Ennek eltérő okai lehetnek: elképzelhető, hogy így akarjuk továbbítani az információt egy másik rendszerbe, de az is lehet, hogy egyszerűen csak meg akarjuk őrizni azokat arra az esetre, ha a rendszeren belüli informácókat valamilyen sérülés érné. A külső adathordozókon tárolt adatok védelméről kétféle módon is kell gondoskodni: egyrészt fizikai védelm et kell nyújtani a külső hatások ellen, ami keiterjedhet a

folyadékokra, tűzre és mindenféle egyéb szennyeződésre is. Ezek többnyire kivül esnek az OR hatáskörén. A műveletekre vonatkozó védelemről elsősorban a teljes ad atmentés (backup) során beszélhetünk. Egy backup eljárásaal szemben a következő elvárásaink lehetnek: • A létrehozott backupnak könnyen azonosíthatónak kell elnni. 147 • A másolatok egymás utáni generációit rotációs eljárással kell adathordozóra rögzíteni. • Programokat és az OR-t minden változtatás után meg kell őrizni. • A backupon található állományoknak könnyen azonosíthatóknak kell lenni. • Lehetőséget kell biztosítani arra, hogy csak a backup egy részét töltsük vissza. A backup alkalmazásának egyik kulcsfontosságú része az, hogy mennyi ideig tart a mentési eljárás. Ha túl nehézkes és/vagy nagyon hosszú ideig tart, akkor a felhasználók vagy az operátor nem fogja végrehajtani a rendszeres mentést abban a reményben, hogy arra nem

lesz szükség. A leggyakrabban ez a probléma a mikroszámítógépes környezetben jelentkezik, amikor nagykapacitású mágneslemezek tartalmát kell floppy lemezekre menteni. Ilyenkor szoktak tömörítő eljárásokat alkalmazni a mentés előtt MS-DOS környezetben jól ismert tömörítő eljárások az ARJ és ZIP/UNZIP programok. 13.34 Jogi védelem A fejezet végén néhány szót kell szólni a jogi védelemről, amely ugyan nem tartozik szorosan az OR hatáskörébe, mégis beszélni kell róla, mert a jogi védelem nyújtja azokat a kereteket, amelyeket az OR tervezése során figyelembe kell venni. Ezeknek a törvényeknek, rendeleteknek egy része az adatok titkosságára, más része a különböző softwarek védelmére vonatkozik. Itt hívjuk fel az olvasó figyelmét arra a tényre, hogy a Magyar Köztársaságban 1993 szeptemberétől szerzői jogok védik a különböző software termékeket (köztük az OR-ket is.), tehát illegális másolásuk és

felhasználásuk törvénybe ütközik 148 14. Rendszer kezelés, rendszer könyvelés Rendszer kezeléséről és adminisztrációról mind egy- mind pedig többfelhasználós környezetben beszélhetünk. Ez magában foglalja • • • • • az OR generálását egy rendelkezésre álló hardware konfigurácó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 (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. E feladatok egy részét esetlegesen kell végrehajtani, másokat pedig rendszeresen ismétlünk. Ebben a fejezetben ezekkel a feladatokkal fogunk foglalkozni részletesebben 14.1 Rendszer generálás Az OR egyik fontos feladata 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ás mindig attól függ, hogy az OR-nek mely részei változtathatók. Ennek megfelelően az első feladat egy rendszer generálása során annak a megvizsgálása, hogy mely képességeket, tulajdonságokat és támogatási módokat lehet változtatni az installálandó OR-en belül. Néhány ilyen szempontot felsorolunk: 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 maximális száma Készülékek maximális száma Alkalmazni kívánt karakter kód típusa A swap/paging készülék azonosítója 149 14.11 A telepítés típusai Amikor rendszert generálunk, akkor az elkészült OR vagy forrásnyelvi- vagy már lefordított formában áll rendelkezésünkre Ettől függően a rendszer

telepítésére különböző módszerek állnak rendelkezésünkre: A. Ha a rendszer forrásnyelven áll rendelkezésre, akkor szükségünk van egy fordító programra.(Ez az esetek többségében egy assembler) Ennek a fordítóprogramnak a segítségével le kell fordítani a forrásmodulokat úgy, hogy a fordítás közben paraméterek, konstansok formájában adjuk meg a fenti táblázatban bemutatott rendszerparamétereket. Természetesen a lefordított modulokat szerkeszteni kell Az így előállított OR pontosan a kívánt paramátereket tartalmazza. Ebben van a módszer legnagyobb előnye. A hátránya az, hogy az OR generálása nagyon hoszzú ideig tarthat, hiszen minden forrásnyelvi programot le kell fordítani. B. Ha az OR-t leíró táblázatok valamilyen formában rendelkezésünkre állnak, akkor elkerülhetjük a fordítást. Ilyenkor a rendszer specifikumokat leíró paraméterek táblázatban tároljuk, és ezeket egy szerkesztési lépésben kell a már

lefordítottan rendelkezésre álló többi modulhoz kapcsolni. Ennek az a következménye, hogy a telepítési idő alaposan lecsökken, azonban romlik a rendszer alkalmazkodó képessége is. C. Az előző pontban leírt módszer tovább finomítható azáltal, hogy dinamikus konfigurálási lehetőséget biztosítunk a telepítéshez. Ennek a lényege abban áll, hogy a rendszerhez kapcsolódó készülékek paramétereit egy készülék táblában írjuk le, de a készülék meghajtókat csak akkor kapcsoljuk a rendszerhez, ha a készülék ténylegesen rendelkezésünkre áll. Így maga a rendszer is két komponensből épül fel: lesz egy ”alaprendszer”, és ehhez kapcsolódnak a különböző meghajtó modulok. Ez utóbbi módszert alkalmazzák kis gépek esetében is .(pl MS-DOS) 14.12 A telepítés módszerei Az esetek legnagyobb részében az OR-ket úgy szállítják, hogy leválasztanak róla egy un. betölthető változatot, amely lényegében független a

hardware-től (Ez nem teljesen így van, hiszen az architektura és a CPU alapvetően meghatározza a futtatható modult, de itt arra gondolunk, hogy a betöltéshez a megadunk egy minimális konfigurációt az adott CPU mellet.) Ha ezt az un ”startup” OR-t betöltjük, akkor ennek segítségével felépíthetjük az OR-t. Ez az eljárás kétféleképpen történhet: batch üzemmódban és interaktívan. A következőkben ezeket a módszereket vizsgáljuk A. Batch eljárás esetében az OR rendelkezik valamilyen kommunikációs lehetőséggel (nyelvvel), amelyet a telepítése során használ. Mivel a feldolgozásra nincsenek általános szabályok, ezért a szemléletesség kedvéért egy gyakorlati példán (a UNIX rendszeren) mutatjuk be az ilyen módszerrel történő rendszer generálást. 150 A rendszer betöltése egy un. config program indításával kezdődik Ahhoz, hogy a konfigurálás megtörténhessen alapinformációkra van szükség, amelyeket a program egy

konfigurációs állományból fog kiovasni. Ez az állomány a kezdetben üres, és a config program egy egyszerű nyelvet használ a kitöltéséhez. A következő táblázat azokat a minimális információkat mutatja, amellyel a programnak rendelkeznie kell a telepítés során: Gép típusa Rendszer azonosító Felhasználók max. száma Rendelkezésre álló hardware CPU típusa Időzóna Root file rendszer helye Érdekesség az, hogy egy editor használatával lehetőség van arra, hogy módosításokat hajtsunk végre a konfigurációs állományban. A rendszer felépítése során a következő lépéseket kell végrehajtani (Leffler , Joy [1983]): • Állítsunk elő a konfigurációs állományt. • Állítsunk elő egy könyvtárat, amelyben a rendszert generálni akarjuk. • Futtasuk a config programot azoknak az állományoknak a generálásához, amelyek a rendszer aktuális változatának fordításához és betöltéséhez szükségesek. • Konstruáljuk meg a

konfigurált rendszerhez tartozó forráskód ”függőségi szabályait”. • Fordítsuk le és töltsük be a rendszert. A config program futtatásakor két lehetőségünk van: • Specifikálhatunk olyan készülékeket, amelyek nincsenek pillanatnyilag a rendszerben, de a közeljövőben lehetőséget akarunk biztosítani az installálásukhoz anélkül, hogy újra kellene telepíteni a UNIX-ot., • Egy un. autokonfugurációs lépést hajt végre a program, és csak azokat a meghajtókat tölti be, amelyekhez tartozó készülékek jelen vannak a config program futtatásakor. B. In teraktí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. (Ez többnyire yes/no, készülék szám, egy adott cím stb) A megadott válaszok függvényében az OR egy batch állományt generál, amely még a fordítás előtt korlátozott keretek között szerkeszthető egy

interaktív editor segítségével. Mivel e batch állomány készítése többnyire menüvezérelt módon történik, ezért ennek a módszernek az az előnye, hogy azok a felhasználók is telepíteni tudják a rendszert, akik nem járatosak az ilyen munkákban. Jó példa az interaktív telepítésre a DEC számítógépen telepíthető RT-11 OR. 151 14.2 Rendszer betöltés Miként arra már utaltunk, a rendszer telepítéséhez szükségünk van egy kisméretű, futtatható formában rendelkezésre álló programra, amelyet a memória valamilyen fix helyére betölthetünk. A mai rendszerekben általában un mag-memóriát (core-memory) használnak, amelynek az a lényege, hogy a betöltött program a memóriában marad akkor is, ha a gépet közben kikapcsolják. Az egyik jellemző ilyen memória a mikroszámítógépeknél alkalmazott ROM memória. Amint az OR-t betöltöttük bizonyos kézenfekvő kezdeti beállításokra azonnal szükség van: ellenőrizni kell a

memóriát a készülékeket, esetenként át kell helyezni az OR-t a memória meghatározott helyére, be kell állítani a megszakításokat, be kell tölteni a készülék meghajtókat, a beindított folyamatokhoz be kell állítani a PCB-ket és végül át kell adni a vezérlést a folyamat ütemezőnek, amely behozza az első indítandó programot. Magának az OR-nek kétféle indítási módja ismert: a kis rendszerek mindig un. hideg start segítségével indulnak. Ilyenkor az OR ”elfelejt” mindent, 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. Az indítás másik módja az un meleg start , amelynek során a rendszer felhasználja azokat az információkat, amelyeket a korábbi állapotokból megőrzött. Az információ megőrzésére a rendszerek az ellenőrző pontokat (checkpoint) használják. E technika alkalmazásakor a rendszer egy program feldolgozása során egy-egy kijelölt ponton rekordot

készít, amelyben a rendszer fontosabb állapotait eltárolja, és meleg indításkor ezek segítségével építi fel a rendszert. BREAK=OFF BUFFERS=8 FILES=11 DEVICE=C:VDISK.SYS 512/E LASTDRIVE=D SHELL=C:SHELL1.COM 14.1Ábra Egy MS-DOS rendszerhez tartozó CONFIGSYS állomány A rendszer betöltés következő fontos fázisa az önkonfiguráció. Ennek során a rendszer bizonyos paramétereket a rendelkezésre álló erőforrások függvényében olyan módon jelöl ki, amelyek a később betöltendő programok hatékonyabb futtatását eredményezik. Jó példa erre az MS-DOS esetében alkalmazott CONFIGSYS állomány, amely megmondja az OR-nek, hogy mely készülékeket kell felismernie (DEVICE), hány darab mágneslemez puffert használhat (BUFFER), hány darab állomány lehet egyidőben nyitva (FILES), milyen nyelvet kívánunk használni a 152 kommunikáció során (COUNTRY) stb. Egy tipikus CONFIGSYS állományt mutat be a 14.1 Ábra A rendszer inicializálás során a

következő fontos feladat annak ellenőrzése, hogy a a rendszerhez tertozó file rendszer rendben van-e. Az egyszerűbb rendszerek mint az MS-DOS nem rendelkeznek automatikus ellenőrző képességgel, de itt is rendelkezésre áll egy olyan program, amely átvizsgálja a mágneslemezt, és a lerombolt clustereket megpróbálja ismét a rendszerhez kapcsolni. A bonyolultabb, többfelhasználós rendszerek esetében az abnormális rendszer leállás sokkal nagyobb problémákat okozhat, ezért a file rendszer ellenőrzésére ezeknél a rendszereknél sokkal nagyobb hangsúlyt fektetnek. (A lost+found állományok létrehozásáról már korábban is beszéltünk). Az állományok ellenőrzése a rendszer indítási diagnosztika fontos de nem egyetlen alkotóeleme: ennek során ellenőrzik a rendszerek a különböző hardware elemeket, az állományok felépítését és végrehajtanak minden olyan ellenőrzést, amely ahhoz szükséges, hogy az OR hiba nélkül működni tudjon

a későbbiek során. 14.3 Rendszer leá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 hajtunk végre. Ezért van az, hogy számos OR figyelmezteti a rendszerben dolgozó összes felhasználót arra, hogy a rendszer adminsztrátor által kiadott shutdown parancs végrehajtásának megkezdése előtt lépjen ki a rendszerből (logoff). Amikor a rendszert újra indítjuk, akkor az OR-nek rendelkeznie kell azzal a képességgel, hogy átvizsgálja a file rendszert, és utasítja a rendszeradminisztrátort a hibák kijavítására, amennyiben az megtehető. Ha a hiba nem elhárítható, akkor magának az OR-nek kell olyan ”tisztogatást” végrehajtania,

amelynel eredményeként a rendszer ismét működőképes lesz. Vizsgáljuk meg azt, hogy mi történik a rendszerben szabályos ill. nem szabályos leállás esetén 14.31 Szabályos leállítás A rendszerekben a shutdown eljárás úgy hajtódik végre, hogy a rendszeradminisztrátornak vagy az operátornak követnie kell a rendszer üzeneteket. Ha a rendszerben levő felhasználók figyelmeztetést kapnak a leépítésről, akkor idejében ki tudnak lépni az éppen futó programjaikból, le tudják zárni a rekordokat, egy szóval el tudják végezni a saját munkájukkal kapcsolatos feladataikat. Ha a felhasználókat nem figyelmeztetjük, akkor előfordulhat, hogy a rendszer egyes állományokat nem tud szabályosan a rendszerhez kapcsolni, ami problémákat okozhat 153 a rendszer újraindításakor. Ez ellen az OR úgy ”védekezik”, hogy egy lost+found könyvtárban helyezi el azokat az állományokat, amelyek fizikailag megtalálhatók a rendszerben, de nem

történik rájuk hivatkozás. Itt kell még egyszer megjegyeznünk, hogy nagyobb rendszerek esetében feltétlen indokolt a szünetmentes táp egységek (UPS) alkalmazása, mert ezek áramkimaradás esetén biztosítják a lehetőséget a szabályos rendszerleépítés számára. 14.32 Nem szabályos leállás Az áramkimaradás esetéről már korábban is szóltunk. Előfordulhatnak persze más leállások is. Gondoljunk például arra, amikor végrehajtás közben rendszer állományokat nem tud az OR elérni, ezáltal nem képes a feladatát folytatni. Ilyenkor a a legtöbbször képes arra, hogy hibakezelő eljárások beindításával adatokat és programokat mentsen, és felkészüljön a szabályos rendszerleépítésre. Ha körültekintően jár el, akkor másolatot készít (system dump) az aktuális állapotról egy háttértárra azért, hogy később a hiba oka kideríthető legyen. Természetesen mindig előfordulhatnak olyan hibák, amikor a hibakezelő eljárások

nem hívhatók meg. Ilyenkor a hiba elhárítása teljes egészében a rendszer adminisztrátorra, ill. az operátorra marad 14.4 Rendszer tuningolá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. (Ha valaki úgy ítéli meg, hogy egy alkalmazói programcsomag a rendszerén túl lassan fut annak ellenére, hogy minden erőforrás a rendelkezésre áll, akkor többnyire a gyorsabb CPU megvásárlása a megoldás.) 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. Ilyenkor célszerű megvizsgálni, hogy mit is csinál a rendszer valójában, hol van ”szűk keresztmetszeti” probléma. Amikor a rendszer hatékonyságát akarjuk megnövelni, akkor tunningolásról beszélünk. Ezt a legkülönbözőbb célok

érdekében végezhetjük el. Az alábbiakban felsorolunk néhány olyan okot, amely lelassíthatja a rendszert Ezek vizsgálata tehát feltétlen indokolt, ha a hatékonyságot nem találjuk megfelelőnek. • CPU kihasználtság. • Készülék kihasználtság (Itt minden erőforrásra elvégezhetjük a vizsgálatot). • Átfordulási idő (batch környezetben mennyi idő telik el a job elküldése és az output visszakapása között). • Válasz idő interaktív környezetben. • Várakozási idő különböző készülékekre. • I/O készülékek kezelése. 154 • Lapozás kezelése. • Process ütemezés. 14.5 Rendszer kö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. Amikor rendszer elszámolásról beszélünk, akkor két alapvető feladatot kell megoldanunk: • Információkat kell tárolnunk arról, hogy egyes felhasználók a rendszer

erőforrásait milyen mértékben veszik igénybe. • Mennyiségi korlátokat kell felállítanunk arra, hogy az egyes erőforrásokat mely felhasználók meddig vehetik igénybe. Az első feladatot user accoun tok felállításával segíthetjük. Ennek az a lényege, hogy a felhasználókhoz egy azonosítót (ID) rendelünk, amelyet a rendszer arra használ, hogy az egyes erőforrások használatakor a felhasználói ID-hez hozzárendeli az igénybevételt. Egy későbbi időpontban egy számlázó program feldolgozza ezeket a bejegyzéseket. A mennyiségi korlátok felállítása is fontos feladata az OR-nek. Többfelhasználós rendszereknél nem engedhető meg, hogy a felhasználók minden kötöttség nélkül vehessék igénybe az erőforrásokat. Ezért a felhasználókat kategóriákba sorolják, és ennek megfelelően kaphatnak lehetőséget az erőforrások igénybe vételére. Tipikusan korlátozható területek: • • • • • Felhasználható mágneslemez terület.

CPU idő igénybevétel jobonként. I/O műveletek maximális száma. Nyomtatható sorok maximális száma Futtaható jobok maximális száma. Az OR-nek biztosítania kell azt, hogy a rendszer adminisztrátor könnyen hozzáférhessen a user account-hoz, jól fel tudja az adatokat dolgozni. Ezért a jól felszerelt OR-k a rendszerprogramok egész sorával rendelkeznek az ilyen típusú feladatok megsegítésére. 155 15.Osztott Operációs Rendszerek Az eddigiek során azt feltételeztük, hogy a klasszikus felépítésű számítógépes architektura áll a rendelkezésünkre. Egy ilyen környezetben az OR-k kapacitása elsősorban úgy növelhető, hogy az egyes hardware komponensek kapacitásást növeljük meg. (Új perifériát adunk a rendszerhez, megnöveljük a központi tárat, gyorsabb központi vezérlő egységet alkalmazunk stb.) Központi vezérlő egység Bemenő Egység Kimenő Egység Operatív memória Aritmetikai Egység Háttértárolók 15.1 Ábra

Klasszikus számítógép architektura Az elemzések során láttuk, hogy a számítógépek kapacitásának talán legszűkebb keresztmetszete a közponi vezérlő egység. Így eléggé kézenfekvő az a gondolat, hogy használjunk több processzort annak érdekében, hogy a rendszer hatékonyságát megnöveljük. Kezdetben csak két processzort használtak, és a jelentkező számos újtípusú probléma ellenére a hatékonyság növekedés olyan mértékű volt, hogy a többprocesszoros rendszerek igen gyorsan terjedni kezdtek. Ma amikor egyetlen nagy bonyolultságú VLSI chipbe elhelyezhető egy processzor számos olyan többprocesszoros rendszert ismerünk, amelyben CPU-k tucatjai dolgoznak együtt. Az új architekturában felmerülő problémák egy részét az okozza, hogy egyrészt ezek a processzorok a legkülönbözőbb módon kapcsolhatók össze, másrészt pedig a hatékonyság növelése érdekében a processzorok által elvégezhető műveletek számát sok

esetben erősen korlátozzák. (Azt már csak zárójelben jegyezzük meg, hogy sokszor speciális algoritmusokra van szükség ahhoz, hogy a többprocessoros rendszereket hatékonyan tudjuk működtetni. Mivel ezek vizsgálata kívül esik a jegyzet témakörén, az érdeklődő olvasó figyelmébe ajánljuk Liu [1987] könyvét a párhuzamos gépek strukturájáról. és az ezeken jól futtatható párhuzamos algoritmusokról) A processzorok összekapcsolásának egyik lehetséges módja az, hogy független egyprocesszoros számítógépes rendszereket kötünk össze. Ezek a kapcsolatok 156 lehetőséget biztosítanak ahhoz, hogy a gépek megosszák az információkat egymással. 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 = Local Area Network), amikor a gépek legfeljebb néhány száz méterre fekszenek egymástól, és nagy

távolságú (WAN = Wide Area Network) hálózatokról, amelyek akár az egész Földet is behálózhatják. A LAN-ok esetében a hálózat elemei nagyteljesítményű ennek megfelelően igen drága kábelekkel (pl. üvegszál) vannak összekötve, amelyek a gyors és megbízható adatátvitelt biztosítják. Az adatátvitel sebessége a modern rendszereken eléri az 10-20 Mbit/sec.-ot is Nagyobb távolságra ilyen sebességgel adatokat továbbítani rendkívül költséges. Ezeknél a hálózatoknál az elérhető sebesség néhány Mbit/sec. 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, vagy folyamatok egy részhalmazáért. A folyamatok a végrehajtás alatt hivatkozhatnak más processzorokra is. Bizonyos esetekben olyan erőforrásokat is igényelhetnek, amelyek más gépekhez tartoznak vagy éppenséggel (multiprocesszoros környezetben) minden processzor számára elérhetők.

Ha bizonyos tevékenységek felügyeletét meg kell osztanunk processzorok egy csoportja között, akkor 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 (DCS = Distributed Computing System) nevezzük. A fentiekben bemutatott rendszerek mindegyike tekinthető osztott rendszernek, de mivel teljesen eltérő felépítésűek, ezért más-más célokra használhatók és különböző problémák megoldására alkalmasak. Érdemes megjegyezni, hogy a hálózatok esetében egyáltalán nem biztos, hogy a hálózat minden egyes gépe egy adott időpillanatban az osztott számítógépes rendszerhez tartozik: csak azokat tekintjük mindig a rendszer részének, amelyek közös feladatokat hajtanak végre, és amelyek közösen felügyelnek futó folyamatokat. A hálózat többi része egyedi feladatokat lát el ilyenkor, és esetleg egy későbbi időpontban csatlakozik a rendszerhez. Mivel az osztott

számítógépes rendszer közös feladatokat lát el, és közös folyamatokat kell kezelnie, ezért kézenfekvő az, hogy egy egységes mechanizmus kezelje a munkáját. A források kezelésére olyan OR kell, amely össze tudja hangolni az egyes gépeken rendelkezésre álló erőforrásokat. Azt az OR-t, amely az ilyen munkát el tudja látni Osztott Operációs Rendszernek (Distributed Operating System) nevezzük. Egy ilyen rendszert különböző módon lehet telepíteni: vagy a ”klasszikus” OR fölé helyezzük el egy magasabb szinten vagy egy egységes rendszert alakítunk ki, amely együttesen kezeli a rendszerben lévő összes processzort. Ha osztott számítógépes rendszert akarunk felépíteni, akkor azt különböző előnyök elérésére akarjuk felhasználni. Ezek a következők lehetnek: • Humán kommunikációra alkalmas rendszert tudunk kifejleszteni, amelyben az egyes felhasználók kényelmesen tudnak üzeneteket váltani egymással elektromos levelezési

rendszerek (email) segítségével. • Erőforrások megosztását tudjuk elérni oly módon, hogy a különböző helyszineken rendelkezésre álló erőforrásokat át tudjuk csoportosítani egymás között. Ez 157 vonatkozhat a fizikai erőforrások mellett a rendszerben lévő logakai erőforrásokra (adatbázisok, rendszer programok) is. • Növelhetjük a rendszer megbízhatóságát azáltal, hogy a több processzor mellet az egyes hardware elemekből is több áll a rendelkezésünkre, ami biztosíthatja a számunkra azt, hogy egy-egy elem meghibásodása esetén a rendszerben futó programok továbbra is hiba nélkül befejeződhetnek. • 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. A fenti célok mindegyike körültekintő szervezéssel elérhető. Az

természetes, hogy a megvalósítás során újabb problémákkal találkozhatunk. Ilyen például az, hogy ha a kiegyensúlyozott terhelés érdekében át akarunk irányítani programot az egyik helyszínről a másikra, akkor figyelembe kell venni az átviteli költségeket és az esetleges kősőbbi információcsere költségeit is. Mivel a jellemzők a többprocesszoros rendszernél és a hálózatoknál eltérnek egymástól, ezért külön fogjuk tárgyalni azokat az OR-eket, amelyeket ezeknél a renszereknél használunk. 15.1 OR-k többprocesszoros környezetben Többprocesszoros környezetben a számítógépes rendszerhez kettő vagy ennél több CPU tartozik. A rendszerben elhelyezkedő memória egységek különböző módon kapcsolódhatnak a processzorokhoz: vagy kizárólagos alapon egy memória egységet egy processzorhoz rendeljük hozzá, vagy a memória egységet megosztjuk a processzorok között. Az első eset technikailag könnyen kezelhető, de költséges A

második esetben előfordulhat, hogy a memóriát olyan folyamatok között kell felosztani, amelyek más-más processzorokhoz tartoznak. Ezért a többprocesszoros folyamatok speciális kommunikációs lehetőségei az alábbial: • kapcsolattartás az osztott memóriákkal, • üzenetek továbbítása, • az első két lehetőség kombinációja. Mivel a kommunikáció mindkét esetben a rendszeren belül zajlik le, ezért viszonylag alacsony költségű. Az ilyen rendszerek egyik legnagyobb problémája az egyenletes terhelés biztosítása az egyes CPU-k számára, de azok a módszerek, amelyek ennek a problémának a megoldásához vezetnek már nem tartoznak e jegyzet hatáskörébe. 15.2 OR-k hálózatokon 158 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 azon üzeneteket vagy adatokat továbbítsunk. A számítógépek mellett a hálózatba integrálhatunk

terminálokat, nyomtatókat és más egyéb készülékeket is. (Azt azonban megjegyezzük, hogy ha egy számítógéphez csak távoli terminálok és nyomtatók vannak kapcsolva, akkor azt nem tekintjük hálózatnak.) A hálózatnak 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 meglevő OR ”fölé”. Ezt a rendszert szokásos hálózati OR-nek (NOS = Network Operating System) nevezni. • Osztott OR-t istallálunk a hálózat minden gépen. Ez az un osztott OR (Distributed OS). A többprocesszoros rendszerekkel szemben itt a fő kérdés az, hogy miképpen tudjuk biztosítani kommunikácós helyszínek között a megbízható és gyors adatátvitelt. Ezért az esetek többségében az egyszerű fizikai összeköttetés a számítógépek között még nem

fog hálózatot eredményezni: szinte mindig szükség van arra, hogy a meglevő hardware elemek hatásfokát software elemek alkalmazásával javítsuk. Néhány hálózat esetében (pl. Ethernet LAN) a hálózat minden helyszínén viszonylag drága hardware elemeket használnak, és a fizikai összeköttetést biztosító kábel is nagysebességű adattranszfert enged meg (1-2 Mbit/sec). Más hálózatok a software elemekre helyezik a fő hangsúlyt. Az ilyen rendszereknél az adatátvitel másodpercenkénti sebessége alig haladja meg a néhány száz bitet. Az utóbbi rendszer előnye az, hogy mindig sokkal olcsóbban installálható Ha a hálózatban hosszabb üzeneteket továbbítunk, akkor azokat csomagokra bontjuk. A hálózatban ezek a csomagokat önálló egységként kezeljük Az érdekesség az, hogy az nincs biztosítva, hogy az egymás után elküldött csomagok a célhelyszínre ugyanabban a sorrendben érkeznek meg. A helyes sorrend megállapítása, és az üzenetek

”összerakása” mindig a célállomáson installált OR feladata. Ha a csomagok sorrendje megváltozhat a hálózatban, akkor az csak úgy lehet, hogy a különböző helyszínek nem közvetlenül vannak összekötve, hanem közbülső állomásokon jut el az üzenet a célállomásra. Ez felveti azt a kérdést, hogy miként kell a hálózat helyszíneit összekötni, azaz milyennek kell lenni a hálózat topológiájának? Az világos, hogy a hálózatnak összefüggőnek kell lenni, de az összekötés módja nagyon keltérő lehet. A 152 Ábra néhány jellegzetes összekötési módot mutat be A topológiák bemutatásából jól látszik, hogy egyes hálózati típusoknál két helyszín között különböző útvonalakon juthat el a továbbítandó csomag. Ez felveti azt a problémát, hogy melyik útvonalat válasszuk egy üzenet továbbításához? Az első gondolat az, hogy érdemes a legrövidebb utat választani. Valóban, számos OR az adatcsomag elküldése előtt a

rendszer topológiájának ismeretében kikeresi a szóban forgó ítvonalat, és ezen továbbítja a csomagot a célhelyszínre. De ez nem mindig lehetséges, hiszen előfordulhat, hogy valamely közbülső helyszín annyira 159 túlterhelt, hogy ”elakad” az üzenet. Ezért némely hálózati rendszer úgy dolgozik, hogy a csomagok küldése előtt kiépít egy virtuális útvonalat, amelyen aztán elsőbbséget biztosítva a hálózati forgalomnak lebonyolítja az adattranszfert. Az adatkommunikáció kapcsán felmerülő problémák megoldására hoztak létre az ISO szabvány keretén belül 1983-ban egy nemzetközi standardot ( OSI = Open Systems Interconnection Model) , amely az adatkommunikációt hét szintre osztja. Minden osztott OR-nek szükségképpen tartalmaznia kell a négy legalsó szintet: Sugaras összekötés Gyűrűs összekötés Teljes összekötés 15.2 Ábra Hálózati topológiák • FIZIKAI SZINT: az elektronikus és a fizikai összeköttetést

alapozza meg ahhoz, hogy az átvitel végrehajtható legyen. • ADATÖSSZEKÖTTETÉSI SZINT: az adatok csomagokba. Általában hibakezelővel van ellátva különálló bitjeit szervezi • HÁLÓZATI SZINT: A csomagok számára biztosítja a célállomáshoz vezető utat. • ÁTVITELI SZINT: A kimenő üzeneteket csomagokba szervezi, és feldolgozza a bejövő adatokat. Érzékeli és kezeli a csomagokban előforduló hibákat, intézkedik a visszaküldésről, ha szükséges, és sorbarendezi a bejövő csomagokat. Tekintettel arra, hogy az OSI további szintjei inkább a felhasználó kényelmét szolgálják, és esetenként csak speciális alkalmazásoknál használatosak, már nem kötelezően előírtak a hálózati rendszereknél. Ezek a következők: • BEJELENTKEZÉSI SZINT: A kommunikációs helyszíneken jelen levő aktív felhasználók ill. folyamatok közötti logikai kapcsolatot biztosítja 160 • ÁTADÁSI SZINT: A helyszínek közott továbbítandó

adatok szemantikáját kezeli. Gondoskodik az adatok összenyomásáról és visszaalakításáról, ha arra szükség van. • APPLIKÁCIÓS SZINT: Specifikus felhasználói programok esetén gondoskodik a megfelelő hálózati interfacekről. A fejezet végén szólni kell még egy problémáról, amely fontos szempont a hálózaton dolgozó felhasználók kényelme miatt. Az a felhasználó, aki hálózatban dolgozik, a legtöbbször tökéletesen tisztában van a hálózat topológiájával, és a rendelkezésre álló erőforrásokkal, sőt az esetek nagy részében az ezekből származó előnyöket ki is akarja használni. Ezért fontos szabályaz, hogy a hálózat átjárhatóságát biztosítani kell. A tökéletesen átjárható rendszerekben a felhasználónak nincs tudomása arról, hogy egyes állományai melyik helyszínen tárolódnak, és azt sem tudja, hogy az OR melyik helyszínen futtatja a programját. Az OR a szükséges erőforrásokat különböző helyszíneken

veheti igénybe, és azokat váltogathatja attól függően, hogy a leterhelés milyen fokú. A teljes átjárhatóságnak azonban meg van a maga veszélye is: Jelentősen megnövekszik az az üzenetforgalom, amelyet az OR generál, amely a rendszer hatékonyságának csökkenéséhez vezet. Fontos megjegyezni azt is, hogy a konvencionális OR-k fölé telepített hálózati ORk esetében az átjárhatóság nem biztosított. 15.3 Osztott OR-k 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 OR egy helyszínen egy memóriában helyezkedik el. • OSZTOTT: Az OR-t részekre bontjuk, és az egyes részeketkülönböző helyszíneken tároljuk. • MÁSOLATOS: AZ OR teljes egészét vagy annak csak egy részét egy-egy példányban több helyszínen tároljuk. Többprocesszoros környezetben

vetődik fel az a kérdés, hogy melyik processzoron kell futni a folyamatnak? Az ilyen rendszerek nagy része az un. master-slave megközelítést alkalmazza. Ennek az a lényege, hogy van egy kitüntetett CPU (ez a master), amelyen az OS dolgozik. A többit tartalékként kezeli a rendszer, erőforrásnak tekinti, amelyet szükség esetén felhasználhat. Jellemző példa erre a SUN többprocesszoros rendszere. A többfelhasználós rendszerek következő kérdése a ”Hol tároljam?”. Azt mindenekelőtt le kell szögezni, hogy ez a kérdés csak átjárható rendszereknél vetődik 161 fel. A korábbiakban láttuk, hogy a tárolás a konvencionális OR-knél file rendszerekben történik. Ez így van az osztott rendszereknél is, csak most a fő feladat az, hogy egy olyan osztott file ren dszert (distributed file system) biztosítsunk a felhasználóknak, amely virtuális, egységes, és amelyben az állományok elérhetők anélkül, hogy hogy a felhasználó bármit tudna

annak elhelyezéséről. Ezért az OR megköveteli a felhasználótól, hogy olyan neveket adjon az állományának, amely független az elhelyezéstől (hiszen futásonként máshol helyezkedhetnek el az állományok). Az osztott file rendszerek másik jellemző tulajdonsága az, 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ő helyszineken. (Gondoljunk egy statisztikai programra, amely csak olvasásra használja a megnyitott állományokat.) 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 kiegy ensú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. 162 16. Utószó Amikor elhatároztam, hogy jegyzetet írok, már akkor is tisztában voltam vele, hogy nem törekedhetek teljességre, hiszen az OR-k annyira szerteágazóak és sokrétűek, hogy egy rövid jegyzet keretében erre vállalkozni nem lehet. Nem tudományos művet szerettem volna írni, hanem egy olyan összefoglalót, amely segíti az érdeklődő hallgatót eligazodni abban a ”rengetegben”, amelynek egy OR tünhet akkor, amikor tájékozatlanok vagyunk a vele kapcsolatos feladatokban, és még a kérdések

megfogalmazása is bizonytalan. A jegyzet írása közben vált még világosabbá, hogy mi mindent kell lerövidíteni vagy éppenséggel kihagyni. Ezt egyrészt terjedelmi okokból kellett megtenni, másrészt azért is, mert kiderült, hogy a fejlődés egy szakaszában fontos szerepet játszó elvek, elgondolások ma már idejét múltak, túlhaladottá váltak. Ugyanakkor az OR-k rohamos fejlődése miatt olyan új elvek nem kerülhettek a jegyzetbe, amelyekről ma már jól látszik, hogy fontos szerepet fognak betölteni a jövőben, de kiforratlanságuk okán nem foglalkozhattam ezekkel. Bízom benne, hogy a jegyzet használható arra, amire szántam: alapismereteket nyújtani az OR-k általános feladatairól, bemutatni azokat az általános elveket, amelyeket egy OR készítése során figyelembe kell venni, és amelyet egy számítástechnikát oktató tanárnak elengedhetetlenül tudnia kell ahhoz, hogy számítógépes ismereteit meg tudja alapozni. 163