Kondorosi Károly - Operációs rendszerek könyv

Országok listájaHungaryBudapesti Műszaki és Gazdaságtudományi EgyetemVillamosmérnöki és Informatikai KarMérnök informatikusOperációs RendszerekKönyvKondorosi Károly - Operációs rendszerek könyv

OPERÁCIÓS RENDSZEREK mérnöki megközelítésben ................................................................................ 1 I. EL SZÓ........................................................................................................................................................... 10 II. BEVEZETÉS.................................................................................................................................................. 11 II.1. MIT NEVEZÜNK OPERÁCIÓS RENDSZERNEK?.............................................................................................. 12 II.2. AZ OPERÁCIÓS RENDSZEREK TÖRTÉNETE .................................................................................................. 15 II.2.1. Korai rendszerek............................................................................................................................... 15 II.2.2. Batch rendszerek............................................................................................................................... 16 II.2.3. Multiprogramozott rendszerek.......................................................................................................... 20 II.2.4. Id osztásos rendszerek...................................................................................................................... 21 II.2.5. Személyi számítógépek ...................................................................................................................... 22 II.2.6. Elosztott rendszerek .......................................................................................................................... 23 II.2.7. Valósidej rendszerek ....................................................................................................................... 25 II.2.8. Nyílt rendszerek ................................................................................................................................ 26 II.2.9. Napjaink rendszerei .......................................................................................................................... 27 II.3. RENDSZERMODELL ÉS RENDSZERARCHITEKTÚRA ...................................................................................... 29 II.3.1. Az operációs rendszer és környezete................................................................................................. 29 II.3.2. Funkciók ........................................................................................................................................... 30 II.3.3. Csatlakozási felületek........................................................................................................................ 31
II.3.3.1. Kezel i (operátori) felület (Operator Interface, User Interface).................................................................. 31 II.3.3.2. Alkalmazási (programozói) felület (Application Interface, Program Interface).......................................... 34 II.3.3.3. Hardver felület (Hardware Interface) .......................................................................................................... 36

II.3.4. Számítógép-architektúrák ................................................................................................................. 38
II.3.4.1. Egyszer mikrogép ..................................................................................................................................... 39 II.3.4.2. Jellegzetes személyi számítógép ................................................................................................................. 40 II.3.4.3. Szuperszámítógép ....................................................................................................................................... 41

II.3.5. Bels szerkezet .................................................................................................................................. 42
II.3.5.1. Rétegek és modulok.................................................................................................................................... 43 II.3.5.2. Tipikus modulok ......................................................................................................................................... 45 II.3.5.3. Virtuális hardver ......................................................................................................................................... 46 II.3.5.4. Kliens-szerver szerkezet ............................................................................................................................. 48

II.3.6. M ködés............................................................................................................................................ 49
II.3.6.1. Rendszerhívások kezelése........................................................................................................................... 50 II.3.6.2. Be/kivitel végrehajtása................................................................................................................................ 52 II.3.6.3. Kezel i parancsok....................................................................................................................................... 55 II.3.6.4. Küls megszakítások kezelése .................................................................................................................... 57 II.3.6.5. Id mérés ..................................................................................................................................................... 57 II.3.6.6. Hibamegszakítások kezelése (kivételkezelés) ............................................................................................. 58 II.3.6.7. Rendszerindítás és leállás............................................................................................................................ 60

III. AZ OPERÁCIÓS RENDSZER, MINT ABSZTRAKT, VIRTUÁLIS GÉP............................................ 61 III.1. FOLYAMATOK ÉS SZÁLAK ........................................................................................................................ 61 III.2. FOLYAMATOKBÓL ÁLLÓ RENDSZEREK ..................................................................................................... 65 III.2.1. Folyamatok létrehozásának indokai ................................................................................................ 66 III.2.2. Független, verseng és együttm köd folyamatok .......................................................................... 67 III.2.3. Folyamatok születése és halála ....................................................................................................... 69 III.2.4. Folyamatok együttm ködése............................................................................................................ 70
III.2.4.1. Együttm ködés közös memórián............................................................................................................... 70 III.2.4.2. Együttm ködés üzenetváltással ................................................................................................................. 72

III.2.5. Folyamatok szinkronizációja ........................................................................................................... 73
III.2.5.1. Megoldások a PRAM modell keretei között (szoftver-megoldások) ......................................................... 75 III.2.5.2. A PRAM modell kiterjesztése ................................................................................................................... 79 III.2.5.3. Szinkronizációs eszközök az operációs rendszer szintjén.......................................................................... 81

III.2.6. Folyamatok kommunikációja........................................................................................................... 83
III.2.6.1. A partner megnevezése.............................................................................................................................. 84 III.2.6.2. Szemantikai konzisztencia......................................................................................................................... 87 III.2.6.3. Járulékos (implicit) szinkronizáció ............................................................................................................ 89

III.2.7. Holtpont........................................................................................................................................... 89

-2-

III.2.7.1. Mi a holtpont?............................................................................................................................................ 90 III.2.7.2. Holtpont er forrásokért verseng rendszerekben ...................................................................................... 92 III.2.7.3. A strucc algoritmus.................................................................................................................................... 95 III.2.7.4. A holtpont észlelése................................................................................................................................... 96 III.2.7.5. A holtpont feloldása................................................................................................................................. 100 III.2.7.6. A holtpont megel zése ............................................................................................................................ 101 III.2.7.7. A holtpont elkerülése............................................................................................................................... 103 III.2.7.8. Kombinált stratégiák................................................................................................................................ 108 III.2.7.9. Kommunikációs holtpontok..................................................................................................................... 109

III.2.8. Éhezés............................................................................................................................................ 110 III.2.9. Klasszikus konkurens problémák................................................................................................... 111
III.2.9.1. Termel - fogyasztó probléma ................................................................................................................. 111 III.2.9.2. Írók - olvasók problémája ........................................................................................................................ 112 III.2.9.3. Az étkez filozófusok problémája ........................................................................................................... 113 III.2.9.4. Adatfolyamok illesztése........................................................................................................................... 114

III.2.10. Folyamatokból álló rendszerek leírása nyelvi szinten ................................................................. 115
III.2.10.1. A párhuzamosság leírása ....................................................................................................................... 116 III.2.10.2. Az együttm ködés nyelvi modelljei ...................................................................................................... 118

III.3. TÁRAK.................................................................................................................................................... 121 III.3.1. Tárhierarchia ................................................................................................................................ 121 III.3.2. A logikai memória ......................................................................................................................... 123 III.3.3. A háttértár - fájlok ......................................................................................................................... 124
III.3.3.1. Fájlmodellek ............................................................................................................................................ 124 III.3.3.2. Fájlm veletek .......................................................................................................................................... 125

III.3.4. Tárak tulajdonságai....................................................................................................................... 127
III.3.4.1. M ködési sebesség .................................................................................................................................. 127 III.3.4.2. Címezhet adategység ............................................................................................................................. 127 III.3.4.3. Tárolási biztonság.................................................................................................................................... 127

III.4. KÉSZÜLÉKEK ÉS KÜLS KAPCSOLATOK .................................................................................................. 128 III.4.1. A küls eszközök f típusai ............................................................................................................ 128 III.4.2. Készülékmodell az alkalmazói felületen ........................................................................................ 130
III.4.2.1. Egyszer be/kivitel .................................................................................................................................. 131 III.4.2.2. Fájlm veletek .......................................................................................................................................... 132 III.4.2.3. Grafikus eszközök kezelése ..................................................................................................................... 133 III.4.2.4. Terminálkezelés....................................................................................................................................... 133 III.4.2.5. Hálózati kapcsolatok kezelése ................................................................................................................. 134

III.4.3. Készülékmodell a kezel i felületen ................................................................................................ 134 III.5. VÉDELEM ÉS BIZTONSÁG ........................................................................................................................ 135 III.5.1. Védelem ......................................................................................................................................... 135
III.5.1.1. Védelmi tartományok .............................................................................................................................. 135 III.5.1.2. Elérési mátrix ábrázolása és kezelése ...................................................................................................... 138

III.5.2. Biztonság ....................................................................................................................................... 139
III.5.2.1. A felhasználók azonosítása...................................................................................................................... 140 III.5.2.2. A rendszer biztonságát növel általános módszerek................................................................................ 142

IV. MULTIPROGRAMOZOTT OPERÁCIÓS RENDSZEREK................................................................. 145 IV.1. BEVEZETÉS ............................................................................................................................................ 145 IV.2. A SZÁMÍTÓGÉP-ARCHITEKTÚRA ............................................................................................................. 147 IV.2.1. Az egyprocesszoros von Neumann struktúrájú számítógép-architektúra....................................... 147
IV.2.1.1. Bekapcsolási folyamat............................................................................................................................. 148 IV.2.1.2. Megszakítási rendszer ............................................................................................................................. 148 IV.2.1.3. I/O struktúra ............................................................................................................................................ 149 IV.2.1.4. Közvetlen memória hozzáférés, DMA .................................................................................................... 150 IV.2.1.5. Tárak ....................................................................................................................................................... 150 IV.2.1.6. Védelem .................................................................................................................................................. 152

IV.2.2. Többprocesszoros, szorosan csatolt számítógéprendszerek........................................................... 153 IV.3. FOLYAMATKEZELÉS ............................................................................................................................... 154 IV.3.1. A folyamatmodell leképezése a fizikai eszközökre ......................................................................... 154
IV.3.1.1. A m ködés alapjai ................................................................................................................................... 155 IV.3.1.2. Sorállási modell....................................................................................................................................... 157 IV.3.1.3. Állapotmodell.......................................................................................................................................... 160 IV.3.1.4. Egy megvalósítási séma .......................................................................................................................... 162

-3-

IV.3.1.5. Tétlen ciklusok kiküszöbölése................................................................................................................. 165

IV.3.2. Processzor ütemezés ...................................................................................................................... 167
IV.3.2.1. Az ütemezési algoritmusok összehasonlítása .......................................................................................... 168 IV.3.2.2. Az ütemezési algoritmusokkal szembeni követelmények........................................................................ 170 IV.3.2.3. Ütemezési algoritmusok .......................................................................................................................... 171 IV.3.2.4. Az ütemezési algoritmusok ,,jóságának" értékelése ................................................................................ 176

IV.3.3. Ütemezés többprocesszoros rendszerekben ................................................................................... 178 IV.4. TÁRKEZELÉS .......................................................................................................................................... 179 IV.4.1. A f tár megosztása a folyamatok között......................................................................................... 180
IV.4.1.1. A program címeinek kötése..................................................................................................................... 180 IV.4.1.2. Társzervezési módszerek......................................................................................................................... 185

IV.4.2. Virtuális tárkezelés ........................................................................................................................ 198
IV.4.2.1. A m ködés alapjai ................................................................................................................................... 198 IV.4.2.2. Betöltend lap kiválasztása (fetch-strategy) ............................................................................................ 203 IV.4.2.3. Lapcsere stratégia (replacement strategy)................................................................................................ 203 IV.4.2.4. Gazdálkodás a fizikai tárral ..................................................................................................................... 208 IV.4.2.5. Egyéb tényez k ....................................................................................................................................... 212

IV.4.3. Fájlrendszerek ............................................................................................................................... 214
IV.4.3.1. Az állományok tárolása a lemezen .......................................................................................................... 216 IV.4.3.2. A fájlok szerkezete .................................................................................................................................. 222 IV.4.3.3. Könyvtárak .............................................................................................................................................. 223 IV.4.3.4. M veletek................................................................................................................................................ 224 IV.4.3.5. Osztott fájlkezelés ................................................................................................................................... 225 IV.4.3.6. A hozzáférés szabályozása ...................................................................................................................... 226

IV.5. KÉSZÜLÉKKEZELÉS ................................................................................................................................ 227 IV.5.1. A kernel I/O alrendszere ................................................................................................................ 229 IV.5.2. Háttértárak kezelése ...................................................................................................................... 231
IV.5.2.1. A lemezegység fizikai szervezése ........................................................................................................... 232 IV.5.2.2. A lemezm veletek ütemezése ................................................................................................................. 233 IV.5.2.3. Egyéb szervezési elvek a teljesítmény növelésére ................................................................................... 234 IV.5.2.4. Az adattárolás megbízhatósága................................................................................................................ 235

IV.6. OPERÁCIÓS RENDSZEREK KEZEL I FELÜLETE ........................................................................................ 236 IV.6.1. Az X Window rendszer ................................................................................................................... 238
IV.6.1.1. Az X protokoll......................................................................................................................................... 239 IV.6.1.2. Az X Window rendszer koncepciója ....................................................................................................... 239 IV.6.1.3. Ablakkezelés ........................................................................................................................................... 239 IV.6.1.4. Bemeneti eszközök kezelése ................................................................................................................... 240 IV.6.1.5. Megjelenít eszköz kezelése ................................................................................................................... 240 IV.6.1.6. A kezel i felület elemei........................................................................................................................... 241

V. HÁLÓZATI ÉS ELOSZTOTT RENDSZEREK....................................................................................... 242 V.1. BEVEZETÉS .............................................................................................................................................. 242 V.2. HÁLÓZATI ARCHITEKTÚRA ...................................................................................................................... 244 V.2.1. Alapfogalmak .................................................................................................................................. 244 V.2.2. A hálózatok topológiája .................................................................................................................. 245 V.2.3. A hálózatok típusai.......................................................................................................................... 248 V.2.4. A hálózati kommunikáció rétegei .................................................................................................... 249 V.2.5. Címzés és forgalomirányítás ........................................................................................................... 251 V.3. HÁLÓZATI JELLEG SZOLGÁLTATÁSOK ................................................................................................... 252 V.3.1. Telnet: távoli terminál..................................................................................................................... 252
V.3.1.1. A Telnet kapcsolat .................................................................................................................................... 253 V.3.1.2. Szerver és kliens programok ..................................................................................................................... 254 V.3.1.3. A Telnet parancsértelmez ....................................................................................................................... 255

V.3.2. FTP: fájl átvitel............................................................................................................................... 257
V.3.2.1. FTP kapcsolat ........................................................................................................................................... 257 V.3.2.2. FTP kliens és szerver programok.............................................................................................................. 258 V.3.2.3. Az FTP parancsértelmez ......................................................................................................................... 260

V.4. ELOSZTOTT SZOLGÁLTATÁSOK ............................................................................................................... 260 V.4.1. Jellemz k......................................................................................................................................... 260
V.4.1.1. Az elosztott rendszerek legfontosabb jellemz i........................................................................................ 261 V.4.1.2. Elosztott rendszerek tervezési szempontjai............................................................................................... 269

-4-

V.4.2. Elosztott fájlrendszerek ................................................................................................................... 279
V.4.2.1. Az elosztott fájlrendszer szolgáltatás ........................................................................................................ 280 V.4.2.2. Az állományok azonosítása....................................................................................................................... 280 V.4.2.3. Elnevezési módszerek............................................................................................................................... 281 V.4.2.4. Az ügyfelek kéréseinek kielégítése........................................................................................................... 283 V.4.2.5. A szolgáltató implementációja.................................................................................................................. 286 V.4.2.6. A fájlok többszörözése.............................................................................................................................. 287

V.4.3. Folyamatkezelés .............................................................................................................................. 288
V.4.3.1. Kliens-szerver folyamatok ........................................................................................................................ 288 V.4.3.2. Távoli eljáráshívás - RPC ......................................................................................................................... 290 V.4.3.3. Szálak alkalmazásának el nyei................................................................................................................. 293

V.4.4. Id kezelés és koordináció elosztott rendszerekben ......................................................................... 295
V.4.4.1. Id kezelés ................................................................................................................................................. 295 V.4.4.2. Elosztott koordináció ................................................................................................................................ 305

V.4.5. Elosztott rendszerek biztonsági kérdései......................................................................................... 313
V.4.5.1. Mi a biztonság?......................................................................................................................................... 313 V.4.5.2. Kik a támadók és mik a fenyegetések? ..................................................................................................... 314 V.4.5.3. A támadás módszerei ................................................................................................................................ 314 V.4.5.4. Az elosztott biztonsági rendszer tervezése................................................................................................ 315 V.4.5.5. Titkosítás .................................................................................................................................................. 316 V.4.5.6. Hozzáférés szabályozás ............................................................................................................................ 318 V.4.5.7. Azonosítás ................................................................................................................................................ 318 V.4.5.8. Azonosítás és kulcs szétosztás .................................................................................................................. 318 V.4.5.9. Kerberos: hitelesítési protokoll nyílt hálózati rendszerekre ...................................................................... 320

VI. UNIX............................................................................................................................................................ 323 VI.1. BEVEZETÉS ............................................................................................................................................ 323 VI.2. A UNIX RÖVID TÖRTÉNETE ................................................................................................................... 324 VI.3. BELS SZERKEZET ÉS M KÖDÉS............................................................................................................. 327 VI.3.1. Szerkezet ........................................................................................................................................ 327 VI.3.2. Folyamatkezelés............................................................................................................................. 330
VI.3.2.1. Végrehajtási módok és környezetek ........................................................................................................ 331 VI.3.2.2. A folyamat absztrakció ­ a folyamatok állapotai és az állapot-átmeneti gráf.......................................... 333 VI.3.2.3. Folyamatok környezete (kontextus) ........................................................................................................ 335 VI.3.2.4. Folyamatok létrehozása ........................................................................................................................... 338 VI.3.2.5. Folyamatok befejezése (terminálás) ........................................................................................................ 339

VI.3.3. Ütemezés ........................................................................................................................................ 340
VI.3.3.1. Az ütemezési algoritmussal szemben támasztott követelmények............................................................ 340 VI.3.3.2. A UNIX-ütemezés rövid jellemzése ........................................................................................................ 341 VI.3.3.3. Folyamatok ütemezési prioritása ............................................................................................................. 342 VI.3.3.4. Környezetváltás ütemezéskor .................................................................................................................. 347 VI.3.3.5. Adatszerkezetek a folyamatok prioritásának tárolására........................................................................... 347 VI.3.3.6. Példa az ütemezés számolására ............................................................................................................... 348 VI.3.3.7. A UNIX-ütemezés értékelése .................................................................................................................. 350 VI.3.3.8. Call-out.................................................................................................................................................... 351

VI.3.4. Szinkronizáció................................................................................................................................ 354
VI.3.4.1. UNIX jelzések ......................................................................................................................................... 354 VI.3.4.2. Jelzések keltése........................................................................................................................................ 355 VI.3.4.3. Jelzések kezelése ..................................................................................................................................... 356 VI.3.4.4. Megbízhatatlan jelzések .......................................................................................................................... 358 VI.3.4.5. Megbízható jelzések ................................................................................................................................ 358 VI.3.4.6. Az SVR3 implementáció ......................................................................................................................... 359 VI.3.4.7. BSD jelzésmenedzsment ......................................................................................................................... 359 VI.3.4.8. Az SVR4 jelzések.................................................................................................................................... 360 VI.3.4.9. Kivételkezelés ......................................................................................................................................... 361 VI.3.4.10. Folyamatcsoportok és terminálkezelés .................................................................................................. 361

VI.3.5. Folyamatok közötti kommunikáció (interprocess communication)................................................ 363
VI.3.5.1. Jelzések ................................................................................................................................................... 363 VI.3.5.2. Cs vezetékek........................................................................................................................................... 364 VI.3.5.3. Folyamat-nyomkövetés ........................................................................................................................... 365 VI.3.5.4. System V IPC .......................................................................................................................................... 366 VI.3.5.5. Szemaforok.............................................................................................................................................. 367 VI.3.5.6. Üzenetsorok............................................................................................................................................. 368

-5-

VI.3.5.7. Osztott memória ...................................................................................................................................... 369 VI.3.5.8. Hálózati kommunikáció ­ socket programozás ....................................................................................... 370

VI.3.6. Állományrendszer implementációk ................................................................................................ 374
VI.3.6.1. A System V állományrendszer ................................................................................................................ 375 VI.3.6.2. A Berkeley FFS állományrendszer .......................................................................................................... 391 VI.3.6.3. Az állományrendszerek megvalósításának újabb megközelítése............................................................. 395 VI.3.6.4. Speciális állományrendszerek.................................................................................................................. 398 VI.3.6.5. Modern állományrendszerek ................................................................................................................... 401

VI.3.7. Teljes folyamatok háttértárra írása (swapping) ............................................................................ 403
VI.3.7.1. A háttértár szervezése.............................................................................................................................. 404 VI.3.7.2. A háttértár foglalási és felszabadítási algoritmus .................................................................................... 405 VI.3.7.3. Folyamatok háttértárra írása .................................................................................................................... 405 VI.3.7.4. A háttértárra írás, illetve a háttértárról való beolvasás szabályai ............................................................. 409 VI.3.7.5. A háttértárra kiírandó folyamat kiválasztásával kapcsolatos problémák ................................................. 410

VI.3.8. Igény szerinti lapozás..................................................................................................................... 410
VI.3.8.1. A virtuális memóriakezelést támogató adatszerkezetek .......................................................................... 412 VI.3.8.2. A virtuális memóriakezelést támogató adatszerkezetek használata ......................................................... 415 VI.3.8.3. Laphibák.................................................................................................................................................. 418 VI.3.8.4. A laptábla bejegyzés, a diszk blokk leíró és a pfdata együttes használata ............................................... 419 VI.3.8.5. A copy-on-write technika és használata .................................................................................................. 421 VI.3.8.6. Hivatkozás bit szimulálása szoftverb l.................................................................................................... 423 VI.3.8.7. A 4.3 BSD virtuális memóriakezelése..................................................................................................... 425

VI.4. HÁLÓZATI ÉS ELOSZTOTT SZOLGÁLTATÁSOK A UNIX-BAN ................................................................... 426 VI.4.1. A TCP/IP protokoll család............................................................................................................. 426 VI.4.2. A SUN Network File System (NFS)................................................................................................ 427
VI.4.2.1. SUN NFS jellemz tulajdonságai............................................................................................................ 428 VI.4.2.2. A SUN NFS részei .................................................................................................................................. 429 VI.4.2.3. XDR (EXtended Data Representation) protokoll .................................................................................... 431 VI.4.2.4. Az RPC protokoll .................................................................................................................................... 432 VI.4.2.5. Az RPC protokoll m ködése ................................................................................................................... 433 VI.4.2.6. A SUN NFS m ködése............................................................................................................................ 435 VI.4.2.7. Távoli fájlok elérése NFS használatával.................................................................................................. 436

VI.5. POSIX ................................................................................................................................................... 438 VI.5.1. Alapfogalmak, felépítés.................................................................................................................. 439 VI.5.2. POSIX környezet............................................................................................................................ 442 VI.5.3. Hordozható alkalmazások.............................................................................................................. 443 VI.5.4. Folyamatkezelés............................................................................................................................. 445 VI.5.5. Állománykezelés............................................................................................................................. 446 VI.5.6. Jelzéskezelés .................................................................................................................................. 448 VI.5.7. Terminálkezelés ............................................................................................................................. 450 VI.6. A LINUX RENDSZER ......................................................................................................................... 451 VI.6.1. A Linux fejl désének állomásai ..................................................................................................... 452 VI.6.2. A Linux felépítése és m ködése...................................................................................................... 453 VII. A WINDOWS NT OPERÁCIÓS RENDSZER ...................................................................................... 457 VII.1. A WINDOWS NT KIALAKULÁSA ........................................................................................................ 457 VII.1.1. Az NT-vel szemben támasztott követelmények .............................................................................. 458
VII.1.1.1. Elvárások................................................................................................................................................ 458 VII.1.1.2. Tervez i célkit zések............................................................................................................................. 459

VII.1.2. A Windows NT, a Windows 95, és a Windows 98 összehasonlítása ............................................. 459 VII.1.3. Az NT felépítésének f jellemz i ................................................................................................... 462 VII.1.4. Az NT objektumorientált szemlélete ............................................................................................. 462 VII.2. A WINDOWS NT FELÉPÍTÉSE ............................................................................................................. 464 VII.2.1. HAL (Hardware Abstraction Layer)............................................................................................. 464 VII.2.2. Kernel ........................................................................................................................................... 465 VII.2.3. Készülékkezel k (device driver-ek)............................................................................................... 466 VII.2.4. Executive ...................................................................................................................................... 467 VII.2.5. Rendszerfolyamatok...................................................................................................................... 467 VII.2.6. Szolgáltatások............................................................................................................................... 468 VII.2.7. NTDLL.DLL ................................................................................................................................. 469 VII.2.8. Alrendszerek ................................................................................................................................. 469

-6-

VII.2.8.1. POSIX alrendszer................................................................................................................................... 470 VII.2.8.2. Win32 alrendszer ................................................................................................................................... 470

VII.3. A WINDOWS NT BELS MECHANIZMUSAI ......................................................................................... 471 VII.3.1. Megszakítás- és kivételkezelés ...................................................................................................... 471
VII.3.1.1. A megszakítások típusa és prioritása...................................................................................................... 472 VII.3.1.2. Kivételkezelés ........................................................................................................................................ 474

VII.3.2. Objektumkezelés ........................................................................................................................... 474 VII.3.3. Szinkronizáció .............................................................................................................................. 475
VII.3.3.1. Kernel szinkronizáció............................................................................................................................. 475 VII.3.3.2. Executive szinkronizáció........................................................................................................................ 476

VII.3.4. Lokális eljáráshívás...................................................................................................................... 477 VII.4. FOLYAMATOK KEZELÉSE ÉS ÜTEMEZÉSE .............................................................................................. 478 VII.4.1. A Windows NT folyamat modellje ................................................................................................ 478 VII.4.2. Folyamatok kezelése a Windows NT-ben ..................................................................................... 479 VII.4.3. Szálak kezelése az NT-ben ............................................................................................................ 482 VII.4.4. Szálak ütemezése .......................................................................................................................... 484
VII.4.4.1. A kvantum.............................................................................................................................................. 484 VII.4.4.2. Egy szál állapotai ................................................................................................................................... 486 VII.4.4.3. A processzor affinitás............................................................................................................................. 487 VII.4.4.4. A processzor kiválasztása....................................................................................................................... 488

VII.5. MEMÓRIAKEZELÉS................................................................................................................................ 489 VII.5.1. Memória manager felhasználói interfésze.................................................................................... 489 VII.5.2. Memória foglalás ......................................................................................................................... 490 VII.5.3. Osztott elérés memória ............................................................................................................... 491 VII.5.4. Memória védelem ......................................................................................................................... 492 VII.5.5. Copy-on-Write .............................................................................................................................. 492 VII.5.6. Memória foglalása ....................................................................................................................... 495 VII.5.7. A memória mérete ........................................................................................................................ 495 VII.5.8. Címtranszformáció ....................................................................................................................... 497 VII.6. A WINDOWS NT FÁJLRENDSZERE (NTFS)......................................................................................... 498 VII.6.1. Elvárások az NTFS-sel szemben................................................................................................... 499
VII.6.1.1. Tranzakciónkénti feldolgozás ................................................................................................................ 499 VII.6.1.2. Réteg szerkezet device driver struktúra................................................................................................ 501

VII.6.2. Az NTFS további el nyös tulajdonságai....................................................................................... 503 VII.6.3. Az NTFS által használt adattípusok, adatszerkezetek................................................................... 503 VII.6.4. Fájlok elérése NTFS alatt............................................................................................................. 506 VII.6.5. File Record ................................................................................................................................... 507
VII.6.5.1. Rezidens tárolás ..................................................................................................................................... 508 VII.6.5.2. Nem rezidens tárolás .............................................................................................................................. 509

VII.7. BIZTONSÁGI ALRENDSZER .................................................................................................................... 511 VII.7.1. A biztonsági alrendszer komponensei........................................................................................... 511 VII.7.2. Az objektumok védelme................................................................................................................. 512 VII.7.3. A biztonsági auditálás .................................................................................................................. 513 VII.7.4. A logon ......................................................................................................................................... 514 VIII. KÉRDÉSEK, FELADATOK.................................................................................................................. 517 VIII.1. BEVEZETÉS .......................................................................................................................................... 517 VIII.2. AZ OPERÁCIÓS RENDSZER MINT ABSZTRAKT, VIRTUÁLIS GÉP .............................................................. 522 VIII.3. MULTIPROGRAMOZOTT OPERÁCIÓS RENDSZEREK ............................................................................... 528 VIII.4. HÁLÓZATI ÉS ELOSZTOTT RENDSZEREK ............................................................................................... 536 VIII.5. UNIX .................................................................................................................................................. 542 VIII.6. WINDOWS NT...................................................................................................................................... 552

I. Bevezetés

1

I. BEVEZETÉS

Az operációs rendszerek alapvet részét képezik bármelyik számítógépes rendszernek. Egy operációs rendszer olyan program, amely közvetít ként m ködik a felhasználó és a számítógép hardvere között. Els dleges célja, hogy biztosítsa azt a környezetet, amelyben a felhasználó kényelmesen és hatékonyan végre tudja hajtatni a saját programját. A másodlagos cél a számítógép hardverjének minél hatékonyabb használata. Mindehhez az is szükséges, hogy az operációs rendszerek megfelel szolgáltatásokat nyújtsanak a programoknak és a programok felhasználóinak, azzal a céllal, hogy a programfejlesztési feladat könnyebbé váljék.

A számítógépes rendszerek lényegében három f

komponensre oszthatók: hardver,

rendszerprogramok (melyek egészét vagy részét képezi az operációs rendszer), valamint alkalmazói programok.

A hardver - a központi feldolgozó egység (CPU: Central Processing Unit), a memória, valamint a bemeneti/kimeneti (I/O) egységek szolgáltatják az alapvet számítási

er forrásokat. Az alkalmazói programok a felhasználók számára segítik el a saját feladataik megoldását. A rendszerprogramok leglényegesebb része, az operációs rendszer a számítógépes rendszer helyes m ködését biztosítja, vagyis vezérli és koordinálja a hardver felhasználását a különböz alkalmazói programok között. Az operációs rendszer pontos iskolák más-más megközelítései révén eltér

meghatározása nem egységes, a különböz nézetek terjedtek el.

A fejezet további részében el ször az operációs rendszer lehetséges értelmezéseit elemezzük. A következ alfejezetben az operációs rendszerek fejl déstörténetét vizsgáljuk

részletesebben. Végül pedig a II.3. alfejezet a számítógép rendszerek modelljével és architektúrális kérdéseivel foglalkozik.

I. Bevezetés

2

I.1. Mit nevezünk operációs rendszernek?

Van egy olyan mondás, miszerint ,,Szoftver nélkül a számítógép csak egy össze-vissza gubancolt ócskavas-halom". Bárki, aki dolgozott már számítógéppel - bármilyen rövid ideig is - tisztában van ennek a mondásnak az igazságával. A legtöbb ember számára a ,,szoftver (SW)" szó alkalmazói (application) vagy másszóval felhasználói (user) szoftver-t jelent, azaz olyan programokat, amelyek segítségével tervezhetünk egy rhajót, kiszámíthatjuk az adónkat, mozijegyet vásárolhatunk vagy játszhatunk. Ez azonban az igazságnak csak egy része.

Képzeljük el, hogy odaültetnek bennünket egy olyan számítógép elé, amely tényleg csak a puszta hardverb l (HW) áll, semmilyen szoftver nem található rajta: Hogyan lennénk képesek az említett feladatokat megoldani? De még az olyan egyszer dolgok is gondolkodást

igényelnének, mint két szám összeadása, nem is beszélve a szorzásról, osztásról.

Szerencsére azonban a helyzet a valóságban - legalábbis a számítógép történetének nagyobbik felében - ennél sokkal jobb, mert a szoftvernek van egy általában nem mindig látott, de mindig használt rétege (layer), amely a felhasználó (itt ne csak emberi felhasználókra gondoljunk, a rendszer szempontjából felhasználó lehet valamilyen gép vagy akár egy másik számítógép is) és a hardver között helyezkedik el, olyan környezetet teremtve, amely lehet vé teszi az alkalmazó számára a számítógép kényelmes és hatékony használatát. Ezt hívják operációs rendszernek (operating system).

Az operációs rendszer fogalmát nem igen tudjuk pontosan meghatározni, különböz irányzatok más-más ,,szigorúsággal" állnak a kérdéshez. Abban mindenki egyetért, hogy az operációs rendszer része a mag (kernel), vagyis az a program, amely feltétlenül szükséges a gép m ködéséhez és amely közvetlenül vezérli azt. Régebben ezt úgy is meg lehetett közelíteni, hogy a kernel az a program, amely állandóan fut. A dinamikus kernel megjelenése óta azonban ez utóbbi definíció már nem állja meg teljesen a helyét. A másik véglet szerint az operációs rendszerbe tartoznak azok a - tulajdonképpen felhasználói ­

I. Bevezetés

3

rendszerprogramok (system program) is, amelyek a gép általános felhasználását segítik, például a fordítók, szövegszerkeszt k, parancsértelmez .

E könyv a

nézetek különböz ségét figyelembe véve megpróbál inkább

az operációs

rendszer két szintjér l beszélni. A bels , sz kebben értelmezett szint a kernelt takarja, míg egy tágabb szint alatt a köznapi értelemben vett operációs rendszert értjük - azaz mindazokat a programokat, amelyeket egy felhasználó a gép vásárlásakor megkap. Lényeges különbség a kett között, hogy a kernel el van rejtve, ,,védve" van (hardver védelem) a felhasználó el l, azaz ehhez a felhasználó nem fér hozzá, nem tudja módosítani és - elrontani. Bizonyos rendszerprogramokat célszer , ha elérhet a felhasználó, mert így azokat úgy tudja alakítani, hogy használatuk a számára a legkényelmesebb legyen. A hardver és szoftver rétegek egy lehetséges egymásra épülését a II.1.1. ábra mutatja.
Megjegyzés: Számozás (azért írom bele, hogy könnyebb legyen majd megtalálni).

II.1.1. ábra A számítógépes rendszer egymásra épül rétegei

Az

alkalmazói

programok

tehát

a

felhasználó

problémáit

oldják

meg,

míg

a

rendszerprogramok a számítógép saját tevékenységét irányítják. Ezen belül az operációs rendszer felügyeli az összes er forrást (resource), továbbá biztosítja azt a környezetet, amelyben az alkalmazói programok futhatnak. Vezérli mind a programok, mind az er források m ködését, valamint meggátolja a számítógép hibás felhasználását.

A hardver hatékony használatának biztosítása tekintetében az operációs rendszer feladatát er forrás kezelés - ,,alulról", a hardver oldaláról fogalmaztuk meg (ezt hívják ,,bottom-up view"-nak). Er forrás alatt mind hardver, mind pedig szoftver er forrásokat értünk (CPU-id , memória, perifériák, állományok, adatok, stb.), melyeket a felhasználók céljaik elérése érdekében használni szeretnének. A sok, sokszor ütköz vagy ellentmondó igény között az operációs rendszernek kell döntenie és az igényelt er forrásokat felhasználóhoz rendelnie úgy, hogy hatékony, biztonságos és igazságos m ködést biztosítson.

A kényelmes használat biztosítása tekintetében - megkönnyíti a programozást - ,,felülr l", a felhasználó oldaláról (,,top-down view") közelítünk az operációs rendszerhez. Az operációs rendszer önmagában nem végez (kívülr l nézve) hasznos tevékenységet, de olyan környezetet

I. Bevezetés

4

biztosít, amelyben a felhasználói programok képesek hasznos munka végzésére. Ezt úgy is tekinthetjük, hogy az operációs rendszer egy olyan réteget képez a hardver fölött, amely elrejti annak körülményességét és bonyolultságát a programozó el l, és kib víti a számítógép hardver szolgáltatásait. Így a felhasználó egy sokkal kellemesebb tulajdonságokkal rendelkez virtuális gépet (virtual machine, extended machine) lát.

Manapság a felhasználóbarát (user friendly) virtuális gép, illetve környezet biztosítása egyre növekv fontosságú alapkövetelmény minden operációs rendszerrel szemben. Hosszú id t igényelt azonban, amíg eljutottunk ide. A következ fejezetben ezt a történeti fejl dést fogjuk röviden áttekinteni, hangsúlyozva azt, ahogyan a hardver- és szoftver-technikai el relépések kölcsönösen egymásra hatottak, kedvez lökést adva a továbbfejl désnek.

I. Bevezetés

5

I.2. Az operációs rendszerek története

Az operációs rendszerek történetét a számítógépek történetével párhuzamosan, azzal szoros összefüggésben tárgyaljuk. A fejl dés menetének felvázolása során vegyük észre, hogy minden kornak megvolt a ,,legéget bb" problémája, amely mellett a többi - bármilyen komoly volt is - eltörpült. Amint azonban sikerült megoldást találni erre, azonnal a következ id szer nehézség megoldását célozták meg. Így például, mint látni fogjuk az alábbiakban, az els generációs (elektroncsöves) gépek legnagyobb gondja a megbízhatatlanság volt, amely mellett nem igen számított a rossz gépkihasználás. Amint azonban megjelentek a második generációs ,,megbízható" (tranzisztoros) gépek, rögtön a gépid jobb kihasználásának kérdése került el térbe. Vagy egy másik példát említve, amint napjainkhoz közeledve eljutottunk ahhoz, hogy a nagysebesség , megbízható gépek kihasználása ,,optimálissá" vált, majd bizonyos eszközök olcsósága miatt egyre kevésbé volt fontos azok minél jobb kihasználása, a felhasználó kényelmének kiszolgálása lett a ,,legsúlyosabb" megoldandó probléma.

I.2.1. Korai rendszerek

Charles Babbage (1792-1871) nevéhez f z dik az a szerkezet, amely tulajdonképpen a digitális számítógép sének tekinthet . Az általa ,,elemz gépnek" (analytical engine)

nevezett mechanikus szerkezetet azonban soha nem sikerült megépíteni, mert abban az id ben nem tudták az alkatrészeket megfelel pontossággal el állítani.

Hatalmas el relépést jelentett, hogy a II. világháború befejez dése környékén több egyetemen illetve kutatóintézetben sikerült m köd számítógépet építeni - például az Egyesült

Államokban H. Aiken (Harvard), J.P. Eckert és W. Mauchley (University of Pennsilvania), Németországban pedig K. Zuse nevéhez f z dnek sikerek. Igazán ismertté azonban Neumann János (1903-1957) magyar származású, Amerikában élt matematikus és H.H. Goldstine írányítása alatt épült (1945) ,,els " számítógép vált. Az EDVAC (Electronic Discrete Variable Calculator, diszkrét változós elektronikus számológép) hosszú ideig mintául szolgált a többi

I. Bevezetés

6

tárolt programú, elektronikus programvezérlés számítógép építéséhez. A von Neumann által megfogalmazott alapelv (mely szerint a programokat és adatokat ugyanabban a tárban, ugyanolyan formában tárolták és csak környezetük alapján különböztették meg) miatt nevezik ma is a hagyományos számítógépeket von Neumann struktúrájú gépeknek.

Az els

számítógépek 1500 szorzás vagy 15000 összeadás elvégzésére voltak képesek

másodpercenként legfeljebb 12 jegy decimális számnak megfelel bináris számokkal. A tervezést, építést, programozást, m ködtetést, javítást egyetlen csapat végezte. A gépek elektroncsövesek voltak, ami teljesen megbízhatatlanná tette a m ködést, mivel a nagyjából 20000 elektroncs közül nagy valószín séggel kiégett valamelyik az egyszer programok futása alatt. Programnyelveket nem ismertek ebben az id ben, így mindent gépi kódban oldottak meg. A programokat dugaszolós kapcsolótáblán rögzítették és ezeket csatlakoztatták a számítógépbe. További problémát jelentett, hogy nem ismerték el re a futáshoz szükséges id t, így a gépid foglalást becslés alapján végezték, ami azzal járt, hogy - jobbik esetben kihasználatlan maradt a drága gépid egy része, - rosszabbik esetben pedig - az eredmények kiszámítása el tt meg kellett szakítani a futást, és a gépet át kellett adnia következ foglalónak. Technikai el relépést jelentett, amikor az '50-es években megjelentek a lyukkártyák.

Ebben az id ben számítógép segítségével olyan egyszer számítási feladatokat oldottak meg, mint szinusz, koszinusz táblázatok kiszámítása.

I.2.2. Batch rendszerek

A számítógépek II. generációját (1955-65) már tranzisztorokból építették, így megoldódott az eddigi legéget bb probléma - az elektroncsövek miatti megbízhatatlan m ködés. Azonban ezek a gépek rettenetesen drágák voltak. M ködtetésükhöz speciális légkondicionált géptermek kellettek. A korszakhoz f z dik a külön professzionális operátori csapat megjelenése, amely a gép kiszolgálását és a programok futtatását végezte. A programozás akkori menete szerint a programokat papíron írták (ekkor már ismertek programnyelveket, például assemblereket, Fortran-t), majd ezeket lyukkártyán kilyukasztották. Az elkészült
Megjegyzés: Azért kezdetben vala az "open shop", ami még mindig gépid -foglalás.

I. Bevezetés

7

lyukkártyákat leadták egy teremben, ahonnan azokat az operátorok vitték a géphez, majd a szükségnek megfelel en betöltötték a fordítót, stb. Az eredményeket papírra nyomtatták (online módon, azaz a beolvasás és az eredmények kinyomtatása nem volt id ben szétválasztva a programok futásától), melyeket egy újabb teremben lehetett átvenni. A programok el készítési ideje tehát roppant nagy volt, a drága gépek drága gépidejének egy jó része azzal telt, hogy az operátorok a gépterem és kiszolgáló termei között sétáltak, miközben maga a számítógép kihasználatlanul állt. Ezért aztán következ id veszteségek csökkentését t zték ki célul. fejl dési lépésként a ,,felesleges"
Megjegyzés: Ezt még meg lehet oldani munkaszervezéssel....

A megoldást a kötegelt vagy batch feldolgozás megjelenése jelentette, amely szerint az operátorok összeválogatták a ,,hasonló" munkákat (például mindegyik Fortran fordítót igényelt), majd ezeket egymás után futtatva több korábbi lépést csak egyszer kellett elvégezni. Az mágnesszalagok megjelenése (az összeállított köteget a lyukkártyákról egy szalagra másolták) tovább könnyítette és gyorsította ezt a folyamatot Hasonlóképpen, a jobb gépkihasználást segítette, hogy az on-line perifériás m veletekr l áttértek az off-line perifériás m veletekre (II.2.1. ábra), azaz a lyukkártyák beolvasását, valamint az eredmények nyomtatását a programok futtatásától elválasztva, általában egy külön erre a célra kifejlesztett kis számítógép segítségével végezték.
Megjegyzés: Az egyszer monitor talán már a kártyás világban megjelent, az off-line I/O egykés bbi ötlet, ami már a készülékföggetlenség igényét is felveti. Megjegyzés: A kötegelt feldolgozás a kártyakötegr l kapta a nevét. A mágnesszalag nem feltétele az összeválogatásnak.

II.2.1. ábra a, On-line b, off-line periférás m veletek blokkvázlata

A programok futása között eltel ,,üres" id t (amíg az operátor észrevette, hogy egy munka (job) befejez dött és elindította a következ t) tovább csökkentette, amikor sikerült kifejleszteni egy olyan felügyel programot - egyszer monitort (resident monitor) -, amely egy-egy munka befejez dése után automatikusan beolvasta a következ t és megkezdte annak végrehajtását. Vagyis megjelentek az els operációs rendszerek. A jobleírásokat a könnyebb felismerhet ség kedvéért speciális karakterrel kezd d vezérl utasításokkal egészítették ki, amelyek a monitor számára hordoztak információt. (Így minden jobleírás a munka kezdetét és végét jelz utasítással kezd dött illetve végz dött; külön utasítás adta meg, hogy mikor és milyen fordítóprogramot kell betölteni, mikor lehet a tárgyprogramot betölteni (azaz hol a programrész vége); elkezd dhet a program futtatása, stb.)

I. Bevezetés

8

II.2.2. ábra A korai batch programok tipikus szerkezete

Az egyszer monitorok megjelenése egyben azt is jelentette, hogy a korábban egy területként kezelt memóriát a továbbiakban két alapvet részre, egy monitor és egy felhasználói területre osztották.

Az off-line perifériás m veletek alkalmazásának legnagyobb el nye abban rejlett, hogy a f számítógép m ködése nem függött többé a lassú kártyaolvasó és sornyomtató m ködését l, hanem a sokkal gyorsabb mágnesszalagvezérl ét l. Összességében azonban ez a megoldás csak akkor gyorsította a munkák befejez dését, ha nagyjából azonos idej CPU és perifériás m veletet tartalmaztak.

Az új technika elterjedése azt is eredményezte, hogy a programok nem az eredeti perifériákat, hanem logikai I/O készülékeket használtak. Ezt hívjuk készülékfüggetlen vagy perifériafüggetlen programozásnak (device independence). Szabványos felület

perifériameghajtókat kezdtek alkalmazni egyrészt, hogy biztosítsák, hogy a programok ne vegyék észre a ,,cserét", másrészt viszont a programokat átírás nélkül lehetett használni akkor is, ha a rendszerben kicserélték a perifériákat.

A fenti megoldásnak minden el nye mellett hátránya volt, hogy több számítógépet (esetenként hármat vagy akár többet is) igényelt és a szalagok cseréje még mindig nehézkesen, operátori segédlettel történt. A probléma megoldására megalkották az autonóm perifériavezérl ket. Az autonóm perifériavezérl k lehet vé tették a pufferelést (buffering), azaz, hogy az I/O m veletek a perifériák és a CPU között elhelyezked pufferen keresztül hajtódnak végre megszakítás, illetve blokkos átvitel segítségével. Tehát például a beolvasás egy pufferbe történik és a CPU innen veszi az adatot, majd annak feldolgozásával egyid ben újabb perifériás m velet hajtódhat végre (átlapolt feldolgozás).

A hibakeresés (debugging) továbbra is komoly nehézségekbe ütközött, ugyanis ezt nyilvánvalóan csak a programozó tudta elvégezni. Mivel azonban nem volt közvetlen kapcsolatban a számítógéppel, ezért off-line módon, a hibás befejez déskor kiiratott (dumping) memória és regiszter tartalmak segítségével végezte.

I. Bevezetés

9

Ebben az id ben a számítógép segítségével olyan tudományos és mérnöki számításokat is el tudtak már végezni, mint például parciális differenciálegyenletek megoldása.

A II. generációs gépek hatására a '60-as évek elejére két teljesen független, egymástól eltér fejl dési irány alakult ki: szószervezés nagy tudományos komputerek és karakterszervezés kis perifériás gépek, ami a fejlesztést igen megdrágította. Következ lépésként tehát ezen kellett segíteni.

A kérdést a számítógépek harmadik generációjánál (1965-80, hardver: integrált áramkörök) az IBM oldotta meg, a System/360 számítógépcsalád bevezetésével. A család különböz méret (memória, gyorsaság, perifériák, ár, teljesítmény), de egymással kompatibilis gépekb l állt, így elvileg bármely gépre írt szoftver futtatható volt bármelyiken. A gyártmánycsalád és szabványos egységek bevezetése a hardver fejlesztés költségeinek csökkenése mellett egyéb el nyökkel is járt, ugyanakkor azonban nagyon drága és bonyolult operációs rendszert igényelt.
Megjegyzés: A drágaság talán nem triviális, és a megoldás sem. Utalni kellene a gyártmánycsalád és a szabványos egységek el nyére.

Újra el térbe került tehát az alapvet kérdés, a költségcsökkentés kérdése. Ehhez komoly lökést jelentett a nagykapacitású, gyors és véletlen hozzáférés (random access) mágnesdobok és mágneslemezek megjelenése. Az ún. spooling technika (simultaneous peripherial operation on-line) ezeket a tárakat mint egy hatalmas méret puffert használja, és egyszerre nemcsak egy, hanem több munkát is lemezre tölt. Ez a megoldás lényegében az off-line perifériás m veletek egyetlen gépen történ megvalósítása. Lehet vé válik a perifériás és CPU m veletek teljes szétválasztása úgy, hogy több munka is átlapolódhat, azaz például az egyik munka végrehajtásával egyid ben egy másik munka beolvasása és egy harmadik eredményeinek kivitele folyhat. Ezzel mind a perifériák, mind pedig a CPU kihasználtsága jelent sen megn tt (lásd II.2.3. ábra).

II.2.3. ábra A spooling technika

A véletlen hozzáférés háttértárak megjelenésének legnagyobb jelent ség következménye azonban a multiprogramozás lehet sége volt.

I. Bevezetés

10

I.2.3. Multiprogramozott rendszerek

A multiprogramozás megjelenése el tt a lassú perifériák korlátozták a CPU kihasználtságát: a CPU-nak meg kellett várnia a perifériás m veletek befejez dését, miel tt a következ munka végrehajtásába belekezdhetett. Ráadásul a szekvenciális hozzáférés tárak miatt a munkákat csak érkezési sorrendjükben lehetett feldolgozni.

A véletlen hozzáférés tárakról az operációs rendszer tetsz leges sorrendben választhatja ki a következ végrehajtandó munkát, és egy speciális adatszerkezet (nyilvántartás) a ,,job pool" révén úgy ütemezheti, hogy a CPU kihasználtsága közel 100 %-os legyen. (A kés bbiekben látni fogjuk, hogy a gyakorlatban legjobb esetben is csak nagyjából 90 %-os kihasználtság érhet el, mivel annak biztosításához, hogy a munkák kés bb tovább futtathatók legyenek, szükséges a környezetük elmentése illetve visszaállítása.) Egy-egy munka addig fut, amíg várakozni nem kényszerül. Ekkor az operációs rendszer egy másik, futni képes munkát választ ki és indít el. Amint a félbehagyott munka várakozási feltétele teljesül, újra felkerül a futtatható folyamatok listájára, és az operációs rendszer a következ ütemezési alkalommal kiválaszthatja futásra (II.2.4. ábra).

II.2.4. ábra A multiprogramozás alapelve

A számítógép és a periférák jó kihasználása mellett a multiprogramozás teljesen új feladatok elé állította a rendszertervez ket. A munkák kiválasztása ütemezést igényel. Természetesen egyszerre több programot is a tárban kell tartani, a memória felhasználói területe több munka között oszlik meg, vagyis megjelenik a tárgazdálkodás igénye. A CPU mellett a többi er forrás felhasználását is koordinálni kell, gondoskodni kell az egyes programok és memóriaterületük védelmér l a többiekkel szemben, stb.

A III. generációs számítógépek elég gyorsak és nagy kapacitásúak voltak és lényegében sikerült megoldani az optimális kihasználtság kérdését is. Így a legéget bb problémát az jelentette, hogy továbbra sem volt közvetlen kapcsolat a programozó és a gép között, vagyis

I. Bevezetés

11

nehéz volt a programokat módosítani, illetve hibát keresni bennük. Ezért ebben az irányban történtek fejlesztések, aminek hatására létre is jöttek az els olyan rendszerek, amelyeknél közvetlen on-line kapcsolat volt a felhasználó és a számítógép között.

I.2.4. Id osztásos rendszerek

Az

id osztásos

(time-sharing,

multitasking)

rendszerek

közvetlen,

interaktív

kommunikációt biztosítanak a felhasználó és programja, valamint az operációs rendszer között. Ezeknél a rendszereknél általában minden felhasználónak külön beviteli eszköze (terminál, konzol) van, melyen keresztül on-line módon adhat parancsokat és kaphat a rendszert l válaszokat. Bár a CPU egyszerre több párhuzamosan dolgozó felhasználó között meg van osztva, azok úgy dolgoznak a számítógépen, mintha az kizárólag hozzájuk tartozna. Ezért fontos elvárás, hogy a rendszer válaszideje értelmes t réshatáron belül legyen.

Általában a háttérben valamilyen batch-rendszer is fut, hogy az ,,üresjáratok" idején se legyen tétlen a gép.

Ehhez a korszakhoz köt dik az MIT, a Bell Laboratorium és a General Electric közösen megkezdett fejlesztése. Terveikhez az ötletet a városi elektromos hálózatok adták, mely szerint minden lakásban megtalálhatók a rendszerhez csatlakozó dugaszoló aljzatok, melyekhez csatlakoztatni lehet a különböz elektromos készülékeket. Ennek mintájára olyan számítógéphez csatlakozó hálózati rendszert szerettek volna létrehozni - el ször Bostonban, majd másutt is - melyben mindenki számára lehet vé válik - otthonról - a nagy, drága, közös er forrásokhoz való hozzáférés, vagyis az egy hatalmas közös számítógéphez, valamint adatbázisokhoz, stb. való kapcsolódás terminálokon keresztül. Bár a terv abban az id ben megvalósíthatatlan maradt, a MULTICS (MULTiplexed Information and Computing Service) néven ismertté vált rendszer híressé vált újszer és maradandó ötletei miatt. Hogy mást ne említsünk, a projekt pozitív és negatív tapasztalatai egyaránt jelent sen hatottak a UNIX operációs rendszer fejleszt ire. A UNIX pedig bizonyított, még ma is az egyik uralkodó operációs rendszer a miniszámítógépeken és a munkaállomásokon.
Megjegyzés: Ez javított szöveg!

I. Bevezetés

12

I.2.5. Személyi számítógépek

Az LSI (Large Scale Integration) áramkörök megjelenése jelent sen lecsökkentette a számítógép hardver költségeit, így a IV. generációs számítógépek (1980-90) szinte mindenki számára elérhet k (megvásárolhatók) voltak. Emiatt általánossá vált az egy felhasználó-egy gép struktúra, vagyis, hogy minden egyes felhasználó külön számítógéppel rendelkezik. Ezért is hívjuk ezeket az olcsó kisgépeket személyi számítógépnek (personal computer, PC).

A személyi számítógépek megjelenése átüt változást hozott a számítástechnikában. Olyan felhasználók és olyan alkalmazási területek számára vált elérhet vé az eszköz, amelyek korábban fel sem merültek, vagy ahol az ötletek korábban megvalósíthatatlannak bizonyultak (ld. MULTICS projekt). A sokszor egészen más érdekl dés felhasználók új követelményt fogalmaztak meg a rendszerekkel szemben, mivel nem tudtak és nem is akartak tudni a számítógépek m ködési elveir l, részleteir l. A felhasználóbarát (user friendly) szoftver éppen ezt, azaz a részletek elrejtését és a kényelmes programozási felület biztosítását jelenti. A korra legjellemz bb operációs rendszerek az MS-DOS (PC-re) és a UNIX (munkaállomásra), amelyek kés bb a felhasználó-barátság jegyében, a feldolgozási sebességben és tárkapacitásban mérhet teljesítményparaméterek rohamos javulásának

lehet ségével élve, els sorban a felhasználói felületek tekintetében jelent s fejl dést mutattak (Windows, X-Windows).

A személyi számítógépek minden kényelme és el nye mellett azonban a `80-as évek közepét l igényként merült fel, hogy kapcsolatot lehessen teremteni más - szintén PC-t használó - felhasználókkal, illetve használni lehessen drága, egy-egy ember által már nem megvehet er forrásokat. Ezért a PC-ket hálózatba kezdték kötni. A hálózattal összekötött (és így más felhasználók által is elérhet ) személyi számítógéprendszerek rávilágítottak az ezen gépeken futó rendszerek legnagyobb hibájára, nevezetesen, hogy mivel a PC-ket alapvet en úgy tervezték, hogy egyetlen felhasználó fogja használni ket, ezért semmilyen illetéktelen hozzáférés elleni védelemmel nem látták el ket. Gondoljunk csak például a vírusokra, hogy mennyire esetleges még ma is a PC-k védelme ezekkel szemben.

I. Bevezetés

13

A `80-as évek közepe két jelent s technológiai fejl dést hozott. Egyrészt bekövetkezett a mikroprocesszorok minden eddiginél nagyobb teljesítmény növekedése, másrészt megjelentek a lokális hálózatok (local area network, LAN). Ez utóbbiak általában 10-100 összekötött gépet tartalmaztak, uniformizált információ áramlást téve lehet vé közöttük. A korábbi központi (centralized) rendszerek (egy CPU, a memóriája, perifériái, terminálok, stb.) mellett tehát megjelentek az elosztott (distributed) rendszerek (több CPU, közös, illetve külön memóriák stb.)

I.2.6. Elosztott rendszerek

A feldolgozó képesség elosztottsága (decentralizálás) igen sok el nyös tulajdonságot hordoz a centralizált rendszerekkel szemben. Hogy csak néhányat említsünk, mindenképpen megjegyzend a sebesség növekedése, a funkciók térbeli elosztása (a feladathoz igazodó, térben elosztott rendszerstruktúra alakítható ki), a megbízhatóság növekedése (egy-egy gép meghibásodása esetén a többi továbbra is m köd képes, feladatait az esetek többségében át tudják venni a többiek), a fejlesztés lehet sége (kis lépésekben is), az adatok és eszközök megosztása (közös adatbázis, illetve drága perifériák közös használata), a kommunikáció lehet sége (felhasználók és programok között, elektronikus levelezés, e-mail, stb.), flexibilitás (terhelés megosztás, optimalizálás).

Külön kiemelend ek az ár/teljesítmény arányra vonatkozó gazdasági szempontok. A modern mikroprocesszorok megjelenése el tt Grosch törvénye adta meg, hogy a CPU teljesítménye az ár négyzetével arányos, vagyis kétszeres árért négyszeres teljesítményt lehetett elérni. A mikroprocesszorokra azonban ez már nem érvényes. Kétszeres árért lényegében ugyanazt a CPU-t lehet megvásárolni, valamelyest gyorsabb órával (vagyis a teljesítmény arányaiban alig növekszik). A teljesítmény növelés lehet ségét a több CPU alkalmazása hordozhatja.
Megjegyzés: Ezt vagy magyarázzuk, vagy hivatkozzunk, vagy hagyjuk.

Az elosztott rendszerek természetesen problémákat is felvetnek, melyek közül a három legfontosabbnak maga a szoftver (az elosztottság és párhuzamosság miatt felmerül problémák komplexitása min ségi ugrás jelent, ezért a korábbiakhoz képest egészen más jelleg operációs rendszerekre lenne szükség, melyekr l azt mondhatjuk, hogy bizonyos

I. Bevezetés

14

értelemben még ma is kezdeti stádiumban vannak), maga a hálózat (megfelel

átviteli

sávszélesség és min ség biztosítása, túlterhelés és egyéb problémák), és a biztonság (könnyebb az illetéktelen hozzáférés a "titkos" adatokhoz).

Az elosztott rendszerek fejlesztése során két alapvet cél megvalósítása lebegett a tervez k szeme el tt. Egyrészt olyan rendszereket próbáltak létrehozni, amelyek lehet vé teszik, hogy sok felhasználó tudjon egymás mellett dolgozni és egymással kapcsolatot tartani. A másik cél pedig olyan rendszerek megvalósítása, melyek egy adott problémát a részfeladatok párhuzamosításával maximális sebességgel oldanak meg. Bizonyos szerz k a kétféle rendszer megkülönböztetésére az el bbi esetben használják az elosztott rendszer elnevezést (további elnevezések: hálózati (network) vagy multikomputeres rendszerek), az utóbbiakra pedig a párhuzamos (parallel), rendszer elnevezés az elterjedt. A multikomputeres rendszerekben az egyes gépek az esetek többségében saját, külön memóriával és órával rendelkeznek, vagyis lazán csatoltak (loosely coupled), míg a multiprocesszoros rendszerek többségére a közös memória és óra használat (szorosan csatolt, strongly coupled rendszerek) a jellemz .
Megjegyzés: Nem igazán tetszik.

Az architektúrától függetlenül különbséget kell tennünk a rendszerek között az átlátszóság (transparency) alapján. Ennek hiánya esetén a felhasználóknak tudniuk kell, hogy a rendszerben több számítógép is van, melyeken saját operációs rendszer fut, és az alkalmazók beléphetnek felhasználóként távoli gépekre is. Az ilyen rendszerek operációs rendszerei nem térnek el alapvet en az egyprocesszoros rendszerek operációs rendszereit l, mindössze egy hálózatvezérl (network controller) kiegészítés szükséges a helyes m ködtetéshez.

A fentiekkel ellentétben az átlátszó rendszereket a felhasználó úgy látja, mint egy tradicionális egyprocesszoros rendszert. Vagyis, bár általában tisztában van vele, hogy a rendszerben több processzor is m ködik, a feladatok szétosztását az operációs rendszer automatikusan végzi, azaz a felhasználó nem tudja, hogy egy-egy munka melyik processzoron fut, egy fájl melyik számítógép lemezén tárolódik. A feladatok jellegéb l következ en itt egészen más fajta operációs rendszer szükséges a helyes m ködtetéshez.

I. Bevezetés

15

I.2.7. Valósidej rendszerek

Egészen röviden említjük a IV. generációs számítógép rendszerek egy további fajtáját, a valósidej (real-time) rendszereket.

Azokat a rendszereket, amelyekkel szemben a környezeti, valós id skálához kötött id követelményeket támasztunk, valósidej rendszereknek nevezzük. El írhatjuk például, hogy a rendszer egy környezeti eseményre mennyi id n belül reagáljon, vagy milyen id zített akciókat hajtson végre. Az elnevezés utal arra a különbségre, hogy egy általános célú számítógéperendszer szokásos feladatai ,,id tlenek" (pl. egy szokásos job végrehajtása a lefuttatás id pontjától függetlenül ugyanazt a helyes vagy hibás végeredményt adja), vagy esetleg bels id t használnak (pl. szimulációs feladatok esetén). A valósidej ség szorosan kapcsolódik más tulajdonságokhoz is. A valósidej rendszerek

leggyakrabban célrendszerek (ipari folyamatfelügyel , -irányító, orvosi rendszerek, stb), melyek célhardveren futnak. Speciális célú operációs rendszereik bizonyos id korlátok betartásával kell, hogy m ködjenek. Érzékel k (sensor) segítségével észlelt, a környezetben (külvilágban) történt változásokra adott id n belül válaszolniuk kell, vagyis a rendszernek garantálnia kell valamilyen el írt id korláton belüli válaszid t.

A valósidej rendszerek két alapvet fajtáját különböztetjük meg: a szigorúbb feltételeket teljesít kemény valósidej rendszerek (hard real-time) biztosítják, hogy a kritikus munkák befejez dnek id ben, míg a lágy valósidej (soft real-time) rendszerek csak azt garantálják, hogy a kritikus munkák prioritással futnak.

A valósidej operációs rendszerek tárgyalása mind mennyiségében, mind témájában messze meghaladja e könyv lehet ségeit, így ezekkel a rendszerekkel a továbbiakban legfeljebb utalásszer en fogunk foglalkozni.

I.2.8. Nyílt rendszerek

I. Bevezetés

16

A hálózatok széles kör

terjedése és ezzel együtt új és drága eszközök széles kör
Megjegyzés: Mi jellemzi az V. generációs számítógépeket? Tudjuk már?

hozzáférhet sége új igények megfogalmazását vonta maga után a rendszertervez k felé. A számítógépek V. generációja (napjainkban) olyan számítógéprendszerekben m ködik,

melyek fizikailag is nagy távolságokon keresztül, az egész világot behálózva, szinte mindenhonnan hozzáférhet k. A fizikai, kulturális, technikai különbségek áthidalása szükségszer en maga után vonja a kommunikáció és a csatlakozási felületekegységesítését, világszabványok alkalmazását. Ennek jegyében egy nemzetközi szervezet az OSI (International Organization for Standardization) ajánlásokat fogalmaz meg a rendszerek egységes m ködéséért, melyeket célszer mindenkinek betartani, aki piacképes termékeket akar létrehozni. Így léteznek szabványok az operációs rendszerekre vonatkozóan (open operating system standards), a felhasználói felületekre vonatkozóan (open user interface standards), az alkalmazásokra vonatkozóan (open user application standards), és a kommunikációra vonatkozóan (open communication standards).
Megjegyzés: Akkor mi a nyílt rendszer? Az ami OSI-konform? És a monopolhelyzetben lév érdeke is a szabványosítás? És piacképes? Megjegyzés: Hát nem éppen az OSI-konformitás a piacképesség csúcsa.

I.2.9. Napjaink rendszerei

Napjaink rendszerei multiprogramozott rendszerek. Megtalálhatjuk közöttük a IV. generációtól kezd d en mindegyik említett rendszerfajtát. A rendszerek általában interaktív rendszerek, bár találkozhatunk (az esetek többségében nem tiszta) batch-rendszerekkel is. Ez utóbbiak azonban különböznek a korai batch rendszerekt l, szervez dési elvük nem az azonos munkafázisok szükségszer csoportosítását jelenti. Elnevezésük azonban megmaradt, mert ezekben a rendszerekben el re összeállított, vezérl információkkal ellátott munkák futnak, és a programok futásába nem lehet interaktívan beavatkozni.

Az operációs rendszerek kezel i felületét napjainkban az ablakozó technika jellemzi. Ez a felhasználók számára lényegesen barátságosabb, áttekinthet bb munkalehet séget nyújt. Ugyanakkor az ablakozó felület mellett - els sorban a távoli belépések számára, továbbá a parancsértelmez szövegmanipulációs lehet ségeinek és az operációs rendszer batch-fájlokkal történ programozási lehet ségének megtartása érdekében - a hagyományos, parancssor-

orientált kezel i felület is megtalálható (ld. UNIX és származékai).

I. Bevezetés

17

A számítógépek és az operációs rendszerek területe a technika talán legdinamikusabban fejl d területének tekinthet . Így, bár az operációsrendszerek történeti taglalását itt

abbahagyjuk, maga a történet nem fejez dött be. Éppen nemrégiben jelentették be egy elveiben, m ködésében teljesen új, beágyazott celluláris neurális hálózatokat (cellural neural network, CNN) alkalmazó, három dimenziós rácsszerkezet , analóg, univerzális, tárolt programú számítógép létrehozását, mely a biológiai szinopszisok terjedéséhez hasonló jelterjedési elv alkalmazásával m ködik, minden eddiginél nagyobb m veleti sebességet és számítási kapacitást biztosítva. Elterjedése esetén nyilvánvalóan forradalmi változásokat fog hozni a számítástechnikában és az operációs rendszerek fejl désében. És ki tudja, mi minden van még el ttünk?

I.1. Rendszermodell és rendszerarchitektúra

1

I.1. Rendszermodell és rendszerarchitektúra

Miután megismerkedtünk az operációs rendszerek rövid történetével, most - megmaradva a bevezet höz ill áttekint szinten - váltsunk néz pontot. Közelítsünk az operációs rendszerhez a szoftver rendszerek szokásos tervezési szemléletével. El ször húzzuk meg a rendszer határait, vizsgáljuk meg a tipikus környezeti kapcsolatokat, és a rendszer viselkedését a környezet szerepl ivel való kapcsolatban (rendszermodell). Ezt követ en pedig foglalkozzunk azzal a kérdéssel, hogy a modell milyen bels szerkezetekkel valósítható meg (rendszerarchitektúra).

I.1.1. Az operációs rendszer és környezete
A rendszermodell felállításához a I.1-1. ábra legyen kiindulási alapunk, amelyik az operációs rendszer úgynevezett kontextdiagramját mutatja be. A kontextdiagram alapján az operációs rendszer f környezeti kapcsolatai: · a kezel k (operátorok) · az alkalmazói programok · a számítógéphardver Az operációs rendszernek m ködése során ezek felé kell csatlakozási felületet nyújtania, és alapvet funkcióit a környezeti kapcsolatokban mutatott viselkedésével jellemezhetjük.

I.1. Rendszermodell és rendszerarchitektúra

2

K EZEL K K EZEL K

- -egyszer felhasználó egyszer felhasználó - -program fejleszt program fejleszt - -rendszerm enedzser rendszerm enedzser

A LK A LM AZÁ SO K A LK A LM A ZÁS O K

O PER Á C IÓ S O PER Á C IÓ S R EN D SZER R EN D SZER

H A RD V ER HA R D VER

- -processzor processzor - -tár tár - -be/kiviteli rendszer be/kiviteli rendszer - -be/kiviteli eszközök be/kiviteli eszközök

I.1-1. ábra. Az operációs rendszer kontextdiagramja

I.1.2. Funkciók
Mint korábban megállapítottuk, az operációs rendszernek két alapvet feladata van: · kényelmesen használható virtuális gép megvalósítása a kezel k és az alkalmazások felé · a számítógép-hardver hatékony és biztonságos m ködtetése A kényelmesen használható virtuális gép azt jelenti, hogy a hardver részleteit el kell fedni, a felhasználók számára áttekinthet modelleket kell kínálni, és azokat meg kell valósítani a fizikai rendszeren. Másként fogalmazva a fizikai rendszer kényelmes és célszer absztrakcióit kell implementálni az adott számítógép-konfiguráción. Ilyen absztrakciók például az önálló logikai processzorral és tárterülettel rendelkez , egymástól védett, de egymással kommunikálni tudó, párhuzamosan végrehajtódó folyamatok, a fizikai címtartomány méretét meghaladó címezhet tártartomány (virtuális tár), a fájl és a katalogizált fájlrendszer, ahol megoldott a biztonságos és védett adattárolás, stb.

A számítógép-hardver hatékony m ködtetése azt jelenti, hogy az alkalmazások futtatását úgy kell koordinálni, hogy a fizikai eszközök kihasználtsága minél jobb legyen, és a felhasználó által el írt prioritások teljesüljenek. A hatékonyság követelményét ugyanis elméletileg megfogalmazhatjuk egy optimum-kritériumként, ahol a célfüggvényben különböz min ségi

I.1. Rendszermodell és rendszerarchitektúra

3

paraméterek

szerepelhetnek

(pl.

processzor-kihasználás,

válaszid ,

átfutási

id ,

átereszt képesség stb., illetve ezen paraméterek statisztikai jellemz i). Az egyes paraméterek jelent sége rendszerenként különböz megjelenhetnek. A biztonságos m ködtetés pedig azt jelenti, hogy az operációs rendszer korrekt megoldásokat tartalmaz a megosztott er forrás-használatból ered problémákra (pl. közös fizikai processzor használata, a fizikai tár kiosztása, ugyanazon készülékre indított több, egyidej be-kiviteli m velet végrehajtása), valamint elfedi a tranziens hardverhibákat (pl. hibat r , hibajavító kódolás adattárolások, adatátvitelek esetén). lehet, illetve egyéb, speciális szempontok is

I.1.3. Csatlakozási felületek
A következ kben az operációs rendszer kapcsolódási felületeit jellemezzük. I.1.3.1. Kezel i (operátori) felület (Operator Interface, User Interface) A kezel i felület ember-gép kapcsolat. Arra szolgál, hogy az operációs rendszer ezen keresztül m ködtethet legyen, illetve m ködésér l a felhasználó tájékoztatást kapjon. A kezel i felület kialakításának tipikus fizikai eszköze a képerny t, billenty zetet és esetleg egeret (grafikus pozicionáló eszköz) tartalmazó munkahely. Kevésbé elterjedten - egyel re f ként speciális rendszerekben - már az operációs rendszerek kezel i felületén is találunk egyéb eszközöket, például hang be- és kimeneteket.

A rendszert kezel

felhasználók a következ

jellegzetes csoportokra oszthatók: egyszer

felhasználókra, alkalmazásfejleszt kre, és rendszermenedzserekre.

Az egyszer

felhasználók jellegzetes tevékenysége, hogy programokat (alkalmazásokat)

futtatnak, amelyek segítségével szokásos napi feladataikat látják el (pl. irodában dokumentumkezelés, táblázatszerkesztés, automatizált üzemben diszpécser-feladatok stb.). Az egyszer felhasználók jelent s része els sorban az alkalmazásokat és azok kezel i felületét használja, az operációs rendszerrel közvetlenül alig kerül kapcsolatba. Számukra az operációs rendszerben a f szerepet a katalogizáltan nyilvántartott fájlok játsszák, amelyek között vannak futtatható programokat tartalmazó, végrehajtható fájlok, továbbá vannak az alkalmazások által kezelt, adatokat tároló fájlok. Érdekli ket, hogy tudnak-e futtatni

I.1. Rendszermodell és rendszerarchitektúra

4

egyidej leg több alkalmazást, és ezek az alkalmazások tudnak-e információt cserélni egymással. Az egyszer felhasználó elvár bizonyos megbízhatóságot, védelmet és biztonságot a rendszert l, ennek érdekében tudomásul veszi, hogy bejelentkezés, azonosítás, és néhány egyéb rendszabály betartása szükséges. A rendszabályokat azonban hajlamos lazán és fegyelmezetlenül kezelni, amint azok számára a legkisebb kényelmetlenséget okozzák.

Az egyszer

felhasználó számára tehát az operációs rendszer olyan gép, amelyik egy

felhasználói körnek lehet séget ad adat- és programfájlok védett és rendezett tárolására, valamint alkalmazások futtatására. A rendszer legfontosabb szolgáltatásai: bejelentkezés, a rendelkezésre álló alkalmazások áttekintése, alkalmazások indítása, esetleges együttm ködése és leállítása, fájlm veletek (másolás, mozgatás, törlés, tartalomfügg feldolgozás).

Az alkalmazásfejleszt k részletes ismeretekkel rendelkeznek az operációs rendszer alkalmazói programok számára nyújtott szolgáltatásairól és bizonyos mélységig ismerik az operációs rendszer bels m ködését. Ezeket az ismereteiket a programkészítésben használják fel. Mint kezel k, az általuk készített alkalmazások tesztelésével, teljesítményelemzésével is foglalkoznak. Egyes operációs rendszerek nyújtanak ehhez eszközöket (pl. debug módú futtatás), gyakoribb eset azonban, hogy a fejlesztést támogató speciális alkalmazás (pl. PASCAL, C, C++ nyelvek integrált fejleszt i környezete) tartalmazza a megfelel szolgáltatásokat. Mindenképpen szükségesek azonban olyan eszközök, amelyek az egyes programok és a hozzájuk tartozó er források (memóriaterület, processzor, perifériák) aktuális állapotát, az er forrás-használatok id tartamát, az ezekre vonatkozó statisztikákat láthatóvá teszik. Ezek akkor is az operációs rendszer szolgáltatásaira támaszkodnak, ha a fejlesztést támogató alkalmazás teszi ket elérhet vé az alkalmazásfejleszt számára.

Az alkalmazásfejleszt számára tehát az operációs rendszer olyan gép, amelyik a programok számára meghívható eljárásokat biztosít, amivel · leveszi a válláról a hardver pontos és részletes ismeretének és programozásának terhét · lehet séget ad arra, hogy együttm köd programokkal oldjon meg egy feladatot · a programok együttm ködéséhez ellen rzött eszközöket ad · megszervezi a programok együttfutását és er forrás-használatát · megfigyelhet vé teszi a programok futása közben kialakuló rendszerállapotokat.

I.1. Rendszermodell és rendszerarchitektúra

5

Az alkalmazásfejleszt knek nyújtott szolgáltatások tehát már bizonyos mérték bepillantást engednek az operációs rendszer bels szerkezetébe, a futó programokhoz rendelt fizikai

eszközök állapotát is láthatóvá, esetleg közvetlenül módosíthatóvá teszik.

A rendszermenedzser feladata az operációs rendszer üzemeltetése, valamennyi ezzel kapcsolatos probléma megoldása. Ez magában foglalja egyrészt a rendszergenerálás feladatát, ami azt jelenti, hogy a rendszert a rendelkezésre álló hardverhez és az ellátandó feladatokhoz illesztett kiépítésben kell telepíteni. Másrészt adminisztrációs feladatokat, ami a rendszer felhasználóinak, a rendszerhez kapcsolódó alkalmazásoknak a nyilvántartását, jogosultságaik kiosztását, a rendszer üzemeltetési szabályainak, biztonsági el írásainak meghatározását, azok betartásának felügyeletét jelenti. Harmadrészt hangolási feladatokat, ami a hardver lehet ségeit, a tipikus alkalmazásokat és a rendszer statisztikáit figyelembe véve azoknak a rendszerparaméterek beállítását jelenti, amelyek az üzemeltetés hatékonyságát befolyásolják (pufferméretek, ütemezési és kiosztási algoritmusok stb.). Negyedrészt rendszerfelügyeletet takar, ami a zavartalan, folyamatos m ködés biztosítását, az esetleges rendellenességek észlelését, elhárítását, az ennek érdekében szükséges id szakos feladatok ellátását (karbantartások, mentések stb.) jelenti.
Megjegyzés: Panni megjegyzését nem tudom elolvasni.

A rendszermenedzser számára tehát az operációs rendszer olyan gép, amelyik a hardver adott célú hatékony alkalmazását segíti, és amelynek a hardverhez és a feladatokhoz illeszked , megfelel telepítése, behangolása, használatának adminisztrációs és általános üzemeltetési feladatai rá hárulnak. A rendszermenedzser részletes és alapos ismeretekkel rendelkezik mind az operációs rendszerr l, mind a környezetr l, és a feladatok ellátásához olyan beavatkozási lehet ségekre van szüksége, amilyen a többi felhasználónak nincs. Ezért a rendszermenedzser számára gyakran külön fizikai eszköz (rendszerkonzol) áll rendelkezésre.

A kezel i felület lehet szöveges vagy grafikus. A grafikus felületek könnyebben áttekinthet k, inkább nevezhet k felhasználóbarát megoldásnak. A szöveges felület el nye ezzel szemben, hogy a kezel távoli terminálról, kis sávszélesség összeköttetésen keresztül is m ködtetni tudja a rendszert, és könnyebben megvalósítható a készülékfüggetlenség.

I.1. Rendszermodell és rendszerarchitektúra

6

A szöveges kezel i felület lehet parancsnyelv (és általában egyben parancssor-orientált), vagy menürendszer (és általában egyben képerny -orientált). A menürendszer

felhasználóbarát, amennyiben mentesíti a kezel t a parancskészlet és gyakran igen bonyolult paraméterezés megtanulása alól. A parancsnyelv el nye ismét csak a készülékfüggetlenség könnyebb megvalósítása, továbbá a parancsok összef zésének lehet sége (ld. batch üzemmód).

A kezel i felületek általában interaktív m ködtetésre adnak lehet séget. A kezel

egy

beavatkozását a rendszer azonnali reakciója követi. Rákattintunk egy ikonra, kiválasztunk egy menüpontot, vagy begépelünk egy parancsot, mire a rendszer a megfelel m velet

végrehajtásával reagál. Általában a végrehajtás befejezését követ en fogad el a rendszer újabb kezel i beavatkozást, vagy parancsot (szinkron m ködés). Vannak rendszerek (a multiprogramozott, vagy multitaszk rendszerek általában ilyenek), amelyek megengedik, hogy az el z parancs befejez dése el tt újabb parancsot indíthassunk (aszinkron m ködés).

Gyakran hasznos, ha az operációs rendszernek szóló parancsokat egy parancssorozattá f zhetjük össze. Ezt a parancssorozatot tárolhatjuk például egy fájlban (batch-file, shellscript), és bármikor egyetlen parancsként végrehajtathatjuk a rendszerrel. Ilymódon tulajdonképpen az operációs rendszernek szóló programot állítottunk össze. Úgy is fogalmazhatunk, hogy az operációs rendszer a kezel számára ugyanúgy egy programozható gépnek látszik, mint a processzor a programozó számára.

Ugyanazon operációs rendszernek többféle kezel i felülete is lehet. Általában a parancsnyelv felület az alap, amire ráépülhetnek menürendszer , illetve grafikus felületek. A batch, illetve script készítésének lehet sége a parancsnyelv felületen van meg. Az interaktív, illetve a grafikus felületen ilyen "programok" például a WinWord-b l ismert tanítási (makrorögzítés) technikával lennének létrehozhatók, az operációs rendszereknél azonban ez nem terjedt el. I.1.3.2. Alkalmazási (programozói) felület (Application Interface, Program Interface) A számítógéprendszeren futó, adott feladatokat megoldó programok valamilyen programozási nyelven (FORTRAN, PASCAL, C, C++ stb.) íródnak. El készítési id ben (fordítás,

I.1. Rendszermodell és rendszerarchitektúra

7

szerkesztés) történik meg a program átalakítása a processzor által végrehajtható formára (gépi kód). A program készít je általában feltételezi, hogy a program valamilyen operációs rendszer felügyelete alatt fog futni, az operációs rendszer pedig kész, el re programozott megoldásokat tartalmaz például a be/kiviteli m veletekre, az id kezelésre, a dinamikus tárigények kielégítésére, a programok együttm ködésének és információcseréjének megoldására. Ezek a m veletek a szubrutinhíváshoz hasonló, de attól néhány tekintetben különböz módon,

rendszerhívásokkal hajthatók végre. A futtatható program tehát nem zárt abban a tekintetben, hogy saját maga tartalmazza valamennyi, a futása során végrehajtódó gépi utasítását, hanem rendszerhívó utasításokat is tartalmaz, amelyek hatására az operációs rendszer lép m ködésbe, az operációs rendszer részét képez program kezd futni. Az operációs rendszer által végrehajtott m veletet követ en - el bb-utóbb, esetenként jelent s kitér kkel - általában a hívást követ utasítással folytatódik a hívó program végrehajtása.

Maga a rendszerhívás a legtöbb operációs rendszer és a legtöbb processzor esetén egy programozott megszakítás el idézésével történik meg. A szubrutinhívástól - amelyre a legtöbb processzor külön gépi utasítást tartalmaz - abban tér el, hogy végrehajtásakor a visszatérési cím mentése és vezérlésátadás mellett a processzor m ködési módját (védelmi állapotát) is meg kell változtatni, felhasználói (user) módból a privilegizált utasítások végrehajtását is megenged rendszer (system) módba kell átkapcsolni. A rendszerhívás programozott megszakítással történ megoldása amellett, hogy megoldja a m ködési mód átváltását, a lehet legnagyobb mértékben függetleníti is egymástól a hívó programot és az operációs rendszert. Az operációs rendszerb l a hívó csak egyetlen belépési pontot ismer. Információcsere a hívó és az operációs rendszer között csak paraméterátadással történik (általában még a végrehajtandó m veletet is átadott paraméter jelöli ki).

Az alkalmazások számára az operációs rendszer egy olyan gép, amelyik kiterjeszti a processzor utasításkészletét. A számítógép és az operációs rendszer együtt egy kiterjesztett utasításkészlet , új gépet alkot, amelyik a processzor utasításkészletén kívül tartalmazza az operációs rendszer m veleteit is. Ez a kiterjesztett gép a futtatható programok rendelkezésére áll.

I.1. Rendszermodell és rendszerarchitektúra

8

Természetesen a programok írásakor és fordításakor is számíthatunk erre a kiterjesztett utasításkészletre, noha a használt programnyelv az operációs rendszer felületét gyakran elfedi. A programozó számára a programozási nyelv - hacsak nem assembly nyelv programozásra gondolunk - eleve magasabb szint m veleteket enged meg, mint a processzorok gépi nyelve. Ezek a m veletek vagy fordításkor fejt dnek ki gépi utasítássorozattá, vagy a nyelv úgynevezett futtató rendszere tartalmazza a komplex m veleteket megvalósító

eljáráskönyvtárat, és

a fordító a komplex m veletet megfelel en paraméterezett

szubrutinhívássá fordítja. Az operációs rendszert tehát a nyelvi szint elfedi a programozó el l. A rendszerhívások nem közvetlen nyelvi utasítások formájában használhatók, hanem a nyelv által megengedett - általában eljáráskönyvtárakkal megvalósított - komplex m veletekbe épülnek be. A rendszerhívást még akkor is be kell illeszteni a nyelv szintaxisába, ha a nyelvi utasítás pontosan az adott rendszerhívás megfelel paraméterekkel történ meghívását

eredményezi, és semmivel sem többet. Ezt a szintet ragadja meg például a POSIX szabvány, amelyik az operációs rendszer programozói felületét a C nyelvi elérés megadásával definiálja.

Az alkalmazási felület nyelvi szint megragadása abból a szempontból is el nyös, hogy a felület ezzel processzorfüggetlenné válik. Az elterjedt programnyelvek, különösen a C nyelv, fordítóprogramjai sokféle processzorra tudnak kódot generálni. A C nyelv forrásprogram így hordozható, hiszen a rendszerhívásokat is a megfelel generálja a fordító. processzor figyelembevételével

I.1.3.3. Hardver felület (Hardware Interface) A hardver fejl désének köszönhet en egyre újabb, nagyobb teljesítmény processzorok,

be/kiviteli eszközök, továbbá összekapcsolási módok, architektúrák alakulnak ki. Az operációs rendszerek m ködtetik a hardvert, igyekeznek hatékonyan kihasználni a hardver lehet ségeit. Ebben a pontban csak a kapcsolódási felület jellegét tárgyaljuk, azonban az operációs rendszer és a hardver szoros és összetett kapcsolatrendszere miatt külön pontot szánunk a számítógép-architektúrák tárgyalására.

Az operációs rendszer és a hardver kapcsolódási felülete több ponton valósul meg. · Az operációs rendszer maga is program, ami az adott számítógéprendszeren fut, tehát a processzor és az architektúra lehet ségei (utasításkészlet, regiszterkészlet, a

I.1. Rendszermodell és rendszerarchitektúra

9

rendszerhívás megvalósítása, megszakítási rendszer, címzési módok, be/kiviteli rendszer) azok, amiket az operációs rendszer felhasználhat. · Az operációs rendszer kezeli a hardver eszközöket és egyben gazdálkodási feladatokat is ellát. Az alkalmazások számára tárat, processzorhasználatot, lemezterületet biztosít, végrehajtja az alkalmazások által kezdeményezett be/kiviteli m veleteket. Az architektúra ismerete beépül az operációs rendszert alkotó programokba, meghatározza, hogy az operációs rendszer milyen er forrás-kezelési és -gazdálkodási feladatokkal foglalkozzon, és ezek során milyen megoldások használata célszer . Hatékony géphasználat ugyanis nyilvánvalóan csak a m ködtetett hardver tulajdonságainak ismeretében érhet el. · Az operációs rendszernek kezelnie kell a rendszerhez kapcsolódó be/kiviteli eszközöket, amelyek igen heterogén csoportokból kerülhetnek ki, és a rendszer élettartama során új eszközök beillesztésére is sor kerülhet.
Megjegyzés: ??

Az els ként említett kapcsolódási pont egyszer en azt jelenti, hogy az operációs rendszernek az adott processzoron, illetve rendszerarchitektúrán kell futnia, ezekhez illeszkednie kell a m köd képesség érdekében. Az elterjedten alkalmazott operációs rendszereknek ezért különkülön verziójuk van a különböz processzorokra. Egy-egy géptípus különböz kiépítés

konfigurációihoz pedig telepítéskor illeszthet k az operációs rendszerek (telepítés, rendszergenerálás). A tervez k szokásos törekvése, hogy az operációs rendszer processzortól, illetve kiépítést l függ kódrészeit lehet leg külön modulokba helyezzék (ez a UNIX és a Windows NT esetén is megfigyelhet ).

A második kapcsolódási pont tekintetében is a fenti alapelv érvényesül. Kialakult a kezelend er források egy egységes absztrakciója (pl. tár, processzorid , lemezterületek, fájlok stb.), amelyek gyakorlatilag valamennyi rendszer esetén használhatók. Ezek kezelésének algoritmusai is jelent s részben közösek lehetnek. Az algoritmusoknak azonban vannak hardverfügg részei (pl. tárallokáció a lehetséges címzési módokhoz igazítva, környezetváltás a konkrét regiszterkészlet figyelembevételével), amelyek ugyancsak a hardverfügg modulokba kerülhetnek.

I.1. Rendszermodell és rendszerarchitektúra

10

A harmadik kapcsolódási pont a be/kiviteli eszközök csatlakoztatási felülete. Míg egy rendszer életében a processzor- és architektúra-váltás meglehet sen ritka, készülékcsere, vagy új készülék beiktatása sokkal gyakoribb. Egy új eszköz hozzákapcsolása a rendszerhez egyrészt megfelel hardver csatlakoztatás, másrészt megfelel kezel program (driver)

segítségével történik. A készülékek választéka gyakorlatilag korlátlan, minden készülék rendelkezhet olyan specialitásokkal, amelyek csak rá jellemz ek. Az operációs rendszert gyakorlatilag lehetetlen felkészíteni arra, hogy minden elképzelhet készüléket tudjon kezelni. Ezért a készülékeknek is kialakult egy egységes absztrakciója, aminek lényege, hogy a rendszer a készülékeket azonosítani tudja, és egységes módon tud velük párbeszédet folytatni. A párbeszéd a készülékkezel készülékkezel programokon (device driver) keresztül valósul meg. A

programok tehát az operációs rendszer többi részéhez egységes felületen

csatlakoznak, de ismerik a készülék részletes m ködését, és az operációs rendszer egységes felületén kapott parancsokat a specialitások ismeretében hajtatják végre a konkrét eszközökön. (Például egy mágneslemez egység különböz módon, különböz

vezérl egységeken keresztül kapcsolódhat a rendszerhez. Az operációs rendszer számára ez az egység adatblokkok sorozatát tároló készülék, amire kiadható például egy "olvass blokkot" parancs. A készülékkezel program ismeri a vezérl és a lemezegység közötti

munkamegosztást, tudja, hogy ha nincs bekapcsolva a lemezegység motorja, akkor azt el ször neki kell-e elindítania és aztán megvárnia a megfelel fordulatszám elérését, majd

elvégeztetnie az olvasást, avagy ezeket a vezérl egység saját hatáskörében elintézi, és elég egyszer en továbbadni az olvasás parancsot a vezérl egységnek.)

Érdekes "munkamegosztás" van az operációs rendszerek szállítói és a készülékgyártók között. Az operációs rendszer szállítója általában mellékeli a nagyobb készülékgyártók tipikus eszközeihez a kezel programokat. Természetesen nem tud felkészülni minden készülékre. Más oldalról a készülékszállítók mellékelik az eszközhöz tartozó kezel programokat különböz operációs rendszerekhez.

Összességében tehát a be/kiviteli készülékek csatlakoztatása kett s szabványosítást igényel, egyrészt egy szabványos hardver csatlakoztatást, másrészt a készülékkezel program számára egy szabványos szoftver csatlakoztatást. Az operációs rendszer kezel i felülete pedig

I.1. Rendszermodell és rendszerarchitektúra

11

megfelel

eljárást kínál a rendszermenedzser számára a készülék és a kezel

program

csatlakoztatására.

I.1.4. Számítógép-architektúrák
A mikrokontrollerekt l a szuperszámítógépekig és elosztott számítási rendszerekig a különböz méret , teljesítmény és szerkezet hardverek széles skálája az, amit operációs rendszerrel kell m ködtetni. Meglehet sen nehéz megtalálni ezekben a rendszerekben azokat a közös vonásokat, amelyek meghatározzák, hogy mit kell tennie az operációs rendszernek a hatékony m ködtetés érdekében.

Illusztrációként három jellegzetes hardver-felépítést mutatunk be, egy egyszer mikrogépet, egy tipikus személyi számítógépet, valamint egy szuperszámítógépet.

I.1.4.1. Egyszer mikrogép Az egyszer mikroszámítógép felépítése a I.1-2. ábra mutatja.

Memória

soros / párhuzamos portok

Rendszersín

CPU

DMA vezérl

Lemezvezérl

diszk

I.1-2. ábra Egyszer mikrogép architektúrája

I.1. Rendszermodell és rendszerarchitektúra

12

Az egyszer mikrogép egyetlen sínnel rendelkezik, amelyet mind a CPU - memória, mind a B/K forgalom terhel. A CPU egyben a sínvezérl szerepét is betölti. Esetleges kezel szervek a soros / párhuzamos portokra csatlakoztathatók. A DMA vezérl képes önállóan szervezni a lemez - memória közötti blokkátvitelt, az adatforgalom azonban a rendszersínt veszi igénybe. A rendszersín használatának szervezésére a DMA vezérl és a CPU között külön jelforgalom van. A sín lehet séget ad megszakításkérések továbbítására is.

I.1.4.2. Jellegzetes személyi számítógép

Egy jellegzetes személyi számítógép architektúráját mutatja be a I.1-3. ábra.

diszk CPU gyorsítótár (cache) memória memória- / sínvezérl grafikus vezérl SCSI vezérl monitor SCSI sín diszk

PCI sín

IDE vezérl

b vít sín vezérl

b vít sín

diszk

diszk

soros / párhuzamos portok

billenty zet

I.1-3. ábra Személyi számítógép architektúrája

Az architektúra lényegesen bonyolultabb, és olyan megoldásokat tartalmaz, amelyeket korábban csak a nagyszámítógépekben alkalmaztak. A gyorsítótár megfelel találati arány esetén lehet vé teszi, hogy a memória a CPU utasítás-végrehajtásával egyidej leg a B/K adatforgalom számára is rendelkezésre álljon. A grafikus vezérl saját videomemóriával és

I.1. Rendszermodell és rendszerarchitektúra

13

intelligens processzorral rendelkezhet, aminek hatása, hogy a grafikus m veletek nem vesznek igénybe nagy sávszélességet a PCI sínen. A b vít sín általában lassabb küls készülékek csatlakoztatására ad lehet séget, külön vezérl hajtja meg, biztosítva befelé a megfelel hatékonyságú sínfoglalást. Természetesen a sín megszakításkéréseket is tud
Megjegyzés: Több magyarázat kellene

továbbítani. Két további vezérl (IDE és SCSI) ad lehet séget jellegzetesen lemezegységek csatlakoztatására, ugyancsak autonóm blokkátviteli képességekkel.

I.1.4.3. Szuperszámítógép A I.1-4. ábra a Convex Exemplar számítógépcsalád bels felépítését mutatja, amelyik

lehet vé teszi, hogy 128 processzor (HP PA-RISC típusúak) hatékony együttm ködésével alakuljon ki igen nagy teljesítmény számítási rendszer. Az építkezés hierarchikus, kett s processzoregységekb l négy építhet egy hipernódba. Minden CPU saját gyorsító utasítás- és adattárral (cache) rendelkezik. A hipernódhoz egy B/K alrendszer is tartozik. A crossbar kapcsolóhálózat a processzorpárok, valamint a B/K alrendszer hatékony és átlapolt kapcsolatát teszi lehet vé a négy memóriablokkal. A memóriablokkok tartalmazzák a hipernód saját adatterületét, a közös tár egy adatterületét, valamint a hipernódok kapcsolatának hatékonyságát fokozó bels hálózati gyorsítótárak területét. A hipernódokat négy SCI (Scalable Coherent Interface) szabvány szerint kialakított gy r kapcsolja össze. A rendszerben valamennyi processzor számára rendelkezésre áll a memóriában egy közös címtartomány, amely valójában egy elosztott, koherens gyorsítótárral támogatott memóriával valósul meg.

I.1. Rendszermodell és rendszerarchitektúra

14

CPU 1

CPU 2

CPU 3

CPU 4

CPU 5

CPU 6

CPU 7

CPU 8

2MB 2MB gyorsító gyorsító tár tár

2MB 2MB gyorsító gyorsító tár tár

2MB 2MB gyorsító gyorsító tár tár

2MB 2MB gyorsító gyorsító tár tár

Ágens

Ágens

Ágens

Ágens B/K alrendszer gyorsítótár / memória vezérl 1. hipernód

5x5 crossbar (1,25 GB/s)

gyorsítótár / memória vezérl

gyorsítótár / memória vezérl

gyorsítótár / memória vezérl

512 MB memória

512 MB memória

512 MB memória

512 MB memória

2. hipernód : : 16. hipernód

Skálázható, koherens interfész gy r k (600 MB/s)

I.1-4. ábra Szuperszámítógép architektúra

Ha általános következtetéseket akarunk levonni a bemutatott architektúrákból, azt állapíthatjuk meg, hogy egy bizonyos számítási teljesítmény alatt az architektúrák megtartják a gépi utasításkészlet szintjén a Neumann modell szerinti szekvenciális utasítás-végrehajtást, de legalábbis ennek a látszatát, és ennek, valamint az ezzel átlapolódó B/K m veleteknek a támogatására adnak egyre hatékonyabb eszközöket. A valódi m ködés elosztottá és többszálúvá válik, azonban ez a programozó el l rejtve marad. A nagyobb teljesítménykategóriákban már a gépi utasítások szekvenciális végrehajtásának látszata sem marad meg, a magasabb (nyelvi, operációs rendszer) szint fogalmak hatékony megvalósítása a cél. A szuperszámítógépek egyik alkalmazási stílusa, hogy a magasszint nyelveken íródott programokban a fordítók megkeresik a párhuzamosítható m veleteket (pl. vektor- és mátrixm veletek) és az adott hardverarchitektúrán hatékonyan futó kódot

I.1. Rendszermodell és rendszerarchitektúra

15

generálnak. A másik alkalmazási stílus a m velet-végrehajtás párhuzamosítását a programozó kezébe adja és speciális operációs rendszerekkel és programozási nyelvekkel támogatja.

I.1.5. Bels szerkezet
Az operációs rendszerek meglehet sen nagy és bonyolult rendszerek. Létrehozásuk során mai szemmel - a nagy és bonyolult rendszerek valamilyen fejlesztési módszertanát célszer alkalmazni, amelyek lényeges alapelve a rendszer részekre bontása (dekompozíció), és az általánosítás, azaz a részletek elrejtése (absztrakció). A módszeres fejlesztés eredményeként általában egy jól strukturált (áttekinthet , a feladat fogalomrendszeréhez igazodó) rendszer jön létre. Egy zavaró tényez rendszerek futási idej azonban nem hagyható figyelmen kívül: az operációs

hatékonysága (minél kisebb tár és minél kevesebb processzorid

felhasználása a feladatok teljesítéséhez) fontos szempont (még ma, a kissé indokolatlanul, felfokozott teljesítmény- és tárigények korában is). A tiszta struktúra és az adott esetre vonatkozó maximális hatékonyság pedig általában ellentmondó követelmények. Említésre méltó, hogy a fejlesztési módszertanokra vonatkozó igény (és a szoftverkrízis tudatosodása) jelent s részben a korai multiprogramozott operációs rendszerek fejlesztési problémáinak köszönhet . (Különösen nagy szerepe volt a legendás IBM 360 sorozatra készült, univerzális, OS 360 operációs rendszer hibáinak.) Ezek a rendszerek monolitikus szerkezet ek voltak, azaz egységes rendez elv szerinti bels struktúrájuk nem ismerhet fel.

A kés bbi rendszerekben általában felismerhet

a strukturált programozási szemlélet

eredményeként kialakult rétegszerkezet, illetve a moduláris programozási elvek szerinti modulszerkezet. Napjainkra a hordozhatóság és a hardver lehet ségeinek hatékony kihasználása vált a bels szerkezet kialakításának f szempontjává. I.1.5.1. Rétegek és modulok A strukturált programozás alapelveinek következetes betartása (eljárásabsztrakción alapuló lépésenkénti finomítás) rétegszerkezet programrendszert eredményez. A rétegek

hierarchikusan egymásra épülnek. Minden réteg úgy fogható fel, hogy az alatta lév réteget mint virtuális gépet - használva egy bonyolultabb virtuális gépet valósít meg a felette

I.1. Rendszermodell és rendszerarchitektúra

16

elhelyezked réteg számára. Ebb l következik, hogy minden réteg csak a közvetlen alatta elhelyezked réteg "utasításkészletét" használhatja.

A moduláris programozás dekompozíción alapuló megközelítése szerint a nagy programokat szét kell vágni külön kezelhet részekre, modulokra. A modulok belseje a külvilág (többi modul) számára rejtett, a modulból csak az általa mutatott csatlakozási felület érhet el más modulok számára (interface). A modulokat lehet leg úgy kell kialakítani, hogy a közöttük lév csatolás minimális, a modul összetartó ereje (kohézió) pedig maximális legyen.

Tapasztalatok szerint a maximális kohéziót és minimális csatolást egy-egy komplex adatszerkezetet és a rajta végezhet m veleteket összefogó modul eredményezi, amelyik

eljárás-interfésszel és paraméterátadással tart kapcsolatot más modulokkal. Lényegében a ma legelterjedtebb objektumorientált dekompozíció is ezen az elven alapul. Mindemellett más, gyakorlati szempontok indokolhatják a modulok más elvek szerint történ kialakítását (pl. a rétegszerkezet mentén történ modulok kialakítása stb.). modularizálás, adatmodulok, vezérl modulok, interfész-

Illusztrációként bemutatjuk a THE és a VENUS operációs rendszerek rétegszerkezetét (I.1-5. ábra). A THE operációs rendszert (els sorban kötegelt feldolgozásra) E.W. Dijkstra (a strukturált programozás és a szemafor atyja) és munkatársai fejlesztették ki és publikálták 1968-ban. 1970-ben Brinch Hansen javasolta els k között a rendszermag (kernel, nucleus) kialakítását az operációs rendszer alapfunkcióinak megvalósítására. A két munka nyomán fejlesztették ki Liskov és munkatársai az inkább id osztásos üzemmódra szánt VENUS operációs rendszert, amelynek alsó öt rétegét mikroprogramozottan valósították meg (1972).

6. réteg 5. réteg 4. réteg 3. réteg 2. réteg 1. réteg 0. réteg felhasználói programok B/K pufferelés operátori konzol kezelése tárkezelés CPU-ütemezés hardver 5. réteg 4. réteg 3. réteg 2. réteg 1. réteg 0. réteg

felhasználói programok készülékkezelés és ütemezés virtuális tár B/K csatornák CPU-ütemezés parancsértelmez hardver

A THE operációs rendszer rétegei

A VENUS operációs rendszer rétegei

I.1-5. ábra Nevezetes operációs rendszerek rétegszerkezete A rétegszerkezet kialakítása messze nem egyértelm , hiszen például a háttértárat kezel program maga is hasonlóan m ködhet, mint egy felhasználói program, mivel m ködése során várakozásokra kerülhet sor. Ezért indokolt t a CPU-ütemez réteg fölé helyezni. Ugyanakkor a CPU-ütemez bonyolultabb rendszerekben dönthet úgy, hogy egy programot kisöpör a memóriából háttértárra, amihez szüksége van a háttértár-kezel szolgáltatásaira. Ez a

szempont éppen fordított réteghierarchiát indokolna. Úgy is fogalmazhatnánk, hogy réteghierarchia és az ésszer , funkcionális modulszerkezet ortogonálisan alakul ki. A rétegszerkezet másik problémája, hogy a szigorú hierarchia betartása sok üresjáratot okoz. Egy mélyebb rétegben megvalósított szolgáltatás használata ugyanis több rétegen át érdemi funkció nélkül végrehajtott eljáráshívásokat és paraméterátadásokat eredményez, ami rossz hatékonyságra vezet.

A réteges szerkezet problémái miatt a kés bbi operációs rendszerek már nem törekedtek tiszta rétegszerkezetre, hanem kevés réteget és inkább több funkcionális modult alakítottak ki. I.1.5.2. Tipikus modulok Az operációs rendszerek feladataiból adódóan számos rendszerben a tipikus funkcióknak megfelel modulszerkezetet találunk. A szokásos alapvet funkciócsoportok a következ k: · Folyamatkezelés · Tárkezelés · Fájlkezelés · Be/kivitel kezelése

I.1. Rendszermodell és rendszerarchitektúra

18

· Háttértár kezelése · Hálózatkezelés · Védelmi és biztonsági rendszer · Parancsértelmezés · Felhasználóbarát kezel i felületek A fenti funkcionális modulok megjelenése mellett a rétegszerkezet abban nyilvánul meg, hogy · a hardverfügg részek egy alsó, hardverközeli rétegbe kerülnek · az operációs rendszer alapfunkciói a rendszermagban (kernel) valósulnak meg, amely egyre inkább csak a minimálisan szükséges funkciókat tartalmazza (mikrokernel) · a feltétlen szükségest meghaladó kényelmi szolgáltatások a felhasználói programokhoz hasonló rendszerprogramokba, (rendszerfolyamatokba, alrendszerekbe) kerülnek · megjelenik a felhasználói programokból érkez rendszerhívások fogadó felületét megvalósító réteg

Illusztrációként bemutatjuk a UNIX rendszerek és az OS/2 operációs rendszer bels szerkezetét, de a fentiekhez hasonló tendencia figyelhet egymást követ verzióin is (I.1-6. ábra).
Felhasználó Felhasználó Felhasználó Alkalmazás Alkalmazás Alkalmazás

meg a Windows NT rendszer

Shell, parancsértelmez , rendszerkönyvtárak
rendszerhívási felület

Alkalmazások kapcsolódási felülete Alrendszer Alrendszer Alrendszer

Kernel
CPU TerminálFájlkezel ütemez kezel Blokkos B/K Virtuális Karakteres Lemez- és tár B/K Lapcsere Terminál- szalagmeghajtók kezel meghajtók hardver csatlakoztatási felület készülékkezel készülékkezel készülékkezel

Kernel
- memóriakezelés - taszk-kezelés - készülékkezelés

készülékkezel

készülékkezel

készülékkezel

UNIX rétegek

OS/2 rétegek

I.1-6. ábra A UNIX és az OS/2 rétegszerkezete

I.1. Rendszermodell és rendszerarchitektúra

19

I.1.5.3. Virtuális hardver A kernel-koncepció lényege, hogy a felhasználói- és a rendszerprogramok számára a processzor utasításkészletének kiterjesztésével a kernel egy virtuális gépet jelenít meg. Mind a felhasználói, mind a rendszerprogramok futásuk során tehát egyrészt a processzor utasításkészletét (eltekintve a privilegizált utasításoktól), másrészt a kernel által nyújtott, rendszerhívással elérhet m veleteket használhatják. A rendszerben egyetlen kernel és több aktív program van jelen, a programok tehát mind a valódi processzort, mind a kernelt közösen, megosztottan használják. Ez azt jelenti, hogy nem csak a valódi processzort, hanem a kernelt is multiprogramozottan kell használni, azaz a processzor állapotának elmentéséhez hasonlóan a kernel állapotát is menteni kell, amikor egyik programról a másik futtatására vált át a rendszer.

Az IBM kutatóinak ötlete volt, hogy a kernel alatt elhelyezked

rétegbe olyan funkció

kerüljön, amelyik egyszer en a fizikai eszközök megosztott használatára ad lehet séget, nem kiterjesztett, hanem pontosan a fizikai processzorral és eszközökkel azonos felületen. Így minden felhasználó egy saját virtuális hardvert lát, amelyen elvileg tetsz leges kernelt, operációs rendszert futtathat (általában egyfelhasználós, interaktív üzemmódban) (I.1-7. ábra). A megoldást el ször az IBM 360/67-es számítógépre dolgozták ki (1970), kereskedelmi forgalomba pedig az IBM VM/370 operációs rendszerben került (1979).

I.1. Rendszermodell és rendszerarchitektúra

20

Alkalmazás

Alkalmazás

Alkalmazás

Alkalmazás

Alkalmazás

Alkalmazás

Kernel Kernel

Kernel

Kernel

Virtuális hardver

Hardver

Hardver

Közös kernel

Virtuális hardver privát kernelekkel

I.1-7. ábra A virtuális hardvert megvalósító rendszer és a közös kernel

A virtuális hardver gondolatának továbbvitele napjainkban ismét népszer . A felhalmozódott szoftverkincs felhasználásának egyik problémája a hardver-kompatibilitás hiánya. Ezen is segíthet a virtuális hardver, vagy hardver-emuláció. Jellegzetes példák a Sun és DEC processzorain futó operációs rendszerek virtuális Intel CPU-ja, az Apple Macintosh virtuális Motorola 68000 processzora. A JAVA programok kompatibilitásának kulcsa ugyancsak a JVM (Java Virtual Machine) virtuális gép, amelyik bájtkód szinten definiált utasításkészletet képes végrehajtani.

Ebbe a sorba illeszkedik az MIT (Massachusetts Institute of Technology) kutatóinak exokernel koncepciója (1995), amelyik ugyancsak a legalsó szintre helyezi a hardver multiplexelésének feladatát, és az egyes felhasználóknak a kívánt hardver er forrásokhoz biztonságos, védett hozzáférést nyújt. Ez a szint azonban semmiféle további kiterjesztett funkciót nem valósít meg a hardverhez képest. I.1.5.4. Kliens-szerver szerkezet A kernel minimalizálása és a rendszerszolgáltatások rendszerprogramokkal történ megvalósítása a szerkezeti tisztaság és a hatékonyság jó kompromisszumának látszott. Találkozott ez a tendencia a hardver lehet ségeinek b vülésével, többek között azzal, hogy egyetlen rendszeren belül több processzor m ködik. Ez egyrészt több CPU-t jelenthet, másrészt speciális (aritmetikai, sínvezérl , készülékvezérl stb.) processzorokat. A

I.1. Rendszermodell és rendszerarchitektúra

21

multiprogramozás nyújtotta látszólagosan párhuzamos végrehajtással szemben a több processzor lehet séget ad a programok valóban párhuzamos végrehajtására. A

hardverfüggetlenségre való törekvés jegyében megn tt azoknak a modelleknek a jelent sége, amelyeket követve olyan programokat hozhatunk létre, amelyek változtatás nélkül, hatékonyan futtathatók akár egyetlen processzoron multiprogramozottan, akár több proceszoron, multiprocesszálással.

Ezeknek a követelményeknek megfelel a kliens-szerver modell. Lényege, hogy adott funkciókért egy program felel s, amelyik a funkciók ellátásához szükséges er forrásokat is kezeli. Ennek a programnak (szolgáltató, szerver) a szerepe a többiek (ügyfél, kliens) kiszolgálása az adott funkciók tekintetében. Az ügyfél üzenetet küld a szolgáltatónak, ami tartalmazza a kért m veletet és a szükséges paramétereket, és megvárja a szolgáltató válaszát. A szolgáltató fogadja az ügyfelek kéréseit, elvégzi a kért m veleteket és az eredményekr l válaszüzenetben tájékoztatja az ügyfeleket.

Ragadjuk ki egy operációs rendszer néhány funkcióját, például a fájlkezelést, a folyamatkezelést és a felhasználóbarát kezel i felület nyújtását (pl. grafikus terminálon). Bízzuk ezeket a feladatokat egy-egy szolgáltató programra! Szükség esetén a szolgáltatók természetesen egymás szolgálatait is igénybe vehetik. Az így kialakuló szerkezetet a I.1-8. ábra mutatja. A rendszerben a kernel els dleges szerepe az üzenetek pontos és biztonságos közvetítése. A szolgáltatók változtatás nélkül m ködnek akkor is, ha a szerverek külön-külön processzoron futnak. Természetesen a kernelnek ilyenkor ismernie kell a szerepl k elhelyezkedését, és az üzenetközvetítés során használnia kell a processzorok közötti adatátvitel eszközeit.

Alkalmazások

Rendszerprogramok

Alkalmazás (ügyfél)

...

Alkalmazás (ügyfél)

...

Folyamatkezel (szolgáltató)

Fájlkezel (szolgáltató)

...

Terminálkezel (szolgáltató)

Kernel (végrehajtás rendszer módban)

I.1-8. ábra Kliens-szerver szerkezet rendszer

I.1. Rendszermodell és rendszerarchitektúra

22

I.1.6. M ködés
Ez a pont az operációs rendszerek m ködését, azaz jellegzetes bels vezérlési szerkezetét tárgyalja. A programokkal kapcsolatban a vezérlési szerkezet az egyes utasítások végrehajtási sorrendjének el írását jelenti. Arra keressük tehát a választ, hogy mikor mit csinál a program.

A hagyományos programok esetén megszoktuk, hogy az utasítások végrehajtása a processzor m ködésének megfelel en, sorosan történik, azaz egy utasítás befejezése után kezd dik a következ utasítás végrehajtása. A programnak van kezdete, ahonnan a végrehajtás

elkezd dik, és - esetleg adatfügg útvonalon - halad a program végéig. A processzort a program végrehajtásának menetéb l csak egy megszakításkérés elfogadása tudja

kizökkenteni. Ilyenkor a processzor úgy tér át automatikusan a megszakításhoz rendelt kiszolgáló program végrehajtására, hogy a megszakított programot kés bb folytatni tudja. A megszakítási rendszer célja és értelme az, hogy a rendszer valamilyen küls , esetleg bels történésre gyorsan tudjon reagálni.

Az operációs rendszer m ködésének vizsgálatakor legyen az a kiinduló állapotunk, hogy a CPU éppen egy felhasználói program utasításait hajtja végre. Az operációs rendszer ilyenkor nyugalomban van. Mi hozhatja m ködésbe? · A futó program rendszerhívást hajt végre. · A processzor küls megszakításkérést fogad el. · Hibamegszakítás (exception) következik be. Bár a rendszerhívás a hívó program szándéka szerinti vezérlésátadás, megvalósítása a legtöbb rendszeren programozott megszakítással történik. Így mondhatjuk, hogy az operációs rendszert mindig megszakítás hozza m ködésbe, azaz m ködését a megszakítást kiváltó események vezérlik. Az egyes pontokban tárgyalt megszakítások azonban néhány fontos tulajdonságban különböznek, ezért indokolt a külön csoportba sorolásuk.

Az operációs rendszernek van néhány olyan alapfunkciója, amelyik látszólag elemi, de m ködése nem korlátozódik egyetlen rendszerhívás, vagy megszakítás hatására végrehajtott

I.1. Rendszermodell és rendszerarchitektúra

23

utasítássorozatra, hanem vezérlési szerkezetében bonyolultabb megoldást igényel. Ezek közül a B/K m veletek és a kezel i parancsok végrehajtását, valamint az id mérést tárgyaljuk.

A m ködés két sajátos szakasza a rendszerindítás és rendszerleállás folyamata. Az operációs rendszer funkcióit általában "állandósult" állapotban tárgyaljuk, azonban mindennapi tapasztalatainkból is tudjuk, hogy mind az indítás, mind a korrekt leállítás olyan folyamat, amelynek során a rendszer speciális üzemállapotban m ködik, és ezek a m veletek elég id igényesek lehetnek. Röviden ezzel a kérdéssel is foglalkozunk. I.1.6.1. Rendszerhívások kezelése A rendszerhívás általában programozott megszakítást okoz. Hatására az adott processzor megszakítási rendszerének mechanizmusa szerint az operációs rendszer egy meghatározott belépési pontjára kerül a vezérlés. Az elvégzend m veletet, valamint annak paramétereit a rendszer konvenciói szerint átadott paraméterekkel jelöli ki a hívó program. Az operációs rendszer a m veletet kijelöl paraméter szerint elágazva végrehajtja a m veletet, majd az esetek többségében visszatér a hívó programhoz. Néhány esetben azonban nem a hívó programhoz való visszatérés történik. Ilyen esetek lehetnek: · a program befejez dését jelz rendszerhívás, amikor a program által használt er források felszabadíthatók, esetleg új program (pl. a job következ lépése) betöltése és indítása következhet · er forrás-igénylés (pl. munkaterület a tárban vagy lemezen, kizárólagos periféria-, vagy fájlhasználat stb.), amit a rendszer éppen nem tud kielégíteni, emiatt a hívónak várakoznia kell · várakozás másik program jelzésére vagy üzenetére, ami még nem érkezett meg, emiatt a hívónak várakoznia kell · adott id tartamú késleltetés, vagy adott id pontra való várakozás · újraütemezés kérése, azaz lemondás a futásról esetleges fontosabb feladatokat megoldó programok javára · B/K m velet indítása, aminek végrehajtása alatt a hívó várakozik

I.1. Rendszermodell és rendszerarchitektúra

24

Amikor egy rendszerhívás következtében a hívó program várakozásra kényszerül, az operációs rendszer meg rzi a program állapotát, de a várakozás idejére más program végrehajtásáról intézkedik. A hívás helyére való visszatérés tehát késleltetve lesz mindaddig, amíg a várt feltétel nem teljesül, és a rendszer úgy nem dönt, hogy ismét az adott programot futtatja. A hívó program számára a várakozás a legtöbb esetben nem jelent a szekvenciális végrehajtástól eltér m ködést, számára logikailag a várakozás mindössze annyit jelent, hogy a rendszerhívás "lassan" hajtódik végre (szinkron m velet). Néhány rendszer lehet vé tesz aszinkron rendszerhívásokat is, jellegzetesen a B/K m veletek, valamint a programok együttm ködését szervez m veletek esetén. Az aszinkron B/K

rendszerhívás a kért B/K m velet elindítása után visszatér a hívóhoz, a hívó program a B/K m velettel párhuzamosan folytatódhat, és külön rendszerhívás szolgál az átvitel

befejez désének lekérdezésére, illetve az arra való várakozásra. Más rendszerek arra adnak lehet séget, hogy egy program megadjon egy olyan belépési pontot a saját címterében, amelyikre a rendszer valamilyen esemény bekövetkezésekor (pl. B/K m velet befejez dése, másik program jelzésének megérkezése) adja át a vezérlést. Így a felhasználói program tulajdonképpen egy küls megszakításkezelés jelleg eseményre induló ágat, azaz egy

programrészt is tartalmaz, amelyik azonban természetesen

felhasználói módban fog végrehajtódni. A rendszerhívások hatására kialakuló jellegzetes vezérlési szálakat a I.1-9. ábra szemlélteti.

I.1. Rendszermodell és rendszerarchitektúra

25

Alkalmazás rendszerhívás

Operációs rendszer

pl. B/K indulj

Alkalmazás

rendszerhívás: indít visszatérés

Operációs rendszer

pl. B/K indulj pl. B/K vége megszakítás

pl. B/K vége megszakítás

rendszerhívás: vár

visszatérés

visszatérés

Szinkron rendszerhívás

Aszinkron rendszerhívás várakozással

Alkalmazás

rendszerhívás: indít visszatérés

Operációs rendszer

pl. B/K indulj

pl. B/K vége megszakítás

eseménykezel indítása

Aszinkron rendszerhívás eseménykezelés átvételével

I.1-9. ábra Vezérlési szálak különböz típusú rendszerhívások esetén

I.1.6.2. Be/kivitel végrehajtása A multiprogramozás a CPU kihasználásának javítását úgy éri el, hogy egy program B/K m veleteinek idején más programot futtat a processzoron. Természetesen a megvalósítás feltétele, hogy a hardver-architektúra adjon lehet séget a B/K m veletek és a programutasítások valódi párhuzamos végrehajtására (B/K vezérl egységek, pufferelés, megszakítási rendszer).

A B/K m veletekre rendszerhívások állnak rendelkezésre. Vizsgáljuk a szinkron rendszerhívások esetét, tehát a hívó program akkor folytatódik (a rendszerhívást követ utasításon), amikor a B/K m velet már befejez dött. A rendszerhívás hatására m ködésbe lép operációs rendszer a kapott paramétereknek megfelel en elindítja a B/K m veletet,

például úgy, hogy felprogramozza és elindítja a B/K készülék vezérl egységét. Ett l kezdve

I.1. Rendszermodell és rendszerarchitektúra

26

a B/K m velet az illesztési módnak megfelel

szervezésben (megszakításosan, DMA

használattal stb.) megy a maga útján. Az operációs rendszer megjegyzi, hogy az átvitel befejez désére a hívó program vár, majd választ egy másik futtatható programot, és a "visszatérés rendszerhívásból" m veletet úgy hajtja végre, hogy ez a kiválasztott program folytatódjon.

A B/K m velet befejez dését a B/K vezérl megszakításkéréssel jelzi. A megszakításkérés hatására ismét az operációs rendszer lép m ködésbe, észleli, hogy a B/K m velet befejez dött.
(Megjegyzés: ha a B/K m velet karakterenkénti, vagy bájtonkénti megszakítással zajlik, akkor az operációs rendszer - a készülékhez rendelt megszakítási rutin - karakterenként m ködésbe lép, és programozottan viszi át a következ karaktert a memória és a B/K készülék adatregisztere között. Ilyenkor az átvitel közben egyszer "visszatérés megszakításból" m velettel zárul az operációs rendszer aktuális futama. Ha a megszakítási rutin észleli, hogy vége az átvitelnek, azaz éppen az utolsó megszakításra reagált, akkor kell végrehajtani azokat a lépéseket, amelyeket pl. DMA szervezés esetén az egyetlen, átvitel végét jelz megszakítás kiszolgálásakor.)

Ez egyben azt jelenti, hogy a befejez dött B/K m veletre várakozó program folytatható, és ezt az operációs rendszer megjegyzi. Nem jelenti azonban azt, hogy a várakozó programot azonnal folytatni kell, hiszen a B/K megszakítás egy másik, futó programot szakított meg, a CPU tehát nem volt tétlen. Az, hogy végül mikor fog folytatódni a várakozó program, az operációs rendszer további döntését l függ.

Némi bonyodalmat okoz, hogy egy program, amelyik egy másik program B/K m veletével párhuzamosan éppen fut, elindíthat egy újabb B/K m veletet ugyanarra a készülékre. Ilyenkor a rendszerhívás végrehajtásakor az operációs rendszer nem tud azonnal intézkedni az átvitel indításáról, hiszen a készülék még foglalt, vezérl jének regiszterei még az el z átvitel adatait tárolják, átírásuk hibát okozna. A megoldás az, hogy az átvitel paramétereit meg kell jegyezni, a hívót ugyanúgy várakoztatni kell, mintha az átvitel azonnal indítható lett volna, és új futtatható programot kell választani. Az átvitel a megjegyzett paraméterekkel akkor indítható el, amikor a készülék felszabadul (ezt az operációs rendszer észleli az el z ekben elmondottak szerint). Továbbgondolva a lehet ségeket beláthatjuk, hogy a fenti ráindítás többszöröz dhet. Egy adott pillanatban tehát nem csak a CPU-ra várakozhat több program, hanem egy B/K

I.1. Rendszermodell és rendszerarchitektúra

27

készülékre is több átviteli kérelem. Az operációs rendszernek ezért a B/K készülékekre is várakozási sort kell szerveznie.

PROGRAMOK

CPU

OPERÁCIÓS RENDSZER

B/K HARDVER

Pi fut CALLSYS (B/K,B/K-leíró)

rendszerhívás

B/K leíró bef zése a készülék sorába

Pi rendszerhívása hajtódik végre

dolgozik a készülék? igen

nem

B/K indítása az els B/K-leíró szerint

Pi várakozó állapotba B/K m velet folyamatban

Új futó program választása (Pj) visszatérés

Pj fut Pi vár esetleg más programok futnak B/K vége megszakítás

Befejezett B/K-leíró kif zése a váró sorból

B/K-ra váró program (Pi) futtatható állapotba igen

Pi futtatható

Van még váró B/K kérelem a készülékre? nem

B/K indítása az els B/K-leíró szerint

Esetleg új futó program választása visszatérés Pj, esetleg új program fut

I.1-10. ábra Be/kivitel lefolyása multiprogramozott rendszerebn

I.1. Rendszermodell és rendszerarchitektúra

28

Egy B/K rendszerhívás végrehajtásának menete a fentiek szerint a következ képpen foglalható össze: · az operációs rendszer m ködésbe lép a rendszerhívás hatására, és a következ ket teszi: · a B/K kérelmet az indításhoz szükséges paraméterekkel a készülék várakozási sorába helyezi · ha a készülék szabad, elindítja a B/K végrehajtását · választ egy futtatható programot, és oda tér vissza · az operációs rendszer B/K megszakításokat fogad el, amelyekre reagálva: · B/K végét jelz megszakítás esetén futtathatóvá teszi a befejez dött B/K-ra várakozó programot · ha van várakozó B/K m velet a készülékre, elindítja a következ B/K m veletet · ütemezési stratégiájától függ en vagy új programot választ futásra, vagy visszatér a megszakított programra · a B/K rendszerhívást kiadó program akkor folytatódik, ha ismét futtathatóvá vált, és az operációs rendszer t választotta futtatásra. A folyamatot a I.1-10. ábra szemlélteti. I.1.6.3. Kezel i parancsok A kezel i felületen az operációs rendszernek szóló parancsok érkezhetnek, valamint a kezel nek szóló információk jelennek meg a rendszer állapotáról. A legegyszer bb kezel i felületet a parancsértelmez nyújtja, jellegzetesen interaktív, karakteres eszközökön

(terminálon). Egyfelhasználós, valamint interaktív, id osztásos rendszerekben az operációs rendszernek szóló parancsokat a felhasználó ugyanarról a terminálról adja, amelyik egyben az általa indított alkalmazásokkal való párbeszéd eszköze is. Ebben az esetben az operációs rendszerrel, illetve az alkalmazással folytatott dialógus elkülönítését meg kell oldani (id beli elkülönítés, képerny felosztása, ablakozás stb.)

Az egyszer parancsértelmez felépítését és m ködését a I.1-11. ábra mutatja.

I.1. Rendszermodell és rendszerarchitektúra

29

Parancssorszerkeszt Terminálkezel Parancsértelmez

Sorpuffer

I.1-11. ábra A parancsértelmez szerkezete

Az operációs rendszer m ködése közben a terminál billenty zetének megszakításkéréseit a terminálkezel fogadja, leolvassa a leütött billenty kódját, és átadja a parancssor-

szerkeszt nek, amelyik egy bels tárban gy jti és a képerny n visszajelzi a beírt szöveget. A sorszerkeszt egyszer javításokra (karakter visszatörlés, felülírás, beszúrás) lehet séget ad. A parancs összeállítását követ en egy érvényesít végjel (szokásosan ENTER) leütésével jelzi a kezel , hogy kéri a parancs végrehajtását. Ilyenkor a parancssor-szerkeszt átadja a bels tárat a parancsértelmez nek, amelyik elemzi a sort (megkeresi és elkülöníti a

paramétereket), és egy prioritási sorrend szerint megkísérli értelmezni és végrehajtatni a parancsot. A prioritás azt jelenti, hogy a parancsértelmez egy értelmezési sorrendet követ. Ha a parancs értelmes a rendszermag számára, akkor egy rendszerhívással elindítja a végrehajtást, ha nem, megkísérli rendszerprogramként értelmezni, ha így sem, akkor a parancsot egy alkalmazás nevének tekinti, és megpróbálja azt indítani. A parancs végrehajtásának befejez dése után a tárolt parancssor törl dik és ismét a parancssor-szerkeszt kezd m ködni.

Ez

a m ködés

igen

rugalmas

abban

a

tekintetben, hogy az

alkalmazások a

rendszerparancsokkal azonos módon hajtathatók végre, azaz a kezel i felületen az operációs rendszer kiterjesztésének t nnek.

A parancsvégrehajtás alapesetben szinkron szervezés , azaz a parancs befejez dése el tt nem adható ki újabb parancs. Multitaszkos rendszerekben azonban lehet ség van aszinkron parancsindításra, amikor a kezel egy parancs kiadását követ en, annak befejez dése el tt

I.1. Rendszermodell és rendszerarchitektúra

30

újabb parancsokat adhat a rendszernek. Ilyenkor a parancsokat végrehajtó programok multiprogramozottan hajtódnak végre.

A bemutatott, legegyszer bb kezel i felület sem része a kernelnek a legtöbb esetben, és egy operációs rendszerhez akár több kezel i felület is lehet használatban (ld. UNIX shell). I.1.6.4. Küls megszakítások kezelése A küls megszakítás egy számítógéprendszerben olyan eszköz, amelyik lehet vé teszi, hogy a rendszer gyorsan reagáljon egy el re nem látható id pontban bekövetkez küls jelzésre. A hardver a rendszerek nagy többségében prioritásos, vektoros megszakításkezelést biztosít. Egy küls megszakítás elfogadásakor a processzor általában m ködési módot vált (rendszermódba kapcsol), és a megszakítási vektor által meghatározott címen folytatja a programvégrehajtást. Ezen a címen az operációs rendszer megfelel része helyezkedik el és reagál a megszakításkérésre. A módváltás miatt fontos, hogy a teljes megszakítási rendszert beleértve a vektortáblákat, a megszakítási programok címkiosztását is - az operációs rendszer kezelje, mert ellenkez esetben kijátszható lenne a védelmi rendszer. Ebb l következik, hogy a megszakítási programok csak olyan reakciókat tartalmazhatnak, amelyek az operációs rendszer írásakor ismertek. Sok esetben hasznos lehet, ha egyes felhasználói programokat, esetleg programrészleteket megszakítás hatására tudunk végrehajtatni. A rendszerek egy része ezért lehet séget ad ilyen megoldásokra, azonban ezt áttételek beiktatásával teszi, úgy, hogy a felhasználói programrészlet ne rendszer-módban fusson.

Küls

megszakításkérések egy számítógéprendszerben jellegzetesen a B/K készülékek

m ködése során keletkeznek, amikor a készülék, vagy készülékvezérl programozott kezelést igényel (pl. kész egy újabb adategység küldésére, vagy fogadására, befejezte az átvitelt stb.). I.1.6.5. Id mérés Gyakorlatilag minden operációs rendszer tartalmaz id kezelési, id mérési funkciókat. Különösen fontos ez a lehet ség a valósidej rendszerekben. Szokásosan a rendszer vezet egy naptárat, amely kezel i paranccsal, vagy programmal lekérdezhet , illetve beállítható, és legalább másodperc felbontású. A további id kezelési feladatok között szerepelhet az egyes felhasználók processzorid -felhasználásának

I.1. Rendszermodell és rendszerarchitektúra

31

nyilvántartása, késleltetett, illetve adott id pontra id zített programindítás, id zített jelzések, valamint egyes m veletekhez, eseményekhez rendelt id korlát el írása a végtelen várakozások kiküszöbölésére.

Korrekt id mérés egy rendszerben csak hardver órával valósítható meg. Fizikailag az óra szorosan integrálódik a processzorhoz, rendszertechnikailag azonban általában egy speciális B/K készülékként kezelhetjük. Az óra általában egy pontos frekvenciájú kvarc-oszcillátor impulzusait számolja és felprogramozással beállítható, hogy hány impulzusonként kérjen megszakítást. Így egy igen pontos periódusidej megszakításkér egységhez jutunk, amellyel szemben elvárás, hogy megszakításait a periódusid n belül lekezelje a rendszer. Ezeknek a megszakításoknak a számlálására építhet fel a további, szoftveres id kezelés. A megszakítás periódusideje meghatározza az operációs rendszer id kezelésének felbontását. Speciális esetekben, ha egyes funkciók finomabb felbontású id kezelést igényelnek, a rendszer lekérdezhet vé teheti a fizikai óra számlálóját, vagy B/K készülékként további programozható órák iktathatók a rendszerbe.

Minden id mérés elvi problémája, hogy az id pontot jelent szám folyton növekszik, és el bb-utóbb minden tároló túlcsordul (ld. 2000. év probléma). A felbontás és az átfogás megválasztása egy-egy rendszerben több szempontot mérlegel eredménye. I.1.6.6. Hibamegszakítások kezelése (kivételkezelés) A számítógéprendszer m ködése során el fordulhatnak olyan hibák, amelyeket a hardver észlelni képes, de amelyek nem okozzák feltétlen a teljes rendszer m ködésképtelenségét. Ilyenek lehetnek egyrészt azok a tranziens hibák, amelyek esetleg a m velet ismétlésével javíthatók, illetve a programok olyan hibái, amelyek csak futási id ben fedhet k fel, és végrehajthatatlan m veletet eredményeznek (pl. nemlétez memóriacímre való hivatkozás, nullával osztás, privilegizált utasítás végrehajtásának kísérlete felhasználói módban stb.). Ezekben az esetekben a hardver nem vált m ködésképtelenné, de a program továbbfuttatása feltehet leg értelmetlen. A processzorok ezért ilyen esetekben hibamegszakítást (trap, exception) generálnak, aminek hatására a program folytatása helyett egy megszakítási program indul el, ami az operációs rendszer része. tervez i kompromisszum

I.1. Rendszermodell és rendszerarchitektúra

32

Az operációs rendszer a hibamegszakítás feldolgozása során · visszaléphet a megszakított utasításra, ha tranziens hiba valószín síthet · hibajelzést küldhet a kezel i konzolra · abortálhatja a hibát okozó programot · elindíthatja a felhasználói program hibakezel részét (kivételkezel , exception-handler) · diagnosztizáló programot indíthat Bizonyos esetekben a hibamegszakítás rendszerére komplex rendszerszolgáltatások építhet k. Ilyen például a kés bbiekben részletezett virtuális tárkezelés, ahol a nemlétez címre való hivatkozás által okozott hibamegszakítás indítja el a keresett információ memóriából való betöltésének folyamatát.

A hibamegszakítások és a küls

megszakítások között fontos különbség, hogy a

hibamegszakítás utasítás közben keletkezik, és az aktuális utasítás nem tud befejez dni, míg küls megszakítást a processzor mindig két utasítás között fogad el, amikor a processzor az utasítás-végrehajtási ciklus kezd pontján van. Ha az operációs rendszer a hibamegszakítást okozó program folytatása mellett dönt, a program tehát vagy a megszakítást okozó utasítás egy közbüls fázisától folytatható (ehhez meg kell rizni az utasításon belüli

processzorállapotot), vagy az utasítás ismétlésével, amihez nyomtalanul törölni kell az el z , félbemaradt végrehajtási kísérlet hatását (utasítás visszaállítás, rollback).

A kezel i konzolra küldött hibajelzések is okozhatnak problémákat. Sok esetben ugyanis a futó alkalmazás kezel eszköze és az operációs rendszer kezel eszköze ugyanaz a terminál. Különösen valósidej , illetve beágyazott rendszerek esetén az alkalmazás kezel i felületén a felhasználó - esetleg például egy technológiát irányító diszpécser - az alkalmazás saját gondolatkörében mozog és dolgozik - például éppen technológiai folyamatábrán követ egy gyártási folyamatot. Az operációs rendszer - miután írója nem készülhetett fel minden lehetséges alkalmazásra - csak uniformizált, sz kszavú, többnyire csak kézikönyvek és részletes szakismeret birtokában értelmezhet hibaüzeneteket tud el állítani és kiírni. Egy ilyen üzenet a diszpécsernek nem igazán informatív, és könnyen pánikhelyzetet okozhat. Hasonló rendszereknél ezért el nyös, ha a felhasználói programban megadható az a pont (kivételkezelés, exception), ahova az operációs rendszer a hibamegszakítás során visszalép, és

I.1. Rendszermodell és rendszerarchitektúra

33

ahol az alkalmazásfügg

hibakezelés a saját állapot- és változótérben programozható. A

folyamat hasonló a .... ábrán bemutatott eseménykezelés-átvételhez. I.1.6.7. Rendszerindítás és leállás Az operációs rendszer két sajátos m ködési állapota a rendszerindítás (boot) és a rendszerleállítás (shut-down) folyamata. Aki kapcsolt már be UNIX, vagy Windows NT operációs rendszert futtató számítógépet, tudja, hogy bizony mind az indítás, mind a leállítás folyamán az amúgy villámgyors rendszer jócskán "molyol" valamin, mire végre feláll a rendszer, vagy mire kikapcsolhatjuk a gépet.

A bajok egyik forrása az, hogy a számítógépek memóriái ma általában felejt memóriák, azaz kikapcsoláskor, vagy tápkimaradáskor tartalmuk törl dik. A rendszerben tápkimaradásokat és egyéb katasztrófákat leginkább "túlél " (perzisztens) tároló a mágneslemez. Bekapcsoláskor tehát az üres memóriában fel kell építeni a rendszert, és ehhez igen sok lemezm veletre van szükség. Kikapcsoláskor ennek a fordítottja játszódik le. A memória és a háttértár (lemez) kezelésében ugyanis a rendszerek igen sokféle hatékonyságnövel trükköt alkalmaznak

(pufferelés, virtuális tár, swapping stb.), aminek következménye azonban az, hogy a lemezen tárolt fájlrendszer és a memóriakép sem lesz minden pillanatban konzisztens. Ha lehet ség van a "rendezett" visszavonulásra (kikapcsolási folyamat) akkor a lemez konzisztenciája és az üzemállapot lemezre írása biztosítható, így a következ indítás várhatóan problémamentes lesz. Ugyanakkor egy váratlan tápkimaradás egy nagyobb rendszert igen kellemetlenül érint, a szünetmentes tápegységek ezért ilyenkor nélkülözhetetlenek.

A másik id igényes bekapcsolási m veletsorozat tulajdonképpen biztonsági és kényelmi okok miatt szükséges. A korszer operációs rendszerek ugyanis az indítás során feltérképezik a rendelkezésre álló hardvert és ellen rzik annak m köd képességét. Ezzel jelent s adaptivitás érhet el (plug and play), és megel zhet k a futás közbeni kellemetlen meglepetések. Ebben a fázisban építi fel a rendszer a konfigurációnak megfelel en a készülékkezel ket és a fizikai készülékeket összekapcsoló rendszertáblákat, a megszakítási vektortáblát, amelynek bejegyzései a küls megszakítások kezelését a megfelel készülékkezel rutinra irányítják. A rendszer - ahol lehetséges - ki is próbálja a beállításokat, megszólítja a kapcsolódó eszközöket, és ellen rzi a reakciókat.

I. Az operációs rendszer, mint absztrakt, virtuális gép

1

I. AZ OPERÁCIÓS RENDSZER, MINT ABSZTRAKT, VIRTUÁLIS GÉP

Mint az el z fejezetben megállapítottuk, az operációs rendszer egyik f feladata, hogy egy kényelmesen kezelhet virtuális gépet jelenítsen meg a felhasználói és a programozói

felületen. Ebben a fejezetben ennek a virtuális gépnek a fontosabb jellemz it tárgyaljuk.

A tárgyalás során el ször most is szoftvertervez i szemlélettel közelítünk az operációs rendszerhez. Egy szoftverrendszer tervezése során a rendszert három nézetb l kell leírni: · adatnézetb l, azaz fel kell térképezni és le kell írni a szerepl ket és kapcsolataikat (objektumok, objektummodell, adatszerkezetek) · a m veletek, funkciók oldaláról, azaz meg kell határozni az egyes szerepl k által, vagy rajtuk végezhet m veleteket (funkcionális modell) · a viselkedés, vagy vezérlés oldaláról, azaz le kell írni a m ködést, azt, hogy melyik m velet mikor hajtódik végre F rendez elvünk az "adatnézet" lesz, azaz sorra vesszük a legfontosabb fogalmakat,

amelyeket az operációs rendszer megjelenít. Ezek a f szerepl k a folyamatok, a tárak, a készülékek és a felhasználók. Természetesen az egyes pontokon belül foglalkozunk a fogalmakhoz köt d funkciókkal és viselkedéssel is.

A fejezet végén foglalkozunk az operációs rendszerek legfontosabb min ségi jellemz ivel, ezek közül kiemelten a védelem és biztonság kérdésével.

I.1. Folyamatok és szálak
A korábbiakban megmutattuk, hogy a különböz típusú rendszerek (kötegelt, id osztásos, valósidej , stb.) egyaránt a multiprogramozás elvén értek el kielégít hatékonyságot. A

multiprogramozás alkalmazása azt jelentette, hogy a kötegelt feldolgozást végz rendszerekben egyidej leg több munka végrehajtása van folyamatban, az id osztásos rendszeren egyidej leg több felhasználó kiszolgálása van folyamatban, a valósidej

I. Az operációs rendszer, mint absztrakt, virtuális gép

2

rendszerekben pedig egyidej leg több küls eseményre reagáló feladat végrehajtása lehet folyamatban. A feldolgozás egységeinek megnevezése a különböz rendszerekben más és más ­ például munka (job), feladat (task) ­, azonban az operációs rendszer szintjén felmerül problémák jórészt közösek. A megvalósítás közös problémái vezettek a valamennyi rendszerben egyaránt használható folyamat fogalmának kialakulásához, a szakirodalomban azonban a job, task, process kifejezések gyakran egymás szinonimájaként fordulnak el . A folyamatmodellel szemben a több processzort tartalmazó, multiprocesszáló rendszerek megjelenése újabb követelményt támasztott, mégpedig azt, hogy a modell legyen használható mind multiprogramozott, mind multiprocesszáló rendszerek esetén.
Megjegyzés: Terminológia (multiprocesszoros)???

A folyamat (process) tehát a multiprogramozott operációs rendszerek alapfogalma. A kifejezést azonban a köznyelv is, és más szakterületek is elterjedten használják. Folyamaton általában m veletek meghatározott sorrendben történ végrehajtását értjük. A folyamat tehát elkezd dik és befejez dik, közben pedig minden részm velet végrehajtása csak akkor kezd dhet el, ha az el z önmagában szekvenciális. részm velet végrehajtása már befejez dött. A folyamat tehát A folyamatok azonban haladhatnak egymással id ben

párhuzamosan. A folyamat kiterjedésének megválasztása elvileg önkényes. A folyamat egy szakasza kiválasztható és önmagában is folyamatként vizsgálható, illetve egymást követ folyamatok egyesíthet k, és egyetlen nagyobb folyamatként vizsgálhatók.

A folyamathoz köt d további általános fogalom a szál fogalma (pl. a cselekmény több szálon fut). A m veletek sorrendjét szemléletesen úgy is meghatározhatjuk, hogy egy képzeletbeli fonalra egymás után felf zzük a m veleteket jelképez gyöngyszemeket. Ezzel a hasonlattal a folyamat egy szálon történ végighaladásnak felel meg.

Az operációs rendszerekkel kapcsolatban a folyamat és a szál kifejezés természetesen sz kebb, konkrétabb értelemben használatos:

Az egyes rendszertípusok természetes feldolgozási egységei (egy job végrehajtása, egy felhasználó kiszolgálása, egy technológiai eseményre való reagálás) folyamatként vizsgálhatók. Ezen folyamatok közös eleme, hogy mindegyikben programok egymást követ

I. Az operációs rendszer, mint absztrakt, virtuális gép

3

végrehajtása történik. A program betöltése és végrehajtása az operációs rendszer egy tipikus m velete, amelyik valamennyi rendszertípusra jellemz . A program több szempontból is összetartozó feldolgozási egység (jól meghatározható funkciója van, többnyire egy fájlban tároljuk, végrehajtáskor egy címtartományt rendelünk hozzá stb.). Egy program végrehajtása az esetek többségében sorrendi, a programon belüli párhuzamosítás speciális esetekben fordul el . Ezeknek a szempontoknak az alapján indokolt a különböz típusú rendszerek közös folyamat fogalmát a programok szintjén megragadni.

Az operációs rendszerek körében tehát a folyamat egy program végrehajtása. Pontosabban, a fogalom inkább tárgyiasult értelemben használatos, azaz a folyamat egy végrehajtás alatt álló program. A "végrehajtás alatt álló" úgy értend , hogy végrehajtása már megkezd dött, de még nem fejez dött be. Így akár multiprogramozott, akár multiprocesszáló a rendszer, egyidej leg több folyamatot kezel. Egy program egy végrehajtása egy utasítássorozat végrehajtását jelenti. Ugyanannak a programnak - az adatfügg elágazások miatt - többféle végrehajtása létezhet. A programkód alapján valamennyi lehetséges végrehajtás el állítható. Felvehetünk egy irányított gráfot, amelynek csomópontjai az utasítások, irányított élei pedig az utasításokat a végrehajtás lehetséges sorrendjében kötik össze (folyamatábra, vezérlési gráf). Egy végrehajtás jellemezhet egy vezérlési szállal, amelyik az irányított gráfon a program belépési pontjától egy befejez dési pontig vezet útnak felel meg.

A fentiek alapján a folyamatról a következ logikai modellt alkothatjuk:

Minden folyamathoz tartozik egy logikai processzor és egy logikai memória. A memória tárolja a programkódot, a konstansokat és a változókat, a programot a processzor hajtja végre. A programkódban szerepl utasítások és a végrehajtó processzor utasításkészlete megfelelnek egymásnak. Egy utasítás végrehajtását ­ néhány kivételt l eltekintve ­ oszthatatlannak tekintjük, azaz a folyamat állapotát csak olyan id pontokban vizsgáljuk, amikor egy utasítás már befejez dött, a következ pedig még nem kezd dött meg. A programvégrehajtás egy vezérlési szál mentén, szekvenciálisan történik, alapvet en az utasítások elhelyezkedésének sorrendjében, ett l speciális utasítások esetén van eltérés. A processzornak vannak saját

I. Az operációs rendszer, mint absztrakt, virtuális gép

4

állapotváltozói (programszámláló, veremmutató, regiszterek, jelz bitek stb.), amelyek értéke befolyásolja a következ utasítás végrehajtásának eredményét. A memória a RAM-modell szerint m ködik, azaz · tárolórekeszekb l áll · egy dimenzióban, rekeszenként címezhet · csak írás és olvasás m veletekkel érhet el · az írás a teljes rekesztartalmat felülírja az el z tartalomtól független új értékkel · az olvasás nem változtatja meg a rekesz tartalmát, tehát tetsz leges számú, egymást követ olvasás az olvasásokat megel z en utoljára beírt értéket adja vissza.

A folyamatot egy adott pillanatban leíró információk (a folyamat állapottere): · a memória tartalma, azaz a végrehajtandó programkód, valamint a változók pillanatnyi értéke · a végrehajtó processzor állapota (programszámláló állása, további regiszterek, jelz bitek stb. értéke)

Az operációs rendszer feladata, hogy a fizikai eszközökön (fizikai processzor, fizikai memória) egymástól elkülönítetten (védetten) létrehozza és m ködtesse a folyamatoknak megfelel logikai processzorokat és memóriákat. A logikai processzor utasításkészlete a

fizikai processzor utasításkészleténél egyrészt sz kebb, mivel nem tartalmazza a privilegizált utasításokat, másrészt ugyanakkor b vebb is, mivel az operációs rendszer szolgáltatásait is tartalmazza (ld. be/kiviteli m veletek stb.). A logikai memória a fizikai tár akár nem összefügg címtartományára, s t esetleg háttértár címekre lehet leképezve, ráadásul a

leképezés a végrehajtás során esetleg változhat is.

Felt nhet, hogy ebb l a modellb l hiányzik a külvilággal tartott kapcsolat eszközrendszere, azaz a be/kivitel. A tárgyalás ezen szintjén a B/K m veleteket a logikai processzor utasításkészlete részének tekintjük, hiszen a B/K m veletekre rendszerhívások állnak rendelkezésre. Valójában a be/kivitel hatékony szervezése az operációs rendszerek legbonyolultabb funkciói közé tartozik.

I. Az operációs rendszer, mint absztrakt, virtuális gép

5

A folyamat logikai modellje mind multiprogramozott, mind multiprocesszoros rendszerek esetén használható. A multiprogramozott rendszerek jellemz je, hogy egyetlen fizikai processzoron, valamint a hozzá tartozó memórián és perifériákon kell egyidej leg több folyamatot végrehajtani, azaz több logikai processzort és memóriát m ködtetni. Ezt úgy is felfoghatjuk, hogy az operációs rendszer a logikai - fizikai leképezés mellett a folyamatok számára er forrásokat biztosít, azaz er forrás-kiosztó, illetve -gazdálkodási feladatot is ellát. Multiprocesszoros rendszerek esetén az egyes folyamatoknak megfelel logikai

processzorokat több fizikai processzorra lehet szétosztani. Az er forrás-gazdálkodás itt több processzorral, valamint a hozzájuk tartozó memóriával való gazdálkodást jelenti.

Összefoglalóan: · Az operációs rendszerek körében a folyamat egy végrehajtás alatt álló ­ "életre kelt" ­ program. · A folyamat létrejön (megszületik), amikor a végrehajtás megkezd dik, és megsemmisül (meghal), amikor a végrehajtás befejez dik. · A folyamatot egy memória-processzor együttes m ködésével modellezhetjük, amelynek állapotleírói a memóriatartalom (a végrehajtandó kód és a változók értéke), valamint a processzor állapota (a programszámláló és a regiszterek értéke).

Egyes operációs rendszerek lehet séget adnak szálak (thread) létrehozására is. A szálak lényegében párhuzamos végrehajtású, közös memóriát használó programrészek a

folyamatokon belül (egy program végrehajtása több szálon futhat). A szálaknak saját logikai processzoruk van (a CPU-ért ugyanúgy versenyeznek, mint a folyamatok), azonban memóriáik nincsenek védetten elkülönítve, közös logikai memóriát használnak, azaz a kódon és változókon osztoznak. Emiatt - és ez a szálak alkalmazásának gyakorlati jelent sége - az operációs rendszer lényegesen gyorsabban tud végrehajtani egy átkapcsolást a szálak között, mint a folyamatok között. A szál és a folyamat megkülönböztetésére használatos a pehelysúlyú (lightweight) és nehézsúlyú (heavyweight) folyamat elnevezés is. A továbbiakban nem teszünk éles különbséget a folyamatok és szálak között, a szálakat általában önálló folyamatoknak tekintjük.

I. Az operációs rendszer, mint absztrakt, virtuális gép

6

I.2. Folyamatokból álló rendszerek
Egy számítógéprendszeren belül általában egyidej leg több folyamat van jelen. Ezek a folyamatok különböz képpen keletkezhettek és különböz kapcsolatok lehetnek közöttük. Ha a rendszer célja csak a hatékony er forrás-kihasználás, a folyamatok kezelése az operációs rendszer belügye maradhat. A felhasználó (az egyszer felhasználó és a programfejleszt ) nem is találkozik folyamatokkal, számára csak futtatandó programok, esetleg job-ok léteznek. A folyamatkezelésben csak az operációs rendszert készít programozók és a

rendszermenedzserek érintettek. Más a helyzet, ha a felhasználó is létrehozhat olyan folyamatokat, amelyek együttm ködve oldanak meg egy feladatot. Ilyenkor a kezel i és programozói felületen is meg kell jeleníteni a folyamatkezelést, valamint a folyamatok együttm ködésének szervezését segít funkciókat. Azokat az operációs rendszereket, amelyek a felhasználó számára is lehet vé teszik a folyamatkezelést, multitaszkos rendszereknek szokták nevezni.

I.2.1. Folyamatok létrehozásának indokai
Láttuk, hogy történetileg a multiprogramozás kialakulását a processzor-kihasználás javítása motiválta. Emellett más szempontok is indokolhatják, hogy egy rendszerben több folyamatot hozzunk létre. Melyek tehát az indokok?

Hatékonyabb er forrás-kihasználás Ez a processzor-kihasználás javításának egy általánosabb megfogalmazása. A processzoron kívül lehetnek a rendszerben más, nagy érték er források, amelyeket egyetlen folyamat csak m ködésének egy rövidebb szakaszában használ, a többi id ben indokolt a használatot mások számára lehet vé tenni. Egy feladatmennyiség egy adott er forráskészlettel akkor oldható meg a leghatékonyabban, ha lehet leg minden eszköz (er forrás) minden pillanatban valamilyen hasznos feladatot végez, és nem tétlen.

A feladat-végrehajtás gyorsítása

I. Az operációs rendszer, mint absztrakt, virtuális gép

7

Az er források hatékony kihasználása általában a feladatmegoldást is gyorsítja. Ezen túlmen en a feladatoknak kereshetjük azokat a megoldásait, amelyek párhuzamosan megoldható részfeladatokra bontják az eredeti problémát. Ha ilyenkor ezeket a részfeladatokat az er források többszörözésével, valódi párhuzamossággal,

folyamatokként tudjuk végrehajtani, további jelent s gyorsítást érhetünk el.

Többféle feladat egyidej végrehajtása A felhasználók számára hasznos és kényelmes lehet, ha a számítógépet egyidej leg többféle célra használhatják. (Pl. egy hosszadalmas számítás közben

szövegszerkesztés végezhet .)

Rendszerstrukturálás Bizonyos feladatokra könnyebb olyan szerkezet programrendszert készíteni,

amelyiken belül több folyamat m ködik együtt, mindegyik a feladat egy leválasztható részén dolgozik, csak meghatározott pontokon cserélnek információt. Ilyen feladatok els sorban a valósidej rendszerek körében fordulnak el , ha a

rendszernek a környezet többféle, egymástól függetlenül bekövetkez eseményére kell reagálnia (pl. irányító rendszerek, több kezel t interaktívan kiszolgáló rendszerek).

A folyamatok létrehozása mellett szóló érvek mellett meg kell említeni egy lényeges ellenérvet is. A folyamatokból álló rendszer fejlesztése - els sorban a tesztelés fázisában lényegesen nehezebb és bonyolultabb feladat, mint a szekvenciális programoké. A folyamatok aszinkron futása miatt ugyanis a rendszer egy adott lefutása gyakorlatilag reprodukálhatatlan, a szisztematikus tesztelés és hibakeresés ezért igen nehéz.

I.2.2. Független, verseng és együttm köd folyamatok
A rendszer folyamatai egymáshoz való viszonyukat, a köztük lév csatolás er sségét tekintve lehetnek függetlenek, verseng k, vagy együttm köd k.

A független folyamatok egymás m ködését semmilyen módon nem befolyásolják. Végrehajtásuk teljes mértékben aszinkron, azaz egymással párhuzamosan is

I. Az operációs rendszer, mint absztrakt, virtuális gép

8

végrehajtódhatnak, de a végrehajtás egymáshoz viszonyított sebességér l semmilyen feltételezést nem tehetünk. Számunkra az ilyen folyamatok gyakorlatilag érdektelenek, hiszen ezek külön-külön, önálló programokként vizsgálhatók.

A verseng

folyamatok nem ismerik egymást, de közös er forrásokon kell osztozniuk.

Verseng folyamatok alakulnak ki például egy kötegelt feldolgozást végz rendszerben, a véletlenszer en érkez , egymást nem ismer felhasználói job-ok feldolgozásakor. Az egyes job-ok részeként elinduló programok ugyanazon a számítógépen hajtódnak végre egy multiprogramozott operációs rendszer felügyelete alatt. Ezeknek a folyamatoknak nem kell tudniuk még azt sem, hogy ket multiprogramozottan fogják végrehajtani, ezért

programkódjuk ugyanolyan, mintha egy soros feldolgozást végz rendszerre írták volna. A több egyidej leg m köd folyamat helyes és hatékony futtatásának problémáit az operációs rendszeren belül kell megoldani (pl. minden folyamatnak külön memóriaterülete legyen, a nyomtatásaik ne gabalyodjanak össze, lehet leg minden er forrás munkában legyen stb.). Ezt a bonyolult er forrás-kiosztási, -gazdálkodási, védelmi és koordinációs feladatot az operációs rendszereken belül gyakran együttm köd folyamatokkal oldják meg. Az operációs rendszer saját, bels folyamatait rendszerfolyamatoknak, a többit felhasználói folyamatoknak

nevezzük. A korrekt és biztonságos er forrás-kezelés a folyamatok aszinkron futásának korlátozását, szinkronizálását igényli (pl. ha egy folyamat nyomtatni akar, amikor egy másik folyamat éppen összetartozó adatsorozatát nyomtatja ki, meg kell várnia, amíg a másik folyamat nyomtatóhasználata befejez dik).

Az együttm köd folyamatok ismerik egymást, együtt dolgoznak egy feladat megoldásán, információt cserélnek. Az együttm köd folyamatokból álló rendszert tervszer en bontottuk folyamatokra, amelyekt l ezért a tervez szándéka szerinti kooperatív viselkedés várható el. Ezekben az esetekben a folyamatok egymástól való védelmének jelent sége kisebb, párhuzamosan m köd programrészekként szálak is alkalmazhatók. Együttm köd

folyamatok esetén a folyamatok leírása és az együttm ködés m veletei a programkódban is megjelennek, azaz a logikai processzor utasításkészletében szerepelnie kell az ehhez szükséges utasításoknak (pl. folyamat indítása, er forrás kizárólagos használatának kérése, üzenetküldés egy másik folyamatnak stb.). Valójában ezeket a m veleteket az operációs rendszer hajtja végre. Az együttm ködéshez szükséges funkciókon kívül természetesen a

I. Az operációs rendszer, mint absztrakt, virtuális gép

9

verseng

folyamatoknál már említett er forrás-kezelési feladatokat is el kell látnia az

operációs rendszernek.

Együttm köd folyamatok munkájukat információcsere útján tudják összehangolni. A cserélt információ esetenként egyetlen bitnyi, csupán jelzés jelleg , máskor akár több megabájt is lehet.

I.2.3. Folyamatok születése és halála
Mindeddig nem foglalkoztunk azzal a kérdéssel, hogy hogyan jönnek létre és hogyan sz nnek meg a rendszert alkotó folyamatok. Vizsgáljuk most ezt a kérdést az egyszer ség kedvéért egyetlen fizikai processzort tartalmazó, azaz multiprogramozott rendszerre.

A Neumann-elven m köd számítógépek soros feldolgozást végeznek. Amikor egy ilyen számítógépet bekapcsolunk, elindul egy rendszerépítési folyamat (boot, inicializálás). Ezt egy sfolyamatnak tekinthetjük, amelyik létrehozza a rendszert alkotó többi folyamatot. A rendszerépítés eredményeként már egy m ködésre kész operációs rendszer alakul ki, amelyik maga is több folyamatból állhat (rendszerfolyamatok). A m ködésre kész operációs rendszerben például interaktív kiszolgálás esetén minden terminálhoz tartozhat egy rendszerfolyamat, amelyik felhasználói parancsokat fogad és hajt végre. Kötegelt feldolgozás esetén elindulhat egy job-készletet kezel folyamat, amelyik jobok végrehajtását kezdi meg és job-onként egy újabb folyamatot indít. Valósidej rendszer esetén az operációs rendszer saját felépülése után létrehozza és inicializálja a felhasználói rendszert alkotó folyamatokat. A rendszerfolyamatok tehát újabb, felhasználói folyamatokat hoznak létre, a felhasználói folyamatok pedig ­ bizonyos típusú rendszerekben ­ maguk is létrehozhatnak további felhasználói folyamatokat a logikai processzor megfelel utasításának végrehajtásával (pl. fork, create). A folyamatok általában saját jószántukból fejezik be m ködésüket a logikai processzor megfelel (pl. exit) utasításának végrehajtásával. Bizonyos esetekben (pl. m ködési hibák) azonban szükség lehet arra, hogy más folyamat szüntessen meg egy folyamatot (pl. kill).

I. Az operációs rendszer, mint absztrakt, virtuális gép

10

Azokat a rendszereket, amelyek m ködése során ­ a felépülés és inicializálás kezdeti szakaszától eltekintve ­ nem jönnek létre és nem sz nnek meg folyamatok, statikus rendszereknek nevezzük, szemben a dinamikus rendszerekkel, amelyekben m ködés közben bármikor születhetnek és megsz nhetnek folyamatok.
Megjegyzés: ????

A folyamatok eredetét szükség esetén a szül

- gyermek viszonyokkal, azaz egy fa

struktúrával írhatjuk le (processzgráf). Dinamikus rendszerben a fa természetesen folyamatosan követi a folyamatok születését és halálát. Sok operációs rendszer a szül gyermek viszonyokra építi er forrás-gazdálkodási és jogosultsági filozófiáját. Ennek egyik megközelítése a hierarchikus er forrás-gazdálkodás, amikor a gyermek folyamatok csak a szül er forrásaiból részesülhetnek és nem létezhetnek önállóan, csak amíg szül jük is

létezik. Egy másik megközelítés a globális er forrás-gazdálkodás, amikor a rendszer valamennyi folyamata létrejötte után egyenrangú, önálló szerepl , és versenyezhet a teljes er forráskészletb l való részesedésért.

I.2.4. Folyamatok együttm ködése
A folyamatok együttm ködése információ-átadással valósul meg. A folyamatok közötti információcserének két alapvet módja alakult ki, a közös memórián keresztül, illetve az üzenetváltással történ adatcsere (kés bb mindkett t részletesen tárgyaljuk). Valamennyi

konkrét megoldás ­ a legegyszer bb, processzorok közötti jelz bitt l a nagy adatbázisokon végzett tranzakciókig vagy a földrészeket átfogó hálózati alkalmazásokig ­ erre a két alapsémára vezethet vissza. I.2.4.1. Együttm ködés közös memórián Közös memórián keresztül történ adatcsere esetén az együttm köd folyamatok mindegyike saját címtartományában lát egy közös memóriát. A közös memória elérését (a közös memória címtartományára kiadott olvasás, vagy írás m velet végrehajtását) valamilyen adatátviteli rendszer (kapcsolóhálózat, sín stb.) teszi lehet vé.

A folyamatok párhuzamos futása miatt a közös memóriát egyidej leg több folyamat is írhatja, illetve olvashatja. Ilyen esetekre a RAM modell nem határozza meg a memória m ködését,

I. Az operációs rendszer, mint absztrakt, virtuális gép

11

ezért a közös memóriát a RAM modell kiterjesztésével kapott PRAM (Pipelined Random Access Memory) modell szerint kell kialakítani.

Közös memória

Közös memória

Adatátviteli rendszer

P1

P2

...

Pn olvas olvas ír

Sorbaállító cs vezeték (Pipeline)

Saját memória

Saját memória

...

Saját memória olvas

olvas ír

Folyamatok együttm ködése közös memórián A PRAM szemléltetése

I.2-1. ábra Folyamatok együttm ködése PRAM szerint m köd közös memórián

A PRAM modell szerint m köd memóriát több processzor írhatja és olvashatja egyidej leg. Az olvas és ír m veletek egyidej kiegészítések vonatkoznak: olvasás - olvasás ütközésekor mindkét olvasás ugyanazt az eredményt adja, és ez megegyezik a rekesz tartalmával, olvasás - írás ütközésekor a rekesz tartalma felülíródik a beírni szándékozott adattal, az olvasás eredménye vagy a rekesz régi, vagy az új tartalma lesz, más érték nem lehet, írás - írás ütközésekor valamelyik m velet hatása érvényesül, a két beírni szándékozott érték valamelyike írja felül a rekesz tartalmát, harmadik érték nem alakulhat ki. Ezek a szabályok lényegében azt jelentik, hogy az egyidej m veletek nem interferálhatnak, azaz nem lehet közöttük zavaró kölcsönhatás. Hatásuk olyan lesz, mintha valamilyen el re nem meghatározható sorrendben hajtódnának végre (ezt tükrözi a pipelined elnevezés, arra utalva, hogy a memóriához egy sorosítást végz cs vezetéken jutnak el a parancsok).
Megjegyzés: ????

végrehajtására a RAM modellhez képest az alábbi

Másként fogalmazva, ezek a m veletek a modell szintjén oszthatatlanok (atomiak).

I. Az operációs rendszer, mint absztrakt, virtuális gép

12

A közös memória használatával történ adatcsere helyes lebonyolításához a PRAM modell szerint m köd memória mellett a folyamatok m ködésének összehangolása is szükséges (pl. az adat fogadója akkor olvassa el az adatot, ha a küld már elhelyezte azt; összetett adatok átadásakor félig átírt rekordot ne kezdjen olvasni a fogadó, stb.). Ez ismét a folyamatok szabadon futásának (aszinkronitásának) korlátozását jelenti, azaz szinkronizációt igényel. I.2.4.2. Együttm ködés üzenetváltással Üzenetváltásos adatcsere esetén a folyamatoknak nincs közös memóriája. Az adatátviteli rendszer most a logikai processzorokat kapcsolja össze. Rajta keresztül a folyamatok üzeneteket tudnak küldeni, illetve fogadni. Az üzenetküldésre, illetve fogadásra a folyamatok logikai processzorainak utasításkészletében megfelel utasítások állnak rendelkezésre.

Legyenek ezek a Küld (Send) és a Fogad (Receive) m veletek.

A Küld(,) m velet végrehajtásakor a m veletet végrehajtó folyamat elküldi a saját memóriájának megadott címén tárolt adatot a megadott folyamatnak, a Fogad(,) m velet pedig végrehajtásakor a megadott folyamattól érkez üzenetet a saját memória megadott címén tárolja.

Adatátviteli rendszer

küld P1 P2 ...

fogad Pn

Saját memória

Saját memória

...

Saját memória

Folyamatok együttm ködése üzenetváltással

I.2-2. ábra Folyamatok együttm ködése üzenetváltással Míg gyakorlatilag valamennyi közös memóriás információcserét alkalmazó megoldás a PRAM modellre alapul, az üzenetközvetítésre nincs egyetlen elfogadott modell. Ha csak a m ködés logikájával foglalkozunk, és olyan lényeges kérdéseket nem is érintünk, mint az átviteli sávszélesség, az összeköttetés megbízhatósága, az üzenetszerkezet, az átviteli közeg

I. Az operációs rendszer, mint absztrakt, virtuális gép

13

sajátosságai, a kapcsolatépítés esetleges dinamikája, akkor is számos tulajdonságot találunk, amelyekben az egyes megoldások eltérhetnek, és amelyek ismerete fontos a felhasználók (rendszertervez k, programozók, üzemeltet k) számára. A folyamatok kommunikációs m veleteinek tulajdonságaival ezért külön pontban foglalkozunk.

I.2.5. Folyamatok szinkronizációja
A közös er források használata valamint a folyamatok közötti közös memóriás információcsere biztonsága és helyessége érdekében a folyamatok aszinkron

"szabadonfutását" esetenként korlátozni kell. A m velet-végrehajtásra vonatkozó id beli korlátozásokat nevezzük szinkronizációnak. A korlátozások alapesetei a következ k:

Kölcsönös kizárás (mutual exclusion) Több folyamatban lehetnek olyan utasítássorozatok (kritikus szakaszok), amelyek egyidej (konkurens) végrehajtása nem megengedett, azaz ezeknek az

utasítássorozatoknak a végrehajtása kölcsönösen ki kell, hogy zárja egymást.

Kölcsönös kizárás szükséges jellegzetesen a megosztottan használt er forrásokon végzett oszthatatlan m veletsorozatok esetén (pl. ha egy folyamat megkezdett egy nyomtatást, ki kell zárni, hogy más folyamat közbenyomtathasson egy-egy sort, vagy a közös memóriában tárolt, összetett adatszerkezetek kezelésekor, az adatbázistranzakciók végrehajtásakor meg kell akadályozni, hogy egyes folyamatok félig átírt, inkonzisztens rekordokat lássanak). Ezeknek a m veletsorozatoknak az idejére az adott er forrás használatára kizárólagosságot kell biztosítani a folyamat számára.

Kicsit pontosabb fogalmazásban: Egy folyamatokból álló rendszerben egy K kritikus szakasz folyamatok végrehajtási szakaszainak egy Sk halmazát jelenti, amely Sk halmaz bármely két sk,i és sk.j elemének átlapolt végrehajtása tilos. Ha egy folyamat sk,i Sk szakaszának végrehajtása

megkezd dik, azt mondjuk, hogy a folyamat belépett a K kritikus szakaszba. Hasonlóan sk,i végrehajtásának befejez désekor azt mondjuk, hogy a folyamat kilépett a K kritikus szakaszból. Egy folyamat csak akkor léphet be a K kritikus szakaszba, ha egyetlen más folyamat sem tartózkodik éppen K-ban. Ellenkez esetben meg kell várnia, amíg a bent

I. Az operációs rendszer, mint absztrakt, virtuális gép

14

tartózkodó folyamat elhagyja K-t. Ha egy folyamat elhagyja K-t, az esetleges belépésre várakozó folyamatok közül egyetlen léphet be K-ba.

Fentiekb l következik, hogy egy rendszerben több, egymástól független kritikus szakasz létezhet. Minden kritikus szakaszhoz az egymást kizáró végrehajtási szakaszok egy halmaza tartozik. Egy K kritikus szakaszba való belépésnek nem feltétele az, hogy más (L, M, N stb.) kritikus szakaszokban éppen tartózkodik-e folyamat és melyik. Az is lehetséges, hogy egy folyamat egyszerre több kritikus szakaszban tartózkodik (pl. több kizárást igényl er forrást használ egyidej leg.

Megjegyezzük, hogy a folyamat szekvenciális végrehajtása miatt (a szálakat önálló folyamatnak tekintve) egy folyamaton belül a kölcsönös kizárás bármely két utasítás között teljesül, folyamaton belüli két utasítássorozat kölcsönös kizárásának el írása értelmetlen.

A kritikus szakaszokat a programozók definiálják, a belépési szándékot és a szakaszból való kilépést a kódban elhelyezett m veletekkel jelölik. Verseng folyamatok esetén ez nem más, mint kizárólagos használat kérése, illetve ennek feloldása bizonyos eszközökre (pl. Lefoglal(nyomtató), Felszabadít(nyomtató)). A m veletek

rendszerhívásokat jelölnek, és futási id ben az operációs rendszer hozza meg a döntést a folyamat továbbengedésér l vagy várakoztatásáról. Együttm köd folyamatok elvileg bármilyen egyeztetett megoldást használhatnának a probléma megoldására. A gyakorlatban számukra is kialakultak az operációs rendszer szinkronizációs rendszerhívásai, amelyek már nem köt dnek konkrét eszközhasználathoz, csak koordinációs szerepük van (ld. kés bb).

Egyidej ség (randevú) Különböz folyamatokban elhelyezett m veletekre el írhatjuk, hogy azok várják be egymást és "egyidej leg" hajtódjanak végre. Kell en finom id léptékben természetesen az egyidej ség értelmezése problematikus. Az egyidej ség pontosabban úgy értend , hogy egyik folyamat sem léphet túl a benne egyidej végrehajtásra kijelölt végrehajtási

I. Az operációs rendszer, mint absztrakt, virtuális gép

15

szakaszon mindaddig, amíg valamennyi többi folyamat meg nem kezdte a saját kijelölt szakaszának végrehajtását. Az egyidej ség tipikus alkalmazása az átmeneti tárolót nem tartalmazó adatátvitel Küld és Fogad m veleteinek végrehajtása, valamint a távoli eljáráshívás kiadása és elfogadása (ld. kés bb).

El írt végrehajtási sorrend (precedencia) Különböz folyamatok kijelölt m veletei között végrehajtási sorrendet írhatunk el . Legyen például P1 folyamat egy utasítása S1, P2 egy utasítása pedig S2. Az S1 => S2 precedencia el írása azt jelenti, hogy S1 végrehajtásának be kell fejez dnie, miel tt S2 végrehajtása megkezd dik. Ha az egyébként aszinkron futású P1 és P2 úgy hajtódna végre, hogy S2 hamarabb kerülne sorra, P2-nek meg kell várnia, míg P1-ben S1 végrehajtása befejez dik. A precedencia el írása jellegzetesen annak biztosítására használatos, hogy egy folyamat csak akkor kezdje felhasználni a másik folyamat által el állított adatokat, amikor azok már rendelkezésre állnak. I.2.5.1. Megoldások a PRAM modell keretei között (szoftver-megoldások) A szinkronizáció igénye el ször a multiprogramozott operációs rendszeren belül a kölcsönös kizárás problémájának formájában vet dött fel. A multiprogramozott rendszer folyamatainak kézenfekv együttm ködési módja a közös memória használata. A probléma megoldását

ennek megfelel en a PRAM modell szerinti közös memóriát használó folyamatokra keresték további hardveres támogatás nélkül. A szinkronizáció ebben a felfogásban a folyamatok felel ssége. A folyamatok egyezményes adatszerkezeteket használnak a probléma megoldására, és a szinkronizációs pontokon egyezményes m veletsorozatot (protokoll) hajtanak végre. Ezért említi az irodalom ezeket szoftver-megoldásokként.
(Megjegyzés: a szoftver-megoldások bemutatását els sorban didaktikai szempontok indokolják, hiszen a mai megoldások hardver-támogatásra épülnek.)

Lássuk tehát a kölcsönös kizárás problémájának megoldási kísérleteit!

A kölcsönös kizárás megoldásaival szemben a következ általános elvárásokat támasztjuk: Minden körülmények között teljesüljön a kölcsönös kizárás.

I. Az operációs rendszer, mint absztrakt, virtuális gép

16

A belépési protokoll döntéshozatala csak a belépésben érdekelt folyamatok részvételét igényelje, azaz a többi folyamat nyugodtan haladhasson anélkül, hogy foglalkozniuk kellene a kérdéssel. Véges id n belül minden belépni szándékozó folyamat bejuthasson (ett l esetenként eltekinthetünk).

Kézenfekv megoldásnak t nik kritikus szakaszonként egy foglaltságjelz bit elhelyezése a közös memóriában szabad kezd értékre állítva. A kritikus szakaszba belépni szándékozó folyamat teszteli a jelz t, ha szabad, akkor átállítja foglaltra és belép a kritikus szakaszba, kilépéskor pedig visszaállítja szabadra.

A folyamatok tehát a következ képpen m ködnek:
(Megjegyzés: a programrészleteket Pascal-szer pszeudo-kóddal illusztráljuk.)

var közös_jelz :{foglalt,szabad}:=szabad

Valamennyi folyamat: ... belépés: olvas (közös_jelz ) if foglalt then goto belépés ír (közös_jelz ,foglalt)

kilépés: ír (közös_jelz ,szabad) ...

A megoldás problémája, hogy mivel a közös_jelz a közös memóriában helyezkedik el, kis valószín séggel bár, de el fordulhat, hogy több folyamat olvassa egyidej leg, és így többen is szabadnak találják. Ekkor egyidej leg többen léphetnek be a kritikus szakaszba, ami nyilvánvalóan hibás.
Megjegyezzük, hogy az algoritmus nem csak a folyamat általános modelljét (amikor minden folyamatnak külön processzora van) feltételezve hibás, hanem multiprogramozott megvalósításban is. Ekkor ugyan a párhuzamos

I. Az operációs rendszer, mint absztrakt, virtuális gép

17

olvasás kizárt (hiszen az egyetlen processzor egyidej leg csak egyetlen utasítással foglalkozik), azonban az olvasás és visszaírás közé beékel dhet más folyamat végrehajtása, amelyik ugyancsak olvashatja, és szabadnak találhatja a jelz t.

Néhány további zsákutcát átugorva, amelyek vagy ugyancsak nem biztosítják a kölcsönös kizárást, vagy csak felváltva engedik be a két folyamatot, vagy holtpontot okozhatnak, lássunk egy igazi megoldást! A probléma egy helyes megoldása két folyamatra (Peterson, 1981.): Legyen a két folyamat P1 és P2. Legyen mindkét folyamatnak egy-egy jelz je a belépési szándékra, valamint egy változó, amelyik megmutatja, hogy egyidej belépési szándék esetén melyik léphet be.

I. Az operációs rendszer, mint absztrakt, virtuális gép

18

var

jelz :array[1..2]of{foglal,szabad}:=szabad következ : {1,2}

P1 folyamat: ... ír (jelz [1],foglal) ír (következ ,2) belépés1: olvas (jelz [2]) if szabad then goto belép1 olvas (következ ) if 2 then goto belépés1 belép1:

kilép1:

ír (jelz [1],szabad) ...

-----------------

P2 folyamat: ... ír (jelz [2],foglal) ír (következ ,1) belépés2: olvas (jelz [1]) if szabad then goto belép2 olvas (következ ) if 1 then goto belépés2 belép2:

kilép2:

ír (jelz [2],szabad) ...

-----------------

Figyeljük meg, hogy a belépésre vonatkozó döntésben a következ változónak csak akkor van szerepe, ha a másik folyamat jelz je nem szabadot mutat, azaz egyidej belépési szándék veszélye áll fenn. Ilyenkor legrosszabb esetben a következ változóra kiadott írás is

I. Az operációs rendszer, mint absztrakt, virtuális gép

19

egyidej , de az írási verseny valahogy eld l. A következ változó csak egy értéket vehet fel, mégpedig a kés bbi írás eredménye (a vesztes) jelöli ki a másik folyamatot belép nek, ami akkor is helyes, ha a másik folyamat már korábban is a szakaszban tartózkodott.

A megoldás követése már két folyamatra sem valami egyszer , több folyamatra pedig csak a gyakorlatban alig használható bonyolultságú általános megoldás adható. Els ként Dijkstra publikált megoldást n folyamatra 1965-ben, majd több más javaslat is született. Talán a legáttekinthet bb Lamport megoldása (1974) a pékség és egyéb sorállásra alkalmas üzletek és szolgáltatóhelyek m ködésének analógiájára (bakery algorithm).

Bakery algoritmus adatszerkezetek közös tárban: var számot_kap: array [0..n-1] of Boolean := false; (jelzi, hogy egy folyamat éppen sorszámot kap) sorszám: array [0..n-1] of integer := 0; (tárolja a sorszámokat) Pi folyamat: belépési protokoll: Sorszámot kér: számot_kap[i]:=true; sorszám[i]:=max(sorszám)+1; számot_kap[i]:=false; Amíg van nála kisebb sorszámú, helybenjár: for j:=0 to n-1 do begin while számot_kap[j] do üres_utasítás; while sorszám[j] 0 and (sorszám[j],j)< (sorszám[i],i) do üres_utasítás; end; kilépési protokoll: sorszám[i]:=0;

Az algoritmus szerint a belépni szándékozó folyamatok el ször sorszámot kérnek. Mivel a sorszámosztás a közös memóriában tárolt sorszám tömb maximális elemének kiválasztását

I. Az operációs rendszer, mint absztrakt, virtuális gép

20

igényli, nem atomi PRAM m velet. Ezért folyamatonként egy jelz (számot_kap) véd attól, hogy eközben a folyamat sorszámát vizsgálhassa egy másik folyamat. Az ellen azonban nincs védelem az algoritmusban, hogy két folyamat azonos sorszámot kapjon. Miután a folyamat megkapta a sorszámát, végignézi a többi folyamat sorszámait, és ha az övé a legkisebb, belép a kritikus szakaszba. A vizsgálat közben kivárja, míg egy éppen sorszámot kér folyamat megkapja a számot, csak utána hasonlítja össze a sajátjával. Valahányszor talál olyan folyamatot, amelyik kisebb sorszámot kapott, kivárja, amíg az a folyamat elhagyja a szakaszt, csak azután lép a következ folyamat sorszámának vizsgálatára. Így a ciklus végére érve biztosan beléphet a szakaszba, mert kivárt minden korábban érkez t, és ezek egy esetleges következ belépési szándék esetén már csak nagyobb sorszámokat kaphattak. Mivel két folyamatnak lehet azonos sorszáma, az algoritmus a sorszámok összehasonlítása helyett a sorszámból és a folyamat azonosító számából álló rendezett számpárokat (sorszám[i],i) hasonlítja össze, így egyez sorszámok esetén is egyértelm a döntés a kisebb azonosító számot visel folyamat javára.

A szoftver-megoldások bonyolultsága más irányokba terelte a probléma megoldásán fáradozó kutatókat. Olyan eszközöket dolgoztak ki, amelyek - a PRAM modellt is kiterjesztve - a processzor utasításkészletébe épülve támogatják a folyamatok szinkronizációjának

megoldását (hardver támogatás). A következ kben ezek közül ismertetünk néhányat.

I.2.5.2. A PRAM modell kiterjesztése A kritikus szakaszhoz rendelt foglaltságjelz bit logikailag egyszer és jó ötlet. A problémát az okozza, hogy a jelz értékét többen is kiolvashatják, miel tt az els olvasó szabadról foglaltra állította volna. Megoldódik a probléma, ha a PRAM modellt úgy módosítjuk, hogy a jelz kre vonatkozóan az olvas és ír utasításokon kívül bevezetjük az OlvasÉs Ír (TestAndSet) utasítást. Az utasítás kiolvassa és az olvas utasításhoz hasonlóan visszaadja egy jelz értékét, majd foglaltra állítja azt. A m velet ugyanúgy oszthatatlanul (sorosítva) hajtódik végre, mint az olvas és ír utasítások. Ez azt jelenti, hogy egy szabad jelz re több OlvasÉsÍr utasítást egyidej leg végrehajtva ezek közül csak egy ad vissza szabad értéket, a jelz végs értéke pedig természetesen foglalt lesz. Az OlvasÉsÍr utasítás segítségével a kölcsönös kizárás megoldása:

I. Az operációs rendszer, mint absztrakt, virtuális gép

21

var közös_jelz :{foglalt,szabad}:=szabad

Valamennyi folyamat: ... belépés: OlvasÉsÍr (közös_jelz ) if foglalt then goto belépés

kilépés: ír (közös_jelz ,szabad) ...

Az OlvasÉsÍr utasításhoz hasonlóan a Csere (Swap) utasítás bevezetésével is megoldható a probléma. A Csere utasítás a közös memória egy rekeszének és a folyamat saját memóriája egy rekeszének tartalmát cseréli meg ugyancsak oszthatatlanul. A kölcsönös kizárás megoldása a Csere utasítással:
var közös_jelz :{foglalt,szabad}:=szabad

Valamennyi folyamat: var saját_jelz :{foglalt,szabad} ... saját_jelz :=foglalt belépés: Csere (közös_jelz ,saját_jelz ) olvas (saját_jelz ) if foglalt then goto belépés

kilépés: ír (közös_jelz ,szabad) ...

Az OlvasÉsÍr vagy a Csere utasítások valamelyikét egy ideje már a fizikai processzorok utasításkészlete tartalmazza. Ezek megvalósítása olyan, hogy többprocesszoros rendszerben is

I. Az operációs rendszer, mint absztrakt, virtuális gép

22

garantálja az oszthatatlanságot például a memóriasín több m veletre kiterjed lefoglalásával (ld. LOCK az Intel processzorcsalád, read-modify-write ciklus a Motorola processzorcsalád esetén). Multiprogramozott rendszerben (egy processzor) az oszthatatlanságot a

megszakítások tiltásával is elérhetjük, így szimulálhatók az oszthatatlan OlvasÉsÍr vagy a Csere utasítások.

A fenti megoldások nem garantálják, hogy a kritikus szakaszba belépni szándékozó folyamatok véges id n belül bejutnak a szakaszba. Ez ugyanis azon múlik, hogy a versenyz OlvasÉsÍr vagy Csere utasítások milyen sorrendben kerülnek a PRAM sorosító cs vezetékébe. A foglaltságjelz ciklikus tesztelésére alapozottan ez a probléma ismét csak igen bonyolultan oldható meg. Áttekinthet megoldáshoz akkor jutunk, ha a várakozó

belépési szándékokat nyilvántartjuk, és a belépések ütemezését meghatározottá tesszük. Minden szempontból célszer bb tehát, ha a folyamatok önszervez belépési protokolljai

helyett a szinkronizáció problémájának korrekt, a hardver lehet ségeihez igazodó, tisztességes ütemezést biztosító megoldását logikailag a folyamatokat végrehajtó virtuális processzorra, realizációját tekintve az operációs rendszerre bízzuk.

I.2.5.3. Szinkronizációs eszközök az operációs rendszer szintjén A kiterjesztett PRAM modell felhasználásával az operációs rendszer szintjén összetettebb szinkronizációs eszközök hozhatók létre. Ezek közül a következ kben a szemafort, az er forrást és az eseményt tárgyaljuk.

Szemafor A szemafor, mint univerzális szinkronizációs eszköz használatára Dijkstra tett javaslatot 1965-ben. A szemafor egy speciális változó, amelyet csak a hozzá tartozó két, oszthatatlan m velettel lehet kezelni. Az általános szemafor esetén a szemafor-változó egész (integer) típusú. A két m velet elnevezése többféle lehet, pl. Belép és Kilép, vagy Vár (Wait) és Jelez (Signal). Leggyakrabban azonban az eredeti definícióban szerepl szakirodalom, így a továbbiakban mi is ezt követjük. A P(s) m velet hatása egyenérték azzal, mintha a folyamathoz tartozó logikai processzor a következ programrészletet hajtaná végre oszthatatlanul (definíciós program): jelölést (P és V) használja a

I. Az operációs rendszer, mint absztrakt, virtuális gép

23

while s<1 do üres_utasítás; s:=s-1; (az üres_utasítás m velet nélküli továbblépést jelent, s pedig a közös

memóriában lév szemafor-változó) A V(s) m velet definíciós programja: s:=s+1; Hangsúlyozni kell, hogy mindkét m velet oszthatatlan, valamint azt is, hogy a szemaforváltozó más utasításokkal (írás, olvasás) nem érhet el. Azt is meg kell jegyeznünk, hogy a definíció a véletlenre bízza, hogy a várakozó folyamatok közül melyiknek sikerül a továbbhaladás, amikor egy másik folyamat V m veletet hajtott végre.

Vegyük észre, hogy az általános szemafort k kezd értékre állítva a rendszer k darab P m veletet végrehajtó folyamatot enged tovább, a továbbiakat azonban várakoztatja. Ezután csak akkor enged tovább folyamatot a P rendszerhívásról, ha más folyamat V m veletet hajtott végre. Ezzel egy olyan általánosított kritikus szakaszt hoztunk létre, amelyiken belül egyidej leg k darab folyamat tartózkodhat.

Precedencia és kölcsönös kizárás megvalósítására alkalmas a bináris szemafor, amelynek szemaforváltozója csak két értéket vehet fel (0 és 1, vagy foglalt és szabad). Kölcsönös kizárásra 1 kezd érték bináris szemafor használható, amelyre a kritikus szakaszba belépni kívánó folyamat P m veletet, a kritikus szakaszból kilép pedig V m veletet hajt végre. Precedencia megvalósításához 0 kezd érték bináris szemafor használható. Az el bb

végrehajtandó m veletet követ en a folyamat V m veletet hajt végre a szemaforra, a másik folyamat pedig a kés bb végrehajtandó m velet el tt P m veletet.

Er forrás Az er forrás, mint szinkronizációs eszköz egy logikai objektum, amelyet egy folyamat lefoglalhat és felszabadíthat. A lefoglalás és a felszabadítás között a folyamat kizárólagosan használhatja az er forrást, azaz erre a szakaszára és más folyamatok ugyanezen er forrásra vonatkozó foglalási szakaszaira kölcsönös kizárás valósul meg. Az er forrásokat egy név vagy egy sorszám azonosítja. A programozók megegyezésén, illetve rendszertervez i döntésen múlik, hogy egy-egy er forrást milyen tartalommal használnak. A

I. Az operációs rendszer, mint absztrakt, virtuális gép

24

Lefoglal() és Felszabadít() m veletek egyenérték ek egy s bináris szemaforra kiadott P(s) és V(s) m veletekkel. Mint a szemafornál sem, az er forrásra várakozó folyamatok esetén sem meghatározott, hogy melyikük kapja meg a felszabaduló er forrást, és haladhat tovább. Csak az biztos, hogy egyetlen ilyen folyamat lesz.

Esemény Az esemény egy pillanatszer történés a rendszerben, amelyre folyamatok várakozhatnak. Az esemény bekövetkezése valamennyi rá várakozó folyamatot továbbindítja. Az eseménnyel így egy összetett precedencia valósítható meg, ahol több, különböz folyamatokban elhelyezett m veletre ugyanazt az el zményt írjuk el . Két folyamat esetén egy esemény jelzése és az arra való várakozás egyenérték egy szemaforra kiadott V, illetve P m veletekkel. Több folyamat esetén azonban lényeges különbség, hogy a szemaforra kiadott V m velet hatására csak egyetlen várakozó folyamat indulhat tovább, míg az esemény bekövetkezése valamennyi várakozó folyamatot továbbindítja. Míg a szemafor és az er forrás felszabadítása az objektum állapotában meg rz dik akkor is, ha nem várnak rá, és egy kés bbi foglalás várakozás nélkül sikeres lesz, az esemény jelzése általában hatástalan, ha nincs rá várakozó, csak a várakozás megkezdése után bekövetkez esemény indít tovább folyamatot.

A bemutatott szinkronizációs eszközök közül a szemafor és az er forrás több várakozó folyamat közül egy továbblépését teszi lehet vé, azonban ennek kiválasztását a véletlenre bízza. Ez a megoldás sok esetben nem kielégít . Az egyik f érv a megoldás ellen, hogy nincs garancia arra, hogy minden várakozó véges id n belül tovább tud lépni. Egy másik - az el z nek egyébként ellentmondó - érv a véletlenre hagyatkozás ellen, hogy amennyiben fontossági sorrendet (prioritást) állítunk fel a folyamatok között, a véletlenszer továbbindítás ezt nem érvényesíti. Felmerül tehát annak az igénye, hogy a választás meghatározott algoritmus szerint történjen. Ennek megoldása a várakozó folyamatok sorbaállítása, és ütemezett továbbengedése. A szemaforokhoz és er forrásokhoz így várakozási (ütemezési) sorokat rendelhetünk, amelyeket a rendszer meghatározott (ütemezési) algoritmus szerint kezel. A leggyakoribb az érkezési sorrend szerinti (FIFO), illetve a prioritásos ütemezés.
Megjegyzés: Nyelvi szint.

I. Az operációs rendszer, mint absztrakt, virtuális gép

25

I.2.6. Folyamatok kommunikációja
Mint láttuk, a folyamatok együttm ködésének másik alapmodellje a közös memóriás együttm ködés mellett az üzenetváltásos együttm ködés, azaz a folyamatok közötti kommunikáció. Az üzenetváltásos együttm ködés akkor került el térbe, amikor realitássá vált több, adatátviteli vonalon, vagy hálózaton keresztül összekapcsolt számítógép

együttm ködése. A kommunikáció alapsémáját a I.2-2. ábra mutatja be. Azon kívül, hogy a logikai processzor utasításkészletében szerepel Küld és Fogad m velet, a kommunikáció m ködésével, tulajdonságaival kapcsolatban számos nyitott kérdés maradt, és megállapítottuk, hogy nincs egyetlen tiszta modell, amelyet a megoldások követnek.

Néhány a legkézenfekv bb kérdések közül: Hogyan nevezhetjük meg a partnert? A partnert látjuk, vagy egy közbüls objektumot

(csatornát, postaládát)? Egyetlen partner veheti egyszerre az üzenetünket, vagy több is? Csak egyetlen partnert l várhatunk üzenetet egy adott pillanatban, vagy többekt l is? Amikor a Küld m velet befejez dött, meddig jutott az üzenet? Már ott van a partnernél, vagy csak útjára bocsátottuk (ld. levél bedobása a postaládába)? Honnan fogjuk megtudni, hogy rendben megérkezett-e? Hogyan m ködik a Fogad m velet? Mi történik, ha hamarabb akarunk fogadni egy üzenetet, mint azt elküldték? Kell-e visszaigazolást küldenünk, vagy ezt a rendszer automatikusan elintézi?

A következ kben a felmerül kérdések közül hárommal foglalkozunk részletesebben: milyen megnevezést használhatnak a kommunikáló partnerek, hogy egymásra találjanak milyen szemantikai konzisztenciának kell fennállni a küldés és a fogadás között milyen járulékos (implicit) szinkronizációs hatása van a kommunikációnak I.2.6.1. A partner megnevezése Megnevezés tekintetében beszélhetünk közvetlen (direkt), közvetett (indirekt) valamint aszimmetrikus kommunikációról, illetve megnevezésr l, továbbá csoportkijelölésr l és üzenetszórásról.

I. Az operációs rendszer, mint absztrakt, virtuális gép

26

A közvetlen (direkt) kommunikáció két folyamat között zajlik, mind a Küld, mind a Fogad m velet megnevezi a partner folyamatot (I.2-3. ábra). P1 elküldi a saját címtartományában tárolt x változó értékét P2-nek, aki azt saját y változójába teszi el. (Ha a változók közös címtartományban lennének, egyszer en y:=x értékadást használhatnánk, így azonban kommunikációs m veletek szükségesek.)

Direkt megnevezés
x

P1 Küld(x, P2)

adatátviteli rendszer

y

P2 Fogad(y, P1)

I.2-3. ábra Kommunikáció direkt megnevezéssel

Közvetett (indirekt) kommunikáció esetén a partnerek nem egymást nevezik meg, hanem egy közvetít objektumot, (pl. postaládát, vagy csatornát). A postaládán keresztül bonyolódó kommunikációt a I.2-4 szemlélteti.

Indirekt megnevezés (postaláda)
L postaláda
x y

P1 Küld(x,L)

adatátviteli rendszer

P2 Fogad(y,L)

I.2-4. ábra Kommunikáció indirekt megnevezéssel A postaláda egy általában véges, de elméletileg esetleg korlátlan befogadóképesség , az üzenetek sorrendjét megtartó (FIFO) tároló, amely a Küld - Fogad, (betesz - kivesz) m veletpárral kezelhet . A Küld(,) m velet a saját címtartományban elhelyezked üzenetet a postaláda következ szabad tárolóhelyére másolja. Ha a postaláda tele van, ürülésig várakozik. A Fogad(,) m velet a postaládában legrégebben várakozó üzenetet kimásolja a megadott, saját címtartománybeli címre, helyét pedig felszabadítja. A csatorna olyan kommunikációs objektum, amelyik két folyamatot kapcsol össze. A csatorna lehet egyirányú (szimplex), osztottan kétirányú, azaz egyidej leg egyirányú, de az

I. Az operációs rendszer, mint absztrakt, virtuális gép

27

irány változtatható (félduplex), vagy kétirányú (duplex). Tartalmazhat 0, véges, vagy végtelen kapacitású átmeneti tárolót. Egy véges tárolókapacitású duplex csatorna egyenérték két

véges befogadóképesség postaládával, amelyeket csak két folyamat használ, egyiket egyik irányú, másikat az ellenkez irányú adatcserére. A postaláda és a csatorna lazítja a kommunikáló folyamatok közötti csatolást, lehet vé teszi, hogy olyan folyamatok is információt cseréljenek, amelyek nem ismerik egymást

Aszimmetrikus megnevezés (kapu a fogadó oldalon)

x

P1 Küld(x,P2)

adatátviteli rendszer

y

P2 Fogad(y)

I.2-5. ábra Kommunikáció aszimmetrikus megnevezéssel Aszimmetrikus megnevezés esetén (I.2-5. ábra) az egyik folyamat, az adó vagy vev , megnevezi, hogy melyik folyamattal akar kommunikálni, a másik partner viszont egy saját be/kimeneti kaput (port) használ, amelyiket - ha csak egy van - nem is kell megneveznie. Ha az üzenet vev je használ bemeneti kaput, akkor a m veletek alakja

Küld(,), Fogad(). Ez a megoldás azokban az esetekben hasznos, amikor a fogadó folyamat nem ismeri a küld t, de a küld ismeri a fogadót, pl. egy ügyfél folyamat szolgáltatási kérelmet küld egy szolgáltató folyamatnak (kliens - szerver modell). A fordított irányú aszimmetria alkalmazására pedig egy feladat lebontását és szétosztását végz menedzser folyamat és több, munkáért verseng végrehajtó folyamat kapcsolata lehet példa. A küld a kimeneti portjára küldi az elvégzend feladatot tartalmazó üzenetet, a fogadó pedig az els ráér feldolgozó lesz (farmer - worker modell).

I. Az operációs rendszer, mint absztrakt, virtuális gép

28

y

Üzenetszórás

P2 Fogad(y)

x

P1 Küld(x,mindenki)

adatátviteli rendszer

z

P3 ...
w

Fogad(z)

Pn Fogad(w)

I.2-6. ábra Kommunikáció üzenetszórással Csoportkommunikáció esetén az üzenet küld je folyamatok (esetleg kommunikációs objektumok) egy csoportját nevezheti meg vev ként. Ilyenkor egyetlen üzenetküld m velet végrehajtása azt eredményezi, hogy az üzenetet a csoport valamennyi tagja megkapja. Az üzenetszórás (broadcasting) logikailag a csoportkommunikáció azon esete, amikor az egyetlen m velettel elküldött üzenet a rendszer valamennyi folyamatához eljut (I.2-6. ábra). A csoportkommunikáció lehet sége lényegesen egyszer síti a küld m veleteit, ha több

folyamattal akarja ugyanazt az információt közölni. Bizonyos típusú fizikai átviteli közegeken a csoportkommunikáció igen hatékonyan valósítható meg (pl. sín-topológiájú összeköttetések, rádiókommunikáció). I.2.6.2. Szemantikai konzisztencia Most azt szeretnénk tisztázni, hogy mi történik a kommunikációs m veletek végrehajtásakor, milyen hatása van a m veleteknek az egyes folyamatok állapotterére (változókra, kommunikációs objektumokra), milyen minimális konzisztencia-feltételt kell betartani a m veletek megvalósításakor.

Az üzenetváltásos modell akkor került el térbe, amikor több számítógépet kapcsoltak össze egy rendszerré adatátviteli vonalon, vagy hálózaton keresztül. Ilyenkor fel kell készülni olyan rendkívüli esetekre is, hogy a partner folyamatot futtató számítógépet esetleg kikapcsolták, vagy a nagyobb távolságot áthidaló átvitel közben az adatok sérülnek, hiszen a hibalehet ség lényegesen nagyobb, mint az egyetlen chipben, dobozban, esetleg egyetlen kártyán elhelyezked egységek közötti átvitel esetén. Az üzenettovábbítás m veleteivel szemben ezért elvárás, hogy a m veletet végrehajtó folyamat ne fagyjon be sem átviteli hibák, sem a partner

I. Az operációs rendszer, mint absztrakt, virtuális gép

29

folyamatok kiesése esetén, és a kommunikációs m veletek helyes, vagy hibás végrehajtásáról szerezzen tudomást. A m veletek helyességének visszajelzésére az egyik szokásos megoldás egy állapotkód visszaadása, amelynek egyik értéke a helyes végrehajtás, további értékei pedig az el forduló hibakódok lehetnek. Egy másik megoldás lehet a logikai processzor szintjén megvalósított hiba-megszakítás, ami a folyamat végrehajtását a hiba felderítéséhez és a folyatáshoz szükséges információk tárolását követ en egy hibakezelési pontra (exception handler) irányítja. A partner folyamat kiesését szokásosan a m veletekre megszabott id korlát (time-out) figyelésével észlelik. A kommunikációs m velet az id korlát elérésekor hibajelzéssel akkor is befejez dik, ha a partner válaszának hiánya, vagy a kommunikációs közeg hibája miatt az adatcsere még nem történt meg. A folyamatok programozásához megfelel rugalmasságot nyújt, ha lehet ség van a kommunikációs m veletekre vonatkozó id korlát paraméterként történ megadására. A hibajelzéssel és id korláttal kiegészítve közvetlen kommunikáció esetén a m veletek a következ alakúak: Küld(,,,), illetve

Fogad(,,,). Az id korlát lehetséges értékei között célszer a 0 és a értéket is megengedni. A 0 várakozás például akkor hasznos, ha egy fogadó folyamat m ködésének egy pontján csak akkor akar üzenetet fogadni, ha azt már elküldték, egyébként van más teend je. A várakozás pedig az olyan folyamatok esetén szükséges, amelyiknek nincs teend je, amíg valaki egy üzenettel el nem indítja.

A Küld m velet szemantikáját tekintve els sorban az a kérdés merül fel, hogy okozhat-e várakozást a m velet, és mi az, ami az adatcseréb l a m velet befejez désekor, azaz a folyamat továbblépésekor már megtörtént. A lehetséges megoldásváltozatok közül az egyik véglet: a Küld m velet akkor fejez dik be, amikor az adatcsere teljes egészében befejez dött, a küldött üzenet rendben megérkezett és a helyére került. Ez a megoldás általában a Küld m velet várakozását is okozhatja, a végrehajtás során ellen rzések, esetleg hibajavítások is történhetnek. A megoldás ahhoz hasonló, mint amikor tértivevényes levelet küldünk valakinek, és addig nem lépünk tovább, amíg a tértivevény aláírva vissza nem érkezett. A másik véglet az lehet, hogy a Küld befejez désekor az üzenet csupán bekerült a kommunikációs rendszerbe, de további sorsáról semmit sem tudunk. Ilyenkor a Küld m velet

I. Az operációs rendszer, mint absztrakt, virtuális gép

30

általában sohasem várakozik. Ez a megoldás ahhoz hasonló, mint amikor valakinek úgy küldünk levelet, hogy egyszer en bedobjuk a postaládába, és továbbmegyünk. A két véglet között számos köztes megoldás létezhet (pl. az üzenet elhagyta azt a processzort, amelyiken a küld folyamat fut stb.).

Valamennyi megoldás esetén be kell tartani azt a minimális konzisztencia-feltételt, hogy amennyiben nincs hibajelzés, az elküldött üzenetet tartalmazó terület a küld folyamat saját memóriájában (a tartalma) a Küld befejez dése után ­ akár a következ utasítással ­ felülírható legyen. Ennek már nem szabad hatással lennie az elküldött üzenetre.

A Fogad m velet megvalósításai általában várakozást okozhatnak abban az esetben, ha még nem érkezett üzenet. A m velet egyszeri végrehajtása pontosan egy üzenetet helyez el a fogadó folyamat saját memóriájába akkor is, ha esetleg több várakozó üzenet van a folyamat számára a kommunikációs rendszerben. Az üzenetek érkezési sorrendben fogadhatók, minden üzenet csak egyszer, azaz a fogadás törli az üzenetet a kommunikációs rendszerb l. Postaláda, illetve bemeneti kapu használata esetén kérdés, hogy a fogadó tudomást szerez-e arról, hogy ki az üzenet küld je. Erre általában szükség van, hiszen az üzenetre gyakran választ kell küldeni. Ha a kommunikációs rendszer ezt az információt nem közli automatikusan, a folyamatoknak kell gondoskodniuk arról, hogy a küld azonosítható legyen az üzenet tartalma alapján. I.2.6.3. Járulékos (implicit) szinkronizáció A kommunikációs m veletek általában a kommunikációban résztvev folyamatok

szabadonfutásának korlátozását okozzák. Az egyes m veletekkel járó szinkronizációs mellékhatás els sorban a kommunikációs rendszer átmeneti tárolójának (puffer) kapacitásától függ.

Tárolás nélküli átvitel esetén a kommunikációs rendszer csak közvetít, de a Küld és Fogad m veleteknek be kell várnia egymást ahhoz, hogy az információcsere megtörténhessen. A két folyamat ezen utasításaira egyidej ség érvényes (a Küld és a Fogad randevúja).

Véges kapacitású tároló alkalmazása bizonyos keretek között kiegyenlíti a küld és fogadó folyamatok sebességingadozásait. A fogadó folyamat várakozik, ha üres az átmeneti tároló, a

I. Az operációs rendszer, mint absztrakt, virtuális gép

31

küld

folyamat pedig akkor, ha nincs szabad hely a tárolóban. Ugyanazon üzenet

elküldésének meg kell el znie az üzenet fogadását, tehát ezen m veletekre sorrendiség (precedencia) érvényesül. Emellett egy rövid távú szinkronizációs hatás is érvényesül, magának a tárolónak a kezelése általában kölcsönös kizárással valósul meg, azaz két folyamat ugyanazon kommunikációs objektumra hivatkozó kommunikációs m veleteinek

megvalósítási részleteit szemlélve egyes szakaszokra kölcsönös kizárás áll fenn.

Végtelen kapacitású tároló (csak modellben létezik) esetén a küld folyamatnak sohasem kell várakoznia, egyébként a véges kapacitású tárolóra elmondottak érvényesek.

I.2.7. Holtpont
Amikor az els multiprogramozott rendszereket üzembe állították, id nként nehezen

reprodukálható, ezért nehezen megkereshet és megmagyarázható hibákat tapasztaltak. Ezek egyik típusa a lyukas kölcsönös kizárásokból (foglaltságjelz bit) származott. A másik

jelenségtípus a rendszerek id nkénti "lefagyása". Ahogy a kölcsönös kizárás korrekt megoldása is alapos analízist, majd elméletileg megalapozott megoldást igényelt, a lefagyási jelenségekkel kapcsolatban is hasonló volt a helyzet. Az elemzések kiderítették, hogy folyamatok bizonyos esetekben úgy akadhatnak össze, hogy csak egymást tudnák továbbindítani, de mivel mindegyik a másikra vár, senki nem tud továbblépni. Az ilyen helyzeteket holtpontnak (deadlock) nevezzük. Holtpont bekövetkezésének igen gyakran kicsi a valószín sége. A hiba éppen ezért alattomos, és nehezen reprodukálható. Vegyük hát alaposabb vizsgálat alá a jelenséget!

I.2.7.1. Mi a holtpont? Ha az együttm köd folyamatok szinkronizációs és kommunikációs m veleteit kell

körültekintés nélkül alkalmazzuk, könnyen el idézhetjük a rendszer folyamatainak teljes, vagy részleges befagyását.

Tegyük fel, hogy egy rendszerben két er forrást (pl. az NY nyomtatót és az M mágnesszalag egységet) használ két folyamat a következ módon:

I. Az operációs rendszer, mint absztrakt, virtuális gép

32

P1 folyamat: ... Lefoglal(M) ... Lefoglal(NY) ... ... Felszabadít(M) Felszabadít(NY) ... -----------------------

P2 folyamat: ... Lefoglal(NY) ... Lefoglal(M) ... ... Felszabadít(NY) ... Felszabadít(M) .... -----------------------

Tegyük fel, hogy a két folyamat együttfutásakor P1 már lefoglalta M-t, de még nem foglalta le NY-t, P2 pedig lefoglalta NY-t de még nem foglalta le M-t. (Ilyen helyzet kialakulhat, hiszen a folyamatok futására nincs korlátozás, de ugyanezért nem biztos, hogy minden együttfutáskor kialakul.) A továbbiakban P1 el bb-utóbb le akarja foglalni NY-t is, de nem kaphatja meg, mert az már P2-é, P2 pedig le akarja foglalni M-t is, de az már P1-é. Így mindkét folyamat arra fog várni, hogy a másik elengedje az er forrását, de addig egyik sem tud eljutni, mert el bb er forráshoz kellene jutnia. A két folyamat között keresztreteszelés alakul ki, ebb l a helyzetb l egyik sem tud továbblépni.

Vegyük észre, hogy ha a folyamatok úgy futnak le, hogy valamelyiknek sikerül mindkét er forrást megszerezni, akkor már nem alakulhat ki holtpont, hiszen akkor ez a folyamat el bb-utóbb fel is szabadítja azokat és ekkor ­ ha már közben igényelte, várakozás után ­ a másik is hozzájuk juthat. A holtpont kialakulásának valószín sége annál nagyobb, minél hosszabb a folyamatok azon szakasza, amikor még csak egyik er forrást birtokolják. Nem alakulhatna ki holtpont, ha a folyamatok egyetlen m velettel kérnék el mindkét er forrást. Vegyük észre azt is, hogy akkor sem alakulhatna ki holtpont, ha mindkét folyamat azonos sorrendben kérné el a két er forrást.

- 33 -

A

fenti,

legegyszer bb

esetnél

lényegesen

bonyolultabban

és

áttételesebben

is

összegubancolódhatnak folyamatok amiatt, hogy közös er forrásaik vannak, illetve üzeneteket várnak egymástól.

Általánosságban azt mondjuk, hogy egy rendszer folyamatainak egy H részhalmaza holtponton van, ha a H halmazba tartozó valamennyi folyamat olyan eseményre vár, amelyet csak egy másik, H halmazbeli folyamat tudna el idézni.

Megjegyzések: A definíció általános, az esemény nem csak er forrás felszabadulása lehet, hanem tetsz leges más valami, amire egy folyamat várakozni tud. A rendszerben lehetnek futó, él folyamatok a holtponton lév k mellett, tehát nem biztos, hogy a befagyás teljes. Nem biztos, hogy a holtpont a folyamatok minden együttfutásakor kialakul, s t az esetek jelent s részében igen kis valószín séggel alakul ki. Ezért a jelenség nehezen reprodukálható, alattomos hibaforrás. A holtpont egyrészt azon funkciók kiesését okozza, amelyeket a befagyott folyamatok látnak el, másrészt csökkenti a rendszer teljesít képességét, hiszen a befagyott folyamatok által lekötött er forrásokhoz a többi folyamat sem tud hozzájutni.

A továbbiakban olyan rendszerekre szorítkozunk, amelyek folyamatai között csak az er forrásokért folytatott verseny miatt van kapcsolat (ide tartozhat tetsz leges, kölcsönös kizárás jelleg szinkronizáció is).

I.2.7.2. Holtpont er forrásokért verseng rendszerekben Az er forrásokért verseng rendszerekre a következ rendszermodellt állíthatjuk fel: A rendszerben véges számú és típusú er forrást kell felosztani az értük verseng folyamatok között. Az er források osztályokba (típusokba) sorolhatók. Egyes típusokhoz egyetlen er forráspéldány tartozik (egypéldányos er források), más típusú er forrásokból több példány áll rendelkezésre (többpéldányos er források), amelyek használati értékükben azonosak. Egy folyamat számára közömbös, hogy azonos típuson belül melyik er forrás-példányokat

- 34 -

használja. Jellegzetes egypéldányos er források például a speciális perifériák (rajzgép, kisebb rendszerek egyetlen nyomtatója), rendszertáblák, multiprogramozott rendszerek processzora stb. Jellegzetes többpéldányos er források: memória, a rendszer egyenérték nyomtatói, munkaterület a mágneslemezen. Az er forrásokat használati módjuk szerint csoportosíthatjuk megosztottan használható vagy csak kizárólagosan használható er forrásokra. A megosztottan használható er források állapota menthet és visszaállítható (preemptable), így esetleg elvehet k egy folyamattól, és kés bb visszaadhatók úgy, hogy a folyamat zökken mentesen folytatódhasson (ld. CPU, memória). Ilyen er forrásokra megfelel id beli ütemezéssel (a használat id beli megosztásával) látszólag párhuzamos használatot lehet szimulálni. A csak kizárólagosan használható er források állapota nem menthet (non-preemptable), így nem vehet k el a folyamattól anélkül, hogy a folyamatot visszaküldenénk egy korábbi állapotába (ld. nyomtató). A folyamatok az er források használata során a következ lépéseket hajtják végre: Igénylés. Az igénylés rendszerhívással történik. Legyen az er forráskérés m velete a Kér. Egy kéréssel általános esetben (többpéldányos er források) akár valamennyi er forrásfajtából is lehet egyidej leg több példányt igényelni. Ha a rendszerben n fajta er forrás van, a m velet paramétere egy n elem vektor, amelynek minden eleme az adott er forrásfajtából igényelt mennyiséget jelöli (Kér (n1,n2,...,nn) ). Az igény nem teljesíthet , ha bármelyik er forrástípusból nem adható ki a folyamatnak az igényelt mennyiség. Ilyenkor a folyamat várakozni kényszerül. Tekintve, hogy az er forráspéldányok egyenérték ek, a folyamat a szabad példányok bármelyikét megkaphatja. A folyamat azonban a megkapott konkrét példányokat használja, amelyeket tehát most már azonosítani kell. A Kér m velet ezért általános esetben er forrás-típusonként egy-egy tömböt is visszaad, amelyik az odaadott er forráspéldányok azonosítóit tartalmazza. A felszabadítás - amennyiben nem az adott típus valamennyi birtokolt példányának felszabadítása a folyamat szándéka - a konkrét példányok felszabadítását kell, hogy jelentse. Használat.

- 35 -

Felszabadítás. Általános esetben a Felszabadít m velet két formáját célszer bevezetni. A Felszabadít (E1,E2,...,Em) paraméterei er forrástípusok. A m velet a felsorolt er forrástípusokból a folyamat által birtokolt valamennyi példányt felszabadítja. A Felszabadít (V1,V2,...,Vn) alakban a paraméterek Vi vektorok, amelyek az egyes er forrástípusokból felszabadítandó példányok azonosítóit tartalmazzák. Amennyiben az er forrásokra várakoztak más folyamatok, ezek közül valamelyik megkaphatja a felszabaduló er forrásokat és továbbléphet.

A holtpont kialakulásának szükséges feltételei: Kölcsönös kizárás: legyenek olyan er források a rendszerben, amelyeket a folyamatok csak kizárólagosan használhatnak. Foglalva várakozás: legyen olyan folyamat, amelyik lefoglalva tart er forrásokat, miközben más er forrásokra várakozik. Nincs er szakos er forrás-elvétel a rendszerben, azaz minden folyamat addig birtokolja a megkapott er forrásokat, amíg saját jószántából fel nem szabadítja azokat. Körkörös várakozás: a rendszerben lév folyamatok közül létezik egy olyan {P0, P1, ... Pn} sorozat, amelyben P0 egy P1 által lefoglalva tartott er forrásra vár, Pi egy Pi+1re, végül Pn pedig P0-ra vár.

A rendszer pillanatnyi állapotát er forrás-foglalási gráffal (resource allocation graph) modellezhetjük (I.2-7. ábra).

R1

R2

foglalás kérés P1 P2 P3

R3 R4

- 36 -

I.2-7. ábra Er forrásfoglalási gráf A gráfnak kétféle csomópontja van: er forrás (Ri, téglalap) és folyamat (Pi, kör). Ugyancsak kétféle él található a gráfon. Irányított él vezet Pi folyamattól Rj er forráshoz (kérés él), ha Pi már kérte Rj-t, de még nem kapta meg. Irányított él vezet Ri-t l Pj-hez (foglalás él), ha Pj birtokolja (megkapta és még nem szabadította fel) Ri-t. Többpéldányos er források esetén a példányokat megfelel számú ponttal jelezzük az er forrástípust jelképez téglalapon belül. Annak érzékeltetésére, hogy a folyamat konkrét példányt birtokol, de csak típust kér, a foglalás éleket a konkrét példányt jelképez pontból indítjuk, a kérés éleket pedig csak a téglalap határvonaláig vezetjük.

Az er forrás-foglalási gráf a rendszer m ködése során folyamatosan változik, ahogyan új kérések és foglalások történnek. A gráf elemzése alapján következtethetünk holtponthelyzetek fennállására. Körkörös várakozás esetén (holtpont 4. szükséges feltétele) a gráfon is irányított kör van. Abban az esetben, ha minden er forrás egypéldányos, a gráfon kimutatható kör egyben elégséges feltétel is a holtpont fennállására. Többpéldányos esetben azonban kör jelenléte nem jelenti feltétlen azt, hogy a rendszerben holtpont van. A I.2-8. ábra b.) oldalán a kör ellenére látjuk, hogy mind R1, mind R2 egy-egy példányát olyan folyamat birtokolja, amelyik nem várakozik (P2 és P4), így van esély rá, hogy felszabadítja az er forrást. A körben szerepl P1 és P2 tehát nem feltétlen egymásra vár, hanem P2, illetve P4 által okozott esemény hatására is továbbléphetnek.

R1

R2

R1

P2

P1

P2

P3

P1

P3

a.) Holtpont

b.) Nincs holtpont

P4

R3

R2

- 37 -

I.2-8. ábra Irányított kört tartalmazó gráf holtponttal és holtpont nélkül

Az ábra a.) oldalán ezzel szemben olyan helyzetet látunk, amelyben mindhárom folyamat várakozik, és bármelyiküket csak a három várakozó valamelyike tudná egy er forrásfelszabadítással továbbengedni.

Miután megalkottuk a holtpont-probléma vizsgálatára alkalmas rendszermodellt az er forrásokért verseng folyamatok esetére, foglalkozzunk azzal a kérdéssel, hogy mit

kezdhetünk a problémával. Háromféle alapállásunk lehet: Nem veszünk tudomást a problémáról és nem teszünk semmit (strucc algoritmus) Észrevesszük, ha holtpont alakult ki, és megpróbáljuk feloldani (detektálás és feloldás) Védekezünk a holtpont kialakulása ellen. Ezen belül is két lehet ségünk van: megel zés, amikor is strukturálisan holtpontmentes rendszert tervezünk, amelyben a szükséges feltételek valamelyikének kizárása miatt eleve nem alakulhat ki holtpont elkerülés, amikor is a rendszer futás közben csak olyan er forrás-kéréseket elégít ki, amelyek nem vezetnek holtpontveszélyhez. I.2.7.3. A strucc algoritmus Az "algoritmus" elnevezését Tanenbaum és Woodhull könyvéb l kölcsönöztük. Els reakciónk valószín leg az, hogy ez az alapállás meglehet sen hanyag magatartásforma, hiszen ismert hibalehet séget hagyunk tudatosan a rendszerben. Bizonyos típusú rendszerek ahol élet- és vagyonbiztonság a tét - nem is engedhet meg az ilyen tervez i megközelítés. Más, kisebb kockázatú esetekben - ahol megengedhet a "kiszállunk, beszállunk, és akkor biztos jó lesz ..." szemlélet, azaz különösebb veszteség nélkül újraindítható a rendszer azonban mégis reális lehet a probléma figyelmen kívül hagyása.

Mint a mérnöki praxisban annyiszor, azt kell mérlegelnünk, mekkora a probléma és milyen áron tudjuk megoldani. Az esetek többségében a holtpont kialakulásának valószín sége meglehet sen kicsi, bár néhány tényez ezt a valószín séget jelent sen megnövelheti. Minél többféle típusú, de típusonként minél kevesebb er forrásért minél több folyamat verseng, a holtpont kockázata általában annál nagyobb. Minél hosszabb ideig tartják lefoglalva a

- 38 -

folyamatok az er forrásokat, és minél inkább alkalmazzák a "rákérést", azaz újabb er források igénylését a már használtak mellé, a holtpont kialakulásának valószín sége ugyancsak annál nagyobb. Ugyanakkor látni fogjuk, hogy az észlelés és feloldás a kritikus rendszerekben nem jelent min ségi különbséget a probléma figyelmen kívül hagyásához képest, a megel zésnek és elkerülésnek pedig hatékonyságromlásban jelentkez ára van.

Végül is tervez i mérlegelés kérdése, hogy egy rendszerben milyen alapállás és milyen megoldás a legmegfelel bb. Tény, hogy az általános célú, közismert operációs rendszerek általában nem foglalkoznak a problémával, legfeljebb a bels funkciók tervezésekor

törekedtek arra, hogy a holtpont kialakulásának valószín ségét csökkentsék. A felhasználó együttm köd folyamatainak holtpontra jutása ellen azonban nincsenek beépített védelmek.

I.2.7.4. A holtpont észlelése A rendszer futása során több jel mutathat arra, hogy holtpont van. Bizonyos funkciók nem élnek, a rendszer lelassul, parancsokra nem, vagy nagyon lassan reagál. A gyanú felmerülésekor - vagy óvatosságból gyakrabban, például bizonyos id közönként, vagy eseményekhez kötötten is - elindíthatunk a rendszerben egy holtpontdetektálást végz programot, amelyik felderíti, hogy vannak-e a rendszerben holtponton lév folyamatok, és ha igen, melyek azok. Ha vannak, akkor a holtpontot érdemes felszámolni, ami többnyire rombolással jár, de annyival jobb a helyzet, mint a probléma figyelmen kívül hagyása esetén, hogy nem kell a teljes rendszert újraindítani, hanem megúszhatjuk néhány folyamatra kiható beavatkozással.

A detektálás indítása történhet az operációs rendszer által automatikusan, vagy kezel i parancsra. Megjegyzend , hogy ha nagyon óvatosak vagyunk, akkor az operációs rendszer akár minden er forráskérés teljesítése után ellen rizheti, nem vezetett-e holtpontra a kérés teljesítése. Ezzel azonban körülbelül akkora adminisztrációs terhelést (overhead) okozunk a rendszerben a detektáló program gyakori futtatásával, mintha az elkerülés érdekében minden kérés teljesítése el tt hajtanánk végre ellen rzéseket, tehát akkor már inkább az elkerülést válasszuk.

- 39 -

Milyen algoritmus szerint m ködjön a detektáló program? Érdemes megkülönböztetni az egypéldányos és többpéldányos er források esetét, ugyanis egyszer bb algoritmust alkalmazhatunk, ha valamennyi er forrásfajtából csak egyetlen példányunk van.

Kezdjük az általános esettel, azaz a többpéldányos er forrásokkal. Mutassuk be a problémát egy példán. Egy adott fajtájú er forrásból a rendszerben van 10 példány. A rendszerben négy folyamat (P1,...,P4) m ködik. A pillanatnyi helyzetet a I.2-9. ábra szemlélteti.

FOGLAL P1 P2 P3 P4 4 1 3 1

KÉR 4 0 4 2

I.2-9. ábra Többpéldányos er források pillanatnyi allokációja és igénylése Az er források közül 9 a FOGLAL oszlop szerint már ki lett osztva, 1 szabad példánya van még a rendszernek. P1, P3 és P4 várakozik a KÉR oszlop szerinti példányra (nyilván egyik sem szolgálható ki, mert nincs elég szabad példány), P2 pedig fut. Vajon vannak-e a rendszerben holtponton lév folyamatok? P2 nyilván nincs holtponton, hiszen fut. P1, P3 és P4 várakozik, de vajon egymásra várnak-e, vagy van még esélyük a továbblépésre? A válasz némi elemzést igényel. Meg kell vizsgálni a továbblépési esélyeket. Pillanatnyilag csak P2 fut, fel tud szabadítani er forrásokat,

legfeljebb annyit, amennyi van nála. Ez 1 példány, ezzel együtt a rendszernek 2 szabad példánya lesz. Ez mire elég? P1-nek nem, P3-nak nem, de P4-nek igen. Így P4-nek van továbblépési esélye. Ha továbblép, arra is van esély, hogy felszabadítsa a nála lév er forrásokat. Már nála van egy, a továbblépéshez kap kett t, tehát három példányt tud felszabadítani. Mivel a rendszernek nincs további szabad példánya, ebben az esetben összesen ez a 3 lesz szabad. Sajnálatosan ez sem P1, sem P3 számára nem elég, így innen már nincs

- 40 -

továbblépési lehet ség. Az elemzés végeredménye tehát az, hogy P1-nek és P3-nak nincs továbblépési esélye, P1 és P3 tehát holtponton van.

Az elemzésnek ezt a gondolatmenetét általánosítja a Coffman és szerz társai által 1971-ben publikált algoritmus több er forrástípusra.

Legyen a folyamatok száma N, az er forrástípusok száma M. Tároljuk a szabad er források számát a SZABAD nev , M elem vektorban, az egyes mátrixban, a

folyamatok által már lefoglalt er források számát a FOGLAL, NxM elem várakozó kéréseket a KÉR, NxM elem mátrixban.

Jelentse FOGLAL[i] a Pi folyamat által az egyes er forrásfajtákból foglalt mennyiséget tároló vektort, azaz a FOGLAL mátrix i-edik sorát, hasonlóan KÉR[i] pedig a Pi folyamat egyes er forrás-típusokra vonatkozó várakozó kéréseit, az a KÉR mátrix i-edik sorát. Az algoritmus alapgondolata, hogy szisztematikusan megkeresi azokat a folyamatokat, amelyeknek továbblépési esélye van, ha végül maradnak olyan folyamatok, amelyeknek nincs, azok holtponton vannak. A keresés minden lépésében olyan folyamatot keres, amelynek várakozó kérései kielégíthet k a rendelkezésre álló er forrásokkal. Ha van ilyen folyamat, akkor az kivehet a további vizsgálatból (van továbblépési esélye), a rendelkezésre álló készlet pedig megnövelhet a folyamat által birtokolt er forrásokkal (hiszen van rá esély, hogy a továbbinduló folyamat ezeket felszabadítja), és a következ folyamat a megnövelt készlettel kereshet . Az algoritmus úgy zárul, hogy nem talál újabb folyamatot. Ennek egyik lehetséges oka, hogy elfogytak a folyamatok - ilyenkor nincs holtpont a rendszerben - másik lehetséges oka, hogy nincs köztük olyan, amelyiknek elég az éppen rendelkezésre álló készlet - ilyenkor a megmaradt folyamatok holtponton vannak.
Megjegyzés: Nem kell, hogy lefusson.

Az algoritmus egy GY JT

nev , M elem vektort használ a továbbléptethet folyamatoktól logikai

visszakapott er források akkumulálására, valamint egy TOVÁBB nev , N elem

változó-vektort azoknak a folyamatoknak a kipipálására, amelyeket továbbléptethet nek talált. Az algoritmus 2. lépésében a KÉR[i] <= GY JT reláció (két vektor összehasonlítása) akkor igaz, ha KÉR[i],[j] <= GY JT [j] fennáll minden j-re (j=1,2,...,M), azaz a kérést valamennyi er forrásfajtából ki lehet elégíteni.
Megjegyzés: ????

- 41 -

A Coffman-féle holtpontdetektáló algoritmus

1. Kezd értékek beállítása: GY T := SZABAD

TOVÁBB[i] := hamis minden i-re (i=1,2,...,N) 2. Továbblépésre esélyes folyamatok keresése: Keress i-t, amelyre (TOVÁBB[i] = hamis ÉS KÉR[i] <= GY JT ); Ha van ilyen i, akkor GY JT := GY JT + FOGLAL[i];

TOVÁBB[i] := igaz; ismételd a 2. lépést; Egyébként folytasd a 3. lépéssel 3. Kiértékelés: Ha TOVÁBB[i] = igaz minden i-re (i=1,2,...,N), akkor NINCS HOLTPONT; Egyébként A Pi folyamatok, amelyekre TOVÁBB[i] = hamis, HOLTPONTON VANNAK.

A fenti algoritmus természetesen egypéldányos er források esetén is m ködik, azonban ilyenkor egyszer bb, kedvez bb komplexitású algoritmus is használható. Egypéldányos er források esetén holtpont van a rendszerben, ha az er forrás-foglalási gráfon kör alakul ki, és azok a folyamatok vannak holtponton, amelyek a kör csomópontjaiban találhatók. Az irányított gráfok kördetektáló algoritmusai hatékonyabbak az általános esetre bemutatott Coffman-algoritmusnál, ezért egypéldányos esetben inkább ezek használata célszer .

I.2.7.5. A holtpont feloldása Ha a holtpont már kialakult, általában nem számolható fel veszteségek nélkül. Ahhoz, hogy a holtponton lév folyamatok továbbléphessenek, illetve az általuk foglalt er források

felszabaduljanak, valamilyen er szakos megoldáshoz kell folyamodni. A lehetséges megoldásokat közelíthetjük a folyamatok, illetve az er források oldaláról, de az eredmény

- 42 -

minkét esetben hasonló. Ha a folyamatok oldaláról közelítünk, ki kell l ni (abortálni kell) egy vagy több folyamatot a holtponton lév k közül, ezeket egyszersmind megfosztjuk valamennyi er forrásuktól. Az er források oldaláról közelítve a feloldáshoz er szakkal kell elvenni er forrásokat egy vagy több folyamattól. Ennek következménye - hacsak az er forrás állapota nem menthet - az, hogy az érintett folyamatokat vagy kezd pontjukra kell visszaállítani (ez egyenérték az abortálással), vagy legalábbis egy olyan állapotba kell visszaküldeni, ahol még nem használták az er forrásokat, és ahonnan ismételhet a végrehajtásuk (rollback). A holtpont feloldását végezheti a rendszer kezel je manuálisan, vagy megkísérelheti az operációs rendszer automatikusan.

A holtpont feloldásakor - bármelyik oldalról közelítünk is - a következ találkozunk: Dönteni kell, hogy radikális, vagy kíméletes megoldást válasszunk-e

problémákkal

A radikális megoldás, ha valamennyi, a holtpontban érintett folyamatot felszámoljuk. Ez biztosan megszünteti a holtpontot és nem merül fel kiválasztási költség. Mérlegelés esetén meg kell vizsgálni, hogy a választott folyamatok felszámolása elegend -e a holtpont megsz néséhez. Ezen túlmen en az áldozatok kiválasztásához

szempontrendszert kell felállítani, és ennek megfelel

döntési algoritmust kell

végrehajtani, ami id t és er forrásokat igényel. A mérlegelend szempontok között szerepelhet például, hogy nincsenek-e menthet állapotú er források, amelyek elvétele esetén nincs szükség abortálásra, vagy visszaállításra a lehet legkevesebb folyamatot kelljen felszámolni milyen a folyamatok prioritása mekkora részét végezték már el feladataiknak (ez veszne kárba). Biztosítani kell a folyamatok visszaállíthatóságát Ha arra gondolunk, hogy egy folyamat létrehozhat és módosíthat fájlokat, egyéb maradandó változásokat okozhat a rendszerben, s t holtpontra jutásakor félkész, inkonzisztens állapotot hagyhat maga után, az sem nyilvánvaló, hogy egy folyamat következmények nélkül abortálható és újraindítható. Közbens visszaállítási pontok

létrehozásához pedig legalább a végrehajtáskor érintett utolsó visszaállítási ponthoz tartozó állapotot tárolni kell. Ezt a problémát az operációs rendszer önmaga

- 43 -

gyakorlatilag nem tudja megoldani, a folyamatokat is fel kell készíteni arra a lehet ségre, hogy sor kerülhet újraindításukra, vagy visszaállításukra.

I.2.7.6. A holtpont megel zése Ha a holtpont kialakulása nem engedhet meg egy rendszerben, védekezni kell ellene. Ennek egyik módja, hogy gondosan tervezünk, és valamelyik szükséges feltétel kiküszöbölésével strukturálisan holtpontmentes rendszert hozunk létre, ezzel megel zzük a holtpont kialakulását. Az így tervezett rendszernek futás közben nem kell foglalkoznia az er források kiadásakor a pillanatnyi helyzethez igazodó döntéshozatallal, hiszen m ködése során eleve nem alakulhat ki holtpont.

Vegyük sorra, milyen lehet ségeink vannak arra, hogy a holtpont kialakulásának szükséges feltételeit kiküszöböljük!

Kölcsönös kizárás feltétele A kiküszöbölésre gyakorlatilag nincs esélyünk. Bizonyos mozgásterünk van abban, hogy csökkentsük a kizárólagosan használt er források számát. Például egy rekord vagy fájl esetén, amelyeket egyébként indokoltan nyilvánítunk er forrásnak, megengedhetjük az olvasások egyidej ségét. Egy másik lehet ség a kizárólagos használati szakaszok oszthatatlan m veletként történ megvalósítása, és ezeknek az oszthatatlan m veleteknek a sorosítása. Erre példa az operációs rendszerekben gyakran alkalmazott fájlonkénti nyomtatás. A folyamatok a nyomtató hosszútávú lefoglalása helyett egy saját használatú fájlban tárolják a nyomtatandó adatokat, majd a fájlt küldik el a nyomtató várakozási sorába. A sort egy önálló nyomtató folyamat dolgozza fel fájlonként sorosan, így a fájlok között nincs konfliktus, és nem szükséges a nyomtató er forrásként történ lefoglalása. Finomabb léptékben a

folyamatok közös memóriájának PRAM modellje is ezt az elvet követi, de alkalmazhatjuk a megoldást rekordok felülírása esetén is. Megjegyzend , hogy a kölcsönös kizárás problémáját ezek a megoldások nem szám zik a rendszerb l, csupán az id távot csökkentik, és a megoldás felel sségét a rendszer egy jól kézbentartható területére korlátozzák. A nyomtató sorába való beláncolás, vagy a PRAM cs vezetékébe való parancselhelyezés ugyanis maga is igényli, hogy rövidebb távú kölcsönös kizárások érvényesüljenek.

- 44 -

Foglalva várakozás Foglalva várakozás akkor alakul ki, ha egy folyamat már birtokol er forrást, és ekkor kér újabbat, amire várakoznia kell. Ez a helyzet elkerülhet , ha minden folyamat betartja azt a szabályt, hogy az egyidej leg szükséges valamennyi er forrását egyetlen rendszerhívással kéri el. A szabály betartásával megel zhet a holtpont, de ára az er forrás-kihasználás

jelent s romlása. Ha ugyanis a folyamatnak van olyan futási szakasza, amelyiken több er forrást is használ egyidej leg, akkor ezek mindegyikét már akkor le kell foglalnia, amikor az els re szüksége van. Így a többit akkor is leköti, amikor még nem használja ket.

Nincs er szakos er forrás-elvétel Ezt a feltételt menthet állapotú er források esetén küszöbölhetjük ki problémamentesen, ellenkez esetben az er forrás elvétele egyben a folyamat abortálását, vagy legalábbis egy korábbi állapotba való visszaállítását okozza. Az egyik er szakos megoldás az er forrást kér folyamatot bünteti. Amelyik folyamat olyan er forrást kér, amire várnia kellene, várakozásba is kerül, egyben valamennyi már birtokolt er forrását is elveszti, és csak akkor folytatódhat, ha ezeket is, és a kérteket is egyidej leg vissza tudja kapni. A másik megoldás az er forrást kér folyamatot igyekszik el nyben részesíteni. Ha a

folyamat kérése nem elégíthet ki a szabad készletb l, a rendszer a már amúgy is várakozó folyamatoktól elvett er forrásokkal igyekszik teljesíteni a kérést. Ha így sem sikerül, csak akkor kell a kér folyamatnak várakoznia, ami persze azt jelenti, hogy közben t le is vehetnek el er forrást. A folyamat akkor folytatódhat, ha a kért és az esetleg közben elvett er forrásokat is egyszerre megkaphatja.

Körkörös várakozás Ez a feltétel kiküszöbölhet , ha a folyamatok mindegyike betart egy viselkedési szabályt, amelyik kicsit bonyolultabb, mint az "egyszerre kérem az er forrásaimat", de kevésbé rontja az er forrás-kihasználást. Az körkörös várakozás az er forrás-foglalási gráfon keletkez körnek felel meg. Egy ilyen kör alakja: Pi Rj Pi+1 Rj+1 .... Pi+n Rj+n Pi Tegyük fel, hogy a folyamatok megegyeznek az er forrástípusok sorszámozásában. Viselkedjen minden folyamat úgy, hogy csak nagyobb sorszámú er forrást kérhet azoknál,

- 45 -

amelyek már a birtokában vannak. Vegyük észre, hogy ekkor a gráf minden útja csak növekv sorszámú er forrásokon át vezethet (a folyamatokba befutó élek kisebb sorszámú er forrástól indulnak, mint ahova a folyamatból kivezet élek befutnak), így ezek az utak sohasem záródhatnak, nem alakulhat ki kör az er forrás-foglalási gráfon.

I.2.7.7. A holtpont elkerülése A holtpont elleni védekezés másik lehet sége a megel zés mellett az elkerülés. Az elkerülés alapelve, hogy a rendszer minden er forrás-igény kielégítése el tt mérlegeli, hogy nem vezete holtpontveszélyre a kérés teljesítése, másszóval, fennmarad-e a biztonságos állapot. Így lehetséges, hogy egy kérést akkor sem elégít ki, és a kér egyébként elegend folyamatot várakoztatja, ha

számú szabad példány áll rendelkezésre a kérés teljesítéséhez. Az

elkerülés tehát a védekezés egy dinamikus formája, amelyik futási idej helyzetelemzést igényel. Nem vezet be az er forrás-kihasználást rontó megkötéseket, ugyanakkor adminisztrációs teljesítményveszteséget okoz.

Kérdés, hogy milyen algoritmussal dönthet el, hogy egy kérés kielégítése esetén biztonságos marad-e a rendszer állapota. Ismét csak érdemes megkülönböztetni az egypéldányos, illetve többpéldányos er források esetét. Kezdjük ismét az általános, többpéldányos esettel és egy egyszer példával!

A rendszerben négy folyamatunk van (P1,...,P4), és egy er forrástípusból tíz példányunk. Az aktuális helyzetet a I.2-10. ábra mutatja. Tudjuk, hogy futásuk során az egyes folyamatoknak egyidej leg legfeljebb hány példányra lesz szükségük (MAXIMÁLIS IGÉNY). A már megkapott mennyiséget a FOGLAL oszlop mutatja, a MÉG KÉRHET oszlop pedig a két el z különbsége, legfeljebb ekkora igénnyel jelentkezhet a továbbiakban egy-egy folyamat. Ennek alapján a rendszernek még 3 szabad példánya van. Pillanatnyilag P3 jelentkezett 2 példányért, és P4 1 példányért. A szabad mennyiségb l mindkét kérés kielégíthet . Vizsgáljuk meg, mi történik, ha kielégítjük mindkét kérést!

- 46 -

MAXIMÁLIS IGÉNY P1 P2 P3 P4 7 7 8 6 FOGLAL 3 0 1 3

MÉG KÉRHET 4 7 7 3 KÉR 0 0 2 1

I.2-10. ábra Többpéldányos er források maximális igény el rejelzésével P3 sora a táblázatban ekkor 8,3,5,0 lesz, P4-é pedig 6,4,2,0. A rendszernek nem marad szabad példánya. Mi történhet ezután? A legrosszabb esetben a következ pillanatban minden

folyamat bejelenti a még kérhet maximális igényét, azaz P1 4, P2 7, P3 5, P4 pedig 2 példányt kér. A rendszernek nincs szabad példánya, egyik kérést sem tudja kielégíteni, tehát holtpont alakul ki. Mindkét kérés kielégítése tehát veszélyes, a rendszer holtpontra juthat.

Most tegyük fel, hogy csak P4 kérését teljesítjük. Ekkor a táblázatban P3 sora 8,1,7,2 marad, és a folyamat várakozik, P4 sora pedig 6,4,2,0 lesz. A rendszernek marad 2 szabad példánya. Tegyük fel most is, hogy a következ pillanatban a legrosszabb eset lép fel, azaz minden folyamat jelentkezik a még kérhet maximumra vonatkozó igényével, azaz P1 4, P2 7, P3 további 5, tehát összesen 7 (ez úgy értend , hogy ha megkapja a várt 2 példányt, a következ pillanatban kérhet újabb 5-öt), P4 pedig 2 példányt kér. Mit tehet most a rendszer? P4 kérését teljesíteni tudja a 2 szabad példánnyal. P4 már nem kérhet többet, feltételezhetjük, hogy lefut és felszabadítja a nála lév valamennyi er forrást. Ekkor a rendszernek 6 szabad példánya lesz. A még várakozó folyamatok közül ki tudja elégíteni P1 kérését (4), P1 is lefuthat, és felszabadítja er forrásait. Ezután a rendszernek már 9 szabad példánya lesz. Ezzel már P2 vagy P3 kérése is teljesíthet vé válik, bármelyiket teljesítjük el ször, a folyamat lefuthat és újabb er források szabadulnak fel, tehát az utolsónak hagyott folyamat igénye is teljesíthet lesz. Megállapíthatjuk tehát, hogy ha a rendszer továbbra is kell óvatosságot tanúsít, akkor nem alakul ki holtpont. Az az állapot tehát, amelyik az eredeti helyzetb l P4 kérésének teljesítésével kialakul, biztonságos.

- 47 -

A bemutatott gondolatmenetet követi a problémát több er forrásfajtára általánosan megoldó bankár-algoritmus (Dijkstra, 1965). A név onnan származik, hogy a probléma hasonló a bankok er forrás-kihelyezési problémájához. Hitelez k fordulnak a bankhoz beruházásaik finanszírozásához szükséges hitelekért. Közlik a maximális hiteligényüket, amelyet a bank a megvalósítás ütemében folyósít. A bank véges t kével rendelkezik. A hitelt csak az az ügyfél tudja visszafizetni, aki be tudta fejezni a beruházást, ehhez pedig szüksége van arra, hogy el bb-utóbb hozzájusson az igényelt hitel teljes összegéhez. Ha a bankár nem elég óvatos, ott állhat egy csomó félkész beruházással és kiürült kasszával, a hitelek következ részletét nem tudja folyósítani, ügyfelei pedig nem tudnak törleszteni. Hogy viselkedjen a bankár, hogy elkerülje az ilyen helyzeteket (kicsit életszer tlenül tételezzük fel, hogy az állam segítségére sem számíthat)?
Megjegyzés: Nem veszed a humorom?

Legyen a folyamatok száma N, az er forrástípusok száma M. A folyamatoktól elvárjuk, hogy el zetesen bejelentik er forrás-típusonként a maximális igényeiket. Ezt a MAX nev , NxM elem mátrixban tartjuk nyilván. Tároljuk a szabad er források számát a SZABAD nev , M elem vektorban, az egyes

folyamatok által már lefoglalt er források számát a FOGLAL, NxM elem mátrixban. Jelöljük a MAX - FOGLAL mátrixot MÉG névvel. MÉG ugyancsak NxM méret , és elemei azt jelölik, hogy egy folyamat egy er forrásból még legfeljebb mekkora igényt nyújthat be. Jelentse FOGLAL[i] a Pi folyamat által az egyes er forrásfajtákból foglalt mennyiséget tároló vektort, azaz a FOGLAL mátrix i-edik sorát, hasonlóan MÉG[i] a MÉG mátrix i-edik sorát. A folyamatok várakozó kéréseit a KÉR mátrix (NxM elem , i-edik sora a Pi folyamat várakozó kérésének adatait tartalmazza, jelölése KÉR[i] ) tárolja.

Az algoritmus arra ad választ, hogy egy kiválasztott folyamat várakozó kérése kielégíthet -e úgy, hogy a rendszer biztonságos állapotban maradjon.

Az algoritmust két szinten tárgyaljuk. Az els szint ellen rzi a kérést, és ha érdemes vele foglalkozni, módosítja a nyilvántartást a kérés teljesítése után kialakuló értékekre. Ezután megvizsgálja, hogy ez az állapot biztonságos-e. Ha igen, a kérés teljesíthet , a folyamat

- 48 -

megkapja az er forrásokat. Ha nem, a folyamatnak várakoznia kell, a nyilvántartást pedig vissza kell állítani a vizsgálat kezdetén fennálló értékekre.

- 49 -

Bankár-algoritmus (els 1. A kérés ellen rzése:

szint):

Ha KÉR[i] >= MÉG[i] akkor STOP; (HIBA, a folyamat hazudós) Ha KÉR[i] >= SZABAD akkor VÉGE; (nincs elég, várni kell) 2. A nyilvántartás átállítása az új állapotra: SZABAD := SZABAD - KÉR[i]; FOGLAL[i] := FOGLAL[i] + KÉR[i]; 3. Biztonságosság vizsgálata

4.

Ha nem BIZTONSÁGOS akkor állapot visszaállítása: SZABAD := SZABAD + KÉR[i]; FOGLAL[i] := FOGLAL[i] - KÉR[i]; VÉGE; (várni kell) Egyébként kérés teljesítése; VÉGE;

Biztonságosság vizsgálata (2. szint, el z B1. Kezd értékek beállítása: GY JT := SZABAD

3. pont):

LEFUT[i] := hamis minden i-re (i=1,2,...,N) B2. Továbblépésre esélyes folyamatok keresése: Keress i-t, amelyre (LEFUT[i] = hamis ÉS MÉG[i] <= GY JT ); Ha van ilyen i, akkor GY JT := GY JT + FOGLAL[i];

LEFUT[i] := igaz; ismételd a B2. lépést; Egyébként folytasd a B3. lépéssel

B3. Kiértékelés: Ha LEFUT[i] = igaz minden i-re (i=1,2,...,N), akkor

- 50 -

BIZTONSÁGOS Egyébként NEM BIZTONSÁGOS; (A Pi folyamatok, amelyekre LEFUT[i] = hamis, holtpontra juthatnak)

A második szinten a biztonságosság vizsgálatát mutatjuk be. Az algoritmus alapgondolata, hogy szisztematikusan megkeresi azokat a folyamatokat, amelyek a legkedvez tlenebb esetben is le tudnak futni. A legkedvez tlenebb eset az, ha az adott pillanatban mindenki a még kérhet maximális igénnyel jelentkezik. A keresés minden lépésében olyan folyamatot keres, amelynek a még kérhet maximális igénye is kielégíthet a rendelkezésre álló

er forrásokkal. Ha van ilyen folyamat, akkor az kivehet a további vizsgálatból (biztosan le tud futni), a rendelkezésre álló készlet pedig megnövelhet a folyamat által birtokolt

er forrásokkal (hiszen a folyamat lefutása után ezek felszabadulnak), és a következ folyamat a megnövelt készlettel kereshet . Az algoritmus úgy zárul, hogy nem talál újabb folyamatot. Ennek egyik lehetséges oka, hogy elfogytak a folyamatok - ilyenkor az állapot biztonságos, hiszen minden folyamat biztosan le tud futni - másik lehetséges oka, hogy nincs köztük olyan, amelyiknek elég az éppen rendelkezésre álló készlet - ilyenkor az állapot nem biztonságos, hiszen a legkedvez tlenebb esetben a maradék folyamatok holtpontra juthatnak.

A biztonságosságot vizsgáló algoritmus egy GY JT

nev , M elem vektort használ a lefutó

folyamatoktól visszakapott er források akkumulálására, valamint egy LEFUT nev , N elem logikai változó-vektort azoknak a folyamatoknak a kipipálására, amelyeket

továbbléptethet nek talált. Az algoritmusban a vektorok összehasonlítása (pl. MÉG[i] <= GY JT reláció) akkor igaz,

ha MÉG[i],[j] <= GY JT [j] fennáll minden j-re (j=1,2,...,M), azaz a kérést valamennyi er forrásfajtából ki lehet elégíteni.

Az algoritmus emlékeztet a korábban tárgyalt Coffman-féle holtpontdetektáló algoritmusra, a két algoritmus megszületésének id rendje azonban tárgyalási sorrendünkkel ellentétes.

- 51 -

A detektáló algoritmusokhoz hasonlóan egypéldányos er források esetére ismét csak érdemes az er forrás-foglalási gráfhoz fordulni, mert ott hatékonyabb algoritmusokat találhatunk. A biztonságosság vizsgálatához szükséges el zetes információ egypéldányos esetben azt jelenti, hogy fogja-e használni a folyamat az adott er forrást. Ennek jelölésére bevezethetünk a gráfon egy új éltípust, az úgynevezett lehetséges kérés élet. Ez az él folyamattól er forráshoz vezet, és jelöli, hogy egy folyamat kérheti az adott er forrást. A biztonságosság vizsgálatakor a legrosszabb eset az, ha valamennyi lehetséges kérés fellép, azaz a lehetséges kérések valódi kérésekké válnak. Ha tehát egy kérés teljesítését mérlegeljük, kísérletképpen módosítjuk az er forrás-foglalási gráfot, mintha odaadtuk volna az er forrást (egy kérés él iránya megfordul és foglalás éllé válik). Ha most a lehetséges kérés éleket is figyelembe véve kört találunk a gráfon, a kérés teljesítésekor kialakuló állapot nem biztonságos, a kérést nem szabad teljesíteni. Az elmondottakat a I.2-11. ábra szemlélteti két folyamat és két er forrás egyszer esetére. A lehetséges kérés éleket szaggatott vonal jelzi. A kezdeti állapotot az a.) ábra mutatja. El ször P1 kéri R1-et. A vizsgálathoz a rendszer bejegyzi a b.) ábrának megfelel en az R1 P1 foglalás élet. A gráfon láthatóan nincs kör, a kérést a rendszer teljesíti.

R1

P1 R1 R1

P2

c.)
R2 P1 P2 P1 P2 R1

R2

R2

a.)

b.)

P1

P2

d.)
R2

I.2-11. ábra Potenciális kérések az er forrás-foglalási gráfon

- 52 -

Ezután két lehetséges továbblépést mutat a c.) és a d.) ábra. Ha P2 kéri R2-t, a c.) ábra szerinti helyzet alakul ki a kérés teljesítése esetén. A gráfon kör van, az állapot nem biztonságos, a kérést nem szabad kielégíteni. P1 ugyanis bármikor kérheti R2-t, P2 pedig R1-et, és ekkor a rendszer holtpontra jutna. Ha viszont P1 kéri R2-t, a d.) ábra szerinti helyzet áll el , a gráfon nincs kör, a rendszer biztonságos állapotban marad, a kérés teljesíthet .

I.2.7.8. Kombinált stratégiák A holtpont-probléma kezelésének ismertetett módszerei kombináltan is alkalmazhatók. A rendszer er forrásai például osztályokba sorolhatók. Az egyes osztályok sorszámozottak, a folyamatok betartják, hogy különböz osztályokhoz tartozó er forrásokat csak az

osztálysorrend szerint foglalnak le. Az egyes osztályokon belül más-más megel zési vagy elkerülési stratégia is használható. Egy ismert rendszer például a következ megoldást alkalmazta: Az er forrásokat négy osztályba sorolták: Bels er források (pl. rendszertáblák, leírók stb.). Mivel ez a rendszerfolyamatokat érinti, a megoldás a rendszertervez kezében van, aki betartathat egy egyezményes foglalási sorrendet, így az osztályon belül is alkalmazható a sorrendezésen alapuló megel zés. Memória. Menthet állapotú er forrás (háttértárra másolás, visszatöltés), er szakos elvétel használható megel zésre. Készülékek és fájlok. Az osztályon belül elkerülés alkalmazható a használati igény el zetes bejelentése alapján. Munkaterület a lemezen. Általában ismert méret igények vannak, egyszerre kell kérni a szükséges méretet, nincs "rákérés". Az osztályok között a felsorolás szerinti sorrendet kellett betartani.

I.2.7.9. Kommunikációs holtpontok Holtponthelyzet nem csak er forrás-használat miatt alakulhat ki, hanem a folyamatok tetsz leges olyan együttm ködése során, amelyik a folyamatok körkörös várakozására vezethet.

- 53 -

Tételezzünk fel például egy kliens-szerver architektúrájú rendszert, ahol az ügyfelek és a szolgáltatók is folyamatok. Ebben a rendszerben az ügyfél küld egy kiszolgálást kér üzenetet a szolgáltatónak, majd vár a válaszra. Ha a szolgáltatói és ügyfél szerepeket nem sikerül statikusan elkülöníteni, el fordulhat, hogy egy folyamat egyik kapcsolatában ügyfél, egy másikban azonban szolgáltató. Az is el állhat, hogy egy szolgáltatónak egy ügyfél kiszolgálása közben ügyfélként kell más szolgáltatóhoz fordulnia. El fordulhat, hogy ilyenkor az ügyfél-kiszolgáló lánc záródik, tehát egy kiszolgálást kér folyamat a választ csak akkor kaphatja meg, ha a közben - esetleg több áttételen keresztül - hozzá, mint kiszolgálóhoz érkez kérésre válaszol. Ha a folyamat erre nincs felkészítve, ebben az esetben holtpont alakul ki. Az ehhez hasonló problémák kezelésében segítenek a folyamaton belül kialakítható szálak, amelyek különösen a szerver szerepet (is) betölt folyamatok programozásakor hasznosak.

A kommunikáció által okozott várakozások ugyancsak szemléltethet k irányított gráfokkal, amelyek csomópontjai folyamatok, irányított élei pedig a várakozó folyamattól vezetnek ahhoz a folyamathoz, amelyiknek az üzenetet küldenie kellene. Ilyen várakozási gráf (wait-for graph) egyébként az er forrás-foglalási gráf redukálásával is létrejöhet. A kördetektáló algoritmusok értelemszer en itt is használhatók.

I.2.8. Éhezés
A holtpont mellett a folyamatok m ködésének egy másik zavara lehet az éhezés. Az éhezés azt jelenti, hogy egy várakozó folyamat nincs ugyan holtponton, de nincs rá garancia, hogy véges id n belül továbbindulhasson.

A szinkronizációs eszközök tárgyalásakor bevezettük az ütemezés fogalmát. Azokban az esetekben, amikor több várakozó folyamat közül kell továbbindulót választani, a választást gyakran nem célszer a véletlenre bízni, hanem meghatározott algoritmus szerint kell dönteni. A rendszer a szemaforokhoz, er forrásokhoz, egyéb szinkronizációs objektumokhoz várakozási (ütemezési) sorokat rendel, amelyeket meghatározott algoritmusok szerint kezel (így még az esetleges véletlen kiválasztás is tudatossá tehet ).

Az ütemezés leggyakoribb alap-algoritmusai az érkezési sorrend szerinti (FIFO) és a prioritásos ütemezés.

- 54 -

Egy ütemezést tisztességesnek (fair) nevezünk, ha garantálja, hogy egy várakozási sorból minden folyamat véges id n belül továbbindulhat, amennyiben a rendszerben véges számú folyamat m ködik és a rendszerben nincs holtpont vagy hibás folyamat (amelyik pl. nem enged el egy megszerzett er forrást). Ellenkez esetben az ütemezés tisztességtelen (unfair). Tisztességes ütemezés például az érkezési sorrend szerinti kiszolgálás, tisztességtelen a statikusan rögzített prioritás szerinti kiszolgálás (ilyenkor nincs garancia arra, hogy egy alacsony prioritású folyamat valaha is hozzájut az er forráshoz, ha mindig van nála magasabb prioritású igény).

Megjegyzések: Az éhezés nem jelent holtpontot. Küls eseményre (pl. kezel i beavatkozás) való meghatározatlan idej várakozás nem jelent sem éhezést, sem holtpontot. Tisztességtelen ütemezés tudatosan is alkalmazható, csak számolni kell a kevésbé fontos funkciók kiesésével a terhelés (a futtatandó folyamatok száma) növekedésekor.
Megjegyzés: Nem szinkronizációs!!!!

I.2.9. Klasszikus konkurens problémák
Tekintsünk át néhány olyan feladatot, amelyek megoldása jellegzetesen együttm köd folyamatokra vezet! Tapasztalatok szerint a folyamatok használatával megoldható gyakorlati problémák többsége visszavezethet ezeknek a klasszikussá vált feladatoknak valamelyikére. Éppen ezért ezek a problémák egy-egy újabb együttm ködési modell, szinkronizációs, vagy kommunikációs eszköz kidolgozása esetén gyakran szerepelnek mint teszt és benchmark esetek. I.2.9.1. Termel - fogyasztó probléma A rendszerben egymással párhuzamosan egy termelési folyamat, valamint egy fogyasztási folyamat zajlik. A Termel saját ritmusában és algoritmusa szerint el állít valamit (pl.

adatokat), amit egy raktárba tesz (Buffer). A Fogyasztó saját ritmusában, saját algoritmusa szerint m ködve felhasználja a termel következ t mindig a raktárból véve el . által el állított terméket (adatokat), a soron

- 55 -

Buffer Termel Fogyasztó

Termel : loop ; ; endloop

Fogyasztó: loop ; ; endloop

I.2-12. ábra A termel -fogyasztó probléma

A Termel és a Fogyasztó sebességére nincs kikötésünk. A Buffer kiegyenlít hatású, kisebb sebességingadozások esetén nem akadnak fenn a folyamatok, legfeljebb a Termel lelassulása esetén a raktárkészlet fogy, a Fogyasztó lelassulása esetén pedig növekszik. Mivel a Buffer kapacitása véges, elvárjuk, hogy ha megtelt a Buffer, a Termel várjon a következ elem betételével, amíg felszabadul egy hely, illetve ha üres a Buffer, a Fogyasztó várjon, amíg érkezik egy elem. Ugyancsak elvárjuk, hogy az elemeket a Fogyasztó ugyanabban a sorrendben dolgozza fel, ahogyan a Termel el állította azokat. Hogyan tudnánk olyan programot írni egy adott programozási nyelvet és operációs rendszert feltételezve, amelyik végrehajtásakor a Termel végre, és a Buffer kezelése is helyes lesz? I.2.9.2. Írók - olvasók problémája Egy adatszerkezetet (például egy hirdet táblát, vagy egy fájlt) többen kívánnak írni is és olvasni is. Az írások és olvasások csak bizonyos rendszabályok betartása esetén nem zavarják össze egymást: Egyidej olvasásokat tetsz leges számban megengedünk, mert nem zavarják egymást. Írás és olvasás nem folyhat egyidej leg, mert aki olvas, félig átírt dolgokat látna, amib l valami zagyvaság jöhet ki. Több írás nem folyhat egyidej leg, mert ha két írás átlapolódhatna, a végeredmény egyik fele az egyik írás eredménye lehet, a másik fele a másiké, ami nagy valószín séggel megint csak zagyvaságot eredményez. és a Fogyasztó párhuzamosan hajtódhat

- 56 -

Ennek megfelel en elvárjuk, hogy írás csak akkor kezd dhessen, ha sem írás, sem olvasás nincs folyamatban, olvasás viszont kezd dhet ha más olvasások már folyamatban vannak.

Író Író Író Író Író Író

Fájl

Olvasó Olvasó Olvasó Olvasó Olvasó

I.2-13. ábra Az írók-olvasók problémája Megjegyezzük, hogy ésszer lehet még egy kikötés annak elkerülésére, hogy a folyamatosan érkez olvasók miatt az írni szándékozók a végtelenségig ne jussanak szóhoz: ha van

várakozó író, akkor újabb olvasó már ne kerüljön sorra, amíg a várakozó írók nem végeztek (írók - olvasók II. probléma).

Hogyan tudnánk olyan programot írni, amelyik kifejezi az írók és olvasók párhuzamos m ködését és biztosítja a megadott szabályok betartását (nyelv, operációs rendszer)? I.2.9.3. Az étkez filozófusok problémája Egy tibeti kolostorban öt filozófus él. Minden idejüket egy asztal körül töltik (I.2-14. ábra). Mindegyikük el tt egy tányér, amib l sohasem fogy ki a rizs. A tányér mellett jobb és bal oldalon is egy-egy pálcika található a rajz szerinti elrendezésben.

- 57 -

I.2-14. ábra Az étkez filozófusok problémája A filozófusok életüket az asztal melletti gondolkodással töltik. Amikor megéheznek, étkeznek, majd ismét gondolkodóba esnek a következ megéhezésig. És ez így megy az id k végezetéig. Az étkezéshez egy filozófusnak meg kell szereznie a tányérja melletti mindkét pálcikát. Ennek következtében amíg eszik, szomszédai nem ehetnek. Amikor befejezte az étkezést, leteszi a pálcikákat, amelyeket így szomszédai használhatnak.

Hogyan kell viselkedniük a filozófusoknak, hogy ne vesszenek össze a pálcikákon, ne kerüljenek olyan megoldhatatlan probléma elé, amin fennakadva többé nem tudnak sem enni, sem gondolkozni (pl. ha mindegyikük felveszi mondjuk a bal pálcikát és nem teszi le, az holtponthelyzet), és egyikük se haljon éhen, azaz ha enni akar, ez egy id után a

leggyámoltalanabbjuknak is sikerüljön? Hogyan tudnánk olyan programot írni, amelyik leírja a filozófusok viselkedését?

I.2.9.4. Adatfolyamok illesztése Ez a probléma a CPASCAL (Concurrent Pascal) nyelv bevezetésének szokásos mintapéldája. Eredetileg arról szól, hogy adott egy kártyaolvasó és egy nyomtató. A kártyaolvasóba helyezett kártyák egy hosszabb szöveget tartalmaznak, amit ki kell nyomtatni. Maga a szöveg egy bekezdésekre tagolt karakterfolyam, amelyben az új bekezdést speciális karakter jelzi (NL). Egy kártya 80 karaktert tud tárolni, a kártyaolvasóról tehát nyolcvan karakteres blokkokban érkezik az adatfolyam. A szöveget lapokra tördelve, lapszámozással ellátva, a bekezdéseket külön sorban kezdve, soronként 132 pozíciót használva kell kinyomtatni.

- 58 -

A probléma általánosabban úgy fogalmazható meg, hogy egy beérkez , sajátosan strukturált és ütemezett adatfolyamot egy más struktúrájú és ütemezés adatfolyamként kell továbbítani. Modern változatban könnyen fogalmazhatnánk hasonló feladatot szövegfájlok kezelése, vagy hálózati adatátviteli rendszerek protokolljainak illesztése témakörében.

Klasszikus adatfolyam-illesztési feladat kártyaolvasó és nyomtató között

Program

I.2-15. ábra Adatfolyamok illesztésének problémája A kérdés ismét az, hogy hogyan írhatunk olyan programot, amelyik maximális sebességgel tudja m ködtetni mindkét oldalon a készülékeket, és minél tisztább szerkezetben tudja megoldani az eltér struktúrák illesztését. (Ennél a feladatnál még a folyamatokra bontás sem adott. Ha a feladat megoldásával próbálkozunk, érdemes kísérletet tenni el ször egyetlen szekvenciális programmal, azaz egyetlen folyamattal, majd legalább két, egy olvasó és egy nyomtató folyamatra való felbontással.)

A bemutatottakon kívül további klasszikus problémákat is találhatunk az irodalomban. Valamennyinek lényeges eleme, hogy több aktív szerepl (több folyamat) együttm ködését kell megoldani és leírni. Ajánljuk az olvasónak, hogy vágjon neki, és próbáljon kedvenc programnyelvén (persze annak pszeudo változata is megteszi) megoldási kísérleteket tenni a fenti feladatokra. Egyel re tételezze fel, hogy írhat olyan programrészleteket, amelyek majd valahogy folyamatként, egymással párhuzamosan fognak végrehajtódni. Válasszon

valamilyen együttm ködési modellt (közös memória vagy üzenetváltás), és használja a már bemutatott szinkronizációs, kommunikációs eszközök közül azokat amelyeket jónak lát. Tételezze fel, hogy ezek rendszerhívásként elérhet ek.

I.2.10. Folyamatokból álló rendszerek leírása nyelvi szinten

- 59 -

Ahhoz, hogy az el z megfelel

pontban bemutatott feladatokat megoldó programokat írhassunk,

nyelvi eszközök szükségesek annak kifejezésére, hogy mely programrészletek

lesznek önálló folyamatok, azaz hajtódhatnak végre párhuzamosan, valamint milyen m veletekkel oldják meg a kommunikáció lés a szinkronizáció problémáit. Ezek nélkül csak "kézi" módszereink vannak: egyenként megírjuk a programokat, valahogyan elindítjuk ket folyamatként az operációs rendszer kezel i felületér l, és a szinkronizációs, kommunikációs rendszerhívásokat megpróbáljuk a nyelvi interfészen keresztül elérni.

Konkurens (párhuzamosan végrehajtható ágakat tartalmazó) programok készítésének igénye el ször az operációs rendszerek programozásakor vet dött fel, azonban a multiprogramozott, majd a multitaszkos rendszerek megjelenésekor az alkalmazásfejleszt k ilyen irányú igénye is megjelent. A nyelveknek egyrészt tehát a párhuzamosság leírására, másrészt a folyamatok együttm ködésének leírására kellett modelleket és eszközöket adniuk. A következ kben az erre kialakult megoldásokat mutatjuk be röviden.

I.2.10.1. A párhuzamosság leírása Tegyük fel, hogy egy feladat megoldása során olyan m veleteket használunk fel, amelyeket már nem tudunk, vagy nem akarunk tovább bontani, részletezni (elemi folyamatok). A megoldáshoz meg kell adnunk, azt is, hogy ezek az elemi m veletek milyen vezérléssel (milyen sorrendben, milyen feltételek mellett stb.) hajtandók végre. Ha folyamatokban gondolkozunk, lehetnek ezek között párhuzamosan végrehajthatók, és lehetnek olyanok, amelyek csak egy másik elemi folyamat után hajthatók végre. Ahhoz képest, hogy akár minden elemi folyamat párhuzamosan futhatna, egy sereg precedenciát írunk el . A végeredményt egy precedencia-gráfon ábrázolhatjuk (16. ábra).

- 60 -

U0

U1

U3

U4 U8 U2 U6

U5

U7

16. ábra Precedencia-gráf

A precedencia-gráfon bármelyik irányított úton elhelyezked elemi folyamatok (Ux) egyetlen folyamattá is összevonhatók. Bármely két utasítás, amelyet nem köt össze irányított út, párhuzamosan is végrehajtódhat, azaz konkurens.

A precedencia-gráf szemléletesen kifejezi a párhuzamosságot, de síkban kell ábrázolni, míg a programszövegek lineáris sorozatok.

A programnyelvi leírásra az els javaslat a fork - join operátorok alkalmazása volt. A fork C utasítás hatására a végrehajtás párhuzamosan elágazik, az egyik szál a következ utasításon, a másik a C címkén folytatódik. A join N utasítás pedig N szál összefuttatását oldja meg. Az utasítás több szálon is végrehajtódhat. Minden végrehajtása eggyel csökkenti az utasításhoz rendelt számláló értékét, amelynek kezd értéke N volt. Az utasítás minden t végrehajtó szálat elnyel, amíg a számláló le nem nullázódik, csak azt engedi tovább, amelyik a nullára csökkenést el idézte.

A fork-join páros a goto-hoz hasonló anomáliákhoz vezetett (áttekinthetetlen vezérlési szerkezet), így helyette egy strukturált utasítás bevezetését javasolták, a parbegin-parend

- 61 -

párt. Ez a megoldás valóban áttekinthet bbé és biztonságosabbá tette a nyelvi leírást, de nem írható le vele tetsz leges precedencia-gráf, csak járulékos szinkronizációs m veletekkel.

A megvalósított els konkurens nyelvben, a CPascal-ban (és kés bb több másikban is, pl. MODULA, ADA) az explicit folyamatdeklaráció (process declaration) használatos annak kifejezésére, hogy egy programegység folyamatként, azaz más hasonló programegységgel párhuzamosan hajtódhat végre. A folyamatdeklarációk igen hasonlóak az eljárásdeklarációkhoz.

I.2.10.2. Az együttm ködés nyelvi modelljei A párhuzamos végrehajtású programrészek az egygépes rendszerekben közös memórián m ködhettek együtt - megfelel szinkronizációt feltételezve. A szemaforra alapozott

szinkronizációt a párhuzamosságot megenged magasszint nyelvekben nem találták elég biztonságosnak, hiszen például egy kölcsönös kizárás megoldása esetén a programozó következmények nélkül elfelejtheti a használatát, vagy ami legalább olyan kellemetlen, elfelejtheti a felszabadítását. A szemafor és a védett objektum között csak a programozó(k) tudatában van kapcsolat, így az objektumot bármelyik folyamat nyugodtan használhatja a szemafor lefoglalása nélkül.

A kölcsönös kizárás megoldására az els javasolt magasszint eszköz a kritikus régió volt. A javaslat szerint a változódeklarációkban jelölni kellett a védett közös változókat (shared), az ilyen változókra pedig csak a változóhoz tartozó kritikus régióban hivatkozhat a program (ha X shared-ként deklarált: region X do......od). A megoldás lehet vé teszi a fordítási id ben történ ellen rzést az esetleges régión kívüli hivatkozások felderítésére.

A kritikus régióval meglehet sen nehézkesen kezelhet k azok a helyzetek, amelyekben egy feltételvizsgálattól teszik függ vé a folyamat a szakaszba való belépést, de már magának a feltételvizsgálatnak az elvégzéséhez is a védett változót kell használni. Erre kínált megoldást a feltételes kritikus régió.

A következ

jelent s lépcs fok a CPascal nyelvi modellje, amelyik az absztrakt

adatszerkezetek adatrejtési elveit (encapsulation) és a konkurens végrehajtás lehet ségét

- 62 -

ötvözte. Bevezette a monitor rendszertípust. A monitor három f összetev b l áll. Vannak privát, kívülr l el nem érhet adatai, ezeken saját, kívülr l is hívható eljárásai tudnak csak m veletet végezni, valamint vagy egy inicializáló kódrésze. A kívülr l hívható eljárásokra garantált, hogy kölcsönös kizárással futnak le, és várakozási sor szervez dik rájuk. Az eljárásokban a feltételes kritikus szakasz funkciójának megvalósítására egy speciális változótípust (queue) vezettek be, amely delay és continue m veletekkel kezelhet . Egy delay(x:queue) m velet várakozásba helyezi a hívó folyamatot, és lehet vé teszi, hogy más lépjen be a kritikus szakaszba. A folyamat addig vár, amíg valaki végre nem hajt egy continue(x:queue) m veletet. Megjegyzend , hogy a continue hatása nem rz dik meg, ha nincs várakozó, a jelzés elszáll.

Két maradandó hatású nyelvi modell - nem konkrét nyelv - született a 70-es években: az együttm köd folyamatok CSP (Cooperating Sequential Processes) és az elosztott

folyamatok DP (Distributed Processes) modell.

Mindkett t az motiválta, hogy megjelentek az egymással adatátviteli vonalakon, vagy hálózaton összekapcsolt számítógépek, és a folyamatmodellt és a folyamatok

együttm ködésének modelljét lehet leg úgy kellett kialakítani, hogy azonos processzoron futó, és különböz processzorokon futó folyamatokra is alkalmazható legyen.

A CSP modell üzenetváltással együttm köd

folyamatokat kezel, bevezeti az

rzött

parancs(guarded command), az alternatíva, és az ismétléses alternatíva szerkezeteket, amelyekkel a több belépési ponttal rendelkez , konkurens hívásoknak kitett szerver típusú folyamatok m ködése is leírható, amelyek nem tudják el re, hogy a következ honnan fog érkezni. hívásuk

A DP modell hasonló alapokról indul, a folyamatok közötti kommunikációt azonban az eljáráshívás és paramétercsere szemantikájára alapozza (távoli eljáráshívás, remote procedure call).

A '80-as évek elején érett szabvánnyá az ADA nyelv, amely szintetizálta a kor valamennyi elméleti eredményét. A párhuzamos programrészek létrehozására taszkok deklarálhatók,

- 63 -

amelyek a távoli eljáráshívás elvén m ködhetnek együtt. A szerver típusú folyamatok a CSP modellben javasolt alternatív szerkezetet (select), és az rzött parancsoknak megfelel

szerkezetet (when F => accept ) használhatják a többfel l várható hívások fogadására.

A további nyelvek a párhuzamosság és az együttm ködés alapsémái tekintetében már nem hoztak átüt újdonságot. Napjainkban a legelterjedtebben a C nyelvi könyvtárak formájában megvalósított PVM (Parallel Virtual Machine), vagy MPI (Message Passing Interface), valamint a Java nyelv modelljei használatosak a programszinten párhuzamos végrehajtás területén.

I.1. Tárak

1

I.1. Tárak
Annak a virtuális gépnek, amelyet az operációs rendszer nyújt az alkalmazások és a kezel k számára, eddig els sorban a processzorával, illetve processzoraival ismerkedtünk. Egy valós, vagy virtuális gép hasonlóan fontos alkotórészei a tárak.

I.1.1. Tárhierarchia

Egy számítógépes rendszerben a tárak hierarchikus rendbe szervezettek. A hierarchia legalsó szintjén a fizikai processzor regiszterei helyezkednek el, fölötte sorrendben az operatív tár (memória), a háttértárak, vagy másodlagos tárolók, valamint a küls tárak, vagy harmadlagos tárolók találhatók. Minél magasabb hierarchia-szinten van egy tár, általában annál nagyobb mennyiség adat befogadására alkalmas, viszont ­ gyakran a hosszabb keresési id

következtében ­ annál lassabb m ködés , és annál nagyobb egységekben címezhet . Ugyancsak különböznek az egyes szintek a tárolt információ élettartama és tárolási biztonsága tekintetében is. A processzor-regiszterekben tárolt adatok élettartama néhány utasítás, a memóriatartalomé jó esetben a program futási ideje. A programokat túlél , maradandó adatokat fájlok tárolják, egy aktualitási id szakban a másodlagos tárakon, majd archiválva, harmadlagos tárolókon.

A több tárolási szint hatékony kezelése a rendszerek m ködtetésének egyik legfontosabb problémája. Azt az ellentmondást, hogy a m veletvégzésben résztvev adatoknak a

processzor regisztereiben, kell elhelyezkedniük, míg a számítógépes rendszerben kezelt adatés programmennyiség általában még a háttértárakra sem fér el egyidej leg, csak az adatok tárolószintek közötti folyamatos mozgatásával lehet feloldani. A szintek közötti adatmozgatás hagyományos megoldása, hogy a processzor utasításonként esetleg többször is a memóriához fordul (egyrészt magáért az utasításért, másrészt adatokért), a programokat végrehajtás el tt a háttértárról a memóriába kell tölteni, a háttértáron tárolt adatokat csak fájlm veletekkel (a be/kiviteli rendszeren keresztül) lehet elérni, a harmadlagos, küls tárakból pedig a

I.1. Tárak

2

személyzet közrem ködésével kell kikeresni és a megfelel perifériába helyezni a megfelel adathordozókat.

Az egyes hierarchiaszintekhez más-más elérési, hivatkozási módok tartoznak. Az operatív tár címeire az utasítások meghatározott címzési módokkal és numerikus címértékekkel hivatkoznak. A háttértárakon tárolt fájlokra ezzel szemben nevekkel, amelyekhez csak futási id ben - a fájlok megnyitásakor - köt dnek konkrét blokkcímek. A memória bájtonként, szavanként címezhet en érhet el, a fájlok ezzel szemben gyakran szekvenciális elérés ek. A tárolószintek közötti adatmozgatások történhetnek explicit módon, valamelyik alkalmazás megfelel m veletének végrehajtásával. A rendszerekben azonban igen gyakran rejtett

átjárások vannak a szintek között, amelyek célja a hatékonyság, vagy a kényelem fokozása.

A rejtett átjárások két módja fordul el : az alacsonyabb szint elérési módjait terjesztik ki a magasabb szint tárra (virtualizálás) a magasabb szint tár elérési módját használva valójában egy alacsonyabb szint tárat kezelnek (gyorsítótár, cache)

A két mód megvalósítása végül hasonló részproblémákra vezet, mindkett re hasonló fogalmak (találat, betöltési, kiírási stratégiák stb.) alkalmazhatók

A virtualizálás természetesen a magasabb szint

tár bevonása miatt lassabb m ködést

eredményez, mint a valódi alacsonyabb szint elérése, ám igen kényelmes, hiszen az alacsony szint felhasználható címtartománya sokszorosára n het.

A gyorsítótár két szint közé épül be, vagy az alacsonyabb szint tárolóban kerül kialakításra a magasabb szinten elhelyezked adatmennyiség egyes részeinek átmeneti tárolására. Az

eredetileg magasabb szinten tárolt adatokra vonatkozó m veletek végrehajtásakor a m velet végrehajtója el ször megvizsgálja, hogy az adat nincs-e a gyorsítótárban. Ha ott van (találat), akkor a m velet gyorsan végrehajtható. Ha nincs ott, akkor adatcserét kell végrehajtani, a magasabb szintr l be kell hozni az adatot a gyorsítótárba.

I.1. Tárak

3

Jellegzetes gyorsítótárak: · a processzorokba épített hardver gyorsítótárak (utasítás- és adatcache), amelyek a memóriában tárolt adatok egy munkában lév részét teszi gyorsan elérhet vé a processzor számára, · a fájlok egy részének tárolására a memóriában kialakított átmeneti tárterületek (buffercache)

A felhasználó által manuálisan kezelt gyorsítótárak: · a memóriában kialakított, több fájl tárolására alkalmas virtuális diszkek (RAM-diszk, elektronikus diszk), · a harmadlagos tárak fájlrendszereit tároló mágneslemez területek. A gyorsítótárak és a magasabb szintek közötti adatcsere általában a felhasználó el l rejtetten, egyidej leg nagyobb adatmennyiségeket mozgatva történik. A hatékonyságnövekedés oka a feldolgozás lokalitási tulajdonsága, azaz ha egy adatra (beleértve a program utasításait is) a feldolgozás során szükség van, akkor nagy valószín séggel a környezetében tárolt adatokra is szükség lesz. A gyorsító tár megfelel méretezésével és hatékony adatcsere-algoritmusokkal 80-99%-os találati arány is elérhet .

Az operációs rendszerek hatáskörébe a tárhierarchia szintjei közül a memória, valamint a háttértárakon és harmadlagos tárolók aktuális adathordozóján kialakított fájlrendszerek tartoznak, a felsorolt gyorsítótárak közül pedig a virtuális memória és a fájlrendszerek gyorsítótárai (buffer-cache). Ezek közül a fájlrendszerek kezelése ­ tekintve, hogy perifériákon történ adattárolásról van szó ­ a be/kiviteli rendszerre épül.
Megjegyzés: Itt hiányoska

I.1.2. A logikai memória
Mint korábban bemutattuk, a folyamathoz tartozó virtuális gép a processzoron kívül egy logikai memóriát tartalmaz. A logikai memóriát a folyamat egy RAM, illetve közösen használt memória esetén PRAM modell szerint m köd tárnak látja. Az egyetlen folytonos címtartomány helyett már a logikai szinten is érdemes három önálló címtartományt elkülöníteni, mivel ezek viselkedése és kezelése eltér . A folyamathoz tartozó programkódot

I.1. Tárak

4

és esetleg konstansokat tároló kódterületet, az adatokat, változókat tároló adatterületet, valamint a verem (stack) területét. A kódterületet általában csak olvassák a folyamatok, ezért közös használata kevesebb problémát okoz. Mérete általában már végrehajtás el tt ismert. Az adatterület változókat tárol, a folyamatok írják is, de mérete ugyancsak ismert. A verem ezzel szemben amellett, hogy változókat tárol, dinamikusan növekedhet, és a mérete bizonyos esetekben - például iteráció adatfügg mélység rekurzív eljáráshívások esetén - nem

határozható meg el zetesen. A folyamatoknak ezért általában fel kell készülniük a verem túlcsordulását jelz hibamegszakításra.

I.1.3. A háttértár - fájlok

A folyamatok a másodlagos tárolókon a futásukat túlél adatok tárolására névvel azonosítható fájlokat hozhatnak létre. A fájl tartalmát a folyamatok állítják el és használják fel, az

operációs rendszer a tartalommal általában nem foglalkozik, a fájlt egyszer bájtfolyamként kezeli. A fájlok, mint tárolási egységek, egészükben is lehetnek m veletek tárgyai, illetve természetesen m veletek szükségesek a fájlban tárolt adatok kezelésére is. A másodlagos tárolókon elhelyezked igen nagyszámú fájl megtalálása, egyértelm azonosítása rendezett nyilvántartási rendszert igényel, ami leggyakrabban egy hierarchikus könyvtárszerkezettel valósul meg. A hierarchikus könyvtárszerkezet azt jelenti, hogy a könyvtárak tartalmazhatnak fájlokat, valamint további könyvtárakat (alkönyvtárak), és ez valamennyi szinten lehetséges. A könyvtárhoz tartozó fájlokról egy katalógusfájl (directory) tartalmazza a szükséges adatokat. A tárolási hierarchia a legtöbb esetben egyetlen közös gyökérb l indul, más esetekben a legmagasabb szinten több kötet (volume) helyezkedhet el, ami gyakran egyben egy fizikai egységet is jelöl. A tárolási hierarchiában a fájlt elérési útvonala és neve együttesen azonosítja, így csak az adott könyvtáron belül szükséges egyedi neveket használni.

I.1.3.1. Fájlmodellek A fájlban tárolt adatok elérésére háromféle fájlmodell (elérési módszer, access method) használatos:

I.1. Tárak

5

Soros elérés (sequential) fájl:

A fájl fogalma az operációs rendszerekben a mágnesszalag analógiájára alakult ki. A szalagon tárolt információt csak a tárolt byte-ok sorrendjében lehetett olvasni vagy írni. Sok információ-feldolgozási feladathoz a soros hozzáférés elegend . A soros elérés modelljéhez tartozik egy ún. fájlpointer, ami az aktuális elérési pozíciót tárolja.

Közvetlen elérés (direct) fájl:

A tárolt adatelemeket (pl. bájtokat) közvetlenül, sorszámuk alapján el lehet érni. Az átviteli eljárásoknak paraméterként meg kell adni az adatelem állományon belüli címét (sorszámát).

Indexelt, index-szekvenciális elérés (index sequential access method, ISAM):

Ez a modell a fájlban tárolt adatok szerkezetének ismeretét is feltételezi. Ha a fájl rekordokat tárol, akkor a rekordokat kijelölt mez ik (kulcs) tartalma alapján érhetjük el. A keresés megkönnyítésére egy segédfájl (index-fájl) szolgál, amelyik a fájlban el forduló kulcsértékek szerint rendezve tárol egy-egy mutatót a megfelel operációs rendszerben áll rendelkezésre. rekordra. Ez a modell nem minden

I.1.3.2. Fájlm veletek A m veletek egy része a fájl egészére vonatkozik, más része a fájl adatainak kezelését teszi lehet vé.

· Adatelérés, írás vagy olvasás: · közvetlen hozzáférésnél a m velethez meg kell adni az információ címét, pozícióját; · soros hozzáférésnél az átvitel során az aktuális pozíciót a rendszer növeli és tárolja. Eldöntend , hogy megengedjük-e az átvitel során az állomány szimultán írását és olvasását is, és ha igen, akkor soros elérésnél közös vagy külön-külön fájlmutatót használunk-e.

I.1. Tárak

6

· Hozzáírás (append), b vítés: Az állomány végéhez új információt írunk. Az állomány mérete növekszik.

· Pozicionálás: A soros hozzáférésnél használt pozíciót a soros átvitel mindig növeli, pozicionálásnál viszont azt az állomány tetsz leges pontjára állíthatjuk. Gyakori eset a pozició visszaállítása az állomány elejére, a mágnesszalag analógiát sugalló visszacsévélés (rewind). A pozicionálás m veletével lehet a közvetlen hozzáférést megvalósítani.

· Megnyitás (open): Az átviteli m veletek hatékonyabbak, ha nem kell mindegyiknél az állományt a neve alapján a nyilvántartásokból megkeresni. Ezért a modell szintjén is megjelenik a megnyitás m velete, hiszen a további m veletek már más (nem név szerinti) hivatkozási módot igényelnek. A megnyitás m veletének szerepe: · az állomány megkeresése, fizikai elhelyezkedésének meghatározása, a további elérést segít adatszerkezetek felépítése; · hozzáférési jogosultságok ellen rzése; · az állományon elvégezhet m veletek (írás, olvasás, hozzáírás) megadása. · osztott állománykezelés szabályozása; · fájlmutató kezdeti beállítása; Az állomány sikeres megnyitása után az operációs rendszer visszaad egy olyan értéket (mutató, vagy logikai periféria-szám) amely a további m veletekben a név helyett használható az állomány azonosítására.

· Lezárás (close): Jelzi a folyamat részér l az adatelérési m veletsorozat befejezését. A megnyitáskor fájlt elhelyezett zárak feloldódnak, a fájl esetleg a másodlagos tárra még ki nem írt (pufferelt) adatai kiíródnak.

· Végrehajtás (execution):

I.1. Tárak

7

Az operációs rendszer létrehoz egy új folyamatot, a programfájlt betölti a folyamat tárterületére és elindítja.

· Létrehozás (create): Az állomány létrehozásakor egy új katalógus-bejegyzés is létrejön, a rendszer szükséges esetén az állományhoz szabad blokkokat foglal le. · Törlés (delete): A törlés megszünteti a katalógus-bejegyzést, felszabadítja az állományt tároló területet a másodlagos táron.

I.1.4. Tárak tulajdonságai
Az el z ekben a tárhierarchia egyes szintjein elhelyezked adatok címzése és elérése szerint tettünk különbséget a memória és a háttértár között. Emellett a táraknak más fontos tulajdonságai is lényegesek, és hozzátartoznak a virtuális gép jellemzéséhez. I.1.4.1. M ködési sebesség A tárak m ködési sebessége az adatelérési id vel (access time) jellemezhet , ami egy olvasási, illetve írási m velet végrehajtási ideje. A fizikai memória esetén az elérési id címfüggetlennek vehet . A modellben is ezzel a feltételezéssel élhetünk, bár a rejtett átjárások (virtuális tárkezelés) miatt egyes hivatkozások végrehajtási id i között jelent s különbségek lehetnek, és az átlagos érték kedvez tlenebb a fizikai tárra jellemz id knél. A fájlok fizikai tárolói jelent s keresési id vel rendelkeznek (lemezek fejmozgása, elfordulása). A gyorsítótáras kezelés (buffer cache) miatt a modell kedvez bb átlagos végrehajtási id ket vehet figyelembe.

I.1.4.2. Címezhet adategység A fizikai eszközök eltér felépítése, m ködése ellenére a modell bájt felbontásban teszi

elérhet vé mind a memóriában, mind a fájlokban tárolt adatokat. Fájlok esetén ez a bemutatott soros, illetve direkt elérés valamelyike lehet.

I.1. Tárak

8

I.1.4.3. Tárolási biztonság Az egyes tárak robosztussága, m ködésbiztonsága igen eltér lehet. A ma általánosan

használt memóriák (elektronikus tárak) legkellemetlenebb tulajdonsága, hogy tápellátás kimaradás esetén felejtenek. A mágneses elven m köd háttértárak ilyen szempontból

kedvez bbek, "nem felejt k", ugyanakkor el fordulnak lemezsérülések, vagy tranziens felírási, leolvasási hibák.

A rendszertervez , alkalmazásfejleszt általában három tárkategóriában gondolkozik: felejt , nem-felejt és stabil tárakban. A felejt tár kisebb rendszerzavarok esetén is elveszíti

tartalmát. A nem-felejt kisebb sokkokat túlél (pl. tápkimaradás), a stabil tár pedig elvileg mindent túlél, gyakorlatilag igen nagy valószín séggel lehet számítani az adatok meg rzésére az újraindításig. A közelít leg stabil tárak megfelel alakíthatók ki.
Megjegyzés: Ezt az egészet majd jól át kell dolgozni.

redundanciával kezelt háttértárakon

I.2. Készülékek és küls kapcsolatok
A virtuális gép fontos objektumai a folyamatok és tárak mellett a készülékek, illetve az egyéb küls kapcsolatok. A valamennyi olyan eszközt, amelyik a fizikai architektúra szerint

perifériának min sül, igyekeznek egységesen kezelhet vé tenni, közös modellt találni számukra. Ez nem könny , mert ezek az eszközök igen sokfélék. Két f irány figyelhet meg, amelyek - ha kicsit mélyebbre nézünk - nem is különböznek olyan lényegesen egymástól. A két irány a fájlok és a többi készülék viszonyának meghatározásában különbözik. Az egyik irány valamennyi küls eszközt a fájl absztrakció alá sorol be, és speciális fájloknak tekinti például a nyomtatót, a terminált és a többi perifériát, kezelésükre - esetleg speciálisan paraméterezhet - fájlm veleteket nyújt. A másik irány központi fogalma a logikai periféria, amelyik egy absztrakt be/kiviteli eszköz, és a rendszer m ködése során a logikai perifériához akár különböz fizikai eszközök, és rendszerint fájlok is rendelhet k. Bármelyik irányból közelítünk is, a meglehet sen vékony fed rétegek alatt elég hamar el kerülnek az eszközök különböz ségéb l származó problémák, ami nem jelenti azt, hogy a készülékeket ne lehetne osztályokba sorolni. Ebben a fejezetben egyrészt egy rendszerezésre teszünk kísérletet, majd a

I.1. Tárak

9

jellegzetes készülékek modelljeit tárgyaljuk, amelyek a felhasználói, illetve programozói felületen megjelennek.

I.2.1. A küls eszközök f típusai
A számítógépek körül egyre többféle olyan készüléket találunk, amelyekkel közvetlen kapcsolatban van. Ezek a készülékek feladataikat, szerkezetüket, m ködési elvüket tekintve rendkívül sokfélék lehetnek.

A perifériákat egyrészt jellegzetes feladatköreik szerint csoportosíthatjuk, amelyek a következ k lehetnek: · ember-gép kapcsolat · gép-gép kapcsolat · adattárolás Jellemz tendencia, hogy egyre újabb, a korábbiakra alig emlékeztet készülékek jelennek meg, amelyeknek együtt kell m ködniük a számítógéppel. Ugyanakkor ­ szerencsére ­ a készülékek csatlakoztatásának szabványosodása is megfigyelhet . Ugyancsak jellemz tendencia, hogy a perifériák egyre intelligensebb saját vezérl egységgel rendelkeznek, így a kapcsolatokban is egyre magasabb szint , a részleteket elfed modellt láttatnak magukból. Mindennek eredményeként a fenti, funkcionális különbség a kapcsolat alacsony szint rétegeiben nem ismerhet szabványai szerint kezelhet . fel, ott minden eszköz a gép-gép kapcsolat sajátosságai és

A következ

csoportosítási szempont a perifériák m ködési sebessége lehet. Többségük

mechanikus alkatrészeket is tartalmaz, ezért a perifériák m ködési sebessége (pl. feldolgozott bájt/s mértékegységben) általában lényegesen alatta marad a processzorok sebességének. Különösen azok az eszközök lassúak, amelyek m ködési sebességét emberi reakcióid k határozzák meg. Más esetekben azonban - f ként célrendszerek, speciális alkalmazások gépgép kapcsolataiban - a küls eszközként kezelt m szerek, érzékel k, egyéb készülékek olyan gyorsak, hogy a számítógéphez való illesztésük speciális megoldásokat igényel

I.1. Tárak

10

A készülékek jellegzetes sebességkategóriái (a felsorolás sorrendjében egyre gyorsabbak): · emberi beavatkozást igényl készülékek · mechanikus, elektromechanikus készülékek · elektromos, elektronikus készülékek · optikai készülékek · részecskefizikai készülékek Ismét más csoportosítási szempont a készülékek vezérelhet sége. Vannak eszközök, amelyek (természetesen adott sebességi korlátokon belül) a számítógép által meghatározott ütemben képesek adatok küldésére vagy fogadására. Más eszközöknél ellenben éppen az jelenthet gondot, hogy egy hosszabb adatfolyamot csak saját ritmusukban képesek kezelni. Ilyenek például a hagyományos rendszerekben a diszkek a lemez folyamatos forgása miatt, vagy a mai rendszerek multimédiás, audio/video jelfolyamait közvetít eszközök, a küls TV adás számítógépes fogadásának, vagy számítógépes mozgókép TV adásba történ közvetítésének eszközei. Ha a számítógép oldalán nem tudunk igazodni a készülék által diktált ütemhez (szinkronhoz), adatvesztés lép fel, és az átvitel egyáltalán nem, vagy csak jelent s id veszteséggel ismételhet meg.

Az operációs rendszer készít jének szempontjából újabb rendez

elv lehet az egyes

készülékek illesztési módja a számítógéphez. A számítógép hardver általában különböz készülékvezérl k alkalmazásával oldja meg a készülékek és a tár közötti adatcserét. Egyes vezérl k csak egy-egy eszközt felügyelnek, mások egy külön sínrendszeren több eszközt kezelnek. Egyes vezérl k önálló processzorral és mikrokóddal, jelent s memóriával rendelkezhetnek, mások csupán néhány regisztert (adat ki/bemenet, parancs, státusz) és sínilleszt áramköröket tartalmaznak (portok). Egyes eszközök csak I/O címeket használnak, mások memóriába ágyazott címeket, vagy azokat is. Egyes eszközök állapotjelz it programozottan kell lekérdezni (polling), mások megszakításkéréssel jeleznek egy-egy eseményt. Egyes eszközök bájtonként vagy szavanként igényelnek processzor-m veletet, mások blokkonként cserélnek adatot a memóriával (DMA).

I.1. Tárak

11

Ez az utóbbi szempont nem csak az illesztés, hanem a magasabb szint kezelés során is el térbe kerül. A készülék és a számítógép közötti adatfolyam jellege szerint ugyanis a készülékek karakteres, vagy blokkos átvitellel m ködtethet k.

A bemutatott csoportosítás is érzékelteti, hogy az operációs rendszer által kezelt készülékek rendkívül sokfélék, ráadásul további, nehezen tipizálható tulajdonságokkal is rendelkeznek. Hogyan lehet ezeknek a készülékeket a kezel i és programozói felületen egységesen megjeleníteni?

Az egységes felület kialakításának elve, hogy találjuk meg a lényeges közös vonásokat, és rejtsük el a részleteket, ruházzuk a megfelel felel sségeket az architektúra alacsonyabb

szintjeire. A készülékek esetén elég sok elrejteni való akad, és elég kevés a tipizálható, általánosítható funkció. A készülékkezel feladat marad. (device driver) programokra meglehet sen sok

I.2.2. Készülékmodell az alkalmazói felületen
Az operációs rendszer programjai számára a legfontosabb absztrakció, hogy a készülékre adatokat lehet küldeni, illetve adatokat lehet róla fogadni. Ez megfelel a fájlokra kiadható írás, olvasás m veleteknek, ezért sok rendszer a fájl fogalmát terjeszti ki a készülékekre. A készülékek ilyen esetben a fájlokhoz hasonlóan nevükkel azonosíthatók, és beilleszkednek a könyvtári nyilvántartás névhierarchiájába. A fájlok használata el tt meg kell nyitni azokat, ami a készülékek esetén is értelmezhet , hiszen vannak eszközök, amelyek például el zetes motorindítást, kizárólagos használat lefoglalását, vagy kapcsolat-felépítést igényelnek, miel tt az érdemi adatátvitelre sor kerülhetne. Ugyancsak értelmezhet a készülékekre a használati jog ellen rzése. Mint a fájlok megnyitása, a készülékek el készítése is gyakran rejtetten történik a folyamatok indulásakor, vagy az els hivatkozáskor.

A fájlrendszerre épülve, vagy a mellett a rendszerek lehet vé teszik logikai perifériák használatát, ami a készülék-független programozást szolgálja. Egy logikai periféria a rendszerben névvel vagy sorszámmal azonosítható, és ez a név, vagy sorszám használható a be/kiviteli m veletekben írás esetén a cél, vagy olvasás esetén a forrás kijelölésére. A névhez a kezel rendelhet konkrét fizikai eszközt, vagy a folyamat az el készítési szakaszában

I.1. Tárak

12

végrehajtott megnyitásokkal maga végzi el a hozzárendelést (ez a szakasz természetesen nem lesz készülék-független, de a kód dönt része az marad). A logikai perifériákhoz általában nem csak készülékek, hanem fájlok is hozzárendelhet k. A logikai perifériákra egyszer be/kiviteli m veletek adhatók ki. Lássuk ennek egy modelljét részletesebben!

I.2.2.1. Egyszer be/kivitel A kernel alkalmazói felületén a B/K (I/O) m veletek egy adatblokk mozgatására vonatkoznak a memória és valamely logikai periféria között. Ennek a m veletnek a bonyolítására egy indító (START), egy várakozó/tesztel (WAIT) és rendellenességek esetére egy leállító (STOP) m velet szükséges, valamint az átvitel paraméterezéséhez egy egyezményes adatstruktúra, a B/K leíró (Input Output Control Block, IOCB).

Az adatmozgatás paraméterei: forrás, cél, mennyiség. A forrás és a cél közül az egyik egy memóriacím, a másik egy logikai periféria név (vagy szám). A mennyiség az átviend bájtok száma. A m veletek argumentumában a logikai periféria neve és egy mutató szerepel az IOCB-re. Az IOCB tartalma: parancs, ami lehet írás, olvasás stb.; állapotjelz , amelyik az átvitel sikerét, vagy hibáját jelzi vissza, memóriacím; mennyiség; egyéb paraméterek, amelyek a periféria által értelmezhet k lehetnek (pl. diszkek esetén blokkcím).

A START a logikai periférianév alapján fizikai készüléket választ ki, a fizikai periféria várakozási sorába f zi az átviteli paramétereket tartalmazó IOCB-t. Ha a periféria nincs m ködésben, meghívja a készülékkezel program szabványos Start_Device m veletét (az egységes készülékcsatlakoztatási felület el írja, hogy ilyen m veletnek kell lennie). Ezután mindkét esetben visszatér, azaz aszinkron hívásként nem várja meg a B/K m velet végét.

A WAIT m velet ellen rzi az IOCB állapotjelz jét. Ha az I/O m velet még nem fejez dött be, a hívó folyamatleíróját ráf zi a megadott IOCB-re és a folyamatot várakozó állapotba helyezi, majd CPU ütemezést indít. Ha az I/O m velet befejez dött, visszatér a hívóhoz. Egyes rendszerekben a m velethez id korlát rendelhet , amely 0 és végtelen értékekre is beállítható. A 0 érték lehet vé teszi az elindított m velet befejez désének lekérdezéses észlelését (polling), a végtelen id korlát pedig a blokkolt m veletek megvalósítását.

I.1. Tárak

13

A STOP m velet használatával programhibák, leállások esetén megállítható az elindított, de még be nem fejez dött I/O m veletet. Ha a készülék még nem kezdte meg a végrehajtást (nem az els az IOCB a sorban), egyszer en kif zi az IOCB-t, ha már megkezdte, a

szabványos készülékcsatlakoztatási interfészen keresztül meghívja a kezel program Stop_Device eljárását.

Az alkalmazások általában nem közvetlenül ezt a felületet használják, hanem a nyelv, illet leg a rendszer könyvtári csomagjainak eljárásait. Az egyszer I/O m veletek lehet vé teszik, hogy a magasabb szint , nyelvi és könyvtári m veleteket akár szinkron (várakozó blokkolt), akár aszinkron (továbbfutó, nem blokkolt) változatban kialakíthassák. A blokkolt megoldás a START után azonnal WAIT hívást tartalmaz, így a folyamat általában várakozó állapotba kerül. A nem blokkolt megoldás csak elindítja az átvitelt, majd a folyamat tovább futhat, és alkalmas ponton lekérdezheti az átvitel eredményét. A magasszint m veletek szívesebben alkalmaznak blokkolt megoldást, mert a vezérlési szál ilyenkor nem ágazik el az I/O indítás következtében, és a programkód könnyebben érthet és követhet . Ha nem

blokkolt megoldás szükséges, akkor is szívesebben hoznak létre inkább új szálat a folyamaton belül, és azon az I/O m veletet akkor is blokkoltan hajtják végre. I.2.2.2. Fájlm veletek A legtöbb eszközre a szekvenciális fájl modellje jól illeszthet , hiszen az adatáramlás bájtfolyam jelleg .

A diszkes fájlok tipikus m veleteit az el z fejezetben áttekintettük. Megnyitáskor a fájlra névvel kell hivatkozni, a további read, write, seek m veletekben azonban már a megnyitáskor kapott számmal.

A virtuális tárat használó rendszerek gyakran lehet vé teszik a fájlok memóriába ágyazott kezelését. Egy leképez m velet helyet foglal a fizikai tárban a fájl memóriában tartandó részeinek és visszaadja azt a virtuális címtartományt, amelyben a fájl látszik. Ezt követ en a fájl adataira memóriareferenciákkal hivatkozhatunk.

A további fizikai eszközök (pl. nyomtató, billenty zet, modem, audio és video berendezések) read, write m veleteinek egy része ugyancsak blokkonkénti, más része karakterenkénti I/O

I.1. Tárak

14

rendszerhívást okoz. Egyes eszközökre csak olvasás (billenty zet, CD), vagy csak írás (nyomtató) értelmezhet , ett l eltekintve a fájlként történ kezelés a felhasználói felületen könnyen értelmezhet . I.2.2.3. Grafikus eszközök kezelése A grafikus eszközöket az alkalmazások általában egy grafikus könyvtár eljárásaival kezelik. Ezek az eljárások egy raszter-, vagy vektorgrafikai modellt valósítanak meg, és alakzatrajzoló, törl , mozgató, továbbá állapotbeállító (háttérszín, rajzolószín, vonaltípus, kitöltés stb.) m veleteket tesznek lehet vé. A könyvtári eljárások a monitorok grafikus memóriáját, vagy annak egy részét általában memóriába ágyazottan látják. Bizonyos eszközökben a könyvtári eljárások programja és a grafikus memória egy külön célprocesszorral együtt a grafikus vezérl kártyáján helyezkedik el. Ezt az eszközt az

operációs rendszer csak néhány I/O címen, vagy memóriába ágyazottan kezelhet regiszterként látja. Ennek ellenére a felhasználó számára logikailag ugyanaz a felület jelenik meg, mint a hagyományos megoldásoknál, a m veletek végrehajtása azonban lényegesen gyorsabb lehet. I.2.2.4. Terminálkezelés A terminál egy karakteres be/kiviteli egység, amelyik képerny t és billenty zetet tartalmaz, és általában a számítógépt l távolabb helyezkedik el, ezért adatátviteli vonalon, vagy hálózaton csatlakozik a számítógéphez. Az alkalmazások számára a terminál sor-orientált, vagy képerny -orientált kezelésére állnak rendelkezésre m veletek. Az adatátvitel jellegzetesen karakterenkénti és nem transzparens, azaz egy adott kódrendszert (benne vezérl karaktereket is) használ. A terminálok igen sokféle szabvány szerint m ködhetnek, különösen a billenty zet-kiosztás és a vezérl karakterek elhelyezése a kódtáblában lehet sokféle. Az operációs rendszerek ma már valamennyi, a fontosabb szabványoknak megfelel kezelést választhatóan tartalmazzák, ám ezek közül választani sem egyszer felhasználói feladat I.2.2.5. Hálózati kapcsolatok kezelése A hálózati kapcsolatok kezelésére jellegzetes megoldás a logikai csatlakozók (socket) fogalmának bevezetése (ld. UNIX, Windows NT). Az alkalmazások létrehozhatnak csatlakozókat, segítségükkel becsatlakozhatnak távoli címekre, figyelhetik, hogy más rácsatlakozott -e az csatlakozójukra. A kapcsolat létrejötte után a csatlakozó egy indirekt

I.1. Tárak

15

kommunikációs objektumként m ködik. A szerver oldal ­ ahova több csatlakozón érkezhetnek hívások ­ munkájának támogatására nyújtják a rendszerek a select m veletet, amely visszaadja azon csatlakozók listáját, amelyiken van várakozó üzenet. A csatlakozók mellett igen változatos további kommunikációs modellek is megjelennek a rendszerekben (postaláda, üzenetsor, pipe, stream stb.). A készülékekbe épített vezérl k képességeinek fejl désével számos készülék a folyamatok közötti kapcsolatokhoz egyre inkább hasonlatos módon kezelhet .

I.2.3. Készülékmodell a kezel i felületen
Az egyszer felhasználó kezel i felületén a készülékeket is az alkalmazások közvetítik. Az alkalmazásfejleszt számára az alkalmazói felület modellvilága bír els dleges

jelent séggel, azon túl pedig az eszközök konfigurálása, a logikai, fizikai készülékek összerendelésének lehet ségei. Újdonságot az eddigiekhez képest leginkább a rendszermenedzser számára nyújtandó készülékmodellek jelentenek. Neki kell ugyanis végrehajtani új készülékek csatlakoztatását a rendszerhez, továbbá elvégezni azok megfelel beállítását. Ezen a szinten a rendszerek

némelyike valóban egy széles, modellezett eszközválasztékot kínál, ahol tipikus funkciójú készülékek legfontosabb paraméterei beállíthatók, és a konkrét eszközpéldányok

hozzárendelése is megtörténhet a megfelel modellhez. Például egy modemre beállítható, hogy milyen adatkapcsolati protokollt használjon, használjon-e paritásbitet, meddig várjon a tárcsahangra stb., és az is, hogy mindez melyik fizikai csatlakozóra kapcsolt készülékre vonatkozik.

I.3. Védelem és biztonság

Védelemnek nevezzük eljárásoknak és módszereknek azon rendszerét, mely lehet séget teremt a számítógép er forrásainak programok, folyamatok, ill. felhasználók által történ elérésének szabályozására. A védelem fogalmát fontos megkülönböztetnünk a rendszer

I.1. Tárak

16

biztonságának (vagy biztonságosságának) fogalmától. A rendszer biztonsága annak a mértéke, hogy mennyire lehetünk bizonyosak a számítógépes rendszer, ill. a rendszerben tárolt adatok sérthetetlenségében. Míg a védelem szigorúan a rendszer bels problémája, kizárólagosan csak a rendszeren belüli objektumokkal foglakozik, addig a rendszer biztonságának biztosításakor figyelembe kell venni rendszer m ködési környezetét, amelyb l a rendszerünket potenciális támadások érhetik. Természetesen a két témakör szervesen összefügg, hiszen minden biztonsági rendszer feltételez egy megfelel en m köd védelmi mechanizmust, amire építhet.

I.3.1. Védelem
A védelemr l beszélve célszer szétválasztani a védelem módszerét és a védelem szabály rendszerét. A védelem szabályrendszere meghatározza, hogy mit kell tenni a rendszer zökken mentes biztonságos használatához, míg a védelem módszere (vagy mechanizmusa) lehet séget teremt a szabályozás megvalósítására, vagyis a rendszerobjektumok kezelésének módját határozza meg. I.3.1.1. Védelmi tartományok Védelmi szempontból a számítógépes rendszereket tekinthetjük úgy, mint objektumok, ill. az objektumokat használó folyamatok halmazát. Az objektumok ebben a modellben lehetnek mind szoftver komponensek (pl. fájlok, programok, szemaforok stb.), mind pedig hardver komponensek (pl. CPU, memória, nyomtató stb.). Az objektumok egyedi névvel érhet k el a rendszerben, és mindegyiken az objektumra jellemz m veletek végezhet k. Pl. egy fájlt a fájl nevével és az elérési útjával azonosítjuk. A fájlon végezhet tipikus m veletek, pl.

olvasás, írás, végrehajtás. A rendszermodellt általánosan tekinthetjük úgy, hogy az objektumok absztrakt adattípusok, amin végezhet m veletek függenek az adott objektum típusától. A folyamatok m ködése a fenti modellben gondolkodva nem más, mint a fent definiált absztrakt adattípusok példányain végzett m veletek sorozata. A rendszert biztonságossá tehetjük, ha az objektumokon végzett m veletek végrehajtását jogosítványokhoz kötjük. Természetesen egy folyamat végrehajtásához szükségünk van a folyamat által használni kívánt objektum elérését lehet vé tev jogosítványra ami az objektumon végzend m veletet engedélyezi. A rendszer abszolút biztonságosan m ködik, ha minden pillanatban minden

I.1. Tárak

17

folyamat pontosan csak azokkal a jogosítványokkal rendelkezik, ami feltétlenül szükséges az aktuálisan végzett m velet végrehajtásához, hiszen ha más objektumot próbálna elérni a folyamat, vagy az adott objektumot nem megengedett módon, a számítógép védelmi rendszere azonnal jelezne. (A szabályozásnak ezt a formáját ún. need-to-know szabályozásnak ­ szükséges, hogy ismerje, elérje szabályozásnak - nevezik.) Ez az ideális szabályozás a valóságban nem valósítható meg els sorban a szükséges tetemes rendszeradminisztráció miatt. Az objektumok elérésének szabályozására az ún. védelmi tartományok szolgálnak. A védelmi tartomány nem más, mint jogosítványok gy jteménye objektumokon végezhet m veletek végrehajtására. Egy védelmi tartomány tartalmazhat jogosítványt egyazon objektum többféle m velettel történ elérésére, ill. egy objektum-m velet páros akár több különböz

tartományban is szerepelhet. A legegyszer bben a védelmi tartományokat táblázatos formában az ún. elérési mátrix segítségével ábrázolhatjuk. Az 1. Táblázat egy statikus elérési mátrixot mutat. A táblázatból kiolvashatjuk, pl. hogy csak a B tartományban tartózkodó folyamat jogosult nyomtatni a nyomtatón vagy azt, hogy az A tartományban tartózkodó folyamat két fájlt olvashat: az adat.txt-t és a help.bat-ot.

objektumok adat.txt tartományok A B C D olvasás, írás olvasás végrehajtás olvasás, írás olvasás doc.doc help.bat olvasás nyomtatás nyomtató

1. Táblázat: Elérési mátrix statikus védelmi tartományokkal Egy rendszerben használhatunk · · dinamikus és statikus

védelmi tartományokat attól függ en, hogy egy folyamathoz tartozó védelmi tartomány változik-e a folyamat végrehajtása során. Ha nem változhat, statikus, míg az ellenkez esetben dinamikus védelmi tartományról beszélünk.

I.1. Tárak

18

Dinamikus védelmi tartományok használatakor szabályozni kell a védelmi tartomány váltásának ill. megváltoztatásának módját. Több módszer létezik ennek megvalósítására. Védelmi tartomány váltás (switch) A legegyszer bb módszer, hogy definiálják, mely védelmi tartományból mely védelmi tartományba léphet át egy folyamat. Ennek ábrázolása lehetséges az el bb megismert elérési mátrixban is. A 2. Táblázat els sorában pl. láthatjuk, hogy az A jel tartományból csak a B jel tartományba léphetünk át, a B jel tartományból a C és a D jel tartományokba léphet a folyamat, míg a C jel tartományból nem lehetséges a védelmi tartomány megváltoztatása.

objektumok adat.txt doc.doc help.bat printer A tartományok B C D
olvasás írás olvasás végrehajtás olvasás írás váltás olvasás olvasás nyomtatás

tartományok A B
váltás váltás váltás

C

D

2. Táblázat: Elérési mátrix dinamikus védelmi tartományokkal Elérési jogosítványok másolása (copy) Lehetséges, hogy a rendszer engedélyezi egy bizonyos objektumon történ m velet

végrehajtására vonatkozó jogosítvány másolását egy adott védelmi tartományban. Ez azt jelenti, hogy az adott védelmi tartományban futó folyamat jogosult az általa birtokolt, egy adott m velet elvégzésére szóló jogosítványt odaadni más védelmi tartományoknak. Objektumok tulajdonlása (owner) Az el z másolási jogot általánosíthatjuk. Kijelölhetünk egyes védelmi tartományokat,

melyek ún. tulajdonosi joggal rendelkeznek egy adott objektum felett, ami azt jelenti, hogy az általuk birtokolt objektumon végezhet bármelyik m veletre adhatnak jogosítványt egy másik tartománynak. I.3.1.2. Elérési mátrix ábrázolása és kezelése Egy valós rendszerben igen sok objektum és nagyon sok védelmi tartomány létezhet, azonban egy-egy tartomány általában csak néhány objektum elérésére tartalmaz jogosítványokat. Az

I.1. Tárak

19

elérési mátrix ennek megfelel en egy igen nagy, de ritka mátrix, melynek optimális tárolása és kezelésére számos különböz módszert használnak. (1) Globális tábla A globális tábla a legegyszer bb tárolási mód. Egyszer en a rendszer tárolja a hármasokat, vagyis egyszer en egy listába gy jti az elérési mátrix kitöltött elemeit. (Az 1. Táblázat els sora alapján pl. a következ két elemet tárolná a rendszer: , .) A módszer hibája, hogy az adódó lista igen hosszú egy valós rendszerben, ami hosszadalmassá teszi a táblázaton végzett m veleteket (keresés, beszúrás, változtatás). A m veletek elvégzését gyakran a háttértár elérése is meghosszabbítja, hiszen nagy táblázat nem fér be teljesen a memóriába. (2) Objektum elérési lista Ennél a módszernél az elérési mátrixot lényegében az oszlopai mentén feldaraboljuk, és az oszlopok tartalmát tároljuk. Van egy listánk a rendszerben létez összes objektumokról, és minden objektumhoz tároljuk a hozzá tartozó párokat. (3) Tartományok jogosítványainak listája Ennél a módszernél az elérési mátrixot a sorai mentén daraboljuk fel, és a sorok tartalmát tároljuk. A rendszerben létezik egy lista a védelmi tartományokról, és minden tartományhoz tároljuk a hozzá tartozó párokat. (4) Zár-kulcs (lock-key) módszer A zár-kulcs módszer átmenet az el z két módszer között. Minden objektumhoz tartoznak egyéni bitminták. Ezek töltik be a zár szerepét. Hasonlóan, minden védelmi tartomány rendelkezik egy vagy néhány bitmintával. Ezek töltik be a kulcs szerepét. Ha egy tartomány bitmintája egyezik az objektum bitmintájával, vagyis a tartomány egyik kulcsa illeszkedik az objektum zárjába, azt jelenti, hogy a tartományt birtokló folyamat elvégezheti a kulcshoz tartozó m veletet. Mint említettük, a globális tábla módszer nehézkes, így a gyakorlatban ritkán használják. A objektum elérési lista használata gyorsítja a jogosultság ellen rzését és annak elérését az objektum alapján. A tartományok jogosítványainak tárolása viszont a tartományok szerinti elérést támogatja, ami hasznos lehet egy folyamat jogainak meghatározásakor. Látható, hogy

I.1. Tárak

20

más-más szituációkban használható ki a két módszer el nyös tulajdonsága, emiatt ez utóbbi módszereket gyakran kombinálják. Vegyünk egy példát. Tételezzük fel, hogy a védelmi tartományok egyszer en folyamatokhoz köt dnek, minden folyamatnak van egy védelmi tartománya. Ha egy folyamat el ször kezdeményezi egy objektum elérését, ellen rzi a rendszer az objektum elérési listájában, hogy a folyamat végezheti-e az adott m veletet. Ezek után a rendszer ad egy elérési jogosítványt a folyamatnak, aminek segítségével az objektumon történ további m veletvégzéskor már

igazolni tudja a jogosultságát. Ezt a módszert használja pl. a UNIX rendszer fájlok elérésekor. A fájlok használatát minden esetben a fájl megnyitásának kell megel znie, mikor is a folyamat köteles megadni a fájl adatain kívül a fájlon végzend m velet típusát is. A

megnyitás során az operációs rendszer ellen rzi a folyamat fájlra vonatkozó jogosultságait. Ha a folyamat számára engedélyezett m veletet kíván végezni, az operációs rendszert l kap egy fájlleírót, melynek használatával további ellen rzés nélkül érheti el a kívánt fájlt. Természetesen a fájlleíró csak a kért m velettípus végrehajtására alkalmas, a rendszer minden alkalommal ellen rzi ezt. Az elérési mátrix ábrázolási módszerek közül a zár-kulcs mechanizmus a leghatékonyabb módszer. Ennek használata rugalmas, a kulcsok egyszer en adhatók át a tartományok között, a zár egyszer megváltoztatásával megvonhatók jogosultságok, ill. a jogosultság ellen rzése is gyors, hiszen nem szükséges nagy tömeg adatot mozgatni. Ez a módszer el nyei miatt gyorsan terjed a modern rendszerekben.

I.3.2. Biztonság
Egy számítógépes rendszer biztonsága, mint korábban már meghatároztuk, annak a bizonyosságnak mértéke, hogy a rendszer, ill. a rendszerben tárolt információ nem sérülhet meg vagy illetéktelenül nem kerülhet a ki a rendszerb l. A védelemmel ellentétben, aminek biztosítása szigorúan a rendszer bels problémája, a rendszer biztonságának

meghatározásakor szükség van a rendszer környezetének a vizsgálatára is. Míg a védelem esetén programhibák ill. programok nem kívánt mellékhatásai, vagyis véletlen események ellen kell a folyamatokat megvédeni, addig a biztonság biztosításakor feltételezni kell szándékos és rosszindulatú támadásokat is a rendszer ellen. A számítógépes rendszerek biztonságáról beszélve nemcsak technikai, hanem

rendszerszervezési, rendszeradminisztrációs kérdésekkel is foglalkoznunk szükséges.

I.1. Tárak

21

Technikailag tökéletes biztonságú rendszerben tárolt adatok is könny szerrel elérhet vé válnak egy támadó számára, ha nem biztosítunk megfelel fizikai védelmet a rendszernek. Ha pl. a rendszer adattárolói a megfelel védelem hiányában egyszer en kivehet k a rendszerb l és egy másik, védelem nélküli helyen lemásolhatók, a rendszer biztonsága elégtelen, holott az technikailag tökéletes. A rendszer biztonságát ért sérülések oka lehet szándékos és véletlen. A szándékos támadásoknak három fajtáját különböztetjük meg: · adatok illetéktelen olvasása, · adatok illetéktelen módosítása, · adatok tönkretétele. A biztonsági rendszer feladata, hogy a szándékos támadások ill. véletlen sérülések ellen védelmet nyújtson. Mivel a gyakorlatban abszolút biztonságos rendszert igen nehéz létrehozni, ezért a gyakorlatban alkalmazott védelmi rendszerek célkit zése az, hogy támadó dolgát annyira nehezítse meg, hogy a támadás "költsége" nagyobb legyen, mint a sikeres támadás eredményeként remélt haszon. I.3.2.1. A felhasználók azonosítása A számítógépes rendszerhez történ jogosulatlan hozzáférés megakadályozásának els lépése a felhasználók azonosítása. A felhasználók azonosítására több módszer létezik: · Felhasználó azonosítása személyes tulajdonságai pl. ujjlenyomat, retinamintázata, aláírása, kezének erezete stb. alapján. · Felhasználó azonosítása annak birtokában lév tárgyak pl. kulcs, azonosító kártya stb. alapján. · Felhasználó azonosítása csak általa ismert információ pl. név, jelszó esetleg algoritmus alapján. A személyes tulajdonság és a tárgyak alapján történ azonosítás esetén a számítógépes

rendszer valamilyen speciális periféria (aláírás-scanner, ujjlenyomat digitalizáló, kártyaolvasó stb.) segítségével végzi a felhasználó azonosítását. A számítógépes rendszerekben a jelszóval történ azonosítás a legelterjedtebb els sorban azért, mert ez a módszer valósítható meg a legegyszer bben. A jelszóval történ azonosítás tipikusan két problémát vet fel: Ne lehessen a jelszót egyszer en kitalálni ill. annak megadásakor azt "kihallgatni". Gyakori, hogy a felhasználók mások által egyszer en

I.1. Tárak

22

kitalálható jelszót használnak: pl. saját login nevük, házastársuk nevét, születésük dátumát stb.. A jelszó kihallgatása történhet egyszer en annak begépelésekor, de gyakori támadási forma volt a korai hálózati rendszerekben a hálózaton kódolatlanul továbbított jelszók begy jtése is. A jelszó kitalálása ellen a következ képen védekeznek a rendszerek: · ,,Nehezen kitalálható" jelszó választására kényszeríti a felhasználót. · Jelszó gyakori cseréjére kötelezik a felhasználót. A jelszó érvényessége id ben korlátozott a rendszerben, az érvényesség lejártával a rendszer kéri a felhasználót jelszavának megváltoztatására. Általában a rendszerek tároljál a korábban már használt jelszavakat, és ezeket nem engedik megint használni. Ha nehezen kitalálható jelszót szeretnénk választani, akkor érdemes figyelembe venni, milyen tipikus támadási stratégiák léteznek egy felhasználó jelszavának megfejtésére. Az egyik ilyen támadási stratégia, hogy a támadó a felhasználók által gyakran használt jelszavakkal, ill. a felhasználó nevéb l, esetleg más személyes adataiból generált kulcsszavakkal próbálkozik. Ennek a támadásnak kiküszöbölésére szolgálnak az ún. jelszóellen rz programok. A

rendszer új jelszó megadásakor vagy valamilyen gyakorisággal rendszeresen lefuttatja a jelszóellen rz programot. Ez mechanikusan végigpróbálja a felhasználó nevéb l, ismert

adataiból kikövetkeztethet legkézenfekv bb, ill. a rendszerben mások által gyakran használt jelszavakat. Ha ilyet talál, felszólítja a rendszer a felhasználót jelszavának megváltoztatására. A másik gyakori támadási forma, az ún. szisztematikus támadás, amikor a támadó egy szótárból módszeresen végigpróbálgatja az összes benne szerepl szót. Ezt a támadást

nagyban segítheti, ha valamilyen módon ismertté válik a jelszó hossza és ez a hossz rövid. Az ilyen támadások meghiúsítása érdekében a rendszerek általában megszabják a legrövidebb elfogadható jelszó méretét és megkövetelik legalább néhány nem alfanumerikus karakter (szám vagy jel) ill. nagybet használatát. Az el bbieken túl fontos figyelembeveend szempont amikor a rendszer nehezen megfejthet jelszavak választására forszírozza a felhasználókat, hogy a jelszó ne legyen annyira nehezen memorizálható, hogy azt a felhasználó ne tudja megjegyezni. Ezzel ugyanis arra ösztönözi a rendszer a felhasználót, hogy a jelszavát valamilyen formában külön tárolja. Ez igen veszélyes lehet, hiszen ebben az esetben a védtelen helyen tárolt jelszó könnyedén illetéktelen kezekbe kerülhet. A jelszó kihallgatásának megakadályozása a következ képen történhet:

I.1. Tárak

23

A legegyszer bb alapvet képerny n.

védekezés, hogy a jelszó megadáskor az nem jelenik meg a

A felhasználók jelszavait a rendszer csak a rendszergazda által elérhet védett állományban, vagy kódoltan tárolja. Gyakran alkalmazott megoldás, hogy a rendszer a jelszavakat kódolja olyan, nem invertálható kóddal, mely esetén az eredeti jelszavak a kódolt állomány alapján nem visszaállíthatók. A rendszer egy felhasználó belépésekor a megadott jelszót ugyanazzal az eljárással kódolja, és a kódolt jelszót hasonlítja össze az általa tárolt változattal. Ebben az esetben a kódolt jelszavakat tartalmazó fájl lehet akár mindenki számára elérhet , hiszen abból az eredeti jelszó nem fejthet meg. Ilyen módszert alkalmaz a UNIX rendszerek

többsége a felhasználók jelszavainak tárolására. Annak oka, hogy az utóbbi id kben fejlesztett UNIX rendszerek esetén a jelszavakat tartalmazó fájl mégsem publikus az, hogy az ilyen tárolás megkönnyíti a korábban már említett szótárt használó szisztematikus támadást, ha a használt kódolás algoritmusa a támadó számára ismert. A jelszavak lehallgatásának megakadályozása érdekében fejlesztették ki a felhasználó által ismert algoritmussal történ azonosítást. Ebben az esetben létezik egy, a felhasználó és a rendszer által ismert algoritmus, ami általában két, terminálon begépelhet bet sorozatot rendel egymáshoz. A rendszer belépéskor egy véletlen bet sorozatot ad a felhasználónak. A felhasználónak az algoritmust alkalmaznia kell a megadott sorozaton, és annak eredményével kell válaszolnia. Ebben az esetben az esetleges támadó akár tudhatja is a két karaktersorozatot, de azt nem tudja többet használni, mert a rendszer mindig más és más bet sorozatot használ egy felhasználó beléptetéskor. Ez az azonosítási eljárás természetesen akkor fog jól m ködni, ha minden felhasználó esetén különbözik a használt algoritmus. Ezt úgy oldja meg a rendszer, hogy az algoritmusnak két bemeneti paramétere van. Az egyik a paramétert a rendszer az els belépéskor közli a felhasználóval, és minden alkalommal ezt a paramétert használja a felhasználó azonosításakor a rendszer által minden belépéskor külön generált változó paraméterrel együtt. I.3.2.2. A rendszer biztonságát növel általános módszerek A rendszer elleni támadások megakadályozásának általános módszere a veszélyeztetett pontok figyelése (threat monitoring). Folyamatosan vizsgálja a rendszer a felhasználók tevékenységét és a gyanús aktivitást jelzi a gép rendszergazdájának vagy a felhasználónak. Gyakori pl., hogy a felhasználót belépésekor tájékoztatják arról, hogy mikor használta utoljára a rendszert, illetve az azóta eltelt id ben hány sikertelen - hibás jelszavú - belépési kísérlet

I.1. Tárak

24

történt. Gyakori megoldás, hogy a hibás jelszó megadásakor a rendszer mesterségesen lelassul, és egyre hosszabb id t váratja a felhasználót a jelszó begépelése után, így nehezítve meg a szisztematikus támadást. Még szigorúbb, de gyakori megoldás, hogy a rendszer néhány sikertelen belépési próbálkozás után a felhasználó belépési lehet ségét meghatározott ideig letiltja. Az esetleges betörések diagnosztizálására szolgál az ún. aktivitás naplózás (audit logging), mely során a rendszer feljegyzi az egyes er forrásokhoz történ hozzáférés id pontját, a m veletet végz felhasználót és az er forráson végzett m veletet. Ez a módszer ugyan nem véd az illetéktelen hozzáférésekt l, de az elkövet utólagos azonosítását megkönnyíti. A rendszer publikus, vagyis több felhasználó által is elérhet csatornán továbbított

üzeneteinek lehallhatását megakadályozó módszer a kódolás vagy rejtjelezés (encryption), melynek célja, hogy az üzenetet olyan módon alakítsa át, kódolja, hogy az értelmezhetetlen legyen a csatornát figyel támadó számára. Az üzenet valódi címzettje valamilyen

többletinformáció (ún. kulcs) segítségével képes az üzenet eredeti tartalmát visszaállítani. A rejtjelezés els dleges felhasználói a katonai alkalmazások, azonban napjainkban a civil szférában is rohamosan terjed a rejtjelezés használata. A rejtjelezéssel rokon terület az üzenet ill. partner hitelesítés, ami a kommunikációs partner ill. az általa küldött üzenet hitelesítésére szolgál. Egy publikus csatornán érkez üzenetr l a címzett nem lehet biztos az üzenet küld jének személyében ill. abban, hogy az elküldött üzenetet nem változtatta-e meg valaki. Az Interneten pl. nagyon egyszer olyan e-mailt

küldeni, amelyben nem a tényleges írója van küld ként megnevezve. Az ilyen támadások kivédése érdekében az üzeneteket többletinformációval látják el. Ez lehet a küld t azonosító ún. elektronikus aláírás (electronic signature), vagy más, a tényleges üzenetb l és a küld t azonosító információból generált kódolt üzenetrész.

I. Multiprogramozott operációs rendszerek

1

I. MULTIPROGRAMOZOTT OPERÁCIÓS RENDSZEREK

Ebben a fejezetben azokat a problémákat és megoldási elveket tárgyaljuk, amelyek a modellszinten felvázolt operációs rendszer ­ az absztrakt virtuális gép ­ egyetlen processzort tartalmazó hardver-architektúrán történ megvalósítása során merülnek fel.

Több processzor többféleképpen alkothat rendszert. Ezek egy része nem alkalmaz min ségileg új megoldásokat és elveket a multiprogramozáshoz képest. Az ilyen rendszerek egyszer en a CPU többszörös er forrásként történ figyelembevételével, vagy összekapcsolt, önálló multiprogramozott alrendszerekként kezelhet k. Az els esetben a CPU ütemezés vesz figyelembe néhány új szempontot, a második esetben pedig az alrendszerek küls kapcsolatként látják egymást. A rendszerek más része azonban néhány szolgáltatásban min ségileg is újat nyújt. Ezekkel az ún. hálózati és elosztott rendszerekkel a következ , V. fejezet foglalkozik.

Ugyancsak ebben a fejezetben szerepelnek a tárak, készülékek, kezel i felületek megvalósításának azok a megoldásai, amelyek a szokásos eszközökre építenek, és a multiprogramozott rendszerekben alakultak ki. Természetesen ezek a megoldások a hálózati és elosztott rendszerekbe is beépülnek.

I.1. Bevezetés

A II.2. fejezetben az operációs rendszerek története kapcsán már szó volt a mutiprogramozott rendszerek létrejöttének okairól, illetve néhány szóban arról is, hogy milyen új kihívásokat jelentett e rendszerek megjelenése, és el nyeik mellett milyen új feladatok megoldása elé állították a rendszerfejleszt ket. Röviden szeretnénk tehát csak összefoglalni azokat az indítékokat, amelyek a mai multiprogramozott rendszerek kialakulásához vezettek, valamint

I. Multiprogramozott operációs rendszerek

2

vázolni azokat a - kés bb részletesen tárgyalt - problémákat, amelyek megoldása szükséges feltétele volt a multiprogramozott operációs rendszerek megbízható és helyes m ködésének.

A félvezet technika és a számítógép architektúrák fejl dése során a CPU sebessége olyan nagymértékben megnövekedett, hogy felvetette a lassú perifériás m veletek eredményeire várakozás idejének esetleges kihasználását. Megoldást erre egy másik program futtatása jelenthetett. Vagyis az, hogy az operációs rendszer ,,egyszerre" több munkát futtat. A multiprogramozott rendszerek létrejöttében az alapvet gazdaságossági szempontok mellett természetesen szerepet játszottak olyan további szükséges technikai feltételek is, mint a véletlen hozzáférés tárak megjelenése vagy a tárkapacitás megnövekedése.

A multiprogramozott rendszerekben a következ futtatása:

lépések alapján történik a folyamatok

· Az operációs rendszer nyilvántartja és tárolja a futtatandó folyamatokat. · A futtatható folyamatok közül az operációs rendszer választ. · A futásra kiválasztott folyamat addig fut, amíg várakozni nem kényszerül, illetve bizonyos rendszereknél amíg el nem veszik t le a futás jogát. · Az operációs rendszer megjegyzi a várakozni kényszerül folyamat várakozási okát, és elmenti azt a környezetet, amely a kés bbi továbbfutáshoz szükséges. Ezután kiválaszt egy másik, futni képes folyamatot (beállítja a környezetét) és elindítja. · Ha a félbehagyott folyamat várakozási feltétele teljesül, az operációs rendszer a következ alkalommal, amikor az éppen futó folyamat várakozni kényszerül, újra elindít(hat)ja.

Az alapmodellb l és a fenti lépésekb l adódóan a multiprogramozott rendszerek a következ új problémákat vetették fel: · A folyamatok közötti hatékony átkapcsolások megkövetelik, hogy több program egyid ben a központi tárban tartózkodhasson, vagyis a tárgazdálkodást. · A folyamatok között egyszerre több futásra kész is lehet, amelyek közül az operációs rendszer a CPU ütemezés során választ. · A CPU mellett a rendszerben lev többi er forrás használatát több folyamat is igényelheti. Ennek megfelel en az er forrásokat folyamathoz kell rendelni, a hozzáféréseket

I. Multiprogramozott operációs rendszerek

3

koordinálni (szinkronizálni) kell, bizonyos er forrásokhoz biztosítani kell a kizárólagos használat jogát, a holtpont helyzeteket kezelni kell. · A védelmi mechanizmusokon keresztül az operációs rendszernek biztosítania kell, hogy az egyes programok ne zavarják egymás, illetve az operációs rendszer m ködését. · A számítógép bonyolultságának növekedése miatt a hardver-architektúra, és különösen a B/K készülékek részleteit el kell rejteni, és a szolgáltatásokat megfelel en ki kell b víteni a felhasználóbarát virtuális gép és környezet biztosítása révén. · A hálózatok, elosztott rendszerek megjelenése óta biztosítani kell a megfelel kommunikációs felületet, kapcsolatot más számítógépek és programok felé.

A következ fejezetekben el ször annak a hardver-architektúrának a lényegesebb jellemz it foglaljuk össze, amelyre a multiprogramozott operációs rendszerek építhetnek, majd az imént felsorolt problémákat és megoldásaikat fogjuk részletesebben vizsgálni.

I.2. A számítógép-architektúra

Az operációs rendszer felépítésének és m ködésének részletes tárgyalásához szükségünk van számítógép architektúrákra vonatkozó általános ismeretekre, illetve annak pontosítására, hogy milyen hardver modellt tételezünk fel az operációs rendszerek ,,alatt". Mint a II.3. fejezetben láttuk, a hardver-architektúra igen széles teljesítmény-spektrumot foghat át, és igen sokféle lehet. A könyv írása során abból a feltételezésb l indultunk ki, hogy az olvasónak megvannak a megfelel el ismeretei e tekintetben, így itt csak ismétlés jelleggel, nagyon nagy

vonalakban utalunk azokra a legfontosabb hardver sajátságokra, amelyek a multiprogramozott rendszerekben tipikusak, és amelyekre építve az operációs rendszerek megvalósítják feladataikat.

I.2.1. Az egyprocesszoros von Neumann struktúrájú számítógéparchitektúra

I. Multiprogramozott operációs rendszerek

4

A von Neumann struktúrájú, modern, általános célú számítógépek CPU-ból és különböz berendezésvezérl egységekb l állnak, amelyeket közös busz (sín) köt össze. Az egységek közötti információ (utasítás és adat) áramlás a buszon keresztül történik, és ez biztosítja a CPU és készülékvezérl k memóriához való hozzáférését is. Minden egyes készülékvezérl egység bizonyos típusú ­ hozzájuk kapcsolt - készülék(ek) m ködését és használatát kontrollálja (4.2.1. ábra). A CPU és a készülékvezérl k egyidej leg m köd(het)nek.

4.2.1. ábra Von Neumann struktúrájú számítógép egyszer sített tömbvázlata

I.2.1.1. Bekapcsolási folyamat

A számítógép bekapcsolásakor vagy újraindításakor egy egyszer

indítóprogram (az un.

bootstrap program) kezd el futni, amely beállítja (inicializálja) a rendszer kezdeti állapotát, majd betölti az operációs rendszer magját. Ezután az operációs rendszer veszi át a vezérlést, feltérképezi és inicializálja a hardvert, felépíti a rendszertáblákat (pl. megszakítási vektortábla), elindítja a rendszerfolyamatokat (ha vannak), és elindul(nak) a felhasználói bejelentkezésre váró folyamat(ok). Ebben az állapotában a rendszer valamilyen eseményre szoftver vagy hardver megszakításra (interrupt) - vár.

I.2.1.2. Megszakítási rendszer

A megszakítási rendszer az architektúra egyik legsajátosabb, leginkább processzorcsaládfügg eleme.

Küls hardver megszakítás bármikor érkezhet - általában a buszon keresztül - a CPU-hoz. A szoftver azáltal kezdeményez megszakítást, hogy egy speciális fajta utasítást, rendszerhívást (system call, monitor call) hajt végre. Külön osztályát képezik a megszakításoknak a hibamegszakítások, amelyek valamilyen m ködési rendellenesség esetén következnek be. Összességében tehát nagyon sokféle esemény, például perifériás m velet befejez dése, nullával való osztás, illegális memória hozzáférés stb. eredményezhet megszakítást.

I. Multiprogramozott operációs rendszerek

5

Megszakítás esetén a CPU felfüggeszti az éppen futó tevékenységet, és adott helyre adja a vezérlést. A megszakítás-kezelés logikai lépései szerint az így elindított megszakítás-kezel program szükség szerint elmenti a megszakított folyamat környezetét (regiszterek, verem tartalmát, stb.), majd a megszakítás okának megfelel kiszolgáló rutin fut. Befejez dése után visszaállítja a régi környezetet, és visszaadja a vezérlést a korábban futott folyamatnak. A különböz fajtájú megszakítások kezelésére külön rutinok szolgálnak.

A megszakítási rendszerek lehetnek egy- és többszint ek. El bbi esetben egy megszakítás kiszolgálása alatt le vannak tiltva az újabb megszakítások. A kifinomultabb rendszerek többszint megszakítást tesznek lehet vé. Ilyenkor lehetséges megszakítás fogadása

megszakítás kezelés alatt is. A maszkregiszter segítségével állítható be, hogy adott interrupt idején melyek a fogadható magasabb prioritású megszakítások.

Az operációs rendszerek un. esemény-vezérelt rendszerek, azaz, ha nem fut éppen valamilyen folyamat, nincs I/O kiszolgálás, felhasználói kérés, akkor az operációs rendszer tétlenül vár valamilyen eseményre, interruptra.

Fentiek miatt a megszakításkezelés a számítógép-architektúrák kiemelt fontosságú részét alkotja. Gyors m ködést várunk t le (hogy ne tartsa fel a folyamatokat), ezért általában úgy valósítják meg a megszakítás kezelést, hogy egy rendszertáblában tárolják az ismert, véges számú lehetséges megszakításhoz tartozó kezel rutin kezd címét. A rutinok futási id re optimalizáltak, még a felesleges adminisztrációt okozó eljáráshívásokat is kiküszöbölik, és egy eljárás keretében végzik el a megszakításkezelés összes szükséges lépését.

I.2.1.3. I/O struktúra

A perifériás m veletek elindításakor a CPU feltölti a kívánt periféria vezérl regisztereit, melyek tartalma alapján a vezérl azonosítja a kívánt szolgáltatást és megkezdi az adatátvitelt egy lokális pufferen keresztül. Az adatátvitel befejez désekor (vagy ha a puffer megtelik) a készülékvezérl egy megszakításkéréssel értesíti err l a CPU-t.

I. Multiprogramozott operációs rendszerek

6

A perifériás átvitelt a készülékvezérl

is kezdeményezheti - megszakításkéréssel -,

amennyiben a pufferébe adat érkezik kívülr l, valamilyen perifériás készülék fel l.

A felhasználói folyamatok által kezdeményezett perifériás m veletek fenti folyamata kétféle ütemezéssel történhet. Szinkron I/O esetén a folyamat csak a perifériás m velet végrehajtása után kapja vissza a vezérlést. A másik lehet ség, az aszinkron I/O szerint a folyamat már a perifériás m velet megindítása után visszakaphatja azt. Ez utóbbi változat hatékonyabb rendszerm ködést eredményez.
Megjegyzés: Miért biztos ez?

I.2.1.4. Közvetlen memória hozzáférés, DMA

Nagy sebesség készülékek nagyobb méret adatblokkjainak a memória és a készülék között történ gyors átvitelére dolgozták ki a közvetlen memória hozzáférés (Direct Memory Access, DMA) technikáját. Ilyen - egyszerre elérhet - nagyobb méret tömböknél a CPU-t er sen megterhelné, és a rendszer m ködését nagyon lelassítaná, ha az információt - a perifériás készülék nagy sebessége miatt viszonylag kis id közökkel - kis egységekben, például karakterenként, megszakítással vinnénk a CPU regiszterekbe, vagy rajtuk keresztül a memóriába, illetve innen a perifériavezérl pufferébe.

Miután a CPU a készülékhez tartozó, megfelel

regisztereket - mutatók, számlálók ­ a pufferéb l

beállította a készülékvezérl n, vagy a DMA-vezérl n, a készülékvezérl

közvetlenül a memóriába, vagy egy memóriaterületr l a saját pufferébe tölt egy (a puffer méretének megfelel en tipikusan 128 byte és 4 Kbyte közötti méret ) adatblokkot anélkül, hogy a CPU-t megzavarná a m ködésében. Legfeljebb buszciklust kell ,,lopjon" (cycle stealing) a CPU el l az átvitelhez. A DMA átvitel befejez dése után a perifériavezérl , vagy a külön DMA-vezérl blokkonként egyetlen megszakítással jelzi a m velet befejez dését.

I.2.1.5. Tárak

Az utasításoknak (és a hozzájuk tartozó operandusoknak) a központi tárban kell lenniük a végrehajtáskor. A regisztereken kívül ez az egyetlen olyan memória fajta, amelyhez a CPU

I. Multiprogramozott operációs rendszerek

7

közvetlenül hozzá tud férni. Az utasítás-végrehajtási ciklus során az utasítások el ször (a programszámláló értékének megfelel címr l) az utasításregiszterbe kerülnek, majd

dekódolás és az esetleges operandusok beolvasása után végrehajtódnak. Az eredmények a legtöbb esetben a memóriába íródnak vissza.

A von Neumann struktúrájú számítógépeknél az adatok és utasítások nincsenek megkülönböztetve. Ugyanabban a memóriában, ugyanúgy vannak tárolva, csak a környezetük alapján lehet különbséget tenni közöttük.

A fentiekb l következ en az lenne az optimális, ha az összes programot és adatot a központi tárban tárolhatnánk. Sajnos ez nem lehetséges, mert egyrészt a központi tár túl kicsi az összes szükséges program és adat állandó tárolásához, másrészt pedig ez a memória nem képes meg rizni (elveszti) a tartalmát a tápfeszültség kikapcsolása vagy kimaradása esetén.

Mindezek miatt megfelel en nagy méret másodlagos tárolási lehet séget kell biztosítani az információ állandó tárolására. Ebben az értelemben a másodlagos vagy háttértárak a központi memória kiterjesztésének tekinthet k.

A számítógépek adattároló rendszereit sebességük, méretük és áruk alapján hierarchia szintekbe sorolhatjuk (4.2.2. ábra). A hierarchián lefelé haladva egyrészt csökken a bitenként költség (és így n az elérhet méret), másrészt azonban az elérési id növekszik. Az effektív elérési sebesség növelése céljából gyorsítótárakat (cache) szokás alkalmazni a f szintek regiszterek és központi memória, illetve f memória és háttértárak - között. A CPU és a memória közötti gyorsítótárat általában hardver kezeli. Ezek gyakran a processzorhoz integrált gyors és viszonylag kis méret tárak. A memória és a háttértár közötti

gyorsítótárakat pedig az operációs rendszer valósítja meg. A gyorsítótárakban a mögöttes memóriaszint leggyakrabban, vagy a közeljöv ben várhatóan használt információi találhatók, amelyek a rájuk való hivatkozás százalékos arányának (találati arány) megfelel en javítják a átlagos hozzáférési id t.

4.2.2. ábra Tárhierarchia

I. Multiprogramozott operációs rendszerek

8

A regiszterek, a központi memória és a gyorsítótárak a tápfeszültség kikapcsolásakor elveszítik a tartalmukat, míg a háttértárak meg rzik azt.

A leggyakrabban használt másodlagos tárak a lemezegységek (mágneses, illetve optikai) ezek blokkonként címezhet véletlen hozzáférés (random access) memóriák - valamint a mágnesszalag, amely szekvenciális hozzáférés tároló. A mágneses diszkek még ma is igen elterjedten használtak, ezért az ezeket érint adatforgalom hatékonysága (gyorsasága) fontos tényez lehet a rendszer optimalizálásban. Az optikai diszkek, bár lassabbak a mágneses diszkeknél, elérhet áruk és egyéb kiváló tulajdonságaik miatt egyre inkább terjed ben

vannak. A mágnesszalagok sok szempontból elvesztették már a jelent ségüket lassúságuk és hozzáférési módjuk merevsége miatt, azonban az adatsérülésekkel szembeni robusztusságuk, és nagy tárolási kapacitásuk okán ma is használják hosszú távú tárolására. ket igen nagyméret adathalmazok

I.2.1.6. Védelem

Védelmi kérdésekkel kés bb részletesen fogunk foglalkozni, ezért itt éppen csak megemlítjük, hogy a mai számítógép rendszerek komoly hardver támogatást nyújtanak különböz védelmi mechanizmusok megvalósításához.

Védelemr l alapvet en három szinten beszélhetünk. Ezek a CPU védelem, az operációs rendszer védelme és a felhasználói programok, területek védelme. Az utóbbi kett az, amely szorosan köt dik az operációs rendszerek témájához, így ezekr l a kés bbiekben részletesen fogunk beszélni. Az els , azaz a CPU védelem kérdése túlmutat a könyv által tárgyalni kívánt témákon, ezért csak a teljesség kedvéért említjük, hogy ide tartozik például a hurokba került programoknak egy id zít m ködése, stb. által okozott megszakítása (timer IT), watchdog processzorok

Az operációs rendszer szintjén megvalósítandó védelmek alapfeltétele, hogy a CPU két m ködési módban tudjon dolgozni, amelyek közül az egyik, az utasításkészlet és az alapvet er források teljes kör használatát biztosító ún. privilegizált (rendszer, kernel stb.) mód, csak az operációs rendszer számára legyen fenntartva.

I. Multiprogramozott operációs rendszerek

9

Mind a védelmet, mind egyéb rendszerfunkciókat további hardver megoldások támogathatják (pl. memóriakezel egységek, asszociatív tárak, speciális környezetváltó utasítások stb.),

amelyeket az egyes funkciók tárgyalásakor részletezünk.

I.2.2. Többprocesszoros, szorosan csatolt számítógéprendszerek

Többprocesszoros,

szorosan

csatolt

(un.

multiprocesszoros)

rendszerekben

a

korábbiakkal ellentétben nem egy, hanem több CPU található, és az egyes processzorok között a kapcsolat közös er forráso(ko)n keresztül valósul meg. A szorosan csatolt rendszerek közös memóriát és órát, és az esetek nagy részében közös operációs rendszert használnak. (Természetesen ezen felül mindegyik processzorhoz tartozhatnak saját er források, például saját memória is, amelyeket közvetlenül csak az adott processzor éri el.)

A rendszer moduljait egy rendszersín köti össze, amelyen keresztül a közös információforgalom bonyolódik, illetve amelyen keresztül a közös memóriához hozzá lehet férni (4.2.3. ábra). Ha a CPU modulok azonos felépítés ek és tulajdonságúak, akkor homogén rendszerr l beszélünk, ha eltér ek is lehetnek, akkor a rendszer inhomogén. A CPU modulok rendelkezhetnek azonos jogokkal (szimmetrikus esetben), illetve lehetnek közöttük kiemelt jogosultságokkal bírók (aszimmetrikus vagy master-slave elrendezés esetén).

4.2.3. ábra Mulitprocesszoros rendszerek logikai tömbvázlata

Az el z , egyprocesszoros esetet vizsgáló részben tárgyalt elvek és megoldások több processzoros esetben is alkalmazhatók, érvényesek. A több processzor miatt azonban koordinálni kell a közös rendszersínhez való hozzáférést. A rendszersín vezérl a memória vagy perifériacím alapján dönti el, hogy saját (bels ) er forráshoz, hogy közös er forráshoz kell fordulnia (ez utóbbi esetben a rendszersínen keresztül).

A rendszersínhez való hozzáférést egy sínvezérl (arbiter) egység felügyeli. Több, egyidej igény fellépése esetén a vezérl többféle ­ egyszer vagy kombinált - stratégia alapján

I. Multiprogramozott operációs rendszerek

10

választhat. Egyik legegyszer bb módszer, ha egyik irányból indulva a másik felé, a ,,helyileg" el bbre lev buszt igényl modul kapja meg a rendszersín használati jogát (daisy chain). Ez a megvalósítás igen egyszer , azonban komoly hátránya a terjedési késleltetés, valamint az, hogy a rendszerbe kapcsolható modulok számát ez utóbbi sajátság korlátozza.

Több esetleges kérés között a vezérl választhat prioritás alapján is, ilyenkor a sínhasználatot a legnagyobb prioritású modulnak kínálja fel, amennyiben a rendszerbusz szabad. Kritikus hibát okozhat a prioritás eldönt meghibásodása.

Azonos CPU-n futó folyamatok a saját bels memóriájukon osztoznak (ha van ilyen), míg a különböz CPU-kon futó folyamatok a közös memórián keresztül kommunikálnak egymással. Emiatt a rendszersín mind teljesít képessége, mind esetleges meghibásodása miatt er sen befolyásolja a rendszer m ködését.

A vázolt felépítési és m ködési struktúra lehet vé tesz további hierarchikus szervez dést is, amikor egy modul bels buszára is több processzort kapcsolunk.

I.3. Folyamatkezelés
A III. fejezetben tárgyalt folyamatmodell feltételezte, hogy minden folyamat a saját különálló processzorán fut. A multiprogramozott rendszerekben azonban egyetlen processzor több folyamatot futtat. A következ kben azzal foglalkozunk, hogy hogyan teszi mindezt .

I.3.1. A folyamatmodell leképezése a fizikai eszközökre
A folyamatmodell feltételezte, hogy a rendszer minden folyamata saját processzoron fut, és saját memóriája van. A multiprogramozott rendszerben egyetlen fizikai processzoron és egyetlen, lineárisan címezhet fizikai memóriában kell megvalósítani a folyamatok

m ködtetését. A modell leképezésének legfontosabb kérdéseit tárgyaljuk a következ kben.

I. Multiprogramozott operációs rendszerek

11

I.3.1.1. A m ködés alapjai A folyamat megismert modellje mind multiprogramozott, mind multiprocesszáló

rendszerekben használható. A folyamatok kezelésével kapcsolatos feladatok természetesen különböz ek a két rendszertípus esetén, hiszen a modell megvalósítása a különböz rendszerarchitektúrákon egymástól lényegesen különböz problémákat vet fel. Általában igaz, hogy a multiprocesszáló rendszerekben a folyamatok száma meghaladja a processzorok számát, emiatt ilyenkor is megoldandó az egyes processzorok multiprogramozott m ködtetése (és emellett természetesen a processzorok együttm ködésével kapcsolatos feladatok is). A folyamatok kezelésének alapvet kérdéseit a következ kben multiprogramozott esetre

tárgyaljuk, a multiprocesszálás esetére csak utalunk, illetve egyes kérdéseinek külön fejezetet szánunk.

Egy multiprogramozott operációs rendszer minden id pillanatban folyamatok egy csoportjának végrehajtásával foglalkozik, amelyeket egyetlen fizikai processzoron futtat. A multiprogramozás foka a rendszerben egy adott pillanatban jelenlév ­ tehát megkezdett, de még be nem fejezett ­ folyamatok száma.

Az operációs rendszer egyik alapvet feladata az er forrás-gazdálkodás és -kiosztás A két alapvet er forrás a processzor (CPU), és a memória. Ezek kiosztása még együttm köd folyamatok esetén is általában a versengés elvén történik, hiszen a folyamatok kódjában rendszerint nem jelenik meg külön utasítás ezek lefoglalására, illetve felszabadítására.

Amikor egy folyamat létrejön a rendszerben, létrejön számára egy logikai memória és egy logikai processzor, amelyekhez fizikai megfelel ket kell rendelni.

A logikai memória létrehozása a fizikai rendszer tekintetében azt jelenti, hogy a folyamat megkapja a fizikai tár egy részét, ahova a kódja és változói (vagy legalább is azok egy futáshoz éppen szükséges része) megfelel kezd értékekkel betölt dnek. Elvileg a logikai memóriához a háttértár valamely területe is hozzárendelhet , az éppen futó folyamat végrehajtandó utasításának azonban mindenképpen a memóriában kell lennie (hiszen a háttértárról való betöltés a processzorsebességhez képest rendkívül lassú). A processzorért

I. Multiprogramozott operációs rendszerek

12

emiatt csak azok a folyamatok versenyezhetnek, amelyek következ végrehajtandó kódrésze a memóriában van.

A logikai processzorok látszólag párhuzamosan m ködnek. Valójában az egyetlen fizikai processzor egyidej leg egyetlen folyamat utasításait tudja végrehajtani. Ha a fizikai processzor elég gyakran átkapcsol egy folyamat egy részletének végrehajtása után egy másik folyamatra úgy, hogy mindegyik elég gyakran jusson szóhoz, akkor egy durvább id léptékben a folyamatok futása párhuzamosnak látszik. A dolgot úgy is felfoghatjuk, hogy a rendszer legfontosabb egyedi er forrása a fizikai processzor, amelyet egyidej leg egyetlen folyamat használhat, és amelyhez tartozik egy várakozási sor, ahol a többi, processzorra váró folyamat tartózkodik. A processzor felszabadulásakor az operációs rendszer választja ki valamilyen algoritmussal a sorban várakozók közül azt a folyamatot, amelyik a következ id szakra megkapja a processzort (CPU ütemezés).

A folyamatok tipikus szerkezete olyan,

hogy egy processzor

által végrehajtott

utasítássorozatot ­ processzor-löket (CPU-burst) ­ egy be/kiviteli (B/K) m velet ­ be/kiviteli löket (I/O-burst) ­ követ, és ez a két fázis ismétl dik ciklikusan. A be/kiviteli m velet végrehajtása a megszakításos, vagy DMA jelleg szervezés miatt gyakorlatilag csak a perifériát (és id szakosan a be/kivitelben résztvev vezérl egységeket és adatutakat) köti le és nem veszi igénybe a CPU-t. Egy folyamat be/kiviteli m veleteinek végrehajtása közben a CPU így más folyamat futtatásával foglalkozhat. Ekkor természetesen lehetséges, hogy a m köd perifériára egy közben futó folyamat újabb be/kiviteli m veletet kezdeményez, és ez többször is ismétl dhet. Tehát a perifériákért is versenyeznek a folyamatok, azokat is egyedi er forrásoknak kell tekinteni, a rájuk várakozó folyamatokat sorba kell állítani, ütemezni kell stb. Amikor egy be/kiviteli m velet befejez dött, a m veletet kezdeményez folyamat ismét a CPU-ért versenyez, hogy következ processzor-lökete végrehajtódhasson.

A rendszer folyamatai különbözhetnek abban a tekintetben, hogy futásuk során milyen arányban használják a CPU-t és a B/K eszközöket. Vannak folyamatok, amelyeket intenzív CPU-használat, és mérsékelt B/K igény jellemez. Ilyenek például a numerikus közelít módszerekkel dolgozó egyenletmegoldások, és minden olyan program, amelyik sok számítást végez viszonylag kevés adattal. Más folyamatok alig használnak CPU-t, de annál intenzívebb

I. Multiprogramozott operációs rendszerek

13

a B/K tevékenységük. Ilyenek például a formátum-átalakítást végz konverziós programok. A CPU használat és B/K használat aránya alapján megkülönböztetünk CPU-intenzív, illetve B/K-intenzív folyamatokat. Az er források jó kihasználásának feltétele, hogy egy adott id szakban a CPU-intenzív folyamatok és a B/K-intenzív folyamatok száma kiegyenlített legyen a rendszerben.

Az operációs rendszer az elvégzend

feladatok végrehajtását valamilyen szempontból

optimalizálni igyekszik. Ez lehet például kötegelt feldolgozás esetén az átereszt képesség, vagy a processzor-kihasználás maximalizálása, egy feladat átlagos átfutási idejének minimalizálása stb., interaktív rendszerek esetén az átlagos válaszid valósidej minimalizálása,

rendszerek esetén a határid -mulasztások minimalizálása, és még sok más

jellemz . A megfogalmazott célokhoz igazítják azokat az algoritmusokat, amelyek döntenek új folyamatok beengedésér l a rendszerbe (új job indulása, új felhasználó belépése), a multiprogramozás fokának változtatásáról (növelés vagy csökkentés), az egyes

folyamatoknak kiosztott memóriaterület méretér l, és amelyek ütemezik az er forrásokat.

Az operációs rendszer folyamatkezelését két modellel szemléltetjük. Az egyik egy tömegkiszolgálási modell, az úgynevezett sorállási modell (grafikus ábrázolása a sorállási diagram), amelyik a folyamatok er forrás-használatára koncentrál, a másik egy állapotmodell (grafikus ábrázolása az állapotdigram), amelyik a folyamatok

végrehajtásának menetére koncentrál.

I.3.1.2. Sorállási modell A sorállási modell korlátos er forráskészletért verseng folyamatok rendszerének elemzésére alkalmas. A modell a sorállási diagramon szemléltethet . A modell addig áttekinthet , amíg azoknak az er forrásoknak a használatát szemléltetjük vele, amelyeket a folyamatok szekvenciálisan használnak, azaz elengedik a birtokolt er forrást, miel tt újat igényelnének. Az operációs rendszerek tipikus sorállási diagramját a 1. ábra mutatja. A diagram a processzor-löket, I/O-löket ciklikusságot szemlélteti azzal a feltételezéssel (ami normális m ködés esetén általában teljesül), hogy a folyamatoknak közben folyamatosan elegend memória áll rendelkezésükre.

I. Multiprogramozott operációs rendszerek

14

Hosszútávú ütemezés Belép CPU várakozási sor

Rövidtávú (CPU) ütemezés

Kilép CPU

Diszk

Diszk várakozási sor

Szalag

Szalag várakozási sor

...

Perifériák ütemezése

...

Nyomtató

Nyomtató várakozási sor

1. ábra Sorállási diagram

Az er forrásokat körök, a várakozási sorokat téglalapok jelölik. A rendszer m ködését a folyamatok irányított élek mentén történ vándorlása szemlélteti. Az új, induló folyamatok processzor-lökettel kezd dnek, ezért a CPU várakozási sorába lépnek be. Normál befejez dés esetén ugyancsak processzor-löketb l lépnek ki. Közben a be/kiviteli m veleteikt l függ en kerülnek át a különböz perifériák várakozási soraiba, illetve lesznek a perifériák használói. Egy be/kiviteli löket után ismét a CPU várakozási sorába kerülnek vissza.

A

modell

számításokra

is

alkalmas

változata

valószín ségi

változókat

és

eloszlásfüggvényeket használ a terhelés (a folyamatok rendszerbe történ belépésének id beli gyakorisága) és a kiszolgálás (az er források birtoklásának id szükséglete) jellemzésére. A valószín ségi modell kiértékelése alapján adott struktúrára, adott terhelési és kiszolgálási paraméterek mellett számíthatók a rendszer fontos m ködési jellemz inek (pl. átfutási id , várakozási id , sorhosszúság) várható értékei, illetve egyéb valószín ségi jellemz i.

I. Multiprogramozott operációs rendszerek

15

A diagramon jól azonosíthatók az ütemezési pontok, amelyek tipikusan a várakozási sorok kimenetén helyezkednek el. Kivétel a rendszerbe való bejutást szabályozó ún. hosszútávú ütemez , amelyik tipikusan a kötegelt feldolgozást végz rendszerekben van jelen, és új jobok végrehajtásának megkezdésér l (új folyamatok indításáról) dönt. Az elvégzésre váró munkák közül a választás szempontja, hogy a rendszerben a CPU-intenzív, és B/K-intenzív folyamatok aránya optimális legyen (optimális job-mix fenntartása). Jó tehát, ha a rendszernek van el zetes információja egy-egy munka CPU, illetve B/K igényér l. Kitüntetett szerepe van a CPU-ütemez nek, amit általában rövidtávú ütemez nek hívnak, és amelynek algoritmusait külön fejezetben tárgyaljuk. (A rövid- illetve hosszútávú elnevezés a futási gyakoriságra utal. A hosszútávú ütemez általában akkor fut le, amikor egy job végrehajtása befejez dik. A rövidtávú ütemez pedig biztosan lefut, amikor egy processzorlöket befejez dik. A két gyakoriság között több nagyságrend különbség van). A perifériák ütemezése a leggyakrabban érkezési sorrendben (FIFO) történik. Kivétel pl. a mágneslemez, amelynek hatékony ütemezésével ugyancsak foglalkozunk a kés bbiekben. Néhány rendszerben m ködik középtávú ütemez is, amelynek egyik szerepe a

multiprogramozás fokának változtatása jellegzetesen azokban a helyzetekben, amikor a memória válik a rendszer sz k keresztmetszetévé, illetve ez a helyzet megsz nik. A középtávú ütemez ­ észlelve a memória-sz két ­ egyes folyamatokat felfüggeszt, ket az

memóriaterületüket háttértárra menti és felszabadítja, átmenetileg kivonja

er forrásokért folytatott versengésb l. A felfüggesztett folyamatok memóriaterületét a többi folyamat használhatja. Kés bb, ha a terhelés csökken, a felfüggesztett folyamatok visszatölthet k és folytathatják m ködésüket. A felfüggesztend , illetve visszatöltend folyamatok kiválasztásának szempontja is a CPU-intenzív és B/K-intenzív folyamatok kiegyensúlyozása lehet, ami már nem csak el zetes információkra, hanem a folyamatok korábbi viselkedésére is alapozhat. A középtávú ütemez akkor is felfüggeszthet folyamatot, ha az várhatóan igen hosszú várakozásra kényszerül. A középtávú ütemez helye nem

mutatható meg a diagramon, mert a memória használata és a memóriaigény növekedése más er források (CPU) használata közben lép fel, az er forrás-használat nem szekvenciális, ezért a modell ennek leírására ebben a formában nem alkalmas.

I. Multiprogramozott operációs rendszerek

16

I.3.1.3. Állapotmodell Egy folyamat végrehajtásának dinamikáját a multiprogramozott rendszerekben egy hozzárendelt állapotjelz vel és az állapot-átmeneti gráffal írhatjuk le.

Az állapot-átmeneti gráf legegyszer bb változatát a 2. ábra. mutatja be.

Létrejön Futásra kész

CPU-t kap Futó CPU-t elveszik, vagy lemond A várt esemény bekövetkezik

Befejezõdik

Várakozásra vezetõ rendszerhívás

Várakozó

2. ábra Folyamat állapot-átmeneti diagramja

Futásra kész (ready) állapotban vannak azok a folyamatok, amelyeknek következ m veletét a CPU bármikor végrehajthatná. Másszóval a CPU-n kívül minden más er forrást birtokolnak, amire m ködésük adott szakaszában szükségük van. Futó (running) állapotban egy multiprogramozott rendszerben egyidej leg egyetlen folyamat lehet, amelyiknek az aktuális m veletét a CPU éppen végrehajtja. Várakozó (waiting, blocked) állapotban vannak azok a folyamatok, amelyek nem tudják használni a CPU-t, mert valamilyen feltétel teljesülésére várakoznak. Ilyen feltétel lehet pl. egy általuk kezdeményezett be/kiviteli m velet befejez dése, együttm köd esetén valamilyen szinkronizációs vagy kommunikációs m velet végrehajtódása. folyamatok

Állapotátmenetek:

Amikor a folyamat létrejön, megkapja a fizikai memória egy területét, ahova betölt dik a kódja, vagy legalább is annak az induláshoz szükséges része, létrejönnek a változói, esetleg más er forrásokat, indítási paramétereket kaphat. Az operációs rendszer nyilvántartásba veszi, és futásra kész állapotba állítja, hogy végrehajtása megkezd zhessen.

I. Multiprogramozott operációs rendszerek

17

Futásra kész => futó állapotátmenet történik, amikor az operációs rendszer CPU-ütemez je kiválasztja a folyamatot végrehajtásra. Új futó folyamat kiválasztása mindenképpen szükséges, ha az el z folyamat befejezte m ködését, vagy várakozó állapotba került, hiszen ilyenkor a CPU felszabadul.

Futó => futásra kész állapotátmenet két ok miatt fordul el . · Az operációs rendszer elveszi a processzort a folyamattól (preemptív ütemezés). Amikor a CPU ütemez nem érkezési sorrendben hajtja végre a futásra kész folyamatokat, hanem például prioritás szerinti sorrendben, akkor el fordulhat, hogy egy folyamat futása közben egy nála magasabb prioritású másik folyamat átlép várakozó állapotból futásra kész állapotba. Ha a prioritás azonnali érvényesítése fontosabb szempont, mint egyszer en a CPU munkában tartása, akkor a futó folyamatot meg kell szakítani, vissza kell léptetni futásra kész állapotba, és a magasabb prioritású folyamatot kell futásra kiválasztani. · A folyamat lemond a processzorról (újraütemezést kér). Együttm köd folyamatok kooperatív viselkedésének egyik formája, hogy nempreemptív ütemezés esetén egy folyamat hosszú processzor-löketek közben, meghatározott pontokon lehet séget ad más folyamatok futására.

Futó => várakozó állapotátmenet akkor következik be, ha a folyamat olyan m veletet indított, amelynek végrehajtása várhatóan hosszabb (más folyamat futtatására kihasználható idej ) CPU-tétlenséget okozna. Ilyenek a be/kiviteli m veletek, az er forrás-foglalások, ha az er forrás foglalt, a szemaforra kiadott várakozások, ha a szemafor tilosat jelez, az üzenetfogadások, ha az üzenet még nem érkezett meg, stb.

Várakozó => futásra kész állapotátmenet történik, ha a folyamat által várt esemény bekövetkezik (pl. az elindított be/kivitel befejez dik, az er forrás felszabadul, a szemaforra jelzés érkezik, az üzenet megérkezik stb.).

A folyamatok m ködésüket akkor fejezik be, amikor utolsó utasításuk végrehajtódik. Ez normális esetben egy olyan rendszerhívás (pl. exit), aminek hatására az operációs rendszer

I. Multiprogramozott operációs rendszerek

18

felszabadítja a folyamat er forrásait és törli a folyamatot a nyilvántartásából, esetleg információt ad a folyamat szül jének a futás eredményér l.

A bemutatott állapotmodell csak a legalapvet bb eseteket tartalmazza. A gyakorlatban az operációs rendszerek általában bonyolultabbak. Alkalmazzák például a felfüggesztést, ami a folyamat m ködésének id leges szüneteltetését jelenti, miközben memóriaterülete

felszabadul, vagy a folyamat "kilövésének" lehet ségét (végleges eltávolítását általában rendellenes m ködés miatt), illetve több más várakozó állapotot is bevezetnek. A felfüggesztett állapotokkal kiegészített állapot-átmeneti diagram egy változatát mutatja a 3. ábra.

Létrejön Futásra kész

CPU-t kap Futó CPU-t elveszik, vagy lemond

Befejezõdik

Felfüggesztve futásra kész

A várt esemény bekövetkezik Várakozó

Várakozásra vezetõ rendszerhívás

Felfüggesztve várakozó Felfüggesztett állapotok

3. ábra Felfüggesztett állapotokkal kiegészített állapot-átmeneti diagram Látható, hogy a rendszer várakozó, vagy legfeljebb futásra kész folyamatokat függeszt fel, és a felfüggesztett folyamatokat is áthelyezi felfüggesztve futásra kész állapotba a várt esemény bekövetkezésekor. I.3.1.4. Egy megvalósítási séma A következ kben egy logikai sémát mutatunk be. A legtöbb operációs rendszerben ehhez hasonló megoldásokat találunk, bár a konkrét részletekben jelent s eltérések lehetnek.

I. Multiprogramozott operációs rendszerek

19

Az operációs rendszer a folyamatok kezeléséhez szükséges információkat egy speciális adatszerkezetben, a folyamatleíróban (Process Control Block, PCB) tárolja.

A folyamatleíró tartalma: · a folyamat azonosítója · a folyamat állapota · a folyamat szül jének és gyerekeinek azonosítója · a folyamathoz tartozó összes tárterület leírása, mutatók illetve a virtuális tárkezeléshez szükséges összes adat (címtranszformációs táblák, lemez blokkok leírása, stb.) · a folyamat által használt egyéb er források leírása (pl. a nyitott állományok leírása) · a regiszterek tartalma · várakozó folyamatoknál a várt esemény leírása · ütemezéshez szükséges információk (prioritás, várakozási id ) · számlázási információk és egyéb statisztikák.

A sorállási modellt az operációs rendszer tipikusan a folyamatleírók láncolt listákra f zésével valósítja meg (4. ábra).

I. Multiprogramozott operációs rendszerek

20

PCB 4 Futó folyamat

Futásra kész sor (CPU várakozási sora)

PCB 1

PCB 3

PCB 5

PCB 7

1. periféria várakozási sora

...

PCB 2 n. periféria várakozási sora IOCB 2

PCB 6 IOCB 6

4. ábra Folyamatleírók láncolása

Az ábrán a P4 folyamat fut, a P1, P3. P5. és P7. folyamat futásra kész, az 1. periféria szabad, az n. periféria a P2 folyamat által kezdeményezett be/kiviteli m veletet hajtja végre (a perifériák érkezési sorrendben szolgálják ki a folyamatokat, ezért nincs külön mutató arra, hogy melyik folyamat m veletét hajtja végre éppen a periféria), de már a P6 folyamat is kiadott rá m veletet. A P2 és P6 folyamat várakozó. A be/kiviteli m veletek paramétereinek tárolására a rendszer be/kiviteli leírókat (IOCB, Input-Output Control Block) használ. Az IOCB tartalmazza a m velet kijelölését (pl. olvasás, írás), a tárterület címét, ahova, vagy ahonnan a B/K m velet végrehajtandó, szükség esetén a B/K készülékre vonatkozó egyéb adatokat (pl. mágneslemez egység szektorcíme, az átviend adatmennyiséget, állapotjelz ket stb., azaz a m velet végrehajtásához szükséges valamennyi adatot. Az IOCB-k a B/K m veletet kezdeményez folyamat PCB-jére f z dnek fel, így az elindított B/K m veletek és az azokra várakozó folyamatok összetartozásának nyilvántartása is megoldott.

A perifériák mellett hasonló várakozási sorok szervezhet k szemaforokra, logikai er forrásokra és más szinkronizációs, kommunikációs objektumokra.

Látható, hogy a bemutatott megoldásban a folyamat állapotát a PCB-ben tárolt állapotjelz mellett az is jellemzi, hogy a hozzá tartozó PCB éppen melyik sorban található.

I. Multiprogramozott operációs rendszerek

21

Amikor a rendszer átkapcsol egy másik folyamat futtatására, a futó folyamat teljes állapotterét menteni kell, hogy a végrehajtás folytatható legyen (logikai memória, logikai processzor), továbbá az új futó folyamat utoljára elmentett állapotterét kell el venni és visszaállítani, hogy annak végrehajtása folytatódjon. Ezt a m veletet környezetváltásnak (context switching) nevezik. Tekintve, hogy a memóriát a folyamat tartósan birtokolja, a memóriakép meg rz dik a folyamat várakozó állapotában is, így csak a logikai processzor átkapcsolása szükséges. Ez egyrészt a fizikai processzor regisztereinek, másrészt az operációs rendszer bels változóinak (rendszertáblázatok, memóriakezelési információk, periféria hozzárendelések stb.) elmentését, és az új folyamatnak megfelel beállítását jelenti. A mentés a PCB-ben fenntartott megfelel területre történik.

A be/kiviteli m veletek végrehajtásának menete a következ : · A folyamat (általában rendszerhívások segítségével) kitölt egy IOCB-t, amiben megadja a m velet paramétereit · B/K rendszerhívást hajt végre az IOCB paraméterként történ átadásával · Az operációs rendszer · hozzáláncolja az IOCB-t a folyamat PCB-jéhez · a folyamat PCB-jét bef zi a periféria sorába · ha a sor üres volt, az IOCB paramétereivel indítási parancsot ad a perifériának · a folyamatot várakozó állapotba helyezi · CPU ütemezést hajt végre, azaz kiválasztja a következ futó folyamatot és környezetet vált · visszatér (a visszatérés a környezetváltás miatt az új folyamatra történik)

A CPU és a perifériák párhuzamosan m ködnek. Az átvitelek végét megszakítások jelzik, amelyeket az operációs rendszer kezel (a megszakítások kiszolgáló programjait hardverütemezés rendszerfolyamatoknak tekinthetjük).

Egy be/kiviteli megszakítás kezelésekor az operációs rendszer: · az átvitel helyes vagy hibás eredményére utaló jelzést ír a periféria várakozási sorának elején álló PCB-hez láncolt IOCB-be

I. Multiprogramozott operációs rendszerek

22

· a sor elején álló PCB-t kif zi a sorból, átteszi a futásra kész sorba, a PCB-ben a folyamat állapotjelz jét futásra kész-re állítja · ha van még várakozó folyamat a periféria sorában, a következ IOCB paramétereivel indítási parancsot ad a perifériának · ha a CPU-ütemezés preemptív, CPU ütemezést hajt végre · visszatér

Ezzel a szervezéssel a B/K rendszerhívást kiadó folyamatnak a rendszerhívást követ utasítása akkor hajtódik végre, amikor az átvitel már befejez dött, és a CPU ütemez választotta ki futásra. t

I.3.1.5. Tétlen ciklusok kiküszöbölése A szinkronizációs és kommunikációs m veletek ugyancsak okozhatják a folyamatok várakozását. A szemafor P(s) m veletének korábban (a III.2.5.3. pontban) bemutatott definíciós programja: while s<1 do skip; s:=s-1; Ez a program az oszthatatlanság mellett még azzal a feltételezéssel is él, hogy minden folyamatot külön processzor hajt végre, amelynek nincs más dolga, mint ciklikusan tesztelni a szemaforváltozót, amíg csak szabadnak nem találja. Multiprogramozott rendszerben ezek a tétlen ciklusok ­ az ún. foglalva várakozás (busy waiting) ­ használhatatlanok (gyakorlatilag még multiprocesszoros esetben is azok, ezért nevezzük a programot csupán definíciós programnak), hiszen a ciklikus tesztelés feleslegesen kötné le a processzort és a memóriát.

A szemaforkezelést ezért az operációs rendszer hatáskörébe kell utalni P és V rendszerhívásokkal, amelyek megvalósítása például a következ lehet:

Feltételezzük, hogy az operációs rendszer folyamatkezel rendszerhívásai között van Elalszik m velet, amelyik a hívó folyamatot várakozásba helyezi és CPU ütemezést indít, valamint

I. Multiprogramozott operációs rendszerek

23

Felébreszt(p) m velet, amelyikkel egy folyamat futásra kész állapotba tudja tenni a p várakozó folyamatot. Feltételezzük továbbá, hogy a nyelv rendelkezik listakezel m veletekkel (Felf z, Lef z).

A szemafor megvalósításának pszeudo kódja:

type semaphore = record érték:integer:=1; várósor: list of folyamat; end;

P(s): s.érték:=s.érték-1; if s.érték < 0 then begin Felf z(s.várósor); Elalszik; end;

V(s): s.érték:=s.érték+1; if s.érték < 1 then begin Lef z(p,s.várósor); Felébreszt(p); end;

Megjegyzések: · A szemafor s változójának pillanatnyi értéke tárolja a szemaforra várakozó folyamatok számát (negatív el jellel). · A szemafor ütemezési elve (a várakozók közül a továbbinduló kiválasztása) a listakezel m veletek algoritmusában van elrejtve.

I. Multiprogramozott operációs rendszerek

24

I.3.2. Processzor ütemezés

A multiprogramozott operációs rendszerek alapjának a CPU ütemezés tekinthet . A rövidtávú ütemezés feladata annak eldöntése, hogy a processzort melyik futásra kész folyamat kapja meg. Mivel, mint azt az el z fejezetben láttuk, a rövidtávú ütemez gyakran fut, ezért gyorsnak kell lennie, hogy a CPU id ne az ütemezéssel teljék. Ezért ez az ütemez része a kernelnek és állandóan a memóriában van.

A rövidtávú ütemez k két alapvet fajtáját különböztehetjük meg. Preemptív (preemptive) ütemezésr l beszélünk, ha az operációs rendszer elveheti a futás jogát az éppen futó folyamattól, "futásra kész" állapotúvá teheti, és a CPU-t egy másik folyamatnak adhatja, azaz egy másik folyamatot indíthat el.

Nem preemptív (non preemptive) ütemezésr l akkor beszélünk, ha az operációs rendszer nem veheti el a futás jogát a folyamattól, azaz a futó folyamat addig birtokolja a CPU-t, amíg egy általa kiadott utasítás hatására állapotot nem vált, azaz csak maga a folyamat válthatja ki az új ütemezést, pl. ha befejez dik, valamilyen er forrásra, eseményre vár vagy önként lemond a futás jogáról.

Ütemezés következhet be, ha

· a futó folyamat befejez dik · egy folyamat felébred, futásra késszé válik · a futó folyamat várakozni kényszerül (valamilyen esemény bekövetkezésére), illetve · a futó folyamat önként lemond a futás jogáról vagy pedig elveszik t le.

Az els és a harmadik esetben az ütemezés mindig környezetváltással jár, hiszen a következ futó folyamat egészen biztosan nem a korábban futott lesz. A másik két esetben el fordulhat, hogy az ütemez nek nem kell másik folyamatot kiválasztania.

I. Multiprogramozott operációs rendszerek

25

Ha történik ütemezés a második esetben (folyamat felébred), illetve a negyedik eset bizonyos eseteiben (elveszik a CPU-t a futó folyamattól), akkor egészen biztos preemptív az ütemez , egyébként lehet ilyen is és olyan is. Maga az ütemezés úgy történik, hogy az ütemez valamilyen algoritmus szerint kiválaszt egy futásra kész folyamatot a futásra kész sorból (ready queue).
Megjegyzés: Nem értek egyet a felvezetés logikájával. El ször kellene arról beszélni, hogy mikor lehet értelme ütemezni, aztán arról, hogy a döntés szerint lehet preemptív vagy nem.

Miel tt azonban belemennénk a rövidtávú ütemezési algoritmusok tárgyalásába, nézzük meg, hogyan lehet ezeket összehasonlítani, illetve milyen követelményeket fogalmazhatunk meg az ütemezési algoritmusokkal szemben.

I.3.2.1. Az ütemezési algoritmusok összehasonlítása

A különböz

ütemezési algoritmusok különböz

tulajdonságokkal rendelkeznek. Adott

helyzetekben alkalmazott algoritmusok kiválasztásánál ezen tulajdonságok hatását kell mérlegelni és a célnak legmegfelel bbet kiválasztani.

A leggyakrabban alkalmazott összehasonlítási mértékek a következ k:

· Központi egység kihasználtság (CPU utilization). Alapvet cél, hogy a CPU lehet leg minél több id t fordítson ,,hasznos" munka végzésére. A CPU kihasználtság azt mutatja, hogy a CPU id hány százaléka fordítódik ténylegesen a folyamatok utasításainak végrehajtására. A kihasználtságot csökkenti, ha a CPU henyél (idle), azaz nincs olyan folyamat, amelyik futhat, illetve amikor rendszeradminisztráció, ütemezés, stb. történik (rezsi, overhead):

CPU id

- (henyé lé s adminisztrá ció) + 100 CPU id

[% ]

A kihasználtság tipikus értékei 40-90 % közé esnek.

I. Multiprogramozott operációs rendszerek

26

· Átbocsátó képesség (throughput). Az egy id egység alatt elvégzett munkák számát mutatja.
Megjegyzés: Eezt nem tudom javítani (egybe-külön)....

elvé gzettmunká k szá ma id

Az átbocsátó képesség tipikus értékei nagyon széles tartományban szórnak, a feladatok jellegét l függ en (pl. ...,1/h, ..., 10/sec, ...).

· Körülfordulási id (turnaround time). Egy-egy munkára vonatkozóan a rendszerbe helyezést l a munka befejez déséig eltelt id t mutatja.

si ( vé grehajtá id

+ vá rakozá si id

)

A fenti két összetev közül a végrehajtási id nem függ az ütemezést l, ezért az ütemezési algoritmusok jellemzésére alkalmasabbnak t nik a várakozási id .

· Várakozási id (waiting time). Értéke azt mutatja, hogy egy-egy munka összességében

mennyi id t tölt várakozással. A várakozó és futásra kész állapotokban töltött id n kív l ide számítódik a felfüggesztett állapotok ideje, valamint a hosszútávú ütemezésig eltel el zetes várakozás is:

sz (vá rakozó+ futá sra ké + felfüggesztett + hosszútá vú ütemezé sig eltel )

id

· Válasz id (response time). Id osztásos rendszerekben nagyon fontos, hogy a

felhasználók érezzék, hogy a rendszer reagál a parancsaikra. A válaszid az az id , amely az operációs rendszer kezel i felületének - esetleg egy felhasználóval kommunikáló folyamatnak - adott kezel i parancs után a rendszer els látható reakciójáig eltelik, vagyis amennyi id alatt a rendszer válaszolni képes.
Megjegyzés: Nem csak id osztásos

I. Multiprogramozott operációs rendszerek

27

I.3.2.2. Az ütemezési algoritmusokkal szembeni követelmények

Az ütemezési algoritmusokkal szemben az operációs rendszerekben különböz - gyakran egymásnak ellentmondó - követelmények fogalmazhatók meg. Az alábbiakban néhányat felsorolunk ezek közül:

· Valamilyen célfüggvény szerint legyen optimális. (Ez a követelmény messze túlmutat az

operációs rendszereken, hiszen bármilyen mérnöki tervezés esetén fontos annak a megfogalmazása, hogy az adott rendszer milyen célra készül, és ennek megfelel en lehet törekedni a cél szerinti optimum elérésére.)
· Legyen korrekt, azaz minden folyamat kapjon egy bizonyos CPU id t, kezeljen azonosan

bizonyos folyamatokat.
· Egyes folyamatoknak biztosítson prioritást. · Kerülje a kiéheztetést. · A viselkedése legyen ,,jósolható", azaz terhelést l függetlenül becsülhet legyen pl. a

várható maximális körülfordulási id , a futtatási költség, stb.
· Legyen minimális a rezsi id . (Bár ez nem mindig eredményez jobb teljesítményt!) · Legyen minimális a batch munkák várakozási ideje. · Legyen maximális az átbocsátó képesség. · Részesítse el nyben azokat a folyamatokat, amelyek fontos (népszer ) er forrásokat
Megjegyzés: Adminisztrációs id veszteség (overhead)

foglalnak (hiszen az ilyen folyamatok sok más folyamatot várakozásra kényszeríthetnek).
· Részesítse el nyben a kihasználatlan er forrásokat igényl folyamatokat. · Növekv terhelés esetén a rendszer teljesítménye ,,elegánsan", azaz fokozatosan romoljon

le és ne omoljon össze hirtelen (graceful degradation). (Napjainkban ez a követelmény egyre fontosabb alap-szemponttá válik, és megint csak azt kell mondanunk, hogy az operációs rendszereken túlmen en, szinte minden összetett, orvosi, diagnosztikai, folyamatirányítási, kommunikációs, beágyazott, stb. rendszer kapcsán az egyik els dleges tervezési szempontként merül fel.)

Jól látható, hogy a fenti elvárások közül több egymásnak ellentmondó, így együttesen nem teljesíthet . Ezért is olyan fontos minden rendszernél megfogalmazni azokat a célokat,

I. Multiprogramozott operációs rendszerek

28

amelyek kiemelt fontosságúak az adott esetben, hogy ennek megfelel en kiválaszthatók legyenek azok a szempontok, amelyek mentén optimalizálni akarunk.

I.3.2.3. Ütemezési algoritmusok

(1) Egyszer ütemezési algoritmusok

Legrégebben várakozó (First Come First Served, FCFS)

Nem preemptív algoritmus, amely a legrégebben várakozó folyamatot választja ki futásra. Megvalósítása igen egyszer , a futásra kész folyamatok egy várakozási sor végére f z dnek fel, az ütemez pedig mindig a sor legelején álló folyamatot kezdi futtatni.

Ennél az algoritmusnál igen nagy lehet az átlagos várakozási id , mivel egy-egy hosszú CPU löket folyamat feltartja a mögötte várakozókat (ezt hívjuk konvoj hatásnak). Képzeljünk el egy rendszert egy hosszú CPU löket idej és több rövid CPU löketidej folyamattal. Az els folyamat futása alatt az összes többi várakozni kényszerül és a perifériák is tétlenek lesznek. Kés bb, amikor a hosszú CPU löketidej folyamat perifériás m veletre vár, a helyzet

megfordulhat, azaz a rövid folyamatok futása után a CPU lehet tétlen.

Körbeforgó (Round Robin, RR)

Preemptív algoritmus, amely az id osztásos rendszerek alapjának tekinthet . Minden folyamat, amikor futni kezd, kap egy id szeletet (time slice). Ha a CPU lökete nagyobb ennél, akkor az id szelet végén az ütemez elveszi a folyamattól a processzort, és a futásra kész állapotúvá tett folyamatot a futásra kész sor végére állítja.

Ha a CPU löket rövidebb az id szeletnél, akkor újraütemezzük, és a futó folyamat id szelete újraindul.

a löket végén a rendszer folyamatait

I. Multiprogramozott operációs rendszerek

29

Ezeknél az algoritmusoknál nehéz az id szelet megfelel méretének a meghatározása. Túl hosszú id szelet esetén ugyanis az algoritmus átmegy FCFS algoritmusba, míg túl kicsire választás esetén megn a környezetváltások száma, ami a rendszer hasznos teljesítményét jelent sen lerontja. A statisztikai vizsgálatok alapján ökölszabályként alkalmazható, hogy a CPU löketek kb. 80%-a legyen rövidebb az id szeletnél.

Egy másik érdekes kérdés az id szelet hossza és a körülfordulási id közötti összefüggés. Els várakozásainkkal ellentétben az esetek jelent s részében nem monoton függvényt

kapunk válaszul. Példaként próbáljuk felrajzolni (környezetváltások nélkül) a fenti összefüggést egy olyan rendszerben, ahol négy futásra kész folyamat van, a következ CPU löketid kkel: 6, 3, 1 és 7 id egység (lásd 4.3.x. ábra).
Megjegyzés: Ennek mi a jelent sége?Ki vár monotont, és milyen irányban? Átlagos körülfordulási id r l van szó?

4.3.x. ábra Példa a körülfordulási id és az id szelet hosszának összefüggésére Round Robin

rendszerekben

(2) Prioritásos ütemezési algoritmusok

A prioritásos algoritmusok közös sajátossága, hogy a futásra kész folyamatok mindegyikéhez egy, a futás kívánatos sorrendjére utaló számot - prioritást (priority) rendelünk. Az algoritmusok pedig a futásra kész folyamatok közül a ,,legnagyobb" prioritásút választják ki következ futtatandónak.

A prioritás hozzárendelése történhet az operációs rendszeren kívüli tényez k (pl. a folyamat saját kérése vagy operátori beavatkozás) által - ilyenkor küls prioritásról beszélünk, vagy történhet az operációs rendszer által - ilyenkor bels prioritásról beszélünk.

A prioritások lehetnek id ben állandóak - statikus prioritás - vagy (az operációs rendszer által módosított) id ben változóak - dinamikus prioritás.

Az alább ismertetett algoritmusok esetében a prioritást a CPU löketid határozza meg.

Legrövidebb (löket)idej (Shortest Job First, SJF)

I. Multiprogramozott operációs rendszerek

30

Nem preemptív algoritmus, amely a futásra kész folyamatok közül a legrövidebb becsült löketid vel rendelkez folyamatot választja ki következ nek futásra.

Az algoritmus kiküszöböli a FCFS-nél tapasztalható konvoj hatást, és ennél az algoritmusnál optimális az átlagos várakozási és körülfordulási id .

Komoly gondot jelenthet azonban az, hogy a löketid k általában nem ismertek. Ilyenkor az operációs rendszer becslésekb l indul ki, vagy a folyamatot elindító felhasználó ,,bevallását" tekinti kiindulásnak. El bbi esetben a folyamat el z viselkedése alapján, a korábbi löketid k - általában exponenciális - átlaga szolgál a prioritás alapjául.

Ha a felhasználó által megadott értékeket vesszük alapul, akkor figyelembe kell venni azt is, hogy a felhasználók ,,nem érdekeltek" a löketid k pontos megadásában, hiszen tisztában vannak vele, hogy kisebb érték vallása esetén el nyösebb lesz a besorolásuk (bár a rajtakapott hazugságokat büntetheti is az operációs rendszer ,,hátrasorolással").

Ismételt futás esetén azonban a helyzet sokkal jobb, hiszen a rendszerstatisztikákból már ismertek lehetnek a löketid k.

Legrövidebb hátralev idej (Shortest Remaining Time First, SRTF)

Ez az algoritmus az SJF preemptív változata. Ha egy új folyamat válik futásra késszé, akkor az ütemez megvizsgálja, hogy az éppen futó folyamat hátralev löketideje, vagy az új

folyamat löketideje kisebb, és a rövidebbet indítja el.

Egy futó folyamat megszakításához és egy másik elindításához környezetváltásra is szükség van, ami szintén id t igényel, így ezt is figyelembe kell venni, amikor egy futó folyamat megszakítása mellett döntünk.

Az algoritmus használata az el z ével azonos problémákat vet fel.

I. Multiprogramozott operációs rendszerek

31

Legjobb válaszarány (Highest Response Ratio, HRR)

A prioritásos algoritmusok nagy hátránya a kiéheztetés veszélye. (Vagyis, hogy a kis prioritású folyamatok el l a nagyobb prioritásúak ,,ellopják" a CPU-t.) Ennek kivédése az
öregítés (aging) révén történhet, amikor a rendszer a régóta várakozó folyamatok prioritását

fokozatosan növeli.

Ezt az elvet alkalmazza az SJF-b l kiindulva a HRR algoritmus. A folyamatok kiválasztásánál a löketid mellett, a várakozási id t is figyelembe veszi. A prioritás alapjául a

(löketid + k* várakozási id ) / löketid

összefüggés szolgál (k egy alkalmasa megválasztott konstans).

(3) Többszint algoritmusok

A többszint algoritmusok sajátossága, hogy a futásra kész folyamatok nem egy, hanem több sorban várakozhatnak. Minden sorhoz prioritás van rendelve és az ütemez csak akkor választ ki futásra kisebb prioritású sorból folyamatot, ha a nagyobb prioritású sorok mind üresek. Az egyes sorokon belül különböz kiválasztási algoritmusok m köd(het)nek.

Statikus többszint sorok (Static Multilevel Queues, SMQ)

Ennél az algoritmusnál a folyamatokhoz statikus prioritás rendel dik, azaz minden folyamathoz az elindulásakor rendelünk valamilyen prioritás (vagyis valamilyen kritérium alapján egy adott várakozási sorba soroljuk), amely a folyamat élete során nem változik (4.3.y. a, ábra).

Egy lehetséges példa a folyamattípusok prioritás besorolására a következ :

· rendszerfolyamatok (ezekhez célszer a legmagasabb prioritást rendelni, hiszen közvetlen

hatással vannak a rendszer m ködésére)

I. Multiprogramozott operációs rendszerek

32

· interaktív folyamatok (hogy biztosítani tudjuk a felhasználók számára elfogadható

válaszid t)
· interaktív szövegszerkeszt k (kevésbé kritikusak, mint az el z ek) · kötegelt feldolgozás (általában akkor futnak, ha ,,van id ") · rendszerstatisztikákat gy jt folyamatok (a kés bbi futtatásokhoz,

rendszerfejlesztésekhez, stb. hasznos illetve szükséges információkat gy jtik össze, azonban ezek általában nincsenek közvetlen hatással a pillanatnyi rendszer m ködésre, így alacsony lehet a prioritásuk).

A statikus prioritásra épül algoritmusok komoly hátránya az alacsony prioritással rendelkez folyamatok nagy várakozási ideje, kiéheztetése. Erre példaként említjük azt a világot bejárt esetet, amely szerint egy 1973-ban kikapcsolt IBM számítógépen az operátor talált egy 1967ben elindított és még mindig futásra váró folyamatot.

Visszacsatolt többszint sorok (Multilevel Feedback Queues, MFQ)

Az el z algoritmusnál mutatott probléma megoldása a már említett öregítés vagy valamilyen más, ezt teljesen vagy részlegesen kiváltó technika alkalmazása lehet. Az MFQ ütemezésnél a folyamatokhoz dinamikus prioritás rendel dik. Ez az ütemezés tehát dinamikus, vagyis a folyamatok a prioritás hozzárendelésüknek megfelel en dinamikusan átkerülhetnek egyik sorból a másikba.

Az egyes sorokon belül általában preemptív algoritmusokat - például növekv id szelet RRt - alkalmaz, kivéve a legkisebb prioritású sort, amelyen belül az ütemezés történhet egy egyszer FCFS által.

Az algoritmus a folyamatokat futásuk alapján különböz osztályokba sorolja és a rövid löketidej

maximális CPU löketidej

folyamatokat részesíti el nyben: A folyamatok

elindulásukkor általában a legnagyobb prioritású sorba lépnek be. Ha azonban túllépik az id korlátot, azaz futásukhoz nem elegend egy id szelet, akkor az operációs rendszer

csökkenti a prioritásukat, és eggyel lejjebbi (kisebb prioritású, ám nagyobb id szeletre, illetve FCFS-re épül ) sorba kerülnek át.

I. Multiprogramozott operációs rendszerek

33

Hogy feloldjuk a maximális löketid n alapuló besorolásból következ merevséget (vagyis hogy a folyamatok ne hordozzák egész életük során azt a ,,büntetést", amelyet akácsak egyszeri id szelet túllépés miatt is kaptak), célszer lehet id r l-id re felülvizsgálni a mérése alapján, a

folyamatok besorolását, és ha szükséges, például az átlagos löketid prioritásokat módosítani (növelni).

Hasonlóképpen, a régóta várakozó folyamatok prioritását az operációs rendszer megnövelheti (aging), és nagyobb prioritású sorba sorolhatja át (4.3.y. b, ábra).

Az MFQ ütemez ket a következ szempontok alapján lehet osztályokba sorolni:
· Hány sorban várakoznak a futásra kész folyamatok? · Milyen ütemezési algoritmus(oka)t használunk az egyes sorokon belül? · Hogyan kaphat nagyobb prioritást egy folyamat? · Mikor csökken egy folyamat prioritása? · Hová lépnek be az elindított folyamatok?

4.3.y. ábra Többszint ütemezés a, statikus b, visszacsatolt többszint sorok

I.3.2.4. Az ütemezési algoritmusok ,,jóságának" értékelése

Egy mérnök számára a ,,mi van benne" ,,hogyan m ködik" és ,,miért így" kérdések mellett soha nem kerülhet el annak megválaszolása sem, hogyha több lehet ség közül

választhatunk, akkor ,,melyik a jobb", illetve a meglev ,,hogyan tehet jobbá". Ez utóbbi kérdések megválaszolása a legtöbb esetben igen bonyolult, vagy egyenesen lehetetlen. Hiszen láttuk korábban, hogy a ,,jóság" követelményei összetettek, s t egymásnak ellentmondó elemeket tartalmaznak. Vagyis nem lehet általánosságban egyértelm választ adni. A konkrét esetekben azonban - alapos elemzés után - sokszor megadhatók a prioritások, vagyis az egyes elvárások fontossága. Így már közelebb kerülhetünk ahhoz, hogy megadjuk, hogy egy-egy konkrét esetben mit tekintünk ,,jónak", ,,optimális" m ködésnek.

I. Multiprogramozott operációs rendszerek

34

Példaként az id osztásos, interaktív rendszereket említjük, ahol az elfogadhatóan kis válaszid követelménye az egyik legfontosabb az elvárások között. Más rendszerek esetében ez a követelmény nem számít fontos tervezési szempontnak. Vagyis a jóság kérdését mindig a céllal szoros összefüggésben kell vizsgálnunk.

Az ütemezési algoritmusok jóságának mérésére többféle lehet ség kínálkozik. A fejezet végén egészen röviden ezeket fogjuk áttekinteni, mely a téma iránt mélyebben érdekl d k számára kiinduló pontul szolgálhat.

(1) Analitikus vizsgálat

A determinisztikus modellezés analitikus eszközt kínál az algoritmusok viselkedésének elemzésére. Sajnos a rendszerek terhelése számos véletlenszer paraméterrel jellemezhet , így a determinisztikus modellek inkább esetek elemzésére, mint jósági jellemz k számítására alkalmasak. El re összeállított adatokból - folyamatok száma, löketid k hossza ­ kiindulva, és az algoritmusokat a sorbanállás elmélet és sztochasztikus modellezés segítségével kezelve lehet következtetéseket levonni, azonban bármennyire is egyszer a vizsgálati
Megjegyzés: Valami fogalmazási nyeklés

módszer, a kapott eredmények nem általános érvény ek, hanem csak sz k körre lesznek igazak.

(2) Szimuláció

Az ütemezési algoritmusokat számítógépes modell segítségével is vizsgálhatjuk, mely során korábbi tapasztalatok vagy mérések alapján meghatározott eloszlású véletlen illetve konkrét mért számértékekkel jellemezhetjük a folyamatokat. számokkal

A nyert eredmények érvényessége a modell és az adatok helyességét l, valamint az elvégzett szimulációk mennyiségét l függ.

(3) Implementáció

I. Multiprogramozott operációs rendszerek

35

Elvileg lehet ségünk van az algoritmusok implementálására és így teljesítményük valós
körülmények közötti mérésére. Ez módszer a legmegbízhatóbb a felsoroltak közül, azonban

értelemszer en egyben a legköltségesebb is, így a gyakorlatban nem igen használják.

I.3.3. Ütemezés többprocesszoros rendszerekben

Az el z

fejezetben az egyprocesszoros rendszerekben történ

ütemezés kérdéseivel

foglalkoztunk. Napjainkban azonban egyre gyakoribbak az olyan, több processzort tartalmazó - szorosan csatolt - rendszerek, ahol igényként merül fel, hogy a futásra kész folyamatok a rendszer bármelyik szabad processzorán elindulhassanak, és így a feladatok elvégzése minél rövidebb id t igényeljen, illetve a rendszeren belül egyenletes terheléselosztást biztosítsunk a processzorok között.

A többprocesszoros rendszerekben történ processzor-ütemezés értelemszer en bonyolultabb feladat az egyprocesszoros esetnél. Az el z ekhez hasonlóan itt sem létezik ,,legjobb" megoldás, azonban a korábban tárgyalt elvek és sajátságok az esetek egy részében itt is alapvet en igazak lesznek.

Különbséget kell tennünk heterogén és homogén rendszerek processzor-ütemezése között. A
heterogén rendszerekre az jellemz , hogy a rendszerbe épített CPU-k különböz ek lehetnek

nemcsak méret, sebesség, felépítés, funkció, stb. tekintetében, hanem például az utasításkészlet szempontjából is. Ilyen esetekben a lefordított folyamatok kötötten, csak a nekik megfelel gépi utasításkészlettel rendelkez processzoro(ko)n lesznek képesek futni.

Hasonlóképpen csak bizonyos processzorokon indíthatók el azok a folyamatok, amelyek valamilyen speciális, az adott processzorhoz bels buszon keresztül csatlakoztatott eszköz használatát igénylik. Ez mind homogén, mind pedig heterogén rendszereknél kötöttséget jelent.

I. Multiprogramozott operációs rendszerek

36

A homogén rendszereknél, tehát ahol a beépített CPU-k funkcionalitás szempontjából egyformák, általában nagyobb szabadságunk van az ütemezésnél. A futásra kész folyamatok a rendszer bármelyik szabad processzorán elindulhatnak. Alapvet cél a terheléselosztás

biztosítása, tehát ahelyett, hogy a futásra kész folyamatok CPU-khoz rendelt külön sorokban várakoznának (és így könnyen el fordulhatna, hogy egy CPU tétlenül áll, míg egy másik futásra kész sorában több folyamat is várakozik), célszer közös várakozási sort (sorokat) létrehozni, ahonnan mindegyik processzor veheti a rajta következ ként futó folyamatot.

A közös várakozási sor(ok)on alapvet en kétféle ütemezési megközelítést alkalmazhatunk.
Szimmetrikus multiprocesszoros rendszerekben minden egyes CPU saját külön ütemez

algoritmust futtat, amely a közös sorból választ. A sorok hibamentes megosztott használatához pedig biztosítani kell a hozzáférésre vonatkozó kölcsönös kizárást.

Az aszimmetrikus multiprocesszoros rendszerek megkerülik ezt a problémát azzal, hogy egyetlen ütemez fut egy kiválasztott processzoron és ez az egyetlen ütemez osztja szét a feladatokat a szabad CPU-k között. Értelemszer en ez a master-slave felépítés sokkal egyszer bb adathozzáférést eredményez.

I.4. Tárkezelés

A multiprogramozott rendszerekben a CPU-t több folyamat megosztottan használja. Ahhoz, hogy megfelel m ködési sebességet tudjunk biztosítani, egyszerre több folyamatot is a

központi tárban (main storage, memory) kell tartanunk, hiszen, mint korábban láttuk, a

háttértárak elérési ideje - gyorsító tár alkalmazása ellenére is - sokkal nagyobb a f tárénál, így nagyon lassú lenne, ha környezetváltásnál a háttértárról kellene behozni, illetve a háttértárra kellene kivinni a folyamatokat. Vagyis a központi tár igen fontos er forrás, melyért több folyamat verseng, és szervezése, kezelése az operációs rendszerek tervezését, megvalósítását és teljesítményét befolyásoló egyik legfontosabb tényez .

I. Multiprogramozott operációs rendszerek

37

I.4.1. A f tár megosztása a folyamatok között

A korábban tárgyalt tárhierarchia és általános társzervezési elvek folytatásaként ebben a fejezetben a ,,klasszikus" tárkezelés két legfontosabb kérdését, a program címeinek kötését és a tárallokációt fogjuk részleteiben megvizsgálni.

I.4.1.1. A program címeinek kötése

A CPU közvetlenül csak a központi tárhoz tud hozzáférni, így a folyamatok aktuálisan végrehajtandó utasításának és az operandusoknak az operatív tárban kell elhelyezkedniük. Ez azt jelenti, hogy a programokat, adatokat végrehajtás el tt a másodlagos (háttér) tárakból be kell tölteni a központi (fizikai) memória valamilyen címére.

Egy programhoz általában lineáris, folytonos címtartományt szoktunk képzelni, amely 0-tól kezd d en (a program eleje) a program maximális címéig terjed. Ezt hívjuk logikai
címtartománynak (logical address space). A mai rendszerekben a programok végrehajtása

gyakorlatilag soha nem a 0. címt l kezdve, azaz a logikaival egyez

fizikai

címtartományban (physical address space) történik. Egy program a megírása (ahol

értelemszer en a logikai címtartományban vagy szimbolikus elnevezésekben gondolkodunk) és a végrehajtása (itt viszont a konkrét fizikai szó vagy byte címekre van szükség) között különböz fázisokon mehet keresztül (fordítás, kapcsolatszerkesztés, betöltés, stb.). Az egyes lépések alatt a címek különböz módon lehetnek reprezentálva.

Egy-egy program lefordításakor, szerkesztésekor a fordító és a kapcsolatszerkeszt program els menetben általában a logikai címtartományban ad értékeket a szimbolikus

hivatkozásoknak. Ugyanakkor a végrehajtáshoz már a fizikai címekre van szükség. A logikai
és fizikai címtartomány közötti megfeleltetés, leképezés (mapping) elvileg bármelyik lépés

alatt elvégezhet , de valamikor biztosan meg kell tenni. Nézzük meg tehát, hogy mikor (a program el készítésének melyik fázisában) milyen lehet ségeink vannak a leképezés elvégzésére (4.4.x. ábra):

I. Multiprogramozott operációs rendszerek

38

4.4.x. ábra Logikai-fizikai címtranszformáció a felhasználói programok többlépcs s

feldolgozása során

(1) Statikus logikai-fizikai címleképezés

A címkonverzió történhet fordítás közben (compile time). Ha ismeretesek a program fizikai címei, akkor a leképezés elvégezhet a fordítás alatt. Ha a kés bbiek során a program (fizikai) kezd címe megváltozik, akkor azt újra le kell fordítani. Éppen ezért, ezt a megoldást merevsége miatt - csak speciális esetekben, a ROM (Read Only Memory, csak olvasható tár) memóriába kerül programok esetén használják, egyébként pedig nem a végleges fizikai cím, hanem logikai cím rendel dik a tárgykódban a hivatkozásokhoz.

A végleges fizikai címek kötésére a következ lehet ség szerkesztés közben adódik (link
time). Szerkesztésre akkor van szükség, ha egy program több, egymástól függetlenül

lefordított modulból áll, amelyek hivatkoznak más modulban definiált logikai címre. A kapcsolatszerkeszt (linker) program feladata a modulok közötti kereszthivatkozások

feloldása, és a modulok egymás mögé helyezése. Ennek eredményeképpen a tárgykódban a logikai címek helyére fizikai címek helyettesít dhetnek, azonban az esetek többségében csak a modulok logikai címtartományainak egyesítése történik meg, és egy áthelyezhet kódot
(relocatable code) kapunk eredményül.

Ha a végleges címkonverzió betöltés közben (load time) történik, akkor a korábban kapott áthelyezhet kód címhivatkozásait módosítja a betölt program (loader) az aktuális

címkiosztás szerint.

Az eddig felsorolt megoldások un. statikus leképezést valósítanak meg, azaz a fizikai címek hozzárendelése a program élete során egyszer, végrehajtásuk el tt következik be, és az értékek többé nem változnak.

(2) Dinamikus logikai-fizikai címleképezés

I. Multiprogramozott operációs rendszerek

39

A tárgazdálkodás szempontjából igen el nyös lehet, ha a program módosítás nélkül futtatható tetsz leges szabad tárterületre töltve, és helye akár végrehajtás közben is megváltoztatható. Ilyenkor dinamikus címleképezésr l és dinamikus áthelyezhet ségr l beszélünk. Dinamikus címleképezésnél a program memóriaképe logikai címeket tartalmaz, és a konkrét fizikai címhozzárendelés csak az utasítás-végrehajtás során következik be (speciális hardver elemek segítségével).

A legegyszer bb dinamikus címleképezést a bázisrelatív címzés valósítja meg. Ha a program valamennyi címhivatkozása bázisrelatív címzési módú, a program tetsz leges helyre betölthet , a bázisregisztert a betöltési kezd címre állítva a program végrehajtható (4.4.y. a, ábra). Ekkor annak sincs akadálya, hogy a program végrehajtásának megszakadása után a teljes programot egy új kezd címre töltsük vissza, vagy másoljuk át, és így folytatódjék a végrehajtás.

A bázisrelatív címzéshez igen hasonló (akár annak alesetének is tekinthet ) dinamikus címleképezési mód az utasításszámláló-relatív címzés, melynek eredményeképpen pozíciófüggetlen kódot (position independent code, PIC) kapunk, amelyet ugyancsak

végrehajthatunk tetsz leges címre töltve (4.4.y. b, ábra).

4.4.y. ábra Dinamikus címleképezési módok a, bázisrelatív címzés (a - a program fizikai

kezd címe, b - virtuális (logikai) cím, r - fizikai cím), b, utasításszámláló relatív címzés

(3) Késleltetett betöltés

Jobb tárkihasználás érhet el késleltetett betöltés alkalmazásával, vagyis, ha a programok indításakor nem a teljes programot, hanem csak egyes részeit töltjük a tárba, míg más részek futás közben, szükség esetén tölt dnek be. Az ide sorolható módszerek az esetek többségében dinamikus címleképezést igényelnek.

Dinamikus betöltésnek (dynamic loading) hívjuk azt a módszert, ha a programhoz tartozó

egyes eljárások - áthelyezhet formában - a háttértáron vannak, és csak a meghívásukkor tölt dnek be. Ilyenkor a futás elindításakor csak a f program kerül a memóriába, majd egy-

I. Multiprogramozott operációs rendszerek

40

egy eljárás meghívásakor el ször azt kell ellen rizni, hogy a meghívott eljárás a memóriában van-e. Ha nem, akkor egy speciális programrész betölti a kívánt rutint, majd átadja a vezérlést az eljárásnak (4.4.z. a, ábra).

A módszer el nye, hogy a programok összméretüknél általában lényegesen kisebb tárterületet igényelnek, a ténylegesen meg nem hívott eljárások soha nem tölt dnek be. (A program részei között sokszor találunk olyan eljárásokat - például hibakezel rutinokat - melyekre csak ritkán van szükség, így felesleges azokat minden esetben betölteni a memóriába.)

A dinamikus betöltést a programozónak magának kell megszerveznie, a megvalósításhoz az operációs rendszer nem, legfeljebb a nyelvekhez tartozó fordító, szerkeszt programok adnak támogatást. és futtató

A késleltetett betöltés következ , az el bbi módszer módosított - az operációs rendszer által is támogatott - változata a dinamikus könyvtárbetöltés vagy dinamikus kapcsolatszerkesztés
(dynamic linking). A programban használt rendszerkönyvtárak eljárásai helyett a szerkeszt
Megjegyzés: Hol van itt az operációs rendszer által nyújtott támogatás?

csak egy csonkot (stub) tesz be a programba, mely valamilyen hivatkozást tartalmaz egy könyvtárra és ezen belül az adott eljárásra. A csonk els meghívásakor a rendszer a kívánt eljárást betölti a tárba, majd az eljárás fizikai kezd címét a hívó eljárásban szerepl logikai címhez rendeli. Az ezután következ hívások már a betöltött eljárást fogják - id veszteség nélkül - meghívni (4.4.z. b, ábra). (A könyvtárakat természetesen pozíciófüggetlenül kell kódolni.)

A módszer el nye a csökkentett tárfelhasználáson kívül az is, hogy a könyvtárak módosítása (hibajavítás, újabb, javított változatra cserélés) esetén nem szükséges az összes, a módosított könyvtárat használó programot újrafordítani. Az azonban el fordulhat módosított könyvtárak esetén, hogy a memóriába ugyanannak az eljárásnak különböz verziói (egymástól eltér példányai) tölt dnek be, attól függ en, hogy a futó folyamatok módosítás el tt vagy után hívták meg az eljárást. M ködési problémát okozhat, ha a változtatások a korábbival
inkompatibilis új verziót eredményeznek.

I. Multiprogramozott operációs rendszerek

41

A dinamikus kapcsolatszerkesztést alkalmazó korszer rendszerek annyiban különböznek a fenti sémától, hogy a betöltött eljárások más folyamatok számára is rendelkezésre állnak, azaz a csonk els meghívásakor a rendszer figyelembe veszi azt is, ha más folyamat már meghívta az eljárást, és így a kívánt eljárás már a tárba tölt dött. Ilyenkor ez a fizikai cím rendel dik a hívó eljárás logikai címéhez. A megoldás felveti az újrahívhatóság problémáját (amikor több folyamat egyid ben is végrehajthatja ugyanazt az eljárást), melyr l a fejezetben kés bb részletesebben is szó lesz.

A központi tár fizikai méreténél nagyobb méret programok írását és futtatását teszi lehet vé az átfed
program részek (overlay) technikája. A módszer kifejlesztésénél abból a

felismerésb l indultak ki, hogy a programoknak csak egy részét teszik ki azok a programrészek, illetve adatok, amelyekre a teljes futási id alatt szükség van, így elegend ezeket állandóan a memóriában tartani. A programok fennmaradó része pedig ,,szétvágható" olyan részekre, amelyek id ben elkülönülten - azaz egyid ben csak az egyik - dolgoznak. Ezeket szükség esetén egyesével töltjük be, majd használatuk után újra a háttértárba menthetjük (ezt sok rendszer nem teszi meg), hogy a felszabaduló területre egy másik overlay részt tölthessünk (4.4.z. c, ábra). (A módszer tehát tulajdonképpen annyiban különbözik a dinamikus betöltést l, hogy itt a betöltött részek nem maradnak bent a memóriában állandó jelleggel a további futás idejére.)

Az átfedés számára fenntartott tárterület a legnagyobb programrészlet hosszával egyezik meg. Az overlay technika szempontjából az átfed programrészek a háttértáron tartalmazhatnak abszolút címeket is (így a módszer nem igényel feltétlenül dinamikus címleképezést), hiszen ugyanarra az ismert kezd címre tölt dnek be.

A dinamikus betöltéshez hasonlóan ez a módszer sem igényel különleges támogatást az operációs rendszert l. Egyszer fájlrendszer alkalmazásával megoldható az átfed

programrészek memóriába olvasása, illetve háttértárra írása, azonban az overlay részek tervezése a program szerkezetének és futás közbeni viselkedésének alapos ismeretét igénylik a programozótól, ezért manapság ritkán használják, csak ott, ahol a fizikai memória mérete ezt szükségessé teszi, és más, korszer bb automatikus módszerek (pl. virtuális tárkezelés) nem valósíthatók meg.

I. Multiprogramozott operációs rendszerek

42

4.4.z. ábra Késleltetett betöltési módok a, dinamikus betöltés b, dinamikus könyvtárbetöltés

c, átfed programrészek.

I.4.1.2. Társzervezési módszerek

A számítógépek történetének korai id szakában a memória viszonylag drága er forrásnak számított. Ezért a rendszertervez k komoly er feszítéseket tettek a központi tár használatának optimalizálására. A mai tárak ára egyre alacsonyabb, ezért, a ,,gazdaságos" tárkihasználás némileg mást jelent, mint korábban. (A ,,gazdaságosság" mögött húzódó költségfüggvényben a hangsúlyok eltolódtak a mai élet kihívásai által diktált követelmények - pl. felhasználói kényelem, nagy komplexitású, beágyazott rendszerek összetett feladatai, valósidej m ködés - felé.)

Társzervezés alatt azt a módot értjük, ahogyan a központi tárat a felhasználók (folyamatok) között megosztjuk. Az ,,optimális" tárhasználatra való törekvés során felmerült kérdések közül az els megválaszolandó mindjárt az volt, hogy egyszerre csak egyetlen, vagy több felhasználó is használhassa-e a f memóriát. Kés bb az vet dött fel, hogy ha egy id ben párhuzamosan több felhasználó között osztjuk meg a memóriát, akkor vajon mindegyikhez ugyanakkora területet rendeljünk-e, vagy különböz méret részekre, partíciókra (partition) osszuk azt. És ezeknek a partícióknak a hossza állandó vagy pedig változó legyen-e? Eldöntend az is, hogy a programok a (felhasználói) memórián belül bárhol, vagy csak

bizonyos részeken futhatnak-e, továbbá, hogy a folyamatokhoz rendelt fizikai memória területnek egybefügg nek kell-e lennie, vagy össze nem függ részekb l is állhat.

A fenti kérdésekkel is érzékeltethet , egyre táguló lehet ségek a történeti fejl dés során nyíltak meg. Mindegyik változatra találhatunk m köd rendszert, ezért a fejezet további részében azt fogjuk áttekinteni, hogy ezek milyen sajátságosságokkal rendelkeznek, és hogyan is lehet megvalósítani ket.

(1) Egy partíciós rendszer

I. Multiprogramozott operációs rendszerek

43

Az egy partíciós rendszereknél egyid ben egyszerre egyetlen folyamat használhatja a központi tárat, így az operációs rendszeren - és a speciális tárterületeken, mint például a megszakítás vektorok, a periféria címtartományok - felüli folytonos címtartományon teljes egészében ez a folyamat futhat.

A betölt a program indításakor azt az els szabad címre hozza be. Ha a program futása során az operációs rendszernek több tárra van szüksége, akkor azt vagy a program által nem használt területr l - a tár másik végér l - ,,lopja" el, vagy a programot kell áthelyezni, ami hardver támogatás nélkül nehézkes.

Az operációs rendszer védelmére elegend egyetlen regiszter, amely a program legkisebb címét tartalmazza. A folyamat futása közben - felhasználói módban - a tárkezel hardver minden egyes kiadott memória címet összehasonlít a határregiszter értékével, és ellen rzi, hogy minden hivatkozás a tárolt cím felett legyen. Rendszerhíváskor a processzor olyan m ködési módba kerül át (rendszer, vagy kernel mód), ahol ez a védelem kikapcsol, és az operációs rendszer a teljes tárat eléri. A határregiszter értéke csak rendszermódban változtatható meg.

A folyamatok váltása a központi tár és a háttértár közötti a kés bbiekben részletezett tárcsere (swapping) segítségével történhet.

4.4.v. ábra Egy partíciós memória szervezés

(2) Több partíciós rendszer

Bár swapping segítségével egy partíciós rendszerekben is megvalósítható valamiféle multiprogramozás, azonban ez a mágneslemezes átvitel nagy id igénye miatt jelent sen megnöveli a környezetváltási id t, így legfeljebb a lemeznél még sokkal lassabb perifériális m veletek esetén, vagy a felhasználói esélyegyenl ség biztosítása érdekében volt érdemes átkapcsolni más folyamat végrehajtására. A hatékony multiprogramozás megkövetelte, hogy egy id ben egyszerre több folyamat is a tárban tartózkodjék.

I. Multiprogramozott operációs rendszerek

44

Multiprogramozás rögzített partíciókkal

A korai rendszerekben a felhasználói tárterületet olyan különböz

méret

partíciókra

osztották, melyek mérete a rendszer m ködése során nem változhatott (rögzített partíciók,
fixed partition). A programok a méretüknek megfelel

partícióban futtathatók. Minden

partícióban egyetlen folyamat tartózkodhat. Így a multiprogramozás fokát alapvet en a partíciók száma korlátozza.

Egy-egy folyamat befejez dése után az operációs rendszer egy következ folyamatot választ ki futásra a szabad partícióhoz, vagy az egyetlen közös várakozási sorból (ilyenkor nyilván figyelembe kell venni, hogy a programok csak a maximális memória igényüknek megfelel méret partícióban futtathatók), vagy pedig a már eleve ehhez a partícióhoz kötött várakozási sorból (ilyenkor a hosszútávú ütemez a belép folyamatokat közvetlenül a különböz
Megjegyzés: Fel kéne bontani

partíciókhoz tartozó várakozási sorokba sorolja) valamilyen - általában a legjobb illeszkedést keres - stratégia szerint (4.4.w. ábra).

4.4.w. ábra Többpartíciós memória szervezés

Ez a tárkezelési mód nagyon egyszer , ugyanakkor nagyon merev, így végeredményben rossz tárkihasználást biztosít. A folyamatok nem használják ki teljesen a partícióban rendelkezésükre álló tárterületet, minden partícióban a benne futó folyamathoz rendelt, ám kihasználatlan memóriaterület, ,,lyuk" marad. Ezt hívjuk bels
fragmentation). tördel désnek (internal

(3) Multiprogramozás változó méret partíciókkal

Fejlettebb operációs rendszerekben a folyamatok - igényeiknek megfelel - változó méret
partíciót (variable partition) kapnak. Így a partíciókon belül nincs kihasználatlan memória

terület.

I. Multiprogramozott operációs rendszerek

45

A belép folyamatok számára az ütemez egy kell en nagy, folyamatos, szabad memória területet keres, melyet két részre oszt. A szükséges nagyságú területet a folyamathoz rendeli, a maradék pedig továbbra is szabad marad. Ezzel sikerül kivédeni a bels tördel dést.

Változó méret partíciók használata esetén a problémák akkor kezd dnek, amikor folyamatok befejezik a futásukat és az operációs rendszer felszabadítja az általuk foglalt területet. Így lyukak keletkeznek az allokált memória részek között. Ezek ugyan hozzárendelhet k más folyamatokhoz, azonban szinte biztos, hogy el bb-utóbb a folyamatokhoz rendelt tárterületek között akkora szabad területek maradnak, melyek egyenként túl kicsik a folyamatok számára, és így kihasználatlanok maradnak. Ezt a jelenséget hívjuk küls tördel désnek (external
fregmentation).

A küls

tördel dés, ha meghalad egy bizonyos mértéket, jelent sen késleltetheti újabb

folyamat elindítását, mindamellett, hogy összességében elegend szabad terület lenne ehhez. Azonban ezek a területek nem alkotnak folytonos címtartományt. Ezen segíthet a szabad
helyek tömörítése (compaction, garbage collection), azaz a tár egyik végére rendezése.

Ilyenkor az operációs rendszer úgy helyezi át a partíciókat, hogy azok érintkezzenek egymással, és így összefügg szabad területet kapjunk.

A módszer ugyan megoldja a problémát, azonban nagyon id igényes, hardver támogatást (dinamikus áthelyezhet séget) igényel, megzavarhatja a rendszer m ködését (például egy interaktív rendszer válaszideje váratlanul jelent sen megnövekedhet), és a tárterületek mozgatásához az áthelyezési információkat meg kell rizni.

Mindezek miatt nem egyértelm , hogy érdemes-e alkalmazni. Összességében jobban járhatunk, ha ehelyett inkább várakozunk, amíg más futó folyamatok is befejez dnek, vagy pedig a tárterület lefoglalása során próbáljuk optimalizálni a kihasználást.

A küls

tördel dés csökkentésére különböz

stratégiákat dolgoztak ki a folyamatokhoz

rendelend tárterület kiválasztására. Az operációs rendszer a betöltend program számára a szabad területek közül az alábbiak szerint választhat.

I. Multiprogramozott operációs rendszerek

46

Az els megfelel (first fit) algoritmus a tár elejér l indulva az els elegend en nagy területet foglalja le a folyamat számára. Az algoritmus igen gyors, eredményeképpen a memória mintegy 30%-a marad kihasználatlan. (Ezt hivják 50%-os szabálynak, mivel a folyamatok által lefoglalt területek összegének mintegy fele marad kihasználatlan.)

Az következ

megfelel

(next fit) algoritmus annyiban különbözik az el z t l, hogy a

keresést nem a tár elején, hanem az utoljára lefoglalt tartomány végét l kezdi. Hatásfoka hasonló az el z éhez.

A legjobban megfelel (best fit) algoritmus a legkisebb, még elegend méret területet foglalja le. A mögöttes filozófia szerint, minél kisebbek a megmaradó lyukak, összességében annál kevesebb lesz a kihasználatlan memória terület. A módszer az el z eknél lassabb, és bár els pillanatra hihetetlennek t nik, de némileg rosszabb memória kihasználást eredményez az el z eknél.

A legrosszabban illeszked (worst fit) algoritmus az el z vel épp ellentétben, a legnagyobb szabad területb l foglal, mert abban bízik, hogy a megmaradó ,,nagy" lyuk elegend en nagy lesz egy további folyamat számára. Szimulációs vizsgálatok alapján azt mondhatjuk, hogy ez a legrosszabb hatásfokú algoritmus (a memória terület kb. 50%-a marad kihasználatlan).

Az statisztikai vizsgálatok eredményeképpen tehát megállapíthatjuk, hogy hatásfokát tekintve az els három algoritmus nagyjából azonos kihasználtságot eredményez. Figyelembe véve, hogy az els megfelel algoritmus megvalósítása a legegyszer bb és ez m ködik a

leggyorsabban, mindenképpen ez t nik a legjobbnak.

A több partíciós rendszerek megjelenésével nem csak az operációs rendszert, hanem más folyamatok tárterületét is védeni kell a hibás (vagy rosszindulatú) folyamatok m ködésének következményeit l. Ezért a védelem két határregisztert használ, amelyekbe a folyamat futásakor, a hozzá tartozó címtartomány határait tölthetjük. Az egyes címzéseknél a hardver a tartományból való kicímzést figyeli.

(4) Tárcsere

I. Multiprogramozott operációs rendszerek

47

A folyamatoknak a háttértárról a memóriába való bevitelét, illetve a memóriából a háttértárra való kivitelét a tárcsere (swapping) technika segítségével oldhatjuk meg. Ennek során az operációs rendszer egy-egy folyamat teljes tárterületét a háttértárra másolja, így szabadítva fel a területet más folyamatok számára. Ehhez természetesen az operációs rendszernek pontosan ismernie kell a folyamatok aktuális tárigényét.

A tárcsere a perifériás átvitel miatt id igényes - egyszerre nagy tárterületet kell mozgatni -, így jóval hosszabb id t vesz igénybe, mint egy szokásos környezetváltás. A tárcserével töltött id jelent sen megnövelheti a futás idejét, ezért mindenképpen célszer a tárcsere idejét viszonylag alacsonyan tartani az effektív futási id khöz képest (például egy Round-Robin ütemezést alkalmazó rendszer tervezésekor az id szelet hosszának megválasztásánál figyelembe kell venni a swapping idejét és arányát), valamint lehet ség szerint minimalizálni kell a tárcserék számát és optimalizálni magát a m veletet.

Az ütemez nek célszer

a tárban lev

futásra kész folyamatok közül - ha van ilyen -

választani. A tárterület elmentésénél pedig figyelhetünk arra is, hogy egy változatlan, a háttértáron meglev tartományt nem kell újra kiírni. További gyorsítást tesz lehet vé az
átlapolt tárcsere (overlapped swapping), vagyis amikor az éppen futó folyamat

végrehajtásával párhuzamosan történik egy másik folyamat kivitele, illetve egy harmadik behozatala (lásd 4.4.k. ábra).

4.4.k. ábra Átlapolt tárcsere

Tárcserét korszer

rendszerek a várhatóan hosszabb ideig várakozni kényszerül

folyamatoknál, vagy a rendszer túlterheltségét (pl. feladatok, azonos igények torlódása) megel zend alkalmaznak. Tárcserére lehet szükség új folyamat létrehozása (fork) esetén (ha nincs elég hely a szül és a gyerek számára), ha egy folyamat tárigénye - például a verem mérete - megn , illetve ha egy másik - nagyobb prioritású - folyamatnak van szüksége a memória területre.

I. Multiprogramozott operációs rendszerek

48

Ha szükség van további memória területre, akkor el kell dönteni, melyik folyamat legyen az áldozat. Ehhez figyelembe vehetjük a folyamatok állapotát, prioritását, futási, illetve várakozási idejét stb. Behozatalnál pedig azt kell megválaszolni, hogy a háttértáron lev k közül mikor és kit hozzunk be, szintén a fenti szempontok esetleges figyelembevételével. Mindkét esetben figyelnünk kell azonban arra, hogy a folyamatokat feleslegesen ne pakolgassuk, valamint, hogy a választási algoritmus ne vezessen éhezésre.

Statikus logikai-fizikai címleképezésnél egy további megkötést jelent, hogy a háttértárra kivitt folyamatokat ugyanarra a memória területre kell behozni, amelyet korábban elfoglaltak. Dinamikus - futás közbeni - címtranszformáció alkalmazása esetén a folyamatok minden további nélkül betölthet k az el z t l eltér memória területre.

Az eddigi társzervezési megoldásoknál abból a feltételezésb l indultunk ki, hogy a folyamatok fizikailag is folytonos memória területet használnak. A korszer tárkezel

hardverek azonban lehet vé teszik, hogy a folyamatok folytonos logikai címtartományának nemfolytonos fizikai címtartományt feleltessünk meg (ezt
hívjuk mesterséges

folytonosságnak (artificial continuity)). Ezzel megszüntethet

a küls , és jelent sen

csökkenthet a bels tördel dés.

A tárcserék ideje er sen függ az átvitt információ mennyiségét l, azaz az átvitt memória terület nagyságától. Ezért a tárcsere id lecsökkentésének kézenfekv módjaként kinálkozik, hogy ne a teljes folyamatokat, hanem csak egy részüket kelljen mozgatni a memória és a háttértár között. Ehhez az igazi segítséget azok a speciális hardver elemek jelentették, amelyek lehet vé tették, hogy a futó folyamatnak ne a teljes címtartománya, hanem annak csak egy része tartózkodjék a központi tárban. Ilyenkor el fordulhatnak olyan hivatkozások, amelyekhez nem tartozik érvényes fizikai cím, mivel a hivatkozott cím nincs a memóriában. Megfelel hardver-szoftver összjáték esetén azonban a rendszer képes arra, hogy a

felhasználó számára észrevétlenül a szükséges programrészletet a háttértárból a központi tárba töltse, és a korábbi hivatkozást - ezúttal már sikeresen - végrehajtsa.

Az alábbiakban következ korszer társzervezési módszerek közös jellemz je, hogy egyrészt mesterségesen folytonos címtartományt használnak (azaz a fizikai címtartomány általában

I. Multiprogramozott operációs rendszerek

49

több, egymástól elkülönült memória blokkból áll), másrészt lehet séget adnak arra, hogy a folyamatok tárterületének csak egy része tartózkodjék egyid ben a memóriában. A szabad tárterületek rugalmas felhasználhatósága érdekében ezek a módszerek futás közbeni címleképezést alkalmaznak.

A leképezéshez szükséges többlet információk mennyiségének elviselhet

szinten tartása

céljából a gyakorlati címtranszformációk tartományonként meg rzik a megfeleltetés folytonosságát. Egy-egy összefügg logikai címtartományt (blokk) egy-egy önmagában

összefügg , de tetsz leges fizikai címtartományra képeznek le.

A megfelel sebességet hardver támogatás biztosítja. Minden egyes folyamathoz tartozik egy un. blokktábla (block map table), amely a logikai cím-fizikai cím összerendeléseket tartalmazza (a folyamatonkénti külön blokktáblára azért van szükség, mert a folyamatok logikai címtartománya fedi egymást, de fizikai címtartományuk el kell különüljön). A logikai címek , azaz formában adottak. A blokktábla minden egyes blokkhoz megadja a blokk fizikai kezd címét. A hardverrel támogatott címleképezés mindig egy meghatározott módon elérhet (aktuális) blokktábla

használatával történik. A futó folyamathoz tartozó blokktáblát az operációs rendszer teszi aktuálissá környezetváltáskor. Szokásos megoldás, hogy a címképz egység egy mutatón (pointer) keresztül éri el a blokktáblát, mert ilyenkor az aktuálissá tétel igen gyors lehet, hiszen csak a mutató átállítását igényli..

(5) Szegmensszervezés

A

programozók

a

programjaikat

nem

egyetlen

összefügg ,

folyamatos

logikai

címtartománynak látják, hanem sokkal inkább úgy, mint több, különböz

funkcionális

részegység együttesét, amelyek egy-egy részfeladatot oldanak meg (például a f program, egyegy eljárás, a verem, stb.). A részegységek fizikai elhelyezkedése pedig közömbös a felhasználó számára.

A szegmensszervezés (segmentation) ezt a látásmódot tükrözi, a címtranszformációnál a logikai szegmenseket (segment) felelteti meg egy-egy blokknak. Az értelemszer en

I. Multiprogramozott operációs rendszerek

50

különböz hosszúságú blokkok önmagukban folytonos fizikai címtartományt foglalnak el, a

címképzés a blokktáblás sémát követi (4.4.l. ábra). Bels tördel dés nem lép fel.

4.4.l. ábra Címtranszformáció szegmensszervezés esetén

A blokktáblában a szegmensek hosszát is tárolni kell. Ezzel biztosítható, hogy a folyamat ne címezhessen ki a szegmensb l. A címképz hardver a szegmens területén kívülre mutató
túlcímzést figyeli, és ha ilyen el fordul, hibamegszakítást generál (segment overflow fault).

Ahhoz, hogy a szegmentált címzési mód segítse a szegmensenkénti tárcserét is, a blokktábla egy bitje (residency bit) azt mutatja, hogy a szegmens a memóriában van-e vagy sem. Ha olyan szegmensre történik hivatkozás, amelyik nincs a tárban, ennek a bitnek az állása alapján a címképz hardver hibamegszakítást generál (missing segment fault). Természetesen a

tárcserék lebonyolításához tárolni kell azt az információt is, hogy a háttértáron hol található meg a szegmens.

A szegmensszervezés lehet séget ad arra, hogy több folyamat egy-egy logikai szegmense ugyanarra a fizikai címtartományra legyen leképezve, vagyis, hogy a folyamatok közös eljárásai egyetlen példányban tárolódjanak a memóriában (osztott szegmenshasználat,
segment sharing).

Szegmensszervezés esetén könnyen megvalósítható a hozzáférések szabályozása (access
control). A folyamatoknak az egyes szegmensekhez különböz

hozzáférési módokat

engedélyezhetünk. Ezzel a folyamat tárterületét védhetjük saját m ködésének hibáitól, illetve osztott szegmenshasználat esetén a különböz folyamatoknak különböz hozzáférési

jogosultságokat adhatunk. Szokásos hozzáférési jogok az olvasási jog (read access, ilyenkor a folyamat a szegmens területét olvashatja), írási jog (write access, a folyamat a szegmens területére írhat, az ott lev értékeket módosíthatja) és a végrehajtási jog (execute access, a szegmensben gépi utasítások vannak, amelyeket a folyamat végrehajthat). A módosítható adatterületek helyes osztott használatához a kölcsönös kizárást a folyamatoknak kell biztosítania, ehhez a hardver nem nyújt támogatást.

I. Multiprogramozott operációs rendszerek

51

(6) Lapszervezés

A szegmensszervezésnél használt változó méret

blokkok megoldást jelentenek a bels tördel dés jelensége. Ez utóbbi
fizikai memória

tördel désre, azonban óhatatlanul fellép a küls megszüntetéséhez azonos, rögzített méret

blokkok és nekik megfelel

keretek (frame) használata szükséges (vagyis, hogy a folyamatok tárterületét ilyen

egységekben allokáljuk). Az azonos méret blokkokra a lap (page), az ennek megfelel társzervezésre pedig a lapszervezés (paging) elnevezést használjuk. A küls tördel dés

megszüntetésének ára a bels tördel dés megjelenése. A folyamatok utolsó lapja átlagosan csak félig lesz tele, a tördel dési veszteség tehát átlagosan folyamatonként fél lap. A lapméretet az egyes rendszerekben egymásnak ellentmondó szempontok mérlegelése alapján választják meg. A lapméret csökkentésével csökken a bels tördel désb l származó

tárveszteség. Ugyanakkor n a laptábla mérete, és az adategységre vonatkoztatott átlagos keresési (címzési, lappangási) id növekedése miatt csökken a memória és a háttértér közötti adatátvitel sebessége (ugyanolyan adatmennyiséget több blokkban kell átvinni).

A lap mérete gyakorlati szempontok miatt mindig 2 hatványa (általában 512 és 16 K byte között), ugyanis ez esetben a címtranszformáció második részében (a blokkon belüli eltolás figyelembevételénél) nem szükséges összeadást végezni, hanem elegend az eltolást

egyszer en a fizikai címben a kisebb helyiérték bitek helyére másolni (4.4.m. ábra).

4.4.m. ábra Címtranszformáció lapszervezés esetén

Közvetlen leképezés esetén a folyamathoz tartozó minden lap fizikai címe egy laptáblában

van, és a transzformáció mindig innen veszi el a fizikai lapcímet. Mivel a lapok mérete viszonylag kicsi a programok méretéhez képest, ezért a laptábla mérete meglehet sen nagy lehet, és így nehéz speciális, elkülönített, gyors hozzáférés tárban tartani. Ha pedig a laptábla a memóriában helyezkedik el, akkor minden egyes laptábla hozzáférést igényl címtranszformációt magában foglaló memóriam velet két memória hozzáférést igényel, ami jelent s lassulást okoz.

I. Multiprogramozott operációs rendszerek

52

A laptábla méretének csökkentésére a megoldást a többszint laptábla alkalmazása kínálja. A modern rendszerek korábban elképzelhetetlen nagyságú logikai címtartomány használatát teszik lehet vé, amely azonban egyben hatalmas méret laptáblák használatát is jelenti.
12

Gondoljuk csak meg, hogy egy 32 bites logikai cím 4K (2 ) byte méret lapok használata esetén 1 millió (220) laptábla bejegyzést jelenthet. Ez - bejegyzésenként 4 byte-tal számolva önmagában 4Mbyte fizikai memóriát igényel. Ekkora méret táblák memóriában tartása, kiés bevitele semmiképpen sem célszer . Ugyanakkor már utaltunk rá, hogy a folyamatok egy adott id intervallumban a teljes címtartományuknak nagy valószín séggel csak egy-egy részét használják. Így, ha a laptáblát megfelel en osztjuk részekre, elegend néhány részlaptáblát a memóriában tartani.

A gyakorlatban - az effektív hozzáférési id

növekedése miatt ­ legfeljebb két, illetve

háromszint laptáblát szoktak használni. Kétszint laptábla-szervezés esetén a címképzést a 4.4. n. ábra mutatja.

4.4.n. ábra Címtranszformáció lapszervezés esetén kétszint laptábla használatával

A hozzáférési id problémájára a tipikus megoldást az asszociatív leképezés, azaz egy speciális szervezés , gyors asszociatív tár (associative registers, translation look-aside
buffer) alkalmazása jelenti, ahol a folyamat bizonyos - gyakran vagy a közeljöv ben

várhatóan használt - lapjainak logikai és fizikai címei találhatók. Az asszociatív tár gyors hozzáférés és egyetlen m velettel kiadja a bemenetére juttatott logikai címhez tartozó fizikai címet, tehát lényegében a laptábla gyorsító tárjaként funkcionál.

A sebességben megfelel

asszociatív tárak általában nem elegend en nagyok akár csak

egyetlen folyamat teljes laptáblájának befogadására sem, így az asszociatív leképezés megvalósítására kombinált technikák alakultak ki. A fizikai lapcím keresése a logikai lapcím alapján egyidej leg kezd dik mind az asszociatív tárban, mind pedig a direkt laptáblában (ami ilyenkor általában memóriában tárolt). Ha a keresett cím megvan az asszociatív tárban, ez igen gyorsan - gyakorlatilag még a direkt táblához forduló memóriam velet megkezdése el tt - kiderül, és a direkt táblához fordulás leáll. Mivel az asszociatív tár csak a laptábla töredékét képes tárolni, tartalmát valamilyen stratégiával

I. Multiprogramozott operációs rendszerek

53

folyamatosan frissíteni kell, hogy a várható hivatkozások minél nagyobb valószín séggel megtalálhatók legyenek benne. Kés bb még részletesen elemezzük azt a megfigyelést, hogy azonos lapra általában több egymást követ hivatkozás történik rövid id n belül. Ezért, ha a hivatkozott lapcím nem található az asszociatív tárban, a direkt leképezés eredményeként kapott logikai-fizikai címpárt érdemes felvenni az asszociatív tárba valamelyik régen használt bejegyzés helyére. Környezetváltáskor az asszociatív tár tartalmát is cserélni kell, hiszen ugyanazon logikai címekhez most új fizikai címek fognak tartozni.

Mivel a programok futásuk egyes id szakaiban a teljes címtartományuknak csak kis részét használják, ezért az asszociatív tárak - kis méretük ellenére - általában 80-99% közötti találati
arányt (hit ratio) tesznek lehet vé (találati aránynak nevezzük az asszociatív tárban

megtalált hivatkozott lapok arányát).

Egyszer ség kedvéért tegyük fel, hogy a memória hozzáférés ideje 100 nsec, az asszociatív tárban való keresés pedig 20 nsec-t igényel. Asszociatív tár használata nélkül a fizikai memória cím elérése 200 nsec-t igényel (100 nsec laptábla hozzáférés + 100 nsec memóriakeret elérés). Asszociatív tárral, 90 %-os találati arányt feltételezve, az effektív memória hozzáférési id kb. 128 nsec (0.9×(20 nsec asszociatív tár elérés + 100 nsec

memóriakeret elérés) + 0.1×(100 nsec laptábla hozzáférés + 100 nsec memóriakeret elérés)), az elvi 100 nsec helyett.

Az eddigi társzervezési módszerekkel ellentétben lapszervezés esetén az eltolás tekintetében nincs szükség túlcímzés elleni védelemre, hiszen minden kiadható cím lapon belül marad. Túlcímzés csak a lapcímben történhet, ami a laptábla méretének megfelel határregiszter segítségével ellen rizhet . A memória védelem az egyes fizikai memória keretekhez rendelt védelmi bitek segítségével történhet, amelyeket az elviselhet sebesség érdekében hardvernek kell ellen riznie. A számítógépek többsége azonban nem tartalmazza ezt a hardver támogatást.

A szegmensszervezéshez hasonlóan szükség van viszont egy olyan bitre (érvényességi, valid bit), amely azt mutatja, hogy a lap a memóriában van-e, és természetesen a háttértáron való elhelyezkedés információját is tárolni kell valahol.

I. Multiprogramozott operációs rendszerek

54

A szegmensszervezés rendszerekhez hasonlóan a lapszervezés rendszereknél is nagy el ny az osztott laphasználat lehet sége. Ilyenkor több folyamat hivatkozhat azonos fizikai lapokra, amelyeket az esetek nagy részében azonos logikai címen is látnak, de ez nem szükségszer . Képzeljük, mekkora tárigény csökkenést jelent az, hogy a több felhasználó által használt programok kódrészének, illetve a könyvtári eljárásoknak - szövegszerkeszt , fordító, ablakozó, adatbáziskezel stb. - csak egyetlen példányát kell a memóriában tartani. Ezek a lapok általában olyan eljárásokat tartalmaznak, amelyek kódja végrehajtás során sohasem változik, így több folyamat egyid ben is végrehajthatja ugyanazt az eljárást (újrahívható,
reentrant code). Természetesen minden folyamatnak külön regiszter- és adatkészlete kell,

hogy legyen a változók számára. A védelemmel kapcsolatban korábban mondottakkal ellentétben az ilyen közösen használt lapoknál az operációs rendszer gondoskodik a ,,csak olvasható" jelleg biztosításáról.

(7) Kombinált szegmens- és lapszervezés

A kombinált szervezés egyesíti mind a szegmens-, mind pedig a lapszervezés el nyeit. A logikai cím három komponensb l (szegmenscím, lapcím, eltolás) áll. A lapszervezésb l következ en nincs küls tördel dés. A szegmens szervezés miatt a feladat logikai szerkezete tükröz dik a társzerkezetben és egyszer bben megvalósítható az osztott használat. A bels tördel dési veszteség ezzel szemben szegmensenként jelentkezik.

A hozzáférési jogok ellen rzése és az osztott tárhasználat a szegmens szervezésnek megfelel en történik. A címtranszformáció lényegében els szinten egy laptábla-címeket

tartalmazó szegmenstábla, második szinten pedig szegmensenként egy-egy fizikai lapcímeket tartalmazó laptábla segítségével történik, az esetleges asszociatív tár pedig itt címhármasokat tárol, és szegmenscím, lapcím párossal kereshet .

I. Multiprogramozott operációs rendszerek

55

I.4.2. Virtuális tárkezelés

Az el z

fejezetben különböz

memória kezelési stratégiákat vizsgáltunk. Mindegyik célja, hogy lehet leg kell en sok folyamatot tudjunk a

módszernek az volt az alapvet

memóriában tartani egyszerre, és így megfelel szint multiprogramozást tudjunk biztosítani. Azonban a fenti technikák alapvet en megkövetelték, illetve törekedtek arra, hogy a programok végrehajtásuk el tt minél teljesebb terjedelmükben a memóriába kerüljenek. A késleltetett, illetve overlay betöltések, tárcserék, a felhasználók és a programfejlesztési segédeszközök szintjén tették lehet vé a tártakarékos futtatást, általános megoldást nem kínáltak.

Ezzel szemben a virtuális tárkezelés (virtual memory management) - a lap-, illetve szegmensszervezésre épül en - olyan szervezési elvek és az operációs rendszer olyan algoritmusainak összességét takarja, mely megengedi és biztosítja, hogy a rendszer
folyamataihoz tartozó logikai címtartományoknak csak egy - a folyamat futásához éppen szükséges - része legyen a központi tárban, de ennek ellenére bármelyik folyamat szabadon hivatkozhasson bármilyen, tartományában szerepl logikai címre.

I.4.2.1. A m ködés alapjai

A korábbi algoritmusok tárgyalása során láttuk, hogy nem kerülhet végrehajtandó utasítások a fizikai memóriában legyenek. Els

meg az, hogy a

megközelítésként a teljes

logikai címtartományt a fizikai memóriába olvasták. Az átfed programrészek alkalmazása és a dinamikus betöltés valamelyest lazított a fenti követelményen, azonban e technikák sok óvatosságot és er feszítést követeltek a programozótól. A virtuális tárkezelés ezzel szemben a programozó el l is rejtett megoldást kínál, amelyet az operációs rendszer nyújt, és amely teljes szabadságot biztosít akár a fizikai memória méretét sokszorosan meghaladó logikai (virtuális) címtartományok használatában.

I. Multiprogramozott operációs rendszerek

56

A virtuális tárkezelés el zményeit tekintve különböz

programok vizsgálata során

bebizonyosodott, hogy nem szükséges, hogy a programok teljes logikai memória területe a központi tárban legyen, mert a programok nem használják ki a teljes címtartományukat:
· tartalmaznak ritkán futó kódrészleteket (pl. a hibakezel rutinok) · a statikus adatszerkezetek általában túlméretezettek (pl. vektorok, tömbök, szimbólum

táblák definiálásánál a ténylegesen szükségesnél sokkal nagyobb területeket foglalhatunk le)
· a program különböz részei id ben egymástól elkülönülten m ködhetnek (ezt már az

overlay technika is kihasználta)
· a programok az összetartozó részek címtartományát is id ben egyenetlenül használják,

azaz az id ben egymáshoz közeli utasítások és adatok általában a térben is egymáshoz közel helyezkednek el (lokalitás).

A korábbi vizsgálatokból az is világossá vált, hogy nem is célszer , hogy a programok teljes logikai memória területe a központi tárban legyen, hiszen
· ekkor a futtatható programok méretét nem korlátozza a központi memória nagysága, azaz a

ténylegesen meglev tárterületnél nagyobb tárigény (hosszabb) programokat is futtathatunk
· az egyes folyamatok tárigényének csökkenésével a memóriában tartott folyamatok száma

növelhet , azaz növelhet a multiprogramozás foka, és ezzel javítható a CPU kihasználtság és átbocsátóképesség, anélkül, hogy a körülfordulási id , vagy a válaszid növekednék
· a programok betöltéséhez, illetve a folyamatok háttértárba mentéséhez kevesebb perifériás

m veletre van szükség, azaz a betöltés/kivitel gyorsabb lesz.

Jól látható tehát, hogy mind a rendszer, mind pedig a felhasználó szempontjából el nyös, ha a folyamatok tárterületének csak egy részét tartjuk egyidej leg a memóriában.

Amikor egy folyamat érvénytelen - azaz nem a valós memóriában lev - címre hivatkozik, a címképz hardver hibamegszakítást okoz, amelyet az operációs rendszer kezel, és behozza a háttértárról a szükséges blokkot. Ennek logikai lépései a következ k:
· Az operációs rendszer megszakítást kiszolgáló programrésze kapja meg a vezérlést, amely · elmenti a folyamat környezetét

I. Multiprogramozott operációs rendszerek

57

· elágazik a megfelel kiszolgáló rutinra · eldönti, hogy a megszakítást programhiba (pl. kicímzés) vagy logikailag érvényes,

de nem betöltött blokkra való hivatkozás okozta. Ez utóbbi esetben
· Az operációs rendszer behozza a kívánt blokkot a központi tárba: · a blokknak helyet keres a tárban; ha nincs szabad terület, fel kell szabadítania egy

megfelel méret címtartományt, ennek tartalmát esetleg a háttértárba mentve
· beolvassa kívánt blokkot · Az operációs rendszer átadja a vezérlést a folyamatnak, amely ismételten végrehajtja, vagy

folytatja a megszakított utasítást.

A blokk behozatala természetesen nem a folyamat aktív várakozása mellett történik. A perifériás m velet(ek) miatt a blokk behozatal sok id t vesz igénybe (meg kell várni, amíg a perifériás eszköz felszabadul, ki kell várni az átvitelt el készít m veleteket, valamint át kell vinni egy blokkot a periféria és a tár között), ezért a központi egység jobb kihasználása érdekében a blokkhiba miatt megszakított folyamatot az operációs rendszer várakozó állapotba helyezi, és más, futásra kész folyamatot indít el. Amikor a kívánt tartomány bekerül a tárba (azaz a folyamat várakozási feltétele bekövetkezik), az igényl folyamat futásra kész állapotú lesz, és átkerül a futásra kész sorba, ahol megvárja, amíg az ütemez újra elindítja. A folyamatot a ... ábra szemlélteti.

I. Multiprogramozott operációs rendszerek

58

FOLYAMATOK

OPERÁCIÓS RENDSZER

MÁGNESLEMEZ

Pi fut laphiba

laphiba-megszakítás

címzési hiba

laphiba oka?

nincs a tárban szabad vagy cserélendõ lap kiválasztása

hibakezelés (pl. Pi abortálása)

(mentés) betöltés indítása

Pi várakozó állapotba

CPU ütemezés

betöltés folyamatban

Pi vár

Pj fut betöltés vége megszakítás

Pi futásra kész állapotba, laptáblájának módosítása Pi futásra kész Pj fut

... ábra Laphiba kezelésének folyamata

A virtuális tárkezelés megvalósítása teljesen új feladatok elé állítja az operációs rendszert, amelynek megoldásához megfelel hardver támogatás szükséges. Legel ször is biztosítani kell, hogy az érvénytelen címre való hivatkozás megszakítást okozzon. Ezenfelül a megszakított utasítások újraindíthatók, vagy folytathatók kell, hogy legyenek. A folytathatóság megoldása ritkább, mert utasítások végrehajtása közben fennálló állapotot kellene elmenteni, ami meglehet sen bonyolulttá tenné a processzorokat. Az újraindíthatóság megoldása, bár els pillanatra talán triviálisnak t nik, bizonyos típusú utasításoknál - például

I. Multiprogramozott operációs rendszerek

59

több cím , blokkmozgató, autoinkremens, illetve autodekremens indirekt cím utasítások ugyancsak nem egyszer feladat.
Megjegyzés: Úgy rémlik, hogy azon próbálták ki, de a 370-en terjedt el. (Valahol meg kéne nézni)

A virtuális tárkezelést az IBM/360 számítógépcsalád megjelenésével kezdték elterjedten alkalmazni, és elmondhatjuk, hogy ma már a fejlettebb mikroprocesszorok mindegyike használ valamilyen fajta virtuális tárkezelést. A korszer hardverek szinte kivétel nélkül lapvagy kombinált szervezés ek, ezért a virtuális tárkezelés is csaknem mindig lapok mozgatásán alapul, így a továbbiakban mi is lapszervezés rendszerekkel foglalkozunk.

A virtuális tárkezelés lapcsere algoritmusait egyéb, a blokkokhoz tartozó - kés bb részletesen tárgyalt - bitek is támogatják.

A különböz

rendszerek min sítését alapvet en befolyásolja a m ködési sebességük. A

folyamatok futásának sebességét pedig dönt en a tárhoz férés effektív ideje határozza meg. Ez virtuális tárkezelés esetén a megfelel el fordulási valószín séggel súlyozott memória hozzáférés, illetve (laphiba esetén) lapbehozatali id b l számítható. Ha p jelöli a laphiba el fordulás valószín ségét, akkor

effektív hozzáférési id = (1-p) * memória hozzáférési id + p * laphiba id .

A laphiba kiszolgálási ideje több, mint öt nagyságrenddel is nagyobb lehet a valós memória hozzáférési id nél (a lemezm veletek id igénye a mai rendszerekben is 10 msec körül van), ezért p-nek nagyon kicsinek ( 10-6-10-8) kell lennie ahhoz, hogy a folyamatok futása ne lassuljon le túlságosan.
Megjegyzés: három

A virtuális tárkezelés tárgyalásánál három alapvet kérdést kell megválaszolnunk:
· Melyik lapot hozzuk be a tárba ? (Betöltend lap kiválasztása) · Ha nincs szabad hely a memóriában, akkor melyik lapot cseréljük le? (Lapcsere,

replacement strategy)
· Hogyan gazdálkodjunk a fizikai tárral, azaz melyik folyamat számára hány lapot

biztosítsunk?

I. Multiprogramozott operációs rendszerek

60

A továbbiakban e három kérdést fogjuk kicsit részletesebben megvizsgálni.

I.4.2.2. Betöltend lap kiválasztása (fetch-strategy)

Alapvet en két stratégiát követhetünk:

Igényszerinti lapozás (demand paging) esetén csak a laphibánál hivatkozott lapot hozzuk be

a tárba. A módszer el nye, hogy a betöltend lap kiválasztása nagyon egyszer , továbbá, hogy csak a biztosan szükséges lapok kerülnek be a tárba. Ugyanakkor az új lapokra való hivatkozás mindig laphibát okoz, ami lassítja a m ködést.

El retekint

lapozásnál (anticipatory paging) ezzel szemben az operációs rendszer

megpróbálja ,,kitalálni", hogy a folyamatnak a közeljöv ben mely lapokra lesz szüksége, és azokat szabad idejében - amikor a lapcseréhez használt háttértár szabad - betölti.

Ha a jóslás helyes volt, akkor az el re behozott lapok miatt jelent sen lecsökken a laphibák száma, és ezzel a folyamat futási sebessége nagyban felgyorsul. Ha a döntés hibás volt, akkor felesleges lapok foglalják el a tárat.

Mivel manapság a központi tár ára drasztikusan csökken és ezzel párhuzamosan mérete egyre n , ezért az el retekint lapozás egyre népszer bb, hiszen a hibás döntés - azaz a felesleges tárfoglalás - ,,ára" egyre kisebb.

I.4.2.3. Lapcsere stratégia (replacement strategy)

Lapcsere esetén ki kell választani azt a lapot, amelyiket feláldozzuk az új lap betöltése érdekében. A lapcsere stratégiák alapvet célja az, hogy az optimális esetet közelítsék, azaz azt a lapot válasszák áldozatul, amelyikre a legkés bb lesz szükség (vagy másképp fogalmazva legtovább nem lesz szükség).

I. Multiprogramozott operációs rendszerek

61

A lapcsere általános esetben két lépésb l áll: az áldozat kimentéséb l és az új lap betöltéséb l Az algoritmusok hatékonyságát nagyban fokozhatja, ha a mentést - vagyis háttértárra írást csak akkor végzik el, ha szükséges, vagyis ha a lap tartalma a betöltés óta módosult. Annak nyilvántartása, hogy egy lapra betöltése óta írtak-e, csak hardver támogatással valósítható meg hatékonyan. A támogatás lényege, hogy minden fizikai laphoz tartozik egy jelz bit - a
módosított bit (modified bit, dirty bit, M bit). Ezt a bitet a lap betöltésekor az operációs

rendszer törli, a tárkezel hardver pedig minden, a lapra író memóriam velet végrehajtásakor beállítja. A bit a laptáblában is elhelyezhet .

Bizonyos algoritmusok igénylik a lapra történ hivatkozások figyelését is, ami ugyancsak hardver támogatással hatékony. A laptáblában erre a célra is fenntarthatunk egy bitet. Ezt a
hivatkozott bitet (referenced bit, used bit, R bit) a címképz hardver állítja be minden

esetben, amikor az adott lapon belüli címre történik hivatkozás. A bitet az operációs rendszer törli adott id nként, vagy eseményhez (például laphiba) kötötten.

Optimális (Optimal, OPT) algoritmus

Az algoritmus el renéz és a lapok következ használatának idejét veszi figyelembe. Ennél az algoritmusnál a legkevesebb a laphibák száma. Sajnos azonban a megvalósítása nehézségekbe ütközik, mivel jöv beni laphivatkozásokra vonatkozó információt igényel (a helyzet az SJF ütemez algoritmushoz hasonló). Az egzakt végrehajtás gyakorlatilag megoldhatatlan, a

kódok valamiféle el reolvasását és szimulált végrehajtását igényelné az adatfügg elágazások figyelembevételével, ami csaknem olyan bonyolult lenne, mint a program valódi végrehajtása. Így csak közelít megoldásokkal találkozunk. Az optimális algoritmus szerepe pedig az, hogy összehasonlítási alapként szolgáljon egy-egy eset utólagos értékelésekor, amib l

következtetéseket vonhatunk le arra nézve, hogy az alkalmazott algoritmus mennyire közelítette meg az optimumot.

Legrégebbi lap (FIFO) algoritmus

A FIFO algoritmus úgy próbálja közelíteni az optimálist, hogy hátranéz és a behozatal idejét figyeli. Az algoritmus azt a lapot cseréli le, amelyik legrégebb óta a tárban van. Megvalósítása

I. Multiprogramozott operációs rendszerek

62

egy egyszer FIFO listával történhet. Hibája azonban, hogy azokat a lapokat is lecseréli, amelyeket a folyamatok gyakran használnak. Ennél az algoritmusnál felléphet egy érdekes jelenség, amelyet Bélády1 anomáliának hívunk. Eszerint - várakozásainkkal ellentétben - bizonyos esetekben, ha növeljük a folyamathoz tartozó fizikai memória keretek számát, akkor nem csökken, hanem éppen növekszik a laphiba gyakoriság. A 4.4.o. ábra mutat példát erre.

4.4.o. ábra Bélády anomália
Megjegyzés: Didaktikailag ezt a végére tenném, mint jó kompromisszumot, és a leggyakrabban alkalmazott megoldást.

Újabb esély (Second Chance, SC) algoritmus

Az újabb esély algoritmus a FIFO olyan változatát valósítja meg, amely a sor elején lev lapot csak akkor cseréli le, ha nem hivatkoztak rá. Vagyis hátranéz és a használat tényét figyeli. Ha hivatkoztak a lapra, akkor a hivatkozott bitet törli és a lapot visszateszi a FIFO lista végére, vagyis a lap kap egy újabb esélyt. Ezzel kiküszöböli a FIFO algoritmus hibáját és a gyakran használt lapokat nem cseréli le. A hivatkozott bit tehát ebben a megoldásban azt jelzi, hogy a lapra történt-e hivatkozás azóta, mióta az operációs rendszer legutóbb megvizsgálta, mint lehetséges áldozatot.

Óra (Clock) algoritmus

Az óra algoritmus csak megvalósításában különbözik az újabb esély algoritmustól. A tárban lev lapok egy körkörös listára vannak felf zve a betöltés sorrendjében, és egy mutató mutat a legrégebbi lapra. Lapcserénél a kijelölt lap kivitele el tt az algoritmus megvizsgálja az R bitet. Amennyiben egynek találja, úgy nem viszi ki ezt a lapot, hanem törli az R bitet, és a mutató eggyel el bbre lép. A lépések addig ismétl dnek, amíg az algoritmus egy kivihet lapot nem talál (azaz amelynél R=0).

Legrégebben nem használt (Least Recently Used, LRU) algoritmus

1

Bélády László magyar származású kutató, aki az IBM virtuális tárkezelésének egyik kidolgozója.

I. Multiprogramozott operációs rendszerek

63

Az LRU algoritmus azt a lapot választja áldozatul, amelyre a folyamatok leghosszabb ideje nem hivatkoztak. Ez az algoritmus közelíti legjobban az optimálist, mivel ugyan hátrafele néz, viszont a használat idejét veszi figyelembe (azaz a közelmúltból következtet a közeljöv re, ami a lokalitás miatt jó becslést adhat).

Ennél a jó teljesítménye miatt gyakran használni kívánt algoritmusnál gondot okoz, hogy ,,drága". A használat ideje alapján történ sorbarendezés külön hardver támogatást igényel, és az algoritmus futási ideje is magasabb az egyszer algoritmusokénál. A megvalósításra több változatot is kidolgoztak.

· Számlálóval: A lapra történ minden hivatkozásnál feljegyezzük annak id pontját (egy

logikai óra, vagy számláló állását). Lapcserénél a tárolt id pontok közül a legrégebbit keresi ki az algoritmus. Ez a megvalósítás a lapkiválasztási id t is megnövelheti, hiszen a legkisebb id megkeresése mellett minden memória hivatkozásnál egy extra memória írási ciklust jelenthet (az id pont tárolása).
Megjegyzés: Hát, ha vagyunk olyan hülyék, és memóriában tároljuk az órát.

· Láncolt listával: A memóriában tárolt lapok egy láncolt listában vannak felf zve, az

újonnan behozott lapok a lista végére kerülnek, az algoritmus a lista elején álló lapot választja ki. Címhivatkozásnál a címzett lapot kivesszük a listából és a végére illesztjük.

· Két dimenziós tömbbel: Ennél a megvalósításnál a hardver egy n*n-es (n a lapok számát

mutatja) mátrixot használ (inicializáláskor a mátrix a 0 mátrixszal egyezik meg). Az i. lapra történ hivatkozásnál a mátrix i. sorának minden bitjét egyre, majd az i. oszlop minden elemét nullára állítja. A legkisebb bináris érték sor az LRU laphoz tartozik.

A bonyolult megvalósítás miatt az LRU algoritmus helyett sokszor annak - hardver támogatást nem, vagy alig igényl - közelítését szokták használni:

Legkevésbé használt (Least Frequently Used, LFU vagy Not Frequently Used, NFU) algoritmus

I. Multiprogramozott operációs rendszerek

64

Ennél az algoritmusnál abból indulhatunk ki, hogy a közelmúltban gyakran használt lapokat a folyamatok a közeljöv ben is használni fogják még, és ugyanígy, a közelmúltban ritkán, vagy nem használt lapokra a közeljöv ben nem lesz szükség. Ilyenkor az operációs rendszer rendszeres id közönként végignézi a memóriában lev lapokat, és a hozzájuk rendelt

számlálóhoz hozzáadja az R bit (0 vagy 1) értékét, és egyben törli az R biteket. Az algoritmus a legkisebb számláló értékkel rendelkez - vagyis a legritkábban használt - lapot választja ki kivitelre.

Hátrányt jelent, hogy az algoritmus ,,nem felejt", vagyis az egykor gyakran használt lapok még sokáig a memóriában maradnak akkor is, ha már biztosan nem lesz rájuk hivatkozás (pl. több menetes fordításnál az egyes menetekhez tarozó lapok). A problémán öregítéssel segíthetünk, például úgy, hogy az R bitet a legnagyobb helyiérték bit helyére másoljuk, de el tte a számlálót jobbra léptetve csökkentjük a régebbi hivatkozások súlyát.

A módszer másik problémája, hogy a frissen betöltött (és így biztosan kis számláló érték ) lapokat is könnyen kiteheti újra a háttértárra. Ezért általában a frissen behozott lapokat az els használatig befagyasztjuk (page locking) a tárba.

Utóbbi id ben nem használt (Not Recently Used, NRU) algoritmus

Az utolsó algoritmus, amelyet megemlítünk, az R (hivatkozott) és M (módosított) bitek használatán alapszik. A hivatkozottság egy id elteltével elveszti a jelent ségét, ezért az operációs rendszer rendszeres id közönként törli az R bitet. Ugyanakkor az M bit értékét rizni kell, hiszen törlése információ veszteséghez vezetne.

A két bit értéke alapján az algoritmus a lapokat négy csoportba osztja, és lapkivitelnél
hátranézve és a használat idejét és módját is figyelembe véve, a lehet legkisebb prioritású

csoportból választ véletlenszer en:

I. Multiprogramozott operációs rendszerek

65

prioritás 0 1 2 3

R bit 0 0 1 1

M bit 0 1 0 1

Megjegyzés nem hivatkozott, nem módosított nem hivatkozott, módosított hivatkozott, nem módosított hivatkozott, módosított

Az algoritmusok m ködhetnek úgy, hogy szükség esetén mindig a folyamat saját munkaterületén belül választanak ki lapot kivitelre - ilyenkor lokális lapcsere algoritmusról beszélünk, vagy pedig az egész memórián belül keresnek - globális lapcsere algoritmus esetén. Ez utóbbi stratégia sokkal alkalmasabb a terhelésingadozások kiegyenlítésére, azonban könnyen el fordulhat, hogy a ,,burjánzó" (sokfele hivatkozó) folyamatok kiszorítják a ,,kicsiket".

Bármelyik algoritmus használata esetén gyorsíthatjuk a lapcserét, és az eszközök egyenletesebb terhelését érhetjük el, ha egy periódikusan felébresztett háttérfolyamat, a
paging daemon a háttértár szabad idejében (henyélésekor) a módosított lapokat kimásolja, így

ezek esetleges kés bbi lecserélésekor azokat nagy valószín séggel már nem kell újra kiírni.

Fenntarthatunk egy el rehozott, kisebb CPU-terhelés idején futtatott áldozatválasztással kialakított listát, amelyikr l azonnal leemelhetünk egy lapot, ha cserére van szükség. Ha a listán lév lapok száma csökken, újabb el zetes áldozatokat választhatunk. Fokozza a

hatékonyságot, ha a paging daemon a szabad listára tett módosított lapokat írja ki el ször, illetve a listára eleve a kimentést követ en kerülnek fel a lapok. El fordulhat az is, hogy a szabad listára került lapok felülírása el tt újabb hivatkozás történik rájuk. Ezek a hivatkozások még megtalálják a lapokat, ilyenkor természetesen nem kell azokat újra behozni, csupán lekerülnek a szabad listáról.

I.4.2.4. Gazdálkodás a fizikai tárral

I. Multiprogramozott operációs rendszerek

66

(1) A folyamatok lapigénye

A fizikai tárgazdálkodás legalapvet bb kérdése, hogy hány lapot adjunk az egyes folyamatoknak. A folyamatok szempontjából nézve az a jó, ha minél több lapjuk van a tárban, hiszen nagy valószín séggel annál kevesebb laphibát okoznak. Túl kevés lap esetén állandóan laphiba lép fel. Ha a rendszerben átlagosan nem tud befejez dni egy laphiba kiszolgálása, miel tt egy újabb laphiba fellép, a folyamatok felgy lnek a mágneslemez várakozási sorában, és a CPU-nak nem lesz futtatható folyamata, CPU-tétlenség alakul ki. A rendszer teljesítménye leromlik. (Fennáll annak a veszélye is, hogy a hosszútávú ütemez ezt a B/Kintenzív folyamatok túlsúlyaként értékeli, és újabb folyamatokat enged be, ami természetesen tovább rontja a helyzetet.) A gyakori laphibák által okozott teljesítménycsökkenést
verg désnek (thrashing) nevezzük. A jelenséget jól szemlélteti a IV.4.p. ábra, amelyik a

multiprogramozás fokának és a CPU-kihasználásnak az összefüggését mutatja virtuális tárkezelést alkalmazó rendszerek esetére.

4.4.p. ábra A multiprogramozás hatása a CPU kihasználtságra

A rendszer szempontjából nézve, ha egy folyamatnak sok lapot adunk, azt jelenti, hogy kevesebb folyamatot tudunk a tárban tartani, így alacsonyabb lesz a multiprogramozás foka és ezzel várhatóan a CPU kihasználtság is: A görbe kezdeti szakaszán kevés folyamat van a rendszerben. Minél kevesebben vannak, annál nagyobb annak a valószín sége, hogy mindegyikük várakozik, a CPU pedig tétlen. A folyamatok számának a növekedésével a CPU-kihasználás aszimptotikusan közelít az adminisztrációs (pl környezetváltási)

veszteségekkel csökkentett 100%-os maximumhoz. A folyamatok számának további növekedésekor azonban - mivel az egy folyamatra jutó tárterület csökken - belép a tárkezelés hatása és kialakul a verg dés, a CPU-kihasználás pedig a folyamatok számának további növelésével meredeken leesik. El kell kerülni, hogy a rendszerben ilyen üzemállapot alakulhasson ki, azonban az optimumot lehet leg meg szeretnénk közelíteni. Fontos tehát, hogy meg tudjuk becsülni, milyen laphiba gyakoriság (page fault frequency, PFF) mellett marad még a rendszer egyensúlyban.

I. Multiprogramozott operációs rendszerek

67

Könnyen beláthatjuk, hogy a rendszer egészét tekintve a CPU akkor nem válik tétlenné, ha átlagosan egy laphiba kezelése közben nem következik be újabb laphiba (ha meggondoljuk, ugyanerre a következtetésre jutottunk az effektív memória hozzáférési id kapcsán). kiszámítása

A teljes rendszerre vonatkozó egyensúlyi feltételt vonatkoztathatjuk az egyes folyamatokra is, azaz el írhatjuk, hogy két laphiba közötti átlagos futási idejük haladja meg a laphiba átlagos kiszolgálási idejét. Ha ez minden folyamatra teljesül, akkor az egész rendszer is egyensúlyban lesz.

Visszatérve az eredeti kérdésre, célszer tehát egy folyamatnak annyi lapot adni, amennyi szükséges az egyensúlyhoz, azaz ahány lapra hivatkozik a laphiba kiszolgálás átlagos ideje alatt (ugyanakkor nem sokkal többet, mert akkor leromlik a multiprogramozás foka). Ezt az értéket a munkahalmaz méretének (working-set size) nevezzük.

(2) Munkahalmaz

Munkahalmaznak (working set, bizonyos irodalmakban m köd lapkészlet) nevezzük egy

folyamat azon lapjainak a halmazát, amelyre egy adott id intervallumban (munkahalmazablak) - a hossza célszer en a laphiba kiszolgálási id vel egyezik meg - hivatkozik. A munkahalmaz dinamikus fogalom, tehát id ben változik, ami nemcsak a munkahalmazba tartozó lapok, hanem a munkahalmaz méretének a változását is jelenti az id tengely mentén. Pontos mérése, nyilvántartása igen nehézkes, ezért az esetek többségében csak becslésekre hagyatkozunk.

(3) Lokalitás

A munkahalmaz becslésében nagy szerep jut a lokalitásnak (locality). A folyamatok statisztikailag megfigyelhet tulajdonsága, hogy egy id intervallumban a címtartományuknak csak egy sz k részét használják. Id beni lokalitás alatt azt értjük, hogy egy hivatkozott címet a folyamat a közeljöv ben várhatóan újra használni fog, míg a térbeli lokalitás fogalma azt

I. Multiprogramozott operációs rendszerek

68

takarja, hogy az id ben egymáshoz közelálló hivatkozások nagy valószín séggel egymáshoz közeli címekre történnek.

A munkahalmaz becslése során tehát kiindulhatunk abból, hogy a közelmúltra vonatkozó munkahalmaz nem fog lényegesen eltérni a közeljöv ben szükséges munkahalmaztól (a korábban tárgyalt lapcsere stratégiák is mind ezen a felismerésen alapulnak). Ez nem jelenti azt, hogy a folyamatok munkahalmazának mérete egyes futási szakaszokban ne változhatna meg jelent sen.

A lokalitás hatással van arra is, hogy hogyan alakul a laphiba gyakoriság a folyamat teljes címtartományából a memóriába töltött hányad függvényében. A laphibák aránya nem lineáris függvénye lesz a memóriába töltött címtartomány arányának (mint ahogy véletlen hivatkozás esetén fennállna), hanem ennél kisebb értékeket kapunk (4.4.q. ábra).

4.4.q. ábra A lokalitás hatása a laphiba gyakoriságra

(4) Dinamikus lokális tárgazdálkodás

Az optimális rendszerm ködéshez tehát el kell kerülni a verg dést, és törekedni kell arra, hogy a folyamatoknak a lokalitás alapján meghatározott munkahalmaza futás közben a központi memóriában legyen. A folyamatokat úgy érdemes elindítani vagy felfüggesztés után újraindítani, hogy egyszerre több lapjukat - a várható munkahalmazt - behozzuk a tárba (másképp induláskor túl gyakori lenne a laphiba). (El relapozás, prepaging)

Az optimális (legmagasabb fokú) multiprogramozás eléréséhez a legtöbb rendszer lokális lapcsere algoritmust alkalmaz. Ugyanakkor a munkahalmaz tárban tartását - a laphiba gyakoriság mérésén alapuló - a folyamatokhoz tartozó memóriaterület méretének dinamikus változtatásával biztosítja.

A globális lapgazdálkodás (globális lapcsere algoritmusok) kedvez tlen kölcsönhatást okozhatnának egymástól egyébként független folyamatok között. A statikus lokális tárgazdálkodás ezt megakadályozza, de nem tud alkalmazkodni a folyamatok futás közben

I. Multiprogramozott operációs rendszerek

69

változó lapigényéhez. A jó kompromisszumot egy dinamikus lokális gazdálkodás jelentheti, amelyik alkalmazkodni képes a folyamatok aktuális lapigényéhez.

A folyamatok aktuális lapigényének meghatározására az egyik megoldás a munkahalmaz (illetve méretének) mérése, azonban, mint korábban említettük, ez túl körülményes lenne. Ehelyett inkább a folyamatok laphiba gyakoriságát, illetve az ezzel egyenérték laphibák
között eltelt id t (interfault time) mérik, ami sokkal könnyebben megoldható.

Ha a laphiba gyakoriság meghalad egy fels határértéket, akkor a folyamathoz újabb lapot rendel, vagy pedig - amennyiben nincs több hozzárendelhet szabad memóriakeret, vagy memóriab vében lév folyamat - a multiprogramozás fokának csökkentése mellett dönt, és felfüggeszti valamelyik folyamatot. Ha pedig a laphiba gyakoriság alatta marad egy alsó határértéknek, akkor elvesz a folyamattól egy lapot (4.4.r. ábra). Új folyamatot pedig csak akkor lehet elindítani, ha van ,,elegend " szabad memóriakeret a számára.

4.4.r. ábra Rendszer egyensúly biztosítása a laphiba gyakoriság mérése alapján

I.4.2.5. Egyéb tényez k

(1) Lapméret

A rendszer m ködésére közvetlen hatással van a lapok mérete is. Ezt általában a hardver köti meg, így az itt következ ket inkább hardver, mint szoftver rendszerfejleszt k mérlegelik.

Nagyobb lapméretek alkalmazása esetén figyelembe kell venni, hogy kevesebb lappal, így kisebb laptáblával számolhatunk, a perifériás átvitel fajlagos ideje csökken (az átvitel idejének nagyobb részét az el készítési id teszi ki), a folyamatok munkahalmazának mérete n , ugyanakkor nagyobb lesz a bels tördel dés.

I. Multiprogramozott operációs rendszerek

70

Kisebb lapoknál éppen ellenkez leg, jobban érvényesül a lokalitás (kisebb lesz a munkahalmaz), kisebb lesz a bels tördel dés, viszont a perifériás átvitel fajlagos ideje és a laptáblák mérete is megn .

(2) Lapok tárba fagyasztása

Az LFU lapcsere algoritmusnál már említettük a lapok tárba fagyasztásának lehet ségét. Erre kifejezetten szükség is van bizonyos esetekben. Például, elindított perifériás m veleteknél az átvitel befejez déséig a kijelölt címtartományt a tárban kell tartani.

(3) Program struktúra

A virtuális tárkezelés átlátszó, azaz m ködése el van rejtve a felhasználó el l. Ha azonban a tárkezelés m ködését és sajátságait - els sorban a lokalitás hatását - mérnöki szemmel vizsgáljuk, jól látható, hogy maga a programozó is sokat tehet a programok gyorsabb lefutásáért, a rendszer jó teljesítményéért.

Csak néhányat említve a jól alkalmazható ,,trükkök" közül:

Programíráskor

· több dimenziós tömböket célszer a tárbeli elhelyezkedésüknek megfelel en bejárni

(például keresésnél)
· a programokban célszer kerülni a nagy ugrásokat · az egyszerre használt változókat, az egymást hívó eljárásokat célszer egymás mellé

helyezni

Fordításkor

· az eljárásokat célszer egymás mellé helyezni

I. Multiprogramozott operációs rendszerek

71

· a kód- és adatterületeket célszer szétválasztani (a kódterület nem változik, így

lapcserénél nem kell kimenteni).

I.4.3. Fájlrendszerek
A klasszikus operációs rendszerek felhasználók által leginkább használt absztrakciója a fájl, állomány. Fájlnak a felhasználó, vagy a rendszer szempontjából összetartozó információk perzisztens, a létrehozó programot ,,túlél " gy jteményét nevezzük. A fájlokat a rendszer többnyire valamilyen háttértáron tárolja, amely tartalmát meg rzi még akkor is, amikor a rendszer áramellátását kikapcsolták. Leggyakoribb a közvetlen hozzáférés perifériás

eszközök, mint például a mágneslemez használata, de f leg korábbi rendszerekben felfelt ntek soros hozzáférés tárolóeszközök is. Ma ezek az eszközök els sorban a biztonsági másolatok és a nagyméret , off-line adatraktárak tárolóiként használatosak.

Egy operációs rendszer rendszerint nagy számú fájlt tárol, kezel. Ezeket egymástól meg kell különböztetni, el kell különíteni. Az egyes állományokat tipikusan egy hozzájuk rendelt név azonosítja, a nagy számú fájlt könnyebb kezelhet ség érdekében könyvtárakba csoportosítják. Az állományok az operációs rendszer felhasználói számára közös, logikai er forrás halmazt képeznek, az ebb l fakadó er forrás-gazdálkodási feladatok, mint például a hozzáférések ütemezése, koordinálása, szabályozása, korlátozása is a fájlkezel rendszerek feladata.

A fájl absztrakció a rendszer használója, programozója számára kényelmes hozzáférést biztosít a fájl tartalmához, elrejtve a tárolás és kezelés konkrét részleteit. A fájlkezel rendszer tipikusan a következ magas szint feladatokat valósítja meg:

· hozzáférést biztosít az állomány részeihez, megvalósítja az állományok tartalmának

átvitelét a háttértár és a központi tár, illetve a háttértár és egyéb perifériák - például nyomtató - között
· m veleteket biztosít az egyes fájlokon, illetve a fájlokat összefoglaló könyvtárakon · osztott hozzáférések esetén koordinálja, id zíti az egyes folyamatok fájlhasználatát

I. Multiprogramozott operációs rendszerek

72

· szabályozza a felhasználóknak, vagy azok programjainak a fájlokhoz hozzáférést,

különválasztva kezeli az egyes felhasználók állományait és könyvtárait, megakadályozza, hogy a fájlokon illetéktelen felhasználók m veleteket végezhessenek. Esetlegesen védi a fájlokban tárolt információkat az illetéktelen olvasások ellen, kódolva, titkosítva annak tartalmát.
· gyakori a fájlokban tárolt információk sérülése, hardver vagy kezelési hiba miatt

bekövetkez elvesztése elleni védelem, a fájlok id szakonkénti megbízhatóbb háttértárra mentése is.

A fájlok kezelését különböz , a konkrét hardvert l egyre távolodó, a logikai szervezéshez egyre közeled , egymásra épül programrétegek valósítják meg.

A perifériás eszközhöz legközelebb az úgynevezett készülékkezel programok (device driver, meghajtó) állnak, amelyek közvetlenül a berendezéseket vezérlik. Ezen réteg feladata az adatok központi tár és a periféria közötti átvitelének kezdeményezése, vezérlése, lebonyolítása. A jelenlegi hardver rendszerekben tipikusan megszakításosan vezérelt perifériák megszakításai is ide futnak be.

A meghajtókra épül az elemi átviteli m veletek lebonyolítására szolgáló réteg. Itt történik meg a fájlok tartalmának a periféria által használt címzési rendszerre való leképzése, a periféria által megkövetelt, avagy csak a rendszer teljesítményét javító, az átvitelek számát csökkent blokkok képzése. Mivel a háttértár elérése még a korszer , nagy sebesség

mágneslemezes tárak esetén is több nagyságrenddel lassabb, mint a központi tár elérése, e réteg gyakori feladata gyorsító tárak (cache) képzése, a gyakran használt blokkok központi tárból történ újrafelhasználásának megvalósítása is. Egyidej hozzáférés kérelmek esetén a réteg sorba állíthatja a kéréseket, optimalizálva a fizikai er forrás kihasználását.

A elemi átvitelekre épül az állományszervezés rétege, amely nyilvántartja a háttértár szabad és lefoglalt területeit, gondoskodik az egyes fájlokhoz tartozó blokkok logikai összef zésér l, a dinamikus helygazdálkodásról. Ide tartozik új fájlok létrehozásakor, vagy a fájlokban tárolt információ b vülésekor további szabad helyek lefoglalása, illetve állományok törlésekor a

I. Multiprogramozott operációs rendszerek

73

korábban lefoglalt területek felszabadítása. Tipikusan ez a réteg biztosít eljárásokat a rendszer programozói számára az állomány tartalmának eléréséhez, módosításához.

A logikai állományszervezés rétege ismeri és kezeli a nyilvántartásokat, az állomány neve alapján megtalálja annak helyét. Ide tartozik az állományok felhasználónkénti hozzáférésének szabályozása, de gyakran a konkurens elérések id beli ütemezése, szinkronizálása is e réteg feladata.

Vizsgáljuk meg részletesebben az egyes rétegek megvalósításánál használt adatszerkezeteket, algoritmusokat. A készülékkezel k és az elemi átviteli m veletek rétegével itt nem foglalkozunk, azt a készülékkezelésr l szóló fejezet részletezi. Az állományok tárolására közvetlen hozzáférés lemezegységet tételezünk fel.

I.4.3.1. Az állományok tárolása a lemezen

Az operációs rendszer a lemezterületet a hardverhez hasonlóan nagyobb egységekben, blokkokban kezeli. Ez az adatmozgatás, lefoglalás, felszabadítás alapegysége, ennél kisebb területekkel az operációs rendszer nem foglalkozik (néhány kivételt l eltekintve). Egy logikai - operációs rendszer által képzett - blokk tipikusan 1 vagy néhány hardver blokkot - szektort tartalmaz. A blokkok méretének meghatározását szervezési, tárolási és hatékonysági szempontok befolyásolják. Minél nagyobb blokkokat használunk, annál kevesebb az egységnyi információ átviteléhez szükséges többlet m velet, viszont a nagy blokkokat ki nem tölt információ miatt feleslegesen foglalunk mind a háttértárban, mind a központi tárban területet, jelent s bels tördel dési veszteség lép fel.

A blokkok méretét gyakorta meghatározza az adatszerkezetekben a blokkokat azonosító címek számára fenntartott hely mérete. F leg kisebb, kezdetlegesebb rendszerekben a blokkok címzésére viszonylag kevés helyet, mondjuk 16 bitet tartottak fenn. Eleinte a 16 biten ábrázolható különböz értékek b ven elegend nek bizonyultak az összes a lemezen el forduló fizikai szektor egyenkénti megcímzésére. Azonban a lemezegységek kapacitásának ugrásszer növekedésével ez a 16 bit hamarosan kevésnek bizonyult, fizikai szektorokat össze kellett vonni az operációs rendszer által egyben kezelt logikai blokkokká, hiszen ezek száma

I. Multiprogramozott operációs rendszerek

74

nem haladhatta meg a 64K-t. Ezért aztán a logikai blokkok mérete egyre növekedett, így gyakran el fordulhatott, hogy egy tipikusan néhány száz bájtból álló szöveges fájl a lemezen több megabájtnyi területet kényszerült elfoglalni. A csapdából természetesen egyszer nek t nik a kiút, nagyobb címtartományt kell fenntartani a blokkok számára. Ám ez nem csak a blokkok adminisztrációja számára fenntartott területeket növeli, elvéve a helyet az ,,értékes" adatoktól, de a háttértárak rohamos fejl désével a ma még b ségesen elegend nek t n címtartomány 1-2 éven belül sz knek bizonyulhat. Az egyes rendszerváltozatok kompatibilitásának fenntartása is nehezíti a probléma megoldását, hiszen a rendszer bels adatszerkezeteit érint módosításokat nem könny zökken mentesen lebonyolítani. Másik lehet ség a háttértár particionálása, a fizikailag nagy számú blokkot tartalmazó lemezegységek logikailag kisebb egységekre, ún. kötetekre ,,darabolása", ám a szétszabdalt tárterület kezelése is problémákat okoz.

A fájlszervezés rétegének a lemez minden egyes blokkját nyilván kell tartania, tudni kell, mely blokkok tartoznak az egyes fájlokhoz, melyek az éppen szabad, fel nem használt blokkok. Ismernie kell a különböz alacsony- (például szabad területek) illetve magas szint (például könyvtárak) nyilvántartások tárolására fenntartott blokkokat is, és gazdálkodnia kell velük.

Alacsony szinten kétfajta adatszerkezetet különíthetünk el, a lemez szabad blokkjainak, illetve az egyes fájlokhoz tartozó blokkoknak a leírását. Mivel mind információtartalmában, mind kezelésében más jelleg nyilvántartással van dolgunk, e célokra más és más adatszerkezetek honosodtak meg.

A szabad blokkok nyilvántartására a különböz adatszerkezetek használatosak:
· bittérképes ábrázolás:

A lemez mindegyik logikai blokkjához egy bitben tárolható, hogy szabad-e. Ezekb l a bitekb l képzett vektort a lemez kijelölt helyén tároljuk. A bitvektoros szervezés esetén egymás melletti szabad blokkok kiválasztása nagyon egyszer , de a vektor kezelése csak akkor hatékony, ha a teljes vektort a központi tárban tudjuk tartani.
· láncolt listás ábrázolás:

I. Multiprogramozott operációs rendszerek

75

A szabad blokkokból ,,lecsípett" bájtokban egy másik szabad blokk sorszámát, címét tárolhatjuk. Így a szabad blokkokat mintegy láncra f zzük, csak a lánc elejét kell ,,kézben tartani" - egy jól definiált helyen tárolni -, innen kiindulva az összes szabad blokk elérhet . Mivel a szabad blokkban értékes információ nincs, ezért a lecsípett bájtok nem okoznak problémát. Az ábrázolás viszont nem hatékony, a lista bejárása lassú, mert több lemezm veletet igényel.
· szabad helyek csoportjainak listája:

A fenti ábrázolás teljesítménye könnyen javítható. Ahelyett, hogy minden egyes blokkból csak egyetlen címnyi területet csippentenénk le, kihasználhatjuk a teljes blokkot arra, hogy más szabad blokkok címét tároljuk. Mivel a szabad blokkok száma dinamikusan változhat, az egyik címet a fenti láncolt lista képzésére használjuk, ám a többi n-1 címnyi terület 1-1 szabad blokkot jelöl ki.
· egybefügg szabad területek nyilvántartása:

A szabad blokkok egyesével történ tárolása helyett egy táblázatban az egymás mellett lév szabad blokkokról az els sorszámát és a terület hosszát tároljuk. A módszer akkor el nyös, ha a szabad területek átlagos hossza (jóval) nagyobb egynél, valamint ha az allokálásnál egymás melletti szabad területeket akarunk kiválasztani. Ha a táblázat elemei a kezd egyszer . blokk szerint rendezettek, az egymás melletti szabad területek összevonása

Az egyes állományokhoz tartozó blokkok tárolására, lefoglalására a következ megoldások alakultak ki:

általános

· Folytonos terület lefoglalása:

A fájlhoz tartozó információt egymás melletti szabad blokkokban tároljuk. A rendszernek csupán az els blokk sorszámát, valamint a blokkok számát kell tárolni az állományt leíró adatok között.

A módszer legnagyobb hátránya, hogy az esetek nagy többségében nem tudjuk el re, hány blokkra lesz szükségünk, így valamilyen algoritmussal a szükséges blokkok számát becsülni kell. Ha ez nem bizonyul elégnek és a lefoglalt blokkokat követ területet már használják, akkor a foglalást végz eljárás hibajelzést ad vissza, vagy megpróbál nagyobb

I. Multiprogramozott operációs rendszerek

76

szabad területet keresni, és oda a már felhasznált blokkok tartalmát is átmásolni. Itt is felléphet a küls tördel dés problémája, azaz az összefügg területek lefoglalása és

felszabadítása esetén a szabad területek kis, nehezen használható részekre tördel dnek. Különböz allokációs algoritmusokkal (els illeszked , legjobban illeszked ,

legrosszabbul illeszked kiválasztása) küzdhetünk a tördel dés ellen, illetve id szakonként tömörítést hajthatunk végre, ami azonban meglehet sen id igényes és körülményes eljárás, ezért viszonylag ritkán használatos. A fájlkezelésben az allokációs algoritmusok kombinált használata is el fordul. Amíg a lemezen nagy szabad területek vannak, általában teljesül a worst-fit allokáció mögött álló feltételezés, azaz a maradék használható más célra, legyen hát minél nagyobb. Amikor a lemez foglaltsága növekszik, ez a feltételezés egyre kevésbé teljesül, gyakorlatilag nincs jelent sége, melyik területet allokáljuk (first-fit, next-fit). További telít déskor már használhatatlan hulladékok keletkeznek, amelyeket

minimalizálni érdemes (best-fit). Ha mindemellett még a lefoglalandó terület méretét és figyelembe vesszük, és az átlagos szabad területhossz és a foglalás aránya szerint választunk algoritmust, viszonylag kedvez kihasználást érhetünk el.

A folytonos terület foglalásának el nye, hogy a tárolt információnak mind soros, mind közvetlen elérése egyszer , gyors. Napjaink rendszerében ez a tárolási forma általában akkor használt, ha el re tudjuk a szükséges blokkok számát, illetve igény az összes blokk egyidej , gyors tárba- illetve tárból való mozgatása. Tipikus eset a virtuális tárkezelés esetén a tárcsere (swapping) megvalósítása.
Megjegyzés: Szerintem a demand paging virtuális tárkezelés inkább tipikusan egyedi blokkok. A Swapping, azaz teljes folyamatok mozgatása, az OK.

· Láncolt tárolás:

A szükséges blokkokat egyesével allokáljuk, minden blokkban fenntartva egy helyet a következ blokk sorszámának. Általában a rendszer állományleíróban az els és esetleg az utolsó blokk sorszámát tárolja. A tárolási mód nagy el nye, hogy ez egy dinamikus adatszerkezet, az állomány mérete szükség szerint tetsz legesen növekedhet, határt csak a szabad blokkok száma szab. A fenti módszer küls tördel dését l is mentes, a szabad területeket nem kell tömöríteni.

Hátrány, hogy a láncolt tárolás csak a tárolt információ soros elérést támogatja, a közvetlen eléréshez a listát az elejér l végig kell járni.

I. Multiprogramozott operációs rendszerek

77

Külön problémát jelent, hogy a lánc szervezéséhez szükséges címet a blokkok hasznos területéb l kell lecsípni. Így egy-egy blokk központi tárba másolásakor ezeket a darabokat ki kell hagyni. Ezen a problémán segít a láncolt tárolás egy változata, ahol a láncokat az állományoktól elkülönülten, egy fájl allokációs táblában (FAT) tároljuk. Ennek a táblának minden eleme egy lemez blokkhoz tartozik, amelyben, ha a blokk egy állományhoz tartozik, tárolhatjuk az állományhoz tartozó következ blokk címét. Az egyes állományokhoz csak a lánc els blokkjának sorszámát kell tárolni az állományleíróban, a következ blokkok a FAT-ból megtalálhatók. Ezt az allokációs táblát egyidej leg a szabad blokkok tárolására is fel lehet használni. A tárolt információ közvetlen elérése is egyszer bb, nem kell az egyes blokkokat végigjárni, elég e FAT-ban ,,lépkedni". A FAT, vagy annak jelent s része a tárban tartható, így ez a keresés gyors. A sérülékenység ellen a FAT kett zött tárolásával védekezhetünk. Ezt a megoldást alkalmazzák az MS-DOS rendszerek.

· Indexelt tárolás:

Az indexelt ábrázolás alapötlete, hogy az állományhoz tartozó blokkokat leíró címeket külön adatterületre, az indextáblába gy jtjük. Az állományleíróban az indextáblát tartalmazó blokk(ok) címét kell tárolni.

A módszer el nyei, hogy a közvetlen hozzáférés megvalósítása egyszer , hiszen az indextábla segítségével minden blokk közvetlenül megtalálható. Lehet ség van "lyukas" állományok tárolására, azaz olyan állományokra, amelyek nem minden blokkja tartalmaz információt. Ebben az ábrázolási formában a nem használt területekhez nem kell lemez blokkot lefoglalni, azok helyét az indextáblában üresen hagyjuk.

Hátránya, hogy a blokkok címeinek tárolásához akkor is legalább egy teljes (index)blokkot kell lefoglalni, ha az állomány csak kevés blokkot tartalmaz. A tárolási mód pazarló. Mivel az index tábla mérete el re nem ismert, ezért meg kell oldani, hogy a táblázat is dinamikusan növekedhessen, például az index blokkokat láncba f zzük, hasonlóan a szabad helyek csoportjainak tárolásához, vagy több szint index táblákat használunk.

I. Multiprogramozott operációs rendszerek

78

· Kombinált módszerek:

Egyes rendszerek az állomány hozzáférési módja, vagy mérete függvényében más és más módszert alkalmazhatnak. Például kis állományokat folytonosan, míg nagyokat indexelten tárolhatunk. Vagy soros hozzáférés igénye esetén láncolt, közvetlen hozzáférés esetén összefügg blokkok tárolását választhatjuk.

Mind a szabad blokkok, mind az állományok tárolásának fent említett módszerei többékevésbé érzékenyek a lemezen tárolt nyilvántartások, adatszerkezetek sérülésére. Például egy láncolt blokkos szabad hely nyilvántartásnál egy blokk sérülése a lánc megszakadásához vezethet, ezzel a lánc végén álló blokkok elvesznek a rendszer számára. Még nagyobb problémát jelenthet az egyes állományokhoz tartozó blokkok leírásának elvesztése, megsérülése.

Ezt a problémát az operációs rendszerek általában redundáns adatszerkezetekkel igyekeznek enyhíteni. Például használhatunk kétirányú láncokat, ha a lánc mindkét vége még megvan, egy-egy blokk kiesését könnyen elviselhetjük, mindkét irányból elindulva megkeressük a ,,szakadást" és összef zzük a láncot.

A redundáns adatszerkezetek árát a csökken értékes tárolási kapacitással és a lassabb kezel algoritmusokkal fizetjük meg. Egy rendszer tervez jének gondosan mérlegelnie kell tehát az egyes tényez ket, például azt hogy a perifériás eszköz várhatóan milyen arányú meghibásodásokat produkál, mekkora katasztrófát okoz számunkra egyes szabad blokkok, vagy az állományok blokkjainak elvesztése. A sérülések hatásai kiküszöbölésének egyszer eszköze a háttértár tartalmának rendszeres, gyakori mentése.

A fájlkezel rendszernek - vagy az erre szorosan épül segédprogramoknak - tipikus feladata a különböz lemezen tárolt nyilvántartások konzisztenciájának ellen rzése, az esetleges

sérülések kijavítása. A javítás ügyesen megválasztott adatszerkezetek esetén, bonyolult - nagy lemezegységek esetén lassú - ellen rz algoritmusokat használva gyakran automatikusan

történhet, ám néha a rendszergazda kézi beavatkozására is szükség lehet. Legrosszabb esetben a rendszergazdának egyes blokkok tartalmát ,,szemrevételeznie" kell, megtippelni, hogy vajon ez szabad blokk lehetett-e, vagy valamelyik - és f leg melyik - állományhoz tartozhatott. Ez a

I. Multiprogramozott operációs rendszerek

79

tevékenység szöveges információk esetén még úgy-ahogy sikerrel kecsegtet, de ,,bináris" állományok esetén nagyon nehezen használható.

I.4.3.2. A fájlok szerkezete

Míg a fentiekben az állományok háttértáron lév fizikai szerkezetével foglalkoztunk, most a felhasználó szempontjait tükröz bels szerkezetét taglaljuk.

A fájl legáltalánosabb esetben összetartozó bitek sorozatának tekinthet . Napjaink hardver architektúrái tipikusan a bájtot tekintik a tárolás alapegységének, így a fájlokat is felfoghatjuk mint összetartozó bájtsorozatot. Ha ritkán is, de azért találkozhatunk a bájthatárokat nem ,,tisztel ", - változó bithosszúságú - információtárolási móddal is.

Az így tárolt bit- vagy bájtsorozathoz a felhasználó saját szempontjai szerint szerkezetet, jelentést rendelhet. Ilyenkor az alapegységet általában mez nek nevezzük, amely rendeltetése szerint egy-egy adott típusú, kódolású adatot tartalmaz. Az összetartozó mez ket gyakran rekordokba foglalhatjuk. Mind az egyes mez k, mind a rekordok tárolás szerint lehetnek kötött, vagy változó hosszúságúak. Ez utóbbi esetben gondoskodni kell az egyes mez k, rekordok határainak felismerhet ségér l, például tárolva a mez végjellel jelezve az adategység végét. hosszát, vagy speciális

Az

egyes operációs rendszerek a

felhasználói adatszerkezethez

különböz képpen

viszonyulhatnak. A leggyakoribb, általános célú fájlrendszerek nem veszik figyelembe a jelentés szerinti adatcsoportosítást, számukra a fájl ,,csak" egy bájt-, esetleg ritkán bitfolyam. A rendszer csak ennek a folyamnak a manipulálásához ad közvetlen eljárásokat (pl. olvasd a következ n bájtot). Az állományokat kezel felhasználói programoknak kell a megkapott bájtokhoz jelentést rendelni, elkülöníteni az egyes információ-darabkákat.

Célrendszerekben,

vagy

univerzális,

adatbáziskezelést

is

integráló

általános

célú

rendszerekben (ilyeneket különösen IBM rendszereken találhatunk) megtalálható viszont a felhasználói adatszerkezetet figyelembe vev , azt támogató szervezés is, ahol pl. létjogosultsága van az olvasd a következ rekordot, vagy következ mez t eljárásnak. Persze

I. Multiprogramozott operációs rendszerek

80

itt külön gondot jelent az egyes adatszerkezetek ,,megismertetése" a kezel

eljárásaival,

gyakori, hogy új adatszerkezet, tárolási mód, stb. esetén a fájlrendszer adatkezel eljárásait is b víteni kell.

Megjegyzend , hogy még azon rendszerekben is, amelyek a felhasználók fájljait szerkezet nélküli bájtsorozatnak tekintik, vannak a rendszer által ismert és kezelt szerkezet állományok. Például a futtatható programok kódját tartalmazó fájlok általában rendszerenként különböz , de kötött, szigorúan definiált szerkezettel rendelkeznek. Bár az operációs rendszer fájlkezel alrendszere nem ismeri ezek szerkezetét, de az erre épül betölt program annál inkább ismeri és használja. Ugyancsak találunk a rendszerekben minimális támogatást egyszer szövegfájlok, illetve parancsfájlok kezelésére.

I.4.3.3. Könyvtárak

A könyvtár állományok - esetleg más könyvtárak - gy jteménye, a könyvtár tartalmát a hozzátartozó nyilvántartás (katalógus, directory) írja le. A könyvtár és nyilvántartás fogalma a szakirodalomban gyakran keveredik.

Az egyes nyilvántartások állományonként egy ún. nyilvántartás bejegyzést tárolnak. A bejegyzések tartalmazzák az egyes állományok attribútumait.

Az állomány legfontosabb attribútuma az azonosítására szolgáló név. Ennek a névnek könyvtáranként egyedinek kell lennie. Míg egyes rendszerek a nevet csak egy karaktersorozatnak tekintik, addig mások a nevet részekre osztják, például névre, típusra (ún. kiterjesztésre), esetleg verziószámra. Ezeket a rendszer külön kezeli, például hivatkozhatunk az adott könyvtár összes adott típusú fájljára, vagy például az egyes fájlok legutolsó, legfrissebb tárolt verziójára.

A nyilvántartás bejegyzés tartalmazhat az állomány fizikai elhelyezkedésére vonatkozó információkat, mint például a hosszát, a hozzá tartozó blokkok leírását, a lehetséges hozzáférés módját. Gyakoriak a logikai attribútumok is, például az állomány típusa (bels szerkezete szerint), tulajdonosa, különböz id pont adatok - létrehozásának, utolsó

I. Multiprogramozott operációs rendszerek

81

hozzáférésének, módosításának dátuma, esetleg érvényességének ideje -, felhasználónkénti, vagy felhasználó-csoportonkénti hozzáférés, engedélyezett m veletek.

A nyilvántartás bejegyzéseket tárolhatjuk a lemez speciális, elkülönített területén, de speciális, kötött szerkezet fájlokban is. Néha el fordul kombinált tárolási forma, például kötet

nyilvántartásba kerül a köteten lév összes fájlt leíró nyilvántartás bejegyzés fizikai, esetleg logikai attribútumai, míg a neve, a könyvtárak szervezésének leírása külön tárolódik.

Az aktuálisan használatban lév fájlokról az operációs rendszer nem csak a háttértáron, de a központi tárban is tárol információkat. Ezek a fenti attribútumok - egy része - mellett a nyitott fájlok kezeléséhez szükséges egyéb állapotinformációt is tartalmazzák. Ilyen lehet például soros hozzáférés esetén az aktuális pozíció az állományban, vagy a megengedett m veletek listája, de osztott, konkurens kezelés esetén a szinkronizációhoz szükséges információk (pl. lock) is ide kerülnek.

A fájlkezel rendszerek gyakorta szerveznek hierarchiákat az egyes könyvtárakból. A korai rendszerek például kétszint hierarchiát használtak, a második szinten felhasználóként külön könyvtárba foglalva az egyes fájlokat. Napjainkban elterjedtek a szabadabb, flexibilisebb szerkezetek, például a faszerkezet könyvtárak, ahol az egyes könyvtárak nem csak fájlokat, hanem alárendelt könyvtárakat is tartalmazhatnak. Legáltalánosabb a gráfszer

könyvtárszerkezet. Mivel tipikus probléma lehet egy körrel rendelkez

gráfban a tárolt

elemek bejárása, kilistázása, ezért a rendszerek igyekeznek biztosítani a körmentes gráfszerkezetet, esetleg kivételt téve a rendszergazdával.

I.4.3.4. M veletek

A fájlkezelés modell-szinten is megjelen

alapm veletein túl a megvalósítás további

részm veleteket igényel. A fájlok nyilvántartásának megoldása az egyes rendszerekben igen különböz lehet, így a könyvtárakra vonatkozó m veletek is jelent sen különbözhetnek. Jellegzetes m veletek a könyvtárakon:

· fájl attribútumainak módosítása:

I. Multiprogramozott operációs rendszerek

82

Az állományhoz tartozó egyes logikai információk az állományban tárolt információk módosítása nélkül is megváltoztathatók.
· új könyvtár létrehozása · könyvtár törlése

Könyvtár törlésekor eldöntend , hogy mi történjék a tartalmával. Például egy könyvtár csak akkor törölhet , ha üres, nincsenek benne állományok vagy könyvtárak. Esetleg a törlés törli az összes benne lév állományt, esetleg rekurzívan törli az összes benne foglalt könyvtárat is.
· keresés:

A könyvtárakon végzett egyik leggyakoribb m velet, hogy egy névhez meg kell találni a hozzátartozó állományt. Keresni lehet a hierarchikus könyvtár szerkezetben, de végezetül a keresés mindig az egy könyvtárban tárolt állományok között történik. A keresés sebessége jelent sen befolyásolhatja a fájlkezel rendszer teljesítményét. Ezért különböz

adatszerkezetekkel igyekeznek a keresés felgyorsítani. A könyvtár hierarchiában történ keresést gyakran hash táblákkal gyorsítják, míg a nyilvántartás bejegyzések közötti keresést például rendezéssel vagy hash táblákkal lehet gyorsítani.

I.4.3.5. Osztott fájlkezelés

A fájl lehet olyan er forrás, amelyet egyidej leg több folyamat is használni akar. Amennyiben ezek a folyamatok csak olvassák, tartalma nem módosul, így az állomány osztottan is használható. Ha azonban legalább egy folyamat írja az állományt, akkor mint minden er forrást, ezt is kölcsönös kizárással védeni kell. Kérdés, hogy a kölcsönös kizárást mennyi ideig kell fenntartani.

Az osztott fájlkezelést szabályozhatjuk a teljes fájlra. Ilyenkor az állományt el ször megnyitó folyamat definiálhatja, hogy a kés bbi megnyitási kérelmekb l mit engedélyezhetünk: például kizárólagos használatot kérünk, azaz több megnyitást nem engedélyezünk. Esetleg megengedhet hogy a többi folyamat az állományt csak olvassa; legáltalánosabb esetben pedig egy vagy több folyamat is megnyithatja írási joggal.

I. Multiprogramozott operációs rendszerek

83

Ha az állományt legalább egy folyamat írhatja, a fájlkezel rendszernek definiálni kell, hogy az olvasó folyamatok az állomány változását mikor veszik észre: azonnal, vagy csak azután, hogy az író folyamat lezárta az állományt, addig a régi tartalmat látják.

Az egész állományra vonatkozó kölcsönös kizárás néha túlzottan, megengedhetetlenül óvatos, hiszen egyéb folyamatok az állományhoz csak lezárása után férhetnének hozzá. Amelyik folyamat az állományban összetartozó információt akar elérni - írni vagy olvasni -, akkor ez(eke)t, mint önálló er forrásokat lefoglalja - illetve várakozik, amíg felszabadul(nak) -, majd az átvitel lezajlása után a lefoglalt rekordo(ka)t felszabadítja. Természetesen akár több egyidej leg írási joggal rendelkez folyamat is létezhet, a kölcsönös kizárás csak egyes kijelölt rekordokra vonatkozik. Az állomány módosítását a többi folyamat a módosított rekordok felszabadítása után azonnal látja.

Sajnos a kölcsönös kizárás miatt itt is felléphet a holtpont vagy a kiéheztetés veszélye.

I.4.3.6. A hozzáférés szabályozása

Mivel az operációs rendszer általában több felhasználó állományait tárolja, kezeli, felvet dik az az igény, hogy jogosulatlan felhasználók ne férhessenek hozzá minden állomány tartalmához, illetve ne végezhessenek rajtuk bizonyos m veleteket.

A hozzáférési jogokat az állomány létrehozója vagy az állomány felett speciális jogokkal rendelkez felhasználó definiálhatja. Megjegyzés: az állományokat folyamatok hozzák létre, a "létrehozó" vagy az a felhasználó, aki a folyamatot elindította, vagy a folyamathoz tartozik egy fix felhasználó. A hozzáférési jogok általában az egyedi fájlokhoz, esetleg egész könyvtárakhoz tartoznak. Néha azonos fájlokat több néven, több hozzáférési úton is elérhetünk, ilyenkor a jogosultságokat rendelhetjük mind a konkrét fájlhoz, mind az elérési útvonalhoz. A jogosultságok azt szabályozzák, hogy a rendszer egyes felhasználói milyen m veletek elvégzésére jogosultak. Amennyiben a rendszernek túl sok felhasználója van, célszer a jogosultságokat felhasználói csoportokhoz rendelni.

I. Multiprogramozott operációs rendszerek

84

Fájlokhoz rendelhet tipikus jogosultságok: írás, olvasás, hozzáírás, végrehajtás, törlés, míg könyvtárakra vonatkozóan megengedhet módosítás, törlés, listázás, keresés, új állomány létrehozása.

I.5. Készülékkezelés

A számítógépeken futó alkalmazások jelent s része B/K intenzív, azaz a számítógép feldolgozó képességét els sorban küls eszközökkel (perifériákkal) folytatott szervezett,

rendezett adatcserére használja. A be/kiviteli eszközök hatékony m ködtetése ezért az operációs rendszerek egyik legfontosabb feladata. A számítógépeket a legváltozatosabb készülékek veszik körül, amelyek mindegyike speciális kezelést igényel.

Az operációs rendszer feladatai az I/O kezelésben:

· egységes alkalmazói felület kialakítása (application interface)

Ennek keretében el kell takarni a részleteket, minél inkább egységesíteni a m veleteket, lehet vé tenni a logikai perifériakezelést, a m veletek átirányíthatóságát.

· egységes csatlakozó felület kialakítása a készülékek számára (device interface)

A perifériák fizikai csatlakoztatása a hardver architektúra meghatározott helyein, egyszer bb, vagy bonyolultabb vezérl k csatlakozási pontjaira történhet. Egyszer bb eszközök és szabványos I/O vezérl esetén az operációs rendszer eleve tartalmazza a vezérl egység kezel programját, a m ködésbe helyezéshez csupán néhány paramétert kell megadni. Bonyolultabb, új eszközök esetén az operációs rendszerhez való illesztés egy speciális kezel program (device driver) beillesztését igényli a rendszerbe, amelyik a periféria minden sajátosságát ­ beleértve a fizikai csatlakoztatás módját és adatait is ­ ismeri. A kezel program és az operációs rendszer illesztési felületét ezért egységes, specifikált felületként kell kialakítani.

I. Multiprogramozott operációs rendszerek

85

· a készülékek hatékony m ködtetése

Ennek keretében meg kell oldani a perifériák ütemezését és az átvitelek szimultán lebonyolításában a programozottan végrehajtandó feladatokat (megszakítás-kezelések, vezérl egységek felprogramozása, állapotellen rzések, hibakezelések, pufferelések stb.).

Ezek a feladatok az operációs rendszer bels szerkezetét is meghatározzák, és jellegzetesen a xx. ábrán bemutatott rendszerstruktúrára vezetnek.

alkalmazói felület kernel

kernel I/O alrendszer SW

kezelõprogram 1

kezelõprogram 2 ... ...

...

kezelõprogram n

készülékvezérlõ 1 HW

készülékvezérlõ 21

...

készülékvezérlõ 2p

készülékvezérlõ m

készülék 1

készülék 21

készülék 2p1

...

készülék 2pq

készülék m

xx. ábra

A rendkívül heterogén perifériakészlet részletkérdéseit l elvonatkoztatva az alkalmazói felület a be/kivitelre egységes, néhány paraméterrel leírható m veleteket ad.

I. Multiprogramozott operációs rendszerek

86

A kernel I/O alrendszere már valamelyest megosztottabb, az ábrán nem jelölt alrétegekre és modulokra osztható, amelyek szükség szerint ütemezéseket, puffereléseket, blokkosításokat végeznek. A rendszerben több azonos típusú eszköz m ködhet. Ezek illesztési módja, vezérl egysége eltér lehet. A legegyszer bb esetben egy perifériához egy vezérl egység és ahhoz egy

kezel program (device driver) tartozik. Egy kezel programmal m ködtethetünk több vezérl egységet, azon belül több perifériát. Ilyen esetekben is mindig vannak azonban a kezel programnak legalább is olyan adatszerkezetei, amelyek a perifériákra nézve egyediek. A perifériák m ködtetésének részleteit csak a kezel programjuk ismeri. Ezért minden perifériatípushoz külön kezel program tartozik. Egy rendszeren belül a kezel programok és a kernel csatlakozási felülete szabványos, rendszerenként azonban jelent sen eltér lehet. Ha egy új perifériát vásárolunk és csatlakoztatjuk a rendszerünkhöz, egy megfelel kezel programot is telepítenünk kell hozzá, amit vagy az operációs rendszer szállítója készített és a rendszerkönyvtárban megtalálható, vagy a periféria szállítója mellékelt a különböz operációs rendszereknek megfelel en több változatban.

Az egységes alkalmazói felületen a készülékekr l a III. fejezetben bemutatott kép rajzolódik ki. Hogyan valósítja meg ezt a modellt a kernel I/O alrendszere? Ezt mutatjuk be a következ kben, majd a legbonyolultabb készülékek egyikének, a mágneslemeznek a kezelésével foglalkozunk, és megmutatjuk a hatékony kezelés érdekében kialakult megoldásokat.

I.5.1. A kernel I/O alrendszere
A kernel I/O alrendszerének jellegzetes feladatai:
· perifériák ütemezése · átmeneti és gyorsítótár m ködtetés · perifériahasználat koordinálása · hibakezelés

A perifériák ütemezése annak a végrehajtási sorrendnek a maghatározását jelenti, amelyet a perifériára várakozó átviteli kérelmek végrehajtására alkalmaz a rendszer. Az érkezési

I. Multiprogramozott operációs rendszerek

87

sorrendt l való eltérés bizonyos esetekben jelent sen javíthatja a perifériahasználat hatékonyságát. Erre egy példát a következ kben a diszkm veletek ütemezésének bemutatásakor látunk.

Átmeneti tárolást (pufferelést) alkalmaz a kernel, ha
· két eltér sebesség adatfolyamot kell összekapcsolni (gyakran kett s puffert

alkalmazva)
· a periféria számára blokkosítás szükséges és az alkalmazás nem blokkokkal

dolgozik, vagy más blokkméretet használ
· az adatküld m velet szemantikája csak átmeneti tárolással biztosítható (a m velet

visszatérése után az elküldött példány módosítható legyen).

Háttértárak esetén gyorsító tár alkalmazása is jelent sen növelheti a hatékonyságot, ha ismétl d írások/olvasások jellemzik a perifériahasználatot. (Az átmeneti tároló és a

gyorsítótár közötti lényeges különbség, hogy a puffer az egyetlen létez kópiát tárolja az adatról, a gyorsítótár pedig a háttértáron lév adat egy másolatát.)

A perifériahasználat koordinálása tekintetében az egyszer I/O m veletek sorbaállítása csupán ezeknek a m veleteknek az oszthatatlanságát garantálja. Külön megoldást kell találni azoknak a perifériáknak a kezelésére, amelyek hosszabb távú oszthatatlan m veletekkel kezelhet k hatékonyan. Ilyen például a nyomtató vagy a mágnesszalag, amelyekre az alkalmazások az összetartozó adatokat általában nem tudják egyetlen I/O m velettel elküldeni. A probléma egyik megoldása, hogy ezekhez a perifériákhoz egy speciális puffert ­ spoolt ­ rendelnek. Egy folyamat által a perifériára küldött adatokat el ször egy spool-fájlban gy jtik össze. A kész fájlokat aztán egyenként másolják ki a perifériára. Így a fájlon belüli sorrendek meg rz dnek. Más rendszerek a kizárólagos perifériahasználat kérésére biztosítanak eszközöket (lefoglalás, felszabadítás).

Az I/O m veletek közben el forduló hibákat a kezel programok, vagy az operációs rendszer észleli. Mindkét észlelési szinten megkísérelhet a tranziensnek vélt hibák kiküszöbölése a m velet, vagy részm velet ismétlésével. Más hibatípusok esetén az operációs rendszernek

I. Multiprogramozott operációs rendszerek

88

nincs javítási lehet sége. A hibát ilyenkor jelezni kell a magasabb szintek (a hívó) felé. A hibajelzés, azaz a m velet sikertelenségének, vagy sikerének visszajelzésére a könny kiértékelhet ség érdekében általában 1 bit szolgál. Hibajelzés esetén ezen kívül további kísér információk segítik a hiba okának behatárolását. A hibakezelés beépített folyamatában gyakran szerepel a kezel értesítése is. Az operációs rendszer ezt csak alkalmazás-független, általános kijelzésekkel tudja megtenni, ilyen információ megjelenése egy alkalmazás kezel ábráján rendkívül zavaró lehet. A beépített hibajelzéseket ezért a rendszer saját kezel szervére célszer irányítani, a hibát pedig jelezni kell az alkalmazás felé is, hogy az alkalmazáshoz ill reakciót tudja lejátszani.

I.5.2. Háttértárak kezelése
A számítógéprendszerekben azért alkalmaznak háttértárat, mert:
· a központi tár fajlagos, egy bitre jutó ára magas, ezért kapacitása viszonylag kicsi; · a központi tárban az információk a tápfeszültség kikapcsolásával elvesznek; · minél nagyobb a tárolási kapacitás, gyakorlati okokból annál nagyobb kell legyen az

egyedileg megcímezhet információ-egység mérete.

A hardver fejl désével a következ típusú háttértárak jelentek meg:
· mágnesszalag; · mágnesdob; · mágneslemez; · optikai adatrögzítés (lemez szervezés ; csak olvasható (pl. CD-ROM), egyszer írható

(WORM), illetve írható-olvasható lemezek);
· egyéb (kísérleti jelleg ) megoldások: · mágnesbuborék tár; · félvezet tárak, (EEPROM, memória kártya); · holografikus tárolás.

A háttértárak fizikai kezelése adott esetben igen bonyolult feladat. Az operációs rendszerek törekszenek a különböz típusú tárolóeszközök egységes kezelésére. Az operációs rendszer háttértár kezel egysége az operációs rendszer többi komponense felé a háttértárakat

függetlenül elérhet adattároló blokkok sorozataként mutatja. A háttértár kezel k m ködését a

I. Multiprogramozott operációs rendszerek

89

jelenlegi rendszerek legelterjedtebb háttértára esetén, a mágneslemezes tár (magnetic disc) kezelésén keresztül mutatjuk be.
I.5.2.1. A lemezegység fizikai szervezése

A mágneslemezes egység m ködésének lényege, hogy a tárcsaszer , forgó mágneses hordozó felett - oldalanként egy - író-olvasó fej mozog, a fejek mozgatását közös mechanika végzi. Általában a lemezek mindkét oldalát használják, a lemez felett és alatt is található fej. A mágneslemez sematikus felépítését az 1. ábra mutatja.

5. ábra ­ Mágneslemezegység felépítése

Az 1. ábrán látható elnevezések magyarázata: Sáv (track) egy-egy lemezfelület azon területe, amelyet a fej elmozdulás nélkül, a lemez egyetlen körülfordulása alatt elér. Cilindernek (cylinder) nevezik a fejtartó szerkezet egy adott pozíciójában leolvasható sávok összességét. Egy-egy sávot - általában sávonként azonos méret , gyakorta az összes sávon azonos számú, azonos szögtartományt elfoglaló - szektorra (sector) osztják. Az információtárolás a szektoron belül bitsoros. A szektor az információátvitel legkisebb egysége, a lemezvezérl egyszerre egy teljes szektort olvas vagy ír. A modern lemezeken a szektorok elhelyezkedését a vezérl a sávra felírt speciális mágneses jelekb l ismeri fel.

A mágneslemez egységek lemezei lehetnek fixek, de cserélhet lemezek (pl. hajlékony lemez,
floppy disc) is használatosak.

Átvitel kiszolgálásának ideje a következ összetev kre osztható:
· a fejmozgási id (seek time) az az id , amíg a fej a kívánt sávra áll; · az elfordulási id (latency time) az az id , amíg a kívánt szektor a fej alá fordul. · az információ átvitelének ideje (transfer time).

A felsorolt id k között nagyságrendi különbségek vannak, a fejmozgási id a leghosszabb.

I. Multiprogramozott operációs rendszerek

90

Szektorok címzése: A lemez szektorait az operációs rendszer lineárisan címzi, a lemezilleszt viszont több komponens - több dimenziós - címet igényel. A kett között az összefüggés:
b = s * (i * t + j) + k

ahol s a sávon lév szektorok száma, t a cilindereken lév sávok száma, i a kijelölt cilinder, j a fej (lemez felület) száma, k pedig a sávon belüli szektorok száma (i, j, és k értékei 0-tól indulnak). A b eredmény a szektor lineáris, 0-tól induló sorszáma.
I.5.2.2. A lemezm veletek ütemezése

A multiprogramozott rendszerekben egyszerre több folyamat verseng a mágneslemezes perifériákért, egy átvitel lezajlása után több újabb kérés várakozhat kiszolgálásra. Az ütemezési algoritmusok a kérések megfelel sorrendbe állításával az egyes folyamatok rovására

próbálják a várakozási id k csökkentésével a rendszer teljesítményét növelni. Az algoritmusok célja a fejmozgás optimalizálása, vagy az elfordulási várakozás csökkentése.

Az algoritmusok értékelésének szempontjai:
· átbocsátó képesség, id egység alatt lebonyolított átvitelek száma; · átlagos válaszid , egy átvitel kérését l a végrehajtásáig eltelt átlagid ; · válaszid szórása; · els sorban interaktív rendszerekben fontos szempont, hogy a folyamatok el re látható

sebességgel fussanak, a futásuk ne ingadozzon nagyon rajtuk kívül álló okok miatt. Az algoritmusok értékelésénél az átviteli kérések címének egyenletes eloszlását tételezzük fel.
(1) A fejmozgás optimalizálása

Sok algoritmus képzelhet el, az itt következ felsorolás csak néhány ismertebb alaptípust vizsgál.
Sorrendi kiszolgálás (First Come First Served, FCFS):

Az átviteli kéréseket érkezésük sorrendjében szolgáljuk ki. Az algoritmus nem tör dik a fej mozgásával, kicsi az átbocsátó képessége, nagy az átlagos válaszideje, de ennek szórása viszonylag kicsi.
Legrövidebb fejmozgási id (Shortest Seek Time First, SSTF):

Az algoritmus következ nek azt a kérést szolgálja ki, amelyik az aktuálishoz legközelebb lév cilinderre hivatkozik - ennek az eléréséhez szükséges a legkisebb fejmozgási id . Bár

I. Multiprogramozott operációs rendszerek

91

teljesítménye az FCFS-nél jobb, de a válaszid k szórása nagy, s t fennáll a kiéheztetés veszélye: egy távoli cilinderre vonatkozó kérést az újra és újra érkez közeli kérések nem meghatározható ideig késleltethetik.
Pásztázó (SCAN):

Az algoritmus a következ kérés kiválasztásánál csak azokat a kéréseket veszi figyelembe, amelyekhez szükséges fejmozgás az aktuális mozgási iránynak megfelel . A mozgási irány akkor fordul meg, ha az aktuális irányban már nincs több kiszolgálatlan kérés. Az algoritmus teljesítménye jobb, mint az SSTF, a válaszid szórása is kisebb. A pásztázásból következ sajátossága, hogy a középs cilindereket gyakrabban látogatja, mint a széls ket.
N lépéses pásztázó (N-SCAN):

Egy irányba mozogva csak azokat a kéréseket - közülük is csak N-et - szolgálunk ki, amelyek a pásztázás elején már megvoltak. A pásztázás közben érkez kérésekre csak a következ irányváltás után kerül sor. Az algoritmus válaszidejének szórása kisebb a

SCAN-nél is, a válaszid akkor sem n meg, ha az aktuális cilinderre sok kérés érkezik.
Egyirányú (körforgó) pásztázó (Circular SCAN, C-SCAN):

A kérések kiszolgálása mindig csak az egyik irányú fejmozgásnál történik, a másik irányban a fej közvetlenül a legtávolabbi kérés cilinderére ugrik. Implementálható a pásztázás közben beérkezett kérések mind menet közbeni, mind a következ pásztázásra halasztott kiszolgálásával. Az algoritmus elkerüli a küls szonyított alacsonyabb fokú kiszolgálását. sávoknak a bels khöz vi-

Egyes rendszerekben a lemez terhelésének függvényében különböz kalmaznak, például:
· alacsony terhelésnél SCAN, · közepes terhelésnél C-SCAN, · nagy terhelésnél az elfordulási id optimalizálásával b vített C-SCAN.
(2) Az elfordulási id optimalizálása

módszereket al-

Az egy cilinderen belüli kérések a lemezek aktuális pozíciójának, valamint a szektorok sorrendjének - ami nem mindig monoton növekv (szektor közbeékel dés, sector interleave) ismeretében kiszolgálás el tt sorbaállíthatók.

I. Multiprogramozott operációs rendszerek

92

I.5.2.3. Egyéb szervezési elvek a teljesítmény növelésére

Lemezterület tömörítése (disk compaction): Az egymáshoz tartozó blokkokat lefoglaláskor a lemezen fizikailag is egymás mellé igyekszünk elhelyezni, illetve ezt az állapotot egy id nként futtatott rendez programmal elérni. A lemezm veleteknél is megfigyelhet lokalitás következményeként egy folyamat

várhatóan az egymáshoz közeli - egymást követ - blokkokat fogja olvasni, így a fejmozgás minimális lesz. A tömörítés nem mindig vezet teljesítményjavuláshoz, hiszen egy multiprogramozott rendszerben egy id ben sok folyamat használja a lemezt.

A gyakran szükséges adatokat SCAN típusú ütemezésnél érdemes a lemez középs sávjain elhelyezni.

A gyakran szükséges adatokat a lemezen több példányban, különböz sávokon helyezzük el, így minden fejállásnál kiválaszthatunk egy viszonylag közel lév cilindert, ahol a kívánt adat megtalálható. A módszer els sorban nem - vagy csak nagyon ritkán - változó adatoknál használható, hiszen valamennyi példány módosítása hosszú id t jelentene, és módosítás közben az adatok konzisztenciájának biztosítása is megoldandó.

Több blokk egyidej átvitele Mivel a kérések kiszolgálásának jelent s része a fejmozgásból ered várakozással telik, ha már a megfelel pozíción vagyunk, igyekezzünk minél több blokkot egyszerre átvinni és azokat a memóriában tárolni.

Blokkok átmeneti tárolása A gyakran vagy a közeljöv ben várhatóan szükséges blokkokat igyekezzünk a központi-, esetleg a perifériailleszt ben lév tárban tartani (disk cache). Az átmeneti tárolás közben foglalkozni kell a megváltozott tartalmú szektorokkal:
· a tárban változással egyidej leg a lemezre is felírjuk (write through cache) vagy · csak akkor írjuk ki, ha a tárra szükség lesz.

Ez utóbbi a nagyobb teljesítmény módszer, hiszen egy gyakran változó szektor kiírás el tt újra megváltozhat, viszont kevésbé biztonságos, hiszen a rendszer meghibásodása esetén a szükséges módosítások nem kerültek a lemezre.

I. Multiprogramozott operációs rendszerek

93

Adattömörítési (data compression) eljárások használata: A lemezen az információt tömörített (compressed) formában tároljuk, visszaállítása - a programozó számára láthatatlanul - csak a beolvasásakor történik meg. ly módon csökkenthet a szükséges perifériás átvitelek száma. A tömörítést és visszaállítást a

perifériakezel program vagy célhardver végezheti.
I.5.2.4. Az adattárolás megbízhatósága

Adatok mentése (backup): A lemez teljes vagy az el z mentés óta megváltozott tartalmát (incremental backup) id nként más - általában mágnesszalagos, újabban optikai lemezes - háttértárra kell kimásolni, ahonnan a lemez sérülése, a tárolt adatok véletlen törlése esetén az egész, illetve a szükséges részek visszaállíthatók.

Átmeneti tár és a háttértár tartalmának szinkronizálása: Az átmeneti tárban lév ,,fontosabb" változásokat, esetleg id nként az összes változást a lemezre kell írni (sync a UNIX-ban).

Lemezegységek többszörözése:
· kétszerezés (disk shadowing, mirroring)

Az írásokat egyszerre mindkét lemezen elvégezzük, így a két lemez pontosan azonos információt tárol, az egyik kiesése esetén a másik még használható.
· többszörözés

Egy nagy kapacitású lemezegység helyett több kicsit használnak, amelyekre az információt hibajavító kódolással - legegyszer bb esetben paritásbittel - megtoldva szétterítik. így egység(ek) kiesése esetén a tárolt információ még visszaállítható. (Redundant Array of Inexpensive Disks, RAID)

I.6. Operációs rendszerek kezel i felülete

I. Multiprogramozott operációs rendszerek

94

Az operációs rendszerek kezel i felülete felel s a felhasználóval történ kapcsolattartásért. A kezel i felületek tipikus feladatai a következ k:
· Felhasználói parancsok bevitele, értelmezése. · Parancsok végrehajtása. · Eredmények, ill. esetleges hibák közvetítése, megjelenítése.

A felhasználók által használható parancsok típusai:
· Bels parancsok:

Közvetlenül az operációs rendszer kezel i felülete hajtja végre a parancsot.
· Tárolt (küls ) parancsok:

Az operációs rendszer kezel i felülete egy önálló programként megvalósított parancsot hív meg. Ezeket a parancsokat két csoportra oszthatjuk:
· Rendszer parancsok

A parancs az operációs rendszerrel együtt szállított parancsok. Minden felhasználó azonos parancsot ér el.
· Felhasználói parancsok:

A felhasználó önmaga fejlesztette a parancsot.

A kezel i felületek fejlesztésekor a legfontosabb szempont a felhasználóbarát tulajdonság megvalósítása. Ez els sorban széleskörben használt rendszerek esetén okoz gondot, mert a rendszer felhasználói köre nagyon heterogén lehet, vagyis az egyes felhasználók eltér igényeket támasztanak a rendszer elé.

A kezd , tapasztalatlan felhasználó igényei általában a következ k:
· Kis számú és egyszer parancsok. · Biztonságos parancsok, amelyek nem okozhatnak súlyos és visszaállíthatatlan

változást a rendszerben, ill. meger sítést kérnek minden ilyen akció el tt.
· Részletes, és környezetfügg segítség minden szituációba.

A tapasztalt felhasználó igényei ezzel szemben:
· Hatékony, a rendszer minden lehet ségét kihasználó parancsok.

I. Multiprogramozott operációs rendszerek

95

· Konfigurálható parancsok, amelyeket a felhasználó saját igényeinek megfelel en

meg tud változtatni.
· A felhasználó által b víthet parancs készlet.

A fenti igények láthatóan több ponton ellentmondanak egymásnak. Ez természetesen lehetetlenné teszi, hogy egy minden igényt kielégít felhasználói interfészt készítsünk. A felhasználói interfész fejlesztésénél általában valamilyen kompromisszumot kell kötni a fenti szempontok között. Gyakran alkalmazott megoldás, hogy a felhasználói interfész valamilyen paraméter állításával lehet séget ad a felhasználó tapasztaltságának beállítására, ezzel biztosítva a felhasználó igényeihez való igazodását.

Az operációs rendszerek és a felhasználó közötti kommunikáció eszközei: Nem interaktív rendszerekben: Job Control Card Interaktív karakteres interfészt biztosító rendszerekben: billenty zet (keyboard) karakteres terminál (display) Grafikus be/kimenetet kezel rendszerekben: egér fényceruza érint képerny (touch-screen) grafikus terminál (display) Speciális rendszerekben: hang be/kimenet

A fenti felsorolás a rendszerek fejl dését is mutatja. A számítógépek kapacitásának gyors fejl désével az operációs rendszerek mind nagyobb súlyt fektettek a felhasználói felületek fejlesztésére. A fejl dés els lépcs je az interaktív rendszerek megjelenése volt, majd a grafikus interfészt biztosító rendszerek következtek. A mai napig is tart az emberi kommunikációra mindinkább hasonlító kezel i felületet biztosító rendszerek fejlesztése. A beszédfelismerésen ill. beszéd szintézisen alapuló kommunikációt biztosító rendszerek egyre

I. Multiprogramozott operációs rendszerek

96

nagyobb teret hódítanak, hiszen alapvet beszédfelismerési funkciókat akár egy mobiltelefon kínálta számítási kapacitással is lehetséges megvalósítani. A továbbiakban egy konkrét példán, az X Window rendszeren keresztül mutatjuk be egy grafikus interfész felépítésének és m ködésének részleteit.

I.6.1. Az X Window rendszer

Az X Window egy olyan rendszer, mely grafikus kimenettel rendelkez

alkalmazások

felhasználói felületének kialakítására ad lehet séget. A rendszer fejlesztése 1983-84-ben kezd dött a Massachusetts Institute of Technology-n (MIT, USA). A fejlesztés célja olyan kommunikációs felület készítése volt, ami azonos kezel i felületet biztosít a hálózattal összekötött, különböz operációs rendszereket futtató számítógépeken. Az X Window

segítségével lehet ség van az alkalmazás és a kezel i felület szétválasztására. Míg a kezel i felületet a helyi gépen futó X szerver jeleníti meg, addig az alkalmazás akár távoli gépeken is futhat. A rendszer gyors elterjedését számos el nyös tulajdonságán túl segítette, hogy az X Window forráskódja publikus. Az X Window-t els sorban a UNIX rendszerek támogatják. Az X Window m ködésének jellemz je a kliens-szerver modell használata. A szerver egy grafikus terminálon futó folyamat, mely grafikus ki- és bemeneti lehet séget biztosít a kliens folyamat számára. A szerver kezeli az ún. grafikus munkahelyet, melynek részei:
· a képerny (ill. képerny k), · a billenty zet (alfanumerikus bemeneti eszköz), és · egy grafikus bemeneti eszköz.

A kliens egy grafikus be/kimenetet igényl (általában interaktív) folyamat.
I.6.1.1. Az X protokoll

A rendszer magja az X protokoll, amely definiálja a kliens és a szerver együttm ködésének módját. Leírja a lehetséges grafikus funkciókat, valamint a megengedett akciókat. A protokoll kétirányú aszinkron kommunikációt tesz lehet vé, vagyis mind a kliens, mind a szerver küldhet üzeneteket. Az üzenetek küldése után egyik fél sem várakozik visszajelzésre, hanem folytatja m ködését.

I. Multiprogramozott operációs rendszerek

97

Az üzenetek típusai a következ k lehetnek:
· Kérés (kliens küldi a szervernek). · Válasz (szerver küldi a kliensnek). · Esemény (szerver küldi a kliensnek). · Hiba (szerver küldi a kliensnek).

A protokoll legfontosabb jellemz je, hogy a hálózati kommunikáció mérséklésére törekszik. Ennek módjai:
· A kliens nem egyes üzeneteket, hanem üzenetek összegy jtött csomagját küldi át a

hálózaton.
· A szerver helyben kezel bizonyos egyszer eseményeket, mint pl. az egérmozgatást. · A szerver szoftver er forrásokat (grafikus környezetet, bet típushoz tartozó leírást,

stb.) hoz létre a kliens kérésére, amiket kés bb a kliens folyamat egyszer hivatkozással érhet el.
I.6.1.2. Az X Window rendszer koncepciója

Az X környezet alapvet eleme a grafikus, ún. X munkahely, mely egy X display-b l (X megjelenít b l) és az azon lev (egy vagy több) X screen-b l (X képerny b l), valamint bemeneti eszközökb l áll. Az X munkahely egy karakteres bemeneti eszközt (általában billenty zet) és egy pozicionálásra alkalmas grafikus bemeneti eszközt kezel. A grafikus bemeneti eszköz leggyakrabban egér, de lehet fényceruza vagy érint képerny is.
I.6.1.3. Ablakkezelés

A grafikus képerny kezelése ablakok létrehozásával történik. Az ablak egy téglalap alakú képerny részlet, melyben a felhasználó újabb ablakokat nyithat, vagy az egyes ablakok területére rajzolhat. Az ablakok rendszere hierarchikus. A kliens a m ködése elején nyit egy ún. gyökér ablakot. Az összes többi ablaka ennek az ablaknak lesz leszármazottja. Az ablakok mozgathatók a képerny n. A leszármazott ablakok területe csak az sük ablakfelületén látszik. A kilógó vagy esetleg átlapolódó, egymást fed ablakoknál a rendszer automatikus vágást alkalmaz. Egy ablakfelület kitakaráskor (láthatóvá válásakor) a szerver ún. kitakarás eseményt küld a kliens

I. Multiprogramozott operációs rendszerek

98

folyamatnak, lehet séget adva annak tartalmának frissítésére. A kliens külön kérésére a szerver támogathatja az ablak automatikus, szerver által megvalósított frissítését.
I.6.1.4. Bemeneti eszközök kezelése

A bemeneti eszközöket az X szerver figyeli. Az eszközök állapotváltozásakor (pl. egy billenty vagy egér gombjának leütésekor) a szerver esemény üzenettel értesíti a klienst. A bemeneti információ elosztására az X Window rendszer bevezette az ún. input focus fogalmát. Az input focus birtokosa az a kitüntetett kliens folyamat, amelyik a bemeneti eszközök állapotváltozásakor a szerver által értesítend . Az input focus-t mindig egy folyamat birtokolja, és a szerver által definiált módon adható át, ill. kérhet el a kliensek között. Pozicionáló eszköz mozgásáról a kliens az aktív ablak bal fels sarkától számított relatív koordinátákban mért információt kap a szervert l. Karakteres bevitel esetén a billenty khöz történ karakter-hozzárendelést a szerver végzi, azonban a kliens kérésére a szerver

megváltoztathatja az aktuális karakter-hozzárendelést.
I.6.1.5. Megjelenít eszköz kezelése

Az X Window ún. raszteres (képpontokból, pixelekb l álló) grafikus terminált tud kezelni. Az ablakok helyét a képerny bal fels sarkától számolt derékszög koordináta rendszerben tartja számon. Az ablakok és egyéb rajzelemek elhelyezkedését képpontokban méri. Az ablakon belüli rajzelemek elhelyezkedését az ablak bal fels sarkától mért relatív koordináták szerint tárolja. Rajzoláskor az X egyszer , el re definiált rajzelemek használatát engedi meg. A rajzelemek halmaza azonban b víthet a felhasználó által. Rajzolni mind a képerny re, mind pedig (virtuálisan) a memóriába lehetséges. Virtuális rajzolással a kliens karban tarthatja az esetlegesen latakart képerny jének tartalmát, melyet majd a kitakarás esemény után frissíthet. Az X Window a színek használatát ún. palettázással támogatja. A kliens egy 128-elem paletta színeit definiálhatja a szerver által biztosított színtartományban, mely általában igen széles. A palettahasználat el nye, hogy egy palettaszín definiálása után a kliens egy nyolcbites azonosítóval hivatkozhat egy színre, mely szín ábrázolására a szerver 16, 24, vagy akár 32 bitet is használhat. A paletta színein az azonos képerny n futó alkalmazások osztoznak. Ha egy alkalmazásnak nem elegend a palettában megmaradt színek száma, kérheti a szervert, hogy biztosítson számára egy külön palettát. Ez a felhasználó számára is szembet n , mert

I. Multiprogramozott operációs rendszerek

99

ebben az esetben a képerny színei megváltoznak, attól függ en, hogy az önálló palettát használó vagy valamelyik másik, közös palettát használó folyamat birtokolja az input focus-t.
I.6.1.6. A kezel i felület elemei

Egy m köd X rendszernek három f eleme van:

Windowing system:

A rendszernek ez az eleme felel s az X protokollt megvalósításáért, vagyis ez a rendszer magja. Lebonyolítja a kommunikációt a kliensekkel, elvégzi a megjelenítési funkciókat.

Window manager:

A Window manager egy kitüntetett kliens folyamat, ami az ablakok felhasználó által történ manipulálását intézi. Minden Windowing system-hez csak egy Window manager kapcsolódhat. A Window manager által támogatott m veletek az ablakokkal:
· mozgatás · méretezés · zárás · ikonizálás · menü biztosítása

A Window manager minden ablakot ellát az ablakok kezelését (mozgatását, ikonizálását, stb.) megkönnyít tartozékokkal. A tartozékok kinézete, ill. a biztosított funkciók az adott X megvalósítástól függ en különbözhetnek.

Session manager:

A Session manager egy állandóan futó X szerver esetén a felhasználó beléptetését intézi a grafikus képerny n. Opcionális része a rendszernek. Session manager használata esetén a felhasználók nem a megszokott karakteres login promptot használják belépéskor, hanem a Session manager által biztosított grafikus környezetet. A Session manager funkciója a felhasználó kényelmének növelésén túl annak a lehet ségnek biztosítása, hogy a felhasználó választhasson az adott rendszerben

I. Multiprogramozott operációs rendszerek

100

rendelkezésre álló Window manager-ek között, vagyis lehet vé tegye a felhasználónak a grafikus környezetének beállítását.

V. fejezet

I. HÁLÓZATI ÉS ELOSZTOTT RENDSZEREK

I.1. Bevezetés

Mára a számítógépes hálózatok, az elosztott rendszerek szerves részét képezik életünknek. Ebben nagy szerepet játszott az Internet, ami az elmúlt közel két évtizedes élete során százmilliókat ismertetett meg a számítógépes hálózatokkal és elosztott rendszerekkel. Bár ezen felhasználók nagy része valóban csak felhasználó, azonban ez a hatalmas érdekl dés a fejlesztésnek, az új m szaki megoldások kutatásának is nagy lendületet adott.

A számítógépes hálózatok és elosztott rendszerek gyors terjedésével egy újfajta számítási, feldolgozási módszer alakult ki. Míg kezdetben, a hálózatok alkalmazása el tt a számítási modell nagyon egyszer volt: az adott feladatot egyetlen gép számítási kapacitásával kellett megoldani, addig a hálózatok megjelenésével a modell b vülhetett, a számítások elvégzésére már több együttm köd processzort, vagy számítógépet tartalmazó elosztott rendszer áll

rendelkezésre. Ez a változás persze nem robbanásszer en ment végbe. Kezdetben a számítógépek összekapcsolásának els dleges célja az adatok számítógépek közötti továbbítása volt. Azonban nagyon hamar felismerték, hogy az elosztottság több el nnyel is kecsegtet: egyrészt a terheléselosztás megvalósítása, másrészt pedig hibat r viselkedés,

nagyobb rendelkezésre állás, és más hasonló szolgáltatások területén is nagy el relépést jelenthet. A 80-as évek közepére kialakult a ma is egyik legelterjedtebben alkalmazott számítási modell, az elosztott architektúra nyújtotta el nyeit kihasználó kliens-szerver modell. Ebben a megközelítésben a rendszerünkben bizonyos kitüntetett feladatokat egy-egy adott szerver végez el a kliensek kérésére. Amennyiben például egy állományhoz szeretnénk hozzáférni, akkor azt egy file szerver, ha nyomtatni szeretnénk, akkor azt egy nyomtató szerver tudja a számunkra biztosítani. A kliens-szerver modell mellet megjelentek az objektum orientált számítási modellek is.

1

V. fejezet

Az elosztottság az operációs rendszerekkel szembeni elvárásainkat is módosította. Az elosztott operációs rendszer egyik f feladata, hogy egy elosztott rendszerben lehet vé tegye annak kényelmes programozását, és ne korlátozza a rajta megvalósítható alkalmazások körét. Ehhez az elosztott rendszerben rendelkezésre álló er forrásokat az alkalmazások számára általános, probléma-orientált absztrakciókkal írja le. Például a hálózatok és processzorok helyett engedje meg, hogy a felhasználó kommunikációs csatornákban és folyamatokban gondolkodjon. Egy nyílt elosztott rendszerben az elosztott operációs rendszer mikrokernelek és szolgáltatások halmazából épül fel. Nem lehet éles határvonalat húzni az operációs rendszer és a rajta futó alkalmazások között. Ebben az esetben a határvonal még inkább elmosódott, mint a hagyományos operációs rendszerek esetén.

Az elmúlt években számos kutatás foglalkozott az elosztott operációs rendszerek kérdéskörével. Ezek közül néhány, mint például a Mach és a Chorus, mind m szaki, mind pedig kereskedelmi szempontból is az érdekl dés középpontjába került, az általuk felvetett m szaki megoldások számos ponton radikálisan új megoldásokat kínáltak. Az Amoeba, a Clouds és a V rendszerek szintén elosztott operációs rendszer kutatás eredményei, ezek els sorban érdekes m szaki megoldásaikkal hívták fel magukra a figyelmet. Mind az öt projekt egy ún. minimálkernelre, vagy mikrokernelre alapozta a rendszert.

Az V. fejezet az alábbi témákra bomlik:

Az V.2. fejezet bevezeti a hallgatót a hálózatok alapfogalmaiba, ismerteti a topológiák és a kapcsolatok alaptípusait és rámutat a név- és címkezelés legfontosabb problémáira és megoldásaira. Az V.3 fejezet ismerteti a hálózati alapszolgáltatásokat. Az V.4.1. fejezet részletesen ismerteti az elosztott rendszerek alapvet jellemz it, és a tervezésüknél

figyelembe veend legfontosabb tervezési szempontokat. Az V.4.2. részletesen tárgyalja az elosztottság hatását az egyik legfontosabb operációs rendszer komponensre, az

állományrendszerre. Bemutatja a fájlszerver modellt és példát ad a megvalósítási lehet ségekre. Az V.4.3. fejezet rámutat a folyamatkezeléssel szembeni elvárásokra elosztott környezetben, tárgyalja a kliens-szerver folyamatok, a távoli eljáráshívások, proxyk és

2

V. fejezet

démonok használatának el nyös tulajdonságait. A V.4.4 fejezet az id kezelésnek és a koordinációnak az elosztottságból ered problémáit és azok megoldásait szemlélteti. Az

elosztottság és a nyílt hálózatok egy jelent s problémát állítanak az el térbe: a biztonsági kérdéseket. Az új környezetben át kell gondolni a korábban alkalmazott biztonságpolitikát és biztonságtechnikai eszközöket, és ezeket hozzá kell igazítani az elosztott környezet követelményeihez. Az V.4.5. fejezet részletesen tárgyalja az elosztott rendszerek biztonsági kérdéseit, és ismertet egy kliens-szerver modellre épül hitelesít rendszert. Az V.5.

fejezetben az érdekl d olvasó egy kis ízelít t kap a rendszermenedzsment kérdéseib l, ami az elosztott, hálózati környezetben szintén felvet néhány problémás kérdést.
Megjegyzés: Ezek csak az automatikus számozás miatt vannak.

I.2. Hálózati architektúra
I.2.1. Alapfogalmak
A számítógép hálózat fogalma általában számítógépek és perifériák (pl. nyomtató) egy adott halmazának valamilyen eszközzel történ összekötését takarja. A kapcsolat lehet közvetlen (egy kábellel kialakított), vagy közvetett (a hálózati kapcsolat kialakítását segít eszközökön, például modemen keresztüli). A hálózatba kapcsolt komponenseket csomópontoknak nevezzük. A csomópontokat kommunikációs hálózatok kötik össze, melyek az átvitelt biztosító vonalakból és kapcsolóelemekb l állnak. Az átvitelt biztosító vonalak neve csatorna, vonal, vagy trönk. A kapcsolóelemek vagy a hálózatba kapcsolt gépek részei (pl. hálózati kártya), vagy önálló speciális berendezések (útvonalválasztók, hidak, stb.). A hálózati csomópontok

összekapcsolási rendje az ún. hálózati topológia. A hálózati adatcsere (kommunikáció) architektúrája réteges felépítés : a kommunikáció egyes szintjeit megvalósító algoritmusok egymástól elkülönülnek, közöttük interfészek biztosítják a kapcsolatot. A rétegek egymásra épülnek, a kapcsolatban részt vev két fél azonos szinten lev rétegei kommunikálnak egymással az alsóbb rétegek szolgáltatásait igénybe véve. Az azonos rétegek közötti kommunikációban használt adatformátumok és párbeszéd szabályok összességét protokollnak nevezzük.

3

V. fejezet

I.2.2. A hálózatok topológiája
A számítógép hálózatok csomópontjainak összekapcsolását, azaz a hálózat topológiáját többféle szempont szerint lehet értékelni. A csomópontok közötti kapcsolatok kiépítettsége, a kommunikáció sebessége és az adattovábbítás megbízhatósága a legfontosabb szempontok. A kapcsolat kiépítettsége szerint a hálózatokat két nagy kategóriába soroljuk: · Teljesen összekapcsolt (fully connected): A rendszert alkotó összes csomópont között közvetlen kapcsolat van. A kapcsolat kiépítésének költsége magas, négyzetesen arányos a csomópontok számával. A kommunikáció gyors, hiszen csak egy csatorna kell az üzenetnek a címzetthez juttatásához; megbízható, mivel a közvetlen csatorna meghibásodása esetén két csomópont között sok egyéb, más csomópontokat érint út van. · Részlegesen összekapcsolt (partially connected): Nincs minden csomópont-pár között közvetlen kapcsolat. A hálózat építésének költsége kisebb, mint a teljesen összekapcsolt esetben, de a kommunikáció is lassabb, egyes üzenetek csak több közvetít csomóponton keresztül juthatnak el a címzetthez. A hálózat egyes csatornák meghibásodására érzékeny lehet, a teljes hálózat több részhálózatra eshet szét, amelyekben lév csomópontok csak egymással tudnak üzenetet váltani, a másik részben lév kkel nem. A kritikus, könnyen meghibásodó csatornák mellé érdemes kerül utakat biztosítani.

5.2.1. ábra Teljesen és részlegesen összekapcsolt hálózat A részlegesen összekapcsolt hálózatok a következ alap topológiákból épülhetnek fel: · Hierarchikus: A csomópontok közötti kapcsolatok faszerkezet ek, minden csomópontnak - a legfels kivételével - van egy szül és néhány gyerek csomópontja. Csak a szül és a gyerekek

4

V. fejezet

tudnak közvetlenül üzeneteket váltani, a testvérek, rokonok csak a megfelel keresztül üzenhetnek egymásnak.

sökön

Egy csatorna vagy egy - üzenettovábbító - szül állomás kiesése esetén a hálózat részekre szakad. · Csillag (star): A csillag hálózatban van egy központi csomópont, amely az összes többi csomóponttal közvetlen kapcsolatban áll, a többiek viszont csak a központi csomóponthoz csatlakoznak, más közvetlen kapcsolatuk nincs. A kapcsolatok kiépítésének költsége viszonylag kicsi, két állomás közötti kommunikáció viszonylag gyors - csak a központi csomópont közrem ködését igényli -, viszont a központ kiesése esetén a csomópontok magukra maradnak, túl sok csomópont üzenetei pedig túlterhelhetik a központot.

5.2.2. ábra Hierarchikus és csillag összekapcsolás · Gy r (ring): A gy r olyan topológia, ahol minden csomópont pontosan két másikhoz kapcsolódik. Létezik egyirányú - ahol minden csomópont ugyanabba az irányba továbbítja az üzeneteket - illetve kétirányú gy r . A hálózat kiépítési költsége az állomások számával lineárisan arányos. Az üzenettovábbítás lassú, sok csomópont közvetítésére lehet szükség: legrosszabb esetben egyirányú gy r esetén n-1, kétirányú gy r nél n/2 átvitel kell. Egyirányú gy r nél egy, kétirányú gy r nél pedig két csomópont kiesése esetén szakad részekre a hálózat. Ez ellen kett zött gy r vel védekeznek. Ezzel együtt a gy r hálózatok rendkívül érzékenyek a csomópontok, vagy a köztük lév kapcsolatok kiesésére.

5

V. fejezet

5.2.3. ábra Gy r és kett zött gy r hálózat · Vezérjeles gy r (token ring): A gy r höz hasonló kialakítású hálózat, melyben egy hurkolt kábelközpontban történik a gépek összekötése (azaz minden gép egy központi egységbe csatlakozik). A vezérjel egy speciális adat, mely állandóan körbejár a hálózatban, és az az állomás kap engedélyt kommunikáció kezdeményezésére, mely az adott pillanatban a vezérjelet birtokolja. A hálózat kiépítési költség szempontjából a csillag topológiához hasonlít, üzenettovábbítás szempontjából gy r topológiájú. Megbízhatósága lényegesen nagyobb a gy r topológiánál, mivel csak egy virtuális gy r t tartalmaz, fizikai topológiája csillag. · Sín (bus): A sín topológiájú hálózatban az összes állomás egy közösen használt kommunikációs csatornára kapcsolódik. Bármelyik két csomópont a csatornán keresztül közvetlenül válthat üzeneteket. A gy r topológiához hasonlóan a hálózat kiépítésének költsége az állomásszámmal lineárisan n , a kommunikáció gyors, de a csatorna könnyen telít dhet. Egyes állomások kiesése a többit nem érinti, a csatorna meghibásodása viszont katasztrofális.

5.2.4. ábra: Sín típusú hálózat

6

V. fejezet

A csillag topológiák váltak a mai lokális hálózatok legelterjedtebb megoldásává, mivel rugalmasak, könnyen b víthet ek, viszonylag kis költséggel telepíthet ek (különösen a ma elterjedt integrált kábelezési rendszerekben, ahol nem csak a számítógépes, de a telefon és épület-felügyeleti kábelezés is egy rendszer része). A csillag topológia szinte teljesen kiszorította a busz és gy r megoldásokat, és egy új topológia kialakulásának alapját képezte: a kapcsolt hálózatokét. · kapcsolt (switched): A kapcsolt hálózatok topológiája lényegében csillag alakú, azzal a különbséggel, hogy a központban egy speciális hálózati eszköz, a kapcsoló (switch) foglal helyet. A kapcsoló a csomópontok közötti hálózat kialakítását a hálózatban adott pillanatban található csomagoknak megfelel en alakítja ki, a feladókat közvetlenül összekötve a vev kkel. Ily módon a kapcsolt topológia az állomások között olyan pont-pont kapcsolatot valósít meg, mely dinamikusan változtatható az adatátviteli igényeknek megfelel en. A hálózat kiépítésének költségét a csillag topológiához képest csak a kapcsoló eszköz beépítése növeli. A kommunikáció sebessége nagy, mivel egyszerre kevés eszköz használja ugyanazt a vonalat, és az állomások a kapcsolón keresztül pont-pont módon köthet k össze. A kapcsoló képes különböz sebesség vonalak összekötésére is. Az eddigiekben felsorolt alap topológiákat felhasználva komplex hálózati topológiákat építhetünk. Az alap topológiák kizárólag kis, helyi hálózatok számára alkalmasak, skálázhatóságuk (azaz a hálózatba kapcsolt gépek számának és a hálózat méretének lehetséges növelése) er sen korlátozott. Az egyedi igényeknek megfelel en kell egy skálázható, komplex topológiát kialakítani ezen alap épít elemek felhasználásával.
Megjegyzés: Talán nem ártana megmondani, mi a skálázhatóság.

I.2.3. A hálózatok típusai
A hálózatokat kiterjedésük alapján is lehet osztályozni: · Helyi hálózat (local area network, LAN) A helyi hálózatok tipikusan egy, illetve néhány szomszédos épületet fednek le (néhány kilométer kiterjedés ek), átviteli sebességük nagy (másodpercenként 10 Mbit és 1 Gbit között van). Tipikus helyi hálózati topológia a sín, gy r vagy csillag, a tipikus átviteli közeg a csavart érpáros kábel (UTP).

7

V. fejezet

· Nagy terület hálózat (wide area network, WAN) A nagy terület hálózatok helyi hálózatok összekapcsolásával jönnek létre. A helyi hálózatok közötti kapcsolatok általában nagysebesség (100 Mbit feletti) vonalak, bár nem ritka a modemes, illetve más telefonvonalas összeköttetés sem. Általában elmondható, hogy a nagy hálózatok sebessége az egyéni felhasználók szemszögéb l nézve egy-két nagyságrenddel kisebb a helyi hálózatokénál.

I.2.4. A hálózati kommunikáció rétegei
Egy alkalmazás teljes hálózati kommunikációját megvalósító szoftver egy olyan bonyolult rendszer, melyben egyszerre többféle feladattal és hardver architektúrával kell foglalkozni. Emiatt a szoftvert jól meghatározott részkomponensekre kell bontani. Ezen komponensek egy része a hálózati eszközökben (kapcsolókban, útvonal választókban) található, más részük a hálózatba kapcsolt számítógépek operációs rendszereinek része, míg harmadrészben az adott alkalmazás szoftverébe épülnek be. A kommunikációt végz szoftver ilyen felbontását a számítógép-hálózati kommunikáció réteges szervezése segíti. A rétegek (layers) a kommunikációs rendszer egymástól jól elkülönül , független részei, melyek szabványos interfészekkel kapcsolódnak egymáshoz. Többféle modell létezik a rétegszerkezet kialakítására, mint például az Open Systems Interconnection (OSI) Referencia Modell, vagy az Internet világában használatos TCP/IP rendszer.

Az OSI modell hét réteget határoz meg: · Fizikai (physical): a legalsó szint, az adatok átvitelére szolgáló mechanikai, elektromos, és egyéb jellemz ket leíró modul. Ez a réteg határozza meg az átvitel id zítéseit, a kapcsolat irányát, felépítésének és lebontásának módját. A réteg többféle fizikai hordozó közeget használhat az elektromos jelekt l a fényjeleken át a rádióhullámokig. · Adatkapcsolati (data link): A fizikai réteg szolgáltatásainak igénybevételével az adatok megbízható átküldését végzi el, azaz észleli és lehet ség szerint javítja a kommunikáció során bekövetkez adatátviteli hibákat. Az átviend adatokat keretekbe (bájtcsoportokba) szervezi, ellátja ket kiegészít
Megjegyzés: Csak mert a laikusban felmerülhet, hogy ki kit vezérel.

8

V. fejezet

adatokkal (cím, ellen rz összeg, stb.), és elküldi a vev felé. A vev t l fogadja az adatvételt igazoló keretet. · Hálózati (network): Az adatok fizikai útját határozza meg a célállomásig. Több lehetséges út esetén kiválasztja a legmegfelel bbet (útvonalválasztás, routing). · Szállítási (transport): Feladata a gépek közötti transzparens adatátvitel megvalósítása. A kommunikációban részt vev gépek el l teljesen elfedi a hálózatot, annak topológiáját, és olyan kapcsolatot biztosít számukra, mintha pont-pont összeköttetésben lennének. Ez a réteg gondoskodik arról, hogy a fogadott adat pontosan megegyezzen az elküldött adattal. Hiba esetén újraküldi az adatot. · Viszony (session): A kommunikációban részt vev gépek a kommunikáció során valamilyen viszonyban állnak egymással (azaz a kommunikáció nem csak egy üzenet küldését és fogadását, hanem ezek sorozatát is jelenti). A viszony réteg feladata a párbeszéd megszervezése, a helyes szinkronizáció megteremtése, a két fél m veleteinek összehangolása, egymás állapotának megismerése. · Megjelenítési (presentation): A réteg az adatok alkalmazástól független, egységes kezeléséért felel s. Az alkalmazás különböz típusú adatait egységes, közös reprezentációra hozza, szükség esetén tömöríti, illetve titkosítja. Ez az a szint, ahol a fájl és karakter formátumok egységes, alkalmazástól független ábrázolása kialakul. · Alkalmazási (application): Ez a réteg kapcsolódik a felhasználóhoz, illetve a felhasználói alkalmazásokhoz, mint például az elektronikus levelezés, fájl átvitel, web böngész stb. Alapvet feladata a hálózaton keresztül érkez információ megjelenítése, illetve a felhasználó által bevitt információ továbbítása az alsóbb rétegek felé.

A TCP/IP, az internet alap protokoll családja, szintén réteges felépítés , de csak öt réteget használ. Az OSI modellben található rétegek közül néhánynak a feladatait másokkal összevonja, illetve bizonyos rétegekkel (mint a fizikai és az adatkapcsolati) nem foglalkozik. A hálózati réteg protokollja az IP (Internet Protokol), míg a szállítási rétegben a TCP és az

9

V. fejezet

UDP protokollokat definiálja. Az e fölötti rétegekben a TCP/IP rendszer az UDP illetve a TCP protokollokra épít. A megjelenítési és viszony szintek szolgáltatásai a TCP/IP alkalmazási rétegben jelennek meg.

5.2.5. ábra: A hálózati rétegek és protokollok kapcsolata

I.2.5. Címzés és forgalomirányítás
A forgalomirányítás (routing) feladata annak meghatározása, hogy két állomás közötti üzenetek, amennyiben nincs köztük közvetlen kapcsolat, milyen úton, mely közbüls csomópontokon keresztül haladjanak. A forgalomirányítást a csomópontok olyan táblázatok alapján végzik, amelyek tartalmazzák a lehetséges útvonalakat és esetleg az útvonalakhoz tartozó egyéb információkat, mint például a csatorna sebességét, költségét, aktuális terhelését. A forgalomirányító táblázatokat id nként aktualizálni kell akár kézzel, akár automatikusan. A gyakrabban használt forgalomirányítási módszerek: · fix útvonal: Két adott csomópont között az üzenetváltás mindig rögzített - általában a legrövidebb, legkisebb költség - útvonalakon történik. · virtuális áramkör (virtual circuit): Egy kapcsolati viszony (session) elején kialakult útvonalon halad az összes üzenet, amíg a kapcsolatot valamelyik fél le nem zárja. · dinamikus forgalomirányítás (dynamic routing): Minden üzenethez külön keresnek útvonalat. A közbüls állomások üzenetenként döntik el, hogy azt melyik útvonalon adják tovább. A döntést befolyásolhatja a csatornák aktuális rendelkezésre állása, illetve terhelése.

10

V. fejezet

Miután a forgalomirányítás talált egy útvonalat a két állomás között, az ott futó folyamatok üzeneteket váltanak. Az állomások kapcsolódásának módjai a következ k lehetnek: · Áramkörkapcsolás (circuit switching): A két folyamat kommunikációjához egy fizikai csatorna tartozik, amelyet más folyamatok a kapcsolat id tartama alatt nem használhatnak. A kapcsolat kialakítása lassú, de ezután az üzenetváltás a csatorna kapacitását teljesen kihasználva folyhat. Ha a folyamatok ritkán küldenek üzenetet, a csatorna kihasználatlan. · Üzenetkapcsolás (message switching): Minden üzenet csomópontok közötti továbbításához ideiglenesen egy fizikai csatornát rendelnek, amelyet az üzenet átvitele után más folyamatok használhatnak. Az átvitel során a közbüls állomásoknak a teljes - gyakorta nagyon nagy - üzenetet venni és a továbbításig tárolnia kell. · Csomagkapcsolás (packet switching): Az üzeneteket a küld állomás kis, rendszerint azonos hosszúságú csomagokra bontja. A csomagok önállóan haladnak a hálózaton a céljuk felé, csak a fogadónál állítják bel lük össze újra az üzenetet. A megoldás jól kihasználja a csatornák átviteli kapacitását, hiszen egymás után több üzenethez tartozó csomagot lehet átvinni, nagy méret közbüls tárakra sincs szükség. Ezzel szemben minden csomag többletinformációt tartalmaz, az átvitel sebessége lassabb.

I.3. Hálózati jelleg szolgáltatások
A hálózati szolgáltatások jellemz je, hogy a felhasználó tisztában van azzal, hogy a rendszerben több csomópont m ködik. Számára a távoli és a helyi objektumok kezelése nem homogén. Ebben a fejezetben a két legalapvet bb hálózati szolgáltatást, a távoli terminált és a hálózati fájlátvitelt foglaljuk össze. A kés bbi fejezetekben további szolgáltatásokat, mint például az elosztott fájlrendszer részletesebben is ismertetünk.

11

V. fejezet

I.3.1. Telnet: távoli terminál
A távoli terminál alapvet célja, hogy hálózaton keresztül távoli belépési lehet séget és virtuális terminált (billenty zetet és képerny t) nyújtson a felhasználók számára. Más szavakkal, bárhol is legyen egy A gép el tt ül felhasználó, mindenhonnan oly módon

használhassa a B gépet, mintha el tte ülne, annak terminálját használná, feltételezve, hogy A és B gépek között létezik hálózati összeköttetés. Eredetét tekintve a távoli terminál a soros vonali terminál-hozzáférés (dialup terminal connection) megfelel je a hálózati környezetben. A távoli belépés legelterjedtebb megvalósítása a Telnet (telecommunications network) protokoll, mely a TCP/IP protokollcsalád része, illetve a protokollt használó Telnet program. A fejezet további részében e rendszeren keresztül ismertetjük a távoli terminál elérés legfontosabb tulajdonságait. A távoli terminál elérés megvalósítása látszólag egyszer feladat, a valóságban azonban a terminálok és számítógépek sokfélesége miatt nem is olyan egyszer . A következ kben összefoglaljuk a leglényegesebb feladatokat és azok megvalósításának alapelemeit. I.3.1.1. A Telnet kapcsolat A távoli terminál kapcsolat lényege két hálózati gép közötti karakter-alapú kommunikáció megvalósítása. A Telnet a kliens és a szerver között egy hálózati virtuális terminál (network virtual terminal) kapcsolatot hoz létre. A kapcsolat mindkét vége az adott gépen virtuális terminálként m ködik, logikai billenty zetet és képerny t definiálva. A logikai képerny karakterek megjelenítésére képes, míg a logikai billenty zet karaktereket generál. A Telnet kliens és szerver oldali programjai felel sek a virtuális és valóságos eszközök közötti megfeleltetésért, a karakterek tényleges megjelenítéséért, illetve fogadásáért. A virtuális terminál koncepció segítségével a Telnet rendszer minden olyan fizikai eszközzel képes kommunikálni, melynél a virtuális kódok és a valóságos eszköz közötti leképezés létezik. A kapcsolatot megvalósító rendszernek gondoskodnia kell a valóságos eszköz sajátosságainak figyelembe vételér l, azaz például a vezérl karakterek és terminál jellemz k megfelel átalakításáról a kapcsolatban részt vev gépek között. A Telnet a feladatot protokoll szinten oldja meg a terminálok jellemz it leíró protokoll elemek beiktatásával. Amikor két gép Telnet protokollal kapcsolatba lép egymással, a kapcsolat kiépítése során a Telnet önmaga meghatározza a kapcsolatra érvényes terminál és kommunikációs jellemz ket. A Telnet protokoll része az a képesség, hogy csak azokat a
Megjegyzés: Van jelent sége, hogy más a fordítási szórend? nincs, csak jobban hangzott

12

V. fejezet

kommunikációs módokat támogassa egy kapcsolatban, melyeket mindkét végállomás képes kezelni. Mindezeket maga a protokoll tisztázza a kapcsolat kiépítése során, megkímélve a kommunikáló feleket a további adat és vezérl jel átalakításoktól, értelmezésekt l. Ily módon lehet vé válik, hogy a virtuális terminál csak azokat a vezérl kódokat fogadja, amelyek a hozzá rendelt fizikai eszközökön is értelmezettek. I.3.1.2. Szerver és kliens programok A Telnet a szerver gépen általában egy állandóan futó folyamattal rendelkezik, amelyik a kliens gépekt l beérkez kéréseket fogadja, azok kiszolgálását kezdeményezi. UNIX

rendszerekben ez az ún. telnetd program, melyet az inetd szuperszerver indít el a beérkez kéréseknek megfelel en. Windows NT és más PC alapú rendszerek esetén egy önálló Telnet szerver alkalmazás oldja meg a feladatot. A szerver folyamat feladata a kommunikációs paraméterek tisztázása (a virtuális terminál meghatározása) után a terminált kiszolgáló folyamat elindítása és hozzárendelése a virtuális terminálhoz. UNIX rendszerekben ez általában a felhasználó shell programja, Windows és más PC rendszerek esetében az alap parancsértelmez (pl. DOS prompt). A kliens oldal általában egy telnet nev programot futtat, és ezzel kezdeményezi a kapcsolat kiépítését a szerverhez. A Telnet kliens elindításához szükség van a szerver IP címére, vagy nevére (ez utóbbi csak akkor használható, ha a rendszer képes a névhez tartozó IP cím megtalálására). A TCP/IP protokoll családban az alkalmazások gépen belüli címzésére szolgáló portok közül a Telnet saját, dedikált port számmal (23) rendelkezik. A kliens indításakor ez az alapértelmezés szerinti port, amely újabb paraméter megadásával módosítható. A telnet kliens program hívása:
telnet [] []

Az alábbi példák egyenérték ek, feltételezve, hogy a használt gépnév megfelel az IP címnek.
telnet 152.66.76.1 telnet server.mit.bme.hu telnet server.mit.bme.hu 23

A 23-as Telnet porttól eltér szám használata esetén természetesen szerver oldalon is az eltér számú porton kell a telnetd programot elindítani.
$ telnet server.mit.bme.hu Trying 152.66.76.1... Connected to server.mit.bme.hu.

13

V. fejezet

Escape character is '^]'.

SunOS 5.7 login: labor Password: ******** Last login: Thu Sep $ 2 12:41:28 from labpc1.mit.bme.hu

Ahogy az látható az el z példa kódjában, a telnet parancs kiadása után a Telnet program elvégzi a név ­ IP cím átalakítást, majd hozzákapcsolódik a szerverhez. Ezek után beállítja a kommunikációs paramétereket a szerver és a kliens között, kiírja a speciális Telnet kontroll karaktert (CTRL + ]), végül összekapcsolja a klienst a szerver folyamat által elindított login programmal. A login program a felhasználói név és jelszó ellen rzése után a felhasználó saját shell programját indítja el (a $ jel jelzi a várakozó shell-t). A Telnet kliens programot paraméterek nélkül elindítva az ún. parancsértelmez módot

kapjuk, amikor a Telnet rendszer beépített parancsait érhetjük el. Ez a parancsértelmez mód a létrejött kapcsolat során (a virtuális terminál használata közben) is elérhet a speciális kontroll karakter leütésével (általában a CTRL + ]). I.3.1.3. A Telnet parancsértelmez A Telnet parancsértelmez része kliens oldali parancsok kiadására, beállítások

megváltoztatására szolgál. Ha a kapcsolat már kiépült a szerverig, akkor minden parancs kiadása után a Telnet visszatér a virtuális terminálhoz. Ha a kapcsolat még nem épült ki, akkor folyamatosan parancs módban marad mindaddig, míg kapcsolat kiépítését nem kezdeményezzük. Parancs módban elindíthatunk kliens oldali alkalmazásokat,

megváltoztathatjuk az aktuális kliens könyvtárat, speciális vezérl karaktereket küldhetünk a szervernek, alapállapotba állíthatjuk a kliens-szerver kapcsolatot, illetve megváltoztathatunk egyes kommunikációs paramétereket. Az alábbi példa szemlélteti a Telnet parancsokat:
telnet> telnet> help Commands may be abbreviated. close Commands are:

close current connection

14

V. fejezet

logout display mode open quit send set unset status toggle slc z ! environ ? telnet> display

forcibly logout remote user and close the connection display operating parameters try to enter line or character mode ('mode ?' for more) connect to a site exit telnet transmit special characters ('send ?' for more) set operating parameters ('set ?' for more) unset operating parameters ('unset ?' for more) print status information toggle operating parameters ('toggle ?' for more) change state of special charaters ('slc ?' for more) suspend telnet invoke a subshell change environment variables ('environ ?' for more) print help information leave command mode

will flush output when sending interrupt characters. won't send interrupt characters in urgent mode. won't skip reading of ~/.telnetrc file. won't map carriage return on output. will recognize certain control characters. won't turn on socket level debugging. won't print hexadecimal representation of network traffic. won't print user readable output for "netdata". won't show option processing. won't print hexadecimal representation of terminal traffic. echo escape rlogin tracefile flushoutput interrupt quit eof erase kill lnext [^E] [^]] [off] "(standard output)" [^O] [^C] [^\] [^D] [^H] [^U] [^V]

15

V. fejezet

susp reprint worderase start stop ayt DO DO ECHO

[^Z] [^R] [^W] [^Q] [^S] [^T] SUPPRESS GO AHEAD

WILL TERMINAL TYPE WILL NAWS WILL NEW-ENVIRON
Megjegyzés: Nem biztos, hogy ez mind kell ide. Kimaradhat. Igyekeztem követni a más könyvekben szokásos részletezettséget.

A kapcsolat módosítását, inicializálását, illetve egyéb, a Telnet szervert is érint parancsokat a kliens egy speciális Telnet COMMAND csomagban küldi el a szervernek. Ezen csomagok tipikusan pár bájtot tartalmaznak, els a parancs kódja, majd opcionálisan azt követik a paraméterek.

I.3.2. FTP: fájl átvitel
A fájl átviteli protokoll (file transfer protocol, FTP) a gépek közötti hálózati fájl átvitel segédeszköze. Lehet vé teszi a fájlok mozgatását a kliens és szerver között mindkét irányban, könyvtárak létrehozását, átnevezését, illetve törlését. Ellentétben a Telnet programmal, az FTP nem képes távoli programok futtatására, de fájlátvitelre sokkal egyszer bben használható program. I.3.2.1. FTP kapcsolat A Telnet programmal ellentétben az FTP két párhuzamos kapcsolatot épít ki a kliens és a szerver között: egyet az FTP parancsok és egy másikat az adatok átvitelére. Ennek megfelel en a szerver oldalon a kiszolgáló folyamat két részre bontható, egy protokoll értelmez re és egy adatátvitel végrehajtóra. Az FTP esetében a gépek közötti kommunikáció kiépítése lényegesen egyszer bb: nincs szükség a virtuális terminálok beállítására. Ugyanakkor itt is gondoskodni kell az eltér reprezentációk megfeleltetésér l. Az FTP a fájlátvitel többféle formáját is megengedi. A legelterjedtebb a következ két forma: bináris és szöveges. Bináris FTP kapcsolat esetén az átküldött fájlok bájthelyesen, változtatás nélkül érkeznek meg. Szöveges kapcsolat esetén az FTP gondoskodik az eltér szöveges

16

V. fejezet

fájlformátumok átalakításáról (pl. a DOS ­ UNIX szövegfájlok konverziójáról). A helyes átviteli mód kiválasztása az átvitel el tt a felhasználó feladata. Alapértelmezésben az FTP a szöveges módot használja, ami sok hibára ad lehet séget. Az FTP további lényeges jellemz je, hogy az adatátvitel (a rendszer lényegi szolgáltatása) a felhasználó számára is jól követhet , ellen rizhet . A felhasználó képes az adatkapcsolat beállítására. Erre a Telnet-hez hasonlóan az FTP parancs üzemmód alkalmas. I.3.2.2. FTP kliens és szerver programok Szerver oldalon az FTP folyamat szolgálja ki a klienseket. UNIX rendszerekben ez tipikusan a telnetd démon folyamat, míg Windows NT és más PC rendszerek alatt egy önálló FTP Szerver alkalmazás. A szerver folyamat a kliens kérések fogadása után ellen rzi a felhasználói nevet és jelszót, majd az ellen rzött jogosultságok alapján hozzáférést teremt a szerver gép fájlrendszeréhez. A UNIX rendszerek többségében az FTP szerviz alapértelmezésben engedélyezett, az inetd szuperszerver kezeli. A Windows alapú rendszerekb l hiányzik ez a szolgáltatás, külön szoftver telepítésével és futtatásával hozható létre. A Windows alapú TCP/IP
Megjegyzés: ugyanaz, mint a telneté? Ezt nem értem? A kliens oldalon a telnet nem démon folyamat. A szerver oldalon igen, vagyis bizonyos esetekben. Az esetek többségében az inetd szuperszerver indítja.

programcsomagok többsége tartalmaz ilyen szervert, illetve önálló programként is beszerezhet . Az FTP klienst a felhasználó a Telnet klienshez hasonlóan, a szerver címének megadásával indíthatja el. Itt is létezik a Telnet esetében látott parancs üzemmód, mely azonban itt alapértelmezésnek számít, azaz a kapcsolat kiépítése során is ez az interfész látszik a felhasználó felé. A parancsértelmez nek adott utasításokkal vezérelhetjük az FTP kapcsolatot, a fájlátvitelt, és ezek segítségével utasíthatjuk az FTP szerver folyamatot a szerver gép fájlrendszerének módosítására. A Telnet programhoz hasonlóan az FTP is dedikált portszámot használ, az 21-est. Itt is megadható más portszám a kliens program paraméterei között. Az FTP kliens program használata:
ftp [] []

Alkalmazási példa:
$ ftp ftp.mit.bme.hu Connected to ftp.mit.bme.hu. Name (ftp.mit.bme.hu:labor): labor 331 Password required for labor. Password: ********

17

V. fejezet

230 User labor logged in. ftp> $

A kapcsolat kiépítése után itt is a felhasználói név és jelszó megadása és ellen rzése következik, ami után a parancsértelmez promptot kapjuk. Általában a helyi és távoli

könyvtár, valamint a fájlátviteli mód meghatározása után kezd dik el a tényleges fájlátvitel. A következ rövid példa egy szöveges fájl átvitelét mutatja a kliens gépr l a szerver gépre, majd egy bináris fájl átvitelét a szerverr l a kliensre.
ftp> ascii 200 Type set to A. ftp> put leiras.txt 200 PORT command successful. 150 Opening ASCII mode data connection for leiras.txt (4896 bytes). 226 Transfer complete. local: leiras.txt remote: leiras.txt 4896 bytes received in 1.8 seconds ftp> bin 200 Type set to I. ftp> get backup.zip 200 PORT command successful. 150 Opening BINARY mode data connection for backup.zip (4944123 bytes). 226 Transfer complete. local: backup.zip remote: backup.zip 4944123 bytes received in 9.8 seconds ftp>

Az FTP általában egy speciális felhasználó azonosítási módot is alkalmaz, mellyel lehet vé válik a valós név és jelszó nélküli, ún. anonim FTP belépés. Ekkor névként az ,,anonymous" (vagy esetenként az ,,ftp") nevet kell megadni, jelszóként pedig az FTP kapcsolatot kezdeményez személy email címét. Ilyenkor az FTP szerver egy speciális könyvtárterülethez engedélyez korlátozott hozzáférést, általában a fájlrendszer egyéb részeinek teljes kizárásával. UNIX operációs rendszer alatt ezt a chroot() rendszerhívás segítségével oldja meg a kapcsolathoz rendelt szerver folyamat. A chroot() rendszerhívás a fájlrendszert egy adott pontjától kezdve ,,levágja", azaz a fa struktúra pont feletti részeinek elérését teljesen megszünteti.

18

V. fejezet

I.3.2.3. Az FTP parancsértelmez Az FTP rendszerben a felhasználó alapértelmezésben a parancsértelmez t használja helyi és távoli feladatok megoldására, illetve a fájlátvitelre. Az alábbi példa összefoglalja egy tipikus FTP rendszer parancsszavait.
ftp> help Commands may be abbreviated. ! $ account append ascii bell binary bye case cd cdup close ftp> cr delete debug dir disconnect form get glob hash help lcd ls Commands are: macdef mdelete mdir mget mkdir mls mode mput nmap ntrans open prompt proxy sendport put pwd quit quote recv remotehelp rename reset rmdir runique send status struct sunique tenex trace type user verbose ?

A parancsok alapvet en három nagy kategóriába sorolhatóak: helyi (kliens) parancsok, távoli (szerver) parancsok, és adatátviteli parancsok. Az átviteli mód meghatározására szolgáló ascii és binary parancsok kiadása után a cd paranccsal beállíthatjuk a távoli, illetve az lcd paranccsal a helyi munkakönyvtárat. Ezek után a put vagy get parancsok segítségével bonyolítható le a kívánt fájl átvitel, majd a quit paranccsal szakíthatjuk meg a kapcsolatot és léphetünk ki az FTP kliens program parancsértelmez jéb l.

I.4. Elosztott szolgáltatások
I.4.1. Jellemz k

Mint azt korábban láttuk, az elosztott rendszer hálózattal összekötött, elosztott szoftverrel felruházott autonóm számítógépek összessége. Ebben az architektúrában az elosztott szoftver

19

V. fejezet

két f

feladatot lát el: az aktivitások koordinálását és az er források megosztását. Egy

elosztott rendszer akkor teljesíti a vele szemben támasztott elvárásokat, ha a felhasználója egyetlen, integrált számítási eszközt lát, az elosztottság számára rejtve marad. Az alábbiakban áttekintjük azokat a jellemz ket, amik alapján egy elosztott rendszert min síteni lehet.

I.4.1.1. Az elosztott rendszerek legfontosabb jellemz i

Az elosztott rendszerekkel szemben számos követelmény merül fel. Ezek közül a legfontosabbak:

1. er forrás megosztás 2. nyitottság 3. konkurencia 4. skálázhatóság 5. hibat rés 6. átlátszóság

A továbbiakban részletesen elemezzük ezeket a követelményeket.

(1) er forrás megosztás

Az er források osztott használata mindig jelent s szerepet töltött be a számítógépes rendszerek történetében. Ezt els sorban gazdasági és rendszerszervezési okokra lehet visszavezetni. A hardver és szoftver komponensek fejl dése egyre finomabb megközelítést tett lehet vé az osztott er forrás használathoz. Míg a 60-as évekre els sorban az id osztásos rendszerek voltak jellemz ek, ahol a hangsúly els sorban a CPU osztott használatára helyez dött, addig a 70-es évek elején megjelentek a többfelhasználós rendszerek, felvetve egyéb hardver berendezések, mint például a nyomtatók, lemezegységek és perifériák osztott használatának az igényét, ahol kényelmi és költségkímél szempontok domináltak. A

szoftver eszközök rohamos fejl dése szinte elengedhetetlenné tette a koncepcionális er források, az adatok osztott használatát. Manapság komplex szoftver rendszer fejlesztése

20

V. fejezet

elképzelhetetlen osztott adat és program használat nélkül. A fejleszt

csapat együtt

használhatja a fejleszt eszközöket, közvetlen betekintést nyernek egymás munkájába, s t az osztott használat a bonyolult rendszerek karbantartását is megkönnyíti. A kereskedelmi alkalmazások egyre elterjedtebben alkalmazzák azt a megközelítést, hogy a felhasználók egyetlen aktív adatbázis osztottan használt adat objektumaihoz férnek hozzá, ahelyett, hogy mindenhol egy-egy saját másolattal dolgoznának, így a kényelmes használat mellett lényegesen egyszer bb a konzisztencia karbantartás is. A hálózati és elosztott alkalmazások egyre szélesed területe, amikor a számítógépekkel együttm köd felhasználói csoportok hatékony munkavégzését támogatják. Ez elvezetett egy újfajta munkamódszer kialakulásához, az úgynevezett Számítógéppel támogatott együttm köd munkavégzéshez (Computer

Supported Cooperative Working ­ CSCW, amit groupware néven is ismernek), ahol egy adott nagy komplexitású feladat elvégzésén egyszerre párhuzamosan többen is dolgoznak, és a feladat megoldásához szükséges összes szoftver komponenst (programokat, modelleket, adatelemeket, adatbázisokat) közösen, osztottan használják.

Míg a többfelhasználós rendszerekben az er források osztott használata nyilvánvaló (egy rendszer, a kernel felügyeli az er forrásokat), addig elosztott rendszerekben újfajta architektúrára, támogatásra van szükség. Ez az új elem az er forrás menedzser, aminek az a feladata, hogy biztosítsa egy adott er forrás optimális és igazságos használatát. Az er forrás felhasználói az er forrás menedzserrel kommunikálnak, t le kérnek hozzáférést az er forráshoz. Az utóbbi id ben két elterjedt modellt alkalmaznak: a kliens-szerver modellt és az objektum modellt.

A kliens-szerver modellben a szerver egy adott er forrás menedzsere, a kliensek kéréseken keresztül próbálják az er forrást használni. Ennél a modellnél nagyon fontos, hogy a kliensszerver kapcsolat mindig egy adott feladatra vonatkozik, egy másik feladatkörben a szerver is lehet kliens (egy másik szerver számára). Az általános modellben egy tetsz leges számítógép futtathatja a klienst és a szervert (kliens/szerver lehet azonos gépen is). Nagyon fontos, hogy egy elosztott rendszerben egy adott típusú szolgáltatást egyszerre több, egymással ekvivalens szerver is nyújthat, így meg kell különböztetni a szolgáltatást magától a szolgáltatást konkrétan nyújtó szervert l!

21

V. fejezet

Egy rendszerben azonban nem lehet minden er forrást ezzel a modellel kezelni, bizonyos er forrásoknak lokálisnak kell maradni. Ezek közül a legfontosabbak a CPU, a memória és a lokális hálózat interfész. Ezeket tipikusan az operációs rendszer, a kernel kezeli.

Az objektum alapú modell hasonló az objektumorientált programozás modelljéhez. Itt minden osztott er forrást egy objektumként modellezünk, az er forrást bezárjuk az objektumba. Az objektumok egyedi azonosítókkal rendelkeznek, így mozgathatók. A szolgáltatáskérést egyszer en az objektumnak küldött üzeneteken keresztül lehet megvalósítani. A modell el nye, hogy egyszer , rugalmas keretet biztosít az er források kezeléséhez, másrészt az osztott er forrásokat azonos módon lehet kezelni.

(2) Nyitottság

A nyitottság kérdése a rendszer b víthet ségével foglalkozik. Alapvet en az elosztott modellben azzal a feltételezéssel élünk, hogy minden er forrásból korlátlan mennyiség áll rendelkezésünkre (ha mégsem, akkor a rendszert zökken mentesen b víthetjük). Ebb l adódóan egy elosztott rendszerrel szemben természetes elvárás, hogy ha a rendszert valamilyen szempontból b vítjük (például újabb gépeket adunk hozzá, újabb szolgáltatásokat integrálunk, újabb szerverekkel b vítjük), akkor ne kelljen architektúrális változtatásokat végrehajtani, a felhasználók el l a b vítés rejtve maradjon. A b víthet ség egyaránt vonatkozik hardver elemekre (további perifériák, memória, kommunikációs interfész), illetve szoftver elemekre is (az operációs rendszer szolgáltatásai, kommunikációs protokoll, er forrás megosztó szolgáltatások). Így a nyitottság mértékét az határozza meg, hogy az új osztott er forrásokat kezel szolgáltatásokat mennyire lehet ,,folytonosan" hozzáadni a rendszerhez (m ködés megszakítása, illetve komponensek duplikálása nélkül).

Felmerül a kérdés, hogy hogyan lehet elérni a nyitottságot? Erre elég nehéz kimerít választ adni, azonban egy elengedhetetlen feltételnek mindenféleképpen meg kell felelni: a f bb szoftver interfészeket nyilvánosságra kell hozni (publikálni kell). A korai rendszerek zártak voltak, mivel nem feleltek meg ennek az igen fontos feltételnek. Végezetül összefoglalva a nyitott elosztott rendszerek f bb ismérveit:

22

V. fejezet

· a f bb (operációs rendszer) interfészek publikáltak · egységes folyamatok közötti kommunikáció, publikált interfészek az osztott er források eléréséhez · eltér HW/SW, de a publikált szabványokhoz igazodni kell.

Nyitottság szempontjából a kés bb ismertetett Unix az azt megel z rendszerekhez képest ,,nyitottabbnak" számít:

· Az alkalmazás fejleszt k számára nyitottabb, mert hozzáférnek a rendszer által nyújtott összes szolgáltatáshoz; · A hardver forgalmazók és a rendszer adminisztrátorok számára is nyitottabb, mert az operációs rendszert viszonylag egyszer en lehet b víteni, könnyen hozzá lehet adni új perifériákat; · A szoftver forgalmazók és a felhasználók számára is nyitottabb, mert hardver-független. A szoftver fejleszt k olyan programokat írhatnak, amelyek módosítás nélkül futnak több hardver platformon is. (Persze, mint azt kés bb látni fogjuk, ez az állítás csak akkor igaz, ha adott Unix változatra készülnek a programok, vagy azzal a feltételezéssel élnek, hogy az adott Unix változat megfelel bizonyos kés bb ismertetett szabványoknak.)

(3) Konkurencia

A konkurencia és a párhuzamos végrehajtás természetesen vet dik fel az elosztott rendszerekben, mivel a felhasználók egymástól elkülönül tevékenységeket végeznek,

független er források (is) megtalálhatók a rendszerben és a szerver folyamatok külön számítógépeken is futnak. Ezen tevékenységek szétválasztása lehet vé teszi, hogy a feldolgozás párhuzamosan folyjon a különböz számítógépeken. Azonban nagy hangsúlyt kell fektetni az osztottan használt er források hozzáférés szabályozására és frissítésére, a szinkronizációs sémákat gondosan meg kell tervezni, valamint biztosítani kell, hogy a konkurens végrehajtás biztosította el nyök nem tékozlódnak el egy rossz szinkronizációs séma miatt.

23

V. fejezet

Ha a számítógép csak egyetlen processzort tartalmaz, és egyszerre több folyamatot szeretnénk futtatni, akkor a folyamatok végrehajtását össze kell fésülni, megfelel támogatást biztosítva a folyamatok közötti váltáshoz, az adatszerkezetek mentéséhez és visszaállításához. Ebben az esetben a folyamatok koncepcionálisan úgy érzékelik, hogy párhuzamosan futnak. Ezt virtuális párhuzamosságnak nevezik. Ha egy gépben N processzor található, akkor N folyamat futhat valóban fizikailag is párhuzamosan. Ekkor, ha a folyamatok közel függetlenek, a gyorsulás az adminisztratív tevékenység idejét leszámítva majdnem N-szeres lehet. Azonban az esetek nagy részében együttm köd folyamatokkal van dolgunk, amelyek egymás eredményeit felhasználják, kommunikálnak egymással, így az N-szeres

sebességnövekedés közel sem érhet

el. Az elosztott rendszereknél sok számítógép

kapcsolódik össze egy hálózaton keresztül. Amennyiben a folyamatok az egyes gépekre szétoszthatók, akkor hasonló a helyzet a többprocesszoros rendszerekéhez: a feldolgozás itt is jelent sen felgyorsítható. Ezen struktúrát tipikusan a gyakran használt szolgáltatások használják ki intenzíven. Például az állomány szerverek nagy terhelésnek vannak kitéve egy elosztott rendszerben, ezért szokás több állomány szervert is m ködtetni, méghozzá különböz gépeken. Így a rendszer szempontjából az állomány szerver nyújtotta szolgáltatás a kliensei számára lényegesen felgyorsulhat. (Meg kell jegyezni, hogy a nagyteljesítmény szerverek ráadásul tipikusan többprocesszoros architektúrákon futnak, tovább javítva a szolgáltatás teljesítményét.)

(4) Skálázhatóság

Az elosztott rendszerek eltér

méret ek lehetnek, kezdve a legkisebb, két gépb l álló

rendszert l a lokális hálózatra épített akár több száz gépet is magába foglaló rendszerig. A skálázhatóság fogalma azt jelenti, hogy amikor a rendszer méretét növeljük, akkor ne kelljen a rendszer architektúráját vagy a szoftver alkalmazásokat megváltoztatni. Egy rendszer tervezésénél figyelembe kell venni annak várható életciklusát, az esetleges felmerül b vítési igényeket, és úgy kell kialakítani, hogy ezek az ésszer igények radikális változtatás nélkül megvalósíthatóak legyenek. Az elmúlt években tanúi lehettünk egy skálázhatósági problémának: pár évvel ezel tt a budapesti telefonszámok még hatjegy ek voltak. A telefonok, illetve fax berendezések rohamos terjedésével azonban a hat számjegy kevésnek bizonyult, így át kellett térni a 24

V. fejezet

hétjegy telefonszámokra, ami miatt a régi telefonszámok megváltoztak, vagyis a régi számok tulajdonosai a rendszer b vítése során radikális változtatást érzékeltek. A tervezésnél persze nem szabad átesni a ló túlsó oldalára, nem szabad irreális követelményekre tervezni, a praktikusságot, kényelmes használatot is szem el tt kell tartani. Valószín leg egyetlen olvasónk sem repesne a boldogságtól, ha pl. 20 számjegyes telefonszámokat kellene használnia, holott az a közeljöv ben biztosan nem fog skálázhatósági problémákhoz vezetni.

A skálázható rendszerekben azt az egyszer tervezési filozófiát alkalmazzák, hogy semmilyen er forrás nem korlátozott, ha a rendszer b vülésével valamilyen er forrásnak mégis sz kében lennénk, újabbat adunk a rendszerhez. Például, ha az elosztott állományszolgáltatás lelassul, mert a szerver nem képes már tolerálható id n belül kiszolgálni a megs r södött kéréseket, újabb állomány szervert állíthatunk szolgálatba.

(5) Hibat rés

A számítógépes rendszerek bonyolultságukból adódóan néha meghibásodnak. Mivel a hardver és szoftver hibák miatt hibás eredmények születhetnek, illetve a programok a feladataik elvégzése el tt is befejezhetik futásukat, így feltétlenül foglalkozni kell a hibat rés megvalósításával. A hibat r viselkedés megvalósításához mind hardver redundanciát (hardware

redundancy) (redundáns komponensek alkalmazása), mind pedig szoftver felépülést (software recovery) (olyan szoftverek alkalmazása, amik hibákból felépülnek, folytatják a helyes m ködést) alkalmaznak. A hardver redundanciát gyakran meleg tartalék formájában valósítják meg, vagyis egy adott kritikus funkciót megvalósító berendezés mellett párhuzamosan m ködtetnek egy másik, azonos, vagy azonos funkciót nyújtó berendezést. Ennek a megoldásnak hátránya, hogy nagyon költséges, azonban számos kritikus alkalmazásnál a biztonsági szempontok dominálnak és megkövetelik a meleg tartalékot. Nagyon sok alkalmazásnál azonban ennek költségei megengedhetetlenek, más megoldásokat kell alkalmazni. Az elosztott rendszerekben a redundancia finomabb szinten is tervezhet , például kritikus szerverek replikálhatók. Másrészt az elosztott rendszerekben a redundáns hardvert ki lehet használni nem-kritikus tevékenységek végrehajtására, amíg nincs rá szükség. 25

V. fejezet

A szoftver felépülés megvalósításához mint azt már korábban láttuk, olyan szoftver komponenseket kell tervezni, amelyek segítségével az állandó adatok meghibásodás észlelésekor visszaállíthatók, a számítások visszagörgethet k (recovery, roll-back). Az elosztott rendszerek egy másik el nyös tulajdonsága, hogy hardver hibák jelenlétében is nagyfokú rendelkezésre állást biztosítanak. Egy többfelhasználós rendszerben egyetlen hiba hatására majdnem minden esetben a rendszer elérhetetlenné válik az összes felhasználója számára. Ezzel szemben amikor egy elosztott rendszerben meghibásodik valamelyik komponens, a hiba csak a meghibásodott komponensen folyó munkát érinti.

(6) Átlátszóság (fizikai széttagoltság elrejtése)

Az átlátszóság (transparency) nem más, mint egy elosztott rendszerben a komponensek elosztott természetének elrejtése a felhasználó és az alkalmazás fejleszt el l, hogy azok a rendszert egy egységes egészként, nem pedig független komponensek laza összességeként lássák. Ennek eléréséhez hálózati és kommunikációs, explicit menedzsment és integrációs technikákra van szükség. Az alábbiakban röviden vázoljuk a nyolcféle átlátszóság definícióját.

· A hozzáférés átlátszóság (access transparency) lehet vé teszi a helyi és a távoli er források azonos m veleteket használó, azonos módon történ kezelését. · A hely átlátszóság (location transparency) lehet vé teszi információs objektumok elérését azok helyének ismerete nélkül. A hozzáférés átlátszóságot és a hely átlátszóságot együttesen szokás hálózati átlátszóságnak (network transparency) nevezni. · A konkurencia átlátszóság (concurrency transparency) lehet vé teszi folyamatok konkurens együttm ködését osztott információs objektumok használatán keresztül, anélkül, hogy azok zavarnák egymást. · A másolat átlátszóság (replication transparency) lehet vé teszi, hogy az információs objektumokból (a nagyobb megbízhatóság, jobb teljesítmény érdekében) több másolat is létezzen a rendszerben, anélkül, hogy a felhasználó és a programok tudomást szereznének a másolatokról.

26

V. fejezet

· A hiba átlátszóság (failure transparency) lehet vé teszi a meghibásodások elrejtését, lehet vé téve a felhasználók és az alkalmazói programok számára, hogy a feladataikat hardver vagy szoftver hibák jelenlétében is elvégezzék. · A vándorlási átlátszóság (migration transparency) lehet vé teszi az információs objektumok szabad mozgatását a rendszerben, anélkül, hogy befolyásolnák a felhasználó, illetve az alkalmazói programok m ködését. · A teljesítmény átlátszóság (performance transparency) lehet vé teszi a rendszer átkonfigurálását, hogy a rendszer teljesítménye terhelésváltozáskor javítható legyen. · A skálázási átlátszóság (scaling transparency) lehet vé teszi a rendszer b víthet ségét, a rendszer struktúrájának, illetve az alkalmazások algoritmusainak megváltozása nélkül.

A fenti átlátszóságok közül a két legfontosabb a hozzáférés és a hely átlátszóság, ezek megléte vagy hiánya van a legnagyobb hatással az elosztott er források használhatóságára. Az alábbiakban egy példát mutatunk a hálózati átlátszóság hiányára. A Unix jól ismert rlogin parancsával egy felhasználható beléphet egy megnevezett gépre. Itt máris sérül a hely átlátszóság, mert a gépet mindenképp meg kell nevezni. Továbbá az rlogin használatakor követett eljárás eltér a lokális gépre történ bejelentkezést l, mivel a lokális gépre történ bejelentkezésnél a login programot a rendszer automatikusan futtatja, nem kell azt explicite meghívni. Ebb l adódóan a hozzáférés átlátszóság sem teljesül. Egy átlátszóságot megvalósító rendszerben elképzelhet , hogy a felhasználó nem egy adott gépre, hanem egy domainbe lép be. Ekkor a felhasználó jogosultságot kapna az adott domain összes szolgáltatásának a használatához. Ezzel szemben az elektronikus levelezés a hálózati átlátszóság tulajdonságát mutatja. Egy elektronikus levelezési cím, mint például roman@mit.bme.hu egy felhasználói és egy domain névb l áll. A domaineket szervezeti struktúrák alapján definiálják és osztják ki. A felhasználókhoz egy adott domainen belül rendelnek levelezési nevet. Ha egy ilyen felhasználónak küldünk levelet, ahhoz nem kell ismernünk a felhasználó fizikai vagy hálózati helyét, illetve magának a levélküldésnek a folyamata is független a címzett helyét l. Ebb l adódóan az Internetes elektronikus levelezés rendelkezik a hálózati átlátszóság

tulajdonsággal.

27

V. fejezet

I.4.1.2. Elosztott rendszerek tervezési szempontjai

Az el z

alfejezetben áttekintettük az elosztott rendszerek hasznosságát leíró f bb

jellemz ket. Ebben az alfejezetben az elosztott rendszerek tervezésénél figyelembe veend legfontosabb tervezési szempontokat vizsgáljuk. Bár egy elosztott rendszer vagy alkalmazás tervezésénél számos olyan szempontot is figyelembe kell venni, ami nem kapcsolódik a rendszer elosztottságához, mint például szoftver mérnöki technikák, ember-gép kapcsolat és algoritmus tervezés, az alábbiakban csak azokkal a tervezési szempontokkal foglalkozunk, amelyek kifejezetten a rendszer elosztott természetéb l fakadnak. A továbbiakban az alábbi témaköröket tárgyaljuk:

1. megnevezés 2. kommunikáció 3. szoftver struktúra 4. terhelés kiosztás 5. konzisztencia karbantartás

(1) Megnevezés

Ha egy folyamat egy olyan er forráshoz akar hozzáférni, amit nem a folyamat maga felügyel, akkor meg kell neveznie az er forrást. A továbbiakban név alatt egy olyan megnevezést értünk, amit az emberi felhasználók könnyen értelmezni tudnak, mindamellett programok is használhatnak, míg azonosító alatt csak programok által értelmezhet megnevezést értünk. Ebben az esetben tipikusan valamilyen kompakt ábrázolásmódot, bitmintát alkalmaznak. Azt a folyamatot, amely során egy nevet leképeznek egy olyan alakra, ami lehet vé teszi az er forrásokon való m veletvégzést, név feloldásnak (name resolution) nevezzük. Elosztott rendszerekben a névfeloldás talán az egyik legfontosabb szolgáltatás, melynek során általában egy kommunikációs azonosítót állítanak el . Például az Internetes kommunikációban a kommunikációs azonosító két részb l áll: egy host azonosítóból és egy port számból.

28

V. fejezet

Mivel

a

név

feloldás

er sen

befolyásolja

az

elosztott

rendszer

hatékonyságát,

használhatóságát, így megválasztásánál nagyon körültekint en kell eljárni. A választásnál az alábbi ortogonális tervezési szempontokat kell figyelembe venni: Egyrészt választhatunk véges vagy potenciálisan végtelen névteret, másrészt kialakíthatunk strukturált vagy lapos (egyszint ) névteret.

A nevek feloldása mindig valamilyen környezetben történik és a név feloldásához mindig meg kell adni azt a környezetet is, amiben a feloldást el kell végezni. Például az állományrendszer esetében minden egyes könyvtár egy környezetet jelent.

A nevek és azonosítók mindig a rendeltetésüknek leginkább megfelel alakot öltik. Bizonyos neveket az emberek számára olvasható alakúra terveznek, hogy az emberi felhasználó könnyen eligazodjon közöttük. Az állománynevek, mint például

~roman/dokumentumok/konyv és a magasszint hálózati nevek, mint például az Internetes domain nevek ­ például mit.bme.hu ­ ebbe a kategóriába esnek. Más neveket ezzel szemben úgy alakítanak ki, hogy azok tömör ábrázolásmódot biztosítsanak, helytakarékosak legyenek, esetleg az azonosított er forrás elhelyezkedésér l áruljanak el valamit. (Meg kell jegyezni, hogy az utóbbi esetben sérül a hely átlátszóság.)

Nagyon elterjedten alkalmaznak hierarchikus névteret. Az egyik legjelent sebb el nye, hogy a név minden egyes része eltér környezetben kerül feloldásra, így ugyanaz a név komponens többször is felhasználható. Ebb l adódóan egy hierarchikus névtér potenciálisan végtelen névteret jelöl ki.

A megnevezési sémák kialakításánál figyelembe lehet venni védelmi szempontokat is. Ki lehet alakítani olyan névteret, amely már a név megválasztásával véd a jogosulatlan használat ellen. Ennek leggyakoribb módja, hogy olyan azonosítót alkalmaznak, aminek az el állítása számításigényes olyan folyamatok számára, amelyek azt nem birtokolják. A számításigény annyira megnövelhet , hogy ezáltal praktikusan lehetetlenné válik jogosulatlan nevek megszerzése azok véletlen generálásával.

(2) Kommunikáció 29

V. fejezet

Egy elosztott rendszer komponensei mind logikailag, mind pedig fizikailag széttagoltak, együttm ködésükhöz kommunikációra van szükség. Egy folyamat pár közötti

kommunikáció a küld és a fogadó folyamatok olyan m veleteit foglalja magába, aminek eredményeképp adatátvitel jön létre a küld folyamat környezetéb l a fogadó folyamat

környezetébe és szinkronizáció valósul meg a két folyamat között. A kommunikációt két alapvet programozástechnikai primitív, a send és a receive (küldés és fogadás) valósítja meg. A kommunikáció ebben a sémában üzenetküldésen alapszik. A kommunikációs mechanizmus, mint azt korábban láttuk, lehet szinkron vagy blokkolódó, vagyis a küld folyamat bevárja az üzenet vételét, vagy aszinkron vagy nem blokkolódó, vagyis a küld folyamat továbbhalad anélkül, hogy megvárná az üzenet fogadását.

A továbbiakban megvizsgálunk három kommunikációs sémát: a kliens-szerver sémát, a csoportos multicast-ot és a függvényszállítást.

Kliens - szerver séma

A kliens-szerver kommunikációs modellt szervizek nyújtására dolgozták ki. A kommunikáció három lépésb l tev dik össze:

1. A kliens elküldi a kérését a szervernek; 2. A szerver elvégzi a kliens számára a kért m veletet (szolgáltatást); 3. A szerver elküldi a választ a kliensnek.

A kliens-szerver kommunikációs sémát meg lehet valósítani a send és receive primitívekkel, azonban azt nagyon gyakran nyelvi szintre emelve távoli eljáráshívásokkal valósítják meg. Ennek részleteit majd a kés bbiekben ismertetjük. A kommunikáció során leggyakrabban az ún. Request-Reply protokollt használják, erre optimalizálják a kommunikációt. (A kérés tartalmaz egy kommunikációs azonosítót, ahová a választ a szervernek vissza kell küldeni.)

30

V. fejezet

Mint azt korábban láttuk, az elosztott rendszereknél a rendszer nyíltsága nagyon fontos követelmény. A szerverek és az általuk nyújtott szolgáltatások könny b víthet sége és

integrálhatósága érdekében a szerverekhez dinamikusan kell az azonosítókat hozzárendelni. Ennek legelterjedtebb módja, hogy a rendszerben m ködik egy (vagy több) név szolgáltatás, ahová az új szervereknek be kell jelentkezni, regisztrálni kell. A szerver regisztrációkor kap egy azonosítót. A kliensek a szerver azonosítóját a név szolgáltatótól kapják meg.

Csoportos multicast

A csoportos multicasting esetén a folyamatok szintén üzenetküldéssel kommunikálnak, azonban ebben az esetben az üzenetet nem egyetlen folyamatnak, hanem egy folyamat csoportnak küldik el. Egy csoportos üzenetküldéshez a csoport minden egyes folyamatának egy üzenet fogadása kapcsolódik. Szokás megkülönböztetni a broadcast-ot (üzenetszórás) a csoportos multicast-tól. Az üzenetszórást elterjedten használják a lokális hálózatoknál. Ekkor az üzenetet mindenki megkapja, aki a hálózathoz kapcsolódik. A csoportos multicast ezzel szemben valamilyen logikai csoportosítás alapján szelektál ebb l a sokaságból.

A csoportos multicast használatát az alábbi motivációk támasztják alá:

· objektumok megkeresése (Például ha több állományszerver van a rendszerben, és keresünk egy állományt, akkor csoportos multicast-ot küldhetünk a szervereknek, és csak az válaszol, aki tárolja a keresett állományt.) · hibat rés (Például a kliens a kérését nem csak egyetlen szervernek küldi el, hanem szerverek egy csoportjának. Ha a szerver csoport valamelyik szervere meghibásodik, akkor egy másik szerver nyújtja a kért szolgáltatást.) · többszörös frissítés (Esemény értesítésre szolgálhat. Például egy pontos id szolgáltató adott id közönként ,,szétsugározhatja" a pontos id t másodlagos id szolgáltatóknak ,,most 17:00 az id " jelleg üzenetekkel.)

31

V. fejezet

A hálózati hardver nem biztos, hogy támogatja a csoportos multicast-ot. Ebben az esetben szoftverb l, az üzenetek szekvenciális elküldésével lehet csoportos multicast-ot

megvalósítani.

Függvényszállítás

Tulajdonképpen a függvényszállítás tekinthet a kliens-szerver modell egy speciális esetének is. Míg a kliens-szerver modellben tisztán adatok áramolnak (bár az els üzenet azt határozza meg, hogy a szerver mit is hajtson végre a kliens számára), addig a függvényszállítás esetén utasításblokkok, eljárás definíciók is mehetnek az üzenetekben, a szerveren interpreter értelmezi azokat. Ezzel a technikával a szerver képességei dinamikusan b víthet k, egy speciális feladat megoldására ,,kiképezhet ". A függvényszállítás legismertebb példái a postscript nyomtatók és például a Sun NeWs ablakozó rendszer.

(3) Programstruktúra

A centralizált számítógép rendszerek operációs rendszerét gyakran nevezik monolitikusnak, mert az általuk nyújtott absztrakciókat egy mereven lezárt interfész biztosítja, mint például a Unix rendszerhívás interfésze. Ezzel szemben az elosztott rendszerekben az alkalmazói programok számos szolgáltatást érhetnek el, amelyek mind a saját interfészüket biztosítják a bezárt er források eléréséhez. Mivel az elosztott rendszereknél a nyitottság kulcs szerepet tölt be, így azok számára egy merev, lezárt interfész alkalmatlan.

A centralizált és az elosztott rendszerek réteg struktúrája eltér képet mutat. Az V.4.1. ábra mutatja a centralizált rendszerek rétegstruktúráját.

32

V. fejezet

alkalmazások programnyelvi támogatás operációs rendszer hardver

V.4.1. ábra: A centralizált rendszer rétegstruktúrája

Mint az jól látszik, a négy réteg ­ a hardver, operációs rendszer, a programnyelvi támogatás és az alkalmazások egymásra épülnek. Minden két réteget egy határfelület választ el, a fels bb rétegek csak az alattuk lév rétegek szolgáltatásain keresztül érhetik el az alsóbb rétegeket. Ebben az elrendezésben az operációs rendszer a f szoftver réteg. Az operációs rendszer kezeli a legfontosabb er forrásokat és fontos szolgáltatásokat biztosít az alkalmazások és a felhasználók számára. A f bb feladatok magukban foglalják a memória allokációt és védelmet, a folyamatok létrehozását és a processzor ütemezést, a perifériális berendezések kezelését, a felhasználó hitelesítést és hozzáférés szabályozást, az állomány kezelést, az óra szolgáltatásokat, stb. Ezzel szemben az elosztott rendszerek eltér rétegszerkezetet mutatnak (lásd az V.4.2. ábrát).

alkalmazások

elosztott programozási támogatás

nyílt szolgáltatások

operációs rendszer kernel szolgáltatások számítógépes és hálózati hardver

V.4.2. ábra: Elosztott rendszerek réteg struktúrája

33

V. fejezet

Itt már nem csak két szomszédos réteg található, illetve az operációs rendszer feladatai az alapvet er források ­ a memória allokálás és védelem, a folyamatok létrehozása és

processzor ütemezés, a folyamatok közötti kommunikáció és a perifériális berendezések kezelése ­ kezelésére korlátozódnak. A nyitottság itt azt jelenti, hogy az elosztott rendszereket egy adott felhasználói kör vagy alkalmazási kör igényeinek megfelel en lehet konfigurálni.

(4) Terhelés szétosztás

Egy centralizált rendszerben a rendelkezésre álló számítási és memória er forrásokkal az operációs rendszer a pillanatnyi terhelésnek leginkább megfelel módon gazdálkodik. Az elosztott rendszerek legegyszer bb architektúrájában munkaállomások kapcsolódnak össze egy lokális hálózattal, és ehhez a hálózathoz kapcsolódnak még különböz szerverek, mint például állomány szolgáltatók, nyomtató szolgáltatók, stb. Ebben a struktúrában a munkaállomások képviselik a számítási kapacitást. Ezt a modellt szokás munkaállomásszerver modellnek nevezni. Mint azt majd a kés bbiekben látni fogjuk, a felhasználói kezel i felület konzisztencia szempontjából el nyös, ha az er sen interaktív alkalmazások feladatai magán a munkaállomáson futnak, amely képerny je el tt ül a felhasználó, mivel így a hálózati késleltetés kiiktatható. Ezt a munkaállomás-szerver modell hatékonyan tudja megvalósítani. Nyilvánvaló azonban, hogy az egyszer munkaállomás-szerver modell nem optimális a rendszerben található számítási és memória er források kihasználása tekintetében, továbbá nem teszi lehet vé, hogy egyetlen, nagy számítás- és memóriaigény feladatokat futtató felhasználó további számítási és memória er forrásokra tegyen szert.

A rendelkezésre álló számítási kapacitás jobb kihasználását célozza a munkaállomás-szerver modell módosításán alapuló processzor pool modell. A modell els dleges célja, hogy a rendelkezésre álló számítási kapacitást dinamikusan, az igényeknek megfelel en ossza szét a felhasználók között. Ebben a modellben akár egyetlen felhasználó is használhatja a processzor pool nyújtotta teljes számítási kapacitást, így nagy rugalmasságot biztosítva a számítási kapacitás rendszeren belüli felhasználásában. A processzor pool modellt támogató elosztott rendszerek egy munkaállomás rendszerb l állnak, amihez hozzácsatoltak egy vagy több processzor poolt. A processzor pool elemei alacsony költség számítógépek, gyakran nem 34

V. fejezet

tartalmaznak mást, mint egy processzort, memóriát és hálózati csatolót. A költségkímélés miatt gyakran ezek a számítógépek egyetlen alaplapra vannak integrálva és osztoznak egy közös tápegységen. A modell segítségével a felhasználók kis hardver er forrásokkal rendelkez számítógépeken, s t hálózati terminálokon ­ mint például az X terminálok ­ is végezhetnek hasznos munkát, hisz a processzor pool nyújtotta számítási kapacitás a rendelkezésükre áll. Ekkor a felhasználó munkaállomása vagy terminálja csak eszközt biztosít a pool számítási kapacitásának kihasználásához. Mint láttuk, ezen modell járulékos hardver elemeket igényel. Egy munkaállomás-szerver modellben a tétlen, kihasználatlan számítási kapacitással rendelkez munkaállomások fölös kapacitását a munkaállomás-szerver modell szoftver kiterjesztésével hasznosítani lehet. Ez nem igényel járulékos hardver elemeket, azonban a terhelés szétosztás gondos körültekintést igényel az azt megvalósító szoftver rendszert l.

Meg kell itt említenünk, hogy a manapság rendelkezésre álló úgynevezett osztott memóriás multiprocesszoros számítógép rendszerek hatékonyan alkalmazhatók mindkét fent ismertetett modell megvalósítására, különösen nagy számításigény , több processzorra szétosztható feladatok megoldására. Ilyen feladatok gyakran jelentkeznek leterhelt szerverek esetén, ott tág tér nyílik ezen architektúra alkalmazása számára.

(5) Konzisztencia karbantartás

Az elosztott rendszerekben a számítási er források széttagoltsága miatt fokozottan kell foglalkozni a konzisztencia kérdésével. Az alábbiakban áttekintjük az elosztott

rendszerekben felmerül különféle konzisztencia problémákat. A legfontosabb konzisztencia típusok:

· frissítés konzisztencia · másolat konzisztencia · cache konzisztencia · hiba konzisztencia · óra konzisztencia

35

V. fejezet

· felhasználói interfész konzisztencia

Frissítés konzisztencia

A frissítés konzisztencia nem csak az elosztott rendszereknél jelentkezik. A probléma számos olyan alkalmazásnál felmerül, ahol osztott adathasználatra van szükség. A legkézenfekv bb ilyen alkalmazások az adatbázis kezel alkalmazások. Az elosztott rendszereknél azonban kiemelten foglalkozni kell a frissítési konzisztenciával, mivel egy elosztott rendszerben nagy valószín séggel nagyon sok felhasználó fér hozzá az osztottan használt adatokhoz (például egy elosztott állományrendszerhez), másrészt magának a rendszernek a m ködése függ bizonyos adatbázisok konzisztenciájától. A rendszerben tehát biztosítani kell, hogy összetartozó adatok változását a folyamatok atominak, azonnal végbemen nek érzékeljék, annak ellenére, hogy technikailag a változások bizonyos id intervallum alatt következnek be.

Másolat konzisztencia

Egy fontos adatforrásról másolatok készítése és a másolatok, replikák használata elterjedt módszer az adatbázisok területén. A másolatok használatának hatékonysági el nyeit az elosztott rendszerekben is kiaknázzák. Azonban a másolatok készítése és használata (amennyiben a másolatokat az egyes felhasználók módosíthatják) magában hordozza az inkonzisztencia veszélyét. Mivel az adatok egy közös forrásból származnak, így a másolatoknak, replikáknak minden pillanatban azonosaknak kell lenniük. Ezt az azonosságot elég nehéz biztosítani, mivel az elosztott rendszerben az információ átadásra egy kommunikációs hálózatot kell használni, ami a fizikai széttagoltság miatt eltér késleltetéseket jelent az egyes komponensek felé. Egy tipikus másolat inkonzisztencia típus, amikor az információt hordozó üzenetek eltér sorrendben érkeznek be az egyes rendszer

komponensekhez, akár a logikai ok-okozat sorrendet is felborítva. Az Internet netnews tipikus példája a másolat inkonzisztenciának. Itt el fordulhat, hogy egy hírcsoportnak küldött üzenet bizonyos csomópontokra inkonzisztens sorrendben érkezik meg ­ a kérdésekre adott válaszok gyakran hamarabb megérkeznek, mint maga a feltett kérdés.

Cache konzisztencia

36

V. fejezet

A cache-elési technikák minden számítógépes rendszerben, így az elosztott rendszerekben is kulcs szerepet töltenek be. Nélkülük számos elosztott szolgáltatás hatékonysága elfogadhatatlan lenne. Például ha egy folyamatnak minden egyes alkalommal igénybe kellene vennie a név feloldási szolgáltatást, ahelyett, hogy a helyi cache-ben keresné ki a kérdéses információt, akkor a rendszer m ködése szinte elfogadhatatlanná válna. Azonban ez a helyzet nagyon hasonlít a másolat konzisztenciánál vázolt helyzethez. Amennyiben a cache-ben tárolt globális adatot egy másik folyamat, csomópont módosítja, akkor a helyi cache-ben tárolt információ érvénytelenné válik. Ezért biztosítani kell valamilyen mechanizmust, amivel a helyi másolatokat frissíteni lehet. Tipikus megoldás, hogy a szerver tárolja, hogy egy adott adat elemet mely csomópontok kérdeztek le, így mely csomópontok lokális cache-ében találhatók meg nagy valószín séggel. Amikor az adott adatelem módosul, a szerver egy üzenetet, értesítést küld az összes érintett csomópontnak.

Hiba konzisztencia

Egy centralizált számítógép rendszer meghibásodása esetén az azon futó folyamatok egyformán érzékelik a hibát, egyszerre hibásodnak meg ­ ilyen rendszerekben egyetlen hibamód jelentkezik. Elosztott rendszerekben ha egy komponens meghibásodik, akkor a többi komponens folytatja futását, még azok is, amik a meghibásodott komponenssel együttm ködtek. Ha azonban az együttm köd komponensek, folyamatok a kés bbiekben függnek a meghibásodott komponens további m ködését l, akkor valamilyen kés bbi id pontban ezek is meghibásodhatnak. Ebb l adódóan eltér fázisban történhetnek újabb meghibásodások. Ez az elosztott rendszerek többszörös hibamódja. Az együttm köd programok eltér pontot érhetnek el a meghibásodásig. Ahhoz, hogy biztosítani lehessen, hogy az összes program által tárolt állandó adatok konzisztensek maradjanak, a meghibásodás után felépülési eljárásokkal az állandó adatokat vissza kell görgetni valamilyen ismert, konzisztens állapotba.

Óra konzisztencia

37

V. fejezet

Az alkalmazásokban és rendszer szoftverekben alkalmazott algoritmusok jelent s része id bélyegeket alkalmaz, konzisztens m ködésük függ az id bélyegekbe foglalt id információ konzisztenciájától. Centralizált rendszerben ez nem jelent problémát, mert egy gépen futó folyamatok ugyanazon id szolgáltatótól ­ ebben az esetben a rendszer órájától ­ szerzik be az id információt. Egy elosztott rendszerben azonban minden folyamat a saját gépnek az óráját használja. Sajnos ezek az órák nem szinkronban járnak, így elosztott rendszerekben a fizikai id kezelése problémát okozhat. A problémát a számítógépek közötti információ küldés véges sebessége és az egyes gépek közötti eltér mérték kommunikációs késleltetés okozza. A konzisztencia biztosítása érdekében az órákat id r l-id re valamilyen módszerrel szinkronizálni kell. Ezek az algoritmusok figyelembe tudják venni a hálózati késleltetést és számos alkalmazás számára kell biztosítani. Szerencsére egy elosztott rendszerben számos esetben nem az abszolút id pontos ismeretére van szükség, hanem események, mint például állományok frissítésének ideje, relatív sorrendje a fontos. Ezen problémára kidolgozták a logikai órákat, amik segítségével az esemény sorrendezés problémája kezelhet az elosztott rendszerekben. pontosságú id információt tudnak

Felhasználói kezel i felület konzisztencia

Ez a probléma els sorban elosztott környezetben futtatott interaktív feladatokra vonatkozik. Ergonómiai mérések azt támasztják alá, hogy az ember 0,1 másodperces késleltetést még nem érzékel megszakításnak. Így az interaktív rendszerekben a válaszid t ez alatt a határ alatt kell tartani. Elosztott rendszerekben, ahol a kezel i felületen végrehajtott változások gyakran valamilyen távoli számítási csomóponton indítanak m veleteket, ez szigorú megkötést jelenthet. Az interaktív késleltetés a felhasználói beavatkozás szerverhez történ elküldésének, feldolgozásának, a válasz visszaküldésének és a képerny állapotának

megváltoztatásához szükséges id k összege. Amennyiben a hálózati késleltetés jelent s, akkor a felhasználó érzékeli az elosztottságot, a rendszer nem lesz átlátszó. Ezen probléma kezelésére is gyakran alkalmazzák a cache-elési technikákat.

38

V. fejezet

I.4.2. Elosztott fájlrendszerek
Az elosztott fájlkezelés a helyi operációs rendszer fájlkezelési szolgáltatásainak kiterjesztése számítógép hálózaton keresztül kapcsolódó számítógépekre. Az elosztott fájlrendszer felhasználói a rendszert alkotó gépeken található fájlokat használják a fájl pontos helyének ismerete nélkül. A fájl lehet helyi (local), azaz a felhasználó számítógépéhez kapcsolódó valamelyik háttértáron elhelyezked , illetve távoli (remote), azaz egy másik számítógéphez csatolt periférián található. Ideális esetben a fájl tényleges elhelyezkedése a felhasználó el tt rejtve van. Az elosztott fájlrendszer az elosztott rendszerek (distributed systems) tipikus alkalmazási példája. Elosztott rendszerek esetén a szolgáltatások hálózatba kötött számítógépeken úgy m ködnek, hogy a felhasználónak (és alkalmazásainak) nincs tudomása azok tényleges elhelyezkedésér l, illetve nem szükséges azt tudniuk, hogy mi módon építhet ki a kapcsolat saját kliens gépeik és a szolgáltatásokat üzemeltet szerver gépek között. (Ezzel ellentétben a hálózati modellben a hasonlóképpen elosztott szolgáltatások eléréséhez szükséges az elérési mód ismerete.) I.4.2.1. Az elosztott fájlrendszer szolgáltatás Elosztott fájlrendszerek esetén a fájlt tároló számítógép a szolgáltató, amely a többi csomópont, az ügyfelek számára szolgáltatásként m veleteket biztosít a fájljain. Bár az el z fejezetben ismertetett Telnet és FTP protokollok is lehet vé teszik a távoli fájl hozzáférést, illetve fájlok mozgatását a hálózatba kapcsolt gépek között, de egyrészt ezek használata külön tudást igényel, másrészt nem használják ki igazán a kliens gép operációs rendszere nyújtotta lehet ségeket. Az elosztott fájlrendszer egy olyan megoldás, amely a felhasználó és alkalmazásai számára a helyi hozzáféréssel azonos módon teszi lehet vé m veletek végrehajtását távoli állományokon. Az elosztott fájlkezelést kezdetben a hagyományos operációs rendszerre épül olyan szoftver réteg valósította meg, amely több operációs rendszer fájlkezelése között teremtett kapcsolatot. A korszer elosztott operációs rendszerek integráns része az elosztott fájlkezelés. Legelterjedtebb a UNIX operációs rendszer NFS (network file system) elosztott fájlrendszere, amely PC alapú operációs rendszerekb l is elérhet . Manapság egyre inkább terjed a PC alapú rendszerekb l kialakult másik elosztott fájlrendszer, az CIFS (Common Internet File System), amely az SMB (Server Message Block) protokollon alapszik.

39

V. fejezet

A fájlokat egyedi nevük alapján azonosíthatjuk. A név a felhasználó el l elrejti a fájl elhelyezkedésének, tárolásának részleteit. Elosztott fájlkezelés esetén a névnek azt is el kell(ene) takarnia, hogy a fájl melyik számítógép háttértárján található. I.4.2.2. Az állományok azonosítása Az állományok azonosításánál két különböz szintet különböztetünk meg, a felhasználói

szint neveket, illetve a rendszerszint fájl-azonosítókat. A fájlkezel feladata a két szint azonosító egymáshoz rendelése.

A fájlnevek és a fájlok a felhasználó számára átlátszó (transparent) egymáshoz rendelésénél két fogalmat különbözhetünk meg: · rejtett elhelyezkedés (location transparency) a fájl neve nem utal arra, hogy az melyik gépen található. · elhelyezkedés függetlenség (location independence) a fájl neve nem változik meg akkor sem, ha a fájl átkerül egy másik gépre.

Szorosan ide tartozik a fájlok az elosztott rendszer felügyelete alatti, kezdeményezésre történ vándorlásának (file migration) fogalma. Míg az els esetben a felhasználói nevek leképzése statikus táblázatok alapján történhet, addig az elhelyezkedés-független elnevezési rendszerben dinamikusan változó leképzési információt kell használni. A jelenleg elterjedt, kiforrott elosztott fájlkezel rendszerek nem támogatják ezt a - lényegesen bonyolultabb - módszert. Az elhelyezkedés-független nevek el nyei: · Az elnevezés elrejt minden, a fizikai tárolással kapcsolatos információt, a fájl az információtárolás teljesen absztrakt fogalma marad. · A fájl vándorlás lehet séget nyújt arra, hogy az elosztott operációs rendszer a rendelkezésre álló teljes háttértár területet egységesen kezelje, a szabad területekkel rendszerszinten gazdálkodjon. Lehet ség van a háttértárak kihasználtságának dinamikus kiegyensúlyozására. · Az elnevezési rendszer szerkezete teljesen független a számítógépek összekapcsolódásának konkrét szerkezetét l, nem szükséges speciális fájlokat - például egy egységes könyvtárstruktúrában a gyökér könyvtárat - el re kijelölt csomópontokon tárolni.

40

V. fejezet

I.4.2.3. Elnevezési módszerek Az elnevezési rendszer feladata, hogy a fájlneveket leképezze konkrét csomópontra és azon belüli fizikai elhelyezkedésre. · Csomópont explicit megnevezése: a fájlokra hivatkozás két részre bontható: a csomópont megnevezése és a csomópont helyi fájlrendszerében a fájl neve; például a VMS operációs rendszerben ::. Bár ez a fajta megnevezés nem felel meg a rejtett elhelyezkedés követelményének, hiszen a felhasználónak a hivatkozásban meg kell jelölnie a fájl konkrét helyét, ám a módszer a hálózati operációs rendszereknél többet nyújt azzal, hogy a távoli fájlokon a helyi fájlokkal teljesen azonos m veletek végezhet k. · A távoli fájlrendszer a helyi könyvtár-hierarchia része: A távoli fájlrendszert - vagy annak egy részét - a helyi könyvtár-hierarchia egy pontjára csatlakoztatják (mount). Ehhez a m velethez meg kell nevezni a távoli gépet is, de ezután az ott lév fájlok a helyi fájlokkal azonos módon kezelhet k. Ez a megoldás található például a UNIX operációs rendszerekben elterjedt NFS (Network File System) rendszerben. A megoldás korlátozott érvény - csak a távoli gépen felajánlott hierarchia-részek láthatók - és egy bizonyos fájlra a hálózat különböz gépein különböz elérési útvonalon kell(het) hivatkozni. · A teljes elosztott rendszert lefed egységes elnevezések: A fájlokra globális, a rendszer egészén érvényes nevekkel hivatkozhatunk.
Megjegyzés: Tetszik a függesztik is, de máshol már a csatlakoztatják mellett maradtunk.

A fentebb felsorolt leképzési módok táblázatok segítségével valósíthatóak meg. Az implementáció lehet ségei és problémái: · Állomány csoportok szerinti leképzés: ha a leképzési táblákban minden fájl szerepel, a táblák kezelhetetlenül nagyokká válhatnak. Célszer bb a fájlokat csoportokba (component units) szervezni és a leképzést ezekre a csoportokra együtt végezni. Például az NFS rendszerben ilyen csoportnak tekinthet k a (távoli) könyvtárak, könyvtár-hierarchiák. · Leképzési táblák többszörözése: a leképzési táblákban tárolt információhoz a rendszer minden csomópontja hozzá kell férjen. Ez megoldható egy központi nyilvántartással is, de így ezt a nyilvántartást kezel

41

V. fejezet

csomópont kiesése a rendszer szétesését vonja maga után. A táblázatok többszörözésének indokai: · decentralizált, hibat r rendszer, · adatbiztonság, · a táblázatok gyors elérése. Nem szükséges a teljes táblázatot a rendszer több csomópontján tárolni, elég lehet a táblázatok egy - a helyi rendszer számára szükséges - részének helyi átmeneti tárolása is (caching). A fájlok vándorlásánál természetesen a leképzési táblákban tárolt információt minden másolatban aktualizálni kell. · Kétszint leképzési táblák: A több leképzési táblában történ módosítást egyszer síti, ha bevezetünk elhelyezkedésfüggetlen alacsonyszint fájl azonosítókat. A "fels " szint leképzés a felhasználói neveket ezekre az azonosítókra képzi le, amelyek tartalmazzák azt, hogy a fájl melyik csoportba tartozik. Egy másik leképzési mechanizmus végzi el a csoportok csomópontokra történ leképzését.

Az elosztott fájlkezelés a fájloknak a rendszerben való megtalálásához szükséges id , a hálózaton történ megbízható adatátvitelhez szükséges információtöbblet és a nagyobb

adminisztrációs teher miatt óhatatlanul lassabb, mint a helyi fájlkezelés, de rejtett szolgáltatás esetén az elosztott fájlkezelés teljesítményének a hagyományos fájlrendszerrel összehasonlíthatónak kell lennie. Az elosztott fájlkezelés teljesítménye növelhet · speciális hardver elemekkel: gyors kommunikációs csatornákkal, a szolgáltatók nagy sebesség háttértáraival, a szolgáltatók speciális architektúrájával, nagy központi táraival; · szoftver módszerekkel: gyors, kevés kiegészít információt tartalmazó kommunikációs protokollokkal, a szolgáltató operációs rendszerének, ütemezési algoritmusainak a feladathoz hangolásával, a szolgáltatónál, illetve az ügyfélnél végzett átmeneti tárolással.

42

V. fejezet

I.4.2.4. Az ügyfelek kéréseinek kielégítése Miután a név alapján a rendszer megtalálta a hivatkozott fájlt, a felhasználó a fájlokon a helyi fájlkezelésnek megfelel m veleteket akarja végezni. Ezt két elvileg különböz , a
Megjegyzés: Ezt inkább számozni, vagy bet zni kellene

gyakorlatban gyakran összefonódó módon lehet elvégezni: a. távoli szolgáltatásokon keresztül A felhasználói m veletek mint kérések eljutnak a szolgáltató csomóponthoz, amely ezen kéréseket végrehajtja, majd az eredményt - amely lehet például a fájlban tárolt információ, illetve a m velet végrehajtásának eredményessége - a hálózaton visszaküldi a kér nek. A hálózaton a szolgáltatóhoz továbbított kérések pontosan megfeleltethet k a helyi fájlrendszer felé kiadott m veleteknek: írás, olvasás, létrehozás, törlés, átnevezés, attribútumok lekérdezése, módosítása. A távoli szolgáltatást tipikusan a távoli eljáráshívás mechanizmusára építve implementálják: Minden a fájlrendszernek szóló m velethez tartozik egy távoli eljárás. Az ügyfél folyamatok a kívánt m velet paramétereit az eljárás paramétereibe írják, majd meghívják a megfelel eljárást. A szolgáltató az eljárás visszaadott paramétereiben válaszol a kérésre. A szolgáltatóban minden távoli eljáráshíváshoz tartozik egy speciális "démon" (daemon) folyamat, amely feladata, hogy a különböz kliensek fel l érkez kéréseket kiszolgálja. A folyamat egy hozzá rendelt kaput (portot) figyel, ha ott egy kérés érkezett, a szükséges m veletet végrehajtja, majd a választ a kérésb l megállapítható feladónak küldi vissza. (Az ügyfél folyamat és a démon között aszimmetrikus megnevezésen alapuló kommunikáció valósul meg. Az ügyfélnek meg kell neveznie egy kaput, és ezzel a hozzá tartozó démont, a démon azonban bárkit l elfogad kéréseket.)

b.

helyi átmeneti tárak segítségével Az elosztott fájlrendszer teljesítményének növelésére, a hálózati adatforgalom csökkentésére a helyi gépek a szükséges fájlokat, illetve azok részeit átmenetileg tárolják, a kívánt m veleteket azon végzik. A módszer elve azonos a virtuális tárkezelésnél megismert átmeneti tárkezeléssel (caching):

ha szükséges, az új információnak helyet csinálunk, a szükséges információt a hálózaton keresztül az átmeneti tárba töltjük, a m veleteket a helyi másolaton végezzük,

43

V. fejezet

változás esetén a módosult információt visszaírjuk a távoli gépre.

A távoli eljáráshívás speciális problémái: · A hálózati kommunikáció nem megbízható. A fájlkezel rendszernek vigyáznia kell arra, hogy minden kérést pontosan (legfeljebb) egyszer hajtson végre. A megoldáshoz a kéréseket az ügyfelek sorszámozzák - id bélyeget (time stamp) f znek hozzá -, a szolgáltató az egyszer már kiszolgált kéréssel azonos sorszámú következ kéréseket elhanyagolja. · Az ügyfél programokban a távoli eljárásokat a szolgáltató megfelel kapuira kell leképezni, ahol a kívánt démon várakozik. A leképzés lehet · statikus, minden m velethez el re kijelölt kapu tartozik; · dinamikus, m veletenként a megfelel kapu számát egy speciális, mindig egy kötött kapuban ücsörg démonnak, a házasságközvetít nek (matchmaker) küldött kérésre adott válaszból kapjuk.

A helyi átmeneti tárak alkalmazásának problémái: · Az átviteli egység méretének meghatározása: A gyakorlatban a különböz rendszerek a háttértár egy blokkjától teljes fájlokig különböz méret egységekben végzik az átvitelt. Figyelembe kell venni: · a rendelkezésre álló átmeneti tár méretét, (ne legyen túl kevés blokk benne); · az alapszint hálózati protokoll illetve az RPC mechanizmusában megengedett blokkméretet.

· Hol legyen az átmeneti tárolás: · általában a helyi gép központi tárában; ez gyors megoldás és háttértár nélküli rendszerekben is alkalmazható. · a helyi gép háttértárján; ami megbízhatóbb, hiszen a helyi gép katasztrófája után is megmarad az átmeneti tárban lév információ, vagy teljes fájlok egy id ben történ másolásánál a központi tár ezeknek a tárolására már nem elegend .
Megjegyzés: ....fogalmazás

· A változások érvényre juttatása (update): A helyi másolaton végzett módosításokat a szolgáltatóval közölni kell. Ez történhet:

44

V. fejezet

· azonnal; lassú, de biztonságos(abb) módszer; · késleltetve (delayed write); gyors, de a helyi rendszer esetleges katasztrófája miatt nem biztonságos megoldás. Az írás történhet: · ha szükség van az átmeneti tárban helyre, · id közönként, · a fájl lezárásakor.

· Az átmeneti tár konzisztenciája: Ugyanazt a fájlt az elosztott rendszerben több ügyfél használhatja egyszerre, amennyiben valamelyik a fájlt megváltoztatja, a többi ügyfél másolata már nem aktuális. A másolat felújítása történhet · az ügyfél kezdeményezésére; az ügyfél, ha "gyanakszik", kérheti a szolgáltatótól annak ellen rzését, hogy a saját másolata helyes-e · minden hozzáférésnél, · a fájl újra megnyitásánál, · id közönként. · a szolgáltató kezdeményezésére; A szolgáltató nyilvántartja összes ügyfelér l, hogy azok mit tárolnak helyileg (speciális üzeneteket igényel az ügyfelekt l), ha a fájljaiban olyan változás van, amely valahol inkonzisztenciát okoz, értesíti az ügyfeleket. Az, hogy a szolgáltató mikor értesíti az ügyfelet arról, hogy a másolata érvénytelen, a rendszerben megvalósítandó elosztott fájlkezelési stratégia (consistency semantics) függvénye: történhet azonnal vagy csak akkor, amikor a fájlt a módosító lezárja. Amennyiben a szolgáltató értesül arról, hogy az ügyfelek mikor és milyen m veletekre nyitnak meg egy fájlt, el relátható problémák esetén már megnyitáskor üzenhet az ügyfélnek, hogy ne alkalmazzon helyi tárolást, hanem használja a távoli szolgáltatásokat.
Megjegyzés: ...nehézkes

A két módszer összehasonlítása

45

V. fejezet

Az átmeneti tárolás el nyei: · a m veletek jelent s része helyben végrehajtható, az ügyfél programjai lényegesen gyorsabban futhatnak, csökken a hálózat illetve a szolgáltató terhelése. · nagy blokkok egyszerre történ átvitele viszonylag gazdaságosabb, mert · a hálózati protokoll a blokk méretéhez képest kevesebb többletinformációt jelent, · a szolgáltató lemezm veletei is gyorsulhatnak, ha egyszerre nagy blokkok átvitelét kérjük.

A távoli szolgáltatás el nyei: · nincs konzisztencia probléma, hiszen a fájl egyetlen példányát a szolgáltató kezeli. A konzisztencia biztosítása bonyolult algoritmusokat, hálózati többletforgalmat igényelne; · ott is m ködik, ahol az ügyfél er forrásai nem teszik lehet vé az átmeneti tárolást; · a távoli szolgáltatások elérésének felülete megfelel a helyi fájlkezel szolgáltatások igénybevételének módjával. I.4.2.5. A szolgáltató implementációja · Állapotot tároló (stateful) szolgáltató: a szolgáltató az ügyfelek kéréseir l, kiszolgálásuk folyamatáról, állapotáról a saját központi tárában információkat tárol. Az új fájlok megnyitásáról értesül, és ehhez egy kapcsolat-leírót készít, amellyel a lezárásig nyomon követi az átvitelt. El nyei: · nagyobb teljesítmény · a fájlokhoz való egymás utáni hozzáférések már egy el készített fájlra hivatkoznak · szekvenciális olvasás esetén a szolgáltató el re olvashat · az ügyfelek átmeneti tárolása miatti konzisztencia problémákat figyelheti, kezelheti. Hátrányai: · a szolgáltató leállásakor az állapotinformáció elveszik újrainduláskor · ilyenkor az ügyfelek átviteli kéréseit nem tudja kiszolgálni, az ügyfeleknek is terminálinuk kell; · az ügyfelekkel konzultálva újra fel kell építenie az elveszett állapotinformációt, ez bonyolult protokollt igényel. · a szolgáltatónak fel kell ismernie, ha egy ügyfél váratlanul terminált (orphan detection), hogy a hozzátartozó állapotinformációt érvénytelenítse.

46

V. fejezet

· Állapot nélküli (stateless) szolgáltató: A szolgáltató az ügyfelekr l nem tárol semmilyen információt, az ügyfelek minden kérése önállóan is kielégíthet . (A fájlok megnyitására és lezárására nincs szükség.) El nye, hogy az állomások meghibásodását jól tolerálja, ha az ügyfél nem kap választ a kérésére, egyszer en újra kísérletezik. Hátránya, hogy lassú, mert · kérésenként több információt kell átvinni; · a fájlt minden kérés kiszolgálásához a helyi fájlrendszerben újra meg kell találni. I.4.2.6. A fájlok többszörözése Az elosztott fájlrendszerekben érdemes lehet egyes fájlokat megsokszorozni (file replication): · növeli a rendszer hibat r képességét, ha a másolatokat olyan csomópontokon helyezzük el, amelyek meghibásodás szempontjából függetlenek egymástól; · gyorsabb kiszolgálást biztosíthat, ha a rendszer megtalálja a "legközelebbi" vagy a legkevésbé terhelt szolgáltatón lév másolatot.

Felmerül problémák: · a fájl megnevezését a felhasználó számára láthatatlanul valamelyik másolathoz kell kötni; · a rendszernek automatikusan kell kezelni a fájlok többszörözését, a másolatok különböz csomópontokon történ elhelyezését, megszüntetését; · a szükséges változtatásokat az összes másolaton el kell végezni.

I.4.3. Folyamatkezelés
Az elosztott rendszerek kialakítását leggyakrabban a kliens-szerver modellel és egy protokollal, a távoli eljáráshívással (remote procedure call, RPC) kötik össze, melyet gyakran használnak a modell megvalósítására. I.4.3.1. Kliens-szerver folyamatok A kliens-szerver modell alapötlete egy szoftver rendszer olyan particionálása, amely meghatározza a rendszer által nyújtott szolgáltatásokat (szervizeket) a hozzájuk tartozó algoritmusokkal (szerverekkel), valamint tartalmazza az adott alkalmazásnak megfelel

47

V. fejezet

kliens programokat, melyek a szerverek szolgáltatásait igénybe véve oldják meg a feladatot a felhasználó számára. Ebben a modelben a kliens alkalmazás programok nem kommunikálnak egymással, hanem direkt módon érik el a szerverek szolgáltatásait. A szervereken úgynevezett démon folyamatok (daemon processes) várják a kliensekt l beérkez kéréseket. Egy démon folyamat általában csak a kapcsolat kezdeti kiépítését végzi el egy, a kliens kiszolgálásához rendelt szerver folyamathoz. A démon folyamatok állandóan futó folyamatok, melyek a szolgáltatás állandó elérhet ségét biztosítják. TCP/IP vagy UDP/IP protokoll feletti kommunikáció esetén a démon egy TCP vagy UDP porthoz kötött folyamat, amely a porton beérkez kérésekhez rendel kiszolgáló rutint. UNIX rendszer alatt az önálló folyamatokon kívül létezik egy általános megoldás is a feladat elvégzésére: az internet démon (internet daemon, röviden inetd). Ennek több TCP és UDP port, és a hozzájuk tartozó szerver program is megadható egy erre szolgáló konfigurációs fájlban (inetd.conf), így egyetlen folyamattal lehet megvalósítani a kérések fogadását. A démon folyamatok UNIX alatt a háttérben futnak, nem tartozik hozzájuk terminál viszony. Elindulásuk után elszakadnak a terminál kapcsolatuktól, ily módon garantálva azt, hogy a terminál kapcsolat lebomlása után is tovább fussanak. A hálózati számítási modellben (amelynek alappillére a kliens-szerver modell) a szerverek eléréséhez a kliens alkalmazásoknak tisztában kell lenni a szerverek pontos címével (pl. IP cím és portszám), a szolgáltatásuk elérésének módjával, valamint a kapott eredmények értelmezésével. Az elosztott számítási modell szintén alkalmazza a kliens-szerver megközelítést, de ebben az esetben a kliens els sorban a szerverek által nyújtott szolgáltatások alapján éri el a szervert, mintsem annak címének pontos ismerete alapján. Egy elosztott rendszerben a kliens-szerver kapcsolat kiépítését egy külön kommunikációs közbüls réteg (middleware) biztosítja. Rengeteg példát találunk kliens-szerver rendszerekre, mint a fájl szerverek (hálózati fájlmegosztás), adatbázis szerverek, hálózati autentikációs szerverek, web szerverek, stb. Ezek túlnyomó többsége a hálózati számítási modell követi, kisebb részük, mint pl. az NFS és az elosztott objektum-orientált rendszerekre épül alkalmazások az eloszott számítási modell felé közelítenek. Egy elosztott környezetben a szerverek egyszerre több klienssel is kapcsolatban állnak, és a kliensek egy id ben több szerver szolgáltatásait is igénybe vehetik. A kliens és szerver folyamatokat tervezésük során alkalmassá kell tenni az ilyen többirányú kapcsolatok

48

V. fejezet

kiépítésére. Egy kliens és egy szerver közötti kapcsolat kiépítése, a kötés (binding) az a folyamat ami során a kliens megtalálja a számára szükséges szolgáltatást nyújtó szervert, és kettejük között kialakul a kommunikációs kapcsolat. Többféle kötési rendszer létezik, azaz többféle módot választhatunk a szerver kiválasztására és a kapcsolat kiépítésére. Például egy web szerver esetén a kliens (web böngész ) a szerver címének (internet cím és portszám) ismeretében a HTTP protokollban meghatározottak szerint küld egy üzenetet a szervernek. A szerver általában külön kiszolgáló eljárást rendel a klienshez (hogy egy id ben több kérést is kiszolgálhasson), mely értelmezi a klienst l kapott üzenetet, elkészíti a választ és elküldi a kliensnek. A kliens-szerver kapcsolat a Web rendszerben ekkor le is bomlik (nem perzisztens). Ha a gépünk óráját akarjuk beállítani, akkor ezt olyan kliens program segítségével is megtehetjük, amely nem közvetlenül egy szervert szólít meg a feladat megoldására, hanem a hálózatra egy szórt (broadcast) üzenetet küld, és az összes szervert l beérkez válasz alapján állítja be gépünk óráját. A kötés folyamatát tovább bonyolíthatja, ha alkalmazásuk megbízhatóságának növelése, nagyobb adatbiztonság, vagy egyszer en csak a gyorsabb válaszid k érdekében több, konkurrens, ugyanazt a szolgáltatást nyújtó szervert is üzemeltetünk. Ez a replikáció (replication). Egy szerver kiesése (pl. az NFS rendszerben egy fájlszervíz leállása) ilyenkor a kliens-szerver kötés megváltozását eredményezheti (NFS esetében a fájl szervíz tartalék szervere szolgálja ki a következ kliens kérést), gyakran olyan módon, melyr l a kliens nem is szerez tudomást. Átmeneti gyorsítótárak alkalmazása (caching) szorosan összefügg a replikációval. Ez a fájlrendszereknél és adminisztrációs adatbázisoknál gyakran alkalmazott technika a kliens által gyakran kért információt egy helyi átmeneti tárolóban helyezi el a klienshez közel. Ily módon a következ megegyez kérés kiszolgálási sebessége megn , ugyanakkor az adatok konzisztenciájának biztosítása nagyobb feladatokat ró a szerver kidolgozójára. Az elosztott gyorsítótárak egy speciális fajtája a proxy, mely els sorban a web szerverek területén elterjedt. A proxy egy olyan szervert takar, amelyik valamilyen más szerveren tárolt információt helyileg is meg riz a kliensek számára. A proxy általában nem közvetlenül a szervert l kérdezi le az adatokat, hanem egy másik, a szerverhez a hálózaton közelebb elhelyezked proxy-tól. Ily módon a proxy szerverek egy hierarchikus rendszer alkotnak, amelyben egy kliens kérés addig továbbítódik a adatot eredetileg tároló szerver felé, míg egy

49

V. fejezet

proxy átmeneti tárában azt meg nem találja. Egy proxy rendszer els sorban a hálózati kapcsolat lassúsága miatti id késést hivatott csökkenteni. Kliensek és szerverek közötti kommunikáció kialakításának legelterjedtebb formája a távoli eljáráshívás (remote procedure call, RPC). Ennek során a szolgáltatásokat eljárások valósítják meg, a kliensek pedig a szolgáltatásokat az eljárások meghívásával veszik igénybe. A távoli eljárások meghívása az alkalmazások szempontjából nagyon hasonlatos a helyi eljárások meghívására ­ a lényeges különbséget (a hálózati kapcsolat kialakítását, az adatok átjuttatását és az eredmények visszaküldését) a távoli eljárást megvalósító rendszer elfedi az alkalmazások el l. I.4.3.2. Távoli eljáráshívás - RPC Az RPC rendszer egy protokoll leírást és egy programozói interfészt tartalmaz. Alapvet en egy kliens gép számára lehet vé teszi, hogy egy kiválasztott szerver gépen egy el re meghatározott eljárást lefuttasson. A kliens gépen futó folyamat eljárás hívása a szerver gépen futó folyamat egy eljárásának meghívását eredményezi. A bemen paraméterek és a

visszatérési érték átvitelér l, valamint a szerver eljárás meghívásáról az RPC alrendszer gondoskodik. Több magasabb szint szolgáltatás épül az RPC rendszerre, mint például az NFS (Network File System) és a NIS (Network Information System). Az RPC protokoll alapvet en a kliens és a szerver közötti kommunikáció adatformátumát határozza meg. Ezen kívül foglalkozik az üzenetek átvitelének mechanizmusával, illetve a kapcsolatban álló felek azonosításával is. A protokoll megbízható kapcsolatot épít ki a kommunikáló felek között, azaz garantálja a kérések továbbítását a célállomásig, illetve a válaszok visszajuttatását. Bár az RPC alapvet en szállítási protokoll független rendszer, általában UDP/IP (User Datagram Protocol / Internet Protocol) felett implementálják, mely alapvet en megbízhatatlan (ellentétben a TCP/IP protokollal). Az RPC réteg feladata a biztonságos átvitel megvalósítása az üzenetek periodikus megismétlésével a nyugtázás vételéig.

50

V. fejezet

(1) RPC hívás xid direction (= hívás) rpc_vers (= 2) prog vers proc autentikációs információ eljárás-specifikus argumentumok

(2) RPC válasz xid direction (= válasz) reply_stat autentikációs információs accept_stat eljárás-specifikus eredmények

I.4.3.3. Az RPC üzenetek felépítése Az ábra egy tipikus RPC kérés-válasz párt szemléltet. Az xid az átvitel azonosító, mely egyértelm en megjelöli a kérést. Az azonosítót a kliens egyedileg készíti minden üzenete számára, a szerver pedig ugyanezt az azonosítót alkalmazza a válaszában. Ily módon a kliens egyértelm en azonosítani tudja azokat a kéréseket, amelyekre választ kapott a szervert l. A direction mez azt jelzi, hogy az aktuális üzenet és kérés, vagy egy válasz. Az rpc_vers mez az RPC protokoll verziószámát rögzíti, a prog és vers azonosítók a szerver folyamat (RPC szolgáltatás) program és verzió azonosítói. Ezek után az azonosítással kapcsolatos információk következnek, majd a kérésben a meghívott eljárás paraméterei, a válaszban pedig az eljárástól érkez eredmények. Az RPC egy egységes, ún. kiterjesztett adat reprezentációt (Extended Data Representation ­ XDR) használ a hálózati adatforgalomban. Az XDR szabvány (Sun Microsystems) egy gépfüggetlen adatábrázolási mód. Többféle egyszer adattípust definiál, illetve szabályokat határoz meg bonyolultabb adatstruktúrák létrehozására. Alapvet adattípusai a következ ek: · Egész szám 32 bites entitás, ahol a 0. bájt reprezentálja a legnagyobb helyiérték bájtot. El jeles egészeket kettes komplemens alakban tárolnak.

51

V. fejezet

· Változó hosszúságú adatfolyam Egy négy bájtos hossz mez vel leírt adat. A hossz mez után az adatfolyam következik. Az adatot nullák egészítik ki a négy bájtos határig. · Szöveg Az adatfolyamhoz hasonlóan egy hossz mez vel kezd d ASCII karaktersorozat, nullákkal kiegészítve a négy bájtos határra (amennyiben a szöveg hossza épp néggyel osztható, nincs lezáró nulla ellentétben a UNIX rendszereknél szokásos gyakorlattal). · Tömb Azonos típusú elemekb l álló vektor, mely szintén egy négy bájtos hossz mez vel kezd dik, majd a vektor elemei következnek. Minden elemnek néggyel osztható hosszúságúnak kell lennie. Bár az elemeknek azonos típusúnak kell lenniük, hosszuk különbözhet (pl. szövegekb l álló tömb esetén). · Struktúra A struktúrák komponenseit sorrendben tárolja a szabvány azzal a megkötéssel, hogy minden komponens hosszát néggyel oszthatóra igazítja nullák beszúrásával. Az adatstruktúrák meghatározásán kívül az XDR egy formális nyelvet is bevezet az adatok leírására. Az RPC rendszer is ezen nyelv kiterjesztését használja a távoli eljáráshívás formális leírására. Az XDR alapvet hátránya, hogy az adatreprezentációjától jelent sen eltér reprezentációt használó architektúrákon er forrásigényes lehet a szükséges konverziók megvalósítása. Ez elkerülhet lenne, ha az adatok átalakítása helyett a kommunikációban részt vev felek

egymás adatreprezentációs különbségeiket tisztáznák csak. Ilyen megoldást alkalmaz a DCE (Distributed Computing Environment, OSF 1992) RPC az XDR helyett. Az RPC az adatcserén és a távoli eljárások meghívásán kívül programozási eszközöket is nyújt a kommunikációs szoftverek megvalósításához. A már említett RPC nyelv, mely az XDR formalizmusát követi, alkalmas a szerver interfészének formális leírására. A formális leírásból az rpcgen program képes a szerver és a kliens programok megfelel részeit,

valamint a szükséges XDR konverziós függvényeket elkészíteni C nyelven. Az így kapott C forráskódú modulokat a kliens és szerver alkalmazással kib vítve kapjuk a teljes kommunikáló rendszert. A következ programlista egy egyszer távoli id szerver interfészét mutatja.
/*

52

V. fejezet

* date.x - Specification of remote date and time service. */ /* * Define 2 procedures: * bin_date_1() returns the binary time and date (no arguments). * str_date_1() takes a binary time, returns a human-readable string. */ program DATE_PROG { version DATE_VERS { long string } = 1; } = 0x31234568; BIN_DATE(void) = 1; STR_DATE(long) = 2; /* procedure number = 1 */ /* procedure number = 2 */ /* version number = 1 */ /* program number = 0x31234568 */

I.4.3.4. Szálak alkalmazásának el nyei A mai RPC rendszerekhez általában szorosan kapcsolódik a szálak (threads) alkalmazása, mely lehet vé teszi egy program számára, hogy több feladatot is végrehajtson egyazon id ben. Bár a szálaknak kevés köze van a hálózati kommunikációhoz, mégis gyakran alkalmazzák ket a kliens-szerver rendszerekben. Használatukkal ugyanis lehet vé válik a kliens kérések párhuzamos kiszolgálása, illetve párhuzamos szerver kérések elküldése egyazon folyamaton belül. A szálak alkalmazásának több el nye is. Ezek egy része a szerverek teljesítményét növeli, más részük a tervezéskor és megvalósításkor könnyíti a programozók dolgát. Képzeljük el a következ példát! Egy RPC szerver a klienst l érkez feladata megoldásához más szerverek szolgáltatását is igénybe veszi. Azok további szervereket kapcsolnak a feladat megoldásába, míg végül valamelyikük az eredeti kliens valamely szolgáltatását szeretné igénybe venni. Kialakult a holtpont. Helyi függvényhívások esetén ez rekurzióhoz vezetne, az RPC esetén azonban holtpont alakul ki. Ez a helyzet feloldható a szálak alkalmazásával. Ha az RPC szerver a beérkez eljáráshívásokhoz különálló szálakat rendel (melyek a

folyamatokkal ellentétben képesek ugyanazon adatstruktúrákon dolgozni), a holtpont feloldódik, átalakul rekurzióvá. A szálak alkalmazásával mind a szerverek, mind a kliensek párhuzamosíthatják futásukat az RPC kommunikáció alatt. A szerverek minden beérkez RPC kérésre különálló szálat

53

V. fejezet

indítanak el (adott maximumig). A kliens a távoli eljárást egy külön szálban indítja el, így annak eredményére várakozva más feladatokat is megoldhat. Egy távoli eljárás meghívása során a kliens és szerver programokban létrejöv szálakat logikailag egy szállá foghatjuk össze. Ez az RPC szál (RPC thread). Az RPC szál a kliens oldalon keletkezik (mint kliens szál), majd kiterjeszt dik a hálózaton keresztül a szerverre, ahol szerver szállá válik, amin belül végrehajtódik a távoli eljárás. Az eljárás lefutása után a szál ,,visszatér" a klienshez és ismét kliens szálként szolgáltatja a függvény visszatérési értékeit. A szerver egyszerre több RPC szálat is fogadhat a kliens kérések kiszolgálása érdekében. Praktikusan létezik a szerverben párhuzamosan futtatható szálak számának egy maximális értéke, mely után a következ beérkez RPC szál várakozni kezd mindaddíg, míg egy szerver szálnak létrehozása lehet vé nem válik. Ez a mechanizmus része a DCE (Distributed Computing Environment) 1.1 RPC specifikációjának. A szálak természetesen nem csak a távoli eljáráshívás modelljében használatosak. A mai korszer operációs rendszerek mindegyike kínál megoldást a szálak létrehozására. Szálak alkalmazásával általában egyszer bben megvalósítható konkurrens futási környezetet alakíthatunk ki. Lehet vé válik a párhuzamos feldolgozás a lehet legkisebb vízfejjel ­ mind kernel, mind alkalmazás szinten. A kernel a szálak közötti váltást lényegesen kevesebb adminisztrációval oldja meg, míg az alkalmazások mentesülnek a folyamatok közötti kommunikációs terhekt l a szálak közötti adatcserében. A szálak alkalmazásának ugyanakkor vannak hátrányai is. Szálakat alkalmazó programoknál sokkal körültekint bben kell eljárni a tervezés során. A szálak okozta konkurrens adat- és er forrás hozzáférés az alkalmazás készít jére hárítja a kölcsönös kizárás tervezésének és megvalósításának feladatát. E nélkül a többszálú rendszer adatai könnyen inkonzisztens állapotba kerülhetnek. Másrészt a szálak futása nem szakad el teljesen a folyamat futásától. Egy operációs rendszerben a szálak megvalósításától függhet a folyamatok és a szálak futási viszonya és viselkedése. Amennyiben a szálakat felhasználói szinten, a kernelt l függetlenül valósítják meg (user-level threads) és egy szál kiad egy olyan rendszerhívást, ami blokkolható, az egész folyamat futása blokkolódik. Kernel szint szálak megvalósítása esetén (kernel-level threads) ez a probléma nem áll fent. Ez azonban újabb követelményeket jelent a rendszerhívások megvalósításával szemben. Az ilyen operációs rendszerek külön jelzik, ha egy rendszerhívás biztonságos a szálak szempontjából (thread-safe). Ett l eltér esetben (a

54

V. fejezet

gyakorlati esetek többségében) a szálakban a rendszerhívások alkalmazása gondosan tervezend (például kölcsönös kizárás alkalmazásával) az újrahívások elkerülése végett.

I.4.4. Id kezelés és koordináció elosztott rendszerekben

Mint azt korábban láttuk, az elosztott rendszerek számos tekintetben eltér követelményeket támasztanak a rendszer funkcióival és kialakításaival szemben, mint a centralizált rendszerek. Az id kezelés sem kivétel ez alól: elosztott rendszerekben az id , és annak konzisztens kezelése központi jelent ség . Egyes alkalmazásokban a pontos, valós id re van szükség (pl. naplózás, számlakezelés), míg az esetek jelent s részében elegend olyan id kezelés, amely biztosítja a rendszerben bekövetkez események sorrendezését. Az alábbiakban áttekintjük az ezen feladatok ellátásával kapcsolatos fogalmakat és a szükséges eszközöket.

I.4.4.1. Id kezelés

Az id kezelés két alapvet funkciót hivatott támogatni: a valós id pontos ismeretét (ami elengedhetetlen pl. naplózási, számlázási feladatok ellátásához), illetve a rendszerben bekövetkezett események sorrendezését (event ordering). Ez a két feladat eltér igényeket támaszt az id kezeléssel szemben, és mint azt majd látni fogjuk, az el bbit fizikai órák, míg az utóbbit logikai órák használatával lehet a leghatékonyabban megoldani.

(1) Koordinált Univerzális Id (KUI)

Az emberek életében az id kitüntetett szerepet tölt be. Míg a hétköznapi életben nagyon gyakran megelégszünk az id ,,hozzávet leges" ismeretével, számos, els sorban csillagászati alkalmazások ennél precízebb id fogalmat igényelnek. Ma az id mérésére a legpontosabb eszköz az atomóra. Ennek pontossága 10-13 sec/sec. A Nemzetközi Atomid az atomóra pontosságával méri az eltelt id t, mely szerint egy másodperc 9192631777 átmenet a Cs133 alapállapotának 2 hiperfinom szintje között. Ez pontos id mérést tesz lehet vé. Azonban az emberiség az id t a csillagászati id höz igazítja, 55

V. fejezet

így bevezették a Koordinált Univerzális Id

- KUI (Coordinated Universal Time)

fogalmát, aminél meghatározott id közönként szök másodperceket kell beiktatni, vagy törölni. Ezt a koordinált univerzális id t használják a valós fizikai id etalonjaként. Ezt az id t rádióállomások (pl. az amerikai WWV), rszondák (pl. Geostationary Operational

Environmental Satellites (GOES)), Global Positioning System (GPS) sugározzák, így amennyiben küls szinkronizálásra van szükség, akkor az ezeket a jelet vev berendezések segítségével ez megtehet . A szinkronizálás pontossága az alkalmazott módszert l függ en 0.1-10 miliszekundumos nagyságrendbe esik. Ezen berendezések alkalmazásánál azonban a jel vételének módját figyelembe kell venni, mert az meghatározza a szinkronizálás pontosságát. Ha például Magyarország keleti és nyugati határánál egy-egy id szolgáltató egy közeli földi rádióállomás alapján szinkronizál a KUI-hez, akkor ezen két id szolgáltató órája között nagyságrendileg miliszekundumos eltérés lesz. Ennek oka az eltér terjedési id , ami sajnos a légköri zavarok miatt nem becsülhet pontosan.

(2) A valós, fizikai id kezelése

A valós fizikai id mérésére a rendszer órája szolgál. Egy centralizált rendszerben ez egyetlen órát jelent, míg elosztott rendszerben a rendszer minden egyes számítási csomópontja tartalmazhat egy saját fizikai órát. Ekkor nagyon fontos, hogy biztosítsuk ezen fizikai órák együtt járását. Mivel az órák referencia jelét egy analóg berendezés (tipikusan egy kvarc oszcillátor) szolgáltatja, így a referencia jelek adott pontosságúak. A kvarc oszcillátorok tipikusan 10-6­10-7 sec/sec pontosságúak. Ebb l adódóan az egyes órák a rendszerben csúsznak egymáshoz képest, így azokat id r l-id re szinkronizálni kell, hogy a rendszerben adott pontossággal tudjunk egy úgynevezett globális id t mérni.

Elosztott rendszerekben nagyon gyakran az az elvárás, hogy az egyes órák adott pontossággal együtt járjanak. Ezt a követelményt a bels szinkronizációval tudjuk biztosítani. Ekkor az órák az id r l-id re elvégzett szinkronizálás miatt együtt járnak, egymáshoz képest nem csúsznak, pontosabban a csúszás jól kontrollált. Ezzel szemben bizonyos esetekben az elosztott rendszer együtt m ködik más rendszerekkel, és elvárás, hogy az órák a valódi fizikai 56

V. fejezet

id t mérjék. Ilyenkor nem elég, hogy a rendszer órái egymáshoz képest nem csúsznak, a valós fizikai id höz, a Koordinált Univerzális Id höz képest sem csúszhatnak. Ezt a küls szinkronizálással lehet elérni, amikor id r l-id re a Koordinált Univerzális Id höz szinkronizál a rendszer.

A továbbiakban vázlatosan áttekintjük az elosztott rendszerekben alkalmazott legismertebb óra rendszereket.

(3) Elosztott rendszerekben alkalmazott óra rendszerek Elosztott rendszerekben három típusú óra rendszert szokás alkalmazni a fizikai id nyilvántartására: a pontos központi órával rendelkez rendszereket, a központilag felügyelt órákkal rendelkez rendszereket és a teljesen elosztott órás rendszereket. Az alábbiakban ezen rendszerek f bb tulajdonságait adjuk meg.

(1) Pontos központi órával rendelkez rendszerek A pontos központi órával rendelkez rendelkeznek: rendszerek az alábbi jellemz tulajdonságokkal

· Egy pontos óra szolgáltatja az id t az egész rendszernek. (A többi óra jelenlétér l nem veszünk tudomást, amíg a központi óra meg nem hibásodik.) · A hibat rés meleg tartalékként jelenik meg. Ha a központi pontos óra meghibásodik, egy másik óra veszi át a szerepét. · A módszer pontos (az alkalmazott órától függ en ns - ms), de drága. · Speciális, a processzorba integrált hardvert igényel. Az óra ezt állítja, a többi folyamat ezt olvassa. · Kommunikációs költség alacsony: 1 üzenet/szinkronizáció/hely, vagy broadcast. · Példa: GPS, 4 szatelit , körülbelül ns-os pontosság.

(2) Központilag felügyelt órákkal rendelkez rendszerek (master -slave) A központilag felügyelt órákkal rendelkez rendszerek az alábbi jellemz tulajdonságokkal rendelkeznek:

57

V. fejezet

· A pontosnak elfogadott master óra lekérdezi a slave-eket. · Csúszásokat mér, korrekciót küld a slave-eknek. · Ha a master meghibásodik, akkor valamilyen választási algoritmus alapján egy új mastert kell választani. · Az átviteli id t becsülik.

(3) Elosztott órás rendszerek Az elosztott órás rendszerek az alábbi jellemz tulajdonságokkal rendelkeznek:

· Minden hely homogén, azonos algoritmust futtat. · Minden hely a többi óra üzenete alapján frissíti a saját óráját (becsüli saját pontosságát). · A hibat rés protokoll alapú. A csomópontok észreveszik, ha valamelyik óra meghibásodott, és figyelmen kívül hagyják annak értékét. · Nagy kommunikációs költség.

Az órák szinkronizálásánál nem szabad azzal a naiv feltételezéssel élni, hogy elég ismerni az egyes órák közötti eltérést, és akkor megoldható a szinkronizálás. Ez a gondolatmenet azért hibás, mert az egyes órák csúsznak (drift) egymáshoz képest. A kvarc oszcillátor alapú órák is csúsznak, vagyis az id t más "frekvenciával" mérik, mint a pontos referencia óra, így az általuk mutatott id egyre jobban eltér attól. A csúszás lehet nagyon pici, de ez az id múltával akkumulálódik. Például kvarc oszcillátoros órák esetén 10-6 sec/sec pontosságot feltételezve 1000000 másodperc, vagyis 11.6 nap alatt csúsznak 1 másodpercet.

(4) Óracsúszás kompenzálása

Egy adott gép órája kétféleképpen csúszhat a valós, pontos órához képest: késhet, illetve siethet. Az els esetet viszonylag egyszer en le lehet kezelni. Ha a valós id t Tval, a pontatlan lokális id t Tlok jelöli, és Tval > Tlok, akkor Tlok := Tval állítással a problémát meg lehet oldani. Ez a módosítás teljesíti a természetes elvárást, hogy az id értéke növekedjen. Sajnos ennél nehezebb problémával találjuk szemben magunkat, ha a lokális óra siet. Nem tehetjük meg,

58

V. fejezet

hogy egyszer en visszaállítjuk, mert ekkor az a feltételezés, hogy az id el re halad nem teljesülne. (Például a Unix make csak azokat az állományokat fordítja újra, amelyeknek a forrása frissebb, mint a hozzájuk tartozó object állomány. Ha megengednénk az óra

visszaállítását, akkor el állhatna az az eset, hogy módosítunk egy forrás állományt, és a make mégsem fordítja újra, mert közben a szinkronizálás miatt az órát a rendszer visszaállította, és így az object állomány kés bbinek t nik.) Így azt kell elérni, hogy az óra lassabban járjon. A hardver órát általában nem lehet lassítani, így a szoftver órát kell állítani. Az alábbiakban ismertetünk egy óracsúszás kompenzációs algoritmust. Ehhez az alábbi jelöléseket vezetjük be: S(t):szoftver óra H(t): hardver óra

(t):kompenzáció
S(t) = H(t) + (t)

Amennyiben a módosítást folytonosnak szeretnénk, akkor (t) legyen egy lineáris függvény:

(t) = aH(t) + b
Tegyük fel, hogy S(t) = Tcsúszás amikor H(t) = h, és ekkor a pontos referencia óra Tvalódi-t mutat. Ha azt akarjuk elérni, hogy S N további tikk (óra ütés) után mutassa a pontos id t, akkor

Tcsúszás = (1+a)h + b Tvalódi+N = (1+a)(h+N) + b innen

a = (Tvalódi - Tcsúszás)/N és b = Tcsúszás - (1+a)h

59

V. fejezet

Tehát ezt a módszert alkalmazva elérhet , hogy a szoftver órát úgy járassuk lassabban, hogy az N tikk, vagyis óraütés múlva a pontos id t mutassa.

(5) Óra szinkronizációs módszerek

Az alábbiakban vázlatosan áttekintünk három óra szinkronizációs módszert.

(1) Cristian algoritmus Cristian algoritmusa átmenet a pontos központi órával rendelkez és a központilag felügyelt órás rendszerek között. Az algoritmus feltételez egy pontos id szolgáltatót, amihez a kliensek id kéréseket juttatnak el, ha a pontos id re van szükségük. Amikor az id szolgáltató kap egy id kérést, a nagyobb pontosság érdekében a válaszul összeállított üzenetbe a lehet legutolsó pillanatban helyezi bele az id t. Ezt az üzenetet visszaküldi a kliensnek. A kliens a megkapott üzenetb l kiolvassa az id t és kompenzálja az átviteli id vel. A nagyobb pontosság elérése érdekében az oda-vissza üzenet úthoz tartozó id átlagával kompenzál. Az átviteli id t úgy modellezi, hogy Tátvitel = min + x, vagyis az átvitelt felbontja két komponensre: a min azt az id t jelöli, amennyi id t az átvitel akkor igényelne, ha csak az id t kér folyamat futna és nem lenne más hálózati forgalom, illetve egy járulékos tagra, ami a többi folyamat és a többi hálózati forgalom hatását modellezi. Ezzel a modellel a szinkronizálás pontosságára a ±(Toda-vissza/2-min) eredmény adódik.

(2) A Berkeley algoritmus A Berkeley algoritmus egy tipikus master-slave algoritmus. Itt a Cristian algoritmussal ellentétben a master folyamatosan lekérdezi a slave órákat és kiszámítja az egyes órák csúszásait. Továbbá nem a master által mutatott id t küldi el a slave-eknek, hanem a csúszást, ezáltal csökkentve az átviteli késleltetés okozta pontatlanságot. A nagyobb pontosság érdekében a kompenzációra felhasznált értékeket átlagolja, ezáltal a kommunikációs csatorna változó késleltetését és egyéb járulékos hibáit is csökkenti. Az algoritmus már hibat r tulajdonságokkal rendelkezik. Egyrészt a kirívó értékeket figyelmen kívül hagyja, másrészt amennyiben a master csomópont meghibásodik, egy (a kés bbiek folyamán tárgyalt)

60

V. fejezet

választási algoritmussal új master csomópont kerül megválasztásra. Az algoritmussal elért pontosság durván 20 - 25 ms.

(3) A Network Time Protocol A Network Time Protocol egy id szolgáltató architektúrát és protokollt ír le, amit eltér hálózatokból összekötött elosztott rendszerben az id információ terjesztésére lehet használni. Ez az algoritmus képezi az Internetes óra szinkronizáció alapját. A megtervezésénél az alábbi f bb szempontokat vették figyelembe:

· kliensek pontosan szinkronizálhassanak a KUI-hez · megbízható szolgáltatás legyen, éljen túl hosszú idej szétcsatolást · kell en gyakori szinkronizálást tegyen lehet vé · védjen id szolgáltatás hamisítás ellen

Ennek megvalósítása érdekében egy hierarchikus struktúrát építettek ki. Az algoritmus terminológiájában a stratum a szinteket jelöli a hierarchiában. Az 1-es stratumon az úgynevezett els dleges id szolgáltatók helyezkednek el, amelyek valamilyen célberendezés segítségével közvetlenül a KUI-hoz szinkronizálnak. A 2-es stratumon másodlagos id szolgáltatók helyezkednek el, amelyek els dleges id szolgáltatókhoz szinkronizálnak. A sémából jól látszik, hogy minél magasabb stratumon helyezkedik el egy id szolgáltató, annál távolabb van a KUI-t l, így annál pontatlanabb az általa szolgáltatott id , viszont annál kisebb a költsége. Nagyon sok alkalmazás nem igényli, hogy az általa ,,látott" id KUI pontosságú legyen, számos alkalmazásnál elegend olyan óra pontosság, amit a hétköznapi életünkben használunk. A struktúra er sen hibat r tulajdonságot mutatja. A rendszerben három típusú szinkronizálás valósul meg: és a ,,graceful degradation" (elegáns letörés)

1. multicast (LAN) ­ Kis késleltetést feltételez, pontatlan, de sok alkalmazás számára ez a pontosság is elégséges. 2. eljáráshívás ­ Kliens-szerver modellt alkalmaz, nagyobb pontosságot ér el az el bbi típusnál. Akkor alkalmazzák, ha nagyobb pontosságot kell elérni, vagy ha a multicast nem támogatott.

61

V. fejezet

3. szimmetrikus mód ­ alakú üzeneteket használ. A gépek az utolsó nyolcat tárolják, a legkisebb késleltetés t választják.

Míg 1991-ben megközelít leg 20 - 30 els dleges szerver és 2000 másodlagos szerver kapcsolódott az Internethez, addig ezek a számok mára nagyságrendekkel növekedtek. A Network Time Protocol-lal megközelít leg 30 miliszekundumos pontosság érhet el. Itt meg kell jegyezni, hogy ez az id szolgáltatás úgynevezett best-effort szolgáltatás, nincs garantált id korlát.

(6) Logikai id és logikai órák

Az eddigiekben tárgyaltuk a fizikai órákat és kezelésüket, els sorban az elosztott rendszerek óráinak szinkronizálási kérdéseire koncentráltunk. A bevezet ben említettük, hogy az egyik legfontosabb id kezeléssel kapcsolatos feladat az esemény sorrendezés. Míg tetsz leges folyamatban a folyamat eseményeit egyértelm en sorba lehet rendezni a folyamat fizikai órája alapján, addig elosztott rendszerekben sajnos fizikai órát nem lehet események sorrendezésére használni, mert a folyamatok fizikai óráit nem lehet tökéletesen szinkronizálni. Ezért szükség van valamilyen módszerre, amely biztosítja a folyamatok eseményeinek sorrendezését elosztott környezetben. Már korábban is láttuk, hogy erre a feladatra a fizikai órák nem igazán alkalmasak. Ezt támasztja alá az is, hogy például 10 ms-os pontosságot figyelembe véve, ez a pontosság nem elégséges számos alkalmazás számára azok eseményeinek sorrendezésére. Egy 10 MIPS-es gép ennyi id alatt 100000 utasítást végez el, ami alatt számos, például szinkronizációs esemény következhet be. Ebb l jól látszik, hogy ha a rendszerben az események az óra felbontásánál gyakrabban (nagyobb frekvenciával) következnek be, akkor azokat fizikai órával nem lehet sorrendezni, szükség van valamilyen, kifejezetten az események sorrendezését támogató absztrakcióra.

Miel tt rátérnénk a módszer tárgyalására, definiáljuk a korábban-történt (happened before) relációt. Ennek értelmezéséhez tekintsük el ször azonban az alábbi két triviálisnak t n kijelentést:

62

V. fejezet

1. Ha két esemény ugyanabban a folyamatban történt, akkor azok sorrendje megegyezik azzal a sorrenddel, ahogyan azt a folyamat látja. 2. Amikor egy folyamat üzenetet küld egy másik folyamatnak, akkor az üzenet elküldése megel zi az üzenet megkapását.

Ezek után már definiálható a korábban-történt (KT) reláció, az alábbi jelölésekkel:

x y

P

: x és y két esemény, mindkett egyazon P folyamatban történt, és
x megel zte y-t.

x y

: x korábban-történt relációban van y-nal (x és y nem egy folyamat eseményei)

KT1: Ha P folyamat, melyre KT2: m üzenetre
- -

x y

P

, akkor

x y

send( m) rcv( m)

, ahol

send(m) az üzenet elküldésének, rcv(m) pedig az üzenet megkapásának eseménye.

KT3: Ha x, y és z olyan események, amelyekre x y és y z , akkor x z

Ezek után már bevezethetjük a logikai órákat.

Logikai órák

A korábban-történt rendezéshez támogatást kell nyújtani, hogy azt számszer en meg lehessen ragadni. Ezt a szerepet hivatott betölteni a logikai óra. A logikai óra monoton növekv szoftver számláló, amelynek az értéke nem kell, hogy bármilyen fizikai órához kapcsolódjon. Minden P folyamatnak van egy saját logikai órája, CP, amelyet a folyamat események id címkével való ellátására használ. A következ kben a P folyamatban az a esemény id címkéjét CP(a) jelöli, míg egy tetsz leges folyamat b eseményét C(b). A folyamatok az

63

V. fejezet

alábbi szabályok szerint (LSZ) állítják a logikai órájukat, illetve az üzenetekben az alábbi id címkéket küldik:

LSZ1: LSZ2: a)

CP minden egyes esemény P-beli bekövetkezte el tt inkrementálódik:

CP := CP + 1

Amikor egy P folyamat egy m üzenetet küld, akkor a folyamat az m üzenetet
t = CP id címkével látja el.

b)

Amikor

egy

Q

folyamat

megkap

egy

(m,

t)

üzenetet,

kiszámolja

CQ := max(CQ, t)-ot és aztán alkalmazza LSZ1-et az rcv(m) esemény id címkével

történ ellátása el tt.

A fenti logikai órára teljesül az alábbi összefüggés:
a b C(a) < C(b)

Vagyis ha egy a esemény korábban történt egy b eseménynél, akkor az a eseményhez kisebb logikai óra érték tartozik, mint a b eseményhez. Könnyen belátható azonban, hogy a fenti összefüggés fordítottja nem igaz, vagyis C(a) < C(b)-b l nem következik, hogy a b. Ez az eset tipikusan konkurens eseményeknél áll fenn.

Teljesen rendezett logikai órák

Az el bbiekben tárgyalt logikai óra konstrukció csak részleges rendezést ad az eseményeken, hisz léteznek olyan különböz folyamatokhoz tartozó események, amelyekhez azonos logikai óra érték tartozik. Azonban viszonylag egyszer en ki lehet terjeszteni a fenti sémát, hogy az teljes rendezést adjon. Ehhez a folyamatok azonosítóját is fel kell használni az id címkék megkonstruálásához. Ha a a Pa folyamat egy eseménye, amely Ta helyi id címkével rendelkezik, és b a Pb folyamat egy eseménye, amely Tb helyi id címkével rendelkezik, akkor az ezen eseményekhez tartozó globális id címkék:
(Ta, Pa ), illetve (Tb, Pb). Ezek segítségével a teljes rendezés: (Ta, Pa ) < (Tb, Pb) akkor és csak

akkor, ha Ta < Tb vagy Ta = Tb és Pa < Pb. Itt feltételeztük, hogy a folyamatokra létezik egy teljes rendezés, ami a gyakorlatban mindig fennáll.

64

V. fejezet

I.4.4.2. Elosztott koordináció

Elosztott folyamatoknak is koordinálni kell a tevékenységüket, különös tekintettel az osztottan kezelt er forrásokra. A Sun NFS egy állapotmentes szerver, így ott állományok megosztott kezelésére nem lehet a szerveren zárakat használni, hisz ez ellentmondana az állapotmentességnek. Így ebben az esetben a Unix egy külön daemon - a lockd segítségével oldja meg a szinkronizálást. Azonban gyakran célszer szervesen egybeépíteni a szinkronizálási eszközöket. A leggyakrabban el forduló szinkronizálás osztottan használt er források esetén a kölcsönös kizárás. Elosztott rendszerekben az elosztottság a korábban megismert megvalósításokkal szemben újabb igényeket támaszt, amelyeket elosztott kölcsönös kizárási algoritmusokban figyelembe kell venni. A továbbiakban ezekre nézünk meg néhány példát. az er forrást kezel szerverrel

(1) Elosztott kölcsönös kizárás

Egy osztottan használt er forrással kapcsolatosan a kölcsönös kizárással (KK) szemben az alábbi követelményeket támasztjuk:

KK1(biztonság): Egy id pillanatban egyszerre csak egyetlen folyamat tartózkodhat a kritikus szakaszban. KK2(haladás): Egy folyamat, amely be akar lépni a kritikus szakaszba, véges

id n belül beléphet. Ez a kritérium a rendszer holtpont mentességét és kiéheztetés mentességét fogalmazza meg. KK3(rendezés): A kritikus szakaszba a folyamatok a korábban-történt rendezés alapján lépnek be, vagyis ha valaki korábban kérte a belépés korábban is kapja meg. jogát, az

Központi szerver algoritmus

Az elosztott kölcsönös kizárás legegyszer bb megvalósítása a központi szerver algoritmus. Itt minden egyes osztott er forráshoz hozzárendelünk egy szervert, amelyre a kölcsönös

65

V. fejezet

kizárást meg kell valósítani. Ez a szerver engedélyezi a belépést a kritikus szakaszba. Minden alkalommal csak egy folyamatot enged be. Ha már tartózkodik egy folyamat a kritikus szakaszban, akkor a további kéréseket várakoztatja. Ezt a modellt úgy is elképzelhetjük, hogy a szerver birtokol egy tokent az általa felügyelt kritikus szakaszhoz. A szakaszba mindig csak az a folyamat léphet be, amelyik birtokolja a tokent. Mivel kezdetben egy token volt a rendszerben, így a kölcsönös kizárás biztosított. A szerver semmi mást nem tesz, mint amennyiben egy folyamat be akar lépni a kritikus szakaszba és a token a szervernél van (vagyis a kritikus szakaszban nem tartózkodik egyetlen folyamat sem), akkor a kér folyamatnak odaadja a tokent, ellenkez esetben várakozásra kényszeríti. A megoldás

problémája, hogy a szerver kritikus hibapont, annak meghibásodását megfelel en kezelni kell.

Logikai órákat alkalmazó elosztott algoritmus

Egy másik megközelítés a logikai órákat alkalmazó elosztott algoritmus. Logikailag ez az algoritmus is a belépést engedélyez token meglétéhez köti a kritikus szakaszba történ

belépést, itt azonban a token a rendszerben lév többi folyamattól kapott megfelel üzenetek együtteséb l áll el . Az algoritmus lényege, hogy ha egy folyamat be szeretne lépni a kritikus szakaszba, akkor az összes többi folyamatnak elküld egy üzenetet, ami ezen szándékát jelöli, és az üzenetet ellátja a szándék id pontját jelz id bélyeggel. A folyamat ekkor bevárja, hogy a rendszer összes folyamata válaszoljon. Amikor az összes válasz megérkezett, a folyamat beléphet a kritikus szakaszba. Amennyiben egyszerre több folyamat is be akar lépni a kritikus szakaszba, akkor több belépési szándékot jelöl üzenet is van a rendszerben. Ekkor, ha egy folyamat be akar lépni a kritikus szakaszba, és egy másik folyamattól egy hasonló jelleg üzenetet kap, akkor az üzenet id bélyegét összehasonlítja a saját üzenete id bélyegével. Amennyiben a saját id bélyege kisebb, akkor nem válaszol a kérésre, hanem egy várakozási sorban várakoztatja, és majd csak a kritikus szakaszt elhagyva válaszol neki. Amennyiben a saját id bélyege nagyobb, akkor azonnal válaszol a kérésre (ekkor majd a másik folyamat fogja t várakoztatni). Jól látszik, hogy a sorrendezési kritérium is teljesül az algoritmusra.

A gy r alapú algoritmus

A gy r alapú algoritmus egy logikai gy r t épít a folyamatokból, amelyben egy token kering. Amelyik folyamat be akar lépni a kritikus szakaszba, az megvárja a token megérkezését, és belép, majd a kritikus szakasz elhagyása után küldi tovább a tokent.

66

V. fejezet

Ezek az algoritmusok azt sugallják, hogy azok az osztottan használt er forrás menedzserét l függetlenül futtathatók. Ez valóban így van, azonban egy praktikus implementációban célszer a kölcsönös kizárást az osztott er forráshoz a lehet legközelebb megvalósítani, vagyis célszer ezt a feladatot is az er forrás menedzserre ruházni.

A továbbiakban a választási algoritmusokat tárgyaljuk.

(2) Választási algoritmusok

Elosztott rendszerekben a választási algoritmusok nagy szerepet kapnak. Feladatuk egy folyamatcsoportból egy kitüntetett folyamat kiválasztása. Ezen folyamat több szempontból is lehet kitüntetett: például kölcsönös kizárást biztosító szerver, koordinátor, token generátor, id szolgáltató stb. A választási algoritmus eredményeként kiválasztott folyamattal szemben a f követelmény, hogy a kiválasztott folyamat egyedi legyen, a csoport minden folyamata ugyanazt a folyamatot gondolja megválasztottnak, még akkor is, ha egyszerre több folyamat is elindítja a választást. A továbbiakban két algoritmust vizsgálunk meg: a bully algoritmust, amely esetén a résztvev folyamatok ismerik egymás azonosítóit, azok prioritását, illetve a gy r

algoritmust, amelynél csak az egyik szomszéd kommunikációs azonosítójára van szükség.

A bully (er szakos) algoritmus

Az algoritmus akkor alkalmazható, ha a folyamatcsoport tagjai ismerik egymás azonosítóit (illetve a hozzájuk rendelt prioritásokat - gyakran a prioritás megegyezik az azonosítóval), és hálózati címeit. Az algoritmus a folyamatcsoportból kiválasztja a legnagyobb prioritású még aktív folyamatot, és megválasztja koordinátornak. Az algoritmus m ködése során feltételezzük, hogy a kommunikáció megbízható, de a folyamatok maga a választási algoritmus alatt is meghibásodhatnak, továbbá a tárgyalás leegyszer sítése érdekében a folyamat azonosítója egyben a prioritása is, és a nagyobb azonosító nagyobb prioritást jelöl. Az algoritmusban három eltér típusú üzenet jelenhet meg: 67

V. fejezet

· · ·

választás válasz koordinátor

- a választás megkezdését jelzi - választási üzenetre adott válasz - az új, megválasztott koordinátor szétküldi az azonosítóját

Az algoritmus mindig azzal kezd dik, hogy egy folyamat észreveszi a koordinátor meghibásodását. Legyen ez Pi. Ekkor:
Pi választás(Pi) üzenetet küld minden egyes Pj folyamatnak, amelyre j > i (az indexek

·

prioritási sorrendet jelölnek). Ezután Pi várakozik válasz(Pj)-re Tvv ideig. Ha nem érkezik válasz, akkor Pi magát tekinti a legnagyobb prioritású, még m köd folyamatnak (hisz a magasabb prioritásúaktól nem kapott választ), és az alacsonyabb prioritású folyamatoknak kiküld egy koordinátor(Pi) üzenetet, vagyis, megválasztja magát koordinátornak.
·

Ha érkezett valamilyen Pj folyamattól válasz, amelyre j > i, akkor Pi vár Tvk ideig, hogy a magasabb prioritású folyamat koordinátornak deklarálja magát. Amennyiben Tvk id alatt nem jön ilyen üzenet, újabb választást kezdeményez. Ha egy folyamat egy koordinátor(Pj) üzenetet kap, akkor feljegyzi az üzenetben szerepl folyamat azonosítóját, és ett l kezdve ezt a folyamatot koordinátorként kezeli. Ha egy Pj folyamat választás(Pi) üzenetet kap, akkor visszaküld egy válasz(Pj) üzenetet, és Pj is kezdeményez egy választást, hacsak már nem kezdeményezett korábban.

·

·

Mint azt korábban említettük, az algoritmus kezeli a választási algoritmus futtatása során történ folyamat meghibásodásokat is. Erre szolgál a Tvk várakozási id szerepeltetése az algoritmusban. Tvk a koordinátor megválasztási üzenet megérkezésére történ várakozás id korlátját jelöli. Mint láttuk, ha egy folyamat észleli a koordinátor meghibásodását, választási üzenetet küld minden nála nagyobb prioritású folyamatnak (mivel ezek lehetnek a potenciális következ koordinátorok). Ha ezek közül valaki válaszol, az azt jelenti, hogy m köd képes és akar lenni a koordinátor. Ehhez egy adott Tvk id korláton belül egy

üzenettel koordinátornak kell nyilvánítania magát. Ha az üzenet mégsem érkezik meg Tvk id n belül, ez azt jelenti, hogy a folyamat a választási algoritmus befejez dése el tt meghibásodott. Ekkor újabb választás indul.

68

V. fejezet

Amikor egy meghibásodott folyamat újraindul, azonnal választást kezdeményez. Amennyiben ennek a folyamatnak a legnagyobb prioritású az azonosítója, akkor úgy dönt, hogy lesz a

koordinátor, még akkor is, ha a korábbi koordinátor m köd képes. Ezért kapta az algoritmus a nevét, vagyis, hogy er szakos, hisz minden körülmények között a legmagasabb prioritású m köd folyamat lesz a koordinátor. Az algoritmus m ködésének bemutatására tekintsük az alábbi egyszer példát (lásd az V.4.x1. ábrát): négy folyamat alkotja a folyamatcsoportot, ezek P1, P2, P3 és P4. P2 észreveszi a P4-es koordinátor folyamat meghibásodását, és egy választást kezdeményez. (a . ábra 1. lépése). A választás üzenet elküldése után P2 Tvv ideig vár a válaszra, ami azt jelzi, hogy P3 él, így lehet a koordinátor. A 2. lépésben P3 visszaküldi a választ P2-nek. Ekkor P2 Tvv ideig ismét elkezd várakozni, hogy P3 bejelentse, hogy lett a koordinátor. Ekkor P3 meghibásodik (3. lépés). Mivel P2 az id korláton belül nem kapott koordinátori üzenetet, magát tekinti megválasztott koordinátornak, így egy koordinátor(P2) üzenetet küld P1-nek. Egy id után a
P4-es folyamat újra indul, és azonnal értesít mindenkit, hogy a koordinátor. választás(P2)

1. lépés:

P1

P2 várakozás Tvv ideig

P3

P4

2. lépés:

P1

P2

P3
válasz(P3)

P4

várakozás Tvk ideig

3. lépés:

P1

P2

P3

P4

koordinátor(P2) koordinátor(P4)

69

V. fejezet

4. lépés:

P1

P2

P3
koordinátor(P4)

P4

koordinátor(P4)

V.4.x1. ábra: A Bully algoritmus. P2 kordinátorrá választása P4 és P3 meghibásodása után.

Majd P4 koordinátorrá választása annak újraindulása után.

Az algoritmus során küldött üzenetek száma

A legkedvez bb esetben a második legnagyobb prioritású folyamat veszi észre a koordinátor meghibásodását és kezdeményez választást. Ekkor rögtön megválaszthatja magát, és szétküld (n-2) koordinátor üzenetet az alacsonyabb prioritású folyamatoknak. A legrosszabb esetben a Bully algoritmus O(n2) üzenetet igényel. Ebben az esetben a legkisebb prioritású folyamat észleli a koordinátor meghibásodását, és mind az (n-1) folyamat választást kezdeményez, választás üzeneteket küldve a magasabb prioritású folyamatoknak.

A gy r algoritmus

A folyamatcsoportban lév folyamatokat egyirányú logikai gy r be kell szervezni. Ez nem
jelent megkötést a fizikai topológiára. Ebben az esetben feltételezzük, hogy az egyes

folyamatok nem ismerik egymás azonosítóit, így prioritásukat sem, csak azt tudják, hogyan kell kommunikálni az egyik, mondjuk az óra járásával megegyez szomszédjukkal. Az

algoritmus célja a legnagyobb prioritású egyedi koordinátor megválasztása. Az algoritmus
feltételezi, hogy a folyamatok az algoritmus alatt nem hibásodnak meg, és elérhet k maradnak.

Kezdetben minden folyamat a választásban nem-résztvev -nek van jelölve. Bármelyik folyamat kezdeményezhet választást. Ekkor els lépésben választásban résztvev -nek jelöli magát, és az azonosítóját egy választás üzenetben elküldi a szomszédjának. Amikor egy folyamat egy választás üzenetet kap, összehasonlítja az üzenetben foglalt azonosítót a sajátjával. Amennyiben a beérkezett azonosító nagyobb, a folyamat továbbítja az

70

V. fejezet

üzenetet a szomszédjának. Azonban ha a beérkezett azonosító kisebb a saját azonosítójánál, akkor a folyamat el ször megvizsgálja, hogy résztvev -e. Amennyiben nem, akkor az üzenetben lecseréli az azonosítót a sajátjára, és résztvev -nek jelöli magát, majd továbbítja a
választás üzenetet a szomszédjának. A folyamat akkor is résztvev -nek jelöli magát, ha nem

cserélte le az azonosítót. Amennyiben az azonosító megegyezik az üzenetet kapó folyamat saját azonosítójával, akkor a kör bezárult, a folyamat a legnagyobb prioritású folyamat a körben, lesz a koordinátor. A

folyamat nem-résztvev -nek jelöli magát, és egy megválasztott üzenetet küld a szomszédjának a saját azonosítójával, így tudatva a koordinátor kilétét. Ha egy nem koordinátor folyamat megválasztott üzenetet kap, magát nem-résztvev -nek jelöli, megjegyzi a koordinátor azonosítóját és továbbítja az üzenetet a szomszédjának. Folyamatok résztvev -nek, illetve nem-résztvev -nek jelölésének az értelme akkor domborodik ki, amikor egyszerre több folyamat kezdeményez választást. Ekkor a fenti jelöléseket ki lehet használni, és minimalizálni lehet az üzeneteket.

Az algoritmus során küldött üzenetek száma

Ha csak egy folyamat kezdeményezi a választást, akkor a legrosszabb eset olyankor áll fenn, amikor a kezdeményez azonosítót. óra járásával ellentétes szomszédja birtokolja a legmagasabb

5

71

V. fejezet

6

választás 19 kezdeményezés

7 33

33

13

2

45 V.4.x2.ábra: A gy r választási algoritmus m ködése. A választást most a 19-es csomópont kezdeményezte.

Ekkor ezen szomszéd eléréséhez n - 1 üzenet szükséges, amely addig nem nyilvánítja magát koordinátornak, amíg a saját üzenetét vissza nem kapja újabb n üzenettel kés bb. Ekkor a
megválasztott üzenet is n-szer megjelenik, így összesen 3n - 1 üzenetre van szükség. Az

V.4.x2 . ábra egy gy r s választási algoritmust mutat. A választást a 19-es folyamat kezdeményezte. A választás üzenet jelenleg a 33-as azonosítót tartalmazza, de a 45-ös folyamat ezt majd lecseréli a saját azonosítójára, ha majd megkapja az üzenetet. A jelölt körök a résztvev folyamatokat jelölik.

I.4.5. Elosztott rendszerek biztonsági kérdései
Az elosztott rendszerekkel foglalkozó fejezet végén az elosztottsággal összefügg biztonsági kérdésekre térünk ki. Az elosztott rendszerek fokozottan ki vannak téve a különféle biztonsági veszélyeztetéseknek. Bár a biztonság megteremtéséhez szükséges eszközök többsége adott, alkalmazásuk azonban alapos tervezést és széleskör vizsgálatokat igényel.

72

V. fejezet

Elosztott rendszerek biztonságát különböz biztonsági módszerek alkalmazásával érthetjük el. Ezen módszerek azonban nem alkalmazhatóak önállóan, vagy folyamatosan b víthet en ­
a rendszer egyidej , a kívánalmaknak megfelel en teljes kör védelmére van szükség. Egy

elosztott, nyílt rendszerben a teljeskör biztonság megteremtése egyetlen rendszerrel nem valósítható meg. Helyi, egyes gépeket, szolgáltatásokat véd rendszerek telepítése könnyebb feladat, ezek azonban egy elosztott rendszerben kezelhetetlenül bonyolultá tehetik a rendszert. A felhasználók által megjegyzend jelszavak számának minimális szinten tartása

megköveteli, hogy egy elosztott rendszerben egyetlen azonosítás elegend legyen a teljes rendszer használatára. Nem elegend a módszerek teljes kör alkalmazása sem: a biztonság megteremtésére és meg rzésére úgynevezett biztonságpolitikára is szükség van. Nem elegend a módszerek bevezetése, azok alkalmazását is pontosan szabályozni kell. Hiába alkalmazzuk a lehet legkifinomultabb, legbiztonságosabb azonosító rendszert, ha a felhasználók az íróasztalukon kit zve tárolják jelszavaikat. A biztonságpolitikának a módszerek helyes alkalmazásán kívül hangsúlyt kell fektetnie a felhasználók oktatására és ellen rzésére is.
Mi a biztonság?

Egy rendszer biztonsága alatt különböz

emberek különböz

dolgokat értenek. A

számítógépeket használók többsége a számítógépes vírusokra és az internet kalózok támadásaira gondol, ha a számítógépek biztonságáról van szó. Mások a bizalmas adatok védelmét, titkosságát és a hozzáférés szabályozását értik e fogalom alatt. Egy rendszer biztonságossá tétele mindezen problémák kezelését megköveteli. Általában a következ területeket értjük alatta: · Azonosítás (authentication) Felhasználók és számítógépek megbízható és egyértelm azonosítása, üzenetek biztonságos aláírása és bizonyos események, akciók egyértelm rögzítése. · Felhatalmazás (authorization) A felhasználók, számítógépek és programok által végrehajtható akciók nyilvántartása. · Titkosítás (encryption) Hozzáférés szabályozása bizalmas információkhoz.

73

V. fejezet

· Rendszer védelem (system protection) A rendszerek megbízható és folyamatos m ködésének biztosítása (vírus védelem, szolgáltatások folyamatos fenntartása, véletlen rendszerhibák elkerülése).
Kik a támadók és mik a fenyegetések?

Elosztott rendszerekben tárolt információ megszerzésére, illetve a rendszerek m ködésének megzavarására emberek és programok (folyamatok) törekedhetnek. A továbbiakban a támadó kifejezést alkalmazzuk az elosztott rendszerben tárolt információt vagy er forrást illetéktelenül megszerezni próbáló ügynökre. A támadó a rendszer valamilyen biztonsági hibáját használja ki a támadás véghezvitele során. A biztonsági hiba lehet a biztonsági
módszerek vagy a biztonságpolitika hibája.

A következ f bb fenyegetés fajták léteznek: · Jogosulatlan megbízók információszerzése. · Információ (beleértve programokat is) jogosulatlan módosítása. · Az er források jogosultság nélküli használata. · Zavarkeltés a rendszer megfelel m ködésében, anélkül, hogy a támadónak ebb l haszna származna.
I.4.5.1. A támadás módszerei

A fenyegetések valóra váltásához hozzá kell férni a rendszerhez. Ennek legelterjedtebb módjai: · Lehallgatás Az elosztott rendszer komponensei közötti üzenetváltásokról jogosultság nélküli információ szerzése. Ez történhet úgy is, hogy a támadó közvetlenül a hálózatról szerzi be az üzeneteket, vagy nem megfelel en védett tárolt információt olvas el. · Maszkírozás Egy felhasználó vagy program rendszerbeli azonosítóját használva a támadó üzenetet küld, illetve fogad a megfelel jogosultságok nélkül. · Üzenet módosítás A támadó üzeneteket fog el és megváltoztatja a tartalmukat, majd a megváltoztatott üzenetet továbbküldi a rendszer megtévesztése céljából.

74

V. fejezet

· Visszajátszás A támadó a rendszer egy üzenetét eltárolja, és egy kés bbi id pontban újra lejátssza. A visszajátszás ellen nem lehet egyszer titkosítással védekezni, mert a visszajátszást használni lehet er forrás lopásra és vandalizmusra is, még akkor is, ha a támadó nem érti az üzenetet. A fenti támadások véghezviteléhez a támadónak hozzá kell férnie a rendszerhez, hogy futtathassa a programot, amely megvalósítja a támadást. A legtöbb támadásért a rendszer jogosult felhasználói a felel sek nem megfelel jelszóhasználati gyakorlatukkal. A

legegyszer bb beszivárgási módszer a jelszó feltörés, vagyis a szisztematikus próbálgatás. Léteznek szótárak, amelyek a leggyakrabban használt jelszavakat tartalmazzák. Ez ellen megbízható jelszó választásával lehet védekezni.
I.4.5.2. Az elosztott biztonsági rendszer tervezése

Elosztott rendszerekben a fenyegetettség f forrása a kommunikációs csatornák nyitottsága. Fel kell tételezni, hogy a rendszer minden szintjén lév kommunikációs csatorna és program ki van téve a fenti fenyegetéseknek. A lehetséges betolakodókat nem könny

azonosítani, így olyan világnézetet kell alkalmazni, amely nem feltételez bizalmat. De ahhoz, hogy használható rendszert építhessünk, néhány megbízható komponensb l kell kiindulni. Egy hatékony tervezési megközelítés lehet annak feltételezése, hogy minden kommunikáció megbízhatatlan forrásból jön, amíg az ennek ellenkez jét nem bizonyítja. A kommunikáló felek megbízhatóságát minden egyes kommunikációs csatorna használatkor bizonyítani kell. A biztonság megvalósítására használt mechanizmusokat nagy gonddal kell ellen rizni, pl. egy biztonságos kommunikációs protokollnak és az azt megvalósító programnak bizonyíthatóan helyesnek kell lenni az összes lehetséges üzenet szekvenciára. A bizonyításnak ideális esetben formális alapokon kell nyugodnia. A biztonsági rendszer tervezése során els sorban nem a biztonsági módszerek ,,er ssége" befolyásolja a teljes rendszer biztonságát, hanem alkalmazásuk körülményei és teljessége. Biztonsági rendszerek véleményezése során a felhasználók gyakran esnek a technikai részletek els dleges min sítésének hibájába. Sokkal jobban figyelnek a titkosításban alkalmazott kulcsok hosszára, mintsem alkalmazásuk helyességére és teljességére. A biztonsági rendszerek tervezésének els
aranyszabálya szerint tökételes biztonság nem

létezik. A biztonság mindig a védend rendszer értékének és a biztonsági rendszer kiépítési

költésének kompromisszumán alapszik. Drágább és jobb technológia alkalmazása javíthatja a 75

V. fejezet

rendszer biztonságát, azonban mindig létezni fog sikeres (és egyre költségesebb) támadási technika a rendszer ellen. A rendszer védelmi mechanizmusait úgy kell megválasztani, hogy a támadó által elérhet nyereség (vagy okozott kár) mindig lényegesen kevesebb legyen a támadás költségénél. A rendszer tervezésének második aranyszabálya szerint a legtöbb biztonsági problémát
mindig az emberek viselkedése okozza. Semmilyen biztonsági mechanizmus nem lehet

sikeres, ha használói nem viselkednek biztonságos módon. Ezért a rendszer tervezése során olyan megoldásokat és módszereket kell alkalmazni, melyek ösztönzik a felhasználók biztonságos viselkedését. Az összes biztonsági technika három alapvet mechanizmuson alapszik: titkosításon,

azonosítási mechanizmusokon, és hozzáférés szabályozáson.
I.4.5.3. Titkosítás

Biztonságos rendszerek megvalósításában a titkosítási módszerek központi szerepet játszanak. Amikor valamilyen információt titkosítunk, akkor egy olyan transzformációt végzünk rajta, ami az inverz transzformáció ismerete nélkül lehetetlenné (pontosabban praktikusan lehetetlenné, vagy a titkosított adatok értékéhez mérten lényegesen költségesebbé) teszi az információ visszafejtését. A gyakorlatban használt titkosítási algoritmusok két nagy csoportba oszthatók: titkos kulcsú és nyilvános kulcsú titkosítási algoritmusok. A titkos kulcsú titkosítás során a sima szöveget egy el re megegyezett függvénnyel titkosítják, egy titkos kulcsot használva. A megfejtés során az inverz függvényt kell alkalmazni ugyanazon titkos kulccsal. Így ha biztosítjuk, hogy a titkos kulcsot csak a kommunikációban résztvev két folyamat birtokolja, akkor az információ titkosságát

biztosítottuk. Mivel a kulcsokat titokban, mások el l elrejtve tartjuk, így a függvényt, illetve az inverz függvényt nem kell titokban tartani. Általánosságban a titkosító függvény és annak inverze lehet különböz , de választható olyan függvény is, amelynek az inverze megegyezik magával a függvénnyel. A gyakorlatban ilyen függvényeket alkalmaznak. A titkosító algoritmusnak biztonságosnak kell lennie

szisztematikus feltörési kísérletekkel szemben is. A leggyakoribb ilyen próbálkozás, hogy rendelkezésre álló sima szöveg, és a hozzá tartozó titkosított szöveg alapján megpróbálják kitalálni a kulcsot, illetve titkosított szövegekre alkalmazzák az inverz függvényt véletlenül megválasztott kulccsal, és ha az eredmény értelmesnek t nik, akkor a kulcs helyes.

76

V. fejezet

A nyilvános kulcsú titkosítás egy olyan titkosító módszer, amelyben a kommunikáló feleknek nem kell bízni egymásban. A kommunikációban minden egyes részt vev létrehoz egy

kulcspárt, egy kódoló és egy dekódoló kulcsot. A dekódoló kulcsot titokban tartja (titkos kulcs), a kódoló kulcsot nyilvánosságra hozza (nyílvános kulcs). Mindenki, aki titkos üzeneteket szeretne küldeni neki, a kódoló kulcs segítségével titkosítja az üzenetét, melyet csak a dekódoló kulccsal rendelkez fél tud visszafejteni. A módszer a két kulcs között kapcsolatot teremt olyan függvényen alapul, amelyre a kódoló kulcs ismeretében nagyon nehéz meghatározni a dekódoló kulcsot. A függvény olyan Y = f(X) függvény, amelyre X kiszámítása Y ismeretében annyira számításigényes, hogy gyakorlatilag kivitelezhetelen. Ez a nyilvános kulcsú titkosítás, amely során nincs szükség titkos kulcsok küldözgetésére a kommunikációs csatornán. A módszer két nagyon nagy prím szám szorzatának használatán alapul, kihasználva azt a tényt, hogy ilyen nagy számok prímfelbontásának meghatározása olyan számításigényes, hogy gyakorlatilag kivitelezhetetlen. (Megjegyzend , hogy

matematikailag nem bizonyított, hogy nem létezik gyors felbontási algoritmus, de praktikusan elfogadott tény.) A titkosítás alkalmazható bizalmas információk elrejtésére, amikor csak az fejtheti meg az üzenetet, aki birtokolja a megfejtéséhez szükséges kulcsot. A módszer kommunikáció hitelesítésénél segédeszközként is használatos. Ha a vev sikeresen dekódol egy üzenetet, feltételezheti, hogy az hiteles forrásból származik, mert a küld ismerte a kulcsot. Az

azonosítás finomabb formájának, a digitális aláírás létrehozásában is alkalmazható. Ennek feladata azt ellen rizni, hogy az üzenet valóban sértetlenül és a feltételezetett feladótól érkezett-e meg, valamint annak biztosítása, hogy a feladó a kés bbiekben ne tagadhassa le az üzenet elküldését.
I.4.5.4. Hozzáférés szabályozás

A hozzáférés szabályozás feladata az adatokhoz és er forrásokhoz való hozzájutás szabályozása és korlátozása az azonosított felhasználók és programok körére. A hozzáférés szabályozás az er források használóinak azonosítása után az er forrás használati szabályok (pl. id pont ­ er forrás ­ felhasználó mátrix) alapján engedélyezi vagy tiltja meg a hozzáférést.

77

V. fejezet

I.4.5.5. Azonosítás

Az azonosítás az elosztott rendszer résztvev inek egyértelm

és megbízható hitelesítését

jelenti. Centalizált többfelhasználós rendszerekben viszonylag egyszer en meg lehet oldani az azonosítást: a munkamenet elején valamilyen jelszó ellen rzéssel hitelesíteni lehet a felhasználót (vagy programot), és az azonosítás után a munkamenetet egy olyan tartománynak lehet tekinteni, amelyben az összes m veletet az azonosított felhasználó nevében lehet elvégezni. Ez a megközelítés feltételezi a rendszer er forrásainak centralizált kezelését, ami nehezen oldható meg, vagy általában nem kívánatos elosztott rendszerekben. Elosztott rendszerekben a hitelesítést általában egy kitüntetett szolgáltatás ­ az azonosító szolgáltatás ­ végzi, amely titkosítási eszközöket használ a feladat megoldására. A rendszer elosztott szolgáltatásai az azonosító szolgáltatást használhatják fel a felhasználók (és programjaik) azonosítására.
I.4.5.6. Azonosítás és kulcs szétosztás

Titkos kulcsú rendszerekben régebben a kulcsokat valamilyen más hordozón osztották szét. Például papíron oda lehet adni a kulcsot, majd kés bb megsemmisíteni. Ez a módszer elosztott számítógépes hálózatokban nehezen járható megoldás, általában valamilyen más titkosítási mechanizmust alkalmaznak a titkos kulcsok átvitelére. A titkos kulcsok tárolására és elosztására speciális kulcsszervereket lehet használni, de a hitelesítésre nagy gondot kell fordítani. Nyilvános kulcsú titkosítás esetén a nyilvános kulcs megkapóinak biztosnak kell lenniük, hogy a kapott kulcs hiteles, vagyis annak a kulcs párnak a nyilvános része, amelynek titkos kulcsát a kommunikációs partner birtokolja. Ellenkez esetben egy ál partner bizalmas

információkhoz juthat, ha hamis nyilvános kulcsot ad. A hitelesség biztosítására elektronikus aláírásokat lehet használni. A hitelesítés és a kulcsok biztonságos szétosztását Needham és Schroeder hitelesít
szerveren alapuló hitelesítési és kulcs szétosztási algoritmusán keresztül mutatjuk be. A

hitelesít szerver feladata, hogy folyamat pároknak biztonságos módon kulcsot biztosítson a kommunikációjukhoz. Ehhez a klienseivel a szerver titkosított üzenetekkel kommunikál. A továbbiakban az algoritmus titkos kulcsokon alapuló változatát tekintjük át.

78

V. fejezet

A következ kben a Needham - Schroeder titkos kulcsú hitelesítési protokoll egyes lépéseit foglaljuk össze. A példában két állomás (A és B) a hitelesítési szerver (S) segítségével vált üzenetet. Az üzenetváltásban felhasználják kett jük K titkos és nyilvános kulcsait.

fejléc 1. A --> S:

üzenet
A, B, NA {NA,B,

megjegyzés
A S-t l kér egy kulcsot a B-vel történ

kommunikációhoz. 2. S --> A:
KAB, S visszaküld egy üzenetet, amelyet A titkos

{KAB, A}KB}KA

kulcsával titkosít. Az üzenet tartalmazza a frissen generált KAB kulcsot, és egy B titkos kulcsával titkosított jegyet. Az NA címke azt mutatja, hogy a jelen üzenet válasz a megel z re. A azt hiszi, hogy az üzenetet S küldte, mert csak S ismeri A titkos kulcsát.

3. A --> B: 4. B --> A:

{KAB, A}KB {NB}KAB

A elküldi a jegyet B-nek. B visszafejti a jegyet, és az új KAB kulccsal

titkosítja az NB címkét. 5. A --> B:
{NB - 1}KAB A azzal mutatja meg B-nek, hogy

küldte az megegyezett

el z

üzenetet,

hogy

egy

transzformációt végez NB-n.

Jelölések:
A B KA KB KAB NA {M}K

A kommunikációt kezdeményez megbízó neve. A kommunikációs partner megbízójának neve.
A titkos kulcsa. B titkos kulcsa. A és B közötti kommunikáció titkos kulcsa. A által generált címke. K kulccsal titkosított M üzenet.

79

V. fejezet

A protokoll egyik gyenge pontja, hogy B-nek nincs információja arról, hogy a 3. üzenet friss. Egy behatoló megszerezheti a KAB kulcsot és a {KAB, A}KB hitelesít t, és akkor A-nak adhatja ki magát. Ezt a problémát id címke használatával küszöbölhet ki. Az algoritmusnak létezik nyilvános kulcson alapuló változata is, de helysz ke miatt itt azzal nem foglalkozunk.
I.4.5.7. Kerberos: hitelesítési protokoll nyílt hálózati rendszerekre

A Kerberos egy titkos kulcsú titkosításon (DES) alapuló hitelesítési rendszer melyet az MIT (Massachusetts Institute of Technology) fejlesztett ki az Athena projekt keretében. A Kerberos rendszerben a szolgáltatások igényl it (legyenek azok felhasználók vagy programok) kliensnek, a szolgáltatásokat nyújtó programokat pedig szervernek nevezzük. A rendszer úgynevezett megbízó leveleket (credentials) alkalmaz a hozzáférés szabályozás megoldására. A megbízó levelek beszerzésének mechanizmusa a Kerberos azonosító rendszere. A Kerberos egy megbízható kívülálló hitelesítési szervizt, amely a korábban ismertetett Needham és Schröder modellen alapul. A rendszer a módszert kiegészíti az id bélyegek alkalmazásával. A Kerberos tartalmaz egy adatbázist a klienseir l és szerverekr l, illetve ezek kulcsairól. A kliensek és szerverek privát kulcsát csak a Kerberos illetve a kulcs tulajdonosa ismeri. Felhasználók esetén a privát kulcs egy titkosított jelszó. A Kerberos a titkos kulcsok ismeretében képes egyrészt a kommunikáló felek azonosítására, másrészt titkosított üzenetváltásra a rendszer minden szerepl jével. A felek egymás közötti (a Kerberostól független) kommunikációjához a Kerberos úgynevezett viszony kulcsot (session
key) ad, mely egy adott kapcsolatban felhasználható az üzenetek titkosítására.

Kerberos három különböz védelmi szintet határoz meg. Az alkalmazást készít programozó választja ki ezek közül az alkalmazások igényeinek leginkább megfelel t. Az alkalmazások egy részében elegend a megbízható azonosítás a kapcsolat kezdetén (pl. az NFS esetében). Ennél egy szinttel magasabban minden egyes üzenetváltásnál szükséges a felek azonosítása. A harmadik szinten nem csak az azonosítás, hanem az üzenetek titkosítása is megoldható. Egy kliens csak akkor használhat egy szervizt, ha már korábban szerzett erre egy jegyet, azaz speciális megbízólevelet. Ezt kell bemutatnia a szervernek, annak bizonyítása céljából, hogy valóban jogosult a szerviz használatára. Ilyen jegy beszerzéséhez a kliensnek el bb

80

V. fejezet

azonosítania kell magát a Kerberos rendszer számára, majd egy megbízólevelet kell szerezni az úgynevezett jegyosztóhoz (ticket granting service ­ TGS). A jegyet tehát egyetlen szerver-kliens pár között használjuk. A jegy tartalmazza a szerver nevét, a kliens nevét, a kliens internet címét, egy id bélyeget, egy lejárati id t, és egy viszony kulcsot. A kibocsátott jegyet a kliens mindaddig használhatja a szerver elérésére, míg az érvényes. Mivel ezen jegy titkosított a szerver kulcsával, ezért a szerveren kívül más nem tudja ezt értelmezni, így szabadon átadható a kliensnek, mely nem tudja módosítani.

A kerberos jegy: {s,c,addr,timestamp,life,Ks,c}Ks

Ett l eltér en a hitelesít jegyet a kliens csak egyszer használhatja, minden olyan esetben újat kell generálnia, amikor egy új szervizt akar használni. A hitelesít jegy a következ ket tartalmazza: a kliens nevét, a munkaállomás IP címét, és a munkaállomás aktuális idejét. A hitelesít jegyet a szerverre és kliensre kiadott kapcsolati kulcssal titkosítja.

A kerberos hitelesít : {c,addr,timestamp}Ks,c

A rendszerbe lépéskor az azonosítás a Kerberos szerver segítségével történik a felhasználó jelszavát használva. Az azonosítás után a Kerberos szerver állít ki olyan megbízóleveket, melyek a kliens hitelességét bizonyítják. Ilyen megbízólevéllel lehet a jegyosztótól a különböz szolgáltatásokhoz jegyet kérni. Az azonosításhoz a felhasználó átadja a

felhasználói nevét és a TGS nevét a Kerberos szervernek. A Kerberos szerver ellen rzi ezt a kliensér l tárolt információk alapján. Ha rendben találja, akkor generál egy véletlen viszony kulcsot (Kc,tgs), amelyet kés bb a kliens és jegyosztó szerver fog használni egymás közötti kommunikációjukra. A Kerberos ezenkívül elkészíti a jegyet (Tc,tgs) a TGS számára, amely tartalmazza a kliens nevét, a TGS nevét, az aktuális id t, a jegy élettartamát, a kliens IP címét és az elkészített random viszony kulcsot (Kc,tgs). Ezt a jegyet a TGS privát kulcsával titkosítja (Ktgs), ily módon biztosítva, hogy a kliens ezt ne tudja megváltoztatni. A hitelesít szerver ezután visszaküldi a kódolt jegyet és a Kc,tgs viszony kulcsot a kliensnek annak privát kulcsával titkosítva (Kc). Ez lesz a válasz üzenet a felhasználó jelszavára. Ezzel véget ért a bejelentkezési folyamat. Most már a kapott jegy (Tc,tgs) segítségével a kliens a TGS-t l beszerezheti a kívánt szerverre a megbízásokat (amíg a jegy élettartama le nem jár).

81

V. fejezet

A Kerberos el nyös tulajdonságai: · titkosítja a rendszerben áramló adatokat; · nagyon megbízható; · TCP/IP protokollra implementálták; · a felhasználói felületen semmit sem kell változtatni; · sohasem kerül fel a hálózatra kódolatlan jelszó. Hátrányai: · a Kerberos szerver egy kitüntetett gép a rendszerben, ezért ennek biztonságossága az egész rendszerét meghatározza (fizikailag is védeni kell); · a Kerberos szerver döntései mindenki számára els dlegesek; · az összes szoftvert újra kell fordítani, ,,Kerberizálni", hogy azok Kerberos hívásokat használjanak.

82

I. UNIX

1

I. UNIX

I.1. Bevezetés

A UNIX operációs rendszer 1999-ben ünnepli a 30. születésnapját. Ezalatt a 30 év alatt hardver platformok tucatjaira implementálták, cégek, egyetemek, kutató intézetek számtalan változatát fejlesztették ki. Mivel a UNIX az egyik legrégebb óta használt operációs rendszer, a fejleszt i közösség annak fejlesztése, implementálása során rengeteg tapasztalattal gazdagodott. Másrészt a fejlesztés különböz lépései viszonylag jól dokumentáltak. Ez a két tényez kiváltképp alkalmassá teszi a UNIX-ot, hogy egy, az operációs rendszereket

feldolgozó tankönyvben esettanulmányként szolgáljon az operációs rendszerek általános elveinek és algoritmusainak demonstrálására.

Ebben a részben áttekintjük, hogy az operációs rendszerek épít köveit hogyan valósították meg a UNIX operációs rendszerben. Célunk, hogy egy konkrét implementáción keresztül megmutassuk az elvek megvalósulását, felhívva az olvasó figyelmét a fejlesztés során felmerül problémákra és azok lehetséges orvoslási lehet ségeire. Nem a UNIX

pillanatnyilag ismert legfrissebb implementációinak pontos ismertetésére törekszünk (ehhez az érdekl d olvasó b séges irodalmat talál az irodalomjegyzékben), hanem, mint azt a könyv címe is mutatja, mérnöki szemlélettel elemezzük az egyes funkciók megvalósítását, annak nehézségeit, illetve azt a gondolatmenetet, ahogyan a fejleszt k eljutottak a mai rendszerekig. A jelen könyv terjedelme nem engedi meg az összes funkció részletes ismertetését, így didaktikai okokból úgy döntöttünk, hogy egyrészt kiemeljük a legfontosabb funkciókat, másrészt els sorban az elveket szépen és egyszer en bemutató implementációt írunk le, (nem feltétlenül a legfrissebb implementációt), rámutatunk az ezen implementációk által megvalósított elvekre, kiemelve erényeiket, azonban nem hallgatjuk el az adott implementáció hiányosságait sem. A hiányosságok leírásakor utalunk azok orvoslásának mai megközelítéseire.

I. UNIX

2

Miel tt rátérnénk a UNIX operációs rendszer bels szerkezetének az ismertetésére, hasznos lehet röviden áttekinteni a UNIX történetét és fejl dését.

I.2. A UNIX rövid története

Az 1960-as évek végén a Bell Telephone Laboratories, a General Elecric és az MIT egy közös projekten vett részt, amelynek célja egy többfelhasználós operációs rendszer kifejlesztése volt. A projekt kudarcba fulladt, de a Bell laboratórium egyik munkatársa, Ken Thompson, 1969-ben egy ,, rutazás" játékot fejlesztett egy PDP-7-es gépre, amihez egy kényelmes futtatási környezetre volt szüksége. Ez motiválta a UNIX kezdetleges változatának a kifejlesztését. (Mint azt ebb l is láthatjuk, a nagy dolgokat leginkább az emberi elme játékos hajlama lendíti el re.) A programozási környezet els elemét egy állományrendszer alkotta, ami a kés bbiek folyamán a System V állományrendszerré n tte ki magát. Ennek a felépítését majd a VI.3.6. fejezet részletesen tárgyalja.

A programozási környezet egyre népszer bbé vált a laboratórium munkatársainak körében, de a továbblépéshez a legnagyobb lökést a C nyelvre való áttérés jelentette, amit Dennis Ritchie, Thompson kollégája fejlesztett ki. Ennek óriási jelent sége volt a UNIX fejlesztésében és jelent s szerepet játszott a kés bbi gyors terjedésében. A UNIX-ot ett l kezdve már magas szint programozási nyelven írták, illetve arra törekedtek, hogy az implementáció amennyire csak lehet, hardver független legyen. Ehhez modularizálták a rendszer felépítését, elválasztották a hardverfügg részeket a hardver független részekt l, és az el bbiek

kivételével mindent C-ben kódoltak. Az el bbit hatékonysági okokból továbbra is alacsony szinten írták meg.

A nagy népszer ségnek köszönhet en Thompson és Ritchie 1971-ben publikálta az els UNIX kézikönyvet. Mivel ekkor egy 1956-os trösztellenes törvény miatt az AT&T nem jelenhetett meg a számítógép piacon, a UNIX-ot (forráskód formájában is) ingyenesen az oktatási intézmények rendelkezésére bocsátotta, ami meggyorsította a UNIX elterjedését. Azonban minden érmének két oldala van: a gyors terjedés mellett ett l kezdve a UNIX-nak

I. UNIX

3

rengeteg egymástól eltér eredményezett.

változata jelent meg, ami a kés bbiekben jelent s problémát

A Kaliforniai Berkeley Egyetem 1974-ben jutott hozzá egy UNIX licenszhez. A használat során számos hasznos kis programmal egészítették ki, illetve módosításokat eszközöltek rajta. Ennek eredményeként létrejött a Berkeley Software Distribution (BSD), ami ma a UNIX egyik legelterjedtebb alapváltozatát fémjelzi. A másik legjelent sebb alapváltozat a System V a UNIX-ot útjára bocsátó AT&T nevéhez köt dik. Számos kereskedelmi változat is megjelent a piacon, amelyek általában valamelyik alap UNIX változatra építve értéknövelt szolgáltatásokat nyújtottak, illetve a rendszer bizonyos részeit kereskedelmi alkalmazásokra alkalmassá tették. A legismertebb változatok: a Sun cég SunOS változata, ami a 4.2BSD-n alapul, majd a kés bbi Solaris változatok, amik már a System VR4 rendszert vették alapul, a Santa Cruz Operation kidolgozta a System VR3 alapjaira építve Intel processzorra az SCO UNIX-ot, az IBM az AIX-et (ami els k között alkalmazott kereskedelmi napló alapú (journaling) állományrendszert, a Hewlett-Packard Corporation megjelent a HP UX rendszerével, és a Digital piacra dobta az Ultrixot (majd kés bb a DEC OSF/1-et, amit Digital UNIX-ra kereszteltek). Az Ultrix volt az egyik els többprocesszoros UNIX rendszer.

A UNIX elterjedéséhez, mint azt már korábban láttuk, nagyban hozzájárult, hogy eleinte ingyen hozzá lehetett jutni a forráskódhoz, viszont egyben a ma egyik legnagyobb problémát is ez jelenti, ugyanis számos, egymástól többé-kevésbé eltér változat jelent meg. Az utóbbi id ben ezt a problémát orvosolandó, több szabványosítási kísérlet is megindult. A legtöbb gyártó megegyezett pár szabványban. Ezek közé tartozik az AT&T System V Interface Definition (SVID) szabványa, az IEEE Posix szabvány (amit a VI.5. fejezet részletesen tárgyal) és az X/Open konzorcium X/Open Portability Guide. Ezen szabványok mindegyike a programozó és az operációs rendszer közötti interfésszel foglalkozik, és nem tör dik annak megvalósításával. Az 1990-ben megjelentetett POSIX1003.1 szabvány (elterjedt nevén POSIX.1) ötvözi az SVR3 és a 4.3BSD lényegi részeit. Széleskör elfogadásának egyik oka, hogy a szabvány semelyik UNIX változat mellett sem kötelezi el szorosan magát (lásd a VI.5. fejezetet).

I. UNIX

4

A rendszer fejl désével egyre b vült, gazdagodott a rendszer nyújtotta szolgáltatások halmaza. Ezek közül talán a legfontosabbak a System V IPC-ként ismert folyamatok közötti kommunikációs eszközök, illetve a hálózati kommunikációt támogató eszközök, amik manapság már minden UNIX változat kerneljében megtalálhatók.

A UNIX rendszerek lépést tartanak a számítógépes hardver technológia fejl désével. A leggyakrabban ez a rendszer átemelését (portolását) jelenti újabb processzorokra és architektúrákra. Ez általában nem okoz túl nagy gondot, hisz mint azt már láttuk, a rendszer számottev része C-ben íródott. Néhány esetben azonban a rendszerfejleszt k lényegesen keményebb feladattal találják szemben magukat: jelent s módosításokat kell végrehajtani a kernelen. A hagyományos UNIX-ot egyprocesszoros rendszerekre tervezték, így annak idején nem tervezték bele az adatok védelmét több processzor konkurens adathozzáféréseivel szemben. Bizonyos gyártók ezt zárak bevezetésével orvosolták, míg mások radikálisan megváltoztatták a kernel szerkezetét.

A különféle hardver technológiák eltér

fejl dési sebessége jelent s hatást gyakorol az

operációs rendszer tervezésére. Az els , PDP-7-esen futtatott UNIX rendszer megjelenése óta a CPU sebessége körülbelül három nagyságrenddel gyorsult, a felhasználók rendelkezésére álló memória és diszk terület több mint egy nagyságrenddel növekedett, azonban a memória és a lemez sebessége alig duplázódott meg. A 70-es években a UNIX teljesítményét a processzor sebessége és a memória mérete korlátozta, ezért a rendszer folyamatok háttértárra írásával (swapping) és lapozási technikákkal próbálta kezelni a memória gondokat. Az id el re haladtával a memória és a CPU sebesség okozta problémák egyre inkább elvesztették jelent ségüket, a rendszer egyre inkább B/K korlátozottá vált. Ez jelent s kutatásokat inspirált az állományrendszer, a virtuális memória kezelés és a tárolás megszervezésének a területén, hogy megbirkózzanak a lemezen tárolt adatok elérési ideje, mint sz k keresztmetszet okozta problémákkal. Megjelentek az újszer elveken alapuló állományrendszerek (pl. journaling), illetve kidolgozták a RAID technikát.

A technológia gyors fejl dése lehet vé tette újszer alkalmazások kialakulását. Megjelentek a multimédiás alkalmazások, amik korlátos válaszid ket és er forrás rendelkezésre állási garanciákat igényeltek. A beágyazott alkalmazások is hasonló igényeket támasztottak az

I. UNIX

5

operációs rendszerrel szemben. Ennek hatására a modern UNIX rendszerek kernelében megjelentek ún.,,puha valósidej " (soft real-time) elemek. (Például a Solaris új változatai támogatják a soft real-time ütemezési algoritmusok alkalmazását.)

Az eredeti UNIX rendszer egyik nagy erénye a kis méretében rejlett. Az egész kezdeti fejlesztés h en tükrözte az ,,A kicsi szép" filozófiát. A hatékony m ködést egyszer eszközök, épít kövek alkalmazása garantálta, amiket rugalmasan lehetett összeépíteni (az egyik legszebb példa erre a sz r k alkalmazása). A hagyományos UNIX kernel azonban monolitikus és nehezen b víthet volt. Ahogy egyre több funkcióval b vült, egyre inkább elhajlott a kezdeti filozófia irányától, egyre nagyobbá vált.

A továbbiakban áttekintjük a UNIX bels alrendszerek funkcióit és megvalósításait.

felépítését és tárgyaljuk a legfontosabb

I.3. Bels szerkezet és m ködés

Az alábbi részek a UNIX rendszer legfontosabb alrendszereit és funkcióit tárgyalják.

I.3.1. Szerkezet

Ebben a részben a UNIX kernel felépítését tárgyaljuk. Röviden ismertetjük a hagyományos és a mai modern UNIX kernel réteg (illetve modul) szerkezetét és vázoljuk ezek f feladatait.

A korai 80-as évekig az eltér UNIX változatok ellenére a kernelek elég egységes képet mutattak. Egyetlen állományrendszer típust, egyetlen ütemezési politikát és egyetlen végrehajtható állomány formátumot támogattak (lásd a VI.3.1. ábrát).

I. UNIX

6

állományrendszer (s5fs)

virtuális memóriakezel rendszer

betölt

blokkos berendezésmeghajtó kapcsoló

karakteres berendezésmeghajtó kapcsoló

lemeze gység megha jtó

szalag egység megha jtó

hálóza ti megha jtó

nyomt ató megha jtó

termin ál megha jtó

VI.3.1. ábra: A hagyományos UNIX rendszerek bels szerkezete

A VI.3.1. ábra jól mutatja a moduláris felépítést. Ebben a szerkezetben a rugalmasságot a blokkos és a karakteres berendezés kapcsolók biztosították. Ezek lehet vé tették, hogy a rendszerben eltér típusú berendezéseket egy egységes interfészen keresztül lehessen elérni. A réteges szervezésben rejl el nyöket már ekkor is hatékonyan kihasználták. Az egymásra épül rétegek a közvetlen felettük lév réteg szolgáltatásait egy jól definiált interfészen keresztül vehették igénybe. Sajnos a korai implementációkban a megvalósítás

leegyszer sítése érdekében ez alól akadt néhány kivétel, ami a kés bbiekben meg is nehezítette a fejleszt k dolgát.

Mint azt majd a kés bbiekben látni fogjuk, a 80-as évek közepén egyre nagyobb teret nyer elosztott állományrendszerek megkövetelték, hogy a UNIX adjon támogatást mind a lokális, mind pedig a távoli állományrendszerek kezeléséhez. Másrészt az osztott könyvtárak megjelenésével szükségessé vált több futtatható fájl formátum támogatása is, illetve speciális alkalmazások (mint pl. a korábban említett multimédiás alkalmazások) az ütemezéssel szemben is újfajta igényeket támasztottak. Ebb l adódóan rugalmasabb kernel szerkezet kialakítására volt szükség, ami több alrendszer, interfész laza, de szerves kapcsolatából épül

I. UNIX

7

fel. A VI.3.2.. ábra ezt az új szerkezetet mutatja. A küls lekerekített téglalapok interfészeket reprezentálnak, amiket számos eltér módon lehet megvalósítani. Jól látható, hogy az egyes f bb funkciókhoz tartozik egy-egy interfész (de akár több is), amelyeken keresztül az adott funkciók többféle megvalósítását el lehet érni.

RFS NFS

s5fs FFS

lemezegység meghajtó blokkos berendezésmeghajtó kapcsoló

vnode/vfs interfész hálózati meghajtó terminál meghajtó közös szolgáltatások virtuális memóriakezel alrendszer ütemez alrendszer felhasználói folyamatok rendszer folyamatok

szalagegység meghajtó

STREAMS alrendszer

CD-ROM meghajtó állomány leképzés

berendezés leképzés

exec kapcsoló

valósidej folyamatok

új végrehajtható állomány formátumok

a.out formátum

VI.3.2. ábra: A modern UNIX-ok egy lehetséges szerkezeti felépítése

Erre talán az egyik legjobb példa az állományrendszer. Míg a korai UNIX rendszerekben csak egyetlen állományrendszer állt rendelkezésre, a gyakorlati igények megkövetelték, hogy egyszerre több, akár eltér típusú állományrendszerrel is dolgozni lehessen. Ennek

eredményeképp el állt a vnode/vfs interfész, ami már absztrakt szinten kezeli az állományrendszert, lehet vé téve ezáltal eltér állományrendszerek egységes kezelését. Az

I. UNIX

8

interfészb l kiinduló nyíl a különféle implementációkat mutatja. Ebben a példában a hagyományos System V s5fs mellett található egy Berkeley FFS, egy elosztott NFS és RFS állományrendszer implementáció is. Az állományrendszerek részletes leírását és fejl désüket a VI.3.6. fejezet részletesen tárgyalja. A többi alrendszer esetén is hasonló igények merültek fel. A VI.3.2. ábrán például a futtatható állományok kezeléséért felel s exec kapcsolóhoz (alrendszer) is a hagyományos a.out végrehajtható állomány formátum mellett más formátumok kezelését is lehet vé kell tenni.

A továbbiakban a UNIX f bb funkcióit, alrendszereit, és a hozzájuk kapcsolódó interfészeket tárgyaljuk.

I.3.2. Folyamatkezelés

Mint azt korábban láttuk, az operációs rendszer els dleges feladata, hogy a felhasználói programoknak, alkalmazásoknak egy végrehajtási környezetet (execution environment) biztosítson. A UNIX végrehajtási környezet a folyamat (process) absztrakción alapszik. A hagyományos UNIX rendszerekben a folyamat egyetlen utasítássorozatot hajt végre egy címtérben (address space). A modern UNIX változatokban már egy folyamaton belül egyszerre több szálon futhat végrehajtás, több vezérlési pont található. A szálak (threads) vagy könny súlyú folyamatok (lightweight processes) bevezetése bizonyos

alkalmazásoknál jelent s hatékonyság növekedést eredményezett. A kliens-szerver architektúra szerver komponense hatékonyan kihasználja a szálak alkalmazásából adódó el nyöket.

Ebben a fejezetben a UNIX hagyományos folyamat-modellt ismertetjük. A UNIX modern folyamat modelljének a részleteit az érdekl d olvasó az irodalomjegyzékben felsorolt

idevágó irodalmak tanulmányozásából részletesen megismerheti.

I. UNIX

9

A UNIX rendszer egy multiprogramozott környezet, a rendszerben egyszerre párhuzamosan több folyamat is aktív. Ezen folyamatok egy virtuális gépen (virtual machine) futnak, minden folyamat a B/K m veletek és a készülékek vezérlésen kívül úgy érzékeli, mintha csak egyedül futna a gépen. A B/K m veleteket és a készülék vezérlést az operációs rendszer

végzi el a folyamat számára. A virtuális gép koncepciójának megfelel en minden folyamat rendelkezik egy regiszter készlettel, ami a valós hardver regisztereknek felel meg. A rendszerben számos aktív folyamat található, viszont általában ­ az egyetlen CPU-nak megfelel en ­ csak egy hardver regiszterkészlet létezik. A kernel az aktív, futó folyamat regisztereit tartja a hardver regiszterekben, a többi folyamat regiszter készletének tartalmát elmenti folyamatonkénti adatszerkezetekbe. A kernel tehát az a speciális program, ami közvetlenül a hardveren fut, és a kernel valósítja meg több más rendszer szolgáltatással egyetemben a folyamat modellt.

I.3.2.1. Végrehajtási módok és környezetek

A UNIX futtatásához olyan hardverre van szükségünk, ami legalább két végrehajtási módot (execution mode) biztosít: egy privilegizált kernel módot, és egy felhasználói (user) módot. A kernel a címtér egy részét védi felhasználói módú hozzáféréssel szemben, valamint bizonyos privilegizált utasítások csak kernel módban adhatók ki. Ezek tipikusan memóriakezel , illetve B/K kezel utasítások. Ma már szinte minden általános célú UNIX változat alkalmaz virtuális memóriakezelést (virtual memory). Ekkor a folyamatok a virtuális címtartományban adnak ki címeket és a rendszer címleképzési táblázatokkal futási id ben köti ezekhez a virtuális címekhez a valós fizikai címeket. Minden folyamat virtuális címtartományának egy rögzített része a kernel fizikai címtartományára képz dik le, ahol a kernel kódja és adatszerkezetei találhatók. Ezt a kernel területet (kernel area) csak kernel módban lehet elérni. A folyamatok közvetlenül nem, csak rendszerhívásokkal tudják elérni a kernelt.

Meg kell említeni két fontos folyamatonkénti adatszerkezetet, amiket bár a kernel kezel, gyakran a folyamat címterében implementálnak. Ezek az u-terület (u area) és a kernel verem (kernel stack). Az u-terület a kernel számára fontos információkat tárol a folyamatról, mint például a megnyitott állományok táblája, azonosítók, a regiszterek elmentett tartalma, ha

I. UNIX

10

a folyamat nem fut, stb. Ezen információkat a kés bbiekben részletesebben tárgyaljuk. Bár az u- terület a folyamat címterében található, ahhoz csak kernel módban lehet hozzáférni, annak tartalmát a folyamat maga önkényesen nem módosíthatja. A végrehajtási környezet (execution context) a folyamat szempontjából nagy jelent séggel bír. A kernel részek végrehajtódhatnak folyamat vagy kernel környezetben (process, kernel context). Folyamat környezetben a kernel az adott folyamat számára hajt végre valamilyen feladatot (például egy rendszerhívás során). Ekkor a kernel hozzáfér a folyamat címteréhez, uterületéhez és a kernel verméhez. S t, a kernel folyamat környezetben blokkolhatja is az aktuális folyamatot, ha a végrehajtás során valamilyen er forrásra vagy eseményre kell várakoznia. A kernelnek bizonyos rendszer szint feladatokat is végre kell hajtania, amiket nem

kifejezetten egy adott folyamat számára hajt végre, ezeket rendszer környezetben hajtja végre. Tipikus rendszer környezetben végrehajtott feladatok a küls megszakítások kezelése, a

prioritások újraszámítása, stb. Rendszer környezetben a kernel nem fér hozzá közvetlenül az aktuális folyamat címteréhez, u-területéhez vagy kernel verméhez. Meg kell jegyezni, hogy bizonyos speciális indirekt leképzések segítségével a kernel ekkor is elérheti az aktuális folyamat címterét. Rendszer környezetben a kernel nem blokkolódhat, mert ekkor ezzel egy ,,ártatlan" folyamatot blokkolna. A VI.3.3. ábrában a mód és a környezet tengelyek négy negyedre osztják az ábrát. Az egyes negyedekbe beírtuk az adott állapotban elvégezhet m veleteket.

I. UNIX

11

folyamat környezet

alkalmazás (felhasználói) kód, csak a folyamat címteréhez lehet hozzáférni user mód

rendszerhívások, kivételek, a folyamat és a rendszer címteréhez is hozzá lehet férni kernel mód megszakítások, rendszer feladatok, , csak a rendszer címteréhez lehet hozzáférni

nem megengedett

rendszer környezet

VI.3.3. ábra: Végrehajtási mód és környezet

I.3.2.2. A folyamat absztrakció ­ a folyamatok állapotai és az állapot-átmeneti gráf

A folyamatokat gyakran úgy definiálják, hogy ,,A folyamat egy végrehajtás alatt álló program." A UNIX rendszerrel kapcsolatban talán szerencsésebb, ha úgy fogalmazunk, hogy a folyamat egy olyan entitás, ami egyrészt futtat egy programot, másrészt biztosítja a futáshoz szükséges végrehajtási környezetet. A UNIX folyamatai egy jól-definiált hierarchiát alkotnak. Minden folyamatnak pontosan egy szül je (parent) van (aki mint azt majd a kés bbiekben látjuk, egy fork rendszerhívással hozza létre gyermekét), és egy vagy több gyermek folyamata (child process) lehet. A folyamat hierarchia tetején az init folyamat helyezkedik el. Az init folyamat az els

létrehozott felhasználói folyamat, a rendszer indulásakor jön létre. Minden felhasználói folyamat az init folyamat leszármazottja. Néhány rendszer folyamat, mint például a swapper és a pagedaemon (a háttértár kezelésével kapcsolatos folyamatok), szintén a rendszer indulásakor jön létre és nem az init folyamat leszármazottja. Ha egy folyamat befejez désekor még léteznek aktív gyermek folyamatai, akkor azok árvákká (orphan) válnak és azokat az init folyamat örökli.

I. UNIX

12

A UNIX folyamatai minden id pillanatban egy jól definiált állapotban találhatók. Ezeket az állapotokat és a közöttük lehetséges állapot átmeneteket egy állapot átmeneti gráffal lehet szemléletesen ábrázolni. Az VI.3.4. ábra ezt a gráfot mutatja.

user fut

rendszerhívás, megszakítás fork kiinduló (henyél)

visszatérés rendszerhívásból vagy megszakításból

fork

swtch

kernel fut

exit zombi sleep

wait

futásra kész

swtch

wakeup

alszik

stop stop continue continue

felfüggesztve futásra kész

wakeup

felfüggesztve alszik

VI.3.4. ábra: A folyamatok állapot-átmeneti gráfja

Mint azt korábban láttuk, egy új folyamatot a fork rendszerhívással lehet létrehozni, amelynek hatására a folyamat kezdeti állapotba kerül. Itt végrehajtódnak a legfontosabb inicializálások, majd a fork lefutása után a folyamat készen áll a futásra, már csak a processzorra van szüksége. Ezt az állapotot jelöli a futásra kész (ready) állapot. Innen az ütemezés hatására egy környezetváltással (context switch) (swtch rendszerhívás) kernel fut (kernel running) állapotba kerül. Egy frissen létrejött folyamat a rendszerhívás befejez dése után átlép user fut (user running) állapotba. Egy user módban futó folyamat egy rendszerhívás vagy egy

I. UNIX

13

megszakítás hatására léphet át kernel fut állapotba, ahonnan a rendszerhívásból vagy a megszakításból való visszatérés után léphet vissza a user fut állapotba. A VI.3.4. ábrán a további állapot átmenetek: amikor egy folyamat befejezi futását és végrehajtja az exit rendszerhívást, átlép zombi (zombie) állapotba. A zombi állapotban a folyamat már felszabadította a foglalt memóriát, lezárta az állományokat, minden er forrását visszaadta a rendszernek, csak a proc struktúráját tartja fogva, amiben visszatérési és statisztikai információkat tárol a szül számára. A szül wait rendszerhívásának hatására a folyamat véglegesen kilép az állapot átmenet gráfból, felszabadul a proc struktúra is, a folyamat teljesen megsz nik létezni. Amikor egy folyamatnak valamilyen er forrásra kell várakoznia, akkor kiad egy sleep rendszerhívást és alvó állapotba megy. Az alvó állapotból a várt esemény bekövetkezése által kiváltott wakeup rendszerhívás hatására a folyamat átlép a futásra kész állapotba és várja, hogy az ütemez ismét futásra ütemezze. A VI.3.4. ábra alján a bekeretezett két állapotot el ször a 4BSD vezette be, majd kés bb a SVR4 is átvette. Egy alvó folyamat egy stop jelzés hatására átlép a felfüggesztve alszik (stopped + asleep) állapotba. (A stop1 jelzés

különlegessége, hogy azt a rendszer a többi jelzéssel ellentétben azonnal kezeli. A jelzések kezelésével részletesebben a VI.3.4. fejezet foglalkozik.) Ebb l az állapotból a continue jelzés hatására a folyamat visszalép az alvó állapotba. Ha a felfüggesztve alszik állapotban következik be egy wakeup rendszerhívás, akkor a folyamat átlép a felfüggesztve futásra kész állapotba, ahonnan egy continue jelzés hatására kerül át a futásra kész állapotba.

I.3.2.3. Folyamatok környezete (kontextus)

Mint azt korábban láttuk, a folyamat absztrakció egy végrehajtási környezetet biztosít. Ennek a környezetnek tartalmaznia kell a folyamatok leírásához szükséges összes információt. Ezek az alábbi f bb részekb l állnak:

· felhasználói (user) címtér
1

A stop és a continue jelzések fogalmi megnevezések. Az egyes UNIX változatokban

ezekhez a jelzésekhez más és más szimbolikus neveket rendeltek. Lásd az adott implementáció jelzésekkel kapcsolatos man lapjait.

I. UNIX

14

· vezérlési információk: · u-terület · proc struktúra (folyamattábla bejegyzés) · hitelesít k (credentials), többek között a felhasználó és csoport azonosítók) · környezetváltozók · hardver kontextus (program számláló, veremmutató, a processzor állapota, memóriakezel regiszterek, lebeg pontos egység regiszterei, stb.)

A hardver regiszterei mindig a végrehajtás alatt álló aktuális folyamat környezetét tárolják. Környezetváltáskor ezen regiszterek tartalmát az operációs rendszer elmenti az aktuális folyamat u-területére. Az ütemez által kiválasztott új folyamat környezetét a kernel betölti a regiszterekbe, és az új folyamat folytathatja a futását.

A továbbiakban fontosságuk miatt részletesebben is mertetjük a hitelesít ket és megadjuk az u-területen és a proc struktúrában tárolt f bb információkat.

Hitelesít k (credentials)

A UNIX rendszerben minden felhasználót egy egyedi azonosító, a felhasználói azonosító (UID) azonosít. Ezen felül minden felhasználó egy vagy több csoportba tartozik, amiket szintén egyedi azonosítók, a csoportazonosítók (GID) azonosítanak. Minden rendszerben van egy kitüntetett felhasználó, a superuser, aki kitüntetett jogosultságokkal rendelkezik a rendszerben. A superuser UID-je 0, GID-je 1. Meg kell jegyezni, hogy a modern UNIX rendszerek fejlett biztonsági megoldásokat nyújtanak, ahol a privilégiumokat összefogva kezel superuser absztrakció helyett m veletenkénti privilégiumkezelés valósul meg. Az azonosítókból minden folyamat egy párral rendelkezik: a valódi (real) és az effektív (effective) azonosítókkal. Az effektív azonosítók (UID, GID) az állománykezelésben, míg a valódi azonosítók a jelzések kezelésében töltenek be meghatározó szerepet. Az operációs rendszer ki is használja ezt a kett sséget. Amikor egy folyamat az exec rendszerhívással futtat egy programot, aminek a suid bitje be van állítva, akkor a kernel a folyamat effektív UID-jét átállítja a végrehajtható állomány tulajdonosának az azonosítójára. Hasonlóan, ha a program sgid bitje be van állítva, akkor a kernel a folyamat effektív GID-jét átállítja a végrehajtható

I. UNIX

15

állomány tulajdonosának az azonosítójára. Ezen a mechanizmuson keresztül a UNIX különleges jogosultságokat tud biztosítani a felhasználóknak bizonyos feladatok

végrehajtásához. A mechanizmus alkalmazásának egy gyakran idézett példája a passwd program, amivel a felhasználó megváltoztathatja a jelszavát. A jelszó egy a rendszer tulajdonában lév jelszó adatbázisban található, amit a felhasználók közvetlenül nem

módosíthatnak. A passwd program tulajdonosa a superuser és a suid bitje be van állítva. Így amikor a felhasználó a programot futtatja, hogy megváltoztassa a jelszavát, akkor állománykezelés szempontjából superuseri jogosultságokat kap, így elvégezheti a megfelel módosítást. Ezen felül még a setuid és a setgid rendszerhívásokkal lehet az azonosítókat módosítani. A felhasználók ezekkel a rendszerhívásokkal az effektív azonosítóikat visszaállíthatják a valódi azonosítóikra, míg a superuser mind az effektív, mind pedig a valós azonosítókat megváltoztathatja.

Az u terület és a proc struktúra

A folyamatokhoz kapcsolódó vezérlési információkat két folyamatonkénti adatszerkezet az uterület és a proc struktúra tárolja. Korábbi implementációkban a kernel egy rögzített méret proc struktúrákból álló tömböt, egy úgynevezett folyamattáblát (process table) tartalmazott. A folyamattábla mérete meghatározta a rendszerben az egyidej leg létez folyamatok

maximális számát. A kés bbi implementációk ezt a merev szerkezetet leváltották egy dinamikus allokációs sémával: a kernel szükség esetén újabb proc struktúrákat tud allokálni. Egy nagyon lényeges különbség van a proc struktúra és az u-terület között: míg a proc struktúra rendszer területen található, addig az u-terület a folyamat címterének része (bár a kernel felügyelete alatt áll). Ebb l adódóan a kernel az összes (nem csak a futó) folyamat proc struktúrájához hozzáfér, míg csak a futó folyamat u-területét éri el (indirekt

mechanizmusokon keresztül elérheti a többi folyamat u-területét is, azonban ez lassabb hozzáférést biztosít). Ebb l adódóan a UNIX rendszerek evolúciója során hatékonysági okok miatt bizonyos korábban az u-területen tárolt (többek között az ütemezéssel és a jelzéskezeléssel kapcsolatos) információkat áthelyeztek a proc struktúrába. Az alábbiakban megadjuk az u-területen és a proc struktúrában tárolt leglényegesebb információkat.

I. UNIX

16

Az u-területen tárolt f bb információk

· PCB (Process Control Block) hardver környezet · mutató a folyamattábla bejegyzésre (proc struktúrára) · valós és effektív UID, GUID · argumentumok, visszaadott értékek, hiba érték az aktuális rendszerhívásból · jelzés kezel k · program fejléc információk (kód-, adat- és veremméret, stb.) · folyamatonkénti állományleíró tábla (nyitott állományokról) · mutató az aktuális könyvtár és a vezérl terminál v-node-jára · CPU használati statisztikák, diszk kvóta, er forrás korlátok · folyamat kernel verme

A proc struktúrában tárolt f bb információk

· PID, PGID, SID (munkamenet azonosító) · kernel címleképzési térkép az u-területhez · az aktuális folyamat állapot · mutatók az ütemezési (alvás esetén az alvó) sorokba · ütemezési prioritás és információk · jelzéssel kapcsolatos információk (pl. maszk) · memóriakezelési információk · mutatók az aktív, szabad, ill. zombi folyamat sorokra · egyéb jelz bitek · hash mutatók · hierarchia információk (folyamatok közötti kapcsolatról)

I.3.2.4. Folyamatok létrehozása

A UNIXban új folyamatok létrehozására a fork rendszerhívás szolgál. A létrejött folyamat majdnem teljes mása a szül folyamatnak, csak a megkülönböztetésükhöz szükséges

I. UNIX

17

adatokban (folyamat azonosító) térnek el. A fork rendszerhívás az alábbi f bb feladatokat hajtja végre:

· háttértár (swap) terület foglalás a folyamat számára · PID generálás a gyermek folyamat számára · proc struktúra foglalás és inicializálás · címleképzés táblák allokálása · u-terület frissítése, hogy az már az új címleképzési táblát tükrözze · osztottan használt kód tartomány megfelel kezelése · szül verem- és adattartományainak duplikálása · referenciák begy jtése osztottan használt er forrásokra (nyitott állományok, stb.) · hardver kontextus inicializálása szül t l másolva · a folyamat futásra késszé tétele, illetve a megfelel ütemezési sorba helyezése · a gyermeknek 0, a szül nek a gyermek PID-jének, mint visszatérési értéknek a visszaadása

I.3.2.5. Folyamatok befejezése (terminálás)

Egy folyamat kétféle okból fejez dhet be (terminálódhat). Ha elvégezte a feladatát, m ködését normál módon fejezte be. Ekkor a folyamat maga adja ki az exit rendszerhívást, ami az exit() függvényt meghívva terminálja a folyamatot. Egy folyamat egy jelzés hatására is befejezheti a futását. Az ilyen ,,rendellenes" terminálás során az operációs rendszer hívja meg az exit() függvényt a folyamat megszüntetése céljából. Az alábbiakban vázlatosan ismertetjük az exit() függvény által elvégzend feladatokat.

· a jelzések ,,kikapcsolása" · a nyitott állományok lezárása · a text állomány és más er források, mint például az aktuális könyvtár felszabadítása · a megfelel információk beírása a statisztika naplóba (log) · az er forrás használati statisztikák és a kilépési státuszt elmentése a proc struktúrába · átlépés zombi állapotba és a folyamat a zombi listára kerül

I. UNIX

18

· amennyiben a folyamatnak még léteznek él gyermekei, azokat az init folyamat örökli · a címtér, a foglalt területek, táblák, címtérképek, a háttértár (swap) terület felszabadítása · SIGCHLD jelzés küldés a szül nek (amely általában figyelmen kívül hagyja azt) · a szül felébresztése, amennyiben az alszik · swtch() rendszerhívással átütemezés kezdeményezése.

Ezek után a folyamat már csak egy folyamattábla bejegyzést foglal. Ezt a folyamat állapotot nevezik zombi állapotnak. A szül feladata, hogy a statisztikai információk begy jtése után ezt a fennmaradó memóriadarabot felszabadítsa. Tipikusan a szül wait() rendszerhívással megvárhatja a gyermek terminálását és felszabadíthatja ezt az utolsó er forrást is.

I.3.3. Ütemezés
A CPU ütemez , illetve az ütemezési algoritmus minden multiprogramozott operációs rendszer lelke. A rendszer teljesítménye illetve a hardver kihasználtsága szempontjából az egyik legfontosabb, ha nem a legfontosabb tényez körültekint en paraméterezett ütemezési algoritmus. Ebben a fejezetben ismertetjük a tradicionálisnak tekintett UNIX ütemezési algoritmust, amit az SVR3, illetve 3.1BSD UNIX rendszerek alkalmaztak. Az ismertetetésre kerül ütemezési algoritmust a UNIX rendszerekben használt ütemezés tipikus példájának tekinthetjük, annak ellenére, hogy a ma használt UNIX rendszerek az algoritmus valamilyen továbbfejlesztett változatát használják. Mint látni fogjuk, a UNIX-ban használt ütemezés meglehet sen összetett. Az ismertetend ütemezési algoritmus kiválasztásával az volt a célunk, hogy a UNIX rendszerek ütemez iben használt minél több ötletet bemutathassunk. I.3.3.1. Az ütemezési algoritmussal szemben támasztott követelmények A UNIX rendszert els sorban többfelhasználós, interaktív és batch programokat egyaránt futtató felhasználói környezetre tervezték. Az ütemezési algoritmussal szemben támasztott követelményeket a következ kben foglalhatjuk össze: · Alacsony válaszid biztosítása az interaktív folyamatok támogatásának érdekében. a megfelel en kiválasztott és a

I. UNIX

19

· Nagy átbocsátó képesség biztosítása. · Az alacsony prioritású, háttérben futó folyamatok éhezésének elkerülése.

A fenti követelményeket még kiegészíthetjük az ütemez kkel szemben támasztott általános kritériumokkal: · A rendszer terhelését figyelembe vev ütemezés, mely a terhelés növekedésével nem hirtelen omlik össze, hanem lehet séget ad beavatkozásra. · A felhasználónak legyen lehet sége a folyamatok futási esélyeinek befolyásolására.

A UNIX ütemezési algoritmusa a fenti követelmények megvalósítása jegyében született, azonban néhány ponton a fenti követelmények egymásnak ellentmondó igényeket képviselnek, így ­ mint látni fogjuk ­ az algoritmus nem mindegyik követelményt elégíti ki maradéktalanul. I.3.3.2. A UNIX-ütemezés rövid jellemzése A UNIX ütemezése prioritásos. A rendszer minden egyes folyamathoz hozzárendel egy, az id ben dinamikusan változó prioritást. Az ütemezés felhasználói, illetve kernel módban eltér egymástól: · A felhasználói módban futó folyamatok ütemezése: preemptív ütemezés, id osztásos, id ben változó prioritású folyamatok, azonos prioritású folyamatok esetén köforgásos (Round-Robin), FCFS (First Come First Served: érkezési sorrend szerinti kiszolgálás). · A kernel módban futó folyamatok ütemezése: nem preemptív ütemezés, rögzített prioritású folyamatok

A kernel módban az ütemezés szigorúan nem preemptív. Kernel kódot végrehajtó folyamatot (pl. rendszerhívás, megszakítás-kezelés) nem lehet kényszeríteni, hogy lemondjon a CPU használatról egy nagyobb prioritású folyamat javára. Újraütemezés akkor következik be, amikor a folyamat önként lemond a futás jogáról (sleep rendszerhívást hajt végre), illetve, amikor a folyamat visszatér kernel módból felhasználói módba. Megjegyzend , hogy a kernel kód újrahívható, vagyis egyszerre több példányban is végrehajtódhat. (Pl. ha egy kernel módban futó folyamat lemond a futás jogáról, vagyis egy

I. UNIX

20

sleep rendszerhívást hajt végre, más folyamat rendszerhívása miatt ugyanaz a kernel-eljárás újra elindulhat.) Annak oka, hogy a kernel futása során az ütemezés nem preemptív, egyszer en az, hogy az operációs rendszer számos olyan adatszerkezetet használ, amit nem lehet egy lépésben megváltoztatni. Ha egy ilyen adatszerkezet változtatása közben vennék el a futás jogát egy kernel módban futó folyamattól, az nem konzisztens állapotban hagyná az operációs rendszer adatállományait, vagy pedig tele kellene t zdelni szinkronizációs m veletekkel a kölcsönös kizárás biztosítása érdekében.

Egy ilyen szituációt szemléltet a 3.1. ábra, ami egy két irányban láncolt lista listaelemének lef zését mutatja. Tegyük fel például, hogy a kernel a szabad memória-lapok láncolt listájából szeretne egy elemet kivenni. A probléma abból adódik, hogy a listaelemet nem lehet egy lépésben lef zni a láncból. A lef zési lépések köztes állapotát (amikor a második elem lef zése közben az egyik irány mutatói már megváltoztak) illusztrálja a 3.2. ábra. Ha a folyamattól el lehetne venni a vezérlést miközben az a listán dolgozik, a következ folyamat a lista végér l keresve eggyel kevesebb memória lapot látna, mint elölr l indulva, vagyis a kernel adatai nem lennének konzisztens állapotban.
Megjegyzés: Majd átszámozni

.1. ábra: Láncolt lista egy közbüls elem lef zése el tt

.2. ábra: Láncolt lista egy közbüls elem lef zése közben I.3.3.3. Folyamatok ütemezési prioritása A UNIX-ban a folyamatok prioritását 0-127 közötti egész számok jelölik. (Némelyik UNIX változatban ett l eltér prioritási tartományt használnak.) A nullás prioritás jelöli a

legnagyobb prioritást, vagyis a kisebb prioritási érték nagyobb prioritáshoz tartozik. A rendszer a felhasználói és a kernel módban futó folyamatok prioritását eltér módon kezeli. A prioritási értékeket két prioritási tartományra osztja amint azt a következ , 3.3. ábra
Megjegyzés: Majd átszámozni

I. UNIX

21

mutatja. Az 50 fölötti prioritási értékeket felhasználói módban futó folyamatokhoz rendeli a rendszer, míg az 50 alatti prioritások kernel módú folyamatokhoz tartoznak.

0 . . . 49 50 . . . 127

legnagyobb prioritás

KERNEL prioritások

FELHASZNÁLÓI prioritások legkisebb prioritás

.3. ábra: A UNIX prioritási tartományai

Prioritás meghatározása kernel módban

A kernel módban futó folyamat prioritása statikus, nem függ attól, hogy a folyamat mennyit használta a CPU-t, vagyis mennyi ideig futott. A prioritás attól függ, hogy a folyamat milyen ok miatt hajtott végre sleep rendszerhívást, vagyis, hogy milyen eseményre várakozik. Emiatt a kernel prioritást szokták alvási prioritásnak is nevezni. Jogos a kérdés, hogy mi alapján határozza meg a rendszer annak a kernel módban futó folyamatnak a prioritását, amelyik nem hajtott még végre sleep rendszerhívást mióta kernel módba került. A válasz nagyon egyszer . A rendszer a folyamatok prioritását az ütemezés, vagyis az ütemez folyamat futása alkalmával vizsgálja. Mivel kernel módban a UNIX nem preemptív, ütemezésre csak akkor kerülhet sor, ha a futó folyamat végrehajt egy sleep rendszerhívást. A sleep rendszerhívás végrehajtása után viszont meghatározható a kernel módú prioritás.

I. UNIX

22

Vizsgáljuk meg egy kicsit részletesebben is a kernel prioritás generálását. Hogyan kerülhet egy folyamat kernel módba? Két lehet ség van: vagy rendszerhívást hajt végre (vagyis implicit módon egy trap utasítást), vagy küls megszakítás kiszolgálása történik. Ha rendszerhívás történik, a kernel módú futást felhasználói módú futás el zte meg, amikor is a folyamat prioritása adott. Ezt az értéket - mint majd látni fogjuk - a rendszer kés bbi használatra elmenti. Ebben a pillanatban folyamat kernel módú prioritása - mint láttuk elvileg nem határozható meg, de ez nem okoz problémát.

Megszakítás esetén a rendszer nem ütemezi át a folyamatokat, a megszakítási rutin az éppen futó folyamat környezetében hajtódik végre. A megszakítási rutint az operációs rendszer úgy tekinti, mintha az éppen futó (vagyis a megszakított) folyamat futna tovább. (Ennek következtében minden megszakítási rutin által felhasznált id a megszakított folyamat

id kvótáját terheli.) Ütemezésre csak a megszakítás kiszolgálása után kerülhet sor, hiszen a megszakítási rutin kernel módban hajtódik végre. Ha a megszakított folyamat eredetileg is kernel módban futott, a rendszer nem tér vissza felhasználói módba, vagyis az ütemez nek megintcsak nincs lehet sége futni. Ha a megszakított folyamat felhasználói módban futott, akkor a visszatérés után a megszakított folyamat felhasználói módú prioritása él tovább. Láthatjuk tehát, hogy megszakítás kiszolgálása esetén, bár kernel módú futás történik, a rendszernek nincs szüksége kernel módú prioritás számolására. (Megjegyezzük, hogy az ütemezés kritikus szakaszaiban, amikor például éppen nincs futásra kijelölt folyamat és a környezet is indefinit, a megszakítások tiltva vannak)

Folyamatok prioritásának meghatározása felhasználói módban

Felhasználói módban a prioritást egy adott pillanatban két dolog határozza meg: · a felhasználó által adott küls prioritás (nice szám, kedvezési szám), · a folyamat korábbi CPU használata. A nice szám a felhasználó által meghatározható érték, amivel kifejezheti, hogy mennyire fontos az általa indított folyamat. Minél kisebb egy folyamat nice száma, annál fontosabb a folyamat, vagyis annál nagyobb lesz a prioritása a futás során.

A prioritás számításához a következ négy paramétert használja a UNIX:

I. UNIX

23

· p_pri: · p_usrpri: · p_cpu: · p_nice:

aktuális ütemezési prioritás felhasználói módban érvényes prioritás a CPU használat mértékére vonatkozó szám a felhasználó által futás elején adott nice szám

Az operációs rendszer a fenti paramétereket minden folyamat esetén külön-külön számon tartja.

Az ütemez a p_pri paraméterben tárolja a folyamat aktuális prioritását, tehát ez alapján választja ki, hogy melyik folyamatot ütemezze futásra. Amikor a folyamat felhasználói módban fut, akkor a p_pri megegyezik a p_usrpri-vel. Kernel módba váltásnál a p_pri paraméter megkapja a kernel módban érvényes prioritás értékét, míg a p_usrpri értéke nem változik, s t a rendszer továbbra is karbantartja a p_usrpri értékét az ütemezési algoritmus szerint. Amikor visszatér felhasználói módba, a rendszer a p_pri értékét a p_usrpri-b l frissíti. Amikor egy folyamat felébred egy sleep hívás után, akkor a kernel módú prioritása lesz érvényes, ami, mint láttuk, mindig magasabb, mint a felhasználói módú folyamatok prioritása. A rendszer így biztosítja a kernel módú folyamatok preferenciáját. A p_cpu paraméter a folyamat CPU használatára jellemz paramétere, a folyamat indításakor nulla értékre áll. érték. A folyamat p_cpu

A folyamatok p_cpu értékének módosításai az óra-megszakításhoz kapcsolódnak a következ k szerint (3.4. ábra): · p_cpu-t minden óra-megszakítás alkalmával emeli a kiszolgáló rutin a futó folyamatnál: p_cpu := p_cpu +1 · ha több azonos felhasználói prioritású folyamat van a rendszerben az aktuálisan legmagasabb prioritási szinten, minden tizedik megszakításnál lefut a Round-Robin algoritmus, vagyis az ütemez az azonos prioritású folyamatok között forgatja a végrehajtás jogát · minden századik megszakításnál az ütemez újraszámolja minden folyamat felhasználói prioritását a következ három lépésben: · korrekciós faktor (KF) számítása: KF: = 2*futásra kész folyamatok száma / (2* futásra kész folyamatok száma+1)

I. UNIX

24

· minden folyamat CPU használatára jellemz változó kiszámítása: p_cpu = p_cpu * KF · felhasználói prioritás kiszámolása: p_usrpri = P_USER+p_cpu/4+2*p_nice ahol P_USER egy alkalmas konstans.

futó folyamat minden óramegszakítás minden 10. óramegszakítás minden 100. óramegszakítást p_cpu := p_cpu +1

minden folyamat

Megvizsgálja, van-e a futónál magasabb prioritású folyamat. Ha van, újraütemez. Round-Robin algoritmus: ha több azonos prioritású folyamat van a legmagasabb prioritású pozícióban, 10 óra-megszakításonként váltja a futó folyamatot korrekciós faktor számítása p_cpu = p_cpu * KF p_usrpri = P_USER+p_cpu/4+2*p_nice

.4. ábra: Az óra-megszakításhoz köt d ütemezési tevékenységek A fenti képletben szerepl P_USER egy konstans. Arra szolgál, hogy a p_usrpri változó, vagyis a folyamat felhasználói prioritása, ne hagyja el a felhasználói prioritási tartományt. (A P_USER értéke a legkisebb felhasználói prioritás értékével egyezik meg, vagyis példánkban P_USER = 50.)

A KF korrekciós faktor számításával a rendszer terhelését igyekszik figyelembe venni az ütemez . Ha megvizsgáljuk a korrekciós faktor viselkedését, láthatjuk, hogy a korrekciós faktor értéke annál inkább egyhez tart, minél több futásra kész folyamat volt a rendszerben az elmúlt ütemezési periódusban (elmúlt 100 óramegszakítás ideje alatt), vagyis minél nagyobb volt a rendszer terheltsége: 1 futásra kész folyamatnál ez a szám 2/3; 2 folyamatnál 4/5, 10 folyamatnál 10/11, stb. Megjegyezzük, hogy számos UNIX rendszer a korrekciós faktor értékét konstansnak (½) veszi. Nagyon fontos kiemelni, hogy az ütemezési algoritmus, illetve a hozzá köt d tevékenységek nem közvetlenül a megszakítási rutinban hajtódnak végre, hiszen ekkor feleslegesen hosszú id t töltene a rendszer a megszakítás kiszolgálásával. Az ütemezéshez köt d rutinokat ­

I. UNIX

25

hasonlóan más ciklikusan végrehajtandó rendszerfeladatokhoz ­ a call-out mechanizmus segítségével hajtja végre a rendszer. Err l a kés bbiekben még részletesen szó lesz. Másik ide tartozó megjegyzés, hogy a fent említett, óramegszakításokhoz köt d három

tevékenység gyakorisága változhat az egyes UNIX rendszerekben. A fent szerepl 10-es, illetve 100-as számok tipikus értékek. I.3.3.4. Környezetváltás ütemezéskor Az ütemezési algoritmus ismeretében tanulságos végignézni, hogy milyen esetekben történik környezetváltás a UNIX-ban, vagyis milyen események hatására kerül át a CPU-használat joga ­ az ütemez közrem ködésével ­ az egyik folyamattól a másik folyamathoz.

Környezetváltás a következ esetekben történik: · Nem preemptív ütemezés: · Egy folyamatnak várnia kell valamilyen eseményre (sleep rendszerhívást hajt végre). · Egy folyamat befejez dik (exit rendszerhívást hajt végre). · Preemptív ütemezés: · A 100-adik óraciklusban a prioritások újraszámításakor az egyik folyamat prioritása nagyobb lesz, mint a futó folyamat prioritása. Ekkor prioritás-vizsgálat után új folyamatot futtat a rendszer, tehát környezetváltás szükséges. · A 10-edik óraciklus esetén a Round-Robin algoritmus egy másik, azonos prioritású folyamatot választ futásra. · Egy futó folyamat, vagy megszakítási rutin m ködésének eredményeképpen felébred (ready to run állapotba jut) egy, az aktuálisan futónál magasabb prioritású, eddig várakozó folyamat.

I.3.3.5. Adatszerkezetek a folyamatok prioritásának tárolására Az id ben változó prioritások tárolására a rendszer dinamikus adatszerkezetet használ. Az azonos prioritású, futásra kész folyamatok láncolt listán tárolódnak. Az adott prioritású folyamatok keresésének megkönnyítése érdekében a listafejeket egy hashtáblázatban tárolja a UNIX. Egy listafejhez négy egymás után következ prioritásértékkel rendelkez folyamat tartozik. A hashtáblás ábrázolást mutatja be a 3.5. ábra.
Megjegyzés: Majd átszámozni

I. UNIX

26

0 1 0

...

0 1 0

a hash tábla megfelel sorainak státuszát jelz bitek

0-3 4-7 KERNEL prioritások ... 44 - 47 48 - 49 50 - 53 USER prioritások 54 - 57 ... 118 - 121 122 - 127
.5. ábra: A folyamatok prioritásának tárolása A fenti megoldás nemcsak azért el nyös, mert csökkenti a hashtábla bejegyzéseinek számát, hanem lehet vé teszi adott prioritású folyamatok létezésének ellen rzését is. A rendszer minden sorhoz hozzárendel egy jelz bitet. A jelz bit értéke mutatja, hogy az adott sorbanlétezik-e futásra kész folyamat. Ezeket a biteket a listába történ beszúrás, illetve lef zés alkalmával frissíti a rendszer. Az ellen rzés gyorsítása azért fontos, mert nagy gyakorisággal (minden óramegszakítás esetén) lefut, tehát ennek a tevékenységnek az ideje a rendszer teljesítményét nagymértékben befolyásolja. A négy prioritási szint egyetlen hashtábla-bejegyzésbe történ összevonása azért el nyös, mert így pontosan 32 jelz bit lesz, amit egy memóriaszóba összevonva egyszer kezelni a 32bites rendszerekben. (A jelz biteket tartalmazó változó neve: whichqs.) I.3.3.6. Példa az ütemezés számolására A következ kben egy konkrét példán keresztül mutatjuk be a prioritás számolását. Legyen a korrekciós tényez értéke ½, és ne változzon az ütemezés alatt. (Ez egyébként több UNIX rendszerben is hasonlóan van.) Tekintsünk el a Round-Robin algoritmus használatától. Válasszuk a nice számot minden folyamatnál 0-nak. Esetünkben tehát az ütemez algoritmus tevékenységei: · minden óramegszakításnál emeli a futó folyamat p_cpu értékét:

PID=26 PID=46 PID=24

PID=23

PID=28

PID=29

PID=16

I. UNIX

27

p_cpu := p_cpu +1
· minden 100-adik óramegszakításnál újraszámolja minden folyamat felhasználói prioritását

a következ két lépésben:
· kiszámítja a minden folyamat CPU használatára jellemz változó, (p_cpu) értékét:

p_cpu = p_cpu * KF = p_cpu * ½
· kiszámítja a felhasználói prioritás értékét:

p_usrpri = P_USER+p_cpu/4+2*p_nice = 50 + p_cpu/4

Minden folyamatnak négy, ütemezésnél használt paraméterét (p_pri, p_usrpri, p_cpu, p_nice) tartja számon a rendszer, azonban esetünkben csak kett (p_pri, p_cpu) érdekes, mivel a
p_nice szám zéró, a p_pri értéke pedig megegyezik a p_usrpri értékével, hiszen csak
Megjegyzés: Majd átszámozni

felhasználói módú futásról van szó. A számításokat a 3.6. ábrán látható táblázatban foglaltuk össze.

I. UNIX

28

A
p_pri p_cpu 0 1 ... 99 100/2 50 p_pri

B
p_cpu p_pri

C
p_cpu Lépés Futó foly.

50 50 ... 50 50+50/4 63 63 ... 63 50+25/4 56 56 ... 56 50+13/4 53

50 50 ... 50 50

0 0 ... 0 0

50 50 ... 50 50

0 0 ... 0 0

1 2 ... 99 100

A A A A A

50 ... 50 50/2 25 25 ... 25 25/2 13

50 .... 50 50+50/4 63 63 .... 63 50+25/4 56

1 ... 99 100/2 50

50 ... 50 50

0 ... 0
0

101 ... 199 200

B B B B

50 ... 50 50/2 25

50 ... 50 50+50/4 63

1 ... 100 100/2 50

201 ... 299 300

C C C C

.6. ábra: Ütemezési példa Láthatjuk, hogy mindegyik folyamat futási lehet séghez jutott a vizsgált periódus alatt. A várakozó folyamatok prioritása a várakozási id növekedésével folyamatosan növekedett, míg el nem érték a lehet legmagasabb prioritási szintet. A futó folyamat prioritása a futási id vel arányosan csökent. Az ütemez így el zi meg a folyamatok éheztetését.
I.3.3.7. A UNIX-ütemezés értékelése

A UNIX ütemezése viszonylag jó rendszerkihasználást és jó átereszt képességet biztosít a felhasználók számára átlagos, vagyis nem széls séges rendszerterhelés esetén. Az utóbbi években azonban a felhasználók igényei megemelkedtek az ütemez vel szemben, nem utolsósorban azért, mert megjelentek a UNIX-nál nagyobb hatékonyságot és több lehet séget

I. UNIX

29

biztosító rendszerek. Az ütemezés értékelésénél így els sorban az algoritmus negatívumait emeljük ki:
· Nem méretezhet megfelel en. Az alkalmazott algoritmus a folyamatok számának

emelkedése esetén nem tud rugalmasan alkalmazkodni, vagyis változni a terhelés növekedésével. A korrekciós faktor használata nem elég hatékony eszköz.
· Az algoritmussal nem lehet meghatározott CPU id t allokálni egy adott folyamat, illetve a

folyamatok egy csoportja számára, vagyis nem lehet a CPU-t adott esetben ,,kiosztani".
· Nem lehet a folyamatok fix válaszidejét garantálni. Bár az algoritmus igyekszik minél

alacsonyabb válaszid t biztosítani, de nagy rendszerterhelés esetén ez limit nélkül megn het, vagyis nem lehet garantált válaszid r l beszélni. Emiatt a UNIX ütemezést nem lehet valósidej (real-time) rendszerben alkalmazni. Ezt a hiányosságotszámos rendszerben (SVR4, Digital UNIX, stb.) megpróbálták kiküszöbölni.
· Az el z hiányossággal rokon probléma, de érdemes külön is kiemelni, hogy ha egy kernel

rutin sokáig fut, az feltartja az egész rendszert, mivel a kernel nem preemptív.
· A felhasználó a folyamatainak prioritását nem tudja megfelel módon befolyásolni. A

gyakorlatban a nice szám nem elég hatásos eszköz erre a célra.
I.3.3.8. Call-out

A call-out mechanizmus arra szolgál, hogy egy adott tevékenységet (függvényt) a kernel egy kés bbi id pontban hajtson végre (hívjon meg). A call-out függvények adott id ben történ meghívását a timeout rendszerhívással lehet megadni, illetve az untimeout rendszerhívással lehet törölni. Fontos megjegyezni, hogy a call-out függvények rendszerkörnyezetben futnak, így nem aludhatnak, illetve nem érhetik el a folyamatok környezetét. A call-out függvények periodikusan ismétl d végrehajtására használhatók pl.: hálózati csomagok ismételt elküldésére, ütemezési és memóriakezel függvények hívására, készülékek monitorozására (nehogy megszakítások maszkolása miatt elvesszünk bemeneti adatokat), olyan készülékek lekérdezésére, amelyek nem megszakításkéréssel m ködnek. feladatok (tipikusan kernel funkciók)

I. UNIX

30

A call-out-ok meghívását az óramegszakítás végzi, azonban mivel a call-out függvények kernel rutinok, futásuk alatt az megszakítások fogadása nem lehet letiltva, hiszen ekkor hosszú ideig nem fogadná a rendszer az óramegszakításnál alacsonyabb prioritású megszakításokat. Emiatt a megszakításkezel nem közvetlenül hívja meg a call-out

függvényeket, hanem csak ellen rzi, hogy elérkezett-e az ideje valamelyik call-out függvény meghívásának. Ha igen, beállít egy erre a célra rendszeresített jelz bitet. A kernel ezt a jelz bitet minden esetben ellen rzi, amikor a megszakítások befejezése után visszatér a megszakított tevékenységéhez, vagyis feloldaná a legkisebb prioritású megszakítás tiltását. Így biztosított, hogy a kernel a call-out-okat a lehet leghamarabb, de az összes megszakítás kiszolgálása után meghívja. A
call-out

függvények

meghívásának

adminisztrálására

a

rendszer

különböz

adatszerkezeteket használhat. Mindegyik adatszerkezet dinamikus, hiszen a call-out függvények száma futás közben változik, és nem lehet tudni, hány call-out függvény lesz egy adott rendszerben. Az adatszerkezetek megválasztásakor ismét az óramegszakításkor végrehajtandó m veletek gyorsítása a cél. Két megoldást ismertetünk: a láncolt listás és az id kerekes
call-out listakezelést.

Call-out függvények láncolt listás ábrázolása Ebben az esetben a call-out függvények listája egy rendezett lista, amely a call-out függvényeket ,,tüzelési sorrendben" (meghívási sorrendben) tartalmazza. Az id t a rendszer óramegszakításokban számolja. Ezt az id egységet hívjuk tikknek. A listaelemekben a láncolt listás tárolás esetén relatív id pontok vannak tárolva. A rendszer az egyes függvények meghívásának idejét az el z elem tüzelési idejéhez képest relatív számként tárolja, vagyis a rendszernek a lista el z eleméhez képest az adott listaelemben tárolt számú tikkel kés bb kell aktiválni a listaelemben megnevezett függvényt. A kernel minden egyes óramegszakítás esetén eggyel csökkenti az els listaelem id pontszámlálóját, és amikor az eléri a 0-át, akkor aktivizálja az els listaelemben tárolt függvényt, illetve mögötte az összes 0 id t tartalmazó elemet. A megoldás el nye az egyszer kezelhet ség, viszont hátránya, hogy a lista igen hosszú lehet, ami id igényessé teheti a lista kezelését, pl. a listába való beszúrást (3.6. ábra).
Megjegyzés: Majd átszámozni

I. UNIX

31

relatív id az el z elemhez viszonyítva

meghívandó függvény

Lista fej

5, shedule()

0, checkIT()

15, memoc()

.7. ábra: Call-out függvények láncolt listás ábrázolása

Call-out függvények tárolása id kerékkel
Az id kerekes ábrázolás esetén a rendszer lényegében felszabdalja a listát nagyjából egyenl részlistákra. A listaelemekben az abszolút meghívási id van tárolva tikkekben mérve. A függvények meghívási ideje alapján egy hashtáblát készít a rendszer. Ha mondjuk egy 10elem hashtábla van használatban, akkor az els listában azok a call-out függvények lesznek, amelyek meghívási ideje 10-zel osztva 1-et ad maradékul. Így átlagosan egy lista hossza az el z tárolási móddal összevetve a tizedére csökken. Az egyes listák rendezettek, az els ként meghívandó függvény áll a lista els helyén. Az id kerekes ábrázolást láthatjuk a 3.7. ábrán.
Megjegyzés: Majd átszámozni

0 1 2 3 4 5 6 7 8 9

11, fv4

101, fv5

111, fv2

14, fv5

704, fv9

904, fv1

28, fv11

28, fv11

888, fv4

.8. ábra: Call-out függvények id kerekes ábrázolása Az id kerék kezelése a következ módon történik: A rendszer megvizsgálja, hogy melyik részlistában tárolódnak az adott id pillanathoz tartozó call-out függvények. (Megnézi, 10-zel osztva mennyi maradékot ad az aktuális óra tikk-sorszáma.) Összehasonlítja az els listaelem tüzelési idejét az aktuális id vel. Ha a két érték megegyezik, meghívja a hozzátartozó rutint, majd a lista esetleges további, azonos tüzelési idej függvényeit. Ha a tüzelési id nagyobb,

I. UNIX

32

nem tesz semmit. A nevét a módszer onnan kapta, hogy a hashtáblán a rendszer ellen rzéskor körbe-körbe jár.

I.3.4. Szinkronizáció
A szinkronizáció (syncronization) egy folyamat végrehajtásának olyan id beli korlátozása, ahol ez egy másik folyamat futásától, esetleg egy küls esemény bekövetkezését l függ. Alapeseteit a korábbiakban tárgyaltuk. A UNIX operációs rendszer alatt a szinkronizáció legegyszer bb eszközei a jelzések (signals).

I.3.4.1. UNIX jelzések
A jelzések els dleges célja a UNIX rendszerekben az, hogy a folyamatok különböz (rendszer- vagy alkalmazásszint ) események bekövetkezésér l értesüljenek. A jelzések részletes m ködése és rendszerszint megvalósítása az egyes UNIX változatokban lényeges eltéréseket mutat. Az eredeti System V jelzés implementáció alapvet en megbízhatatlan és hibás volt. A BSD UNIX variációk ezért egy robosztusabb, megbízhatóbb

jelzésmechanizmust dolgoztak ki, amely azonban nem kompatibilis a System V jelzésekkel. Ezt a problémát a POSIX.1 szabvány (IEEE 90) próbálta meg feloldani egy szabványos interfész definiálásával. A System V Release 4 (SVR4) UNIX variáns már ennek megfelel en, a BSD jelzések bizonyos tulajdonságait is ötvözve tartalmazza a jelzés kezelést. A mai modern UNIX rendszerek (Solaris, AIX, HP-UX, Digital UNIX, stb.) a POSIX.1 szabványnak megfelel jelzéskezel rendszert tartalmaznak. A UNIX jelzések arra kínálnak módot, hogy események egy meghatározott halmazának bekövetkezése esetén a futó folyamat egy eljárása meghívásra kerüljön. Az eseményeket egész számokkal reprezentálják a rendszerek, és szimbolikus konstansokkal hivatkoznak rájuk. Az eredeti System V megvalósítás 15 jelzést tartalmazott, a mai rendszerek általában 31 jelzéssel dolgoznak.

I. UNIX

33

Az alábbi táblázat néhány tipikus jelzést ismertet.

A jelzés SIGABRT SIGTERM SIGSEGV SIGALRM SIGBUS SIGPIPE

Leírása A folyamat megszakítása A folyamat leállítása Szegmentációs hiba Valósidej óra riasztás Busz hiba Olvasó nélküli cs vezetékbe írás

A jelzésrendszerben két lépés különíthet következ kben ezeket a lépéseket ismertetjük.

el: a jelzések keletkezése és kezelése. A

I.3.4.2. Jelzések keltése
Sokféle esemény válthat ki jelzéseket a futó folyamat környezetében: a futó folyamat maga, más folyamatok, az operációs rendszer, küls események, megszakítások. A jelzések forrásai a következ f bb kategóriákba csoportosíthatóak. Kivételek (exception) A kivételek (például illegális utasítás végrehajtásának kísérlete) bekövetkezése esetén a kernel értesíti a folyamatot egy jelzés elküldésével. Más folyamatok Egy folyamat jelzést küldhet egy más folyamat, vagy folyamatok csoportja számára az erre szolgáló rendszerhívások (kill() illetve sigsend()) segítségével. A folyamat önmaga számára is küldhet jelzést. Terminál megszakítások A terminál bizonyos karaktereinek (mint pl. a CTRL+C) leütése a terminálhoz csatlakozó, el térben futó folyamatok számára jelzést generál. Munkamenet kezelés (job control) Az ilyen képességgel rendelkez parancsértelmez k (shellek) az el térben, illetve háttérben futó folyamatokat jelzések segítségével manipulálják, illetve a kernel egy folyamat megsz nése esetén ilyen jelzéssel értesíti a szül folyamatát.

I. UNIX

34

Kvóta jelzések Amikor egy folyamat eléri a számára rendelkezésre bocsátott CPU-használat vagy fájlméret határait, a kernel jelzést küld számára. Értesítések Egy folyamat bizonyos események (pl. egy periféria készen áll az adatátvitelre) bekövetkezésér l értesítést kérhet a kernelt l. Riasztások Egy folyamat beállíthat riasztást egy adott id hosszra, amely letelte után, a kernel jelzést küld a folyamat számára.

I.3.4.3. Jelzések kezelése
Egy folyamat számára a hozzá beérkez jelzések aszinkron események, azaz futása során bármikor beérkezhetnek. A jelzés létrejötte után a második fázis a folyamatok értesítése és a jelzések kezelése. A jelzés akkor számít kézbesítettnek, ha az a folyamat, amelynek a jelzés szól, tudomásul veszi a megérkezését, és normális futását megszakítva valamilyen meghatározott akciót hajt végre. Minden jelzéshez tartozik egy alapértelmezett akció (default action), amit a kernel hajt végre, amennyiben a folyamat nem határozott meg más akciót. Öt lehetséges alapértelmezett akció létezik: Megszakítás (abortálás) A folyamat megszakítását eredményezi egy futási lenyomat (core dump) generálása után. A lenyomat egy core nev fájlban keletkezik a folyamat aktuális könyvtárában. Tartalmazza a folyamathoz tartozó tárterület tartalmát (memóriakép) és a processzor regisztereinek pillanatnyi értékét (regiszterkép). Ez a lenyomat felhasználható a kés bbiekben a megszakítási helyzet analízisére. Kilépés A program leállítása core fájl generálása nélkül. Figyelmen kívül hagyás (ignore) A jelzést figyelmen kívül hagyja a kernel (folyamat). Felfüggesztés A folyamat felfüggeszt dik Folytatás A folyamat folytatódik, ha fel volt függesztve, egyébként figyelmen kívül hagyja a jelzést.

I. UNIX

35

A következ táblázat a korábbiban felsorolt jelzésekre adja meg az alapértelmezett akciókat.

I. UNIX

36

A jelzés SIGABRT SIGTERM SIGSEGV SIGALRM SIGBUS SIGPIPE

Leírása A folyamat megszakítása A folyamat leállítása Szegmentációs hiba Valósidej óra riasztás Busz hiba Olvasó nélküli cs vezetékbe írás

Alapértelmezett akció megszakítás kilépés megszakítás kilépés megszakítás kilépés

7.3.4.1. ábra: Tipikus UNIX jelzések és értelmezésük A folyamatok futásuk során bármikor felülírhatják ezeket az alapértelmezett akciókat a jelzések többségére. Az így meghatározott akció lehet a jelzés figyelmen kívül hagyása, vagy egy, a folyamat által meghatározott, ún. jelzéskezel (handler) eljárás meghívása. A

folyamat bármikor visszaállíthatja a jelzéshez tartozó alapértelmezett akciót is. Bizonyos jelzések esetében, mint például a SIGKILL vagy a SIGSTOP az alapértelmezett akciók felülírása nem lehetséges. Fontos megjegyezni, hogy a jelzésekhez tartozó akciók a címzett folyamat környezetében hajtódnak végre, azaz csak akkor, ha a hozzájuk tartozó folyamatok futó állapotba kerülnek. Bizonyos esetekben ez lényeges késleltetést okozhat a jelzések kezelésében. A jelzést fogadó folyamat tudomására akkor jut egy jelzés érkezése, ha a kernel meghívja az erre a célra szolgáló issig() rendszerhívást. Ez a következ esetekben fordul el : visszatéréskor felhasználói futási szintre egy rendszerhívásból vagy megszakításból, egy megszakítható eseményre történ várakozás el tt, és közvetlenül egy nem megszakítható eseményre történ várakozás után. Látható, hogy a jelzések kezelése szempontjából a folyamat várakozó (alvó) állapotai közül a nem megszakítható eseményre várakozás különleges jelent séggel bír. Az ilyen típusú várakozás esetén a kernel a jelzést várakozó állapotban tartja mindaddig, míg a folyamat vissza nem tér (fel nem ébred) ebb l az állapotából. Megszakítható várakozások (mint például a terminál bevitelre történ várakozás) esetén a kernel a jelzése beérkezésének hatására a folyamatot felébreszti. Ha az issig() hívás IGAZ értékkel tér vissza, a kernel a psig() hívás segítségével kezeli a jelzést. A psig() vagy végrehajtja a kernel által meghatározott alapértelmezett akciót, vagy a sendsig() hívás segítségével meghívja a folyamat kezel függvényét. A kezel függvény
Megjegyzés: Ez így igaz?

I. UNIX

37

meghívása el tt a folyamat kilép a kernel futási módból. A psig() a verem és a folyamat kontextusának manipulálásával arról is gondoskodik, hogy a folyamat a jelzés kezelése után normálisan folytatható legyen.

I.3.4.4. Megbízhatatlan jelzések
Az eredeti Sytem V jelzésrendszer több hibát is tartalmaz, ezért megbízhatatlan jelz vel illetik. Egyik tipikus problémája, hogy a kernel a jelzés kezelésekor minden alkalommal visszaállítja az alapértelmezett akciót, így a folyamat jelzéskezel eljárásának gondoskodnia kell az egyedi kezelés ismételt beállításáról. Ez versenyhelyzetet teremt a jelzések keletkezése és az egyedi akciók beállítása között, ami egy-egy jelzés esetében könnyen az alapértelmezett akció végrehajtását eredményezheti. Egy másik tipikus probléma a jelzéseket leíró tábla elhelyezéséb l adódik. A táblát a kernel ugyanis a folyamathoz kötött u területen tárolja, amihez csak az aktuális folyamatnál fér hozzá. Ily módon egy nem megszakítható várakozásban lév folyamat esetén a kernel nem tudja eldönteni, hogy a folyamat maga kezeli-e a jelzést, vagy az alapértelmezett akciót kell végrehajtania. Ez csak a folyamat felébresztése után derülhet ki. Végezetül hiányzott a jelzések kézbesítésének átmeneti blokkolása, illetve az olyan munkamenetek kezelése, ahol folyamatok csoportosan kezelhet ek a terminál-hozzáférés során.

I.3.4.5. Megbízható jelzések
Az el bbi problémákra a BSD 4.2-es verziója egy új jelzésrendszer bevezetésével hozott megoldást, illetve az AT&T SVR3 verziójában található megbízható jelzések is ebben az irányban változtak. A két megoldás ugyanakkor nem volt kompatibilis, mindkett más és más rendszerhívások bevezetésével orvosolta a problémákat. A POSIX.1 szabvány teremtett rendet egy egységes interfész bevezetésével, melynek implementációs részleteit nem rögzítették, így mindkét UNIX-variáns beépíthette. Az SVR4 UNIX egy új, POSIX.1-nek megfelel korábbi BSD és SVR3 verziókkal is. A megbízható jelzéskezel nyújtja: rendszerek mindegyike a következ közös szolgáltatásokat rendszert tartalmazott, amely kompatibilis volt a

I. UNIX

38

Perzistens kezel k (persistent handlers) A jelzéskezel eljárás végrehajtásának beállítása a jelzés kezelése után is megmarad, így nincs szükség újbóli beállítására. Maszkolás (masking) Egy jelzés átmenetileg maszkolható, avagy blokkolható. Az ilyen jelzések keletkezését a kernel megjegyzi, de nem értesíti a hozzájuk rendelt folyamatokat. Ez lehet vé teszi a folyamatok kritikus részeinek védelmét a jelzések megszakításaival szemben. Alvó folyamatok (sleeping processes) A folyamatokhoz tartozó jelzéseket leíró információk egy része akkor is látható a kernel számára, ha a folyamat éppen nem fut (az u terület helyett a proc területen tárolódik), ily módon a kernel a folyamat felébresztése nélkül ellen rizheti, hogy az megadott-e egyedi akciót, vagy az alapértelmezett jelzéskezel akciót kell végrehajtani. Felszabadítás és várakozás (unblock and wait) A megbízható jelzések mechanizmusa egy speciális rendszerhívás (sigpause()) segítségével képes megoldani azt, hogy egy folyamat felszabadítsa a blokkolt jelzést, majd azonnal várakozó állapotba kerüljön a jelzés megérkezéséig.

I.3.4.6. Az SVR3 implementáció
Az AT&T által kidolgozott implementáció minden lényeges tulajdonsággal rendelkezett a megbízható jelzéskezelés kidolgozásához, azonban megvalósításának voltak sajátos hátrányai. Legfontosabb hiányossága, hogy egyszerre nem képes több jelzést blokkolni, így nehéz több jelzést is kezel kritikus régiók megírása (ahol a folyamatot nem szakíthatják félbe jelzések). Az SVR3-ból hiányzott a munkafolyamat kezelés is. Mindezeket a hiányosságokat a 4BSD rendszere pótolta.

I.3.4.7. BSD jelzésmenedzsment
A 4.2BSD volt az els megbízható jelzésrendszerrel ellátott UNIX-variáns. A

rendszerhívások többsége tartalmaz egy jelzésmaszk paramétert, így egy hívás egyszerre több jelzésen is végrehajthat egy m velet. A jelzéseket blokkoló sigsetmask() függvényhívásnak egyszerre több jelzést is megadhatunk. A jelzések kezelésére szolgáló eljárásokhoz megadásukkor jelzésmaszkot rendelhetünk, így végrehajtásukkor a kernel gondoskodik a maszkolt jelzések helyes és automatikus

I. UNIX

39

beállításáról. Ily módon egy jelzés második példányát a rendszer nem fogja kezelni addig, míg az els kezelését be nem fejezte. A BSD implementáció további újdonsága, hogy a jelzéseket különálló vermet használva is kezelheti a folyamat. Így lehet vé válik például a verem túlcsordulását jelz jelzés kezelése is. Ez az implementáció további jelzéseket is bevezetett, els sorban a munkafolyamat-kezelés területén. A munkafolyamat összefügg folyamatok olyan csoportja, amelyek általában egy cs vezetéket formálva helyezkednek el (standard be- illetve kimeneteiket összekötve). Egy terminálhoz tartozó több folyamat esetén csak egy rendelkezhet a terminál írásának és olvasásának jogával (el térben futó folyamat), a többiek a háttérben futnak. A háttérben futó folyamatok jelzéseket kapnak, amikor megpróbálják elérni a terminált, és általában felfüggeszt dnek. A felhasználó parancsértelmez je jelzések küldésével képes a folyamatokat el térbe vagy háttérbe helyezni, felfüggeszteni és továbbindítani a futásukat. Végezetül a 4BSD UNIX képes a jelzések által félbeszakított, hosszú ideig futó rendszerhívások automatikus újrahívására. Ilyen rendszerhívások lehetnek a karakteres eszközök írás és olvasás m veletei, a hálózati kapcsolatokat és cs vezetékeket kezel m veletek és a várakozás jelleg ek (pl. wait(), waitpid(), és ioctl()). Amikor egy ilyen hívást félbeszakít egy jelzés, a jelzés lekezelését követ en a rendszerhívás automatikusan újra meghívódik (e nélkül EINTR hibával térne vissza). A BSD jelzésinterfész hatékony és flexibilis. Legfontosabb hátránya, hogy nem kompatibilis az eredeti AT&T interfésszel. Ez azt eredményezte, hogy a szoftvergyártók maguk kezdtek olyan közös interfészeket kifejleszteni, amelyek mindkét (BSD, SysV) UNIX-variánssal használhatóak. Ezt a problémát oldotta meg az egységes POSIX.1 jelzésinterfész, amelyet az SVR4 (System V Release 4) vezetett be.

I.3.4.8. Az SVR4 jelzések
A UNIX Systems Laboratories UNIX SVR4.2 Operációs rendszer API Interfésze által bevezetett jelzéskezel rendszerhívások a BSD és korábbi SVR3 variánsok és a nem

megbízható jelzések teljes halmazát lefedik. A régi signal(), sigset(), sighold(), sigelse(), sigignore(), és sigpause() rendszerhívások mellett új, a BSD javított jelzéskezelését megvalósító rendszerhívásokat vezettek be. A jelzésekkel kapcsolatos állapotinformációk kezelését a BSD megoldásnál látható módon oldották meg, kisebb változó- és függvénynév módosításokkal.

I. UNIX

40

A kernel a folyamatok felébresztése nélkül képes ellen rizni, hogy azok foglalkoznak-e a jelzéssel. Ha igen, akkor egy bitsorozat (p_cursig) megfelel elemét bebillentve a kernel jelzi a folyamat számára a jelzés megérkezését. (Ily módon egy jelzésb l egyszerre maximum egy kezeletlen lehet.) Ha a folyamat megszakítható várakozásban van és a jelzés nem blokkolt, akkor a kernel felébreszti a folyamatot. A folyamat a BSD megoldásnál megismert issig() rendszerhívással ellen rzi a jelzések meglétét (a p_cursig bitjeinek tesztjével). A kernel itt is a psig() rendszerhívással kezdeményezi a jelzések kezelését.

I.3.4.9. Kivételkezelés
Kivételen azt értjük, amikor egy program egy nem megszokott szituációval, tipikusan valamilyen hibával találja magát szemben. Ezek valamilyen hardver eszköz (többnyire a processzor) által generált megszakítások, mint például a hibás címzés, nullával való osztás stb. Ez általában hibamegszakítást okoz, amelynek kiszolgálásakor a kernel jelzések segítségével értesíti a programot a bekövetkezett kivételr l. A jelzés típusa a kivétel természetét l függ. Például egy hibás címzés SIGSEGV (szegmentációs hiba) jelzést eredményez. Amennyiben a folyamat meghatározott egy kezel függvényt a jelzéshez, úgy a kernel azt hívja meg. (Ezt a mechanizmust használják a nyomkövet k is a program futásának befolyásolására). A UNIX kivételkezelésnek ­ többek között ­ két nagy hátránya van: a kivételkezelés a kivétellel megegyez kontextusban fut; a kernel ugyan átadja a kivétel bekövetkezésekor aktuális kontextus bizonyos részét a kivételkezel nek, de ennek pontos tartalma UNIX-implementációnként változhat. a jelzéseket alapvet en egyszálú folyamatok számára találták ki; többszálú végrehajtást is támogató UNIX-variánsok (pl. Solaris 7) csak körülményesen alkalmazhatják a jelzéseket.
Megjegyzés: Ez a rész kicsit nehezen emészthet . Kicsit könnyedebbé kellene tenni a fogalmazását, esetleg példán megmutatni, mi az értelme a viszony-nak. Megjegyzés: Ez a szekció? Megjegyzés: Ez-e a baj, vagy az, hogy nem tudni, hogy a hiányosan átadott kontextus miatt ez mennyire teljesül?

I.3.4.10. Folyamatcsoportok és terminálkezelés
A UNIX a korábban említett folyamatcsoportokat használja a terminál hozzáférés és a felhasználói viszony kezelésére. (Felhasználói viszonyon azt értjük, amikor a felhasználó interaktív kapcsolatot létesít az operációs rendszerrel.) Minden folyamathoz tartozik egy folyamatcsoport azonosító (process group ID), melyet a kernel a folyamatok teljes csoportjára vonatkozó akciók végrehajtásában használ fel. A csoportoknak lehet egy

I. UNIX

41

csoportvezet je, melynek processzazonosítója (PID) megegyezik a folyamatcsoport azonosítóval. Normális esetben a folyamatok szül jükt l öröklik csoportazonosítójukat. Az egy csoportba tartozó folyamatokhoz egy vezérl terminál tartozik, általában a felhasználó belépésének terminálja, ahonnan a folyamatokat elindította. Ehhez a terminálhoz egy speciális eszköz, a /dev/tty rendel dik (az eszköz neve kiegészülhet a terminált azonosító jellel, pl. /dev/tty01). A munkamenet-kezelés az a mechanizmus, mely egy folyamatcsoport futását

felfüggesztheti, vagy továbbengedheti, és meghatározza a csoport kapcsolatát a terminálhoz. Munkamenet-kezelésre alkalmas shellek, mint például a csh vagy ksh speciális vezérl karaktereket (pl. CTRL+Z) és parancsokat (pl. fg és bg) használnak ezen szolgáltatások elérésére. A kezdeti System V implementációk a folyamatcsoportokat általában a felhasználókhoz kötött folyamatok reprezentálására használták, és nem tartalmaztak munkamenet-kezelést. A 4BSD minden parancssorhoz új folyamatcsoportot vezetett be, így megjelent a munkamenet fogalma. Az SVR4 vezette be az egységes, felhasználói belépési viszonyon és munkameneten alapuló folyamatcsoport-kezelést. Az SVR4 (illetve a 4.4BSD) egy új viszony objektum (session object) bevezetésével írja le a felhasználói kapcsolatot a folyamatokhoz. A folyamatok egyaránt tartozhatnak viszonyhoz és folyamatcsoporthoz. A viszonyok leírására egy új azonosítót (SID ­ session id) használ a rendszer. A viszony objektum a felhasználóhoz és a vezérl terminálhoz rögzített. A viszony kapcsolatban lev folyamatok vezet je (session leader) jogosult egyedül a vezérl terminál lefoglalására, vagy felszabadítására. Amikor a felhasználó belép a rendszerbe, a termináljához rendelt els folyamat a setsid() rendszerhívás segítségével létrehoz egy új viszony csoportot, mely egyben folyamatcsoport is lesz. A felhasználó által elindított további folyamatok ehhez a viszony csoporthoz fognak tartozni, viszont újabb, az els t l független folyamatcsoportot is alakíthatnak. Így egyetlen belépéshez több folyamatcsoport is tartozhat. Ezen csoportok egyike az el térben futó csoport (foreground group), amely kizárólagos hozzáféréssel rendelkezik a terminálhoz. Amennyiben a háttérben futó folyamatok hozzá akarnak férni a terminálhoz, egy speciális jelzés értesíti ket arról, hogy ezt nem tehetik meg, mivel a háttérben futnak.
Megjegyzés: Ez a fogalom így igen nehezen ehet (már az el bb is az volt). Vagy ki kellene találni rá valami, vagy magyarázni kellene.

I. UNIX

42

A viszony csoporton belül a folyamatok megváltoztathatják aktuális folyamatcsoportjukat, de más viszonyhoz tartozó folyamatcsoportba nem léphetnek át. Erre csak egy mód van: a folyamat maga alapít egy új viszony csoportot, teljesen szakítva az el z vel.

I.3.5. Folyamatok közötti kommunikáció (interprocess communication)

Bizonyos programozási környezetekben gyakran együttm köd használhatjuk egymással összefügg

folyamatok csoportját

feladatok megoldására. A folyamatok között

információáramlásra van szükség. Az információcsere alapvet en két módon valósulhat meg: közösen használt tárterületen, vagy kommunikációs csatornán keresztül. Ebben a fejezetben azzal foglalkozunk részletesebben, hogy a UNIX rendszer milyen eszközöket nyújt a második eset, azaz a folyamatok üzenetváltásos együttm ködésének megszervezéséhez. A UNIX operációs rendszer többféle IPC mechanizmust kínál. Ezek a következ k: jelzések (signals) cs vezetékek (pipes) és folyamat-nyomkövetés (process tracing). Bizonyos UNIXvariánsok ezen kívül rendelkeznek az osztott memória (shared memory), szemaforok (semaphores) és üzenet-sorok (message queues) lehet ségeivel is. A következ kben röviden áttekintjük ezen eszközöket.

I.3.5.1. Jelzések
A jelzések els dleges célja a folyamatok értesítése aszinkron módon bekövetkez eseményekr l. Bár eredetileg hibák jelzésére szolgáltak, egyszer folyamatok közötti

kommunikációt is lehet vé tesznek. A modern UNIX rendszerek 31 jelzést alkalmaznak, melyek közül kett , a SIGUSR1 és SIGUSR2 az alkalmazások számára fenntartott. Egy folyamat jelzést küldhet egy vagy több másik számára rendszerhívások (kill()) segítségével. A jelzésekkel részletesebben a VI.3.4. fejezetben foglalkozunk.
Megjegyzés: Számozás

I.3.5.2. Cs vezetékek
A cs vezeték (pipe) tradicionálisan egy egyirányú, FIFO jelleg , nem strukturált, változó méret adatokat közvetít adatfolyam. A cs vezeték írói adatokat helyeznek a cs be, olvasói

I. UNIX

43

kiolvassák azokat. A kiolvasott adatok elt nnek a cs b l. Egy üres cs b l olvasni kívánó folyamat megáll addig, míg adat nem érkezik a cs be. Hasonlóképpen, egy tele cs be írni akaró folyamat is megáll, amíg a cs b l egy adat nem távozik. A pipe() rendszerhívással hozható létre egy cs . A rendszerhívás két fájl-leíróval tér vissza, a cs vezeték írására és olvasására való leírókkal. A leírókat felhasználva a cs vezetéket a fájlkezelésben használható read() és write() rendszerhívásokkal olvashatjuk, illetve írhatjuk. Ezeket a leírókat a folyamatból létrejött gyermekek öröklik, megosztva ezzel a fájl használatát. Ily módon egy cs vezetéknek több írója és olvasója lehet. Egy adott folyamat önmaga is lehet egyszerre író és olvasó is. A cs vezetéket azonban általában két folyamat közötti egyirányú kommunikációra használják, amikor pontosan egy írója és egy olvasója van. Ilyen cs vezetéket a felhasználók a parancsértelmez ben is létrehozhatnak a cs vezeték jel ( `|' ) segítségével. A jel bal oldalán szerepl folyamat a cs írója, a jobb oldali pedig az olvasója lesz. A parancsértelmez gondoskodik a cs vezeték létrehozásáról a folyamatok indítása során. A cs vezetékek legfontosabb hátrányai a következ k: mivel nincs rögzített adatméret és ­struktúra, a vev nek nincs tudomása arról, hogy hol vannak az adatok határai, amennyiben több olvasó is van, úgy az író nem tudja kiválasztani, hogy melyik olvasónak küldi az üzenetet, és mivel az olvasás kiveszi az adatot a cs vezetékb l, nincs lehet ség több címzetthez is eljuttatni az adatot. A System V rendszerekben létezik egy speciális cs vezeték, az elnevezett cs vezeték (named pipe). Ez létrehozási módjában és használatában is különbözik az eddig megismertekt l, bár lényegében ugyanazt a célt szolgálja. A felhasználó a fájlrendszerben létrehoz egy FIFO elv speciális fájlt egy speciális parancs segítségével (mknod). A FIFO-t a folyamatok a fájlokhoz hasonlóan nyithatják meg és használhatják. Viselkedését tekintve az elnevezett cs vezeték nem különbözik a korábban megismert, névtelen cs vezetékt l. Lényeges különbség, hogy a FIFO a folyamatoktól függetlenül létezik, az írók és olvasók megsz nésével nem törl dik. Ez a megoldás több el nyt is jelent a korábbi cs vezetékekkel szemben: a FIFO-kat egymástól független folyamatok is használhatják (csak a nevet kell ismerniük), az adat megmarad még akkor is, ha az összes hozzáfér folyamat megsz nik. Hátrány azonban, hogy kevésbé biztonságosak (csak a fájlrendszerben alkalmazott biztonsági

I. UNIX

44

mechanizmusok vonatkoznak rájuk), valamint könnyen el fordulhat, hogy senki sem törli ket, és feleslegesen foglalnak er forrásokat. A névtelen cs vezetékeket egyszer bb létrehozni és kevesebb er forrást kötnek le. Az SVR4 kétirányú cs vezetéket is implementál. A pipe() rendszerhívás itt is két leíróval tér vissza, azonban mindkett használható írásra és olvasásra is. Valójában két független

cs vezeték keletkezik (fd[2]), melyeknél a kernel oldja meg a leírók egymáshoz rendelését. Mindkét cs vezetékhez egy-egy leírót rendel a kernel, így megvalósítva a kétirányú adatforgalmat. Az fd[0]-ba írt adat az fd[1]-b l olvasható ki, míg az fd[1]-be írt adat az fd[0]ból olvasható. A kétirányú cs vezeték hasznos eszköz, mivel az alkalmazások többségénél kétirányú adatforgalmat szeretnénk kiépíteni.

I.3.5.3. Folyamat-nyomkövetés
Ezt a lehet séget els sorban a nyomkövet programok használják. A ptrace() rendszerhívás segítségével egy folyamat befolyásolhatja a gyermeke futását. A következ f bb feladatok oldhatóak meg a rendszerhívás segítségével: adat olvasása és írása a gyermek címtartományában, adat olvasása és írása a gyermek u területén, a gyermek folyamat általános célú regisztereinek írása és olvasása, adott jelzések ,,elkapása", aminek során a kernel a gyermeket felfüggeszti és értesíti a szül t a jelzésr l, megfigyelési pontok (watchpoints) beállítása és törlése a gyermek címtartományában, a leállított gyermek folyamat futásának folytatása, a gyermek futásának folytatása egy utasítás végrehajtására, a gyermek futásának leállítása, valamint a gyermek engedélyezheti a szül számára a nyomkövetést. A nyomkövet tipikusan gyermek folyamataként hozza létre a követend programot, amely a ptrace() rendszerhívás segítségével engedélyezi a nyomkövetést. A szül ezek után a wait() rendszerhívással várakozik a gyermekkel kapcsolatos eseményekre. A hívás visszatérési értéke ad információt arra nézve, hogy aktuálisan milyen esemény következett be. Ezek után a szül a ptrace() rendszerhívással befolyásolja a gyermeket, majd ismét várakozni kezd. Bár a ptrace() alapvet en lehet vé tette nyomkövet programok létrehozását, rendelkezik fontos korlátokkal és hátrányokkal:

I. UNIX

45

A nyomkövet kizárólag a közvetlen gyermekeit tudja nyomon követni, az általuk létrehozott gyermekeket már nem. A rendszer nem hatékony, rengeteg környezetváltást igényel. A ptrace() hívással kiadott utasítások ugyanis nem közvetlenül érik el a gyermeket, hanem a kernel segítségével egy környezetváltás után. A nyomkövet már futó folyamatokat nem követhet, mivel a gyermeknek el bb

engedélyeznie kell a nyomkövetést. setuid jelzéssel ellátott programok nyomkövetése általában tiltott, mivel súlyos biztonsági problémákat vetne fel (a címterület módosításával a program m ködése lényegesen befolyásolható, pl. ha a gyermek egy másik folyamatot indít, a nyomkövet megváltoztathatja a program nevét). A mai modern UNIX rendszerek új módszereket kínálnak a nyomkövetés megoldására a /proc fájlrendszeren keresztül. Ez a rendszer a felsorolt hiányosságok nagy részét megoldja, így a korszer nyomkövet programok a ptrace() interfész helyett ezt használják.

I.3.5.4. System V IPC
A következ kommunikációs eszközöket (szemaforok, üzenetsorok, osztott memória)

összefoglaló néven csak System V IPC-ként szokás említeni. Eredetileg a SYSV UNIX variánsokban tranzakció-feldolgozásra kifejlesztett eszközök mára részeivé váltak minden korszer UNIX rendszernek. Ezen eszközök (IPC er források) használata és programozói interfésze lényeges közös elemeket tartalmaz. Minden IPC er forrás rendelkezik a következ azonosítókkal: kulcs (key) ­ a felhasználó által meghatározott egész szám, mely az er forrás egy példányát azonosítja, létrehozó (creator) ­ az er forrás létrehozójának felhasználói és csoport azonosítói (UID, GID), tulajdonos (owner) ­ az er forrás tulajdonosának felhasználói és csoport azonosítói (UID, GID), hozzáférési jogok (permissions) ­ a fájlrendszerhez hasonlatos olvasási/írási/végrehajtási jogok a tulajdonos, csoportja és mások számára. Minden er forrásnak van létrehozó (shmget(), semget(), msgget()) és vezérl rendszerhívása (shmctl(), semctl(), msgctl()). A létrehozáskor a kulcs megadása mellett a létrehozási opciókat, illetve egyéb, az adott er forrásra jellemz paramétereket adhatunk meg. A létrehozó

I. UNIX

46

függvények az er forrás elérésére alkalmas leírót adnak vissza (shmid, semid és msgid). A vezérl függvényeknek átadott parancsok segítségével befolyásolhatjuk az er forrás

m ködését. Ezek egyike a megszüntet parancs (IPC_RMID) is. A megszüntetés nélkül a kernel folyamatosan fenntartja az er forrásokat, még akkor is, ha minden kezel folyamatuk megsz nt. Ennek megvalósítása érdekében a kernel egy elkülönített, a folyamatoktól független területen tartja fent az er forrásokat és a kezelésükhöz szükséges adminisztrációs táblákat. Ez a terület korlátos méret , általában kernel-paraméterként méretezhet . Bizonyos alkalmazások (pl. adatbázis kezel k) megkövetelhetik az operációs rendszer alapértelmezett területméretének növelését.

I.3.5.5. Szemaforok
A SYSV IPC szemaforok az általános szemafor mechanizmusát és operációit (P() és V()) valósítják meg. A megvalósítás némiképp bonyolultabb, körültekint bb használatot igényel, de összetettebb megoldások is kialakíthatóak segítségével. A szemaforokat a semget() rendszerhívással hozhatjuk létre:

semid = semget(key, count, flag);
A kernel a megadott kulccsal (key) count darab szemafort hoz létre. Létrehozásuk után a semop() rendszerhívás segítségével használhatjuk ket.

status = semop(semid, semops, nsemops);
Az nsemops méret semops tömb sembuf típusú elemei tartalmazzák a szemaforon

végrehajtandó utasításokat. A sembuf struktúra a következ :

struct sembuf { unsigned short sem_num; short sem_op; short sem_flg; };
A sem_num jelöl ki egy szemafort a létrehozottak tömbjéb l, a sem_op által meghatározott m velet pedig a következ lehet: sem_op > 0 esetén sem_op értéke hozzáadódik a szemafor értékéhez, sem_op = 0 esetén a kernel blokkolja a folyamatot mindaddig, míg a szemafor értéke nulla nem lesz,

I. UNIX

47

sem_op < 0 esetén a kernel blokkolja a folyamatot, míg a szemafor értéke nagyobb vagy egyenl lesz, mint a sem_op abszolút értéke. Ha ez bekövetkezik, akkor ezzel az értékkel csökkenti a szemafor értékét és továbbengedi a folyamatot. Látható, hogy egyetlen semop() hívás több szemaforon többféle m velet végrehajtását is jelentheti. A kernel garantálja azt, hogy a m veletek végrehajtásáig (vagy a folyamat blokkolásáig) más m veleteket ezen a halmazon nem kezd el végrehajtani (a szemafor m veletek kizárólagosak). Ha bármelyik m velet blokkolja a folyamatot, akkor a kernel visszaállítja az esetlegesen módosított szemaforok értékét a semop() hívás el tti értékekre. A flag paraméter beállításával (IPC_NOWAIT) blokkolás helyett hibaüzenettel való visszatérés is választható. Másrészt a SEM_UNDO flag beállítása esetén a kernel megjegyzi a folyamat által végrehajtott m veleteket, és azokat automatikusan visszaállítja, ha a folyamat kilép. Ez a módszer használható fel olyan holtpont helyzetek kezelésére, amikor a szemafort tartó folyamat kilépése miatt a szemaforra várakozók örökre leállnának a P() m veletben. A System V szemaforimplementáció legnagyobb problémája, hogy a szemaforok létrehozása és inicializálása nem atomi m velet. A két rendszerhívás (semget() és semctl()) között más folyamatok is hozzáláthatnak ugyanazon szemafor létrehozásához. A másik probléma a SYSV IPC általános vonása: a szemaforok törlésük nélkül a hozzájuk tartozó folyamatok megsz nése után is létezni fognak, feleslegesen foglalva a rendszer er forrásait.

I.3.5.6. Üzenetsorok
Az üzenetsor egy olyan leíró, mely üzenetek láncolt listájára mutat. Minden egyes üzenet egy típusjelz után egy adatterületet tartalmaz. A felhasználói folyamat az msgget()

rendszerhívással hozhat létre egy üzenetsort, melyet aztán az msgsnd() és msgrcv() rendszerhívásokkal írhat és olvashat a read() és write() rendszerhívásokhoz hasonlóan. Az üzenetsorok a cs vezetékekhez hasonlatosan FIFO m ködés ek, azaz a kernel nyilvántartja az üzenetek érkezési sorrendjét, és a legel ször érkezett üzenetet adja vissza az els olvasási kérésre. Két lényeges különbség van a cs vezetékekhez képest. Az üzenetek típusjelz je felhasználható sz r ként az olvasáskor bizonyos típusú üzenetek kiválasztására, azaz ilyenkor az els ként érkezett, megegyez típusú üzenettel tér vissza az msgrcv() hívás. Ez a mechanizmus felhasználható például üzenetprioritási rendszer megvalósítására. A másik különbség az üzenetsorok azon tulajdonsága, hogy az adatokat nem formázatlan folyamként, hanem elkülönül üzenetekben továbbítják, ami az adatok pontosabb

I. UNIX

48

feldolgozását teszi lehet vé, mivel az üzenetek belsejében a tartalmi feldolgozást segít típusazonosítókat lehet elhelyezni. Az üzenetsorok jól használhatóak kis méret adatcsomagok küldésére, de kevéssé alkalmasak nagy mennyiség adat átvitelére. A kernel bels adatbuffereket használ az üzenetek tárolására a kiolvasásig. Az üzenet beérkezésekor a kernel a küld adatterületér l átmásolja az üzenetet a bels tárolóba, majd a kiolvasáskor tovább másolja a fogadó adatterületére. Ily módon egyazon adatcsomagot kétszer kell mozgatni, ami nagy mennyiség adat esetén költséges megoldás. Az üzenetsorok másik hátránya, hogy nem nevezhet meg címzett az üzenetekhez. Bármilyen, megfelel jogosultságokkal rendelkez , folyamat kiolvashatja az üzeneteket.

Ennek megfelel en a kooperációban részt vev feleknek meg kell egyezniük valamilyen saját címzési protokollban, amit a kernel semmilyen eszközzel nem támogat.

I.3.5.7. Osztott memória
Az osztott memória a központi tár egy olyan régiója, melyet egyszerre több folyamat is használhat. A folyamatok ezen tartományt bármilyen virtuális címhez hozzárendelhetik saját címtartományukban. A hozzárendelés után a memória a folyamat saját memóriájával teljesen megegyez módon ­ rendszerhívások nélkül ­ használható. Ezért az osztott memória a

leggyorsabb kommunikációs forma azonos gépen futó folyamatok között. A memória létrehozója a kulcs megadása mellett meghatározhatja a memória méretét:

shmid = shmget(key, size, flag);
Már létez osztott memóriaterülethez az shmat() rendszerhívással lehet virtuális címet

rendelni, illetve az shmdt() hívással lehet a hozzárendelést megszüntetni:

addr = shmat(shmid, shmaddr, shmflag); shmdt(shmaddr);
A memória teljes megszüntetéséhez az shmctl() rendszerhívással ki kell adni az IPC_RMID parancsot. Ez azonban nem jár a memória azonnali megszüntetésével, csak megjelöli azt. A tényleges megszüntetés akkor következik be, amikor minden, a memóriához kapcsolódott folyamat lekapcsolódik róla. A törlésre megjelölt memóriához azonban új folyamatok már nem kapcsolódhatnak. Törlés nélkül a memória a folyamatok megsz nése után is megmarad, meg rizve minden adatot, amit a folyamatok ott elhelyeztek. Ily módon lehet vé válik például a folyamatok két futása közötti adatátmentés. Az osztott memória rendkívül gyors és egyszer en megvalósítható módszer az azonos gépen futó folyamatok közötti adatcserére. Legnagyobb hátránya, hogy semmilyen szinkronizációs

I. UNIX

49

mechanizmus nem kapcsolódik hozzá, így az adatok módosítása konkurens lehet. Még önálló adatstruktúrák módosításán belül is lehetséges a párhuzamosság, ami teljesen inkonzisztens adatokat eredményez. Ezért az osztott memóriát használó folyamatoknak egymás között meg kell oldaniuk a konzisztens módosítás rendszerét (például szemaforok segítségével).

I.3.5.8. Hálózati kommunikáció ­ socket programozás
A számítástechnikában a gépeket összekapcsoló hálózat megjelenése egy új fejezetet nyitott. A soros vonali terminál illesztés (dialup) továbbfejl dése gépek közötti pont-pont adatkapcsolat kialakítását tette lehet vé. Megjelent a kliens-szerver modell, mely szolgáltatásalapon különítette el a felhasználót (kliens) és a szolgáltatót (szerver). A UNIX operációs rendszerben alapvet en a TCP/IP protokollcsaládra alapuló

kommunikációs eszközöket fejlesztettek ki a különböz gépeken futó folyamatok közötti kommunikáció megoldására. A különböz gépeken futó alkalmazások közötti adatátvitel programozói interfésze nagyon hasonlatos az eddigiekben megismertekhez. A hálózati kommunikációs csatorna leírója az ún. socket, egy absztrakt objektum, ami felhasználható üzenetek küldésére és fogadására. A socket programozói interfész nem csak hálózati, hanem gépen belüli IPC megvalósítására is alkalmas. A socket (és az adatforgalom) alapvet en két típusú lehet (zárójelben az IP fölötti réteg protokolljának rövidítése olvasható): folyam (stream) (TCP): megbízható, sorrendhelyes, kétirányú kapcsolat üzenetszórás (datagram) (UDP): kapcsolatmentes csomagküldés, ahol a sorrend és a megérkezés nem garantált. Amikor egy folyamat egy socket hívást hajt végre, a kernel ezen alacsony szint adatátviteli protokollokat hívja meg az üzenetek átvitelére. A protokollhoz tartozó átviteli függvényeket egy táblából választja ki a kernel, és elküldi hozzájuk az adatokat. A magasabb szint kommunikációs rétegek az alacsonyabb szint ekkel közös adatstruktúrákon keresztül cserélik ki az adatokat. A socket hívások a hívó folyamat környezetében hajtódnak végre. Ily módon minden hiba szinkron módon jelentkezhet a hívónál. A socket hívások megvalósítására az ún. socklib felhasználói szint használni. Ez a legtöbb UNIX-variánsban elérhet . könyvtárat lehet

I. UNIX

50

(1) A socket létrehozása A hálózati programozás legkényesebb (legnehezebben megérthet ) része a socket létrehozásával, illetve konfigurálásával kapcsolatos. Ellentétben a fájlm veletek egyszer open() rendszerhívásával, itt több rendszerhívást is használni kell, valamint a kitöltend adatstruktúrák is bonyolultabbak. A socket a következ rendszerhívással hozható létre:
int socket(int domain, int type, int protokol);

ahol a domain esetünkben az AF_INET (más domain-ek is léteznek, mivel a socket nem csak hálózati kommunikációra használható), a típus stream vagy datagram (SOCK_STREAM, vagy SOCK_DGRAM), a protokoll praktikusan 0 (akkor más, ha a típuson és domain-en belül többféle protokoll is létezik). A visszatérési érték a socket-leíró, vagy hibajelzés. Ez azonban önmagában nem elegend adatok küldéséhez. (2) A socket kötése A socket létrehozása csak a névtérben történik meg a socket() rendszerhívással. A socket a következ rendszerhívással köthet a lokális gépen egy porthoz.
int bind(int sockfd, const struct sockaddr *addr, int addrlen);

Ezt tipikusan a szerver alkalmazásokban használjuk. Az így kötött portra kapcsolódhatnak a kliens alkalmazások a következ rendszerhívással:
int connect(int sockfd, const struct sockaddr *addr, int addrlen);

A connect() segítségével a socket egy tényleges adatúthoz köthet , azaz egy másik gépen futó alkalmazásig (a másik gép adott portjáig) vezet hálózati kapcsolatot hozunk létre. Ez a hívás egyrészt felépíti az adatutat, másrészt hozzárendel egy helyi portot, amihez köti a socketet. Els ránézésre nincs különbség az el z bind()-hez képest, azonban a cím (addr) struktúra kitöltése különböz a két esetben. A cím kitöltéséhez egy struktúrát használunk:
struct sockaddr { short int sin_family; char } sa_data[14]; /* Address family, esetünkben AF_INET */ /* 14 bájtos protokoll cím */

Ez túl általános, ezért az AF_INET domain-re készült egy jobb struktúra is:
struct sockaddr_in { short int unsigned short struct in_addr unsigned char }; sin_family; sin_addr; /* AF_INET */ /* IP cím */ int sin_port; /* portszám */ sin_zero[8];/* feltöltés sockaddr méret re */

I. UNIX

51

Ez a struktúra méretében megegyezik az el z vel (fontos a sin_zero feltöltése nullával), ezért használható helyette, csak a függvények hívásakor kell típuskonverziót végezni. Fontos megjegyezni, hogy a sin_port és a sin_addr hálózati bájtsorrendet követ (network byte order), tehát erre a formára kell hozni. Erre (illetve a visszaalakításra) a következö függvények valók: htons(), htonl(), ntohs(), és ntohl(), ahol az els bet a forrás (n: network, h: host), a negyedik bet a cél, míg az utolsó a típus (l: long, s: short). A kommunikáció során az adatokat is célszer ilyen bájtsorrendben küldeni, mivel így kikerülhet k a különböz architektúrák

eltér ábrázolási sorrendjéb l fakadó problémák. A fenti struktúrában szerepl in_addr kifejtése a következ
struct in_addr { unsigned long } s_addr; /* 4 bájtos cím */

például:
struct in_addr server_addr = inet_addr("152.66.82.1"); /* hálózati bájt sorrenddel tér vissza */

A név szerinti címek leírására a következ függvények használhatóak.

struktúra, illetve kezelésükre a következ

/* FONTOS! Minden adat hálózati bájtsorrendben adott */ struct hostent { char char *h_name; **aliases; /* els dleges név */ /* alternatív nevek */ /* esetünkben AF_INET */ /* a cím hossza bájtokban */

int h_addrtype; int h_length; char }

**h_addr_list; /* a gép címei, nullával végz dik */

#define h_addr h_addr_list[0] /* a gép els dleges címe */ /* A címek lekérdezése név alapján: */ struct hostent *gethostbyname(const char *hostname);

(3) A socket használata A szerverek a bind() hívás után bejöv adatokra várakoznak. Miel tt ezt megtennék egy rendszerhívással konfigurálják a várakozási sor hosszát.
int listen(int sockfd, int backlog); /* backlog: a sor hossza */ int accept(int sockfd, void *addr, int *addrlen);

I. UNIX

52

Az operációs rendszer a portra beérkez kapcsolatokat egy sorban helyezi el, aminek hosszát határozza meg a backlog paraméter. A szerver az accept() rendszerhívással a sor elején álló kérést fogadja, az addr struktúrában megkapva annak paramétereit. A következ accept() a sorban következ kéréssel fog foglalkozni. Az accept visszatérési értéke egy új socket-leíró, mely a klienshez létrejött kapcsolatban használható adatküldésre és fogadásra.
int send(int sockfd, const void *msg, int len, int flags); int recv(int sockfd, void *buf, int len, unsigned int flags); /* Mint minden fájlleíróra, itt is használható a read() és a write() */

Mindkét rendszerhívás az elküldött, illetve fogadott bájtok számával tér vissza, amely küldésnél kevesebb is lehet, mint az el írt. (4) A socket lezárása A socket a shutdown() és a fájl m veleteknél megszokott close() rendszerhívásokkal zárható le. Az el bbinek paraméterként megadható, hogy a kétirányú adatforgalomból melyik irányt zárja le. (5) Tipikus szerver és kliens alkalmazás Egy tipikus szerver alkalmazás szerkezete UNIX alatt:
servsock = socket(); bind(servsock, ...); listen(servsock, ...); while (1) { newsock=accept(servsock, ...); if (fork()==0) { /* a gyerek kiszolgálja a kérést */ if (send(new_fd, "Hello, world!\n", 14, 0) == -1) perror("send"); close(new_fd); exit(0); } /* a gyerek vege */ close(new_fd); /* a szül nek nem kell */ } /* while() */

A kliens programjának szerkezete:
#define SERVERPORT sockfd = socket(); srv_addr.sin_family = AF_INET; srv_addr.sin_port = htons(SERVERPORT); 1201 srvent = gethostbyname(server_hostname);

I. UNIX

53

srv_addr.sin_addr = *((struct in_addr *)srvent->h_addr); bzero(&(srv_addr.sin_zero), 8); connect(sockfd, (struct sockaddr *)&srv_addr, numbytes = recv(sockfd, buf, MAXDATASIZE, 0) buf[numbytes] = '\0'; printf("Received: %s",buf); ... close(sockfd); sizeof(struct sockaddr))

(6) Megjegyzések Az itt ismertetett rendszerhívások nem csak UNIX, hanem más operációs rendszer alatt is így használhatóak (könnyen írható olyan forráskód, mely UNIX, DOS, Windows, OS/2 alatt is lefordul). Legnagyobb különbség az egyéb rendszerhívásokban van, pl. új folyamatot másképp kell Windows és UNIX alatt indítani (de még a UNIX verziók között is lehet választási lehet ség). Windows, OS/2, illetve újabb UNIX verziók (pl. Solaris 2) esetén már használhatunk szálakat (thread) is (pl. a fent bemutatott tipikus szerverben a kérés kiszolgálására), míg régebbi UNIX-ok (pl. SunOS) esetén csak folyamatokban (process) gondolkozhatunk.

I.3.6. Állományrendszer implementációk

A mai modern Unix rendszerek számos különböz típusú állományrendszert támogatnak. Ezek két nagy csoportra oszthatók: lokális és távoli állományrendszerek. Az el bbi a rendszerhez közvetlenül csatlakoztatott berendezéseken tárolja az adatokat, míg az utóbbi lehet séget nyújt a felhasználónak, hogy távoli gépeken elhelyezked állományokhoz férjen hozzá. A legtöbb modern Unix rendszerben megtalálható két általános célú állományrendszer a System V állományrendszer (s5fs) és a Berkeley Fast File System (FFS). Az s5fs az eredeti UNIX állományrendszer. A System V rendszerek mindegyike és a kereskedelmi rendszerek nagy része is támogatja ezt az állományrendszert. Az FFS-t a 4.2 BSD vezette be, jobb hatékonyságú, robosztusabb és több funkcionalitást biztosít korábbi társánál. Kiváló tulajdonságai miatt széles körben elterjedt a kereskedelmi változatokban, s t a SVR4-be is bekerült.

I. UNIX

54

A korai Unix rendszerek egyetlen egy típusú állományrendszer kezelésére voltak képesek, így a rendszerek fejleszt i választásra kényszerültek. Mint azt majd a kés bbiekben látni fogjuk, a Sun Microsystems által kidolgozott vnode/vfs interfész lehet vé tette több állományrendszer egyidej alkalmazását is.

A következ kben el ször részletesen ismertetjük a s5fs felépítését, annak lemez szervezését és az alkalmazott adatszerkezeteket, majd rámutatunk azokra a hiányosságokra, amik elvezettek az FFS és a vnode/vfs interfész kidolgozásához. Ez a tárgyalásmód egyrészt segít megérteni az állományrendszerek általános felépítését és funkcióit, másrészt szépen mutatja a mérnöki fejlesztés, problémamegoldás logikus lépéseit.

I.3.6.1. A System V állományrendszer

(1) Az állományrendszer felépítése

A Unix más operációs rendszerekhez hasonlóan logikai szinten, nem pedig diszk szinten kezeli az állományrendszert. A kernel logikai blokkokban szervezi az állományrendszert, egy blokk lehetséges mérete: 512*2k byte, ahol a k kitev tipikus értékei a 0 - 5 tartományba esnek, megválasztásánál az alábbi szempontokat szokás figyelembe venni:

minél nagyobb a blokkméret, annál hatékonyabb az adathozzáférés, kisebb az adategységre jutó keresési id veszteség, nagyobb az átvitel sávszélessége minél kisebb a blokkméret, annál kisebb a tördel dés

A kezdeti s5fs implementációban 512, majd a kés bbiekben 1Kb-os blokkméretet alkalmaztak.

Az állományrendszer logikai szerkezete

I. UNIX

55

A továbbiakban részletesen tárgyaljuk a s5fs lemezen található adatszerkezeteit. A lemezt az állományrendszer négy logikailag eltér feladatot ellátó részre osztja:

boot blokk

szuper blokk

inode lista

adat blokkok

Az egyes részek feladatai az alábbiak:

boot blokk ­ A rendszer elindulásához szükséges információkat tartalmazza. (Bár csak egyetlen állományrendszernél van szükség a boot blokkra, minden állományrendszer tartalmazza, legfeljebb üres). szuperblokk ­ Az állományrendszerr l tartalmaz a rendszer m ködéséhez szükséges metaadatokat, az állományrendszer állapotát írja le. Az itt tárolt információkat a kés bbiekben részletezzük. inode lista ­ Minden állományhoz pontosan egy inode tartozik, ezek alapján lehet az állományokra hivatkozni. A lista méretét a rendszergazda adja meg, meghatározva ezzel az állományrendszerben a maximális állományszámot. Az inode-ok és a lista szerkezetét a kés bbiekben részletesen tárgyaljuk. adat blokkok ­ Ezek szolgálnak a fizikai adattárolásra.

A következ kben tekintsük át az egyes elemeket egy kicsit részletesebben.

A szuperblokk szerkezete

A szuperblokk az állományrendszer egészér l tartalmaz fontos információkat, ún. metaadatokat. A szuperblokkban tárolt legfontosabb információk:

az állományrendszer mérete a szabad blokkok száma a szabad blokkok listája a következ szabad blokk indexe az inode lista mérete a szabad inode-ok száma

I. UNIX

56

inode lista (tömb) a következ szabad inode indexe lock mez k (inode, blokk lista) módosítás jelz bit

A továbbiakban a szuperblokk két legfontosabb adatszerkezetének, a szuper blokkon belül tárolt inode listának és a szabad blokkok listájának a felépítését és kezelését ismertetjük.

Az inode lista

Mint azt már korábban láttuk, az állományrendszer a szuperblokk után egy lineáris listában tárolja az inode-okat. Az inode tartalmaz egy típus mez t, amely értéke 0 ha az inode szabad, vagyis felhasználható. Így a kernel viszonylag könnyen kereshet szabad inode-okat. Azonban az állományrendszerben gyakori esemény, hogy új inode-ra van szükség, hisz minden

megnyitott állományhoz hozzá kell rendelni egyet, így a fenti megoldás nem elég hatékony. Ezért a szuperblokk tartalmaz egy fix méret tömböt (szuperblokk inode lista), amelyet

gyorsítótárként (cache) használ a szabad inode-ok sorszámainak tárolására. Minden egyes elem egy szabad inode sorszámát tárolja. Ha a rendszernek szabad inode-ra van szüksége (pl. fájl létrehozása), keresés helyett kiveszi a tömbben tárolt utolsó elemet. A tömb kezelését egy index nyilvántartása segíti. Ez megmutatja, hogy hány felhasználható elem (szabad inode sorszám) van még a tömbben, illetve éppen az utolsó felhasználható elemre mutat. A VI.3.5. ábra fels részén az index a 44. elemre mutat, vagyis a 44. elem tartalmazza a legközelebb felhasználandó inode indexét. Ez a példában a 23-as. Amennyiben a kernel felhasznál egy inode-ot, akkor az indexet eggyel csökkenti (lásd a VI.3.5. ábra alsó részét).

351

szabad inode-ok ...

71 43

23 44 index

üres

megjegyzett inode

351

szabad inode-ok ...

71

üres

I. UNIX

57

43 index

VI.3.5. ábra: A szuperblokkban tárolt inode lista

Amikor kiürül a szuperblokk inode listája, a kernel elkezdi vizsgálni az (igazi) inode listát, szabad inode-okat keres, és hátulról kezdve teljesen feltölti a szuperblokkon belüli inode listát. Az utolsó megtalált szabad inode sorszám kerül a tömb els helyére. Ezt megjegyzett

inode-nak is nevezik. Ennek nagy hatékonyság növel

szerepe van, mert a kernel a

legközelebbi feltöltéskor ett l a sorszámtól kezd d en kezdi el keresni a szabad inode-okat. Amikor a kernel felszabadít egy inode-ot, akkor megnézi, hogy van-e szabad hely a tömbben. Amennyiben igen, egyszer en beteszi a sorszámot a tömb els szabad helyére, és eggyel növeli az indexet. Amennyiben a tömb tele van, megnézi, hogy a megjegyzett inode sorszáma kisebb-e, mint a felszabadítandó inode-é. Amennyiben kisebb, akkor a felszabadított inode-ot az algoritmus meg fogja találja a diszken, hiszen az a megjegyzett inode után következik, így nincs további teend . Amennyiben a felszabadított inode sorszáma kisebb, mint a megjegyzetté, akkor annak helyére írja ­ ez lesz tehát a megjegyzett inode ­, így biztosítva, hogy a kernel valóban a legkisebb sorszámú szabad inode-tól kezdje majd a következ keresést.

A szabad lemezblokkok listája

Mint azt korábban láttuk, az inode-ról egyértelm en el lehet dönteni, hogy szabad-e: amennyiben a típus mez értéke 0, akkor szabad, ellenkez esetben foglalt. Sajnos a

lemezblokkok (adat blokkok) esetében pusztán azok tartalmának vizsgálatával nem lehet eldönteni, hogy szabadok-e, vagy használatban vannak, ezért a szabad lemezblokkokat adminisztrálni kell, azokat külön kell kezelni. Ennek érdekében a szuperblokk tartalmaz egy szabad blokk listát, amelynek a szervezése az alábbi:

A lista rögzített méret , és a szabad blokkok sorszámait tartalmazza. Az els (a felhasználás sorrendjében utolsó) elem pedig egy olyan blokk sorszáma, amelyik szintén szabad blokkok

I. UNIX

58

sorszámait tartalmazza. (Tegyük fel, hogy egy blokk mérete 1K, és a sorszámok 4 byte-osak. Így egy blokkban 1024/4 = 256 szabad blokk sorszámát lehet tárolni.)

Például: a szuperblokkban tárolt szabad blokkok listájának egy lehetséges állapota:

A szuperblokkban lév szabad blokkok listája 105 108 115 214 ...

A 105-ös blokk tartalma 214 206 203 217 ...

A 214-es blokk tartalma 313 315 317 321 ...

Ezen lista kezelése hasonló a szabad szuperblokk inode lista kezeléséhez: egy index segítségével a kernel mindig nyilvántartja, hogy hányadik elem tartalmazza a következ szabad blokk sorszámát. Amennyiben szabad blokkra van szükség, a kernel visszaadja az els szabad blokk sorszámot. Amennyiben felszabadul egy blokk, akkor a sorszámát a kernel beírja az els szabad helyre. Amennyiben nincs szabad hely már a listán, akkor a lista

tartalmát bemásolja a felszabadított blokkba, és a visszaadandó blokk sorszámát beírja a lista utolsó helyére. Így a szabad blokkok listája egy újabb blokknyi (256) index hellyel b vül. Amennyiben a szuperblokkban tárolt szabad blokkok listája már csak egy elemet tartalmaz, akkor ez olyan blokkra mutat, amelyik újabb szabad blokkok sorszámait tartalmazza. Ha most újabb szabad blokkra van szükség, el ször a kernel a maradék egyetlen sorszám által mutatott blokk tartalmát (újabb szabad blokkok sorszámai) bemásolja a szuperblokk szabad blokk listájába (ekkor a blokk valóban szabaddá vált), majd visszaadja a sorszámot. Lássunk egy példát! A szuperblokkban tárolt szabad blokkok listája már csak egyetlen sorszámot tartalmaz, a 105-öst (amely újabb 256 szabad blokk sorszámait tartalmazza).

A szuperblokkban lév szabad blokkok listája 105 ...

I. UNIX

59

A 105-ös blokk tartalma 214 206 203 217 ...

Tegyük fel, hogy ekkor a kernel felszabadítja a 934-es blokkot és visszateszi a szabad blokkok listájára.

A szuperblokkban lév szabad blokkok listája 105 934 ...

A 105-ös blokk tartalma 214 206 203 217 ...

Tegyük fel, hogy ezek után szükség van egy szabad blokkra. A kernel visszaadja a 934-es blokkot. Ezután újabb blokkra van szükség. Ekkor a kernel a 105-ös blokk tartalmát bemásolja a szuperblokk szabad blokk listájába, majd visszaadja a 105-ös blokkot. A szuperblokkban lév szabad blokkok listája 214 206 203 217 ...

A 214-es blokk tartalma 313 315 317 321 ...

Az eddigiek során számos alkalommal hivatkoztunk már az inode-okra, vázlatosan ismertettük a rendeltetését, azonban még nem adtuk meg a bels szerkezetét, a benne tárolt információkat. A Unix állományrendszerben betöltött központi szerepe miatt az alábbiakban részletesen ismertetjük az inode felépítését

Az inode

Az inode a fizikai állományhoz tartozó azonosító. Az állományrendszer minden egyes állományához pontosan egy inode tartozik. Az állományrendszerben az inode-ok diszken

I. UNIX

60

találhatók, azonban a gyorsabb m ködés érdekében a kernel cache-eli azokat a memóriában. A diszken tárolt inode számos, az állományhoz kapcsolódó információt tárol:

tulajdonos azonosító (UID, GID) állomány típusa ­ reguláris, könyvtár, FIFO, karakteres vagy blokkos berendezés állomány hozzáférési jogosultságok (tulajdonos, csoport, ill. a világ számára, olvasási, írási ill. végrehajtási jogok) id címkék az utolsó állományhozzáférés ideje az utolsó állomány módosítás ideje az utolsó attribútum módosítás ideje (inode módosítás) linkek száma (hány könyvtári bejegyzés hivatkozik az adott fizikai állományra) címtábla (mutatók adat blokkokra ­ 10 db direkt, 1 db indirekt, 1 db kétszeres indirekt és 1 db háromszoros indirekt mutató) állomány méret

A kernel a memóriában cache-eli az inode-okat (ezeket in-core inode-oknak is nevezzük). Ezek egy kicsit más felépítés ek, mint a diszken tárolt másolatuk. Tartalmazzák a diszken tárolt inode összes információját, azonban néhány további információval ki vannak egészítve:

az in-core inode státusza - zárolt (locked) - folyamat vár rá - eltér a diszken lév változattól attribútum írás következtében adat írás következtében az állomány mount pont, vagyis az adott pontra egy másik állományrendszer csatlakozik az állományt tartalmazó állományrendszer logikai berendezés azonosítója az inode sorszáma (a diszken az inodok az inode listában sorszámuk által meghatározott, rögzített helyen találhatóak, nincs szükség a sorszám tárolására.) mutatók más in-core inode-okra (hash sorok, szabad lista) hivatkozásszámláló (hány példányban van nyitva az állomány)

I. UNIX

61

A hivatkozásszámláló fontos szerepet játszik a memóriabeli inode-ok kezelésében. Mivel a számláló megmutatja, hogy az adott állomány hány példányban van nyitva, így amíg az nagyobb nullánál, addig az inode aktív, használatban van. Amennyiben a számláló értéke nulla, akkor az inode inaktív, éppen senki sem használja, így az a szabad listára kerülhet, ahonnan majd a kernel újra allokálhatja, és esetleg már egy másik állományhoz rendelheti.

(2) Reguláris állományok szerkezete

A UNIX rendszer az indexelt allokáció egy speciális formáját alkalmazza a fájlokhoz tartozó adatblokkok lefoglalásakor. Az indexelt allokáció lehet vé teszi az adatterület blokkonkénti lefoglalását. Így a fájl egyes adatblokkjai a lemez tetsz leges blokkjában tárolhatók. A fájlhoz tartozó adatok elhelyezkedését az inode-ban található címtábla (13 mutató) írja le.

Tegyük fel, hogy a rendszer diszk blokkjai 1K-sak, és 4 byte-on lehet a blokkokat címezni. Az inode címtáblájának els 10 pointere egy-egy 1K-s diszk blokkra mutat. Ezek a direkt elérés blokkok. A következ mutató egy olyan diszk blokkra mutat, amely további mutatókat tárol, most már adatokat tartalmazó blokkokra. Mivel egy blokkba 256 mutató fér el, így a fenti egyszeres indirekt címzéssel további 256K adatot lehet megcímezni. A következ mutató kétszeres indirekt mutató, vagyis egy olyan blokkra mutat, amely 256 mutatót tartalmaz, amelyek mindegyike egy-egy további indirekt blokkra mutat. Vagyis most hivatkozáskor az els két lépésben indirekt blokkokat kapunk, és csak a harmadik lépésben jutunk el az adatokhoz. Ezzel a módszerrel 64M adatot lehet megcímezni. A következ , egyben utolsó mutató egy háromszoros indirekt mutató, vagyis még a harmadik hivatkozás is 256 pointert tartalmazó indirekt blokkra mutat, és onnan egy újabb referenciával juthatunk el az adatokhoz. Ezzel a módszerrel 16G adatot lehet címezni. Tehát a fent vázolt struktúrával összesen:

10 db 1 db 1 db 1 db

direkt blokk egyszeres indirekt blokk kétszeres indirekt blokk háromszoros indirekt blokk

10K 256K 64M 16G

I. UNIX

62

adatot lehet tárolni. A valóságban persze ennél kevesebbet, mert az inode állományhossz mez je is 4 byte, a méretet byte egységben tárolják, így ez 4G-ra korlátozza a maximális állományméretet.

A jobb érthet ség érdekében tekintsünk két példát: (a blokkméret továbbra is 1Kb és a blokkokat 4 byte-on címezzük, így egy blokkban 256 blokkcím tárolható. A példához használt állomány lemez blokkjait a . ábra mutatja.)

1. példa:

Tegyük fel, hogy egy fájl 9500-adik byte-ját akarjuk olvasni, amihez a kernelnek meg kell találni az ehhez tartozó blokk címet.

A 9500-adik byte a 9. direkt blokkban van (9*1024 = 9216), ott pedig a 284-edik (a blokkokat 0-tól kezd d en sorszámozzuk). A példában az inode 9. direkt blokkra mutató pointer a 3361. lemezblokkra mutat, vagyis a 3361. blokk 284. byte-ja a keresett adat.

I. UNIX

63

4016 2328 45344 0 0 12121 0 1004 118 3361 322 7147 333 80. 3121 --------> 3121-es blokk --------> 2456 --------> --------> 3361-es blokk

VI.3.6. ábra: A példa állomány lemez blokkjainak az elhelyezkedése

2. példa: (VI.3.6. ábra)

Tegyük fel, hogy a 355 000-es byte-ot akarjuk olvasni. Ehhez kétszeres indirekt blokkot kell használni, mert a 10 direkt és az egyszeres indirekt blokkal 10*1024 + 256*1024 = 272384 byte-ot lehet elérni. Innen számítva a 82616. byte-ot keressük. Az a kétszeres indirekt blokk els mutatója által kijelölt egyszeres indirekt blokkban van, méghozzá annak 80. elemében (80X1024 = 81920) Az így kijelölt blokk 696. byte-ja a keresett adatelem. A fenti példa esetén a kétszeres indirekt blokk pointere a 7147. diszk blokkra mutat, annak az els pointere a 2456. blokkra, ami tartalmazza 80. elemként a keresett adatokat tartalmazó blokk címét, a 3121-et. Ezen a blokkon belül a 696. byte-ot kerestük.

A fenti séma problémája, hogy az indirekciók id igényesek, nagy fájlok esetén lassul az adatelérés. A bevezetés id szakára jellemz statisztika szerint azonban az állományok kb.

I. UNIX

64

85%-a kisebb 8K-nál (így elférnek a direkt blokkokban), és ezen állományok kb. 48%-a kisebb 1K-nál! Ebb l következik, hogy indirekt elérésre ritkán van szükség, így az effektív adathozzáférés gyors. Nagy fájlok esetén pedig egyrészt a felhasználók is türelmesebben viselik a hosszabb keresési id ket, másrészt a rendszerek egyéb megoldásokat is alkalmaznak a gyorsítás érdekében (pl. buffer-cache).

(3) Az állománykezelés logikai sémája és adatszerkezetei

A UNIX a fájlkezelés multiprogramozott rendszerekben felmerül kérdéseire a következ választ adja: A folyamatoknak csak megnyitáskor kell névvel hivakozniuk egy fájlra. A megnyitás egy számot (logikai perifériaszám) ad vissza a folyamatnak, a további m veletekben (read, write) ezzel hivatkozhat a fájlra. Egy folyamat többször is megnyithat egy fájlt, minden megnyitáskor önálló logikai periféria jön létre, amelyek azonban külön-külön fájlmutatóval ugyan, de ugyanazt a fizikai fájlt jelentik. Így egy folyamat különböz logikai perifériaként ugyannak a fájlnak különböz részeit használhatja különböz fájlmutatókkal. Több folyamat megnyithatja és használhatja ugyanazt a fájlt párhuzamosan, a read és write rendszerhívások atomicitása teljesül, azonban hosszabb távú szinkronizáció megoldása külön m veleteket igényel. A gyermek folyamatok öröklik a szül k logikai perifériáit. Ha a gyermek és a szül ugyanazt a logikai perifériát használja, a gyermek és a szül fájlm veletei a CPU-ütemezést l függ sorrendben írják, vagy olvassák a fájlt ugyanazon fájlmutató használatával.

A s5fs állományrendszerben a logikai állománykezelés három szintre tagozódik, amelyekhez egy-egy fontos adatszerkezet tartozik. Az alábbiakban az egyes lépcs khöz tartozó adatszerkezeteket (folyamatonkénti állományleíró tábla, globális állománytábla, és inode tábla) és a hozzáférésben betöltött funkciójukat ismertetjük.

Folyamatonkénti állományleíró tábla:
Minden egyes folyamathoz tartozik egy állománytábla. Mint azt a neve is mutatja, ez egy folyamathoz tartozó adatszerkezet. A tábla egy bejegyzése egy logikai perifériának felel meg.

I. UNIX

65

A folyamatok állománytáblájuk bejegyzéseinek indexeit használják a logikai periféria azonosítására. Ebben a táblában minden, a folyamat által elérhet , megnyitott állományhoz legalább egy mutató tartozik. A mutató a globális állománytábla megfelel elemére mutat.

Globális állománytábla:
Minden egyes open rendszerhívás hatására létrejön egy bejegyzés (struktúra) a globális állománytáblában, amely az adott állomány névhez rendel dik, tartalmazza a megnyitás módját, jogosultságokat, egy fájlmutatót, hogy hol tartunk az állományban az

olvasással/írással,

illetve egy hivatkozásszámlálót,

amely megmondja,

hogy hány

folyamatonkénti állománytábla bejegyzés mutat rá. A globális állománytáblában egy állománynévhez több bejegyzés is tartozhat, itt a bejegyzések munkamenetet tárolnak.) A globális állománytábla használata az állományok osztott használatát teszi lehet vé.

Inode tábla (in-core inode tábla):
Minden egyes megnyitott állományhoz tartozik egy inode a memóriában, tartalmaz egy hivatkozásszámlálót, hogy az adott nev fizikai állományt hány példányban használják,

vagyis hány globális állománytábla bejegyzés mutat rá.

A folyamatonkénti állományleíró tábla els

három eleme (0, 1, 2) a standard input-, a

standard output-, illetve a standard error logikai perifériákat jelöli. Ezeket a folyamatok indulásukkor megnyitva kapják.

A Unixban az állományok megnyitására az open rendszerhívás szolgál. Ennek alakja:

fd = open(path, flag, mode);

Kötelez en meg kell adni a megnyitandó állomány elérési útját (path) és a megnyitás módját. A rendszerhívás egy egész számot (fd) ad vissza, ami tulajdonképp nem más, mint egy index a folyamatonkénti állományleíró táblába.

I. UNIX

66

Az alábbi példában megnyitunk három állományt, majd az egyik állományleírót megkett zzük. A VI.3.7. ábra mutatja, hogy a rendszerhívások hatására milyen bejegyzések jelennek meg a fent ismertetett három adatszerkezetben. Az ábrán a nyilak mutatókat jelölnek.

fd1 = open("/etc/group", O_RDONLY); fd2 = open("readme", O_RDWR); fd3 = open("/etc/group", O_WRONLY); fd4 = dup(fd2);

folyamatonkénti állományleíró tábla Stdin Stdout Stderr fd1

globális állománytábla

inode tábla

1

/etc/group

2 /etc/group

(RDONLY) fd2 2 (RDWR) fd3 1 /etc/group readme 1 readme

(WRONLY) fd4

VI.3.7. ábra: Az open és dup rendszerhívások hatása az állománykezeléssel kapcsolatos adatszerkezetekre

A VI.3.7. ábrán jól látszik, hogy minden egyes open rendszerhívás hatására a globális állománytáblában létrejön az adott állománymegnyitáshoz tartozó bejegyzés. A jelölt számok hivatkozásszámlálók, megadják, hogy a folyamatonkénti állományleíró táblák hány bejegyzése mutat az adott elemre. Bár a jobb áttekinthet ség érdekében az ábrán nem tüntettük fel, a globális állománytábla bejegyzései tárolják az állományból/ba történ olvasás/írás pillanatnyi pozícióját (fájlmutató), vagyis egy indexet, hogy hol tart az adott m velet az állományban. Az open rendszerhívás végrehajtásakor bejegyz dik egy mutató a

I. UNIX

67

folyamatonkénti állományleíró táblába is, ami az adott állománymegnyitáshoz tartozó globális állománytábla bejegyzésre mutat. A dup rendszerhívás a paraméterül kapott állományleírót megduplázza és beírja a folyamatonkénti állományleíró tábla els szabad helyére. (Ezt a standard bemenet és kimenet átirányítására hatékonyan ki lehet használni.) Az ábrán jól látszik, hogy a dup rendszerhívás hatására egy újabb mutató mutat a globális állománytábla

readme állományhoz tartozó bejegyzésére (ezt a hivatkozásszámláló is jelzi). Míg a
globális állománytábla munkameneteket reprezentál, addig az inode tábla magukat az állományokat. Ebb l adódóan minden egyes állományhoz és nem pedig az állomány megnyitásokhoz tartozik egy-egy bejegyzés. A fenti példa állománymegnyitásai így két új bejegyzést hoznak csak létre az inode táblában, hisz két megnyitás ugyanarra a fizikai állományra vonatkozik (ami persze két különböz munkamenetet jelent). A

hivatkozásszámláló az egyes inode tábla bejegyzésekre mutató globális állománytábla bejegyzések számát mutatja.

(4) Állományok és könyvtárak

Az állomány logikailag egy adattároló egység. A felhasználónak lehet sége van a fájl adatainak mind szekvenciális (sequencial), mind pedig címzett elérésére (véletlen ­ random access), a kernel segítségével számos m veletet végezhet a fájlokon. Fontos megjegyezni, hogy a kernel nem értelmezi az állományban tárolt adatokat, nem feltételez semmilyen magasabbrend struktúrát, egyszer en byte-ok folyamának tekinti a fájlt.

(Amennyiben szükség van valamilyen magasabbrend szerkezetre - pl. rekordra - azt az alkalmazásoknak kell kezelni.) A Unix a felhasználó szemszögéb l tekintve az állományokat egy hierarchikus fa struktúrájú névtérbe rendezi (lásd a VI.3.8. ábrát).

I. UNIX

68

VI.3.8. ábra: A Unix állományrendszer könyvtár struktúrája

A nevek a / és a NULL karakter kivételével tetsz leges ASCII karaktert tartalmazhatnak. A gyökér (root) könyvtárat a ,,/" név jelöli. A hierarchikus névtérb l adódóan egy könyvtáron belül egyedi állományneveknek kell szerepelni, más könyvtárban azonban szerepelhet egy állomány azonos névvel (ekkor az egyediséget az eltér elérési út biztosítja). A Unix támogatja az aktuális könyvtár fogalmát, amelyhez képest relatív elérési utat is lehet használni. Az aktuális könyvtárat a chdir rendszerhívással lehet megváltoztatni. Egy állományhoz tartozó könyvtár bejegyzést az állományra mutató hard linknek vagy egyszer en csak linknek nevezünk. Minden állományra több link is mutathat, akár más-más könyvtárakból is. Ebb l adódóan a UNIX-ban egy állomány nem egyetlen adott névhez köt dik, nincs egyedi neve. A név nem az állomány attribútuma, van azonban egy ún. link számláló minden egyes állományhoz, amely megadja, hogy hány néven lehet hivatkozni az adott állományra. (Ez az inode-ban tárolt hivatkozásszámláló megmutatja, hogy hány könyvtári bejegyzés mutat a fájlra.) Egy állomány addig létezik, amíg a link számlálója nagyobb nullánál. Amikor a számláló nullává válik, az állomány már elérhetetlen, így az általa használt diszk terület felszabadítható. Az állomány bármelyik linken keresztül teljesen egyenrangúan érhet el.

A s5fs könyvtárszerkezete

I. UNIX

69

A Unix alatt a könyvtárak is állományok, de speciális szerkezettel bírnak. Minden egyes könyvtár tartalmaz két különleges bejegyzést: A . és a .. bejegyzéseket az aktuális könyvtárhoz, illetve a szül könyvtárhoz. A s5fs könyvtárak szerkezete a következ : minden bejegyzés tartalmaz egy 2 byte-os inode számot, amely az adott nev állomány inode-ját adja meg, illetve egy 14 karakterb l álló állománynevet. Így minden egyes bejegyzés 16 byte-ot foglal. Például a /etc könyvtár tartalmazhatja az alábbi adatokat:

relatív bytecím 0 16 32 48

inode száma (2 byte) 83 2 1798 1276

állománynév (14 byte) . .. group networks

Ezek után egy adott nev állományhoz tartozó inode megkeresése elég egyszer m velet: a kernel az adott könyvtárban végez egy lineáris keresést a név alapján, és a hozzá tartozó inode-ot a megfelel könyvtár bejegyzésb l ki tudja olvasni.

(5) Az s5fs értékelése

Az s5fs-t az egyszer felépítése emeli ki a többi állományrendszer közül. Ez az egyszer ség nagyon el nyös az érthet ség, áttekinthet ség és megvalósítás szempontjából, azonban a megbízhatóság, teljesítmény és funkcionalitás területén kívánnivalókat hagy maga után. A megbízhatósági problémák els dleges forrása a szuperblokk kezelésével kapcsolatos. A szuperblokk az állományrendszer szempontjából életbevágóan fontos információkat, mint például a szabad blokkok listája, a szabad inode-ok száma tartalmaz. A s5fs-ben minden egyes állományrendszer csak egyetlen példányban tartalmazza a szuperblokkot. Ebb l adódóan ha a szuperblokk megsérül, a teljes állományrendszer használhatatlanná válhat. A teljesítmény problémák is több okra vezethet k vissza. Az s5fs együtt kezeli az inode-okat, azokat az állományrendszer elején tárolja, majd utána következnek az adatblokkok. Ebb l

I. UNIX

70

adódóan egy állomány hozzáférés esetén el ször be kell olvasni az inode-ot, majd utána a fizikailag távol elhelyezkedhet adatblokkot. Ez gyakran jelent s fejmozgásokat igényelhet, ami lassítja az adathozzáférést. Másrészt az inode-ok kiosztása is véletlenszer , nem követi az esetlegesen meglév logikai állománycsoportokat (pl. azonos könyvtárban lév állományok). Nemcsak az inode-ok kiosztása véletlenszer , hanem az adatblokkoké is. Bár kezdetben a szabad blokkok rendezetten tárolódnak, a folyamatos használat (foglalás, felszabadítás) hatására ez a rendezettség megsz nik. Egy állomány logikailag szomszédos blokkjai véletlenszer en, akár távoli sávokon is elhelyezkedhetnek, aminek hatására a szekvenciális hozzáférés lelassulhat. A lemez blokkok mérete is problémát jelent. A korai, SVR2 rendszerekben 512 byte-os blokkokat használtak. Ennek hatására a bels tördel dést alacsony szinten lehetett tartani (átlagosan a blokkméret fele), ennek ára viszont, hogy egy lemezhozzáféréssel kevesebb adatot lehet beolvasni. A SVR3-tól kezd d en 1K-s blokkokat használtak, ami javította az adatátvitelt, de növelte a tördel dést. Ez a probléma egy rugalmasabb allokációs módszer igényét vetette fel. Végezetül a s5fs néhány funkcionalitásbeli problémával is küszködik. Ezek közül talán a legjelent sebb korlátozás az állománynevek 14 karakteres maximális hossza. A korai id kben ez minden bizonnyal elegend volt, azonban manapság felettébb rontja a rendszer

kereskedelmi értékét, hisz a mai felhasználók már egyre inkább megszokták, hogy hosszú, beszédes neveket adjanak az állományaiknak. Másrészt számos alkalmazás, mint például a fordítók, szövegfeldolgozók munkájuk során új kiterjesztéseket, tagokat f znek a feldolgozandó állomány nevéhez. Ebben az esetben a 14 karakteres állományhossz megkeseríti az ilyen alkalmazás íróinak az életét. Mint azt korábban láttuk, a könyvtárszerkezetben minden állományhoz egy 16 byte-os bejegyzés tartozik. Ebb l 14 byte az állomány neve (innen a 14 karakteres maximális állománynév korlátozás) és a maradék két byte azonosítja az állományhoz tartozó inode-ot. Ebb l viszont következik, hogy egy állományrendszerben maximum 16 biten

megkülönböztethet , vagyis 65535 inode­vagyis állomány lehet. Ez a mai alkalmazások tükrében megengedhetetlen korlátozásnak t nik. Ezek a problémák motiválták a Berkeley Fast File System állományrendszer kidolgozását. Az alábbiakban vázlatosan kitérünk a fenti problémák megoldására.

I. UNIX

71

I.3.6.2. A Berkeley FFS állományrendszer

Az FFS az s5fs számos hiányosságát próbálta meg orvosolni. A s5fs minden funkcionalitását megtartotta, a kernel adatszerkezetek nagy része, illetve a rendszerhívások kezelési algoritmusa is változatlan maradt. A legjelent sebb átalakítást a lemez használatában, a lemezen lév adatszerkezeteken és a szabad blokk allokáción hajtották végre.

Az FFS-nél a korábban látott partíció csoportosítás mellett bevezették a cilinder csoportokat (cylinder groups), ami valahány folytonos cilindert tartalmazott. Ezzel a

kiegészít szervezéssel lehet vé vált, hogy a Unix az egymáshoz tartozó adatokat egy cilinder csoporton tárolja, miáltal minimalizálni lehet a fejmozgást. (Az adatátvitel szempontjából a legjelent sebb id költsége a fej mozgatásnak van.) Ez a kiegészítés újabb metaadatok megjelenését vonta maga után, amiket cilinder csoportonként a csoport elején tárolnak. A s5fs megbízhatósági problémája els sorban abból fakadt, hogy az állományrendszer egészér l életbevágóan fontos információkat tároló szuperblokk csak egy példányban, a boot blokk után került tárolásra. Az FFS-nél a szuperblokkról minden egyes cilinder csoport tartalmaz egy másolatot. Ezek a másolatok úgy vannak elhelyezve a cilinder csoportokban, hogy egyetlen sáv, cilinder vagy lemez sem tartalmazza az összes másolatot, így mechanikai sérülésekkel szemben is kell védelmet biztosít.

Mint azt a x. fejezetben láttuk, a blokkméret meghatározásakor ellentmondó szempontokat kell figyelembe venni. Minél nagyobb blokkokat használunk, annál jobb az adatátviteli sebesség, viszont annál nagyobb a bels tördel dés. Az FFS ezt a problémát töredékek (fragment) alkalmazásával próbálja orvosolni. Egy állomány minden blokkja azonos méret (a minimális blokkméret 4kB), azonban az utolsó blokk tartalmazhat egy vagy több, külön címezhet és allokálható folyamatos töredék blokkot. Meg kell jegyezni, hogy a töredék blokkok maximális száma az állományrendszer létrehozásakor kerül rögzítésre: 1, 2, 4 vagy 8 lehet. Ezzel a struktúrával 4k-s blokkokat és 8 töredékblokkot alkalmazva 512 byte-os alsó határt lehet elérni, ami megegyezik a szektormérettel. A nagyobb blokkméret alkalmazásának egy járulékos el nye, hogy 232 byte (4GB) méret állományokat is két indirekciós szinten

I. UNIX

72

lehet címezni. Az FFS általában ebb l kifolyólag nem is alkalmazza a háromszoros indirekt blokkokat. A lemezblokk töredékek használatára érvényes néhány korlátozás: Egy állomány blokknak egyetlen lemez blokkban kell lennie. Szomszédos lemezblokkok összefügg töredékei nem vonhatók össze. Továbbá, ha egy állomány utolsó blokkja több töredéket is tartalmaz, ezen töredékeknek összefügg eknek kell lenniük és azonos lemezblokkon kell elhelyezkedniük. Ezen adatszerkezet csökkenti a lemez tördel dését, használatához azonban módosítani kell a szabad lemezblokkok nyilvántartását: a listát le kell cserélni az összes töredék blokkot nyilvántartó bittérképre. A többlet adminisztráció mellett bizonyos esetekben adatok átmásolására is szükség van. Amikor például egy olyan állományt próbálunk meg növelni, amelynek utolsó blokkja egyetlen töredéket foglal el, és ugyanazon blokk többi töredéke más állományokhoz tartozik, akkor el ször allokálni kell egy új blokkot, ami több szabad töredéket tartalmaz, majd a töredéket át kell másolni. Lassan, kis lépésekben b vül állomány esetén számos ilyen másolásra lehet szükség. Ebb l adódóan a jobb hatékonyság érdekében az alkalmazások, amikor csak lehetséges, teljes blokkokat kell, hogy az állományba írjanak.

(1) Lemezblokk allokációs politika

Az FFS lemezblokk allokációs politikájának célja, hogy az egymáshoz kapcsolódó információkat egy helyen tárolja, és a szekvenciális hozzáférésre optimalizálja az allokációt. A s5fs-nél láttuk, hogy listában tárolja a szabad blokkokat és inode-okat. Bár kezdetben ezek lemezelfordulás szempontjából optimalizáltak voltak, a használat során teljesen

véletlenszer vé válnak, gyakorlatilag az operációs rendszernek semmilyen befolyása sincs az allokálandó adatblokk vagy inode elhelyezkedésére. Ezzel szemben az FFS itt is a cilinder csoportokat alkalmazza. Az alábbiakban a teljesség igénye nélkül felsorolunk néhány szempontot, amit az FFS az allokáció során figyelembe vesz.

Az FFS az egy könyvtárban lév

állományok inode-ját megkísérli ugyanarra a cilinder

csoportra helyezni. Ennek ésszer magyarázata, hogy számos parancs, mint pl az ls is, gyors egymásutánban olvassa a könyvtár inode-jait, így ha azok egy cilinder csoporton helyezkednek el, a fejmozgások csökkenthet k.

I. UNIX

73

Minden új könyvtárat más cilindercsoportra helyez, hogy az adatokat egyenletesen terítse szét a lemezen. Egy állományhoz tartozó adatblokkokat megpróbálja ugyanarra a cilinder csoportra helyezni, ahol az állomány inode-ja is található, hisz tipikusan az inode-ot és az adatokat együtt használja. A nagy állományokat ,,szétkeni" a cilindercsoportokon. Amikor az állományméret eléri a 48kB-ot, új cilindercsoportra lép, majd 1MB után újra, stb. Ezzel meg tudja akadályozni, hogy egy óriási állomány feltöltse a teljes cilinder csoportot. A 48Kb-os határ a direkt blokkokon tárolható méretet jelöli (az FFS-nél 12 db direkt blokk található az inode-ban), így a direkt blokkokban tárolt adatok azonos cilinder csoportra kerülnek az inode-dal. Az egymást követ blokkokat ­ amennyiben az lehetséges ­ lemezelfordulás szerint

optimálisan allokálja.

(2) Funkcionális b vítések a s5fs-hez képest

Hosszú állománynevek

Mint azt láttuk, a 16 bájtos könyvtár bejegyzés miatt a s5fs-nél a maximális állománynév 14 karakter lehetett. Ez a mai alkalmazásoknál elég húsbavágó korlátozást jelent, így az FFS megalkotói egy eltér könyvtárszerkezetet dolgoztak ki, ami feloldja ezt a korlátozást. A könyvtár bejegyzés egy rögzített és egy változó részb l áll. A rögzített rész tartalmazza az inode számát, az allokált területet, illetve, hogy ebb l a területb l maga az állománynév mennyit foglal le. A rögzített részt követi a változó hosszúságú rész, ami a null karakterrel lezárt állománynevet tartalmazza, négy byte-os margóra igazítva. (lásd a VI.3.9. ábrát). Ebben az esetben a maximális állománynév hossz 255 karakter. Egy probléma merül fel ezzel a szerkezettel kapcsolatban: mit kell tenni, ha egy könyvtár bejegyzést törlünk? Ekkor a rendszer a törölt bejegyzés területét hozzáolvasztja az el z bejegyzés területéhez, a változást feltüntetve az allokált terület nagyságában (lásd a VI.3.9. ábra jobb oldalát).

I. UNIX

74

13 4 2 'a' '1' 0 0 52 12 9 'a' 'l' 'l' 'o' 'm' 'a' 'n' 'y' '2' 0 0 0

inode szám allokált méret ebb l a név hossza a név és helytölt nullák

13 28 2 'a' '1' 0 0 0000 0000 0000 0000 0000 0000 0000

VI.3.9. ábra: Az FFS könyvtárszerkezete

Egyéb b vítések

Az FFS vezette be a szimbolikus link fogalmát. A szimbolikus linkek kiküszöbölik a hard linkek számos korlátját. A szimbolikus link tulajdonképpen egy olyan speciális állomány, ami egy másik állományra, az ún. célállományra mutat. A szimbolikus linket az inode típus mez je alapján lehet felismerni, és tulajdonképpen csak a cél állomány elérési útját tartalmazza.

Továbbá az FFS bevezette a kvóta mechanizmust, amivel korlátozni lehet az egyes felhasználók rendelkezésére álló állományrendszer er forrásokat.

(3) Az FFS teljesítménye

Az FFS teljesítménye jelent sen túlszárnyalja a s5fs teljesítményét. Mérések szerint a s5fs olvasás esetén a megközelít leg 30 Kb/s-os átbocsátóképességét (1Kb-os blokkok használata

I. UNIX

75

mellett) az FFS megközelít leg 220 Kb/s-ra javította (4Kb-os blokkokat és 1Kb-os töredék blokkokat alkalmazva). A CPU kihasználtság is jelent sen növekedett: a s5fs körülbelüli 1%os kihasználtságát sikerült majd megnégyszerezni. Írás esetén az eltérés nem ennyire domináns, de ott is jelent s.

I.3.6.3. Az állományrendszerek megvalósításának újabb megközelítése

A korai Unix rendszerek azt a filozófiát követték, hogy egy rendszerben csak egyetlen állományrendszer létezik. Ebben a megközelítésben az állományok leírására elégséges volt az inode absztrakció. Hamar felismerték azonban, hogy ez a korlátozás indokolatlan, több állományrendszer (beleértve a több típust is) számos el nnyel kecsegtet. A megvalósításához azonban már nem elegend k az inode-ok. Az új leíró adatszerkezet a virtuális csomópont (vnode) és a virtuális állományrendszer (vfs).

Az új absztrakció bevezetésének célja:

egyszerre támogasson több állományrendszert (Unix, nem Unix) különböz diszk partíciók tartalmazhassanak különböz állományrendszert, viszont csatlakoztatás (mount) esetén egységes "képet" kell hogy mutassanak. támogassa a hálózaton történ állományok osztott használatát modulárisan b víthet legyen

Az absztrakciót tulajdonképpen két adatszerkezet a vnode és a vfs, illetve azok kezelési módja valósítja meg. El ször vizsgáljuk meg az inode szerepét átvev vnode-ot. A VI.3.10. ábra mutatja a vnode szerkezetét. Mint az az ábrán jól látható, az adatszerkezet három részre tagolódik: az adatmez kre, a virtuális függvényekre valamint a segédrutinokra, és makrókra. Az adatmez k egyes elemei töltik be az inode megfelel funkcióinak a szerepét: megjelenik típus mez (v_type), ami a vnode által leírt állomány típusát adja meg, található itt

hivatkozásszámláló (v_count), mount információ (v_vfsmountedhere), stb. Ezen felül megtalálható itt két mutató (v_data, v_op), amelyek implementációfügg valódi, a

virtuális csomópont által elfedett adatszerkezetekre mutatnak, amelyekre a konkrét

I. UNIX

76

állományrendszerek kezeléséhez, karbantartásához van szükség. A v_data mez

s5fs

esetén pontosan egy inode-ra mutat. A v_op mez által mutatott táblában pedig a valódi adatszerkezeteken az absztrakt állománym veleteket konkrétan végrehajtó függvények címei találhatók. A vnode-ban megtalálható virtuális függvények szerepe, hogy az állomány m veleteket konkrét állományrendszer implementációtól függetlenül ki lehessen adni és majd a vnode kezel mechanizmusa gondoskodik róla, hogy az adott absztrakt m veletet megvalósító

konkrét, az adott állományrendszerhez tartozó állománym velet hajtódjon végre. Ehhez a vnode absztrakció definiál egy m velet halmazt (állomány megnyitás, olvasás, írás, stb.) amelyeket minden konkrét állományrendszer implementációban meg kell valósítani. Így egy indexelési és mutató indirekción keresztül el lehet jutni a konkrét m veletet megvalósító függvényhez.

adatmez k (struct vnode) v_countv_data v_typev_op v_vfsmountedhere

állományrendszer függ privát adat pl. az inode s5fs, ufs esetén

a vnodeops állományrendszer függ implementációja

virtuális függvények (struct vnodeops) vop_openvop_lookup vop_readvop_mkdir vop_getaddr ...

segédrutinok, makrók vn_openVN_HOLD vn_linkVN_RELE ...

VI.3.10. ábra: A vnode szerkezete

A vnode használatával a korábban látott kett s indirekció (folyamatonkénti állományleíró tábla, globális állománytábla bejegyzés, inode tábla bejegyzés) egy újabb elemmel b vül (lásd a VI.3.11. ábrát):

I. UNIX

77

folyamatonkénti állományleíró tábla bejegyzés fd globális állománytábla bejegyzés struct file open mode flag vnode ptr ... offs ptr vnode tábla bejegyzés struct vnode v_countv_data v_typev_op v_vfsmountedhere inode tábla bejegyzés inode (s5fs)

VI.3.11. ábra: A vnode-ot is tartalmazó állományrendszer hozzáférés logikai sémája

A virtuális állományrendszer megvalósításához egy, a vnode-hoz hasonló adatszerkezetet, a vfs-t használják. Ennek felhasználásával több eltér típusú állományrendszert egységesen lehet kezelni az alábbi módon (lásd a VI.3.12. ábrát):

root vfs

struct vfs (root fs) vfs_next vfs_nodecovered ...

struct vfs (mounted fs) vfs_next vfs_nodecovered ...

struct vnode (a / vnode-ja)

struct vnode

struct vnode (a felmountolt állományrendszer / vnode-ja) VROOT v_vfsp v_vfsmountedhere

VROOT v_vfsp v_vfsmountedher

v_vfsp v_vfsmountedhere

VI.3.12. ábra: Több állományrendszer használata vfs-sel

I. UNIX

78

Az ábrán jól látszik, hogy van egy root állományrendszer, amire a többi állományrendszert csatlakoztatni lehet (fel lehet mount-olni). A rendszer minden egyes állományrendszer típushoz tartalmaz egy vfs struktúrát, ami tárolja az állományrendszerhez kapcsolódó, az állományrendszer kezeléséhez elengedhetetlen információkat. Továbbá minden egyes olyan virtuális csomópontban (vnode), amely egyben egy állományrendszer gyökér csomópontja, a VROOT jelz bit be van billentve.

I.3.6.4. Speciális állományrendszerek

Az s5fs és az FFS állományrendszer a UNIX általános célú lokális állományrendszerei. Amennyiben az állományrendszernek távoli hozzáférést is támogatnia kell, akkor a kialakítását ezekhez az igényekhez kell alakítani. A távoli állományrendszerekkel az V.4.2 fejezet foglalkozik.

A továbbiakban vázlatosan ismertetünk néhány speciális állományrendszert, amelyek egy-egy adott speciális igényt szolgálnak ki, a felépítésük ezekhez az igényekhez alkalmazkodott.

(1) Ideiglenes állományrendszer

Számos program - f ként a fordítóprogramok és az ablakkezel k - nagyon kiterjedten használ ideiglenes állományokat (temporary files) közbüls eredményeik, állapotuk tárolására.

Ezekre az állományokra az alkalmazás befejez dése után már nincs szükség, nem kell túlélniük egy rendszer összeomlást. Ezen állományok létrehozásának, hozzáférésének és törlésének a használatukból adódóan gyorsnak kell lennie. Már a korai rendszerekben is a kernel az ideiglenes állományok helyett a memóriában található blokk buffer cache-be írt, így késleltetve a valódi állományba írást. Ezzel a hozzáférés jelent sen gyorsult, azonban az állomány létrehozása és törlése a többszöri szinkron lemezhozzáférés miatt még mindig felettébb lassúnak számított. Ezt a problémát a RAM diszkek alkalmazásával küszöbölték ki. Mivel ekkor az adatok a fizikai memóriában kerültek tárolásra, így a hozzáférések jelent sen felgyorsultak. A RAM

I. UNIX

79

diszk nagy sebessége azonban nem igazán tudja kompenzálni azt a kellemetlen tulajdonságát, hogy nagyon pazarlóan bánik a globális er forrásokkal, vagyis els sorban a memóriával. A rendszer m ködése során változóak az igények az ideiglenes állományrendszerrel szemben, sajnos azonban a RAM diszk számára fenntartott memóriát a rendszer külön kezeli, így azt kisebb igények esetén sem lehet más célra felhasználni. A Memória Állományrendszer (Memory File System - mfs) ezt a problémát próbálta orvosolni. Az állományrendszert egy folyamat, méghozzá az állományrendszert csatlakoztató (mount-oló) folyamat virtuális címtartományában építették fel. Mivel az állományrendszer egy folyamat virtuális címtartományában van, így a standard memóriakezel

mechanizmusokkal éppúgy ki lehet lapozni háttértárra, mint bármilyen más adatot. Mivel ebben a megvalósításban egy külön folyamat kezelt minden B/K m veletet, így mindig két környezetváltásra van szükség. Ezzel szemben a teljesen kernelben megvalósított, elterjedten használt tmpfs nem használ külön B/K szervert, így elkerüli a felesleges környezetváltásokat. Mivel a metaadatokat nem kilapozható memóriában tárolja, így számos memória-memória másolást és néhány lemezm veletet is el lehet kerülni. Ezen felül, mivel támogatja a memória leképzést, így gyorsan és közvetlenül is hozzá lehet férni az állomány adatokhoz.

A specfs állományrendszer a felhasználók számára láthatatlan módon egységes interfészt biztosít a készülék állományokhoz, ami jelent sen megkönnyíti a készülékek kezelését.

(2) A /proc állományrendszer

A /proc állományrendszer elegáns és hatékony interfészt biztosít minden folyamat címteréhez. Eredetileg a hibakeresés támogatására dolgozták ki (hogy leváltsa a kényelmetlenül használható ptrace funkciót), azonban egy általános interfésszé n tte ki magát a folyamat modellhez. A megközelítés nagy el nye, hogy a standard állományrendszer interfész segítségével a felhasználók folyamatok címteréb l olvashatnak és módosíthatják azt. A jogosultságokat a közönséges állományoknál megszokott jogosultságkezelési

mechanizmussal lehet szabályozni. Az állományrendszer bevezetésekor minden egyes folyamathoz egy-egy bejegyzés tartozott a /proc könyvtárban. A bejegyzések nevei megegyeztek a folyamat azonosítókkal. A kés bbiek folyamán finomították a modellt és

I. UNIX

80

minden folyamatot egy könyvtár jelölt a /proc könyvtárban, aminek a neve továbbra is a folyamat azonosítója maradt. A könyvtáron belül a logikailag eltér funkciókhoz egy-egy külön állomány jelent meg, mint pl. a folyamat állapotát, a virtuális címtérképét, jelzés információkat, stb. leíró állományok.

(3) A Processzor állományrendszer

A processzor állományrendszert a többprocesszoros környezet és az ezekhez alkalmazkodó operációs rendszerek hívták életre. Az állományrendszer egy interfészt biztosít egy többprocesszoros számítógép egyes processzoraihoz. A /system/processor könyvtárra mountolódik fel és a rendszer minden processzorához tartalmaz egy állományt. Az állomány a processzorral kapcsolatos legfontosabb információkat tartalmazza, mint például a CPU típusa, a CPU sebessége, a cache mérete, a hozzá kapcsolódó speciális berendezések, stb.

I.3.6.5. Modern állományrendszerek

Az operációs rendszerek tervezésekor figyelembe veszik a hardver adottságokat, maximálisan megpróbálják kiaknázni a bennük rejl lehet ségeket, illetve a fejlesztés során hozott

döntések magukon viselik az adottságok hatását. A Unix kialakulásakor a tervezési döntéseket er sen befolyásolta, hogy a korai 80-as években viszonylag kis memóriára, lassú processzorra és relatíve gyors lemezegységekre kellett alapozni a tervezést. Id közben a hardver fejlesztés eltér léptékben haladt el re, a memória mérete jelent sen megn tt, a CPU sebessége közel három, míg a memória mérete közel két nagyságrenddel megnövekedett, ezzel szemben bár mérete jelent sen n tt, a lemezegység sebessége alig duplázódott meg. Ebb l adódóan a Unix bels szerkezete szempontjából megváltozott hardver feltételek miatt számos tervezési döntés elvesztette létjogosultságát, azokat az új feltételeknek megfelel en újra át kellett gondolni.

A lemezegység sebességének lassú növekedése els sorban az állományrendszert érinti hátrányosan. A hagyományos állományrendszereket a mai számítógépeken használva er sen B/K korlátozott rendszerek jönnek létre, ami gátolja a jelent s CPU sebességnövekedés kiaknázását.

I. UNIX

81

A sebesség problémák kiküszöbölésére számos modern állományrendszer alkalmazza az úgynevezett naplózási (journaling vagy log) technikát. A megközelítés lényege, hogy minden állományrendszer változást a rendszer egy csak hozzáf zhet állományba naplóz, vagyis az egész állományrendszer tulajdonképp egy hatalmas napló állomány. A naplót a rendszer szekvenciálisan írja, nagy darabokban, ami jelent sen javítja a lemezkihasználtságot és a teljesítményt. Továbbá egy rendszer összeomlás után a napló állománynak csak a végét kell vizsgálni, ami a felépülést jelent sen felgyorsíthatja.

Egy naplózó állományrendszer tervezésénél is számos döntést kell meghozni. Ezek közül az alábbiakban a teljesség igénye nélkül vázoljuk a legfontosabbakat.

Mit írjunk a napló állományba M veletek vagy értékek Kiegészít állományrendszerként alkalmazzuk, vagy cseréljük le a korábbi

állományrendszert A változtatásokat újra lejátszva (REDO) vagy a legutóbbi változtatásokat visszavonva (UNDO) Szemétgy jtési stratégia Csoport véglegesítés (commit) Adat visszakeresés

A hely sz ke miatt itt nem tárgyaljuk részletesen az implementációt, csak felhívjuk a figyelmet a napló alapú állományrendszer alkalmazásának néhány nyilvánvaló el nyös tulajdonságára, illetve a megoldandó problémákra.

Az el nyök eléggé szembeötl k. Mivel mindig a napló állomány végére írunk, így az írás mindig szekvenciális és nincs szükség fejmozgatásra. A naplóba írás során egyszerre mindig nagy mennyiség adatot írunk, tipikusan egy egész sávot, ebb l adódóan nem kell elfordulás alapján optimalizálni, illetve a lemezegység teljes sávszélességét ki lehet használni. Egy m velet minden adat összetev jét (metaadatot és valódi adatot) össze lehet fogni egyetlen

I. UNIX

82

atomikusan

végrehajtott

írásba,

ami

jelent sen

növelheti

az

állományrendszer

megbízhatóságát. Az írás tehát nem okoz problémát. Viszont a rendszer hatékonysága szempontjából nagy gondot kell fektetni az adat visszakeresés problémájára. Az adatokat a hagyományos módszerrel (állandó helyen tárolt szuperblokk, inode, stb.) már nem lehet kezelni, a napló állományban keresést kell végrehajtani. Ezt a keresést jelent sen támogatja a memóriában történ cache-elés, ami a mai memória méretek mellett nem jelent problémát. Ett l függetlenül az állomány szerkezetének támogatni kell a napló állományban történ keresést, mert enélkül a rendszer használati értéke jelent sen csökken.

Számos napló alapú rendszert dolgoztak ki, mint például a 4.4BSD napló alapú állományrendszere, metaadat naplózó rendszerek, az Episode állományrendszer. Ezeket részletesen az irodalomjegyzékben felsorolt források tárgyalják.

I.3.7. Teljes folyamatok háttértárra írása (swapping)

A korai Unix rendszerekben a virtuális memóriakezelést teljes folyamatok háttértárra írásával oldották meg (swapping rendszerek). Ennek történeti okai vannak: az els Unix rendszerek PDP-11-en futottak, ahol a folyamatokra 64K-s memóriakorlát volt kiszabva. Ilyen kis méret folyamatokat viszonylag gyorsan ki lehetett írni háttértárra. Nagy folyamatok esetén (manapság egy-egy folyamat virtuális memória méretére nincs elvi korlátozás, gyakoriak a több Mbyte-os folyamatok) a háttértárra írás id igényes, így önmagában, egyedüli módszerként nem használatos, azt egy igény szerinti lapozási technikával ötvözve alkalmazzák. Bár a teljes folyamatok háttértárra írása (tárcsere) veszített a jelent ségéb l, a modern rendszerek is alkalmazzák, hogy gyorsan orvosolják a leterhelt rendszereknél gyakran jelentkez er forrás sz ke okozta hatékonysági problémákat. A továbbiakban áttekintjük, hogy a tárcsere rendszer megvalósítása milyen feladatokat ró az operációs rendszerre, és hogy ezeket a feladatokat hogyan oldják meg.

I. UNIX

83

A swapping rendszerekben három, logikailag elkülönül feladatot kell megoldani:

a háttértár kezelését (swap device) folyamatok háttértárra írását folyamatok háttértárról memóriába történ beolvasását.

A továbbiakban ezeket a feladatokat tárgyaljuk.

I.3.7.1. A háttértár szervezése

A háttértár (swap device) egy blokkos eszköz, általában merevlemez. Ellentétben a Unix állományrendszerrel (amely egy lépésben egy blokkot foglal le), a háttértárra íráskor a rendszer a folyamatoknak összefügg blokkcsoportot foglal. Ez, persze a rendelkezésre álló terület tördel déséhez (fragmentation) vezet, de ebben az esetben ez nem jelent olyan nagy problémát, mert a háttértáron a folyamatok csak ideiglenesen tartózkodnak, onnan id r lid re bekerülnek a memóriába, és ekkor a háttértáron használt terület felszabadul. A tördel désnél fontosabb, kritikus probléma a háttértárra írás sebessége. Folyamatok háttértárra írása és onnan történ beolvasása nagyon gyakori esemény volt a korai rendszerek m ködése során, így a m veletek sebessége valóban létfontosságú volt. Az is maradt mindmáig, mert a gyakoriság ugyan csökkent, de a processzor és a háttértár közötti sebességkülönbség jelent sen növekedett. A rendszer a háttértáron rendelkezésre álló szabad területeket egy memóriában tárolt táblával (ún. map-pal) tartja nyilván. A map szerkezete egyszer : a bejegyzések (cím, szabad blokkok száma) alakú rendezett párok. Itt a cím a háttértár blokk relatív címe a swapping területen (a logikai swap device-on ­ a számozás 1-gyel kezd dik). A táblát a rendszer mindig a lehet legtömörebben tartja, felesleges bejegyzést nem tartalmaz. Például, feltételezve egy 100000 blokkot tartalmazó háttértárat, azt a pillanatot, amikor a teljes háttértár üres, vagyis minden blokk szabad, az alábbi ábrán látható map írja le.

I. UNIX

84

Szabad terület kezd címe

Az összefügg szabad terület mérete (blokkokban) 1 100000

A map egy dinamikusan b vül illetve sz kül szerkezet, vagyis m ködés közben a táblába új sorok szúródnak be, illetve sorok törl dnek. Mivel a gyorsaság a legfontosabb tervezési szempont a háttértár kezelésében, ezért a foglalási stratégia is ezt tükrözi: a stratégia first-fit, vagyis az els megfelel méret területet használja fel a rendszer. A map struktúráját

végiggondolva jól látható, hogy az a first-fit stratégiát támogatja.

I.3.7.2. A háttértár foglalási és felszabadítási algoritmus

A háttértár foglalása és felszabadítása során a kernel megpróbálja a map-ot a lehet legtömörebben tartani. Foglaláskor, ha egy teljes map bejegyzést foglalunk, akkor a kernel törli a bejegyzést (nem hagy meg 0 méret bejegyzést). Felszabadításkor a kernel

megvizsgálja, hogy a felszabadított terület pontosan beilleszkedik-e két map bejegyzés közé. Amennyiben igen, akkor a nagyobb index bejegyzést törli, és az alacsonyabb index

bejegyzés által megadott szabad blokkok számát úgy módosítja, hogy az lefedje a kisebb index bejegyzés, a felszabadított terület és a nagyobb index bejegyzés szabad blokkjait. Amennyiben a felszabadított terület nem tölt ki teljesen egy "lyukat" a map táblában, a kernel megvizsgálja, hogy a felszabadított terület illeszkedik-e valamelyik korábbi bejegyzéshez (egy korábbi map bejegyzéshez a felszabadított terület alulról vagy felülr l illeszkedhet). Amennyiben igen, módosítja a már meglév bejegyzést. Amennyiben a felszabadított terület egyetlen bejegyzéshez sem illeszkedik, akkor a kernel új bejegyzést hoz létre.

A korai Unix rendszerekben csak egy háttértár volt, manapság már a kernel több swap berendezést is használhat. Ezeket a rendszer konfigurálásakor a rendszergazda adja meg. Amennyiben több swap berendezés is van, a kernel azokat round-robin stratégiával használja.

I. UNIX

85

I.3.7.3. Folyamatok háttértárra írása
Az operációs rendszer m ködése során négy esetben lehet szükség folyamatok háttértárra írására:

a kernel fork rendszerhívást hajt végre ­ új folyamatot hoz létre, és nincs elég memória a kernel (s)brk rendszerhívást hajt végre ­ vagyis memória tartományt b vít a verem dinamikusan b vül a kernel átütemez (korábban háttértárra írt folyamatnak kell a hely)

Tárcserénél (1­ 3) a kernel zárolja az érintett folyamatokat, hogy a swapper (0-ás folyamat) menet közben háttértárra ne írja. A memória objektumok éppúgy, mint az állománykezeléshez tartozó adatszerkezetek, hivatkozásszámlálóval rendelkeznek, ami megmondja, hogy egy adott id pontban az objektumot hányan használják. Amikor a swapper egy tartományt háttértárra akar írni, csökkenti eggyel a tartomány hivatkozás számlálóját, és ha az 0-ra csökken, ki is írja. Itt gondoljunk az osztottan használt tartományokra (shared memory regions), ahol egy tartományt egyszerre több folyamat is használ. Ekkor a tartomány hivatkozás-számlálója a tartományt használó folyamatok számával egyezik meg. Amikor a swapper úgy dönt, hogy egy folyamatot háttértárolóra ír, a folyamat azon tartományait, amelyeket más folyamat is használ, nem szabadíthatja fel! Amikor a kernel egy tartományt kiír a háttértárra, akkor a tartomány háttértáron elfoglalt címét beírja a tartomány táblába (region table).

A folyamatok virtuális címtartománya ,,hézagos", ritka, vagyis a folyamatok általában nem használják a teljes virtuális címtartományukat. A kód-, adat- és verem tartományok általában nem összefügg k (már csak azért sem, hogy azok dinamikusan növekedhessenek). Ebb l adódóan a swapper nem írja ki a folyamat teljes virtuális címtartományát a háttértárra, hisz az felesleges és pazarló lenne, hanem csak a valójában használt (fizikai címmel rendelkez ) címtartományokat menti el (lásd a VI.3.13. ábrát).

I. UNIX

86

A folyamat memória képe virtuális cím fizikai cím 0K381K kód 1K165K üres

Háttértár blokk index 681 682 683 684 685 686

A folyamat memória képe virtuális cím fizikai cím 0K111K 1K615K üres kód

. lyuk . . 64K415K
. adat 65K573K 66K631K üres

. lyuk . . 64K333K
. 65K253K 66K689K üres

adat

verem

. lyuk . . 128K331K
. üres

. lyuk . . 128K174K
. üres

verem

VI.3.13. ábra: Folyamat háttértárra írása és visszatöltése

A VI.3.13. ábrán jól látszik, hogy a folyamatban csak hat laphoz tartozik fizikai memória, így a háttértárra csak ez a hat lap íródik ki. A tartománytáblában tárolódnak a virtuális címek az egyes tartományokhoz, így amikor a folyamat visszatölt dik a memóriába, bár a fizikai címek megváltozhatnak, a virtuális címek (vagyis a folyamat memóriaképe) nem változnak (lásd a VI.3.13. ábra jobb oldalát).

(1) Háttértárra írás fork rendszerhívás esetén

A fork rendszerhíváskor két helyzet állhat el :

1. van memória a gyermek folyamat létrehozásához (ekkor nem kell semmit sem háttértárra írni) 2. nincs elég memória a gyermek folyamat létrehozásához

A második esetben a swapper kiírja háttértárra a szül memóriaképét (ez lesz majd a gyermek memóriaképe), de a hozzá tartozó fizikai memóriát nem szabadítja fel, a szül a memóriában

I. UNIX

87

marad. Ezek után a swapper futásra késszé teszi a gyermeket a háttértáron. Mivel a háttértáron lév futásra kész folyamatokat el bb-utóbb a swapper betölti, így a gyermek folyamat is bekerül majd a memóriába. Majd az ütemez valamikor futásra ütemezi, amikor majd befejez dik a gyermekben is a fork hívás, majd a gyermek folyamat user módba vált.

(2) Tartomány növelés

Ez az eset akkor áll el , amikor egy memóriában lév folyamat valamelyik tartományának a méretét szeretné növelni, de nem áll rendelkezésre fizikai memória. Leggyakoribb eset, hogy a verem méretét szeretné növelni a kernel. A tartományok méretének növelését az (s)brk rendszerhívásokkal lehet megtenni. (A brk hívás adott memóriacímre állítja az adott tartományhoz tartozó legmagasabb memóriacímet, míg az sbrk adott mérettel b víti a tartományt.) Amennyiben a rendszerhívás idején rendelkezésre áll a kívánt memória, a rendszerhívás lefut, lefoglalva a megfelel méret memóriát. Amennyiben nincs elég

memória, a kernel a virtuális címtartományban elvégzi a címleképezést, de nem foglal az új memóriaterülethez fizikai memóriát, hanem a folyamatot kiírja a háttértárra és futásra késszé teszi. (A háttértáron megjelenik a memórianövelés el tti memóriakép, valamint a lefoglalt új memóriatartomány is, amelyet a kernel a háttértáron kinulláz ­ lásd a VI.3.14. ábrát.) Amikor legközelebb a swapper betölti a folyamatot, a kernel az új virtuális címtartományhoz is allokál fizikai memóriát, így a folyamat ,,megnövekedett" memóriával fut tovább. (A folyamat nem veszi észre, hogy futása megszakadt, és háttértáron töltött valamennyi id t ­ ez ütemezés miatt is el fordulhatott volna.)

I. UNIX

88

A folyamat memória képe virtuális cím fizikai cím kód 0K381K 1K165K üres

Háttértár blokk index 681 682 683 684 685 686 687

A folyamat memória képe virtuális cím fizikai cím 0K111K 1K615K üres kód

. . lyuk . . 64K415K
adat 65K573K 66K631K üres

. lyuk . . 64K333K
. 65K253K 66K689K üres adat

. lyuk . . 128K331K
. verem 129K­ üres

. lyuk . . 128K174K
. 129K444K üres verem

VI.3.14. ábra: Tartományb vítés háttértárra írással

(3) Folyamatok betöltése

A swapper folyamat mindig kernel módban fut, nem ad ki rendszerhívásokat, hanem közvetlenül meghívja a kernel rutinokat. Végtelen ciklusban dolgozik, folyamatokat próbál meg memóriába tölteni, illetve memóriából háttértárra írni. Amikor nem tud mit csinálni, alszik. A swapper nem kitüntetett folyamat, ugyanúgy fut, mint bármely más folyamat, csak magasabb a prioritása.

A swapper m ködési fázisai:

ha nincs a háttértáron futásra kész folyamat, a swapper alszik ha van, de a rendszerben nincs memória, megpróbál folyamat(okat) háttértárra írni, és kezdi elölr l a futásra kész folyamatok keresését a háttértáron.

I. UNIX

89

Itt fontos megjegyezni, hogy a swapper zombi folyamatot sohasem ír ki háttértárra, hiszen a zombi folyamatok csak folyamattábla bejegyzést foglalnak, fizikai memóriát nem.

I.3.7.4. A háttértárra írás, illetve a háttértárról való beolvasás szabályai

A swapper néhány egyszer szabályt alkalmaz annak eldöntésére, hogy mely folyamatok alkalmasak háttértárra történ kiírásra, illetve háttértárból történ beolvasásra. Ezen szabályok a következ k: a folyamat memóriába tölthet , ha már legalább 2 másodpercet2 háttértáron töltött a folyamat háttértárra írható, ha már legalább 2 másodpercet3 memóriában töltött

· ·

Az óra minden másodpercben felébreszti a swappert. Mivel a swapper nagy prioritású folyamat, minden másodpercben fut is. Fontos tulajdonsága a háttértárba író algoritmusnak, hogy amikor egy folyamat sleep rendszerhívást ad ki, akkor az algoritmus elölr l indul, hiszen valószín leg érdemesebb az épp ,,elalvó" folyamatot a háttértárra írni.

I.3.7.5. A háttértárra kiírandó folyamat kiválasztásával kapcsolatos problémák

A folyamatokat a swapper azért írja ki háttértárra, hogy helyet csináljon a betöltend folyamatoknak. A folyamatok kiválasztásakor azonban az alábbiakat figyelembe kell venni:

·

lehet, hogy a kiírt folyamat kicsi, továbbra sem lesz elég hely a memóriában ahhoz, hogy egy másik folyamatot betöltsön a swapper (pl. ha kiír egy 2K-s folyamatot, az nem fog elég helyet biztosítani egy 1M-s folyamatnak) Erre a problémára megoldást jelenthet, ha a swapper folyamatcsoportokat ír ki háttértárra, amelyeknek összes memóriafoglalása már elég lesz a betöltend folyamat számára.

2 3

A fent említett konstans rendszerspecifikus. A fent említett konstans rendszerspecifikus.

I. UNIX

90

·

Ha a swapper azért alszik, mert nem volt elég memória, akkor ébredéskor újra kezdi az egész algoritmust. Ebb l fakadóan egy korábban várakozó folyamat lehet, hogy ismét nem jut be a memóriába, mert id közben egy másik folyamatot fontosabb lett betölteni.

·

Amennyiben egy futásra kész folyamatot ír ki, el fordulhat, hogy az a folyamat még nem is futott (prioritás, nice)

Egy érdekes elvi problémára fel kell itt figyelni: szerencsétlen körülmények között holtpont is kialakulhat. Ennek feltételei:

nincs hely a háttértáron a memóriában minden folyamat alszik minden futásra kész folyamat a háttértáron van nincs elég hely a memóriában, hogy a swapper a háttértárból egy futásra kész folyamatot memóriába töltsön

Szerencsére, ezen állapot kialakulásának kicsi az esélye.

I.3.8. Igény szerinti lapozás

Az operációs rendszer egyik els dleges feladata, hogy a rendszer memória er forrásait hatékonyan kezelje. Ezen feladat ellátására az operációs rendszerben a memóriakezel rendszer egy alrendszert alkot. A memóriakezel rendszerrel szemben természetes elvárás, hogy segítségével a fizikai memória méreténél nagyobb programokat lehessen futtatni, csak részben memóriában lév programok is futtathatók legyenek, a multiprogramozásból adódóan támogatnia kell, hogy egyszerre több program is a memóriában lehessen, támogassa áthelyezhet programok kezelését, a memóriakezelés legyen gépfüggetlen, vegye le a programozó válláról a memória allokációs és menedzselési terheket,

I. UNIX

91

tegye lehet vé az osztott memória használatot.

Ezen feladatok megoldásához egy magas szint

absztrakcióra van szükség: a virtuális

memóriakezelésre (virtual memory). A virtuális memória használata feltételezi, hogy a címtér (address space) a fizikai memóriától független er forrás. Mérések azt mutatják, hogy a memóriakezeléssel kapcsolatos tevékenységek jelent s CPU id t emésztenek fel ­ terhelt rendszeren megközelíti a 10%-ot.

A UNIX, mint azt korábban láttuk, kezdetben csak a folyamatok háttértárra írását (swapping) biztosította. A modern operációs rendszereknek ennél hatékonyabb eszközökre is szükségük van. A 80-as évek közepére már minden UNIX változat az igény szerinti lapozást használta, mint els dleges virtuális memóriakezel technikát. A legújabb rendszerek már el retekint lapozási technikákat (anticipatory paging) is alkalmaznak, amivel a rendszer olyan lapokat is behoz a fizikai memóriába, amikr l úgy hiszi, hogy majd a közeljöv ben szüksége lesz rá.

Mivel a IV.4.2. fejezet már részletesen tárgyalta a virtuális memóriakezelés elvi alapjait, ismertetve a szükséges hardver és szoftver feltételeket, így ebben a fejezetben már nem térünk ki ennek részleteire, hanem a UNIX azon adatszerkezeteit és használatukat ismertetjük, amelyek az igény szerinti lapozás megvalósításához szükségesek. Fogalmi tisztasága miatt a következ kben a SVR3 adatszerkezeteit ismertetjük. A legújabb UNIX rendszerek már egy új, memóriába ágyazott állományokon alapuló virtuális memóriakezel alrendszert alkalmaznak, azonban azok kialakítására nagy hatással volt a SVR3. A tárgyalás végén felhívjuk az olvasó figyelmét a hatékonysági problémákra, és rámutatunk, hogy a kés bbi virtuális memóriakezel alrendszerek hogyan orvosolták ezeket a problémákat.

I.3.8.1. A virtuális memóriakezelést támogató adatszerkezetek

A UNIX az alábbi fontosabb adatszerkezeteket használja memóriakezeléshez:

pfdata (page frame data table): Ez az adatszerkezet a fizikai lapok állapotát írja le. A tartalmazott információkat alább ismertetjük. A rendszer induláskor foglal helyet számára, statikus adatszerkezet.

I. UNIX

92

laptábla bejegyzés (page table entry): Egyrészt tartalmazza a virtuális-fizikai címleképzést, másrészt a memóriakezel funkciók megvalósításához elengedhetetlen jelz biteket tárol. diszk blokk leíró (disk block descriptor): A virtuális memória lapjaihoz tartozó háttértár címeket (a lap háttértáron tárolt másolatának a helyét) adja meg egyéb fontos információkkal együtt. háttértár használat tábla (swap use table): A háttértár használatát adminisztrálja.

A továbbiakban a fenti adatszerkezeteket és használatukat ismertetjük.

A pfdata adatszerkezet

A pfdata a fizikai lapokat írja le, az alábbi információkat tartalmazza:

a lap állapota (háttértáron, végrehajtható állományban található, DMA van folyamatban a lapra, a lap kiadható) hivatkozásszámláló: a lapra hivatkozó folyamatok száma (ez megegyezik az érvényes laptábla hivatkozások számával). Ezen mez támogatja a fizikai memória osztott használatát, illetve a kernel ez alapján tudja eldönteni, hogy egy adott lapot újra ki lehet-e adni. a lapra éppen melyik háttértár blokk van betöltve: a háttértár logikai címe, az azon belüli blokk cím (ez utóbbi jelent ségét a kés bbiekben részletesen tárgyaljuk) mutatók pfdata bejegyzésekre (szabad lista, hash tábla)

A pfdata bejegyzések a háttértár blokk cím szerint hash sorokba vannak rendezve (amennyiben több háttértár is van a rendszerben, akkor a hash kulcsban szerepel a háttértár logikai címe is). Ezáltal gyorsan meg lehet találni a blokk cím alapján egy adott háttértár blokkhoz tartozó lapot a memóriában. Ez javítja a hatékonyságot, ugyanis, ha egy olyan lapra van szükség, ami már bent van a memóriában, akkor azt nem kell ismét betölteni, meg lehet takarítani egy lemezm veletet. Ezen felül a szabad memória lapok egy szabad listára is fel vannak f zve. Amennyiben az operációs rendszer lapot akar foglalni, ezen szabad lista elejér l foglal. Az lenne az ideális, ha a szabad lista elején olyan lapok lennének, amelyekre

I. UNIX

93

már soha sem lesz szükség a kés bbiekben, vagyis ezeknek a lapoknak meg kellene el zni azokat a lapokat, amelyekre esetleg a kés bbiekben szükség lehet. Ha nincsenek ilyen lapok, akkor a lokalitás elvéb l adódóan a legrégebben használt (least recently used) lapokat lenne célszer felhasználni, azokat lenne célszer a szabad lista elején tárolni. Ezzel kapcsolatban felmerül egy gyakorlati probléma: a legrégebben használt sorrend fenntartásához minden egyes laphivatkozás után újra kellene rendezni a listát, aminek id költsége nem megengedhet . Ezért egy ésszer kompromisszummal a legrégebben használt stratégia helyett a régen használt (not recently used) stratégiát alkalmazzák. Ehhez egy hivatkozás bitet rendelnek minden egyes laphoz, ami az adott lapra történ hivatkozáskor beállítódik, illetve adott id közönként törl dik. Bár ez a stratégia nem optimális, garantálja, hogy csak olyan lapok kerüljenek újra kiadásra, amiket az elmúlt id szakban nem használtak. A kés bbiekben ismertetjük, hogy ezt a technikát szimulált hivatkozás bit bevezetésével hogyan lehet megvalósítani olyan architektúrán, ami hardverb l nem támogatja a hivatkozás bitet.

Laptábla bejegyzés

Minden egyes folyamathoz tartozik legalább egy laptábla (page table), aminek a bejegyzései a folyamat címterét képezik le a fizikai memória címeire, illetve további memóriakezeléssel kapcsolatos információkat tárolnak. A laptábla elemei magától értet d en tartalmazzák a fizikai memóriacímeket és a hozzáférési jogosultság biteket. Az igény szerinti lapozás támogatására azonban még az alábbi biteket is nyilván kell tartani (lásd a VI.3.15. ábrát):

érvényességi (valid) hivatkozás (reference) módosítás (modify, dirty) másolás írás esetén (copy on write - C/W) öregítés (age) védelem (protection)

lap fizikai címe

Age

C/W

Mod

Ref

Val

Protection

I. UNIX

94

VI.3.15. ábra: A laptábla bejegyzés által tárolt információk. A bejegyzést a folyamat virtuális címei címzik. Jelölések: Age - öregítés bit(ek), C/W - copy-on-write bit, Mod - módosítás bit, Ref - hivatkozás bit, Val - érvényességi bit, Protection - védelmi bitek

A hivatkozás és módosítás biteket általában a hardver állítja. Léteznek olyan hardverek is, amelyek ezt nem teszik meg. A hivatkozás bit szoftver szimulációját majd a kés bbiekben tárgyaljuk. Az érvényes, C/W, és az öregítés biteket a kernel kezeli.

Diszk blokk leíró és a háttértár használat tábla

A diszk blokk leíró (disk block descriptor) a virtuális memória lapjaihoz tartozó háttértár címeket adja meg. Ehhez tartalmazza a háttértár logikai címét, a lap háttértáron elfoglalt helyét, illetve megadja a lap típusát, vagyis, hogy milyen módon lehet a tárolt másolatot (backing store) elérni (lásd a VI.3.8.16. ábrát). A lap lehet a háttértáron (swap), lehet a memóriában, illetve lehet fill-on-demand típusú, vagyis ha szükség van a lapra, akkor azt egy adott tartalommal fel kell tölteni. Ennek két típusa ismeretes. Fill-from-text esetén a betöltend tárolt másolat egy végrehajtható állományban található. Az ilyen típusú lapok általában kódot vagy inicializált adatot tartalmaznak. Zero-fill esetén nincs tárolt másolat, a kernel a lapot kinullázza, vagyis nullával tölti fel. Az ilyen típusú lapok általában nem inicializált adatot tartalmaznak. A kinullázással a kernel biztosítja, hogy a nem inicializált változók kezdeti értéke nulla legyen.

háttértár logikai címe

blokk sorszám

típus (swap, file, ZF, FT)

VI.3.16. ábra: A diszk blokk leíró által tárolt információk. A bejegyzést a folyamat virtuális címei címzik.

A háttértár használati tábla a háttértár használatát adminisztrálja. Ez az adatszerkezet is tartalmaz egy hivatkozásszámlálót, ami a pfdata hivatkozásszámlálójához hasonló szerepet tölt be. Amikor a kernel fizikai lapot allokál a háttértáron tárolt laphoz (vagyis amikor a lap

I. UNIX

95

betölt dik a fizikai memóriába), a laphoz tartozó pfdata hivatkozásszámláló értékét a háttértár használati tábla hivatkozásszámlálójának az értékére állítja, így a konzisztencia biztosítható.

I.3.8.2. A virtuális memóriakezelést támogató adatszerkezetek használata

A SVR3 a memóriakezeléshez a tartomány (region) modellt alkalmazta. Ennek lényege, hogy a lapszervezés memóriát nagyobb logikai egységenként, tartományonként kezelte.

Egy-egy tartományt rendeltek a folyamatok kód, adat és verem területéhez, illetve egyéb logikai egységeihez. A tartományok a memóriahasználat logikai szerkezetét tükrözik. A VI.3.17. ábra a tartományok és a laptábla bejegyzések, illetve diszk blokk leírók viszonyát mutatja.

>
laptábla bejegyzés tartomány diszk blokk leíró

VI.3.17. ábra: A tartomány modell és a virtuális memóriakezelést támogató adatszerkezetek kapcsolata.

Az ábrán jól látszik, hogy minden tartományhoz tartozik egy laptábla, illetve, hogy a laptábla bejegyzéseket és a diszk blokk leírókat a kernel együtt kezeli (mindkett t a folyamat virtuális címeivel címzi), azok akár egyetlen adatszerkezetet is alkothatnának, azonban eltér funkcionalitásuk miatt és az áttekinthet ség kedvéért célszer azokat külön adatszerkezetbe foglalni.

A virtuális memóriakezelést támogató adatszerkezetek közötti kapcsolat

A korábbi bekezdésekben ismertetett adatszerkezetek között számos kereszthivatkozás található, ami megkönnyíti az operációs rendszer hatékony m ködését. A VI.3.18. ábra ezeket

I. UNIX

96

a kapcsolatokat mutatja. A jobb áttekinthet ség érdekében az ábra egyetlen laptábla bejegyzést és a hozzá kapcsolódó adatelemeket mutatja.

Virtuális cím 1592K

Laptábla bejegyzés 711. lap

Diszkblokk leíró háttértár 2343. blokk

háttértárhasználat tábla hivatkozásszámláló: 1 711-es pfdata bejegyzés hivatkozásszámláló: 1 1. logikai háttértár 711-es fizikai lap 2343. blokk háttértár 2343. blokk

VI.3.18. ábra: A virtuális memóriakezelést támogató adatszerkezetek kereszthivatkozásai.

Mint az a VI.3.18. ábrán jól látszik, mind a laptábla bejegyzést, mind pedig a diszk blokk leírót a folyamat virtuális lapcímével címzik. A laptábla bejegyzésben tárolt fizikai lapcím egyrészt kapcsolatot teremt magával a fizikai lappal, másrészt az adott laphoz tartozó pfdata bejegyzéssel is (a példában ez a 711-es lapkeret). A 711-es lapkeretet (fizikai memória lapot) leíró pfdata bejegyzés természetesen szintén hivatkozik magára a 711-es lapkeretre. Továbbá ugyanezen bejegyzés hivatkozik arra a háttértár blokkra, amely tárolja a virtuális lap tartalmát (ebben az esetben az 1. háttértár 2343-as blokkjára). Ugyanerre a blokkra hivatkozik a diszk blokk leíró és a háttértár használati tábla megfelel bejegyzése is. Els látásra ez a

redundancia tékozlónak t nhet, azonban egy példa hamarosan rávilágít, hogy ezen adatszerkezetek segítségével bizonyos esetekben jelent s hatékonyság növekedést lehet elérni.

A ,,laplopó" folyamat

I. UNIX

97

A ,,laplopó" folyamat (vagy pagedaemon) kernel szint folyamat, inicializáláskor jön létre. Akkor aktivizálódik, amikor a rendelkezésre álló szabad lapok száma egy alsó határ alá csökken, és addig fut, amíg a szabad lapok száma újra egy fels határ fölé nem ér. Erre a két határra azért van szükség, hogy a verg dést (thrashing) elkerülje a rendszer. A lapoknak két állapota lehetséges:

·

a lapot még nem lehet kiírni háttértárra, öregszik (ez tulajdonképpen több állapotot takar, és implementáció függ , hogy a laplopó egy lapot hányszor vizsgál meg kiírás el tt). A laplopó minden egyes vizsgálatnál törli a referencia bitet és öregít.

·

a lap kiírható, újra kiadható

A lapok nem feltétlenül arányosan vannak elosztva a folyamatok között. Egy fontos szabályt mindig betart a laplopó: használatban lév lapot nem lop el. Amikor a laplopó úgy dönt, hogy kiír egy lapot, három eset lehetséges:

· ·

nincs másolat a háttértáron --> ütemezi a lapot kiírásra van másolat, nincs módosítás --> laptábla bejegyzés valid bitjét törli, csökkenti eggyel a pfdata hivatkozásszámlálóját, és a lapot a szabad listára teszi.

·

van másolat, és a memóriakép módosult --> kiírásra ütemezi a lapot, és az éppen használt háttértár helyet felszabadítja (blokkos kiírás)

A háttértár tördel dése jelent s lehet, mert bár a kiírás blokkos, de a felszabadítás, illetve a beolvasás laponkénti. Amikor a kernel kiírja a lapot, törli az érvényességi bitet, és a pfdata hivatkozásszámlálóját eggyel csökkenti. Amennyiben a hivatkozásszámláló 0 lett, akkor a lapot a szabad lista végére teszi.

I.3.8.3. Laphibák

Mint azt korábban láttuk, a címtranszformáció során a memóriakezel egység a virtuális címet szétbontja egy virtuális lapcímre és egy lapon belüli eltolásra. A virtuális lapcím alapján

I. UNIX

98

megkeresi a laphoz tartozó laptábla bejegyzést, amib l kiolvassa a laphoz tartozó fizikai lapcímet. A fizikai lapcímhez hozzáilleszti a lapon belüli eltolást és így el áll a teljes fizikai cím. A címleképzés az alábbi okok miatt hiúsulhat meg:

túlcímzés hiba (bounds error) ­ A kiadott cím kívül esik az adott folyamat által kiadható érvényes címtartományon, ebb l adódóan a címhez nem tartozik laptábla bejegyzés. érvényességi hiba (validity fault) ­ A laphoz tartozik laptábla bejegyzés, azonban a hozzá tartozó érvényességi bit törölve van, ami általában azt jelenti, hogy a laphoz nem tartozik fizikai memória lap. Mint azt majd a kés bbiekben látni fogjuk, a szoftverb l szimulált referencia bit esetén az érvényességi bitet a rendszer felhasználja a szimulációhoz, és a lap akkor is érvényes lehet, ha az érvényességi bitje ki van törölve. védelmi hiba (protection fault) ­ A lap nem engedi meg a kiadott m velet igényelte hozzáférést (például egy csak olvasható lapot nem lehet írni, vagy a felhasználó nem férhet hozzá a kernel lapokhoz). A copy-on-write technikánál is ezt a mechanizmust használja a kernel.

A fent ismertetett hibák minden esetben kivételt (exception) okoznak, amit egy kivételkezel rutin kezel le. Ezeket a kivételeket általánosan laphibának nevezik. A kivételkezel megkapja paraméterként a hibát kiváltó virtuális lapcímet, illetve a hiba típusát is (védelmi vagy érvényességi hiba ­ a határ hiba is érvényességi hibát okoz). A kivételkezel a hiba típusától függ en megpróbálja a megfelel lapot behozni a memóriába vagy egy jelzés

elküldésével értesíti a folyamatot. A hibakezel k általában nem kerülnek alvó állapotba, kivéve ezen hibák kezel it. Ezek aludhatnak, de ezek adott folyamathoz tartoznak. Továbbá a hiba kezelése alatt a tartományt zárolni kell, hogy a laplopó nehogy ellopjon lapokat a tartományból.

I.3.8.4. A laptábla bejegyzés, a diszk blokk leíró és a pfdata együttes használata

A továbbiakban szemléletes példákon keresztül bemutatjuk a laptábla bejegyzés, a diszk blokk leíró és a pfdata együttes használatát. Mint azt korábban láttuk, az igény szerinti lapozás kihasználja, hogy az érvénytelen lapra történ hivatkozás laphibát okoz. A kivételkezel , ha már tudomást szerzett róla, hogy a hiba

I. UNIX

99

azt jelzi, hogy egy lapot a memóriába kell tölteni, akkor a legfontosabb feladata, hogy a lapot megkeresse és betöltse.

A hibát okozó lap az alábbi állapotban lehet: háttértáron, de nincs memóriában a szabad listán a memóriában végrehajtható állományban zero fill

A VI.3.19. ábra ezekre az esetekre mutat egy-egy példát.

virt. cím 0K 3. eset 1K 2K 3K 4K

fizikai lapcím

érv.

hely

blokk

lap

diszk blokk

hivatkozás -számláló

1343

Inv.

File

3

nincs

Inv.

TF

5 1036 387 1

2. eset 4. eset 1. eset

64K 65K 66K

1457 nincs 1036

Inv. Inv. Inv.

Diszk ZF Diszk

1336

1343 1618

1

813

1611 1336

0

VI.3.19. ábra: A laphibát okozó lap állapotai.

1. eset: A lap a háttértáron van, de nincs a memóriában

A VI.3.19. ábrán, az 1. esettel jelölt sorban látható, hogy a kérdéses lap nincs memóriában (az érvényességi bit törölve van, a lap invalid), és a háttértáron a 813-as blokkon található (a Diszk bejegyzés jelöli). A pfdata adatszerkezet diszk blokk oszlopát végigkeresve a 813-as blokkal, látjuk, hogy az nem szerepel, vagyis a szabad listán sincs sehol. A pfdata

I. UNIX

100

adatszerkezetb l az is kiolvasható, hogy a 1036-os fizikai lap, ami korábban a 813-as háttértár blokk tartalmát tárolta, jelenleg a 387-es háttértár blokk tartalmát tárolja. A laphiba kezel ekkor lapot allokál a 66K virtuális lapnak, megkapja az 1676-os fizikai lapot, és a 813-as blokk tartalma ide tölt dik be. A VI.3.20. ábra az ez utáni adatszerkezeteket mutatja.

66K

1676

Val.

Diszk

813

1676 813

1

VI.3.20. ábra: A módosult adatszerkezetek a lap allokálás után

2. eset: A lap a szabad listán, a memóriában található

A VI.3.19. ábrán, a 2. esettel jelölt sorban látható, hogy a 64K-s virtuális cím lap még a szabad listán megtalálható a memóriában. Ezt a kernel a következ képpen találja meg: a lap a diszken a 1336-os blokkban található. Ez alapján a blokk alapján keres a pfdata adatszerkezet diszk blokk oszlopában, és megtalálja, hogy az ehhez a blokkhoz tartozó lap az 1611-es fizikai lapban található. A hivatkozásszámláló 0-ás értéke jelöli, hogy a lapot jelenleg senki sem használja, az valóban a szabad listán található. Ekkor a hivatkozásszámlálót eggyel növeli a kernel, és ezt a lapcímet beírja a laptábla bejegyzésbe. Ez után a 64K-s virtuális lap bejegyzése a VI.3.21. ábra szerint alakul:

64K

1611

Val.

Diszk

1336

1611 1336

1

VI.3.21. ábra: A módosult adatszerkezetek a lap szabad listán történ megtalálása után

3. eset: A lap egy végrehajtható állományban található

A VI.319. ábrán, a 3. esettel jelölt sorban látható, hogy a lap egy végrehajtható állomány adott blokkjában található (erre a hely oszlop File bejegyzése utal). A példában az 1K virtuális címhez tartozó lap tartalma egy végrehajtható állomány 3. logikai blokkja. Az állomány megnyitásakor a kernel végez egy kis adatel készítést: az állományhoz tartozó inode-ba a

I. UNIX

101

végrehajtható

állomány

logikai

blokkjaihoz

tartozó

fizikai

blokkcímeket

írja

be

sorfolytonosan, így a logikai blokk cím rögtön indexként használható.

4. eset: A laphoz nem tartozik tárolt másolat, azt fizikai memória allokálásakor ki kell nullázni

A VI.3.8.19 ábrán, a 4. esettel jelölt sorban látható, hogy a lap zero-fill, vagyis nem inicializált adatot tartalmaz (erre a hely oszlop ZF bejegyzése utal). Ekkor a kernel amikor fizikai memória lapot allokál, azt kinullázza, ezzel biztosítva, hogy a nem inicializált változók nulla kezdeti értékkel rendelkezzenek.

I.3.8.5. A copy-on-write technika és használata

Mint azt a folyamatkezeléssel kapcsolatban láttuk, a UNIX-ban új folyamatot a fork rendszerhívással lehet létrehozni. A rendszerhívás hatására a létrejöv gyermek folyamat memóriaképe megegyezik a szül memóriaképével. A korai rendszerekben a folyamat

létrehozásával automatikusan allokáltak memóriát a gyermek folyamat számára. Ez nagyon rossz memóriagazdálkodást eredményezett, hisz nagyon gyakran a gyermek folyamat ugyanazt a kódot futtatja, mint a szül je, és a gyermek folyamat gyakran memóriamódosítás nélkül fejez dik be. Ilyenkor felesleges külön memóriát allokálni a gyermek számára.

A folyamat

pfdat

543

Val.: 1

C/W: 1 W: 0

B folyamat 543 Val.: 1 C/W: 1 W: 0 543 3

C folyamat 543 Val.: 1 C/W: 1 W: 0

I. UNIX

102

a)

A folyamat 543 Val.: 1 C/W: 1 W: 0

pfdata

746 B folyamat 746 Val.: 1 C/W: 0 W: 1 543

1

2

C folyamat 543 Val.: 1 C/W: 1 W: 0

b)

VI.3.22. ábra: Egyszer példa a copy-on-write technika alkalmazására. Az a) ábra azt az állapotot mutatja, amikor az A folyamat és két gyermeke osztoznak egy lapon, míg a b) ábrán már az egyik gyermek (B) írás miatt külön lapot használ.

A probléma kezelésére kidolgozták a copy-on-write technikát. A módszer során, ha egy folyamat gyermek folyamatot hoz létre, a kernel el ször csak a mutatókat kezeli. El ször csak az osztottan kezelt tartományok hivatkozás számlálóját növeli. A privát tartományokra új tartománytábla bejegyzés készül, illetve a kernel új laptáblákat foglal. Ezek után a kernel végigmegy a szül lapjain. Ha a lap érvényes, akkor a pfdata hivatkozásszámlálóját eggyel megnöveli (ezzel jelzi, hogy a fizikai lapot külön tartományok használják). Amennyiben a lap háttértáron van, akkor a háttértár használat tábla hivatkozásszámlálóját növeli eggyel. Továbbá a folyamatok laptábla bejegyzéseiben a hozzáférési jogosultságot csak olvasási jogosultságra állítja (W: 0) és bebillenti a C/W (copy-on-write) bitet, jelezve, hogy a copy-onwrite technikát alkalmazza. Ha a szül vagy a gyermeke megpróbálja írni a közösen használt lapok valamelyikét, akkor az írás védelmi laphibát (protection fault) okoz. A laphiba kezel megvizsgálja a C/W bit állapotát. Ha a bit nincs beállítva, akkor valóban jogosulatlan m veletet próbáltak meg végrehajtani, ellenkez esetben viszont a kernel tudomást szerez

I. UNIX

103

róla, hogy most már nem lehet tovább elodázni a fizikai memóriafoglalást, a laphibát okozó folyamat számára lapot kell foglalni, és a foglalás tényét be kell jegyezni a laptáblába, illetve a korábbi leképzésben szerepl fizikai laphoz tartozó pfdata adatszerkezetben csökkenteni kell a hivatkozásszámlálót. A VI.3.22. a) ábra egy ilyen helyzetet mutat be. Az A folyamat két gyermek folyamatot hozott létre, B-t és C-t. A három folyamat közösen használja az 543-as fizikai lapot. Az ábrán a jobb áttekinthet ség érdekében laptábla bejegyzés és a pfdata adatszerkezetnek csak a releváns komponenseit tüntettük fel, illetve csak egyetlen lapot, az éppen írt lapot ragadtuk ki. A VI.3.22. ábrán jól látszik, hogy mindhárom folyamat az 543-as lapot használja, amit a pfdata hivatkozásszámlálójának 3-as értéke is jól mutat. Ekkor a B folyamat írni próbál a mutatott lapra. A folyamat védelmi laphibát okoz (W: 0 volt). A laphiba kezel látja, hogy az adott laptábla bejegyzés C/W bitje be van állítva, így fizikai memória lapot kell allokálnia a B folyamat számára. A VI.3.22. b) ábra ezt az állapotot mutatja. Jól látszik, hogy a hiba kezelése során a B folyamathoz egy új lap (746) allokálódott, amelynek a hivatkozásszámlálója 1, hisz csak a B folyamat hivatkozik rá, míg az 543-as lap hivatkozásszámlálója eggyel csökkent, mert a B folyamat már nem rá hivatkozik. Amennyiben a C/W bit be van billentve, de a hivatkozásszámláló már csak 1, akkor a kernel nem allokál újabb lapot, hanem az eredetiben törli a C/W bitet, és engedi a folyamatnak a lap írását.

I.3.8.6. Hivatkozás bit szimulálása szoftverb l

Néhány számítógép architektúra, mint például a VAX-11 vagy a MIPS R3000, nem nyújt hardver támogatást a hivatkozás (reference) bit használatához. Ekkor annak funkcióját egy szimulált szoftver hivatkozás bit veheti át. Ezt egy egyszer mechanizmussal lehet biztosítani: be lehet vezetni egy úgynevezett szoftver érvényességi (valid) bitet, ami a memória lap valódi érvényességi információját hordozza. Nevezzük az eredeti érvényességi bitet megkülönböztetésül hardver érvényességi bitnek, ezt a hardver teszteli, és érvénytelen állapota okozza a laphibát. A szoftver hivatkozás bitet most a kernel kezeli, ez tölti be a szokásos hivatkozás bit szerepét, a szoftver érvényességi bitet ugyancsak a kernel állítja. Induljunk onnan, hogy a lap érvényes, a hardver érvényességi bit be van billentve. Amikor adott id közönként a kernel (vagy a laplopó folyamat) törli a (most szoftver) hivatkozás bitet,

I. UNIX

104

vele együtt a hardver érvényességi bitet is törli, és a szoftver érvényességi bitet bebillenti, jelezve, hogy a lap valójában érvényes. Ezek után, amikor hivatkozunk a lapra, az laphibát okoz, hiszen a hardver érvényességi bit ki van törölve. A laphiba kezel megnézi, hogy valóban érvénytelen-e a lap. Látja azonban, hogy a szoftver érvényességi bit be van állítva, vagyis a lap érvényes, így most hivatkozás történt egy érvényes lapra. Ekkor a kernel beállítja mind a szoftver hivatkozás bitet, mind a hardver érvényességi bitet. Ezzel a rendszer információt szerzett arról, hogy a lapot nem ,,túl régen" használták, és az érvényesség is helyreállt, a közeli jöv ben történ hivatkozás már nem okoz laphibát. Amikor a laplopó folyamat végigvizsgálja a lapokat a memóriában, nem választ hivatkozott lapot, de törli a hivatkozás bitet és most vele együtt a hardver érvényességi bitet is. Amennyiben a lapra történik újabb hivatkozás, a a fentiek szerint a szoftver hivatkozás bit beáll, és a lap "friss"-nek fog t nni, amennyiben nem, a laplopó legközelebb elveheti a lapot. Természetesen amikor a lap valóban érvénytelenné válik, mind a hardver, mind a szoftver érvényességi bitet törölni kell.

HW érvényességi bit 0

SW érvényességi bit 1

SW hivatkozás bit 0

a)

HW érvényességi bit 1

SW érvényességi bit 1

SW hivatkozás bit 1

b)

VI.3.23. ábra: A hardver, szoftver érvényességi és a szoftverb l szimulált hivatkozás bit állapota a) memóriahivatkozás el tt, b) memóriahivatkozás után

A VI.3.23. ábra a hardver, szoftver érvényességi és a szoftverb l szimulált hivatkozás bit állapotát mutatja memóriahivatkozás el tt és után.

I. UNIX

105

I.3.8.7. A 4.3 BSD virtuális memóriakezelése

A 4.3 BSD virtuális memóriakezel

sok szempontból hasonlít a SVR3 virtuális

memóriakezel alrendszerre, hasonló adatszerkezeteket használ, azonban a terminológia kissé eltér . A 4.3 BSD-ben a fizikai memóriát egy úgynevezett memória térkép (core map), a virtuális memóriát laptáblák, míg a háttértárat a diszk térképek (diszk map) írják le. A fizikai memória használat szempontjából három részre oszlik. Az alsó memória területeken helyezkedik a nem lapozott memória pool, ami tipikusan kernel kódot és a kernel statikusan allokálható adatszerkezeteit tartalmazza, középen helyezkedik el a lapozott memória pool, amit általános célra, a felhasználók folyamatai és a kernel dinamikus adatszerkezetei használnak (ez teszi ki a fizikai memória jelent s részét) és a fizikai memória fels címtartományában található a hiba buffer, amit a rendszerhívások során generált hibaüzenetek tárolására tartanak fenn.

Mint azt láttuk, a SVR3 implementáció a nem memória rezidens lapokról egy külön adatszerkezetben, a diszk blokk leíróban tárol információkat. Ez a megoldás jelent s redundanciát tartalmaz, és többlet memóriát igényel. A 4.3 BSD ezt a problémát úgy oldotta meg, hogy kihasználta, hogy a védelmi és érvényességi biteken kívül a többi bitmez t a hardver nem vizsgálja, ha az érvényességi bit nincs beállítva. Mivel a nem memória rezidens lapok esetén az érvényességi bit törölt állapotú, így ezek a mez k más olyan információ tárolására használhatók fel, amik nyilvántartják ezen lapok helyét. Erre egy tipikus példa, hogy egy fill-on-demand lap esetén, ha azt egy végrehajtható állományból kell betölteni, akkor mivel ilyenkor az érvényességi bit törölt állapotú, és így a memóriakezel tudja, hogy a fizikai lapkeret címét leíró mez ben más információ jelenik meg. Ebben az esetben egy biten jelezni lehet, hogy a fill-on-demand lap végrehajtható állományból töltend vagy ki kell nullázni, és ha végrehajtható állományból töltend , akkor a lapkeret címe helyett a végrehajtható állomány állományrendszerben elfoglalt megfelel blokk címét lehet ezen a helyen tárolni. Ez jelent s memória megtakarítást eredményezett a SVR3 implementációhoz képest.

A legújabb UNIX rendszerek már egy új, memóriába ágyazott állományokon alapuló virtuális memóriakezel alrendszert alkalmaznak, ami kialakulásában magán viseli az el dök

I. UNIX

106

fejlesztési tapasztalatait, azonban egy jelent sen eltér struktúrát vezet be. Ennek tárgyalása meghaladja ezen könyv kereteit. Az irodalomjegyzék b séges forrást tartalmaz, ami alapján az érdekl d olvasó elmélyülhet a témában.

I.4. Hálózati és elosztott szolgáltatások a UNIX-ban
A UNIX történetének egyik legfontosabb állomása volt, amikor az 1984-ben kiadott BSD UNIX-ba bekerült a TCP/IP protokoll támogatása. A TCP/IP támogatást ezután a többi UNIX verzió is gyorsan átvette. A UNIX egyik nagy er ssége azóta, hogy igen könny hálózatba kötni az akár különböz hardveren futó UNIX rendszereket. A UNIX rendszerek fejleszt i azóta is nagy súlyt fektettek a hálózati szolgáltatások fejlesztésére. Az egyik legfontosabb hálózati szolgáltatás az elosztott fájlrendszerek biztosítása. A UNIX rendszerek több alternatívát is kínálnak hálózaton keresztül történ fájlelérés támogatására (pl. HA-NFS, Remote File Sharing ­ RFS, Andrew File System, Unix to Unix Copy). Ezek közül a legsikeresebb a megjelenése óta az elosztott fájlrendszerek szabványává vált SUN Network File System, amit részletesen is bemutatunk. Ennek a rendszernek a bemutatása alkalmat ad számos hálózati protokoll ismertetésére is.

I.4.1. A TCP/IP protokoll család
A TCP/IP családba tartozó protokollok nem a fizikai átviteli közeg elérését szabályozzák, mint pl. az Ethernet, hanem a fizikai átvitel fölé épülnek. Ezek a protokollok a csomópontok címzési módját, illetve a hálózaton továbbított adatcsomagok méretét és formátumát rögzítik. A család legalacsonyabb szint protokollja az IP (Internet Protokoll). Az IP protokoll nem biztosít megbízható átvitelt, az adatcsomagok késhetnek, sérülhetnek, duplikálódhatnak, elveszhetnek, de csak abban az esetben, ha az IP által használt hálózat hibázik. (Ez pontosan azt jelenti, hogy az IP használata nem jelent garanciát az ilyen hibák kiküszöbölésére.) Az IP adatcsomagok formátuma viszonylag bonyolult, méretük maximum 64 kbyte lehet. Mindig egy ún. fejrésszel (header) kezd dnek, ami tartalmazza a küld és a címzett csomópont IP címét. Ez az egyetlen része az üzenetnek, mely redundáns, vagyis védett a sérülések ellen,

I. UNIX

107

megteremtve a lehet ségét annak, hogy az IP protokollt megvalósító szoftver felismerje az esetleges hibákat (5.5. ábra).
Megjegyzés: Ellen rizni!

I. UNIX

108

Vezérl információ

Küld IP címe

Címzett IP címe

Ellen rz adat

Adat

Fejrész (header)

.9. ábra: Egy IP adatcsomag vázlatos felépítése Az IP protokollt megvalósító szoftver feladata ezek után az, hogy az IP címet a helyi hálózatban használatos címmé alakítsa, és az adatcsomagot továbbküldje, elvégezve a használt alacsonyabb szint protokollnak megfelel változtatásokat az adatrészben. Az IP protokoll nagyon népszer a hálózati rendszerekben. Több megvalósítása létezik különböz , alacsony szint hálózati protokollok fölé, így Ethernet hálózat fölé is. Az IP protokollra számos más protokoll épül. A TCP (Transport Control Protocol) az IP protokollra épülve megbízható hálózati átvitelt garantál, míg az UDP (User Datagram Protocol) ugyancsak az IP-re épülve csak az üzenetek továbbítását biztosítja. Mindkét protokoll lehet séget ad a csomópontokon futó folyamatok közvetlen elérésére (címzésére) az ún. process port-okon keresztül. Mind a TCP mind az UDP közvetlenül is elérhet különböz alkalmazások számára. Nagyon sok magasabb szint szolgáltatást adó protokoll épül a TCP/IP család protokolljaira. A TCP-t használó legismertebb szolgáltatások: fájlok átvitele távoli gépekre (file transfer - FTP), távoli gépekre történ belépés (telnet), továbbá elktronikus mail (e-mail) szolgáltatás alapját adó SMTP protokoll. Az UDP-t használó szolgáltatások: távoli gépeken dolgozó felhasználók azonosítójának lekérdezése (rwho), fájlok hordozása (TFTP).

I.4.2. A SUN Network File System (NFS)
A SUN NFS a SUN cég (USA) által kifejlesztett elosztott állományrendszer, els változata 1985-ben jelent meg. Megjelenésével egyid ben szabadon elérhet vé tették az általa használt protokollt valamint referencia-implementációkat is közzétettek, melyek nagyban el segítették a rendszer elterjedését. Ma már, széleskör használata miatt, mintegy szabványnak tekinthet az elosztott állományrendszerek körében.

I. UNIX

109

I.4.2.1. SUN NFS jellemz tulajdonságai
A SUN NFS a kliens-szerver modellre épül. A kliens és a szerver egymástól független, szétválasztható, azonos vagy távoli gépeken is futhatnak. A szolgáltatás az ún. távoli eljáráshívásra (Remote Procedure Call - RPC) épül, mely módszert a kés bbiekben részletesen is ismertetjük. A SUN NFS az RPC szinkron megvalósítását használja, vagyis a kliens folyamatok mindig várakoznak a kérésük teljesítésére. A SUN NFS felhasználói felületének lehet ségei a következ k: Egy vagy több fájlrendszer teljes vagy részleges (részfa) exportálása (láthatóvá tétele a rendszer többi csomópontja számára) lehetséges egy adott csomópontról. Konfigurációs fájl készíthet az exportált fájlrendszert elér kliensek definiálására, amelynek segítségével pl. a felhasználói azonosítók alapján szabályozhatjuk az egyes fájlrendszerek elérését. Távoli fájlrendszer csatlakoztatásának (mount-olásának) lehet sége a lokális fájlrendszerhez az elérési jogosultságok definiálásával. Szoros (hard), illetve laza (soft) csatlakoztatás: Szoros csatlakoztatás esetén a rendszer addig próbálkozik a kívánt fájl elérésével, míg az sikerrel nem jár. Laza csatlakoztatás esetén néhány sikertelen próbálkozás után a rendszer hibaüzenetet küld. A SUN NFS a távoli fájloknak a lokális fájlokkal azonos módon történ elérését biztosítja. A szerver csak a saját, lokális fájlrendszerét exportálhatja a rekurzió elkerülése érdekében. A SUN NFS tervez i a következ célokat t zték a rendszer elé: A protokoll legyen megvalósítható minden operációs rendszer alatt. A protokoll hardver-független legyen. Létezzen egyszer újraindítási lehet ség a kliens, illetve a szerver számára. A kliens kezelje az operációs rendszert l függ fájlelérési metodikát. Az NFS teljesítménye a helyi fájlrendszer teljesítményével összemérhet legyen. A hálózati összeköttetést l független, illetve a forgalomnövekedéssel b víthet kapacitású implementációt tegyen lehet vé Az NFS specifikáció következménye az állapotmentes megvalósítás. Ennek el nye, hogy a kliensek kérései függetlenek egymástól, így önállóan is értelmezhet k. A kliens állapota a szerverben nem tárolt, (az csak statisztikai információt gy jthet), ami biztosítja a szerver egyszer újraindíthatóságát.

I. UNIX

110

Hátránya az állapotmentes megvalósításnak, hogy a szerver csak stabil állapotában válaszolhat a kliens kéréseire, ami id késleltetést okozhat a rendszer m ködésében. Egy egyszer példával illusztrálható ez a szituáció. Tegyük fel, hogy a szerver, cache memóriát használ a fájlok elérésére. Az NFS szerver egy fájlírási kérés végrehajtása esetén csak a m velet teljes lezárását követ en, azaz a cache lemezre történ kiírása után válaszolhat a kliens kérésére. Ellenkez esetben esetleges rendszerhiba (pl. áramszünet miatti

rendszerleállás) esetén a cache tartalma elveszhet, ami a kliens fájlírás kérésének meghiúsulását jelentené. Ha a szerver a cache kiírása el tt nyugtázná a kliens kérését, akkor nem biztosítaná a kért szolgáltatás biztonságos megvalósítását ami viszont az RPC protokollban el írás.

I.4.2.2. A SUN NFS részei
A SUN NFS m ködését nem egyetlen protokoll, hanem egymásra épül protokollok halmaza biztosítja. A protokollok önmagukban is értelmesek, számos az NFS-t l független alkalmazás használja ket. A SUN NFS által használt protokollok a következ k: NFS protokoll: a fájlelérés magas szint protokollja. Definiálja, hogy a kliens és a szerver hogyan tudnak együttm ködni. A kliens a szervert l milyen szolgáltatásokat kérhet, milyen kérései lehetnek, illetve a szerver milyen válaszokat adhat. Pl.: get/setattrib(fájl), lookup(fájl_név), write(fájl), read(fájl) RPC (Remote Procedure Call) protokoll: a távoli eljáráshívás protokollja. Rögzíti, hogy két folyamat hogyan tud egymással kommunikálni, és ezáltal egyik a másik szolgáltatását elérni. Az NFS kliens és a szerver közötti kommunikáció RPC csomagokkal (RPC hívásokkal) történik. XDR (EXtended Data Representation) protokoll: a rendszer-független adatábrázolást rögzít protokoll. Szabványos leírás a különböz típusú adatok egységes hardverfüggetlen ábrázolására és

kommunikációs csatornán (hálózaton) történ továbbítására. Mount protokoll: távoli fájlrendszerek összekapcsolását leíró protokoll. A csatlakoztatás a távoli fájlrendszer helyi fájlrendszerben történ láthatóvá tétele,

bekapcsolása. A csatlakoztatás után a távoli fájlrendszer a lokális fájlrendszer egyik alkönyvtárán keresztül lesz elérhet . A mount protokoll definiálja, hogy hogyan történjen a

I. UNIX

111

távoli fájlrendszer bekapcsolása, milyen csatlakoztatással kapcsolatos szolgáltatásokat érhet el a A mount: unmount: mount távoli fájlrendszer protokoll helyi tipikus történ felhasználó. szolgáltatásai: láthatóvá tétele,

fájlrendszerben

kapcsolat

megszüntetése,

dump: a fájlrendszerbe ,,felmountolt" távoli fájlrendszerek kilistázása. A protokollokat megvalósító, egy m köd komponensek: NFS szerver. Az a szoftver egység ami megvalósítja a protokollban definiált szolgáltatásokat, illetve a rendszer m ködéséhez szükséges egyéb funkciókat (üzenetküldés, fogadás stb.). Tartalmazza ­ általában függvények formájában ­ az egyes szolgáltatásokat megvalósító kódot. Pl.: a szerver oldalon lesz egy lookup() függvény, mely egy elérési út/fájl név paraméterrel meghívva kikeresi a megnevezett fájlt és visszaadja annak fájlleíróját. NFS kliens kód. A kliens oldali funkciókat (üzenetküldés, fogadás, adatkonverzió, stb.) megvalósító szoftver. Biztosítja a kliens oldalon futó alkalmazásnak, hogy a helyi fájlok elérésével azonosan tudják kezelni a távoli fájlokat. SUN NFS rendszerben megtalálható szoftver

Pl.: kliens az NFS-en keresztül távoli fájlt szeretne elérni, akkor a rendszer az NFS klienshez fordul, amely kapcsolódik a szerverhez, és megvalósítja a távoli fájl elérését. Démon (daemon) folyamatok. Az NFS szerver állandóan elérhet szolgáltatásait megvalósító folyamatok. Ezek az NFS szolgáltatás indításakor elindulnak, és figyelik, majd lekezelik a bejöv Tipikus biod: blokkos adatátvitelt kezel démon démon. A kliens fel l érkez kéréseket. processzek: adattömeget kezeli és

továbbítja a szerverhez, illetve a szerver fel l érkez kliensnek. mountd: csatlakoztatással kapcsolatos

adattömeget kezeli és továbbítja a

kéréseket

elégíti

ki.

nfsd: a fájlok elérésével kapcsolatos kéréseket intézi. NLM (Network Lock Manager): Önálló szoftverkomponense a rendszernek. Az NLM segítségével a kliensek jelezhetik, hogy kizárólagosan szeretnének egy fájlt megnyitni és használni, vagyis szeretnék a fájlt zárolni

I. UNIX

112

(lock m velet). Opcionális szoftver komponense az NFS rendszernek, nem minden NFS használja. NSM (Network Status Manager): A fájlok állapotának (lock-olt/nem lock-olt) lekérdezésére szolgáló komponens. Az NSM az NLM-hez hasonlóan opcionális része az NFS-nek.

I.4.2.3. XDR (EXtended Data Representation) protokoll
Az XDR protokoll rögzíti különböz típusú adatok hardver-független ábrázolásának, illetve a hálózaton történ továbbításának módját. Definiálja az adatelemek méretét, azok sorrendjét átvitel esetén, valamint az adatelemek formátumát. Pl. az egész számokat (integer típus) négy bájton ábrázolja, hálózati transzfer esetén els ként a legfels bájtot küldi át. A negatív egészeket kettes komplemens kódolásban ábrázolja. Tömbök átvitele esetén a tömb elé beszúrja a tömb hosszát (5.6. ábra).
Megjegyzés: Majd beszámozni!

Típus
Egész szám

Adat
0x123456 [tömb hossza] 0x00 0x00 0x00 0x00 0xFF

XDR ábrázolás
0x12 0x00 0x00 0x00 0xFF 0x34 0x00 0x00 0x00 0xFF 0x56 0x03 0x04 0x02 0xFF

Három-elem egészekb l álló tömb

4 2 -1

.10. ábra: Példa az XDR adatábrázolásra Az XDR által definiált alap-adattípusok halmazát a felhasználó b vítheti. A protokoll az új adattípusok ábrázolására egy szabályrendszert (adattípus-leíró formális nyelvet) ad, melynek segítségével akár kombinált típusok is definiálhatók.

I.4.2.4. Az RPC protokoll
Számos RPC (távoli eljáráshívás, remote procedure call) protokoll létezik, több szoftverfejleszt cég definiált egymással párhuzamosan RPC protokollokat. Az RPC

I. UNIX

113

protokollt megvalósító szoftverek nem csak az NFS rendszerekben m ködnek, az RPC szolgáltatást az operációs rendszer számos más komponense, illetve az alkalmazások is használják. Az RPC protokoll legfontosabb tulajdonsága, hogy megbízható üzenettovábbítást valósít meg a kommunikáló partnerek között. (Meg kell jegyezni, hogy számos más protokoll létezik, ami nem biztosít megbízható üzenettovábbítást.) A megbízható üzenettovábbítás

megvalósításának leggyakoribb megoldása, hogy a protokollt megvalósító szoftver addig ismétli a küldend üzenetet, míg annak vételér l nyugtázás nem érkezik. Az RPC protokollok el írják üzenetváltás esetére: az üzenetek formátumát (mit tartalmazhatnak az üzenetek), az üzenetközvetítés módját (mely üzenetek milyen sorrendben küldhet k), és a partnerazonosítás (címzés) módját. Fontos kérdés az RPC üzenetküldési módjának definiálásakor, hogy a kliens folyamat várakozik-e az általa kért szolgáltatás végrehajtására, vagyis a szerver válaszának megérkezéséig, avagy nem várakozik. Az els esetben szinkron, míg a második esetben

aszinkron RPC protokollról beszélünk. Az RPC protokollok között léteznek mind szinkron, mind aszinkron megvalósítások. A SUN NFS rendszerben az RPC protokoll a kliens és a szerver kommunikációjának formai definiálására szolgál. A kliens és a szerver között a kérés, illetve a válasz üzenetek RPC csomagok formájában vándorolnak. A SUN NFS a saját fejlesztés SUN RPC protokollt használja, ami szinkron m veletvégzést és megbízható üzenettovábbítást biztosít. A SUN RPC protokoll az üzenetek formátumának definiálására az XDR protokollt használja.

I.4.2.5. Az RPC protokoll m ködése
Az RPC protokollt megvalósító rendszerek is a kliens-szerver modellre épülnek. A m ködés sémáját az 5.3. ábra szemlélteti.
RPC kérés RPC kliens RPC válasz RPC szerver
Megjegyzés: Majd beszámozni!

.11. ábra: Az RPC m ködése Az RPC-kérés felépítése az 5.4. ábrán látható.
Megjegyzés: Majd beszámozni!

I. UNIX

114

XID IRÁNY RPC VERZIÓ PRG AZONOSÍTÓ PRG VERZIÓ SZOLGÁLTATÁS AZONOSÍTÁSI INFORMÁCIÓ ADAT 5.4. ábra: Az RPC-kérés felépítése Az adatelemek magyarázata a következ : XID: Minden egyes üzenetnek generál az RPC egy egyedi azonosítót, aminek alapján az üzenetet számon tartja, és ismétli, ha nem érkezik rá válasz. Az XID ez az azonosító. IRÁNY: A kliens szerver kommunikációban minden üzenet lehet kérés vagy válasz. RPC verzió: Az RPC protokollnak több verziója létezik. Az üzenet formája (vagyis, hogy milyen részeket tartalmaz) függhet az RPC aktuális verziójától. PRG azonosító: Az RPC-t, mint kommunikációs eszközt, több, párhuzamosan futó (applikáció) is használhatja. A PRG azonosító tartalmazza a kért szolgáltatást nyújtó alkalmazás azonosítóját. Az NFS szolgáltatások azonosítója pl. 1000003, vagyis minden NFS csomagban ez az azonosító szerepel. Ebb l tudja az RPC szerver, illetve kliens, hogy az adott üzenetet az NFS szervernek, illetve kliensnek kell továbbítania. PRG verzió: Az adott szolgáltatás verziója. Az NFS-nek pl. két verziója létezik: 2-es és 3-as. Azonosítási információ: A küld folyamat azonosítója. UNIX rendszer esetén ez például a process_ID (PID). Adat: Az üzenet adatrésze. Ennek tartalma az RPC-t használó alkalmazástól függ.

I. UNIX

115

Az RPC-válasz felépítése az 5.5. ábrán látható. XID IRÁNY STÁTUSZ AZONOSÍTÁSI INFORMÁCIÓ STÁTUSZ 2 ADAT

Megjegyzés: Majd beszámozni!

5.5. ábra: Az RPC-válasz felépítése Az RPC-válasz adatelemei részben megegyeznek a kérés adat elemeivel. A válaszban szerepel a kért szolgáltatás státusza is, amely megadja, hogy sikeres volt-e a kért szolgáltatás végrehajtása, történt-e hiba a m ködés során, stb.

I.4.2.6. A SUN NFS m ködése
Az 5.6. ábra az NFS rendszer m ködését foglalja össze. Láthatjuk, hogy a fájlok elérését kezdeményez kéréseket, rendszerhívásokat az ún. virtuális fájlrendszer (VFS) kezeli. A
Megjegyzés: Majd beszámozni!

virtuális fájlrendszer a hagyományos UNIX fájlrendszert továbbfejleszt fájlrendszer, ami lehet vé teszi különböz típusú fájlrendszerek kezelését a UNIX rendszerben.
helyi gép (kliens folyamat) távoli gép (NFS szerver)

kliens folyamat

UNIX kernel virtuális file rendszer (VFS) kérés UNIX file rendszer (UFS) NFS kliens válasz NFS szerver

Unix kernel virtuális file rendszer (VFS)

UNIX file rendszer (UFS)

lemez

lemez

.. ábra: Az NFS m ködésének sémája

I. UNIX

116

A virtuális fájlrendszer, ha lokális fájlt szeretne a kliens folyamat elérni, a kérést a helyi lemezt kezel UNIX fájlrendszer (UFS) felé továbbítja, amelyik a fájlt közvetlenül eléri és visszaadja a kért adatokat. Ha a folyamat távoli fájlt szeretne elérni, a virtuális fájlrendszer a kérést az NFS klienshez továbbítja. Az NFS kliens a hálózaton keresztül eléri a kért fájlt tároló csomóponton m köd NFS szervert. A távoli NFS szerver az ottani VFS rendszeren keresztül kérést küld a helyi UNIX fájlrendszernek (UFS). Az UFS visszaadja a kért adatokat az NFS szervernek, aki továbbítja azokat a kérést kezdeményez kliens folyamat felé az NFS kliens illetve a kliens folyamat csomópontján m köd virtuális fájlrendszeren (VFS) keresztül.

I.4.2.7. Távoli fájlok elérése NFS használatával
Az NFS rendszer m ködését egy példán keresztül foglaljuk össze. Az 5.9. ábrán láthatóan egy kliens folyamat írást (write) hajt végre egy távoli fájlon. A kliens folyamat a hagyományos interfészt használva kezdeményez egy fájlm veletet, vagyis végrehajt egy rendszerhívást (pl. write(fájlleíró_sorszám, adat)). A paraméterként megadott fájlleíró sorszám alapján a rendszer kikeresi a folyamatonkénti, illetve a globális fájltáblából a megfelel bejegyzést. A v_data megmutatja, hogy milyen fájlrendszerbe tartozik az elérend fájl, illetve az elérend fájlrendszerben mik az azonosító adatai. A v_ops megmutatja, hol vannak az adott fájlrendszert kezel rutin címei. A rendszer tudja, hogy az írás m velete, pl. a második rutin a fájlkezel m veletek címeit tartalmazó táblázatban, így elugrik a második címre. A rutinok (távoli fájlról lévén szó) természetesen az NFS kliens kódjában vannak implementálva.
Megjegyzés: Majd beszámozni!

I. UNIX

117

kliens folyamat

Virtuális fájl rsz. NFS funkciók (mutatók) write

FR.ID

i-node k. sz. Távoli file

Lokális file i-node v_data UFS funkciók (mutatók) v_ops write Virtuális fájl rsz.

v_data v_ops NFS szerver

NFS kliens (kód) write RPC kliens

UFS hívások kódja write

kérés (write) válasz (write)

RPC szerver

KLIENS

SZERVER

.. ábra: Távoli fájl elérése NFS segítségével

Az NFS kliens készít egy RPC-kérés csomagot, amit elküld a fájlszerver gépén m köd RPC szervernek. Az RPC szerver észleli, hogy a csomag NFS csomag, és továbbítja az NFS szervernek. Az NFS szerver a helyi VFS rendszeren keresztül kezdeményezi az adott fájl írását. A távoli gépen (amelyiken a szerver fut) a VFS által használt globális fájl táblabejegyzésben természetesen már a lokális fájlok elérésére használt adatelemek lesznek, vagyis a v_data az adott i-node-ra mutat, illetve a v_ops az UFS kódjára. Miután, az UFS write m velete befejez dött, az NFS szerver RPC-válasz formájában nyugtát küld vissza az NFS kliensnek, amely felébreszti a várakozó kliens folyamatot.

I. UNIX

118

I.5. POSIX

A számítógépes rendszerek fejl désével a 80-as évek végére egyre inkább igény mutatkozott egy hordozható rendszerinterfész megalkotására. Ezt er sítette, hogy a UNIX rendszerek fejl désének akkor közel 20 éve során a UNIX a legkülönfélébb hardver környezetekben jelent meg a kis- és nagyképeken egyaránt, de sajnos némileg eltér irányzatot képviselve. A változatok közötti kis eltérések azonban megkeserítették a szoftvergyártók életét, akik el tt a UNIX rendszerek széleskör elterjedésével és elfogadásával felcsillant a lehet ség, hogy ne csak egy hardver platformhoz köt d alkalmazásokat készítsenek. Ezen probléma

megoldásaként született meg a POSIX (Portable Operating System Interface) szabvány, amely az alkalmazói programok szempontjából egy általános felületet kívánt definiálni, hordozhatóvá téve ezzel a szabványt betartó alkalmazásokat.

Amint a bet szó is utal rá, egy hordozható felületet kívántak a szabványban rögzíteni, de nem titkoltan a UNIX különböz változatainak figyelembevételével. Ez a magyarázata az X

megjelenésének a POSIX bet szóban. Az 1990-ben megjelent szabványt röviden POSIX vagy POSIX.1 néven szokás emlegetni. A különböz nevek a következ k: ISO/IEC IS 9945-1:1990 ANSI/IEEE 1003.1-1990 szabványügyi szervezetek által használt

Ez a szabvány C nyelven definiál egy operációs rendszer interfészt, ami az alkalmazások szempontjából ír le egy szabványos rendszerfelületet. A POSIX.1 kidolgozásával párhuzamosan több 1003.x jel IEEE szabvány kidolgozása is megkezd dött, melyeket

gyakran POSIX.x szabványoknak neveznek. Ezek többnyire az 1003.1 el írásait tekintik alapnak és arra épülnek. Ezek közül a legfontosabbak:

I. UNIX

119

1003.0 1003.1 1003.2 1003.3 1003.4 1003.5 1003.6 1003.7 1003.8 1003.9 1003.10 1003.11 1003.12 1003.13

Útmutató a POSIX nyílt rendszerkörnyezethez Rendszer interfész (C nyelven) Shell-ek és segédprogramok Tesztelési eljárások Real time kiterjesztés az 1003.1-hez Ada interfész az 1003.1-hez Biztonság Rendszeradminisztráció Transzparens állományelérés Fortran interfész az 1003.1-hez profil (AEP) a szuperszámítógépekhez profil (AEP) a tranzakciókezeléshez Protokoll-független hálózati elérés Real-time profil (AEP)

A szabványosítási törekvések eredményeként számos más, az alkalmazások hordozhatósága szempontjából fontos szabvány is készült. Ezek nagy száma miatt azonban hamar tarthatatlanná vált az összes egymás melletti, és egymásra épül szabvány minden

kombinációjának megtartása, hiszen adott esetben még az is el fordulhatna, hogy két alkalmazás azért nem kompatíbilis, mert az alkalmazás számára el írt szabványok ellentétesek egymással. Ezt az elvi ,,rendetlenséget" próbálják feloldani az ún. alkalmazási profilok (AEP= Application Environment Profile). Ezek az alkalmazások különböz jellegéhez alakított szabványhalmazok. Így külön szabványhalmaz definiálja pl. a hálózati alkalmazások környezetét,a CAD alkalmazások környezetét stb.

A továbbiakban összefoglaljuk az egyik legfontosabb szabvány, a POSIX.1 célkit zéseit és a szabvány környezetét, felépítését, fontosabb témáit. Az egyszer ség kedvéért az 1003.1 jel szabványra egyszer en csak POSIX néven hivatkozunk, ahol ez nem zavaró.

I.5.1. Alapfogalmak, felépítés

A POSIX.1 alapvet célkit zése, hogy olyan rendszerinterfészt definiáljon, amely alkalmas hordozható alkalmazások készítésére. Ezt több mint 200 C függvény segítségével adja meg, melyek többsége a két nagy UNIX irányzat, a BSD és a System V rendszerhívásával, vagy

I. UNIX

120

rendszer függvényével azonos. Van azonban néhány terület, ahol a szabvány szakítva a BSD és a System V megoldásaival egy harmadik megoldást ír el .

Fontos hangsúlyozni, hogy a szabvány csupán rendszer felületet definiál, és nem írja el annak megvalósítási módját, így nem írja el azt sem, hogy egy adott függvény valójában egy rendszerhívás, vagy csupán egy könyvtári függvény. A megvalósítás oldaláról nézve a UNIX csupán egy lehetséges megvalósítás, de lehet más rendszer is POSIX-megfelel .

Ha POSIX-megfelel ségr l beszélünk, akkor értelemszer en azt vagy az operációs rendszer oldaláról, mint egy POSIX implementációról, vagy az alkalmazás oldaláról tesszük. Implementáció oldalról a megfelel ség azt jelenti, hogy egy adott operációs rendszer mennyire felel meg a szabvány el írásainak. Egy konkrét operációs rendszer megfelel ségét dokumentációval kell alátámasztani. A dokumentáció szerkezetének pontosan követni kell a POSIX szabvány szerkezetét, amelyben nyilatkozni kell a megvalósítás megfelel ségér l. Maga a szabvány 6 különböz kategóriába sorolja az el írásokat, attól függ en, hogy milyen jelleg az el írás. Ezek a kategóriák a következ k: Implementáció által definiált (implementation-defined). Ezzel olyan m ködést, vagy értéket jelöl, amelyet a szabvány nem köt meg, de az implementáció megfelel ségi dokumentumában pontosan meg kell adni annak értékét, vagy le kell írni a pontos m ködést. Az ilyen jelleg dolgokat alkalmazás oldalról ki lehet használni, de lehet leg kerülni kell.

Nem specifikált (unspecified). Ezzel olyan m ködést vagy értéket jelöl a szabvány, mellyel szemben nincs semmilyen követelmény. Az implementáció szabadon rendelkezhet és a konkrét m ködést, vagy értéket nem kell dokumentálni.

Nem definiált (undefined). Ez olyan m ködést, vagy értéket jelent, mellyel szemben egy hibátlan program nem támaszthat követelményeket. Természetesen ilyet az alkalmazás oldalról nem szabad kihasználni.

I. UNIX

121

Kell (shall). Az implementáció pontosan el írja a m ködést vagy a kérdéses értéket.

Kellene (should). Ez egy javaslatot ír el az adott értékre, vagy m ködésre, de az implementáció ett l eltérhet.

Lehet (may). Ez az implementáció számára egy opciót jelöl, amit nem kötelez megvalósítani.

Az alkalmazás oldalról a megfelel ség tekintetében négy egymásra épül különböztetünk meg (VI.5.1 ábra): Szigorúan megfelel alkalmazás.

szintet

Olyan alkalmazás, amely csak a POSIX szabványra épül, és hibátlanul m ködik a szabványban nem specifikált és implementáció által definiált tulajdonságok és paraméterek tetsz leges értékével.

ISO/IEC megfelel alkalmazás. Olyan alkalmazás, amely a POSIX szabvány mellett felhasznál más ISO/IEC szabványokat is.

Nemzeti szabványokat is felhasználó alkalmazás. Olyan POSIX alkalmazás, amely nemzeti szabványokat is felhasznál.

Egyéb nem szabványos kiterjesztéseket is felhasználó alkalmazás. Olyan POSIX alkalmazás, amely felhasznál nem szabványos kiterjesztéseket is.

I. UNIX

122

Szigorúan megfelel

ISO/IEC megfelel

Nemzeti szabványokat is felhasználó

Egyéb kiterjesztéseket is felhasználó alkalmazás

VI.5.1 ábra: alkalmazások megfelel sége

I.5.2. POSIX környezet

A szabvány értelmezési és felhasználási területét definiálja az a leírás, amely a környezetet adja meg. Ez a környezet sokban hasonlít a UNIX rendszerhez, de az implementációt tekintve nem feltétlenül UNIX, hiszen a szabvány nem definiál implementációt, csak felületet. A környezet legfontosabb elemei a következ k: Többfelhasználós, több folyamat konkurens futtatására alkalmas környezet, melyben a folyamatoknak és a felhasználóknak egyedi azonosítójuk van. Hierarchikus, nem tisztán fa szerkezet állományrendszer. Fontos kiemelni, hogy a hierarchia nevek szintjén, azaz egy névtérben jelenik meg. Az állományoknak van ugyan egy egyedi sorszám azonosítója, de a megvalósítást a szabvány nem írja el . A felhasználók adatainak elérését védelmi rendszer szabályozza, amely hasonlít a UNIX rendszeréhez, de lehet attól szelektívebb, azaz szigorúbb is.

A szabvány a UNIX implementációk felhasználásával keletkezett ugyan, de a fenti környezetet tekintve nem zár ki más rendszereket (pl. VMS, OS/2 MVS) sem.

I. UNIX

123

I.5.3. Hordozható alkalmazások

Ahogyan azt a szabvány fogalmainak ismertetéskor láttuk, az implementáció tekintetében vannak választási lehet ségek (should, may). Ezek els sorban a különböz UNIX

változatoknak a szabványhoz való igazítása miatt jöttek létre. A legfontosabb ilyen implementáció által definiált területek a következ k: Job-kontrol megvalósítása. Elmentett set-uid megvalósítása. chown() kiterjesztett megvalósítása. Ez azt jelenti, hogy az implementáció lehet sége, hogy a System V filozófiának megfelel en minden tulajdonos használhatja a chown() rendszerhívást, vagy csak a superuser (POSIX terminológiával: megfelel user). Hosszú állománynevek kezelése. Speciális karakterek kezelésének tiltása.

A hordozhatóság érdekében a POSIX szabvány által megengedett lehet ségekhez az alkalmazásokat úgy kell elkészíteni, hogy ezeket vagy ne használják ki, vagy rugalmasan alkalmazkodjanak az adott implementáció tulajdonságaihoz. Ez utóbbi megvalósítására a szabvány két lehet séget kínál: Fordítási id ben megfelel feltételes fordítási opciók és konstansok használatával. Ezt a C nyelvi interfészen a állomány konstansai biztosítják. Futási idej lekérdezéssel a sysconf(), pathconf() ill. fpathconf() függvények használatával.

A hordozhatóság lehet sége azonnal felveti azt a kérdést, hogy hogyan, milyen formátumban lehetséges az adatok ill. programok átvitele az egyik környezetb l a másikba. A POSIX.1 rendszerfelületet definiál ugyan, de mivel ezt a kérdést nem tudta megkerülni, egy külön fejezetben ajánlást tesz hordozható formátumokra és az ezeket el állító segédprogramokra is, amit kés bb az 1003.2 (POSIX.2) jel részletesen. szabvánnyal foglalkozó bizottság dolgozott ki

A POSIX.1 alapján egy alkalmazás új környezetbe való telepítéséhez a következ információkat kell egy hordozható csomagba becsomagolni: Az alkalmazás programkódját

I. UNIX

124

Forráskódban. Ez a kódkészlet problémáját veti fel, mivel a POSIX az ISO 646 kódkészletre épül. Sajnos az ISO 646 kódkészletben számos jel nem definiált, amit viszont a legtöbb programozási nyelv, így a C is használ. Ezek helyettesítésére az ún. trigraph karaktereket használhatjuk. Ezek 3 karakteres karaktersorozatok, amelyek

helyettesítik a megfelel jelet. Bináris változatban. Bináris formában természetesen csak bizonyos korlátozásokkal lehetséges

programokat egyik környezetb l a másikba átvinni. A POSIX.1 utal arra, hogy létezik ún. ABI (Application Binary Interface), amivel részben lehetséges a probléma kezelése. A másik ígéretes próbálkozás az ANDF (Architecture Neutral Distribution Format), amely egy közbüls kódot definiál. Ez a közbüls kód minden lényeges információt tartalmaz a végleges kód generálásához. A kódgenerálás fázisa így eltolódhat az adott architektúrán történ installálás pillanatáig. Az alkalmazás adatait, ami tartalmazza az on-line dokumentációt is. Ez az eltér számábrázolási formátumok és pontosságok problémáját veti fel. Ezek

elkerülhet k, ha az adatokat is szövegként visszük át, bár ahogyan a forráskód átvitelénél tárgyaltuk ez sem teljesen problémamentes. Az installációs utasításokat és scripteket. Annak ellenére, hogy a POSIX.1 nem elvileg alapszik más szabványokon, ezen a téren a POSIX.2-re utal, mint ajánlásra, hiszen ez foglalkozik a shell-ekkel.

Egy hordozható alkalmazásnál különös figyelemmel kell lenni arra, hogy az alkalmazásban használt állományok nevei hordozhatók legyenek, és lehet leg ne tartalmazzon abszolút útnévvel állományhivatkozást.

Az állományok csomagolására a cpio és a tar segédprogramokat javasolja a szabvány. Ezek kimeneti formátuma kell en egyszer , így szinte minden operációs rendszerben lehetséges a kezelésük. Mindkét programnak vannak el nyös és hátrányos tulajdonságai a másikkal szemben, ami használatukat bizonyos körülmények között korlátozza. Így pl. a tar nem menti ki a device típusú állományokat. A cpio ezeket kimenti ugyan, de visszatöltéskor a tar-ral ellentétben nem tartja meg a linkeket.

I. UNIX

125

ASCII

[ ] { } \ | ^ # ~

trigraph ??( ??) ??<

??> ??/ ??! ??' ??= ??trigraph karakterek

I.5.4. Folyamatkezelés

A POSIX környezetben a folyamatok konkurensen futnak, melyeket a UNIX rendszereknél megismert módon a fork() rendszerhívással lehet létrehozni, és az ott megszokott jellemz kkel rendelkeznek. A szabványba a folyamatkezelés terén alapvet en a System V rendszerekben alkalmazott megoldások kerültek be. BSD örökség viszont a kiegészít csoportazonosítók és a jelzés-maszk alkalmazása. A terminálhoz rendelt szekciók (session) ötlete a két irányvonal ötvözéseként jött létre, ami lehet séget ad a BSD rendszerekben támogatott ún. job-kontrol koncepció, és a System V rendszerekben alkalmazott folyamatcsoport használatára is. Ennek lényege az, hogy minden folyamat tagja egy szekciónak és egy folyamatcsoportnak is. Egy szekcióhoz egyszerre több folyamatcsoport is tartozhat, ami lényegében a BSD job koncepciójának felel meg.

A folyamatok legfontosabb tulajdonságai a következ k: Folyamat-azonosító (PID). Egyedi azonosítószám. Szül folyamat azonosítója (PPID). Folyamat csoportazonosító (PGID). Login név. Valós felhasználói azonosító (UID).

I. UNIX

126

Effektív felhasználói azonosító. Ez az ún. set-uid bittel rendelkez programoknál eltérhet a valós UID-t l. Ez lehet séget ad arra, hogy átmenetileg, vagy véglegesen a folyamatot indító felhasználó azonosítójától eltér rendelkezzen a folyamat. Valós felhasználói csoportazonosító (GID). Effektív felhasználói csoportazonosító. Ez az ún. set-uid bittel rendelkez programoknál eltérhet a valós GID-t l. Ez lehet séget ad arra, hogy átmenetileg, vagy véglegesen a folyamatot indító felhasználó csoportazonosítójától eltér azonosítóval, ill. jogokkal rendelkezzen a processz. Kiegészít csoportazonosítók. Munkakatalógus. Állományok létrehozási maszkja (UMASK). Ez egy bitmaszk, mely minden új állomány létrehozásánál részt vesz a védelmi attributumok kialakításában. Jelzés maszk. Terminál azonosító. Szekció (session) azonosító. Futási id k. azonosítóval ill. jogokkal

A szabvány a folyamatkezeléshez a következ , a UNIX rendszerekb l jól ismert függvényeket definiálja: abort(), exit(), execl(), execle(), exelp(), execv(), execve(), execvp(), wait(), waitpid().

I.5.5. Állománykezelés

A szabvány állománykezeléssel foglalkozó része azt a programfelületet definiálja, ahogyan az állományokat az egyes alkalmazások elérhetik. Az állományrendszer felépítésével a POSIX csak a VI.4.2 pontban ismertetett névtér absztrakció szintjén foglalkozik. Ez azt jelenti, hogy az állományokat, pontosabban azok neveit nem tisztán fa struktúrájú hierarchiában képzeljük el. Ebben a hierarchiában öt állománytípust különböztetünk meg: normál állomány (regular file) katalógus (directory)

I. UNIX

127

FIFO blokkos elérés eszköz karakteres elérés eszköz

A szabvány javasolja (should), hogy az állományok nevei ún. hordozható állománynevek legyenek. Ezek csak az angol abc kis és nagybet it, a pont (.), az aláhúzás (_) és a köt jel (-) karaktereket tartalmazhatják. Ezen felül a nevek nem kezd dhetnek köt jellel sem. Az útnevekben az egyes komponenseket per (/) karakterrel kell elválasztani. Egymás után több ilyen elválasztójel is lehet, kivéve az útnév legelején. Az egymás utáni / jelek egy / jelnek értelmez dnek.

Az állományok legfontosabb tulajdonságai a következ k: Állomány típusa. Hozzáférés védelmi kódja (permission). A POSIX a UNIX 3x3-as védelmét követeli meg, de implementáció által definiált módon megenged ezen felüli védelmet is. Ha ilyen létezik, akkor: Annak állományonként engedélyezhet nek ill. tilthatónak kell lennie. Az alkalmazói program szempontjából ugyanúgy kell megjelennie, mint az eredeti 3x3-as védelem, tehát létezni kell a ,,tulajdonos", ,,csoport", és ,,bárki" fogalmaknak. Ha engedélyezve van, akkor az a korábbi védelmet felülírva jelenik meg a különböz rendszerhívásoknál (pl. stat, fstat). Egyedi azonosítószám. Ez gyakorlatban az eszköz azonosítóját és az i-node számot jelenti, de ez már implementáció kérdése. Hivatkozás (link) számláló. Tulajdonos azonosítója és csoportazonosítója (UID, GID). Állomány hossza byte-ban. Utolsó módosítási id . Utolsó hozzáférési id . Utolsó státusz-módosítási id . A fenti adatokat tároló adatstruktúra módosítási ideje. Gyakorlatban az i-node módosítási ideje.

I. UNIX

128

Az állományok kezelése az ANSI C alacsony és magas szint függvényeivel történhet a POSIX rendszerekben. Ezek leírására nem térünk ki részletesen, csupán néhány fontos elemet ragadunk ki, amelyek nemileg eltérnek mind a BSD, mind a System V megoldásaitól: Nem használható az mknod() rendszerhívás. Helyette a speciális bejegyzések külön hívással állíthatók el (pl. mkdir(), mkfifo()). A katalógusok kezelésére külön interfész van (mkdir(), rmdir(), opendir(), readdir(), rwinddir(), closedir()). A POSIX el írásai szerint a katalógusok nem olvashatók normál állományként, csak a fenti függvényeken keresztül, és csak szekvenciálisan érhet k el. A szabvány bevezeti a rename() rendszerhívást, bár normál állományokra a link() és unlink() páros is használható, de katalógusokra csak a rename(). Az állományok megnyitása más UNIX változatokhoz hasonlóan lehetséges O_APPEND ill. O_NONBLOCK módon is, de a POSIX nem támogatja az O_SYNC flag használatát, és sync() rendszerhívás sincs a szabványban. Ez utóbbi helyett egy fsync() rendszerhívást definiál, ami állományokra szelektíven adható ki. A megnyitott állomány különböz tulajdonságai az fcntl() függvény használatával lekérdezhet k ill. beállíthatók. Ezzel oldhatók meg a kölcsönös kizárást biztosító zárolások (lock) is.

I.5.6. Jelzéskezelés

A POSIX jelzéskezelés az egyik olyan terület, amely teljesen szakított a UNIX hagyományokkal és a rendszerfelületet tekintve eltér a UNIX irányvonaltól. Ennek oka, hogy mind az eredeti System V, mind a BSD jelzés kezelése megoldhatatlan problémákat vet fel. A f gondot az a dilemma jelenti, hogy mi történjen abban az esetben, ha egy jelzés érvényre jut, majd hatására elindul az alkalmazásban definiált kezel rutin, és közben újból bejön ugyanaz a jelzés.

A System V filozófia szerint a jelzés érvényre jutásakor az adott jelzéshez tartozó kezelési mód kijelölése visszaáll az alapértékre. Ha az alkalmazásnak ez nem felel meg, akkor a kezel rutinban újra át kell állítani, különben az alapértelmezés szerinti tevékenységet hajtja végre a rendszer, ami a legtöbb jelzés esetén programmegállást jelent. Azonban hiába veszi

I. UNIX

129

magához a program újból az adott jelzést a kezel rutin elején, lehet hogy ott már kés , ugyanis van egy rövid id , amikor a jelzés már alaphelyzetben van, és már érvényre juthat a következ jelzés.

A BSD filozófia szerint a jelzéshez rendelt kijelölés nem áll vissza alaphelyzetbe. Ez viszont feltételezi, hogy a kezel rutin újrabelép . Ami nem minden esetben teljesíthet .

A POSIX jelzéskezelése némi hardveres szemléletet tükröz. Ahogyan egy hardver megszakítás is maszkolható, úgy egy POSIX folyamathoz és a jelzést lekezel rutinhoz is hozzárendelhet egy maszk. Ez az ún. jelzésmaszk el írja, hogy az adott pillanatban mely jelzések nem juthatnak érvényre, azaz blokkolódnak (VI.5.2 ábra). Ez a megoldás a jelzéskezelés megszokott interfészét is érintette, hiszen egy adott szignáljelzéshez nem csak a kezel rutint kell hozzárendelni, hanem egy maszkot is. Így a jelzéskezelés beállításához nem a UNIX signal() rutinját, hanem a sigaction() POSIX rutint kell alkalmazni, melynek egy struktúrában kell megadni a megfelel paramétereket. A folyamat jelzésmaszkja a folyamat keletkezése során örökl dik, amit maga a folyamat is megváltoztathat a sigprocmask() rendszerhívással. Ha egy jelzés érvényre jut, akkor a kezel rutin futása alatt egy új maszk jut érvényre, ami az eredeti maszk, a kezel rutinhoz rendelt maszk, és az aktuális jelzés

sorszámának uniójaként keletkezik. Ezzel és a maszkot manipuláló függvényekkel (sigemtyset(), sigfillset(), sigaddset(), sigdelset(), sigismember()) korrektül kezelhet k a fenti problémák.

I. UNIX

130

jelzés érkezik

normál program végrehajtás maszk = M1

normál program végrehajtás maszk = M1

a jelzés kezel rutinja M2 maszkkal maszk = M1 M2 [akt. jelzés] VI.5.2 ábra: POSIX jelzéskezelés

A jelzés küldésére továbbra is megmaradt a UNIX rendszerekben használatos kill() függvény. Hasonlóan használható a pause() függvény is, amely egy jelzést generáló eseményre való várakozásra használható. Ennek POSIX kiterjesztése a sigsuspend() függvény, amelynek paraméterként megadható a várakozás idejére érvényes jelzésmaszk is.

I.5.7. Terminálkezelés

A POSIX terminálkezelés új elemeket és régi UNIX hagyományokat is tartalmaz. Alapjában a terminál kezelését befolyásoló paraméterek és m ködési módok lényegében változatlanul maradtak, de a kezelést végz függvények teljesen megváltoztak. Így megmaradtak az input és output kezelését befolyásoló speciális karakterek és az input két f m ködési módja a

kanonikus és nem kanonikus mód. Megsz nt viszont a korai UNIX verziókban megjelen ioctl() függvény, mivel nem illeszkedett sem a POSIX sem az ANSI C filozófiájához. Ezt teljesen kiváltották a tcgetattr() és a tcsetattr() POSIX függvények. Az ioctl() függvény leginkább azért nem felelt meg a szabvány követelményeinek, mert nagyon sok feladata volt,

I. UNIX

131

és ennek megfelel en különböz

módon kellet paraméterezni. Jellemz

a függvény

összetettségére, hogy a harmadik argumentumának típusa és jelentése függött a második argumentumtól.

A terminálkezelés tekintetében azért is különösen fontos a strukturált, átlátható módszerek használata, mert ha egy program megváltoztatja a terminál kezelésének módját és paramétereit, az hatással van az összes azonos terminálról futó programra is. Ezért külön hangsúlyozza a szabvány, hogy a programok indulásakor el kell menteni az eredeti beállításokat, miel tt megváltoztatnánk azokat, hogy az alkalmazás megállásakor az eredeti állapot visszaállítható legyen. Fontos továbbá, hogy a visszaállítás a különböz hibaágakon, ill. megszakítás hatására történ megálláskor is megtörténjen.

I.6. A LINUX RENDSZER
A Linux operációs rendszer tulajdonképpen a UNIX-nak egy önálló változata, amely az elmúlt évek során egyre növekv népszer ségre tett szert. A rendszer napjainkban is egyre inkább elterjed ben van, amit nagymértékben el segít az a tény, hogy a különböz fejlesztési változatainak forráskódja bárkinek ingyenesen rendelkezésére áll az Interneten. Ez egyben azt is jelenti, hogy a fejlesztésekbe is szabadon kapcsolódhatnak be az abban érdekelt m helyek, intézmények. A szabad hozzáférés lehet sége egyébként a Linux eddigi teljes történetére jellemz volt, aminek következtében az egyes változatok a világ különböz felhasználóinak és fejleszt inek együttm ködéséb l jöttek létre, javarészt az Interneten keresztül történ kommunikáció révén. Elvileg bárki installálhat egy Linux rendszert azáltal, hogy az Internetr l ftp-vel letölti a legújabb rendszerkomponenseket, majd lefordítja és összeszerkeszti ket. Ezt a munkát

lényegesen megkönnyítették azok a fejleszt k, akik standard, el reszerkesztett csomagokat tettek közzé a könnyebb installálás érdekében. Az így el készített összeállítások általában jóval többet rejtenek magukban, mint az alapkiépítés Linux. Tipikusan olyan komponenseket is tartalmaznak, mint rendszerkezelési segédprogramok (utility-k), Web-keres k,

szövegfeldolgozó és szerkeszt eszközök, s t még játékprogramok is. A legújabb megoldások

I. UNIX

132

szerint már külön csomagkezel

eszközök állnak rendelkezésre, a keresést megkönnyít

adatbázissal. Mindez a csomagok installálását, követését, módosítását, upgrade-olását, illetve eltávolítását segíti el Interneten keresztül. A Linux felhasználási jogát illet en a következ kikötések, feltételek vannak érvényben: A Linux nem tekinthet ún. nyilvános (public-domain) szoftvernek. A public-domain

megjelölés azt jelenti, hogy a szerz k nem tartanak igényt semmiféle szerz i jogra. A Linuxkód fölött azonban érvényesül a szerz ségi jog. Ugyanakkor a Linux szabad szoftver. Szabad abban az értelemben, hogy bárki lemásolhatja, módosíthatja, használhatja oly módon, ahogy neki tetszik, és tovább adhatja a saját példányait bármiféle megszorítás nélkül. A legf bb kikötés itt az, hogy akár felhasználó, akár szerz lesz valaki, nem teheti saját tulajdonává az általa használt, vagy módosított terméket, így pénzért nem is forgalmazhatja azt. A másik kikötés az, hogy ha valaki kibocsát egy általa létrehozott példányt, akkor a bináris kódon kívül köteles a forráskódot is közreadni. A fentiekhez kapcsolódóan érdemesnek tartjuk még megjegyezni, hogy ugyancsak széles körben terjedt el az A. S. Tanenbaum professzor és munkatársai által kifejlesztett MINIX nev operációs rendszer (els változata 1987-ben jelent meg), amelynek terjesztése a Linux-éhoz hasonló elvek szerint történik. A MINIX els sorban oktatási célokra használható fel jól, valójában a UNIX-nak egy kicsinyített változata. Igen alkalmas arra, hogy az operációs rendszerekkel ismerked informatikus hallgatók ennek a rendszernek a tanulmányozása és használata alapján mélyítsék el tudásukat. A MINIX C nyelv forráskódja megtalálható az 1999-ben magyarul is kiadott, az operációs rendszerekkel foglakozó Tanenbaum-könyvben.

I.6.1. A Linux fejl désének állomásai
A Linux fejlesztése 1991-ben vette kezdetét, amikor egy finn egyetemista, Linus Torvalds egy önálló kernelt írt Intel 80386 processzorra. A Linux elnevezés t le (a saját nevéb l) származik. A kernel forráskódját szintén tette publikussá Interneten. Fontos még

megemlíteni, hogy az Intel-386 volt az els 32-bites processzor a PC-kompatibilis CPU-k körében. A Linux-projektekben mindvégig alapvet tervezési szempont volt a UNIX-szal való

kompatibilitás, azaz a UNIX-on futó standard alkalmazások többségének futniuk kellett Linux-on is.

I. UNIX

133

Az 1991-ben kibocsátott els kernel még meglehet sen korlátozott felhasználást tett lehet vé. Nem rendelkezett hálózati támogatással, csak személyi számítógépen m ködött, ezen kívül igen kevés perifériát támogatott, kevés készülékkezel (device driver) állt rendelkezésre. A Linux történetében a következ fontos állomás az 1.0 verzió volt, amelyet 1994-ben

bocsátottak ki. Ez már képes volt a hálózati m ködtetésre, a UNIX által is támogatott TCP/IP protokollt használta, továbbá BSD-kompatibilis socket interfészen keresztül lehet vé tette a hálózati programozást is. Az 1.0-s kernel már fejlett fájlkezel rendszerrel volt ellátva, amely nagyteljesítmény

diszkelérést is lehet vé tett. A virtuális memória alrendszert kiegészítették a lapkezeléssel (paging), ami a tárcserét (swapping) nagyban meggyorsította. Jóllehet ez a verzió még mindig csak Intel-es PC-ken üzemelt, a hardver-támogatás tovább b vült a floppy diszkek, CDROM-ok kezelésével, továbbá hangkártyák, nemzetközi billenty zetek, stb. használatával. Három közbüls verzió megjelenését követ en, a következ kiugró állomás a Linux 2.0 volt, 1996-ban. Ez két területen tartalmazott lényeges el relépést: egyrészt több fajta architektúra használatát engedte meg, beleértve a tiszta 64-bites Alpha portot is, másrészt pedig alkalmassá vált a többprocesszoros m ködésre. A 2.0-s verzió már futott Motorola 68000 sorozatú processzorokon, továbbá a Sun Sparc rendszereken is. További lényeges el relépés történt a TCP/IP protokoll-kezelés teljesítményében, és számos új hálózati protokollt fogadott be a rendszer, valamint belekerült az ISDN támogatás is. Ugyancsak fontos javítás volt még a bels kernel-szálak lehet vé tétele, ami a betölthet modulok közötti függ ség-kezelésére alapozva a modulok automatikus betöltésének támogatására szolgált.

I.6.2. A Linux felépítése és m ködése
Általános tervezési szempontból a Linux hasonlít bármelyik hagyományos UNIXimplementációhoz. Többfelhasználós, multiprogramozott rendszer a UNIX-kompatibilis eszközök teljes készletével. Fájlrendszere a tradicionális UNIX-szervezést követi, ugyanazzal a hierarchikus könyvtári fa-struktúrával és ugyanazzal a nyelvi szemantikával. A fájlrendszer a standard UNIX-os hálózati modellt is teljes mértékben megvalósítja. A Linux rendszer kódja három f részb l tev dik össze, a legtöbb normál UNIX-

implementációval teljes összhangban. A részek a következ k:

I. UNIX

134

Kernel: az operációs rendszer összes fontos bels funkcióját látja el, mint pl. a virtuális memória kezelése, vagy a folyamatkezelés. Rendszerkönyvtárak: elemei azon standard funkciókat valósítják meg, amelyeken keresztül az alkalmazások együtt tudnak m ködni a kernellel, másrészt pedig azokat a tevékenységeket látják el, amelyek nem igénylik a kernel felügyeletét. Segédprogramok (utility-k): olyan programok, amelyek egyedi, speciális feladatokat látnak el. A utility-k egy része inicializálásra, valamint konfigurálásra való. Mások folyamatosan használatban lehetnek: a hálózati kapcsolatokat intézik, logon-kérést fogadnak terminálról, vagy naplózási fájlokat újítanak fel. A 7.1. ábrán láthatjuk a Linux rendszer felépítését. A legfontosabb különbség a kernel és a többi komponens között, hogy a kernel a processzor privilegizált (ún. kernel) végrehajtási módjában hajtódik végre. Így a kernel szabadon eléri a számítógép összes fizikai er forrását. A kernel a LINUX-ban egyáltalán nem tartalmaz felhasználói módú kódot. A processzor privilegizált módba történ átkapcsolása a rendszer programozói interfészét adó
Megjegyzés: Majd beszámozandó

rendszerkönyvtárak rutinjaiban elhelyezett rendszerhívásokkal történik.

Rendszerkezel programok

Felhasználói Felhasználói folyamatok segédprogramok Rendszerkönyvtárak Linux kernel Betölthet kernel modulok

Fordító programok

7.1. ábra: A Linux rendszer komponensei A Linux megtartotta a UNIX tradicionális szerkezetét. Ez azt jelenti, hogy a kernel egyetlen monolitikus bináris kód. Ennek f oka a minél nagyobb teljesítmény elérése volt. Mivel a teljes kernel-kód és az adatterületek egyetlen címtérben vannak, nincs szükség környezetváltásra (context switch), amikor egy folyamat rendszerfunkciót hív meg, vagy egy megszakítás lép fel. Ezt a címteret nemcsak az ütemez és a virtuális memóriát kezel kód használja, hanem a teljes kernel-kód: Az összes készülékmeghajtó kódja, a fájlrendszer és a hálózatkezel mind ugyanebben a címtérben találhatók.

I. UNIX

135

A kernel azonban nem s rít magába mindent, teret ad a modularitásnak is. Ugyanúgy, ahogyan a felhasználói alkalmazások futási id ben be tudnak tölteni osztott elérés könyvtárakat (run time library), a kernel is be tud tölteni kernel-modulokat futási id ben. Ezek a modulok önállóan betölthet komponensei a kernelnek. A kernel a Linux operációs rendszer magját képezi. Mindazt a funkcionalitást biztosítja, ami a folyamatok futtatásához szükséges, továbbá olyan rendszerszolgáltatásokat nyújt, amelyek a hardver er források szabályozott elérését biztosítják. Maga a Linux kernel több lényeges ponton eltér a megszokott UNIX kernelt l. A UNIX kernelhez képest több extra funkció hiányzik bel le. Az általa megvalósított funkciókat pedig nem szükségszer en ugyanabban a formában látja el, mint a tipikus UNIX kernel. A futó alkalmazások számára látható interfészt nem közvetlenül a kernel biztosítja. Az alkalmazások a rendszerkönyvtárakat hívják meg, amelyek szükség szerint meghívják az operációs rendszer szolgáltatásait. A rendszerkönyvtárak legegyszer bb funkciója, hogy lehet vé teszik az alkalmazások számára a kernel által biztosított rendszerszolgáltatások elérését. Egy rendszerhívás átkapcsolja a processzort felhasználói módból privilegizált (kernel) módba. Ennek az átváltásnak a részletei hardver architektúránként változnak. A könyvtárak az alapvet rendszerhívásokon kívül összetett funkciókat is biztosítanak az alkalmazások számára. Például, a C nyelv fájlkezel függvényei mind a rendszer-

könyvtárakban vannak megvalósítva. Ez a fájlok elérésekor hatékonyságnövekedést eredményez. A könyvtárak olyan rutinokat is tartalmaznak, amelyek végrehajtása során nem hívódik meg a kernel. Ilyenek például a rendez algoritmusok, matematikai függvények, valamint a stringkezel rutinok. Mindazok a funkciók, amelyek ahhoz szükségesek, hogy UNIX vagy POSIX alkalmazásokat lehessen futtatni Linux alatt, itt vannak megvalósítva. A Linux rendszer magában foglal még számos felhasználói módú programot, mind rendszersegédprogramokat, mind pedig felhasználói segédprogramokat (utility). A rendszersegédprogramok közé tartoznak mindazok a programok, amelyek a rendszer inicializálásához szükségesek, mint pl. a hálózati eszközöket konfiguráló, illetve a kernel modulokat betölt programok. A folyamatosan futó szerver programok ugyancsak rendszerprogramnak számítanak. Az ilyen programok kezelik a felhasználói beléptetéseket, a bejöv kapcsolatokat, valamint a nyomtatási sorokat. hálózati

I. UNIX

136

Nem mindegyik standard segédprogram lát el rendszeradminisztrációs feladatot. A UNIX felhasználói környezete nagyszámú standard segédprogramot tartalmaz olyan mindennapos feladatok ellátására, mint a könyvtárak kilistázása, fájlok mozgatása és törlése, egy fájl tartalmának megjelenítése stb. Ennél bonyolultabb segédprogramok szövegfeldolgozó funkciót tudnak ellátni: például szöveges adatok rendezése, szövegrészekre történ keresés. Ezek a segédprogramok együttesen olyan standard eszközkészletet alkotnak, amit a felhasználók bármelyik UNIX rendszeren megtalálnak, és el is várnak. Jóllehet ezek nem végeznek operációs rendszerre háruló tevékenységet, a Linux rendszernek is alapvet en fontos részét képezik. A Linux többfelhasználós rendszer. Biztosítja a folyamatok párhuzamos futtatásának lehet ségét, az ehhez szükséges védelmi funkciókkal együtt. A ütemez id osztásos. Az

újonnan létrehozott folyamatok osztozhatnak a szül vel a környezetük egyes részein. Így lehet ség van többszálú programozásra (multithreaded programming). A folyamatok közötti kommunikációt a UNIX-ban megszokott mechanizmusok támogatják, mint például az üzenetsorok (message queue), szemaforok, osztott elérés memória, valamint a BSD socket interfésze. A különböz hálózati protokollok egyidej leg érhet ek el a socket interfészen keresztül. A felhasználói felületen a Linux fájlrendszere teljes mértékben a UNIX-szemantikát alkalmazza. Belülr l a Linux egy absztrakciós réteget használ a különböz fájlrendszerek kezelésére. A készülék-orientált, az NFS, és a virtuális (VFS) fájlrendszert egyaránt támogatja a Linux. A készülék-orientált fájlrendszerek a diszket két cache-en keresztül képesek elérni: az ún. lap cache-en (page cache), illetve a puffer cache-en (buffer cache) keresztül. A Linux memóriakezel rendszere támogatja az osztott memóriaelérést. Alkalmazza a copyon-write módszert annak érdekében, hogy minimalizálja a különböz osztottan használt adatok duplikálását. A memórialapokat a rendszer a rájuk történ els hivatkozáskor tölti be a fizikai memóriába. Háttértárra mentésük pedig akkor következik be, amikor a rendszer szabad memóriája egy adott szint alá kerül. Lapcserénél az átmenetileg a háttértárra mentend memórialapot a Linux az ún. LFU-algoritmussal (LFU: least-frequently used) választja ki, vagyis a többiekhez képest legritkábban használt lap kerül ki a memóriából. folyamatok által

VII

VII. fejezet

A WINDOWS NT OPERÁCIÓS RENDSZER
A WINDOWS NT kialakulása
A Windows NT a Microsoft cég új generációs operációs rendszere. A Windows NT operációs rendszerrel a Microsoft a DOS, ill. Windows rendszereket kívánta felváltani. Eredetileg az OS/2-es rendszerek nyomdokán akarták az NT-s fejlesztéseiket folytatni, id közben azonban, alkalmazkodva a piaci igényekhez, a 32-bites Windows rendszerekhez közelítettek. A más Windows rendszerekt l struktúrájában is különböz operációs rendszer a New

Technology (NT) szavak rövidítéséb l kapta a nevét. Az elnevezés annyiban jogos, hogy az NT, el deit l örökölt gyermekbetegségeit l eltekintve, ténylegesen új és korszer megoldásokat alkalmaz. Az NT rövid történetének f állomásait a VII.1 ábrán látható táblázat foglalja össze:

1

VII

VII. fejezet

Megjelenés ideje

Verzió szám (bels név)

A verzió tulajdonságai, ill. újdonságai

1989. 1993. július

Az NT tervezésének kezdte. NT 3.1. Kompatibilis a WIN 3.1.-gyel; 16-bites operációs rendszer

1994. szeptember

NT 3.5 (Daytona )

Optimalizálják a rendszer méretét, és teljesítményét; hatékonyságnövelés. Power PC architektúra támogatása. Azonos küls (felhasználói interfész) a Windows 95-ös rendszerekkel. Megnövekedett hatékonyság: pl. a grafikus alrendszer, képerny kezel funkciók (a Win32-es alrendszer egyes részei) átkerültek felhasználói módból kernel módba.

1995. május 1996. július

NT 3.51 NT 4.0 (Shell Update Release ­ SUR)

0.1. ábra: Az NT történetének f állomásai

Az NT-vel szemben támasztott követelmények
A Windows NT tervezésekor a leend rendszerrel szemben támasztott követelményeket két csoportra lehet osztani. Az els csoportban azok a tulajdonságok kerültek követelmények formájában megfogalmazásra, amely tulajdonságokkal a rendszernek feltétlenül rendelkeznie kell a rendszer piaci sikere érdekében. A követelmények második csoportját inkább tervez i célkit zéseknek lehetne nevezni, mert olyan tervezési elveket és tulajdonságokat tartalmaznak, amik a rendszer átláthatóságát, karbantarthatóságát, valamint kés bbi továbbfejleszthet ségét biztosítják.

2

VII Elvárások A Windows NT-vel szemben a támasztott követelmények a következ k:

VII. fejezet

Valós 32-bites, preemptív (kiszorításos, vagyis bármikor megszakítható), újrahívható (reentrant), virtuális memóriakezelést megvalósító operációs rendszer legyen. Fusson különböz hardver platformokon. Fusson szimmetrikus multiprocesszoros környezetben, és skálázható tulajdonságával tegye lehet vé az adott környezetben rendelkezésre álló er források hatékony kihasználását. Fusson elosztott hardver környezetben; és tegye lehet vé elosztott számítási környezet létrehozását. A ,,legtöbb" 16-bites MS-DOS és Windows 3.1-es alkalmazás (applikáció) futtatását tegye lehet vé. Teljesítse a POSIX 1003.1 szabványt. (Legyen POSIX-kompatibilis.) Teljesítse az amerikai biztonsági szabványokat. Használjon UNICODE-ot a karakterek és stringek ábrázolására. A felsorolt kritériumok önmagukért beszélnek, csak az utolsóhoz szükséges némi magyarázat. A UNICODE a karakterek gépi ábrázolásának szabványa. El nye, hogy minden karaktert 16 biten ábrázol, így szinte minden nyelv ábécéjének karakterkészletét lehetséges azonos kódolást használva ábrázolni. A UNICODE-ot alkalmazva lehet ség nyílik az alkalmazások nyelvterülett l független változatának elkészítésére. Az els olyan, Microsoft által gyártott operációs rendszer, amely binárisan is egységes lesz az egész világon, a következ bejelentett verzió, a Windows 2000 (Windows NT 5.0) lesz. Az NT 4.0 a bels karakterábrázolásában már UNICODE-ot használ. Mivel az NT-s

alkalmazások nagy része még nem használ UNICODE-ot, így a string változókat paraméterként átadó programozói interfészben (Win32 API) definiált függvényeknek két változata létezik: "széles" UNICODE-os változat ami 16-bites karaktereket kezel, ill. "keskeny" ANSI változat ami 8-bites karaktereket kezel. A keskeny változatú függvények megvalósítása egyszer : el ször átkódolják a string paramétereket UNICODE-ba (a 8-bites karaktereket 16-bites karakterekké cserélik), majd meghívják az adott függvény UNICODE-os változatát. Tervez i célkit zések Az NT tervez i az operációs rendszer min ségének, ill. korszer ségének biztosítása érdekében a fenti követelmények teljesítésén felül a következ célokat t zték ki:

3

VII

VII. fejezet

Legyen az NT kódja ,,kiterjeszthet ", vagyis könnyen továbbfejleszthet . (A lehet ségeket figyelembe véve legyen nyílt rendszer.) Legyen hordozható a kód, vagyis legyen lehet ség a kés bbiekben új hardver platformokra átvinni. A legyen rendszer megbízható és robosztus (teherbíró). Ennek három vonatkozását különböztették meg: két applikáció futása ne befolyásolja egymást, egy applikáció ne dönthesse össze az operációs rendszert, az operációs rendszer bels komponensei ,,megférjenek" egymás mellett. A lehet ségekhez mérten maximálisan legyen kompatibilis a meglév rendszerekkel. Itt mind a felhasználói interfészre, mind pedig a programozói interfészre (API-ra) gondoltak. A kompatibilis rendszereknek két csoportját különböztették meg: A Microsoft korábbi operációs rendszerei: MS-DOS, Windows 3.2. Nem a Microsoft által készített, azonban széles körben elterjedt rendszerek: UNIX, OS/2, NetWare. A rendszer a hardver környezett l függetlenül legyen hatékony, vagyis a teljesítménye legyen maximális bármelyik hardver platformon.

A Windows NT, a Windows 95, és a Windows 98 összehasonlítása
A nyolcvanas évek végére a hardver eszközök fejl dése révén a Microsoft-termékek célpiacának tekintett személyi számítógépek teljesítményben annyira meger södtek, hogy már felvehették a versenyt a tradicionálisan UNIX rendszerek által uralt munkaállomásokkal (workstation). A Microsoft cég els grafikus interfészt biztosító operációs rendszerei, a 16-bites Windows család tagjai, mind a DOS rendszerre alapulva, annak továbbfejlesztéséb l alakultak ki. Ez er sen rányomta bélyegét a Windows rendszerek felépítésére és m ködésére. Az új, nagyteljesítmény PC-k felhasználói olyan igényeket támasztottak az operációs

rendszerrel szemben, amit már nem lehetett a Windows rendszerek továbbfejlesztésével kielégíteni. Ezért döntött a Microsoft egy új, struktúrájában is modern elveket követ operációs rendszer fejlesztése mellett. Ez az operációs rendszer a Windows NT. Természetesen továbbra sem hagyhatta cserben régi vásárlóit a Microsoft, így folytatta a Windows rendszerek fejlesztését is. Ennek a fejleszt munkának a terméke a Windows 95 és a Windows 98. Ezeknek az operációs rendszereknek a jellemz je, hogy bár szinte teljesen kompatibilisek a korábbi Windows rendszerekkel, funkcionalitásban fokozatosan közelítenek az NT felé. Ennek a folyamatnak a befejezése a rövidesen megjelen Windows 2000, ami már publikáltan NT-alapú rendszer lesz, vagyis a két fejlesztési szál össze fog futni.

4

VII

VII. fejezet

A közelítés egyik legfontosabb területe a felhasználói felület: a Windows NT, a Windows 95, és a Windows 98 felhasználói felületei szinte teljesen azonosak. A másik fontos területe a rendszerek kompatibilitásának a programozói felület (Application Programming Interface -API). A Win32 API közös programozói interfésze a fenti operációs rendszereknek. A felsorolt rendszerek API-ja persze nem teljesen azonos. A bennük szerepl hívások dönt többsége közös, azonban vannak olyan függvények, amelyek az egyik rendszer API-jában megtalálhatók, míg a másikban nem. Ilyen szempontból az NT 5.0 közeljöv ben várható megjelenése nagy jelent ség lesz, mivel az NT 5.0 API-ja tartalmazni fogja az összes többi rendszer API-jának hívásait. B vebb információt az API-król a

http://msdn.microsoft.com/default.asp Internet-címen lehet olvasni. Hasonlóan az NT 5.0-ban kerül alkalmazásra a Windows 98-ban kifejlesztett új készülékkezel (device driver) modell, az ún. WDM. A gyártó közös volta, ill. a fejlesztés párhuzamossága miatt nem meglep , hogy a felsorolt rendszerek kódja részben közös. Az VII.2. ábrán látható táblázatban összehasonlítjuk az NT, ill. a Windows 95, és a Windows 98 tulajdonságait. (A szimbólumok jelentése: *: teljesen megvalósított, +: részben megvalósított, -: nem megvalósított.)

5

VII

VII. fejezet

Tulajdonságok NT 95/98 Multiprocesszoros környezet * támogatása Változó HW platform * + (korlátozottan) NTFS (biztonsági hozzáférés) * 32 bites kód * + Újrahívható (több példányban, * párhuzamosan futtatható) kód 16-bites (Windows 3.1-es) * + alkalmazások futtatása (biztonságos) (összeakadhatnak) Megosztott memória elérésének csak az ér el aki mindenki elérheti korlátozása megnyitja A rendszer adatstruktúráit nem érhetik sok adatszerkezet * el az applikációk elérhet User módban nem írhatóak az * operációs rendszer adatai Windows 2000-ben (NT 5.0-ban) várható újdonságok Plug and Play képesség + Power management + Infrared támogatás + FAT32 könyvtárszerkezet támogatás + Minden Windows 3.1-es és DOS -(nem is lesz) * alkalmazás futtatása

0.2. ábra: Operációs rendszerek összehasonlítása Látható, hogy az NT 5.0 az összes fent felsorolt kedvez tulajdonsággal rendelkezni fog, egyet kivéve: Az NT nem lesz képes az összes Windows 3.1-es és DOS alkalmazást futtatni. Ezt a tulajdonságot nem is szándékoztak megvalósítani a fejleszt k, hiszen az NT struktúrájában is különbözik a régi rendszerekt l, ami lehetetlenné teszi számos alkalmazás futtatását. A Microsoft operációs rendszerekr l szólva a felsorolást a teljesség kedvéért még ki kell egészíteni a Windows CE operációs rendszerrel. A Windows CE a korábban említett rendszerekhez nagyon hasonló felhasználói felülettel, és részben közös programozói felülettel rendelkezik. A legfontosabb különbség, hogy a Windows CE valósidej (on-line)

rendszerekhez készült, vagyis garantálja a limitált válaszid t. Ez természetesen a többi rendszert l lényegesen eltér bels felépítést eredményez. A Windows CE rendszerek

felépítésér l, m ködésér l a továbbiakban csak utalások szintjén lesz szó.

6

VII

VII. fejezet

Az NT felépítésének f jellemz i
A Windows NT felépítése rétegszerkezet , számos alrendszerének m ködése a kliens-szerver architektúrára alapul. Az NT jól definiált rétegekre bomlik, mely rétegek szigorúan interfészeken keresztül érintkeznek. A szolgáltatások java részénél kliens-szerver architektúrát találunk. Nem tartották viszont szigorúan be az NT fejleszt i azt az elvet, hogy amennyiben mód van rá, a szolgáltató folyamatok felhasználói (user) módban fussanak és a rendszer a mikrokernelen keresztül érje el a hardvert. Ez azért van így, mert bizonyos szolgáltatásokat nem hatékony felhasználói módban megvalósítani. Így kernel módban azok a szolgáltatások kerültek, amelyek intenzíven használják a hardvert és futásuk gyorsaságára az egész rendszer teljesítménye érzékeny, vagyis a user módban történ megvalósításuk a rendszert nagyon lelassítaná a gyakori

környezetváltás miatt. (Ilyen pl.: a cache manager, a memóriakezel , az objektumkezel és biztonsági alrendszer, vagy a WIN32-es alrendszer grafikus szolgáltatásokat nyújtó részei, stb.)

Az NT objektumorientált szemlélete
Az Windows NT fejlesztésénél fontos szempont volt az objektum-orientált szemlélet használata. A fejleszt k igyekeztek a rendszert jól meghatározható funkcionalitású objektumokból felépíteni, mely objektumok egymással az el re definiált interfészükön keresztül érintkeznek. A határozott törekvés ellenére, a hardver-közeli programozás szüksége miatt, azonban csak az alábbi két objektum-orientált tulajdonságot valósítja meg: adatrejtés: Az operációs rendszer objektumai csak saját adataikat érhetik el. interfész-használat: Az objektumok formális interfészt használnak egymás elérésére. Ugyanakkor azonban a Windows NT nem valósítja meg a következ tulajdonságokat: polimorfizmus: Azonos néven különböz objektumokat érhetünk el. Attól függ, hogy milyen objektumra hivatkozunk az adott azonosítóval, hogy mi az azonosító használatának környezete. Például polimorfizmus, amikor azonos névvel, de különböz paraméterlistával definiálunk objektum-orientált

7

VII

VII. fejezet

függvényeket egy objektumon belül. Ekkor az aktuálisan használt paraméterek típusától függ, hogy melyik funkciót érjünk el. örökl dés: Az objektumoknak hierarchikus származási rendszere létezik. A származtatott objektum örökli, és így használhatja a szül megfelel en definiált adatelemeit ill. függvényeit. dinamikus adattípus kötés: Definiálhatóak adattípussal paraméterezett objektumok.

8

VII

VII. fejezet

A WINDOWS NT felépítése
A Windows NT felépítését a VII.3. ábrán mutatjuk be. A téglalapok az egyes komponenseket szemléltetik, a köztük lév kapcsolatot a nyilak mutatják. Jól láthatók az egymásra épül rétegek, ill. az ket összeköt interfészek. 0.3. ábra: A Windows NT felépítése

Rendszer folyamatok Service conroller WinLogon Session Manager

Szolgáltatások TCP/IP Helper Event Log RPC Service

Alrendszerek POSIX conroller OS/2 Win32

Felhasználói Applikáció Felhasználói Applikáció Felhasználói Alrendszer DLL alkalmazás Alrendszer DLL Alrendszer DLL

NTDLL.DLL user mód Rendszer szálak kernel mód

Executive API I/O System Cache kezel File rendszer Device driver-ek Folymat és szál kezel Biztonsági alrendszer Virtuális memória kezel Win32 USER, GDI

Objektum kezel HAL Kernel

A következ funkcióit.

fejezetekben részletesen bemutatjuk az NT komponenseit, ismertetve azok

HAL (Hardware Abstraction Layer)
A HAL (Hardware Abstraction Layer) az aktuálisan használt hardvert teljesen elfed , legalacsonyabb szoftver réteg. Az operációs rendszer HAL fölötti rétegei (vagyis a device driver-ek, ill. a kernel) csak ezen keresztül érheti el a hardvert. Minden processzorhoz, amelyen az NT-t implementálták, készül külön HAL réteg, vagyis a HAL a használt processzor típusától függ. Egy adott rendszerben az aktuálisan használt HAL réteget a rendszer telepítésekor választja ki.

9

VII

VII. fejezet

A HAL igyekszik az általa rejtett processzortól független szolgáltatásokat nyújtani a többi réteg számára. Azonos architektúrájú processzorok esetén ez teljesül is, vagyis pl. az x86 típusú processzorokon futó NT rendszerek között csak a HAL-ban van különbség. Úgy is tekinthetjük, hogy a HAL az aktuális hardverre támaszkodva egy virtuális gépet valósít meg, amelynek funkcionalitása minden rendszerben azonos.

Kernel
A kernel a rendszer állandóan memóriában lev kernel (védett) módban futó része. A kernel a HAL-on kívül az egyetlen hardver-függ része az NT-nek. Azonban míg a HAL a processzor típusától függ, addig a kernel csak a processzor architektúrájától. Ez azt jelenti, hogy azonos felépítés processzorok esetén a kernel is azonos, csak eltér felépítés processzorok esetén lehet különbség. Pl. két x86-os processzor alapú rendszerben a kernel réteg is azonos attól függetlenül, hogy konkrétan milyen processzort használunk. Egy RISC alapú rendszerben azonban a kernel réteg is különbözni fog. Az adott konfigurációban használt HAL-t az NT installálásakor választja ki. Az installáló CD-n így számos HAL-t találhatunk. Érdemes megnézni az NT CD \i386­os alkönyvtárát. Fontos látni, hogy a kernel és a rá épül további komponensek csatlakozási felülete már hardver-független. Ebb l következik, hogy a rendszer további komponensei is hardverfüggetlenek, vagyis hordozhatók. Az NT hordozhatósága tehát úgy valósul meg, hogy a hardvert minden processzoron hasonló interfésszel elérhet szoftver rétegek fedik el. Ez a két hardver réteg a HAL és a kernel. A kernelben kerültek megvalósításra a processzorok architektúrájától függ funkciók (pl. szálak környezetváltása), míg a HAL az azonos architektúrájú processzorok adott típusától függ funkcióit tartalmazza. A hordozhatóságról szólva meg kell említeni a hordozhatóság másik eszközét, nevezetesen azt, hogy az NT ­ a UNIX rendszerekhez hasonlóan ­ hordozható programnyelven íródott. A kód túlnyomó része C-ben készült. A grafikus alrendszernek és a felhasználói interfésznek egy kisebb részét C++-ban fejlesztették. Assembly nyelven csak a hardver közvetlen kezelését végz (pl. IT kezelés), vagy a rendszer teljesítményét nagymértékben befolyásoló (pl.

környezetváltás) részek íródtak.

10

VII

VII. fejezet

A kernel feladata, a rendszer további részeinek a hardvert l történ teljes elhatárolásán túl, hogy az operációs rendszer többi komponense számára egyszer , jól definiált m ködés alapmodulokat (ún. primitíveket) biztosítson. A primitívek a következ funkciókat valósítják meg: thread (szál) ütemezés, trap-kezelés és kivételkezelés, IT-kezelés, multiprocesszor-ütemezés, kernel objektumok kezelése. A kernel objektumok egyszer bbek, mint a többi réteg objektumai, mert a gyors kezelés érdekében a kernel nem végez ellen rzést az egyes objektumok elérésekor, megbízik abban, hogy a rendszer tagjai helyesen használják az objektumokat.

Készülékkezel k (device driver-ek)
A device driver-ek az I/O alrendszer és a hardver között teremtenek kapcsolatot. Mint már említettük, nem közvetlenül érik el a hardvert, hanem a HAL rétegen keresztül. Ez pl. lehet vé teszi, hogy a device driver-ek forráskódban hordozhatók különböz hardver

architektúrák között, és akár binárisan is hordozhatók azonos architektúrájú, de különböz típusú processzorok esetén. A device driver-ek három típusát különböztetjük meg: Hardver driver-ek, melyek a hardver egységek elérését biztosítják, az eszközök közvetlen beés kimeneteit kezelik. Fájlrendszer driver-ek, melyek a fájlrendszerek elérését biztosító kéréseket fogadnak el és I/O kérésekké transzformálják azokat. Sz r típusú device driver-ek, melyek az ún. réteg szerkezet device driver struktúra lehet ségeit kihasználva speciális többletfunkciókat valósítanak meg. A sz r típusú device driver-ek általában a magasszint (pl. fájlrendszer driver-ek) és az I/O kéréseket kezel alacsony szint driver-ek közé ékel dnek. Hálózat elérését biztosító device driver-ek, melyek a hálózati kéréseket szolgálják ki, ill. továbbítják azokat. Az NT ún. réteg szerkezet device driver struktúrát használ, ami lehet vé teszi a funkciók szétválasztását, ill. rugalmas driver szerkezet kialakítását. A réteg szerkezet struktúrának köszönhet en lehet ség van a hagyományosakon túl olyan driver-ek használatára is, amelyek lehet séget adnak többletfunkciók megvalósítására, mint pl. a redundáns adattárolás merevlemezek tükrözésével vagy több lemezen tárolt fájlrendszer kezelése. Ezekr l a lehet ségekr l a kés bbiekben részletesen is lesz szó.

11

VII

VII. fejezet

Executive
Az executive réteg az operációs rendszerek magasszint szolgáltatásait nyújtó alrendszereket megvalósító rétege az NT-nek. Önálló részei a következ k: Folyamat és szál kezel Virtuális memória kezel Biztonsági alrendszer (monitor) Cache kezel I/O rendszer kezel Az executive réteg tartalmazza az NTDLL.DLL által definiált függvények hívásainak megvalósítását, valamint biztosítja a operációs rendszer bels kommunikáció lehet ségét. Az executive réteg legfontosabb szolgáltató funkciója az LPC (Local Procedure Call, lokális eljáráshívás) szolgáltatás megvalósítása. Az LPC az NT IPC (Inter Process Communication, folyamatok közötti kommunikáció) eszköze. Ennek segítségével egy felhasználói objektum egy másik felhasználói objektum függvényét hívhatja meg. Így érhetik el pl. az egyes alkalmazások a hozzájuk tartozó alrendszer szolgáltatásait. Ezen felül az executive réteg tartalmaz run-time library függvényeket és különböz támogató funkciókat megvalósító objektumai közötti

függvényeket a rendszerfolyamatok és szolgáltatások számára.

Rendszerfolyamatok
Rendszerfolyamatok közé az operációs rendszer azon funkcióit megvalósító önálló folyamatok tartoznak, amelyek független felhasználói folyamatként kerültek megvalósítva. Fontos kiemelni, hogy bár user módban futó folyamatokról van szó a rendszerfolyamatok alapvet részei az operációs rendszernek, futásuk nélkül az NT nem képes m ködni. Fontos rendszerfolyamatok: SMSS (Session Manager): A rendszer indításakor létrehozott folyamat, ami az alkalmazások elindításáért felel s. Az SMSS indítja el az egyes alrendszereket, ha futásukra szükség van, és még nem futnak; biztosítja a kapcsolatot a debugger és az általa futtatott applikáció között; valamint biztosítja a környezeti változók definiálásának és elérésének lehet ségét. Logon:

12

VII A felhasználók ki- és beléptetését intéz Attention Sequence) billenty

VII. fejezet folyamat. Minden ún. SAS (Secure (alapesetben: CTRL-ALT-DEL)

kombináció

aktivizálja. Beléptetéskor a felhasználói azonosító (username) és jelszó (password) kombinációt az önálló folyamatként futó Local Security Authentication Server-hez (LSASS) továbbítva ellen rzi. Ha az azonosítás sikeres, elindítja a USERINIT.EXE programot, ami beállítja a felhasználó által definiált környezetet, és elindítja az általa kért shell-t (alapesetben: EXPLORER.EXE). Service Controller: A szolgáltatások indításáért és leállításáért felel s folyamat.

Szolgáltatások
Az NT-ben szolgáltatásnak hívják azokat a kliens-szerver modellben szerverként m köd szolgáltató folyamatokat, amelyek a kliens programok (felhasználói vagy akár rendszer programok) számára az operációs rendszer lehet ségeire építve többletszolgáltatásokat nyújtanak. Létezik pl. RPC (Remote Procedure Call) szolgáltató, különböz protokollokat megvalósító hálózati kapcsolatot biztosító szolgáltatók, vagy az NT-specifikus

eseménynaplózó (event logger) szolgáltató. (Megjegyzend , hogy egy-egy szolgáltatást gyakran nem egyetlen folyamat valósít meg.) A szolgáltatások a rendszerfolyamatokhoz hasonlóan felhasználói módban futó folyamatok. Lényeges különbség azonban, hogy míg a rendszerfolyamatok szükséges részei a rendszernek, addig a szolgáltatásokat megvalósító folyamatok futása nélkül is képes m ködni az NT. A szolgáltatások a Service Manager segítségével elindíthatók és leállíthatók a rendszer m ködése közben. A szolgáltatásokat megvalósító programok egyszer Win32-es alkalmazások, azzal a

különbséggel, hogy együttm ködnek a Service Conroller (SERVICES.EXE) folyamattal. Az regisztrálja ket, és annak segítségével lehet ket elindítani, leállítani, szüneteltetni stb. A rendszerben elérhet szolgáltatásokat és azok aktuális státuszát a felhasználói felületr l is megnézhetjük és változtathatjuk a Control Panel-en a Services ikonra kattintva. (Egy szolgáltatásnak így három elnevezése is lehetséges: Az els az a név, ahogy a szolgáltatás a Control Panel / Services alpontján keresztül elérhet , a másik az a név, amin az a Registryben szerepel, a harmadik pedig az a név, amely a szolgáltatást megvalósító futtatható program neve.)

13

VII

VII. fejezet

NTDLL.DLL
Az NTDLL.DLL az a dinamikusan kapcsolódó könyvtár (Dinamically Linked Library -DLL), amin keresztül a felhasználói módú folyamatok elérhetik az NT-t. Mivel az egyes objektumok közötti kapcsolattartás az LPC mechanizmuson keresztül történik, így minden felhasználói objektum ­ mint a 2.1. ábrán is látható volt ­ az NTDLL.DLL-en keresztül éri el a környezetét. Az NTDLL által megvalósított m ködés egyszer . Ha egy hívás érkezik, ellen rzi a hívás paramétereit, és megvalósítja a user­kernel módváltást, majd meghívja az NT kért funkciót megvalósító függvényét.

Alrendszerek
Mint már említettük, az NT alkalmas különböz típusú applikációk futtatására. Ezt az

alrendszerek segítségével valósítja meg. Három alrendszere van: Win32, POSIX, és az OS/2. A Win32 alrendszer kitüntetett abban a tekintetben, hogy a Win32 alrendszer nélkül az NT nem tud futni. A másik két alrendszer opcionális, csak abban az esetben kezdenek futni, amikor az adott alrendszerhez tartozó alkalmazást akar egy felhasználó elindítani. Az alrendszerek els dleges feladata, hogy a hozzájuk tartozó alkalmazások futtásához szükséges szolgáltatásokat nyújtsák. Minden alrendszer a hozzá tartozó alkalmazásokat kontrollálja. Minden alrendszerhez tartozik egy ún. alrendszer DLL, amin keresztül az alrendszerhez tartozó alkalmazás az NT szolgáltatásait elérheti. Ez tehát a programozói interfész (API, Application Programming Interface), ami az egyes alrendszerekhez tartozó applikációk számára elérhet . Ezt azért fontos kiemelni, mert ez az a publikált, jól definiált felület, amit minden program használhat. Az összes többi interfész (pl. NTDLL.DLL) nem publikus interfész. Az egyes alrendszerekhez tartozó API-k lényegesen különböznek egymástól. A legszélesebb lehet ségeket a Win32 API biztosítja (pl. ablakozás, szálak kezelése stb.). Fontos tudni, hogy egy applikáció csak egy alrendszerhez tartozhat, nem keveredhetnek egymással egy applikáción belül különböz alrendszerhez tartozó hívások.

14

VII POSIX alrendszer

VII. fejezet

A POSIX alrendszer szigorúan a POSIX 1003.1-es szabványban rögzített tulajdonságokat valósítja meg. Így van lehet ség új folyamatok létrehozására (fork), fájlok több néven történ elérésére (hard link-ek definiálására), folyamatok közötti kommunikációra (IPC), folyamatok kezelésére, valamint karakteres I/O kezelésére. Ezzel szemben nincs lehet ség szálak (thread) létrehozására, ablakkezelésre, távoli eljáráshívásra (RPC elérésére), socket-ek használatára. (A UNIX alkalmazások hordozása érdekében készítettek már a szabványos POSIX alrendszernél szélesebb lehet ségeket megvalósító POSIX alrendszereket, ill. POSIX API-t, valamint vannak olyan programkönyvtárak, amelyek lehet vé teszik, hogy egy POSIX (UNIX) alkalmazást Win32-es futtatható állománnyá fordítsunk.) Win32 alrendszer A Win32 alrendszer futtatja nemcsak a 32 bites alkalmazásokat (vagyis azokat, amelyek Win32 API-t használnak), hanem a 16 bites és DOS alkalmazásokat is. A Win32 alrendszer nem csak abban különbözik a többit l, hogy nélküle nem futhat az NT, hanem abban is, hogy az alrendszer egy része kernel módban fut. (WIN32K.SYS) Ez a rész valósítja meg a grafikus képerny -kezelési funkciókat. (A USER32.DLL, GDI.DLL, KERNEL32.DLL, ADVAPI.DLL könyvtárakban definiált funkciókat.) Ez a rendszer hatékonysága miatt került ide, mert így módváltás nélkül lehetséges az executive, ill. kernel szolgáltatások (függvények) elérése.

A Win32 API-hívások háromfélék lehetnek a megvalósításuk helye szerint: alrendszer DLL-ben van megvalósítva: Ezek egyszer funkcionalitású függvények, a végrehajtásukhoz nincs szükség a rendszer más részeinek elérésére. Az alrendszerben vannak megvalósítva: A hívást ebben az esetben az alrendszer DLL továbbítja az NTDLL.DLL felé, ami az executive réteg LPC szolgáltatását igénybe véve, eljut a Win32 alrendszerhez, ami a kérést teljesíti. Az NT más kernel módban futó rétege valósítja meg a hívást: A hívás ebben az esetben is az executive réteghez kerül, ami továbbítja a megfelel kernel réteg felé. A WIN32 API-ban számos grafikus funkció van definiálva. A grafikus eszközök és a nyomtató szabványos felületen történ kezelését a GDI (Graphical Device Interface), ill. a 15 Az

VII

VII. fejezet

hozzá tartozó GDI32.DLL (WIN32 API része) teszi lehet vé. Az ebben definiált funkciók a WIN32 alrendszer kernel módú részében (WIN32K.SYS) vannak megvalósítva. Ezek a rutinok intézik az eszközökhöz tartozó device driver-ek meghívását. Egy-egy GDI32.DLLben definiált grafikus funkcióhoz az adott eszközt l függ en akár több device driver is tartozhat.

A WINDOWS NT bels mechanizmusai
A Windows NT számos olyan mechanizmussal rendelkezik, amelyeket a kernel módú komponensek, mint az executive, valamint a device driver-ek használnak. Eben a fejezetben a következ rendszermechanizmusokat fogjuk bemutatni: megszakítás- és kivételkezelés. executive objektumkezelés. szinkronizáció. lokális eljárás hívás (Local Procedure Calls -LPC's).

Megszakítás- és kivételkezelés
A megszakítások (interrupt, IT) és a kivételek (exception) olyan események az operációs rendszerben, amelyek a CPU-t eltérítik az utasítások normál végrehajtási sorrendjét l. A megszakításokat és a kivételeket detektálhatják a rendszer hardver, és szoftver komponensei egyaránt. Az NT-hez kapcsolódó szóhasználatban a trap (csapda) fogalom a processzor azon mechanizmusát jelöli, amelynek segítségével az egy végrehajtás alatt lev szálat állít meg egy megszakítás, vagy egy kivétel hatására. A trap mechanizmus a processzort felhasználói módról kernel módra kapcsolja át, és a vezérlést az operációs rendszer egy fix helyére, a trapkezel rutinra adja át. A trap-kezel eldönti, melyik operációs rendszer komponens képes a magszakítást, vagy kivételt kiváltó eseményt lekezelni. A teljes képhez hozzátartozik, hogy a trap-kezel aktivizálódik a rendszer hívások végrehajtásakor is, amikor a megszakítások és kivételek kezeléséhez hasonlóan a rendszernek kernel módba kell váltania. A trap-kezel és az általa megvalósított funkciók összefoglalását a VII.4. ábrán láthatjuk.

16

VII

VII. fejezet

Trap kezel IT IT diszpécser

IT rutinok

Rendszer szolgáltatás hívás

Rendszer szolgáltatás diszpécser

Rendszer szolgáltatások

Kivételek (HW/SW)

Kivétel diszpécser

Kivétel kezel rutinok

Virtuális memória kivételek

Virtuális memóriakezel lapkezel je

0.4. ábra: A trap-kezel m ködése Bár általában igaz az, hogy a megszakítást hardver egység, a kivételt pedig szoftver komponens idézi el , ez nem feltétlenül igaz minden esetben. Hardver eredet kivételre példa a busz-hiba által kiváltott kivétel melynek forrása hardver meghibásodás. Szoftver által generált megszakításra is találunk b ségesen példát az NT-ben. Az NT kernel szoftver megszakításokkal kezeli néhány esetben a futó szál váltását, az id zített óra lejárását, illetve néhány szinkron I/O folyamatot. A megszakítások típusa és prioritása A különböz processzorok különböz számú és típusú megszakítást képesek felismerni. Az megszakításokhoz prioritási szinteket (ún. Interrupt Request Level -IRQL) rendel az operációs

17

VII rendszer. A párhuzamosan érkez

VII. fejezet megszakítások kiszolgálása a prioritási szinteknek

megfelel en történik. A magasabb prioritású IT megszakítja az alacsonyabb prioritású IT kiszolgálását. A VII.5. ábra a DEC Alpha processzorhoz tartozó megszakítási szintek tábláját (IRQL-táblát) mutatja be, aVII.6. ábra pedig az Intel x86-os processzorokhoz tartozót. 7 6 5 4 3 2 1 0 Fels szint Processzor ­ IT Órajel I/O-eszköz/Fels szint I/O-eszköz Késleltetett eljáráshívás Aszinkron eljáráshívás Alsó szint

0.5. ábra: IRQL tábla az Alpha processzornál 31 30 29 28 Fels szint Tápfeszültség-kimaradás Processzor ­ IT Órajel I/O-eszköz(n) . . . I/O-eszköz(2) I/O-eszköz(1) Késleltetett eljáráshívás Aszinkron eljáráshívás Alsó szint

2 1 0

0.6. ábra: IRQL tábla az Intel X86 processzoroknál Az megszakítások fels szintjei a hardver-megszakításokra vannak fenntartva. Az 1-es és 2-es szintek mindkét táblázatban a szoftver-megszakítások. A késleltetett eljáráshívást eredményez IT-re egyes szálak biztonságos végrehajtása érdekében van szükség. Az

aszinkron eljáráshívások a felhasználói programok, ill. rendszerprogramok számára biztosítanak lehet séget, hogy egy másik felhasználói szálon hajthassanak végre (hívjanak meg) egy eljárást. A legalsó, nullás szint a normál szálvégrehajtáshoz tartozik. Ezen a szinten minden IT engedélyezett.

18

VII Kivételkezelés

VII. fejezet

A bármikor fellép megszakításokkal ellentétben a kivételek olyan feltételek, amelyek egy futásban lev program végrehajtása következtében jönnek létre. A kivételeket egy speciális kernelmodul, a kivétel-felügyel (exception dispatcher) dolgozza fel. A kivétel-felügyel

els dleges feladata az aktuális kivétel azonosítása: memória-túlcímzés, nullával való osztás, egész-túlcsordulás, lebeg pontos kivételek, a nyomkövet töréspontjai, stb. Ezek mindegyike architektúra-független eset. Amikor egy kivétel lép fel, a kernelben egy eseményláncolat indul el. A CPU a vezérlést a kernel trap-kezel jének adja át. Ez egy ún. trap-keretet állít el , amely mindazt az információt tartalmazza, ami a kivételkezelés befejezése utáni visszatéréshez (újrakezdéshez) szükséges az operációs rendszer számára. A trap-kezel ezen kívül még el állít egy rekordot, ami a kivétel eredetét rögzíti, és más szükséges információt tartalmaz. A nyomkövet felügyel els programok töréspontjai rendszeresen kivételforrások. Emiatt a kivételteend je annak ellen rzése, hogy a kivétel egy nyomkövet folyamattól

származik-e.

Objektumkezelés
A Windows NT-ben lev executive egyik komponense az objektumkezel (object manager), amely az objektumok el állítására, törlésére, védelmére, és kezelésére szolgál. Az objektumkezel összefogja az er forrás-kezel m veleteket, hogy azok ne legyenek

szétszórva az operációs rendszer egyes komponenseibe. Az objektumkezel t a következ célok elérésére tervezték: Egységes mechanizmust biztosítson a rendszer er forrásainak elérésére ill. használatára. Az objektumok védelmét megvalósító kód egy helyre legyen összegy jtve, a C2-es szint biztonság elérése érdekében. Lehet séget biztosítson a folyamatok objektumhasználatának figyelésére, amivel lehet ség van korlátozni a rendszer er forrásainak használatát. Olyan objektum-elnevezési módszert valósítson meg, ami lehet vé teszi a létez objektumcsoportok egyszer megkülönböztetését. Elégítse ki a különböz alrendszerek által támasztott követelményeket: például egy folyamat legyen képes er forrásokat örökölni szül jét l (erre szükség van a Win32-es és a POSIX alrendszernél), vagy lehessen kis- és nagybet t megkülönböztet (case sensitive) neveket használni (ami a POSIX alrendszer követelménye). Egységes szabályok szerint kezelje az objektumok ,,életben tartását", vagyis egy objektum mindaddig álljon rendelkezésre, amíg az összes folyamat be nem fejezte használatát. 19

VII

VII. fejezet

Belülr l a Windows NT kétfajta objektummal rendelkezik: executive objektummal és kernel objektummal. Az executive objektumokat az executive réteg különböz komponensei hozzák létre, mint például a folyamatkezel , memóriakezel , I/O alrendszer, stb. A kernel objektumok sokkal egyszer bbek, mint az executive objektumok. Olyan alapvet funkciókat valósítanak meg, mint pl. a szinkronizáció, amely funkciókra az executive objektumok is épülnek. Az executive objektumok általában több kernel objektumból épülnek fel. Amikor egy folyamat létrehoz és megnyit egy objektumot név szerint, akkor egy ún. handle-t kap vissza (a szó jelentése fogantyú, nyél, de a magyar elnevezést nem tartjuk megfelel nek). A handle az objektumhoz való hozzáférési információt tartalmazza. Valójában nem más, mint egy összetett elérési cím, egy összetett pointer, aminek használatával jóval gyorsabban lehet elérni egy objektumot, mint a név szerinti kereséssel.

Szinkronizáció
A kölcsönös kizárás megvalósítása alapvet els sorban az nem osztott elérés fontosságú az operációs rendszerekben

er források használatának szabályozására (pl. akár a

rendszer összetett adatszerkezetei esetén). A kölcsönös kizárás különösen fontos a Windows NT esetében, amely támogatja a szorosan csatolt szimmetrikus-multiprocesszoros hardver architektúrát. Az egyes processzorok ugyanazt a rendszerkódot hajtják végre egyidej leg, bizonyos, közös memóriában tárolt adatstruktúrák megosztásával. A Windows NT-ben a kernel feladata a több szál által is használt adatstruktúrák használatának összehangolása. A kernel ennek a feladatnak a megoldására a kölcsönös kizárást megvalósító alapmodulokat (ún. primitíveket) tartalmaz. Ezeket a primitíveket a kernelen kívül az executive réteg is használja a közös adatstruktúrák elérésének id beli összehangolása, szinkronizálása céljából. Kernel szinkronizáció A kernel kód végrehajtásának különböz fázisaiban a kernelnek garantálnia kell, hogy egy kritikus szakaszt kizárólag csak egyetlen processzor hajt végre. A kernelben a kritikus

20

VII szakaszokban lév

VII. fejezet kódrészek módosítják a globális adatstruktúrákat (pl. a késleltetett

eljáráshívások várakozási sora vagy a kernel dispatcher adatbázisa). A szinkronizáció során a legnagyobb gondot a megszakítások jelentik. El fordulhat például, hogy a kernel egy globális adatstruktúrát módosít, amikor egy olyan IT lép fel, aminek az kezel rutinja éppen ugyanazt a struktúrát módosítaná. Egy processzor esetén a Windows NT a következ mechanizmust alkalmazza: A kernel a globális er források használata el tt programja ugyanazt az

ideiglenesen letiltja azokat az IT-ket, amelyeknek az IT-kezel

er forrást használja. Ehhez fel kell emelnie a processzor futási szintjét a szóban forgó megszakítások közül a legmagasabb szintjére. Ez a megoldás azonban nem elégséges több processzor esetén. Ugyanis a futási szint megemelése egy processzornál még nem akadályozza meg egy megszakítás fellépését egy másik processzoron. A kernelnek azonban ilyenkor is garantálnia kell a kölcsönös kizárást az er források használatakor. A kölcsönös kizárás megvalósítására Windows NT ezért az egyedi lezárás (locking) módszerét alkalmazza. A kizárással használandó er forrásokat - így a globális adatstruktúrákat - használatuk el tt az er forrást használni kívánó szálnak le kell zárnia, meg kell szereznie az er forráshoz tartozó ún. spinlockot. Amíg ezt nem tudja megtenni, várakoznia kell. A rendszer az egyes hozzáférési igényeket sorba állítja, és a lezárás megsz nésekor mindig csak egy várakozót enged tovább. Executive szinkronizáció A multiprocesszoros környezetben az executive réteg komponenseinek is szinkronizálnia kell a globális adatstruktúrákhoz való hozzáférést. A kernel funkciók hívásakor az executive is használhatja a lezárás módszerét. Ez azonban csak részben oldja meg az executive réteg szinkronizációs igényeit. Mivel egy lezárás feloldására történ várakozás ténylegesen is

várakoztatja az érintett CPU-t, a megoldás csak az alábbi korlátozásokkal alkalmazható: A védett er forrásnak gyorsan elérhet nek kell lennie, anélkül, hogy más kóddal komplikált kapcsolatban állna. A kritikus szakaszok nem page-elhet k ki a memóriából, nem hívhat küls eljárásokat (rendszerszolgáltatást sem), továbbá nem generálhat megszakítást vagy kivételt. A fenti szigorú korlátozások sajnos nem tarthatók be minden esetben. Ráadásul az executive réteg különböz m ködéseinek szinkronizációja nemcsak a kölcsönös kizárást, hanem más típusú szinkronizációt (el idej ség, egyidej ség) is igényelnek. Ezen felül szinkronizációs lehet séget kell biztosítani a felhasználói alkalmazások számára is.

21

VII

VII. fejezet

Mindezeket a feladatokat speciális szinkronizációs objektumok kezelésével valósítotja meg a Windows NT. Ezeket az objektumokat együttesen diszpécser objektumoknak (dispetcher object) nevezzük. A rendszer biztosít megfelel függvényhívásokat (WaitForSingleObject, WaitForMultipleObject), melyek meghívásakor az ütemez az adott szálat várakozó (waiting) állapotba viszi és berakja a megnevezett objektum várakozási sorába. Az objektum

felszabadulásakor a rendszer az objektum típusától függ en egy vagy több várakozó folyamatot futásra kész (ready) állapotba tesz. A dispatcher object-ek között létezik pl. a kölcsönos kizárást megvalósító ún. mutex objektum, mely esetén mindig csak egy várakozó szál lesz futásra kész, de van olyan, mint pl. a semaphore, ahol ­ a semaphore inicializálási értékét l függ en ­ akár több is lehet. S t létezik olyan dispatcher object is ­ a timer ­, ami szbaddá válása (lejárása) esetén minden az objektumra várakozó szál átkerül a ready állapotba. Így az executive rétegben lehet ség van bonyolult szinkronizációs feladatok megoldására is. Az dispatcher object-ek és azokat kezel hívások egy része a Win32 API-n keresztül is elérhet lehet vé téve a szinkronizációt a felhasználói alkalmazások számára is.

Lokális eljáráshívás
A lokális eljáráshívás (Local Procedure Call -LPC) a folyamatok közötti kommunikációra ad lehet séget, nagysebesség üzenettovábbítás formájában. Ez a bels mechanizmus csak a Windows NT operációs rendszer komponensei számára áll rendelkezésre, a Win32 API-n keresztül nem érhet el. Két példa az LPC-k használatára: Távoli eljáráshívások (Remote Pprocedure Call) LPC-t használnak akkor, ha a kommunikáló folyamatok ugyanazon a rendszeren belüli vannak. A felhasználói bejelentkezéseket kezel WinLogon processz LPC hívásokat használ arra, hogy kommunikáljon helyi biztonsági jogosultság ellen rz szerverrel (LSASS). Az LPC kommunikációt leggyakrabban az NT szolgáltatásait megvalósító szerver folyamatok használják a kliens folyamatokkal történ kapcsolattartásra. LPC-kapcsolat létrehozható két felhasználói módú folyamat között, vagy egy kernel módú komponens és egy felhasználói módú folyamat között. Az LPC az üzenetváltás három különböz formáját teszi lehet vé: A 256 bájtnál rövidebb üzenet úgy küldhet el, hogy az LPC üzenet küldésekor közvetlenül megadjuk egy pufferben az üzenetet. Az üzenetet a rendszer a híváskor átmásolja a saját címtartományába, majd onnan a hívott folyamat címtartományába. 22

VII

VII. fejezet

Ha egy kliens és egy szerver 256 bájtnál több adatot szeretne továbbítani, akkor midketten egy meg kell hogy nyitssanak egy osztott elérés memóriaterületet. A küld az üzenetet eltárolja az osztott elérés memóriába, majd egy rövid LPC üzenetet (lásd els eset) küld a hívott folyamatnak, melyben egy pointert ad az üzenet kezdetére. Ha egy szerver több adatot akar írni vagy olvasni, mint amennyi az osztott elérés memórialapon elférne, akkor a szerver folyamat ­ megfelel elérési tokenek megszerzése után ­ közvetlenül is elérheti a kliens címtartományát, ahonnan tud olvasni és oda írni. A üzenetváltás szinkronizálására megint csak rövid üzeneteket (lásd els eset) használhatnak a kommunikáló folyamatok.

Folyamatok kezelése és ütemezése
Ebben a fejezetben azokat az adatstruktúrákat és algoritmusokat mutatjuk be, amelyek a folyamatokkal és szálakkal kapcsolatosak a Windows NT 4.0-s operációs rendszerben.

A Windows NT folyamat modellje
A folyamatok az NT-ben egy adott program kódját végrehajtó (egy vagy több) szálból, balamint a szálak által lefoglalt er forrásokból állnak. Az NT folyamat modellje a következ dolgokat foglaja magába: A végrehajtandó program kódját és adatait. Saját virtuális memória címteret, amit a folyamat használhat. Rendszerer forrásokat (szemaforokat, fájlokat, stb.) amiket az operációs rendszer foglal a folyamat számára, amikor a folyamathoz tartozó szálak azokat megnyitják. A folyamat egyedi azonosítóját (process ID, PID). Legalább egy végrehajtható szálat. A szál az az egység (entitás) az NT-ben, amit az ütemez kezel és végrehajtásra ütemez a CPU-hoz. A szálak a következ komponensekb l állnak: A szálat végrehajtó processzor regiszterei, melyek a processzor állapotát írják le. Két veremtárat (stack). Egyet a kernel módban történ program-végrehajtáshoz, egyet a felhasználói módban történ program-végrehajtáshoz. Kizárólagosan használható tárterületet a DLL-ek, run-time könyvtárak számára. A szál egyedi azonosítóját (thread ID). (Megjegyzend , hogy a thread ID és a process ID ugyanabból a névtérb l adja a rendszer, így egy rendszerben sohasem két egyez .) A felsorolás els három elemét együttesen a szál környezeteként (thread context) emlegetjük. Láthatjuk, hogy az egy folyamathoz tartozó szálak közös virtuális címtartományt használnak. Az egyes folyamatok viszont külön címtartományban futnak, csak osztott elérés memória használata esetén lehet átfedés két folyamat által használt memóriaterület között.

23

VII

VII. fejezet

A folyamatok ill. egészen pontosan a folyamatokat alkotó szálak által használni kívánt memóriaterületeket természetesen a rendszert l kérni kell, le kell foglalni azokat. A memóriához hasonlóan a folyamatnak le kell foglalni a folyamat által használni kívánt er forrásokat, amelyeket az NT objektumokként reprezentál. Minden ilyen objektumhoz a megnyitása után a folyamat a gyorsabb elérés érdekében egy ún. handle kap. A rendszer er forrásainak védelme, ill. az er forrás használat szabályozása érdekében minden folyamat rendelkezik egy ún. elérési token-nel, mely tartalmazza a folyamat biztonsági azonosítóját, ill. a folyamat jogosultságainak leírásását. Az NT folyamatmodelljének vázlatos képét a következ a VII.7: ábrán láthatjuk.

folyamat elérési token

virtuális memória leíró

virtuális memória leíró

virtuális memória leíró

virtuális címtér leírás handle táblázat handle handle handle objektum objektum objektum

szál szál elérési token szál

0.7. ábra: A Windows NT folyamat modellje 24

VII

VII. fejezet

Folyamatok kezelése a Windows NT-ben
A Windows NT executive rétege a folyamatokhoz tartozó adatokat egy ún. folyamatblokkban (EPROCESS) tárolja. Minden folyamathoz hozzárendel az NT egy ilyen adatstruktúrát a folyamat indulásakor. A blokk a folyamat kísér adatait tartalmazza, valamint egy sereg mutatót a kapcsolódó adatstruktúrákra. Például minden folyamaton belül van egy vagy több szál, ahol a szálakat ún. executive szálblokkok (ETHREAD) ír le. Az EPROCESS blokk és a hozzá tartozó adatstruktúrák a rendszer címterében helyezkednek el. Kivétel ezalól a folyamat futási környezetét leíró ún. folyamat-környezeti blokk (Process Environment Block - PEB), amely a folyamat címterében található. Ennek oka, hogy ez az adatstruktúra olyan információt tartalmaz, amit a felhasználói módban futó kód is megváltoztathat. Az EPROCESS blokkon felül a Win32 alrendszer folyamata is kezel egy folyamatleíró adatstruktúrát (W32PROCESS). Minden Win32 kódot végrehajtó folyamathoz tartozik egyegy ilyen adatstruktúra. A folyamatok és szálak adatstruktúrájának egyszer sített vázlatát a VII.8. ábrán mutatjuk be.

25

VII Folyamatkörnyezeti blokk Szálkörnyezeti blokk

VII. fejezet

Folyamat címtere Rendszer címtere Folyamatblokk (EPROCESS) Win32 folyamat blokk Handle tábla Szál blokk (ETHREAD)

0.8. ábra: Folyamatokhoz és szálakhoz tartozó adatstruktúra

Folyamat létrehozása (CreateProcess): Egy Win32 folyamat akkor jön létre, amikor egy alkalmazás meghívja a Win32 CreateProcess függvényét. A létrehozás több fázisból áll, amelyeket az operációs rendszer három részlete valósít meg: a Win32 kliens-oldali könyvtárából a KERNEL32.DLL, a Windows NT executive, valamint a Win32 alrendszer folyamat (CSRSS). Mivel a Windows NT több környezeti alrendszert kezel, emiatt egy Windows NT executive réteg processz objektumának kezelése (amit más alrendszerek is tudnak használni) szét van választva attól a tevékenységt l, ami a Win32 folyamat létrehozásával jár. A következ felsorolás összefoglalja a Win32 CreateProcess hívásának f bb lépéseit: A processzen belül végrehajtandó image-fájl (.EXE) megnyitása. A Windows NT executive processz objektumának létrehozása. A kezdeti szál létrehozása. A Win32 értesítése az új processzr l, azzal a céllal, hogy az felkészüljön az új processzre és szálra. A kezdeti szál végrehajtásának elindítása. 26

VII

VII. fejezet

Az újonan létrehozott processz és szál környezetben a címtér inicializálása (pl. a szükséges DLL-ek betöltése), majd a program végrehajtásának elkezdése. A fenti lépések mindegyikére vonatkozóan az alábbi megjegyzések érvényesek: Egyetlen CreateProcess híváshoz egynél több prioritási osztály specifikálható. A Windows NT a processzhez automatikusan a legalacsonyabb prioritási osztályt rendeli. Ha nincs prioritási osztály specifikálva az új folyamathoz, a prioritási osztály a Normal besorolást kapja. Minden ablakot egy desktophoz rendeli a rendszer. (Desktop-nak nevezi az NT a felhasználó által használható grafikus környezetet. Egy munkahelyen több desktop-ot is képes kezelni a rendszer.) Ha a CreateProcess-ben nincs megadva melyik desktop-ot használja a folyamat, akkor a folyamat automatikusan a hívó aktuális desktopjához rendel dik.

Szálak kezelése az NT-ben
A következ kben el ször a szálak struktúrájával foglalkozunk. A továbbiakban, hacsak másként nem említjük, az itt leírtak egyaránt érvényesek mind a normál felhasználói módú szálakra, mind pedig a kernel módú rendszerszálakra. Az operációs rendszer szintjén egy Windows NT szálat egy ún. executive szál blokk (ETHREAD) reprezentál. A blokkot a VII.9. ábra mutatja be. Az ETHREAD blokk és azok az adatstruktúrák, melyekre az ETHREAD blokkban tárolt pointerek mutatnak a rendszer címtartományában találhatók, a szál környezeti blokkjának kivételével, ami a folyamat címtartományában van. Az ETHREAD blokkon kívül, a Win32 alrendszer folyamata is kezel egy szál-leíró adatstruktúrát minden egyes szálhoz, ami egy Win32-es folyamatban jött létre.

27

VII

VII. fejezet

Kernel szál blokk (KTHREAD) Létrehozási és kilépési id k Processz azonosító EPROCESS Szál handle Elérési token Megszemélyesítési információ LPC üzenetek leírása Timer információ Függ ben lév I/O kérések

0.9. ábra: Az executive szál blokk feképítése

Az ábrán látható els mez a kernel szál blokk (KTHREAD). Ezt követi a szálazonosítási információ, a processzazonosítási információ, a saját processzhez tartozó pointerrel, biztonsági információ az elérési tokenre mutató pointer formájában, a megszemélyesítési információ, és végül az LPC üzenetekre, ill. a függ ben lev I/O-kérésekre vonatkozó mez k. A KTHREAD blokk tartalmazza mindazokat az adatokat, amelyekre a kernelnek van szüksége a szálütemezés és a szinkronizáció végrehajtása érdekében. Szál létrehozása (CreateThread): Egy szál életciklusa akor veszi kezdetét, amikor egy program új szálat hoz létre. Az ere irányuló kérés eljut a Windows NT executive-hoz, ahol a processzkezel (elnevezése: process dispatcher) helyet jelöl ki egy szálobjektum számára, majd a kernelt hívja, a kernel szál blokk kezdeti értékeinek beállítása végett. A következ kben végigvesszük azokat a lépéseket, 28

VII

VII. fejezet

amelyek a Win32 CreateThread függvénye szerint történnek a KERNEL32.DLL-ben, azzal a céllal, hogy egy Win32 szál jöjjön létre: A CreateThread egy felhasználói módú stack-et hoz létre a szál részére, a folyamat címterében. A CreateThread beállítja a kezdeti értékeket a a szál hardver kapcsolataihoz. Az NtCreateThread függvény hívására kerül sor, ami az executive szál objektumát hozza létre. Az ide tartozó lépések sorozata kernel módban hajtódik végre, a Windows NT executive-ján és kernelén belül. A CreateThread értesíti a Win32 alrendszert az új szálról, amire az alrendszer különböz beállításokat eszközöl az új szál részére. A szál összetett elérési címe (handle) és azonosítója (amik a 3. lépésben lettek generálva) visszaadódik a hívónak. A szál olyan állapotba került, amire már be lehet ütemezni a végrehajtását.

Szálak ütemezése
Ebben az alfejezetben az ütemezési elvekkel foglalkozunk. A Windows NT prioritáson alapuló, preemptív (kiszorító) ütemezési elvet valósít meg. Egy NT rendszerben mindig a legmagasabb prioritású futtatható szál fut, azzal a megkötéssel, hogy a futást azok a processzorok korlátozhatják, amelyeken a szál futása meg van engedve. Ezt a jelenséget processzor-affinitásnak nevezzük. Általában egy szál bármelyik rendelkezésre álló processzoron futhat, de a processzor-affinitás megváltoztatható a Win32 ütemezési függvényeinek felhasználásával. A kvantum Amikor egy szál futásra választódik ki, egy el re megszabott ideig fog futni. Ezt az id szeletet kvantumnak (quantum) nevezzük. Egy kvantum az az id tartam, amennyit egy szál futhat, miel tt a Windows NT megszakítja a szálat azért, hogy kiderítse, nem vár-e futásra egy másik szál ugyanakkora prioritással, vagy pedig nincs-e szükség a megszakított szál prioritásának csökkentésére. A kvantumok értéke szálanként változhat. Ugyanakkor azonban az is lehetséges, hogy egy szál nem jut el a kvantumja végéig. Ez a szituáció a preemptív ütemezés következtében léphet fel: Ha egy másik szál, nagyobb prioritással, futásra kész állapotba kerül, a futásban lev szál ki lesz szorítva a saját id szelete lejárta el tt. Ezen felül még az is el fordulhat, hogy egy szál futásra lesz kiválasztva, és még azel tt leállítódik, hogy elkezdené a kvantumját. A Windows NT ütemezési funkcióit a kernel valósítja meg. Nincs azonban külön ütemez modul a kernelen belül, az ütemez rutinok kódja a kernel különböz helyein vannak

29

VII

VII. fejezet

szétosztva. Az ütemezést megvalósító rutinok összességét közös néven a kernel diszpécserének (dispatcher) nevezik. Egy szál ütemezése az IRQL 2-es szintjén fordul el , és a következ események bármelyike elindíthatja: Egy szál futásra kész állapotba kerül. Például egy újonnan kreált szál, vagy egy olyan, ami éppen felszabadult a várakozásból. Egy szál futása leáll, mivel a kvantumja véget ért, ill. befejez dött a futás, vagy várakozási állapotba került a szál. Egy szál pioritása megváltozik, vagy egy rendszerkiszolgálási hívás miatt, vagy mert maga a Windows NT változtatja meg a prioritási értéket. Egy futásban lev szál processzor affinitása megváltozik. Az operációs rendszernek a fenti esetek mindegyikében el kell döntenie, melyik szál fog futásra követezni. A futó szál váltásakor a rendszer környezetváltást hajt végre: elmenti az éppen futó szál környezetét és betölti a futásra kijelölt szál környezetét. Az ütemezési döntések szigorúan a szálak alapján történnek, ami azt jelenti, hogy egyáltalán nem számít, hogy egy szál melyik processzhez tartozik. Ha például egy A processznek 10 futtatható szála van, egy B-nek pedig 2, és mindegyik szálnak ugyanaz a prioritása, akkor mindegyik szál a CPU-id 12-ed részét kapja. Vagyis a Windows NT nem fog 50 százalék CPU-id t adni az A processznek, és 50 százalékot a B-nek. A szálütemez algoritmusok szorosan köt dnek a prioritási szintekhez. A Windows NT 32 prioritási szintet használ, 0-tól 31-ig. Ezek felosztása a következ : Tizenhat valós idej szint (16 ­ 31). Tizenöt változó szint (1 ­ 15). Egy rendszer szint (0), ami le van foglalva minden NT rendszerben egyedül létez ún. zérus oldal (zero page) szálának. A szálakhoz rendelt kvantumok értékét a Windows NT a következ tényez k beszámításával határozza meg: Minden szálnak van egy kijelölt kvantumértéke, ami nem id tartam, hanem egy egész szám, amit nevezzünk kvantum egységnek. Határozatlan helyzetben a szálak a Windows NT Workstation-ön 6-tal indulnak, míg a Windows NT Serveren 36-tal. Az utóbbi érték azért nagyobb, hogy több id jusson a kliensek beérkez kéréseinek biztonságos kiszolgálására. Amikor az órajel ad megszakítást, akkor a szál kvantumából 3 levonódik. Ha az 0 vagy kevesebb lesz, lejár a kvantum, és új szál lesz futásra kiválasztva. Eszerint az NT Workstation-ön 2 óraintervallum, az NT Server-en pedig 6 óraintervallum jut egy szál futására ilyenkor. Az óraintervallumok hossza természetesen függ a hardver platformtól. Másrészr l a megszakítások gyakoriságát a HAL m ködése szabja meg, nem pedig a kernel. Például, az Intel rendszerek óraimpulzusa 10 msec (486-os), ill. 15 msec (Pentium Pro), míg a DEC Alpha AXP rendszereké 7,8 msec. 30

VII Egy szál állapotai

VII. fejezet

A Windows NT operációs rendszerben egy szál futása során több végrehajtási állapoton megy keresztül. Ezek a lehetséges állapotok a következ k: Készenlét: A szál végrehajtásra kész állapotban van. A diszpécser csak az ebben az állapotban lev szálak halmazát veszi figyelembe a végrehajtás ütemezésekor. Standby: Egy szál akkor van standby állapotban, ha a dispatcher kiválasztotta egy adott CPUn futásra az éppen futó szálat követ en. Egy processzorhoz csak egyetlen szál létezhet standby állapotban az operációs rendszeren belül. Futás: Miután a diszpécser környezet váltást hajt végre, a futási jogot megkapó szál futási állapotba kerül és megindul a végrehajtása. A végrehajtás addig folytatódik, amíg a kernel ki nem szorítja a szálat egy nagyobb prioritású szál futása érdekében, vagy lejár a szál kvantuma, a szál befejez dik, vagy pedig saját magától a várakozási állapotba lép. Várakozás: Egy szál több módon léphet be a várakozási állapotba: önkényesen várhat egy objektumra, hogy az szinkronizálja a végrehajtását, az operációs rendszer (az I/O rendszer például) várakozhat a szál érdekében, vagy egy környezeti alrendszer irányítja a szálat önmaga felfüggesztésére. Amikor a szál várakozása véget ér, akkor a prioritástól függ en a szál vagy azonnal elkezd futni, vagy visszakerülhet várakozási állapotba. Átmenet: Egy szál az átmeneti állapotba lép át, ha készen áll a végrehajtásra, de az kernel stack-je ki van mentve (page-elve) a memóriából. Miután a szál kernel stack-je visszakerül a memóriába, a szál készenléti állapotba megy át. Befejezett: Amikor egy szál végrehajtása véget ér, a szál a befejezett állapotba kerül. Ebben az állapotban a szál objektumának a törlése az objektumkezel t l függ. Ha az executive-nak van pointere az objektumhoz, az executive inicializálva ismét fel tudja használni a szál objektumát. Az állapotok közötti átmenet gráfját aVII.10. ábra mutatja be.

31

VII

VII. fejezet

Egy szál objektumának létrehozása és inicializálása

Befejezett

Újrainicializálás

Inicializált

Készenléti sorba helyezés

Készenlét

Szál egy objektum hadle-jére vár Végrehajtás befejezve

Várakozás vége

Várakozás Kernel stack visszahozva Várakozás befejezve Kernel stack kimentve Átmenet

Kiszorítva

Végrehajtásra kiválasztva

Futás

Id kvantum lejárt (kiszorítás)

Végrehajtás elindítása

Standby

0.10. ábra: Egy szál állapotai a Windows NT-ben

Multiprocesszoros környezetben a szálütemezés megoldása a CPU-k közötti munkamegosztás intenzív szervezését követeli meg. Mindent összevéve a Windows NT úgy jár el, hogy megkísérli a legmagasabb prioritású futtatható szálakat a szabadon lév CPU-khoz ütemezni. Mindazonáltal több tényez befolyásolja annak megválasztását, hogy egy szál melyik CPU-n fusson. A kiválasztási algoritmus ismertetése el tt néhány fogalmat vezetünk be: A processzor affinitás Minden egyes szál egy ún. affinitási maszkkal (affinity mask) rendelkezik, amely azokat a processzorokat adja meg, amelyeken a szál futása megengedett. A szál affinitási maszkja a

32

VII

VII. fejezet

processz affinitási maszkjából örökl dik. Alapesetben mindegyik processz, és ennek megfelel en mindegyik szál, egy olyan affinitási maszkkal kezd, amely megegyezik a rendszer aktív processzorainak a halmazával. Más szóval: mindegyik szál tud futni mindegyik processzoron. Ezt az állapotot két dolog képes megváltoztatni: Egy hívás az alkalmazás fel l, amely át tudja állítani a processzhez, ill. a szálhoz tartozó maszkokat: ez a SetProcessAffinityMask, ill. a SetThreadAffinityMask függvények hívása. Az image-fejlécben specifikált affinitási maszk, amely a teljes image-re érvényes. Az ideális és a következ processzor: Mindegyik szálnak van két CPU-sorszáma, amik a kernel szál blokkban vannak tárolva: Ideális processzor, vagyis a kitüntetett processzor, amin a szálnak futni kell. Következ processzor, vagyis az a processzor, amelyik a szál következ kiválasztva (vagy amin az utoljára futott). futására lett

Az ideális processzor kiválasztása véletlenszer en történik, amikor egy szál létrejön. Ehhez a processz blokkban egy számláló van fenntartva. Ez a számláló minden egyes szál létrehozásakor eggyel növekszik, ami által az új szálak ideális processzorai körben választódnak ki a rendelkezésre állókból. A Windows NT már nem változtatja meg az ideális processzort, miután a szál létrejött. A változtatásra csak az alkalmazásoknak van módjuk az olyan szálnál, ami a SetThreadIdealProcessor függvényt használja. A processzor kiválasztása Amikor egy szál futásra kész állapotba kerül, a Windows NT el ször egy tétlen processzorhoz próbálja a szálat ütemezni. Ha a tétlen processzorokból lehet választani, akkor el nyben részesül a szál ideális processzora, majd ezután jön a szál következ processzora. Ha ez sem áll rendelkezésre, akkor az utasításokat éppen végrehajtó processzor jön sorra. (Vagyis az, amelyiken az ütemezési kód fut.) Ha ezen CPU-k egyike sem tétlen, akkor az els rendelkezésre álló tétlen processzor lesz kiválasztva úgy, hogy a Windows NT végigellen rzi a tétlen processzorok maszkját, növekv CPU-sorszám szerint. Ha pillanatnyilag mindegyik CPU foglalt, és egy szál futásra kész állapotba került, a Windows NT azt vizsgálja meg, hogy van-e olyan futásban vagy várakozásban lev szál, amit ki lehetne szorítani valamelyik CPU-n. A kiválasztás elve ilyenkor a következ : Az els választás a szál ideális processzora, a második pedig a következ processzora. Ha egyik CPU sincs a szál affinitási maszkjában, akkor az els olyan aktív processzor lesz kiválasztva, amelyiken a szál futni tud.

33

VII

VII. fejezet

Ha ez a processzor olyan, amin egy másik szál van legközelebb futásra jelölve, (vagyis standby állapotban várakozik az ütemezésre), és annak a szálnak a prioritása kisebb, mint az indításra el készített szálé, akkor az új szál kiszorítja a másikat a standby állapotból, és maga lesz a CPU következ szála. Ha ennél a CPU-nál nincsen következ szál futásra

választva, akkor az NT megvizsgálja, hogy az éppen futó szál prioritása kisebb-e, mint az új szálé. Ha kisebb, a futásban lev szálat kiszorításra jelöli ki, és elhelyez a sorban egy

processzor-megszakítást arra, hogy a futó szál félrelök djék az új szál javára. Megjegyzés: A Windows NT nem vizsgálja az összes CPU-n a jelenlegi és a következ szálak prioritását, hanem csak azon az egy CPU-n teszi ezt, amit a fentiek szerint választott ki. Ha ezen a CPU-n nincsen kiszorítható szál, akkor az új szál bekerül a prioritási szintje szerinti készenléti sorba, ahol várakozni fog, amíg ütemezve nem lesz. Mint látható volt az el bbiekben, multiprocesszoros környezetben a Windows NT nem mindig a legnagyobb prioritású szálat választja ki egy CPU-n való futtatásra. Így egy olyan szál, ami egy adott CPU-n éppen futó szálnál nagyobb prioritású, készenlétbe kerülhet, de nem biztos, hogy azonnal kiszorítja a futó szálat.

Memóriakezelés
Az Windows NT memóriakezel jének feladata, hogy a folyamatok virtuális címterének címeit megfeleltesse fizikai címeknek, vagyis elvégezze a logikai-fizikai címtranszformációt. A másik fontos feladata, a virtuális memóriakezelés megvalósítása, vagyis a memória terheltsége esetén a régen nem használt memóriaterületek háttértárra menti, valamint ha hivatkozás történik egy háttértárra mentett memórialapra, a szálat várakoztatja, míg bemozgatja a kérdéses lapot a fizikai memóriába. Az NT 32 bites virtuális memória kezelést valósít meg. A memóriát laponként (page) kezeli, foglalás, felszabadítás, háttértárra mentés esetén memórialapokat mozgat. Az fent említett alapszolgáltatáson felül az NT memória kezel je olyan

többletszolgáltatásokat is ad a felhasználóknak, melyek nagyban megnövelik a rendszer hatékonyságát. Ilyen szolgáltatás pl. a fájlok memóriaként történ elérése (memory mapped files), amit lehet vé teszi a fájlok osztott elérését, vagy a copy-on-write mechanizmus használata, mely lehet ségeket a fejezetben részletesen is ismertetjük.

34

VII

VII. fejezet

Memória manager felhasználói interfésze
Az NT memóriakezel jének szolgáltatásait az alkalmazások a Win32 API interfész függvényeinek meghívásával érhetik el. Az NT memóriakezel je a következ szolgáltatásokat nyújtja a felhasználóknak: virtuális memória allokáció ill. felszabadítás osztott (shared) memória létrehozása fájlok osztott memóriához hasonló elérése virtuális memória kezelése (információ kérés, memóriába rögzítése, kiírása háttértárra stb.) memória védelmi funkciók kernel színt funkciók (els sorban a device driver-ek) támogatása (pl. fix fizikai memóriaterület használata)

Memória foglalás
A memória foglalás két lépésben történik a Windows NT-ben: reserve virtuális címtartomány lefoglalása commit virtuális memória lefoglalása A felhasználó természetesen kérheti a két lépést egy függvényhívásban történ végrehajtását. A reserve m velet még nem jelent tényleges memóriafoglalást. A reserve végrehajtásával a folyamat csak deklarálja az operációs rendszer számára, hogy mennyi memóriára lesz, vagy lehet szüksége. A rendszer csak a commit m velet hívásakor foglal tényleges tárterületet a korábban a reserve m velettel már lefoglalt memória részére. Ennek megfelel en csak a commit m velet után tudja a folyamat a memóriát használni, a csak reserved memóriacímre történ hivatkozás hibát okoz. A memória foglalás két lépcs ben történ megvalósításának célja a hatékonyabb m ködés biztosítása. A reserve hatására az operációs rendszer csak egy bels táblázatában jelzi, hogy a folyamat lefoglalta az adott címtartományt. A rendszer csak a commit hatására fog tényleges memórialapokat (page) ill ún. backing store-t, a memóriaterület potenciális mentésére szolgáló háttértárat lefoglalni. A kétlépéses memóriafoglalással lehet sége nyílik egy folyamatnak el re lefoglalni egybefügg címtartományokat, úgy, hogy csak a memória

tényleges használata esetén - vagyis a commit m velet végrehajtása után) - terheli az a rendszer memóriáját.

35

VII

VII. fejezet

Jól érzékelhetjük a memória foglalás két lépcs ben történ megvalósításának el nyeit például a szálak user stack-jének foglalásakor. A stack-nek természetesen egy folyamatos címtartománynak kell lennie. Alapértelmezés szerint, ha a szál indításakor másképpen nem kérjük, a rendszer 1 MB memóriát foglal reserve m velettel, de csak 2 lapnyi (x86-os rendszerekben kétszer 4KB) memóriát foglal commit m velettel. (Az els lap a stack teteje lesz, a második lap pedig arra szolgál, hogy a rendszer érzékelje, ha a stack megtelt, és automatikusan foglaljon commit m velettel új oldalakat.) Ha nem lenne két lépéses memóriafoglalás, minden szál indulásakor a rendszermemóriából ténylegesen le kellene foglalni 1 MB-nyi területet, melynek valószín leg jelent s részét a szálak többsége nem is használná. A két lépcs s memóriafoglalásnak köszönhet en azonban a stack csak akkor terheli a rendszer memóriáját, ha az ténylegesen is használatra kerül. Meg kell említeni, hogy a memória foglalás m veletek mindig lapokat (page) foglalnak, akkor is, ha a folyamat ennél kisebb memóriát kér. (Az x86-os rendszerekben a memórialapok mérete 4 KB.) Ráadásul a reserved (és így természetesen a commited) memórialapok mindig 64KB-os memóriaegységek határán kezd dnek, ezzel támogatva a memórialapok a kés bbiekben történ esetleges növelését.

Osztott elérés memória
Az osztott elérés memória használata a folyamatok közötti információcsere lehet ségén túl adott esetben jelent sen lecsökkentheti a rendszer memóriaterhelését. Vegyük pl. azt az esetet, hogy a rendszerben két folyamat is éppen C programot fordít. Az osztott memória használatával lehetséges, hogy a C fordító csak egy példányba kerüljön a memóriába, mely esetet a XX ábra szemléltet. A Windows NT az osztott elérés memóriát (shared memory) ill. a fájlok osztott elérését hasonló módon kezeli. A kezelés alapeleme az ún. section object (szekció objektum). (A section object név helyett a Win32 API file mapping object elnevezést használ.) A section object lényege, hogy létrehozásakor hozzátársíthatjuk egy fájlhoz vagy a fájl egy részéhez. Ha a section objecthez társított fájl a rendszer memóriáját a háttértáron reprezentáló ún. page file, a section object-tel osztott memóriát fogunk elérni. A section object-et létrehozása után akár több folyamat is megnyithatja, így biztosított a párhuzamos használata a section object által elért objektumnak, ami tehát lehet memória vagy egy létez fájl is.

36

VII

VII. fejezet

Az NT-ben a fájlok mérete, így a section object-en keresztül elért fájlok mérete is lényegesen nagyobb lehet, mint a folyamat memória címtartománya. Ebben az esetben a folyamat nem tudná az egész fájlt elérni. Ennek a problémának a megoldására biztosítja az NT-ben a fájlok egy részének, ún. nézetének (view) a map-pelési lehet ségét. A section object létrehozásakor a folyamat definiálhatja, a fájl melyik nézetét, melyik részét szeretné az adott section objecttel elérni. A fájlok section object-ten keresztül történ elérése az NT-ben egy nagyon gyakran

alkalmazott m velet. Az alkalmazások így hajtják végre azokat az I/O m veleteiket, amelyek kimenetét egy fájlba szeretnék irányítani, vagy pl. így történik a végrehajtható (ún. image) fájlok és a DLL-ek memóriába mappelése is. A cache manager section objectek segítségével éri el az általuk kezelt fájlokat.

Memória védelem
A memóriavédelem biztosítja, hogy sem két folyamat, sem egy folyamat és az operációs rendszer ne módosíthassa egymás címtartományába tartozó memóriaterületeket. (Az osztott elérés memória természetesen kivétel ezalól.) A kiterjedt memóriavédelem az egyik

legfontosabb funkciója az NT-nek, ami miatt megbízhatóan m köd , robosztus operációs rendszerként tartják az NT-t számon. A memóriavédelem négy szinten valósul meg: Az operációs rendszer kernel módban futó komponensei által használt adatstruktúrák a felhasználói módban futó folyamatok számára elérhetetlenek. Bármilyen ilyen elérési kísérlet hardver megszakítást eredményez, és a memória kezel egység jelzi a memória elérést kezdeményezó szálnak az elérési jog megsértését. Minden folyamat külön virtuális címtartományt használ, melyeknek ­ eltekintve az osztott elérés memóriától ­ nincs közös részük. A folyamatok a memóriát a memória kezel egységen keresztül érik el, ami amellet, hogy megfelel hardver támogatással elvégzi a logikai ­fizikai címtranszformációt, biztosítja, hogy egyik folyamat se érjen el egy másik folyamat által használt memórialapot. A fenti, a memóriakezel címtranszformációja által biztosított implicit memóriavédelmen túl az NT által támogatott processzorok lehet séget adnak hardver memóriavédelemre. A processzortípustól függ en az egyes memóriaterületek különböz védelmi attribútumuak lehetnek (pl. csak írhatóak, csak olvashatóak, írhatóak és olvashatóak stb.) Az egyes területek elérésekor a memóriakezel hardver ellen rzi az elérési jogosultságot. Pl. a kódszegmensek betöltéskor csak olvasható attribútumot kapnak, így megel zve a kód átítását. A negyedik védelmi szint a az osztott memória elérését biztósító section object-ekhez köt dik. A section object-ekhez definiálható egy ún. elérési lista (access control list, ACL),

37

VII

VII. fejezet

melyben megadható, hogy mely folyamatok jogosultak az adott section objectáet elérni. Ez a módszer teljesen illeszkedik az NT objektumok védelmi rendszerébe.

Copy-on-Write
A copy-on-write memóriahasználat ­ mely fordítása talán ,,írás esetén másolás" lehetne ­ egy széleskörben alkalmazott módszer a használt memória ill. a rendszer memória kezel m veleteinek optimalizálására. A copy-on-write jó példája az ún. lusta kiértékelés/végrehajtás (lazy evaluation) elvnek, ami azt mondja, hogy a rendszerben a költséges, vagyis sok er forrást igényl m veleteket el kell halasztani mindaddig, amíg azok végrehajtása már ténylegesen kikerülhetetlen nem lesz. A copy-on-write memóriahasználat m ködése a következ : Ha egy folyamat egy írhatóolvasható, más folyamatok által is potenciálisan használt section object-et kezd használni, akkor a rendszer nem készít a folyamat számára egy lokális másolatot az egész elért memóriatartalomról annak érdekében, hogy a memória megváltoztatása csak a kérdéses folyamat számára legyen látható. Ehelyett az NT csak bebillenti a memóriatlapokhoz tartózó copy-on-write (C-o-W) jelz bitet (flag-et) (VII.11. ábra).

38

VII

VII. fejezet

1 lap (eredeti adat) 2 lap (eredeti adat) 3 lap (eredeti adat)

1 lap (C-o-W) 2 lap (C-o-W) 3 lap (C-o-W)

1 lap (eredeti adat) 2 lap (eredeti adat) 3 lap (eredeti adat)

I. process címtartománya

Fizikai memória

II. process címtartománya

0.11. ábra: Copy-on-write memórialapok írást megel z en Tényleges másolás a rendszerben csak akkor történik, amikor a section obeject bármelyik használója kezdeményez egy memória írási m veletet. Ekkor a rendszer miel tt

megváltoztatná a memóriatartalmat, a kérdéses memórialapról egy privát mósolatot készít az írást kezdeményez folyamat számára (VII.12. ábra). Így biztosítja a rendszer ,,takarékosan", hogy a változtatás csak az írást kezdeményez folyamat számára legyen látható.

39

VII

VII. fejezet

1 lap (eredeti adat) 2 lap (eredeti adat) 3 lap (eredeti adat)

1 lap (C-O-W) 2 lap (C-O-W) 3 lap (C-O-W)

1 lap (eredeti adat) 2 lap (módosított) 3 lap (eredeti adat)

2 lap (másolat)

I. processz címtartománya

Fizikai memória

II. processz címtartománya

0.12. ábra: Copy-on-write memórialapok írást követ en

Memória foglalása
Az NT lapkezelést valósít meg, vagyis a memória allokálása memórialaponként (memory page) történik. A memóriakezel kevés szabad fizikai memória esetén háttértárra mentheti az egyes lapokat. Ezt a m veletet nevezzük lapozásnak pageing-nek. A folyamatok a memória lapokat foglalhatják a rendszer ún. lapozott memória tárából (paged memory pool) és a nem lapozott memória tárából (nonpaged memory pool). A két memória tár közötti különbség a lapozásnál van. A nem lapozott memória tárából történt memória foglalás esetén a kért memórialapot a rendszer állandóan a fizikai memóriában tartja, sosem menti háttértárra. Ezzel lehet biztosítani, hogy valamilyen szempontból fontos (pl. driverek által használt) memóriaterületek akkor is a fizikai memóriában maradjanak, ha ritkán használják ket.

40

VII

VII. fejezet

A memória mérete
A Windows NT 32-bites memória címzést valósít meg, ami minden processz számára 4 GB virtuális címtartományt jelent. Alapesetben a 4 GB fels 2 GB-os részét használhatják az alkalmazások (00000000-7FFFFFFF címek), míg az alsó 2 GB (80000000-FFFFFFFF) az operációs rendszert tartalmazza. A Windows NT Server Enterprize Edition lehet ség ad egy bootoláskor megadható paraméter használatával a user címtartomány 3 GB-ra történ növelésére. A user ill. a rendszer címtartomány felosztását, valamint a címtartományban a különböz memóriaterületek elosztását az VII.13. ábra mutatja. 00000000 alkamazás kódja globális változók szálak stack területe DLL 7FFFFFFF 80000000 kernel , executive HAL C0000000 processz lap tábla C0800000 rendszer cache paged pool nonpaged pool FFFFFFFF rendszer címtartomány

alkalmazás címtartomány

0.13. ábra: A logikai címtér felépítése

41

VII

VII. fejezet

Az NT memóriakezel jének m ködése ­ pl. rendszer általa használt adatmez k méretének változtatásával, vagy a folyamatoknak biztosított memóriaterületek nagyságának

módosításával ­ alkalmazkodik az adott számítógében lév fizikai memória méretéhez. Az NT három memória méretkategóriát különböztat meg: kicsi (small), közepes (medium), nagy (large). A különböz kategóriákhoz trtozó memórianagyságot a VII.14. ábrán láthatjuk. (A memóriák árának csökkenése, így az általánosan használt memóriaméret növekedése ezeket a határokat viszonylag gyorsan megváltoztatja.)

méret kategória kicsi közepes nagy 19 MB 20-32 MB 32 MB (NT Workstation) 64 MB (NT Workstation) x86 31 MB nem használt 32 MB (NT Workstation) 64 MB (NT Workstation) Alpha

0.14. ábra: A fizikai memória mérete különböz memóriamodellek esetén

Címtranszformáció
A Windows NT kétszint indexelést használ a virtuális-fizikai címtranszformációhoz, amit mind az x86-os, mind az Alpha processzorok támogatnak. A virtuális cím felépítése processzor függ . A VII.15. ábra mutatja, hogy x86-os processzor esetén hogyan áll össze a lap könyvtár indexb l (page directory index - PDI), laptábla indexb l (page table index - PTI), ill. a byte indexb l (byte index - BI) a virtuális cím.

42

VII

VII. fejezet

31 laptábla könyvtár index (PDI) x86: 10 bit Alpha: 8 bit laptábla index (PTI) x86: 10 bit Alpha: 11 bit virtuális memórialap szám x86: 12 bit Alpha: 13 bit eltolás byte index (BI)

0 (LSB)

0.15. ábra: A virtuális cím felépítése A PDI ill. a PTI kijelöli az elérend memórialapot, míg a BI a lapon belüli eltolást adja meg. A címtranszformáció menetét a VII.16. ábra mutatja be.

43

VII

VII. fejezet

KPROCESS

PDI

PTI

BI

page byte PD entry PT entry

Lap tábla könyvtár

Lap tábla

Fizikai memória

0.16. ábra: A címtranszformáció menete x86-os processzorok esetén Minden folyamathoz tartozik egy lap könyvtár (page directory) maximum 1024 bejegyzéssel. Ennek kezd címe a folyamat leíróban (KPROCESS) van. A PDI kijelöli, hogy a táblázat melyik bejegyzésében találjuk a címtranszformációhoz használandó laptábla kezd címét. A laptábla egy maximum 1024 bejegyzést tartalmazó táblázat, melyb l maximum 512 darab lehet egy folyamaton belül, ami egyben az egy rendszerben használható laptáblák maximáli száma is. Ebben a laptáblában a PTI kijelöli, hogy melyik bejegyzés tartalmazza a használandó memórialap kezd címét. A memórialapon belül pedig a BI pontosan kijelöli a keresett byte eltolását.

44

VII

VII. fejezet

A WINDOWS NT fájlrendszere (NTFS)
Ebben a fejezetben a Windows NT fájlrendszerének bels felépítését és m ködését mutatjuk be. A Windows NT által használt fájlrendszer elterjedt rövid elnevezése: NTFS (Windows NT File System).

Elvárások az NTFS-sel szemben
Tervezéskor az NTFS elé állított legfontosabb követelmények a következ k voltak: Megbízható fájlrendszer, vagyis adatállományok sikertelen m veletek utáni visszaállíthatóságának, helyrehozhatóságának garantálása (recoverability). Állományok biztonságának, vagyis illetéktelen elérésekt l történ védelmének garantálása (security). Hibat rés, redundáns tárolás lehet sége, vagyis az egyes fájlok elérhet ségének biztosítása (fault tolerance). Nagy diszkek és nagy fájlok tárolásának lehet sége. A megbízható fájlrendszer megvalósítását két alapvet eszközzel éri el a Windows NT: Tranzakciónkénti feldolgozás (transaction processing) Redundáns tárolása a fontos adatoknak A redundáns tárolás azt jelenti, hogy a rendszer duplikálja a m ködés szempontjából fontos adatállományokat a lemezen. Igyekszik a lemez egymástól távoli régióiban tárolni a másolatokat, hogy csökkentse mindkét másolat egy id ben történ sérülésének

valószín ségét. A tranzakciónkénti feldolgozás a lemezm veletek biztonságos végrehajtásának elve, melyet a következ alfejezetben mutatunk be. A fájlrendszer biztonságának garantálása érdekében a rendszer minden állományhozzáféréskor ellen rzi az elérési jogosultságot. A fájlelérés ellen rzése illeszkedik az NT általános objektumelérést ellen rz szólunk. A nagy diszkek kezelését, ill. nagy fájlok tárolását az NT 64 bites cluster-leíró használatával támogatja. Egy fájlrendszerben összesen 248 fájl lehet egyid ben. Egy fájl mérete maximum 264 byte lehet. A fájlrendszer további korlátainak ismertetésére a tárolás részleteinek leírásakor még visszatérünk. biztonsági rendszerébe, amir l a kés bbiekben még

45

VII Tranzakciónkénti feldolgozás

VII. fejezet

A tranzakciónkénti feldolgozás (m veletenkénti feldolgozás) a fájlhozzáférések megbízható végrehajtását teszi lehet vé. A tranzakciónkénti feldolgozás a ,,Mindent vagy semmit" elvre épül. Ez esetünkben azt jelenti, hogy egy lemezm velet vagy teljesen végrehajtódik, vagy ha valamilyen oknál fogva megszakadna, a rendszer visszaállítja a fájlrendszer eredeti állapotát. Így mindig konzisztens fájlrendszer lesz a lemezen. A rendszer az egyes fájlrendszeren végzett m veleteket lépésekre bontja, és kiegészíti azokat a megbízhatóságot növel redundáns adminisztrációs lépésekkel. Ezek után meghatározza a lépések olyan sorozatát, mely lehet vé teszi azt, hogy a lemezen minden pillanatban csak konzisztens adatok legyenek, ill. a lemezen lév adatok alapján visszaállítható legyen egy-egy m velet megkezdése el tti állapot. Egy fájlírási m velet során végrehajtott lépéseket a VII.17. ábra mutatja be: ,,WRITE" kérés Log File Sercive (LFS) 4 5 2 3 1

NTFS driver

Cache Manager (CM) 6, 7

0.17. ábra: Egy lemez írási m velet kiszolgálása

A fájlírási m velet kiszolgálásának lépései: Az NTFS driver üzenetet küld az LFS-nek, hogy írás tranzakció következik, adminisztrálja azt (készítsen a tranzakcióról ún. log rekordot). Az LFS írja a cache-ben lév log fájlt.

46

VII

VII. fejezet

Az NTFS végrehajtja a kért utasítást, írja a (cache-ben lév ) fájlt. A CM üzen, hogy az írás befejez dött, minden adat megvan. Az LFS megadja, hogy milyen adatokat kell a cache-b l üríteni. (A megváltoztatott fájlt és a log fájlt.) A CM kiírja a lemezre a log fájlt. A CM kiírja a lemezre az adatokat, vagyis a megváltoztatott fájlt. A lemezen történt m veletek adminisztrálása úgy történik, hogy a rendszer a m veletek leírását, ill. a visszaállításukhoz szükséges adatokat egy ún. log fájlba írja. Ennek a Log File Service modul által használt fájlnak a szerkezetét a VII.18 ábra mutatja be.

1 2 A fájlrendszer újraindításkor szükséges információ két példányban

3

4 5 6 ... n-3 n-2 n-1 n. Tranzakciók során körkörösen íródó tömb, ami minden tranzakcióról

tartalmaz egy log rekordot. A rekordban eltárolja a rendszer a tranzakció újbóli elvégzéséhez ill. a hatástalanításához (visszavonásához) szükséges információkat.

0.18. ábra: A lemezm veletek adminisztrálására használt log fájl szerkezete Réteg szerkezet device driver struktúra A réteg szerkezet device driver struktúra lehet vé teszi a különböz funkcionalitású driverek rugalmas használatát, ill. a driver-ekb l az igényeknek megfelel rendszer építését. A módszer lényege, hogy a driver-eknek különböz szintjeit különbözteti meg. A szintek

funkcionalitása, ill. az adott funkcionalitáshoz tartozó interfész jól definiált. Emiatt a drivereket egyszer egymáshoz illeszteni. A réteg szerkezet device driver struktúra lényegét legegyszer bben egy példán keresztül érthetjük meg. Az ábrán egy lemez írási m velet végrehajtása látható. Az API hívást az Executive réteg továbbítja az I/O Manager felé, amely eléri a Disc Driver-eket. A File Manager Driver el állítja a fájl-handle és az adatbuffer alapján az írandó lemezen a megcímzend cluster címét, ill. az írandó adatot. Egyszer esetben a File System Driver (az I/O Manager-en keresztül) eléri a Disk Drivert, ami végrehajtja a lemez írását.

47

VII

VII. fejezet

A réteg szerkezet driver-struktúrának köszönhet en lehet ség van azonban további driver réteget a két szint közé illeszteni. Ebben az esetben a beillesztett driver réteg a File System Driver felé úgy viselkedik, mit egy egyszer Disc Driver, de belül bonyolultabb

többletszolgáltatásokat nyújtó funkciókat valósíthat meg. Megvalósíthat például hibat r (redundáns) tárolást (pl. lemez tükrözést) vagy megvalósíthat több lemezen tárolt (multivolume file system) fájlrendszert, ami lehet vé teszi különösen nagy fájlok tárolását.

48

VII

VII. fejezet

Alrendszer vagy alrendszer DLL
USER mód NtWriteFile(FileHandle, charBuffer) KERNEL mód

EXECUTIVE API (System Services)
IRÁS(adat, fájl relatív eltolás)

File System Driver

IRÁS(adat, diszk relatív eltolás)

IRÁS(adat, diszk relatív eltolás)

I/O Manager

Fault Tolerant vagy Multivolume Driver

IRÁS(adat, diszk szám + eltolás)

Opcionális driver réteg
IRÁS(adat, diszk szám + eltolás)

Disc Driver
IRÁS(adat, diszk relatív eltolás) IRÁS(adat, diszk relatív eltolás)

0.19. ábra: Réteg szerkezet device driver struktúra

Az NT által támogatott hibat r adattárolási technikák: RAID level 1: diszkek tükrözése RAID level 5: diszkszeletek prioritásos védelme

49

VII

VII. fejezet

A RAID a Redundant Array of Inexpensive Disks (olcsó lemezegységek redundáns tára) rövidítése. Ezek a hibat r szabványban definiáltak. tárolást kommersz elemekkel lehet vé tev módszerek

Az NTFS további el nyös tulajdonságai
A fenti tulajdonságokon kívül az NTFS további el nyös tulajdonságokkal rendelkezik. Ezek a következ k: stream-ek használata Egy adott néven elérhet adatállománynak több függetlenül elérhet alszekciója (streamje) lehet. Ezeket külön-külön írhatjuk és olvashatjuk. UNICIODE használható a fájlnevek megadásakor A UNICODE használatán túl lehet ség van maximum 255 karakter hosszú fájl nevek választására, ami szóközöket illetve pontokat is tartalmazhat. indexelés lehet sége Egy fájlrendszerben készíthetünk egy ún. index buffert, ami egy adott tulajdonság alapján tartalmaz közvetlen hivatkozásokat fájlokra. Dinamikus hibás (bad) szektor-kezelés A rendszer futás közben észleli, ha egy cluster meghibásodik, és utána többet nem használja. Hibat r fájlrendszer esetén akár el is fedheti a rendszer az adott lemezhibát. Posix szabvány támogatása hard link kisbet t és nagybet t megkülönböztethet (case sensitive) fájlnevek id bélyegek (time stamp-ek) használata

Az NTFS által használt adattípusok, adatszerkezetek
Volume (kötet): A lemez egy logikai partícióját nevezzük volume-nak. Minden volume-hoz egy logikai fájlrendszerhez tartozik, ami formázáskor alakul ki. Egy lemezen így lehet akár több, akár eltér típusú (pl. FAT és NTFS) volume is. Egy volume lehet hibat r Cluster: Az adattárolás alapegysége. Néhány egymás után következ szektor, melyeket a rendszer együtt kezel. Az NT csak clustereket tart nyilván. Logical Cluster Number (LCN): Egy adatszerkezethez, pl. egy fájlhoz tartozó cluster-ek sorszáma. Egy fájlhoz tartozó clustereket pl. 0-tól n-ig folyamatosan számozzuk.

50

VII Virtual Cluster Number (VCN):

VII. fejezet

A lemezen elhelyezked cluster-ek azonosítására szolgáló sorszám. A rendszer egy lemezt a cluster-ek sorozatának lát. A lemezmeghajtó feladata, hogy a VCN alapján megtaláljon és elérjen egy adott a VCN-hez tartozó cluster-t. A lemezen tárolt adatszerkezetek eléréséhez pontosan az LCN-ek VCN-ekhez történ hozzárendelését kell megadni, vagyis azt, hogy a fájl egy adott LCN-el jelölt clustere, melyik disk cluster-ben tárolódik, vagyis melyik VCN-el érhet szemléltetjük. el. Mindezt a VII.20. ábrán

LCN: VCN:

0 6324

1 857243

2 9454

... ...

n. 542

0.20. ábra: LCN és VCN egymáshoz rendelése NTFS metadata: Azoknak az adatoknak a gy jt neve, a mely egy fájlrendszer kezeléséhez ill. a benne tárolt fájlok eléréshez szükséges. Az NTFS tartja magát ahhoz az elvhez, hogy minden, ami a lemezen van, az fájl. Így pl. a volume-leíró, a boot információ, a hibás szektorok leírása, stb. mind-mind egy-egy fájlként van eltárolva. Az NTFS metadata információkat tároló fájlokat aVII.21. ábra mutatja be.

51

VII

VII. fejezet

$Boot fájl $Bad sector $Bitmap $Logfile $MFT $MFT mirror $Volume $Attribute

A rendszer indulásakor használt információ A hibás clusterek sorszáma (LCN) A clusterek foglaltsági térképe A Log File Service által a lemeztranzakciók adminisztrálására használt fájl Master File Table A Master File Table (részleges) biztonsági másolata A kötet leírását (típusát, fájlrendszer, stb.) tartalmazó fájl A kötet tulajdonságait, attribútumait tartalmazó fájl

0.21. ábra: NTFS metadata információk MFT (Master File Table): A Master File Table a fájlrendszerben tárolt fájlok leírását, elérésükhöz szükséges információt tartalmazza. Az NT szemlélete a következ : Egy fájl nem más, mint egymással összerendelt adatok halmaza. A fájl neve, keletkezési id pontja, elérhet sége, stb. mind-mind egy-egy adatokkal jellemzett ,,attribútuma" az adott fájlnak. Maguk a fájlban tárolt adatok is a fájl tartalom nev attribútumának leírása. A fájlok az ún. file record-okban tárolódnak, amelyben a fájl attribútumok (file attribute) azonosítója (neve) és az attribútumhoz tartozó adatmez k van egymás után felsorolva. A Master File Table nem más, mint file record-ok sorozata. A tárolás megkönnyítése érdekében a Mastar File Table nem az egész file record-ot, hanem csak annak els 1K-s darabját tartalmazza. A kés bbiekben majd meglátjuk, milyen technikával tárolja az NT az 1K-nál nagyobb file rekordokat, ill. a record-okban lev attribútumokat. Ha végiggondoljuk az NT tárolási technikáját, akkor látjuk, hogy a Master File Table nem más, mint egy 1K-s bejegyzéseket tartalmazó táblázat. A táblázat minden bejegyzése egy-egy fájlt azonosít. A fájl egyedi azonosítója ezek után az a sorszám lesz, ami megmondja, hogy az MFT hányadik bejegyzése tartozik hozzá. A bejegyzések minden fájlra vonatkozó információt tartalmaznak, azonban szerkezetük nem kötött. A rekordok szerkezetének leírását, vagyis az egyes attribútumok tárolásának módját kés bbi fejezetben ismertetjük.

52

VII A Master File Table els

VII. fejezet 16 bejegyzése mindig azonos fájlokhoz tartozik. Ezek az ún.

rendszer fájlok a fájlrendszer számára fontos adatokat tartalmazzák. Nevük mindig $ jellel kezd dik. A Master File Table szerkezetét a VII.22. ábra tünteti fel:

$ MFT $ MFT mirror $ Logfile $ Volume $ Attrib ... $... USER FILE1 USER FILE2 ... USER FILEn

0. 1. 2. 3. 4. ... 15. 16. 17. ... n.

0.22. ábra: A Master File Table szerkezete Az ábrán látható, hogy az els 16 bejegyzést az operációs rendszer használja, utána pedig a felhasználói fájlok következnek. Fontos megjegyezni, hogy a könyvtárak leírása is egyszer felhasználói fájlokban tárolódik. Ebben az adott könyvtárban lev fájlok neveinek és a fájlokhoz tartozó MFT bejegyzés sorszámának összerendelése található. Ennek megfelel en az egyik felhasználói fájl pl. a f könyvtár leírását fogja tartalmazni. Ennek helyét azonban a fix helyen elérhet rendszer fájlok tartalmazzák.

Fájlok elérése NTFS alatt
Egy lemez tranzakciót az NT következ módon hajt végre. A lépések többségét csak a kötet (volume) rendszerindulás (boot) utáni els elérésekor kell végrehajtani. A $Boot fájl elérése, amely rögzített helyen van. $MFT elérése. A $Boot tartalmazza az MFT kezdetének helyét. Az $MFT mindig az els MFT rekordhoz tartozik, $MFTMirr a másodikhoz. $LogFile a harmadikhoz, stb.) $MFT ($MFTMirr) elérése, memóriába tárolása $LogFile és más meta-fájlok beolvasása A kötet (volume) rendszerindulás (boot) utáni els elérésekor végrehajtja az ún. recovery m veletet. A recovery nem más, mind a fájlrendszer konzisztens állapotának ellen rzése, 53

VII

VII. fejezet

szükség esetén annak helyreállítása. A log fájl alapján ellen rzi a rendszer, hogy kell-e tranzakciót ,,visszagörgetni" vagy újra végrehajtani. Recovery után a lemez konzisztens állapotba kerül. A root ,,\" könyvtárhoz tartozó MFT bejegyzés megkeresése, ill. a memóriában tárolása a kés bbi elérések gyorsítása érdekében. A tényleges fájl tranzakció végrehajtása. Természetesen a log fájl írása minden tranzakciónál folyamatosan történik.

File Record
Mint már említettük, a file record tartalmazza a fájlhoz tartozó összes információt. Az adatok attribútumok formájában tárolódnak. Egy tipikus attribútum halmazt mutat be aVII.23. ábra:

54

VII

VII. fejezet

attribútum header információ

standart info Fájl név Read only Dos név Hardlink szám NT-s név Timestamp ... ...

Security info Data Ki és hogyan érheti A fájl által reprezentált el a fájlt. adattömeg.

0.23. ábra: Egy tipikus file record Az attribútumok értéke tárolódhat rezidens és nem rezidens módon attól függ en, hogy fizikailag hol helyezkedik el az attribútumot jellemz adathalmaz. Ha közvetlenül az

attribútum header után tárolódik, akkor rezidens tárolásról beszélünk. Nem rezidens tárolás esetén az attribútum után csak egy hivatkozást találunk, hogy a lemez mely clustere tartalmazza az attribútum adatait. Rezidens tárolás Az attribútum értékét reprezentáló bináris információ közvetlenül az attribútum header után van tárolva a rekordban. Erre vonatkozóan nézzünk egy példát a VII.24. ábrán: Általános felépítés: attribútum (adat) fájl név header

fájl név (adat)

security header

security (adat)

Egy konkrét példa: (az adatelemek fölött az lefoglalt byte-ok száma látható) 0..............7 8...............21 22..........29 30 ... ,,RESIDENT" ,,RESIDENT" 8h (offset) ,,MYFILE.DAT" 8h (offset) 14h (Length) 25h (length) 0.24. ábra: Attribútumok rezidens tárolása

55

VII Nem rezidens tárolás

VII. fejezet

A header után csak az attribútum értékét reprezentáló adatok helye van rögzítve. Pl. az adatokat tartalmazó buffer címeit tárolja a rendszer a rekordban. Pl. egy könyvtár nem rezidens tárolása a VII.25. ábra szerint néz ki (kétszint indextáblával). A nem rezidens tárolás esetén a header jelzi a nem rezidens tárolás tényét. A fájl rekordban ezután egy indextábla kerül, ami megmutatja, mely bufferek-ben tárolódik az adott attribútum értéke. Ezután egy VCN ­ LCN megfeleltetési táblázat következik, amelynek segítségével az attribútumok értékét tároló bufferek közvetlenül elérhet k. Az attribútum leírás végén egy táblázat következik, mely megmutatja, mely clusterek kihasználtak és mely clusterek nem használtak a bufferekben. Az adatok fent leírt módon történ használó egyszint indexelésnek. tárolását nevezzük dinamikusan növekv indextáblát indexelés, dinamikus méret

56

VII

VII. fejezet

Általános felépítés: File index VCN - LCN megfeleltetése az index buffereknek

Gyökér index tábla: Header mutatók az index bufferekre

Bitmap: Tárolja, mely indexek használtak az index bufferekben.

Kokrét példa: ,,NONRESIDENT" 8h (offset) 14h (length)

F1

F9

F22

VCN - LCN MAP

BITMAP

F22 Index tábla (4 cluster) F1 F1 F3 F3 F7 F7 F9 F10 F11 F18

Index tábla (4 cluster)

Index tábla (4 cluster)

0.25. ábra: Attribútumok nem rezidens tárolása

Biztonsági alrendszer
A Windows NT olyan átfogó és konfigurálható biztonsági szolgáltatásokat nyújt, amelyek együttesen kielégítik az USA Védelmi Minisztériuma által a megbízható operációs rendszerekre el írt C2-es szint biztonsági követelményeket. A Windows NT Server és a Windows NT Workstation 3.51 1996. októberben, a Windows NT 4.0 1999. márciusban kapta meg a C2-es biztonsági jóváhagyást. A biztonsági szolgáltatások és a szükséges alapvet tulajdonságaik a következ k: A biztonságos logon (bejelentkezés) lehet sége megköveteli, hogy a felhasználó egyedi logon azonosítóval és jelszóval azonosítsa magát bejelentkezéskor. A tetsz legesen konfigurálható (discretionary) elérési ellen rzés lehet vé teszi, hogy egy er forrás tulajdonosa meghatározza, hogy ki érheti el az er forrást, és mit tehet vele. Így

57

VII

VII. fejezet

olyan jogosultságok adhatók, amelyek egy felhasználónak vagy egy felhasználói csoportnak engedélyeznek különböz fajta hozzáférést. A biztonsági auditálás azt a képességet jelenti, amivel a biztonságot érint események felismerése és feljegyzése történik, beleértve a rendszer-er források létrehozására, elérésére vagy törlésére irányuló lépéseket. Mindez megkönnyíti az illetéktelen akciót végrehajtó személy kinyomozását. A memóriavédelem megakadályozza, hogy egy jogosulatlan processz egy másik folyamat privát virtuális memóriáját elérhesse. Ezen túlmen en a Windows NT garantálja, hogy amikor egy memóriaoldal hozzárendel dik egy felhasználói folyamathoz, ebbe az oldalba soha nem kerülhetnek bele adatok másik folyamattól. A fenti követelmények teljesítése a Windows NT biztonsági alrendszerén és az ahhoz kapcsolódó komponenseken keresztül valósul meg.

A biztonsági alrendszer komponensei
A Windows NT biztonságát megvalósító legfontosabb komponensek a következ k: Biztonsági referencia monitor (Security Reference Monitor -SRM): Ez a komponens az executive-ban van (NTOSKRNL.EXE). Funkciói: az objektumok biztonsági elérésének ellen rzése, privilégiumok (felhasználói jogok) kezelése, biztonsági auditálási üzenek el állítása. Helyi biztonsági jogosultság ellen rz (Local Security Authority -LSA) szolgáltatása: Ez egy felhasználói módú folyamat, az LSASS.EXE image-et futtatja, ami a felhasználók bejelentkezési jogait és jelszavát ellen rzi, a felhasználóknak és csoportoknak adott privilégiumokat, továbbá a biztonsággal kapcsolatos auditálás üzeneteit küldi az események naplójába. LSA adatbázis: Ez az adatbázis tartalmazza a rendszer biztonságos m ködésére vonatkozó beállításokat. Biztonsági témaszám kezel (Security Accounts Manager -SAM) szerver: Ez egy szubrutinok halmazából álló szolgáltató. A szubrutinok a felhasználói neveket és a csoportokat tartalmazó adatbázist kezelik. Ezek a nevek és csoportok vagy a helyi gépre vannak definiálva, vagy - ha a gép egyben tartomány (domain) vezérl - az adott domain-re. Utóbbi esetben a rendszer tartományvezérl . A SAM az LSASS folyamat környezetében fut. SAM adatbázis: Adatbázis, ami tartalmazza a definiált felhasználókat és csoportjaikat, jelszavukkal és egyéb attribútumaikkal együtt. Logon processz: Felhasználói módú folyamat, amely a WINLOGON.EXE­t futtatja. A folyamat a felhasználói nevet és jelszót veszi át, majd elküldi ket az LSA-hoz ellen rzés céljából, ezután pedig a kezdeti folyamatot hozza létre. Hálózati logon szolgáltatás: Felhasználói módú szolgáltatás a SERVICES.EXE processzen belül, amely a hálózati logon kérésekre válaszol. A jogosultságot úgy kezeli, mint a helyi logonokat, azáltal, hogy ellen rzés végett ezeket is az LSA processzhez küldi el. Az SRM, ami kernel módban fut, és az LSA, ami felhasználói módban fut, egymás között a helyi eljáráshívás (LPC) révén kommunikálnak.

58

VII

VII. fejezet

Az objektumok védelme
Az objektumvédelem a konfigurálható elérési ellen rzés és az auditálás alapját képezi. A Windows NT-ben védhet objektumok a következ k lehetnek: fájlok, hardver eszközök,

postázási helyek, elnevezett és névtelen cs vezetékek, folyamatok, szálak, események, szemaforok, id mér k, elérési tokenek, ablak-állomások, desktopok, hálózati megosztások, szolgáltatások, ill. nyomtatók. Mivel a rendszer felhasználói szálba exportált er forrásai objektumként vannak megvalósítva, a Windows NT objektumkezel je kulcsszerepet kap a biztonsági elérések szervezése során. Annak érdekében, hogy ellen rizni lehessen, ki manipulálhat egy objektumot, a biztonsági rendszernek mindegyik felhasználó kilétér l tudnia kell. Ez az oka annak, hogy a Windows NT megköveteli a hitelesített logont, miel tt a felhasználó bármelyik rendszer-er forráshoz hozzáférne. Amikor egy szál megnyit egy objektumhoz tartozó handle-t, az objektumkezel és a biztonsági rendszer a hívó biztonsági azonosítóját használja fel annak eldöntésére, hogy a hívó megkaphatja-e a kért handle-t. A védelemben részesítend objektumok ún. biztonsági adatokkal (security descriptors) hozzáférési joga van az

rendelkeznek. Ezek szabják meg, hogy kinek milyen jelleg objektumhoz. A f bb biztonsági adatok a következ k:

A tulajdonos biztonsági azonosítója (security ID, SID). A felhasználó csoport biztonsági azonosítója (grup security ID; ezt csak a POSIX használja). Konfigurálható elérési lista: Azt specifikálja, hogy kinek milyen fajta elérése van az objektumhoz. Rendszerelérési lista: Azt specifikálja, hogy mely felhasználók mely m veleteit kell felsorolni a biztonsági auditálási naplóba. Elérési tokenek és megszemélyesítés: Egy elérési token (access token) az az adatstruktúra, amely egy folyamat vagy egy szál biztonsági adatait tartalmazza: a biztonsági azonosítót, azon csoportok listáját, amelyeknek a felhasználó a tagja, valamint a megengedett és letiltott privilégiumok listáját. Mivel az elérési tokenek felhasználói módba vannak exportálva, számos Win32 függvény hoz létre elérési tokeneket, ill. változtat rajtuk. Mindegyik folyamatnak van egy els dleges elérési tokenje, amelyet az t el állító folyamattól örököl. Logonnál az LSA folyamat gy z dik meg arról, hogy a felhasználói név és a jelszó 59

VII

VII. fejezet

összhangban van-e az SAM adatbázisában lev információval. Ha igen, akkor az LSA logon folyamatnak visszaad egy elérési tokent a WinLogon, amely ekkor ezt a tokent hozzárendeli a kezdeti folyamathoz a felhasználói területen. A felhasználói területen létrejöv folyamatok ezt az elérési tokent öröklik. Az egyes szálaknak szintén lehet saját elérési tokenjük. Ez akkor van így, ha azok egy klienset személyesítenek meg. Ez a képesség lehet vé teszi a szálaknál, hogy olyan elérési tokenjük legyen, ami különbözik a folyamat elérési tokenjét l. Például, a szerver folyamatok tipikusan kliens folyamatokat személyesítenek meg úgy, hogy egy szerver folyamat egy kliensnek a nevében hajt végre m veleteket, a kliens biztonsági adatait használva a saját adatai helyett. további

A biztonsági auditálás
Az objektumkezel auditálási eseményeket tud generálni egy-egy elérési ellen rzés

eredményeként. A Win32-es alkalmazások számára elérhet k olyan API függvények, melyek segítségével auditálási eseményeket közvetlenül is képesek generálni. A kernel módú kód mindig generálhat auditálási eseményt. Ugyanakkor pedig azok a folyamatok, amelyek auditálási rendszerszolgáltatást hívnak, a SeAuditPrivilege privilégiummal kell rendelkezzenek, hogy sikeresen generálhassanak egy auditálási rekordot. Ez a követelmény megakadályozza azt, hogy egy rosszindulatú felhasználói módú program elrontsa a biztonsági naplózást. Az auditálási rekordok a megérkezésük után azonnal bekerülnek az LSA-nak küldend rekordok sorába, a rendszer nem várakozik, hogy csomagokban küldje azokat tovább. Az auditálási rekordok az SRM-r l kétféle módon kerülnek át a biztonsági alrendszerhez. Ha a rekord kicsi (kisebb, mint a maximális LPC üzenetméret), akkor LPC üzenetként lesz elküldve. Az auditálási rekordok az SRM címteréb l az LSA folyamat címterébe másolódnak át. Ha a rekord nagy, az SRM megosztott memóriát használ, hogy elérhet vé tegye az üzenetet az LSA számára. Ilyenkor egyszer en csak egy pointert továbbít egy LPC üzenetben.

A logon
A logon (bejelentkezés) a WinLogon processz, az LSA, egy vagy több hitelesít valamint az SAM közrem ködésével megy végbe. A hitelesít amelyek jogosultsági ellen rzéseket hajtanak végre. rutin,

rutinok olyan DLL-ek,

60

VII

VII. fejezet

A WinLogon egy megbízható folyamat, amely a biztonsággal kapcsolatos felhasználói beavatkozásokat kezeli. Koordinálja a logont, kezeli a logoffot, ill. olyan m veleteket irányít, mint a jelszavak bevitele logonnál, jelszavak megváltoztatása, a munkaállomás lezárása és a lezárás megszüntetése. A WinLogon processznek kell biztosítania azt, hogy a biztonsággal kapcsolatos m veletek ne legyenek láthatóak semelyik más aktív folyamat számára. Például, a WinLogon garantálja, hogy egy megbízhatatlan folyamat nem juthat hozzá egy desktop vezérléséhez ezen m veletek során, és ezáltal nem érheti el a jelszót. A WinLogon az egyetlen folyamat, amely logon kérést fogad a billenty zetr l. Ekkor hívja az LSA-t, hogy az ellen rizze a felhasználó jogosultságát a bejelentkezésre. Ha a jogosultság fennáll, a logon folyamat egy logon shellt aktivizál a felhasználó számára. A logonban részt vev komponensek közötti kapcsolatot a VII.26. ábra mutatja be.

61

VII

VII. fejezet

LSA szolgáltató (service) processz

WinLogon processz

LPC kommunikációs csatorna

LSA

SAM

0.26. ábra: A logonban részt vev komponensek

A WinLogon-inicializálás: A rendszer inicializálásakor, amikor még egyik felhasználói alkalmazás sem aktivizálódott, a WinLogon olyan lépéseket hajt végre, amiknek eredményeként nála lesz a munkaállomás vezérlése, amikor a rendszer már kész kiszolgálni a felhasználót. Ide tartozik például az, hogy létrehoz és megnyit három desktopot: egy alkalmazási desktopot, egy WinLogon desktopot és egy képerny -mentési desktopot. A Winlogon desktop biztonságát az teremti meg, hogy ezt a desktopot egyedül csak a WinLogon képes elérni. A másik két desktop elérése a WinLogon-on kívül a felhasználók számára is megengedett. Ez az elrendezés azzal jár, hogy ha a WinLogon desktop aktív, akkor semmilyen más folyamat nem férhet hozzá olyan aktív kódhoz vagy adathoz, amely ezzel a desktoppal van összefüggésben. A Windows NT ezt a megoldást arra használja fel, hogy védje azoknak a m veleteknek a biztonságát, amelyek a jelszó kezelésére, valamint a desktop zárására és a zárás feloldására vonatkoznak.

62

VII Miután a WinLogon desktop létrejött az inicializálás során,

VII. fejezet lesz az aktív desktop. Amikor a

WinLogon desktop aktív, akkor mindig lezárt állapotban van. A WinLogon csak akkor oldja fel a lezárást, amikor átkapcsol az alkalmazási desktopra, vagy a képerny -mentési desktopra. Ehhez még megjegyzend , hogy egyedül csak a WinLogon folyamat képes egy desktopot lezárni vagy a lezárást feloldani.

63

VIII. fejezet

I. KÉRDÉSEK, FELADATOK

I.1. Bevezetés

Melyek egy operációs rendszer alapfeladatai?

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

Melyek igaz állítások? Az operációs rendszerek szerkezeténél megismert virtuális gép (virtual machine) megközelítés el nye, hogy a virtuális gép a valódi hardvernél megbízhatóbb, védettebb m ködést biztosít. a virtuális gép segítségével egyidej leg több, különböz operációs rendszer is futtatható anélkül, hogy ezeken változtatni kellene. a virtuális gép m ködését a rajta futtatott operációs rendszer menet közben is szabadon megváltoztathatja.

Sorolja fel, hogy a korai operációs rendszerek milyen módszereket használtak a perifériás m veletek lassúságának ellensúlyozására.

Ismertesse a korai operációs rendszerek történeténél megismert batch rendszerek m ködését. Milyen elvi és gyakorlati HW, illetve SW fejlesztések köt dnek ehhez a korhoz?

Mit nevezünk spooling-nak? Miért vezet ez a módszer a számítógép jobb kihasználásához? Mondjon példát arra, hol használnak spooling-ot a korszer operációs rendszerekben.

1

VIII. fejezet

Melyik állítás igaz a spooling rendszereknél?

A spooling-hoz független számítógépek szükségesek, amelyek a lassú periféria és a központi számítógép közötti átvitelt intézik.

A spooling m ködéséhez a lemez perifériának közvetlen táreléréssel (DMA) kell m ködnie.

A spooling-nál különböz munkák feldolgozása és perifériás m veletei történhetnek egymással átlapoltan.

Melyek igaz állítások?

Minden id osztásos (time-sharing) operációs rendszer egyben valósidej (real-time) is, elosztott (distributed) is, multiprogramozott is.

Mi a hasonlóság és mi a különbség az operációs rendszerek történeténél megismert pufferelt adatátvitel és az ún. spooling módszer között? Mi a kapcsolat a jelenlegi operációs rendszerekben a multiprogramozás és a spooling között?

Mit jelent az operációs rendszereknél a multiprocesszing fogalma?

Definiálja a valósidej (real-time) operációs rendszer fogalmát. Ilyen-e az "általános" Unix rendszer?

Mit jelent a korszer operációs rendszerekben a batch feldolgozás?

Melyek az operációs rendszer f környezeti kapcsolatai?

2

VIII. fejezet

Milyen csatlakozási felületekkel rendelkezik egy operációs rendszer?

Hogyan látja az operációs rendszert az egyszer felhasználó, az alkalmazásfejleszt , illetve a rendszermenedzser?

Milyen el nyt nyújthat a szöveges felhasználói felület a grafikussal szemben?

Milyen el nyüket nyújthat a parancsnyelv viszonyítva?

kezel i felület a menürendszerhez

Mi a különbség a szinkron illetve aszinkron m ködés között?

Mire szolgálnak a batch-fájlok, illetve shell-script-ek?

Miben tér el a rendszerhívás a közönséges szubrutinhívástól?

Mit jelent az, hogy az operációs rendszer ,,kiterjeszti" a számítógép utasításkészletét?

Hogyan közvetíti a programozási nyelv a rendszerhívásokat a programozó számára?

Milyen el nnyel jár a rendszerhívások valamilyen magasszint programnyelvvel történ megadása?

Milyen módokon kapcsolódik az operációs rendszer a hardverhez?

Mi a készülékkezel (driver) program feladata?

Rajzolja le egy egyszer

mikroszámítógép felépítését és adja meg, hogy milyen

feladatokat látnak el az egyes részek!

Rajzolja le egy tipikus személyi számítógép felépítését és adja meg az egyes részek funkcióit!

3

VIII. fejezet

Milyen architektúrabeli eltéréseket mutat egy szuperszámítógép egy személyi számítógéphez képest?

Melyek egy szuperszámítógép lehetséges alkalmazási stílusai?

Milyen kapcsolatban vannak egymással egy operációs rendszer rétegei?

Melyek a moduláris programozás alapelvei?

Miért ütközik nehézségekbe egy operációs rendszer tiszta rétegszerkezet kialakítása?

Melyek egy operációs rendszer által megvalósítandó alapvet funkciócsoportok?

Hogyan valósul meg a rétegszerkezet a modern operációs rendszerekben?

Mire szolgál az operációs rendszer magja, a kernel?

Mi a virtuális hardver koncepció lényege?

Mi a kliens-szerver modell lényege?

Mi a kernel szerepe kliens-szerver modell esetén?

Milyen események aktiválhatják az operációs rendszert, ha az várakozó állapotban tartózkodik?

Milyen esetekben nem folytatódik az aktuális folyamat végrehajtása egy rendszerhívás végrehajtása után?

Mit nevezünk szinkron, illetve aszinkron rendszerhívásnak és hogyan valósíthatóak meg?

4

VIII. fejezet

Milyen feltételnek kell eleget tennie a hardver architektúrának a multiprogramozás megvalósíthatóságához?

Hogyan valósul meg egy B/K m velet szinkron rendszerhívás esetén?

Mi a specialitása a karakterenkénti, vagy bájtonkénti B/K m velet megvalósításának?

Miért kell az operációs rendszernek várakozási sort szerveznie a B/K készülékekre?

Mi a parancsértelmez feladata?

Milyen értelmezési prioritást követ a parancsértelmez ?

Mire szolgálnak a küls megszakítások?

Miért kell a teljes megszakítási rendszert kizárólag az operációs rendszernek kezelnie?

Hogyan teszi lehet vé az operációs rendszer a megszakítások felhasznákói programok által történ kezelését?

Milyen tipikus id kezelési funkciókat valósít meg az operációs rendszer?

Hogyan valósítható meg a korrekt id mérés?

Milyen hardver illetve szoftver hibákat kell az operációs rendszernek kezelnie?

Milyen lehet ségei vannak az operációs rendszernek valamely hiba bekövetkezése esetén?

Mi az alapvet különbség a küls megszakítás illetve a hibakezelés között?

5

VIII. fejezet

Miért van szükség a felhasználói programban kivételkezelés megvalósítására, és hogyan támogatja ezt az operációs rendszer?

Milyen

feladatokat

kell

végrehajtani

egy

operációs

rendszer

be,

illetve

kikapcsolásakkor?

I.2. Az operációs rendszer mint absztrakt, virtuális gép

Mi a különbség a multiprogramozás és a multiprocesszálás között?

Mi a különbség a vezérlési gráf és a vezérlési szál között?

Ismertesse a folyamatok logikai modelljét!

Mit jelent az, hogy a memória RAM modell szerint m ködik?

Mi jellemzi egy folyamat adott pillanatbeli állapotát?

Miben tér el egymástól a folyamatokhoz tartozó logikai, illetve a számítógép fizikai processzorának utasításkészlete?

Mi a különbség a logikai és a fizikai memória között?

Mi az eltérés a folyamatok illetve a szálak között, és milyen el nnyel jár a szálak alkalmazása?

Mit nevezünk multitaszkos operációs rendszernek?

Milyen célokat szolgálhat egyszerre több folyamat futtatása egy rendszerben?

6

VIII. fejezet

Milyen járulékos nehézség merül fel egy folyamatokból álló rendszer fejlesztése során a hagyományos szekvenciális programfejlesztési módszerhez képest?

Definiálja a független, verseng , illetve együttm köd folyamatok fogalmát! Milyen támogatást kell nyújtson az operációs rendszer ezek megvalósításához?

Milyen módon jönnek létre egy rendszer folyamatai?

Mikor nevezünk statikusnak, illetve dinamikusnak egy operációs rendszert?

Mi a különbség a hierarchikus és a globális er forrás-gazdálkodás között?

Miben tér el a PRAM modell a RAM modellhez képest?

Hasonlítsa össze a közös memórián, illetve az üzenetváltáson alapuló folyamatok közötti együttm ködést!

Miért van szükség a folyamatok szinkronizálására?

Mit nevezünk kritikus szakasznak?

Mi a folyamatok közötti kölcsönös kizárás?

Definiálja két folyamat egyidej ségét (randevúját) illetve precedenciáját!

Milyen elvárásoknak kell megfeleljen a kölcsönös kizárás megvalósítása?

Milyen megoldást ajánlott Peterson két folyamat közti kölcsönös kizárás szoftveres megvalósítására?

Miért van szükség hardvertámogatásra a kölcsönös kizárás megvalósításához, illetve milyen módszerek segítségével oldható ez meg?

7

VIII. fejezet

Hogyan garantálható, hogy a kritikus szakaszba belépni kívánó folyamatok véges id alatt be is jussanak?

Adja meg a szemafor primitív m veleteinek definícióját!

Hogyan alkalmazható a szemafor a precedencia, illetve a kölcsönös kizárás megvalósítására?

Szemaforok felhasználásával írjon olyan programrészletet (pl. eljárást), amely lehet vé teszi N (el re adott konstans) folyamat randevúját, azaz az összes folyamat bevárja egymást.

Egy laktanyát rség riz, az rség minden tagja (folyamat) tudja, hogy rhelyét csak akkor hagyhatja el, ha a váltás a következ r megérkezett. Szemaforokat használva írja

meg az rségváltás lebonyolításának algoritmusát.

Van N (el re adott konstans) folyamatunk, mindegyikük tudja a saját sorszámát. Szemaforok felhasználásával írjon olyan

WaitForMyTurn(i: INTEGER)

eljárást, amelyet ha az egyes folyamatok a saját sorszámukkal meghívják, akkor onnan a sorszámuk szerinti sorrendben lépnek ki, azaz egy folyamat az eljáráson belül várakozik mindaddig, amíg az összes nála kisebb sorszámú folyamat ki nem lépett ebb l az eljárásból.

Hasonlítsa össze a szemafor m veleteit az er forrás, illetve az esemény szinkronizációs eszközökkel!

Miért kell az er forrásokhoz, és a szemaforokhoz várakozási sorokat létrehozni?

8

VIII. fejezet

Lazán csatolt rendszerekben egymással kommunikáló folyamatok milyen különböz megnevezési módszereket használhatnak. Milyen paramétereket használnak az üzenetküldés (send) és üzenetfogadás (receive) parancs hívásakor a különböz módszerek alkalmazása esetén?

Üzenetváltásos modell esetén milyen módszereket használnak a kommunikációs m veletek helyességének visszajelzésére?

Milyen konzisztencia feltételt kell betartani a küld (send) parancs megvalósításakor?

Milyen megoldások alkalmazhatóak a küld (send), illetve fogad (receive) parancsoknál fellép várakozás kezelésére?

Milyen járulékos mellékhatásokat okoznak a kommunikációs m veletek a rendszer átmeneti tárolójának (pufferének) függvényében?

Definiálja a holtpont fogalmát!

Milyen problémákat okoz egy rendszerben a holtpont kialakulása?

Ismertesse az er forrásokért verseng rendszerekre vonatkozó rendszermodellt!

Ismertesse a holtpont kialakulásának feltételeit. Mikor elégségesek ezek a feltételek?

Hogyan követhet segítségével?

nyomon a holtpont kialakulása az er forrás foglaltsági gráf

Az operációs rendszer milyen általános eljárásokat használhat a holtpont kezelésére?

Milyen tényez kt l függ, hogy egy rendszerben milyen gyakorisággal következhet be holtpont?

9

VIII. fejezet

Mit jelent a holtpont elkerülése (deadlock avoidance)?

Mondjon egy-egy példát a holtpont megel zésénél (deadlock prevention) használt, a kialakulás különböz feltételeit figyelembe vev algoritmusokra.

Milyen algoritmust javasolt Coffman a holtpont észlelésére?

Mit nevezünk a holtpont szempontjából biztonságos állapotnak?

Mi a bankár algoritmus szerepe a holtpont probléma megoldásában?

Hogyan kombinálhatóak a holtpont kezelésére alkalmazott technikák?

Mikor alakulhatnak ki kommunikációs holtpontok?

Egy rendszerben 4 er forrásosztály van (A, B, C és D), az egyes osztályokba rendre 8, 11, 7 és 10 er forrás tartozik. A rendszerben 4 folyamat verseng az er forrásokért, a következ aktuális foglalással és maximális igénnyel:

maximális

Aktuális

A B C D A B C D P1 2 P2 7 P3 5 P4 4 2 6 6 1 5 3 3 2 4 4 4 3 0 3 2 2 2 1 2 1 3 2 0 2 3 2 2 2

A rendszer a bankár algoritmust alkalmazza a holtpont elkerülésére. Biztonságos állapotban van-e jelenleg a rendszer? Ha igen, mutassa meg, a folyamatok hogyan tudják befejezni m ködésüket, ha nem, hogyan alakulhat ki holtpont.

Ismertesse a kiéheztetés (starvation) fogalmát. Az operációs rendszer milyen eljárásokat használhat a kiéheztetés elkerülésére?

10

VIII. fejezet

Mutasson példát arra, mikor fordulhat el kiéheztetés.

Ismertesse a termel - fogyasztó problémát!

Milyen kérdést kell megoldani az írók - olvasók probléma esetén?

Mi az étkez filozófusok problémája?

Milyen probléma merül fel adatfolyamok illesztése esetén?

Mi a bels biztonság?

Mi a különbség a statikus és a dinamikus védelmi tartomány között?

Mi a hozzáférési mátrix?

Mi a globális tábla?

Mi a hozzáférési lista?

Mi a jogosítvány lista?

Mit takar a küls biztonság fogalma?

Mi az információ szivárgás?

Milyen

fenyegetések

léphetnek

fel

elosztott

rendszerek

küls

biztonságával

kapcsolatban?

Milyen támadási módszerek léteznek elosztott rendszerek küls kapcsolatban?

biztonságával

11

VIII. fejezet

Mi a ,,féreg"?

Mi a ,,trójai faló"?

I.3. Multiprogramozott operációs rendszerek

Mi a futásra kész állapotú folyamatok közös jellemz je?

Miért lehet szükség egy operációs rendszer felügyelete alatt futó folyamatoknál felfüggesztett állapotra. Mondjon konkrét példát a felfüggesztés okára.

Sorolja fel, hogy egy operációs rendszerben a rendszerhívások végrehajtása milyen f bb lépésekben zajlik. Mi a jelent sége annak, hogy a felhasználói programok és az operációs rendszer magja a CPU különböz m ködési módjában fut?

Rajzolja fel egy "tipikus", felfüggesztett állapotokat is használó operációs rendszerben a folyamatok állapot-átmeneti diagrammját az állapotok és az átmenetek elnevezésével. Mikor, milyen okok hatására következhet be a futó állapotból futásra kész állapotba átmenet?

Az operációs rendszerek a megszakítások kiszolgálására milyen alapvet módszereket alkalmazhatnak?

Ismertesse a hosszú-, közép- és rövidtávú ütemezés feladatát. Egy folyamat állapotátmeneti diagrammján jelölje be azokat az átmeneteket, amelyek a fenti ütemezéseket jelentik.

Milyen szempontok alapján történhet a folyamatok hosszútávú ütemezése?

12

VIII. fejezet

Ismertesse, hogy az operációs rendszer megszakítás kiszolgálása során milyen tevékenységeket hajt végre. Hogyan jelentkezik a megszakítások kiszolgálásánál a preemtív és a nem preemptív ütemezés különböz sége?

Mit jelent a CPU ütemezési algoritmusok paraméterei között a CPU kihasználtság?

Mi a kapcsolat a CPU ütemezési algoritmusok jellemzésére használt körülfordulási id (turnaround time) és várakozási id (waiting time) között?

Mikor nevezünk egy ütemez t preemptívnek?

Milyen paraméterek alapján lehet a különböz

CPU ütemezési algoritmusokat

értékelni? Definiálja a különböz paraméterek jelentését. Hasonlítsa össze valamely fenti paraméter alapján a legrégebben várakozó (FCFS) és a legrövidebb löketidej (SJF) algoritmusokat.

Ismertesse a legrövidebb löketidej (SJF, Shortest Job First) és a legrövidebb hátralév löketidej (SRTF, Shortest Remaining Time First) CPU ütemezési algoritmusokat,

kiemelve a közöttük lév lényeges különbségeket.

Definiálja a preemptív és a nem preemptív ütemez közötti különbséget. Rajzoljon fel egy felfüggesztett állapotokat nem tartalmazó folyamat állapotátmeneti diagrammot és illusztrálja ezen az ábrán is a preemptív és nem preemptív ütemezés közötti különbséget.

Milyen szempontok alapján lehet osztályozni a folyamatok ütemezésénél megismert visszacsatolt többszint sorokat (Multilevel Feedback Queues)?

Hogyan lehet a CPU löketid n (burst time) alapuló ütemezési algoritmusoknál a futásra kész folyamatok következ löketidejét meghatározni?

13

VIII. fejezet

Egy operációs rendszerben a következ folyamatok találhatók futásra kész állapotban (az érkezési id azt az id pillanatot jelenti, amikor a folyamat futásra késszé vált):

Folyamat érkezési

löketid

id P1 P2 P3 P4 P5 0 1 5 7 9 4 5 3 1 3

Adja meg, hogy az egyes folyamatok milyen sorrendben futnak le, számolja ki a folyamatok átlagos várakozási idejét sorrendi (First Come First Serve, FCFS), legrövidebb löketidej (Shortest Job First, SJF), legrövidebb hátralév löketidej (Shortest Remaining Time First, SRTF), 2 id egységnyi id szelet körforgó (Round Robin, RR), nem preemptív prioritásos ütemezés esetén.

Melyik ütemezési algoritmus esetén a legkisebb a válaszid (response time) szórása? legrégebben várakozó (First Come, First Served, FCFS), körbeforgó (Round Robin, RR), legrövidebb löketidej (Shortest Job First, SJF).

Mely állítások igazak a algoritmusra?

CPU ütemezésnél használt körbeforgó (Round Robin)

biztosítja a legkisebb átlagos várakozási id t. használata esetén nem lép fel a folyamatok kiéheztetése. használatával lehet valósidej operációs rendszert készíteni.

Mely állítások igazak a preemtív ütemez algoritmusra?

14

VIII. fejezet

mindig prioritásos ütemezési algoritmusokat használ annak eldöntésére, hogy mikor és melyik folyamatot kezdje el futtatni, alkalmazása esetén egy éppen futó folyamatot bármelyik id pillanatban megszakíthat és futásra kész állapotúvá tehet az operációs rendszer, használatával az operációs rendszer átlagos válaszideje (response time) csökkenthet .

Mely állítások igazak a prioritásos ütemez algoritmusokra? jobban kihasználják a CPU-t. használata holtpont kialakulásához vezethet. használata kiéheztetéshez vezethet.

Milyen ütemezési módszereket alkalmaznak szimmetrikus, illetve aszimmetrikus multiprocesszoros rendszerekben?

Definiálja a küls - (external) és bels tördel dés (internal fragmentation) fogalmát. Mondjon konkrét példát mindkét jelenségre.

Mit jelent a pozíció-független (position independent, PIC) programrészlet?

Mi a kapcsolatszerkeszt (linker) program feladata?

Mit jelent a változó méret

partíciós rendszerekben használt algoritmusoknál a

tárkihasználtság 1/3-os szabálya?

Mit jelent az átfed programrészekkel (overlay) történ tárkezelés?

Mi a tömörítés (garbage collection) szerepe a többpartíciós társzervezésben?

A

programfejlesztés,

illetve

futtatás

mely

fázisaiban

történhet

a

program

memóriacímeinek kötése?

Magyarázza el a változó méret partíciók lefoglalásánál használt

15

VIII. fejezet

legjobban megfelel (best fit), els megfelel (first fit), legrosszabban illeszked (worst fit) algoritmusokat. Egy rendszerben az adott pillanatban 100K, 600K, 200K, 300K, és 500K méret szabad területek vannak. Hogyan fog a fenti 3 algoritmus sorrendben 417K, 212K, 112K és 426K méret partícióknak helyet foglalni?

Ismertesse kombinált szegmens- és lapszervezést tartalmazó tárkezel hardver esetén a logikai-fizikai címtranszformáció módját. Melyek a kombinált társzervezés el nyei?

Ismertesse az igény szerinti lapozáson (demand paging) alapuló virtuális tárkezelésnél a legrégebben nem használt (LRU, Least Recently Used) és az újabb esély (Second Chance) lapcsere algoritmusokat. Hogyan lehet(ne) az LRU algoritmust implementálni? Milyen hardver támogatás szükséges az újabb esély algoritmushoz?

Definiálja a következ fogalmakat: verg dés (trashing), munkahalmaz (working set), térbeli- és id beli lokalitás. Hogyan lehet a folyamatok munkahalmazának méretét figyelembe venni a verg dés elkerüléséhez?

Milyen összefüggés van a virtuális tárkezelésnél munkahalmaz nagysága és a folyamat által okozott laphibák gyakorisága között? Hogyan lehet a laphiba gyakoriságot felhasználni a folyamatok számára allokált lapok számának meghatározásánál?

Ismertesse és hasonlítsa össze a virtuális tárkezelésnél használt FIFO és újabb esély (second chance) algoritmusokat. Milyen hardver támogatást igényelnek ezek?

Mit nevezünk Belady-féle anomáliának?

Milyen rész-id kb l áll össze a háttértáron lév lapokhoz való hozzáférési id ? Kis, vagy nagy lapok használata esetén kapunk jobb transfer id t?

16

VIII. fejezet

Egy igény szerinti lapozást alkalmazó rendszerben 4 fizikai memória lap található és sorban a következ virtuális lapokra történik hivatkozás:

1, 2, 3, 4, 2, 1, 5, 6, 2, 1, 2, 3, 7, 6, 3

Számítsa ki a rendszerben bekövetkez alkalmazása esetén: legrégebbi lap (FIFO), újabb esély (Second Chance),

laphibák számát a következ

algoritmusok

legrégebben nem használt (Least Recently Used, LRU), optimális. A négy fizikai lap kezdetben "üres", nem tartalmazza egyik virtuális lapot sem.

Mi a translation lookaside buffer, és mi a szerepe a fizikai cím kiszámításánál?

Melyek igaz állítások? A lapokat alkalmazó virtuális tárkezelésnél el forduló bels tördel dést csökkenteni lehet az egyes lapok méretének növelésével, az egyes lapok méretének csökkentésével, megfelel en kiválasztott lap elhelyezési (placement) stratégia alkalmazásával.

Melyek igaz állítások? A virtuális tárkezelésnél egyes lapokat ideiglenesen a tárba kell "fagyasztani" (page locking), azaz megakadályozni, hogy a lapcsere algoritmus cserére kijelölje, ha azokat több folyamat is használja, az adott lapokon valamelyik folyamat verme található, az adott lapokra folyamatban van perifériás m velet.

Melyek igaz állítások? Igény szerinti lapozást (demand paging) használó rendszerekben egy folyamat verg dik, ha

17

VIII. fejezet

a folyamatnak túl kicsi a prioritása. a folyamat munkahalmaza (working set) több lapból áll, mint ahány lapot a rendszer a folyamathoz rendel. a folyamat munkahalmaza nagyobb, mint a rendszer generálásakor megadott konstans. a folyamat futását gyakran szakítják meg nála nagyobb prioritású folyamatok.

Hogyan lehet egy szegmensszervezés védekezni?

tárkezel

rendszerben a túlcímzés ellen

Melyik állomány tárolási módszer esetén jelent gondot az állomány blokkjaihoz direkt hozzáférés megvalósítása? láncolt listás, indexelt, FAT-ot használó.

Ismertesse az állományokhoz tartozó blokkok tárolásához használt láncolt listás, az ún. FAT-os (File Allocation Table) és az indextáblás módszereket. Milyen el nyös tulajdonságokkal rendelkezik a FAT-os módszer?

Sorolja fel, milyen módszereket ismer a lemezegységen a szabad helyek illetve az egyes állományokhoz tartozó blokkok nyilvántartására.

Mit jelent a adattárolás biztonságának növelésére használt inkrementális mentés (incremental backup)?

Rajzolja fel egy mágneslemezes háttértár tipikus felépítését, valamint adja meg az egydimenziós blokkcímek meghatározási módját!

Mi a RAID (Redundant Array of Inexpensive Disks) technika lényege?

Egy 200 sávos (0 .. 199) mágneslemezegységen a fej jelenleg a 143-as sáv felett áll, ezt megel z en a 125-ös sávon szolgált ki egy átviteli kérelmet. Jelenleg a következ

18

VIII. fejezet

sávokra várakozik - a megadott érkezési sorrendben - egy-egy átviteli kérelem: 86, 147, 91, 177, 94, 150, 102, 175, 130. Adja meg, hogy a kéréseket az id rendi kiszolgálás (First Come, First Served, FCFS), legkisebb fejmozgás (Shortest Seek Time First, SSTF), pásztázó (SCAN), körkörös (Circular LOOK) algoritmus milyen sorrendben szolgálja ki, illetve közben a fej mekkora utat (hány sávnyit) tett meg.

Melyik a lemezm veletek ütemezésénél használt algoritmusnál nem lép fel kiéheztetés veszélye: pásztázó (SCAN), N lépéses pásztázó (N-SCAN), legrövidebb fejmozgáis idej (Shortest Seek Time First).

Melyek igaz állítások? A lemezm veletek ütemezésénél használt algoritmusok közül a következ nek a legkisebb az átlagos kiszolgálási id szórása: legrövidebb fejmozgási id (Shortest Seek Time First) pásztázó (SCAN) egyirányú pásztázó (Circular SCAN)

Melyek az ún. bels , illetve küls parancsok?

A felhasználóknak milyen igényei lehetnek egy felhasználói felülettel szemben?

Milyen feladatokat kell ellátnia a rendszeradminisztrátornak?

Milyen feladatokat kell ellátnia a rendszeradminisztrátornak a rendszer biztonságának növelése érdekében?

19

VIII. fejezet

I.4. Hálózati és elosztott rendszerek

Mit nevezünk elosztott rendszernek?

Soroljon fel legalább hármat az elosztott rendszerek alkalmazásával járó el nyök közül.

Elosztott rendszerekben mit jelent a skálázhatóság?

Mi a nyitottság elérésének legfontosabb feltétele?

Mi a különbség a szinkron, illetve az aszinkron üzenetküldés között?

Mi a különbség a csoportos multicast és a broadcast között?

Mi a függvényszállítás és mire szolgál?

Mit nevezünk protokollnak?

Milyen el nyökkel, illetve hátrányokkal jár a részlegesen összekapcsolt topológia a teljesen összekpcsoltal szemben?

Milyen részlegesen összekapcsolt hálózati topológiákat ismer? Hasonlítsa össze ket!

Adja meg az ISO OSI modell rétegeit és azok funkcióját! Mire szolgál a modell?

Milyen módszereket alkalmazhatnak forgalomirányításra (routing)?

Mi az alapvet különbség az áramkor- üzenet- és illetve csomagkapcsolás között?

Mi a távoli terminálszolgáltatás feladata?

20

VIII. fejezet

Hogyan hozza létre a telnet program a különféle típusú terminálok közötti kapcsolatot?

Hogyan valósul meg a kliens-szerver modell egy telnet kapcsolatban?

Mire szolgál a telnet parancsértelmez ?

Mi a különbség az ftp bináris és szöveges átviteli módja között?

Hogyan valósul meg a kliens szerver modell egy ftp kapcsolat során Windows illetve Unix alapú rendszerekben?

Mire szolgál az anonim belépés egy ftp szerverre, hogyan valósították meg ezt Unix alatt?

Milyen követelmények merülnek fel egy elosztott rendszerrel szemben?

Mit takar az er forrás megosztás? Milyen módszereket alkalmaznak er forrás megosztásra?

Hogyan biztosítható egy rendszer nyitottsága?

Mit jelent a virtuális párhuzamosság?

Hogyan biztosítható a skálázottság?

Hogyan tehet hibat r vé egy rendszer?

Mit jelent az átlátszóság fogalma?

Egy elosztott rendszerben mire szolgál a név feloldás (name resolution)?

Mi az el nye a hierarchikus névtér alkalmazásának?

21

VIII. fejezet

Mi a különbség a szinkron (azaz blokkolódó), illetve aszinkron (azaz nem blokkolódó) üzenetküldés között?

Hasonlítsa

össze

a

kliens-szerver

alapú,

a

csoportos

multicast,

illetve

a

függvényszállításon alapuló kommunikációs sémákat!

Egy elosztott operációs rendszer esetén mik az ún. nyílt szolgáltatások?

Hasonlítsa össze a munkaállomás-szerver és a processzor pool modellt!

Elosztott rendszerekben milyen konzisztenciákat kell biztosítani és miért?

Mi az el nye az elosztott fájlrendszer alkalmazásának a telnet vagy ftp alapú fájltranszferrel szemben?

Miben különbözik az elosztott állománykezelésnél az állományok elhelyezkedését eltakaró (location transparent), illetve az elhelyezkedést l független (location independent) elnevezés?

Milyen elnevezési módszereket alkalmazhatnak elosztott fájlrendszerekben?

Mire szolgál a leképezési táblák többszörözése?

Ismertesse az elosztott állományrendszerek implementációjánál használt távoli szolgáltatások (remote services) és helyi átmeneti tárolás (local cache) módszerek egymáshoz viszonyított el nyeit.

Átmeneti tárak használata esetén hogyan biztosítható azok konzisztenciája?

Definiálja és hasonlítsa össze az elosztott állománykezelésnél alkalmazott állapotot tároló (stateful) és állapot nélküli (stateless) szolgáltató implementációkat.

22

VIII. fejezet

Mire

szolgál

elosztott

rendszerekben

a

fájlok

megsokszorozása?

Milyen modulokból épül fel egy elosztott állományrendszer szolgáltató?

Milyen problémát jelent, ha az NFS elosztott állományrendszer teljesítményének növelésére a kliens oldalon helyi gyorsító tárat (cache) is használ? Az gyorsító tár betelése esetén a kliens oldal nem képes addig új állományt megnyitni, amíg valamelyik nyitott állományt le nem zárták. A szerver leállása és újraindulása után újra meg kell nyitni a korábban megnyitott állományokat. Az egyik kliens által a közösen használt állományszerkezetben létrehozott állományokat a többi kliens esetleg csak kés bb veszi észre.

Melyek igaz állítások? Az elosztott állománykezelésnél az állapotmentes (stateless) szolgáltató el nyösebb az állapotot tárolónál (statefull), mert az állományok kezelése sokkal gyorsabb. egyszer bb a szolgáltató újraindulása után a m veleteket folytatni. könnyebb a kérések jogosságának ellen rzése.

Mi az ún. démon folyamatok feladata?

Mi a különbség a hálózati, illetve az elosztott számítási modell között?

Mi a middleware?

Kliens szerver rendszereknél mi a kötés (binding) feladata, és milyen fajtái vannak?

Mi a szerver replikáció illetve az átmeneti tárolás (caching) közti különbség?

Mire szolgálnak a proxy szerverek?

23

VIII. fejezet

Mire szolgál az RPC protokoll?

Mit definiál az XDR szabvány, milyen esetben jelenthet hátrányt alkalmazása?

Mi az RPC szál, milyen el nnyel jár alkalmazása?

Milyen problémákhoz vezethet egy operációs rendszerben a szállak alkalmazása?

Mit neveznek küls , illetve bels szinkronizációnak?

Mi a Koordinált Univerzális Id ?

Milyen óra rendszereket ismer?

Mit jelent a stratum a Network Time Protocol-ban?

Hogyan m ködik a Network Time Protocol?

Mire szolgál a logikai óra?

Hogyan lehet definiálni a korábban-történt relációt?

Mit jelent a teljesen rendezett logikai óra fogalom, és minek a segítségével lehet elérni a teljes rendezést?

Sorolja fel az elosztott kölcsönös kizárás módszereit!

Ismertesse az elosztott rendszerekben a kölcsönös kizárás megvalósításra használható teljesen elosztott algoritmus m ködését. Melyek az algoritmus problémái a központosított algoritmussal összevetve?

24

VIII. fejezet

Ismertesse az id címkés elosztott kölcsönös kizárási algoritmust!

Mire szolgálnak a választási algoritmusok?

Mit feltételez a gy r választási algoritmus?

Mit feltételez a bully algoritmus?

Ismertesse az elosztott rendszerekben alkalmazott ún. er szakos (bully) választási (election) algoritmust.

Mi a feladata a biztonságpolitikának elosztott rendszerek védelménél?

Milyen területekre terjed ki egy rendszer védelme?

Milyen céljai lehetnek, illetve ezek elérésére milyen módszereket alkalmazhat egy lehetséges támadó?

Miért kellene formális módszerekkel igazolni a biztonsági protokoll helyességét?

Mi a biztonsági rendszerek két aranyszabálya?

Mi a különbség a nyilvános és a titkos kulcsú titkosítási rendszerek között?

Milyen problémát kel megoldani egy titkosító rendszerben a kulcsok szétosztásánál?

Mire szolgál a hitelesít szerver elosztott rendszerekben?

Ismertesse a Needham - Schroeder titkos kulcsú titkosítást (mutassa be az egyes lépéseket két folyamat titkos kommunikációjával)!

Milyen védelmi szinteket definiál a Kerberos hitelesít rendszer?

25

VIII. fejezet

Mi a DES?

Mit tartalmaz egy Kerberos jegy?

Mit tartalmaz egy Kerberos hitelesít (jegy)?

Kliens kérésére hogyan hitelesíti magát egy szerver Kerberos alatt?

Hogyan védekeznek a Kerberos rendszerben a felhasználónak kiadott, valamely szolgáltató felhasználására feljogosító jegy (ticket) mások általi felhasználása ellen?

Milyen el nyökkel, illetve hátránnyal jár a Kerberos hitelesít rendszer alkalmazása?

Mi a szerepe a Kerberos rendszerben a hitelesít nek (authenticator)? azonosítja a felhasználót a Kerberos rendszer számára; igazolja, hogy a jegyet (ticket) a jogos tulajdonosa nyújtotta be a szervernek; tartalmazza a felhasználó saját titkos kulcsát.

Mely állítások igazak? A Kerberos rendszerben egy szolgáltatás igénybevételére jogosító jegyet (ticket) az ügyfél és a szerver is dekódolni tudja a kapcsolatuk idejére kiadott titkos kulcs segítségével, csak a szerver tudja dekódolni a saját titkos kulcsa segítségével, egyik fél sem dekódolja, a szerver is kapott egy a felhasználóéval azonos jegyet, csak a benyújtott és ennek a tárolt jegynek az azonosságát ellen rzi.

I.5. UNIX

Milyen el nyöket biztosít a Unix rendszerek réteges bels szervezése?

26

VIII. fejezet

Milyen alapvet fejlesztéseket hajtottak végre a modern Unix rendszerek felépítésében?

Miért növeli a hatékonyságot Unix rendszerekben a szálak használata?

Rajzolja fel a Unix operációs rendszer folyamatainak teljes állapotátmeneti diagramját. Mi a zombie állapot szerepe, mikor kerül egy folyamat ebbe az állapotba és mikor hagyja azt el?

Ismertesse a Unix rendszerben a folyamatok létrehozásának mechanizmusát! Térjen ki a kernel által elvégzend feladatokra, és a folyamatok közötti leszármazási hierarchiára!

Ismertesse a Unix rendszerben a folyamatok leállításának mechanizmusát, a kernel által elvégzett feladatokat, és a folyamat szül jének küldött jelzés jelent ségét!

Mikor tér vissza hibával a UNIX operációs rendszerben a fork rendszerhívás? ha nincs a központi tárban elegend szabad tárterület; ha az operációs rendszer folyamat táblájában (process table) nincs üres hely; ha a felfüggesztett folyamatok száma átlépett egy a rendszer generálásakor megadott értéket. Mely állítások igazak? A UNIX operációs rendszerben egy folyamat megszüntekor zombie állapotú marad addig, amíg vannak még él gyerekei; az általa írt pipe-okat olvasó folyamatok még nem sz ntek meg; a szül - vagy annak halála esetén az init - el nem vette a folyamat visszatérési értékét. Sorolja fel, hogy a UNIX folyamatok esetén mi tartozik egy folyamat környezetéhez (context). A következ információk közül jelölje be azokat, amelyeket a UNIX kernel a

folyamatok ún. u-area területén tart. folyamat prioritása,

27

VIII. fejezet

folyamat futása alatt érvényes aktuális könyvtár, folyamat adatterületének nagysága és címe, folyamat által eddig felhasznált összes CPU id , a nyitott állományok aktuális pozíciója, a folyamat zombie állapotú gyermekeinek visszatérési értéke, az aktuálisan végrehajtódó rendszerhívások paraméterei, a folyamat állapota, a folyamat várakozásának (sleep) oka, a folyamat által lekezelt jelzések (signal) kezelésére szolgáló függvények címe. Mit jelent a UNIX operációs rendszerben, ha egy program setuid jogosultsággal rendelkezik?

Mire szolgálnak a hitelesít k (kredenciálisok) a Unix rendszerben?

Mire szolgál a UNIX operációs rendszerben a wait rendszerhívás?

Milyen ütemezést valósít meg a Unix SVR3? (Gondoljon a kernel, user módra.)

Mi a különbség a megszakítható és a nem megszakítható alvás közöttt?

Mit jelent, hogy a kernel kód reentrens?

Miért nem preemtív kernel módban a Unix ütemezése?

A UNIX operációs rendszer futásra kész folyamatai prioritása annál nagyobb minél kevesebb folyamatot futtat az adott felhasználó; minél kisebb tárterületet használ; minél régebben nem használta a CPU-t.

Miért van a UNIX kerneljében a várakozó állapotba átmenetet kiváltó sleep hívás mindig egy while ciklus belsejében?

28

VIII. fejezet

Jelölje be valamennyi olyan eseményt, amikor a UNIX operációs rendszerben biztosan környezetváltás (context switch) történik. egy futásra kész folyamat olyan jelzést kap, amit nem kezel le és nem is hanyagol el, a futónál nagyobb prioritású folyamat futásra késszé válik, a read rendszerhívás végrehajtásához szükséges diszk blokk nincs bent a gyorsító tárban (buffer cache), a futó folyamat exit rendszerhívást hajt végre, minden óramegszakítás bekövetkeztekor, a futó folyamat laphiba megszakítást okozott és a szükséges lap nincs a fizikai tárban, egy várakozó állapotban lév folyamat a folyamat által nem lekezelt jelzést (signal) kap.

Unix kernelben hol preemptiv a folyamatok ütemezése?

Mire szolgálnak a callout-ok, hogyan biztosítható minél hamarabbi végrehajtásuk?

A Unix operációs rendszer a folyamatainak ütemezésénél megkülönböztet rendszer- és felhasználói prioritásokat. Mikor kap egy folyamat rendszer prioritást és mit l függ ennek az értéke? Milyen paraméterek befolyásolják a felhasználói prioritás értékét?

Mire szolgál a whichqs?

Mutassa be a hagyományos Unix ütemez m ködését a következ példán: nice nincs, prioritás = CPU/2 + 60, csillapítás = CPU/2, az óra 60-at üt másodpercenként.

Melyek a hagyományos Unix rendszerekben megvalósított ütemezési algoritmus hiányosságai?

Ismertesse a UNIX operációs rendszer jelzéseinek (signal) fogalmát, az ezeket kezel rendszerhívásokat, fontosabb paramétereit. Hogyan reagálhat egy folyamat a neki küldött jelzésekre?

29

VIII. fejezet

Hol tárolja a UNIX operációs rendszer az egyes folyamatok által lekezelt jelzéseket (signal) kezel eljárások kezd címeit?

Milyen célokat szolgálnak, és milyen hatásuk lehet a jelzéseknek (signals) a Unix rendszerekben?

Mutassa meg, hogy az SVR2-beli signalkezelés miért nem volt megbízható!

Ismertesse az SVR4 és a BSD verziókban alkalmazott jelzésmenedzsmentet!

Ismertesse a UNIX operációs rendszer jelzéseinek (signal) kezelésére szolgáló legfontosabb rendszerhívások feladatát. Mikor, milyen állapotátmeneteknél juthatnak érvényre a jelzések? Mondjon konkrét példát, eseményt, mikor az operációs rendszer küld jelzést egy folyamatnak.

Milyen kapcsolat van a folyamatcsoportok és a terminál kezelés között?

Mi a viszony-objektum (session object) feladata?

Milyen célokat szolgálhat a folyamatok közötti kommunikáció?

Milyen fizikai tulajdonságai vannak a kommunikációs csatornának?

Milyen módszereket használnak a folyamatok a megnevezésre (naming)?

Milyen típusú szinkronizáció történik tárolás nélküli átvitel, véges kapacitású tároló, illetve végtelen kapacitású tároló típusú átviteli csatornák esetén?

Mi történik ha a kommunikáció folyamán az egyik folyamat leáll?

Hogyan kezelhet ek a hibás, iletve elveszett üzenetek?

30

VIII. fejezet

Sorolja fel a UNIX rendszerekben folyamatok közötti kommunikációra szolgáló módszereket. Melyek alkalmazhatok közülük csak szül -leszármazottai viszonylatban?

Ismertesse hogyan történik az adatok átvitele a Unix cs vezetékek (pipe) használatával. Térjen ki a széls séges esetekre (túltöltés, olvasás üres cs vezetékb l) is!

Ismertesse a Unix System V IPC mechanizmusainak közös(!) vonásait!

Mi a különbség az elnevezett (named) és az anonim (unnamed) Unix cs vezetékek (pipe) között? (Létrehozás, használat, megsz nés.)

Milyen problémák merülnek fel a System V által megvalósítot szemaforokkal kapcsolatban?

Mikor érdemes kommunikációra üzenet sorokat, illetve osztott memóriaterületet használni?

Melyek igaz állítások? A UNIX rendszer cs vezetékét (pipe) használva az író (write) folyamatnak soha nem kell várakoznia. az olvasó (read) eljárás csak akkor tér vissza, ha a cs vezetékb l beolvasta a megkívánt számú Byte-ot. minden cs vezetékhez külön tárbeli inode tartozik.

Jelölje be a felsoroltak közül az összes olyan információt, amelyek a UNIX operációs rendszer a memóriában lév inode adatszerkezetben tárol. az átvitel (írás vagy olvasás) aktuális poziciója, az inode azonosítója (kötet és a köteten belüli index), az állományt tartalmazó könyvtár inode-jának száma, az inode-hoz tartozó állomány tulajdonosának azonosítói (UID és GID). mutatók a tárban lév szabad inode-ok listájának megel z és következ elemére,

31

VIII. fejezet

Jelölje be a felsoroltak közül az összes olyan információt, amelyek egy UNIX kötet szuperblokkjában találhatók. a kötet mérete blokkokban; annak a könyvtárnak a helye (path), ahova a kötet fel van mount-olva, a szabad inode-ok egy részének sorszámai, a kötet blokkjainak mérete, a kötet tulajdonosa.

Hol és hogyan tárolja a UNIX operációs rendszer a lemezen lév állományokhoz tartozó blokkokat. Írja le, hogyan található meg egy állomány állomány 274452. Byte-ja (268x1024 + 20), feltételezve, hogy az egyes blokkok 1024 Byte mért ek, illetve egy köteten legfeljebb 232 blokk lehet.

Háromszoros indirekt blokkal mennyi tárolóegységet lehet megcímezni (1 blokk 1K, egy cím 4 byte - a számolás menetét kell megadni)?

Hogy néz ki Unix alatt egy könyvtár bejegyzés?

Egy UNIX folyamat az open("/path/filename", O_RDWR, O_CREAT) rendszerhívással sikeresen létrehoz egy új állományt. Írja le, hogy a ennek során milyen változások történtek a köteten tárolt adatszerkezetekben.

A

UNIX

operációs

rendszer

hierarchikus

könyvtárszerkezetében

milyen

adatszerkezettel ábrázolják az egyes állomány-nyilvántartásokat? Mi a különbség a szimbólikus és az ún. hard link között, hogyan ábrázolja a UNIX ezeket? Mikor nem lehet hard link-et létrehozni? Hogyan változik egy állományt leíró i-node tartalma, ha létrehozunk az állományra egy hard- illetve szimbolikus link-et?

A

UNIX

operációs

rendszerben

használt

diszk

gyorsítótár

(buffer

cache)

megvalósításánál mikor szerepel egy blokk egyidej leg a szabad blokkok listáján és a diszk blokkok hash listáján? Mikor kerül egy módosult blokk kiírásra? Sorolja fel a gyorsítótár alkalmazásának hátrányait.

32

VIII. fejezet

Mi a szerepe a szabad helyek nyilvántartásánál a kötet szuperblokkjának?

Milyen problémák adódnak az S5FS állományrendszer esetén, és hogyan oldották meg ezeket a Berkeley FFS esetén?

Mi a virtuális állományrendszer?

Milyen speciális állományrendszerek találhatóak Unix rendszerekben?

Milyen szempontokat kell figyelembe venni egy naplózó állományrendszer tervezése esetén?

Mit nevezünk tartománynak?

Milyen algoritmus szerint allokál helyet a swapper a háttértáron?

Milyen esetben csökken a map bejegyzések száma?

Miért nem ír ki háttértárra zombi folyamatot a swapper?

Milyen feltételeknek kell teljesülni, hogy a swapper egy folyamatot háttértárra írjon, illetve onnan beolvasson?

Ismertesse a háttértár kezelését fork, illetve memória növelés esetén!

Mi a legfontosabb különbség a tárcsere (swap) és az igény szerinti lapozás (demand paging) között?

Mit jelent a virtuális tárkezelésnél alkalmazott copy-on-write módszer?

33

VIII. fejezet

Ismertesse az igény szerinti lapozáshoz használt adatszerkezeteket és azok szerepét Unix alatt!

Ismertesse a "laplopó" folyamatot, annak m ködését lapok háttértárra írásakor, illetve onnan történ olvasásakor!

Milyen hardver támogatásra van szükség igény szerinti lapozás megvalósításához?

Milyen állapotokban lehet egy laphibát okozó lap?

Mi teszi lehet vé az igény szerinti lapozás elvi alkalmazását?

Mit jelent a munkahalmaz ablakszélessége?

Mire szolgál a Unixban a pfdata?

Milyen f bb adatszerkezeteket használnak a Unixban memória kezeléshez?

Milyen eltérés tapasztalható a BSD virtuális memóriakezelésében a System V implementációhoz képest?

Jellemezze az IP protokollt!

Mi a különbség az UDP és a TCP protokollok között?

Milyen lehet ségeket biztosít a Sun NFS a felhasználó számára?

Az NFS (Network File System) rendszerben a szerver oldalon az exportált könyvtáraknál a könyvtár nevén (elérési útján) kívül milyen paramétereket lehet megadni?

Sun NFS esetén mi a különbség a soft, illetve hard mount között?

34

VIII. fejezet

Milyen célokat tüzek ki a Sun NFS tervez i, és milyen típusú megvalósítást választottak?

Milyen protokollokat használ a Sun NFS, adja meg ezek funkcióját!

Adja meg a Sun NFS szoftver komponenseit és azok feladatát!

Milyen információkat tartalmaz egy RPC kérés-, illetve válasz-üzenet?

Mi a szerepe a virtuális fájl-rendszernek az NFS esetében?

Hogyan hajtódik végre egy write m velet távoli állomány esetén?

Mit ls hogyan definiál a Posix szabvány?

Milyen kategóriákat definiál a Posix szabvány az egyes el írások megvalósításának besorolására?

Az alkalmazás oldaláról milyen megfelel ségi kategóriákat különböztet meg a Posix?

Hogy definiálja a felhasználási környezetet a Posix?

Hogyan támogatja a Posix a hordozhatóságot?

Milyen eltéréseket mutat a Posix a könyvtárak kezelésében a hagyományos Unix megvalósításokhoz képest?

Mi a Posix által a folyamat-kezelésnél definiált session funkciója?

Mi a hasonlóság és különbség a System V, a BSD illetve a Posix szignál kezelésében?

35

VIII. fejezet

Milyen változást hozott a Posix terminál kezelése a hagyományos Unix rendszerekhez képest?

Milyen komponensekb l tev dik össze a Linux?

Hogyan jelentkezik a modularitás a Linux kernelben?

Melyek a Linux rendszerkönyvtárainak funkciói?

Hogyan támogatja a Linux a többszálú (multithreaded) programozást?

Mire szolgál a Linux-ban a socket interfész?

Milyen virtuális memória és fájlkezelést támogat a Linux?

I.6. Windows NT

Melyik az az alrendszere az NT-nek, ami nélkül nem tud futni?

Ismertesse az NT objektumainak általános jellemz it?

Sorolja fel az NT hardver függ rétegeit!

Mi volt a f oka annak, hogy a 4.0-s NT-ben a képerny kezel és grafikus funkciókat megvalósító rendszerkomponensek kernel módba kerültek?

Mi az NTDLL.DLL f funkciója és milyen m veleteket hajt végre?

Nevezzen meg egy kliens szerver modell alapján m köd komponenst az NT-ben.

36

VIII. fejezet

Mi a f különbség egy Win32-es alkalmazás és egy szolgáltatást megvelósító folyamat futása között az NT-ben?

Milyen operációs rendszer megvalósítási ideológiát tükröz az NT felépítése?

Sorolja fel az NT Executive rétegének f funkcióit?

Mondjon legalább három példát arra, hogy milyen többletszolgáltatást érhet el egy Win32-es programozói interface-t (felülelet) használó alkalmazás egy POSIX-es alkalmazáshoz képest?

Miért van két változata a string paramétert is használó a WIN32-es API hívásoknak?

Miért kerültek a Win32-es alrendszer egyes részei (pl. ablak-kezelés) kernel módban megvalósításra?

Melyik az a tulajdonsága a Windows 95/98-nak, amit az NT-s rendszerek sohasem fognak megvalósítani?

Milyen el nyei vannak a UNICODE használatának?

Ismertesse a NT alrendszereinek szerepét! Hogyan m ködnek együtt az alrendszerek a hozzájuk tartozó alkalmazásokkal? Példaként ismertesse, hogy egy Win32 API-ban definiált hívás az NT mely komponensében lehet megvalósítva?

Mutassa be részletesen az NT felépítését! Milyen szerepe és funkciója van a rendszerben a Kernel és a HAL (Hardware Abstraction Layer) rétegeknek?

Sorolja fel, milyen interface-eket ismer az NT-ben! Részletesen ismertesse az egyes interface-ek szerepét és a köztük lév különbségeket!

37

VIII. fejezet

Ismertesse, hogy milyen szolgáltatásokat és rendszer folyamatokat ismer az NT-ben és mi az egyes részek funkciója! Milyen operációs rendszer felépítési elvet tükröz az NT ezen részeinek megvalósítása? Rajzolja fel, hogy hogyan épül fel az NT szolgáltatásokat és rendszer folyamatokat megvalósító része!

Mit jelent az NT file rendszerének (NTFS) megvalósításakor használt "Mindent vagy semmit" elv?

Mi a különbség egy file attribútum rezidens és nem rezidens tárolása között az NT-ben?

Ismertesse az NT file rendszere elé állított legfontosabb tervezési követelményeket! Részletesen ismertesse, hogyan kerültek megvalósításra az egyes követelmények!

Mutassa be, hogy az NT hogyan tárolja az file-okat ill. a könyvtárakat a lemezen! Definiálja az NTFS metadata és a Master File Table fogalmát! Rajzolja fel, hogy hogyan tárolja az NT az adatokat a file record-ban!

Sorolja fel az NT memóriakezelésének legfontosabb jelemz it!

Hogyan történik a memória foglalása az NT-ben?

Hogyan valósítja meg az NT az memóriaterületek osztott elérését?

Milyen szinteken történik a memória védelem implementálása az NT-ben?

Mi a különbség egy file attribútum rezidens és nem rezidens tárolása között az NT-ben?

Hogyan optimalizálja a copy-on-write módszer a memóriahasználatot?

Hogyan kezeli a memórialapokat az NT?

Milyen a folyamatok logikai címterének a felépítése az NT-ben?

38

VIII. fejezet

Adja meg az NT által használt logikai cím felépítését!

Milyen adatszerkezeteket használ a logikai-fizikai címtranszformáció során az NT x86os processzorok esetén?

Milyen biztonsági szolgáltatásokat nyújt az NT?

Sorolja fel az NT biztonsági alrendszerének részeit!

Ismertesse, hogyan történik az objektumok védelme az NT-ben?

Ismertesse a logon menetét az NT-ben!

Hogyan kezeli az NT az interruptokat? Adjon példát, milyen interruptokat kezel a rendszer x86-os processzor esetén!

Ismertesse a trap kezel m ködését!

Mutassa be az NT objektumkezelésének alapjait!

Milyen szinkronizációs lehet séget kínál az NT a folyamatok számára?

Hogyan történik a kernel és az executive réteg folyamatainak szinkronizálása?

Mi a lokális eljáráshívás (Local Procedure Call) szolgáltatás m ködésének lényege, és az NT mely részei használnak LPC-t?

Milyen típusai léteznek az LPC hívásoknak?

Ismertesse az NT folyamat modelljét!

39

VIII. fejezet

Milyen adatstruktúrákat használ az NT a folyamatok leírásásra?

Mutassa be, hogyan történik a folyamatok létrehozása az NT-ben!

Milyen adatstruktúrákat használ az NT a szálak leírásásra?

Ismertesse egy szál létrehozásának lépéseit az NT-ben!

Milyen elvek alapján történik a szálak ütemezése az NT-ben?

Mit nevezünk kvantum-nak, és mi alapján számolja ki az NT a kvantum hosszát?

Milyen prioritási szintek vannak az NT-ben?

Mutassa be a szálak állapotátmenet diagrammját!

Mit nevezünk processzor affinitásnak, és mi a szerepe ütyemezéskor?

Hogyan választja ki az NT egy szál ütemezésekor, hogy melyik processzoron fog futni?

40



Hasonló témájú dokumentumok

Excel feladatok

- 2009-12-16 10:26:07

Előadásjegyzet - Dr. Vadász Dénes

- 2008-06-24 17:13:45

Infomédia konzultációs jegyzet Lengyelné Molnár Tünde

- 2008-01-26 17:22:56

Fazekas G - Oprendszerek 2 - formázott, 57-77; 84-108

- 2011-01-08 15:27:37

Operációs rendszerek 2 Fazekas Gábor

- 2009-10-06 18:44:28

A mások által feltöltött dokumentumokat értékelheted. Ha úgy ítéled meg, hogy a vizsgára való felkészülés szempontjából hasznos volt egy dokumentum, akkor adj rá sokcsillagos értékelést.
Ha hibákat tartalmaz, vagy egyéb probléma van vele, akkor keveset.
A dokumentumok sorrendje az értékelések alapján adódik. Ami fentebb van a listában, azt hasznosabbnak ítélték társaid. Az új dokumentumok pedig (értékelések hiányában) szintén a lista tetején kezdenek.

Hozzászólások

Ha észrevételed van egy dokumentummal kapcsolatban (például hibát találtál benne), akkor a Hozzászólások részben jelezheted. Az olyan jellegű kérdéseket mint pl.: A 2. feladat 4. sorából milyen átalakítással jutottunk az 5. sorban szereplő képlethez? - szintén ide érdemes írni

Egy tipp az oldalhoz! - Töltsétek ki a Tantárgyi adatlapokat a tantárgyak oldalain. Fontos lehet a tantárggyal kapcsolatos információ vagy az előadóval való egyszerű kapcsolattartás végett. Az adatlapot csak akkor módosíthatod ha az adott tárgyat a saját tárgyaidhoz adtad.