PROCESAMI
Spis treści tomu I
Rozdzia 3. Procesy 139
3.1. Koncepcja procesu 140
3.2. Planowanie procesów 146
3.3. Dzia ania na procesach 152
3.4. Komunikacja mi dzyprocesowa (IPC) 161
3.5. IPC w systemach z pami ci dzielon 163
3.6. IPC w systemach z przekazywaniem komunikatów 166
3.7. Przyk ady systemów IPC 171
3.8. Komunikacja w systemach klient-serwer 186
3.9. Podsumowanie 196 wiczenia 197
Dalsze lektury 200
Bibliogra a 200
Rozdzia 4. W tki i wspó bie no 201
4.1. Przegl d 202
4.2. Programowanie wielordzeniowe 205
4.3. Modele wielow tkowo ci 209
4.4. Biblioteki w tków 212
4.5. W tkowo niejawna 221
4.6. Problemy w tkowo ci 234
4.7. Przyk ady systemów operacyjnych 242
4.8. Podsumowanie 244 wiczenia 246
Dalsze lektury 248
Bibliogra a 248
Rozdzia 5. Planowanie przydzia u CPU (jednostki centralnej) 249
5.1. Poj cia podstawowe 250
5.2. Kryteria planowania 255
5.3. Algorytmy planowania 257
5.4. Planowanie w tków 271
5.5. Planowanie wieloprocesorowe 274
5.6. Planowanie CPU w czasie rzeczywistym 283
5.7. Przyk ady systemów operacyjnych 293
5.8. Ocena algorytmów 304
5.9. Podsumowanie 310
wiczenia 312
Dalsze lektury 315
Bibliogra a 315
CZ 3 SYNCHRONIZACJA PROCESÓW
Rozdzia 6. Narz dzia synchronizacji 319
6.1. Podstawy 319
6.2. Problem sekcji krytycznej 322
6.3. Rozwi zanie Petersona 325
6.4. Sprz towe rodki synchronizacji 328
6.5. Blokady muteksowe 335
6.6. Semafory 337
6.7. Monitory 341
6.8. ywotno 349
6.9. Ocena 351
6.10. Podsumowanie 353 wiczenia 355
Dalsze lektury 357
Bibliogra a 357
Rozdzia 7. Przyk ady synchronizacji 359
7.1. Klasyczne problemy synchronizacji 360
7.2. Synchronizacja w j drze 367
7.3. Synchronizacja POSIX-owa 371
7.4. Synchronizacja w Javie 375
7.5. Podej cia alternatywne 383
7.6. Podsumowanie 387 wiczenia 388
Dalsze lektury 390
Bibliogra a 390
Rozdzia 8. Zakleszczenia 391
8.1. Model systemu 392
8.2. Zakleszczenie w aplikacjach wielow tkowych 394
8.3. Charakterystyka zakleszczenia 397
8.4. Metody post powania z zakleszczeniami 401
8.5. Zapobieganie zakleszczeniom 403
8.6. Unikanie zakleszcze 406
8.7. Wykrywanie zakleszczenia 414
8.8. Likwidowanie zakleszczenia 420
8.9. Podsumowanie 421 wiczenia 422
Dalsze lektury 427
Bibliogra a 427
CZ 4 ZARZ DZANIE ZASOBAMI PAMI CI
Rozdzia 9. Pami g ówna (operacyjna) 431
9.1. Podstawy 432
9.2. Przydzia ci g y pami ci 440
9.3. Stronicowanie 445
9.4. Struktura tablicy stron 458
9.5. Wymiana 465
9.6. Przyk ad: 32- i 64-bitowe architektury Intela 468
9.7. Przyk ad – architektura ARMv8 472
9.8. Podsumowanie 474 wiczenia 476
Dalsze lektury 479
Bibliogra a 479
Rozdzia 10. Pami wirtualna 481
10.1. Podstawy 482
10.2. Stronicowanie na danie 485
10.3. Kopiowanie przy zapisie 493
10.4. Zast powanie stron 495
10.5. Przydzia ramek 510
10.6. Szamotanie 518
10.7. Kompresja pami ci 526
10.8. Przydzia pami ci dla j dra 527
10.9. Inne rozwa ania 532
10.10. Przyk ady z systemów operacyjnych 540
10.11. Podsumowanie 544 wiczenia 546
Dalsze lektury 551
Bibliogra a 551
CZ 5 ZARZ DZANIE PAMI CI MASOW
Rozdzia 11. Struktura pami ci masowej 555
11.1. Przegl d struktur pami ci masowej 556
11.2. Planowanie dysków twardych (HDD) 566
11.3. Planowanie nieruchomych urz dze pami ci (NVM) 571
11.4. Wykrywanie i korygowanie b dów 573
11.5. Zarz dzanie urz dzeniami pami ci masowej 574
11.6. Zarz dzanie obszarem wymiany 580
11.7. Pod czanie pami ci masowej 583
11.8. Struktury RAID 588
11.9. Podsumowanie 603 wiczenia 604
Dalsze lektury 609
Bibliogra a 609 Spis treści tomu I
Rozdzia 12. Systemy wej cia-wyj cia 611
12.1. Przegl d 612
12.2. Sprz t wej cia-wyj cia 612
12.3. U ytkowy interfejs wej cia-wyj cia 626
12.4. Podsystem wej cia-wyj cia w j drze 635
12.5. Przekszta canie zamówie wej cia-wyj cia na operacje sprz towe 647
12.6. Strumienie (STREAMS) 650
12.7. Wydajno 652
12.8. Podsumowanie 656 wiczenia 657
Dalsze lektury 660
Bibliogra a 660
CZ 6 SYSTEM PLIKÓW
Rozdzia 13. Interfejs systemu plików 663
13.1. Poj cie pliku 664
13.2. Metody dost pu 676
13.3. Struktura katalogowa 680
13.4. Ochrona 691
13.5. Pliki odwzorowane w pami ci 697
13.6. Podsumowanie 702 wiczenia 703
Dalsze lektury 706
Bibliogra a 706
Rozdzia 14. Implementacja systemu plików 707
14.1. Budowa systemu plików 708
14.2. Operacje systemu plików 711
14.3. Implementacja katalogu 715
14.4. Metody przydzia u 716
14.5. Zarz dzanie woln przestrzeni 727
14.6. Wydajno i osi gi 731
14.7. Rekonstrukcja 737
14.8. Przyk ad – system plików WAFL 742
14.9. Podsumowanie 747 wiczenia 748
Dalsze lektury 750
Bibliogra a 750
Rozdzia 15. Wewn trzna organizacja systemów plików 751
15.1. Systemy plików 751
15.2. Montowanie systemu plików 753
15.3. Partycje i montowanie 756
15.4. Dzielenie plików 758
Spis treści tomu I
15.5. Wirtualne systemy plików 759
15.6. Zdalne systemy plików 761
15.7. Semantyka spójno ci 766
15.8. NFS 767
15.9. Podsumowanie 775 wiczenia 776
Dalsze lektury 778
Bibliogra a 778
Wst p
System operacyjny (operating system) jest oprogramowaniem, które zarz dza sprz tem komputera. Stanowi on równie baz dla programów u ytkowych i dzia a jako po rednik mi dzy u ytkownikiem komputera a sprz tem komputerowym. Zadziwiaj cym aspektem systemów operacyjnych jest ich ró norodno , je li chodzi o sposób, w jaki spe niaj te zadania w najrozmaitszych rodowiskach komputerowych. Systemy operacyjne wyst puj wsz dzie – od samochodów i sprz tu domowego wyposa onego w urz dzenia „internetu rzeczy”, po smartfony, komputery osobiste, komputery w przedsi biorstwach i rodowiska oblicze chmurowych.
Aby bada rol , jak odgrywa system operacyjny w nowoczesnym rodowisku obliczeniowym, trzeba najpierw zrozumie organizacj i architektur sprz tu komputerowego. Mamy na my li jednostk centraln , pami g ówn (operacyjn ), urz dzenia wej cia-wyj cia oraz pami masow . Podstawowym obowi zkiem systemu operacyjnego jest przydzielanie tych zasobów programom.
Poniewa system operacyjny jest du y i skomplikowany, musi by tworzony kawa ek po kawa ku – fragmentami. Ka dy fragment musi by dobrze odgraniczon od innych porcj systemu ze starannie zde niowanym wej ciem, wyj ciem oraz funkcjami. W tym rozdziale dokonujemy ogólnego przegl du wa nych sk adowych wspó czesnego systemu komputerowego oraz funkcji pe nionych przez system operacyjny. Poruszamy ponadto kilka innych tematów, aby da podstaw do studiowania dalszych tre ci: struktury danych u ywane w systemach operacyjnych, rodowiska obliczeniowe oraz systemy operacyjne o otwartym kodzie i wolne od op at.
CELE ROZDZIA U
• Nakre lenie ogólnej organizacji systemu komputerowego i znaczenia przerwa .
• Opisanie elementów wspó tworz cych nowoczesny wieloprocesorowy system komputerowy.
• Zobrazowanie przechodzenia od trybu u ytkownika do trybu j dra.
• Przedstawienie ró nych sposobów stosowania systemów operacyjnych w rozmaitych rodowiskach obliczeniowych.
• Podanie przyk adów wolnych systemów operacyjnych i maj cych powszechnie dost pny kod.
1.1. Co robi systemy operacyjne?
Nasze omówienie zaczniemy od przyjrzenia si roli systemu operacyjnego w ogólnie rozumianym systemie komputerowym. System komputerowy mo na z grubsza podzieli na cztery cz ci: sprz t, system operacyjny, programy u ytkowe i u ytkowników (rys. 1.1).
Użytkownik
Programy użytkowe
(kompilatory, przeglądarki, zestawy konstrukcyjne itd.)
System operacyjny
Sprzęt komputerowy (CPU, pamięć, urządzenia we-wy itd.)
Rys. 1.1. Abstrakcyjne wyobra enie elementów systemu komputerowego
Sprz t (hardware), czyli procesor – zwany te jednostk centraln (central processing unit – CPU), pami i urz dzenia wej cia-wyj cia to podstawowe zasoby systemu komputerowego. Programy u ytkowe (aplikacje) – takie jak edytory tekstów, arkusze kalkulacyjne, kompilatory i przegl darki sieciowe –okre laj sposoby u ycia tych zasobów do rozwi zywania zada stawianych przez u ytkowników. System operacyjny nadzoruje i koordynuje pos ugiwanie si sprz tem przez ró ne programy u ytkowe, które pracuj na zlecenie rónych u ytkowników.
2.6. Dlaczego aplikacje zale od systemu operacyjnego
W zasadzie aplikacje skompilowane w jednym systemie operacyjnym nie s wykonywalne w innych systemach operacyjnych. Gdyby by y, wiat by by lepszym miejscem, a w wyborze systemu operacyjnego kierowaliby my si jego wygod i w asno ciami, a nie tym, które aplikacje s w nim dost pne. Opieraj c si na tym, co wcze niej powiedzieli my, mo emy obecnie dostrzec cz tego problemu – ka dy system operacyjny rozporz dza swoistym zbiorem wywo a systemowych. Wywo ania systemowe s cz ci zbioru us ug wiadczonych przez system operacyjny na u ytek aplikacji. Gdyby nawet wywo ania systemowe da o si w jaki sposób ujednolici , inne przeszkody utrudnia yby wykonywanie programów u ytkowych w ró nych systemach operacyjnych. Je li jednak u ywali cie kilku systemów operacyjnych, to zapewne z niektórych takich samych aplikacji da o si w nich skorzysta . Jak to mo liwe? S trzy sposoby udost pnienia aplikacji do pracy w wielu systemach operacyjnych:
1. Mo na napisa aplikacj w j zyku interpretowanym (takim jak Python lub Ruby), którego interpretery s dost pne w wielu systemach operacyjnych. Interpreter czyta kolejne wiersze programu ród owego, wykonuj c zawarte w nich instrukcje za pomoc równowa nych im ci gów rozkazów z zestawu w a ciwego danej maszynie, i u ywa wywo a w a ciwych rodzimemu systemowi operacyjnemu. Cierpi na tym wydajno w stosunku do rdzennych aplikacji, a interpreter dostarcza tylko podzbiór cech kadego z systemów operacyjnych, ograniczaj c by mo e zbiory w asno ci kojarzonych aplikacji.
2. Aplikacj mo na napisa w j zyku, który uwzgl dnia maszyn wirtualn z wykonywan aplikacj . Maszyna wirtualna jest cz ci pe nego rodowiska wykonawczego (RTE) danego j zyka. Przyk adem tej metody jest Java. Java ma RTE zawieraj ce adowacz, wery kator bajtokodu i inne sk adowe, które wprowadzaj aplikacj Javy do maszyny wirtualnej Java. To RTE zosta o przeniesione (ported) do wielu systemów operacyjnych (lub opracowane dla nich od zera), poczynaj c od komputerów g ównych, na smartfonach ko cz c. Teoretycznie dowolna aplikacja Javy mo e pracowa w takim rodowisku wykonawczym, gdziekolwiek jest ono dost pne. Systemy tego rodzaju wykazuj wady podobne do wad interpreterów, które omówili my wcze niej.
3. Budowniczy aplikacji mo e wykorzysta standardowy j zyk lub API, w którym kompilator generuje binaria w maszynowym i specy cznym dla systemu operacyjnego j zyku. Aplikacja musi by przeniesiona do ka dego systemu operacyjnego, w którym b dzie wykonywana. To przeniesienie mo e zajmowa du o czasu i trzeba je wykonywa dla ka dej nowej wersji aplikacji, a w konsekwencji testowa i czy ci z b dów. By mo e najlepiej znanym przyk adem jest POSIX API i jego zbiór standardów utrzymywania
Rozdział 2. Struktury systemów operacyjnych
zgodno ci kodu ród owego mi dzy ró nymi odmianami uniksopodobnych systemów operacyjnych.
Z teoretycznego punktu widzenia te trzy podej cia zdaj si zapewnia proste rozwi zania problemu budowy aplikacji, które mog dzia a w ró nych systemach operacyjnych. Jednak ogólny brak mobilno ci aplikacji ma kilka przyczyn, a ka da z nich sprawia, e opracowywanie aplikacji mi dzyplatformowych jest nie lada zadaniem. Dostarczane wraz z systemami operacyjnymi biblioteki zawieraj na poziomie aplikacji interfejsy API wyposa one w takie mo liwo ci jak interfejsy gra czne, wi c aplikacja pomy lana tak, aby wywoywa a jeden zbiór interfejsów API (powiedzmy, tych, które s dost pne pod systemem iOS w iPhonie Apple’a) nie b dzie dzia a w systemie operacyjnym, który tych API nie ma (np. Android). Na ni szych poziomach w systemie istniej inne wyzwania, w tym nast puj ce:
• Ka dy system operacyjny ma jaki format binarny aplikacji, który narzuca uk ad nag ówka, instrukcji i zmiennych. Te komponenty musz si znajdowa w pliku wykonywalnym w okre lonych miejscach zde niowanych struktur, aby system operacyjny móg otworzy plik, za adowa aplikacj i w a ciwie j wykona .
• Jednostki centralne maj ró ne zbiory rozkazów i tylko aplikacja zawieraj ca odpowiednie rozkazy mo e by poprawnie wykonana.
• Systemy operacyjne dysponuj wywo aniami systemowymi, które umoliwiaj aplikacjom zamawianie rozmaitych czynno ci, takich jak tworzenie plików i otwieranie po cze sieciowych. Wywo ania systemowe ró ni si w ró nych systemach operacyjnych pod wieloma wzgl dami, m.in. specy cznymi argumentami i ich uporz dkowaniem, sposobem uaktywniania przez aplikacj funkcji systemowych, ich numeracj i liczb , znaczeniem i zwracanymi wynikami.
Jest kilka podej pomocnych w pokonywaniu tych architektonicznych ró nic, lecz nie daj cych kompletnych rozwi za . Na przyk ad w Linuxie –i w prawie ka dym systemie uniksowym – dla wykonywalnych plików binarnych przyj to format ELF. Mimo e ELF stanowi powszechny standard w systemach Linux i UNIX, nie jest zwi zany z adn konkretn architektur komputera, nie gwarantuje wi c, e plik wykonywalny b dzie dzia a na ró nych platformach sprz towych. Interfejsy API, jak ju wspomniano, okre laj pewne funkcje na poziomie aplikacji. Na poziomie architektonicznym stosuje si binarny interfejs aplikacji (application binary interface – ABI) de niuj cy sposób wspó pracy ró nych komponentów kodu binarnego w danym systemie operacyjnym i danej architekturze. ABI okre la szczegó y niskiego poziomu, w tym d ugo adresu, metody przekazywania parametrów do wywo a systemowych, organizacj stosu w fazie wykonywania, binarny format bibliotek systemowych i rozmiar typów danych
2.7. Projektowanie i implementowanie systemów operacyjnych
– by wymieni tylko niektóre. ABI jest zazwyczaj zde niowany dla okre lonej architektury (istnieje na przyk ad ABI dla procesora ARMv8). Tak wi c ABI jest odpowiednikiem API na poziomie architektonicznym. Je eli binarny plik wykonywalny zosta skompilowany i skonsolidowany zgodnie z konkretnym ABI, powinien da si wykona w ró nych systemach udost pniaj cych ten ABI. Poniewa jednak konkretny ABI jest zde niowany dla okre lonego systemu operacyjnego dzia aj cego w okre lonej architekturze, interfejsy ABI w niewielkim stopniu przyczyniaj si do zapewniania zgodno ci mi dzyplatformowej. Podsumowuj c, wszystkie te ró nice oznaczaj , e dopóki interpreter, RTE lub binarny plik wykonywalny nie zostan napisane i skompilowane w okre lonym systemie operacyjnym dla jednostki centralnej okre lonego typu (np. dla Intela lub ARMv8), aplikacja nie b dzie dzia a a. Wyobra my sobie, ile trzeba pracy, aby program w rodzaju przegl darki Firefox dzia a pod systemami Windows, macOS, w ró nych wydaniach Linuxa, w systemach iOS i Android, i jeszcze niekiedy na CPU o ró nych architekturach.
2.7. Projektowanie i implementowanie systemów operacyjnych
W tym podrozdziale omówimy zagadnienia projektowania i implementowania systemu operacyjnego. Nie istniej – rzecz jasna – gotowe rozwi zania takich problemów, lecz niektóre podej cia zosta y sprawdzone w praktyce.
2.7.1.
Za o enia projektowe
Pierwszym zagadnieniem przy projektowaniu systemu jest okre lenie celów i specy kacji systemu. Na najwy szym poziomie projekt systemu b dzie w duym stopniu zale a od wyboru sprz tu i typu systemu – czy ma to by system dla konwencjonalnego komputera biurkowego lub laptopa, czy ma by mobilny, rozproszony, czy pracuj cy w czasie rzeczywistym.
Pomin wszy poziom najwy szy, sformu owanie wymaga mo e by znacznie trudniejsze. Wymagania te mo na zasadniczo podzieli na dwie grupy: cele u ytkownika i cele systemu.
U ytkownicy oczekuj od systemu operacyjnego pewnych oczywistych cech. Powinien on by wygodny i atwy w u yciu, atwy do nauki, niezawodny, bezpieczny i szybki. Jest zrozumia e, e ze wzgl du na brak powszechnej zgody co do sposobu osi gania tak okre lonych celów, tego rodzaju specy kacje nie s zbyt przydatne w projektowaniu systemu.
Podobny zestaw wymaga mog sformu owa osoby, których zadaniem jest taki system zaprojektowa , utworzy , utrzymywa i obs ugiwa . System operacyjny powinien by atwy do zaprojektowania, realizacji i piel gnowania; powinien by elastyczny, niezawodny, wolny od b dów i wydajny. I znowu, tak postawione wymagania s niejasne i mog by interpretowane przeró nie.
• Sprawno dzia ania systemu operacyjnego mo na monitorowa za pomoc liczników lub ledzenia. Liczniki stanowi zbiór ogólnosystemowych lub procesowych statystyk, natomiast podczas ledzenia pod a si za programem wykonywanym w systemie operacyjnym.
wiczenia
2.1. Do czego s u wywo ania (funkcje) systemowe?
ODPOWIEDŹ
Wywołania systemowe umożliwiają procesom z poziomu użytkownika zamawianie usług systemu operacyjnego.
2.2. Co nale y do zada interpretera polece ? Dlaczego na ogó jest on oddzielony od j dra?
ODPOWIEDŹ
lub te, które pobiera z pliku poleceń, zamieniając je zwykle na jedno lub więcej wywołań systemowych. Na ogół nie jest on częścią jądra, gdyż może być zmieniany.
Interpreter poleceń czyta i wykonuje polecenia podawane przez użytkownika
2.3. Jakie wywo ania systemowe musz by wykonane przez interpreter polece lub pow ok , aby rozpocz nowy proces w systemie UNIX?
ODPOWIEDŹ
i exec(). Wywołanie fork() klonuje aktualnie wykonywany proces, natomiast wywołanie exec()nakłada nowy proces, oparty na innej jednostce wykonywalnej, na proces wywołujący.
Aby rozpocząć nowy proces, należy wykonać wywołania systemowe fork()
2.4. Do czego s u programy systemowe?
ODPOWIEDŹ
ODPOWIEDŹ Programy systemowe można uważać za wiązki pożytecznych wywołań systemowych. Realizują one podstawowe funkcje dla użytkowników, dzięki czemu użytkownicy nie muszą pisać własnych programów, aby rozwiązywać typowe problemy.
2.5. Na czym polega g ówna zaleta podej cia warstwowego w projektowaniu systemu? Jakie s wady podej cia warstwowego?
nia przez różne warstwy w celu uzyskania usługi systemu operacyjnego.
ścia warstwowego jest słaba wydajność spowodowana kosztami przechodze-
ograniczone do konkretnego modułu lub warstwy. Podstawową wadą podej-
Rozdział 2. Struktury systemów operacyjnych
przechowywane tylko tam, gdzie są potrzebne i dostępne tylko w określonym i ograniczonym obszarze, więc wszelkie błędy dotyczące danych muszą być
dotyczą tylko ograniczonej liczby jego części, a nie wszystkich. Informacje są
Jak wszędzie w projektowaniu modularnym, projektowanie systemu operacyjnego w sposób modularny ma kilka zalet. System jest łatwiejszy do uruchamiania (usuwania błędów, „debugowania”) i kowania,modyfi ponieważ zmiany
2.6. Wymie pi us ug wykonywanych przez system operacyjny i wyja nij, na czym polega wygoda, któr ka da z nich daje u ytkownikowi. W jakich przypadkach nie by oby mo liwe zrealizowanie tych us ug w programach pracuj cych na poziomie u ytkownika. Uzasadnij swoj odpowied . ODPOWIEDŹ
przez system operacyjny, procesy nie muszą zawierać kodu przechwytującego i korygującego wszystkie błędy, które mogą się pojawiać w systemie.
że błędy są niezależne od procesów (np. uszkodzenie danych dyskowych), musi więc istnieć jakiś ogarniający to wszystko program (system operacyjny), który obsługuje wszystkie błędy. Poza tym, jeśli błędy są przetwarzane
mie sprzętowym, jak i programowym. Należy kontrolować wszystkie poziomy sprzętowe i wszystkie przesłania danych, aby gwarantować, że dane nie zostały uszkodzone w trakcie przechodzenia. Wszystkie dane na nośnikach muszą być sprawdzane, aby mieć pewność, że nie uległy zmianie od czasu, gdy je na nich zapisano. Na poziomie oprogramowania trzeba kontrolować spójność danych – czy na przykład liczba bloków przydzielonych i nieprzydzielonych jest równa ogólnej liczbie bloków na urządzeniu. Często bywa,
5. Wykrywanie błędów. Wykrywanie błędów ma miejsce zarówno na pozio-
nież w tym przypadku programy użytkownika nie dałyby rady koordynować dostępu do urządzenia sieci lub odbierałyby pakiety przeznaczone dla innych procesów.
4. Komunikacja. Przekazywanie komunikatów między systemami wymaga zamiany komunikatów na pakiety informacji, wysyłania ich do sterownika sieci, transmitowania nośnikiem komunikacyjnym i składania ich z powrotem przez docelowy system. Trzeba porządkować komunikaty i korygować dane. Rów-
3. Działania na plikach. Tworzenie, usuwanie i nazywanie plików oraz przydzielanie im miejsca wymaga uwzględnienia wielu szczegółów, którymi nie powinni zajmować się użytkownicy. Pliki używają bloków dyskowych, których trzeba pilnować. Usuwanie pliku wymaga skasowania informacji dotyczących nazwy pliku i zwolnienia przydzielonych bloków. Trzeba również dokonywać kontroli, aby zapewnić plikowi właściwą ochronę. Programy użytkowników nie nadają się do realizacji metod ochrony ani nie są odpowiednio zaufane, by mogły same przydzielać wolne bloki i zwalniać bloki podczas usuwania pliku.
