Betriebssysteme - Institut für Verteilte Systeme

Transcription

Blätter zur Vorlesung
Betriebssysteme
Sommersemester 2003
Dr. Michael Schöttner
Fakultät für Informatik, Verteilte Systeme
Universität Ulm
1. Vorschau
1.1
Einordnung & Organisation
• Grundlage für Vorlesungen:
- Systemprogrammierung,
- Verteilte Betriebssysteme,
- und zur Allgemeinbildung ...
• Praktika & Diplomarbeiten VS:
- Verteilte Betriebssysteme,
- QoS und virtuelle Präsenz, ...
• Vorlesung 3V+1Ü, ab 28.04.2003:
- Montag, 14-16h, H21 (wöchentlich),
- Freitag, 10-12h, H21 (alle 2 Wochen).
• Übung im Wechsel mit der Vorlesung:
- Freitag, 10-12, H21 (alle 2 Wochen).
• Übungsbetreuung: M. Schöttner.
• Sprechstunde: nach Vereinbarung,
Zimmer 3209, o-27 Informatik.
• Anrechnung der kombinierten Klausur- und
Übungsnote im Rahmen der Diplomprüfung
möglich (>50%).
• Vorlesungsunterlagen: größtenteils von Herrn
Prof. Dr. Schulthess übernommen.
Betriebssysteme 2003, MS, VS-Informatik, Ulm
2
1.2
Definition
" An operating system is the software that
breathes life into a computer." (Unbekannter
amerikanischer Autor)
" Die Programme eines digitalen Rechensystems, die zusammen mit den Eigenschaften
der Rechenanlage die Grundlage der möglichen Betriebsarten des digitalen Rechen–
systems bilden und insbesondere die
Abwicklung von Programmen steuern und
überwachen" (DIN 66029, (1978))
(
Interrupts, Multitasking, Operating...)
" Das Betriebssystem macht den Anwendungssystemen die Betriebsmittel zugänglich; insbesondere Verarbeitungsleistung,
Speicher und Kommunikationswege."
(Peter Schulthess)
3
• Schema aus "Road Map to A/UX":
Programme
Befehlsinterpreter
System-Call
interface
Kern
Treiber
Treiber
Treiber
Treiber
Hardware
4
1.3
1.
Vorschau ....................................................... 2
1.1
1.2
1.3
1.4
2.
Monolithisch .................................................24
Geschichtet ....................................................25
Mikrokern......................................................28
Virtuelle Maschinen ......................................29
Client / Server................................................30
Hauptspeicher............................................. 35
4.1
4.2
4.3
4.4
4.5
4.6
4.7
5.
Geschichte .......................................................9
Arten von Betriebssystemen..........................13
Aufgaben eines Betriebssystems ...................15
Beispiele von Betriebssystemen ....................21
Betriebssystemorganisation....................... 24
3.1
3.2
3.3
3.4
3.5
4.
Einordnung & Organisation ............................2
Definition ........................................................3
Inhalt ...............................................................5
Literatur...........................................................8
Einführung in Betriebssysteme ................... 9
2.1
2.2
2.3
2.4
3.
Inhalt
Einführung.....................................................35
Partitionen im Hauptspeicher ........................37
Verwaltung & Vergabe .................................48
Overlay & Swapping.....................................51
Virtueller Speicher ........................................53
Beispiele: Linux & Windows NT..................83
Automatische Freispeichersammlung ...........86
Plattenspeicher ........................................... 93
5.1
Aufbau einer Festplatte .................................93
5
5.2
5.3
5.4
5.5
6.
Nebenläufigkeit......................................... 124
6.1
6.2
6.3
6.4
7.
Lese/Schreibkonflikt ...................................151
Serialisierung mit Signal/Wait: ...................152
Kritische Abschnitte....................................153
Wechselseitiger Ausschluss ........................156
Klassische Problemstellungen.....................167
Verklemmungen ..........................................171
Interprozesskommunikation ........................179
Ein-/Ausgabe............................................. 187
8.1
8.2
8.3
9.
Prozesse und Threads ..................................124
Koroutinen & Fibers ...................................134
Kontextwechsel ...........................................135
Ablaufplanung.............................................137
Synchronisierung ..................................... 151
7.1
7.2
7.3
7.4
7.5
7.6
7.7
8.
Festplatten-Scheduling ..................................98
Speicherverwaltung.....................................101
Dateisysteme ...............................................109
Redundanz & Spiegelung............................123
Peripherie ....................................................187
Unterbrechungen .........................................189
E/A-Software...............................................197
Namensdienste .......................................... 209
9.1
9.2
9.3
9.4
9.5
Namen & Adressen .....................................209
Beispiel: JavaOS .........................................214
Beispiel: Windows NT ................................215
Konfigurationsverwaltung...........................216
Internet Domain Name Service ...................221
10. Bibliotheken.............................................. 224
6
10.1
10.2
10.3
10.4
Programmierschnittstellen...........................224
Prozedurbasierte Bibliotheken ....................225
Objektorientierte Bibliotheken ....................234
Systemaufruf am Beispiel von NT ..............240
11. Benutzerschnittstellen.............................. 242
11.1
11.2
11.3
11.4
Überblick.....................................................242
Befehlsinterpreter ........................................245
X Window ...................................................249
Microsoft Windows.....................................252
12. Sicherheitsaspekte .................................... 256
12.1
12.2
12.3
12.4
12.5
12.6
Einleitung ....................................................256
Zugangskontrolle.........................................257
Zugriffskontrolle .........................................258
Supervisor Betriebsmodus...........................261
Isolation der Adressräume...........................262
Angriffsformen............................................263
7
1.4
Literatur
- Stallings William: „Betriebssysteme“, Prentice
Hall, Pearson Studium, 4. Auflage, 2002.
- Tanenbaum Andrew: „Moderne Betriebssysteme“, München, Prentice Hall, 1995.
- Silberschatz, Galvin: „Operating System
Concepts“, Addison-Wesley, 1998.
- Nehmer Jürgen und Sturm Peter: „Systemsoftware. Grundlagen moderner Betriebssysteme“,
dpunkt-Verlag, Heidelberg, 1998.
- Traub, Stefan: „Verteilte PC-Betriebssysteme“,
Teubner Verlag 1997.
- Solomon , David: „Inside Windows NT”,
Microsoft Press, 2nd Edition, 1998.
- Custer, Helen: „Inside the Windows NT file
system”, Microsoft Press, 1994.
- Windows Interna: www.sysinterals.com
- Herold, Helmut: „Linux-Unix-Systemprogrammierung, 2. Aufl., Addison-Wesley, 1999.
- Beck, Michael: „Linux-Kernel-Programmierung:
Algorithmen und Strukturen der Version 2.2, 5.
Auflage, Addison-Wesley, 1999.
8
2. Einführung in Betriebssysteme
2.1
Geschichte
Erste Generation: 1945-1955
• Röhren (>10.000 Stk.) und Klinkenfelder.
• K. Zuse (irb.cs.tu-berlin.de/~zuse/Konrad_Zuse).
• Fest verdrahtete Programme.
• Aufwendiger Betrieb und Wartung.
• Für numerische Berechnungen (Tab. für Log).
Zweite Generation: 1955-1965
• Erhöhte Zuverlässigkeit durch Transistoren.
• Aber sehr teuer (mehrere Millionen EUR).
• Programme auf Lochkarten (Ass. & Fortran).
• Stapelbetrieb (Batchsystem):
- Manuell: Operateur lädt neuen Job, wenn der
Alte abgearbeitet wurde ineffizient.
- Automatisch: Kleiner, billiger Rechner liest
neue Jobs und speichert diese auf Band. Band
dient als Eingabe für den Mainframe.
- Sequentielle Verarbeitung der Programme.
- Keine Interaktion zw. Programm und Benutzer.
9
Dritte Generation: 1965-1980
• Einführung von integrierten Schaltungen.
• IBM System/360:
- Serie von kompatiblen Rechnern.
- Für wissenschaftl. und kommerz. Bereich.
- sehr komplexes BS (mehrere Mio. Zeilen
Assembler-Code; >1000 Entwickler).
• Fortschritte der dritten Generation:
- Spooling (Simultaneous Peripheral Operation
On Line):
o Aufträge von Lochkarten einlesen und auf
Platte zwischenspeichern.
o Heute: Ansteuerung von Drucker.
- Mehrprogrammbetrieb (Multiprogramming):
o Mehrere Jobs im Hauptspeicher.
o E/A-Wartezeiten ausnutzen.
o Verteilen der CPU.
- Time Sharing (Zeitscheibenkonzept):
o Erstes System von MIT (1962).
o Dialogbetrieb: jeder Benutzer ist über ein
Terminal mit dem System verbunden.
o Quasi-parallele Ausführung von Prgs.
Multitasking
o Programmumschaltung (Zeitscheiben).
10
• Einführung von Unix:
- Vorläufer: MULTICS, 1965.
- Ken Thompson schrieb abgespeckte Version
UNICS für Einbenutzersysteme.
- Dennis Ritchie entwickelte die Sprache C und
schrieb UNICS zusammen mit Thompson neu in
C: UNIX (8.200 Zeilen C und 900 Zeilen Ass.).
- Wurde nachfolgend vielfach portiert.
Vierte Generation: 1980-1990
• Hardware:
- large scale integrated circuits (LSI).
- Bauelemente mit 1000en von Transistoren.
- Entwicklung von Mikrocomputern und PCs.
• Software:
- BS überwinden Rechnergrenzen.
- Graphische Benutzschnittstellen.
- Parallelität durch Threads.
• Betriebssysteme:
-
CP/M (8-Bit) für Intel 8080.
MS-DOS (16-Bit) für Intel 80x86.
Microsoft Windows (16/32-Bit) für 80x86.
Unix (32-Bit) für Workstations (X-Window).
MacOS: Einführung einer graph. Oberfläche.
• Netzwerkbetriebssysteme und verteilte BS.
11
Moderne Entwicklungen
• Cluster Systeme:
- Hochverfügbarkeit durch Redundanz.
- Bündelung von Rechenleistung.
• Multimedia:
- Unterstützung von Audio- und Videoströmen.
- Dienstegarantien (Quality of Service).
• Eingebettete Systeme:
- Maßgenscheiderte kleine Betriebssysteme.
- Typischerweise mit Echtzeitanfoderungen.
• Interoperabilität: Unterstützung heterogener
Umgebungen.
12
2.2
Arten von Betriebssystemen
• Mainframe Betriebssysteme:
- Früher in großen Rechenzentren, heute auch
Web-/E-commerce-Server, …
- Große Ein- und Ausgabebandbreiten
möglichst viele Prozesse effizient ausführen
- Unterschiedliche Betriebsarten:
o Stapelbetrieb, z.B. Schadensmeldungen in
einer Versicherung
o Transaktionsbetrieb, z.B.
Banküberweisungen, Flugbuchungen, …
o Timesharingbetrieb bei zentralen Diensten
- Beispielsystem OS/390.
• Server Betriebssysteme:
-
Eine Ebene unterhalb der Mainframes.
Bedienen viele Nutzer über ein Netzwerk.
Verteilen Hardware- und Software-Ressourcen.
Für Datei-, Mail-, Web-, Druckservern, …
Beispiele: UNIX, Linux, Windows 2000/XP.
• Netzwerk-Betriebssysteme:
- Verwaltet gemeinsame Ressourcen im Netz.
- Benutzer kennen die Existenz des Netzwerks
von Rechnern.
- Benutzer können sich an fremden Maschinen
anmelden, um Dienste in Anspruch zu nehmen.
- Beispiel: Novell Netware.
13
• Verteilte Betriebssysteme:
- Rechnerverbund bleibt Benutzer verborgen.
- Wo die Programme ausgeführt werden und wo
die benötigten Daten liegen wird durch das BS
bestimmt und ist dem Benutzer nicht bekannt.
- Benutzer hat den Eindruck einer einheitlichen
Computerressource.
- Beispiele: Amoeba, Kerrighed, Plurix.
• PC- Betriebssysteme:
-
Beschränkt auf einen Benutzer.
Benutzerfreundliche Oberfläche.
Einfache Installation und Wartung.
Unterstützung vieler Peripheriegeräte.
• Echtzeit-Betriebssysteme:
- Verarbeitung von Daten innerhalb bestimmter,
üblicherweise enger Zeitgrenzen.
- Je nach Toleranz bzgl. Überschreitung von
Sollzeitpunkten wird zwischen harter und
weicher Echtzeit unterschieden.
- Für Überwachungs-, Fertigungsanlagen, …
- Beispielsysteme: VxWorks, QNX, ...
• Betriebssysteme für eingebettete Systeme:
- Besitzen oft Echtzeiteigenschaften.
- Optimiert bzgl. Programmgröße, verfügbarer
Arbeitsspeicher und Stromverbrauch.
- Typischerweise für Mikrocontroller oder PDAs.
- Beispiele: OSEK, PalmOS, Windows CE, ...
14
• Betriebssysteme für Chipkarten:
- Harte Bed. an Speicher und Rechenleistung.
- Oft nur einzelne Funktionen, wie elektronisches
Bezahlen, realisiert.
- SmartCards gewinnen zusehens an Bedeutung.
- Java-orientierte SmartCards mit JVM im ROMSpeicher vorhanden.
2.3
Aufgaben eines Betriebssystems
2.3.1 Betriebsmittelzuteilung
• Betriebsmittel werden vom System zugeteilt:
- um Doppelbelegungen zu vermeiden,
- zwecks Rückgabe beim Programabsturz,
• Zuteilung jeweils an ein "Objekt", z.B. an:
- Programm, Prozess, Thread, Instanz, User ...
• Hauptspeicher wird benötigt für:
-
Prozeduraktivierungen auf dem Keller,
Puffer für Dateien und Datenpakete,
Codesegmente & Kontrollblöcke,
Heap-Objekte.
• Geräte / Devices:
- entweder nur exklusiv nutzbar (exklusiv),
- oder gleichzeitig nutzbar (sharable),
• Plattenspeicher wird als Dateien vergeben.
15
• Bei Bedarf wird der Prozessor zwischen verschiedenen Threads umgeschaltet.
• Bildschirmoberfläche ist kostbar. Programme
erhalten Fenster auf dem Bildschirm.
2.3.2 Bedienerschnittstelle:
• Anzeigen von Fehlersituationen.
• Dialogsteuerung für:
- Navigation im (Datei-)System:
- Anwenderprogramme.
- Systembedienung.
16
2.3.3 Abstraktion von der Hardware
Für den Anwendungsprogrammierer:
• Ein Subset von Laufzeitroutinen ist allen Unix
Implementierungen gemeinsam:
- creat, open, close, read, write,
- malloc, fork, wait, waitpid,
- socket, bind, printf, scanf ...
• Viele Karten unterstützen Grafikstandard:
- DirectX, OpenGL, QuickDraw.
• Java Programme laufen auf beinahe jedem
Rechner, wenn dort eine Virtuelle Java
Maschine (JVM) vorhanden ist.
Für den Systemprogrammierer:
• Wenn eine "Hardware Abstraktionsschicht"
eingezogen wird, ist es leichter, ein Betriebssystem auf eine neue Rechnerplattform zu
bringen.
• Erhalten bleiben etwa:
- Formate im Dateisystem,
- Protokolle auf dem Netz,
- Algorithmen und Strategien ...
•
17
2.3.4 Verzeichnisdienste
"Machines use adresses, people prefer names"
• Übersetzung zwischen Namen und Adressen:
• Adressen für:
- Hauptspeicher, Ethernet, Internet, Disksektoren,
E/A-Ports, SCSI-Devices ...
• Suchpfade für Klassen & Bibliotheksmodule.
• Navigation im Namensraum.
• Dateiverzeichnisse:
- Dateinamen auf Diskadressen abbilden,
- Aliases, Shortcuts und Decknamen,
- geschachtelte Unterverzeichnisse.
• Registry in Windows:
- hierarchische Datenbank,
- Schlüssel und Werte.
• Auffinden von Namen im Netz:
- Namen für Benutzer & Dienste,
- Maschinennamen.
• Namen für Objekte:
- Fenster und Dialogelemente,
- Ereignisobjekte,
- Com-Objekte ...
18
2.3.5 Fehlerbehandlung & Zugriffsschutz
• "Post Mortem" müssen die Betriebsmittel eines Programmes wieder freigegeben werden:
-
Hauptspeicher,
offene Dateien,
Peripheriegeräte,
Bildschirmfenster,
Warteschlangenpositionen ...
• Der Benutzer wünscht eine verständliche
Fehlermeldung:
- kein Hex-Dump,
- kein blauer Bildschirm,
- keine allgemeine Schutzverletzung.
• Schutz:
-
vor unabsichtlicher Beschädigung des System,
vor böswilligen Einbruchsversuchen,
vor Monopolisierung des Systems,
vor Fehlern im Betriebssystem,
vor Hardwaredefekten.
19
2.3.6 Konfigurierung & Startup
• Konfigurierungsbedarf für:
-
Benutzerrechte,
Festplatteneinteilung,
Netzwerkportokolle,
Bildschirmauflösung,
Bios-Einstellungen ...
• Automatische Erkennung von Hardware.
- Plug & Play vs. Plug & Work,
- für Geräte am PCI Bus,
- für ISA Geräte?
• Initialisierung:
- der Hardwarekomponenten,
- des Betriebssystemkernes,
- der Serverdienste.
• Ausschalten des Systems:
-
Dokumente sichern lassen,
Dateipuffer auf Disk schreiben,
Druckerwarteschlange schliessen,
Abmelden am Netz,
Services beenden,
Power down !
• Schlafmodus einleiten.
20
2.4
Beispiele von Betriebssystemen
VMS:
•
•
•
•
•
Für Mainframe-Rechner von Digital Equipment.
Virtueller Speicher.
Hochentwickeltes Dateisystem.
Vernetzung über DecNet.
Flexible Anbindung von Unix & Macintosh
Systemen.
MVS:
•
•
•
•
•
Für IBM Mainframes.
Ungeeignet für Arbeitsplatzrechner.
Betreung nur durch den Spezialisten.
Variantenreiche Jobkontrollsprache.
Vernetzung über SNA.
Windows 98 & Windows NT:
•
•
•
•
•
•
•
•
•
Bill Gates, Microsoft Corp.
Betriebssystem für IBM-PCs und dgl.
Rechner der 80xxx-Familie.
C Schnittstelle zum Betriebssystem.
Mehrprogrammbetrieb.
32 Bit Adressen.
Vernetzung TCP/IP, Netbeui & Novell Net.
Windows 98 für Klientenstationen.
Windows NT/2000/XP für Workstations und
kleinere Server.
21
Unix:
•
•
•
•
•
•
•
•
•
•
Portables Betriebssystem für Workstations.
Auch für Mainframe-Rechner.
Ursprünglich für PDP11.
Geschrieben in der Sprache C.
Allgemeines Prozesskonzept.
Viele Dienstprogramme, E-Mail.
Standardisierungsgremien.
X-Window als graphische Bedieneroberfläche.
Vernetzung über NFS/TCP/IP ...
Linux: Public Domain Unix (GPL).
OS/2 (IBM):
•
•
•
•
•
•
gedacht als Nachfolger von MS-DOS.
für Rechner der 80xx-Familie.
32 Bit Adressen.
LAN-Manager.
Presentation Manager.
Macintosh OS:
•
•
•
•
•
Xerox-Star Lisa Macintosh.
halbwegs objektorientiert.
für Arbeitsplatzrechner mit PowerPC CPUs.
für Grafik & DTP.
Erste marktgängige Bedieneroberfläche mit
Desktop Symbolik.
• OS & Toolbox im ROM.
• Vernetzung über AppleTalk & TCP/IP.
• System X basiert auf Mach Kern.
22
Oberon System:
•
•
•
•
•
Wirth & Gutknecht, ETH Zürich.
Kleines Betriebssystem für PCs.
Objektorientiert mit Oberon als Sprache.
Automatische Freispeichersammlung.
Kooperatives Single Tasking.
Plurix:
•
•
•
•
•
•
Experimentelles verteiltes BS aus Ulm.
PC-Cluster mit DSM-Speicher.
Transaktionen statt Prozesse.
Programmierung in Java.
Schnellstart-Option.
Code < 200 KByte.
23
3. Betriebssystemorganisation
3.1
Monolithisch
Anwendungen
Dispatcher
OS - Routinen
Hardware
• Sammlung von Routinen, ohne Hierarchie,
Kapselung und Schichtung.
• Folgen von Änderungen und Erweiterungen
sind schwer abzuschätzen.
• Beispiel: MS-DOS.
24
3.2
Geschichtet
Anwendungen
Dispatcher
OS - Routinen
Treiber
Hardware
• Verschiedene Abstraktionsebenen respektive
Schnittstellen:
-
Programmierschnittstelle für Anwendung,
"Service-Provision",
Treiberschnittstelle,
Hardwareschnittstellen.
25
• Auswechselbar sind unter Umständen:
-
Betriebssystemkern: Releasewechsel ...
CPU-Generation: Intel8086 ... Pentium III ...
Hauptplatine: Bios, Chipsatz, Busse
Prozessortyp: Intel x86, Sun-Sparc, Power PC,
Protokolle: TCP/IP, IPX, AppleTalk
Geräte: Festplatte, Drucker, Grafikkarte ...
• SW-Schichtenmodell:
-
Anwendungsprogramm,
Laufzeitbibliothek,
Pseudotreiber,
OS-Dienste,
Gerätetreiber.
• HW-Schichtenmodell:
-
Busschnittstelle (PCI, EISA, ISA),
Host-Controller (z.B. SCSI, USB),
Peripheriebus (SCSI, USB, FireWire),
Firmware (z.B. in SCSI-Platte),
elektromechanisches Gerät.
• Beispiele:
- THE System, Dijkstra, 1968.
- MULTICS: Ringe mit HW-Schutz.
- Oberon, 1992.
26
Beispiel: Oberon System - geschichtet
• Wirth & Gutknecht, 1992:
System
Edit
TextFrames
Printer
Net
Backup
SCC
Diskette
Befehle
Texte
MenuViewers
Oberon
Viewers
Texts
Modules
Fonts
Reals
Files
Display
FileDir
Input
Treiber
Kernel
27
3.3
Mikrokern
Anwendungen
OS-Dienste
Mikrokern
Treiber
Hardware
• Zuverlässiger Mikrokern, etwa für:
- Nachrichtenvermittlung & Prozessumschaltung,
- Speicherverwaltung & Security ...
• Dienste im Adressraum der Anwendung:
-
Bedieneroberfläche,
Dateiverwaltungen,
Vernetzung ...
Beispiel: Mach, L4.
28
3.4
Virtuelle Maschinen
• Nachbildung der zugrunde liegenden HW, so
dass mehrere Betriebssysteme gleichzeitig auf
einem Rechner laufen können.
• Erstes System IBM VM/370:
- Monitor der virtuellen Maschine: Ausführung
auf der realen Hardware, Realisierung von
- Auf der nächst höheren Ebene werden mehrere
virtuelle Maschinen zur Verfügung gestellt.
- Exakte Kopien der HW mit Kern- und Benutzermodus, Ein- und Ausgabe, Unterbrechungen und
andere Eigenschaften der realen Maschine.
• Systemaufrufe werden von der virtuellen
Maschine abgefangen.
• Die tatsächliche Ausführung der Systemaufrufe erfolgt auf der realen HW durch den
Monitor auf HW-Ebene.
• Klare Trennung vereinfacht den Entwurf der
beiden Komponenten.
• Abwandlungen:
- Virtueller 8086 Modus für Pentium-CPUs zur
Ausführung von 16-Bit MS-DOS Programmen.
- JVM (Java Virtual Machine) interpretiert
plattformunabhängigen Bytecode.
29
3.5
Client / Server
Anw.
Services
Executive
Kern
HAL
Treiber
Hardware
• Aufteilung in Client- und Server-Prozesse.
• Zwanglose Erweiterung auf verteiltes System.
• Keine Privilegien für Dienste im User-Mode.
• Validierung der Aufrufsparameter zum Dienst
im Executive (gültige Handles, Rechte, ...).
30
3.5.1 Fallbeispiel: Windows NT
"Executive" in Windows NT
• Dienste im sicheren Teil des Systems.
Virtual
memory
LPC
Process
Manager
Security
Monitor
Objekt
Manager
Kernel Mode
E/A
- Dateien
- Cache
- Drivers
- Network
Kern
Hardware Abstraktion
• Security Monitor kooperiert mit Security-SS.
• Object Manager verwaltet OS-Ressourcen.
• Prozess Manager für Prozesse & Threads.
• "Local Procedure Calls" für Aufrufe über
getrennte Adressräume hinweg.
• VM für Adressräume und Paging.
• E/A-Manager: verwaltet und ruft Treiber.
(Direkte E/A aus Performance-Gründen)
31
Subsysteme in Windows NT
User Mode
Win32
Klient
Win32
Klient
MS-DOS
Klient
Win32
WoW
Klient
Klient
OS/2
Klient
Posix
Klient
Kernel Mode
LPCs
Virtuelle
DOS Masch.
OS/2
Subsystem
Posix
Subsystem
User Mode
Win32
Subsystem
• Kommunikation mit Subsystemen über den
LPC Manager im Executive.
• Kommunikation zw. Subsystemen über LPC.
• Wechsel zum Kernel-Modus via INT 0x2e.
• Win32-Subsystem:
- DLLs beim Klienten: User32, Kernel32, GDI32,
- LPC zum W32-Subsystem-Prozess CSRSS.exe.
32
Virtuelle DOS Maschinen
• Eine Virtuelle Dos-Maschine (VDM) bildet
eine reale DOS-Maschine nach:
-
E/A-Port Zugriffe abfangen & emulieren,
Virtuelle Gerätetreiber in der VDM,
E/A-Unterbrechungen weiterreichen,
640 KByte für DOS-Programme,
16 MByte Adressraum für Win16 Programme.
Adressen &
Instruktionsinterpreter
16 MBytes
32-Bit Windows Manager
& GDI Thunks
32-Bit MS-DOS Emulation
Virtuelle Gerätetreiber
Windows 3.11 Anwendungen
640 KBytes
Windows Mgr. & GDI Stubs
Windows 3.11 Kern
16-Bit MS-DOS Emulation
• Pro MS-DOS Programm wird ein Thread in
NTVDM Prozess gestartet.
• 16-Bit Windows-Programme können optional
in separaten NTVDMs gestartet werden:
- WoW = "Windows on Windows" (16 on 32),
- kooperatives Multitasking ...
33
Koexistenz von 16- & 32-Bit Applikationen
16-Bit
16-Bit
16-Bit
Klient
Klient
Klient
Win32
Klient
Krnl386/Gdi/User.exe
Win32
Klient
Thunk-Layer
Kernel32 / Gdi32 / User32 / NTdll / Advapi .dll
Kernel Mode / native NT-Funktionen
• Thunk-Layer besorgt Konvertierungen:
-
Segment:Offset nach Linear 32-Bit Adresse,
(DX,AX)-Register nach EAX-Register,
16-Bit Stack nach 32-Bit Stack,
und umgekehrt,
etc. ...
• Teile der 32-Bit Funktionen sind noch nicht
implementiert und rufen wiederum 16-Bit
Prozeduren.
34
4. Hauptspeicher
4.1
Einführung
• Speicherhierarchie:
- Cache:
o teuer.
o flüchtiger Inhalt.
o meist mehrstufig organisiert.
o Kapazität in Kilobyte (z.B. 512 KB).
o Zugriff bei Pentium 4 mit CPU-Takt.
- Hauptspeicher:
o flüchtiger Inhalt.
o schneller Zugriff (z.B. SDRAM 7ns).
o Kapazität in Megabyte (z.B. 512 MB).
- Platttenspeicher:
o persistente Speicherung.
o Kapazität in Gigbyte (z.B. 80 GB).
o Zugriffszeiten in Millisek. (z.B. 7ms).
• Hauptspeicher wird:
-
zugeteilt,
geschützt,
ausgelagert,
freigegeben,
kompaktifiziert.
35
Binden von Speicheradressen
• Programm muß zur Ausführung in den Hauptspeicher geladen werden.
• Adressbindung zur Übersetzungszeit:
- fest „verdrahtete“ Adr. im ausführbaren Prg.
- Prg. muß an bestimmte Adresse geladen werden.
Konflikte bei Mehrprogrammbetrieb
• Adressbindung zur Ladezeit:
- PC-relative Adressierung oder Binder erzeugt
relozierbare Adressen (beginnend bei 0).
- Positionen der zu relozierenden Adr. in Tabelle.
- Lader passt die Adressen an die zugewiesene
Speicherposition an.
• Adressbindung zur Laufzeit:
- Relozierung des Programms zur Laufzeit.
- benötigt HW-Unterstützung (z.B. Segmente mit
Basisregister).
MMU
Hauptspeicher
Basisregister
10000
CPU
Logische
Adresse
4711
+
Phys.
Adresse
14711
36
4.2
Partitionen im Hauptspeicher
• Ziel: mehrere Programme, geschützt voneinander, gleichzeitig im Hauptspeicher halten.
Multiprogramming
• Aufteilung des Hauptspeichers in Partitionen.
• Partition = Speicherblock für ein Programm.
4.2.1 Statische Partitionierung
• Statische Unterteilung des Hauptspeichers in
gleich große oder variabel große Partitionen.
• Feste Partitionen:
- einfach implementierbar.
- maximale Anzahl Programme festgelegt.
- Nachteil: ungenutzter Platz verloren
interne Fragmentierung.
• Unterschiedlich große Partitionen:
- gleiche Nachteile wie bei festen Partitionen,
- aber etwas höhere Flexibilität.
• Beispiel: OS-360 MFT.
- IBM Betriebssystem für Mainframes.
- MFT=Multiprogramming with a Fixed number
of Tasks.
37
4.2.2 Dynamische Partitionierung
• Länge & Anzahl der Partitionen sind variabel.
• Programm erhält genau so viel Speicher wie
es benötigt und nicht mehr.
interne Fragmentierung wird verhindert
• Aber neues Probl. externe Fragmentierung:
- im Laufe der Zeit entstehen Löcher zw. Part.
- insgesamt genügend Speicher vorhanden,
- aber Programm paßt in keine Lücke.
Lösung: Heap Kompaktifizierung
n
Hauptspeicher
Hauptspeicher
Betriebssystem
Betriebssystem
kompaktieren
0
38
4.2.3 Anwenderprogrammpartition
• Heap (Halde) für dyn. Speicherverwaltung:
- Ressourcen,
- (Codesegmente),
- dyn. Datenstrukturen.
• Stack (Keller) für Parameter & lokale Var.
• A5-Welt des Macintosh:
- Globale Variablen des Programmes,
- Einsprungtabelle für Prozeduren,
- Grafik-Kontext.
Sprungtabelle
Grafik-Kontext
Register A5 Globale Variablen des Programmes
Keller
high
frei
memory
Register A7
Halde
low
39
Format von Heapblöcken:
• Jeder Heapblock enthält einen Header mit
Informationen für die Speicherverwaltung:
- Flags & Längenfelder,
- nächster Heapblock
- Typ, ...
• Header normalerweise außerhalb des Blocks.
• Alternativ Doppelköpfiges Format (Plurix).
Variablen
Referenzen
40
Handles & Masterzeiger:
• Der Masterzeiger referenziert die Daten.
• Ein Handle als Zeiger auf einen MasterZeiger.
• Eventuell verweisen viele Handles auf einen
MasterZeiger:
aHandle
bHandle
relozierbarer Block
cHandle
MasterPtr
Daten können verschoben werden, ohne
alle Handles zu kennen und zu verändern.
41
Laufzeitkeller
Displaytabelle
• Spiegelt die verschachtelten Gültigkeitsbereiche des Quellprogrammes wieder:
#0
Globale
Variablen
Proc B
Proc C
Proc A
#1
A-Variablen
#2
B-Variablen
#3
C-Variablen
#4
Displaytabelle
Keller
Programmtext
• Globale Variablen auf lexiklaischer Ebene #0.
• Compiler kennt aktuelle lexikalische Ebene,
jedoch nicht die Rekursionstiefe.
• Nur Variablen im Keller, kein Code.
• Displaytabelle erledigt nicht:
- Aufbewahrung der alten Ebenen,
- Prozedurrücksprungadresse, ...
42
Statische und dynamische Kette
= „Static & dynamic Chain“
• Statische Verkettung anstelle von Display.
• Dynamische Verkettung für Rekursion:
globale
A
Proc B
Proc C
Proc A
static
chain
B
B
C
dynamic
chain
C
B
Programmtext
C
B
43
Kellerrahmen („Stackframe“)
• Welche Information wird pro Prozeduraufruf
im Keller festgehalten?
Funktionsresultat
Statische Verkettung
Rücksprungadresse
Dynamische Verkettung
Stackframe
Parameter
Lokale Variablen
Registeraufbewahrung
Temporäre Zwischenwerte
• Funktionsresultat nur bei Funktionen.
• Statische Verkettung falls lex. Ebene >0.
• Aufgaben des Kellers
-
Speichern von lokalen Variablen
Übergabe von Parametern an eine Prozedur
Rückgabe von Funktionsresultaten
funktioniert nach Prinzip „Last in First Out“
44
Aufrufkonventionen
• Pascal:
- Parameter werden von links nach rechts
übergeben
- Die aufgerufene Prozedur räumt den Keller auf
- Funktionsresultate werden über den Keller
zurückgegeben
• C:
- Parameter werden von rechts nach links
übergeben
- Die aufrufende Prozedur räumt den Keller auf
- Funktionsresultate werden in Registern
zurückgegeben
• Bei RISC-Prozessoren
- Parameterübergabe fast immer in Register
- Möglichkeit, Register zumzunummerieren
45
Intel: Kellerrahmen (Stackframe)
• Aufbau:
Parameter
EBP
Rücksprungadresse
altes EBP
ESP
Lokale Variablen
• Adressierung:
- Parameter relativ zu EBP mit pos. Index.
- Lokale Var. relativ zu EBP mit neg. Index.
• Beispiel C:
void add(int x, int y)
{
int result;
result = x + y;
return result;
}
...
add(5, 7)
push
mov
sub
mov
add
mov
mov
mov
pop
ret
EBP
EBP,ESP
ESP,4
EAX,[EBP+8]
EAX,[EBP+12]
[EBP-4],EAX
EAX,[EBP-4]
ESP,EBP
EBP
push
push
call
add
7
5
add
ESP,8
46
• Beispiel Pascal:
function add(x,y: int) push
mov
begin
sub
int result;
mov
add
result := x + y;
mov
mov
add := result;
mov
end;
EBP
EBP,ESP
ESP,4
EAX,[EBP+12]
EAX,[EBP+8]
[EBP-4],EAX
EAX,[EBP-4]
[EBP+16],EAX
mov
pop
ret
ESP,EBP
EBP
8
push
push
push
call
pop
0
5
7
add
eax
...
add(5, 7)
47
4.3
Verwaltung & Vergabe
4.3.1 Speicherverwaltung
• Bitvektor
- Problem: Wahl der Granularität.
- je kleiner G., desto größer wird Bitvektor.
- interner Versch. steigt mit Größe des Granulats.
• Freispeicherliste
- freie Speicherblöcke verketten.
- Zeiger für die Freispeicherliste im leeren Block
unterbringen.
- eventuell mehrere Listen verwenden.
• Linearer Heap
- freie & belegte Blöcke sind dicht aneinander
gereiht (Verkettung über Längenfeld).
- optimale Ordnung der Blöcke ist schwierig.
- interne Zeiger sind überflüssig.
- z.B. Mac OS & Plurix.
• Buddy-System
- Speicher besteht aus 2kmax Einheiten.
- jeweils eine Liste für Blöcke der Größe 2i
- kleiner Stücke entstehen aus (fortgesetzter)
Halbierung größerer Stücke.
- benachbarte kleinere Stücke werden bei der
Freigabe wieder vereinigt.
48
- Ablauf Anforderung:
o Aufrunden auf nächste Zweierpotenz
o Zugriff auf erstes freies Stück der Liste
o Falls Liste leer (rekursiv):
Zugriff auf Liste der nächsten Größe
Stück entfernen & halbieren
Hintere Hälfte (=Buddy) in zugehörige
Liste einhängen
- Ablauf Freigabe:
o Buddy bestimmen
o falls Buddy belegt, freigewordenes Stück
in die Liste einhängen
o falls Buddy frei Vereinigung
o Vorgang iterieren, bis Buddy belegt oder
bei der max. Größe angekommen.
- Beispiel:
alloc 3MB
alloc 800k
alloc 12MB
free 12MB
alloc 3,5MB
free 3MB
free 800k
free 3,5MB
49
4.3.2 Speichervergabe
• Gute Strategie kommt mit kleinem Heap aus.
• Kriterien: Verschnitt & Geschwindigkeit.
• Die beste Strategie zu finden, ist auch „post
festum“ ein schwer lösbares Problem.
• „First fit“:
- nimmt ersten freien Block der groß genug ist.
- evt. teilen, um ungebrauchten Platz zu sparen.
• „Best fit“:
- sucht den Block, der am wenigsten Speicherverschnitt verursacht.
- Vorteil: keine Zerschneidung großer Stücke.
- Nachteil: langsam; neigt bei Zerschneiden dazu
sehr kleine unbrauchbare Stücke zu erzeugen.
• „Worst fit“: nimmt den größten Block, damit
noch was übrig bleibt.
• „Buddy-Technik“:
- bei Bedarf wird ein zu großes Element geteilt.
- später werden kleine benachbarte Blöcke wieder
vereinigt.
- interner und externer Verschnitt vorhanden.
50
4.4
Overlay & Swapping
4.4.1 Overlay Technik
• Notwendig, wenn das Programm größer als
der Hauptspeicher ist.
• Idee: Nicht benötigte Programmteile werden
durch andere Programmteile überlagert.
• Realisierung:
- ein Wurzelsegment muß immer im HS sein.
- Overlays werden vor dem Binden festgelegt.
- Unterstützung durch:
o Betriebssystem (z.B. MSDOS),
o Compiler (z.B. Turbo Pascal Units).
Hauptspeicher
n
OverlayBereich
Wurzelsegment
Betriebssystem
0
51
4.4.2 Swapping
• Swapping = Aus- und Wiedereinlagern von
Programmen/Partitionen auf Disk.
• Notwendig im Multiprogrammbetrieb, falls
nicht genügend Hauptspeicher vorhanden.
• Zeitaufwendig, da immer ganze Partition ausund eingelagert wird.
• Evt. erfolgt Einlagerung an anderer Adresse.
• Strategien:
- Auslagern nicht rechenbereiter Prozesse
- Prioritäten berücksichtigen.
52
4.5
Virtueller Speicher
4.5.1 Grundprinzip
• Scheinbare Hauptspeicher-Vergrösserung.
selten benötigte Speicherbereiche auslagern
• Realisierungsformen: HS unterteilen in
- variabel große Segmente = Segmentation.
- gleich große Seiten (pages) = Paging.
- evt. beides kombiniert (z.B. Intel).
• Seiten im log. Adressraum werden auf phys.
Kacheln (page frames) im HS abgebildet.
Einfach virtualisierter Speicher:
• Ein virt. Adressraum für mehrere Programme:
Hintergrundspeicher
Progr. 1
Progr. 2
Logischer AR
M
M
U
Physikalischer AR
System
53
Mehrfach virtualisierter Speicher:
Hintergrundspeicher
Prg.-1
Prg.-2
System
M
M
U
Physikalischer AR
• Jedes Programm besitzt einen eigenen virt.
Adressraum.
• Adressübersetzungstabelle muss beim Prozeßwechsel umgeschaltet werden.
• Teile des Betriebssystemadressraumes auch
für die Anwendungsprogramme zugreifbar.
• MMU = Memory Management Unit, HWEinrichtung zur Adressübersetzung.
54
4.5.2 Adressübersetzung
Einstufige Übersetzung bei Segmentierung
• Abbildungsprinzip.
• z.B. 32 Bit virtuelle Adressen + 16 Bit
Segmentindex.
• Segmenttabellen speichern vollst. Adressen.
Seg. können an bliebigen Adr. beginnen.
#Segment
Offset
16
32
Segment-Index
Start
Offset
Limit
Segmenttabelle
reale Adresse
55
Einstufiger Übersetzungsvorgang bei Paging
• Abbildungsprinzip.
• z.B. 20 Bit virtuelle Adresse, 4 KByte Seiten.
virtuelle Adresse
20
Seitentabellen-Index
12
Offset
Seitentabelle
reale Adresse
• Bem.: aufeinanderfolgende Seiten müssen
nicht unbedingt auf fortlaufende Kacheln abgebildet werden.
56
Mehrstufige Adressübersetzung bei Paging
• Eine Übersetzungstabelle pro Prozeß.
• Adresskontext umschalten.
• Seitentabellen der Ebenen 1+i können evt.
ausgelagert werden.
virtuelle Adresse
8
6
6
12
Offset
Kontextregister
Kontexttabelle
Ebene 3
Ebene 2
Ebene 1
Seitentabellen
57
Typisches Format eines Eintrages in der
Seitentabelle (Intel Pentium):
Page Frame/Kachel-Adresse
20
Avail
12
Nutzbar für Betriebssystem
00
dirty
accessed
PCD
PWT
U/S
W/R
P
beschrieben
Use-Bit
Seite hat Cache Disabled
Cache durchschreiben
User Seite, nicht Supervisor
Seite beschreibbar
Präsenz Bit, Seite vorhanden
• Kacheladresse nur gültig, wenn die Seite im
Speicher vorhanden ist.
• Auffinden der Seite im Sekundärspeicher.
58
Uebersetzungspuffer (TLB)
• TLB = "Translation Lookaside Buffer".
• TLB puffert früher übersetzte Adressen.
• Nur wenige Einträge: P4 (40), IA64 (128).
• Falls kein Treffer im TLB erfolgt, wird hardwaremässig auf die Seitentabellen im Hauptspeicher zugegriffen (teuer).
• Hohe Trefferrate (Hit ratio) wichtig.
• Cache benützt nur physikalische Adressen:
- nicht sichtbar für die Software !
- mit physikalischer Adresse Eindeutigkeit:
virtuelle
Adresse
TLB
Seitentabellen
Betriebssystem
physikalische
Adresse
Cache
HauptSpeicher
Daten
• TLB Programmierung:
- Komplett löschen bei Adressraumwechsel.
- 1 Eintrag entfernen beim Einlagern einer Seite.
59
• Assoziativer Speicher (ähnlich einem Cache).
- direkt indexiert (mapped) oder voll assoziativ:
virtuelle Adresse
27
Kacheladdresse
7
Kacheladdresse
20
virtuelle Adresse
- oder 2 Wege Set-assoziativ.
virtuelle Adresse
Kacheladdr.
6
Kacheladdr.
21
60
Invertierte Seitentabellen
• Für sehr grosse virtuelle Adressenbereiche.
• Für CPUs mit 64-Bit Adressen, z.B. Sun
Sparc, Intel Itanium, Dec Alpha, ...
• 64-Bit Adressraum:
~ 252 Einträge in Seitentabelle,
~ für 4 KB Seiten & 8 Byte pro Eintrag,
~ 32 000 Terabyte nur für Seitentabellen.
• Besser ein Eintrag pro physikalische Kachel
als ein Eintrag pro logischer Seite.
• Parallele Suche in grossem TLB.
• Bei Fehlanzeige im TLB:
-
Firmware aufrufen,
oder OS via Interrupt aufrufen (TLB Fault),
über Hashtabelle zur physikalischen Adresse,
Hashtabelle aktualisieren.
• Bei Fehlanzeige in der Hashtabelle:
-
sekundäre Seitentabelle konsultieren,
evtl. Tabellen und Seiten auf Platte,
Hashtabelle aktualisieren,
Seite einlagern.
• Neue MMU für 64-Bit Intel-Architektur.
61
4.5.3 Ersetzungsalgorithmen
Prinzip der Seitenersetzung:
• Ist eine Seite nicht im HS (page fault), so wird
sie mit Seitenersetzungsverfahren eingelagert.
• Ist der HS erschöpft muss zuvor eine Seite auf
Disk ausgelagert werden, damit Platz frei
wird.
Ersetzungsalgorithmus
• Ein-/Auslagern teuer
sollte Seitenfehler minimieren.
Optimale Seitenersetzung:
• Ersetze die Seite, die zukünftig am längsten
nicht mehr benötigt wird.
• Zukunft unbekannt
theoret. untere Grenze
• Beispiel für HS mit 3 Kacheln:
a
b
c
d
c
a
e
d
b
c
a
auslagern
Seitenfehler für Seite D
62
Not recently used (NRU):
• Flags in der Seitentabelle:
- USE-Bit falls die Seite referenziert wurde,
- DIRTY-Bit falls die Seite verändert wurde.
• USE-Bit periodisch zurücksetzen (~16 ms).
• Auslagerung nach Klassen:
A:
B:
C:
D:
USE-Bit = false, Seite unverändert
USE-Bit = false, Seite verändert
USE-Bit = true, Seite unverändert
USE-Bit = true, Seite verändert
• Fall B beschreibt eine Seite, die in einem
früheren Intervall verändert wurde und noch
zurückgeschrieben werden muss.
• Auslagerungspriorität: A > B > C > D
First-in, First-out (FiFo).
• Einfache Liste der eingelagerten Seiten.
• Die am längsten residente Seite wird ersetzt.
• Nachteil:
- Auch häufig genutzte Seiten werden entfernt.
- ungünstig bei zyklischen Zugriffsmustern.
63
Belady’s Anonomalie:
• Mehr Seitenfehler trotz mehr Kacheln: tritt
u.U. bei FIFO-Strategie auf.
• 4 Kacheln
11 Seitenfehler:
0 1 2 3 4 0 1 5 6 0 1 2 3 5 6
• 5 Kacheln
13 Seitenfehler:
0 1 2 3 4 0 1 5 6 0 1 2 3 5 6
• Optimal: 4 Kacheln
9 Seitenfehler:
0 1 2 3 4 0 1 5 6 0 1 2 3 5 6
64
Verfahren des zweiten Versuches:
• "Second chance page replacement algorithm".
• Verbesserung der FiFo-Strategie.
2nd Chance
a
used
b
used
alte Seiten
c
unused
a
unused
d
e
used
used
neue Seiten
auslagern
• Falls USE-Bit gelöscht, dann Seite auslagern.
• Falls USE-Bit gesetzt:
zweite Chance
- USE-Bit zurücksetzen,
- Seite hinten erneut einordnen,
• Mehr Verwaltungsaufwand für die Liste als
bei einfachem Fifo.
• Probl.: evt. lange Suche nach AuslagerungsKandidat.
65
Uhrzeigerverfahren
• Ähnlich wie Verfahren des zweiten Versuchs:
i
unused
j
unused
k
unused
h
unused
l
unused
g
used
a
used
f
used
b
used
e
used
d
used
c
unused
• Ringliste der Speicherseiten absuchen.
• Einen Zeiger im Ring umlaufen lassen.
• Falls Use-Bit gelöscht, dann Seite auslagern.
• Falls Use-Bit gesetzt, zurücksetzen.
• Eventuell mehr als zwei Chancen.
66
Least recently used (LRU)
• Am längsten unbenutzte Seite auslagern.
• Theoretischer Ansatz:
-
nur in Hardware realisierbar,
64 Bit Zeitstempel in Kacheltabelle halten,
Zeitpunkt des letzten Zugriffs eintragen,
bei jedem Zugriff aktualisieren kostspielig.
• Realisierung von LRU mit N*N Matrix:
- N phys. Kacheln N-Bit Vektor pro Kachel.
- Zugriff auf Kachel k:
o Bits der Zeile k auf ’1’
o Bits der Spalte k auf ’0’
- älteste Seite = Zeile mit kleinstem Binärwert.
- Bsp.: 4 Kacheln
Zugriff: 0 1 2 3 2 1 0 3 2 3
0
1
2
3
012
011
000
000
000
3
1
0
0
0
0
1
2
3
012
000
101
100
100
3
0
1
1
0
0
1
2
3
0123
0011
1011
0000
0000
0
1
2
3
0123
0111
0011
0001
0000
0
1
2
3
0123
0101
1001
1101
0000
0
1
2
3
0123
0110
0010
0000
1110
0
1
2
3
0123
0000
1000
1100
1110
0
1
2
3
0123
0100
0000
1101
1100
0
1
2
3
0
0
1
1
1
123
000
000
101
100
0
1
2
3
0
0
0
1
1
123
100
000
100
110
67
• LRU-Simulation in Software:
- pro Kachel ein Zähler,
- periodisch werden die Zähler gealtert,
- Kachel mit niedrigstem Zähler auslagern.
• Arbeitsweise des Zählers:
Zähler vor Verschiebung
1)
01011000
2)
0101100
USE-Bit wird
vorne eingefügt
1
Rechtsverschiebung
0
herausgeschobenes Bit
entfällt
Leistungsaspekte
• Jedes Prog. benötigt Mindestanzahl Kacheln.
• Allokationsalgo.: gleichverteilt, proportional,
prioritätenabhängig, ...
• Lokale Strategie:
- Bei einem Seitenfehler werden nur Seiten des
betroffenen Prozesses ausgelagert.
- Die Proz. haben Speicherbereich fester Größe.
- Vorteil: andere werden nicht beeinträchtig.
- Nachteil: Speicherbedarfs schwer schätzbar.
68
• Globale Seitenersetzungsverfahren:
- Tritt ein Seitenfehler auf, so stehen die Seiten
aller Prozesse zur Disposition.
- Die Proz. haben Speicherbereich var. Größe.
- Vorteil: mehr Flexibilität.
Trashing
• Prozeß hat weniger Seiten zur Verfügung als
er ständig nutzt sehr häufig Seitenfehler.
• Trashing: Prozeß verbringt die meiste Zeit mit
dem Ein- und Auslagern von Seiten.
• Mögliche Ursachen:
- Lokale Verfahren: Zahl der Seiten zu gering.
- Globale Verfahren: ein Prozeß braucht zu einem
Zeitpunkt sehr viele Seiten, wodurch die
Bereiche aller anderen sehr klein werden.
• Abhilfe:
- Eventuell Prozeß mit niedriger Priorität ganz
auslagern Speicher wird frei
- Zuordnen ausreichend vieler Kacheln
Problem: Bestimmen dieser Anzahl
Lösungsansatz: Working-Set-Modelle
69
Working-Set-Modell
• Lokalitätsprinzip:
- Programm greift in einem kleinen Zeitraum ∆t
nur auf einen kl. Teil seines Adreßraums zu.
- Räumliche Lokalität: nach Zugriff auf Adr. a ist
ein Zugriff in der Nähe von a wahrscheinlich.
- Zeitliche L.: nach Zugriff auf Adr. a ist ein
erneuter Zugriff (in Kürze) auf a wahrscheinl.
- Gründe: sequentielle Ausführung, Schleifen, ...
• Bem.: Lokalität ist Grundlage für Caching.
• Approximation durch Working-Set-Modell:
-
Working Set: in ∆t benutzte Seitenmenge.
Problem: richtige Wahl von ∆t.
Lösungsansatz: Timer & Referenzbit
Bem:
o ∆t bzgl. der Rechenzeit des Proz.
o Working Set Size ändert sich ständig.
70
4.5.4 Shared Memory
• Kacheln gemeinsam nutzen:
- Datenaustausch zw. Prozessen,
- Redundanz von Code vermeiden.
• Speicherbereich kann an verschied. logischen
Adressen eingeblendet werden:
Hintergrundspeicher
shared
shared
Logischer AR
System
M
M
U
Physikalischer AR
System
• Muß beim Auslagern berücksichtigt werden
betrifft auch bei lokalen Strategien andere!
• Copy-On-Write:
- Speicher nur zum Lesen gemeinsam nutzen.
- schreibt ein Proz., so wird die zugehörige Seite
kopiert Änderungen für andere unsichtbar.
- für Unix fork, globale Variablen in Windows
DLLs, ...
71
4.5.5 Fallstudie: Intel i386
Adressierung im Protected Mode
Segmentselektor
virtuelle
Adresse
GDTR LDTR
Lokale
Deskriptortabelle
Globale
Deskriptortabelle
SEGMENTIERUNG
• Segmentierung und Paging kombinierbar:
PAGING
lineare
Adresse
CR3
Page
Directory
Page
Table
physikalische
Adresse
72
Intel Arbeitsregister ab i386
• Für Anwendungsprogramme zugänglich,
• Arbeitsregister verknüpft mit bestimmtem
Segmentregister, aber umsteuerbar.
• Funktionsbezogene Arbeitsregister:
- Stack, Code,
- Daten, Extra-Daten,
- Flags (mit IO-Privilege Level).
SS
CS
ESP
EIP
SP
DS
EAX
AX
AL
EBX
ECX
EDX
BX
BL
CX
CL
DX
DL
ES
FS
ESI
EDI
SI
GS
EBP
BP
Eflags
Flags
IP
DI
73
Intel Steuer- & Kontrollregister
• Verwendung:
Erweiterte Adressierung im Protected Mode,
Zugriffsschutz & Maschinenzustand
Prozessorsteuerung (Control [0..3]).
SS
CS
DS
ES
FS
GS
SS-Basis/-Limit
CS-Basis/-Limit
SegmentDS-Basis/-Limit
DeskriptorES-Basis/-Limit
caches
FS-Basis/-Limit
GS-Basis/-Limit
TR
LDTR
TSS-Basis/-Limit
LDT-Basis/-Limit
IDTR
GDTR
IDT-Basis/-Limit
GDT-Basis/-Limit
CR0
CR1
CR2
CR3
Debug,
Test
74
• Segmentregister bzw. -selektor hält Index in
die globale oder die lokale Deskriptortabelle.
• Gleichzeitig mit dem Segmentregister wird
implizit der Segmentdeskriptorcache geladen.
• Dabei geschehen unter Umständen mehrere
Hauptspeicherzugriffe.
• Auch für das aktuelle Task-State Segment und
die lokale Deskriptortabelle werden Deskriptoren gepuffert (gecached).
• Segmentdeskriptorcache nicht zugreifbar.
• 4(5) Kontrollregister:
CR0 PG
......
TS, EM, MP, PE
reserviert
CR1
Lin. Pagefault-Adresse
CR2
CR3 PageDirectory Adr.
CPU Erweiterungen
CR4
• CR0:
Paging, Taskswitch, Coproc., Protected Mode.
75
Segmentdeskriptoren
• Die Originaldeskriptoren liegen in der lokalen
oder der globalen Deskriptortabelle.
• Segmentdeskriptorcaches unsichtbar in CPU.
• Potential für einen segmentierten virtuellen
Speicher ohne Seiteneinteilung:
-
für jedes Objekt einen Segmentdeskriptor,
anstatt eines Zeigers nur Segment-Selektor,
gleichzeitig 8000 lokale & 8000 globale D.
evtl. Segment-Deskriptoren in LDT und GDT
ein- & auslagern und Selektoren ergänzen.
• Schutzfunktion bei Segmentierung:
- Zugriffsmodus (exec, read, write ),
- Protection Level (0..3)=(privileged .. non-priv.)
- Segmentlänge im Deskriptor.
• Die Segmentregister arbeiten im Protected
Mode als 16 Bit Segmentselektoren:
Requ.
Tabellenindex
15
LDT Priv.
GDT Level
2
1
0
76
Formate von Segmentdeskriptoren
• Deskriptor für Applikationssegmente:
Granularität
32/16 Bit,
Reserve,
OS use,
8
31..24
19...
4
Basis 15..0
Present,
Protect 0..3,
Application-Deskr.,
Typ 23..16 4
Limit 15..0
0
• "Historium" aus der Intel 286 Architektur.
• Granularität der Länge: 1 Byte / 4K Page.
• 32 Bit oder 16 Bit Instruktionen & Adressen.
• Beim Zugriff auf ein ausgelagertes Segment
erfolgt ein Interrupt an das Betriebssystem.
• Nur Deskriptoren mit gleicher oder
niedrigerer Sicherheitsstufe dürfen geladen
werden (CS).
77
Applikations-Segmente
• DT-Bit=1: Kennung für Applikationsseg.
#11: EXE (code/not data)
#10: E/C (downward,conforming),
#9: W/R (write data, read code),
#8: A (accessed).
1 Typ
P
• Bit#11=true (EXE-Bit): Code
- Codesegment, darf ausgeführt werden,
- darf auch gelesen werden, falls Bit9=true (W/R),
- falls Bit#10=true (conforming), ist Ausführung
durch ein unterprivilegiertes Segment gestattet.
• Bit#11=false (EXE-Bit): Data
- Datensegment, nicht ausführbar,
- schreiben erlaubt, falls Bit9=true (W/R),
• falls Bit#10=true (abwärts), erstreckt sich das
Segment von Basisadresse nach unten (Stack).
• Bit#8=true (Access-Bit):
- dieses Segment wurde benützt,
- nützlich für die Speicherauslagerungsstrategie.
78
Intel386 System-Segmente
• Haben das DT-Bit gelöscht.
• Call-Gate Deskriptor (Typ = 12):
-
beschreibt den Einsprung in geschützte Routine,
normalerweise in anderem Segment (far call),
referenziert einen weiteren Segmentdeskriptor,
ändert kurzzeitig die Privilegierungsebene,
übernimmt bis zu 128 Parameterbytes:
present, privilege, typ12
Zieloffset 31..16
Zielsegment #
DWcnt
Zieloffset 15..0
• Interrupt- & Trap-Gate Deskr. (Typ = 14/15):
- beschreibt den Einsprung in Interruptroutine,
- 8 Byte Einträge in Interrupt-Deskriptortabelle,
- IDT-Basis/Limit geladen über LIDT-Instruktion,
present, privilege, typ14/15
Zieloffset 31..16
Tables
Zielsegment #
Zieloffset 15..0
Tables
• Trap-Gate Deskriptoren (Typ = 15) arbeiten
ähnlich, jedoch ohne Interrupts zu maskieren.
79
• Task-Gate Deskriptor (Typ = 5):
- referenziert ein Task-State Segment (TSS),
- evtl. mehrere Task-Gates für ein TSS,
- enthält Privilegierungsstufe:
present, privilege, typ=5
Tables
TSS Zielsegment #
• Task-Switch falls:
- Far-Call oder Far-Jump, falls Sprungzielselektor
Task-Gate oder TSS,
- Interrupt oder Exception, falls zugehöriger IDTEintrag auf Task-Gate verweist.
- IRET von. nested Task.
80
• Task-State Segment Deskriptor (Typ = 9/11):
-
Enthält akt./geretteten Prozessorzustand (TSS),
Segmentselektor für lokale Deskriptortabelle,
Basisadresse für Seitentabellendirectory,
Stacks der Privilegierungstufen 0,1,2,
aktuell sichttbare Prozessorregister,
Zugriffsmaske für die E/A-Ports,
Link zum vorherigen Tasksegm.,
aktives TSS mit Typ=11.
Task-State Segment
11111111
TSS-Limit
IO-Permission
Bitmap
OS Zeux
IO-Bitmap
TSS-Base
Register
Stacks 0,1,2
PrevTSS
Task-Register
81
Zugriffsschutz-Mechanismen
• Zugang über Gate-Deskriptoren.
• Max. vier Privilegierungsebenen, zum Bsp.:
3:
2:
1:
0:
Anwendungsprogramme,
Laufzeitumgebungen, GUI ...
Gerätetreiber,
Kernel.
1
2
3
0
Privilegierungscode:
CPL im aktuellen Codesegment,
RPL im Selektorargument,
DPL im Deskriptor,
IOPL in Flags.
• Zur privilegierteren Ebene nur über ein Gate:
Call, Trap, Interrupt, Task, TSS,
Ausnahme: Conforming Deskriptors.
82
4.6
Beispiele: Linux & Windows NT
4.6.1 Linux
• Unterteilung des virtuellen Adreßraums:
- User Mode: 0-3GB.
- Kernel Mode: 3-4 GB.
• Zonen des physikalischen Adreßraums:
-
ZONE_DMA: für ISA Geräte.
ZONE_NORMAL: Standardzone.
ZONE_HIGHMEM: > 896 MB RAM.
Zonen-Information siehe auch Befehl dmesg.
4 GB
virtueller
Adreßraum
physikalischer
Adreßraum
Kern
3 GB
ZONE_HIGHMEM
User
896 MB
ZONE_NORMAL
16 MB
0
ZONE_DMA
0
• Dreistufige Seitentabellenstruktur:
- Entwickelt für 64-Bit Alpha.
- IA 32 unterstützt nur zweistufige Tab.
Eintrag im Page-Directory wird als mittlere
Seitentabelle mit nur einem Eintrag behandelt.
83
• Kachelverwaltung:
-
mit Hilfe der Buddy-Technik,
freier Block schnell auffindbar,
mildert externe Fragmentierung,
aber interne Fragmentierung problemat.,
Kacheln des Kerns werden nicht ausgelagert.
• Slab Allocator:
-
gruppiert Objekte gleichen Typs in Caches
ein Cache ist in mehrere ‚slabs’ unterteilt.
Zum Bsp.: voll, partiell gefüllt, leer, ...
pro ‚slab’ eine oder mehrere Kacheln.
Allokation in den Größen 2x (x>5).
Mildert interne Fragmentierung.
Info: cat /proc/slabinfo
• Seitenersetzung:
- Modifizierter Clock Algorithmus.
- Use-Bit erweitert durch 8-Bit Altersvariable.
- Wird bei jedem Anpassen des Zeigers erneuert.
• Insgesamt komplizierte Speicherverwaltung.
• Weitergehende Informationen unter:
- http://linux-mm.org
- http://kt.zork.net/kernel-traffic/kt20030124_202.html#22
84
4.6.2 Windows NT
• Unterteilung des Adreßraums:
- User Mode: 0-2GB.
- Kernel Mode: 2-4 GB.
• Zustände der Seiten eines Prozesses:
- Verfügbar: ungenutzte Seiten.
- Reserved: logischer Adreßbereich reserviert.
- Commited: Kacheln bzw. Platz in Paging Datei
wird alloziert.
- Vorteil: Kacheln möglichst spät allozieren.
• Kacheln je nach Zustand in eigener Liste
page frame database
• Seitenersetzung:
- variabel großer Working Set; Standardwerte für
Minimum und Maximum.
- lokale Strategie:
o FIFO bei Multiprozessor-Systemen.
o Clock bei Einzel-CPUs.
- Anpassung des Working Set (WS):
o Wenn genügend Kacheln vorhanden sind
wächste der WS bei einem Seitenfehler.
o Wenn HS knapp wird, so werden die WSs
geschrumpft (ältere Seiten auslagern).
- Clustering: Beim Einlagern einer Seite werden
Nachbarseiten mit eingelagert.
85
4.7
Automatische Freispeichersammlung
• = „Garbage Collection“
• Explizite Speicherrückgabe durch den Programmierer ist fehleranfällig und mühsam.
• Manche Prog.sprachen sammeln Speicherbereiche, die nicht mehr adressierbar sind auto.
wieder ein (Java, Oberon, .NET, ...).
Motivierung & Voraussetzungen
• Freigabe von Speicher ist fehleranfällig:
- dangling Pointers
- Code notwendig zum Abbauen komplexer
Strukturen
- bei modularer Programmierung werden
Kontrollstrukturen benötigt
(müssen explizit programmiert werden)
- Nicht Freigabe von Speicher ist ebenfalls eine
Fehlerquelle (Memory leaks)
• Voraussetzungen:
- Sämtliche Referenzen auf einen Speicherblock
müssen auffindbar sein.
- Typsichere Sprache dringend empfohlen.
86
Assignment-Listen:
Heap Blöcke
Nil
Nil
• Die Freispeichersammlung sammelt nun alle
Blöcke mit leerer Assignment-Liste ein.
• Heap-Kompaktifizierung:
- Verschieben von allozierten Blöcken
- Zeiger mit Hilfe der Assignment-Liste anpassen.
• Beispiel: Plurix Backchain.
87
Grundtechnik
• 2 Phasen Modell
- 1. Phase: Erkennung von referenzierbaren und nicht
mehr referenzierbaren Objekten (Garb. Detection)
- 2. Phase: Freigabe des Speichers von nicht mehr
referenzierbaren Objekten (Garbage Reclamation).
• Nicht mehr referenzierbare Objekte erkennen:
es existiert kein Pfad zwischen dem Objekt und
einer Zustandsvariablen (Root-Set).
• Zustandsvariablen:
- globale/statische Variablen,
- lokale & Modulvariablen.
• Jeder (allozierte) Block führt eine Liste mit
Zeigern, welche auf ihn zeigen.
• Im Falle einer Allozierung (New...) wird der
zugeordnete Zeiger eingetragen.
• Wird ein gültiger Zeigerinhalt einem anderen
Zeiger zugewiesen (assigned), so wird auch dieser
Zeiger eingetragen.
• Wird eine Zeigervariable freigegeben, so muß sie
aus der Assignment-Liste entfernt werden. Das
kann schwierig werden.
88
4.7.1 Mark & Sweep
• Der Sammelalgorithmus markiert alle noch
erreichbaren Blöcke im Heap:
Garbage
Z
Z
Z
• Nicht markierte Blöcke sind dann frei (bzw.
Garbage) und können eingesammelt werden.
für jede Zustandsvariable s:
Markiere(s);
für jedes Objekt o, für das gilt o.mark = 0 :
Speicherfreigabe(o)
Markiere(s):
wenn s.mark = 1 dann beende Prozedur
s.mark := 1;
für jedes von s referenzierteObjekt o:
Markiere(o)
89
• Ausgehend von einer Menge von Wurzelzeigern werden alle noch aktiven (live) Zeiger
und deren Objekte gefunden.
• Das Verschieben von Blöcken zur Gewinnung
von größeren Bereichen (Kompaktieren) ist
möglich aber mühsamer.
• Die Freispeichersammlung muss in einem
Manipulation an
Stück zu Ende laufen.
Zeigern durch das Anwenderprogramm
würden die Freispeichersammlung verwirren.
• Die hierzu erforderlichen Symbol- und Typentabelle wird vom Compiler erzeugt.
90
4.7.2 Compilerunterstützung
• Referenzen innerhalb eines Blocks müssen
identifizierbar sein, benötigt wird:
-
Offset und Typ der globalen Zeigervariablen,
Offset und Typ der lokalen Zeigervariablen,
Identifikation der Prozedurframes im Stack,
Zeigerfelder in dynamisch allozierten Records.
X
X
^Y
^Y
B
Y
A
^X
^Y
^X
^Y
Global
Stack
Global Frame
Proc-A Frame
Proc-B Frame
Record-X Type
Record-Y Type
…
Y
^X
^Y
Heap
– – –
– –^X
–^Y –
– – –
–^X –
– –
– –
– –
–^Y
– –
–^Y
– –
– –
– –
–^Y
Tabelle
– –
– –
– –
– –
– –
91
4.7.3 Kopierende Freispeichersammlung
• Die Objekte werden solange von einer alten
Region in eine neue kopiert bis der Rootset
nur noch Referenzen in die neue Region hat.
• Ein kopiertes Objekt darf nicht mehr in die
alte Region zeigen.
• Ein Objekt wird zusammen mit den Objekten
kopiert auf welche es zeigt.
• Eventuell Zugriffe auf die alte Region mit
MMU abfangen.
Alte Region
Neue Region
92
5. Plattenspeicher
5.1
Aufbau einer Festplatte
5.1.1 Physikalischer Aufbau
• Platten:
-
magnetisierbare Schicht.
rotieren mit 5.400 - 15.000 U/min.
unterteilt in konzentrische Spuren (Tracks).
Spuren sind wiederum in Sektoren unterteilt.
äußere Spuren mit bis zu 40% mehr Sektoren.
Zylinder = Menge aller Spuren, die mit fester
Armposition gelesen werden können.
• Kamm mit Leseköpfen.
• Adressierung:
- über Zylinder, Kopf, Sektor (CHS),
- oder über logische Block Nummer (LBA)
93
5.1.2 Aufbau eines Sektors
GAP3
DATA
ECC
DAM
SYNC
GAP2
ECC
ID
IDAM
SYNC
SPD
GAP1
IAM
SYNC
• typischerweise 512 Bytes pro Sektor: entsteht
durch phys. bzw. Low-Level-Formatierung.
• Wichtige Felder:
-
ID: Zylinder; Head und Sektor
ECC: Error Correction Code
DATA: zur Informationspeicherung
GAP4: Nach letztem Sektor eines Zylinders
Aufbau des Bootsektors:
• Position ist (Zylinder 0, Kopf 0, Sektor 1)
• Wird durch BIOS beim Systemstart geladen
und angesprungen.
000
Bootlader (446 Bytes)
446
Partitionstabelle
510
Signatur (2 Bytes)
94
Fehlerbehandlung:
• Disks sind fehleranfällig
- Köpfe schweben über Oberfläche.
- Staubkorn kann zum Headcrash führen.
- Teilweise fehlerhafte Blöcke bei Auslieferung.
• Sector Forwarding:
- Controller hat Liste „schlechter“ Blöcke und
leitet Zugriffsversuch auf fehlerhaften Block
(unsichtbar für BS) auf einen Reserveblock um.
- Auswirkungen auf Disk-Scheduling !
- Reserveblöcke in allen Zylindern und / oder in
einem Reservezylinder.
95
5.1.3 Partitionstabelle
• Beschreibt logische Laufwerke (Volumes):
Offset Größe
Inhalt
446
16
Partition 4
462
16
Partition 3
478
16
Partition 2
494
16
Partition 1
• Arten von Partionen:
- Primäre: max. vier Stück möglich bei PCs,
- Erweitert: primäre Part. mit log. Unterpart.,
- Logisch: einer erweiterten Partition zugeordnet.
• Nicht alle Partitionierungsprgramme arbeiten
gleich Vorsicht!
• Vorteile:
-
verschiedene Dateisysteme auf einer Festplatte,
mehrere Betriebssysteme auf einer Disk,
Trennung von System & Benutzerdaten,
Besonderheit in Linux: Swap-Partition.
• Namensgebung:
- Windows: Laufwerksbuchstaben „c:“, „d:“, ...
- Unix: interner Name: z.B. „/dev/hda2“.
96
Aufbau eines Partitionseintrages
Offset Größe Inhalt
0
1
Boot – Flag
(80h aktiv; 00h inaktiv)
1
3
Beginn der Partition
4
1
System Kennung
(z.B. 1: DOS 12-Bit FAT;
4: DOS 16-Bit FAT …)
5
3
Ende der Partition
8
4
Startsektor als logischer Sektor 0
12
4
Größe der Partition in Sektoren
• Probleme bei großen Festplatten
- 224 Sektoren zu 512Bytes = 8 Gigabyte
- 232 Sektoren zu 512Bytes = 2 Terrabyte
Mounting:
• Mounting: Einblenden einer Partition in
einem Verzeichnis des Dateisystems.
• Windows-Diskmanager, Unix: mount
mount
97
5.2
Festplatten-Scheduling
• Aufgabe des BS: effiziente Nutzung der Disk:
- Suchzeit: Kopf auf Zylinder positionieren.
- Rotationsverzögerung bis Sektor unter Kopf.
• Positionierung teuer:
- Möglichst sequentiell schreiben & lessen.
- Schreiben auf einer modernen IDE-Disk:
sequentiell: ~ 45 MB/s; verstreut: ~ 1 MB/s.
• Strategien zur Kopfpositionierung:
- Zufallsstrategie (Random): Aufträge werden in
zufälliger Reihenfolge ausgewählt.
- FCFS (First Come First Serve): Abarbeitung der
Aufträge in der Ankunftsreihenfolge.
- Prioritätsstrategie: Die Reihenfolge wird
entsprechenden der Priorität der Aufträge
erstellt.
- SSTF (Shortest Seek Time First): Auftrag mit
kürzester Armpositionierung zuerst
- SCAN (Fahrstuhlstrategie): Der Plattenarm
bewegt sich in eine Richtung, bis alle
Anforderungen abgearbeitet sind. Erst
anschließend ist Bewegung zurück oder in
andere Richtung erlaubt.
• Beispiel: Start bei 53; Sequenz: 98, 183, 37,
122, 14, 124, 65, 67
98
• FCFS (First Come First Serve):
- Kopfbewegung über 640 Zylinder.
• SSTF (Shortest Seek Time First):
- Mögliches Aushungern.
99
• SCAN (Fahrstuhlstrategie):
• Anmerkungen:
- FCFS erfordert im Mittel (Gleichverteilung) ein
Überfahren von 1/3 der Spuren.
- SCAN, und SSTF bringen vor allem bei starker
Last Vorteile, denn im Grenzfall ist nur eine
Spur weit zu springen.
- SCAN und SSTF benachteiligen die
„Randspuren“.
- SSTF ist i.a. am besten, kann jedoch zum
„Verhungern“ von Aufträgen führen.
100
5.3
Speicherverwaltung
• Sequentielle Natur einer Platte erfordert
andere Verfahren als im Heap:
- Armbewegungen sind kritisch,
- kleines Abbild im Hauptspeicher,
- optimale Suchverfahren für Verzeichnisse …
• Ausgangssituation: fast alle Dateisysteme
unterteilen Partition in feste Blockgröße:
- Kompromiß zw. Zugriffsgeschwindigkeit und
Fragmentierung bei Wahl der Blockgröße.
- Typische Werte: 0,5 – 32 KB (je nach Disk).
5.3.1 Freispeicherverwaltung
Bit-Vektoren
• Partition in Blöcke fester Größe unterteilen.
• Jeweils ein Bit zeigt an, ob ein Block frei ist
oder nicht (0=belegt,1=frei).
• 10 GB Disk, 1 KB pro Block
Bitmap.
1,25 MB für
• Bewertung:
- fortlaufende Blöcke einfach identifizierbar.
- u.U. große Bitmap bei kleinen Blöcken.
- Bitmap im virtuellen Speicher halten.
101
Verkettete Freispeicherliste
• Finden von N zusammenhängenden Blöcken
schwieriger.
• Ermitteln N aufeinanderfolgendener Blöcke
erfordert Durchlaufen von mind. N Blöcken.
• Ggf. effizienter als Bitmap, da nur freie
Blöcke gespeichert werden müssen.
102
Freispeicherverwaltung mit Zählen
• Verkettete Liste.
• Speichern von Zeiger und Anzahl unmittelbar
nachfolgender freier Blöcke in einem freien
Block.
• Vereinfacht die Suche nach N aufeinanderfolgenden Blöcken.
1
1
3
1
2
2
1
2
1
2
103
Freispeicherverwaltung mit Gruppieren
• Speichern der ersten N freien Blöcke im
ersten Block.
• N-1 dieser Blöcke sind frei.
• Im N-ten Block sind weitere N freie Blöcke
gespeichert - usw.
• Beispiel: N=4 Speichern von Zeiger und Anzahl unmittelbar.
104
Beispiel: Macintosh
• Vergabeeinheiten:
Logischer Block (512 Bytes)
phys. EOF
Belegungsblock
Erweiterungsquantum
• Log. Blöcke à 512 Bytes werden normalerweise auf einen phys. Sektor abgebildet.
• Die Belegungseinheit (Allocation Block) ist
jeweils mindestens 2 logische Blöcke. Dies
reduziert die Größe der Vergabetabellen.
• Die Zuteilung erfolgt aber in Erweiterungsquanten (Clumps) von mehr als einer Belegungseinheit:
- typisch sind 4 Belegungseinheiten,
- teilweise erfolgt Rückgabe nach Close,
- fördert zusammenhängende Dateiplazierung.
105
5.3.2 Speicherallokation
• Allokation von Blöcken für Dateien.
• Ziele:
- effektive Ausnutzung der Festplatte (Disk),
- schneller Dateizugriff.
Zusammenhängende Allokation
• Jede Datei belegt zusammenhängende Blöcke.
• Problem bei der Expansion von Dateien.
• Platzverschwendung (externe Frag.).
• Einfach Implementierung.
• Effektiver Zugriff.
Datei
Test.java
.profile
Plan
News
Mail
Start Länge
0
2
6
2
16
3
19
6
28
4
106
Verkettete Allokation
• Datei als verkettete Liste von Blöcken.
• Beliebige Anordnung der Blöcke einer Datei.
• Expansion von Dateien einfach.
• Keine Platzverschwendung.
• Speichern von Zeigern in Blöcken.
• Bei einem beschädigtem Block geht die ganze
Datei verloren.
• Zugriffsgeschw. abhängig von Zersplitterung.
• Z.B. FAT (leicht abgewandelt).
Datei
Test.java
…
Start Länge
9
25
…
…
107
Multilevel-Index Allokation
• Limitierte Dateigröße bei einem Indexblock:
- 1 Block = 512 Byte
- Z.B. 1 Zeiger = 4 Bytes
max. 128 Zeiger Datei max. 64 kB
• Verketten von Indexblöcken.
• Multilevel Index:
- Beispiel: 2 Level
- 128*128 Zeiger 16384 Zeiger
- max. Dateigröße = 8 MB
• mehrere Levels z.B. in Unix I-Nodes (Typen:
Dateien, Verzeichnisse, Links, ...).
VerwaltungsInformation
Direkte
Blöcke
Blöcke mit 1er
Indirektion
Blöcke mit 2
Indirektionen
108
5.4
Dateisysteme
• Anforderungen: Persistenz, Zugang per Name,
Schutz durch Zugriffsrechte, ...
• Logische Formatierung = Initialisierung
einer Partition mit einem Dateisystem.
• Datei (File):
- Def.: Behälter zur dauerhaften Speicherung von
beliebigen Informationen (Daten & Prgs).
- Dateistruktur abhängig vom Dateityp.
- Attribute: Name, Typ, Grösse, letzte Änderung,
Zugriffsschutz, ...
• Verzeichnis (Directory):
- Vom Dateisystem verwaltete Datei zur
Strukturierung externer Speichermedien.
- Problem: Organisation der Dateinamen
o flacher Namensraum alle Dateienamen
müssen systemweit eindeutig sein.
o hierarchische Organisation besser.
• Verweis (Link, Shortcut):
- Direkter Zugriff, ohne navigieren zu müssen.
- Links in Unix:
o fest: Verweis auf I-Node.
o symbolisch: Verweis auf Dateinamen.
- Problem beim Löschen: ungültige Links.
109
5.4.1 Beispiel: Dateizugriff
• Unter Windows NT:
#include <string.h>
#include <windows.h>
int main() {
HANDLE
DWORD
char
hFile;
dwWritten;
*data=“hello world“;
hFile = CreateFile(
"c:\\test.txt",
GENERIC_WRITE,
// write access
0, NULL,
// share mode & security
CREATE_ALWAYS,
// creation mode
FILE_ATTRIBUTE_NORMAL|
FILE_FLAG_NO_BUFFERING,
NULL
// template file
);
WriteFile(hFile,
&data, strlen(data),
&dwWritten,
NULL
);
// file handle
// data + len
// #bytes written
// overlapped I/O
CloseHandle(hFile);
}
110
5.4.2 FAT16
• Allokation durch abgesetzt Verkettung in
FAT = File Allocation Table.
• Dateizuordnungstabelle:
- auf den ersten Spuren einer Festplatte,
- sicherheitshalber oft repliziert,
- für jeden Block einen Eintrag.
• Alle Belegungseinheiten (Blöcke) einer Datei
sind über die File Allocation Table verkettet:
- 0 = leerer Block.
- $FFF7 = schadhafter Block.
- $FFFF = letzter Block einer Datei.
0 fff7
#1 #2
4
#3
7
#4
0 fff7
#5 #6
8
#7
a ffff
#8 #9
b ffff
#a #b
• Verzeichnis zeigt auf den ersten Block einer
Datei, bzw. den ersten Eintrag in der Tabelle.
• Verzeichnisse sind ebenfalls Dateien.
• Größe einer Zuordnungseinheit:
- variabel, aber fest für eine Partition.
- üblich sind 512, 1024, 4096 Bytes.
111
• FAT16: DOS, Win 3.x
- 16-Bit max. 65.536 Cluster,
- max. 2 GB pro Partition bei 32KB Cluster.
• FAT32: Windows 98/Me
- 32-Bit keine 2 GB Beschränkung,
- weniger Verschnitt durch kleinere Cluster.
• VFAT16/32: virtual FAT; lange Dateinamen.
• Weitere Eigenschaften:
- FAT bietet keine Schutzmechanismen.
- aber Daten unter vielen BS zugänglich.
- optionale Kompression möglich.
Aufbau eines FAT16 Dateieintrages:
• Sind in Verzeichnisdateien untergebracht.
Offset
0
Größe
8
8
11
3
1
12
22
24
26
28
10
2
2
2
4
Inhalt
Dateinamen
Sonderfälle für das 1. Zeichen:
00h: leerer Eintrag
E5h: Eintrag wurde gelöscht
Dateinamen-Erweiterung
Attribute:
Archiv-Bit, read-only, Verzeichnis/Datei,
versteckt
Reserviert
Uhrzeit der Erstellung
Datum der Erstellung
Start Cluster
Dateilänge
112
5.4.3
I-Nodes in Unix
• I-Node ! Index-Nodes.
• Zentrale Struktur für Dateien.
• Aufbau eines I-Nodes:
-
„mode“ (16-Bit): Dateityp und Berechtigungen.
„link count“: Anzahl harter Links auf die Datei.
„owner gid“: Projektgruppe des Eigentümers.
„owner uid“: User-ID des Eigentümers.
„file size“: Größe der Datei in Bytes.
Zeiger auf Daten- und Indexblöcke.
Datumseinträge, ...
I-Node
data blocks
mode
link count
owner uid
owner gid
file size
...
direct blocks
(12)
single indirect
double indirect
triple indirect
...
...
index blocks
• Multilevel-Index Allokation (dreifach):
- Direkte Datenblöcke,
- und Extent-Blöcke per Index.
113
• Dateityp:
-
Verzeichnis,
reguläre Datei,
Special File für Block Device,
Special File für Character Device,
Special Files für Pipes und Sockets.
• Verzeichnisse:
-
Implementiert als Dateien.
Kennzeichnung im Typfeld.
Eintrag: Dateinnamen & I-Node-Nummer.
Zusätzliche Attribute in I-Nodes der Dateien.
Beispiel: Verzeichnisstruktur für /usr/ms
„/usr“
Wurzelverz.
I-Node #6
(Block 132)
I-Node #26
1
.
Modus
6
.
Modus
1
..
Grösse
1
..
Grösse
4
bin
...
19
ps
...
7
dev
132
26
ms
406
14
lib
51
sf
9
etc
30
rg
6
usr
8
tmp
• Implementierung in Linux ext2.
• Journaling Dateisysteme
ReiserFS, ext3, ...
(mit
Logging):
114
• Plattenstruktur:
BootBlock
SuperBlock
I-Nodes
...
Datenblöcke
...
- Boot-Block: Bootprogramm.
- Super-Block:
o Verwaltungsinfos: Blöckgröße, Liste freier
Blöcke, Liste freier I-Nodes, ...
o Wird im Hauptspeicher gehalten.
- I-Nodes: Liste fortlaufender I-Nodes.
- Datenblöcke: folgen im Anschluß an I-Nodes.
Zugriffsrechte
• Mit jeder Datei wird Besitzer und Gruppe, zu
der eine Datei gehört abgespeichert.
• Als Gruppe wird normalerweise die primäre
Gruppe des Besitzers verwendet.
• Ferner gibt es neun Zugriffsbits (r,w,x), für
den Besitzer, die Gruppe und den Rest.
• Zugriffsbits bei Verzeichnissen:
- r: Inhalt darf aufgelistet werden,
- x: mit cd darf in das Verz. gewechselt werden,
- x+w: neue Dateien dürfen angelegt werden.
115
• Beispiel Zugriffsbits: Besitzer, Gruppe, Rest
drwxr-xr-x 2 ms users 1024 Feb 10 10:39
-rwxr-x--- 1 ms users 224 Feb 10 10:36
-rw------- 1 ms users 103 Feb 12 09:39
Typ+Rechte #Links
Größe Datum
Mail/
hello.c
test
Name
Spezialbit: Setuid
• Problembeispiel:
- Nur root darf auf die Passwortdatei zugreifen.
- User sollten gelegentlich ihr Passwort ändern,
dürfen aber nicht auf die Datei zugreifen.
• Lösungsansatz:
- Passwortprogramm gehört root und hat sein
Setuid-Bit gesetzt.
- Wird es vom User gerufen, so läuft es nicht etwa
mit der Zugriffsberechtigung des Users, sondern
mit derjenigen des Eigentümers (z.B. root).
- Nur der Eigentümer kann das Setuid-Bit setzen
(und immer auch root).
- Es geht nicht um die Ausführungsberechtigung
von /bin/passwd, sondern um den Zugriff auf
/etc/passwd.
- Verfahren patentiert (durch Dennis Ritchie).
• ls –l zeigt bei den Benutzer-Zugriffsbits ein
s (statt eines x) an.
116
Spezialbit: Setgid
• Bei der Ausführung des Programms wird
immer die GID der Datei verwendet (und
nicht die GID des aktuellen Benutzers).
• ls –l zeigt bei den Gruppen-Zugriffsbits ein
s (statt eines x) an.
• Bei Verzeichnissen bewirkt dieses Bit, daß
neu angelegte Dateien der Gruppe des Verz.
angehören (nicht der Gruppe des Benutzers).
Spezialbit: Sticky
• Bewirkt bei Verzeichnissen, auf denen alle
Benutzer Dateien ändern dürfen, daß nur
eigene Dateien gelöscht werden dürfen.
• Zum Beispiel
für /tmp.
• ls –l zeigt bei
allen gültigen
Zugriffsbits ein t
(statt eines x) an.
117
5.4.4
NTFS
Allgemeine Eigenschaften
• Fehlertoleranz:
- Transaktionskonzept (all-or-nothing).
- Logging: undo/redo nach Absturz.
- RAID: Diskfehler tolerieren.
• Sicherheit:
- Zugriffskontrolle,
- Verschlüsselung (EFS).
• Unterstützung für große Disks & Dateien
64-Bit für Blocknummern
• Mehrere Datenströme pro Datei
Zugriff über datei:stream
• Alle Informationen des Dateisystems werden
als Datei gespeichert, auch Metadaten.
• Optionale Kompression möglich.
Volumes
• Unterteilung der Partition in Clusters.
• Cluster besteht aus einem oder mehreren
fortlaufenden Sektoren.
118
• Struktur eines Volumes:
PBS
MFT
SystemFiles
File Area
• PBS (Partition Boot Sector):
- Boot-Programm (optional).
- Sektoren pro Cluster.
- Plattengeometrie, ...
• MFT (Master File Table):
-
MFT ist auch eine Datei.
entspricht I-Node Tabelle.
pro Datei/Verzeichnis ein Eintrag.
beschreibt die Lage der Datenblöcke.
• Systemdateien:
- MFT2: erste drei Zeilen der MFT
- Log-Datei: Änderungen an MFT protokollieren
- Volume-Datei: Größe & Name des Volumes,
Versionsnummer der Part.
- Bitmap-Datei: freie & belegte Cluster.
- Boot-Datei:
o Größe eines Clusters,
o und eines MFT-Eintrags,
o sowie Boot-Code (Kopie von PBS).
- Bad-Cluster-Datei: vermerkt defekte Cluster.
119
• Aufbau eines MFT-Eintrages:
- Sammlung von Attributen.
- „standard info“: verschied. Datumseinträge.
- „security descriptor“: für Zugriffskontrolle.
standard
info
file
name
security
descr.
data
starting starting no. of
VCN
LCN clusters
VCN
0
1355
3
4
1388
4
VCN
0
1
2
VCN
3
data
LCN 1355
4
5
6
data
1357
LCN 1388
1391
- kleine Dateien wird direkt in MFT abgelegt.
- große Dateien belegen mehrere Einträge in MFT
(Base-Record enthält nur Zeiger).
• Adressierung:
- über Cluster-Nummern (CN).
- virt. CN (VCN): Adressierung in einer Datei.
- log. CN (LCN): Adressierung in einer Partition.
120
• Attribute:
- Jede Datei ist ein Satz von Attributen.
- Sämtliche Elemente, wie z.B. der Dateiname,
die SicherheitsID, die Daten sind Dateiattribute.
• Aufbau eines Verzeichnisses:
-
Sammlung von Referenzen auf Dateien.
Dateinamen im Verzeichnis repliziert.
Referenziert über Position in MFT.
Sequentielle Suche in kleinen Verzeichnissen
(die in einem MFT-Eintrag Platz finden).
- Für umfangreiche Verzeichnisse ein B*-Baum
indiziert nach Namen der Dateien.
- Aber kein B*-Baum über alle Dateien auf einem
Volume.
Fehlertoleranz
• Nur die Integrität der MFT gewährleistet.
• Jede Modifikation an der MFT wird in eine
Transaktion gekapselt.
• Transaktionen können wiederholt und rückgängig gemacht werden.
• Hierzu werden Update-Operationen einer TA
in einer Logdatei protokolliert (Undo+Redo).
• Mehr Infos: Helen Custer, „Inside Windows
NT File System“, Microsoft Press, 1994.
121
5.4.5 Memory-Mapped Files
• (Teil einer) Datei wird in den virtuellen
Adreßraum eingeblendet.
• Speicherzugriffe auf diesen Bereich werden
wie Dateizugriffe behandelt.
• Implementierung:
-
logischen Adreßraum reservieren.
Seitentabellendeskr. zeigen auf Disk-Blöcke.
bei einem Seitenfehler wird von Disk geladen.
Zurückschreiben beim Schließen der Datei.
• Beispiel: Unix
#include <unistd.h>
#include <stdio.h>
#include <fcntl.h>
#include <sys/mman.h>
void main() {
char * p;
int fd;
fd = open("txt", O_RDWR);
p = mmap(0, getpagesize(), PROT_READ|PROT_WRITE,
MAP_PRIVATE,fd, 0);
printf("%08X\n", p);
munmap(p, getpagesize());
close(fd);
}
122
5.5
Redundanz & Spiegelung
• RAID:
-
Redundant Array of Inexpensive Disks.
mehrere Levels def. von Universität Berkeley.
Software- und Hardware-Lösungen vorhanden.
Hardware sollte ebenfalls dupliziert werden.
• RAID Level 0:
- keine Redundanz der Daten.
- Daten werden auf mehrere Platten verteilt
hohe Lese- und Schreibleistung.
• RAID Level 1:
-
z.B. Windows NT.
benötigt zwei Festplatten.
wird auch als „Spiegeln“ bezeichnet.
Gesamtkapazität entspricht einer Platte.
Schreiboperationen immer auf beiden Disks.
• RAID Level 4:
-
Platten werden nicht mehr komplett gespiegelt.
Festplattenkapazität wird besser ausgenutzt.
Redundanz durch Checksumme (XOR).
Nachteil: Parity Platte ist Flaschenhals.
• RAID Level 5:
- Paritätsinfo verteilt über alle Festplatten.
- z.B. Windows NT.
123
6. Nebenläufigkeit
6.1
Prozesse und Threads
6.1.1 Begriffliches
• Nebenläufig.: paralleler od. verzahnter Ablauf
• Parallelität: simultaner Ablauf.
P1
P2
P3
1 Prozessor
P2
P1
P3
3 Prozessoren
• Ziele: Wartezeiten ausnutzen und den Eindruck der Gleichzeitigkeit erwecken.
• Programm: statische Darstellung eines Algo.
• Prozeß = Adreßraum + Thread(s)
124
• Task = Aufgabe, die durch einen oder mehrere
Prozesse erledigt wird.
• Thread (Leichtgewichtsprozeß, Ausf.-Spur):
-
gehört zu einem Adreßraum,
teilt sich Daten, Code u. BM,
separater Registersatz & Laufzeitkeller,
beschreibt dyn. Ablauf der Verarbeitung.
Instruktionsteil
Programm
zähler
Gemeinsame Daten
• Multithreading: mehrere Threads pro Prozeß
• Multitasking: Mehrere Tasks werden (scheinbar) gleichzeitig ausgeführt.
• Preemptives Multitasking:
BS kann einer Task CPU jederzeit entziehen.
• Kooperatives Multitasking:
Tasks müssen Prozessor freiwillig freigeben.
125
6.1.2 Prozeßmodelle
• Sequentiell: viele Module und ein Thread
(~ Modula-2):
• Nebenläufig:
- Viele Threads u. ein gemeinsamer Adreßraum
(Light-Weight Process),
- Viele Threads und pro Thread ein eigener
Adreßraum (trad. Unix-Prozeß).
• Terminologie in Literatur nicht einheitlich.
126
• Verwaltung durch einen Prozeßkontrollblock:
- Charakteristika,
- Zustandsinformation,
- Verwaltungsdaten für BS.
ID
Programmname
Speicherinformation
Betriebsmittel
Priorität
User-ID
• Prozeßzustände:
blockiert
debloc
neu
start
warten
freigeben
bereit
läuft
beendet
stop
zuordnen
127
Unix
• Viele Prozesse mit eigenem Adreßraum, aber
jeweils mit nur einem Thread.
• Moderne Varianten bieten mehrere Threads
pro Proz. (z.B. spezielle Bibliothek in Linux).
• Erzeugen von Prozessen durch „fork“:
- Vater-Sohn-Beziehung,
- erzeugt Kopie des aktuellen Prozesses.
• Hintergrundprozesse werden als Daemon bezeichnet (z.B. Spooler).
• Prozeßzustände in Unix:
128
Windows NT
• Prozeß:
- ein oder mehrere Thread(s),
- keine Verwandtschaft zw. Prozessen,
- in BS-Verwaltung als Objekt implementiert.
• Dienste als Hintergrundprozesse:
- siehe „Dienste“ in Systemsteuerung,
- kontrolliert durch Service Control Manager.
• Taskmanager zeigt Prozeßliste.
• Threadzustände:
129
• Prozeß starten durch „CreateProcess“:
main() {
STARTUPINFO
si; // window stuff
PROCESS_INFORMATION pi; // handles
CreateProcess(
„MyProg.exe“, // Programm (Pfad)
„“,
// command line
NULL,
// process attributes
NULL,
// thread attributes
FALSE,
// inherit handle
CREATE_NEW_CONSOLE,
NULL,
// env. Block
NULL,
// curr. Directory
&si,
// startup info.
&pi
// process info.
);
...
}
130
6.1.3 Multithreading
• pro Thread ein separater Adreßraum ist teuer:
- Start ist aufwendig,
- Kontextwechsel ist teuer (Cache & TLB),
- kontextübergreifende Komm. ist langsam.
mehrere Threads in einem Adreßraum
• Verwaltung durch Thread-Kontrollblöcke:
ID
Programmzähler
Register
Priorität
Ausführungszeit
• Typische Einsatzgebiete:
- Blockierendes Warten auf Ereignisse,
- Benutzerschnittstelle am Leben erhalten,
- gleichzeitige Bearbeitung von unabhängigen
Aufgaben innherhalb eines Programmes.
131
• Beispiel: Thread in Windows NT:
#include "stdio.h"
#include "windows.h"
DWORD
HANDLE
HANDLE
loop = 500*1000*1000;
hEvent;
hChild;
DWORD WINAPI Child( LPVOID lpParm ) {
while (loop>0){
--loop;
};
printf("'Child' signalisiert:\n");
SetEvent(hEvent);
return 0;
}
int main(int argc, char* argv[]) {
hEvent =CreateEvent(NULL, 0, 0, NULL);
// defaultSecurity, autoReset, nonsignalled, noname
hChild =CreateThread(NULL, 8, &Child, &loop, 0, 0);
// defaultSecurity, stack, procAddr, tParam, noname
printf( "'main' wartet auf Signal.\n" );
result =WaitForSingleObject( hEvent, INFINITE );
printf( "Signal ist angekommen !\n\n" );
}
132
Threads in Java:
• Sprachunterstützung für Threads.
• Java Virtual Machine bietet:
- Green threads: emuliert durch JVM.
- Native threads: abgebildet auf Betriebssystem.
• Thread-Funktionen in java.lang.Thread:
-
Starten: start();
Unterbrechen: suspend();
Aufwecken: resume();
Verzögern: sleep();
Abbrechen: stop();
Warten auf Beendigung: join();
• Beispiel:
class ExampleThread extends Thread {
int param;
ExampleThread (int p) { param = p; }
public void run() {
// was soll der neue Thread ausführen?
}
public static void main(String[] args) {
ExampleThread t = new ExampleThread(42);
t.start();
}
}
r
133
6.2
Koroutinen & Fibers
Koroutinen in Modula-2:
• Explizit zwischen Prozessen wechseln:
TRANSFER(VAR FromProz, ToProz: PROCESS)
IOTRANSFER(
VAR Handler,
Interrupted: PROCESS;
IntVec: CARDINAL);
NEWPROCESS( proc : Proc;
addr : ADDRESS;
size : CARDINAL;
VAR new : PROCESS);
• NEWPROCESS reserviert Speicher für Stack
des neuen Proz. (addr=Beginn & size=Größe).
• IOTRANSFER erlaubt Interrupt-Handler in
Modula-2 zu schreiben.
Fibers in Windows NT:
• Für BS unsichtbare Threads.
• Anwendung verwaltet Fibers in eigener Regie
und übernimmt Scheduling.
• API: “CreateFiber”, “SwitchToFiber”, …
134
6.3
Kontextwechsel
• Dispatcher: Modul welches Kontextwechsel
implementiert.
• Beim Umschalten auf einen anderen Thread
muß der aktuelle Kontext gesichert werden:
- hierzu dienen diverse Felder im PCB/TCB,
- teuer ist das Umschalten des Adreßraumes
Caches & TLB spülen
- Beschleunigung durch HW-Unterstützung
(z.B. Intel Tast State Segment).
• Gründe für einen Kontextwechsel:
-
Interrupt von HW,
Rechenzeit abgelaufen,
Warten auf Betriebsmittel,
freiwillige Abgabe der CPU.
• Umschalten muß teilweise verhindert werden,
z.B. bei HW-Zugriff in Treibern.
• Reentranter Code, falls Umschalten erlaubt:
- durch mehrere Threads gleichzeitig nutzbar.
- keine Zustandsinformation in globalen Var.
• Bem.: Compiler berücksichtigt auch Kontextwechsel, aber Klassen- und Modulkontexte.
135
• Ablauf:
laufend
Status von P1 sichern
schlafend
P2
P1
Status von P2 sichern
laufend
Status von P1 laden
schlafend
laufend
schlafend
Status von P2 laden
136
6.4
Ablaufplanung
• Scheduler:
- regelt die Zuteilung des Prozessors
- wählt nächsten Threads aus der Ready-Queue.
• Verdrängung = entziehen der CPU
• Ziele:
-
faire CPU Verteilung,
Wartezeiten bestmöglichst ausnutzen,
Verweilzeit von Programmen minimieren,
mögl. viele Threads pro Zeitintervall bedienen,
Antwortzeit f. interaktive Benutzer minimieren.
• Scheduler tritt in Aktion wenn ein Thread:
-
startet,
terminiert,
freiwillig die CPU freigibt,
auf ein Betriebsmittel wartet,
seine Zeitscheibe voll ausgenutzt hat.
6.4.1 Strategiealternativen
• ohne / mit Prioritäten
• ohne / mit Verdrängung (Preemption)
• unabhängig / abhängig von Bedienzeit
137
First Come First Served (FCFS)
• Bearbeitung der Threads in der Reihenfolge
ihrer Ankunft in der Bereitliste.
• Prozessorbesitz bis zum Ende oder freiwilligen Aufgabe.
• Beispiel:
- Laufzeit: t(T1)=24, t(T2)=3, t(T3)=3
- Ankunftsreihenfolge: T1, T2, T3
- durchschnittliche Wartezeit: (0+24+27) / 3 = 17.
T1
T2
0
24
T3
27
30
- Ankunftsreihenfolge: T2, T3, T1
- durchschnittliche Wartezeit = 3!
T2
0
T3
3
T1
6
30
• Probleme:
- Konvoi-Effekt = schnelle Threads hinter einem
langsamen.
- CPU-lastige Threads halten I/O-lastige auf.
138
Shortest Job First (SJF)
• Thread mit der kürzesten Bedienzeit wird als
nächster bis zum Ende oder freiwilligen
Aufgabe bearbeitet.
• Bevorzugt kurze Threads.
• Bedienzeit muß bekannt sein, lang laufende
Threads können verhungern.
• Beispiel:
- Laufzeit: t(T1)=7, t(T2)=4, t(T3)=1, t(T4)=5
- Ankunftszeiten: at(T1)=0, at(T2)=1, at(T3)=2,
at(T4)=3.
- non-preemptive: durchschn. Wartezeit = 6,75
T1
T3
0
7
T2
T4
8
12
17
- preemptive: durchschnittliche Wartezeit = 3,5
T1 T2 T3
0
1
2
T2
3
T4
6
T1
11
17
139
Round Robin (Zeitscheibenverfahren)
• Ziel: gleichmäßige Verteilung der CPU.
• Bearbeitung der Threads in der Ankunftsreihenfolge.
• Nach Ablauf einer vorher festgesetzten Frist
(z.B. 20-50ms) findet eine Verdrängung statt.
• Einreihung des Threads nach Ablauf des Zeitquantums in die Ready-Queue (sofern nicht
blockiert).
• Verbreitete Strategie.
• Problem: richtige Wahl der Zeitscheibe.
• Beispiel:
- Laufzeit: t(T1)=53, t(T2)=17, t(T3)=68,
t(T4)=24
- Ankunftszeiten: at(T1)=0, at(T2)=1, at(T3)=2,
at(T4)=3.
- Zeitscheibe = 20.
T1
0
20
T2
T3
37
57
T4
77
T1
97
T3
T4
117
T1
121
T3
134
T3
154
162
140
Prioritäts-Scheduling
• Jeder Thread erhält eine Prioritätsnummer.
• Threads mit der höchsten Priorität wird aus
der Ready-Queue selektiert.
• Bem: SJF ist Prioritäts-basiertes Verfahren
mit Priorität = erwartete Burst-Zeit.
• Implementierung: mehrere Ready-Queues:
- Vordergrund- und Hintergrundprozesse,
- oder für jede Priorität eine Warteschlange.
Gruppen gleicher Priorität
TCBs
• Problem Aushungern (Starvation): ein Thread
mit niedriger Priorität bekommt die CPU nicht
zugeteilt, da immer Threads mit höherer
Priorität rechenbereit sind.
• Lösung: Altern (Aging): Priorität steigt mit
der Wartezeit.
141
• Problem: Prioritätsinvertierung
Zustand
“blockiert”
wartet auf
Thread C
Prio=12
Ressource
besitzt
Thread A
Prio=4
Zustand
“bereit”
Thread B
Prio=8
Zustand
“rechnend”
- Thread C „verhungert“, trotz höchster Priorität.
- Thread B dominiert die CPU.
- Dadurch kommt Thread A nicht zum Zuge und
kann daher die Ressource nicht freigeben.
Thread C auf unbestimmte Zeit blockiert.
- Lösung Altern mit der Wartezeit:
o Priorität von Thread A steigt langsam an.
o Sobald sie >8 ist, löst sich das Problem.
142
6.4.2 Strategien für Echtzeitsysteme
• Echzeitsysteme müssen def. Zeitschranken
einhalten, auch in Fehlersituationen.
• Für krit. Anwendungen (z.B. Kernkraftwerk).
• Threads erhalten Sollzeitpunkte (Deadlines).
- Voraussetzung: Laufzeit vorab bekannt.
- Unterscheidung bei Sollzeitpunkten zwischen:
o Harter Echtzeit: Verletzung bedeutet
Ausfall des Systems (nicht tolerierbar).
o Weicher EZ: Qualitätseinbußen bei Verletzung, aber in Grenzen tolerierbar.
• Keine Desktop-Betriebssysteme, sonder mehr
für eingebette Systeme (z.B. OSEK).
Offline-Scheduling
• Scheduling vor der eigentlichen Ausführung
zur Vermeidung von Scheduling-Overhead.
• Vorberechnung eines vollständigen
führungsplans in Tabellenform.
Aus-
• Einfacher Tab.zugriff während Ausführung.
• Sinnvoll für harte Echtzeitanforderung.
143
Earliest Deadline First (EDF)
• Verbreitete Strategie.
• Threads mit Ausführungsfristen.
• Thread mit engster Frist wird bevorzugt.
• Beispiel: Earliest Deadline First
- Laufzeit: t(T1)=4, t(T2)=5, t(T3)=3
- Fristen: f(T1)=10, f(T2)=7, f(T3)=17
- non-preemptive; gleiche Ankunftszeit.
T2
T1
0
T3
5
9
12
- preemptive: Ankunftszeiten: at(T1)=0, at(T2)=1,
at(T3)=2.
T1
0
1
T1
T2
6
9
T3
11
• Dynamischer Einplanbarkeitstest notwendig,
wenn ein neuer Thread hinzukommt.
• CPU Auslastungsgrenze 100%.
144
Rate Monotonic Scheduling (RMS)
• Zur Beschreibung periodischer Systeme:
- hohe Priorität für Aktivitäten mit hoher Freq.
- niedrige Prio. für Akt. mit kleiner Frequenz.
• Ende der Periode entspricht Deadline.
• Voraussetzung: Threads sind unabhängig voneinander.
• Vorteil: minimale Verzögerung hochfreq.
Aktivitäten
• Nachteil: Zerstückelung niederfrequenter Akt.
wegen höherer Anzahl von Kontextwechseln
zu Threads mit höherer Priorität.
• Situation, die durch Verzögerung eines höher
priorisierten Threads, zu einem gültigen Ablauf führen, sind nicht lösbar.
• CPU Auslastungsgrenze 82,8%.
• Nicht optimal, aber große Bedeutung in Echtzeitsystemen.
145
6.4.3 Mehrprozessor-Aspekte
• Wahllose CPU-Zuteilung schlecht.
• Hat Thread t zuletzt Prozessor p genutzt, so
besteht die Chance, dass noch wesentliche
Teile seines Adressraums im Cache von p
vorhanden sind.
• Einführung der Prozessor-Affinität: TCB wird
um zuletzt benutzte CPU erweitert.
• Nachteil: Aufweichung von Prioritäten
6.4.4 Leerlaufproblem
• Falls alle Threads warten ist die CPU frei
• In dieser Zeit läuft ein Leerlauf-Thread:
- darf nicht anhalten,
- hat geringste Priorität,
- muß jederzeit verdrängbar sein.
• Im Leerlauf können diverse Aufgaben bearbeitet werden:
- Prüfungen,
- Garbage Collection,
- Heap Kompaktifizierung.
146
6.4.5 Scheduling in Unix
-m
Systemprozesse
…
-1
0
…
Benutzerprozesse
n
• Benutzerprozesse haben eine statische Basispriorität von 0 (erhöhbar mit „nice“).
• Dynamische Priorität:
- jede Sekunde angepaßt nach der Formel:
dyn_prio := base_prio + recent_cpu_usage / 2
- Prozessornutzung gemessen in „Uhr-Ticks”.
- Vorher wird schrittweise „vergessen”, wie groß
die Prozessornutzung war:
recent_cpu_usage := recent_cpu_usage / 2
• starke CPU-Nutzung
schlechten Priorität.
147
• Idee:
- Rechenintensive Prozesse werden
benachteiligt“.
- I/O-intensive Prozesse werden bevorzugt!
- Sie belegen den Prozessor nur kurz, um einen
E/A-Auftrag abzusetzen.
- Man erreicht dadurch eine hohe Parallelität
zwischen den aktiven Rechnerkomponenten
(CPU und Peripherie).
• Round Robin (z.B. 100ms bei BSD Unix) als
Scheduling-Strategie.
Linux:
• Verwendet eine Mischung aus verschiedenen
Schedulingklassen.
- SCHED_FIFO: FiFio-Strategie.
- SCHED_RR: Zeitscheiben-Verfahren.
- SCHED_OTHER: traditionelles Unix-Verfahren
• Scheduling für alle Klassen mit mehreren
Queues, je nach Priorität.
• SCHED_FIFO und SCHED_RR:
-
statische Priorität.
für Echtzeitprozesse.
reserviert für Superuser.
FiFo unlimitierte CPU-Zeit.
148
6.4.6 Scheduling in Windows NT
• Verdrängendes, auf Zeitscheiben basierendes
Scheduling mit Prioritäten:
- Workstation-Zeitscheibe: 20-30 ms.
- Server-Zeitscheibe: 150-180 ms.
• 32 Prioritätsklassen (32 FiFo-Queues):
- Leerlaufthread: 0.
- Variable Priorität: 1-15.
- Echtzeitpriorität 16-31 (statisch).
höchste (31)
Echtzeitpriorität
…
geringste (16)
höchste (15)
…
variable Priorität
geringste (0)
149
• Richtige Echtzeitfähigkeiten nicht vorhanden,
sondern nur höhere Prioritäten.
• Prioritätsklasse berechnet sich aus der Prozeßklasse und dem relativen Thread-Prioritätslevel (von –2 bis +2).
• Anpassung von Prioritäten durch Scheduler:
- Priorität wird um 1 erniedrigt, falls Zeitscheibe
komplett verbraucht.
- Wenn E/A-Auftrag beendet ist, auf den ein
Thread gewartet hat, so wird dessen Priorität
erhöht (1-8 Level) = Priority Boost.
- Nach einem Priority-Boost, wird nach jedem
Ablauf einer Zeitscheibe, die Priorität wieder
um 1 erniedrigt, bis zum Ausgangswert.
• Prioritätserhöhung, wenn der Thread lange
(~ 3 sec.) in der Bereitliste war:
- vermeidet Verhungern.
- und Prioritätsinversion.
• Zeitscheibe kann für Vordergrundprozesse
Systemsteuerung):
angepaßt werden (
doppelt oder dreifach lange Zeitscheiben.
• CPU-lastige Threads neigen zu niedrigeren
Prioritäten und I/O-lastige zu höheren.
• Prioritätsklasse über Taskmanager anpaßbar.
en
150
7. Synchronisierung
7.1
Lese/Schreibkonflikt
• = race condition: wenn nebenläufige Threads
auf gemeinsamen Variablen schreiben, so ist
das Ergebnis nicht deterministisch:
Thread-2
Thread-1
1
2
2
t
• Synchronisierung der nebenläufigen Threads
macht das Resultat deterministisch:
Thread-2
Thread-1
wait()
2
signal()
1
t
1
• Bemerkung:
- Nebenläufigkeit führt zu einer implizitzen oder
expliziten gegenseitigen Beeinflußung.
- Synchronisierung notwendig.
151
7.2
Serialisierung mit Signal/Wait:
• Oft muß ein Thread warten, bis ein anderer
Thread einen vorgesehenen Punkt erreicht:
-
warten auf richtige Drehzahl der Platte,
warten auf vorherige DB-Transaktion,
Berechnung im Koprozessor,
nachstehendes Beispiel "Warten auf Puffer",
warten bis der Partner einen kritischen Bereich
verlassen hat …
• Wartefunktion wait(event) suspendiert den
aktuellen Thread solange bis das Ereignis
event gemeldet wird.
• Die Funktion signal(event) meldet das
Ereignis event. Der signalisierende Thread
läuft ungehindert weiter.
• Ein signal-Aufruf lässt maximal einen
wartenden Thread weiterlaufen. Wartet
keiner, so geht der Aufruf verloren.
• Mit jeder Ereignisvariablen ist auch eine
Queue für wartende Thread verknüpft.
• Eventuell gleichzeitig
Ereignisse warten:
auf
verschiedene
- WaitForMultipleObjects( …, &Handles, …).
152
7.3
Kritische Abschnitte
• = Critical Regions: Programmabschnitte, die
auf gemeinsame Variablen zugreifen und deshalb einer Synchronisierung bedürfen.
• Unterschiedliche Programmabschnitte können
dieselben Variablen nutzen.
=> Nicht der Programmabschnitt sondern das
Variablenobjekt wird geschützt.
• Ziel: wechselseitiger Ausschluss (mutual
exclusion) = max. 1 Thread in krit. Abschnitt.
• Fehlerhafte Lösung:
while (busyFlag) {}; ->
busyFlag=true;
count++;
busyFlag=false;
<- while (busyFlag) {};
busyFlag=true;
count++;
busyFlag=false;
- Dies ist keine Lösung, weil "Testen & Setzen"
des Flags hier wieder nicht atomar geschieht.
• Bem.: Threadprioritäten u. U. verletzt.
• Das Schlüsselwort "synchronized" definiert in
Java einen Kritischen Abschnitt:
- einzelne Anweisung oder Anweisungsgruppe,
- statische oder dynamische Methode,
- ganze Klasse.
153
7.3.1 Programm "Incrementer.java":
• Zwei Threads inkrementieren gemeinsame
Variablen:
- auf dem Umweg über eine Zwischenvariable,
- Variable "asyn" ohne Synchronisierung,
- Variable "sync" mit Synchronisierung:
public class Incrementer extends Thread{
static Incrementer lnx,rxz;
static long sync=0;
static long asyn=0;
long count=1000*10000;
public static void main(String[] s){
lnx = new Incrementer();
rxz = new Incrementer();
lnx.start(); rxz.start();
}
public void run(){
long zwisch;
// force non atomic
while (count-- > 0) {
zwisch=asyn+1; asyn=zwisch;
synchronized(lnx)
{ zwisch=sync+1; sync=zwisch;};
}
System.out.println("asyn: " + asyn);
System.out.println("sync: " + sync);
}}
• Synchronisierung ist in Java nur auf Objekte
möglich. Hier z.B. auf Objekt "lnx" - ersatz–
weise für die Variablen (asyn, sync).
154
• Ausgabe von Incrementer z.B.:
asyn: 18213815
sync: 18761335
asyn: 19452479
sync: 20000000
• Wenn eine Inkrementierung unterbrochen
wird und der andere Thread ebenfalls inkre–
mentiert geht eine Inkrementierung verloren.
“lost update problem”
• Ausnahmsweise und je nach Last und Laune
des Betriebssystems läuft das Programm auch
ohne Verlust:
asyn: 19843320
sync: 19843320
asyn: 20000000
sync: 20000000
155
7.4
Wechselseitiger Ausschluss
7.4.1 Peterson's Algorithmus
• Realisiert wechselseitigen Ausschluß nur abgestützt auf sequentiellen Speicherzugriff:
Program Peterson;
var latest: (first,secnd);
p1Tries, p2Tries: Boolean;
Process Process1;
begin
repeat p1Tries:= true;
latest:= first;
while p2Tries and latest=first do { loop} ;
KritischeRegion1;
p1Tries:= false;
OtherStuff1
until false;
end { Process1 };
Process Process2;
begin
repeat p2Tries:= true;
latest:= secnd;
while p1Tries and latest=secnd do { loop} ;
KritischeRegion2;
p2Tries:= false;
OtherStuff2
until false;
end { Process1 };
Begin p1Tries := false; p2Tries := false;
parbegin Process1; Process2 parend
end { Peterson }.
156
• Fall A:
p1 kommt zuerst und p2 kommt später. p2 muss
warten bis p1 die Warnungsvariable p1Tries
freigibt.
p1Tries
latest
p2Tries
• Fall B:
p2 kommt als einziger und muss nicht warten bis
p1 die Warnungsvariable p1Tries freigibt.
p1Tries=false
latest
p2Tries
• Bemerkung:
- auf mehrere Threads erweiterbar.
- benötigt keine HW-Unterstützung.
- SW-Erweiterungen ebenfalls unnötig.
157
7.4.2 Atomare Maschinenoperationen
• Viele CPUs haben Test&Set-Instruktionen:
- für atomare bzw. unteilbare Bustransaktion,
- lesen eines Speicherwortes,
- Speicherwort schreiben:
Speicher
Bus
Prozessoren & DMA
• Unteilbare Bustransaktion:
-
reservieren des Speicherbusses,
kein Zugriff durch andere CPUs,
Cache-Konsistenz gewährleisten,
keine Interrupts an der eigenen CPU,
kein Zugriff durch DMA oder Bus-Master.
• Assembler-Fragment (hypothetisch):
locked
wait:
WORD 0
; = nicht gesperrt
......
TestSet 1
; testen und setzen
JumpH wait ; loop while high
• Bei Uniprozessoren genügt es meist, Unter–
brechungen zu unterdrücken: Intel (CLI, STI).
158
7.4.3 Semaphor-Variablen
sem>0
sem=0
Warteschlange
• Wartende Threads zu Semaphor.
• Binäre Semaphore mit Werten 0 oder 1.
• Zählende Semaphore mit Werten 0 .. n.
• Semaphor-Operationen:
-
Initialisieren:
InitSem( semVar ),
Prüfen:
P( semVar ),
"Versenden":
V( semVar ),
Originalsprache Holländisch,
vorgeschlagen durch E. Djikstra.
• P(semVar) & V(semVar) sind etwa aequivalent zu Wait(ev) & Signal(ev). Allerdings
verpuffen unerwartete Signale hier nicht.
159
Beispiel: Synchronisierung mit Semaphor
• Semaphor-Variable dient hier dazu, die Anzahl Nutzer einer Ressource zu beschränken:
#define userLimit = 20;
HANDLE hSem;
void SomeUser() {
// =P();
WaitForSingleObject(hSem,INFINTE);
// kritischer Abschnitt
use_resource();
// =V(); semaphor,release-cnt., before-cnt.
ReleaseSemaphore(hSem,1,NULL);
END SomeUser;
int main() {
// security descr., start-cnt., max.-cnt., name
hSem=CreateSemaphore(NULL,0, userLimit,NULL);
…
}
160
Realisierung atomarer Semaphoroperationen
• Semantik für P(semVar):
if semVar > 0
then semVar:=semVar-1
else { warten auf V(semVar) }
• Semantik für V(semVar):
if { kein Prozess wartet auf semVar }
then semVar:=semVar+1
else { wartenden Prozess anstossen }
• P und V als atomare bzw. unteilbare Operationen realisieren, sonst entstehen NichtDeterminismen:
• Zur Realisierung von Semaphor-Variablen
verwendet man i. d. R. eine Interruptsperre
oder besondere Test&Set-Instruktionen.
• Für den Fall von scheinbarer Nebenläufigkeit
auf einem Uniprozessor genügt es die Priorität
der P & V-Routinen soweit zu erhöhen, daß
eine Unterbrechung nicht mehr möglich ist.
161
7.4.4 Monitore
• C. A. Hoare und P. B. Hansen, 1974.
• Sprachkonstrukt für Synchronisierung
serially reusable Module
• Die Monitor-Prozeduren garantieren:
- nur ein Thread jeweils im Monitor,
- kein externer Zugriff auf Monitorvariablen,
- auto. Freigabe des Monitors beim Rücksprung:
Shared Resource
MonitorModul
Proc
Proc
• Im Vergleich dazu sind Semaphore etc. lowlevel Sprachelemente:
- Risiko von Programmierfehlern,
- ohne P() kein gegenseitiger Ausschluß,
- ohne V() eventuell Verklemmung.
162
Incrementer-Monitor
• Beispiel in "Concurrent Pascal":
monitor Incrementer;
var zaehler: integer;
procedure PlusEins;
begin
zaehler:= zaehler+1
end { PlusEins };
{ P(IncSem) implizit }
{ V(IncSem) implizit }
procedure PlusZwei … end;
begin
zaehler := 0
end { Incrementer }.
• Die Laufzeitumgebung sorgt mit Unterstützung des Compilers dafür, daß sich nur ein
Thread im Monitor befindet.
• Realisiert eine geschützte kritische Region
oder auch mehrere verbundene.
• Passives Programmelement
Modula-2 Module:
ähnlich
wie
- Kapselung ("Information hiding"),
- Module-Initialisierung.
163
Erweiterung: Warten im Monitor
• Zusätzlich zum impliziten P & V auch noch
Signal & Wait in Monitoren drin erlaubt.
monitor PrintMon;
var printerBusy: Boolean;
printerFree: Condition;
procedure ReservePrinter;
begin
if printerBusy
then wait( printerFree);
printerBusy:= true
end { ReservePrinter};
procedure ReleasePrinter;
begin
printerBusy:= false;
signal( printerFree);
end { ReleasePrinter};
begin
printerBusy:= false
end { PrintMon}.
164
• Warten im Monitor würde zur Blockierung
führen. wait(<condition>) bewirkt deshalb
eine Verdrängung des Threads nach aussen.
• Aus didaktischen Gründen nicht einfach wait(
printerFree).
• Diskussion um verschachtelte Monitoraufrufe:
- bleiben eingekellerte Monitore blockiert?
- oder wird ein Monitor beim Aufruf des nächsten
freigegeben?
• Signal( thisCondition ) nur am Prozedurende:
- Aufruf aktiviert anderen Thread im Monitor
- und aktueller Thread verläßt Monitor.
wenn Awaited( thisCondition)
dann Resume(thisCondition)
sonst Release(thisMonitor);
165
7.4.5 Message Passing
• Eine Nachricht ist eine Verallgemeinerung
eines Signales.
• Sie enthält neben der Ereignis-Information
auch noch Daten.
• Empfänger wartet auf eine Nachricht:
receive() anstelle von wait().
• Sender sendet eine Nachricht:
send() anstelle von signal().
• Typisch besonders in Verteilten Systemen:
- RPC, Remote Procedure Call,
- RMI, Remote Method Invocation,
- Socket-gestützte Kommunikation ...
• Socketkommunikation mit den Urfunktionen
("Primitives"):
- Send( SocketID, Message),
- Receive( SocketID, Message),
- Blocking/Nonblocking Send…
• Alternativ: Kommunikation mit Hilfe eines
gemeinsamen Speicherbereichs (lokal oder
verteilt) bzw. gemeinsamer Variablen.
166
7.5
Klassische Problemstellungen
7.5.1 Erzeuger/Verbraucher-Problem
int
buffer[N];
// Puffer
int
in,out;
// Pufferzeiger
semaphore full=0, empty=N, mutex=1;
Erzeuger:
int item_w;
for (;;) {
produce(&item_w);
P(empty);
P(mutex);
buffer[in]=item_w;
in=(in+1)%N;
V(mutex);
V(full);
}
// noch Platz im Puffer?
// Eintritt in krit. Abschnitt
// ein weiterer Eintrag belegt
Verbraucher:
int item_r;
for (;;) {
P(full);
P(mutex);
item_r=buffer[out];
out=(out+1)%N;
V(mutex);
V(empty);
consume(item_r);
}
// Daten im Puffer?
// Eintritt in krit. Abschnitt
// ein Eintrag wird frei
167
• Schutz eines Puffers zwischen vielen
parallelen Konsumenten- und Produzententhreads.
• Bem.: Bei nur je einem Konsumenten und
Produzenten können die Event-Variablen
noch als Boolean realisiert werden.
7.5.2 Leser/Schreiber mit Semaphore
• N Leser oder 1 Schreiber parallel erlaubt.
int
readcount=0;
// Anzahl aktiver Leser
semaphore mutex=1, wrt=1;
Leser:
P(mutex);
readcount++;
if (readcount==1)
P(wrt);
V(mutex);
reading();
P(mutex);
readcount--;
if (readcount==0)
V(wrt);
V(mutex);
Schreiber:
P(wrt);
writing();
V(wrt);
// kein Leser aktiv?
// mit Schreiber sync.
// kein Leser mehr aktiv?
// Schreiber zulassen
// jeweils nur 1 Schreiber
168
7.5.3 Dining Philosophers
• N Philosophen sitzen um einen Tisch; sie
denken und wollen Spaghetti essen.
• Zum Essen benötigt jeder zwei Gabeln gleichzeitig.
• Lösungsansatz 1:
- Funktioniert, aber wenig Parallelität
Philosoph i:
think();
P(mutex);
take_fork(i);
take_fork((i+1)%5);
eat();
put_fork(i);
put_fork((i+1)%5);
V(mutex);
// linke Gabel nehmen
// rechte Gabel nehmen
// linke Gabel ablegen
// rechte Gabel ablegen
169
• Lösungsansatz 2:
- “state”: THINKING, HUNGRY, EATING.
- Essen nur mögl., wenn kein Nachbar gerade isst.
- N Semaphore S[]: blockieren hungriger
Philosophen, falls Gabeln in Gebrauch.
- LEFT=(i-1)%N; RIGHT=(i+1)%N;
Philosoph i:
think()
take_forks(i);
eat();
put_forks(i);
// beide Gabeln aufnehmen
// beide Gabeln ablegen
take_forks(i) {
P(mutex);
state[i]=HUNGRY;
test(i);
// Versuch beide Gabeln zu nehmen
V(mutex);
P(S[i]); // blockiere, falls Gabeln nicht frei waren
}
put_forks(i) {
P(mutex);
state[i]=THINKING;
test(LEFT);
// will linker Nachbar Gabel?
test(RIGHT);
// will rechter Nachbar Gabel?
V(mutex);
}
test(i) {
// beide Gabeln frei?
if (state[i]==HUNGRY && state[LEFT]!=EATING
&& state[RIGHT]!=EATING)
state[i]= EATING;
V(S[i]);
}
take_
170
7.6
Verklemmungen
• Verklemmung (engl. Deadlock): zwei oder
mehrere Threads sind blockiert, weil sie
Ressourcen besitzen, die von einem anderen
blockierten Thread benötigt würden.
• Verklemmungsgefährdete Ressourcen: Hauptspeicher, Drucker, Bandstationen, ...
Beispiel: System mit drei Bandstationen
• Drei Threads verlangen erst eine Bandstation
und später noch eine zweite.
• Günstiger Verlauf, die Threads terminieren:
T1
T2
T3
r1
r2
r3
wartet auf
Bandstation
171
• Ungünstig, kein Thread terminiert:
T1
T2
T3
r1
r2
r3
wartet auf
Bandstation
• Deadlock ist möglich, aber nicht zwingend.
7.6.1 Wartegraph
• Ein gerichteter Graph mit den Threads als
Knoten und Wartebeziehungen als Pfeile heißt
Wartegraph (engl. wait-for graph).
• Eine Verklemmung ist charakterisiert durch
einen Zyklus im Wartegraphen:
T3
wartet auf
T1
wartet auf
T2
wartet auf
T1
T2
wartet auf
direkter
Deadlock
indirekter
Deadlock
172
7.6.2 Notwendige Bedingungen
• Ist eine dieser Bedingungen verletzt, so ist
keine Verklemmung möglich:
1. wechselseitiger Ausschluss: Die betroffene
Ressource ist nicht gemeinsam benutzbar.
2. Halten und Warten: Wartender Thread besitzt
eine Ressource, während er auf weitere wartet.
3. Keine Verdrängung: Ressourcen können einem
Thread nicht entzogen werden.
4. Zirkuläre Wartesituation.
7.6.3 Gegenmaßnahmen
• Vorbeugen (prevention).
• Vermeiden (avoidance).
• Entdecken (detection).
• Auflösen (resolution).
• Bemerkung:
- die meisten Betriebssysteme ignorieren dieses
Problem (Unix & Windows NT).
- NT: Timeout bei „WaitForSingleObject“.
173
7.6.4 Verklemmungsvorbeugung
• Methoden um zu verhindern, dass eine der
vier Verklemmungsbedingungen zutrifft.
• Summenbelegung (preclaiming):
- sämtliche jemals benötigten Ressourcen werden
einmalig zu Beginn angefordert.
- unökonomisch & Bedarf schwer abschätzbar.
• Totalfreigabe bei jeder Belegung:
- auch hier wird eine Anforderung aus einem
„besitzlosen“ Zustand vorgenommen und somit
eine zirkuläre Wartesituation vermieden.
Thread
Belegen (r1, r2)
Freigeben (r1, r2)
Belegen (r3)
evt. zwangsweise
Freigeben (r3)
Belegen (r1, r2)
• Belegung gemäß vorgegebener Ordnung:
- Zyklen werden durch das Einhalten einer vorgegebenen Ordnung vermieden.
174
- Beispiel: Ressourcen seien geordnet (r1, r2, ...)
Thread-1
Thread-2
Belegen ( r1)
Belegen ( r2)
Belegen ( r3)
Belegen ( r3)
Belegen ( r4)
Belegen ( r5)
7.6.5 Verklemmungsvermeidung
• Für jede einzelne Ressourcenanforderung
wird entschieden, ob dadurch ein Deadlock
auftreten kann.
• Voraussetzung: Restanforderung aller Threads
muss bekannt sein.
• Im ungünstigsten Fall werden alle Restanforderungen gleichzeitig gestellt.
• Könnten diese zu einem Zeitpunkt alle erfüllt
werden, so heißt die aktuelle Situation sicher,
andernfalls unsicher.
175
Beispiel: Bankier Algorithmus (Dijkstra)
• Jeder Thread
nennt die maximale
Anzahl Bandstationen,
die er benötigt
(max[i]=Kreditrahmen).
Deadlock
unsicher
sicher
• Jeder Thread leiht sich
eine Anzahl Stationen aus (loan[i] " max[i]).
• Für Ressourcen mit mehrfachen Instanzen.
• Wie ein Bankier beurteilt das BS die Kreditwürdigkeit der einzelnen Threads (max) und
verteilt entsprechend die Ressourcen (loans).
Sicherer Zustand (12 Stationen):
Anleihe
Kredit
Thread A
1
4
Thread B
4
6
Thread C
5
8
Verfügbar
2
• Vergabe einer Station an B ist zulässig.
• Vergabe an A oder C ist unzulässig und führt
zu einem unsicheren Zustand.
176
Unsicherer Zustand (12 Stationen):
Anleihe
Kredit
Thread A
1
4
Thread B
4
6
Thread C
6
8
Verfügbar
1
• Für keinen der beteiligten Threads kann die
Terminierung garantiert werden.
• Hoffentlich gibt bald einer der Threads wieder
eine Einheit zurück.
Beurteilung:
• Verhinderung von Verklemmungen
Bedingungen 1 bis 4.
trotz
• Feste Anzahl von Benutzern und verfügbaren
Ressourcen (Defekte nicht einkalkuliert).
• Allozierung und garantierte Rückzahlung in
endlicher Zeit genügt nicht für EchtzeitSysteme.
• Vor.: Threads voneinander unabhängig.
• Bedarf muß zu Beginn der Verarbeitung angemeldet werden.
177
7.6.6 Verklemmungsentdeckung
• Sind die Restanforderung nicht bekannt, so
kann keine Vermeidung durchgeführt werden.
• Bei Entdeckungsstrategien erlauben das Auftreten von Deadlocks.
• Der Bankier-Algorithmus kann auch hier eingesetzt werden, wenn die Restanforderungen
durch die akt. Anforderungen ersetzt werden.
• Es müssen alle Threads einbezogen werden.
• Aufruf: bei jeder Belegung, periodisch, im
Leerlauf, bei Verdacht, ...
7.6.7 Verklemmungsauflösung
• Durchbrechen einer zirkulären Wartesituation.
• Falls ein Entzug von Ressourcen nicht
möglich ist, so muss mindestens ein Prozeß /
Thread abgebrochen werden.
178
7.7
Interprozesskommunikation
7.7.1 Klassifikation
• Synchron/asynchron:
- synchron: Sender wird bis zur Auslieferung der
Nachricht blockiert.
- asynchron: Sender arbeitet sofort weiter.
• Gepuffert/ungepuffert:
- gepuffert: u.U. mehrere Nachrichten bündeln.
- ungepuffert: direktes Empfangen/Übetragen.
• Verbindungsorientiert/verbindungslos:
- verbindungsorientiert: expliziter Verbindungsaufbau vor der Kommunikation notwendig.
- verbindungslos: Zieladresse in jeder Nachricht;
Multicast und Broadcast mögl.
• Meldungs-/autragsorientiert:
- Meldung: Sender wird bis zur Bestätigung der
Meldung blockiert.
- Auftrag: Sender wird bis zur Beendigung des
Auftrages blockiert.
• Kommunikationsarten:
- nachrichtenbasiert: Socket, RPC, RMI, Corba, ...
- speicherbasiert: (Distributed) Shared Memory.
179
7.7.2 Beispiel: Linux
• Interprozesskommunikation (IPC) in UnixSystemen umfasst:
-
Warten auf externe Signale
Steuerung nebenläufiger Prozesse,
Übergeben von Daten und Nachrichten,
Synchronisierung des Ressourcenzugriffs.
• Dazu wird eine Vielfalt von Mechanismen
unterstützt:
Resource
Sharing
SynchroniSierung
Verbindungslose
Nachrichten
Verbindungs
orientierte
Nachrichten
im Kern
Datenstrukturen, Puffer
Semaphore,
CLI/STI
Queues
Signale
zwischen Prozessen
im Netz
Shared Memory
Dateien
Semaphore,
File Locking,
(NFS Files)
Lock Datei
Unix-Domain Datagr.,
Signale,
UDP
Queues
Sockets
(Named) Pipes,
Unix-Domain Streams TCP Sockets
• Zusätzlich System V IPC: Message Queues,
erweiterte Semaphore und Shared Memory.
• Der Linux Kern läuft in einem Adressraum
und im kooperativen Multitasking Modus.
Damit vereinfachen sich die IPC-Verfahren.
180
Kommunikation über Signale
• Signale sind kurze wichtige Meldungen.
• 32 vordefinierte Systemsignale:
- SIGTERM: Terminierungsaufforderung,
- SIGKILL: ultimative Terminierung,
- SIGUSR1: für Anwendungen, ...
• Signalverarbeitung durch Handler:
- Default-Handler im Kern.
- für Anwendungen optional:
#include <stdio.h>
#include <signal.h>
// Signal auslösen mit: kill –SIGUSR1 pid
void myHandler(int parm) {
printf(“received SIGUSR1\n”);
}
int main() {
struct sigaction action,old;
action.sa.flags=0;
sigemptyset(&action.sa_mask);
action.sa_handler=myHandler;
// Signaltyp, neuer Handler, alter Handler
sigaction(SIGUSR1, &action, &old);
sleep(60);
sigaction(SIGUSR1, &old, NULL);
}
181
Kommunikation über Dateien
• Konkurrierende Schreibzugriffe auf Dateien
werden durch Open/Close-Routinen geregelt.
• Eventuell nur im Read-Only Mode öffnen.
• Wird die Datei im Multiple Writer Modus
geöffnet, so riskiert man Inkonsistenzen.
• Sperren ganzer Dateien:
- per Lock Datei.
- Oder mit Aufruf flock().
• Sperrung von Dateibereichen:
int sys_fcntl( unsigned int fileDeskriptor,
unsigned int command, /* F_GETLK, ... */
struct flock * fileLock ) ;
• Datenstruktur im Betriebssystem:
FileLock
FileLock
FileLock
FileDeskriptor
• struct flock:
- Lesesperre, Schreibsperre, Dateibereich, PID.
182
Kommunikation über Pipes
• Klassische IPC Methode unter Unix.
• Für Kommunikation zw. verwandten Proz.
• Implizite Erzeugung einer anonymen Pipe
mit der Befehlszeile:
% ls -l | more
• Nutzung einer benannten Pipe (named pipe)
mit Befehlszeilen:
% mkfifo nmPip
% ls -l >nmPip & more <nmPip
• Lesen und Schreiben auf eine benannte Pipe
wie auf eine Datei (halbduplex).
• Zusätzlich jedoch mehrfache Leser und
Schreiber möglich:
named pipe
writers
readers
183
• Beispiel: Unix-Pipe zwischen Vater und Sohn
#include <stdio.h>
#include <unistd.h>
int main() {
char
int
in
data[80];
rb;
// nr of read bytes
pipe_ends[2]; // handles: read=0; write=1
pipe(pipe_ends);
if (fork()==0) {
// child process
close(pipe_ends[1]); // code write port
rb=read(pipe_ends[0], data,80);
data[rb]=’\0’;
// terminate string
printf ("%s\n",data);
close(pipe_ends[0]); // close read port
}
else {
// father process
close(pipe_ends[0]); // close read port
write(pipe_ends[1],"hello",5);
close(pipe_ends[1]); // close write port
}
}
184
7.7.3 Beispiel: Windows NT
• Vielfältige Mechanismen:
-
Mutex, Events, Semaphore,
Named Pipes, Mailslots,
Shared Memory,
LPC & RPC.
Local Procedure Call
• Prozeduraufruf über Adressraumgrenzen hinweg, abgebildet auf Nachrichtenübertragung.
• LPC Varianten:
a) Nachricht an Port-Objekt im Server,
b) Zeiger auf gemeinsamen Speicher senden,
c) "Quick LPC".
• Nachrichtentransport zum Port-Objekt im
Server-Subsystem (Fall a,b):
OpenConnection
Connection
Port
connected
Server
Subsystem
Klient
service reply
service request
185
Quick LPC:
• Komponenten, jeweils pro Klient:
- 64 KB gemeinsamer Speicher,
- eigener Server-Thread,
- ein Event-Paar.
• Vermeidet Communication-Ports mit Queues.
• Nachrichten und Daten in Shared-Memory.
• Executive signalisiert die Events.
• Bewertung:
- schnelle Signalisierung,
- Speicheroverhead für die Threads.
Klient
Server
Subsystem
186
8. Ein-/Ausgabe
8.1
Peripherie
PC Busstrukturen:
CPU
AGP
Host-PCI
Brücke
Speicher
PCI
USB
IDE
UDMA
PCI-ISA
ISA
- Host-PCI Brücke (auch Nordbrücke) als DatenDrehscheibe zw.: Frontside-, PCI-, AGP-Bus.
- PCI: 32/64 Bit; Bandbreite: 132 - 512 Mbyte/s.
- PCI-ISA Brücke (auch Südbrücke) zur
Anbindung von USB-, IDE-, ISA-Bus.
- ISA: 8/16 Bit; Bandbreite: 8 - 16 Mbyte/s.
187
Datenübertragung:
• Programmed I/O:
- CPU überträgt wortweise Daten aus dem
Hauptspeicher in Datenregister des Gerätes.
- wird in der Regel nicht verwendet, da teuer.
• Direkter Speicherzugriff:
- DMA für ISA-Geräte
- Busmaster für PCI-Geräte.
- CPU initiert nur den Transfer.
CPU
RAM
Gerät
Steuerung:
• CPU startet einen E/A-Auftrag.
• Nach Beenden eines E/As muss der Prozessor
informiert werden:
- Polling: CPU kann Statusregister des Geräts
gelegentlich prüfen, was aber ineffizient ist.
- Interrupt: Am Ende des E/As löst das Gerät
eine Unterbrechung aus (üblicher Ansatz).
188
8.2
Unterbrechungen
• Ein Programm wird unterbrochen zugunsten
einer Aufgabe mit höherer Priorität:
• Der Zustand des unterbrochenen Programmes
wird aufgezeichnet und nach Abschluß der
Unterbrechung wiederhergestellt.
• Mit der Ausführung des unterbrochenen
Programmes wird später unmittelbar nach der
Unterbrechungstelle fortgefahren:
Anwenderprogramm
Unterbrechungsroutine
Device
Ret.-Adr.
Flags
Stack
189
• Lesen & Schreiben aus externen Gerätepuffern:
-
Tastatur, Serielle Datenleitung,
Festplattenkontroller,
Netzwerkkarte,
Strahlrücklauf ...
• Behandlung von internen Fehlersituationen:
-
allgemeine Speicherschutzverletzung,
ungültige Maschineninstruktion,
Paritätsfehler im Hauptspeicher,
arithmetische Fehlersituation,
ausgelagerte Speicherseite,
Debugging ...
• Explizite Anforderung von DOS-Diensten:
- Assemblerinstruktion INT <intcode>,
- DOS-Dienste über INT 21h.
• BIOS-Dienste anfordern:
-
INT
INT
INT
INT
INT
INT
INT
INT
10h
11h
12h
13h
14h
16h
17h
1Ah
Videokarte
Konfiguration feststellen
RAM-Speichergrösse feststellen
Disketten & Festplatten steuern
Serielle Schnittstelle steuern
Tastatur steuern
Parallelschnittstelle
Uhrzeit, PCI & PCMCIA(PC)
190
8.2.1 Maskieren von Interrupts
• Aufruf von Interrupts möglichst nicht rekursiv
zulassen, da schwer handhabbar.
• Zu Beginn einer Interrupt-Sequenz sind die
Interrupts automatisch ausgeschlossen.
• Anschliessend wird der Interrupt bestätigt und
nachfolgende Interrupts kommen durch:
- IRET oder POPF beim Rücksprung der Routine,
- EOI-Befehl an den Interrupt-Kontroller.
• Interrupts im Prozessor expizit maskieren:
- CLI löscht Interrupt-Enable Bit im Statusreg.,
- STI setzt das Bit wieder.
• Möglichkeiten der Interruptmaskierung:
- Enable-Bit im CPU-Statusregister,
- Mask-Register im 8259A-Kontroller,
- auch NMI kann maskiert werden (Port $70).
191
8.2.2 Interrupttabelle
• Externe und interne Unterbrechungen wählen
jeweils einen aus 256 Tabelleneinträgen aus:
NMI
255
Slave
INTR
INTA
Vektor#
Master
CPU
Interrupt
Entry
IRQ-Pin#
8259A
Programmierter
Offset
IRQ 0,1,3-15
0 IDTR
• Index in die Tabelle:
- für interne U. durch CPU-Hardware,
- für externe U. durch Interrupt-Kontroller,
- Ausnahme: NMI direkt auf Eintrag #2.
• Startadresse der Interrupttabelle:
- Real-Mode:
ab Speicherstelle 0,
- Protected M.: via IDTR-Register.
• Maximal 256 Einträge:
- Real-Mode: jeweils 4 Byte als Segment:Offset,
- Protected: 8 Byte Interrupt-Deskriporen.
192
8.2.3 Externe Unterbrechungen
• Externe Interrupts von der Hauptplatine:
- IRQ-0: Timer-Interrupt,
- IRQ-1: Tastatur-Interrupt,
- IRQ-2: sekundärer Interrupt-Kontroller (wird
nicht ausgelöst)
- IRQ-8: Echtzeit-Uhr (RTC),
- IRQ-13: Koprozessor.
• Externe Interupts vom ISA-Bus:
- IRQ-[3 .. 7, 9 .. 12, 14,15],
- IRQ-[3, 4, 5] für COM1, COM2, LPT1 evtl. im
CMOS-Setup anders zuordnen,
- für Disks, Netzwerkadapter, Soundkarten, SCSIKontroller, Videokarten, Steuerungen, ...
• Interrupts vom PCI-Bus werden durch die
PCI-Bridge auf ISA-Interrupts abgebildet.
• PCI erlaubt "Shared Interrupts".
193
8.2.4 Verketten mit Interrupt-Routine
• Eine neuer Interrupt-Handler wird eingetragen
und ruft am Ende die bisherige Routine auf.
• Interrupt-Return (IRET):
- Flags vom Stack herunterholen,
- und ins Flag-Register laden,
- Rücksprungadresse holen.
• Die bisherige Routine erwartet ein Flagwort
auf dem Stack:
- Assemblereinschub "asm pushf end" lädt dieses.
• Das Schlüsselwort "Interrupt" sorgt für ein
"IRET" am Ende der eigenen Prozedur.
Interrupttabelle
Flags
:
Flags
neue Int.routine
IRET
alte Int.routine
IRET
194
Programmbeispiel "TimerChain.pas"
• Zählt die Systemuhr mit.
• Prozedurvariable für alten Handler.
• Ausgabe: ca. 1 Punkt pro Sekunde:
......... Done
(*$F+ Force far jumps *)
program TimerChain;
uses Crt, Dos;
var oldHandler : procedure;
ticks
: integer;
procedure MyHandler; Interrupt;
begin ticks := ticks + 1;
if ( ticks mod 18 )=0 then write( ' .' );
asm pushf end; (* simulate flags on stack *)
oldHandler; (* chain to old Handler *)
end;
begin ticks:=0;
GetIntVec( 8 , addr(oldHandler) );
SetIntVec( 8 , addr(MyHandler) );
repeat until ticks=182;
SetIntVec( 8 , addr(oldHandler) );
writeln( 'Done' );
end.
195
8.2.5 Timer-Interrupt
• Alte Int.Routine aufbewahren & ersetzen.
• Prozeduradressen übergeben.
• Interrupt-Kontroller explizit mit EOI auf
Port[$20] zurücksetzen.
(*$F+ Force far jumps *)
program MilliTimer; (* provides a Millisecond timer *)
uses Crt, Dos;
const milliSec = 4772720 div 4000;
var
oldHandler : procedure;
ticks
: real;
procedure SetTimer( Handler: pointer; period: integer);
begin Port[$43] := $34; (* select timer 0, function 2 *)
Port[$40] := period mod 256; (* Low byte *)
Port[$40] := period div 256; (* High byte *)
SetIntVec( 8 , Handler);
end;
procedure MyHandler; Interrupt;
begin ticks := ticks + 1;
port[$20] := $20; (* EOI to 8259 *)
end;
begin ticks:=0;
GetIntVec( 8 , addr( oldHandler ) );
SetTimer( addr( myHandler ), milliSec );
repeat until keypressed;
SetTimer( addr( oldHandler), 0 (* is Maximum*) );
writeln( ticks/1000:8:3, ' sec' );
end.
196
8.3
E/A-Software
Ziele:
• Komplexität und Heterogenität der Geräte
verbergen.
• Geräteunabhängigkeit:
- E/A-Schnittstelle soll unabhängig vom Gerät
implementiert werden können.
- einheitl., geräteunabhängige Namensstrukturen.
• Virtualisierung von Geräten.
• Fehlerbehandlung.
• Pufferung von Daten.
• Zugriffskontrolle.
E/A-Software Struktur:
Anwendungen
User-Level E/A-Software
E/A-Subsystem
Gerätetreiber
Hardware
197
8.3.1 User-Level E/A-Software
• Bereitstellung von Bibliotheksfunktionen:
- open, read, write, close, ...
- printf, ioctl, ...
• Systemaufruf zur Ausführung eines Betriebssystemdienstes
Bilden der notwendigen
Parameterstruktur.
• Spooling: (z.B. Drucker)
- Unterstützung paralleler E/A auf Geräte, die
nicht gleichzeitig mehrfach nutzbar sind.
- Alle Aufträge werden in Spooling-Verzeichnis
abgelegt.
- Spezieller Daemon-Prozess selektiert Aufträge
und führt E/A auf Gerät durch.
8.3.2 E/A-Subsystem im Kern
• Bereitstellen einheitl. Geräteschnittstellen für
Gerätetreiber:
- Standard-Interfaces für Geräte-Kategorien:
z.B. Block- und zeichenorientierte Geräte.
- Verwaltung der Namen von Dateien & Geräten.
• Scheduling von E/A-Aufträgen (z.B. HDD).
• Zugriffskontrolle.
198
• Konfiguration/Initialisierung der Geräte.
• Zuordnen & Freigeben von Geräten.
• Puffern:
- Eingaben: verzögert an Anwendung Puffern.
- Ausgaben: unterschiedliche Geschwindigkeit
von Erzeuger & Verbraucher Daten kopieren.
• Fehlerbehandlung und –berichte.
8.3.3 Gerätezugriff
Gerätezugriff in Unix
• Gerät:
-
Abstraktion=Datei (im Verzeichnis „/dev“)
spezieller I-Node,
werden wie Dateien angesprochen,
nicht direkt zugreifbar für Standard-Benutzer.
• Blockorientierte Geräte
- Speicherung der Informationen in BlockEinheiten, z.B. 1024 Bytes.
- Beispiel: Festplatten.
- Kommandos: read, write.
• Zeichenorientierte Geräte
- Erzeugen bzw. Akzeptieren von Zeichenströmen
- Beispiel: Tastatur
- Kommandos: get, put.
199
Gerätezugriff in Windows NT
• Gerät:
- Abstraktion=Objekt,
- tauchen nicht im Dateisystem auf.
- nicht direkt zugreifbar für Standard-Benutzer.
• Kommandos: Öffnen, Lesen, Schreiben und
Schließen, wie bei Dateien.
• Aber verschiedene Geräteklassen (z.B. Netzwerk, Modem, Grafik, Drucker) mit jeweils
spezifischen Laufzeitfunktionen.
• Komplizierte Treiberarchitektur (~ 1.000 Fkt.
im Kern für Treiber-Entwickler vorhanden).
8.3.4 Pufferung
Eingangspufferung
• Ungepuffert: Problem häufige Prozeßwechsel
teuer (z.B. pro Tastendruck)
• Puffern im Anwendungsadressraum:
- Vorteil: kein Umkopieren
- Nachteil: Speicherseiten der anfragenden Anwendung müssen zugreifbar sein.
vielleicht ist gerade ein anderer Prozeß aktiv.
200
• Doppeltes Puffern: Daten müssen umkopiert
werden, aber sonst keine Probleme.
User
Kern
ungepuffert
doppeltes
Puffern
Ausgangspufferung
• Benutzer übergibt mit write Daten an Kern.
• Kern übernimmt die Daten in seinen Puffer.
• Der Prozeß kann seinen eigenen Puffer sofort
weiterverwenden.
• Problem: Leistung.
• Beispiel: Datenübertragung über Netzwerk:
Computer-1
Computer-2
User
Kern
Netzwerkkarte
201
8.3.5 Gerätetreiber
• Treiber laufen in der Regel im BS-Kern:
-
greifen direkt auf HW zu.
haben höchste Privilegstufe.
Fehler führt zum Systemabsturz.
benötigen klar definierte Schnittstellen.
• Aufgaben eines Gerätetreibers:
-
Prüfen und Übersetzen der Parameter,
Statusüberprüfung, Starten d. Geräts,
Absetzen einer Befehlssequenz,
Fehlerbehandlung.
• API: Funktionen zum Öffnen, Schreiben,
Lesen, Schliessen, ...:
- verbirgt gerätespezifische Details,
- exportiert beim Laden des Treibers,
- Schnittstelle durch E/A-Subsystem definiert.
• Gerätekontrollblock: zum Speichern von
Zustandsinformationen pro Gerät.
• Gerätetreiber
(abstrakt):
GeräteKontrollBlock
API
Gerätetreiber
inkl. InterruptBehandlung
202
Windows NT Treiber
• Windows Driver Model (WDM):
-
Treiber werden dynamisch geladen,
PnP- und Power-Management,
geschichtetes Treibermodell,
Dateien mit Endung „.sys“,
in „\system32\drivers“.
Einstieg „DriverEntry“.
• I/O-Manager (Kernmodul) kommuniziert mit
Treibern nur asynchron über sogenannte I/O
Request Packets (IRPs).
• IRP ist variable große Datenstruktur für die
Unterstützung eines Treiber-Schichtenmodells
• Vordefinierte Funktionscodes: Create, Close,
Read, Write, ...
Stackeintrag
IRP_MJ_WRITE
Length
ByteOffset
Header
IoStatus
* SysBuffer
*Mdl
* UserBuffer
Cancel
IRP
Header
..
.
Stack
203
• Treiber kann beim Abschluss eines IRPs die
Priorität des wartenden Threads erhöhen.
• Treiber kommunizieren untereinander ebenfalls asynchron:
Driver -2
Driver -1
I/O-Manager
Driver -0
Gerät
• Aber auch direkte Aufrufe zwischen Treibern
möglich:
- nicht empfohlen.
- Funktionen exportieren (wie bei DLLs).
- Importieren eines anderen Treibers bedeutet, daß
dieser auto. mitgeladen wird.
204
WDM-Treiberstapel:
• FDO behandelt typischerweise I/O IRPs.
• PnP & Power-IRPs traversieren ganzen Stack.
• PDO wird durch den Bus-Treiber erzeugt.
• FDO's und Filter werden in "AddDevice" erzeugt (Parameter ist PDO).
IRP
IRP
Upper
Upper Class
Class Filters
Filters
Upper
Upper Device
Device Filters
Filters
FDO
FDO
Functional
Functional Device
Device Object
Object
Lower
Lower Class
Class Filters
Filters
Lower
Lower Device
Device Filters
Filters
PDO
PDO
Physical
Physical Device
Device Object
Object
DevNode
• Mehr Infos in Systemprogrammierung II.
205
Linux Treiber
• Treiber:
- statisch mit Kern gebunden
- oder dynamisch ladbares Modul.
• Modul:
- muss zwei Funktionen exportieren:
int init_module(void);
void cleanup_module(void) ;
- Treiber registriert sich mit register_chrdev.
- hierbei Fkt. in definierter Struktur exportieren.
• Zuordnung über Spezialdateien in /dev:
- Major-Number: identifiziert Treiber.
- Minor-Number (0-255): Geräte-ID.
Typ+Rechte
Maj.,Min.
brw-rw---- 1 root disk 3,0
brw-rw---- 1 root disk 3,1
crw-rw-rw- 1 root tty 2,176
Name
Aug 31 01:31 hda
Aug 31 01:31 hda1
Aug 31 01:31 ptya0
• Kein Schichtenmodell wie in Windows NT.
• Nebenläufigkeit:
- verschiedener Warteschlangen im Kern,
- entspricht Koroutinen,
- kein Threads.
• Rubini, Alessandro: Linux Device Drivers,
O’Reilly, 2nd Edition, 2001.
206
8.3.6 E/A- Aufrufe
• Synchroner Aufruf (blockierend):
- Aufruf kehrt erst zurück, wenn E/A fertig.
- Anwendung wird verdrängt und am Ende des
Systemaufrufs wieder aktiviert.
- Blockierende E/A ist für Entwickler einfacher
Realisierung durch separaten Thread.
• Asynchroner Aufruf (nicht-blockierend):
- kehren sofort zum Aufrufer zurück.
- Programm selbst kann E/A-Wartezeiten
berücksichtigen
- Ergebnis als Nachricht oder Callback-Aufruf.
Aufrufer
Callback
Request-Queue
Element
I/O-Task
Async.
Aufruf
BS
CompletionCode
207
Beispiel: Windows NT
• Beispiel: asynchrones Schreiben in eine Datei
dwErrorCode,
void CALLBACK Compl( DWORD
DWORD
dwWritten,
OVERLAPPED *pOverlapped.
);
int main() {
HANDLE
OVERLAPPED
char
hFile;
ov;
*data=“hello world“;
hFile = CreateFile(
"a:\\test.txt",
GENERIC_WRITE,
// write access
0, NULL,
// share mode & security
CREATE_ALWAYS,
// creation mode
FILE_ATTRIBUTE_NORMAL|
FILE_FLAG_OVERLAPPED,
NULL
// template file
);
ov.Offset
= 0;
ov.OffsetHigh = 0;
// file-pos
WriteFileEx(hFile, &data, strlen(data), &ov, &Compl);
CloseHandle(hFile);
}
208
9. Namensdienste
9.1
Namen & Adressen
9.1.1 Begriffliches
• people prefer names, machines use addresses
• Namen in Betriebssystemen:
-
WWW, E-Mail, ...
Rechner, Benutzer, ...
Dateien, Verzeichnisse, ...
Geräte, Dienste, Fenster, ...
Packages, Klassen, Methoden,Variablen, ....
• Gründe für Benennung:
- Erklärung,
- Lokalisierung,
- Identifizierung.
• Namenskonvention: Regeln für den Aufbau
von gültigen Namen:
-
UNC: \\fix\public
URL: http://cool.uni-ulm.de/zeux
Java: class Test1 aber class 1Test
Dateien: FAT16 Dateinamen mit 8+3 Zeichen
• Namensraum: Menge aller gültigen Namen,
die eine Namenskonvention erfüllen.
209
• Binden: Beziehung zw. Namen und Adresse
• Strukturierung von Namen:
- Flach: unstrukturiert, beliebige Zeichenfolge.
- Hierarchisch: syntaktisch strukturiert.
• Flache Namen:
- Eindeutigkeit schwer prüfbar
- Bsp.: „Schulthess“, „Schoettner“, „Wende“
• Hierarchische Namen:
- „www.uni-ulm.de“
- „c:\winnt\system32\drivers“
• Namensdienst: Datenbasis, welche die Zuordnung von Namen zu Adressen speichert.
• Namensauflösung:
- Dynamisch zur Laufzeit,
- Statisch zur Übersetzungszeit,
- Rückwärtsrichtung: z.B. Debugger.
210
9.1.2 Lokale Namensdienste
• Benutzerverwaltung:
- Flacher Namensraum,
- Benutzer- und Gruppennamen.
• Dateisysteme:
- Flache Dateinamen,
- Hierarchische Pfadnamen,
- Unix: eine Wurzel „\“, Microsoft: „A:“, „C:“, ...
211
• Software-Komponenten:
- JVM: Java Packages, Klassen,
- BS: DLLs, Shared Libraries, ...
- COM-Laufzeitbibliothek: COM-Objekte.
• GUI-Elemente und Betriebsmittel:
- Flache Namen,
- Betriebsmittel: Prozesse, Semaphore, ...
- GUI-Elemente: Fenster, Controls, Ressourcen.
• Compiler:
- Buchführung in Symboltabellen,
- Sichtbarkeitsregeln für Namen (Scopes),
- Namenskonventionen abhängig von Sprache.
• Lader: Zuordnung Klasse & Deskriptor, ...
• Konfigurationsverwaltung:
- Flache Namen,
- Benutzerkonfiguration: z.B. Desktop,
- Maschinenspez. Einstellungen (z.B. IP-Adresse)
212
9.1.3 Verteilte Namensdienste
• Ziele:
-
Effizienz,
Datenschutz,
Selbstkonfigurierung,
Verfügbarkeit & Skalierbarkeit.
• Verzeichnisdienste (z.B. X.500, NDS, ADSI):
- ähnliche Funktionalität wie ein Telefonbuch,
- Durchsuchen mit partiellen Informationen mögl.
- bieten hohe Flexiblität, aber oft eingeschränkte
Skalierbarkeit.
• Verteilte Dateisysteme (z.B. NFS, Coda):
- Logische Zusammenfassung lokaler Dateiverzeichnisse verschied. Rechner eines Netzes.
- Mount-Tabellen erforderlich mit u.U.
aufwendiger Administrierung.
- Konsistenzprobleme bei Replikation
• Globale Namensverwaltungen (z.B. DNS):
-
Delegation v. Zuständigkeiten f. Unterbereiche.
Hierarchische Organisation des Namensraumes.
Ausfallsicherheit durch Replikation.
Rekonfiguration ist aufwendig.
Effizienz durch Vorhalten.
213
9.2
Beispiel: JavaOS
Root
Temp
Gerät
Interface
Alias
nicht-persistent
Software
Config
persistent
• Java System Database (JSD):
-
Hierarchischer Namensraum,
Sammlung von benannten Objekten,
Nachfolger sind horizontal verknüpft,
Objekt durch Pfadnamen eindeutig bestimmt.
• Format eines Eintrages:
Name(String)
Status (Drafted, Published, ...)
Parent Entry Link
Sibling Entry Links
Child Entry Link
Lock
Manager
Generation Number
+
Entry-Specific Properties
214
9.3
• Objekt-Manager mit zentralem Namensdienst:
- Funktionen in NTOSKRNL.EXE,
- Objekte werden nur zum Auffinden über den
Namen identifiziert, danach über ein Handle,
- Nicht alle Objekte sind im User-Mode sichtbar.
• Format eines Eintrages:
Name(String)
Directory
Security
Open
Handle
Descriptor
Permanent/Temporary
Counter
Kernel/User
Type
mode Pointer
...
Object
Header
Type
Object
Object Body
• Namen von Laufwerken (A:) sind intern durch
Aliase realisiert:
\
Device
DosDevices
...
Floppy0
A:
\Device\Floppy0
...
...
215
9.4
Konfigurationsverwaltung
9.4.1 Einführung
• Konfigurieren ist keine triviale Aufgabe:
- Viele Ebenen: Hardware, System, Benutzer,
- Viele Werkzeuge: BIOS-Setup, BS-Tools, ...
• Hardware:
- ISA: Interrupt-Nummer durch Jumper,
- PnP: dynamisches Aushandeln von Ressourcen.
• Plug and Play:
-
max. 31 Geräte pro PCI-Bus,
max. 255 PCI Busse (hierarchisch),
256 Byte Konfigurationsadressraum,
BIOS handelt Interrupts & Speicher aus.
• BIOS-Setup:
- Festplatten (logische Geometrie),
- Chipset Einstellungen (Timing für Speicher).
• BS-Konfiguration:
- Treiber: Parameter, Ladezeitpunkt, ...
- Protokolle: Bindungen, IP-Adresse, ...
- Benutzerkonten: Rechte, Gültigkeitsdauer, ...
• Benutzereinstellungen:
- Desktop (Ordner, Erscheinung, ...),
- Anwendungsspez.: E-Mail-Adresse, ...
216
9.4.2 Beispiel: JavaOS
• Informationen über Maschinen und Benutzer
auf einem zentralen Server gespeichert.
• Bootphase nutzt nur Teilbaum „Machine“
• Durch das Anmelden eines Benutzers werden
Teile aus „User“ eingeblendet.
Config
User
Users
Machine
Groups
Platforms
Identifiers
Profiles
• Werkzeug: JavaOS Configuarion Tool (JCT).
• JCT erzeugt ein Master Client File (MCF).
217
9.4.3 Beispiel: Windows NT Registry
• Registry: Zentrale Konfigurationsdatenbank.
• Aufbau:
- Persistente Daten: system.dat & user.dat,
- Flüchtige Infos im HS (z.B. laufende Prozesse).
• Programme greifen massiv auf Registry zu:
- Netscape Gold 3.0 starten: ~ 1.400 Zugriffe,
- Dokument in Winword öffnen: ~ 200 Zugriffe.
• Zugriff auf Registry über:
- Systemaufrufe,
- Werkzeuge: regedit.exe,
- Dateien mit Endung *.reg.
218
• Probleme der Registry:
-
wächst durch Relikte von entfernten Prog.,
unübersichtlich, da zu wenig standardisiert,
falsche Einstellung führen u.U. zum Absturz,
je größer die Registry wird, desto langsamer
wird das BS Neuinstallation des Rechners.
• Systemkonfiguration in der Registry:
- Suchpfade: zusätzlich zu „PATH“
HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths
- DLLs:
HKLM\Software\Microsoft\Windows\CurrentVersion\SharedDLLs
- Deinstallationsprogramme:
HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall
- Drucker:
HKCC\System\CurrentVersion\Control\Print\Printers
- Treiber:
HKLM\System\CurrentControlSet\Services
• Anwendungskonfiguration:
- Empfehlung:
HKLM\Software\<Firmen-Name>\<Programm-Name>\<Version>
• Benutzereinstellungen:
- Pfad der Benutzerprofile:
HKLM\Software\Microsoft\Windows\CurrentVersion\ProfileList
- Anpassen von Anwendungen:
HKCU\Software\<Firmen-Name>\<Programm-Name>
219
• Beispiel: Schlüssel und Wert anlegen
#define NAME "Software\\Abteilung VS\\PlurixServer"
main()
{
HKEY
char
char
DWORD
hNewKey;
*szNewKey=NAME;
*szCont = "zeux";
dwDisposition;
// handle to new key
// name of new key
// name of value
// performed action
RegCreateKeyEx(
HKEY_LOCAL_MACHINE, // root-key
szNewKey,
// new key
0,
// reserved
"",
// unused class str
REG_OPTION_NON_VOLATILE,// persistent
KEY_ALL_ACCESS,
// access rights
NULL,
// security
&hNewKey,
// handle to new key
&dwDisposition
// performed action
);
RegSetValueEx(
hKey,
"String",
0,
REG_SZ,
(LPBYTE)szCont,
strlen(szCont)+1
);
// handle to key
// name of value
// reserved
// type of value
// string data
// string length
RegCloseKey(hNewKey);
}
220
9.5
Internet Domain Name Service
• DNS wurde 1987 eingeführt (RFC 1034).
• Verwaltet den Internet Namensraum.
• Merkmale:
-
hierarchisch strukturiert,
ersetzt zentrale Hosts-Tabellen,
verwaltet Millionen von rel. stat. Adressen,
Zuordnung von DNS-Namen & IP-Adressen.
• Organisation des Namensraumes:
- organisatorisch innerhalb der USA,
- geographisch auf der restlichen Welt.
Root
COM
EDU
GOV
UNI-X
UNI-Y
INST-A
Host
A
DE
Host
B
221
• Domain-Namen:
- Zeichenketten durch „.“ konkateniert,
- ortsunabhängig & immer absolut zur Wurzel.
• DNS Namer-Sever:
- Namensdaten primär aus lokalen Domäne,
- zusätzlich Adressen anderer Name-Server.
• Namensdaten werden in Zonen unterteilt:
- Zonen def. administrative Einheiten,
- Zonen-Konfigurationsdatei enthält Adresse &
Namen von anderen Name-Servern.
• Verfügbarkeit:
- Replikation auf mind. zwei unabh. Servern,
- primäre und sekundäre Zonen-Server,
- Vorhalten von Anfragen mit TTL (TimeToLive)
• Beispiel: Domains und Zonen
„“
nz
au
gov
com
edu
Zone au
Domain au
222
• Im Schnitt wird eine Name durch zwei
Resolutionsschritte aufgelöst
my.mac.gov.au ?
Name
Server
siehe au
„“
Name Server
au
gov.au
Name Server
gov.au
mac.gov.au
Name Server
Antwort
Anfrage
mac.gov.au
my.mac.gov.au
Name Server
Anfrager
• siehe auch: www.scit.wlv.ac.uk/~jphb/comms/dns.html
223
10.
Bibliotheken
10.1 Programmierschnittstellen
• Viele Schnittstellen auf verschied. Ebenen:
- HW: Register memory-mapped od. port-basiert.
- Treiber:
o nutzen Kernfunktionen.
o Implementieren vordef. Schnittstelle.
- Kern:
o Aufruf aus User-Mode per SW-Interrupt.
o Funktionsnummer indiziert in Fkt.-Tab.
- System-DLLs:
o prüfen Parameter, zusätzl. Fkt.
o führen Kernaufruf durch.
- User-DLLs & Dienste: zusätzliche Fkt.
Anwendungen
Middleware
User-DLLs
Dienste
System-DLLs
user-mode
kernel-mode
Kern
Treiber
Hardware
224
10.2 Prozedurbasierte Bibliotheken
• Als Arbeitserleichterung für Programmierer.
• Programmierschnittstelle zum System (API).
• Beispiele:
-
DirectX:
"Win32"
Open GL:
RPC:
Multimedia & Spiele,
Betriebssystemdienste,
Open Graphics Language,
Remote Procedure Call, …
10.2.1 Statische Bibliotheken
• Bibliotheken werden mit einem Programm in
einer Datei gebunden:
winword.exe
• Linux: test.a.4
excel.exe
Windows: myBib.lib
• Vorteile: immer alle Funktionen vorhanden.
• Nachteile:
- längere Ladezeiten,
- Speicherverschwendung,
- schlechte Erweiterbarkeit.
225
10.2.2 Dynamische Bibliotheken
• Gemeinsam nutzbar durch mehrere Prozesse.
• Unterstützt in allen Betriebssystemen:
- Apple Shared Library Manager für MacOS.
- Dynamic Link Libraries für Windows.
- Shared Libraries in Linux.
• Linux: libc.so.6.0.1
winword.exe
Windows: gdi32.dll
excel.exe
• Eine DLL ist eine Bibliothek, die zur Laufzeit
(beim Programmstart) geladen und mit dem
Programm verbunden (gelinkt) wird.
• Vorteile:
- nur benötigte Bibliotheken laden,
- gute Erweiterbarkeit,
- Speicherersparnis.
• Nachteile:
- Es können Laufzeitfehler durch unabsichtlich
gelöschte Bibliotheken entstehen.
- Meist verschied. Versionen einer Bibliothek im
System (teilw. unbenutzt) „DLL hell“.
226
10.2.3 Fallstudie: Windows DLLs
Aufruf einer Biblioheksfunktion
• Konsolenapplikation in C:
int main(int argcount, char* argvec[]){
return MessageBoxA(
NULL, "Boxtext(s)", "Boxtitel", MB_OK);
}
• Zeigt eine MessageBox (ASCII-Variante):
• #include "windows.h":
- includiert rekursiv weitere *.h-Dateien,
- für Signaturen und Typeninformation,
- für "MessageBoxA", "NULL" und "MB-OK" ...
• Compiler erzeugt ein Objektmodul mit einer
Importtabelle für den Linker, u.a.:
- .... External ... __imp__MessageBoxA@16 ...
227
Erzeugungsschritte eines C-Programmes:
*.c
Compiler
*.h
*.obj
Linker
*.lib
*.exe
Lader
*.dll
run
• Dateierweiterungen für Windows.
• Static Library (*.LIB):
- Bindung durch Linkage Editor,
• Dynamic Link Library (*.DLL):
- Bindung zum Ladezeitpunkt,
- Bindung zur Laufzeit.
228
Inspektion von Dateien mit Dumpbin:
• Dumpbin analysiert *.obj, *.lib, *.dll, *.exe.
• Unsere *.exe Datei enthält eine Importtabelle
für benötigte Bibliotheken, diese werden vom
Lader eingebunden.
C:\>dumpbin linkstatic.exe /imports
... USER32.dll
42428C Import Addr Table
42414C Import Name Table
...
1BE
MessageBoxA
KERNEL32.dll
42417C Import Addr Table
42403C Import Name Table
...
19D
19B
CA
174
7D
51
152
2DF
1AD
1F5
13E
1C2
1B0
124
29E
HeapDestroy
HeapCreate
GetCommandLineA
GetVersion
ExitProcess
DebugBreak
GetStdHandle
WriteFile
InterlockedDecrement
OutputDebugStringA
GetProcAddress
LoadLibraryA
InterlockedIncrement
GetModuleFileNameA
TerminateProcess ...
229
Laden einer DLL zur Laufzeit:
• Vorgehen in 3 Schritten:
- Laden der Dymaic Link Library (User32.dll),
- Suchen der Funktion (MessageBoxA),
- Rufen der Funktion.
int main(int argc, char* argv[]){
HANDLE hLib;
FARPROC hBxProc;
hLib = LoadLibrary("User32.dll");
hBxProc = GetProcAddress( hLib, "MessageBoxA");
return hBxProc(NULL, "Boxtext(d)", "Boxtitel", MB_OK);
}
Programmierung einer DLL:
• Funktionen explizit exportieren:
BOOL WINAPI DllMain(
HINSTANCE hinstDLL, // handle to DLL module
DWORD fdwReason,
// reason for calling function
LPVOID lpvReserved
// reserved
)
{ return TRUE; }
void __declspec(dllexport) PrintString(char *str) {
MessageBox(GetFocus(),str, "MyDLL", MB_OK);
}
230
10.2.4 Fallstudie: Linux Shared Libraries
• Name der Bibliothek:
-
z.B. libHello.so.1.0.1
Präfix „lib“ (optional).
Suffix „.so“: (Shared Library).
gefolgt von „Major-Versionsnummer“.
anschließend „Minor-Versionsnummer“.
und schließlich noch „Release-Nummer“.
• Name für Linker: symbolischer Link auf die
Bibliothek ohne Versionsnr., z.B. libHello.so
• Name für Lader: symbolischer Link “soname”
mit Major-Versionsnr. z.B. libHello.so.1.
• Bessere Handhabung von verschiedenen
Versionen, als bei Windows DLLs.
• Fkt. müssen nicht explizit exportiert werden.
• Standard-Speicherort: /lib, /usr/lib, ...
• Beim Laden des Programms werden Shared
Libraries automatisch gesucht & geladen:
- Pfade in Var. LD_LIBRARY_PATH.
- Pfade mit ‘:’ konkateniert.
• Suche nach Bibiotheken langsam -> Cache in
/etc/ld.so.cache (verwaltet mit ldconfig).
231
• Beispiel:
libhello.c:
/* libhello.c - demonstrate library use. */
#include <stdio.h>
void hello(void) {
printf("Hello, library world.\n");
}
demo.c:
/* demonstrate direct use of the "hello" routine */
#include "libhello.h"
int main(void) {
hello();
return 0;
}
Übersetzen, Binden & Starten:
gcc -fPIC -c libhello.c
# compile library
# (-fPIC position independent code)
gcc -shared -Wl,-soname,libhello.so.0
# create library
-o libhello.so.0.0.0 libhello.o –lc
# -lc link library
ln -sf libhello.so.0.0.0 libhello.so.0
# set up soname
ln -sf libhello.so.0 libhello.so
# set up linker name
gcc -c demo.c -o demo.o
# compile demo prg
gcc -o demo demo.o -L. –llibhello
# bind demo prg
# (-L lib search path for linker)
LD_LIBRARY_PATH="." ./demo
# test program
• Inspektion von Dateien mit ldd.
232
Laden einer Shared Library zur Laufzeit:
• Vorgehen wie bei Windows:
#include <stdlib.h>
#include <stdio.h>
#include <dlfcn.h>
// Shared Libs. dynamisch laden
int main(int argc, char **argv) {
void *handle;
double (*cosine)(double); // Funktions-ptr.
char *error;
// Fehler-String
// RTLD_LAZY=Symbole dyn. auflösen
handle = dlopen ("/lib/libm.so.6", RTLD_LAZY);
if (handle==0) {
fputs (dlerror(), stderr); // Fehler des letzten Aufrufs
exit(1);
}
cosine = dlsym(handle, "cos");
error = dlerror();
if (error!=NULL) {
fputs(error, stderr);
exit(1);
}
// GetProcAddress
printf ("%f\n", (*cosine)(2.0));
dlclose(handle);
// Fkt. aufrufen
// Shared Lib. freigeben
}
• Übersetzen des Programms:
gcc -o test test.c -ldl
233
10.3 Objektorientierte Bibliotheken
• COM = Component Object Model, 1992.
• Verwendet unter Microsoft Windows.
• Grundlage für viele weitere Dienste: OLE,
OCX, ActiveX, DCOM.
• Merkmale:
- Objekte in DLLs oder Programmen,
- sprachunabhängig (C++, Java, Basic, ...).
• Grundidee: Zusammenfassen von Funktionen
eines Serverobjektes zu Einheiten (Interfaces).
Klient
COMObjekt
Realisierung:
• Def. lediglich Speicherlayout von Interfaces.
• Layout entspricht dem einer abstrakten C++
Klasse.
234
• COM-Speicherlayout:
IfcPtr
virtualTable
private
Daten
func-1
func-2
func-3
ObjektCode
• C++ Notation:
class Interface1 {
public:
virtual void func1()=0;
}
class MyObject : public Interface1 {
void func1();
void func2();
void func3();
}
• Aufruf einer Interface-Methode:
C++:
o = new MyObject;
o->func1();
C:
o->vtbl->func1();
235
Instanziierung:
• Können nicht mit „new“ instanziiert werden.
• Obj. über COM-Laufzeitbibliothek erzeugen.
• Objekte durch UUID eindeutig identifizierbar.
• UUID = Universal Unique Identifier (128-Bit
Zahl mit guidgen.exe erzeugen).
• Ablauf der Instanziierung:
Server
COMObjekt
Klient
(1)
anc
bra
ry
(3)
L
nst
oa
dL
i
eI
eat
Cr
Co
(4)
ClassFactory
e
t
ea
r
C
(4)
e
nc
a
t
s
eI n
COM-Bibliothek
(2)
Registry
• Für den Klienten bleibt transparent, ob das
Objekt in einer DLL oder einem Programm
untergebracht ist.
236
Interfaces:
• Sind durch UUID eindeutig identifizierbar.
• Konventionen:
- jedes COM-Objekt muss mindestens das
Interface IUnknown implementieren
- und von IUnkown abgeleitet sein.
interface IUnknown {
HRESULT QueryInterface(REFIID riid, void **Obj);
ULONG AddRef();
ULONG Release();
}
In-Process-Server:
• COM Objekte in einer DLL:
- Im selben Adreßraum (DLL).
- COM-Bibliothek lädt die DLL bei Bedarf.
• Beispiel: ein eigenes Interface:
class CTest : public IUnknown {
public:
CTest();
STDMETHODIMP QueryInterface(REFIID, PPVOID);
STDMETHODIMP_(ULONG) AddRef(void);
STDMETHODIMP_(ULONG) Release(void);
virtual STDMETHODIMP Print(char *str);
};
237
• Beispiel Klassenfabrik:
class CTestClassFactory : public IClassFactory
{
public:
CTestClassFactory();
STDMETHODIMP QueryInterface(REFIID, PPVOID);
STDMETHODIMP_(ULONG) AddRef(void);
STDMETHODIMP_(ULONG) Release(void);
STDMETHODIMP CreateInstance(LPUNKNOWN, REFIID,
PPVOID);
STDMETHODIMP LockServer(BOOL);
};
• Beispiel Registrierung:
[HKEY_CLASSES_ROOT\CLSID\{6F922D61-D801-11D0-A2200020182C05E3}\InprocServer32]
@="e:\\BS\\InProcServer\\Debug\\comdll.dll"
• Zusätzlich notwendige Funktionen in DLL:
- DllGetClassObject:
o liefert Zeiger auf die Klassenfabrik,
o zum Erzeugen von Objekten.
- DllCanUnloadNow:
o teilt mit, ob die DLL noch benötigt wird.
o wird periodisch vom System gerufen.
238
Local- Server:
• COM-Objekte in einem separatem Programm
(EXE) residieren in fremden Adressraum.
• Server:
- eigenständiges Programm,
- Kommunikation über RPC,
- registriert seine Klassenfabrik beim Start.
• Für Interfaces eines fremden Adreßraumes,
werden Proxy-Stub-Objekte geladen:
- Signatur gemäß RPC Notation,
- Erzeugung mittels MIDL-Compiler,
- es gibt vordef. Interfaces: IStream, IStorage, ...
Klient
Server
Proxy-DLL
COMObjekt
ClassFactory
• Ablauf der Instanziierung:
-
Klient ruft „CoGetClassObject“
COM-Bib. lädt LocalServer und Proxy-Dll
Klient ruft „CreateInstance“ der ClassFactory
LocalServer gibt Klient Zeiger auf Interface
239
10.4 Systemaufruf am Beispiel von NT
DWORD CreateEventDirect(
HANDLE
*SemaphoreHandle,
// result handle
DWORD
DesiredAccess,
// access bits
UNICODE
*ObjectName,
// name of evt-object
ULONG
ManualReset,
// after use
ULONG
InitialState
// initial value
{ __asm { mov eax, 0x23;
// # of NtCreateSemaphore
lea edx,[ebp+0x8]; // parameters (skip 2 W)
int 0x2e;
// _KiSystemService
}
}
// end assembly, end CE
void main() {
HANDLE hEvt;
// the desired handle
DWORD
status;
// status code
DWORD
acc = EVENT_ALL_ACCESS;
// create an event-object via software-interrupt INT 2e :
status = CreateEventDirect(&hEvt, acc, NULL, 1, 1);
if (status!=STATUS_SUCCESS) printf(" error \n");
else printf("success, handle: %x\n", hEvt);
// or create an event-object via kernel32.dll :
hEvt = CreateEventW(NULL, 1, 1, NULL); // W=wide
if (hEvt==NULL) printf(" error \n");
else
printf("success, handle: %x\n", hEvt);
}
// kernel-mode unicode strings
typedef struct _UNICODE_STRING {
USHORT Length;
// used length
USHORT MaximumLength; // max. length of buffer
PWSTR Buffer;
// WCHAR buffer
} UNICODE;
typedef UNICODE * PUNICODE_STRING ;
240
• Im NtOSkernel.exe findet sich eine Funktion
mit einer Signatur wie CreateEventDirect:
NTSTATUS NtCreateSemaphore(
OUT HANDLE
IN
ACCESS_MASK
IN
PUNICODE_STRING
IN
ULONG
IN
ULONG
);
*SemaphoreHandle,
DesiredAccess,
ObjectName,
ManualReset,
InitialState
• Diese Funktion NtCreateSemaphore wird
indirekt gerufen:
- über den LPC Manager.
- da in einem anderen Adressraum,
- über einen Software-Interrupt (int 0x2e),
• CreateEventDirect präpariert die Parameter
auf dem User-Stack:
- zusätzlicher Parameter: Funktionsnummer,
- zusätzlicher Parameter: Zeiger auf Stackframe,
• LPC kopiert diese dann in den Kernel-Stack.
• Alternativ wird derselbe Effekt erreicht durch
Aufruf von CreateEventW in Kernel32.dll.
Die DLL übernimmt die Vorbereitung der
Parameter und ist komfortabler zu benutzen.
• Bem.: es wird hier nur der NT-Kern, aber kein
Server-Prozess gerufen.
241
11.
Benutzerschnittstellen
11.1 Überblick
• Ziel: Interaktion mit dem Benutzer
• Gliederung nach Art der Interaktion:
- Batchorientierte Systeme,
- Interaktive Betriebssysteme,
- Transaktionsorientierte Systeme.
• Unterscheidung nach Ein-/Ausgabegeräten:
-
Automaten,
Textbildschirm,
Grafikbildschirm,
Sprachausgabe & -erkennung.
Textbildschirm / Konsole
• Historisch: Fernschreiber (Teletype)
- Eingabe: Tastatur,
- Ausgabe: serielle Leitung,
- Programme: TTY (Unix & Windows).
• Textbildschirm:
- ASCII-Zeichensatz,
- 80*25 Zeichen oder besser,
- Farbe möglich, aber keine Grafik.
242
• Konsole: ASCII-basierte Interaktion
- MS-DOS: command.com
- Windows: cmd.exe
- Linux:
o verschiedene Shells (z.B. bash),
o virtuelle Konsolen mit ALT-Fx; xterm
• Zugang über Netzwerk mit Telnet oder SSH:
-
Remote-Login Dienst,
Übertragung über TCP,
Terminal-Typen: z.B. VT100,
Windows: telnet.exe, TTermPro
Linux: telnet, SSH.
Konsole
Anwendung
VT100Treiber
PseudoTerminal
TelnetClient
TelnetServer
Internet
243
Graphische Benutzerschnittstellen
• Pixelbasierte Ansteuerung des Bildschirms.
• Fenster:
- virtualisieren Bildschirmfläche.
- meist rechteckig, aber nicht zwingend.
- Anordnung überlappend oder gekachelt.
• Mehrere Applikationen können auf dem Bildschirm verwaltet werden.
• Grundelemente eines Fensters:
- Rahmen mit Verstellelementen,
- Titelleiste mit Menü,
- Klientenbereich,
• Ausgabe von Text und Grafik innerhalb eines
Fensterrahmens.
• Steuerelemente (Controls) ebenfalls Fenster.
• Eingabe per Maus & Tastatur.
• Symbole (Icons) statt langer Befehle.
• Vorteil: verwandtes Aussehen und Bedienung
für verschiedene Programme.
244
11.2 Befehlsinterpreter
• Befehlsinterpreter:
- Nimmt Befehle und Parameter entgegen,
- Eingebaute Kommandos sind a priori bekannt,
- Zusätzliche Befehle durch externe Programme.
• Syntax: <Kommando> <Param1> ... <Pn>
-
Erstes Token wird als Kommando interpretiert,
Parameter: Trennung mit Space oder Komma,
Optionen: meist gekennzeichnet durch -, --, /,
Parameter & Optionen in argv[].
• Kommandos unter Microsoft Windows:
-
Interpreter: cmd.exe (Win9x: command.com).
Befehle sind nicht case-sensitiv.
Diverse eingebaute Kommandos „help“.
Externe Befehle:
o Programme (.exe),
o Dateien mit bekannter Verknüpfung,
o Suchpfade (beachte PATH-Variable).
• Kommandos unter Unix:
- Diverse Interpreter: bash, ksh, ...
- Befehle sind case-sensitiv.
- Eingebaute Befehle: Syntax & bekannte Befehle
abhängig von Shell.
- Externe Befehle: Ausführbare Dateien,
245
Standard Ein-/Ausgabe
• Jedes Programm besitzt geöffnete Dateien auf
Tastatur (stdin) und Bildschirm (stdout).
• stdin, stdout zeigen auf Gerät:
- „CON“: Windows
- „/dev/tty“: Linux
• Umleiten der Eingabe: <Datei.
• Umlenken der Ausgabe: >Datei & >>Datei.
• Mehrere Kommandos in einer Kette: „c1 | c2“:
Ausgabe von c1 ist Eingabe für c2 ( Pipe).
Umgebungsvariablen
• Konfiguration von Programmen & System.
• Zugriff in Programmen & Konsole möglich.
• Steuerung in Konsole (Windows):
- Setzen & Löschen: SET Name=Wert
- Ausgabe: echo %name%
• Verwendung unter Linux (bash):
- Setzen & Löschen: export Name=Wert
- Ausgabe: echo $name
• Konfiguration in Linux abhängig von Shell.
246
Stapeldateien (BAT-Dateien)
• Zusammenfassung mehrerer hintereinander
auszuführender Kommandos (NT).
• Ziel: Automatisierung bestimmter Abläufe.
• Zugriff auf Argumente durch: %1 %2
• Anweisungen (siehe Hilfe „help“):
-
ECHO: Ausgabe,
PAUSE: Tastendruck abwarten,
GOTO: Sprung zu Marke ":NAME",
ERRORLEVEL: Fehlerstufe von Prg.aufruf,
IF, FOR, CALL, usw.
• Beispiel:
@ECHO OFF
REM das ist ein Kommentar
IF p%1 == pParam ECHO kein Parameter!
• Tutorials: www.antonis.purespace.de/batchtut
247
Erweitertes Scripting
• Windows Scripting-Host interpretiert mehrere
Sprachen: VB-Script, Java-Script, Perl ...
• Einsatzgebiete:
- Automatisierung von Abläufen,
- Erweiterung von Programmen & Systemen.
• Merkmale:
-
weniger Aufwand, da kein Compiler notwendig,
Erweiterung von Programmen & Systemen,
umfangreiche Sprachkonzepte.
basiert auf COM.
• Aufruf über:
- cscript Programm Konsolausgabe,
- wscript Programm Windows-Ausgabe,
- oder direkt durch die Erweiterung ".vbs".
• Nutzung von eingebauten Obj. z.B. „WScript“
• Zugriff auf externe Obj. mit „CreateObject“.
• Beispiel: Ausgabe des Namens des aktuellen
Benutzers:
Set net = Wscript.CreateObject("Wscript.Network")
MsgBox(net.UserName)
248
11.3 X Window
• Projekt Athena (MIT 84), derzeit Ver. X.11.
• Trennung von Programm (X Klient) und Ausgabegerät (X Window Server).
• Struktur:
• Window Server:
-
verwaltet Bildschirm, Tastatur & Maus,
kann mehrere Klienten bedienen,
Rückmeldung an App. (selektiv),
Grundoperationen auf Fenstern,
Ausgabe von Basisfiguren,
Schriften, Farbtab. , ...
• X Klient (Anwendung):
- Grafikausgaben & Ereignisverarbeitung,
- zu einem oder mehreren Servern verbunden.
249
• Window Manager:
- eine X Window Server Anwendung,
- einmal gestartet pro X Window Server,
- definiert Look & Feel (z.B. olwm, fwm, ...).
• X Protokoll:
- Kommunikation zw. X Klient und X Server.
- asynchrone Verarbeitung.
- TCP, bzw. IPC lokal.
• X Lib:
-
C-Bibliothek.
realisiert X-Protokoll.
Verbindungsauf- und –abbau.
Eingabeereignisse in Warteschlange,
Ausgabefunktionen: Text und Grafik.
• X-Toolkits:
- erleichtern Entwicklung GUI-basierter Prgs.
- objektorientiert Bib., z.B. Qt (KDE).
• Desktop Systeme:
- erweiterten X Window Manager,
- gleiches „Look and Feel“ für Programme
- z.B. KDE, Gnome, ...
250
• Umlenkung des Displays:
xterm –display 134.60.77.99:0
• Berechtigung für lokales Display:
xhost +134.60.77.99 (setzen)
xhost -134.60.77.99 (löschen)
• Kommando-Interpreter unter X-Window:
251
11.4 Microsoft Windows
• Ursprünglich 16-Bit Aufsatz für MS-DOS.
• Kein separater Window-Manager.
• Toolkit: MFC.
• Tastatur- und Mauseingaben werden dem Programm meist als Nachricht übergeben:
typedef struct tagMSG {
HWND
hwnd;
UINT
message;
WPARAM
wParam;
LPARAM
lParam;
DWORD
time;
POINT
pt;
} MSG;
//
//
//
//
//
//
respektives Fenster
MessageCode
32 Bit in Win32
32 Bit
Stempel
Mauskoordinaten
• Tastatureingabe:
message:
wParam:
lParam:
WM_KEYDOWN
virtual key code
Scan-Code, Repeat, Modifier ...
• Maus-Ereignisse:
- WM_LBUTTONDOWN,
- WM_MBUTTONDOWN,
- WM_RBUTTONDOWN,
• Ca. 1000 weitere WM... Nachrichten und
Unternachrichten.
252
Grobstruktur einer Benutzereingabe:
NewWClass
WindowFunkt.
NewWindow
GetMessage
Translate
DispatchMessage
MessageLoop in WinMain
• Programmstart über WinMain.
• Fensterklasse als Schablone für FenstererDekoration.
• Erzeugen von Fenstern mit gemeinsamer oder
separater Fensterfunktion.
• Nachrichten werden in einer zentralen
Nachrichtenschleife entgegengenommen.
253
Beispielprogramm "SimpleWindow.c"
• Eintragen unserer Fensterklasse und erzeugen
eines Fensters:
#define WINDOW_CLASS_NAME "SimpleWindowClass"
#define WINDOW_TITLE
"A SimpleWindow"
void NewWindowClass( HINSTANCE hProgram,
WNDPROC CallBackProc)
{ DWORD
res;
WNDCLASS
wc;
wc.style
= CS_HREDRAW|CS_VREDRAW;
wc.lpfnWndProc
= CallBackProc;
wc.cbClsExtra
= 0;
// class extra data
wc.cbWndExtra
= 0;
// window extra data
wc.hInstance
= hProgram; // associated prog
wc.hIcon
= NULL;
// when minimized
wc.hCursor
= LoadCursor( NULL, IDC_ARROW);
wc.hbrBackground = (HBRUSH)( COLOR_WINDOW+1);
wc.lpszClassName = WINDOW_CLASS_NAME;
res
= RegisterClass( &wc );
}
void NewWindow(HINSTANCE hProgram)
{ HWND hWnd= CreateWindow(
WINDOW_CLASS_NAME,
WINDOW_TITLE,
WS_OVERLAPPEDWINDOW,
9, 9, 320, 200, // pos & size
NULL,
// no parent window
NULL,
// no menu
hProgram,
// associated prog.
NULL);
// no creation data
ShowWindow(hWnd, SW_SHOW);
UpdateWindow(hWnd);
}
254
• Callback Funktion für unser Fenster und
Entry für das Programm:
LRESULT CALLBACK WndProc(
HWND hWnd, UINT msgCode,
WPARAM wPar, LPARAM lPar )
{ switch (msgCode) {
case WM_DESTROY:
PostQuitMessage(0); return 0;
default:
return DefWindowProc( hWnd,wmCode,wPar,lPar);
}
}
int WINAPI WinMain(
{ MSG
HINSTANCE
HINSTANCE
LPSTR
int
hProgram,
hPrevProg,
lpCmdLine,
nCmdShow)
msg;
NewWindowClass( hProgram, (WNDPROC) WndProc );
NewWindow( hProgram );
while ( TRUE )
// message loop
{
if ( GetMessage( &msg, NULL, 0, 0) ==WM_QUIT )
return msg.wParam ; // result of WM_QUIT
TranslateMessage( &msg ); // translate Characters
DispatchMessage( &msg ); // invoke callbacks
}
}
255
12.
Sicherheitsaspekte
12.1 Einleitung
• Ziel: Schutz vor Fehlern & Eindringlingen.
• Objekt: passive Ressource (z.B. Datei)
• Subjekt: aktive Einheiten (Proz. & Benutzer)
• Sicherheit: Fähigkeit eines BS, für seine Obj.
Vertraulichkeit & Integrität zu garantieren.
• Anfordernungen:
- Nur berechtigte Subj. dürfen mit Obj. arbeiten.
- Subjekte müssen sich zunächst authentisieren.
- Zugriffe sollen protokollierbar sein.
• Orange Book (DoD) definiert Klassen für die
Sicherheit von Computersystemen:
-
A: Verified Design
B3: Security Domains
B2: Structured Protection
B1: Labeled Security Protection
C2: Controlled Access Protection
C1: Discretionary Security Protection
D: Minimal Protection
A, B3, B2, B1, C2, C1, D
sicher
unsicher
256
12.2 Zugangskontrolle
• Nur best. Subjekte dürfen das System nutzen.
• Voraussetzung für die Nutzung ist eine:
- Identifikation (Angabe, welcher Nutzer) und
- Authentisierung (Nachweis, der Nutzerangabe).
• Nicht Aufgabe des BS-Kerns, sondern durch
Systemprozeß.
• Authentisierung durch: Paßwort, Chipkarte
oder biometrische Merkmale.
• Windows und Linux verwenden einen Benutzernamen zusammen mit einem Paßwort.
Passwörter in Unix:
• Verschlüsselung sofort nach Passworteingabe:
- Vergleich mit Passwortdatei.
- niemand (inkl. root) sieht Passwörter i. Klartext.
- aber Verschlüsselungsalgorithmus ist bekannt
Angriff per trial and error mit Wörterbuch
• Probleme früherer Versionen:
- Passwortdatei (/etc/passwd) für Benutzer lesbar.
Angriff: Datei kopieren und Ausprobieren.
- jetzt getrennte Speicherung der Passwörter in
nicht lesbarer Shadow-Datei (/etc/shadow).
257
12.3 Zugriffskontrolle
12.3.1 Zugriffsmatrix
• Zuordnung von Benutzerrechten und Objekten
in einer Matrix:
1
2
A
R
RW
B
R
C
R
D
R
3
4
5
6
RW
RWX
R
X
R
• Probleme:
- Matrix nur dünn besetzt,
- Einträge sind sehr dynamisch.
• Alternativen:
- Zugriffskontrollisten (access control lists).
- Berechtigungslisten (capability lists).
258
12.3.2 Zugriffskontrollisten
• engl. Access Control Lists
• Speicherung & Verarbeitung nach Spalten.
• Sicherheitsmanager prüft Berechtigung eines
Subjektes bei Zugriff auf ein Objekt.
• Verwendet in Windows NT/2000 und Unix.
234 567 8
• Bewertung:
+ Überblick beim Objekt
+ Rechte leicht widerrufbar
- Delegation umständlich
.
/0
1
/
• Arbeitet mir Zugriffskontrollisten.
• Sicherheitstoken besteht aus 128-Bit IDs.
& '()*+
$ %
! " " !#
, -
259
12.3.3 Berechtigungslisten
• engl. Capabilities.
• Speicherung & Verarbeitung nach Zeilen.
• Beim Zugriff auf ein Objekt muß das Subjekt
die passende Berechtigung vorweisen.
• Berechtigungen müssen geschützt werden.
• Nur in der Forschung verwendet (z.B. Hydra).
• Bewertung:
+ kompletter Überblick beim Subjekt
+ Delegation einfach
- schwierig widerrufbar
260
12.4 Supervisor Betriebsmodus
• HW-Unterstützung zur Unterscheidung zw.
User- und Supervisor-Modus.
• Zusätzliches Mode-Bit in Hardware:
- 0: supervisor-mode,
- 1: user-mode.
• Im Fall eines Traps oder Interrupts wird das
Mode-Bit gelöscht.
• Wenn das BS die Kontrolle an das Programm
abgibt, wird Bit wieder gesetzt.
• Privilegierte Befehle dürfen nur
Supervisor-Modus ausgeführt werden.
im
• Ggf. wird ein Trap ausgelöst.
• Systemaufrufe mittels Supervisor-Call (z.B.
SVC bei MVS).
• 4Verfeinerung durch mehrere Privilegstufen
Ringe bei x86-CPUs im Protected Mode.
261
12.5 Isolation der Adressräume
• Getrennte Adreßräume durch:
- Segmentierung,
- mehrfach virtualisierten Speicher.
• Beispiel: Windows NT
-
Kernel- und User-Mode,
pro Prozeß jeweils 2 GB virt. Speicher,
Kernel-Mode Speicher gemeinsam genutzt,
Komm. Kernel- und User-Mode umständlich.
262
12.6 Angriffsformen
• Ziel: Versuch, bestimmten Programmcode in
Rechtebereich auszuführen, in dem das nicht
vorgesehen war.
• Einschleusen von:
-
kompletten Programmen,
Code in Quellprogrammen,
Code in ausführbaren Dateien,
Code während der Programmausführung.
Einschleusen von kompletten Programmen
• Vorgehen: Komplettes Programm so platzieren, dass Rechteinhaber X es (bewusst oder
unbewusst) startet und ausführt.
• Bewusste Ausführung durch Rechteinhaber:
- Attraktives Programm anbieten, das Rechteinhaber ggf. selbst auf den Rechner überträgt und
dort ausführt.
- "Trojanisches Pferd": Erbringt möglicherweise
die erwartete Leistung, enthält aber zusätzlich
Codeteile, die Manipulationen vornehmen.
- Gegenmaßnahmen kaum möglich.
263
• Unbewusste Ausführung:
- Platzierung so, dass der Rechteinhaber das
Programm unbewusst an Stelle eines anderen
Programms ausführt.
- Z.B. Mißbrauch der PATH-Umgebungsvariable.
- Gegenmaßnahmen kaum möglich.
• Platzierung in Daten:
- Nutzung von "Makro"-Mechanismen: in Daten
einbettbare Programme, die bei Bearbeitung der
Daten ausgeführt werden. "Makroviren".
- Die meisten weltweiten Virusangriffe der letzten
Jahre waren Makroviren.
- Gegenmaßnahme: Makros deaktivieren.
Einschleusen von Code in Quellprogrammen
• Programmquelle modifizieren oder erweitern.
• Relativ einfach und verwendbar für unterschiedl. Zielplattformen.
• Voraussetzung: Zugang zur Programmquelle.
• Z.B. best. Eingabe wird speziell behandelt
erlaubt Programmierer später Zugang zu
allen Systemen, die das Programm einsetzen.
• Gegenmaßnahmen: Begutachtung des Quellcodes durch mehrere Programmierer.
264
Ausführbare Dateien modifizieren
• Ausführbares Programm modifizieren oder
erweitern.
• Voraussetzung: Schreibzugriff auf Programmdatei und gewisse Kenntnisse über Struktur
des ausführbaren Programms.
• Prinzip der klassischen "Viren".
• Gegenmaßnahmen: Virenscanner.
Einschleusen von Code während der
Programmausführung
• Programmcode modifizieren oder erweitern
im Hauptspeicher, während Programm durch
Prozess ausgeführt wird.
• Voraussetzung: Zugang zum Codebereich des
Prozesses im Hauptspeicher.
• Normalerweise nur Datenbereich zugänglich.
In gewissen (fehlerhaften) Fällen aber auch
Codebereich.
• Gegenmaßnahme: Prävention durch korrekte
sichere Programmierung.
265

Betriebssysteme - Institut für Verteilte Systeme

Transcription

Similar documents

Dateien anzeigen - Heinrich-Heine

Thread - Universität Ulm

Windows - Registry