Vorlesung BT - Dr. Ulrich Margull
Werbung
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt ““
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Skript zur Vorlesung
Betriebssysteme
für das 4. Semester Wirtschaftsinformatik
an der FH Regensburg
gehalten vom Dr. Ulrich Margull
im Sommersemester 2004
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 1 of 170
- 1 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt ““
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Inhaltsverzeichnis
1Einführung................................................................................................................13
1.1Betriebsarten.......................................................................................................13
1.1.1Batch/Dialog(Interaktiv)/Echtzeit......................................................................13
1.1.2Ein-Nutzer/Mehr-Nutzer..................................................................................14
1.1.3Nebenläufigkeit:.............................................................................................14
1.2Anforderungsprofile.............................................................................................14
1.3Historische Entwicklung.......................................................................................14
2Übersicht..................................................................................................................16
2.1Wiederholung: Computer Hardware ......................................................................16
2.1.1Funktionsweise einer "von Neumann" - Maschine.............................................16
2.1.2Prozessor......................................................................................................17
2.1.3Zentralspeicher (Memory)...............................................................................17
2.1.4I/O Geräte.....................................................................................................18
2.1.5Datenbusse...................................................................................................18
2.1.6Multi-Prozessor-Architekturen.........................................................................19
2.2Aufgaben, Dienste und Komponenten von Betriebssystemen....................................20
2.2.1Prozeß- und Prozessorverwaltung....................................................................20
2.2.2Programmverwaltung.....................................................................................21
2.2.3Zentralspeicherverwaltung..............................................................................22
2.2.4Ein-/Ausgabe-Steuerung.................................................................................23
2.2.5Externe Datenverwaltung................................................................................23
2.2.5.1 Physikalische Speichermedien..................................................................23
2.2.6Betriebsmittelverwaltung (Resource Management).............................................24
2.2.7Zugriffsschutz (Security)................................................................................25
2.2.8Kommando-Interpreter (Shell)..........................................................................25
2.3Betriebssystem Strukturen....................................................................................25
2.3.1Einfache Strukturen.......................................................................................25
2.3.1.1Beispiel MS-DOS ....................................................................................25
2.3.1.2Beispiel: Unix .........................................................................................25
2.3.2Microkernel...................................................................................................26
2.3.2.1Beispiel Windows XP ..............................................................................27
2.3.3Konzept virtueller Maschinen..........................................................................28
2.3.3.1Übersicht VM..........................................................................................28
2.3.3.2OS/370 .................................................................................................28
2.3.3.3Java Virtual Machine (JVM)......................................................................29
2.3.3.4Weitere Virtuelle Maschinen......................................................................29
3Prozesse ..................................................................................................................30
3.1Was ist ein Prozess?............................................................................................30
3.2Prozessverwaltung...............................................................................................31
3.2.1Prozesskontrollblöcke.....................................................................................31
3.2.2Verwaltung der PCBs ....................................................................................32
3.2.3Prozesserzeugung & -vernichtung....................................................................32
3.2.3.1Statisch vs. Dynamisch............................................................................32
3.2.3.2Prozesserzeugung....................................................................................33
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 2 of 170
- 2 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt ““
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
3.2.3.3Prozessvernichtung..................................................................................33
3.2.3.4Beispiel Unix: fork()..................................................................................33
3.2.3.5Beispiel Unix: exec().................................................................................34
3.2.3.6Beispiel Win32: CreateProcess()................................................................35
3.3Kontextwechsel...................................................................................................36
3.3.1Funktionsaufruf.............................................................................................37
3.3.2Interrupt.......................................................................................................37
3.3.3Prozesswechsel.............................................................................................37
3.3.4Unterbrechungsarten......................................................................................37
3.4Interprozess-Kommunikation.................................................................................38
3.4.1Message Passing...........................................................................................38
3.4.1.1Direkte Kommunikation............................................................................39
3.4.1.2Indirekte Kommunikation..........................................................................39
3.4.1.3Synchronisierung.....................................................................................39
3.4.1.4Pufferung................................................................................................40
3.4.1.5Beispiel: Mach.........................................................................................40
3.4.2Pipes............................................................................................................40
3.4.3Sockets........................................................................................................41
3.4.4Client-Server: RPC.........................................................................................42
3.4.5Verteilte Objekte............................................................................................43
3.4.5.1Komponenten-Transaktions-Server (CTS)...................................................44
4Threads....................................................................................................................45
4.1Allgemein............................................................................................................45
4.1.1Anwendungsbeispiel 1: MS Word....................................................................46
4.1.2Anwendungsbeispiel 2: Web-Server.................................................................46
4.2Threaderzeugung.................................................................................................46
4.2.1Linux: clone() ...............................................................................................47
4.2.2Win32: CreateThread()...................................................................................47
4.2.3POSIX: pthread-create()..................................................................................48
4.3User- und Kernel-Threads.....................................................................................49
4.3.1User-Level Threads........................................................................................49
4.3.2Kernel-Level Threads......................................................................................50
4.3.3Many-to-one Modell (User-Level-Threads).........................................................50
4.3.4One-to-one Modell (Kernel-Level-Threads).........................................................51
4.3.5Many-to-many Modell (gemischt).....................................................................51
4.4Beispiele.............................................................................................................52
4.4.1Pthreads: User-Level Bibliothek.......................................................................52
4.4.2Win2000 Threads..........................................................................................52
4.4.3Solaris 2 Threads...........................................................................................52
4.4.4Linux-Threads................................................................................................52
4.4.5Java Threads................................................................................................53
5CPU Scheduling.........................................................................................................54
5.1Grundlagen.........................................................................................................54
5.1.1CPU Burst / I/O Burst.....................................................................................54
5.1.2Scheduler......................................................................................................55
5.1.3Dispatcher....................................................................................................56
5.2Ziele des Scheduling............................................................................................56
5.2.1Allgemeine Kriterien.......................................................................................56
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 3 of 170
- 3 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt ““
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
5.2.2Großrechner (Batch Systeme).........................................................................56
5.2.3Interaktive Systeme.......................................................................................57
5.2.4Echtzeit-Systeme...........................................................................................57
5.3Algorithmen........................................................................................................57
5.3.1First Come First Served Scheduling (FCFS).......................................................57
5.3.2Shortest Job First Scheduling (SJF).................................................................59
5.3.3Round-Robin Scheduling (RR)..........................................................................60
5.3.4Prioritäten-Scheduling....................................................................................61
5.3.5Multilevel Queue Scheduling...........................................................................62
5.3.6Realtime Scheduling: Rate-Monotonic Scheduling (RMS)....................................63
5.3.6.1Hard-Realtime..........................................................................................63
5.3.6.2Soft-Realtime..........................................................................................63
5.3.6.3Rate-Monotonic Scheduling......................................................................63
5.3.6.4Problem: Prioritäteninversion.....................................................................65
5.3.7Evaluierung der Algorithmen...........................................................................65
5.4Thread Scheduling...............................................................................................65
5.5Beispiele.............................................................................................................66
5.5.1Solaris 2.......................................................................................................66
5.5.2Windows 2000.............................................................................................67
5.5.3Linux (Kernel < 2.6)......................................................................................67
6Prozesssynchronisierung.............................................................................................68
6.1Kritische Bereiche (Critical Section)........................................................................70
6.2Lösungen............................................................................................................71
6.2.1Abschalten der Interrupts ..............................................................................71
6.2.2Zwei-Prozess Lösungen..................................................................................72
6.2.2.1Software-Lösung Versuch 1: Sperr-Variable (lock variable)...........................72
6.2.2.2Lösungsversuch 2: Abwechselnder Zugang (strict alternation)......................72
6.2.2.3Peterson's Lösung...................................................................................73
6.2.3Test And Set Lock (TSL)................................................................................75
6.2.4Sleep And Wakeup........................................................................................75
6.2.5Semaphoren..................................................................................................76
6.2.5.1Implementierung......................................................................................77
6.2.5.2Beispiel: Consumer-Producer mit Semaphore..............................................77
6.2.6Monitors.......................................................................................................78
6.2.7Weitere Verfahren zur Prozesssynchronisierung.................................................80
6.3Beispiele.............................................................................................................80
6.3.1Windows 2000.............................................................................................80
6.3.1.1Interlocked-Funktionen.............................................................................80
6.3.1.2Critical Section........................................................................................80
6.3.1.3Dispatcher Objects: Events, Mutex, Semaphore..........................................81
6.3.2Unix.............................................................................................................81
6.3.2.1Semaphore..............................................................................................81
6.3.3Java.............................................................................................................81
6.4Klassische Probleme der Synchronisierung..............................................................82
6.4.1Bounded-Buffer (Producer-Consumer-Problem)..................................................82
6.4.2Readers-Writers-Problem.................................................................................82
6.4.3Fünf speisende Philosophen............................................................................82
6.5Prioritäteninversion..............................................................................................87
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 4 of 170
- 4 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt ““
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
6.6Deadlocks...........................................................................................................89
6.6.1Wiederholung: Begrifflichkeiten.......................................................................89
6.6.2Bedingungen für ein Deadlock.........................................................................89
6.6.3Ignorieren des Problems (Vogel-Strauss-Strategie).............................................90
6.6.4Entdeckung und Behandlung...........................................................................90
6.6.5Vermeidung von Deadlocks.............................................................................90
6.6.6Verhinderung von Deadlocks...........................................................................91
6.6.7Beispiel (nach [1])..........................................................................................93
7Zentralspeicherverwaltung..........................................................................................95
7.1Grundlagen.........................................................................................................95
7.1.1Bindung der Speicheradressen.........................................................................95
7.1.2Logischer und physikalischer Speicher..............................................................96
7.1.3Dynamisches Laden / Overlay Technik.............................................................97
7.1.4Dynamisches Linken und gemeinsame Bibiliotheken (Shared Libraries).................97
7.1.5Echtzeitsysteme............................................................................................98
7.2Monoprogrammierung........................................................................................100
7.3Multiprogrammierung-Betrieb mit festen Partitionen...............................................101
7.4Swapping..........................................................................................................101
7.4.1Speicherverteilung.......................................................................................102
7.4.2Speicherschutz............................................................................................103
7.4.3Problem: Fragmentierung und Verschnitt........................................................103
7.4.4Verwaltung von freien Speicherbereichen.......................................................103
7.4.4.1Bitmaps: Bitketten für Speicher...............................................................103
7.4.4.2Speicherverwaltung über lineare Listen (Freikette).....................................104
7.4.5Algorithmen zur Auswahl von Speicher aus der Freikette.................................105
7.4.5.1First Fit.................................................................................................105
7.4.5.2Best Fit.................................................................................................105
7.4.5.3Worst Fit: ............................................................................................105
7.4.5.4Problem: Externer Verschnitt...................................................................105
7.4.5.5Buddy-System nach Knuth......................................................................106
7.5Virtueller Speicher: Paging..................................................................................109
7.5.1Übersicht Paging..........................................................................................109
7.5.2Umsetzung mittels Seitentabellen..................................................................109
7.5.3Hierarchische Seitentabellen..........................................................................112
7.5.4Einträge in einer Seitentabelle........................................................................114
7.5.5TLBs – Translation Lookaside Buffers............................................................114
7.5.6Invertierte Seitentabellen..............................................................................116
7.5.7Speicherschutz............................................................................................117
7.5.8Gemeinsame Seiten......................................................................................118
7.5.9Seitentauschstrategien.................................................................................118
7.5.10Arbeitsmenge (Working Set).......................................................................128
7.5.11Praxisbeispiele...........................................................................................130
7.5.12Anforderungen an den Prozessor.................................................................134
7.5.13Nebeneffekte des Paging............................................................................134
7.6Segmentierung..................................................................................................134
8I/O Systeme............................................................................................................136
8.1Allgemein..........................................................................................................136
8.1.1I/O Geräte...................................................................................................136
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 5 of 170
- 5 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt ““
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
8.1.2I/O Gerätecontroller......................................................................................136
8.1.3Adressierungsarten von I/O Geräten...............................................................137
8.1.4Polling........................................................................................................139
8.1.5Interrupts....................................................................................................139
8.1.6Direkter Speicherzugriff (Direct Memory Access, DMA)...................................140
8.2I/O Software Schichten......................................................................................141
8.2.1Interrupt Handler..........................................................................................141
8.2.2Gerätetreiber...............................................................................................142
8.2.3Geräte-unabhängige Software.......................................................................143
8.2.3.1Einheitliches Interface für alle Treiber.......................................................143
8.2.3.2Datenpufferung.....................................................................................143
8.2.3.3Fehlermeldungen....................................................................................144
8.2.3.4Belegung und Freigabe von Geräten (Resource-Handling)...........................144
8.2.3.5Geräte-unabhängige Block-Größe.............................................................144
8.2.4User-Space I/O Software..............................................................................144
8.3Plattenlaufwerke................................................................................................144
8.3.1Hardware....................................................................................................145
8.3.2Zugriffsstategien..........................................................................................145
8.3.2.1FCFS Scheduling...................................................................................146
8.3.2.2SSTF Scheduling (auch SST)...................................................................146
8.3.2.3Aufzug-Algorithmus (SCAN)...................................................................146
8.3.3Fehlerbehandlung.........................................................................................147
8.3.4Stabilität.....................................................................................................147
8.4Serielle Schnittstelle...........................................................................................148
8.4.1Grundlagen der Asynchronen Seriellen Kommunikation (RS232).......................148
8.4.2Controller-Register.......................................................................................148
8.4.3Ansteuerung auf Interrupt-Ebene...................................................................148
8.4.4Ansteuerung auf User-Ebene (Win32)............................................................149
8.5Weitere Geräte..................................................................................................149
9Dateisysteme..........................................................................................................150
9.1Dateien.............................................................................................................150
9.1.1Dateinamen.................................................................................................150
9.1.2Dateistruktur und -zugriff..............................................................................151
9.1.3Datei-Attribute.............................................................................................151
9.1.4Dateioperationen..........................................................................................151
9.1.5Memory-Mapped Files..................................................................................152
9.2Verzeichnisse....................................................................................................153
9.2.1Verzeichnisse mit einer Ebene.......................................................................153
9.2.2Verzeichnisse mit zwei Ebenen......................................................................153
9.2.3 Hierarchische Verzeichnisstrukturen..............................................................153
9.2.4 Dateipfade.................................................................................................153
9.2.5 Verzeichnis-Operationen .............................................................................154
9.2.6Links..........................................................................................................154
9.2.7Mount-Punkte..............................................................................................155
9.3Implementierung von Dateisystemen....................................................................156
9.3.1Partitionierung von Festplatten......................................................................156
9.3.2Implementierung von Dateien........................................................................156
9.3.2.1Kontinuierliche Belegung.........................................................................156
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 6 of 170
- 6 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt ““
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
9.3.2.2Verlinkte Liste.......................................................................................157
9.3.2.3FAT......................................................................................................158
9.3.2.4Indizierte Belegung (I-Nodes)...................................................................159
9.3.3Implementierung von Verzeichnissen..............................................................160
9.3.3.1Lineare Liste..........................................................................................160
9.3.3.2Hash-Tabelle.........................................................................................161
9.3.4Freispeicherverwaltung.................................................................................161
9.3.5Implementierung von Links (Verknüpfungen)...................................................162
9.3.5.1Harter Link............................................................................................162
9.3.5.2Verknüpfung (Symbolischer Link)............................................................163
9.3.6Nicht-Funktionale Aspekte: Performance, Zuverlässigkeit, Effizienz...................163
9.4Protokollierende Dateisysteme (Journaling File Systems)........................................164
9.5Netzwerk-Dateisysteme: NFS..............................................................................165
9.6Beispiele...........................................................................................................165
9.6.1Win32-Schnittstelle (API)..............................................................................165
9.6.2MS-DOS Dateisystem: FAT...........................................................................168
9.6.3NTFS..........................................................................................................169
10Danksagung..........................................................................................................170
Abbildungsverzeichnis
Abbildung
Abbildung
Abbildung
Abbildung
Abbildung
Abbildung
Abbildung
Abbildung
Abbildung
Abbildung
Abbildung
Abbildung
Abbildung
Abbildung
Abbildung
Abbildung
Abbildung
Abbildung
Abbildung
Abbildung
Abbildung
Abbildung
Abbildung
Abbildung
Abbildung
Abbildung
1: Alter IBM Rechner (Folie)...........................................................................14
2: Übersicht Rechneraufbau..........................................................................16
3: Übersicht "von Neumann" Maschine..........................................................16
4: Programmausführung................................................................................17
5: Pipeline, Superskalar Pipeline.....................................................................17
6: Zugriffspyramide......................................................................................17
7: Pentium Busstruktur (aus [1])....................................................................18
8: Schema Rechner......................................................................................19
9: Mehr-Prozessor-Systeme: Shared Memory, Interconnected, Distributed..........19
10: Prozess-Zustände, Prozessorzuteilung.......................................................20
11: Interprozess-Kommunikation (a) Message Passing, (b) Shared Memory........21
12: Übersicht Programmverwaltung...............................................................21
13: Übersicht virtuelle Speicherverwaltung.....................................................22
14: Schema E/A Steuerung...........................................................................23
15: Deadlock an der Kreuzung.......................................................................24
16: DOS Struktur.........................................................................................25
17: Unix Struktur (siehe Folie).......................................................................26
18: Windows Übersicht................................................................................27
19: Aufbau BT.............................................................................................28
20: Virtual Machine (VM) OS/370..................................................................29
21: Java VM................................................................................................29
22: Prozess-Zustände...................................................................................30
23: Organisation von PCBs............................................................................32
24: Prozesshierarchie....................................................................................34
25: Ablauf fork() - exec()..............................................................................35
26: Funktionsaufruf, Interrupt, Prozesswechsel...............................................36
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 7 of 170
- 7 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt ““
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Abbildung 27: Schema Message Passing........................................................................39
Abbildung 28: Message Passing....................................................................................39
Abbildung 29: Schema Pipes........................................................................................40
Abbildung 30: Schema Sockets.....................................................................................41
Abbildung 31: Client-Server mit Sockets........................................................................42
Abbildung 32: Schema RPC Aufruf................................................................................43
Abbildung 33: Thread vs. Prozess (nach [2])..................................................................45
Abbildung 34: Threaderzeugung (einfache Darstellung ohne Kernel)..................................46
Abbildung 35: Thread-Erzeugung (Darstellung mit Kernel)................................................47
Abbildung 36: Wechsel von User-Thread zu Kernel-Thread...............................................49
Abbildung 37: many-to-one Thread Modell (nach [2]).....................................................50
Abbildung 38: One-to-one Thread Modell (nach [2])........................................................51
Abbildung 39: Many-to-many Thread Modell (nach [2])...................................................51
Abbildung 40: Solaris 2 Threading Modell (nach [2]).......................................................52
Abbildung 41: CPU intensiv (a) vs. I/O intensiv (b) (nach [2])..........................................54
Abbildung 42: Burst Dauer (Histogramm) (nach [2]).......................................................54
Abbildung 43: 3-Level Scheduler (nach [2])....................................................................55
Abbildung 44: Prozess-Zustände...................................................................................55
Abbildung 45: FCFS Warteschlange...............................................................................57
Abbildung 46: FCFS Beispiel.........................................................................................58
Abbildung 47: Konvoi Effekt bei FCFS...........................................................................59
Abbildung 48: Round-Robin Beispiel..............................................................................60
Abbildung 49: Multilevel Feedback Queue (nach [2]).......................................................62
Abbildung 50: RMS Aktivierungsschema (Beispiel)..........................................................64
Abbildung 51: Overview Thread Scheduling (nach [1])....................................................66
Abbildung 52: Schema kritischer Bereich........................................................................71
Abbildung 53: Ein Philosophen-Esstisch.........................................................................83
Abbildung 54: Prioritätsinversion (P2 beendet vor P3).....................................................87
Abbildung 55: Prioritäten-Vererbung..............................................................................88
Abbildung 56: Prioritäten-Vererbung (P1 erhält dieselbe Priorität wie P3)...........................88
Abbildung 57: Priority-Ceiling(P1 erhält kurzzeitig eine hohe Priorität)................................88
Abbildung 58: Betriebsmittelbelegungsgraphen
(A, B, C, D: Prozesse, R, S, T, U: Resourcen).................................................................89
Abbildung 59: Deadlock-Trajektorie (nach [1])................................................................92
Abbildung 60: Deadlock!..............................................................................................93
Abbildung 61: Kein Deadlock!.......................................................................................94
Abbildung 62: Übersicht Adressenbindung (nach [2])......................................................95
Abbildung 63: MMU Architektur....................................................................................96
Abbildung 64: Adressumsetzung mittels Relocation Register............................................97
Abbildung 65: Adressumsetzung mittels Relocation Register............................................97
Abbildung 66: Adress- und Datenbus für ein Echtzeitsystem............................................99
Abbildung 67: Speicherlayout Echtzeitsystem...............................................................100
Abbildung 68: Speicherverwaltung bei Monoprogrammierung (nach [1])..........................100
Abbildung 69: Speicherverwaltung mit festen Partitionen (nach [1])................................101
Abbildung 70: Ablauf beim Swapping..........................................................................102
Abbildung 71: Speicherverteilung im Prozess (nach [1]).................................................102
Abbildung 72: Adressverschiebung mit Begrenzung.......................................................103
Abbildung 73: Verschmelzung von freien Bereichen (nachdem Prozess X terminiert).........105
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 8 of 170
- 8 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt ““
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Abbildung 74: Speicherfragmentierung.........................................................................106
Abbildung 75: Speicheraufteilung nach dem Buddy-System...........................................107
Abbildung 76: Buddy-System (Beispiel)........................................................................108
Abbildung 77: Übersicht Paging .................................................................................109
Abbildung 78: Übersicht Paging MMU........................................................................110
Abbildung 79: Beispiel Seitentabelle............................................................................111
Abbildung 80: Zwei-stufige Seitentabelle.....................................................................113
Abbildung 81: Typischer Eintrage in einer Seitentabelle.................................................114
Abbildung 82: Schema Translation Lookaside Buffer.....................................................115
Abbildung 83: Seitentabelle a) normal b) invertiert c) mit Hash-Tabelle (nach [1]).............117
Abbildung 84: Gemeinsamer Speicher durch Paging......................................................118
Abbildung 85: Verschiedene Segmente eines Programmes.............................................134
Abbildung 86: Segemente..........................................................................................134
Abbildung 87: Übersicht Rechneraufbau.......................................................................136
Abbildung 88: Adressierungsarten für I/O Geräte (nach [1]): a) getrennte Befehle; b) MemoryMapped I/O; c) gemischt;...........................................................................................137
Abbildung 89: Busarchitektur für Memory-Mapped-I/O...................................................137
Abbildung 90: I/O Adressen eines PCs (nicht vollständig)...............................................138
Abbildung 91: Vektor-Interrupttabelle des PCs..............................................................139
Abbildung 92: Schema DMA.......................................................................................140
Abbildung 93: (a) Ohne Pufferung (b) User-Space Pufferung (c) Einfach-Pufferung (d)
Doppelte Pufferung (nach [1]).....................................................................................143
Abbildung 94: Festplatten-Geometrie und Bezeichnungen..............................................144
Abbildung 95: Festplattenzugriffe FCFS (links) und SSTF (rechts), nach [2].....................145
Abbildung 96: Festplattenzugriffe SCAN (links) und C-SCAN (rechts), nach [2]................146
Abbildung 97: Fehlerhafte Sektoren.............................................................................146
Abbildung 98: RS232-Übertragung (7-Bit)....................................................................147
Abbildung 99: Virtueller Speicher und Memory-Mapped Files..........................................152
Abbildung 100: Links.................................................................................................154
Abbildung 101: Mount-Punkt im Verzeichnis................................................................154
Abbildung 102: Partitionen.........................................................................................155
Abbildung 103: Kontinuierliche Belegung.....................................................................156
Abbildung 104: Verlinkte Liste....................................................................................157
Abbildung 105: FAT (aus [1]).....................................................................................158
Abbildung 106: I-Node (direkt sowie einfache, zweifache und dreifache Indirektion) (aus [1]). .
159
Abbildung 107: Verzeichnis (lineare Liste)....................................................................160
Abbildung 108: Liste freier Blöcke...............................................................................162
Abbildung 109: Implementierung eines harten Link........................................................163
Abbildung 110: NFS Systemarchitektur........................................................................165
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 9 of 170
- 9 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Abschnitt ““
<Mit Absicht leer gelassen>
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 10 of 170
- 10 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt ““
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
A Die Vorlesung
Dozent: Dr. Ulrich Margull
Organisatorisches
• Montags 15:15 – 16:45 im Raum 213
• Freitags 10:00 – 11:30 im Raum 612
Übungen
• Organisiert Herr Opel
Leistungsnachweis
• Klausur am Ende des Semesters (120 Minuten)
• 1/3 Übungsstoff, 2/3 Vorlesungsstoff
• Erlaubte Materialen: Skript, Übungen + Lösungen
Empfohlene Literatur
[1] „Modern Operating Systems“, 2nd Edition, Andrew Tanenbaum, Prentice Hall,
2001 (deutsch: „Moderne Betriebssysteme“ im Verlag Pearson Studium)
[2] „Operating System Concepts“, 6th Edition, A. Silberschatz et.al, Wiley, 2003
[3] Betriebssysteme . Funktion und Design von William Stallings
Hinweis zu diesem Skript
Dieses Skript ist kein Lehrbuch, sondern sind meine Notizen zu der Vorlesung und
geben im wesentlichen den Tafelanschrieb wieder. Im Zweifelsfall gilt das in der
Vorlesung gesagte; zudem verweise ich auf die empfohlene Literatur.
Für Fehlerhinweise und Korrekturvorschläge bin ich sehr dankbar (wiewohl alle Fehler
absichtlich & zur Übung der Studenten eingefügt wurden!)
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 11 of 170
- 11 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt ““
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
B Glossar (englisch-deutsch)
Dieser Abschnitt listet die einige Begriffe auf, die in der Vorlesung auf deutsch und englisch
verwendet werden. Das Glossar soll ein besseres Verständnis der verwendeten Begriffe und
ihrer Übersetzungen ermöglichen.
Deutsch
Befehlszähler (BZ)
Betriebsmittel
Betriebssystem
Gegenseitiger
Ausschluss
Kritischer Bereich
Kurzzeit Scheduler
Prozessleitblock (PLB)
Seite
Seitenrahmen
Seitentabelle
Verdrängung
Verklemmung
Englisch
Program Counter (PC)
Resource
Operating System
Mutual Exclusion
Critical Section
Short-Term Scheduler
Process control block
(PCB)
Page
Page frame
Page tabelle
Preemption
Deadlock
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Bemerkung
Abk. BT bzw. OS
Auch: Kritischer Abschnitt (KA)
Auch 'task control block (TCB)'
Page 12 of 170
- 12 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 1 “Einführung“
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
1 Einführung
Was ist ein Betriebssystem?
DIN 44300: „Die Programme eines digitalen Rechensystems, die zusammen mit den
Eigenschaften der Rechneranlage die Basis der möglichen Betriebsarten der digitalen
Rechensysteme bilden und insbesondere die Abwicklung steuern und überwachen.“
Was bedeutet das?
Wozu brauchen Sie ein BS? Brauchen Sie überhaupt eins?
• Antwort: ja und nein, je nachdem
• Einfache Systeme mit Spezialhardware können auch direkt programmiert werden
• Ansteuerung der gesamten Hardware „per Hand“
• Interruptprogrammierung zur Hardware-Ansteuerung / gleichzeitiger Verarbeitung
• nur bei Spezialhardware oder sehr einfachen Systemen
• Beispiel: ASCENTRONIC Aufzugsteuerung
• Beispiel: Funkschlüssel, Transponder
• Beispiel: SIM-Karte
• Beispiel: PC: selber schreiben
• I/O: Festplattenansteuerung über IDE
• Graphik-Treiber,
• Keyboard- und Maustreiber
• und und und
• möglich ist es: siehe Linux!
• Dann doch nur einmal die Arbeit machen und ein General Pupose OS schreiben, z.B. Linux
1.1 Betriebsarten
1.1.1 Batch/Dialog(Interaktiv)/Echtzeit
•
Batch
Einzelne Jobs laufen nach- oder nebeneinander
• Keine direkte Interaktion mit dem Benutzer
• Job-Control-Language nötig
• Ziel: maximaler Durchsatz
sekundär: zeitliches Antwortverhalten
• Dialog/Interaktiv
• Direkte Interaktion des Benutzers mit dem System
• Ziel: Schnelle Antwortzeit
sekundär: Auslastung/Durchsatz
• Echtzeitsystem (Embedded System)
• Aktuatoren und Sensoren (keine Benutzer im klassischen Sinne)
• Echtzeit: definierte Antwortzeiten: „Korrektes Funktionieren des Systems hängt
nicht nur von der Antwort ab, sondern auch davon, ob diese rechtzeitig vorliegt.“
• Ziel: rechtzeitige Antwort
sekundär: Durchsatz, CPU-Auslastung
•
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 13 of 170
- 13 -
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Abschnitt 1 “Einführung“
1.1.2 Ein-Nutzer/Mehr-Nutzer
Einfache Systeme / Embedded Systeme: nur 1 Benutzer, keine Benutzer- / Rechteverwaltung
Workstation, Großrechner: mehrere User gleichzeitig, Benutzer- / Rechteverwaltung
1.1.3 Nebenläufigkeit:
•
•
•
Ein-Prozess (wie MSDOS)
Mehr-Prozess (nacheinander)
Time-Sharing (quasi-parallel)
1.2 Anforderungsprofile
Rechnerart
Großrechner: Interaktiv, Stapelverarbeitung
Workstation:
PCs:
Prozessrechner, Embedded Systems:
Hand-Held:
Betriebssystem
MVS
UNIX, Linux, Windows-NT…
Consumer-Windows, Mac
Embedded-Linuxe, WindowsCE, OSEK, Betriebssystem –
Baukästen
Palm-OS, Windows-CE,
Symbian
1.3 Historische Entwicklung
a) 0te Generation 1945 - 1955:- Elektronenröhren <= 20.000- Programmierung:
Zusammenstecken von Schalttafeln- Magnetische Trommelspeicher
b) 1te Generation 1955 - 1960:- FORTRAN 1955 Peter Naur (BNF)- Trennung zwischen
Entwickler, Fertigung, Operating, Programmierung, Benutzer Þ Beginn der kommerziellen
DV- Typisches Betriebssystem: FMS (FORTRAN Monitoring System)
Job:- Aufgabe des Betriebssystem:
® Daten von Band lesen
® Programme (z.B. Compiler) von Systemband lesen
® Ausgabe auf Band
- Problem: Schlechte CPU – Nutzung
Jobkarte für
Abrechnung
Aufruf
Compiler
Fortran
Programm
EOF
LOAD oder
RUN
Daten
STOP
Abbildung 1: Alter IBM Rechner (Folie)
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 14 of 170
- 14 -
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Abschnitt 1 “Einführung“
c) 2te Generation 1960 – 1980:
• Geschwindigkeit bei hohen Kosten um Faktor 10 gesteigert.
Þ Hardware muss besser genutzt werden
® Multiprogramming
® Festplatten mit autonomen Controllern (E/A - Kanäle)
® Virtuelle Speichertechnik
® Timesharing für Terminals
® Umfangreiche JCC (Job Control Language)
• Mit dem MULTICS (MULTiplexed Information and Computing System) wollte General
Electric ganz Bosten mit Rechnerleistung versorgen. Das Projekt scheiterte zwar, jedoch
brachte die Entwicklung viele neue Aspekte und Erfahrungen, u. a. Abgrenzung der
einzelnen Tasks, Schutzkonzepte (à 286, 386, 486 und Pentium), virtuelle
Speichertechnik.
• ca. 1970: UNIX (Uniplexed Information and Computing Service). Entwicklung mit C
d) 3te Generation 1990 bis heute: PCs
Mikroprozessor- Mooresches Gesetz: Alle 18 Monate Verdopplung der Schaltkreise pro
Fläche- hohe Rechnerleistung an jedem Ort verfügbar- Internet, Netzwerke- Sichere
Betriebssysteme, Fehlertoleranz
Bis 1955
bis 1960
bis 1965
bis 1980
ab 1980
Transistor
IC´s
VLSI
ab ´78 : 8086 ,
68000
SW
FORTRAN
LISP
COBOL
Algol 60
Algol 68
1970 : Pascal, C
Datenbanken
Benutzeroberflächen,
File/Print/Webserver, Browser
BS
JCL , FMS
komplexe
JCL
OS /360
Multiprogramming
BS1000, BS2000
UNIX
DOS , OS/2,
Windows,
Network
Betriebssysteme,
Linux
HW
Elektronenröhren
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 15 of 170
- 15 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Abschnitt 2 “Übersicht“
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
2 Übersicht
2.1 Wiederholung: Computer Hardware
Einfacher PC (Hardware Schema):
Abbildung 2: Übersicht Rechneraufbau
2.1.1 Funktionsweise einer "von Neumann" - Maschine
Speicher:
Prozessor:
Befehle und Daten
Grundzyklus zur Befehlsbearbeitung
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 16 of 170
- 16 -
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Abschnitt 2 “Übersicht“
Unterbrechung ?
ja
Umschalten:
Befehlszeiger, Status
Befehl (Befehlszeiger) aus Speicher
Befehlszeiger erhöhen
Befehl 'holen'
Operanden aus Speicher/Register/Status/BZ
Operanden verknüpfen
Befehl 'verarbeiten'
Ergebnis(se) nach Speicher / Register / Status / BZ
Abbildung 4: Programmausführung
Programmausführung:
·
Prozeß aus Befehlsbearbeitungen
·
Prozeß benötigt Betriebsmittel: Prozessor, Speicher, E/A-Geräte
2.1.2 Prozessor
Moderner Prozessor: a) Pipeline b) superscalar pipeline
Abbildung 5: Pipeline, Superskalar Pipeline
2.1.3 Zentralspeicher (Memory)
Abbildung 6: Zugriffspyramide
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 17 of 170
- 17 -
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Abschnitt 2 “Übersicht“
In embedded-Systemen: EEPROM als permanenter Speicher
Neueste Entwicklung: MRAM magnetic RAM (persistent)
2.1.4 I/O Geräte
Steuerung von I/O Geräten. Eine Übersicht über typische I/O-Geräte gibt die folgende Tabelle:
Tabelle 1: Übersicht I/O Geräte
Gerät
Datenrate
Gerät
Datenrate
Tastatur
10 Bytes/s
Fast Ethernet
12,5 MB/s
Maus
100 B/s
ISA Bus
16,7 MB/s
56K Modem
7 kB/s
EIDE (ATA-2) Festplatte
16.7 MB/s
ISDN mit Kanalbündelung
16 kB/s
FireWire (IEEE 1394)
50 MB/s
Laserdrucker
100 kB/s
XGA Monitor
60 MB/s
Ethernet
1,25 MB/s
SCSI Ultra 2 Festplatte
80 MB/s
USB
1.5 MB/s
Ultrium Tape
320 MB/s
IDE Festplatte
5 MB/s
PCI Bus
528 MB/s
40x CDROM
6 MB/s
Sun Giagplane XP Backbone
20 GB/s
2.1.5 Datenbusse
Abbildung 7: Pentium Busstruktur (aus [1])
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 18 of 170
- 18 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 2 “Übersicht“
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
2.1.6 Multi-Prozessor-Architekturen
Mehr-Prozessor-Rechner:
CPU
Shared
Memory
I/O
controller
device
CPU
device
CPU
device
Abbildung 8: Schema Rechner
Verschiedene Arten von Mehrprozessorsystemen:
a) Shared Memory: Alle Prozessoren greifen auf denselben Speicher zu (als Pentium
Hyperthreading auch im PC Standard); max. 16-32 CPUs
• Windows Server 2003:
• Enterprise Edition: 8 CPUs
• Datacenter: 128 CPUs
• Solaris 9:
• One million simultaneous processes on a single system
• Up to 128 CPUs in a single system and 848 CPUs in a clustered
environment
• Support for up to 576 GB of memory
• More than four billion network connections
• Up to 252 TB file systems with Sun StorEdge QFS
• IPv6, enabling a 128-bit IP address space
• A 64-bit Java virtual machine
b) Message-Passing: Jeder Prozessor hat eigenen Speicher, Austausch über eine
Kommunikationsmatrix (Crossbar)
c) Wide-Area Distributed System: Stand-Alone Systeme, die über ein WAN verbunden sind
• Grid-Computing
Abbildung 9: Mehr-Prozessor-Systeme: Shared Memory, Interconnected, Distributed
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 19 of 170
- 19 -
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Abschnitt 2 “Übersicht“
2.2 Aufgaben, Dienste und Komponenten von Betriebssystemen
2.2.1 Prozeß- und Prozessorverwaltung
Prozeß
Programm
Speicherbereich
Daten
Speicherbereich / Register
übrige Betriebsmittel
z. B. Dateien, Geräte
dynamischer Zustand
Prozessorzuordnung
Entzug
bereit
fortsetzen
zuordnen
wartend
rechnend
blockieren
Prozessorzuteilung
P3
P2
Prozessor 2
P1
Prozessor 1
t
Abbildung 10: Prozess-Zustände, Prozessorzuteilung
•
•
•
•
•
logische Prozesse (Erzeugung, Löschung)
Prozessorzuordnung
gegenseitige Beeinflussung von Prozessen, Synchronisation
Ablaufsteuerung, betriebsmittelabhängige Planung und Kontrolle des Gesamtablaufs
Interprozess-Kommunikation:
a) Message Passing
b) Shared Memory
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 20 of 170
- 20 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 2 “Übersicht“
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Abbildung 11: Interprozess-Kommunikation (a) Message Passing, (b) Shared Memory
2.2.2 Programmverwaltung
(übersprungen)
Programmdatei
Auftragsdefinition
Prozeß
Programme
Daten
Betriebsmittel
dynamischer Zustand
Ablaufparameter
Nutzerverweis
Speicherbereiche
Code
Daten
sonstige Betriebsmittel
Sitzungsumgebung
Abbildung 12: Übersicht Programmverwaltung
·
·
·
·
Definition von Programmen
Zuordnung von Programmen zu Prozessen
Abbildung des Programmablaufs auf Prozesse
Besonderheiten
• mehrfach-verwendbarer Code
• dynamisches Binden
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 21 of 170
- 21 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 2 “Übersicht“
•
•
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
z.B. shared Libraries (.dll unter Windows)
Komponenten-Middleware COM/DCOM, CORBA
2.2.3 Zentralspeicherverwaltung
Virtuelle Speicherverwaltung (Paging)
· Jeder Prozess hat eigenen, virtuellen Speicher
· Memory Management Unit setzt jeden Adress-Zugriff von der virtuellen Adresse auf die
physikalische um -> eigene MMU-Hardware nötig
· Ist der physikalische Speicher ausgeschöpft, können Seiten auf die Festplatte ausgelagert
werden. Greift ein Prozess auf diese Seiten zu, so wird ein Seitenfehler ausgelöst -> die
Seite muss von Festplatte nachgeladen werden
Abbildung 13: Übersicht virtuelle Speicherverwaltung
Aufgaben:
· Belegung, Freigabe und Zuordnung von verschiedenen Speicherbereichen an Prozesse
· Verwaltung des Zentralspeichers
· gegenseitiger Zugriffsschutz
· virtuelle Adreßräume
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 22 of 170
- 22 -
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Abschnitt 2 “Übersicht“
2.2.4 Ein-/Ausgabe-Steuerung
Rechnersystem
Zentral
Speicher
c)
Prozessoren
a)
b)
Gerät
E/ASystem
Steuerung
d(
Laufwerk
e
d)
Abbildung 14: Schema E/A Steuerung
Datenfluss:
a) Ein/Ausgabeunterbrechungen
b) Ein/Ausgabebefehle
c) Interprozessorsignale
d) Daten
e) Busprotokoll:
Bus Befehle, Gerätedaten (Adresse, Status), Transferdaten
Aufgaben:
- Geräte-/Konfigurationsverwaltung
* Verkabelung
* Parameter
- physikalische Ein-/Ausgabe
* Gerätesteuerung
* Datentransfer
- logische Geräte
* z.B. Dateien
* Abbildungs- und Zugriffsparameter
- logische Ein-/Ausgabe
* Dateiorganisation
* Dateizugriffe
- Betriebsmittelverwaltung
* Zuordnung zu Prozessen
2.2.5 Externe Datenverwaltung
(übersprungen)
2.2.5.1 Physikalische Speichermedien
* Magnetplatte (Schreib-/Lesekopf, Sektor, Spur)
* Magnetband (Block, Spur, Sprosse)
Dateien
*logischer Adressraum der Datei
Satz: logische Zugriffseinheit für Ein/Ausgabe
Logische Zugriffsstruktur: Satz-Schlüsselfeld
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 23 of 170
- 23 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Abschnitt 2 “Übersicht“
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Feld: vom Programm auswertbarer Teil eines Satzes
*Physikalischer Adressraum der Datei
Block: physikalische Zugriffseinheit für Ein/Ausgabe
Dateiorganisation
* Darstellung: sequentiell, indexsequentiell,direkt ...
* Zugriffsmethoden: sequentiell, indexsequentiell, physikalisch ..
* Verwaltung:
Statisch: Dateikataloge, Speicherplatz, ...
Dynamisch: Sperrenverwaltung, ...
2.2.6 Betriebsmittelverwaltung (Resource Management)
Betriebsmittel
• physikalisch (z.B. Festplatte) – logisch (z.B. Datei)
• aktiv (z.B. Prozessor, Festplattencontroller) - passiv (z.B. Drucker)
• exklusiv (z.B. CD Brenner) – teilbar (z.B. Netzwerk)
• unterbrechbar (z.B. Speicherbelegung: kann geswappt werden) – ununterbrechbar (z.B.
CD-ROM Brenner)
• Anforderung, Belegung, Freigabe
• Fremdzuweisung, Entzug
• Wettbewerb um Betriebsmittel: Achtung Verklemmung (Deadlocks)!
• Beispiel Deadlock: ein Programm fordert zunächst den Drucker, dann eine Datei
„message.log“ an, um eine Meldung auszugeben. Ein anderes Programm fordert
zunächst die Datei „message.log“ an, dann den Drucker -> Verklemmung möglich!
•
Anderes Beispiel:
Abbildung 15: Deadlock an der Kreuzung
•
•
Auswahl- und Zuteilungsstrategien
Verklemmungen (Verhinderung, Entdeckung, Auflösung)
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 24 of 170
- 24 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 2 “Übersicht“
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
2.2.7 Zugriffsschutz (Security)
Gegenseitiger Schutz der Prozesse :
·
Speicher auslesen, überschreiben
·
Fremde Dateien lesen, manipulieren
·
Tastatureingaben, Bildschirmausgaben
-> Rechtesystem „erlaubt“ oder „verbietet“ Zugriff auf Objekte des BT, z.B. Dateien,
Programme,
2.2.8 Kommando-Interpreter (Shell)
Direkter Zugang des Benutzers zum BT, Dateisystem
è
Teil des BT, z.B. DOS, Windows
è
Fremdprodukt, z.B. bei Unix „bash“
2.3 Betriebssystem Strukturen
2.3.1 Einfache Strukturen
2.3.1.1 Beispiel MS-DOS
• Sehr einfache Struktur
• User-Programme greifen direkt auf BIOS (hardware) zu, keine Kontrolle, kein Schutz
• Nur 1 Programm gleichzeitig möglich
• Jedoch „speicher-resistente Programme“ TSR (terminate and stay resident)
möglich: diese TSR installieren sich in einer Interrupt-Kette, z.B. bei
Tastaturangaben, lesen alle Tastatureingaben & werden bei Bedarf aktiv.
Abbildung 16: DOS Struktur
2.3.1.2 Beispiel: Unix
• Großer, monolithischer Kernel der das gesamte BT enthält: ein großes ausführbares
Programm
• 2 Schichten bzw. Modi: User und Kernel; Definierter Übergang vom User-Space in den
Kernel Space via System Trap:
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 25 of 170
- 25 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 2 “Übersicht“
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Typischerweise Software-Interrupt mit Parameterübergabe (Register, Stack,
gemeinsamer Speicher)
• Parameter werden genau geprüft
• Im User-Mode nur beschränkter Zugriff auf Hardware-Resourcen:
• Prozessor-Interrupts können nicht abgeschalten werden -> Prozess schaltet
Scheduler ab!
• Kein Zugriff auf Interrupt-Vektortabelle -> Prozess verbiegt Scheduler-TimerInterrupt auf sich selbst -> Scheduler geht nicht mehr
• Kein direkter Speicherzugriff -> User-Prozess zerstört Kernel-Datenstrukturen,
löscht z.B. alle anderen Prozesse
• Kein Zugriff auf I/O möglich -> User-Prozess stört andere I/O Vorgänge
• Hardware-Unterstützung nötig: wenn der Prozessor den User-Mode nicht
unterstützt, kann man keine saubere Trennung implementieren
• Typischerweise 5 Bereiche:
• Prozess-Kontrolle
• Datei-Verwaltung
• Geräte-Verwaltung
• Informationsaustausch, z.B. date / time Funktionen
• Interprozess-Kommunikation
•
Abbildung 17: Unix Struktur (siehe Folie)
2.3.2 Microkernel
è
Carnegie Mellon University entwickelt das BT „Mach“ mit Mikrokernel Ansatz:
• Alle nicht unbedingt benötigten Komponenten werden aus dem Kernel entfernt und
als User- oder Systemkomponenten implementiert
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 26 of 170
- 26 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 2 “Übersicht“
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Kernel stellt Kommunikationsdienste zwischen den Komponenten zur Verfügung,
z.B. durch Message Passing
• Dadurch sehr kleiner Kernel möglich
Vielfach in anderen Systemen verwendet, z.B. Tru64 UNIX, MacOS X Server; hybrider
Ansatz in WinNT
Teilweise in XP verwirklicht
•
è
è
2.3.2.1 Beispiel Windows XP
·
Hardware Abstraction Layer
·
Kernel: Non-Preemptive -> muss deshalb klein und schnell sein
·
Executive
·
Win32 Subsystem: Programmierer-Schnittstelle zum OS; einige tausend
Funktionen
·
User mode / kernel mode
·
Window Manager im Kernel -> bei Unix typischerweise im User-Mode (X11
Server)
Abbildung 18: Windows Übersicht
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 27 of 170
- 27 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Abschnitt 2 “Übersicht“
2.3.3 Konzept virtueller Maschinen
2.3.3.1 Übersicht VM
Kommandointerpreter
Editor
Compiler
Linker
Dienstprogramme
Betriebssystemaufrufe
-> Maschinensprache
* E/A-Steuerung, logische E/A
* Speicherverwaltung
Betriebssystem
* Prozeßverwaltung
Speicher
höhere Programmiersprache
Maschinensprache
Prozessor
E/A
Hardware-Maschine
Abbildung 19: Aufbau BT
Maschine:
Mechanismus zur Interpretation von in Maschinensprache formulierten Programmen.
Virtuelle Maschine:
Durch interpretierende oder abbildende Software auf Basis einer gegebenen Maschine
definiert.
Hierarchie virtueller Maschinen:
Hardware und Software-Schichten definieren Maschinen mit steigendem Sprachniveau
è
è
Strenges Schichtenmodell
• Jeder Layer greift nur auf den nächst-niedrigeren Layer zu
• der untere Layer stellt eine vollständige „Maschine“ zur Verfügung
• unterschiedliche Definitionen in der Literatur, z.B. Schichtenmodell nur bei VM
Erstmals in IBM OS/370 realisiert:
2.3.3.2 OS/370
è
Vorteile:
• Vollständiger Schutz durch Kapselung -> Sicherheit
• System-Entwicklung ohne Unterbrechung möglich
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 28 of 170
- 28 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 2 “Übersicht“
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Abbildung 20: Virtual Machine (VM) OS/370
2.3.3.3 Java Virtual Machine (JVM)
Virtuelle Maschine auf bytecode-Basis:
Abbildung 21: Java VM
2.3.3.4 Weitere Virtuelle Maschinen
· Emulation von PC-Rechnern:
o
VMWare emuliert PC-Hardware
o
Windows auf Linux-Systemen ist möglich
· Microsoft Virtual Server: neue Server-Familie
· Win32-Emulation: WINE (Wine Is Not an Emulator)
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 29 of 170
- 29 -
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Abschnitt 3 “Prozesse “
3 Prozesse
3.1 Was ist ein Prozess?
Prozess:
• Ausführung eines logisch zusammengehörenden Programms
• Verwaltungseinheit des Betriebssystems
• Prozesse belegen Betriebsmittel
• Prozesse sind aktive Komponenten des Gesamtsystems
Programm
Statisch, wiederholbar
•
Prozess
Dynamisch, nicht wiederholbar
Einmalige Abläufe (Prozessidentifikation PID)
Braucht ein Programm
Ein Objekt im Sinne der Informatik
(Prozessbeschreibung und Methoden)
Im Sinne des BT besteht ein Prozess aus:
• Unveränderlichem Teil: Code, Konstanten
• Veränderlichem Teil: Globale Daten, Stack, Heap
• Kontext (Umgebung): Register, Zeit, Verwaltungsdaten
Eigenschaften:
• Das BT ordnet einzelnen Prozessen das Betriebsmittel CPU zu und entzieht es ihnen
wieder.
• Bei einem Prozessor: Quasi-simultane Ausführung der Prozesse
• Auf einem n-Prozessorsystem laufen zu einem Zeitpunkt maximal n Prozesse.
Typische Zustände eines Prozesses:
DONE
kill
beenden
RUN
kill
zuteilen
blockieren
Entzug
WAIT
READY
NOT
EXISTING
fortsetzen
Abbildung 22: Prozess-Zustände
·
Prozesserzeugung:
• Unix: fork()
• Win32: CreateProcess()
Begrifflichkeiten für lauffähige Objekte des BT:
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 30 of 170
- 30 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 3 “Prozesse “
•
•
•
•
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Üblicherweise wird heutzutage Prozess verwendet.
Früher (Batch-Betrieb) war Job gebräuchlich.
In Embedded Systemen oft auch Task (typischerweise kein Speicherschutz).
Thread oder LWP (Light-Weight Process) bezeichnet lauffähiges Objekt innerhalb eines
Prozesses, die typischerweise Resourcen mit dem Prozess teilen (Dateien, Speicher, etc)
3.2 Prozessverwaltung
3.2.1 Prozesskontrollblöcke
Prozesskontrollblock (PLB, PCB) oder Task Control Block (TCB). Pro Prozess gibt es genau
einen PCB, der diesen Prozess beschreibt. Das BT verwaltet die Prozesse anhand der PCBs.
Enthält alle wesentlichen Eigenschaften eines Prozesses:
- Beschreibende Eigenschaften:
· Name
· Art
· Basispriorität
· Codedatei-Verweis
· Betriebsmittel-Bedarf: Speicherbedarf, weitere Resourcen, Zeitbedarf
- Prozessorverwaltung:
· Prozess-Zustand (READY, WAITING, etc.)
· Aktuelle Priorität
· Prozessidentifikation PID (bzw. TID)
· Prozessor-Zustand:
o Spezialregister-Inhalte: Programmzähler, Flags, Statuswort,
Unterbrechungsmasken, Schutzmasken, Adressumsetzungsdaten, StackZeiger
o Daten- und Adressregister-Inhalte
· Ggfs. verbrauchte Zeit
- Speicherverwaltung
· Zeiger auf Programm (CODE)
· Zeiger auf Daten (DATA)
· Zeiger auf Stack
· Ggfs. Shared Memory
- Dateiverwaltung (I/O)
· Root Directory
· Aktuelles Directory
· Geöffnete Dateien
· Zugriffsrechte
· User ID, Group ID
- Verwaltungsdaten
· Rechte
· Statistikdaten
Implementierung:
· Entweder alle Eigenschaften in einer Struktur
· Oder Verweise auf Unterstrukturen
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 31 of 170
- 31 -
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Abschnitt 3 “Prozesse “
3.2.2 Verwaltung der PCBs
Viele Prozesse möglich, die effektiv verwaltet werden müssen -> Datenstruktur-Problem
• Einzelne Skalare (Variablen)
• Bei eingebetteten Systemen sind oftmals alle Tasks statisch und zur Compilezeit
bekannt
• Konstantes Array (Feld)
• Maximale Anzahl der Prozesse vorgegeben
• Variable verkettete Liste
• Baum
P3
P1
P2
P1
P3
P4
P2
P1
P3
P2
3 - - 1 4 - 2 - - -
P4
P5
Abbildung 23: Organisation von PCBs
Teilmengenbildung bezüglich wichtiger Attribute, z.B. je eine Queue für Prozesse im Zustand
READY, WAITING, RUN, dient zur Effizienzsteigerung
3.2.3 Prozesserzeugung & -vernichtung
3.2.3.1 Statisch vs. Dynamisch
Statische Betriebssysteme:
Alle Prozesse sind vorher bekannt und statisch definiert. Z.B. bei eingebetteten Systemen.
• Alle Prozesse werden „am Schreibtisch“ statisch festgelegt
• PCBs werden als Variable gespeichert, z.B.
struct task_struct MyTask1;
• Prozesse werden für eine bestimmte Anwendung geschrieben
• Die PCBs werden vom einem Tool einmalig erzeugt
• Keine Vernichtung von Prozessen
Dynamische Betriebssysteme:
Die Prozesse werden mittels Kernel-Aufrufen erzeugt und vernichtet.
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 32 of 170
- 32 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 3 “Prozesse “
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
3.2.3.2 Prozesserzeugung
· Systeminitialisierung
· Aus anderem Prozess heraus
· Durch Benutzeranforderung
· Als Batchjob
3.2.3.3 Prozessvernichtung
· Normales Ende (freiwillig)
· Fehlerzustand (freiwillig)
· Systemfehler (unfreiwillig)
· Killed (durch anderen Prozess)
· Unix: exit()
· Win32: ExitProcess()
3.2.3.4 Beispiel Unix: fork()
Unix-Aufruf zum Erzeugen eines Prozesses:
pid_t fork(void);
• Erzeugt eine „Kopie“ des aktuellen Prozesses
• Dasselbe Programm
• Dieselben geöffneten Dateien
• Neue PID
• Der gesamte Speicher wird kopiert und dem neuen Programm zur Verfügung
gestellt
• Nach dem fork() Aufruf existieren zwei verschiedene Prozesse für dasselbe Programm.
• Falls der Rückgabewert ungleich 0 ist: ursprüngliches Programm, Rückgabewert =
PID des Kindes
• Ist der Rückgabewert 0, so handelt es sich um den Kindprozess.
Pseudo-Code:
int pid = fork();
if( pid==0 ) {
// dieser Code wird im Kindprozess ausgeführt
} else {
// dieser Code wird im Vaterprozess ausgeführt
}
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 33 of 170
- 33 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 3 “Prozesse “
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
In Unix strenge, unabänderliche Prozesshierarchie: einmal child, immer child:
Abbildung 24: Prozesshierarchie
3.2.3.5 Beispiel Unix: exec()
Lädt ein neues Prozess-Image im aktuellen Prozess:
• Ersetzt das aktuelle Programm vollständig
• Das neue Programm startet von Null
• exec() kehrt nicht zurück; Ausnahme: im Fehler (neues Programm nicht gefunden, keine
ausreichenden Rechte, zu wenig Speicher) gibt exec() einen Fehlercode zurück.
Ausschnitt aus POSIX-Standard 1003.1-2001:
NAME
environ, execl, execv, execle, execve, execlp, execvp - execute a file
SYNOPSIS
#include <unistd.h>
extern char **environ;
int execl(const char *path, const char *arg0, ... /*, (char *)0 */);
int execv(const char *path, char *const argv[]);
int execle(const char *path, const char *arg0, ... /*,
(char *)0, char *const envp[]*/);
int execve(const char *path, char *const argv[], char *const envp[]);
int execlp(const char *file, const char *arg0, ... /*, (char *)0 */);
int execvp(const char *file, char *const argv[]);
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 34 of 170
- 34 -
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Abschnitt 3 “Prozesse “
DESCRIPTION
The exec family of functions shall replace the current process image with a new
process image. The new image shall be constructed from a regular, executable
file called the new process image file. There shall be no return from a
successful exec, because the calling process image is overlaid by the new
process image.
Prozess 501
"bash"
kernel
fork()
Idle
fork()
Code
Prozess 748
exec("ls","")
"bash"
exec() Code:
ls laden und starten
"ls"
Abbildung 25: Ablauf fork() - exec()
3.2.3.6 Beispiel Win32: CreateProcess()
Es wird immer ein neues Programm ausgeführt
Parameter von CreateProcess():
· Name des Programms
· Kommandozeilenparameter
· Prozess- und Thread-Security Beschreibungen
· Vererbungsflag: sollen alle Handles vererbt werden? Ja -> wie fork
· Spezialeinstellungen
· Neues Environment,
· Aktuelles Verzeichnis
· Startup-Informationen für das Fenster-System
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 35 of 170
- 35 -
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Abschnitt 3 “Prozesse “
3.3 Kontextwechsel
Funktionsaufruf, Interrupt (Systemaufruf), Kontextwechsel
Funktionsaufruf
P1
Interrupt oder
Systemaufruf
P1
Kernel
P1
Interrupt oder
Systemaufruf
Kernel
P2
Interrupt oder
Systemaufruf
Interrupt:
- PC auf Stack
- Register, etc. auf Stack
- neuen PC setzen
Funktionsaufruf:
- Parameter auf Stack
- PC auf Stack
- neuen PC setzen
Rückkehr:
- PC von Stack holen &
setzen
Kontextwechsel
PCB1
sichern
Rückkehr (RTI):
- Register wiederherstellen
- PC von Stack holen &
setzen
- Löschen von Kernel-Mode
PCB2
laden
PCB2
sichern
Interrupt oder
Systemaufruf
PCB1
laden
Abbildung 26: Funktionsaufruf, Interrupt, Prozesswechsel
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 36 of 170
- 36 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Abschnitt 3 “Prozesse “
3.3.1 Funktionsaufruf
Auslöser ist der Prozess (das Programm) selbst
Aufruf:
• Parameter auf Stack legen
• Befehlszähler auf Stack legen
• Neuen Befehlszähler laden
• Rückkehr:
• Alten Befehlszähler vom Stack laden
•
•
3.3.2 Interrupt
Auslöser von I/O Gerät (z.B. Festplattenkontroller, Timer) oder Prozess selbst (SystemTrap für Kernel-Aufruf)
• Aufruf:
• Befehlszähler auf Stack legen
• Neuen Befehlszähler laden
• Kernel-Mode setzen
• Rückkehr (Return from Interrupt, RTI):
• Interrupt-Flag, Kernel-Mode zurücksetzen
• Alten Befehlszähler vom Stack laden
•
3.3.3 Prozesswechsel
•
•
•
•
•
•
➔
➔
Interrupt in den Kernel
• Auslöser von I/O Gerät (z.B. Festplattenkontroller, Timer) oder Prozess selbst
(System-Trap für Kernel-Aufruf)
Scheduler entscheidet, jetzt Prozess 2 laufen zu lassen
• Prozess 1 geht von RUN -> READY oder WAITING über
Zustand (PCB) von Prozess 1 sichern
PCB P2 laden:
• Prozessor-Spezialregister
• Daten- und Adressregister
• Speicherverwaltung
• I/O Verwaltung
Rücksprungadresse auf Stack manipulieren
Rücksprung (RTI) aus Interrupt in den neuen Prozess
Kontextwechsel sehr zeitaufwändig
HW Unterstützung möglich, Wechselregistersätze, etc.
3.3.4 Unterbrechungsarten
(übersprungen)
Externe Unterbrechungen
• Geräte-Interrupts:
Fertig-Meldungen von I/O Steuerungen / Geräten
Alarme von Spezialperipherie
Konsol-Eingriffe (z.B. Ctrl-Alt-Del)
Interne Unterbrechungen
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 37 of 170
- 37 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 3 “Prozesse “
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Fehlersignale
Verknüpfungsfehler, z.B. Division durch Null
Privileg-Verstöße
Unbekannter Befehl
Adressierungsfehler
• Durch Spezialbefehle erzeugt
BT-Aufrufe (Trap)
Befehlssimulation
• Debug-Interrupts
Einzelschrittmodus: jeder Befehl löst einen Interrupt aus
Sprungmodus: bei bestimmten Sprüngen (z.B. Rücksprung) wird ein IR ausgelöst
Zugriffsmodus: bei Zugriff auf bestimmten Speicher wird ein IR ausgelöst
Interprozessor-Signale
• Im Mehrprozessorsystem von fremdem Prozessor per Spezialbefehl ausgelöst
•
Interrupt-Verarbeitung:
Je nach Prozessor verschiedene Bearbeitungen möglich:
• Nur ein Interrupt möglich: alle weiteren Interrupts müssen warten bis der aktuelle
fertig ist
Nachteil: hochpriore, „eilige“ Interrupts können verzögert werden
• Mehrere, geschachtelte Interrupts möglich: Rettung der Daten auf dem Stack
Vorteil: hochpriore IR werden bevorzugt behandelt
Nachteil: erhöhter Stackbedarf
• Spezialregister teilweise mehrfach vorhanden für verschiedene Interrupts
• Prioritisierung von Interrupts
• Maskierung von Interrupts
3.4 Interprozess-Kommunikation
Prozesse:
• eigenständige, abgekapselte Einheiten im Betriebssystem
-> keine Kommunikation zwischen den Prozessen möglich!
Man möchte jedoch eine Zusammenarbeit zwischen verschiedenen Prozessen haben!
3.4.1 Message Passing
Mindestens zwei Funktionen:
•
•
send(message)
receive(message)
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 38 of 170
- 38 -
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Abschnitt 3 “Prozesse “
Prozess P
Nachricht X
Prozess Q
Nachricht X
Mailbox 471
Abbildung 27: Schema Message Passing
Verschiedene Möglichkeiten:
• direkte oder indirekte Kommunikation
• synmmetrisch oder asymmetrisch
• automatische oder explizite Pufferung
• Send-by-Copy oder Send-By-Reference
• Feste Länge der Messages oder variabel
3.4.1.1 Direkte Kommunikation
• Eins-zu-eins Kommunikation: Für jedes Sender / Empfänger Paar gibt es genau einen
Kommunikationskanal.
• Ein sendender Prozess muss explizit den Empfänger-Prozess angeben.
• Symmetrisch: Sender und Empfänger kennen sich:
•
•
•
send(P, message) – schicke Nachricht an P
receive(Q, message) – hole Nachricht
Asymmetrisch: Sender kennt Empfänger, Empfänger jedoch nicht unbedingt den Sender:
•
•
send(P, message) – schicke Nachricht an P
receive(sender_id, message) – hole Nachricht (asymmetrisch)
Nachteil:
• fehlende Modularität, da der Sender den Empfänger kennen muss
3.4.1.2 Indirekte Kommunikation
• Nachrichten werden an Mailboxen (oder Ports) geschickt:
•
•
•
•
send(A, message) – A ist eine Mailbox
receive(A, message)
Mehr als 1 Sender oder 1 Empfänger möglich
Mehrere verschiedene Kommunikationskanäle zwischen zwei Prozessen möglich
3.4.1.3 Synchronisierung
Sender:
• blockierend (synchron): Sender wartet, bis die Nachricht verarbeitet wurde
• nicht-blockierend (asynchron): Sender schickt die Nachricht und rechnet sofort weiter; die
Nachricht muss vom OS gepuffert werden
Empfänger:
• blockierend: falls keine Nachricht da ist, wartet der Empfänger solange bis eine kommt
• nicht-blockierend: Empfänger schaut nach, ob eine da ist; falls ja, wird diese geholt, falls
nicht, so kommt eine entsprechende Fehlermeldung zurück
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 39 of 170
- 39 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Abschnitt 3 “Prozesse “
3.4.1.4 Pufferung
• Keine Pufferung (nur synchrone Zustellung möglich)
• Feste Puffergrösse: einfach, Nachteil: Puffer kann überlaufen
• Variable Puffergrösse: aufwändig zu implementieren
3.4.1.5 Beispiel: Mach
Verwendet MP zur Interprozess-Kommunikation und zur Kommunikation von Prozessen mit
dem Kernel: alle System-Calls werden über MP realisiert
• Jede Task (Prozess) hat zwei spezielle Mailboxen: Kernel und Notify
• Über Kernel kann die Task messages an den Kernel schicken
• Sie wird über Notify vom Kernel über die Ergebnisse benachrichtigt
3.4.2 Pipes
Unix-Manual zu Pipes:
PIPE
Section: Linux Programmer's Manual (2)
NAME
pipe - create pipe
SYNOPSIS
#include <unistd.h>
int pipe(int filedes[2]);
DESCRIPTION
pipe creates a pair of file descriptors, pointing to a pipe inode, and
places them in the array pointed to by filedes. filedes[0] is for reading,
filedes[1] is for writing.
RETURN VALUE
On success, zero is returned. On error, -1 is returned, and errno is set
appropriately.
SEE ALSO
read(2), write(2), fork(2), socketpair(2)
Dient zum Datenaustausch mit einem anderen Prozess
Vater
Kind
Abbildung 28: Schema Pipes
•
Mittels read() und write() werden Daten an den anderen Prozess übergeben
• read() liest eine Anzahl von Daten von der Pipe
• write() schreibt eine Anzahl von Daten in die Pipe
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 40 of 170
- 40 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 3 “Prozesse “
•
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Kommunikation typischerweise zwischen Vater und Kind
• Vater legt pipes an
• Nach fork() stehen diese auch dem Kind zur Verfügung
int a_pipe[2];
int res=pipe(a_pipe);
if( fork()==0 ) {
// child: read from pipe 0, write to pipe 1
...
} else {
// parent: read from pipe 1, write to pipe 0
...
}
3.4.3 Sockets
Ein Socket ist definiert als Endpunkt für eine Kommunikation, basiert auf TCP/IP
Netzwerkprotokoll.
Ähnlich wie Pipes, ein Prozess kann Daten in ein Socket schreiben, ein zweiter kann Daten
aus dem Socket lesen
• 1 Socket ist jedoch bi-direktional: beide Seiten können der jeweils anderen etwas
schicken
• Client-Server-Verhalten
• Der Server öffnet ein Socket als Zuhörer (Listener) und wartet auf
Verbindungswünsche von den Clients
• Der Client baut eine Verbindung zum Server auf und schickt diesem die Daten zu
• Der Server verarbeitet die Daten und schickt eine Antwort zurück
• Im Unterschied zu Pipes auch Netzwerk-fähig
• Ein Socket wird dynamisch aufgebaut
• Der Client spezifiziert den gewünschten Server anhand der IP-Adresse und der PortNummer, z.B. 192.168.100.11:23 (telnet-Port)
• Auf einem Rechner können mehrere Server laufen; diese unterscheiden sich anhand
der Port-Nummer
• Reservierte (bekannte) Portnummer <1024, z.B.
• Port 23: telnet
•
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 41 of 170
- 41 -
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Abschnitt 3 “Prozesse “
Port 21: ftp
Port 80: http
• Über 1024: frei wählbare Portnummern
• auch zwischen Prozessen auf demselben Rechner möglich; IP-Nummer 127.0.0.1
(localhost)
•
•
Beispiel:
• Web-Server
Server
Initialisiere
(listen-Modus)
Client
Anforderung
Engegennehmen
und bearbeiten
Antwort
Abbildung 30: Client-Server mit Sockets
3.4.4 Client-Server: RPC
Remote Procedure Call: Funktionsaufrufe in andere Prozesse oder auf andere Rechner
Prozessgrenze,
Netzwerk
Client
Server
6
1
Stub
2
3
5
f()
4
Skeleton
Abbildung 31: Schema RPC Aufruf
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 42 of 170
- 42 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 3 “Prozesse “
•
•
•
•
•
•
•
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Notation gemäß Java-RMI; Microsoft nennt den Stub Proxy, und das Skeleton Stub...
Adressierung: wie Sockets über IP-Nummer / Portnummer; basiert auf Sockets
Ablauf:
1. Client ruft Funktion auf; wird von Stub entgegen genommen
2. Stub verpackt Funktionsname und Parameter in einen Datenstrom und schickt
diesen an den Server
• Adresse des Servers (IP+Port)
• Funktionsname
• Parametern
3. Skeleton nimmt Datenstrom entgegen, packt Daten aus und ruft die Funktion auf
4. Skeleton nimmt das Ergebnis entgegen, erzeugt davon einen Datenstrom
5. und schickt diesen an den Stub zurück
6. Dieser packt das Ergebnis aus und gibt es an das aufrufende Programm zurück (es
war solange blockiert)
Einheitliche Datenrepresentation nötig
• external data representation (XDR) ist Standard
• muss unterschiedliche Prozessorarchitekturen berücksichtigen (Bigendian vs.
Littleendian)
• das Verpacken der Parameter nennt man marshalling
Client-Server Binding:
• feste Bindung (zur Compile-Zeit) oder
• dynamische Bindung: ein OS-Programm vermittelt zwischen Client und Server
Probleme mit RPC:
• sehr lange im Vergleich zu “einfachem” Funktionsaufruf:
• direkter Funktionsaufruf einige ns
• Funktionsaufruf von einem Prozess zu einem anderen (auf demselben
Rechner): mindestens einige ms (Faktor 1000 größer!)
• Netzwerk-Funktionsaufruf: mindestens einige ms (Faktor 1.000.000 größer!)
• Funktionsaufrufe können fehlschlagen
• Netzwerkfehler, Server nicht bereit oder ausgelastet, etc.
• Mehrfache Ausführung möglich
Ähnliches Protokoll auf XML/HTTP basierend: Web-Services
3.4.5 Verteilte Objekte
-> wird in “Verteilte Systeme” nochmals behandelt
RPC: der Server stellt Funktionen zur Verfügung (strukturierte Programmierung)
Objektorientierte Ansätze: der Server stellt Objekte zur Verfügung:
• Zustandsbehaftet: der Server erzeugt ein Objekt, das ausschließlich einem Client gehört;
damit ist zum Beispiel möglich:
• Client “bestellt” Objekt o bei Server
• Client: o.init(p1, p2);
• Client: o.tu_etwas(p3);
• Client gibt Objekt wieder frei: o.bin_fertig();
• Das Objekt wird an einen Client gebunden
• Zustandslos: das Objekt hat keinen Zustand, d.h. es ist nicht an einen Client gebunden;
bessere Performance am Server (Beispiel: HTTP Protokoll ist zustandslos)
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 43 of 170
- 43 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 3 “Prozesse “
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Stub/Skeleton für das ganze Objekt
Objekte finden & erzeugen: Object Request Brokers (ORB)
• Client stellt Anfrage an ORB, z.B. mit Namen des gewünschten Server-Objektes
• ORB liefert Referenz auf das Objekt zurück
• Ggfs. Erzeugt der ORB das Objekt
Techniken:
• Microsoft COM/DCOM
• Java RMI
• CORBA
•
•
3.4.5.1 Komponenten-Transaktions-Server (CTS)
Komponenten-Transaktions-Server stellen eine Laufzeitumgebung für Komponenten zur
Verfügung
• Erzeugung / Vernichtung von Komponenten
• Transaktionen
• Sicherheit
• Persistenz
• Konfigurierbarkeit
• u.v.m.
Beispiele:
• Microsoft COM+ Services (früher MTS)
• Enterprise Java Beans (EJB), von SUN, IBM, Bea, u.v.a.
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 44 of 170
- 44 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 4 “Threads“
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
4 Threads
4.1 Allgemein
Prozessmodell:
Zwei unabhängige Eigenschaften eines Prozesses:
• Er hat Resourcen: Adressen, Daten, geöffnete Dateien
• und ist ausführbar
Thread:
• hat keine eigenen Resourcen (ausser Thread Local Storage, TLS)
• ist ausführbar (Umschaltung wie bei Prozess)
• erlaubt Nebenläufigkeit innerhalb einer Prozessumgebung
Abbildung 32: Thread vs. Prozess (nach [2])
Begriffsdefinition:
• Ein Prozess hat mindestens einen Ausführungs-Thread.
• Threads werden auch LWP (Light Weight Processes) genannt.
• Thread-Local Storage (TLS): Daten, die einem bestimmten Thread zugeordnet sind (sind
manchmal zur Programmierung nötig)
Prozess
Thread
Addressraum
Befehlszähler
Globale Variablen
Register
Geöffnete Dateien
Stack
Kindsprozesse
Zustand
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 45 of 170
- 45 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 4 “Threads“
Prozess
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Thread
Ausstehende Alarme
Signale, Signalhandler
Verwaltungsdaten
-> kein Schutz zwischen verschiedenen Threads!
4.1.1 Anwendungsbeispiel 1: MS Word
1 Programm bearbeitet 1 Dokument; dennoch sind verschiedene Aufgaben gleichzeitig zu
erledigen:
• Anzeige des Dokumentes, Scrollen
• Drucken im Hintergrund
• Speichern im Hintergrund
• Verschiedene Prozesse: Kein Zugriff auf die Daten möglich
• Kein Zugriffsschutz nötig, da ja alle Teile zu MS Word gehören
•
4.1.2 Anwendungsbeispiel 2: Web-Server
Der Web-Server bearbeitet verschiedene Anfragen; für jede Anfrage ist z.B. ein Zugriff auf
das Datei-System nötig (blocking I/O): während dieser Zeit können keine weiteren Anfragen
bearbeitet werden
Deshalb: jede Anfrage wird in einem eigenen Thread bearbeitet.
-> bessere Performance
4.2 Threaderzeugung
Vergleich von Prozesserzeugung und Threaderzeugung:
a) Prozesserzeugung
Prozess 1
fork()
b) Threaderzeugung
Prozess 1
Prozess 2
clone()
Abbildung 33: Threaderzeugung (einfache Darstellung ohne Kernel)
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 46 of 170
- 46 -
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Abschnitt 4 “Threads“
a) Prozesserzeugung
Prozess 1
b) Threaderzeugung
(User-Level Thread)
Kernel
c) Threaderzeugung
(Kernel-Level Thread)
Prozess 1
Prozess 2
fork()
Prozess 1
pthread_create()
Kernel
clone()
Abbildung 34: Thread-Erzeugung (Darstellung mit Kernel)
Allgemeine Parameter bei der Threaderzeugung:
• Arbeitsfunktion (worker function): eine Funktion, die im Thread abgearbeitet wird
• Stack für neuen Thread:
• Extra Speicherbereich
• oder Bereitstellung durchs Betriebssystem
• Funktionsparameter: 1 Parameter reicht, da typischerweise ein Zeiger auf Datenstrukturen
übergeben werden kann; dort können beliebig viele Daten gespeichert werden
(gemeinsamer Speicherbereich!)
• Einstellungen (Flags):
• Optionen bei der Erzeugung, z.B. Übernahme offener Dateien, etc.
• Sicherheitseinstellungen (Win32)
4.2.1 Linux: clone()
Dient zum Erzeugen eines neuen Threads bzw. LWP (Light-Weight-Process)
Parameter:
• Thread Worker-Funktion: enthält die Funktion, die im Thread ausgeführt werden soll
• wenn die Funktion zurückkehrt, wird der Thread beendet
• Child-Stack: eigener Stack wird benötigt; hier kann der benötigte Speicher zur Verfügung
gestellt werden
• Flags: verschiedene Einstellungen sind möglich; einige sind:
• CLONE_PARENT: Thread hat denselben Vater wie der erzeugende Prozess
• CLONE_FS: Dateisystem wird zwischen Kind und Vater geteilt (shared)
• CLONE_FILES: Dateien werden zwischen Kind und Vater geteilt (shared)
4.2.2 Win32: CreateThread()
Win32-Befehl zum Erzeugen und Vernichten eines neuen Threads: CreateThread(),
ExitThread()
• In der C-Standardbibliothek: _beginthread(), _exitthread()
•
Parameter:
• Sicherheitskontext
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 47 of 170
- 47 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 4 “Threads“
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Stack-Größe
Funktionszeiger auf Arbeitsfunktion (worker function), die nach dem Erzeugen des Threads
aufgerufen wird
• 1 Parameter, der der Arbeitsfunktion übergeben wird (typischerweise ein Zeiger auf eine
Datenstruktur)
• Flags zur Threaderzeugung, z.B.
• CREATE_SUSPENDED: der Thread wird erzeugt, ist aber suspendiert (läuft nicht)
• Rückgabe-Parameter: Thread-ID des erzeugten Threads
•
•
4.2.3 POSIX: pthread-create()
POSIX-Threads: erzeugen mit pthread_create()
Parameter:
• Rückgabe-Parameter Thread-ID
• Thread-Attribute
• Arbeitsfunktion
• Argument
POSIX-Man-Pages:
NAME
pthread_create - thread creation
SYNOPSIS
#include <pthread.h>
int pthread_create(pthread_t *thread, const pthread_attr_t *attr,
void *(*start_routine)(void*), void *arg);
DESCRIPTION
The pthread_create() function is used to create a new thread, with attributes
specified by attr, within a process. If attr is NULL, the default attributes are used.
If the attributes specified by attr are modified later, the thread's attributes are not
affected. Upon successful completion, pthread_create() stores the ID of the
created thread in the location referenced by thread.
The thread is created executing start_routine with arg as its sole argument. If the
start_routine returns, the effect is as if there was an implicit call to pthread_exit()
using the return value of start_routine as the exit status. Note that the thread in
which main() was originally invoked differs from this. When it returns from main(),
the effect is as if there was an implicit call to exit() using the return value of main
() as the exit status.
The signal state of the new thread is initialised as follows:
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 48 of 170
- 48 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Abschnitt 4 “Threads“
•
The signal mask is inherited from the creating thread.
•
The set of signals pending for the new thread is empty.
If pthread_create() fails, no new thread is created and the contents of the location
referenced by thread are undefined.
RETURN VALUE
If successful, the pthread_create() function returns zero. Otherwise, an error
number is returned to indicate the error.
4.3 User- und Kernel-Threads
Unterschiedliche Threads im User-Space und im Kernel-Space:
• User-Threads: werden vom Programm explizit erzeugt & führen eine Berechnung durch
(Arbeitsfunktion)
• Kernel-Threads: laufen im Kernel, um Kernel-spezifische Aufgaben zu erledigen
• z.B. I/O, Datenstrukturen updaten, etc.
• Bei Systemaufrufen wechselt der ausführende Thread: ein User-Thread übergibt die
Kontrolle an einen Kernel-Thread
User
Thread
Kernel
Thread
I/O Gerät
Systemaufruf
WAITING
I/O Befehl
WAITING
Abbildung 35: Wechsel von User-Thread zu Kernel-Thread
4.3.1 User-Level Threads
Sind auf User-Ebene implementiert durch eine System-Bibliothek, wie z.B. POSIX Pthreads.
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 49 of 170
- 49 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 4 “Threads“
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Vorteile:
• Einfach zu implementieren
• Sehr effizient, da kein Übergang von User-Mode in Kernel-Mode nötig ist
• Keine Kernel-Unterstützung nötig -> können auch auf Betriebssystemen realisiert werden,
die keine Thread-Unterstützung bieten
Problem:
• Prozess hat mehrere User-Level-Threads und ruft nun eine System-Funktion auf, die
blockiert (z.B. I/O). Dann wird der gesamte Prozess in den Zustand WAITING versetzt,
obwohl andere Threads noch lauffähig wären
4.3.2 Kernel-Level Threads
Sind Bestandteil des Kernels. Alle modernen Betriebssysteme unterstützen Threads.
Vorteile:
• Mehr Nebenläufigkeit:
• Threads können auf Mehrprozessor-Maschinen auf verschiedenen Prozessoren
laufen
• Thread blockieren sich nicht gegenseitig
Nachteile:
• Betriebssystem-Unterstützung nötig
• Threadwechsel aufwändiger, da dies vom Kernel / Scheduler durchgeführt wird
4.3.3 Many-to-one Modell (User-Level-Threads)
Dies entspricht User-Level-Threads: mehreren Threads im User-Space ist ein Kernel-Thread
zugeordnet. Wenn der Kernel-Thread blockiert, blockieren alle anderen Threads ebenso.
Abbildung 36: many-to-one Thread Modell (nach [2])
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 50 of 170
- 50 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 4 “Threads“
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
4.3.4 One-to-one Modell (Kernel-Level-Threads)
Jedem User-Level-Thread ist genau ein Kernel-Thread zugeordnet. Alle Threads können vom
Scheduler getrennt behandelt werden.
Abbildung 37: One-to-one Thread Modell (nach [2])
4.3.5 Many-to-many Modell (gemischt)
Jedem Thread im User-Space werden nach Bedarf Kernel-Threads zugeordnet.
Abbildung 38: Many-to-many Thread Modell (nach [2])
Vorteile:
• Beliebig viele User-Threads möglich
• Zugeordnete Kernel-Threads erlauben hohes Mass an Nebenläufigkeit
• Viele Betriebssysteme unterstützen dieses Modell, z.B. Solaris 2
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 51 of 170
- 51 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 4 “Threads“
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
4.4 Beispiele
4.4.1 Pthreads: User-Level Bibliothek
•
•
Implementiert den POSIX-Standard
User-Level Threads, überall verfügbar
4.4.2 Win2000 Threads
•
•
One-to-one Thread Modell: jeder User-Thread entspricht einem Kernel-Thread
Zusätzliche Fiber-Bibliothek ermöglicht ein many-to-many Thread-Modell
4.4.3 Solaris 2 Threads
Pthreads auf User-level
Zwischenebene: LWPs
• Jeder Prozess hat zumindest einen LWP
• Die Thread-Bibliothek bildet die verschiedenen User-Threads nach Bedarf auf LWPs
ab
• Jeder LWP hat einen Kernel-Thread
• Standard-Kernel-Threads dienen zur Abwicklung aller Kernel-Aufgaben
•
•
Abbildung 39: Solaris 2 Threading Modell (nach [2])
4.4.4 Linux-Threads
•
clone()-Befehl, ähnlich wie fork()
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 52 of 170
- 52 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 4 “Threads“
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
4.4.5 Java Threads
Erinnerung: Java läuft in der Java Virtual Machine
• JVM verwaltet Java-Threads
• weder User- noch Kernel-Threads im klassischen Sinne
• Mapping auf Kernel-Threads hängt von der jeweiligen Java-VM ab
• Objekt-Orientiert:
• Lauffähige Objekte werden von java.lang.Thread abgeleitet
• müssen eine run() Funktion bereitstellen, die beim Starten des Thread aufgerufen
wird (Arbeitsfunktion)
• Thread wird durch o.start() erzeugt, welches implizit o.run() aufruft – o.run() wird
nie direkt aufgerufen!
-> dazu gibt es eine Übung!
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 53 of 170
- 53 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Abschnitt 5 “CPU Scheduling“
5 CPU Scheduling
5.1 Grundlagen
5.1.1 CPU Burst / I/O Burst
Beobachtung: Programme rechnen typischerweise etwas, dann tätigen sie Ein/Ausgabe:
• CPU-Burst: das Programm rechnet eine Weile intensiv
• I/O Burst: das Programm wartet auf I/O
-> Unterteilung der Programme nach CPU-intensiv und I/O intensiv
Abbildung 40: CPU intensiv (a) vs. I/O intensiv (b) (nach [2])
Abbildung 41: Burst Dauer (Histogramm) (nach [2])
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 54 of 170
- 54 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Abschnitt 5 “CPU Scheduling“
5.1.2 Scheduler
Ein OS kann mehrere Scheduler haben, z.B.
• Admission Scheduler: startet Batch Jobs wenn ausreichende System-Resourcen vorhanden
sind
• CPU-Scheduler (Kurzzeit-Scheduler): entscheidet, welcher Prozess (im Zustand READY) als
nächstes aktiviert werden soll
• Swapper-Demon: entscheidet bei Systemüberlast, welcher Prozess ausgelagert werden
soll; bei starker Systemüberlast können auch Prozesse gekillt werden; Linux: Prozess
kswapd
Im folgenden beschäftigen wir uns mit dem Kurzzeit-Scheduler.
Abbildung 42: 3-Level Scheduler (nach [2])
DONE
kill
beenden
RUN
kill
zuteilen
blockieren
Entzug
WAIT
READY
NOT
EXISTING
fortsetzen
Abbildung 43: Prozess-Zustände
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 55 of 170
- 55 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 5 “CPU Scheduling“
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Wann werden nun Prozesse vom Scheduler zugeteilt?
1. Wenn ein Prozess vom Zustand RUNNING in den Zustand WAITING wechselt (z.B. I/O
Request, oder wait()-Aufruf )
2. Wenn ein Prozess vom Zustand RUNNING in den Zustand READY wechselt (z.B. durch
Interrupt)
3. Wenn ein Prozess vom Zustand WAITING in den Zustand READY wechselt (z.B. weil ein
I/O Request fertig ist)
4. Wenn ein Prozess terminiert
Definition: Non-preemptive System
Ein aktiver Prozess läuft solange, bis er entweder blockiert (auf I/O wartet) oder von alleine
die Kontrolle abgibt (z.B. sich selbst schlafen legt oder terminiert).
• D.h. Ein Prozesswechsel tritt nur bei 1) oder 4) auf.
• Alle diese Vorgänge sind unter Kontrolle des Prozesses, keine unerwarteten
Prozesswechsel.
Definition: Preemptive System
Ein aktiver Prozess läuft maximal eine vorgegebene Zeit, danach wird er vom Scheduler
unterbrochen und ein anderer Prozess wird aktiviert.
• Prozesswechsel auch bei 2 & 3: dies ist für den Prozess unverhersehbar und überraschend
• Zusätzlich benötigte Hardware: z.B. ein Timer, der regelmässig den Scheduler aktiviert
5.1.3 Dispatcher
Lädt den ausgewählten Prozess :
– Kontextwechsel
– Wechsel in den User-Mode (der Scheduler läuft im Kernel-Mode!)
– Sprung an die Stelle, an der der Prozess unterbrochen wurde, um das Programm
weiterzuführen
Dispatch-Verzögerung: Zeit, die der Dispatcher braucht um einen anderen Prozess zum laufen
zu bringen; diese Zeit geht verloren
5.2 Ziele des Scheduling
Was sind die Ziele des Scheduling?
Nach welchen Kriterien soll der nächste Prozess ausgewählt werden?
5.2.1 Allgemeine Kriterien
•
•
Gerechtigkeit: alle Prozesse bekommen die CPU zugeteilt
Balance: alle Teile des Rechners werden möglichst gleichmässig ausgelastet
5.2.2 Großrechner (Batch Systeme)
•
•
CPU-Auslastung: die CPU-Auslastung sollte so hoch wie möglich sein.
Throughput (Durchsatz): Möglichst viele Jobs in möglichst kurzer Zeit fertigstellen.
Gesamtsicht auf das System: wieviele Jobs werden in 1 Stunde durchgerechnet?
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 56 of 170
- 56 -
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Abschnitt 5 “CPU Scheduling“
•
Turnaround Time (Gesamtzeit): Wie lange dauert es, bis ein Job fertig gerechnet wurde?
Ist die Summe aus Rechenzeit, Wartezeit in der READY-Queue und I/O Wartezeit
5.2.3 Interaktive Systeme
Waiting Time (Wartezeit): Wie lange muss ein Prozess warten? Scheduling kann nicht die
Rechenzeit beeinflussen, sondern nur die Wartezeit.
• Response Time (Antwortzeit): Zeit, bis die erste Response vom System kommt.
Turnaround-Time beschreibt die Beendigung des Jobs; in interaktiven Systemen ist oft die
Zeit bis zur ersten Antwort wichtig (entscheidend für die Schnelligkeit aus User-Sicht).
•
5.2.4 Echtzeit-Systeme
Erfüllung von Zeitvorgaben: Ein Echtzeitsystem muss die vorgegebenen Fristen (Deadlines)
erfüllen.
• Vorhersagbarkeit: Vermeidung von Qualitätsverlusten, z.B. in Multimedia-Systemen.
•
5.3 Algorithmen
5.3.1 First Come First Served Scheduling (FCFS)
Algorithmus:
Die Jobs werden in der Reihenfolge ausgeführt, in der sie READY werden. Jeder Job läuft bis
er blockt oder terminiert, dann startet der nächste.
letzter
nächster
aktiv
P3
P5
P1
P2
P4
P4
P3
P5
P1
P2
Abbildung 44: FCFS Warteschlange
Der Algorithmus ist nicht-preemptive.
Implementierung: als FIFO-Queue.
• Nachteil: durchschnittliche Wartezeit ist lang.
•
•
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 57 of 170
- 57 -
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Abschnitt 5 “CPU Scheduling“
Beispiel:
Gegeben seien folgende Prozesse mit ihren Burst-Zeiten:
Prozess
Burst Zeit
P1
24 m
P2
3 ms
P3
3 ms
Annahme: Alle Prozesse werden gleichzeitig READY:
P1
3
0
P2
P2
6
P3
24
P3
27
30
P1
Abbildung 45: FCFS Beispiel
Je nach Reihenfolge ergeben sich folgende Auswertungen:
•
•
Auswertung
Reihenfolge P1, P2, P3
P2, P3, P1
Durchschnittliche Wartezeit
(0+24+27) / 3 = 17 ms
(0+3+6) / 3 = 3 ms
Große Unterschiede in der Wartezeit, generell schlechte Performance
Führt zu schlechter Ausnutzung des Rechners:
Konvoi-Effekt:
Annahme: ein CPU-intensiver Job und mehrere I/O intensive Jobs.
Der CPU-intensive Job blockiert die CPU für lange Zeit; alle anderen Prozesse sind idle. Blockt
der CPU-intensive Job doch einmal aufgrund von I/O, dann kommen alle anderen Jobs der
Reihe nach dran; da diese jedoch I/O intensiv sind, gehen sie schnell in den Wartezustand
über. Dann kommt wieder der CPU-intensive Job dran, und alle anderen Warten.
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 58 of 170
- 58 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 5 “CPU Scheduling“
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Annnahme:
• P1 CPU intensiv,
• P2 und P3: I/O intensiv
P1
P2
P3
I/O
I/O Anforderung
I/O Anforderung
I/O Anforderung
Idle
Antwort P1
Antwort P2
Wartezeit
P3
Wartezeit
P2
Antwort P3
Abbildung 46: Konvoi Effekt bei FCFS
5.3.2 Shortest Job First Scheduling (SJF)
Algorithmus:
Der Job mit dem kürzesten CPU-Burst wird als nächstes drangenommen.
•
Minimiert die Wartezeit: durchschnittliche Wartezeit ist kurz (sogar optimal unter der
Bedingung dass alle Jobs zum gleichen Zeitpunkt ankommen)
Nachteile:
• Starvation (Verhungern) von CPU-intensiven Prozessen möglich: es werden immer
Prozesse mit kurzen CPU-Bursts vorgezogen, ein Prozess mit sehr langem CPU-Burst kann
verhungern
• Länge des nächsten CPU-bursts i.a. nicht bekannt, deshalb so nicht zu implementieren.
Schätzung der Länge aus bisherigen Daten,z.B. Exponentielles Mittel der bisherigen CPU
Bursts, mit 0 £ a £ 1:
tn+1 = a tn +(1-a)tn
Typischerweise a = ½.
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 59 of 170
- 59 -
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Abschnitt 5 “CPU Scheduling“
Auch mit Preemption möglich:
Definition Shortest Remaining Time Next (SRTN, auch Shortest Remaining Time First SRTF):
Wenn ein neuer Job READY wird, der eine kürzere verbleibende CPU Burst-Zeit hat als der
aktuelle, so unterbricht er den aktuellen.
5.3.3 Round-Robin Scheduling (RR)
Algorithmus:
Jeder Prozess bekommt eine Zeitscheibe (Time-Quantum) zugeteilt, z.B. 10ms. Wenn der
aktive Prozess sein Quantum aufgebraucht hat, wird er unterbrochen (preempted), und ein
anderer Prozess wird aktiv. Blockiert ein Prozess vor Ende des Quantums, so wird wie FCFS
geschedult.
•
•
•
•
Preemptiver Algorithmus
Sehr einfach: Verkettete Liste, wie FCFS (siehe Graphik bei FCFS)
Einziger Parameter: Länge des Time-Quantums
Verhindert Konvoi-Effekt, da lange Prozess-Bursts unterbrochen werden
Beispiel:
Gegeben seien wieder folgende Prozesse mit ihren Burst-Zeiten:
Prozess
Burst Zeit
P1
24
P2
3
P3
3
Zeitscheibe (Quantum): 4ms
P1
0
P2
4
P3
7
P1
10
P1
14
P1
P1
22
18
P1
26
30
Abbildung 47: Round-Robin Beispiel
•
Wartezeit: 6 ms (P1) + 4 ms (P2) + 7 ms (P3) = 17 ms, durchschnittliche Wartezeit:
17/3 = 5.66 ms
Nachteil:
Zusätzliche Scheduler-Aufrufe und Kontextwechsel kosten Zeit:
Beispiel:
CPU Burst des Prozesses: 100 ms
Beispiel A: Zeit Scheduler-Aufruf 1 ms
Beispiel B: Zeit Scheduler-Aufruf 5 ms
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 60 of 170
- 60 -
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Abschnitt 5 “CPU Scheduling“
Graphik
Quantum Kontextwechsel
Verschwendung Bsp. A
Verschwendung Bsp. B
120 ms
0
0
0
60 ms
1
1 ms = 1%
5 ms = 5 %
10 ms
9
9 ms = 9 %
45 ms = 45 %
Time-Quantum:
• zu kurz: Verschwendung durch zuviele Kontextwechsel
• zu lang: kein Job wird unterbrochen, Round-Robin degeneriert zu FCFS
5.3.4 Prioritäten-Scheduling
Algorithmus:
Jeder Prozess erhält eine weitere Eigenschaft, die Priorität. Es wird derjenige Prozess mit der
höchsten Priorität ausgewählt.
Beispiel: Batch-Betrieb an der FH
Jobs von Studenten: Priorität 30
Jobs von Assistenten: Priorität 40
Jobs von der Verwaltung: Priorität 50
Jobs von Professoren: Priorität 60
•
•
•
Achtung: manchmal bedeuten höhere Prioritäten höhere Zahlen, manchmal niedrigere.
Bei mehreren Prozessen mit derselben Priorität: FCFS möglich, oder RR.
Prioritäten können statisch vergeben werden (bei Prozessstart), oder dynamisch angepasst
werden.
Prozess
Burst Zeit
Priorität
P1
10 ms
3
P2
1 ms
1
P3
2 ms
4
P4
1 ms
5
P5
5 ms
2
(niedrige Zahlen = hohe Priorität)
Reihenfolge (und Startpunkte): P2 (0 ms), P5 (1 ms), P1(6 ms), P3(16 ms), P4(18 ms)
Durchschnittliche Wartezeit: 41 ms/5=8.2 ms
Problem: Starvation (Aushungern)
Prozesse mit niedriger Priorität können “verhungern”, d.h. niemals drankommen. (Gerücht:
IBM 7094 bei MIT im Jahre 1973: ein niedrig-priorer Job lief seit 1967...)
Abhilfe:
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 61 of 170
- 61 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 5 “CPU Scheduling“
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
“Altern”, d.h. dynamische Prioritätenvergabe; je länger ein Prozess wartet, umso mehr wird
seine Priorität heraufgesetzt, oder alternativ: je mehr ein Prozess rechnet, desto mehr wird
seine Priorität herabgesetzt. Irgendwann ist seine Priorität so hoch, dass er drankommt.
5.3.5 Multilevel Queue Scheduling
Problem: Unterscheidung von CPU-intensiven und I/O-intensiven Prozessen
1. Möglichkeit: Priorität invers zur Länge des CPU-bursts:
• I/O-intensive Prozesse haben kurze CPU-bursts -> erhalten eine hohe Priorität
• CPU-intensive Prozesse -> niedrige Priorität
• Stellt sicher, dass I/O-intensive Prozesse oft drankommen
Möglichkeit: Multilevel Queues
Algorithmus: Multilevel-Queues
Die Prozesse werden in verschiedene Queues eingeteilt, die unterschiedliche Prioritäten
haben.
• System-Prozesse (höchste Priorität)
• Interaktive Prozesse
• Interaktive Editier-Prozesse
• Batch-Prozesse
• Studenten-Prozesse (niedrigste Priorität)
2-stufiges Scheduling:
Zunächst Auswahl der höchsten nicht-leeren Prioritätsklasse; innerhalb dieser Klasse FCFS
oder RR.
Multilevel Queue Scheduling mit Feedback
Die Einteilung der Prozesse in verschiedene Queues wird mit der Zeit angepasst.
quantum = 8
Prio = 1
Prio = 2
quantum = 16
Prio = 3
FCFS
Abbildung 48: Multilevel Feedback Queue (nach [2])
Beispiel:
• Ein Prozess startet in der höchst-prioren Quantum Queue mit Zeitquantum 8. I/O intensive
Prozesse brauchen ihr Zeitquantum nicht auf; sie verbleiben in dieser Queue. CPUFile: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 62 of 170
- 62 -
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Abschnitt 5 “CPU Scheduling“
intensive Prozesse brauchen ihr Zeitquantum auf und werden in die nächste Queue weiter
geschoben.
• Wird der Prozess in der mittleren Queue ebenfalls unterbrochen, d.h. ist er sehr CPUintensiv, so wird er in die niedrigt-priore Queue verschoben.
• Wechselt ein Prozess sein Verhalten, z.B. von CPU-intensiv zu I/O-intensiv, so kann er
wieder in eine höher-priore Queue eingestuft werden.
5.3.6 Realtime Scheduling: Rate-Monotonic Scheduling (RMS)
5.3.6.1 Hard-Realtime
Definition:
Alle Prozesse müssen innerhalb der vorgegebenen Zeit beendet werden.
• Beispiel: ABS Bremssystem, Airbag-Auslöser (eine gelegentliche Überschreitung der Fristen
ist inaktzeptabel)
• Ist schwierig zu garantieren
5.3.6.2 Soft-Realtime
Weniger strenge Anforderungen: Zeitliche Vorgaben sollten eingehalten werden. Ein
Überschreiten der Fristen stellt zwar ein Qualitätsverlust dar, ist jedoch noch kein
Totalausfall.
• Beispiel: Video-Player, der ab und zu ein Bild “auslässt”
• typischerweise durch hohe Prioritäten für Realtime-Prozesse
5.3.6.3 Rate-Monotonic Scheduling
Für periodische Aktivierungen von Prozessen
Definition:
Prioritäten-basiertes Scheduling, wobei die Priorität des Prozesses umso höher ist je kürzer
die Periode ist
Ausführbarkeit (Schedulability), System mit Preemption:
Gegeben seien n Prozesse mit den (worst-cast) Laufzeiten c1, ... cn und den jeweiligen
Perioden p1, ..., pn. Eine Bedingung für die Ausführbarkeit ist (bei Preemption) ist:
n
U =∑
i=1
ci
1
pi
Beispiel:
Gegeben seien 3 periodische Prozesse P1, P2 und P3 mit:
Prozess
Periode (ms)
Worst-case
Dauer (ms)
Prio1
P1
100
50
1
P2
200
30
2
P3
500
100
5
Niedrige Zahlen = hohe Priorität
1
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 63 of 170
- 63 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 5 “CPU Scheduling“
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Dann ergibt sich
U=
30 100
50
=0.50.150.2=0.851
100 200 500
Annahme: Aktivierung von
• P1 bei 50, 150, 250, ...
• P2 bei 66, 266, 466,
• P3 bei 0, 500, 1000, ...
Dann ergibt sich folgendes Aktivierungsschema:
P1
P2
P3
0 ms
100 ms
200 ms
300 ms
400 ms
500 ms
600 ms
700 ms
800 ms
900 ms
Abbildung 49: RMS Aktivierungsschema (Beispiel)
Dies reicht jedoch nicht aus, um die Ausführbarkeit aller Deadlines zu garantieren.
Eine untere Grenze ergibt sich aus:
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 64 of 170
- 64 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 5 “CPU Scheduling“
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Gegeben seien n Prozesse mit den (worst-cast) Laufzeiten c1, ... cn und den jeweiligen
Perioden p1, ..., pn. Eine Bedingung für die Ausführbarkeit ist (bei Preemption) ist:
n
U =∑
i=1
ci
n21/n­1
pi
5.3.6.4 Problem: Prioritäteninversion
1. Ein niedrig-priorer Prozess P1 ist aktiv und allokiert eine Resource A
2. Ein mittel-priorer Prozess P2 wird aktiv und unterbricht P1
3. Ein hoch-priorer Prozess P3 wird aktiv, P2 wird unterbrochen
4. P3 benötigt die Resource A und geht in den Wartezustand über
5. Als nächstes rechnet P2 zum Ende
6. Dann erst kommt P1 dran: P1 rechnet weiter und gibt A wieder frei
7. Nun erst kommt P3 (höchst-prior) wieder dran und unterbricht P1
Folge: P2 hat vor P3 fertiggerechnet, obwohl die Priorität von P2 niedriger ist als die von P3!
Mögliche Alternativen:
• Priority Inheritance: warten ein oder mehrere Prozesse auf eine Resource, die ein anderer
Prozess gelockt hat, so erhält dieser Prozess kurzzeitig die Priorität des höchsten
wartenden Prozesses
• Priority Ceiling: Für jede Resource wird im Vorfeld eine Ceiling-Priorität festgelegt, die
höher ist als die jeden Prozesses der diese Resource zu irgendeinem Zeitpunkt nutzen will.
Ein Prozess, der die Resource aquiriert, erhält automatisch die Ceiling-Priorität.
5.3.7 Evaluierung der Algorithmen
Um den geeignetsten Algorithmus auswählen zu können, werden diese evaluiert. Ein
wichtiges Mittel dazu sind Simulationen, die auf aktuellen Szenarien beruhen.
5.4 Thread Scheduling
Mit Threads haben wir zwei ausführbare Einheiten im System.
Unterschiede bei User-level Threads (many-to-one) und Kernel-Threads (one-to-one):
• Bei User-level Threads (many-to-one) kennt der Scheduler keine Threads. Er teilt die CPU
jeweils einem Prozess zu; der User-level-Scheduler führt dann verschiedene Threads aus.
Beispiel: Time-Quantum 50ms (für Prozesse), 10ms für User-level threads:
Kernel schedult Prozess A: A1, A2, A3, A1, A2, dann Prozess B: B1, B2, B3, B1, B2
• Bei Kernel-level Threads (one-to-one) kennt der Kernel-Scheduler die Threads und schedult
diese einzeln:
Beispiel: Thread-Quantum 20ms: A1, B1, A2, B2, A3, B3, A1, ...
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 65 of 170
- 65 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 5 “CPU Scheduling“
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Abbildung 50: Overview Thread Scheduling (nach [1])
Unterschiede:
• User-level Thread Scheduling:
• Vorteil: ist schnell, da kein Prozesswechsel stattfindet
• Nachteil: Blockiert ein Thread, wird der gesamte Prozess -> WAITING und alle
anderen Threads blockieren auch
• Alle Threads eines Prozesses laufen in derselben Prioritätsklasse
• Kernel-level Thread Scheduling:
• Kontextwechsel erforderlich -> schlechtere Performance
• Threads eines Prozesses können unterschiedlich geschedult werden ->
unterschiedliche Prioritäten möglich
• Kernel kann Threads und Prozesse berücksichtigen
5.5 Beispiele
Generell gilt: ein gutes Scheduling für allgemeine Rechner erfordert viel Alchemie: man liest
oft so Sachen wie “kurzzeitig um 3 Prioritätsstufen erhöhen” (Win 2000), oder bei Linux: “im
einen Fall um zwei Einheiten erniedrigen, andernfalls verdoppeln” - wo kommen diese Zahlen
her? Erfahrungswerte, gewonnen aus vielen verschiedenen Simulationen. Gutes Scheduling
= Kompromiss zwischen vielen verschiedenen, sich widersprechenden Anforderungen.
5.5.1 Solaris 2
Prioritäts-basiertes Scheduling mit 4 Klassen:
1. Real-time: garantierte Antwortzeit (nur sehr wenige Prozesse), FCFS
2. System: Reserviert für Kernel-Use FCFS
3. Time-sharing
4. Interaktive
Realtime hat die höchste Priorität, gefolgt von System. Time-Sharing und Interaktive haben
dieselbe Priorität.
Interaktive und Time-Sharing benutzen Multilevel-Feedback-Queue mit Round-Robin, wobei
Interaktive für Fenster-Applikationen (Response) optimiert ist, während Time-Sharing für
CPU-intensive Prozesse optimiert ist.
Scheduler: ein Prozess läuft bis
• er blockiert
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 66 of 170
- 66 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 5 “CPU Scheduling“
•
•
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
sein Zeit-Quantum abgelaufen ist (nicht Realtime- und System-Threads)
er durch einen höher-prioren Thread unterbrochen wird.
Klasse
Priorität
Scheduler
Bemerkungen
Realtime
Höchste
FCFS
Realtime-Kernel Threads
System
Hoch
FCFS
Kernel-Threads
Interaktive
Normal
MultilevelFeedback-Queue
Optimiert für interaktive
Anwendungen
Time-Sharing
Optimiert für CPU-intensive
Prozesse
5.5.2 Windows 2000
•
•
•
•
•
•
Scheduler nutzt ein 32-Stufen Prioritätsschema:
• 16-31: Realtime Prioritäten
• 1-15: Variable Klasse Prioritäten
• 0: Idle-Prozess und Swapper
Für jede der 32 Prioritäten gibt es eine eigene READY-Queue; der Scheduler aktiviert
jeweils den nächsten Job aus der höchsten, nicht-leeren Queue.
Wenn es keinen READY-Job gibt, wird der Idle-Thread ausgeführt.
Beendet ein Thread den WAITING-Zustand, so erhält er einen Boost: bessere Performance
für interaktive Prozesse, die oft auf Tastatur und Maus warten.
Wenn ein Thread aus der variablen Klasse sein Time-Quantum aufgebraucht hat, so wird
seine Priorität in gewissen Grenzen erniedrigt. Dadurch werden CPU-intensive Prozesse
etwas gebremst.
Win2K unterscheidet zwischen Foreground und Background-Prozessen. Erstere erhalten
einen Performance-Bonus.
5.5.3 Linux (Kernel < 2.6)
Zwei unterschiedliche Prozess-Scheduling Algorithmen:
• ein fairer preemptiver Algorithmus für normale Prozesse
• und ein prioritäsbasierter für zeitkritische Prozesse
• Kredit-basierter Algorithmus:
• jeder Prozess erhält einen bestimmten Kredit
• der Prozess mit dem höchsten Kredit wird ausgewählt
• Hat kein Prozess mehr einen Kredit, so erhalten alle (auch die im WAITING-Zustand)
Prozesse zusätzliche Kredite nach der Formel
credits = credits/2 + priority
(gibt I/O-intensiven und interaktiven Prozessen mehr Kredits)
• 2.6-Kernel: anderer Scheduler
•
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 67 of 170
- 67 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Abschnitt 6 “Prozesssynchronisierung“
6 Prozesssynchronisierung
Zusammenarbeitende Prozesse haben sich gemeinsame Daten:
• Threads (LWPs) teilen sich gesamten Prozessraum
• Prozesse haben entweder gemeinsamen (shared) Speicher oder teilen sich Dateien
Problem: Inkonsistenzen in (Verwaltungs-)Daten durch zeitlich überlagerte Zugriffe
nebenläufiger Prozesse auf diesselben Daten.
Verallgemeinert: nebenläufiger Zugriff auf geteilte Resourcen
Nebenläufigkeit:
• Mehrprozessor-System: Prozessoren bearbeiten unabhängig voneinander verschiedene
Prozesse
• Einprozessor-System und Mehrprozessor-System: Interrupt kann asynchron zum
Prozessablauf die Bearbeitung einer Unterbrechungsroutine bewirken. Prozessumschaltung
kann unvorhergesehen im Prozessablauf auftreten.
Beispiel: Banksystem, Einzahlung und Abhebung laufen nebenläufig
• Kontostand: 1000 EUR
• Einzahlung von 3000 EUR
• Abhebung von 500 EUR
Zeit
Prozess 1: Einzahlung
Prozess 2: Abhebung
T0
Liest: Kontostand 1000 EUR -
T1
-
Liest: Kontostand 1000 EUR
T2
-
Bucht: -500 EUR
T3
-
Schreibt: Kontostand 500 EUR
T4
Bucht: +3000 EUR
-
T5
Schreibt: 4000 EUR
-
Kontostand ist 4000 EUR, richtig wäre 3500 EUR!
Die Transaktion „Lesen-Buchen-Schreiben“ wird als kritischer Abschnitt oder kritischer
Bereich bezeichnet.
Definition Wettlauf (Race-Condition):
Eine Situation, in der mehrere Prozesse auf gemeinsame Daten zugreifen und in der das
Ergebnis von der – zufälligen – Reihenfolge der einzelnen Befehle abhängt, heisst RaceCondition (Wettlaufsituation).
Um einen Wettlauf zu verhindern, müssen wir gewährleisten, dass nur ein Prozess zu einer
Zeit Zugriff auf die Variable hat -> Prozess-Synchronisierung
Beispiel: Produzenten-Consumer-System
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 68 of 170
- 68 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 6 “Prozesssynchronisierung“
•
•
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Der Produzent erzeugt Daten, die vom Consumer verarbeitet werden
Für den Datenaustausch wird ein Datenpuffer verwendet:
• Datenpuffer bietet die Funktionen insert_item() und remove_item()
• Maximale Größe des Datenpuffers: N
• Implementiert z.B. als Array:
const int N=100;
int buffer[N];
int in = 0;
int out = 0;
// Zeider auf nächster freier Pufferplatz zum Schreiben
// Zeiger auf nächster Element zum Lesen
void insert_item( int item ) {
buffer[in] = item;
in = (in+1) % N;
}
int remove_item( ) {
int retItem;
retItem = buffer[out]
out = (out+1) % N;
return retItem;
}
•
Der Produzent- und der Consumer-Prozess greifen auf den Puffer zu; sie müssen die
Anzahl der Elemente im Puffer selbst verwalten2
Zählvariable (gemeinsam für Producer und Consumer):
int counter;
Produzent-Prozess:
while(1) {
// warte, falls Puffer voll ist
while( counter==N )
; // tue nix
insert_item( item );
counter++;
}
Consumer-Prozess:
while(1) {
// warte, bis ein Element im Puffer bereit steht
while( counter==0 )
; // tue nix
item = remove_item();
counter--;
}
Dies ist ein schlechtes Design. Ein guter Datenpuffer würde seine Größe selbst verwalten, und das
nicht den benutzenden Programmen überlassen. Was aber soll der Puffer machen, wenn er überfüllt
wird? Zur Verdeutlichung müssen in den Beispielen der P- und der C-Prozess selbst die Anzahl der
Elemente im Puffer überwachen.
2
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 69 of 170
- 69 -
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Abschnitt 6 “Prozesssynchronisierung“
Beide Prozesse sind für sich genommen richtig, zusammen ergibt sich jedoch ein Fehler!
• Der P-Prozess führt counter++ aus, das im Assembler etwa so implementiert wird:
P1: Lies Register1 ein aus Speicher counter
P2: Erhöhe Register1 um 1
P3: Speichere Register1 nach Speicher counter
•
Der C-Prozess führt counter-- aus, das im Assembler etwa so implementiert wird:
C1: Lies Register2 ein aus Speicher counter
C2: Erniedrige Register2 um 1
C3: Speichere Register2 nach Speicher counter
Annahme: counter hat den Wert 5
Mögliche Abläufe:
Tabelle 4: Ablauf 3 (falsch)
Tabelle 2: Ablauf 1 (korrekt)
Schritt Register1 Register2 Counter
Schritt
Register1
Register2
Counter
??
??
5
P1
5
??
5
5
P2
6
??
5
??
6
C1
Unverändert 5
5
??
6
6
C2
Unverändert 4
5
C2
??
5
6
P3
6
C3
??
5
5
C3
Unverändert 4
??
??
5
P1
5
??
5
P2
6
??
P3
6
C1
Unverändert 6
4
Tabelle 3: Ablauf 2 (falsch)
Schritt
Register1
Register2 Counter
??
??
5
P1
5
??
5
P2
6
??
5
C1
Unverändert 5
5
C2
Unverändert 4
5
C3
Unverändert 4
4
P3
6
6
??
Problem: beide Prozesse verändern die Variable counter zur selben Zeit.
6.1 Kritische Bereiche (Critical Section)
Gegeben seien n Prozesse { P0, P1, ... PN-1 }. Jeder Prozess hat einen kritischen CodeBereich (Critical Section), in dem er gemeinsame Daten liest oder verändert, Dateien
beschreibt, etc.
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 70 of 170
- 70 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Abschnitt 6 “Prozesssynchronisierung“
Nach Dijkstra ist zu beachten:
1. Gegenseitiger Ausschluss (Mutual exclusion): Wenn ein Prozess Pi in seinem kritischen
Bereich ist, dann darf kein anderer Prozess in seinem kritischen Bereich laufen.
2. Es dürfen keine Annahmen über die Abarbeitungsgeschwindigkeit Anzahl der Prozesse
bzw. Prozessoren gemacht werden.
3. Kein Prozess der ausserhalb seines kritischen Bereiches läuft, darf einen anderen Prozess
blockieren.
4. Gerechtigkeit (Fairness Condition): Jeder Prozess, der am Eingang eines kritischen
Abschnittes wartet, muss garantiert werden, dass er den KA irgendwann betreten darf
(kein ewiges Warten)
Abbildung 51: Schema kritischer Bereich
Allgemeine Struktur:
• Eintrittsbereich
• Kritischer Bereich
• Austrittsbereich
• Verbleibender Bereich
Critical-Section-Problem: Wie muss ein Verfahren aussehen, um Datenkonsistenz zu
garantieren?
6.2 Lösungen
6.2.1 Abschalten der Interrupts
Einfachste Lösung: Interrupts im kritischen Bereich abschalten.
Keine Interrupts->kein Prozesswechsel
• Wird häufig in einfachen Echtzeit-Systemen verwendet,
• oder innerhalb des Kernels für kritische Bereiche
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 71 of 170
- 71 -
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Abschnitt 6 “Prozesssynchronisierung“
Aber: Abschalten der Interrupts im User-Prozess: was passiert, wenn das User-Programm in
eine Endlosschleife geht? -> Das gesamte OS bleibt stehen!
6.2.2 Zwei-Prozess Lösungen
6.2.2.1 Software-Lösung Versuch 1: Sperr-Variable (lock variable)
Wir verwenden eine Schutz-Variable:
int lock=0;
L1:
L2:
L3:
L4:
L5:
while (lock!=0 )
;
lock = 1;
// in KA: tue irgendwas
lock = 0;
// warte bis KA frei ist
// tue nix
// wir betreten KA: zunächst sperren
// KA verlassen
Definition Spin Lock:
Eine Sperre, die in einer Warteschleife auf die Freigabe wartet, heisst Spin-Lock.
L1-L3: EnterCriticalSection
L4: LeaveCriticalSection
Problem: funktioniert so nicht!
Sei lock = 0:
Zeit
P1
P2
T0
L1
-
T1
-
L1
T2
-
L3
T3
-
L4
T4
L3
-
T5
L4 Fehler!
6.2.2.2 Lösungsversuch 2: Abwechselnder Zugang (strict alternation)
Wir verwenden eine Anzeiger-Variable. Jeder Prozess kommt abwechselt dran.
Gegeben: Zwei Prozesse, jeder bekommt eine Nummer zugeteilt (0 oder 1):
Prozess i (i=0 oder i=1):
L1:
L2:
L3:
L4:
while (turn!=i)
;
// in KA: tue irgendwas
turn = 1 – i;
// warte bis ich an der Reihe bin
// tue nix
// KA verlassen
Mutual Exclusion: ok, da nicht beide Prozesse gleichzeitig in der KA sein können!
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 72 of 170
- 72 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 6 “Prozesssynchronisierung“
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Fairness: Nein, da die Prozesse können nur abwechselt drankommen:
• Wenn als Prozess 0 in der KA war, ist turn=1
• Kommt nun P0 wieder in die KA, muss er warten!
• Dies wiederspricht Forderung 3: Kein Prozess darf auf einen anderen warten, der nicht in
der KA ist!
6.2.2.3 Peterson's Lösung
Kombination aus den beiden vorigen Lösungen:
• Feld von zwei Variablen flag[0] und flag[1] zeigt an, dass ein Prozess den KA betreten will
• Eine turn-Variable entscheidet, welcher von beiden drankommt
Peterson's Lösung (nach [2]):3
// Zwei Prozesse P0 und P1
int turn;
// Wechselnder Zugang, Initialisierung egal
int flag[2];
// Zutrittswunsch
// Prozess i (i=0 oder 1)
int other = 1 - i;
L1:
L2:
L3:
L4:
L5:
L6:
L7:
// melde Wunsch an
flag[i] = TRUE;
// anderer Prozess hat Vortritt
turn = other;
// bin ich der einzige?
while (flag[other]
&& (turn==other))
; // tue nix
// in KA: tue irgendwas
// KA verlassen
flag[i]=FALSE;
In der Vorlesung vom 3.5.2004 habe ich die Lösung nach Tanenbaum präsentiert, die sich in der
Benutzung der turn-Variable unterscheiden. Beide Lösungen sind richtig, und der Beweis ist derselbe.
3
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 73 of 170
- 73 -
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Abschnitt 6 “Prozesssynchronisierung“
Beweis:
Zu Verdeutlichung hier der Code für die beiden Prozesse P0 und P1:
int turn=0;
int flag[2];
// Wechselnder Zugang
// Zutrittswunsch
// Prozess 0
L1:
L2:
L3:
L4:
L5:
L6:
L7:
// melde Wunsch an
flag[0] = TRUE;
// P1 hat Vortritt
turn = 1;
// bin ich der einzige?
while (flag[1]
&& (turn==1))
; // tue nix
// in KA: tue irgendwas
// KA verlassen
flag[0]=FALSE;
L1:
L2:
L3:
L4:
L5:
L6:
L7:
// Prozess 1
// melde Wunsch an
flag[1] = TRUE;
// P0 hat Vortritt
turn = 0;
// bin ich der einzige?
while (flag[0]
&& (turn==0))
; // tue nix
// in KA: tue irgendwas
// KA verlassen
flag[1]=FALSE;
Wir müssen zeigen:
1. Mutual Exclusion – nur ein Prozess kann zu einem Zeitpunkt in der KA sein.
• Es reicht zu beweisen, dass wenn ein Prozess in der KA ist, der andere diese nicht
betreten kann. Annahme: P0 ist in KA, P1 nicht.
• Dann gilt: flag[0]=TRUE.
• Sei tx der Zeitpunkt, an dem P0 die KA betreten hat, d.h. zu tx wurde die whileSchleife verlassen wurde.
• Fall 1: Zum Zeitpunkt tx war flag[1]=FALSE. Dann kann P1 die KA nicht betreten,
da es selbst turn=0 setzt.
• Fall 2: Zum Zeitpunkt tx war flag[1]=TRUE.
• Fall 2a: Falls turn=0, dann kann P1 den KA nicht betreten.
• Fall 2b: Falls turn=1, dann kann P0 den KA nicht betreten haben => Widerspruch
zur Annahme, dass P0 in KA ist!
• Nach tx kann P1 die KA nicht betreten, da flag[0]=TRUE und turn=0 ist solange
P0 in der KA ist.
2. Keine Annahmen über Geschwindigkeit, etc.
3. Blockierung:
• Wenn ein Prozess i die KA verlässt, so setzt er flag[i]=FALSE, und somit blockiert
er den anderen Prozess nicht mehr
4. Fairness: jeder Prozess kommt in endlicher Zeit dran.
• Dazu reicht es zu zeigen: Wenn P1 auf Zutritt in die KA wartet, dann kommt es
auch irgendwann (nach endlicher Zeit) dran).
• Annahme: P1 wartet an der Schleife
• Dann gilt: flag[0]=TRUE und turn=0.
• Wenn P0 in der KA ist, dann wird es diese irgendwann verlassen -> flag[0]
=FALSE -> P1 kann KA betreten
• Will in der Zwischenzeit P0 wieder die KA betreten, so führt es L1 aus: flag[0] ist
wieder TRUE. Im nächsten Schritt wird jedoch turn=1, so dass auf jeden Fall
zunächst P1 drankommt!
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 74 of 170
- 74 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Abschnitt 6 “Prozesssynchronisierung“
6.2.3 Test And Set Lock (TSL)
Einfache Lösung für ein Lock durch Hardware Unterstützung!
Spezielle Hardware-Anweisung TSL RX, LOCK (TSL=“Test and Set Lock”):
• Liest den Speicherinhalt an der Stelle LOCK in das Register RX ein und speicht einen Wert
ungleich Null an der Stelle LOCK ab
• Die gesamte Operation ist unteilbar – kein anderer Prozess (oder Prozessor) kann auf die
Speicheradresse zugreifen solange die Anweisung nicht beendet wurde
• Bei mehreren CPUs sperrt die zugreifende CPU kurzzeitig den Speicherbus und verhindert
so einen Zugriff der anderen CPUs
Wie kann man damit einen kritischen Bereich schützen?
• Wir benutzen eine gemeinsame Variable lock als Sperrvariable.
• Wenn lock Null ist, kann jeder Prozess die Variable auf 1 setzen und den kritischen Bereich
betreten.
• Ist lock jedoch nicht Null, so wartet der Prozess bis lock Null ist
enter_region:
TSL RX, LOCK
CMP RX,#0
JNE enter_region
RET
|
|
|
|
leave_region:
MOVE LOCK,#0
RET
| set lock to zero
| done
copy lock to register
was lock zero?
no -> loop
return to caller: enter critical section
6.2.4 Sleep And Wakeup
Nachteil der bisherigen Lösungen: “busy wait”, d.h. der Prozess läuft in einer Endlosschleife!
Auf einem Uniprozessor-System ist das Zeitverschwendung!
Definition Spin-Lock:
Ein Spin-Lock ist eine Sperre, an der ein Prozess in einer Schleife auf den Zugang zu einem
kritischen Abschnitt wartet.
•
Bei den bisherigen Beispielen handelt es sich um ein Spin-Locks
Was wäre besser? Anstelle in einer “Endlosschleife” zu laufen, sollte der Prozess schlafen
gelegt werden und ein anderer Prozess aufgeweckt werden!
-> sleep-Befehl und wakeup-Befehl
• sleep() ohne Parameter, wakeup() mit Angabe der PID (oder Thread-ID)
• oder Zuordnung über einen eindeutigen Parameter: sleep(void*) und wakeup(void*)
Produzenten-Prozess: (hat ein neues Element in nextProduced)
while(1) {
// L1: warte, falls Puffer voll ist
if( counter==N ) sleep();
insert_item( item );
counter++;
// Falls Queue leer war: wecke Consumer auf
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 75 of 170
- 75 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Abschnitt 6 “Prozesssynchronisierung“
}
if(counter==1)wakeup(consumer);
Consumer-Prozess: (liest ein Element nach nextConsumed aus)
while(1) {
// warte, bis ein Element im Puffer bereit steht
if( counter==0 ) ª sleep();
item = remove_item();
counter--;
// Falls Queue voll war: wecke Produzent auf
if( counter==BUFFER_SIZE-1 ) wakeup(producer);
}
Achtung! Obiger Code hat einen fatalen Fehler:
• Der Produzent liest in L1 die Counter-Variable ein und testet, ob der Puffer voll ist.
• Angenommen, der Puffer ist voll. Dann legt sich der P-Prozess schlafen.
• Weiter angenommen, dass nach dem Vergleich, jedoch vor dem sleep-Befehl (markiert mit
ª) ein Prozesswechsel stattfindet.
• Nun kommt der C-Prozess dran: er nimmt ein Element aus der Queue, verarbeitet dieses
und weckt nun den P-Prozess auf. Da dieser jedoch nicht schläft, geht der wakeup-Befehl
ins Leere.
• Nach einem weiteren Prozesswechsel kommt wieder der P-Prozess dran: er legt sich
schlafen, und schläft nun für immer!
6.2.5 Semaphoren
Deshalb schlug Dijkstra (1965) eine weitere Lösung vor:
• Integer-Variable, welche die Anzahl der Wakeup-Signale zählt
• Eine Semaphore hat den Wert Null, wenn keine Wakeup-Signale vorliegen, oder einen
positiven Wert der der Anzahl der noch nicht verarbeiteten Wakeups entspricht
• Dijkstra schlug zwei Operationen vor, up() und down() (bzw. P() für holl. proberen, testen
und V() verhoegen, erhöhen)
• Die Operation down() prüft, ob der Wert der Integer-Variable größer Null ist:
• Falls ja, wird die Variable um eins erniedrigt, und das Programm rechnet weiter.
• Ist die Variable Null, so wird der Prozess schlafen gelegt
• Die Operation up() erhöht den Wert der Semaphore um eins. Falls ein oder mehrere
Prozesse auf die Semaphore warten, so wird einer vom System ausgewählt und er darf
seine down()-Operation beenden. Die Semaphore wird dann wieder den Wert Null haben,
dafür wartet jedoch ein Prozess weniger auf die Semaphore.
• Die Operationen up() und down() müssen atomar, d.h. unteilbar sein. Wenn ein Prozess ein
up() oder down() auf eine Semaphore durchführt, so darf kein anderer Prozess auf die
Semaphore zugreifen.
Beispiel: Mutual Exclusion mit Semaphoren
semaphore s(1);
// initialisiere Semaphore mit 1
// Prozess rechnet
// ...
down(s);
// ....
up(s);
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
// Eintritt in den kritischen Abschnitt
Kritischer Abschnitt
// kritischen Abschnitt verlassen
Page 76 of 170
- 76 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Abschnitt 6 “Prozesssynchronisierung“
•
Binäre Semaphore: Mutex (für Mutual Exclusion), hat nur zwei Werte: 0 und 1, wird für
gegenseitigen Ausschluss verwendet.
6.2.5.1 Implementierung
• Typischerweise als Systemaufruf
• Mutual Exclusion:
• Ein-Prozessor-System: Bei Zugriff auf die Semaphore werden kurzzeitig die
Interrutps gesperrt;
• Mehr-Prozessor-Lösung: mittels TSL-Anweisung
• Warten auf das Aufwachen
• Spin-Lock (Endlosschleife): ineffektiv
• besser: jede Semaphore verwaltet eine Liste der schlafenden Prozesse; ein up()
wählt einen Prozess aus der Liste auf und weckt ihn auf.
// Beispiel-Implementierung für Semaphore (Pseudo-Code)
// hier fehlt noch der Zugangsschutz für die Semaphore!
typedef struct {
int value;
struct process *p_list;
} semaphore;
void down(semaphore s)
{
s.value--;
if(s.value<0) {
// füge den Prozess zu der Warteschlange hinzu
// blockiere den Prozess
}
}
void up(semaphore s)
{
s.value++;
if( s.value<=0 ) {
// entferne einen Prozess von der Warteschlange
// wecke den Prozess auf!
}
}
6.2.5.2 Beispiel: Consumer-Producer mit Semaphore
Zwei Semaphoren für die Anzahl, eine Mutex um den Puffer zu schützen:
semaphore empty=N;
semaphore full=0;
semaphore mutex=1;
// Ist noch Platz in der Queue?
// Sind Elemente in der Queue verhanden?
// Puffer: gegenseitiger Ausschluss
Produzenten-Prozess: (hat ein neues Element in nextProduced)
while(1) {
// teste, ob Platz in der Queue ist
down(&empty);
// schütze Zugriff auf Puffer
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 77 of 170
- 77 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Abschnitt 6 “Prozesssynchronisierung“
}
down(&mutex);
insert_item( item );
up(&mutex);
// Ein weiteres Element ist in der Queue verfügbar
up(&full);
Consumer-Prozess: (liest ein Element nach nextConsumed aus)
while(1) {
// teste, ob ein Element verfügbar ist
down(&full);
// schütze Zugriff auf Puffer
down(&mutex);
item = remove_item();
up(&mutex);
// Ein weiteres Element hat Platz in der Queue
up(&empty);
}
Semaphoren werden im Beispiel für zwei verschiedene Zwecke verwendet:
1. Mutual Exclusion: mutex
2. Prozesssynchronisierung (Benachrichtigung durch Aufwecken): empty, full
6.2.6 Monitors
Semaphoren sind besser als bisherige Lösung, jedoch immer noch sehr kompliziert!
• Obiges Beispiel, P-Prozess: wenn down(&empty) und down(&mutex) vertauscht werden,
gibt es ein Deadlock!
• Deshalb haben Hoare (1974) und Brinch Hansen (1975) ein hochwertiges
Synchronisierungsmittel vorgeschlagen, genannt monitor
• Ein Monitor ist eine Gruppe von Funktionen, Variablen und Datenstrukturen, die in einem
Modul (oder Klasse) zusammengruppiert sind
• Datenkapselung: Prozesse können die Funktionen aufrufen, jedoch sind die inneren Daten
vor direktem Zugriff geschützt
• Beispiel (Pidgin-Pascal):
monitor example
integer i;
condition c;
procedure producer();
.
.
.
end;
procedure consumer();
.
.
.
end;
end monitor;
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 78 of 170
- 78 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Abschnitt 6 “Prozesssynchronisierung“
•
•
•
•
•
•
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Mutual exclusion: nur ein Prozess kann zu einer Zeit innerhalb des Monitors laufen. Dies
wird von der Programmiersprache sichergestellt.
Aber wie soll ein Prozess auf einen anderen warten? Zum Beispiel wenn der Produzent im
Producer-Consumer-Beispiel kein weiteres Element in der Queue ablegen kann?
Deshalb Einführung von condition-Variablen, mit zwei Operationen: wait() und signal().
Wenn ein Prozess 1 auf eine condition-Variable c warten will, so ruft er wait(c) auf. Der
Prozess 1 geht in den WAITING-Zustand über. Gleichzeitig kann der Monitor von einem
anderen Prozess P2 betreten werden.
Mittels signal(c) kann Prozess P2 den Prozess 1 wieder aufgewecken.
Es muss vermeiden werden, dass zwei aktive Prozesse im Monitor laufen:
• Lösung nach Hoare: der laufende Prozess P2 wird suspendiert, während der eben
erwachte Prozess P1sofort weiterläuft; verlässt P1 den Monitor, kann auch P2
wieder weiterrechnen.
• Lösung nach Brinch-Hansen: Der Prozess P2, der signal(c) aufruft, verlässt den
Monitor sofort; dann kann P1 im Monitor verbleiben.
• Weitere Lösung: P1 wird zwar aufgeweckt, kann jedoch er im Monitor
weiterrechnen, wenn P2 den Monitor verlassen hat (Java-Lösung)
Beispiel: Producer-Consumer mit Monitore (nach [1])
Monitor ProducerConsumer
{
final static int N = 5;
static int count = 0;
condition full = false;
condition empty = true;
// Maximale Anzahl an Items im Puffer
// Zähler für Items im Puffer
// Bedingungsvariable: Puffer ist voll
//(zunächst nicht voll)
// Bedingungsvariable: Puffer ist leer
// (Anfangszustand)
// Operation zum Einfügen eines Items im Puffer
void insert(item: integer) {
if (count == N)
wait(full);
// Warten, bis Puffer nicht mehr voll ist
// Füge Item ein
count+=1;
if (count == 1)
signal(empty);
// Signalisieren, dass Puffer nicht mehr leer ist
}
}
// Operation zum Entfernen eines Items aus dem Puffer
int remove() {
if (count == 0)
wait(empty);
// Warten, bis Puffer nicht mehr leer ist
// Entferne Item
count--;
if (count == (N-1)
signal(full);
// Signalisieren, dass Puffer nicht mehr voll ist
return (item);
}
Benutzung des Monitors:
class UseMonitor
{
ProducerConsumer mon = new ProducerConsumer();
...
// Produzent, der Items erzeugt
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 79 of 170
- 79 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 6 “Prozesssynchronisierung“
void producer() {
while (true) {
// Erzeuge Item
mon.insert(item);
}
}
}
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
// Einfügen des Items in den Puffer,
// evtl. Muss gewartet werden
// Konsument, der Items verwendet
void consumer() {
while (true) {
item = mon.remove(); // Hole ein Item aus dem Puffer
// warte, wenn Puffer leer ist
// Konsumiere ein Item
}
}
6.2.7 Weitere Verfahren zur Prozesssynchronisierung
Haben wir schon bei Interprozesskommunikation (Kapitel 3) besprochen:
• Message Passing
• Pipes
• Sockets
• RPC
• sowie Atomic Transactions:
• werden in Datenbanken benutzt, um die Integrität der Daten sicher zu stellen
• Ein kritischer Bereich wird entweder ganz ausgeführt oder gar nicht
Beispiel für Transaktionen
• Vorbereitung der TA: BEGIN_TRANSACTION
• Durchführen der TA: COMMIT_TRANSACTION
• Aufgeben (abbrechen) der TA: CANCEL_TRANSACTION
• Alle durchgeführten Operation (seit BEGIN_TRANSACTION) werden rückgängig
gemacht
• Wird auch Rollback genannt
6.3 Beispiele
6.3.1 Windows 2000
6.3.1.1 Interlocked-Funktionen
Einfache Thread-sichere Funktionen:
• InterlockedIncrement(DWORD*par): erhöht die Variable *par um 1
• InterlockedDecrement(DWORD*par): erniedrigt die Variable *par um 1
• weitere Interlocked-Funktionen, z.B. InterlockedExchanged(), etc.
6.3.1.2 Critical Section
Bietet gegenseitigen Ausschluss für Threads innerhalb eines Prozesses
• Sehr effektiv
• Implementiert als Spin-Lock
• Verwendung:
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 80 of 170
- 80 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Abschnitt 6 “Prozesssynchronisierung“
// Definition
CRITICAL_SECTION myCriticalSection;
// Initialisierung
InitializeCriticalSection( &myCriticalSection );
// Betreten und verlassen des kritischen Abschnitts mittels
EnterCriticalSection( &myCriticalSection );
// im kritischen Abschnitt...
LeaveCriticalSection( &myCriticalSection );
•
Weitere Befehle
// teste ob die KA belegt ist
BOOL isLocked = TryCriticalSection( &myCriticalSection );
// Löschen der Critical Section
DeleteCriticalSection( &myCriticalSection );
6.3.1.3 Dispatcher Objects: Events, Mutex, Semaphore
• Dispatcher Objekte sind Win32 Kernel Objekte. Ein Kernel-Objekt wird über eine HANDLE
identifiziert.
• Erzeugen der Objekte: CreateEvent(), CreateMutex(), CreateSemaphore()
• Benannte Objekte: Beim Erzeugen wird ein Name (string) angegeben. Damit können
Prozess-übergreifende Objekte angelegt werden. Typischerweise werden GUID (global
unique identifier) zur eindeutigen Identifizierung der Objekte verwendet (z.B. {11EE3539E892-4409-BF6B-C5778F3472EB})
• Warten auf ein Objekt (down()-Operation) mittels WaitForSingleObject() (ein Objekt) oder
WaitForMultipleObject() (mehrere Objekte)
• Hochzählen (up()-Operation): Semaphore: ReleaseSemaphore(), Mutex: ReleaseMutex(),
Event: PulseEvent()
6.3.2 Unix
6.3.2.1 Semaphore
• Semget() zum Erzeugen einer Semaphore und zum Aufnehmen einer Verbindung zu einer
Semaphore
• semop() für die Semaphore-Operation hochzählen (up(), V()) und Herunterzählen (down(),
P()) und zum Abfragen der Semaphore
• semctl() zum Setzen und Abfragen einer Semaphore. Beispielsweise kann mit der
Operation abgefragt werden, wieviele Prozesse gerade durch das Warten auf die
Semaphore blockiert sind.
6.3.3 Java
Unterstützt Monitore
synchronized-Keywort schützt Objekte vor gleichzeitigem Zugriff
Innerhalb einer synchronized-Umgebung können Threads mittels wait() schlafen gelegt
werden
• Mittels notify() oder notifyAll() werden sie wieder aufgeweckt
• Extra Übung!
•
•
•
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 81 of 170
- 81 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 6 “Prozesssynchronisierung“
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
6.4 Klassische Probleme der Synchronisierung
6.4.1 Bounded-Buffer (Producer-Consumer-Problem)
Ein Produzent schreibt in einen Puffer begrenzter Größe, ein Consumer liest Elemente aus
dem Puffer
• Produzent und Consumer müssen synchronisiert werden:
• Wenn der Puffer voll ist, muss der Produzent auf den Consumer warten
• Wenn der Puffer leer ist, muss der Consumer auf den Produzenten warten
• Typischerweise dürfen nicht beide gleichzeitig auf den Puffer zugreifen
•
6.4.2 Readers-Writers-Problem
Problem:
• Lesender und schreibender Zugriff auf gemeinsame Daten
• Beliebig viele Leser können gleichzeitig lesen
• Bei einem Schreibzugriff müssen jedoch die Daten für alle anderen (Leser und Schreiber!)
gesperrt sein
Beispiel:
• ein Leser R1 liest Daten
• nun möchte gleichzeitig ein Leser R2 die Daten lesen, während ein Schreiber W1 die Daten
ändern will
• Möglichkeit A: der Leser R2 darf die Daten lesen, dies ist ja gleichzeitig zu R1 möglich. W1
muss warten.
Problem: es können immer neue Leser kommen, und W1 kommt nie dran.
• Möglichkeit B: R2 muss warten, bis W1 die Daten geschrieben hat. In der Zeit können
weitere Leseanforderungen kommen, die auch alle warten müssen, d.h. ein Schreiber
blockiert viele Leser.
• Wichtig in Datenbanken, wo viele Clients gleichzeitigen Zugriff auf die Daten haben
6.4.3 Fünf speisende Philosophen
Klassisches Problem der Prozesssynchronisierung
5 Philosophen sitzen an einem rundem Tisch mit 5 Tellern und je einer Gabeln dazwischen
(insgesamt 5 Gabeln)
• Philosophen denken eine Weile nach, und dann bekommen sie Hunger und möchten essen
• Sie brauchen jedoch zum essen beide Gabeln (links und rechts von ihrem Teller). Wenn ein
Philosoph beide Gabeln bekommen hat, isst er eine Weile, dann legt er sie wieder hin.
• Wie sollen sich die Philosophen verhalten, damit
a) jeder drankommt (keiner verhungert)
b) keiner umsonst warten muss?
•
•
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 82 of 170
- 82 -
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Abschnitt 6 “Prozesssynchronisierung“
Hier der Tisch:
Fork 0
Fork 4
0
1
4
Fork 1
Fork 3
3
2
Fork 2
Abbildung 52: Ein Philosophen-Esstisch
Vorschlag 1:
#define N 5
// fünf Philosophen
void philosopher(int i) {
while(1) {
think();
take_fork(i);
take_fork( (i+N-1)%N );
eat();
put_fork(i);
put_fork( (i+N-1)%N );
}
}
// denken
// linke Gabel
// rechte Gabel
// linke Gabel niederlegen
// rechte Gabel niederlegen
Problem: was passiert, wenn z.B. alle Philosophen gleichzeitig die linke Gabel nehmen? Dann
warten sie ewig auf die rechte... sie “verhungern”!
Vorschlag 2: Ein Philosoph nimmt die linke Gabel, dann testet er, ob die rechte verfügbar ist.
Falls nicht, so legt er die linke Gabel wieder hin und wartet eine Weile.
Problem: Alle Philosophen nehmen die linke Gabel, und legen sie gleich wieder hin; das
wiederholt sich in alle Ewigkeit...
Vorschlag 3: Dann warten sie eben eine zufällig verteilte Zeit; irgendwann wird es schon mal
passen.
Problem: Würden sie z.B. eine Kernkraftwerkssteuerung einem Zufalls-Algorithmus
anvertrauen?
Vorschlag 4: Gesamten Tisch durch eine Mutex schützen. Der erste Philosoph, der eine Gabel
aufnimmt, bekommt den ganzen Tisch, dann kann er auch eine zweite Gabel aufnehmen.
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 83 of 170
- 83 -
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Abschnitt 6 “Prozesssynchronisierung“
Problem: Keine Starvation, fairer Algorithmus, aber Resourcen-Verschwendung: es kann
immer nur ein Philosoph zu einer Zeit essen.
Lösung aus 1 und 4: Wie Vorschlag 4, nur lassen wir bis zu 4 Philosophen an den Tisch.
Wenn 4 Philosophen essen wollen, so kann einer auch immer essen.
Problem mit Vorschlag 1 tritt auf, wenn alle 5 Philosophen gleichzeitig essen wollen. Tisch
durch eine Mutex schützen. Der erste Philosoph, der eine Gabel aufnimmt, bekommt den
ganzen Tisch, dann kann er auch eine zweite Gabel aufnehmen.
Einfache Lösung (nicht optimal in der Performance):
#define N
5
// fünf Philosophen
semaphore table(4);
semaphore fork[N];
// Nur 4 Phil. am Tisch erlaubt!
// Gabeln
void init()
{
int i;
for(i=0; i<N; i++ )
fork[i] = 1;
}
// initialisiere alle Gabeln mit 1
void philosopher(int i)
{
while(1) {
think();
take_forks(i);
eat();
put_forks(i);
}
}
// i: Nummer des Philosophen, 0..N-1
void take_forks(int i)
{
down( &table );
down( &fork(i) );
down( &fork( (i+N-1)%N );
}
// i: Nummer des Philosophen, 0..N-1
void put_forks(int i)
{
up( &fork(i) );
up( &fork( (i+N-1)%N );
up( &table );
}
// i: Nummer des Philosophen, 0..N-1
//
//
//
//
//
Endlosschleife
Denken
Nimm zwei Gabeln
Essen
Gabeln wieder hinlegen
// betrete Tisch
// linke Gabel nehmen
// rechte Gabel nehmen
// linke Gabel freigeben
// rechte Gabel freigeben
// verlasse Tisch
Anmerkung:
Für Windows kann die ::WaitForMultipleObjects-Funktion zum Warten verwendet werden.
Dann können die 3 down auf einmal ausgeführt werden.
• Anstelle vom Semaphore-Namen “Margull_Table” kann auch ein GUID verwendet werden,
z.B. “{11EE3539-E892-4409-BF6B-C5778F3472EB}_Table“.
•
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 84 of 170
- 84 -
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Abschnitt 6 “Prozesssynchronisierung“
#define N
5
// fünf Philosophen
HANDLE hSemaTable;
HANDLE hSemaFork[N];
// Tisch-Semaphore
// Gabeln-Semaphore
void init()
{
hSemaTable =
hSemaFork[0]
hSemaFork[1]
hSemaFork[2]
hSemaFork[3]
hSemaFork[4]
}
// initialisiere alle Gabeln mit 1
::CreateSemaphore( NULL, 5, 99, "Table");
= ::CreateSemaphore( NULL, 1, 99, "Fork0");
= ::CreateSemaphore( NULL, 1, 99, "Fork1");
= ::CreateSemaphore( NULL, 1, 99, "Fork2");
= ::CreateSemaphore( NULL, 1, 99, "Fork3");
= ::CreateSemaphore( NULL, 1, 99, "Fork4");
void philosopher(int i)
{
while(1) {
think();
take_forks(i);
eat();
put_forks(i);
}
}
// i: Nummer des Philosophen, 0..N-1
//
//
//
//
//
Endlosschleife
Denken
Nimm zwei Gabeln
Essen
Gabeln wieder hinlegen
void take_forks(int i)
// i: Nummer des Philosophen, 0..N-1
{
HANDLE handles[3];
handles[0] = hSemaTable;
handles[1] = hSemaFork[i];
handles[2] = hSemaFork[ (i+N-1)%N ];
::WaitForMultipleObjects( 3, handles, TRUE, INFINITE );
}
void put_forks(int i)
// i: Nummer des Philosophen, 0..N-1
{
LONG prev;
::ReleaseSemaphore( hSemaFork[ (i+N-1)%N ], 1, &prev);
::ReleaseSemaphore( hSemaFork[ i ], 1, &prev);
::ReleaseSemaphore( hSemaTable, 1, &prev);
}
•
Das komplette Beispiel kann auf der Skript-Seite heruntergeladen werden.
Lösung nach Tanenbaum:
#define
#define
#define
#define
#define
#define
N
5
LEFT (i+N-1)%N
RIGHT
(i+1)%N
THINKING
0
HUNGRY
1
EATING
2
int state[N];
semaphore mutex(1);
semaphore s[N];
void philosopher(int i)
{
while(1) {
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
// fünf Philosophen
// Nummer des linken Nachbarns
// Nummer des rechten Nachbarns
// Zustand 0: Philosoph denkt
// Zustand 1: Philosoph ist hungrig
// Zustand 2: Philosoph isst
// Feld mit Philosophen-Zuständen
// Mutex: Schutz des Zustandsfeldes
// Warte-Zustände des Philosophen
// i: Nummer des Philosophen, 0..N-1
// Endlosschleife
Page 85 of 170
- 85 -
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Abschnitt 6 “Prozesssynchronisierung“
}
}
think();
take_forks(i);
eat();
put_forks(i);
void take_forks(int i)
{
down(&mutex);
state[i] = HUNGRY;
test(i);
up(&mutex);
down( &s[i] );
}
void put_forks(int i)
{
// Denken
// Nimm zwei Gabeln
// Essen
// Gabeln wieder hinlegen
// i: Nummer des Philosophen, 0..N-1
// betrete kritischen Abschnitt
// Phil. i ist hungrig
// teste, ob beide Gabeln frei sind
// verlasse kritischen Abschnitt
// blockiere falls keine zwei Gabeln
// verfügbar sind
// i: Nummer des Philosophen, 0..N-1
down(&mutex);
// betrete kritischen Abschnitt
state[i] = THINKING;
// Phil. i beendet sein Essen
test(LEFT);
// Kann linker Nachbar jetzt essen?
(RIGHT);
// Kann rechter Nachbar jetzt essen?
up(&mutex);
// verlasse kritischen Abschnitt
}
test
void test(i)
// i: Nummer des Philosophen, 0..N-1
{
if( state[i]==HUNGRY
// Ist Phil. i hungrig?
&& state[LEFT]!=EATING
// und linke Gabel frei?
&& state[RIGHT]!=EATING ) // und rechte Gabel frei?
{
state[i] = EATING; // yumm yumm essen!
up( &s[i]);
// Blockierung von Phil.i aufheben
}
}
Nach Tanenbaum [1] schaut das dann etwa so aus:
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 86 of 170
- 86 -
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Abschnitt 6 “Prozesssynchronisierung“
6.5 Prioritäteninversion
Prioritäteninversion tritt in Prioritäts-gesteuerten Systemen auf:
1. Ein niedrig-priorer Prozess P1 ist aktiv und allokiert eine Resource A
2. Ein mittel-priorer Prozess P2 wird aktiv und unterbricht P1
3. Ein hoch-priorer Prozess P3 wird aktiv, P2 wird unterbrochen
4. P3 benötigt die Resource A und geht in den Wartezustand über
5. Als nächstes rechnet P2 zum Ende
6. Dann erst kommt P1 dran: P1 rechnet weiter und gibt A wieder frei
7. Nun erst kommt P3 (höchst-prior) wieder dran und unterbricht P1
Folge: P2 hat vor P3 fertiggerechnet, obwohl die Priorität von P2 niedriger ist als die von P3!
P1 (Niedrig)
P2 (Mittel)
P3 (Hoch)
P3 muss warten
da R1 nicht
verfügbar ist
Belegt R1
Prioritätsinversion:
P2 vor P3
Beantragt R1
Gibt R1 frei
Gibt R1 frei
Prozess hat Resource
Prozess wartet
Abbildung 53: Prioritätsinversion (P2 beendet vor P3)
Mögliche Alternativen:
• Prioritätsvererbung (priority inheritance): warten ein oder mehrere Prozesse auf eine
Resource, die ein anderer Prozess mit niedriger Priorität hält, so erhält dieser Prozess
kurzzeitig die Priorität des höchsten wartenden Prozesses
• Priority Ceiling: Für jede Resource wird im Vorfeld eine Ceiling-Priorität festgelegt, die
höher ist als die jedes Prozesses der diese Resource zu irgendeinem Zeitpunkt nutzen will.
Ein Prozess, der die Resource aquiriert, erhält automatisch die Ceiling-Priorität.
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 87 of 170
- 87 -
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Abschnitt 6 “Prozesssynchronisierung“
P1 (Niedrig)
P2 (Mittel)
P3 (Hoch)
P3 muss warten da
R1 nicht verfügbar ist
Belegt R1
Prioritätsvererbung:
P1 vor P2
Beantragt R1
Gibt R1 frei
Gibt R1 frei
Prozess hat Resource
Prozess wartet
Abbildung 54: Prioritäten-Vererbung (P1 erhält dieselbe Priorität wie P3)
P1 (Niedrig)
Belegt R1
P2 (Mittel)
P3 (Hoch)
P1 erhält eine Priorität
höher als P3 (wird nicht
unterbrochen)
Gibt R1 frei
Beantragt R1
P1 verliert
hohe Priorität
Gibt R1 frei
Prozess hat Resource
Prozess wartet
Abbildung 55: Priority-Ceiling(P1 erhält kurzzeitig eine hohe Priorität)
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 88 of 170
- 88 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 6 “Prozesssynchronisierung“
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
6.6 Deadlocks
6.6.1 Wiederholung: Begrifflichkeiten
Blockierung:
Ein Prozess P1 belegt ein Betriebsmittel, ein zweiter Prozess P2 benötigt dasselbe
Betriebsmittel und wird daher blockiert, bis es P1 freigegeben hat.
Verhungern (Starvation):
Ein Prozess erhält trotz Rechenbereitschaft keine CPU-Zeit zugeteilt, z.B. weil ihm immer
wieder Prozesse mit höherer Priorität vorgezogen werden.
Verklemmung (Deadlocks):
Zwei oder mehr Prozesse halten jeder für sich ein oder mehrere Betriebsmittel belegt und
versuchen ein weiteres zu belegen, das aber von einem anderen belegt ist. Es liegt ein Zyklus
von Abhängigkeiten vor. Kein Prozess gibt seine Betriebsmittel frei und alle Prozesse warten
daher ewig.
6.6.2 Bedingungen für ein Deadlock
Ein Deadlock kann nur eintreten, wenn folgende vier Bedingungen eintreffen:
1. Gegenseitiger Ausschluss (Mutual Exclusion) für die benötigten Betriebsmittel: nur ein
Prozess kann die Resource verwenden. Andere Prozesse müssen warten.
2. Hold and Wait: Prozesse belegen Betriebsmittel und fordern weitere an.
3. No Preemption: Kein Entzug eines Betriebsmittels ist möglich.
4. Circular Wait: Zwei oder mehrere Prozesse warten in einer verketteten Liste (in einer
Schleife, circular waiting) auf weitere Betriebsmittel.
Betriebsmittelbelegungsgraphen:
Eine in der Praxis häufig eingesetzte Technik ist das Erkennen und Beseitigen von Deadlocks
zur Laufzeit, wobei man hierzu sog. Betriebsmittelbelegungsgraphen einsetzt. Dies sind
Graphen, die als Knoten Ressourcen und Prozesse/Threads enthalten und Kanten, welche die
Belegung der Ressourcen durch Prozesse/Threads aufzeigen. Als Maßnahmen zur Beseitigung
eines Deadlocks sind das Abbrechen eines Prozesses/Threads oder das Entziehen eines
Betriebsmittels möglich.
Abbildung 56: Betriebsmittelbelegungsgraphen
(A, B, C, D: Prozesse, R, S, T, U: Resourcen)
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 89 of 170
- 89 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Abschnitt 6 “Prozesssynchronisierung“
In der Graphik:
(a) Prozess A hält Resource R belegt
(b) Prozess B wartet auf Resource S
(c) Deadlock:
• Prozess D hält T und möchte U
• Prozess C hält U und möchte T
(Ein weiteres Beispiel ist am Ende dieses Abschnittes zu sehen)
Strategien zur Deadlock-Behandlung:
• Ignorieren des Problems: Deadlocks passieren. Thats life.
• Zulassen: Entdeckung (detection) und Auflösung (Recovery) der Verklemmung.
• Vermeidung (prevention): Durch Eliminierung einer (oder mehrerer) der oben genannten
Ursachen.
• Verhinderung (avoidance): Erfüllbare Resource-Anforderungen werden nicht gewährt,
wenn Verklemmungsgefahr besteht.
6.6.3 Ignorieren des Problems (Vogel-Strauss-Strategie)
Einfachste Strategie, z.B. von Unix und Windows verwendet.
Jdeoch nicht unbedingt geeignet für:
• Echtzeitsysteme, z.B. Automobilsteuerungen4
• Kernkraftwerkssteuerungen5
6.6.4 Entdeckung und Behandlung
Wenn Verklemmung aufgetreten ist, wird diese beseitigt:
• Algorithmus zum Erkennen von Deadlocks notwendig
• Was tun, wenn man ein Deadlock erkannt hat?
• Einen Prozess aus der Schleife entfernen (killen); bei Batchsystemen kann dieser
später nochmals gestartet werden (Operator muss alles Papier aus dem Drucker
nehmen und wegschmeissen)
• Weitere Möglichkeiten, z.B. Prozess anhalten und einen früheren Zustand
wiederherstellen
6.6.5 Vermeidung von Deadlocks
Vermeidung = Eliminierung einer der notwendigen Bedingungen für ein Deadlock
Eliminierung von: Mutual Exclusion
Im Allgemeinen nicht vermeidbar. In der Betriebssystementwicklung wird jedoch diese
Bedingung immer mehr aufweicht:
• Speicher: war früher ausschliesslich einem Prozess zugeordnet; heute durch
Speichermanagement (und zusätzliche Hardware) mehrere Prozesse gleichzeitig im
Hauptspeicher
Wird trotzdem oft verwendet. Ein Watchdog (Hardware-Überwachung) überwacht das Steuergerät, und
wenn es nicht mehr reagiert, wird ein Reset ausgelöst.
5
Leider weiss ich nicht, wie hier Deadlocks vermieden werden.
4
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 90 of 170
- 90 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 6 “Prozesssynchronisierung“
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Ebenso CPU: früher (z.B. MS-DOS) nur ein Programm zu einem Zeitpunkt möglich; um ein
neues Programm zu starten, musste zunächst das Alte beendet werden. Heute quasiparallele Verarbeitung möglich
• Drucker: früher hat nur 1 Programm zu einem Zeitpunkt drucken können. Heute: DruckerSpooler sammeln Druckaufträge ein und drucken sie nacheinander.
• u.s.w.
•
Eliminierung von: Hold and Wait
• Gesamtanforderung aller Betriebsmittel bei Programmstart -> extrem schlechte Auslastung
der Resourcen
• Bei neuer Anforderung werden zunächst alle vom Prozess angeforderten Resourcen
freigegeben, um dann erneut in einem Schritt angefordert zu werden -> Möglichkeit der
Starvation
• Anforderung aller benötigten Resourcen auf einmal (z.B. WaitForMultipleObject() )
Eliminierung von: No Preemption
• Wartende Prozesse werden zwangsenteignet
Problem: Resourcen können sich in einem inkonsistenten Zustand befinden
Eliminierung von: Circular Wait
• Vorgeschriebene Reihenfolge bei der Anforderung von Resourcen:
• alle Resourcen werden linear angeordnet, z.B. Drucker=1, Band=2, CDROM=3
• Wenn ein Prozess mehrere Resourcen benötigt, so muss er sie in der vorgegebenen
Reihenfolge anfordern
• Beispiel: Ein Prozess braucht z.B. Band und CDROM: erst Band, dann CDROM
anfordern
• Beispiel: Ein Prozess hat das CDROM angefordert und will nun das Band haben ->
nicht möglich; zuerst muss CDROM freigegeben werden, dann Band und dann
CDROM angefordert werden
• Bei Spezialsystemen, z.B. Echtzeitsystemen, sehr effektive Massnahme
• In General-Purpose Systemen mit vielen Resourcen, vielen Programmen, vielen Prozessen,
etc. jedoch nicht praktikabel.
6.6.6 Verhinderung von Deadlocks
Deadlocks können u.U. verhindert werden, wenn augenblicklich erfüllbare Anforderungen
zurückgewiesen werden.
• Sicherer Zustand:
a) kein Deadlock
b) Selbst wenn alle Prozesse sofort alle benötigten Resourcen anfordern, gibt es eine
Scheduling-Reihenfolge, die alle Anforderungen ohne Deadlock erfüllen kann.
• Unsicherer Zustand: das System kann in einen Deadlock-Zustand geraten (oder ist schon
im Deadlock), d.h. a) oder b) im obigen Punkt sind nicht erfüllt.
Beispiel:
Zwei Prozesse A und B fordern die Resource “Printer” und “Plotter” an. Seien l1 – l4
Zustände von A, die in der Reihenfolge l1, l2, l3, l4 durchlaufen werden, und l5 – l8
Zustände von B (wieder in der Reihenfolge l5, l6, ... durchlaufen).
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 91 of 170
- 91 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 6 “Prozesssynchronisierung“
•
•
•
•
•
•
•
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Bei A1 fordert A den Printer an, bei A2 den Plotter, bei A3 wird der Printer wieder
freigegeben, bei A4 der Plotter
Bei B5 fordert B den Plotter an, bei B6 den Printer, bei B7 wird der Plotter wieder
freigegeben, bei B8 der Printer
p, q, r, s, t, u sind Zustände die das gesamte System (A und B) durchlaufen
Innerhalb der schraffierten Gebiete haben sowohl A als auch B dieselbe Resource
bekommen; dies verletzt die Mutual-Exclusion Bedingung. Diese Gebiete können also nicht
betreten werden.
Bei r fordert A die Resource “Printer”: die Anforderung wird gewährleistet. Bei s rechnet B
weiter
Bei t fordert B nun die Resource Plotter an: Falls diese Anforderung gewährleistet wird, ist
ein Deadlock unvermeidlich. Deshalb wird die Anforderung nicht gewährt, B muss warten.
Das unsichere Gebiet ist gelb gezeichnet. Innerhalb des Gebietes gilt: Wenn A und B ihre
Maximalforderungen stellen, so tritt ein Deadlock auf.
Abbildung 57: Deadlock-Trajektorie (nach [1])
•
Generell gilt: ein unsicheres Gebiet muss nicht immer zwangsläufig zum Deadlock führen.
Betritt ein System das unsichere Gebiet, so kann jedoch unter Umständen ein Deadlock
nicht mehr verhindert werden. Verzichtet z.B. B in manchen Situationen auf den Printer, so
führt der grüne Weg nicht zum Deadlock.
Algorithmus:
• Bedingung: Prozesse müssen im voraus angeben, welche Resourcen (und wieviel davon)
sie benötigten.
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 92 of 170
- 92 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 6 “Prozesssynchronisierung“
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Bei jeder Anforderung prüft das System, ob diese gefahrlos ausgeführt werden kann, d.h.
ob das System in einem sicherem Zustand bleibt.
• Beispiel: Bankers Algorithmus (Dijkstra, 1965)
•
6.6.7 Beispiel (nach [1])
Im folgenden Beispiel fordern die 3 Prozesse A, B und C jeweils zwei Resourcen an:
• Prozess A fordert R und S an
• Prozess B fordert S und T an
• Prozess C fordert T und R an
-> Es kommt zu einem Deadlock!
Abbildung 58: Deadlock!
Fragen:
• Ab welchem Bild befindet sich das System in einem unsicheren Zustand?
• Welche Anforderung muss es ablehnen, um sicher ein Deadlock zu vermeiden?
• Würde eine lineare Ordnung bei den Resourcenanforderungen helfen?
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 93 of 170
- 93 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 6 “Prozesssynchronisierung“
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Abbildung 59: Kein Deadlock!
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 94 of 170
- 94 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 7 “Zentralspeicherverwaltung“
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
7 Zentralspeicherverwaltung
7.1 Grundlagen
Erinnerung: jedes Programm verwendet den Hauptspeicher. Die CPU lädt Programmcode und
Daten aus dem Hauptspeicher, führt diese aus bzw. verarbeitet die Daten und schreibt sie in
den Hauptspeicher zurück. Eine CPU-Anweisung kann mehrere Speicherzugriffe enthalten.
Beispiele:
MOV R1, 4711
TSL 0815
// lade den Inhalt von Speicherzelle 4711 nach R1
// teste 0815 und setzte auf eins
7.1.1 Bindung der Speicheradressen
Abbildung 60: Übersicht Adressenbindung (nach [2])
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 95 of 170
- 95 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 7 “Zentralspeicherverwaltung“
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Compile-Time: Beim Compilieren werden die physikalischer Adressen im Programm
festgelegt. Wurde bei MS-DOS im COM-Format verwendet.
Nachteil: Es kann nur ein Programm gleichzeitig im Speicher sein! Würde z.B. ein
Programm zweimal gestartet, so würden beide Instanzen dieselben Adressen verwenden!
• Load-Time: Beim Laden des Programmes werden die physikalischen Adressen ins
Programm geschrieben. Der Linker erzeugt relative Adressangaben, z.B. „Variable X belegt
4 Byte an Stelle 14 gezählt vom Modul-Start“, oder „Funktion Y() befindet sich an Position
4711 im Code-Modul“. Der Program Loader ersetzt vor Programmstart alle relativen
Adressbezüge durch die physikalischen Adressen; dasselbe Programm kann zweimal
gestartet werden, da beide Instanzen unterschiedliche Adressen bekommen.
• Execution-Time: Beim Adresszugriff wird die relative Adresse in eine physikalische
umgesetzt->nur mit Spezialhardware möglich
•
7.1.2 Logischer und physikalischer Speicher
Logische (virtuelle) Adresse:
bezeichnet die Adresse, wie sie von der CPU erzeugt und gesehen wird.
Physikalische Adresse:
Die Adresse, mit der die Speicherstelle im Hauptspeicher angesprochen wird.
Bei Compile-Time und Load-Time Adressbindung sind logische und physikalische Adresse
identisch.
Umsetzung von logischer auf physikalische Adresse durch Spezial-Hardware Memory
Management Unit (MMU):
Abbildung 61: MMU Architektur
Einfache MMU zur Adress-Verschiebung mittels Relocation Register:
• Die CPU adressiert die Adresse 346
• Das Relocation Register enthält 14000; der Adresszugriff wird umgesetzt auf 14346 und
die entsprechenden Daten aus dem Speicher geholt.
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 96 of 170
- 96 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Abschnitt 7 “Zentralspeicherverwaltung“
•
•
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Logische Adressen: 0 bis zu einem Maximum max
Physikalische Adressen: 14000 bis 14000+max
Abbildung 62:
63: Adressumsetzung mittels Relocation Register
Das Programm sieht niemals die physikalische Adresse, sondern arbeitet ausschliesslich mit
den logischen Adressen!
7.1.3 Dynamisches Laden / Overlay Technik
Nicht der gesamte Programmcode befindet sich im Hauptspeicher, sondern nur Teile davon.
Wird ein Teil benötigt, der nicht im Hauptspeicher ist, so wird dieser dynamisch nachgeladen.
->Overlay-Technik
7.1.4 Dynamisches Linken und gemeinsame Bibiliotheken (Shared Libraries)
Statisches Linken:
Alle Programmbibliotheken werden vom Linker zum Programm hinzugefügt.
Dynamisches Linken:
Der Linker fügt anstelle der Bibliothek einen Stub hinzu; wird die erste Funktion aus der
Bibliothek aufgerufen, so wird diese dynamisch hinzulinkt.
• Befindet sich die Bibliothek noch nicht im Speicher, so wird sie geladen
• Alle Referenzen im Programm werden an die geladene Bibiliothek angepasst.
• Befindet sich die Bibliothek bereits im Speicher, da sie z.B. von einem anderen Programm
genutzt wird, so muss sie nicht mehr geladen werden; ggfs. sind Initialisierungen
durchzuführen
• Wird hauptsächlich für Systembibliotheken verwendet.
Vorteil:
• DLLs können mehrfach genutzt werden (geringerer Speicherverbrauch, kürzere Ladezeit).
• Bugfixes: wird eine DLL verbessert, so profitieren automatisch alle Programme davon!
ABER:
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 97 of 170
- 97 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 7 “Zentralspeicherverwaltung“
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
“DLL-Hell” (DLL-Hölle) bei Windows:
• viele Programme verwenden z.B. comctl32.dll (enthält graphische Elemente von
Windows, z.B. Buttons, Drop-Down-Lists, etc).
• Irgendwann hat Microsoft die DLL erweitert, um neue Buttons etc. zu
implementieren. Kein Problem, die alten Programme funktionieren auch mit den
neuen DLL.
• Jahre gehen ins Land und jedes Programm nutzt das neue Feature.
• Jetzt installiert der Benutzer ein Uralt-Programm “grauer-opa.exe” von 1993. Dieses
benötigt die comctl32.dll, und um sicher zu gehen, dass sie auch da ist, kopiert es
diese beim installieren ins Windows-System32 Verzeichnis. “grauer-opa.exe”
funktioniert dann auch einwandfrei, leider stürzen alle anderen Programme ab! Sie
nutzen die neuen Features in der comctl32.dll, die in der alten DLL nicht drin sind!
• Dies führte zu bizarren Fehlern, die kaum beseitigt werden konnten. Nach der Installation
eines neuen Programmes X funktierten Teile von Y auf einmal nicht mehr!
• Es gab sogar Situationen, wo entweder X oder Y auf einem System installiert werden
konnten, jedoch nicht beide gemeinsam!
• Das Problem liegt in der mangelhaften Versionierung von DLLs. .NET enthält
Mechanismen, um alle DLLs für jedes Programm getrennt zu verwalten. Jedes Programm
erhält dann “seine” DLLs in der gewünschten / benötigten Version (was natürlich den
Gedanken der “gemeinsamen Nutzung” etwas untergräbt)
•
7.1.5 Echtzeitsysteme
Viele einfache Echtzeitsysteme haben keine Festplatte. Das Programm ist unveränderlich im
ROM (Read-Only Memory) gespeichert, während die Daten im RAM gespeichert sind. ROM
kann z.B. sein:
• EPROM (erasable programmable read-only memory): durch UV-Licht löschbarer Speicher
• Flash: elektrisch löschbarer Speicher
• Maske: es wird eine eigene Prozessormaske entwickelt, die das Programm fest enthält.
Für ROM und RAM werden jeweils eigene Adressbereiche festgelegt. Nach dem Compilieren
und dem Linken wird ein weiterer Schritt durchgeführt, in dem die absoluten Adressen für
RAM und Programmcode eingefügt werden. Anschließend kann das Progamm auf die TargetHardware ausgeführt werden.
Beispiel: Aufzugsteuerung, 16-Bit Prozessor (NEC V25) mit 20 Adressleitungen
20 Adressleitungen, möglicher Adressraum 220 = 0x100000, 128 K Programm, 6 K
Speicher:
• Programmcode (ROM) 0xE0000 – 0xFFF00
• Hauptspeicher (RAM) 0x01000 – 0x02800
• 256 Spezialregister des Prozessors (z.B. serielle Schnittstelle, Timer, etc.) 0xFFF00 –
0xFFFFD
• Reset-Vektor (16 Bit) 0xFFFFE – 0xFFFFF
• Interrupt-Vektortabelle 256 Bytes 0x00000 – 0x00100
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 98 of 170
- 98 -
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Abschnitt 7 “Zentralspeicherverwaltung“
A19
0
0
...
1
1
A18 A17
0
0
0
1
1
1
0
1
Chip
RAM
Chip
Select
ROM
ROM
A19
ROM Chip
Select
RAM Chip
Select
A17
Adressbus
A0..A16
CPU
Datenbus D0..D7
D0
D7
A0
A15
D0
RAM
D7 A0
A16
ROM
Enable
Read/Write
Abbildung 64: Adress- und Datenbus für ein Echtzeitsystem
Hardware-Aufbau:
• Adress-Leitung 20 Bits
• RAM 64kB (16 Adressleitungen)
• ROM 128 kB (17 Adressleitungen)
• Adressleitungen A17-A19 werden zur Auswahl des Chips herangezogen
Daten lesen:
• CPU legt Adresse an den Adressbus an, und gibt Read/Write aus (für Einlesen: Read-aktiv)
• Chip-Select Chip wählt entsprechenden Chip aus (RAM, ROM)
• CPU wartet, bis Adressbus stabilisiert ist
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 99 of 170
- 99 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 7 “Zentralspeicherverwaltung“
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Dann wird mit Enable der Chip aktiviert; die entsprechenden Daten werden an den
Datenbus gelegt
• Wiederum wartet die CPU kurz; dann liest sie die Daten von D0..D7 ein.
•
Spezialregister
0xFFFFF
0xFFF00
Programmcode
(128K ROM)
0xC0000
Speicher
(64 K RAM)
Interrupt
Tabelle
0x2FFFF
0x20000
0x100
0x0
Abbildung 65: Speicherlayout Echtzeitsystem
7.2 Monoprogrammierung
Es läuft maximal ein Programm, z.B. MS-DOS.
• Das Betriebssystem belegt ein oder mehrere Bereiche im Speicher, typischerweise am
unteren und / oder oberen Rand. Der Rest steht für das Programm zur Verfügung.
• Programm verwendet physikalische Adressen, keine Adressumsetzung nötig
Abbildung 66: Speicherverwaltung bei Monoprogrammierung (nach [1])
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 100 of 170
- 100 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 7 “Zentralspeicherverwaltung“
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
7.3 Multiprogrammierung-Betrieb mit festen Partitionen
Wurde früher für Großrechnersysteme, z.B. IBM OS/360 verwendet. Der verfügbare Speicher
wird in Partitionen mit fester Größe aufgeteilt. In jeder Partition wird genau ein Job
ausgeführt. Die Jobs warten in einer Warteschlange auf die Zuteilung zu einer Partition.
Die Partitionen werden vom Operator fest konfiguriert und können nicht geändert werden.
• Adressumsetzung durch Loader (bei Programmstart) oder durch einfache Verschiebung
(z.B. Relocation Register)
Abbildung 67: Speicherverwaltung mit festen Partitionen (nach [1])
7.4 Swapping
•
•
•
•
•
•
•
Ein Prozess kann angehalten und aus dem Speicher entfernt werden. Dabei wird sein
gesamter Speicher auf Festplatte geschrieben.
Der Prozess kann später jederzeit wieder fortgeführt werden; der Speicherinhalt wird
wieder geladen. Dies muss nicht notwendigerweise an derselben physikalischen Adresse
geschehen.
Erfordert Adressbindung zur Laufzeit (Execution-Time), da der Prozess ja wieder an anderer
Stelle geladen werden kann.
Kontextwechsel dauert sehr lange, da gesamter Speicher auf Festplatte geschrieben
werden muss (bzw. wieder geladen werden muss)
Wenn der Prozess auf I/O wartet, so kann er nicht so einfach geswappt werden
Kann mit einfachen Hardware-Mitteln (z.B. relocation register, RR) verwirklicht werden:
Das Relocation Register wird im PCB gespeichert; bei einem Prozesswechsel wird das
entsprechende RR wieder hergestellt.
Wird nur noch „im Notfall“ verwendet, z.B. wenn Linux der physialische Speicher ausgeht
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 101 of 170
- 101 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 7 “Zentralspeicherverwaltung“
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Abbildung 68: Ablauf beim Swapping
7.4.1 Speicherverteilung
•
•
typischerweise OS unten oder oben (z.B. Windows: obere 2 GB sind Betriebssystem)
Platz zum Wachsen bereitstellen: typischerweise wird für Stack und Daten (Heap) Platz
bereitgestellt (siehe folgende Abbildung (b) )
Abbildung 69: Speicherverteilung im Prozess (nach [1])
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 102 of 170
- 102 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 7 “Zentralspeicherverwaltung“
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
7.4.2 Speicherschutz
Einfache Möglichkeit: Relocation Register mit Limit Register
Abbildung 70: Adressverschiebung mit Begrenzung
7.4.3 Problem: Fragmentierung und Verschnitt
Interne Verschnitt:
Das Betriebssystem teilt Speicher in festen Blockgrößen zu, z.B. immer 4 kB Blöcke. Benötigt
ein Prozess z.B. 10 kB, so bekommt er 12 kB zugeteilt -> interner Verschnitt von 2 kB.
Externe Verschnitt:
Das Betriebssystem teilt Speicher in variabler Größe zu, dadurch wird der verfügbare freie
Speicher zerstückelt.
Externer Verschnitt: Verhältnis von größtem freiem Block zu freiem Speicher
Durch Relocation (Verschieben von Prozessen) kann der externe Verschnitt beseitigt werden;
wird jedoch nicht gemacht, da es sehr zeitaufwendig ist
7.4.4 Verwaltung von freien Speicherbereichen
7.4.4.1 Bitmaps: Bitketten für Speicher
Der Speicher wird in gleich große Blöcke aufgeteilt. Eine Bitmap enthält für jeden Block den
Zustand frei / belegt: ist das Bit 0, so ist der Block frei, ist das Bit 1, so ist der Block belegt.
Algorithmus:
• Anfangszustand: alle Bits auf Null (Speicher ist frei)
• Neue Anforderung für n Blöcke: suche eine Unterkette der Länge n aus Null-Bits, belege
diese Unterkette mit Einsen
• Freigabe: setzte alle n Bits auf Null
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 103 of 170
- 103 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 7 “Zentralspeicherverwaltung“
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Beispiel: Blockgröße 4K
Blockbelegung:
Block:
1
0
1
0
0
0
0
1
0
1
2
3
4
5
6
7
Belegt: Block 0, Block 2, Block 7
Anfoderung von 10 K RAM, d.h. 3 Blöcke: z.B. Block 3 – 5
Analyse:
Speicherbedarf:
• Blockgröße 4 Byte (32 Bit): 1/32 ≈ 3%
• Blockgröße 512 Bytes: 1/(512*8)=1/4096≈ 0,024%
• Bei 1 MB (220 Bytes) Speichergröße und einer Blockgröße von 512 Bytes: 2048 Blöcke,
256 Bytes Speicher werden benötigt
• Bei 1 GB (230 Bytes) Speichergröße und einer Blockgröße von 512 Bytes: 2 Millionen
Blöcke, 260 kB werden benötigt
Laufzeit:
• Bei 8086: infolge fehlender Befehle nur aufwändig möglich -> für MS-DOS nicht geeignet
trotz Verwendung im Vorgänger CP/M
• Bei 386 oder 68000: kein Problem
7.4.4.2 Speicherverwaltung über lineare Listen (Freikette)
In einer verketteten Liste (Freikette) werden alle freien Blöcke gespeichert.
Algorithmus:
• Anfangszustand: gesamter Speicher ist frei, d.h. die Freikette enthält 1 Listenelement mit
dem gesamten (freien) Speicher
• Neue Anforderung von n Bytes:
• suche einen Element in der Freikette mit mehr als n Bytes
• Teile diesen Bereich in zwei Teile: n Bytes zur Erfüllung der Anforderung, Rest wird
neues Element in der Freikette
• Freigabe von Speicherbereich: füge neuen freien Speicher in die Freikette ein, anschließend
eventuelle Verschmelzung von benachbarten Freibereichen. Dabei sind 4 Fälle zu
unterscheiden:
• keine Verschmelzung möglich: der freigegebene Speicherbereich ist links und rechts
von belegtem Speicher umgeben
• Verschmelzung mit linkem (oder rechtem) Speicherbereich: der linke (oder rechte)
Speicherbereich ist frei und wird mit dem neu freigegebenem Speicher
verschmolzen.
• Verschmelzung mit linkem und rechtem Speicherbereich: links und rechts von dem
freigegebenen Speicher sind Freibereiche. Dann können alle 3 Bereiche (links, rechts
und neu freigegeben) zu einem Element in der Freikette verschmolzen werden.
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 104 of 170
- 104 -
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Abschnitt 7 “Zentralspeicherverwaltung“
A
X
A
X
X
B
A
B
A
B
B
X
Abbildung 71: Verschmelzung von freien Bereichen (nachdem
Prozess X terminiert)
7.4.5 Algorithmen zur Auswahl von Speicher aus der Freikette
Wenn eine Speicheranforderung an das BT gestellt wird, so muss aus den verfügbaren freien
Speicherbereichen ein Bereich ausgewählt werden. Dazu werden verschiedene Algorithmen
verwendet.
7.4.5.1 First Fit
Algorithmus:
Die Liste der verfügbaren Speicherbereiche wird durchsucht; der erste, passende
Speicherbereich wird verwendet
Die Suche geht immer vom Anfang des Speichers aus, der niedrige Speicherbereich wird
stark fragmentiert. Am Ende sammeln sich größere freie Bereiche an.
• Einfachster, und sehr effektiver Algorithmus.
•
7.4.5.2 Best Fit
Algorithmus:
Die gesamte Liste wird durchsucht; der kleinste freie Speicherbereich, der die Anforderung
erfüllen kann, wird verwendet
Auswirkung:
• Die Freikette muss vollständig durchsucht werden. Dies kann durch eine Anordnung
verbessert werden: die Freikette wird nach Größe sortiert. Durch binäre Suche kann
schnell der passende freie Speicherbereich gefunden werden.
• Nachteil: es entstehen viele kleine (nicht weiter verwendbare) Blöcke
7.4.5.3 Worst Fit:
Algorithmus:
Der größte freie Speicherbereich wird verwendet.
Auswirkung:
• Nach einiger Zeit keine großen freien Bereiche mehr vorhanden.
7.4.5.4 Problem: Externer Verschnitt
In allen Fällen tritt externer Verschnitt auf!
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 105 of 170
- 105 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 7 “Zentralspeicherverwaltung“
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Beispiel:
Speicher: 1 MB, Algorithmus: First Fit
Anforderungen:
1. 200K: Bereich 0 – 200K
2. 100K: Bereich 200K – 300K
3. 200 K: Bereich: 300K – 500K
4. 100K: Bereich 500K – 600K
5. Freigabe von 1.
6. Freigabe von 3.
7. 500K: geht nicht, obwohl nur 800K frei sind!
Speicherabbild (nach Schritt 6):
1M
400K frei
100K
600K
500K
200K frei
100K
300K
200K
200K frei
0
Abbildung 72: Speicherfragmentierung
7.4.5.5 Buddy-System nach Knuth
Ziel:
• freien Speicher schnell finden
• effizientes Verschmelzen
• Fragmentierung begrenzen
Algorithmus:
n
• Der Speicher wird in Einheiten von 2 vergeben (Anforderung von 100 Bytes -> Zuteilung
von 128 Bytes)
• Für jeden Topf mit Elementen der Länge 2i gibt es eine Freikette (i=1..n)
• Anfangszustand: alle Freiketten sind leer, bis auf die mit den höchsten Topf
• Anforderung von x bytes:
• x wird auf die nächst-höhere Zweierpotenz 2i , i<n, aufgerundet. Anschließend
wird die Speicheranforderung aus der i-ten Freikette erfüllt.
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 106 of 170
- 106 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 7 “Zentralspeicherverwaltung“
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Ist die i-te Freikette leer, so wird aus der nächst-höheren Freikette i+1ein freier
Speicherbereich entnommen und in zwei Hälften geteilt. Ein Teil wird zur
Befriedigung der Anforderung verwendet, der andere wird in der i-ten Freikette als
frei gespeichert. Falls die Freikette i+1 leer ist, so wird eine höhere, nicht-leere
Freikette j>i gesucht und diese heruntergebrochen.
• Freigabe: wird ein Speicherbereich freigegeben, so wird er wieder in die i-te Freikette
zurückgegeben.
• Nur wenn die andere Hälfte, aus der er ursprünglich durch Teilung entstanden ist,
auch in der Freikette vorhanden ist, werden beide Teile wieder verschmolzen und an
die nächst-höheren Freikette i+1 zurückgegeben.
• Zwei Bereiche der Freikette i können dann verschmolzen werden, wenn sich
Anfangsadressen nur in einem Bit unterscheiden: die Bits 0..i-1 sind Null, Bit i ist
unterschiedlich, und alle höheren Bits müssen gleich sein.
• Dies ist in Abbildung 73: Speicheraufteilung nach dem Buddy-System dargestellt:
die Zahlen bezeichnen die Anfangsadresse der jeweiligen Speicherbereiche (die
unteren 16 Bits wurden weggelassen).
•
Abbildung 73: Speicheraufteilung nach dem Buddy-System
Vorteil: Speicher wird nicht so stark fragmentiert wie bei anderen Verfahren (externe
Fragmentierung).
Jedoch interner Verschnitt, da immer auf Zweierpotenzen aufgerundet wird; durchschnittliche
Fragmentierung liegt etwa 25 %.
Beispiel:
Ablauf: Anforderung 100K (1), 200K (2), 30K (3), 20K (4); Freigabe Anf. 2 (5); Anforderung
80K (6); Freigabe Anf. 3 (7); Anforderung 90 K (8); Freigabe Anf. 6 (9), Anf. 4 (10)
Bemerkungen:
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 107 of 170
- 107 -
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Abschnitt 7 “Zentralspeicherverwaltung“
In Zeile 1-3 wird jeweils ein freier Speicherbereich halbiert, ebenso in Zeile 6 und 7 sowie
in Zeile 11
• In Zeile 21 und 22 werden jeweils benachtbarte Bereiche verschmolzen
• Die beiden 128K Bereiche in Zeile 22 können nicht verschmolzen werden, da sie nicht
auseinander hervorgegangen sind.
•
0 K
32 K
64 K
12 8 K
25 6 K
51 2 K
51 2 K
1
25 6 K
2
25 6 K
3
12 8 K
12 8 K
25 6 K
4
1
12 8 K
25 6 K
5
1
12 8 K
2
6
1
64 K
64 K
2
7
1
32 32
64 K
2
8
1
3
32
64 K
2
9
1
3
4
64 K
2
10
1
3
4
64 K
5
1
3
4
64 K
12 8 K
12 8 K
1
3
4
64 K
6
12 8 K
1
7
4
64 K
6
12 8 K
1
32
4
64 K
6
12 8 K
1
32
4
64 K
6
8
1
32
4
64 K
9
8
1
32
4
64 K
12 8 K
8
1
32 10
64 K
12 8 K
8
20
1
32 32
64 K
12 8 K
8
21
1
64 K
64 K
12 8 K
8
22
1
12 8 K
8
11
12
13
14
15
16
17
18
19
12 8 K
Abbildung 74: Buddy-System (Beispiel)
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 108 of 170
- 108 -
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Abschnitt 7 “Zentralspeicherverwaltung“
7.5 Virtueller Speicher: Paging
Virtueller Speicher:
• Trennung zwischen logischer Adresse und physikalischer Adresse.
• Mehr logischer Speicher als physikalisch verfügbarer Speicher
• Mehreer Prozesse nutzen denselben physikalischen Speicher
7.5.1 Übersicht Paging
logischer Adressraum
von Prozess 1
logischer Adressraum
von Prozess 2
0xFFFFFFFF
11
11
10
10
9
7
6
5
Seite ->
Seitenrahmen
4
Prozess1
9
physikalischer
Adressraum
8
sieht
0xFFFFFFFF
3
3 5
2
9 7
1
2 1
0
0
Seiten (P1)
5 2
Seitentabelle (P1)
8
7
7
Seite 9 (P1)
6
Seite 2 (P2)
5
Seite 3 (P1)
4
Seite 1 (P2)
2
6
3
3
Seite 5 (P2)
9
0
2
2
Seite 5 (P1)
5
3
1
1
Seite 2 (P1)
1
4
0
0
Seite 9 (P2)
Seitenrahmen
6
5
Seite ->
Seitenrahmen
4
Seitentabelle (P2)
sieht
Prozess2
0
Seiten (P2)
9
Seite in Benutzung
9
Seite in Benutzung
0
unbenutzte Seite
0
unbenutzte Seite
Abbildung 75: Übersicht Paging
Der logische Speicher wird in gleich große Blöcke aufgeteilt (z.B. 4 kB)
Der Prozess sieht einen zusammenhängenden Speicherbereich, der größer sein kann als
der verfügbare physikalische Speicher
• Jeder Zugriff auf eine logische Adresse wird auf die entsprechende physikalische Adresse
umgesetzt: Jeder Block wird über eine Seitentabelle einem Bereich im physikalischen
Adressraum abgebildet
• Ist eine Seite nicht im Speicher, so wird ein System-Trap ausgelöst.
•
•
7.5.2 Umsetzung mittels Seitentabellen
•
Logische Adresse wird geteilt:
• obere Bits geben die Seitennummer an
• untere Bits den Offset in dieser Seite
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 109 of 170
- 109 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 7 “Zentralspeicherverwaltung“
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Abbildung 76: Übersicht Paging MMU
• In einer Tabelle werden zu jeder Seite der physikalische Seitenrahmen gespeichert
• ist eine Seite nicht im physikalischen Speicher, so wird dies durch ein
entsprechendes Bit vermerkt.
• Anhand der Seitennummer wird die zugehörige Seitennummer herausgesucht
• Ist die Seite nicht im Speicher, so wird ein System-Trap ausgelöst
• Durch Addition der physikalischen Adresse der Seite und des Offsets wird die
physikalische Adresse gebildet.
Beispiel:
• Seitengröße 4K (der Offset beträgt 12 bit, von 0 .. 4095 )
• logischer Speicher: 16 Seiten a 4K = 64K
• physikalischer Speicher: 32 K
• Seitentabelle siehe Abbildung 77: Beispiel Seitentabelle
• Die 16-bit Adresse 8196 = 0010.0000.0000.0100 wird wie folgt umgesetzt:
• Offset (die unteren 12 Bit) gleich 4
• Seitennummer (die oberen 4 Bits) gleich 2
• Heraussuchen der Seitenrahmennummer zur Seite 2: Seitenrahmennummer 6
• Berechnung der physikalischen Adresse:
• Seitenrahmennummer 6 * 4096 (Seitengröße) ergibt 24576
• plus Offset 4 = 24580
• Die logische Adresse 8196 wird umgesetzt auf die physikalische Adresse 24580
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 110 of 170
- 110 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 7 “Zentralspeicherverwaltung“
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Abbildung 77: Beispiel Seitentabelle
Bemerkungen:
• Die Seitentabelle kann sehr groß werden:
➢ 32-Bit Adressraum bei 4K Seitengröße: Seitentabelle hat 1 Million Einträge
➢ Für jeden Prozess ist eine eigene Seitentabelle nötig!
➢ 64-Bit Adressraum: sehr sehr viele Einträge im Adressraum...
• Die Umsetzung muss sehr schnell sein.
➢ Für jeden Speicherzugriff ist eine Umsetzung nötig! Viele Prozessoranweisungen
greifen ein oder mehrmals auf den Speicher zu, so das bei fast jedem
Prozessorschritt auf die Seitentabelle zugegriffen werden muss.
➢ Bei 1 GHz wird 1 Befehl pro Nanosekunde abgearbeitet, d.h. der Befehl dauert 1ns.
Wenn ein Zugriff auf die Seitentabelle auch 1 ns dauert, so wird der Rechner nur
halb so schnell sein!
• Problem: wo wird die Seitentabelle gespeichert?
➢ In Prozessorregistern:
Vorteil: schneller Zugriff
Nachteil: nicht genügend Register vorhanden
➢ Im Hauptspeicher:
Vorteil: große Seitentabellen möglich
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 111 of 170
- 111 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 7 “Zentralspeicherverwaltung“
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Nachteil: Zugriff auf die Seitentabelle bedeutet, dass die MMU zuerst die
Seitentabelle aus dem Hauptspeicher holen muss, um dann den
Seitenrahmen zu ermitteln; d.h. es sind zwei Speicherzugriffe nötig
7.5.3 Hierarchische Seitentabellen
Um keine großen Seitentabellen im Speicher zu halten, wird eine Hierarchie von
Seitentabellen verwendet.
• Die logische Adresse wird in 3 Bereiche aufgeteilt:
➢ Die unteren 12 Bit sind wieder der Offset
➢ Die oberen 20 Bit werden in zwei Felder aufgeteilt: 10 Bit Seitentabelle ST1, 10 Bit
Seitentabelle ST2. Jede Tabelle enthält 1024 Einträge
➢ Die Felder von ST1 (obere 10 Bit einer logischen Adresse) geben die Nummer einer
Seitentabelle ST2 an
➢ In dieser Seitentabelle ST2 wird nun mit den nächsten 10 Bit der Seitenrahmen
ermittelt; zusammen mit dem Offset kann nun die physikalische Adresse gebildet
werden
➢ Trick dabei: Man muss nur ein paar der Seitentabellen ST2 im Speicher halten. Ein
Prozess benutzt z.B. 4 MB am unteren Ende des Adressbereiches für den
Programmcode, die nächsten 4 MB für Daten und die obersten 4 MB für den Stack.
Dann müssen nur 4 Seitentabellen im Speicher gehalten werden (ST1 und 3 mal
ST2), zusammen also 4*1024 gleich 4096 Einträge (anstelle 1 Million!)
• Auch 3 oder mehr Hierarchie-Ebenen möglich
•
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 112 of 170
- 112 -
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Abschnitt 7 “Zentralspeicherverwaltung“
Seitentabelle ST2
(zweite Ebene)
Seitenrahmen
(physikalischer Speicher)
höchste 4MB
1023
...
6
5
4
Seitentabelle ST1
(obere Ebene)
3
2
1023
1
...
0
3
el
eg
4-8MB
ch
tb
4
1023
ni
5
t
6
...
2
6
1
5
0
4
3
2
1
0
0-4MB
1023
Schritt 1: Seitentabelle der
zweiten Ebene raussuchen
...
6
5
4
3
Schritt 2: Seitenrahmen
aus ST2 ermitteln
2
1
0
Schritt 3: Offset
hinzuzählen
Adresse 0x406CA3
0000000001
0000000110
110010010011
10 Bit ST1
10 Bit ST2
12 Bit Offset
Abbildung 78: Zwei-stufige Seitentabelle
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 113 of 170
- 113 -
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Abschnitt 7 “Zentralspeicherverwaltung“
7.5.4 Einträge in einer Seitentabelle
Ein Eintrag in einer Seitentabelle enthält im Allgemeinen die folgenden Informationen (manche
Einträge sind abhängig von der speziellen Hardware des Rechners):
• Wichtigster Eintrag ist natürlich die Nummer des Seitenrahmens
• P-Bit (Present-Bit): Ist die Seite überhaupt vorhanden? Falls nicht -> Seitenfehler -> MMU
löst Interrupt aus, wird vom Betriebssystem bearbeitet
• Seitenschutz (Protection): Zugriffsrechte, z.B. Read-Only, Read-Write, Execute-Recht, etc.
Kann 1-Bit oder mehrere Bits sein.
• M-Bit (Modified-Bit): Wurde die Seite geändert? Wird nach Schreibzugriffen auf die Seite
gesetzt.
• R-Bit (Referenced-Bit): Wurde auf die Seite schon einmal zugegriffen? Dieses Bit wird nach
einem Zugriff (lesend oder schreibend) auf die Seite gesetzt; wird für
Seitentauschstrategien benötigt
• Caching-Disabled Bit: Diese Seite darf nicht gecached werden (nötig z.B. wenn die Seite
auf ein Hardware-Gerät gemapped wird).
M-Bit: Seite
geändert?
Kein Caching ?
Seite
vorhanden?
Nummer des Seitenrahmens
Zugriffsrechte
R-Bit: Wurde auf
Seite zugegriffen?
Abbildung 79: Typischer Eintrage in einer Seitentabelle
7.5.5 TLBs – Translation Lookaside Buffers
Heutezutage befinden sich die Seitentabellen meistens im Speicher. Bei einer zweistufigen
Seitentabelle sind anstelle eines Speicherzugriffes drei nötig, d.h. das System ist um 2/3
langsamer!
Um dies zu vermeiden, wird eine spezielle Hardware verwendet, die Translation Lookaside
Buffers. Diese speichern einige Seitentabelleneinträge in Spezialregistern. Durch die
Verwendung von assoziativem Speicher können alle Einträge in einem Prozessortakt
untersucht werden.
Ein Programm benötigt typischerweise nur eine geringe Anzahl von Seiten zu einem
bestimmten Zeitpunkt. Deshalb reichen auch geringe Größen (selten mehr als 64) der TLBs
aus, um eine drastische Performance-Steigerung zu erreichen.
Ablauf:
• Zugriff auf eine Speicherstelle
• Die logische Adresse wird in zwei Teile zerlegt
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 114 of 170
- 114 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 7 “Zentralspeicherverwaltung“
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Im TLB wird die Seitennummer gesucht
➢ Falls im TLB vorhanden: bingo! (TLB hit)
➢ Andernfalls in der Seitentabelle die Seite suchen und Seitenrahmennummer
entnehmen (TLB miss)
➢ Gegebenfalls die Seite ins TLB laden
• Aus Seitenrahmennummer und Offset physikalische Adresse berechnen
•
Abbildung 80: Schema Translation Lookaside Buffer
Behandlung eines TLB-Fehlers in Software:
Wenn ein TLB-Miss stattfindet, so wurde dies früher in Hardware behandelt (laden der Seite
über die Seitentabelle).
Moderne Risc-Maschinen (SPARC, MIPS, Alpha, HP PA) implementieren einen TLB-miss
jedoch in Software; eine Spezialhardware ist nicht mehr nötig. Wird ein Eintrag nicht im TLB
gefunden, so wird ein TLB-Miss-Interrupt erzeugt, und das Betriebssystem kümmert sich
darum:
• es lädt den entsprechenden Eintrag aus der Seitentabelle
• führt ggfs. ein Update der TLB durch
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 115 of 170
- 115 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 7 “Zentralspeicherverwaltung“
•
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
komplexe Algorithmen sind hier möglich, z.B. das vorausschauende Lader der TLB mit
Seiten, die vermutlich als nächstes gebraucht werden.
Problem:
Bei einem TLB-miss muss die Seitentabelle befragt werden. Diese kann jedoch ebenfalls zu
einem TLB-miss führen, was zu einer verschlechterten Performance führt.
Abhilfe:
• Es wird ein Cache verwendet, z.B. 1024 Einträge, der in eine 4KB-Seite reinpasst. In
diesem Cache können TLB-Einträge zwischengespeichert werden, auf die dann schnell
zugegriffen werden kann. Diese Seite wird nie aus dem TLB entfernt, kann als immer
schnell zugegriffen werden.
7.5.6 Invertierte Seitentabellen
Bisher: Einträge in der Seitentabelle werden über die virtuelle Adresse indiziert, d.h. für jeden
Block im virtuellen Speicherraum gibt es einen Eintrag. Auf einem 32-bit System mit maximal
232 = 4.294.967.296 Bytes und einer Blockgröße von 4096 Bytes sind 1 Million Einträge in
der Seitentabelle nötig, d.h. 4 MB Speicher.
Für 64-Bit Rechner ist das nicht so einfach. Bei 264 Bytes und 4K Blockgröße sind 252
Einträge in der Seitentabelle nötig; bei 8 Byte / Eintrag ergeben sich über 30 Millionen GB!
Das ist nicht so einfach zu realisieren.
Ein anderer Ansatz ist die invertierte Seitentabelle. Hier wird ein Eintrag pro physikalischem
Seitenrahmen verwendet, anstelle einem Eintrag pro virtueller Seite. Die Größe des virtuellen
Speicher spielt dann keine Rolle mehr; entscheidend ist der physikalische Speicher. Bei einer
Seitenrahmengröße von 4K und 12 Bytes pro Eintrag müssen 0.3 % des physikalischen
Speichers für die Seitentabelle verwendet werden.
Beispiel:
Ein Rechner mit 64-Bit virtuellem Adressraum, 4 KB Seitengröße und 1 GB RAM benötigt
262144 Einträge; bei 12 Byte / Eintrag sind das 3 MB.
Nachteil:
• Umsetzung von virtueller auf physikalische Adresse ist nicht mehr direkt möglich, sondern
sie erfordert eine Suche in der invertierten Tabelle. Bei jedem Speicherzugriff ist dies nicht
möglich; steht jedoch ein ausreichender TLB zur Verfügung steht, so ist ein schneller
Speicherzugriff wieder möglich.
• Die Suche kann durch Hash-Tabellen oder andere Algorithmen weiter verbessert werden
(siehe folgende Abbildung c) )
Verwendung:
Inverierte Seitentabellen werden gegenwärtig in einigen IBM und HP Rechnern verwendet; bei
größerer Verbreitung von 64-Bit Rechnern werden sie häufiger eingesetzt werden.
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 116 of 170
- 116 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 7 “Zentralspeicherverwaltung“
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Abbildung 81: Seitentabelle a) normal b) invertiert c) mit Hash-Tabelle (nach [1])
7.5.7 Speicherschutz
Durch Paging kann Speicherschutz einfach realisiert werden:
• Jeder Prozess sieht einen eigenen Adressraum. Entweder er greift auf seine eigene Seite
zu (das darf er), oder eine Seite ist in der Seitentabelle als nicht vorhanden markiert. Dann
wird durch den Zugriff ein Seitenfehler ausgelöst & der Zugriff verhindert.
• Zudem können bestimmte Zugriffsrechte für jede Seite definiert werden, z.B. Read-Only,
Execute-Only.
Buffer-Overflow:
Der Buffer-Overflow ist eine der häufigsten und gefährlichsten Angriffsarten von Viren,
Würmern und Hackern.
In der Programmiersprache C werden lokale Daten (die nur innerhalb einer Funktion
gebraucht werden), auf dem Programm-Stack abgelegt. Dort liegt jedoch auch die
Rücksprungadresse, die nach Beendigung der Funktion aufgerufen wird.
Ein Buffer-Overflow-Angriff geht nun wie folgt:
Der Angreifer entdeckt eine Server- oder Betriebssystem-Funktion, die fehlerhaft
programmiert ist: sie legt ein Datenfeld (z.B. String) auf dem Stack ab, überwacht jedoch
nicht (oder nicht korrekt) die Länge des Datenfeldes. Der Angreifer manipuliert nun die
Eingangsdaten in diese Funktion in der Art, dass der Stack überläuft. Legt die Funktion z.B.
ein Datenfeld mit 100 Zeichen auf dem Stack an, so “füttert” der Angreifer die Funktion mit
200 Zeichen. Die ersten 100 Zeichen passen in das Datenfeld; die zweiten 100 Zeichen
überschreiben jedoch andere Daten auf dem Stack. Gelingt es dem Angreifer, die
Rücksprungadresse zu überschreiben, so kann er den Rücksprung der Funktion kontrollieren.
Hat der Angreifer z.B. ausführbaren Code in den 200 Zeichen Eingangsdaten untergebracht,
so kann der Angreifer dadurch die Kontrolle über das System übernehmen!
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 117 of 170
- 117 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 7 “Zentralspeicherverwaltung“
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Beispiele für einen Buffer-Overflow: Code Red (August 2001), Nimda (August 2001),
SQLSlammer (Februar 2003). Alle diese Würmer haben sich über das Internet verschickt:
die ersten beiden haben einen Buffer-Overflow im MS Internet Information Server
verursacht, der SQLSlammer im MS SQL Server.
Einfache Schutzmassnahme durch Trennung von Daten und Code: Dadurch kann Code, der
auf dem Stack gelegt wird, nicht ausgeführt werden.
Wird z.B. in OpenBSD verwendet (www.openbsd.org)
7.5.8 Gemeinsame Seiten
Mittels Paging kann gemeinsamer Speicher leicht realisiert werden:
Dieselbe Seite wird in mehrere Adressräume (von verschiedenen Prozessen) eingeblendet.
Änderungen in der Seite sind sofort in allen Prozessen sichtbar!
Achtung: bei Zugriff auf gemeinsamen Speicher sind Prozesssynchronisierungen nötig!
logischer Adressraum
von Prozess 2
logischer Adressraum
von Prozess 1
0xFFFFFFFF
11
11
10
10
9
9
physikalischer
Adressraum
8
7
6
Prozess1
8
7
6
5
5
sieht
0xFFFFFFFF
Shared
4
4
3
3
2
2
1
1
0
0
0
sieht
Prozess2
0
Seiten (P2)
Seiten (P1)
Seitenrahmen
Abbildung 82: Gemeinsamer Speicher durch Paging
7.5.9 Seitentauschstrategien
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 118 of 170
- 118 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 7 “Zentralspeicherverwaltung“
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Page 119 of 170
- 119 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 7 “Zentralspeicherverwaltung“
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Page 120 of 170
- 120 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 7 “Zentralspeicherverwaltung“
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Page 121 of 170
- 121 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 7 “Zentralspeicherverwaltung“
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Page 122 of 170
- 122 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 7 “Zentralspeicherverwaltung“
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Page 123 of 170
- 123 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 7 “Zentralspeicherverwaltung“
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Page 124 of 170
- 124 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 7 “Zentralspeicherverwaltung“
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Page 125 of 170
- 125 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 7 “Zentralspeicherverwaltung“
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Page 126 of 170
- 126 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 7 “Zentralspeicherverwaltung“
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Page 127 of 170
- 127 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 7 “Zentralspeicherverwaltung“
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
7.5.10Arbeitsmenge (Working Set)
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 128 of 170
- 128 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 7 “Zentralspeicherverwaltung“
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Page 129 of 170
- 129 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 7 “Zentralspeicherverwaltung“
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
7.5.11Praxisbeispiele
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 130 of 170
- 130 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 7 “Zentralspeicherverwaltung“
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Page 131 of 170
- 131 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 7 “Zentralspeicherverwaltung“
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Page 132 of 170
- 132 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 7 “Zentralspeicherverwaltung“
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Page 133 of 170
- 133 -
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Abschnitt 7 “Zentralspeicherverwaltung“
7.5.12Anforderungen an den Prozessor
Bei Seitenfehler: Unterbrechung der Prozessor-Anweisung -> muss später wiederholt werden!
Problem: nicht immer möglich!
Beispiel: Spezialbefehle die ganze Speicherbereiche kopieren, eg.
STRMOV Zieladresse, Quelladresse, Anzahl Bytes
Der Befehl kppiert einen ganzen Speicherbereich von der Quell- zur Zieladresse. Tritt dabei ein
Seitenfehler auf, so muss der Befehl wieder neu gestartet werden; dies ist jedoch nicht immer
möglich, da z.B. Quell-und Zielbereich überlappen können und Daten schon kopiert wurden.
Beispiel: indiziertes Lesen: lade den Speicherinhalt, auf den R1 zeigt, an die Speicherstelle, auf
die R2 zeigt; dabei wird R1 nach der Anweisung um eins erhöht, und R2 vor der Anweisung um
eins erniedrigt:
MOV (R1)+, -(R2)
Die Anweisung enthält 3 Speicherzugriffe; nach einer Unterbrechung ist unklar, welche Register
verändert wurden
-> Prozessor muss für virtuelles Speichermanagement geeignet sein!
Abhilfe:
• Schattenregister speichern den Prozessorzustand; dann kann der Zustand nach einem
Seitenfehler wieder hergestellt werden
7.5.13Nebeneffekte des Paging
•
•
Paging ist transparent für den Benutzer. Aber: Nebeneffekte sind möglich!
Paging kann zu Verzögerungen des Programms führen -> ungeeignet für Echtzeitsysteme
Beispiel: Seitengröße 4kByte; Programm benötigt Feld mit 1024 mal 1024 Integer-Zahlen
int i, j, a[1024][1024];
// schnelle Schleife:
for(i=0; i<1024; i++)
for(j=0; j<1024; j++)
a[i][j] = 0;
// langsame Schleife:
for(i=0; i<1024; i++)
for(j=0; j<1024; j++)
a[j][i] = 0;
Links 1024 Seitenanforderungen, rechts 1024*1024 !
7.6 Segmentierung
Kein linearer Speicher, sondern verschiedene Segmente. Jede Adresse wird durch zwei
Angaben gebildet: Segment und Offset im Segment. Die CPU kennt und arbeitet mit
verschiedenen Segmenten.
Typische Segmente:
• globale Daten
• Stack
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 134 of 170
- 134 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Abschnitt 7 “Zentralspeicherverwaltung“
•
•
Programmcode für jede Funktion
lokale Variablen jeder Funktion
Daten
(DATA)
Konstanten
(CONST)
Stack
(STACK)
Progr.
Text
(CODE)
Programm
Abbildung 83: Verschiedene Segmente eines Programmes
Abbildung der <Segment, Offset> Adresse auf die physikalische Adresse:
Abbildung 84: Segemente
Auch Kombinationen von Segmentierung und Paging möglich.
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 135 of 170
- 135 -
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Abschnitt 8 “I/O Systeme“
8 I/O Systeme
8.1 Allgemein
8.1.1 I/O Geräte
Unterscheidung in
• blockorientierte und
• zeichenorientierte Geräte
Ein blockorientiertes Gerät speichert oder verarbeitet die Daten in Blöcken, z.B. 512 Bytes
oder 32178 Bytes.
Beispiele: Festplatten, Bandgeräte, Zeilendrucker (eine Zeile = 132 Zeichen)
Ein zeichenorientiertes Gerät verarbeitet im wesentlichen einzelne Zeichen oder Gruppen
unterschiedlicher Größe, z.B. Tastatur, Maus, serielle Schnittstelle.
Die Grenzen zwischen beiden Arten sind jedoch fliessend, dennoch sind die meisten Treiber
der einen oder anderen Art zugeordnet.
Einige typische Geräte und ihre Datenraten sind in der folgenden Tabelle aufgeführt.
Tabelle 5: Übersicht I/O Geräte
Gerät
Datenrate
Gerät
Datenrate
Tastatur
10 Bytes/s
40x CDROM
6 MB/s
Maus
100 B/s
Fast Ethernet
12,5 MB/s
56K Modem
7 kB/s
ISA Bus
16,7 MB/s
ISDN mit Kanalbündelung
16 kB/s
EIDE (ATA-2) Festplatte
16.7 MB/s
Laserdrucker
100 kB/s
FireWire (IEEE 1394)
50 MB/s
Scanner
400 kB/s
XGA Monitor
60 MB/s
Ethernet
1,25 MB/s
SCSI Ultra 2 Festplatte
80 MB/s
USB
1.5 MB/s
Ultrium Tape
320 MB/s
Digitaler Camcorder
4 MB/s
PCI Bus
528 MB/s
IDE Festplatte
5 MB/s
Sun Giagplane XP Backbone
20 GB/s
8.1.2 I/O Gerätecontroller
Aufteilung des I/O Gerätes in einen mechanischen (das Gerät selbst) und einen elektronischen
Teil (den Gerätecontroller). Dies ist in der folgenden Graphik dargestellt.
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 136 of 170
- 136 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 8 “I/O Systeme“
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Abbildung 85: Übersicht Rechneraufbau
Beispiele:
• Lesen von Festplatte: Der Gerätecontroller liest die Bit-Folgen von der Festplatte ein,
überprüft die Checksumme (ECC) und gibt einen Rückgabestatus und den eingelesenen
Block zurück
• Serielle Schnittstelle: Ein Zeichen wird in den Controller geschrieben, der schickt dieses
dann Bit-für-Bit (mit Start-, Stop- und Parity-Bit) auf die Leitung
8.1.3 Adressierungsarten von I/O Geräten
Generell gibt es zwei unterschiedliche Adressierungsarten für I/O Zugriffe:
1. Getrennte CPU Befehle für Speicher- und I/O-Gerätezugriff:
• Eingabe
IN REG, PORT
•
Ausgabe
OUT REG, PORT
Dann sind die folgenden Befehle unterschiedlich:
IN R0, 4
MOV R0, 4
; lese I/O Port 4 in Register R0 ein
; lese Speicherzelle 4 in Register R0 ein
2. Speicher-gemapptes I/O (Memory-Mapped I/O): Die Geräteadressen werden in den
Adressraum des Speichers eingeblendet.
• Der Adressraum wird aufgeteilt in Speicher und I/O Adressen
• Die MMU muss Adresszugriffe entsprechend erkennen und umsetzen (gehört diese
Adresse zum Speicher oder zum I/O Adressbereich?)
Beispiel Embedded Bereich (siehe auch Abschnitt 7.1.5): Gegeben sei ein Prozessor, der im
Bereich 0xFFF00- 0xFFFFF Spezialregister zur Ansteuerung von I/O Geräten hat. Für den
Zugriff auf I/O und Speicher wird derselbe Befehl verwendet:
MOV R0, 0xFFFD1
MOV R0, 0xD0004
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
; lese serielles Empfangsregister nach R0 ein
; lese Speicherzelle 0xD0004 in Register R0 ein
Page 137 of 170
- 137 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 8 “I/O Systeme“
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Abbildung 86: Adressierungsarten für I/O Geräte (nach [1]): a) getrennte Befehle; b) MemoryMapped I/O; c) gemischt;
Für effektiven Speicherzugriff werden heutzutage spezielle hoch-performante Speicherbusse
verwendet, die nicht für I/O geeignet sind. Deshalb werden z.B. beim Pentium 2 Busse
eingesetzt, ein schneller für Speicherzugriffe und ein etwas langsamerer zur Anbindung vom
PCI-Bus (siehe folgende Abbildung und Abbildung 7: Pentium Busstruktur (aus [1])).
Abbildung 87: Busarchitektur für Memory-Mapped-I/O
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 138 of 170
- 138 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 8 “I/O Systeme“
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Abbildung 88: I/O Adressen eines PCs (nicht vollständig)
8.1.4 Polling
Prinzip: der I/O Controller hat ein Status-Bit, mit dem die Beendigung der Aktion angezeigt
wird.
Ablauf:
1. Gerät ist bereit.
2. CPU schreibt ein Kommando ins Kommando-Byte (und ggfs. ein Datenbyte ins
Datenregister) und setzt das Command-Ready-Bit.
3. Das I/O-Gerät liest das Kommando und das Datenbyte, setzt das Busy-Bit auf 1 und
beginnt die Abarbeitung der Aufgabe.
4. Derweil pollt die CPU regelmässig das Status-Bit
5. Wenn der Controller fertig ist, werden das Command-Ready und das Busy-Bit
zurückgesetzt; ggfs. wird ein Fehlerbit gesetzt.
6. Die CPU bemerkt die Beendigung und holt ggfs. das Ergebnis ab.
Beispiel: Das Schreiben einer Speicherzelle in einem EEPROM dauert typischerweise einige
Millisekunden. Die CPU wartet solange, bis das Busy-Bit zurück gesetzt wird, bevor sie den
nächsten Schreibvorgang startet.
8.1.5 Interrupts
Über eine Interrupt-Request-Line kann das Gerät einen Interrupt auf der CPU auslösen
Nummer des Interrupts am Adress-Bus -> mittels Vektor-Interrupt-Tabelle wird die
entsprechende Interrupt-Routine aufgerufen
• Kann maskable (abschaltbar) oder unmaskable (nicht abschaltbar) sein
• Verschiedene Interrupts können unterschiedliche Prioritäten haben, d.h. ein niederpriorer
Interrupt wird von einem höher-prioren Interrupt unterbrochen
•
•
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 139 of 170
- 139 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 8 “I/O Systeme“
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Abbildung 89: Vektor-Interrupttabelle des PCs
8.1.6 Direkter Speicherzugriff (Direct Memory Access, DMA)
Um die CPU beim Datentransfer von und zu den I/O Geräten zu entlasten, wird ein DMAController eingesetzt, der Zugriff auf den Speicher und die I/O Geräte hat. Er kann
unabhängig von der CPU einen Datentransfer durchführen und die Daten in den Speicher
schreiben bzw. von dort lesen.
Der allgemeine Ablauf ist wie folgt (lesender Zugriff):
1. Die CPU startet einen DMA-Transfer, indem sie den Controller entsprechend programmiert.
Wichtige Daten sind Anfangsadresse im Speicher, Adresse der Daten im I/O Gerät, Anzahl
der Bytes, sowie weitere Kontrollbefehle
2. Die DMA fordert ein oder mehrere Bytes vom I/O Gerät an
3. Das I/O Gerät legt die geforderten Bytes auf den PCI Bus
4. Die DMA liest die Bytes vom Gerät und schreibt sie an die gewünschte Stelle im
Speicher.Gegebenfalls werden die Schritte 2. bis 4. wiederholt, bis alle Daten in den
Speicher transferiert wurden.
5. Ist der Transfer beendet, so löst die DMA einen Interrupt in der CPU aus und
benachrichtigt diese, dass die Daten nun im Speicher vorliegen.
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 140 of 170
- 140 -
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Abschnitt 8 “I/O Systeme“
CPU
1. Initialisierung und
Start des Transfers
4. Daten werden in
Speicher geschrieben
5. Ende
DMA
CPU Speicherbus
Speicher
3. Gerät schickt Daten
PCI Bus
2. Anforderung der
Daten vom Gerät
IDE
Festplatten
controller
Abbildung 90: Schema DMA
Wichtig: Das virtuelle Speichermanagement muss auf die DMA abgestimmt sein. Es muss
vermieden werden, dass eine Seite aus dem Hauptspeicher entfernt wird, während die DMA
darauf zugreift. Seiten mit DMA-Zugriff müssen deshalb im Speichermanagement gesperrt
werden.
8.2 I/O Software Schichten
Generell ist es bei der Entwicklung eines Betriebssystems sinnvoll, eine möglichst einheitliche
Treiberarchitektur zu schaffen. Aufgrund der schnellen Hardware-Entwicklungszeiten müssen
immer neue Treiber ins Betriebssystem eingebunden werden. Standardisierte Schnittstellen
bieten die Möglichkeit, leicht neue Treiber hinzuzufügen, ohne andere Teile des OS ändern zu
müssen.
Ein Betriebssystem besteht typischerweise aus 4 Software-Schichten:
User-Level I/O Software
Geräte-unabhängige Betriebssystem-Software
Gerätetreiber
Interrupt-Handler
Hardware
8.2.1 Interrupt Handler
Unterste Ebene der I/O-Verarbeitung:
• Interrupt-Routine, wird direkt als Interrupt ausgeführt
• Input: Liest Geräte-Daten / Stati ein und schreibt diese in einen Puffer des Gerätetreibers
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 141 of 170
- 141 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 8 “I/O Systeme“
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Output: Entnimmt neue Daten / Kommandos aus den Puffern des Gerätetreibers und
schickt sie an das Gerät
• Interrupts sind schwierig zu programmieren:
• sehr Hardware-nah, genaue Kenntnisse der CPU und der Hardware sind nötig
• Synchronisierung mit dem Rest des Betriebssystems “per Hand” nötig,
typischerweise nur wenige Betriebssystemmittel zur Verfügung
• Interrupts dürfen keine Seitenfehler erzeugen -> sonst Blockade des
Betriebssystems möglich!
•
8.2.2 Gerätetreiber
Geräte-spezifischer Code zur Kontrolle des Gerätes, wird typischerweise vom Hersteller der
Hardware mitgeliefert
• Für jeden Typ von Hardware ein eigener Treiber, z.B. jeweils einer für Maus, Joystick,
Tastatur, Modem, ISDN-Karte
• Manchmal ein Treiber für mehrere ähnliche Geräte, z.B. SCSI-Kontroller für mehrere,
unterschiedliche Festplatten
• Treiber muss im Kernel laufen, da Hardware-Zugriffe nötig sind (-> Sicherheitsproblem!
Ein schlechter Treiber kann die Stabilität des OS gefährden!)
• Typischerweise ist ein Treiber entweder block-orientiert oder zeichen-orientiert.
• Treiber können fest in den Kernel kompiliert sein (frühere Unix-Varianten) oder dynamisch
nachgeladen werden. Letzteres kann entweder zum System-Startup geschehen (dann ist
nach Hardware-Updates ein Reboot nötig), oder zur Laufzeit, z.B. USB-Treiber für
Kameras.
Typische Aufgaben eines Gerätetreibers (Interface):
• Treiber-Initialisierung und Ende-Routinen
• I/O Systemaufrufe: open/close
• Geräte-Kontrollfunktionen, read/write, etc.
• Datentransfer-Routinen
• Timer (Zeitdienste)
• und weitere
Gerätetreiber und DRM (Digital Rights Management)
Ausgehend von der Musikindustrie gibt es Bestrebungen, ein DRM auf den Rechnern zu
etablieren. Dabei handelt es sich um Kontrollmechanismen, mit denen der Schutz der
Urheberrechte auf PCs durchgesetzt werden kann. Urheberrechte beziehen sich dabei auf die
Nutzung von Musikstücken, Filmen, Bildern, Dokumenten etc. Im wesentlichen soll ein
solches DRM das unerlaubte Abspielen von solchen Inhalten verhindern.
Technisch ist das jedoch nicht einfach. Der Schutz von Musikstücken muss sich z.B. von
der Quelle (CD, Internet) bis auf die Abspielgeräte erstrecken (d.h. im PC: Soundkarte).
Dabei geht es vor allem um die digitalen Daten; analog lässt sich natürlich jedes Musikstück
kopieren. Abspielgerät im PC ist die Soundkarte; die Daten müssen also auf dem gesamten
Weg bis zur Soundkarte geschützt werden:
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 142 of 170
- 142 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 8 “I/O Systeme“
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Das Sound-Aufzeichnungsprogramm totalrecorder (www.totalrecorder.com) installiert
sich z.B. in Form eines Soundtreibers im System. Spielt man die Musik auf diesem
“Soundtreiber” ab, so wird sie auf Festplatte in ein Datei geschrieben.
Um den PC DRM-fähig zu machen, dürfen also nur zertifizierte Sound-Treiber geladen
werden. Dass OS muss alle anderen Treiber verbieten oder zumindest keine DRMgeschützten Inhalte diesen Treibern überlassen.
• Auch wenn nur geschützte Treiber verwendet werden: während des Abspielvorganges
werden die Daten natürlich immer wieder im Speicher gehalten und z.B. von einem Puffer
in den nächsten kopiert. Gelingt es nun einem Programm, diese Speicherbereiche
auszuspionieren, so kann es die Musikdaten kopieren.
Die gesamte Verarbeitungskette von DRM-Material muss also geschützt werden.
• Dies betrifft auch die Hardware: sonst könnte ein findiger Bastler eine Soundkarte bauen,
die alle eintreffenden Daten auf einen Datenträger, z.B. Festplatte oder Speicher,
schreibt.
Das OS bzw. die Rechner-Hardware muss also alle Hardware-Geräte kontrollieren und
sicherstellen, dass diese nicht manipuliert wurden.
•
Trotz diesen Problemen ist die Industrie stark an der Entwicklung von DRM-Systemen
interessiert. Microsoft entwickelt entsprechende Konzepte für die nächste Generation des
Windows-Betriebssystems (Codename Longhorn), wie NGSCB (Next Generation Secure
Computing Base). Auch die benötigte Hardware befindet sich in der Entwicklung.
Weitere Aspekte von DRM sind neben der Technik (Hardware und Betriebssystem) die
rechtlichen und wirtschaftlichen Hintergründe und die sozialen Folgen dieser Technik. Eine
ausführliche Behandlung dieses Themas würde den Rahmen der Vorlesung sprengen.
Weitere Informationen dazu gibts im Internet (z.B www.heise.de/security, nach “ngscb”
suchen); eine aktuelle Beschreibung befand sich in Zeitschrift ct 12/04.
8.2.3 Geräte-unabhängige Software
Viele Teile eines Gerätetreibers sind geräte-unabhängig; typische geräteunabhängige
Aufgaben werden in den nächsten Abschnitten dargestellt.
8.2.3.1 Einheitliches Interface für alle Treiber
Wichtig, wenn neue Hardware zum System hinzukommt (dann will man nicht das Ganze
Betriebssystem ändern müssen). Deshalb verwendet man ein einheitliches Interface, dass alle
Treiber implementieren müssen.
8.2.3.2 Datenpufferung
Kopieren der Daten von und zu den User-Prozessen
Problem:
Typischerweise hat ein User-Prozess Daten von einem Gerät angefordert, z.B. von einer Datei
von der Festplatte. Dazu hat der User-Prozess einen Puffer angegeben, in dem diese Daten
geschrieben werden können. Dorthin soll der Gerätetreiber nun die Daten schreiben; da er
jedoch im Kernel-Mode läuft, hat er gar keinen Zugriff auf den Speicherbereich des UserProzesses!
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 143 of 170
- 143 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Abschnitt 8 “I/O Systeme“
Lösung: Das Betriebssystem stellt einen eigenen I/O Manager bereit, der Daten zwischen
User- und Kernelspace hin- und herkopieren kann, und der vom Gerätetreiber genutzt wird.
Abbildung 91: (a) Ohne Pufferung (b) User-Space Pufferung (c) Einfach-Pufferung (d)
Doppelte Pufferung (nach [1])
8.2.3.3 Fehlermeldungen
Standardisierte Fehlermeldungen und -behandlung, z.B. Gerät als inaktiv markieren,
Fehlermeldung ausgeben, System anhalten & rebooten
8.2.3.4 Belegung und Freigabe von Geräten (Resource-Handling)
Das OS stellt Funktionen zur Resourcen-Verwaltung zur Verfügung
8.2.3.5 Geräte-unabhängige Block-Größe
Die unterschiedlichen Block-Größen verschiedener Geräte wird versteckt, und nur eine
System-Blockgröße zurückgegeben. Ggfs. werden mehrere Blöcke zusammengefasst.
8.2.4 User-Space I/O Software
Stellt ein einheitliches Interface zur Hardware zur Verfügung:
• printf() Funktion zur Ausgabe von Zeichen
• Spooling, zur Verhinderung von Resourcen-Blockaden
8.3 Plattenlaufwerke
Es gibt verschiedene Typen von Plattenlaufwerken:
• Magnetische Disks (Festplatte, Floppies)
• CD-ROMs
• CD-R, CD-RW
• DVD
Im folgenden betrachten wir die Festplatte etwas näher.
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 144 of 170
- 144 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 8 “I/O Systeme“
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
8.3.1 Hardware
Physikalisches Prinzip:
Die Daten werden auf einer magnetischen Schicht gespeichert. Beim Schreiben wird über
einen Kopf (Head) ein Magnetfeld erzeugt, dass in der magnetischen Schicht gespeichert
wird. Beim Lesen wird das Magnetfeld mit demselben Kopf wieder ausgelesen.
Grundlagen der Hardware einer Festplatte (Zylinder, Tracks, Sektoren, etc.) werden wir nicht
behandeln (ggfs. im Tanenbaum [1] nachlesen).
Früher wurden die Festplatten vom Betriebssystem in
den Koordinaten Kopf, Zylinder und Sektor
angesprochen. Moderne Festplatten führen die
Adressierung selbst durch:
• Die Anzahl der Sektoren in einem Track ist
heutzutage typischerweise aussen höher als innen.
Bei konstanter Plattengeschwindigkeit ist die
Bitraten innen und aussen unterschiedlich (Constant
Angular Velocity, CAV). Alternativ wird auch die
Plattengeschwindigkeit variiert (Constant Linear
Velocity, CLV).
• Defekte Sektoren werden erkannt und vom
Festplattencontroller durch Reservesektoren ersetzt.
Das Betriebssystem adressiert die Festplatte in
logischen Blöcken adressiert, d.h. alle Blöcke sind
Abbildung 92: Festplatten-Geometrie durchnummeriert, beginnend mit Null. Die typische
und Bezeichnungen
Blockgröße beträgt 512 Bytes, obwohl auch andere
Größen möglich sind.
8.3.2 Zugriffsstategien
Begrenzende Faktoren für die Geschwindigkeit von Festplatten sind:
1. Zugriffszeit: die Zeit, die der Magnetkopf braucht, um auf den richtigen Zylinder bewegt zu
werden; typische Zugriffszeit heutzutage: 5-10 ms
2. Rotationsbedingte Latenz: Ist der Magnetkopf auf der richtigen Spur positioniert, muss
gewartet werden, bis der gesuchte Sektor vorkommt. Bei einer Drehzahl von 7200/min=
120/s beträgt die durchschnittliche Verzögerung etwa 4 ms. Teilweise werden höhere
Geschwindigkeiten eingesetzt, z.B. 10000/min bei Serverplatten.
3. Datentransferzeit: Einlesen der Daten, Aufbereitung und Übertragung in den
Hauptspeicher; Datentransferrate heutzutage etwa 40 MB/s
Ein entscheidender Faktor für die Geschwindigkeit von Festplatten ist also die Zugriffszeit.
Um die Plattenperformance zu steigern, wird der Zugriff auf die Platten optimiert. Dabei sind
folgende Kriterien zu beachten:
• Geringe Zugriffszeit: die Zugriffszeit soll minimiert werden (Verbesserung der Performance)
• Fairness: alle Anforderungen sollen möglichst gleich berücksichtigt werden; keine
Anforderung soll benachteiligt werden.
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 145 of 170
- 145 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 8 “I/O Systeme“
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
8.3.2.1 FCFS Scheduling
Die Anforderungen werden in der Reihenfolge abgearbeitet, in der sie ankommen. Der
Algorithmus ist an sich fair, da keine Anforderung benachteiligt wird. Allerdings ist die
Performance nicht besonders gut, was in folgendem Beispiel sichtbar wird:
Angenommen, die Anforderungen kommen in der folgenden Reihenfolge an:
98, 183, 37, 122, 14, 124, 65, 67.
Zu Beginn steht der Kopf auf 53. in der folgenden Graphik sind die Kopf-Bewegungen
dargestellt: problematisch ist z.B. der Wechsel von 122 zu 14 und wieder zurück zu 124, der
sehr zeitaufwändig ist; dabei hätten auch zugleich die Spuren 65 und 67 eingelesen werden
können.
Abbildung 93: Festplattenzugriffe FCFS (links) und SSTF (rechts), nach [2]
8.3.2.2 SSTF Scheduling (auch SST)
Die Performance wird gesteigt, indem immer die Spur angefahren wird, die sich am nächsten
an der augenblicklichen Kopfposition befindet (shortest-seek-time-first, SSTF). Dies ist am
Beispiel an der obigen Graphik gezeigt.
Der Algorithmus ist jedoch nicht fair: bei hoher Last, d.h. wenn permanent neue
Anforderungen ankommen, bewegt sich der Kopf immer weniger aus der Mittelposition
heraus. Anforderungen, die Randsektoren betreffen, haben dann eine sehr lange Wartezeit.
8.3.2.3 Aufzug-Algorithmus (SCAN)
Beim SCAN Algorithmus startet der Kopf an einem Ende der Platte, und fährt dann in
Richtung des anderen Endes, und arbeitet dabei alle Anforderungen ab. Dort angekommen,
ändert er seine Richtung, und setzt die Abarbeitung fort. Der Algorithmus wird manchmal
auch Aufzug-(Elevator)-Algorithmus, da derselbe Algorithmus auch bei Aufzugssteuerungen
eingesetzt wird.
Das Verhalten in in der folgenden Graphik dargestellt.
Verbesserungen vom SCAN Algorithmus sind der C-(Circular)-SCAN Algorithmus, in dem der
Kopf nur in eine Richtung fährt; ist er am Ende angekommen, fährt er schnellstmöglichst zum
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 146 of 170
- 146 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 8 “I/O Systeme“
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Abbildung 94: Festplattenzugriffe SCAN (links) und C-SCAN (rechts), nach [2]
Start zurück, ohne Anforderungen zu bearbeiten. Dort kehrt er seine Richtung um und
beginnt wieder von vorne.
8.3.3 Fehlerbehandlung
Schlechte Sektoren werden durch Ersatzsektoren ausgetauscht.Dazu sind in jeder Spur einige
Ersatzsektoren vorgesehen (siehe folgende Abbildung, links). Ist ein Sektor fehlerhaft, so wird
er durch einen Ersatzsektor ausgetauscht (b). Allerdings ist dann die Zugriffsfolge 6-7-8 sehr
ungünstig, da die Blöcke nicht kontinuierlich eingelesen werden können. Eine andere
Möglichkeit besteht darin, die folgenden Blöcke zu verschieben, um die Reihenfolge zu
erhalten (c).
Abbildung 95: Fehlerhafte Sektoren
8.3.4 Stabilität
Was passiert, wenn ein Fehler während eines Schreibvorgangs auftritt?
-> Stabile Schreibvorgänge nötig
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 147 of 170
- 147 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 8 “I/O Systeme“
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
8.4 Serielle Schnittstelle
8.4.1 Grundlagen der Asynchronen Seriellen Kommunikation (RS232)
Datenlänge 7 oder 8 Bit
1 Start-Bit, 1 oder 2 Stop-Bits
Optional 1 Parity Bit, wobei Odd oder Even Parity möglich ist
TTL-Pegel 0 V (logisch 0) und 5 V (logisch 1); RS232 Pegel logisch 0 entspricht +12V
(+3V bis +15V), logisch 1 – 12V (-3V bis -15V)
• unterschiedliche Baud-Raten möglich; da asynchrone Kommunikation (keine ClockLeitung), müssen Empfänger und Sender vorher die Baudrate kennen (manche Geräte
haben jedoch eine automatische Baudratenerkennung)
•
•
•
•
Abbildung 96: RS232-Übertragung (7-Bit)
8.4.2 Controller-Register
Ein typischer Controller ist z.B. der UART 16550 (Universal Asynchronous Receiver
Transmitter). Das Prinzip ist immer dasselbe:
• Senderegister (1 Byte oder mehr Byte)
• Empfangsregister (1 Byte oder mehrere Bytes, z.B. 16)
• Kontroll-Register, mit denen die wesentlichen Parameter eingestellt werden können:
• Baudrate, Datenlänge, Parity, Stop-Bits, etc.
• Ob und wann ein Interrupt ausgelöst werden soll, z.B. nach dem Empfang eines
Zeichens
• Fehlerbehandlung
• Erkennen von Datenübertragungsfehlern
• Erkennen von Leitungsbruch
8.4.3 Ansteuerung auf Interrupt-Ebene
Der Controller wird wie folgt angesteuert:
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 148 of 170
- 148 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 8 “I/O Systeme“
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Initialisierung und Setzen der Kontrollregister
Senden:
• Zu sendende Daten befinden sich in einem Puffer im Speicher.
• 1 oder mehrere Zeichen (je nach Fähigkeiten des UART) werden in den Sendepuffer
des UART kopiert. Dann wird die Sendung gestartet.
• Der UART sendet nun Bit für Bit auf der Leitung. Wenn er mit dem Zeichen fertig
ist, nimmt er das nächste Zeichen aus seinem Sendepuffer und sendet dieses. Ist
der Sendepuffer leer, wird ein Interrupt ausgelöst.
• Im Interrupt werden weitere Zeichen aus dem Puffer (im Speicher) in den Controller
kopiert und der vorige Schritt wird wiederholt.
• Wurden alle Zeichen gesendet, wird in der Interrupt-Routine ein entsprechendes
Flag gesetzt, damit das Hauptprogramm über das Ende der Bearbeitung
benachrichtigt wird.
• Empfangen analog. Beim Empfangen ist zu beachten, dass die Zeichen rechtzeitig aus dem
Controller ausgelesen werden müssen. Beträgt die Baudrate z.B. 115kBit, so werden etwa
11 Zeichen / Millisekunde empfangen. Beträgt der Empfangspuffer im Controller 16 Bytes,
so müssen er alle 1,5 Millisekunden ausgelesen werden. Wird das einmal versäumt, so
läuft der Empfangspuffer über und Zeichen gehen verloren.
•
•
8.4.4 Ansteuerung auf User-Ebene (Win32)
Windows (Win32) bietet folgende Funktionen zur Ansteuerung der seriellen Schnittstelle:
• Initialisieren der RS232 Schnittstelle mittels SetCommState() / GetCommState; dabei wird
eine Datenstruktur vom Typ DCB verwendet, die alle Einstellungen der Schnittstelle enthält
• Öffnen einer Kommunikation mittels CreateFile()
• Schreiben von Daten: WriteFile()
• Lesen von Daten: ReadFile()
• Asynchroner Datentransfer: Durch ein ReadFile() wird der Datentransfer initialisiert, und die
Funktion kehrt sofort zurück (ohne Daten!). Wurden die Daten eingelesen, so
benachrichtigt das OS das Programm, das die Daten nun vorliegen.
• Vorteil: bessere Performance, da das Programm nicht auf die Daten warten muss
• Nachteil: Sehr viel aufwändiger zu implementieren, da mehrere Threads nötig sind
und diese entsprechend synchronisiert werden müssen.
Mit all diesen Funktionen (CreateFile/ReadFile/WriteFile) können die unterschiedlichsten
Geräte angesprochen werden (Datei, Console, seriell, parallel, u.a.). Durch ein einheitliches
Interface wird der Umgang und die Programmierung vereinfacht. Zudem enthält das Win32
API dadurch weniger Funktionen. Funktionalität die allen Geräten gemeinsam ist – wie z.B.
asynchrone Funktionsaufrufe zur Ein/Ausgabe – kann mit denselben Funktionen erfüllt
werden. Ebenso eine einheitliche Fehlerbehandlung für alle Geräte
8.5 Weitere Geräte
Viele weitere Geräte: Uhren, Zeichen-Orientierter Tastaturen, Graphische User-Interfaces,
Netzwerk, Power-Management
behandlen wir leider nicht! -> Für Interessierte: einschlägige Literatur, z.B.[1]
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 149 of 170
- 149 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 9 “Dateisysteme“
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
9 Dateisysteme
Permanenter Speicher (Secondary Storage) ist definiert durch:
• Die Daten sind über das Prozessende hinaus verfügbar
• Daten können gelesen, geändert und neu geschrieben werden
• Es können je nach Anforderung beliebige Daten von verschiedenen Stellen des Mediums
gelesen werden (Random Access).
Typischerweiser permanenter Speicher ist die Festplatte, aber auch Bandlaufwerke, oder
NVRAM (non-volatile RAM, e.g. Flash oder EEPROM).
Das Betriebssystem verwendet Dateisysteme:
• um die Daten in Dateien zu speichern
• um die Dateien wiederzufinden
• und um die Daten wieder aus den Dateien zu lesen.
Ein Dateisystem hat dabei zwei Seiten:
• Zum einen eine Schnittstelle zum Benutzer. Diese definiert, wie Dateien benannt werden,
welche Attribute es gibt, die Operationen, die mit Dateien erlaubt sind, und wie die
Dateien angeordnet sind (Verzeichnisstruktur). Die Benutzerschnittstelle soll einfach sein,
jedoch sollen alle notwendigen Operationen enthalten.
• Zum anderen eine Implementierung, die die Dateien auf das physikalische Medium
abbildet. Sie muss entsprechende Datenstrukturen verwalten und Algorithmen
bereitstellen, um effiziente Zugriffe zu ermöglichen.
Dateisysteme sind in der Regel block-orientiert: die Daten werden in Blöcken gespeichert.
Typische Blockgrößen sind z.B. 512 Bytes, 1 KB, 4KB oder 8KB.
9.1 Dateien
9.1.1 Dateinamen
MSDOS 8.3-Notation:
• Dateiname 8 Zeichen
• Dateityp (Extension) 3 Zeichen
• Case-Insensitive: MeinText.txt, MEINTEXT.TXT und meintext.txt bezeichnen alle
dieselbe Datei
• ASCII Zeichensatz, nicht alle Zeichen erlaubt
• Andere Dateisysteme:
• Längere Dateinamen möglich, z.B. 255 oder 65535 Zeichen
• Andere Zeichensätze, z.B. Windows NT/2K/XP: Unicode
• Dateityp wird durch die Dateiendung definiert (MSDOS/Windows) oder durch eine magic
number, d.h. durch eine Kennung am Anfang der Datei. Anhand des Dateityps kann das
Betriebssystem verschiedene Unterscheidungen treffen, z.B. ob die Datei ausführbar ist
(.exe. oder .txt?), oder welches Programm zum Öffnen verwendet werden kann
•
Neben regulären Dateien verwendet das Betriebssystem Verzeichnisdateien, in denen die
Verzeichnisstruktur gespeichert wird. Weiterhin gibt es so spezielle Dateien, über die z.B. in
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 150 of 170
- 150 -
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Abschnitt 9 “Dateisysteme“
Unix Geräte eingebunden werden (Verzeichnis /dev). Unter Windows entspricht dies den
speziellen Laufwerken “COM1:”, “LPT3:” usw.
9.1.2 Dateistruktur und -zugriff
Eine Datei kann verschieden strukturiert werden:
1. Ein Feld von einzelnen Bytes
2. Ein Feld von einzelnen Blöcken
3. Baumartig nach einem Schlüssel (Key)
4. Bestehend aus mehreren Streams, d.h. mehreren Dateien (z.B. MacOS: Programm und
Resourcen-Stream)
V Bild
Einfachste Art des Zugriffs ist sequentiell, d.h. die Datei kann nur von Anfang bis Ende Bytefür-Byte (oder Block-für-Block) gelesen werden. Freier Zugriff ist mittels “random access”
möglich, wo das Programm an beliebiger Stelle positionieren und einlesen kann.
9.1.3 Datei-Attribute
Zu jeder Datei sind eine Reihe von Attributen möglich:
Tabelle 6: Mögliche Dateiattribute
Attribut
Bedeutung
Zugriffsrechte
Wer darf wie auf die Datei zugreifen? Z.B. Lese-, Schreib-,
Ausführungsrechte. Hier sind sehr komplexe Rechtesysteme
möglich
Erzeuger
Wer hat die Datei angelegt
Besitzer
Wem gehört die Datei?
Read-Only Flag
Nur lesender Zugriff möglich
Hidden Flag
Die Datei ist versteckt und wird im Listing nicht angezeigt
System Flag
Es handelt sich um eine System-Datei
Archiv Flag
Die Datei wurde seit dem letzten Archivieren modifiziert und
muss neu archiviert werden
Zeitpunkt der letzten
Änderung
Zeitpunkt des letzten Zugriffs
Größe
Dateigröße
Maximale erlaubte Größe
9.1.4 Dateioperationen
Typische Dateioperationen sind:
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 151 of 170
- 151 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 9 “Dateisysteme“
Operation
Beschreibung
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Unix
Win32
Erzeugen der Datei
eine Datei wird im Dateisystem
angelegt
creat()
CreateFile()
Öffnen der Datei
Beim Öffnen einer Datei muss der
Name sowie der gewünschte Mode
angegeben werden. Die Datei muss
bereits existieren.
open()
CreateFile()6
Löschen der Datei
Die Datei wird gelöscht.
remove()
DeleteFile()
Schließen der Datei
Die Datei wird geschlossen, alle
gecachten Daten werden auf
Festplatte geschrieben
close()
CloseHandle()
Lesen aus der Datei
Es wird eine bestimmte Anzahl von read()
Zeichen (oder Blöcken) aus der Datei
gelesen
ReadFile()
Schreiben in eine
Datei
Es wird eine bestimmte Anzahl von write()
Zeichen (oder Blöcken) aus der Datei
geschrieben
WriteFile()
Positionieren in der
Datei
Der Dateizeiger wird an eine Stelle in lseek()
der Datei posititioniert (random
access)
SetFilePointer()
Lesen der Attribute,
Ändern der Attribute
Umbenennen
Umbenennen einer Datei; oftmals
auch verschieben einer Datei
stat(),
chmod(),
chown(),
readlink()
GetFileAttributes(),
SetFileAttributes()
rename()
MoveFile()
Eine vollständige Liste aller Win32-Dateifunktionen findet sich weiter unten.
9.1.5 Memory-Mapped Files
Zugriff auf eine Datei über die Zugriffsoperationen ist umständlich und aufwändig.
Eigentliches Ziel ist es, die Daten aus der Datei in den Hauptspeicher zu transportieren, um
sie dort zu bearbeiten. In modernen Betriebssystemen gibt es bereits einen Mechanismus, der
sehr effektiv Dateien von und zum Hauptspeicher bringen kann: das virtuelle
Speichermanagement.
Bei Memory-Mapped Files wird das Speichermanagement angewiesen, bestimmte Seiten im
Hauptspeicher auf die Datei abzubilden. Alle Änderungen in diesen Seiten werden wieder in
die Datei zurückgeschrieben.
Dabei gelten folgende Eigenschaften:
• Große Dateien (z.B. 6 GB Video) können nicht komplett in den Speicher eingeblendet
werden. Dann müssen jeweils Teile davon eingeblendet werden.
Die Win32 Funktion OpenFile() gibt es nur aus Kompatibilitätsgründen und sollte nicht verwendet
werden.
6
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 152 of 170
- 152 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Abschnitt 9 “Dateisysteme“
Oftmals können nicht beliebige Stücke eingeblendet werden, sondern nur vielfache der
Seitengröße. Unter Win32 z.B. können nur 64kB-Blöcke bearbeitet werden.
• Ein Problem ist das Dateiende: Da das virtuelle Speichermanagement immer nur ganze
Seiten betrachtet, weiss es nicht, wieviele Bytes in der letzten Seite zur Datei gehören.
Deshalb muss das Programm typischerweise die Dateigröße angeben; diese kann auch bei
geöffneten Dateien geändert werden.
•
logischer
Adressraum
Memory-Mapped File
0xFFFFFFFF
physikalischer
Speicher
11
10
9
MMU
8
6
3
7
6
5
myfile.dat
6
1
5
4
3
2
1
0
0
0
3
5
1
Seitenrahmen
0
pagefile.sys
Seiten
Auslagerungsdatei
Abbildung 97: Virtueller Speicher und Memory-Mapped Files
9.2 Verzeichnisse
9.2.1 Verzeichnisse mit einer Ebene
Alle Dateien befinden sich in einem Verzeichnis, dem sog. root-Verzeichnis.
Beispiel: CPM-Betriebssystem, erste MS-DOS Version
9.2.2 Verzeichnisse mit zwei Ebenen
Im root-Verzeichnis befinden sich eine Reihe von Unterverzeichnissen, in denen die
eigentlichen Dateien liegen.
9.2.3 Hierarchische Verzeichnisstrukturen
Es sind beliebige Verzeichnisstrukturen möglich. Jedes Verzeichnis kann beliebig viele Dateien
und Unterverzeichnisse besitzen (Baumförmige Struktur).
9.2.4 Dateipfade
Um Dateien in einem Verzeichnisbaum zu finden, muss der gesamte Pfad (beginnend vom
root-Verzeichnis) angegeben werden. Alternativ können auch relative Pfade angegeben
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 153 of 170
- 153 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 9 “Dateisysteme“
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
werden. Zusätzlich hat jedes Verzeichnis die zwei Spezialverzeichnisse “.” (das Verzeichnis
selbst) und “..” (das übergeordnete Verzeichnis).
9.2.5 Verzeichnis-Operationen
Typische Operationen im Verzeichnisbaum sind:
• Erzeugen eines Verzeichnisses
• Löschen eines Verzeichnisses
• Verzeichnis lesen (Öffnen, Lesen, Schließen)
• Umbenennen
• Verlinken. Mit einem Link kann innerhalb des Dateisystems eine Datei mehrere Namen
besitzen.
9.2.6 Links
In Unix-Dateisystemen können Links gesetzt werden. Durch ein Link wird ein DateisystemObjekt (Datei oder Verzeichnis) über einen anderen Pfad und Namen angesprochen; das
Objekt hat dann zwei Namen im Dateisystem.
Dabei gibt es zwei Arten:
• Symbolische Links entsprechen den Verknüpfungen unter Windows. Ein symbolischer Link
deutet jeweils auf die entsprechende Zieldatei oder das Zielverzeichnis. Wird das Ziel
gelöscht, so zeigt der Link ins Leere.
Symbolische Links sind manchmal verwirrend.
• Harte Links sind eine Eigenschaft des Dateisystems: damit können mehrere Namen und
Pfade für eine Datei vergeben werden. Bei harten Links gibt es keine Unterscheidung
zwischen der Datei (Originaldatei) und dem Link: der harte Link ist ein weiterer Name für
die Datei und gleichbedeutend mit dem Orignalnamen.
Beispiel: Legt man im Verzeichnis test1 eine Datei x.txt an, und zusätzlich ein harten Link
y.txt, der auf x.txt zeigt, so kann die Datei sowohl unter ./test1/x.txt als auch unter ./y.txt
angesprochen werden. Wird einer der beiden Einträge entfernt, so bleibt die Datei
bestehen und ist immer noch unter dem anderen zu erreichen. Erst wenn der letzte Eintrag
gelöscht wird, werden auch die Daten gelöscht.
Harte Links sind oft verwirrend.
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 154 of 170
- 154 -
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Abschnitt 9 “Dateisysteme“
A
a
b
c
B
Wurzelverzeichnis
C
Verzeichnis
d
D
f
Legende:
a
b
Symbolischer Link
(Verknüpfung)
E
c
Datei
d
A
Verzeichniseintrag
mit Namen A
Harter Link: /A/c und /d
bezeichnen dieselbe Datei
Abbildung 98: Links
9.2.7 Mount-Punkte
Unter Windows hat jede Partition, jedes Netzlaufwerk und jedes Dateisystem einen eigenen
Laufwerksbuchstaben.
In der Unix-Welt gibt es keine Laufwerksbuchstaben: im Dateisystem können durch MountPunkte andere Dateisysteme eingefügt werden.
Mount-Punkte werden in die System-Datei fstab eingetragen und durch das Mount-Programm
durchgeführt.
Wurzelverzeichnis
A
5
6
B
7
C
8
D
X
1
2
Q
Y
3
4
Mount-Punkt
a
b
c
Andere Partition,
anderes Dateisystem,
Netzlaufwerk
Abbildung 99: Mount-Punkt im Verzeichnis
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 155 of 170
- 155 -
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Abschnitt 9 “Dateisysteme“
9.3 Implementierung von Dateisystemen
9.3.1 Partitionierung von Festplatten
Typischerweise werden Dateisysteme auf Festplatten installiert. Eine Festplatte kann nun
mehrere Partitionen unterstützen; in jeder Partition kann ein eigenes Dateisystem installiert
werden. Der MBR enthält Informationen über die Partitionsverteilung auf der Festplatte.
Er befindet sich typischerweise im ersten Block der Festplatte (Block 0).
Eine Partition ist im MBR als aktiv gekennzeichnet; beim Booten des Rechners liest das BIOS
den MBR aus, sucht die aktive Partition, lädt von dort den boot block und führt ihn aus. Der
boot block der Partition enthält den Start-Code für das Betriebssystem.
Partitionstabelle
MBR
Partition 1
Boot
VerzeichnisFAT
FAT
Block
struktur
Abbildung 100: Partitionen
Partition 2
Partition 3
Dateien
9.3.2 Implementierung von Dateien
Die Daten eines Programmes werden in den Dateien in Form von Blöcken gespeichert. Eine
Datei besteht somit aus einer geordneten Menge vom N Blöcken { B0, B1, ..., BN-1}.
Der Zugriff erfolgt entweder sequentiell, d.h. die Blöcke werden nacheinander in ihrer
Reihenfolge eingelesen, oder als wahlfreier Zugriff (random access), d.h. es werden beliebige
Blöcke nacheinander gelesen.
Die Speicherung kann wie folgt geschehen:
9.3.2.1 Kontinuierliche Belegung
Jede Datei besteht aus einer Folge von Blöcken; dabei müssen alle Blöcke kontinuierlich
angeordnet sein. Ist eine Datei also 10 Blöcke groß und beginnt bei Block 4711, dann belegt
sie die Blöcke 4711 – 4720.
Die Vorteile liegen vor allem in der Einfachheit:
• Einfache Verzeichnisstruktur: die Datei ist durch Anfangsblock und Größe eindeutig
beschrieben
• Zugriff auf die Datei ist einfach: beim sequentiellen Zugriff werden die Blöcke
nacheinander, beginnend beim ersten Block b, gelesen. Bei wahlfreiem Zugriff (random
access) auf Block i wird entsprechend der Block b+i gelesen.
Die kontinuierliche Belegung hat jedoch schwerwiegende Nachteile:
• Wird eine neue Datei angelegt, so muss ein entsprechend großer Platz auf der Festplatte
gefunden werden. Die Probleme sind dieselben wie beim Swapping (siehe Abschnitt 7.4):
• Verwaltung der freien Bereiche (Bitmaps oder verlinkte Liste)
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 156 of 170
- 156 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 9 “Dateisysteme“
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Externe Fragmentierung tritt auf; dem kann nur durch gelegentliche Kompaktierung
begegnet werden, was jedoch sehr zeitaufwändig ist.
• Passender Algorithmus für die Verteilung ist nötig (Best Fit, First Fit, Worst Fit)
• Ein schwerwiegender Nachteil besteht darin, dass bei kontinuierlicher Belegung die
maximale Größe zu Beginn bekannt sein muss. Beginnt der Benutzer z.B. ein WordDokument zu schreiben, so könnte das System 100 Blöcke zu 512 Bytes reservieren;
schreibt der Benutzer jedoch mehr als 50kB, so reicht der Platz nicht aus. Befindet sich
hinter dem Bereich bereits eine neue Datei, so kann die Datei nicht vergrößert werden,
sondern sie muss komplett in einen größeren freien Bereich verschoben werden. Das ist
sehr aufwändig ist.
Wegen dieser Nachteile wird die kontinuierliche Belegung heutzutage nicht mehr verwendet.
•
Datei A
Datei B
Datei C
frei
Abbildung 101: Kontinuierliche Belegung
9.3.2.2 Verlinkte Liste
Eine andere Methode besteht darin, alle Blöcke einer Datei miteinander zu verlinken. Der
Verzeichniseintrag zeigt dann auf den ersten Block der Datei; dieser zeigt auf den zweiten
Block, der wiederum auf den dritten, usw.
Vorteile:
• Die Datei kann beliebig wachsen: bei Bedarf kann ein beliebiger Block auf der Festplatte
hinten an die Datei angehängt werden, und es müssen nur die entsprechenden Links
angepasst werden.
• Einfacher sequentieller Zugriff: durch folgen der verlinkten Liste können die Blöcke
nacheinander gelesen werden.
Nachteile:
• Wahlfreier Zugriff ist nicht möglich. Soll der i-te Block der Datei gelesen werden, so muss
die verlinkte Liste vom Beginn bis zum i-ten Block verfolgt werden
• In jedem Block muss ein Zeiger auf den nächsten Block gespeichert werden. Beträgt die
Blockgröße 512 Bytes, und werden 4 Bytes für den Zeiger benötigt, so wird insgesamt
0,78 % des verfügbaren Platzes für Zeigerinformationen benötigt.
Cluster: jeweils mehrere Blöcke werden zu einem Cluster zusammengefasst: weniger Platz
für Zeiger, jedoch höhere interne Fragmentierung.
• Sind die Blöcke einer Datei weit auf der Festplatte verstreut, wird der sequentielle Zugriff
durch die vielen Kopf-Bewegungen verlangsamt.
• Zuverlässigkeit: tritt mitten in der Datei ein Fehler auf und ist der Zeiger auf den nächsten
Block fehlerhaft, so ist der Rest der Datei verloren.
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 157 of 170
- 157 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 9 “Dateisysteme“
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Datei C
Datei B
Datei A
Abbildung 102: Verlinkte Liste
9.3.2.3 FAT
Die Nachteile der verlinkten Liste können durch eine File-Allocation-Table (FAT) ausgeglichen
werden. Die FAT speichert dabei die Verlinkung der einzelnen Dateiblöcke. Ein
Verzeichniseintrag für eine Datei enthält einen Zeiger auf den ersten Block der Datei. Mit
diesem Zeiger kann aus der FAT der jeweils nächste Block ermittelt werden. Nicht benutze
Blöcke werden mit 0 gekennzeichnet (siehe Graphik).
Um einen schnellen wahlfreien Zugriff zu ermöglichen, wird die gesamte FAT im
Hauptspeicher gehalten. So kann beim Zugriff auf den i-ten Block einer Datei schnell die
verlinkte Liste durchsucht und der entsprechende Block gefunden werden. Anschließend wird
der gefundene Block von Festplatte geladen.
Eigenschaften:
• Dieses Verfahren wird bei MS-DOS und OS/2 verwendet.
• Die FAT wird typischerweise am Beginn der Partition gespeichert.
• Zuverlässigkeit: tritt in der FAT ein Fehler auf, so sind die betroffenen Dateien unter
Umständen komplett verloren. Deshalb ist die FAT immer zweimal gespeichert; alle
Änderungen werden erst in der einen, dann in der anderen durchgeführt. Jede FAT ist
dabei durch eine Prüfsumme geschützt; tritt ein Fehler auf, so wird dies an der falschen
Prüfsumme erkannt, und stattdessen kann die andere, korrekte FAT verwendet werden.
• Größe der FAT: die FAT muss für jeden Block einen Zeiger bereitstellen. Eine 8 GB
Festplatte besitzt 16 Millionen Blöcke zu 512 Bytes; werden 4 Bytes / Zeiger benötigt, so
ist die FAT 64 MB groß! Durch Cluster-Bildung kann dies reduziert werden; werden z.B. 8
kB Cluster eingesetzt, so ist die FAT nur noch 4 MB groß. Da sie jedoch im Hauptspeicher
gehalten werden muss, ist das immer noch viel. Für große Festplatten ist das Verfahren
also nicht besonders gut geeignet.
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 158 of 170
- 158 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 9 “Dateisysteme“
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Abbildung 103: FAT (aus [1])
9.3.2.4 Indizierte Belegung (I-Nodes)
Anstelle die Zeiger jeweils in den Blöcken zu speichern, werden bei der indizierten Belegung
alle Blockzeiger einer Datei zentral in einem I-Node (Index-Knoten) gespeichert. Wird ein
bestimmter Block der Datei benötigt, so kann dieser direkt aus dem I-Node ermittelt werden.
Aus Effizienzgründen ist ein I-Node oftmals genau einen Block groß. Wie können nun große
Dateien, die mehr als einen I-Nodes benötigen, verwaltet werden?
• Alle I-Nodes werden in einer verlinkten Liste gespeichert. Der letzte Zeiger eines I-Nodes
zeigt dann auf den nächsten I-Node der Datei.
• Alternativ können auch zwei Hierarchieebenen verwendet werden: der erste I-Node einer
Datei zeigt jeweils auf Sub-I-Nodes; diese wiederum zeigen auf die Blöcke der Datei. Auch
mehr als zwei Hierarchieebenen sind möglich.
• Auch Kombinationen sind möglich: Besitzt ein Verzeichniseintrag z.B. Platz für 15 Zeiger,
so können diese wie folgt verwendet werden:
• Die ersten 12 Zeiger zeigen auf direkt auf die Blöcke der Datei. Bei einer Blockgröße
von 4kB können so 48 kB an Daten verwaltet werden; somit wird für kleine Dateien
kein weiterer I-Node benötigt.
• Der 13te Zeiger zeigt auf einen I-Node, der direkt die Blöcke der Datei adressiert.
• Der 14te Zeiger zeigt auf einen doppelt-indirekten I-Node: dieser I-Node zeigt
jeweils auf weitere I-Nodes, die die Blockadressen enthalten.
• Der 15te Zeiger enthält eine dreifache Indirektion: er zeigt auf I-Nodes, die jeweils
auf weitere I-Nodes zeigen, die wiederum auf weitere I-Nodes zeigen. Dadurch
können auch sehr große Dateien komplett verwaltet werden.
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 159 of 170
- 159 -
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Abschnitt 9 “Dateisysteme“
Abbildung 104: I-Node (direkt sowie einfache, zweifache und dreifache Indirektion) (aus [1])
9.3.3 Implementierung von Verzeichnissen
9.3.3.1 Lineare Liste
Das Verzeichnis wird als lineares Feld gespeichert; jeder Eintrag bezeichnet eine Datei und
enthält zumindest den Dateinamen und einen Zeiger auf die Daten.
FAT
Verzeichnis
Dateiname
test.txt
Beispiel.doc
Programm.exe
Vorlesung.doc
Klausur.doc
Attribute
R/W
Read-Only
R/X
R/W
Hidden
Block
5
0
2
11
7
0
1
1
-1
2
12
3
4
4
-1
5
3
6
-1
7
8
8
9
9
-1
10
-1
11
-1
12
13
13
-1
Disk
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Abbildung 105: Verzeichnis (lineare Liste)
Vorteile:
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 160 of 170
- 160 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 9 “Dateisysteme“
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Einfache Implementierung
Nachteile:
• Lineare Suche in der Liste ist nötig -> schlechte Performance
• Alternativ kann das Verzeichnis immer sortiert sein, dann ist jedoch Einfügen oder Löschen
von Dateien aufwändig
• Eine andere Möglichkeit sind binäre Bäume, die immer sortiert sind.
•
Im MS-DOS wurde ein einfaches Feld verwendet:
• max. 255 Einträge in einem Verzeichnis möglich
• Löschen einer Datei -> im Verzeichnis wird der erste Buchstabe gelöscht,
Löschen von Dateien
Beim Löschen einer Datei wird im Verzeichnis der erste Buchstabe des Dateinamens
gelöscht, damit ist dieser Verzeichniseintrag frei und kann beim Anlegen einer neuen Datei
wiederverwendet werden. Die Blöcke der Datei werden in die Liste der freien, verfügbaren
Blöcke aufgenommen; die FAT-Einträge selbst bleiben erhalten, bis sie durch Überschreiben
einer anderen Datei gelöscht werden.
Wurde eine Datei unter MS-DOS gelöscht, so kann sie unmittelbar danach wieder komplett
hergestellt werden. Dazu gibt es Spezialprogramme wie z.B. undelete, die die
Verzeichnisliste nach gelöschten Dateien durchsuchen (erste Buchstabe gelöscht), und eine
Wiederherstellung versuchen. Wurden die Blöcke der gelöschten Datei noch nicht durch eine
andere Datei belegt, so kann die Datei wiederhergestellt werden; nur der erste Buchstabe
des Dateinamens muss vom Benutzer eingegeben werden. Ist jedoch einige Zeit vergangen,
so ist die Wahrscheinlichkeit groß, dass Blöcke durch andere Dateien überschrieben wurden;
in diesem Fall sind die Daten nicht mehr vorhanden.
Alte Festplatten stellen ein Sicherheitsrisiko dar; werden die Festplatten ohne spezielle
Maßnahmen entsorgt (z.B. in den Müll geschmissen), so können die Daten meistens wieder
hergestellt werden. Auch löschen oder neu formatieren reicht nicht aus.
Um Daten auf einer Festplatte sicher zu löschen, müssen spezielle Löschprogramme
verwendet werden. Diese überschreiben jeden Block der Datei mehrfach (3-27 mal) mit
wechselnden Folgen von Nullen und Einsen; dadurch wird zuverlässig die Magnetisierung
einzelner Bits gelöscht.
Eine Alternative ist die physikalische Zerstörung der Festplatte: schreddern (in viele, kleine
Teile), Plattenoberfläche stark zerkratzen oder anderweitig zerstören, einschmelzen.
9.3.3.2 Hash-Tabelle
Aus dem Dateinamen wird ein Hash-Wert gebildet, über den der Eintrag einem Feld
ausgelesen werden kann.
9.3.4 Freispeicherverwaltung
Wenn eine neue Datei angelegt oder eine bestehende erweitert wird, so wird dazu freier
Speicher benötigt. Der freie Speicher auf einer Festplatte muss also verwaltet werden:
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 161 of 170
- 161 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 9 “Dateisysteme“
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Bei Bedarf (Anlegen einer neuen Datei, Erweiterung einer bestehenden) werden freie
Blöcke benötigt
• Gegebenfalls werden Blöcke frei (z.B. Löschen einer Datei), die anderen Dateien zur
Verfügung stehen
Die verschiedenen Algorithmen dazu haben wir bereits bei der Freispeicherverwaltung des
Hauptspeichers besprochen (siehe Abschnitt 7.4.4Verwaltung von freien Speicherbereichen).
Die wichtigsten Verfahren sind:
• Freier Speicher in Bitmaps: Jedes Bit entspricht einem Block; eine Null bedeuted, der Block
ist frei, andernfalls ist er belegt
• Verlinkte Liste des freien Blöcke
•
Abbildung 106: Liste freier Blöcke
9.3.5 Implementierung von Links (Verknüpfungen)
9.3.5.1 Harter Link
Harte Links sind Bestandteil des Unix-Dateisystems. Dabei können mehrere
Verzeichniseinträge auf dieselbe Datei (Inode) verweisen. Zusätzlich zu den bisherigen
Eigenschaften besitzt ein Inode einen Referenzzähler, der zählt, wieviele Verzeichniseinträge
auf diese Datei verweisen:
• Wird ein harter Link auf eine Datei angelegt (mittels ln Befehl), so wird ein neuer
Verzeichniseintrag angelegt, der auf denselben Inode verweist wie der Orginalname. Der
Referenzzähler im Inode wird um eins hochgezählt. Für das Dateisystem sind alle
Verzeichniseinträge, die auf denselben Inode verweisen, gleichberechtigt.
• Wird eine Datei gelöscht, so wird zunächst der Referenzzähler des Inodes um eins
erniedrigt. Ist der Zähler größer als Null, so wird nur der Verzeichniseintrag gelöscht; die
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 162 of 170
- 162 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 9 “Dateisysteme“
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Datei selbst bleibt bestehen und ist unter anderem Namen erreichbar. Erst wenn der letzte
Verzeichniseintrag der Datei gelöscht ist (Referenzzähler gleich Null), so wird die Datei
selbst gelöscht.
Beispiel:
• Die Datei in der folgenden Graphik ist unter zwei Verzeichniseinträgen zu erreichen:
/Verzeichnis1/Name1 und /Verzeichnis1/Verzeichnis2/Name2.
• Wird z.B. /Verzeichnis1/Name1 gelöscht, so wird der Referenzzähler im Inode um eins
erniedrigt; die Datei bleibt bestehen.
• Erst wenn auch /Verzeichnis1/Verzeichnis2/Name2 entferntwird, ist der Referenzzähler
Null und die Datei wird gelöscht.
Wurzelverzeichnis
Verzeichnis 1
Name1
Verzeichnis2
Verzeichnis 2
Name2
Datei (Inode)
Attribute
Referenzzähler: 2
Block 1
Block 2
Block 3
...
Abbildung 107: Implementierung eines harten Link
9.3.5.2 Verknüpfung (Symbolischer Link)
Eine Verknüpfung (symbolischer Link) enthält im wesentlichen den Pfad zu der Orginaldatei.
Wird die Verknüpfung geöffnet, so wird zunächst der Pfad zur Orginaldatei eingelesen;
anschließend wird diese geöffnet.
Eigenschaften:
• Wird die Orginaldatei gelöscht, so zeigt die Verknüpfung ins Leere; beim Öffnen der
Verknüpfung erfolgt eine Fehlermeldung.
• Eine Verknüpfung kann über mehrere Dateisysteme gehen (z.B. in ein
Netzwerkverzeichnis); ein harter Link muss immer im selben Dateisystem erfolgen.
9.3.6 Nicht-Funktionale Aspekte: Performance, Zuverlässigkeit, Effizienz
Dateisysteme sind ein wichtiger und oft benutzter Teil des Betriebssystems. Die Schnelligkeit
von Dateisystemen ist deshalb für den gesamten Betrieb des Rechners von Bedeutung. Dazu
gehören effektive Verwaltung der Verzeichnisse sowie der Blöcke einer Datei, ebenso wie
effektive Verwaltung der freien Blöcke. Oftmals werden Daten im Hauptspeicher gehalten,
um schnellen Zugriff zu ermöglichen.
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 163 of 170
- 163 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 9 “Dateisysteme“
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Die Daten im Hauptspeicher sind jedoch nicht permanent; beim ungeplanten Abschalten des
Rechners (z.B. bei Stromausfall oder Absturz des OS) gehen diese verloren. Dabei besteht die
Gefahr, das die Verwaltungsstrukturen auf der Festplatte inkonsistent sind:
• Stimmt z.B. die FAT-Tabelle auf der Festplatte nicht mehr, so können einzelne Blöcke einer
Datei verloren gehen
• in der Freiblockverwaltung können Blöcke fehlen; diese Blöcke sind weder frei verfügbar
noch gehören sie einer Datei an
• Die Verzeichnisstruktur kann Fehler enthalten, ganze Verzeichnisse können verloren gehen
Gegen all diese Fehler muss ein Dateisystem abgesichert sein. Ältere Dateisysteme
benötigten extra Korrekturprogramme, die im Fehlerfall die gesamte Partition untersucht
haben und deren Konsistenz wiederhergestellt haben. Beim Systemstart wurde das
Dateisystem überprüft und bei einem Fehler wurde eine Korrektur durchgeführt; dies dauerte
teilweise mehrere Stunden. Als Ergebnis erhielt man ein konsistentes Dateisystem, und
oftmals eine Reihe von Dateien, die Blöcke enthielten die keiner Datei zugeordnet wurden
(utner Unix z.B. in einem lost+found Ordner).
Zudem muss ein Dateisystem performant sein; die Geschwindigkeit des gesamten Systems
wird durch das Dateisystem bestimmt.
9.4 Protokollierende Dateisysteme (Journaling File Systems)
Alle Änderungen an den Metadaten (Verwaltungsdaten des File-Systems) werden zunächst in
eine Log-Datei geschrieben. Die Log-Datei ist transaktionsorientiert, d.h. alle
zusammengehörenden Aktionen werden als eine Transaktion behandlet. Wird z.B. eine neue
Datei angelegt, so umfasst das einen Eintrag ins Verzeichnis, belegen der benötigten Blöcke,
etc. Wurden alle Aktionen einer Transaktion ins Log geschrieben, so gilt die Transaktion als
committed. Anschließend werden im Hintergrund die entsprechenden Änderungen an den
Verwaltungsstrukturen durchgeführt. Wurden alle Aktionen erfolgreich durchgeführt, so wird
die Transaktion aus dem Log entfernt.
Stürzt das System ab, so sind Null oder mehr Transaktionen im Log vorhanden. Keine dieser
Transaktionen wurde erfolgreich beendet; sie werden alle neu aufgesetzt und beendet.
Transaktionen, die nicht committed wurden (sie wurden noch nicht komplett ins Logfile
geschrieben), werden nicht berücksichtigt. Im Fehlerfall ist die Konsistenz des Dateisystems
sehr schnell wiederhergestellt. Zusätzlich bieten JFS auch im Normalbetrieb PerformanceVorteile.
Viele moderne Dateisysteme verwenden diesen Ansatz, z.B. NTFS auf Windows-Rechnern,
UFS auf Solaris-Systemen, ReiserFS u.a. bei Linux-Systemen.
Beispiel für eine dateiorientierte Transaktion: eine Datei wächst, d.h. sie wird um einen Block
erweitert.
Nötig sind die folgenden Aktionen:
1. Freien Block im Dateisystem suchen
2. Freien Block als belegt markieren
3. Den neuen Block in die Verlinkung des Inodes aufnehmen
4. Größe der Datei anpassen.
Die Schritte 2-4 werden zu einer Transaktion zusammengefasst, da sie zusammen ausgeführt
werden müssen. Wird die Transaktion nicht komplett durchgeführt, so ist das Dateisystem
inkonsistent: bricht man z.B. nach Schritt 2 ab, so wurde 1 Block als belegt markiert, der
jedoch von keiner Datei benutzt wird.
Schritt 1 ist nicht Teil der Transaktion, da nur lesender Zugriff nötig ist.
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 164 of 170
- 164 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 9 “Dateisysteme“
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
9.5 Netzwerk-Dateisysteme: NFS
Das verbreitetste Netzwerk-Dateisystem ist NFS (Network File System) und wurde
ursprünglich von SUN entwickelt. Es erlaubt, Laufwerke über das Netzwerk anzusprechen.
Der Zugriff erfolgt dabei über RPC (remote procedure calls):
• auf dem Client findet ein Zugriff (Lesen/Schreiben/Öffnen etc.) auf ein Netzlaufwerk statt.
Der Client nimmt die Anfrage entgegen und leitet sie via RPC zum Server weiter.
• Der Server führt den Zugriff auf dem echten Dateisystem aus und schickt die Antwort an
den Client zurück.
• Das NFS-Laufwerk wird über einen Mount-Punkt ins Dateisystem gehängt; der ganze
Vorgang ist für den Benutzer transparent.
Abbildung 108: NFS Systemarchitektur
9.6 Beispiele
9.6.1 Win32-Schnittstelle (API)
In der folgenden Tabelle sind alle Dateioperationen der Win32 Schnittstelle aufgeführt:
Function
AreFileApisANSI
Description
Determines whether the file I/O functions are using the ANSI
or OEM character set code page.
CancelIo
Cancels all pending I/O operations that were issued by the
calling thread for the specified file handle.
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 165 of 170
- 165 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 9 “Dateisysteme“
Function
CloseHandle
CopyFile
CopyFileEx
CopyProgressRoutine
CreateDirectory
CreateDirectoryEx
CreateFile
CreateIoCompletionPort
DefineDosDevice
DeleteFile
FileIOCompletionRoutine
FindClose
FindCloseChangeNotification
FindFirstChangeNotification
FindFirstFile
FindFirstFileEx
FindNextChangeNotification
FindNextFile
FlushFileBuffers
GetBinaryType
GetCurrentDirectory
GetDiskFreeSpace
GetDiskFreeSpaceEx
GetDriveType
GetFileAttributes
GetFileAttributesEx
GetFileInformationByHandle
GetFileSize
GetFileSizeEx
GetFileType
GetFullPathName
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Description
Closes an open object handle.
Copies an existing file to a new file.
Copies an existing file to a new file.
An application-defined callback function used with CopyFileEx
and MoveFileWithProgress.
Creates a new directory.
Creates a new directory with the attributes of a specified
template directory.
Creates or opens a file object.
Creates and I/O completion port or associates an instance of
an opened file with a newly created or an existing I/O
completion port.
Defines, redefines, or deletes MS-DOS device names.
Deletes an existing file.
An application-defined callback function used with ReadFileEx
and WriteFileEx.
Closes the specified search handle.
Stops change notification handle monitoring.
Creates a change notification handle.
Searches a directory for a file whose name matches the
specified file name.
Searches a directory for a file whose name and attributes
match those specified.
Requests that the operating system signal a change
notification handle the next time it detects an appropriate
change.
Continues a file search.
Clears the buffers for the specified file and causes all
buffered data to be written to the file.
Determines whether a file is executable.
Retrieves the current directory for the current process.
Retrieves information about the specified disk, including the
amount of free space on the disk.
Retrieves information about the specified disk, including the
amount of free space on the disk.
Determines whether a disk drive is a removable, fixed, CDROM, RAM disk, or network drive.
Retrieves attributes for a specified file or directory.
Retrieves attributes for a specified file or directory.
Retrieves file information for a specified file.
Retrieves the size of a specified file.
Retrieves the size of a specified file.
Retrieves the file type of the specified file.
Retrieves the full path and file name of a specified file.
Page 166 of 170
- 166 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 9 “Dateisysteme“
Function
GetLogicalDrives
GetLogicalDriveStrings
GetLongPathName
GetQueuedCompletionStatus
GetShortPathName
GetTempFileName
GetTempPath
Int32x32To64
Int64ShllMod32
Int64ShraMod32
Int64ShrlMod32
LockFile
LockFileEx
MoveFile
MoveFileEx
MoveFileWithProgress
MulDiv
PostQueuedCompletionStatus
QueryDosDevice
ReadDirectoryChangesW
ReadFile
ReadFileEx
ReadFileScatter
RemoveDirectory
ReplaceFile
SearchPath
SetCurrentDirectory
SetEndOfFile
SetFileApisToANSI
SetFileApisToOEM
SetFileAttributes
SetFilePointer
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Description
Returns a bitmask representing the currently available disk
drives.
Fills a buffer with strings that specify valid drives in the
system.
Converts the specified path to its long form.
Attempts to dequeue an I/O completion packet from a
specified I/O completion port.
Retrieves the short path form of a specified input path.
Creates a name for a temporary file.
Retrieves the path of the directory designated for temporary
files.
Multiplies two signed 32-bit integers.
Performs a left logical shift operation on an unsigned 64-bit
integer value.
Performs a right arithmetic shift operation on a signed 64-bit
integer value.
Performs a right logical shift operation on an unsigned 64-bit
integer value.
Locks a region in an open file.
Locks a region in an open file for shared or exclusive access.
Moves an existing file or a directory.
Moves an existing file or a directory.
Moves a file or directory.
Multiplies two 32-bit values and then divides the 64-bit result
by a third 32-bit value.
Posts an I/O completion packet to an I/O completion port.
Retrieves information about MS-DOS device names.
Retrieves information describing the changes occurring within
a directory.
Reads data from a file, starting at the specified position.
Reads data from a file asynchronously.
Reads data from a file and stores the data into a set of
buffers.
Deletes an existing empty directory.
Replaces one file with another file.
Searches for the specified file.
Changes the current directory for the current process.
Moves the end-of-file position for the specified file.
Causes the file I/O functions to use the ANSI character set
code page.
Causes the file I/O functions to use the OEM character set
code page.
Sets a file's attributes.
Moves the file pointer of an open file.
Page 167 of 170
- 167 -
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Abschnitt 9 “Dateisysteme“
Function
SetFilePointerEx
SetFileSecurity
SetVolumeLabel
UInt32x32To64
Description
Moves the file pointer of an open file.
Sets the security of a file or directory object.
Sets the label of a file system volume.
Multiplies two unsigned 32-bit integers, returning an unsigned
64-bit integer result.
Unlocks a previously locked region in an open file.
Unlocks a previously locked region in an open file.
Writes data to a file.
Writes data to a file asynchronously.
Gathers data from a set of buffers and writes the data to a
file.
UnlockFile
UnlockFileEx
WriteFile
WriteFileEx
WriteFileGather
9.6.2 MS-DOS Dateisystem: FAT
Eigenschaften:
• 8 + 3 Namenskonvention (nur Großbuchstaben)
• Die erste Version (MS-DOS 1.0) hatte nur ein Verzeichnis, in dem alle Dateien lagen; die
nächsten Versionen erlaubten dann hierarchische Verzeichnisstrukturen.
• Links sind nicht erlaubt
• Kein Rechtesystem; jeder Benutzer hat Zugriff auf alle Dateien
• MS-DOS Verzeichniseintrag ist 32 Bytes groß und wie folgt aufgebaut:
Bytes
8
Name
3
Ext
1
Attr.
10
Reserviert
2
Zeit
2
2
4
Datum
Erster
Block
Größe
Die einzelnen Einträge sind:
• Name und Typ (Extension) der Datei
• Attribute: R=Read-Only, H=Hidden (versteckt), A=muss archiviert werden,
S=Systemdatei
• 10 Bytes sind reserviert (unbenutzt)
• Zeit und Datum, an dem die Datei erzeugt wurde: die Zeit wird dabei in Einheiten
von 2 Sekunden angegeben (1Tag ist 86400 Sekunden), das Datum besteht aus 5
Bits für den Tag, 4 Bits für den Monat und 7 Bits für das Jahr (0 entspricht 1980;
somit reicht das Datum bis 2107; Achtung! Jahr-2108-Problem mit MS-DOS!!)
• Der erste Block bezeichnet den ersten Block der Datei in der FAT; von dort können
jeweils die nächsten Blöcke der Datei gefunden werden
• Größe der Datei: dadurch kann unter anderem im letzten Block das Ende der Datei
ermittelt werden.
• MS-DOS verwendet eine FAT für die Zuordnung der Beschreibung der Blöcke einer Datei:
• Zunächst FAT-12 für Floppies: bei 12 Bit = 4096 Blöcke und 512 Bytes / Block
können 2 MB addressiert werden
• Später FAT-16 mit 16-Bit Adressen. Diese Adresse adressiert einen Cluster d.h.
mehrere Blöcke auf einmal; dadurch können je nach Cluster-Größe unterschiedliche
Datenmengen adressiert werden:
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 168 of 170
- 168 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Abschnitt 9 “Dateisysteme“
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
Tabelle 7: Maximale Partitionsgrößen bei MS-DOS
Block Größe FAT-12
FAT-16
FAT-32
0,5 kB
2 MB
1 kB
4 MB
2 kB
8 MB
128 MB
4 kB
16 MB
256 MB
1 TB
8 kB
512 MB
2 TB
16 kB
1024 MB 2 TB
32 kB
2048 MB 2 TB
Bei größerer Clustergröße nimmt jedoch der interne Verschnitt der Dateien zu;
beträgt die Clustergröße z.B. 32 kB, so belegt jede Datei mindestens 32 kB, auch
wenn sie nur einige Bytes enthält.
9.6.3 NTFS
Hier ein Überblick über eine Eigenschaften von NTFS (für einen vollständigen Überblick, siehe
[1]):
• NTFS hat eine feste Blockgröße, von 512 Bytes bis 64 kB (meistens wird 4 kB
verwendet). Zur Adressierung eines Blocks wird eine 64-Bit Zahl verwendet.
• Hauptstruktur jeder NTFS-Partition ist die MFT (Master File Table), eine lineare Liste von 1
kB-großen Einträgen. Jeder Eintrag bezeichnet eine Datei oder ein Verzeichnis, und enthält
den Dateinamen, alle Attribute, und die verwendeten Blöcke. Große Dateien können mehr
als einen Eintrag besitzen.
• Freie MFT-Einträge werden über eine Bitmap verwaltet.
• Die MFT ist selbst eine Datei und kann irgendwo in dem Dateisystem vorhanden sein. Der
Boot-Block enthält einen Verweis auf die MFT.
• Dateien haben sowohl einen 8+3 Namen (für MS-DOS Kompadibilität) als auch einen
längeren Namen (in Unicode-Zeichen).
• Attribute von NTFS-Dateien sind unter anderem: Standardinformationen (Flag bits,
Zugriffszeiten, etc.), Dateiname, Sicherheitsattribute, Verweis auf weitere Attribute (falls
nötig)
• Kurze Dateien (einige hundert Bytes) werden direkt in der MFT gespeichert, anstelle von
Verweisen auf die benötigten Blöcke (reduziert Speicherbedarf für kleine Dateien)
• NTFS versucht, Dateien immer möglichst kontinuierlich zu speichern. Falls das gelingt,
reicht ein Eintrag auf den ersten Block, und die Anzahl der folgenden Blöcke; gelingt dies
nicht, so werden weitere Einträge verwendet, für jeden kontinuierlichen Bereich einen.
• NTFS bietet Komprimierung und Verschlüsselung für die Dateien
• NTFS ermöglicht mehrere Datenströme (Streams) in einer Datei: die Datei enthält mehrere
Datenströme, z.B. Video- und Audiodaten in unterschiedlichen Strömen. Wurde
ursprünglich implementiert, um MAC-Dateien in NTFS zu speichern: diese bestehen aus
zwei Strömen, den eigentlichen Daten und Metadaten.
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 169 of 170
- 169 -
FH Regensburg BT/SS04
“Betriebssysteme“ Wirtschaftsinformatik
Abschnitt 10 “Danksagung“
Dr. Ulrich Margull
Kirchweg 6 * 93055 Regensburg
Tel. (+49) 941 78956-8 Fax –9
www.margull.de
10 Danksagung
Herrn Prof. Dr. Schicker möchte ich für die Anregung danken, meine Skripten doch den
Studenten zur Verfügung zu stellen. Für die Unterstützung während der Vorlesung möchte
ich den Professoren Dr. Jobst und Dr. Söder danken, sowie Prof. Dr. Mandl von der FH
München. Herr Opel war für die Durchführung der Übungen zuständig und stand mir hilfreich
bei Fragen zur Seite.
Diese Vorlesung wäre ohne die Bücher von Tanenbaum [1] und Silberschatz et.al. [2] nicht
möglich gewesen.
Trotz der vielen Arbeit & Nachtschichten hat es Spass gemacht, diese Vorlesung zu halten.
Für mich war es lehrreich und interessant, und ich hoffe, dass es das auch für meine
Zuhörerinnen und Zuhörer war. Ihnen wünsche ich viel Glück bei der Klausur und Erfolg im
weiteren Studium und im Berufsleben.
Dr. Ulrich Margull
Regensburg, 30.06.2004
Dieses Skript wurde mit OpenOffice 1.1.1 in einer Datei erstellt. Zusammen mit
allen Bildern ist die Datei etwa 20 MB groß. Trotz einiger eigenartigen Effekte
(Bilder verschwanden und mussten neu eingefügt werden, Formatierungen
konnten nicht rückgängig gemacht werden, etc.) lies sich das Skript ohne
Probleme schreiben.
Der verwentete Font ist Univers.
File: 2004-ss-bt-vorlesung-buch.sxw
03/29/2004
Ausdruck vom: 7/26/2004
Page 170 of 170
- 170 -