Systemy operacyjne.
Wydanie III
Autor:
T³umaczenie: Rados³aw Meryk, Miko³aj Szczepaniak
ISBN: 978-83-246-2311-2
Tytu³ orygina³u:
Modern Operating Systems (3rd Edition)
Format: 172
×245, stron: 1288
Wszystko, co chcesz wiedzieæ o systemach operacyjnych!
• Jak dzia³aj¹ algorytmy szeregowania?
• Jakie mo¿liwoœci stoj¹ za wirtualizacj¹?
• Jak systemy operacyjne zarz¹dzaj¹ pamiêci¹?
Ta ksi¹¿ka to aktualne wydanie œwiatowego bestsellera, bêd¹cego kompletnym Ÿród³em
wiedzy na temat wspó³czesnych systemów operacyjnych. Autor tego podrêcznika –
Andrew S. Tanenbaum – przez wiele lat projektowa³ trzy systemy operacyjne lub
wspó³uczestniczy³ w ich projektowaniu, dziêki czemu mo¿e dzieliæ siê sw¹ ogromn¹
wiedz¹ i doœwiadczeniem praktyka. W tej publikacji szczególny nacisk k³adzie on na
mo¿liwie szczegó³ow¹ prezentacjê takich aspektów systemów, jak procesy, w¹tki,
zarz¹dzanie pamiêci¹, systemy plików, operacje wejœcia-wyjœcia, zakleszczenia,
projektowanie interfejsu, multimedia, dylematy zwi¹zane z wydajnoœci¹ czy najnowsze
trendy w projektach systemów operacyjnych. W trakcie lektury poznasz dok³adnie
systemy operacyjne Windows, Linux oraz Symbian. Pozycja ta stanowi niezast¹pione
kompendium wiedzy na temat systemów operacyjnych, zarówno dla studentów
informatyki, jak i wszystkich pasjonatów komputera.
• Rys historyczny systemów operacyjnych
• Sprzêt komputerowy – przegl¹d komponentów
• Rodzaje systemów operacyjnych
• Struktura systemów operacyjnych
• Obs³uga wywo³añ systemowych
• Zarz¹dzanie procesami i w¹tkami oraz komunikacja miêdzy nimi
• Szeregowanie zadañ
• Zarz¹dzanie pamiêci¹
• Obs³uga systemów plików
• Urz¹dzenia wejœcia-wyjœcia
• Metody zarz¹dzania energi¹
• Rozwi¹zywanie problemu zakleszczeñ
• Charakterystyka multimedialnych systemów operacyjnych
• Obs³uga systemów wieloprocesorowych
• Wirtualizacja
• Bezpieczeñstwo danych na poziomie systemu operacyjnego
• Zagro¿enia ze strony z³oœliwego oprogramowania
• System Linux – historia, budowa, dzia³anie
• System Windows Vista – studium przypadku
• System Symbian – przeznaczenie, dzia³anie, obs³uga
Kompendium wiedzy o wspó³czesnych systemach operacyjnych!
5
SPIS TRECI
PRZEDMOWA
23
O AUTORZE
27
1
WPROWADZENIE
29
1.1.
CZYM JEST SYSTEM OPERACYJNY? 32
1.1.1.
System operacyjny jako rozszerzona maszyna 32
1.1.2.
System operacyjny jako meneder zasobów 34
1.2.
HISTORIA SYSTEMÓW OPERACYJNYCH 36
1.2.1.
Pierwsza generacja (1945 – 1955)
— lampy elektronowe 37
1.2.2.
Druga generacja (1955 – 1965)
— tranzystory i systemy wsadowe 37
1.2.3.
Trzecia generacja (1965 – 1980)
— ukady scalone i wieloprogramowo 40
1.2.4.
Czwarta generacja (1980 – czasy wspóczesne)
— komputery osobiste 45
1.3.
SPRZT KOMPUTEROWY — PRZEGLD 50
1.3.1.
Procesory 50
1.3.2.
Pami 54
1.3.3.
Dyski 58
1.3.4.
Tamy 59
6
SPIS TRECI
1.3.5.
Urzdzenia wejcia-wyjcia 59
1.3.6.
Magistrale 63
1.3.7.
Uruchamianie komputera 66
1.4.
PRZEGLD SYSTEMÓW OPERACYJNYCH 67
1.4.1.
Systemy operacyjne komputerów mainframe 67
1.4.2.
Systemy operacyjne serwerów 68
1.4.3.
Wieloprocesorowe systemy operacyjne 68
1.4.4.
Systemy operacyjne komputerów osobistych 68
1.4.5.
Systemy operacyjne komputerów podrcznych 69
1.4.6.
Wbudowane systemy operacyjne 69
1.4.7.
Systemy operacyjne wzów sensorowych 70
1.4.8.
Systemy operacyjne czasu rzeczywistego 70
1.4.9.
Systemy operacyjne kart elektronicznych 71
1.5.
POJCIA DOTYCZCE SYSTEMÓW OPERACYJNYCH 72
1.5.1.
Procesy 72
1.5.2.
Przestrzenie adresowe 74
1.5.3.
Pliki 75
1.5.4.
Wejcie-wyjcie 79
1.5.5.
Zabezpieczenia 79
1.5.6.
Powoka 80
1.5.7.
Ontogeneza jest rekapitulacj filogenezy 81
1.6.
WYWOANIA SYSTEMOWE 85
1.6.1.
Wywoania systemowe do zarzdzania procesami 90
1.6.2.
Wywoania systemowe do zarzdzania plikami 93
1.6.3.
Wywoania systemowe do zarzdzania katalogami 94
1.6.4.
Róne wywoania systemowe 96
1.6.5.
Interfejs Win32 API systemu Windows 97
1.7.
STRUKTURA SYSTEMÓW OPERACYJNYCH 99
1.7.1.
Systemy monolityczne 100
1.7.2.
Systemy warstwowe 101
1.7.3.
Mikrojdra 102
1.7.4.
Model klient-serwer 105
1.7.5.
Maszyny wirtualne 106
1.7.6.
Egzojdra 110
1.8.
WIAT WEDUG JZYKA C 111
1.8.1.
Jzyk C 111
1.8.2.
Pliki nagówkowe 112
1.8.3.
Due projekty programistyczne 113
1.8.4.
Model fazy dziaania 114
SPIS TRECI
7
1.9.
BADANIA DOTYCZCE SYSTEMÓW OPERACYJNYCH 115
1.10. PLAN POZOSTAEJ CZCI KSIKI 117
1.11. JEDNOSTKI MIAR 118
1.12. PODSUMOWANIE 119
2
PROCESY I WTKI
123
2.1.
PROCESY 123
2.1.1.
Model procesów 124
2.1.2.
Tworzenie procesów 126
2.1.3.
Koczenie dziaania procesów 129
2.1.4.
Hierarchie procesów 130
2.1.5.
Stany procesów 131
2.1.6.
Implementacja procesów 133
2.1.7.
Modelowanie wieloprogramowoci 135
2.2.
WTKI 137
2.2.1.
Wykorzystanie wtków 137
2.2.2.
Klasyczny model wtków 143
2.2.3.
Wtki POSIX 147
2.2.4.
Implementacja wtków w przestrzeni uytkownika 150
2.2.5.
Implementacja wtków w jdrze 153
2.2.6.
Implementacje hybrydowe 154
2.2.7.
Mechanizm aktywacji zarzdcy 155
2.2.8.
Wtki pop-up 157
2.2.9.
Przystosowywanie kodu jednowtkowego
do obsugi wielu wtków 158
2.3.
KOMUNIKACJA MIDZY PROCESAMI 161
2.3.1.
Wycig 162
2.3.2.
Regiony krytyczne 163
2.3.3.
Wzajemne wykluczanie
z wykorzystaniem aktywnego oczekiwania 165
2.3.4.
Wywoania sleep i wakeup 171
2.3.5.
Semafory 174
2.3.6.
Muteksy 177
2.3.7.
Monitory 182
2.3.8.
Przekazywanie komunikatów 188
2.3.9.
Bariery 191
8
SPIS TRECI
2.4.
SZEREGOWANIE 193
2.4.1.
Wprowadzenie do szeregowania 193
2.4.2.
Szeregowanie w systemach wsadowych 201
2.4.3.
Szeregowanie w systemach interaktywnych 203
2.4.4.
Szeregowanie w systemach czasu rzeczywistego 210
2.4.5.
Oddzielenie strategii od mechanizmu 212
2.4.6.
Szeregowanie wtków 212
2.5.
KLASYCZNE PROBLEMY
KOMUNIKACJI MIDZY PROCESAMI 214
2.5.1.
Problem piciu filozofów 214
2.5.2.
Problem czytelników i pisarzy 218
2.6.
PRACE BADAWCZE NAD PROCESAMI I WTKAMI 219
2.7.
PODSUMOWANIE 220
3
ZARZDZANIE PAMICI
227
3.1.
BRAK ABSTRAKCJI PAMICI 228
3.2.
ABSTRAKCJA PAMICI: PRZESTRZENIE ADRESOWE 232
3.2.1.
Pojcie przestrzeni adresowej 232
3.2.2.
Wymiana pamici 235
3.2.3.
Zarzdzanie woln pamici 237
3.3.
PAMI WIRTUALNA 241
3.3.1.
Stronicowanie 243
3.3.2.
Tabele stron 247
3.3.3.
Przyspieszenie stronicowania 249
3.3.4.
Tabele stron dla pamici o duej objtoci 253
3.4.
ALGORYTMY ZASTPOWANIA STRON 257
3.4.1.
Optymalny algorytm zastpowania stron 258
3.4.2.
Algorytm NRU 258
3.4.3.
Algorytm FIFO 260
3.4.4.
Algorytm drugiej szansy 260
3.4.5.
Algorytm zegarowy 261
3.4.6.
Algorytm LRU 262
3.4.7.
Programowa symulacja algorytmu LRU 263
3.4.8.
Algorytm bazujcy na zbiorze roboczym 265
SPIS TRECI
9
3.4.9.
Algorytm WSClock 269
3.4.10. Podsumowanie algorytmów zastpowania stron 271
3.5.
PROBLEMY PROJEKTOWE
SYSTEMÓW STRONICOWANIA 273
3.5.1.
Lokalne i globalne strategie alokacji pamici 273
3.5.2.
Zarzdzanie obcieniem 276
3.5.3.
Rozmiar strony 277
3.5.4.
Osobne przestrzenie instrukcji i danych 278
3.5.5.
Strony wspódzielone 279
3.5.6.
Biblioteki wspódzielone 281
3.5.7.
Pliki odwzorowane w pamici 283
3.5.8.
Strategia czyszczenia 284
3.5.9.
Interfejs pamici wirtualnej 284
3.6.
PROBLEMY IMPLEMENTACJI 285
3.6.1.
Zadania systemu operacyjnego
w zakresie stronicowania 286
3.6.2.
Obsuga bdów braku strony 287
3.6.3.
Wznawianie instrukcji 288
3.6.4.
Blokowanie stron w pamici 289
3.6.5.
Magazyn stron 290
3.6.6.
Oddzielenie strategii od mechanizmu 292
3.7.
SEGMENTACJA 294
3.7.1.
Implementacja klasycznej segmentacji 298
3.7.2.
Segmentacja ze stronicowaniem: MULTICS 298
3.7.3.
Segmentacja ze stronicowaniem: Intel Pentium 302
3.8.
BADANIA NAD ZARZDZANIEM PAMICI 307
3.9.
PODSUMOWANIE 308
4
SYSTEMY PLIKÓW
317
4.1.
PLIKI 319
4.1.1.
Nazwy plików 319
4.1.2.
Struktura pliku 321
4.1.3.
Typy plików 323
4.1.4.
Dostp do plików 325
4.1.5.
Atrybuty plików 325
10
SPIS TRECI
4.1.6.
Operacje na plikach 327
4.1.7.
Przykadowy program
wykorzystujcy wywoania obsugi systemu plików 328
4.2.
KATALOGI 331
4.2.1.
Jednopoziomowe systemy katalogów 331
4.2.2.
Hierarchiczne systemy katalogów 332
4.2.3.
Nazwy cieek 333
4.2.4.
Operacje na katalogach 335
4.3.
IMPLEMENTACJA SYSTEMU PLIKÓW 337
4.3.1.
Ukad systemu plików 337
4.3.2.
Implementacja plików 338
4.3.3.
Implementacja katalogów 344
4.3.4.
Pliki wspódzielone 347
4.3.5.
Systemy plików o strukturze dziennika 349
4.3.6.
Ksigujce systemy plików 352
4.3.7.
Wirtualne systemy plików 354
4.4.
ZARZDZANIE SYSTEMEM PLIKÓW I OPTYMALIZACJA 357
4.4.1.
Zarzdzanie miejscem na dysku 357
4.4.2.
Kopie zapasowe systemu plików 365
4.4.3.
Spójno systemu plików 371
4.4.4.
Wydajno systemu plików 375
4.4.5
Defragmentacja dysków 380
4.5.
PRZYKADOWE SYSTEMY PLIKÓW 381
4.5.1.
Systemy plików na pytach CD-ROM 381
4.5.2.
System plików MS-DOS 387
4.5.3.
System plików V7 systemu UNIX 391
4.6.
BADANIA DOTYCZCE SYSTEMÓW PLIKÓW 394
4.7.
PODSUMOWANIE 394
5
WEJCIE-WYJCIE
399
5.1.
WARUNKI, JAKIE POWINIEN SPENIA
SPRZT WEJCIA-WYJCIA 400
5.1.1.
Urzdzenia wejcia-wyjcia 400
5.1.2.
Kontrolery urzdze 402
SPIS TRECI
11
5.1.3.
Urzdzenia wejcia-wyjcia odwzorowane w pamici 403
5.1.4.
Bezporedni dostp do pamici (DMA) 407
5.1.5.
O przerwaniach raz jeszcze 410
5.2.
WARUNKI, JAKIE POWINNO SPENIA
OPROGRAMOWANIE WEJCIA-WYJCIA 415
5.2.1.
Cele oprogramowania wejcia-wyjcia 415
5.2.2.
Programowane wejcie-wyjcie 417
5.2.3.
Wejcie-wyjcie sterowane przerwaniami 419
5.2.4.
Wejcie-wyjcie z wykorzystaniem DMA 420
5.3.
WARSTWY OPROGRAMOWANIA WEJCIA-WYJCIA 420
5.3.1.
Procedury obsugi przerwa 421
5.3.2.
Sterowniki urzdze 422
5.3.3.
Oprogramowanie wejcia-wyjcia
niezalene od urzdze 426
5.3.4.
Oprogramowanie wejcia-wyjcia
w przestrzeni uytkownika 432
5.4.
DYSKI 435
5.4.1.
Sprzt 435
5.4.2.
Formatowanie dysków 452
5.4.3.
Algorytmy szeregowania da dostpu do dysku 456
5.4.4.
Obsuga bdów 459
5.4.5.
Stabilna pami masowa 462
5.5.
ZEGARY 466
5.5.1.
Sprzt obsugi zegara 466
5.5.2.
Oprogramowanie obsugi zegara 468
5.5.3.
Zegary programowe 471
5.6.
INTERFEJSY UYTKOWNIKÓW:
KLAWIATURA, MYSZ, MONITOR 473
5.6.1.
Oprogramowanie do wprowadzania danych 473
5.6.2.
Oprogramowanie do generowania wyjcia 479
5.7.
CIENKIE KLIENTY 496
5.8.
ZARZDZANIE ENERGI 499
5.8.1.
Problemy sprztowe 500
5.8.2.
Problemy po stronie systemu operacyjnego 501
5.8.3.
Problemy do rozwizania
w programach aplikacyjnych 507
12
SPIS TRECI
5.9.
BADANIA DOTYCZCE WEJCIA-WYJCIA 509
5.10. PODSUMOWANIE 510
6
Zakleszczenia
517
6.1.
ZASOBY 518
6.1.1.
Zasoby z moliwoci wywaszczania i bez niej 518
6.1.2.
Zdobywanie zasobu 520
6.2.
WPROWADZENIE W TEMATYK ZAKLESZCZE 521
6.2.1.
Warunki powstawania zakleszcze zasobów 522
6.2.2.
Modelowanie zakleszcze 523
6.3.
ALGORYTM STRUSIA 526
6.4.
WYKRYWANIE ZAKLESZCZE I ICH USUWANIE 526
6.4.1.
Wykrywanie zakleszcze
z jednym zasobem kadego typu 527
6.4.2.
Wykrywanie zakleszcze
dla przypadku wielu zasobów kadego typu 529
6.4.3.
Usuwanie zakleszcze 532
6.5.
UNIKANIE ZAKLESZCZE 534
6.5.1.
Trajektorie zasobów 534
6.5.2.
Stany bezpieczne i niebezpieczne 535
6.5.3.
Algorytm bankiera dla pojedynczego zasobu 537
6.5.4.
Algorytm bankiera dla wielu zasobów 538
6.6.
PRZECIWDZIAANIE ZAKLESZCZENIOM 540
6.6.1.
Atak na warunek wzajemnego wykluczania 540
6.6.2.
Atak na warunek wstrzymania i oczekiwania 541
6.6.3.
Atak na warunek braku wywaszczania 541
6.6.4.
Atak na warunek cyklicznego oczekiwania 542
6.7.
INNE PROBLEMY 543
6.7.1.
Blokowanie dwufazowe 543
6.7.2.
Zakleszczenia komunikacyjne 544
6.7.3.
Uwizienia 546
6.7.4.
Zagodzenia 548
SPIS TRECI
13
6.8.
BADANIA NA TEMAT ZAKLESZCZE 548
6.9.
PODSUMOWANIE 549
7
MULTIMEDIALNE
SYSTEMY OPERACYJNE
555
7.1.
WPROWADZENIE W TEMATYK MULTIMEDIÓW 556
7.2.
PLIKI MULTIMEDIALNE 561
7.2.1.
Kodowanie wideo 562
7.2.2.
Kodowanie audio 565
7.3.
KOMPRESJA WIDEO 567
7.3.1.
Standard JPEG 568
7.3.2.
Standard MPEG 571
7.4.
KOMPRESJA AUDIO 574
7.5.
SZEREGOWANIE PROCESÓW MULTIMEDIALNYCH 577
7.5.1.
Szeregowanie procesów homogenicznych 577
7.5.2.
Szeregowanie w czasie rzeczywistym
— przypadek ogólny 578
7.5.3.
Szeregowanie monotoniczne w czstotliwoci 580
7.5.4.
Algorytm szeregowania EDF 581
7.6.
WZORCE MULTIMEDIALNYCH SYSTEMÓW PLIKÓW 584
7.6.1.
Funkcje sterujce VCR 585
7.6.2.
Wideo niemal na yczenie 587
7.6.3.
Usuga wideo niemal na yczenie
z funkcjami magnetowidu 589
7.7.
ROZMIESZCZENIE PLIKÓW 591
7.7.1.
Umieszczanie pliku na pojedynczym dysku 591
7.7.2.
Dwie alternatywne strategie organizacji plików 592
7.7.3.
Rozmieszczenie plików w usudze wideo
niemal na yczenie 596
7.7.4.
Rozmieszczenie wielu plików na jednym dysku 598
7.7.5.
Rozmieszczanie plików na wielu dyskach 600
14
SPIS TRECI
7.8.
BUFOROWANIE 603
7.8.1.
Buforowanie bloków 603
7.8.2.
Buforowanie plików 605
7.9.
SZEREGOWANIE OPERACJI DYSKOWYCH
W SYSTEMACH MULTIMEDIALNYCH 606
7.9.1.
Statyczne szeregowanie operacji dyskowych 606
7.9.2.
Dynamiczne szeregowanie operacji dyskowych 608
7.10. BADANIA NA TEMAT MULTIMEDIÓW 610
7.11. PODSUMOWANIE 610
8
SYSTEMY WIELOPROCESOROWE
617
8.1.
SYSTEMY WIELOPROCESOROWE 620
8.1.1.
Sprzt wieloprocesorowy 620
8.1.2.
Typy wieloprocesorowych systemów operacyjnych 630
8.1.3.
Synchronizacja w systemach wieloprocesorowych 634
8.1.4.
Szeregowanie w systemach wieloprocesorowych 640
8.2.
WIELOKOMPUTERY 646
8.2.1.
Sprzt wielokomputerów 647
8.2.2.
Niskopoziomowe oprogramowanie komunikacyjne 651
8.2.3.
Oprogramowanie komunikacyjne
poziomu uytkownika 654
8.2.4.
Zdalne wywoania procedur 657
8.2.5.
Rozproszona wspódzielona pami 660
8.2.6.
Szeregowanie systemów wielokomputerowych 665
8.2.7.
Równowaenie obcienia 666
8.3.
WIRTUALIZACJA 669
8.3.1.
Wymagania dla wirtualizacji 671
8.3.2.
Hipernadzorcy typu 1 672
8.3.3.
Hipernadzorcy typu 2 673
8.3.4.
Parawirtualizacja 675
8.3.5.
Wirtualizacja pamici 678
8.3.6.
Wirtualizacja wejcia-wyjcia 679
8.3.7.
Urzdzenia wirtualne 681
8.3.8.
Maszyny wirtualne na procesorach wielordzeniowych 681
8.3.9.
Problemy licencji 682
SPIS TRECI
15
8.4.
SYSTEMY ROZPROSZONE 683
8.4.1.
Sprzt sieciowy 685
8.4.2.
Usugi i protokoy sieciowe 689
8.4.3.
Warstwa middleware bazujca na dokumentach 693
8.4.4.
Warstwa middleware bazujca na systemie plików 694
8.4.5.
Warstwa middleware bazujca na obiektach 700
8.4.6.
Warstwa middleware bazujca na koordynacji 701
8.4.7.
Siatki 707
8.5.
BADANIA DOTYCZCE
SYSTEMÓW WIELOPROCESOROWYCH 708
8.6.
PODSUMOWANIE 710
9
Bezpieczestwo
717
9.1.
RODOWISKO BEZPIECZESTWA 719
9.1.1.
Zagroenia 720
9.1.2.
Intruzi 721
9.1.3.
Przypadkowa utrata danych 723
9.2.
PODSTAWY KRYPTOGRAFII 723
9.2.1.
Kryptografia z kluczem tajnym 725
9.2.2.
Kryptografia z kluczem publicznym 726
9.2.3.
Funkcje jednokierunkowe 727
9.2.4.
Podpisy cyfrowe 727
9.2.5.
Modu TPM 729
9.3.
MECHANIZMY OCHRONY 730
9.3.1.
Domeny ochrony 730
9.3.2.
Listy kontroli dostpu 733
9.3.3.
Uprawnienia 736
9.3.4.
Systemy zaufane 740
9.3.5.
Zaufana baza obliczeniowa 742
9.3.6.
Modele formalne bezpiecznych systemów 743
9.3.7.
Bezpieczestwo wielopoziomowe 745
9.3.8.
Ukryte kanay 748
9.4.
UWIERZYTELNIANIE 753
9.4.1.
Uwierzytelnianie z wykorzystaniem hase 755
16
SPIS TRECI
9.4.2.
Uwierzytelnianie z wykorzystaniem
obiektu fizycznego 765
9.4.3.
Uwierzytelnianie z wykorzystaniem
technik biometrycznych 769
9.5.
ATAKI Z WEWNTRZ 772
9.5.1.
Bomby logiczne 773
9.5.2.
Tylne drzwi 773
9.5.3.
Podszywanie si pod ekran logowania 774
9.6.
WYKORZYSTYWANIE BDÓW W KODZIE 776
9.6.1.
Ataki z wykorzystaniem przepenienia bufora 777
9.6.2.
Ataki z wykorzystaniem acuchów formatujcych 780
9.6.3.
Ataki powrotu do biblioteki libc 782
9.6.4.
Ataki z wykorzystaniem
przepenie liczb cakowitych 783
9.6.5.
Ataki polegajce na wstrzykiwaniu kodu 784
9.6.6.
Ataki polegajce na rozszerzaniu uprawnie 786
9.7.
ZOLIWE OPROGRAMOWANIE 786
9.7.1.
Konie trojaskie 790
9.7.2.
Wirusy 793
9.7.3.
Robaki 805
9.7.4.
Oprogramowanie szpiegujce 808
9.7.5.
Rootkity 813
9.8.
RODKI OBRONY 819
9.8.1.
Firewalle 820
9.8.2.
Techniki antywirusowe i antyantywirusowe 822
9.8.3.
Podpisywanie kodu 830
9.8.4.
Wtrcanie do wizienia 832
9.8.5.
Wykrywanie wama z uyciem modeli 833
9.8.6.
Izolowanie kodu mobilnego 835
9.8.7.
Bezpieczestwo Javy 840
9.9.
BADANIA DOTYCZCE BEZPIECZESTWA 843
9.10. PODSUMOWANIE 844
SPIS TRECI
17
10 Pierwsze studium przypadku: Linux
851
10.1. HISTORIA SYSTEMÓW UNIX I LINUX 852
10.1.1. UNICS 852
10.1.2. PDP-11 UNIX 853
10.1.3. Przenony UNIX 855
10.1.4. Berkeley UNIX 856
10.1.5
Standard UNIX 857
10.1.6. MINIX 858
10.1.7. Linux 860
10.2. PRZEGLD SYSTEMU LINUX 863
10.2.1. Cele Linuksa 863
10.2.2. Interfejsy systemu Linux 865
10.2.3. Powoka 867
10.2.4. Programy uytkowe systemu Linux 870
10.2.5. Struktura jdra 872
10.3. PROCESY W SYSTEMIE LINUX 876
10.3.1. Podstawowe pojcia 876
10.3.2. Wywoania systemowe Linuksa
zwizane z zarzdzaniem procesami 879
10.3.3. Implementacja procesów i wtków w systemie Linux 884
10.3.4. Szeregowanie w systemie Linux 892
10.3.5. Uruchamianie systemu Linux 896
10.4. ZARZDZANIE PAMICI W SYSTEMIE LINUX 899
10.4.1. Podstawowe pojcia 899
10.4.2. Wywoania systemowe Linuksa
odpowiedzialne za zarzdzanie pamici 903
10.4.3. Implementacja zarzdzania pamici w systemie Linux 904
10.4.4. Stronicowanie w systemie Linux 911
10.5. OPERACJE WEJCIA-WYJCIA W SYSTEMIE LINUX 916
10.5.1. Podstawowe pojcia 916
10.5.2. Obsuga sieci 917
10.5.3. Wywoania systemowe wejcia-wyjcia
w systemie Linux 919
10.5.4. Implementacja wejcia-wyjcia w systemie Linux 921
10.5.5. Moduy w systemie Linux 925
18
SPIS TRECI
10.6. SYSTEM PLIKÓW LINUKSA 925
10.6.1. Podstawowe pojcia 926
10.6.2. Wywoania systemu plików w Linuksie 931
10.6.3. Implementacja systemu plików Linuksa 936
10.6.4. NFS — sieciowy system plików 945
10.7. BEZPIECZESTWO W SYSTEMIE LINUX 953
10.7.1. Podstawowe pojcia 953
10.7.2. Wywoania systemowe Linuksa
zwizane z bezpieczestwem 956
10.7.3. Implementacja bezpieczestwa w systemie Linux 957
10.8. PODSUMOWANIE 958
11 Drugie studium przypadku:
Windows Vista
965
11.1. HISTORIA SYSTEMU WINDOWS VISTA 965
11.1.1. Lata osiemdziesite: MS-DOS 966
11.1.2. Lata dziewidziesite: Windows na bazie MS-DOS-a 967
11.1.3. Lata dwutysiczne: Windows na bazie NT 967
11.1.4. Windows Vista 971
11.2. PROGRAMOWANIE SYSTEMU WINDOWS VISTA 972
11.2.1. Rdzenny interfejs programowania aplikacji
(API) systemu NT 975
11.2.2. Interfejs programowania aplikacji Win32 980
11.2.3. Rejestr systemu Windows 984
11.3. STRUKTURA SYSTEMU 987
11.3.1. Struktura systemu operacyjnego 988
11.3.2. Uruchamianie systemu Windows Vista 1006
11.3.3. Implementacja menedera obiektów 1007
11.3.4. Podsystemy, biblioteki DLL
i usugi trybu uytkownika 1019
11.4. PROCESY I WTKI SYSTEMU WINDOWS VISTA 1023
11.4.1. Podstawowe pojcia 1023
11.4.2. Wywoania API zwizane z zarzdzaniem zadaniami,
procesami, wtkami i wóknami 1029
11.4.3. Implementacja procesów i wtków 1036
SPIS TRECI
19
11.5. ZARZDZANIE PAMICI 1045
11.5.1. Podstawowe pojcia 1045
11.5.2. Wywoania systemowe
zwizane z zarzdzaniem pamici 1051
11.5.3. Implementacja zarzdzania pamici 1052
11.6. PAMI PODRCZNA SYSTEMU WINDOWS VISTA 1063
11.7. OPERACJE WEJCIA-WYJCIA
W SYSTEMIE WINDOWS VISTA 1066
11.7.1. Podstawowe pojcia 1067
11.7.2. Wywoania API zwizane z operacjami wejcia-wyjcia 1069
11.7.3. Implementacja systemu wejcia-wyjcia 1072
11.8. SYSTEM PLIKÓW NT SYSTEMU WINDOWS 1079
11.8.1. Podstawowe pojcia 1079
11.8.2. Implementacja systemu plików NTFS 1081
11.9. BEZPIECZESTWO W SYSTEMIE WINDOWS VISTA 1093
11.9.1. Podstawowe pojcia 1095
11.9.2. Wywoania API zwizane z bezpieczestwem 1097
11.9.3. Implementacja bezpieczestwa 1098
11.10. PODSUMOWANIE 1102
12 Trzecie studium przypadku:
Symbian OS
1107
12.1. HISTORIA SYSTEMU SYMBIAN OS 1108
12.1.1. Korzenie systemu operacyjnego Symbian OS:
Psion i EPOC 1108
12.1.2. Symbian OS 6 1110
12.1.3. Symbian OS 7 1111
12.1.4. Wspóczesna wersja systemu operacyjnego
Symbian OS 1111
12.2. PRZEGLD SYSTEMU SYMBIAN OS 1111
12.2.1. Obiektowo 1112
12.2.2. Projekt mikrojdra 1113
12.2.3. Nanojdro systemu Symbian OS 1114
12.2.4. Dostp do zasobów w trybie klient-serwer 1115
20
SPIS TRECI
12.2.5. Funkcje znane z wikszych systemów operacyjnych 1116
12.2.6. Komunikacja i multimedia 1117
12.3. PROCESY I WTKI W SYSTEMIE SYMBIAN OS 1117
12.3.1. Wtki i nanowtki 1118
12.3.2. Procesy 1119
12.3.3. Obiekty aktywne 1120
12.3.4. Komunikacja midzyprocesowa 1121
12.4. ZARZDZANIE PAMICI 1121
12.4.1. Systemy pozbawione pamici wirtualnej 1122
12.4.2. Adresowanie pamici w systemie Symbian OS 1124
12.5. WEJCIE I WYJCIE 1127
12.5.1. Sterowniki urzdze 1127
12.5.2. Rozszerzenia jdra 1128
12.5.3. Bezporedni dostp do pamici (DMA) 1128
12.5.4. Przypadek specjalny: noniki pamici 1129
12.5.5. Blokujce operacje wejcia-wyjcia 1129
12.5.6. Noniki wymienne 1130
12.6. SYSTEMY PRZECHOWYWANIA DANYCH 1130
12.6.1. Systemy plików dla urzdze mobilnych 1131
12.6.2. Systemy plików systemu operacyjnego Symbian OS 1132
12.6.3. Bezpieczestwo i ochrona systemu plików 1132
12.7. BEZPIECZESTWO W SYSTEMIE SYMBIAN OS 1133
12.8. KOMUNIKACJA W SYSTEMIE SYMBIAN OS 1136
12.8.1. Podstawowa infrastruktura 1136
12.8.2. Bardziej szczegóowa analiza
infrastruktury komunikacji 1137
12.9. PODSUMOWANIE 1141
13 Projekt systemu operacyjnego
1143
13.1. ISTOTA PROBLEMÓW ZWIZANYCH
Z PROJEKTOWANIEM SYSTEMÓW 1144
13.1.1. Cele 1144
13.1.2. Dlaczego projektowanie systemów operacyjnych
jest takie trudne? 1146
SPIS TRECI
21
13.2. PROJEKT INTERFEJSU 1148
13.2.1. Zalecenia projektowe 1148
13.2.2. Paradygmaty 1150
13.2.3. Interfejs wywoa systemowych 1155
13.3. IMPLEMENTACJA 1158
13.3.1. Struktura systemu 1158
13.3.2. Mechanizm kontra strategia 1163
13.3.3. Ortogonalno 1164
13.3.4. Nazewnictwo 1165
13.3.5. Czas kojarzenia nazw 1167
13.3.6. Struktury statyczne kontra struktury dynamiczne 1168
13.3.7. Implementacja z góry na dó
kontra implementacja z dou do góry 1170
13.3.8. Przydatne techniki 1171
13.4. WYDAJNO 1177
13.4.1. Dlaczego systemy operacyjne s powolne? 1177
13.4.2. Co naley optymalizowa? 1179
13.4.3. Dylemat przestrze – czas 1180
13.4.4. Buforowanie 1183
13.4.5. Wskazówki 1185
13.4.6. Wykorzystywanie efektu lokalnoci 1185
13.4.7. Optymalizacja z myl o typowych przypadkach 1186
13.5. ZARZDZANIE PROJEKTEM 1186
13.5.1. Mityczny osobomiesic 1187
13.5.2. Struktura zespou 1189
13.5.3. Znaczenie dowiadczenia 1191
13.5.4. Nie istnieje jedno cudowne rozwizanie 1192
13.6. TRENDY W WIECIE PROJEKTÓW
SYSTEMÓW OPERACYJNYCH 1192
13.6.1. Wirtualizacja 1193
13.6.2. Ukady wielordzeniowe 1193
13.6.3. Systemy operacyjne
z wielkimi przestrzeniami adresowymi 1194
13.6.4. Komunikacja sieciowa 1195
13.6.5. Systemy równolege i rozproszone 1196
13.6.6. Multimedia 1196
13.6.7. Komputery zasilane bateriami 1197
22
SPIS TRECI
13.6.8. Systemy wbudowane 1197
13.6.9. Wzy czujników 1198
13.7. PODSUMOWANIE 1198
14 Lista publikacji i bibliografia
1203
14.1. SUGEROWANE PUBLIKACJE DODATKOWE 1203
14.1.1. Publikacje wprowadzajce i ogólne 1204
14.1.2. Procesy i wtki 1204
14.1.3. Zarzdzanie pamici 1205
14.1.4. Wejcie-wyjcie 1205
14.1.5. Systemy plików 1206
14.1.6. Zakleszczenia 1206
14.1.7. Multimedialne systemy operacyjne 1207
14.1.8. Systemy wieloprocesorowe 1208
14.1.9. Bezpieczestwo 1209
14.1.10. System Linux 1211
14.1.11. System Windows Vista 1212
14.1.12. System Symbian OS 1213
14.1.13. Zasady projektowe 1213
14.2. BIBLIOGRAFIA W PORZDKU ALFABETYCZNYM 1214
Skorowidz
1247
123
2
PROCESY I WTKI
Zanim rozpocznie si szczegóowe studium tego, w jaki sposób systemy operacyjne
s zaprojektowane i skonstruowane, warto przypomnie, e kluczowym pojciem we
wszystkich systemach operacyjnych jest proces: abstrakcja dziaajcego programu.
Wszystkie pozostae elementy systemu operacyjnego bazuj na pojciu procesu,
dlatego jest bardzo wane, aby projektant systemu operacyjnego (a take student) jak
najszybciej dobrze zapozna si z pojciem procesu.
Procesy to jedne z najstarszych i najwaniejszych abstrakcji wystpujcych w sys-
temach operacyjnych. Zapewniaj one moliwo wykonywania (pseudo-) wspó-
bienych operacji nawet wtedy, gdy dostpny jest tylko jeden procesor. Przekszta-
caj one pojedynczy procesor CPU w wiele wirtualnych procesorów. Bez abstrakcji
procesów istnienie wspóczesnej techniki komputerowej byoby niemoliwe. W niniej-
szym rozdziale przedstawimy szczegóowe informacje na temat tego, czym s procesy
oraz ich pierwsi kuzynowie — wtki.
2.1. PROCESY
2.1
PROCESY
Wszystkie nowoczesne komputery bardzo czsto wykonuj wiele operacji jedno-
czenie. Osoby przyzwyczajone do pracy z komputerami osobistymi mog nie by do
koca wiadome tego faktu, zatem kilka przykadów pozwoli przybliy to zagadnie-
nie. Na pocztek rozwamy serwer WWW. dania stron WWW mog nadchodzi
z wielu miejsc. Kiedy przychodzi danie, serwer sprawdza, czy potrzebna strona
znajduje si w pamici podrcznej. Jeli tak, jest przesyana do klienta. Jeli nie,
inicjowane jest danie dyskowe w celu jej pobrania. Jednak z perspektywy procesora
124
PROCESY I WTKI
ROZ. 2
obsuga da dyskowych zajmuje wieczno. W czasie oczekiwania na zakocze-
nie obsugi dania na dysk moe nadej wiele kolejnych da. Jeli w systemie
jest wiele dysków niektóre z da moe by skierowanych na inne dyski na dugo
przed obsueniem pierwszego dania. Oczywiste, e potrzebny jest sposób zamo-
delowania i zarzdzania t wspóbienoci. Do tego celu mona wykorzysta procesy
(a w szczególnoci wtki).
Teraz rozwamy komputer osobisty uytkownika. Podczas rozruchu systemu
nastpuje start wielu procesów. Czsto uytkownik nie jest tego wiadomy. Na przy-
kad moe by uruchomiony proces oczekujcy na wchodzce wiadomoci e-mail.
Inny uruchomiony proces moe dziaa w imieniu programu antywirusowego i spraw-
dza okresowo, czy s dostpne jakie nowe definicje wirusów. Dodatkowo mog
dziaa jawne procesy uytkownika — na przykad drukujce pliki lub wypalajce
pyt CD — podczas gdy uytkownik przeglda strony WWW. Dziaaniami tymi trzeba
zarzdza. W tym przypadku bardzo przydaje si system z obsug wieloprogramo-
woci, obsugujcy wiele procesów jednoczenie.
W kadym systemie wieloprogramowym procesor szybko przecza si pomidzy
procesami, powicajc kademu z nich po kolei dziesitki bd setki milisekund.
Chocia cile rzecz biorc w dowolnym momencie procesor realizuje tylko jeden
proces, w cigu sekundy moe obsuy ich wiele, co daje iluzj wspóbienoci.
Czasami w tym kontekcie mówi si o pseudowspóbienoci, dla odrónienia jej
od rzeczywistej, sprztowej wspóbienoci systemów wieloprocesorowych (wypo-
saonych w dwa procesory wspódzielce t sam fizyczn pami lub wiksz liczb
takich procesorów). ledzenie wielu równolegych dziaa jest bardzo trudne. Z tego
powodu projektanci systemów operacyjnych w cigu wielu lat opracowali model poj-
ciowy (procesów sekwencyjnych), które uatwiaj obsug wspóbienoci. Ten
model, jego zastosowania oraz kilka innych konsekwencji stanowi temat niniejszego
rozdziau.
2.1.1. Model procesów
W tym modelu cae oprogramowanie moliwe do uruchomienia w komputerze —
czasami wcznie z systemem operacyjnym — jest zorganizowane w postaci zbioru
procesów sekwencyjnych (lub w skrócie procesów). Proces jest egzemplarzem
uruchomionego programu wcznie z biecymi wartociami licznika programu, reje-
strów i zmiennych. Pojciowo kady proces ma wasny wirtualny procesor CPU.
Oczywicie w rzeczywistoci procesor fizyczny przecza si od procesu do procesu.
Aby jednak zrozumie system, znacznie atwiej jest myle o kolekcji procesów dzia-
ajcych (pseudo) wspóbienie, ni próbowa ledzi to, jak procesor przecza si od
programu do programu. To szybkie przeczanie si procesora jest okrelane jako
wieloprogramowo, o czy mówilimy w rozdziale 1.
Na rysunku 2.1(a) pokazalimy komputer, w którym w pamici dziaaj w trybie
wieloprogramowym cztery programy. Na rysunku 2.1(b) wida cztery procesy —
PODROZ. 2.1
PROCESY
125
kady ma wasny przepyw sterowania (tzn. wasny logiczny licznik programu) i kady
dziaa niezalenie od pozostaych. Oczywicie jest tylko jeden fizyczny licznik pro-
gramu, dlatego kiedy dziaa wybrany proces, jego logiczny licznik programu jest
kopiowany do rzeczywistego licznika programu. Kiedy proces koczy dziaanie (na
pewien czas), jego fizyczny licznik programu jest zapisywany w logicznym liczniku
programu umieszczonym w pamici. Na rysunku 2.1(c) wida, e w duszym prze-
dziale czasu nastpi postp we wszystkich procesach, jednak w danym momencie
dziaa tylko jeden proces.
Rysunek 2.1. (a) Cztery programy uruchomione w trybie wieloprogramowym;
(b) pojciowy model czterech niezalenych od siebie procesów sekwencyjnych;
(c) w wybranym momencie jest aktywny tylko jeden program
W tym rozdziale zaoymy, e jest tylko jeden procesor CPU. Coraz czciej jednak
takie zaoenie okazuje si nieprawdziwe. Nowe ukady czsto s wielordzeniowe —
maj dwa procesory, cztery lub wiksz ich liczb. O ukadach wielordzeniowych
i systemach wieloprocesorowych powiemy wicej w rozdziale 8. Na razie bdzie
prociej, jeli przyjmiemy, e maszyna wykorzystuje jednorazowo tylko jeden proce-
sor. Jeli zatem mówimy, e procesor w danym momencie moe wykonywa tylko
jeden proces, to jeli zawiera dwa rdzenie (lub dwa procesory), na kadym z nich
w okrelonym momencie moe dziaa jeden proces.
Ze wzgldu na szybkie przeczanie si procesora pomidzy procesami, tempo,
w jakim proces wykonuje obliczenia, nie jest jednolite, a nawet trudne do powtórzenia
w przypadku ponownego uruchomienia tego samego procesu. A zatem nie mona
programowa procesów z wbudowanymi zaoeniami dotyczcymi czasu dziaania.
Rozwamy dla przykadu proces wejcia-wyjcia, który uruchamia tam streamera
w celu odtworzenia plików z kopii zapasowej, nastpnie wykonuje 10 000 iteracji pustej
ptli w celu rozpdzenia streamera do waciwej szybkoci i, na koniec, wydaje
polecenie przeczytania pierwszego rekordu. Jeli procesor zdecyduje si na prze-
czenie do innego procesu podczas trwania ptli, w której streamer si rozpdza,
proces obsugi tamy nie bdzie móg ponownie si uruchomi do momentu, kiedy
pierwszy rekord znajdzie si za gowic czytajc. Kiedy proces obowizuj tak
cise wymagania dziaania w czasie rzeczywistym — to znaczy okrelone zdarze-
nia musz wystpi w cigu okrelonej liczby milisekund — trzeba przedsiwzi
126
PROCESY I WTKI
ROZ. 2
specjalne rodki w celu zapewnienia, e tak si stanie. Zazwyczaj jednak wikszoci
procesów nie dotycz ograniczenia wieloprogramowoci procesora czy te wzgld-
ne szybkoci dziaania rónych procesów.
Rónica pomidzy procesem a programem jest subtelna, ale ma kluczowe znacze-
nie. Do wyjanienia tej rónicy posuymy si analogi. Zaómy, e pewien infor-
matyk o zdolnociach kulinarnych piecze urodzinowy tort dla swojej córki. Ma do
dyspozycji przepis na tort urodzinowy oraz kuchni dobrze wyposaon we wszystkie
skadniki: mk, jajka, cukier, aromat waniliowy itp. W tym przykadzie przepis spe-
nia rol programu (tzn. algorytmu wyraonego w odpowiedniej notacji), informatyk
jest procesorem (CPU), natomiast skadniki ciasta odgrywaj rol danych wejcio-
wych. Proces jest operacj, w której informatyk czyta przepis, dodaje skadniki
i piecze ciasto.
Wyobramy sobie teraz, e z krzykiem wbiega syn informatyka i mówi, e u-
dlia go pszczoa. Informatyk zapamituje, w którym miejscu przepisu si znajdowa
(zapisuje biecy stan procesu), bierze ksik o pierwszej pomocy i zaczyna post-
powa zgodnie z zapisanymi w niej wskazówkami. W tym momencie widzimy prze-
czenie si procesora z jednego procesu (pieczenie) do procesu o wyszym priory-
tecie (udzielanie pomocy medycznej). Przy czym kady z procesów ma inny program
(przepis na ciasto, ksika pierwszej pomocy medycznej). Kiedy informatyk poradzi
sobie z opatrzeniem udlenia, powraca do pieczenia ciasta i kontynuuje od miejsca,
w którym skoczy.
Kluczowe znaczenie ma uwiadomienie sobie, e proces jest pewnym dziaaniem.
Charakteryzuje si programem, wejciem, wyjciem i stanem. Jeden procesor moe
by wspódzielony przez kilka procesów za pomoc algorytmu szeregowania. Algo-
rytm ten decyduje, w którym zatrzyma prac nad jednym programem i rozpocz
obsug innego.
Warto zwróci uwag na to, e jeli program uruchomi si dwa razy, liczy si
jako dwa procesy. Na przykad czsto istnieje moliwo dwukrotnego uruchomienia
edytora tekstu lub jednoczesnego drukowania dwóch plików, jeli system kompu-
terowy jest wyposaony w dwie drukarki. Fakt, e dwa dziaajce procesy korzystaj
z tego samego programu, nie ma znaczenia — s to oddzielne procesy. System ope-
racyjny moe mie moliwo wspódzielenia kodu pomidzy nimi w taki sposób,
e w pamici znajduje si jedna kopia. Jest to jednak szczegó techniczny, który nie
zmienia faktu dziaania dwóch procesów.
2.1.2. Tworzenie procesów
Systemy operacyjne wymagaj sposobu tworzenia procesów. W bardzo prostych
systemach lub w systemach zaprojektowanych do uruchamiania tylko jednej aplikacji
(na przykad kontrolera w kuchence mikrofalowej), bywa moliwe zainicjowanie
wszystkich potrzebnych procesów natychmiast po uruchomieniu systemu. Jednak
PODROZ. 2.1
PROCESY
127
w systemach ogólnego przeznaczenia potrzebny jest sposób tworzenia i niszczenia
procesów podczas ich dziaania. W tym punkcie przyjrzymy si niektórym sporód
tych mechanizmów.
S cztery podstawowe zdarzenia, które powoduj tworzenie procesów:
1.
Inicjalizacja systemu.
2.
Uruchomienie wywoania systemowego tworzcego proces przez dziaajcy
proces.
3.
danie uytkownika utworzenia nowego procesu.
4.
Zainicjowanie zadania wsadowego.
W momencie rozruchu systemu operacyjnego zwykle tworzonych jest kilka procesów.
Niektóre z nich s procesami pierwszego planu — to znaczy s to procesy, które
komunikuj si z uytkownikami i wykonuj dla nich prac. Inne s procesami
drugoplanowymi, które nie s powizane z okrelonym uytkownikiem, ale spe-
niaj pewn specyficzn funkcj. Na przykad jeden proces drugoplanowy moe by
zaprojektowany do akceptacji wchodzcych wiadomoci e-mail. Taki proces moe
by upiony przez wikszo dnia i nagle si uaktywni, kiedy nadchodzi wiadomo
e-mail. Inny proces drugoplanowy moe by zaprojektowany do akceptacji wchodz-
cych da stron WWW zapisanych na serwerze. Proces ten budzi si w momencie
odebrania dania strony WWW w celu jego obsuenia. Procesy dziaajce na drugim
planie, które s przeznaczone do obsugi pewnych operacji, takich jak odbiór wiado-
moci e-mail, serwowanie stron WWW, aktualnoci, drukowanie itp., s okrelane
jako demony. W duych systemach zwykle dziaaj dziesitki takich procesów.
W systemie UNIX, aby wywietli list dziaajcych procesów, mona skorzysta
z programu
ps
. W systemie Windows mona skorzysta z menedera zada.
Procesy mog by tworzone nie tylko w czasie rozruchu, ale take póniej. Dzia-
ajcy proces czsto wydaje wywoanie systemowe w celu utworzenia jednego lub
kilku nowych procesów majcych pomóc w realizacji zadania. Tworzenie nowych
procesów jest szczególnie przydatne, kiedy prac do wykonania mona atwo sfor-
muowa w kontekcie kilku zwizanych ze sob, ale poza tym niezalenych, wspó-
dziaajcych ze sob procesów. Jeli na przykad przez sie jest pobierana dua
ilo danych w celu ich póniejszego przetwarzania, to mona utworzy jeden proces,
który pobiera dane i umieszcza je we wspódzielonym buforze, oraz drugi proces, który
usuwa dane z bufora i je przetwarza. W systemie wieloprocesorowym, w którym
kady z procesów moe dziaa na innym procesorze, zadanie moe by wykona-
ne w krótszym czasie.
W systemach interaktywnych uytkownicy mog uruchomi program poprzez
wpisanie polecenia lub kliknicie (ewentualnie dwukrotne kliknicie) ikony. Wyko-
nanie dowolnej z tych operacji inicjuje nowy proces i uruchamia w nim wskazany
128
PROCESY I WTKI
ROZ. 2
program. W systemach uniksowych bazujcych na systemie X Window nowy proces
przejmuje okno, w którym zosta uruchomiony. W systemie Microsoft Windows po
uruchomieniu procesu nie ma on przypisanego okna. Moe on jednak stworzy jedno
(lub wicej) okien i wikszo systemów to robi. W obydwu systemach uytkownicy
maj moliwo jednoczesnego otwarcia wielu okien, w których dziaaj jakie pro-
cesy. Za pomoc myszy uytkownik moe wybra okno i komunikowa si z proce-
sem, na przykad podawa dane wejciowe wtedy, kiedy s potrzebne.
Ostatnia sytuacja, w której s tworzone procesy, dotyczy tylko systemów wsa-
dowych w duych komputerach mainframe. W systemach tego typu uytkownicy
mog przesya do systemu zadania wsadowe (czasami zdalnie). Kiedy system ope-
racyjny zdecyduje, e ma zasoby wystarczajce do uruchomienia innego zadania,
tworzy nowy proces i uruchamia nastpne zadanie z kolejki.
Z technicznego punktu widzenia we wszystkich tych sytuacjach proces tworzy
si poprzez zlecenie istniejcemu procesowi wykonania wywoania systemowego
tworzenia procesów. Moe to by dziaajcy proces uytkownika, proces systemowy,
wywoany z klawiatury lub za pomoc myszy, albo proces zarzdzania zadaniami
systemowymi. Proces ten wykonuje wywoanie systemowe tworzce nowy proces.
To wywoanie systemowe zleca systemowi operacyjnemu utworzenie nowego procesu
i wskazuje, w sposób poredni lub bezporedni, jaki program naley w nim uruchomi.
W systemie UNIX istnieje tylko jedno wywoanie systemowe do utworzenia
nowego procesu:
fork
. Wywoanie to tworzy dokadny klon procesu wywoujcego.
Po wykonaniu instrukcji
fork
procesy rodzic i dziecko maj ten sam obraz pamici,
te same zmienne rodowiskowe oraz te same otwarte pliki. Po prostu s identyczne.
Wtedy zazwyczaj proces-dziecko uruchamia wywoanie
execve
lub podobne wywoa-
nie systemowe w celu zmiany obrazu pamici i uruchomienia nowego programu.
Kiedy uytkownik wpisze polecenie w rodowisku powoki, na przykad
sort
, powoka
najpierw tworzy proces-dziecko za pomoc wywoania
fork
, a nastpnie proces-dzie-
cko wykonuje polecenie
sort
. Powodem, dla którego dokonuje si ten dwuetapowy
proces, jest umoliwienie procesowi-dziecku manipulowania deskryptorami plików
po wykonaniu wywoania
fork
, ale przed wywoaniem
execve
w celu przekierowania
standardowego wejcia, standardowego wyjcia oraz standardowego urzdzenia bdów.
Dla odrónienia w systemie Windows jedna funkcja interfejsu Win32 —
Create
´Process
— jest odpowiedzialna zarówno za utworzenie procesu, jak i zaadowanie
odpowiedniego programu do nowego procesu. Wywoanie to ma 10 parametrów. S
to program do uruchomienia, parametry wiersza polecenia przekazywane do pro-
gramu, róne atrybuty zabezpiecze, bity decydujce o tym, czy otwarte pliki bd
dziedziczone, informacje dotyczce priorytetów, specyfikacja okna, jakie ma by utwo-
rzone dla procesu (jeli proces ma mie okno), oraz wskanik do struktury, w której
s zwracane do procesu wywoujcego informacje o nowo tworzonym procesie. Oprócz
wywoania
CreateProcess
interfejs Win32 zawiera okoo 100 innych funkcji do zarz-
dzania i synchronizowania procesów oraz wykonywania powizanych z tym operacji.
PODROZ. 2.1
PROCESY
129
Zarówno w systemie UNIX, jak i Windows po utworzeniu procesu rodzic i dziecko
maj osobne przestrzenie adresowe. Jeli dowolny z procesów zmieni sowo w swojej
przestrzeni adresowej, zmiana nie jest widoczna dla drugiego procesu. W systemie
UNIX pocztkowa przestrze adresowa procesu-dziecka jest kopi przestrzeni adre-
sowej procesu-rodzica. S to jednak cakowicie odrbne przestrzenie adresowe.
Zapisywalna pami nie jest wspódzielona pomidzy procesami (w niektórych imple-
mentacjach Uniksa tekst programu jest wspódzielony pomidzy procesami rodzica
i dziecka, poniewa nie moe on by modyfikowany). Nowo utworzony proces moe
jednak wspódzieli niektóre inne zasoby procesu swojego twórcy — na przykad
otwarte pliki. W systemie Windows przestrzenie adresowe procesów rodzica i dziecka
od samego pocztku s róne.
2.1.3. Koczenie dziaania procesów
Po utworzeniu proces zaczyna dziaanie i wykonuje swoje zadania. Nic jednak nie
trwa wiecznie — nawet procesy. Prdzej czy póniej nowy proces zakoczy swoje
dziaanie. Zwykle dzieje si to z powodu jednego z poniszych warunków:
1.
Normalne zakoczenie pracy (dobrowolnie).
2.
Zakoczenie pracy w wyniku bdu (dobrowolnie).
3.
Bd krytyczny (przymusowo).
4.
Zniszczenie przez inny proces (przymusowo).
Wikszo procesów koczy dziaanie dlatego, e wykonay swoj prac. Kiedy
kompilator skompiluje program, wykonuje wywoanie systemowe, które informuje
system operacyjny o zakoczeniu pracy. Tym wywoaniem jest
exit
w systemie UNIX
oraz
ExitProcess
w systemie Windows. W programach wyposaonych w interfejs
ekranowy zwykle s mechanizmy pozwalajce na dobrowolne zakoczenie dziaania.
W edytorach tekstu, przegldarkach internetowych i podobnych im programach
zawsze jest ikona lub polecenie menu, które uytkownik moe klikn, aby zleci
procesowi usunicie otwartych plików tymczasowych i zakoczenie dziaania.
Innym powodem zakoczenia pracy jest sytuacja, w której proces wykryje bd
krytyczny.
Jeli na przykad uytkownik wpisze polecenie:
cc foo.c
w celu skompilowania programu foo.c, a taki plik nie istnieje, to kompilator po prostu
skoczy dziaanie. Procesy interaktywne wyposaone w interfejsy ekranowe zwykle
nie kocz dziaania, jeli zostan do nich przekazane bdne parametry. Zamiast
tego wywietlaj okno dialogowe z prob do uytkownika o ponowienie próby.
130
PROCESY I WTKI
ROZ. 2
Trzecim powodem zakoczenia pracy jest bd spowodowany przez proces —
czsto wynikajcy z bdu w programie. Moe to by uruchomienie niedozwolonej
instrukcji, odwoanie si do nieistniejcego obszaru pamici lub dzielenie przez zero.
W niektórych systemach (na przykad w Uniksie) proces moe poinformowa system
operacyjny, e sam chce obsuy okrelone bedy. W takim przypadku, jeli wystpi
bd, proces otrzymuje sygna (przerwanie), zamiast zakoczy prac.
Czwartym powodem, dla którego proces moe zakoczy dziaanie, jest wyko-
nanie wywoania systemowego, które zleca systemowi operacyjnemu zniszczenie
innego procesu. W Uniksie mona to zrobi za pomoc wywoania systemowego
kill
.
Odpowiednikiem tego wywoania w interfejsie Win32 API jest
TerminateProcess
.
W obu przypadkach proces niszczcy musi posiada odpowiednie uprawnienia do
niszczenia innych procesów. W niektórych systemach zakoczenie procesu — nie-
zalenie od tego, czy jest wykonywane dobrowolnie, czy przymusowo — wie si
z zakoczeniem wszystkich procesów utworzonych przez ten proces. Jednak w taki
sposób nie dziaa ani system UNIX, ani Windows.
2.1.4. Hierarchie procesów
W niektórych systemach, kiedy proces utworzy inny proces, to proces-rodzic jest
w pewien sposób zwizany z procesem-dzieckiem. Proces-dziecko sam moe tworzy
kolejne procesy, co formuje hierarchi procesów. Zwrómy uwag, e w odrónieniu
od rolin i zwierzt rozmnaajcych si pciowo proces moe mie tylko jednego
rodzica (ale zero, jedno dziecko lub wicej dzieci).
W Uniksie proces wraz z wszystkimi jego dziemi i dalszymi potomkami tworzy
grup procesów. Kiedy uytkownik wyle sygna z klawiatury, sygna ten jest dostar-
czany do wszystkich czonków grupy procesów, które w danym momencie s powi-
zane z klawiatur (zwykle s to wszystkie aktywne procesy utworzone w biecym
oknie). Kady proces moe indywidualnie przechwyci sygna, zignorowa go lub
podj dziaanie domylne — to znaczy zosta zniszczonym przez sygna.
W celu przedstawienia innego przykadu sytuacji, w której hierarchia procesów
odgrywa rol, przyjrzyjmy si sposobowi, w jaki system UNIX inicjuje si podczas
rozruchu. W obrazie rozruchowym wystpuje specjalny proces o nazwie
init
. Kiedy
rozpoczyna dziaanie, odczytuje plik i informuje o liczbie dostpnych terminali. Nastp-
nie tworzy po jednym nowym procesie na terminal. Procesy te czekaj, a kto si
zaloguje. Kiedy logowanie zakoczy si pomylnie, proces logowania uruchamia
powok, która jest gotowa na przyjmowanie polece. Polecenia te mog urucha-
mia nowe procesy itd. Tak wic wszystkie procesy w caym systemie nale do
tego samego drzewa — jego korzeniem jest proces
init
.
Dla odrónienia w systemie Windows nie wystpuje pojcie hierarchii proce-
sów. Wszystkie procesy s sobie równe. Jedyn oznak hierarchii procesu jest to, e
podczas tworzenia procesu rodzic otrzymuje specjalny znacznik (nazywany uchwy-
tem — ang. handle), który moe wykorzysta do zarzdzania dzieckiem. Moe jednak
PODROZ. 2.1
PROCESY
131
swobodnie przekaza ten znacznik do innego procesu i w ten sposób zdezaktualizo-
wa hierarchi. Procesy w Uniksie nie maj moliwoci „wydziedziczenia” swoich
dzieci.
2.1.5. Stany procesów
Chocia kady proces jest niezalenym podmiotem, posiadajcym wasny licznik pro-
gramu i wewntrzny stan, procesy czsto musz si komunikowa z innymi proce-
sami. Jeden proces moe generowa wyjcie, które inny proces wykorzysta jako
wejcie. W poleceniu powoki:
cat rozdzial1 rozdzial2 rozdzial3 | grep drzewo
pierwszy proces uruchamia polecenie
cat
, czy i wyprowadza trzy pliki. Drugi proces
uruchamia polecenie
grep
, wybiera wszystkie wiersze zawierajce sowo „drzewo”.
W zalenoci od wzgldnej szybkoci obu procesów (co z kolei zaley zarówno od
wzgldnej zoonoci programów, jak i tego, ile czasu procesora kady z nich ma do
dyspozycji), moe si zdarzy, e polecenie
grep
bdzie gotowe do dziaania, ale nie
bd na nie czekay adne dane wejciowe. Proces bdzie si musia zablokowa do
czasu, a bd one dostpne.
Proces blokuje si, poniewa z logicznego punktu widzenia nie moe kontynu-
owa dziaania. Zazwyczaj dzieje si tak dlatego, e oczekuje na dane wejciowe,
które jeszcze nie s dostpne. Jest równie moliwe, e proces, który jest gotowy
i zdolny do dziaania, zostanie zatrzymany ze wzgldu na to, e system operacyjny
zdecydowa si przydzieli procesor na pewien czas jakiemu innemu procesowi.
Te dwie sytuacje diametralnie róni si od siebie. W pierwszym przypadku wstrzy-
manie pracy jest cile zwizane z charakterem problemu (nie mona przetworzy
wiersza polece wprowadzanego przez uytkownika do czasu, kiedy uytkownik go
nie wprowadzi). W drugim przypadku to techniczne aspekty systemu (niewystar-
czajca liczba procesorów do tego, aby kady proces otrzyma swój prywatny proce-
sor). Na rysunku 2.2 pokazano diagram stanów pokazujcy trzy stany, w jakich moe
znajdowa si proces:
1.
Dziaanie (rzeczywiste korzystanie z procesora w tym momencie).
2.
Gotowo (proces moe dziaa, ale jest tymczasowo wstrzymany, aby inny
proces móg dziaa).
3.
Blokada (proces nie moe dziaa do momentu, w którym wydarzy si jakie
zewntrzne zdarzenie).
Z logicznego punktu widzenia pierwsze dwa stany s do siebie podobne. W obu przy-
padkach proces chce dziaa, ale w drugim przypadku chwilowo brakuje dla niego
czasu procesora. Trzeci stan róni si od pierwszych dwóch w tym sensie, e proces
nie moe dziaa nawet wtedy, gdy procesor w tym czasie nie ma innego zajcia.
132
PROCESY I WTKI
ROZ. 2
Rysunek 2.2. Proces moe by w stanie dziaania, blokady lub gotowoci. Na rysunku
pokazano przejcia pomidzy tymi stanami
Tak jak pokazano na rysunku, pomidzy tymi trzema stanami moliwe s cztery
przejcia. Przejcie nr 1 wystpuje wtedy, kiedy system operacyjny wykryje, e pro-
ces nie moe kontynuowa dziaania. W niektórych systemach proces moe wykona
wywoanie systemowe, na przykad
pause
, w celu przejcia do stanu zablokowania.
W innych systemach, w tym w Uniksie, kiedy proces czyta dane z potoku lub pliku
specjalnego (na przykad terminala) i dane wejciowe s niedostpne, jest automa-
tycznie blokowany.
Przejcia nr 2 i nr 3 s realizowane przez program szeregujcy (ang. process sche-
duler) — cz systemu operacyjnego, a procesy nie s o tym nawet informowane.
Przejcie nr 2 zachodzi wtedy, gdy program szeregujcy zdecyduje, e dziaajcy pro-
ces dziaa wystarczajco dugo i nadszed czas, by przydzieli czas procesora jakie-
mu innemu procesowi. Przejcie nr 3 zachodzi wtedy, gdy wszystkie inne procesy
skorzystay ze swojego udziau i nadszed czas na to, by pierwszy proces otrzyma
procesor i wznowi dziaanie. Zadanie szeregowania procesów — to znaczy decydo-
wania o tym, który proces powinien si uruchomi, kiedy i na jak dugo — jest bardzo
wane. Przyjrzymy si mu bliej w dalszej czci tego rozdziau. Opracowano wiele
algorytmów majcych na celu zapewnienie równowagi pomidzy wymaganiami
wydajnoci systemu jako caoci oraz sprawiedliwego przydziau procesora do indy-
widualnych procesów. Niektóre z tych algorytmów omówimy w dalszej czci niniej-
szego rozdziau.
Przejcie nr 4 wystpuje wtedy, gdy zachodzi zewntrzne zdarzenie, na które
proces oczekiwa (na przykad nadejcie danych wejciowych). Jeli w tym momencie
nie dziaa aden inny proces, zajdzie przejcie nr 3 i proces rozpocznie dziaanie.
W innym przypadku moe by zmuszony do oczekiwania w stanie gotowoci przez
pewien czas, a procesor stanie si dostpny i nadejdzie jego kolejka.
Wykorzystanie modelu procesów znacznie uatwia mylenie o tym, co dzieje si
wewntrz systemu. Niektóre procesy uruchamiaj programy realizujce polecenia
wprowadzane przez uytkownika. Inne procesy s czci systemu i obsuguj takie
zadania, jak obsuga da usug plikowych lub zarzdzanie szczegóami dotycz-
cymi uruchamiania napdu dysku lub tam. Kiedy zachodzi przerwanie dyskowe,
system podejmuje decyzj o zatrzymaniu dziaania biecego procesu i uruchamia
proces dyskowy, który by zablokowany w oczekiwaniu na to przerwanie. Tak wic
zamiast myle o przerwaniach, moemy myle o procesach uytkownika, proce-
sach dysku, procesach terminala itp., które blokuj si w czasie oczekiwania, a co
PODROZ. 2.1
PROCESY
133
si wydarzy. Kiedy nastpi próba czytania danych z dysku albo uytkownik przycinie
klawisz, proces oczekujcy na to zdarzenie jest odblokowywany i moe wznowi
dziaanie.
Ten stan rzeczy jest podstaw modelu pokazanego na rysunku 2.3. W tym przy-
padku na najniszym poziomie systemu operacyjnego znajduje si program szere-
gujcy, zarzdzajcy zbiorem procesów wystpujcych w warstwie nad nim. Cay
mechanizm obsugi przerwa i szczegóów zwizanych z waciwym uruchamianiem
i zatrzymywaniem procesów jest ukryty w elemencie nazwanym tu zarzdc pro-
cesów. Element ten w rzeczywistoci nie zawiera zbyt wiele kodu. Pozostaa cz
systemu operacyjnego ma struktur procesów. W praktyce jednak istnieje bardzo
niewiele systemów operacyjnych, które miayby tak przejrzyst struktur.
Rysunek 2.3. Najnisza warstwa systemu operacyjnego o strukturze procesów
zarzdza przerwaniami i szeregowaniem. Powyej tej warstwy znajduj si sekwencyjne
procesy
2.1.6. Implementacja procesów
W celu zaimplementowania modelu procesów w systemie operacyjnym wystpuje
tabela (tablica struktur), zwana tabel procesów, w której kademu z procesów
odpowiada jedna pozycja — niektórzy autorzy nazywaj te pozycje blokami zarz-
dzania procesami. W blokach tych s zapisane wane informacje na temat stanu
procesu. Zawieraj one wartoci licznika programu, wskanika stosu, dane dotyczce
przydziau pamici, statusu otwartych procesów, rozlicze i szeregowania oraz
wszystkie inne informacje, które trzeba zapisa w czasie przeczania procesu ze stanu
wykonywany do stanu gotowy lub zablokowany. Dziki nim proces moe by póniej
wznowiony, tak jakby nigdy nie zosta zatrzymany.
W tabeli 2.1. pokazano kilka kluczowych pól w typowym systemie. Pola w pierw-
szej kolumnie s zwizane z zarzdzaniem procesami. Pozostae dwa cz si odpo-
wiednio z zarzdzaniem pamici oraz zarzdzaniem plikami. Naley zwróci uwag
na to, e obecno poszczególnych pól w tabeli procesów w duym stopniu zaley od
systemu. Ponisza tabela daje jednak ogólny obraz rodzajów potrzebnych informacji.
Teraz, kiedy przyjrzelimy si tabeli procesów, moemy wyjani nieco dokad-
niej to, w jaki sposób iluzja wielu sekwencyjnych procesów jest utrzymywana
w jednym procesorze (lub kadym z procesorów). Z kad klas wejcia-wyjcia wie
si lokalizacja (zwykle pod ustalonym adresem w dolnej czci pamici) zwana wek-
torem przerwa. Jest w niej zapisany adres procedury obsugi przerwania. Zaómy,
134
PROCESY I WTKI
ROZ. 2
Tabela 2.1. Przykadowe pola typowego wpisu w tabeli procesów
Zarzdzanie procesami
Zarzdzanie pamici
Zarzdzanie plikami
Rejestry
Licznik programu
Sowo stanu programu
Wskanik stosu
Stan procesu
Priorytet
Parametry szeregowania
Identyfikator procesu
Proces-rodzic
Grupa procesów
Sygnay
Czas rozpoczcia procesu
Wykorzystany czas CPU
Czas CPU procesów-dzieci
Godzina nastpnego alarmu
Wskanik do informacji
segmentu tekstu
Wskanik do informacji
segmentu danych
Wskanik do informacji
segmentu stosu
Katalog gówny
Katalog roboczy
Deskryptory plików
Identyfikator uytkownika
Identyfikator grupy
e w momencie wystpienia przerwania zwizanego z dyskiem ma dziaa proces
uytkownika nr 3. Sprzt obsugujcy przerwania odkada na stos licznik programu
procesu uytkownika nr 3, sowo stanu programu i czasami jeden lub kilka rejestrów.
Nastpnie sterowanie przechodzi pod adres okrelony w wektorze przerwa. To
jest wszystko, co robi sprzt. Od tego momentu obsug przerwania zajmuje si opro-
gramowanie — w szczególnoci procedura obsugi przerwania.
Obsuga kadego przerwania rozpoczyna si od zapisania rejestrów — czsto
pod pozycj tabeli procesów odpowiadajc biecemu procesowi. Nastpnie infor-
macje odoone na stos przez mechanizm obsugi przerwania s z niego zdejmo-
wane, a wskanik stosu jest ustawiany na adres tymczasowego stosu uywanego
przez procedur obsugi procesu. Takich dziaa, jak zapisanie rejestrów i ustawie-
nie wskanika stosu, nawet nie mona wyrazi w jzykach wysokopoziomowych,
takich jak C. W zwizku z tym operacje te s wykonywane przez niewielk procedur
w jzyku asemblera. Zazwyczaj jest to ta sama procedura dla wszystkich przerwa,
poniewa zadanie zapisania rejestrów jest identyczne, niezalenie od tego, co byo
przyczyn przerwania.
Kiedy ta procedura zakoczy dziaanie, wywouje procedur w jzyku C, która
wykonuje reszt pracy dla tego konkretnego typu przerwania (zakadamy, e system
operacyjny zosta napisany w jzyku C — w tym jzyku napisana jest wikszo
systemów operacyjnych). Kiedy procedura ta wykona swoje zadanie (co moe spo-
wodowa, e pewne procesy uzyskaj gotowo do dziaania), wywoywany jest pro-
gram szeregujcy, który ma sprawdzi, jaki proces powinien zosta uruchomiony
w nastpnej kolejnoci. Nastpnie sterowanie jest przekazywane z powrotem do
PODROZ. 2.1
PROCESY
135
kodu w asemblerze, który aduje rejestry i map pamici nowego biecego procesu
oraz rozpoczyna jego dziaanie. Obsug przerwa i szeregowanie podsumowano
w tabeli 2.2. Warto zwróci uwag, e róne systemy nieco si róni pewnymi
szczegóami.
Tabela 2.2. Szkielet dziaa wykonywanych przez najniszy poziom systemu
operacyjnego w momencie wystpienia przerwania
1.
Sprzt odkada na stos licznik programu itp.
2.
Sprzt aduje nowy licznik programu z wektora przerwa.
3.
Procedura w jzyku asemblera zapisuje rejestry.
4.
Procedura w jzyku asemblera ustawia nowy stos.
5.
Uruchamia si procedura obsugi przerwania w C (zazwyczaj czyta i buforuje dane wejciowe).
6.
Program szeregujcy decyduje o tym, który proces ma by uruchomiony w nastpnej
kolejnoci.
7.
Procedura w jzyku C zwraca sterowanie do kodu w asemblerze.
8.
Procedura w jzyku asemblera uruchamia nowy biecy proces.
Kiedy proces zakoczy dziaanie, system operacyjny wywietla symbol zachty i ocze-
kuje na nowe polecenie. Po otrzymaniu polecenia aduje do pamici nowy program,
nadpisujc star zawarto pamici.
2.1.7. Modelowanie wieloprogramowoci
Zastosowanie wieloprogramowoci pozwala na popraw wykorzystania procesora.
Z grubsza rzecz biorc, jeli przecitny proces jest przetwarzany przez 20% czasu
rezydowania w pamici, to w przypadku gdy w pamici jest jednoczenie pi pro-
cesów, procesor powinien by zajty przez cay czas. Ten model jest jednak niere-
alistycznie optymistyczny, poniewa zakada, e w adnym momencie nie zdarzy si
sytuacja, w której wszystkie pi procesów bdzie jednoczenie oczekiwao na ope-
racj wejcia-wyjcia.
Lepszym modelem jest spojrzenie na wykorzystanie procesora z probabilistycz-
nego punktu widzenia. Zaómy, e proces spdza fragment p swojego czasu na zako-
czeniu operacji wejcia-wyjcia. Przy n procesach znajdujcych si jednoczenie
w pamici prawdopodobiestwo tego, e wszystkie n procesów bdzie jednoczenie
oczekiwao na obsug wejcia-wyjcia (wtedy procesor pozostanie bezczynny),
wynosi p
n
. W takim przypadku wykorzystanie procesora mona opisa za pomoc
wzoru:
Wykorzystanie procesora = 1p
n
Na rysunku 2.4 pokazano procent wykorzystania procesora w funkcji n — co okrela
si jako stopie wieloprogramowoci.
Z rysunku jasno wynika, e jeli procesy spdzaj 80% czasu w oczekiwaniu na
operacje wejcia-wyjcia, to aby wspóczynnik marnotrawienia procesora utrzyma
136
PROCESY I WTKI
ROZ. 2
Rysunek 2.4. Wykorzystanie procesora w funkcji liczby procesów w pamici
na poziomie poniej 10%, w pamici musi by jednoczenie co najmniej 10 procesów.
Kiedy zdamy sobie spraw ze stanu, w którym proces interaktywny oczekuje, a
uytkownik wpisze na terminalu jakie dane, stanie si oczywiste, e czasy ocze-
kiwania na wejcia-wyjcia rzdu 80% i wicej nie s niczym niezwykym. Nawet
na serwerach procesy wykonujce wiele dyskowych operacji wejcia-wyjcia czsto
charakteryzuj si tak wysokim procentem.
Dla cisoci naley doda, e model probabilistyczny opisany przed chwil jest
tylko przyblieniem. Zakada on niejawnie, e wszystkie n procesów jest niezale-
nych. Oznacza to, e w przypadku systemu z picioma procesami w pamici dopusz-
czalnym stanem jest to, aby trzy z nich dziaay, a dwa czekay. Jednak przy jednym
procesorze nie ma moliwoci jednoczesnego dziaania trzech procesów. W zwizku
z tym proces, który osiga gotowo w czasie, gdy procesor jest zajty, bdzie musia
czeka. Tak wic procesy nie s niezalene. Dokadniejszy model mona stworzy
z wykorzystaniem teorii kolejokowania, jednak teza, któr sformuowalimy — wie-
loprogramowo pozwala procesom wykorzystywa procesor w czasie, gdy w innej
sytuacji byby on bezczynny — jest oczywicie w dalszym cigu prawdziwa. Faktu
tego nie zmieniaby nawet sytuacja, w której rzeczywiste krzywe stopnia wielopro-
gramowoci nieco odbiegayby od tych pokazanych na rysunku 2.4.
Mimo e model z rysunku 2.4 jest uproszczony, mona go wykorzystywa w celu
tworzenia specyficznych, jednak przyblionych prognoz dotyczcych wydajnoci pro-
cesora. Przypumy na przykad, e komputer ma 512 MB pamici, przy czym system
operacyjny zajmuje 128 MB, a kady z programów uytkownika równie zajmuje do
128 MB. Te rozmiary pozwalaj na to, aby w pamici jednoczenie znajdoway si trzy
programy uytkownika. Przy rednim czasie oczekiwania na operacje wejcia-wyjcia,
wynoszcym 80%, mamy procent wykorzystania procesora na poziomie 10,8
3
czyli okoo 49%. Dodanie kolejnych 512 MB pamici operacyjnej umoliwia przejcie
systemu z trójstopniowej wieloprogramowoci do siedmiostopniowej, co przyczyni si
do wzrostu wykorzystania procesora do 79%. Mówic inaczej, dodatkowe 512 MB
pamici podniesie przepustowo o 30%.
PODROZ. 2.2
WTKI
137
Dodanie kolejnych 512 MB spowodowaoby zwikszenie stopnia wykorzystania
procesora z 79% do 91%, a zatem podniosoby przepustowo tylko o kolejne 12%.
Korzystajc z tego modelu, waciciel komputera moe zadecydowa, e pierwsza roz-
budowa systemu jest dobr inwestycj, natomiast druga nie.
2.2. WTKI
2.2
WTKI
W tradycyjnych systemach operacyjnych kady proces ma przestrze adresow
i jeden wtek sterowania. W rzeczywistoci prawie tak wyglda definicja procesu.
Niemniej jednak czsto wystpuj sytuacje, w których korzystne jest posiadanie wielu
wtków sterowania w tej samej przestrzeni adresowej, dziaajcych quasi-równo-
legle — tak jakby byy (niemal) oddzielnymi procesami (z wyjtkiem wspódzielonej
przestrzeni adresowej). Sytuacje te oraz wynikajce z tego implikacje omówiono
w kolejnych punktach.
2.2.1. Wykorzystanie wtków
Do czego moe suy rodzaj procesu wewntrz innego procesu? Okazuje si, e
istniej powody istnienia tych miniprocesów zwanych wtkami. Spróbujmy przyjrze
si kilku z nich. Gównym powodem wystpowania wtków jest to, e w wielu aplika-
cjach jednoczenie wykonywanych jest wiele dziaa. Niektóre z nich mog by zablo-
kowane od czasu do czasu. Dziki dekompozycji takiej aplikacji na wiele sekwencyj-
nych wtków dziaajcych quasi-równolegle model programowania staje si prostszy.
Tak sam dyskusj przedstawilimy ju wczeniej. Dokadnie te same argu-
menty przemawiaj za istnieniem procesów. Zamiast myle o przerwaniach, licz-
nikach czasu i przeczaniu kontekstu, moemy myle o równolegych procesach.
Tyle e teraz, przy pojciu wtków, dodajemy nowy element: zdolno równolegych
podmiotów do wspódzielenia pomidzy sob przestrzeni adresowej oraz wszyst-
kich swoich danych. Zdolno ta ma kluczowe znaczenie dla niektórych aplikacji,
dlatego wanie obecno wielu procesów (z oddzielnymi przestrzeniami adresowymi)
w tym przypadku nie wystarczy.
Drugi argument, który przemawia za istnieniem wtków, jest taki, e — ponie-
wa s one mniejsze od procesów — w porównaniu z procesami atwiej (tzn. szybciej)
si je tworzy i niszczy. W wielu systemach tworzenie wtku trwa 10 – 100 razy krócej
od tworzenia procesu. Poniewa liczba potrzebnych wtków zmienia si dynamicznie
i gwatownie, szybko nabiera duego znaczenia.
Trzecim powodem istnienia wtków s wzgldy wydajnoci. Istnienie wtków
nie poprawi wydajnoci, jeli wszystkie one bd zwizane z procesorem. Jednak
w przypadku wykonywania intensywnych oblicze i jednoczenie znaczcej liczby
operacji wejcia-wyjcia wystpowanie wtków pozwala na nakadanie si na siebie
tych dziaa, co w efekcie kocowym przyczynia si do przyspieszenia aplikacji.
138
PROCESY I WTKI
ROZ. 2
Na koniec — wtki przydaj si w systemach wyposaonych w wiele procesorów,
gdzie moliwa jest rzeczywista wspóbieno. Do tego zagadnienia powrócimy
w rozdziale 8.
Najatwiej przekona si o przydatnoci wtków, analizujc konkretne przykady.
W roli pierwszego przykadu rozwamy edytor tekstu. Edytory tekstu zazwyczaj
wywietlaj na ekranie tworzony dokument sformatowany dokadnie w takiej postaci,
w jakiej bdzie on wyglda na drukowanej stronie. Zwaszcza wszystkie znaki podziau
wierszy i stron znajduj si na prawidowych i ostatecznych pozycjach. Dziki temu
uytkownik ma moliwo przegldania i poprawienia dokumentu, jeli zajdzie taka
potrzeba (na przykad w celu wyeliminowania sierot i wdów — niekompletnych
wierszy na pocztku i na kocu strony, które uwaa si za nieestetyczne).
Zaómy, e uytkownik pisze ksik. Z punktu widzenia autora najatwiej
umieci ca ksik w pojedynczym pliku, tak by atwiej byo wyszukiwa tematy,
wykonywa globalne operacje zastpowania itp. Alternatywnie mona umieci
kady z rozdziaów w osobnym pliku. Jednak umieszczenie kadego podrozdziau
i punktu w osobnym pliku, na przykad gdyby zasza potrzeba globalnego zastpienia
jakiego terminu w caej ksice, byoby prawdziwym utrapieniem. W takim przy-
padku trzeba by byo bowiem indywidualnie edytowa kady z kilkuset plików. Jeli
na przykad zaproponowany termin „standard xxxx” zostaby zatwierdzony tu przed
oddaniem ksiki do druku, trzeba by byo w ostatniej chwili zastpi wszystkie
wystpienia terminu „roboczo: standard xxxx” na „standard xxxx”. Jeli ksika znaj-
duje si w jednym pliku, tak operacj mona wykona za pomoc jednego polecenia.
Dla odrónienia, gdyby ksika skadaa si z 300 plików, kady z nich trzeba by
osobno otworzy w edytorze.
Rozwamy teraz, co si zdarzy, kiedy uytkownik nagle usunie jedno zdanie
z pierwszej strony 800-stronicowego dokumentu. Po sprawdzeniu poprawnoci zmo-
dyfikowanej strony zdecydowa, e chce wykona inn zmian na stronie 600 i wpisuje
polecenie zlecajce edytorowi przejcie do tej strony (na przykad poprzez wyszu-
kanie frazy, która znajduje si tylko tam). Edytor tekstu jest w tej sytuacji zmu-
szony do natychmiastowego przeformatowania caej ksiki do strony 600, ponie-
wa nie bdzie wiedzia, jak tre ma pierwszy wiersz na stronie 600, dopóki nie
przetworzy wszystkich poprzednich stron. Zanim bdzie mona wywietli stron
600, moe powsta znaczce opónienie, co doprowadzi do niezadowolenia uyt-
kownika.
W takim przypadku moe pomóc wykorzystanie wtków. Zaómy, e edytor
tekstu jest napisany jako program skadajcy si z dwóch wtków. Jeden wtek zaj-
muje si komunikacj z uytkownikiem, a drugi przeprowadza w tle korekt forma-
towania. Natychmiast po usuniciu zdania ze strony 1 wtek komunikacji z uytkow-
nikiem informuje wtek formatujcy o koniecznoci przeformatowania caej ksiki.
Tymczasem wtek komunikacji z uytkownikiem kontynuuje nasuchiwanie klawia-
tury i myszy i odpowiada na proste polecenia, takie jak przegldanie strony 1. W tym
samym czasie drugi z wtków w tle wykonuje intensywne obliczenia. Przy odrobinie
PODROZ. 2.2
WTKI
139
szczcia zmiana formatu zakoczy si, zanim uytkownik poprosi o przejcie na
stron 600. Jeli tak si stanie, przejcie na stron 600 bdzie mogo si odby bez-
zwocznie.
Kiedy ju jestemy przy edytorach, odpowiedzmy sobie na pytanie, dlaczego by
nie doda trzeciego wtku. Wiele edytorów tekstu jest wyposaonych w mechanizm
automatycznego zapisywania caego pliku na dysk co kilka minut. Ma to zapobiec
utracie caodniowej pracy w przypadku awarii programu, awarii systemu lub proble-
mów z zasilaniem. Trzeci wtek moe obsugiwa wykonywanie kopii zapasowych
na dysku, nie przeszkadzajc w dziaaniu pozostaym dwóm. Sytuacj z trzema wt-
kami pokazano na rysunku 2.5.
Rysunek 2.5. Edytor tekstu skadajcy si z trzech wtków
Gdyby program zawiera jeden wtek, to kade rozpoczcie wykonywania kopii
zapasowej na dysk powodowaoby, e polecenia z klawiatury i myszy byyby igno-
rowane do czasu zakoczenia wykonywania kopii zapasowej. Uytkownik z pew-
noci by to zauway jako obnion wydajno. Alternatywnie zdarzenia zwizane
z klawiatur i mysz mogyby przerwa wykonywanie kopii zapasowej na dysk, co
pozwolioby na zachowanie dobrej wydajnoci, ale prowadzioby do skomplikowanego
modelu programowania bazujcego na przerwaniach. W przypadku zastosowania
trzech wtków model programowania jest znacznie prostszy. Pierwszy wtek zaj-
muje si jedynie interakcjami z uytkownikiem. Drugi wtek przeformatowuje doku-
ment, kiedy otrzyma takie zlecenie. Trzeci wtek okresowo zapisuje zawarto
pamici RAM na dysk.
W tym przypadku powinno by jasne, e istnienie trzech oddzielnych procesów
w tej sytuacji si nie sprawdzi, poniewa wszystkie trzy wtki musz operowa na
tym samym dokumencie. Dziki wystpowaniu trzech wtków zamiast trzech pro-
cesów wtki wspódziel pami i w efekcie wszystkie maj dostp do edytowanego
dokumentu.
140
PROCESY I WTKI
ROZ. 2
Analogiczna sytuacja wystpuje w przypadku wielu innych interaktywnych
programów. Na przykad elektroniczny arkusz kalkulacyjny jest programem umoli-
wiajcym uytkownikowi obsug macierzy — niektóre z jej elementów s danymi
wprowadzanymi przez uytkownika. Inne elementy s wyliczane na podstawie wpro-
wadzonych danych i z wykorzystaniem potencjalnie skomplikowanych wzorów. Kiedy
uytkownik zmodyfikuje jeden element, moe zaj potrzeba obliczenia wielu innych
elementów. Dziki zdefiniowaniu dziaajcego w tle wtku zajmujcego si przelicza-
niem wtek interaktywny pozwala uytkownikowi na wprowadzanie zmian w czasie,
gdy s wykonywane obliczenia. Na podobnej zasadzie trzeci wtek moe samodziel-
nie obsugiwa kopie zapasowe wykonywane na dysku.
Rozwamy teraz jeszcze jeden przykad zastosowania wtków: serwer orodka
WWW. Przychodz dania stron, a w odpowiedzi dane strony s przesyane do
klienta. W wikszoci orodków WWW niektóre strony WWW s czciej odwie-
dzane ni inne. Na przykad gówna strona serwisu Sony jest odwiedzana znacznie
czciej od strony umieszczonej gboko w drzewie katalogów i zawierajcej spe-
cyfikacj techniczn jakiego modelu kamery wideo. Serwery WWW wykorzystuj ten
fakt do poprawy wydajnoci. Utrzymuj kolekcj czsto uywanych stron w pamici
gównej, aby wyeliminowa potrzeb odwoywania si do dysku w celu ich pobrania.
Taka kolekcja jest nazywana pamici podrczn (ang. cache) i wykorzystuje si j
równie take w wielu innych kontekstach. Na przykad w rozdziale 1. zetknlimy
si z pamiciami podrcznymi procesora.
Jeden ze sposobów organizacji serwera WWW pokazano na rysunku 2.6(a). W tym
przypadku jeden z wtków — dyspozytor — odczytuje z sieci przychodzce dania.
Po przeanalizowaniu dania wybiera bezczynny (tzn. zablokowany) wtek pracow-
nika i przekazuje mu danie — na przykad poprzez zapisanie wskanika do komu-
nikatu w specjalnym sowie powizanym z kadym wtkiem. Nastpnie dyspozytor
budzi upiony wtek pracownika — to znaczy zmienia jego stan z „zablokowany” na
„gotowy”.
Rysunek 2.6. Serwer WWW z obsug wielu wtków
PODROZ. 2.2
WTKI
141
Kiedy wtek si obudzi, sprawdza, czy jest w stanie speni danie z pamici pod-
rcznej strony WWW, do której maj dostp wszystkie wtki. Jeli tak nie jest, roz-
poczyna operacj odczytu w celu pobrania strony z dysku i przechodzi do stanu
„zablokowany”, trwajcego do chwili zakoczenia operacji dyskowej. Kiedy wtek
zablokuje si na operacji dyskowej, inny wtek zaczyna dziaanie, na przykad dys-
pozytor, którego zadaniem jest przyjcie jak najwikszej liczby da, albo inny pra-
cownik, który jest gotowy do dziaania.
W tym modelu serwer moe by zapisany w postaci kolekcji sekwencyjnych
wtków. Program dyspozytora zawiera ptl nieskoczon, w której jest pobierane
danie pracy, póniej wrczane pracownikowi. Kod kadego pracownika zawiera
ptl nieskoczon, w której jest akceptowane danie od dyspozytora i nastpuje
sprawdzenie, czy dana strona jest dostpna w pamici podrcznej serwera WWW.
Jeli tak, strona jest zwracana do klienta, a pracownik blokuje si w oczekiwaniu
na nowe danie. Jeli nie, pracownik pobiera stron z dysku, zwraca j do klienta
i blokuje si w oczekiwaniu na nowe danie.
W uproszczonej formie kod przedstawiono na listingu 2.1. W tym przypadku,
podobnie jak w pozostaej czci tej ksiki, zaoono, e
TRUE
odpowiada staej o war-
toci 1. Natomiast
buf
i
strona
s strukturami do przechowywania odpowiednio da-
nia pracy i strony WWW.
Listing 2.1. Uproszczona posta kodu dla struktury serwera z rysunku 2.6.
(a) Wtek dyspozytora; (b) wtek pracownika
(a)
(b)
while (TRUE){
pobierz_nast_zadanie(&buf);
przekaz_prace(&buf);
}
while (TRUE){
czekaj_na_prace(&buf)
szukaj_strony_w_pamieci_cache(&buf,
´&strona);
if ((&strona))
czytaj_strone_z_dysku(&buf,
´&strona);
zwroc_strone(&strona);
}
Zastanówmy si, jak mógby by napisany serwer WWW, gdyby nie byo wtków.
Jedna z moliwoci polega na zaimplementowaniu go jako pojedynczego wtku.
W gównej ptli serwera WWW nastpowayby pobieranie dania, jego analiza i reali-
zacja. Dopiero potem serwer WWW mógby pobra nastpne danie. Podczas ocze-
kiwania na zakoczenie operacji dyskowej serwer byby bezczynny i nie przetwarzaby
adnych innych przychodzcych da. Jeli serwer WWW dziaa na dedykowanej
maszynie, tak jak to zwykle bywa, w czasie oczekiwania serwera WWW na dysk pro-
cesor pozostaby bezczynny. W efekcie kocowym mona by byo przetworzy znacz-
nie mniej da na sekund. A zatem skorzystanie z wtków pozwala na uzyskanie
znaczcego zysku wydajnoci, ale kady z wtków jest programowany sekwencyj-
nie — w standardowy sposób.
142
PROCESY I WTKI
ROZ. 2
Do tej pory omówilimy dwa moliwe projekty: wielowtkowy serwer WWW
i jednowtkowy serwer WWW. Zaómy, e wtki nie s dostpne, ale projektanci
systemu uznali obnienie wydajnoci spowodowane istnieniem pojedynczego wtku
za niedopuszczalne. Jeli jest dostpna nieblokujca wersja wywoania systemowego
read
, moliwe staje si trzecie podejcie. Kiedy przychodzi danie, analizuje go
jeden i tylko jeden wtek. Jeeli danie moe by obsuone z pamici podrcznej,
to dobrze, ale jeli nie, inicjowana jest nieblokujca operacja dyskowa.
Serwer rejestruje stan biecego dania w tabeli, a nastpnie pobiera nastpne
zdarzenie do obsugi. Moe to by danie nowej pracy albo odpowied dysku doty-
czca poprzedniej operacji. Jeli jest to danie nowej pracy, rozpoczyna si jego
obsuga. Jeli jest to odpowied z dysku, waciwe informacje s pobierane z tabeli
i nastpuje przetwarzanie odpowiedzi. W przypadku nieblokujcych dyskowych ope-
racji wejcia-wyjcia odpowied zwykle ma posta sygnau lub przerwania.
W tym projekcie model „procesów sekwencyjnych” omawiany w pierwszych
dwóch przypadkach nie wystpuje. Stan oblicze musi by jawnie zapisany i odtwo-
rzony z tabeli, za kadym razem, kiedy serwer przecza si z pracy nad jednym
daniem do pracy nad kolejnym daniem. W rezultacie wtki i ich stosy s symu-
lowane w trudniejszy sposób. W projektach takich jak ten wszystkie obliczenia maj
zapisany stan. Ponadto istnieje zbiór zdarze, których wystpienie moe zmienia
okrelone stany. Takie systemy nazywa si automatami o skoczonej liczbie
stanów — pojcie to jest powszechnie uywane w brany komputerowej.
Teraz powinno by jasne, co oferuj wtki. Pozwalaj na utrzymanie idei procesów
sekwencyjnych wykonujcych blokujce wywoania systemowe (na przykad doty-
czce dyskowych operacji wejcia-wyjcia) z jednoczesnym uzyskaniem efektu wspó-
bienoci. Blokujce wywoania systemowe uatwiaj programowanie, a wspóbie-
no poprawia wydajno. Jednowtkowy serwer zachowuje prostot blokujcych
wywoa systemowych, ale gwarantuje wydajno. Trzecie podejcie pozwala na
osignicie wysokiej wydajnoci dziki wspóbienoci, ale wykorzystuje nieblo-
kujce wywoania i przerwania, dlatego jest trudne do zaprogramowania. Dostpne
modele zestawiono w tabeli 2.3.
Tabela 2.3. Trzy sposoby konstrukcji serwera
Model
Charakterystyka
Wtki
Wspóbieno, blokujce wywoania systemowe
Proces jednowtkowy
Brak wspóbienoci, blokujce wywoania systemowe
Automat o skoczonej liczbie stanów
Wspóbieno, nieblokujce wywoania systemowe,
przerwania
Trzecim przykadem zastosowania wtków s aplikacje, które musz przetwa-
rza due iloci danych. Normalne podejcie polega na przeczytaniu bloku danych,
przetworzeniu go, a nastpnie ponownym zapisaniu. Problem w takim przypadku
PODROZ. 2.2
WTKI
143
polega na tym, e jeli dostpne s tylko blokujce wywoania systemowe, proces
blokuje si, kiedy dane przychodz oraz kiedy s wysyane na zewntrz. Doprowa-
dzenie do sytuacji, w której procesor jest bezczynny w czasie, gdy jest wiele oblicze
do wykonania, to oczywiste marnotrawstwo i w miar moliwoci naley unika takiej
sytuacji.
Rozwizaniem problemu jest wykorzystanie wtków. Wewntrz procesu mona
wydzieli wtek wejciowy, wtek przetwarzania danych i wtek wyprowadzania
danych. Wtek wejciowy czyta dane do bufora wejciowego. Wtek przetwarzania
danych pobiera dane z bufora wejciowego, przetwarza je i umieszcza wyniki w bufo-
rze wyjciowym. Wtek wyprowadzania danych zapisuje wyniki z bufora wyjciowego
na dysk. W ten sposób wprowadzanie danych, ich wyprowadzanie i przetwarzanie
mog by realizowane w tym samym czasie. Oczywicie model ten dziaa tylko wtedy,
kiedy wywoanie systemowe blokuje wycznie wtek wywoujcy, a nie cay proces.
2.2.2. Klasyczny model wtków
Teraz, kiedy pokazalimy, do czego mog si przyda wtki i jak ich mona uywa,
spróbujmy przeanalizowa to zagadnienie nieco dokadniej. Model procesów bazuje
na dwóch niezalenych pojciach: grupowaniu zasobów i uruchamianiu. Czasami
wygodnie jest je rozdzieli — wtedy mona skorzysta z wtków. Najpierw przyj-
rzymy si klasycznemu modelowi wtków. Nastpnie omówimy model wtków
Linuksa, w którym linia pomidzy wtkami i procesami jest rozmyta.
Jednym ze sposobów patrzenia na proces jest postrzeganie go jako sposobu gru-
powania powizanych ze sob zasobów. Proces dysponuje przestrzeni adresow
zawierajc tekst programu i dane, a take inne zasoby. Do zasobów tych mona
zaliczy otwarte pliki, procesy-dzieci, nieobsuone alarmy, porcedury obsugi sygna-
ów, informacje rozliczeniowe i wiele innych. Dziki pogrupowaniu ich w formie
procesu mona nimi atwiej zarzdza.
W innym pojciu proces zawiera wykonywany wtek — zwykle w skrócie uywa
si samego pojcia wtku. Wtek zawiera licznik programu, który ledzi to, jaka
instrukcja bdzie wykonywana w nastpnej kolejnoci. Posiada rejestry zawierajce
jego biece robocze zmienne. Ma do dyspozycji stos zawierajcy histori dziaania —
po jednej ramce dla kadej procedury, której wykonywanie si rozpoczo, ale jeszcze
si nie zakoczyo. Chocia wtek musi realizowa jaki proces, wtek i jego pro-
ces s pojciami odrbnymi i mona je traktowa osobno. Procesy s wykorzysty-
wane do grupowania zasobów, wtki s podmiotami zaplanowanymi do wykonania
przez procesor.
Wtki dodaj do modelu procesu moliwo realizacji wielu wykona w tym
samym rodowisku procesu, w duym stopniu w sposób wzajemnie od siebie nie-
zaleny. Równolege dziaanie wielu wtków w obrbie jednego procesu jest analo-
giczne do równolegego dziaania wielu procesów w jednym komputerze. W pierw-
szym z tych przypadków wtki wspódziel przestrze adresow i inne zasoby.
144
PROCESY I WTKI
ROZ. 2
W drugim przypadku procesy wspódziel pami fizyczn, dyski, drukarki i inne
zasoby. Poniewa wtki maj pewne waciwoci procesów, czasami nazywa si je
lekkimi procesami. Do opisania sytuacji, w której w tym samym procesie moe
dziaa wiele wtków, uywa si take terminu wielowtkowo. Jak widzielimy
w rozdziale 1., niektóre procesory maj bezporedni obsug sprztow wielowt-
kowoci i pozwalaj na przeczanie wtków w skali czasowej rzdu nanosekund.
Na rysunku 2.7(a) wida trzy tradycyjne procesy. Kady proces ma swoj wasn
przestrze adresow oraz pojedynczy wtek sterowania. Dla odmiany w ukadzie
z rysunku 2.7(b) widzimy jeden proces z trzema wtkami sterowania. Chocia w obu
przypadkach mamy trzy wtki, w sytuacji z rysunku 2.7(a) kady z nich dziaa w innej
przestrzeni adresowej, podczas gdy w sytuacji z rysunku 2.7(b) wszystkie wspó-
dziel t sam przestrze adresow.
Rysunek 2.7. (a) Trzy procesy, z których kady posiada jeden wtek; (b) jeden wtek
z trzema wtkami
Kiedy wielowtkowy proces dziaa w jednoprocesorowym systemie, wtki dzia-
aj po kolei. Na rysunku 2.1 widzielimy, jak dziaa wieloprogramowo procesów.
Dziki przeczaniu pomidzy wieloma procesami system daje iluzj oddzielnych
procesów sekwencyjnych dziaajcych wspóbienie. Wielowtkowo dziaa w taki
sam sposób. Procesor przecza si w szybkim tempie pomidzy wtkami, dajc iluzj,
e wtki dziaaj wspóbienie — chocia na wolniejszym procesorze od fizycznego.
Przy trzech wtkach obliczeniowych w procesie wtki bd sprawiay wraenie rów-
nolegego dziaania, ale tak, jakby kady z nich dziaa na procesorze o szybkoci
równej jednej trzeciej szybkoci fizycznego procesora.
Róne wtki procesu nie s tak niezalene, jak róne procesy. Wszystkie wtki
posuguj si dokadnie t sam przestrzeni adresow, co równie oznacza, e wspó-
dziel one te same zmienne globalne. Poniewa kady wtek moe uzyska dostp
do kadego adresu pamici w obrbie przestrzeni adresowej procesu, jeden wtek
moe odczyta, zapisa, a nawet wyczyci stos innego wtku. Pomidzy wtkami
nie ma zabezpiecze, poniewa (1) byyby one niemoliwe do realizacji, a (2) nie
powinny by potrzebne. W odrónieniu od rónych procesów, które potencjalnie
PODROZ. 2.2
WTKI
145
nale do rónych uytkowników i które mog by dla siebie wrogie, proces zawsze
naley do jednego uytkownika, który przypuszczalnie utworzy wiele wtków,
a zatem powinny one wspópracowa, a nie walczy ze sob. Oprócz przestrzeni adre-
sowej wszystkie wtki mog wspódzieli ten sam zbiór otwartych plików, proce-
sów-dzieci, alarmów, sygnaów itp., tak jak pokazano w tabeli 2.4. Tak wic organi-
zacja pokazana na rysunku 2.7(a) mogaby zosta uyta, jeli trzy procesy s ze sob
niezwizane, natomiast organizacja z rysunku 2.7(b) byaby waciwa w przypadku,
gdyby trzy wtki byy czci tego samego zadania i gdyby aktywnie i cile ze sob
wspópracoway.
Tabela 2.4. W pierwszej kolumnie wyszczególniono cechy wspólne dla wszystkich
wtków w procesie. W drugiej kolumnie zamieszczono niektóre elementy prywatne
dla kadego wtku
Komponenty procesu
Komponenty wtku
Przestrze adresowa
Licznik programu
Zmienne globalne
Rejestry
Otwarte pliki
Stos
Procesy-dzieci
Stan
Zalege alarmy
Sygnay i procedury obsugi sygnaów
Informacje dotyczce rozlicze
Elementy w pierwszej kolumnie s waciwociami procesu, a nie wtku. Jeli
na przykad jeden wtek otworzy plik, bdzie on widoczny dla innych wtków w pro-
cesie. Wtki te bd mogy czyta dane z pliku i je zapisywa. To logiczne, ponie-
wa wanie proces, a nie wtek jest jednostk zarzdzania zasobami. Gdyby kady
wtek mia wasn przestrze adresow, otwarte pliki, nieobsuone alarmy itd.,
byby osobnym procesem. Wykorzystujc pojcie wtków, chcemy, aby wiele wtków
mogo wspódzieli zbiór zasobów. Dziki temu mog one ze sob cile wspópra-
cowa w celu wykonania okrelonego zadania.
Podobnie jak tradycyjny proces (czyli taki, który zawiera tylko jeden wtek), wtek
moe znajdowa si w jednym z kilku stanów: „dziaajcy”, „zablokowany”, „gotowy”
lub „zakoczony”. Dziaajcy wtek posiada dostp do procesora i jest aktywny.
Zablokowany wtek oczekuje na jakie zdarzenie, by móg si odblokowa. Kiedy
na przykad wtek realizuje wywoanie systemowe odczytujce dane z klawiatury,
jest zablokowany do czasu, kiedy uytkownik wpisze dane wejciowe. Wtek moe si
blokowa w oczekiwaniu na wystpienie zdarzenia zewntrznego lub moe ocze-
kiwa, a odblokuje go inny wtek. Wtek gotowy jest zaplanowany do uruchomienia
i zostanie uruchomiony, kiedy nadejdzie jego kolej. Przejcia pomidzy stanami wt-
ków s identyczne jak przejcia pomidzy stanami procesów. Zilustrowano je na
rysunku 2.2.
146
PROCESY I WTKI
ROZ. 2
Istotne znaczenie ma zdanie sobie sprawy, e kady wtek posiada wasny stos,
co zilustrowano na rysunku 2.8. Stos kadego wtku zawiera po jednej ramce dla
kadej procedury, która zostaa wywoana, a z której jeszcze nie nastpi powrót.
Ramka ta zawiera zmienne lokalne procedury oraz adres powrotu, który bdzie
wykorzystany po zakoczeniu obsugi wywoania procedury. Jeli na przykad proce-
dura X wywoa procedur Y, a procedura Y wywoa procedur Z, to w czasie, kiedy
dziaa procedura Z, na stosie bd ramki dla procedur X, Y i Z. Kady wtek, ogólnie
rzecz biorc, bdzie wywoywa inne procedury, a zatem bdzie mia inn histori
wywoa. Dlatego wanie kady wtek potrzebuje wasnego stosu.
Rysunek 2.8. Kady wtek ma wasny stos
W przypadku gdy system obsuguje wielowtkowo, procesy zazwyczaj rozpo-
czynaj dziaanie z jednym wtkiem. Wtek ten posiada zdolno do tworzenia nowych
wtków za pomoc wywoania procedury, na przykad
thread_create
. Parametr
procedury
thread_create
zwykle okrela nazw procedury, która ma si uruchomi
dla nowego wtku. Nie jest konieczne (ani nawet moliwe) ustalenie czegokolwiek
na temat przestrzeni adresowej nowego wtku, poniewa wtek automatycznie dziaa
w przestrzeni adresowej wtku tworzcego. Czasami wtki s hierarchiczne i zacho-
dz pomidzy nimi relacje rodzic – dziecko, czsto jednak takie relacje nie wystpuj,
a wszystkie wtki s sobie równe. Niezalenie od tego, czy pomidzy wtkami
zachodzi relacja hierarchii, wtek tworzcy zwykle zwraca identyfikator wtku zawie-
rajcy nazw nowego wtku.
Kiedy wtek zakoczy swoj prac, moe zakoczy dziaanie poprzez wywoanie
procedury bibliotecznej, na przykad
thread_exit
. W tym momencie wtek znika
i nie moe by wicej zarzdzany. W niektórych systemach obsugi wtków jeden
wtek moe czeka na zakoczenie innego wtku poprzez wywoanie procedury, na
przykad
thread_join
. Procedura ta blokuje wtek wywoujcy do czasu zakoczenia
(specyficznego) wtku. Pod tym wzgldem tworzenie i koczenie wtków przypo-
mina tworzenie i koczenie procesów i wymaga w przyblieniu tych samych opcji.
PODROZ. 2.2
WTKI
147
Innym popularnym wywoaniem dotyczcym wtków jest
thread_yield
. Umo-
liwia ono wtkowi dobrowoln rezygnacj z procesora w celu umoliwienia dziaa-
nia innemu wtkowi. Takie wywoanie ma istotne znaczenie, poniewa nie istnieje
przerwanie zegara, które wymuszaoby wieloprogramowo, tak jak w przypadku
procesów. W zwizku z tym istotne znaczenie ma to, aby wtki byy „uprzejme” i od
czasu do czasu dobrowolnie rezygnoway z procesora, tak by inne wtki miay szanse
na dziaanie. S równie inne wywoania — na przykad pozwalajce na to, aby jeden
wtek poczeka, a nastpny zakoczy jak prac, lub by ogosi, e wanie zako-
czy jak prac itd.
Chocia wtki czsto si przydaj, wprowadzaj take szereg komplikacji do
modelu programowania. Na pocztek przeanalizujmy efekty na uniksowe wywoa-
nie systemowej
fork
. Jeli proces-rodzic ma wiele wtków, to czy proces-dziecko
równie powinien je mie? Jeli nie, to proces moe nie dziaa prawidowo, ponie-
wa wszystkie wtki mog mie istotne znaczenie.
Tymczasem gdy proces-dziecko otrzyma tyle samo wtków, co rodzic, to co si
stanie, jeli wtek nalecy do rodzica zostanie zablokowany przez wywoanie
read
,
powiedzmy, z klawiatury? Czy teraz dwa wtki s zablokowane przez klawiatur —
jeden w procesie-rodzicu i drugi w dziecku? Kiedy uytkownik wpisze wiersz, to czy
kopia pojawi si w obu wtkach? A moe tylko w wtku rodzica? Lub tylko w wtku
dziecka? Ten sam problem wystpuje dla twardych pocze sieciowych.
Inna klasa problemów wie si z faktem wspódzielenia przez wtki wielu struktur
danych. Co si dzieje, jeli jeden wtek zamknie plik, podczas gdy inny cigle z niego
czyta? Przypumy, e jeden z wtków zauwaa, e jest za mao pamici, i rozpoczyna
alokowanie wikszej iloci pamici. W trakcie tego dziaania nastpuje przeczenie
wtku. Nowy wtek równie zauwaa, e jest za mao pamici i take rozpoczyna
alokowanie dodatkowej pamici. Pami prawdopodobnie bdzie alokowana dwu-
krotnie. Przy odrobinie wysiku mona rozwiza te problemy, jednak poprawna
praca programów wykorzystujcych wielowtkowo wymaga dokadnych przemy-
le i dokadnego projektowania.
2.2.3. Wtki POSIX
Aby byo moliwe napisanie przenonego programu z obsug wielu wtków, organi-
zacja IEEE zdefiniowaa standard 1003.1c. Pakiet obsugi wtków, który tam zdefi-
niowano, nosi nazw
Pthreads
. Jest on obsugiwany przez wikszo systemów
uniksowych. W standardzie zdefiniowano ponad 60 wywoa funkcji. To o wiele za
duo, by mona je byo dokadnie omówi w tej ksice. Omówimy zatem kilka naj-
waniejszych. Dziki temu Czytelnik uzyska obraz ich dziaania. Wywoania, które
opiszemy, zostay wyszczególnione w tabeli 2.5.
148
PROCESY I WTKI
ROZ. 2
Tabela 2.5. Niektóre wywoania funkcji nalece do pakietu Pthreads
Wywoanie obsugi wtku
Opis
Pthread_create
Utworzenie nowego wtku
Pthread_exit
Zakoczenie wtku wywoujcego
Pthread_join
Oczekiwanie na zakoczenie specyficznego wtku
Pthread_yield
Zwolnienie procesora w celu umoliwienia dziaania innemu
wtkowi
Pthread_attr_init
Utworzenie i zainicjowanie struktury atrybutów wtku
Pthread_attr_destroy
Usunicie struktury atrybutów wtku
Wszystkie wtki pakietu
Pthreads
maj okrelone waciwoci. Kady z nich
posiada identyfikator, zbiór rejestrów (cznie z licznikiem programu) oraz zbiór
atrybutów zapisanych w pewnej strukturze. Do atrybutów tych naley rozmiar stosu,
parametry szeregowania oraz inne elementy potrzebne do korzystania z wtku.
Nowy wtek tworzy si za pomoc wywoania
pthread_create
. Jako warto
funkcji zwracany jest identyfikator nowo utworzonego wtku. Wywoanie to nieprzy-
padkowo przypomina wywoanie systemowe
fork
. W tym przypadku identyfikator
wtku spenia rol identyfikatora PID, gównie do celów identyfikacji wtków w innych
wywoaniach.
Kiedy wtek zakoczy prac, która zostaa do niego przydzielona, moe zakoczy
swoje dziaanie poprzez wywoanie funkcji
pthread_exit
. Wywoanie to zatrzymuje
wtek i zwalnia jego stos.
Czsto wtek musi czeka, a inny wtek zakoczy swoj prac. Dopiero pó-
niej moe kontynuowa dziaanie. Wtek oczekujcy na zakoczenie specyficznego
innego wtku wywouje funkcj
pthread_join
. Identyfikator wtku, który ma si
zakoczy, jest przekazywany jako parametr.
Czasami si zdarza, e wtek nie jest logicznie zablokowany, ale czuje, e dziaa
ju do dugo, i chce da innemu wtkowi szans dziaania. Cel ten mona osign
za pomoc wywoania
pthread_yield
. Nie ma takiego wywoania w przypadku pro-
cesów, poniewa zakada si, e procesy ze sob rywalizuj i kady z nich chce uzyska
maksymalnie duo czasu procesora. Poniewa jednak wtki procesu wspódziaaj
ze sob, a ich kod jest pisany przez tego samego programist, czasami programista
chce, aby kady z wtków otrzyma swoj szans.
Nastpne dwa wywoania obsugi wtków dotycz atrybutów wtku. Wywoanie
Pthread_attr_init
tworzy struktur atrybutów powizan z wtkiem i inicjuje j
do wartoci domylnych. Wartoci te (takie jak priorytet) mona zmienia poprzez
modyfikowanie pól w strukturze atrybutów.
Na koniec — wywoanie
pthread_attr_destroy
usuwa struktur atrybutów wtku
i zwalnia pami. Wywoanie to nie ma wpywu na wtki korzystajce z atrybutów.
Wtki te w dalszym cigu istniej.
PODROZ. 2.2
WTKI
149
Aby uzyska lepszy obraz tego, jak dziaa pakiet
Pthreads
, rozwamy prosty przy-
kad z listingu 2.2. Gówny program wykonuje si w ptli
NUMBER_OF_THREADS
razy.
W kadej iteracji program wywietla komunikat i tworzy nowy wtek. Jeli two-
rzenie wtku nie powiedzie si, program wywietla komunikat o bdzie i koczy
dziaanie. Po utworzeniu wszystkich wtków program gówny koczy dziaanie.
Listing 2.2. Przykadowy program wykorzystujcy wtki
#include <pthread.h>
#include <stdio.h>
#include <stdlib.h>
#define NUMBER_OF_THREADS 10
void *print-hello_world(void *tid)
{
/*
Funkcja wywietla identyfikator wtku i koczy dziaanie. */
printf("Witaj, wiecie. Pozdrowienia od wtku %d0, tid);
pthread_exit(NULL);
}
int main(int argc, char *argv[])
{
/*
Program gówny tworzy 10 wtków i koczy dziaanie. */
pthread_t threads[NUMBER_OF_THREADS];
int status, i;
for(i=0; i < NUMBER_OF_THREADS; i++) {
printf("Tu program gówny. Tworzenie wtku %d0, i);
status = pthread_create(&threads[i], NULL, print_hello_world,
´(void *)i);
if (status != 0) {
printf("Oops. Funkcja pthread_create zwrócia kod bdu %d0, status);
exit(-1);
}
}
exit(NULL);
}
Podczas tworzenia wtek wywietla jednowierszowy komunikat, w którym si
przedstawia, a nastpnie koczy dziaanie. Kolejno, w jakiej bd si pojawiay
poszczególne komunikaty, nie jest okrelona i moe by róna w kolejnych urucho-
mieniach programu.
Pakiet
Pthreads
w adnym razie nie ogranicza si do funkcji opisanych powyej.
Jest ich znacznie wicej. Niektóre z kolejnych wywoa opiszemy póniej, po omó-
wieniu zagadnienia synchronizacji procesów i wtków.
150
PROCESY I WTKI
ROZ. 2
2.2.4. Implementacja wtków w przestrzeni uytkownika
Istniej dwa gówne sposoby implementacji pakietu obsugi wtków: w przestrzeni
uytkownika i w jdrze. Podzia ten jest do pynny. Moliwe s równie implemen-
tacje hybrydowe. Poniej opiszemy obie metody razem z ich zaletami i wadami.
Pierwsza metoda polega na umieszczeniu pakietu wtków w caoci w przestrzeni
uytkownika. Jdro nic o nich nie wie. Z jego punktu widzenia procesy, którymi zarz-
dza, s standardowe — jednowtkowe. Pierwsza i najbardziej oczywista zaleta tego
rozwizania polega na tym, e pakiet obsugi wtków na poziomie przestrzeni uyt-
kownika mona zaimplementowa w systemie operacyjnym, który nie obsuguje
wtków. Do tej kategorii w przeszoci naleay wszystkie systemy operacyjne
i nawet dzi niektóre do niej nale. Przy takim podejciu wtki s implementowane
za pomoc biblioteki.
Wszystkie tego rodzaju implementacje maj tak sam ogóln struktur, co zilu-
strowano na rysunku 2.9(a). Wtki dziaaj na bazie rodowiska wykonawczego —
kolekcji procedur, które nimi zarzdzaj. Do tej pory zapoznalimy si z czterema pro-
cedurami z tej grupy:
pthread_create
,
pthread_exit
,
pthread_join
oraz
pthread_
´yield
. Zwykle jednak jest ich wicej.
Rysunek 2.9. (a) Pakiet obsugi wtków na poziomie uytkownika; (b) pakiet obsugi
wtków zarzdzany przez jdro
Jeli wtki s zarzdzane w przestrzeni uytkownika, kady proces potrzebuje
swojej prywatnej tabeli wtków, która ma na celu ledzenie wtków w tym pro-
cesie. Tabela ta jest analogiczna do tabeli procesów w jdrze. Rónica polega na
tym, e ledzi ona waciwoci tylko na poziomie wtku — na przykad licznik pro-
gramu kadego z wtków, wskanik stosu, rejestry, stan itp. Tabela wtków jest
zarzdzana przez rodowisko wykonawcze. Kiedy wtek przechodzi do stanu goto-
woci lub zablokowania, informacje potrzebne do jego wznowienia s zapisywane
w tabeli wtków, dokadnie w taki sam sposób, w jaki jdro zapisuje informacje o pro-
cesach w tabeli procesów.
PODROZ. 2.2
WTKI
151
Kiedy wtek wykona operacj, która moe spowodowa jego lokalne zabloko-
wanie, na przykad oczekuje, a inny wtek w tym samym procesie wykona jak
prac, wykonuje procedur ze rodowiska wykonawczego. Procedura ta sprawdza,
czy wtek musi by przeczony do stanu zablokowania. Jeli tak, to zapisuje rejestry
wtku (tzn. wasne) w tabeli wtków, szuka w tabeli wtku gotowego do dziaania
i aduje rejestry maszyny zapisanymi wartociami odpowiadajcymi nowemu wt-
kowi. Po przeczeniu wskanika stosu i licznika programu nowy wtek automatycznie
powraca do ycia. Jeli maszyna posiada instrukcj zapisujc wszystkie rejestry
oraz inn instrukcj, która je wszystkie aduje, przeczenie wtku mona przepro-
wadzi za pomoc zaledwie kilku instrukcji. Przeprowadzenie przeczania wtków
w taki sposób jest co najmniej o jeden rzd wielkoci szybsze od wykonywania roz-
kazu puapki do jdra. To silny argument przemawiajcy za implementacj pakietu
zarzdzania wtkami na poziomie przestrzeni uytkownika.
Jest jednak jedna zasadnicza rónica w porównaniu z procesami. Kiedy wtek
zakoczy na chwil dziaanie, na przykad kiedy wywoa funkcj
thread_yield
, kod
funkcji
thread_yield
moe zapisa informacje dotyczce wtku w samej tabeli wt-
ków. Co wicej, moe on nastpnie wywoa zarzdc wtków w celu wybrania innego
wtku do uruchomienia. Procedura zapisujca stan wtku oraz program szeregujcy
s po prostu lokalnymi procedurami, zatem wywoanie ich jest znacznie bardziej
wydajne od wykonania wywoania jdra. Midzy innymi nie jest potrzebny rozkaz
puapki, nie trzeba przecza kontekstu, nie trzeba oprónia pamici podrcznej.
W zwizku z tym zarzdzanie wtkami odbywa si bardzo szybko.
Implementacja wtków na poziomie przestrzeni uytkownika ma take inne
zalety. Dziki temu kademu procesowi mona przypisa wasny, spersonalizowany
algorytm szeregowania. W przypadku niektórych aplikacji, na przykad zawierajcych
wtek mechanizmu odmiecania, brak koniecznoci przejmowania si moliwoci
zatrzymania si wtku w nieodpowiednim momencie jest zalet. Takie rozwizanie
okazuje si równie atwiejsze do skalowania, poniewa wtki zarzdzane na pozio-
mie jdra niewtpliwie wymagaj przestrzeni na tabel i stos w jdrze, a to, w przy-
padku duej liczby wtków, moe by problemem.
Pomimo lepszej wydajnoci implementacja wtków na poziomie przestrzeni uyt-
kownika ma równie istotne wady. Pierwsza z nich dotyczy sposobu implementacji
blokujcych wywoa systemowych. Przypumy, e wtek czyta z klawiatury, zanim
zostanie wcinity jakikolwiek klawisz. Zezwolenie wtkowi na wykonanie wywoania
systemowego jest niedopuszczalne, poniewa spowoduje to zatrzymanie wszyst-
kich wtków. Trzeba pamita, e jednym z podstawowych celów korzystania z wt-
ków jest umoliwienie wszystkim wtkom uywania wywoa blokujcych, a przy
tym niedopuszczenie do tego, by zablokowany wtek mia wpyw na inne. W przy-
padku blokujcych wywoa systemowych trudno znale atwe rozwizanie pozwa-
lajce na spenienie tego celu.
Wszystkie wywoania systemowe mona zmieni na nieblokujce (na przykad
odczyt z klawiatury zwróciby 0 bajtów, gdyby znaki nie byy wczeniej zbuforowane),
152
PROCESY I WTKI
ROZ. 2
ale wymaganie zmian w systemie operacyjnym jest nieatrakcyjne. Poza tym jednym
z argumentów przemawiajcych za obsug wtków na poziomie uytkownika bya
moliwo wykorzystania takiego mechanizmu w istniejcych systemach operacyj-
nych. Co wicej, zmiana semantyki wywoania
read
wymagaaby modyfikacji wielu
programów uytkowych.
Jedn z moliwych alternatyw mona zastosowa w przypadku, gdy mona z góry
powiedzie, czy wywoanie jest blokujce. W niektórych wersjach Uniksa istnieje
wywoanie systemowe
select
, które pozwala procesowi wywoujcemu na spraw-
dzenie, czy wywoanie
read
bdzie blokujce. Jeli jest dostpne to wywoanie,
mona zastpi procedur biblioteczn
read
now wersj, która najpierw wykonuje
wywoanie
select
, a nastpnie wywouje
read
tylko wtedy, gdy jest to bezpieczne
(tzn. nie spowoduje zablokowania). Jeeli wywoanie
read
ma doprowadzi do zablo-
kowania, nie jest wykonywane. Zamiast wywoania
read
uruchamiany jest inny wtek.
Nastpnym razem, kiedy rodowisko wykonawcze otrzyma sterowanie, moe spraw-
dzi ponownie, czy wykonanie wywoania
read
jest bezpieczne. Takie podejcie
wymaga zmiany implementacji czci biblioteki wywoa systemowych, jest niewy-
dajne i nieeleganckie, ale moliwoci wyboru s ograniczone. Kod wokó wywoania
systemowego, który wykonuje test, okrela si oson lub opakowaniem (ang.
wrapper).
W pewnym sensie podobnym problemem do blokujcych wywoa systemowych
jest problem braku stron w pamici (ang. page faults). Zagadnienie to omówimy
w rozdziale 3. Na razie wystarczy, jeli powiemy, e komputery mona skonfiguro-
wa w taki sposób, aby w danym momencie w gównej pamici znajdowaa si tylko
cz programu. Jeeli program wywoa lub skoczy do instrukcji, której nie ma
w pamici, wystpuje warunek braku strony. Wtedy system operacyjny jest zmuszony
do pobrania brakujcej instrukcji (wraz z jej ssiadami) z dysku. Na tym wanie
polega warunek braku strony. Podczas gdy potrzebna instrukcja jest wyszukiwana
i wczytywana, proces pozostaje zablokowany. Jeli wtek spowoduje warunek braku
strony, jdro, które nawet nie wie o istnieniu wtków, blokuje cay proces do czasu
zakoczenia dyskowej operacji wejcia-wyjcia. Robi to, mimo e nie ma przeszkód,
by inne wtki dziaay.
Inny problem z pakietami obsugi wtków na poziomie uytkownika polega na
tym, e jeli wtek zacznie dziaa, to aden inny wtek w tym procesie nigdy nie
zacznie dziaa, o ile pierwszy wtek dobrowolnie nie zrezygnuje z procesora.
W obrbie pojedynczego procesu nie ma przerwa zegara, dlatego nie ma moliwoci
szeregowania procesów w trybie cyklicznym (tzn. po kolei). Jeli wtek z wasnej
woli nie przekae sterowania do rodowiska wykonawczego, program szeregujcy
nigdy nie bdzie mia szansy dziaania.
Jednym z moliwych rozwiza problemu wtków dziaajcych bez przerwy jest
zlecenie rodowisku wykonawczemu dania sygnau zegara (przerwania) co sekund
w celu przekazania mu kontroli. Takie rozwizanie okazuje si jednak toporne i trudne
do zaprogramowania. Okresowe przerwania zegara z wysz czstotliwoci nie
PODROZ. 2.2
WTKI
153
zawsze s moliwe, a nawet jeli tak jest, koszt obliczeniowy takiej operacji moe
by wysoki. Co wicej, wtek równie moe potrzebowa przerwania zegara, co prze-
szkadza wykorzystaniu zegara przez rodowisko wykonawcze.
Innym, rzeczywicie druzgoczcym argumentem przeciwko wtkom zarzdza-
nym na poziomie przestrzeni uytkownika jest fakt, e programici, ogólnie rzecz
biorc, potrzebuj wtków w aplikacjach, gdzie wtki blokuj si czsto — na przy-
kad w wielowtkowym serwerze WWW. Wtki te bezustannie wykonuj wywoa-
nia systemowe. Kiedy zostanie wykonany rozkaz puapki do jdra w celu realizacji
wywoania systemowego, jdro nie ma nic wicej do roboty przy przeczaniu wtków,
w przypadku gdy stary wtek si zablokowa, a zlecenie jdru wykonania tej czyn-
noci eliminuje potrzeb cigego wykonywania wywoa systemowych
select
spraw-
dzajcych, czy wywoania systemowe
read
s bezpieczne. Jaki jest sens istnienia
wtków w aplikacjach cakowicie powizanych z procesorem, które rzadko si blokuj?
Nikt nie jest w stanie zaproponowa sensownego rozwizania problemu wyliczania
liczb pierwszych lub grania w szachy z wykorzystaniem wtków, poniewa realizacja
tych programów w ten sposób nie przynosi istotnych korzyci.
2.2.5. Implementacja wtków w jdrze
Rozwamy teraz sytuacj, w której jdro wie o istnieniu wtków i to ono nimi zarzdza.
rodowisko wykonawcze w kadym z procesów nie jest wymagane, co pokazano na
rysunku 2.9(b). Tabela wtków równie nie wystpuje w kadym procesie. Zamiast
tego jdro dysponuje tabel wtków, która ledzi wszystkie wtki w systemie. Kiedy
wtek chce utworzy nowy wtek lub zniszczy istniejcy, wykonuje wywoanie
systemowe, które nastpnie realizuje utworzenie lub zniszczenie wtku poprzez aktu-
alizacj tabeli wtków na poziomie jdra.
W tabeli wtków w jdrze s zapisane rejestry, stan oraz inne informacje dla
kadego wtku. Informacje s takie same, jak w przypadku wtków zarzdzanych na
poziomie uytkownika, z t rónic, e s one umieszczone w jdrze, a nie w prze-
strzeni uytkownika (wewntrz rodowiska wykonawczego). Informacje te stanowi
podzbiór informacji tradycyjnie utrzymywanych przez jdro na temat jednowtkowych
procesów — czyli stanu procesów. Oprócz tego jdro utrzymuje równie tradycyjn
tabel procesów, która suy do ledzenia procesów.
Wszystkie wywoania, które mog zablokowa wtek, s implementowane jako
wywoania systemowe znaczco wikszym kosztem ni wywoanie procedury ro-
dowiska wykonawczego. Kiedy wtek si zablokuje, jdro moe uruchomi wtek
z tego samego procesu (jeli jaki jest gotowy) lub wtek z innego procesu. W przy-
padku wtków zarzdzanych na poziomie przestrzeni uytkownika rodowisko wyko-
nawcze uruchamia wtki z wasnego procesu do czasu, a jdro zabierze mu proce-
sor (lub nie bdzie wtków gotowych do dziaania).
Ze wzgldu na relatywnie wikszy koszt tworzenia i niszczenia wtków na poziomie
jdra niektóre systemy przyjmuj rozwizanie „ekologiczne” i ponownie wykorzystuj
154
PROCESY I WTKI
ROZ. 2
swoje wtki. W momencie niszczenia wtku jest on oznaczany jako niemoliwy do
uruchomienia, ale poza tym struktury danych jdra pozostaj bez zmian. Kiedy
póniej trzeba utworzy nowy wtek, stary wtek jest reaktywowany, co eliminuje
konieczno wykonywania pewnych oblicze. Recykling wtków jest równie mo-
liwy w przypadku wtków zarzdzanych w przestrzeni uytkownika, ale poniewa
koszty zarzdzania wtkami s znacznie nisze, motywacja do korzystania z tego
mechanizmu jest mniejsza.
Wtki jdra nie wymagaj adnych nowych nieblokujcych wywoa systemo-
wych. Co wicej, jeli jeden z wtków w procesie spowoduje warunek braku strony,
jdro moe atwo sprawdzi, czy proces zawiera inne wtki moliwe do uruchomie-
nia. Jeli tak, uruchamia jeden z nich w oczekiwaniu na przesanie z dysku wymaganej
strony. Gówn wad tego rozwizania jest fakt, e koszty wywoania systemowego
s znaczce. W zwizku z tym, w przypadku duej liczby operacji zarzdzania wtkami
(tworzenia, niszczenia itp.), ponoszone koszty obliczeniowe okazuj si wysokie.
O ile wykorzystanie zarzdzania wtkami na poziomie jdra rozwizuje niektóre
problemy, o tyle nie rozwizuje ich wszystkich. Na przykad co si stanie, jeli wie-
lowtkowy proces wykona wywoanie
fork
? Czy nowy proces bdzie mia tyle
wtków, co stary, czy tylko jeden? W wielu przypadkach najlepszy wybór zaley od
tego, do czego bdzie suy nowy proces. Jeli zamierza skorzysta z wywoania
exec
w celu uruchomienia nowego programu, prawdopodobnie waciwe bdzie
stworzenie procesu z jednym wtkiem, jeli jednak ma on kontynuowa dziaanie,
reprodukcja wszystkich wtków wydaje si waciwsza.
Innym problemem s sygnay. Jak pamitamy, sygnay s przesyane do procesów,
a nie do wtków (przynajmniej w modelu klasycznym). Który wtek ma obsuy
nadchodzcy sygna? Mona wyobrazi sobie rozwizanie, w którym wtki rejestruj
swoje zainteresowanie okrelonymi sygnaami. Dziki temu w przypadku nadejcia
sygnau mógby on by skierowany do wtku, który na ten sygna oczekuje. Co si
jednak stanie, jeli dwa wtki (lub wiksza liczba wtków) zarejestruj zaintereso-
wanie tym samym sygnaem? To tylko dwa problemy, jakie stwarzaj wtki. Jest
ich jednak wicej.
2.2.6. Implementacje hybrydowe
Próbowano rónych rozwiza majcych na celu poczenie zalet zarzdzania wt-
kami na poziomie uytkownika oraz zarzdzania nimi na poziomie jdra. Jednym ze
sposobów jest uycie wtków na poziomie jdra, a nastpnie zwielokrotnienie nie-
których lub wszystkich wtków jdra na wtki na poziomie uytkownika. Sposób
ten pokazano na rysunku 2.10. W przypadku skorzystania z takiego podejcia progra-
mista moe okreli, ile wtków jdra chce wykorzysta oraz na ile wtków poziomu
uytkownika ma by zwielokrotniony kady z nich. Taki model daje najwiksz
elastyczno.
PODROZ. 2.2
WTKI
155
Rysunek 2.10. Zwielokrotnianie wtków uytkownika na bazie wtków jdra
Przy tym podejciu jdro jest wiadome istnienia wycznie wtków poziomu
jdra i tylko nimi zarzdza. Niektóre sporód tych wtków mog zawiera wiele
wtków poziomu uytkownika, stworzonych na bazie wtków jdra. Wtki poziomu
uytkownika s tworzone, niszczone i zarzdzane identycznie, jak wtki na poziomie
uytkownika dziaajce w systemie operacyjnym bez obsugi wielowtkowoci. W tym
modelu kady wtek poziomu jdra posiada pewien zbiór wtków na poziomie
uytkownika. Wtki poziomu uytkownika po kolei korzystaj z wtku poziomu jdra.
2.2.7. Mechanizm aktywacji zarzdcy
Chocia zarzdzanie wtkami na poziomie jdra jest lepsze od zarzdzania nimi na
poziomie uytkownika pod pewnymi istotnymi wzgldami, jest ono równie bezdy-
skusyjnie wolniejsze. W zwizku z tym poszukiwano sposobów poprawy tej sytuacji
bez koniecznoci rezygnacji z ich dobrych waciwoci. Poniej opiszemy jedno
z zaproponowanych rozwiza, opracowane przez zespó kierowany przez Andersona
[Anderson et al., 1992] i nazywane aktywacj zarzdcy (ang. scheduler activations).
Podobne prace zostay opisane w [Edlera et al., 1988] oraz [Scott et al., 1990].
Celem dziaania mechanizmu aktywacji zarzdcy jest naladowanie funkcji wt-
ków jdra, ale z zapewnieniem lepszej wydajnoci i elastycznoci — cech, które
zwykle charakteryzuj pakiety zarzdzania wtkami zaimplementowane w prze-
strzeni uytkownika. W szczególnoci wtki uytkownika nie powinny wykonywa
specjalnych, nieblokujcych wywoa systemowych lub sprawdza wczeniej, czy
wykonanie okrelonych wywoa systemowych jest bezpieczne. Niemniej jednak,
kiedy wtek zablokuje si na wywoaniu systemowym lub sytuacji braku strony,
powinien mie moliwo uruchomienia innego wtku w ramach tego samego pro-
cesu, jeli jaki jest gotowy do dziaania.
Wydajno osignito dziki unikniciu niepotrzebnych przej pomidzy prze-
strzeni uytkownika a przestrzeni jdra. Jeli na przykad wtek zablokuje
si w oczekiwaniu na to, a inny wtek wykona jakie dziaania, nie ma powodu
156
PROCESY I WTKI
ROZ. 2
informowania o tym jdra. Dziki temu unika si kosztów zwizanych z przejciami
pomidzy przestrzeniami jdra i uytkownika. rodowisko wykonawcze przestrzeni
uytkownika moe samodzielnie zablokowa wtek synchronizujcy i zainicjowa nowy.
Kiedy jest wykorzystywany mechanizm aktywacji zarzdcy, jdro przypisuje
okrelon liczb procesorów wirtualnych do kadego procesu i umoliwia rodowisku
wykonawczemu (przestrzeni uytkownika) na przydzielanie wtków do procesorów.
Mechanizm ten moe by równie wykorzystany w systemie wieloprocesorowym,
w którym zamiast procesorów wirtualnych s procesory fizyczne. Liczba procesorów
wirtualnych przydzielonych do procesu zazwyczaj pocztkowo wynosi jeden, ale
proces moe poprosi o wicej, a take zwróci procesory, których ju nie potrze-
buje. Jdro moe równie zwróci wirtualne procesory przydzielone wczeniej,
w celu przypisania ich procesom bardziej potrzebujcym.
Podstawowa zasada dziaania tego mechanizmu polega na tym, e jeli jdro dowie
si o blokadzie wtku (na przykad z powodu uruchomienia blokujcego wywoania
systemowego lub braku strony), to powiadamia o tym rodowisko wykonawcze pro-
cesu. W tym celu przekazuje na stos w postaci parametrów numer zablokowanego
wtku oraz opis zdarzenia, które wystpio. Powiadomienie moe by zrealizowane
dziki temu, e jdro uaktywnia rodowisko wykonawcze znajdujce si pod znanym
adresem pocztkowym. Jest to mechanizm w przyblieniu analogiczny do sygnaów
w Uniksie. Mechanizm ten okrela si terminem wezwanie (ang. upcall).
Po uaktywnieniu w taki sposób rodowisko wykonawcze moe zmieni harmono-
gram dziaania swoich wtków. Zazwyczaj odbywa si to poprzez oznaczenie biecego
wtku jako zablokowany oraz pobranie innego wtku z listy wtków bdcych w goto-
woci, ustawienie jego rejestrów i wznowienie dziaania. Póniej, kiedy jdro dowie
si, e poprzedni wtek moe ponownie dziaa (na przykad potok, z którego czyta
dane, zawiera dane lub brakujca strona zostaa pobrana z dysku), wykonuje kolejne
wezwanie do rodowiska wykonawczego w celu poinformowania go o tym zdarzeniu.
rodowisko wykonawcze moe wówczas we wasnej gestii natychmiast zrestartowa
zablokowany wtek lub umieci go na licie wtków do póniejszego uruchomienia.
Jeeli wystpi przerwanie sprztowe, gdy dziaa wtek uytkownika, procesor
przecza si do trybu jdra. Jeli przerwanie jest spowodowane przez zdarzenie,
którym przerwany proces nie jest zainteresowany — na przykad zakoczenie
operacji wejcia-wyjcia innego procesu — to kiedy procedura obsugi przerwania
zakoczy dziaanie, umieszcza przerwany wtek w tym samym stanie, w jakim znaj-
dowa si on przed wystpieniem przerwania. Jeli jednak proces jest zaintereso-
wany przerwaniem — na przykad nadejcie strony wymaganej przez jeden z wtków
procesu — przerwany proces nie jest wznawiany. Zamiast tego jest on zawieszany,
a na tym samym wirtualnym procesorze zaczyna dziaa rodowisko wykonawcze —
stan przerwanego wtku jest w tym momencie umieszczony na stosie. W tym
momencie rodowisko wykonawcze podejmuje decyzj o tym, jakiemu wtkowi przy-
dzieli dany procesor: przerwanemu, nowo przygotowanemu do dziaania czy jakie-
mu innemu.
PODROZ. 2.2
WTKI
157
Wad mechanizmu aktywacji zarzdcy jest cakowite poleganie na wezwaniach —
jest to pojcie, które narusza wewntrzn struktur kadego systemu warstwo-
wego. Zwykle warstwa n oferuje okrelone usugi, które moe wywoa warstwa
n+1, warstwa n nie moe jednak wywoywa procedur w warstwie n+1. Mechanizm
wezwa narusza t podstawow zasad.
2.2.8. Wtki pop-up
Wtki czsto si przydaj w systemach rozproszonych. Istotnym przykadem moe
by sposób postpowania z nadchodzcymi komunikatami — na przykad daniami
obsugi. Tradycyjne podejcie polega na tym, e na komunikat oczekuje proces lub
wtek zablokowany na wywoaniu systemowym
receive
. Kiedy nadejdzie komu-
nikat, wtek ten przyjmuje go, rozpakowuje, analizuje zawarto i przetwarza.
Moliwe jest jednak cakiem inne podejcie — po dotarciu komunikatu system
tworzy nowy wtek do jego obsugi. Taki wtek okrela si jako wtek pop-up.
Zilustrowano go na rysunku 2.11. Zasadnicza zaleta wtków pop-up polega na tym,
e poniewa s one zupenie nowe, nie maj adnej historii — rejestrów, stosu,
czegokolwiek, co musiaoby by odtworzone. Kady wtek rozpoczyna si jako
nowy i wszystkie s identyczne. Dziki temu takie wtki mona tworzy szybko.
Nowy wtek otrzymuje przychodzcy komunikat do przetworzenia. Dziki zasto-
sowaniu wtków pop-up opónienie pomidzy przybyciem komunikatu a rozpocz-
ciem jego przetwarzania jest bardzo niewielkie.
Rysunek 2.11. Tworzenie nowego wtku po przybyciu pakietu: (a) zanim nadejdzie
komunikat; (b) po nadejciu komunikatu
W przypadku wykorzystania wtków pop-up potrzebne jest pewne zaawansowane
planowanie. Na przykad w którym procesie dziaa wtek? Jeli system obsuguje wtki
158
PROCESY I WTKI
ROZ. 2
dziaajce w kontekcie jdra, to wtek moe tam dziaa (dlatego wanie nie poka-
zalimy jdra na rysunku 2.11). Umieszczenie wtku pop-up w przestrzeni jdra
zazwyczaj jest atwiejsze i szybsze ni umieszczenie go w przestrzeni uytkownika.
Ponadto wtek pop-up w przestrzeni jdra moe atwo uzyska dostp do wszystkich
tabel i urzdze wejcia-wyjcia jdra, co moe by potrzebne do przetwarzania prze-
rwa. Z drugiej strony dziaajcy bdnie wtek jdra moe zrobi wicej szkód ni
bdnie dziaajcy wtek przestrzeni uytkownika. Jeli na przykad dziaa zbyt dugo
i nie ma moliwoci jego wywaszczenia, wchodzce dane mog zosta utracone.
2.2.9. Przystosowywanie kodu jednowtkowego
do obsugi wielu wtków
Dla procesów jednowtkowych napisano wiele programów. Ich konwersja na posta
wielowtkow jest znacznie trudniejsza, ni mogoby si wydawa na pierwszy rzut
oka. Poniej zaprezentujemy kilka problemów, które mog wystpi podczas takiej
konwersji.
Na pocztek naley sobie uwiadomi, e wtek, tak jak proces, zwykle skada si
z wielu procedur. Mog one mie zmienne lokalne, zmienne globalne i parametry.
Zmienne lokalne i parametry nie powoduj adnych problemów, tymczasem zmienne,
które s globalne dla wtku, ale nie s globalne dla caego programu, sprawiaj pro-
blem. S to zmienne, które s globalne w tym sensie, e uywa ich wiele procedur
w obrbie wtku (poniewa mog one wykorzystywa dowolne zmienne globalne),
ale inne wtki nie powinny z nich korzysta.
Dla przykadu przeanalizujmy zmienn
errno
wystpujc w systemie UNIX:
kiedy proces (lub wtek) wykonuje wywoanie systemowe, które koczy si nie-
powodzeniem, do zmiennej
errno
jest zapisywany kod bdu. Na rysunku 2.12
wtek nr 1 wykonuje wywoanie systemowe
access
po to, aby si dowiedzie, czy ma
uprawnienia dostpu do okrelonego pliku. System operacyjny zwraca odpowied
w zmiennej globalnej
errno
. Po zwróceniu sterowania do wtku 1., ale jeszcze przed
przeczytaniem przez niego zmiennej
errno
, program szeregujcy zdecydowa, e
wtek nr 1 mia przydzielony procesor wystarczajco dugo i zdecydowa przeczy
go do wtku 2. Wtek 2. uruchomi wywoanie systemowe
open
, które si nie powio-
do. Spowodowao to nadpisanie zmiennej
errno
, a kod dostpu wtku 1. zosta utra-
cony na zawsze. Kiedy wtek 1. póniej si uruchomi, przeczyta nieprawidow warto
i bdzie dziaa nieprawidowo.
Moliwych jest wiele rozwiza tego problemu. Jedno z nich polega na cako-
witym wyczeniu zmiennych globalnych. Cho mogoby si wydawa, e jest to
rozwizanie idealne, koliduje ono z wikszoci istniejcych programów. Inne roz-
wizanie to przypisanie kademu wtkowi wasnych, prywatnych zmiennych glo-
balnych, tak jak pokazano na rysunku 2.13. W ten sposób kady wtek bdzie mia
wasn, prywatn kopi zmiennej
errno
i innych zmiennych globalnych, co pozwoli
na uniknicie konfliktów. Przyjcie tego rozwizania tworzy nowy poziom zasigu:
PODROZ. 2.2
WTKI
159
Rysunek 2.12. Konflikty pomidzy wtkami spowodowany uyciem zmiennej globalnej
Rysunek 2.13. Wtki mog mie prywatne zmienne globalne
zmienne widoczne dla wszystkich procedur wtku. Poziom ten wystpuje obok ist-
niejcych poziomów: zmienne widoczne tylko dla jednej procedury oraz zmienne
widoczne w kadym punkcie programu.
Dostp do prywatnych zmiennych globalnych jest jednak nieco utrudniony, ponie-
wa wikszo jzyków programowania zapewnia sposób wyraania zmiennych lokal-
nych i zmiennych globalnych, ale nie ma form porednich. Mona zaalokowa fragment
pamici na zmienne globalne i przekaza go do kadej procedury w wtku w postaci
dodatkowego parametru. Chocia nie jest to zbyt eleganckie rozwizanie, okazuje
si jednak skuteczne.
Alternatywnie mona stworzy nowe procedury biblioteczne do tworzenia, usta-
wiania i czytania tych zmiennych globalnych na poziomie wtku. Pierwsze wywoa-
nie moe mie nastpujc posta:
create_global("bufptr");
160
PROCESY I WTKI
ROZ. 2
Wywoanie to alokuje pami dla wskanika o nazwie
bufptr
na stercie lub w specjal-
nym obszarze pamici zarezerwowanym dla wywoujcego wtku. Niezalenie od tego,
gdzie jest zaalokowana pami, tylko wywoujcy wtek ma dostp do zmiennej glo-
balnej. Jeli inny wtek utworzy zmienn globaln o tej samej nazwie, otrzyma inn
lokalizacj w pamici — tak, która nie koliduje z istniejc.
Do dostpu do zmiennych globalnych potrzebne s dwa wywoania: jedno do ich
zapisywania i drugie do odczytu. Do zapisywania potrzebne jest wywoanie postaci:
set_global("bufptr", &buf);
Wywoanie to zapisuje warto wskanika w lokalizacji pamici utworzonej wcze-
niej przez wywoanie do procedury
create_global
. Wywoanie do przeczytania
zmiennej globalnej moe mie nastpujc posta:
bufptr = read_global("bufptr");
Zwraca ono adres zapisany w zmiennej globalnej. Dziki temu mona uzyska dostp
do jej danych.
Nastpny problem podczas przeksztacania programu jednowtkowego na wielo-
wtkowy polega na tym, e wiele procedur bibliotecznych nie pozwala na tak zwan
wielobieno. Oznacza to, e nie ma moliwoci wywoania innej procedury, jeli
poprzednie wywoanie si nie zakoczyo. Na przykad wysyanie wiadomoci w sieci
mona by z powodzeniem zaprogramowa w taki sposób, aby wiadomo bya two-
rzona w ustalonym buforze w obrbie biblioteki, a nastpnie by wykonywany rozkaz
puapki do jdra w celu jej wysania. Co si stanie, jeli jeden wtek utworzy swoj
wiadomo w buforze, a nastpnie przerwanie zegara wymusio przeczenie do dru-
giego wtku, który natychmiast nadpisze bufor wasn wiadomoci.
Podobnie procedury alokacji pamici, na przykad
malloc
w Uniksie, utrzymuj
kluczowe tabele dotyczce wykorzystania pamici — na przykad powizan list
dostpnych fragmentów pamici. Podczas gdy procedura
malloc
jest zajta aktu-
alizacj tych list, mog one czasowo by w niespójnym stanie — zawiera wska-
niki donikd. Jeli nastpi przeczenie wtku w chwili, gdy tabele bd niespójne
i nadejdzie nowe wywoanie z innego wtku, moe doj do uycia nieprawidowego
wskanika, co w efekcie moe doprowadzi do awarii programu. Skuteczne wyelimi-
nowanie wszystkich tych problemów oznacza konieczno przepisania od nowa caej
biblioteki. Wykonanie takiego przedsiwzicia nie jest proste.
Innym rozwizaniem jest wyposaenie kadej procedury w kod opakowujcy,
który ustawia bit do oznaczenia biblioteki tak, jakby bya uywana. Kada próba innego
wtku skorzystania z procedury bibliotecznej, podczas gdy poprzednie wywoanie
nie zostao zakoczone, jest blokowana. Chocia takie rozwizanie jest wykonalne,
w duym stopniu eliminuje ono moliwo wykorzystania wspóbienoci.
Inn opcj jest wykorzystanie sygnaów. Niektóre sygnay z logicznego punktu
widzenia s specyficzne dla wtku, a inne nie. Jeli na przykad wtek wykonuje
wywoanie
alarm
, logiczne jest, aby wynikowy sygna zosta przesany do wtku,
który wykona wywoanie. Jeli jednak wtki s zaimplementowane w caoci w prze-
PODROZ. 2.3
KOMUNIKACJA MIDZY PROCESAMI
161
strzeni uytkownika, jdro nie wie nawet o istnieniu wtków, a zatem trudno mu skie-
rowa sygna do waciwego wtku. Dodatkowe komplikacje wystpuj w przypadku,
gdy proces pozwala na wystpowanie tylko jednego nieobsuonego alarmu w danym
momencie, a kilka wtków niezalenie wykonuje wywoanie
alarm
.
Inne sygnay, na przykad przerwanie klawiatury, nie s specyficzne dla wtku.
Co powinno je przechwyci? Wyznaczony wtek? Wszystkie wtki? Nowo utworzony
wtek pop-up? Ponadto co si stanie, jeli jeden wtek zmieni procedury obsugi
sygnaów bez informowania pozostaych wtków? A co si wydarzy, kiedy jeden wtek
bdzie chcia przechwyci okrelony sygna (na przykad wcinicie przez uytkownika
kombinacji Ctrl+C), a inny wtek bdzie potrzebowa tego sygnau do zakoczenia
procesu? Taka sytuacja moe wystpi, jeli jeden wtek lub kilka wtków korzysta
ze standardowych procedur bibliotecznych, a inne s napisane przez uytkownika.
Jest oczywiste, e yczenia tych wtków koliduj ze sob. Ogólnie rzecz biorc,
sygnay s trudne do zarzdzania w rodowisku jednowtkowym. Przejcie do rodo-
wiska wielowtkowego w aden sposób nie uatwia zarzdzania nimi.
Ostatnim problemem zwizanym z wtkami jest zarzdzanie stosem. W wielu
systemach, w przypadku wystpienia przepenienia stosu, jdro automatycznie dostar-
cza takiemu procesowi wicej miejsca na stosie. Jeli proces ma wiele wtków, musi
równie mie wiele stosów. Jeli jdro nie posiada informacji o wszystkich tych
stosach, nie moe ich automatycznie rozszerza, gdy wyczerpie si na nich miejsce.
W rzeczywistoci jdro moe nawet nie wiedzie, e brak strony w pamici jest zwi-
zany z rozszerzeniem si stosu jakiego wtku.
Problemy te nie s oczywicie nie do rozwizania, ale pokazuj, e wprowadze-
nie wtków do istniejcego systemu bez znaczcej jego przebudowy nie zadziaa.
Trzeba co najmniej zmodyfikowa definicj semantyki wywoa systemowych oraz
biblioteki. Wszystkie te czynnoci trzeba dodatkowo wykona tak, aby zachowa
wsteczn zgodno z istniejcymi programami, przy zaoeniu, e wykorzystuj one
procesy zawierajce po jednym wtku. Wicej informacji na temat wtków mona
znale w nastpujcych pozycjach [Hauser et al., 1993] oraz [Marsh et al., 1991].
2.3. KOMUNIKACJA MIDZY PROCESAMI
2.3
KOMUNIKACJA MIDZY PROCESAMI
Procesy czsto musz si komunikowa z innymi procesami. Na przykad w przypadku
potoku w powoce wyjcie pierwszego procesu musi by przekazane do drugiego
procesu, i tak dalej, do niszych warstw. Tak wic wystpuje potrzeba komunikacji
midzy procesami. Najlepiej, gdyby miaa ona czyteln struktur i gdyby nie korzy-
stano w niej z przerwa. W poniszych punktach przyjrzymy si niektórym pro-
blemom zwizanym z komunikacj midzyprocesow (ang. InterProcess Communi-
cation — IPC).
Mówic w skrócie: wi si z tym trzy problemy. O pierwszym bya mowa ju
wczeniej: w jaki sposób jeden proces moe przekazywa informacje do innego?
Wyszukiwarka
Podobne podstrony:
Analiza sledcza i powlamaniowa Zaawansowane techniki prowadzenia analizy w systemie Windows 7 Wydani
Rafał Polak 12k2 lab8, Inżynieria Oprogramowania - Informatyka, Semestr III, Systemy Operacyjne, Spr
Rafał Polak 12k2 lab9, Inżynieria Oprogramowania - Informatyka, Semestr III, Systemy Operacyjne, Spr
PYTANIA WEJSCIOWKI, Materiały, III semestr, Systemy operacyjne- materiały, egzamin, SO egz, SO egz,
Rafał Polak 12k2 lab4a, Inżynieria Oprogramowania - Informatyka, Semestr III, Systemy Operacyjne, Sp
Egzamin lato 2k00-2, Materiały, III semestr, Systemy operacyjne- materiały, egzamin, so-egzamin, roz
Rafał Polak 12k2 lab4b, Inżynieria Oprogramowania - Informatyka, Semestr III, Systemy Operacyjne, Sp
SO, Materiały, III semestr, Systemy operacyjne- materiały, egzamin, egzamin SO, egzamin SO
Egzamin lato 2k00-1, Materiały, III semestr, Systemy operacyjne- materiały, egzamin, so-egzamin, roz
Rafał Polak 12k2 lab11, Inżynieria Oprogramowania - Informatyka, Semestr III, Systemy Operacyjne, Sp
więcej podobnych podstron