KATEDRA INFORMATIKY UNIVERZITA PALACKÉHO VÝVOJ TOHOTO UČEBNÍHO TEXTU JE SPOLUFINANCOVÁN

KATEDRA INFORMATIKY ˇ I´RODOVEˇDECKA ´ FAKULTA PR UNIVERZITA PALACKE´HO

OPERACˇNI´ SYSTE´MY ALESˇ KEPRT

´N VY´VOJ TOHOTO UCˇEBNI´HO TEXTU JE SPOLUFINANCOVA ´ LNI´M FONDEM A STA ´ TNI´M ROZPOCˇTEM CˇESKE´ REPUBLIKY EVROPSKY´M SOCIA

Olomouc, 22.12.2007

Abstrakt

Tento text ma´ za cı´l poslouzˇit jako studijnı´ text k prˇedmeˇtu˚m o operacˇnı´ch syste´mech, ve vsˇech jejich varianta´ch. Text je postaven na u´rovni teoreticke´, prˇicˇemzˇ prakticke´ doplneˇnı´ poskytujı´ dalsˇ´ı samostatne´ ucˇebnı´ texty. Rozsah zde probı´rane´ la´tky odpovı´da´ prˇedevsˇ´ım potrˇeba´m samostudia studentu˚ v kombinovane´ formeˇ, kterˇ´ı majı´ operacˇnı´ syste´my jako jednosemestra´lnı´ kurz. Pro studium v prezencˇnı´ formeˇ, kde operacˇnı´ syste´my majı´ dvojsemestra´lnı´ podobu, mu˚zˇe by´t prˇedevsˇ´ım dobry´m za´kladem studia, nikoliv vsˇak jediny´m studijnı´m zdrojem.

Cı´lova´ skupina

Text je prima´rneˇ urcˇen pro studenty oboru Aplikovana´ informatika uskutecˇnˇovane´ho v kombinovane´ formeˇ na Prˇ´ırodoveˇdecke´ fakulteˇ Univerzity Palacke´ho v Olomouci a da´le pro studenty oboru˚ Informatika, Aplikovana´ informatika a Ucˇitelstvı´ vy´pocˇetnı´ techniky uskutecˇnˇovany´ch v prezencˇnı´ formeˇ tamte´zˇ. Pokry´va´ la´tku prˇedmeˇtu˚ Operacˇnı´ syste´my a Programove´ vybavenı´ pocˇ´ıtacˇu˚ v jejich ru˚zny´ch varianta´ch (ko´dy XOSY, XOS, XSYS, OS1AI, OS1AA, OS2AI, VP1AW, VP2AW). K prakticky´m cvicˇenı´m zde probı´rane´ la´tky slouzˇ´ı take´ dalsˇ´ı dva doplnˇkove´ studijnı´ texty, oznacˇene´ v referencı´ch jako [Kep08a] a [Kep08b].

Obsah 1

2

´ vod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . U

9

1.1

Co je to pocˇ´ıtacˇ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

1.2

Architektura pocˇ´ıtacˇe, von Neumannu˚v model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

1.3

Abstrakce hardwaru a architektury . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

Za´kladnı´ prvky pocˇ´ıtacˇe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

2.1

CPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

2.1.1

Procesor a instrukce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

2.1.2

Vykona´nı´ instrukce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

2.1.3

Paralelnı´ vykona´va´nı´ instrukcı´ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15

2.1.4

Instrukcˇnı´ sada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16

Operacˇnı´ pameˇt’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17

2.2.1

Ulozˇenı´ cˇ´ısel v pocˇ´ıtacˇi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17

2.2.2

Ulozˇenı´ znaku˚ v pameˇti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

19

2.2.3

Adresova´nı´ pameˇti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20

2.2.4

Typy adres v operandech . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21

2.2.5

Cache pameˇt’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

22

I/O zarˇ´ızenı´ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

22

ˇ ´ızenı´ vy´pocˇtu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . R

26

3.1

Porˇadı´ vykona´va´nı´ instrukcı´ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

26

3.2

Vola´nı´ podprogramu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27

3.3

Prˇerusˇenı´ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

Operacˇnı´ syste´m . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

34

4.1

Co je to operacˇnı´ syste´m . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

34

4.2

Typy syste´mu˚ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

36

4.2.1

Sa´love´ pocˇ´ıtacˇe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

36

4.2.2

Osobnı´ pocˇ´ıtacˇe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

37

4.2.3

Vı´ceprocesorove´ pocˇ´ıtacˇe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

37

4.2.4

Distribuovane´ syste´my a klastry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

38

4.2.5

Dalsˇ´ı typy pocˇ´ıtacˇovy´ch syste´mu˚ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

38

Spra´va procesoru . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

41

5.1

Procesy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

41

5.1.1

Zˇivotnı´ cyklus procesu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

42

5.1.2

Prˇepı´na´nı´ procesu˚ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

43

5.1.3

Kooperativnı´ a preemptivnı´ syste´my . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

43

Strategie prˇideˇlova´nı´ procesoru . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

44

5.2.1

44

2.2

2.3 3

4

5

5.2

Cyklicka´ obsluha (round robin) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.2.2

Syste´m priorit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

44

5.2.3

Prakticke´ strategie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

45

Vla´kna . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

45

5.3.1

Zavedenı´ pojmu vla´kno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

45

5.3.2

Vla´kna v kontextu drˇ´ıveˇjsˇ´ıch znalostı´ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

46

5.3.3

Vla´kna na single–user u´loha´ch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

46

5.3.4

Technicka´ realizace vla´ken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

47

5.3.5

Vztah proces–vla´kno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

47

Spra´va procesoru v praxi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

49

6.1

Unix – Vytvorˇenı´, pla´nova´nı´ a stavy procesu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

49

6.1.1

Stavy procesu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

49

6.1.2

Vytvorˇenı´ procesu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

50

6.1.3

Pla´nova´nı´ procesu˚ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

51

NT – Vytvorˇenı´ procesu, pla´nova´nı´ a stavy vla´kna . . . . . . . . . . . . . . . . . . . . . . . . . . . .

51

6.2.1

Stavy vla´kna . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

51

6.2.2

Vytvorˇenı´ procesu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

52

6.2.3

Pla´nova´nı´ vla´ken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

53

6.2.4

Zvysˇova´nı´ priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

58

6.2.5

Symetricky´ multiprocessing (SMP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

59

Vla´kna v Linuxu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

61

Synchronizace vla´ken a procesu˚ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

63

7.1

Principy synchronizace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

63

7.1.1

´ vod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . U

63

7.1.2

Atomicke´ operace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

64

7.1.3

Hardwarove´ atomicke´ operace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

65

7.1.4

Softwarova´ implementace atomicity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

66

7.1.5

Semafor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

67

7.1.6

Mutex a kriticka´ sekce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

67

7.1.7

Uda´lost a signa´l . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

68

7.1.8

Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

69

Synchronizace v NT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

70

7.2.1

Uda´lost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

70

7.2.2

Semafor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

70

7.2.3

Mutex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

71

7.2.4

Kriticka´ sekce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

71

7.2.5

Cˇekacı´ funkce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

71

7.2.6

Dalsˇ´ı synchronizacˇnı´ a komunikacˇnı´ na´stroje . . . . . . . . . . . . . . . . . . . . . . . . . .

72

Futex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

72

5.3

6

6.2

6.3 7

7.2

7.3

8

Deadlock (uva´znutı´) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

75

8.1

´ vod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . U

75

8.2

Kdy nasta´va´ deadlock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

75

8.3

ˇ esˇenı´ deadlocku . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . R

76

8.3.1

Detekce deadlocku . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

76

8.3.2

Zotavenı´ z deadlocku . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

77

8.3.3

Zamezenı´ vzniku . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

78

8.3.4

Vyhy´ba´nı´ se uva´znutı´ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

79

Dvojfa´zove´ zamyka´nı´ a dalsˇ´ı te´mata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

81

Spra´va operacˇnı´ pameˇti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

84

9.1

´ vod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . U

84

9.2

Prˇideˇlova´nı´ souvisly´ch u´seku˚ (bloku˚) pameˇti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

85

9.3

Stra´nkova´nı´ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

87

9.4

Princip lokality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

90

9.5

Stra´nkova´nı´ na 64bitovy´ch procesorech . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

91

9.6

Segmentove´ adresova´nı´ (segmentace) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

92

9.7

Copy–on–write . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

93

10 Virtua´lnı´ pameˇt’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

97

´ vod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.1 U

97

10.2 Startova´nı´ a beˇh programu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

98

10.3 Rezervovana´ a komitovana´ pameˇt’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

98

10.4 Vy´meˇna ra´mcu˚ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

98

8.4 9

10.5 Vy´beˇr obeˇti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 10.5.1 Optima´lnı´ algoritmus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 10.5.2 FIFO – first in, first out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 10.5.3 LRU – least recently used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 10.5.4 Prˇiblizˇne´ LRU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 10.5.5 LFU – least frequently used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 10.5.6 Buffer volny´ch ra´mcu˚ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 10.6 Prˇideˇlova´nı´ ra´mcu˚ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 10.6.1 Minima´lnı´ pocˇet ra´mcu˚ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 10.6.2 Alokacˇnı´ algoritmy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 10.7 Thrashing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 10.7.1 Pracovnı´ mnozˇina ra´mcu˚ (working set) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 10.7.2 Frekvence vy´padku˚ stra´nky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 10.8 Mapova´nı´ souboru do pameˇti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 10.9 Dalsˇ´ı pasti a pasticˇky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 10.9.1 Prˇevod ra´mcu˚ na stra´nky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

10.9.2 Pameˇt’pro objekty ja´dra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 10.9.3 Velikost stra´nky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 10.9.4 Swapova´nı´ stra´nkovacı´ch tabulek, zamyka´nı´ stra´nek . . . . . . . . . . . . . . . . . . . . . . 107 11 Spra´va pameˇti v praxi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 11.1 NT na platformeˇ x86 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 11.1.1 Za´kladnı´ fakta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 11.1.2 AWE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 11.1.3 PAE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 11.1.4 Pameˇt’ove´ stra´nky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 11.1.5 Pracovnı´ mnozˇina ra´mcu˚ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 11.1.6 Logical prefetcher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 11.1.7 Ochrana pameˇti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 11.2 Adresace na procesorech x86 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 11.2.1 Typy adres . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 11.2.2 Logicke´ adresy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 11.2.3 Segmentace (prˇeklad logicke´ adresy na linea´rnı´) . . . . . . . . . . . . . . . . . . . . . . . . 117 11.2.4 Stra´nkova´nı´ (prˇeklad linea´rnı´ adresy na fyzickou) . . . . . . . . . . . . . . . . . . . . . . . . 117 11.2.5 Velikost stra´nky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 ´ rovneˇ opra´vneˇnı´ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 11.2.6 U 11.2.7 Stra´nkova´nı´ v rezˇimu PAE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 11.3 Adresace na procesorech x64 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 11.4 Ochrana pameˇti na procesorech x86 a x64 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 11.4.1 Prˇehled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 11.4.2 Kontrola limitu˚ segmentu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 11.4.3 Kontrola typu deskriptoru a segmentu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 ´ rovneˇ opra´vneˇnı´ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 11.4.4 U 11.4.5 Privilegia u ko´dovy´ch segmentu˚ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 11.4.6 Kontrola na u´rovni stra´nek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 11.4.7 NX bit

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

12 Souborovy´ syste´m . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 12.1 Soubor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 12.2 Souborove´ operace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 12.3 Otevrˇene´ soubory a handly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 12.4 Zamyka´nı´ souboru˚ (lock) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 12.5 Typy souboru˚ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 12.6 Struktura souboru˚ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 12.7 Prˇ´ıstup k souboru˚m . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 12.8 Deˇlenı´ disku a adresa´rˇe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

12.9 Sdı´lenı´ souboru˚ mezi uzˇivateli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 12.10Ochrana souboru˚ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 13 Implementace souborove´ho syste´mu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 13.1 Struktura disku . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 13.2 Master boot record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 13.3 Obecna´ struktura svazku . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 13.4 Data v pameˇti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 13.5 Adresa´rˇe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 13.5.1 Linea´rnı´ seznam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 13.5.2 Hashovacı´ tabulka . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 13.6 Alokace diskove´ho prostoru . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 13.6.1 Souvisla´ alokace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 13.6.2 Spojove´ seznamy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 13.6.3 Indexovana´ alokace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 13.6.4 Srovna´nı´ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 13.7 Evidence volne´ho mı´sta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 13.8 Efektivita a vy´kon diskovy´ch operacı´ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 13.9 Chyby a zotavenı´ z nich . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 13.9.1 Konzistence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 13.9.2 Za´lohy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 13.10Zˇurna´love´ syste´my . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 13.11Pla´nova´nı´ prˇ´ıstupu k disku . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 13.11.1 Algoritmus FCFS (first come, first served) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 13.11.2 Algoritmus SSTF (shortest seek time first) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 13.11.3 Algoritmus SCAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 13.11.4 Algoritmus C–SCAN (Circular SCAN) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 13.11.5 Algoritmy LOOK a C–LOOK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 13.11.6 Vy´beˇr vhodne´ho algoritmu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 14 Prˇ´ıklady souborovy´ch syste´mu˚, RAID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 ´ vod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 14.1 U 14.2 FAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 14.3 Unix File System (UFS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 14.4 NTFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 14.5 RAID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 14.5.1 RAID 0 (stripping – pruhova´nı´) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 14.5.2 RAID 1 (mirroring – zrcadlenı´) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 14.5.3 RAID 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 14.5.4 RAID 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

14.5.5 RAID 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 14.5.6 RAID 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 14.5.7 RAID 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 14.5.8 Softwarova´ emulace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 A Jak vznikajı´ programy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 A.1 Prˇeklad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 A.2 Linkova´nı´ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 A.3 Knihovny a spousˇteˇnı´ programu˚ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 A.4 Komponenty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 B Ochrana a zabezpecˇenı´ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 C Seznam obra´zku˚ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

´ vod U

1

Studijnı´ cı´le: Vı´tejte v u´vodnı´ kapitole tohoto ucˇebnı´ho textu. Te´matem te´to kapitoly je samotny´ „pocˇ´ıtacˇ“, tedy pojem vsˇeobecneˇ zna´my´. Podı´va´me se tedy na to, jak tento pojem mu˚zˇeme definovat, cˇ´ımzˇ za´rovenˇ vysveˇtlı´me, co bude te´matem nasˇeho dalsˇ´ıho studia. Udeˇla´me si take´ kra´tke´ oke´nko do historie pocˇ´ıtacˇu˚ a prˇipomeneme si zna´my´ von Neumannu˚v model popisujı´cı´ hardwarovou strukturu pocˇ´ıtacˇe. Naucˇ´ıme se take´ videˇt pocˇ´ıtacˇ na ru˚zny´ch u´rovnı´ch abstrakce. Klı´cˇova´ slova: pocˇ´ıtacˇ, von Neumannu˚v model, abstrakce hardwaru Potrˇebny´ cˇas: 25 minut.

1.1

Co je to pocˇ´ıtacˇ

Pru˚vodce studiem Pojem „pocˇ´ıtacˇ“ je nasˇteˇstı´ vsˇeobecneˇ zna´my´ (kazˇdy´ z cˇtena´rˇu˚ te´to publikace jisteˇ jizˇ pocˇ´ıtacˇ videˇl), navı´c na ota´zku „Co je to pocˇ´ıtacˇ?“ celkem jisteˇ studenti na zkousˇce z operacˇnı´ch syste´mu˚ nenarazı´, takzˇe odpoveˇd’ na ni vlastneˇ ani nechteˇjı´ studovat.

Pocˇ´ıtacˇ je obvykle definova´n jako stroj pro zpracova´nı´ dat dle dany´ch instrukcı´ (programu). (V literaturˇe prˇitom zrˇejmeˇ najdete mnoho vı´ce cˇi me´neˇ podobny´ch definic.) V dnesˇnı´ dobeˇ pocˇ´ıtacˇe v ru˚zny´ch podoba´ch potka´va´me doslova na kazˇde´m kroku, nejobvyklejsˇ´ım typem pocˇ´ıtacˇu˚ jsou prˇitom jednoznacˇneˇ pocˇ´ıtacˇe zabudovane´ (embedded) – tyto male´ pocˇ´ıtacˇe na´m naprˇ´ıklad slouzˇ´ı v kazˇdodennı´m zˇivoteˇ jako ovla´dacı´ jednotky ru˚zny´ch doma´cı´ch spotrˇebicˇu˚, mobilnı´ch telefonu˚, dopravnı´ch prostrˇedku˚ cˇi hracˇek. Jak zna´mo, pocˇ´ıtacˇe nebyly vzˇdycky tak male´ jako dnes. Naopak, prvnı´ pocˇ´ıtacˇe byly mnohem veˇtsˇ´ı, v cˇesˇtineˇ se pro tyto historicke´ pocˇ´ıtacˇe obvykle uzˇ´ıva´ trefny´ termı´n „sa´love´ pocˇ´ıtacˇe“ (v anglicˇtineˇ „mainframe“ – cˇili nejde o doslovny´ prˇeklad pu˚vodnı´ho termı´nu). Pocˇ´ıtacˇe prvnı´ch generacı´ byly nejen daleko veˇtsˇ´ı nezˇ ty dnesˇnı´, ale take´ mnohem jednodusˇsˇ´ı a pomalejsˇ´ı. Jednı´m z meznı´ku˚ ve vy´voji pocˇ´ıtacˇu˚ bylo pouzˇitı´ tranzistoru, ktery´ nahradil drˇ´ıve pouzˇ´ıvanou elektronku a zaha´jil tı´m tzv. druhou generaci pocˇ´ıtacˇu˚ na konci 50.let 20.stoletı´. Tranzistor umozˇnil vy´robu pocˇ´ıtacˇu˚ levneˇjsˇ´ıch, spolehliveˇjsˇ´ıch, mensˇ´ıch i rychlejsˇ´ıch za´rovenˇ. Pru˚vodce studiem Ma´me-li by´t zcela korektnı´, je trˇeba dodat, zˇe u´plneˇ prvnı´ pocˇ´ıtacˇe nebyly ani „sa´love´“ a dokonce ani bina´rnı´ (tj. nepracovaly na ba´zi jednicˇek a nul). Nicme´neˇ prvnı´ rea´lneˇ pouzˇ´ıvane´ pocˇ´ıtacˇe, ktere´ vsˇechny vznikly v souvislosti s druhou sveˇtovou va´lkou a vojensky´mi u´cˇely, skutecˇneˇ byly velke´ a „sa´love´“.

Integracı´ veˇtsˇ´ıho mnozˇstvı´ malicˇky´ch tranzistoru˚ do jedine´ strojoveˇ vyra´beˇne´ soucˇa´stky zvane´ integrovany´ obvod bylo pozdeˇji umozˇneˇno vytvorˇit pocˇ´ıtacˇe jesˇteˇ mensˇ´ı a opeˇt prˇedevsˇ´ım podstatneˇ levneˇjsˇ´ı nezˇ prˇi manua´lnı´m skla´da´nı´ jednotlivy´ch tranzistoru˚. Tı´m vznikla trˇetı´ generace pocˇ´ıtacˇu˚. Tı´m, jak se pocˇ´ıtacˇe zmensˇovaly a zlevnˇovaly, byl samozrˇejmeˇ take´ otevrˇen prostor pro zveˇtsˇova´nı´ jejich vy´konu cˇi pameˇti (a to samozrˇejmeˇ jejich opeˇtovny´m zveˇtsˇova´nı´m). Beˇhem tohoto postupne´ho vy´voje se zacˇalo ukazovat, zˇe pocˇ´ıtacˇe svou slozˇitostı´ jizˇ jisty´m zpu˚sobem prˇeru˚stajı´ lidem prˇes hlavu a zatı´mco jejich vy´roba byla sta´le jednodusˇsˇ´ı, jejich programova´nı´ bylo sta´le slozˇiteˇjsˇ´ı. A neˇkde v te´to dobeˇ se zacˇaly objevovat prvnı´ na´vrhy operacˇnı´ch syste´mu˚.

9

Pocˇ´ıtacˇ je stroj pro zpracova´nı´ dat dle instrukcı´.

Dnes s odstupem neˇkolika desetiletı´ mu˚zˇeme jizˇ operacˇnı´ syste´m a jeho smysl velmi prˇesneˇ definovat: Je to za´kladnı´ program pocˇ´ıtacˇe, ktery´ odstinˇuje ostatnı´ programy od prˇ´ıme´ komunikace cˇi spolupra´ce s hardwarem. Tento za´kladnı´ program umozˇnˇuje ostatnı´m programu˚m vysˇsˇ´ı u´rovenˇ abstrakce, jsou v neˇm totizˇ rˇesˇeny nejslozˇiteˇjsˇ´ı a cˇasto se opakujı´cı´ operace s hardwarem. Ostatnı´m programu˚m operacˇnı´ syste´m nabı´zı´ sve´ funkce v podobeˇ jednodusˇsˇ´ıho rozhranı´. Pru˚vodce studiem Pro prˇ´ıklad smyslu operacˇnı´ho syste´mu nemusı´me chodit daleko. Klasickou funkcı´ operacˇnı´ho syste´mu je naprˇ´ıklad nacˇtenı´ dat ze souboru. Zatı´mco z hlediska beˇzˇne´ho programu je to ota´zka zavola´nı´ neˇkolika ma´lo funkcı´ (otevrˇi–nacˇti–zavrˇi), operacˇnı´ syste´m s tı´m ma´ pomeˇrneˇ hodneˇ pra´ce. Podı´va´me-li se na veˇc v kontextu doby, cˇili s ohledem na to, zˇe v minulosti neexistovaly sofistikovane´ hard disky cˇi CD mechaniky (ktere´ dnes majı´ samy zabudova´n rˇ´ıdicı´ pocˇ´ıtacˇ), ale jen „hloupa´“ pa´skova´ zarˇ´ızenı´ bez jake´koliv inteligence, je videˇt, zˇe mnozˇstvı´ pra´ce, ktere´ musel operacˇnı´ syste´m prova´deˇt, aby prˇevedl elektricke´ impulzy z pa´skove´ jednotky na smysluplna´ data, bylo opravdu enormnı´.

Vy´znam operacˇnı´ho syste´mu jakozˇto za´kladnı´ softwarove´ vy´bavy pocˇ´ıtacˇe samozrˇejmeˇ jesˇteˇ da´le rostl s tı´m, jak se da´le zveˇtsˇovala slozˇitost pocˇ´ıtacˇu˚. Dalsˇ´ım hlavnı´m meznı´kem byl (samozrˇejmeˇ) prˇechod na 4.generaci pocˇ´ıtacˇu˚ vyuzˇ´ıvajı´cı´ch mikroprocesory. Slozˇitost pocˇ´ıtacˇu˚ i dnes sta´le roste a to jak z du˚vodu jejich zmensˇova´nı´ (mensˇ´ı soucˇa´stky umozˇnˇujı´ rychlejsˇ´ı beˇh), tak z du˚vodu paralelizace – zatı´mco jesˇteˇ v 80.letech 20.stoletı´ se beˇzˇneˇ pouzˇ´ıvaly pocˇ´ıtacˇe s jednı´m mikroprocesorem, dnesˇnı´ beˇzˇne´ pocˇ´ıtacˇe majı´ mikroprocesoru˚ tolik, zˇe je teˇzˇko spocˇ´ıta´me. Prˇ´ıma´ pra´ce s tak slozˇity´m syste´mem inteligentnı´ch stroju˚ by dnes uzˇ ani nebyla mozˇna´, proto se bez operacˇnı´ho syste´mu neobejdeme. Jakkoliv je dnes v beˇzˇne´m zˇivoteˇ mozˇno potkat neprˇeberne´ mnozˇstvı´ pocˇ´ıtacˇu˚, u veˇtsˇiny z nich mu˚zˇeme videˇt jiste´ stejne´ rysy, jak co do jejich hardwarove´ho na´vrhu, tak co do architektury jejich operacˇnı´ho syste´mu. A pra´veˇ tato dveˇ te´mata jsou na´plnı´ studia Operacˇnı´ch syste´mu˚, ktere´ pokry´va´ tento ucˇebnı´ text. Nasˇe pozornost bude samozrˇejmeˇ zameˇrˇena prˇedevsˇ´ım na tzv. beˇzˇne´ doma´cı´ pocˇ´ıtacˇe „PC“, s jejichzˇ provozem a programova´nı´m se informatici obvykle setka´vajı´ v praxi. Me´neˇ pak na´s budou zajı´mat pocˇ´ıtacˇe zabudovane´, protozˇe tyto jsou z principu velmi jednoduche´ (uzˇ proto, zˇe musejı´ by´t take´ velmi levne´, aby jejich pouzˇ´ıva´nı´ meˇlo smysl), kazˇdy´ z nich ma´ u´zkou oblast vyuzˇitı´ a jejich operacˇnı´ syste´my jsou stejneˇ tak velmi jednoduche´.

1.2

Architektura pocˇ´ıtacˇe, von Neumannu˚v model

Prˇipomenˇme si kra´tce termı´n „von Neumannova architektura“ (viz obra´zek 1). Jde o nejzna´meˇjsˇ´ı pocˇ´ıtacˇovou architekturu, ktera´ je dodnes nejcˇasteˇji zminˇova´na jako jaky´si de facto „za´kladnı´ model pocˇ´ıtacˇe“.

CPU

Pameˇt’

I/O

sbeˇrnice Obra´zek 1: Sche´ma pocˇ´ıtacˇe – von Neumannu˚v model Von Neumannova architektura popisuje pocˇ´ıtacˇ jako sekvencˇnı´ stroj, ktery´ pouzˇ´ıva´ jedinou pameˇt’spolecˇnou pro ko´d i data. Podstatny´m rysem te´to architektury tedy je, zˇe ko´d programu i jeho data jsou ulozˇeny ve spolecˇne´ pameˇti. Vy´pocˇetnı´ model je navı´c sekvencˇnı´, cˇili prˇ´ıkazy 10

v programu (instrukce) jsou zpracova´va´ny v rˇadeˇ za sebou, pokud nenı´ (neˇkterou instrukcı´) stanoveno jinak. Pru˚vodce studiem Tomuto vy´pocˇetnı´mu modelu v podstateˇ odpovı´da´ i rˇada zna´my´ch programovacı´ch jazyku˚ (jako Pascal cˇi C). Ma´me-li vsˇak by´t prˇesnı´, prava´ von Neumannova architektura se dnes jizˇ te´meˇrˇ nepouzˇ´ıva´. Pro male´ zabudovane´ pocˇ´ıtacˇe, ktery´ch je nejvı´c, je totizˇ vhodneˇjsˇ´ı harvardsky´ model a „velke´“ klasicke´ pocˇ´ıtacˇe zase dnes jizˇ nepouzˇ´ıvajı´ cˇisty´ sekvencˇnı´ vy´pocˇetnı´ model, protozˇe cˇasto obsahujı´ vı´ce CPU.

Vy´pocˇetnı´ model, o ktere´m je zde rˇecˇ, publikoval v roce 1945 John von Neumann, Americˇan uherske´ho pu˚vodu. Pozdeˇji se vsˇak zjistilo, zˇe jizˇ v roce 1936 si jej patentoval Neˇmec Konrad Zuse, ktery´ je tak vlastneˇ skutecˇny´m objevitelem tohoto vyna´lezu. (Zuseho take´ neˇktere´ zdroje uva´deˇjı´ jako sestrojitele prvnı´ho univerza´lnı´ho (tj. Turing–kompletnı´ho) pocˇ´ıtacˇe v roce 1941.) Za´kladnı´ strukturu von Neumannova modelu tvorˇ´ı CPU s aritmeticko–logickou jednotkou, rˇ´ıdicı´ jednotka (rˇadicˇ), pameˇt’a vstupneˇ–vy´stupnı´ jednotka, ktere´ jsou vsˇechny propojeny jednou spolecˇnou sadou sbeˇrnic (a ta se skla´da´ se trˇ´ı sbeˇrnic: rˇ´ıdicı´, adresove´ a datove´). Jesˇteˇ jednodusˇeji lze model popsat jako „CPU + pameˇt’+ sbeˇrnice“, prˇ´ıpadneˇ dalsˇ´ı externı´ zarˇ´ızenı´ prˇipojena´ ke sbeˇrnici. CPU pak by´va´ obvykle implementova´no pomocı´ mikroprocesoru, proto dnes pojmy CPU a mikroprocesor cˇi procesor sply´vajı´. Zastavme se jesˇteˇ kra´tce u vy´sˇe zmı´neˇne´ aritmeticko–logicke´ jednotky (ALU). Je to obvod prova´deˇjı´cı´ aritmeticke´ a logicke´ operace a je pochopitelneˇ za´kladnı´ soucˇa´stı´ prakticky kazˇde´ho CPU. V modernı´ch mikroprocesorech, at’ uzˇ se pouzˇ´ıvajı´ jako CPU nebo v jiny´ch aplikacı´ch, najdeme takovy´ch ALU hned neˇkolik, protozˇe sta´le je to hlavnı´ vy´pocˇetnı´ soucˇa´st mikroprocesoru. Mnoho cˇesky´ch knih uva´dı´ von Neumannu˚v model jako protiklad k harvardske´mu modelu, ktery´ je podobny´, ale pouzˇ´ıva´ dveˇ neza´visle´ pameˇti pro ko´d a data. Za hlavnı´ vlastnost vsˇak musı´me bra´t fakt, zˇe oba modely pouzˇ´ıvajı´ pameˇt’pro ulozˇenı´ programu. Alternativou k tomuto prˇ´ıstupu by bylo ulozˇenı´ programu prˇ´ımo v procesoru, cozˇ se dnes u maly´ch zabudovany´ch pocˇ´ıtacˇu˚ neˇkdy pouzˇ´ıva´, cˇi naopak ulozˇenı´ programu u´plneˇ externeˇ, cozˇ je nejme´neˇ efektivnı´ a pouzˇ´ıvalo se jen u nejstarsˇ´ıch pocˇ´ıtacˇu˚ (z technicky´ch du˚vodu˚).

1.3

Abstrakce hardwaru a architektury

Jak jizˇ bylo rˇecˇeno a uka´za´no, pocˇ´ıtacˇe jsou stroje pro cˇloveˇka pomeˇrneˇ hodneˇ slozˇite´. Zameˇrˇ´ıme-li se na jejich programova´nı´, pak slozˇitost pocˇ´ıtacˇe se projevuje zejme´na tı´m, zˇe CPU zna´ jen velmi jednoduche´ instrukce, jejichzˇ vy´znam je pomeˇrneˇ dosti vzda´len od toho, v jaky´ch pojmech prˇemy´sˇlı´ a vymy´sˇlı´ programy cˇloveˇk–programa´tor. Proto bylo od zacˇa´tku existence pocˇ´ıtacˇu˚ snahou jejich tvu˚rcu˚ umozˇnit co nejvysˇsˇ´ı u´rovenˇ abstrakce, cˇili umozˇnit psa´t programy ve cˇloveˇku srozumitelne´ formeˇ. Ke kazˇde´mu programovacı´mu jazyku pak musı´ existovat prˇekladacˇ cˇi interpret, ktery´ prˇevede program z jeho za´pisu do neˇjake´ho programovacı´ho jazyka na nizˇsˇ´ı u´rovni abstrakce. Na nejnizˇsˇ´ı u´rovni abstrakce je pak samotny´ jazyk pocˇ´ıtacˇe – strojovy´ ko´d, dalsˇ´ı jesˇteˇ nizˇsˇ´ı u´rovneˇ abstrakce jsou pak jizˇ hardwarove´ a programa´toru˚ se nety´kajı´. Operacˇnı´ syste´m je dalsˇ´ım na´strojem abstrakce. Zatı´mco samotny´ (vysˇsˇ´ı) programovacı´ jazyk umozˇnˇuje vytva´ˇret prˇedevsˇ´ım algoritmickou cˇa´st programu˚ v cˇloveˇku prˇijatelneˇjsˇ´ı formeˇ, operacˇnı´ syste´m tvorˇ´ı vrstvu abstrakce prˇedevsˇ´ım pro pra´ci s hardwarovy´mi zarˇ´ızenı´mi, ktera´ jsou mimo CPU (vcˇetneˇ abstrakce pameˇti). Vy´sˇe uvedeny´ prˇ´ıklad s nacˇ´ıta´nı´m souboru˚ z vneˇjsˇ´ıho me´dia hovorˇ´ı za vsˇe. Navı´c operacˇnı´ syste´m umozˇnı´ naprˇ´ıklad abstrahovat fyzicky´ forma´t me´dia, protozˇe at’ uzˇ je zdrojem dat deˇrny´ sˇtı´tek, magneticka´ pa´ska cˇi internet, program operuje 11

CPU je centra´lnı´ procesnı´ jednotka.

s pojmem soubor a trˇemi jednoduchy´mi prˇ´ıkazy otevrˇi–nacˇti–zavrˇi. A pra´veˇ neby´t operacˇnı´ho syste´mu, pojem soubor by neexistoval. Samotny´ operacˇnı´ syste´m samozrˇejmeˇ mu˚zˇe mı´t mnoho podob, v za´vislosti na konkre´tnı´m pocˇ´ıtacˇi. V na´sledujı´cı´ch kapitola´ch se nejprve kra´tce sezna´mı´me se strukturou pocˇ´ıtacˇe z pohledu programa´tora, pak jesˇteˇ strucˇneˇji nahle´dneme do struktury programu˚ a zby´vajı´cı´ kapitoly se budou veˇnovat jednotlivy´m za´kladnı´m skupina´m funkcı´ operacˇnı´ho syste´mu. Operacˇnı´ syste´m je prˇitom nutno cha´pat jako software, ktery´ ma´ dveˇ ru˚zna´ rozhranı´ – jednı´m komunikuje s hardwarovy´mi zarˇ´ızenı´mi (tj. zbytkem pocˇ´ıtacˇe), druhe´ pak nabı´zı´ ostatnı´m programu˚m jako prostrˇedek k daleko jednodusˇsˇ´ı komunikaci mezi sebou navza´jem a zbytkem pocˇ´ıtacˇe. A pra´veˇ toto druhe´ rozhranı´ na´s v kurzu Operacˇnı´ syste´my bude zajı´mat prˇedevsˇ´ım. Shrnutı´ V te´to kra´tke´ u´vodnı´ kapitole jsme se pokusili forma´lneˇ definovat, co je to pocˇ´ıtacˇ, z cˇeho se skla´da´ a na jake´m principu funguje. De facto jsme tedy jen prˇipomneˇli cˇi forma´lneˇ popsali vsˇeobecneˇ zna´ma´ fakta, vcˇetneˇ male´ho oke´nka do historie pocˇ´ıtacˇu˚ a zmı´nky o von Neumannovu modelu, ktery´ popisuje hardwarovou strukturu pocˇ´ıtacˇe. Za´rovenˇ jsme se vsˇak sezna´mili s tı´m, zˇe pocˇ´ıtacˇ nenı´ jen hardwarem, ale i softwarem; klı´cˇovy´m prvkem na cesteˇ k pochopenı´ fungova´nı´ pocˇ´ıtacˇe jako celku je naucˇit se tento stroj vnı´mat na ru˚zny´ch u´rovnı´ch abstrakce. V tomto duchu budeme ve studiu pokracˇovat i v na´sledujı´cı´ch kapitola´ch. Pojmy k zapamatova´nı´ • • • • • • • •

prvnı´, druha´, trˇetı´ a cˇtvrta´ generace pocˇ´ıtacˇu˚ operacˇnı´ syste´m von Neumannu˚v model pocˇ´ıtacˇe abstrakce hardwaru CPU (centra´lnı´ procesnı´ jednotka) operacˇnı´ pameˇt’ sbeˇrnice I/O zarˇ´ızenı´

Kontrolnı´ ota´zky 1. Popisˇte von Neumannu˚v model pocˇ´ıtacˇe. 2. Vysveˇtlete, procˇ je v souvislosti s pocˇ´ıtacˇem pojem abstrakce tak du˚lezˇity´.

12

2

Za´kladnı´ prvky pocˇ´ıtacˇe

Studijnı´ cı´le: Dle von Neumannova modelu jsou za´kladnı´mi prvky pocˇ´ıtacˇe CPU, operacˇnı´ pameˇt’, I/O zarˇ´ızenı´ (a jesˇteˇ sbeˇrnice, ktera´ je propojuje). V te´to kapitole tyto trˇi cˇa´sti podrobneˇji prozkouma´me a udeˇla´me si tak za´klad pro na´sledne´ studium operacˇnı´ch syste´mu˚. Klı´cˇova´ slova: CPU, instrukce, operand, operacˇnı´ pameˇt’, unicode, adresova´nı´, I/O zarˇ´ızenı´ Potrˇebny´ cˇas: 150 minut.

2.1 2.1.1

CPU Procesor a instrukce

Centra´lnı´ procesnı´ jednotku, neboli CPU, intuitivneˇ cha´peme jako nejdu˚lezˇiteˇjsˇ´ı soucˇa´st pocˇ´ıtacˇe. Obvykle ji neforma´lneˇ nazy´va´me „procesor“ nebo „cˇip“, cozˇ je neprˇesne´, ale velmi zazˇite´, takzˇe se toho budeme drzˇet. Pru˚vodce studiem V soucˇasny´ch pocˇ´ıtacˇ´ıch je CPU implementova´na mikroprocesorem, proto se cˇasto mu˚zˇeme setkat se za´meˇnou cˇi sply´va´nı´m teˇchto dvou pojmu˚. Nejbeˇzˇneˇji uzˇ´ıvany´ je pak termı´n „procesor“, ktery´m vyjadrˇujeme, zˇe mluvı´me o CPU implementovane´ pomocı´ mikroprocesoru. Ma´-li pocˇ´ıtacˇ mikroprocesoru˚ vı´c, pojmem „procesor“ se obvykle oznacˇuje pouze CPU, acˇkoliv ostatnı´ mikroprocesory jsou z technicke´ho hlediska ekvivalentnı´ a rovneˇzˇ majı´ pra´vo na termı´n procesor. Stejneˇ tak popula´rnı´, lecˇ neprˇesny´ je termı´n „cˇip“, ktery´ se rovneˇzˇ nespra´vneˇ pouzˇ´ıva´ jako ekvivalent CPU, acˇkoliv cˇipem je ve skutecˇnosti kazˇdy´ integrovany´ obvod.

Procesor ma´ v pocˇ´ıtacˇi prˇesneˇ definovanou u´lohu: Vykona´va´ instrukce ulozˇene´ v operacˇnı´ pameˇti (pokud se omezı´me na von Neumannu˚v model). Kazˇdy´ procesor obsahuje prˇedevsˇ´ım aritmeticko–logickou jednotku (ALU, vykona´va´ aritmeticke´ a logicke´ operace), rˇ´ıdicı´ jednotku (rˇ´ıdı´ chod procesoru) a registry (pameˇt’ove´ bunˇky umı´steˇne´ uvnitrˇ procesoru). Registru˚ je v procesoru obvykle pomeˇrneˇ ma´lo, protozˇe jejich pocˇet ma´ prˇ´ımy´ vliv na slozˇitost a cenu cele´ho cˇipu. Neˇktere´ registry (na jednodusˇsˇ´ıch pocˇ´ıtacˇ´ıch pouze jeden jediny´) pouzˇ´ıva´ ALU pro vy´pocˇty, ostatnı´ pak slouzˇ´ı jako rˇ´ıdicı´. Naprˇ. v registru IP (instruction pointer) je uchova´na aktua´lnı´ ˇ ´ıka´me proto, zˇe IP ukazuje na aktua´lnı´ pozici vykona´va´nı´ propozice vykona´va´nı´ programu. R gramu. Tato hodnota postupneˇ roste, jak beˇzˇ´ı program, a mu˚zˇe se i na´hle zmeˇnit v okamzˇiku, kdy procesor vykona´ neˇkterou rˇ´ıdicı´ instrukci (skok, vola´nı´ podprogramu, cˇi na´vrat z neˇj). Dalsˇ´ım rˇ´ıdicı´m registrem je IR (instruction register), ve ktere´m ma´ procesor uchova´nu pra´veˇ prova´deˇnou instrukci. Jako trˇetı´ prˇ´ıklad uved’me registr SP (stack pointer), ktery´ neusta´le ukazuje na vrchol programove´ho za´sobnı´ku. (Zde uva´deˇna´ jme´na registru˚ jsou jen orientacˇnı´; jednotlivı´ vy´robci procesoru˚ ve skutecˇnosti pouzˇ´ıvajı´ pro stejne´ registry ru˚zna´ jme´na.)

U´lohou CPU je vykona´vat instrukce.

Kazˇdy´ procesor ma´ svou „instrukcˇnı´ sadu“, cozˇ je sada instrukcı´, ktery´m rozumı´. Kazˇda´ instrukce ma´ neˇjaky´ cˇ´ıselny´ ko´d (takto je program ulozˇen v pameˇti) a take´ na´zev (urcˇen pro lidi). Instrukcˇnı´ ko´dy i jejich jme´na jsou v kompetenci jednotlivy´ch vy´robcu˚ procesoru˚, proto mezi nimi najdeme pomeˇrneˇ velke´ rozdı´ly. Kra´tka´ uka´zka ko´du zapsane´ho v instrukcı´ch procesoru typu x86 [Bra94, IA32-1] je na obra´zku 2. Jak je videˇt na uka´zce, instrukce se obvykle zapisujı´ na samostatne´ rˇa´dky. Kazˇda´ instrukce mu˚zˇe mı´t jeden nebo vı´ce operandu˚ (parametru˚), dle smyslu dane´ instrukce. Terminologie je zde trosˇku matoucı´, protozˇe instrukcı´ nazy´va´me jak cely´ rˇa´dek, tak jeho prvnı´ slovo. Instrukce je tedy jak cely´ prˇ´ıkaz pro procesor vcˇetneˇ jeho parametru˚, tak pouze na´zev tohoto prˇ´ıkazu. 13

Operand je parametr instrukce. Instrukce je prˇ´ıkaz pro procesor.

mov eax , p o l e mov ebx , i n d e x mov eax , [ eax +ebx ∗ 4 ] Obra´zek 2: Uka´zka ko´du v Assembleru x86 Dle typu procesoru a instrukce se mu˚zˇeme setkat s ru˚zny´mi kombinacemi pocˇtu vstupnı´ch a vy´stupnı´ch operandu˚. Zatı´mco nejcˇasteˇji pouzˇ´ıvane´ instrukce obvykle majı´ dvojoperandovou podobu, kde druhy´ cˇi oba operandy jsou pouzˇity jako vstupnı´ a prvnı´ operand je vy´stupnı´ (pokud je neˇjaky´ vy´stup). Potrˇebuje-li instrukce dva vstupy a jesˇteˇ neˇkam ulozˇit vy´sledek, prvnı´ operand je vstupnı´ i vy´stupnı´ soucˇasneˇ. Vı´ce nezˇ dva operandy majı´ instrukce jen velmi zrˇ´ıdka, rˇada instrukcı´ naopak ani dva operandy nepotrˇebuje, takzˇe ma´ jen jeden nebo zˇa´dny´. Neˇktere´ hodneˇ slozˇite´ cˇi ma´lo pouzˇ´ıvane´ instrukce fungujı´ pouze s urcˇity´mi registry pro vstup cˇi vy´stup, takzˇe tyto pak rovneˇzˇ majı´ me´neˇ operandu˚, nezˇ bychom mohli cˇekat, nebo dokonce zˇa´dny´. Zda´-li se va´m tento syste´m poneˇkud neprˇehledny´, skutecˇneˇ to tak je. Du˚vodem je, zˇe instrukce jsou prˇ´ımo vykona´va´ny hardwarovy´m cˇipem, cozˇ je technicky velmi slozˇite´, a proto struktura instrukcˇnı´ sady a podporovane´ operandy jsou na veˇtsˇineˇ procesoru˚ neˇjak omezene´. 2.1.2

Vykona´nı´ instrukce

Jednı´m ze sledovany´ch parametru˚ kazˇde´ho procesoru je jeho takt. (Ten byl kdysi uda´va´n v kHz, pozdeˇji v MHz a dnes uzˇ v GHz.) Takt je uda´va´n hodinovy´m krystalem, cozˇ je soucˇa´stka mimo procesor, ktera´ posı´la´ elektricke´ impulzy v pravidelny´ch intervalech a tı´m popoha´nı´ procesor kuprˇedu. Sa´m takt vsˇak nenı´ jediny´m faktorem ovlivnˇujı´cı´m rychlost procesoru, protozˇe vykona´nı´ jedne´ instrukce mu˚zˇe trvat vı´ce nezˇ jeden tik hodin. Pru˚vodce studiem Nejrozsˇ´ırˇeneˇjsˇ´ı rˇada procesoru˚ typu x86 je zna´ma´ tı´m, zˇe jedna instrukce skutecˇneˇ nenı´ provedena v jednom tiku hodin (1T). Extre´mnı´m prˇ´ıkladem jsou trˇeba instrukce pro na´sobenı´ a deˇlenı´, ktere´ na pu˚vodnı´m procesoru Intel 8086 trvaly azˇ 190T, plus dalsˇ´ı cˇas pro deko´dova´nı´ adresy operandu.

Zpracova´nı´ a vykona´nı´ instrukce probı´ha´ v teˇchto krocı´ch: 1. Prˇesun na dalsˇ´ı instrukci 2. Nacˇtenı´ instrukce do CPU – nacˇte se ko´d instrukce z pameˇti 3. Deko´dova´nı´ instrukce – zjistı´ se, co to je za instrukci 4. Vy´pocˇet adres operandu˚ 5. Prˇesun operandu˚ do CPU 6. Vlastnı´ provedenı´ operace 7. Ulozˇenı´ vy´sledku (a potom zpeˇt k bodu 1) Tento seznam 7 kroku˚ je obecny´ a nety´ka´ se zˇa´dne´ho konkre´tnı´ho procesoru, navı´c jednotlive´ kroky mohou by´t vynecha´ny v prˇ´ıpadeˇ, zˇe dana´ konkre´tnı´ instrukce je nepotrˇebuje. Proto take´ i vykona´nı´ stejne´ instrukce mu˚zˇe trvat ru˚zneˇ dlouhou dobu podle toho, jake´ ma´ tato instrukce operandy. Tento model vykona´va´nı´ instrukce v sedmi krocı´ch tedy vlastneˇ rˇ´ıka´, zˇe v CPU je 7 samostatny´ch cˇa´stı´, z nichzˇ kazˇda´ ma´ zcela jinou u´lohu. Prˇitom vzˇdy jedna cˇa´st CPU pracuje a zbyly´ch 6 cˇeka´. 14

Vy´sledek instrukce je v 1. operandu.

Takovy´ model by byl v praxi samozrˇejmeˇ znacˇneˇ neefektivnı´, takzˇe modernı´ procesory jsou navrzˇeny tak, aby co nejvı´c z teˇchto kroku˚ bylo prova´deˇno paralelneˇ (tj. soucˇasneˇ). Naprˇ´ıklad instrukce na Pentiu 4 trvajı´ beˇzˇneˇ 1–3T (dle operandu˚), jelikozˇ kroky 1–4 jsou prova´deˇny v prˇedstihu a trvajı´ 0T (v idea´lnı´m prˇ´ıpadeˇ, tj. „kdyzˇ se to stihne“) a zbyle´ trˇi kroky trvajı´ maxima´lneˇ 1T. Modernı´ procesory majı´ navı´c neˇkolik ALU, ktere´ mohou pracovat soucˇasneˇ (pro programa´tora je to bez pra´ce, nebot’ rˇ´ıdicı´ jednotka sama urcˇuje, kterou instrukci ktera´ ALU zpracuje, registry jsou spolecˇne´ pro cely´ procesor). 2.1.3

Paralelnı´ vykona´va´nı´ instrukcı´

Zatı´mco naprˇ´ıklad kdysi popula´rnı´ 8bitovy´ procesor Zilog Z80 (nejproda´vaneˇjsˇ´ı 8bitovy´ cˇip vsˇech dob) pouzˇ´ıval jednoduchou posloupnost zpracova´nı´ instrukcı´ ve 4 krocı´ch, takzˇe kazˇda´ instrukce trvala 4T nebo na´sobek 4T, u dnesˇnı´ch procesoru˚ je takove´ mrha´nı´ cˇasem teˇzˇko prˇedstavitelne´. Instrukce jsou prova´deˇny paralelneˇ, vy´robci cˇipu˚ k tomu pouzˇ´ıvajı´ celou rˇadu technik. Skutecˇnou rychlost prova´deˇnı´ cely´ch programu˚ tak cˇasto vı´ce nezˇ takt procesoru ovlivnˇuje rychlost pameˇt’ove´ho cˇipu cˇi zpu˚sob, jaky´m prˇekladacˇ programovacı´ho jazyka doka´zˇe seskla´dat instrukce do rˇady za sebou, aby tyto skutecˇneˇ mohly by´t vykona´ny paralelneˇ. Za´kladnı´m modelem paralelnı´ho zpracova´nı´ instrukcı´ je pipelining. Ten funguje tak, zˇe kazˇda´ ze 7 cˇa´stı´ (nasˇeho modelove´ho) CPU po vykona´nı´ sve´ pra´ce na instrukci okamzˇiteˇ prˇecha´zı´ na dalsˇ´ı instrukci. Pipelining v praxi nemusı´ by´t u´plny´, tj. ne kazˇda´ cˇa´st CPU toto musı´ podporovat. Pokud u´plny´ je, dostaneme se teoreticky azˇ k situaci, zˇe v kazˇde´m tiku hodin se zacˇne zpracova´vat dalsˇ´ı instrukce. Toto je samozrˇejmeˇ omezeno tı´m, zˇe vlastnı´ vykona´nı´ instrukce nemusı´ trvat pouze 1T (viz prˇ´ıklad na´sobenı´ a deˇlenı´ vy´sˇe). Dalsˇ´ım omezujı´cı´m faktorem pipeliningu jsou situace, kdy jedna instrukce za´visı´ na druhe´. Za´kladnı´m prˇ´ıkladem je, kdyzˇ vstupnı´m parametrem instrukce je vy´sledek z prˇ´ımo prˇedchozı´ cˇi neˇktere´ blı´zke´ prˇedchozı´ instrukce. V takove´m prˇ´ıpadeˇ je nutno zajistit, aby instrukce „neprˇedbı´haly“, tj. aby pozdeˇjsˇ´ı instrukce nezacˇala drˇ´ıve, nezˇ vsˇechny ty, na ktery´ch za´visı´, byly hotove´. Procesory x86 majı´ tuto situaci osˇetrˇenou hardwaroveˇ, navenek se tedy vsˇe chova´ tak, jakoby pipelining zaveden nebyl (k „prˇedbı´ha´nı´ “ instrukcı´ a chyba´m prˇi vy´pocˇtu tedy nedocha´zı´). Jine´ procesory ale mohou mı´t trˇeba jiny´ pameˇt’ovy´ model (naprˇ. Intel Itanium 2), ktery´ se projevuje pra´veˇ chybny´m chova´nı´m prˇi pipeliningu. Prakticke´ zkusˇenosti s teˇmito procesory uka´zaly, zˇe osˇetrˇenı´ prˇedbı´ha´nı´ instrukcı´ v prˇekladacˇ´ıch programovacı´ch jazyku˚ je te´meˇrˇ nerˇesˇitelny´ proble´m; tento model se tedy v praxi prˇ´ılisˇ neosveˇdcˇil. I kdyzˇ procesor sa´m osˇetrˇ´ı, aby nedosˇlo k prˇedbı´ha´nı´ instrukcı´, jejich vza´jemna´ za´vislost zpu˚sobı´, zˇe pipelining neprˇinese zˇa´dne´ zrychlenı´ vy´pocˇtu. Extre´mem jsou zde instrukce podmı´neˇny´ch skoku˚ – velmi cˇasto pouzˇ´ıvane´ instrukce, pomocı´ nichzˇ je obvykle implementova´no veˇtvenı´ programu (prˇ´ıkaz if apod.). Tyto instrukce mohou zmeˇnit adresu vykona´va´nı´ ko´du podle toho, jaky´ je vy´sledek neˇktere´ prˇedchozı´ instrukce. Vsˇechny instrukce na´sledujı´cı´ za instrukcı´ podmı´neˇne´ho skoku na nı´ tedy prˇ´ımo za´visı´, protozˇe dokud nenı´ skokova´ podmı´nka vyhodnocena, nevı´me vlastneˇ, zda na´sledujı´cı´ instrukce se vu˚bec majı´ vykona´vat. Skokove´ instrukce tedy zpu˚sobujı´ u´plne´ zastavenı´ pipeliningu a jsou nejme´neˇ efektivnı´mi instrukcemi z hlediska mozˇne´ho paralelnı´ho beˇhu procesoru. Pru˚vodce studiem Prvnı´m procesorem rˇady x86, ktery´ pouzˇ´ıval pipelining, byl i486dx. Tento procesor zpracova´val instrukce v 5 krocı´ch, ktere´ mohly beˇzˇet soucˇasneˇ. Navı´c jednotky deko´dova´nı´ instrukce meˇl hned dveˇ. I prˇes pomeˇrneˇ cˇerneˇ vylı´cˇene´ chova´nı´ u instrukcı´ podmı´neˇny´ch skoku˚ doka´zal tento procesor dı´ky pipeliningu na 25MHz pracovat rychleji nezˇ Intel 386dx na 40MHz.

15

Pipelining je za´kladnı´ formou paralelizmu.

Dalsˇ´ım modelem umozˇnˇujı´cı´m paralelnı´ vykona´va´nı´ instrukcı´ v jednom procesoru je superskala´rnı´ architektura. Ta se v beˇzˇny´ch pocˇ´ıtacˇ´ıch objevila s procesorem Intel Pentium. Tyto procesory (a take´ vsˇechny na´sledujı´cı´ modely rˇady x86) obsahujı´ vı´ce nezˇ jednu ALU. Procesor tak mu˚zˇe zpracova´vat dveˇ nebo vı´ce instrukcı´ soucˇasneˇ, podobneˇ jako prˇi pipeliningu. Obsazˇenı´ dvou ALU take´ umozˇnˇuje sofistikovaneˇjsˇ´ı chova´nı´ u podmı´neˇny´ch skoku˚ – kazˇda´ ALU jde jinou cestou (protozˇe podmı´nka zcela jisteˇ bud’ platı´, nebo neplatı´). Kazˇda´ z ALU jednotek tak vlastneˇ vykona´va´ doprˇedu neˇjaky´ ko´d, anizˇ tusˇ´ı, zda to nedeˇla´ zbytecˇneˇ. V okamzˇiku vyhodnocenı´ podmı´nky je jedna z ALU vynulova´na, zatı´mco druha´ mezitı´m vyuzˇila cˇas produktivneˇ a vykonala cˇa´st programu doprˇedu. Tı´m je procesor jesˇteˇ rychlejsˇ´ı nezˇ prˇi pipeliningu. Pru˚vodce studiem Superskala´rnı´ architektura dnesˇnı´ch procesoru˚ zpu˚sobuje, zˇe u neˇktery´ch programu˚ je skutecˇna´ rychlost vykona´va´nı´ instrukcı´ vysˇsˇ´ı nezˇ takt procesoru. Pru˚meˇrny´ cˇas potrˇebny´ pro vykona´nı´ jedne´ instrukce je tedy me´neˇ nezˇ 1T, cˇasto i docela vy´razneˇ. Ma´-li procesor vı´ce nezˇ dveˇ ALU, pak rozdeˇlenı´ na dveˇ alternativnı´ veˇtve u podmı´neˇne´ho skoku nenı´ zrovna optima´lnı´m vyuzˇitı´m prostrˇedku˚ procesoru. Proto jsou vyuzˇ´ıva´ny i jine´ techniky k optimalizaci skoku˚. Prˇedvı´da´nı´ veˇtvı´ (branch prediction) je technika prˇedvı´da´nı´, zda dana´ podmı´nka bude, cˇi nebude platit. Neˇktere´ procesory toto deˇlajı´ staticky, cˇili u kazˇde´ instrukce podmı´neˇne´ho skoku je da´no, kterou variantu (platnost/neplatnost podmı´nky) uprˇednostnˇuje. Prˇekladacˇe vysˇsˇ´ıch jazyku˚ s tı´m pak mohou pocˇ´ıtat a skla´dat podle toho instrukce. Dokonalejsˇ´ı procesory umeˇjı´ i dynamicke´ prˇedvı´da´nı´, ktere´ je velmi vhodne´ u cyklu˚ (konstrukce typu for, while apod.). Takovy´ procesor si totizˇ u neˇkolika poslednı´ch podmı´neˇny´ch skoku˚ pamatuje, zda jejich podmı´nky byly cˇi nebyly splneˇny, a pokud se dostane na stejne´ mı´sto programu (drˇ´ıve nezˇ tuto zkusˇenostnı´ informaci zapomene), chova´ se dle prˇedchozı´ zkusˇenosti. Pra´veˇ pro beˇzˇne´ konstrukce cyklu˚ je toto velmi vy´hodne´ (splete se jen jednou nebo dvakra´t – mozˇna´ prˇi prvnı´m a urcˇiteˇ prˇi poslednı´m pru˚chodu cyklem). 2.1.4

Instrukcˇnı´ sada

Z hlediska instrukcˇnı´ sady rozlisˇujeme dva za´kladnı´ typy procesoru˚: CISC (complex instruction set computer) obsahuje tzv. u´plnou sadu instrukcı´. Jedna´ se o slozˇite´ procesory nabı´zejı´cı´ velke´ mnozˇstvı´ instrukcı´ a beˇzˇne´ operace umeˇjı´ take´ prova´deˇt prˇ´ımo v operacˇnı´ pameˇti. Instrukce v teˇchto procesorech cˇasto prˇ´ımo podporujı´ operace prova´deˇne´ vysˇsˇ´ımi programovacı´mi jazyky (pra´ce se za´sobnı´kem, loka´lnı´mi promeˇnny´mi, funkcemi apod.). Vykona´nı´ jedne´ instrukce obvykle trva´ de´le nezˇ 1T. Prˇ´ıkladem CISC procesoru je rˇada x86, x64 nebo take´ vy´sˇe zmı´neˇny´ Z80.

CISC procesor ma´ u´plnou sadu instrukcı´.

RISC (reduced instruction set computer) vycha´zı´ z teze, zˇe stejne´ho vy´sledku lze dosa´hnout take´ pomocı´ posloupnosti jednoduchy´ch instrukcı´. Tyto procesory majı´ jen za´kladnı´ sadu instrukcı´, jejich design a vy´roba je tedy jednodusˇsˇ´ı. Vykona´nı´ jedne´ instrukce trva´ 1T. Prˇ´ıkladem RISC procesoru je PowerPC (pouzˇ´ıvajı´ naprˇ. starsˇ´ı modely Macintosh a rˇada hernı´ch konzolı´).

RISC procesor ma´ redukovanou sadu instrukcı´.

Klasicke´ pocˇ´ıtacˇe PC pouzˇ´ıvajı´ procesory rˇady x86, tedy typu CISC. Obrovska´ slozˇitost modernı´ch procesoru˚ rˇady x86 vsˇak prˇimeˇla jejich vy´robce, aby prˇesˇli na RISC technologii. Vsˇechny dnesˇnı´ x86 procesory jsou tedy ve skutecˇnosti RISC procesory, ktere´ simulujı´ slozˇiteˇjsˇ´ı instrukce pomocı´ zabudovany´ch mikroprogramu˚, cˇ´ımzˇ se navenek tva´rˇ´ı jako CISC. Starsˇ´ı procesory by´valy programova´ny prˇ´ımo, tedy pomocı´ procesorovy´ch instrukcı´ ve strojove´m ko´du cˇi assembleru. Aby programova´nı´ bylo jednodusˇsˇ´ı, vy´robci procesoru˚ se tehdy snazˇili implementovat co nejveˇtsˇ´ı funkcionalitu prˇ´ımo do jedine´ instrukce. Tı´m se taky sˇetrˇila tehdy velmi draha´ a pomala´ pameˇt’– kdyzˇ byly instrukce chytrˇejsˇ´ı, programy mohly by´t kratsˇ´ı. 16

Dnes je vsˇak situace zcela odlisˇna´. Pameˇt’ove´ cˇipy jsou pomeˇrneˇ levne´ a rychle´, takzˇe na velikosti programu˚ azˇ tak neza´lezˇ´ı, a implementace neˇktery´ch modernı´ch technik paralelnı´ho zpracova´nı´ instrukcı´ u CISC procesoru˚ je technicky velmi obtı´zˇna´ z du˚vodu jejich slozˇitosti. Navı´c se dnes pouzˇ´ıvajı´ te´meˇrˇ vy´hradneˇ vysˇsˇ´ı programovacı´ jazyky, jejichzˇ prˇekladacˇe si obvykle vystacˇ´ı ˇ ada CISC instrukcı´ je dnes v procesorech tedy vlastneˇ zbytecˇneˇ. s neˇkolika ma´lo instrukcemi. R Z toho du˚vodu dnes jednoznacˇneˇ „vı´teˇzı´“ RISC model.

2.2

Operacˇnı´ pameˇt’

Druhou vy´znamnou soucˇa´stı´ pocˇ´ıtacˇu˚ je pameˇt’. Vy´znam pameˇti je zcela jasny´: Pocˇ´ıtacˇ si v nı´ pamatuje data, cˇasto navı´c i program. Pameˇti by´va´ zvykem deˇlit na vnitrˇnı´ a vneˇjsˇ´ı. Operacˇnı´ pameˇt’ je pameˇtı´ vnitrˇnı´, zatı´mco naprˇ´ıklad hard disk je pameˇtı´ vneˇjsˇ´ı. Nejoblı´beneˇjsˇ´ı jsou pak obecneˇ pameˇti, ktere´ procesoru umozˇnˇujı´ data zapisovat i cˇ´ıst, protozˇe vyuzˇitelnost pameˇtı´ jen pro cˇtenı´ je samozrˇejmeˇ omezena´. Zarˇ´ızenı´, ktera´ naopak data umeˇjı´ jen zapisovat (tiska´rny apod.) obvykle za pameˇti nepovazˇujeme. Podobneˇ jako u procesoru˚, i u pameˇti se velmi cˇasto pouzˇ´ıva´ terminologie, ktera´ je velmi zazˇita´, lecˇ chybna´. Spra´vneˇ bychom totizˇ meˇli vzˇdy hovorˇit o operacˇnı´ pameˇti, protozˇe existujı´ i jine´ druhy pameˇtı´, v praxi se vsˇak prˇi vyslovenı´ jednoduche´ho „pameˇt’“ obvykle myslı´ pra´veˇ pameˇt’ operacˇnı´. Zu˚staneme tedy u tohoto jednoduche´ho termı´nu, budeme prˇitom vzˇdy mı´t na mysli operacˇnı´ pameˇt’z von Neumannova modelu pocˇ´ıtacˇe. 2.2.1

Ulozˇenı´ cˇ´ısel v pocˇ´ıtacˇi

Cˇ´ısla jsou za´kladnı´m typem informace, ktery´ v pocˇ´ıtacˇi uchova´va´me. Ke zpracova´nı´ cˇ´ısel ostatneˇ byly pocˇ´ıtacˇe pu˚vodneˇ vytvorˇeny. Jelikozˇ pameˇt’ ma´ podobu rˇady bitu˚, je zrˇejme´, zˇe ulozˇenı´ u´plneˇ libovolne´ho cˇ´ısla do takove´ formy nenı´ mozˇne´. At’uzˇ chceme ukla´dat pouze cˇ´ısla cela´, nebo i raciona´lnı´ cˇi rea´lna´, jsme vzˇdy neˇjak omezeni. Stejna´ omezenı´ pak majı´ dopad i na aritmeticke´ operace – je-li totizˇ samotne´ ulozˇenı´ cˇ´ısel omezeno, pak i operace s teˇmito cˇ´ısly mohou by´t teˇmito omezenı´mi postizˇeny. Nejjednodusˇsˇ´ı situace je u prvneˇ zmı´neˇny´ch cely´ch cˇ´ısel. Pameˇt’doka´zˇe uchovat libovolne´ cele´ cˇ´ıslo, kladne´ i za´porne´, jehozˇ velikost neprˇesahuje urcˇitou mez. Vı´me, zˇe do 1 bajtu se vejdou cˇ´ısla v rozsahu 0 azˇ 255 (cˇi -128 azˇ +127), atd. Naprosta´ veˇtsˇina procesoru˚ pouzˇ´ıva´ doplnˇkovy´ ko´d, dı´ky ktere´mu rˇada aritmeticky´ch operacı´ mu˚zˇe by´t prova´deˇna bez ohledu na to, zda je cˇ´ıslo kladne´ cˇi za´porne´, a na to, zda samotny´ datovy´ typ je zname´nkovy´ nebo nezname´nkovy´. Doplnˇkovy´ ko´d jizˇ zna´te z drˇ´ıveˇjsˇ´ıho studia, prˇipomenˇme jen, zˇe zmeˇnu zname´nka u cˇ´ısla provedeme tak, zˇe prˇevra´tı´me hodnoty vsˇech jeho bitu˚ a prˇicˇteme k neˇmu jednicˇku. (Pro procvicˇenı´ si dokazˇte!) Dveˇ meznı´ situace, ktere´ mohou nastat u cely´ch cˇ´ısel, jsou prˇetecˇenı´ a podtecˇenı´. Prˇetecˇenı´ nasta´va´, je-li vy´sledek veˇtsˇ´ı nezˇ maxima´lnı´ hodnota ulozˇitelna´ do pameˇti. V takove´m prˇ´ıpadeˇ hodnota v pameˇti takzvaneˇ „prˇetecˇe“ a na´sledujı´cı´ hodnotou za nejveˇtsˇ´ı mozˇnou je nejmensˇ´ı mozˇna´. U scˇ´ıta´nı´ mu˚zˇe prˇi jednom secˇtenı´ dvou cˇ´ısel prˇete´ct hodnota jen jednou, zatı´mco u na´sobenı´ mu˚zˇe prˇete´ct hodnota mnohokra´t. (Naprˇ. 129*128 = 16512, ale v bajtu bude hodnota 128.) Podtecˇenı´ je opacˇna´ situace, kdy vy´sledek je mensˇ´ı nezˇ nejmensˇ´ı mozˇna´ hodnota. Chova´nı´ prˇetecˇenı´ a podtecˇenı´ je zcela stejne´. Pru˚vodce studiem Matematicky funguje prˇetecˇenı´ a podtecˇenı´ tak, zˇe ze skutecˇne´ho vy´sledku se zachova´ jen tolik nejnizˇsˇ´ıch bitu˚, kolik se vejde do pameˇti. Vy´sˇe uvedeny´ prˇ´ıklad 129*128 mu˚zˇeme pro

17

Doplnˇkovy´ ko´d umozˇnˇuje snadnou pra´ci se za´porny´mi cˇ´ısly.

uka´zku zapsat v sˇestna´ctkove´ soustaveˇ, kde kazˇde´mu bajtu odpovı´dajı´ prˇesneˇ dveˇ cifry: 81*80 = 4080, do jednoho bajtu se tedy vejde sˇestna´ctkove´ cˇ´ıslo 80, cozˇ je v desı´tkove´ soustaveˇ pra´veˇ 128. Tı´mto zpu˚sobem funguje prˇetecˇenı´ i podtecˇenı´ a to pro kladna´ i za´porna´ cˇ´ısla. Prˇetecˇenı´ a podtecˇenı´ je jednou z nejdu˚lezˇiteˇjsˇ´ıch uda´lostı´, ktera´ mu˚zˇe prˇi beˇhu nastat, proto je pro jejich zpracova´nı´ vyhrazen specia´lnı´ bit v jednom registru. Tento registr se na x86 jmenuje eflags, samotny´ bit je pak na veˇtsˇineˇ procesoru˚ oznacˇen jako carry, cˇi zkratkou CY, CF nebo C. Prˇi u´plneˇ kazˇde´ aritmeticke´ operaci se CY nastavı´ na nulu, pokud k prˇetecˇenı´/podtecˇenı´ nedosˇlo, cˇi na jednicˇku, pokud k prˇetecˇenı´/podtecˇenı´ dosˇlo. Tato hodnota zu˚sta´va´ v CY tak dlouho, nezˇ ji jina´ aritmeticka´ operace prˇepı´sˇe. U vı´cebajtovy´ch cˇ´ısel (tj. teˇch, ktere´ v pameˇti zabı´rajı´ vı´ce nezˇ jeden bajt) existuje neˇkolik variant, jak je do pameˇti ulozˇit. Kazˇdy´ procesor bohuzˇel pouzˇ´ıva´ jiny´ prˇ´ıstup. Je v za´sadeˇ neˇkolik mozˇny´ch variant: Big endian syste´m ukla´da´ cˇ´ısla od nejvysˇsˇ´ıch rˇa´du˚ po nejnizˇsˇ´ı. Tento syste´m tedy odpovı´da´ nasˇem zpu˚sobu za´pisu cˇ´ısla (de facto pozpa´tku, protozˇe cˇ´ıslo „roste“ doleva). Naprˇ. cˇ´ıslo ABCD v sˇestna´ctkove´ soustaveˇ je ulozˇeno jako AB CD, cˇ´ıslo 1 je ulozˇeno ve 4bajtove´m za´pisu jako 00 00 00 01, cˇ´ıslo 65536 je cˇtyrˇbajtoveˇ ulozˇeno jako 00 01 00 00. Tento zpu˚sob pouzˇ´ıvajı´ naprˇ. procesory Motorola 68k.

Big endian ukla´da´ cˇ´ısla od nejvysˇsˇ´ıch rˇa´du˚ po nejnizˇsˇ´ı.

Little endian syste´m ukla´da´ cˇ´ısla od nejnizˇsˇ´ıho rˇa´du po nejvysˇsˇ´ı. Vy´hodou je, zˇe prˇi takove´m za´pisu mu˚zˇeme cˇ´ıslo zveˇtsˇovat bez zmeˇny adresy. Naprˇ. cˇ´ıslo ABCD v sˇestna´ctkove´ soustaveˇ je ulozˇeno jako CD AB, cˇ´ıslo 1 je ulozˇeno ve 4bajtove´m za´pisu jako 01 00 00 00, cˇ´ıslo 65536 je cˇtyrˇbajtoveˇ ulozˇeno jako 00 00 01 00. Tento zpu˚sob pouzˇ´ıvajı´ procesory rˇady x86, Z80 aj.

Little endian ukla´da´ cˇ´ısla od nejnizˇsˇ´ıch rˇa´du˚ po nejvysˇsˇ´ı.

Bi–endian je oznacˇenı´ pro procesory podporujı´cı´ oba vy´sˇe uvedene´ syste´my. Prˇ´ıkladem je Intel rˇady IA64, PowerPC aj. Middle endian je oznacˇenı´ pro procesory pouzˇ´ıvajı´cı´ jine´ zvla´sˇtnı´ rˇazenı´ bajtu˚ u cˇ´ısel. Pru˚vodce studiem Na´zvy little a big endian pocha´zejı´ z roma´nu Guliverovy cesty, kde dva na´rody vedou nesmirˇitelny´ boj o to, na ktere´ sˇpicˇce se ma´ natloukat vajı´cˇko. Stejneˇ jako u vajı´cˇka, i u procesoru˚ je ve skutecˇnosti samozrˇejmeˇ zcela jedno, ktery´ syste´m pouzˇijeme, objektivneˇ jsou oba stejneˇ dobre´. Domluva na syste´mu za´pisu cely´ch cˇ´ısel je vsˇak velmi du˚lezˇita´ prˇi prˇenosu dat (komunikaci) mezi ru˚zny´mi syste´my (naprˇ. v internetu).

Pru˚vodce studiem Z nasˇeho lidske´ho hlediska je u „endianu˚“ videˇt jeden paradox. Anizˇ bychom si to neˇjak hloubeˇji uveˇdomovali, jelikozˇ pouzˇ´ıva´me arabska´ cˇ´ısla a pı´smo pı´sˇeme zleva doprava, prˇirozeny´ forma´t za´znamu cˇ´ısel je pro na´s big endian. Jenzˇe Arabove´ pı´sˇ´ı zprava doleva a pochopitelneˇ pouzˇ´ıvajı´ stejny´ za´pis cˇ´ısel, tj. tenty´zˇ za´pis je pro neˇ little endian. Tento paradox vznikl tı´m, zˇe jsme prˇevzali arabska´ cˇ´ısla a naucˇili se je psa´t pozpa´tku, prˇestozˇe to je poneˇkud me´neˇ komfortnı´.

Dalsˇ´ım typem cˇ´ısel, se ktery´mi procesor umı´ pracovat, jsou tzv. BCD cˇ´ısla (binary coded decimal). Jedna´ se o ma´lo pouzˇ´ıvanou formu cˇ´ısel, ktera´ je pozu˚statkem z da´vny´ch dob, kdy mikroprocesory byly urcˇeny prˇedevsˇ´ım pro matematicke´ kalkula´tory (kalkulacˇky). Kazˇde´ 4 bity 18

zde uchova´vajı´ jednu desı´tkovou cifru. V bajtu jsou tedy dveˇ desı´tkove´ cifry – tento za´pis je dosti neefektivnı´, ale odpovı´da´ zpu˚sobu, jaky´m fungujı´ kalkulacˇky. Vysˇsˇ´ı programovacı´ jazyky BCD nepouzˇ´ıvajı´ vu˚bec. Trˇetı´m zpu˚sobem ulozˇenı´ cˇ´ısel v pocˇ´ıtacˇi jsou cˇ´ısla v plovoucı´ rˇa´dove´ cˇa´rce (FP, floating point numbers). Obvykle se jim chybneˇ rˇ´ıka´ rea´lna´, i kdyzˇ jde pouze o cˇ´ısla raciona´lnı´. (Onen spra´vny´ termı´n se neujal prˇedevsˇ´ım z toho du˚vodu, zˇe je prˇece jen poneˇkud dlouhy´.) FP–cˇ´ısla jsou opeˇt ulozˇena v neˇkolika bitech, v praxi nejcˇasteˇji zabı´rajı´ 8 bajtu˚, prˇ´ıpadneˇ 4 bajty. Do teˇchto 8 cˇi 4 bajtu˚ jsou zako´dova´ny 3 cˇa´sti cˇ´ısla: zname´nko (1 bit), mantisa (52 cˇi 23 bitu˚) a exponent (zbytek, cˇili 11 cˇi 8 bitu˚). Toto ko´dova´nı´ je nasˇteˇstı´ unifikova´no (je jednotne´ pro ru˚zne´ typy procesoru˚). Skutecˇna´ hodnota cˇ´ısla se vypocˇte takto: hodnota = znaménko ∗ mantisa ∗ základ exponent

FP cˇ´ısla jsou na vsˇech pocˇ´ıtacˇ´ıch ulozˇena stejneˇ.

kde exponent mu˚zˇe by´t kladny´ i za´porny´ a za´kladem by´va´ obvykle 2, vy´jimecˇneˇ i 10. Tento zpu˚sob reprezentace cˇ´ısel je pomeˇrneˇ prakticky´, nebot’ bez ohledu na velikost cˇ´ısla je vzˇdy zarucˇena prˇesnost na urcˇity´ pocˇet rˇa´du˚. Hardwaroveˇ nejefektivneˇjsˇ´ı je, aby za´kladem byla dvojka (rˇada operacı´ se pak hardwaroveˇ jednodusˇe implementuje); nevy´hodou tohoto rˇesˇenı´ vsˇak je, zˇe neˇktera´ beˇzˇna´ cˇ´ısla nelze ulozˇit zcela prˇesneˇ (naprˇ. cˇ´ıslo 0.1). Za´klad 10 se pouzˇ´ıva´ jen vy´jimecˇneˇ a nenı´ podporova´n hardwaroveˇ. U FP cˇ´ısel ma´ take´ jiny´ vy´znam podtecˇenı´ – hovorˇ´ıme o neˇm tehdy, kdyzˇ je hodnota (bez ohledu na zname´nko) mezi nulou a nejmensˇ´ım zobrazitelny´m nenulovy´m cˇ´ıslem. Prˇetecˇenı´ je situace, kdy je cˇ´ıslo (bez ohledu na zname´nko) naopak veˇtsˇ´ı nezˇ nejveˇtsˇ´ı zobrazitelne´ cˇ´ıslo. 2.2.2

Ulozˇenı´ znaku˚ v pameˇti

Ulozˇenı´ znaku˚ v pocˇ´ıtacˇi je poneˇkud jednodusˇsˇ´ı nezˇ v prˇ´ıpadeˇ cˇ´ısel. Historicky se nejvı´ce rozsˇ´ırˇil model pouzˇ´ıvajı´cı´ 7bitove´ ko´dova´nı´ ASCII. Do jednoho bajtu se tak vejde pra´veˇ jeden znak (americke´ abecedy). Tento model vznikl pu˚vodneˇ pro telegrafy, kde nejvysˇsˇ´ı bit byl vyuzˇit pro kontrolnı´ soucˇet (CRC). Na pocˇ´ıtacˇ´ıch vsˇak byl tento prostor vyuzˇit pro na´rodnı´ abecedy (naprˇ. nasˇe cˇeske´ znaky se do 7 bitu˚ nevejdou), nehovorˇ´ıme pak vsˇak jizˇ o ASCII.

ASCII je 7bitovy´ ko´d pro americkou anglicˇtinu.

Osmibitovy´ch ko´dova´nı´ znaku˚ existuje cela´ rˇada, dokonce i pro cˇesˇtinu jich vzniklo pomeˇrneˇ hodneˇ. Tato nejednotnost je samozrˇejmeˇ nesˇt’astna´, dokonce ani Windows, Linux a Macintosh nedoka´zaly pouzˇ´ıt jednotne´ ko´dova´nı´. (Windows a Linux se dokonce lisˇ´ı jen u trˇ´ı pı´smen, cozˇ je azˇ humorne´.) Zatı´mco MS-DOS dlouha´ le´ta pouzˇ´ıval ko´dova´nı´ CP852 (Latin 2), rˇada cˇesky´ch programu˚ da´vala prˇednost ko´dova´nı´ KEYBCS2 (CP895), ktere´ obsahovalo kromeˇ cˇesˇtiny i znaky pro ra´mecˇky. Windows pak prˇisˇlo s ko´dem CP1250, ktery´ je vzhledem k rozsˇ´ırˇenı´ Windows dnes nejrozsˇ´ırˇeneˇjsˇ´ı, ale zpeˇt do DOSu se nikdy neprosadil. Linux pak pouzˇ´ıva´ ISO-8859-2, cozˇ je de jure standard, ovsˇem vnuceny´ na´m z USA. A Macintosh ma´ dalsˇ´ı jine´ ko´dova´nı´. (Podobneˇ jsou na tom i ostatnı´ pocˇ´ıtacˇe – kazˇdy´ pes, jina´ ves.) Nevy´hodu teˇchto 8bitovy´ch ko´dova´nı´ rˇesˇ´ı Unicode – jednotny´ sveˇtovy´ ko´d spolecˇny´ pro vsˇechny na´rodnı´ abecedy. Kazˇdy´ znak v Unicode meˇl pu˚vodneˇ 2 bajty, pozdeˇji se prˇesˇlo na 4 bajty. Znaky vsˇech na´rodnı´ch abeced se vsˇak vesˇly jizˇ do oneˇch prvnı´ch dvou bajtu˚, proto se v praxi neˇktere´ syste´my omezujı´ na 2bajtove´ znaky Unicode. Windows cˇi Java pouzˇ´ıvajı´ ko´dova´nı´ UTF-16, kde veˇtsˇina znaku˚ ma´ 2 bajty (prvnı´ dva bajty Unicode) a pouze v nutny´ch prˇ´ıpadech jsou znaky delsˇ´ı. Prvnı´ch 256 znaku˚ je zde stejny´ch jako v ko´du ISO-8859-1 (za´padnı´ latinka). Do souboru˚ se Unicode obvykle ukla´da´ v ko´du UTF-8, kde znaky ASCII majı´ 1 bajt a ostatnı´ znaky majı´ 2 azˇ 4 bajty (pro cˇesˇtinu vzˇdy dva bajty). Existuje jesˇteˇ neˇkolik dalsˇ´ıch ko´dova´nı´ pro Unicode (naprˇ. 7bitove´ UTF-7), ty se ale te´meˇrˇ nepouzˇ´ıvajı´.

19

Unicode je jednotny´ ko´d pro vsˇechny sveˇtove´ jazyky.

Pru˚vodce studiem Zajı´mavostı´ Unicode je, zˇe neˇktere´ znaky jsou v tomto ko´du vı´cekra´t. Chceme-li pak trˇeba zjistit, zda jsou dva rˇeteˇzce stejne´, je trˇeba nejprve prove´st tzv. normalizaci, kdy se vsˇechny vy´skyty teˇchto znaku˚ sjednotı´ na stejne´ cˇ´ıslo. Pak je mozˇno prove´st porovna´nı´ klasicky´m zpu˚sobem.

2.2.3

Adresova´nı´ pameˇti

Operacˇnı´ pameˇt’ je linea´rnı´ struktura s pevnou de´lkou a na´hodny´m prˇ´ıstupem (cˇili je to tote´zˇ jako „pole“ ve vysˇsˇ´ıch programovacı´ch jazycı´ch). Pojem na´hodny´ prˇ´ıstup znamena´, zˇe procesor mu˚zˇe cˇ´ıst a zapisovat libovolne´ pameˇt’ove´ bunˇky. Acˇkoliv fyzicky mı´vajı´ ru˚zne´ typy pameˇtı´ bunˇky rozlicˇny´ch velikostı´, z hlediska softwarove´ho se ujal jednotny´ model pouzˇ´ıvajı´cı´ „bajt“ – kazˇda´ pameˇt’ova´ bunˇka tedy ma´ velikost jednoho bajtu (8 bitu˚). Urcˇenı´, se kterou bunˇkou chce procesor pracovat, rˇ´ıka´me adresace pameˇti. Kazˇda´ bunˇka pameˇti ma´ tedy svou adresu, cozˇ je cˇ´ıslo v rozsahu 0 azˇ velikost pameˇti–1.

Pameˇt’je jako jedno velke´ pole bajtu˚.

Tento jednoduchy´ a tradicˇnı´ zpu˚sob organizace pameˇti nazy´va´me linea´rnı´ (l. adresova´nı´, l. adresa, atp.). Je vsˇak nevhodny´, nebot’ neumozˇnˇuje jednoduchy´ prˇenos dat cˇi ko´du programu na jine´ mı´sto v pameˇti – prˇi prˇemı´steˇnı´ se totizˇ meˇnı´ adresy. At’ uzˇ prˇemı´stı´me ko´d, cˇi data, musı´me softwaroveˇ prˇepocˇ´ıtat vsˇechny adresy. Veˇtsˇina soucˇasny´ch procesoru˚ umozˇnˇuje i neˇjaky´ jiny´ adresovacı´ rezˇim nezˇ linea´rnı´. Stacˇ´ı prˇitom rozdeˇlit linea´rnı´ adresu na dveˇ slozˇky: ba´zi a posunutı´. Ba´ze urcˇuje zacˇa´tek programu cˇi dat, posunutı´ pak relativnı´ adresu vzhledem k ba´zi. Procesory rˇady x86 majı´ tento princip implementova´n pomocı´ tzv. segmentove´ho adresova´nı´, kde se adresa vypocˇ´ıta´ jako segment + offset.1 Na 16bitovy´ch procesorech ma´ kazˇda´ z teˇchto dvou slozˇek 16 bitu˚, cela´ adresa ma´ tedy 32 bitu˚. (Takove´ 32bitove´ adrese se rˇ´ıka´ far pointer (vzda´leny´ pointer). Opakem je 16bitovy´ near pointer, cozˇ je pouze offset bez urcˇenı´ segmentu.) Prˇevod na linea´rnı´ adresu je proveden jednoduchy´m vzorcem lineární adresa = (segment << 4) + of f set Segment je tedy posunut o 4 bity a secˇten s offsetem. Celkoveˇ tedy mu˚zˇeme adresovat (jen) 20 bitu˚, cˇili 1MB pameˇti. (Tento zpu˚sob adresace pouzˇ´ıva´ syste´m MS-DOS. Cˇa´st pameˇti vyuzˇ´ıva´ syste´m, proto je velikost rea´lneˇ vyuzˇitelne´ pameˇti obvykle me´neˇ nezˇ 640KB.) Noveˇjsˇ´ı procesory x86 pak umozˇnˇujı´ jesˇteˇ dalsˇ´ı adresovacı´ rezˇimy. K podrobneˇjsˇ´ımu popisu adresova´nı´ se dostaneme pozdeˇji, v kapitole o spra´veˇ pameˇti v operacˇnı´m syste´mu. Nynı´ se proto jen sezna´mı´me se za´kladnı´m principem. Adresova´nı´ ve 32bitove´m rezˇimu procesoru˚ x86 pouzˇ´ıva´ opeˇt dveˇ slozˇky: selektor + offset. Selektor ma´ 16 bitu˚ a je to ukazatel do tabulky deskriptoru˚. Kazˇdy´ deskriptor je za´znam v tabulce, ktery´ popisuje neˇjaky´ segment. (Deskriptor popisuje segment. Selektor jej vybı´ra´.) Tı´mto zpu˚sobem je umozˇneˇno, aby programy pouzˇ´ıvaly sta´le jen 16 bitu˚ k popisu segmentu˚ i za hranicı´ 1MB. Po prˇepocˇtu adresy pomocı´ selektoru se jesˇteˇ prˇicˇte offset; ten ma´ samozrˇejmeˇ 32 bitu˚. Cely´ far pointer ma´ tedy 48 bitu˚; tato neobvykla´ velikost mu˚zˇe by´t matoucı´, nicme´neˇ v praxi se veˇtsˇinou pouzˇ´ıvajı´ jen near pointery, nebot’ 32bitovy´ offset adresuje azˇ 4GB pameˇti. U kazˇde´ho programu tedy stacˇ´ı prˇi startu pomocı´ deskriptoru a selektoru nastavit jeho ba´zi (tj. urcˇit, kde v pameˇti zacˇ´ına´), a pak uzˇ se pracuje jen s 32bitovy´m offsetem. Programy tedy vlastneˇ pracujı´ jakoby s linea´rnı´ adresou, cozˇ je dosti vy´hodne´ pro ru˚zne´ vy´pocˇty s adresami apod. Tabulky deskriptoru˚ spravuje pouze operacˇnı´ syste´m, samotne´ programy je nemohou ovliv1

Offset je anglicky´ termı´n pro posunutı´.

20

Deskriptor popisuje segment pameˇti (jeho zacˇa´tek, de´lku atd.).

GDT je globa´lnı´ tabulka deskriptoru˚.

nˇovat. Sa´m procesor ma´ jednu globa´lnı´ tabulku GDT (global descriptor table), ukazuje na ni registr GDTR. Deskriptory v te´to tabulce mohou odkazovat na dalsˇ´ı tabulky deskriptoru˚, z nichzˇ pra´veˇ jedna je vzˇdy aktivnı´ jako LDT (local descriptor table). Kazˇdy´ program tedy obvykle ma´ svou LDT (cozˇ je pochopitelne´), na kterou ukazuje registr LDTR, a navı´c mu˚zˇe pouzˇ´ıvat prˇ´ımo i deskriptory v GDT. Deskriptory, ktere´ program pouzˇ´ıva´, pak jizˇ jsou samotne´ segmenty pro ko´d cˇi data programu. Kazˇdy´ deskriptorovy´ za´znam obsahuje prˇedevsˇ´ım u´daje o pocˇa´tku, de´lce a typu segmentu, povolenı´ cˇtenı´/za´pisu/spousˇteˇnı´, atp. 16bitove´ segmentove´ registry, ktere´ pu˚vodneˇ ukazovaly neˇkam do prvnı´ho 1MB pameˇti, nynı´ ukazujı´ do tabulky LDT nebo GDT. Registry jsou oznacˇova´ny jako selektory segmentu˚ a jejich 16bitova´ hodnota se skla´da´ z indexu do tabulky deskriptoru˚ (13 bitu˚ – maxima´lneˇ tedy mu˚zˇe by´t 8192 deskriptoru˚ v jedne´ tabulce), bitu rozlisˇujı´cı´cho GDT a LDT a 2 bitu˚ opra´vneˇnı´ (bude probra´no v kapitole 11.2 na straneˇ 115). Registr LDTR je sa´m segmentovy´m registrem ukazujı´cı´m do GDT; GDT uzˇ nema´ kam ukazovat, takzˇe obsahuje prˇ´ımo linea´rnı´ adresu tabulky deskriptoru˚ a jejı´ velikost (obojı´ s prˇesnostı´ na bajt). Procesory x86 take´ pouzˇ´ıvajı´ stra´nkova´nı´, cozˇ je dalsˇ´ı stupenˇ abstrakce. Prˇi stra´nkova´nı´ pouzˇ´ıva´ procesor dalsˇ´ı tabulky, pomocı´ ktery´ch se mapujı´ 4KB bloky fyzicke´ pameˇti (ra´mce) do jine´ho porˇadı´. Vznikajı´ tak 4KB ra´mce. Vy´hodou stra´nkova´nı´ je, zˇe umozˇnˇuje, aby vı´ce programu˚ bylo soucˇasneˇ v pameˇti, kazˇdy´ pouzˇ´ıval ru˚zne´ „kousky“ fyzicke´ pameˇti, a prˇitom z pohledu tohoto programu se zda´lo, zˇe ma´ pro sebe jeden linea´rnı´ nekouskovany´ prostor. (Opeˇt totizˇ platı´, zˇe stra´nkova´nı´ zajisˇt’uje operacˇnı´ syste´m a samotne´ programy o neˇm neveˇdı´.) Stra´nkova´nı´ take´ umozˇnˇuje odkla´dat cˇa´st vnitrˇnı´ pameˇti na disk. Programy tedy mohou vyuzˇ´ıvat vı´ce operacˇnı´ pameˇti, nezˇ kolik ma´me v pocˇ´ıtacˇi vnitrˇnı´ pameˇti (RAM). 2.2.4

Typy adres v operandech

Procesory CISC u veˇtsˇiny instrukcı´ umozˇnˇujı´, aby tyto ukazovaly prˇ´ımo na pameˇt’. Vykona´nı´ operace nad neˇjakou promeˇnnou tedy lze prove´st bez toho, abychom hodnotu nejprve nacˇetli do registru, pak provedli operaci, a pak vy´sledek ulozˇili zpeˇt do pameˇti. Procesory x86 umozˇnˇujı´ urcˇit adresu dveˇma zpu˚soby: Prˇ´ıma´ adresa ukazuje na pevne´ mı´sto v pameˇti, cˇili jedna´ se o offset (viz definici vy´sˇe). Tento zpu˚sob je efektivnı´ z hlediska beˇhu programu, ale nenı´ flexibilnı´. V praxi je pouzˇitelny´ jen pro urcˇenı´ adres globa´lnı´ch promeˇnny´ch a podprogramu˚, ktere´ jsou pochopitelneˇ vzˇdy na stejne´m mı´steˇ v pameˇti (vzhledem k ba´zi). Neprˇ´ıma´ adresa ukazuje na mı´sto v pameˇti neprˇ´ımo. Adresa se tentokra´t vypocˇ´ıta´ z hodnot registru˚, prˇ´ıpadneˇ prˇicˇtenı´m neˇjake´ho dalsˇ´ıho posunutı´. Tento zpu˚sob adresova´nı´ je me´neˇ efektivnı´ (pomalejsˇ´ı), ale je naprosto flexibilnı´. 16bitove´ procesory x86 majı´ neprˇ´ıme´ adresova´nı´ mozˇne´ ve formeˇ adresa = posunutí + si/di + bx Jednotlive´ slozˇky (scˇ´ıtance) jsou nepovinne´. Posunutı´ je prˇ´ıma´ hodnota (offset). Si, di a bx jsou registry. (Z prvnı´ch dvou je mozˇno pouzˇ´ıt jen jeden: tedy bud’ si, nebo di.) 32bitove´ procesory x86 majı´ neprˇ´ıme´ adresova´nı´ dokonalejsˇ´ı. Adresu lze urcˇit pomocı´ azˇ dvou registru˚ a posunutı´ takto: adresa = posunutí + báze + index ∗ f aktor Jednotlive´ slozˇky (scˇ´ıtance) jsou opeˇt nepovinne´. Ba´ze a index jsou registry, je mozˇno pouzˇ´ıt te´meˇrˇ libovolne´ vsˇeobecne´ registry. Posunutı´ je prˇ´ıma´ hodnota a faktor je cˇ´ıslo 1, 2, 4 nebo 8. Jednotlive´ soucˇa´sti adresy samozrˇejmeˇ nejsou povinne´ a pouzˇ´ıva´me je dle potrˇeby. Naprˇ´ıklad pro prˇ´ıstup do globa´lnı´ho pole pouzˇijeme forma´t adresy posunutí + index ∗ f aktor, kde 21

Kazˇdy´ program ma´ svou vlastnı´ tabulku deskriptoru˚ LDT.

posunutı´ je adresa pole, index je cˇ´ıslo bunˇky v poli a faktor je velikost jedne´ bunˇky. Druhy´ prˇ´ıklad: Pro prˇ´ıstup do loka´lnı´ho skala´ru (jednoduche´ promeˇnne´) pouzˇijeme posunutı´ + ba´ze, kde ba´ze je adresa ra´mce aktua´lnı´ funkce na za´sobnı´ku a posunutı´ je pozice nasˇ´ı promeˇnne´ v ra´mci funkce. 2.2.5

Cache pameˇt’

Cache neboli vyrovna´vacı´ pameˇt’ je zvla´sˇtnı´ pomocna´ pameˇt’, ktera´ je mala´, ale velmi rychla´. Mu˚zˇeme ji nale´zt v procesorech, ale i v jiny´ch hardwarovy´ch i softwarovy´ch prvcı´ch. Smyslem cache je zrychlit opakovane´ cˇtenı´ pameˇti tı´m, zˇe to, co bylo neda´vno cˇteno, je docˇasneˇ uchova´no take´ v cache a prˇi opakovane´m cˇtenı´ te´hozˇ se data cˇtou z cache namı´sto opravdove´ pameˇti. Modernı´ procesory majı´ ru˚zne´ typy cache pro zrychlenı´ ru˚zny´ch specificky´ch operacı´. Cache obvykle poma´ha´ i se za´pisem do pameˇti tı´m, zˇe prˇi soucˇasne´m cˇtenı´ i za´pisu pameˇti se data docˇasneˇ zapisujı´ jen do cache a prˇednost ma´ cˇtenı´ pameˇti. Teprve pozdeˇji, azˇ je procesor me´neˇ vytı´zˇen, se data z cache zapisujı´ do skutecˇne´ pameˇti. Fungova´nı´ cache pameˇti je prˇitom dosti slozˇite´, nasˇteˇstı´ na´s nemusı´ azˇ tak tra´pit, nebot’pro programy je jejı´ existence zcela transparentnı´ (cˇili neveˇdı´ o nı´). Prˇ´ınos cache je vysˇsˇ´ı, pokud programy dodrzˇujı´ tzv. cˇasoveˇ–prostorovou lokalitu, tj. v urcˇite´m kra´tke´m cˇase prˇistupujı´ pokud mozˇno jen do jedne´ lokality pameˇti. Proto jsou prˇi beˇhu programy pouzˇ´ıvajı´cı´ globa´lnı´ promeˇnne´ nesystematicky rozsete´ po pameˇti pomalejsˇ´ı nezˇ objektoveˇ orientovane´ programy, kde je veˇtsˇina dat jen v loka´lnı´ch promeˇnny´ch funkce a ve „sve´m“ objektu (v rˇadeˇ jazyku˚ na adrese oznacˇene´ jako „this“).

2.3

I/O zarˇ´ızenı´

Trˇetı´ cˇa´stı´ pocˇ´ıtacˇe jsou dle von Neumannova sche´matu I/O zarˇ´ızenı´ (neboli periferie). Sem spada´ vsˇe, co je mimo ja´dro pocˇ´ıtacˇe tvorˇene´ procesorem a vnitrˇnı´ pameˇtı´. Zastavı´me se u nich jen strucˇneˇ, nebot’jich existuje velke´ mnozˇstvı´ a jejich jednotlive´ funkce na´s azˇ tak nezajı´majı´. Tı´m, jak si se zarˇ´ızenı´mi poradı´ operacˇnı´ syste´m, se navı´c budeme zaby´vat azˇ v pozdeˇjsˇ´ıch kapitola´ch. Nynı´ si proto jen prˇedstavme neˇkolik za´kladnı´ch principu˚. V dnesˇnı´ch pocˇ´ıtacˇ´ıch jsou I/O zarˇ´ızenı´ pomeˇrneˇ inteligentnı´, pu˚vodnı´ von Neumannu˚v model vsˇak pocˇ´ıtal s tı´m, zˇe to budou spı´sˇe jednoducha´ zarˇ´ızenı´ umozˇnˇujı´cı´ jen za´kladnı´ formu komunikace s procesorem na ba´zi prˇ´ıkazu˚, ktere´ da´va´ procesor zarˇ´ızenı´, a odpoveˇdi, kterou da´va´ zarˇ´ızenı´ procesoru. Zarˇ´ızenı´ tedy naprˇ. nema´ mı´t prˇ´ımy´ prˇ´ıstup do operacˇnı´ pameˇti (i kdyzˇ v soucˇasne´ praxi je tomu obvykle naopak). Obecneˇ platı´, zˇe spolupra´ce se zarˇ´ızenı´mi patrˇ´ı ke spı´sˇe slozˇiteˇjsˇ´ım postupu˚m, protozˇe je nutno velmi pecˇliveˇ sledovat, v jake´m stavu zarˇ´ızenı´ je, zda vu˚bec ocˇeka´va´ prˇ´ıkazy od procesoru, zda je neposı´la´me moc rychle atd. Prˇi komunikaci je navı´c nutno pocˇ´ıtat s tı´m, zˇe mezi vysla´nı´m povelu a obdrzˇenı´m odpoveˇdi ze zarˇ´ızenı´ je vzˇdy neˇjaka´ prodleva. Situace by´va´ rˇesˇena jednı´m ze dvou zpu˚sobu˚: Aktivnı´ cˇeka´nı´ – Procesor vsˇe sa´m prˇ´ımo rˇ´ıdı´ a sleduje. Beˇhem cˇeka´nı´ na odpoveˇd’ od zarˇ´ızenı´ mu˚zˇe pru˚beˇzˇneˇ kontrolovat situaci, nemu˚zˇe vsˇak vykona´vat zˇa´dny´ jiny´ program. Tento zpu˚sob komunikace se pouzˇ´ıval prˇedevsˇ´ım v minulosti, dnes se mu vyhy´ba´me, nebot’zpu˚sobuje „zamrznutı´ “ pocˇ´ıtacˇe. (Vy´jimkou jsou neˇktere´ teˇzˇko pochopitelne´ chyby v na´vrhu syste´mu, naprˇ. zamrznutı´ Windows prˇi otevı´ra´nı´ CD z mechaniky apod.) Vyuzˇitı´ prˇerusˇenı´ – Procesor jen zarˇ´ızenı´ vysˇle povel a da´l pokracˇuje ve vykona´va´nı´ jine´ho programu. Jakmile je prˇipraven vy´sledek, zarˇ´ızenı´ vyvola´ prˇerusˇenı´, cˇ´ımzˇ procesor prˇejde do podprogramu obsluhy prˇerusˇenı´. Tam vykomunikuje se zarˇ´ızenı´m potrˇebne´ detaily a ukoncˇ´ı tento podprogram. Tı´m se dostane zpeˇt do mı´sta, kde byl prˇerusˇen, a beˇh programu pokracˇuje. 22

Cache je mala´ rychla´ pameˇt’.

Vyuzˇitı´ prˇerusˇenı´ ma´ obrovskou vy´hodu v tom, zˇe je efektivneˇ vyuzˇit vy´pocˇetnı´ vy´kon procesoru, proto ma´ tato metoda komunikace se zarˇ´ızenı´mi jednoznacˇneˇ prˇednost. Nevy´hodou je podstatneˇ slozˇiteˇjsˇ´ı na´vrh jak hardwaru pocˇ´ıtacˇe, tak operacˇnı´ho syste´mu a programu˚, ktere´ s prˇerusˇenı´m neˇjak pracujı´. Proto se v minulosti, kdy pocˇ´ıtacˇe i programy byly jednodusˇsˇ´ı, pouzˇ´ıvalo prˇerusˇenı´ me´neˇ nezˇ dnes. Vy´pocˇetneˇ nejna´rocˇneˇjsˇ´ı operacı´ je cˇtenı´ cˇi za´pis veˇtsˇ´ıho mnozˇstvı´ dat. Naprˇ´ıklad nacˇtenı´ dat z disku zacˇne tı´m, zˇe procesor da´ diskove´mu zarˇ´ızenı´ povel ke cˇtenı´. Pak cˇeka´, azˇ jsou data prˇipravena. Potom je vsˇak trˇeba data nacˇ´ıst, cozˇ znamena´ absolvovat kolecˇko pozˇadavek– odpoveˇd’ pro kazˇdy´ bajt dat. Beˇhem tohoto kolecˇka musı´ procesor pecˇliveˇ sledovat, zda data nezˇa´da´ moc rychle, protozˇe procesor je obvykle mnohem rychlejsˇ´ı nezˇ I/O zarˇ´ızenı´. Jednotlive´ bajty dat zarˇ´ızenı´ posı´la´ po jednom po datove´ sbeˇrnici. Procesor si je pru˚beˇzˇneˇ skla´da´ neˇkam do pameˇti, zatı´mco samo zarˇ´ızenı´ operacˇnı´ pameˇt’prˇ´ımo nevidı´. Alternativou k tomuto postupu je vyuzˇitı´ moderneˇjsˇ´ı techniky zvane´ DMA (Direct Memory Access – prˇ´ımy´ prˇ´ıstup do pameˇti), ktera´ umozˇnˇuje I/O zarˇ´ızenı´m prˇ´ımo prˇistupovat do pameˇti. DMA lze pouzˇ´ıt jen tehdy, podporuje-li ho pocˇ´ıtacˇ, operacˇnı´ syste´m i zarˇ´ızenı´. Na pocˇ´ıtacˇ´ıch PC je funkce DMA zajisˇteˇna obvodem DMAC (DMA Controller). Jedna´ se o inteligentnı´ zarˇ´ızenı´ prˇipojene´ na sbeˇrnici, ktere´ umı´ komunikovat jak s I/O zarˇ´ızenı´mi, tak s operacˇnı´ pameˇtı´. Cˇtenı´ z disku pak mu˚zˇe probeˇhnout tak, zˇe procesor naprogramuje DMAC k prˇenosu dat ze zarˇ´ızenı´ do pameˇti a pak da´ povel zarˇ´ızenı´, aby zaha´jilo cˇtenı´ disku. Procesor pak mu˚zˇe prova´deˇt jiny´ program, zatı´mco DMAC postupneˇ odebı´ra´ data prˇicha´zejı´cı´ ze zarˇ´ızenı´ a ukla´da´ je na urcˇene´ mı´sto do pameˇti. Jedno omezenı´ zde vsˇak zu˚sta´va´: Data do operacˇnı´ pameˇti sta´le proudı´ po te´zˇe sbeˇrnici, kterou procesor pouzˇ´ıva´ pro cˇtenı´ sve´ho programu a dat. DMAC tak vlastneˇ „krade“ sbeˇrnici, nebot’se chova´ jako druhy´ inteligentnı´ procesor na sbeˇrnici. Na sbeˇrnici pak mu˚zˇe docha´zet ke kolizı´m, dalsˇ´ım limitujı´cı´m faktorem je samotna´ rychlost pameˇt’ovy´ch cˇipu˚. Pokud totizˇ CPU i DMAC chteˇjı´ pracovat soucˇasneˇ (cozˇ je jejich cı´lem), za´koniteˇ na omezenou rychlost pameˇt’ove´ho cˇipu narazı´. Proble´mem zde popsane´ho pu˚vodnı´ho DMAC je prˇedevsˇ´ım dnes jizˇ nedostacˇujı´cı´ rychlost a take´ nemozˇnost adresovat vı´ce nezˇ 16MB pameˇti. Dnesˇnı´ zarˇ´ızenı´ vsˇak tento obvod jizˇ nepotrˇebujı´, nebot’ sbeˇrnice PCI (a noveˇjsˇ´ı) umozˇnˇujı´ zarˇ´ızenı´m prˇ´ımy´ prˇ´ıstup do operacˇnı´ pameˇti. Zatı´mco starsˇ´ı zarˇ´ızenı´ byla napojena na sbeˇrnici ISA, ktera´ byla oddeˇlena od sbeˇrnice ja´dra pocˇ´ıtacˇe pomocı´ ISA rˇadicˇe poskytujı´cı´m pouze za´kladnı´ funkcionalitu na frekvenci 8MHz, noveˇjsˇ´ı sbeˇrnice (naprˇ. PCI) jsou jak rychlejsˇ´ı, tak chytrˇejsˇ´ı. Sbeˇrnice AGP urcˇena´ pro graficke´ karty je dokonce prˇ´ımo sprˇazˇena se sbeˇrnicı´, na ktere´ je prˇipojen procesor, takzˇe AGP zarˇ´ızenı´ ma´ opravdu prˇ´ımy´ prˇ´ıstup i bez dalsˇ´ıho rˇadicˇe. Takovy´ prˇ´ıstup je tedy na rozdı´l od PCI nejen jednoduchy´, ale i rychly´; obra´ceneˇ i procesor ma´ prˇ´ımy´ a rychly´ prˇ´ıstup do pameˇti na AGP graficke´ karteˇ. Pru˚vodce studiem Jmenovane´ sbeˇrnice PCI a AGP jsou samozrˇejmeˇ jen dveˇma prˇ´ıklady z mnoha. Du˚vody, procˇ zarˇ´ızenı´ v pocˇ´ıtacˇ´ıch PC nejsou prˇ´ımo prˇipojena na stejnou sbeˇrnici jako procesor, jsou prˇedevsˇ´ım v rovineˇ elektricke´. De´lka vedenı´ by byla neˇkolik desı´tek centimetru˚ a na takovou vzda´lenost nenı´ technicky mozˇne´ zajistit dostatecˇneˇ rychlou a spolehlivou komunikaci. Kazˇde´ zarˇ´ızenı´ navı´c sbeˇrnici da´le zateˇzˇuje, protozˇe jejı´m pouzˇ´ıva´nı´m z jednotlivy´ch linek odebı´ra´ proud. Spolecˇnou sbeˇrnici proto mı´vajı´ jen pomalejsˇ´ı a hlavneˇ pouze male´ pocˇ´ıtacˇe, a to doslova. Dalsˇ´ım zpu˚sobem, jak zlepsˇit fungova´nı´ sbeˇrnice, je prˇechod z paralelnı´ho na se´riovy´ model. Zatı´mco u pocˇ´ıtacˇu˚ hovorˇ´ıme, zˇe jsou naprˇ. 32bitove´, kdyzˇ majı´ 32bitovou sbeˇrnici, nova´ sbeˇrnice PCI Express je 1bitova´. Dı´ky tomu je jejı´ realizace elektricky mnohem jednodusˇsˇ´ı a jejı´ provoz spolehliveˇjsˇ´ı. Se´riova´ sbeˇrnice vsˇak musı´ beˇzˇet mnohem rychleji nezˇ paralelnı´, naprˇ. 32× rychleji nezˇ 32bitova´ PCI, aby dosa´hla jejı´ komunikacˇnı´ propustnosti. Proto se k se´riove´mu typu sbeˇrnic prˇistoupilo teprve v okamzˇiku, kdy byly k dispozici

23

Modernı´ zarˇ´ızenı´ pouzˇ´ıvajı´ se´riove´ sbeˇrnice.

dostatecˇneˇ rychle´ a levne´ rˇadicˇe. (Dalsˇ´ımi prˇ´ıklady se´riovy´ch sbeˇrnic jsou USB cˇi SATA.)

Alternativou k DMA prˇenosu˚m je pouzˇitı´ kana´lu˚. Jde o jesˇteˇ inteligentneˇjsˇ´ı programovatelne´ zarˇ´ızenı´ slouzˇ´ıcı´ ke stejne´mu u´cˇelu. Kana´ly pouzˇ´ıvaly naprˇ. sa´love´ pocˇ´ıtacˇe IBM System/360. Na pocˇ´ıtacˇ´ıch PC se kana´ly nepouzˇ´ıvajı´. Shrnutı´ Tato kapitola prˇinesla podrobneˇjsˇ´ı popis za´kladnı´ch soucˇa´stı´ pocˇ´ıtacˇe, tj. procesoru, operacˇnı´ pameˇti a I/O zarˇ´ızenı´. (Z hlubsˇ´ıch diskuzı´ jsme vynechali sbeˇrnici, ktera´zˇto je cˇisteˇ hardwarovou za´lezˇitostı´ a studia operacˇnı´ch syste´mu˚ se nijak nety´ka´.) V prvnı´ cˇa´sti kapitoly jsme se veˇnovali CPU neboli procesoru. Dozveˇdeˇli jsme se, co je to instrukce a jak se vykona´va´, sezna´mili jsme se take´ s paralelnı´m vykona´va´nı´m instrukcı´ a rozdı´lem mezi procesory s u´plnou a redukovanou instrukcˇnı´ sadou. V dalsˇ´ı cˇa´sti kapitoly jsme se veˇnovali operacˇnı´ pameˇti, zejme´na pak zpu˚sobu ulozˇenı´ informacı´ textovy´ch a cˇ´ıselny´ch v nı´ a take´ obvykly´mi zpu˚soby adresace pameˇti. Vı´ce o instrukcı´ch procesoru a adresova´nı´ pameˇti se studenti mohou doveˇdeˇt na cvicˇenı´ch a/nebo v publikaci [Kep08a], ktera´ slouzˇ´ı jako vodı´tko (ucˇebnı´ text) pro cvicˇenı´. Za´veˇr kapitoly byl veˇnova´n prˇedstavenı´ obvykly´ch zpu˚sobu˚ pra´ce s I/O zarˇ´ızenı´m, zejme´na se zameˇrˇenı´m na problematiku prˇerusˇenı´ a s nı´m souvisejı´cı´ch te´mat. Pojmy k zapamatova´nı´ • • • • • • • • • • • • • • • • • • • • •

procesor instrukce ALU (aritmeticko–logicka´ jednotka) vykona´nı´ instrukce pipelining CISC (u´plna´ instrukcˇnı´ sada) RISC (redukovana´ instrukcˇnı´ sada) doplnˇkovy´ ko´d prˇetecˇenı´, podtecˇenı´ big endian, little endian bi–endian, middle endian BCD (binary coded decimal) adresova´nı´ pameˇti segmentove´ adresova´nı´ prˇ´ıma´ a neprˇ´ıma´ adresa cache pameˇt’ cˇasoveˇ–prostorova´ lokalita aktivnı´ cˇeka´nı´ prˇerusˇenı´ DMA (direct memory access) sbeˇrnice ISA, PCI, AGP, PCI Express

Kontrolnı´ ota´zky 1. Vysveˇtlete postup vykona´nı´ instrukce procesorem. 2. Popisˇte, jak funguje pipelining. 3. Jake´ jsou za´kladnı´ rozdı´ly mezi CISC a RISC procesory? 24

4. Dokazˇte, zˇe zmeˇnu cˇ´ıselne´ho zname´nka v doplnˇkove´m ko´du provedeme prˇevra´cenı´m hodnoty vsˇech bitu˚ a prˇicˇtenı´m jednicˇky. 5. Jaky´ je rozdı´l mezi ko´dova´nı´m cˇ´ısel big endian a little endian? Ktera´ varianta je lepsˇ´ı a procˇ? 6. Popisˇte zpu˚sob adresova´nı´ pameˇti pomocı´ segmentu˚ a offsetu˚. 7. Vysveˇtlete pojem cˇasoveˇ–prostorove´ lokality prˇ´ıstupu do pameˇti. 8. Jake´ jsou nevy´hody aktivnı´ho cˇeka´nı´? Vidı´te v neˇm i neˇjake´ vy´hody? Popisˇte je. 9. Jaky´ ma´ prˇi pra´ci s I/O zarˇ´ızenı´mi vy´znam prˇerusˇenı´? Byl vy´znam prˇerusˇenı´ v minulosti veˇtsˇ´ı, cˇi mensˇ´ı nezˇ dnes? Proved’te diskuzi. 10. Popisˇte, k cˇemu slouzˇ´ı DMA a jak funguje. 11. Vysveˇtlete, procˇ LDTR je segmentovy´ registr, ale GDTR nenı´ segmentovy´ registr.

25

ˇ ´ızenı´ vy´pocˇtu R

3

Studijnı´ cı´le: V prˇedchozı´ kapitole byla rˇecˇ mj. o zpu˚sobu zpracova´nı´ jedne´ instrukce procesorem. Nynı´ na to nava´zˇeme a sezna´mı´me se s globa´lnı´ organizacı´ pra´ce procesoru, tj. s pravidly porˇadı´ vykona´va´nı´ instrukcı´, se skoky a podprogramy. Rˇecˇ bude take´ o za´sobnı´ku a prˇerusˇenı´, cozˇ jsou dveˇ velmi du˚lezˇite´ soucˇa´sti vykona´va´nı´ ko´du programu˚ a rˇ´ızenı´ vy´pocˇtu. Klı´cˇova´ slova: skok, vola´nı´, podprogram, za´sobnı´k, prˇerusˇenı´ Potrˇebny´ cˇas: 90 minut.

3.1

Porˇadı´ vykona´va´nı´ instrukcı´

Jak vı´me, instrukce jsou prova´deˇny sekvencˇneˇ, tj. „jedna za druhou“ tak, jak jsou v pameˇti. Toto je samozrˇejmeˇ naprosto intuitivnı´ a dobrˇe pochopitelne´. Procesory mohou mı´t instrukcˇnı´ sadu postavenou tak, zˇe kazˇda´ instrukce je stejneˇ dlouha´. To umozˇnı´ snadny´ postup programu vprˇed. V praxi se vsˇak cˇasteˇji pouzˇ´ıva´ model promeˇnlive´ de´lky instrukcı´ – kazˇda´ instrukce je pak tak dlouha´, jak je potrˇeba (jeden bajt, cˇi vı´ce). Naprˇ´ıklad na´m zna´ma´ instrukce mov mu˚zˇe pracovat bud’ pouze s registry, nebo take´ s pameˇtı´. Pracuje-li s pameˇtı´, je pochopitelneˇ delsˇ´ı, nezˇ kdyzˇ pracuje jen s registry. (Instrukce je obvykle delsˇ´ı o 4 bajty, kde je adresa pameˇti.) Da´le, jelikozˇ v jednom bajtu ma´me jen 256 hodnot, vsˇechny instrukce se tam nevejdou, takzˇe neˇktere´ instrukce uzˇ z principu majı´ vı´ce nezˇ jeden bajt, prˇestozˇe s pameˇtı´ ani nepracujı´. Procesor tedy musı´ u kazˇde´ konkre´tnı´ instrukce veˇdeˇt cˇi neˇjak spocˇ´ıtat, o kolik bajtu˚ da´le v pameˇti je instrukce na´sledujı´cı´. Zpu˚sob, jaky´m je to zajisˇteˇno, na´s nasˇteˇstı´ nemusı´ tra´pit. Na procesorech x86 je v registru eip adresa pra´veˇ vykona´vane´ instrukce. Beˇzˇneˇ se tedy hodnota tohoto registru postupneˇ zvysˇuje, jak program beˇzˇ´ı. Porˇadı´ vykona´va´nı´ instrukcı´ vsˇak mu˚zˇeme neˇkolika zpu˚soby zmeˇnit – v za´sadeˇ jsou dva typy situacı´, ktere´ mohou nastat: Skok je situace, kdy instrukce velı´ procesoru prˇejı´t s vykona´va´nı´m na jinou adresu. Rozlisˇujeme nepodmı´neˇny´ skok (instrukce jmp), kdy program „skocˇ´ı“ na novou adresu vzˇdy, a podmı´neˇny´ skok, kdy program prˇejde na novou adresu jen prˇi splneˇnı´ urcˇite´ podmı´nky. Ktere´ konkre´tnı´ podmı´nky lze testovat, to za´lezˇ´ı na konkre´tnı´m procesoru. Naprˇ. rˇada x86 umı´ ska´kat dle rˇady hodnot v registru prˇ´ıznaku˚, nebo dle hodnoty registru ecx. Prˇerusˇenı´ cˇi vola´nı´ podprogramu je situace obdobna´ nepodmı´neˇne´mu skoku, jenzˇe tentokra´t si procesor prˇed skokem na novou adresu nejprve na za´sobnı´k uchova´ aktua´lnı´ adresu. Tu pozdeˇji pouzˇije pro na´vrat z podprogramu. Pojem „prˇerusˇenı´“ popisuje zvla´sˇtnı´ prˇ´ıpad vola´nı´ podprogramu, ktere´ sice probeˇhne obvykle velmi podobneˇ klasicke´mu vola´nı´, ale je mozˇno jej vyvolat i z vneˇjsˇ´ıho zarˇ´ızenı´. Konkre´tnı´ mozˇnosti prˇerusˇenı´ jsou samozrˇejmeˇ za´visle´ na konkre´tnı´m procesoru. Prˇerusˇenı´ je tedy na´stroj, jak program „prˇerusˇit“. Po vykona´nı´ neˇjake´ho ko´du, ktere´mu rˇ´ıka´me obsluha prˇerusˇenı´, program pokracˇuje tam, kde byl prˇerusˇen. Jelikozˇ vola´nı´ podprogramu je de facto tote´zˇ, hovorˇ´ıme o neˇm na stejne´m mı´steˇ. Rozdı´ly mezi teˇmito dveˇma na´stroji si popı´sˇeme v na´sledujı´cı´ch odstavcı´ch. Skoky oproti tomu neumeˇjı´ prove´st „na´vrat“ na pu˚vodnı´ mı´sto – jakmile jednou neˇkam takto skocˇ´ıme, program se jizˇ zpeˇt nevra´tı´. Pru˚vodce studiem Samozrˇejmeˇ je mozˇne´ udeˇlat na´vrat na pu˚vodnı´ mı´sto i pomocı´ skoku – stacˇ´ı na konec podprogramu da´t opeˇt instrukci skoku smeˇrˇujı´cı´ zpeˇt na pu˚vodnı´ mı´sto programu. Rozdı´l takove´ho rˇesˇenı´ oproti prˇerusˇenı´ cˇi vola´nı´ podprogramu je, zˇe prˇi neˇm musı´me prˇedem veˇdeˇt, kam se vlastneˇ chceme vra´tit, a napsat to k one´ poslednı´ instrukci skoku. Jenzˇe

26

Instrukce jmp provede nepodmı´neˇny´ skok.

v praxi se podprogramy volajı´ z ru˚zny´ch mı´st, takzˇe neexistuje jedine´ mı´sto na´vratu. Proto se prˇi vola´nı´ cˇi prˇerusˇenı´ ulozˇ´ı aktua´lnı´ hodnota eip na za´sobnı´k a prˇi na´vratu se z neˇj opeˇt vyzvedne.

Pomu˚cka: Instrukce skoku jmp skocˇ´ı na danou adresu. Adresu obvykle oznacˇ´ıme pomocı´ na´veˇsˇtı´ (jme´no s dvojtecˇkou, uvedeno na zacˇa´tku rˇa´dku). Instrukce vola´nı´ call <podprogram> vola´ podprogram. Tato instrukce provede jakoby dveˇ veˇci: push eip jmp <podprogram> Na´vrat z podprogramu provedeme jednoduchou instrukcı´ ret, ktera´ provede jakoby pop eip. Pru˚vodce studiem Acˇkoliv soudobe´ procesory pouzˇ´ıvajı´ pro vola´nı´ podprogramu˚ za´sobnı´k, existujı´ i jine´ modely vola´nı´. Neˇktere´ procesory prosteˇ za´sobnı´k nemajı´; adresu na´vratu pak musejı´ ukla´dat jinam, naprˇ. sa´love´ pocˇ´ıtacˇe rˇady IBM System/360 ukla´dajı´ adresu na´vratu do specia´lnı´ho registru. Zatı´mco beˇzˇne´ rˇesˇenı´ se za´sobnı´kem umozˇnˇuje take´ rekurzi, prˇi ukla´da´nı´ adresy na´vratu do registru nenı´ rekurze tak jednodusˇe mozˇna´. A jelikozˇ rekurze je dnes jednı´m z klı´cˇovy´ch prvku˚ programova´nı´, za´sobnı´k dnes najdeme skutecˇneˇ vsˇude.

3.2

Vola´nı´ podprogramu

Podprogram je obecny´ technicky´ na´zev pro procedury, funkce a metody, ktere´ najdeme ve veˇtsˇineˇ programovacı´ch jazyku˚. Jejich vola´nı´ je jednı´m z nejcˇasteˇjsˇ´ıch u´kolu˚, ktere´ program po ´ rovenˇ hardwarove´ podpory procesoru pozˇaduje, takzˇe neprˇekvapı´, zˇe je zajisˇteˇno hardwaroveˇ. U se samozrˇejmeˇ na ru˚zny´ch procesorech lisˇ´ı, my se opeˇt budeme veˇnovat prˇedevsˇ´ım rˇadeˇ x86. Od vola´nı´ obvykle ocˇeka´va´me: • Prˇeda´nı´ parametru˚ do podprogramu • Prˇeda´nı´ na´vratove´ hodnoty z podprogramu • Umozˇneˇnı´ reentrance (cˇili mozˇnost rekurze) Prˇeda´va´nı´ parametru˚ Procesory x86 umozˇnˇujı´ prˇeda´vat parametry neˇkolika zpu˚soby. Nejrozsˇ´ırˇeneˇjsˇ´ı jsou ty, ktere´ pouzˇ´ıvajı´ prˇekladacˇe nejrozsˇ´ırˇeneˇjsˇ´ıch vysˇsˇ´ıch jazyku˚ (jako je C/C++ cˇi Turbo Pascal). Uved’me si trˇi nejbeˇzˇneˇjsˇ´ı konvence vola´nı´ lisˇ´ıcı´ se mı´stem ulozˇenı´ parametru˚, jejich porˇadı´m a odpoveˇdnostı´ za u´klid parametru˚ po vola´nı´. Prˇeda´va´nı´ pomocı´ registru˚ – Stanovı´me si, ve ktere´m registru budeme prˇeda´vat ktery´ parametr. Toto rˇesˇenı´ mu˚zˇe by´t efektivnı´ z hlediska rychlosti, protozˇe pra´ce s registry je vzˇdy rychla´. Nevy´hodou vsˇak mu˚zˇe by´t, zˇe registry nemu˚zˇeme pouzˇ´ıvat pro beˇzˇne´ vy´pocˇty, pokud jsou obsazeny hodnotami parametru˚. Po na´vratu nenı´ trˇeba prova´deˇt u´klid. V praxi se tento zpu˚sob prˇeda´va´nı´ parametru˚ pouzˇ´ıva´ v neˇkolika varianta´ch. Naprˇ. Visual C++ a GCC pouzˇ´ıvajı´ fastcall model, kdy prvnı´ dva parametry jsou v registrech ecx a edx, ostatnı´ pak jsou na za´sobnı´ku zprava doleva. Za´sobnı´k musı´ uklidit volany´.

27

Instrukce call vola´ podprogram.

Instrukce ret provede na´vrat z podprogramu.

Konvence C – Parametry prˇeda´va´me prˇes za´sobnı´k. Prˇed zavola´nı´m (call) podprogramu ulozˇ´ıme pomocı´ push instrukce jednotlive´ hodnoty parametru˚ na za´sobnı´k v opacˇne´m porˇadı´ (tj. zprava doleva). Ukla´da´me pozpa´tku, za´sobnı´k ale roste dolu˚, takzˇe zavolana´ funkce ma´ parametry peˇkneˇ za sebou zleva doprava. Funkce mu˚zˇe libovolneˇ pouzˇ´ıvat registry eax, ecx, edx. Po na´vratu volajı´cı´ provede u´klid parametru˚ (co ulozˇil na za´sobnı´k, to z neˇj zase vybere), pra´veˇ dı´ky tomu lze tı´mto zpu˚sobem prˇeda´vat promeˇnlivy´ pocˇet parametru˚ (cozˇ pouzˇ´ıva´ naprˇ. funkce printf).

C ukla´da´ parametry na za´sobnı´k zprava doleva.

Pascal – Parametry prˇeda´va´me prˇes za´sobnı´k jako v prˇedchozı´m prˇ´ıpadeˇ, tentokra´t je vsˇak ukla´da´me zleva doprava. Podprogram ma´ parametry tedy pozpa´tku a vola´nı´ s promeˇnlivy´m pocˇtem parametru˚ tedy nenı´ mozˇne´ (nebot’ by se posouvala adresa prvnı´ho parametru, ´ klid za´sobnı´ku provede volany´ – jelikozˇ pocˇet parametru˚ nenı´ promeˇnlivy´, cozˇ nelze). U podprogram vı´, kolik parametru˚ ma´, takzˇe je mu˚zˇe uklidit sa´m. Po na´vratu tedy nenı´ zˇa´dny´ dalsˇ´ı ko´d potrˇeba.

Pascal ukla´da´ parametry na za´sobnı´k zleva doprava.

Na´vratova´ hodnota se na x86 prˇeda´va´ vzˇdy v registru eax. Potrˇebujeme-li 64bitovoou hodnotu, pak pouzˇijeme dvojici registru˚ edx:eax. Pru˚vodce studiem Kvalitnı´ prˇekladacˇe jazyku˚ C/C++ umozˇnˇujı´ pouzˇ´ıvat libovolne´ zpu˚soby prˇeda´va´nı´ parametru˚. Pomocı´ direktiv cdecl, stdcall a fastcall si mu˚zˇeme u kazˇde´ funkce nastavit, jakou konvenci chceme pra´veˇ pro tuto funkci. Cdecl je standardnı´ C konvence, stdcall je zpu˚sob pouzˇ´ıvany´ syste´mem Windows ve Win32 API (tedy Pascal konvence s obra´ceny´m porˇadı´m parametru˚ a volny´m pouzˇitı´m registru˚ eax, ecx a edx) a fastcall je vy´sˇe popsana´ varianta prˇeda´va´nı´ prˇes registr.

Pru˚vodce studiem Potrˇebujeme-li vracet veˇtsˇ´ı mnozˇstvı´ dat, je s tı´m pochopitelneˇ proble´m. Visual C++ v takove´m prˇ´ıpadeˇ zmeˇnı´ podprogram tak, zˇe ma´ jeden dalsˇ´ı skryty´ vstupnı´ parametr, ve ktere´m je adresa pro ulozˇenı´ vy´sledku. Volajı´cı´ tedy prˇed vola´nı´m musı´ prˇipravit dostatecˇneˇ velky´ buffer a jeho adresu prˇeda´ jako dalsˇ´ı parametr vola´nı´. Podprogram na danou adresu ulozˇ´ı vy´sledek a o vı´c se nestara´. Volajı´cı´ pak svu˚j buffer zpracuje a uklidı´ jej. (Deklarativneˇ v C++: Pro struct A, kde sizeof(A)>8, se funkce A func(); prˇelozˇ´ı jako void func(A&);. Na´vratova´ hodnota typu double (64bitove´ FP cˇ´ıslo) se vracı´ na vrcholu FPU stacku.

Co se deˇje na za´sobnı´ku Podı´vejme se nynı´ podrobneˇji, co se prˇi vola´nı´ deˇje na za´sobnı´ku. Neforma´lneˇ rˇecˇeno, kazˇdy´m vola´nı´m na za´sobnı´ku vytvorˇ´ıme jaky´si otisk, ktere´mu rˇ´ıka´me stack frame, cˇili cˇesky ra´mec funkce cˇi ra´mec vola´nı´. Kazˇde´ vola´nı´ vytvorˇ´ı dalsˇ´ı novy´ ra´mec. Prˇipomenˇme, zˇe za´sobnı´k roste dolu˚. Seshora jsou v neˇm tedy ulozˇeny hodnoty tak, v jake´m porˇadı´ je tam ukla´da´me. Cˇili hodnoty jsou na za´sobnı´ku v tomto porˇadı´: • Parametry vola´nı´ (zprava doleva, cˇi zleva doprava – dle konvence) • Na´vratova´ adresa • Loka´lnı´ promeˇnne´ • Dalsˇ´ı rˇ´ıdicı´ informace (naprˇ. odkaz na prˇedchozı´ vola´nı´) 28

Kazˇde´ vola´nı´ stejne´ho podprogramu vytvorˇ´ı stejneˇ velky´ otisk, ru˚zne´ podprogramy vsˇak pochopitelneˇ potrˇebujı´ ru˚zne´ mnozˇstvı´ pameˇti (nebot’ majı´ ru˚zny´ pocˇet parametru˚, ru˚zny´ pocˇet loka´lnı´ch promeˇnny´ch apod.). Prˇi vola´nı´ se pouzˇ´ıvajı´ dva du˚lezˇite´ registry pro pra´ci se za´sobnı´kem. Registr esp vzˇdy ukazuje na vrchol za´sobnı´ku. Kazˇda´ instrukce push cˇi call snı´zˇ´ı esp o 4, kazˇda´ instrukce pop cˇi ret zvy´sˇ´ı esp o 4. Nelze ukla´dat jinak nezˇ 4 bajty (cˇ´ımzˇ se neˇktere´ veˇci komplikujı´, ale na za´sobnı´ku asponˇ ma´me sta´le porˇa´dek.) Druhy´m pouzˇity´m registrem je ebp. Pro pochopenı´ jeho vy´znamu si prˇedstavme na´sledujı´cı´ situaci: Beˇzˇ´ı neˇjaka´ funkce s loka´lnı´mi promeˇnny´mi a tato chce zavolat jinou funkci. Nejprve tedy musı´ na za´sobnı´k ulozˇit vsˇechny parametry pro vola´nı´. Jenzˇe kazˇde´ ulozˇenı´ jednoho parametru zmeˇnı´ vrchol za´sobnı´ku, takzˇe funkce se registrem esp nemu˚zˇe dopı´dit ke svy´m loka´lnı´m promeˇnny´m. Ty jsou totizˇ na pevne´m mı´steˇ v za´sobnı´ku prˇesneˇ tam, kde byl jeho vrchol v okamzˇiku zavola´nı´ funkce. Jelikozˇ se vsˇak na za´sobnı´k zacˇalo prˇipravovat dalsˇ´ı vola´nı´, prˇedchozı´ pozici jsme ztratili. A co se s tı´m da´ deˇlat? Do registru ebp si vzˇdy na zacˇa´tku podprogramu ulozˇ´ıme aktua´lnı´ hodnotu esp. Nasˇe loka´lnı´ promeˇnne´ pak vzˇdy najdeme prˇes ebp, i kdyzˇ se vrchol za´sobnı´ku bude meˇnit. Aby vsˇe spolehliveˇ fungovalo, na zacˇa´tku podprogramu samozrˇejmeˇ musı´me nejprve ulozˇit dosavadnı´ hodnotu ebp, abychom nezrusˇili odkaz na loka´lnı´ promeˇnne´ nadrˇazene´ (tj. volajı´cı´) funkce. Mı´sto, kam ukazuje ebp, oznacˇujeme jako dno za´sobnı´ku. Nynı´ si proces vola´nı´ podprogramu popisˇme v instrukcı´ch procesoru (viz take´ obra´zek 3): 1. Nejprve ulozˇ´ıme parametry. Dle konvence C ukla´da´me parametry zprava doleva. (push ) 2. Vola´me podprogram , tı´m se na za´sobnı´k ulozˇ´ı adresa na´vratu. (call ) 3. Program da´le pokracˇuje jizˇ v podprogramu. Prvnı´ instrukcı´ kazˇde´ho podprogramu musı´ by´t ulozˇenı´ registru ebp, kde je odkaz na ra´mec nadrˇazene´ho podprogramu. (push ebp) 4. Nynı´ do ebp ulozˇ´ıme aktua´lnı´ esp, cˇ´ımzˇ si ulozˇ´ıme odkaz na pozici nasˇeho ra´mce. (mov ebp,esp) 5. Vytvorˇ´ıme potrˇebny´ prostor pro loka´lnı´ promeˇnne´. (sub esp,) 6. Vsˇechny registry kromeˇ eax, ktere´ budeme meˇnit, ulozˇ´ıme na za´sobnı´k. (push) ... Parametr n ... Parametr 1 Na´vratova´ adresa Pu˚vodnı´ ebp Prvnı´ loka´lnı´ promeˇnna´ ... Poslednı´ loka´lnı´ promeˇnna´ ...

←− ebp+8 ←− ebp ←− ebp–4 ←− esp

Obra´zek 3: Data na za´sobnı´ku v okamzˇiku vola´nı´ podprogramu Nynı´ mu˚zˇe beˇzˇet vlastnı´ ko´d podprogramu. Vstupnı´ parametry jsou prˇ´ıstupne´ na adresa´ch ebp+x, loka´lnı´ promeˇnne´ pak na adresa´ch ebp-x. Prvnı´ parametr je na adrese ebp+8, dalsˇ´ı ebp+12 atd. Prvnı´ loka´lnı´ promeˇnna´ pak na adrese ebp-4, dalsˇ´ı ebp-8 atd. (Na adrese ebp je navı´c odkaz na ra´mec nadrˇazene´ funkce, na adrese ebp+4 je na´vratova´ adresa. Tyto dveˇ hodnoty samozrˇejmeˇ nesmı´me meˇnit.)

29

Ebp ukazuje na dno za´sobnı´ku.

Pru˚vodce studiem Programujete-li ve Visual C++, vypneˇte si v Project Properties/Code Generation polozˇku Basic Runtime Checks. Je-li totizˇ zapnuta´, prˇekladacˇ ukla´da´ na za´sobnı´k rˇadu dalsˇ´ıho smetı´, cˇ´ımzˇ se snazˇ´ı kontrolovat chyby prˇi pouzˇ´ıva´nı´ pameˇti. Acˇkoliv tyto kontroly jsou vynikajı´cı´m pomocnı´kem, znemozˇnˇujı´ na´m studium Assembleru. Proto je lepsˇ´ı je vypnout. Rˇa´dne´ ukoncˇenı´ podprogramu provedeme pomocı´ opacˇne´ sekvence kroku˚: 1. Nejprve obnovı´me hodnoty vsˇech zmeˇneˇny´ch registru˚. (pop) 2. Zrusˇ´ıme prostor pro loka´lnı´ promeˇnne´. Vyuzˇijeme prˇitom faktu, zˇe pu˚vodnı´ esp ma´me ulozˇene´ v ebp. (mov esp,ebp) 3. Obnovı´me ukazatel na ra´mec nadrˇazene´ho vola´nı´. (pop ebp) 4. Provedeme na´vrat. (ret) Nynı´ je rˇ´ızenı´ prˇeda´no zpeˇt volajı´cı´mu. Ten musı´ nejprve uklidit ze za´sobnı´ku vsˇechny prˇedane´ parametry vola´nı´. (add esp,<pocˇet*4>) Pru˚vodce studiem Zatı´mco porˇadı´ parametru˚ je prˇi vola´nı´ velmi du˚lezˇite´, u loka´lnı´ch promeˇnny´ch tomu tak nenı´. Kdyzˇ si prostor pro promeˇnne´ vytva´rˇ´ıme sami, tak pochopitelneˇ pouze my vı´me, ktera´ jeho cˇa´st je pro kterou promeˇnnou. Syste´m nejle´pe sami pochopı´te, kdyzˇ si jej vyzkousˇ´ıte v praxi.

Dalsˇ´ı hardwarova´ podpora vola´nı´ Procesory x86 majı´ pocˇ´ınaje modelem 80286 podporu pro vytva´rˇenı´ a u´klid ra´mcu˚ na za´sobnı´ku v podobeˇ dvou doplnˇkovy´ch instrukcı´. Dnes se tyto instrukce prˇ´ılisˇ nepouzˇ´ıvajı´, uplatneˇnı´ vsˇak najdou v jazycı´ch s dynamicky´m rozsahem platnosti promeˇnny´ch, jako je Turbo Pascal. Instrukce enter vykona´ u´vodnı´ sekvenci podprogramu, instrukce leave vykona´ za´veˇrecˇnou sekvenci. Tyto instrukce jsou vsˇak na soucˇasny´ch procesorech prˇi beˇhu pomalejsˇ´ı, nezˇ kdyzˇ vsˇe napı´sˇete rucˇneˇ pomocı´ za´kladnı´ch instrukcı´, jak bylo popsa´no vy´sˇe. Proto je jejich vyuzˇitı´ (mimo zmı´neˇny´ Turbo Pascal) prakticky nulove´.

3.3

Prˇerusˇenı´

Jak jizˇ vı´me, prˇerusˇenı´ je jednı´m z velmi du˚lezˇity´ch prvku˚ pocˇ´ıtacˇu˚. Je to veˇc, ktera´ se ty´ka´ hardwaru i softwaru. Pu˚vodneˇ prˇerusˇenı´ slouzˇilo zejme´na k reagova´nı´ na asynchronnı´ uda´losti2 . Nejcˇasteˇjsˇ´ım prˇ´ıpadem asynchronnı´ uda´losti je, kdyzˇ I/O zarˇ´ızenı´ chce komunikovat s procesorem. V okamzˇiku, kdyzˇ zarˇ´ızenı´ chce procesoru neˇco sdeˇlit, vyvola´ prˇerusˇenı´. Cˇinnost procesoru je v tomto okamzˇiku prˇerusˇena a tento prˇejde do specia´lnı´ho podprogramu zvane´ho obsluha prˇerusˇenı´. To, jaky´m zpu˚sobem procesor vı´, kde ma´ obsluhu prˇerusˇenı´, a jak od sebe rozlisˇ´ı jednotliva´ prˇerusˇenı´, se na jednotlivy´ch pocˇ´ıtacˇ´ıch mu˚zˇe dosti lisˇit. Prˇerusˇenı´ vsˇak nasta´va´ vzˇdy po vykona´nı´ cele´ instrukce; prˇerusˇit program uprostrˇed neˇjake´ instrukce nelze. (Vy´jimkou je neosˇetrˇitelna´ chyba, kdy je vykona´nı´ instrukce prˇerusˇeno a zrusˇeno.) Veˇtsˇina procesoru˚ navı´c take´ obsahuje instrukce, ktery´mi je mozˇno prˇerusˇenı´ vyvolat programoveˇ. Toto je pak velmi podobne´ obycˇejne´mu vola´nı´ podprogramu. Rozdı´l je v tom, zˇe prˇi 2

Asynchronnı´ uda´lost je takova´, se kterou se prˇedem nepocˇ´ıta´. Nastane nepla´novaneˇ.

30

vola´nı´ podprogramu musı´me vzˇdy uve´st adresu tohoto podprogramu, zatı´mco prˇi vyvola´nı´ prˇerusˇenı´ jen uvedeme ko´d prˇerusˇenı´ (cˇ´ıslo) a procesor vykona´ podprogram obsluhy prˇerusˇenı´. V dalsˇ´ıch odstavcı´ch se opeˇt podı´va´me, jak prˇerusˇenı´ funguje na procesorech x86. Pru˚vodce studiem Prˇ´ıkladem I/O zarˇ´ızenı´ mu˚zˇe by´t kla´vesnice. Stisk kla´vesy je asynchronnı´ uda´lost, o ktere´ se procesor dozvı´ dı´ky prˇerusˇenı´, ktere´ kla´vesnice v okamzˇiku stisku vyvola´. Procesor tak prˇejde na obsluhu kla´vesnice, cozˇ je velmi kra´tky´ podprogram. Po nacˇtenı´ stisknute´ kla´vesy z kla´vesnice skoncˇ´ı obsluha prˇerusˇenı´ a opeˇt pokracˇuje pu˚vodnı´ program.

Pru˚vodce studiem Prˇerusˇenı´ se v pocˇ´ıtacˇ´ıch pouzˇ´ıvajı´ ve velke´ mı´rˇe. Drˇ´ıve tomu tak vsˇak nebylo. Naprˇ. pra´veˇ obsluha kla´vesnice prˇerusˇenı´m je mozˇna´ pouze tehdy, kdyzˇ kla´vesnice ma´ vlastnı´ inteligenci. Pokud by ji nemeˇla, musel by procesor v pravidelny´ch intervalech sa´m kontrolovat macˇka´nı´ kla´ves. Extre´mnı´m prˇ´ıkladem, jak se v historii o vsˇe staral sa´m procesor, je kreslenı´ obrazu. Zatı´mco dnes toto zajisˇt’uje graficka´ karta, v da´vneˇjsˇ´ı minulosti to zajisˇt’oval procesor. Veˇtsˇinu vy´pocˇetnı´ho cˇasu tak samozrˇejmeˇ stra´vil pra´veˇ vykreslova´nı´m obrazu, ale takovy´ pocˇ´ıtacˇ byl samozrˇejmeˇ mnohem levneˇjsˇ´ı, nezˇ kdyby musel obsahovat vlastnı´ cˇip pro kreslenı´ obrazu. Naprˇ. Sinclair ZX81 (viz obra´zek 4) z roku 1981 beˇzˇel jen na cˇtvrtineˇ vy´konu, zbytek byl pouzˇit pro kreslenı´. Obraz vsˇak sˇel programoveˇ vypnout (cˇ´ımzˇ se pocˇ´ıtacˇ 4× zrychlil).

Obra´zek 4: Pocˇ´ıtacˇ Sinclair ZX81 Prˇerusˇenı´ jsou obsluhova´na ve spolupra´ci hardwaru (procesoru) a softwaru (operacˇnı´ho syste´mu). V okamzˇiku pozˇadavku prˇerusˇenı´ se nejprve dokoncˇ´ı aktua´lnı´ instrukce. Pak procesor sa´m ulozˇ´ı aktua´lnı´ stav vykona´va´nı´ programu (cˇili prˇedevsˇ´ım na´vratovou adresu) na za´sobnı´k a prˇejde na obsluhu prˇerusˇenı´. Operacˇnı´ syste´m se stara´ o tabulku adres obsluzˇny´ch podprogramu˚. Procesor x86 ma´ registr IDTR obsahujı´cı´ deskriptor tabulky IDT. IDTR tedy ukazuje na IDT, 31

cozˇ je seznam deskriptoru˚ jednotlivy´ch obsluzˇny´ch podprogramu˚. Tyto podprogramy mohou by´t i v jine´m procesu, nezˇ pra´veˇ beˇzˇ´ı. V tom prˇ´ıpadeˇ procesor ulozˇ´ı svu˚j kompletnı´ stav a prˇepne se do kontextu onoho procesu, ktery´ ma´ zajistit obsluhu prˇerusˇenı´. Zde tedy jde o pomeˇrneˇ slozˇitou hardwaroveˇ podporˇenou operaci, podrobnosti odlozˇ´ıme na pozdeˇji. Samotny´ obsluzˇny´ podprogram pochopitelneˇ klasicky ulozˇ´ı vsˇechny registry, ktere´ bude meˇnit, a chova´ se te´meˇrˇ stejneˇ jako kazˇdy´ jiny´ podprogram. Na konci ma´ pak specia´lnı´ instrukci iret, kterou aktivuje proces na´vratu z prˇerusˇenı´. Je-li adresa na´vratu v jine´m procesu, procesor obnovı´ drˇ´ıve ulozˇeny´ stav a prˇejde do pu˚vodnı´ho kontextu. Pak pokracˇuje ve vykona´va´nı´ pu˚vodnı´ho programu. Beˇhem obsluhy prˇerusˇenı´ je dalsˇ´ı prˇerusˇenı´ zaka´za´no. Slouzˇ´ı k tomu specia´lnı´ prˇ´ıznak (bit v registru eflags). Je vsˇak zvykem, zˇe je-li to mozˇne´, obsluzˇny´ podprogram prˇerusˇenı´ opeˇt povolı´. Mu˚zˇe pak nastat situace, zˇe procesor je prˇerusˇen z prˇerusˇenı´. Na konci obsluhy prˇerusˇenı´ je prˇ´ıznak prˇerusˇenı´ kazˇdopa´dneˇ nastaven do pu˚vodnı´ho stavu, v jake´m byl prˇed prˇerusˇenı´m. Vy´sˇe popsany´ syste´m s registrem IDTR pouzˇ´ıva´ na pocˇ´ıtacˇ´ıch PC naprˇ. syste´m Windows. Naproti tomu MS–DOS pouzˇ´ıval jednodusˇsˇ´ı syste´m, dany´ pouzˇity´m procesorem Intel 8088: Prvnı´ch 1024 bajtu˚ fyzicke´ pameˇti je vyhrazeno pro 256 adres obsluh prˇerusˇenı´. Kazˇde´ prˇerusˇenı´ ma´ tedy 4bajtovou adresu, cˇili klasicky segment + offset. Prˇi prˇerusˇenı´ jsou na za´sobnı´k ulozˇeny jen registry CS, IP a FLAGS, da´l nic. Syste´m pouzˇity´ v MS–DOSu umozˇnˇuje, aby libovolny´ program prˇepsal adresu obsluhy prˇerusˇenı´ z pu˚vodnı´ho podprogramu na sebe. Toho vyuzˇ´ıvaly viry – „poveˇsily“ se na obsluhy du˚lezˇity´ch prˇerusˇenı´ a mohly tak ovlivnit, co se stane prˇed cˇi po zavola´nı´ skutecˇne´ obsluhy. Tento ra´j viru˚ byl samozrˇejmeˇ na obtı´zˇ, proto se pozdeˇji od tohoto zpu˚sobu obsluhy prˇerusˇenı´ ustoupilo. (Vyzˇa´dalo si to novy´ mikroprocesor. Samotny´ operacˇnı´ syste´m bez hardwarove´ podpory dokonalou bezpecˇnost zarucˇit nemu˚zˇe. MS–DOS prˇitom zu˚stal u pu˚vodnı´ho syste´mu azˇ do poslednı´ verze, dal tedy prˇed vysˇsˇ´ı bezpecˇnostı´ prˇednost veˇtsˇ´ı zpeˇtne´ kompatibiliteˇ.) IDTR a IDT jsou operacˇnı´m syste´mem chra´neˇny proti zmeˇna´m, takzˇe ve Windows jizˇ viry prakticky neexistujı´. (Acˇkoliv existuje cela´ rˇada jiny´ch sˇkodlivy´ch programu˚, ktery´m laici obvykle rˇ´ıkajı´ „viry“, skutecˇne´ viry v pu˚vodnı´m slova smyslu ve Windows opravdu te´meˇrˇ nejsou.) Hardwaroveˇ je prˇerusˇenı´ na pocˇ´ıtacˇ´ıch PC jesˇteˇ podporˇeno syste´mem priorit. Prˇerusˇenı´ vysˇsˇ´ı priority mu˚zˇe prˇerusˇit beˇzˇ´ıcı´ obsluhu prˇerusˇenı´ nizˇsˇ´ı priority, ale ne naopak. Objevı´-li se pozˇadavek prˇerusˇenı´ v okamzˇiku, kdy je prˇerusˇenı´ zaka´za´no (nastavenı´m prˇ´ıznaku prˇerusˇenı´), pocˇ´ıtacˇ si jej pamatuje a vyvola´ jej pozdeˇji, jakmile bude prˇerusˇenı´ povoleno. Tato „pameˇt’na prˇerusˇenı´ “ je samozrˇejmeˇ limitova´na, ale obvykle stacˇ´ı. Shrnutı´ Tato kapitola se veˇnovala rˇ´ızenı´ vy´pocˇtu, cozˇ je te´ma volneˇ navazujı´cı´ na vykona´va´nı´ jednotlivy´ch instrukcı´ probrane´ v kapitole prˇedchozı´. Dozveˇdeˇli jsme se, zˇe za´kladem je vykona´va´nı´ instrukcı´ v tom porˇadı´, v jake´m jsou zapsane´ za sebou v pameˇti. Da´le jsme se veˇnovali skoku˚m, prˇerusˇenı´ a podprogramu˚m, ktery´mi lze vy´pocˇet veˇtvit cˇi strukturovat. V te´to souvislosti jsme zcela vynechali problematiku podmı´neˇne´ho vykona´va´nı´ ko´du, ktere´ bude veˇnova´n cˇas zejme´na na cvicˇenı´ch (prˇedmeˇtu Operacˇnı´ syste´my) a take´ je probra´na v publikaci [Kep08a]. Naopak jsme se ale podrobneˇ veˇnovali za´sobnı´ku a sezna´mili jsme se s tı´m, jak je tento konstrukt vyuzˇ´ıva´n prˇi prˇerusˇenı´, vola´nı´ podprogramu˚, prˇeda´va´nı´ parametru˚ apod. Pochopenı´, jak funguje za´sobnı´k a co vsˇe dı´ky neˇmu pocˇ´ıtacˇ doka´zˇe, take´ patrˇ´ı k za´kladnı´m cı´lu˚m u´vodnı´ch kapitol tohoto kurzu. Tato kapitola take´ uzavı´ra´ u´vodnı´ blok, ktery´ se veˇnuje spı´sˇe samotne´mu pocˇ´ıtacˇi, ktery´ jsme si prˇedstavili jako komplexnı´ syste´m (stroj) skla´dajı´cı´ se z hardwaru a softwaru. Na´sledujı´cı´ kapitoly se pak budou veˇnovat me´neˇ hardwarove´mu a naopak vı´ce softwarove´mu pohledu na pocˇ´ıtacˇ, protozˇe operacˇnı´ syste´my, ktere´ na´s zajı´majı´ prˇedevsˇ´ım, patrˇ´ı mezi software. Pojmy k zapamatova´nı´ 32

• • • • • • •

skok – podmı´neˇny´ a nepodmı´neˇny´ vola´nı´ podprogramu konvence prˇeda´va´nı´ parametru˚ obsluha prˇerusˇenı´ IDT (interrupt descriptor table) a IDTR vrchol a dno za´sobnı´ku stack frame (ra´mec vola´nı´ na za´sobnı´ku)

Kontrolnı´ ota´zky 1. 2. 3. 4. 5. 6.

7. 8.

9.

Vyjmenujte za´kladnı´ druhy instrukcı´ vedoucı´ch ke zmeˇneˇ porˇadı´ vykona´va´nı´ instrukcı´. Vysveˇtlete rozdı´l mezi skokem, vola´nı´m podprogramu a prˇerusˇenı´m. Ktery´ zpu˚sob prˇeda´va´nı´ parametru˚ do podprogramu˚ je nejvy´hodneˇjsˇ´ı? Proved’te diskuzi. Popisˇte podrobneˇ, co se deˇje na za´sobnı´ku prˇi vola´nı´ funkce od jeho prˇ´ıpravy azˇ po na´vrat. Kdy prˇesneˇ vznika´ a zanika´ ra´mec vola´nı´ funkce na za´sobnı´ku? Proved’te diskuzi. Jak byste implementovali prˇ´ıstup k loka´lnı´m promeˇnny´m a parametru˚m funkce, kdyby kromeˇ vrcholu za´sobnı´ku (esp) nebyl k dispozici druhy´ registr (ebp)? Diskutujte vy´hody a nevy´hody takove´ho rˇesˇenı´. Kdy se procesor mu˚zˇe nebo nemu˚zˇe prˇerusˇit? Uved’te vsˇechna pravidla. Syste´m MS-DOS byl na´chylny´ na viry, protozˇe do syste´move´ tabulky obsluh prˇerusˇenı´ mohl kdokoliv zapisovat cokoliv. Diskutujte mozˇne´ zpu˚soby rˇesˇenı´ te´to situace (a) s pomocı´ hardwaru a (b) bez pomoci hardwaru. Jak uzˇ vı´me, polozˇky IDT mohou odkazovat take´ do cizı´ch procesu˚. Uved’te mozˇna´ vyuzˇitı´ takove´ vzda´lene´ vazby.

33

4

Operacˇnı´ syste´m

Studijnı´ cı´le: Po u´vodnı´ch trˇech kapitola´ch, ve ktery´ch jsme se sezna´mili s pocˇ´ıtacˇem a jeho fungova´nı´m, se nynı´ dosta´va´me k samotne´mu operacˇnı´mu syste´mu. Tato kapitola je tedy jaky´msi druhy´m u´vodem v tomto kurzu a studenti budou sezna´meni s tı´m, co to vlastneˇ je operacˇnı´ syste´m, procˇ vlastneˇ existujı´ operacˇnı´ syste´my a jake´ jsou jejich za´kladnı´ funkce. Klı´cˇova´ slova: operacˇnı´ syste´m, rozhranı´ syste´mu, sa´lovy´ pocˇ´ıtacˇ, osobnı´ pocˇ´ıtacˇ Potrˇebny´ cˇas: 80 minut.

4.1

Co je to operacˇnı´ syste´m

V prˇedchozı´ch kapitola´ch jsme se dı´vali na pocˇ´ıtacˇ z pohledu hardwaru a rozdeˇlili jsme ho na 3 za´kladnı´ cˇa´sti: CPU, operacˇnı´ pameˇt’ a I/O zarˇ´ızenı´. Kdyzˇ se vsˇak na stejny´ stroj (pocˇ´ıtacˇ) podı´va´me z pohledu softwarove´ho, vidı´me jeho strukturu zcela jinak: hardware, operacˇnı´ syste´m a aplikacˇnı´ programy. Jak mu˚zˇete videˇt na obra´zku 5, operacˇnı´ syste´m je jaky´msi prostrˇednı´kem mezi hardwarem a aplikacˇnı´mi programy.

Program 1

Program 2

Program 3

Operacˇnı´ syste´m

Hardware Obra´zek 5: Softwarova´ struktura pocˇ´ıtacˇe Jak uzˇ vı´me, jednı´m z du˚vodu˚ vzniku a existence operacˇnı´ho syste´mu (da´le jen OS) je velka´ slozˇitost hardwaru pocˇ´ıtacˇe. OS je za´kladnı´m programem v pocˇ´ıtacˇi, ktery´ nabı´zı´ vysˇsˇ´ı u´rovenˇ abstrakce prˇi pra´ci s hardwarem, cˇ´ımzˇ velkou meˇrou zjednodusˇuje ostatnı´ programy. Du˚lezˇity´m poznatkem tedy je, a vidı´me to i na obra´zku 5, zˇe OS ma´ dveˇ odlisˇna´ rozhranı´: jednı´m komunikuje s hardwarem, druhy´m komunikuje s ostatnı´mi programy, ktere´ obvykle deˇlı´me na syste´move´ – ty poma´hajı´ operacˇnı´mu syste´mu – a aplikacˇnı´ – ty slouzˇ´ı prˇ´ımo uzˇivatelu˚m (lidem). Dalsˇ´ı pohled na vy´znam OS je zrˇejmy´ kazˇde´mu, kdo neˇkdy pracoval s PC: Operacˇnı´ syste´m umozˇnˇuje, aby v pocˇ´ıtacˇi soucˇasneˇ beˇzˇelo vı´ce programu˚ nezˇ jeden. Obecneˇ lze rˇ´ıci, zˇe hardwarova´ podpora pro soubeˇh programu˚ je cˇi mu˚zˇe by´t jen velmi mala´, zatı´mco pra´veˇ OS k umozˇneˇnı´ soubeˇhu prˇispı´va´ velmi velkou meˇrou. Z hlediska soubeˇhu aplikacı´ musı´ OS prˇedevsˇ´ım prova´deˇt pecˇlivou a spravedlivou spra´vu zdroju˚ – dle typu jednotlivy´ch soucˇa´stı´ pocˇ´ıtacˇe jsou tyto dı´ky operacˇnı´mu syste´mu bud’ rozdeˇlova´ny mezi aplikace (naprˇ. operacˇnı´ pameˇt’), sdı´leny v pravidelny´ch cˇasovy´ch u´secı´ch (naprˇ. CPU), prˇideˇlova´ny do docˇasne´ho vy´hradnı´ho vlastnictvı´ (naprˇ. kla´vesnice) cˇi virtualizova´ny pro umozˇneˇnı´ transparentnı´ho sdı´lenı´ funkcionality (naprˇ. obrazovka, tiska´rna, disk, reproduktory). Fakt, zˇe OS ma´ kromeˇ vneˇjsˇ´ıho rozhranı´, ktery´m nabı´zı´ svou funkcionalitu ostatnı´m programu˚m, take´ druhe´ vnitrˇnı´ rozhranı´, umozˇnˇuje, aby stejny´ operacˇnı´ syste´m a potazˇmo stejne´ aplikace byly provozova´ny na ru˚zny´ch pocˇ´ıtacˇ´ıch. V soucˇasnosti jsou nejveˇtsˇ´ı rozdı´ly zrˇejmeˇ na poli 34

OS ma´ dveˇ odlisˇna´ rozhranı´.

OS zajisˇt’uje spra´vu zdroju˚.

graficky´ch karet – zatı´mco hardwarova´ rˇesˇenı´ jednotlivy´ch vy´robcu˚ majı´ spolu jen velmi ma´lo spolecˇne´ho, uzˇivatel teˇzˇko uvidı´ neˇjaky´ rozdı´l v chova´nı´ pocˇ´ıtacˇe. (Naopak nejmensˇ´ı pokrok v te´to oblasti je jizˇ tradicˇneˇ na poli CPU – provozova´nı´ stejny´ch programu˚ na jine´m procesoru nenı´ obvykle mozˇne´.) Acˇkoliv je videˇt, zˇe OS je du˚lezˇitou soucˇa´stı´ pocˇ´ıtacˇe, prˇesna´ definice, co je to operacˇnı´ syste´m, neexistuje. Kazˇdy´ pocˇ´ıtacˇ ma´ jiny´ u´cˇel, proto take´ jednotlive´ operacˇnı´ syste´my se lisˇ´ı. OS je jednou ze soucˇa´stı´ pocˇ´ıtacˇe, ktera´ se podı´lı´ na tom, aby tento u´cˇel byl naplneˇn. OS mu˚zˇe mı´t mnoho podob. Literatura take´ neˇkdy cynicky definuje operacˇnı´ syste´m jako „to, co dostanete, kdyzˇ si objedna´te „operacˇnı´ syste´m““ (viz [SGG05]). Jina´, pragmaticˇteˇjsˇ´ı definice rˇ´ıka´, zˇe operacˇnı´ syste´m je „to, co beˇzˇ´ı prˇi kazˇde´m provozu pocˇ´ıtacˇe“. Tato definice zohlednˇuje pra´veˇ i rozdı´ly mezi ru˚zny´mi pocˇ´ıtacˇi. Na male´m zabudovane´m pocˇ´ıtacˇi jsou logicky i funkce operacˇnı´ho syste´mu omezeny – nenı´ zde syste´m oken, ani podpora pra´ce s hard diskem. Naopak na PC si dnes pra´ci bez oken cˇi hard disku teˇzˇko dovedeme prˇedstavit, jsou to tedy dveˇ ze za´kladnı´ch soucˇa´stı´ operacˇnı´ho syste´mu. Pru˚vodce studiem Definice operacˇnı´ho syste´mu v poslednı´ch letech take´ velmi zajı´ma´ antimonopolnı´ u´rˇady v mnoha zemı´ch sveˇta. Du˚vodem je Microsoft a jeho syste´m Windows, ktery´ dle na´zoru˚ konkurencˇnı´ch firem ma´ uzˇ funkcı´ prˇ´ılisˇ mnoho. Uzˇivatelu˚m takto bohateˇ vybaveny´ syste´m samozrˇejmeˇ vyhovuje, u´rˇady v neˇktery´ch zemı´ch vsˇak uzˇ neˇkolikra´t narˇ´ıdily, aby Microsoft neˇktere´ cˇa´sti ze sve´ho operacˇnı´ho syste´mu odstranil. Z dlouhodobe´ho hlediska je prˇ´ıstup u´rˇadu˚ jisteˇ spra´vny´ – zatı´mco dnes uzˇivatele´ prˇijdou o cˇa´st softwaru, ktery´ „byl v ceneˇ“, v budoucnu lze dı´ky hospoda´rˇske´ souteˇzˇi ocˇeka´vat bohatsˇ´ı nabı´dku s mnoha alternativami ru˚zny´ch vy´robcu˚.

Cı´le operacˇnı´ho syste´mu Jednodusˇsˇ´ı nezˇ odpoveˇdeˇt na ota´zku: Co to je operacˇnı´ syste´m?, mu˚zˇe by´t odpoveˇdeˇt na ota´zku: Co operacˇnı´ syste´m deˇla´? Co jsou jeho cı´le? Operacˇnı´ syste´m umozˇnˇuje uzˇivatelu˚m snazsˇ´ı pra´ci s pocˇ´ıtacˇem. Na prˇ´ıkladu vy´sˇe zmı´neˇne´ho syste´mu oken je toto velmi zrˇetelne´ a je to mozˇna´ i za´kladnı´ cı´l operacˇnı´ho syste´mu na PC. Na jiny´ch pocˇ´ıtacˇ´ıch je zase prima´rnı´m cı´lem efektivnı´ vyuzˇitı´ hardwaru, ktery´ je k dispozici. Toto je praxı´ u pocˇ´ıtacˇu˚ hodneˇ drahy´ch (naprˇ. velka´ vy´pocˇetnı´ centra) cˇi drahy´ch vzhledem k jejich vyuzˇitı´ (naprˇ. nema´ smysl da´vat PC do automaticke´ pracˇky, kdyzˇ by tı´m rˇ´ıdicı´ pocˇ´ıtacˇ byl drazˇsˇ´ı nezˇ cely´ zbytek pracˇky). Zajı´mave´ je, zˇe tyto dva alternativnı´ cı´le jsou cˇasto oba prˇ´ınosne´, ale jsou take´ ve sporu – zvysˇova´nı´m uzˇivatelske´ prˇ´ıveˇtivosti totizˇ snizˇujeme efektivitu vyuzˇitı´ hardwaru a obra´ceneˇ. V historii byly pocˇ´ıtacˇe prˇece jen dosti pomale´, proto velmi vy´razneˇ prˇevazˇoval pra´veˇ pozˇadavek jejich efektivnı´ho vyuzˇitı´. Toto take´ mnoho let determinovalo vy´voj v oblasti operacˇnı´ch syste´mu˚ i studia jejich teorie. Pru˚vodce studiem Za´veˇr prˇedchozı´ho odstavce diplomaticky rˇ´ıka´, zˇe studium operacˇnı´ch syste´mu˚ je z historicky´ch du˚vodu˚ zameˇrˇeno na te´mata ty´kajı´cı´ se efektivnı´ho vyuzˇitı´ zdroju˚ v pocˇ´ıtacˇi a naopak prakticky ignorova´na je ota´zka graficke´ho uzˇivatelske´ho rozhranı´, ktere´ je dnes velmi aktua´lnı´m te´matem u operacˇnı´ch syste´mu˚ z hlediska uzˇivatelu˚. Autor te´to ucˇebnice zasta´va´ na´zor, zˇe ota´zky graficke´ho uzˇivatelske´ho rozhranı´ urcˇiteˇ patrˇ´ı do studia operacˇnı´ch syste´mu˚ a zˇe tam chybı´ pouze z du˚vodu historicky´ch – autorˇi ucˇebnic i ucˇitele´ se v te´to oblasti jako dinosaurˇi sta´le drzˇ´ı te´mat zavedeny´ch jizˇ v 70.letech 20.stoletı´. Ne nadarmo jsou dinosaurˇi take´ u´strˇednı´m graficky´m motivem knihy [SGG05].

35

Prima´rnı´ cı´le OS: Pocˇ´ıtacˇ ma´ by´t prˇ´ıjemny´ a pracovat efektivneˇ.

Dı´ky tomu, zˇe OS vystupuje jako spra´vce vsˇech hardwarovy´ch zdroju˚ (soucˇa´stı´ pocˇ´ıtacˇe), snazˇ´ı se take´ zajistit urcˇitou bezpecˇnost. Naprˇ. kdyzˇ si jeden program zalozˇ´ı soubor na disku, ostatnı´ programy do tohoto souboru nic zapisovat nesmı´. Tento typ bezpecˇnosti stojı´ na tom, zˇe OS odstinˇuje jednotlive´ programy a tyto o sobeˇ navza´jem pokud mozˇno ani nevı´. Pro maxima´lnı´ bezpecˇnost je samozrˇejmeˇ nutna´ jista´ podpora hardwaru, ale za´kladnı´ u´rovenˇ odstı´neˇnı´ aplikacı´ doka´zˇe zajistit jizˇ sa´m operacˇnı´ syste´m. Naprˇ. tisk na tiska´rneˇ byl jizˇ na starsˇ´ıch verzı´ch Windows (98 a drˇ´ıve) rozumneˇ osˇetrˇen a nebyly s nı´m zˇa´dne´ potı´zˇe, prˇestozˇe technicky tehdy aplikacı´m nic nebra´nilo, aby tisk ostatnı´ch aplikacı´ porusˇily.

4.2

Aplikace na sebe navza´jem nevidı´.

Typy syste´mu˚

O tom, zˇe existujı´ ru˚zne´ typy pocˇ´ıtacˇovy´ch syste´mu˚, jsme se jizˇ zmı´nili v kapitole 1. Vı´me take´, zˇe tato rozmanitost je vy´sledkem jejich historicke´ho vy´voje a take´ obrazem toho, zˇe kazˇdy´ pocˇ´ıtacˇ je prima´rneˇ urcˇen k jine´mu u´cˇelu. Nynı´ se k tomuto te´matu vra´tı´me a uvedeme si za´kladnı´ typy pocˇ´ıtacˇovy´ch syste´mu˚ ze softwarove´ho hlediska. Pru˚vodce studiem Jak lze vypozorovat z popisu v na´sledujı´cı´ch odstavcı´ch, mnoho vlastnostı´ pu˚vodneˇ specificky´ch jen pro velke´ sa´love´ pocˇ´ıtacˇe se postupneˇ dosta´valo a dosta´va´ do pocˇ´ıtacˇu˚ mensˇ´ıch a mensˇ´ıch. Tento trend je vsˇeobecneˇ platny´ – postupne´ zmensˇova´nı´ hardwaru umozˇnˇuje nasazovat pocˇ´ıtacˇe do sta´le vı´ce rozmeˇroveˇ cˇi energeticky na´rocˇneˇjsˇ´ıch prostrˇedı´. Nejprve se tam vsˇak vzˇdy objevı´ pocˇ´ıtacˇe jednoduche´, jakoby vzate´ z historie, a pozdeˇji se jejich „dokonalost“ zvysˇuje a jejich mozˇnosti se sblizˇujı´ s pocˇ´ıtacˇi veˇtsˇ´ımi.

4.2.1

Sa´love´ pocˇ´ıtacˇe

Jak vı´me, prvnı´mi prakticky uzˇitecˇny´mi pocˇ´ıtacˇi byly sa´love´ pocˇ´ıtacˇe z doby kolem konce 2. sveˇtove´ va´lky. Prvnı´ pocˇ´ıtacˇe zpracova´valy da´vkove´ u´lohy. Beˇhem vy´pocˇtu nebyla interakce s uzˇivatelem mozˇna´ – cˇili programa´tor dodal program (u´lohu), opera´tor jej dal do pocˇ´ıtacˇe (naprˇ. ve formeˇ deˇrne´ pa´sky) a po zaha´jenı´ vy´pocˇtu se cˇekalo, dokud pocˇ´ıtacˇ nedodal vy´sledek. Ten pak opera´tor odevzdal programa´torovi. Pocˇ´ıtacˇ pak zaha´lel, dokud opera´tor neprˇipravil k vy´pocˇtu dalsˇ´ı program (u´lohu). Tento zpu˚sob vyuzˇitı´ byl znacˇneˇ neefektivnı´, pra´veˇ proto se jednotlive´ u´lohy spojovaly do da´vek. Pocˇ´ıtacˇ pak dosta´val u´lohy po da´vka´ch – po vykona´nı´ jedne´ u´lohy mohl okamzˇiteˇ pokracˇovat na dalsˇ´ı u´loze a nezaha´lel cˇeka´nı´m na opera´tora. Da´vkove´ zpracova´nı´ vsˇak prˇedevsˇ´ım umozˇnilo, aby pocˇ´ıtacˇ efektivneˇ vyuzˇ´ıval sve´ zdroje. Za´kladnı´ model zpracova´nı´ ma´ totizˇ za´sadnı´ vy´konnostnı´ hrdlo v tom, zˇe zarˇ´ızenı´, ze ktere´ho cˇte data (drˇ´ıve deˇrne´ sˇtı´tky, pozdeˇji magneticke´ pa´sky, dnes magneticke´ cˇi opticke´ disky), je podstatneˇ pomalejsˇ´ı nezˇ samotny´ procesor, takzˇe prˇi sekvencˇnı´m (tj. postupne´m) zpracova´va´nı´ u´loh pocˇ´ıtacˇ neusta´le zaha´lı´ cˇeka´nı´m na nacˇtenı´ vstupnı´ch dat. Prˇi zavedenı´ da´vkove´ho zpracova´nı´ mu˚zˇe pocˇ´ıtacˇ (s pomocı´ vhodne´ho operacˇnı´ho syste´mu) zpracova´vat vı´ce u´loh soucˇasneˇ. V jednom okamzˇiku mu˚zˇe jeden pocˇ´ıtacˇ samozrˇejmeˇ zpracova´vat jen jednu u´lohu. Jakmile vsˇak nastane situace, kdy procesor musı´ cˇekat na externı´ zarˇ´ızenı´ (nejcˇasteˇji nacˇtenı´ vstupnı´ch cˇi za´pis vy´stupnı´ch dat), namı´sto zaha´lky prˇejde k vykona´va´nı´ dalsˇ´ı u´lohy. Jakmile by tato na neˇco meˇla cˇekat, procesor opeˇt prˇejde k dalsˇ´ı u´loze, atd. V okamzˇiku, kdy neˇktera´ z pozastaveny´ch u´loh mu˚zˇe pokracˇovat, procesor se k nı´ vra´tı´ a bude s nı´ pokracˇovat. Pokud tedy opera´tor doda´va´ dostatecˇny´ pocˇet u´loh, pocˇ´ıtacˇ je efektivneˇ vyuzˇit a nikdy nezaha´lı´. Tento model zpracova´nı´ u´loh se nazy´va´ multiprogramova´nı´.

36

Multiprogramova´nı´ – v pocˇ´ıtacˇi je soucˇasneˇ vı´ce programu˚.

Pru˚vodce studiem Multiprogramova´nı´ je beˇzˇne´ i u lidı´. Naprˇ. pra´vnı´k take´ nema´ jen jednoho klienta – spoustu cˇasu by totizˇ jen sedeˇl a cˇekal na vyrˇ´ızenı´ neˇjaky´ch zˇa´dostı´ o dokumenty, o ktere´ zˇa´dal a ktere´ majı´ prˇijı´t posˇtou, atp. Tı´m, zˇe ma´ pra´vnı´k vı´ce klientu˚ a dle svy´ch cˇasovy´ch mozˇnostı´ se veˇnuje kazˇde´mu z nich „chvilku“, doka´zˇe svu˚j pracovnı´ cˇas efektivneˇ vyuzˇ´ıt.

Multiprogramova´nı´ klade pomeˇrneˇ velke´ na´roky na operacˇnı´ syste´m. Ma´-li by´t pocˇ´ıtacˇ efektivneˇ vyuzˇit zpracova´va´nı´m vı´ce u´loh soucˇasneˇ, teˇchto u´loh by meˇlo by´t tolik, aby pocˇ´ıtacˇ nikdy nezaha´lel. Pak ale musı´ operacˇnı´ syste´m rozhodovat, kterou z rˇady cˇekajı´cı´ch u´loh prˇeda´ ´ lohy take´ majı´ sve´ na´roky na operacˇnı´ pameˇt’– pokud je jich procesoru k vyrˇesˇenı´ prˇednostneˇ. U mnoho, do pameˇti se vsˇechny nevejdou; i rˇ´ızenı´ vyuzˇitı´ pameˇti ma´ na starost operacˇnı´ syste´m. Tyto u´koly patrˇ´ı k nejdu˚lezˇiteˇjsˇ´ım, ktere´ operacˇnı´ syste´m plnı´, a budeme se jim podrobneˇji veˇnovat v dalsˇ´ıch kapitola´ch. Pru˚vodce studiem Aby pocˇ´ıtacˇ mohl zpracova´vat vı´ce u´loh soucˇasneˇ, musı´ mı´t minima´lneˇ tyto dveˇ hardwarove´ funkce: 1. oddeˇlena´ cˇinnost CPU a periferiı´, 2. prˇerusˇenı´. Oddeˇlenı´ cˇinnosti periferiı´ od CPU dosa´hneme tı´m, zˇe jim da´me vlastnı´ inteligenci. Pocˇ´ıtacˇ tak mı´sto zbytecˇne´ zaha´lky prˇi cˇeka´nı´ na periferie mu˚zˇe vykona´vat ko´d jine´ u´lohy. Periferie se pozdeˇji dı´ky prˇerusˇenı´ mu˚zˇe sama ozvat a vyzˇa´dat si opeˇtovnou pozornost CPU.

Dalsˇ´ım vy´vojovy´m stupneˇm multiprogramova´nı´ jsou syste´my sdı´lejı´cı´ cˇas – time sharing systems. Pu˚vodnı´ princip da´vkove´ho zpracova´nı´ byl nahrazen mozˇnostı´ interaktivnı´ pra´ce cˇloveˇka s pocˇ´ıtacˇem. Sa´love´ pocˇ´ıtacˇe byly pu˚vodneˇ koncipova´ny tak, zˇe s jednı´m pocˇ´ıtacˇem pracovalo vı´c lidı´. Lze dokonce rˇ´ıci, zˇe prˇ´ımo mnoho lidı´ soucˇasneˇ – hardware byl velmi drahy´ a dı´ky sdı´lenı´ cˇasu bylo mozˇno vy´pocˇetnı´ vy´kon pocˇ´ıtacˇe efektivneˇ vyuzˇ´ıt. Syste´my sdı´lejı´cı´ cˇas majı´ rˇadu vy´hod a pouzˇ´ıvajı´ se dnes na velky´ch serverech i na maly´ch osobnı´ch pocˇ´ıtacˇ´ıch. Tyto pocˇ´ıtacˇove´ syste´my samozrˇejmeˇ pro svu˚j chod potrˇebujı´ jesˇteˇ slozˇiteˇjsˇ´ı operacˇnı´ syste´my, nezˇ meˇly da´vkoveˇ pracujı´cı´ stroje. Modernı´m trendem je take´ nasazova´nı´ vı´ce CPU jednotek do jednoho pocˇ´ıtacˇe. Tyto vı´ceprocesorove´ pocˇ´ıtacˇe jsou opeˇt cenoveˇ vy´hodne´, nebot’ umozˇnˇujı´ zvy´sˇit vy´pocˇetnı´ vy´kon prˇi zachova´nı´ slozˇitosti samotny´ch procesoru˚ a ceny periferiı´, ktere´ jsou sdı´lene´ (takzˇe ma´me jen jedno I/O zarˇ´ızenı´, ale vı´ce procesoru˚ jej pouzˇ´ıva´ spolecˇneˇ). 4.2.2

Osobnı´ pocˇ´ıtacˇe

Samotne´ osobnı´ pocˇ´ıtacˇe (PC – personal computer) se objevily jizˇ v 70.letech 20.stoletı´. Jejich tehdejsˇ´ı procesory postra´daly mozˇnost chra´nit operacˇnı´ syste´m prˇed chybami (cˇi u´toky) aplikacı´, cozˇ znacˇneˇ omezovalo jejich vyuzˇitelnost pro vı´ce uzˇivatelu˚ cˇi aplikacı´ soucˇasneˇ (a za´rovenˇ to umozˇnilo zaplavenı´ pocˇ´ıtacˇu˚ viry). Tato situace se zmeˇnila v polovineˇ 80.let (procesor 80386), ale teprve zacˇa´tkem 90.let se zacˇaly masoveˇ rozsˇirˇovat noveˇjsˇ´ı operacˇnı´ syste´my na u´kor drˇ´ıveˇjsˇ´ıho MS–DOSu. V soucˇasnosti pouzˇ´ıvane´ syste´my (Windows NT, Linux, MacOS X) hodneˇ teˇzˇ´ı z principu˚, ktere´ jizˇ prˇed mnoha lety byly pouzˇity u sa´lovy´ch pocˇ´ıtacˇu˚. 4.2.3

Vı´ceprocesorove´ pocˇ´ıtacˇe

Du˚lezˇity´m hlediskem je take´ pocˇet CPU v pocˇ´ıtacˇi. Poskytuje-li operacˇnı´ syste´m sdı´lenı´ cˇasu pro umozˇneˇnı´ beˇhu vı´ce aplikacı´ soucˇasneˇ, tak se sama nabı´zı´ mozˇnost vyuzˇ´ıt vı´ce CPU 37

pro rychlejsˇ´ı beˇh cele´ho syste´mu. Vı´ceprocesorove´ pocˇ´ıtacˇe, ktere´ by´vajı´ take´ oznacˇova´ny jako teˇsneˇ va´zane´ syste´my, obsahujı´cı´ vı´ce CPU jednotek, ktere´ spolu sdı´lejı´ zbytek pocˇ´ıtacˇe (sbeˇrnici, pameˇt’a periferie), jsou samozrˇejmeˇ variantou cenoveˇ velmi vy´hodnou (levneˇjsˇ´ı nezˇ neˇkolik kompletnı´ch pocˇ´ıtacˇu˚). Vyzˇadujı´ vsˇak jesˇteˇ slozˇiteˇjsˇ´ı operacˇnı´ syste´my a take´ slozˇiteˇjsˇ´ı hardwarovou architekturu, ktera´ souzˇitı´ vı´ce CPU v jednom pocˇ´ıtacˇi umozˇnı´. Dnes nejbeˇzˇneˇjsˇ´ı variantou vı´ceprocesorovy´ch syste´mu˚ jsou symetricke´ multiprocesory (SMP), kde jsou si vsˇechny CPU rovny. (Prˇ´ıkladem je syste´m Windows NT.) Programova´nı´ aplikacı´ pro SMP syste´mu je pomeˇrneˇ jednoduche´ a rovnost mezi CPU jednotkami umozˇnˇuje efektivnı´ vyuzˇitı´ vsˇech zdroju˚. Dalsˇ´ı alternativou jsou pak asymetricke´ syste´my, kde kazˇda´ CPU jednotka ma´ specifickou u´lohu. Symetricˇnost syste´mu mu˚zˇe by´t dana´ jak hardwarem, tak stavbou operacˇnı´ho syste´mu. Naprˇ. syste´m Solaris existuje v symetricke´ i (starsˇ´ı) asymetricke´ verzi pro stejny´ hardware. [SGG05] Pru˚vodce studiem Jak vı´me, v modernı´m pocˇ´ıtacˇi je mnoho mikroprocesoru˚. Pokud pouze jeden z nich ma´ u´lohu CPU a ostatnı´ slouzˇ´ı jako pomocne´ obvody inteligentnı´ch periferiı´, nepovazˇujeme takovy´ pocˇ´ıtacˇ za vı´ceprocesorovy´. Toto je sice cˇisteˇ technicky zcela nespra´vne´, ale odra´zˇ´ı to fakt, zˇe pomocne´ procesory jsou jizˇ dnes zcela beˇzˇne´ a jsou pouzˇ´ıva´ny doslova vsˇude. Teprve pocˇ´ıtacˇe obsahujı´cı´ vı´ce procesoru˚ slouzˇ´ıcı´ch jako CPU a umozˇnˇujı´cı´ch zvy´sˇit vy´kon pocˇ´ıtacˇe jejich spolupracı´ na vy´pocˇtech povazˇujeme za vı´ceprocesorove´. Extre´mnı´m prˇ´ıkladem toho, co se za vı´ceprocesorovy´ syste´m nepovazˇuje, jsou modernı´ graficke´ karty. Jejich procesory jsou velmi vy´konne´ vy´pocˇetnı´ jednotky, zcela beˇzˇneˇ v matematicky´ch operacı´ch i vy´konneˇjsˇ´ı nezˇ samotne´ CPU. Prˇesto prˇ´ıtomnost takove´ho cˇipu v pocˇ´ıtacˇi nenı´ du˚vodem k oznacˇenı´ „vı´ceprocesorovy´“.

4.2.4

Distribuovane´ syste´my a klastry

Dalsˇ´ım typem pocˇ´ıtacˇovy´ch syste´mu˚ jsou distribuovane´ syste´my. Jde de facto o vı´ce samostatneˇ fungujı´cı´ch pocˇ´ıtacˇu˚ propojeny´ch do sı´teˇ. Toto propojenı´ mu˚zˇe mı´t samozrˇejmeˇ mnoho podob a s pomocı´ specia´lnı´ho distribuovane´ho operacˇnı´ho syste´mu mohou vsˇechny takto propojene´ pocˇ´ıtacˇe fungovat jako jeden celek. Teˇmto syste´mu˚m take´ rˇ´ıka´me volneˇ va´zane´ syste´my. Na rozdı´l od vı´ceprocesorovy´ch syste´mu˚, kde neˇkolik CPU obvykle sdı´lı´ stejnou operacˇnı´ pameˇt’, distribuovane´ syste´my obecneˇ nemajı´ tuto vlastnost a jednotlive´ cˇa´sti syste´mu – vy´pocˇetnı´ uzly – spolu pouze komunikujı´ pomocı´ zası´la´nı´ zpra´v. Distribuovany´ operacˇnı´ syste´m zajisˇt’uje tuto komunikaci a mu˚zˇe do urcˇite´ mı´ry i simulovat sdı´lenou pameˇt’a zakry´t tak fyzicke´ rozdı´ly mezi volneˇ a teˇsneˇ va´zany´m syste´mem. Distribuovane´ syste´my take´ cˇasto rozdeˇlujeme dle vnitrˇnı´ organizace uzlu˚ na syste´my typu klient–server, kde jeden uzel ma´ vy´sadnı´ postavenı´ a rˇ´ıdı´ cely´ vy´pocˇet, a syste´my typu peer– to–peer, kde jsou si vsˇechny uzly rovny. Mo´dnı´m pojmem je take´ klastr (anglicky cluster), oznacˇujı´cı´ distribuovany´ syste´m, ktery´ vznikl pouhy´m propojenı´m klasicky´ch pocˇ´ıtacˇu˚ v pocˇ´ıtacˇove´ sı´ti (a doda´nı´m specificke´ho softwaru). Vsˇechny tyto typy distribuovany´ch syste´mu˚ jsou v poslednı´ch letech velmi aktua´lnı´, cozˇ souvisı´ zejme´na s nı´zky´mi na´klady na jejich provoz (ve srovna´nı´ s velky´mi superpocˇ´ıtacˇi) a rozvojem internetu. Jelikozˇ se vsˇak jedna´ o te´ma doty´kajı´cı´ se spı´sˇe pocˇ´ıtacˇovy´ch sı´tı´, nebudeme se mu da´le nijak podrobneˇji veˇnovat. 4.2.5

Dalsˇ´ı typy pocˇ´ıtacˇovy´ch syste´mu˚

Existuje samozrˇejmeˇ jesˇteˇ cela´ rˇada dalsˇ´ıch pocˇ´ıtacˇovy´ch syste´mu˚. Naprˇ. [SGG05] uva´dı´ v prˇehledu jesˇteˇ syste´my pracujı´cı´ v rea´lne´m cˇase (nebo strucˇneˇ „syste´my rea´lne´ho cˇasu“, anglicky 38

real–time systems) a kapesnı´ pocˇ´ıtacˇe (PDA). V prvnı´m prˇ´ıpadeˇ jde o pocˇ´ıtacˇe a operacˇnı´ syste´my zarucˇujı´cı´ vyrˇ´ızenı´ urcˇity´ch pozˇadavku˚ v pevneˇ dane´m maxima´lnı´m cˇase, prˇ´ıkladem mu˚zˇe by´t naprˇ. syste´m elektronicke´ho vstrˇikova´nı´ paliva v automobilech. Tyto syste´my mohou by´t implementova´ny hardwaroveˇ i softwaroveˇ a jsou samozrˇejmeˇ zameˇrˇeny vzˇdy na u´zkou aplikacˇnı´ oblast. Naprˇ. Windows NT syste´mem rea´lne´ho cˇasu nenı´ (i kdyzˇ pocˇ´ıtacˇove´ hry cˇi prˇehra´va´nı´ videoza´znamu˚ jiste´ pozˇadavky na vyrˇizova´nı´ uda´lostı´ v pevne´m cˇase majı´). Ve druhe´m prˇ´ıpadeˇ (PDA) jde o male´ prˇenosne´ pocˇ´ıtacˇe, ktere´ de facto kopı´rujı´ beˇzˇne´ osobnı´ pocˇ´ıtacˇe, ovsˇem jsou velmi limitova´ny energeticky, pameˇt’oveˇ, prostoroveˇ atp. Samozrˇejmeˇ lze ocˇeka´vat, zˇe beˇhem na´sledujı´cı´ch let se soucˇasne´ technicke´ limity podarˇ´ı prˇekonat a programova´nı´ PDA bude vı´ce a vı´ce podobne´ (dnesˇnı´mu) programova´nı´ osobnı´ch pocˇ´ıtacˇu˚. Podobneˇ je tomu i se syste´my pracujı´cı´mi v rea´lne´m cˇase. V poslednı´ch letech je trendem pouzˇ´ıva´nı´ beˇzˇny´ch univerza´lnı´ch operacˇnı´ch syste´mu˚ (naprˇ. Linux cˇi Windows) ve spotrˇebnı´ elektronice (naprˇ. satelitnı´ prˇijı´macˇe, DVD prˇehra´vacˇe cˇi rekorde´ry apod.). Tyto aplikace obvykle pouzˇ´ıvajı´ neˇjaky´ specializovany´ hardwarovy´ obvod (naprˇ. dekode´r MPEG videa) doplneˇny´ o pocˇ´ıtacˇ s upravenou verzı´ neˇktere´ho beˇzˇne´ho operacˇnı´ho syste´mu. Tento celek pak sice nemusı´ by´t nutneˇ syste´mem rea´lne´ho cˇasu, ale svy´m chova´nı´m se mu prˇinejmensˇ´ım velmi blı´zˇ´ı. Dalsˇ´ı specializovane´ syste´my spadajı´cı´ do disciplı´ny operacˇnı´ch syste´mu˚ jsou syste´my multimedia´lnı´, ktere´ se ty´kajı´ studia multime´diı´ (zalozˇeno na zvuku a obrazu). Multime´dia pak u´zce souvisejı´ se syste´my rea´lne´ho cˇasu a distribuovany´mi syste´my. Multimedia´lnı´ operacˇnı´ syste´my jsou tedy jaky´msi mezioborovy´m pru˚secˇ´ıkem neˇkolika disciplı´n a majı´ u´zke´ napojenı´ na prakticke´ aplikace v oblasti pocˇ´ıtacˇu˚, doma´cı´ elektroniky apod. Shrnutı´ V te´to kapitole jsme se sezna´mili s pojmem operacˇnı´ syste´m. Pokusili jsme se jej definovat jak prˇ´ımo, tak neprˇ´ımo skrz jeho cı´le. Dozveˇdeˇli jsme se, zˇe hlavnı´m posla´nı´m operacˇnı´ho syste´mu je abstrahovat hardwarove´ zdroje a zjednodusˇit pra´ci s nimi a umozˇnit soucˇasne´ zpracova´nı´ vı´ce u´loh. Da´le jsme se v te´to kapitole sezna´mili s neˇkolika za´kladnı´mi typy syste´mu˚ a uka´zali jsme si, jak se pocˇ´ıtacˇe a jejich operacˇnı´ syste´my beˇhem let vyvı´jely. Z tohoto prˇehledu bylo take´ patrne´, zˇe i nejslozˇiteˇjsˇ´ı funkce operacˇnı´ch syste´mu˚ se postupneˇ dosta´vajı´ z velky´ch (sa´lovy´ch) superpocˇ´ıtacˇu˚ do mensˇ´ıch a mensˇ´ıch pocˇ´ıtacˇu˚ a rozdı´ly mezi nimi se tak postupneˇ zmensˇujı´. Vy´jimkou jsou samozrˇejmeˇ pocˇ´ıtacˇove´ syste´my zameˇrˇene´ na neˇjakou specia´lnı´ aplikacˇnı´ oblast; ty mohou mı´t specificke´ vlastnosti bez ohledu na jejich velikost cˇi slozˇitost. Pojmy k zapamatova´nı´ • • • • • • •

cı´le operacˇnı´ho syste´mu sa´lovy´ pocˇ´ıtacˇ osobnı´ pocˇ´ıtacˇ vı´ceprocesorovy´ pocˇ´ıtacˇ distribuovany´ syste´m teˇsneˇ/volneˇ va´zany´ syste´m pocˇ´ıtacˇovy´ klastr

Kontrolnı´ ota´zky 1. 2. 3. 4. 5.

Jmenujte za´kladnı´ u´cˇel(y) operacˇnı´ho syste´mu. Jaky´ prˇ´ınos ma´ to, zˇe operacˇnı´ syste´my majı´ (minima´lneˇ) dveˇ ru˚zna´ rozhranı´? Popisˇte hlavnı´ rysy pocˇ´ıtacˇu˚, ktery´m rˇ´ıka´me „sa´love´“. Co je hlavnı´ vy´hodou multiprogramova´nı´? Jaky´ je rozdı´l mezi teˇsneˇ a volneˇ va´zany´mi syste´my? Jmenujte vy´hody a nevy´hody obou rˇesˇenı´. 39

6. Lze zajistit bezpecˇnost syste´mu bez podpory hardwaru (tj. jen napsa´nı´m kvalitnı´ho operacˇnı´ho syste´mu)? Zdu˚vodneˇte. 7. Popisˇte rozdı´l mezi symetricky´m a asymetricky´m multiprocesorem. 8. Jake´ jsou hlavnı´ rozdı´ly mezi operacˇnı´m syste´mem pro sa´love´ a osobnı´ pocˇ´ıtacˇe?

40

5

Spra´va procesoru

Studijnı´ cı´le: Centrem vsˇeho deˇnı´ v pocˇ´ıtacˇi, nebo alesponˇ dle von Neumannova sche´matu, je procesor (CPU). Tato kapitola se veˇnuje jeho spra´veˇ. Studenti budou sezna´meni s pojmy proces a vla´kno, ktere´ zde budou vysveˇtleny prˇedevsˇ´ım teoreticky a v kapitole na´sledujı´cı´ pak i na prˇ´ıkladu dvou operacˇnı´ch syste´mu˚: Unix a Windows NT. Klı´cˇova´ slova: proces, vla´kno, pla´novacˇ u´loh, PCB Potrˇebny´ cˇas: 100 minut.

5.1

Procesy

Cˇinnosti, ktere´ prova´dı´ procesor, mu˚zˇeme nazy´vat ru˚zny´mi zpu˚soby. V syste´mech, ktere´ jsme si prˇedstavili v prˇedchozı´ kapitole, by´vajı´ nazy´va´ny naprˇ. job cˇi task. Obecny´ termı´n pro oznacˇenı´ cˇinnosti procesoru, bez ohledu na konkre´tnı´ situaci, je pak proces. Neforma´lnı´ definice procesu je velmi jednoducha´: Je to beˇzˇ´ıcı´ program. Ma´me-li pocˇ´ıtacˇ vypnuty´, zˇa´dny´ proces tam nenı´. Programy jsou obvykle ulozˇeny naprˇ. na disku, ale nejsou vykona´va´ny. Po zapnutı´ pocˇ´ıtacˇe se spustı´ nejprve operacˇnı´ syste´m, pak mu˚zˇeme spousˇteˇt aplikacˇnı´ programy. Spusˇteˇnı´m neˇjake´ho programu je vytvorˇen novy´ proces. Pro jednoduchost lze tento princip bra´t i doslova: Proces vznikne spusˇteˇnı´m programu. Spusˇteˇnı´m vı´ce programu˚ vznikne vı´ce procesu˚. Opakovany´m spusˇteˇnı´m stejne´ho programu take´ vznikne vı´ce procesu˚. Pru˚vodce studiem Pojem proces je obvykle dobrˇe cha´pa´n i proto, zˇe kazˇdy´ dnes zna´ aplikaci „Spra´vce u´loh“ syste´mu Windows (viz obra´zek 6). Tam je seznam pra´veˇ beˇzˇ´ıcı´ch procesu˚ zobrazen.

Obra´zek 6: Aplikace Spra´vce u´loh (Task Manager) syste´mu Windows XP. Proces je vı´c nezˇ jen program v operacˇnı´ pameˇti. Kromeˇ ko´du programu obsahuje take´ aktua´lnı´ cˇinnost, kterou reprezentujı´ hodnoty vsˇech registru˚ procesoru, programovy´ za´sobnı´k (pouzˇ´ıvany´ prˇi rekurzi a pro ukla´da´nı´ loka´lnı´ch promeˇnny´ch) a samozrˇejmeˇ take´ data. Proces obvykle ma´ kromeˇ tzv. globa´lnı´ch cˇi staticky´ch dat take´ dalsˇ´ı data na haldeˇ (anglicky heap). 41

Proces je beˇzˇ´ıcı´ program.

Pru˚vodce studiem Data na haldeˇ jsou vytva´rˇena dynamicky, v rˇadeˇ vysˇsˇ´ıch programovacı´ch jazyku˚ pomocı´ opera´toru new. Oproti tomu staticka´ globa´lnı´ data majı´ pevnou velikost i pozici v pameˇti, cˇasto jsou dokonce prˇ´ımo ulozˇena v souboru spolu s programem. V neˇktery´ch programovacı´ch jazycı´ch takova´ data definovat cˇi pouzˇ´ıvat nelze, nebo se jim rˇ´ıka´ jinak.

5.1.1

ˇ ivotnı´ cyklus procesu Z

Proces jakozˇto dynamicky´ deˇj v prˇesne´m okamzˇiku vznika´, pak probı´ha´ a v jine´m prˇesne´m okamzˇiku koncˇ´ı. Beˇhem sve´ho zˇivota proces procha´zı´ ru˚zny´mi stavy; zde je du˚lezˇita´ role operacˇnı´ho syste´mu jakozˇto spra´vce procesu˚. Jelikozˇ procesor fyzicky doka´zˇe zpracova´vat jen jednu u´lohu, cˇili jeden proces, operacˇnı´ syste´m „da´vkuje“ procesor a po kra´tky´ch cˇasovy´ch u´secı´ch jej strˇ´ıdaveˇ prˇideˇluje jednotlivy´m procesu˚m. Tyto cˇasove´ u´seky jsou opravdu velmi male´, aby jej uzˇivatele´ pracujı´cı´ s pocˇ´ıtacˇem nijak nepocit’ovali – u jednotlive´ho procesu mohou by´t rˇa´doveˇ stovky prˇepnutı´ za sekundu a v cele´m pocˇ´ıtacˇi rˇa´doveˇ tisı´ce (technicky vzato hornı´ mez je da´na rychlostı´ procesoru). Zˇivotnı´ cyklus procesu je obecneˇ zna´zorneˇn na obra´zku 7. Po vzniku procesu tento vzˇdy prˇejde do stavu ready. V tomto stavu cˇeka´, azˇ operacˇnı´ syste´m rozhodne, zˇe ma´ proces beˇzˇet. V tom okamzˇiku prˇejde do stavu running. Proces pak beˇzˇ´ı, nezˇ nastane neˇktera´ ze trˇ´ı situacı´: 1. Ukoncˇenı´ procesu – Proces prˇestane beˇzˇet, kdyzˇ skoncˇ´ı. (Skoncˇit prˇitom mu˚zˇe pra´veˇ jen ze stavu running.) 2. Cˇeka´nı´ na I/O zarˇ´ızenı´ – Pracuje-li proces prostrˇednictvı´m operacˇnı´ho syste´mu s neˇjaky´m externı´m zarˇ´ızenı´m, pak na neˇj velmi cˇasto musı´ cˇekat. V tom okamzˇiku proces prˇecha´zı´ do stavu waiting. V tomto stavu je tak dlouho, nezˇ zarˇ´ızenı´ odpovı´/dokoncˇ´ı operaci. Pak proces prˇecha´zı´ do stavu ready. 3. Nenastane-li zˇa´dny´ ze dvou prˇedchozı´ch prˇ´ıpadu˚, pak po urcˇite´m cˇase operacˇnı´ syste´m sa´m procesu procesor odebere. new

exit

přidělení CPU

ready připraven

running aktivní

odebrání CPU

událost I/O

waiting

čekání na I/O

Obra´zek 7: Stavy procesu. Ukoncˇeny´ proces lze cha´pat jako proces v dalsˇ´ım (cˇtvrte´m) stavu. To proto, zˇe obvykle jesˇteˇ neˇjakou dobu po skoncˇenı´ procesu o neˇm operacˇnı´ syste´m uchova´va´ informace a je trˇeba neˇjak identifikovat, zˇe proces jizˇ skoncˇil. Podobneˇ prˇi vzniku procesu je tento vytva´rˇen jakoby v dalsˇ´ım (pa´te´m) stavu, ktery´ identifikuje, zˇe proces je vytva´rˇen a jesˇteˇ nikdy neprˇesˇel do stavu ready. ´ daje o procesu si operacˇnı´ syste´m uchova´va´ ve strukturˇe PCB (Process Control Block). Jejı´ U prˇesna´ podoba samozrˇejmeˇ za´visı´ na konkre´tnı´m operacˇnı´m syste´mu, ale obsahuje obvykle minima´lneˇ informaci o aktua´lnı´m stavu procesu, hodnoty registru˚ procesoru, data pouzˇ´ıvana´ pro pla´nova´nı´ beˇhu procesu˚, informace o pouzˇ´ıvane´ pameˇti, statisticke´ u´daje o beˇhu procesu cˇi informaci o pra´veˇ pouzˇ´ıvany´ch zdrojı´ch.

42

PCB nese informace o procesu.

5.1.2

Prˇepı´na´nı´ procesu˚

Prˇepı´na´nı´ procesu˚, cˇili strˇ´ıdave´ prˇeda´va´nı´ procesoru mezi jednotlivy´mi procesy, zajisˇt’uje operacˇnı´ syste´m. Samotne´ aplikacˇnı´ procesy se v idea´lnı´m prˇ´ıpadeˇ nemusejı´ na te´to cˇinnosti podı´let a ani ji nemusı´ nijak pocı´tit – rˇ´ıka´me, zˇe prˇepı´na´nı´ je „transparentnı´ “. (Kazˇdy´ proces ma´ tedy dojem, zˇe v pocˇ´ıtacˇi beˇzˇ´ı jen on sa´m.) Samotne´ prˇepnutı´ pak probı´ha´ vzˇdy pomocı´ prˇerusˇenı´ a prˇes operacˇnı´ syste´m, tj. beˇzˇ´ıcı´ proces je prˇerusˇen, beˇzˇ´ı OS a ten ulozˇ´ı aktua´lnı´ stav procesoru do PCB za´znamu prˇerusˇene´ho procesu. OS potom vybere, ktery´ proces bude da´le beˇzˇet, obnovı´ stav procesoru dle jeho PCB za´znamu procesu a ukoncˇ´ı prˇerusˇenı´. Mı´sto do pu˚vodnı´ho procesu se z prˇerusˇenı´ vracı´ do nove´ho procesu, ktery´ nynı´ beˇzˇ´ı. Vy´beˇr, ktery´ na´sledujı´cı´ proces bude beˇzˇet, musı´ by´t co nejrychlejsˇ´ı a take´ dostatecˇneˇ spravedlivy´. Algoritmus / cˇa´st operacˇnı´ho syste´mu toto zajisˇt’ujı´cı´ se nazy´va´ pla´novacˇ (scheduler). Scheduler pouzˇ´ıva´ obvykle neˇjakou formu fronty cˇekajı´cı´ch procesu˚ v kombinaci se syste´mem priorit. Podrobneˇji se u te´to problematiky zastavı´me pozdeˇji v sekci vla´ken (kapitola 5.3). Prˇepı´na´nı´ procesu˚ je cˇasto podporova´no prˇ´ımo hardwaroveˇ a ma´ to dva du˚vody: 1. Kazˇdy´ procesor mu˚zˇe mı´t jine´ registry a operacˇnı´ syste´m nemusı´ vsˇechny zna´t. Prˇepı´na´nı´ procesu˚ bez ulozˇenı´ a obnovenı´ vsˇech registru˚ by meˇlo fata´lnı´ na´sledky. 2. Prˇepnutı´ musı´ by´t co nejrychlejsˇ´ı. Ukla´da´nı´ jednotlivy´ch registru˚ pomocı´ rˇady instrukcı´ by vsˇak prˇ´ılisˇ rychle´ nebylo. Prˇi hardwarove´ podporˇe mu˚zˇe cela´ akce probeˇhnout rychleji. Procesory x86 jsou rˇesˇeny takto: Kazˇdy´ proces ma´ svu˚j blok pameˇti TSS (Task State Segment), kam se prˇi pozastavenı´ jeho beˇhu stav procesoru automaticky ukla´da´ (a prˇi obnovenı´ beˇhu procesu se odtud znovu obnovı´). Registr TR (Task Register) je selektorem TSS beˇzˇ´ıcı´ho procesu, odkazuje samozrˇejmeˇ prˇ´ımo do GDT. Pro evidenci procesu pak stacˇ´ı v PCB ne´st hodnotu TR. 5.1.3

Kooperativnı´ a preemptivnı´ syste´my

Z hlediska podporovane´ho cˇi preferovane´ho zpu˚sobu prˇepı´na´nı´ procesu deˇlı´me operacˇnı´ syste´my na kooperativnı´ a preemptivnı´. Kooperativnı´ – toto je jednodusˇsˇ´ı model prˇepı´na´nı´, kdy aplikacˇnı´ procesy samy musı´ spolupracovat na prˇepnutı´. Kazˇdy´ proces musı´ co nejcˇasteˇji prˇeda´vat rˇ´ızenı´ zpeˇt do operacˇnı´ho syste´mu. Proces tedy musı´ volat neˇjakou funkci operacˇnı´ho syste´mu, z tohoto vola´nı´ se pak procesor vra´tı´ azˇ po dalsˇ´ım prˇepnutı´. Nevy´hodou tohoto prˇ´ıstupu je, zˇe klade velke´ na´roky na „slusˇnost“ aplikacı´ – bude-li neˇjaky´ program me´neˇ slusˇny´, mu˚zˇe va´zˇneˇ narusˇit plynuly´ beˇh cele´ho syste´mu. Preemptivnı´ – toto je dokonalejsˇ´ı model prˇepı´na´nı´, kde operacˇnı´ syste´m v prˇ´ıpadeˇ dlouhe´ho beˇhu neˇjake´ho procesu sa´m (preemptivneˇ – preventivneˇ) odebere procesor a da´ jej jine´mu procesu. Preemptivnı´ syste´my jsou spolehliveˇjsˇ´ı, tvorba aplikacı´ pro neˇ je prˇitom i jednodusˇsˇ´ı. Slozˇiteˇjsˇ´ı je ale samozrˇejmeˇ stavba preemptivnı´ho operacˇnı´ho syste´mu. Prˇ´ıkladem kooperativnı´ho syste´mu je Windows 3.1 cˇi starsˇ´ı verze MacOS. Prˇ´ıkladem preemptivnı´ho syste´mu je Windows NT cˇi Linux. Pru˚vodce studiem U preemptivnı´ch syste´mu˚ lze take´ diskutovat o tom, „jak moc“ je dany´ syste´m preemptivnı´. Naprˇ. Windows 95 byl preemptivnı´ syste´m a v prˇ´ıpadeˇ poruchy neˇjake´ aplikace, kdy tato odmı´tla sama slusˇneˇ vra´tit procesor, operacˇnı´ syste´m procesor preemptivneˇ odebral. Jenzˇe

43

V kooperativnı´m syste´mu aplikace spolupracujı´ na prˇeda´va´nı´ procesoru.

Preemptivnı´ syste´m sa´m rˇ´ıdı´ prˇepı´na´nı´ procesoru.

beˇh pocˇ´ıtacˇe byl v te´ chvı´li neplynuly´, viditelneˇ zpomaleny´ a bylo znacˇneˇ poznat, zˇe „neˇco nenı´ v porˇa´dku“. Soucˇasne´ verze Windows s ja´drem NT tento neduh nemajı´.

5.2

Strategie prˇideˇlova´nı´ procesoru

Jak jizˇ bylo rˇecˇeno, rˇ´ıdit prˇideˇlova´nı´ procesoru je nutne´ k tomu, aby kazˇdy´ pocˇ´ıtacˇ i s pouze jednı´m procesorem mohl vykona´vat vı´ce procesu˚ soucˇasneˇ. Tuto cˇinnost ma´ na starosti pla´novacˇ u´loh (scheduler). Scheduler se prˇi pla´nova´nı´ snazˇ´ı dosa´hnout na´sledujı´cı´ch cı´lu˚: 1. Fe´rovost ke vsˇem procesu˚m – Scheduler nesmı´ nikoho bezdu˚vodneˇ zvy´hodnˇovat. (Bezdu˚vodne´ by bylo naprˇ´ıklad zvy´hodneˇnı´ vznikle´ jako du˚sledek nekvalitnı´ho pla´novacı´ho algoritmu.) 2. Efektivita vyuzˇitı´ CPU – Procesor nesmı´ zaha´let, pokud je pro neˇj pra´ce. Proto scheduler nesmı´ prˇideˇlovat procesor teˇm procesu˚m, ktere´ jej zrovna nepotrˇebujı´, ani na maly´ okamzˇik. 3. Minimalizace doby odezvy – Uzˇivatel pocˇ´ıtacˇe by meˇl mı´t prˇednost prˇed u´lohami na pozadı´, takzˇe platı´ pravidlo: „Co je nejvı´c videˇt, to deˇlat naprˇed.“ 4. Minimalizace doby pru˚chodu syste´mem (turnaround) – U kazˇde´ho kra´tce existujı´cı´ho procesu je zˇa´doucı´ minimalizovat cˇas od spusˇteˇnı´ po jeho ukoncˇenı´. 5. Maximalizace odvedene´ pra´ce (throughput) – Sledujeme-li dlouhodobeˇ mnozˇstvı´ pra´ce odvedene´ pocˇ´ıtacˇem (naprˇ. za hodinu apod.), meˇlo by by´t maxima´lnı´ mozˇne´. V konkre´tnı´ch situacı´ch se samozrˇejmeˇ mohou priority teˇchto cı´lu˚ lisˇit. Naprˇ´ıklad u osobnı´ch pocˇ´ıtacˇu˚ je velmi du˚lezˇita´ doba odezvy, zatı´mco na serverech mu˚zˇe by´t nejdu˚lezˇiteˇjsˇ´ı naprˇ. throughput. Schedulery obvykle pouzˇ´ıvajı´ na´sledujı´cı´ dveˇ strategie cˇi jejich kombinaci – syste´m cyklicke´ obsluhy a prioritnı´ syste´m. 5.2.1

Cyklicka´ obsluha (round robin)

Princip cyklicke´ obsluhy dodrzˇuje prˇedevsˇ´ım spravedlivost. Procesy jsou zarˇazeny do cyklicke´ fronty a procesor je jim fe´roveˇ prˇideˇlova´n ve stylu „kazˇdy´ chvilku taha´ pilku“. Kazˇdy´ proces dostane procesor na urcˇite´ pevneˇ stanovene´ kvantum cˇasu. Proble´mem mu˚zˇe by´t stanovenı´ optima´lnı´ velikosti kvanta, protozˇe je-li kvantum prˇ´ılisˇ male´, roste rezˇie syste´mu (spojena´ s prˇepı´na´nı´m procesu˚); je-li naopak kvantum prˇ´ılisˇ velke´, prodluzˇuje se doba odezvy jednotlivy´ch procesu˚ (kazˇdy´ fe´roveˇ cˇeka´ ve fronteˇ, azˇ na neˇj prˇijde rˇada). Dalsˇ´ı nedostatky tohoto syste´mu, je-li pouzˇit v cˇiste´ podobeˇ, jsou u du˚lezˇity´ch syste´movy´ch procesu˚ – i ty musejı´ cˇekat ve fronteˇ, azˇ na neˇ prˇijde rˇada. Podobneˇ pro syste´my rea´lne´ho cˇasu se tento princip nehodı´ vu˚bec. Obecneˇ lze rˇ´ıci, zˇe syste´m cyklicke´ obsluhy je 100% spravedlivy´, ale neumozˇnˇuje efektivnı´ vyuzˇitı´ zdroju˚. 5.2.2

Syste´m priorit

V prioritnı´m syste´mu je kazˇde´mu procesu prˇideˇleno cˇ´ıslo oznacˇujı´cı´ jeho du˚lezˇitost (cˇili prioritu). Procesor je pak prˇideˇlen vzˇdy procesu s nejvysˇsˇ´ı prioritou. Mapova´nı´ priorit na cˇ´ısla je obvykle linea´rnı´ a mu˚zˇe mı´t bud’ souhlasny´, nebo opacˇny´ trend, tj. velka´ priorita mu˚zˇe by´t 44

reprezentova´na maly´mi, nebo naopak velky´mi cˇ´ısly. V soucˇasnosti prˇevla´da´ druhy´ zpu˚sob: nejmensˇ´ı priorita je reprezentova´na nulou a s rostoucı´mi cˇ´ısly priorita roste. Vy´hodou prioritnı´ho syste´mu je okamzˇita´ odezva – at’ uzˇ je v dany´ okamzˇik nejdu˚lezˇiteˇjsˇ´ı cokoliv, dany´ proces ma´ nejvysˇsˇ´ı prioritu a zarucˇeny´ prˇ´ıstup k procesoru. Nevy´hodou je naopak nizˇsˇ´ı spravedlnost, kdy v extre´mnı´m prˇ´ıpadeˇ se mu˚zˇe i sta´t, zˇe neˇktery´ proces se k procesoru nedostane nikdy. 5.2.3

Prakticke´ strategie

V praxi se uzˇ´ıva´ vy´hradneˇ kombinacı´ vy´sˇe uvedeny´ch strategiı´ (tj. ne neˇktera´ z variant, ale vzˇdy obeˇ dohromady), cˇ´ımzˇ je dosazˇeno vyva´zˇenı´ jejich kladu˚ a za´poru˚. Za´kladem takove´ kombinovane´ strategie je prioritnı´ syste´m, tj. prˇednost ma´ proces s nejvysˇsˇ´ı prioritou. Procesy se stejnou prioritou jsou obsluhova´ny cyklicky, cˇili na stejne´ u´rovni priority vzˇdy spravedliveˇ. Priorita se navı´c mu˚zˇe dynamicky meˇnit, tj. dlouho cˇekajı´cı´m procesu˚m se zvysˇuje, hodneˇ pracujı´cı´m procesu˚m se naopak snizˇuje, take´ procesu˚m komunikujı´cı´m s uzˇivatelem cˇi periferiemi obecneˇ se zvysˇuje atp. Strategie prˇideˇlova´nı´ procesoru si jesˇteˇ podrobneˇji probereme na prˇ´ıkladech konkre´tnı´ch operacˇnı´ch syste´mu˚, nejdrˇ´ıve si vsˇak musı´me prˇedstavit pojem vla´kna, se ktery´m pla´nova´nı´ u´zce souvisı´.

5.3

Vla´kna

5.3.1

Zavedenı´ pojmu vla´kno

Azˇ dosud bylo povı´da´nı´ te´to kapitoly dosti intuitivnı´, pojem vla´kna jej vsˇak poneˇkud zkomplikuje. V soucˇasny´ch operacˇnı´ch syste´mech se totizˇ procesor neprˇideˇluje prˇ´ımo procesu˚m, ale vla´knu˚m. Samotna´ reprezentace vla´ken mu˚zˇe by´t v jednotlivy´ch operacˇnı´ch syste´mech ru˚zna´, za´visı´ to zejme´na na jejich sta´rˇ´ı (jedna´ se totizˇ o poneˇkud pozdeˇji adoptovany´ prvek), proto se kromeˇ obecne´ho povı´da´nı´ zastavı´me take´ u prˇ´ıkladu˚ konkre´tnı´ch syste´mu˚. Vla´kno (anglicky thread, nebo delsˇ´ım thread of execution) je prvek reprezentujı´cı´ vykona´va´nı´ ko´du procesu. Podporu vla´ken do operacˇnı´ho syste´mu dostaneme tak, zˇe vyjmeme cˇa´st odpoveˇdnostı´ z procesu a osamostatnı´me je. Jak jsme si uvedli na zacˇa´tku te´to kapitoly, informace o procesu jsou uchova´ny v PCB. Do vla´kna z nich oddeˇlı´me prˇedevsˇ´ım hodnoty vsˇech registru˚ procesoru a u´daje potrˇebne´ k pla´nova´nı´. Neˇktere´ u´daje budeme muset zdvojit – naprˇ. statisticke´ u´daje cˇi informace o stavu bude nynı´ mı´t proces i vla´kno (nebot’ kazˇda´ entita ma´ svu˚j stav). V procesu zu˚stanou informace o pouzˇ´ıvane´ pameˇti a dalsˇ´ıch zdrojı´ch. Vztah proces–vla´kno vsˇak nemusı´ mı´t jen povahu 1:1 a v tom je hlavnı´ vy´znam vla´ken. Bude-li mı´t jeden proces vla´ken vı´c, kazˇde´ z nich vykona´va´ svu˚j ko´d, ma´ sve´ hodnoty registru˚ a svu˚j vlastnı´ programovy´ za´sobnı´k. S ostatnı´mi vla´kny vsˇak sdı´lı´ operacˇnı´ pameˇt’a vsˇechny ostatnı´ zdroje.

Jeden proces mu˚zˇe mı´t neˇkolik vla´ken.

Zavedenı´ vla´ken ma´ zejme´na tyto vy´hody: • Prˇepnutı´ mezi vla´kny je rychlejsˇ´ı nezˇ prˇepnutı´ mezi procesy. Prˇepne se totizˇ jen to, co souvisı´ s vla´knem – tj. stacˇ´ı vymeˇnit obsahy pracovnı´ch registru˚. Prˇi prˇepnutı´ procesu˚ naopak musı´ dojı´t k prˇepnutı´ cele´ho kontextu, vcˇetneˇ mapova´nı´ pameˇti atp. (Modernı´ procesory podporujı´ prˇepı´na´nı´ hardwaroveˇ, proto nemusejı´ by´t rozdı´ly nijak dramaticke´.) • Vla´kna spolu sdı´lejı´ prostrˇedky, cˇ´ımzˇ je mohou sˇetrˇit. Naprˇ. potrˇebujı´-li dveˇ vla´kna pracovat se stejny´m datovy´m souborem, stacˇ´ı jej nacˇ´ıst do pameˇti jen jednou. • Zavedenı´ vla´ken umozˇnˇuje znacˇneˇ zjednodusˇit neˇktere´ typy programu˚. Potrˇebuje-li program ze sve´ povahy vykona´vat vı´c ru˚zny´ch cˇinnostı´ soucˇasneˇ, je jednodusˇsˇ´ı rˇesˇit to 45

Vla´kna sdı´lejı´ prostrˇedky.

pomocı´ vla´ken nezˇ velmi slozˇity´mi u´pravami ko´du jednoho vla´kna. (Naprˇ. textovy´ editor Word pouzˇ´ıva´ druhe´ vla´kno pro kontrolu pravopisu na pozadı´. Bez mozˇnosti pouzˇitı´ vla´kna by tato u´loha byla velmi slozˇita´.) 5.3.2

Vla´kna v kontextu drˇ´ıveˇjsˇ´ıch znalostı´

V kontextu nasˇich dosavadnı´ch znalostı´ prˇina´sˇ´ı pojem vla´kna rˇadu novy´ch skutecˇnostı´. Neforma´lneˇ rˇecˇeno, vla´kno je „vykona´va´nı´ ko´du“, zatı´mco proces je „pameˇt’a dalsˇ´ı prostrˇedky“. Cˇili proces ma´ pameˇt’, vcˇetneˇ pameˇti s ko´dem programu. Vla´kno tento ko´d vykona´va´, ale samo svu˚j vlastnı´ ko´d nema´. Dokonce i programovy´ za´sobnı´k, ktery´ ma´ vla´kno samo pro sebe, je v pameˇti procesu. Vla´kna tedy mohou pouzˇ´ıvat i za´sobnı´ky jiny´ch vla´ken te´hozˇ procesu – nepouzˇ´ıvajı´ je pomocı´ push/pop, ale mohou zı´skat adresu na promeˇnne´ tam ulozˇene´ a pracovat s nı´.

Vla´kno nema´ svu˚j vlastnı´ ko´d.

Pru˚vodce studiem Vla´kna se masoveˇ rozsˇ´ırˇila prˇedevsˇ´ım dı´ky operacˇnı´mu syste´mu Windows NT (a pozdeˇji Windows 95). Syste´my MS-DOS a Windows 3.1 naopak vla´kna neznaly. Syste´my Windows NT 3.51 SP3 a noveˇjsˇ´ı znajı´ i fibers, dalsˇ´ı variantu vla´ken.)

Zavedenı´m vla´ken se meˇnı´ zˇivotnı´ cyklus procesu. Proces startuje spolu s jednı´m vla´knem, koncˇ´ı v okamzˇiku ukoncˇenı´ poslednı´ho vla´kna. Trˇi stavy uvedene´ na obra´zku 7 se vztahujı´ ke kazˇde´mu vla´knu samostatneˇ. Procesor je totizˇ prˇideˇlova´n jednotlivy´m vla´knu˚m, nikoliv procesu˚m. Proces nevykona´va´ ko´d, tudı´zˇ procesor dostat nemu˚zˇe. Prvnı´ vla´kno tedy vznika´ spolu s procesem a zacˇne vykona´vat jeho ko´d „od zacˇa´tku“ (kde je onen spra´vny´ „zacˇa´tek vykona´va´nı´ ko´du“ pro prvnı´ vla´kno, je uvedeno v souboru s programem). Kazˇde´ dalsˇ´ı vla´kno mu˚zˇe zacˇ´ıt vykona´vat ko´d z jine´ho mı´sta (a obvykle tomu tak je); dalsˇ´ı vla´kna prˇitom mohou vznikat jen tak, zˇe je vytvorˇ´ı neˇktere´ vla´kno jizˇ existujı´cı´. Prˇepı´na´nı´ se ty´ka´ prˇ´ımo vla´ken. Zdali prˇi prˇepnutı´ dojde k prˇepnutı´ take´ procesu, je pouze sekunda´rnı´ za´lezˇitost. Strategie pla´nova´nı´ se take´ ty´kajı´ vla´ken – round robin i priority majı´ jednotliva´ vla´kna. Vla´kna te´hozˇ procesu jsou tedy pla´nova´na neza´visle na sobeˇ a kazˇde´ mu˚zˇe mı´t jinou prioritu. Proces sa´m o sobeˇ prioritu k nicˇemu nepotrˇebuje, protozˇe se pla´nova´nı´ neu´cˇastnı´. Pru˚vodce studiem Aby nebylo vsˇe tak prˇ´ımocˇare´, ve Windows majı´ i procesy prioritu. S procesy se prˇi pla´nova´nı´ sice prˇ´ımo neoperuje, ale priorita procesu se scˇ´ıta´ s prioritou vla´ken, ktere´ do neˇj patrˇ´ı. Zmeˇnou priority procesu tedy ovlivnˇujeme priority vsˇech vla´ken. Tento vztah vsˇak ve Windows nenı´ prˇ´ımo linea´rnı´, podrobneˇji se s nı´m sezna´mı´me pozdeˇji.

Kazˇde´ vla´kno samozrˇejmeˇ ma´ vlastnı´ programovy´ za´sobnı´k. Jelikozˇ ale vla´kno ve skutecˇnosti sdı´lı´ adresovy´ prostor s ostatnı´mi vla´kny v ra´mci procesu, jeho programovy´ za´sobnı´k existuje ve skutecˇnosti v ra´mci adresove´ho prostoru procesu. Data na za´sobnı´ku jednoho vla´kna jsou tedy prˇ´ıstupna´ i jiny´m vla´knu˚m v ra´mci procesu. 5.3.3

Vla´kna na single–user u´loha´ch

Vla´kna se velmi cˇasto pouzˇ´ıvajı´ i na single–user u´loha´ch (tj. v programech pouzˇ´ıvany´ch jednı´m uzˇivatelem). Procˇ tomu tak je? Uved’me nejobvyklejsˇ´ı du˚vody:

46

Kazˇde´ vla´kno ma´ svu˚j za´sobnı´k.

Pra´ce na poprˇedı´ a na pozadı´ – Jedno vla´kno rˇesˇ´ı GUI (tj. pracuje na poprˇedı´), dalsˇ´ı vla´kno nebo i neˇkolik vla´ken neˇco pocˇ´ıta´ na pozadı´. Prˇ´ıkladem je kontrola pravopisu na pozadı´, kterou prova´dı´ textovy´ editor. Asynchronnı´ zpracova´nı´ – Toto je prˇ´ıpad, kdy neˇjakou cˇinnost spousˇtı´me asynchronneˇ, tj. bez ohledu na pru˚beˇh vy´pocˇtu programu (naprˇ. cˇasovacˇem). Prˇ´ıkladem mu˚zˇe by´t za´lohova´nı´ dat v pravidelny´ch intervalech cˇi zobrazova´nı´ cˇasu na hodina´ch. Rychlejsˇ´ı vykona´va´nı´ ko´du – Ma´-li pocˇ´ıtacˇ vı´ce nezˇ jeden procesor (CPU), mu˚zˇe je cı´leneˇ vyuzˇ´ıt k celkove´mu zrychlenı´ vy´pocˇtu. Modula´rnı´ architektura – Uva´dı´ se, zˇe modula´rnı´ vı´cevla´knove´ rˇesˇenı´ velky´ch syste´mu˚ je obecneˇ flexibilneˇjsˇ´ı a efektivneˇji vyuzˇ´ıva´ syste´move´ zdroje. Prˇ´ıkladem takove´ho syste´mu je naprˇ. DirectShow. 5.3.4

Technicka´ realizace vla´ken

Vla´kna mohou by´t do syste´mu zanesena dvojı´m zpu˚sobem – bud’ je jejich podpora veˇcı´ neˇjake´ doplnˇujı´cı´ knihovny (ktera´ prˇ´ıpadneˇ mu˚zˇe by´t i doda´va´na spolu s operacˇnı´m syste´mem, ale jedna´ se o beˇzˇnou knihovnu, ktera´ nevyzˇaduje zˇa´dne´ specia´lnı´ funkce po ja´dru operacˇnı´ho syste´mu), nebo jsou vla´kna podporova´na prˇ´ımo ja´drem. Oba tyto prˇ´ıstupy majı´ sve´ vy´hody a nevy´hody. Jsou-li vla´kna implementova´na v knihovneˇ, cozˇ je historicky prvnı´ zpu˚sob, jak byla vla´kna zavedena, z hlediska syste´mu se vı´cevla´knovy´ program sta´le jevı´ jako jediny´ proces. Vy´hodou tohoto prˇ´ıstupu je, zˇe prˇepı´na´nı´ vla´ken je o neˇco ma´lo rychlejsˇ´ı, nebot’ prˇi neˇm nedocha´zı´ k prˇechodu mezi uzˇivatelsky´m a privilegovany´m rezˇimem CPU. Aplikace, prˇesneˇji rˇecˇeno knihovna take´ mu˚zˇe ovlivnˇovat pla´nova´nı´ vla´ken – kdyzˇ si vla´kna prˇepı´na´ sama, mu˚zˇe pouzˇ´ıvat jiny´ pla´novacı´ algoritmus, nezˇ pouzˇ´ıva´ operacˇnı´ syste´m. Nevy´hodou tohoto prˇ´ıstupu je pra´veˇ fakt, zˇe z pohledu operacˇnı´ho syste´mu se aplikace jevı´ jako jediny´ proces. Pokud neˇktere´ vla´kno naprˇ. bude cˇekat na dokoncˇenı´ I/O operace, aplikace bude blokova´na na u´rovni procesu a nepobeˇzˇ´ı zˇa´dne´ vla´kno. Obecneˇ: Vla´kna jednoho procesu nikdy nemohou beˇzˇet soucˇasneˇ, takzˇe ani nelze vyuzˇ´ıt vı´ce procesoru˚ (pokud by v pocˇ´ıtacˇi byly). Podpora vla´ken v ja´dru operacˇnı´ho syste´mu odstranˇuje nevy´hody zmı´neˇne´ v prˇedchozı´m odstavci. Prˇepı´na´nı´ vla´ken je zde sice pomalejsˇ´ı, nebot’ jde vzˇdy cestou prˇes ja´dro, z ostatnı´ch pohledu˚ je vsˇak tento prˇ´ıstup vy´hodneˇjsˇ´ı. Vla´kno je zde jizˇ jednotkou prˇideˇlova´nı´ procesoru na u´rovni operacˇnı´ho syste´mu, takzˇe vla´kna jednoho procesu mohou beˇzˇet soucˇasneˇ (ma´me-li v pocˇ´ıtacˇi vı´ce CPU), stejneˇ tak cˇeka´nı´ jednoho vla´kna ostatnı´ vla´kna neblokuje. Podporuje-li operacˇnı´ syste´m vla´kna prˇ´ımo, nic mu nebra´nı´ poskytovat soucˇasneˇ i vy´sˇe zmı´neˇnou knihovnu pro vla´kna. Aplikace pak mohou vyuzˇ´ıvat kombinace obojı´ho a tı´m dosa´hnout efektivneˇjsˇ´ıho vyuzˇitı´ zdroju˚. Nevy´hodou je samozrˇejmeˇ vysˇsˇ´ı pracnost pro programa´tora. 5.3.5

Vztah proces–vla´kno

Obvykly´ vztah mezi procesy a vla´kny je typu 1:N, tj. jeden proces ma´ neˇkolik vla´ken. Na pocˇ´ıtacˇovy´ch klastrech je mozˇno potkat take´ vztah N:1, kdy jedno vla´kno mu˚zˇe putovat mezi pocˇ´ıtacˇi. Tato varianta je samozrˇejmeˇ vyuzˇ´ıva´na zrˇ´ıdka, protozˇe prˇesun vla´kna na jiny´ vy´pocˇetnı´ uzel je cˇasoveˇ na´rocˇna´ operace. Podobneˇ mu˚zˇeme definovat i zobecneˇny´ prˇ´ıpad M:N, kdy kazˇdy´ proces ma´ neˇkolik vla´ken a ta mohou by´t rozmı´steˇna na ru˚zny´ch vy´pocˇetnı´ch uzlech. Tuto variantu povazˇujme pro jejı´ technickou na´rocˇnost za zcela teoretickou. Poslednı´ nezmı´neˇny´ prˇ´ıpad, tedy vztah 1:1, je prˇ´ıpadem syste´mu, kde vla´kna nejsou vu˚bec zavedena (historicke´ syste´my). Shrnutı´ 47

Vla´kna jsou implementova´na knihovnou, nebo prˇ´ımo v ja´dru.

Tato kapitola je prvnı´ z bloku veˇnovane´ho spra´veˇ procesoru. Prˇedstavili jsme si prˇedevsˇ´ım dva za´kladnı´ pojmy: proces a vla´kno. Vysveˇtlili jsme si take´, jak se pla´nuje prˇideˇlova´nı´ procesoru procesu˚m a vla´knu˚m a jak jsou vla´kna technicky realizova´na v syste´mu. V na´sledujı´cı´ kapitole se podı´va´me na procesy a vla´kna v konkre´tnı´ch operacˇnı´ch syste´mech. Pojmy k zapamatova´nı´ • • • • • • •

proces zˇivotnı´ cyklus procesu vla´kno pla´novacˇ u´loh preempce cyklicka´ obsluha (round–robin) priorita

Kontrolnı´ ota´zky 1. Popisˇte obecny´ zˇivotnı´ cyklus procesu. 2. Vysveˇtlete, procˇ TSS odkazuje prˇ´ımo do GDT, a ne do LDT. 3. Procˇ je prˇepı´na´nı´ procesu˚ obvykle rˇesˇeno hardwaroveˇ? Ma´ to i neˇjake´ nevy´hody? Proved’te diskuzi. 4. Pla´novacı´ algoritmus urcˇuje porˇadı´ vykona´nı´ procesu˚. Ma´me-li n procesu˚, ktere´ majı´ probeˇhnout v neˇjake´m porˇadı´ vzˇdy cele´, kolik mozˇny´ch variant pla´nu˚ existuje? 5. Ktere´ z na´sledujı´cı´ch operacı´ vyzˇadujı´ privilegovany´ rezˇim? Nastavenı´ cˇasovacˇe, cˇtenı´ hodin, instrukce simulujı´cı´ zastavenı´ programu vy´jimkou, za´kaz prˇerusˇenı´, modifikace tabulek informacı´ o I/O zarˇ´ızenı´ch, prˇepnutı´ z uzˇivatelske´ho do privilegovane´ho rezˇimu, prˇ´ıstup k I/O zarˇ´ızenı´. 6. Kooperativnı´ multitasking je povazˇova´n obecneˇ za me´neˇ dokonaly´. Jake´ v tomto syste´mu vidı´te vy´hody? A kterou z jeho nevy´hod vidı´te z dnesˇnı´ho pohledu jako klı´cˇovou? Proved’te diskuzi. 7. Strategie cyklicke´ho a prioritnı´ho prˇideˇlova´nı´ procesoru se v praxi v cˇiste´ podobeˇ nepouzˇ´ıvajı´. Uved’te neˇkolik prˇ´ıkladu˚, k jaky´m proble´mu˚m by nasazenı´ v jejich cˇiste´ podobeˇ vedlo. 8. Uved’te neˇkolik konkre´tnı´ch prˇ´ıkladu˚, kde vı´ce vla´ken poma´ha´ zkvalitnit pra´ci v jednouzˇivatelske´m syste´mu. 9. Uved’te me´neˇ obvykle´ vztahy proces – vla´kno. Ktery´ zpu˚sob vazby povazˇujete za zcela nejokrajoveˇjsˇ´ı (nejme´neˇ obvykly´)? Cvicˇenı´ 1. Napisˇte program pro secˇtenı´ vsˇech prvku˚ v poli, ktery´ vyuzˇije vla´kna k rychlejsˇ´ımu beˇhu. K simulaci vı´ceprocesorove´ho pocˇ´ıtacˇe vlozˇte za kazˇdou dı´lcˇ´ı operaci soucˇtu cˇeka´nı´ 1 milisekundu. Funkci programu oveˇrˇte zmeˇrˇenı´m vy´pocˇetnı´ho cˇasu pro ru˚zne´ pocˇty vla´ken (na dostatecˇneˇ velke´m poli).

48

6

Spra´va procesoru v praxi

Studijnı´ cı´le: V te´to kapitole nava´zˇeme na znalosti z kapitoly prˇedchozı´ a sezna´mı´me se s prakticky´mi implementacemi spra´vy procesoru, konkre´tneˇ na syste´mech Windows NT a Unix. Syste´m NT si v neˇktery´ch bodech popı´sˇeme poneˇkud detailneˇji, protozˇe se jedna´ v soucˇasnosti o nejrozsˇ´ırˇeneˇjsˇ´ı operacˇnı´ syste´m pocˇ´ıtacˇu˚ PC. Klı´cˇova´ slova: spra´va procesoru, Unix, POSIX, Windows NT, priorita, afinita Potrˇebny´ cˇas: 150 minut.

6.1

Unix – Vytvorˇenı´, pla´nova´nı´ a stavy procesu

Syste´my oznacˇovane´ jako Unix jsou operacˇnı´ syste´my urcˇene´ prima´rneˇ pro serverove´ pocˇ´ıtacˇe a existujı´ jizˇ neˇkolik desetiletı´. Za tu dobu vzniklo velke´ mnozˇstvı´ verzı´, my si popı´sˇeme prˇedevsˇ´ım obecneˇ platne´ vlastnosti unixovy´ch syste´mu˚. Do te´to skupiny patrˇ´ı take´ syste´m Linux, cozˇ je nekomercˇnı´ operacˇnı´ syste´m, ktery´ poskytuje stejne´ rozhranı´ (API) zvane´ POSIX. Pra´veˇ rozhranı´ POSIX je spojujı´cı´m prvkem vsˇech soucˇasny´ch unixovy´ch syste´mu˚, dı´ky tomuto rozhranı´ jsou programy mezi ru˚zny´mi operacˇnı´mi syste´my z te´to rodiny do jiste´ mı´ry prˇenositelne´. Pru˚vodce studiem Acˇkoliv tato kapitola je rozdeˇlena na povı´da´nı´ o Unixu a o Windows, i syste´m Windows NT v neˇktery´ch verzı´ch umı´ rozhranı´ POSIX. Nenı´ to vsˇak jeho prima´rnı´ rozhranı´ a v praxi se pouzˇ´ıva´ jen velmi zrˇ´ıdka.

6.1.1

Stavy procesu

Stavy procesu˚ v Unixu jsou zna´zorneˇny na obra´zku 8. Rozlisˇujeme zde deveˇt stavu˚: 1. Created – Proces je vytvorˇen. 2. Ready to run in memory – Proces je prˇipraven k beˇhu a cˇeka´, azˇ na neˇj vyjde rˇada (prˇesneˇji rˇecˇeno: azˇ jej pla´novacˇ vybere k beˇhu). 3. Ready to run, swapped out – Proces je prˇipraven k beˇhu, ale nenı´ v pameˇti. 4. Sleeping in memory – Proces cˇeka´ na prostrˇedek aj. 5. Sleeping swapped out – Proces cˇeka´ a navı´c nenı´ v pameˇti. 6. Kernel running – Beˇzˇ´ı ja´dro syste´mu. 7. User running – Proces beˇzˇ´ı (pouze zde se vykona´va´ vlastnı´ ko´d programu). 8. Pre-empted – Beˇh procesu je na´silneˇ prˇerusˇen (preempce). 9. Zombie – proces skoncˇil, ale jesˇteˇ je o jeho existenci za´znam v syste´mu. Prˇi studiu zˇivotnı´ho cyklu a stavu˚ procesu samozrˇejmeˇ nejde jen o to pojmenovat neˇjak oneˇch 9 ru˚zny´ch stavu˚, ale du˚lezˇite´ je take´ vsˇimnout si a pochopit prˇechody mezi stavy. Naprˇ´ıklad vola´nı´ sluzˇeb OS probı´ha´ prˇ´ımo v aplikacˇnı´m procesu (tj. proces je prˇepnut do kernel rezˇimu a sa´m si vykona´ ko´d sluzˇby OS). Beˇhem vykona´va´nı´ sluzˇeb OS nemu˚zˇe by´t proces prˇerusˇen preempcı´. Proces vykona´vajı´cı´ ko´d ja´dra vsˇak mu˚zˇe by´t prˇerusˇen (hardwarovy´m i softwarovy´m) prˇerusˇenı´m. Probı´hajı´cı´ obsluha prˇerusˇenı´ mu˚zˇe by´t take´ prˇerusˇena dalsˇ´ım prˇerusˇenı´m. Popisˇme si jesˇteˇ, jak v Unixu funguje preempce: V za´kladnı´m prˇ´ıpadeˇ se jı´ u´cˇastnı´ 2 procesy, oznacˇme si je A a B. Proces A je v rezˇimu „User Running“ a vykona´va´ svu˚j ko´d. Preempce 49

Obra´zek 8: Stavy procesu v Unixu. [Bac86, BoCe05] je nava´za´na na cˇasovacˇ. Jakmile nastane prˇerusˇenı´ cˇasovacˇe, je aktivova´na obsluha prˇerusˇenı´ (proces A je tedy prˇepnut do rezˇimu ja´dra) a aktivova´n ko´d pla´novacˇe. Pla´novacˇ (nynı´ beˇzˇ´ıcı´ jako proces A) prˇepne rˇ´ızenı´ na proces B. Pla´novacˇ (nynı´ beˇzˇ´ıcı´ jako proces B) pak zmeˇnı´ stav procesu A na „Pre-empted“ a ukoncˇ´ı obsluhu prˇerusˇenı´. Tı´m je proces B prˇepnut zpeˇt do jeho prˇedchozı´ho stavu (obvykle „User Running“). 6.1.2

Vytvorˇenı´ procesu

Procesy v Unixu vytva´rˇejı´ hierarchii, tj. kazˇdy´ proces ma´ sve´ho rodicˇe (cozˇ je proces, ktery´m byl vytvorˇen). Prˇi nabı´ha´nı´ syste´mu vznika´ iniciacˇnı´ proces, ktery´ je korˇenem stromu, dalsˇ´ı procesy mohou vniknout jedineˇ klonova´nı´m neˇjake´ho existujı´cı´ho procesu – k tomu slouzˇ´ı prˇ´ıkazy fork a exec. Prˇ´ıkaz fork klonuje volajı´cı´ proces, cˇili po zavola´nı´ se funkce „vracı´“ do dvou identicky´ch procesu˚. Rodicˇe a potomka rozlisˇ´ıme pouze dle na´vratove´ hodnoty te´to funkce (rodicˇovi vracı´ cˇ´ıslo procesu potomka, potomkovi vracı´ nulu), jinak jsou skutecˇneˇ identicke´. Syste´m se prˇitom snazˇ´ı o maxima´lneˇ u´sporne´ rˇ´ızenı´ pameˇti – ko´d a veˇtsˇina dat je v obou teˇchto procesech totozˇna´, pameˇt’je tedy sdı´lena´. K implementaci klonova´nı´ pameˇti se jesˇteˇ vra´tı´me v kapitole 9. Po vytvorˇenı´ klonu pak prˇ´ıkazem exec nahradı´me ko´d volajı´cı´ho programu novy´m programem. 50

Procesy v Unixu vytva´rˇejı´ hierarchii. Prˇ´ıkaz fork klonuje (tj. zdvojı´) proces.

Tı´m je vytvorˇenı´ procesu dokoncˇeno. 6.1.3

Pla´nova´nı´ procesu˚

Ve starsˇ´ıch verzı´ch Unixu se pouzˇ´ıval na´sledujı´cı´ syste´m pla´nova´nı´: Syste´m pouzˇ´ıva´ tzv. prioritnı´ frontu, cˇili neˇkolik front procesu˚, kde kazˇda´ fronta odpovı´da´ jine´ prioriteˇ. Procesy jsou obsluhova´ny dle priority a na stejne´ u´rovni cyklicky. Klı´cˇovy´ je prˇitom princip zarˇazova´nı´ procesu˚ do front: Novy´ proces dostane vysokou prioritu. Jak proces sta´rne, jeho priorita je pak snizˇova´na; proces je prˇerˇazen do nizˇsˇ´ı u´rovneˇ priority vzˇdy prˇi preempci, zatı´mco prˇi dobrovolne´m odevzda´nı´ procesoru je mu priorita zachova´na. Tento prˇ´ıstup samozrˇejmeˇ uprˇednostnˇuje kra´tke´ u´lohy, cozˇ mu˚zˇe by´t vy´hodne´. Nevy´hodou mu˚zˇe by´t hladoveˇnı´ (starvation) starsˇ´ıch procesu˚. Naprˇ´ıklad prˇi rychle´m prˇida´va´nı´ novy´ch procesu˚ se ty nejstarsˇ´ı nedostanou vu˚bec k procesoru, protozˇe novy´ proces vzˇdy dostane prˇednost a beˇzˇ´ı alesponˇ 1 cˇasove´ kvantum. Od verze 4 pouzˇ´ıva´ Unix trˇi trˇ´ıdy priorit: • Rea´lny´ cˇas (pro kriticke´ procesy) • Syste´move´ procesy • Uzˇivatelske´ procesy Proces se nemu˚zˇe dostat do jine´ trˇ´ıdy priorit, nezˇ ve ktere´ vznikl. Pla´nova´nı´ procesu˚ v Linuxu je podrobneˇ popsa´no naprˇ. v knize [BoCe05] (viz take´ http://www.oreilly.com/catalog/linuxkernel/chapter/ch10.html).

6.2 6.2.1

NT – Vytvorˇenı´ procesu, pla´nova´nı´ a stavy vla´kna Stavy vla´kna

V NT se pla´nova´nı´ zu´cˇastnˇujı´ vla´kna (nikoliv procesy), jejich mozˇne´ stavy jsou zna´zorneˇny na obra´zku 9. Rozlisˇujeme jich sedm: 1. Initialized – Pomocny´ stav, prˇechodneˇ beˇhem inicializace vla´kna. 2. Ready – Cˇekajı´cı´ (pouze z teˇchto vla´ken vybı´ra´ scheduler dalsˇ´ı k beˇhu). 3. Standby – Vla´kno je prˇipraveno k beˇhu na konkre´tnı´m procesoru. Jen jedno vla´kno mu˚zˇe by´t v tomto stavu (na kazˇdy´ procesor). Tento stav mu˚zˇe skoncˇit (a) prˇechodem do stavu Running (kdyzˇ se Running stav uvolnı´). (b) preempcı´ (jine´ vla´kno zacˇne by´t Standby, toto je vra´ceno do fronty Ready). 4. Running – Beˇzˇ´ıcı´ (je vykona´va´n ko´d programu). Tento stav mu˚zˇe skoncˇit (a) preempcı´ s prˇepnutı´m na vla´kno vysˇsˇ´ı priority. Toto vla´kno je vra´ceno do Standby nebo na zacˇa´tek sve´ fronty v Ready. (b) uplynutı´m kvanta. Toto vla´kno je pak umı´steˇno na konec sve´ fronty v Ready. (c) dobrovolny´m prˇechodem do stavu Waiting. (d) ukoncˇenı´m vla´kna. 5. Waiting – Cˇekajı´cı´ (na neˇjaky´ objekt). Po skoncˇenı´ cˇeka´nı´ se vla´kno prˇepne do stavu Ready, nebo prˇ´ımo do Standby cˇi Running (to nastane, pokud ma´ vysokou prioritu). 6. Transition – Vla´kno ma´ za´sobnı´k mimo fyzickou pameˇt’ (odstra´nkovany´). Jakmile se za´sobnı´k dostane zpa´tky do pameˇti, vla´kno prˇecha´zı´ do stavu Ready. 51

Obra´zek 9: Stavy procesu v NT. [SoRu05] 7. Terminated – Ukoncˇeno. Z tohoto stavu lze vla´kno znovu ozˇivit do stavu Initializing. Nejvı´c vla´ken je obvykle ve stavech Waiting nebo Ready. Pla´novacˇ vybı´ra´ vla´kna pro beˇh pra´veˇ jen z Ready vla´ken. Ta ma´ organizova´na do specia´lnı´ prioritnı´ fronty, technicky je samostatna´ fronta pro kazˇdou hodnotu priority. Jak si uka´zˇeme pozdeˇji, vla´kna jsou obvykle prˇepı´na´na v okamzˇiku prˇerusˇenı´ cˇasovacˇe, kdy je dosud beˇzˇ´ıcı´ vla´kno zarˇazeno na konec sve´ fronty a pro beˇh je vybra´no jine´ vla´kno. Jakmile se vsˇak objevı´ vla´kno s vysˇsˇ´ı prioritou ve stavu Ready, nezˇ ma´ vla´kno Running, dojde k okamzˇite´mu prˇepnutı´. (Obdobneˇ to platı´ i pro stav Standby.) Tomuto okamzˇite´mu prˇepnutı´ rˇ´ıka´me preempce – beˇzˇ´ıcı´ vla´kno je vra´ceno na zacˇa´tek sve´ fronty (cˇi do stavu Standby) a nove´ vla´kno ihned beˇzˇ´ı. Vsˇimneˇte si, zˇe preempce vracı´ vla´kno na zacˇa´tek fronty, nikoliv na konec, kam se dosta´va´ jedineˇ po dokoncˇenı´ cele´ho cˇasove´ho u´seku (azˇ do prˇerusˇenı´ pravidelny´m cˇasovacˇem) bez preempce. 6.2.2

Vytvorˇenı´ procesu

Syste´m NT nevyzˇaduje u procesu˚ vztah rodicˇ–potomek jako unixove´ syste´my. Novy´ proces vznika´ vzˇdy spusˇteˇnı´m neˇjake´ho spustitelne´ho souboru (funkce CreateProcess). NT prˇitom pouzˇ´ıva´ princip tzv. subsyste´mu˚, dı´ky neˇmuzˇ lze v ra´mci jednoho operacˇnı´ho syste´mu provozovat programy urcˇene´ pro ru˚zne´ operacˇnı´ syste´my. Spustitelny´ soubor ma´ obvykle zna´mou prˇ´ıponu exe a je ve forma´tu PE (Portable Executable). Tyto soubory majı´ hlavicˇku, podle ktere´ OS mj. pozna´, v jake´m subsyste´mu se ma´ program spustit. Spousˇteˇcı´ ko´d v ja´dru syste´mu NT je jen jeden a umozˇnˇuje spousˇteˇnı´ programu˚ mezi ru˚zny´mi subsyste´my. V jednom souboru lze take´ mı´t vı´ce verzı´ programu, cozˇ se vsˇak v praxi prˇ´ılisˇ nepouzˇ´ıva´. Pru˚vodce studiem Prˇ´ıkladem ulozˇenı´ vı´ce verzı´ programu do jednoho souboru je ona zna´ma´ hla´sˇka „This program cannot be run in DOS mode.“, ktera´ se zobrazı´, spustı´me-li Win32 program v DOSu. Syste´m MS-DOS sice neumı´ poznat, zˇe jde o program pro Windows (resp. Win32), ale prˇi spusˇteˇnı´ spousˇtı´ prvnı´ verzi programu v souboru, kde je kra´tky´ program pra´veˇ pro

52

Proces v NT vznika´ spusˇteˇnı´m programu.

syste´m MS-DOS, ktery´ vypı´sˇe onu hla´sˇku. Prˇi spusˇteˇnı´ te´hozˇ souboru ve Windows syste´m najde Win32 za´znam a da´ mu prˇednost. Ve spustitelny´ch souborech typu PE lze takto mı´t pohromadeˇ verze pro ru˚zne´ operacˇnı´ syste´my cˇi procesory (x86, Itanium, Alpha apod.).

Mnozˇina podporovany´ch subsyste´mu˚ se lisˇ´ı dle verze Windows. Beˇhem let jsme se mohli setkat kromeˇ subsyste´mu Win32, cozˇ je samozrˇejmeˇ prima´rnı´ rozhranı´ syste´mu, ktere´ nejcˇasteˇji pouzˇ´ıva´me, take´ se subsyste´my Win16, DOS, OS/2 cˇi POSIX. Neˇktere´ tyto subsyste´my jsou mezi sebou prova´zane´, cˇili nejde vzˇdy o cˇiste´ implementace fungujı´cı´ jen pomocı´ funkcı´ ja´dra NT. Samotne´ ja´dro syste´mu NT poskytuje tzv. „NT API“, cozˇ je nedokumentovana´ sada funkcı´, ktery´mi jsou pak implementova´ny jednotlive´ subsyste´my. NT API poskytuje univerza´lnı´ funkcionalitu, aby pomocı´ neˇj mohly by´t implementova´ny vsˇechny subsyste´my. Pru˚vodce studiem Rozhranı´ Win32 se proslavilo zejme´na dı´ky syste´mu Windows 95. Prvnı´m syste´m, kde bylo implementova´no, vsˇak bylo Windows NT. Ani jeden z teˇchto syste´mu˚ vsˇak Win32 nema´ jako prima´rnı´ rozhranı´. Zatı´mco NT ma´ sve´ vlastnı´ NT API, Windows 95 ma´ Win32 implementova´no nad starsˇ´ım 16bitovy´m rozhranı´m Win16, ktere´ prˇevzalo ze sve´ prˇedchozı´ verze (Windows 3.11).

Jistou nevy´hodou je, zˇe NT API je skutecˇneˇ nedokumentovane´. Ma´ to ale i jeden pozitivnı´ du˚sledek: Programy napsane´ pro neˇjaky´ subsyste´m nepouzˇ´ıvajı´cı´ prˇ´ımo NT API jsou prˇenositelne´ i na jine´ operacˇnı´ syste´my s dany´m API. Navı´c je tı´m zajisˇteˇna jista´ cˇistota programu˚, nebot’ nenı´ mozˇno mı´chat ru˚zna´ API dohromady. Pru˚vodce studiem Univerza´lnost syste´mu NT ma´ i neˇktere´ pomeˇrneˇ zajı´mave´ du˚sledky. Naprˇ. souborovy´ syste´m NTFS je mozˇno pouzˇ´ıt pro vsˇechny subsyste´my, takzˇe umı´ pracovat jak v rezˇimu bez rozlisˇenı´ velky´ch a maly´ch pı´smen (pro Win32), tak v rezˇimu velikost pı´smen rozlisˇujı´cı´m (pro POSIX). Podobneˇ prˇ´ıkaz fork pro duplikova´nı´ procesu je prˇ´ıtomen i v NT, i kdyzˇ ve Win32 rezˇimu jej nemu˚zˇeme prˇ´ımo pouzˇ´ıt.

6.2.3

Pla´nova´nı´ vla´ken

Jak jizˇ vı´me, v syste´mu NT se pla´nujı´ vla´kna, nikoliv procesy. Z toho na´m hned vyplyne jedna du˚lezˇita´ vlastnost NT: Zalozˇ´ı-li si jeden proces 9 vla´ken (funkcı´ CreateThread) a druhy´ jen jedno, prvnı´ proces bude mı´t 90% procesoru pro sebe. Toto samozrˇejmeˇ platı´ za prˇedpokladu, zˇe vsˇechna tato vla´kna budou mı´t stejnou prioritu, nebot’ pla´nova´nı´ v NT je prioritnı´ a potom cyklicke´ na stejne´ u´rovni priorit. Vla´kno s vysˇsˇ´ı prioritou ma´ tedy vzˇdy prˇednost. Aby nedocha´zelo k hladoveˇnı´ (starvation) vla´ken s nejnizˇsˇ´ı prioritou, v syste´mu jsou dalsˇ´ı doplnˇkove´ mechanizmy – ty si prˇedstavı´me nı´zˇe. Vla´kno vybrane´ k beˇhu dostane CPU na dobu jednoho cˇasove´ho kvanta. Ru˚zne´ verze OS mohou mı´t (a majı´) ru˚zneˇ dlouha´ kvanta, rozlisˇujeme zde syste´my Workstation (naprˇ. Windows XP nebo Windows 2000 Professional) a Server (naprˇ. Windows Server 2003 nebo Windows 2000 Server). Beˇzˇ´ıcı´ vla´kno mu˚zˇe by´t prˇerusˇeno i prˇedcˇasneˇ (prˇed skoncˇenı´m prˇideˇlene´ho kvanta), pak hovorˇ´ıme o preempci. Syste´my NT jizˇ od pomeˇrneˇ da´vny´ch cˇasu˚ take´ podporujı´ vı´ceprocesorove´ pocˇ´ıtacˇe a pro tento u´cˇel ma´ proces i kazˇde´ jeho vla´kno take´ afinitu (anglicky affinity) – je to bitova´ maska urcˇujı´cı´, na ktere´ CPU mu˚zˇe by´t vla´kno pla´nova´no. Vy´chozı´ 53

Pla´nova´nı´ v NT je na u´rovni vla´ken.

nastavenı´ je, zˇe vla´kno mu˚zˇe beˇzˇet na libovolne´m CPU; u jednoprocesorovy´ch pocˇ´ıtacˇu˚ afinita samozrˇejmeˇ nema´ vy´znam. Na pla´nova´nı´ nema´ vliv, zda vla´kno pra´veˇ vykona´va´ ko´d ja´dra syste´mu, nebo beˇzˇny´ uzˇivatelsky´ ko´d. Jakmile ma´ mensˇ´ı prioritu nezˇ jine´ vla´kno, je prˇepnuto. Vykona´va´nı´ ko´du ja´dra syste´mu proto mu˚zˇe by´t pla´novacˇem de facto prˇerusˇeno, syste´m tı´m nijak netrpı´. Kriticka´ mı´sta, naprˇ´ıklad ko´d samotne´ho pla´novacˇe, jsou prˇed prˇepnutı´m chra´neˇna pomocı´ syste´mu prˇerusˇenı´. Prˇerusˇenı´ ma´ v pocˇ´ıtacˇi z principu vysˇsˇ´ı prioritu nezˇ jake´koliv vla´kno. Ko´d beˇzˇ´ıcı´ jako prˇerusˇenı´ tedy nemu˚zˇe by´t prˇerusˇen zˇa´dny´m vla´knem. Pocˇ´ıtacˇe PC jesˇteˇ rozlisˇujı´ mnoho ru˚zny´ch prˇerusˇenı´, ktere´ mezi sebou take´ majı´ prioritu a platı´, zˇe ko´d obsluhy prˇerusˇenı´ mu˚zˇe by´t prˇerusˇen jen prˇerusˇenı´m s vysˇsˇ´ı prioritou, nezˇ ma´ on sa´m. Syste´m priorit prˇerusˇenı´ je vlastneˇ u´plneˇ samostatny´ syste´m priorit, ktery´ je nadrˇazen priorita´m vla´ken. V NT ma´ take´ hodnoty 0–31 a vla´kna mohou dostat prioritu prˇerusˇenı´ jen 0 nebo 1, pla´novacˇ ma´ vzˇdy 2 a dalsˇ´ı vysˇsˇ´ı cˇ´ısla jsou pro skutecˇna´ prˇerusˇenı´ v pocˇ´ıtacˇi. Scheduler/dispatcher Cˇa´stı´ ja´dra odpoveˇdnou za pla´nova´nı´ a prˇepı´na´nı´ vla´ken je scheduler/dispatcher, jednodusˇe rˇecˇeno „pla´novacˇ“. Ten je aktivova´n kdyzˇ a) neˇjake´ vla´kno prˇejde do stavu Ready (noveˇ vytvorˇene´ nebo po skoncˇenı´ cˇeka´nı´). Kdyzˇ toto ma´ vysˇsˇ´ı prioritu, prˇijde na rˇadu preempce. b) beˇzˇ´ıcı´ vla´kno opustı´ stav Running (konec kvanta, konec vla´kna, cˇi prˇechod do stavu Waiting). c) dojde ke zmeˇneˇ priority (libovolne´ho) vla´kna (bud’ cı´leneˇ vola´nı´m funkce OS, nebo kdyzˇ prioritu vla´knu zmeˇnı´ sa´m syste´m). d) dojde ke zmeˇneˇ afinity (libovolne´ho) vla´kna. Cˇ´ıslova´nı´ priorit Priority vla´ken jsou v ja´dru NT cˇ´ıslova´ny 0–31, je jich tedy prˇesneˇ 32. Vysˇsˇ´ı prioritu nezˇ 31 prˇitom majı´ jizˇ zmı´neˇna´ prˇerusˇenı´. Syste´m pouzˇ´ıva´ neˇktera´ vysˇsˇ´ı cˇ´ısla take´ pro oznacˇenı´ nejvı´ce preferovany´ch operacı´. (Priorita beˇzˇ´ıcı´ho ko´du se docˇasneˇ zvy´sˇ´ı, syste´m se tedy tva´rˇ´ı, jakoby to bylo prˇerusˇenı´, cˇ´ımzˇ zajistı´, zˇe dany´ kus ko´du nebude beˇhem vykona´va´nı´ prˇepnut na zˇa´dne´ jine´ vla´kno. Priority vla´ken a priority prˇerusˇenı´ fungujı´ ve skutecˇnosti neza´visle na sobeˇ, ale mu˚zˇeme je cha´pat i jako spolecˇnou veˇc, cozˇ pomu˚zˇe sna´ze pochopit chova´nı´ syste´mu v urcˇity´ch specia´lnı´ch situacı´ch.) V souvislosti s prioritami je nutno rozlisˇit za´kladnı´ pojmy: Trˇ´ıda priority je vlastnostı´ procesu Win32. Je to vzˇdy jedna z neˇkolika hodnot popsany´ch nı´zˇe. (Nenı´ to cˇ´ıslo, ale pojmenovana´ hodnota z vy´cˇtove´ho typu.) Priorita procesu je hodnota ja´dra NT v rozmezı´ 0–31. Priorita vla´kna je uda´va´na relativneˇ (tj. odchylkou) vzhledem k prioriteˇ jeho procesu. Secˇtenı´m te´to hodnoty s prioritou procesu pak zı´ska´me opeˇt cˇ´ıslo 0–31, podle ktere´ho se pak pla´nujı´ vla´kna pla´novacˇem (azˇ na vy´jimky, viz da´le v textu). Scheduler/dispatcher dynamicky meˇnı´ priority vla´ken tak, aby syste´m jako celek beˇzˇel co nejle´pe (podrobneˇji vysveˇtlı´me nı´zˇe). Proto priorita vypocˇtena´ jako soucˇet priority procesu a relativnı´ priority vla´kna nenı´ cˇasto vy´slednou prioritou, ale jen hodnotou, ktera´ se da´le upravuje syste´mem.

54

Priority jsou v NT cˇ´ıslova´ny 0–31.

Aby nedocha´zelo k nechteˇny´m situacı´m, priority jsou rozdeˇleny do trˇ´ı samostatny´ch rozsahu˚ a platı´ pravidlo, zˇe scheduler/dispatcher nikdy nezmeˇnı´ prioritu vla´kna tak, aby se dostalo do jine´ho rozsahu. Idle u´rovenˇ (0) Toto je vyhrazeno pro „Zero page thread“, cozˇ je jedno syste´move´ vla´kno starajı´cı´ se o nulova´nı´ nepouzˇ´ıvane´ pameˇti. Jelikozˇ ma´ nejnizˇsˇ´ı prioritu, beˇzˇ´ı pouze tehdy, kdyzˇ nenı´ vu˚bec nic jine´ho na pra´ci. Syste´m NT totizˇ z bezpecˇnostnı´ch du˚vodu˚ nikdy neprˇideˇlı´ pameˇt’procesu bez toho, aby ji vynuloval. (Pokud je CPU vytı´zˇen a Zero page thread nebeˇzˇ´ı, pameˇt’ je nulova´na azˇ v okamzˇiku alokace.) Jakmile jsou vsˇechny volne´ pameˇt’ove´ stra´nky vynulovane´, CPU spı´ (vykona´nı´m instrukce hlt spı´ do dalsˇ´ıho prˇerusˇenı´). Dynamicke´ u´rovneˇ (1–15) Zde jsou beˇzˇne´ uzˇivatelske´ aplikace i cˇa´st operacˇnı´ho syste´mu. Cˇ´ıslo 15 je obvykle pouzˇ´ıva´no jen cˇasovacˇem (aby meˇl vysˇsˇ´ı prioritu nezˇ vsˇe ostatnı´). Real-time u´rovneˇ (16–31) Toto je pouze pro kriticke´ cˇa´sti operacˇnı´ho syste´mu. (Nutno vsˇak podotknout, zˇe ani zvy´sˇenı´ priority do te´to hladiny nezarucˇuje prˇideˇlenı´ CPU v neˇjake´m pevne´m cˇase. Proto NT nenı´ syste´mem rea´lne´ho cˇasu.) Pru˚vodce studiem Pro zajı´mavost: Zero page thread nenı´ ve skutecˇnosti beˇzˇne´ vla´kno s prioritou 0, ale jen ko´d, ktery´ ani nema´ zˇa´dnou prioritu a jednodusˇe beˇzˇ´ı, kdyzˇ pla´novacˇ nema´ zˇa´dne´ jine´ vla´kno k beˇhu. Prioritu 0 ve skutecˇnosti nelze zˇa´dne´mu vla´knu nastavit a ko´d Zero page thread je vykona´va´n skutecˇneˇ jen tehdy, kdyzˇ pla´novacˇ nema´ jine´ho kandida´ta na beˇh. (V programu Spra´vce u´loh se Zero page thread zobrazuje pod tajemny´m oznacˇenı´m „Necˇinne´ procesy syste´mu“ a i dalsˇ´ı podobne´ programy mu da´vajı´ jina´ dosti podivna´ jme´na.)

Trˇ´ıdy priorit Subsyste´m Win32 pouzˇ´ıva´ syste´m tzv. trˇ´ıd priorit. Kazˇdy´ proces patrˇ´ı do jedne´ z na´sledujı´cı´ch sˇesti trˇ´ıd. Real-time (24) rea´lny´ cˇas (pouzˇ´ıvajı´ jen kriticke´ cˇa´sti ja´dra syste´mu a ovladacˇu˚ zarˇ´ızenı´) High (13) vysoka´ priorita Above normal (10) nad norma´lem (nenı´ ve starsˇ´ıch verzı´ch Windows) Normal (8) norma´lnı´ priorita Below normal (6) pod norma´lem (nenı´ ve starsˇ´ıch verzı´ch Windows) Idle (4) necˇinny´ proces Trˇ´ıda priority urcˇuje, prˇiblizˇneˇ jakou prioritu budou mı´t vsˇechna vla´kna dane´ho procesu. Cˇ´ıslo v za´vorce za na´zvem trˇ´ıdy je pra´veˇ tou hodnotou priority, ktera´ je vy´chozı´. Mu˚zˇeme jej nazy´vat ba´zovou prioritou procesu. Trˇ´ıda priority je tedy vlastnostı´ procesu a urcˇuje vy´chozı´ prioritu pro vsˇechna vla´kna tohoto procesu. Kazˇde´ vla´kno ve Win32 ma´ prioritu urcˇenou jako relativnı´ hodnotu (norma´lneˇ tedy 0, vysˇsˇ´ı priority jsou kladna´ cˇ´ısla, nizˇsˇ´ı priority jsou za´porna´ cˇ´ısla). Zmeˇnı´me-li trˇ´ıdu priority beˇzˇ´ıcı´ho procesu, zmeˇnı´ se tı´m priority vsˇech jeho existujı´cı´ch vla´ken. Relativnı´ priorita vla´kna prˇitom nemu˚zˇe by´t libovolne´ cˇ´ıslo, ale jen jedna ze sedmi konstant, ktere´ numericky vyjadrˇujı´ hodnoty -15, -2, -1, 0, +1, +2, +15. Vla´kna jednoho procesu tedy nemohou mı´t libovolnou prioritu, ale jen neˇkolik vybrany´ch hodnot v okolı´ ba´zove´ priority procesu nebo jednu z meznı´ch hodnot 1 (idle) nebo 15 (time critical). Graficky ukazuje mapova´nı´ priorit Windows API do NT cˇ´ısel obra´zek 10. 55

Obra´zek 10: Mapova´nı´ priorit Windows API do cˇ´ısel priorit NT ja´dra. [SoRu05]

Pru˚vodce studiem Jak uva´dı´ [SoRu05], neˇktere´ syste´move´ procesy majı´ i jine´ ba´zove´ priority, nezˇ ty, ktere´ jsou ve vy´sˇe uvedene´m seznamu trˇ´ıd priorit. Tyto vsˇak nelze nastavit prˇes Windows API, ale jen prˇ´ımy´m vola´nı´m prˇ´ıslusˇne´ funkce NT ja´dra. (Toto nezkousˇejte, je to nedokumentovana´ funkcionalita a slouzˇ´ı to k jemne´mu vyladeˇnı´ beˇhu syste´mu.)

Z pohledu pla´novacˇe ma´ kazˇde´ vla´kno ve skutecˇnosti dveˇ hodnoty priority: ba´zovou (base) a aktua´lnı´ (current). Ba´zova´ priorita vla´kna je soucˇtem hodnoty trˇ´ıdy priority procesu a relativnı´ priority vla´kna, jak jsme si vysveˇtlili vy´sˇe. Aktua´lnı´ priorita vla´kna je druha´ hodnota, ktera´ mu˚zˇe by´t vysˇsˇ´ı nezˇ ba´zova´. Smyslem tohoto rˇesˇenı´ je, zˇe zatı´mco sa´m program a potazˇmo programa´tor ovlivnˇuje jen ba´zovou prioritu, operacˇnı´ syste´m ji mu˚zˇe dle potrˇeby docˇasneˇ zvysˇovat (anglicky: boost). Tato zvy´sˇenı´ (boosting) ovsˇem programa´tor nemu˚zˇe beˇzˇny´mi prostrˇedky ovlivnit ani zjistit. Dodejme, zˇe ke zvysˇova´nı´ priorit docha´zı´ jen u vla´ken dynamicke´m rozsahu (cˇili u vla´ken s prioritou 1–15 mu˚zˇe OS prioritu „tajneˇ“ zvysˇovat azˇ na 15).

56

Vla´kno ma´ ba´zovou a aktua´lnı´ prioritu.

Cˇasova´ kvanta Jizˇ hodneˇ jsme slysˇeli o cˇasovy´ch kvantech slouzˇ´ıcı´ch jako za´kladnı´ jednotka cˇasu prˇideˇlene´ho vla´knu. Vı´me take´, zˇe kvantum zacˇ´ına´ a koncˇ´ı vzˇdy prˇi prˇerusˇenı´ cˇasovacˇe. Syste´m NT vsˇak ve skutecˇnosti pocˇ´ıta´ cˇas kvanta tak, zˇe tento neodpovı´da´ celocˇ´ıselneˇ pocˇtu prˇerusˇenı´ cˇasovacˇe. Kvantum se totizˇ nepocˇ´ıta´ prˇ´ımo dle prˇerusˇenı´ cˇasovacˇe, ale v jaky´chsi abstraktnı´ch cˇasovy´ch jednotka´ch. Cele´ kvantum ma´ velikost 6 jednotek = 2 tiky (workstation) nebo 36 jednotek = 12 tiku˚ (server). (Tik je doba mezi sousednı´mi dveˇma prˇerusˇenı´mi cˇasovacˇe (je to konstanta), cˇasova´ jednotka NT je tedy trˇetinou tiku a kvantum je 6 cˇi 36 jednotek dle verze syste´mu.) Pru˚vodce studiem Workstation a server jsou dveˇ rˇady syste´mu Windows. (Windows XP a Vista patrˇ´ı do rˇady workstation, Windows 2003 a 2008 je server a Windows 2000 ma´ obeˇ verze.) Vy´chozı´ de´lku kvanta lze vsˇak zmeˇnit v syste´move´m registru. Du˚vodem sˇestina´sobneˇ veˇtsˇ´ı de´lky kvanta na serverech je, zˇe se prˇedpokla´da´ vy´skyt procesu˚ cˇi vla´ken, ktere´ beˇhem jednoho kvanta stihnou vykonat svu˚j u´kol a skoncˇit. Tı´m, zˇe se cˇas prˇideˇleny´ vla´knu nekouskuje na mensˇ´ı dı´lky, se zvysˇuje propustnost syste´mu a zkracujı´ se cˇasy odezvy. A to je u serveru jisteˇ prˇ´ıjemne´. Naopak na beˇzˇne´ pracovnı´ stanici (workstation) takto dlouha´ kvanta nejsou zˇa´doucı´.

Kazˇde´ vla´kno si pamatuje „sve´ kvantum“, tj. v jedne´ sve´ promeˇnne´, i kdyzˇ nebeˇzˇ´ı, si pamatuje, kolik cˇasovy´ch jednotek ma´ nebo bude mı´t k dispozici. Jakmile beˇzˇ´ı, tak tato hodnota uby´va´ azˇ k nule a po skoncˇenı´ beˇhu se tato hodnota opeˇt nastavı´ na 6 cˇi 36. Prˇerusˇenı´ cˇasovacˇe odecˇte 3 jednoty z kvanta beˇzˇ´ıcı´ho vla´kna. Jakmile je kvantum vycˇerpa´no, pla´novacˇ vybere dalsˇ´ı vla´kno k beˇhu. Nastane-li prˇerusˇenı´ cˇasovacˇe v okamzˇiku obsluhy jine´ho prˇerusˇenı´, odcˇ´ıta´ se tomu vla´knu, ktere´ beˇzˇelo prˇed prˇerusˇenı´m. (Pozn. Toto nenı´ chyba. Kdyby tomu tak nebylo, kazˇde´ prˇerusˇenı´ teˇsneˇ prˇed tikem hodin by zpu˚sobilo prodlouzˇenı´ rea´lne´ho beˇhu vla´kna. A to by mohlo ohrozit stabilitu syste´mu, nebot’ vla´kno by v nejhorsˇ´ım prˇ´ıpadeˇ mohlo beˇzˇet azˇ nekonecˇneˇ dlouho.) Kdyzˇ vla´kno na neˇco cˇeka´ (naprˇ. vola´nı´m WaitForSingleObject), zmensˇ´ı se po dokoncˇenı´ cˇeka´nı´ pocˇ´ıtadlo kvanta o 1 jednotku. (Opeˇt nutne´ pro stabilitu syste´mu, ze stejne´ho du˚vodu jako v prˇedchozı´m odstavci.) Vla´kno po dokoncˇenı´ cˇeka´nı´ tedy nedosta´va´ cele´ kvantum, ale ma´ jen to, co meˇlo prˇed cˇeka´nı´m −1. Vla´kna s prioritou 14 a vysˇsˇ´ı vsˇak po skoncˇenı´ cˇeka´nı´ dostanou cele´ nove´ kvantum (tj. 6 cˇi 36 jednotek). Samotna´ de´lka tiku hodin za´visı´ na HAL (hardware abstraction layer). A co to vlastneˇ znamena´? HAL je modul stojı´cı´ mimo ja´dro NT a jsou v neˇm implementova´ny procedury za´visle´ na konkre´tnı´m hardwaru. Zatı´mco syste´m NT nenı´ omezen na konkre´tnı´ typ pocˇ´ıtacˇe cˇi procesoru a ma´ vzˇdy stejne´ syste´move´ ja´dro, HAL obsahuje soucˇa´sti na hardwaru za´visle´. A de´lku tiku hodin pra´veˇ urcˇuje HAL, nikoli ja´dro NT. U platformy x86 se uva´dı´ de´lka tiku prˇiblizˇneˇ 10ms na jednoprocesorovy´ch a prˇiblizˇneˇ 15ms na vı´ceprocesorovy´ch pocˇ´ıtacˇ´ıch. V syste´move´m registru Windows lze nastavit: • Zda chceme kra´tka´, cˇi dlouha´ kvanta (6 nebo 36 jednotek). • Zda chceme uprˇednostnit vla´kna procesu na poprˇedı´ (3× delsˇ´ı kvantum), nebo ne. (Toto lze nastavit i v ovla´dacı´m panelu Syste´m – sekce Vy´kon, jako vy´beˇr mezi optimalizacı´ ´ lohy na pozadı´“.) pro „Programy“ nebo „U • O kolik jednotek se ma´ zvy´sˇit priorita vla´kna na poprˇedı´ po dokoncˇenı´ cˇeka´nı´ (mu˚zˇe by´t 0, 1 nebo 2; viz nı´zˇe).

57

Na neserverovy´ch pocˇ´ıtacˇ´ıch ma´ vzˇdy jeden proces delsˇ´ı kvanta. Je to proces, ktere´mu patrˇ´ı okno na poprˇedı´, a ty´ka´ se to vsˇech jeho vla´ken. Okno na poprˇedı´ je to, ktere´ ma´ kla´vesovy´ fokus (tj. kam pra´veˇ jde kla´vesovy´ vstup) – vsˇem vla´knu˚m tohoto procesu je prodlouzˇeno kvantum na trojna´sobek. Ve Windows NT prˇed 4.0 se toto rˇesˇilo zvysˇova´nı´m priority teˇchto vla´ken o 2 body. To vsˇak zpu˚sobovalo, zˇe pla´novacˇ vybı´rat tato vla´kna vzˇdy prˇednostneˇ a pokud program na poprˇedı´ prova´deˇl intenzivnı´ vy´pocˇty, ostatnı´ procesy v syste´mu nedosta´valy CPU ˇ esˇenı´ s prodlouzˇenı´m kvanta zachova´va´ fe´rove´ pla´nova´nı´, kdy se na kazˇde´ho te´meˇrˇ vu˚bec. R dostane, a za´rovenˇ da´va´ vı´c cˇasu procesu na poprˇedı´, cozˇ zlepsˇuje uzˇivatelskou odezvu. 6.2.4

Zvysˇova´nı´ priority

Na zvysˇova´nı´ priority (priority boosting) jsme jizˇ narazili vy´sˇe, nynı´ si jej popisˇme podrobneˇji. Ty´ka´ se jen dynamicky´ch u´rovnı´ (1–15) a vzˇdy platı´: current priority >= base priority, syste´m tedy prioritu jen zvysˇuje a nikdy ji nesnizˇuje pod ba´zovou hodnotu. Syste´m meˇnı´ prioritu vla´kna v teˇchto prˇ´ıpadech: Po dokoncˇenı´ I/O operace. Prˇipomenˇme, zˇe po dokoncˇenı´ kazˇde´ho cˇeka´nı´ se snı´zˇ´ı pocˇ´ıtadlo kvanta o jednicˇku. Podle typu dokoncˇene´ I/O operace se vsˇak take´ docˇasneˇ zvy´sˇ´ı ba´zova´ priorita dane´ho vla´kna. O kolik prˇesneˇ se zvy´sˇ´ı, to si rozhoduje ovladacˇ zarˇ´ızenı´ sa´m, doporucˇeno je: +1 disk, CD-ROM, paralelnı´ port, graficka´ karta +2 sı´t’ova´ karta, pojmenovana´ roura, se´riovy´ port +6 kla´vesnice, mysˇ +8 zvukova´ karta Po uplynutı´ jednoho kvanta se priorita snı´zˇ´ı o 1 stupenˇ, postupneˇ se takto snizˇuje azˇ na pu˚vodnı´ ba´zovou prioritu. Meˇlo by prˇitom platit: Cˇ´ım kratsˇ´ı cˇas ovladacˇ potrˇebuje, tı´m dostane vysˇsˇ´ı prioritu. Navı´c, vla´kna s vysˇsˇ´ı prioritou mohou sta´le prˇerusˇit takto boostovane´ vla´kno, ktere´ prˇed boostova´nı´m meˇlo prioritu nizˇsˇ´ı. Po znovuaktivaci vsˇak toto vla´kno opeˇt pokracˇuje boostovane´, priorita mu klesa´ jen po dokoncˇenı´ cele´ho cˇasove´ho kvanta. Po cˇeka´nı´ na uda´lost nebo semafor. Prˇipomenˇme, zˇe po dokoncˇenı´ cˇeka´nı´ se vla´knu snı´zˇ´ı pocˇ´ıtadlo kvanta o jednicˇku. Ba´zova´ priorita se mu vsˇak na dobu jednoho kvanta zvy´sˇ´ı o jednicˇku. Prˇi neˇktery´ch uda´lostech, naprˇ. uvolneˇnı´ kriticke´ sekce, je aplikova´n jesˇteˇ veˇtsˇ´ı boost: Ma´-li cˇekajı´cı´ vla´kno prioritu 13 nebo nizˇsˇ´ı, dostane prioritu o 1 vysˇsˇ´ı, nezˇ meˇlo vla´kno, ktere´ aktivovalo danou uda´lost. Navı´c ma´-li kvantum mensˇ´ı nezˇ 4 jednotky, zvy´sˇ´ı se mu na 4. (Vla´kno ma´ male´ kvantum, kdyzˇ prˇi poslednı´m beˇhu nebeˇzˇelo po celou de´lku kvanta.) Tento specia´lnı´ „veˇtsˇ´ı“ boost je ukoncˇen po dobeˇhnutı´ kvanta. Kdyzˇ ktere´koliv vla´kno procesu na poprˇedı´ dokoncˇ´ı cˇekacı´ operaci. Aktua´lnı´ priorita se zvy´sˇ´ı +2 na dobu jednoho kvanta. Velikost tohoto zvy´sˇenı´ je jednou z hodnot nastavitelny´ch v syste´move´m registru (+0, +1 nebo +2), Windows Server zde ma´ nastavenu nulu. Kdyzˇ se vla´kno obsluhujı´cı´ GUI probudı´ kvu˚li aktiviteˇ v okneˇ. Toto je tote´zˇ jako v prˇedchozı´m prˇ´ıpadeˇ, ale ty´ka´ se i procesu˚ na pozadı´. Aktivita v okneˇ (GUI aktivita) je, kdyzˇ se neˇco deˇje a prˇijde zpra´va do okna. Vla´kno prˇitom mu˚zˇe by´t na poprˇedı´ a za´rovenˇ cˇekat na GUI, pak je aplikova´n tento i prˇedchozı´ boost soucˇasneˇ (obvykle tedy +4). Kdyzˇ vla´kno v Ready stavu uzˇ dlouho nebeˇzˇelo. Tato situace mu˚zˇe nastat u vla´ken prˇipraveny´ch k beˇhu, avsˇak majı´cı´ch malou prioritu. Kazˇde´ vla´kno, ktere´ nebeˇzˇ´ı 300 tiku˚ (cozˇ jsou 3 azˇ 4 sekundy), dostane prioritu 15 a dvojna´sobne´ kvantum. Po dokoncˇenı´ tohoto 58

dvojkvanta nebo prˇi prˇerusˇenı´ preempcı´ se priorita tomuto vla´knu vracı´ rovnou zpeˇt na pu˚vodnı´ u´rovenˇ. Dlouho nebeˇzˇ´ıcı´ vla´kna se prˇitom kontrolujı´ 1× za sekundu. 6.2.5

Symetricky´ multiprocessing (SMP)

Jak vı´me, syste´m NT je mimo jine´ navrzˇen i pro symetricky´ multiprocessing. V praxi to znamena´, zˇe mu˚zˇete mı´t v pocˇ´ıtacˇi vı´ce procesoru˚ (nebo vı´ceja´drovy´ procesor) a pouzˇ´ıvat stejny´ operacˇnı´ syste´m jako na jednoprocesorove´m pocˇ´ıtacˇi. Pru˚vodce studiem Symetricky´ multiprocessing podporovaly i pomeˇrneˇ da´vne´ verze NT. Beˇzˇneˇ vsˇak byly omezeny na 2 procesory, jinak bylo nutno zakoupit drazˇsˇ´ı verzi. Omezenı´ pocˇtu procesoru˚ u NT prˇitom platı´ dodnes – kdo chce hodneˇ procesoru˚, musı´ si prˇiplatit za „vysˇsˇ´ı“ verzi syste´mu.

Du˚vodem, procˇ se u SMP musı´me zastavit, je, zˇe prˇ´ıtomnost vı´ce procesoru˚ vy´razny´m zpu˚sobem komplikuje pla´nova´nı´ vla´ken. Zatı´mco na jednoprocesorovy´ch pocˇ´ıtacˇ´ıch scheduler/dispatcher vzˇdy jednodusˇe vybı´ra´ k beˇhu vla´kno s nejvysˇsˇ´ı prioritou, na vı´ceprocesorovy´ch by tento jednoduchy´ model nebyl optima´lnı´. Nutno take´ upozornit, zˇe ani skutecˇne´ rˇesˇenı´ pla´novacˇe nenı´ zcela optima´lnı´, protozˇe by to bylo algoritmicky prˇ´ılisˇ slozˇite´ a tı´m by vlastneˇ narostla rezˇie syste´mu natolik, zˇe by vy´sledny´ optima´lnı´ syste´m byl vlastneˇ pomalejsˇ´ı. Vı´ceprocesorove´ pocˇ´ıtacˇe tedy pouzˇ´ıvajı´ specia´lnı´ scheduler/dispatcher, ktery´ je jaky´msi kompromisnı´m rˇesˇenı´m mezi matematicky optima´lnı´m vı´ceprocesorovy´m pla´nova´nı´m a obycˇejny´m jednoprocesorovy´m pla´nova´nı´m. Kazˇdy´ proces ma´ masku afinity (affinity mask) – bitovou masku urcˇujı´cı´ seznam povoleny´ch procesoru˚, na ktery´ch mu˚zˇe beˇzˇet. Kazˇde´ vla´kno ma´ take´ affinity mask (prˇi zalozˇenı´ vla´kna je tato hodnota okopı´rova´na z afinity procesu). Kazˇde´ vla´kno ma´ da´le dva identifika´tory procesoru: idea´lnı´ procesor a minuly´ procesor. Idea´lnı´ procesor je procesor, kde vla´kno „chce“ beˇzˇet. Tato hodnota je nastavena prˇi vzniku vla´kna tak, aby vla´kna byla rovnomeˇrneˇ rozdeˇlena mezi procesory (cˇili cyklicky). Minuly´ procesor je procesor, na ktere´m vla´kno posledneˇ beˇzˇelo. Tato hodnota je sledova´na proto, nebot’mu˚zˇe by´t lepsˇ´ı pla´novat vla´kno opakovaneˇ na stejny´ procesor z du˚vodu lepsˇ´ıho vyuzˇitı´ cache (procesor si mozˇna´ jesˇteˇ pamatuje neˇco z minule´ho beˇhu v cache – dı´ky tomu dosa´hneme vysˇsˇ´ıho celkove´ho vy´konu pocˇ´ıtacˇe). Vy´beˇr procesoru k beˇhu vla´kna Podı´vejme se nynı´ na algoritmus vy´beˇru procesoru k beˇhu vla´kna. Tento algoritmus prˇicha´zı´ ke slovu v okamzˇiku, kdy vla´kno prˇecha´zı´ do stavu ready, tehdy je totizˇ snaha, aby vla´kno okamzˇiteˇ prˇesˇlo do stavu running, cˇi alesponˇ standby (ma´-li dostatecˇneˇ vysokou prioritu, viz take´ kapitolu 6.2.3). Prˇednost ma´ necˇinny´ procesor. Je-li jich vı´c, prˇednost ma´ idea´lnı´ procesor, potom minuly´ procesor, potom aktua´lnı´ procesor (tj. ten, ktery´ prova´dı´ tento ko´d). Pokud jsou necˇinne´ jen ostatnı´ procesory, vybere se ktery´koliv z nich, pouze musı´ odpovı´dat nastavenı´ affinity mask. Na Windows XP a noveˇjsˇ´ıch se zde take´ zohlednˇujı´ hyperthreading a NUMA syste´my. Hyperthreading je technologie dvou logicky´ch procesoru˚ na jednom fyzicke´m, kde ma´me jen jedno plnohodnotne´ ja´dro CPU vykona´vajı´cı´ ko´d, ale na neˇm jsou vytvorˇeny dva logicke´ CPU a prˇepı´na´nı´ mezi nimi je rychlejsˇ´ı. Prˇednost prˇi pla´nova´nı´ dosta´vajı´ ty procesory, kde jsou oba ve dvojici volne´. NUMA (non–uniform memory access) jsou syste´my, kde je nesouroda´ pameˇt’ a jednotlive´ procesory nebo jejich skupiny majı´ sve´ loka´lnı´ pameˇti. V tom prˇ´ıpadeˇ dosta´vajı´ prˇednost ty volne´ procesory, ktere´ jsou ve stejne´ skupineˇ jako procesor idea´lnı´. 59

Maska afinity urcˇuje seznam povoleny´ch procesoru˚ pro vla´kno.

Nenı´-li zˇa´dny´ povoleny´ procesor v masce afinity necˇinny´, syste´m se pokusı´ umı´stit vla´kno preempcı´. Nejprve zkusı´ idea´lnı´ procesor, potom minuly´ procesor. U kazˇde´ho se snazˇ´ı nahradit standby a running vla´kno aktua´lnı´m. Ma´-li standby vla´kno nizˇsˇ´ı prioritu, dojde k preempci. Ma´-li i running vla´kno nizˇsˇ´ı prioritu, dojde k preempci. Z uvedene´ho plyne, zˇe pokud idea´lnı´ ani minuly´ procesor nemajı´ beˇzˇ´ıcı´ vla´kno s nizˇsˇ´ı prioritou, aktua´lnı´ vla´kno nenı´ umı´steˇno nikam a jde do cˇekacı´ fronty. Zde tedy mu˚zˇe nastat situace, zˇe vla´kno s vysokou prioritou cˇeka´ na procesor, zatı´mco na jine´m procesoru beˇzˇ´ı jine´ vla´kno s nizˇsˇ´ı prioritou. Pru˚vodce studiem Prˇipomenˇme, zˇe cela´ tato masˇine´rie se ty´ka´ prˇ´ıpadu, kdy ma´me vla´kno a hleda´me pro neˇj procesor, cozˇ je aktua´lnı´ obvykle u vla´ken s vysˇsˇ´ı prioritou. Vla´kno, ktere´ nema´ beˇzˇet, nepotrˇebuje ani prˇideˇlovat procesor. Vybrany´ procesor ma´ pouze vla´kno aktua´lneˇ beˇzˇ´ıcı´ (tj. ve stavu running) a vla´kno vybrane´ pro prˇ´ısˇtı´ beˇh (tj. ve stavu standby) – v obou prˇ´ıpadech je to pra´veˇ jedno vla´kno. Nejprve je snaha umı´stit vla´kno na neˇjaky´ volny´ procesor dle pravidel popsany´ch vy´sˇe. Pokud se to nepodarˇ´ı, kontrolujı´ se priority vla´ken ve stavech standby a running (a to pouze na procesorech popsany´ch vy´sˇe). Je-li nalezeno vla´kno s nizˇsˇ´ı prioritou ve stavu standby cˇi running, docha´zı´ k preempci. (Cˇili nove´ vla´kno je umı´steˇno namı´sto dosavadnı´ho vla´kna s nizˇsˇ´ı prioritou.) Cˇasteˇjsˇ´ı situaci, kdy vybı´ra´me vla´kno k beˇhu na uvolneˇne´m procesoru, popisuje na´sledujı´cı´ sekce. Vy´beˇr vla´kna pro procesor Nynı´ se zameˇrˇme na situaci, kdy je procesor uvolneˇn a hleda´ se dalsˇ´ı vla´kno k beˇhu. Tato situace nasta´va´, kdyzˇ skoncˇ´ı cˇasove´ kvantum, vla´kno samo odevzda´ procesor zpeˇt syste´mu, zmeˇnı´ se priorita vla´kna atp. Vybı´ra´ se pak nove´ vla´kno pro tento konkre´tnı´ procesor a nehledı´ se na to, co se pra´veˇ deˇje na procesorech ostatnı´ch. Dalsˇ´ı vla´kno je vybı´ra´no z fronty cˇekajı´cı´ch vla´ken s nejvysˇsˇ´ı prioritou. (Je 32 cˇekacı´ch front, pro kazˇde´ cˇ´ıslo aktua´lnı´ priority jedna. Zde pracujeme s jednou z nich – tou, ktera´ odpovı´da´ vla´knu cˇi vla´knu˚m s nynı´ nejvysˇsˇ´ı aktua´lnı´ prioritou.) Vybra´no je prvnı´ z nich, ktere´ ma´ procesor oznacˇen jako minuly´ cˇi idea´lnı´, je ve stavu ready de´le nezˇ 3 tiky hodin nebo ma´ prioritu 24 cˇi vysˇsˇ´ı. Nenı´-li zˇa´dny´ takovy´ kandida´t, vezme se prvnı´ vla´kno z te´to fronty. Prˇitom se ignorujı´ vla´kna, u ktery´ch nevyhovuje maska afinity. Jak je videˇt z popisu algoritmu vy´beˇru, na multiprocesorech NT nezajisˇt’uje, zˇe pobeˇzˇ´ı vla´kno s nejvysˇsˇ´ı prioritou. (Maska afinity ma´ prˇednost prˇed prioritou.) Pru˚vodce studiem Beˇzˇ´ı-li tento algoritmus na jednoprocesorove´m pocˇ´ıtacˇi, chova´ se prˇesneˇ stejneˇ jako drˇ´ıve popsany´ pla´novacı´ algoritmus NT. Prostudova´nı´m teˇchto odstavcu˚ tedy mozˇna´ i le´pe pochopı´te pla´nova´nı´ v jednoprocesorove´m syste´mu NT (zejme´na neˇktere´ netrivia´lnı´ detaily).

Windows Server 2003 a noveˇjsˇ´ı Syste´my Windows Server 2003 a noveˇjsˇ´ı majı´ samostatnou frontu cˇekajı´cı´ch vla´ken pro kazˇdy´ procesor. Zrychluje to pla´nova´nı´, nebot’na drˇ´ıveˇjsˇ´ıch syste´mech nemu˚zˇe pla´novacı´ algoritmus beˇzˇet soucˇasneˇ na vı´ce procesorech a prˇi soubeˇhu pla´nova´nı´ tak musı´ neˇktere´ procesory cˇekat. (Jelikozˇ pla´nova´nı´ je cˇasova´no cˇasovacˇem, prˇi prˇerusˇenı´ cˇasovacˇe se beˇzˇneˇ pla´nuje vı´c nezˇ jeden 60

CPU. Proto cˇ´ım vı´ce je v pocˇ´ıtacˇi CPU, tı´m vı´c tam vadı´ stary´ pla´novacı´ algoritmus. Celkove´ cˇasy stra´vene´ necˇinny´m cˇeka´nı´m sice nejsou velke´, ale jizˇ prˇi 3 CPU docha´zı´ u starsˇ´ıch verzı´ NT vzˇdy ke kolizi prˇi pla´nova´nı´. Pla´nuje se totizˇ 1 CPU prˇi kazˇde´m druhe´m prˇerusˇenı´, takzˇe 3 CPU uzˇ urcˇiteˇ udeˇlajı´ kolizi.) Ma´-li WS2003 pra´zdnou frontu u dane´ho procesoru, spustı´ na neˇm idle vla´kno a to pak prohleda´va´ fronty cˇekajı´cı´ch vla´ken na jiny´ch procesorech a najde-li vhodne´, vezme si jej. Na NUMA syste´mech prˇitom da´va´ prˇednost procesoru˚m ve stejne´ skupineˇ.

6.3

Vla´kna v Linuxu

Na za´veˇr kapitoly se jesˇteˇ strucˇneˇ zastavme u vla´ken syste´mu Linux. Tento syste´m se navenek tva´rˇ´ı jako Unix, nebot’podporuje standardnı´ rozhranı´ (API) POSIX. Interneˇ syste´m podporuje vla´kna a vsˇechny je zverˇejnˇuje jako samostatne´ procesy. Tento prˇ´ıstup je tedy na prvnı´ pohled dosti odlisˇny´ od syste´mu NT, avsˇak prakticke´ chova´nı´ a vlastnosti obou syste´mu˚ jsou co do vla´ken stejne´. (Oba syste´my jsou z tohoto hlediska rovnocenne´.) Vla´kno v Linuxu vytvorˇ´ıme prˇ´ıkazem clone, ktery´ je zobecneˇnı´m prˇ´ıkazu fork. Zatı´mco fork klonuje cely´ proces se vsˇ´ım vsˇudy, u clone mu˚zˇeme nastavit, ktere´ kontexty chceme klonovat, cˇi sdı´let s rodicˇovsky´m procesem. Clone navı´c spousˇtı´ novy´ proces na libovolne´ funkci (zatı´mco v prˇ´ıpadeˇ forku oba procesy pokracˇujı´ na stejne´m mı´steˇ ko´du). Funkce sys clone je kompromisem – chova´ se jako clone, ovsˇem oba procesy pokracˇujı´ ve vykona´va´nı´ ko´du jako v prˇ´ıpadeˇ forku. Kontexty, ktere´ lze v nove´m procesu bud’ naklonovat, nebo nechat sdı´let s rodicˇovsky´m procesem, jsou prˇedevsˇ´ım: • Odkaz na rodicˇovsky´ proces. Sdı´lı´me-li jej, oba procesy majı´ stejne´ho rodicˇe, klonujemeli, volajı´cı´ proces je rodicˇem nove´ho. • Otevrˇene´ soubory. Prˇi sdı´lenı´ majı´ procesy stejnou tabulku otevrˇeny´ch souboru˚. Prˇi klonova´nı´ dostane novy´ proces kopii tabulky v okamzˇiku vytvorˇenı´, takzˇe sice take´ dostane prˇ´ıstup ke vsˇem otevrˇeny´m souboru˚m, ale jen skrze kopii. • Jmenny´ prostor souborove´ho syste´mu. Nastavenı´ tohoto kontextu je vyhrazeno pro procesy s vysˇsˇ´ım opra´vneˇnı´m; kazˇdy´ jmenny´ prostor v Linuxu urcˇuje hierarchii prˇipojeny´ch svazku˚ souborove´ho syste´mu a obvykle nenı´ du˚vod na tom u jednotlivy´ch procesu˚ neˇco meˇnit. • Tabulka signa´lu˚. • Adresovy´ prostor. Jeho sdı´lenı´ je za´kladnı´m prˇedpokladem, abychom mohli procesu rˇ´ıkat vla´kno. Noveˇ vytva´rˇeny´ proces mu˚zˇeme take´ vytvorˇit pozastaveny´. (Chova´ se stejneˇ jako posla´nı´ signa´lu SIGSTOP; pozastaveny´ proces zacˇne (opeˇt) beˇzˇet po signa´lu SIGCONT.) Mu˚zˇeme take´ nastavit pozastavenı´ volajı´cı´ho procesu azˇ do ukoncˇenı´ volane´ho (cozˇ se chova´ stejneˇ jako funkce exec). Flexibilita Linuxu jde tak daleko, zˇe vla´kna ve smyslu, jak je cha´peme my, mohou v syste´mu figurovat bud’ jako plnohodnotne´ procesy se samostatny´mi cˇ´ısly (PID), ktere´ majı´ nastavenou sdı´lenou pameˇt’(prˇ´ıpadneˇ i dalsˇ´ı soucˇa´sti), nebo skutecˇneˇ jako vla´kna, vystupujı´cı´ ve skupina´ch pod stejny´m cˇ´ıslem procesu (PID). (Acˇkoliv vla´kno je interneˇ vzˇdy na u´rovni procesu, funkce operujı´cı´ s identifika´tory mohou vracet za´stupny´ identifika´tor skupiny vla´ken (TGID).) Tyto jemne´ nuance nemusı´me prˇ´ılisˇ podrobneˇ zkoumat, mohou se vsˇak hodit naprˇ. pro dosazˇenı´ 100% kompatibility s jiny´mi operacˇnı´mi syste´my (pro software vyvinuty´ pu˚vodneˇ pro jiny´ syste´m a beˇzˇ´ıcı´ nynı´ na Linuxu). U Linuxu se neˇkdy uva´dı´, zˇe kromeˇ syste´move´ podpory vla´ken lze vla´kna pouzˇ´ıvat take´ na u´rovni knihovny. Zjisˇteˇnı´ podrobnostı´ nemusı´ by´t zrovna snadne´, nebot’literatura se te´to problematice obvykle neveˇnuje s dostatecˇnou prˇesnostı´. Ve skutecˇnosti se vla´kna v Linuxu nejcˇasteˇji 61

pouzˇ´ıvajı´ jako v Unixu, tedy prˇes syste´move´ rozhranı´ POSIX s vla´knovou knihovnou Pthreads. Tato knihovna ve vy´chozı´m provedenı´ implementuje vla´kna na uzˇivatelske´ u´rovni, prˇepı´na´nı´ je tedy rychlejsˇ´ı, nezˇ u vla´ken v ja´drˇe syste´mu, ale negativa tohoto rˇesˇenı´ vy´razneˇ prˇevla´dajı´. Syste´mova´ vla´kna tak, jak byla popsa´na vy´sˇe, nejsou kompatibilnı´ s Pthreads a navı´c majı´ ve veˇtsˇineˇ distribucı´ Linuxu rˇadu skryty´ch nedostatku˚ (naprˇ. existence rˇ´ıdicı´ho vla´kna va´zane´ho na jeden fyzicky´ procesor, prˇes ktere´ jde rˇ´ızenı´ vla´ken v procesu a take´ vsˇechny synchronizacˇnı´ operace), ktere´ rovneˇzˇ snizˇujı´ vy´kon (stejneˇ jako uzˇivatelska´ vla´kna v knihovneˇ). Pouze neˇktere´ nejnoveˇjsˇ´ı distribuce Linuxu implementujı´ Pthreads pomocı´ syste´movy´ch vla´ken; dostupne´ zdroje tuto variantu uva´deˇjı´ jako jednoznacˇneˇ lepsˇ´ı z hlediska vy´konu. (Pro podrobnosti k tomuto tvrzenı´ viz dokumentaci k nejnoveˇjsˇ´ımu ja´dru syste´mu Linux 2.6 [Lov03].) Shrnutı´ V te´to kapitole jsme probrali spra´vu procesoru v operacˇnı´ch syste´mech Unix, Windows NT a Linux. Teoreticke´ pojmy zavedene´ v kapitole prˇedchozı´ jsme tedy zasadili do kontextu skutecˇny´ch operacˇnı´ch syste´mu˚. Prvnı´ cˇa´st kapitoly byla veˇnova´na problematice vytvorˇenı´, pla´nova´nı´ a stavu˚ procesu v syste´mu Unix. V dalsˇ´ı cˇa´sti jsme se veˇnovali stejne´ problematice v syste´mu Windows NT a bylo uka´za´no, zˇe specia´lneˇ u vla´ken se rˇada veˇcı´ se v teˇchto dvou syste´mech vza´jemneˇ lisˇ´ı. Za´veˇr kapitoly byl pak veˇnova´n problematice vla´ken v Linuxu, ktery´ k veˇci prˇistupuje jesˇteˇ dalsˇ´ım jiny´m zpu˚sobem. Zatı´mco v NT jsou vla´kna za´kladem cele´ho syste´mu spra´vy procesoru, v syste´mech Unix a Linux je za´kladnı´m prvkem proces, zatı´mco vla´kna byla prˇida´na azˇ do pozdeˇjsˇ´ıch verzı´. Pojmy k zapamatova´nı´ • trˇ´ıda priorit • sheduler/dispatcher • (cˇasove´) kvantum • HAL (hardware abstraction layer) • zvysˇova´nı´ priority (priority boosting) • idea´lnı´ procesor • minuly´ procesor • maska afinity (affinity mask) • prˇ´ıkazy exec, fork, clone, sys clone • prˇ´ıkazy CreateProcess, CreateThread Kontrolnı´ ota´zky 1. Popisˇte principia´lnı´ rozdı´l mezi cha´pa´nı´m vla´ken v syste´mech Unix a NT. 2. Popisˇte, jak swapova´nı´ ovlivnˇuje stavy procesu˚ v Unixu. 3. Popisˇte postup vytvorˇenı´ nove´ho procesu v Unixu. 4. Vyjmenujte situace, prˇi ktery´ch vla´kno v Unixu opustı´ stav Running. 5. Jak se vytva´rˇ´ı novy´ proces v NT? 6. Jak a kdy mu˚zˇe nastavenı´ afinity pomoci zrychlit vı´cevla´knovy´ program? 7. Co deˇla´ „zero page thread“, jakou ma´ prioritu a procˇ? 8. Jak se lisˇ´ı pla´nova´nı´ procesoru na desktopove´ a serverove´ verzi Windows? Jake´ majı´ tyto rozdı´ly smysl cˇi cı´l? 9. Vyjmenujte situace, prˇi ktery´ch se zvysˇuje priorita vla´kna v NT. U kazˇde´ situace popisˇte, procˇ je v nı´ zvy´sˇenı´ priority vy´hodne´ cˇi prˇ´ınosne´. 10. Procˇ je pla´nova´nı´ vla´ken u vı´ceprocesorovy´ch pocˇ´ıtacˇu˚ komplikovaneˇjsˇ´ı, nezˇ u jednoprocesorovy´ch? Uved’te, co je zdrojem proble´mu˚. 11. Vysveˇtlete algoritmus vy´beˇru procesoru pro vla´kno v NT. 12. Vysveˇtlete algoritmus vy´beˇru vla´kna pro beˇh na procesoru v NT. 13. Popisˇte situaci vla´ken v Linuxu. Jak jsou do syste´mu zanesena a jake´ to ma´ du˚sledky? 62

7

Synchronizace vla´ken a procesu˚

Studijnı´ cı´le: Tato kapitola je pokracˇova´nı´m bloku o procesech a vla´knech. Tentokra´t se sezna´mı´me se synchronizacˇnı´mi objekty operacˇnı´ho syste´mu, ktere´ slouzˇ´ı k synchronizaci vla´ken a procesu˚. Kromeˇ synchronizace se zmı´nı´me take´ o komunikaci mezi vla´kny a procesy, cozˇ je prˇ´ıbuzne´ te´ma. U prakticky´ch cˇa´stı´ se opeˇt budeme veˇnovat prˇedevsˇ´ım syste´mu Windows NT. Klı´cˇova´ slova: synchronizace vla´ken, synchronizace procesu˚, semafor, mutex, kriticka´ sekce Potrˇebny´ cˇas: 120 minut.

7.1 7.1.1

Principy synchronizace ´ vod U

Samostatne´ (neza´visle´) procesy spolu obvykle komunikujı´ pomocı´ zası´la´nı´ zpra´v. Tento model je obecneˇ pouzˇitelny´ jak pro procesy beˇzˇ´ıcı´ na jednom pocˇ´ıtacˇi, tak v prostrˇedı´ pocˇ´ıtacˇove´ sı´teˇ. Problematika komunikace zası´la´nı´m zpra´v je vsˇak mimo oblast studia operacˇnı´ch syste´mu˚ (alesponˇ pro na´s).

Procesy komunikujı´ zası´la´nı´m zpra´v.

Vla´kna jednoho procesu mohou mezi sebou rovneˇzˇ komunikovat zası´la´nı´m zpra´v, tento druh mezivla´knove´ komunikace se vsˇak v praxi te´meˇrˇ nevyskytuje. Dı´ky sdı´lene´ pameˇti totizˇ ma´me mnohem zajı´maveˇjsˇ´ı mozˇnosti, jak vla´kna nechat komunikovat cˇi prˇ´ımo spolupracovat. Dı´ky sdı´lene´ pameˇti cˇasto stacˇ´ı mı´sto neˇjake´ formy komunikace pouzˇ´ıt sdı´lena´ data (naprˇ. ve formeˇ globa´lnı´ promeˇnne´, mu˚zˇe ale jı´t i o ne–globa´lnı´ data, pokud o nich vsˇechna zainteresovana´ vla´kna veˇdı´). Pra´ce se sdı´lenou pameˇtı´ vsˇak prˇina´sˇ´ı jednu velkou starost navı´c: Jelikozˇ vla´kna spolu sdı´lejı´ vesˇkerou operacˇnı´ pameˇt’, mohou ji libovolneˇ cˇ´ıst i zapisovat. Jednotliva´ vla´kna prˇitom neveˇdı´, co deˇlajı´ ta ostatnı´, a to mu˚zˇe mı´t na datech katastrofa´lnı´ na´sledky. Nejcˇasteˇjsˇ´ı proble´my prˇi sdı´lenı´ pameˇti mu˚zˇeme neforma´lneˇ popsat takto: Zatı´mco jedno vla´kno zapisuje novou hodnotu, jina´ vla´kna mohou pracovat se starou hodnotou a pozdeˇji take´ chtı´t zapsat svou novou hodnotu. Tı´m se ztratı´ hodnota prvneˇ zapsana´. Druhy´m typicky´m prˇ´ıpadem je pra´ce se slozˇiteˇjsˇ´ımi daty, ktera´ patrˇ´ı k sobeˇ. Jakmile jedno vla´kno zacˇne aktualizovat (zapisovat novou hodnotu), deˇla´ to postupneˇ, cˇili zapisuje jednotlive´ promeˇnne´, ktere´ tvorˇ´ı veˇtsˇ´ı celek. Ostatnı´ vla´kna v ten okamzˇik ale mohou cˇ´ıst hodnoty a zı´skajı´ tı´m cˇa´stecˇneˇ nove´ a cˇa´stecˇneˇ stare´ hodnoty, tedy jako celek neplatne´. Tyto proble´my mohou mı´t za na´sledek chybny´ vy´pocˇet programu, nebo dokonce jeho zhroucenı´ cˇi uva´znutı´ v mrtve´m bodeˇ. Za´kladnı´m na´strojem pro spolehlive´ fungova´nı´ vı´cevla´knovy´ch programu˚ je mezivla´knova´ (cˇi meziprocesnı´) synchronizace. Synchronizaci realizujeme pomocı´ tzv. synchronizacˇnı´ch primitiv (za´kladnı´ch prvku˚), ktere´ poskytuje operacˇnı´ syste´m. Mezi za´kladnı´ patrˇ´ı jmenoviteˇ naprˇ. uda´lost, semafor, mutex cˇi kriticka´ sekce. Pru˚vodce studiem Ota´zka toho, ktere´ synchronizacˇnı´ primitivum je skutecˇneˇ „za´kladnı´ “, je cˇisteˇ veˇcı´ prˇ´ıstupu. Mu˚zˇeme se dohodnout, zˇe naprˇ. semafor budeme povazˇovat za nejza´kladneˇjsˇ´ı prvek synchronizace, nebot’ se s nı´m dobrˇe pracuje a ostatnı´ primitiva pomocı´ neˇj lze naimplementovat take´. Jeho fyzicka´ implementace v syste´mu je vsˇak o neˇco slozˇiteˇjsˇ´ı nezˇ trˇeba u uda´losti. Uda´lost tedy mu˚zˇeme povazˇovat za za´kladnı´ primitivum pra´veˇ proto, zˇe jde o velmi jednoduchy´ prvek a jeho realizace je mozˇna´ jen s neˇkolika ma´lo instrukcemi procesoru. U objektoveˇ orientovany´ch syste´mu˚ je pak za za´kladnı´ synchronizacˇnı´ primitivum obvykle povazˇova´n jedineˇ monitor.

63

Vla´kna mezi sebou musı´me synchronizovat.

Realizace synchronizacˇnı´ch primitiv je veˇtsˇinou mozˇna´ jen spolupracı´ syste´mu a hardwaru a samotne´ uzˇivatelske´ programy by ji samy realizovat nedoka´zaly. Fakt, ktere´ primitivum je interneˇ v syste´mu realizova´no pomocı´ ktere´ho, nenı´ pro uzˇivatele–programa´tora vu˚bec du˚lezˇity´. Podstatny´ je jen vy´znam a funkcˇnost primitiv, ten je (nebo by alesponˇ meˇl by´t) u vsˇech operacˇnı´ch syste´mu˚ stejny´ (azˇ na drobne´ nuance). 7.1.2

Atomicke´ operace

Spolecˇny´m rysem synchronizacˇnı´ch primitiv je, zˇe majı´ schopnost prove´st neprˇerusˇitelneˇ vı´ce jednoduchy´ch operacı´ v rˇadeˇ. Operace, ktera´ sice mu˚zˇe by´t slozˇena z vı´ce dı´lcˇ´ıch kroku˚, ale je neprˇerusˇitelna´, se nazy´va´ atomicka´. Bez ohledu na pocˇet procesoru˚ a vla´ken, atomicka´ operace vzˇdy probeˇhne cela´ v jeden okamzˇik bez mozˇnosti kolize s jiny´m vla´knem. Tuto vlastnost (atomicitu) si uka´zˇeme na neˇkolika prˇ´ıkladech chyb, ktere´ mohou nastat prˇi soubeˇhu dvou vla´ken. Prvnı´ prˇ´ıklad: Pra´ce se za´sobnı´kem Jak vı´me, za´sobnı´k je jednoducha´ dynamicka´ datova´ struktura, do ktere´ mu˚zˇeme ukla´dat data (operace push) a potom je opeˇt vyzvednout (operace pop), prˇicˇemzˇ platı´ princip LIFO „co jde poslednı´ dovnitrˇ, to jde prvnı´ ven“. Prˇedstavme si za´sobnı´k implementovany´ pomocı´ pole, cˇili stejneˇ jako syste´movy´ programovy´ za´sobnı´k v pocˇ´ıtacˇi, a podı´vejme se na operaci push. Prˇida´nı´ prvku na za´sobnı´k provedeme ve dvou jednoduchy´ch krocı´ch: 1. Posuneme ukazatel vrcholu o jednu bunˇku nı´zˇe. 2. Zapı´sˇeme na pozici vrcholu nova´ data. Tento popis plneˇ odpovı´da´ jak zmı´neˇne´mu programove´mu za´sobnı´ku v pocˇ´ıtacˇi, tak jake´mukoliv za´sobnı´ku implementovane´mu jednoduchy´m polem. Prˇi soubeˇhu dvou vla´ken, tedy prˇi soucˇasne´ pra´ci dvou vla´ken s jednı´m za´sobnı´kem, mu˚zˇe nastat situace, kdy se obeˇ vla´kna snazˇ´ı soucˇasneˇ vlozˇit novy´ prvek na za´sobnı´k. V te´to situaci tedy kazˇde´ z vla´ken provede oba vy´sˇe uvedene´ kroky, prˇicˇemzˇ chyba nastane kdykoliv, kdy neˇktere´ vla´kno neprovede oba sve´ kroky dohromady, ale vlozˇ´ı se mezi neˇ vla´kno druhe´. Oznacˇ´ıme-li si vla´kna A a B, pak prˇi porˇadı´ AABB nebo BBAA k chybeˇ nedojde, ale prˇi porˇadı´ ABBA, ABAB, BAAB nebo BABA dojde k chybeˇ – vy´sledny´ stav za´sobnı´ku nebude spra´vny´, protozˇe polozˇka pod vrcholem bude mı´t na´hodnou hodnotu a hodnota, ktera´ tam meˇla by´t ulozˇena vla´knem, bude bud’ ztracena, nebo bude nespra´vneˇ ulozˇena na vrcholu (a polozˇka patrˇ´ıcı´ na vrchol bude ztracena). Korektnı´m rˇesˇenı´m operace push je provedenı´ obou dı´lcˇ´ıch kroku˚ atomicky. Tj. zarucˇ´ıme, zˇe mezi prvnı´ a druhy´ dı´lcˇ´ı krok se nedostane jine´ vla´kno prova´deˇjı´cı´ take´ operaci push na stejne´m za´sobnı´ku. (Tento postula´t vsˇak nevylucˇuje dalsˇ´ı korektnı´ rˇesˇenı´ dane´ho proble´mu.) Druhy´ prˇ´ıklad: Inkrementace promeˇnne´ Jako druhy´ prˇ´ıklad si uved’me jednoduchou operaci inkrementace promeˇnne´ (cˇili zvy´sˇit hodnotu o jedna). Tato operace je provedena pomocı´ jedine´ instrukce procesoru, takzˇe by se mohlo zda´t, zˇe automaticky atomickou operaci a nenı´ trˇeba ji da´le diskutovat. Opak je vsˇak pravdou. Skutecˇneˇ, prˇi soubeˇhu vla´ken mu˚zˇe inkrementace zpu˚sobit chybu na vı´ceprocesorovy´ch pocˇ´ıtacˇ´ıch. Zatı´mco procesor nelze prˇerusˇit uprostrˇed vykona´va´nı´ jednotlive´ instrukce, beˇzˇ´ı-li soucˇasneˇ vı´ce procesoru˚ tak mohou pracovat s pameˇtı´ libovolneˇ a nejde o prˇerusˇenı´. Konkre´tneˇ inkrementace promeˇnne´ je operace slozˇena´ ze trˇ´ı kroku˚: 1. Procesor prˇecˇte promeˇnnou.

64

Atomicka´ operace je neprˇerusˇitelna´.

2. Procesor inkrementuje hodnotu. 3. Procesor zapı´sˇe hodnotu. Acˇkoliv na prvnı´ pohled mu˚zˇe vypadat podivneˇ, procˇ je tak jednoducha´ operace rozdeˇlena do trˇ´ı kroku˚, prˇi drobne´m zamysˇlenı´ by meˇlo by´t jasne´, zˇe operacˇnı´ pameˇt’podporuje jen operace cˇti a zapisˇ a k inkrementaci hodnoty musı´me nutneˇ zna´t hodnotu inkrementovane´ promeˇnne´. Tento prˇ´ıklad na´m tedy uka´zal, zˇe na vı´ceprocesorovy´ch syste´mech mohou „nefungovat“ i ty programy, ktere´ na jednoprocesorovy´ch fungovaly bezvadneˇ. (A to doslova – tento typ chyby skutecˇneˇ na jednoprocesorove´m pocˇ´ıtacˇi nemu˚zˇe nastat, nelze jej tedy ani vysledovat a odladit.) 7.1.3

Hardwarove´ atomicke´ operace

Na jednoprocesorovy´ch syste´mech dosa´hneme atomicke´ operace tak, zˇe po dobu vykona´va´nı´ kriticke´ho ko´du zaka´zˇeme prˇerusˇenı´. Tento postup je jednoduchy´, spolehlivy´ a funkcˇnı´ v za´sadeˇ na vsˇech procesorech, ktere´ nemusejı´ pracovat v rea´lne´m cˇase. Je prˇitom samozrˇejmeˇ cˇisteˇ na ˇ ada operacˇnı´ch syste´mu˚ vsˇak nasˇ´ı libovu˚li, jak velkou cˇa´st ko´du provedeme takto „atomicky“. R nedovoluje, aby za´kazy prˇerusˇenı´ prova´deˇly prˇ´ımo uzˇivatelske´ procesy, nebot’ se zaka´zany´m ˇ esˇenı´ je zde jesˇteˇ prˇerusˇenı´m je zablokova´n take´ scheduler a nemu˚zˇe probı´hat prˇepı´na´nı´ vla´ken. R pomeˇrneˇ snadne´ – operacˇnı´ syste´m obsahuje sadu za´kladnı´ch atomicky´ch operacı´, takzˇe ko´d za´kazu prˇerusˇenı´ je pouze v ja´dru syste´mu a uzˇivatelske´ procesy prˇerusˇenı´ zaka´zat nemohou. Potrˇebuje-li proces vykonat delsˇ´ı kus ko´du atomicky, musı´ vhodny´m zpu˚sobem pouzˇ´ıt atomicke´ operace syste´mu (cozˇ si prˇedstavı´me pozdeˇji – viz povı´da´nı´ o semaforech, mutextech atp.). Pru˚vodce studiem V neˇktery´ch zdrojı´ch se mu˚zˇeme setkat s informacı´, zˇe pro zajisˇteˇnı´ atomicity stacˇ´ı, aby v dany´ okamzˇik dane´ vla´kno meˇlo nejvysˇsˇ´ı prioritu. Tento postup vsˇak nenı´ bezpecˇny´, nebot’ i vla´kno s nejvysˇsˇ´ı prioritou mu˚zˇe by´t prˇerusˇeno. (S odkazem na popis pla´novacˇe u´loh v kapitole 5.) U vı´ceprocesorovy´ch syste´mu˚ je situace jesˇteˇ slozˇiteˇjsˇ´ı. Za´kaz prˇerusˇenı´ totizˇ ovlivnˇuje jen chova´nı´ jednoho procesoru, navı´c jednotlive´ procesory mohou do pameˇti prˇistupovat tak, zˇe cizı´ procesor se dostane k pameˇti i beˇhem prova´deˇnı´ jedine´ jednoduche´ instrukce (viz prˇ´ıklad inkrementace hodnoty na zacˇa´tku te´to kapitoly – jedna´ se o skoro nejjednodusˇsˇ´ı instrukci, a prˇesto nenı´ atomicka´). Procesory navrzˇene´ pro vı´ceprocesorove´ syste´my obvykle poskytujı´ neˇjake´ specia´lnı´ atomicke´ instrukce, za´kladnı´ teoreticke´ modely si nynı´ prˇedstavı´me. Test–and–set V literaturˇe je nejcˇasteˇji prezentova´n model test–and–set (TAS – otestuj a nastav). Je-li operace TAS implementova´na jako atomicka´ instrukce procesoru, mu˚zˇe by´t za´kladem mezivla´knove´ synchronizace.

Test–and–set je za´kladnı´ model atomicka´ operace.

Instrukce typu TAS atomicky testuje hodnotu v pameˇti a nastavı´ ji na novou hodnotu. Po provedenı´ te´to instrukce ma´me k dispozici pu˚vodnı´ hodnotu z pameˇti a v pameˇti je nova´ hodnota. TAS mu˚zˇe by´t implementova´no nejen samotny´m procesorem, ale take´ jiny´m hardwarovy´m obvodem, typicky trˇeba vı´ceportovy´m pameˇt’ovy´m modulem (ten umozˇnˇuje vı´ce prˇ´ıstupu˚ soucˇasneˇ a pro synchronizaci podporuje operaci TAS). Compare–and–swap Acˇkoliv teoreticka´ literatura lpı´ na modelu TAS, v praxi se velmi rozsˇ´ırˇil take´ model compare– and–swap (CAS – porovnej a vymeˇnˇ). Je veˇdecky doka´za´no, zˇe tento model je nadrˇazeny´ modelu TAS (existujı´ u´lohy, ktere´ pomocı´ CAS lze rˇesˇit efektivneˇji) [Her91]. 65

Compare–and– swap je v praxi nejcˇasteˇji pouzˇ´ıvany´ model atomicke´ operace.

Instrukce typu CAS porovna´ hodnotu v pameˇti s jinou hodnotou a pokud jsou si rovny, hodnotu v pameˇti vymeˇnı´ s jinou (trˇetı´) hodnotou. K dispozici pak ma´me vy´sledek testu rovnosti a v prˇ´ıpadeˇ rovnosti take´ pu˚vodnı´ hodnotu z pameˇti. Tote´zˇ lze popsat i jiny´mi slovy: Instrukce typu CAS ma´ trˇi operandy a je atomicka´. Nejprve porovna´ prvnı´ s druhy´m. Jsou-li rovny, okopı´ruje trˇetı´ do druhe´ho a vracı´ true. Nejsou-li rovny, okopı´ruje druhy´ do prvnı´ho a vracı´ false. Na procesorech x86 je CAS implementova´no instrukcemi CMPXCHG a CMPXCHG64B (32bitova´ a 64bitova´ verze). Na vı´ceprocesorovy´ch syste´mech prˇida´va´me jesˇteˇ prefix LOCK, ktery´ blokuje prˇ´ıstup na sbeˇrnici ostatnı´m procesoru˚m. Fetch–and–add Dalsˇ´ı beˇzˇnou atomickou operacı´ je fetch–and–add, ktera´ atomicky prˇecˇte hodnotu promeˇnne´ a prˇicˇte k nı´ jinou hodnotu. Vracı´ prˇitom pu˚vodnı´ hodnotu. Na procesorech x86 je toto implementova´no instrukcı´ XADD, opeˇt v kombinaci s LOCK u vı´ceprocesorovy´ch syste´mu˚. Dodejme jesˇteˇ, zˇe operace fetch–and–add je rovneˇzˇ funkcˇneˇ podrˇ´ızena´ CAS, stejneˇ jako TAS. 7.1.4

Softwarova´ implementace atomicity

Jako prˇ´ıklad cˇisteˇ softwarove´ho rˇesˇenı´ atomicity uved’me Petersonu˚v algoritmus [Pet81]. Jde o rˇesˇenı´ pro dveˇ vla´kna, ovsˇem je mozˇno jej zobecnit i na vı´ce vla´ken. [Hof90] Pru˚vodce studiem Ota´zky synchronizace se zacˇaly rˇesˇit jizˇ v 50.letech 20.stoletı´. Zatı´mco dnes ma´ kazˇdy´ beˇzˇny´ procesor neˇkolik chytry´ch atomicky´ch instrukcı´, pomocı´ nichzˇ lze synchronizaci snadno zvla´dnout, tehdejsˇ´ı hardware samozrˇejmeˇ u´rovneˇ dnesˇnı´ch mikroprocesoru˚ nedosahoval. Jednı´m z elegantnı´ch softwarovy´ch rˇesˇenı´ je pra´veˇ tento Petersonu˚v algoritmus, ktery´ se ale objevil azˇ v roce 1981. Neˇktere´ zdroje uva´deˇjı´ i starsˇ´ı algoritmy, jako naprˇ. Dekkeru˚v z roku 1965, je vsˇak ota´zkou, nakolik byly tyto algoritmy vsˇeobecneˇ zna´my v dobeˇ sve´ho vzniku. ko´d 1. procesu:

ko´d 2. procesu:

lockA = t r u e ; t u r n = B; w h i l e ( l o c k B && t u r n ! =A) { } ... lockA = f a l s e ;

lockB = t r u e ; t u r n = A; w h i l e ( lockA && t u r n ! =B ) { } ... lockB = f a l s e ;

V mı´steˇ trˇi tecˇek doplnı´me libovolny´ ko´d, ktery´ ma´ by´t atomicky´. (Nenı´ podstatne´, zda se tento ko´d u jednotlivy´ch vla´ken lisˇ´ı, nebo je stejny´.) Tento ko´d ve skutecˇnosti nenı´ opravdu atomicky´, nebot’algoritmus jen zajisˇt’uje, zˇe jakmile se zacˇne vykona´vat ko´d na mı´steˇ trˇ´ı tecˇek v jednom procesu, pak nebude prˇerusˇen ko´dem na mı´steˇ trˇ´ı tecˇek ve druhe´m procesu. Jedna´ se tedy o mı´rneˇjsˇ´ı podmı´nku nezˇ u atomicity a rˇ´ıka´me ji vza´jemne´ vyloucˇenı´. Jiny´mi slovy lze rˇ´ıci, zˇe Petersonu˚v algoritmus rˇesˇ´ı atomicitu jen pro specia´lnı´ prˇ´ıpad, kdy jsou v syste´mu jen dva procesy. Nelze jej tedy pouzˇ´ıt pro vı´ce procesu˚ cˇi pro vla´kna sdı´lejı´cı´ tenty´zˇ ko´d; takove´ zobecneˇnı´ by bylo mozˇne´, avsˇak znacˇneˇ slozˇite´ a z prakticke´ho hlediska nezajı´mave´. Proto se zobecnˇova´nı´m za´kladnı´ho algoritmu zaby´vat nebudeme. V na´sledujı´cı´ch sekcı´ch si neˇktera´ za´kladnı´ synchronizacˇnı´ primitiva prˇedstavı´me podrobneˇji. Vsˇechna se chovajı´ jako objekty – je to tedy vzˇdy neˇjaka´ datova´ struktura obsahujı´cı´ neˇkolik operacı´, ktere´ s nı´ lze deˇlat. Tyto operace jsou obvykle atomicke´ a jsou tı´m hlavnı´m, co na´s bude zajı´mat. Naopak informace o tom, jaka´ data jsou vlastneˇ skryta uvnitrˇ jednotlivy´ch synchronizacˇnı´ch objektu˚, pro na´s vu˚bec podstatna´ (ani zajı´mava´) nenı´. 66

7.1.5

Semafor

Semafor je chra´neˇna´ promeˇnna´ a je za´kladnı´m na´strojem pro rˇ´ızenı´ (a omezenı´) prˇ´ıstupu ke sdı´leny´m prostrˇedku˚m.

Semafor rˇ´ıdı´ prˇ´ıstup k prostrˇedku.

Pru˚vodce studiem Prˇedchozı´ veˇta prakticky zcela popisuje semafor. Co jsme se tedy doveˇdeˇli: Semafor je chra´neˇna´ promeˇnna´, tj. prˇedstavuje promeˇnnou, ke ktere´ je chra´neˇny´ prˇ´ıstup pomocı´ neˇkolika operacı´ semaforu (ktere´ si prˇedstavı´me nı´zˇe). Promeˇnna´ je chra´neˇna´, tzn. pomocı´ operacı´, ktere´ jsou k dispozici, je zajisˇteˇno, zˇe jejı´ stav je vzˇdy korektnı´. Da´le jsme se doveˇdeˇli, zˇe semafor slouzˇ´ı k rˇ´ızenı´ prˇ´ıstupu ke sdı´leny´m prostrˇedku˚m. Hodı´ se tedy vsˇude tam, kde ma´me neˇjake´ prostrˇedky, ktere´ lze sdı´let, ale jejich mnozˇstvı´ je omezeno (cˇasto na pouhy´ jeden prˇ´ıstup, ale mu˚zˇe by´t povoleno i vı´ce prˇ´ıstupu˚ soucˇasneˇ).

Uvnitrˇ semaforu je skryta celocˇ´ıselna´ promeˇnna´, rˇ´ıka´me ji hodnota semaforu, nebo jednodusˇe pocˇ´ıtadlo. Tato hodnota je inicializova´na na pocˇet prostrˇedku˚, ktere´ jsou na zacˇa´tku k dispozici. Potom ma´me k dispozici dveˇ atomicke´ operace, nazy´va´me je P a V. Operace P cˇeka´, nezˇ je k dispozici asponˇ jeden prostrˇedek (pocˇ´ıtadlo > 0). Potom snı´zˇ´ı hodnotu pocˇ´ıtadla o jednicˇku. Operace V oznamuje vra´cenı´ prostrˇedku, cˇili zvy´sˇ´ı hodnotu pocˇ´ıtadla o jednicˇku. V praxi tedy docha´zı´ k tomu, zˇe v operaci P se vla´kno prˇi nedostatku prostrˇedku˚ hlı´dany´ch semaforem zastavı´ a cˇeka´, azˇ bude prostrˇedek k dispozici. Dı´ky tomu, zˇe tato operace je atomicka´ (a cˇeka´nı´ je pasivnı´), jedna´ se o efektivnı´ zpu˚sob rˇ´ızenı´ prˇ´ıstupu ke sdı´leny´m prostrˇedku˚m. A v neposlednı´ rˇadeˇ take´ jednodusˇe pouzˇitelny´. Dodejme jesˇteˇ, zˇe operaci P mu˚zˇe vykonat i jine´ vla´kno nezˇ operaci V. Je tedy mozˇne´, a v praxi se to skutecˇneˇ cˇasto pouzˇ´ıva´(!), zˇe jedno vla´kno vykona´va´ operaci P, cˇ´ımzˇ zı´ska´ prostrˇedek, ale zcela jine´ vla´kno vykona´va´ operaci V, cˇ´ımzˇ prostrˇedek uvolnˇuje. Jedna´ se pak vlastneˇ o jake´si vytva´rˇenı´ prostrˇedku˚ jednı´m vla´knem a jejich konzumaci jiny´m. Pru˚vodce studiem Nicnerˇ´ıkajı´cı´ P a V jsou vsˇeobecneˇ prˇijate´ standardnı´ na´zvy atomicky´ch operacı´ semaforu, se ktery´mi se pracuje v teoreticke´ literaturˇe. V jednotlivy´ch operacˇnı´ch syste´mech jim obvykle odpovı´dajı´ jinak (lidsky) pojmenovane´ funkce, naprˇ. down cˇi wait pro P a up cˇi signal pro V. Prˇ´ıklad programova´nı´ se semaforem si uka´zˇeme pozdeˇji. Neˇktere´ implementace mohou poskytovat navı´c i dalsˇ´ı operace, typicka´ je naprˇ´ıklad mozˇnost zjistit hodnotu vnitrˇnı´ho pocˇ´ıtadla.

7.1.6

Mutex a kriticka´ sekce

Mutex a kriticka´ sekce jsou dva u´zce souvisejı´cı´ pojmy. Mutex je zkratkou z anglicke´ho „mutual exclusion“ (vza´jemne´ vyloucˇenı´) a kriticka´ sekce je na´strojem k jeho dosazˇenı´. Synchronizacˇnı´ objekty mutexu a kriticke´ sekce jsou de facto totozˇne´, jedna´ se o synonyma. V praxi se vsˇak neˇkdy vyskytujı´ i jako dva ne zcela stejne´ prvky. (Rozdı´l mezi nimi ve Windows si popı´sˇeme nı´zˇe v samostatne´ sekci.) Smyslem vza´jemne´ho vyloucˇenı´ je, zˇe pouze jedno vla´kno v dane´ chvı´li vykona´va´ chra´neˇny´ ko´d. Mutex je tedy obdobou semaforu, jenzˇe tentokra´t nejde o chra´neˇnou promeˇnnou, ny´brzˇ cˇa´st ko´du. 67

Mutex chra´nı´ cˇa´st ko´du prˇed soubeˇhem.

Pru˚vodce studiem Uzˇ z u´vodnı´ho popisu mutexu je zrˇejme´, zˇe pomocı´ semaforu lze implementovat mutex a obra´ceneˇ. Zˇe vsˇechny synchronizacˇnı´ objekty jsou nahraditelne´, jsme si ostatneˇ „prozradili“ uzˇ v u´vodu kapitoly.

Mutex je obvykle implementova´n hardwaroveˇ, existujı´ vsˇak i softwarova´ rˇesˇenı´. Zatı´mco semafor je obvykle nakonec implementova´n pomocı´ mutexu, pro mutex majı´ modernı´ procesory specia´lnı´ instrukci. Je totizˇ zjevne´, zˇe umı´me-li prove´st cˇa´st ko´du s vyloucˇenı´m beˇhu ostatnı´ vla´ken, jde o atomickou operaci, cˇ´ımzˇ ma´me vyrˇesˇen proble´m semaforu. Samotne´ vza´jemne´ vyloucˇenı´ se implementuje hardwaroveˇ pomocı´ instrukcı´ prova´deˇjı´cı´ operace typu „test–and– set“ nebo „compare–and-swap“. Mutex ma´ dveˇ atomicke´ operace: Vstoupit do kriticke´ sekce, opustit kritickou sekci. (Na rozdı´l od semaforu se zde nepouzˇ´ıvajı´ zˇa´dne´ jednopı´smenne´ na´zvy). Jedna kriticka´ sekce mu˚zˇe mı´t v ko´du i vı´ce vstupu˚ a vy´stupu˚. Znamena´ to pak, zˇe vsˇechny oznacˇene´ cˇa´sti ko´du patrˇ´ı do spolecˇne´ sekce a platı´ pro neˇ vza´jemne´ vyloucˇenı´. Na zacˇa´tku kriticke´ sekce kazˇde´ prˇ´ıchozı´ vla´kno musı´ vykonat operaci vstupu. V tom okamzˇiku syste´m testuje, zda v kriticke´ sekci uzˇ neˇjake´ jine´ vla´kno nenı´. Pokud je volno, vla´kno ma´ povolen vstup, v opacˇne´m prˇ´ıpadeˇ je uspa´no a cˇeka´ na uvolneˇnı´ sekce. Na rozdı´l od semaforu zde neexistuje pocˇ´ıtadlo umozˇnˇujı´cı´ vı´ce nezˇ jeden prˇ´ıstup v dany´ cˇas. (Bylo-li by vı´ce prˇ´ıstupu˚ soucˇasneˇ, nebylo by to uzˇ „mutually exclusive“.) Vla´kno, ktere´ jizˇ je v kriticke´ sekci, vsˇak mu˚zˇe znovu projı´t prˇes vstup do sekce a tento probeˇhne okamzˇiteˇ. Vla´kno tedy mu˚zˇe libovolneˇ kra´t vstoupit do te´zˇe sekce. Na konci musı´ vla´kno opustit kritickou sekci tolikra´t, kolikra´t do nı´ vstoupilo. Opustit sekci musı´ vzˇdy prˇesneˇ to vla´kno, ktere´ do ni vstoupilo, ne neˇjake´ jine´. (Zde vidı´me za´sadnı´ rozdı´l oproti semaforu.) Pru˚vodce studiem Prˇedchozı´ odstavec popisuje velmi du˚lezˇitou vlastnost mutexu: Vla´kno mu˚zˇe opakovaneˇ vstoupit do kriticke´ sekce. Pozˇadova´no pouze je, aby pocˇet vstupu˚ a opusˇteˇnı´ kriticke´ sekce byl stejny´ a aby vsˇe probeˇhlo ve stejne´m vla´kneˇ.

7.1.7

Uda´lost a signa´l

Uda´lost a signa´l jsou opeˇt dva termı´ny pro tote´zˇ. Vyskytujı´ se v programova´nı´ pocˇ´ıtacˇu˚ v mnoha podoba´ch; my se nynı´ zameˇrˇ´ıme specia´lneˇ na signa´ly souvisejı´cı´ se synchronizacı´ vla´ken a procesu˚. V Unixu (a Linuxu) jsou signa´ly za´kladnı´m na´strojem meziprocesnı´ komunikace. Dı´ky dominantnı´mu postavenı´ jazyka C se s touto formou signa´lu˚ setka´me i v ostatnı´ch syste´mech, i kdyzˇ jejich vy´znam tam jizˇ nemusı´ by´t tak velky´ jako v Unixu. V teoreticke´ rovineˇ odpovı´dajı´ uda´losti softwarovy´m prˇerusˇenı´m a signa´ly jejich handleru˚m. Operacˇnı´ syste´m tedy definuje sadu (neˇkolika ma´lo desı´tek) uda´lostı´, ktere´ mohou nastat, a jednotlive´ procesy mohou teˇmto uda´lostem prˇirˇadit obsluzˇne´ funkce (handleru). V okamzˇiku, kdy nastane dana´ uda´lost, syste´m „vysˇle signa´l“ neboli zavola´ handler – toto probeˇhne stejny´m zpu˚sobem, jak jsme si popsali u fyzicky´ch prˇerusˇenı´ v kapitole 3.3. Pokud proces signa´lu neprˇirˇadı´ zˇa´dny´ handler, je vola´n vy´chozı´ handler. U neˇktery´ch signa´lu˚ je toto samozrˇejmeˇ zˇa´doucı´ (naprˇ. signa´l vy´padku pameˇt’ove´ stra´nky – viz kap. 9 na straneˇ 84). Ve Windows najdeme pod pojmem uda´lost zcela jiny´ synchronizacˇnı´ prvek. Jak si podrobneˇji popı´sˇeme da´le v samostatne´ sekci, Windows umozˇnˇuje procesu˚m vytva´rˇet vlastnı´ uda´losti 68

a pouzˇ´ıvat je k synchronizaci. Nejsme tedy omezeni na neˇkolik pevneˇ dany´ch uda´lostı´, ale vytvorˇ´ıme si libovolneˇ vlastnı´. Naproti tomu tyto uda´losti nejsou nava´za´ny na chova´nı´ syste´mu, signa´ly tedy musı´me posı´lat sami. Dalsˇ´ım rozdı´lem je, zˇe Windows nepouzˇ´ıva´ pro aplikacˇnı´ programy prˇerusˇenı´, takzˇe nelze jednodusˇe nastavit funkci, ktera´ se ma´ zavolat prˇi vy´skytu uda´losti. Acˇkoliv to mu˚zˇe pu˚sobit jako neprˇ´ıjemne´ omezenı´, pomocı´ uda´lostı´ jsou ve Windows implementova´ny ostatnı´ synchronizacˇnı´ objekty (vcˇetneˇ semaforu a mutexu). 7.1.8

Monitor

Monitor je synchronizacˇnı´ prvek, ktery´ se prˇ´ımo v Unixu cˇi Windows NT neobjevuje. Najdeme jej vsˇak v modernı´ch objektoveˇ orientovany´ch syste´mech, jmenoviteˇ platformy Java a .NET jej deklarujı´ jako svu˚j za´kladnı´ synchronizacˇnı´ prvek. Monitory vyuzˇ´ıvajı´ objektoveˇ orientovany´ princip, dı´ky cˇemuzˇ je programova´nı´ s nimi pomeˇrneˇ snadne´. Slozˇiteˇjsˇ´ı vsˇak mu˚zˇe by´t pochopit jejich princip. Popis monitoru˚ se v ru˚zny´ch publikacı´ch lisˇ´ı, pra´veˇ podle toho, nakolik se autorˇi snazˇili o poda´nı´ popisu prˇesneˇ, nebo naopak srozumitelneˇ. My si monitory popı´sˇeme z hlediska platformy .NET. Prˇipomenˇme, zˇe cı´lem cˇi u´kolem monitoru je zajistit, aby prˇi soubeˇhu vla´ken nedocha´zelo k chyba´m, jejichzˇ prˇ´ıklady byly uvedeny na zacˇa´tku te´to kapitoly. Jelikozˇ pracujeme objektoveˇ, ochranu dat mu˚zˇeme zajistit tak, zˇe zarucˇ´ıme, zˇe s dany´m objektem pracuje v jeden okamzˇik jen jedno vla´kno. Jak vı´me, s daty objektu mohou pracovat jen metody tohoto objektu. Za´kladnı´ synchronizaci tedy lze prove´st tak, zˇe uzavrˇeme ko´d vsˇech metod do jedne´ kriticke´ sekce. Monitor tento princip realizuje a jesˇteˇ rozsˇirˇuje. Objektoveˇ orientovany´ syste´m automaticky poskytuje monitor ke kazˇde´mu objektu. Vyuzˇijeme-li jej, ma´me k dispozici za´mek, ktery´m lze snadno zamykat prˇ´ıstup k objektu. Cele´ metody cˇi cˇa´sti ko´du, ktere´ meˇnı´ stav dat v objektu, ktere´ chceme hlı´dat, oznacˇ´ıme k zamknutı´. Jedna´ se tedy o syntakticky jednodusˇsˇ´ı variantu kriticke´ sekce, nebot’se nemusı´me starat o vytvorˇenı´ a zrusˇenı´ kriticke´ sekce a vstup a vy´stup je prˇipojen prˇ´ımo k objektu (pomocı´ odkazu sa´m na sebe (this) – kazˇdy´ objekt ma´ prˇece svu˚j monitor). Vy´hodou monitoru tedy take´ je, zˇe teˇzˇko udeˇla´me chybu – neuva´dı´me nikde odkazy na kritickou sekci, se kterou pracujeme, pouzˇ´ıva´me jen odkazy typu this. Zatı´m jsme tedy popsali, jak monitor nahrazuje kritickou sekci s tı´m, zˇe ma´ jednodusˇsˇ´ı za´pis a mensˇ´ı riziko lidske´ chyby. Monitor ma´ vsˇak i dalsˇ´ı du˚lezˇitou schopnost, kterou jizˇ kritickou sekci prˇevysˇuje. Opustit za´mek monitoru totizˇ lze nejen opusˇteˇnı´m monitoru (na konci hlı´dane´ cˇa´sti ko´du), ale take´ cˇeka´nı´m na uda´lost sprˇazˇenou s monitorem. Dı´ky te´to atomicke´ dvojoperaci lze atomicky uvolnit za´mek monitoru a za´rovenˇ zacˇ´ıt cˇekat na uda´lost. Signa´l o uda´losti prˇitom posˇle jine´ vla´kno v tomte´zˇ monitoru. Pro prˇ´ıklad pouzˇitı´ tohoto konstruktu uved’me rˇesˇenı´ proble´mu dodavatel–odbeˇratel, ktery´ jsme si prˇedstavili v cˇa´sti popisujı´cı´ semafory: Jedno vla´kno vytva´rˇ´ı produkt a druhe´ na neˇj cˇeka´. Toto se mu˚zˇe (ale nemusı´) opakovat. Vla´kno– konzument vstoupı´ do monitoru a cˇeka´ na uda´lost. Vla´kno–producent vstoupı´ do monitoru a signalizuje uda´lost. Dı´ky monitoru mu˚zˇe existovat i neˇkolik producentu˚ a konzumentu˚ a syste´m vzˇdy spolehliveˇ funguje (produkt se dostane vzˇdy k pra´veˇ jednomu konzumentovi). Pomocı´ monitoru˚ lze rˇesˇit vsˇechny klasicke´ synchronizacˇnı´ proble´my. Na za´veˇr dodejme, zˇe neˇktere´ klasicke´ ucˇebnice paralelnı´ho programova´nı´ pouzˇ´ıvajı´ pro vy´uku synchronizace konstrukty mutex a condition variable (tzv. podmı´neˇna´ promeˇnna´), jejichzˇ kombinacı´ lze azˇ na slozˇiteˇjsˇ´ı syntaxi rˇesˇit paralelnı´ u´lohy velmi podobny´m zpu˚sobem jako s monitory. Pru˚vodce studiem Hovorˇ´ıme-li o paralelnı´ch „u´loha´ch“, je to nena´padny´ odkaz na to, zˇe proble´my synchronizace spolupracujı´cı´ch vla´ken, se ktery´mi se v praxi cˇloveˇk mu˚zˇe setkat, lze veˇtsˇinou prˇeve´st na neˇkterou z neˇkolika ma´lo klasicky´ch paralelnı´ch u´loh. Diskuze algoritmu˚ pro rˇesˇenı´ teˇchto u´loh je nad ra´mec kurzu Operacˇnı´ syste´my, implementace zna´my´ch algoritmu˚

69

Monitor je prvek objektoveˇ orientovane´ synchronizace.

pomocı´ prˇ´ıkazu˚ operacˇnı´ho syste´mu je vsˇak jednı´m z te´mat, se ktery´mi se studenti setkajı´ ve cvicˇenı´.

7.2

Synchronizace v NT

Podı´vejme se nynı´ blı´zˇe na synchronizacˇnı´ primitiva, ktera´ nabı´zı´ Windows NT. Hovorˇ´ıme o tzv. „objektech“, protozˇe jde neˇkolik skupin funkcı´ pracujı´cı´ s identifika´torem prˇ´ıslusˇne´ entity – jde tedy de facto o objekty. V syste´mu NT jsou vsˇechny synchronizacˇnı´ objekty odvozeny od spolecˇne´ho za´kladu – jde o objekty, na ktere´ lze cˇekat (cˇekatelny´ objekt – waitable object). Jelikozˇ syste´m nenı´ nativneˇ explicitneˇ objektovy´, neˇktere´ syste´move´ funkce jsou platne´ pro ru˚zne´ typy synchronizacˇnı´ch objektu˚. Z objektoveˇ orientovane´ho hlediska to odpovı´da´ situaci, kdy kazˇdy´ jednotlivy´ synchronizacˇnı´ objekt, ktery´ mu˚zˇeme pouzˇ´ıvat, deˇdı´ z abstraktnı´ho ba´zove´ho typu „waitable object/class“. 7.2.1

Uda´lost

Jak uzˇ bylo zmı´neˇno v prˇedchozı´ sekci, za´kladnı´m (a nejjednodusˇsˇ´ım) synchronizacˇnı´m objektem v NT je uda´lost. Uda´lost je objekt, na ktery´ lze cˇekat. Cˇekajı´cı´ vla´kno neprova´dı´ zˇa´dny´ jiny´ ko´d. Cˇeka´nı´ koncˇ´ı bud’ neu´speˇsˇneˇ po urcˇite´m cˇase (timeout), nebo v okamzˇiku, kdy jine´ vla´kno signalizuje uda´lost. Prˇi pra´ci s uda´lostı´ ma´me k dispozici neˇkolik nastavenı´, ktery´mi mu˚zˇeme jejı´ chova´nı´ ovlivnit. Funkcı´ CreateEvent mu˚zˇeme vytvorˇit uda´lost bud’ typu „auto reset“, nebo „manual reset“. Da´le zde urcˇ´ıme vy´chozı´ stav uda´losti (signalizova´na/nesignalizova´na). Uda´lost lze prˇi vytva´rˇenı´ pojmenovat, pak ji lze sdı´let mezi procesy. Uvedeme-li jme´no, musı´ toto by´t jednoznacˇne´ v ra´mci cele´ho syste´mu (jedne´ uzˇivatelske´ session), podle ktere´ho ho lze najı´t a otevrˇ´ıt v jine´m procesu vola´nı´m OpenEvent. Obvyklejsˇ´ı je vsˇak pouzˇitı´ nepojmenovany´ch uda´lostı´, ty lze sdı´let jen mezi vla´kny jednoho procesu. Vytvorˇenı´m uda´losti zı´ska´me jejı´ identifika´tor (tzv. „handle“). Po skoncˇenı´ pra´ce s uda´lostı´ zrusˇ´ıme handle vola´nı´m CloseHandle. Uda´lost zanikne po zrusˇenı´ poslednı´ho handlu (nepojmenovana´ nejpozdeˇji prˇi skoncˇenı´ procesu). Vla´kno mu˚zˇe na uda´lost cˇekat kteroukoliv cˇekacı´ funkcı´, naprˇ. WaitForSingleObject (cˇeka´ na jeden objekt) nebo WaitForMultipleObjects (cˇeka´ na vı´ce objektu˚, nebo jeden z mnoha). Uda´lost musı´me signalizovat jiny´m vla´knem pomocı´ funkce SetEvent. Uda´lost typu manual reset je pak signalizova´na tak dlouho, nezˇ neˇkdo zavola´ ResetEvent. Prˇitom jsou probuzena vsˇechna cˇekajı´cı´ vla´kna. Uda´lost typu auto reset je signalizova´na jen do doby, nezˇ probudı´ jedno vla´kno. Cˇeka´-li vı´ce vla´ken, jedno z nich (nelze rˇ´ıci, ktere´) je probuzeno. 7.2.2

Semafor

Semafory v NT fungujı´ tak, jak byly popsa´ny v sekci 7.1.5. Novy´ semafor vytvorˇ´ıme funkcı´ CreateSemaphore, uvedeme prˇitom celkovy´ pocˇet hlı´dany´ch prostrˇedku˚ a vy´chozı´ pocˇet volny´ch. Mu˚zˇeme take´ semafor pojmenovat, vy´znam pojmenova´nı´ je stejny´ jako u uda´losti (otevrˇeme jej vola´nı´m OpenSemaphore). Zrusˇenı´ semaforu je stejne´ jako u uda´losti. Zı´ska´nı´ prostrˇedku semaforu provedeme pomocı´ ktere´koliv cˇekacı´ funkce (stejneˇ jako u uda´losti). Cˇeka´me-li na vı´ce semaforu˚, pocˇ´ıtadlo se snizˇuje u kazˇde´ho. Cˇeka´me-li vı´cekra´t na tenty´zˇ, pocˇ´ıtadlo se snı´zˇ´ı jen jedenkra´t. Pro uvolneˇnı´ prostrˇedku pak vola´me ReleaseSemaphore; tato funkce take´ umozˇnˇuje zjistit stav vnitrˇnı´ho pocˇ´ıtadla semaforu.

70

7.2.3

Mutex

Mutexy v NT fungujı´ tak, jak byly popsa´ny v sekci 7.1.6. Novy´ mutex vytvorˇ´ıme funkcı´ CreateMutex, lze take´ nastavit, zda do neˇj vytva´rˇejı´cı´ vla´kno ma´ prˇ´ımo vstoupit. Pojmenova´nı´ a zrusˇenı´ mutexu funguje stejneˇ jako u uda´losti a semaforu. Vstup do mutexu prova´dı´me opeˇt pomocı´ ktere´koliv cˇekacı´ funkce. Uvolneˇnı´ mutexu provedeme vola´nı´m ReleaseMutex. Skoncˇ´ı-li vla´kno bez uvolneˇnı´ mutexu, je tento ve stavu „abandoned“. Jine´ vla´kno pak mu˚zˇe mutex zı´skat standardnı´m zpu˚sobem, cˇekacı´ funkce ale vracı´ prˇ´ıznak chyby abandoned. S mutexem lze da´le pracovat a po dalsˇ´ım uvolneˇnı´ mutexu tento ztra´cı´ prˇ´ıznak chyby. (Mutex s tı´mto prˇ´ıznakem vsˇak znacˇ´ı, zˇe neˇkde v ko´du dosˇlo k chybeˇ a chra´neˇna´ data nemusejı´ by´t v konzistentnı´m stavu.) 7.2.4

Kriticka´ sekce

Kriticka´ sekce je v NT zvla´sˇtnı´m druhem mutexu. Kriticke´ sekce majı´ vlastnı´ sadu funkcı´ a nelze je pojmenovat, cˇili je nelze sdı´let mezi procesy. Jsou tedy rychlejsˇ´ı nezˇ mutexy, ale nelze je kombinovat s jiny´mi objekty, protozˇe nepouzˇ´ıvajı´ ani standardnı´ cˇekacı´ funkce. Jinak se nelisˇ´ı od popisu v sekci 7.1.6. Kritickou sekci vytvorˇ´ıme vola´nı´m InitializeCriticalSection, vstoupı´me do nı´ vola´nı´m EnterCriticalSection nebo TryEnterCriticalSection a opustı´me ji vola´nı´m LeaveCriticalSection. Objekt kriticke´ sekce zrusˇ´ıme vola´nı´m DeleteCriticalSection. Zˇa´dna´ z teˇchto funkcı´ nema´ nastavitelne´ parametry (kromeˇ adresy objektu kriticke´ sekce). Pru˚vodce studiem Pokud mu˚zˇete, dejte ve vasˇich NT programech kriticke´ sekci prˇednost prˇed mutexem.

7.2.5

Cˇekacı´ funkce

V prˇedchozı´ch odstavcı´ch jsme neˇkolikra´t narazili na tzv. cˇekacı´ funkce, ktere´ jsou platne´ pro kazˇdy´ cˇekatelny´ objekt (waitable object). Kromeˇ WaitForSingleObject a WaitForMultipleObjects, ktere´ jsme jizˇ zmı´nili vy´sˇe. Pomocı´ teˇchto funkcı´ lze cˇekat na jeden objekt, jeden z mnoha nebo vı´ce objektu˚. Lze cˇekat nekonecˇneˇ dlouho, nebo po zvolenou maxima´lnı´ dobu (do timeoutu). Dalsˇ´ı sada cˇekacı´ch funkcı´ umozˇnˇuje cˇekat kombinovaneˇ na cˇekatelne´ objekty, uda´losti posı´lane´ do oken, uda´losti dokoncˇenı´ I/O operace a asynchronnı´ vola´nı´ procedur. Podrobnosti lze nale´zt v [MSDN]. Alternativou ke kombinovane´mu cˇeka´nı´ mu˚zˇe by´t take´ pouzˇitı´ vı´ce vla´ken, kde kazˇde´ bude cˇekat na neˇco jine´ho. Du˚lezˇitou funkcı´ je take´ SignalObjectAndWait, ktera´ atomicky signalizuje jeden objekt a cˇeka´ na jiny´. Pouzˇitı´ te´to funkce je de facto ekvivalentnı´ s tı´m, kdyzˇ v monitoru cˇeka´me na sprˇazˇeny´ signa´l. Signalizovat lze semafor, mutex nebo uda´lost; cˇekat lze na celou rˇadu cˇekatelny´ch objektu˚. Pru˚vodce studiem Prˇi synchronizaci vla´ken ve Windows NT se SignalObjectAndWait pouzˇ´ıva´ velmi cˇasto, protozˇe je to jedina´ funkce, ktera´ umı´ atomicky uvolnit objekt a cˇekat an jiny´. Dosa´hnout stejne´ho efektu pouze bez te´to funkce je pomeˇrneˇ slozˇite´ (i kdyzˇ mozˇne´). Zajı´mave´ prˇitom je, zˇe tato funkce je k dispozici azˇ od Windows 2000.

71

Cˇekacı´ funkce cˇeka´ na cˇekatelny´ objekt.

7.2.6

Dalsˇ´ı synchronizacˇnı´ a komunikacˇnı´ na´stroje

Dalsˇ´ım synchronizacˇnı´m objektem je cˇekatelny´ cˇasovacˇ (waitable timer). Je to jeden z mnoha druhu˚ cˇasovacˇu˚ v NT, ktery´ je specificky´ tı´m, zˇe na uplynutı´ meˇrˇene´ho u´seku cˇasu lze cˇekat pomocı´ cˇekacı´ch funkcı´. Jelikozˇ NT ma´ i jine´ druhy cˇasovacˇu˚, tento se v praxi pouzˇ´ıva´ jen vy´jimecˇneˇ, kdyzˇ se na´m hodı´ kombinovat jej s jiny´mi cˇekatelny´mi objekty. Cˇekatelny´ cˇasovacˇ lze take´ napojit na APC (asynchronnı´ vola´nı´ procedury), cozˇ je rovneˇzˇ pomeˇrneˇ ma´lo pouzˇ´ıvana´ funkcionalita NT. Dalsˇ´ım prvkem pouzˇitelny´m prˇi pra´ci s vla´kny a procesy je mapova´nı´ souboru do pameˇti. Namapujeme-li tenty´zˇ soubor do pameˇti ve vı´ce procesech, pak majı´ de facto sdı´lenou pameˇt’. Toto je take´ jediny´ zpu˚sob, jak ve Windows sdı´let operacˇnı´ pameˇt’mezi procesy. Mapovane´mu souboru lze take´ nastavit souborove´ prˇ´ıznaky tak, zˇe ani neexistuje nikde na disku a je jen v pameˇti. Sdı´lenou pameˇt’ pak lze bohateˇ vyuzˇ´ıt ke komunikaci prˇi spolupra´ci procesu˚, pro synchronizaci pra´ce s nı´ pak pouzˇijeme neˇktery´ synchronizacˇnı´ objekt (naprˇ. mutex nebo semafor). Poslednı´m prvkem, ktery´ zmı´nı´me, jsou roury (pipe). Jde opeˇt o prvek urcˇeny´ spı´sˇe ke komunikaci. Roura opeˇt u´zce souvisı´ se soubory, jedna´ se o datovy´ kana´l, ktery´ mu˚zˇe by´t jednosmeˇrny´ nebo obousmeˇrny´. Vzˇdy ma´ dva konce, z nichzˇ kazˇdy´ mu˚zˇe by´t nasmeˇrova´n do libovolne´ho procesu, ale i do souboru na disku, prˇes sı´t’atp. S rourou se pracuje stejneˇ jako se souborem na disku, tj. data mu˚zˇeme cˇ´ıst a zapisovat. Rouru vytvorˇ´ıme pomocı´ CreatePipe nebo CreateNamedPipe. Pojmenovane´ roury majı´ jesˇteˇ celou rˇadu dalsˇ´ıch funkcı´ a lze jimi propojit i vzda´lene´ pocˇ´ıtacˇe. Literatura uva´dı´, zˇe pojmenovane´ roury jsou za´kladnı´m komunikacˇnı´m prostrˇedkem ve Windows NT, pouzˇity´m pro vesˇkerou meziprocesnı´ loka´lnı´ i vzda´lenou komunikaci (s tı´m du˚sledkem, zˇe zˇa´dny´ jiny´ komunikacˇnı´ prostrˇedek nemu˚zˇe by´t rychlejsˇ´ı nezˇ pojmenovane´ roury).

7.3

Futex

V za´veˇru kapitoly se jesˇteˇ kra´tce zastavme u Linuxu. V aktua´lnı´ch verzı´ch tohoto syste´mu se jako za´kladnı´ primitivum pouzˇ´ıva´ futex (toto je i na´zev prˇ´ıslusˇne´ syste´move´ funkce, je to zkratka z Fast Userspace Mutex), cozˇ je specia´lnı´ nı´zkou´rovnˇovy´ prvek beˇzˇ´ıcı´ prˇeva´zˇneˇ v user mo´du (tj. neprˇepı´na´ se do ja´dra). Do rezˇimu ja´dra se prˇepı´na´ jen prˇi nutnosti rˇesˇit kolize mezi procesory a pra´veˇ proto je velmi rychly´. Futex obsahuje pocˇ´ıtadlo a lze jej vyuzˇ´ıt k efektivnı´ implementaci semaforu i mutexu dle standardu POSIX. Prˇ´ıme´ pouzˇitı´ futexu programa´torem obvykle nenı´ nutne´, pro podrobnosti viz stejnojmenna´ funkce. Shrnutı´ Synchronizace je jednı´m z nezbytny´ch pomocnı´ku˚ prˇi pra´ci s vla´kny cˇi obecneˇ se sdı´lenou pameˇtı´ nebo jiny´mi sdı´leny´mi prostrˇedky. Za´kladnı´m na´strojem k synchronizaci je schopnost prova´deˇt neˇkolik po sobeˇ jdoucı´ch operacı´ atomicky, kterou obvykle nabı´zı´ prˇ´ımo procesor a jeho hardwarova´ platforma. Na za´kladeˇ jeho atomicky´ch instrukcı´ jsou v operacˇnı´ch syste´mech vybudova´ny synchronizacˇnı´ primitiva cˇi objekty na vysˇsˇ´ı u´rovni abstrakce, ktera´ jsou pak nabı´zena uzˇivatelsky´m procesu˚m. My jsme si popsali a naucˇili se pouzˇ´ıvat prˇedevsˇ´ım atomicke´ operace test–and–set a compare–and–swap a synchronizacˇnı´ objekty semafor, mutex, kriticka´ sekce, uda´lost a signa´l. Da´le jsme probrali take´ objektoveˇ orientovany´ synchronizacˇnı´ prvek monitor a zmı´nili jsme take´ neˇkolik dalsˇ´ıch synchronizacˇnı´ch a komunikacˇnı´ch pomocnı´ku˚, ktere´ poskytuje Windows NT. Dalsˇ´ı prakticke´ zkusˇenosti je mozˇno zı´skat na cvicˇenı´ch (prˇedmeˇtu Operacˇnı´ syste´my) cˇi v publikaci [Kep08b]. Pojmy k zapamatova´nı´ 72

• • • • • • • • • • • • • • • • • •

zası´la´nı´ zpra´v synchronizacˇnı´ primitivum atomicka´ operace test–and–set compare–and–swap fetch–and–add Petersonu˚v algoritmus semafor mutex kriticka´ sekce uda´lost signa´l monitor cˇekacı´ funkce cˇekatelny´ objekt mapova´nı´ souboru do pameˇti roura futex

Kontrolnı´ ota´zky 1. Ktere´ synchronizacˇnı´ primitivum je za´kladnı´ a procˇ? 2. Vysveˇtlete, procˇ se synchronizace pouzˇ´ıva´ cˇasteˇji mezi vla´kny nezˇ mezi procesy. 3. Co dalsˇ´ıho kromeˇ vla´ken a procesu˚ se synchronizuje pomocı´ synchronizacˇnı´ch primitiv? Uved’te take´ alesponˇ jeden konkre´tnı´ prˇ´ıklad. 4. Co je to atomicka´ operace? 5. Jake´ negativnı´ du˚sledky mu˚zˇe mı´t, kdyzˇ je atomicka´ operace moc velka´ (hodneˇ rˇa´dku˚ ko´du, de´letrvajı´cı´ slozˇiteˇjsˇ´ı algoritmus atp.)? 6. Uved’te prakticky´ prˇ´ıklad ko´du, ktery´ je chybny´ kvu˚li neatomicke´mu prova´deˇnı´ neˇjake´ jednoduche´ operace ve vı´ce vla´knech. 7. Jaka´ hardwarova´ atomicka´ operace je „nejlepsˇ´ı“? Pokuste se to zdu˚vodnit. 8. Procˇ se Petersonu˚v algoritmus v praxi te´meˇrˇ nepouzˇ´ıva´? 9. Jaky´ je principia´lnı´ rozdı´l mezi semaforem a mutexem? 10. Monitor je prvek s mnoha vy´hodny´mi vlastnostmi. Procˇ je k dispozici jen v objektoveˇ orientovany´ch syste´mech? Navrhneˇte, jak by mohl by´t prˇida´n do neobjektovy´ch syste´mu˚. 11. Vysveˇtlete operaci compare–and–swap. 12. Ve Windows jsou uda´losti resetova´ny automaticky nebo manua´lneˇ. V jaky´ch situacı´ch se jeden nebo druhy´ typ pouzˇ´ıva´? Popisˇte je tak, aby byl patrny´ rozdı´l, tj. procˇ je v neˇktery´ch situacı´ch automaticka´ cˇi manua´lnı´ uda´lost nevhodna´. 13. Jaky´ je ve Windows rozdı´l mezi mutexem a kritickou sekcı´? Jaky´ ma´ toto cˇleneˇnı´ prˇ´ınos pro programy cˇi programa´tory? Uved’te strucˇneˇ vy´hody a nevy´hody obou primitiv, ktery´mi se lisˇ´ı. 14. Funkce SignalObjectAndWait je ve Windows atomickou operacı´. Kdyby tato funkce v syste´mu nebyla, jak byste ji implementovali pomocı´ jiny´ch primitiv? Jisteˇ je vı´ce mozˇnostı´, takzˇe vasˇe rˇesˇenı´ zdu˚vodneˇte (uved’te vy´hody cˇi nevy´hody, ktere´ va´s vedly k jeho pouzˇitı´). Cvicˇenı´

73

1. Dokazˇte, zˇe prˇi soubeˇhu vla´ken prˇi operaci push na za´sobnı´ku dojde prˇi porˇadı´ provedenı´ ABBA, ABAB, BAAB nebo BABA k chybeˇ. (Ukazˇte rozdı´l mezi spra´vny´m a skutecˇny´m stavem za´sobnı´ku.) 2. Proble´m kurˇa´ku˚ cigaret (Patil 1971 [Pat71]). Meˇjme trˇi kurˇa´ky cigaret a jednoho agenta. Proces kurˇa´k cyklicky zabalı´ cigaretu a vykourˇ´ı ji. Potrˇebuje k tomu ale trˇi soucˇa´sti: papı´r, taba´k a za´palky. Jeden kurˇa´k ma´ jen papı´r, druhy´ jen taba´k a trˇetı´ jen za´palky. Proces agent ma´ neomezene´ mnozˇstvı´ vsˇeho. Agent polozˇ´ı na stu˚l dveˇ na´hodneˇ vybrane´ soucˇa´sti, kurˇa´k, ktery´ pra´veˇ tyto dveˇ potrˇebuje, je vezme, zabalı´ cigaretu, vykourˇ´ı ji a da´ signa´l agentovi, zˇe dokourˇil. Agent pak da´ na stu˚l dalsˇ´ı dveˇ... Napisˇte program implementujı´cı´ tuto situaci. 3. V MSDN si zjisteˇte, co je to APC a kdy se pouzˇ´ıva´. V textu kapitoly byla uvedena informace, zˇe APC je „pomeˇrneˇ ma´lo pouzˇ´ıvana´ funkcionalita NT“. Co je du˚vodem? (Maly´ prˇ´ınos APC, existence jiny´ch podobny´ch entit v syste´mu, nebo uvedete neˇco jine´ho?)

74

8

Deadlock (uva´znutı´)

Studijnı´ cı´le: V te´to kapitole volneˇ nava´zˇeme na kapitolu prˇedchozı´. Prˇi spolupra´ci vı´ce vla´ken cˇi procesu˚ totizˇ mu˚zˇe dojı´t k tzv. deadlocku (uva´znutı´), kdy vy´pocˇet nemu˚zˇe da´le pokracˇovat. Problematika deadlocku patrˇ´ı ke klasicky´m te´matu˚m studia operacˇnı´ch syste´mu˚. Klı´cˇova´ slova: deadlock, banke´rˇu˚v algoritmus, graf prostrˇedku˚, dvojfa´zove´ zamyka´nı´ Potrˇebny´ cˇas: 90 minut.

8.1

´ vod U

Proble´m uva´znutı´, anglicky deadlock, patrˇ´ı ke klasicky´m te´matu˚m studia operacˇnı´ch syste´mu˚. Strucˇny´ u´vod do problematiky je nasnadeˇ: Ma´me-li vla´kna cˇi procesy synchronizovane´ pomocı´ prvku˚ uvedeny´ch v prˇedchozı´m textu te´to kapitoly, ma´me v ko´du mimo jine´ take´ hodneˇ mı´st, kde vla´kno cˇi proces cˇeka´. Prˇi masivnı´m pouzˇ´ıva´nı´ synchronizace nenı´ daleko k tomu, aby nastala situace, kdy kazˇdy´ na neˇco cˇi neˇkoho cˇeka´, ale nikdo nedeˇla´ nic. Takove´ situaci se rˇ´ıka´ deadlock. Vla´kno prˇitom mu˚zˇe cˇekat jak na jine´ vla´kno, tak na neˇjaky´ hardwarovy´ prostrˇedek (v podobeˇ syste´move´ho zdroje). Za´lezˇ´ı na konkre´tnı´m operacˇnı´m syste´mu, jak jsou cı´le cˇeka´nı´ reprezentova´ny. (Jak uzˇ vı´me, v syste´mu NT lze cˇekat na cˇekatelne´ objekty, ale take´ na uda´losti posı´lane´ do oken nebo uda´losti dokoncˇenı´ I/O operace.) Vy´skyt uva´znutı´ je pra´veˇ cˇasteˇjsˇ´ı prˇi pra´ci se syste´movy´mi zdroji nezˇ prˇi pouhe´ synchronizaci spolupracujı´cı´ch vla´ken. Hovorˇ´ıme-li o prostrˇedcı´ch, obecneˇ platny´ postup pouzˇ´ıva´nı´ prostrˇedku˚ ma´ trˇi kroky: 1. Request – Proces si vyzˇa´da´ prostrˇedek od syste´mu. Nenı´-li prostrˇedek pra´veˇ k dispozici, vla´kno cˇeka´ tak dlouho, nezˇ k dispozici bude. 2. Use – Vla´kno ma´ prostrˇedek a pracuje s nı´m. 3. Release – Vla´kno uvolnı´ prostrˇedek (vra´tı´ jej „zpeˇt“ syste´mu). prˇ´ıklad 1: otevrˇenı´ souboru, pak cˇtenı´/za´pis, pak zavrˇenı´ prˇ´ıklad 2: vyzˇa´da´nı´ hardwarove´ho zarˇ´ızenı´, pra´ce se zarˇ´ızenı´m, uvolneˇnı´ zarˇ´ızenı´

8.2

Kdy nasta´va´ deadlock

Deadlock mu˚zˇe nastat jen v prˇ´ıpadeˇ, kdyzˇ platı´ tyto cˇtyrˇi podmı´nky soucˇasneˇ: 1. Mutual exclusion – Vy´lucˇne´ vlastnictvı´ prostrˇedku˚ (Doslovny´ prˇeklad: vza´jemne´ vyloucˇenı´ [procesu˚].) Alesponˇ jeden prostrˇedek je ve vy´hradnı´m vlastnictvı´, tj. vlastneˇn jednı´m procesem a jake´koliv jine´ procesy v prˇ´ıpadeˇ za´jmu o neˇj musejı´ cˇekat. 2. Hold & wait – Drzˇ´ı a cˇeka´ Proces jizˇ vlastnı´ neˇjaky´ prostrˇedek, drzˇ´ı si jej a cˇeka´ na dalsˇ´ı. 3. No preemption – Nenı´ preempce (Alternativnı´ prˇeklad: neodnı´matelnost [prostrˇedku˚].) Kdyzˇ nenı´ preempce, proces ma´ prostrˇedek tak dlouho, nezˇ jej dobrovolneˇ vra´tı´. Syste´m nemu˚zˇe prostrˇedek nikomu na´silneˇ odebrat. 4. Circular wait – Cyklicke´ cˇeka´nı´ Cyklicky´m cˇeka´nı´m nazy´va´me situaci popsanou na zacˇa´tku kapitoly – kdyzˇ ma´me skupinu procesu˚, kde kazˇdy´ na neˇkoho cˇeka´. Nejjednodusˇsˇ´ı prˇ´ıpad lze forma´lneˇ popsat takto: Proces A vlastnı´ prostrˇedek 1 a chce prostrˇedek 2. Proces B vlastnı´ prostrˇedek 2 a chce prostrˇedek 1. Jakmile A pozˇa´da´ o 2 a B pozˇa´da´ o 1, docha´zı´ k cyklicke´mu cˇeka´nı´. V obecne´m prˇ´ıpadeˇ mu˚zˇe by´t zu´cˇastneˇn libovolny´ pocˇet procesu˚ vlastnı´cı´ch libovolne´ prostrˇedky. 75

Pru˚vodce studiem Vsˇimneˇte si, zˇe cˇtyrˇi uvedene´ podmı´nky nejsou zcela neza´visle´. Naprˇ. cˇtvrta´ podmı´nka automaticky implikuje druhou.

Pru˚vodce studiem Udeˇlejme si jasno v tom, kdo na koho vlastneˇ mu˚zˇe cˇekat. V prˇedchozı´ kapitole byla rˇecˇ o synchronizaci vla´ken, ktera´ se ty´ka´ cˇisteˇ jen vla´ken. Cˇeka´-li neˇjake´ vla´kno kvu˚li synchronizaci, pak cˇeka´ na synchronizacˇnı´ objekt vlastneˇny´ jiny´m vla´knem. V te´to kapitole hovorˇ´ıme spı´sˇe o pra´ci s prostrˇedky, z hlediska deadlocku jsou vsˇak synchronizacˇnı´ objekty a syste´move´ prostrˇedky rovnocenne´ – na obojı´ lze cˇekat. Ostatneˇ objekty i prostrˇedky jsou vlastneˇny neˇjaky´mi procesy cˇi vla´kny a cˇeka´me-li na prostrˇedek, pak cˇeka´me na to, azˇ ho proces cˇi vla´kno, ktere´ jej vlastnı´, uvolnı´.

8.3

ˇ esˇenı´ deadlocku R

K problematice deadlocku lze prˇistupovat v za´sadeˇ cˇtyrˇmi mozˇny´mi zpu˚soby: 1. Ignorance Toto je tzv. „psˇtrosı´ politika“ – proble´m nijak aktivneˇ nerˇesˇ´ıme („Neˇjak to prosteˇ dopadne.“) Tı´mto zpu˚sobem se chova´ veˇtsˇina operacˇnı´ch syste´mu˚. (Prˇidejme jeden cita´t: „Maybe if you ignore it, it will ignore you.“ [Tan01]) 2. Detekce a zotavenı´ (detection & recovery) Deadlock rˇesˇ´ıme, azˇ nastane. Zjistı´me-li jej, tak zrusˇ´ıme jeden ze zu´cˇastneˇny´ch procesu˚. 3. Zamezenı´ vzniku (prevention) Deadlock rˇesˇ´ıme preventivneˇ – zajistı´me, aby neˇktera´ ze cˇtyrˇ podmı´nek deadlocku nemohla nikdy nastat. (Lze toho dosa´hnout zavedenı´m omezujı´cı´ch podmı´nek, jak lze zˇa´dat o prostrˇedky.) 4. Vyhy´ba´nı´ se uva´znutı´ (avoidance) Toto je nejslozˇiteˇjsˇ´ı prˇ´ıstup – syste´m vyhovı´ jen teˇm zˇa´dostem o prostrˇedky, ktere´ nemohou ve´st k uva´znutı´, zatı´mco ostatnı´ pozdrzˇ´ı. Tento prˇ´ıstup je nejpruzˇneˇjsˇ´ı, ale vyzˇaduje jistou spolupra´ci aplikacı´ – ty musejı´ doprˇedu nahla´sit, co vsˇe budou v budoucnu potrˇebovat. Jednotlive´ prˇ´ıstupy si podrobneˇji probereme v na´sledujı´cı´ch sekcı´ch. 8.3.1

Detekce deadlocku

Nedeˇla´-li syste´m prevenci, ani vyhy´ba´nı´ se deadlocku, pak deadlock mu˚zˇe nastat. Syste´m by pak meˇl prova´deˇt detekci deadlocku a zotavenı´ z neˇj, rˇesˇ´ı se tedy dveˇ samostatne´ u´lohy: 1. detekce, 2. zotavenı´. Acˇkoliv tento prˇ´ıstup mu˚zˇe vypadat jako poneˇkud me´neˇcenny´, pro neˇktere´ syste´my je vy´hodny´ – pokud deadlocky nasta´vajı´ jen velmi zrˇ´ıdka, mu˚zˇe by´t neekonomicke´ prova´deˇt velmi slozˇitou prevenci cˇi vyhy´ba´nı´ se jim. Navı´c kazˇdy´ syste´m obvykle obsahuje na´stroje, ktery´mi mu˚zˇe uzˇivatel (cˇi spra´vce) manua´lneˇ prova´deˇt zotavenı´ (naprˇ. ukoncˇenı´ (kill) procesu, ktery´ beˇzˇ´ı s moc velkou prioritou nebo se jakkoliv pokazil); tyto na´stroje pak mohou by´t pouzˇity k zotavenı´ z deadlocku. K detekci deadlocku pouzˇ´ıva´me alokacˇnı´ graf prostrˇedku˚ nebo z neˇj odvozeny´ graf cˇeka´nı´ mezi procesy (viz obr. 11). Alokacˇnı´ graf je orientovany´ graf zna´zornˇujı´cı´ procesy jako kolecˇka 76

(P) a prostrˇedky jako cˇtverecˇky (R). Orientovane´ hrany vyznacˇujı´ bud’, zˇe R „je vlastneˇn“ P, nebo zˇe P „zˇa´da´“ R. Sˇipka od procesu k prostrˇedku tedy znamena´, zˇe proces o neˇj zˇa´da´, obra´cena´ sˇipka pak, zˇe prostrˇedek procesu patrˇ´ı. Prˇedpokla´da´me prˇitom, zˇe prostrˇedky nelze sdı´let, ovsˇem alokacˇnı´ graf lze samozrˇejmeˇ zobecnit i na prˇ´ıpad, zˇe neˇktere´ prostrˇedky lze prˇideˇlit vı´ce procesu˚m soucˇasneˇ.

Obra´zek 11: Alokacˇnı´ graf prostrˇedku˚ (vlevo) a jemu odpovı´dajı´cı´ graf cˇeka´nı´ (vpravo). [SGG05] Graf cˇeka´nı´ (wait–for graph) zobrazuje „kdo na koho cˇeka´“. Sestavı´me jej velmi jednodusˇe z alokacˇnı´ho grafu tak, zˇe vynecha´me uzly prostrˇedku˚ a procesy spojı´me tak, zˇe hrana P1 → P2 vede pra´veˇ tehdy, kdyzˇ pu˚vodneˇ byly hrany P1 → R a R → P2 . Jsou-li v grafu cˇeka´nı´ neˇjake´ cykly, pak nastal deadlock. Za u´cˇelem detekce deadlocku si tedy syste´m musı´ trvale udrzˇovat graf cˇeka´nı´ a pravidelneˇ spousˇteˇt algoritmus hleda´nı´ cyklu˚ v grafu. To je samozrˇejmeˇ vy´pocˇetneˇ na´rocˇne´, se slozˇitostı´ rostoucı´ s pocˇtem procesu˚ (uzly) a pocˇtem cˇeka´nı´ mezi nimi (hrany). Ota´zka, jak cˇasto detekcˇnı´ algoritmus spousˇteˇt, tedy za´visı´ na tom, jak moc je pravdeˇpodobny´ vy´skyt deadlocku, a kolik vlastneˇ ma´me v syste´mu beˇzˇ´ıcı´ch procesu˚. Jelikozˇ deadlock mu˚zˇe nastat jen prˇi cˇeka´nı´, nema´ smysl spousˇteˇt detekci jindy nezˇ v okamzˇiku zˇa´dosti o prostrˇedek, ktera´ zpu˚sobı´ cˇeka´nı´. Pokud tato zˇa´dost byla onou „poslednı´ kapkou“ k deadlocku, pak rovnou zna´me i jeden z uva´znuty´ch procesu˚. Namı´sto prohleda´va´nı´ cele´ho grafu tedy stacˇ´ı vyjı´t od tohoto procesu a hledat jen cykly, ve ktery´ch by byl obsazˇen. Spousˇteˇt detekci prˇi kazˇde´ zˇa´dosti o prostrˇedek, ktera´ nenı´ splneˇna bez cˇeka´nı´, je samozrˇejmeˇ dost neefektivnı´ a zpomalilo by to vy´kon syste´mu. Je vhodneˇjsˇ´ı detekci prova´deˇt jen jednou za cˇas, nebo prˇi zjisˇteˇnı´ nevytı´zˇene´ho CPU (cozˇ jednak znamena´, zˇe CPU lze vyuzˇ´ıt pro detekci, ale mu˚zˇe to take´ znamenat, zˇe pocˇ´ıtacˇ zrˇejmeˇ nema´ nic na pra´ci, protozˇe hodneˇ procesu˚ uva´zlo v deadlocku). 8.3.2

Zotavenı´ z deadlocku

Deadlock lze rˇesˇit dveˇma zpu˚soby: Bud’odstrˇelı´me (kill) jeden nebo vı´ce zu´cˇastneˇny´ch procesu˚, nebo na´silneˇ odebereme jeden nebo vı´ce zu´cˇastneˇny´ch prostrˇedku˚. Zotavenı´ odstrˇelenı´m procesu mu˚zˇe probeˇhnout tak, zˇe jsou odstrˇeleny vsˇechny procesy zu´cˇastneˇne´ v deadlocku a syste´m prˇevezme zpeˇt vsˇechny jejich prostrˇedky. To je znacˇneˇ likvidacˇnı´, navı´c to ani nemusı´ by´t jednoduche´ a rychle´. Druhou mozˇnostı´ je vybrat jen jednoho kandida´ta, odstrˇelit jej a zkontrolovat, zda tı´m byl vyrˇesˇen deadlock. Pokud ne, opakujeme proces zotavenı´ 77

znovu. Nevy´hodou tohoto postupu je, zˇe musı´me znovu a znovu projı´t detekcı´ deadlocku, cozˇ je take´ vy´pocˇetneˇ na´rocˇne´. Syste´m by zde navı´c meˇl rozumneˇ rˇesˇit ota´zku, ktery´ z procesu˚ je ten vhodny´ kandida´t na odstrˇelenı´. Rˇesˇenı´ te´to ota´zky nenı´ jednoduche´, jedna´ se v podstateˇ o obdobu pla´nova´nı´ procesu˚ (diskutova´no v kapitole 5 na straneˇ 41). Zotavenı´ preempcı´ prostrˇedku˚ mu˚zˇe probeˇhnout i bez odstrˇelu beˇzˇ´ıcı´ch procesu˚. Pokud vsˇak tyto s mozˇnou preempcı´ nepocˇ´ıtajı´, vy´sledek jejich vy´pocˇtu nebude korektnı´, cozˇ mu˚zˇe v du˚sledku zpu˚sobit vı´ce sˇkody nezˇ odstrˇelenı´ procesu. Prˇi preempci prostrˇedku˚ opeˇt rˇesˇ´ıme ota´zku, ktery´ prostrˇedek vybrat k preempci a opeˇt jde o pomeˇrneˇ slozˇitou u´lohu. Odstrˇelenı´ procesu˚ i preempce prostrˇedku˚ s sebou nesou jesˇteˇ jedno spolecˇne´ riziko – budemeli takto postupovat, mu˚zˇe dojı´t k hladoveˇnı´ (starvation), kdy opakovaneˇ docha´zı´ k deadlocku, ten je rˇesˇen na u´kor stejne´ho procesu a jeho vy´pocˇet je opakova´n. Zajistit, aby nikdy nedosˇlo k hladoveˇnı´ tohoto typu, je samozrˇejmeˇ take´ znacˇneˇ obtı´zˇne´. 8.3.3

Zamezenı´ vzniku

Zamezenı´ vzniku (neboli prevence) deadlocku funguje na za´kladeˇ bodu˚ uvedeny´ch v sekci 8.2. Deadlocku zamezı´me tak, zˇe zajistı´me, aby neˇktera´ z uvedeny´ch cˇtyrˇ podmı´nek v syste´mu nemohla nastat. Zastavme se nynı´ u jednotlivy´ch prˇ´ıpadu˚. Zamezenı´ vy´lucˇne´mu vlastnictvı´ Vy´lucˇne´mu vlastnictvı´ prostrˇedku˚ zamezı´me teoreticky tak, zˇe vsˇechny prostrˇedky budou sdı´lene´. Jsou-li prostrˇedky sdı´lene´, pak je mohou pouzˇ´ıvat vsˇechny procesy soucˇasneˇ a zˇa´dny´ nemusı´ cˇekat. V praxi vsˇak neˇktere´ prostrˇedky nelze sdı´let, naprˇ. vypalovacˇka CD teˇzˇko bude vypalovat pro dva procesy soucˇasneˇ – vy´sledek by byl nepouzˇitelny´. U rˇady hardwarovy´ch zarˇ´ızenı´ vsˇak soucˇasne´ syste´my poskytujı´ jisty´ zpu˚sob sdı´lenı´, prˇinejmensˇ´ım pomocı´ jiste´ u´rovneˇ virtualizace. Naprˇ. tiska´rna rovneˇzˇ nemu˚zˇe tisknout dva dokumenty soucˇasneˇ (podobneˇ jako vypalovacˇka CD), ale syste´m ji virtualizuje pomocı´ spooleru a dı´ky zarˇazova´nı´ dokumentu˚ do tiskove´ fronty se ru˚zny´m procesu˚m mu˚zˇe tiska´rna jevit, jakoby ji meˇly ve vy´hradnı´m vlastnictvı´. (Tiskove´ fronty byly jednı´m z prvnı´ch zpu˚sobu˚ sdı´lenı´ prostrˇedku˚.) Podobneˇ je sdı´lena take´ obrazovka nebo diskova´ kapacita. Obecneˇ vsˇak v syste´mu mohou by´t zarˇ´ızenı´, ktera´ sdı´let nelze. Zamezenı´ drzˇenı´ a cˇeka´nı´ Drzˇenı´ a cˇeka´nı´ zamezı´me tak, zˇe budeme vyzˇadovat, aby proces zˇa´dal o prostrˇedky pouze tehdy, kdyzˇ zˇa´dne´ nevlastnı´. Tuto na prvnı´ pohled prˇ´ısnou podmı´nku lze splnit tak, zˇe procesy jsou povinny zˇa´dat vsˇechny prostrˇedky prˇed zacˇa´tkem vlastnı´ho vy´pocˇtu. Tento prˇ´ıstup vsˇak nenı´ vhodny´ pro interaktivnı´ aplikace, kde nemusı´ by´t prˇedem jasne´, ktere´ prostrˇedky budou potrˇeba. (Naprˇ. pocˇ´ıtacˇova´ hra mu˚zˇe potrˇebovat prˇ´ıstup na sı´t’pro hru vı´ce hra´cˇu˚. Pokud vsˇak uzˇivatel hru vı´ce hra´cˇu˚ nezapne, sı´t’ova´ komunikace nebude trˇeba, takzˇe nenı´ du˚vod prˇedem automaticky tento prostrˇedek vyzˇadovat.) Dalsˇ´ı alternativou je, zˇe proces mu˚zˇe zˇa´dat o prostrˇedky i pozdeˇji nezˇ na zacˇa´tku vy´pocˇtu a mu˚zˇe je zˇa´dat i ve veˇtsˇ´ım pocˇtu soucˇasneˇ, avsˇak nemu˚zˇe nikdy zˇa´dat o dalsˇ´ı drˇ´ıve, nezˇ syste´mu vra´tı´ vsˇechny, ktere´ jizˇ ma´ z drˇ´ıveˇjsˇka. Tento prˇ´ıstup je opeˇt neprˇ´ılisˇ vhodny´ pro interaktivnı´ aplikace. Popsane´ algoritmy majı´ navı´c dveˇ nevy´hody. Prvnı´ je dosti nı´zka´ efektivita pra´ce se zdroji – mnoho jich je prˇideˇleno procesu˚m, ale tyto je po delsˇ´ı dobu nemusejı´ vyuzˇ´ıvat. Druhy´m proble´mem je nebezpecˇ´ı hladoveˇnı´. Vyzˇaduje-li proces ke sve´ pra´ci prostrˇedky ve veˇtsˇ´ım mnozˇstvı´ nebo alesponˇ neˇjake´ popula´rnı´, pak je velke´ riziko, zˇe na neˇ bude donekonecˇna cˇekat, nebot’v kazˇdy´ okamzˇik alesponˇ jeden z pozˇadovany´ch prostrˇedku˚ vlastnı´ jiny´ proces.

78

Umozˇneˇnı´ odejmout prostrˇedek Zavedenı´ preempce (odejmutı´ prostrˇedku) je dalsˇ´ı mozˇny´ prˇ´ıstup prevence deadlocku. V okamzˇiku, kdy proces zˇa´da´ o prostrˇedek, ktery´ mu nemu˚zˇe by´t prˇideˇlen, syste´m odebere cˇekajı´cı´mu procesu vsˇechny jeho prostrˇedky a prˇida´ je do seznamu prostrˇedku˚, na ktere´ proces cˇeka´. Proces pokracˇuje azˇ v okamzˇiku, kdy mu˚zˇe vsˇechny pozˇadovane´ prostrˇedky dostat, syste´m prˇitom musı´ zajistit obnovenı´ jejich stavu tak, aby proces ani nepoznal, zˇe mu byly prostrˇedky odebra´ny. Druhou alternativou je postup, kde cˇekajı´cı´mu procesu nejsou odebra´ny vsˇechny prostrˇedky, ale prˇi zˇa´dosti o prostrˇedek se tento odebere preempcı´ tehdy, pokud jej vlastnı´ proces, ktery´ sa´m na neˇco cˇeka´. Tento postup je vhodny´ u prostrˇedku˚, jejichzˇ stav lze snadno obnovit, jako naprˇ. hodnoty registru˚ CPU. Pru˚vodce studiem Prˇ´ıkladem syste´mu, ktery´ pouzˇ´ıva´ prevenci deadlocku preempcı´ prostrˇedku˚, je DirectX. U veˇtsˇiny prostrˇedku˚ se syste´m navı´c nezaby´va´ ulozˇenı´m jejich stavu, protozˇe to z povahy veˇci nenı´ podstatne´. (Naprˇ. obrazovka se prˇekresluje cela´ mnohokra´t za sekundu, takzˇe nema´ smysl obnovovat ji do stavu, ktery´ meˇla prˇed dvojı´m prˇepnutı´m procesu˚.) Tato implementace syste´mu 100% zamezuje deadlocku, ale nemusı´ by´t vy´pocˇetneˇ u´plneˇ efektivnı´, protozˇe procesy prˇi pra´ci s prostrˇedky musejı´ prˇedpokla´dat, zˇe naprosto kdykoliv mohou o ktery´koliv prostrˇedek prˇijı´t. Jelikozˇ syste´m DirectX nepouzˇ´ıva´ strukturovane´ vy´jimky, ko´d programu˚ je pak doslova prosˇpikova´n testova´nı´m na´vratovy´ch ko´du˚ jednotlivy´ch syste´movy´ch funkcı´.

Zamezenı´ cyklicke´mu cˇeka´nı´ Poslednı´ mozˇnost prevence deadlocku je zamezenı´ cyklicke´mu cˇeka´nı´. Jak uzˇ bylo zmı´neˇno, hold & wait je podmnozˇinou cyklicke´ho cˇeka´nı´, takzˇe jisteˇ neprˇekvapı´, zˇe algoritmy zamezujı´cı´ teˇmto dveˇma stavu˚m si rovneˇzˇ budou podobne´. Cyklu˚m zamezı´me tak, zˇe zavedeme globa´lnı´ porˇadı´ prostrˇedku˚, prostrˇedky tedy budou mı´t sva´ globa´lneˇ jedinecˇna´ cˇ´ısla. Proces pak mu˚zˇe zˇa´dat o prostrˇedky pouze v tom porˇadı´, v jake´m jsou ocˇ´ıslova´na. Alternativneˇ je mozˇno pozˇadovat, zˇe proces v okamzˇiku pozˇadavku o prostrˇedek nevlastnı´ zˇa´dny´ s vysˇsˇ´ım cˇ´ıslem (tj. mohl jej vlastnit drˇ´ıve, ale uzˇ jej vra´til). Prˇi implementaci cˇ´ıslova´nı´ prostrˇedku˚ je nutno postupovat uva´zˇliveˇ, pokud naprˇ. tiska´rna bude mı´t mensˇ´ı cˇ´ıslo nezˇ disk, pak programy zrˇejmeˇ nic nenatisknou, protozˇe data k tisku je trˇeba nejdrˇ´ıve prˇecˇ´ıst z disku. (I tento proble´m samozrˇejmeˇ lze neˇjak rˇesˇit, ale vhodny´m cˇ´ıslova´nı´m je mozˇno se mu zcela vyhnout.) 8.3.4

Vyhy´ba´nı´ se uva´znutı´

Prevence deadlocku diskutovana´ v prˇedchozı´ch odstavcı´ch funguje na principu omezenı´ zpu˚sobu, jaky´m lze o prostrˇedky zˇa´dat. Jak jsme si vsˇak uka´zali, vedlejsˇ´ım efektem tohoto prˇ´ıstupu by´va´ mala´ efektivita vyuzˇitı´ prostrˇedku˚ a/nebo nı´zky´ vy´pocˇetnı´ vy´kon syste´mu. Jinou alternativou mu˚zˇe by´t vyhy´ba´nı´ se uva´znutı´, kdy procesy majı´ plnou volnost v zˇa´dostech o prostrˇedky, pouze se od nich vyzˇadujı´ dodatecˇne´ informace o tom, co vsˇechno jesˇteˇ pla´nujı´ zˇa´dat prˇed tı´m, nezˇ sve´ prostrˇedky vra´tı´ syste´mu. Prˇi kazˇde´m dalsˇ´ım pozˇadavku pak syste´m mu˚zˇe dı´ky informacı´m, ktere´ ma´, zkontrolovat, zda pozˇadavku lze ihned vyhoveˇt, nebo je trˇeba proces pozdrzˇet, aby se syste´m vyhnul pozdeˇjsˇ´ımu deadlocku. Pru˚vodce studiem Zjednodusˇeneˇ lze vyhy´ba´nı´ se deadlocku popsat takto: Pokud syste´m dle svy´ch znalostı´ „vidı´“, zˇe hrozı´ deadlock, urcˇ´ı jiste´ porˇadı´ prova´deˇnı´ procesu˚. Procesy pak nebeˇzˇ´ı vsˇechny

79

soucˇasneˇ, ale v tom porˇadı´, ve ktere´m se syste´m deadlocku vyhne. (Neˇktere´ procesy prˇitom mohou beˇzˇet soucˇasneˇ, ale ne vsˇechny.) Bohuzˇel, jak si uka´zˇeme nı´zˇe, ne vzˇdy takove´ bezpecˇne´ porˇadı´ existuje. Klı´cˇovy´ je vzˇdy okamzˇik, kdyzˇ neˇkdo zˇa´da´ o dalsˇ´ı prostrˇedek – tehdy musı´ syste´m rozhodnout, zda je bezpecˇne´ mu jej prˇideˇlit hned, nebo azˇ pozdeˇji.

Popisˇme si nynı´ jeden konkre´tnı´ algoritmus vyhy´ba´nı´ se uva´znutı´ (deadlocku). Syste´m prˇi neˇm od procesu˚ pozˇaduje, aby prˇedem sdeˇlily maxima´lnı´ pocˇet prostrˇedku˚ kazˇde´ho typu, ktere´ mohou v budoucnu pozˇadovat. Syste´m pak dı´ky tomu mu˚zˇe zajistit takove´ pla´nova´nı´ procesu˚, kdy nedojde k cyklicke´mu cˇeka´nı´, tedy nevznikne zˇa´dny´ deadlock. Za´kladem algoritmu je pojem bezpecˇny´ stav. Syste´m je v bezpecˇne´m stavu, jestlizˇe existuje neˇjake´ porˇadı´, v jake´m bude syste´m odpovı´dat procesu˚m na jejich pozˇadavky, prˇi ktere´m nedojde k deadlocku. De facto to znamena´, zˇe musı´ existovat jiste´ porˇadı´ procesu˚, kdy jednotlivy´ proces mu˚zˇe prˇi zˇa´dosti o prostrˇedky cˇekat pouze na procesy s nizˇsˇ´ım cˇ´ıslem. Pokud takove´ porˇadı´ neexistuje, pak je stav nebezpecˇny´. Bezpecˇny´ stav nenı´ nikdy deadlockem, avsˇak ani nebezpecˇny´ stav deadlockem by´t nemusı´. Zavedenı´ pojmu bezpecˇny´ stav prˇ´ımo vede k algoritmu vyhy´ba´nı´ se uva´znutı´: Syste´m se vyhy´ba´ uva´znutı´ tı´m, zˇe zˇa´dosti o prˇideˇlenı´ prostrˇedku˚ vyhovı´ jen tehdy, kdy tı´mto neprˇejde do nebezpecˇne´ho stavu. V opacˇne´m prˇ´ıpadeˇ proces cˇeka´ (prˇestozˇe prostrˇedek mu˚zˇe by´t volny´) a to tak dlouho, nezˇ se syste´m dostane do takove´ho stavu, prˇi ktere´m lze dane´ zˇa´dosti vyhoveˇt a zu˚stat v bezpecˇne´m stavu. (Tj. proces musı´ cˇekat, nezˇ jine´ procesy uvolnı´ prostrˇedky, dı´ky ktery´m bude stav i po prˇideˇlenı´ toho problematicke´ho bezpecˇny´.) Algoritmus na ba´zi alokacˇnı´ho grafu Ma´me-li v syste´mu jen jeden prostrˇedek od kazˇde´ho typu, mu˚zˇeme pro vyhy´ba´nı´ se uva´znutı´ vyuzˇ´ıt algoritmus na ba´zi alokacˇnı´ho grafu prostrˇedku˚, ktery´ byl prˇedstaven v sekci 8.3.1. Graf rozsˇ´ırˇ´ıme o vyznacˇenı´ pla´novany´ch alokacı´ prostrˇedku˚, budeme je znacˇit tecˇkovaneˇ sˇipkou od procesu k prostrˇedku. Od procesu˚ zˇa´da´me, jak jizˇ bylo zmı´neˇno vy´sˇe, aby na zacˇa´tku ozna´mily vsˇechny pla´novane´ alokace, nebo aby oznamovaly nove´ pla´ny pouze tehdy, kdy zˇa´dne´ prostrˇedky nemajı´.

Obra´zek 12: Alokacˇnı´ graf prostrˇedku˚ s vyznacˇenı´m pla´novany´ch alokacı´. [SGG05] Prˇ´ıklad alokacˇnı´ho grafu vidı´me na obra´zku 12. Prostrˇedek R2 je zatı´m volny´, ale oba procesy jej majı´ v pla´nu alokovat. Pozˇa´da´-li o neˇj nejprve P2, pak mu syste´m nesmı´ vyhoveˇt, nebot’by tı´m prˇesˇel do nebezpecˇne´ho stavu (viz obra´zek 13). Prˇideˇlenı´m prostrˇedku totizˇ v grafu vznikne hrana od prostrˇedku k procesu, cˇ´ımzˇ v tomto prˇ´ıpadeˇ vznikne cyklus. Samotny´ cyklus jesˇteˇ nenı´ deadlockem. Konkre´tneˇ na obra´zku 13 je nebezpecˇny´ stav, ale deadlock ne. (Stejneˇ jako v sekci 8.3.1, deadlock je v grafu vyznacˇen cyklem bez tecˇkovany´ch hran.)

80

Obra´zek 13: Alokacˇnı´ graf prostrˇedku˚ s cyklem – nebezpecˇny´ stav. [SGG05] Banke´rˇu˚v algoritmus (Dijkstra 1965) Algoritmus prˇedstaveny´ v prˇedchozı´ch odstavcı´ch funguje prˇi alokaci prostrˇedku˚, kde od kazˇde´ho typu prostrˇedku je v syste´mu jen jedna instance. Syste´my s veˇtsˇ´ım pocˇtem prostrˇedku˚ stejne´ho typu mohou pouzˇ´ıt naprˇ. banke´rˇu˚v algoritmus, ktery´ je obecneˇjsˇ´ı, nenı´ vsˇak tak efektivnı´ jako algoritmus alokacˇnı´ho grafu. Banke´rˇu˚v algoritmus ma´ jme´no podle sve´ podobnosti s chova´nı´m banke´rˇe, ktery´ vı´, kolik maxima´lneˇ budou vsˇichni jeho klienti potrˇebovat, a jejich jednotlive´ pozˇadavky o dalsˇ´ı pu˚jcˇky splnˇuje okamzˇiteˇ, nebo pozdrzˇuje na pozdeˇji tak, aby v kazˇde´m okamzˇiku meˇl dostatecˇnou hotovost, aby mohl v konecˇne´m cˇase obslouzˇit vsˇechny klienty. Na zacˇa´tku proces opeˇt musı´ ozna´mit, kolik instancı´ prostrˇedku kazˇde´ho typu bude beˇhem vy´pocˇtu potrˇebovat. Potom prˇi alokaci syste´m opeˇt kontroluje, zda splneˇnı´m pozˇadavku neprˇejde syste´m do nebezpecˇne´ho stavu a prˇ´ıpadneˇ pozˇadavek odlozˇit na pozdeˇji. Je take´ mozˇno rˇ´ıci, zˇe aktua´lnı´ stav je bezpecˇny´, pokud existuje neˇjaka´ posloupnost prova´deˇnı´ procesu˚, prˇi ktere´ jsou pozˇadavky vsˇech uspokojeny. Zjisˇteˇnı´, zda aktua´lnı´ stav procesu je bezpecˇny´, znamena´ porovnat aktua´lneˇ volne´ prostrˇedky s aktua´lneˇ prˇideˇleny´mi a maxima´lnı´mi pozˇadavky jednotlivy´ch procesu˚ a postupneˇ si „odsˇkrta´vat“ ty procesy, u ktery´ch je dostatecˇny´ pocˇet prostrˇedku˚ k dokoncˇenı´. Prostrˇedky ve vlastnictvı´ odsˇkrtnuty´ch procesu˚ prˇipojujeme do seznamu volny´ch, na za´veˇr musı´me mı´t vsˇechny procesy odsˇkrtnute´. Pokud takove´ porˇadı´ neexistuje, stav je nebezpecˇny´ a do takove´ho stavu syste´m nesmı´ prˇejı´t. Forma´lnı´ popis banke´rˇova algoritmu najdete naprˇ. v [SGG05, Tan01].

8.4

Dvojfa´zove´ zamyka´nı´ a dalsˇ´ı te´mata

Problematika deadlocku˚ patrˇ´ı ke „zlaty´m“ te´matu˚m operacˇnı´ch syste´mu˚. Zatı´mco v pocˇa´tcı´ch te´to disciplı´ny se veˇdci deadlocky rozsa´hle a hluboce zaby´vali, v soucˇasnosti je situace pomeˇrneˇ klidna´ – veˇtsˇina operacˇnı´ch syste´mu˚ nerˇesˇ´ı deadlocky nijak, neˇktere´ u´zce specializovane´ aplikace rˇesˇ´ı deadlocky v jiste´ mı´rˇe samy a veˇdci se jimi nezaby´vajı´ prakticky vu˚bec. Prˇ´ıkladem rˇesˇenı´ deadlocku mohou by´t SQL servery, kde se setka´va´me prˇedevsˇ´ım s dvoufa´zovy´m zamyka´nı´m a u teˇch lepsˇ´ıch i s transakcˇnı´m zpracova´nı´m. Dı´ky tomu jsou deadlocky neˇjaky´m zpu˚sobem rˇesˇeny alesponˇ tam, kde by jejich vy´skyt nejvı´c bolel; za´rovenˇ to dokla´da´ fakt, zˇe rˇesˇenı´ deadlocku˚ je snazsˇ´ı u u´zce specializovany´ch syste´mu˚ nezˇ u obecny´ch operacˇnı´ch syste´mu˚. Dvoufa´zove´ zamyka´nı´ je protokol vyzˇadujı´cı´, aby pra´ce s prostrˇedky probı´hala dvoufa´zoveˇ: V prvnı´ fa´zi proces prostrˇedky pouze alokuje, ve druhe´ fa´zi s nimi pracuje a uvolnˇuje je. Zˇa´da´-li proces o prostrˇedek, ktery´ nenı´ volny´, je cela´ prvnı´ fa´ze restartova´na, tj. vsˇechny prostrˇedky jsou odebra´ny a zacˇ´ına´ se odznova. U databa´zovy´ch serveru˚ jsou prostrˇedky obvykle cˇa´sti databa´ze, se ktery´mi proces pracuje, a restartova´nı´ procesu znamena´ znovuprovedenı´ neˇjake´ databa´zove´ operace cˇi transakce sesta´vajı´cı´ z neˇkolika operacı´. Vy´hodou transakcˇnı´ho zpracova´nı´ je, zˇe 81

syste´m doka´zˇe bez u´jmy na datech obnovit prˇedchozı´ stav databa´ze k okamzˇiku, kdy byla zaha´jena transakce, ktera´ skoncˇila nezdarem a byla zrusˇena (rollback). Dvoufa´zove´ zamyka´nı´ a transakcˇnı´ zpracova´nı´ je vy´hodne´ pro SQL databa´ze, ale samozrˇejmeˇ nemusı´ by´t stejneˇ vhodne´ pro ostatnı´ typy u´loh. Beˇzˇne´ operacˇnı´ syste´my je nemohou obecneˇ vyuzˇ´ıvat uzˇ z principu interaktivnı´ pra´ce uzˇivatele, ktera´ dnes prˇevla´da´. Situaci kolem veˇdecke´ho vy´zkumu v oblasti deadlocku˚ shrnuje naprˇ. Tanenbaum [Tan01] tak, zˇe „this research has died out“, s dodatkem k vy´zkumu distribuovany´ch rˇesˇenı´: „Its main function seems to be keeping otherwise unemployed graph theorists off the streets.“ Shrnutı´ Deadlock cˇili uva´znutı´ je potencia´lnı´ proble´m kazˇde´ho syste´mu, operacˇnı´ syste´m nevyjı´maje. V te´to kapitole jsme si nejprve prˇesneˇ popsali, zˇe deadlock mu˚zˇe nastat jen prˇi splneˇnı´ cˇtyrˇ podmı´nek soucˇasneˇ. Pote´ jsme se veˇnovali ru˚zny´m zpu˚sobu˚m, jak se s problematikou deadlocku vyporˇa´dat. Nepocˇ´ıta´me-li tzv. psˇtrosı´ algoritmus „strcˇit hlavu do pı´sku“, pak ma´me trˇi mozˇnosti, co deˇlat. Prvnı´ mozˇnostı´ je pomocı´ alokacˇnı´ho grafu deadlocky detekovat azˇ nastanou a rˇesˇit je posle´ze odstrˇelenı´m jednoho cˇi vı´ce procesu˚. Dalsˇ´ı mozˇnostı´ je zamezenı´ vzniku neboli prevence deadlocku, kdy syste´m nutı´ procesy chovat se tak, aby deadlock nenastal. Poslednı´ alternativou je vyhy´ba´nı´ se deadlocku tı´m, zˇe syste´m vyzˇaduje od procesu˚ informace o budoucı´ch alokacı´ch a necha´ procesy pracovat v urcˇite´m porˇadı´ tak, aby bylo vzˇdy zajisˇteˇno, zˇe vsˇechny procesy v konecˇne´m cˇase budou moci dokoncˇit svu˚j vy´pocˇet. Da´le jsme si uvedli neˇkolik obecny´ch charakteristik deadlocku, jako je jeho vztah k prˇedchozı´ kapitole o synchronizaci, pozice te´matu ve studiu operacˇnı´ch syste´mu˚ nebo princip dvoufa´zove´ho zamyka´nı´ hojneˇ pouzˇ´ıvany´ v SQL databa´zı´ch. Pojmy k zapamatova´nı´ • • • • • • •

vy´lucˇne´ vlastnictvı´ prostrˇedku˚ cyklicke´ cˇeka´nı´ alokacˇnı´ graf prostrˇedku˚ graf cˇeka´nı´ bezpecˇny´ stav [syste´mu] banke´rˇu˚v algoritmus dvojfa´zove´ zamyka´nı´

Kontrolnı´ ota´zky 1. Jmenujte cˇtyrˇi podmı´nky, za ktery´ch nasta´va´ deadlock. Jsou to podmı´nky nutne´, nebo dostacˇujı´cı´? 2. Jmenujte trˇi situace, kdy vznika´ deadlock a nesouvisı´ to s pocˇ´ıtacˇi. 3. Popisˇte dvoufa´zove´ zamyka´nı´. Kde se obvykle pouzˇ´ıva´? Procˇ jej nelze pouzˇ´ıt v obecne´m syste´mu. 4. Popisˇte banke´rˇu˚v algoritmus. 5. Jak lze detekovat deadlock v syste´mu? 6. Prˇedpokla´dejme, zˇe syste´m je v nebezpecˇne´m stavu. Ukazˇte na prˇ´ıkladu, zˇe i tak je mozˇne´, zˇe vsˇechny procesy dokoncˇ´ı cˇinnost bez vy´skytu deadlocku. 7. Prˇedpokla´dejme, zˇe prostrˇedky lze alokovat a uvolnˇovat kdykoliv. Kdyzˇ proces A zˇa´da´ o prostrˇedek, ktery´ je pra´veˇ ve vlastnictvı´ procesu B, kontroluje se, jestli B nenı´ ve stavu cˇeka´nı´. Pokud ano, dany´ prostrˇedek je mu odebra´n a prˇida´n do seznamu prostrˇedku˚, na ktere´ B cˇeka´. A dostane tento prostrˇedek. Mu˚zˇe v takove´m syste´mu dojı´t k deadlocku? Vysveˇtlete. 82

8. Mu˚zˇe se vyskytnout deadlock na pouze jednom procesu? Dokazˇte. Cvicˇenı´ 1. Implementujte banke´rˇu˚v algoritmus pro jeden prostrˇedek podle [Tan01]. 2. Implementujte obecny´ banke´rˇu˚v algoritmus podle [SGG05] nebo [Tan01].

83

9

Spra´va operacˇnı´ pameˇti

Studijnı´ cı´le: V u´vodu nasˇeho studia jsme se sezna´mili s von Neumannovy´m modelem pocˇ´ıtacˇe, ktery´ sesta´va´ ze trˇ´ı za´kladnı´ch cˇa´stı´. V te´to kapitole se dosta´va´me ke studiu druhe´ z nich – operacˇnı´ pameˇti. Tato sekce je opeˇt rozdeˇlena do neˇkolika kapitol. Toto je prvnı´ z nich a sezna´mı´me se s u´vodnı´mi pojmy a za´kladnı´mi zpu˚soby organizace pameˇti, ktery´mi je prˇideˇlova´nı´m souvisly´ch u´seku˚ a stra´nkova´nı´. Rˇecˇ bude take´ o ochraneˇ, ktera´ je neme´neˇ du˚lezˇitou soucˇa´stı´ spra´vy operacˇnı´ pameˇti. Klı´cˇova´ slova: operacˇnı´ pameˇt’, ochrana pameˇti, segmentace, stra´nkova´nı´, copy–on–write Potrˇebny´ cˇas: 150 minut.

9.1

´ vod U

Operacˇnı´ pameˇt’je vedle procesoru druhou nejvy´znamneˇjsˇ´ı soucˇa´stı´ kazˇde´ho pocˇ´ıtacˇe. Jak jisteˇ kazˇdy´ vı´ z vlastnı´ zkusˇenosti, pameˇti na pocˇ´ıtacˇi nenı´ nikdy dost, proto se operacˇnı´ pameˇt’ fyzicky skla´da´ z ru˚zneˇ velky´ch cˇa´sti pameˇtı´ ru˚zny´ch typu˚. Prˇedevsˇ´ım na modernı´ch pocˇ´ıtacˇ´ıch se na operacˇnı´ pameˇti u´cˇastnı´ nejen klasicka´ pameˇt’ RAM cˇi ROM v mnoha varianta´ch, ale take´ pameˇti externı´, prˇeva´zˇneˇ v podobeˇ pevny´ch disku˚ a externı´ch flash modulu˚. Vsˇechny dohromady pak za spolupra´ce operacˇnı´ho syste´mu a hardwaru tvorˇ´ı operacˇnı´ pameˇt’, kterou mu˚zˇe pouzˇ´ıvat centra´lnı´ procesorova´ jednotka a dalsˇ´ı inteligentnı´ soucˇa´sti pocˇ´ıtacˇe, jak jsme si jizˇ uvedli v kapitole 2. Prˇipomenˇme, zˇe v sekci 2.2.3 jsme se sezna´mili s pojmy adresace pameˇti, ba´ze, posunutı´ (offset), linea´rnı´ adresa apod. S teˇmito pojmy budeme v te´to kapitole pracovat. S operacˇnı´ pameˇtı´ souvisı´ prˇedevsˇ´ım tyto za´kladnı´ funkce, na ktery´ch se podı´lı´ hardware pocˇ´ıtacˇe a operacˇnı´ syste´m: • Evidence prostoru volne´ho a prˇideˇlene´ho procesu˚m • Prˇideˇlova´nı´ a uvolnˇova´nı´ pameˇti procesu˚ • Ochrana prˇideˇlene´ho prostoru • Realizace virtua´lnı´ pameˇti V minulosti, a prˇedevsˇ´ım na jednou´lohovy´ch syste´mech, se vesmeˇs pouzˇ´ıvaly velmi jednoduche´ algoritmy organizace pameˇti. Jednou´lohovy´ syste´m, jak si jesˇteˇ uka´zˇeme pozdeˇji, vystacˇ´ı s jednodusˇsˇ´ı spra´vou pameˇti, protozˇe neˇktere´ proble´my tam z principu nemohou nastat vu˚bec, nebo pu˚sobı´ potı´zˇe jen okrajoveˇ. Druhy´m du˚vodem, procˇ se dnes tyto jednoduche´ algoritmy jizˇ nepouzˇ´ıvajı´, je, zˇe prˇi vy´razneˇ vysˇsˇ´ı slozˇitosti a veˇtsˇ´ı pameˇt’ove´ kapaciteˇ dnesˇnı´ch pocˇ´ıtacˇu˚ pro neˇ jizˇ nejsou vhodne´; vy´razneˇ nizˇsˇ´ı cena za jednotku vy´pocˇetnı´ho vy´konu take´ umozˇnˇuje nasazenı´ i takovy´ch algoritmu˚ a zpu˚sobu˚ organizace, ktere´ by v minulosti nebyly ekonomicke´. Na soucˇasny´ch pocˇ´ıtacˇ´ıch a operacˇnı´ch syste´mech se obvykle vyskytuje neˇkolik neza´visly´ch adresovy´ch prostoru˚, tj. samostatny´ch zpu˚sobu˚ cˇ´ıslova´nı´ pameˇt’ovy´ch buneˇk. Existuje jich vı´ce ze dvou du˚vodu˚: Prvnı´m du˚vodem je, zˇe na vı´ceu´lohovy´ch syste´mech je vhodneˇjsˇ´ı, aby kazˇdy´ proces meˇl svou operacˇnı´ pameˇt’ a v nı´ svu˚j vlastnı´ adresovy´ prostor. Druhy´m du˚vodem je hardwarove´ rˇesˇenı´ pocˇ´ıtacˇu˚, kdy tyto obsahujı´ rˇadu neza´visly´ch pameˇtı´ ru˚zny´ch typu˚ a kazˇdy´ z nich ma´ tedy vlastnı´ adresovy´ prostor. Ve spolupra´ci hardwaru s operacˇnı´m syste´mem pak docha´zı´ k mapova´nı´ fyzicke´ pameˇti do adresovy´ch prostoru˚ jednotlivy´ch procesu˚ a to mu˚zˇe by´t deˇla´no i vı´ceu´rovnˇoveˇ, opeˇt cˇisteˇ z prakticky´ch du˚vodu˚, cˇ´ımzˇ vznikajı´ dalsˇ´ı adresove´ prostory. Jednotlive´ adresove´ prostory jsou tedy ru˚zny´mi „pohledy“ na pameˇt’pocˇ´ıtacˇe a prˇedstavı´me si je podrobneˇji ve zbytku te´to kapitoly.

84

Na pocˇ´ıtacˇi je neˇkolik ru˚zny´ch adresovy´ch prostoru˚.

Adresovy´ prostor je pohled na pameˇt’.

Pru˚vodce studiem Na historicky´ch sa´lovy´ch pocˇ´ıtacˇ´ıch lze videˇt, zˇe i v minulosti na nejlepsˇ´ıch (a nejdrazˇsˇ´ıch) pocˇ´ıtacˇ´ıch existovaly sofistikovane´ zpu˚soby organizace pameˇti. Fakt, zˇe rˇada pocˇ´ıtacˇu˚ drˇ´ıve pouzˇ´ıvala spı´sˇe hloupe´ a me´neˇ kvalitnı´ zpu˚soby organizace operacˇnı´ pameˇti, tedy nenı´ zpu˚soben tı´m, zˇe by tato problematika nebyla dostatecˇneˇ odborneˇ zvla´dnuta na teoreticke´ u´rovni. Rˇesˇenı´ zvolene´ pro praxi je vsˇak vzˇdy kompromisem mezi uzˇitkem a cenou. Proto se trˇeba teprve dnes na beˇzˇne´ pocˇ´ıtacˇe dosta´vajı´ rˇesˇenı´ zna´ma´ jizˇ prˇed 30 lety.

Ochrana pameˇti Du˚lezˇity´m te´matem je take´ ochrana pameˇti – musı´ ji zajisˇt’ovat operacˇnı´ syste´m ve spolupra´ci s hardwarem. Smyslem ochrany je zajistit, zˇe kazˇdy´ proces ma´ prˇ´ıstup jen ke sve´ cˇa´sti operacˇnı´ pameˇti a nemu˚zˇe (ani za´meˇrneˇ, ani omylem) cˇ´ıst, nebo dokonce zapisovat a posˇkodit pameˇt’ jine´ho procesu. V minulosti se ochrana pameˇti nerˇesˇila; na jednou´lohovy´ch syste´mech nebyla ani tolik potrˇeba a opeˇt sˇlo o kompromis mezi cenou a uzˇitkem. Nechvalneˇ prosluly´ je syste´m MS-DOS, ktery´ acˇkoliv jednou´lohovy´, ma´ v pameˇti obvykle rˇadu syste´movy´ch ovladacˇu˚, ktere´ snadno mohou by´t porusˇeny chybny´m programem, nebot’tento syste´m zˇa´dnou ochranu pameˇti nepodporuje. Prˇitom pocˇ´ıtacˇe PC AT podporujı´ hardwaroveˇ ochranu pameˇti jizˇ od nejstarsˇ´ıho modelu, pouze chybeˇla podpora v operacˇnı´m syste´mu. Samotna´ realizace ochrany prˇitom prˇ´ımo souvisı´ se zpu˚sobem organizace pameˇti, proto ji budeme diskutovat postupneˇ pro jednotlive´ prˇ´ıpady.

9.2

Prˇideˇlova´nı´ souvisly´ch u´seku˚ (bloku˚) pameˇti

Prˇideˇlova´nı´m souvisly´ch u´seku˚ (bloku˚) nazy´va´me situaci, kdy program je umı´steˇn vcelku na jedno mı´sto fyzicke´ pameˇti. V za´sadeˇ pak lze rozlisˇit dveˇ varianty lisˇ´ıcı´ se tı´m, zda bloky pameˇti jsou stejne´ de´lky, cˇi nikoliv. Prvnı´ mozˇnostı´ je rozdeˇlovat pameˇt’do veˇtsˇ´ıch stejneˇ dlouhy´ch bloku˚. Kazˇdy´ program se pak bez proble´mu˚ vejde do jednoho takove´ho bloku. Jakmile program (prˇesneˇji proces) skoncˇ´ı, jı´m vyuzˇ´ıvany´ blok je vra´cen zpeˇt syste´mu a mu˚zˇe ho pouzˇ´ıt dalsˇ´ı proces. Tento prˇ´ıstup tedy zajisˇt’uje dlouhodobeˇ bezproble´movy´ provoz, ale je zde mala´ efektivita vyuzˇitı´ pameˇti, nebot’ jednotlive´ procesy velmi cˇasto potrˇebujı´ mnohem me´neˇ pameˇti, nezˇ je velikost jednoho bloku. Tomuto jevu rˇ´ıka´me vnitrˇnı´ fragmentace – pameˇt’je obsazena´, ale nenı´ pouzˇ´ıvana´. Tento syste´m pouzˇ´ıval naprˇ. operacˇnı´ syste´m IBM OS/360.

Vnitrˇnı´ fragmentace je u pameˇti obsazene´, ale nepouzˇ´ıvane´.

Druhou mozˇnostı´ je rozdeˇlovat pameˇt’do bloku˚ promeˇnlive´ de´lky podle potrˇeby. Kazˇdy´ program pak mu˚zˇe dostat tolik pameˇti, kolik ve skutecˇnosti potrˇebuje, takzˇe nedocha´zı´ k vy´sˇe zmı´neˇne´ vnitrˇnı´ fragmentaci. Potrˇebuje-li program dalsˇ´ı pameˇt’, mu˚zˇe si pozˇa´dat o dalsˇ´ı u´sek libovolne´ de´lky. Tento zpu˚sob organizace pameˇti pouzˇ´ıva´ naprˇ. syste´m MS-DOS a na jeho prˇ´ıkladu mu˚zˇeme videˇt nevy´hody tohoto rˇesˇenı´ – efektivita vyuzˇitı´ pameˇti je sice zda´nliveˇ velmi vysoka´, ale po jiste´ dobeˇ provozu se zacˇne vyuzˇitı´ pameˇti zhorsˇovat. Tı´m, zˇe bloky pameˇti jsou ru˚zne´ de´lky, totizˇ vznika´ proble´m, kdy hodneˇ pameˇti je volne´, ale je rozkouskovane´ do maly´ch bloku˚, ktere´ nelze vyuzˇ´ıt pro veˇtsˇ´ı programy. Paradoxneˇ totizˇ programy deˇlı´ sva´ data do mensˇ´ıch cˇa´stı´, ktere´ mohou by´t umı´steˇny v libovolne´m mı´steˇ pameˇti, ale jednotlive´ bloky souvisejı´cı´ch dat (vcˇetneˇ ko´du jako celku) musejı´ by´t vzˇdy umı´steˇny spolecˇneˇ – tj. na jeden pozˇadavek o pameˇt’ musı´ syste´m najı´t jeden souvisly´ u´sek pozˇadovane´ velikosti. Vy´sledne´mu jevu se rˇ´ıka´ vneˇjsˇ´ı fragmentace – pameˇt’je sice volna´, ale je nevyuzˇitelna´.

Vneˇjsˇ´ı fragmentace je u pameˇti volne´, ale nevyuzˇitelne´.

Vneˇjsˇ´ı fragmentaci lze cˇa´stecˇneˇ prˇedejı´t pouzˇitı´m neˇjake´ho „chytre´ho“ algoritmu prˇideˇlova´nı´ pameˇti. V okamzˇiku, kdy proces zˇa´da´ o pameˇt’, totizˇ musı´ syste´m rozhodnout, ktery´ z mnoha volny´ch u´seku˚ mu prˇideˇlı´. Nabı´zejı´ se prˇitom nejme´neˇ trˇi mozˇnosti, ze ktery´ch mu˚zˇe vybı´rat: 85

First fit vezme prvnı´ vyhovujı´cı´ blok, ktery´ najde. Cˇili nijak se nesnazˇ´ı rozmy´sˇlet, ktery´ blok je vy´hodneˇjsˇ´ı. Best fit vezme nejmensˇ´ı vyhovujı´cı´ blok. Du˚sledkem tohoto prˇ´ıstupu je, zˇe v pameˇti zby´va´ velmi mnoho nevyuzˇitelny´ch bloku˚, ty jsou vsˇak co nejmensˇ´ı. Worst fit vezme nejveˇtsˇ´ı blok. Du˚sledkem tohoto prˇ´ıstupu je, zˇe v pameˇti nejsou zˇa´dne´ male´ nevyuzˇitelne´ bloky, ovsˇem nelze pak spustit velky´ program, protozˇe velky´ u´sek pameˇti byl rozebra´n na obslouzˇenı´ maly´ch pozˇadavku˚. Bez ohledu na teoreticke´ vlastnosti praxe uka´zala, zˇe worst fit je horsˇ´ı nezˇ prvnı´ dveˇ metody co do efektivity i rychlosti. First fit a best fit jsou zhruba stejneˇ efektivnı´, vhodnost se mu˚zˇe lisˇit dle konkre´tnı´ situace. First fit je prˇitom podstatneˇ rychlejsˇ´ı. Statisticka´ analy´za uka´zala, zˇe u first fit je prˇi alokaci N bloku˚ pru˚meˇrneˇ dalsˇ´ıch 21 N nepouzˇitelny´ch z du˚vodu fragmentace. Cˇili zhruba trˇetina pameˇti je nevyuzˇitelna´. [SGG05] Pru˚vodce studiem Limity zde popsany´ch zpu˚sobu˚ organizace pameˇti jsou dobrˇe videˇt na syste´mu MS-DOS. Pokud ma´ soubor programu 500KB ko´du, tak potrˇebuje jeden souvisly´ u´sek takove´ velikosti. Situaci v MS-DOSu zneprˇehlednˇuje jesˇteˇ rozsˇ´ırˇenı´ DPMI, ktere´ otevrˇelo mozˇnost snadno pouzˇ´ıvat pameˇt’ nad 640KB, cˇ´ımzˇ se obvykle de facto zbavı´me proble´mu˚ s pameˇtı´, nebot’ v MS-DOSu obvykle spousˇtı´me jen jeden program a ten si s fyzickou pameˇtı´ celkem jisteˇ vystacˇ´ı. DPMI je prˇitom jen prˇedpis (standard) a za´lezˇ´ı na jeho implementaci, jak je organizace pameˇti rˇesˇena. Ve skutecˇnosti tedy cˇasto sta´le existuje proble´m vneˇjsˇ´ı fragmentace, ovsˇem nepu˚sobı´ uzˇ tolik proble´my, nebot’velikost fyzicke´ pameˇti vy´razneˇ prˇevysˇuje potrˇeby jednoho programu v MS-DOSu.

Prˇi prˇideˇlova´nı´ souvisly´ch u´seku˚ je fragmentace vzˇdy prˇ´ıtomna´. Mu˚zˇeme se ale pokusit s nı´ bojovat a situaci alesponˇ trochu zlepsˇit. Pokud naprˇ. program potrˇebuje o 2 bajty me´neˇ, nezˇ je velikost volne´ho bloku, pak tyto 2 bajty zu˚stanou v samostatne´m volne´m bloku a budou do budoucna jizˇ prakticky nepouzˇitelne´. Operacˇnı´ syste´m navı´c spotrˇebuje daleko vı´ce pameˇti pro evidenci tohoto bloku. Prvnı´ mozˇnostı´, jak zmensˇit fragmentaci, je alokovat pameˇt’ po veˇtsˇ´ıch kusech nezˇ 1 bajt. Naprˇ. MS-DOS (za podpory hardwaru) alokuje pameˇt’po 16bajtovy´ch blocı´ch. Dalsˇ´ı jeden 16bajtovy´ blok prˇitom spotrˇebuje pro evidenci kazˇde´ho pameˇt’ove´ho bloku, prˇideˇlene´ho i volne´ho. Prˇi tomto syste´mu pak proces zˇa´dajı´cı´ naprˇ. 30 bajtu˚ dostane vzˇdy minima´lneˇ 32. V pameˇti je sice opeˇt fragmentace, tentokra´t vnitrˇnı´, ale celkove´ vyuzˇitı´ je efektivneˇjsˇ´ı nezˇ prˇi prˇideˇlova´nı´ po jednotlivy´ch bajtech. Pru˚vodce studiem Pro zajı´mavost dodejme, zˇe v jazyku C/C++ se v syste´mu MS-DOS pouzˇ´ıva´ vlastnı´ spra´va pameˇti, kdy jazyk alokuje ze syste´mu co nejveˇtsˇ´ı blok pro sebe najednou a z neˇj pak da´va´ programu mensˇ´ı kusy podle potrˇeby. Z kazˇde´ho alokovane´ho bloku prˇitom odebı´ra´ 4 bajty pro evidenci, cozˇ je mnohem lepsˇ´ı nezˇ oneˇch 16 bajtu˚, ktere´ pro svou evidenci vyuzˇ´ıva´ MS-DOS. Vy´hodu jazyk zı´ska´va´ tı´m, zˇe evidenci prostoru vede prˇ´ımo v samotny´ch blocı´ch pameˇti, nepotrˇebuje tedy zˇa´dnou dalsˇ´ı pameˇt’. Syste´mu by sice taky stacˇily 4 bajty, ale nemu˚zˇe si dovolit ukla´dat sva´ data v pameˇti, kterou prˇideˇluje procesu˚m, takzˇe pro kazˇdy´ blok musı´ rezervovat jeden 16bajtovy´ u´sek navı´c. Pokud vsˇak program v jazyku C chce alokovat naprˇ. 16 bajtu˚, ve skutecˇnosti potrˇebuje 16 + 4 = 20 a spotrˇebuje tedy 32 bajtu˚, stejneˇ jako by oneˇch 16 bajtu˚ alokoval prˇ´ımo z operacˇnı´ho syste´mu. Chova´nı´ MS-DOSu z dnesˇnı´ho hlediska jizˇ nenı´ podstatne´. Uva´dı´me jej zde proto, zˇe dı´ky sve´ jednoduchosti je tento model snadno prˇedstavitelny´.

86

Fragmentace znehodnotı´ zhruba trˇetinu pameˇti.

Ochrana pameˇti Prˇideˇlova´nı´ souvisly´ch u´seku˚ je za´kladnı´m modelem organizace pameˇti operacˇnı´m syste´mem a existuje k neˇmu take´ souvisejı´cı´ za´kladnı´ model ochrany pameˇti. Jak uzˇ vı´me z kapitoly 2.2.3, aby se proces dostal ke „sve´“ pameˇti, musı´ zna´t adresu pocˇa´tku neboli ba´zi sve´ho bloku. Tato je obvykle ulozˇena prˇ´ımo v procesoru ve specia´lnı´m registru. Proces pak pracuje pouze s posunutı´m (offsetem) od pocˇa´tku tohoto bloku. Ochrana pameˇti pak mu˚zˇe fungovat tak, zˇe ke kazˇde´mu ba´zove´mu registru je prˇida´n jesˇteˇ druhy´ registr, a ten urcˇuje velikost dane´ho bloku pameˇti. Operacˇnı´ syste´m se stara´ o spra´vne´ nastavenı´ teˇchto dvou registru˚ a hardware kontroluje, zˇe prˇ´ıstupy do pameˇti jsou jen v mezı´ch [ba´ze, ba´ze+limit] a zajisˇt’uje ochranu teˇchto dvou registru˚ – kdyby sa´m proces mohl nastavit libovolne´ hodnoty do teˇchto registru˚, pak by o ochraneˇ nemohla by´t rˇecˇ. Hardware tedy zajisˇt’uje i neˇjaky´ druh odstı´neˇnı´ u´rovneˇ procesu˚, cˇili doka´zˇe rozlisˇit, zda je ko´d vykona´va´n syste´movy´m, nebo uzˇivatelsky´m procesem. Jak uzˇ bylo zmı´neˇno vy´sˇe, i kdyzˇ le´ta popula´rnı´ syste´m MS-DOS ochranu pameˇti neposkytoval, procesory rˇady x86 ano a to uzˇ od varianty 80286 pouzˇite´ v prvnı´m modelu PC AT. Pru˚vodce studiem Pocˇ´ıtacˇe IBM PC existovaly v neˇkolika varianta´ch a pouzˇ´ıvaly ru˚zne´ modely procesoru˚ Intel rˇady x86. Varianta PC AT je ta, ktera´ se beˇhem let nejvı´ce rozsˇ´ırˇila a dnes jsou vsˇechny proda´vana´ „pı´sı´cˇka“ potomky pra´veˇ tohoto typu. Jizˇ pu˚vodnı´ pocˇ´ıtacˇ IBM PC/AT (1984) meˇl zmı´neˇny´ procesor Intel 80286 (1982), ktery´ podporuje hardwarovou ochranu pameˇti. Pu˚vodnı´ operacˇnı´ syste´m tohoto pocˇ´ıtacˇe byl vsˇak PC-DOS (prˇejmenovany´ MS-DOS) 3.0, ktery´ zˇa´dnou ochranu pameˇti nepodporoval.)

9.3

Stra´nkova´nı´

Alternativou k prˇideˇlova´nı´ souvisly´ch u´seku˚ pameˇti je stra´nkova´nı´, kdy mı´sto operacˇnı´ pameˇti ˇ esˇ´ı se tı´m proble´m vneˇjsˇ´ı fragmentace pameˇti, o ktere´m byla naopak „kouskujeme“ programy. R rˇecˇ vy´sˇe, prˇitom se za´rovenˇ otvı´ra´ cesta k vyuzˇitı´ pomocne´ cache na disku, kam lze odkla´dat me´neˇ vyuzˇ´ıvane´ cˇa´sti operacˇnı´ pameˇti. Pru˚vodce studiem Zastavme se u ota´zky, procˇ vy´sˇe popsany´ model souvisly´ch bloku˚ nedovoluje odkla´dat cˇa´st operacˇnı´ pameˇti na disk. Pokud bychom cˇa´st adresove´ho prostoru meˇli na disku, tak musı´me neˇjak ˇresˇit proble´m, zˇe prˇi samotne´m beˇhu potrˇebuje proces mı´t svou pameˇt’fyzicky v pameˇti, tedy ne na disku. Na disk se pameˇt’totizˇ skutecˇneˇ jen docˇasneˇ odkla´da´, program tam beˇzˇet nemu˚zˇe. Odkla´da´nı´ na disk bychom tedy museli rˇesˇit prˇesouva´nı´m bloku˚ pameˇti mezi ru˚zny´mi adresami – to by bylo potrˇeba deˇlat kopı´rova´nı´m, cozˇ je samo o sobeˇ pomale´, navı´c by vsˇechny programy musely by´t tvorˇene´ tak, aby pocˇ´ıtaly s tı´m, zˇe se jim libovolneˇ prˇi beˇhu mohou meˇnit adresy dat i ko´du. Toto pozˇadovane´ zobecneˇnı´ by zkomplikovalo ko´d programu˚. Pro operacˇnı´ syste´m by to take´ bylo mnoho pra´ce navı´c, protozˇe by musel prˇi kazˇde´m prˇesouva´nı´ bloku pameˇti z a na disk procha´zet cele´ programy a meˇnit vsˇechny adresy. To by pocˇ´ıtacˇ jesˇteˇ vı´ce zpomalilo a vyzˇa´dalo by si to dalsˇ´ı pameˇt’, kde by si operacˇnı´ syste´m evidoval vsˇechny adresy, kde se vyskytujı´ odkazy na jine´ adresy, ktere´ je trˇeba prˇi relokaci prˇepocˇ´ıtat. Vy´sledkem by byl operacˇnı´ syste´m, ktery´ by byl extre´mneˇ pomaly´ a usˇetrˇenou pameˇt’by navı´c z cˇa´sti zabı´ral svy´mi evidencˇnı´mi daty.

Stra´nkova´nı´ rusˇ´ı za´kladnı´ prˇ´ıcˇinu proble´mu vneˇjsˇ´ı fragmentace: Programy nynı´ jizˇ nejsou v souvisly´ch u´secı´ch pameˇti. Tı´m odpada´ ˇresˇenı´ nerˇesˇitelne´ho, tedy nenı´ jizˇ trˇeba rˇesˇit, do 87

Stra´nkova´nı´ rˇesˇ´ı vneˇjsˇ´ı fragmentaci.

ktere´ho z mnoha volny´ch u´seku˚ umı´stit novy´ program, aby to neˇkdy v budoucnu nezpu˚sobilo potı´zˇe. Za´kladnı´ model Fyzicky´ adresovy´ prostor je rozdeˇlen na u´seky stejne´ de´lky zvane´ ra´mce, logicky´ adresovy´ prostor je rozdeˇlen na u´seky stejne´ de´lky zvane´ stra´nky. Fyzicka´ i logicka´ adresa ma´ linea´rnı´ povahu. (Prostory ale mohou by´t rˇ´ıdke´, tj. neˇktere´ adresy mohou by´t vynechane´, protozˇe cela´ pameˇt’je slozˇenı´m rˇady dı´lcˇ´ıch pameˇtı´ v pocˇ´ıtacˇi, ktere´ na sebe cˇ´ısly adres nemusejı´ navazovat.) Stra´nka a ra´mec jsou pochopitelneˇ stejneˇ velke´. Fyzicky jsou v pocˇ´ıtacˇi tedy jen ra´mce, zatı´mco procesy vidı´ jen stra´nky. Je pochopitelne´, zˇe procesy se nestarajı´ o to, kde prˇesneˇ fyzicky jejich stra´nky jsou umı´steˇny.

Ra´mec je kus fyzicke´ pameˇti. Stra´nka je kus logicke´ pameˇti.

Obra´zek 14: Za´kladnı´ model stra´nkova´nı´. [SGG05] Stra´nkova´nı´ musı´ by´t implementova´no hardwaroveˇ, nebot’ prˇi kazˇde´ adresaci pameˇti je trˇeba co nejrychleji prˇelozˇit logickou adresu na fyzickou. Jak ukazuje obra´zek 14, syste´m udrzˇuje stra´nkovacı´ tabulku neboli tabulku stra´nek (page table), pomocı´ ktere´ pak hardware adresy prˇeva´dı´. Kazˇda´ logicka´ adresa se skla´da´ ze dvou cˇa´stı´, tj. neˇkolik bitu˚ pro cˇ´ıslo stra´nky p a neˇkolik bitu˚ pro offset. Cˇ´ıslo stra´nky se vezme jako index do stra´nkovacı´ tabulky a nahradı´ se tam ulozˇeny´m cˇ´ıslem ra´mce f , cˇ´ımzˇ je zı´ska´na fyzicka´ adresa. Velikost stra´nky je obvykle mocninou dvojky, rozdeˇlenı´ adresy na cˇ´ıslo stra´nky cˇi ra´mce a offset je pak velmi jednoduche´: je to urcˇity´ pocˇet bitu˚.

Stra´nkova´nı´ je vzˇdy hardwarove´.

Stra´nkova´nı´ a efektivita beˇhu programu˚ Zde popsany´ model na tom z hlediska efektivity na prvnı´ pohled nenı´ zrovna nejle´pe. Rˇesˇ´ı sice vneˇjsˇ´ı fragmentaci, ale vnitrˇnı´ fragmentace je v pru˚meˇru rovna polovineˇ velikosti stra´nky (tj. prˇi typicke´ velikosti stra´nky 4KB je to 2KB) na blok pameˇti. Samotny´ beˇh programu˚ je pomalejsˇ´ı, protozˇe prˇi kazˇde´ adresaci potrˇebujeme udeˇlat dva prˇ´ıstupy do pameˇti – poprve´ k nacˇtenı´ cˇ´ısla ra´mce ze stra´nkovacı´ tabulky, podruhe´ do samotne´ adresovane´ pameˇti. Prˇi pouzˇitı´ stra´nkova´nı´ jsou tedy programy teoreticky minima´lneˇ 2× pomalejsˇ´ı. V modernı´ch procesorech je vsˇak prˇekladu adres veˇnova´na zvla´sˇtnı´ pe´cˇe a za pomocı´ cache pameˇtı´ TLB (Translation 88

Stra´nka ma´ nejcˇasteˇji velikost 4KB.

Lookaside Buffer), kdy hodneˇ pouzˇ´ıvane´ cˇa´sti stra´nkovacı´ch tabulek jsou neusta´le v procesoru, a paralelnı´ho vykona´va´nı´ (viz pipelining, kap. 2.1.3 na str. 15) je dosazˇeno vy´sledne´ rychlosti blı´zˇ´ıcı´ se nestra´nkovane´mu prˇ´ıstupu do pameˇti. Vy´hody zı´skane´ stra´nkova´nı´m tak vy´razneˇ prˇevazˇujı´ a v praxi se skutecˇneˇ pouzˇ´ıva´. Pru˚vodce studiem TLB je zvla´sˇtnı´ druh cache pameˇti fungujı´cı´ jako asociativnı´ pole. Je to tedy obdoba hashovacı´ tabulky, ovsˇem implementovana´ zcela hardwaroveˇ – prˇi doda´nı´ klı´cˇe (cˇ´ısla stra´nky) je odpoveˇdı´ jemu odpovı´dajı´cı´ hodnota (cˇ´ıslo ra´mce). Je-li hodnota v tabulce, je odpoveˇd’ velmi rychla´ (cache hit). V opacˇne´m prˇ´ıpadeˇ je hodnota vyhleda´na ve skutecˇne´ tabulce a odpoveˇd’ je daleko pomalejsˇ´ı (cache miss). S kazˇdy´m cache miss dotazem se TLB aktualizuje doplneˇnı´m nove´ hodnoty a vyrˇazenı´m jedne´ stare´.

Stra´nkova´nı´ tedy umozˇnˇuje vyuzˇ´ıt vesˇkerou volnou pameˇt’bez vneˇjsˇ´ı fragmentace. Syste´m jizˇ nemusı´ rˇesˇit, ktery´ volny´ blok prˇideˇlit, protozˇe vsˇechny jsou doslova „stejneˇ dobre´“. Prˇi nedostatku pameˇti je mozˇno odkla´dat neˇktere´ stra´nky na disk. V tom prˇ´ıpadeˇ ke stra´nce neexistuje odpovı´dajı´cı´ ra´mec – rˇesˇ´ı se to za spolupra´ce s hardwarem tak, zˇe v okamzˇiku prˇ´ıstupu do stra´nky, ktera´ nema´ prˇirˇazen ra´mec, dojde k hardwarove´mu prˇerusˇenı´, operacˇnı´ syste´m nacˇte chybeˇjı´cı´ stra´nku do neˇjake´ho ra´mce a proces adresace se opakuje. Beˇzˇ´ıcı´ proces tedy ani nepozna´, zˇe nebyl v pameˇti – kdykoliv neˇjakou pameˇt’potrˇebuje, tak ji v pameˇti ma´. Aby bylo mozˇno nacˇ´ıst stra´nku odlozˇenou na disk zpeˇt do pameˇti, je obvykle trˇeba neˇkterou jinou stra´nku odlozˇit na disk. Stacˇ´ı tedy chybeˇjı´cı´ stra´nku vymeˇnit s neˇkterou jinou. Podrobneˇji se k te´to problematice vra´tı´me pozdeˇji. Adresa´rˇe stra´nek V za´jmu bezpecˇnosti (ochrany pameˇti) ma´ kazˇdy´ proces svou vlastnı´ stra´nkovacı´ tabulku. (Prˇesneˇji rˇecˇeno „mu˚zˇe mı´t vlastnı´“, protozˇe to za´visı´ cˇisteˇ na operacˇnı´m syste´mu a naprˇ. Windows 95 pouzˇ´ıva´ spolecˇnou stra´nkovacı´ tabulku pro vsˇechny procesy.) Podı´vejme se nynı´ na konkre´tnı´ cˇ´ısla: Na 32bitovy´ch pocˇ´ıtacˇ´ıch ma´ jeden za´znam v tabulce obvykle 4 bajty, to je 32 bitu˚, v syste´mu tedy mu˚zˇe by´t azˇ 232 ra´mcu˚. Prˇi standardnı´ velikosti ra´mce 4KB je to 32 bitu˚ pro cˇ´ıslo ra´mce plus 12 bitu˚ pro offset, tj. 44 bitu˚ celkem. V syste´mu tedy lze fyzicky adresovat azˇ 244 bajtu˚, tedy 16TB. 16TB znı´ peˇkneˇ, proble´mem vsˇak mu˚zˇe by´t samotna´ velikost stra´nkovacı´ tabulky. I prˇi omezenı´ na beˇzˇneˇjsˇ´ı 4GB limit ma´me 1M (220 ) stra´nek o velikosti 4KB (dohromady tedy 1M×4KB = 4GB). Jedna polozˇka tabulky ma´ 4 bajty (je to 32bitova´ adresa), takzˇe cela´ tabulka zabı´ra´ 4MB. Ma´me-li na pocˇ´ıtacˇi naprˇ. 50 procesu˚, pak jejich stra´nkovacı´ tabulky zabı´rajı´ 200MB bez ohledu na to, jak velkou pameˇt’vlastneˇ pocˇ´ıtacˇ fyzicky ma´. Pru˚vodce studiem Nezapomı´nejte, zˇe je sta´le rˇecˇ o operacˇnı´ pameˇti, nikoliv o pameˇti RAM. Proto jsou nespra´vne´ u´vahy typu: „Kdyzˇ ma´m v pocˇ´ıtacˇi jen 512MB RAM, pak mi stacˇ´ı mensˇ´ı stra´nkovacı´ tabulky.“ Pameˇt’RAM v podobeˇ DIMM modulu˚ do PC je sice nejzna´meˇjsˇ´ı, ale v pocˇ´ıtacˇi je obvykle take´ rˇada dalsˇ´ı pameˇti a jednotlive´ soucˇa´sti navı´c obvykle nevyplnˇujı´ adresovy´ prostor souvisle. Naprˇ. graficka´ karta ma´ beˇzˇneˇ 256MB nebo i vı´ce a mapuje je na adresy D0000000h (3/16 prˇed koncem prostoru, cˇili od 3328MB vy´sˇe).

Takove´ ply´tva´nı´ pameˇtı´ je samozrˇejmeˇ nezˇa´doucı´, proto se v praxi v rˇadeˇ syste´mu˚ pouzˇ´ıva´ dvoju´rovnˇovy´ model, ktery´ zabı´ra´ pameˇti me´neˇ. Namı´sto jedne´ stra´nkovacı´ tabulky ma´ kazˇdy´ 89

Adresa´rˇe sˇetrˇ´ı pameˇt’.

proces rˇadu stra´nkovacı´ch tabulek, kde kazˇda´ popisuje cˇa´st adresove´ho prostoru. Pokud vsˇak neˇjakou cˇa´st adres nepouzˇ´ıva´, dana´ stra´nkovacı´ tabulka neexistuje, tedy nezabı´ra´ pameˇt’. Stra´nkova´nı´ je dvouu´rovnˇove´ – cˇa´st adresy urcˇuje cˇ´ıslo stra´nkovacı´ tabulky, dalsˇ´ı cˇa´st pak index do te´to tabulky a zbytek je offset. Prˇi velikosti stra´nky 4KB mu˚zˇe by´t naprˇ. 10 bitu˚ pro cˇ´ıslo tabulky, 10 bitu˚ pro index v tabulce a 12 bitu˚ pro offset. Celkoveˇ ma´ adresova´nı´ stejne´ schopnosti jako vy´sˇe, avsˇak adresovy´ prostor je popsa´n pomocı´ 1024 stra´nkovacı´ch tabulek, kde pouze ty odpovı´dajı´cı´ vyuzˇity´m adresa´m existujı´. Kazˇdy´ stra´nkovacı´ tabulka ma´ tedy 1024 polozˇek (210 ) o 4 bajtech, cˇili zabı´ra´ pra´veˇ jednu stra´nku. Adresa´rˇ stra´nek ma´ taky 1024 polozˇek o 4 bajtech, tedy take´ jednu stra´nku. V tomto prˇ´ıpadeˇ tedy do sebe vsˇe velmi dobrˇe zapada´, proto se tento model v te´to podobeˇ pouzˇ´ıva´ i v praxi, jak si uka´zˇeme nı´zˇe. Ochrana pameˇti Ochranu pameˇti na u´rovni stra´nkova´nı´ lze realizovat pomocı´ bitu (opra´vneˇnı´) prˇ´ıstupu ulozˇene´ho ve stra´nkovacı´ tabulce. Tento jeden vyhrazeny´ bit pak urcˇuje, zda je ra´mec prˇ´ıstupny´ jen pro cˇtenı´, nebo i pro za´pis. Prˇi kazˇde´m prˇekladu adres je pak bit prˇecˇteny´ a pouzˇity´ da´le prˇi pra´ci s touto adresou. Toto lze rozsˇ´ırˇit i na vı´ce stavu˚, naprˇ. pro zvla´sˇtnı´ oznacˇenı´ pameˇti, ve ktere´ je povoleno vykona´vat ko´d. Podobneˇ je mozˇno jednı´m stavem oznacˇit stra´nky, ktere´ jsou zcela neplatne´ (neexistujı´cı´) a nenı´ k nim vu˚bec povolen prˇ´ıstup. Neexistujı´cı´ stra´nky lze take´ rˇesˇit pomocı´ omezenı´ velikosti stra´nkovacı´ tabulky (cˇi adresa´rˇe stra´nek, je-li pouzˇ´ıva´n), nejle´pe jednodusˇe pouzˇitı´m specia´lnı´ho registru, ktery´ ponese pocˇet platny´ch za´znamu˚ ve stra´nkovacı´ tabulce. (Pro oznacˇenı´ stra´nky jednı´m ze cˇtyrˇ uvedeny´ch stavu˚ na´m tedy stacˇ´ı dva bity.) Syste´m IBM/360 pouzˇ´ıval na u´rovni stra´nkova´nı´ ochranu typu za´mek a klı´cˇ – kazˇdy´ proces ma´ svu˚j 4bitovy´ identifika´tor (klı´cˇ) a kazˇda´ stra´nka ma´ v tabulce take´ 4bitovy´ identifika´tor (za´mek). Prˇ´ıstup do pameˇti je povolen jen tehdy, kdyzˇ se klı´cˇ a za´mek shodujı´, nebo kdyzˇ jde o univerza´lnı´ klı´cˇ (cˇ´ıslo 0 – proces ja´dra). Tı´mto zpu˚sobem mohou procesy (jmenoviteˇ azˇ 15 procesu˚) sdı´let spolecˇnou stra´nkovacı´ tabulku. Dodejme jesˇteˇ, zˇe procesory typu x86 tento zpu˚sob ochrany pameˇti na u´rovni stra´nek nepouzˇ´ıvajı´, zatı´mco procesory noveˇjsˇ´ı rˇady x64 ano. Jeden bit je tam vyhrazen pro NX (no–execute, take´ znacˇeno XD jako execute disable), jeho nastavenı´m je zaka´za´no v dane´ stra´nce prova´deˇt ko´d. Tato ochrana je zameˇrˇena zejme´na proti viru˚m – znemozˇnˇuje totizˇ model zavedenı´ sˇkodlive´ho ko´du prˇetecˇenı´m bufferu (buffer overflow), kdy se prˇeplneˇnı´m bufferu zapı´sˇe do oblasti dat (konkre´tneˇ za´sobnı´ku) procesu sˇkodlivy´ ko´d a za´rovenˇ se za´sobnı´k zmeˇnı´ tak, aby se prˇi na´vratu z vola´nı´ (ret) prˇeneslo rˇ´ızenı´ na adresu obsahujı´cı´ tento sˇkodlivy´ ko´d. Je-li v datovy´ch stra´nka´ch zaka´za´no prova´deˇnı´ ko´du, tento typ u´toku nenı´ mozˇny´.

9.4

Princip lokality

Jak jsme si jizˇ naznacˇili vy´sˇe, slozˇite´ adresovacı´ mechanizmy modernı´ch pocˇ´ıtacˇu˚ by se neobesˇly bez TLB, ktery´ zrychluje jinak slozˇite´ vy´pocˇty tı´m, zˇe prˇi opakovane´m prˇ´ıstupu do stejne´ oblasti pameˇti se nemusı´ pro prˇeklad adresy vu˚bec cˇ´ıst skutecˇna´ stra´nkovacı´ tabulka. Vyuzˇ´ıva´nı´ tohoto druhu cache soucˇasneˇ prˇina´sˇ´ı mozˇnost a za´rovenˇ vı´ceme´neˇ nutnost pouzˇ´ıvat takove´ modely programova´nı´, ktere´ v urcˇite´m kra´tke´m cˇasove´m u´seku vyuzˇ´ıvajı´ data a ko´d umı´steˇne´ prˇedevsˇ´ım na jednom mı´steˇ v pameˇti. Pokud totizˇ toto platı´, program beˇzˇ´ı rychleji. Tuto vlastnost ma´ pouzˇ´ıva´nı´ loka´lnı´ch promeˇnny´ch ve funkcı´ch a take´ objektoveˇ orientovane´ programova´nı´ – v urcˇite´m kra´tke´m cˇasove´m u´seku se tam pouzˇ´ıvajı´ prˇedevsˇ´ım loka´lnı´ promeˇnne´ umı´steˇne´ na jednom mı´steˇ na za´sobnı´ku respektive data jednoho objektu, jehozˇ metoda pra´veˇ beˇzˇ´ı.

90

NX bit chra´nı´ proti zneuzˇitı´ prˇetecˇenı´ bufferu.

Pru˚vodce studiem Princip lokality prˇ´ıstupu do pameˇti je neˇco podobne´ho jako spojitost funkce v bodeˇ v matematice: Princip lokality znamena´, zˇe v neˇjake´m dostatecˇneˇ male´m cˇasove´m u´seku se program pohybuje jen v male´m omezene´m prostoru pameˇti – to se ty´ka´ jak ko´du, tak dat. (Obvykle, tj. ne nutneˇ vzˇdy.)

Podı´vejme se nynı´, kolik cˇasu pouzˇ´ıva´nı´ TLB usˇetrˇ´ı. Prˇ´ıstup do pameˇti bez TLB znamena´ vzˇdy dvojı´ cˇtenı´ pameˇti plus hleda´nı´ v tabulce stra´nek. Program je tedy vı´ce nezˇ 2× pomalejsˇ´ı. Rychlost hleda´nı´ v TLB se lisˇ´ı podle toho, zda je hledana´ hodnota nalezena, cˇi nikoliv. Prˇi cache hit se cˇas potrˇebny´ k nalezenı´ blı´zˇ´ı nule, prˇi cache miss se opeˇt prˇistupuje 2× do pameˇti. Celkova´ rychlost pak za´visı´ na pomeˇru cache hits : cache misses, ten je empiricky zjisˇteˇn kolem 99:1, tj. 99% prˇ´ıstupu˚ je cache hits. Tento pomeˇr samozrˇejmeˇ hodneˇ za´visı´ na zvolene´m programovacı´m paradigmatu – paradigmata podporujı´cı´ princip lokality jsou zde pochopitelneˇ ve vy´hodeˇ. Je-li naprˇ. cˇas potrˇebny´ k prˇekladu adresy prˇi cache hit 1.5T a prˇi cache miss 30T, pak pru˚meˇrny´ cˇas prˇi 99% u´speˇsˇnosti je 0.99 · 1.5 + 0.01 · 30 = 1.785T . Ve skutecˇnosti pak do hry vstupuje jesˇteˇ pipelining, protozˇe modernı´ procesory se snazˇ´ı vypocˇ´ıta´vat adresy v prˇedstihu. Prˇi cache hit je potrˇebny´ cˇas prˇekladu 0T a prˇi cache miss mu˚zˇe by´t cca. 10T nebo i vı´ce, ale za´visı´ zejme´na na podı´lu miss prˇ´ıpadu˚ – cˇ´ım me´neˇ jich je, tı´m je rychlost veˇtsˇ´ı dı´ky pipeliningu. (Tyto odhady berte jen jako cˇisteˇ prˇiblizˇne´.)

9.5

Stra´nkova´nı´ na 64bitovy´ch procesorech

V sekci 9.3 jsme si uka´zali efektivnı´ zpu˚sob implementace stra´nkova´nı´ pomocı´ dvoju´rovnˇovy´ch stra´nkovacı´ch tabulek, kde 32bitova´ adresa je rozlozˇena na 10 + 10 + 12 bitu˚ a adresa´rˇ stra´nek i jednotlive´ stra´nkovacı´ tabulky obsahujı´ 1024 polozˇek a jsou tedy velke´ prˇesneˇ jeden ra´mec (4KB). Jak uva´dı´ [SGG05], na 64bitovy´ch pocˇ´ıtacˇ´ıch tento model nebude fungovat, protozˇe prˇi zachova´nı´ 10 + 12 bitu˚ pro stra´nkovacı´ tabulku a offset zby´va´ 64 − 22 = 42 bitu˚ pro adresa´rˇ stra´nek. Polozˇky musejı´ by´t 8bajtove´, takzˇe celkova´ velikost adresa´rˇe je azˇ 245 bajtu˚ (32TB) pro kazˇdy´ proces. Situaci lze rˇesˇit zavedenı´m dalsˇ´ı u´rovneˇ tabulek, cˇili adresu rozdeˇlı´me na trˇi cˇa´sti indexu˚ do tabulek plus offset, tedy naprˇ. 32 + 10 + 10 + 12. Prvnı´ tabulka ma´ sta´le 32bitove´ indexy, cˇili zabı´ra´ azˇ 235 bitu˚ (32GB). Prˇi pouzˇ´ıva´nı´ troju´rovnˇovy´ch tabulek se take´ proporciona´lneˇ zpomaluje prˇeklad adresy prˇi cache miss. Mu˚zˇeme samozrˇejmeˇ prˇidat jesˇteˇ cˇtvrtou u´rovenˇ tabulek, pak ma´ nejveˇtsˇ´ı z nich „maxima´lneˇ“ 32MB. Ve vsˇech prˇ´ıpadech prˇedpokla´da´me stra´nkovacı´ tabulky o velikosti 8KB (1024× 8 bajtu˚). Pru˚vodce studiem Vy´pocˇty v prˇedchozı´ch odstavcı´ch jsou odvozeny od informacı´ v knize [SGG05], jsou zde vsˇak opraveny neˇktere´ tam se vyskytujı´cı´ chyby. Cela´ teorie je vsˇak poneˇkud mimo realitu, nebot’prˇedpokla´da´ vyuzˇ´ıva´nı´ 64bitovy´ch pocˇ´ıtacˇu˚, ktere´ pouzˇ´ıvajı´ cely´ 64bitovy´ adresovacı´ prostor, majı´ zhruba 264 fyzicke´ pameˇti a kazˇdy´ proces zhruba (rˇa´doveˇ) tolik pameˇti pouzˇ´ıva´ i sa´m pro sebe. Tato prˇedstava vsˇak naprosto neodpovı´da´ soucˇasne´ rea´lne´ situaci, kdy 64bitove´ pocˇ´ıtacˇe majı´ sice 64bitove´ adresova´nı´, avsˇak skutecˇne´ velikosti pameˇtı´ se blı´zˇ´ı teˇm 32bitovy´m. Proto lze vyvodit, zˇe take´ adresovacı´ algoritmy u soucˇasny´ch 64bitovy´ch procesoru˚ mohou bez proble´mu˚ by´t stejne´ jako u procesoru˚ 32bitovy´ch. Stra´nkovacı´ syste´m skutecˇne´ho 64bitove´ho procesoru typu x64 probereme podrobneˇji v kapitole 11.3 na straneˇ 119.

91

Kromeˇ zde diskutovane´ho hierarchicke´ho syste´mu adresovacı´ch tabulek, kdy se pro prˇeklad pouzˇ´ıva´ linea´rnı´ rˇada tabulek, existujı´ i dalsˇ´ı alternativy, jako naprˇ. hashovane´ stra´nkovacı´ tabulky nebo clusterovane´ stra´nkovacı´ tabulky. Tyto metody jsou vhodneˇjsˇ´ı pro rˇ´ıdke´ obsazenı´ adresovacı´ho prostoru. Soucˇasne´ 64bitove´ procesory vsˇak sta´le vystacˇ´ı s linea´rnı´m modelem, naprˇ. nejbeˇzˇneˇjsˇ´ı procesory rˇady x64 pouzˇ´ıvajı´ cˇtyrˇu´rovnˇovy´ hierarchicky´ syste´m tabulek; podrobneˇji si stra´nkova´nı´ na teˇchto procesorech prˇedstavı´me da´le v textu. Pru˚vodce studiem Mı´cha´nı´ slov hierarchicky´ a linea´rnı´ by mohlo by´t matoucı´, proto si jej vysveˇtleme: Rˇecˇ je porˇa´d o stejne´m modelu stra´nkova´nı´ pameˇti. Syste´m adresovacı´ch tabulek je hierarchicky´, protozˇe stra´nkovacı´ tabulky jsou usporˇa´da´ny v hierarchii (ve stromu). Prˇeklad adres pouzˇ´ıvajı´cı´ tento model je pak linea´rnı´, protozˇe prˇi prˇekladu cˇteme tabulky linea´rneˇ – vzˇdy jednu na kazˇde´ u´rovni hierarchie.

9.6

Segmentove´ adresova´nı´ (segmentace)

Se segmentovy´m adresova´nı´m jsme se jizˇ sezna´mili v kapitole 2, nynı´ se k neˇmu vra´tı´me v kontextu novy´ch znalostı´. Prˇipomenˇme nejprve, zˇe segmentove´ adresova´nı´ funguje tak, zˇe proces ma´ pameˇt’rozdeˇlenou do neˇkolika segmentu˚, obvykle nejme´neˇ na ko´d, data a za´sobnı´k. Dalsˇ´ı segmenty je pak mozˇno pouzˇ´ıt pro dalsˇ´ı data. Pro lepsˇ´ı pochopenı´ syste´mu organizace pameˇti si popisˇme souvislost segmentace a stra´nkova´nı´. Pouzˇ´ıva´-li pocˇ´ıtacˇ segmentaci i stra´nkova´nı´ dohromady, cozˇ je beˇzˇne´ naprˇ. na procesorech typu x86, pak prˇeklad linea´rnı´ch adres na fyzicke´ probı´ha´ standardnı´m zpu˚sobem, jak bylo popsa´no v te´to kapitole (a podrobnosti budou jesˇteˇ diskutova´ny da´le). Samotne´ programy vsˇak nepracujı´ prˇ´ımo s linea´rnı´ adresou, ny´brzˇ pouzˇ´ıvajı´ logickou adresu ve formeˇ segment + offset. Segment je popsa´n segmentovy´m registrem tak, jak jsme si uvedli v kapitole 2 a prˇi beˇzˇny´ch operacı´ch program pracuje jen s offsetem. K neˇmu se prˇi pra´ci s pameˇtı´ automaticky prˇipocˇ´ıta´va´ ba´ze segmentu a tı´m teprve z logicke´ adresy vznika´ linea´rnı´ adresa, ktera´ se mapuje na fyzickou (bud’ prˇ´ımo, nebo pomocı´ stra´nkova´nı´). Pru˚vodce studiem Segmentaci lze pouzˇ´ıvat i samostatneˇ, bez stra´nkova´nı´. Segmentace sama o sobeˇ je totizˇ mozˇny´m rˇesˇenı´m spra´vy pameˇti. Tento model vsˇak podrobneˇji nediskutujeme, nebot’ se jedna´ jen o konkre´tnı´ implementaci modelu prˇideˇlova´nı´ souvisly´ch u´seku˚ pameˇti.

Ochrana pameˇti V sekci 9.3 jsme k ochraneˇ pameˇti na straneˇ 90 uvedli, zˇe procesory x86 tam popsany´ zpu˚sob ochrany na u´rovni stra´nkova´nı´ nepouzˇ´ıvajı´. Jelikozˇ vesˇkery´ prˇ´ıstup do pameˇti jde prˇes segmentove´ registry, ochrana pameˇti je na teˇchto procesorech realizova´na pra´veˇ na u´rovni segmentu˚. Cely´ segment ma´ tedy vzhledem k pameˇti stejna´ pra´va. Za´kladnı´ ochranou je stanovenı´ dolnı´ a hornı´ hranice segmentu v jeho deskriptoru, takzˇe se vu˚bec nelze dostat mimo prˇideˇlenou pameˇt’. Dolnı´ hranice segmentu mu˚zˇe by´t na libovolne´m bajtu linea´rnı´ho prostoru a hornı´ limit pameˇti mu˚zˇe by´t bud’ prˇ´ımo v bajtech (max. 1MB), nebo ve stra´nka´ch (max. 4GB). Nizˇsˇ´ı rozlisˇovacı´ schopnost u hornı´ho limitu je zpu˚sobena nizˇsˇ´ım pocˇtem bitu˚ vyhrazeny´m pro tento u´daj. V deskriptoru lze nastavit jesˇteˇ neˇkolik prˇ´ıznaku˚, ochranu pameˇti ovlivnˇuje DPL (descriptor privilege level), ktery´m lze nastavit pozˇadovanou u´rovenˇ procesu pro prˇ´ıstup k segmentu3 . 3 Deskriptory mohou popisovat i jine´ prostrˇedky pouzˇ´ıvane´ procesorem nezˇ segmenty. DPL tedy chra´nı´ prˇ´ıstup k ru˚zny´m prostrˇedku˚m, ne jen k pameˇti.

92

Nastavenı´m nuly povolı´me prˇ´ıstup jen ja´dru operacˇnı´ho syste´mu. Nulova´nı´m bitu P (segment present) se oznacˇujı´ zcela neplatne´ segmenty. Pomocı´ segmentova´nı´ lze na 32bitovy´ch procesorech x86 vyuzˇ´ıt i vı´ce nezˇ 232 bajtu˚ (4GB) pameˇti. V praxi se vsˇak tato mozˇnost veˇtsˇinou nepouzˇ´ıva´ a hlavnı´ vy´hodou zavedenı´ segmentu˚ je tedy pra´veˇ ochrana pameˇti na nich zalozˇena´. (Prˇipomenˇme, zˇe v 16bitove´m rezˇimu, naprˇ. v syste´mu MS-DOS, byla hlavnı´ vy´hodou zavedenı´ segmentu˚ naopak mozˇnost vyuzˇ´ıt veˇtsˇ´ı mnozˇstvı´ pameˇti nezˇ 216 bajtu˚.) K problematice vyuzˇitı´ segmentu˚ prˇi adresova´nı´ velke´ pameˇti se jesˇteˇ vra´tı´me v kapitole 11.1.3 na straneˇ 111.

9.7

Copy–on–write

Zastavme se nynı´ u mozˇnosti sdı´let pameˇt’. Z hlediska procesu˚ mu˚zˇe by´t zajı´mave´, kdyzˇ spolu mohou komunikovat a/nebo spolupracovat pomocı´ sdı´lene´ pameˇti. Z hlediska operacˇnı´ho syste´mu je vsˇak zajı´maveˇjsˇ´ı dı´vat se na sdı´lenı´ pameˇti jakozˇto prostrˇedek vedoucı´ k u´sporˇe: Je-li spusˇteˇn neˇjaky´ program vı´cekra´t, pak sdı´lenı´m ko´du lze usˇetrˇit i pomeˇrneˇ hodneˇ pameˇti. Programy jsou ne na´hodou v mnoha syste´mech cˇleneˇny na tzv. knihovny, ty jsou umı´steˇne´ v samostatny´ch souborech a je take´ vy´hodne´ je sdı´let. Sdı´lenı´ stra´nek pameˇti realizuje syste´m jednodusˇe tak, zˇe tyto stra´nky nava´zˇe na stejne´ ra´mce. Syste´m vsˇak samozrˇejmeˇ ma´ jistou pra´ci navı´c s evidencı´ sdı´lene´ pameˇti – prˇi jake´koliv operaci s ra´mcem je potrˇeba zmeˇny zane´st do vsˇech procesu˚, ktere´ ra´mec pouzˇ´ıvajı´. Sdı´let prˇitom lze jak pameˇt’ko´du, tak pameˇt’dat. Dva ru˚zne´ programy mohou sdı´let neˇktere´ knihovny. Prˇ´ıkladem mu˚zˇe by´t Microsoft Word a Microsoft Excel – ty dva kancela´rˇske´ programy proda´vane´ spolecˇneˇ majı´ mnoho spolecˇne´ho a take´ sdı´lejı´ velke´ mnozˇstvı´ spolecˇne´ho ko´du. Dı´ky schopnosti sdı´let pameˇt’ usˇetrˇ´ı operacˇnı´ syste´m prˇi soucˇasne´m spusˇteˇnı´ teˇchto dvou programu˚ mnoho pameˇti. A kromeˇ u´spory pameˇti samozrˇejmeˇ docha´zı´ i k u´sporˇe cˇasu prˇi startu programu, ktery´ pouzˇ´ıva´ knihovny, ktere´ jizˇ jsou v pameˇti. Pro operacˇnı´ syste´m to samozrˇejmeˇ znamena´ ve´st si evidenci souboru˚, ktere´ jsou jizˇ v pameˇti, aby mohl sdı´lenı´ prova´deˇt automaticky. Copy–on–write je specia´lnı´ technika sdı´lenı´ pameˇti, kterou nejle´pe vysveˇtlı´me na prˇ´ıkladu unixove´ funkce fork. Prˇipomenˇme, zˇe tato funkce zdvojı´ proces a ten pak pokracˇuje na stejne´m mı´steˇ ko´du ve dvou exempla´rˇ´ıch, ktere´ se navza´jem doka´zˇ´ı rozlisˇit pomocı´ na´vratove´ hodnoty te´to funkce. Prˇi vola´nı´ fork syste´m musı´ zajistit, zˇe kazˇda´ z kopiı´ procesu bude mı´t vlastnı´ ko´d i data tak, aby se dva procesy navza´jem prˇi dalsˇ´ım beˇhu nechteˇneˇ neovlivnˇovaly. Namı´sto toho, aby syste´m prˇi vola´nı´ fork slozˇiteˇ a zdlouhaveˇ duplikoval vesˇkerou pameˇt’procesu, oznacˇ´ı pameˇt’ko´du jako sdı´lenou a pameˇt’dat jako copy–on–write. Jelikozˇ se ko´d prˇi beˇhu nemeˇnı´, oba procesy budou sdı´let stejnou kopii. Data se meˇnit mohou, ale nemusı´; oznacˇenı´ copy–on–write zajistı´, zˇe jednotlive´ stra´nky dat se duplikujı´ azˇ prˇi prvnı´m pokusu o jejich zmeˇnu. Copy–on–write je mozˇno implementovat pomeˇrneˇ jednodusˇe na syste´mech podporujı´cı´ ochranu pameˇti prˇed za´pisem. Copy–on–write stra´nky syste´m oznacˇ´ı jako read–only (jen pro cˇtenı´) a eviduje si, ktere´ stra´nky to jsou. Prˇi pokusu procesu o za´pis do takto chra´neˇne´ pameˇti dojde k vy´jimce a prˇerusˇenı´ access violation (nepovoleny´ prˇ´ıstup). Syste´m v obsluze te´to vy´jimky projde seznam evidovany´ch copy–on–write stra´nek a pokud najde za´znam, tak stra´nce alokuje dalsˇ´ı ra´mec, okopı´ruje ji tam, zrusˇ´ı aktua´lnı´mu procesu sdı´lenı´ a povolı´ mu za´pis. Zbyde-li u pu˚vodnı´ stra´nky poslednı´ proces, ktery´ ji uzˇ s niky´m nesdı´lı´, syste´m mu rovneˇzˇ povolı´ do stra´nky za´pis. Z pohledu uzˇivatelske´ho procesu je tedy copy–on-write transparentnı´. Vzhledem k tomu, zˇe po vola´nı´ fork velmi cˇasto nacˇteme do procesu jiny´ program, je copy–on–write take´ velmi efektivnı´ z hlediska u´spory pameˇti i vy´pocˇetnı´ho cˇasu. I v prˇ´ıpadeˇ, zˇe nedojde k nacˇtenı´ nove´ho programu do procesu, se dı´ky copy–on–write usˇetrˇ´ı mnoho pameˇti pro data, ktera´ procesy nebudou meˇnit (naprˇ. globa´lnı´ konstanty, ale take´ prostor za´sobnı´ku nad mı´stem rozdeˇlenı´). Copy–on–write se pouzˇ´ıva´ take´ prˇi ladeˇnı´ ko´du. Prˇi ladeˇnı´ vkla´da´ debugger tzv. break pointy (ladicı´ body zastavenı´) do ko´du tak, zˇe na prˇ´ıslusˇna´ mı´sta vkla´da´ instrukci, ktera´ zpu˚sobı´ 93

Copy–on–write sˇetrˇ´ı pameˇt’prˇi sdı´lenı´.

vy´jimku/prˇerusˇenı´ a beˇh procesu je v dane´m mı´steˇ zastaven. Ma´me-li spusˇteˇno vı´ce programu˚ pouzˇ´ıvajı´cı´ch knihovnu, kterou takto ladı´me, pomocı´ copy–on–write je vytvorˇena kopie pro ladeˇny´ proces. Ostatnı´ procesy tedy beˇzˇ´ı da´le a pouze jeden zvoleny´ ladı´me. Ve Windows NT se ke spousˇteˇnı´ procesu˚ (obvykle) nepouzˇ´ıva´ fork; proces startujeme prˇ´ımo uvedenı´m spustitelne´ho souboru ve funkci CreateProcess. NT prˇi spousˇteˇnı´ libovolne´ho souboru (platı´ pro EXE i DLL) tento mapuje do pameˇti a pamatuje si, kde v pameˇti tento soubor je. Prˇi potrˇebeˇ stejne´ho souboru jiny´m procesem pak syste´m jizˇ jen odka´zˇe na mı´sto, kam je soubor namapova´n. Aby bylo mozˇno mapovat i soubory, ktere´ potrˇebujeme meˇnit, mapova´nı´ pouzˇ´ıva´ princip copy–on–write. Jak si uka´zˇeme v na´sledujı´cı´ kapitole o virtua´lnı´ pameˇti, syste´m mapova´nı´ souboru˚ navı´c nacˇ´ıta´ do pameˇti jen ty cˇa´sti souboru˚, ktere´ procesy skutecˇneˇ pouzˇ´ıvajı´. Takzˇe ma´me-li namapovany´ velky´ soubor, ze ktere´ho pouzˇ´ıva´me jen malou cˇa´st, syste´m si eviduje, zˇe soubor je mapova´n do pameˇti, eviduje si take´, kam je mapova´n, ale ty cˇa´sti souboru, ktere´ nepouzˇ´ıva´me, ve skutecˇnosti vu˚bec nezabı´rajı´ pameˇt’ a tato mu˚zˇe by´t pouzˇita pro jine´ u´cˇely. Jedna´ se tedy o propracovany´ syste´m, kde vsˇechno souvisı´ se vsˇ´ım; na dalsˇ´ı podrobnosti se jesˇteˇ podı´va´me pozdeˇji. Shrnutı´ Tato kapitola uvedla blok vy´uky zameˇrˇeny´ na organizaci a spra´vu operacˇnı´ pameˇti. V u´vodu jsme se sezna´mili se za´kladnı´mi u´koly spra´vy pameˇti, ktery´mi je evidence prostoru volne´ho a prˇideˇlene´ho procesu˚m, prˇideˇlova´nı´ a uvolnˇova´nı´ pameˇti procesu˚m, ochrana prˇideˇlene´ho prostoru a realizace virtua´lnı´ pameˇti. Da´le jsme si prˇedstavili model spra´vy pameˇti vyuzˇ´ıvajı´cı´ prˇideˇlova´nı´ souvisly´ch u´seku˚, ktery´ se v ru˚zny´ch varianta´ch pouzˇ´ıval prˇedevsˇ´ım v minulosti. Jeho alternativou pouzˇ´ıvanou v soucˇasny´ch pocˇ´ıtacˇ´ıch je stra´nkova´nı´, ktere´ odstranˇuje vneˇjsˇ´ı fragmentaci – za´kladnı´ nevy´hodu modelu pracujı´cı´ho na ba´zi souvisly´ch u´seku˚. Sezna´mili jsme se take´ s principem lokality, ktery´ vysveˇtluje, procˇ programy vyuzˇ´ıvajı´cı´ prˇedevsˇ´ım loka´lnı´ promeˇnne´ a objektoveˇ orientovane´ programy jsou na stra´nkujı´cı´ch pocˇ´ıtacˇ´ıch rychlejsˇ´ı. Da´le jsme si prˇipomneˇli pojem segmentace a umı´stili ho do kontextu se spra´vou pameˇti a stra´nkova´nı´m. V pru˚beˇhu kapitoly jsme se veˇnovali take´ problematice ochrany pameˇti; pro lepsˇ´ı srozumitelnost jsme ji diskutovali pru˚beˇzˇneˇ u kazˇde´ho modelu spra´vy. V na´sledujı´cı´ kapitole budeme pokracˇovat dalsˇ´ım modelem spra´vy pameˇti vyuzˇ´ıvajı´cı´m virtua´lnı´ pameˇt’. Pojmy k zapamatova´nı´ • • • • • • • • • • • • • • •

adresovy´ prostor ochrana pameˇti vnitrˇnı´ fragmentace vneˇjsˇ´ı fragmentace ba´ze a posunutı´ (offset) stra´nkova´nı´ ra´mec stra´nka stra´nkovacı´ tabulka TLB (translation look–aside buffer) hierarchicky´ syste´m stra´nkovacı´ch tabulek adresa´rˇ stra´nek za´mek a klı´cˇ NX bit (no–execute) segmentove´ adresova´nı´ (segmentace) 94

• copy–on–write Kontrolnı´ ota´zky 1. Jake´ jsou za´kladnı´ funkce spra´vy pameˇti v operacˇnı´m syste´mu? 2. Vysveˇtlete pojmy vneˇjsˇ´ı a vnitrˇnı´ fragmentace. 3. V textu byly popsa´ny trˇi algoritmy prˇideˇlova´nı´ pameˇti prˇi pouzˇ´ıva´nı´ souvisly´ch bloku˚: first fit, best fit, worst fit. Ktery´ z nich je nejlepsˇ´ı? Proved’te diskuzi. 4. Jaka´ velikost stra´nek se obvykle pouzˇ´ıva´? 5. Vysveˇtlete, procˇ prˇi stra´nkova´nı´ nevznika´ vneˇjsˇ´ı fragmentace. 6. Popisˇte vztah segmentace a stra´nkova´nı´ pameˇti. 7. Jake´ proble´my prˇina´sˇ´ı segmentace v programovacı´ch jazycı´ch pouzˇ´ıvajı´cı´ch pointery? Procˇ se s teˇmito proble´my v praxi dnes jizˇ setka´va´me ma´lo? 8. Jaky´m zpu˚sobem mu˚zˇe by´t implementova´na ochrana pameˇti na u´rovni stra´nkova´nı´? 9. Jaky´m zpu˚sobem mu˚zˇe by´t implementova´na ochrana pameˇti na u´rovni segmentace? 10. Co je to copy–on–write a co k tomu musı´ hardware umeˇt? 11. Procˇ jsou v praxi pouzˇ´ıvane´ velikosti stra´nek vzˇdy mocninou dvojky? 12. Co bude vy´sledkem, kdyzˇ povolı´me, aby vı´ce stra´nek odkazovalo na stejny´ ra´mec? Popisˇte, jak to mu˚zˇe zrychlit kopı´rova´nı´ pameˇti. 13. Popisˇte, jaky´m zpu˚sobem mohou dva procesy sdı´let stejny´ segment. Cvicˇenı´ 1. Dokazˇte, zˇe vnitrˇnı´ fragmentace prˇi stra´nkova´nı´ je rovna jedne´ polovineˇ velikosti stra´nky. 2. Ukazˇte, zˇe prˇi vhodneˇ zvolene´ velikosti stra´nek a stra´nkovacı´ch tabulek vsˇechny datove´ struktury pasujı´ do cely´ch stra´nek a vsˇechny bity jsou uzˇitecˇneˇ vyuzˇity. 3. Meˇjme logicky´ adresovy´ prostor velikosti 8 stra´nek o 1024 bajtech a fyzicky´ adresovy´ prostor o 32 ra´mcı´ch. Kolikabitove´ jsou zde logicke´ a fyzicke´ adresy? 4. Ma´te-li ve sve´m pocˇ´ıtacˇi Windows, prohle´dneˇte si ve spra´vci zarˇ´ızenı´ (stiskneˇte Win– Break, potom karta Hardware −→ Spra´vce zarˇ´ızenı´), jake´ rozsahy adres a dalsˇ´ı prostrˇedky va´sˇ pocˇ´ıtacˇ pouzˇ´ıva´. Kazˇde´ zarˇ´ızenı´, ktere´ ma´ vlastnı´ pameˇt’ cˇi mapuje sve´ sluzˇby do adresove´ho prostoru, ma´ zverˇejneˇny´ rozsah pouzˇity´ch adres. Viz obra´zek 15. Vsˇimneˇte si, zˇe u jednotlivy´ch zarˇ´ızenı´ se tyto prostory veˇtsˇinou nesmeˇjı´ prˇekry´vat.

95

Obra´zek 15: Prostrˇedky pouzˇite´ grafickou kartou

96

10

Virtua´lnı´ pameˇt’

ˇ ecˇ bude o virtua´lnı´ pameˇti, cozˇ Studijnı´ cı´le: V te´to kapitole nava´zˇeme na kapitolu prˇedchozı´. R je dalsˇ´ı model spra´vy pameˇti, jehozˇ cı´lem je umozˇnit vyuzˇitı´ diskove´ho prostoru pro odkla´da´nı´ me´neˇ pouzˇ´ıvany´ch dat z fyzicke´ pameˇti. Klı´cˇova´ slova: virtua´lnı´ pameˇt’, vy´meˇna ra´mcu˚, vy´beˇr obeˇti, LRU, thrashing Potrˇebny´ cˇas: 160 minut.

10.1

´ vod U

Virtua´lnı´ pameˇt’zrˇejmeˇ kazˇdy´ uzˇivatel pocˇ´ıtacˇe zna´ z vlastnı´ zkusˇenosti. Fyzicke´ pameˇti RAM, ktera´ je hlavnı´m prostrˇedı´m vykona´va´nı´ programu˚, je obvykle ma´lo4 , a tak soucˇasne´ operacˇnı´ syste´my hojneˇ vyuzˇ´ıvajı´ tzv. virtua´lnı´ pameˇt’ a swapova´nı´, kdy je k fyzicke´ pameˇti prˇipojen jesˇteˇ velky´ soubor na pevne´m disku a za pomoci operacˇnı´ho syste´mu se pocˇ´ıtacˇ tva´rˇ´ı, jakoby fyzicke´ pameˇti bylo ve skutecˇnosti vı´ce. Zatı´mco jednotlive´ procesy vu˚bec nepoznajı´, zˇe jejich ko´d cˇi data obcˇas cestujı´ mezi fyzickou pameˇtı´ a diskem, v pozadı´ tohoto syste´mu je slozˇity´ mechanizmus postaveny´ na spolupra´ci hardwaru a operacˇnı´ho syste´mu. Jelikozˇ realizace virtua´lnı´ pameˇti je u´kolem prˇedevsˇ´ım pro operacˇnı´ syste´m a u´loha hardwaru je jen doplnˇkova´, je tomuto te´matu veˇnova´na cela´ samostatna´ kapitola. Virtua´lnı´ pameˇt’ je operacˇnı´ pameˇt’ zahrnujı´cı´ jak fyzickou pameˇt’, tak vyhrazeny´ prostor na pevne´m disku. (Obecneˇ lze pouzˇ´ıt i jine´ me´dium, pevny´ disk je zde jmenova´n jako nejcˇasteˇjsˇ´ı prˇ´ıpad.) Swapova´nı´ je proces, kdy operacˇnı´ syste´m vymeˇnˇuje u´sek (blok) operacˇnı´ pameˇti mezi fyzickou pameˇtı´ a pevny´m diskem. Cˇasto se pouzˇ´ıva´ take´ pojem stra´nkovacı´ soubor nebo take´ swapovacı´ soubor – to je pra´veˇ onen soubor na disku obsahujı´cı´ data namapovana´ syste´mem do operacˇnı´ pameˇti. (Pro dosazˇenı´ vysˇsˇ´ı rychlosti to mu˚zˇe by´t i vı´ce souboru˚ na ru˚zny´ch discı´ch.) Tato data sice obvykle jsou ulozˇena na pevne´m disku jako beˇzˇny´ soubor, ale z du˚vodu ochrany pameˇti operacˇnı´ syste´m blokuje k tomuto souboru prˇ´ıstup. (Bezpecˇnostnı´ otaznı´k je pak nad situacı´, kdy na´silneˇ vypneme pocˇ´ıtacˇ (simulujeme hava´rii prˇerusˇenı´m doda´vky proudu) a pevny´ disk prˇeneseme do jine´ho pocˇ´ıtacˇe. Je veˇcı´ operacˇnı´ho syste´mu, aby nedovolil swapovacı´ soubor pouzˇ´ıt po hava´rii syste´mu (pokud takovou ochranu potrˇebujeme).) Procˇ vlastneˇ koncept virtua´lnı´ pameˇti funguje? Modernı´ programy obvykle obsahujı´ cˇa´sti ko´du i dat, ktere´ pouzˇ´ıvajı´ velmi sporadicky. Cˇ´ım je program veˇtsˇ´ı, tı´m vı´ce ma´ funkcı´ a tı´m mensˇ´ı procento z nich je pouzˇ´ıva´no pravidelneˇ a cˇasto. Zbytek nenı´ potrˇeba udrzˇovat neusta´le ve fyzicke´ pameˇti. Jestlizˇe jsou v programu ma´lo pouzˇ´ıvane´ cˇa´sti ko´du, pak zrˇejmeˇ take´ existujı´ cˇa´sti dat, ktere´ jsou take´ ma´lo pouzˇ´ıvane´. Kromeˇ toho neˇktere´ datove´ struktury, jako naprˇ´ıklad velmi popula´rnı´ pole, se vzˇdy vytva´rˇejı´ s jistou rezervou, jsou tedy velmi cˇasto veˇtsˇ´ı, nezˇ je potrˇeba. U teˇchto datovy´ch struktur je opeˇt vy´hodne´ je „neˇkam uklidit“, aby nezabı´raly mı´sto ve fyzicke´ pameˇti. Povolı´me-li programu˚m tı´mto zpu˚sobem ply´tvat s pameˇtı´ (tj. naprˇ´ıklad pouzˇ´ıvat prˇeva´zˇneˇ jednoducha´ velka´ pole namı´sto jiny´ch slozˇiteˇjsˇ´ıch struktur), programova´nı´ je take´ jednodusˇsˇ´ı a rychlejsˇ´ı, cozˇ prˇina´sˇ´ı ekonomickou vy´hodu. Prˇitom o ply´tva´nı´ jde jen zda´nliveˇ, nebot’obsazena´ ale nevyuzˇita´ pameˇt’ je dı´ky syste´mu virtua´lnı´ pameˇti velmi „levny´ artikl“. Dalsˇ´ı vy´hodou virtua´lnı´ pameˇti je, zˇe na´m umozˇnı´ spousˇteˇt veˇtsˇ´ı mnozˇstvı´ programu˚ soucˇasneˇ, nebot’ kazˇdy´ potrˇebuje me´neˇ fyzicke´ pameˇti. Lze tedy rˇ´ıci, zˇe virtua´lnı´ pameˇt’prospı´va´ jak syste´mu, tak jeho uzˇivatelu˚m. Virtua´lnı´ pameˇt’funguje stejneˇ jako stra´nkova´nı´ prˇedstavene´ v prˇedchozı´ kapitole, je to de facto jen rozsˇ´ırˇenı´ modelu stra´nkova´nı´. Jedine´, cˇ´ım se tedy v te´to kapitole budeme specia´lneˇ zaby´vat, je problematika prˇesunu stra´nek mezi fyzickou pameˇtı´ a diskem. 4

S nadsa´zkou lze rˇ´ıci, zˇe at’uzˇ je pameˇti libovolneˇ velke´ mnozˇstvı´, je jı´ vzˇdy ma´lo.

97

Stra´nkovacı´ soubor je soucˇa´stı´ operacˇnı´ pameˇti.

10.2

Startova´nı´ a beˇh programu

Da´le v textu budeme rozlisˇovat pameˇt’ prima´rnı´ (fyzickou pameˇt’) a sekunda´rnı´ (swapovacı´ prostor na disku). Podı´vejme se nejprve na startova´nı´ programu, prˇesneˇji procesu. Prˇi spousˇteˇnı´ nove´ho procesu mu˚zˇeme bud’umı´stit cely´ jeho ko´d do prima´rnı´ pameˇti, nebo jednotlive´ stra´nky nacˇ´ıtat azˇ v okamzˇiku, kdy budou potrˇeba. Druha´ varianta (tzv. demand paging, stra´nkova´nı´ na zˇa´dost) je lepsˇ´ı u veˇtsˇ´ıch programu˚, ktere´ obsahujı´ mnoho funkcı´ cˇi podprogramu˚, z nichzˇ ale jen neˇktere´ budou pouzˇity. V praxi se proto pouzˇ´ıva´ tento prˇ´ıstup nebo neˇjaky´ kompromis, protozˇe nacˇ´ıta´nı´ pameˇti po jednotlivy´ch maly´ch 4KB stra´nka´ch by mohlo pu˚sobit negativneˇ na rychlost syste´mu jako celku. (Sekvencˇnı´ cˇtenı´ disku je vy´razneˇ rychlejsˇ´ı nezˇ na´hodne´ cˇtenı´.) Syste´m si musı´ ve stra´nkovacı´ch tabulka´ch evidovat, ktere´ stra´nky jsou v prima´rnı´ pameˇti a ktere´ jsou odswapova´ny, tj. prˇesunuty do sekunda´rnı´ pameˇti. Rˇesˇenı´ te´to evidence je veˇcı´ konkre´tnı´ho hardwaru, protozˇe stra´nkovacı´ tabulky pouzˇ´ıva´ prˇi stra´nkova´nı´ prˇ´ımo procesor (tj. syste´m si tam nemu˚zˇe neˇco pro sebe zapisovat, protozˇe by tomu procesor pak nerozumeˇl). Konkre´tnı´ prˇ´ıklad si uvedeme pozdeˇji. Program beˇzˇ´ı bez proble´mu azˇ do okamzˇiku, kdy se pokusı´ o prˇ´ıstup do stra´nky, ktera´ je odswapovana´. V tom okamzˇiku nastane prˇerusˇenı´ „page fault“ (cˇesky: vy´padek stra´nky), protozˇe pouzˇ´ıvat lze jen prima´rnı´ pameˇt’. Potom je veˇcı´ operacˇnı´ho syste´mu, aby spra´vneˇ osˇetrˇil toto prˇerusˇenı´ – chybeˇjı´cı´ stra´nku tedy nacˇte do prima´rnı´ pameˇti a aktualizuje stra´nkovacı´ tabulku. Je-li prima´rnı´ pameˇt’plna´, syste´m musı´ jesˇteˇ prˇed nacˇtenı´m chybeˇjı´cı´ stra´nky vybrat jinou stra´nku za obeˇt’, kterou odswapuje. (Odtud slovo swap – vy´meˇna – stra´nky v prima´rnı´ pameˇti se pru˚beˇzˇneˇ vymeˇnˇujı´ podle aktua´lnı´ potrˇeby.) Po odswapova´nı´ je rovneˇzˇ nutno aktualizovat prˇ´ıslusˇnou stra´nkovacı´ tabulku. V dalsˇ´ıch sekcı´ch se budeme podrobneˇji zaby´vat jednotlivy´mi u´koly, ktere´ syste´m prˇi spra´veˇ virtua´lnı´ pameˇti ma´; nynı´ jesˇteˇ zmı´nı´me dva body, jejichzˇ diskuzi za´meˇrneˇ odsouva´me na pozdeˇji: • Sdı´lena´ pameˇt’ – prˇi odswapova´nı´ sdı´lene´ho ra´mce je trˇeba aktualizovat vsˇechny stra´nkovacı´ tabulky, ktere´ na neˇj odkazujı´, ne jen jednu. • Obra´cena´ (inverted) stra´nkovacı´ tabulka – prˇi vy´meˇna´ch stra´nek je trˇeba umeˇt rychle prˇeva´deˇt ra´mce na stra´nky, k cˇemuzˇ norma´lnı´ stra´nkovacı´ tabulky nestacˇ´ı.

10.3

Rezervovana´ a komitovana´ pameˇt’

Jednotlive´ stra´nky pameˇti mohou by´t bud’ rezervovane´, nebo komitovane´. Rezervovane´ stra´nky jsou takove´, ktere´ existujı´ v linea´rnı´m adresovacı´m prostoru procesu, ale nikdy se do nich nezapisovalo. Kazˇda´ stra´nka je nejprve rezervovana´. Komitovana´ (z anglicke´ho committed – neprˇekla´da´me pro snazsˇ´ı rozlisˇenı´ od jiny´ch termı´nu˚) stra´nka je takova´, ktere´ je prˇideˇlen ra´mec v prima´rnı´ nebo sekunda´rnı´ pameˇti. Komitovat stra´nku obvykle mu˚zˇe jen operacˇnı´ syste´m – nestacˇ´ı tedy jen neˇco zapsat do rezervovane´ stra´nky. Veˇtsˇinu pameˇti prˇi alokaci rezervujeme a komitujeme soucˇasneˇ a programovacı´ jazyky veˇtsˇinou ani tyto dva stavy nerozlisˇujı´; pameˇt’pouze rezervovanou lze alokovat prˇ´ıslusˇnou funkcı´ operacˇnı´ho syste´mu. Rezervovana´ pameˇt’se hodı´ prˇedevsˇ´ım pro velka´ pole, ktera´ budeme pouzˇ´ıvat postupneˇ, jestli vu˚bec. Typicky´m prˇ´ıkladem je programovy´ za´sobnı´k – prˇi startu procesu lze vytvorˇit obrovsky´ rezervovany´ blok pameˇti pro za´sobnı´k. V linea´rnı´m prostoru pak existuje souvisla´ rˇada stra´nek, ale nejsou k nı´ zˇa´dne´ ra´mce.

10.4

Vy´meˇna ra´mcu˚

Podı´vejme se nynı´ na situaci, kdy je trˇeba prove´st vy´meˇnu ra´mcu˚ (nebo stra´nek – jde o tote´zˇ, nebot’ stra´nky a ra´mce se vymeˇnˇujı´ vzˇdy soucˇasneˇ). Jak bylo zmı´neˇno vy´sˇe, prˇi prˇ´ıstupu do stra´nky, ktera´ nenı´ v prima´rnı´ pameˇti, musı´ syste´m nejprve najı´t volny´ ra´mec v prima´rnı´ pameˇti, 98

Za´sobnı´k pouzˇ´ıva´ rezervovanou pameˇt’.

kam stra´nku umı´stı´. Jsou-li neˇjake´ ra´mce volne´, pouzˇije obvykle ktery´koliv z nich (mu˚zˇe se lisˇit u neˇktery´ch syste´mu˚). Nenı´-li zˇa´dny´ volny´, pak syste´m vybere obeˇt’ – ra´mec, ktery´ bude odswapova´n. (Vy´beˇrem obeˇti se budeme zaby´vat v na´sledujı´cı´ sekci.) Syste´my si obvykle evidujı´ take´ prˇ´ıznak zmeˇny ra´mce (anglicky dirty bit). Je to bit, ktery´ je nulovy´, kdyzˇ ma´ ra´mec prˇesnou kopii v sekunda´rnı´ pameˇti, nebo jednicˇkovy´, kdyzˇ ra´mec bud’ vu˚bec v sekunda´rnı´ pameˇti nenı´, nebo byl zmeˇneˇn. Tento prˇ´ıznak musı´ by´t podporova´n hardwaroveˇ, nastavuje se na jednicˇku prˇi kazˇde´m za´pisu do ra´mce. (Cˇisteˇ softwarove´ rˇesˇenı´ nenı´ mozˇne´.) Je-li obeˇt’zmeˇneˇna, pak syste´m okopı´ruje obeˇt’do jine´ho ra´mce v sekunda´rnı´ pameˇti. Nenı´-li sekunda´rnı´ pameˇt’ volna´, syste´m tam vybere jeden ra´mec, ktery´ ma´ kopii v prima´rnı´ pameˇti, nastavı´ prˇ´ıznak zmeˇny (v prima´rnı´ pameˇti) a tento sekunda´rnı´ ra´mec pouzˇije. V kazˇde´m prˇ´ıpadeˇ pak syste´m jesˇteˇ aktualizuje stra´nkovacı´ tabulku odkazujı´cı´ na obeˇt’. Pru˚vodce studiem Vsˇimneˇte si, zˇe kazˇda´ stra´nka bud’ nema´ zˇa´dny´ ra´mec, nebo ma´ ra´mec v prima´rnı´ pameˇti, nebo ma´ ra´mec v sekunda´rnı´ pameˇti, nebo ma´ ra´mec v prima´rnı´ pameˇti, ktery´ ma´ kopii v sekunda´rnı´ pameˇti. V kazˇde´m prˇ´ıpadeˇ vsˇak celkovy´ pocˇet ra´mcu˚ operacˇnı´ pameˇti musı´ by´t o jeden veˇtsˇ´ı nezˇ pocˇet skutecˇneˇ pouzˇ´ıvany´ch ra´mcu˚, nebo by swapova´nı´ nemohlo fungovat. Diskove´ operace jsou totizˇ jen cˇtenı´ a za´pis, nikoli vy´meˇna. Nynı´ je volny´ ra´mec, syste´m do neˇj tedy okopı´ruje pozˇadovany´ ra´mec ze sekunda´rnı´ pameˇti. Eviduje si prˇitom, kde ve virtua´lnı´ pameˇti je pu˚vodnı´ kopie a nuluje ra´mci prˇ´ıznak zmeˇny. Potom aktualizuje stra´nkovacı´ tabulku odkazujı´cı´ na prˇ´ıslusˇny´ ra´mec a ukoncˇ´ı obsluhu prˇerusˇenı´ page fault. Procesor po skoncˇenı´ prˇerusˇenı´ opakuje poslednı´ instrukci, cˇ´ımzˇ dojde k opeˇtovne´mu pokusu o drˇ´ıve nezdarˇeny´ prˇ´ıstup do pameˇti. Tentokra´t je pameˇt’ jizˇ aktualizova´na a proces pokracˇuje da´l, anizˇ by vu˚bec zjistil, zˇe jeho cˇa´st jesˇteˇ prˇed chvı´lı´ nebyla v prima´rnı´ pameˇti. Vy´meˇna ra´mce samozrˇejmeˇ stojı´ cˇas. Pouzˇitı´m sekunda´rnı´ pameˇti lze operacˇnı´ pameˇt’o hodneˇ zveˇtsˇit („nafouknout“), meˇli bychom se vsˇak drzˇet v rozumny´ch mezı´ch, nebot’ prˇ´ılisˇ cˇaste´ swapova´nı´ ra´mcu˚ by velmi zpomalilo cely´ pocˇ´ıtacˇ. Swapova´nı´ lze zaka´zat zamknutı´m stra´nek, kdy tyto vyrˇadı´me z vy´beˇru obeˇtı´, takzˇe zu˚sta´vajı´ sta´le v prima´rnı´ pameˇti. Zamyka´nı´ by se meˇlo pouzˇ´ıvat co nejme´neˇ, protozˇe zamknutı´m cˇa´sti pameˇti zpu˚sobı´me, zˇe zbytek pameˇti se swapuje jesˇteˇ cˇasteˇji. V praxi se pouzˇ´ıva´ obvykle jen na ja´dro syste´mu nebo ty cˇa´sti programu˚, ktere´ se pouzˇ´ıvajı´ velmi cˇasto. Opravdu nutne´ to vsˇak je jen u pameˇti sdı´lene´ s neˇjaky´m zarˇ´ızenı´m, nebot’ hardwarova´ zarˇ´ızenı´ prˇistupujı´ do fyzicke´ pameˇti a obcha´zejı´ tedy syste´m virtua´lnı´ a linea´rnı´ pameˇti. Na platformeˇ x86 je zamknutı´ nutne´ take´ u rutin obsluhy prˇerusˇenı´, protozˇe prˇi vy´skytu jednoho prˇerusˇenı´ nemu˚zˇe nastat prˇerusˇenı´ dalsˇ´ı (page fault) drˇ´ıve, nezˇ je spusˇteˇna obsluha toho prvnı´ho. Syste´m by tedy zkolaboval. Pru˚vodce studiem Zpomalenı´ prˇi cˇaste´m swapova´nı´ je jedina´ nevy´hoda virtua´lnı´ pameˇti. Je take´ nutno dodat, zˇe swapuje-li pocˇ´ıtacˇ hodneˇ, tak bez virtua´lnı´ pameˇti by v dane´ chvı´li uzˇ to, co pra´veˇ deˇla´, vu˚bec deˇlat nemohl. V praxi poma´ha´ princip lokality prˇedstaveny´ v kapitole 9.4 na straneˇ 90 – proces totizˇ v kra´tke´m cˇase obvykle pracuje sta´le se stejnou pameˇtı´, takzˇe nedocha´zı´ k tomu, zˇe by operacˇnı´ syste´m tra´vil veˇtsˇinu cˇasu neusta´lou zbeˇsilou vy´meˇnou velke´ho mnozˇstvı´ ra´mcu˚. Alesponˇ ne cˇasto.

Hardwarove´ limity Prˇi implementaci vy´meˇny ra´mcu˚ si skutecˇneˇ vystacˇ´ıme jen s operacˇnı´m syste´mem – zˇa´dna´ podpora hardwaru kromeˇ prˇerusˇenı´ page fault a opakova´nı´ instrukce nenı´ trˇeba. Virtua´lnı´ pameˇt’by nesˇlo realizovat, kdyby procesor po skoncˇenı´ prˇerusˇenı´ neopakoval instrukci. 99

Proble´m vsˇak mu˚zˇe by´t i s instrukcˇnı´ sadou. Jelikozˇ se instrukce opakuje, je potrˇeba, aby cˇa´stecˇneˇ provedena´ instrukce nezpu˚sobila neopakovatelnost instrukce. Naprˇ´ıklad procesor pocˇ´ıtacˇe IBM System/360 obsahuje instrukci pro kopı´rova´nı´ azˇ 256 znaku˚ pameˇti. Pokud se adresa cˇtenı´ a za´pisu prˇekry´va´ a za´rovenˇ je blok na hranici stra´nky, mu˚zˇe nastat situace, kdy beˇhem kopı´rova´nı´ dojde k vy´padku stra´nky. Instrukce se pak opakuje, ale v mı´steˇ zdroje dat uzˇ jsou nakopı´rova´na data nova´. V tom okamzˇiku je vy´sledek chybny´. Ma´-li procesor podobne´ instrukce, lze to rˇesˇit naprˇ´ıklad prˇida´nı´m (do hardwaru procesoru) prˇ´ıstupu na zacˇa´tek a konec bufferu prˇed vlastnı´m zpracova´nı´m instrukce. Obecneˇ mohou nastat i jine´ prˇ´ıpady, tj. procesor mu˚zˇe mı´t i jine´ instrukce, jejichzˇ provedenı´ nelze bez u´jmy opakovat. Naprˇ. instrukce cˇtenı´ I/O portu (hardwarove´ho zarˇ´ızenı´), ktera´ zapisuje hodnotu prˇ´ımo do pameˇti prˇi opakova´nı´ opeˇt kontaktuje zarˇ´ızenı´ a to mu˚zˇe zpu˚sobit chybny´ vy´sledek. Proto ne na kazˇde´m pocˇ´ıtacˇi (prˇesneˇji ne na kazˇde´ hardwarove´ platformeˇ) lze realizovat virtua´lnı´ pameˇt’, prˇestozˇe je to funkcionalita zajisˇt’ovana´ cˇisteˇ softwaroveˇ.

10.5

Vy´beˇr obeˇti

Existuje rˇada algoritmu˚ vy´beˇru obeˇti. Jde o cˇisteˇ softwarovou za´lezˇitost, je tedy na operacˇnı´m syste´mu, jak bude postupovat. Za nejlepsˇ´ı povazˇujeme takovy´ algoritmus, kde docha´zı´ k nejmensˇ´ımu pocˇtu vy´padku˚ stra´nek. 10.5.1

Optima´lnı´ algoritmus

Idea´lnı´ obeˇt’je stra´nka, ktera´ nebude v budoucnu pouzˇ´ıva´na. Optima´lnı´ algoritmus tedy za obeˇt’ vybere tu stra´nku, ktera´ v budoucnu nebude pouzˇita´, nebo pokud takova´ nenı´, tak vybere tu, ktera´ bude pouzˇita´ azˇ po nejdelsˇ´ı dobeˇ. Toto vsˇak nenı´ exaktneˇ algoritmizovatelne´, proto se v praxi pouzˇ´ıvajı´ algoritmy jine´. 10.5.2

FIFO – first in, first out

FIFO algoritmus („prvnı´ dovnitrˇ, prvnı´ ven“) za obeˇt’vezme stra´nku, ktera´ je nejde´le v prima´rnı´ pameˇti. Syste´m udrzˇuje evidenci o tom, ktera´ stra´nka byla kdy natazˇena do prima´rnı´ pameˇti. Stacˇ´ı prˇitom udrzˇovat jen frontu stra´nek, prˇesny´ cˇas totizˇ nenı´ podstatny´. Obeˇtı´ je tedy prvnı´ prvek ve fronteˇ, novou stra´nku da´va´me na konec fronty. Tento algoritmus je tedy velmi jednoduchy´, nenı´ vsˇak kvalitnı´. Minima´lneˇ ja´dro syste´mu, ktere´ je cˇasto pouzˇ´ıva´no, bude trpeˇt tı´m, zˇe jednou za cˇas bude prˇesunuto do sekunda´rnı´ pameˇti (a nejspı´sˇe hned zase zpeˇt). FIFO algoritmus vy´beˇru obeˇti dokonce trpı´ Beladyho anoma´liı´ – v neˇktery´ch prˇ´ıpadech se mu˚zˇe sta´t, zˇe da´-li syste´m procesu k dispozici vı´c fyzicke´ pameˇti, dojde prˇi beˇhu k veˇtsˇ´ımu pocˇtu vy´padku˚ stra´nek. K te´to anoma´lii docha´zı´ u neˇktery´ch algoritmu˚; nenı´ tedy pravda, zˇe kdyzˇ ma´me vı´ce fyzicke´ pameˇti, snı´zˇ´ıme automaticky pocˇet vy´padku˚ stra´nky. Prˇ´ıklad Beladyho anoma´lie na FIFO algoritmu [SGG05]: Proces prˇistupuje ke stra´nka´m v porˇadı´ 123412512345. Ma´me-li trˇi ra´mce, pak dojde k devı´ti vy´padku˚m stra´nky (oznacˇeny svislou cˇarou): |1|2|3|4|1|2|512|3|45. Ma´me-li cˇtyrˇi ra´mce, pak dojde k desı´ti vy´padku˚m stra´nky: |1|2|3|412|5|1|2|3|4|5. 10.5.3

LRU – least recently used

LRU algoritmus vezme za obeˇt’ stra´nku, ktera´ je nejdelsˇ´ı dobu nepouzˇ´ıvana´. Vycha´zı´ tedy z prˇedpokladu, zˇe co platilo v neda´vne´ minulosti, to bude platit i v budoucnosti. Tı´m se snazˇ´ı napodobit optima´lnı´ algoritmus popsany´ v sekci 10.5.1.

100

Idea´lnı´ obeˇt’ nebude v budoucnu pouzˇ´ıva´na.

Syste´m udrzˇuje cˇas poslednı´ho pouzˇitı´ u kazˇde´ho ra´mce a podle toho pak vybı´ra´ obeˇt’. LRU mu˚zˇeme povazˇovat za dobry´ algoritmus, ovsˇem je ota´zka, jak jej implementovat, protozˇe nenı´ jednoduche´ sledovat cˇasy vsˇech prˇ´ıstupu˚ do pameˇti. Kazˇdopa´dneˇ to vyzˇaduje hardwarovou implementaci. Prvnı´ mozˇnostı´ implementace je pouzˇ´ıt pocˇ´ıtadlo v procesoru, ktere´ bude inkrementova´no prˇi provedenı´ kazˇde´ instrukce, a jeho hodnota bude ulozˇena jako prˇ´ıznak do stra´nky prˇi kazˇde´m prˇ´ıstupu k nı´. V okamzˇiku hleda´nı´ obeˇti pak projdeme vsˇechny stra´nky a za obeˇt’ vybereme tu s nejmensˇ´ım cˇ´ıslem. Druhou mozˇnostı´ je pouzˇ´ıt pseudo–za´sobnı´k stra´nek, kde prˇi kazˇde´m prˇ´ıstupu da´me dotycˇnou stra´nku na vrchol za´sobnı´ku a za obeˇt’bereme stra´nku na dneˇ za´sobnı´ku. (Za´sobnı´k je jen „pseudo“ proto, zˇe odebı´ra´me prvky z prostrˇedku za´sobnı´ku, cozˇ norma´lneˇ nejde.) Podobneˇ jako optima´lnı´ algoritmus, LRU take´ netrpı´ Beladyho anoma´liı´. (Dokazˇte!) Jeho implementace ktery´mkoliv ze dvou popsany´ch zpu˚sobu˚ by ovsˇem vyzˇadovala slozˇitou hardwarovou podporu a vedlejsˇ´ım efektem by bylo zpomalenı´ kazˇde´ho prˇ´ıstupu do pameˇti z du˚vodu udrzˇova´nı´ evidence. 10.5.4

Prˇiblizˇne´ LRU

Ma´loktera´ hardwarova´ platforma podporuje LRU. Neˇktere´ platformy nepodporujı´ vy´beˇr obeˇti nijak, potom si musı´me vystacˇit naprˇ´ıklad s algoritmem FIFO. Neˇktere´ syste´my nabı´zejı´ alesponˇ cˇa´stecˇnou podporu, potom mu˚zˇeme realizovat algoritmus vy´beˇru alesponˇ prˇiblizˇneˇ odpovı´dajı´cı´ LRU. Ona cˇa´stecˇna´ podpora ma´ podobu bitu prˇ´ıstupu (reference bit), ktery´ je u kazˇde´ stra´nky a je nastaven na jednicˇku prˇi kazˇde´m prˇ´ıstupu ke stra´nce. (Vzpomenˇte na bit dirty (viz sekce 10.4 na straneˇ 99, toto je obdobne´.) Bit prˇ´ıstupu je nejprve nastaven u vsˇech stra´nek na nulu a prˇi beˇhu procesu se u pouzˇ´ıvany´ch stra´nek postupneˇ nastavuje na jednicˇku. Nevı´me tedy sice, kdy byla ktera´ stra´nka naposledy pouzˇita´, dı´ky hardwaru ale vı´me, jestli byla pouzˇita´. Toto je pak za´kladem ru˚zny´ch algoritmu˚ vy´beˇru obeˇti. Algoritmus dalsˇ´ıch bitu˚ prˇ´ıstupu Tento algoritmus zvysˇuje rozlisˇovacı´ schopnost mezi pouzˇity´mi stra´nkami tak, zˇe pracuje s vı´cebitovy´m u´dajem o pouzˇitı´, cˇili naprˇ. „prˇ´ıstupovy´ bajt“ (reference byte), kde hardware nastavuje nejvysˇsˇ´ı bit a syste´m pravidelny´ch cˇasovy´ch intervalech provede bitovy´ posun doprava u kazˇde´ stra´nky. V okamzˇiku obeˇti tedy je k dispozici statistika pouzˇitı´ stra´nek za 8 poslednı´ch cˇasovy´ch u´seku˚. Prˇ´ıstupovy´ bajt lze nynı´ cha´pat jako nezname´nkove´ cˇ´ıslo a za obeˇt’je vybra´na ta stra´nka, ktera´ ma´ nejmensˇ´ı cˇ´ıslo. Je-li takovy´ch stra´nek nalezeno vı´ce, lze z nich vybrat naprˇ. FIFO algoritmem. Pocˇet prˇ´ıdavny´ch bitu˚, ktere´ algoritmus pouzˇ´ıva´, samozrˇejmeˇ mu˚zˇe by´t ru˚zny´. V extre´mnı´m prˇ´ıpadeˇ, kdy to je nula bitu˚, se z tohoto algoritmu sta´va´ algoritmus druhe´ sˇance. Algoritmus druhe´ sˇance Tento algoritmus nepouzˇ´ıva´ zˇa´dne´ prˇ´ıdavne´ bity. Za´kladem je FIFO algoritmus. Prˇed odswapova´nı´m stra´nky na zacˇa´tku fronty vsˇak testujeme jejı´ bit prˇ´ıstupu. Je-li jednicˇkovy´, pak da´me stra´nce druhou sˇanci: nulujeme bit prˇ´ıstupu a da´me ji na konec fronty. Odtud tedy na´zev algoritmu: je to modifikace FIFO algoritmu, kde kazˇda´ v poslednı´ dobeˇ pouzˇ´ıvana´ stra´nka dostane druhou sˇanci. Tento algoritmus se implementuje pomocı´ kruhove´ fronty. Stra´nky zu˚sta´vajı´ sta´le ve stejne´ fronteˇ a posouva´ se jen ukazatel. Kandida´tem na obeˇt’ je stra´nka, na ktere´ je ukazatel. Ma´-li vsˇak tato stra´nka jednicˇkovy´ bit prˇ´ıstupu, tak se tento bit vynuluje a prˇejde na dalsˇ´ı stra´nku a 101

to je novy´ kandida´t. Nejpozdeˇji po projitı´ cele´ kruhove´ fronty tedy najdeme skutecˇnou obeˇt’. Ukazatel se pak posune na dalsˇ´ı stra´nku v rˇadeˇ. Algoritmus druhe´ sˇance lze rozsˇ´ırˇit jesˇteˇ o pouzˇitı´ bitu dirty. Zı´ska´me tak vlastneˇ dvoubitovou hodnotu reference+dirty a za obeˇt’ vybı´ra´me prˇednostneˇ ty stra´nky, ktere´ majı´ v teˇchto dvou bitech nejmensˇ´ı cˇ´ıslo (bra´no jako dvoubitova´ celocˇ´ıselna´ hodnota). Nevy´hodou je, zˇe v extre´mnı´m prˇ´ıpadeˇ musı´me neˇkolikra´t projı´t celou kruhovou frontu, nezˇ obeˇt’ urcˇ´ıme. Vy´hodou je, zˇe obeˇt’je bra´na prˇednostneˇ ze stra´nek, ktere´ nebyly modifikova´ny, takzˇe usˇetrˇ´ıme cˇas tı´m, zˇe nebudeme obeˇt’kopı´rovat do sekunda´rnı´ pameˇti. 10.5.5

LFU – least frequently used

LFU algoritmus pocˇ´ıta´ pocˇet prˇ´ıstupu˚ ke kazˇde´ stra´nce a za obeˇt’ bere tu, kde pocˇet prˇ´ıstupu˚ byl nejmensˇ´ı. Algoritmus stojı´ na prˇedpokladu, zˇe aktivneˇ pouzˇ´ıvane´ stra´nky, ktere´ odswapovat nechceme, budou mı´t napocˇ´ıta´no hodneˇ prˇ´ıstupu˚. Tento algoritmus typicky selha´va´ v situacı´ch, kdy na zacˇa´tku proces provede inicializacˇnı´ ko´d, dı´ky ktere´mu se napocˇ´ıta´ v urcˇity´ch stra´nka´ch hodneˇ prˇ´ıstupu˚, ale nikdy pozdeˇji se tyto stra´nky uzˇ nebudou pouzˇ´ıvat. Pomu˚ckou pak mu˚zˇe by´t obdoba vy´sˇe uvedeny´ch postupu˚, kdy syste´m v pravidelny´ch intervalech procha´zı´ stra´nky a pocˇ´ıtadla prˇ´ıstupu˚ jim posouva´ o jeden bit doprava. Jinou alternativou mu˚zˇe by´t i zcela opacˇny´ postup MFU (most frequently used). Ten stojı´ na prˇedpokladu, zˇe nejme´neˇ pouzˇ´ıvane´ stra´nky byly zrˇejmeˇ teprve natazˇeny do pameˇti a teprve se zacˇnou pouzˇ´ıvat. Pokud bychom je odswapovali, zpu˚sobı´me tak vlastneˇ neusta´le´ swapova´nı´ stejny´ch stra´nek prycˇ z pameˇti a zpeˇt, protozˇe v nich pobeˇzˇ´ı ko´d, ale budou mı´t sta´le ma´lo prˇ´ıstupu˚ a prˇi kazˇde´m odswapova´nı´ se jim znovu vynuluje pocˇ´ıtadlo. Je videˇt, zˇe LFU i MFU majı´ jiste´ neprˇ´ıjemne´ nedostatky, ve skutecˇny´ch operacˇnı´ch syste´mech se pouzˇ´ıvajı´ varianty prˇiblizˇne´ho LRU. 10.5.6

Buffer volny´ch ra´mcu˚

Algoritmy pro vy´beˇr obeˇti lze doplnit o dalsˇ´ı pomocne´ cˇinnosti. Naprˇ. je vy´hodne´ udrzˇovat seznam volny´ch ra´mcu˚. Prˇi vy´padku stra´nky je tato stra´nka nacˇtena do volne´ho ra´mce a proces nemusı´ cˇekat, nezˇ je obeˇt’zapsa´na na disk. Obeˇt’je ale i tak vybra´na a s jisty´m zpozˇdeˇnı´m odswapova´na. Jejı´ ra´mec je pak prˇida´n do seznamu volny´ch. Rozsˇ´ırˇenı´m te´to mysˇlenky je udrzˇova´nı´ seznamu modifikovany´ch stra´nek. Jakmile nema´ procesor nic na pra´ci, mu˚zˇe modifikovane´ stra´nky zapisovat na disk a mazat dirty bit. Tı´mto zpu˚sobem syste´m zvysˇuje sˇanci, zˇe azˇ bude dana´ stra´nka vybra´na za obeˇt’vy´meˇny, usˇetrˇ´ı cˇas, protozˇe ji nebude muset znovu zapisovat na disk. Dalsˇ´ı variantou te´hozˇ je udrzˇovat seznam volny´ch ra´mcu˚ spolu s cˇ´ısly stra´nek, ktere´ v nich naposledy byly. Jelikozˇ ani volny´ ra´mec, ani stra´nka na disku nemu˚zˇe by´t zmeˇneˇna, prˇi potrˇebeˇ vra´tit odswapovanou stra´nku zpeˇt do pameˇti se vu˚bec nemusı´ cˇ´ıst disk – syste´m jen opeˇt aktivuje pu˚vodnı´ ra´mec. Tento princip pouzˇ´ıva´ syste´m VAX/VMS spolu s obycˇejny´m FIFO algoritmem vy´beˇru obeˇti (VAX nema´ k dispozici dirty bit). Zatı´mco FIFO nevhodneˇ vybı´ra´ za obeˇt’ i cˇasto pouzˇ´ıvane´ stra´nky, dı´ky bufferu volny´ch stra´nek se kazˇda´ obeˇt’ mu˚zˇe vra´tit zpeˇt k pouzˇitı´ bez cˇtenı´ disku, pokud je pouzˇita dostatecˇneˇ brzo pote´, co byla odswapova´na. Tuto pomu˚cku pouzˇ´ıvajı´ i neˇktere´ implementace Unixu jako doplneˇnı´ algoritmu druhe´ sˇance. [SGG05]

10.6

Prˇideˇlova´nı´ ra´mcu˚

Prˇipomenˇme, zˇe stra´nkova´nı´ na zˇa´dost, ktere´ jsme popsali v prˇedchozı´ch sekcı´ch, prˇideˇluje ra´mce stra´nka´m azˇ v prˇ´ıpadeˇ potrˇeby. Prˇi beˇhu syste´mu jako celku tedy syste´m postupneˇ rˇesˇ´ı 102

pozˇadavky procesu˚ tak, jak prˇicha´zejı´ prˇes vy´padky stra´nky. Tento jednoduchy´ princip je jisteˇ funkcˇnı´ a zvla´sˇteˇ na jednou´lohovy´ch syste´mech ani nic lepsˇ´ıho nepotrˇebujeme hledat. Lze jej kombinovat i s bufferem volny´ch ra´mcu˚ popsany´m v prˇedchozı´ sekci. Shrnuto do jedne´ veˇty: Vsˇechny ra´mce jsou si rovny a kazˇdy´ proces mu˚zˇe v prˇ´ıpadeˇ potrˇeby dostat ktery´koliv z nich. V dalsˇ´ıch odstavcı´ch se podı´va´me na algoritmy pracujı´cı´ s tezı´, zˇe syste´m bude fungovat le´pe, kdyzˇ si nebudou vsˇechny ra´mce rovny. 10.6.1

Minima´lnı´ pocˇet ra´mcu˚

Pokud klesne pocˇet ra´mcu˚ jednoho beˇzˇ´ıcı´ho procesu pod rozumnou hranici, bude docha´zet k velke´mu mnozˇstvı´ vy´padku˚ stra´nky a to zpomalı´ chod cele´ho syste´mu. Pocˇet ra´mcu˚ musı´ take´ u kazˇde´ho procesu by´t alesponˇ roven pocˇtu ra´mcu˚, ktere´ mu˚zˇe pouzˇ´ıt jedna instrukce, jinak by syste´m mohl skoncˇit v nekonecˇne´ rˇadeˇ vy´padku˚ stra´nky. (Na x86 naprˇ. pro instrukci movsd a hranici stra´nek je potrˇeba 2 stra´nky pro instrukcˇnı´ ko´d, 2 pro cˇtenı´ a 2 pro za´pis dat, celkem tedy azˇ 6 stra´nek. Navı´c potrˇebujeme prˇ´ıstup do stra´nek se stra´nkovacı´mi tabulkami, kde mohou vniknout i vı´cena´sobne´ odkazy (samotna´ stra´nkovacı´ tabulka je ve stra´nce, kterou potrˇebujeme najı´t pomocı´ jine´ stra´nkovacı´ tabulky). Je proto zˇa´doucı´ neusta´le hlı´dat, aby kazˇdy´ proces meˇl alesponˇ jiste´ minima´lnı´ mnozˇstvı´ ra´mcu˚ pro sebe. 10.6.2

Alokacˇnı´ algoritmy

Ra´mce mu˚zˇeme deˇlit mezi procesy bud’ rovnomeˇrneˇ – kazˇdy´ proces dostane stejny´ pocˇet ra´mcu˚, nebo pomeˇrneˇ (proporciona´lneˇ) vzhledem k velikosti virtua´lnı´ho adresovacı´ho prostoru kazˇde´ho procesu – procesy pouzˇ´ıvajı´cı´ veˇtsˇ´ı virtua´lnı´ pameˇt’pak dostanou vı´c ra´mcu˚. V obou prˇ´ıpadech se aktua´lnı´ pocˇty prˇideˇleny´ch ra´mcu˚ pru˚beˇzˇneˇ meˇnı´ podle toho, jak v syste´mu prˇiby´va´ nebo uby´va´ beˇzˇ´ıcı´ch procesu˚. Vsˇimneˇte si take´, zˇe procesy s vysˇsˇ´ı prioritou majı´ stejne´ podmı´nky jako procesy s nizˇsˇ´ı prioritou. V praxi vsˇak mu˚zˇe by´t zˇa´doucı´, aby procesy s vysˇsˇ´ı prioritou meˇly take´ jakousi de facto vysˇsˇ´ı prioritu co do prˇideˇlova´nı´ ra´mcu˚. To lze realizovat naprˇ. prˇideˇlova´nı´m ra´mcu˚ pomeˇrneˇ vu˚cˇi prioriteˇ, namı´sto velikosti virtua´lnı´ho adresovacı´ho prostoru. Dalsˇ´ı mozˇnostı´ je globa´lnı´ alokace ra´mcu˚, kdy procesy sice na zacˇa´tku dostanou urcˇitou mnozˇinu ra´mcu˚ pro sebe (dle neˇjaky´ch pravidel, jak bylo uvedeno vy´sˇe), ale prˇi vy´padcı´ch stra´nky je mozˇno za urcˇity´ch podmı´nek prˇesouvat ra´mce mezi procesy. Naprˇ. stanovı´me, zˇe proces s vysˇsˇ´ı prioritou mu˚zˇe dostat ra´mec na u´kor procesu s nizˇsˇ´ı prioritou. Prˇi vy´padku stra´nky je pak obeˇt’hleda´na mezi ra´mci aktua´lnı´ho procesu a vsˇemi procesy nizˇsˇ´ı priority. Prˇi globa´lnı´ alokaci docha´zı´ k tomu, zˇe opakovaneˇ spousˇteˇny´ program mu˚zˇe beˇzˇet ru˚zneˇ dlouho, protozˇe pokazˇde´ na neˇj vyjde jine´ mnozˇstvı´ ra´mcu˚. (Cˇ´ım me´neˇ ma´ ra´mcu˚, tı´m je jeho vy´pocˇet pomalejsˇ´ı.) Prˇi loka´lnı´ alokaci k tak velky´m rozdı´lu˚m nedocha´zı´, ale vy´pocˇetnı´ vy´kon syste´mu jako celku je omezen tı´m, zˇe syste´m nedoka´zˇe efektivneˇ vyuzˇ´ıvat vsˇechny ra´mce dle aktua´lnı´ch potrˇeb procesu˚. Globa´lnı´ alokace je proto z hlediska syste´mu jako celku vy´hodneˇjsˇ´ı a je v praxi preferova´na.

10.7

Thrashing

Anglicke´ slovo thrashing oznacˇuje situaci, kdy zvy´sˇenı´ pocˇtu prostrˇedku˚ snizˇuje vy´kon syste´mu. Tento paradox si nejle´pe prˇedstavı´me pomocı´ prˇ´ıkladu. Trva´-li postupny´ vy´pocˇet 10 procesu˚ 10T, pak spustı´me-li je soucˇasneˇ na pocˇ´ıtacˇi o deseti procesorech, meˇl by trvat 1T. Pokud vsˇak vsˇechny procesy pracujı´ s CD diskem, pak vy´sledny´ cˇas bude ve skutecˇnosti mnohona´sobny´ – prˇi prˇ´ıstupu k CD bude docha´zet k neusta´le´mu prˇesunu cˇtecı´ hlavicˇky na jina´ mı´sta. Kazˇdy´ proces si prˇecˇte maly´ kousek a jiny´ proces mu opeˇt hlavicˇku prˇesune jinam. 103

Prˇi stra´nkova´nı´ thrashing nasta´va´, kdyzˇ ma´ proces velky´ virtua´lnı´ adresnı´ prostor, ale jen maly´ pocˇet ra´mcu˚. Prˇi pra´ci tak neusta´le vymeˇnˇuje sve´ stra´nky ve sve´m male´m fyzicke´m prostoru. Nastane-li takova´ situace, beˇh procesu se kvu˚li neusta´le´mu swapova´nı´ extre´mneˇ zpomalı´ a obvykle to zpomalı´ i syste´m jako celek. Thrashing je tedy na´zev pro situaci, kdy cˇ´ım vı´ce pameˇti ma´ program, tı´m beˇzˇ´ı pomaleji. Prˇedchozı´ prˇ´ıklady jsou extre´mnı´ a lze se jim cˇasto vyhnout jednodusˇe tak, zˇe nebudeme deˇlat „hloupe´ veˇci“. Thrashing vsˇak mu˚zˇe vzniknout i prˇi beˇzˇne´m provozu jako du˚sledek prˇetı´zˇenı´ syste´mu. Ma´-li procesor na serveru male´ vytı´zˇenı´ (cozˇ operacˇnı´ syste´m umı´ sledovat), pak syste´m startuje dalsˇ´ı u´lohy cˇekajı´cı´ ke zpracova´nı´. Jak se pocˇet beˇzˇ´ıcı´ch procesu˚ zvysˇuje, stoupa´ i vytı´zˇenı´ procesoru. Pokud velikost fyzicke´ pameˇti neodpovı´da´ vy´pocˇetnı´mu vy´konu procesoru, pak prˇi startova´nı´ dalsˇ´ıch procesu˚ postupneˇ kazˇdy´ z nich ma´ me´neˇ a me´neˇ ra´mcu˚, azˇ dojde k thrashingu – procesy zacˇnou hodneˇ swapovat a vytı´zˇenı´ procesoru opeˇt klesa´. Syste´m opeˇt ve snaze o vytı´zˇenı´ procesoru startuje dalsˇ´ı u´lohy a tı´m da´le klesa´ vytı´zˇenı´ procesoru. Tato situace vede k paradoxu: Syste´m odva´dı´ te´meˇrˇ nulovou pra´ci, nebot’je prˇetı´zˇen pracı´. Viz obra´zek 16. Aby procesor zacˇal vı´c pracovat, je paradoxneˇ trˇeba mu od pra´ce odlehcˇit, cˇili snı´zˇit pocˇet soucˇasneˇ prova´deˇny´ch u´loh.

Obra´zek 16: Thrashing – s rostoucı´m pocˇtem procesu˚ klesa´ vytı´zˇenı´ procesoru. [SGG05] Thrashing lze cˇa´stecˇneˇ rˇesˇit pouzˇitı´m loka´lnı´ho alokacˇnı´ho algoritmu zmı´neˇne´ho v prˇedchozı´ sekci. Zaka´zˇeme tı´m, aby jeden prˇetı´zˇeny´ proces „kradl“ ra´mce ostatnı´m procesu˚m a tı´m je take´ prˇetı´zˇil. Nevyrˇesˇ´ıme tı´m vsˇak samotny´ proble´m – ma´-li jeden proces ma´lo ra´mcu˚, bude hodneˇ swapovat a ovlivnı´ tak celkovy´ chod syste´mu minima´lneˇ tı´m, zˇe bude zateˇzˇovat swapovacı´ syste´m svy´mi pozˇadavky a ostatnı´ procesy budou muset de´le cˇekat na vyrˇ´ızenı´ teˇch jejich. Skutecˇny´m rˇesˇenı´m thrashingu je prˇideˇlovat procesu˚m tolik ra´mcu˚, kolik skutecˇneˇ potrˇebujı´. Potrˇeby procesu˚ se samozrˇejmeˇ beˇhem cˇasu meˇnı´, je proto potrˇeba je neˇjaky´m zpu˚sobem pru˚beˇzˇneˇ zjisˇt’ovat. 10.7.1

Pracovnı´ mnozˇina ra´mcu˚ (working set)

Kolik ra´mcu˚ proces potrˇebuje lze pru˚beˇzˇneˇ zjisˇt’ovat naprˇ. skrze jejich tzv. pracovnı´ mnozˇiny ra´mcu˚. Tento algoritmus je postaven na teorii lokalit, ktera´ je odvozena´ od principu lokality, viz kapitolu 9.4 na 90. Platı´-li princip lokality, pak program beˇhem cˇasu pracuje v ru˚zny´ch lokalita´ch, ktere´ se mohou prˇekry´vat. V kazˇde´m okamzˇiku je tedy proces v neˇjake´ lokaliteˇ a pracuje s mnozˇinou stra´nek patrˇ´ıcı´ do te´to lokality. Ma´-li program k dispozici tolik ra´mcu˚, kolik je stra´nek v aktua´lnı´ lokaliteˇ, pak nedocha´zı´ ke swapova´nı´ a potazˇmo thrashingu. Ma´-li program ra´mcu˚ me´neˇ, pak docha´zı´ k thrashingu a vy´pocˇet se velmi zpomalı´. Ma´-li jich naopak vı´ce, pak je snı´zˇena efektivita vyuzˇitı´ pameˇti v syste´mu jako celku (du˚sledkem je, zˇe me´neˇ procesu˚ mu˚zˇe beˇzˇet soucˇasneˇ).

104

Pracovnı´ mnozˇinu lze v praxi zjisˇt’ovat cˇi odhadovat algoritmem vyuzˇ´ıvajı´cı´m kruhovou frontu obdobneˇ jako algoritmus druhe´ sˇance (kapitola 10.5.4 na straneˇ 101). Syste´m s pomocı´ cˇasovacˇe v pravidelny´ch intervalech procha´zı´ stra´nky procesu a zjisˇt’uje, kolik jich ma´ nastaveno bit prˇ´ıstupu, cozˇ je de facto velikost pracovnı´ mnozˇiny. Za´rovenˇ bit prˇ´ıstupu nuluje, takzˇe je vzˇdy nastaven jen u stra´nek, ktere´ byly pouzˇity od prˇedchozı´ kontroly. Podle zjisˇteˇne´ velikosti pracovnı´ mnozˇiny pak syste´m upravuje pocˇty ra´mcu˚ prˇideˇleny´ch jednotlivy´m procesu˚m. Potrˇebuje-li proces dalsˇ´ı volne´ ra´mce, tak je bud’ dostane (jsou-li k dispozici), nebo je naopak cely´ proces pozastaven a odswapova´n (nenı´-li dost ra´mcu˚). V prˇ´ıpadeˇ, zˇe by hrozil thrashing je tedy cely´ proces radeˇji odsunut do sekunda´rnı´ pameˇti, nezˇ aby thrashingem zateˇzˇoval cely´ syste´m. Za´rovenˇ tı´m syste´m zı´ska´ volne´ ra´mce pro jine´ procesy. Algoritmus pracovnı´ mnozˇiny doka´zˇe eliminovat thrashing a tı´m zefektivnit vyuzˇitı´ procesoru, protozˇe ten nebude cˇasto cˇekat na vyrˇ´ızenı´ vy´meˇny ra´mcu˚. Nevy´hodou je nebezpecˇ´ı hladoveˇnı´ – procesy s velky´mi pracovnı´mi mnozˇinami budou pravdeˇpodobneˇ jako prvnı´ odswapova´ny a bez dalsˇ´ıho doplneˇnı´ algoritmus nezarucˇuje, zˇe prˇi neusta´le´m zatı´zˇenı´ syste´mu kazˇdy´ proces vu˚bec v konecˇne´m cˇase skoncˇ´ı. 10.7.2

Frekvence vy´padku˚ stra´nky

S thrashingem lze bojovat i jednodusˇsˇ´ı cestou nezˇ vy´pocˇetneˇ na´rocˇny´mi vy´pocˇty pracovnı´ch mnozˇin. Thrashing se projevuje velky´m mnozˇstvı´m vy´padku˚ stra´nek (v podstateˇ v rˇadeˇ za sebou). Lze jej tedy detekovat pouhy´m sledova´nı´m pocˇtu vy´padku˚ za jednotku cˇasu. Mu˚zˇeme tedy stanovit dolnı´ a hornı´ mez rozumne´ho pocˇtu vy´padku˚ za jednotku cˇasu a pomocı´ cˇasovacˇe pravidelneˇ sledovat, zda vsˇechny beˇzˇ´ıcı´ procesy jsou uvnitrˇ tohoto intervalu. Pokud neˇktery´ nebude, lze pocˇet jemu prˇideˇleny´ch ra´mcu˚ upravit tak, jak bylo popsa´no v prˇedchozı´ sekci (ra´mec prˇida´me cˇi odebereme, prˇ´ıpadneˇ pozastavı´me proces). Tato metoda je vy´pocˇetneˇ me´neˇ na´rocˇna´ nezˇ sledova´nı´ pracovnı´ch mnozˇin.

10.8

Mapova´nı´ souboru do pameˇti

O mapova´nı´ souboru do pameˇti jsme se jizˇ zmı´nili v souvislosti s copy–on–write v kapitole 9.7 na straneˇ 93. Jde o funkci, ktera´ zprˇ´ıstupnı´ soubor (z disku) tak, zˇe se „objevı´“ neˇkde v pameˇti. Pra´ce s mapovany´m souborem je jednodusˇsˇ´ı nezˇ alokovat pameˇt’a rucˇneˇ tam nacˇ´ıtat soubory. Hlavnı´ vy´hodou vsˇak je, jak uzˇ bylo zmı´neˇno, zˇe mapovane´ soubory lze snadno sdı´let mezi procesy, a to dokonce i tehdy, kdyzˇ neˇktery´ z nich chce svou kopii cˇa´stecˇneˇ meˇnit. Pra´ce s pameˇtı´ je take´ algoritmicky jednodusˇsˇ´ı nezˇ pra´ce se souborem (proces vidı´ mapovany´ soubor jako obycˇejne´ pole bajtu˚), takzˇe mapova´nı´ zjednodusˇuje programy a pra´ci programa´toru˚m. Mapovany´ soubor nezabı´ra´ pameˇt’, dokud s nı´m proces nezacˇne pracovat. Teprve po vy´padku stra´nky se nacˇ´ıtajı´ ty cˇa´sti souboru, ktere´ proces ve skutecˇnosti pouzˇ´ıva´. Podobneˇ za´pis do mapovane´ho souboru nejde prˇ´ımo na disk, takzˇe probeˇhne velmi rychle a skutecˇny´ za´pis pak je proveden se zpozˇdeˇnı´m (bud’ v okamzˇiku, kdy syste´m ma´ volny´ cˇas, nebo prˇi ukoncˇenı´ mapova´nı´). Jedinou nevy´hodou mapova´nı´ je, zˇe jej z principu nelze pouzˇ´ıt pro soubory veˇtsˇ´ı, nezˇ je maxima´lnı´ velikost virtua´lnı´ pameˇti (na 32bitovy´ch syste´mech typicky 2–4GB).

Realizace v NT Podı´vejme se nynı´, jak se mapova´nı´ souboru deˇla´ ve Windows NT. Mapova´nı´ zde probı´ha´ dvoufa´zoveˇ: Nejprve vytvorˇ´ıme mapova´nı´ souboru do pameˇti, a pak vytvorˇ´ıme pohled na tento soubor. Vı´ce procesu˚ si mu˚zˇe vytvorˇit pohledy na stejny´ soubor, cˇ´ımzˇ zı´skajı´ sdı´lenou pameˇt’. Tato metoda je jediny´m zpu˚sobem, jak lze v NT sdı´let pameˇt’. (Sdı´lenı´ ko´du, ktere´ syste´m zajisˇt’uje automaticky, funguje take´ na ba´zi mapova´nı´ souboru.) Pouzˇ´ıvajı´-li procesy mapovany´

105

soubor pro komunikaci, je vhodne´ doplnit to jesˇteˇ o mutex cˇi jiny´ synchronizacˇnı´ prostrˇedek pro sledova´nı´, kdy ma´ kdo cˇ´ıst nebo zapisovat. Soubor nejprve otevrˇeme cˇi vytvorˇ´ıme pomocı´ CreateFile. Handle, ktery´ takto zı´ska´me, pouzˇijeme k vytvorˇenı´ mapova´nı´ funkcı´ CreateFileMapping. Tı´m zı´ska´me pojmenovany´ sdı´leny´ objekt, na ktery´ se pomocı´ jme´na mohou odkazovat libovolne´ procesy. Mu˚zˇeme tedy vytva´rˇet pohledy na soubor pomocı´ MapViewOfFile. Dı´ky rozdeˇlenı´ mapova´nı´ na dveˇ fa´ze mu˚zˇeme do adresovacı´ho prostoru procesu namapovat jen cˇa´st souboru. Syste´m prˇitom zajisˇt’uje sdı´lenı´ mapovane´ho souboru, bez ohledu na to, kolik procesu˚ jej pouzˇ´ıva´ a ktere´ jeho cˇa´sti si kazˇdy´ z nich mapuje. (Tento princip je tı´m efektivneˇjsˇ´ı, cˇ´ım vı´ce procesu˚ pracuje s jednı´m souborem a cˇ´ım mensˇ´ı pohledy tyto procesy pouzˇ´ıvajı´.) Po skoncˇenı´ pra´ce nejprve kazˇdy´ proces zrusˇ´ı svu˚j pohled pomocı´ UnmapViewOfFile a zavrˇe vsˇechny handly pomocı´ CloseHandle. (Zavrˇenı´ handlu˚ samozrˇejmeˇ lze prove´st i drˇ´ıve – kdykoliv, kdy uzˇ nebudou potrˇeba.)

10.9

Dalsˇ´ı pasti a pasticˇky

Acˇkoliv tato a prˇedchozı´ kapitola nejsou zrovna strucˇne´, sta´le popisujı´ syste´m spra´vy pameˇti jen ra´mcoveˇ. Pojd’me se na za´veˇr strucˇneˇ sezna´mit s neˇkolika dalsˇ´ımi zajı´mavy´mi te´maty. 10.9.1

Prˇevod ra´mcu˚ na stra´nky

Naprˇ´ıklad jsme nezmı´nili proble´m prˇevodu ra´mcu˚ na stra´nky. Syste´m musı´ umeˇt prˇeve´st cˇ´ıslo ra´mce na cˇ´ıslo stra´nky, protozˇe hardwarova´ zarˇ´ızenı´ pracujı´ s fyzicky´mi adresami (pochopitelneˇ, nepatrˇ´ı prˇece zˇa´dne´mu procesu, takzˇe nemajı´ virtua´lnı´ adresovy´ prostor, ale vidı´ pameˇt’ v jejı´ fyzicke´ podobeˇ). Tento prˇevod ra´mcu˚ na stra´nky je vlastneˇ inverznı´ operacı´ ke stra´nkova´nı´ – kdyby meˇl syste´m hledat kazˇde´ propojenı´ ve stra´nkovacı´ch tabulka´ch, bylo by to velmi pomale´. Navı´c prˇi sdı´lenı´ pameˇti je trˇeba umeˇt namapovat ra´mec na vsˇechny stra´nky, ktere´ se na neˇj odkazujı´. Operacˇnı´ syste´m proto ve skutecˇnosti musı´ udrzˇovat jesˇteˇ tzv. obra´cenou (invertovanou) stra´nkovacı´ tabulku. Potrˇebuje-li proces pracovat s hardwarovy´m zarˇ´ızenı´m (a to nenı´ vu˚bec okrajove´, protozˇe minima´lneˇ syste´move´ procesy a ovladacˇe zarˇ´ızenı´ to deˇlajı´ velmi cˇasto), vyzˇaduje od syste´mu nejen fyzicke´ adresy, ale take´ souvislost prˇideˇleny´ch bloku˚ pameˇti. Potrˇebujeme-li naprˇ. pro zvukovou kartu 64KB pameˇti, pak je musı´me dostat v jednom souvisle´m bloku, ne jako sadu 16 na´hodneˇ nalezeny´ch volny´ch 4KB ra´mcu˚. Operacˇnı´ syste´m tedy musı´ umeˇt take´ vyhoveˇt takto specificky´m pozˇadavku˚m. 10.9.2

Pameˇt’pro objekty ja´dra

Samotne´ ja´dro operacˇnı´ho syste´mu take´ pouzˇ´ıva´ neˇjakou pameˇt’, nejcˇasteˇji potrˇebuje alokovat ˇ ada syste´movy´ch funkcı´ pracuje s datovy´mi pomeˇrneˇ male´ bloky pro syste´move´ struktury. (R strukturami o de´lce neˇkolika desı´tek cˇi stovek bajtu˚.) Bylo by znacˇneˇ nehospoda´rne´ alokovat tyto struktury prˇ´ımo stra´nkovacı´m syste´mem, protozˇe veˇtsˇina z 4KB stra´nek by byla nevyuzˇita (neˇktere´ syste´my navı´c majı´ stra´nky jesˇteˇ veˇtsˇ´ı). Operacˇnı´ syste´m tedy pouzˇ´ıva´ pro sve´ ja´dro jiny´ algoritmus spra´vy pameˇti, ktery´ mu˚zˇe by´t podobny´ naprˇ. haldeˇ dynamicke´ pameˇti jazyka C, i kdyzˇ toto rˇesˇenı´ nenı´ zrovna nejefektivneˇjsˇ´ı z hlediska rychlosti. Jelikozˇ ja´dro syste´mu alokuje pameˇt’ pro datove´ struktury, ktere´ velmi prˇipomı´najı´ objekty, mu˚zˇe to deˇlat v za´sadeˇ libovolny´m zpu˚sobem, ktery´ se osveˇdcˇil v objektoveˇ orientovany´ch programovy´ch prostrˇedı´ch. Proto toto te´ma nebudeme da´le diskutovat.

106

10.9.3

Velikost stra´nky

Dalsˇ´ım te´matem, ktere´ jsme nediskutovali, je volba velikosti stra´nky. U neˇktery´ch pocˇ´ıtacˇu˚ nemajı´ tvu˚rci operacˇnı´ch syste´mu˚ na vy´beˇr a musejı´ pouzˇ´ıvat tu velikost, kterou hardware pocˇ´ıtacˇe podporuje. Prˇi na´vrhu zcela novy´ch pocˇ´ıtacˇu˚ nebo take´ na flexibilnı´ch platforma´ch (kam spadajı´ i nejrozsˇ´ırˇeneˇjsˇ´ı x86, x64 a PowerPC) je vsˇak mozˇnost minima´lneˇ z neˇkolika mozˇnostı´ vybı´rat. V literaturˇe se obvykle jako vy´chozı´ nebo vzorova´ velikost pouzˇ´ıva´ 4KB, protozˇe to je nejcˇasteˇji pouzˇ´ıvana´ velikost v praxi (rozsˇ´ırˇeno dı´ky procesoru Intel 80386 a kompatibilnı´m). Zveˇtsˇ´ıme-li velikost stra´nky, zmensˇ´ıme stra´nkovacı´ tabulky. Jelikozˇ kazˇdy´ proces ma´ svou sadu stra´nkovacı´ch tabulek, mu˚zˇeme tı´m usˇetrˇit i slusˇne´ mnozˇstvı´ pameˇti. Naopak efektivita vyuzˇitı´ pameˇti s rostoucı´ velikostı´ stra´nek klesa´. Z hlediska (vnitrˇnı´) fragmentace je vy´hodneˇjsˇ´ı mı´t stra´nky spı´sˇe mensˇ´ı, aby prˇi alokaci mohlo by´t jednotlivy´m pozˇadavku˚m vyhoveˇno pomocı´ bloku˚ pameˇti o velikosti co nejblizˇsˇ´ı pozˇadovane´ velikosti. Vzˇdy platı´, zˇe pru˚meˇrna´ fragmentace je rovna polovineˇ velikosti stra´nky (na blok). Pru˚vodce studiem Ota´zka volby velikosti stra´nky platı´ zcela stejneˇ i pro volbu velikosti sektoru cˇi clusteru na externı´m pameˇt’ove´m zarˇ´ızenı´ (hard disku apod.). Toto te´ma budeme probı´rat v kapitole 12.6 na straneˇ 133. S rostoucı´ celkovou velikostı´ pameˇti je vhodne´ zveˇtsˇovat i stra´nky. Z hlediska swapova´nı´ ovlivnˇuje chod syste´m cˇasto vı´ce prˇ´ıstupova´ doba nezˇ rychlost cˇtenı´ cˇi za´pisu. Beˇzˇna´ prˇ´ıstupova´ doba je kolem 8ms, zatı´mco rychlost cˇtenı´ je minima´lneˇ 20MB/s. Nacˇtenı´ jedne´ 4KB stra´nky tedy trva´ prˇiblizˇneˇ 0.2ms, cozˇ je 40× me´neˇ, nezˇ je pru˚meˇrna´ prˇ´ıstupova´ doba. Kazˇde´ nacˇtenı´ jedne´ stra´nky z disku tedy trva´ zhruba 8ms bez ohledu na to, zda ma´ stra´nka 4KB nebo trˇeba 64KB. Z tohoto du˚vodu by bylo z hlediska swapova´nı´ vhodneˇjsˇ´ı pouzˇ´ıvat stra´nky veˇtsˇ´ı. Pro mensˇ´ı stra´nky naopak hovorˇ´ı mensˇ´ı fragmentace a take´ lepsˇ´ı rozlisˇovacı´ schopnost lokalit (jsou-li stra´nky mensˇ´ı, pak jsou mensˇ´ı i lokality, takzˇe proces vystacˇ´ı s mensˇ´ım mnozˇstvı´m fyzicke´ pameˇti bez thrashingu). Celkoveˇ vsˇak skutecˇneˇ s rostoucı´ celkovou velikostı´ pameˇti roste vhodnost veˇtsˇ´ıch stra´nek. Velikost pameˇt’ovy´ch stra´nek souvisı´ i s rychlostı´ syste´mu. Jelikozˇ procesor ma´ jen omezenou velikost TLB (viz kapitolu 9.3 na straneˇ 88), pameˇt’ prˇ´ımo prˇ´ıstupna´ bez cache miss je prˇ´ımo u´meˇrna´ velikosti stra´nky. Jsou-li tedy stra´nky veˇtsˇ´ı, ma´me veˇtsˇ´ı pravdeˇpodobnost, zˇe se cela´ aktua´lnı´ lokalita procesu vejde do TLB. V opacˇne´m prˇ´ıpadeˇ pak docha´zı´ k cˇaste´mu cache miss a kvu˚li prohleda´va´nı´ stra´nkovacı´ch tabulek se zpomaluje vy´pocˇetnı´ vy´kon. Neˇktere´ platformy a jejich operacˇnı´ syste´my umozˇnˇujı´ pouzˇ´ıvat ru˚zne´ velikosti stra´nek, podle potrˇeby. Naprˇ. procesory UltraSparc podporujı´ stra´nky o velikosti 8, 64, 512 a 4096KB. Operacˇnı´ syste´m Solaris z toho pouzˇ´ıva´ 8KB a 4MB. Ko´d ja´dra syste´mu je umı´steˇn v 4MB stra´nka´ch, takzˇe prˇ´ıstup do ja´dra vy´znamny´m zpu˚sobem sˇetrˇ´ı TLB. Stejny´m zpu˚sobem funguje i Windows NT na beˇzˇny´ch „pı´sı´cˇka´ch“. 10.9.4

Swapova´nı´ stra´nkovacı´ch tabulek, zamyka´nı´ stra´nek

Dalsˇ´ı zajı´mavostı´ je swapova´nı´ stra´nkovacı´ch tabulek. Jelikozˇ stra´nkovacı´ tabulky jsou umı´steˇne´ zase jen ve stra´nka´ch, mohou by´t prˇi nepouzˇ´ıva´nı´ take´ odswapova´ny. Dojde-li potom k vy´padku stra´nky, mu˚zˇe se sta´t, zˇe prohleda´va´nı´ stra´nkovacı´ tabulky mu˚zˇe ve´st k dalsˇ´ımu vy´padku. A jelikozˇ jsou stra´nkovacı´ tabulky vı´ceu´rovnˇove´, vy´padku˚ mu˚zˇe by´t prˇi jednom prˇ´ıstupu do pameˇti i neˇkolik (azˇ o jeden vı´ce, nezˇ je pocˇet u´rovnı´ tabulek). Operacˇnı´ syste´m musı´ vsˇak se stra´nkovacı´mi tabulkami nakla´dat opatrneˇ, aby nedosˇlo k situaci, kdy stra´nkovacı´ tabulka popisuje sama sebe a je odswapova´na. V tom okamzˇiku by takovy´ proces nemohl pokracˇovat. Syste´m tedy musı´ umeˇt klı´cˇove´ stra´nkovacı´ tabulky, ktere´ nesmı´ by´t odswapova´ny, zamknout. 107

Zamyka´nı´, na druhe´ straneˇ, ma´ tu nevy´hodu, zˇe mu˚zˇe ve´st ke zhroucenı´ syste´mu. Stacˇ´ı mensˇ´ı chyba v ko´du procesu, nebo dokonce v ko´du neˇjake´ cˇa´sti samotne´ho syste´mu, a zamknuta´ pameˇt’uzˇ nebude nikdy odemknuta. Takova´ pameˇt’je nevyuzˇitelna´. Stane-li se to na syste´mech, kde pracuje soucˇasneˇ vı´ce uzˇivatelu˚, jednotlivı´ uzˇivatele´ se budou ovlivnˇovat (jeden zamkne pameˇt’a ostatnı´m tak zneprˇ´ıjemnı´ pra´ci). Neˇktere´ operacˇnı´ syste´my prima´rneˇ pocˇ´ıtajı´cı´ s vı´ceuzˇivatelsky´m nasazenı´m (jako Solaris a dalsˇ´ı serverove´ syste´my) proto vu˚bec zamyka´nı´ pameˇti na u´rovni uzˇivatelsky´ch procesu˚ nepodporujı´, nebo pouze umozˇnˇujı´, aby procesy doporucˇily zamyka´nı´. Nemohou ho vsˇak po syste´mu vyzˇadovat. Pru˚vodce studiem Zde vidı´me typicky´ rozdı´l mezi operacˇnı´mi syste´my unixove´ho typu a syste´my Windows. Zatı´mco ve Windows si mu˚zˇe proces sa´m nastavit nejvysˇsˇ´ı prioritu a zamknout celou pameˇt’, cˇ´ımzˇ efektivneˇ znemozˇnı´ dalsˇ´ı chod pocˇ´ıtacˇe, na unixovy´ch serverech toto nenı´ mozˇne´. Na obranu Windows je vsˇak trˇeba dodat, zˇe pomocı´ spra´vne´ho nastavenı´ u´rovneˇ opra´vneˇnı´ procesu˚ lze jednotlivy´m procesu˚m zaka´zat prova´deˇnı´ potencia´lneˇ destruktivnı´ch operacı´.

Shrnutı´ Tato kapitola byla veˇnova´na virtua´lnı´ pameˇti. Nava´zali jsme na povı´da´nı´ o spra´veˇ pameˇti z prˇedchozı´ kapitoly. Model virtua´lnı´ pameˇti je pouze rozsˇ´ırˇenı´m modelu stra´nkova´nı´, jeho implementace vsˇak vyzˇaduje rˇesˇit celou rˇadu du˚lezˇity´ch detailu˚. Studium te´matu virtua´lnı´ pameˇti sesta´va´ de facto z mnoha strˇ´ıpku˚, vı´ce cˇi me´neˇ neza´visly´ch, ktere´ dohromady skla´dajı´ mozaiku modernı´ho efektivnı´ho zpu˚sobu organizace a spra´vy pameˇti. V te´to kapitole jsme probrali problematiku vy´beˇru obeˇti prˇi swapova´nı´, rozdı´ly mezi rezervovanou a komitovanou pameˇtı´, globa´lnı´ a loka´lnı´ prˇideˇlova´nı´ ra´mcu˚, thrashing, mapova´nı´ souboru˚ do pameˇti a v za´veˇru jsme jesˇteˇ zmı´nili neˇkolik dalsˇ´ıch doplnˇkovy´ch te´mat a proble´mu˚, se ktery´mi se tvu˚rci syste´mu˚ poty´kajı´. V na´sledujı´cı´ kapitole si uka´zˇeme, jak funguje spra´va operacˇnı´ pameˇti v praxi. Pojmy k zapamatova´nı´ • • • • • • • • • • • • • • • • • •

virtua´lnı´ pameˇt’ swapova´nı´ stra´nkovacı´ cˇi swapovacı´ soubor stra´nkova´nı´ na zˇa´dost (demand paging) obra´cena´ (inverted) stra´nkovacı´ tabulka pameˇt’prima´rnı´ a sekunda´rnı´ rezervovana´ a komitovana´ pameˇt’ vy´padek stra´nky vy´meˇna ra´mcu˚ vy´beˇr obeˇti (mezi ra´mci) idea´lnı´ obeˇt’ Beladyho anoma´lie algoritmy vy´beˇru obeˇti: FIFO, LRU, prˇiblizˇne´ LRU, LFU loka´lnı´ a globa´lnı´ alokace ra´mcu˚ thrashing pracovnı´ mnozˇina ra´mcu˚ teorie lokalit mapova´nı´ souboru do pameˇti 108

Kontrolnı´ ota´zky 1. Co musı´ hardware podporovat, aby bylo mozˇno realizovat virtua´lnı´ pameˇt’ a demand paging? 2. Co je prˇ´ıcˇinou thrashingu? Jak jej syste´m mu˚zˇe detekovat? 3. Za jaky´ch okolnostı´ nasta´vajı´ vy´padky stra´nek? Popisˇte, jak na neˇ syste´m reaguje. 4. Meˇjme log obsahujı´cı´ posloupnost cˇ´ısel stra´nek, ke ktery´m dany´ proces prˇistupoval. Proces ma´ k dispozici a ra´mcu˚, na zacˇa´tku pra´zdny´ch. Log ma´ b polozˇek obsahujı´cı´ch c ru˚zny´ch hodnot. Uved’te dolnı´ a hornı´ mez pocˇtu vy´padku˚ stra´nek. 5. Uved’te, ktere´ z na´sledujı´cı´ch programovacı´ch technik a struktur jsou vy´hodne´ prˇi stra´nkova´nı´ na zˇa´dost (demand paging): • za´sobnı´k • hashovacı´ tabulka • sekvencˇnı´ hleda´nı´ • bina´rnı´ hleda´nı´ • cˇisty´ (linea´rnı´) ko´d • operace nad vektory • neprˇ´ıme´ odkazy (pra´ce s pointery atp.) 6. Serˇad’te na´sledujı´cı´ algoritmy vy´beˇru obeˇti od nejlepsˇ´ıho po nejhorsˇ´ı: LRU, FIFO, optima´lnı´ obeˇt’, druha´ sˇance. 7. Popisˇte ru˚zne´ formy prˇiblizˇne´ho LRU. 8. Meˇjme dvojrozmeˇrne´ pole byte A[] = new byte[100][100], ktere´ zacˇ´ına´ na adrese 200. Da´le prˇedpokla´dejme stra´nkovacı´ syste´m s velikostı´ stra´nky 200, algoritmem LRU a cely´m programem ve stra´nce 0. Prˇedpokla´dejme, zˇe stra´nka 0 je nacˇtena v pameˇti a ostatnı´ ra´mce jsou pra´zdne´. Kolik vy´padku˚ stra´nky zaznamena´me u na´sledujı´cı´ch dvou variant inicializace pole A? (a) for each i { for each j { A[i][j] = 0; } } (b) for each j { for each i { A[i][j] = 0; } } 9. Prˇedpokla´dejme syste´m pouzˇ´ıvajı´cı´ demand paging a pevny´ pocˇet soubeˇzˇny´ch procesu˚, u ktere´ho bylo zmeˇrˇeno vyuzˇitı´ CPU a stra´nkovacı´ho disku. Pro na´sledujı´cı´ trˇi alternativy uved’te, co se v syste´mu deˇje. Lze prˇida´nı´m dalsˇ´ıch procesu˚ zvy´sˇit vyuzˇitı´ CPU? Je mozˇnost stra´nkova´nı´ prˇ´ınosem? (a) Vyuzˇitı´ CPU 12%, aktivita disku 95% (b) Vyuzˇitı´ CPU 88%, aktivita disku 4% (c) Vyuzˇitı´ CPU 15%, aktivita disku 5% 10. Pameˇt’se pouzˇ´ıva´ pro ko´d a data. Je neˇktera´ z teˇchto forem vyuzˇitı´ lepsˇ´ım kandida´tem pro stra´nkova´nı´ a odswapova´nı´ nezˇ ta druha´? Svou odpoveˇd’zdu˚vodneˇte. 11. Nejbeˇzˇneˇjsˇ´ım uzˇivatelem rezervovane´ pameˇti je programovy´ za´sobnı´k. Vysveˇtlete, procˇ pra´veˇ za´sobnı´k. 12. Je mozˇne´, aby prˇida´nı´m dalsˇ´ıch procesoru˚ (CPU) do serverove´ho pocˇ´ıtacˇe syste´mu klesl jeho celkovy´ vy´kon? Vysveˇtlete.

109

11

Spra´va pameˇti v praxi

Studijnı´ cı´le: V te´to kapitole si uka´zˇeme, jak funguje spra´va pameˇti v praxi. V prˇedchozı´ch dvou kapitola´ch jsme kompletneˇ probrali te´ma spra´vy operacˇnı´ pameˇti, nynı´ se podı´va´me na technicke´ detaily a rˇesˇenı´ na beˇzˇny´ch pocˇ´ıtacˇ´ıch a operacˇnı´ch syste´mech. Sezna´mı´me se jmenoviteˇ se spra´vou pameˇti v syste´mu Windows NT na nejrozsˇ´ırˇeneˇjsˇ´ı platformeˇ x86. Jelikozˇ spra´va pameˇti hodneˇ za´visı´ na hardwarove´ platformeˇ, rˇada veˇcı´ platı´ analogicky i pro jine´ operacˇnı´ syste´my. Podı´va´me se take´ na prˇeklad virtua´lnı´ch adres na fyzicke´ (ten probı´ha´ zcela hardwaroveˇ). Klı´cˇova´ slova: prˇeklad adres, stra´nkova´nı´, PAE, AWE, x64, ochrana pameˇti Potrˇebny´ cˇas: 230 minut.

11.1

NT na platformeˇ x86

Podobneˇ jako jsme v kapitole 6 na straneˇ 49 diskutovali konkre´tnı´ rˇesˇenı´ spra´vy procesoru na nejbeˇzˇneˇjsˇ´ıch platforma´ch, podı´va´me se nynı´ na to, jak je v praxi rˇesˇena spra´va pameˇti. Na rozdı´l od spra´vy procesoru, kde trˇeba syste´m priorit a pla´nova´nı´ jsou cˇisteˇ softwarove´ za´lezˇitosti, spra´va pameˇti se hodneˇ ty´ka´ i hardwaru, nebot’ jednı´m z u´kolu˚, ktere´ operacˇnı´ syste´m ma´, je prˇ´ıprava stra´nkovacı´ch tabulek, ktere´ pak pouzˇ´ıva´ hardware pro automaticky´ prˇeklad virtua´lnı´ch adres na fyzicke´ prˇi beˇhu programu. Proto se do jiste´ mı´ry spra´va pameˇti na stejne´ platformeˇ ve vsˇech operacˇnı´ch syste´mech podoba´. My se zameˇrˇ´ıme prˇedevsˇ´ım na Windows NT a platformu x86. 11.1.1

Za´kladnı´ fakta

Procesory x86 existujı´ v neˇkolika verzı´ch a podporujı´ ru˚zne´ rezˇimy pra´ce. Syste´m Windows NT je vsˇak mozˇno provozovat pouze v 32bitove´m chra´neˇne´m rezˇimu flat, ktery´ je dostupny´ na procesorech 80386 a vy´sˇe. Rezˇim je 32bitovy´, cˇili procesor ma´ 32bitove´ registry a to jak pro vy´pocˇty, tak pro adresaci. Prˇ´ımo adresovatelny´ prostor je tedy 32bitovy´. Rezˇim je chra´neˇny´, tj. instrukcˇnı´ sada je rozdeˇlena na instrukce beˇzˇne´, ktere´ lze vykona´vat kazˇdy´m procesem, a privilegovane´, ktere´ mohou vykona´vat jen privilegovane´ procesy (tedy ja´dro syste´mu). Prˇipomenˇme take´, zˇe procesy, cˇi prˇesneˇji vla´kna, prˇi beˇhu samy vykona´vajı´ ko´d ja´dra a to tak, zˇe se jim pru˚chodem prˇes specia´lnı´ bra´ny meˇnı´ u´rovenˇ privilegiı´. Na problematiku bran se podı´va´me pozdeˇji, zatı´m vystacˇ´ıme s tı´m, zˇe privilegia vla´kna prˇi beˇhu se meˇnı´ podle toho, zda vykona´va´ ko´d v segmentu patrˇ´ıcı´m ja´dru syste´mu, nebo v segmentu uzˇivatelske´ho procesu. Jak jsme pra´veˇ zmı´nili, syste´m pouzˇ´ıva´ segmentaci pameˇti, avsˇak pouze minima´lneˇ. Segmenty de facto slouzˇ´ı pouze k ochraneˇ pameˇti – kazˇdy´ segment ma´ nastavenou u´rovenˇ pozˇadovany´ch privilegiı´ procesoru. Z aktua´lnı´ho segmentu ko´du lze volneˇ volat jen ty segmenty, ktere´ jsou na stejne´ u´rovni. Vola´nı´ do vysˇsˇ´ı cˇi nizˇsˇ´ı u´rovneˇ probı´hajı´ zvla´sˇtnı´m zpu˚sobem. (K te´matu ochrany se vra´tı´me pozdeˇji.) Beˇzˇny´ proces tedy mu˚zˇe adresovat 32 bitu˚ linea´rnı´ virtua´lnı´ pameˇti, tj. 4GB. Hornı´ polovina je vyhrazena pro operacˇnı´ syste´m, takzˇe pouze dolnı´ 2GB jsou pro uzˇivatelsky´ proces. (Vyply´va´ z toho, zˇe hornı´ 2GB pameˇti se vzˇdy sdı´lı´ mezi vsˇemi procesy, tedy pokud majı´ opra´vneˇnı´ k jednotlivy´m oblastem pameˇti prˇistupovat.) Do hornı´ poloviny pameˇti se naprˇ. take´ mapujı´ hardwarova´ zarˇ´ızenı´ (pameˇt’graficke´ karty atp.). Syste´my Windows NT 4.0 Enterprise, Windows 2000 Advanced Server, Windows XP a noveˇjsˇ´ı mohou by´t prˇi startu spusˇteˇny take´ ve zvla´sˇtnı´m rezˇimu, kdy aplikace majı´ azˇ 3GB a syste´m jen 1GB. V tomto rˇezˇimu sice mohou neˇktere´ aplikace a hlavneˇ ovladacˇe zarˇ´ızenı´ mı´t proble´my s kompatibilitou, ale umozˇnı´ na´m to pohodlneˇ vyuzˇ´ıt o 50% vı´ce pameˇti (cozˇ je pro servery 110

2GB uzˇivatel, 2GB syste´m.

velky´ rozdı´l). (Pro hladky´ chod 3GB rezˇimu je vsˇak obvykle nutne´ vyladit jesˇteˇ rˇadu dalsˇ´ıch syste´movy´ch hodnot, protozˇe jinak bude mı´t syste´m prˇ´ılisˇ male´ syste´move´ tabulky pro celou rˇadu du˚lezˇity´ch prostrˇedku˚, takzˇe pravdeˇpodobneˇ vu˚bec nebude schopen uzˇitecˇneˇ pracovat. Toto je mozˇne´ udeˇlat na Windows Serveru 2003.) 11.1.2

AWE

Dalsˇ´ım rozsˇ´ırˇenı´m je rozhranı´ AWE (Address Windowing Extensions), ktere´ umozˇnˇuje pomocı´ mapova´nı´ do oke´nek zprˇ´ıstupnit vı´ce nezˇ 2GB pameˇti pro proces. Toto rozhranı´ musı´ jednotlive´ aplikace pouzˇ´ıt explicitneˇ, tj. je to sada specia´lnı´ch syste´movy´ch funkcı´, ktere´ deˇlajı´ obdobnou veˇc jako mapova´nı´ souboru. Do vymezene´ho u´seku pameˇti, „pohledu“, zobrazı´ kus pameˇti, ktery´ by jinak nebyl prˇ´ıstupny´.

AWE zprˇ´ıstupnı´ procesu vı´ce nezˇ 2GB pameˇti.

Celkovou dostupnou pameˇt’pro aplikaci vsˇak i prˇi pouzˇitı´ AWE limituje jesˇteˇ schopnost syste´mu adresovat fyzickou pameˇt’. Beˇzˇne´ verze Windows pak i s AWE poskytujı´ aplikacı´m jen 4GB pameˇti. Microsoft navı´c pouzˇ´ıva´ obchodnı´ politiku, kdy blokuje prˇ´ıstup do veˇtsˇ´ı pameˇti dle edice Windows, prˇestozˇe ja´dra vsˇech teˇchto spolecˇneˇ vyda´vany´ch edic jsou stejna´. Pru˚vodce studiem Oke´nkova´ metoda prˇ´ıstupu do pameˇti AWE na´padneˇ prˇipomı´na´ pameˇt’ EMS pouzˇ´ıvanou v 80.letech MS-DOSem. Sˇlo o technologii umozˇnˇujı´cı´ pouzˇ´ıvat pameˇt’nad 640KB v DOSu, ktera´ fungovala stejny´m zpu˚sobem jako AWE. Prˇitom kromeˇ mozˇnosti koupit hardwarove´ cˇipy EMS pameˇtı´ pro libovolne´ pı´sı´cˇko byla na noveˇjsˇ´ıch procesorech 80386 mozˇnost pouzˇ´ıt i levneˇjsˇ´ı klasickou pameˇt’ a softwarovou emulaci EMS pameˇti. Emula´tor pameˇti EMS pojmenovany´ EMM386 patrˇil sve´ho cˇasu k nejpopula´rneˇjsˇ´ımu vybavenı´ kazˇde´ho pocˇ´ıtacˇe a obsahuje jej i emula´tor DOSu zabudovany´ ve Windows NT.

11.1.3

PAE

Chce-li aplikace vyuzˇ´ıvat pameˇt’ nad 4GB prˇes AWE, syste´m kazˇdopa´dneˇ musı´ hardwaroveˇ i softwaroveˇ takovou pameˇt’ podporovat. Hardwaroveˇ podporujı´ pameˇt’ nad 4GB procesory rˇady x86 pocˇ´ınaje modelem Pentium Pro (cˇili jejich poslednı´ generace zna´ma´ take´ jako 686 cˇi P6), softwaroveˇ to podporujı´ ty edice Windows, ktere´ majı´ podporu PAE (Physical Address Extension). PAE je syste´m umozˇnˇujı´cı´ pouzˇitı´ vı´ce fyzicke´ pameˇti nezˇ 4GB. Procesory majı´ konkre´tneˇ o 4 bity sˇirsˇ´ı adresovacı´ sbeˇrnici, takzˇe mohou adresovat azˇ 64GB fyzicke´ pameˇti. To si vyzˇa´dalo u´pravu segmentovy´ch deskriptoru˚ a stra´nkovacı´ch tabulek. PAE je mozˇno pouzˇ´ıvat bud’dohromady s AWE, nebo samostatneˇ. Prˇi pouzˇitı´ samostatne´ho PAE umı´ syste´m adresovat azˇ 64GB pameˇti, prˇicˇemzˇ kazˇdy´ uzˇivatelsky´ proces ma´ sta´le k dispozici jen 4GB adresovacı´ prostor (kde 2GB je vyhrazeno pro ja´dro syste´mu). Beˇzˇ´ı-li vı´ce takovy´ch procesu˚, tak syste´m mu˚zˇe kazˇdy´ z nich mapovat jinam do fyzicke´ pameˇti (takzˇe teoreticky teprve 32 procesu˚ vyuzˇije 64GB pameˇti). Se soucˇasny´m pouzˇitı´m PAE a AWE pak mu˚zˇe oneˇch azˇ 64GB vyuzˇ´ıt kazˇdy´ jednotlivy´ proces. Hardwarovy´ limit 64GB je da´n 36bitovou adresovou sbeˇrnicı´ procesoru˚ x86 pocˇ´ınaje modelem Pentium Pro. Pru˚vodce studiem Zatı´mco syste´m Windows NT umozˇnˇuje pomocı´ AWE a PAE vyuzˇ´ıvat celou pameˇt’ libovolny´m jednı´m procesem, 32bitove´ unixove´ syste´my nemajı´ ve standardu zˇa´dnou obdobu

111

PAE zprˇ´ıstupnı´ vı´ce nezˇ 4GB fyzicke´ pameˇti.

AWE. Prˇed prˇ´ıchodem a rozsˇ´ırˇenı´m 64bitovy´ch pocˇ´ıtacˇu˚ tedy meˇlo Windows NT znacˇnou vy´hodu u serveru˚ pouzˇ´ıvajı´cı´ch hodneˇ pameˇti [SGG05] (naprˇ. nejveˇtsˇ´ı sveˇtove´ SQL databa´ze beˇzˇ´ı veˇtsˇinou na Windows). Microsoft vsˇak limituje celkovou pameˇt’dle zakoupene´ edice Windows. 32bitove´ edice Windows XP a Vista limitujı´ pameˇt’ vzˇdy na 4GB z du˚vodu dosazˇenı´ vysˇsˇ´ı kompatibility se starsˇ´ımi ovladacˇi zarˇ´ızenı´. Windows 2000 podporuje dle edice 4GB azˇ 32GB, Windows Server 2003 dle edice 4GB azˇ 64GB (128GB na x64 procesorech) a Windows Server 2008 dle edice 4GB azˇ 64GB. Neˇktere´ specia´lnı´ zlevneˇne´ edice Windows dokonce podporujı´ vy´razneˇ me´neˇ (naprˇ. 512MB apod.). 64bitove´ edice majı´ tyto limity vysˇsˇ´ı, naprˇ´ıklad Windows XP 128GB, Vista dle verze 8GB azˇ 128GB a serverove´ syste´my v nejvysˇsˇ´ıch verzı´ch azˇ 2TB. PAE rezˇim je potrˇeba explicitneˇ aktivovat, protozˇe se tı´m zmeˇnı´ deskriptory a stra´nkovacı´ tabulky. Je to prˇitom zmeˇna jen pro operacˇnı´ syste´m a ovladacˇe zarˇ´ızenı´ v rezˇimu ja´dra, uzˇivatelske´ procesy by nemeˇly zˇa´dnou zmeˇnu pozorovat. Pro zajı´mavost dodejme, zˇe procesory x64 navı´c umeˇjı´ v rezˇimu PAE blokovat spousˇteˇnı´ ko´du v datovy´ch oblastech pameˇti (NX bit – no execute), takzˇe Windows pocˇ´ınaje verzı´ XP-SP2 automaticky startuje v rezˇimu PAE na procesorech, kde tı´m zı´ska´ mozˇnost vysˇsˇ´ı ochrany pameˇti NX bitem. Procesory x64 v rezˇimu PAE take´ umeˇjı´ pouzˇ´ıt i vı´ce nezˇ 64GB RAM (podporuje-li to operacˇnı´ syste´m). 11.1.4

Pameˇt’ove´ stra´nky

Jak uzˇ bylo zmı´neˇno v kapitole 10.3 na straneˇ 98, v NT je pameˇt’ (kazˇdy´ kousek adresnı´ho prostoru) v jednom ze trˇ´ı stavu˚: Free (volna´) je nevyuzˇita´. Reserved (rezervovana´) ma´ prˇideˇlenou adresu ve virtua´lnı´m prostoru, ale neexistuje mapova´nı´ na ra´mec. Committed (komitovana´ cˇili prˇideˇlena´) ma´ stra´nku a ma´ prˇideˇleny´ ra´mec ve virtua´lnı´m prostoru a je prˇipravena k pouzˇitı´. Jak uzˇ jsme take´ zmı´nili, prˇ´ıkladem pouzˇitı´ tohoto syste´mu je programovy´ za´sobnı´k. Prˇi kompilaci programu˚ lze v prˇekladacˇi nastavit u velikosti za´sobnı´ku dveˇ hodnoty: reserved a committed. Prvnı´ cˇ´ıslo je celkova´ velikost za´sobnı´ku, kterou prˇi naplneˇnı´ zabere v adresnı´m prostoru, druhe´ cˇ´ıslo je startovacı´ velikost, kterou za´sobnı´k ma´ prˇi startu programu. Existence rezervovane´, ale nekomitovane´ pameˇti take´ doplnˇuje samotnou podstatu principu demand–paging. Ma´me-li rezervovanou pameˇt’, program prˇi startu alokuje jen pa´r stra´nek pro za´sobnı´k a o dalsˇ´ı si pozˇa´da´ jen v prˇ´ıpadeˇ potrˇeby. Kdybychom rezervovanou pameˇt’ nemeˇli, prˇi startu programu se alokuje velke´ mnozˇstvı´ stra´nek pro obrovsky´ za´sobnı´k. Tato pameˇt’ se vynuluje a da´le se nejspı´sˇe nikdy nepouzˇije. Syste´m to po chvı´li zjistı´ a odswapuje ji do sekunda´rnı´ pameˇti. Beˇh pocˇ´ıtacˇe bude tedy zpomalen o pocˇa´tecˇnı´ nulova´nı´ velke´ho bloku pameˇti, potom bude mı´t mensˇ´ı volnou pameˇt’a nakonec situaci vyrˇesˇ´ı odswapova´nı´m, cozˇ opeˇt zpomalı´ beˇh cele´ho syste´mu. NT pouzˇ´ıva´ model pracovnı´ mnozˇiny (working set), ktery´ jsme si prˇedstavili v kapitole 10.7.1 na straneˇ 104. NT take´ pouzˇ´ıva´ shlukova´nı´ (clustering), kdy prˇi vy´padku stra´nky automaticky nacˇ´ıta´ neˇkolik sousednı´ch stra´nek najednou, cozˇ obvykle vede ke zrychlenı´ kvu˚li usˇetrˇenı´ cˇasu prˇi pra´ci s diskem (jak jizˇ vı´me). 11.1.5

Pracovnı´ mnozˇina ra´mcu˚

Kazˇdy´ proces startuje s pracovnı´ mnozˇinou minima´lneˇ 50 a maxima´lneˇ 345 ra´mcu˚ [SoRu05]. Tyto hranice jsou vsˇak jen doporucˇene´, prˇi extre´mnı´m mnozˇstvı´ vy´padku˚ stra´nek v procesu 112

mu syste´m prˇideˇlı´ dalsˇ´ı ra´mce i nad maximum pracovnı´ mnozˇiny a naopak pokud proces nema´ zˇa´dne´ vy´padky a jinde v syste´mu je pameˇti nedostatek, syste´m mu˚zˇe i snı´zˇit pocˇet ra´mcu˚ pod minima´lnı´ hranici. Ra´mce se prˇideˇlujı´ pouze na ba´zi pocˇtu vy´padku˚, jak je zde popsa´no, od verze XP. Od verze 2003 je dokonce mozˇno i u jednotlivy´ch procesu˚ nastavit pevne´ limity pracovnı´ mnozˇiny, syste´m je pak dodrzˇuje vzˇdy. Proces kazˇdopa´dneˇ nikdy nedostane vı´ce ra´mcu˚, nezˇ je globa´lnı´ syste´move´ maximum. To je spocˇ´ıta´no prˇi startu syste´mu jako pocˇet vsˇech volny´ch stra´nek – 512. Da´le existujı´ pevne´ hornı´ meze prˇideˇlitelne´ fyzicke´ pameˇti za´visle´ na platformeˇ: U 32bitovy´ch syste´mu˚ je to prˇiblizˇneˇ 2GB, u 64bitovy´ch syste´mu˚ IA-64 a x64 je to neˇkolik TB. Prˇi vy´padku stra´nky proces dostane dalsˇ´ı ra´mec, pokud je dost volne´ pameˇti. V opacˇne´m prˇ´ıpadeˇ syste´m vybere obeˇt’a velikost pracovnı´ mnozˇiny nemeˇnı´. Obeˇt’nenı´ odswapova´na ihned, mı´sto toho je novy´ ra´mec vzat ze seznamu volny´ch ra´mcu˚ a stara´ stra´nka je pouze prˇesunuta do seznamu stra´nek cˇekajı´cı´ch na zapsa´nı´ na disk a vlastnı´ za´pis je proveden, jakmile ma´ procesor cˇas. Je-li syste´m zahlcen pozˇadavky o dalsˇ´ı ra´mce, pak dojde k poklesu pocˇtu volny´ch ra´mcu˚ pod minima´lnı´ mez a syste´m hleda´, ktery´m procesu˚m je vhodne´ da´le zmensˇit pracovnı´ mnozˇinu. (Pokud nenı´ syste´m zahlcen, postupneˇ ukla´da´ stra´nky ze seznamu pouzˇity´ch na disk a uvolnˇuje jejich ra´mce k dalsˇ´ımu pouzˇitı´.) Prˇednostneˇ to prˇitom zkousˇ´ı u procesu˚ s velky´m pocˇtem nepouzˇ´ıvany´ch ra´mcu˚ nebo u velky´ch procesu˚, naopak proces aplikace beˇzˇ´ıcı´ na poprˇedı´ zkousˇ´ı azˇ nakonec, atp. Najde-li syste´m proces, ktery´ ma´ vı´ce ra´mcu˚, nezˇ je minima´lnı´ pocˇet, tak mu odebere neˇjake´ nepouzˇite´. Pokud to nestacˇ´ı k tomu, aby byl v syste´mu alesponˇ minima´lnı´ pocˇet volny´ch ra´mcu˚, syste´m pokracˇuje v hleda´nı´ a zmensˇova´nı´ pracovnı´ch mnozˇin u dalsˇ´ıch procesu˚. Vy´beˇr konkre´tnı´ch stra´nek k odswapova´nı´ funguje na ba´zi bitu accessed, cˇili prˇednostneˇ jsou vybı´ra´ny stra´nky, ke ktery´m se neprˇistupovalo. Syste´m pru˚beˇzˇneˇ sleduje tento bit u kazˇde´ stra´nky, kterou procha´zı´, a udrzˇuje si u nı´ pocˇ´ıtadlo, jak dlouho nebyla pouzˇita. Prˇi vy´beˇru obeˇti pak bere v potaz toto pocˇ´ıtadlo. Stra´nka´m, ktere´ majı´ nastaven access bit tento pouze vynuluje a nezvysˇuje pocˇ´ıtadlo. ´ pravu pracovnı´ch mnozˇin, jak byla popsa´na, prova´dı´ working set manager a rˇ´ıdı´ ji syste´move´ U vla´kno balance set manager. To je aktivova´no bud’ cˇasovacˇem jednou za sekundu, nebo jinou syste´movou komponentou, ktera´ usoudı´, zˇe je trˇeba zmeˇnit velikosti pracovnı´ch mnozˇin. (Prˇi aktivaci cˇasovacˇem se mimochodem stara´ take´ o boostova´nı´ priorit, ktere´ jsme diskutovali v kapitole 6.2.3 na straneˇ 53.) Vla´knu˚m, ktera´ dlouho na neˇco cˇekajı´ (15 sekund ve Windows XP), je odswapova´n za´sobnı´k. Jakmile jsou odswapova´ny za´sobnı´ky vsˇech vla´ken procesu, je odswapova´n cely´ proces. (Naprˇ. sluzˇba winlogon se pouzˇ´ıva´ jen pro prˇihla´sˇenı´ do syste´mu a ma´ beˇzˇneˇ nulovou pracovnı´ mnozˇinu.) Na za´veˇr jesˇteˇ slozˇme celou mozaiku stavu˚ stra´nek a ra´mcu˚: Stra´nka je nejprve rezervovana´ (reserved). Prˇi komitova´nı´ je nejprve ve stavu zero demand – to je stav, kdy stra´nka uzˇ byla komitova´na, ale nebylo do nı´ nic zapsa´no. Takova´ stra´nka se jesˇteˇ chova´ jako reserved a teprve prˇi prvnı´m za´pisu dostane ra´mec. Pouzˇ´ıvana´ stra´nka je committed. Na konci je stra´nka opeˇt reserved a pak free. Stavy ra´mcu˚ ukazuje obra´zek 17. Kazˇdy´ ra´mec je nejprve volny´ a cˇeka´ na vynulova´nı´. Po vynulova´nı´ je nulovy´. Po prˇideˇlenı´ do pracovnı´ mnozˇiny je do neˇj umı´steˇna neˇjaka´ stra´nka. Po odstraneˇnı´ z pracovnı´ mnozˇiny je ra´mec pouzˇity´, tehdy cˇeka´ na za´pis dat na disk. Po zapsa´nı´ na disk je ra´mec opeˇt volny´, prˇed zapsa´nı´m ale mu˚zˇe znovu vejı´t v pouzˇitı´, pokud je vy´padek stra´nky, ktera´ v neˇm byla ulozˇena (viz algoritmus druhe´ sˇance, kap. 10.5.4 na straneˇ 101). Syste´m tedy udrzˇuje seznamy ra´mcu˚ v pracovnı´ch mnozˇina´ch a da´le seznam ra´mcu˚ pouzˇity´ch, volny´ch a nulovy´ch. Kromeˇ toho syste´m udrzˇuje seznam stra´nek vadny´ch (ten je obvykle pra´zdny´) a stra´nek pameˇti ROM – ty samozrˇejmeˇ majı´ zvla´sˇtnı´ pe´cˇi. Jak je take´ videˇt na obra´zku, ja´dro syste´mu ma´ povoleno alokovat pameˇt’i bez nulova´nı´. 11.1.6

Logical prefetcher

Logical prefetcher je komponenta syste´mu, zavedena´ od verze XP, zajisˇt’ujı´cı´ rychlejsˇ´ı start syste´mu (boot) a procesu˚. Fakt, zˇe Windows XP startuje mnohem rychleji nezˇ Windows 2000, 113

Logical prefetcher zrychluje start syste´mu a procesu˚.

Obra´zek 17: Stavy stra´nek. [SoRu05] je mozˇno velmi snadno pozorovat v praxi. Prefetcher pracuje v neˇkolika fa´zı´ch. Nejprve prˇi startu syste´mu cˇi procesu sleduje, ktere´ cˇa´sti ktery´ch datovy´ch cˇi ko´dovy´ch souboru˚ jsou prˇi spousˇteˇnı´ nacˇ´ıta´ny. Neby´t prefetcheru, start syste´mu a kazˇde´ho procesu by prova´zela rˇada te´meˇrˇ souvisly´ch vy´padku˚ stra´nek, prˇi ktery´ch by se do pameˇti natahovaly prˇedevsˇ´ım soubory s ko´dem. Nejveˇtsˇ´ı proble´m prˇi demand–paging je, zˇe spousˇteˇna´ aplikace vyzˇaduje sve´ stra´nky obvykle v na´hodne´m porˇadı´ a hodneˇ cˇasu se tedy ztratı´ neusta´ly´mi prˇesuny cˇtecı´ hlavicˇky z mı´sta na mı´sto. Prefetcher je napojen na spra´vce pameˇti a sleduje vsˇechny vy´padky stra´nek po dobu 10 sekund od startu aplikace a po dobu 30 sekund od spusˇteˇnı´ procesu explorer (prˇi startu syste´mu). Prefetcher sleduje prˇ´ıstupy k MFT na NTFS discı´ch (bude probı´ra´no v kapitole 14.4 na straneˇ 161), prˇ´ıstupy k souboru˚m a prˇ´ıstupy k adresa´rˇu˚m. Po nasbı´ra´nı´ dat je prefetcher analyzuje a zapı´sˇe log do adresa´rˇe Windows\prefetcher, kde je pro kazˇdy´ proces log obsahujı´cı´ seznam objektu˚, ke ktery´m se prˇi startu aplikace cˇi bootu prˇistupovalo. Boot syste´mu ma´ v adresa´rˇi prefetch vlastnı´ soubor. Vlastnı´ logy majı´ take´ u´lohy spousˇteˇne´ v ra´mci hostitelsky´ch procesu˚, jako jsou naprˇ. MMC (Microsoft Management Console) nebo svchost (service host). Seznam aplikacı´ fungujı´cı´ch jako hostitelske´ procesy lze nastavit v syste´move´m registru. Prˇi opeˇtovne´m startu syste´mu cˇi aplikacı´, ktere´ jizˇ majı´ za´znam v adresa´rˇi prefetch, se tento nacˇte a projde se jeho obsah. Jsou nacˇteny vsˇechny polozˇky MFT a soubory ko´du, ktere´ jsou v seznamu, a jsou otevrˇeny vsˇechny soubory, se ktery´mi se bude pracovat. Tı´m se minimalizuje pocˇet na´sledny´ch vy´padku˚ stra´nek.

114

Syste´m jesˇteˇ da´le optimalizuje spousˇteˇcı´ cˇasy tı´m, zˇe kazˇdy´ch pa´r dnı´ procha´zı´ u´daje v prefetch adresa´rˇi a prˇi nı´zke´m vyuzˇitı´ procesoru spousˇtı´ na pozadı´ defragmentaci disku s pozˇadavkem o umı´steˇnı´ souboru˚ z prefetch seznamu za sebe. Prˇi defragmentaci jsou vsˇechny oznacˇene´ soubory prˇesunuty do jednoho mı´sta disku za sebe do porˇadı´, ve ktere´m budou prˇi bootu cˇi startu aplikace nacˇ´ıta´ny. To minimalizuje prˇesuny cˇtecı´ hlavicˇky. 11.1.7

Ochrana pameˇti

Windows NT pouzˇ´ıva´ neˇkolik mechanizmu˚ ochrany pameˇti. Uved’me si zde alesponˇ strucˇny´ prˇehled. 1. Kazˇde´ vla´kno ma´ v deskriptoru segmentu nastavenu aktua´lnı´ u´rovenˇ opra´vneˇnı´. Uzˇivatelske´ procesy majı´ vzˇdy opra´vneˇnı´ nejnizˇsˇ´ı (ring 3). Data ja´dra syste´mu jsou chra´neˇna tak, zˇe jejich segmenty majı´ naopak nejvysˇsˇ´ı u´rovenˇ opra´vneˇnı´ (ring 0). Hardware x86 zajisˇt’uje, zˇe vla´kno beˇzˇ´ıcı´ v ring 3 nema´ prˇ´ıstup do segmentu˚ ring 0, prˇestozˇe jejich selektory ma´ prˇ´ıstupne´ v GDT. 2. Kazˇdy´ proces ma´ vlastnı´ adresovy´ prostor a vlastnı´ sadu segmentu˚ ve vlastnı´ LDT. Procesy na sebe nijak nevidı´, vy´jimkou jsou spolecˇneˇ mapovane´ soubory. 3. Syste´m vyuzˇ´ıva´ vsˇechny dostupne´ prostrˇedky ochrany na u´rovni hardwaru (procesoru). 4. Bloky sdı´lene´ pameˇti majı´ sve´ ACL (access control list). Syste´m kontroluje, zˇe beˇzˇ´ıcı´ proces ma´ opra´vneˇnı´ k prˇ´ıstupu do pameˇti. Tı´m je zajisˇteˇno, zˇe nemu˚zˇe prˇijı´t libovolny´ „cizı´“ proces a prˇidat se ke sdı´lenı´ pameˇti mezi dveˇma sprˇa´teleny´mi procesy. Pomocı´ ACL syste´m kontroluje vsˇechny sdı´lene´ prostrˇedky (pojmenovane´ roury, mutexy atp.) 5. Prˇideˇlovane´ stra´nky jsou vzˇdy nulovane´. V noveˇ alokovane´ pameˇti nikdy nejsou zbytky dat jine´ho procesu. Zvla´sˇtnı´ proces s prioritou 0 neusta´le procha´zı´ vyrˇazene´ stra´nky a nuluje je. Syste´m si udrzˇuje dva seznamy volny´ch stra´nek: zvla´sˇt’ „cˇiste´“ a „sˇpinave´“. Nenı´-li cˇas nulovat stra´nky v prˇedstihu, kazˇda´ se vynuluje nejpozdeˇji v okamzˇiku alokace. Vy´jimkou je ja´dro syste´mu, kde lze pouzˇ´ıvat i nenulovane´ stra´nky. (Nulova´nı´ stra´nek je jednı´m z pozˇadavku˚ americke´ arma´dy na (pro neˇ dostatecˇneˇ bezpecˇny´) operacˇnı´ syste´m.)

11.2

Adresace na procesorech x86

Nynı´ se budeme veˇnovat te´matu˚m souvisejı´cı´m s adresacı´ na procesorech typu x86. Toto je neza´visle´ na operacˇnı´m syste´mu; syste´m ale musı´ by´t napsa´n tak, aby jeho manazˇer pameˇti akceptoval vlastnosti hardwaru. 11.2.1

Typy adres

Na platformeˇ x86 rozlisˇujeme trˇi typy adres: Logicka´ – tu vidı´ program. Ma´ 48 bitu˚, z toho 16 bitu˚ je selektor segmentu a 32 bitu˚ je offset. Beˇzˇneˇ se pracuje pouze s offsetem, protozˇe segmenty jsou doplneˇny automaticky. Linea´rnı´ (virtua´lnı´) – ta ma´ 32 bitu˚, je to jizˇ fina´lnı´ adresa v adresnı´m prostoru procesu. Fyzicka´ – ma´ opeˇt 32 bitu˚ (prˇi PAE 36 bitu˚) a je to jizˇ fyzicke´ cˇ´ıslo bajtu v prima´rnı´ pameˇti. Cˇ´ısla mimo skutecˇnou pameˇt’mu˚zˇe operacˇnı´ syste´m vyuzˇ´ıt pro znacˇenı´ dalsˇ´ıch informacı´, vcˇetneˇ swapovacı´ oblasti. Fyzicky´ adresovy´ prostor je spolecˇny´ cele´mu syste´mu, vcˇetneˇ hardwarovy´ch zarˇ´ızenı´.

115

Zastavme se jesˇteˇ kra´tce u segmentu˚. U adresujı´cı´ instrukce mu˚zˇe by´t uveden segmentovy´ prefix oznacˇujı´cı´ segmentovy´ registr. Adresova´nı´ se pak va´zˇe k dane´mu segmentove´mu registru. Nenı´-li segment uveden prefixem u instrukce, pak se pouzˇije vy´chozı´ segment. Kazˇdy´ registr pouzˇitelny´ pro adresaci ma´ vlastnı´ vy´chozı´ segmentovy´ registr, se ktery´m je asociova´n. Veˇtsˇina registru˚ je asociova´na se segmentovy´m registrem DS, pouze ESP a EBP jsou asociova´ny se SS (adresujı´ za´sobnı´k) a EIP je asociova´n s CS (adresuje ko´d). Kazˇdy´ segmentovy´ registr ma´ kromeˇ viditelne´ho 16bitove´ho selektoru, ktery´m ukazuje do GDT nebo LDT (viz kap. 2.2.3 na straneˇ 20) take´ skrytou cˇa´st obsahujı´cı´ deskriptor, cˇili prˇedevsˇ´ım adresovacı´ ba´zi a limit. 11.2.2

Logicke´ adresy

Jak uzˇ vı´me z kapitoly 2.2.3, x86 pracuje s pojmy segment, deskriptor a selektor. Deskriptor je 8bajtovy´ za´znam v tabulce deskriptoru˚. Syste´m ma´ jednu globa´lnı´ tabulku GDT, na kterou ukazuje registr GDTR, a kazˇdy´ proces ma´ svou loka´lnı´ tabulku LDT, na kterou ukazuje registr LDTR. Deskriptor popisuje jeden segment pameˇti, uda´va´ prˇedevsˇ´ım jeho pocˇa´tek s prˇesnostı´ na bajt, de´lku (limit) s prˇesnostı´ na bajt, u´rovenˇ opra´vneˇnı´ (ring 0–3), typ (data/ko´d atp.), povolenı´ cˇtenı´/za´pisu/spusˇteˇnı´ atp. Proces mu˚zˇe pouzˇ´ıvat GDT i LDT soucˇasneˇ, slouzˇ´ı k tomu segmentove´ registry. Kazˇdy´ segmentovy´ registr ma´ 16 bitu˚, do ktery´ch vlozˇ´ıme selektor – je to index do tabulky GDT nebo LDT plus identifikace, kterou tabulku adresujeme, plus pozˇadovana´ u´rovenˇ zabezpecˇenı´ (ring 0–3). Index do tabulky je v hornı´ch 13 bitech (kazˇdy´ za´znam ma´ 8 bajtu˚, takzˇe je to de facto offset do tabulky), bit 2 rozlisˇuje GDT/LDT a bity 1–0 urcˇujı´ pozˇadovanou u´rovenˇ opra´vneˇnı´. (Opra´vneˇnı´ probereme pozdeˇji.) Nacˇtenı´m hodnoty do segmentove´ho registru (instrukcı´ mov) se kromeˇ ulozˇenı´ te´to 16bitove´ hodnoty take´ nacˇte prˇ´ıslusˇny´ deskriptor do zbytku segmentove´ho registru. Tato cˇa´st nenı´ videˇt a nelze ji nijak prˇecˇ´ıst (jen prˇi prˇepı´na´nı´ vla´ken se ulozˇ´ı do TSS, viz kap. 5.1.2 na straneˇ 43). Prˇi nastavenı´ hodnoty 0 odkazujeme na prvnı´ za´znam v GDT, ktery´ je vzˇdy neplatny´. Je to tedy jaky´si „null“ deskriptor. Tuto hodnotu lze nastavit do selektoru a procesor nevyhodı´ vy´jimku, dokud se nebudeme snazˇit pouzˇ´ıt tento selektor pro prˇ´ıstup do pameˇti. Ulozˇ´ıme-li hodnotu segmentove´ho registru neˇkam do pameˇti, pak se ulozˇ´ı jen 16bitovy´ selektor. Prˇi nacˇtenı´ te´to hodnoty zpeˇt do segmentove´ho registru se znovu nacˇte prˇ´ıslusˇny´ deskriptor do skryte´ cˇa´sti registru. Vy´hodou tohoto rˇesˇenı´ je mj. to, zˇe segmentove´ registry jsou stejneˇ velke´ jako na pu˚vodnı´m procesoru Intel 8086. Programy navı´c pouzˇ´ıva´nı´m 2bajtovy´ch selektoru˚ sˇetrˇ´ı pameˇt’, nemusejı´ s sebou totizˇ vla´cˇet cele´ 8bajtove´ deskriptory. Prˇi kazˇde´m prˇ´ıstupu do pameˇti (cˇtenı´/za´pis cˇehokoliv) se vsˇak pouzˇ´ıva´ cely´ deskriptor ve skryte´ cˇa´sti segmentove´ho registru. Prˇi prˇ´ıstupu do pameˇti nelze nepouzˇ´ıt selektor, protozˇe pameˇt’adresujeme vzˇdy prˇes segmenty a ty jsou popsa´ny v deskriptorech. Acˇkoliv je s kazˇdy´m prˇ´ıstupem do pameˇti mnoho vy´pocˇtu˚, veˇtsˇinou je to rychle´, protozˇe prˇevod adres z logicky´ch na linea´rnı´ a da´le na fyzicke´ zajisˇt’uje samostatna´ adresovacı´ jednotka procesoru, ktera´ beˇzˇ´ı paralelneˇ s dalsˇ´ımi cˇa´stmi procesoru a prˇekla´da´ adresy pokud mozˇno v prˇedstihu. V idea´lnı´m prˇ´ıpadeˇ tedy i prˇes svou slozˇitost trva´ prˇeklad adresy 0T. Jak bylo rˇecˇeno, tabulku deskriptoru˚ zprˇ´ıstupnˇuje segmentovy´ registr LDTR. Ten samozrˇejmeˇ musı´ odkazovat do GDT (nebot’LDT nemu˚zˇe popisovat sama sebe). Na GDT odkazuje registr GDTR, toto vsˇak uzˇ nenı´ segmentovy´ registr (selektor by nemeˇl kam ukazovat), ale mensˇ´ı registr prˇ´ımo obsahujı´cı´ ba´zi a limit v bajtech fyzicke´ pameˇti. Tabulky GDT i LDT jsou velke´ max. 64KB, cˇili kazˇda´ mu˚zˇe obsahovat azˇ 8192 deskriptoru˚. Segmentace pameˇti je prˇitom zcela neza´visla´ na stra´nkova´nı´, jednotlive´ segmenty mohou zacˇ´ınat i koncˇit na libovolne´m bajtu pameˇti, bez ohledu na velikosti stra´nek. V praxi se vsˇak pro jednoduchost a prˇehlednost preferuje syste´m, kdy jsou segmenty zarovna´ny na hranice stra´nek (pocˇa´tkem i koncem). Kazˇdy´ proces prˇitom ve Windows pouzˇ´ıva´ jen neˇkolik ma´lo svy´ch segmentu˚. Velikost kazˇde´ho je totizˇ azˇ 4GB, takzˇe se segmenty veˇtsˇinou pouzˇ´ıvajı´ jen pro rozlisˇenı´ dat, za´sobnı´ku a ko´du (a s tı´m souvisejı´cı´ ochranu pameˇti). 116

Segmentace je neza´visla´ na stra´nkova´nı´.

Pro u´plnost dodejme, zˇe v 8bajtove´m (64bitove´m) deskriptoru je ulozˇena 32bitova´ adresa ba´ze a pouze 20bitovy´ limit segmentu. Zbyly´ch 12 bitu˚ je pouzˇito pro ru˚zne´ prˇ´ıznaky (flagy). Jednı´m z nich je G (granularity), ktery´ urcˇuje, zda se 20bitova´ hodnota limitu bude bra´t jako prˇ´ıma´ hodnota urcˇujı´cı´ velikost segmentu 0–1MB, nebo jako pocˇet stra´nek urcˇujı´cı´ velikost segmentu azˇ 4GB, ale ve skocı´ch po 4KB. Dalsˇ´ı prˇ´ıznaky slouzˇ´ı naprˇ. k rozlisˇenı´ 16/32/64bitove´ho segmentu a typu segmentu. Typ segmentu je vı´cebitova´ hodnota, do ktere´ je zako´dova´no rozlisˇenı´ ko´du a dat a povolenı´ prˇ´ıstupu. V ko´dove´m segmentu je vzˇdy povoleno vykona´va´nı´ ko´du a lze povolit take´ cˇtenı´. V datove´m segmentu je vzˇdy povoleno cˇtenı´ a lze povolit take´ za´pis. Procesor rozlisˇuje take´ dalsˇ´ıch 6 syste´movy´ch typu˚ deskriptoru˚, ktere´ neukazujı´ na segmenty. O nich se zmı´nı´me pozdeˇji. Dalsˇ´ı bit urcˇuje, zda datovy´ segment roste nahoru (data), nebo dolu˚ (za´sobnı´k). U ko´dove´ho segmentu tento bit znacˇ´ı konformitu (prˇizpu˚sobivost), ktera´ ovlivnˇuje opra´vneˇnı´ (k tomu se vra´tı´me pozdeˇji). 11.2.3

Segmentace (prˇeklad logicke´ adresy na linea´rnı´)

Segmentaci, cˇili prˇeklad logicke´ adresy na linea´rnı´, ukazuje obra´zek 18. Ba´ze segmentu je secˇtena s offsetem a tı´m je zı´ska´na linea´rnı´ adresa. Je-li mimo limit nebo neodpovı´da´-li prˇ´ıstup opra´vneˇnı´ ke cˇtenı´/za´pisu take´ ulozˇene´mu v segmentove´m registru, pak je vyvola´na vy´jimka access violation (neopra´vneˇny´ prˇ´ıstup).

Obra´zek 18: Prˇeklad logicke´ adresy na linea´rnı´. [IA32-3A]

11.2.4

Stra´nkova´nı´ (prˇeklad linea´rnı´ adresy na fyzickou)

Stra´nkova´nı´, cˇili prˇeklad linea´rnı´ adresy na fyzickou, ukazuje obra´zek 19. Linea´rnı´ adresa se skla´da´ z cˇ´ısla stra´nky a 12bitove´ho offsetu. Fyzicka´ adresa se skla´da´ z cˇ´ısla ra´mce a stejne´ho 12bitove´ho offsetu. Prˇeklad linea´rnı´ adresy na fyzickou tedy znamena´ prˇeve´st cˇ´ıslo stra´nky na cˇ´ıslo ra´mce. Je-li zcela vypnuta´ virtua´lnı´ pameˇt’ (cozˇ u starsˇ´ıch verzı´ Windows bylo mozˇne´ udeˇlat), pak je fyzicka´ adresa totozˇna´ s linea´rnı´ a zˇa´dny´ prˇeklad se neprova´dı´. Podı´vejme se tedy na situaci, kdy virtua´lnı´ pameˇt’pouzˇ´ıva´me. Jak uzˇ vı´me z kapitoly 9.3 na straneˇ 89, stra´nka i ra´mec majı´ na x86 standardneˇ velikost 4KB a stra´nkovacı´ tabulka obsahuje 4bajtova´ cˇ´ısla ra´mcu˚ pro jednotlive´ stra´nky. V za´jmu u´spory mı´sta pouzˇ´ıvajı´ procesory x86 hierarchicky´ syste´m tabulek, dı´ky cˇemuzˇ nevyuzˇita´ pameˇt’ nezabı´ra´ prostor ve stra´nkovacı´ tabulce. Stra´nkovacı´ tabulka ma´ vzˇdy velikost jedne´ stra´nky (4KB), obsahuje tedy 1024 cˇtyrˇbajtovy´ch za´znamu˚, ktere´ popisujı´ 4MB pameˇti. Index do stra´nkovacı´ tabulky ma´ 10 bitu˚ a tvorˇ´ı prostrˇednı´ cˇa´st adresy (vlevo od 12bitove´ho offsetu). Nejvysˇsˇ´ıch 10 bitu˚ adresy tvorˇ´ı index do adresa´rˇe 117

Obra´zek 19: Prˇeklad linea´rnı´ adresy na fyzickou (PFN = cˇ´ıslo ra´mce, PDE/PTE = za´znam v tabulce). [SoRu05] tabulek, cozˇ je dalsˇ´ı tabulka o velikosti 4KB obsahujı´cı´ opeˇt 1024 cˇtyrˇbajtovy´ch za´znamu˚. Kazˇdy´ za´znam stra´nkovacı´ho adresa´rˇe uda´va´ cˇ´ıslo ra´mce obsahujı´cı´ho prˇ´ıslusˇnou stra´nkovacı´ tabulku. Celkoveˇ tedy adresa´rˇ popisuje 1024 × 1024 × 4KB = 4GB pameˇti. Prˇevod adresy tedy probı´ha´ takto: Fyzicka´ adresa aktivnı´ho adresa´rˇe tabulek je ulozˇena v registru CR3 (platı´ jen hornı´ch 20 bitu˚, protozˇe zacˇ´ına´ vzˇdy na hranici ra´mce). Hornı´ch 10 bitu˚ linea´rnı´ adresy je indexem do adresa´rˇe tabulek. Hodnota na prˇ´ıslusˇne´m mı´steˇ je cˇ´ıslem ra´mce stra´nkovacı´ tabulky. Indexem do te´to tabulky jsou bity 12–21 linea´rnı´ adresy. Cˇ´ıslo na prˇ´ıslusˇne´m mı´steˇ te´to tabulky je pak cˇ´ıslo ra´mce, ktere´ tvorˇ´ı bity 12–31 fyzicke´ adresy. Bity 11–0 jsou stejne´ jako u adresy linea´rnı´.

CR3 obsahuje fyzickou adresu adresa´rˇe stra´nek.

Prˇipomenˇme, zˇe fyzicka´ adresa je nakonec nastavena na adresove´ sbeˇrnici a na rˇ´ıdicı´ sbeˇrnici je nastaven prˇ´ıslusˇny´ prˇ´ıkaz. Na dane´ adrese mu˚zˇe by´t nejen pameˇt’ RAM, ale trˇeba pameˇt’ graficke´ karty nebo cokoliv jine´ho. 11.2.5

Velikost stra´nky

Standardnı´ velikost stra´nky je 4KB. Od procesoru Pentium je mozˇno pouzˇ´ıvat take´ 4MB stra´nky. Hornı´ch 10 bitu˚ adresy je pak indexem do stra´nkovacı´ho adresa´rˇe, na jehozˇ zacˇa´tek ukazuje CR3. Zbyly´ch 22 bitu˚ je uzˇ prˇ´ımo offset (rozsah 0–4MB). NT toto pouzˇ´ıva´ pro ja´dro syste´mu, stejneˇ jako dalsˇ´ı modernı´ operacˇnı´ syste´my. Jak uzˇ jsme zmı´nili v za´veˇru kapitoly 10, pouzˇitı´m 4MB stra´nek pro staticky´ ko´d ja´dra syste´mu se usˇetrˇ´ı pra´ce adresovacı´ jednotce procesoru a prˇedevsˇ´ım se usˇetrˇ´ı velmi cenny´ TLB. Ten se navı´c deˇlı´ na dveˇ cˇa´sti, zvla´sˇt’ pro 4KB a zvla´sˇt’ pro 4MB stra´nky. Obeˇ velikosti stra´nek lze libovolneˇ kombinovat, nebot’ velke´ stra´nky se zapı´najı´ prˇ´ımo v za´znamech stra´nkovacı´ho adresa´rˇe. Nastavenı´m prˇ´ıslusˇne´ho bitu tedy urcˇ´ıme, zda adresa´rˇ ukazuje na stra´nkovacı´ tabulku, ktera´ popisuje mapova´nı´ 4MB pameˇti, nebo prˇ´ımo na 4MB fyzicke´ pameˇti. Za´znamy ve stra´nkovacı´m adresa´rˇi majı´ 32 bitu˚, z toho hornı´ch 20 je cˇ´ıslo fyzicke´ho ra´mce a dolnı´ch 12 bitu˚ jsou dalsˇ´ı flagy. K dispozici jsou take´ 3 bity pro potrˇeby operacˇnı´ho syste´mu. Mezi dalsˇ´ımi bity najdeme i accessed a dirty, ktere´ jsou automaticky nastavova´ny na jednicˇku prˇi prˇ´ıstupu (cˇtenı´/za´pis) cˇi zmeˇneˇ (za´pis) stra´nky. Tyto dva bity pochopitelneˇ pouzˇ´ıva´ syste´m prˇi spra´veˇ pameˇti. Existuje jesˇteˇ trˇetı´ velikost: Prˇi zapnutı´ PAE a vypnutı´ stra´nkovacı´ch tabulek prˇepneme procesor do rezˇimu 2MB stra´nek. 118

Standardnı´ velikost stra´nky je 4KB.

´ rovneˇ opra´vneˇnı´ U

11.2.6

Procesory x86 rozlisˇujı´ cˇtyrˇi u´rovneˇ opra´vneˇnı´ (privilege level), oznacˇovane´ jako ring 0 azˇ 3. Ring 0 je nejvysˇsˇ´ı u´rovenˇ a pouzˇ´ıva´ ji jen ja´dro syste´mu. V te´to u´rovni lze vykona´vat vsˇechny instrukce procesoru. Ring 3 je nejnizˇsˇ´ı u´rovenˇ a beˇzˇ´ı v nı´ vsˇechny uzˇivatelske´ procesy. Ring 1 a 2 lze pouzˇ´ıt naprˇ. pro ovladacˇe zarˇ´ızenı´, ale veˇtsˇina operacˇnı´ch syste´mu˚ pouzˇ´ıva´ jen tyto dveˇ u´rovneˇ, pro rozlisˇenı´ beˇzˇny´ch procesu˚ a ja´dra syste´mu. Kazˇdy´ segment ma´ neˇjakou u´rovenˇ opra´vneˇnı´. Vola´nı´ ko´du v segmentu s jinou u´rovnı´ opra´vneˇnı´ by meˇlo probı´hat jen prˇes bra´ny. Bra´na je za´znam v tabulce deskriptoru˚ oznacˇeny´ jako syste´movy´ segment. Ve skutecˇnosti je v tomto deskriptoru ulozˇena adresa, kterou lze volat mezi segmenty. Bra´na je tedy jaky´si popisovacˇ (deskriptor) vstupnı´ho bodu do neˇjake´ jinak neprˇ´ıstupne´ cˇa´sti ko´du. Vy´znam z hlediska zabezpecˇenı´ je jasny´ – pomocı´ bra´ny je zajisˇteˇno, zˇe uzˇivatelske´ procesy volajı´ syste´move´ funkce jen na spra´vny´ch mı´stech. (Provedenı´m call neˇkam mimo skutecˇny´ zacˇa´tek syste´move´ funkce by bylo v neˇktery´ch prˇ´ıpadech mozˇno nabourat nebo napadnout operacˇnı´ syste´m a zı´skat kontrolu nad pocˇ´ıtacˇem.) K u´rovnı´m opra´vneˇnı´ se jesˇteˇ vra´tı´me v sekci 11.4 veˇnovane´ ochraneˇ pameˇti. 11.2.7

Stra´nkova´nı´ v rezˇimu PAE

V rezˇimu PAE (physical address extension) lze pouzˇ´ıvat 36bitovou adresovou sbeˇrnici (funguje od procesoru Pentium Pro). V tomto rezˇimu pouzˇ´ıva´ procesor stra´nky 4KB nebo 2MB a jiny´ forma´t stra´nkovacı´ch tabulek. Kazˇda´ tabulka ma´ opeˇt velikost 4KB, obsahuje ale 512 osmibajtovy´ch za´znamu˚. Stra´nkova´nı´ je troju´rovnˇove´ – 12 bitu˚ pro offset, 9 bitu˚ pro index do stra´nkovacı´ tabulky, 9 bitu˚ pro index do adresa´rˇe stra´nek a 2 bity pro index do tabulky ukazatelu˚ na adresa´rˇe tabulek (page–directory–pointer table5 (PDPT)). PDPT obsahuje jen 4 osmibajtove´ za´znamy, celkem tedy ma´ 32 bajtu˚. Registr CR3 nynı´ ukazuje na fyzickou adresu PDPT, prˇicˇemzˇ 27 jeho hornı´ch bitu˚ adresuje hornı´ch 27 bitu˚ na 36bitove´ adresove´ sbeˇrnici. PDPT tedy lezˇ´ı na 32bajtove´ hranici a azˇ 128 procesu˚ mu˚zˇe mı´t PDPT ve spolecˇne´m ra´mci pameˇti. 2MB stra´nky v rezˇimu PAE fungujı´ analogicky 4MB stra´nka´m v norma´lnı´m rezˇimu, tj. za´znam v adresa´rˇi stra´nek mu˚zˇe mı´t nastaven bit, ktery´ vyrˇadı´ ze stra´nkovacı´ho algoritmu stra´nkovacı´ tabulku a mı´sto toho se pouzˇije 21bitovy´ offset. (Stra´nky jsou tentokra´t jen 2MB velke´, protozˇe index do stra´nkovacı´ tabulky ma´ jen 9 bitu˚.) Zpu˚sob, jaky´m se nynı´ prˇekla´dajı´ 32bitove´ linea´rnı´ adresy do 36bitove´ho fyzicke´ho prostoru, je jizˇ jasny´ z informacı´ v prˇedchozı´ch dvou odstavcı´ch a nepotrˇebuje dalsˇ´ı komenta´rˇ. Organizace za´znamu˚ v tabulka´ch take´ umozˇnˇuje v budoucnu rozsˇ´ırˇit PAE z pu˚vodnı´ch 36 bitu˚ azˇ na 64bitu˚ adresove´ho prostoru, cozˇ uzˇ dnes pouzˇ´ıvajı´ procesory x64, kde platı´ uzˇ minima´lneˇ 40 bitu˚. PSE–36 Procesory Pentium 3 a noveˇjsˇ´ı nabı´zejı´ pod na´zvem PSE–36 jesˇteˇ dalsˇ´ı variantu, jak zprˇ´ıstupnit 64GB pameˇti. Podrobnosti lze najı´t v [IA32-3A].

11.3

Adresace na procesorech x64

Procesory x64 (zna´me´ take´ jako AMD64 cˇi x86–64) jsou rozsˇ´ırˇenı´m procesoru˚ typu x86. Aktua´lneˇ (v roce 2007) je jizˇ naprosta´ veˇtsˇina procesoru˚ na trhu PC typu x64 a pouze nejlevneˇjsˇ´ı modely jsou jesˇteˇ typu x86 (jde o podtyp P6 cˇili 686). Platforma x64 je velmi chytry´m rozsˇ´ırˇenı´m x86 a z hlediska uzˇivatelsky´ch procesu˚ teˇzˇko vu˚bec videˇt neˇjake´ rozdı´ly, samozrˇejmeˇ kromeˇ 5

Tento krkolomny´ na´zev je skutecˇneˇ pouzˇ´ıva´n v origina´lnı´ dokumentaci [IA32-3A].

119

x86 rozlisˇuje cˇtyrˇi u´rovneˇ opra´vneˇnı´ 0–3.

toho za´kladnı´ho, zˇe vsˇechno je 64bitove´. Registry v procesoru x64 jsou znacˇeny pı´smenem R, cˇili naprˇ. RAX je 64bitove´ rozsˇ´ırˇenı´ registru EAX. Kromeˇ toho ma´ procesor 8 novy´ch registru˚ pro beˇzˇne´ pouzˇitı´, cˇ´ımzˇ zı´ska´va´ neˇkolikana´sobneˇ veˇtsˇ´ı vy´pocˇetnı´ sı´lu uzˇ jen dı´ky svy´m registru˚m (je jich 2× vı´ce a kazˇdy´ je 2× veˇtsˇ´ı). Procesory se navı´c dnes uzˇ beˇzˇneˇ vyra´beˇjı´ i vı´ceja´drove´. Stru˚jcem architektury x64 je AMD, nicme´neˇ Intel dnes jizˇ vyra´bı´ kompatibilnı´ procesory. Pru˚vodce studiem Autor te´to ucˇebnice zde musı´ prˇiznat svu˚j prohrˇesˇek: Informace o procesorech AMD64 jsou azˇ na male´ vy´jimky cˇerpa´ny pouze z materia´lu˚ firmy Intel. Ta totizˇ vyra´bı´ skutecˇneˇ kopie ze softwarove´ho hlediska te´meˇrˇ k nerozezna´nı´. Znacˇky AMD64, x86–64, Intel 64, EM64T a IA-32e vsˇechny oznacˇujı´ tote´zˇ, jde jen o jaky´si „vy´voj zkratek v cˇase“. Mimo firemnı´ materia´ly vy´robcu˚ je nejvı´ce zazˇite´ oznacˇenı´ x64, ktere´ho se budeme drzˇet i my. Podı´vejme se vsˇak na 64bitovou adresaci pameˇti. Procesory x64 mohou by´t provozova´ny bud’ v rezˇimu 32bitove´m, tedy s klasicky´m 32bitovy´m operacˇnı´m syste´mem, kdy velka´ cˇa´st cˇipu doslova lezˇ´ı ladem, nebo v rezˇimu 64bitove´m, kdy procesor ma´ u´plneˇ jinou adresaci pameˇti a jinak ko´dovanou instrukcˇnı´ sadu. Jme´na instrukcı´ jsou sice stejna´, ale registry jsou 64bitove´ a instrukce majı´ jina´ cˇ´ısla v pameˇti, takzˇe automaticky´ prˇevod programu˚ nenı´ mozˇny´. Je vsˇak pochopitelne´, zˇe v 64bitove´m rezˇimu lze prˇejı´t do rezˇimu kompatibility, kde lze spousˇteˇt veˇtsˇinu 32bitovy´ch aplikacı´. Rozdı´ly oproti opravdove´mu 32bitove´mu rezˇimu jsou totizˇ jen na u´rovni ja´dra operacˇnı´ho syste´mu – naprˇ. stra´nkovacı´ tabulky jsou jine´, ale beˇzˇny´ 32bitovy´ program se k takovy´m technicky´m detailu˚m stejneˇ nedostane, takzˇe beˇzˇ´ı, jakoby byl na skutecˇne´m 32bitove´m pocˇ´ıtacˇi. Segmenty V 64bitove´m rezˇimu se nepouzˇ´ıvajı´ segmenty. Existujı´ sice vsˇechny segmentove´ registry a lze do nich nacˇ´ıst selektory, ale prˇi samotne´ adresaci jsou ignorova´ny ba´ze a limit. Platne´ jsou pouze ostatnı´ polozˇky (slouzˇ´ıcı´ ke kontrole typu, opra´vneˇnı´ prˇ´ıstupu atp.). Pameˇt’je tedy „flat“ – zcela linea´rnı´. Vy´jimkou jsou segmentove´ registry FS a GS, jejichzˇ ba´zi lze prˇi adresaci pouzˇ´ıt jako displacement adresy. (Nebudeme rozpitva´vat.) Vsˇechny ostatnı´ segmenty, at’uzˇ do nich nastavı´me cokoliv, majı´ prˇi adresaci ba´zi nula a neomezeny´ limit. (Segmentove´ registry zu˚sta´vajı´, protozˇe se pouzˇ´ıvajı´ v rezˇimu kompatibility.) Kazˇdy´ deskriptor ko´dove´ho segmentu ma´ bit L urcˇujı´cı´, zda je ko´d 32bitovy´, nebo 64bitovy´. V syste´mu lze 64bitove´ a 32bitove´ segmenty libovolneˇ kombinovat, prˇechod mezi takovy´mi segmenty je samozrˇejmeˇ mozˇny´ jen pomocı´ bra´ny. Kanonicke´ adresy Zajı´mave´ je, jaky´m zpu˚sobem je rˇesˇeno rozsˇ´ırˇenı´ adresove´ho prostoru. Soucˇasne´ procesory AMD pouzˇ´ıvajı´ 40bitovy´ fyzicky´ prostor (tj. majı´ 40 bitu˚ na adresove´ sbeˇrnici) a 48bitovy´ logicky´ prostor (tj. stra´nkovacı´ tabulky operujı´ se 48bitovy´mi adresami). Procesory Intel byly v minulosti trochu pozadu, nicme´neˇ nynı´ majı´ stejne´ parametry. Syste´m adres pouzˇ´ıva´ tzv. kanonicke´ adresy, dı´ky ktery´m je mozˇno velmi jednodusˇe v budoucnu rozsˇ´ırˇit adresovacı´ prostor na vı´ce bitu˚. Pru˚vodce studiem Rozsˇirˇitelnost adresove´ho prostoru je velmi du˚lezˇita´ vlastnost, protozˇe vzhledem k tomu,

120

zˇe kompatibilita je u procesoru˚ du˚lezˇiteˇjsˇ´ı (cˇi zˇa´daneˇjsˇ´ı) nezˇ samotna´ kvalita jejich designu, lze odhadovat, zˇe procesory x64 vydrzˇ´ı na trhu velmi dlouho (minima´lneˇ v neˇjake´m rezˇimu kompatibility dalsˇ´ıch noveˇjsˇ´ıch procesoru˚). Soucˇasne´ 32bitove´ procesory x86 se vyra´beˇjı´ od roku 1985, cˇili uzˇ vı´ce nezˇ 20 let, a jesˇteˇ minima´lneˇ neˇkolik let budou. 64bitove´ x64 je nahrazujı´ kvu˚li tomu, zˇe 32bitova´ sbeˇrnice uzˇ nenı´ dostacˇujı´cı´. Prˇitom 64bitova´ sbeˇrnice zrˇejmeˇ vydrzˇ´ı mnohem de´le nezˇ 20 let, nezˇ bude nedostacˇujı´cı´. Acˇkoliv je zrˇejmeˇ prˇedcˇasne´ deˇlat v tomto okamzˇiku neˇjake´ velke´ odhady, platforma x64 mu˚zˇe slouzˇit trˇeba i dalsˇ´ıch 100 let. Jesˇteˇ 5 azˇ 10 let (od nyneˇjsˇka, tj. roku 2007) bude zrˇejmeˇ s x64 koexistovat take´ dozˇ´ıvajı´cı´ x86. Acˇkoliv vy´robci procesoru˚ jsou jizˇ da´vno na jine´ meteˇ, lze rˇ´ıci, zˇe na poli softwaru je x86 dokonce sta´le jednoznacˇneˇ dominujı´cı´ platformou.)

Princip kanonicky´ch adres ukazuje obra´zek 20. Je odvozen od zpu˚sobu, jaky´m Windows (nebo jine´ syste´my) organizuje pameˇt’: Dolnı´ 2GB pro aplikace, hornı´ 2GB pro ja´dro. x64 tento princip rozsˇirˇuje na libovolneˇ velky´ virtua´lnı´ adresovy´ prostor. Polovina virtua´lnı´ho prostoru je tedy pro aplikace, druha´ polovina pro syste´m. Procesor pouzˇ´ıva´ 64bitove´ registry a v budoucnu bude mozˇna´ potrˇeba prˇejı´t z dnesˇnı´ch 48 bitu˚ na vı´ce. Z hlediska registru˚ to nebude proble´m, z hlediska adresova´nı´ to umozˇnı´ pra´veˇ kanonicke´ adresy. Kazˇda´ virtua´lnı´ adresa na x64 musı´ by´t kanonicka´. Pro kanonicke´ adresy platı´, zˇe neadresovatelne´ bity jsou kopiı´ nejvysˇsˇ´ıho platne´ho bitu. Tj. na soucˇasny´ch procesorech majı´cı´ch 48bitove´ adresy je 16 nejvysˇsˇ´ıch bitu˚ ze vsˇech adres vzˇdy kopiı´ bitu 47. Vy´sledkem je tote´zˇ, co zna´me u doplnˇkove´ho ko´du: Hornı´ polovina adresove´ho prostoru se mapuje od konce, tj. jsou to jakoby za´porne´ adresy v 64bitove´m prostoru. Na obra´zku 20 je zeleneˇ oznacˇen prostor pro uzˇivatelske´ procesy, zˇluteˇ prostor pro operacˇnı´ syste´m a bı´la´ cˇa´st je pro adresaci neplatna´.

Obra´zek 20: Kanonicke´ adresy. [Wiki] Podı´vejme se nynı´, jak funguje stra´nkova´nı´ v 64bitove´m rezˇimu. Teoreticky platforma podporuje 64bitove´ virtua´lnı´ a 52bitove´ fyzicke´ adresy. Virtua´lnı´, jak vı´me, jsou va´za´ny na velikost registru˚, proto 64 bitu˚. Fyzicke´ jsou va´za´ny jednak na to, kolik je mı´sta ve stra´nkovacı´ tabulce, to je oneˇch 52 bitu˚, a potom na pocˇet bitu˚ fyzicke´ adresove´ sbeˇrnice, to je v soucˇasnosti 40 bitu˚. 64bitovy´ rezˇim prˇitom lze provozovat jen v adresovacı´m rezˇimu PAE. Ten totizˇ rozsˇirˇuje za´znamy ve stra´nkovacı´ch tabulka´ch na 8 bajtu˚ a zprˇ´ıstupnˇuje tak vı´ce nezˇ 32 bitu˚ na adresove´ 121

sbeˇrnici. Adresovacı´ tabulky v 64bitove´m rezˇimu jsou cˇtyrˇu´rovnˇove´. Offset je 12bitovy´ a kazˇda´ u´rovenˇ tabulek je 9bitova´, cˇili opeˇt ma´me 512 za´znamu˚ v 4KB stra´nce. Celkoveˇ tedy mu˚zˇeme mapovat azˇ 48 bitu˚ (a ne vı´ce) virtua´lnı´ho prostoru. V alternativnı´m rezˇimu 2MB stra´nek se opeˇt vynecha´va´ poslednı´ rˇada tabulek, takzˇe offset je 21bitovy´. Za´znamy ve stra´nkovacı´ch tabulka´ch jsou stejne´ jako v PAE, pouze je rozsˇ´ırˇena adresa tak, aby bylo mozˇno adresovat azˇ 52 bitu˚ fyzicke´ho prostoru. Je k tomu vyuzˇito bitu˚, ktere´ byly drˇ´ıve rezervovane´. (Pu˚vodnı´ stra´nkova´nı´ umozˇnˇovalo adresovat 32 bitu˚. PAE rozsˇ´ırˇilo za´znamy v tabulka´ch ze 32 na 64 bitu˚, tı´m prˇibylo 32 bitu˚ v kazˇde´m za´znamu. 4 bity pouzˇilo PAE pro 36bitove´ adresova´nı´, ostatnı´ byly rezervovane´ pro budoucı´ rozsˇ´ırˇenı´. V 64bitove´m rezˇimu je adresova´nı´ rozsˇ´ırˇeno azˇ na 52 bitu˚, nejvysˇsˇ´ı bit je NX a mezilehly´ch 11 bitu˚ je k dispozici operacˇnı´mu syste´mu.) Jedinou vy´znamnou zmeˇnou je tedy zavedenı´ cˇtyrˇu´rovnˇove´ hierarchie stra´nkovacı´ch tabulek.

11.4 11.4.1

Ochrana pameˇti na procesorech x86 a x64 Prˇehled

Jak uzˇ jsme mnohokra´t zmı´nili v prˇedchozı´m textu, segmentace a stra´nkova´nı´ mohou by´t kombinova´ny s ochranou pameˇti. Pokud to hardware podporuje, jedna´ se o snadno pouzˇitelny´ prostrˇedek ochrany prˇ´ıstupu k pameˇti. Konkre´tneˇ procesory x86 hardwaroveˇ podporujı´ ochranu na neˇkolika u´rovnı´ch, neˇkolikra´t jsme se take´ o nı´ jizˇ zmı´nili v prˇedchozı´m textu. Podı´vejme se nynı´ na kompletnı´ seznam prvku˚ ochrany pameˇti, ktere´ na x86 najdeme. Kontrola prˇ´ıstupu do pameˇti je v x86 jak na u´rovni segmentu˚, tak na u´rovni stra´nkova´nı´ a nejde vypnout. (Mu˚zˇeme samozrˇejmeˇ nastavit segmenty a stra´nky tak, aby kazˇdy´ proces meˇl prˇ´ıstup vsˇude, ale kontrola sta´le probı´ha´.) Kontrola probı´ha´ prˇi kazˇde´m prˇ´ıstupu do pameˇti, prova´dı´ ji vsˇak samostatna´ jednotka v procesoru, ktera´ beˇzˇ´ı paralelneˇ, a kontrola tak nema´ zˇa´dny´ vliv na rychlost vykona´va´nı´ instrukcı´. Je prova´deˇno sˇest druhu˚ kontrol: • Kontrola limitu (velikosti) segmentu • Kontrola typu segmentu • Kontrola u´rovneˇ opra´vneˇnı´ • Omezenı´ adresovatelne´ dome´ny • Omezenı´ vstupnı´ch bodu˚ procedur • Omezenı´ instrukcˇnı´ sady Pokud neˇjaka´ kontrola neprojde, je vyhozena vy´jimka vedoucı´ k prˇ´ıslusˇne´mu prˇerusˇenı´. Jeho obsluha je jizˇ veˇcı´ operacˇnı´ho syste´mu. Neˇktere´ vy´jimky slouzˇ´ı k rˇ´ızenı´ stra´nkova´nı´ virtua´lnı´ pameˇti, takzˇe se nejedna´ o chybove´ stavy. (Ty ostatnı´ pak trˇeba ve Windows obvykle koncˇ´ı nechvalneˇ proslulou hla´sˇkou s tlacˇ´ıtkem „Neodesı´lat“.) 11.4.2

Kontrola limitu˚ segmentu

Kazˇdy´ deskriptor obsahuje u´daj o de´lce segmentu. U za´sobnı´kovy´ch segmentu˚ rostoucı´ch dolu˚ je to velke´ (nebo chcete-li za´porne´) cˇ´ıslo. Limity segmentu˚ jsme jizˇ diskutovali vy´sˇe. Procesor take´ kontroluje limity GDT, LDT a IDT. Velikost GDT a IDT je uvedena´ v registrech GDTR a IDTR, LDT je chra´neˇno jako segment (LDRT je standardnı´ segmentovy´ registr). V 64bitove´m rezˇimu procesor nekontroluje ani ba´zove´ adresy, ani limity segmentu˚. Ve skutecˇnosti je prˇ´ımo ignoruje – do segmentovy´ch registru˚ sice lze standardneˇ nacˇ´ıst deskriptor, ale prˇi adresaci se jeho ba´zova´ adresa a limit ignorujı´. 122

Aresova´nı´ x64 pouzˇ´ıva´ cˇtyrˇu´rovnˇove´ tabulky.

11.4.3

Kontrola typu deskriptoru a segmentu

Kontrolu typu deskriptoru a segmentu mu˚zˇeme cha´pat podobneˇ jako kontrolu typu ve vysˇsˇ´ıch programovacı´ch jazycı´ch. Jeden bit v deskriptoru slouzˇ´ı k rozlisˇenı´ syste´movy´ch a ostatnı´ch deskriptoru˚. (Syste´move´ deskriptory neukazujı´ na segmenty.) Dalsˇ´ı 4 bity v deskriptoru slouzˇ´ı k dalsˇ´ımu uprˇesneˇnı´ typu. U syste´movy´ch deskriptoru˚ se rozlisˇuje cela´ rˇada bran, LDT a TSS. Celkem je tedy 16 mozˇny´ch typu˚ syste´movy´ch deskriptoru˚. Nejcˇasteˇji to je pra´veˇ neˇjaky´ typ bra´ny slouzˇ´ıcı´ k vola´nı´ ko´du mezi segmenty. Procesor velmi omezuje vola´nı´ ko´du pomocı´ klasicky´ch instrukcı´ (call, jmp, ret apod.) do jiny´ch ko´dovy´ch segmentu˚. Mı´sto toho by se pra´veˇ meˇlo pouzˇ´ıvat bran. Bra´na je totizˇ zapsana´ v tabulce deskriptoru˚, takzˇe sa´m proces ji nemu˚zˇe vytvorˇit, ani zmeˇnit. Pomocı´ bra´ny je specifikova´no konkre´tnı´ mı´sto ko´du, ktere´ lze zavolat. Procesor tak nemu˚zˇe volat libovolny´ ko´d, ktery´ si zamane, ma´ mozˇnost volat pouze spra´vne´ vstupnı´ body procedur pomocı´ bran v tabulce deskriptoru˚. Je pochopitelne´, zˇe tento zpu˚sob ochrany vola´nı´ se pouzˇ´ıva´ prˇedevsˇ´ım u ja´dra syste´mu, kde by vola´nı´ na na´hodne´ adresy mohlo vy´znamneˇ usˇkodit cele´mu syste´mu. U segmentovy´ch deskriptoru˚ slouzˇ´ı ony 4 bity k rozlisˇenı´ jejich dalsˇ´ıch vlastnostı´. Jeden bit rozlisˇuje datove´ a ko´dove´ segmenty. Datove´ segmenty majı´ vzˇdy povoleno cˇtenı´, dalsˇ´ı dva bity slouzˇ´ı k blokova´nı´ za´pisu a rozlisˇenı´ za´sobnı´ku rostoucı´ho dolu˚ od ostatnı´ch datovy´ch segmentu˚. Ko´dove´ segmenty majı´ vzˇdy povoleno spousˇteˇnı´ ko´du, dalsˇ´ı dva bity slouzˇ´ı k povolenı´ cˇtenı´ a nastavenı´ konformity. Konformnı´ (prˇizpu˚sobivy´) segment prˇijme prˇi vola´nı´ od volajı´cı´ho nizˇsˇ´ı u´rovenˇ opra´vneˇnı´. Nekonformnı´ (cˇi nonkonformnı´) segment se neprˇizpu˚sobuje volajı´cı´mu a vykona´va´ ko´d ve sve´ u´rovni opra´vneˇnı´. (Budeme jesˇteˇ diskutovat pozdeˇji.) Poslednı´ bit u vsˇech slouzˇ´ı jako prˇ´ıznak prˇ´ıstupu pouzˇ´ıvany´ algoritmem vy´beˇru obeˇti prˇi spra´veˇ pameˇti. Teˇchto peˇt bitu˚ se pak pouzˇ´ıva´ prˇi beˇhu v ru˚zny´ch okamzˇicı´ch. Ihned prˇi nacˇtenı´ selektoru se kontroluje: CS mu˚zˇe ukazovat jen na ko´dovy´ segment, SS jen na segment s povoleny´m za´pisem, ostatnı´ segmentove´ registry jen na segment s povoleny´m cˇtenı´m. LDTR mu˚zˇe ukazovat jen na segment LDT. TR mu˚zˇe ukazovat jen na segment TSS. Prˇi prˇ´ıstupu do segmentu se kontroluje: Cˇ´ıst lze jen ze segmentu s povoleny´m cˇtenı´m. Zapisovat lze jen do datovy´ch segmentu˚ s povoleny´m za´pisem. Instrukce jako call a jmp jsou kontrolova´ny na spra´vny´ typ segmentu drˇ´ıve, nezˇ jsou provedeny. Procesor take´ doka´zˇe dı´ky deskriptoru poznat vola´nı´ mezi procesy a namı´sto obycˇejne´ho vola´nı´ provede prˇepnutı´ kontextu procesu (ve Windows vla´kna). Null segment (prvnı´ polozˇka GDT) nelze nacˇ´ıst do CS nebo SS. Do ostatnı´ch registru˚ ano, ale nelze je pak pouzˇ´ıt k prˇ´ıstupu do pameˇti. V 64bitove´m rezˇimu procesor null segment nepodporuje, tj. prvnı´ polozˇka GDT obsahuje standardnı´ deskriptor. 11.4.4

´ rovneˇ opra´vneˇnı´ U

Jak uzˇ vı´me, jsou 4 u´rovneˇ opra´vneˇnı´ (tzv. ring). Nejvysˇsˇ´ı je ring 0 a pouzˇ´ıva´ ji ja´dro syste´mu. ´ rovneˇ 1 a 2 mohou by´t vyuzˇity naprˇ. Nejnizˇsˇ´ı je ring 3 a pouzˇ´ıvajı´ ji uzˇivatelske´ procesy. U pro ovladacˇe zarˇ´ızenı´ cˇi jine´ soucˇa´sti syste´mu, veˇtsˇina soucˇasny´ch operacˇnı´ch syste´mu˚ je vsˇak nevyuzˇ´ıva´ (tj. rozlisˇujı´ jen ja´dro a zbytek). Ve strucˇnosti lze rˇ´ıci, zˇe syste´m u´rovnı´ slouzˇ´ı ´ rovenˇ opra´vneˇnı´ je tedy k tomu, aby omezil prˇ´ıstup beˇzˇny´ch procesu˚ do ja´dra syste´mu. U 2bitova´ hodnota, kterou najdeme na ru˚zny´ch mı´stech. CPL (current privilege level) je aktua´lnı´ u´rovenˇ beˇzˇ´ıcı´ho procesu. Je ulozˇena v CS a SS a obvykle je rovna u´rovni opra´vneˇnı´ aktua´lnı´ho ko´dove´ho segmentu. Vy´jimkou je vola´nı´ konformnı´ho segmentu vysˇsˇ´ıho opra´vneˇnı´, kdy CPL zu˚sta´va´ na pu˚vodnı´ hodnoteˇ (ko´dovy´ segment tedy pak ma´ vysˇsˇ´ı opra´vneˇnı´, nezˇ je CPL v CS). DPL (descriptor privilege level) je u´rovenˇ opra´vneˇnı´ ulozˇena´ v deskriptoru bra´ny cˇi segmentu. DPL se pouzˇ´ıva´ prˇi prˇ´ıstupu k bra´neˇ cˇi segmentu. 123

Datovy´ segment, TSS a volacı´ bra´na (call gate): DPL je nejnizˇsˇ´ı u´rovenˇ, pro kterou je povolen prˇ´ıstup, tj. vyzˇaduje se CPL≤DPL. Nekonformnı´ ko´dovy´ segment prˇi prˇ´ıme´m vola´nı´: DPL je pozˇadovana´ u´rovenˇ opra´vneˇnı´, tj. vyzˇaduje se CPL=DPL. Nekonformnı´ ko´dovy´ segment prˇi vola´nı´ prˇes bra´nu a konformnı´ ko´dovy´ segment: DPL je nejvysˇsˇ´ı u´rovenˇ opra´vneˇnı´, pro kterou je povolen prˇ´ıstup, tj. vyzˇaduje se CPL≥DPL. RPL (requested privilege level) je pozˇadovana´ u´rovenˇ opra´vneˇnı´, kterou mu˚zˇeme libovolneˇ nastavit do spodnı´ch dvou bitu˚ segmentove´ho selektoru. RPL se pouzˇ´ıva´ k omezenı´ opra´vneˇnı´ k segmentu, anizˇ bychom meˇnili tabulku deskriptoru˚. Podrobneˇji v sekci 11.4.5. Do datovy´ch segmentu˚ lze tedy prˇistupovat, pokud CPL≤DPL a za´rovenˇ RPL≤DPL. Jak jsme jizˇ zmı´nili vy´sˇe, do datovy´ch segmentu˚ lze take´ nacˇ´ıst ko´dovy´ segment, pokud ma´ povoleno cˇtenı´. Podobneˇ lze pouzˇ´ıt segmentovy´ prefix SEGCS ke cˇtenı´ dat prˇ´ımo prˇes CS, opeˇt ale pouze pokud je tam povoleno cˇtenı´. Dodejme, zˇe kromeˇ nastavenı´ hodnoty do segmentovy´ch registru˚ je take´ mozˇno pouzˇ´ıvat vzda´lene´ pointery, kdy se selektor nenacˇ´ıta´ do registru, ale je uveden prˇ´ımo u jedne´ instrukce. SS lze nastavit jen na segment, kdy CPL=RLP=DPL. 11.4.5

Privilegia u ko´dovy´ch segmentu˚

Jak uzˇ bylo videˇt vy´sˇe, u prˇechodu mezi ko´dovy´mi segmenty je situace poneˇkud slozˇiteˇjsˇ´ı nezˇ prˇi pra´ci s daty. Prˇechod na jiny´ ko´dovy´ segment je mozˇny´ prˇ´ımy´m vola´nı´m, prˇes volacı´ bra´nu, prˇes segment TSS nebo prˇes bra´nu u´lohy (task gate). Druhe´ dva prˇ´ıpady vedou k prˇepnutı´ kontextu procesu, cozˇ je specificky´ prˇ´ıpad. Prvnı´ dva prˇ´ıpady pouzˇijeme k beˇzˇne´mu vola´nı´, jak jsme jizˇ zmı´nili vy´sˇe. Procesor rozlisˇuje cˇtyrˇi druhy bran: call, trap, interrupt, task. Kromeˇ prvnı´ho prˇ´ıpadu z nich jde o specificke´ bra´ny pro obsluhy vy´jimek, prˇerusˇenı´ a prˇepı´na´nı´ kontextu˚. Popisˇme si tedy pouze fungova´nı´ beˇzˇne´ volacı´ bra´ny (call gate). Deskriptor volacı´ bra´ny obsahuje selektor a offset ko´du, ktery´ ma´ by´t zavola´n. Procesor za´sadneˇ nesdı´lı´ za´sobnı´k mezi ru˚zny´mi u´rovneˇmi privilegiı´, tj. kazˇde´ vla´kno ma´ cˇtyrˇi za´sobnı´ky, pro kazˇdou u´rovenˇ jeden. Pokud zavola´nı´m prˇes volacı´ bra´nu dojde ke zmeˇneˇ CPL, dojde take´ ke zmeˇneˇ za´sobnı´ku (z TSS se nacˇte jina´ hodnota do SS). Deskriptor volacı´ bra´ny proto take´ uda´va´, kolik dat ze za´sobnı´ku volajı´cı´ho segmentu se ma´ prˇekopı´rovat do za´sobnı´ku volane´ho segmentu (max. 32 buneˇk za´sobnı´ku). Volacı´ bra´nu lze take´ pouzˇ´ıt pro prˇechod mezi 16bitovy´m a 32bitovy´m segmentem. (Procesor mu˚zˇe sdı´let 16bitovy´ a 32bitovy´ ko´d v jednom syste´mu. Je ostatneˇ zna´mo, zˇe Windows umı´ spousˇteˇt programy pro MS-DOS – ty jsou pra´veˇ nacˇ´ıta´ny do 16bitovy´ch segmentu˚.) V 64bitove´m rezˇimu se pouzˇ´ıvajı´ 16bajtove´ deskriptory, ve ktery´ch je mı´sto pro cely´ 64bitovy´ offset. Prˇeda´va´nı´ parametru˚ prˇes za´sobnı´k zde vsˇak podporova´no nenı´ (procesor vsˇak ma´ dvojna´sobny´ pocˇet obecny´ch registru˚, ty lze vyuzˇ´ıt). 16bajtove´ deskriptory 64bitovy´ch bran mohou by´t mı´cha´ny v jedne´ tabulce s 8bajtovy´mi deskriptory 32bitovy´ch bran, syste´m podle typovy´ch bitu˚ doka´zˇe chybny´ prˇ´ıstup k hornı´ polovineˇ velke´ho deskriptoru poznat. Mı´cha´nı´ 32bitovy´ch a 64bitovy´ch bran v jedne´ tabulce je nutne´, protozˇe to je jediny´ zpu˚sob, jak prˇecha´zet mezi 32bitovy´m a 64bitovy´m ko´dem – ten mu˚zˇe koexistovat v jednom syste´mu a pra´veˇ jen pomocı´ bran lze prˇecha´zet naprˇ. mezi 32bitovy´m ko´dem starsˇ´ıho programu a 64bitovy´m ja´drem syste´mu. Prˇipomenˇme take´, zˇe 64bitove´ adresy musejı´ by´t v kanonicke´m tvaru a platı´ to i pro offset ve volacı´ bra´neˇ. 64bitova´ volacı´ bra´na mu˚zˇe smeˇrˇovat jen do 64bitovy´ch ko´dovy´ch segmentu˚.

124

Vola´nı´ bra´ny probı´ha´ pomocı´ libovolne´ standardnı´ volacı´ instrukce. Smeˇrˇuje-li selektor na bra´nu, pak je offset ignorova´n a cele´ vola´nı´ probeˇhne na ba´zi selektoru bra´ny. Procesor prˇecˇte druhy´ selektor z bra´ny, cˇ´ımzˇ zı´ska´ skutecˇny´ cı´l vola´nı´. Pak kontroluje u´rovneˇ privilegiı´. Prˇi vola´nı´ prˇes bra´nu vystupujı´ dva DPL – DPL bra´ny a DPL ko´dove´ho segmentu, obojı´ se kontroluje. DPL bra´ny urcˇuje pozˇadovane´ minima´lnı´ opra´vneˇni pro prˇ´ıstup k bra´neˇ. DPL segmentu se kontroluje standardnı´m zpu˚sobem vu˚cˇi RPL a CPL (za´lezˇ´ı take´ na konformiteˇ segmentu, viz vy´sˇe). Vy´jimkou je vola´nı´ skokem (jmp), ktere´ nesmı´ jı´t do segmentu vysˇsˇ´ı u´rovneˇ privilegiı´ nekonformnı´ho segmentu (u konformnı´ho ano). Smeˇrˇuje-li vola´nı´ u´speˇsˇneˇ do nekonformnı´ho segmentu na jine´ u´rovni opra´vneˇnı´, dojde k prˇepnutı´ za´sobnı´ku. Smeˇrˇuje-li vola´nı´ u´speˇsˇneˇ do segmentu konformnı´ho, tak nedojde ke zmeˇneˇ CPL a prˇepnutı´ za´sobnı´ku. TSS obsahuje SS:ESP za´sobnı´ku pro ring 0–2. Ring 3 nelze volat prˇes bra´nu, takzˇe nepotrˇebuje za´sobnı´k v TSS. Pu˚vodnı´ hodnoty SS:ESP jsou prˇi vola´nı´ ulozˇeny na novy´ za´sobnı´k a po skoncˇenı´ vola´nı´ opeˇt obnoveny. Hodnoty SS:ESP pro ring 0–2 v TSS vsˇak nejsou nikdy meˇneˇny! Prˇi kazˇde´m pouzˇitı´ volacı´ bra´ny jsou hodnoty z TSS pouzˇity jako vy´chozı´. Je veˇcı´ operacˇnı´ho syste´mu, aby do TSS prˇipravil dostatecˇneˇ velke´ za´sobnı´ky pro kazˇdy´ proces. V 64bitove´m rezˇimu se nepouzˇ´ıvajı´ segmenty, proto TSS neobsahuje selektory pro za´sobnı´ky v ring 0–2, ale pouze jejich pocˇa´tecˇnı´ offsety. Jinak je fungova´nı´ obdobne´, pouze vsˇe probı´ha´ 64bitoveˇ. Jak bylo uvedeno vy´sˇe, data na pu˚vodnı´m za´sobnı´ku nejsou prˇekopı´rova´na. Potrˇebujeme-li prˇeda´vat data za´sobnı´kem, pak lze jednodusˇe prˇecˇ´ıst adresu pu˚vodnı´ho RSP z nove´ho za´sobnı´ku a prˇecˇ´ıst si data rucˇneˇ. (Znovu: 64bitovy´ rezˇim nepouzˇ´ıva´ segmenty, takzˇe pu˚vodnı´ a novy´ za´sobnı´k jsou prˇ´ıstupny soucˇasneˇ v pameˇti, kazˇdy´ ma´ jen vrchol na jine´m mı´steˇ. Proto by bylo zbytecˇne´ a neefektivnı´ kopı´rovat data mezi za´sobnı´ky.) Na´vrat z vola´nı´ provedeme instrukcı´ ret. Blı´zky´ na´vrat pouze prˇecˇte offset ze za´sobnı´ku a nastavı´ jej do EIP. Kontroluje se limit aktua´lnı´ho ko´dove´ho segmentu. Vzda´leny´ na´vrat mezi segmenty stejne´ u´rovneˇ opra´vneˇnı´ probeˇhne vyta´hnutı´m dvou hodnot ze za´sobnı´ku a nastavenı´m CS:EIP. Nacˇ´ıta´ se novy´ CS, takzˇe jsou provedeny vsˇechny prˇ´ıslusˇne´ kontroly. Zmeˇna u´rovneˇ opra´vneˇnı´ je mozˇna´ jen smeˇrem dolu˚, cˇili na´vrat je mozˇny´ jen do stejne´ nebo nizˇsˇ´ı u´rovneˇ. (Pochopitelneˇ: Platı´ opak oproti vola´nı´.) Prˇi na´vratu do jine´ u´rovneˇ opra´vneˇnı´ se vracı´ CS:EIP i pu˚vodnı´ za´sobnı´k (bere se ze za´sobnı´ku, tj. musı´ by´t ulozˇen hned za na´vratovou adresou), jsou provedeny vsˇechny prˇ´ıslusˇne´ kontroly. Hodnoty CS:EIP prˇed instrukcı´ na´vratu jsou ztraceny. Nakonec je provedena kontrola vsˇech ostatnı´ch segmentovy´ch registru˚ a ty, ktere´ ukazujı´ do segmentu˚ vysˇsˇ´ı u´rovneˇ opra´vneˇnı´, jsou nulova´ny. Od procesoru Pentium 2 jsou k dispozici take´ instrukce sysenter a sysexit, ktere´ umozˇnˇujı´ vola´nı´ syste´movy´ch sluzˇeb rychlejsˇ´ım zpu˚sobem nezˇ prˇes volacı´ bra´nu. Rychlejsˇ´ı je toto vola´nı´ proto, zˇe pouzˇ´ıva´ dodatecˇne´ registry v procesoru, namı´sto cˇtenı´ hodnot z volacı´ch bran. Dı´ky tomu je me´neˇ prˇ´ıstupu˚ do pameˇti a je trˇeba prova´deˇt me´neˇ kontrol. 11.4.6

Kontrola na u´rovni stra´nek

Kontrola na u´rovni stra´nek funguje na ba´zi stra´nkovacı´ch tabulek. Probı´ha´ prˇi kazˇde´m prˇ´ıstupu do pameˇti a zajisˇt’uje ji samostatna´ jednotka v procesoru pracujı´cı´ paralelneˇ, takzˇe ani tato kontrola nijak nezpomaluje vykona´va´nı´ instrukcı´. Pokud dojde k porusˇenı´ ochrany, je vyhozena vy´jimka page fault (vy´padek stra´nky). Operacˇnı´ syste´m pak musı´ zkontrolovat, zda je vy´jimka zpu˚sobena chybeˇjı´cı´ stra´nkou virtua´lnı´ pameˇti, nebo neopra´vneˇny´m prˇ´ıstupem. Kazˇdy´ za´znam ve stra´nkovacı´ tabulce, vcˇetneˇ adresa´rˇu˚, ma´ dva ochranne´ bity. Prvnı´ z nich oznacˇuje syste´move´ stra´nky – lze jej nastavit pro za´kaz prˇ´ıstupu z ring 3. Stra´nky takto nastavene´ jsou v adresove´m prostoru procesu, ale nejsou prˇ´ıstupne´ z ko´dovy´ch segmentu˚ v ring 3. Vola´nı´m funkce operacˇnı´ho syste´mu prˇes bra´nu dojde ke zmeˇneˇ kontextu procesu a zmeˇneˇ privilegiı´. Tı´m proces zı´ska´ bez pra´ce prˇ´ıstup do takto chra´neˇne´ pameˇti. Prˇitom ru˚zna´ vla´kna te´hozˇ procesu mohou paralelneˇ fungovat v ra´mci jednoho adresove´ho prostoru a pouze ta z nich, ktera´ pra´veˇ vykona´vajı´ syste´move´ funkce, majı´ prˇ´ıstup do syste´movy´ch pameˇt’ovy´ch stra´nek. 125

Druhy´ ochranny´ bit zakazuje za´pis do stra´nky. Tuto ochranu jsme jizˇ zminˇovali naprˇ. v souvislosti s copy–on–write. V ring 0 lze vypnout tuto ochranu, takzˇe procesor mu˚zˇe zapisovat i do stra´nek urcˇeny´ch jen pro cˇtenı´. To je take´ velmi vy´hodne´, proces dı´ky tomu mu˚zˇe sa´m prova´deˇt ru˚zne´ syste´move´ operace nad pameˇtı´. (Uveˇdomme si, zˇe proces ma´ neˇkolik vla´ken a nesˇlo-li by vypnout ochranu za´pisu, tak by v prˇ´ıpadeˇ potrˇeby neˇco zapsat do takove´ pameˇti syste´m musel prˇene´st rˇ´ızenı´ do jine´ho procesu s jinou virtua´lnı´ pameˇtı´. Syste´m by se tak velmi zpomalil a za´rovenˇ zkomplikoval.) Jelikozˇ ochrana je vedena jak na stra´nka´ch, tak na adresa´rˇ´ıch stra´nek, tyto mohou mı´t ru˚zna´ nastavenı´. To mu˚zˇe pomoci prˇedevsˇ´ım u´sporou cˇasu – namı´sto zdlouhave´ho nastavova´nı´ kazˇde´ stra´nkovacı´ tabulky stacˇ´ı nastavit prˇ´ıslusˇny´ stra´nkovacı´ adresa´rˇ. Je to taky jeden z du˚vodu˚, procˇ operacˇnı´ syste´my na x86 pouzˇ´ıvajı´ nelinea´rnı´ organizaci stra´nek (syste´m ma´ ru˚zne´ cˇa´sti „rozha´zene´“ po virtua´lnı´m prostoru). Prˇ´ıstup do GDT, LDT, IDT a pomocny´ch za´sobnı´ku˚ ring 0–2 prˇi vola´nı´ prˇes bra´nu je vzˇdy kontrolova´n jakoby CPL=0. Tı´m je zajisˇteˇno, zˇe syste´m neskoncˇ´ı tota´lnı´m kolapsem naprˇ. prˇi za´kazu prˇ´ıstupu do stra´nek GDT. 11.4.7

NX bit

V rezˇimu PAE je ve stra´nkovacı´ch tabulka´ch jesˇteˇ NX bit (no execute), ktery´ zakazuje spousˇteˇnı´ ko´du v dane´ stra´nce. Jak uzˇ bylo zmı´neˇno v sekci 11.1.3 na straneˇ 111, je to velmi silny´ prostrˇedek ochrany prˇed malwarem (viry atp.), proto operacˇnı´ syste´my podporujı´cı´ NX bit prˇ´ımo startujı´ v rezˇimu PAE, i kdyzˇ ma´ pocˇ´ıtacˇ me´neˇ nezˇ 4GB pameˇti. Upozorneˇme, zˇe NX bit nenı´ podporova´n na vsˇech procesorech, ktere´ podporujı´ PAE. Drˇ´ıve to byla vy´sada drazˇsˇ´ıch modelu˚, nejnoveˇjsˇ´ı procesory jizˇ NX podporujı´ vsˇechny. Spolu s no– execute na ba´zi NX bitu prova´dı´ syste´m majı´cı´ tuto schopnost take´ kontrolu „reserved“ bitu˚. Reserved je rezervovany´ bit a meˇl by by´t sta´le nastaven na vy´chozı´ hodnotu (obvykle nulu). Reserved bity se vyskytujı´ ve vsˇech syste´movy´ch struktura´ch, ktere´ majı´ neˇjakou nevyuzˇitou cˇa´st – pra´veˇ to, co je nevyuzˇite´, je oznacˇeno reserved. Reserved bity jsou urcˇeny pro dalsˇ´ı mozˇne´ rozsˇ´ırˇenı´ procesoru˚ dalsˇ´ımi funkcemi. Vyzˇadova´nı´m a kontrolou spra´vny´ch hodnot (tj. obvykle nul) v reserved bitech syste´m zajisˇt’uje, zˇe soucˇasne´ programy nezpu˚sobı´ neˇjakou nechteˇnou nebo i pla´novanou nehodu na budoucı´ch procesorech. Schopnost kontrolovat reserved bity je nava´za´na na podporu NX bitu. Pru˚vodce studiem Jelikozˇ NX bit je v nejvysˇsˇ´ım bitu 64bitove´ho za´znamu stra´nkovacı´ tabulky, nenı´ ve 32bitove´m rezˇimu k dispozici. Windows XP SP2 a noveˇjsˇ´ı proto u procesoru˚ typu x64 i ve 32bitove´ edici ve skutecˇnosti pracuje v 64bitove´m rezˇimu, aby NX bit mohl by´t vyuzˇit k du˚lezˇite´ ochraneˇ pameˇti prˇed prˇetecˇenı´m bufferu. Windows automaticky detekuje podporu NX bitu na procesoru a prˇecha´zı´ do rezˇimu 64bitove´ho adresova´nı´ (PAE) bez neˇjake´ prˇedchozı´ domluvy s uzˇivatelem. To, zˇe 32bitova´ edice Windows jede v PAE, se lze docˇ´ıst v ovla´dacı´m panelu Syste´m, viz obr.21.

Shrnutı´ V te´to kapitole jsme se veˇnovali hodneˇ technicky´m a prakticky´m veˇcem. V prvnı´ cˇa´sti jsme rozebrali stra´nkova´nı´ ve Windows NT na platformeˇ x86. Zmı´nili jsme AWE, PAE, syste´m typu˚ stra´nek a ochranu pameˇti v NT. Ve druhe´ cˇa´sti kapitoly jsme probrali adresaci na procesorech x86 a x64. Jsou to dva velmi podobne´ typy procesoru˚ a rˇadu vlastnostı´ majı´ spolecˇny´ch, proto byly popsa´ny spolecˇneˇ. Probrali jsme typy adres, prˇeklady mezi nimi, segmentaci, stra´nkova´nı´, u´rovneˇ opra´vneˇnı´, rezˇim PAE, rozdı´ly v 64bitove´m rezˇimu x64. 126

Obra´zek 21: Titulek „Rozsˇ´ırˇenı´ fyzicke´ adresy“ ukazuje, zˇe syste´m beˇzˇ´ı v rezˇimu PAE. Zvla´sˇtnı´ pozornost jsme veˇnovali take´ ochraneˇ pameˇti nava´zane´ na segmentaci a stra´nkova´nı´. Te´ma jizˇ hodneˇ zminˇovane´ v prˇedchozı´ch dvou kapitola´ch jsme nynı´ rozebrali z hlediska procesoru x86 a x64, ktere´ prova´deˇjı´ kontrolu na u´rovni segmentu˚ i na u´rovni stra´nek. Pojmy k zapamatova´nı´ • • • • • • • • • • • • •

AWE (address windowing extension) PAE (physical address extension) ACL (access control list) logical prefetcher deskriptor a selektor tabulky deskriptoru˚ GDT a LDT registry GDTR a LDTR registr CR3 u´rovenˇ opra´vneˇnı´ (privilege level) / ring CPL, DPL, RPL x64 limit segmentu NX (no execute) bit

Kontrolnı´ ota´zky 127

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.

14.

15.

16. 17.

18. 19.

20.

Popisˇte, jak syste´m Windows NT pouzˇ´ıva´ segmentaci pameˇti. Kde a jak funguje AWE? Popisˇte, jak funguje PAE. V cˇem se lisˇ´ı implementace na procesorech x86 a x64? Je stra´nkovacı´ rezˇim PAE vlastnostı´ Windows, nebo mikroprocesoru? Vysveˇtlete vy´hodu rozlisˇova´nı´ rezervovane´ a komitovane´ pameˇti. Co je hlavnı´m du˚vodem toho, zˇe Windows prˇideˇluje pameˇt’azˇ po vynulova´nı´? Popisˇte, jak Windows NT implementuje syste´m pracovnı´ch mnozˇin ra´mcu˚. Co je smyslem logical prefetcheru? Popisˇte jeho funkci. Ktere´ mechanizmy ochrany pameˇti pouzˇ´ıva´ Windows NT? Vysveˇtlete pojmy logicka´, linea´rnı´ a fyzicka´ adresa. Vysveˇtlete, k cˇemu slouzˇ´ı GDT, GDTR, LDT a LDTR. Da´le prˇesneˇ popisˇte, kterou cˇa´st pra´ce ma´ na starosti operacˇnı´ syste´m a kterou hardware. Vysveˇtlete algoritmus segmentace a smysl deskriptoru˚ a selektoru˚ na procesorech x86. Procesory x86 a x64 pouzˇ´ıvajı´ jedno azˇ cˇtyrˇu´rovnˇovou hierarchii stra´nkovacı´ch tabulek. Vysveˇtlete, ktere´ vsˇechny mozˇne´ rezˇimy se dajı´ pouzˇ´ıt, kdy a jak. Uved’te take´, jake´ jsou adresovacı´ mozˇnosti cˇi omezenı´ v jednotlivy´ch rezˇimech, jak se tyto ru˚zne´ rezˇimy dajı´ v jednom syste´mu kombinovat a jaky´ ma´ takovy´ kombinovany´ zpu˚sob stra´nkova´nı´ smysl. Jake´ velikosti stra´nek nebo obecneˇ rˇecˇeno bloku˚ pameˇti pouzˇ´ıvany´ch prˇi stra´nkova´nı´ podporujı´ procesory x86 a x64? Uved’te vsˇechny mozˇnosti a pomocı´ souvislosti s forma´tem stra´nkovacı´ch tabulek vysveˇtlete, procˇ to jsou pra´veˇ tyto velikosti. Vysveˇtlete, jak prˇesneˇ se pouzˇ´ıvajı´ hodnoty u´rovnı´ opra´vneˇnı´ CPL, DPL a RPL. Uved’te take´ odkud se ty hodnoty prˇi vykona´va´nı´ ko´du berou, kde jsou ulozˇeny a kdy vlastneˇ se prova´deˇjı´ kontroly na ba´zi teˇchto hodnot. Vysveˇtlete, jak lze na procesorech x86 volat ko´d mezi ru˚zny´mi ko´dovy´mi segmenty a ru˚zny´mi u´rovneˇmi opra´vneˇnı´. Jak je to prˇi takovy´ch vola´nı´ch s programovy´m za´sobnı´kem? Vysveˇtlete pojem kanonicke´ adresy. Na jaky´ch procesorech se pouzˇ´ıvajı´ a procˇ? Jak kanonicky´ syste´m adres souvisı´ se strukturou a organizacı´ stra´nkovacı´ch struktur? (Na´poveˇda: Stra´nkova´nı´ musı´ by´t funkcˇnı´ a se stejny´m algoritmem bez ohledu na to, kolikabitove´ jsou ve skutecˇnosti adresy na konkre´tnı´m modelu procesoru.) Vysveˇtlete, procˇ prˇes volacı´ bra´nu nelze volat ko´d v ring 3. V operacˇnı´ch syste´mech, ve ktery´ch si jednotliva´ vla´kna sama vykona´vajı´ ko´d syste´movy´ch sluzˇeb, je potrˇeba, aby ko´d i data ja´dra syste´mu byly mapova´ny do adresove´ho prostoru procesu, ale za´rovenˇ tato pameˇt’ musı´ by´t chra´neˇna´, protozˇe proces z bezpecˇnostnı´ch du˚vodu˚ nesmı´ mı´t prˇ´ıstup k pameˇti ja´dra. Jak je toto rˇesˇeno na platformeˇ x86? Procˇ NX bit poma´ha´ chra´nit pocˇ´ıtacˇ proti u´toku typu prˇetecˇenı´ bufferu (buffer overflow)?

Cvicˇenı´ 1. Vyzkousˇejte si spustit Windows v rezˇimu /3GB.

128

12

Souborovy´ syste´m

Studijnı´ cı´le: Tato kapitola zahajuje dalsˇ´ı celek, tentokra´t veˇnovany´ spra´veˇ diskove´ho prostoru. Cı´lem je sezna´mit se se za´kladnı´mi pojmy, jako je soubor a proud, ktere´ pouzˇ´ıva´me na vysˇsˇ´ı u´rovni abstrakce prˇi pra´ci s diskem cˇi prˇesneˇji vneˇjsˇ´ı (sekunda´rnı´) pameˇtı´ obecneˇ. V na´sledujı´cı´ch kapitola´ch se pak podı´va´me na nizˇsˇ´ı u´rovneˇ abstrakce. Klı´cˇova´ slova: soubor, adresa´rˇ, proud, sdı´lenı´ souboru˚, ochrana souboru˚, ACL, DACL Potrˇebny´ cˇas: 140 minut.

´ vod U V prˇedchozı´ch kapitola´ch jsme probrali spra´vu procesoru a pameˇti, nynı´ se dosta´va´me ke trˇetı´ a poslednı´ cˇa´sti pocˇ´ıtacˇe dle von Neumannova modelu – externı´m zarˇ´ızenı´m. Namı´sto obecne´ diskuzi o zarˇ´ızenı´ch se vsˇak budeme nejprve veˇnovat jen te´matu volneˇ ale plynule navazujı´cı´mu na spra´vu operacˇnı´ pameˇti, ktery´m je spra´va diskove´ho prostoru. Vnitrˇnı´ pameˇt’ pocˇ´ıtacˇe nenı´ nikdy dost velka´, aby v nı´ byly ulozˇeny vsˇechny informace dohromady a neusta´le, proto pocˇ´ıtacˇe pouzˇ´ıvajı´ take´ tzv. vneˇjsˇ´ı pameˇt’. Tato oblast prosˇla beˇhem vy´voje pocˇ´ıtacˇu˚ take´ svy´m dramaticky´m vy´vojem a dnes jsme v situaci, kdy pro beˇzˇnou pra´ci pouzˇ´ıva´me v prˇeva´zˇne´ mı´rˇe diskova´ zarˇ´ızenı´. Studium externı´ pameˇti tedy mu˚zˇeme omezit na diskova´ zarˇ´ızenı´ a sta´le pokryjeme te´meˇrˇ 100% prˇ´ıpadu˚. Dalsˇ´ı omezenı´, ktere´ si mu˚zˇeme smeˇle dovolit, je prˇedpokla´dat, zˇe data na disku jsou organizova´na souborovy´m syste´mem. Teˇzˇko si dnes neˇkdo doka´zˇe prˇedstavit, zˇe by sva´ data na disku meˇl ulozˇena jinak nezˇ v souborech a adresa´rˇ´ıch. Z hlediska studia operacˇnı´ch syste´mu˚ je souborovy´ syste´m de facto prˇedstavitelem disku jako takove´ho. Je to totizˇ softwarova´ podoba tohoto hardwarove´ho zarˇ´ızenı´, s diskem pracujeme pouze prostrˇednictvı´m souborove´ho syste´mu a vsˇechno, co je za tı´m, uzˇ se ty´ka´ spı´sˇe hardwaru a do studia operacˇnı´ch syste´mu˚ patrˇ´ı jen okrajoveˇ.

12.1

Soubor

Pru˚vodce studiem Pojem soubor ma´ jednu nedobrou vlastnost – ma´te-li vysveˇtlit cˇloveˇku, ktery´ nikdy nevideˇl pocˇ´ıtacˇ, zˇe tam bude muset pracovat se soubory, zjistı´te, zˇe neˇktere´ veˇci prosteˇ vysveˇtlit nejdou. Na ota´zku: ”Co je to soubor?” pro neˇktere´ lidi neznale´ pocˇ´ıtacˇu˚ prosteˇ odpoveˇd’ neexistuje.

Pocˇ´ıtacˇe obvykle pouzˇ´ıvajı´ k ukla´da´nı´ dat diskova´ cˇi pa´skova´ zarˇ´ızenı´, nejcˇasteˇji s magneticky´m nebo opticky´m me´diem. Operacˇnı´ syste´m definuje abstrakci nad teˇmito zarˇ´ızenı´mi, cˇili jaky´si spolecˇny´ hardwaroveˇ neza´visly´ pohled, kde logickou jednotkou ukla´da´nı´ dat je soubor. Procesy pak pouzˇ´ıvajı´ soubory k trvale´mu cˇi docˇasne´mu ukla´da´nı´ a nacˇ´ıta´nı´ dat, prˇicˇemzˇ u´kolem operacˇnı´ho syste´mu je zajistit mapova´nı´ souboru z podoby, v jake´ ho vidı´ procesy, do fyzicke´ podoby na externı´m zarˇ´ızenı´. Soubor mu˚zˇeme definovat jako pojmenovanou kolekci souvisejı´cı´ch informacı´ ulozˇenou ve vneˇjsˇ´ı pameˇti. Z hlediska procesu je soubor nejmensˇ´ı jednotka vneˇjsˇ´ı pameˇti, kterou lze alokovat. (Cˇili data nelze do vneˇjsˇ´ı pameˇti dostat jinak, nezˇ tak aby byla v souboru). Soubory mohou obsahovat programy i data, mohou to by´t jen posloupnosti bitu˚ cˇi bajtu˚, nebo neˇjaky´ch ˇ ´ıka´me, zˇe soubor ma´ neˇjakou strukturu, te´ prˇitom musı´ slozˇiteˇji strukturovany´ch za´znamu˚. R rozumeˇt samotny´ proces, ktery´ soubor pouzˇ´ıva´. Z hlediska operacˇnı´ho syste´mu je soubor pouze 129

ˇ ´ıka´me tomu take´ data cˇi pojmenovana´ posloupnost bajtu˚ (cˇi jiny´ch jednotek pevne´ de´lky). R teˇlo souboru. Kazˇdy´ soubor ma´ kromeˇ dat take´ neˇjake´ atributy. Je to prˇedevsˇ´ım jme´no, da´le pak typ, velikost, nastavenı´ ochrany/opra´vneˇnı´ prˇ´ıstupu, datum a cˇas, majitel atp. Du˚lezˇity´mi atributy jsou take´ identifika´tor souboru a jeho pozice/umı´steˇnı´ na zarˇ´ızenı´ (tyto dva atributy uzˇivatel souboru prˇ´ımo nevidı´). Atributy o souborech jsou sdruzˇeny v adresa´rˇ´ıch, ktere´ jsou take´ ulozˇeny ve stejne´ vneˇjsˇ´ı pameˇti. V adresa´rˇi by´va´ bud’ cela´ sada atributu˚, nebo jen jme´no a identifika´tor souboru, podle ktere´ho lze najı´t ostatnı´ atributy.

12.2

Souborove´ operace

Operacˇnı´ syste´my, hlavneˇ ty veˇtsˇ´ı, obvykle nabı´zejı´ velke´ mnozˇstvı´ souborovy´ch operacı´. Teˇmi za´kladnı´mi jsou: Create (vytvorˇenı´ souboru) probeˇhne tak, zˇe v adresa´rˇi je vytvorˇen za´znam. Na disku pochopitelneˇ musı´ pro soubor by´t mı´sto. Write (zapisova´nı´ souboru) mu˚zˇe probı´hat bud’ prˇida´va´nı´m dat na konec souboru, nebo prˇepisova´nı´m existujı´cı´ cˇa´sti souboru. Proces zapisuje data tak, zˇe prˇipravı´ v pameˇti veˇtsˇ´ı souvisly´ blok dat k zapsa´nı´, nebo data zapisuje postupneˇ po bajtech cˇi jiny´ch velmi maly´ch cˇa´stech. Read (cˇtenı´ souboru) probı´ha´ tak, zˇe proces prˇipravı´ blok pra´zdne´ pameˇti a necha´ do neˇj nacˇ´ıst cˇa´st souboru. Seek (zmeˇna pozice cˇtenı´/za´pisu) na neˇktery´ch starsˇ´ıch cˇi specia´lnı´ch zarˇ´ızenı´ch ani nemusı´ by´t podporova´na. Erase (smaza´nı´ souboru) probeˇhne tak, zˇe v adresa´rˇi je vyhleda´n za´znam souboru dle jme´na a je zrusˇen. Spolu s tı´m je uvolneˇno vesˇkere´ mı´sto, ktere´ soubor na disku zabı´ral. Truncate (zkra´cenı´ souboru) probeˇhne nastavenı´m nove´ velikosti v za´znamu adresa´rˇe a uvolneˇnı´m te´ cˇa´sti disku, ktera´ jizˇ nebude pouzˇita´. (Prodlouzˇit soubor lze jednodusˇe prˇipsa´nı´m dat na jeho konec. Pokud by soubor nesˇel jednodusˇe zkra´tit, museli bychom jej zrusˇit u´plneˇ a zapsat novou verzi znovu.) Pomocı´ teˇchto sˇesti operacı´ lze prova´deˇt veˇtsˇinu beˇzˇny´ch cˇinnostı´ se soubory. Princip souboru prˇitom pouzˇ´ıva´ veˇtsˇina operacˇnı´ch syste´mu˚ nejen pro disky, ale i pro veˇtsˇinu ostatnı´ch zarˇ´ızenı´ pouzˇ´ıvany´ch ke vstupu cˇi vy´stupu dat. Zatı´mco u mysˇi to mu˚zˇe pu˚sobit komicky, u jiny´ch zarˇ´ızenı´ lze videˇt mnoho vlastnostı´ velmi podobny´ch souboru˚m na disku, a proto je tento jednotny´ prˇ´ıstup typu „Vsˇechno je soubor.“ prˇ´ıjemny´ a dobrˇe se s nı´m pracuje. Pro prˇ´ıklad: Kla´vesnice funguje jako soubor, ze ktere´ho lze jen cˇ´ıst. Nelze prova´deˇt write, seek, erase, ani truncate. Prˇi zavola´nı´ funkce read mu˚zˇe by´t proces blokova´n azˇ do doby, nezˇ je k dispozici neˇjaka´ kla´vesa. Z minulosti prˇitom specia´lneˇ u kla´vesnice prˇetrval zvyk, zˇe data z kla´vesnice jdou do procesu po cely´ch rˇa´dcı´ch, tj. po stisku kla´vesy Enter se v souboru kla´vesnice „objevı´“ znaky cele´ho rˇa´dku najednou. Potom je proces opeˇt blokova´n azˇ do zada´nı´ dalsˇ´ıho rˇa´dku. Toto chova´nı´ ma´ historicke´ du˚vody a obvykle jej lze i vypnout. Druhy´ prˇ´ıklad: Tiska´rna funguje jako soubor, do ktere´ho lze jen zapisovat. Nelze prova´deˇt read, seek, erase cˇi truncate. Tiska´rna tı´mto zpu˚sobem funguje bez ohledu na to, zda je textova´ (tiskne prˇ´ımo text), nebo graficka´ (tiskne jednotlive´ male´ tecˇky – doty).

130

12.3

Otevrˇene´ soubory a handly

Aby syste´m nemusel prˇi kazˇde´ operaci hledat v adresa´rˇi soubor dle jme´na, pouzˇ´ıva´ se operace open – otevrˇenı´ souboru. Otevrˇenı´ je operace, prˇi ktere´ syste´m najde v adresa´rˇi soubor dle jme´na, nacˇte jeho atributy a zacˇne si udrzˇovat v pameˇti informace o tomto souboru. Syste´m vra´tı´ procesu tzv. handl (neboli rukojet’, z anglicke´ho handle). Prˇi dalsˇ´ı pra´ci pak proces identifikuje soubor handlem, nikoli jme´nem, cˇ´ımzˇ se pra´ce s diskem velmi urychlı´. Po skoncˇenı´ pra´ce proces soubor zavrˇe (close). Syste´m otvı´ra´nı´ souboru˚ a handlu˚ se komplikuje tı´m, zˇe v syste´mu je obvykle soubeˇh vı´ce procesu˚. Ty mohou pracovat se stejny´m diskem a dokonce i se stejny´m souborem. Syste´m si proto vede globa´lnı´ seznam otevrˇeny´ch souboru˚ a pak jesˇteˇ loka´lnı´ seznam otevrˇeny´ch souboru˚ pro kazˇdy´ proces zvla´sˇt’, kde ma´ naprˇ. aktua´lnı´ pozice cˇtenı´ cˇi za´pisu a samozrˇejmeˇ odkaz na soubor do globa´lnı´ho seznamu. V globa´lnı´m seznamu je u kazˇde´ho souboru mj. pocˇet otevrˇenı´ procesy. Soubor zu˚sta´va´ fyzicky otevrˇen, dokud s nı´m pracuje alesponˇ jeden proces. Jakmile pocˇ´ıtadlo otevrˇenı´ klesne na nulu, je soubor fyzicky uzavrˇen.

12.4

Zamyka´nı´ souboru˚ (lock)

Modernı´ operacˇnı´ syste´my obvykle umeˇjı´ i zamykat otevrˇene´ soubory. Smyslem zamyka´nı´ je, zˇe proces pracujı´cı´ se souborem si zamknutı´m zajistı´, zˇe jiny´ proces nebude k souboru prˇistupovat. Zamyka´nı´ ma´ vy´znam ve dvou prˇ´ıpadech: • Proces bude soubor meˇnit a nechce, aby jine´ procesy cˇetly obsah souboru beˇhem za´pisu, kdy jsou tam cˇa´stecˇneˇ stara´ a cˇa´stecˇneˇ nova´ data, ale azˇ po sestavenı´ cele´ nove´ verze. • Proces bude soubor cˇ´ıst a nechce, aby mu jej beˇhem toho jiny´ proces zacˇal meˇnit a zpu˚sobil tak prˇecˇtenı´ nekonzistentnı´ho (cˇa´stecˇneˇ stare´ho a cˇa´stecˇneˇ nove´ho) obsahu. Soubor lze obvykle zamknout bud’ jen pro cˇtenı´, nebo pro za´pis. Zamknutı´ pro cˇtenı´ umozˇnˇuje nerusˇene´ cˇtenı´, ale neblokuje jine´ procesy, ktere´ chteˇjı´ take´ jen cˇ´ıst. Zamknutı´ pro za´pis umozˇnˇuje nerusˇeneˇ cˇ´ıst i zapisovat a jine´ procesy nemajı´ k souboru prˇ´ıstup. V neˇktery´ch syste´mech se zamyka´nı´ takto nerozlisˇuje, de facto tedy existuje jen zamknutı´ pro za´pis. Dalsˇ´ı skupina operacˇnı´ch syste´mu˚ neumozˇnˇuje soucˇasny´ prˇ´ıstup vı´ce procesu˚ k jednomu souboru, tam je tedy de facto za´mek pro za´pis automaticky aktivova´n prˇi kazˇde´m otevrˇenı´ souboru. (Takto se chovajı´ prˇedevsˇ´ım syste´my starsˇ´ı a/nebo jednou´lohove´.) Modernı´ syste´my naopak umozˇnˇujı´ zamykat soubory i po cˇa´stech a umozˇnˇujı´ tak naprˇ. soucˇasny´ chra´neˇny´ za´pis dvou procesu˚, kdy kazˇdy´ si pro sebe zamkne „svou cˇa´st“ souboru. Pru˚vodce studiem O zamyka´nı´ byla rˇecˇ jizˇ v kapitole 7 o synchronizaci. Samostatne´ typy za´mku˚ pro cˇtenı´ a za´pis jsou vlastneˇ zobecneˇnı´m principu, ktery´ zna´me jako mutex, a toto se mu˚zˇe v praxi hodit i prˇi pra´ci s jiny´mi typy objektu˚ nezˇ jen se soubory. Proto taky jisteˇ neprˇekvapı´, zˇe tyto za´mky na rˇadeˇ operacˇnı´ch syste´mu˚ najdeme i mezi klasicky´mi synchronizacˇnı´mi objekty, obvykle jako „reader writer lock“ (za´mek cˇtena´rˇu˚ a pı´sarˇu˚).

12.5

Typy souboru˚

Typy souboru˚ jsou dobrˇe zna´my´m prvkem, takzˇe si jen strucˇneˇ shrnˇme, co je jejich smyslem. Rˇada operacˇnı´ch syste´mu˚ zava´dı´ souborove´ typy proto, aby bylo jasne´, co je obsahem dane´ho souboru a co tedy se souborem je trˇeba cˇi mozˇno deˇlat. V praxi se osveˇdcˇily tyto zpu˚soby identifikace typu souboru:

131

Prˇ´ıpona na´zvu Nejcˇasteˇjsˇ´ım zpu˚sobem, jak identifikovat typ souboru, je prˇ´ıpona na´zvu, ktera´ je soucˇa´stı´ na´zvu (cˇa´st na´zvu za poslednı´ tecˇkou). Kvu˚li omezenı´m MS-DOSu se nejvı´ce rozsˇ´ırˇily prˇ´ıpony trˇ´ıznakove´, ale dnes jizˇ jsou beˇzˇne´ i jine´ (kratsˇ´ı i delsˇ´ı). Rˇada prˇ´ıpon ma´ de facto standardnı´ vy´znam naprˇ´ıcˇ operacˇnı´mi syste´my a neˇktere´ existujı´ v trˇ´ı- i vı´ceznakove´ podobeˇ (naprˇ. mı´sto jpeg, mpeg cˇi html cˇasto vidı´me zkra´cene´ tvary jpg, mpg, respektive htm). Magic number Unixove´ syste´my hodneˇ pouzˇ´ıvajı´ tzv. „magicke´“ hodnoty. Jsou to cˇ´ısla ulozˇena´ na zacˇa´tku souboru (prˇ´ımo v datech), obvykle v prvnı´ch dvou bajtech. Typ souboru se pak pozna´ prˇecˇtenı´m jeho zacˇa´tku a zjisˇteˇnı´m hodnot prvnı´ch dvou bajtu˚. Tato metoda se pouzˇ´ıva´ i mimo Unix, naprˇ. MS-DOS a Windows majı´ ve spustitelny´ch souborech znacˇku „MZ“ (nebo „ZM“); textove´ soubory v neˇktere´m z ko´dova´nı´ Unicode (naprˇ. UTF-8 nebo UTF-16) majı´ znacˇku vzˇdy a bez ohledu na operacˇnı´ syste´m. Takove´ soubory tedy mohou mı´t nakonec libovolnou prˇ´ıponu a syste´m stejneˇ doka´zˇe poznat, co v souboru je. Explicitnı´ metadata Typ souboru mu˚zˇe by´t explicitneˇ ulozˇen neˇkam do souborove´ho syste´mu, obvykle neˇkam do metadat souboru. Hovorˇ´ıme o metadatech, protozˇe jde o informace o souboru, ne samotny´ soubor. Je mnoho zpu˚sobu˚, jak toto realizovat, vzˇdy je vsˇak proble´m s kompatibilitou a prˇenositelnostı´, protozˇe tato metadata se obvykle prˇekopı´rova´nı´m souboru na jine´ mı´sto ztra´cı´ (cˇasto se kopı´ruje obsah souboru, jme´no, datum atp., ale ne specia´lnı´ metadata). Proto pouzˇ´ıva´nı´ metadat nenı´ zvla´sˇteˇ v prostrˇedı´ heterogennı´ch pocˇ´ıtacˇovy´ch sı´tı´ prˇ´ılisˇ prakticke´. Mac OS X beˇzˇneˇ pouzˇ´ıva´ prˇ´ıpony souboru˚ a stejneˇ jako Windows je take´ obvykle skry´va´ prˇed uzˇivatelem (cozˇ je jisty´ zpu˚sob ochrany, protozˇe na´hodne´ prˇejmenova´nı´ prˇ´ıpony mu˚zˇe ve´st k jiste´mu druhu narusˇenı´ bezpecˇnosti). Mac OS vsˇak pouzˇ´ıva´ take´ metadata, kde kromeˇ typu souboru ukla´da´ take´ identifika´tor aplikace, ktera´ soubor vytvorˇila. Prˇi pokusu otevrˇ´ıt pozdeˇji tento soubor pak syste´m vı´, ke ktere´ aplikaci patrˇ´ı. (Tato „znacˇka“ vznika´ automaticky, kdyzˇ proces zalozˇ´ı novy´ soubor na disku.) Pru˚vodce studiem Posˇlete-li soubor do tiska´rny, vytiskne se spra´vneˇ jen tehdy, kdyzˇ jeho obsahem je text. Podporuje-li vsˇak operacˇnı´ syste´m typy souboru˚, mu˚zˇe naprˇ´ıklad automaticky cha´pat, zˇe soubor JPEG je obra´zek a pro jeho tisk pouzˇ´ıt specia´lnı´ program pro tisk obra´zku˚. Podobneˇ prˇi spousˇteˇnı´ souboru˚ syste´m mu˚zˇe pomocı´ typu˚ snadno rozlisˇit, zda spousˇtı´te bina´rnı´ program (naprˇ´ıklad tzv. „exe“ ve Windows) nebo soubor obsahuje jen data, ktera´ je pro spusˇteˇnı´ potrˇeba zpracovat jiny´m programem.

12.6

Struktura souboru˚

Typy souboru˚ mohou poslouzˇit take´ k urcˇenı´ vnitrˇnı´ struktury souboru. V soucˇasnosti vsˇak u operacˇnı´ch syste´mu˚ prˇevla´da´ zjednodusˇeny´ princip prˇevzaty´ z Unixu, kdy syste´m podporuje jen jedinou strukturu souboru˚ – kazˇdy´ soubor je obycˇejny´ proud bajtu˚; vy´znam teˇmto bajtu˚m mu˚zˇe da´t jak operacˇnı´ syste´m, tak jednotlive´ programy, ale data souboru˚ jsou plneˇ popsatelna´ touto posloupnostı´ bajtu˚. Neˇktere´ operacˇnı´ syste´my podporujı´ ru˚zne´ souborove´ struktury, naprˇ. pro spustitelne´ soubory mu˚zˇe by´t vy´hodna´ jina´ struktura, nezˇ je proud bajtu˚. Podporuje-li operacˇnı´ syste´m vı´ce souborovy´ch struktur, pra´ce se soubory je pak jednodusˇsˇ´ı, aplikacˇnı´ programy si vsˇak musı´ vystacˇit 132

s omezeny´m vy´beˇrem. Praxe uka´zala, zˇe zobecneˇnı´ na jednotnou a jednoduchou strukturu prˇina´sˇ´ı flexibilitu. Naprˇ´ıklad kopii proudu lze udeˇlat tak, zˇe nacˇteme jeho obsah do pole a zapı´sˇeme jej pak do nove´ho souboru. Soubory slozˇiteˇjsˇ´ıch struktur by takto kopı´rovat nebylo mozˇne´. Mac OS ma´ u kazˇde´ho souboru dva proudy: data a prostrˇedky. V datove´m proudu je klasicky´ obsah souboru, naprˇ. ko´d programu, v prostrˇedkove´m proudu jsou dalsˇ´ı prostrˇedky pouzˇ´ıvane´ tı´mto programem, naprˇ. texty apod. Ostatnı´ operacˇnı´ syste´my sice taky cˇasto pouzˇ´ıvajı´ syste´m prostrˇedku˚ u spustitelny´ch programu˚, umı´st’ujı´ je vsˇak obvykle neˇkam do samotne´ho datove´ho proudu (naprˇ. na jeho konec, za ko´d programu). Souborovy´ syste´m NTFS pouzˇ´ıvany´ na Windows NT zobecnˇuje prˇ´ıstup zna´my´ z Mac OS tak, zˇe umozˇnˇuje kromeˇ datove´ho proudu prˇirˇadit k souboru libovolny´ pocˇet dalsˇ´ıch proudu˚. V praxi je vsˇak tato funkcionalita vyuzˇ´ıva´na velmi ma´lo (naprˇ. Microsoft SQL Server). Samotny´ syste´m NT umozˇnˇuje do alternativnı´ho proudu NTFS ukla´dat pozna´mky o souborech (jako jme´no autora, popis obsahu atp.), opeˇt jde vsˇak o pomeˇrneˇ ma´lo pouzˇ´ıvanou funkcionalitu a neˇktere´ hloupeˇjsˇ´ı na´hrady Pru˚zkumnı´ka mohou prˇi kopı´rova´nı´ souboru˚ tyto informace dokonce ztra´cet (tı´m, zˇe prˇekopı´rujı´ jen datovy´ proud). Vı´ce o NTFS se dozvı´me v sekci 14.4 na straneˇ 161. Fyzicka´ struktura souboru Kromeˇ uzˇivatelske´ho pohledu majı´ soubory jesˇteˇ svou fyzickou strukturu. Ukla´da´nı´ souboru˚ na disk funguje obvykle po jisty´ch veˇtsˇ´ıch blocı´ch (sektorech cˇi klastrech), o velikosti nejcˇasteˇji 512, 1024 nebo 2048 bajtu˚. K proudu tedy prˇistupujeme po jednotlivy´ch bajtech, ale k disku se prˇistupuje jen po cely´ch sektorech cˇi klastrech. Velikost sektoru je nejcˇasteˇji 512 bajtu˚ (z cˇisteˇ historicky´ch du˚vodu˚), klastr je skupina sousednı´ch sektoru˚ a slouzˇ´ı ke zveˇtsˇenı´ jednotky prˇ´ıstupu na disk obvykle na zmı´neˇny´ch neˇkolik ma´lo KB. Pru˚vodce studiem Hardwarova´ pozna´mka: Disky se deˇlı´ na sektory proto, zˇe prˇ´ımy´ prˇ´ıstup k disku by byl velmi slozˇity´, protozˇe by bylo obtı´zˇne´ zjistit, kde prˇesneˇ v dane´m okamzˇiku cˇtecı´ hlavicˇka je. Takto jsou na disku ulozˇeny hlavicˇky sektoru˚ a mezi nimi jejich data. Cˇ´ım mensˇ´ı jsou sektory, tı´m me´neˇ dat se celkoveˇ na disk vejde, protozˇe tam bude vı´ce hlavicˇek. Naopak veˇtsˇ´ı sektory prˇina´sˇejı´ vnitrˇnı´ fragmentaci (viz popis fragmentace v kapitole 9.2 o organizaci pameˇti na straneˇ 85) a opeˇt tedy nizˇsˇ´ı vyuzˇitı´. Klastry (clustery) jsou zavedeny proto, zˇe prˇed prˇecˇtenı´m sektoru je trˇeba jej najı´t. Hlavicˇka cˇeka´, azˇ se neusta´le ota´cˇejı´cı´ se disk natocˇ´ı do spra´vne´ polohy. Cˇtenı´m vı´ce sektoru˚ v rˇadeˇ za sebou tedy usˇetrˇ´ıme cˇas. Nevy´hodou veˇtsˇ´ıch klastru˚ je opeˇt veˇtsˇ´ı vnitrˇnı´ fragmentace, snizˇuje se tı´m vsˇak naopak vneˇjsˇ´ı fragmentace a take´ na´roky na evidenci prˇideˇlene´ho mı´sta. Z pohledu fragmentace je tedy fyzicka´ organizace disku podobna´ spra´veˇ fyzicke´ pameˇti.

Potrˇebujeme-li cˇ´ıst me´neˇ nezˇ cely´ klastr, operacˇnı´ syste´m vzˇdy musı´ nacˇ´ıst cely´ klastr a uchovat si jej v bufferu. Prˇi za´pisu necele´ho klastru musı´ syste´m dokonce nejprve nacˇ´ıst cely´ klastr do bufferu, pak prove´st pozˇadovanou zmeˇnu a pak zapsat cely´ klastr. Za´pis tedy mu˚zˇe by´t velmi pomaly´, pokud se nepostupuje rozumneˇ; prˇi za´pisu je velmi du˚lezˇita´ spra´vna´ funkce diskove´ cache.

12.7

Prˇ´ıstup k souboru˚m

Za´kladnı´m zpu˚sobem pra´ce s proudem je sekvencˇnı´ prˇ´ıstup. Cˇteme cely´ proud od zacˇa´tku a jedina´ dalsˇ´ı operace je rewind (tzv. „prˇetocˇenı´ zpeˇt“, odpovı´da´ seek na zacˇa´tek). Prˇi sekvencˇnı´m prˇ´ıstupu je operace seek omezena jen na prˇesun na zacˇa´tek a na konec souboru. (Na konec se 133

prˇesouva´me, chceme-li k neˇmu prˇipisovat dalsˇ´ı data.) Vy´hodou sekvencˇnı´ho prˇ´ıstupu je, zˇe je pouzˇitelny´ pro ru˚zna´ datova´ me´dia a zdroje, vcˇetneˇ pocˇ´ıtacˇove´ sı´teˇ cˇi pa´skovy´ch zarˇ´ızenı´. Druhy´m cˇasto pouzˇ´ıvany´m zpu˚sobem pra´ce s proudem je prˇ´ımy´ prˇ´ıstup. Ten prˇistupuje pouze k vybrany´m cˇa´stem souboru, kdy pomocı´ operace seek nejprve prˇesune pozici cˇtenı´/za´pisu na pozˇadovane´ mı´sto a pak s nı´m pracuje. Tento zpu˚sob pra´ce je vhodny´ zejme´na pro diskove´ soubory, protozˇe pra´veˇ na disku lze snadno prˇesouvat pozice cˇtenı´/za´pisu na libovolne´ mı´sto. Pru˚vodce studiem ˇ ´ıka´me, zˇe disk umozˇnˇuje na´hodny´ prˇ´ıstup, protozˇe operacı´ seek lze prˇejı´t na libovolne´ R mı´sto souboru. Prˇ´ımy´ prˇ´ıstup k souboru pak funguje tak, zˇe data v souboru se skla´dajı´ z mnoha stejneˇ velky´ch za´znamu˚ (datovy´ch struktur), kde program nejprve stanovı´, kolika´ty´ za´znam v souboru potrˇebuje, tuto hodnotu vyna´sobı´ de´lkou za´znamu v souboru a dı´ky mozˇnosti na´hodne´ho prˇ´ıstupu zı´ska´ prˇ´ımy´ prˇ´ıstup k pozˇadovany´m datu˚m. Pojmy na´hodny´ a prˇ´ımy´ prˇ´ıstup tedy pak v praxi sply´vajı´ a vyjadrˇujı´ zde de facto tote´zˇ. S pomocı´ na´hodne´ho prˇ´ıstupu lze samozrˇejmeˇ realizovat i rˇadu dalsˇ´ıch vlastnı´ch zpu˚sobu˚ prˇ´ıstupu k souboru.

12.8

Deˇlenı´ disku a adresa´rˇe

V soucˇasne´ dobeˇ by´vajı´ disky kapacitneˇ jizˇ pomeˇrneˇ velke´ a doka´zˇ´ı pojmout take´ velke´ mnozˇstvı´ souboru˚, takzˇe nikoho neprˇekvapı´, zˇe tyto soubory se neˇjaky´m zpu˚sobem organizujı´ pro lepsˇ´ı prˇehlednost. Je vsˇeobecneˇ zna´mo, zˇe za´kladnı´m na´strojem k organizaci souboru˚ jsou adresa´rˇe, ze ktery´ch lze vytvorˇit libovolnou stromovou strukturu. Platı´ jednoduche´ pravidlo, zˇe existuje vzˇdy pra´veˇ jeden korˇenovy´ adresa´rˇ a kazˇdy´ adresa´rˇ mu˚zˇe obsahovat soubory nebo dalsˇ´ı adresa´rˇe. Veˇtsˇ´ı disky vsˇak kromeˇ adresa´rˇu˚ deˇlı´me jesˇteˇ na samostatne´ cˇa´sti zvane´ partition (z anglicˇtiny, cˇesky jednodusˇe „cˇa´st disku“ cˇi oddı´l). Toto deˇlenı´ je na u´rovni fyzicke´ho disku. Z pohledu operacˇnı´ho syste´mu se diskova´ pameˇt’ skla´da´ ze svazku˚ (anglicky volume) – kazˇdy´ svazek je jednou instancı´ neˇjake´ho souborove´ho syste´mu, naprˇ. ve Windows jsou svazky oznacˇova´ny klasicky pı´smeny s dvojtecˇkou (A:, C:, D: atd.). Je zrˇejme´, zˇe svazek vytvorˇ´ıme naforma´tova´nı´m neˇjake´ cˇa´sti disku (oddı´lu) do neˇjake´ho souborove´ho syste´mu. Jednotlive´ svazky jsou na sobeˇ navza´jem logicky zcela neza´visle´, avsˇak mohou by´t na stejne´m fyzicke´m disku, dokonce mu˚zˇe by´t vı´ce svazku˚ v jednom oddı´lu (avsˇak tyto nejsou bootovatelne´). Podobneˇ neˇktere´ operacˇnı´ syste´my umozˇnˇujı´ spojovat vı´ce cˇa´stı´ (oddı´lu˚) dohromady pro vytvorˇenı´ veˇtsˇ´ıch svazku˚, cˇi prˇipojovat cele´ svazky jako virtua´lnı´ adresa´rˇe do jiny´ch svazku˚. Tento poslednı´ zpu˚sob je beˇzˇny´ na Unixovy´ch syste´mech, ale je mozˇno jej pouzˇ´ıt take´ ve Windows (mu˚zˇeme se tak zcela zbavit diskovy´ch pı´smen a onoho C: stylu cest, korˇenovy´ adresa´rˇ pak take´ znacˇ´ıme jen lomı´tkem). Prˇipojova´nı´ svazku˚ do souborove´ho syste´mu se nazy´va´ mounting cˇi mountova´nı´ (anglicky, sloveso mount). Prˇesne´ fungova´nı´ te´to operace je samozrˇejmeˇ za´visle´ na konkre´tnı´m syste´mu, ve Windows naprˇ. lze pouzˇ´ıvat svazky i bez explicitnı´ho mountova´nı´ ve tvaru \\?\Volume{GUID}\, kde GUID je jednoznacˇny´ identifika´tor svazku. Pru˚vodce studiem Unix umozˇnˇuje prˇipojit svazek do libovolne´ho adresa´rˇe. Vsˇechny prˇipojene´ svazky pak jsou soucˇa´stı´ jednoho adresa´rˇove´ho stromu. Windows NT jako vy´chozı´ pouzˇ´ıva´ pı´smena (C: aj.), z historicky´ch du˚vodu˚ (pozu˚statek po MS-DOSu). Zajı´mave´ take´ je, zˇe v Unixu se beˇzˇneˇ ru˚zne´ cˇa´sti syste´mu a data deˇlı´ do vı´ce svazku˚, zatı´mco Microsoft da´va´ prˇednost pouzˇ´ıva´nı´ jednoho svazku pro vsˇe (C:). NT prˇitom interneˇ pracuje na podobne´m principu jako Unix, oba syste´my prˇipojujı´ svazky pomocı´ tzv. bodu˚ prˇipojenı´ (anglicky mount point). Mount point je cesta, ktera´ se prezentuje jako adresa´rˇ, ale ve skutecˇnosti je branou do svazku.

134

Mount point lze zarˇadit kamkoliv do adresa´rˇove´ho stromu a umozˇnit tak de facto prˇ´ıstup odkudkoliv kamkoliv. (Ve Windows se pouzˇ´ıva´nı´ te´to funkcionality te´meˇrˇ nerozsˇ´ırˇilo.)

Adresa´rˇove´ operace Beˇzˇne´ adresa´rˇove´ operace jsou vsˇeobecneˇ zna´me´, proto si uved’me jen strucˇny´ vy´cˇet: nalezenı´ souboru, zalozˇenı´ souboru, odstraneˇnı´ souboru, zı´ska´nı´ seznamu souboru˚, prˇejmenova´nı´ souboru, procha´zenı´ adresa´rˇovy´m stromem. Adresa´rˇova´ struktura Existuje vı´ce mozˇnostı´, jak organizovat adresa´rˇe. Nejbeˇzˇneˇjsˇ´ı, jak uzˇ jsme zmı´nili, je stromova´ struktura. Ta se dnes pouzˇ´ıva´ zejme´na z historicky´ch du˚vodu˚. Vzhledem k tomu, zˇe pouze obecna´ grafova´ struktura, kde jsou povolene´ libovolne´ vazby mezi adresa´rˇi a soubory, je jednoznacˇneˇ flexibilneˇjsˇ´ı, ale take´ mnohem slozˇiteˇjsˇ´ı na u´drzˇbu syste´mu, adresa´rˇova´ struktura se jevı´ jako nejlepsˇ´ı z hlediska veˇtsˇiny aplikacı´. Kromeˇ slozˇiteˇjsˇ´ı grafove´ struktury lze adresa´rˇe organizovat i jednodusˇsˇ´ım zpu˚sobem. Nejjednodusˇsˇ´ı syste´my nepouzˇ´ıvajı´ adresa´rˇe vu˚bec, takzˇe vsˇechny soubory jsou na stejne´ u´rovni, prˇ´ıpadneˇ umozˇnˇujı´ jen jednu u´rovenˇ adresa´rˇu˚, kde jiny´ nezˇ korˇenovy´ adresa´rˇ sa´m nemu˚zˇe dalsˇ´ı adresa´rˇe obsahovat. Jednoduche´ vı´ceuzˇivatelske´ syste´my pak mohou deˇlit soubory podle uzˇivatelu˚, takzˇe na nejvysˇsˇ´ı u´rovni je skryta´ adresa´rˇova´ u´rovenˇ, kde kazˇdy´ adresa´rˇ patrˇ´ı jednomu uzˇivateli syste´mu. Vy´sledkem pak mu˚zˇe by´t adresa´rˇova´ dvoju´rovnˇova´ struktura – hlavnı´ syste´movy´ adresa´rˇ slouzˇ´ı k rozdeˇlenı´ dat uzˇivatelu˚, kazˇdy´ z nich pak mu˚zˇe mı´t jednu svou adresa´rˇovou u´rovenˇ. Vsˇechny tyto varianty pak lze zobecnit do stromove´ struktury. Vy´sˇe zmı´neˇna´ grafova´ struktura je dalsˇ´ım zobecneˇnı´m vsˇech ostatnı´ch typu˚ struktur. Modernı´ stromove´ souborove´ syste´my umozˇnˇujı´ prˇi zachova´nı´ stromove´ struktury definovat libovolne´ dodatecˇne´ vazby, cˇ´ımzˇ zı´ska´va´me mozˇnost de facto grafove´ organizace (tzv. hard link a soft link). Vy´hodne´ je to vsˇak jen pro neˇktere´ specia´lnı´ aplikace cˇi situace. Pru˚vodce studiem Hard link je ukazatel na fyzicke´ teˇlo souboru na disku. Kazˇdy´ pojmenovany´ soubor na disku je tedy de facto hard link. Modernı´ souborove´ syste´my pak umozˇnˇujı´ vytva´rˇet vı´ce hard linku˚ k jednomu souboru. Unixove´ syste´my k tomu majı´ prˇ´ıkaz ln, NT ma´ prˇ´ıkaz fsutil hardlink a od verze Vista take´ noveˇ mklink. Soft link (cˇasto take´ nazy´va´no symbolic link cˇi symlink) je odkaz na jiny´ soubor, ktery´ je specifikova´n jeho cestou. Soft link mu˚zˇe odkazovat i na jiny´ soft link. V Unixovy´ch syste´mech se soft link vytva´rˇ´ı opeˇt prˇ´ıkazem ln (s jiny´mi parametry). NT podporuje soft linky jen na u´rovni shellu, tzn. samotny´ operacˇnı´ syste´m je nepodporuje a lze je pouzˇ´ıvat jen v Pru˚zkumnı´kovi – jedna´ se o soubory s prˇ´ıponou lnk (za´stupce) a url (za´stupce internetove´ adresy). Na´hrady shellu (naprˇ. ru˚zne´ „commandery“) podporujı´ tyto za´stupce take´, ale obecneˇ v libovolny´ch programech jej pouzˇ´ıvat nelze bez dalsˇ´ıch u´prav. Pro zajı´mavost dodejme, zˇe syste´m NTFS ve skutecˇnosti soft linky podporuje, ale Windows nema´ zˇa´dny´ na´stroj, jak s nimi pracovat [Wiki]. Od verze Vista jizˇ najdeme podporu soft linku˚ prˇ´ımo na u´rovni souborove´ho syste´mu, pracuje se s nimi standardnı´m prˇ´ıkazem mklink. Informacˇnı´ zdroje o podporˇe linku˚ ve Windows jsou cˇasto dosti matoucı´, nasˇteˇstı´ se jedna´ o funkci ve Windows velmi ma´lo pouzˇ´ıvanou. Za zmı´nku stojı´ i fakt, zˇe soft link ma´ vlastnı´ ACL (viz nı´zˇe). Nejveˇtsˇ´ı proble´m prˇi pouzˇ´ıva´nı´ linku˚ je omyl uzˇivatele, ktery´ ve snaze smazat link ve skutecˇnosti smazˇe obsah cı´love´ho adresa´rˇe cˇi souboru. 135

Prˇi pra´ci v adresa´rˇove´ strukturˇe pracuje proces vzˇdy v neˇjake´m aktua´lnı´m adresa´rˇi. Prˇi pokusu o prˇ´ıstup k souboru˚m pak ma´ v dany´ okamzˇik prˇ´ıstupne´ jen soubory aktua´lnı´ho adresa´rˇe, soubory ostatnı´ch adresa´rˇu˚ pak musı´ kromeˇ jme´na identifikovat take´ urcˇenı´m absolutnı´ cesty k jeho adresa´rˇi, nebo relativnı´ cesty vztazˇene´ k absolutnı´m adresa´rˇi. Pojem cesta prˇitom obvykle oznacˇuje prˇ´ımo konkre´tnı´ soubor, ne jen jeho adresa´rˇ, takzˇe jesˇteˇ mu˚zˇeme pouzˇ´ıvat termı´ny absolutnı´ adresa´rˇ a relativnı´ adresa´rˇ. Pokud budeme cha´pat adresa´rˇ jako specia´lnı´ typ souboru, pak cesta mu˚zˇe oznacˇovat take´ adresa´rˇe. Ve stromove´ strukturˇe by´va´ zvykem cestu oznacˇovat jako posloupnost jmen adresa´rˇu˚ a souboru, kde jednotlive´ na´zvy oddeˇlujeme lomı´tkem. Prˇitom ve Windows obvykle zpeˇtny´m lomı´tkem \, ve veˇtsˇineˇ ostatnı´ch syste´mu˚ obycˇejny´m /. Rozlisˇenı´ absolutnı´ a relativnı´ cesty se deˇla´ take´ v ru˚zny´ch syste´mech ru˚zneˇ, v Unixu je absolutnı´ cestou kazˇda´ zacˇ´ınajı´cı´ lomı´tkem, ve Windows pak absolutnı´ cesta zacˇ´ına´ dveˇma lomı´tky nebo jme´nem disku (pı´smenem s dvojtecˇkou) a lomı´tkem. MS-DOS a neˇktere´ verze Windows pouzˇ´ıvajı´ jesˇteˇ dalsˇ´ı zvla´sˇtnost: Aktua´lnı´ adresa´rˇ je zvla´sˇt’pro kazˇdy´ svazek, takzˇe prˇi prˇechodu mezi svazky tam a zpeˇt se zachova´va´ pu˚vodnı´ adresa´rˇ. Kromeˇ relativnı´ a absolutnı´ cesty pak lze pouzˇ´ıvat i relativnı´ cesty vztazˇene´ k aktua´lnı´mu adresa´rˇi jine´ho svazku, ty se oznacˇujı´ pomocı´ jme´na disku nena´sledovane´ho lomı´tkem. Tento zpu˚sob za´pisu cest je vsˇak poneˇkud matoucı´ a v praxi se prˇ´ılisˇ nepouzˇ´ıva´. Pru˚vodce studiem Dodejme jesˇteˇ, zˇe ve Windows je de´lka cesty omezena na 260 znaku˚, prˇicˇemzˇ u na´rodnı´ch znaku˚ se jesˇteˇ v jednotlivy´ch prˇ´ıpadech mu˚zˇe lisˇit, jak prˇesneˇ se do celkove´ho soucˇtu pocˇ´ıtajı´. Toto omezenı´ nenı´ da´no prˇ´ımo souborovy´m syste´mem, ale jen internı´mi funkcemi zpracova´vajı´cı´mi cesty. Ty vsˇak mu˚zˇeme vypnout (prˇesneˇji rˇecˇeno obejı´t cˇi prˇeskocˇit). Zacˇ´ına´-li ve Windows cesta znaky \\?\, musı´ to by´t absolutnı´ cesta a v ko´dova´nı´ unicode (prˇedana´ do prˇ´ıslusˇne´ unicode verze syste´move´ funkce), de´lka cesty mu˚zˇe by´t ve Windows NT azˇ 32767 znaku˚. Tento tvar je mozˇno pouzˇ´ıt pro loka´lnı´ i sı´t’ove´ cesty, tj. naprˇ. \\?\C:\Windows nebo \\?\server\shared.

Hleda´nı´ spustitelny´ch souboru˚ V syste´mu obvykle ma´me rˇadu programu˚ (a jejich spustitelne´ soubory). Mensˇ´ı programy pouzˇ´ıvane´ na prˇ´ıkazove´ rˇa´dce mu˚zˇeme spousˇteˇt zada´nı´m jejich jme´na. Rˇada syste´mu˚ toto rˇesˇ´ı pomocı´ syste´move´ promeˇnne´ (jme´nem path) obsahujı´cı´ seznam adresa´rˇu˚, ve ktery´ch ma´ hledat programy ke spousˇteˇnı´ bez zadane´ho adresa´rˇe. Toto chova´nı´ je spolecˇneˇ pro Unix, Linux i Windows. Macintosh, jak vı´me, umozˇnˇuje otvı´rat libovolne´ dokumentove´ soubory dı´ky tomu, zˇe si u kazˇde´ho pamatuje, ke ktere´mu programu patrˇ´ı. Pouzˇ´ıva´ jinou strategii: Syste´m si uchova´va´ adresy vsˇech spustitelny´ch programu˚ ve zvla´sˇtnı´m seznamu a prˇi pokusu otevrˇ´ıt dokument hleda´ ve sve´m seznamu, kde ma´ program jme´na uvedene´ho v za´znamu otvı´rane´ho souboru. Windows pak stejnou funkcionalitu zajisˇt’uje jiny´m zpu˚sobem: Programy si mohou zaregistrovat v syste´mu jimi pouzˇ´ıvane´ prˇ´ıpony souboru˚. Samy prˇitom uvedou, jaky´m programem je chteˇjı´ otvı´rat. Tyto registrace jsou ulozˇeny v syste´move´m registru. Syste´m pak prˇi pokusu o otevrˇenı´ dokumentove´ho souboru podle jeho prˇ´ıpony najde potrˇebny´ program. (Syste´movou promeˇnnou path Windows pouzˇ´ıva´ jen pro programy cˇi prˇ´ıkazy na prˇ´ıkazove´ rˇa´dce.)

12.9

Sdı´lenı´ souboru˚ mezi uzˇivateli

V sekci 12.4 na straneˇ 131 jsme hovorˇili o zamyka´nı´ souboru˚. Sdı´lenı´ souboru˚ je de facto opacˇna´ operace k zamyka´nı´ a jedna´ se o pomeˇrneˇ du˚lezˇitou a uzˇitecˇnou funkcionalitu modernı´ch syste´mu˚. (Jedno specificke´ vyuzˇitı´ sdı´lenı´ jsou soubory mapovane´ do pameˇti, ktere´ jsme zmı´nili 136

jizˇ v neˇkolika prˇedchozı´ch kapitola´ch.) Nynı´ vsˇak nahle´dneme na sdı´lenı´ souboru˚ na u´rovni uzˇivatelu˚, nikoliv procesu˚. Ma´me-li vı´ceuzˇivatelsky´ syste´m, cozˇ je dnes jizˇ zcela beˇzˇne´, pak uzˇivatele´ zrˇejmeˇ neˇjaky´m zpu˚sobem sdı´lejı´ spolecˇny´ souborovy´ syste´m. Unixove´ syste´my pouzˇ´ıvajı´ jako za´klad model, kde kazˇdy´ soubor nese informaci o majiteli (to je obvykle uzˇivatel, ktery´ jej vytvorˇil) a trˇi masky prˇ´ıstupovy´ch pra´v zvla´sˇt’pro tohoto uzˇivatele, jeho skupinu a ostatnı´ uzˇivatele. Sdı´lenı´ souboru˚ je aktua´lnı´m te´matem take´ v oblasti pocˇ´ıtacˇovy´ch sı´tı´. Za´kladnı´m prostrˇedkem sdı´lenı´ je dobrˇe zna´my´ protokol ftp, noveˇji pak take´ (velmi popula´rnı´) protokol http; ani jeden z teˇchto prostrˇedku˚ nenı´ trˇeba prˇedstavovat. Alternativou jim jsou syste´my umozˇnˇujı´cı´ sdı´lenı´ souboru˚ pomocı´ mapova´nı´ vzda´leny´ch svazku˚ do souborove´ho syste´mu. Vsˇechny tyto modely jsou typu klient–server, kde jeden pocˇ´ıtacˇ (server) nabı´zı´ soubory a ostatnı´ pocˇ´ıtacˇe (klienti) jej vyuzˇ´ıvajı´. V poslednı´ch letech se velmi rozsˇ´ırˇil take´ model peer–to–peer (ve zkratce P2P), ktery´ se umozˇnˇuje sdı´lenı´ souboru˚ prˇ´ımo mezi uzˇivateli bez potrˇeby serveru. Jako prˇ´ıklad uved’me syste´my Napster (jizˇ nefunkcˇnı´), Kazzaa, Torrent cˇi Direct Connect. Tyto souborove´ P2P sı´teˇ nabı´zejı´ veˇtsˇ´ı flexibilitu a jsou dnes v neˇktery´ch oblastech nasazenı´ jednoznacˇneˇ popula´rneˇjsˇ´ı nezˇ sı´teˇ klient–server, i kdyzˇ technicky se jedna´ o daleko slozˇiteˇjsˇ´ı syste´my. To je pra´veˇ z du˚vodu neexistence neˇjake´ centra´lnı´ autority (serveru), cozˇ znesnadnˇuje naprˇ´ıklad navazova´nı´ spojenı´, vyhleda´va´nı´ souboru˚ apod. Ru˚zne´ P2P sı´teˇ tyto proble´my rˇesˇ´ı cˇa´stecˇnou centralizacı´ neˇktery´ch u´loh, empiricky vsˇak bylo doka´za´no, zˇe u´speˇch P2P rˇesˇenı´ je mimo jine´ neprˇ´ımo u´meˇrny´ u´rovni centralizace. U vsˇech typu˚ sı´t’ovy´ch sdı´lenı´ je trˇeba rˇesˇit proble´my zabezpecˇenı´ a ochrany komunikace, kde ve strucˇnosti lze mozˇne´ proble´my rozdeˇlit do dvou oblastı´: ztra´ta cˇi narusˇenı´ identity uzˇivatele a ztra´ta cˇi narusˇenı´ dat. Tato problematika je vsˇak nad ra´mec te´to kapitoly a de facto i tohoto studijnı´ho kurzu Operacˇnı´ syste´my. Se´mantika konzistence Se´mantika konzistence prˇesneˇ specifikuje chova´nı´ syste´mu prˇi soucˇasne´ pra´ci vı´ce procesu˚ s jednı´m souborem, jmenoviteˇ popisuje zejme´na to, kdy jeden uzˇivatel uvidı´ zmeˇny provedene´ jiny´m uzˇivatelem. Naprˇ. v Unixu jsou zmeˇny souboru okamzˇiteˇ viditelne´ ostatnı´mi procesy, ktere´ pouzˇ´ıvajı´ tenty´zˇ soubor. Jednı´m z mozˇny´ch zpu˚sobu˚ sdı´lenı´ je sdı´lenı´ aktua´lnı´ pozice souboru, kdy cˇtenı´m souboru jednı´m procesem se posouva´ pozice cˇtenı´ i ve vsˇech ostatnı´ch procesech. Jinou alternativou mu˚zˇe by´t se´mantika immutable–shared–file (cˇesky: nemutujı´cı´ soubor), kde zaha´jenı´m sdı´lenı´ dojde k za´kazu zmeˇn dat a jme´na souboru. Sdı´leny´ soubor je tedy nemeˇnny´, cozˇ umozˇnˇuje prˇedevsˇ´ım jednodusˇsˇ´ı implementaci pro operacˇnı´ syste´m.

12.10

Ochrana souboru˚

Soubory zabezpecˇujeme proti fyzicke´ chybeˇ syste´mu (me´dia, disku atp.), pak hovorˇ´ıme o spolehlivosti, a proti nespra´vne´mu prˇ´ıstupu, pak hovorˇ´ıme o ochraneˇ. Spolehlivost zajisˇt’ujeme nejcˇasteˇji vytva´rˇenı´m za´lozˇnı´ch kopiı´ souboru˚ cˇi prˇ´ımo pouzˇ´ıva´nı´m automatizovany´ch syste´mu˚ pro tento u´cˇel, naprˇ. za´lohovacı´ch pa´skovy´ch zarˇ´ızenı´ cˇi diskovy´ch polı´ RAID (viz kapitola 14.5 na straneˇ 163). Ochranu lze zajistit ru˚zny´mi prostrˇedky ru˚zneˇ. Silberschatz [SGG05] naprˇ´ıklad uva´dı´ postup: „Vyjmout disketu se souborem a zamknout ji do za´suvky ve stole.“ Podı´vejme se vsˇak spı´sˇe na softwarova´ rˇesˇenı´ ochrany. Typy prˇ´ıstupu Potrˇeba ochrany prˇ´ımo vyply´va´ z mozˇnosti prˇistupovat k souboru. Jak je zrˇejme´ z prˇ´ıkladu s disketou zamcˇenou ve stolnı´ za´suvce vy´sˇe, ochrany docı´lı´me pra´veˇ kontrolou cˇi omezenı´m 137

prˇ´ıstupu. Nejjednodusˇsˇ´ım typem ochrany je zcela znemozˇnit, aby uzˇivatele´ mohli sdı´let soubory mezi sebou – potom zˇa´dnou ochranu nemusı´me rˇesˇit. Tento zpu˚sob vsˇak nenı´ optima´lnı´. Ochrana je obvykle rˇesˇena pomocı´ kontroly prˇ´ıstupu. Je definova´na mnozˇina mozˇny´ch typu˚ prˇ´ıstupu˚ a u kazˇde´ho souboru jsou pak definova´na pravidla urcˇujı´cı´ch, kdo mu˚zˇe cˇi nemu˚zˇe prova´deˇt dany´ typ prˇ´ıstupu k souboru. Za´kladnı´mi typy prˇ´ıstupu jsou cˇtenı´, zakla´da´nı´ a za´pis, spousˇteˇnı´, prˇipisova´nı´ na konec souboru (append), maza´nı´, prohlı´zˇenı´ vlastnostı´, prˇejmenova´nı´. Jednotlive´ operacˇnı´ syste´my pak mohou k dı´lcˇ´ım operacı´m prˇistupovat jinak, kdyzˇ obvykle neˇkolik prˇ´ıbuzny´ch typu˚ prˇ´ıstupu je pro jednoduchost zahrnuto dohromady pod jednu polozˇku. Kontrola prˇ´ıstupu Ma´me-li definova´ny typy prˇ´ıstupu, pak kontrolu prˇ´ıstupu ke kazˇde´mu souboru a adresa´rˇi realizujeme pomocı´ ACL (access control list). ACL je seznam uzˇivatelu˚ a jim povoleny´ch typu˚ prˇ´ıstupu k dane´mu souboru (jiny´mi slovy seznam povoleny´ch operacı´ se souborem). Prˇi pra´ci se soubory se pak kontrolujı´ jejich ACL. ACL je flexibilnı´, ale mu˚zˇe by´t pomale´ a pameˇt’oveˇ na´rocˇne´, protozˇe uchova´va´nı´ velke´ho mnozˇstvı´ dat v ACL komplikuje jejich vytva´rˇenı´ (Jak vu˚bec zjistı´me vsˇechny uzˇivatele syste´mu, kdyzˇ chceme soubor zprˇ´ıstupnit vsˇem?) i pouzˇ´ıva´nı´ (ACL je trˇeba ulozˇit do za´znamu o souboru v adresa´rˇi, tı´m se adresa´rˇove´ za´znamy neu´meˇrneˇ zveˇtsˇujı´ a jednotlive´ za´znamy potrˇebujı´ promeˇnlivou velikost.). Unixove´ syste´my tyto potı´zˇe rˇesˇ´ı pouzˇ´ıva´nı´m zjednodusˇene´ho syste´mu opra´vneˇnı´, kde soubor ma´ jen trˇi za´znamy v ACL pro majitele souboru, jeho skupinu a ostatnı´ uzˇivatele. (Kazˇdy´ uzˇivatel syste´mu pochopitelneˇ patrˇ´ı do jedne´ z teˇchto trˇ´ı skupin.) ACL tohoto typu pak zabı´ra´ jen neˇkolik ma´lo bajtu˚ pameˇti (3 bity pro kazˇdy´ typ prˇ´ıstupu). ACL se nastavuje prˇ´ıkazem chmod (vyzkousˇejte!). Modernı´ verze Unixovy´ch syste´mu˚ pak umozˇnˇujı´ k tomuto za´kladnı´mu syste´mu prˇida´vat i plnohodnotne´ ACL u souboru˚, kde je to trˇeba. Tı´m je zajisˇteˇna plna´ flexibilita a u´spora mı´sta za´rovenˇ. Windows 95 nepodporuje ochranu souboru˚ vu˚bec, stejneˇ tak MS-DOS a Mac OS do verze 9.x [SGG05]. Mac OS je specificky´ tı´m, zˇe pokry´va´ jen maly´ trh a nenı´ kompatibilnı´ s jiny´mi syste´my v pomeˇrneˇ velke´m mnozˇstvı´ detailu˚. Neˇktere´ zdroje dokonce uva´deˇjı´, zˇe Mac OS ma´ celou rˇadu vlastnostı´, ktere´ jsou v syste´mu z u´plneˇ jiny´ch du˚vodu˚ (by design), ale v du˚sledku v kombinaci s malou penetracı´ Macintoshu˚ prˇ´ızniveˇ ovlivnˇujı´ praktickou bezpecˇnost cele´ho syste´mu. Noveˇjsˇ´ı Mac OS X je pak jizˇ verzı´ Unixu (doslova), takzˇe pro neˇj platı´ tote´zˇ, co pro Unix. Opacˇna´ situace je pak u syste´mu˚ Microsoftu – prˇ´ılisˇ flexibilnı´ design bez ochran v kombinaci s velkou penetracı´ teˇchto syste´mu˚ zpu˚sobil boom viru˚ a jine´ho sˇkodlive´ho softwaru. Windows NT, acˇkoliv take´ od Microsoftu, nabı´zı´ propracovany´ syste´m ochrany souboru˚. Pouzˇ´ıva´ plnohodnotne´ ACL (cˇili bez zjednodusˇenı´) a umozˇnˇuje nastavit sdı´lenı´ ACL s adresa´rˇem, ve ktere´m je soubor umı´steˇn. Ve veˇtsˇineˇ prakticky´ch situacı´ tedy nastavı´me ACL jen u neˇkolika adresa´rˇu˚ a vsˇechny jim podrˇ´ızene´ soucˇa´sti adresa´rˇove´ho stromu jizˇ vlastnı´ ACL nemajı´, takzˇe to nezabı´ra´ zˇa´dny´ diskovy´ prostor. NT take´ na rozdı´l od Unixu definuje velmi mnoho typu˚ souborovy´ch prˇ´ıstupu˚ a take´ umozˇnˇuje kromeˇ ACL pro povolenı´ prˇ´ıstupu definovat seznamy zamezenı´ prˇ´ıstupu DACL (Denied ACL). V NT se ACL nastavuje obvykle v GUI (vyzkousˇejte!) nebo take´ prˇ´ıkazem cacls. Prˇi kolizi opra´vneˇnı´, kdy ACL naprˇ´ıklad definuje neˇjake´ opra´vneˇnı´ pro uzˇivatele, ale jine´ pro jeho skupinu, se jednotlive´ operacˇnı´ syste´my chovajı´ ru˚zne´. Naprˇ´ıklad Solaris uprˇednostnˇuje vı´ce specificke´ u´daje (tj. zde o uzˇivateli) prˇed obecny´mi (tj. zde o skupineˇ). NT vsˇechna povolujı´cı´ opra´vneˇnı´ slucˇuje, ale vysˇsˇ´ı prioritu ma´ vzˇdy za´kaz – je-li v DACL za´kaz na libovolne´ u´rovni, nelze jej pomocı´ ACL nijak prˇebı´t. Shrnutı´ Zaha´jili jsme blok kapitol veˇnovany´ch spra´veˇ diskove´ho prostoru cˇi obecneˇ sekunda´rnı´ pameˇti. 138

Cela´ kapitola se veˇnovala sezna´menı´ se za´kladnı´mi pojmy te´to oblasti na vysˇsˇ´ı u´rovni abstrakce, tj. soubor, adresa´rˇ, proud atp. Probra´no bylo zamyka´nı´ souboru˚, typy souboru˚, sdı´lenı´ souboru˚ a ˇ ada teˇchto pojmu˚ je cˇtena´rˇi za´veˇr kapitoly byl veˇnova´n studiu zabezpecˇenı´ na u´rovni souboru˚. R cˇi studentovi jisteˇ dobrˇe zna´ma´, jedna´ se vsˇak o jedno ze za´kladnı´ch te´mat studia operacˇnı´ch syste´mu˚, proto je mu zde veˇnova´n patrˇicˇny´ prostor. Beˇzˇneˇ pouzˇ´ıvane´ operacˇnı´ syste´my se na u´rovni souborove´ho syste´mu dosti podobajı´, model adresa´rˇu˚ a souboru˚ je znacˇneˇ zazˇity´ a syste´m pracujı´cı´ na jine´m principu by asi dnes nemeˇl sˇanci uspeˇt. K tomu prˇispı´va´ i rozvoj internetu, kde take´ rˇada protokolu˚ pracuje na ba´zi souboru˚ cˇi proudu˚. Problematiku souborovy´ch syste´mu˚ v pocˇ´ıtacˇovy´ch sı´tı´ch jsme zde vsˇak nijak hluboce nezkoumali, v na´sledujı´cı´ch kapitola´ch se spı´sˇe zameˇrˇ´ıme na implementacˇnı´ ota´zky souborovy´ch syste´mu˚ jednotlivy´ch pocˇ´ıtacˇu˚. Pojmy k zapamatova´nı´ • • • • • • • • • • • • • • • • • • • • •

soubor souborove´ operace zamyka´nı´ souboru˚ typ souboru magic number metadata souboru prˇ´ıstup k souboru – sekvencˇnı´, prˇ´ımy´, na´hodny´ proud oddı´l a svazek mounting adresa´rˇ aktua´lnı´ adresa´rˇ absolutnı´ a relativnı´ cesta hard link, soft link sdı´lenı´ souboru˚ klient–server, peer–to–peer (P2P) se´mantika konzistence spolehlivost a ochrana (souborove´ho syste´mu) typ prˇ´ıstupu, kontrola prˇ´ıstupu ACL (access control list) DACL (denied access control list)

Kontrolnı´ ota´zky 1. Co to je zamyka´nı´ souboru˚, jake´ typy zamyka´nı´ zna´me a k cˇemu je to dobre´? Ma´ smysl, aby syste´m umozˇnˇoval zamykat i pouze cˇa´sti souboru˚? Vysveˇtlete. 2. Jmenujte mozˇne´ zpu˚soby, jak by´vajı´ v souborove´m syste´mu reprezentova´ny typy souboru˚. 3. Navrhneˇte, jak rˇesˇit maza´nı´ adresa´rˇu˚, ktere´ obsahujı´ neˇjake´ soubory? 4. Jak syste´m rozhodne o prˇ´ıstupu, kdyzˇ ACL souboru obsahuje vı´ce protichu˚dny´ch za´znamu˚? 5. Co to jsou alternativnı´ datove´ proudy? K cˇemu se pouzˇ´ıvajı´? 6. Prˇ´ımy´ prˇ´ıstup k souboru je na prvnı´ pohled dokonalejsˇ´ı, procˇ tedy vlastneˇ existuje i sekvencˇnı´ prˇ´ıstup? Je to jen historicky´ prvek, nebo se sekvencˇnı´ prˇ´ıstup pouzˇ´ıva´ i dnes? Vysveˇtlete. 7. Jak souvisejı´ oddı´ly a svazky? 8. Jak syste´m NT rozhodne o prˇ´ıstupu, kdyzˇ je stejny´ za´znam v ACL i DACL. 9. Popisˇte syste´m ochrany souboru˚ v MS-DOSu. 139

10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21.

Co je to se´mantika konzistence? Uved’te take´ neˇjaky´ konkre´tnı´ prˇ´ıklad. Jak souvisı´ sdı´lenı´ souboru˚ se zamyka´nı´m? Vysveˇtlete rozdı´l sdı´lenı´ souboru˚ v sı´tı´ch typu klient–server a peer–to–peer. Popisˇte vy´hody a nevy´hody peer–to–peer sı´tı´. Vysveˇtlete, jak syste´my bojujı´ s proble´mem velke´ datove´ na´rocˇnosti ACL (mnoho uzˇivatelu˚ −→ mnoho za´znamu˚ −→ zabı´ra´ mnoho pameˇti). Popisˇte detailneˇ za´kladnı´ model kontroly prˇ´ıstupu k souboru˚m v Unixu. Jmenujte alesponˇ jeden prˇ´ıklad, kdy vyuzˇijete na´stroje pro obecne´ grafove´ vazby v syste´mech se stromovou adresa´rˇovou strukturou. Vysveˇtlete prˇ´ıkazy open() a close(). Uved’te konkre´tnı´ prˇ´ıklad sekvencˇnı´ho a na´hodne´ho prˇ´ıstupu k souboru. Neˇktere´ syste´my umozˇnˇujı´, aby uzˇivatel dostal opra´vneˇnı´ pracovat s adresa´rˇi jako s beˇzˇny´mi soubory. Vysveˇtlete, jaka´ tı´m vznika´ bezpecˇnostnı´ dı´ra. Meˇjme syste´m s 2000 uzˇivateli. Jak v Unixu nastavı´te 1990 z nich prˇ´ıstup k souboru? K prˇedchozı´ ota´zce uved’te, jak lze tote´zˇ jednodusˇe rˇesˇit v NT.

Cvicˇenı´ 1. Vyzkousˇejte si v praxi zamyka´nı´ souboru pro cˇtenı´ a pro za´pis. 2. Vyzkousˇejte si v Linuxu cˇi Unixu zmeˇnu ACL pomocı´ prˇ´ıkazu chmod. Vyzkousˇejte si tote´zˇ nastavit programoveˇ. 3. Vyzkousˇejte si ve Windows nastavenı´ ACL a DACL. Oveˇrˇte si, zˇe prˇi kolizi ma´ DACL vysˇsˇ´ı prioritu nezˇ ACL.

140

13

Implementace souborove´ho syste´mu

Studijnı´ cı´le: V prˇedchozı´ kapitole jsme si prˇedstavili princip souborove´ho syste´mu, nynı´ si prˇiblı´zˇ´ıme jeho mozˇnou strukturu a prˇedevsˇ´ım probereme ota´zku jeho implementace. Tu je mozˇno studovat jak teoreticky, tak prakticky, protozˇe te´meˇrˇ kazˇdy´ z beˇzˇneˇ pouzˇ´ıvany´ch operacˇnı´ch syste´mu˚ pouzˇ´ıva´ svu˚j vlastnı´ souborovy´ syste´m. V te´to kapitole se na implementaci souborove´ho syste´mu podı´va´me uceleneˇ, prˇedevsˇ´ım se tedy zameˇrˇ´ıme na principy pouzˇ´ıvane´ prˇi implementaci pojmu˚, se ktery´mi jsme se jizˇ sezna´mili (adresa´rˇova´ struktura atp.). Klı´cˇova´ slova: rame´nko, MBR, FCB, adresa´rˇ, soubor, zˇurna´lova´nı´ Potrˇebny´ cˇas: 180 minut.

13.1

Struktura disku

Popisˇme si na u´vod strukturu pevne´ho disku. Pro za´kladnı´ prˇedstavu postacˇ´ı znalost disket, beˇzˇne´ 3.5” diskety fungujı´ prˇiblizˇneˇ na stejne´m principu jako pevne´ disky. Na rozdı´l od diskety, kdy v pocˇ´ıtacˇi je disketova´ mechanika, zatı´mco samotne´ diskety jsou prˇenosne´, u pevne´ho disku je cele´ zarˇ´ızenı´ napevno v pocˇ´ıtacˇi. Prˇitom „pevnost“ disku nenı´ da´na tı´m, zˇe je pevneˇ v pocˇ´ıtacˇi, ale tı´m, zˇe magneticky´ kotoucˇ a mechanika s nı´m pracujı´cı´ jsou pevneˇ spojeny. Pra´veˇ dı´ky tomuto rˇesˇenı´ je zabra´neˇno vnika´nı´ cizı´ch cˇa´stic (necˇistot) do mechaniky, dı´ky cˇemuzˇ pevne´ disky mohou nabı´dnout daleko vysˇsˇ´ı kapacity a spolehlivost nezˇ prˇenosne´ diskety. Disk obvykle obsahuje neˇkolik ploten (anglicky platter), nejcˇasteˇji to jsou dveˇ nebo trˇi. Plotna je magneticky´ kotoucˇ (prˇipomı´najı´cı´ kotoucˇ v disketeˇ), na ktere´m jsou ulozˇena data. Kazˇda´ plotna ma´ pochopitelneˇ dveˇ strany a vlastnı´ hlavy, ktere´ magnetickou informaci cˇtou/zapisujı´. Plotny se neusta´le ota´cˇejı´ a hlavy jsou prˇipojeny na rame´nku, ktere´ je posuvne´ a nastavuje tak hlavu nad urcˇitou stopu disku. Stopa je de facto kruzˇnice. Na rozdı´l od disket, kde na kazˇde´ stopeˇ obvykle by´va´ stejne´ mnozˇstvı´ dat, u pevny´ch disku˚ obvykle na vnitrˇnı´ch stopa´ch by´va´ dat me´neˇ, aby byla data ulozˇena s rovnomeˇrnou hustotou. Samotna´ data, jak vı´me, jsou ulozˇena po blocı´ch, obvykle o velikosti 512B. Tyto bloky se nazy´vajı´ sektory a je to vzˇdy cˇa´st jedne´ stopy. Tı´m, zˇe disk ma´ vı´ce ploten nad sebou a na vsˇech jsou hlavy, prˇi pra´ci s diskem obvykle pracujı´ vsˇechny hlavy najednou, takzˇe pracujeme s urcˇitou stopou na vsˇech strana´ch vsˇech ploten. Takova´ skupina stop se nazy´va´ cylindr (anglicky cylinder). U pojmu˚ stopa a cylindr neˇkdy docha´zı´ k za´meˇneˇ cˇi sply´va´nı´, nenı´ to vsˇak z pohledu nasˇeho studia podstatny´ proble´m. Podrobneˇjsˇ´ı (tedy hardwarove´) informace o fungova´nı´ disku˚ jsou mimo ra´mec tohoto prˇedmeˇtu (viz prˇedmeˇt Struktura pocˇ´ıtacˇu˚), na za´veˇr te´to sekce se vsˇak jesˇteˇ zastavı´me u problematiky rychlosti disku˚. Rychlost disku je dana´ neˇkolika faktory: Prvnı´m je prˇenosova´ rychlost, to je rychlost toku dat mezi diskem a pocˇ´ıtacˇem. Jde tedy o rychlost datove´ho kana´lu (kudy data „tecˇou“). Rychlost cˇtenı´ a za´pisu jsou rychlosti, ktery´mi disk skutecˇneˇ cˇte cˇi zapisuje data, pokud pracujeme s po sobeˇ jdoucı´mi sektory a stopami. Rea´lnou rychlost disku velmi ovlivnˇuje take´ tzv. seek time, cozˇ je pru˚meˇrna´ doba potrˇebna´ k nastavenı´ hlav nad urcˇitou stopu. Dodejme jesˇteˇ, zˇe rychlost disku˚ je v soucˇasnosti velmi mala´ ve srovna´nı´ s rychlostı´ operacˇnı´ pameˇti a procesoru, takzˇe se obvykle vyplatı´ i vy´pocˇetneˇ cˇi pameˇt’oveˇ na´rocˇne´ algoritmy rˇesˇ´ıcı´ snı´zˇenı´ pocˇtu prˇ´ıstupu˚ na disk, stejneˇ jako algoritmy rˇesˇ´ıcı´ minimalizaci pocˇtu a vzda´lenostı´ prˇesunu˚ rame´nka mezi stopami.

13.2

Master boot record

Neˇktere´ vlastnosti majı´ rea´lne´ syste´my spolecˇne´, obvykle proto, zˇe jsou urcˇeny pro stejny´ typ pocˇ´ıtacˇe, nebo pro stejny´ typ datove´ho me´dia. Naprˇ. prvnı´ sektor pevne´ho disku se na pocˇ´ıtacˇ´ıch PC nazy´va´ master boot record (MBR) a obsahuje informace o cˇleneˇnı´ disku (anglicky partitioning) na jednotlive´ cˇa´sti (anglicky partitions). Kazˇda´ cˇa´st ma´ typ: Je bud’ prima´rnı´, nebo sekunda´rnı´. Prima´rnı´ cˇa´st prˇ´ımo odpovı´da´ svazku a mu˚zˇe by´t pouzˇita k bootova´nı´ operacˇnı´ho 141

Disk obsahuje plotny.

Cylindr je skupina stop.

syste´mu. Sekunda´rnı´ cˇa´st lze da´le rozdeˇlit na vı´ce svazku˚, ktere´ vsˇak nejsou bootovatelne´. Zde popsany´ princip MBR je obvykle pouzˇ´ıva´n i na jiny´ch pocˇ´ıtacˇ´ıch nezˇ PC, du˚vodem je samozrˇejmeˇ dominantnı´ postavenı´ PC mezi pocˇ´ıtacˇi. Rozdeˇlenı´m disku na vı´ce svazku˚ vznikne ve Windows vı´ce „pı´smen“ disku˚, v Linuxu se pro zmeˇnu vı´ce svazku˚ pouzˇ´ıva´ k prˇesneˇjsˇ´ımu oddeˇlenı´ samostatny´ch cˇa´stı´ adresa´rˇove´ho stromu. Naprˇ. adresa´rˇe uzˇivatelu˚ v /home jsou na jine´m svazku nezˇ docˇasne´ soubory v /tmp – vy´hodou i nevy´hodou pak mu˚zˇe by´t fakt, zˇe jednotlive´ svazky majı´ vzˇdy pevnou velikost. Pru˚vodce studiem Windows prˇi startu syste´mu (a kdykoliv pozdeˇji, kdy objevı´ novy´ svazek – naprˇ. USB disk) prˇipojı´ vsˇechny svazky na prvnı´ volna´ pı´smena (pocˇ´ınaje C:, protozˇe A: a B: jsou vyhrazeny pro disketove´ mechaniky). Pı´smena je mozˇno pohodlneˇ zmeˇnit cˇi u´plneˇ zrusˇit ve spra´vci disku˚, kde lze take´ prˇipojit svazky do stromu jako adresa´rˇe jiny´ch svazku˚ (ve stylu Unixu). Prˇi odpojenı´ svazku/zarˇ´ızenı´ si syste´m pamatuje jeho minule´ pı´smeno a prˇ´ısˇteˇ opeˇt pouzˇije to stejne´ (ty´ka´ se pevny´ch i prˇenosny´ch disku˚), pokud ho ovsˇem doka´zˇe podle jme´na cˇi cˇ´ısla prˇ´ısˇteˇ opeˇt identifikovat. (Naprˇ. kazˇde´mu USB disku mu˚zˇete prˇirˇadit jine´ pı´smeno, prˇestozˇe je budete strˇ´ıdaveˇ zapojovat do stejne´ho USB portu.)

Samotny´ proces bootova´nı´ a podrobneˇjsˇ´ı popis struktury MBR jdou nad ra´mec u´vodnı´ho kurzu Operacˇnı´ syste´my. Opacˇnou situaci, kdy namı´sto deˇlenı´ cˇa´stı´ disku na svazky naopak jeden svazek je na vı´ce diskovy´ch cˇa´stech, budeme diskutovat v sekci 14.5 na straneˇ 163.

13.3

Obecna´ struktura svazku

Bez ohledu na konkre´tnı´ forma´t, kazˇdy´ svazek obvykle sesta´va´ z vlastnı´ bootovacı´ hlavicˇky pouzˇ´ıvane´ prˇi startu operacˇnı´ho syste´mu z tohoto svazku, da´le pak obsahuje neˇjaka´ rˇ´ıdicı´ data svazku (tj. informace ty´kajı´cı´ se svazku jako celku), informace o adresa´rˇove´ strukturˇe a informace o jednotlivy´ch souborech. Kazˇdy´ soubor je popsa´n svy´m FCB (file control blok), adresa´rˇ pak obsahuje odkazy na tyto FCB. Jme´no souboru (a naprˇ. take´ datum) je obvykle v adresa´rˇi, zatı´mco FBC popisuje teˇlo (data). To vsˇe samozrˇejmeˇ platı´ prˇedevsˇ´ım na beˇzˇny´ch pocˇ´ıtacˇ´ıch, nebot’ cˇisteˇ technicky mu˚zˇe disk a potazˇmo svazek mı´t libovolny´ obsah. Neˇktere´ (hlavneˇ starsˇ´ı a jednodusˇsˇ´ı) souborove´ syste´my nemajı´ samostatneˇ ulozˇene´ adresa´rˇe, takzˇe FCB pak pochopitelneˇ musejı´ obsahovat i jme´no a dalsˇ´ı u´daje, ktere´ by byly v adresa´rˇi.

13.4

Data v pameˇti

Operacˇnı´ syste´m si v pameˇti uchova´va´ prˇedevsˇ´ım informace o tom, ktery´ svazek a jak je prˇipojen (namountova´n) do syste´mu – dohromady se pak obvykle vsˇechny prˇipojene´ svazky tva´rˇ´ı jako jeden spolecˇny´ souborovy´ syste´m. Operacˇnı´ syste´m tedy uzˇivatelsky´m procesu˚m poskytuje jaky´si jeden spolecˇny´ virtua´lnı´ souborovy´ syste´m, obvykle v podobeˇ adresa´rˇove´ho stromu a jeho vlastnosti jsou takove´, aby pokryly vlastnosti vsˇech fyzicky´ch souborovy´ch syste´mu˚, ktere´ reprezentuje. Dalsˇ´ım du˚lezˇity´m prvkem je diskova´ cache, ve ktere´ operacˇnı´ syste´m uchova´va´ nejcˇasteˇji cˇi nejposledneˇji pouzˇ´ıvane´ informace o souborech cˇi svazcı´ch za u´cˇelem zrychlenı´ pra´ce se soubory. Pru˚vodce studiem Diskova´ cache vy´razneˇ zrychluje pra´ci s diskem. I kdybychom nikdy opakovaneˇ necˇetli stejne´ soubory, dı´ky cache se pra´ce s diskem zrychlı´ uzˇ uzˇ proto, zˇe v nı´ operacˇnı´ syste´m mu˚zˇe uchova´vat informace o adresa´rˇove´ strukturˇe apod. Prˇi za´pisu souboru˚ cache poma´ha´

142

jesˇteˇ vı´ce – modernı´ syste´my umeˇjı´ kromeˇ jednoduche´ho principu write through, kdy zapisovana´ data zu˚sta´vajı´ v diskove´ cache pro prˇ´ıpad, zˇe by se meˇla v blı´zke´ dobeˇ opeˇt cˇ´ıst, take´ princip write back, kdy jsou data zapisova´na pouze do cache a teprve pozdeˇji jsou zapisova´na na disk. Jelikozˇ rychlost pocˇ´ıtacˇe je vy´razneˇ vysˇsˇ´ı nezˇ rychlost disku, write back cache se projevı´ velmi zrˇetelneˇ. Konkre´tnı´ implementace diskove´ cache je samozrˇejmeˇ veˇcı´ konkre´tnı´ho operacˇnı´ho syste´mu.

Z principu pra´ce se soubory popsane´ho v prˇedchozı´ kapitole je zrˇejme´, zˇe operacˇnı´ syste´m si take´ uchova´va´ seznam informacı´ o otevrˇeny´ch souborech a buffery pro kazˇdy´ z nich. Kazˇdy´ otevrˇeny´ soubor ma´ tedy v pameˇti jakousi obdobu FCB. Buffer slouzˇ´ı pro pra´ci s proudem dane´ho souboru – syste´m si zde uchova´va´ cˇa´st dat souboru, protozˇe cˇ´ıst z disku lze jen po cely´ch klastrech, ale jednotlive´ procesy mohou od operacˇnı´ho syste´mu zˇa´dat data po libovolneˇ velky´ch blocı´ch a nacˇ´ıst opakovaneˇ stejne´ klastry by bylo znacˇneˇ neefektivnı´ (pomale´). Operacˇnı´ syste´my podporujı´cı´ sdı´lenı´ souboru˚ cˇi duplikaci procesu˚ take´ obvykle umozˇnˇujı´ sdı´let tyto seznamy otevrˇeny´ch souboru˚ – syste´m mu˚zˇe naprˇ´ıklad evidovat zvla´sˇt’loka´lnı´ otevrˇene´ soubory procesu a zvla´sˇt’ otevrˇene´ soubory sdı´lene´ vı´ce procesy. Ke kazˇde´mu otevrˇene´mu souboru existuje jednoznacˇny´ identifika´tor (ve Windows file handle, v Unixu file descriptor). Vsˇechny funkce, ktere´ lze volat pro pra´ci se soubory, pak pozˇadujı´ jako jeden z argumentu˚ pra´veˇ identifika´tor otevrˇene´ho souboru. (Vy´jimkou je pochopitelneˇ funkce open(), ktera´ soubor otevrˇe a identifika´tor vracı´.) Jak vı´me, mnohe´ operacˇnı´ syste´my pouzˇ´ıvajı´ princip souboru˚ a proudu˚ i pro dalsˇ´ı u´cˇely (prˇ´ıstup k hardwarovy´m zarˇ´ızenı´m, sı´t’ova´ komunikace aj.). V tom prˇ´ıpadeˇ musı´ mı´t za´znam o souboru takovy´ forma´t, aby doka´zal popsat vsˇechny typy otevrˇeny´ch souboru˚, at’ uzˇ se odkazujı´ na soubory na disku, cˇi jine´ zdroje dat. Je to tedy specificka´ datova´ struktura, ktera´ se va´zˇe vı´ce ke konkre´tnı´mu operacˇnı´mu syste´mu nezˇ k souborove´mu syste´mu. Operacˇnı´ syste´my pouzˇ´ıvajı´cı´ soubor jako „na´stroj na vsˇechno“ se obvykle inspirujı´ syste´mem Unix, kde se tento princip nejvı´ce rozsˇ´ırˇil (cˇi prosadil, cˇi osveˇdcˇil). Podobneˇ jako „vsˇechno je soubor“, prˇi pra´ci se soubory neza´lezˇ´ı ani na konkre´tnı´m pouzˇite´m souborove´m syste´mu – operacˇnı´ syste´m pomocı´ neˇkolika u´rovnı´ abstrakce zprˇ´ıstupnˇuje uzˇivatelsky´m procesu˚m vsˇechny soubory stejneˇ (naprˇ. CD-ROM a disk pouzˇ´ıvajı´ zcela odlisˇny´ syste´m ukla´da´nı´ dat, ale s otevrˇeny´mi soubory se pracuje v obou prˇ´ıpadech u´plneˇ stejneˇ).

13.5

Adresa´rˇe

Zpu˚sob implementace adresa´rˇu˚ mu˚zˇe vy´razneˇ ovlivnit vy´slednou rychlost pra´ce se souborovy´m syste´mem a take´ bezpecˇnost, jde proto jednu z naprosto klı´cˇovy´ch veˇcı´. 13.5.1

Linea´rnı´ seznam

Linea´rnı´ model implementuje adresa´rˇe jako obycˇejne´ pole za´znamu˚ pevne´ de´lky popisujı´cı´ch jednotlive´ soubory. Prˇi potrˇebeˇ prˇidat dalsˇ´ı soubor se na konci prˇida´ dalsˇ´ı za´znam. Prˇi naplneˇnı´ klastru se prˇida´ dalsˇ´ı. (Zde je videˇt, zˇe adresa´rˇ skutecˇneˇ prˇipomı´na´ beˇzˇny´ soubor, protozˇe to je take´ prˇedevsˇ´ım blok dat na disku.) Vy´hodou tohoto rˇesˇenı´ je velmi snadna´ implementace. Nevy´hodou je pak cˇasova´ na´rocˇnost operacı´. Pro vytvorˇenı´ souboru je nutne´ projı´t cely´ adresa´rˇ, abychom zjistili, zda se dane´ jme´no souboru jizˇ nevyskytuje. Pro smaza´nı´ souboru je rovneˇzˇ nutno projı´t cely´ adresa´rˇ a mazany´ soubor oznacˇit jako smazany´. Po smazany´ch souborech zu˚sta´va´ v adresa´rˇi nevyuzˇite´ mı´sto. Alternativou mu˚zˇe by´t prˇesunutı´ za´znamu poslednı´ho souboru do uvolneˇne´ho mı´sta, tı´m se vsˇak meˇnı´ porˇadı´ souboru˚ v adresa´rˇi, cozˇ mu˚zˇe by´t nezˇa´doucı´. Obecneˇ te´meˇrˇ vsˇechny operace vedou k proble´mu nalezenı´ souboru podle jme´na, cozˇ lze realizovat jen pomaly´m linea´rnı´m prohleda´va´nı´m cele´ho adresa´rˇe (slozˇitost O(n)). Operace 143

s adresa´rˇi se opakujı´ velmi cˇasto, proto jsou pra´veˇ adresa´rˇova´ data nejcˇasteˇjsˇ´ım objektem cachova´nı´ – klastry obsahujı´cı´ adresa´rˇe jsou zrˇejmeˇ u´plneˇ nejcˇasteˇji pouzˇ´ıvany´mi cˇa´stmi disku, proto je uchova´nı´ jejich kopiı´ v prima´rnı´ pameˇti pocˇ´ıtacˇe zvla´sˇteˇ vy´hodne´. Data adresa´rˇu˚ se do cache nacˇtou vzˇdy prˇi prvnı´m prˇ´ıstupu k jednotlivy´m adresa´rˇu˚m, takzˇe prvnı´ prˇ´ıstup je beˇzˇneˇ znatelneˇ pomalejsˇ´ı nezˇ prˇ´ıstupy na´sledujı´cı´. 13.5.2

Hashovacı´ tabulka

Slozˇiteˇjsˇ´ı, ale lepsˇ´ı alternativou je model pouzˇ´ıvajı´cı´ hashovacı´ tabulku. K vy´sˇe popsane´ linea´rnı´ strukturˇe je prˇida´na hashovacı´ tabulka slouzˇ´ıcı´ k rychle´mu nalezenı´ souboru podle jme´na. Vy´hodou tohoto rˇesˇenı´ je vy´razne´ zrychlenı´ veˇtsˇiny operacı´ (slozˇitost O(1)), nevy´hodou jsou pak klasicke´ teˇzˇkosti spojene´ s hashova´nı´m: tabulka musı´ mı´t urcˇitou pevnou velikost dle hashovacı´ funkce, zatı´mco ru˚zne´ adresa´rˇe mohou obsahovat velmi rozlicˇna´ mnozˇstvı´ souboru˚. Hashovacı´ tabulky lze implementovat ru˚zny´mi zpu˚soby a v prˇ´ıpadeˇ adresa´rˇu˚ nejde o nic zvla´sˇtnı´ho (viz naprˇ. ucˇebnice [Knu98] nebo [Vecˇ04]).

13.6

Alokace diskove´ho prostoru

Podobneˇ jako u spra´vy operacˇnı´ pameˇti je alokace prostoru take´ u spra´vy diskove´ho prostoru jednou z hlavnı´ch funkcı´ a pouzˇ´ıva´ i podobne´ algoritmy. 13.6.1

Souvisla´ alokace

Souvisla´ alokace funguje stejneˇ jako spra´va pameˇti v syste´mu MS-DOS. Diskovy´ prostor je rozdeˇlen na klastry, ktere´ jsou serˇazeny (tj. existuje urcˇite´ linea´rnı´ porˇadı´ klastru˚). Poloha souboru na disku je pak urcˇena pocˇa´tecˇnı´m klastrem a pocˇtem zabrany´ch klastru˚. (Tyto dveˇ hodnoty jsou obvykle ulozˇeny v adresa´rˇove´m za´znamu o souboru.) Implementace tohoto algoritmu je jednoducha´. Vy´hodou je rychle´ sekvencˇnı´ cˇtenı´ disku, protozˇe prˇi cˇtenı´ nenı´ trˇeba prˇesouvat cˇtecı´ hlavu na jine´ pozice. Prˇida´nı´ nove´ho souboru vsˇak vyzˇaduje nalezenı´ dostatecˇneˇ velke´ho prostoru a zejme´na pak je potrˇeba prˇedem zna´t velikost budoucı´ho souboru, jinak mu˚zˇe nastat proble´m v okamzˇiku, kdy se alokovany´ prostor zcela zaplnı´ a potrˇebujeme soubor jesˇteˇ da´le zveˇtsˇit. Tento proble´m je identicky´ se situacı´ prˇi souvisle´ alokaci pameˇti, vcˇetneˇ alternativ rˇesˇenı´ a vneˇjsˇ´ı fragmentace (naprˇ. MS-DOS, viz kap.9.2 na straneˇ 85). 13.6.2

Spojove´ seznamy

Proble´my souvisle´ alokace lze rˇesˇit naprˇ. pouzˇitı´m spojovy´ch seznamu˚ (linked list). Soubor v tom prˇ´ıpadeˇ mu˚zˇe by´t ulozˇen v libovolne´ posloupnosti klastru˚, kde kazˇdy´ ukazuje na na´sledujı´cı´ klastr v rˇadeˇ. Pro prˇ´ıklad: Prˇi velikosti klastru 512 bajtu˚ bude 510 bajtu˚ obsahovat data a zbyle´ 2 bajty budou cˇ´ıslo klastru obsahujı´cı´ na´sledujı´cı´ cˇa´st souboru. V adresa´rˇove´m za´znamu o souboru pak stacˇ´ı ulozˇit cˇ´ıslo pocˇa´tecˇnı´ho klastru. Cˇtenı´ souboru je v tomto prˇ´ıpadeˇ opeˇt velmi rychle´, protozˇe nacˇtenı´m klastru ihned zjistı´me cˇ´ıslo klastru na´sledujı´cı´ho. V prˇ´ıpadeˇ fragmentace souboru˚ mu˚zˇe by´t cˇtenı´ zpomaleno o prˇesuny cˇtecı´ hlavy, ale to jen v teˇch prˇ´ıpadech, ktere´ by u souvisle´ alokace vedly k nerˇesˇitelny´m situacı´m. Cˇili technika spojovy´ch seznamu˚ je oproti souvisle´ alokaci lepsˇ´ı. Nevy´hodou spojovy´ch seznamu˚ je problematicky´ na´hodny´ prˇ´ıstup. Chceme-li najı´t urcˇitou cˇa´st souboru na disku, je trˇeba sekvencˇneˇ projı´t cely´ soubor. Dalsˇ´ı nevy´hodou je chova´nı´ prˇi chybeˇ na disku: Jeden vadny´ klastr zpu˚sobı´ necˇitelnost cele´ho zbytku souboru. Variaci spojove´ho seznamu pouzˇ´ıva´ MS-DOS: Tabulka FAT umı´steˇna´ na zacˇa´tku disku obsahuje tolik buneˇk, kolik je klastru˚, kde v kazˇde´ je vy´sˇe popsany´ odkaz na na´sledujı´cı´ klastr v rˇeteˇzu 144

souboru. Samotne´ klastry na disku pak jizˇ obsahujı´ jen data souboru. Nejde tedy o zcela jiny´ syste´m, jen o jinou implementaci spojove´ho seznamu. Vy´hodou tohoto rˇesˇenı´ je, zˇe nalezenı´ ktere´koliv cˇa´sti souboru je mnohem rychlejsˇ´ı, nebot’ na´m k neˇmu stacˇ´ı nacˇ´ıst FAT a projı´t odkazy, zatı´mco klastry obsahujı´cı´ nepotrˇebne´ cˇa´sti dat nacˇ´ıtat nemusı´me. Dalsˇ´ı vy´hodou je snadne´ hleda´nı´ volne´ho mı´sta. Vy´sˇe uvedena´ souvisla´ alokace, ani klasicky´ spojovy´ seznam totizˇ nedoka´zˇ´ı neˇjak efektivneˇ najı´t volne´ mı´sto na disku bez toho, aby nacˇetli data vsˇech souboru˚. Alternativou (platnou pro kazˇdy´ syste´m) mu˚zˇe by´t tzv. bitova´ mapa volny´ch klastru˚, cozˇ je bitove´ pole, kde jednicˇka cˇi nula na kazˇde´ pozici znacˇ´ı obsazenı´ cˇi uvolneˇnı´ prˇ´ıslusˇne´ho klastru. Nevy´hodou bitove´ mapy je, zˇe jejı´ udrzˇova´nı´ stojı´ vy´pocˇetnı´ cˇas, zpu˚sobuje dodatecˇne´ cˇtenı´ a za´pisy disku. Mapa volny´ch klastru˚ i FAT tabulka nesou jiste´ informace o klastrech. Pokud dojde k selha´nı´ syste´mu (naprˇ. v du˚sledku vypnutı´ proudu) v okamzˇiku za´pisu, pak FAT tabulka cˇi bitova´ mapa neodpovı´dajı´ skutecˇne´mu obsahu disku, prˇicˇemzˇ du˚sledkem je dle konkre´tnı´ situace te´meˇrˇ libovolne´ mozˇne´ posˇkozenı´ dat na disku. Toto je proto nutne´ rˇesˇit kontrolou disku prˇ´ıslusˇny´m programem po kazˇde´m takove´m selha´nı´ syste´mu. (V MS-DOSu a Windows 95 je k tomu prˇ´ıkaz scandisk.) Nevy´hodou FAT tabulky je take´ pomalejsˇ´ı prˇ´ıstup k souboru˚m, protozˇe syste´m musı´ kromeˇ vlastnı´ch souboru˚ pru˚beˇzˇne´ nacˇ´ıtat i ru˚zne´ cˇa´sti FAT do pameˇti. Toto zpomalenı´ mu˚zˇe by´t dosti znatelne´, proto je FAT jednı´m z hlavnı´ch kandida´tu˚ na cachova´nı´. Cachova´nı´ FAT tabulky obvykle probı´ha´ podobneˇ jako u adresa´rˇu˚: Prˇi prvnı´m nacˇtenı´ urcˇite´ cˇa´sti tato zu˚sta´va´ v cache pro dalsˇ´ı pouzˇitı´. 13.6.3

Indexovana´ alokace

Dalsˇ´ı alternativou je vedenı´ seznamu pouzˇity´ch klastru˚ pro kazˇdy´ soubor a jejich ulozˇenı´ k podobeˇ posloupnosti jejich cˇ´ısel (indexu˚) na zacˇa´tku souboru (v jeho prvnı´m klastru). Indexova´ tabulka je tedy jakousi „malou FAT“ u kazˇde´ho souboru. Toto rˇesˇenı´ tedy ma´ podobne´ vlastnosti jako prˇi pouzˇitı´ FAT tabulky, ale prˇ´ıstup k disku je rychlejsˇ´ı, protozˇe cˇ´ısla pouzˇity´ch klastru˚ jsou na jednom mı´steˇ. Nevy´hodou je, zˇe kazˇdy´ soubor potrˇebuje vı´ce prostoru na disku pro ulozˇenı´ tabulky indexu˚. Abychom umozˇnili vytva´rˇenı´ velky´ch souboru˚, tabulka musı´ by´t hodneˇ velka´, cozˇ je pak ale zvla´sˇt’neefektivnı´ u maly´ch souboru˚. Tento proble´m lze rˇesˇit bud’vı´ceu´rovnˇovy´mi odkazy (jako u stra´nkovacı´ch tabulek, viz kap. 9.3 na straneˇ 89). Vy´hodnou alternativou mu˚zˇe by´t kompromisnı´ sche´ma, kde indexova´ tabulka ma´ jen neˇkolik ma´lo za´znamu˚, kde prvnı´ch neˇkolik z nich jsou prˇ´ıme´ odkazy na klastry a dalsˇ´ı ukazujı´ neprˇ´ımo na klastry obsahujı´cı´ pokracˇova´nı´ indexove´ tabulky. Tento zpu˚sob je pouzˇity´ naprˇ. v syste´mu UFS. 13.6.4

Srovna´nı´

Nelze rˇ´ıci, ktery´ alokacˇnı´ model je obecneˇ nejlepsˇ´ı, protozˇe ru˚zne´ zpu˚soby (strategie) vyuzˇitı´ disku mohou ve´st k volbeˇ jine´ho alokacˇnı´ho modelu. Naprˇ´ıklad aplikace vyzˇadujı´cı´ prˇedevsˇ´ım sekvencˇnı´ cˇtenı´ jisteˇ budou nejle´pe fungovat s obycˇejnou souvislou alokacı´, protozˇe cˇtenı´ je zde nejrychlejsˇ´ı. Tento zpu˚sob je take´ de facto prˇenesenı´ zpu˚sobu, jaky´m fungujı´ magneticke´ pa´sky, na disky. Proto software urcˇene´ pu˚vodneˇ pro pa´skova´ zarˇ´ızenı´ bude se souvislou alokacı´ mı´sta na disku fungovat stejneˇ dobrˇe. Spojove´ seznamy rˇesˇ´ı rˇadu proble´mu˚ souvisle´ alokace, zvla´sˇteˇ fragmentaci, ale majı´ proble´my s prˇ´ımy´m prˇ´ıstupem. Neˇktere´ syste´my proto pro soubory prˇ´ıme´ho prˇ´ıstupu pouzˇ´ıvajı´ jiny´ alokacˇnı´ model nezˇ pro klasicke´ sekvencˇnı´ soubory. Soubory urcˇene´ pro sekvencˇnı´ cˇtenı´ pak pouzˇ´ıvajı´ spojovy´ seznam, zatı´mco soubory urcˇene´ pro sekvencˇnı´ i prˇ´ımy´ prˇ´ıstup pouzˇ´ıvajı´ souvislou alokaci a musejı´ mı´t prˇedem pevneˇ danou velikost. Indexova´ alokace je take´ pomala´, zvla´sˇteˇ u vı´ceu´rovnˇovy´ch tabulek, kde pro nacˇtenı´ indexu prvnı´ho klastru mu˚zˇe by´t potrˇeba nacˇ´ıst neˇkolik jiny´ch klastru˚ umı´steˇny´ch trˇeba i v ru˚zny´ch cˇa´stech disku. 145

Vsˇechny druhy spojovy´ch seznamu˚ i indexovy´ch tabulek je mozˇno uchova´vat v cache, ovsˇem jen pokud je k dispozici dostatecˇna´ pameˇt’. V prˇ´ıpadeˇ, zˇe cache je pouzˇita, pra´ce s diskem mu˚zˇe by´t srovnatelneˇ rychla´ (oproti souvisle´ alokaci), bez cache je zpomalenı´ (zvla´sˇteˇ u pomaly´ch me´diı´ jako je naprˇ. disketa) dosti znatelne´. Obecneˇ mu˚zˇe rychlosti prospeˇt kromeˇ spra´vne´ volby alokacˇnı´ho algoritmu take´ jeho dodatecˇna´ u´prava. Naprˇ. uprˇednostneˇnı´ alokace vı´ce sousedı´cı´ch klastru˚ najednou obvykle poma´ha´, nebot’ umozˇnı´ veˇtsˇ´ı (delsˇ´ı) neprˇerusˇene´ DMA prˇenosy z/na disk. U vı´ceu´lohovy´ch syste´mu˚ mu˚zˇe takovy´ postup take´ znamenat snı´zˇenı´ fragmentace souboru˚ (cozˇ u diskety opeˇt vede ke znacˇne´mu zrychlenı´ cˇtenı´ i za´pisu). Jelikozˇ CPU je dnes o neˇkolik rˇa´du˚ rychlejsˇ´ı nezˇ disk, i velmi slozˇity´ ko´d mu˚zˇe by´t prˇ´ınosny´, pokud povede k usˇetrˇenı´ asponˇ neˇkolika prˇ´ıstupu˚ na disk.

13.7

Evidence volne´ho mı´sta

Proble´m evidence volne´ho mı´sta na disku jsme zmı´nili jizˇ v prˇedchozı´ sekci v souvislosti s jeho alokacı´. Evidence volne´ho mı´sta je potrˇeba v okamzˇiku, kdy zakla´da´me soubor cˇi zapisujeme nova´ data. Bez ohledu na pouzˇity´ alokacˇnı´ algoritmus, syste´m musı´ veˇdeˇt, odkud bra´t dalsˇ´ı klastry pro zapisovany´ soubor. Za´kladnı´ metodou evidence volne´ho mı´sta je bitova´ mapa zmı´neˇna´ v prˇedchozı´ sekci. Nevy´hodou mu˚zˇe by´t velikost te´to tabulky. Pomeˇrna´ velikost k cele´mu disku je sice mala´ (1 bit na klastr, cˇili minima´lneˇ 1:4096 a v praxi i vı´ce), zdlouhave´ mu˚zˇe by´t procha´zenı´ te´to tabulky prˇi hleda´nı´ onoho jednoho volne´ho klastru. Naprˇ. u 400GB disku je trˇeba projı´t azˇ 100MB a hledat jednicˇku cˇi nulu (viz poveˇstne´ hleda´nı´ jehly v kupce sena). Procha´zenı´ je samozrˇejmeˇ v pru˚meˇru tı´m pomalejsˇ´ı, cˇ´ım plneˇjsˇ´ı je disk. Kromeˇ samotne´ho procha´zenı´ je vsˇak prˇedevsˇ´ım trˇeba oneˇch 100MB nacˇ´ıst do pameˇti a zde je cˇasova´ na´rocˇnost jizˇ znacˇna´. Alternativou mu˚zˇe by´t pouzˇitı´ spojove´ho seznamu, obdobneˇ jako u alokace mı´sta pro soubory. Tentokra´t tedy spojovy´ seznam eviduje vsˇechno volne´ mı´sto, jakoby patrˇilo do specia´lnı´ho souboru. Klasicka´ implementace je zde velmi nevy´hodna´, protozˇe zjisˇteˇnı´ volne´ho mı´sta mu˚zˇeme prova´deˇt jedineˇ tak, zˇe volne´ klastry nacˇ´ıta´me (zbytecˇneˇ) do pameˇti. Vhodneˇjsˇ´ı mu˚zˇe by´t evidence veˇtsˇ´ıho pocˇtu volny´ch klastru˚ v prvnı´m z nich pomocı´ indexove´ tabulky, kde poslednı´ odkaz vede na klastr s pokracˇova´nı´m te´to indexove´ tabulky. Pra´ce s tı´mto volny´m mı´stem nynı´ bude mnohem rychlejsˇ´ı. Vhodny´m doplnˇujı´cı´m mechanizmem je namı´sto evidence kazˇde´ho jednotlive´ho klastru evidovat jejich souvisle´ bloky. V tom prˇ´ıpadeˇ pro kazˇdy´ souvisly´ blok volny´ch klastru˚ evidujeme jeho pocˇa´tek a de´lku. Prˇi vysoke´ fragmentaci disku je tento prˇ´ıstup dvakra´t na´rocˇneˇjsˇ´ı (potrˇebujeme dveˇ hodnoty pro kazˇdy´ volny´ klastr), ale v praxi dı´ky neˇmu naopak mı´sto obvykle usˇetrˇ´ıme.

13.8

Efektivita a vy´kon diskovy´ch operacı´

Disky jsou dnes nejpomalejsˇ´ı soucˇa´stı´ pocˇ´ıtacˇe, zefektivneˇnı´ jejich cˇinnosti je tedy velmi zˇa´doucı´. Obecneˇ lze rˇ´ıci, zˇe modernı´ operacˇnı´ syste´my dosahujı´ nejlepsˇ´ıch vy´sledku˚ tehdy, kdyzˇ minimalizujı´ pocˇet prˇ´ıstupu˚ na disk a kdyzˇ data na neˇm organizujı´ tak, aby se v kazˇde´m kra´tke´m cˇasove´m u´seku prˇistupovalo pokud mozˇno jen do neˇjake´ dostatecˇneˇ male´ oblasti disku (princip lokality). Obvykle by´va´ vhodne´ do jiste´ mı´ry obeˇtovat efektivitu vyuzˇitı´ prostoru na u´kor rychlosti. Proto se beˇzˇneˇ pouzˇ´ıvajı´ veˇtsˇ´ı klastry, kdy docha´zı´ z vnitrˇnı´ fragmentaci diskove´ho prostoru, ale zrychlujı´ se vsˇechny diskove´ operace dı´ky snı´zˇenı´ vneˇjsˇ´ı fragmentace. Syste´my nabı´zejı´cı´ vysˇsˇ´ı funkcionalitu ji cˇasto nabı´zejı´ pra´veˇ na u´kor rychlosti. Naprˇ. NTFS eviduje nejen beˇzˇny´ cˇas poslednı´ zmeˇny souboru, ale i cˇas poslednı´ho cˇtenı´. Prˇi kazˇde´m prˇ´ıstupu k souboru tedy syste´m musı´ nacˇ´ıst blok popisujı´cı´ soubor, zmeˇnit v neˇm datum a opeˇt jej ulozˇit. Pocˇet diskovy´ch operacı´ se tı´m samozrˇejmeˇ zvysˇuje. 146

U velky´ch disku˚ (cozˇ je relativnı´ pojem, takzˇe se to ty´ka´ vlastneˇ vsˇech disku˚) je ota´zkou take´ velikost datovy´ch polozˇek pro cˇ´ıslova´nı´ klastru˚. Jsou-li male´, pak je maxima´lnı´ velikost disku limitova´na. Jsou-li vsˇak prˇ´ılisˇ velke´, je mnoho diskove´ kapacity vyply´tva´no na tyto hodnoty. Naprˇ´ıklad u beˇzˇne´ 1.44MB diskety nenı´ vhodne´ pouzˇ´ıvat stejny´ syste´m jako u 1TB pevne´ho disku, protozˇe bychom tı´m skutecˇneˇ vyuzˇitelnou kapacitu diskety zbytecˇneˇ zmensˇili. Prvkem ovlivnˇujı´cı´m rychlost pra´ce s diskem je prˇedevsˇ´ım cache. MS-DOS implementuje diskovou cache jako samostatny´ program (smartdrv), ktery´ si pro sebe alokuje jiste´ mnozˇstvı´ pameˇti, ve ktere´ udrzˇuje posledneˇ pouzˇ´ıvane´ klastry disku. Vzhledem k tomu, zˇe samotny´ MSDOS vyuzˇije v za´sadeˇ jen 1MB, zby´va´ obvykle dost pameˇti pro potrˇeby cache. Modernı´ syste´my (NT, Linux, Solaris aj.) vsˇak pracujı´ s operacˇnı´ pameˇtı´ efektivneˇji: Pouzˇ´ıvajı´ jednotnou cache pro pameˇt’ove´ stra´nky i soubory a soubory cachujı´ na u´rovni souborovy´ch dat (vysˇsˇ´ı abstrakce), namı´sto klastru˚. Spra´va pameˇti a diskove´ operace tedy jsou implementova´ny dohromady v jedne´ cˇa´sti syste´mu. Toto komplikovane´ rˇesˇenı´ vyzˇaduje rˇadu detailnı´ch nastavenı´, aby nedocha´zelo k tomu, zˇe prˇi na´rocˇneˇjsˇ´ıch diskovy´ch operacı´ch se odswapujı´ procesy a pameˇt’zbytecˇneˇ zaplnı´ diskove´ soubory, nebo obra´ceneˇ. Pru˚vodce studiem Zajı´mavou anoma´lii mu˚zˇeme objevit prˇi porovna´nı´ MS-DOSu a Windows NT. Windows NT ma´ svou jednotnou cache prˇ´ımo v ja´dru syste´mu, zatı´mco ovladacˇ disku je samostatny´ modul. MS-DOS naopak implementuje ovladacˇ disku prˇ´ımo v ja´dru syste´mu, ale diskovou cache musı´me doplnit pomocı´ dodatecˇne´ho programu. Rˇesˇenı´ MS-DOSu je de facto prˇesny´m opakem optima´lnı´ho stavu, proto lze s urcˇitou nadsa´zkou hovorˇit o anoma´lii. Cachovacı´ algoritmy jsou u disku˚ stejne´ jako u operacˇnı´ pameˇti s tı´m, zˇe prˇi pra´ci s diskem ma´me u´plnou kontrolu nad tı´m, kdy se ke ktere´mu bloku prˇistupuje, takzˇe je mozˇno implementovat i naprˇ. algoritmus LRU (least recently used), ktery´ u operacˇnı´ pameˇti efektivneˇ implementovat nelze. U disku˚ je prˇitom implementace jednoducha´: Stacˇ´ı evidovat seznam bloku˚ serˇazeny´ tak, zˇe na konci je vzˇdy posledneˇ prˇistupovany´. Tento seznam udrzˇujeme v pevne´ velikosti, takzˇe prˇi prˇida´nı´ nove´ho bloku vzˇdy nejstarsˇ´ı vyhodı´me. Podobneˇ lze bez proble´mu implementovat a pouzˇ´ıt i LFU cˇi MFU. Jelikozˇ provoznı´ rezˇie diskove´ cache je velmi mala´ ve srovna´nı´ s mozˇnou u´sporou cˇasu prˇ´ıstupu k disku, osveˇdcˇujı´ se i sofistikovaneˇjsˇ´ı algoritmy, naprˇ´ıklad kombinace LFU a LRU, kdy cˇerstveˇ nacˇtene´ stra´nky (ty majı´ nejme´neˇ prˇ´ıstupu˚) jsou organizova´ny pomocı´ LRU a drˇ´ıve nacˇtene´ stra´nky jsou organizova´ny pomocı´ LFU. Prˇi zarˇazenı´ nove´ stra´nky se tato zarˇadı´ vzˇdy do prvnı´ sekce, nejstarsˇ´ı stra´nka z nı´ se zarˇadı´ do druhe´ sekce a z nı´ se vyrˇadı´ nejme´neˇ pouzˇ´ıvana´ stra´nka. (Samozrˇejmeˇ existuje vı´ce mozˇnostı´, jak LRU a LFU kombinovat.) Pouzˇitı´ jednotne´ spra´vy virtua´lnı´ pameˇti spolecˇneˇ se syste´mem mapova´nı´ souboru˚ do pameˇti vede paradoxneˇ k velmi jednoduche´mu zpu˚sobu pra´ce se soubory: Prˇi otevrˇenı´ souboru se provede jeho mapova´nı´ do pameˇti a vsˇechny stra´nky se oznacˇ´ı jako alokovane´ a odswapovane´ (a „necˇekaneˇ“: namı´sto swapovacı´ho souboru jsou odswapova´ny pra´veˇ do onoho mapovane´ho souboru). Prˇi pra´ci s jednotlivy´mi cˇa´stmi souboru pak docha´zı´ k jeho nacˇtenı´ prˇes demand paging. Takto se vyrˇizuje jak cˇtenı´, tak za´pis a prˇi zavrˇenı´ souboru stacˇ´ı jen odswapovat stra´nky, ktere´ majı´ prˇ´ıznak zmeˇny. Pru˚vodce studiem Prvnı´m masoveˇ rozsˇ´ırˇeny´m syste´mem s jednotnou spra´vou virtua´lnı´ pameˇti byl NT. Jak uva´dı´ Silberschatz [SGG05], Solaris naprˇ´ıklad vesˇkerou pra´ci s diskem interneˇ takto prˇeva´dı´ na mapova´nı´ souboru a tı´m jej zahrne do sve´ho jednotne´ho cachovacı´ho syste´mu. U knihoven vysˇsˇ´ıch jazyku˚, ktere´ implementujı´ vlastnı´ diskove´ operace (naprˇ. u jazyka C), obvykle najdeme vlastnı´ cachova´nı´. Soubor se pak cachuje vlastneˇ (minima´lneˇ) dvakra´t: Poprve´ spra´vcem pameˇti v operacˇnı´m syste´mu prˇi fyzicke´m cˇtenı´ z disku a podruhe´

147

v knihovneˇ vysˇsˇ´ıho jazyka. Dı´ky ostre´mu nepomeˇru rychlosti CPU a disku˚ se toto v praxi obvykle prˇ´ılisˇ neprojevı´. Ve specia´lnı´ch prˇ´ıpadech vsˇak mu˚zˇe by´t dvojı´ cachova´nı´ zdrojem zpomalenı´, ale take´ zrychlenı´, pra´veˇ podle konkre´tnı´ situace.

Dalsˇ´ım prvkem zrychlujı´cı´m pra´ci s diskem je asynchronnı´ za´pis. Toto souvisı´ s diskovou cache: Zapisovana´ data jdou jen do cache a na disk se zapisujı´ azˇ pozdeˇji. Tento zpu˚sob pouzˇ´ıva´nı´ cache se nazy´va´ write–back cache, zatı´mco prˇ´ımy´ za´pis s uchova´nı´m kopie v pameˇti je write through cache. (Druhy´ jmenovany´ zpu˚sob byl pouzˇ´ıva´n zejme´na v MS-DOSu.) NT naprˇ´ıklad nabı´zı´ funkce pro explicitnı´ asynchronnı´ za´pis, kdy je proces informova´n v okamzˇiku skutecˇne´ho fyzicke´ho zapsa´nı´ dat. To vsˇak v praxi neprˇina´sˇ´ı zˇa´dny´ zvla´sˇtnı´ benefit, beˇzˇne´ syste´my pro tento u´cˇel navı´c majı´ i zvla´sˇtnı´ funkci (flush – vypra´zdni buffery). NT vsˇak stejnou funkcionalitu nabı´zı´ i pro cˇtenı´, tj. umozˇnˇuje zaha´jit asynchronnı´ cˇtenı´ s tı´m, zˇe proces je informova´n o jeho dokoncˇenı´. Asynchronnı´ cˇtenı´ disku bylo po dlouha´ le´ta vy´sadou NT, v poslednı´ verzi Linuxu (kernel 2.6) ji vsˇak jizˇ najdeme take´ a stejneˇ tak se postupneˇ dosta´va´ do ru˚zny´ch klonu˚ Unixu. (Linux a Unix v tomto smeˇru vsˇak nejsou kompatibilnı´, asponˇ zatı´m.) Pru˚vodce studiem Acˇkoliv pojmy blokujı´cı´/neblokujı´cı´ a synchronnı´/asynchronnı´ jsou ve skutecˇnosti neza´visle´, v praxi pouzˇ´ıvane´ metody jsou obvykle bud’synchronnı´ a blokujı´cı´, nebo asynchronnı´ a neblokujı´cı´. Proto tyto pojmy do urcˇite´ mı´ry sply´vajı´.

Sekvencˇnı´m cˇtenı´ souboru je mozˇno da´le optimalizovat. (Za´kladem je, aby uzˇivatelsky´ proces syste´mu ozna´mil, zˇe bude cˇ´ıst pouze sekvencˇneˇ.) Obecneˇ pouzˇ´ıvany´ algoritmus vy´beˇru obeˇti LRU je prˇi sekvencˇnı´m cˇtenı´ vhodne´ nahradit jiny´m, protozˇe posledneˇ pouzˇ´ıvana´ stra´nka se po prˇesunu na dalsˇ´ı jizˇ pouzˇ´ıvat nebude, ale v LRU bude mı´t nejvysˇsˇ´ı prioritu a nejspı´sˇe jesˇteˇ dlouho zu˚stane v pameˇti. Princip free–behind likviduje z pameˇti prˇecˇtene´ stra´nky souboru okamzˇiteˇ, jakmile se nacˇ´ıta´ stra´nka dalsˇ´ı. Princip read–ahead naopak prˇi cˇtenı´ nacˇ´ıta´ vı´ce stra´nek souboru najednou, protozˇe vı´, zˇe prˇi sekvencˇnı´m cˇtenı´ by se stejneˇ pozdeˇji nacˇetly a nacˇtenı´m veˇtsˇ´ıho bloku najednou, jak vı´me, se pra´ce s diskem zrychlı´. Pru˚vodce studiem Disk CD-ROM (a podobne´) ukla´da´ data do spira´ly a disk se v mechanice neusta´le ota´cˇ´ı. Prˇi cˇtenı´ se cˇtecı´ hlava postupneˇ posouva´ po spira´le. Prˇi prˇerusˇenı´ cˇtenı´ ztratı´me pozici ve spira´le a prˇi dalsˇ´ım pokracˇova´nı´ ve cˇtenı´ se tato musı´ pomeˇrneˇ obtı´zˇneˇ hledat. Proto se u CD a DVD zvla´sˇt’ vyplatı´ nacˇ´ıtat i velke´ bloky dat doprˇedu. Na druhou stranu je trˇeba dodat, zˇe tato vlastnost je samozrˇejmeˇ vsˇeobecneˇ zna´ma, takzˇe i samotna´ CD/DVD mechanika se snazˇ´ı nacˇ´ıtat data doprˇedu (read–ahead) a uchova´va´ si je ve sve´m bufferu. Pokud prˇijde pozˇadavek na prˇecˇtenı´ dalsˇ´ıho bloku dostatecˇneˇ brzy, mechanika prˇeda´ jizˇ nacˇtena´ data ze sve´ho bufferu a cˇtenı´ disku tedy pokracˇuje neprˇerusˇeneˇ da´l. Prˇi delsˇ´ım zdrzˇenı´ CPU je pak vsˇak dalsˇ´ı penalizace kvu˚li zmı´neˇne´mu nutne´mu hleda´nı´ pozice poslednı´ho cˇtenı´. Cˇtenı´ CD je tedy dı´ky read–ahead asynchronnı´, i kdyzˇ jsou cˇtecı´ funkce blokujı´cı´. (Stejny´ princip se pouzˇ´ıva´ i na pevne´m disku, jen s mensˇ´ım rychlostnı´m ziskem.)

Pouzˇitı´ write–back cache prˇina´sˇ´ı i mozˇnost optimalizace postupu za´pisu. Ovladacˇ disku totizˇ namı´sto postupne´ho zapisova´nı´ bloku˚ dat z cache mu˚zˇe zmeˇnit porˇadı´ pozˇadavku˚ tak, aby posuny hlavy byly co nejkratsˇ´ı. Existuje prˇitom neˇkolik strategiı´, prˇedstavı´me si je podrobneˇji v kapitole 13.11 na straneˇ 151.

148

13.9

Chyby a zotavenı´ z nich

Chyby souvisejı´cı´ se souborovy´m syste´mem jsou nejcˇasteˇji du˚sledkem selha´nı´ syste´mu v okamzˇiku, kdy data na disku nejsou v konzistentnı´m stavu. V te´to sekci se tedy nebudeme prˇ´ılisˇ zaby´vat hardwarovy´mi selha´nı´mi disku˚ a jiny´ch datovy´ch me´diı´, ale zameˇrˇ´ıme se pra´veˇ na problematiku konzistence. 13.9.1

Konzistence

Jak vı´me, rˇada cˇasto pouzˇ´ıvany´ch informacı´ je dlouhodobeˇ udrzˇova´na v cache za u´cˇelem zrychlenı´ diskovy´ch operacı´. Vı´me, take´, zˇe zmeˇny v teˇchto datech nejsou na disk zapisova´ny ihned, ale obvykle azˇ pozdeˇji a postupneˇ dle vytı´zˇenı´ syste´mu (write–back princip). Dojde-li k selha´nı´ syste´mu, cˇili k hava´rii pocˇ´ıtacˇe (softwarove´ cˇi hardwarove´), pak data v cache, ktera´ nebyla zapsa´na na disk, jsou ztracena. S ohledem na to, zˇe disky a cache jsou dnes jizˇ pomeˇrneˇ velke´, beˇzˇneˇ se sta´va´, zˇe prˇi takove´m selha´nı´ jsou neˇktera´ spolu souvisejı´cı´ data jizˇ zapsa´na na disk, zatı´mco jina´ ne. Pru˚vodce studiem Mı´sto pojmu „selha´nı´ syste´mu“ by mozˇna´ bylo prˇesneˇjsˇ´ı hovorˇit o „hava´rii“, nebot’ na´s zajı´majı´ jen ty selha´nı´, ktera´ vedou k prˇedcˇasne´mu ukoncˇenı´ cˇinnosti cˇi u´plne´ho restartu operacˇnı´ho syste´mu a pocˇ´ıtacˇe. Dohodneˇme se vsˇak, zˇe v te´to kapitole budeme tyto stavy nazy´vat pra´veˇ selha´nı´m syste´mu.

Uved’me si jednoduchy´ prˇ´ıklad nekonzistence disku: Prˇi za´pisu souboru se syste´mem FAT se nejprve ulozˇ´ı data souboru, pak se v adresa´rˇi vyznacˇ´ı nova´ de´lka souboru a na za´veˇr se ve FAT aktualizuje rˇeteˇz klastru˚ na´lezˇejı´cı´ch k souboru. Prˇi selha´nı´ syste´mu prˇed aktualizacı´ FAT dojde k tomu, zˇe v adresa´rˇi uzˇ je uvedena nova´ de´lka souboru, ale rˇeteˇz ve FAT neexistuje. Pouzˇije-li se opacˇne´ porˇadı´ operacı´, tj. nejprve se aktualizuje FAT, potom adresa´rˇ a na konec soubor, pak opeˇt prˇi selha´nı´ syste´mu po prvnı´m kroku je stav disku nekonzistentnı´. Specia´lneˇ u syste´mu pouzˇ´ıvajı´cı´ch FAT tabulku nebo jine´ typy tabulek zasahujı´cı´ch do vı´ce klastru˚ je pak nejva´zˇneˇjsˇ´ım proble´mem mozˇne´ selha´nı´ beˇhem aktualizace te´to tabulky. Tabulka je pak z cˇa´sti nova´ a z cˇa´sti stara´, cozˇ cˇasto vede azˇ k rozsa´hly´m ztra´ta´m dat na disku. V praxi je navı´c vy´hodne´ FAT tabulku zapisovat azˇ na konci, protozˇe naprˇ. prˇi za´pisu 1000 souboru˚ je zbytecˇne´ po kazˇde´m jednotlive´m za´pisu zdlouhaveˇ aktualizovat FAT tabulku; stacˇ´ı na za´veˇr zapsat novy´ stav po vsˇech zmeˇna´ch. Unix naopak ukla´da´ informace o souboru vzˇdy na jedno mı´sto a to prˇed zaha´jenı´m za´pisu. Prˇi selha´nı´ tedy je za´znam v adresa´rˇi veˇtsˇinou jizˇ novy´ a korektnı´, ale data souboru mohou chybeˇt. Jelikozˇ selha´nı´ syste´mu mu˚zˇe by´t cˇaste´ a nekonzistentnı´ stav disku mu˚zˇe ve´st k rozsa´hly´m chyba´m v budoucnu, vcˇetneˇ celkove´ ztra´ty vsˇech dat, operacˇnı´ syste´my majı´ pro tyto prˇ´ıpady kontrolnı´ programy (fsck (file system check) v Unixu/Linuxu, chkdsk (checkdisk) ve Windows). Posˇkozenı´ konzistence, jak bylo videˇt na prˇ´ıkladu vy´sˇe, se nejcˇasteˇji ty´ka´ evidence obsazeny´ch a volny´ch klastru˚ a adresa´rˇu˚. Pokud jsou vsˇechny tyto u´daje v porˇa´dku, ale nenı´ spra´vneˇ zapsa´n obsah souboru, pak je to sice take´ chyba, ale neovlivnˇuje konzistenci svazku jako celku. Syste´my obvykle doka´zˇ´ı poznat, kdy je trˇeba spousˇteˇt kontrolnı´ programy konzistence disku. Prˇi spra´vne´m vypnutı´ syste´mu se na kazˇdy´ svazek ulozˇ´ı znacˇka, zˇe je v konzistentnı´m stavu. Prˇi prˇedcˇasne´m vypnutı´ tedy tato znacˇka chybı´, takzˇe prˇi prˇ´ısˇtı´m startu syste´m bezpecˇneˇ pozna´, ktere´ svazky je nutno zkontrolovat. Nalezne-li kontrolnı´ program chyby, pokusı´ se je opravit. Mozˇnosti oprav jsou samozrˇejmeˇ za´visle´ na konkre´tnı´ implementaci alokace a strukturˇe svazku. Vy´sledky se mohou lisˇit – od kompletnı´ opravy vsˇech proble´mu˚, azˇ po ztra´tu dat. (Ztra´ta vznika´ 149

naprˇ´ıklad tehdy, kdyzˇ za u´cˇelem znovuzı´ska´nı´ konzistence svazku jsou zrusˇeny vadne´ soubory, u ktery´ch se nevı´, zda jsou jejich data v porˇa´dku, cˇi nikoliv.) Pru˚vodce studiem Mozˇnosti oprav konzistence jsou za´visle´ na konkre´tnı´m forma´tu posˇkozene´ho svazku. Ota´zky na toto te´ma se mohou objevit na zkousˇce, protozˇe spra´vnou odpoveˇdı´ student potvrdı´, zˇe spra´vneˇ cha´pe strukturu dane´ho souborove´ho syste´mu.

13.9.2

Za´lohy

Jednı´m z du˚lezˇity´ch podpu˚rny´ch mechanizmu˚ ochrany prˇed selha´nı´m je za´lohova´nı´ dat. Za´lohova´nı´ lze prova´deˇt i rucˇneˇ, naprˇ. prˇekopı´rova´nı´m du˚lezˇity´ch dat na diskety cˇi CD a jejich ulozˇenı´ na bezpecˇne´m mı´steˇ. Za´lohy nenı´ vhodne´ ukla´dat na mı´steˇ serveru, protozˇe naprˇ. prˇi pozˇa´ru o neˇ prˇijdeme spolu se serverem. U veˇtsˇ´ıch syste´mu˚, trˇeba zmı´neˇny´ch serveru˚, je vsˇak mı´sto rucˇnı´ho za´lohova´nı´ vhodneˇjsˇ´ı nasadit automaticky´ za´lohovacı´ syste´m. Teˇch existuje cela´ rˇada a jejich podrobneˇjsˇ´ı studium je nad ra´mec tohoto kurzu. Za´lohova´nı´ velke´ho mnozˇstvı´ dat je obvykle prova´deˇno na magneticke´ pa´sky, v poslednı´ dobeˇ ale cˇ´ım da´le cˇasteˇji i na za´lozˇnı´ pevne´ disky. Pa´sky jsou obvykle levneˇjsˇ´ı, majı´ vysˇsˇ´ı kapacitu, ale pracuje se s nimi hu˚rˇe. Klesa´nı´ cen disku˚ a ru˚st jejich kapacity vsˇak postupneˇ pa´skova´ zarˇ´ızenı´ vytlacˇuje z trhu. Pro organizaci za´lohova´nı´ lze zvolit ru˚zne´ postupy. Obvykle jednou za cˇas provedeme kompletnı´ za´lohu, zatı´mco v mezilehle´m obdobı´ vzˇdy za´lohujeme jen zmeˇny od poslednı´ za´lohy. Deˇla´meli za´lohy pravidelneˇ, pak zmeˇneˇne´ soubory pozna´me podle jejich data (datum poslednı´ zmeˇny souboru je ulozˇen na disku) nebo take´ podle prˇ´ıznaku za´lohova´nı´, ktery´ veˇtsˇina operacˇnı´ch syste´mu˚ podporuje. Kazˇde´mu souboru je tento prˇ´ıznak nastaven prˇi za´pisu dat a vynulova´n prˇi vytvorˇenı´ za´lohy. (Je to souborova´ obdoba dirty bitu zna´me´ho ze spra´vy pameˇti.)

13.10

Zˇurna´love´ syste´my

Modernı´ souborove´ syste´my obvykle veˇnujı´ problematice konzistence veˇtsˇ´ı pozornost a implementujı´ tzv. log cˇi zˇurna´l (dva na´zvy te´hozˇ). Tento princip je odvozen od relacˇnı´ch databa´zı´, kde se zacˇal pouzˇ´ıvat za stejny´m u´cˇelem – aby prˇi selha´nı´ syste´mu neskoncˇila databa´ze v nekonzistentnı´m stavu. Log je de facto za´pis o vsˇech operacı´ch, ktere´ se deˇjı´ na svazku. Mu˚zˇeme si jej prˇedstavit jako beˇzˇny´ textovy´ soubor, kde si rucˇneˇ zapisujeme, jake´ cˇa´sti disku se postupneˇ meˇnı´ a jak. Ve skutecˇnosti vsˇak log zapisuje sa´m syste´m a jeho podoba je pro neˇj vı´ce cˇitelna´ (nezˇ textove´ soubory blı´zke´ cˇloveˇku). Do logu se zapisujı´ obvykle jen metadata, tj. „data o datech“, nikoliv vsˇak samotna´ data souboru˚. Metadata svazku jsou tedy vsˇechny informace zapsane´ na disku kromeˇ vlastnı´ch teˇl souboru˚. Princip pra´ce s logem je pomeˇrneˇ jednoduchy´ a popı´sˇeme si jej na prˇ´ıkladu syste´mu NTFS, kde se logova´nı´ jako prvnı´ masoveˇ rozsˇ´ırˇilo: Log je soubor na disku a zapisujı´ se do neˇj vsˇechny pla´novane´ operace tak, aby z toho bylo mozˇno tyto operace prove´st nebo zrusˇit. Vlastnı´ data (teˇla) souboru˚ se do logu nezapisujı´. Do procesu za´pisu na disk se take´ vy´razneˇ projevuje pouzˇitı´ cache, takzˇe kazˇda´ zmeˇna disku je provedena ve cˇtyrˇech krocı´ch: 1. Zmeˇna je zapsa´na do logu. Log ve skutecˇnosti zu˚sta´va´ jen v cache. 2. Zmeˇna je provedena. Opeˇt ve skutecˇnosti vsˇe zu˚sta´va´ v cache. 3. Log je zapsa´n z cache na disk. (write–back) 150

Zˇurna´lova´nı´ zajisˇt’uje konzistenci disku.

4. Zmeˇneˇna´ cache je zapsa´na na disk. (write–back) Jakmile jsou zmeˇny skutecˇneˇ na disku, log je vynulova´n (log nikdy neobsahuje jizˇ provedene´ zmeˇny). Jde-li o operace prˇi ktery´ch se zapisujı´ i (nelogovana´) data, pak data souboru mohou by´t z cache zapsa´na fyzicky na disk azˇ po zapsa´nı´ logu. V prˇ´ıpadeˇ selha´nı´ se pak podle logu mohou jednotlive´ neprovedene´ operace prove´st cˇi zrusˇit. Nevy´hodou pouzˇitı´ logu je zpomalenı´ kvu˚li nutnosti zapisovat vsˇe dvakra´t. Vy´hodou je vsˇak to, zˇe log je na jednom mı´steˇ a za´pis do neˇj je rychlejsˇ´ı nezˇ prˇ´ımy´ za´pis zmeˇn na disk. Prˇitom samotne´ zmeˇny lze zapsat azˇ pozdeˇji, jakmile bude pocˇ´ıtacˇ me´neˇ vytı´zˇen. V praxi tedy zˇurna´love´ souborove´ syste´my nejsou dvakra´t pomalejsˇ´ı, jak by se teoreticky mohlo zda´t.

13.11

Pla´nova´nı´ prˇ´ıstupu k disku

V za´veˇru kapitoly jesˇteˇ nava´zˇeme na te´ma efektivity diskovy´ch operacı´ probrane´ v sekci 13.8 ˇ ada syste´mu˚ dnes pouzˇ´ıva´ write back cache a s tı´m spojeny´ opozˇdeˇny´ za´pis na straneˇ 146. R na disk. Opozˇdeˇny´ za´pis prˇitom lze pouzˇ´ıt nejen v souvislosti s cache, ale i jako samostatneˇ pouzˇitelny´ mechanizmus, jak optimalizovat pra´ci s diskem. V obou prˇ´ıpadech mu˚zˇeme usˇetrˇit prˇesuny rame´nka (seek) tı´m, zˇe prˇeusporˇa´da´me pozˇadavky diskovy´ch operacı´ do takove´ho porˇadı´, aby mezi sousednı´mi operacemi byly prˇesuny co nejkratsˇ´ı. Pru˚vodce studiem Problematiku strategie za´pisu na disk je trˇeba vnı´mat v souvislosti s vı´ceuzˇivatelsky´m prostrˇedı´m. Je beˇzˇne´, zˇe na pocˇ´ıtacˇi v danou chvı´li pracuje vı´ce nezˇ jeden uzˇivatel a na pozadı´ jesˇteˇ cˇasto probı´hajı´ neˇjake´ syste´move´ operace (defragmentace disku, antivirova´ kontrola, atp.). V tom prˇ´ıpadeˇ disk dosta´va´ te´meˇrˇ soubeˇzˇneˇ rozdı´lne´ pozˇadavky a obvykle existuje rˇada variant, v jake´m porˇadı´ je plnit, ktere´ se mohou dosti lisˇit co do cˇasove´ efektivity. Tuto optimalizaci mu˚zˇe vsˇak deˇlat nejen operacˇnı´ syste´m, ale cˇasto jizˇ sa´m disk ma´ jistou inteligenci a vestaveˇnou cache a doka´zˇe pozˇadavky zpracova´vat efektivneˇji nezˇ jen klasicky v porˇadı´, v jake´m je dosta´va´. Beˇzˇny´ disk v soucˇasny´ch pocˇ´ıtacˇ´ıch pracuje asynchronneˇ, tj. beˇhem jeho pra´ce se procesor pocˇ´ıtacˇe mu˚zˇe zaby´vat jinou cˇinnostı´. V dobeˇ, kdy disk pra´veˇ nevykona´va´ zˇa´dne´ operace, mu˚zˇe noveˇ prˇ´ıchozı´ pozˇadavek okamzˇiteˇ zacˇ´ıt vykona´vat. V opacˇne´m prˇ´ıpadeˇ jsou vsˇechny prˇ´ıchozı´ pozˇadavky na diskove´ operace zarˇazova´ny do fronty. Po dokoncˇenı´ aktua´lnı´ operace vybere syste´m dalsˇ´ı operaci z fronty cˇekajı´cı´ch a zacˇne ji vykona´vat. Operacˇnı´ syste´m mu˚zˇe pouzˇitı´m vhodne´ strategie vy´beˇru porˇadı´ diskovy´ch operacı´ zrychlit celkovou pra´ci s diskem. Tato strategie je da´na pouzˇity´m algoritmem vy´beˇru pozˇadavku˚ z fronty. Jedna´ se tedy o jistou obdobu algoritmu˚ pro vy´beˇr procesu k beˇhu cˇi stra´nky k odswapova´nı´, protozˇe se opeˇt vybı´ra´ jedna polozˇka z mnoha prvku˚ seznamu, ale v prˇ´ıpadeˇ disku se pouzˇ´ıvajı´ jine´ algoritmy nezˇ u pla´nova´nı´ procesu˚ cˇi stra´nkova´nı´ pameˇti. 13.11.1

Algoritmus FCFS (first come, first served)

Algoritmus FCFS je nejjednodusˇsˇ´ı algoritmus, ktery´ jednodusˇe zpracova´va´ pozˇadavky v porˇadı´, v jake´m prˇicha´zejı´. Tento algoritmus je vzˇdy fe´rovy´, ale pochopitelneˇ je take´ neefektivnı´. 13.11.2

Algoritmus SSTF (shortest seek time first)

Algoritmus SSTF vybı´ra´ pozˇadavek, jehozˇ seek time je nejkratsˇ´ı. Seek time je cˇas potrˇebny´ pro prˇesun rame´nka z aktua´lnı´ pozice na pozici, kde bude vykona´n pozˇadavek. Tento algoritmus 151

Disk pracuje asynchronneˇ.

tedy uprˇednostnˇuje pozˇadavky, ktere´ lze nejrychleji vyrˇ´ıdit. Nenı´ fe´rovy´, protozˇe ve fronteˇ mohou zu˚sta´vat a sta´rnout pozˇadavky na vzda´leny´ch mı´stech disku, na ktere´ nikdy neprˇijde rˇada. Prˇi beˇzˇne´ vı´ceu´lohove´ pra´ci s diskem je takove´ sta´rnutı´ pozˇadavku˚ u tohoto algoritmu dokonce beˇzˇne´. 13.11.3

Algoritmus SCAN

Algoritmus SCAN (tzv. „vy´tah“) systematicky prˇesunuje rame´nko mezi obeˇma konci disku tam a zpeˇt a cestou vykona´va´ pozˇadavky na aktua´lnı´ pozici. Nevy´hodou tohoto algoritmu je, zˇe pozˇadavky ve strˇednı´ cˇa´sti disku se zpracova´vajı´ zhruba dvakra´t rychleji nezˇ pozˇadavky v okrajovy´ch cˇa´stech disku. Prˇi rovnomeˇrne´m rozlozˇenı´ pozˇadavku˚ na disku totizˇ rame´nka v okamzˇiku dojetı´ na jeden okraj disku bude opeˇt zpracova´vat nejprve pozˇadavky ve stejne´ cˇa´sti disku, zatı´mco nejstarsˇ´ı pozˇadavky, ktere´ jsou na opacˇne´ straneˇ disku, zpracuje azˇ na konci zpeˇtne´ho chodu. 13.11.4

Algoritmus C–SCAN (Circular SCAN)

Algoritmus C–SCAN je variantou prˇedesˇle´ho, ktera´ se snazˇ´ı rˇesˇit vy´sˇe zmı´neˇny´ nedostatek. C–SCAN take´ posouva´ rame´nko po disku od kraje ke kraji, ale pozˇadavky zpracova´va´ vzˇdy jen prˇi cesteˇ jednı´m smeˇrem. Tı´m je odstraneˇno zvy´hodnˇova´nı´ strˇednı´ cˇa´sti disku oproti okraju˚m. Pru˚vodce studiem Na´zev Circular SCAN je odvozen od prˇedstavy, zˇe stopy na disku jsou v kruhu a rame´nko se pohybuje jednı´m smeˇrem po tomto kruhu. Za poslednı´ stopou je tedy jakoby opeˇt stopa prvnı´, cozˇ je pak tote´zˇ jako prˇesun rame´nka zpeˇt na zacˇa´tek disku bez realizace cˇekajı´cı´ch operacı´.

13.11.5

Algoritmy LOOK a C–LOOK

LOOK a C–LOOK jsou u´pravou prˇedesˇly´ch dvou, kdy rame´nko necestuje azˇ ke kraji disku, pokud tam nenı´ cˇekajı´cı´ operace na vyrˇ´ızenı´. Tı´m se tedy jednotlive´ cesty zkra´tı´ a vyrˇizova´nı´ pozˇadavku˚ se zrychlı´. Pru˚vodce studiem Na´zev „look“ je odvozen od principu, zˇe syste´m se nejprve „podı´va´“ (anglicky look), na ktere´m mı´steˇ disku je nejkrajneˇjsˇ´ı pozˇadavek, nezˇ tam prˇesune hlavu.

13.11.6

Vy´beˇr vhodne´ho algoritmu

Jak uzˇ vı´me, mozˇny´ch algoritmu˚ pla´nova´nı´ prˇ´ıstupu na disk je mnoho, je tedy ota´zkou, ktery´ z nich je v praxi nejvhodneˇjsˇ´ı. Silberschatz [SGG05] uva´dı´, zˇe nejbeˇzˇneˇjsˇ´ı je SSFT, ktery´ je rychlejsˇ´ı nezˇ FCFS, zatı´mco SCAN varianty se hodı´ pro syste´my s velky´m vytı´zˇenı´m disku. V praxi nasˇteˇstı´ toto pla´nova´nı´ prˇebı´ra´ take´ samotny´ disk, ktery´ obsahuje vlastnı´ inteligenci a pomeˇrneˇ velkou cache. Vy´kon disku je ovlivneˇn take´ zpu˚sobem vyuzˇitı´ pocˇ´ıtacˇe. Budou-li v jednom okamzˇiku dva procesy sekvencˇneˇ cˇ´ıst velke´ soubory, kazˇdy´ z nich bude generovat souvislou rˇadu pozˇadavku˚ na cˇtenı´, obvykle po sobeˇ jdoucı´ch sektoru˚. Z hlediska celkove´ho a dlouhodobe´ho vy´konu syste´mu je pak nejvhodneˇjsˇ´ı nejprve nacˇ´ıst cely´ jeden soubor, a pak 152

teprve prˇejı´t na druhy´ (SSTF), ovsˇem prˇi spolupra´ci vı´ce uzˇivatelu˚ to povede k velmi nevyva´zˇene´mu chova´nı´ syste´mu. Naopak strˇ´ıdave´ vyrˇizova´nı´ pozˇadavku˚ jednotlivy´ch uzˇivatelu˚ (varianty SCAN a LOOK) zajistı´ rovnomeˇrny´ beˇh vsˇech procesu˚, i kdyzˇ celkovy´ vy´kon syste´mu bude zjevneˇ velmi sˇpatny´. Jak uzˇ bylo rˇesˇeno v prˇedchozı´m textu, vy´kon diskovy´ch operacı´ negativneˇ ovlivnˇuje take´ nutnost prˇistupovat k adresa´rˇu˚m (minima´lneˇ prˇi otevı´ra´nı´ souboru je to nezbytne´). Hodneˇ tedy za´lezˇ´ı nejen na algoritmu prˇ´ıstupu k disku, ale take´ na samotne´ organizaci svazku (tj. kde jsou adresa´rˇe) a cache (tj. zda se adresa´rˇe cachujı´ prˇednostneˇ). Z hlediska efektivity pra´ce je take´ zajı´mavy´ jisty´ „souboj“ mezi operacˇnı´m syste´mem a samotny´m diskem. Modernı´ pevne´ disky totizˇ jsou schopny organizovat pozˇadavky tak, aby byl celkovy´ vy´kon co nejvysˇsˇ´ı; operacˇnı´ syste´m na druhe´ straneˇ vı´, zˇe neˇktere´ diskove´ pozˇadavky jsou du˚lezˇiteˇjsˇ´ı nezˇ jine´. Naprˇ´ıklad vy´padky stra´nek prˇi stra´nkova´nı´ je trˇeba vyrˇizovat drˇ´ıve nezˇ za´pis dat z diskove´ cache. Podobneˇ cˇtenı´ disku ma´ prˇednost prˇed za´pisem, pokud je vsˇak cache te´meˇrˇ plna´, pak za´pis musı´ mı´t prˇednost prˇed cˇtenı´m. Podobneˇ prˇi zˇurna´lova´nı´ diskovy´ch operacı´ je prˇ´ımo nezbytne´ pevneˇ urcˇovat porˇadı´ za´pisu˚, aby byla konzistence svazku zarucˇena. (Pokud aktualizace rˇ´ıdicı´ch dat na disku prˇedbeˇhne za´pis zˇurna´lu, mu˚zˇe prˇi vy´padku syste´mu dojı´t k narusˇenı´ konzistence. Viz kap. 14.4 na straneˇ 161.) Situace, kdy operacˇnı´ syste´m prˇebı´ra´ kontrolu nad cˇasovou organizacı´ diskovy´ch pozˇadavku˚, by´va´ neforma´lneˇ oznacˇova´na jako „spoon–feeding“ (krmenı´ lzˇicˇkou – sousto po soustu). Shrnutı´ V te´to kapitole jsme se podı´vali z prakticke´ho a vı´ce technicke´ho hlediska na pra´ci s diskem jakozˇto za´kladnı´m me´diem pro souborovy´ syste´m. V u´vodu kapitoly jsme se sezna´mili se strukturou disku a rozdeˇlenı´m na svazky. Da´le jsme se veˇnovali implementacˇnı´m ota´zka´m: Probrali jsme implementaci adresa´rˇu˚, evidenci volne´ho mı´sta, ota´zky efektivity diskovy´ch operacı´ a algoritmy pla´nova´nı´ prˇ´ıstupu na disk, algoritmy alokace mı´sta na disku. Veˇnovali jsme se take´ problematice chyb, jejich detekci a prˇedcha´zenı´ jim pomocı´ zˇurna´lova´nı´. V na´sledujı´cı´ kapitole budeme pokracˇovat jesˇteˇ vı´ce prakticky a prˇedstavı´me si neˇktere´ konkre´tnı´ souborove´ syste´my. Pojmy k zapamatova´nı´ • • • • • • • • • • • • • • • • • •

plotna stopa cylindr MBR (master boot record) FCB (file control block) write through cache write back cache free behind read ahead zˇurna´lova´nı´ (neboli logova´nı´) pla´nova´nı´ prˇ´ıstupu k disku FCFS (first come first served) SSTF (shortest seek time first) SCAN C–SCAN (circular scan) LOOK C–LOOK (circular look) spoon–feeding („krmenı´ lzˇicˇkou“) 153

Kontrolnı´ ota´zky 1. Vysveˇtlete vy´znam master boot recordu na disku. 2. Jaky´m zpu˚sobem operacˇnı´ syste´my rˇesˇ´ı to, zˇe v syste´mu je obvykle zapojeno vı´ce nezˇ jedno zarˇ´ızenı´ se souborovy´m syste´mem? Je beˇzˇneˇ pouzˇ´ıvane´ rˇesˇenı´ optima´lnı´, nebo byste preferovali spı´sˇe jine´? Proved’te diskuzi. 3. Popisˇte vy´hody a nevy´hody cache typu write through a write back. 4. Prˇi implementaci adresa´rˇu˚ se neˇkdy pouzˇ´ıvajı´ hashovacı´ tabulky. Jaky´ je jejich vy´znam? Je hashovacı´ tabulka struktura za´kladnı´, nebo jen doplnˇkova´? Vysveˇtlete procˇ. 5. Diskovy´ prostor lze alokovat ru˚zny´mi zpu˚soby. Uved’te ru˚zne´ mozˇnosti, jak v syste´mu evidovat prostor prˇideˇleny´ souboru˚m, a proved’te diskuzi. 6. Jak se eviduje volne´ mı´sto na disku? Je takova´ evidence du˚lezˇita´ i u syste´mu˚, ktere´ evidujı´ prˇideˇlene´ mı´sto, takzˇe volne´ je tam pochopitelneˇ vsˇechno ostatnı´ (neprˇideˇlene´ souboru˚m)? Proved’te diskuzi. 7. Jake´ cachovacı´ algoritmy jsou vhodne´ pro cachova´nı´ diskovy´ch operacı´? Je cache syste´m soucˇa´stı´ modulu souborove´ho syste´mu, nebo jine´ cˇa´sti operacˇnı´ho syste´mu? Vysveˇtlete, procˇ tomu tak je a jake´ vy´hody cˇi nevy´hody majı´ jednotliva´ technicky mozˇna´ rˇesˇenı´. 8. Popisˇte princip zˇurna´lova´nı´ diskovy´ch operacı´. Neˇktere´ syste´my zˇurna´lujı´ jen metadata, jine´ pak vsˇechny operace. Diskutujte vy´hody a nevy´hody obou teˇchto prˇ´ıstupu˚. 9. Popisˇte za´kladnı´ algoritmy pla´nova´nı´ prˇ´ıstupu k disku. Ktery´ algoritmus je obecneˇ nejvhodneˇjsˇ´ı? Je lepsˇ´ı, aby toto rˇesˇil operacˇnı´ syste´m, nebo spı´sˇe prˇ´ımo elektronika v pevne´m disku?

154

14

Prˇ´ıklady souborovy´ch syste´mu˚, RAID

Studijnı´ cı´le: V te´to kapitole si prˇedstavı´me neˇkolik souborovy´ch syste´mu˚ z praxe. Jmenoviteˇ to budou syste´my MS-DOSu (FAT), Unixu (UFS) a Windows NT (NTFS). Cı´lem kazˇde´ sekce je popsat strukturu dane´ho souborove´ho syste´mu a take´ diskutovat jeho vy´hody cˇi nevy´hody. Na konci kapitoly se podı´va´me na syste´my diskovy´ch polı´ RAID. Klı´cˇova´ slova: FAT, UFS, NTFS, RAID Potrˇebny´ cˇas: 160 minut.

14.1

´ vod U

Jednotlive´ souborove´ syste´my byly obvykle navrzˇeny take´ specia´lneˇ pro urcˇita´ datova´ me´dia, jako hard disky (cˇesky pevne´ disky) nebo CD-ROM; neˇktere´ z nich prˇitom meˇly to sˇteˇstı´, zˇe z historicky´ch du˚vodu˚ se pouzˇ´ıvaly cˇi dodnes pouzˇ´ıvajı´ na ru˚zny´ch syste´mech cˇi me´diı´ch. Naprˇ. syste´m FAT, ktery´ pu˚vodneˇ pouzˇ´ıval MS-DOS na disketa´ch, se pozdeˇji pouzˇ´ıval take´ na pevny´ch discı´ch a dodnes je to nejrozsˇ´ırˇeneˇjsˇ´ı souborovy´ syste´m vy´meˇnny´ch me´diı´, jako jsou naprˇ. USB disky. Kromeˇ syste´mu FAT, ktery´ si prˇedstavı´me podrobneˇji, se da´le v te´to kapitole podı´va´me take´ na Unix File System (UFS) a NT File System (NTFS). Zmı´nı´me take´ Extended File System (ext) pouzˇ´ıvany´ na Linuxu. Ve vsˇech prˇ´ıpadech (vcˇetneˇ FAT) jde o souborove´ syste´my existujı´cı´ v mnoha verzı´ch, ktere´ se v ru˚zny´ch prˇ´ıpadech ru˚zneˇ lisˇ´ı, od maly´ch detailu˚ azˇ po za´sadnı´ syste´move´ rozdı´ly.

14.2

FAT

V na´sledujı´cı´ch sekcı´ch si prˇedstavı´me neˇkolik konkre´tnı´ch souborovy´ch syste´mu˚. Prvnı´ na rˇadeˇ je syste´m FAT, ktery´ pu˚vodneˇ slouzˇil v syste´mu MS-DOS, kde se pouzˇ´ıval pro diskety i pevne´ disky. Jeho varianty se pouzˇ´ıvaly jako prima´rnı´ souborovy´ syste´m azˇ do Windows Me (ovsˇem ne ve Windows NT) a rozsˇ´ırˇil se jako de facto standardnı´ forma´t disket. Varianty FAT12 a FAT16 bez dlouhy´ch jmen (bude vysveˇtleno nı´zˇe) jsou dnes standardem i de jure a podporujı´ je prakticky vsˇechny operacˇnı´ syste´my pracujı´cı´ s teˇmito disketami. Stejny´ forma´t se dnes pouzˇ´ıva´ take´ pro USB disky. To se vsˇak v budoucnu mu˚zˇe zmeˇnit, jak se jejich kapacity budou zveˇtsˇovat, nebot’FAT12 a FAT16 nejsou pro velke´ svazky vhodne´. Pru˚vodce studiem Za´kladem toho, aby syste´m mohl podporovat forma´t FAT, je mı´t stejny´ cˇi kompatibilnı´ hardware. Prˇitom nejde jen o samotne´ diskety, ale take´ o pouzˇity´ rˇadicˇ. Naprˇ. PC, Macintosh nebo taky Atari ST pouzˇ´ıvajı´ kompatibilnı´ rˇadicˇ a jejich operacˇnı´ syste´my tedy mohou diskety navza´jem cˇ´ıst. Naopak trˇeba Commodore Amiga pouzˇ´ıva´ stejne´ 3.5” diskety, ale jejı´ rˇadicˇ nenı´ schopen magnetickou informaci z PC prˇecˇ´ıst (platı´ i obra´ceneˇ). Samotna´ kompatibilita rˇadicˇe vsˇak nestacˇ´ı ke cˇtenı´ disket. Naprˇ. Sam Coupe´ ma´ stejny´ rˇadicˇ jako Atari ST, ale diskety forma´tuje na 800KB a pouzˇ´ıva´ vlastnı´ zvla´sˇtnı´ souborovy´ syste´m. Naopak Atari ST pouzˇ´ıva´ prˇ´ımo syste´m FAT, takzˇe mu˚zˇe vymeˇnˇovat diskety s PC pocˇ´ıtacˇi prˇ´ımo, zatı´mco diskety ze Sam Coupe´ jdou cˇ´ıst je fyzicky po jednotlivy´ch sektorech. Neˇktere´ mechaniky na PC pak cˇasto mohou mı´t proble´my s hustotou za´pisu, kdyzˇ na disketeˇ je mı´sto obvykly´ch 720KB cely´ch 800KB. (Je rˇecˇ o disketa´ch s dvojitou hustotou MF-2DD 3.5”.) Syste´m FAT je pomeˇrneˇ jednoduchy´. Na zacˇa´tku disku je boot sektor, za nı´m jsou dveˇ identicke´ kopie FAT tabulky, potom korˇenovy´ adresa´rˇ a za nı´m soubory. Adresa´rˇe (kromeˇ korˇenove´ho) se 155

ukla´dajı´ take´ jako soubory. FAT nepodporuje prˇ´ıstupova´ opra´vneˇnı´ (kazˇdy´ soubor je prˇ´ıstupny´ vsˇem) ani jiny´ typ ochrany dat, nepouzˇ´ıva´ zˇurna´l a hlavnı´ nevy´hodou je omezenı´ jmen souboru˚ a adresa´rˇu˚ na 8.3 (8 znaku˚ jme´no + 3 znaky prˇ´ıpona). FAT12 Nejstarsˇ´ı verzı´ FAT je FAT12, ktera´ se objevila jizˇ v roce 1977 (tedy jizˇ 4 roky prˇed uvedenı´m MS-DOSu). Bunˇky FAT tabulky zde majı´ 12 bitu˚, cˇili kazˇde´ trˇi bajty popisujı´ vzˇdy dva sousednı´ klastry. Svazek tedy mu˚zˇe obsahovat max. 212 = 4096 klastru˚. Cˇ´ıslo ulozˇene´ ve FAT tabulce vzˇdy oznacˇuje cˇ´ıslo na´sledujı´cı´ho klastru v rˇeteˇzu souboru. Volne´ klastry majı´ 0 a konec souboru je oznacˇen jako −1. Dalsˇ´ıch neˇkolik hodnot je vyhrazeno pro oznacˇenı´ vadny´ch klastru˚, takzˇe skutecˇna´ maxima´lnı´ kapacita je o neˇco mensˇ´ı nezˇ oneˇch 4096 klastru˚ a za´visı´ take´ na konkre´tnı´ implementaci FAT. Prˇi maxima´lnı´ velikosti klastru 8KB je celkova´ maxima´lnı´ velikost svazku (necely´ch) 32MB. I v soucˇasnosti se FAT12 sta´le pouzˇ´ıva´ jako prima´rnı´ forma´t pro svazky do 32MB. Pru˚vodce studiem Limit 32MB platı´ pro souborovy´ syste´m. V praxi ale mu˚zˇe by´t limitujı´cı´m faktorem take´ implementace v konkre´tnı´m operacˇnı´m syste´mu. Neˇktere´ indexy jsou navı´c rezervovane´, takzˇe skutecˇna´ maxima´lnı´ velikost je vzˇdy o neˇco mensˇ´ı.

FAT tabulka nesoucı´ nejdu˚lezˇiteˇjsˇ´ı informace o svazku je na jeho zacˇa´tku. Konvencı´ dokonce je, zˇe je cela´ na prvnı´ stopeˇ. Diskety s porusˇenou prvnı´ stopou jsou tedy ve FAT syste´mu nepouzˇitelne´. Acˇkoliv FAT je na disketeˇ ulozˇena dvakra´t za sebou, MS-DOS druhou kopii nepouzˇ´ıva´, ani prˇi fyzicke´ chybeˇ na prvnı´ stopeˇ disku. Adresa´rˇe Pu˚vodnı´ FAT syste´m nepodporoval podadresa´rˇe, vsˇechny soubory byly umı´steˇny ve spolecˇne´m adresa´rˇi umı´steˇne´m na disku za FAT tabulkou. Za´znam jednoho souboru zde ma´ 32 bajtu˚. Stromovy´ syste´m adresa´rˇu˚ prˇibyl v syste´mu MS-DOS 2.0 (1983). Zatı´mco korˇenovy´ adresa´rˇ zu˚stal nezmeˇneˇn (ma´ pevnou velikost), dalsˇ´ı podadresa´rˇe je mozˇno vytva´rˇet a libovolneˇ vnorˇovat do stromu, limitujı´cı´m faktorem je pouze de´lka cesty (pocˇet znaku˚). Podadresa´rˇe jsou ulozˇeny jako soubory, samy mohou obsahovat libovolny´ pocˇet souboru˚ a za´znam o kazˇde´m ma´ opeˇt 32 bajtu˚. FAT16 MS-DOS 3.0 (1984) prˇinesl novou verzi FAT, kde polozˇky FAT tabulky meˇly kazˇda´ 16 bitu˚. Od te´ doby se pu˚vodnı´ FAT oznacˇuje jako FAT12 a tato druha´ verze jako FAT16. Neˇktere´ nove´ vlastnosti FAT16 bylo vsˇak mozˇno pouzˇ´ıvat azˇ v pozdeˇjsˇ´ıch verzı´ch syste´mu, protozˇe pu˚vodneˇ bylo hlavnı´m limitujı´cı´m faktorem 16bitove´ cˇ´ıslova´nı´ sektoru˚. (Bez ohledu na dalsˇ´ı forma´t svazku byla maxima´lnı´ velikost 32MB.) Kromeˇ nove´ velikosti FAT tabulky neprˇina´sˇ´ı FAT16 zˇa´dne´ novinky. Maxima´lneˇ tedy lze pouzˇ´ıt svazky o necely´ch 216 klastrech. Syste´my veˇtsˇinou podporujı´ klastry do 32KB a sektory cˇ´ıslujı´ 32bitoveˇ, takzˇe maxima´lnı´ velikost svazku je 2GB. (Neˇktere´ verze Windows podporujı´ i 64KB klastry a 4GB svazky.) Nutno dodat, zˇe prˇi 32KB klastrech docha´zı´ k velke´ fragmentaci (beˇzˇneˇ je ztraceno i 10%–15% diskove´ kapacity).

156

Pru˚vodce studiem Pro zajı´mavost: Velikost klastru je na 32KB omezena tı´m, zˇe pocˇet sektoru˚ v klastru je ulozˇen jako zname´nkove´ 8bitove´ cˇ´ıslo. Maxima´lnı´ mocnina dvojky tedy je 64, cozˇ prˇi 512 bajtech na sektor da´va´ celkoveˇ 32KB. Acˇkoliv velikost sektoru mu˚zˇe by´t take´ zveˇtsˇena (na 1024, 2048 atd.), v praxi se te´meˇrˇ vy´hradneˇ pouzˇ´ıvaly pra´veˇ sektory 512bajtove´. Velikost korˇenove´ho adresa´rˇe se nastavuje prˇi forma´tova´nı´, protozˇe jde o pevneˇ vyhrazeny´ prostor za FAT tabulkou. Jeho velikost je ulozˇena jako 16bitova´ zname´nkova´ hodnota, cˇili je mozˇno nastavit max. prˇiblizˇneˇ 32 tisı´c. Na disketa´ch se vsˇak beˇzˇneˇ pouzˇ´ıva´ jen 256 cˇi 512 polozˇek v adresa´rˇi (cozˇ i tak pro korˇenovy´ adresa´rˇ zabere 8KB cˇi 16KB prostoru diskety). FAT32 Dosud poslednı´ (a zrˇejmeˇ skutecˇneˇ poslednı´) verzı´ FAT je 32bitove´ rozsˇ´ırˇenı´ zna´me´ jako FAT32, ktere´ prˇisˇlo s druhou verzı´ Windows 95 (rok 1996). Polozˇky FAT tabulky nynı´ majı´ 32 bitu˚, cozˇ umozˇnˇuje pouzˇ´ıvat svazky veˇtsˇ´ı nezˇ 2GB a prˇedevsˇ´ım opeˇt se vra´tit k mensˇ´ım velikostem klastru˚. 32bitova´ FAT tabulka teoreticky doka´zˇe popsat velmi velke´ disky, v praxi vsˇak FAT32 nara´zˇ´ı na rˇadu implementacˇnı´ch nedokonalostı´ cˇi omezenı´. Beˇzˇneˇ se pouzˇ´ıva´ jen 28 bitu˚, celkovy´ pocˇet sektoru˚ na disku je taky ve 32bitove´m cˇ´ısle, program scandisk pro kontrolu disku ve Windows 95 pojme jen 22 bitu˚, program fdisk pro vytva´rˇenı´ oddı´lu˚ a svazku˚ na disku je limitova´n na 64GB apod. Microsoft prˇidal do NT podporu FAT32 od verze Windows 2000, ovsˇem pozdeˇji netradicˇnı´m zpu˚sobem FAT32 „pohrˇbil“ tı´m, zˇe nastavil limit velikosti svazku na 32GB. Du˚vodem nenı´ technicke´ omezenı´, ale prosteˇ svobodna´ volba Microsoftu s odkazem na to, zˇe pra´ce a u´drzˇba velky´ch FAT32 disku˚ je velmi cˇasoveˇ na´rocˇna´. A skutecˇneˇ, prˇi selha´nı´ syste´mu trva´ kontrola velke´ho FAT32 disku velmi dlouho, nicme´neˇ Microsoft tı´m FAT32 efektivneˇ pohrˇbil. Dalsˇ´ım proble´mem FAT32 je limit velikosti souboru na 232 − 1 bajtu˚ (4GB), cozˇ je nedostatecˇne´ zejme´na prˇi pra´ci s videem. FAT32 byl pu˚vodneˇ urcˇen prˇedevsˇ´ım pro (tehdy) velke´ pevne´ disky, s u´stupem rˇady Windows 9x vsˇak i FAT32 ztratil svou pozici a dnes mu˚zˇe by´t snad jen alternativou pro velke´ USB disky. (Je ke zva´zˇenı´, zda USB disky forma´tovat do NTFS, cˇi zu˚stat u FAT. Neˇktere´ zdroje uva´deˇjı´, zˇe zˇurna´lova´nı´ v NTFS snizˇuje zˇivotnost pameˇt’ovy´ch cˇipu˚ typu flash pouzˇ´ıvany´ch v USB discı´ch.) Dlouhe´ na´zvy (LFN) Pu˚vodnı´ omezenı´ na´zvu˚ na 8.3 znaku˚ padlo ve Windows 95, ktere´ prˇisˇlo s tzv. „dlouhy´mi na´zvy“ neboli LFN (long file names). Dlouhe´ na´zvy na FAT svazcı´ch podporovalo jizˇ drˇ´ıve i Windows NT, ovsˇem jiny´m nekompatibilnı´m zpu˚sobem, ktery´ se dnes jizˇ nepouzˇ´ıva´. LFN rozsˇ´ırˇenı´ se ty´ka´ jen dat ulozˇeny´ch v adresa´rˇi, je proto pouzˇitelne´ ve vsˇech verzı´ch FAT, pokud to syste´m podporuje. Pokud syste´m LFN nepodporuje, pak LFN za´znamy prˇeskakuje dı´ky nastavenı´ atributu volume label (soubor totizˇ nemu˚zˇe by´t jme´nem svazku), takzˇe lze bez proble´mu prˇena´sˇet diskety mezi Windows a syste´my bez podpory LFN. Dlouhe´ jme´no mu˚zˇe mı´t azˇ 255 znaku˚ v ko´dova´nı´ UTF-16 (cozˇ je taky za´sadnı´ zmeˇna oproti pouze velky´m anglicky´m pı´smenu˚m v pu˚vodnı´ FAT). Jme´na jsou ukla´da´na do buneˇk adresa´rˇove´ struktury, vzˇdy 13 znaku˚ LFN zabere jeden slot. (Tj. naprˇ. soubor se jme´nem o 30 znacı´ch potrˇebuje 3 sloty v adresa´rˇi – jeden pro vlastnı´ soubor a dva pro LFN.) Dodejme, zˇe 8.3 na´zvy jsou vzˇdy velky´mi pı´smeny a kazˇdy´ soubor ma´ ve Windows kromeˇ dlouhe´ho na´zvu i 8.3 alternativu. Tyto alternativy vytva´rˇ´ı syste´m automaticky, pokud je cely´ na´zev souboru kompatibilnı´ s 8.3 syste´mem, pak se LFN za´znam nevytva´rˇ´ı. (Windows 9x prˇitom za kompatibilnı´ akceptuje i cˇeske´ znaky, zatı´mco Windows XP pro zmeˇnu ko´duje mala´/velka´ na zvla´sˇtnı´m mı´steˇ, aby nepotrˇeboval LFN a prˇitom zu˚stal plneˇ kompatibilnı´ se standardem.) 157

Zhodnocenı´ FAT syste´mu Souborovy´ syste´m FAT je vı´ce nezˇ 30 let stary´ a byl navrzˇen pro svazky maly´ch kapacit (rˇa´doveˇ stovky KB na pu˚vodnı´ch disketa´ch) s ohledem na tehdejsˇ´ı prˇevazˇujı´cı´ zpu˚sob pra´ce s diskem a take´ se snahou vyhnout se slozˇite´ implementaci, protozˇe tehdejsˇ´ı pocˇ´ıtacˇe nebyl ani rychle´, ani nemeˇly hodneˇ pameˇti pro pomocne´ datove´ struktury. Z dnesˇnı´ho pohledu tedy mu˚zˇe hodnocenı´ FAT by´t znacˇneˇ deformovane´, nicme´neˇ pra´veˇ z dnesˇnı´ho pohledu jde o syste´m s mnoha nedostatky a nevy´hodami. Na´zvy 8.3 mohou by´t doplneˇny o LFN, v praxi vsˇak prakticky jen syste´my Windows toto podporujı´ a ostatnı´ syste´my zu˚sta´vajı´ jen u 8.3 na´zvu˚. Velikost svazku je znacˇneˇ omezena, na 2GB u FAT16 a 32GB u FAT32. Takto velke´ svazky vsˇak jizˇ majı´ velkou vnitrˇnı´ fragmentaci (v prˇ´ıpadeˇ FAT16) cˇi velmi pomale´ operace jako je kontrola disku prˇi restartu nebo zjisˇt’ova´nı´ volne´ho mı´sta na disku. (Zjistit volne´ mı´sto lze jen nacˇtenı´m a prozkouma´nı´m cele´ FAT tabulky. Ta je u FAT32 velmi velka´.) Syste´m nepodporuje uzˇivatelska´ opra´vneˇnı´. Rychlost je take´ pomeˇrneˇ mala´, nebot’klı´cˇova´ data svazku jsou vsˇechna soustrˇedeˇna na jeho zacˇa´tku a vynucujı´ si tak neusta´le´ prˇesuny rame´nka na zacˇa´tek svazku. Ze stejne´ho du˚vodu je FAT take´ nebezpecˇny´ v okamzˇiku fyzicke´ho porusˇenı´ disku v mı´steˇ zacˇa´tku svazku – takovy´ svazek je nepouzˇitelny´. Zvla´sˇteˇ u disket je podobna´ porucha celkem beˇzˇna´ (prˇi cˇaste´m pouzˇ´ıva´nı´, ty´ka´ se i ZIP a jiny´ch podobny´ch magneticky´ch me´diı´). (Umı´steˇnı´ FAT na jine´ mı´sto disku cˇi jejı´ rozdeˇlenı´ na vı´ce cˇa´stı´ by prˇineslo minima´lneˇ podstatne´ zrychlenı´ a zrˇejmeˇ i veˇtsˇ´ı spolehlivost.) FAT syste´m jsme si prˇedstavili pomeˇrneˇ podrobneˇ, ne vsˇak z du˚vodu jeho du˚lezˇitosti, ale pouze pro uka´zku, zˇe i v takto jednoduche´m souborove´m syste´mu lze najı´t velkou rˇadu detailu˚ komplikujı´cı´ch situaci.

14.3

Unix File System (UFS)

UFS, jak uzˇ sa´m na´zev napovı´da´, je souborovy´ syste´m syste´mu Unix, ktery´ se pouzˇ´ıva´ v ru˚zny´ch varianta´ch v jednotlivy´ch verzı´ch Unixu. V Linuxu se tento syste´m jako prima´rnı´ nikdy nepouzˇ´ıval, i kdyzˇ aktua´lnı´ verze Linuxu jizˇ doka´zˇe s UFS svazky pracovat. Rea´lneˇ pouzˇ´ıvane´ varianty UFS obvykle obsahujı´ ru˚zna´ navza´jem nekompatibilnı´ rozsˇ´ırˇenı´, cozˇ je zrˇejmeˇ prˇedevsˇ´ım du˚sledek sta´rˇ´ı syste´mu cˇi historicke´ho vy´voje. V praxi tedy nelze prˇ´ılisˇ spole´hat na mozˇnost sdı´lenı´ svazku˚ mezi jednotlivy´mi Unixy, i kdyzˇ trˇeba mozˇnost za´kladnı´ho prˇecˇtenı´ obsahu disku a svazku je dı´ky stejny´m datovy´m struktura´m pomeˇrneˇ pravdeˇpodobna´. Stejneˇ jako FAT, pracuje UFS se soubory a adresa´rˇi a nepodporuje zˇurna´lova´nı´. Kromeˇ teˇchto neˇkolika za´kladnı´ch shodny´ch bodu˚ se vsˇak UFS a FAT velmi lisˇ´ı. UFS take´ pouzˇ´ıva´ jinou terminologii (cozˇ mu˚zˇe by´t trochu matoucı´ pro cˇtena´rˇe.) Svazky UFS pracujı´ prˇ´ımo s 512bjtovy´mi sektory, cˇi s veˇtsˇ´ımi klastry, pouze jsou zde nazy´va´ny bloky. Struktura Na zacˇa´tku disku je bootovacı´ blok, pouzˇ´ıvany´ jen prˇi startu syste´mu z dane´ho svazku. Na´sleduje superblok, cozˇ je hlavicˇka obsahujı´cı´ informace o svazku jako celku. Kazˇdy´ soubor (vcˇetneˇ adresa´rˇu˚) je popsa´n strukturou zvanou inode, ktery´ch je na disku pevny´ pocˇet. V adresa´rˇi jsou jen jme´na souboru˚ a odkazy na inode (zvane´ inumber). Vı´ce adresa´rˇovy´ch polozˇek mu˚zˇe odkazovat na tenty´zˇ inode (hard link), cˇili soubor mu˚zˇe mı´t vı´ce jmen. Pocˇet odkazu˚ je ulozˇen v inode a soubor se mazˇe prˇi odstraneˇnı´ poslednı´ho hard linku. Ru˚zne´ varianty Unixu vnesly do UFS rˇadu u´prav, ktery´mi se snazˇily za´platovat nedostatky pu˚vodnı´ho syste´mu bez toho, aby vytva´rˇely zcela nove´ struktury. Beˇhem let se tak objevila rˇada zajı´mavy´ch u´prav z nichzˇ neˇktere´ si nynı´ prˇedstavı´me. 158

Zˇurna´lova´nı´ Zˇurna´lova´nı´ bylo do UFS prˇida´no jako nadstavba jesˇteˇ v pu˚vodnı´m BSD Unixu, kdy dolnı´ vrstva funguje klasicky´m zpu˚sobem a nad nı´ je dalsˇ´ı vrstva, ktera´ implementuje zˇurna´lova´nı´ pomocı´ standardnı´ch diskovy´ch operacı´. Toto rˇesˇenı´ sice nedosahuje kvalit prˇ´ıme´ho zˇurna´lova´nı´ (viz NTFS nı´zˇe), ale oproti pu˚vodnı´mu UFS je to jisteˇ pokrok. Rozdı´l oproti NTFS, kde zˇurna´lova´nı´ je za´kladem syste´mu, v mnoha implementacı´ch UFS se zˇurna´lova´nı´ nepouzˇ´ıva´ vu˚bec, nebo bylo jako standardnı´ funkce prˇijato azˇ pomeˇrneˇ pozdeˇ (naprˇ. Solaris v roce 2004 [McMa06], 11 let po Windows NT a NTFS). Skupiny stop BSD Unix upravil take´ strukturu svazku tak, zˇe jej rozdeˇlil do mensˇ´ıch cˇa´stı´ (skupin stop – cylinder group) a data z kazˇde´ho jednoho adresa´rˇe se snazˇ´ı (pokud se vejdou) umist’ovat vzˇdy do stejne´ cˇa´sti. Prˇi pra´ci v neˇjake´m adresa´rˇi pak nedocha´zı´ k divoky´m prˇesunu˚m rame´nka mezi vzda´leny´mi stopami. (Tato zmeˇna prˇinesla velke´ zrychlenı´, vesˇkery´ zisk vsˇak samozrˇejmeˇ koncˇ´ı v okamzˇiku, kdy na syste´mu pracuje rˇada ru˚zny´ch uzˇivatelu˚ soucˇasneˇ, cozˇ je u serverovy´ch Unixu˚ i docela beˇzˇne´.) Kazˇda´ skupina ma´ vlastnı´ inode objekty a take´ nese kopii superbloku. Rovneˇzˇ evidence volne´ho mı´sta (ve formeˇ seznamu volny´ch bloku˚) je vedena v kazˇde´ skupineˇ zvla´sˇt’. Adresa´rˇe Adresa´rˇe jsou ukla´da´ny jako soubory. Adresa´rˇ prˇitom nese jen jme´no souboru a cˇ´ıslo inode, vsˇe ostatnı´ je v inode. (Zde je rozdı´l oproti syste´mu˚m Microsoftu, kde naprˇ. datum zmeˇny souboru a atributy jsou ulozˇeny v adresa´rˇi.) Jme´na byla pu˚vodneˇ omezena na de´lku 14 znaku˚ kvu˚li pevne´ de´lce za´znamu˚ v adresa´rˇi, pozdeˇji se vsˇak prˇesˇlo na za´znamy promeˇnlivy´ch de´lek a jme´no mu˚zˇe mı´t azˇ 255 znaku˚. Korˇenovy´ adresa´rˇ / ma´ vzˇdy inode cˇ.2 a kazˇdy´ adresa´rˇ obsahuje (pro snadnou navigaci ve stromu i bez cache) jako prvnı´ dveˇ polozˇky . s odkazem na sebe sama a .. s odkazem na nadrˇazeny´ adresa´rˇ. (Tyto odkazy . a .. ma´ v adresa´rˇ´ıch i syste´m FAT.) Teˇla souboru˚ Inode obsahuje take´ popis, kde na disku je teˇlo souboru. Syste´m nema´ zˇa´dnou centra´lnı´ FAT tabulku, kazˇdy´ soubor nese seznam bloku˚ se souborem. Inode obsahuje odkazy na 12 bloku˚, da´le jeden neprˇ´ımy´ odkaz na pokracˇova´nı´ te´to tabulky, pak jesˇteˇ jeden dvojiteˇ neprˇ´ımy´ a jeden trojiteˇ neprˇ´ımy´ odkaz. Neprˇ´ıme´ odkazy jsou pouzˇity jen u velky´ch souboru˚, ktere´ nelze prˇ´ımy´mi odkazy popsat. Kazˇda´ neprˇ´ıma´ tabulka zabı´ra´ cely´ blok, takzˇe maxima´lnı´ velikosti souboru˚ za´visı´ prˇedevsˇ´ım na velikosti bloku. UFS obvykle pouzˇ´ıva´ 8KB bloky (16 sektoru˚, tedy 2–4 kra´t veˇtsˇ´ı nezˇ u syste´mu˚ Microsoftu). Princip prˇ´ımy´ch a neprˇ´ımy´ch odkazu˚ na bloky je zobrazen na obra´zku 22, zde pro velikost bloku 8KB a 32bitovy´ odkaz na blok. Pu˚vodnı´ UFS pouzˇ´ıvalo 16bitove´ odkazy, takzˇe velikost svazku byla limitova´na na 216 × 8KB = 512M B. Prˇechod na 32bitove´ odkazy zobrazene´ na obra´zku 22 prˇinesl mozˇnost pouzˇ´ıvat veˇtsˇ´ı svazky, ale vyzˇa´dal si zmeˇnu struktur inode, jmenoviteˇ zveˇtsˇenı´ ze 64 na 128 bajtu˚. Proto tyto dveˇ varianty UFS jsou zcela nekompatibilnı´. Maxima´lnı´ velikost souboru je tedy dana´ verzı´ UFS a (nelinea´rneˇ) roste s velikostı´ bloku, je vsˇak take´ limitova´na u´dajem o de´lce souboru v inode, cozˇ je na rˇadeˇ implementacı´ 32bitove´ zname´nkove´ cˇ´ıslo, takzˇe soubor nemu˚zˇe mı´t vı´c nezˇ 2GB. (Noveˇjsˇ´ı kvalitnı´ implementace samozrˇejmeˇ toto neprˇ´ıjemne´ omezenı´ jizˇ nemajı´.) Podobneˇ datum je dle Unixovy´ch zvyklostı´ ko´dova´n tak, zˇe nelze vyja´drˇit roky po 2031, a i toto omezenı´ je v noveˇjsˇ´ıch varianta´ch UFS odstraneˇno pouzˇitı´m veˇtsˇ´ı promeˇnne´.

159

Obra´zek 22: Prˇ´ıme´ a neprˇ´ıme´ odkazy na bloky v inode. [McMa06] Bloky a fragmenty Jak vı´me, pouzˇ´ıva´nı´ velky´ch bloku˚ s sebou nese vysˇsˇ´ı rychlost, ale take´ vnitrˇnı´ fragmentaci. Kazˇdy´ soubor zabı´ra´ na disku v pru˚meˇru o polovinu velikosti bloku vı´ce mı´sta, nezˇ je jeho de´lka. Toto ztracene´ mı´sto je prˇitom vzˇdy v poslednı´m bloku souboru. UFS tyto neu´plneˇ vyuzˇite´ bloky rozdeˇluje na mensˇ´ı kousky (na polovinu, cˇtvrtinu cˇi osminu), ktere´ pak mu˚zˇe prˇideˇlit ru˚zny´m souboru˚m. Du˚sledky fragmentace se tak vy´razneˇ zmensˇ´ı. Prˇesneˇjsˇ´ı chova´nı´ UFS se mu˚zˇe lisˇit dle implementace. Solaris kouskuje velke´ soubory, tak zˇe do prvnı´ skupiny stop umı´stı´ jen 12 prˇ´ımo odka´zany´ch bloku˚ a dalsˇ´ı pak da´va´ do dalsˇ´ıch skupin tak, zˇe do kazˇde´ prˇida´ jednu celou tabulku odkazu˚ (tj. 2048 odkazu˚ kra´t 8KB dat = 16MB dat souboru v kazˇde´ skupineˇ stop). Skupiny jsou vybı´ra´ny cyklicky, prˇeskakujı´ se prˇitom ty, ktere´ jizˇ nemajı´ potrˇebnou volnou kapacitu. Cely´ svazek je tedy zaplnˇova´n rovnomeˇrneˇ, soubor 160

prˇitom zacˇ´ına´ vzˇdy ve skupineˇ, kde je jeho adresa´rˇ. Zajı´mave´ take´ je, zˇe velikost skupiny stop je limitova´na na 54MB, takzˇe se tam vejdou 16MB cˇa´sti trˇ´ı souboru˚. (Popsany´ algoritmus zjevneˇ ma´ proble´my v situaci, kdy je svazek te´meˇrˇ plny´ a zˇa´dna´ skupina stop jizˇ nema´ 16MB volne´ho mı´sta.)

14.4

NTFS

NTFS je souborovy´ syste´m Windows NT (tj. od Microsoftu). Pouzˇ´ıva´ se od roku 1993 a od te´ doby doznal v neˇkolika verzı´ch neˇkolika u´prav, ktere´ jsou vsˇak jen kosmeticke´ ve srovna´nı´ s bourˇlivy´m vy´vojem UFS. Syste´m je od zacˇa´tku flexibilneˇ a moderneˇ navrzˇen a i prˇes strmy´ ru˚st kapacit disku˚ za poslednı´ch 10 let (s cˇ´ımzˇ se neˇktere´ syste´my obtı´zˇneˇ vyporˇa´da´vajı´) je bez proble´mu˚ pouzˇitelny´ na discı´ch libovolny´ch kapacit. Prˇitom „masoveˇ“ se zacˇal pouzˇ´ıvat azˇ od Windows 2000 (rok 1999), kdy nahradil dosluhujı´cı´ FAT32. Microsoft uva´dı´, zˇe NTFS byl navrzˇen (jako na´hrada FAT) pro splneˇnı´ teˇchto cı´lu˚: 1. Zajisˇteˇnı´ integrity souborove´ho syste´mu prˇi selha´nı´ syste´mu. 2. Mozˇnost ochrany citlivy´ch dat prˇed neopra´vneˇny´m prˇ´ıstupem. 3. Mozˇnost softwaroveˇ rˇ´ızene´ datove´ redundance (RAID-1 a RAID-5, viz kap.14.5 na straneˇ 163). Klastry jsou zde od zacˇa´tku cˇ´ıslova´ny 64bitoveˇ, cozˇ posouva´ teoreticke´ kapacity svazku˚ azˇ do rˇa´du˚ miliard GB. Soucˇasne´ 32bitove´ Windows pouzˇ´ıvajı´ jen 32 bitu˚, cˇ´ımzˇ je limit svazku prˇiblizˇneˇ 130TB (cozˇ zrˇejmeˇ take´ jesˇteˇ neˇjakou dobu bude stacˇit). Na rozdı´l od FAT je v NTFS integrova´na podpora prˇ´ıstupovy´ch opra´vneˇnı´, prˇicˇemzˇ na rozdı´l od UFS pouzˇ´ıva´ NTFS daleko flexibilneˇjsˇ´ı syste´m ACL. Syste´m je implicitneˇ zˇurna´lovany´, takzˇe prˇi selha´nı´ syste´mu se na rozdı´l od FAT nemusı´ spousˇteˇt kontrola disku. Na´zvy souboru˚ jsou 255 znaku˚ unicode a v rezˇimu POSIX se rozlisˇujı´ velka´ a mala´ pı´smena (cozˇ standardneˇ ve Windows nenı´ zapnuto). Zajı´mavostı´ take´ je, zˇe cˇas je ukla´da´n vy´hradneˇ v GMT, takzˇe kazˇdorocˇneˇ prˇi prˇechodu na letnı´ cˇas a zpeˇt se jakoby posouva´ cˇas vsˇech souboru˚ na disku o hodinu. (Na disku se nic nemeˇnı´, jen uzˇivatel se prˇesune do jine´ho cˇasove´ho pa´sma. Jinak rˇecˇeno, jde tedy jen o zmeˇnu zobrazenı´ cˇasu na monitoru.) Pru˚vodce studiem Oprava dat podle zˇurna´lu probeˇhne prakticky okamzˇiteˇ, ve srovna´nı´ s minutami cˇi desı´tkami minut nutny´mi na kontrolu FAT32 disku (pouze pro kontrolu, cˇas pro opravu nenı´ zapocˇten). Paradoxneˇ, pra´veˇ Windows 9x, ktere´ je proslule´ neusta´ly´m pada´nı´m, NTFS nepodporuje a tak po kazˇde´m restartu je nutno zdlouhaveˇ kontrolovat FAT32 disky. Naopak Windows NT, ktere´ tak nepada´, pouzˇ´ıva´ implicitneˇ NTFS syste´m, u ktere´ho se kontroly prova´deˇt nemusı´.

Struktura svazku Na zacˇa´tku svazku je tzv. bootovacı´ sektor (partition boot sector, de´lka azˇ 16 sektoru˚). Na´sleduje master file table (MFT), cozˇ je seznam vsˇech souboru˚ na disku. Na´sledujı´ syste´move´ soubory a pak ostatnı´ soubory. Skupina 16 syste´movy´ch souboru˚ (tzv. metasoubory) je klı´cˇova´ pro chod disku, proto jsou odkazy na neˇ ulozˇeny vzˇdy ve stejne´m porˇadı´ na zacˇa´tku MFT. V syste´mu NTFS je vsˇechno soubor, proto neprˇekvapı´, zˇe prvnı´m souborem v MFT je samotna´ MFT. Druhy´m souborem je MFT2 obsahujı´cı´ kopii prvnı´ch 16 souboru˚, ktery´ je ulozˇen vzˇdy uprostrˇed svazku a slouzˇ´ı jako ochrana prˇed fyzicky´m posˇkozenı´m zacˇa´tku disku (svazku). Dalsˇ´ı v rˇadeˇ je log (zˇurna´l), 161

potom hlavicˇka disku, definice atributu˚, korˇenovy´ adresa´rˇ, bitmapa volny´ch klastru˚, boot sektor, uzˇivatelske´ kvo´ty, tabulka akordance pı´smen. Z toho seznamu je trˇeba vyjasnit jen dveˇ polozˇky: Soubor definice atributu˚ obsahuje seznam rozsˇirˇujı´cı´ch atributu˚ podporovany´ch na tomto svazku a uda´va´, podle ktery´ch z nich lze indexovat (rˇadit soubory) a ktere´ z nich se zˇurna´lujı´. Tabulka akordance (anglicky accordance) slouzˇ´ı jako pomu˚cka pro pra´ci s maly´mi a velky´mi pı´smeny. Jme´na souboru˚ jsou v UTF-16 a pomocı´ te´to tabulky lze rychle porovna´vat na´zvy bez ohledu na mala´ a velka´ pı´smena (cozˇ je vy´pocˇetneˇ na´rocˇne´, ale je to vy´chozı´ chova´nı´ vsˇech syste´mu˚ Microsoftu). Pro tabulku MFT je vyhrazeno zacˇa´tecˇnı´ch 12% prostoru svazku – je to prostor, kam dle potrˇeby mu˚zˇe MFT ru˚st (a bez fragmentace). Soubory jsou ukla´da´ny do zbyly´ch 88%. V okamzˇiku, kdy nenı´ dalsˇ´ı mı´sto pro soubory, mu˚zˇe by´t prostor pro MFT zmensˇen, v okamzˇiku opeˇtovne´ho uvolneˇnı´ mı´sta opeˇt zveˇtsˇen. MFT se tı´m mu˚zˇe fragmentovat, cozˇ mu˚zˇe zpomalit chod disku, ale neovlivnˇuje to funkcˇnost. Za´znamy o souborech jsou v MFT, vcˇetneˇ jme´na. (Zde rozdı´l od UFS, kde jme´na jsou zvla´sˇt’ v adresa´rˇ´ıch a zbytek je v inode.) Polozˇky MFT majı´ pevnou velikost a kazˇdy´ soubor mu˚zˇe v prˇ´ıpadeˇ potrˇeby pouzˇ´ıt vı´c polozˇek (trˇeba prˇi velmi dlouhe´m na´zvu a rˇadeˇ atributu˚), nemusı´ prˇitom jı´t o polozˇky prˇ´ımo navazujı´cı´. Samotne´ teˇlo souboru je pak kdekoliv na disku. Pokud je vsˇak soubor maly´, mu˚zˇe by´t jeho teˇlo prˇipsa´no prˇ´ımo do polozˇky souboru v MFT. Dı´ky tomu male´ soubory nezabı´rajı´ prakticky zˇa´dne´ mı´sto na disku (cozˇ je velky´ rozdı´l oproti jiny´m souborovy´m syste´mu˚m). Tento netradicˇnı´ prˇ´ıstup se v praxi velmi osveˇdcˇil. Soubor mu˚zˇe obsahovat vı´ce proudu˚ dat. Ve skutecˇnosti vsˇechny informace o souboru jsou nazy´va´ny atributy a jsou to proudy. A v NTFS je teˇlo souboru je jen jednı´m z mnoha takovy´ch atributu˚, takzˇe potom neprˇekvapı´, zˇe teˇl mu˚zˇe by´t vı´ce. Mozˇnost vı´ceproudovy´ch souboru˚ je v poslednı´ dobeˇ pomeˇrneˇ popula´rnı´m te´matem odborny´ch studiı´, avsˇak rea´lne´ pouzˇitı´ je sta´le pomeˇrneˇ male´. Konkre´tneˇ ve Windows to pouzˇ´ıvajı´ neˇktere´ databa´zove´ servery a take´ u´daje zadane´ na karteˇ „Souhrn“ ve vlastnostech souboru jsou ulozˇeny v alternativnı´m proudu. Pru˚zkumnı´k vsˇak u souboru˚ obecneˇ alternativnı´ proudy nijak viditelneˇ neoznacˇuje, dokonce jejich velikost ani nezahrnuje do de´lky souboru. Programy ve Windows obecneˇ s alternativnı´mi proudy moc nepocˇ´ıtajı´, je proto mozˇne´, zˇe prˇi pra´ci se soubory pomocı´ neˇktery´ch programu˚ dojde ke ztra´teˇ dat (alternativnı´ proud se prosteˇ ztratı´ prˇi amate´rske´m prˇekopı´rova´nı´ souboru atp.). Adresa´rˇe NTFS ukla´da´ adresa´rˇe jako B+ stromy s prvky rˇazeny´mi dle jme´na (max. 255 znaku˚ UTF16). Vy´hodou pak je rychle´ vyhleda´nı´ souboru (rˇa´doveˇ log n oproti n u beˇzˇne´ho linea´rnı´ho seznamu). Prˇida´nı´ nove´ polozˇky do stromu i linea´rnı´ho seznamu je prˇiblizˇneˇ stejneˇ na´rocˇne´. Polozˇky adresa´rˇe obsahujı´ jme´no souboru, jeho atributy a odkaz na soubor do MFT (tj. jeho cˇ´ıslo). Oproti UFS tedy NTFS ukla´da´ atributy do adresa´rˇe, nikoliv k souboru. Jak uzˇ vı´me, korˇenovy´ adresa´rˇ je jednı´m z metasouboru˚ svazku, dalsˇ´ı adresa´rˇe pak mohou by´t obsazˇeny v libovolne´m adresa´rˇi. Zˇurna´lova´nı´ Jednou z nejzna´meˇjsˇ´ıch vlastnostı´ NTFS je zˇurna´lova´nı´ diskovy´ch operacı´. Syste´m NTFS byl prvnı´m souborovy´m syste´mem, ktery´ rozsˇ´ırˇil zˇurna´lova´nı´ mezi „masy“ uzˇivatelu˚. Ve srovna´nı´ s FAT mohou by´t neˇktere´ operacı´ kvu˚li zˇurna´lova´nı´ pomalejsˇ´ı, ale v praxi je naopak dı´ky chytre´mu syste´mu cachova´nı´ rˇada operacı´ na NTFS svazku rychlejsˇ´ı. NTFS zˇurna´luje pouze metadata, cozˇ je de facto vsˇe kromeˇ datovy´ch proudu˚. Prˇi rˇa´dne´m vypnutı´ syste´mu (cˇi odpojenı´ svazku) syste´m na svazek ulozˇ´ı za´znam, zˇe svazek byl bezpecˇneˇ odpojen (unmounted). Prˇi selha´nı´ syste´mu tam tato informace chybı´, syste´m pak podle zˇurna´lu zrusˇ´ı nedokoncˇene´ operace, cˇi dokoncˇ´ı operace, ktere´ jsou v zˇurna´lu, ale nebyly provedeny na disku. 162

Komprese NTFS implicitneˇ podporuje kompresi souboru˚. Pouzˇ´ıva´ prˇitom jednoduche´ kompresnı´ sche´ma s cı´lem, aby komprese neovlivnila chod syste´mu negativneˇ. Standardneˇ nenı´ komprese zapnuta pro vsˇechny soubory; je to prˇ´ıznak (atribut) pouzˇitelny´ na u´rovni jednotlivy´ch souboru˚ cˇi adresa´rˇu˚. Popisem, jak funguje komprese, si za´rovenˇ uka´zˇeme, jak vlastneˇ NTFS ukla´da´ informace o tom, kde je ktery´ soubor na disku. Za´znam o souboru v MFT obsahuje tabulku mapova´nı´ virtua´lnı´ch klastru˚ (VCN – virtual cluster number, tj. cˇ´ıslo klastru v souboru) na logicke´ klastry (LCN – logical cluster number, tj. cˇ´ıslo klastru ve svazku). Tato tabulka ma´ trˇi sloupce: VCN, LCN, de´lka. Prvnı´ rˇa´dek zacˇ´ına´ na VCN = 0, dalsˇ´ı rˇa´dky pak majı´ VCN vysˇsˇ´ı o de´lku prˇedchozı´ho rˇa´dku. Cˇ´ıslo LCN na prˇ´ıslusˇne´m rˇa´dku oznacˇuje pocˇa´tek souvisle´ho bloku klastru˚. V idea´lnı´m prˇ´ıpadeˇ je pak cely´ soubor popsa´n jediny´m rˇa´dkem, v nejhorsˇ´ım prˇ´ıpadeˇ je kazˇdy´ klastr (VCN) na samostatne´m rˇa´dku. NTFS umozˇnˇuje prˇeskakovat pra´zdne´ klastry. V mapovacı´ tabulce mu˚zˇe VCN rˇa´dku by´t veˇtsˇ´ı, nezˇ VCN prˇedchozı´ho rˇa´dku + de´lka. Pak vynechane´ klastry (VCN) jsou pra´zdne´ (plne´ nul). Soubory vyuzˇ´ıvajı´cı´ tuto vlastnost jsou tzv. rˇ´ıdke´ soubory (sparse). Toto chova´nı´ nenı´ standardneˇ zapnuto, kazˇdy´ proces zapisujı´cı´ soubor si mu˚zˇe nastavit, zˇe ma´ by´t rˇ´ıdky´. NTFS kromeˇ rˇ´ıdky´ch souboru˚ vsˇak podporuje take´ skutecˇnou kompresi. Tu mu˚zˇeme zapnout i uzˇivatelsky (z karty vlastnosti souboru) nebo opeˇt programoveˇ. Komprese funguje tak, zˇe prˇi za´pisu se syste´m snazˇ´ı zkompresovat bloky 16 klastru˚ souboru slovnı´kovy´m algoritmem (specificka´ varianta LZ). Pokud vy´sledek zabı´ra´ me´neˇ nezˇ 16 klastru˚, jsou data ulozˇena zkompresovana´. V opacˇne´m prˇ´ıpadeˇ je tento blok 16 klastru˚ ulozˇen bez komprese. Ktere´ cˇa´sti souboru jsou takto zkompresovane´, se jednodusˇe pozna´ opeˇt podle tabulky mapova´nı´ VCN na LCN, tentokra´t podle sloupce de´lka. Pra´ce se souborem je zcela transparentnı´, bez ohledu na to, zda je nebo nenı´ rˇ´ıdky´ cˇi kompresovany´.

14.5

RAID

V prˇedchozı´ch sekcı´ch jsme si tedy prˇedstavili neˇkolik konkre´tnı´ch souborovy´ch syste´mu˚, za´veˇr te´to kapitoly bude veˇnova´n technologii RAID (Redundant Array of Independent Disks) slouzˇ´ıcı´ ke zvy´sˇenı´ spolehlivosti a/nebo rychlosti fyzicky´ch disku˚ (cˇili je to na jine´ u´rovni, nezˇ souborovy´ syste´m). Zatı´mco rozdeˇlenı´ disku na svazky umozˇnˇuje rozdeˇlit jeden fyzicky´ disk na samostatne´ souborove´ syste´my, RAID naopak umozˇnˇuje vytvorˇit jeden souborovy´ syste´m na vı´ce discı´ch dohromady, a prˇitom take´ zvy´sˇit rychlost a spolehlivost. Syste´my RAID mohou by´t implementova´ny jak hardwaroveˇ (rˇadicˇem disku˚), cozˇ je preferova´no, tak softwaroveˇ (emulace operacˇnı´m syste´mem). RAID prˇitom rozezna´va´ neˇkolik samostatny´ch u´rovnı´, z nichzˇ ty nejdu˚lezˇiteˇjsˇ´ı si prˇedstavı´me v na´sledujı´cı´ch sekcı´ch. 14.5.1

RAID 0 (stripping – pruhova´nı´)

´ rovenˇ 0 nerˇesˇ´ı bezpecˇnost, ale pouze rychlost. Data svazku jsou po cˇa´stech (pruhy – stripes) U ukla´da´na na vı´ce disku˚. Tı´m, zˇe se data ukla´dajı´ strˇ´ıdaveˇ, prˇi cˇtenı´ veˇtsˇ´ıho mnozˇstvı´ dat se pracuje se vsˇemi disky najednou, cˇ´ımzˇ se rychlost pro n disku˚ teoreticky zvysˇuje azˇ na nna´sobek rychlosti jednoho disku. Skutecˇna´ rychlost je pak za´visla´ zejme´na na rychlosti rˇadicˇe a pouzˇite´ sbeˇrnice. Spolehlivost pole o N discı´ch vyja´drˇena´ jako MTTF (Mean Time To Failure, cˇesky pru˚meˇrna´ doba do poruchy) cˇi MTBF (Mean Time Between Failures, cˇesky pru˚meˇrna´ doba mezi poruchami) RAID 0 je rovna spolehlivosti jednoho disku deˇlene´ pocˇtem disku˚. M T T Fpole =

M T T Fdisk N

163

14.5.2

RAID 1 (mirroring – zrcadlenı´)

´ rovenˇ 1 rˇesˇ´ı bezpecˇnost. Data svazku jsou zrcadlena na vı´ce disku˚. Vsˇechny disky tedy U obsahujı´ stejna´ data a syste´m mu˚zˇe by´t v provozu, dokud je v provozu alesponˇ jeden disk. Jedna´ se tedy o pomeˇrneˇ nehospoda´rny´ zpu˚sob zajisˇteˇnı´ bezpecˇnosti (porovnejte s dalsˇ´ımi u´rovneˇmi popsany´mi nı´zˇe). RAID 1 prˇi cˇtenı´ mu˚zˇe prˇi cˇtenı´ poskytovat urcˇiteˇ zrychlenı´, podobneˇ jako RAID 0. Je toho dosazˇeno tı´m, zˇe data se cˇtou strˇ´ıdaveˇ z ru˚zny´ch disku˚ – transfer time se tedy na´sobı´ pocˇtem disku˚, zatı´mco seek time zu˚sta´va´ stejny´ jako u disku samostatne´ho. Typicke´ vyuzˇitı´ je na vı´ceu´lohovy´ch syste´mech, kde z kazˇde´ho disku lze cˇ´ıst jiny´ soubor (cˇili ma´me neˇco jako dvouja´drovy´ procesor, ale u disku). Prˇi za´pisu je u RAID 1 nepatrne´ zpomalenı´ oproti jednomu disku. (Pro srovna´nı´: RAID 0 zrychluje transfer i seek time.) Spolehlivost pole o N discı´ch vyjadrˇujeme v za´vislosti na procentua´lnı´ pravdeˇpodobnosti selha´nı´ jednoho disku v urcˇite´m cˇasove´m u´seku. Oznacˇ´ıme-li tuto pravdeˇpodobnost jako pF , pak pravdeˇpodobnost selha´nı´ cele´ho syste´mu je rovna pravdeˇpodobnosti selha´nı´ vsˇech disku˚ v poli beˇhem tohoto cˇasove´ho u´seku. pFpole = (pFdisk )N 14.5.3

RAID 2

´ rovenˇ 2 zajisˇt’uje vysˇsˇ´ı bezpecˇnost pouzˇitı´m Hammingova ko´du. Data jsou deˇlena na jednotlive´ U disky na u´rovni bitu˚ a Hammingu˚v ko´d zajisˇt’uje detekci a korekci dat. Pru˚vodce studiem Hammingu˚v ko´d je ECC algoritmem (error checking & correction. Teorie ko´dova´nı´ je samostatny´m prˇedmeˇtem v magisterske´m studiu informatiky je te´ma nad ra´mec nasˇeho studia operacˇnı´ch syste´mu˚. Pro prˇ´ıklad uved’me, zˇe beˇzˇny´ je naprˇ´ıklad (7,4)–ko´d, kde v kazˇdy´ch 7 bitech jsou ulozˇeny 4 bity dat a 3 bity informace. Kazˇda´ takova´ 7bitova´ jednotka je schopna detekovat 2 bitove´ chyby (tj. libovolne´ azˇ dva bity z te´to skupiny s chybnou cˇi zˇa´dnou hodnotou lze detekovat) a opravit 1 bitovou chybu (tj. jeden bit chybny´ cˇi bez hodnoty ze skupiny lze opravit).

Dodejme, zˇe RAID 2 je jedinou u´rovnı´ standardu RAID, ktera´ se v praxi (alesponˇ prozatı´m) vu˚bec nepouzˇ´ıva´. 14.5.4

RAID 3

´ rovenˇ 3 pouzˇ´ıva´ namı´sto Hammingova opravne´ho ko´du jednoduchou paritnı´ informaci. Pro U N disku˚ v poli vzˇdy N − 1 disku˚ obsahuje data a poslednı´ disk obsahuje paritnı´ informaci. Data jsou na disky deˇlena na u´rovni bajtu˚, cozˇ znemozˇnˇuje prova´deˇt paralelnı´ cˇtenı´, nebot’prˇi cˇtenı´ souboru musı´ by´t rame´nka vsˇech disku˚ na stejne´ pozici. Paritnı´ disk pouzˇ´ıva´ jednoduchy´ algoritmus xorujı´cı´ data na odpovı´dajı´cı´ch pozicı´ch ostatnı´ch disku˚. Syste´m tedy umı´ detekovat 1 bitovou chybu ve skupineˇ. Opravit lze pouze data, u ktery´ch vı´me, ktery´ z disku˚ je vadny´. Cˇili naprˇ´ıklad prˇi u´plne´m selha´nı´ neˇktere´ho disku cˇi fyzicky vadne´m sektoru (cozˇ jsou mimochodem nejcˇasteˇjsˇ´ı v praxi se vyskytujı´cı´ vady) lze ze zbyly´ch disku˚ data dopocˇ´ıtat.

164

14.5.5

RAID 4

´ rovenˇ 4 je obdobou prˇedchozı´, ovsˇem deˇlı´ data na veˇtsˇ´ı bloky a dı´ky tomu (prˇi odpovı´dajı´cı´ U podporˇe rˇadicˇe disku˚) umı´ cˇ´ıst vı´ce dat paralelneˇ (v ra´mci jednoho bloku). Pru˚vodce studiem Paralelnı´ cˇtenı´ je operace, prˇi ktere´m se cˇte vı´ce souboru˚ soucˇasneˇ. Jde tedy o funkci velmi zˇa´danou na serverech, prˇitom bez pouzˇitı´ RAID polı´ je to nemozˇne´, nebot’ disk ma´ jen jedno rame´nko a to mu˚zˇe v dany´ okamzˇik by´t jen na jedine´ pozici. Proto je na obycˇejny´ch jednotlivy´ch discı´ch vzˇdy daleko rychlejsˇ´ı nejprve nacˇ´ıst cely´ jeden soubor, a pak prˇejı´t na cˇtenı´ jine´ho souboru. Prˇi paralelnı´m cˇtenı´ RAID pole se vyuzˇije toho, zˇe kazˇdy´ jeden blok je vzˇdy pouze na jednom disku, takzˇe mezitı´m, co se cˇte, mohou ostatnı´ disky cˇ´ıst jina´ data. (Samozrˇejmeˇ to funguje pouze tehdy, kdyzˇ ma´me sˇteˇstı´ a pra´veˇ pozˇadovana´ data opravdu jsou rozlozˇena na ru˚zne´ disky.)

14.5.6

RAID 5

´ rovenˇ 5 je obdobou prˇedchozı´ s tı´m rozdı´lem, zˇe paritnı´ informace je strˇ´ıdaveˇ ukla´da´na na U jednotlive´ disky. Vy´sledkem je jesˇteˇ vysˇsˇ´ı mozˇna´ rychlost prˇi paralelnı´m cˇtenı´, protozˇe zatı´mco u RAID 4 nenı´ prˇi cˇtenı´ nikdy poslednı´ disk pouzˇit (protozˇe neobsahuje zˇa´dna´ data, ale jen paritnı´ informace), u RAID 5 je rozlozˇenı´ dat rovnomeˇrne´ na vsˇechny disky a vsˇechny se tedy mohou zu´cˇastnit paralelnı´ho cˇtenı´. RAID 5 je v praxi nejpopula´rneˇjsˇ´ı u´rovenˇ, implementova´na beˇzˇneˇ by´va´ hardwaroveˇ i softwaroveˇ. Lze ji pouzˇ´ıt pro minima´lneˇ 3 disky a vy´hodou je pomeˇrneˇ nı´zka´ cenova´ na´rocˇnost. (Pro libovolny´ch N disku˚ na´m stacˇ´ı vzˇdy jen jeden disk navı´c pro paritnı´ informace, takzˇe cˇ´ım vı´ce disku˚ ma´me, tı´m me´neˇ musı´me zaplatit navı´c.) RAID 5 pole je pomale´ prˇi za´pisu kra´tky´ch bloku˚ dat, protozˇe zapisujeme-li me´neˇ nezˇ cely´ pruh, tak musı´me pouzˇ´ıt metodu cˇti–zmeˇnˇ–zapisˇ jak pro samotny´ blok dat, tak pro jemu odpovı´dajı´cı´ blok paritnı´. Naopak rychlost cˇtenı´ je velmi dobra´, te´meˇrˇ porovnatelna´ s RAID 0 (zejme´na pro veˇtsˇ´ı pocˇty disku˚). Prˇi na´hle´m vypnutı´ cˇi selha´nı´ syste´mu v okamzˇiku, kdy na disk jizˇ byla zapsa´na nova´ data, ale jesˇteˇ ne nova´ paritnı´ informace, mu˚zˇe diskove´ pole da´le fungovat, protozˇe prˇi cˇtenı´ jsou pouzˇity jen datove´ bloky. Pokud vsˇak tato vadna´ cˇi chybeˇjı´cı´ paritnı´ informace nenı´ opravena drˇ´ıve, nezˇ dojde k porusˇe disku, pak dojde k nena´vratne´ ztra´teˇ dat. Tyto prˇ´ıpady u hardwarovy´ch rˇesˇenı´ RAID 5 eliminuje pouzˇitı´ bateriı´ zajisˇteˇne´ho rˇadicˇe, ktery´ i prˇi vy´padku proudu nevypne disky drˇ´ıve, nezˇ jsou vsˇechna data konzistentneˇ zapsa´na. U softwarove´ho rˇesˇenı´ RAID 5 toto samozrˇejmeˇ mozˇne´ nenı´. 14.5.7

RAID 6

Sˇesta´ u´rovenˇ jizˇ nepatrˇ´ı do pu˚vodnı´ho standardu, ovsˇem v poslednı´ dobeˇ se sta´le cˇasteˇji pouzˇ´ıva´. Jde o rozsˇ´ırˇenı´ pa´te´ u´rovneˇ o druhy´ paritnı´ blok v kazˇde´m pruhu. Pomocı´ Reed–Solomon ko´du je pak mozˇno opravit libovolnou jednu chybu. Jesˇteˇ zajı´maveˇjsˇ´ı je vsˇak schopnost opravit azˇ dveˇ chyby, pokud zna´me jejich pozice. V praxi tedy je mozˇno spolehliveˇ data opravit i prˇi soucˇasne´m fyzicke´m posˇkozenı´ dvou disku˚. (Opeˇt: Prˇi fyzicke´m posˇkozenı´ cele´ho disku nebo jeho cˇa´sti je toto posˇkozenı´ obvykle prˇesneˇ identifikovatelne´ – prˇesneˇ vı´me, ktery´ disk nefunguje.) RAID 6 je v praxi pouzˇ´ıva´n tam, kde je trˇeba vysˇsˇ´ı bezpecˇnost. Prˇi porusˇe disku se tento okamzˇiteˇ vymeˇnı´ (kvalitnı´ rˇadicˇe RAID umozˇnˇujı´ disky meˇnit za beˇhu pocˇ´ıtacˇe) a rˇadicˇ dopocˇ´ıta´ chybeˇjı´cı´ informace na noveˇ zarˇazeny´ disk. Pokud beˇhem toho dojde k dalsˇ´ı porusˇe (jine´ho 165

disku), opeˇt je mozˇno jej za beˇhu vymeˇnit a syste´m sta´le pokracˇuje v bezchybne´m provozu. Jakmile rˇadicˇ dokoncˇ´ı aktualizaci dat na noveˇ vlozˇeny´ch discı´ch, syste´m je prˇipraven na dalsˇ´ı dveˇ poruchy. (V kazˇde´m okamzˇiku syste´m funguje, pokud alesponˇ N − 2 disku˚ je v provozu. Jsou-li poroucha´ny jen cˇa´sti disku˚, tak cely´ syste´m mu˚zˇe by´t v bezchybne´m provozu teoreticky i prˇi selha´nı´ vsˇech disku˚, dokud jsou u kazˇde´ho pruhu chyby na nejvy´sˇe dvou discı´ch.) Pozna´mka: Podle neˇktery´ch definic lze za RAID 6 povazˇovat kazˇdou implementaci diskove´ho pole, ktera´ „prˇezˇije“ selha´nı´ dvou disku˚. Nemusı´ tedy nutneˇ jı´t jen o pouzˇitı´ Reed–Solomon ko´du. 14.5.8

Softwarova´ emulace

Jak jizˇ bylo rˇecˇeno v u´vodu, neˇktere´ operacˇnı´ syste´my podporujı´ RAID technologii softwaroveˇ, tedy bez potrˇeby jake´hokoliv specia´lnı´ho hardwaru. Naprˇ. Windows NT jizˇ od da´vny´ch verzı´ obsahuje softwarovou implementaci u´rovnı´ 0, 1 a 5 a tyto jsou nejcˇasteˇji podporova´ny i jiny´mi syste´my. Softwarova´ emulace RAID je v syste´mu implementova´na jako dalsˇ´ı vrstva abstrakce napojena´ na ovladacˇ disku, nebo prˇ´ımo jeho soucˇa´st. Kromeˇ jiste´ho zatı´zˇenı´ procesoru, ktery´ se musı´ o organizaci (ko´dova´nı´) dat na discı´ch pochopitelneˇ starat, to s sebou nese i neˇktera´ dalsˇ´ı specifika: Prˇedevsˇ´ım syste´m musı´ by´t nejprve nabootova´n, takzˇe obvykle potrˇebuje mı´t syste´movy´ svazek na ne–RAID disku. Na druhu stranu tyto syste´my obvykle umozˇnˇujı´ vytva´rˇet RAID svazky z cˇa´stı´ disku˚, tedy z logicky´ch cˇa´stı´ (partition) a ne nutneˇ z cely´ch disku˚. U softwarovy´ch rˇesˇenı´ RAID polı´ nemu˚zˇe by´t zcela zarucˇena bezpecˇnost, nebot’ prˇi selha´nı´ syste´mu beˇhem za´pisu nelze cˇisteˇ softwaroveˇ zarucˇit, zˇe vsˇechny souvisejı´cı´ sektory byly zapsa´ny. U hardwarovy´ch rˇadicˇu˚ RAID toto mu˚zˇe by´t rˇesˇeno naprˇ´ıklad za´lozˇnı´ bateriı´, ktera´ zajistı´, zˇe disky se vypnou azˇ po dosazˇenı´ konzistentnı´ho stavu. Shrnutı´ V te´to kapitole jsme si prˇedstavili neˇktere´ konkre´tnı´ souborove´ syste´my, ktere´ se nejcˇasteˇji pouzˇ´ıvajı´ v praxi. Byl to jmenoviteˇ FAT syste´m pouzˇ´ıvany´ pro vy´meˇnna´ me´dia, UFS pouzˇ´ıvany´ v ru˚zny´ch verzı´ Unixu a NTFS pouzˇ´ıvany´ ve Windows NT. V za´veˇru kapitoly jsme si jesˇteˇ prˇedstavili RAID pole, cozˇ je du˚lezˇity´ doplneˇk souborovy´ch syste´mu˚ pouzˇ´ıvany´ zejme´na na serverech a obecneˇ vsˇude tam, kde je vyzˇadova´na vysˇsˇ´ı bezpecˇnost. Pojmy k zapamatova´nı´ • • • • • • • • • •

FAT (file allocation table) dlouhy´ na´zev (LFN – long file name) UFS (Unix file system) inode NTFS (NT file system) MFT (master file table) akordance pı´smen RAID (redundant array of independent drives/disks) MTTF (mean time to failure) MTBF (mean time between failures)

Kontrolnı´ ota´zky 1. FAT tabulku lze do cache nacˇ´ıtat po jednotlivy´ch klastrech v okamzˇiku jejich prvnı´ potrˇeby, nebo jako celek na zacˇa´tku pra´ce s diskem. Vysveˇtlete vy´hody a nevy´hody teˇchto dvou rˇesˇenı´.

166

2. Co se deˇje s cˇasovy´mi za´znamy u souboru˚ v okamzˇiku prˇechodu na letnı´ cˇas nebo zpeˇt? Uved’te pro jednotlive´ souborove´ syste´my. 3. Pokuste se definovat alternativnı´ zpu˚sob implementace RAID 6 (tj. jiny´ nezˇ pouzˇitı´ Reed– Solomon ko´du). 4. Vysveˇtlete, co je to paralelnı´ cˇtenı´ a dı´ky cˇemu jej lze v neˇktery´ch syste´mech RAID prova´deˇt. 5. Popisˇte algoritmus a prˇ´ınos komprese v syste´mu NTFS. 6. Popisˇte, jaky´m zpu˚sobem jsou do syste´mu FAT zakomponova´ny dlouhe´ na´zvy. Procˇ pra´veˇ u FAT je problematika dlouhy´ch na´zvu tak du˚lezˇita´? 7. Syste´m FAT je obvykle popisova´n jako sˇpatny´. Uved’te jeho nevy´hody cˇi proble´my a vysveˇtlete, procˇ na vymeˇnitelny´ch me´diı´ch je sta´le nejvı´ce pouzˇ´ıvany´. 8. Jmenujte alesponˇ trˇi nevy´hody softwarovy´ch rˇesˇenı´ RAID.

´ koly k textu U 1. Zajı´ma´-li va´s, jak prˇesneˇ fungujı´ opravne´ ko´dy zmı´neˇne´ v te´to kapitole, prˇecˇteˇte si o nich dalsˇ´ı informace na internetu (naprˇ. ve Wikipedii [Wiki]).

167

A

Jak vznikajı´ programy

Studijnı´ cı´le: V te´to kapitole se podı´va´me na postup, prˇi ktere´m se ze zdrojovy´ch textu˚ programu stane skutecˇny´ program a jak se pak tento v pocˇ´ıtacˇi spustı´. Jedna´ se o doplnˇkove´ te´ma, proto je zarˇazeno mezi prˇ´ılohami. Klı´cˇova´ slova: prˇeklad, spusˇteˇnı´, knihovna, linker, komponenta Potrˇebny´ cˇas: 40 minut.

A.1

Prˇeklad

Vysˇsˇ´ı jazyky, jako C/C++ cˇi Pascal, jsou do spustitelne´ho tvaru prˇekla´da´ny pomocı´ dvoufa´zove´ho prˇekladu. V prvnı´ fa´zi se program prˇelozˇ´ı do Assembleru, ve druhe´ fa´zi se pak Assembler prˇevede do strojove´ho ko´du. Tento proces ma´ na ru˚zny´ch pocˇ´ıtacˇ´ıch a v ru˚zny´ch operacˇnı´ch syste´mech vsˇelijake´ nuance, podı´va´me se tedy pouze na jeden vzorovy´ prˇ´ıklad.

Vysˇsˇ´ı jazyky se obvykle prˇekla´dajı´ prˇes Assembler.

Za prˇeklad vysˇsˇ´ıho jazyka do Assembleru je vzˇdy odpoveˇdny´ prˇekladacˇ onoho vysˇsˇ´ıho jazyka. Neˇktere´ prˇekladacˇe prˇekla´dajı´ svu˚j ko´d nejprve do jine´ho vysˇsˇ´ıho jazyka (naprˇ. do C/C++), ze ktere´ho se teprve do Assembleru. Prˇeklad Assembleru probı´ha´ tak, zˇe se jde rˇa´dek po rˇa´dku a analyzuje se jme´no instrukce a typy operandu˚. Podle toho je urcˇen bina´rnı´ ko´d te´to instrukce. Je-li v operandech pouzˇito neˇjake´ symbolicke´ jme´no (na´zev adresy, promeˇnne´ apod.), toto se nahradı´ jeho skutecˇnou hodnotou. Nenı´-li v okamzˇiku pouzˇitı´ symbolicke´ho jme´na jesˇteˇ zna´ma jeho hodnota, probeˇhne pak jesˇteˇ dalsˇ´ı pru˚chod. Veˇtsˇinu programu˚ lze prˇelozˇit v nejvy´sˇe dvou azˇ trˇech pru˚chodech. Prˇelozˇeny´ vy´sledek, cˇili ko´d z jednoho zdrojove´ho souboru, se ulozˇ´ı do jednoho vy´stupnı´ho souboru. Jedna´ se o tzv. „modul“, obvykle s prˇ´ıponou .obj, ve ktere´m je jizˇ vy´sledny´ strojovy´ ko´d, ovsˇem jsou v neˇm take´ tabulky vsˇech pouzˇity´ch symbolicky´ch jmen a jejich vy´skytu˚ v programu. Modul se take´ mu˚zˇe odkazovat na externı´ jme´na, tj. nezna´me´ prvky, ktere´ se nacha´zejı´ v jiny´ch zdrojovy´ch souborech. (Naprˇ. funkci pro psanı´ na obrazovku printf v nasˇem souboru nema´me, prˇesto ji mu˚zˇeme zavolat. Prˇekladacˇ do modulu nasˇeho programu ulozˇ´ı informaci, zˇe tento modul potrˇebuje funkci printf. Odkud tu funkci vzı´t, jizˇ v modulu uvedeno nenı´.) Podobneˇ je v modulu uveden seznam verˇejny´ch jmen, tj. jmen nabı´zeny´ch pro pouzˇitı´ v jiny´ch modulech. Neˇktere´ jazyky (naprˇ. C/C++) nabı´zejı´ standardneˇ vsˇechna sva´ jme´na jako verˇejna´.

Modul je vy´sledek prˇekladu jednoho souboru.

Jmenne´ tabulky obsahujı´ pro kazˇde´ jme´no jeho adresu uvnitrˇ modulu, je-li tam jme´no definova´no, a seznam adres, kde se toto jme´no v modulu pouzˇ´ıva´, je-li tam jme´no pouzˇ´ıva´no. Pru˚vodce studiem Jme´na funkcı´ vysˇsˇ´ıch jazyku˚ jsou obvykle dekorova´na, aby nedosˇlo ke kolizi s neˇjaky´m syste´movy´m jme´nem. Naprˇ. eax je jme´no registru a funkce se nemu˚zˇe jmenovat stejneˇ. Jazyk C proto vsˇechna jme´na dekoruje prˇida´nı´m znaku na zacˇa´tek na´zvu. Jazyk C++ pak navı´c umozˇnˇuje definovat stejneˇ pojmenovane´ funkce lisˇ´ıcı´ se jen v pocˇtu cˇi typech parametru˚. Soucˇa´stı´ dekorovane´ho jme´na je v C++ tedy i zako´dovana´ informace o pocˇtu parametru˚ a jejich typech. Takto dekorovana´ jme´na jsou bohuzˇel nesrozumitelna´ a lisˇ´ı se v jednotlivy´ch prˇekladacˇ´ıch (podle vy´robce). Proto v Assembleru spolupracujeme jen s jazykem C.

A.2

Linkova´nı´

Spustitelny´ program vytvorˇ´ıme procesem zvany´m linkova´nı´ ; program prova´deˇjı´cı´ linkova´nı´ 168

Prˇi linkova´nı´ se moduly spojı´ dohromady.

nazy´va´me linker. Jeho u´kolem ja´ da´t dohromady vsˇechny uvedene´ moduly, jak nasˇe vlastnı´, tak moduly vestaveˇny´ch knihoven vysˇsˇ´ıho jazyka. Prˇi linkova´nı´ se projdou vsˇechny jmenne´ tabulky a odkazy na nezna´ma´ jme´na se vyrˇesˇ´ı a napojı´ naprˇ´ıcˇ moduly. Na rozdı´l od prˇekladu, linkova´nı´ je jizˇ pomeˇrneˇ jednoduchy´ proces pra´ce s mnoha poli. Kromeˇ vyrˇesˇenı´ jmen linkova´nı´ take´ provede spojenı´ ko´du vsˇech modulu˚ do jednoho bloku. K tomu pouzˇije take´ tabulky pouzˇity´ch adres kazˇde´ho modulu, protozˇe aby moduly mohly by´t spojeny, musı´ se jednotlive´ moduly posunout v pameˇti (aby nebyly vsˇechny na stejne´m mı´steˇ). Tomuto procesu se rˇ´ıka´ relokace. Toto vyzˇaduje zmeˇnit neˇktere´ instrukcˇnı´ ko´dy, konkre´tneˇ pra´veˇ adresnı´ operandy (cozˇ je zcela pochopitelne´). Vy´sledkem linkova´nı´ je soubor s prˇ´ıponou .com nebo .exe. Prvnı´ jmenovany´ je stary´ forma´t, ktery´ je prˇezˇitkem ze syste´mu CP/M (prˇedchu˚dce MS-DOSu). Tento typ souboru˚ obsahuje jen cˇisty´ ko´d bez jake´koliv hlavicˇky. Nahraje se vzˇdy na stejne´ mı´sto v pameˇti a spustı´ se od zacˇa´tku. Druha´ jmenovana´ prˇ´ıpona je beˇzˇna´ naprˇ. ve Windows. Jine´ operacˇnı´ syste´my ale pouzˇ´ıvajı´ jine´ forma´ty a i samotny´ „ekza´cˇ“ mu˚zˇe ve skutecˇnosti mı´t neˇkolik ru˚zny´ch vnitrˇnı´ch forma´tu˚.

A.3

Knihovny a spousˇteˇnı´ programu˚

Knihovny jsou programy cˇi cˇa´sti programu˚, ktere´ nabı´zejı´ svou funkcionalitu jiny´m knihovna´m cˇi programu˚m. Z hlediska prˇekladu a spousˇteˇnı´ ko´du rozlisˇujeme knihovny prˇedevsˇ´ım na staticke´ a dynamicke´. Staticky linkovana´ knihovna je ve forma´tu modulu. Prˇed jejı´m pouzˇitı´m se musı´ slinkovat dohromady s nasˇ´ım programem a vznikne tak jeden celek. Vy´hodou takove´ho postupu je rychlejsˇ´ı beˇh, nevy´hodou pak pouzˇitı´ vı´ce pameˇti, kdyzˇ spousˇtı´me programy se stejny´mi knihovnami (kazˇdy´ ma´ svou kopii). Dynamicky´ linkovana´ knihovna je ve forma´tu spustitelne´ho programu. Ve Windows ma´ prˇ´ıponu .dll. Forma´t takove´ho souboru je totozˇny´ se souborem .exe. V souboru vsˇak chybı´ beˇzˇny´ startovacı´ bod (dll nelze spustit) a navı´c je zde seznam zverˇejneˇny´ch jmen. Ten je obdobou jmen zverˇejneˇny´ch v modulu a vytva´rˇ´ı ho linker. Vy´hodou dynamicky´ch knihoven je, zˇe umozˇnˇujı´ sdı´lenı´ ko´du. Nevy´hodou je slozˇiteˇjsˇ´ı postup prˇi spusˇteˇnı´: Prˇedevsˇ´ım musı´me opeˇt prove´st relokaci (posunutı´ adres, jako v linkeru), protozˇe nejde umı´stit vı´ce knihoven na stejne´ mı´sto pameˇti Dynamicky linkovane´ knihovny je mozˇno k programu prˇipojovat (bindovat) staticky nebo dynamicky. Nejcˇasteˇji se pouzˇ´ıva´ staticke´ prˇipojenı´ dynamicky linkovane´ knihovny. Tento poneˇkud tajemny´ na´zev znacˇ´ı, zˇe prˇipojenı´ knihovny k programu a vyrˇesˇenı´ a prˇipojenı´ vsˇech jmen se provede ihned prˇi spusˇteˇnı´ programu. Nelze-li neˇktere´ jme´no vyrˇesˇit, program ohla´sı´ chybu a nespustı´ se. Alternativou je dynamicke´ prˇipojenı´ dynamicky linkovane´ knihovny, kdy se jednotliva´ jme´na rˇesˇ´ı azˇ v okamzˇiku jejich pouzˇitı´. Tento zpu˚sob je mozˇno provozovat jen s pomocı´ podpu˚rne´ho ko´du, protozˇe namı´sto obycˇejne´ho zavola´nı´ neˇjake´ funkce v dll knihovneˇ je trˇeba rucˇneˇ osˇetrˇit jejı´ nacˇtenı´ a prˇipojenı´ dane´ho jme´na. Tento zpu˚sob je tedy pomalejsˇ´ı prˇi beˇhu, ale je flexibilneˇjsˇ´ı – umozˇnˇuje pouzˇ´ıvat i knihovny nezna´me´ prˇi tvorbeˇ programu, meˇnit knihovny za beˇhu programu, atp. Prˇi spusˇteˇnı´ programu˚ tedy syste´m zacˇne od exe souboru. Umı´stı´ jej do pameˇti a pomocı´ dll knihoven se snazˇ´ı vyrˇesˇit vsˇechna externı´ jme´na. Kazˇdou knihovnu nacˇte a aktivuje stejneˇ jako samotny´ exe soubor – knihovna ma´ svu˚j startovacı´ bod, kde mu˚zˇe mı´t kra´tky´ program, ktery´m se inicializuje. Knihovna se samozrˇejmeˇ mu˚zˇe odkazovat na dalsˇ´ı knihovny. Kazˇdy´ soubor prˇitom prˇi nacˇ´ıta´nı´ do pameˇti mu˚zˇe by´t umı´steˇn na jine´ mı´sto, nezˇ kam byl pu˚vodneˇ urcˇen. V tom prˇ´ıpadeˇ se prova´dı´ relokace adres (stejneˇ jako prˇi linkova´nı´). Pouzˇ´ıva´-li neˇjaky´ program veˇtsˇ´ı mnozˇstvı´ svy´ch vlastnı´ch knihoven, je vhodne´ je prˇelozˇit tak, aby kazˇda´ pouzˇ´ıvala jinou vy´chozı´ adresu. Tı´m se umozˇnı´ spousˇteˇt program bez relokace adres a spusˇteˇnı´ je tak rychlejsˇ´ı. 169

Dynamicky linkovane´ knihovny jsou sdı´leny mezi vı´ce programy.

A.4

Komponenty

Pouzˇ´ıva´nı´ klasicky´ch dll knihoven ma´ rˇadu nevy´hod. Proklamovanou vy´hodou dll totizˇ meˇlo by´t sdı´lenı´ ko´du mezi ru˚zny´mi programy. V praxi se to vsˇak prˇemeˇnilo v nocˇnı´ mu˚ru (v literaturˇe obvykle najdeme vy´stizˇny´ pojem „DLL Hell“ – DLL peklo), nebot’rˇada programu˚ drze umı´st’uje DLL soubory do adresa´rˇe Windows, cˇasto i prˇepı´sˇ´ı novou verzi starsˇ´ı verzı´ te´zˇe knihovny apod. Tento proble´m rˇesˇ´ı komponenty. Existuje prˇitom neˇkolik komponentnı´ch technologiı´ ru˚zny´ch vy´robcu˚ (autoru˚). Microsoft pouzˇ´ıva´ ve Windows syste´m COM (Component Object Model), alternativou je naprˇ. syste´m CORBA (Common Object Request Broker Architecture). Za´kladnı´m prˇ´ınosem komponentnı´ch syste´mu˚ je podpora objektoveˇ orientovane´ho prˇ´ıstupu – knihovny jsou trˇ´ıdy cˇi sady trˇ´ıd. Pro vyrˇesˇenı´ DLL Hell je prˇida´na rˇada informacı´, prˇedevsˇ´ım cˇ´ıslo verze, a je odstraneˇno odkazova´nı´ jme´nem souboru – identifikace nynı´ probı´ha´ jme´nem knihovny a jme´nem trˇ´ıdy. V syste´mu mu˚zˇe tedy soucˇasneˇ koexistovat vı´ce verzı´ stejne´ knihovny. Prˇ´ıkladem syste´mu, ktery´ COM bohateˇ pouzˇ´ıva´, je DirectX – v pocˇ´ıtacˇi ma´te obvykle mnoho verzı´ te´to rozsa´hle´ knihovny. Neˇktere´ komponentnı´ technologie (naprˇ. DCOM – Distributed COM) umozˇnˇujı´ te´meˇrˇ transparentneˇ take´ rozmı´stit komponenty na vı´ce pocˇ´ıtacˇu˚ – klient v krajnı´m prˇ´ıpadeˇ ani nemusı´ veˇdeˇt, zˇe pouzˇ´ıva´ funkce komponenty, ktera´ je fyzicky umı´steˇna na vzda´lene´m pocˇ´ıtacˇi. Tato funkcionalita ale samozrˇejmeˇ vyzˇaduje pomeˇrneˇ rozsa´hly´ ko´d v pozadı´ (v operacˇnı´m syste´mu). Zvla´sˇtnı´ kapitolou jsou platformy Java a .NET. Jsou to modernı´ objektoveˇ orientovane´ syste´my, ktere´ te´meˇrˇ odstinˇujı´ program od operacˇnı´ho syste´mu. Samy tak vlastneˇ vystupujı´ v roli operacˇnı´ho syste´mu. Jednı´m ze za´kladnı´ch kamenu˚ teˇchto syste´mu˚ jsou pra´veˇ komponenty. Microsoft svu˚j .NET samozrˇejmeˇ realizoval jakozˇto jakousi dalsˇ´ı inkarnaci COM, kde jsou le´pe vyrˇesˇeny neˇktere´ proble´my, ktere´ v COM byly. Syste´m vsˇak je zpeˇtneˇ kompatibilnı´ a spolupra´ce mezi COM a .NET programy a komponentami je velmi snadna´. Oproti tomu Java spolecˇnosti Sun je platformoveˇ neza´visla´ a svu˚j syste´m komponent umozˇnˇuje pouzˇ´ıvat na ru˚zny´ch operacˇnı´ch syste´mech. Cela´ problematika komponent je bohuzˇel jizˇ nad ra´mec tohoto kurzu. Shrnutı´ Tato kapitola cˇtena´rˇe strucˇneˇ sezna´mila s problematikou prˇekladu programu˚, tj. vysveˇtlila „jak ze zdrojovy´ch textu˚ vznikajı´ programy“.

170

Komponenty jsou modernı´ na´hradou knihoven.

B

Ochrana a zabezpecˇenı´

Studijnı´ cı´le: V te´to sekci se kra´tce zmı´nı´me o ochraneˇ a zabezpecˇenı´, cozˇ je te´ma spadajı´cı´ do studia operacˇnı´ch syste´mu˚, ale je jizˇ nad ra´mec tohoto nasˇeho u´vodnı´ho kurzu. Klı´cˇova´ slova: ochrana, zabezpecˇenı´ Potrˇebny´ cˇas: 10 minut. Te´ma ochrany a zabezpecˇenı´ je u operacˇnı´ch syste´mu˚ pomeˇrneˇ nove´, v soucˇasnosti je zde vsˇak jizˇ zcela „zdoma´cneˇle´“. O ochraneˇ hovorˇ´ıme u syste´mu˚ jako takovy´ch (ochrana pameˇti mezi procesy, ACL – ochrana prˇ´ıstupu k souboru˚m). O zabezpecˇenı´ pak hovorˇ´ıme prˇi pra´ci s lidmi (RSA sˇifrova´nı´, digita´lnı´ podpis, firewall, login). Toto na´zvoslovı´ se neˇkdy plete, protozˇe nenı´ zrovna intuitivnı´, nejde vsˇak o za´sadnı´ proble´m. O ochraneˇ byla rˇecˇ jizˇ v kapitola´ch ty´kajı´cı´ch spra´vy pameˇti a disku. Dalsˇ´ı velkou dome´nou je sı´t’ove´ cˇi obecneˇ jake´koliv verˇejne´ prostrˇedı´. Pra´veˇ rozvoj internetu take´ tuto problematiku dostal do hleda´cˇku za´jmu studia operacˇnı´ch syste´mu˚, za nejveˇtsˇ´ı proble´m minulosti mu˚zˇeme oznacˇit neko´dovane´ posı´la´nı´ hesel po sı´ti. Naprˇ. beˇzˇneˇ pouzˇ´ıvany´ sı´t’ovy´ protokol FTP je mozˇno velmi snadno odposloucha´vat na loka´lnı´ sı´ti a zı´skat tak hesla uzˇivatelu˚. Moderneˇjsˇ´ı rˇesˇenı´ problematiky vzda´lene´ho prˇihlasˇova´nı´ (cˇi obecneˇji a prˇesneˇji autentifikace/oveˇrˇenı´) uzˇivatelu˚ rˇesˇ´ı naprˇ. protokol Kerberos, ktery´ umozˇnˇuje vza´jemne´ zabezpecˇene´ oveˇrˇenı´ obou stran (serveru i klienta) i na sı´ti, ktera´ sama zabezpecˇena´ nenı´. Kerberos pouzˇ´ıvajı´ Windows 2000 a noveˇjsˇ´ı, Mac OS X i dalsˇ´ı modernı´ syste´my. Toto te´ma je take´ zna´mo z poloviny 90.let, kdy Microsoft upravil tehdejsˇ´ı verze Windows NT do podoby, ktera´ vyhovuje zvy´sˇeny´m bezpecˇnostnı´m standardu˚m americke´ arma´dy. Standard ministerstva obrany USA TCSEC (Trusted Computer System Evaluation Criteria) definuje neˇkolik u´rovnı´ bezpecˇnosti operacˇnı´ch syste´mu˚ od A (nejvysˇsˇ´ı bezpecˇnost) azˇ po D (zˇa´dna´ bezpecˇnost). Windows NT zı´skalo certifikaci C2, ktera´ vyzˇaduje mimo jine´ spra´vu prˇ´ıstupovy´ch opra´vneˇnı´ na u´rovni objektu˚ syste´mu (implementova´no jako syste´m ACL), nulova´nı´ prˇideˇlene´ pameˇti, mozˇnost odejmout prˇ´ıstupova´ opra´vneˇnı´ (implementova´no jako DACL) nebo povinny´ audit uda´lostı´ ty´kajı´cı´ch se zabezpecˇenı´. Acˇkoliv rˇadu z teˇchto funkcı´ beˇzˇnı´ uzˇivatele´ nepotrˇebovali (a zejme´na ne v tehdejsˇ´ı dobeˇ, prˇed masovy´m rozsˇ´ırˇenı´m internetu), Windows NT dı´ky tomu zı´skalo na poli bezpecˇnosti pomeˇrneˇ velky´ na´skok prˇed konkurencˇnı´mi syste´my, ktere´ tuto problematiku obvykle nerˇesˇily vu˚bec. (Unixove´ syste´my naprˇ´ıklad beˇzˇneˇ posı´laly nezasˇifrovana´ hesla po sı´ti tak, zˇe bylo velmi snadne´ je odchytit trˇetı´m pocˇ´ıtacˇem v sı´ti. Pru˚vodce studiem Jak zna´mo, kazˇda´ mince ma´ dveˇ strany. I prˇes dobry´ na´vrh syste´mu Windows NT jeho skutecˇnou bezpecˇnost limitujı´ chyby v syste´mu. Ty jsou samozrˇejmeˇ ve vsˇech operacˇnı´ch syste´mech, ovsˇem v teˇch vı´ce pouzˇ´ıvany´ch jsou vı´ce „na ra´neˇ“.

Pojmy k zapamatova´nı´ • • • •

ochrana zabezpecˇenı´ Kerberos TCSEC (Trusted Computer System Evaluation Criteria)

171

Kerberos oveˇrˇuje uzˇivatele v sı´ti.

C

Seznam obra´zku˚ 1

Sche´ma pocˇ´ıtacˇe – von Neumannu˚v model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

2

Uka´zka ko´du v Assembleru x86 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

3

Data na za´sobnı´ku v okamzˇiku vola´nı´ podprogramu . . . . . . . . . . . . . . . . . . . . . . . . . . .

29

4

Pocˇ´ıtacˇ Sinclair ZX81 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

5

Softwarova´ struktura pocˇ´ıtacˇe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

34

6

Aplikace Spra´vce u´loh (Task Manager) syste´mu Windows XP. . . . . . . . . . . . . . . . . . . . . .

41

7

Stavy procesu. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

42

8

Stavy procesu v Unixu. [Bac86, BoCe05] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

50

9

Stavy procesu v NT. [SoRu05] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

52

10

Mapova´nı´ priorit Windows API do cˇ´ısel priorit NT ja´dra. [SoRu05] . . . . . . . . . . . . . . . . . .

56

11

Alokacˇnı´ graf prostrˇedku˚ (vlevo) a jemu odpovı´dajı´cı´ graf cˇeka´nı´ (vpravo). [SGG05] . . . . . . . . .

77

12

Alokacˇnı´ graf prostrˇedku˚ s vyznacˇenı´m pla´novany´ch alokacı´. [SGG05] . . . . . . . . . . . . . . . . .

80

13

Alokacˇnı´ graf prostrˇedku˚ s cyklem – nebezpecˇny´ stav. [SGG05] . . . . . . . . . . . . . . . . . . . .

81

14

Za´kladnı´ model stra´nkova´nı´. [SGG05] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

88

15

Prostrˇedky pouzˇite´ grafickou kartou . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

96

16

Thrashing – s rostoucı´m pocˇtem procesu˚ klesa´ vytı´zˇenı´ procesoru. [SGG05] . . . . . . . . . . . . . . 104

17

Stavy stra´nek. [SoRu05] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

18

Prˇeklad logicke´ adresy na linea´rnı´. [IA32-3A] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

19

Prˇeklad linea´rnı´ adresy na fyzickou (PFN = cˇ´ıslo ra´mce, PDE/PTE = za´znam v tabulce). [SoRu05] . . 118

20

Kanonicke´ adresy. [Wiki] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

21

Titulek „Rozsˇ´ırˇenı´ fyzicke´ adresy“ ukazuje, zˇe syste´m beˇzˇ´ı v rezˇimu PAE. . . . . . . . . . . . . . . . 127

22

Prˇ´ıme´ a neprˇ´ıme´ odkazy na bloky v inode. [McMa06] . . . . . . . . . . . . . . . . . . . . . . . . . . 160

172

Reference [Bac86]

Maurice J. Bach. Design of the Unix Operating System. Prentice Hall, 1986. 486 pp., ISBN 0-13-201799-7. cˇesky´ prˇeklad: Principy operacˇnı´ho syste´mu Unix. Softwarove´ Aplikace a Syste´my, Praha, 1993. 514 pp. ISBN 80-901507-0-5.

[BoCe05] Daniel P. Bovet, Marco Cesati. Understanding the Linux Kernel, 3.vyda´nı´. O’Reilly, 2005. 942 pp., ISBN 0-596-00565-2. [Bra94]

Michal Brandejs. Mikroprocesory Intel Pentium a spol. Grada, 1994. ISBN 80-7169-041-4.

[Her91]

Maurice Herlihy. Wait–Free Synchronization. In: ACM Trans. Program. Lang. Syst. 13(1):124–149.

[Hof90]

Micha Hofri. Proof of a Mutual Exclusion Algorithm. In: Operating Systems Review, January 1990.

[IA32-1] IA-32 Intel Architecture Software Developer’s Manual. Volume 1: Basic Architecture. Intel, 2006. 476 pp. (Existuje ve verzı´ch pro jednotlive´ procesory Intel, ke stazˇenı´ na www.intel.com.) [IA32-3A] IA-32 Intel Architecture Software Developer’s Manual. Volume 3A: System Programming Guide, Part 1. Intel, 2006. 630 pp. (Existuje ve verzı´ch pro jednotlive´ procesory Intel, ke stazˇenı´ na www.intel.com.) [Kep08a] Alesˇ Keprt. Assembler. Univerzita Palacke´ho, 2008. Studijnı´ text pro distancˇnı´ vzdeˇla´va´nı´, v prˇ´ıpraveˇ, dostupny´ studentu˚m na adrese http://www.keprt.cz/vyuka/. [Kep08b] Alesˇ Keprt. Syste´move´ programova´nı´ v jazyce C#. Univerzita Palacke´ho, 2008. Studijnı´ text pro distancˇnı´ vzdeˇla´va´nı´, v prˇ´ıpraveˇ, dostupny´ studentu˚m na adrese http://www.keprt.cz/vyuka/. [Knu98]

Donald E. Knuth. Art of Computer Programming, volume 3: Sorting and Searching. Addison-Wesley Professional, 2.vyda´nı´, 1998. ISBN 0-201-89685-0.

[Lov03]

Robert Love. Introducing the 2.6 Kernel. In Linux Journal. http://www.linuxjournal.com/article/6530

[McMa06] Richard McDougall, Jim Mauro. Solaris Internals: Solaris 10 and OpenSolaris Kernel Architecture, 2.vyda´nı´. Prentice Hall, 2006. 1072 pp., ISBN 0-13-148209-2. http://www.informit.com/content/images/0131482092/samplechapter/mcdougall ch15.pdf [MSDN] Microsoft Developer Network. http://www.microsoft.com/msdn/ [Pat71]

Suhas Patil. Limitations and capabilities of Dijkstra’s Semaphore Primitives for Coordination Among Processes. technical report, MIT, 1971.

[Pet81]

Gary L. Peterson. Myths About the Mutual Exclusion Problem. In: Information Processing Letters. 12(3):115–116, 1981.

[SGG05] Abraham Silberschatz, Peter B. Galvin, Greg Gagne. Operating Systems Concepts, 7. vyda´nı´. John Wiley & Sons, 2005. 944 pp., ISBN 0-471-69466-5. [SoRu05] David A. Solomon, Mark E. Russinovich. Microsoft Windows Internals, 4.vyda´nı´. Microsoft Press, 2004. 976 pp., ISBN 0-7356-1917-4. [Sta05]

William Stallings. Operating Systems, 5.vyda´nı´. Prentice Hall, 2005. ISBN 0-13-147954-7.

[Tan01]

Andrew Tanenbaum. Modern Operating Systems, 2.vyda´nı´. Prentice Hall, 2001. ISBN 0-13-031358-0.

[Vecˇ04]

Arnosˇt Vecˇerka. Za´kladnı´ algoritmy. Text distancˇnı´ho vzdeˇla´va´nı´, Katedra informatky, UP Olomouc, 2004.

[Wiki]

Wikipedia, the free encyclopedia. http://en.wikipedia.org/

173