Sie sind auf Seite 1von 635

Chair of Connected Mobility

Department of Informatics
Technische Universität München

Kapitel 01

Grundlagen Betriebssysteme und Systemsoftware


Einführung

Prof. Dr.-Ing. Jörg Ott


Lehrstuhl Connected Mobility

Folien frei nach der Vorlage von Prof. C. Eckert (WS16/17, WS17/18) – danke!

© 2018-21 Jörg Ott | GBS | IN 0009 1


Fragen
• Welche Aufgaben hat ein Betriebssystem?

• Wie erfüllt es diese?

• Wie grenzt sich das Betriebssystem von Anwendungen der


Nutzer ab – konzeptuell und in der Umsetzung?

© 2018-21 Jörg Ott | GBS | IN 0009 2


Ziele
• Definition Rechensystem als komplexes System

• Einordnung Betriebssysteme

• Aufgaben eines Betriebssystems

• Grundlegende Konzepte (später vertieft)

• Betriebssystem-Architekturen

• Systemprogrammierung

© 2018-21 Jörg Ott | GBS | IN 0009 3


Begriffe
• Allgemein: Aufgabe der Informatik
• Aufgabe der Informatik ist es, Rechensysteme zu entwickeln und
diese Anwendern als leistungsfähige Hilfsmittel für Lösungen ihrer
Informationsverarbeitungsprobleme zur Verfügung zu stellen.

• Definition: Rechensystem (synonym: Rechner, Computer)


• Rechensysteme sind
• offene,
• dynamische,
• technische Systeme

• mit der Fähigkeiten zur


• Speicherung und
• Verarbeitung von Information sowie
• der Fähigkeit zur Kommunikation.

© 2018-21 Jörg Ott | GBS | IN 0009 4


Ein Rechensystem: Raspberry Pi 3

Quelle: https://electronicshobbyists.com/tutorial-1-what-is-raspberry-pi-getting-started-with-raspberry-pi-3/

© 2018-21 Jörg Ott | GBS | IN 0009 5


Von-Neumann-Architektur

Quelle: Wikipedia (https://commons.wikimedia.org/wiki/File:Von-Neumann_Architektur.svg)


© 2018-21 Jörg Ott | GBS | IN 0009 6
Einfache Systemstruktur

Quelle: Modern Operating Systems. Andrew S. Tanenbaum and Herbert Bos. 4th edition Pearson, 2015, Seite 20

© 2018-21 Jörg Ott | GBS | IN 0009 7


Raspberry Pi Modell 3B

Quelle: http://doc.xdevs.com/doc/RPi/pi3-block-diagram-rev4.png
© 2018-21 Jörg Ott | GBS | IN 0009 8
Offenes System, Komponenten, Sichten
• Offenes System
• Besteht aus Komponenten,
• Verbindungen zwischen Komponenten beschreiben Abhängigkeiten,
• Besitzt Schnittstellen zur externen Einwirkung auf das System.
(Wichtige weitere Fassung von „offen“: Ist so gestaltet und dokumentiert,
dass die Schnittstellen von Dritten genutzt werden können.)

• Schnittstelle: z.B. Benutzerinteraktion, Netzschnittstelle


• Schnittstellen ermöglichen verschiedene Sichten auf ein System:
• Von außen: Black-Box-Sicht
• Zusammenfassungen von Komponenten und Abgrenzungen liefern
Einheiten, für die Black-Box-Sichten möglich sind.
• Von innen: White-Box-Sicht
• Rekursive Aufteilung in Komponenten bzw. Sub-Komponenten liefern
verfeinerte White-Box-Sichten.

© 2018-21 Jörg Ott | GBS | IN 0009 9


Sichten: Black Box vs. White Box

© 2018-21 Jörg Ott | GBS | IN 0009 10


Dynamisches System
• Dynamisches System
• Eine Reihe von Eigenschaften beschreiben den Zustand des
Systems – zu einem Betrachtungszeitpunkt
• Die Eigenschaften eines Rechensystems verändert sich über die Zeit.
• Eigenschaftsänderungen sind Zustandsänderungen
• Eine Folge von Zuständen bzw. Zustandsänderungen beschreibt das
Systemverhalten
• Diese Fähigkeit zur Zustandsänderung erhält ein Rechensystem durch
aktive (z.B. CPU) und passive Komponenten (z.B. Arbeitsspeicher)
• Aktive Komponenten führen Aktionen aus, die Zustandsveränderungen
bewirken.
• Die passiven Komponenten sind Hilfsmittel für diese Aktionen.
• Technisches System
• Ein Rechensystem ist mit hardware- und softwaretechnischen Mitteln
realisiert.
© 2018-21 Jörg Ott | GBS | IN 0009 11
Betriebssysteme als Teil von Rechensystemen
Allgemeine Schichtenstruktur und Einordnung des Betriebssystems

Betriebssystem

Quelle: Schlichter

Optional: Virtualisierung mehrerer Betriebssysteme inkl. virtueller Hardware


© 2018-21 Jörg Ott | GBS | IN 0009 12
Definitionen Betriebssystem
• Definition Betriebssystem nach DIN 44300 (1972):
• Das Betriebssystem wird gebildet durch die Programme eines digitalen
Rechensystems, die zusammen mit den Eigenschaften der
Rechenanlage die Grundlage der möglichen Betriebsarten des
digitalen Rechensystems bilden und insbesondere die Ausführung von
Programmen steuern und überwachen.

• Alternative Definition
• Das Betriebssystem ist selbst ein Programm, das die Ausführung von
System- oder Anwendungsprogrammen steuert und überwacht und
für die Anwendungsprogramme eine Schnittstelle zu den Hardware-
Komponenten bereitstellt.
• Schnittstellen sind z.B. Operationen wie read, write für den Zugriff
auf gespeicherte Daten.

© 2018-21 Jörg Ott | GBS | IN 0009 13


Aufgaben eines Betriebsystems (1)
1. Abstraktion

• Vereinfachung, Bereitstellung von abstrakten Konzepten


und gemeinsamen Schnittstellen, z.B. Dateien.

• Beispiel für Abstraktion: Zugriff auf Ein-Ausgabe-Geräte


• Jedes Gerät besitzt eigenen Befehlssatz, Register usw.
• Problem: Programmierer müsste für jedes Gerät dessen Eigenschaften
kennen
• Lösung: Betriebssystem definiert einheitliche Operationen
(Schnittstelle), z.B. read, write
• Programmierer nutzt diese Operationen
• Betriebssystem setzt diese auf die Geräte-spezifischen Befehle um
• unter Verwendung eines gerätespezifischen Treibers, der die Details des
Geräts versteht
© 2018-21 Jörg Ott | GBS | IN 0009 14
Aufgaben eines Betriebsystems (2)
2. Management (von Ressourcen)

• Steuern und Kontrollieren der Programmausführung


• Beispiel:
• Kontrolle der CPU-Nutzung: welches Programm darf wie lange ohne
Unterbrechung die CPU nutzen

• Strategische Entscheidungen
• Priorisierung: Wer hat Vorrang? Fairness?
• Agil, adaptiv: Wie geht man mit spontanen Anforderungen um?

• Operative Entscheidungen
• Einem Programm die CPU zu einem bestimmten Zeitpunkt zuweisen
bzw. wegnehmen
© 2018-21 Jörg Ott | GBS | IN 0009 15
Faktoren für die Entwicklung von BS (1)
1. Fortschritte der Hardwaretechnologie
• Gutes Preis-Leistungs-Verhältnis
• Beispiel: Speicher: Große Festplattenspeicher zu geringen Preisen
• Anforderungen an das Betriebssystem: u.a.
• Schnelle Zugriffe auf gespeicherte Daten ermöglichen,
• Unterstützung von Parallelverarbeitung: viele Programme gleichzeitig im
Speicher

2. Übergang von rein numerischer Berechnung zur


allgemeinen Informationsverarbeitung.
• Interaktive Verarbeitung, Graphische Datenverarbeitung, Multimedia
• Anforderungen an das Betriebssystem: u.a.
• Grafischer Nutzeroberflächen: Nutzung auch durch Nicht-Spezialisten
• Realzeit-Unterstützung, z.B. bei Verarbeitung von Videos

© 2018-21 Jörg Ott | GBS | IN 0009 16


Faktoren für die Entwicklung von BS (2)
3. Neue Anwendungsbereiche und Digitalisierung
• Auslagerung von Diensten und Datenspeicherung an externe Anbieter
(im Gegensatz zum eigenständigen Betrieb)
• Auslagerung des Rechenzentrums bzw. der Server
• Vernetzung von physischen mit digitalen Komponenten
• z.B. Energie-Bereich, Auto
• Einbetten von IT in Objekte des täglichen Lebens
• z.B. Internet of Things (IoT), z.B. smart Home
• Anforderungen an das Betriebssystem: u.a.
• Cloud-Computing, Virtualisierung und Containerisierung (Docker etc.)
• Eingebettete Betriebssysteme: u.a. ohne Nutzerschnittstellen

© 2018-21 Jörg Ott | GBS | IN 0009 17


Betriebsarten
• Stapelverarbeitung (batch processing)
• Das Programm wird vor dem Start komplett definiert und geschlossen
ausgeführt.
• Nutzer-Interaktion ist nicht vorgesehen
• Transaktionsbetrieb (transaction system)
• Auch bekannt aus dem Bereich der Datenbanken
• ACID-Kriterien (Atomarität, Konsistenz, Isolation, Dauerhaftigkeit)
• Dialogbetrieb (time sharing)
• Interaktion zwischen dem Nutzer und dem Betriebssystem
• Erfordert (G)UIs
• Echtzeitbetrieb (real time system)
• Harte Echtzeit (hard deadlines) – Reaktionszeit darf nicht überschritten
werden
• Weiche Echtzeit (soft deadlines) – Gewisse Toleranzen sind erlaubt.
• Einsatzbeispiele: Robotik (hart), Multimedia-Anwendungen (weich)
© 2018-21 Jörg Ott | GBS | IN 0009 18
Zweck und Ziele von Betriebssystemen
• Zweck
• General Purpose vs. Special Purpose
• Bedeutung?

• Ziele: nicht alle gleichzeitig zu erreichen


• Hohe Auslastung
• Kurze Antwortzeiten
• Geringer Energieverbrauch
• Beispiele?

© 2018-21 Jörg Ott | GBS | IN 0009 19


Historische Entwicklung
Die Betriebssystementwicklung spiegelt sich in
Betriebssystem-Generationen wider:
1. Generation • Arbeiten an leerer Rechenanlage
1945 - 1955 • z.B. Zuse Z3

2. Generation • Stapelbetrieb ohne parallele Verarbeitung


1955 - 1965 • z.B. TR4

3. Generation • Mehrprogrammbetrieb, Spooling von Aufträgen auf


Platten, Dateisystem, Dialogbetrieb
1965 - 1980 • z.B. Multics, Unix V6, DEC VMS

4. Generation • PC, graphische Benutzungsoberflächen, Vernetzung,


Multimedia
ab 1980 • z.B. Windows, MacOS, Linux

5. Generation • Eingebettete Systeme, Chipkarten, Mobilität, Ubiquität


• Cloud Computing, Cluster Computing, Grid Computing
ab 2000 • z.B. Android, iOS
© 2018-21 Jörg Ott | GBS | IN 0009 20
Typen von Betriebssystemen
• Server-Betriebssysteme
• SuperMUC, MPI
• Dedizierte BS für Datenzentren

• Server- und Desktop-Betriebssysteme


• Linux, Windows, MacOS

• Mobile Betriebssysteme
• Android, iOS usw.

• Eingebettete Betriebssysteme
• QNX, L4 (embedded), PikeOS, TinyOS, RTOS, RIOT
• Ggf. Echtzeit-fähig

© 2018-21 Jörg Ott | GBS | IN 0009 21


Grundlegende BS-Konzepte
• Erste Runde: eine Übersicht über einige wichtige Konzepte
• Im Laufe der LV vertieft

• Grundlegende Konzepte
• Ressourcen (Betriebsmittel) und ihre Klassifikation
• Prozess als Abstraktion des Prozessors
• Datei als Abstraktion des Speichers
• Betriebssystem-Modi
• Systemaufrufe als Schnittstelle zwischen Anwendungsprogramm und
Betriebssystem

© 2018-21 Jörg Ott | GBS | IN 0009 22


Klassifikation von Ressourcen
• Anzahl der Nutzungen • Zentrale Ressourcen
• Einmal benutzbar • Prozessoren (CPUs,
• Wiederholt benutzbar Rechnerkerne)
• Arbeitsspeicher
• Parallelität • Periphere Ressourcen
• Parallel benutzbar • Kommunikationseinheiten
(uneingeschränkt) • Speichereinheiten
• Exklusiv benutzbar • Weitere Unterscheidungsmerkmale
• Beschränkt parallel benutzbar • Aktive vs. passive Ressourcen
• Hardware- vs. Software-
• Dauerhaftigkeit Ressourcen
• Unterbrechbar • …
• Ununterbrechbar

© 2018-21 Jörg Ott | GBS | IN 0009 23


Prozesse
• Definition Prozess
• Ein Prozess ist ein Programm in Ausführung
• Programm ist eine passive Einheit, Prozess eine aktive Einheit
• Ein Programm kann in mehreren Prozessen (Instanzen des
Programms) ausgeführt werden:
• z.B. zwei Instanzen von Microsoft Word.
• Ein System besteht aus einer Menge von Prozessen.
Bild: System mit parallelen Aktivitäten: Prozessen (z.B. 2x Editor)

© 2018-21 Jörg Ott | GBS | IN 0009 24


Prozesse
• Definition Prozess: Fortsetzung
• Ein Prozess benötigt Ressourcen, um seine Aufgabe zu erfüllen.
• Ressourcen sind u.a. eine CPU, Speicher, Ein- Ausgabegeräte oder auch
Dateien
• Konzeptuell besitzt jeder Prozess seine eigene CPU
• In Realität muss sich der Prozess die CPU mit den anderen Prozessen
teilen: dies ist die Prozessorverwaltungsaufgabe des Betriebssystems
Bild: Abstrakte Sicht eines Prozesses und reale Umsetzung

© 2018-21 Jörg Ott | GBS | IN 0009 25


Prozesse
• Definition Prozess: Fortsetzung
• Jeder Prozess besitzt einen eigenen Prozessadressraum
• Virtueller Adressraum ist eine Abstraktion des physischen Speichers
• Beinhaltet Programmcode und Daten.
• Adressräume verschiedener Prozesse sind von der Hardware
gegeneinander abgeschottet.
• Prozesse teilen sich den physischen Speicher, der vom
Betriebssystem verwaltet wird.
Bild: virtueller vs. realer Adressraum

© 2018-21 Jörg Ott | GBS | IN 0009 26


Sequenzielle und parallele Prozesse
• Ein Sequenzieller Prozess
• Besitzt einen Kontrollfluss (engl. thread) mit einen Befehlszähler (engl.
program counter).
• Führt die Instruktionen seines Programms sequentiell aus.
• Ein Multi-Threaded-Prozess
• Besitzt mehrere Kontrollflüsse (Threads)
• Jeder Thread hat seinen eigenen Befehlszähler und weitere Register
• Jeder Thread besitzt seinen eigenen Stack.
Bild: Prozess mit Threads

© 2018-21 Jörg Ott | GBS | IN 0009 27


Dateien und Dateisysteme
• Beispiel Dateisystemstruktur

Aktuelles Arbeitsverzeichnis

Quelle: Modern Operating Systems. Andrew S. Tanenbaum and Herbert Bos. 4th edition Pearson, 2015, Seite 277
© 2018-21 Jörg Ott | GBS | IN 0009 28
Dateien und Dateisysteme
• Prinzip: “Everything is a file” (Unix / Linux)
• Dateien und Verzeichnisse
• Auch auf verschiedenen Gerätetypen werden gleich behandelt und
adressiert
• /home/jo /mnt/media
• Ein- / Ausgabegeräte
• Tastatur, Maus, andere Peripheriegeräte
• Character Special Files
• Direkter Zugriffs auf Festplatten, CDs, DVDs, USB-Sticks, …
• Block Special Files
• /dev
• Pipes
• Verbindung zur Kommunikation zwischen zwei Prozesses
• Benannt (named pipes, z.B. /tmp/talk-to-me) vs. unbenannt
• $ grep ”Lastname” students.txt | sort | uniq –c
• Systemzustand (Linux)
• /proc
© 2018-21 Jörg Ott | GBS | IN 0009 29
Dateien und Dateisysteme
• Gemeinsame Abstraktion durch das Betriebssystem
• File Descriptor: Referenz auf eine Datei für Ein-/Ausgabe
• Allgemein: open, close, read, write, …
• Spezifische Steuerung: iotcl, …

• Beispiel

© 2018-21 Jörg Ott | GBS | IN 0009 30


Zusammenfassung vom 4.11.
• Betriebssysteme sind Bestandteil eines Rechensystems
• Unterstützen unterschiedliche Betriebsarten
• General purpose vs. special purpose

• Zwei wesentliche Aufgaben


• Abstraktion (von Hardware)
• Verwaltung von Betriebsmitteln

• Grundlegende Konzepte
• Klassifikation von Ressourcen
• Prozesse: Instanzen von Programmen
• Dateisystem
• Betriebsmodi: User vs. Kernel Mode
• Systemaufrufe (Systemcalls)

© 2018-21 Jörg Ott | GBS | IN 0009 31


Betriebssystem-Modi
• Ziel: Schutz des Betriebssystems vor Programmierfehlern
und Angriffen
• Lösungsansatz: Unterschiedliche Berechtigungen durch
Arbeitsmodi
• Benutzermodus (User Mode/Space)
• Kein direkter Hardware-Zugriff, Zugriff nur über das BS.
• Keine privilegierten Befehle, wie z.B. Ein-Ausgabe
• Kein oder nur lesender Zugriff auf Systemcode oder -daten
• Zugriff nur auf virtuelle Adressen
→Anwendungen laufen im Benutzermodus.
• Systemmodus (Kernel Mode/Space)
• Privilegierter Modus, alle ausführbaren Maschinenbefehle
• Privilegierte Befehle, z.B. direkter Hardware-Zugriff.
• Exklusiver Zugriff auf Systemcode und -daten.
→Der Betriebssystemkern läuft im Systemmodus.
© 2018-21 Jörg Ott | GBS | IN 0009 32
Betriebsystem-Modi
• Architekturbild mit Modi

© 2018-21 Jörg Ott | GBS | IN 0009 33


System-Aufrufe (Systemcalls)
• Aufgabe
• Bereitstellen einer Schnittstelle, so dass Anwendungen BS-Dienste
nutzen und darüber Zugriff auf die Hardware erhalten können.

• Lösung
• Definition einer Menge von Diensten, das sind die Systemcalls (grob
vergleichbar mit Methodenaufruf).
• Systemcalls werden typischerweise nicht direkt in Anwendungen
verwendet, sondern der Aufruf erfolgt über Systembibliotheken
• z.B. libc
• Bibliotheken werden zum Anwendungsprogramm hinzugebunden
(Aufgabe des Linker/Loader).

© 2018-21 Jörg Ott | GBS | IN 0009 34


Beispiele für Systemcalls
• Dateimanagement
• open, close, read, write

• Prozessmanagement
• fork, waitpid, exit

• Verzeichnismanagement
• mkdir, rmdir, link, unlink, mount, umount

• Gerätemanagement
• open, close, ioctl, fcntl

• Kommunikation
• send, recv, connect, bind, listen, accept

© 2018-21 Jörg Ott | GBS | IN 0009 35


Zugriff auf Systemcalls aus dem User Mode
• Nutzen von Systemcalls aus dem User Mode
• Beim Booten befindet sich das System im Kernel Mode.
• Bei Ausführung eines Benutzerprozesses befindet sich das System im
Schlichter,
UserTU München
Mode. 2.1. BETRIEBSSYSTEM - ÜBERBLICK
• Bei Zugriff auf einen BS-Dienst (z.B. I/O), erfolgt ein Systemcall, der
mit einem Wechsel in den Kernel Mode verbunden ist.

Benutzerprozess
Ausführung System Rückkehr von
Benutzermodus
Benutzerprozess Aufruf System Aufruf

Betriebssystemkern
Ausführung
Systemmodus
Systemdienst

• ©Struktureller
2018-21 Jörg Ott | GBS | IN 0009
Aufbau 36
Schlichter, TU München 2.2. BETRIEBSSYSTEM-ARCHITEKTUR

Systemcall: Grober Ablauf


• Anwendung ruft main ( ) {
--------------
Bibliotheksfunktion auf,
printf ("hello ); Anwendung
z.B. printf() --------------

User Mode
}
• Bibliotheksfunktion ruft
dus
den eigentlichen
-------------
Systemcall auf. printf erledigt Formatierung
-------------- Bibliotheksfunktion
• Der Systemcall wird Systemaufruf
durch Trap-Instruktion
realisiert: Unterbrechung
-------------
des aktuellen Ablaufs
Kernel Mode

write (1, "hello , 5); Betriebssystemkern


und Sprung in BS-Kern. dus --------------

• Der Systemcall wird im


Hardware
Kernel Mode ausgeführt. Z.B. Zugriff auf Festplatte

© 2018-21 Jörg Ott | GBS | IN 0009 37


rundlegende Betriebssysteme-Konzepte
Systemcall: Beispiel Technische
Universität
München
frufe – Systemcalls
count = read (fd, buf, nbytes)
blauf: (Niedrige Adressen) 0x00000000

ndung ruft
1.
theksfunktion auf, z.B.
f.
2. Rückkehr zum aufrufenden Programm
9
Aufruf Kernel Bibliotheksfunktion read
3. Setzen der Nummer für Systemaufruf read 5
theksfunktion ruft den
4.
lichen Systemcall auf.
10

Benutzermodus

ystemcall5.wird durch
4
Inkrementierung Stack Pointer 11

Aufruf Bibliotheksfunktion read


6.
Befehl realisiert: Push fd 3
Aufruf von read
im Programm

brechung 7.des Push &buffer


Push nbytes
2

llen Ablaufs
8. und
g in BS-Kern. 6

9. 0xc0000000

ystemcall wird im
10.
7 8
Kernelmodus Syscall
Dispatch
(Betriebssystem) Handler
l Mode ausgeführt.
11. (Hohe Adressen) 0xffffffff

Abbildung: Ablauf eines Systemcalls (Quelle: A. Tanenbaum)


kert © 2018-21 Jörg Ott | GBS | IN 0009 Kapitel 01 — Grundlagen 3822 / 1
Betriebssystem-Architekturen
• Im Laufe der Zeit haben sich unterschiedliche Architekturen
für Betriebssysteme entwickelt

• Übersicht
• Monolithische Systeme (monolithic systems)

• Geschichtete Systeme (layered systems)

• Mikrokernel-Systemen (microkernels)

• Client-Server-Systeme

• Virtuelle Maschinen (virtual machines)

© 2018-21 Jörg Ott | GBS | IN 0009 39


Monolithisches System
• BS umfasst umfangreiche Menge von Funktionen
• Zusammenfassung der Funktionen in einem BS-Kern
• Alle Treiber sind innerhalb des Kernels implementiert.
• Betreten des Kerns durch Systemaufrufe (Systemcalls).
• Vielen Prozeduren, zu einem Executable gebunden
• Das BS wird als ein (großes) Programm ausgeführt
• z.B. Linux 4.1 > 20 Mio Lines of Code,
• Anmerkung: 5 Mio LoC: 1000 Bücher à 1000 Seiten à 50 Zeilen
• Einige Konsequenzen
• Sehr flexibel: Prozeduren können sich wechselseitig aufrufen
• Unübersichtlich wegen fehlender Struktur, Probleme bei der Wartung
• Wenig resilient: Crash in einer Prozedur führt zu Crash des
Programms

• Häufig: Minimale Struktur


© 2018-21 Jörg Ott | GBS | IN 0009 40
Beispiel monolithisches BS: Unix / Linux

© 2018-21 Jörg Ott | GBS | IN 0009 41


Monolithisches System
• Eigenschaften
• Das Betriebssystem arbeitet vollständig im Kernel Mode
• Der BS-Kern hat hohe Ablaufpriorität
• Der BS-Kern ist permanent im Arbeitsspeicher
• Ein monolithischer BS-Kern besitzt (oft) wenig Struktur
• Dadurch meist schwer wart- und erweiterbar
• Varianten: Ziel u.a. bessere Wartbarkeit
• Modularität: Erweiterbarkeit
• Neue Module können geladen und die Funktionalität erweitern.
• Portierbarkeit: Übertragen von Software auf andere Hardware
• Innerhalb des Betriebssystem werden Basisfunktionen bereitgestellt.
Aufwandreduktion: nur diese Basisfunktionalität muss auf eine neue
Hardwarearchitektur portiert werden
• Geschichtete Systeme (Layers):
• Hierarchie von Schichten oder Ringen. Vereinfachung durch Abstraktion

© 2018-21 Jörg Ott | GBS | IN 0009 42


Mikrokerne
• Motivation
• Fehler in Software: 2-10 Fehler pro 1.000 Lines of Code
• 5 Mio LoC: 10.000 - 50.000 Fehler (Kernel Bugs)
• Linux-Kern: > 20 Mio LoC, d.h. 40.000 - 200.000 Bugs!
• Ziel: kleiner BS-Kern
• Beispiel MINIX: 12.000 LoC

• Idee
• BS in kleine Module aufteilen = eigenständige Systemprozesse
• Nur ein Modul, der Mikrokern, läuft im Kernel Mode
• Kleinerer Kern: leichter wartbar.
• Isolation von Fehlern

• Beispiele: L4, PikeOS, Mach, QNX, MINIX

© 2018-21 Jörg Ott | GBS | IN 0009 43


Mikrokerne
• Mikrokern-Ansatz
• Bietet nur noch Basismechanismen wie Prozesskommunikation (IPC)
und CPU-Zuteilung (Scheduling)
• Subsysteme sind als Systemdienste im User Mode implementiert,
keine Privilegien
• Beispiele: Dateisystem, Speicherverwaltung oder Prozessverwaltung
• Dadurch ist der Kern selbst leichter absicherbar, ggf. beweisbar
• Einzelne Subsysteme können so auch einfach ausgetauscht werden

• Systemfunktionen werden als Serverprozesse ausgeführt


• Benötigt eine Anwendung einen Dienst, kommuniziert sie mit dem
entsprechenden Serverprozess.
• Die Kommunikation zwischen Diensten erfolgt nicht direkt sondern
über den Betriebssystem-Kern mittels IPC: Client-Server-Prinzip

• Vorteile? Nachteile?
© 2018-21 Jörg Ott | GBS | IN 0009 44
5 Betriebssystem-Architekturen
Mikrokerne
Technische
Universität
München
krokerne

Benutzer-
Memoryserver Netzwerkserver
programm
Benutzermodus
(User-Mode)

Prozessserver Fileserver Displayserver


Antwort

Antwort

Antwort
Anfrage

Anfrage

Anfrage
Antwort

Antwort

Antwort
Anfrage

Anfrage

Anfrage
Systemmodus
Mikrokern
(Kernel-Mode)

Hardware

Abbildung: Übersicht über Mikrokernel Architektur

© 2018-21 Jörg Ott | GBS | IN 0009 45


C. Eckert Kapitel 01 — Grundlagen
Systemprogrammierung
• Die BS-Programmierung zählt zum Bereich der
Systemprogrammierung = Erstellung von System-Software
• Definition: Systemprogrammierung
• Systemprogrammierung befasst sich mit der Konstruktion von
Algorithmen für ein Rechensystem, die die Bearbeitung und
Ausführung von Benutzerprogrammen unter vorgegebenen
Qualitätsgesichtspunkten organisieren, d.h. steuern und
kontrollieren und zum Teil selbst durchführen.
• System-Software
• Programme, die Dienste für (Anwendungs)-Programme anbieten.
• Hardwarenahe Programmierung: Assembler, C, C++
• Auf effiziente Ausführung optimiert
• Beispiele für System-Software
• Betriebssysteme, Geräte-Treiber
• Compiler, Linker, Loader
© 2018-21 Jörg Ott | GBS | IN 0009 46
BS, Assembler, Maschinenebene
• BS sind Dienstprogramme, die den Zugriff auf die Hardware
erleichtern

• BS müssen effizient sein, hardware-nah programmiert

• D.h.: Betriebssysteme sind sehr eng mit der Hardware, auf


der sie ausgeführt werden, verbunden
• Auf der Hardware sind nur Maschinenprogramme ausführbar.
• Die hardwarenahe Programmierung ist fehleranfällig und aufwändig.
• Eine abstraktere und damit einfachere, maschinennahe Ebene für die
Programmierung liefert der Assembler.

© 2018-21 Jörg Ott | GBS | IN 0009 47


BS, Assembler, Maschinenebene
• Definition: Maschinenschnittstelle, Instruction Set
Architecture (ISA)
• Die ISA ist der Befehlssatz eines Prozessors, also die Menge der
Maschinenbefehle.
• Unterscheidung zwischen RISC- (Reduced Instruction Set Computer)
und CISC- (Complex Instruction Set Computer) Architekturen
• Definition: Assembler
• Assembler ist eine maschinennahe (konkrete) Programmiersprache.
Sie ist an die ISA der Zielarchitektur angelehnt. Durch Verwendung
von Namen und symbolischen Adressen wird die Nutzung der ISA
vereinfacht.
• Achtung: Als Assembler wird auch das Systemprogramm bezeichnet,
das:
• Assemblerbefehle in Maschinencode transformiert.
• Symbolischen Namen Maschinenadressen zuweist und ein
Objektprogramm erzeugt.
© 2018-21 Jörg Ott | GBS | IN 0009 48
BS, Assembler, Maschinenebene
• Vom Programm (z.B. in C) zum ausführbaren Code:
Transformationen

• Compiler
• Übersetzer von C in Assembler
• Assembler
• Übersetzer von Maschinen-
sprache in die ISA
• Linker (Binder)
• einzelne Module binden
• Liefert ausführbare Datei
(Executable)
• Loader
• Laden der gebundenen
Objekte in den Speicher

© 2018-21 Jörg Ott | GBS | IN 0009 Quelle: Tanenbaum 49


Chair of Connected Mobility
Department of Informatics
Technische Universität München

Kapitel 02

Grundlagen Betriebssysteme und Systemsoftware


Prozess- und Prozessorverwaltung

Prof. Dr.-Ing. Jörg Ott


Lehrstuhl Connected Mobility

Folien frei nach der Vorlage von Prof. C. Eckert (WS16/17, WS17/18) – danke!

© 2018-21 Jörg Ott | GBS | IN 0009 1


Fragen
• Wie werden auf einem Rechner mit einer CPU (und nur
einem Kern) mehrere Prozesse „parallel“ ausgeführt?
• Wie wird das technisch umgesetzt?

• Wie unterscheiden sich Prozesse und Threads?


• Warum sind Threads „leichtgewichtiger“?

• Wann werden welche Prozesse ausgeführt?


• Was für Strategien und Algorithmen gibt es hierzu?

© 2018-21 Jörg Ott | GBS | IN 0009 2


Ziele
• Grundlagen: Prozessor und Prozesse

• Implementierungs-Konzepte zur Verwaltung von Prozessen


und Threads.

• Algorithmen (Verwaltungsstrategien), um Prozesse der CPU


zuzuteilen
• Aufgabe des Schedulers

• Konzepte und Techniken, um Prozesse an den Prozessor


(CPU) zu binden/zu entbinden
• Aufgabe des Dispatchers

• Scheduling-Algorithmen
© 2018-21 Jörg Ott | GBS | IN 0009 3
Vom Quellcode zum Programm
• Vom Programm (z.B. in C) zum ausführbaren Code:
Transformationen

• Compiler
• Übersetzer von C in Assembler
• Assembler
• Übersetzer von Maschinen-
sprache in die ISA
• Linker (Binder)
• einzelne Module binden
• Liefert ausführbare Datei
(Executable)
• Loader (BS)
• Laden der gebundenen
Objekte in den Speicher

© 2018-21 Jörg Ott | GBS | IN 0009 Quelle: Tanenbaum 4


Erinnerung: Prozesse
• Definition Prozess
• Ein Prozess ist ein Programm in Ausführung
• Programm ist eine passive Einheit, Prozess eine aktive Einheit
• Ein Programm kann in mehreren Prozessen (Instanzen des
Programms) ausgeführt werden.
• Ein Prozess benötigt Ressourcen, um seine Aufgabe zu erfüllen.
• U.a. eine CPU, Speicher, Ein- Ausgabegeräte oder auch Dateien
• Konzeptuell besitzt jeder Prozess seine eigene CPU
• Ein sequentieller Prozess besitzt einen Kontrollfluss (thread)
• Jeder Prozess besitzt einen eigenen Prozessadressraum
• Virtueller Adressraum ist eine Abstraktion des physischen Speichers
• Enthält Programmcode und Daten
• Adressräume verschiedener Prozesse sind von der Hardware
gegeneinander abgeschottet
• Prozesse teilen sich den physischen Speicher, der vom Betriebssystem
verwaltet wird.

© 2018-21 Jörg Ott | GBS | IN 0009 5


Prozessor
• Beispiel: Intel Xeon E7-8870
• 2011
• 64-bit-Instruktionssatz

Quelle: Wikipedia
https://commons.wikimedia.org/wiki/File:Table_of_x86_Registers_svg.svg
© 2018-21 Jörg Ott | GBS | IN 0009 6
Prozessor (2)
• Beispiel: Intel 80386
• 1985
• 32-Bit-Instruktionssatz
• Register
• Steuern u.a.
• Betriebsmodus
• Speichernutzung
• Programmablauf
• Interruptverhalten
• Zeigen Status von
Operationen an
• Arithmetik, Vergleiche

Siehe https://en.wikipedia.org/wiki/FLAGS_register,
https://en.wikipedia.org/wiki/Intel_80386
Quelle: https://commons.wikimedia.org/wiki/File:Priv_rings.svg
© 2018-21 Jörg Ott | GBS | IN 0009 https://commons.wikimedia.org/wiki/File:KL_Intel_i386DX.jpg 7
Prozess im Speicher
(stark vereinfacht) 0xFFFF…FFFF
Stack
Register der CPU
• Stack segment Lokale Variablen

• Base pointer Funktionsaufrufe

• Stack pointer

• Data Segment(s) Heap malloc ()

• Instruction Pointer Data Globale Variablen


• = Programmzähler

• Code Segment Code (Text)

0x0000…0000

© 2018-21 Jörg Ott | GBS | IN 0009 8


Prozess im Speicher (2a): Stack
Stack
main () {
int p1 = 0x30;
int p1 = 0x30
int p2 = p1+0x12;
Stack
int p2 = 0x42 int d = 0x99;
int d = 0x99 f (p1, p2);

[padding]
}
p2=42
Heap
Data
p1=30 void f (int p1, int p2) {
int a = p1;
Return-Adresse
char b [8] = ”string!”;
Code (Text) Stack-Base-Pointer int c = p2;
int a
char b [4…7] …
return;
char b [0…3] }
int c
© 2018-21 Jörg Ott | GBS | IN 0009 9
Prozess im Speicher (2b): Stack
Praxis: Übergabe der ersten 6 (Integer-)Parameter in Registern!

main () {
Stack int p1 = 0x30;
int p2 = p1+0x12;
int p1 = 0x30 int d = 0x99;
Stack
f (p1, p2);
int p2 = 0x42 …
int d = 0x99 }
Heap
[padding]
void f (int p1, int p2) {
Data Return-Adresse int a = p1;
Stack-Base-Pointer char b [8] = ”string!”;
Code (Text) int a int c = p2;
char b [4…7] …
char b [0…3] return;
int c }

© 2018-21 Jörg Ott | GBS | IN 0009 Siehe z.B. https://eli.thegreenplace.net/2011/09/06/stack-frame-layout-on-x86-64/ 10


Prozesskontext im Betriebssystem
• Untermenge des Prozesskontextes

Quelle: Tanenbaum / Bos


© 2018-21 Jörg Ott | GBS | IN 0009 11
Prozesskontext im Betriebssystem
• struct task_struct { ... }; // linux-4.19/include/linux/sched.h:
• struct thread_struct { … }; // linux-4.19/include/arch/x86/include/asm/processor.h
struct thread_struct {
/* Cached TLS descriptors: */
struct desc_struct tls_array[GDT_ENTRY_TLS_ENTRIES];
unsigned long sp;
unsigned short es;
unsigned short ds;
unsigned short fsindex;
unsigned short gsindex;
unsigned long fsbase;
unsigned long gsbase;
...
/* Fault info: */ Quelle z.B. https://www.kernel.org
unsigned long cr2;
unsigned long trap_nr;
unsigned long error_code;
/* IO permissions: */
unsigned long *io_bitmap_ptr;
unsigned long iopl;
/* Max allowed port in the bitmap, in bytes: */
unsigned io_bitmap_max;
mm_segment_t addr_limit;
unsigned int sig_on_uaccess_err:1;
unsigned int uaccess_err:1; /* uaccess failed */
...
};
© 2018-21 Jörg Ott | GBS | IN 0009 12
Parallele Prozesse, Multiprogramming
• Ein System besteht aus einer Menge von Prozessen
• Prozesse können (quasi) parallel verarbeitet werden
• Wechseln zwischen verschiedenen Prozessen (Scheduling)
• Die quasi-parallele Prozess-Verarbeitung ist die Grundlage
für das Multiprogramming

• Beispiel: Multiprogramming-Systeme
• Vier unabhängige Prozesse mit
jeweils einem eigenen Kontrollfluss.
• In Einprozessorsystemen führt die
CPU zu jedem Zeitpunkt nur einen
Prozess aus.
• Über die Zeit gesehen werden alle
Prozesse ausgeführt

© 2018-21 Jörg Ott | GBS | IN 0009 13


Warum Multiprogramming?
• Prozesse können CPU-limitiert oder I/O-limitiert sein
• Wenn ein Prozess einen Anteil p seiner Zeit auf Ein-/Ausgabe wartet,
ist die CPU-Auslastung probabilistisch als 1 – pn bei n Prozessen

Grobe(!) Approximation

Quelle: Tanenbaum, Bos


© 2018-21 Jörg Ott | GBS | IN 0009 14
Beispiel
• cat rooms1.txt rooms2.txt rooms3.txt | grep -i FMI

© 2018-21 Jörg Ott | GBS | IN 0009 15


Prozess-Zustände (1)
resign

add retire
rechenwillig assign rechnend
ready running

block
ready

wartend
blocked

swap out
swap in
ausgelagert
swapped out

© 2018-21 Jörg Ott | GBS | IN 0009 16


resign

Prozess-Zustände (2) add


rechenwillig assign rechnend
retire

block
ready

wartend

swap out
swap in

• Zustandsübergänge
ausgelagert

add Ein neu erzeugter Prozess wird zu der Menge der


rechenwilligen Prozesse hinzugefügt
assign Als Folge eines Kontextwechsels wird dem Prozess die
CPU zugeordnet
block Aufgrund eines I/O-Aufrufs oder einer Synchronisations-
operation wird der Prozess wartend gesetzt
ready Nach Beendigung der angestoßenen Operation wechselt
der Prozess in den Zustand rechenwillig
resign Dem rechnenden Prozess wird die CPU entzogen
retire Der aktuell rechnende Prozess terminiert
swap out Der Prozess wird auf die Festplatte ausgelagert
swap in Ein ausgelagerter Prozess wird in den Speicher gebracht
© 2018-21 Jörg Ott | GBS | IN 0009 17
Prozess vs. Thread
• Prozess: Programm in Ausführung
• Benutzt Ressourcen (CPU, Speicher, Dateien, Geräte usw.)
• Hat einen Kontrollfluss (definiert durch die Instruktionen des
Programms)

• Ressourcen und Kontrollfluss sind unabhängige Konzepte


• Lassen sich trennen

• Ein Prozess gruppiert und verwaltet Ressourcen


• Ein Thread definiert einen Kontrollfluss

• Bisher: Prozess hat genau einen Thread

© 2018-21 Jörg Ott | GBS | IN 0009 18


Threads
• Definition: Thread
• Ein Thread wird betrachtet als
eine Abstraktion eines physischen
Prozessors
• Threads repräsentieren neben-
läufige Ausführungspfade eines
Rechensystems
• Ein Prozess besitzt mindestens
einen Thread

Adressraum
• Ein Multi-Threaded-Prozess
besitzt mehrere Kontrollflüsse
• Threads eines Prozesses
teilen sich dessen Adressraum
• Jeder Thread besitzt seinen
eigenen Befehlszähler

© 2018-21 Jörg Ott | GBS | IN 0009 Quelle: Tanenbaum, Bos 19


Prozesse vs. Threads (1)
• Threads sind Aktivitätsträger
• Thread-spezifische Informationen, der Thread-Kontext:
• Program Counter
• Registerwerte (z.B. Variablen, etc.)
• Stack zur Verwaltung von Unterprogrammaufrufen
• Threads können auch in verschiedenen Zuständen sein
• (erzeugt,) rechenwillig, rechnend, wartend, terminiert
• Bild: Thread-Zustände

© 2018-21 Jörg Ott | GBS | IN 0009 20


Prozesse vs. Threads (2)

Quelle: Tanenbaum / Bos

© 2018-21 Jörg Ott | GBS | IN 0009 21


Prozesse vs. Threads (3)
• Thread-Kontext muss gesichert werden, sobald einem
Thread die CPU entzogen wird
• Zustandsübergang von rechnend nach wartend oder rechenwillig
• Prozesse gruppieren Ressourcen
• Adressraum inkl. Programmcode und Daten
• Gemeinsam nutzbare Ressourcen für alle Threads eines Prozesses
• Globale Variablen, offene Dateien, Kind-Prozess-Deskriptoren, Alarme bzw.
Interrupts (signal handler).

Quelle: Tanenbaum / Bos


© 2018-21 Jörg Ott | GBS | IN 0009 22
Gründe für Multi-Threading
• Overhead
• Ein Thread ist ein „lightweight“ Prozess (u.a. gemeinsamer
Adressraum).
• Einfache Kommunikation zwischen Threads eines Prozesses über
gemeinsamen Adressraum.
• Der Aufwand, einen Thread innerhalb eines Prozesses zu erstellen
(erzeugen), ist wesentlich geringer als einen Prozess zu erzeugen
(Faktor 10-100).
• Threads können wesentlich schneller ihren Kontext wechseln.
Was heißt das?

• Performance
• Multi-Threading ermöglicht die quasi-parallele Ausführung von I/O
intensiven und CPU-intensiven Bereichen eines Prozesses.
Warum quasi-parallel möglich?
• Echt parallele Ausführung von Threads auf mehreren CPUs/Cores.

© 2018-21 Jörg Ott | GBS | IN 0009 23


Beispiel: Multi-Threaded Word-Processor
Formatierung
(Hintergrund,
rechenintensiv)

Nutzerinteraktion Quelle: Tanenbaum / Bos


Speicher
(interaktiv) (I/O-intensiv)

© 2018-21 Jörg Ott | GBS | IN 0009 24


Beispiel: Multi-threaded Web-Server
• Ein Dispatcher-(Verteiler-) Thread erstellt auf Anfragen neue Server-
Threads.
• Mehrere Server-Threads (dynamisch erzeugt) bearbeiten eine Anfrage.

Quelle: Tanenbaum, Bos

© 2018-21 Jörg Ott | GBS | IN 0009 25


Beispiel: Multi-Threaded Web-Server

Dispatcher-Thread Worker-Threads:

while (TRUE) { while (TRUE) {


get_next_request (&buf); wait_for_work (&buf); // block
handoff_request (&buf); look_for_page_in_cache (&buf, &page);
} if (page_not_in_cache (&page));
read_page_from_disk (&buf, &page);
return_page (&page);
}

© 2018-21 Jörg Ott | GBS | IN 0009 26


Implementierung von Prozessen
• Kernel-Datenstruktur: Process Control Block (PCB)
• Informationen für die Prozessverwaltung (engl. process management)
• Registerinhalte (inkl. Programm Counter, Stack Pointer, Statusregister, etc.)
• Prozess Zustand (z.B. wartend, rechnend, etc.)
• Rechnend: Angabe der zugehörigen CPU
• Wartend: Angabe des Ereignisses, auf das der Prozess wartet
• Priorität
• Eindeutige Process ID (PID)
• Parent PID (PPID), Identität des Eltern-Prozesses
• Process Group ID (PGID)
• Informationen für die Speicherverwaltung (engl. memory management)
• Pointer zu Code-, Daten-, und Stack-Segment
• Informationen beinhalten Anfang und Größe der entsprechenden Segmente

• Informationen für die Dateiverwaltung (engl. file management)


• Root Verzeichnis
• File Deskriptoren: Datenstrukturen, die geöffnete Dateien beschreiben
• Benutzer (User) und Gruppen ID (UID, GID)
© 2018-21 Jörg Ott | GBS | IN 0009 27
Implementierung von Prozessen
• BS verwaltet alle Prozesse in Prozesstabellen
• Eine Prozesstabelle ist eine verkettete Liste von PCBs
• Separate Listen für die verschiedenen Prozesszustände
• Run Queue: (Ready Queue) Linux rechenwillige Prozesse (Linux)
• Wait Queue: Verwaltet unter Linux wartende Prozesse
• Warum?
Prozessidentifikation
Rechnend
Registerzustand

Scheduling Information (z.B.


Priorität)
Rechenwillig
Adressrauminformation
Ready-Queue
Sonstiges

Wartend nächster PCB

Prozesskontrollblock PCB
© 2018-21 Jörg Ott | GBS | IN 0009 28
BS-Dienste zur Prozessverwaltung
• Dienste zur Erzeugung eines Prozesses

• Dienste zur Terminierung von Prozessen

• Strategien zur Prozessorzuteilung (Scheduling)


• Wählt den nächsten auszuführenden Prozess aus der Menge der
rechenbereiten Prozesse aus

• Dienste zur Prozessor-Anbindung (Dispatching)


• Kontext- und Zustandswechsel umsetzen

© 2018-21 Jörg Ott | GBS | IN 0009 29


Erzeugung von Prozessen: Auslöser
• Prozesserzeugung während der Systeminitialisierung
• Erzeugung von Vordergrundprozessen
• Interagieren mit dem Benutzer
• Erzeugung von Hintergrundprozessen
• Dämonen (engl. daemons), spezielle Systemprozesse.
• Langlebige, passive Systemprozesse, die durch Ereignisse aktiviert werden.
• Frage: Beispiele für Hintergrundprozesse?

• Prozesserzeugung durch andere Prozesse


• Auslagerung der Arbeit auf mehrere Prozesse
• Beispiel: Server erzeugt für jede Client-Anfrage einen neuen Prozess
• Prozesserzeugung durch Benutzer
• Ausführung eines Kommandos in der Shell; Doppelklick auf ein Icon
• Prozesserzeugung durch das BS (Batch-Systeme)
• Das Betriebssystem erstellt neue Prozesse, um eine Menge von
Aufgaben oder Daten zu verarbeiten.
© 2018-21 Jörg Ott | GBS | IN 0009 30
Erzeugung von Prozessen: Dienste
• POSIX-Systemcall: pid_t fork ()
• Eltern-Prozess erzeugt exakte Kopie (Kind-Prozess) inkl. Code, Data
• Kopie des Speicherabbildes des Elternprozesses
• Ausnahme copy-on-write (COW) Memory
• Jeder Prozess erhält bei Erzeugung eine Identifikation:
Process-Identifier (PID)
• Rückgabewert von fork unterscheidet Eltern- und Kindprozess
• Elternprozess ehält die PID des Kindprozesses als Ergebnis
• Kindprozess erhält den Wert 0
• Prozess kann die eigene PID erfragen mittels getpid()
• Erfragen der PID des Elternprozesses mittels getppid()
• Kind erbt unter anderem Filedeskriptoren zu offenen Dateien
(z.B. stdin, stdout, stderr)
• Falls der Kind-Prozess eigenen Code etc. benötigt, so führt das Kind
exec{ve|le|...} aus, um das Speicherabbild zu überschreiben
• Beide Prozesse sind unabhängig voneinander
• Änderungen in einem nicht sichtbar für den anderen Prozess
© 2018-21 Jörg Ott | GBS | IN 0009 31
Prozessterminierung
• Normale Beendigung (freiwillig)
• Das Programm terminiert durch das Aufrufen eines Systemcalls
• Beispiele: void exit (int status), return status; aus main()
• Vorzeitige Beendigung bei einem durch den Prozess
erkannten Fehler (freiwillig)
• Beispiel: Das Programm erkennt, dass eine Datei Datei nicht existiert
• Nutzung von exit wie oben, aber mit Fehlercode
• Vorzeitige Beendigung bei einem fatalem Fehler, erkannt
durch das BS
• Verursacht durch einen Fehler im Programm
• Beispiel: Zugriff auf nicht existierenden Speicherbereich (Segmentation
Fault)
• Terminierung durch einen anderen Prozess
• Beispiel: Senden einen Signals durch die Funktion
int kill (pid_t process_id, int signal);

© 2018-21 Jörg Ott | GBS | IN 0009 32


nste der Prozessverwaltung (Unix)
Prozesshierarchien
Technische
Universität
München
ie

• Nach Initialisierung aller


Subsysteme des Kernels wird der
archie unter UNIX: init
erste Userspace-Prozess init PID=1
itialisierung aller Subsysteme des Kernels,
erzeugt PPID=0

r erste Userspace Prozess


• init erstellt init
einen erzeugt.
Login-Prozess
ellt einen Prozess pro Bildschirm,
pro „Terminal“, der das der einen
Einloggen sshd bash httpd
ur Verfügung stellt.
ermöglicht PID=2
PPID=1
PID=3
PPID=1
PID=4
PPID=1
• Der
in erzeugt eineLogin-Prozess erzeugt
Shell, die wiederum eine
weitere
e erzeugt. Shell, die wiederum weitere
Prozesse erzeugen kann ls firefox ps
ozess inkl. Kinder formen eine PID=5 PID=6 PID=7
• Jeder Prozess inkl. seiner Kinder PPID=3 PPID=3 PPID=3
gruppe (durch
formendie eine
PGIDProzessgruppe
gekennzeichnet).(durch
er-Prozess der Prozessgruppe
die PGID bildet dabei
gekennzeichnet).
zessgruppen
• DerLeader.
Eltern-Prozess der firefox child
PID=8
Prozessgruppe bildet dabei den PPID=6

Prozessgruppen-Leader PGID=6

© 2018-21 Jörg Ott | GBS | IN 0009 33


Kapitel 03 — Prozess- und Prozessorverwaltung 17 / 1
Beispiel (1)
• Der Eltern-Prozess erzeugt ein Kind mit dem Systemcall
fork
• Der Kind-Prozess erhält eine neue PID
• Die PPID des Kindes verweist auf die PID des Eltern-Prozesses
• Der Rückgabewert hilft, um zwischen dem Eltern- und Kind-
Prozess zu unterscheiden
• Elternprozess erhält die PID des Kind-Prozesses
• Kind erhält 0 als Rückgabe
• Beide Prozesse setzen ihre Ausführung nach dem
Systemcall fork fort
• Das Kind kann mit exec eine Binärdatei laden um, sein
Speicherabbild zu ersetzen

© 2018-21 Jörg Ott | GBS | IN 0009 34


der Prozessverwaltung Technische
Universität
München

Beispiel (2)
eugung unter UNIX 1 static int mydata = 111;
2 int main(int argc, char *argv[]) {
ss erzeugt ein Kind mit
Frage: 3 pid_t cpid = fork();
fork. 4

ozess erhält eineWert


neue(mydata)
PID. 5 switch (cpid) {
Welcher
6 case -1: /* Error */
s Kindeswird
verweist auf die PID
ausgegeben? 7 perror("Cannot create child\n");
ozesses. 8 return EXIT_FAILURE;
case 0: /* Child */
ert hilft, um zwischen dem 9
10 printf("Hello from child process with PID=%d\n",
-ProzessZusatzfrage:
zu unterscheiden. 11 getpid());
die PID des Kind-Prozesses. 12 mydata = mydata * 3;
13 break;
0 als Rückgabe.
In welcher Reihenfolge
14 default: /* Parent */
wird Ausführung
setzen ihre das printf () 15 printf("Hello from parent process with PID=%d,
In Zeile 19 ausgegeben? 16 my child’s PID=%d\n", getpid(), cpid);
mcall fork fort. 17 }
mit execLässt
einesich
Binärdatei
das steuern?
18 /* Print by both parent and child process */
19 printf("PID=%d: mydata=%d", getpid(), mydata);
Speicherabbild zu ersetzen. 20 return EXIT_SUCCESS;
21 }
a) wird ausgegeben?
© 2018-21 Jörg Kapitel
Ott | GBS
03 |—INProzess-
0009 und Prozessorverwaltung 18 /35
1
Prozesshierarchien: Zombies
• Der Eltern-Prozess kann mit den Systemcalls wait oder
waitpid darauf warten, dass der Kind-Prozess terminiert.
• Der Eltern-Prozess blockiert (einfügen in die Wait-Queue), bis der
Kind-Prozess terminiert.
• Nach der Beendigung des Kindes, kann der Elternprozess den Grund
der Terminierung erfragen
• Zombies
• Wenn der Kind- vor dem Eltern-Prozess terminiert, entsteht ein sog.
Zombie-Prozess
• Wenn ein Kind-Prozess so terminiert, dann wird
• Der Speicher des Prozesses de-allokiert und
• Der Exit-Status in den PCB geschrieben und bleibt erhalten: Zombie
• Sobald der Elternprozess den Exit-Status mit wait (waitpid) gelesen hat,
wird der Zombie entfernt
• Zombie-Prozesse führen keinen Code mehr aus, belegen aber noch Platz in
der Prozess-Tabelle

© 2018-21 Jörg Ott | GBS | IN 0009 36


Prozesshierarchien: Waisen
• Waisen (engl. orphans) entstehen, wenn der Eltern- vor dem
Kind-Prozess terminiert.
• Kind-Prozess wird dann vom Init-Prozess adoptiert : PPID=1.

• Ein Waisen-Prozess kann anschließend zum Dämonen


(Hintergrundprozess) werden
• Dafür muss der Prozess sich von der Gruppen-ID und Benutzer-ID
lösen
• Gegebenenfalls alle offenen Filedeskriptoren (stdin, stdout, stderr)
umleiten
• Mehr zu Daemon-Prozessen später

• Notiz: bei Windows gibt es keine Prozesshierarchien


• Jedem Prozess wird bei Erzeugung ein Handle zugeordnet
• Kann an andere Prozesse übergeben werden

© 2018-21 Jörg Ott | GBS | IN 0009 37


Prozessorverwaltung
• Aufgaben werden auf Dispatcher und Scheduler aufgeteilt
• Dispatcher: Realisiert Prozess-Zustandsübergänge von rechenwillig
nach rechnend
• Die Ausführung von Prozess A muss unterbrochen werden, um die
Ausführung eines anderen Prozesses B zu ermöglichen
• Scheduler: Wählt einen Prozess aus der Liste der rechenwilligen
Prozesse (Run Queue).
• Wahl des nächsten Prozesses durch Scheduling-Algorithmen getroffen.
Zeit
Zuweisung
A hat CPU CPU an A A hat CPU
Prozess A

Unterbrechung
BS-Kern
hat CPU
BS-Kern
BS-Kern
Unterbrechung
hat CPU

B hat CPU
Prozess B
Zuweisung
CPU an B
© 2018-21 Jörg Ott | GBS | IN 0009 38
Dispatching (1)
Aufgaben des Dispatchers (meist Bestandteil des Schedulers)

• Bei den Zustandsübergängen zwischen rechnend und


rechenwillig finden Kontextwechsel (engl. context switch)
statt

• Der Dispatcher implementiert den Wechsel

• Der Dispatcher entzieht dem rechnenden Prozess/Thread


die CPU und teilt sie einem anderen rechenbereitem
Prozess/Thread zu

© 2018-21 Jörg Ott | GBS | IN 0009 39


Dispatching (2)
1. Ändert den Zustand des
rechnenden Prozesses zu
wartend oder rechenbereit

2. Sichert den Kontext des


zuvor rechnenden
Prozesses/Threads im PCB.

3. Lädt den Kontext des


rechenbereiten
Prozesses/Threads.

4. Ändert den Zustand des


rechenbereiten Prozesses
zu rechnend.
Quelle: Silberschatz

© 2018-21 Jörg Ott | GBS | IN 0009 40


Dispatching (3)
• Beachte: Je umfangreicher ein PCB, desto teurer
(d.h. aufwendiger) sind Kontextwechsel

• Threads haben einen kleineren Kontext im Vergleich zu


Prozessen
• Erinnerung: Prozesse gruppieren Ressourcen
• Threads teilen sich Ressourcen mit dem Prozess (u. a. Adressraum)

• Ein Umschalten zwischen Threads im gleichen Prozess


erfolgt deshalb sehr schnell
• Wechseln zwischen Threads verschiedener Prozesse ist
genauso teuer, wie ein Prozess-Wechsel

© 2018-21 Jörg Ott | GBS | IN 0009 41


Scheduling (1)
Aufgaben des Schedulers
• Treffen von strategischen Entscheidungen
• Welchen Prozess oder Thread, wann und wie lange an die CPU
binden
• Bei Multiprozessor-Systemen muss zusätzlich entschieden werden, an
welche CPU der Prozess gebunden wird
• Ausnutzen von typischem Prozessverhalten
• CPU-Nutzungs-Bursts wechseln sich mit I/O-Wartephasen ab
• Berücksichtigung von CPU-limitierten- und I/O-limitierten-Prozessen

Quelle: Silberschatz
© 2018-21 Jörg Ott | GBS | IN 0009 42
Scheduling (2)
• Der Scheduler wird bei nachfolgenden Ereignissen aktiv und
muss Entscheidungen treffen
• Wenn ein neuer Prozess erzeugt wird
• Soll der Eltern- oder der Kind-Prozess ausgeführt werden?
• Wenn ein Prozess terminiert
• Frage: Was passiert, wenn kein rechenwilliger Prozess existiert?
• Wenn ein Prozess blockiert (aufgrund von I/O, Semaphoren, etc.)
• Was passiert, wenn der blockierende Prozess eine Ressource belegt und
der nächste Prozess diese Ressource benötigt?
• Wenn ein Interrupt auftritt
• Ein Interrupt ausgehend von einem I/O-Device, kann einen blockierten
Prozess aufwecken.
• Eine Scheduling-Entscheidung kann bei jedem Timer-Interrupt getroffen
werden.

Anmerkung: Konkrete Scheduling-Verfahren werden ausführlich später vorgestellt

© 2018-21 Jörg Ott | GBS | IN 0009 43


Implementierung von Threads
• Threads werden im Addressraum eines Prozesses
ausgeführt
• Verwenden Synchronisationsmechanismen, um koordiniert auf
gemeinsame Ressourcen zuzugreifen (und diese zu „schützen“).
• Analog zu Prozessen können Threads in den folgenden
Zuständen sein
• wartend, rechenbereit, rechnend, etc.

• Implementierungs-

Thread 1

Thread 2

Thread 3
varianten von Threads

Thread 1

Thread 2

Thread 3
Space

Space
• User Space
User

User
• Kernel Space
• Hybride Varianten im Laufzeitsystem
Thread-Verwaltung
User- und Kernel-Space
Kernel

Kernel
Space

Space
Kernel Kernel

© 2018-21 Jörg Ott | GBS | IN 0009 44


User-Level-Threads
• BS-Kern kennt keine Threads, sondern nur Prozesse
• Der BS-Kern verwaltet Single-threaded-Prozesse
• Realisierung von Threads und deren Verwaltung erfordert
zusätzliche Operationen
• Implementierung mittels eines Thread-Pakets
• Bibliothek im User-Space, die für die Thread-Verwaltung zuständig ist
• Ein Thread-Paket setzt auf einem beliebigem BS auf
• Das Thread-Paket stellt als Laufzeitsystem eine Menge von
Operationen zur Verfügung
• Beispiele: thread_create, thread_exit, thread_join, thread_yield, etc.
• Das Laufzeitsystem verwaltet Threads im User-Space
• Eine Threadtabelle für jeden Prozess
• Prozessorzuteilung im BS-Kern erfolgt an Prozesse
• Das Thread-Paket implementiert einen eigenen Thread-Scheduler
• D.h. das System implementiert ein Two-level-Scheduling-Verfahren
© 2018-21 Jörg Ott | GBS | IN 0009 45
Scheduling User-Level-Threads
• Das Betriebssystem hat keine
Kenntnis von User-Level Threads

• Scheduler wählt einen Prozess aus


und gibt diesem ein Quantum an
CPU-Zeit

• Laufzeitsystem des Prozesses wählt


einen rechenwilligen Thread des
Prozesses aus.

• Ein Thread kann vom Laufzeitsystem


nicht unterbrochen werden.
• Aber Threads können selbst durch den Aufruf
der Funktion thread_yield die CPU abgeben
Quelle: Tanenbaum / Bos
• Frage: Probleme bei diesem Ansatz?

© 2018-21 Jörg Ott | GBS | IN 0009 46


Vor-/Nachteile
Schlichter, TU München von User-Level-Threads 4.2. PROZESSVERWALTUNG

Prozess Thread

Benutzer
Adressraum
(Benutzermodus)

System
BS-Kern Adressraum
(Systemmodus)

Laufzeit- Thread Prozess-


system tabelle tabelle

– Threads werden durch Laufzeitsystem im Benutzeradressraum verwaltet.


Eine Thread-Tabelle speichert Informationen (Register, Zustand, etc.) über
© 2018-21 Jörg Ott | GBS | IN 0009 47
Threads pro Prozess.
Kernel-Level-Threads (1)
• Der BS-Kern verwaltet Threads selbst
• Der BS-Kern hält eine Threadtabelle für alle Threads (im Kern)
• Thread-Operationen führen zu einem Trap in den Kern
• thread_create, thread_exit, thread_join, thread_yield, etc.
• Wechsel von User zu Kernel Mode
• Systemaufrufe bei Erzeugung bzw. Terminierung von Threads
• Nicht mehr so leichtgewichtig verglichen mit Prozessen
Prozess Thread

Benutzer
Adressraum
(Benutzermodus)

System
BS-Kern Adressraum
(Systemmodus)

Thread Prozess-
© 2018-21 Jörg Ott | GBS | IN 0009 tabelle tabelle 48
Kernel-Level-Threads (2)
• BS-Scheduler wählt einen rechenwilligen Thread
• BS kontrolliert die CPU Zuteilung an Threads

• Overhead minimieren
• Scheduling-Entscheidungen: Kernel sollte
die Thread-Zugehörigkeit zu Prozessen
berücksichtigen, um den Overhead für
einen Kontextwechsel zu verringern
• Blockierende I/O-Operationen
• Wenn ein Kernel-Level Thread blockiert,
so kann die CPU einem anderen Thread
des gleichen Prozesses zugeordnet
werden, ohne den gesamten Prozess
aufzuhalten
Quelle: Tanenbaum / Bos

© 2018-21 Jörg Ott | GBS | IN 0009 49


Hybride Implementierung
• Der BS-Kern verwaltet sogenannte Kernel-Threads.
• Das BS kennt nur Kernel-Threads: das Scheduling erfolgt
für Kernel-Threads
• n Threads im User-Space werden auf m Kernel-Threads
abgebildet (n:m Abbildung).

© 2018-21 Jörg Ott | GBS | IN 0009


Quelle: Tanenbaum / Bos 50
Unix-Threads
• UNIX-basierte Systeme unterstützen Kernel-Level Threads
• LinuxThreads: Erste Thread Implementierung unter Linux
• Thread-Erzeugung mit dem Systemcall clone()
• Threads teilen sich den Adressraum, Datei-Deskriptoren, Signale, etc.
• Jedoch besitzen alle Threads unterschiedliche PIDs und PPIDs.
• Benötigen einen zusätzlichen Manager-Thread zur Erzeugung und
Terminierung von Threads.

• Native POSIX Thread Library (ab Linux kernel v2.6):


• Erweiterung des Systemcalls clone (u.A. durch das Flag CLONE_THREAD)
• POSIX Thread Schnittstelle abstrahiert den Systemcall.
• Implementiert eine 1:1 Abbildung von User-Space-Threads auf Kernel-Level
Threads

• Beispiel: Java Threads (JVM Verwendet NPTL)


• Jeder Java-Thread gehört dem Java-Virtual-Machine (JVM) Prozess an
• Jeder Java Thread wird 1:1 auf einen Kernel-Level-Thread abgebildet

© 2018-21 Jörg Ott | GBS | IN 0009 51


Beispiel: Thread-Erzeugung unter Linux
• Der Main-Thread erstellt einen zweiten Thread mit
pthread_create
• Die neue Thread führt die übergebene Funktion thread_func aus
• Der String “hello world” wird thread_func als Argument übergeben

• Der erzeugte Thread führt die Funktion aus und beendet


sich mit pthread_exit
• Alternativ, kann der Rückgabewert auch mit return übergeben werden.
• Achtung: Ausführen von exit beendet den gesamten Prozess.

• pthread_join wartet auf die Terminierung und


Rückgabewert des Threads
• Andernfalls entsteht ein Pendant zu einem Zombie-Prozess.
• Problem?

© 2018-21 Jörg Ott | GBS | IN 0009 52


mentierung von Threads Technische
Universität

Beispiel: Thread-Erzeugung unter Linux


München

erzeugung unter UNIX 1 static void* thread_func(void *arg) {


2 char *s = (char *)arg;
read erstellt einen zweiten 3 printf("Thread TID=%d says %s\n", pthread_self, s);
thread_create. 4 pthread_exit((void *)strlen(s));
Thread führt die übergebene 5 }
6
thread_func aus.
7 int main(int argc, char *argv[]) {
g “hello world” wird thread_func 8 pthread_t thread;
ment übergeben. 9 void *res;
10 int ret = pthread_create(&thread, NULL, thread_func,
Thread führt die Funktion 11 "hello world");
ndet sich mit pthread_exit. 12 if (ret != 0)
13 fprintf(stderr, "Error: Cannot start thread\n");
v, kann der Rückgabewert auch
14 /* Wait for thread */
n übergeben werden. 15 ret = pthread_join(thread, &res);
Ausführen von exit beendet den 16 if (ret != 0)
n Prozess. 17 fprintf(stderr, "Error: Cannot join thread\n");
18
wartet auf die Terminierung 19 printf("Thread returned %ld\n", (long)res);
bewert des Threads. 20
21 exit(EXIT_SUCCESS);
alls entsteht ein Pendant zu 22 }
ombie-Prozess. Problem?
Kapitel 03 — Prozess- und Prozessorverwaltung 34 / 1
© 2018-21 Jörg Ott | GBS | IN 0009 53
Scheduling
• Vergabe der CPU an Prozesse (auch Threads)

• Batch-Systeme
• Interaktive Systeme
• Echtzeit-Systeme

• Ziele
• Metriken
• Algorithmen

© 2018-21 Jörg Ott | GBS | IN 0009 54


Ziele
Optimierungsziele sind systemabhängig
• Alle Systeme
• Fairness: Jeder Prozess soll einen fairen Anteil der CPU erhalten
• Balance: Alle Teile des Systems (CPU, I/O) möglichst effektiv auslasten
• Batch-Systeme
• Durchsatz: Maximiere Anzahl der Aufträge pro Zeit, Maß für
Systemauslastung
• Ausführungszeit: Minimiere Ausführungszeit
• CPU Belegung: Konstante Belegung der CPU
• Interaktive Systeme
• Antwortzeit: Minimiere die Antwortzeit für eingehende Anfragen
• Proportionalität: Berücksichtige die Erwartungshaltung der Benutzer
• Echtzeit-Systeme
• Deadlines einhalten: Vermeide Datenverlust (Soft-Deadlines). Umgang
mit Hard-Deadlines?
• Vorhersagbarkeit: Vermeide Qualitätsverlust z.B. in Multimediasystemen
© 2018-21 Jörg Ott | GBS | IN 0009 55
Kriterien zur Auswahl von Prozessen
• Fairness vs. Priorität
• Die CPU sollte fair zwischen ähnlichen Prozessen (einer Klasse) aufgeteilt
werden.
• Jedoch sollten höher priorisierte Prozesse mehr CPU-Zeit erhalten.
• In welchen Fällen ist Fairness nicht erwünscht?
• I/O- vs. CPU-bound Prozesse
• Wie sollte die Prozessverteilung sein, um die CPU möglichst gut
auszulasten?
• Sollten I/O-bound Prozesse vorgezogen werden, um andere Prozesse
nicht zu behindern?
• Wartezeit
• Prozesse können verhungern, wenn sie nicht zum Einsatz kommen
• Wird langes Warten mit einer Erhöhung der Priorität belohnt?
• CPU-Belegung vs. Durchsatz
• Obwohl eine CPU dauerhaft belegt ist, muss es nicht heißen, dass ihr
Durchsatz hoch ist
• Nach welcher Zeit sollte ein Prozess unterbrochen werden?

© 2018-21 Jörg Ott | GBS | IN 0009 56


Scheduling-Klassen
Prinzipielle Unterscheidung

• Nicht-unterbrechend (engl. non-preemptive)


• Prozesse werden so lange ausgeführt, bis sie blockieren oder freiwillig
die CPU abgeben
• (Ähnlich wie User-Level-Threads in einem Prozess)

• Unterbrechend (engl. preemptive)


• Prozesse werden beim Auftreten von bestimmten Ereignissen (z.B.
Timer-Interrupt) unterbrochen.

© 2018-21 Jörg Ott | GBS | IN 0009 57


Scheduling-Strategien
• Scheduling in Batch-Systemen
• First-Come-First-Served (FCFS), nicht unterbrechend.
• Shortest Job First (SJF), nicht unterbrechend,
• Ausführungszeiten müssen vorab bekannt sein.
• Shortest Remaining Time Next (SRTN), unterbrechend bei Ankunft
neuer Prozesse,
• Ausführungszeiten müssen ebenfalls bekannt sein.

• Scheduling in interaktiven Systemen


• Round-Robin Scheduling (RR), Zeitscheibenstrategie,
unterbrechend nach Ablauf der Zeitscheibe.
• Priority Scheduling, unterbrechend, höher priorisierte Prozesse
haben Vorrang
• Scheduling in Echtzeit-Systemen
• Earliest Deadline First (EDF), kann unterbrechend oder nicht-
unterbrechend implementiert sein
• Rate-Monotonic Scheduling (RMS), unterbrechend
© 2018-21 Jörg Ott | GBS | IN 0009 58
Metriken zur Bewertung

© 2018-21 Jörg Ott | GBS | IN 0009 59


Batch-Systeme: FCFS
• First-Come-First-Served (non-preemptive)
• Die CPU wird den Prozessen in der Reihenfolge zugewiesen, in der
sie angefordert wird
• Verwaltet FIFO-Run-Queue (Ready-Queue) mit rechenwilligen Prozessen
• Ein Prozess wird so lange ausgeführt, bis er blockiert oder freiwillig die CPU
abgibt
• Sobald der rechnende Prozess die CPU abgibt, wird der erste Prozess aus
der Run-Queue aktiv
• Beispiel

• Welchen Nachteil hat die FCFS-Scheduling-Strategie?


© 2018-21 Jörg Ott | GBS | IN 0009 60
Batch-System: SJF
• Shortest Job First (non-preemptive)
• Die CPU wird einem Prozess mit der kürzester Rechenzeit
zugewiesen
• SJF ist optimal, wenn alle Jobs am Anfang vorliegen und alle
Rechenzeiten bekannt sind.
• Beispiel: vier Prozesse: P1 (8min), P2 – P4 (je 4min)

Warum kann SJF nicht (nur bedingt) in interaktiven Systemen verwendet werden?
© 2018-21 Jörg Ott | GBS | IN 0009 61
Scheduling in Batch Systemen

Shortest Remaining Time Next (SRTN) (preemptive):


� Das SRTN Scheduling ist die unterbrechbare Variante von (SJF).
Batch-Systeme: SJF (2)
� Sobald ein neuer Prozess rechenwillig wird, so wird seine Gesamt-Rechenzeit mit
•verbleibenden
Problem: ManZeitmuss
des aktiven
immerProzesses
noch die verglichen.
Rechenzeit der Prozesse im
� Wenn die Rechenzeit des neuen Prozesses kürzer ist, so wird der aktive Prozess unt
Voraus kennen
� Problem: Man muss immer noch die Rechenzeit der Prozesse im Voraus kennen.
• Approximation in Phasen: Abschätzen der nächsten Rechenphase

→ Abschätzen der nächsten Rechenphase:


� Ti : Ausführungszeit der i-ten Rechenphase.
� Si : Schätzung für die i-te Rechenphase.
� S1 : Schätzung für die erste Rechenphase (gegeben).

Sn+1 = 1�n ∑ Ti , bzw.


n

i=1
� Sn+1 = 1�n ∗ Tn + (n − 1)�n ∗ Sn
Anpassung der Berechnung ohne Neuberechnung der Gesamtsumme,
jeder Rechenphase wird gleiches Gewicht gegeben.

C. Eckert Kapitel 03 — Prozess- und Prozessorverwaltung

© 2018-21 Jörg Ott | GBS | IN 0009 62


� Sobald ein neuer Prozess rechenwillig wird, so wird seine Gesamt-Rechenzeit mit de
verbleibenden Zeit des aktiven Prozesses verglichen.
� Wenn die Rechenzeit des neuen Prozesses kürzer ist, so wird der aktive Prozess unterb
Batch-Systeme: SJF (3)
� Problem: Man muss immer noch die Rechenzeit der Prozesse im Voraus kennen.
→• Abschätzen
Erläuterungder und Beispiel
nächsten Rechenphase:
� Ti : Ausführungszeit der i-ten Rechenphase.
� Si : Schätzung für die i-te Rechenphase.
� S1 : Schätzung für die erste Rechenphase (gegeben).

Sn+1 = 1�n ∑ Ti , bzw.


n

i=1
� Sn+1 = 1�n ∗ Tn + (n − 1)�n ∗ Sn
• Anpassung
Schätzung der Berechnung ohne Neuberechnung der Gesamtsumme,
jeder Rechenphase
• n= 0: wird gleiches
Start: S1, erste Gewichtz.B.
Rechenphase, gegeben.
8 Einheiten (z.B. Minuten)
C. Eckert Kapitel 03 — Prozess- und Prozessorverwaltung

© 2018-21 Jörg Ott | GBS | IN 0009 63


Batch-Systeme: SRTN
• Shortest Remaining Time Next (SRTN) (preemptive)
• Das SRTN Scheduling ist die unterbrechbare Variante von (SJF)
• Sobald ein neuer Prozess rechenwillig wird, wird seine Gesamt-Rechenzeit mit
der verbleibenden Zeit des aktiven Prozesses verglichen
• Ist die Rechenzeit des neuen Prozesses kürzer, wird der aktive Prozess unterbrochen

Prozess Ankunftszeit Rechenzeit Ausführungszeit Wartezeit

© 2018-21 Jörg Ott | GBS | IN 0009 64


Interaktive Systeme: RR
• Round-Robin, Zeitscheibenstrategie (preemptive)
• Benötigte Rechenzeit der Prozesse ist nicht vorab bekannt
• Rechenwillige Prozesse werden in einer FIFO Run-Queue (Ready-
Queue) verwaltet.
• Neue Prozesse werden am Ende der Queue hinzugefügt.
• Jedem Prozess wird ein Zeit-Quantum q zugeteilt.
• Die CPU wird den Prozessen spätestens nach Ablauf des Quantums q
entzogen.
• Ein Prozess kann für das Zeit-Quantum q die CPU belegen, vorzeitige CPU-
Freigabe, falls der Prozess blockiert oder freiwillig die CPU abgibt
• Strategische Frage hier: Wahl des Quantums q:
• Quantum q zu kurz: Erzeugt zu viele Kontextwechsel (teuer)
• Frage: Was passiert, wenn das Quantum zu lang gewählt wird?

© 2018-21 Jörg Ott | GBS | IN 0009 65


Interaktive Systeme: RR
• Beispiel:
• q=10 Einheiten
• Rechenzeiten: P1 benötigt 8 Einheiten
P2 benötigt 4 Einheiten
P3 benötigt 9 Einheiten
P4 benötigt 5 Einheiten

© 2018-21 Jörg Ott | GBS | IN 0009 66


Interaktive Systeme: Priority-Scheduling
• Priority Scheduling (preemptive)
• Jedem Prozess wird eine Priorität zugewiesen.
• Die CPU wird einem rechenwilligen Prozess mit der höchsten Priorität
zugewiesen.
• Prozesse mit gleicher Priorität werden in einer Queue verwaltet.
• Eine Queue pro Priorität.
• Kontextwechsel sobald ein höher-priorisierter, rechenwilliger Prozess
bereit ist.
• Statische Priorisierung: Prioritäten ändern sich nicht.
• Frage: Welche Probleme entstehen bei statischen Prioritäten?
• Beispiel: 4 Prioritätenklassen, Bearbeitung von hoher zu niedriger Prio
hoch Prio 1 P1 P7

Prio 2 P3

Prio 3 P4 P5 P6

niedrig Prio 4 P2 P8
© 2018-21 Jörg Ott | GBS | IN 0009 67
Interaktive Systeme: Priority-Scheduling (2)
• Dynamische Priorisierung: z.B. nach einem Timer-Interrupt
neu berechnet
• Prioritätsverringerung
Vermeiden, dass hoch-priorisierte Prozesse endlos laufen
• Beispiel: Unter UNIX Systemen, existiert der Befehl nice, der explizit die
Priorität verringert.
• Prioritätserhöhung
Vermeiden, dass niedrig-priorisierte Prozesse verhungern.
• I/O-Boost (z.B. unter Windows)
I/O-Bound Prozesse werden kurzzeitig stark bevorzugt

• Beispiel
• Multilevel-Feedback-Warteschlange als Datenstrukturen zur
Umsetzung: siehe Bild auf späterer Folie
• Round-Robin Strategie für Prozesse innerhalb der gleichen
Prioritätsklasse

© 2018-21 Jörg Ott | GBS | IN 0009 68


Interaktive Systeme: Priority-Scheduling (3)
• Beispiel: Prozess Startzeit CPU-Zeit Priorität
P1 0 8 4
P2 6 7 2
P3 3 5 3
P4 8 3 0
P5 5 3 1

© 2018-21 Jörg Ott | GBS | IN 0009 69


Echtzeit-Systeme (real-time systems)
• In Echtzeit-Systemen spielt Zeit eine entscheidende Rolle
• Man unterteilt Echtzeit Systeme in weiche (soft) und harte
(hard) Echtzeit-Systeme
• Weiche Echtzeit-Systeme: Es wird toleriert, dass nicht alle Deadlines
eingehalten werden (soft deadlines)
• Beispiel: Verlieren von Paketen während einer Skype-Konferenz
• Harte Echtzeit-Systeme: Es existieren harte Deadlines, die eingehalten
werden müssen (hard deadlines)
• Beispiel: Airbag muss sich innerhalb von einer bestimmten Zeit nach dem
Aufprall geöffnet haben

• Gegensätzliche Scheduling-Ziele bei unkritischen und


zeitkritischen Prozessen
• Unkritische Prozesse: Sollen nicht dauerhaft blockiert werden
(verhungern)
• Zeitkritische Prozesse: Müssen ihre Zeitvorgaben einhalten
© 2018-21 Jörg Ott | GBS | IN 0009 70
Echtzeit-Systeme: EDF
• Earliest Deadline First (EDF)
• Die CPU wird dem Prozess mit der nächsten Deadline zugeordnet.
• Interpretiert man Deadlines als Prioritäten, so entspricht EDF einem
Prioritäten-basierten Scheduling-Verfahren
• Es existieren zwei Varianten: Non-preemptive und preemptive
• Non-preemptive
• Der Prozess wird so lange ausgeführt, bis er blockiert oder freiwillig die
CPU abgibt
• Neue Prozesse mit früheren Deadlines werden erst beim nächsten
Kontextwechsel berücksichtigt
• Preemptive
• Der aktive Prozess wird unterbrochen, sobald ein Prozess mit einer
früheren Deadline rechenwillig wird
• Vor- und Nachteile?
© 2018-21 Jörg Ott | GBS | IN 0009 71
Echtzeit-Systeme: RMS
• Rate-Monotonic Scheduling (RMS)
• Schedulingverfahren für periodische Prozesse, z.B. Ablaufsteuerungen
in Anlagen
• Die Prozess-Priorität wird in Abhängigkeit von der Periode zugeordnet
• Die Deadline entspricht dem Ende einer Periode, Prozess muss
innerhalb der Periode beendet werden
• Prozesse mit der höchsten Frequenz (kleinste Periode) erhalten die
höchste Priorität
• Prozesse mit der geringsten Frequenz (längste Periode) erhalten die
niedrigste Priorität
• Die Priorität wird statisch vergeben
• RMS erlaubt es abzuschätzen, ob eine Echtzeit Anwendung auf einem
bestimmten System ohne Deadline-Verletzung ausgeführt werden
kann (Planbarkeit)

© 2018-21 Jörg Ott | GBS | IN 0009 72


Echtzeit-Systeme: RMS
• Beispiel
• Drei Prozesse: A, B. C. Alle drei benötigen 15ms für ihre Berechnung
• Prioritäten: Prio(A) = 33: A muss seine Berechnung alle 30ms
abschließen
• Prio(B) = 24, Prio(C) = 20

© 2018-21 Jörg Ott | GBS | IN 0009 73


Multilevel Scheduling
• Mehrschichtiges Scheduling
• Motivation
• Ggf. sind nicht alle rechenwilligen Prozesse bereits im Speicher
eingelagert
• Das Einlagern von der Festplatte ist aufwendig und sollte vorab erfolgt
sein: Mehrschichten-Scheduling
• Short-Term-Scheduler (STS)
• Preemptive vs. non-preemptive Scheduling von rechenwilligen Prozessen
• Auswahl eines geeigneten Prozesses aus der Run-Queue (Ready-Queue)
• Verwendet die bisher vorgestellten Verfahren
• Dispatcher ist i. d. R. Bestandteil des Short-Term-Schedulers
• Wird sehr häufig aufgerufen
• Medium-Term-Scheduler (MTS)
• Entscheidet darüber, ob ein Prozess in den Speicher eingelagert werden
soll
• Teil des Swapping-Mechanismus
© 2018-21 Jörg Ott | GBS | IN 0009 74
Multilevel Scheduling Schlichter, TU München 4.3. PROZESSORVERWALTUNG

• Long-Term-Scheduler (LTS) neue


• Ziel: guten Prozessmix erzielen, Aufträge

d.h. Mischung aus I/O-intensiven Long-term


Scheduler ausgeswappte
und rechenintensiven Prozessen Prozesse
swap-out
• Auswahl rechenwilliger neuer Aufträge swap-in

und Einlagerung in den


Arbeitsspeicher Ready Queue CPU fertig

• Scheduler steuert den


Multiprogramming-Grad, d.h. wieviele CPU Scheduler
Prozesse im Arbeitsspeicher liegen
• Der LTS wird aufgerufen, sobald ein E/A-Befehl

neuer Prozess erzeugt wird E/A-Warteschlange


• Entscheidet darüber, ob der Prozess Zeitscheibe
abgelaufen
zur Ready-Queue hinzugefügt werden
soll sleep-Befehl
Zeit-Interrupt-
• Sehr selten aufgerufen Warteschlange
• Nicht immer vorhanden, z.B nicht
Ausführung im Systemaufruf
unter Unix BS-Kern

© 2018-21 Jörg Ott | GBS | IN 0009 75


4.3.6 Echtzeit Scheduling
Scheduling unter Linux
• Linux-Scheduling
• Threads unter Linux werden 1:1 auf Kernel-Level-Threads abgebildet
→ Thread-basiertes Scheduling.

• Linux unterscheidet zwischen drei Thread-Klassen:


1. Echtzeit-FIFO
• Können von anderen Thread-Klassen nicht unterbrochen werden.
2. Echtzeit-Round-Robin
3. Timesharing
• Bis Kernel v2.6: O(1)-Scheduler basierend auf Priority Scheduling von 140
Prioritäten
• Je höher die Priorität, desto geringer ist das Quantum
• Ab Kernel v2.6: Completely-Fair-Scheduler (CFS) basierend auf dem O(1)-
Scheduler.
• Verwendet eine Red-Black Tree (anstatt Doubly-Linked Lists) basierte Run-Queue,
sortiert nach bereits verbrauchter CPU-Rechenzeit (Prozess mit geringster Zeit
wird gescheduled).

© 2018-21 Jörg Ott | GBS | IN 0009 76


Scheduling unter Linux (2)
• Linux unterscheidet zwischen 140 Prioritäten:
• Prioritäten 0 − 99 sind reserviert für Echtzeit-Threads.
• Prioritäten 100 − 139 sind reserviert für Timesharing-Threads.

• Beachte: Echtzeit-Threads können mit dem Standard-


Linux-Kernel nicht für Echtzeitanwendungen genutzt
werden.

© 2018-21 Jörg Ott | GBS | IN 0009 77


Multicore- /Multiprozessorscheduling
Probleme:

• Zuordnung von Prozessen zu einzelnen


Kernen/Prozessoren

• Verschiedene Charakteristika der verschiedenen


Recheneinheiten

• Erhöhung der Komplexität des Schedulings erfordert


Abwägung zwischen Qualität der Schedules und
Schedulinggeschwindigkeit

© 2018-21 Jörg Ott | GBS | IN 0009 78


Globale Warteschlange
• Eine globale Warteschlange für alle CPUs

• Vorteile:
• Gute CPU Auslastung
• Fair für alle Prozesse

• Nachteile:
• Schlechte Skalierbarkeit durch lock contention
• Schlechte Cache Lokalität

• Wurde in Linux v2.4 verwendet

© 2018-21 Jörg Ott | GBS | IN 0009 79


Eine Warteschlange für jede CPU
• Statische Aufteilung der Prozesse auf CPUs

• Vorteile
• Einfache Implementierung
• Skalierbar (keine lock contention)
• Bessere Cache Lokalität

• Nachteil
• Ungleiche Auslastung der CPUs è Unfair gegenüber Prozessen

© 2018-21 Jörg Ott | GBS | IN 0009 80


Hybride Herangehensweise
• Verwendung einer globalen zusammen mit lokalen
Warteschlangen

• Falls nötig werden Prozesse von einer lokalen Wartschlange


in eine andere verschoben (Work stealing)
• Vorteil:
• Gute Auslastung
• Prozessor-Affinität erlaubt Wiederverwendung von Daten im Cache
• Nachteil:
• Kompliziertere Implementierung
• Linux v2.6 verwendet ähnlichen Mechanismus
Quelle: https://www.cs.columbia.edu/~junfeng/13fa-w4118/lectures/l13-adv-sched.pdf
© 2018-21 Jörg Ott | GBS | IN 0009 81
Heterogenität von Prozessoren
• In der Realität hängt die Ausführungszeit eines Prozesses
stark von der Wahl des Prozessors ab

• Gründe:

• Cache-Reuse: Wurde der Prozess bereits einmal auf dem Prozessor


ausgeführt, kann er potentiell auf noch im Cache vorhandene Daten
zurückgreifen

• Hitze: Wärmeabgabe ist ein großes Problem in Prozessoren.


Abhängig von den Operationen produziert ein Prozess mehr oder
weniger Wärme. Ein Prozess mit hoher Wärmeabgabe sollte nicht auf
einen bereits heißen Prozessor geschedulet werden

© 2018-21 Jörg Ott | GBS | IN 0009 82


Heterogenität von Prozessoren
• NUMA (Non-Uniform Memory Access): Die Zugriffszeit auf den
Arbeitsspeicher ist nicht für alle Prozessoren identisch. Prozesse
sollten möglichst nahe an dem von ihnen benötigten Speicher
ausgeführt werden

• Big-Little-Architecture: Aktuelle Entwicklung bei der zur Reduzierung


des Stromverbrauchs verschiedene Prozessoren verbaut werden, die
sich in ihrer Leistungsfähigkeit und somit ihrem Stromverbrauch
unterscheiden. Zunehmend Relevant für mobile Endgeräte.
Weitere Informationen: https://www.droidwiki.org/wiki/ARM_big.LITTLE

•…

© 2018-21 Jörg Ott | GBS | IN 0009 83


Scheduling außerhalb der CPU
• Neben klassischen Prozessoren werden zunehmend
spezialisierte Rechenmodule (GPU, FPGA, ASIC, …) für
bestimmte Aufgaben verbaut. Vielfach ist auch hier ein
Scheduling nötig.

• Beispiel: GPU-Scheduling
• Windows: https://devblogs.microsoft.com/directx/hardware-
accelerated-gpu-scheduling/

• Zukünftige Bedeutung des Betriebssystems im Kontext


neuer Hardware vielfach unklar. Teil einer laufenden
Debatte über die Verteilung von Management-Aufgaben
zwischen Betriebssystem, Anwendung und Hardware

© 2018-21 Jörg Ott | GBS | IN 0009 84


Chair of Connected Mobility
Department of Informatics
Technische Universität München

Kapitel 03

Grundlagen Betriebssysteme und Systemsoftware


Parallele Systeme und Synchronisation

Prof. Dr.-Ing. Jörg Ott


Lehrstuhl Connected Mobility

Folien frei nach der Vorlage von Prof. C. Eckert (WS16/17, WS17/18) – danke!

© 2018-21 Jörg Ott | GBS | IN 0009 1


Ziele
• Sequentielle und parallele Programme

• Interaktionen zwischen Programmen

• Koordinierungskonzepte
• Störungen vermeiden
• Konflikte vermeiden bzw. auflösen
• Verklemmungen vermeiden oder erkennen und auflösen

• Klassische Synchronisationsprobleme
• Speisende Philosophen
• Leser-Schreiber-Problem
• Erzeuger-Verbraucher-Problem

• Verklemmungen
© 2018-21 Jörg Ott | GBS | IN 0009 2
Fragen…
• Welche Probleme können durch die (quasi-)parallele
Ausführung von Prozessen oder Threads entstehen?

• Wie können sich Prozesse/Threads abstimmen


(“synchronisieren”)?

• Wie wird diese Abstimmung praktisch umgesetzt?

• Warum ist eine korrekte Abstimmung manchmal gar nicht so


einfach?

• Warum überhaupt Parallelität?

© 2018-21 Jörg Ott | GBS | IN 0009 3


Entwicklung der Prozessorleistung

Quelle: https://www.karlrupp.net/2015/06/40-years-of-microprocessor-trend-data/

© 2018-21 Jörg Ott | GBS | IN 0009 4


Beispiel: Sortieren
student@gbsvm:gbs$ time sort num-1M.txt > sorted-1M.txt

real 0m1.297s
user 0m1.124s
sys 0m0.168s

student@gbsvm:gbs$ time sort num-16M.txt > sorted-16M.txt

real 0m48.227s
user 0m44.280s
sys 0m3.400s

© 2018-21 Jörg Ott | GBS | IN 0009 5


Beispiel: Sortieren (Merge Sort)

© 2018-21 Jörg Ott | GBS | IN 0009 6


Einführung
• Herausforderung
• Viele Aktivitäten und Berechnungen sind nahezu gleichzeitig
durchzuführen
• Hohe Anforderungen an kurze Ausführungszeiten/Berechnungsdauer
• Aber: Grenzen der Leistungssteigerung bei der Rechenleistung der
Hardware erreicht
• Performante Ausführung vieler Aktivitäten erfordert parallele
Ausführung bei Nutzung gemeinsamer Ressourcen: Prozessor,
Speicher, . . .
• Probleme
• Parallele Aktivitäten konkurrieren um die Ressourcen
• Parallele Aktivitäten können sich gegenseitig stören
• Aufgabe
• Parallele Aktivitäten müssen koordiniert werden
• Was sind geeignete Koordinierungskonzepte?
© 2018-21 Jörg Ott | GBS | IN 0009 7
Sequentielle und Parallele Programme
• Sequentielle und Parallele Abläufe
• Ein Programm ist die Repräsentation eines Algorithmus
• Ein Programm ist eine sequentielle Folge von Anweisungen
• Sequentielle Programmausführung
• Determiniertes Programmverhalten
• Bei gleichen Bedingungen und Eingaben berechnet das Programm
das gleiche Ergebnis
• Parallele Programmausführung
• Nebenläufige Ausführung (engl. concurrency) von Programm(teilen)
• Programm(teile) unabhängig und in einer beliebigen Reihenfolge ausführen
• Programm(teile) gleichzeitig oder zeitlich verzahnt ausführen
• Echt parallele Ausführung
• Mehrere CPUs verfügbar, z.B. Multi-Core/Multi-Prozessor-Systeme
• Bei Ein-Prozessor Systemen: echte Parallelität z.B. zwischen CPU und
Ein/Ausgabegeräten
• Programmverhalten kann nicht-determiniert sein
© 2018-21 Jörg Ott | GBS | IN 0009 8
Interaktion
• (Parallele) Programme interagieren und beeinflussen sich
• Erwünscht, z. B. durch direkten Datenaustausch.
• Unerwünscht: z. B. durch Verzögerung aufgrund von Konkurrenz

• Wir unterscheiden im Folgenden folgende Interaktionen


• Kausale Beziehungen
• Zwischen räumlich verteilten und nebenläufig ausgeführten Aktivitäten
• Beispiel: Kausale Abhängigkeit zwischen Ampel und Fußgänger
• Ereignis ausgehend vom Fußgänger: Fußgänger drückt den Knopf
• Ereignis beeinflusst Ampel: Ampel schaltet auf Rot für ein Auto
• Kommunikation
• Prozesse auf gleichen oder unterschiedlichen Rechensystemen tauschen
Nachrichten aus
• Koordinierung
• Beziehung zwischen Auftraggeber und Auftragnehmer, z.B. Client-Server
• Konkurrenz
• Prozesse konkurrieren um gemeinsame Ressourcen

• Parallelität von Aktivitäten kann zu nicht-deterministischem


Verhalten von Prozessen führen
© 2018-21 Jörg Ott | GBS | IN 0009 9
Nichtdeterminismus
• System zeigt bei gleichen Ausgangsbedingungen und
gleichen Eingaben unterschiedliches Verhalten
• Die Reihenfolge der Prozesse spielt eine Rolle
• Ursache ist z.B. unterschiedliche Last auf dem System oder Netz
• Problem: Nichtreproduzierbarkeit von Ergebnissen
• Wieso ist das ein Problem?
• Beispiel: Übungsaufgaben

• Beispiel
• Gemeinsame Variable: x=2
• Prozess P1: x = x + 5;
• Prozess P2: x = x * 2;

• Ausführung P1 vor P2: x == 14


• Ausführung P2 vor P1: x == 9

© 2018-21 Jörg Ott | GBS | IN 0009 10


Beschreibung paralleler Aktivitäten
• Auf unterschiedlichen Abstraktionsebenen
• Modell-Ebene (primär nächste Woche)
• Fokus auf Aktionen und deren Abhängigkeiten: z.B. Aktionsstrukturen
• Fokus auf Zuständen und Zustandsüberg.ngen: z.B. Petri-Netze
• Programmiersprachen-Ebene: Konkretisierung der Modellierung durch
programmiersprachliche Konzepte
• Parallele Teilabläufe innerhalb eines Prozesses:
• Beispiele: POSIX-, C++ oder auch Java-Threads Tasks in Ada.
• Konzepte zur Bildung von Prozesshierarchien: fork, join.
• Kommunikationskonzepte: send, recv.
• Synchronisationskonzepte: lock, unlock.
• Betriebssysteme-Ebene: Verwaltung paralleler Aktivitäten
• Prozesse (Programme in Ausführung): Besitzen einen eigenen Adressraum.
• Threads (Leichtgewichtige Prozesse): Threads von Prozessen teilen sich
einen Adressraum.
• Kommunikation: Shared Memory, Dateien, Nachrichten, etc.
• Synchronisation: Locks, Interrupts, etc.

© 2018-21 Jörg Ott | GBS | IN 0009 11


Modellierung paralleler Systeme
Konzepte zur Verhaltensbeschreibung vorn Aktivitäten
• Verhalten kann aus zwei sich ergänzenden Sichten beschrieben
werden
• Sicht auf Tätigkeiten
Aktionen sind die zu modellierenden Einheiten, z.B. C-Anweisung,
Maschinenbefehl
• Sicht auf Veränderungen
Ereignisse sind die modellierten Einheiten, die beobachtbare
(modellierbare) Veränderungen bewirken
• Beispiel

Ziel: Einfache Beschreibung und Analyse paralleler Aktivitäten


• Spezifikation eines Modells durch das Weglassen von Details
(Abstraktion)
• Das System wird auf interessante Eigenschaften beschränkt.
• Beispiele für solche Eigenschaften?
© 2018-21 Jörg Ott | GBS | IN 0009 12
Eigenschaften paralleler Systeme
• Determiniertheit
• Bei gleichen Bedingungen entstehen die gleichen Ergebnisse

• Störungsfreiheit
• Unter Einhaltung einer (durch eine Ordnung) festgelegten
Ausführungsreihenfolge paralleler Ereignisse und deren Aktionen wird
das Ergebnis nicht beeinflusst
• Frage: was könnte ein Beispiel einer Reihenfolge sein?

• Wechselseitiger Ausschluss exklusiv nutzbarerer


Ressourcen (engl. mutual exclusion)
• Bei konkurrierenden Zugriffen greift zu jedem Zeitpunkt maximal ein
Prozess auf gemeinsame Ressourcen zu (die Ressource wird exklusiv
verwendet)
• Frage: wie kann man mögliche Konkurrenzsituationen im Modell
erkennen?
© 2018-21 Jörg Ott | GBS | IN 0009 13
Eigenschaften paralleler Systeme (2)
• Verklemmungsfreiheit (engl. Deadlock)
• Zyklische Wartesituation zwischen mehreren Prozessen: jeder dieser
Prozesse wartet auf ein Ereignis, das nur ein anderer Prozess aus
dieser Menge verursachen kann
• Beispiel

• Kein Verhungern (engl. Starvation)


• Es gibt keine Prozesse, deren Ausführung unendlich lange
aufgeschoben wird, obwohl sie nicht in einem Deadlock sind
• Beispiel

© 2018-21 Jörg Ott | GBS | IN 0009 14


Sequentielle und parallele Systeme
• Sequentielles System
• Elementare Aktionen werden sequentiell ausgeführt
• Es existiert eine lineare Ordnung bzgl. der Zeitachse
• Anmerkung: modelliert wird nur die sequentielle Abfolge, von der
Dauer der jeweiligen Aktionen wird abstrahiert
• Beispiel

• Paralleles System
• Umfasst sequentielle und nebenläufige Aktionen.
• Es kann keine zeitliche Reihenfolge für die nebenläufigen Aktionen
bestimmt werden
• Beispiel

© 2018-21 Jörg Ott | GBS | IN 0009 15


Parallele Systeme: Synchronisation
• Abstimmung des zeitlichen Verhaltens nebenläufiger
Aktivitäten
• Koordinierung von Zugriffen auf gemeinsame, exklusiv
nutzbare Ressourcen

• Race Condition
• Mindestens zwei Prozesse greifen lesend oder schreibend auf
gemeinsame Ressourcen zu
• Das Ergebnis hängt von der Reihenfolge der Prozess-Ausführung ab

• Wechselseitiger Ausschluss (engl. mutual exclusion) von


konkurrierenden Aktionen zur Vermeidung von Race
Conditions

© 2018-21 Jörg Ott | GBS | IN 0009 16


Einführung Technische
Universität
München

ronisation:
Race Condition
bstimmung des zeitlichen Verhaltens nebenläufiger Aktivitäten.
• Beispiel
oordinierung von Zugriffen auf gemeinsame, exklusiv nutzbare Ressourcen.
• P0 und P1 sind parallele Prozesse, die beide auf eine gemeinsame
el: Race-Condition:
Variable x zugreifen, d. h. um diese Variable konkurrieren
und P1 sind parallele
• P0 wird aufProzesse,
CPU 0 und dieP1um eine
wird aufgemeinsame Variable
CPU 1 parallel x konkurrieren.
ausgeführt
wird auf CPU 0 und Ptritt
• Problem 1 wird
auch auf CPU
mit nur 1 parallel
einer CPU auf,ausgeführt.
da Prozesse unterbrechbar sind
x = 0;
P0 P1

mov rax, [mem_x]


A: x = x + 1;
mov rax, [mem_x]
add rax, $1
B: x = x + 2; mov
add rax, $2
mov [mem_x], rax [mem_x], rax

x=?

• Welchen Wert hat x nach Ausführung der Aktivitäten A und B?


elchen Wert hat x nachdem die Aktivitäten A und B ausgeführt wurden?
• Das Ergebnis hängt von der Ausführungsreihenfolge von P0 und P1
as Ergebnis ab:
hängt vonCondition
Race der Ausführungsreihenfolge von P0 und P1 ab: Race Condition.
Eckert Kapitel 04 — Prozess-Synchronisation
© 2018-21 Jörg Ott | GBS | IN 0009 17
Kritischer Abschnitt
• (engl. critical section, critical region)
• In Kritischen Abschnitten greifen Prozesse auf gemeinsame
Ressourcen zu
• Der Zugriff muss koordiniert werden, um Race Conditions zu
vermeiden
• Bei exklusiv nutzbaren Ressourcen wird der Zugriff sequentialisiert
• Beispiel: Prozesse mit kritischen Abschnitten
/* P0 */ /* P1 */
int main(void) { int main(void) {
... ...
enter_crit_region(); enter_crit_region();
x = x + 1; x = x + 2;
leave_crit_region(); leave_crit_region();
... ...
} }

© 2018-21 Jörg Ott | GBS | IN 0009 18


Kritischer Abschnitt (2)
Phasen des kritischen Abschnitts
1. Ausführung der unkritischen Abschnitte
2. Betreten eines kritischen Abschnitts (k. A.)
3. Ausführung der Aktionen des kritischen Abschnitts
4. Verlassen des kritischen Abschnitts

• Kritische Abschnitte verlangen wechselseitigen Ausschluss


• In Abhängigkeit von den ausgeführten Aktionen

• Beispiel: Leser-Schreiber-Problem (z. B. Datenbank)


• Mehrere Leser sind gleichzeitig zugelassen
• Mehrere Schreiber dürfen nicht gleichzeitig aktiv sein
• Leser und Schreiber dürfen auch nicht gleichzeitig aktiv sein

© 2018-21 Jörg Ott | GBS | IN 0009 19


Wechselseitiger Ausschluss
• Anforderungen an die Realisierung des wechselseitigen
Ausschlusses:
1. Die kritischen Abschnitte sind wechselseitig ausgeschlossen
2. Eine Realisierung des w. A. darf nicht von einer Annahme über die
Reihenfolge, in der die Prozesse ihre kritischen Abschnitte
ausführen, abhängen
3. Eine Realisierung des w. A. darf nicht von Annahmen über die
Ausführungszeit der Prozesse abhängen
4. Kein Prozess darf einen anderen Prozess unendlich lange daran
hindern, seinen kritischen Abschnitt auszuführen

• Grundlage für Lösungen


• Atomare, d.h. nicht teilbare Operationen
• Atomare Operationen können von Hard- und/oder Software zur
Verfügung gestellt werden

© 2018-21 Jörg Ott | GBS | IN 0009 20


Beispiel für Synchronisation von P1, P2

© 2018-21 Jörg Ott | GBS | IN 0009 21


Überblick über Lösungskonzepte
• Hardware-Ebene
• Interrupts sperren (disabling), Unterbrechungssperre
• Atomare Maschinenbefehle u.a. TSL, cmpxchg

• Einfache Betriebssystemdienste
• Dienste mit Aktivem Warten u.a. über Spin-Lock
• Dienste mit PassivemWarten u.a. mit sleep/wakeup

• Betriebssystemkonzepte auf höherem Abstraktionsniveau


• Semaphore: entweder mit aktivem oder passivemWarten
• Mutexe: binäre Semaphore

• Programmiersprache: u.a.
• Monitor-Konzept

© 2018-21 Jörg Ott | GBS | IN 0009 22


Erinnerung: Prozess-Zustände
resign

add retire
rechenwillig assign rechnend
ready running

block
ready

wartend
blocked

swap out
swap in
ausgelagert
swapped out

© 2018-21 Jörg Ott | GBS | IN 0009 23


Unterbrechungssperre
• Hardware-Unterbrechungen (engl. hardware interrupts)
• Interrupts werden über dedizierte Interrupt-Leitungen signalisiert, z.B.
• I/O Gerät signalisiert Beendigung des Auftrags.
• Timer signalisiert, dass ein Zeitquantum aufgebraucht ist.
• Behandlung eines Unterbrechungssignals
• Interrupt unterbricht die Ausführung des aktiven Prozesses
• Prozess wird in den Zustand rechenwillig/wartend überführt: gibt die CPU frei
• Die Unterbrechung wird behandelt (Handler).
• Bild: Ablauf bei einem Interrupt

• Wechsels. Ausschluss durch Deaktivieren von Interrupts


• Die Unterbrechungssperre verhindert, dass der aktive Prozess die CPU
abgeben muss
• D. h. der Prozess kann ohne Unterbrechung seinen kritischen Abschnitt
ausführen
© 2018-21 Jörg Ott | GBS | IN 0009 24
Unterbrechungssperre (2)
• Unterbrechungssperre ist nur bei Ein-Prozessorsystemen
zur Realisierung kritischer Abschnitte geeignet.
• Warum?

• Kritische Abschnitte, die durch Unterbrechungssperren


geschützt sind, müssen kurz sein.
• Warum?

• Das Konzept sollte höchstens im Betriebssystem-Kern


verwendet werden.
• Warum?

© 2018-21 Jörg Ott | GBS | IN 0009 25


Atomare Maschinenbefehle
• Die meisten Rechnerarchitekturen besitzen einen speziellen
Maschinenbefehl für atomare Operationen
• Wir erklären das Konzept zunächst anhand eines abstrakten
Maschinenbefehls: TSL (Test-and-Set Lock)
• TSL RAX, [LOCK]
• Hardware implementiert atomares Lesen und Schreiben einer
Speicherzelle
• Lesen des Inhalts des Speicherworts von der Adresse LOCK in das
Register RAX
• Schreiben eines Wertes ≠ 0 in das Speicherwort mit Adresse LOCK
• Lesen und Schreiben des Speichers werden als unteilbare, atomare
Operation ausgeführt
• Dazu wird der Speicherbus gesperrt, kein anderer Prozessor hat
Zugriff auf den Speicher
• Unterschied zur Unterbrechungssperre?
© 2018-21 Jörg Ott | GBS | IN 0009 26
Wechselseitiger Ausschluss mit TSL-Befehl
• Definition von zwei Funktionen
• enter_crit_region und leave_crit_region
• Synchronisation der Speicherzugriffe über die gemeinsame Variable LOCK
• Vor dem Betreten eines kritischen Abschnitts ruft ein Prozess P
enter_crit_region auf
• Falls LOCK == 0, kann der Prozess P seinen kritischen Abschnitt ausführen
• anderenfalls muss er aktiv warten, bis die LOCK-Variable auf 0
zurückgesetzt wurde.
• Nach Beendigung des kritischen Abschnitts muss der Prozess P die
gemeinsame Variable zurücksetzen: Aufruf von leave_crit_region

enter_crit_region:
tsl rax, [lock] ; Copy lock to rx leave_crit_region:
; and set lock to 1 mov [lock], $0 ; Reset lock to 0
cmp rax, $0 ; Was lock zero? ret
jne enter_crit_region ; Busy-Waiting
ret ; Process can enter

© 2018-21 Jörg Ott | GBS | IN 0009 27


Konkreter atomarer Maschinenbefehl
• Instruktion CMPXCHG auf x86 (Compare and Exchange):
• Gegeben: zwei Register rax, rbx, denen Werte zugewiesen seien
• Beispiel einer Nutzung des cmpxchg-Befehls: CMPXCHG <mem>, rbx
• Atomarer Austausch von zwei Werten
• z. B. Speicherwort und Register-Wert
• Liest Speicherwort von Adresse mem und vergleicht dessen Wert mit
dem Wert von rax
• Falls Werte gleich sind, wird der Speicher an der Adresse mem mit
dem Wert von rbx überschrieben
• Sonst wird der Wert der Adresse mem in das Register rax geschrieben
• Die Instruktion kann nicht von anderen CPUs unterbrochen werden
enter_crit_region: leave_crit_region:
mov rax, $0 ; Expected val mov [lock], $0
mov rbx, $42 ; New value ; Reset lock to 0
cmpxchg [lock], rbx ret
jne enter_crit_region ; Busy-Waiting
ret
© 2018-21 Jörg Ott | GBS | IN 0009 28
Aktives Warten
• Das eben vorgestellte Synchronisationskonzept bezeichnet
man als Spin-Lock

• Der Prozess testet kontinuierlich in einer Schleife, ob die


Ressource noch belegt ist (“looping”, “spinning”)

• Aktives Warten

• Beurteilung der Lösung mit aktivem Warten?

/* busy waiting emulation */


main () {
while (1)
;
}

© 2018-21 Jörg Ott | GBS | IN 0009 29


Passives Warten
• BS-Dienst (z.B. sleep): Prozess → Zustand wartend
• BS-Dienst (z.B. wakeup): Prozess → Zustand rechenbereit
• Beispiel
• 2 parallele Prozesse (ein Erzeuger und ein Verbraucher) greifen auf
gemeinsamen Puffer zu
• Pufferzugriff muss mit w. A. erfolgen
• Bild: Pufferzugriff

© 2018-21 Jörg Ott | GBS | IN 0009 30


Beispiel: Erzeuger-Verbraucher
void producer (void) { void consumer (void) {
int item; int item;

while (true) { while (true) {


item = produce_item (); if (count == 0)
if (count == N) sleep ();
sleep (); item = remove_item ();
insert_item (item); count = count - 1;
count = count + 1; if (count == N-1)
if (count == 1) wakeup (producer);
wakeup (consumer); consume_item (item);
} }
} }

• Pseudocode oben ist fehlerhaft: was ist das Problem?

© 2018-21 Jörg Ott | GBS | IN 0009 31


Semaphore
• Problem: fehleranfällige Nutzung von low-level Diensten
• Lösung: BS-Konzept auf höherem Abstraktionsniveau
• Realisierung von Semaphoren mit aktivem und passivem Warten möglich
• Definition Semaphore (E.W. Dijkstra, 1965)
• Eine Semaphore (Signalmast) ist eine ganzzahlige Kontrollvariable s.
• Auf der Kontrollvariable s sind 3 Operationen definiert:
Initialisierung, P (down, wait) und V (up, signal).
• Der Wert der Kontrollvariable s definiert die Anzahl der Prozesse, die
gleichzeitig den kritischen Abschnitt betreten dürfen
• Operationen P (Proberen, passering) = down und
V (Verhogen, vrijgave) = up sind atomar
• P und V werden wechselseitig ausgeschlossen ausgeführt
• Die Atomarität von P und V wird unter Nutzung von Hardeware-Befehlen
umgesetzt
• Anmerkung: Die Kontrollvariable s ist ein zählendes Semaphor. Damit
lassen sich allgemeine Synchronisationsprobleme lösen
© 2018-21 Jörg Ott | GBS | IN 0009 32
Semantik der Semaphor-Operationen
• Operation down (bzw. P)
• Kontrollvariable s wird dekrementiert
• Falls s < 0, muss der Prozess warten
• Bei einer Lösung mit passivem Warten
• Prozess wird in Zustand wartend überführt (verwaltet in einer Wait-Qeue)
• Operation up (bzw. V)
• Die Kontrollvariable s wird inkrementiert
• Bei passivem Warten: Falls die Wait-Queue nicht leer ist, wird ein
Prozess aus der Queue in den Zustand rechenbereit überführt

void down (semaphore *sema) { void up (semaphore *sema) {


int *s = &sema->s; int *s = &sema->s;
*s = *s - 1; *s = *s + 1;
if (*s < 0) { if (*s <= 0) {
thread_yield(sema->wait_queue); thread_wakeup(sema->wait_queue);
} }
} }

© 2018-21 Jörg Ott | GBS | IN 0009 33


Nutzung von Semaphoren
• Nutzung von Semaphoren zur Realisierung kritischer
Abschnitte (abstrakte Syntax)
• Definition eines Semaphor-Objekts wa („wechselseitiger Ausschluss“)
• Initialisierung der Kontrollvariable s des Semaphor-Objekts wa mit 1
(bzw. n)
• Klammern kritische Abschnitte mit P- und V-Operationsaufrufen
down (&wa);
execute_crit_region ();
up (&wa);
• Erfüllen Semaphore die Anforderungen an Lösungen des
wechselseitigen Ausschlusses?
• Wechselseitiger Ausschluss für alle kritischen Abschnitte?
• Keine Reihenfolge-Annahmen?
• Keine Ausführungszeit-Annahmen?
• Kein Verhungern?

© 2018-21 Jörg Ott | GBS | IN 0009 34


Bsp.: Erzeuger-Verbraucher-Problem
• Einsatz von zählenden Semaphoren zur Synchronisation
• Beispiel: Producer-Consumer Problem
• Fehlerhafter Lösungsversuch
• Puffer W: Zugriff synchronisiert mit Semaphore wa, initialisiert mit dem
Wert 1, so dass nur ein Prozess gleichzeitig darauf zugreifen kann
• Erzeugerprozess E und Verbraucherprozess V

/* Producer */ /* Consumer */
while(true) { while(true) {
element = produce(); down(&wa);
down(&wa); element = read_from_buf(W);
write_to_buf(W, element); // wait if empty
// wait if full up(&wa);
up(&wa); consume(element);
} }

• Problematische Aktionsfolge(n)?
© 2018-21 Jörg Ott | GBS | IN 0009 35
Bsp.: Erzeuger-Verbraucher-Problem
• Korrekte Lösung
• Zwei zusätzliche Semaphore
• voll, initialisiert mit dem Wert 0; zählt die Elemente im Puffer
• leer, initialisiert mit n, n ist die Anzahl der Pufferplätze; zählt die freien
Pufferplätze

/* Producer */ /* Consumer */
while(true) { while(true) {
element = produce(); down(&voll);
down(&leer); down(&wa);
down(&wa); element = read_from_buf(W);
write_to_buf(W, element); // Would wait if empty
up(&wa); up(&wa);
up(&voll); up(&leer);
} consume(element);
}

© 2018-21 Jörg Ott | GBS | IN 0009 36


Mutex
• Binärer Semaphor (Mutex)
• Vereinfachte Realisierung, falls ausschließlich der
wechselseitigen Ausschluss erforderlich ist
• Ein Mutex ist eine gemeinsame Variable, die zwei Zustände annehmen
kann: unlocked oder locked
• Definition
• Ein Mutex ist ein binäres Semaphor, mit s ∊ {0; 1}
• Vermeidet Busy-Waiting, falls das Mutex belegt ist
• Implementierung eines Mutex mutex_lock:
• Prinzip angelehnt an Spin-Lock mov rax, $0 ; Expected val
• Gleiche Maschineninstruktion mov rbx, $42 ; New value
cmpxchg [mutex_addr], rbx
• Aber ohne busy-waiting je cont ; Success
call thread_yield ; Sleep
mutex_unlock: jmp mutex_lock
mov [mutex_addr], $0 cont:
ret ret

© 2018-21 Jörg Ott | GBS | IN 0009 37


Monitore
• Programmiersprachen-Konzept, 1974
• Sprachkonstrukte z.B. in Java, Python, C++
• Höheres Abstraktionsniveau als Semaphore-Ebene
• Vermeiden von Problemen, wie
• vertauschen der Operationen P und V
• vergessen der zu einer P- zugehörigen V-Operation

• Monitor-Konzept
Compiler generiert Semaphore und Code zu deren Nutzung.
• Monitor fasst Daten mit dazugehörigen Zugriffsoperationen zusammen
• Beispiel: Monitor-Objekt Puffer mit buffer-Datenstruktur
• Zugriffsoperationen auf Monitor: Produce und Consume
• Beide Operationen greifen auf die gemeinsame Variable buffer
schreibend zu: Zugriffe müssen mit wechselseitigem Ausschluss erfolgen
• Compiler erzeugt automatisch Semaphore dafür und erweitert
Programmcode der Operationen um P- bzw. V-Aufrufe auf Semaphore

© 2018-21 Jörg Ott | GBS | IN 0009 38


Monitore
• Zu jedem Zeitpunkt darf höchstens ein Prozess innerhalb des Monitors
aktiv sein
• Prozesse dürfen die Methoden eines Monitors aufrufen, jedoch können
sie nicht direkt auf dessen interne Daten zugreifen
• im Beispiel: auf Datenstruktur buffer

• Bedingungsvariablen zur Synchronisation innerhalb des Monitors


• Ein Prozess kann auf die Erfüllung einer Bedingung warten
• Gibt solange den Monitor frei, d.h. ein anderer Prozess kann ihn betreten
• Ein anderer Prozess kann das Erfüllen einer Bedingung signalisieren
• Achtung: Signale gehen verloren, wenn gerade niemand auf sie wartet
• Was tun, wenn ein Prozess im Monitor wartet?
• Was passiert mit den Datenstrukturen im Monitor
• Deren Zustand kann sich durch andere Prozesse ändern
• Prinzipiell gewollt (siehe Beispiel)
• Ungewollte Änderungen müssen beachtet warden
• Den wartenden Prozess erst fortführen, wenn der signalisierende den Monitor verlässt
• Wann darf ein Prozess signalisieren?
• Beispielsweise nur unmittelbar bevor er den Monitor verlässt

© 2018-21 Jörg Ott | GBS | IN 0009 39


Monitore: Beispiel
monitor example
character buffer [SIZE];
integer count;
condition full, empty;

procedure insert (item)


begin
if (count = N) then wait (full);
insert_item (item);
count := count + 1;
if (count = 1) then signal (empty);
end;

function remove : integer;


begin
if (count = 0) then wait (empty);
remove = remove_item;
count := count – 1;
if (count = N – 1) then signal (full);
end;

count := 0;
end monitor;

© 2018-21 Jörg Ott | GBS | IN 0009 40


Beispiel: Speisende Philosophen
• Dining Philosophers von Dijsktra
• Fünf Philosophen wechseln zwischen Denken und Essen
• Sie sitzen am Esstisch mit einer Schale Reis in der Mitte
• Zwischen je zwei Philosophen
liegt genau ein Stäbchen
• Der Reis kann nur mit genau zwei
Stäbchen gegessen werden
• Jeder Philosoph darf nur das
benachbarte linke und rechte
Stäbchen verwenden
• Ablauf
• Alle Philosophen denken
• Wenn einer hungrig wird, greift er
nacheinander zu den beiden Stäbchen
• Hat er beide, beginnt er zu essen
• Wenn er satt ist, legt er beide wieder weg
© 2018-21 Jörg Ott | GBS | IN 0009 41
Fehlerhafte Lösung
• Definition von 5 Semaphoren: stick[0], ... , stick[4]
• Philosoph n verwendet Stäbchen n und (n+1)%5
• Nutzung z.B. für Philosoph 0:
• Aufnehmen linkes Stäbchen: down(stick[0]) ; Aufnehmen rechtes Stäbchen:
down(stick[1])
• Nutzung z.B. durch Philosoph 4:
• Aufnehmen linkes Stäbchen: down(stick[4]) ; Aufnehmen rechtes Stäbchen:
down(stick[0])
void philosopher (int pos) {
// initialization
while (true) {
// all sticks on the table
think_hard ();
semaphore stick[5];
down (stick[pos]);
down (stick[(pos + 1) % 5]);
void init (&sema, 5) {
eat_alot ();
for (int i=0; i<5; i++)
up (stick[pos]));
init_sema (stick[i], 1);
up (stick[(pos + 1) % 5]);
}
}
}
• Problem: Aktionsfolge mit Deadlock möglich
© 2018-21 Jörg Ott | GBS | IN 0009 42
Fehlerhafte Lösung (2)
void philosopher (int pos) {
while (true) {
think_hard ();
down (stick[pos]);
if (available (stick [(pos + 1) % 5)
down (stick[(pos + 1) % 5]);
else {
up (stick [pos]);
continue;
}
eat_alot ();
up (stick[pos]));
up (stick[(pos + 1) % 5]);
}
}

• Problem: Starvation-Risiko (bzw. Livelock)

© 2018-21 Jörg Ott | GBS | IN 0009 43


Eine korrekte Lösung
• Einführung einer weiteren Semaphore table, initialisiert mit 1
void philosopher(int pos) {
while (true) {
think_hard();
down(table);
down(stick[pos]);
down(stick[(pos + 1) % 5]);
eat_alot();
up(stick[pos]));
up(stick[(pos + 1) % 5]);
up(table);
}
}

• Korrekte Lösung, aber…?


• Bessere Lösung → Tutorium

© 2018-21 Jörg Ott | GBS | IN 0009 44


Deadlocks
• Wiederholung: Verklemmung (engl. Deadlock)
• Ein Deadlock ist ein Zustand und beschreibt eine Menge von
Prozessen, in der jeder Prozess auf ein Ereignis wartet, das nur ein
anderer Prozess aus dieser Menge auslösen kann
• Beispiel
• Möglicher Deadlock bei der exclusiven Benutzung zweier Ressourcen
R1, R2. Realisiert mit jeweils einem binären Semaphor pro Ressource
void process_A(void) { void process_B(void) {
down(&sema_resource_1); // Request R1 down(&sema_resource_2); // Request R1
down(&sema_resource_2); // Request R2 down(&sema_resource_1); // Request R2
use_both_resources(); use_both_resources();
up(&sema_resource_2); // Release R2 up(&sema_resource_1); // Release R2
up(&sema_resource_1); // Release R1 up(&sema_resource_2); // Release R1
} }

• Beispiel für eine Aktionsfolge mit Deadlock


• Ursachen für Deadlock-Situation
© 2018-21 Jörg Ott | GBS | IN 0009 45
Bedingungen für Deadlocks
• Notwendige und hinreichende Bedingungen für das
Auftreten von Deadlocks
1. Exklusiv nutzbare Ressource (Mutual Exclusion)
• Die gemeinsam genutzten Ressourcen sind nur exklusiv nutzbar, d.h. eine
Ressource ist entweder verfügbar oder genau einem Prozess zugeordnet
2. Belegen und Anfordern (Hold-and-wait)
• Prozesse, die bereits Ressourcen zugeteilt haben, belegen diese
Ressourcen, auch wenn sie noch weitere Ressourcen anfordern
3. Nicht Entziehbar (No-preemption)
• Zugeteilte Ressourcen können einem Prozess nicht entzogen werden,d.h.
die Ressourcennutzung ist nicht unterbrechbar
4. Zyklische Wartebedingung (Circular wait)
• Es gibt eine zyklische Kette von min. zwei Prozessen, die jeweils auf eine
Ressource warten, die vom nächsten Prozess in der Kette belegt ist
Für das Auftreten von Deadlocks müssen alle vier Bedingungen erfüllt sein
(Coffman 1971). D.h. Deadlocks sind vermeidbar, wenn mindestens eine
Bedingung außer Kraft gesetzt wird.
© 2018-21 Jörg Ott | GBS | IN 0009 46
Modellierung von Deadlocks
• Die vier Deadlock Bedingungen können durch einen
gerichteten Graphen, den Belegungsanforderungsgraphen,
modelliert werden (Holt, 1972).
• Knoten
• Prozesse (Kreise) und Ressourcen (Quadrate)
• Kanten
• Prozess A belegt Ressource R: gerichtete Kante von R zu A
• Prozess A fordert Ressource R an: gerichtete Kante von A zu R

• Beispiel

© 2018-21 Jörg Ott | GBS | IN 0009 47


Belegungs-Anforderungsgraph
• Gegeben
• Prozesse P = { A, B, C, D }
Deadlocks • Ressourcen R = { R, S, T, U }
Technische
Universität
München
gs-Anforderungsgraph

• Zyklus C → T → D → U → C repräsentiert ein Deadlock

A S D

T U

R B C

A belegt R B fordert S Deadlock

egeben: Prozesse P = {A, B, C, D} und Ressourcen R = {R, S, T, U}.


© 2018-21 Jörg Ott | GBS | IN 0009 48
Beispiel: Finde DL-freie Aktionsfolge
• Gegeben sind P = {A;B;C} und Ressourcen BM = {R; S;T}
mit den folgenden Aktionen
Prozess A Prozess B Prozess C
• fordert R • fordert S • fordert T
• fordert S • fordert T • fordert R
• gibt R frei • gibt S frei • gibt T frei
• gibt S frei • gibt T frei • gibt R frei

• Versuch 1

A B C

R S T

© 2018-21 Jörg Ott | GBS | IN 0009 49


Beispiel: Finde DL-freie Aktionsfolge
• Gegeben sind P = {A;B;C} und Ressourcen BM = {R; S;T}
mit den folgenden Aktionen
Prozess A Prozess B Prozess C
• fordert R • fordert S • fordert T
• fordert S • fordert T • fordert R
• gibt R frei • gibt S frei • gibt T frei
• gibt S frei • gibt T frei • gibt R frei

• Deadlockfreie Aktionsfolge

A B C

R S T

© 2018-21 Jörg Ott | GBS | IN 0009 50


Strategien zum Umgang mit Deadlocks
1. Ignorieren
• Vogel-Strauß Methode, wird in BS häufig gemacht
z.B. Verwaltung der Prozesstabelle im Linux Kernel.
• Wann kann das Vorgehen sinnvoll sein?

2. Deadlock-Detection (Erkennung)
• Das BS erkennt und beseitigt Deadlocks, falls sie auftreten sollten
• Mögliche Probleme?

3. Deadlock-Prevention (Verhinderung)
• BS setzt eine der Deadlock-Bedingungen außer Kraft

4. Deadlock-Avoidance (Vermeidung):
• BS führt keine Ressourcenzuteilung durch, die potentiell in einem
Deadlock enden könnte
• Problem?
© 2018-21 Jörg Ott | GBS | IN 0009 51
Deadlock-Detection
• Finde Prozess-Reihenfolge, so dass alle Prozesse
terminieren können
• Algorithmus zur Reihenfolge-Suche
1. Starte mit Prozessmenge P, die alle Prozesse enthält
2. Suche Prozess p ∊ P, dessen zusätzliche Anforderungen im
aktuellen Zustand erfüllbar sind
3. Falls gefunden, simuliere, dass p seine belegten Ressourcen wieder
freigibt
4. Entferne p ∊ P und gehe zu 2
5. Falls kein Prozess mehr in P ist, dann terminiert Suche: kein
Deadlock
6. falls P ≠ ∅ und in Schritt 2 kein Prozess mehr gefunden wird, dessen
Anforderungen erfüllbar sind, dann terminiert die Suche;
P enthält die Menge der verklemmten Prozesse

© 2018-21 Jörg Ott | GBS | IN 0009 52


Beispiel zu Deadlock-Detection
1. Starte mit Prozessmenge P, die alle Prozesse enthält
2. Suche Prozess p ∊ P, dessen zusätzliche Anforderungen im aktuellen Zustand
erfüllbar sind
3. Falls gefunden, simuliere, dass p seine belegten Ressourcen wieder freigibt
4. Entferne p ∊ P und gehe zu 2
5. Falls kein Prozess mehr in P ist, dann terminiert Suche: kein Deadlock
6. falls P ≠ ∅ und in Schritt 2 kein Prozess mehr gefunden wird, dessen
Anforderungen erfüllbar sind, dann terminiert die Suche;
P enthält die Menge der verklemmten Prozesse

• Beispiel von vorne: P = {A;B;C}, Zustand z: A belegt R und B belegt S.

Prozess A Prozess B Prozess C z Deadlockzustand?


• fordert R • fordert S • fordert T
• fordert S • fordert T • fordert R
• gibt R frei • gibt S frei • gibt T frei
• gibt S frei • gibt T frei • gibt R frei

© 2018-21 Jörg Ott | GBS | IN 0009 53


Deadlock-Detection: Behebung
• Abbruch der verklemmten Prozesse
• Prozesse müssen anschließend neu gestartet werden

• Ressourcenentzug, um die Ressource einem anderen


Prozess zur Verfügung zu stellen

• Zurückführung der verklemmten Prozesse auf einen


Kontrollpunkt
• Dafür sind zusätzliche Massnahmen erforderlich:
• Definition von Check-Points
• Sichern von Zuständen an Check-Points. Zurückrollen von Zuständen bis
zum Check-Point
• Maßnahmen sind aus dem Bereich der Zuverlässigkeit, Fehlertoleranz
bekannt

© 2018-21 Jörg Ott | GBS | IN 0009 54


Deadlock-Avoidance
• Idee bei der Vermeidung von Deadlocks
• Bei jeder Ressourcen-Belegung wir dynamisch eine Analyse
angestoßen und entschieden, ob die Belegung erfolgen kann oder
nicht
• Analyse der zukünftigen Betriebsmittelanforderungen der Prozessen
(bzw. diese geeignet abschätzen) und
• Verbieten von solchen Zustände (also Ressourcen-Belegungen),
die zu Deadlocks führen könnten
• Zugelassene Zustände werden als sicher bezeichnet

• Vermeidungs-Algorithmen
• Bankier-Algorithmus (Dijkstra, 1965)

© 2018-21 Jörg Ott | GBS | IN 0009 55


Bankier-Algorithmus
• Grober Ablauf
• Falls ein Prozess eine Ressourcen-Anforderung hat, die aktuell
erfüllbar ist, so teilt man das die Ressource probeweise zu und
• untersucht für den neuen Zustand, ob jetzt ein Deadlock vorliegt,
indem
• für alle anderen Prozesse von deren ungünstigsten Anforderungen
ausgegangen wird (alle stellen Maximalanforderungen).
• Auf den dann vorliegenden, fiktiven Zustand wird ein Deadlock-
Erkennungs-Algorithmus ausgeführt
• Falls kein Deadlock auftritt, kann die Zuteilung tatsächlich erfolgen

• Problem: Der Bankier-Algorithmus ist nicht praxistauglich


• Ressourcenbedarfe sind häufig nicht bekannt und auch nicht
abschätzbar
• Prozesse werden während der Laufzeit dynamisch erzeugt, d.h. die
Prozessmenge ist nicht fest
© 2018-21 Jörg Ott | GBS | IN 0009 56
Bankier-Algorithmus (2)
• Beispiel
• Bankier hat vier Kunden A, B, C, D
• Unterschiedliche maximale Kreditlinien: Summe maximal 22 Einheiten
• Bankier hat 10 Einheiten zum Verleihen
• Wenn ein Kunde seine maximale Kreditlinie erreicht, wird er nach
endlicher Zeit alles zurückzahlen
• Wie kann der Bankier sicherstellen, dass kein Deadlock auftritt

sicher sicher unsicher


© 2018-21 Jörg Ott | GBS | IN 0009 Quelle: Tanenbaum / Bos 57
Deadlock-Prevention
• Deadlock-Verhinderung: Idee: Deadlock-frei by Design
• Sicherstellen, dass mindestens eine der vier Deadlock-Bedingungen nicht
erfüllt ist
• Bedingung: exklusive Ressourcen
• Spooling: Nur Spooler-Prozess hat als einziger die Ressource zugeteilt
• Alle Prozesse nutzen Ressource indirekt über Spooler (z.B. Drucker)
• Spooler verwaltet eine Auftragswarteschlange für Aufträge
• Generell: Weise Ressourcen nur dann zu, wenn absolut notwendig
• Versuche, die Ressourcen an so wenige Prozesse wie möglich zuzuweisen
• Bedingung: Belegen und zusätzlich Anfordern, Hold-and-Wait
• Prozesse müssen alle benötigten Ressourcen vor der Ausführung
anfordern. Problem: sehr restriktiv, durch abschnittsweises Vorgehen lässt
sich das etwas Flexibilisieren
• Wenn mindestens eine der Ressourcen nicht frei ist, so muss der Prozess
warten. Wichtig: er belegt während des Wartens keine Ressourcen
• Problem: Prozesse kennen ihren Ressourcenbedarf i.d.R. nicht im voraus
© 2018-21 Jörg Ott | GBS | IN 0009 58
Deadlock-Prevention (2)
• Bedingung: nicht unterbrechbare Ressourcen, No-Preemption
• Nicht unterbrechbare Ressourcen können nur schwer temporär entzogen
werden
• Es ist jedoch möglich bestimmte Ressourcen zu virtualisieren und sie bei
Bedarf zu entziehen
• Problem: Nicht alle Ressourcen können virtualisiert bzw. durch
Virtualisierungstechniken entzogen werden
• Bedingung: ZyklischesWarten, Circular Wait
• Geordnete Ressourcen-Anforderung
• Festlegen einer linearen Ordnung auf den Ressourcen: R1 < R2 < ... < Rm
• Die Prozesse dürfen Ressourcen nur gemäß dieser Ordnung anfordern.
• D.h. ein Prozess, der Ressource Ri belegt, darf nur Ressourcen
Rj anfordern, für die gilt: Rj > Ri .
• Belegungs-Anforderungsgraph kann somit keine Zyklen enthalten.
• Problem: wie legt man die Ordnung fest?
• Ansatz: Unterscheidung nach stark ausgelasteten und weniger stark
ausgelasteten Ressourcen
• Wie könnte eine Ordnung aussehen?

© 2018-21 Jörg Ott | GBS | IN 0009 59


Vergleich der Ansätze

Ansatz Verfahren Vorteile Nachteile


Erkennung Periodischer Aufruf Interaktive Reaktion Verlust durch
Abbruch
Verhinderung Feste Reihenfolge Keine Statisch, inflexibel
bei Zuteilung Laufzeitprüfungen
Alle Ressourcen auf Kein Ineffizient
einmal zutleilen Ressourcenentzug
nowendig
Vermeidung Bankiers- Kein Ressourcen- Zukünftiger Bedarf
Algorithmus Entzug muss bekannt sein

© 2018-21 Jörg Ott | GBS | IN 0009 60


Weitere Verklemmungsarten
• Livelock: Beispiel: 2 parallele Prozesse, die jeweils zwei
Ressourcen benötigen
• Beide Prozesse setzen Locks, um die Ressourcen zu belegen
• Beide Prozesse sind höflich und geben die belegte Ressource wieder
frei, wenn sie merken, dass sie die andere Ressource nicht erhalten
können, da diese von anderen Prozess belegt ist
• Beide Prozesse führen ihre jeweiligen Ausführungen weiter, es existiert
kein Deadlock
• Beide Prozesse werden wieder Ressourcen belegen und weitere
anfordern, die der jeweils andere bereits belegt hat
• Obwohl beide Prozesse weiterhin ausgeführt werden, machen sie
keinen echten Fortschritt, sie sind in einem Livelock

• Mögliche Lösung?

© 2018-21 Jörg Ott | GBS | IN 0009 61


Weitere Verklemmungsarten (2)
• Starvation
• Ein Prozess kann verhungern, wenn seine Ressourcenanfrage nie
erfüllt wird, da stets andere (höher priorisierte) Prozesse Vorrang
haben
• Die Ursache für das Verhungern liegt in einer unfairen
Zuteilungsstrategie, sie aber durchaus sinnvoll sein kann

• Lösung: Bearbeitung von Anfragen nach FIFO

© 2018-21 Jörg Ott | GBS | IN 0009 62


Chair of Connected Mobility
Department of Informatics
Technische Universität München

Kapitel 04

Grundlagen Betriebssysteme und Systemsoftware


Modellierung Paralleler Systeme

Prof. Dr.-Ing. Jörg Ott


Lehrstuhl Connected Mobility

Folien frei nach der Vorlage von Prof. C. Eckert (WS16/17, WS17/18) – danke!

© 2018-21 Jörg Ott | GBS | IN 0009 1


Ziele
• Modellierung von Systemen

• Sequentielle und parallele Programme

• Aktionsstrukturen

• Zustandsautomaten

• Petri-Netze

© 2018-21 Jörg Ott | GBS | IN 0009 2


Erinnerung: Interaktionen
• (Parallele) Programme interagieren und beeinflussen sich
• Erwünscht, z. B. durch direkten Datenaustausch.
• Unerwünscht: z. B. durch Verzögerung aufgrund von Konkurrenz

• Wir unterscheiden im Folgenden folgende Interaktionen


• Kausale Beziehungen
• Kommunikation
• Koordinierung
• Konkurrenz

• Parallelität von Aktivitäten kann zu nicht-deterministischem


Verhalten von Prozessen führen

© 2018-21 Jörg Ott | GBS | IN 0009 3


Beschreibung paralleler Aktivitäten
• Auf unterschiedlichen Abstraktionsebenen
• Modell-Ebene (primär nächste Woche)
• Fokus auf Aktionen und deren Abhängigkeiten: z.B. Aktionsstrukturen
• Fokus auf Zuständen und Zustandsüberg.ngen: z.B. Petri-Netze
• Programmiersprachen-Ebene: Konkretisierung der Modellierung durch
programmiersprachliche Konzepte
• Parallele Teilabläufe innerhalb eines Prozesses:
• Beispiele: POSIX-, C++ oder auch Java-Threads Tasks in Ada.
• Konzepte zur Bildung von Prozesshierarchien: fork, join.
• Kommunikationskonzepte: send, recv.
• Synchronisationskonzepte: lock, unlock.
• Betriebssysteme-Ebene: Verwaltung paralleler Aktivitäten
• Prozesse (Programme in Ausführung): Besitzen einen eigenen Adressraum.
• Threads (Leichtgewichtige Prozesse): Threads von Prozessen teilen sich
einen Adressraum.
• Kommunikation: Shared Memory, Dateien, Nachrichten, etc.
• Synchronisation: Locks, Interrupts, etc.

© 2018-21 Jörg Ott | GBS | IN 0009 4


Modellierung paralleler Systeme
Konzepte zur Verhaltensbeschreibung vorn Aktivitäten
• Verhalten kann aus zwei sich ergänzenden Sichten beschrieben
werden
• Sicht auf Tätigkeiten
Aktionen sind die zu modellierenden Einheiten, z.B. C-Anweisung,
Maschinenbefehl
• Sicht auf Veränderungen
Ereignisse sind die modellierten Einheiten, die beobachtbare
(modellierbare) Veränderungen bewirken

Ziel: Einfache Beschreibung und Analyse paralleler Aktivitäten


• Spezifikation eines Modells durch das Weglassen von Details
(Abstraktion)
• Das System wird auf interessante Eigenschaften beschränkt.
• Beispiele für solche Eigenschaften?

© 2018-21 Jörg Ott | GBS | IN 0009 5


Eigenschaften paralleler Systeme
• Determiniertheit
• Bei gleichen Bedingungen entstehen die gleichen Ergebnisse
• Störungsfreiheit
• Unter Einhaltung einer festgelegten Ausführungsreihenfolge paralleler
Ereignisse und deren Aktionen wird das Ergebnis nicht beeinflusst
• Wechselseitiger Ausschluss exklusiv nutzbarerer
Ressourcen (engl. mutual exclusion)
• Zu jedem Zeitpunkt greift maximal ein Prozess auf gemeinsame
Ressourcen zu (die Ressource wird exklusiv verwendet)
• Verklemmungsfreiheit (engl. Deadlock)
• Zyklische Wartesituation zwischen mehreren Prozessen
• Kein Verhungern (engl. Starvation):
• Es gibt keine Prozesse, deren Ausführung unendlich lange
aufgeschoben wird, obwohl sie nicht in einem Deadlock sind
© 2018-21 Jörg Ott | GBS | IN 0009 6
Formalisierung
• Formale Beschreibung der wesentlichen Teile des
Systemverhaltens
• Abstraktion!

• Möglichkeit des Nachweises (math. Beweisens) bestimmter


Systemeigenschaften
• Z.B. Deadlock-frei

• Drei Beispiele
• Aktionsstrukturen
• Zustandsautomaten
• Petri-Netze

© 2018-21 Jörg Ott | GBS | IN 0009 7


Aktionsstruktur
• Präzise Beschreibung des Prozess-Begriffs mittels
Aktionsstrukturen

• Definition: Aktionsstruktur
Gegeben seien
• E* eine Menge von Ereignissen (engl. events)
• A eine Menge von Aktionen (engl. actions)

Ein Tripel p = (E, ≤, 𝛼𝛼) heißt Aktionsstruktur des Prozesses p, wenn gilt

1. Für die Ereignismenge gilt: E ⊆ E*


2. ≤ ist eine partielle Ordnung über E. ≤ ist die Kausalitätsrelation.
Eigenschaften einer part. Ordnung?
3. Die Abbildung 𝛼𝛼 : E → A ist die Aktionsmarkierung des Prozesses p
4. Die Abbildung 𝛼𝛼 ordnet jedem Ereignis eine Aktion zu

© 2018-21 Jörg Ott | GBS | IN 0009 8


Beispiel: Fußgängerübergang

© 2018-21 Jörg Ott | GBS | IN 0009 9


Beispiel
• Auszug aus dem Modell eines Fußgängerübergangs

• E = {e1, ... , e5}


• ≤ = {(e1, e2), (e2, e3), (e3, e4), (e3, e5)}
• A = { Knopf gedrückt, ... }

• 𝛼𝛼 (e1) = Knopf gedrückt


• 𝛼𝛼 (e2) = Ampel schaltet auf Gelb
• 𝛼𝛼 (e3) = Ampel schaltet auf Rot
• 𝛼𝛼 (e4) = Auto hält
• 𝛼𝛼 (e5) = Fußgänger-Ampel schaltet auf Grün

© 2018-21 Jörg Ott | GBS | IN 0009 10


Eigenschaften von Prozessen
• In einem Prozess ist jedes Ereignis eindeutig
• Es kann verschiedenen Ereignissen die gleiche Aktion zugeordnet
werden
• Beispiel

• Für einen Prozess p = (E, ≤, 𝛼𝛼) nennen wir zwei Ereignisse e1; e2 ∈ E
parallel oder nebenläufig (engl. concurrent), wenn sie in p nicht in einer
kausalen Relation stehen
• ¬(e1 ≤ e2 ⋁ e2 ≤ e1)
• Parallele (nebenläufige) Ereignisse sind kausal unabhängig
• Beispiel

• Ein Prozess p = (E, ≤, 𝛼𝛼) heißt endlich, falls seine Ereignismenge eine
endliche Menge ist
• Beispiel

• Ein Prozess p = (E, ≤, 𝛼𝛼) heißt sequentiell, wenn die Kausalitätsrelation


≤ eine lineare Ordnung ist
• Lineare Ordnung?
© 2018-21 Jörg Ott | GBS | IN 0009 11
Graphische Darstellung von Aktionsstrukturen
• Knotenmarkierte, gerichtete, zyklenfreie Graphen
• Knoten repräsentieren Ereignisse und sind durch Aktionen
markiert
• Ereignisse werden nicht wiederholt
• Aktionen können wiederholt werden, jede wiederholte
Ausführung der gleichen Aktion führt zu einem neuen
Ereignis (zyklenfrei)

e1 e2 e3 e5 e6

e4

© 2018-21 Jörg Ott | GBS | IN 0009 12


Beispiel: Fußgängerübergang

© 2018-21 Jörg Ott | GBS | IN 0009 13


Kausale Abhängigkeiten zwischen Aktionen
• Für Verwaltung von Prozessen ist wichtig, was die
Ursachen für Abhängigkeit sind
• Unterschiedliche Klassen kausaler Abhängigkeiten
1. Echt kausale Beziehungen
• Ereignis e ist kausal für das Ereignis d, wenn d ohne e niemals auftreten
kann.
• Beispiel
2. Zeitliche Beziehungen
• Ereignis e endet bevor das Ereignis d beginnt
• Die kausale Beziehung impliziert eine zeitliche Relation:
Zusammenhang ist bekannt als: L. Lamport’s „happened before“-Relation.
• Beispiel? Mögliche Konsequenz für BS-Verwaltung?
3. Systembeschränkungen
• Wechselseitiger Ausschluss: Ereignis e darf nicht parallel zum Ereignis d
auftreten
• Beispiel? Mögliche Konsequenz für BS-Verwaltung?
© 2018-21 Jörg Ott | GBS | IN 0009 14
Sequentialisierung
• Ziel: Vereinfachte Darstellung paralleler Abläufe
• Schritt 1: durch zusätzliche Abhängigkeiten eine Reihenfolge
festlegen, deterministische Abläufe konstruieren
• Schritt 2: mit Aktionsfolgen (traces) das Verhalten eines sequentiellen
Prozesses beschreiben
• Schritt 1:
• Ein Prozess p1 = (E1, ≤1, 𝛼𝛼1) repräsentiert eine Sequentialisierung
eines Prozesses p2 = (E2, ≤2, 𝛼𝛼2), falls gilt:
• E1 = E2
• ∀ e, d ∈ E1 gilt: ≤2 d → e ≤1 d
• 𝛼𝛼1 = 𝛼𝛼2
• Ist p1 sequentiell, so heißt die Sequentialisierung vollständig
• Die Vervollständigung einer partiellen zu einer linearen Ordnung heißt
topologisches Sortieren
• Parallele Aktionen werden in eine zufällige Reihenfolge gebracht
• Das Ergebnis ist ein sequentieller Prozess mit einer zufällig gewählten
Sequentialisierung
© 2018-21 Jörg Ott | GBS | IN 0009 15
Sequentialisierung (2)
• Schritt 2: Verhaltensbeschreibung über Aktionsfolgen
• Notation
• Sei A Menge von Aktionen
• Wir bezeichnen mit A+ die Menge der endlichen Folgen von Aktionen aus A
• Wir bezeichnen mit A∞ die Menge der unendlichen Folgen von
Aktionen aus A
• Jedem sequenziellen Prozess ist eine Folge von Aktionen zugeordnet,
die Spur (engl. trace)
• spur : {p | p ist sequentieller Prozess} → A ∪ A∞
• spur(p) = empty; falls E = ∅
• spur(p) = <a> ∘ spur(p | E \ {e}), falls E ≠ ∅,
wobei e das gemäß Kausalitätsordnung kleinste Ereignis von p ist und es
gilt: 𝛼𝛼(e) = a.
• Für einen nicht-sequentiellen Prozess p gilt:
• spuren(p) = {spur(q) : Prozess q ist eine vollständige Sequenzialisierung
von p}

© 2018-21 Jörg Ott | GBS | IN 0009 16


Beispiele

Eine mögliche spur(p) einer beispielhaften vollständige Sequentialisierung

© 2018-21 Jörg Ott | GBS | IN 0009 17


Zustandsautomaten

ready running

blocked

swapped out

© 2018-21 Jörg Ott | GBS | IN 0009 18


Zustandsautomaten
• Duale Sicht: Aktionen erhalten eine Bedeutung
• modelliert durch Zustände und Zustandsübergänge
• Definition: Nichtdeterministischer endlicher
Zustandsautomat (nondeterministic finite automaton, NFA)
• Ein NFA ist gegeben durch
• S : eine Menge von Zuständen (engl. states), genannt Zustandsraum
• A : eine Menge von Transitionsaktionen (engl. actions)
• S0 : eine Menge von möglichen Anfangszuständen
• R ⊆ S × A × S eine Zustandsübergangsrelation
• Seien s0, s1 ∈ S und a ∈ A gegeben, so gilt
• Im Zustand s0 kann die Aktion a ausgeführt werden, um den Zustand s1 zu
erreichen: s0 →a s1, falls (s0, a, s1) ∈ R.
• Der Automat ist nichtdeterministisch
• In einem Zustand sind mehrere Transitionsaktionen möglich
• Eine Transitionsaktion-Auswahl kann zu unterschiedlichen
Nachfolgezuständen führen.

© 2018-21 Jörg Ott | GBS | IN 0009 19


Beispiel: Fahrkartenautomat

© 2018-21 Jörg Ott | GBS | IN 0009 20


Konflikte
• Problem
• Aktionen und die damit verbundenen Zustandsänderungen können
miteinander in Konflikt stehen
• Beispiel: Konflikte bei parallel durchzuführenden Zuweisungen
e1 : x = x + 1;
e2 : x = 2 * x;

• Die Zuweisungen stehen im Konflikt


• Bei paralleler Ausführung kann dem zugehörigen Prozess keine
Zustandsänderung eindeutig zugeordnet werden
• Wir sagen: die Aktionen stören sich wechselseitig

• Aufgabe des Betriebssystems (BS): Störungen vermeiden!


• Frage: Welche Kriterien charakterisieren eine Störung, so dass das BS
die Einhaltung der Kriterien prüfen kann?

© 2018-21 Jörg Ott | GBS | IN 0009 21


Störungsfreiheit
• Definition Störungsfreiheit
• Gegeben sei eine Transitionsaktion a
• V(a) ⊆ S heißt Vorbereich
V(a) ist die Menge der gelesenen Zustandsvariablen
• N(a) ⊆ S heißt Nachbereich
N(a) ist die Menge der geschriebenen Zustandsvariablen.
• Prozess p = (E, ≤, 𝛼𝛼) heißt störungsfrei, wenn für jedes Paar von
Ereignissen e1, e2 ∈ E gilt:
• e1 ≤ e2 ∨ e2 ≤ e1, oder
• Es gelten die Bernstein-Bedingungen, d.h. es gilt:
1. V(𝛼𝛼(e1)) ∩ N(𝛼𝛼(e2)) = ∅ ∧
2. V(𝛼𝛼(e2)) ∩ N(𝛼𝛼(e1)) = ∅ ∧
3. N(𝛼𝛼(e1)) ∩ N(𝛼𝛼(e2)) = ∅

• Beispiel: Sei S = { x, y, z }
• e1 : x = x + 3y + z; V(𝛼𝛼(e1)) = N(𝛼𝛼(e1)) =
• e2 : y = 2 *x; V(𝛼𝛼(e2)) = N(𝛼𝛼(e2)) =

© 2018-21 Jörg Ott | GBS | IN 0009 22


Petri-Netze
• Graphische Verhaltensmodellierung
• Alternative zur Aktionsstruktur
• Beschreibung eines nebenläufigen Systems und dessen Abläufen mit
einem Petri-Netz (durch Carl Adam Petri, 1962)
• Petri-Netze sind Basis u.a. für UML-Aktionsdiagramme (sehr breit im
Einsatz)
• Definition: Petri-Netz
• Ein Petri-Netz ist ein Tripel (S,T, F), mit
• S : endliche Menge von Stellen, repräsentiert als Kreise
• Stellen modellieren passive Elemente, z.B. Speicherzellen
• T : endliche Menge von Transitionen, repräsentiert als Rechtecke
• Transitionen modellieren aktive Elemente, z.B. Prozessoren, Prozesse
• Es gilt S ∩ T = ∅
• F ist eine Flussrelation mit F ⊆ (S × T) ∪ (T × S)
• Elemente von F werden als gerichtete Kanten repräsentiert
• Für einen Knoten x ∈ (S ∪ T) gilt
• Vorbereich: •x = {y | y F x}
• Nachbereich: x• = {y | x F y}

© 2018-21 Jörg Ott | GBS | IN 0009 23


Beispiel: Materialverarbeitung

Beispiel: Für die Transition Bestellaufnahme gilt:


• •Bestellaufnahme = {Bestellung}
• Bestellaufnahme• = {Produktionsauftrag; Lieferauftrag}

© 2018-21 Jörg Ott | GBS | IN 0009 24


Verfeinerung
• Petrinetze können schrittweise verfeinert werden
• Die zu verfeinerte Transition kann nach außen hin als Blackbox
aufgefasst werden
• Globale Struktur muss erhalten bleiben (alle ein- und ausgehenden
Kanten der verfeinerten Transition bleiben erhalten)
• Innere Struktur der Transition kann um Stellen, Transitionen und
Kanten erweitert werden
• Beispiel: Verfeinerung der Materialverwaltung

© 2018-21 Jörg Ott | GBS | IN 0009 25


Dynamisches Verhalten eines Petri-Netzes
• Definition: Markiertes Netz, Stellen-Transitionsnetz
• Gegeben sei ein Petri-Netz (S, T, F)
• Die Abbildung c : S → IN ∪ {∞} beschreibt die Kapazität einer Stelle
• Wenn nicht explizit markiert, so besitzen die Stellen eine unendliche
Kapazität
• Die Abbildung w : F → IN ∪ {0} beschreibt die Gewichtung einer Kante
• Wenn nicht explizit markiert, so haben die Kanten das Gewicht 1
• Ein Stellen-Transitionsnetz ist ein natürlichzahlig markiertes Netz:
M:S→N
• Natürlichzahlige Markierungen der Stellen beschreiben einen Zustand des
Netzes
• Es muss gelten: ∀ s ∈ S M(s) ≤ c(s)
• Eine Marke wird häufig als Token bezeichnet
• Ein Bedingungs/Ereignisnetz oder Boolesches Netz: M : S → IB
• Eine Transition t schaltet nur dann, wenn alle s ∈ t• mit false markiert sind

© 2018-21 Jörg Ott | GBS | IN 0009 26


Beispiele

© 2018-21 Jörg Ott | GBS | IN 0009 27


Definition Schaltregel
• Gegeben seien ein Petri-Netz (S, T, F), die Funktionen c, w
und eine Anfangsmarkierung M0.
• Ein Zustandsübergang erfolgt durch das Schalten von Transitionen
• Das Modell sagt nichts über die Schaltdauer einer Transition (Schalten
erfordert keine Zeit)
• Eine Transition t ∈ T kann schalten (d.h. ist transitionsbereit),
wenn gilt:
• ∀s ∈ •t gilt: M(s) ≥ w((s, t))
• ∀s ∈ t• gilt: M(s) ≤ c(s) − w((t, s))
• Durch das Schalten von t wird eine Folgemarkierung M' zu M
erzeugt:
• ∀s ∈ •t ∖ t• gilt: M' (s) = M(s) − w((s, t))
• ∀s' ∈ t• ∖ •t gilt: M‘(s') = M(s') + w((t, s'))
• ∀s‘' ∈ •t ∩ t• gilt: M‘(s") = M(s") − w((s", t)) + w((t, s"))
• Sonst: M'(s) = M(s)
© 2018-21 Jörg Ott | GBS | IN 0009 28
Beispiel: Schalten einer Transition

© 2018-21 Jörg Ott | GBS | IN 0009 29


Beispiel für nichtschaltbare Transitionen

© 2018-21 Jörg Ott | GBS | IN 0009 30


Modellierung von Systemeigenschaften
• Nebenläufige Systeme
• Beispiel: Vier Aktivitäten t1, ..., t4
• Jede Aktivität wird durch eine Transition modelliert
• Nach Beendigung von t1 können t2 und t3 nebenläufig aktiv sein
• t2 und t3 müssen beendet sein, bevor t4 ausgeführt werden kann

© 2018-21 Jörg Ott | GBS | IN 0009 31


Modellierung von Systemeigenschaften (2)
• Nichtdeterminismus
• Bei einer gegebenen Markierung M können Konflikte bzgl. der
Schaltbereitschaft auftreten
• Zwei Transitionen t1 und t2 stehen im Konflikt, wenn:
• Wenn t1 und t2 gemeinsame Eingangs- und Ausgangsstellen besitzen, die
so markiert sind,
• dass nur eine von beiden Transitionen schalten kann.
• Es erfolgt eine nichtdeterministische Auswahl der schaltbereiten
Transitionen

© 2018-21 Jörg Ott | GBS | IN 0009 32


Erreichbarkeit
• Fragestellung: Erreicht ein Netz ausgehend von der
Markierung M irgendwann eine Folgemarkierung M‘?
• Definition: Erreichbarkeit, Ereichbarkeitsgraph
• Gegeben sei ein Petri-Netz (S, T, F) mit der Markierung M
• Eine endliche Sequenz 𝜌𝜌 = t1, t2, ..., tn mit ti ∈ T heißt von M aktivierte
endliche Schaltfolge, wenn Markierungen M1, M2, ..., Mn existieren mit:

• M‘ ist von M erreichbar, wenn es eine Sequenz gibt, die von


M in den Endzustand M‘ führt.
• Modellierung des Netzes als einen Zustandsautomat, der
als ein Erreichbarkeitsgraph dargestellt wird, um erreichbare
Markierungen zu beschreiben.
• Die Knoten des Graphen sind die erreichbaren Markierungen
• Die Kanten des Graphen sind mit Transitionen beschriftet
© 2018-21 Jörg Ott | GBS | IN 0009 33
Beispiel: Bahnnetz
• Vier Städte sind durch Bahngleise, die nur in einer Richtung befahrbar
sind, im Kreis verbunden. Zwei Züge fahren auf der Streckez
• Aufgabe: Konstruiere ein System, in dem die Züge nie gleichzeitig auf
der selbe Strecke sind.

Je ein Zug

© 2018-21 Jörg Ott | GBS | IN 0009 34


Beispiel: Bahnnetz (2)
• Der Erreichbarkeitsgraph zeigt, dass kein Zustand
erreichbar ist, in dem mehr als eine Marke eine Stelle belegt
• Es existiert ein (komplexer) Algorithmus, der entscheidet, ob M' aus M
aus erreichbar ist (Mayr, 1980)

Erreichbarkeitsgraph des Bahnnetzes


© 2018-21 Jörg Ott | GBS | IN 0009 35
Nebeneinander…

© 2018-21 Jörg Ott | GBS | IN 0009 36


Darstellungsweise von Erreichbarkeitsgraphen

Zustand gegeben als Liste der


markierten Stellen

Zustand als Zahlenvektor


s1s2s3s4 k1k2k3k4

In GBS bevorzugte Variante

© 2018-21 Jörg Ott | GBS | IN 0009 37


Lebendigkeit bzw. Blockierungen
• Fragestellung: Kann es in einem System zu Blockierungen
kommen?
• Antwort: Untersuche, ob bestimmte Stellen niemals markiert oder
niemals ihre Marken verlieren

Definition: Lebendigkeit (engl. liveness)


• Gegeben sei ein Petri-Netz (S, T, F) mit der
Anfangsmarkierung M0.
• Das Netz heißt lebendig, wenn für jede erreichbare
Markierung M und für jede Transition t ∈ T eine Markierung
M' existiert, die aus M erreichbar und in der t
transitionsbereit ist.

© 2018-21 Jörg Ott | GBS | IN 0009 38


Lebendigkeit bzw. Blockierungen
Definition: Verklemmung (engl. deadlock)
• Gegeben sei ein Petri-Netz (S, T, F) mit der
Anfangsmarkierung M0

• Die von M0 aus erreichbare Markierung M beschreibt eine


vollständige Verklemmung, wenn es keine Transition t ∈ T
gibt, die unter M schalten kann.

• Die von M0 aus erreichbare Markierung M beschreibt eine


lokale Verklemmung, wenn es eine Transition t ∈ T gibt, so
dass ausgehend von M keine Folgemarkierung M'
erreichbar ist, in der t transitionsbereit ist

• Wichtig: Ist (S, T, F) mit Anfangsmarkierung M0 lebendig,


dann ist es auch verklemmungsfrei
© 2018-21 Jörg Ott | GBS | IN 0009 39
Beispiel: FIFO-Puffer
• Modellierung eines FIFO-Puffers mit Kapazität 3, der
veerklemmungsfrei und lebendig ist.

© 2018-21 Jörg Ott | GBS | IN 0009 40


Beispiel: Verklemmung
• Zwei Studenten benötigen ein zwei-bändiges Lehrbuch.
• Student 1 leiht sich zunächst nur Band 1; Student 2 Band 2 aus
• Bevor Student 1 Band 1 zurückgibt, möchte er Band 2 ausleihen
• Bevor Student 2 Band 2 zurückgibt, möchte er Band 1 ausleihen

© 2018-21 Jörg Ott | GBS | IN 0009 41


Weitere Eigenschaften von Petri-Netzen
• Fairness
• Das Netz ist unfair für eine Transition t, wenn:
• Transition t ist unendlich oft transitionsbereit
• Es gibt eine unendliche Sequenz, in der t nur endlich oft auftritt

• Verhungern: (engl. Starvation).


• Eine Transaktion t verhungert, wenn es eine unendliche Sequenz gibt,
in der t trotz Transitionsbereitschaft niemals auftritt.

© 2018-21 Jörg Ott | GBS | IN 0009 42


Chair of Connected Mobility
Department of Informatics
Technische Universität München

Kapitel 05

Grundlagen Betriebssysteme und Systemsoftware


Inter-Prozesskommunikation (IPC)

Prof. Dr.-Ing. Jörg Ott


Lehrstuhl Connected Mobility

Folien frei nach der Vorlage von Prof. C. Eckert (WS16/17, WS17/18) – danke!

© 2018-21 Jörg Ott | GBS | IN 0009 1


Ziele
• Weitere Mittel zur kontrollierten Interaktion zwischen
Prozessen

• Synchrone vs. asynchrone Kommunikation


• Nachrichtenbasierte Kommunikation
• Stromorientierte Kommunikation

• Signale
• Shared Memory
• Pipes
• Sockets

© 2018-21 Jörg Ott | GBS | IN 0009 2


Fragen
• Wie können Daten zwischen Prozessen ausgetauscht
werden?

• Wie funktionieren eigentlich Pipes?


$ grep FMI room.txt | less

• Wie schreibe ich einen minimalen (Web-)Server?


• bzw. einen Client

© 2018-21 Jörg Ott | GBS | IN 0009 3


Einführung
• Thema: (Inter-)Prozesskommunikation

• Kommunikation ist eigentlich Thema der Vorlesung


„Grundlagen Rechnernetze und Verteilte Systeme“ (GRNVS)

• Wir konzentrieren und auf die für Betriebssysteme bzw.


Betriebssystementwicklung relevanten Aspekte

• Einige Konzepte werden auch zur Kommunikation über


mehrere Computersysteme hinweg verwendet

© 2018-21 Jörg Ott | GBS | IN 0009 4


Bisher
• Prozesse mit getrennten Adressräumen
• Wissen über Prozess-Ids nur innerhalb von Prozessgruppen
• Elternprozess ↔ Kindprozesse

• Threads mit gemeinsamem Adressraum

• Synchronisationsmechanismen
• zur Koordination beim Zugriff auf gemeinsame Ressourcen
• Semaphore, Mutexe usw.

• Inter-Prozesskommunikation
• Für wohldefinierte Interaktionen zwischen Prozessen, Threads, …
• Dabei ist natürlich Synchronisation erforderlich!

© 2018-21 Jörg Ott | GBS | IN 0009 5


Kommunikationsformen
• Arten der Kommunikation zwischen Prozessen bzw.
Threads
• Signalisierung von Ereignissen
• Austausch von Nachrichten
• Auch komplexe Kommunikationsprotokolle möglich (z.B. TCP, UDP)
• Gemeinsamer Speicher

• Eigenschaften von Interprozesskommunikation (u.a.)


• Breitbandig vs schmalbandig
• Implizit vs explizt
• Nachrichtenorientiert vs speicherorientiert
• Antwortverhalten: Nachricht vs Auftrag

• Meta-Problem: Rendezvous
• Woher weiß ein Prozess, mit welchem anderen er kommunizieren soll?
• Wie findet ein Prozess seine(n) Kommunikationspartner?
© 2018-21 Jörg Ott | GBS | IN 0009 6
Bandbreite des Kommunikationskanals
• Schmalbandige Kanäle
• Übertragen von wenigen Bits an Information
• Melden von Ereignissen
• Synchronisationskonzepte und Unterbrechungskonzepte erforderlich
• Beispiel unter Linux: Signals
• Prozesse können sich gegenseitig Signale senden (kill())
• Prozesse können diese Signale explizit abfangen (signal())
• Durch registrieren eines Signal-Handlers
• Durch explizites Ignorieren (SIG_IGN)
• In Posix 31 unterschiedliche Signale möglich
• z.B. SIGINT, SIGTERM, SIGKILL, SIGSEGV, SIGILL, ... (man 7 signal)
• Wenn der Prozess das Signal nicht abgefängt, wird er vom
Betriebssystem beendet
• Die Signale SIGKILL und SIGSTOP können nicht abgefangen werden
• Achtung: Signale unter Linux unterbrechen einen Prozess asynchron
• Der Prozess muss mit solchen Unterbrechungen umgehen können
© 2018-21 Jörg Ott | GBS | IN 0009 7
Beispiel
void sighandler (int sig) {
printf ("Caught signal %d\n", sig);
signal (SIGINT, sighandler);
signal (SIGALRM, sighandler);
} $ ./signal
Counting 0...
int main (int argc, char *argv [], char *envp []) { Counting 1...
char buffer [1024];
int len;
Counting 2...
Counting 3...
signal (SIGINT, sighandler); Counting 4...
signal (SIGALRM, sighandler); Caught signal 14
alarm (5);
for (len = 0; len < 10; len++) Counting 5...
printf ("Counting %d...\n", len), sleep (1); Counting 6...
alarm (10); Counting 7...
while (1) { Counting 8...
len = read (0, buffer, sizeof (buffer) - 1);
if (len == -1) { Counting 9...
perror ("read () failed"); hello, world
continue; hello, world
}
if (len == 0) {
Caught signal 14
printf ("Exiting\n"); echo this
exit (0); echo this
} ^CCaught signal 2
buffer [len] = '\0';
if (!strncmp (buffer, "exit", 4)) exit
exit (0); $
write (1, buffer, strlen (buffer));
}
}

© 2018-21 Jörg Ott | GBS | IN 0009 8


Bandbreite des Kommunikationskanals
• Breitbandige Kanäle
• Übertragung größerer Datenmengen
• Unterscheidung nach:
• impliziter Übertragung (z.B. Gemeinsamer Speicher)
• expliziter Übertragung (z.B. Pipes, Sockets (AF_INET))
• Hierbei auch Konzepte aus dem Bereich der verteilten Systeme
relevant
• z.B. Omega-Switching-Netze oder verschiedene Vernetzungsarchitekturen
(Ring, Stern)
• Allgemeine, teilstrukturierte Netze wie das Internet
• Werden über die gleichen Betriebssystemfunktionen realisiert

• Im folgenden werden einige Beispiele für breitbandige


Kanäle betrachtet

© 2018-21 Jörg Ott | GBS | IN 0009 9


Implizite Kommunikation
• Implizite Kommunikation über gemeinsame Betriebsmittel
• keine direkte Unterstützung durch das Betriebssystems
• Vorteil: Einfach und schnell, da kein Kopieren zwischen Adressräumen
benötigt wird
• Aber:
• Gemeinsame Bereiche sind nicht immer vorhanden.
• Aufwendiges busy-waiting kann auftreten.
• Weitere (schmalbandige) Synchronisation ist notwendig (siehe Kapitel 3)
• Beispiele
• Speicher, Register, Dateien, Ringpuffer
• Queue-Datenstruktur im Prozess, welche von allen Threads verwendet wird
• Speicher der Datenstruktur kann auch in mehrere Prozesse gemappt
sein
• Hier ist Unterstützung durch das Betriebssystem erforderlich
• Eintrag in Pagetables (siehe Kapitel 6)

© 2018-21 Jörg Ott | GBS | IN 0009 10


Beispiel: Gemeinsamer Speicher (1/2)
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/mman.h>
#include <signal.h>

int message = 0;

void child_handler (int sig) {


message = 1;
}

int main (int argc, char *argv [], char *envp []) {
char *shmem;
pid_t pid;

if ((shmem = mmap (NULL, 1024, PROT_READ|PROT_WRITE, MAP_ANONYMOUS|MAP_SHARED, 0, 0))


== NULL)
perror ("Cannot create shared memory");
exit (-1);
}
// set up the signal handler before forking, so it surely is in place
signal (SIGUSR1, child_handler);

...

© 2018-21 Jörg Ott | GBS | IN 0009 11


Beispiel: Gemeinsamer Speicher (2/2)
switch (pid = fork ()) {
case -1: /* error */
perror ("fork () failed");
exit (-1);

case 0: /* child process */


printf ("child %d: waiting for message...\n", getpid ());
while (!message)
usleep (1000);
printf ("child %d reading from shmem: %s\n", getpid (), shmem);
sprintf (shmem, "Got it [%d] -- exiting", getppid ());
printf ("child %d writing to shmem: %s\n", getpid (), shmem);
break;

default: /* parent process */


signal (SIGUSR1, SIG_IGN);
sprintf (shmem, "Parent %d sending message to child %d", getpid (), pid);
kill (pid, SIGUSR1); /* notify the child process */
wait (NULL); /* wait for the child to terminate */
printf ("Message from child %d: %s\n", pid, shmem);
break;
}
exit (0);
}

© 2018-21 Jörg Ott | GBS | IN 0009 12


Explizite Kommunikation
• Versenden und Empfangen von Nachrichten:
message passing
• Geeignet für Prozesse in disjunkten Adressräumen
• Dedizierte Interaktion mit dem Betriebssystem (Beispiel Linux)
• send (int sockfd, const char* buf, ...)
• recv (int sockfd, const char* buf, ...)

• Funktionssignaturen sind abhängig vom Betriebssystem, aber in


POSIX standardisiert
• Typische Signatur: (Sender/Empfänger, Nachricht)

• Kommunikation sowohl lokal (z.B. PID) als auch mit entfernten


Partnern (z.B. IP Adresse, Portnummer) möglich
• Auch Verwendung von read()/write() möglich, da Sockets auch
Filedeskriptoren sind (siehe Kapitel 9)

© 2018-21 Jörg Ott | GBS | IN 0009 13


Explizite Kommunikation
• Nachrichtenaufbau
• Nachrichtenkopf (header): Managementinformationen
• u.a. Sender-, Empfänger-Identifikation, Größe usw.
• Nachrichtenkörper enthält die Nutzlast (payload).

• Ablauf
1. Prozess sendet mit Hilfe von send() die Nachricht.
2. Nachrichtendienst des Betriebssystems übermittelt die Nachricht
3. Empfänger Prozess empfängt Nachricht mit Hilfe von recv()

• Unterscheidung in synchrone und asynchrone


Kommunikation

© 2018-21 Jörg Ott | GBS | IN 0009 14


Synchron vs. Asynchron
• Kopplungsgrad zwischen Prozessen
• synchron: beide Prozesse werden zur Nachrichtenübertragung
synchronisiert, blockierend
• asynchron: Entkopplung von Sender und Empfänger, nicht blockierend

• Muster der Nachrichtenkommunikation


• Meldung (Signal, nicht mit Linux-Signals verwechseln!)
• Einzelne Nachricht vom Sender zum Empfänger (unidirektional)
• Wenige Daten werden übertragen.
• Beispiel: Mitteilung einer Zustandsänderung (Datei fertig gedruckt)
• Aber: häufig Empfangsbestätigung erforderlich, Acknowledgment (Ack)

• Auftrag (Request – Response)


• Interaktion zwischen Sender und Empfänger (bidirektional)
• Beispiel: Anfrage nach bestimmten Daten. Antwort enthält geforderte Daten

© 2018-21 Jörg Ott | GBS | IN 0009 15


Schlichter, TU München 6.3. NACHRICHTENBASIERTE KOMMUNIKATION

Es ist auch möglich das Merkmal Synchronität nicht auf die Nachrichtentrans-
Asynchrone Meldung
aktion, sondern getrennt auf Sender und Empfänger anzuwenden. Damit las-
sen sich asynchrone und synchrone Formen des Nachrichtenversands und -
empfangs
• Sender (S) übergibt diebeliebig kombinieren.
Nachricht an den Nachrichtendienst des
Betriebssystems (send())
Meldung
• BS puffert Nachrichten
• Asynchron: S
• wartet nicht,Meldung
Asynchrone bis der Empfänger die Nachricht empfangen hat
• Empfänger (E) Sender
kann Nachricht
wird lediglichmittels Ablieferungempfangen
bis zur recv() der Meldung an das Nachrichtensy-
• Falls keine Nachricht gepuffert ist wird der blockiert.
stem (Kommunikationssystem) Empfänger blockiert, bis eine
Nachricht gesendet wird
Sender S Nachrichtendienst ND Empfänger E

send
Meldung
receive

© 2018-21 Jörg Ott | GBS | IN 0009 16


Zeit
Synchrone Meldung
• Der Empfänger sendet nach Erhalt der Nachricht eine Bestätigung
• Der Sender wartet nach dem Senden auf die Empfangsbestätigung
• Die Empfangsbestätigung enthält hier keine Daten sondern dient nur der
Synchronisation
• Alternativ: Rendezvous-Verfahren
• Sender und Empfänger
Schlichter, TUstellen
Münchenvor Austausch der6.3.Meldung die Sende-
NACHRICHTENBASIERTE und
KOMMUNIKATION
Empfangsbereitschaft her
• Die Nachricht muss nicht gepuffert werden
Sender S Nachrichtendienst ND Empfänger E

send Meldung

receive

Quittung

© 2018-21 Jörg Ott | GBS | IN 0009 Zeit 17


Asynchroner Auftrag
• Auftrag und Resultat werden als unabhängige Meldungen verschickt
• Zwischen send() und recv() kann der Sender weitere Aufträge
versenden
• Die Aufträge können an den gleichen oder andere Empfänger gesendet
werden
Sender S Nachrichtendienst ND Empfänger E

send Auftrag receive

Auftrags
bearbeitung
receive Resultat reply
result

Zeit

© 2018-21 Jörg Ott | GBS | IN 0009 18


Synchroner Auftrag
• Nachrichtenbearbeitung und Senden des Resultats sind Teil
der Transaktion
• Zum Beispiel Aufruf einer Webseite
Sender S Nachrichtendienst ND Empfänger E

send Auftrag receive

Auftrags
bearbeitung
Resultat reply

Zeit

© 2018-21 Jörg Ott | GBS | IN 0009 19


Bewertung synchron vs. asynchron
• Vorteile von asynchronem Senden:
• Nützlich für Echtzeitanwendungen, wenn sendender Prozess nicht
blockiert werden darf
• Ermöglicht parallele Abarbeitung durch Sender und Empfänger
• Anwendbar zum Signalisieren von Ereignissen

• Nachteile
• Verwaltungsoverhead im Betriebssystem (Puffer für Nachrichten)
• Behandlung von Fehlern schwieriger
• Keine direkte Benachrichtigung des Senders möglich
• Paketverlust (durch volle Puffer, insbesondere bei Netzkommunikation)
• Wiederholung von Paketen

• Typischerweise wird asynchrone Kommunikation verwendet


• Vor allem, wenn unklar ist, ob Empfänger erreichbar oder wie schnell
mit einer Antwort zu rechnen ist
• Option: Threads verwenden, um synchron und asynchron zu mischen
© 2018-21 Jörg Ott | GBS | IN 0009 20
Beispiel

Dispatcher-Thread Worker-Threads

while (TRUE) { while (TRUE) {


get_next_request (&buf); wait_for_work (&buf); // block
handoff_request (&buf); look_for_page_in_cache (&buf, &page);
} if (page_not_in_cache (&page));
read_page_from_disk (&buf, &page);
return_page (&page);
}

© 2018-21 Jörg Ott | GBS | IN 0009 21


Message Passing
• Beispiel: Lösung des Erzeuger-Verbraucher Problems mit
Hilfe von synchronem Message Passing.
• Verwendung der Funktionen send() und recv().
• Die Synchronisation von Erzeuger und Verbraucher erfolgt durch das
Kommunikationssystem selbst, es sind keine Semaphore notwendig
• Bemerkung: Kein gemeinsamer Speicherbereich, der bzgl. der Zugriffe
von Erzeuger und Verbraucher synchronisiert werden muss

// Erzeuger // Verbraucher

while (true) { while (true) {


data = produce_item (); recv (E, data);
send (V, data); consume_item (data);
} }

© 2018-21 Jörg Ott | GBS | IN 0009 22


Streams
• Bisher
• Verbindungslose Kommunikation
• Keine Annahme über den Art des Nachrichtenversands
• Ein Strom (engl. Stream) = Abstraktion einer Verbindung
• Nachrichten werden auf dem Kommunikationsweg gepuffert
• Die versendeten Nachrichten werden als logischer Bytestrom vereinigt
• Der Bytestrom kann unabhängig von den Nachrichtengrenzen
verarbeiten werden
• Achtung: wer Nachrichtengrenzen braucht, muss diese selbst hinzufügen
• Dienste des Betriebssystems: Verbindungsauf- und -abbau, lesen und
schreiben in Strom
• Beispiel: Input/Output Streams in Java oder C++
send (120 Bytes)
send (74 Bytes)
Sender send (233 Bytes)
Strom receive (50 Bytes)
receive (377 Bytes)

Empfänger
© 2018-21 Jörg Ott | GBS | IN 0009 1 Byte 23
Pipes
• Das Pipe-Konzept (z. B. in Unix, Windows) dient zur
Realisierung von Strömen
• Eine Pipe (“|”, Röhre) ist ein unidirektionaler Strom zwischen zwei
Kommunikationspartnern
• Es kann auch bidirektionale Kommunikation mit Paaren von Pipes realisiert
werden
• Eine Pipe erlaubt FIFO-artigen Datentransfer: open pipe, read, write
• Blockieren bei voller Pipe (write) und bei leerer Pipe (read)
• Pipes können als virtuelle Dateien realisiert sein (named pipes)
• Unter Linux oft auf der Kommandozeile:
Prozess1.stdout → Prozess2.stdin)
• cat <datei> | wc -l
• grep “<stdio.h>” /usr/src/linux-source-4.8 -R | wc -l

Prozess 1 Prozess 2

Schreiben Lesen
© 2018-21 Jörg Ott | GBS | IN 0009 24
Pipes int main (...) {
int p [2];
pipe (p);
• Verwendung von Pipes
• Die Funktion pipe() erstellt sendData (p [1]) ;
receiveData (p [0]) ;
zwei Kommunikationsendpunkte }
• Einer davon kann z.B. beim fork() void sendData (int fd) {
an den Kindprozess übergeben const char *msg = “Wello, world";
werden uint16_t len = strlen (msg);
uint16_t nLen = htons (len);
• Alternativ: Verwendung in
unterschiedlichen Threads send (fd, &nLen, sizeof (nLen));
send (fd, msg, len);
}
• Named Pipes void receiveData (int fd) {
• Für die Kommunikation zwischen char msg [1024];
mehreren Prozessen sind auch uint16_t nLen;
uint16_t len;
Named Pipes möglich
• Diese tragen einen Namen und recv (fd, &nLen, sizeof (nLen));
len = ntohs (nLen);
sind im Dateisystem verlinkt recv (fd, msg, sizeof (msg) − 1);
msg [len] = ’\0’;
printf ("\%u \%s\n", len, msg);
© 2018-21 Jörg Ott | GBS | IN 0009 } 25
Adressierung: Ports
• Bisherige Annahmen
• Feste Beziehung zwischen Sender und Empfänger über PID / Namen
• Prozesse sollen Nachrichten im eigenen Adressraum
entgegennehmen können
• Prozesse benötigen eigene Nachrichtenpuffer für neue, nicht
angenommene Nachrichten

• Problem
• Prozessnummern ändern sich und Prozessnamen sind nicht eindeutig
• Prozesse wollen unter Umständen mit mehreren Partnern gleichzeitig
kommunizieren.

• Lösung
• Einführung von Ports als logische Abstraktion von
Kommunikationsendpunkten
• Wir wählen Ports der Internet-Protokolle als Beispiel

© 2018-21 Jörg Ott | GBS | IN 0009 26


Historisches: Ursprüngliche Terminologie
und Architektur im Internet (1974)
Process Port Process
Process Process
Process Process
Connection:
Association w/o a path
Transmission Transmission
Control Control
Program Program

Host Network GW Network GW Network Host

Nach: Robert E. Kahn, Vinton G. Cerf: A Protocol for Packet Network Intercommunication, IEEE Trans on Comm, May 1974

© 2018-21 Jörg Ott | GBS | IN 0009 27


Ports
• Ein Port gehört eindeutig zu einem Prozess
• zu einer gegebenen Zeit

• Empfängerprozess kann senderspezifische Ports einrichten


• Einem Port kann ein eigener Thread zugeordnet werden

• Mehrere Ports pro Prozess möglich


• z.B. 65.535 TCP-Ports pro IP-Adresse
• Portnummern 0 – 1023 sind fest reserviert für bestimmte Protokolle
(Well-known Ports)
• Portnummern 1024 – 49151 für registrierte Anwendungen (IANA)
• Portnummern 49152 – 65535 dynamisch vom BS zugewiesen
• etwa für abgehende Verbindungen

© 2018-21 Jörg Ott | GBS | IN 0009 28


Ports (2)
• Passive Prozesse (z.B. Server)
• Registrieren sich auf einer (oder mehrerer) Portnummer(n)
• Warten auf eigehende Verbindungen (TCP) oder Nachrichten (UDP)
• Ein (TCP-)Port entspricht einer FIFO-Warteschlange
• Die Warteschlange sammelt die Verbindungswünsche
• Die maximale Länge ist abhängig vom Betriebssystem, (z. B. 50)
• Es werden keine weiteren Verbindungswünsche akzeptiert, wenn die
Warteschlange voll ist

• Aktive Prozesse (z.B. Client)


• Initiieren die Interaktion mit einem passiven Prozess
• Erhalten hierfür dynamisch vom BS eine freie Portnummer
• Auf dieser empfangen Sie dann auch Daten
• Identifikation einer Kommunikationsbeziehung durch 5-Tupel
• Quell-IP-Adresse, Ziel-IP-Adresse, Quell-Port, Ziel-Port, Protokoll
• Vom BS verwendet, um eingehende Nachrichten zuzuordnen

© 2018-21 Jörg Ott | GBS | IN 0009 29


Adressen im Internet

https://www.acm.org/index.html
DNS server

Port: 51111 @
130.233.238.138 Port 443 @
5.79.89.115

00-16-41-52-DE-EF 00-0D-56-2A-AC-92

© 2018-21 Jörg Ott | GBS | IN 0009 30


Ports
• Beispiele Protokoll Port Beschreibung
echo 7 Sendet empfangene Daten zurück
SSH 22 Secure Shell (interaktive Terminal-Sitzung)
SMTP 25 Versenden von E-Mail (zwischen Servern)
DNS 53 Auflösung von Domain-Namen
HTTP 80 Unsicheres HTTP
HTTPS 443 Sicheres HTTP
SMTPS 465 Sicheres SMTP
IMAPS 993 Protokoll zum sicheren E-Mail-Abruf

• Viele weitere well-known Ports


• siehe /etc/services (unter Linux)
• https://www.iana.org/assignments/service-names-port-
numbers/service-names-port-numbers.xhtml
• Zustände von Ports: offen, geschlossen, blockiert.
© 2018-21 Jörg Ott | GBS | IN 0009 31
Kurze Erinnerung
• Interprozesskommunikation
• Verschiedene Kommunikationsformen
• Synchron vs. asynchron
• Schmalbandig vs. breitbandig
• Nachrichtenbasiert vs. Datenströme
• Meldungen vs. Request-Response-Interaktionen
• Rendezvous-Problem

• Spezifische Mechanismen
• Signale
• Shared Memory
• Pipes
• Ports und Adressierung (im Internet)
• Sockets

© 2018-21 Jörg Ott | GBS | IN 0009 32


Sockets
• Bisherige Annahmen
• Verbindungslose Kommunikation mit Nachrichtenversand (UDP)
• Bei verbindungsorientierter Kommunikation (TCP) muss zwischen den
Endpunkten ein logischer Kanal aufgebaut werden
• Abstraktion im BS für beide Interaktionsformen:
socket („Steckdose“)
• logische Verbindung zwischen Kommunikationspartnern
• typischerweise bidirektional, kann aber einseitig geschlossen werden
• typischerweise eine Zuordnung von zwei Endpunkten (Ports) (und ggf.
IP-Adressen)
• aber auch als Broadcast (alle) oder Multicast (selektiv) möglich
• ermöglicht verbindungsorientierte, strombasierte Kommunikation

• BSD 4.2 Unix Socket API für Netzprogrammierung


• Details zu Socket-Programmierung später

© 2018-21 Jörg Ott | GBS | IN 0009 33


Sockets (2)
• Abstraktion für bidirektionalen Datenaustausch
Input Strom

Client Server

Output Strom

Socket Verbindung

• Lokale Integration durch das Betriebssystem


• Socket-Deskriptoren == File-Deskriptoren
• Unterstützung gleicher System-Calls
• read(), write(), close()
• Besonderheiten für das Erzeugen und Verbinden von sockets
• socket(), connect(), bind(), listen(), … (analog zu pipe())
• Steuerung
• setsockopt(), getsockopt(), ioctl()

© 2018-21 Jörg Ott | GBS | IN 0009 34


Pipes, Sockets und Prozesse
• Pipes und Sockets liefern Ein-/Ausgabe über
Prozessgrenzen hinweg

• Was passiert, wenn ein Prozess terminiert, der mit einem


anderen verbunden ist?
• Die Pipe bzw. Socket-Verbindung wird geschlossen
• Signalisierung kann verschiedene Formen annehmen
• EOF für Eingabe
• Linux-Signal: SIGPIPE
• Fehlermeldung, dass der entsprechende Deskriptor nicht mehr funktioniert
• Erfordert entsprechende Fehlerbehandlung
• Signal wird aber nur generiert, wenn die entsprechende
Verbindung wirklich keinen Gegenüber mehr hat
• Wichtig beim Erzeugen von Kind-Prozessen

© 2018-21 Jörg Ott | GBS | IN 0009 35


Pipes, Sockets und Prozesse (2)
• Exkurs zu Kernel-Ressourcen
• Gilt für alle Formen von I/O-Deskriptoren
• Standardein-/-ausgabe, Pipes, Sockets, geöffnete Dateien

• Wenn eine Ressource geöffnet/genutzt wird, erhält sie


• eine entsprechende Datenstruktur
• Informationen über die Ressource
• einen Reference-Counter
• Wie oft diese Ressource gerade genutzt wird
• Innerhalb eines Prozess
• Über Prozessgrenzen hinweg
2. fork ()

Deskriptor 0 Deskriptor 0
Prozess 1

Prozess 2
Deskriptor 1 Ressource Deskriptor 1
… 1. dup (1) X
Deskriptor k Deskriptor k
Ref count = 1
Ref count = 2
Ref count = 4
© 2018-21 Jörg Ott | GBS | IN 0009 36
Pipes, Sockets und Prozesse (3)

Prozess 1

pipe (pipe_fd);

pipe_fd [1] == 4
pipe_fd [0] == 3
FD=4

FD=3
Prozess 1 Prozess 1

© 2018-21 Jörg Ott | GBS | IN 0009 37


Pipes, Sockets und Prozesse (4)

FD=4

FD=3
Prozess 1 Prozess 1

fork ();
FD=4

FD=3
close (3);
Prozess 1 Prozess 1
X
X
FD=4

FD=3
Prozess 2 close (4); Prozess 2

© 2018-21 Jörg Ott | GBS | IN 0009 38


Pipes, Sockets und Prozesse (5)
• Durch ein fork() nutzen plötzlich zwei Prozesse eine
gemeinsame Ressource im Kern
• Trotz sonst getrennter Adressräume
• Implikationen
• Wenn beide Prozesse darauf schreiben, ist die Reihenfolge der
einzelnen Ausgaben nicht definiert
• Siehe die Synchronisation der Ausgabe mehrerer Threads
• Wenn beide Prozesse davon lesen, ist nicht definiert, welcher Prozess
welchen Teil der Eingaben erhält
• Wenn ein Prozess die Pipe/Verbindung schließt oder terminiert, so
wird diese durch den anderen Prozess immer noch offen gehalten
• Es wird also kein EOF, SIGPIPE oder Verbindungsende signalisiert
• Denn der andere Prozess kann ja noch Daten senden.

• Wichtig: Deskriptoren schließen, die in einem Prozess nicht


mehr gebraucht werden (z.B. in einer Shell mit Pipes)
© 2018-21 Jörg Ott | GBS | IN 0009 39
Client-Server-Modell
• Das Client-Server Modell basierend auf der verteilten Verarbeitung
synchroner Aufträge
• Annahme: Endpunkte (Clients) sind ressourcenarm, Server sind
ressourcenstark
• Server: ein dedizierter Prozess, der einen Dienst zur Verfügung stellt
• Beispiele: Dateidienst (File-Server, Web-Server), Namensdienst (DNS-Server)
• Client initiiert Aufträge an einen von einem Server angebotenen Dienst
• Zuvor findet er den (bzw. einen geeigneten) Server z.B. über einen Namensdienst

• Clients sind kurzlebigere Prozesse und einem Server a-priori nicht


bekannt
• Server sind langlebige Prozesse, Aufträge werden in einzelnen Threads
(Worker-Threads) abgearbeitet
• Clients und Server kommunizieren über Nachrichten und werden i.d.R.
auf verschiedenen Rechnern ausgeführt
• Diese Nachrichten können dennoch über einen Datenstrom übertragen werden

© 2018-21 Jörg Ott | GBS | IN 0009 40


Alternative: Peer-to-Peer-Modell (P2P)
• Keine Unterscheidung zwischen Client und Server
• Die beteiligten Systeme übernehmen beide Rollen
• Prinzipieller Ansatz
• Eine Gruppe von Systemen organisiert sich selbst
• Systeme treten der Gruppe explizit bei
• Auffinden der Gruppe z.B. über DNS
• Systeme bauen Verbindungen zueinander auf
• z.B. Ringstruktur, Grid, Mesh, ...
• Jedes System steuert Ressourcen zur Gemeinschaft bei
• Speicherplatz, Rechenkapazität, Dienste
• Verteilter Ansatz statt zentral bereitgestellter Ressourcen
• Systeme wachen übereinander und ersetzen ausfallende Peers
• Angebotene Dienste werden in gruppenspezifischen Verzeichnis
(Directory Service) registriert
• Diese können mit einem Discovery-Protokoll gefunden werden

• Strukturierung möglich (z.B. reguläre Peers vs. Super-Peers)


• In der Vorlesung nicht weiter betrachtet
© 2018-21 Jörg Ott | GBS | IN 0009 41
Software-Bussysteme
• Bisherige Annahmen
• (Verbindungsorientierte) Kommunikation zwischen jeweils zwei Endpunkten
• Prozesse können / wollen Aktivitäten miteinander abstimmen
• Sie sind daher an gegenseitigen Benachrichtigungen interessiert
• Bei gleichzeitiger Kommunikation mit mehreren Kommunikationspartnern
müssen (quadratisch) viele Verbindungen aufgebaut werden
• Lösung: Kommunikation über einen gemeinsamen Nachrichten-Bus

Prozess A
Prozess A Prozess A Prozess A
Prozess F Prozess B

Software-Bus

Prozess E Prozess C
Prozess A Prozess A Prozess A
Prozess D

N x (N – 1) Verbindungen: O(N2) N Verbindungen: O(N)

© 2018-21 Jörg Ott | GBS | IN 0009 42


Beispiel: Dbus (Linux)
• In Analogie zu Hardware-Bussystemen
• PCI Express Bus (in PCs), frühes Ethernet
• Ein oder mehrere Busse für alle Kommunikationspartner (System Bus,
Session Bus)
• Adressierung über Namen (well-known names)
• Jeder Teilnehmer bekommt eine Adresse und einen oder mehrere Namen
• Konventionen über Namensvergabe erforderlich (wie bei Ports)
• Möglichkeit, Signale und Funktionen zu registrieren
• Verschiedene Interaktionsformen
• Remote Method Invocation (RMI) / Remote Procedure Call (RPC)
• Request-Response
• Publish/Subscribe (Beispiel: MQTT)
• Prozesse registrieren Interesse an bestimmten Nachrichten/Ereignissen (über Namen)
• Ereignisse werden dann unter diesen Namen „publiziert“ und erreichen genau die
Interessenten
• Geschwindigkeit: Früher rein im Userspace, mittlerweile auch im Kernel

© 2018-21 Jörg Ott | GBS | IN 0009 43


Beispiel: Dbus (Linux)
• Vorteile
• Kanal ist breitbandiger als reine Linux-Signale
• Applikationen können sich für Nachrichten selektiv registrieren

• Beispiele
• Neue Hardware (z.B. USB-Stick) verbunden. Dateimanager kann
direkt reagieren.
• Network Manager setzt neue IP-Adresse. Applikationen können
reagieren.
• Mit folgendem Befehl können alle auf dem Bus verbundenen
Endpunkte gelistet werden
• dbus-send -system -dest=org.freedesktop.DBus -print-reply
/org/freedesktop/DBus org.freedesktop.DBus.ListNames
• Die Einträge mit Namen bieten registrierte Dienste an

© 2018-21 Jörg Ott | GBS | IN 0009 44


Socket-Programmierung

• Sockets eingeführt in BSD 4.2 Unix


• BSD-Unix-Mechanismus für Interprozesskommunikation
• Transparenz lokaler und entfernter Kommunikation
• Unterstützen unterschiedliche Interaktionsformen
• Essentiell für die Verbreitung von TCP/IP in den 1980ern!

© 2018-21 Jörg Ott | GBS | IN 0009 45


Übersicht
• Sockets abstrahieren von den technischen Details der
Kommunikation
• Übertragungsmedium, Paketgröße, Paketwiederholung bei Fehlern

• Ein Socket unterstützt eine Reihe von Basisoperationen:


• socket(): Aufbau eines neuen Sockets (anfangs als einzelner
Endpunkt)
• bind(): Server: assoziiere Socket mit einem Port
• listen(): Server: warte auf eintreffende Daten
• accept(): Server: akzeptiere Verbindungswünsche von Clients
• connect(): Client: Initiierung der Verbindung zum Server
• send(): Senden von Daten. Alternativ: write()
• recv(): Empfangen von Daten. Alternativ: read()
• close(): einseitiges Beenden der Verbindung

© 2018-21 Jörg Ott | GBS | IN 0009 46


Ablauf: Server
• Randbedingungen: Der Server...
• kommuniziert mit N Clients, die a priori nicht bekannt sind
• muss auf eintreffende Verbindungswünsche reagieren können
• nimmt die Assoziierung mit einem Port vor und akzeptiert
Verbindungswünsche
• Ablauf aus Serversicht
• socket(): Es wird zuerst ein ungebundener Socket erzeugt
• bind(): Der Socket wird mit einem bestimmten Port verbunden
(localhost:4444)
• listen(): Anschließend wartet der Server auf Verbindungswünsche
von Clients
• accept(): Eingehende Verbindungswünsche werden einzeln
akzeptiert und liefern jeweils einen neuen Socket
• read/write(): Austausch von Daten zwischen Client und Server
• close(): Schießen der Verbindung auf Serverseite

© 2018-21 Jörg Ott | GBS | IN 0009 47


Anlauf: Client
• Randbedingungen: Der Client...
• initiiert eine Verbindung durch Senden eines Verbindungswunsches an
den Port des Servers

• Ablauf aus Clientsicht:


• socket(): Es wird zuerst ein ungebundener Socket erzeugt
• connect(): Der Socket wird mit dem Port des Servers verbunden
(z.B. localhost:4444)
• read/write(): Austausch von Daten zwischen Client und Server
• close(): Schießen der Verbindung auf Clientseite

© 2018-21 Jörg Ott | GBS | IN 0009 48


Beispiel: Einfache Client-Server-Interaktion
Client Server
Socket erstellen socket()

An Port binden bind()


socket() Socket erstellen Auf Verbindungen warten listen()
Verbindungsaufbau
connect() Verbinden zum Server
Verbindung aus dem
send() Senden einer Anfrage accept()
Kern holen

Warten auf Daten und


Warten auf Anwort und recv()
recv() Lesen sobald eingetroffen
Lesen sobald eingetroffen
Senden der Antwort send()

Warten auf Daten und recv()


Lesen sobald eingetroffen
send() Senden von Daten

Schließen der Verbindung close()

close() Schließen der Verbindung

© 2018-21 Jörg Ott | GBS | IN 0009 49


Socket-Programmierung: Details

© 2018-21 Jörg Ott | GBS | IN 0009 50


Typische Programmstruktur
Start Initialisierung
} Kommandozeile parsen, Argumente
interpretieren
Init } Ggf. Rechnernamen auflösen
} Sockets erzeugen, ggf. Port registrieren
} Signal-Behandlung initialisieren
Wait

Hauptschleife
} Socket-Deskriptoren verwalten
Y
INT? } Daten lesen, interpretieren
} Ausgaben/Antworten erzeugen
N } Signal-, Timeout und Fehlerbehandlung
Summary Process
Aufräumen
} Alle Deskriptoren schließen
End } Speicher freigeben
} Geordnet terminieren

© 2018-21 Jörg Ott | GBS | IN 0009 51


Socket erzeugen
int socket(domain, type, proto)

• Erzeugt einen neuen Kommunikationsendpunkt


• Domain: verschiedene Adressarten (~30 in socket.h)
• (Named) Pipes (e.g., AF_UNIX), ...
• Internet Protocols (AF_INET, AF_INET6)
• Type: unterschiedliche Interaktionsformen
• SOCK_STREAM: TCP = stromorientierte Kommunikation
• SOCK_DGRAM: UDP = nachrichtenbasierte Kommunikation
• Achtung: UDP ist unzuverlässig!

• Proto: Protokollfamillie
• Muss zur Domain passen, meistens auf 0 gesetzt

© 2018-21 Jörg Ott | GBS | IN 0009 52


Datenstrukturen für Adressen
• Adressierung eines Kommunikationspartners über dessen
IP-Adresse
• Spezialfall: lokaler Rechner: 127.0.0.1 bzw. ::1 (localhost)

struct sockaddr_in { struct sockaddr_in6 {


sa_family_t sin_family; sa_family_t sin6_family;
in_port_t sin_port; in_port_t sin6_port;
struct in_addr sin_addr; uint32_t sin6_flowinfo;
}; struct in6_addr sin6_addr;
};

IPv4-Adresse (historisch motiviert, unhandlich) IPv6-Adresse (in Kurzform)

struct in_addr { struct in6_addr {


in_addr_t s_addr; uint8_t u6_addr8[16];
}; #define s6_addr in6_u.u6_addr8
};

© 2018-21 Jörg Ott | GBS | IN 0009 53


Passives Warten (z.B. Server)
• Registieren eines Ports
• Warten auf den Empfang von Nachrichten (UDP)
• Warten auf eingehende Verbindungen (TCP)
int bind (int sd, struct sockaddr *, socklen_t len);

• UDP: fertig

• TCP: Einrichten einer Queue für eingehende Verbindungen


• int listen (int sd, int backlog);
• Gestattet <backlog> ausstehende Verbindungen im Kern

• setsockopt() und ioctl()


• Zum Setzen weiterer Socket-Parameter
• Siehe Man-Pages für Details, hier nur sekundär von Bedeutung
© 2018-21 Jörg Ott | GBS | IN 0009 54
Verbindungen (TCP)
• int connect (int sd, struct sockaddr *target, socklen_t len);
• Baut (synchron) eine Verbindung zu einem Server auf
• Synchron
• Systemcall kehrt erst zurück, wenn die Verbindung aufgebaut wurde oder
• Wenn ein Fehler gemeldet wird (z.B. kein Serverprozess gestartet) oder
• Wenn eine im System vorgegebene Wartezeit überschritten wurde (Timeout)
(z.B. weil der Server nicht erreichbar war)
• Asynchron: Option TCP_NODELAY für den Socket einschalten
• new_sd = accept (int sd, struct sockaddr *peer, socklen_t *peerlen);
• Annehmen einer neuen Verbindung
• Explizites Ablehnen nicht vorgesehen → sofortiges close()
• Liefert einen neuen Socket-Deskriptor für diese Verbindung
• Zeigt an, wer der Kommunikationspartner der Verbindung ist
• Der ursprüngliche (sd) bleibt zum Annehmen weiterer Verbindungen
• close (sd)
• schließt eine Verbindung; Achtung: Datenverlustrisiko!
• shutdown (int sd, int mode)
• Lokal: nicht mehr senden/empfangen

© 2018-21 Jörg Ott | GBS | IN 0009 55


Senden von Daten
• Datenstrom (TCP)
write (int sd, char *buffer, size_t length);
writev (int sd, struct iovec *vector, int count);
• Liste von Puffern mit Speicherbereichen und Länge

send (int sd, char *buffer, size_t length, int flags)


• Steuerung des Versendens durch ergänzende Flags

• Nachrichtenbasiert (UDP)
sendto (int sd, char *buffer, size_t length, int flags,
struct sockaddr *target, socklen_t addrlen)
sendmsg (int sd, struct msghdr *msg, int flags)
• Zieladresse (muss pro Nachricht angegeben werden)
• Zeiger auf Speicherbereich mit Daten und Länge
• Steuerung des Versendens durch ergänzende Flags

© 2018-21 Jörg Ott | GBS | IN 0009 56


Empfangen von Daten
• Datenstrom (TCP)
read (int sd, char *buffer, size_t length);
readv (int sd, struct iovec *vector, int count);
• (Liste von) Puffer(n) mit Speicherbereich(en) und Länge

recv (int sd, char *buffer, size_t length, int flags)


• Steuerung des Empfangvorgangs über Flags
• z.B. auch Fehlermeldungen, asynchron empfangen

• Nachrichtenbasiert (UDP)
recvfrom (int sd, char *buffer, size_t length, int flags,
struct sockaddr *target, socklen_t addrlen)
recvmsg (int sd, struct msghdr *msg, int flags)
• Liefert die Absenderadresse
• Puffer zum Ablegen der Daten
• Steuerinformationen
© 2018-21 Jörg Ott | GBS | IN 0009 57
Weitere Funktionen
• getpeername (int sd, struct sockaddr *peer, size_t *len)
• Auslesen der Adresse des Kommunikationsparters

• getsockname (int sd, struct sockaddr *local, size_t *len)


• Auslesen der eigenen Socket-Adresse
• Nützlich für dynamisch vom Betriebssystem zugewiesene Ports

• Modifizieren von Socket-Einstellungen


getsockopt (int sd, int level, int option_id, char *value, size_t length)
setsockopt (int sd, int level, int option_id, char *value, size_t length)
• Beispiel
• Puffergröße im Kern, Paket-Lebensdauer (TTL), Protokollparameter

ioctl (int sd, int request, ...);


fcntl (int sd, int cmd [, long arg] [, ...]);
• Beispiel
• Asynchrones Senden/Empfangen
© 2018-21 Jörg Ott | GBS | IN 0009 58
Namensauflösung
• Umwandeln einen symbolischen Namens in eine
protokollspezifische Adresse
• Achtung: unterschiedliche Adressformate und Längen

• APIs
• gethost*(), inet_aton(), inet_ntoa()
• getaddrinfo(), inet_pton(), inet_ntop()

ð alt, funktionieren aber noch

© 2018-21 Jörg Ott | GBS | IN 0009 59


Alte Funktionen

int gethostname (char *name_buffer, int buffer_length)


struct hostent *gethostbyname (char *namestr)
struct hostent *gethostbyaddr (struct sockaddr *, size_t, int);

struct hostent {
char *h_name;
char **h_aliases;
int h_addrtype;
int h_length;
char **h_addr_list;
#define h_addr h_addrlist [0]
};

struct hostent *gethostent ();


endhostent ();

© 2018-21 Jörg Ott | GBS | IN 0009 60


getaddrinfo
int getaddrinfo(host,server,hints,result)
struct addrinfo {
int ai_flags; /* AI_PASSIVE, AI_CANONNAME,
AI_NUMERICHOST */
int ai_family; /* PF_UNSPEC */
int ai_socktype; /* SOCK_xxx */
int ai_protocol; /* 0 or IPPROTO_xxx for IPv4 and IPv6 */
size_t ai_addrlen; /* length of ai_addr */
char *ai_canonname; /* canonical name for nodename */
struct sockaddr *ai_addr; /* binary address */
struct addrinfo *ai_next; /* next structure in linked list */
};

void freeaddrinfo(struct addrinfo *res);


const char *gai_strerror(int errcode);
Konvertierungsfunktionen (1)
• IP-Adressen
Dotted decimal notation: aaa.bbb.ccc.ddd (nur IPv4)

in_addr_t inet_addr (char *buffer)


in_addr_t inet_aton (char *buffer)
char *inet_ntoa (in_addr_t ipaddr)

aaa.bbb.ccc.ddd (IPv4), aaaa:bbbb:cccc:dddd:eeee:ffff:gggg:hhhh (IPv6)


int inet_pton (int af, const char *src, void *dst)
dst: in_addr bzw. in6_addr

const char *inet_ntop (int af, const void *src, char *dst, size_t)
src: in_addr bzw. in6_addr
char dst [INET_ADDRSTRLEN] bzw. char dst [INET6_ADDRSTRLEN]

© 2018-21 Jörg Ott | GBS | IN 0009 62


Konvertierungsfunktionen (2)
• Network vs. Host Byte Order
• Daten im Netz werden immer “Big Endian” übertragen
• Lokale CPU verwendet eine andere Repräsentation
• Beispiel: Intel x86 nutzt “Little Endian”
Konvertierung in lokale Repräsentation potentiell notwendig
§ Erforderlich für “Little-Endian” (LSB-first) Architekturen wie Intel
§ No-op für MSB-first-Architekturen
§ Sollte immer gemacht werden für Portabilität
netshort = htons (hostshort) 16-bit
netlong = htonl (hostlong) 32-bit
hostshort = ntohs (netshort) 16-bit
hostlong = ntohl (netlong) 32-bit
§ Siehe auch
§ bswap_16(), bswap_32(), bswap_64() Quelle: Wikipedia-Artikel
§ htobe{16|32|64}(), htole{16|32|64}() zu „Endianness“
§ betoh{16|32|64}(), letoh{16|32|64}()

© 2018-21 Jörg Ott | GBS | IN 0009 63


Beispiel: Server
#include <arpa/inet.h>
#include <stdio.h>
#include <string.h>
#include <sys/socket.h>
#include <unistd.h>

int main (int argc, char *argv []) {


int s = 0, fd = 0;
struct sockaddr_in sa;
char sendbuf [1025] = "Message from Server\n";

if ((s = socket (AF_INET, SOCK_STREAM, 0)) == -1)


return -1;
memset (&sa, 0, sizeof (sa));
sa.sin_family = AF_INET ;
sa.sin_addr.s_addr = htonl (INADDR_ANY); // do not pick a specific local IP address
sa.sin_port = htons (5000);
if (bind (s, (struct sockaddr *) &sa, sizeof (sa)) == -1)
return -1;
if (listen (s, 10) == −1)
return −1;
while (1) {
fd = accept (s, NULL, NULL);
send (fd, sendbuf ,strlen (sendbuf), 0);
close (fd);
}
close (s);
return 0;
}

© 2018-21 Jörg Ott | GBS | IN 0009 64


Beispiel: Client
#include <arpa/inet.h>
#include <stdio.h>
#include <string.h>
#include <sys/socket.h>
#include <unistd.h>

int main (int argc, char *argv []) {


int fd = 0, n = 0;
char rb [1024] = { 0 };
struct sockaddr_in sa;

if ((fd = socket (AF_INET, SOCK_STREAM, 0)) < 0) {


return -1; // No socket available
}
sa.sin_family = AF_INET;
sa.sin_port = htons (5000);
sa.sin_addr.s_addr=inet_addr ("127.0.0.1");
if (connect (fd, (struct sockaddr *) &sa, sizeof (sa))) {
return -1; // Connect failed
}
while ((n = recv (fd, rb, sizeof (rb) −1, 0)) > 0) {
rb [n] = ’\0 ’;
printf ("%s\n", rb);
}
if (n < 0) return -1; // Error during recv
close (fd);
return 0;
}

© 2018-21 Jörg Ott | GBS | IN 0009 65


I/O-Multiplexing
• Was tun, wenn ein Prozess Daten auf mehreren
Verbindungen empfangen möchte
• Round-Robin asynchron abfragen (busy waiting) ist unpraktisch

• Betriebssystem liefert Funktionen, die das Überwachen


mehreren Eingabequellen gleichzeitig gestattet
• Blockieren, bis mindestens eine Eingabequelle Daten zu lesen hat
• Optional: bis ein Timeout abgelaufen ist

• Liefert dann eine Liste der Deskriptoren, von denen gelesen


werden kann

© 2018-21 Jörg Ott | GBS | IN 0009 66


I/O-Multiplexing: select
int select (maxfdset, readset, writeset, extset, timeout)

• Auflisten aller zu beobachtenden Deskriptoren (fdset)


• Ggf. Timeout bestimmen
• Datenstruktur struct timeval { … } zur Angabe des Zeitintervalls als
Paar (Sekunden, Mikrosekunden)
• (0, 0) == Busy Waiting
• NULL-Pointer == Blockieren (kein Timeout)
• Aufrufen von select()
• Rückgabewerte: Fehler untersuchen
• -1: Fehler untersuchen
• Fatal ® Terminate
• Reparierbar (z.B. interrupted system call) ® nochmal
• 0: Timeout-Behandlung
• > 0 = Anzahl der Deskriptoren mit z.B. verfügbaren Eingaben
• fdset zeigt an, welche Deskriptoren z.B. lesbar sind
• Durchgehen, Daten lesen, bearbeiten
© 2018-21 Jörg Ott | GBS | IN 0009 67
fd_set Makros

#include <sys/select.h>

fd_set rfdset; // Deskriptoren zum Warten auf Eingabe


FD_ZERO (&rfdset); // initial mit Nullen füllen
FD_SET (fd, &rfdset); // jeden Deskriptor einzeln setzen
...
select (..., &rfdset, NULL, NULL, NULL);
...
if (FD_ISSET(fd, &rfdset)) { // jeden Deskriptor einzeln prüfen
...
}

© 2018-21 Jörg Ott | GBS | IN 0009 68


I/O Multiplexing (poll)
int poll (struct pollfd [], int n_fd, int timeout)
struct pollfd {
int fd; // file descriptor
int events; // events to watch for
int revents; // occurred events
};

• Heißt zwar poll(), macht aber kein Polling (= Busy waiting)


• Poll events
• POLLIN Warten auf Eingabe / Eingabe verfügbar
• POLLOUT (Prüfen ob) Socket schreibbar (asynchrone E/A)
• POLLHUP, POLLERR
• Timeout in Millisekunden
• -1 == no timeout, 0 == return immediately (perform real polling)
• Nutzung vergleichbar mit select()
© 2018-21 Jörg Ott | GBS | IN 0009 69
Timeouts (1)
• Interprozesskommunikation nutzt oft Timeouts
• Häufiges Setzen, Zurücksetzen, Abschalten
• Muss deshalb effizient implementiert werden
• select () und poll () erlauben genau einen Timeout
• poll () in Millisekunden
• select () in Mikrosekunden mittels struct timeval
• Verwalten einer sortierten Liste aller Timeouts
• Jeweils immer die absolute Zeit merken, wenn Timeout gesetzt wird
• Außerdem Kontext merken, zu dem der Timeout gehört
• Beispiel: maximale Wartezeit auf Antwort, dann erneut versuchen
• Vor dem Aufrufen von select/poll
• Aktuelle – ebenfalls absolute – Zeit bestimmen (gettimeofday ())
• Den frühesten Timeout aus der Timeout-Liste nehmen
• Prüfen, ob dieser Zeitpunkt bereits verstrichen ist → ggf. sofort behandeln
• Schließlich kann viel Zeit seitdem Setzen des Timeout vergangen sein
• Abstand von frühestem Timeout zur aktuellen Zeit bestimmen
• Dieses Delta an poll/select() als Timeout übergeben
• Hierzu gibt es Event-Loop-Bibliotheken (etwa libevent oder libev)

© 2018-21 Jörg Ott | GBS | IN 0009 70


Timeouts (2)
Beispiel: Timeout 200ms
struct timeval tv, delta, now;

/* some event -> calculate absolute time till timeout in tv */


gettimeofday (&tv, NULL);
tv.tv_usec += 200*1000;
if (tv.tv_usec >= 1000000) {
tv.tv_usec -= 1000000;
tv.tv_sec++;
}

/* ... many other activities -> back in mainloop */


gettimeofday (&now, NULL);
delta.tv_usec = tv.tv_usec – now.tv_usec;
delta.tv_sec = tv.tv_sec - now.tv_sec;
if (delta.tv_usec < 0) {
delta.tv_usec += 1000000;
delta.tv_sec--;
}
if (delta.tv_sec < 0) {
/* timeout has also passed -> handle now */
}
switch (n = select (..., ..., ..., ..., &delta) {
...
}
© 2018-21 Jörg Ott | GBS | IN 0009 71
Fazit
• Verschiedene Konzepte zur Interprozesskommunikation
• Schmalbandig durch minimale Mitteilungen (z.B. Signale)
• Breitbandig zur Übermittlung komplexer bzw. großer Datenmengen
• Implizit durch gemeinsame Ressourcen
• Explizit durch Signale, Nachrichtenaustausch, Ströme
• Synchron vs. asynchron

• Wesentliche Mechanismen
• Gegeneinander abgegrenzte Nachrichten, z.B. UDP, DBus
• Ströme: Abstraktion nachrichtenbasierter Verbindungen, verdeckte
Nachrichtengrenzen
• Pipe: Unidirektionaler Strom zwischen zwei Kommunikationspartnern
• Port: Endpunkt einer Kommunikation, kann bei Bedarf dynamisch
eingerichtet und gelöscht werden
• Socket: Gemeinsame Abstraktion verschiedener
Kommunikationsformen zwischen zwei Endpunkten (Ports)
© 2018-21 Jörg Ott | GBS | IN 0009 72
Chair of Connected Mobility
Department of Informatics
Technische Universität München

Kapitel 06

Grundlagen Betriebssysteme und Systemsoftware


Speicherverwaltung

Prof. Dr.-Ing. Jörg Ott


Lehrstuhl Connected Mobility

Folien frei nach der Vorlage von Prof. C. Eckert (WS16/17, WS17/18) – danke!

© 2018-21 Jörg Ott | GBS | IN 0009 1


Ziele
• Speicherverwaltung
• Verwaltung des physischen Speichers: hier, Fokus auf
Hauptspeicherverwaltung
• Abbildung von virtuellen Prozess-Adressen auf physische
Speicheradressen
• Datenstrukturen zur Verwaltung von belegten und freien
Speicherbereichen
• Strategien zur Zuteilung von freien Speicherbereichen
• Virtueller Speicher
• Paging, Page-Tabellen
• Seitenersetzungsstrategien
• Fallbeispiel

© 2018-21 Jörg Ott | GBS | IN 0009 2


Fragen
• Was für verschiedene Möglichkeiten gibt es, mehrere
Prozesse „gleichzeitig“ und unabhängig voneinander im
Speicher zu halten?

• Was für Verwaltungsstrukturen brauche ich (und wieviel


„kosten“ die), um mit 1TB Hauptspeicher umzugehen?

• Warum ist ein Rechner mit hoher Auslastung manchmal


besonders langsam?

• Was kann ich tun, um schnelle Programme zu schreiben?

© 2018-21 Jörg Ott | GBS | IN 0009 3


Erinnerung: Von-Neumann-Architektur

© 2018-21 Jörg Ott | GBS | IN 0009 4


Speicherzugriff über den Bus (1)
• Ein ganz altes Beispiel: 6502 (8-Bit-Prozessor, 1975)
• Unkomplizierter als moderne Prozessoren
• 16 Adressleitungen
• 64 KB Speicher
• 8 Datenleitungen
• 1-Byte-Zugriff auf den Speicher
• R/W
• Daten lesen vs. schreiben
• !0 / !1 / !2
• Takt, Synchronisation beim Speicherzugriff
• Other pins (for those interested)
• IRQ/NMI: Interrupts
• RDY: run/suspend CPU operation
• RESet

Bild: http://atariage.com/forums/topic/196546-how-do-i-
read-a-pinout-with-memory-info/
https://de.wikipedia.org/wiki/MOS_Technology_6502
© 2018-21 Jörg Ott | GBS | IN 0009 5
Speicherzugriff über den Bus

CPU 6502, Taktfrequenz 2 MHz


Quelle: https://www.youtube.com/watch?v=Vq0x-ic9q04
© 2018-21 Jörg Ott | GBS | IN 0009 6
Anforderungen
• Ideale Welt
Hauptspeicher (Random Access Memory (RAM), Main
Memory) eines Rechners ...
• ... unbeschränkt groß, schnell, preiswert und nicht flüchtig (non-
volatile) bei Verlust der Stromversorgung

• Realität
• schnell zugreifbare Hauptspeicher deutlich teurer, als langsame
Hintergrundspeicher (u.a. Festplatten)

• Konsequenzen
• Große Datenvolumen werden auf langsamen Hintergrundspeichern
gespeichert
• Zur Verarbeitung müssen Daten jedoch im Hauptspeicher liegen
• Hauptspeicher ist eine knappe Ressource, die das Betriebssystem zu
verwalten hat
© 2018-21 Jörg Ott | GBS | IN 0009 7
Anforderungen (2)
• Weitere Probleme
• Prozessoren werden immer schneller, aber
• Die Speicherzugriffszeiten halten damit nicht Schritt (Von Neumann-
Flaschenhals)

• Aufgabe der Speicherverwaltung des Betriebssystems


• Von Neumann-Flaschenhals auflösen mit einer Speicherhierarchie
• Sehr schnelle, teure Speicher mit geringer Kapazität (wenige Megabyte) in
Prozessornähe (u.a. Caches)
• Schnelle, teure Hauptspeicher mit mittlerer Kapazität (einige Gigabyte
flüchtiger Speicher)
• Langsame, preiswerte Massenspeicher mit großer Kapazität (viele Terabyte)

© 2018-21 Jörg Ott | GBS | IN 0009 8


nführung Technis
Univers
Münche
rarchie

Speicherhierarchie
rhierarchie:

≈ 103 ≈ 10−9
Register

Instruktionsoperanden

größer ≈ 106 Cache ≈ 10−7 schnellere


Zugriffszeit
(Größenordnung
Cache-Zeilen (Größenordnung
in Bytes)
≈ 109 ≈ 10−5
in Sekunden)
Hauptspeicher
Seiten

≈ 1012 Festplatten ≈ 10−3

Dateien
≈ 1013 Bandlaufwerke ≈ 100

© 2018-21 Jörg Ott | GBS | IN 0009 9


kert Kapitel 06 — Speicherverwaltung
Adressraumkonzept
• Verwaltung des physischen Speichers
• Alle Programme haben vollen Zugriff auf den kompletten physischen
Hauptspeicher
• Wird u.a. implementiert in Sensoren, eingebetteten Systemen, frühen
Spielekonsolen, ...
• Probleme
• Jedes Programm belegt potentiell den gesamten Hauptspeicher (main
memory) des Rechners
• Programme können das im Hauptspeicher befindliche Betriebssystem
unbrauchbar machen
• Programme können sich (versehentlich) gegenseitig stören
• Lösung: Abstraktion vom physischen Speicher
• Einführung einer Speicherabstraktion in Form von Adressräumen
• (Abstrakte) Menge von Speicherzellen, die ein Prozess adressieren
kann. z.B. 4GByte
• Jeder Prozess erhält seinen eigenen, isolierten Adressraum
© 2018-21 Jörg Ott | GBS | IN 0009 10
Verwaltung von Adressräumen durch BS
• Physischer Adressraum des Hauptspeichers
• (physical address space)
• Folge von fortlaufend nummerierten Bytes, beginnend bei 0
• Die Position eines Bytes bezeichnet seine physische Speicheradresse
(physical address)
• Logischer Adressraum eines Prozesses
• Menge von adressierbarem Speicher.
• Die Position eines Bytes im logischen Adressraum bezeichnet seine
logische Adresse. Sie wird auch als virtuelle Adresse bezeichnet
• Bei einem logischen Adressraum von 4 GB (z.B. Linux), benötigt man
32-Bit Adressen
• Speicherabbildung (Memory Address Translation)
• Abbildung von logischen Adressen auf physische Adressen:
• Direkte, Basis- und Segment-Adressierung, sowie
• Seiten- und Segment-Seiten-Adressierung

© 2018-21 Jörg Ott | GBS | IN 0009 11


peicherabbildungen Technische
Universität
München
dressierung
Direkte Adressierung
rekte Adressierung:
• Jede logische (virtuelle) Adresse vi entspricht ihrer
e logischephysischen
Adresse vi entspricht
Adresse ihrer
pi physischen Adresse pi .

Logischer ...
v0 v1 v2 v3 vn−1 vn
Adressraum V

f ∶V�P
f f f f f f
px ∶= f (vx ) = vx

Physischer ...
p0 p1 p2 p3 pn−1 pn
Adressraum P
Abbildung: Direkte Adressierung

• Beispiele: 8080, Z80, 6502, viele Microcontroller, …


me? © 2018-21 Jörg Ott | GBS | IN 0009 12
kert Kapitel 06 — Speicherverwaltung
Direkte Adressierung (2)
• Mehrere Programme können auch hier ausgeführt werden
• Option 1: Extensives Swapping
• Zu einem Zeitpunkt ist immer nur ein Programm im Speicher und wird
ausgeführt
• Wenn das Betriebsystem ein anderes Programm ausführen will
• speichert es den Speicherinhalt des laufenden Programms auf die Festplatte
• lädt das nächste von der Festplatt in der Speicher
• Langsam!
• Option 2: Relokation
• Programme werden an unterschiedliche Stellen im Speicher geladen
• Beim Laden müssen dann die Adressen in den Programmen
umgeschrieben warden, damit sie zur Stelle im Speicher passen
• Aufwendig!
• Programme können sich immer noch gegenseitig stören, weil sie auf
den gesamten Speicher zugreifen können
• Ggf. durch Progress-spezifische Zugriffsrechte auf Speicherbereiche lösbar
© 2018-21 Jörg Ott | GBS | IN 0009 13
Direkte Adressierung: Relokation
• Beispiel für nötige Relokation
• a) und b) sind zwei unabhängige Programme
• Beide nutzen physische Adressen im Speicher
• c) zeigt ein mögliches Speicherlayout, wenn beide
Programme gleichzeitig im Speicher sind
• “JMP 28” würde hier ins Programm a) springen statt in c)
• Alle Adressen müssen beim Laden umgeschrieben
warden
• Dazu muss man alle
Befehle im Programm
kennen, die Adressen
verwenden und diese
beim Laden korrigieren
• Hier: 16380 addieren

© 2018-21 Jörg Ott | GBS | IN 0009 14


Basis-Adressierung
• Das BS legt für jeden logischen Adressraum eines
Prozesses eine Basisadresse bx fest
• Bei Prozess-Start wird die Basisadresse bx in das
Basisregister der CPU geladen
• Adressberechnung
• physische Adresse = logische Adresse + Basisadresse
• Berechnung erfolgt durch die CPU, bevor eine Adresse auf den
Speicherbus gelegt wird
• Vorteile
• Das BS kann Programme im Hauptspeicher verschieben (relocation)
• Das BS kann mehrere Prozesse zu einem Zeitpunkt in den
Hauptspeicher laden
• Nachteil: Aufwändige Additionsoperation
© 2018-21 Jörg Ott | GBS | IN 0009 15
ogramme im Hauptspeicher verschieben (relocation).
hrereBasisadressierung
Prozesse zu einem Zeitpunkt
(2) in den Hauptspeich
ge Additionsoperation
Logischer
b0 ∶ v0 b0 ∶ v1 b0 ∶ v 2 b1 ∶ v0 ... b1 ∶ v 5 b1 ∶ v6
Adressraum V

f ∶V�P
f f f f f f
px ∶= f (bx , vx ) = bx + vx

Physischer ...
p0 p1 p2 p3 pn−1 pn
Adressraum P

Abbildung: Basisadressierung
Kapitel 06 — Speicherverwaltung

© 2018-21 Jörg Ott | GBS | IN 0009 16


Speicherabbildungen Universität
München
dressierung – Anmerkungen

Vergleich: direkte vs. Basisadressierung


eich direkte und Basis-Adressierung:

Problem gelöst?
Direkt Basis
Jedes Programm belegt potentiell den gesamten 7 3
Hauptspeicher des Rechners.
Prozesse benötigen Kenntnis über Struktur des 7 3
Hauptspeichers.
Programme können das ebenfalls im Hauptspei- 7 3
cher befindliche Betriebssystem korrumpieren.

C. Eckert Kapitel 06 — Speicherverwaltung

© 2018-21 Jörg Ott | GBS | IN 0009 17


Segmentadressierung
• Unterteilung des Adressraums in logische Segmente,
unterschiedlicher Länge
• Beispiele für logische Segmente eines Prozesses:
Stack-, Daten-, Code-Segment
• Nutzen der Segmentierung
• u.a. Unterschiedliche Zugriffsberechtigungen für Segmente
• Segment-Adressierung: Pro Segment erforderlich
• eine Segmentanfangsadresse, das entspricht der Basisadresse
• die Länge des Segments
• CPU: stellt i. d. R. ein Segmentregister bereit
• Beispiel: Segmentadressierung beim Intel x86 Prozessor
• Verwaltung einer Tabelle: Global Descriptor Table (GDT)
• Eintrag in der Tabelle enthält für jedes Segment:
• Basisadresse und Länge des Segments
• Flags (Zugriffsbeschränkungen, Code-/Datensegment, etc.).
• Segmentregister: Index in die Global Descriptor Table

© 2018-21 Jörg Ott | GBS | IN 0009 18


Segmentadressierung
Anmerkungen
• Späte 32-Bit Betriebssysteme (Linux 2.6.8, 2004, Windows XP
SP2, 2004) nutzen Segmentierung zur Trennung von Code und
Daten
• 64-Bit-Betriebssysteme nutzen Segmentierung zum einfachen
Zugriff auf den Thread-Control-Block, der Informationen über die
Ausführungsumgebung einzelner Threads, aber auch thread-
lokale Variablen verwaltet (gs/fs-Segmentregister)
• Unter 64-Bit Betriebssystemen wird die GDT typischerweise nur
noch nach dem flat memory model befüllt und enthält Einträge,
die Code und Daten von Benutzer- und Kernel-Prozessen
trennen.
• Size-Bit in der GDT erlaubt einfaches Mischen von 32- und 64-
Bit-Maschinencode auf 64-Bit-Betriebsssystemen (Linux Multiarch
/ Windows SystemWindows on Windows 64 (SysWOW64))
© 2018-21 Jörg Ott | GBS | IN 0009 19
Beispiel Segmentadressierung x86
Segmentregister Global Descriptor Table
cs 0x01 Basis Länge Zugriff Typ
ss 0x03 0x10000 0x03000 Kernel Code
ds 0x03 0x20000 0x04200 User Code
es 0x03 0x30000 0x16300 Kernel Daten
fs 0x02 0x70000 0x02000 User Daten
gs 0x02

Beispiel: mov ax, ds:0x1234

0x1234 + 0x70000 = 0x71234

© 2018-21 Jörg Ott | GBS | IN 0009 20


Segmentierung: Swapping
• Irgendwann ist der Speicher voll
• Prozesse werden temporär auf die Festplatte ausgelagert
• Zur Erinnerung: Prozesszustand „ausgelagert“
• Wieder eingelagert, wenn sie fortgesetzt werden sollen

© 2018-21 Jörg Ott | GBS | IN 0009 21


Segmentierung: Dynamik
• Wie geht man damit um, dass ein Prozess wächst?

© 2018-21 Jörg Ott | GBS | IN 0009 22


Freispeicherverwaltung
• Geklärt (in erster Approximation)
• Adressabbildung: logische Adresse auf physische Adresse
• Zu klären
• Zuordnung von Hauptspeicherbereichen zu Adressräumen
Erforderlich
• Frei-Speicherverwaltung durch das BS mit
1. Datenstrukturen zur Verwaltung der Speicherbelegung
2. Strategien zur Belegung freier Speicherbereiche
• Datenstrukturen zur Freispeicherverwaltung, u.a.
1. Bitmap
2. Verkettete Liste von Frei-Speicherbereichen
• Strategien zur Verwaltung freier Speicherbereiche: u.a.
• First Fit, Next-Fit, Best-Fit,Worst-Fit
• Buddy-Verfahren
© 2018-21 Jörg Ott | GBS | IN 0009 23
Datenstruktur: Bitmap
• Aufteilung des Speichers in Blöcke gleicher Größe
• Einführung einer Bitmap zur Indexierung des Speichers
• Pro Block 1 Bit zur Repräsentation in der Map
• 1 = Block belegt, 0 = Block frei

• Beispiel: Adressangaben in Hexadezimal: z.B. 0x78


• Mögliche Speicherbelegung

A B C D E …

Index-Bitmap: 1 1 1 1 1 0 0 0 1 1 1 1 1 1 0 0 0 1 1 1 1 0 0 1 1 1 1 1 1 1 1 1 1 0 0 0 0 …

Im Speicher: 0xf8 0xfc 0x75 0xff 0x…

© 2018-21 Jörg Ott | GBS | IN 0009 24


Bitmaps (2)
• Problem: Wahl der Blockgröße
• Zu kleine Blöcke: es wird eine große Bitmap zur Verwaltung benötigt
• Zu große Blöcke: Gefahr von Speicherverschwendung (Verschnitt)
• Beispiel:
• Blockgröße 4 Byte, d.h. 1 Bit pro 32-Bit-Block erforderlich
• Die Bitmap belegt 1/32 des gesamten Speichers
• Vorteil einer Bitmap
• Einfacher, schneller Zugriff auf Speicherblöcke fixer Größe
• Nachteil
• Gegeben sei ein Prozess P, dessen logischer Adressraum k
Hauptspeicherblöcke umfasst
• Es werden k aufeinanderfolgende freie Blöcke im Hauptspeicher
benötigt
• Erfordert eine aufwendige lineare Suche nach k aufeinanderfolgenden
0-Bits in der Bitmap
• (Segmentierung gestattet immerhin Trennung von Text, Daten, Stack)
© 2018-21 Jörg Ott | GBS | IN 0009 25
Verkettete Liste
• Gegeben seien wieder Hauptspeicherblöcke einer festen
Länge b
• Das BS verwaltet eine Liste mit Bereichen bestehend aus
zusammenhängenden Hauptspeicherböcken
• Jeder Bereich ist entweder einem Prozess zugeordnet (P),
oder frei (F)
• Jeder Listen-Eintrag enthält
• die Anfangsadresse des Bereichs
• die Länge des Bereichs (in Blöcken)
• einen Zeiger auf den nächsten Eintrag (oder Terminator T == NULL)

© 2018-21 Jörg Ott | GBS | IN 0009 26


Verkettete Liste (2)
• Voriges Beispiel realisiert mit einer Liste
• Mögliche Speicherbelegung

A B C D E …
Adresse 0 1 2 3 4 5 6 7 8 9 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 3 3 3 3
01234567890123456789012345

• Repräsentation in einer verketten Liste

P 0 5 F 5 3 P 8 6

F 14 3 P 17 4 F 21 2

P 23 6 P 29 4 F 33 4

© 2018-21 Jörg Ott | GBS | IN 0009 27


Verkettete Liste (3)
• Vorteile
• Flexible Speicheraufteilung

• Nachteile
• Lineare Suche
• Keine feste Verwaltungsstruktur
• kann dynamisch wachsen und schrumpfen

• Optimierungsmöglichkeiten
• Getrennte Listen für belegten und freien Speicher
• Sortierung nach Speichergröße
• Verwaltung in (balancierter) Baumstruktur
• Ggf. Nutzung mehrerer Listen gleichzeitig

© 2018-21 Jörg Ott | GBS | IN 0009 28


Belegungstrategien
• Speicherfreigabe und Zusammenführung freier Bereiche
• Zur Vereinfachung der Listenverwaltung: Verwendung einer doppelt
verketteten Liste
• Vorteil der Sortierung der Liste nach den Anfangsadressen der
Speicherbereiche
• Einfache Verwaltung der Liste z.B. bei Prozess-Terminierung
• Beim Prozess-Terminierung: wenn möglich: freie Speicherbereiche zu
einem großen Bereich zusammenführen
• Beispiel
A X X B

A X

X B B

© 2018-21 Jörg Ott | GBS | IN 0009 29


Belegungsstrategien (2)
• Problem: Zusammenführung freier Bereiche nicht immer
möglich

• Konsequenz: Hauptspeicher im Laufe der Zeit zerstückelt


• Gefordert: Strategie zur effizienten Belegung der freien
Speicherbereiche
• First-Fit
• Next-Fit
• Best-Fit
• Worst-Fit

© 2018-21 Jörg Ott | GBS | IN 0009 30


First-Fit
• Durchsuchen der Liste der Freibereiche, beginnend am
Anfang der Liste
• Der erste Freibereich ausreichender Größe wird belegt
• Der nicht benötigte freie Speicher wird als neuer, verkleinerter
Freibereich der Freibereichsliste zugefügt.
• Vorteil
• Sehr einfach, findet schnell einen passenden Freibereich
• Beispiel

• Mögliche Probleme?
© 2018-21 Jörg Ott | GBS | IN 0009 31
Next-Fit
• Variante von First-Fit
• Durchsuchen der Liste der Freibereiche, beginnend beim als letztes
belegten Bereich
• der erste passende Freibereich wird belegt
• nicht genutzter Speicher wird als Freibereich der Liste hinzugefügt
• Beispiel

© 2018-21 Jörg Ott | GBS | IN 0009 32


Best-Fit und Worst-Fit
• Best-Fit
• Vollständiges Durchsuchen der Liste der Freibereiche
• Freibereich mit dem geringsten Verschnitt wird belegt.
• Vor- und Nachteile?

• Worst-Fit
• Vollständiges Durchsuchen der Liste der Freibereiche
• Freibereich mit dem größten Verschnitt wird belegt
• Vor- und Nachteile?

© 2018-21 Jörg Ott | GBS | IN 0009 33


Buddy-Algorithmus
• Ziel: Kompromiss zwischen
• der Verwaltung von Speicherblöcken fester Größe mit aufwendiger
Suche nach k freien zusammenhängenden Blöcken und
• Der Verwaltung von Speicherbereichen dynamischer Größe mit dem
Problem der ggf. erforderlichen aufwendigen Zusammenführung freier
Bereiche
• Buddy-Algorithmus (D. Knuth)
• Verwaltung des Speichers in Blöcken der Größe 2k, wobei l ≤ k ≤ u
• 2l : kleinste Blockgröße, die belegt werden kann
• 2u : ist die größte mögliche Blockgröße
• In der Regel ist 2u der gesamte belegbare Speicher.
• Speicherbelegung
• Zu Beginn steht ein zusammenhängender Bereich der Größe 2u zur
Belegung zur Verfügung
• Das System verwaltet Freibereichslisten für die Blockgrößen 2i
• Zum Start gibt es nur eine Liste mit einem Block der Größe 2u
© 2018-21 Jörg Ott | GBS | IN 0009 34
Buddy-Algorithmus (2)
• Anforderung zur Belegung eines Bereichs der Größe s
• Falls für s gilt: 2u−1 < s ≤ 2u
• dann wird der gesamte freie Block 2u belegt und aus der Freibereichsliste
für Blöcke der Größe 2u entfernt
• Anderenfalls wird
• der Block aus der Freibereichsliste für 2u entfernt
• der Block in zwei gleich große Bereiche der Größe 2u−1 (Buddies) aufgeteilt
• Einer der beiden freien Blöcke in die Freibereichsliste für Blöcke der Größe
2u−1 eingehängt
• Falls für s gilt: 2u−2 < s ≤ 2u−1, dann wird der andere Block belegt
• Der Algorithmus terminiert.
• Anderenfalls
• wird der Block erneut in zwei gleich große Bereiche der Größe 2u−2 aufgeteilt
• Falls für s gilt: 2u−2 < s ≤ 2u−1 dann wird einer der beiden Blöcke belegt und der
freie Block in die Freibereichsliste für Blöcke der Größe 2u−2 eingehängt
• Die Aufteilung wird solange fortgesetzt, bis der kleinste Block b gefunden
ist, mit s ≤ b

© 2018-21 Jörg Ott | GBS | IN 0009 35


Buddy-Algorithmus (3)
• Veranschaulichung

© 2018-21 Jörg Ott | GBS | IN 0009 36


Buddy-Algorithmus (4)
• Zusammenführung von freien Buddies:
• Freigabe eines Blocks b der Größe 2i
• Falls der Buddy des Blocks b ebenfalls frei ist
• werden die beiden Buddies zu einem Block der Größe 2i+1 verschmolzen und
• dieser Block wird der Frei-Bereichsliste für Blöcke der Größe 2i+1 hinzugefügt
• Die Anfangsadresse des freien Blocks der Größe 2i+1 ist die kleinste
Adresse der beiden verschmolzenen Buddies
• Diese Verschmelzungsoperation für Buddies wird rekursiv solange
fortgesetzt, bis keine Buddies mehr verschmolzen werden können
• Veranschaulichung

© 2018-21 Jörg Ott | GBS | IN 0009 37


Buddy-Algorithmus (5)
• Anmerkungen
• Sehr einfach zu implementieren, effizientes Suchen nach freien
Speicherbereichen
• Verschnitt ist maximal ein halber Block
• Verschmelzen von Buddies ist sehr effizient möglich
• Eine Variante des Buddy-Algorithmus wird in der Speicherverwaltung
von Linux verwendet
• Problem: Es kann freie benachbarte Bereiche geben, die nicht
verschmolzen werden

© 2018-21 Jörg Ott | GBS | IN 0009 38


Beispiel (1)
6.4 Frei-Speicherverwaltung Technische
Universität
München
Buddy-Algorithmus

� Beispiel: W = alloc(57K); X = alloc(65K); Y = alloc(120K); Z = alloc(99K); free(X);


free(Y); free(W); free(Z); (Blockgröße 16K)

1. Initialzustand B5 = Bz
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K

2. Teile ersten Block B4 B4


0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K

3. Teile ersten Block B3 B3 B4


0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K

4. Teile ersten Block,


W B2 B3 B4
vergebe W
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K

C. Eckert Kapitel 06 — Speicherverwaltung 29 / 1

© 2018-21 Jörg Ott | GBS | IN 0009 39


Beispiel (2)
6.4 Frei-Speicherverwaltung Technische
Universität
München
Buddy-Algorithmus

� Beispiel: W = alloc(57K); X = alloc(65K); Y = alloc(120K); Z = alloc(99K); free(X);


free(Y); free(W); free(Z); (Blockgröße 16K)

5. Vergebe X W B2 X B4
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K

6. Vergebe Y W B2 X Y B3
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K

7. Vergebe Z W B2 X Y Z
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K

8. Gebe X frei W B2 B3 Y Z
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K

C. Eckert Kapitel 06 — Speicherverwaltung 30 / 1

© 2018-21 Jörg Ott | GBS | IN 0009 40


Beispiel (3)
6.4 Frei-Speicherverwaltung
Buddy-Algorithmus
Technische
Universität
München

� Beispiel: W = alloc(57K); X = alloc(65K); Y = alloc(120K); Z = alloc(99K); free(X);


free(Y); free(W); free(Z); (Blockgröße 16K)

9. Gebe Y frei W B2 B3 B3 Z
(Kein Verschmelzen!) 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K

10. Gebe W frei,


B3 B3 B3 Z
verschmelze
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K

11. Verschmelze B4 B3 Z
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K

12. Gebe Z frei,


B5
verschmelze zweimal
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K 16K

C. Eckert Kapitel 06 — Speicherverwaltung 31 / 1

© 2018-21 Jörg Ott | GBS | IN 0009 41


Fragmentierung
• Interne Fragmentierung
• Beim blockweisen Allokieren von Speicher wird meist mehr Speicher
vergeben als benötigt
• Dieser zuviel belegte Speicherbereich wird weder vom belegenden
Prozess (intern) noch durch andere Prozesse (extern) genutzt werden
• Es kommt zu einem Verschnitt, der Speicher ist fragmentiert
• Veranschaulichung

© 2018-21 Jörg Ott | GBS | IN 0009 42


Fragmentierung (2)
• Externe Fragmentierung
• Durch die Dynamik beim Anlegen und Freigeben von Speicherblöcken
können Löcher im Hauptspeicher entstehen.
• Obwohl in Summe genügend freier Speicher zur Verfügung steht, kann
es sein, dass kein ausreichend großer zusammenhängender Bereich
zur Verfügung steht, um eine Anfrage zu bedienen.
• Veranschaulichung

• Behebung des Problems?


• Fragmentierung beim Buddy-Allocator?
© 2018-21 Jörg Ott | GBS | IN 0009 43
Virtueller Speicher
• Problem
• Der virtuelle Prozess-Adressraum eines Prozesses kann größer sein,
als der zur Verfügung stehende physische Hauptspeicher

• Eine manuelle Aufteilung (in Overlays) des virtuellen Adressraums


durch den Programmierer und das manuelle Ein- und Auslagern von
Adressbereichen in den Hauptspeicher durch den Programmierer ist
aufwendig und fehleranfällig.
• Forderung: das BS sollte diese Aufgabe automatisiert durchführen
• Lösung: Virtuelle Speicherverwaltung
• Häufigstes Konzept zur Umsetzung: Paging
© 2018-21 Jörg Ott | GBS | IN 0009 44
eller Speicher Universität
München

Paging
Adressräume werden in Seiten (pages) aufgeteilt.
• Virtuelle Adressräume werden in Seiten (pages) aufgeteilt
ptspeicher wird in physische Kacheln (frames) aufgeteilt.
• Hauptspeicher wird in physische Kacheln (frames) aufgeteilt
gel besitzen diehaben
• I.d.R. Seiten und und
Seiten die die
Hauptspeicher-Kacheln
Hauptspeicher-Kacheln die die gleiche
gleiche Größe od
Größe
ße ist ein• Vielfaches der Kachelgröße.
Oder die Seitengröße ist ein Vielfaches der Kachelgröße
• Bem.: Typische Seiten-/Kachelgrößen auf x86: 4 KB / 2 MB / 1 GB
pische Seiten-/Kachelgrößen auf x86: 4 KByte / 2 MByte / 1 GByte
• Aufgabe des BS zusammen mit Hardware:
des BS zusammen
Abbilden von mitSeiten
Hardware: Abbilden von Seiten auf Kacheln.
auf Kacheln
lden der •Seiten-Adressen auf physische
Abbilden der Seiten-Adressen Adressen
auf physische in einer
Adressen Kachel:
in einer Kachel
ie Aufgabe der Memory
• Aufgabe Management
der Memory ManagementUnit als Teilalsder
Unit (MMU) TeilHardware
der Hardware
Virtueller ...
v0 v1 v2 v3 vm−2 vm−1 vm
Adressraum V

f ∶V�P
px ∶= f (vx ) = ?

Physischer ...
p0 p1 p2 p3 pn−1 pn
Adressraum P

© 2018-21 Jörg Ott | GBS | IN 0009 45


Kapitel 06 — Speicherverwaltung
Paging (2)
• Page Table
• Verwaltung der Zuordnung von Seiten zu Kacheln
• Das BS verwaltet eine Page Table pro Prozess.
• Bei einem Prozesswechsel wird die Anfangsadresse der neuen
Prozess-Page-Table in das Seitentabellenregister der CPU geladen
• Seitenfehler (page fault)
• Bei Zugriff auf eine virtuelle Adresse einer Seite, die in keiner Kachel
eingelagert ist.
• Die Hardware löst einen Interrupt, einen page fault, aus
• Das Betriebssystem muss die erforderliche Seite einlagern
• Seiteneinlagerung
• Falls alle Kacheln belegt sind, müssen Seiten ersetzt werden
• Es werden also ggf. Seiten (auf die Festplatte) ausgelagert

© 2018-21 Jörg Ott | GBS | IN 0009 46


Paging (3): Beispiel

© 2018-21 Jörg Ott | GBS | IN 0009 47


Paging vs. Swapping

© 2018-21 Jörg Ott | GBS | IN 0009 48


Memory Management Unit (MMU)
• Teil der Hardware, führt die Adressumrechnung durch
1 - Prozessor sendet eine virtuelle Adresse an MMU
2,3 - MMU lädt Pagetableeintrag (PTE) aus Cache / Speicher VA = Virtuelle Adresse
4 - MMU sendet die physische Adresse an Cache / Speicher Cache / Speicher PA = Physische Adresse
5 - Cache / Speicher sendet die Daten zum Prozessor PTEA = Page Table Entry Address
PTE = Page Table Entry
Daten = Speicherinhalt an PA
CPU Chip

2) PTEA
1) VA
CPU MMU
3) PTE
4) PA

Quelle (bearbeitet): 5) Daten


http://db.in.tum.de/teaching/ss20/dataprocessingonmodernhardware/MH_4.pdf

• Problem: Adressabbildung ist teuer (im Sinne von Zeit)


• Grund: Page Table liegt im Hauptspeicher
• Lösung: Cache, als Teil der MMU
© 2018-21 Jörg Ott | GBS | IN 0009 49
Translation Lookaside Buffer (TLB)
• Cache für die Abbildung von Seiten auf Kacheln
• Klein: wenige Einträge, typisch: 256
• Oft Mehrstuftig
TLB
VA = Virtuelle Adresse
PA = Physische Adresse VPN → PTE
VPN = Virtual Page Nummer
VPN → PTE Ein TLB Hit vermeidet einen Speicherzugriff!
PTE = Page Table Entry
Daten = Speicherinhalt an PA VPN → PTE

CPU Chip Cache / Speicher


TLB
2) 3)
VPN PTE

1) VA
CPU MMU

4) PA

Quelle (bearbeitet):
http://db.in.tum.de/teaching/ss20/dataprocessingonmodernhardware/MH_4.pdf 5) Daten

© 2018-21 Jörg Ott | GBS | IN 0009 50


TLB Miss
VA = Virtuelle Adresse
PA = Physische Adresse TLB
VPN = Virtual Page Nummer Bei einem TLB Miss wird ein
PTE = Page Table Entry VPN → PTE zusätzlicher Speicherzugriff zum
PTEA = Page Table Entry Address VPN → PTE Laden des PTE nötig!
Daten = Speicherinhalt an PA
VPN → PTE

CPU Chip Cache / Speicher


TLB
2) 4) PTE
VPN
3) PTEA
1) VA
CPU MMU

5) PA

6) Daten

Quelle (bearbeitet):
http://db.in.tum.de/teaching/ss20/dataprocessingonmodernhardware/MH_4.pdf
© 2018-21 Jörg Ott | GBS | IN 0009 51
Beispiel: TLB

Data

Text
Data
Text
Stack

© 2018-21 Jörg Ott | GBS | IN 0009 52


Fallbeispiel: Intel Core i7

Zweistufiger TLB Cache


• Separate L1 Caches für Instruktionen
und Daten enthaltende Seiten
• L2 Cache für Instruktionen und Daten

© 2018-21 Jörg Ott | GBS | IN 0009 53


Page Table
• Eine virtuelle Adresse v wird interpretiert als v=(s, w), wobei
• die höherwertigen Bits als Seitennummer s und die niedrigwertigen
Bits als Offset w interpretiert werden
s w
• Seitennummer definiert den Index in die Seiten-Tabelle des BS mit
dem Eintrag für die Seite
• Page-Table-Eintrag: 1 Eintrag pro Seite
• Ein Eintrag umfasst i.d.R. 32 Bit (bei 32-Bit-Systemen) bzw.
64 Bit (bei 64-Bit-Systemen)
• Eintrag enthält die Frame-Nummer für die Seite (falls vorhanden)
• Adressabbildung: der s-Teil der virtuellen Adresse wird durch die
Frame-Nummer ersetzt

© 2018-21 Jörg Ott | GBS | IN 0009 54


Page Table (2)
• Weitere Informationen repräsentiert über einzelne Bits
• P (present)
• Gibt an, ob die physische Adresse als existent (vorhanden) markiert ist
• Wenn das P-Bit nicht gesetzt ist, kann das Betriebssystem alle weiteren Bits
im Page-Table-Eintrag mit eigener Semantik versehen
• Beispiel Windows: Bits für Auslagerungszustand einer Seite, Guard Page,
Zero Page, ...
• U/S (user/supervisor)
• Gibt an, ob nur der Betriebssystemkern die Seite lesen/schreiben darf
• R (referenced) (oder auch A (accessed))
• Wird von der CPU gesetzt, sobald auf die Seite zugegriffen wurde
• M (modify) (oder auch dirty Bit)
• Wird von der CPU gesetzt, sobald mindestens ein Byte in dem
referenzierten Frame geschrieben wurde
• XD (execute-disable)
• Gibt an, ob die CPU in diesem Frame gespeicherte Bytes als Instruktionen
ausführen darf.
• Generell: Protection Bit, z.B. nur lesender und schreibender Zugriff erlaubt
© 2018-21 Jörg Ott | GBS | IN 0009 55
Adressabbildung
• Gesucht: Physische Adress p = (k, w)
Seitentabellenregister
Virtuelle Adresse
Page Table s w

s < L?
s

L sizeof (s) ≠ sizeof (k)

k w
Physische Adresse
Längenregister

© 2018-21 Jörg Ott | GBS | IN 0009 56


Beispiel: Adressabbildung
• Gegeben: 16-Bit virtueller Adressraum, Seitengröße 4096 = 212 Byte
• Gesucht: Physische Adresse zu virtueller Adresse 0x3f48
Virtuelle Adresse: v
Page Table Aufteilung der Bits innerhalb
einer virtuellen Adresse?

Größe der
Page Table? `

Physische Adresse: p

© 2018-21 Jörg Ott | GBS | IN 0009 57


Beispiel: Adressabbildung
• Gegeben: 16-Bit virtueller Adressraum, Seitengröße 4096 = 212 Byte
• Gesucht: Physische Adresse zu virtueller Adresse 0x3f48
Virtuelle Adresse: v
Page Table 0011 111101001000
0 010 3 < 16? = 0x3f48
1 001 3
2 110
3 000
4
216 5
= 16
212
6

… 000 111101001000
Physische Adresse: p
15 = 0x0f48

© 2018-21 Jörg Ott | GBS | IN 0009 58


Mehrstufige Seitentabellen
• Weiteres Problem beim Paging
• Große virtuelle Adressräume
• Die zugehörige Seitentabelle ist ebenfalls sehr groß
• Die Speicherung der Tabelle belegt viel Hauptspeicher
• Beispiel:
• Typische Adressraumgröße auf x86-64: 248 Bytes virtueller Adressraum
• Typische Seitengröße auf x86-64: 4096 = 212 Bytes
• Zur Verwaltung des Adressraums wird pro Prozess eine Page Table der
Größe: 248 / 212 = 236 Einträge (= 6,8x1010) benötigt
• Selbst bei x86-32: 232 Bytes virtueller Adressraum = 220 (= 106) Einträge

• Lösungsansatz
• Einführung mehrstufiger Tabellen: z.B. 2stufig, 3-stufig etc.

• Konsequenz
• Nur ein Teil der ursprünglichen Page Table muss zur Prozess-
Ausführung im Hauptspeicher eingelagert sein
© 2018-21 Jörg Ott | GBS | IN 0009 59
ueller Speicher Technis
Univers
Münche
itentabellen

stufigeBeispiel:
PageTable Zweistufige Seitentabelle
Second-level Page Tables

0
1
2
3 Seiten für virtuelle Adressen
4 zwischen 0x00000000 und
5 0x003fffff
6

1023
Top-level
0
Page Table
1
0 2
1 3 Seiten für virtuelle Adressen
2 4 zwischen 0x00400000 und
Bits 10 10 12 3 5 0x007fffff
PT1 PT2 Offset 4 6
5
6 1023

1023 0
1
2
3 Seiten für virtuelle Adressen
4 zwischen 0xffc00000 und
5 0xffffffff
6

1023
© 2018-21 Jörg Ott | GBS | IN 0009 60
irtueller Speicher Technische
Universität
München

Beispiel: IA-32e Paging auf x86-64


e Seitentabellen

: IA-32e Paging auf x86-64

© 2018-21 Jörg Ott | GBS | IN 0009 61


ckert Kapitel 06 — Speicherverwaltung
Seitenfehler (Page Fault)
• Tritt auf, wenn die Seite der zugegriffenen virtuellen Adresse nicht
im Speicher eingelagert ist (P bit ist nicht gesetzt)
• Hardware löst Interrupt aus und initiiert Interrupt-Behandlung
durch BS
• Ausführung des Page-Fault-Handlers
• speichert Programmzustand, deaktiviert Interrupts
• Betriebssystem behandelt den Seitenfehler
• (a) Seite ist ausgelagert: Suche freie Kachel und lagere Seite ein
• Falls noch freie Kachel verfügbar, wähle eine aus
• Anderenfalls führe eine Seitenersetzungsstrategie (s.u. ) aus
• (b) Seite ist nicht ausgelagert: BS löst Speicherschutz-Fehler aus
• Aktualisieren des Page-Table-Eintrags
• Setzen des P-Bits, Löschen der R- und M-Bits
• Wiederherstellen des Programmzustands, reaktivieren der
Interrupts
• Interrupt-Kontext verlassen
© 2018-21 Jörg Ott | GBS | IN 0009 62
Adressübersetzung
Virtuelle Adresse

TLB
Lookup
TLB miss TLB hit
PTE
Page Table PTE Protection
prüfen Check
Seite nicht Seite im Zugriff Zugriff
eingelager Speicher gestattet verweigert

Page Fault Update Protection Physische


(OS muss Seite laden) TLB Fault Adresse

Suche auf Hintergrundspeicher Suche im Speicher SIGSEGV Datencache prüfen

Quelle (bearbeitet):
http://db.in.tum.de/teaching/ss20/dataprocessingonmodernhardware/MH_4.pdf
© 2018-21 Jörg Ott | GBS | IN 0009 63
Seitenersetzungsstrategien
• Drei strategische Aufgaben
• Wann ist eine Seite zu laden?
• On-Demand Paging
• Eine Seite wird genau dann geladen, wenn auf sie zugegriffen wird und sie sich
noch nicht im Hauptspeicher befindet
• Prefetching
• Seiten werden im Voraus geladen, um bei Bedarf verfügbar zu sein
• Frage: wann sinnvoll und welche Seiten sollen im Voraus geladen werden?

• Platzierungsstrategie: Wohin ist eine Seite zu laden?


• Alle Kacheln sind gleichwertig: keine strategische Entscheidung erforderlich
• Praxis: Spezialbehandlung für Kernel-Code und Kernel-Daten eine Form
des Identity-Mappings
• Effekt: konstante Differenz zwischen virtueller und physischer Adresse,
schnelle Rückrechnung von physischer zu virtueller Adresse
• Seitenersetzungsstrategie Welche Seite wird im Zweifelsfall
ausgelagert?

© 2018-21 Jörg Ott | GBS | IN 0009 64


Seitenersetzungsstrategien (2)
• Vorbemerkung
• Optimale Strategie:
• Auslagern derjenigen Seite, deren nächster Zugriff am weitesten in der
Zukunft liegt
• Problem: Strategie ist nicht implementierbar, da das BS keine Voraussagen
über künftige Seitenzugriffe machen kann
• Idee: Algorithmen entwickeln, die die optimale Strategie approximieren

• Ersetzungsstrategien
• FIFO: First-In, First-Out
• Second-Chance
• Clock
• Least Recently Used
• Working Set
• Working Set with Clock

© 2018-21 Jörg Ott | GBS | IN 0009 65


FIFO-Strategie
• BS verwaltet Liste aller eingelagerten Seiten im Speicher
• Sortierung nach Ankunftszeiten: First-in-First-Out (FIFO)
• Beim Page-out wird diejenige Seite gewählt, die am längsten im
Speicher gehalten wurde: Kopf der Liste
• Die einzulagernde Seite kommt an das Ende der Liste

• Problem
• Seite, die am längsten im Speicher ist, wird u.U. aber häufig benutzt,
z.B. Nutzung globaler Variablen
• FIFO ist eine schlechte Approximation des optimalen Algorithmus
• Weiteres Problem: Béládys Anomalie (FIFO-Anomalie):
• Zuordnung von zusätzlichen Frames an einen Prozess kann u. U. sogar die
Zahl der Seitenfehler erhöhen

• FIFO wird in der Reinform kaum eingesetzt, wohl aber


Varianten, wie z.B. Second Chance
© 2018-21 Jörg Ott | GBS | IN 0009 66
Beispiel
6.5 Virtuellerfür die FIFO-Anomalie
Speicher Technische
Universität
München
FIFO-Algorithmus

Beispiel für die FIFO Anomalie: Sequenz benötigter Seiten: 1, 2, 3, 4, 1, 2, 5, 1, 2, 3, 4, 5


0. 17 0. 17
1. 1 1 3, 2 7 1. 1 1 3, 2 7
2. 1 2 2 3, 3 7 2. 1 2 2 3, 3 7
3. 1 2 3 3 3, 4 7 3. 1 2 3 3 3, 4 7
4. 2 3 4 4 3, 1 7 4. 1 2 3 4 4 3, 1 3, 2 3, 5 7
5. 3 4 1 1 3, 2 7 5. 2 3 4 5 5 3, 1 7
6. 4 1 2 2 3, 5 7 6. 3 4 5 1 1 3, 2 7
7. 1 2 5 5 3, 1 3, 2 3, 3 7 7. 4 5 1 2 2 3, 3 7
8. 2 5 3 3 3, 4 7 8. 5 1 2 3 3 3, 4 7
9. 5 3 4 4 3, 5 3 9. 1 2 3 4 4 3, 5 7
10. 2 3 4 5 53
⇒ 9 Seitenfehler ⇒ 10 Seitenfehler
C. Eckert Kapitel 06 — Speicherverwaltung 49 /

© 2018-21 Jörg Ott | GBS | IN 0009 67


Second-Chance-Algorithmus
• FIFO lagert die älteste Seite aus: Modifikation
• Wenn die älteste Seite das R-Bit gesetzt hat
• lösche dieses und verschiebe die Seite an das Ende der Liste
• aktualisiere Einlagerungszeit (als wurde die Seite gerade geladen)
• fahre dann mit der Suche fort
• Seite erhält eine zweite Chance, weil sie kürzlich genutzt wurde.
• Andernfalls
• schreibe den Inhalt dieser Seite auf den Hintergrundspeicher zurück,
wenn zusätzlich das M-Bit gesetzt ist,
• andernfalls verwerfe die Inhalte der Seite
• Anmerkung
• Wenn auf alle Seiten in dem betrachteten Zeitintervall zugegriffen
wurde (alle R-Bits gesetzt), dann degeneriert Second Chance zu FIFO
• Problem: Seiten in der Liste werden unnötig häufig verschoben.
• Lösung: Effiziente Alternative zur Liste: Clock-Algorithmus

© 2018-21 Jörg Ott | GBS | IN 0009 68


Second-Chance-Algorithmus
• Beispiel: Verkettete Liste von Seiten, nach
Einlagerungszeitpunkt sortiert

© 2018-21 Jörg Ott | GBS | IN 0009 69


Clock-Algorithmus
• Konzept
• Verwalten der Seiten in einer zirkulären Liste, angeordnet wie bei einer Uhr
• Nutzen eines (Uhr-)Zeigers, der auf die älteste Seite verweist

• Bei Page-Fault (Seitenersetzung erforderlich)


1. Falls für die Seite, auf die der Zeiger verweist, das R-Bit nicht gesetzt ist,
ersetze diese Seite durch die neue Seite und rücke den Clock-Zeiger um
eine Position weiter
2. Falls R-Bit gesetzt, rücke den Clock-Zeiger um eine Position weiter und
3. lösche den R-Eintrag der vorherigen Seite.
4. Schritte 1-3 werden solange wiederholt, bis eine Seite mit R=0 gefunden wird
5. Wenn das M-Bit der gefundenen Seite gesetzt ist, schreibe den Inhalte der
Seite auf den Hintergrundspeicher zurück,
6. wenn das M-Bit nicht gesetzt, verwerfe Seiteninhalte

© 2018-21 Jörg Ott | GBS | IN 0009 70


Beispiel
• Lesezugriff auf Seite 42: Page 8
page fault R=0 M=1
• Löschen aller R-Bits, die der Frame 7
Zeiger passiert Page 9
7 Page 94
R=1
R=0 M=0
M=1 R=0 M=0
• Laden der Seite 42 in ersten
Frame 6 Frame 0
Frame mit R-Bit = 0 (Frame 5)
• Lesezugriff
⇒ R-Bit = 1, M-Bit = 0
Page 42 Page 95
R=0
R=1 M=0 R=0
R=1 M=0
• Schreibzugriff auf Seite 9: Frame 5 Frame 1
page fault
• Laden der Seite 13 in ersten
Frame mit R-Bit = 0 (Frame 6) Page 47 Page 45
R=1
R=0 M=1 R=1
R=0 M=0
• Seite 7 hat M-Bit gesetzt Frame 4 Frame 2
• Zurückschreiben auf den Page 46
Hintergrundspeicher, R=1
R=0 M=0
Verwerfen der Seite Frame 3
• Schreibzugriff
⇒ R-Bit = 1, M-Bit = 1

© 2018-21 Jörg Ott | GBS | IN 0009 71


Least Recently Used (LRU)
• Hintergrund
• Hypothese: Seiten, die in vergangenen Instruktionen häufig genutzt wurden,
werden auch mit hoher Wahrscheinlichkeit in naher Zukunft wieder verwendet.
• Frage: ist diese Hypothese valide?
• Antwort: Ja, wegen Lokalitätseigenschaft von Programmen
• LRU: Ausnutzen der Lokalitätseigenschaft:
• Ersetze bei einem Seitenfehler diejenige Seite, welche am längsten nicht
verwendet wurde.
• Gute Approximation des optimalen Seitenersetzungsalgorithmus
• Problem: Exakte Implementierung von LRU benötigt
• verkettete Liste von genutzten Seiten, zuletzt genutzte Seite am Listen-Anfang
• Aktualisierung der Liste nach jedem Seitenzugriff und sehr zeitaufwendiges
Umsortieren der Liste
• Zur effizienten Umsetzung ist spezielle Hardware erforderlich. I.d.R. nicht
vorhanden
• Lösung
• Simulation von LRU durch Software: Not-Frequently-Used (NFU) bzw. Aging
© 2018-21 Jörg Ott | GBS | IN 0009 72
Not Frequently Used (NFU), Aging
• Konzept
• Einführung eines Software-Counters Ap pro Seite p
• Zähler mit fester Größer: b-Bit, initialisiert mit 0
• Vorgehen: bei jedem Timer-Interrupt durchsucht das BS alle
Seitendeskriptoren
• Falls R-Bit der Seite p gesetzt, dann zugehörigen Zähler Ap um 1 erhöhen
• Auslagern der Seite mit kleinstem Zählerstand.
• Beispiel: Seiten 0, 1, 2, 3, 4 Referenzkette sei: 0111221123324434
• Zähler A0=1, A1=5, A2=4, A3=3, A4=3

• Problem
• Zähler repräsentiert nicht, wann die häufigen Zugriffe waren (siehe Bsp)
• Lösung: Aging-Verfahren
• Idee: Zählerstand Ap spiegelt wider, ob Zugriffe frisch sind oder schon
lange zurück liegen, also altern
• Bei einem Seitenfehler wird die Seite mit dem niedrigsten Zählerwert
ausgelagert
© 2018-21 Jörg Ott | GBS | IN 0009 73
Aging (2)
• Erfassung der Alterung von Zugriffen
• Festlegung eines Zeit-Intervalls t, in dem Seitenzugriffe erfasst
werden, z.B. 20 ms
• Sei R der Wert des Reference-Bits (R-Bit) der Seite p, sei Ap der
Zähler der Seite
• Timer-Interrupt nach Ablauf des Zeitintervalls t
• Neuberechnung des Zählerstands von Ap
• Shift des Zählers Ap um eine Stelle nach rechts.
• Addition des Wertes R zum am weitestens links stehenden Bit des
Zählers Ap
• Beispiel:
• Zähler Ap, mit Ap ∊ {0, ..., 15}, 1510 = 11112
• Sei Ap = 11002 also Ap= 12, Interrupt erfolge nach Zeitintervall t, es
gelte r=0 von Ap
• Neuer Zählerstand von Ap=

© 2018-21 Jörg Ott | GBS | IN 0009 74


Aging (3)
• Aging ist eine LRU-Vergröberung
• Beschränkter zeitlicher Horizont
• Zähler Ap ist nur b-bit groß und repräsentiert nur Zugriffe in den letzten
b Zeitintervallen
• Das Verfahren vergisst alle älteren Zugriffe, die vor b Intervallen waren
• Problematisch?

• Geringe Differenzierung
• Pro Zeit-Intervall wird nur protokolliert, ob eine Seite referenziert
wurde, nicht wann
• Konsequenz?

© 2018-21 Jörg Ott | GBS | IN 0009 75


Beispiel
6.5• Virtueller Speicher
8-bit Zähler Ap für 6 Seiten und 5 Zeit-Intervalle
Technische
Universität
München
Beispiel
• Rote Markierungen identifizieren Seiten, die bei Bedarf im
Beispiel: 8-bit Zähler Ap für 6 Seiten und 5 Zeit-Intervalle, rote Markierungen identifizieren
Folgeintervall ausgelagert werden würden
Seiten, die bei Bedarf im Folgeintervall ausgelagert werden würden.

Intervall 0 Intervall 1 Intervall 2 Intervall 3 Intervall 4


R-Bits
am Ende
1 0 1 0 1 1 1 1 0 0 1 0 1 1 0 1 0 1 1 0 0 0 1 0 0 1 1 0 0 0
von Intervall i

A0 10000000 A0 11000000 A0 11100000 A0 11110000 A0 01111000

A1 00000000 A1 10000000 A1 11000000 A1 01100000 A1 10110000

Zählerstand Ap A2 10000000 A2 01000000 A2 00100000 A2 00010000 A2 10001000


der Seiten p am
Ende von Intervall i A3 00000000 A3 00000000 A3 10000000 A3 01000000 A3 00100000

A4 10000000 A4 11000000 A4 01100000 A4 10110000 A4 01011000

A5 10000000 A5 01000000 A5 10100000 A5 01010000 A5 00101000

C. Eckert Kapitel 06 — Speicherverwaltung 59 / 1

© 2018-21 Jörg Ott | GBS | IN 0009 76


Working Set
• Bislang: Demand-Paging
• Seiten wurden dann eingelagert, wenn sie benötigt wurden (Page Fault)
• Die Menge der Seiten, die ein Prozess aktuell benötigt, heißt Working-Set
• Lokalitätsprinzip: Prozesse arbeiten eine Zeitlang mit gleichem Working-
Set
• Falls gesamter Working-Set im Speicher ist, verursacht der Prozess keine
Seitenfehler
• Falls der Working-Set nur zu geringem Teil im Speicher eingelagert ist,
kommt es zu häufigen Seitenfehlern
• Seitenflattern (thrashing): wenn ein Prozess sehr häufig einen Seitenfehler
verursacht

• Aufgabe des BS:


• Thrashing vermeiden, denn dann ist das BS nur mit Ein- und Auslagern beschäftigt
• hohen Multiprogramming-Grad unterstützen
• Prepaging: Working-Set für rechnende Prozesse bereit halten

• Lösung: Working-Set-Modell
© 2018-21 Jörg Ott | GBS | IN 0009 77
Working Set (2)
• Working-Set-Modell
• Zu jedem Zeitpunkt t bezeichnet der Working-Set w(k, t) die Menge der
Seiten der k letzten Speicherzugriffe
• w(k, t) kann über die Zeit unterschiedlich groß sein
• Bei großer Lokalität der Zugriffe ist der Working-Set klein
• Beispiel: Zugriffe: 26157777516234123444344, sei k=4, w(k, t1)=
• Abbildung zeigt die Größe des Working-Sets w(k; t) über die
Zugriffe k

k
© 2018-21 Jörg Ott | GBS | IN 0009 78
Working Set (3)
• Working-Set Ersetzungs-Verfahren:
• Idee: Ersetzungs-Strategie auf der Basis des Working-Set Modells
• Bei Seitenfehler werden nur Seiten ersetzt, die sich nicht im aktuellen Working-Set
befinden
• Problem: Protokollieren der k letzten Speicherzugriffe aufwendig
• Lösung: Approximation über die Ausführungszeit (Rechenzeit) des Prozesses
• Ausführungszeit: die Zeit, die ein Prozess die CPU genutzt hat
• Typischerweise geringer als die absolut vergangene Zeit (Echtzeit)
• ! bezeichnet ein Intervall in der Rechenzeit (nicht der Echtzeit)

• Erforderliche Hilfswerte für den Ersetzungsalgorithmus:


• Festlegung eines Zeit-Intervalls I. Timer-Interrupt nach Ablauf von I (Clock-Tick)
• Neuberechnung des Working-Sets
• Löschen aller R-Bits aller Seiten. Typischerweise ist I < !
• Monoton ansteigender Zähler Z pro Prozess, der die Rechenzeit des Prozesses
approximiert
• Zähler Zp für jede Seite p, der die letzte Zugriffszeit approximiert
Clock-Tick Intervall I
Echtzeit

Rechenzeit

© 2018-21 Jörg Ott | GBS | IN 0009 ! 79


Working Set (4)
• Seitenfehlerbehandlung: BS inspiziert R-Bits aller Seiten
• R = 1 für Seite p: Seite gehört zum Working-Set und wird nicht entfernt
Setze Zähler Zp auf den aktuellen Wert von Z
• R = 0 für Seite p
• Z − Zp > ! : p gehört nicht mehr zum Working-Set und wird ersetzt
• Z − Zp ≤ ! : p wurde während I nicht verwendet, gehört aber noch zum
Working Set
• System merkt sich Kandidaten für Ersetzung: pold ist Seite p mit kleinstem
Wert Zp
• Wenn keine passende Seite gefunden wurde, sind alle Seiten im
Working-Set. Ersetze die älteste Seite, also pold
• Erläuterung

© 2018-21 Jörg Ott | GBS | IN 0009 80


Working-Set (5)
• Anmerkungen
• Das reine Working-Set-Modell ist aufwendig zu implementieren
• In der Praxis: Working-Set Ansatz mit Clock-artiger Verwaltung der
Seiten
• Effiziente und gute Approximation des optimalen Ersetzungsverfahrens
• Nutzung: als (Prozess)-lokale oder globale Ersetzungsstrategie
• Über Wahl der Parameter (Working-Set-Größe) steuert BS den
Multiprogramming-Grad (Load-Control)

© 2018-21 Jörg Ott | GBS | IN 0009 81


WSClock
• Beispiel
• Virtuelle Zeit: 2204
• Jede Seite speichert
die letzte Zugriffszeit
• Eine Seite wird
gesucht mit R = 0
• Wenn M = 0
• Seite verwerfen
• Neue Seite einlagern
• Fertig
• Wenn M ≠ 0
• Schreiben der Seite auf
die Festplatte anstoßen
• Aber nicht warten!
• Weitersuchen mit der
nächsten Seite

© 2018-21 Jörg Ott | GBS | IN 0009 82


© 2018-21 Jörg Ott | GBS | IN 0009
Working Set in der Wirklichkeit
• Ein einfaches Beispielprogramm
• Initialisierung eines Arrays
#include <stdio.h>
#include <stdlib.h>

#define N_ELEM 1000

int array [N_ELEM][N_ELEM];

int main (int argc, char *argv []) {


int i, j, k;

for (i = 0; i < N_ELEM; i++) {


for (j = 0; j < N_ELEM; j++) {
array [i][j] = i + N_ELEM * j;
}
}
exit (0);
}

© 2018-21 Jörg Ott | GBS | IN 0009 84


Working Set in der Wirklichkeit (2)
• Erinnerung: ein Array in C…
• int arr [4][2];
arr [0][0] arr [0][1] arr [1][0] arr [1][1] arr [2][0] arr [2][1] arr [3][0] arr [3][1]

• int a [X][Y]

0 a [0][0] a [0][1] a [0][2] a [0][3] … a [0][y-2] a [0][y-1]


sizeof(int) * y a [1][0] a [1][1] a [1][2] a [1][3] a [1][y-2] a [1][y-1]
… …

x-1*sizeof(int)*y a [x-1][0] a [x-1][1] a [x-1][2] a [x-1][3] … a [x-1][y-2] a [x-1][y-1]

• 1.000 x 1.000 Einträge zu je 4 Bytes = 4.000.000 Bytes = 976 Seiten


• 10.000 x 10.000 Einträge = 400.000.000 Bytes = 97657 Seiten

© 2018-21 Jörg Ott | GBS | IN 0009 85


Working Set in der Wirklichkeit (3)
• Unser C-Programm (loop.c)
• $ valgrind --tool=lackey --trace-mem=yes ./loop 2> loop-ij.txt
• 8762 Bytes Executable
• 0x04000a50 – 0x0400ff6b, 0x00108530 – 0x001087ac

• Für N_ELEM = 1.000


• Speicherzugriffe: 23.144.780
• Instruktionen: 16.104.375
• Variable lesen: 5.026.862
• Variable schreiben: 1.012.338
• Variable ändern: 1.001.205
• Laufzeit: kurz

• N_ELEM = 10.000 (Mittelwert; 100 Wdh. in VirtualBox)


$ time ./loop
• Laufzeit: 0.969s
• User: 0.712s
• System: 0.255s
© 2018-21 Jörg Ott | GBS | IN 0009 86
Working Set in der Wirklichkeit (4)
• Minimale Modifikation unseres Beispielprogramms

#include <stdio.h>
#include <stdlib.h>

#define N_ELEM 1000

int array [N_ELEM][N_ELEM];

int main (int argc, char *argv []) {


int i, j, k;

for (i = 0; i < N_ELEM; i++) {


for (j = 0; j < N_ELEM; j++) {
array [j][i] = j + N_ELEM * i;
}
}
exit (0);
}

© 2018-21 Jörg Ott | GBS | IN 0009 87


Working Set in der Wirklichkeit
• Ergebnis
• Für N_ELEM = 10.000 (Mittelwert; 100 Wiederholungen in VirtualBox)
• Laufzeit: 4.693s
• User: 4.335s
• System: 0.352s

• Ursache?

• Verteilung bzw.
Reihenfolge der
Speicherzugriffe

© 2018-21 Jörg Ott | GBS | IN 0009 88


Verzögerungen beim Paging
• Festplattenzugriffe kosten Zeit
• Größenordnung 1-10ms, schneller bei SSD
• Beim Lesen der zu ladenden Seite
• Lässt sich nur begrenzt optimieren
• Wissen über zukünftige Zugriffe erforderlich
• Beispiel: Prefetching von Seiten
• Beim Schreiben einer zu
ersetzenden Seite (wenn M = 1)
• Zuletzt nicht/wenig genutzte Seiten
sind bekannt
• Warum nicht präventiv schreiben?
• 2-Handed-Clock-Algorithmus
• Erster Zeiger wird durch einen Paging-Daemon geführt
• Trifft diese auf modifizierte Seiten, so schreibt sie diese auf die Festplatte
• Sorgt damit dafür, dass immer freie Seiten zur Verfügung stehen
• Zweiter Zeiger: normaler Clock- oder Working-Set-Clock-Algorithmus

© 2018-21 Jörg Ott | GBS | IN 0009 89


Globale vs. lokale Allokation
• Frage
• Soll jeder Prozess seinen eigenen Seitenpool haben? (lokal)
• Nächste Frage: wie teilt man dann den globalen Speicher auf?
• Bekommt jeder Prozess gleich viele Seiten?
• Funktioniert im allgemeinen nicht so gut
• Sollen sich alle Prozesse einen gemeinsamen Pool von Seiten teilen?
• Ein Prozess kann dann die Seiten eines anderen verdrängen
• Dafür können sich kleine und große Prozesse den Speicher gut teilen
• Nicht alle brauchen gleichermaßen viel
• Wichtige Metrik: Seitenfehler pro Zeiteinheit
• Dient dazu die Anzahl der
Seiten für einen Prozess
zu steuern
• A: High-Water-Mark
• B: Low-Water-Mark

© 2018-21 Jörg Ott | GBS | IN 0009 90


Shared Memory (Pages)
• Effizienz in der Speicherverwaltung
• Vermeiden von unnötiger oder redundanten Daten im Speicher
• Beim Starten eines Prozesses
• Nicht gleich den gesamten Prozess einlagern
• Beginnen mit einer oder einigen Seiten (z.B. initialer Working-Set)
• On-demand-Paging
• Nach dem Erzeugen eine Kindprozesses, z.B. fork()
• Vollständiges Speicherabbild doppelt vorhanden
• Erzeugen einer Kopie sehr aufwendig
• Eltern- und Kindprozess nutzen dieselben Seiten
• Copy-on-write für Daten und Stack
• Gemeinsame genutzte Bibliotheken (Shared Libraries, DLLs)
• Können sehr umfangreich sein (z.B. Grafik)
• Trivialbeispiel: mem (472 Zeilen Quellcode inkl. aller .c- und .h-Dateien)
• 27.160 Bytes mit Shared Libraries, 833.360 Bytes statisch gelinkt
• Code einmal im Speicher vorhalten, von mehreren Prozessen zugreifen
• Aber: Bibliotheken können bei Prozessen an unterschiedlichen Stellen im jeweils
virtuellen Adressraum liegen
• Was tun mit Sprunginstruktionen usw.?
• Compiler gestattet die Nutzung ausschließlich relativer Adressen

© 2018-21 Jörg Ott | GBS | IN 0009 91


BS und Paging
• BS wird aktiv bei
• Erzeugung eines Prozesses
• Speicherbedarf ermitteln, Raum für Swapping/Paging vorhalten
• Seitentabellen anlegen (ggf. vom Elternprozess übernehmen, Sharing)
• Ausführung eines Prozesses
• Seitentabelle laden
• MMU konfigurieren, TLB löschen (gehört zum vorigen Prozess)
• Ggf. prepaging
• Seitenfehler durch einen Prozess (Unterbrechungsbehandlung, S. 59)
• Fehlende Seite bestimmen
• Aus dem Sekundärspeicher laden
• Instruktion erneut ausführen
• Termination eines Prozesses
• Seitentabelle freigeben, ebenso Sekundärspeicher
• Achtung: gemeinsam genutzte Seiten warden ggf. noch benötigt

• Page Locking
• Trennung von Politik und Mechanismus
© 2018-21 Jörg Ott | GBS | IN 0009 92
Zurück zu malloc()
• BS verwaltet den Speicher aller Prozesse
• Prozesse können ihren Speicherbedarf dynamisch anpassen
• malloc(), realloc(), free() usw.
• Minimieren teurer Systemaufrufe
• Mehrstufiges Vorgehen
• Die C-Library (libc) stellt eigene Speicherverwaltung bereit
• Kann auch durch speziell optimierte Varianten ersetzt werden
• Nutzt nur bei Bedarf die Dienste des Betriebssystems
• void *brk (void *) – Setzen des Endes Datensegments eines Prozesses
• void *sbrk (int) – relative Vergrößerung / Verkleinerung
• Interne Algorithmen zur Freispeicherverwaltung wie besprochen
brk (break + !) == sbrk (!)

Text Daten ! Stack

etext edata end break = sbrk(0);


© 2018-21 Jörg Ott | GBS | IN 0009 93
Minimales malloc ()
#include <assert.h>
#include <string.h>
#include <sys/types.h>
#include <unistd.h>

void *malloc (size_t size) {


void *p = sbrk(0);
void *request = sbrk(size);
if (request == (void*) -1) {
return NULL; // sbrk failed.
} else {
assert (p == request); // Not thread safe.
return p;
}
}
Ineffizient wg. vieler Interaktionen mit dem Kern.

© 2018-21 Jörg Ott | GBS | IN 0009 94


malloc () – libc
• Eigene Datenstruktur zur Speicherverwaltung angehängt an
den Speicherbereich, den der Nutzer erhält
malloc (size);
• Allozierter Speicherblock
Speicherblock N

Größe N-1
(wenn N-1 frei)
Größe N P

• Freier Speicherblock prev next Freispeicherliste

Speicherblock N

Größe N-1
Größe N P
© 2018-21 Jörg Ott | GBS | IN 0009 (wenn frei) 95
Beispiel

© 2018-21 Jörg Ott | GBS | IN 0009 96


Beispiel: Windows-Speicherverwaltung
• Sehr komplexe Verwaltungsmassnahmen: hier nur Auszüge
• Virtueller Adressraum bei 32-Bit Architektur: 4 GB, wobei je 2 GB für
Prozess und für Kern
• Seitengröße bei x86: i.d.R. 4 KB
• Keine Adressraumsegmentierung, aber Bündelung virtueller Seiten in
Regions
• Vorhalten von freien Frames, um dynamisch und schnell auf Anfragen
zu reagieren
• Falls genügend freie Frames: kein Handlungsbedarf
• Prepaging: Verwendung eines Working-Set-Ansatzes, um die
benötigten Seiten vorzuhalten
• Seitenersetzung: Aging-artige LRU-Approximation

© 2018-21 Jörg Ott | GBS | IN 0009 97


Beispiel: Linux-Speicherverwaltung
• Virtueller Adressraum auf 32-Bit-Architekturen: 4 GB, davon
1 GB für Seitentabelle und Kernel-Objekte
• Virtueller Adressraum aufgeteilt in:
• Text (read-only)
• Daten (dynamisches Speicherallokieren mit malloc() auf dem Heap)
• Stack-Segment
• 4-stufige Pagetabelle
• Speicher-Allokation
• Buddy-Allocator: Page als kleinste Blockgröße
• Zusätzlich: für Blöcke des Buddy-Verfahrens
• Slab-Allocator: Verwaltung kleinerer Einheiten, um interne Fragmentierung
zu verringern
• Seitenersetzungsstrategie
• Swap-Bereiche: Seiten werden nicht direkt ausgelagert
• Eine Menge von Frames freigehalten, um schnell einlagern zu können
• Variante des Clock-Algorithmus zur Seitenersetzung
© 2018-21 Jörg Ott | GBS | IN 0009 98
6.5 Beispiel:
Virtueller Speicher
Linux-Speicherverwaltung (2) Technische
Universität
München
Linux - Virtuelle Adressierung

• Typische Laufzeitumgebung eines Prozesses unter Linux


� Typische Laufzeitumgebung eines Prozesses unter Linux
(sortiert
(sortiert nach Platzierung
nach Platzierung im Virtuellenim Virtuellen Speicher)
Speicher):

Name Protections Zweck


.text r-x Ausführbarer Code, der die Programmlogik implementiert
.rodata r-- Globale Variablen, nur lesbar (Strings, Konstanten-Pools, ...)
.bss rw- Statisch allokierte globale, schreibbare Variablen (Arrays, ...)
Heap rw- Dynamisch allokierter, schreibbarer Speicher (malloc/free)
libc rw-/r--/r-x C-Standard-Bibliothek
GNU_STACK rw- Programmstack (1 Instanz pro Thread)
vdso r-x Shared Page zwischen Kernel und Prozess zur Performanz-
steigerung bestimmter Systemaufrufe (gettimeofday, ...)
Kernel rw-/r--/r-x Der Betriebssystemkern ist in jeden Prozess gemappt, aller-
dings vom Benutzermodus aus nicht lesbar/schreibbar.

C. Eckert Kapitel 06 — Speicherverwaltung 67 / 1

© 2018-21 Jörg Ott | GBS | IN 0009 99


Beispiel: cat

© 2018-21 Jörg Ott | GBS | IN 0009 100


Chair of Connected Mobility
Department of Informatics
Technische Universität München

Kapitel 07

Grundlagen Betriebssysteme und Systemsoftware


Dateisysteme

Prof. Dr.-Ing. Jörg Ott


Lehrstuhl Connected Mobility

Folien frei nach der Vorlage von Prof. C. Eckert (WS16/17, WS17/18) – danke!

© 2018-21 Jörg Ott | GBS | IN 0009 1


Fragen
• Wie sind Daten auf einer Festplatte abgelegt?

• Woraus ergeben sich Größengrenzen für Dateisysteme?

• Unterschiede zwischen Dateisystemen (z.B. ext2 vs. ext4)?

• Was heißt eigentlich Journaling?

© 2018-21 Jörg Ott | GBS | IN 0009 2


Anforderungen an Dateisysteme
• Motivation
• Prozesse besitzen während ihrer Ausführung nur ihren virtuellen Adressraum,
um Daten zu speichern: beschränkte Kapazität
• Wenn der Prozess terminiert, gehen die Daten aus dem virtuellen Adressraum
verloren: keine langlebige, persistente Datenspeicherung
• Speicherung von Daten in virtuellen Prozessadressräumen erlaubt nur
eingeschränkt gemeinsamen Zugriff: keine gleichzeitige, parallele Nutzung

• Anforderungen an eine Langzeit-Datenspeicherung


• Speicherplatz für (sehr) große Datenmengen bereitstellen
• Daten sollen in großen Mengen (unabhängig von der Hauptspeichergröße)
gespeichert werden können
• Datenverlust vermeiden
• Daten sollen dauerhaft (persistent) gespeichert werden und die Terminierung von
Prozessen überdauern
• Nebenläufigen Zugriff auf Daten ermöglichen
• Mehrere Prozesse sollen in der Lage sein, gleichzeitig auf die Daten zuzugreifen.

© 2018-21 Jörg Ott | GBS | IN 0009 3


Abstraktion der Fesplatte
• Medien für die Langzeit-Datenspeicherung
• Festplatten, SSDs, CD-ROMs, DVDs, Magnetbänder usw.
• Festplatte als Langzeit-Speicher
• Eine Festplatte kann als eine lineare Sequenz von Blöcken fester Größe
angesehen werden
• Operationen zum Lesen eines Blocks: read block k und
zum Schreiben, write block k
• Probleme
• Wie findet man gewünschte Informationen?
• Wie hält man einen Benutzer davon ab, auf Dateien eines anderen
Benutzers zuzugreifen?
• Woher weiß man, welche Blöcke noch frei sind?
• Lösung: BS-Konzept zur Virtualisierung der Eigenschaften der
Festplatte
• Datei-Konzept (engl. file)
• Dateien sind logische Verwaltungs-Einheiten
• Dateien speichern beliebige Informationen persistent (dauerhaft)

© 2018-21 Jörg Ott | GBS | IN 0009 4


Abstraktion der Fesplatte (2)
• Datei-Konzept (Fortsetzung)
• Datei abstrahiert davon, wo die Blöcke gespeichert sind, welche Blöcke
frei sind usw.
• Prozesse können über Systemaufrufe Dateien erstellen, schreiben,
lesen, löschen
• Dateien werden sowohl von Benutzerprogrammen als auch von der
Systemsoftware verwendet
• Beispiel: Auslagern von Seiten des virtuellen Adressraums in das swap file

• Auf UNIX-basierten Systemen gilt:


„Everything is a file“, z.B. auch Geräte
• Drucker /dev/lp0
• Terminals: /dev/tty
• Speziell: /dev/null , /dev/[u]random
• Nur Prozesse, Threads und (virtuelle) Adressräume sind keine Dateien

© 2018-21 Jörg Ott | GBS | IN 0009 5


Dateisystem (file system)
• Zur Verwaltung von Dateien durch das Betriebssystem
• Strukturierung der (Blöcke der) Festplatte
• Aufgaben des Betriebssystems u.a.
• Datenstrukturen zur Beschreibung von Dateien
• auf der Festplatte (z.B. inode)
• Geöffnete Dateien der Prozesse (z.B. Filedeskriptor)
• Implementierung der Dateien
• Benennung
• Zugriffe auf Dateien ermöglichen
• Schutz vor unberechtigten Zugriffen
• Beispiele
• FAT-16/32 (DOS)
• NTFS (Windows NT)
• Ext2/3/4 (Linux)
• ReiserFS, Btrfs, XFS, etc.
• HFS, HFS+, APFS (MacOS)
© 2018-21 Jörg Ott | GBS | IN 0009 6
Dateien
• Dateien als zu verwaltende Einheiten
• Dateien können von unterschiedlichen Prozessen genutzt werden
• Dateien müssen benannt werden: bei ihrer Erzeugung erhält eine Datei
einen Namen
• Dateinamen: Kein einheitliches Benennungsschema für alle BS
• Dateiname besteht häufig aus zwei Teilen
Name und Extension, getrennt durch einen Punkt: filename.extension
• Manche Betriebssysteme (wie z.B.Windows) interpretieren die Datei-
Extensions
• Datei-Extension wird interpretiert und ein bestimmtes Programm aufgerufen,
z.B. Word-Prozessor
• Beispiel-Extensions .pdf, .zip, .html, .gif, .mp3, .docx, etc.
• Andere BS, z.B. UNIX, interpretieren Extensions nicht, diese sind optional
• In Unix sind mehrere Extensions möglich, z.B. homepage.html.zip
• Freiheitsgrad: Beliebiger Inhalt in Datei mit beliebiger Extension
• Aber: das BS interpretiert nicht, keine Unterstützung durch BS
• Datei-Extensions können auch unter Unix hilfreich sein (Konventionen)
• Beispiel: Hilfe für den Compiler: automatische Unterscheidung zwischen C-,
Objekt- und Assembler-Dateien
© 2018-21 Jörg Ott | GBS | IN 0009 7
Dateien (2)
• Dateien können auf drei verschiedene Arten strukturiert sein
• Unstrukturiert: Datei als eine Folge von Bytes (UNIX und Windows)
• Das Betriebssystem hat keine Kenntnis über den Aufbau von Dateien
• Jegliche Strukturierungsinformation muss direkt von Benutzerprogramme
erstellt werden
• Vorteil: Flexibilität für Benutzerprogramme (das BS macht keine Vorgaben)

• Sequenzen von Einträgen (engl. records) fester Größe


• Jeder Eintrag hat eine feste Größe und Struktur
• Gängige BS nutzen dieses Konzept heute nicht mehr

• Ein Baum mit Einträgen unterschiedlicher Größe


• Jeder Eintrag ist mit einem Key versehen
• Die Einträge werden sortiert gespeichert (ermöglicht schnelles Auffinden
von einem Key)
• Wird heute z.B. noch bei Großrechner-BS für die Verarbeitung großer
Datenmengen genutzt

© 2018-21 Jörg Ott | GBS | IN 0009 8


Dateien (3)

© 2018-21 Jörg Ott | GBS | IN 0009 9


Dateitypen
• Betriebssysteme unterstützen verschiedene Dateitypen
• Dateien (engl. regular files) enthalten Benutzerdaten
• Text-Dateien: Bestehen aus Zeilen, die durch carriage return und/oder
linefeed Zeichen abgeschlossen sind
• Binärdateien: Besitzen ein bestimmtes Format, z.B. ausführbare Dateien
und Archivdateien (siehe nächste Folie)
• Verzeichnisse (engl. directories)
• Systemdateien zur Verwaltung und Strukturierung des Dateisystems
• Character Special Files
• Modellieren serielle I/O Geräte wie z.B. Terminals, Drucker, Netze usw.
• Block Special Files
• Modellieren Massenspeicher wie Festplatten, CD-ROMs, USB-Speicher,
SSDs usw.

• Dateityp wird bei „ls -l“ angezeigt (erstes Zeichen)


• Datei (-), Verzeichnis (d), Character (c) und Block (b) Special File
© 2018-21 Jörg Ott | GBS | IN 0009 10
Beispiele
Ausführbare Datei Archivdatei

© 2018-21 Jörg Ott | GBS | IN 0009 Quelle: Tanenbaum/Bos 11


Dateizugriff
• Sequential access (in älteren Betriebssystemen)
• Prozess liest der Reihe nach Bytes (oder Records) einer Datei
• Teile der Datei können nicht übersprungen werden
• Geeignet für Magnetbänder als Speichermedium, aber unflexibel

• Random-access
• Prozess liest Bytes (oder Records) einer Datei in einer beliebigen
Reihenfolge
• Random-access ist essentiell unter anderem in Datenbanksystemen
• Der lseek Systemcall unter UNIX erlaubt es, die aktuelle Position in
der Datei zu spezifizieren
• Beispiel: lseek (fd, 10, SEEK_SET);

© 2018-21 Jörg Ott | GBS | IN 0009 12


Dateizugriff (2)
Technische
Universität
München

1 int main(int argc, char *argv[])


2 {

en Betriebssystemen): 3 int fd;


4 char buf[128];
nach Bytes (oder Records) 5
6 fd = open("myfile.txt", O_RDONLY);
nicht übersprungen 7 if (fd < 0)
8 return EXIT_FAILURE;
9
nder als Speichermedium, 10 /* Move current position by 10 bytes */
11 if (lseek(fd, 10, SEEK_SET) < 0)
12 return EXIT_FAILURE;
13
14 if (read(fd, buf, 128) < 0)
r Records) einer Datei in 15 return EXIT_FAILURE;
folge. 16
nziell unter anderem in 17 printf("%s\n", buf);
18
19 close(fd);
nter UNIX erlaubt es, die 20
Datei zu spezifizieren. 21 return EXIT_SUCCESS;
k_set): 22 }

© 2018-21 Jörg Ott | GBS | IN 0009 13


Kapitel 07 — Dateisysteme 10 / 1
Dateiattribute
• Dateiname, Dateiinhalt
• Weitere Information pro Datei: (Meta-)Informationen
• Zugriffsrechte an der Datei
• Beispiel Unix-artige Systeme
• Vergabe von Zugriffsrechten an: Owner, Group und All
• Zugriffsrechte: r (read), w (write), x (execute)
• Beispiel: drwx r-x —
• drei Gruppen zu je drei Bit – typischerweise in Oktalrepräsentation angegeben

• Flags (Bitfelder) kontrollieren einige Eigenschaften der Datei


• Z.B. Dateien verstecken, unterscheiden zwischen Binär- oder Archivdateien,
etc.
• Zeiteinträge beschreiben u.a. wann die Datei erstellt, zuletzt modifiziert und
ggf. zugegriffen wurde
• Makefiles nutzen diese Informationen
• Dateigröße

© 2018-21 Jörg Ott | GBS | IN 0009 14


Dateiattribute (2)

Quelle: Tanenbaum/Bos
© 2018-21 Jörg Ott | GBS | IN 0009 15
Datei-Operationen
• BS definieren Operationen, um auf Dateien zuzugreifen
• Gängige Operationen, angeboten über Systemcalls
• Erzeugen und Löschen einer Datei
• Open: Vor einem Zugriff auf eine Datei muss diese geöffnet werden
• Damit lädt das BS die Dateiattribute und andere Infos in den Hauptspeicher, für
eine schnelle Bearbeitung wichtig
• Open liefert einen Datei-Deskriptor als Ausgabe, das ist ein kleiner Integerwert
• Unlink: entfernt eine Datei

• Nachfolgende Zugriffe auf die Datei unter Nutzung des Deskriptors.


• Close: Angabe des Datei-Deskriptors, Freigabe von internen
Datenstrukturen, manche BS erlauben nur eine festgelegte Zahl von offenen
Dateien pro Prozess
• Read: Angabe der gewünschten Daten und Angabe eines Puffers, in den die
Daten geschrieben werden sollen.
• Write: Schreiben von Daten an der aktuellen Position
Daten werden ggf. überschrieben
• Seek: Positionieren des Datei-Zeigers auf eine spezifische Position
(ab der gelesen oder geschrieben werden soll)
© 2018-21 Jörg Ott | GBS | IN 0009 16
Beispiel: Kopieren einer Datei
#include <stdlib.h>
#include <fcntl.h>
#include <unistd.h>
#define BUF_SIZE 4096

int main (int argc, char *argv[]) {


int fd_in, fd_out, count;
char buf[BUF_SIZE];

if (argc != 3) return EXIT_FAILURE; // We expect 2 file names as input.

if ((fd_in = open (argv[1], O_RDONLY)) == -1) // Open file to read from.


return EXIT_FAILURE;
// Open/create file with rw privileges for the user.
if ((fd_out = open (argv[2], O_WRONLY|O_CREAT, S_IRUSR|S_IWUSR)) == -1)
return EXIT_FAILURE;
// Copy the file’s contents in the loop.
while ((count = read(fd_in, buf, BUF_SIZE)) > 0) {
if (write(fd_out, buf, count) <= 0)
return EXIT_FAILURE;
}
close(fd_in); close(fd_out);
return EXIT_SUCCESS;
}
© 2018-21 Jörg Ott | GBS | IN 0009 17
Verzeichnisse
• Das Datei-System organisiert Dateien in Verzeichnissen
(engl. directories)
• Verzeichnis ist eine Datei, die nur Verwaltungsinformationen enthält
• Ein Verzeichnis ermöglichen eine hierarchische Verwaltung

• Single-Level Verzeichnisstrukturen
• Nur ein Verzeichnis (root-Verzeichnis) für alle Dateien
• Dateien können sehr schnell gefunden werden, aber keine Struktur!
• Heute noch eingesetzt in Embedded Systemen
• z.B. digitale Kameras, Musikplayer, etc.
• Problem: Nur ein Verzeichnis für alle Benutzer

Quelle: Tanenbaum/Bos

© 2018-21 Jörg Ott | GBS | IN 0009 18


Verzeichnisse (2)
• Hierarchische Verzeichnisstrukturen
• Hierarchische Gruppierung verwandter Dateien in einem Verzeichnis
• Benutzer haben jeweils ihr eigenes Verzeichnis mit Unterverzeichnissen

© 2018-21 Jörg Ott | GBS | IN 0009 Quelle: Tanenbaum/Bos 19


Pfadnamen
• Benennung von Dateien in baumartigen Verzeichnisstrukturen
• Absolute Pfadnamen
• Pfadnamen umfassen den gesamten Pfad vom Root-Verzeichnis
bis zur gesuchten Datei
• Pfadname des Root-Verzeichnisses: “/” (UNIX) und “\” (Windows).
• Beispiel: /tum/git/gbs/uebungsbetrieb/ws18/09/c-files/mem.c

• Relative Pfadnamen
• Pfadnamen beziehen sich auf das aktuelle Arbeitsverzeichnis
(Current) Working Directory
• Beispiel: Referenzieren der Datei blatt09.pdf oder c-files/mem.c in dem
Arbeitsverzeichnis /tum/git/gbs/uebungsbetrieb/ws18/09

• Spezielle Einträge in jedem Verzeichnis


• Zwei spezielle Einträge: “.” (dot) und “..” (dotdot)
• Dot bezieht sich auf das aktuelle Arbeitsverzeichnis
• Dotdot bezieht sich auf den übergeordnete Verzeichnis
• Beispiel: cp ../08/gbsuebung.cls . im Arbeitsverzeichnis ws18/09/

© 2018-21 Jörg Ott | GBS | IN 0009 20


Dateisystem-Implementierung
• Bislang: Nutzer-Sicht auf ein Dateisystem
• Datei-Benennungsschema
• Operationen auf Dateien
• strukturierte Verwaltung

• Im Folgenden: Implementierungs-Sicht
• Speicherung und Verwaltung von Dateien und Verzeichnissen

• In Vorlesung nicht: Verwaltung des Plattenplatzes


• z.B. Freibereichsliste für Blöcke usw.
• Ähnliche Fragestellungen wie bei Freispeicherverwaltung

© 2018-21 Jörg Ott | GBS | IN 0009 21


Dateisystem-Layout
• Speicherung des Dateisystems auf der Festplatte
• Festplatten in Partitionen aufgeteilt
• Speichern eines Dateisystems pro Partition (unabhängig von anderen)
• Sektor 0 der Platte ist der Master Boot Record (MBR) mit
dem MBR-Programm
• Beim Booten liest das BIOS (heute eher UEFI) den MBR in den
Speicher ein und führt das MBR-Programm aus
• Lokalisieren der aktiven Partition
• Einlesen des ersten Blocks, des Boot-Blocks
• Ausführen des Boot-Blocks: Programm im Boot-Block lädt das BS aus
der Partition
• Partitions-Tabelle: Anfangs- und End-Adresse pro Partition

© 2018-21 Jörg Ott | GBS | IN 0009 22


Dateisystem-Layout (2)
• Layout einer Partition mit Einträgen, Dateisystem-abhängig
• Superblock mit Informationen über das Dateisystem
• u.a. Magic Number, Anzahl der Blöcke, etc.
• Informationen über freie Blöcke
• z.B. in Form einer Bitmap oder Liste von Pointern
• Eine Menge von Dateideskriptoren (in Unix i-node)
• Beschreiben die Dateien im Dateisystem
• Daten der Verzeichnisse und Dateien

© 2018-21 Jörg Ott | GBS | IN 0009 Quelle: Tanenbaum/Bos 23


Implementierung von Dateien
• Hauptaufgabe
• Verwalten der Blöcke, die die Datei-Inhalte speichern
• Verschiedene Ansätze dafür
1. Continous
2. Linked List
3. i-nodes

© 2018-21 Jörg Ott | GBS | IN 0009 24


Contiguous Allocation
• Datei wird als zusammenhängende Folge von Blöcken auf
der Festplatte verwaltet
• Beispiel: Festplatte mit 2-KB Blöcken. Eine 50-KB Datei wird in 25
zusammenhängenden Blöcken gespeichert
• Vorteile:
• Einfache Implementierung
• Speichern der Adresse des ersten Blocks und Anzahl der Blöcke pro Datei
• Lesen ist sehr performant
• Nur eine Positionierungs-Operation für den Schreib/Lesekopf notwendig,
um die gesamte Datei von der Platte einzulesen
• Nachteile
• (Externe) Fragmentierung
• Mit der Zeit entstehen “Löcher” von freien Speicherbereichen
• Defragmentierung des Speichers ist sehr zeitaufwendig
• Nutzung bei Read-Only-Medien
• CD-ROM, DVD, BluRay-Disks
© 2018-21 Jörg Ott | GBS | IN 0009 25
Beispiel: Contiguous Allocation

Quelle: Tanenbaum/Bos

© 2018-21 Jörg Ott | GBS | IN 0009 26


Linked List Allocation
• Die durch die Datei belegten Blöcke werden in einer
verketteten Liste verwaltet
• Das erste Wort innerhalb des Blocks wird als Zeiger auf den
nächsten Block verwendet
• Vorteile
• Es geht kein Speicherplatz verloren
• bis auf interne Fragmentierung im letzten Block
• Nachteile
• Niedrige Performance bei Random-Access
• Um Block n zu finden, müssen die ersten n−1 Blöcke gelesen werden
• Festplattenzugriff ist sehr langsam.
• Größe des verfügbaren Speichers in einem Block keine 2er-Potenz
• Zeiger auf den nächsten Block nimmt Platz im Block ein
• Operationen nutzen i.d.R. Blockgrößen als Parameter
• zum Lesen eines Bereichs, der eine Blockgröße umfasst, müssen 2 Blöcke
geladen werden

© 2018-21 Jörg Ott | GBS | IN 0009 27


Beispiel: Linked List Allocation

Quelle: Tanenbaum/Bos
© 2018-21 Jörg Ott | GBS | IN 0009 28
Linked List Allocation mit File Allocation Table (FAT)
• Zeiger auf den nächsten Block wird in einer Tabelle im
Hauptspeicher verwaltet
• Beispiel: Zwei Dateien mit Blöcken
A: 4, 7, 2, 10, 12 (-1 = Ende der Liste)
B: 6, 3, 11, 14 (-1)
• Vorteile
• Kein Verschnitt pro Block.
• Random-Access ist schneller
• Liste nur im Speicher durchlaufen
• Nachteile
• FAT muss im RAM gehalten werden
• Wieviel Speicher benötigt eine FAT bei
einer 1-TB-Festplatte, 1-KB Blockgröße
und 4 Byte pro Eintrag?
Quelle: Tanenbaum/Bos
© 2018-21 Jörg Ott | GBS | IN 0009 29
i-nodes
• Jede Datei wird durch die Datenstruktur
eines Index-Node (i-node) repräsentiert
• Dateiattribute und die Adressen der
belegten Blöcke
• Vorteile
• Ein i-node muss nur für eine geöffnete
Datei in den Speicher geladen werden
• Speicherbedarf proportional zur Anzahl
von Dateien, die gleichzeitig geöffnet sein
dürfen (nicht zur Festplattenkapazität)
• Nachteile
• Jeder i-node enthält eine feste Anzahl an
Blockadressen: begrenzt max. Dateigröße
• Umgehung: Der letzte i-node Eintrag zeigt Quelle: Tanenbaum/Bos
auf einen Block mit weiteren Blockadressen
© 2018-21 Jörg Ott | GBS | IN 0009 30
i-nodes (2)
• Indirekte, doppelt indirekte und dreifach indirekte Blöcke
• Dateien sind meist klein
• Für große Dateien sind zunehmende Indirektionen akzeptabel

Quelle: Tanenbaum/Bos
© 2018-21 Jörg Ott | GBS | IN 0009 31
Beispiel: i-nodes
• Öffnen einer Datei unter Linux: Datenstrukturen im RAM
• i-node Tabelle
• Open-File-Descriptor-Table
• Pro Prozess: File-Descriptor Table
• Prozess P1
• fd = open(Datei1);
1. Lade inode für Datei 1
2. Erzeuge Eintrag in Open-File-Descriptor-Table
3. Erzeuge fd
4. Erzeuge Verweis in File-Descriptor-Table von P1

• Prozess P2
• fd = open(Datei1);

© 2018-21 Jörg Ott | GBS | IN 0009 32


Realisierung von Verzeichnissen
• Hauptaufgabe: Pfadname auflösen, Datei auf der Festplatte
finden
• Verzeichniseintrag (engl. directory entry)
• Verzeichnisse bestehen aus einer Menge von Verzeichniseinträgen
• Beispiel: /home/eva, /home/heinz, /home/karl
• Verzeichnis /home enthält 3 Dateien, mit jeweils einem Eintrag in /home
• Beim Öffnen verwendet das BS den Pfad einer Datei, um den
zugehörigen Verzeichniseintrag zu finden
• Ein Verzeichniseintrag enthält
• Dateinamen
• Adress-Informationen, um die gesuchte Datei zu lokalisieren
• Adresse auf der Festplatte
• oder die Nummer des ersten Blocks
• oder die Nummer des I-nodes
• Verweis auf Datei-Attribute
• Datei-Besitzer
• Erzeugungszeitpunkt
• ...
© 2018-21 Jörg Ott | GBS | IN 0009 33
Realisierung von Datei-Attributen
• Unterschiedliche Optionen zur Verwaltung
• (a) Direkt im Verzeichniseintrag
• (b) In den i-nodes
• Verzeichniseintrag besteht nur aus dem Dateinamen und einer i-node
Nummer.

Quelle: Tanenbaum/Bos

© 2018-21 Jörg Ott | GBS | IN 0009 34


Beispiel
• Pfadauflösung: /home/eva/file
• i-node-Nummern
• 1 von /
• 4 von home
• 6 von eva
• 7 von file


Disk

i-nodes Datenblöcke
© 2018-21 Jörg Ott | GBS | IN 0009 35
Dateinamen variabler Länge
• Bislang: Annahme, dass Dateinamen
eine kurze (maximale) Länge haben
• Wie können wir längere Dateinamen mit
variabler Länge verwalten?
• Dateinamenlänge limitieren
• z.B. auf 255 Zeichen
• Nicht alle Dateinamen sind gleich lang
• Verschwendung von Speicherplatz

• Dateinamen mit beliebiger Länge


• Jeder Verzeichniseintrag benötigt eine Länge
• Beispiel: Drei Dateien mit unterschiedlich langen
Dateinamen: project-budget, personnel und foo
• Problem?
Quelle: Tanenbaum/Bos

© 2018-21 Jörg Ott | GBS | IN 0009 36


Dateinamen variabler Länge (2)
• Verzeichniseinträge mit Referenzen zum
Heap, der die Datei-Namen speichert
• Vorteil: Keine Fragmentierung beim Löschen
von Dateien. Ein neuer Eintrag wird immer an
die Stelle des gelöschten Eintrags passen

• Problem
• Suchen von Dateien in Verzeichnissen
mit vielen Einträgen ist langsam

• Verbesserung
• Verwenden einer Hash-Tabelle in jedem
Verzeichnis (siehe nächste Folie)
• Index des Verzeichniseintrages wird
durch das Hashen vom Dateinamen erhalten
• Kollisionen in einem Verzeichniseintrag explizit
durch eine verkettete Liste behandeln
Quelle: Tanenbaum/Bos
© 2018-21 Jörg Ott | GBS | IN 0009 37
Dateinamen variabler Länge
• Ergänzung: Hashfunktion
• Eine Hashfunktion bildet eine große Eingabemenge (die Schlüssel) auf
eine kleinere Zielmenge (die Hashwerte) ab
• Eine Hashfunktion ist i.d.R. nicht injektiv
• mehrere Dateinamen können auf denselben Hashwert abgebildet werden
• Kollisionen Möglich, die aufgelöst werden müssen
• z.B. mit Hashketten

• Hashtabelle
• Indexstruktur, um Datenelemente in einer großen Datenmenge
aufzufinden
• konstante Zeit für Einfüge- und Entnahme-Operationen
• Beispiel: Hashtabelle mit 26 Einträgen
• Hashfunktion H(Suchbegriff): Abbilden auf den ersten Buchstaben von
Suchbegriff
• z.B. H(Budget) = b, H(Personal)= P, H(Projekt) = P Kollision!

© 2018-21 Jörg Ott | GBS | IN 0009 38


Gemeinsame Nutzung von Dateien
• Einführung von Links
• Aus einem Baum wird ein azyklischer Graph
• Mehrere Pfade führen zu einer Datei
• Unterschiedliche Namen möglich
• Zwei Ansätze
• Hard Links
• Verzeichnisse verweisen auf i-nodes
• i-nodes beschreiben die Dateien
• Weitere Verweise auf i-nodes zulassen
• Keine Unterscheidung zwischen 1. und n. Link
• i-nodes erhalten Reference Counts
• Zeigt an, wann die Datenstruktur freigegeben warden kann
• Erklärt den Namen des Systemcalls
zum Löschen unter UNIX: unlink()
Quelle: Tanenbaum/Bos
• Symbolic Links
• Erzeugen einer besonderen Datei mit Verweis auf die verlinkte Datei
durch Angabe des Pfadnamens (je nach Länge in i-Node oder Datenblock)
© 2018-21 Jörg Ott | GBS | IN 0009 39
(Hard) Links

Quelle: Tanenbaum/Bos

© 2018-21 Jörg Ott | GBS | IN 0009 40


Journaling-Dateisysteme
• Motivation: Konsistenz nach System-Crashes
• Mehrere Operationen notwendig, um eine Datei unter UNIX zu löschen
1. Entferne die Datei aus ihrem Verzeichnis
2. Gib den i-node in den Pool der freien i-nodes frei
3. Markiere alle von der Datei belegten Festplatten Blöcke als frei
• Beispiel: rm /home/eva/file
1. Entfernung Eintrag für file aus Verzeichnis eva (i-node 007)
2. Freigabe der inode für Datei file (i-node 4711)
3. Markierung der Datenblöcke von file als frei

• Crash nach Schritt 1: i-node und Blöcke nicht mehr zugreifbar


• in inode 007 (eva) kein Verweis mehr auf die inode 4711
• inode 4711 und die Datenblöcke der Datei file sind nicht mehr auffindbar
• Alternative
1. Freigabe der inode für Datei file (i-node 4711)
2. Entfernung Eintrag für file aus Verzeichnis eva (i-node 007)
3. Markierung der Datenblöcke von file als frei
• Problem bei Crash nach Schritt 1?
© 2018-21 Jörg Ott | GBS | IN 0009 41
Journaling-Dateisysteme
• Lösung: Journaling Dateisysteme
• z.B. in: NTFS, ReiserFS, ext3/4
• Protokollieren aller Änderungen des Dateisystems in einem Speicherbereich
(dem Journal), bevor sie durchgeführt werden.
• Alle Änderungen können rekonstruiert werden
• Vorgehen
• Erstellen eines Log-Eintrags, der die drei Operationen beschreibt
• Speicherung in Journal auf der Platte
• erneutes Lesen, um korrekte Speicherung zu prüfen
• Ausführen der drei Operationen
• Abschluss jeder Operation auf der Platte vermerkt: Fortschrittsbericht
• Löschen des Log-Eintrags, wenn die drei Operationen vollständig durchgeführt
worden sind
• Crash und Reboot
• Inspektion des Journals
• Wenn unvollständige Operationen vorhanden: alle drei erneut ausführen
• Voraussetzung: alle Operationen müssen idempotent sein

© 2018-21 Jörg Ott | GBS | IN 0009 42


Journaling-Dateisysteme
• Idempotente Operationen
• Das wiederholte Ausführen einer Operation führt zum selben Ergebnis
• D.h. Operationen können wiederholt werden (keine Seiteneffekte)
• Beispiel: Markiere den Block k in der Bitmap als frei
• Problem
• Operation ggf. umzudefinieren, damit sie idempotent werden
• Beispiel: Operation Block-Freigeben
• Füge freien Block am Ende der Liste ein
• Nicht idempotent; ggf. wird der Block mehrfach als frei markiert eingefügt
• Idempotente Alternative
• Suche, ob Block n schon in der Frei-Liste ist; falls nicht, füge ihn ein

• Erhöhung der Zuverlässigkeit eines Dateisystems


• Klammern von Operationen in einer atomaren Transaktion
• Semantik der atomaren Transaktion
• Ausführung der Operationen: ganz oder gar nicht

© 2018-21 Jörg Ott | GBS | IN 0009 43


Virtual File System (VFS)
• Motivation
• Auf einem Rechner können mehrere FS genutzt werden
• z.B. unter Windows: Windows NTFS, FAT-32, CD-ROM etc.
• Windows
• Jedem Dateisystem wird ein Laufwerk zugewiesen: C, D, etc.
• keine Integration der Dateisysteme in ein einheitliches Dateisystem
• Unix-artige Systeme
• Integration, einheitliche Struktur, transparent für Nutzer
• Integration durch virtuelles Dateisystem

• Virtuelles Dateisystem
• Konzept, um mehrere unterschiedliche
Dateisysteme auf einem lokalen
Rechner zu unterstützen und
• um entfernte Dateisysteme zu nutzen

© 2018-21 Jörg Ott | GBS | IN 0009 44


Virtual File System (VFS)
• VFS stellt einheitliche (POSIX) Schnittstelle zur Verfügung
• open, read, write, lseek usw.
• (Im Kern) abgebildet auf Operationen der einzelnen Dateisysteme

Quelle: Tanenbaum/Bos

© 2018-21 Jörg Ott | GBS | IN 0009 45


Optimierungen für Dateisysteme (1)
• Buffer Cache
• Pufferplatz im Hauptspeicher für Datenblöcke des Dateisystems
• Vorgehen bei Lese-Operation
• Prüfen, ob der Block im Cache ist: ja -> Schritt 3
• Andernfalls: Block in den Cache lesen
• Daten des Blocks zurückliefern
• Falls kein Platz im Cache ist
• Ersetzungsstrategie z.B. entsprechend der Paging-Algorithmen
• Problem: Blöcke sind unterschiedlich bedeutsam
• Einige Blöcke (i-Nodes, Verzeichnisse) wichtiger für Konsistenz als Dateiblöcke
• Erstere eher Zurückschreiben als letztere
• Vorgehen bei Schreib-Operationen
• Daten in den Buffer Cache geschrieben (nicht zwingend sofort auf die Disk)
• Unix: Befehl (sync(1)) zum Schreiben des Buffer Cache auf die Festplatte
• Wird regelmäßig im Hintergrund ausgeführt (z.B. alle 30s durch update daemon)
• Windows: Write-thru Cache
• Daten warden sofort auf die Festplatte geschrieben
• Unterschiedliche Vor- und Nachteile
© 2018-21 Jörg Ott | GBS | IN 0009 46
Optimierungen für Dateisysteme (2)
• Read-Ahead
• In Kürze benötigte Blöcke vorab in den Buffer Cache laden
• Einfache Vorhersage
• Wenn Block k einer Datei angefragt wird, prüfe ob k+1 im Cache ist
• Falls nicht: lade Block k+1 vorab
• Kombiniert mit Erfahrungen über Dateinutzung
• In einem Dateiattribut vermerken, ob die Datei sequentiell gelesen wurde
• Read-Ahead nur dann, wenn dem so ist
• Reduktion der Bewegungen des Schreib-/Lese-Kopfes
• Unterbringen der benachbarten Daten einer Datei nahe beieinander
• Z.B. in Blöcken auf demselben Zylinder
• Ein Ansatz: Verwaltung von Blöcken in Gruppen (z.B. 2, 4) statt einzeln
• Unterstützt implizit eine gewissen Grad an Lokalität
• i-nodes nicht (nur) am Anfang der Partition
• In der Mitte oder verteilt auf mehrere Gruppen von Zylindern

• Defragmentierung
• Neugruppierung der Blöcke der Dateien auf der Festplatte

© 2018-21 Jörg Ott | GBS | IN 0009 47


Beispiel: ext2 für Linux
• Aufteilung der Festplatten-Partition in Block-Gruppen
• Block 0 reserviert für den System-Bootup-Vorgang
• Alle folgenden Block-Gruppen umfassen
• Einen Superblock mit Informationen über das Layout des Dateisystems
• Anzahl der i-nodes und Blöcke, Pointer zur Liste mit freien Blöcken, etc.
• Einen Gruppen-Deskriptor mit Informationen über die Block-Gruppe
• Position der Bitmaps, Anzahl freie i-nodes und Blöcke, Anzahl der Verzeichnisse
• Zwei Bitmaps (je ein Block groß), die freie Blöcke und i-nodes verwalten
• Bei 1-KB großen Blöcken limitiert dieses Design die Blockgruppe auf 8192
Blöcke und i-nodes.
• i-nodes (je 128 Byte) und Daten Blöcke

© 2018-21 Jörg Ott | GBS | IN 0009 Quelle: Tanenbaum/Bos 48


Beispiel: ext2 für Linux
• Beim Öffnen einer Datei, wird zunächst nach dem i-node
des Verzeichnisses gesucht
• i-node-Nummer aus dem Verzeichniseintrag indiziert die i-node-Tabelle
auf der Festplatte, um den i-node der Datei in den Speicher zu laden
• Der i-node wird in die i-node-Tabelle im Speicher eingetragen
• Die i-node-Tabelle enthält i-nodes für alle offenen Dateien und
Verzeichnisse

© 2018-21 Jörg Ott | GBS | IN 0009 Quelle: Tanenbaum/Bos 49


Beispiel: ext2 für Linux
• Lesen einer Datei mit Datei-Deskriptor als Parameter
• Datei-Deskriptor ist Index in die Datei-Deskriptor-Tabelle des Prozesses im BS
• Tabellen-Eintrag enthält Zeiger auf systemglobale Open-File-Description-
Tabelle des Betriebssystems
• Eintrag in der Open-File-Description-Tabelle enthält u.a.
• Zeiger auf die i-node in der i-node Tabelle, Position des letzten Dateizugriffs
• Eltern-, Kindprozesse teilen ggf. Einträge in der Open-File-Description-Tabelle
• Unabhängige Prozesse haben eigenständige Einträge

• Verwaltung von großen Dateien


• I-nodes speichern Adressen zu den ersten 12 Blöcken der Datei
• Falls die Datei größer als 12 Blöcke sein sollte, so wird indirekt durch einen oder
mehrere Blöcke mit Adressen zu weiteren Blöcken verlinkt

• Erhöhung der Lese-Performance


• Verzögerung aller Schreiboperationen um 30 Sekunden
• Problem: Es kann zu (begrenztem) Datenverlust bei Systemausfällen kommen
• Besser: Verwendung eines Journaling-Dateisystems

© 2018-21 Jörg Ott | GBS | IN 0009 50


Beispiel: ext2 für Linux

© 2018-21 Jörg Ott | GBS | IN 0009 Quelle: Tanenbaum/Bos 51


Beispiel: ext4 für Linux
• Linux ext4-(Journaling-)Dateisystem
• Nachfolger von ext3, das wiederum Nachfolger von ext2 ist
• Das Dateisystem unserer Linux-VM verwendet ext4
• Journal ist eine Datei, als ein Ringpuffer implementiert
• Journal wird auf einer Dateisystem-unabhängigen Schicht verwaltet: Journaling
Block Device (JBD)
• JBD unterstützt die folgenden Datenstrukturen
• Log-Eintrag (Log Record)
• Beschreibt eine Low-level-Dateisystem-Operation, die einen Block modifiziert
• Atomic Operation Handle
• Gruppiert mehrere zusammengehörige Log-Einträge und führt sie atomar aus
• Beispiel: Systemcall write()
• Änderungsoperationen betreffen die i-node, Blöcke, die Liste der freien Blöcke usw.
• Diese Änderungsoperationen sollten atomar als Einheit ausgeführt werden.
• Transaktionen
• JBD behandelt mehrere atomare Operationen als Transaktionen
• Log-Einträge einer Transaktion dürfen nur dann aus dem Journal entfernt werden,
wenn alle Operationen auf die Festplatte geschrieben wurden
Siehe https://www.kernel.org/doc/html/latest/filesystems/ext4/
© 2018-21 Jörg Ott | GBS | IN 0009 52
Beispiel: ext4 für Linux
• Zuordnung von Blöcken zu Dateien
• Bisher: Pointer auf einzelne Blöcke (60 Bytes in i-Node)
• Direkte und ein-/zwei-/dreifach indirekte Blöcke
• Neu: Extents (60 Bytes in i-Node)
• Baumstruktur
• Lauflängenkodierung für Blöcke
• Effizient für aufeinanderfolgend liegende Blöcke

Header Extent Extent Extent


Magic # Typ: Blatt (implizit aus Tiefe = 0)
# Extents = 3 Log. Block in Datei (1. Block = 0)
Max extents Anzahl aufeinanderfolgender Blöcke
Tiefe = 0 Start-Blocknummer auf der Festplatte

Header Extent Extent Header Extent Extent


Magic # Typ: Knoten (implizit aus Tiefe > 0)
# Extents = 1 Log. Block in Datei (1. Block = 0)
Extent Extent Extent
Max extents Blocknummer des nächsten Extents …
Tiefe = 1 auf der Festplatte
© 2018-21 Jörg Ott | GBS | IN 0009 53
Beispiel: /proc unter Linux
• /proc ist ein virtuelles Dateisystem als Schnittstelle zu
Kernel-Datenstrukturen
• Kernel-Datenstrukturen repräsentiert in Form von Dateien und Verzeichnissen
• /proc wird nicht auf der Festplatte gespeichert, sondern vom Betriebssystem
im Speicher angelegt
• Jeder Prozess hat ein Verzeichnis in /proc/, mit der PID als Namen:
/proc/<PID>
• Der Eintrag enthält Prozess-relevante Informationen, wie z.B. belegter Platz im
Speicher, offene Dateien, etc.
• Weitere Einträge in /proc enthalten z.B. Informationen über die Hardware
• /proc/devices Liste der block- und zeichenorientierten Geräte.
• /proc/partitions Liste aller bekannten Plattenpartitionen
• Informationen über den Kernel, u.a. in
• /proc/filesystems Liste aller Dateisystemtypen
• /proc/modules Eine Liste der aktuell geladenen Kernel-Module
• /proc/net Netzkonfiguration

© 2018-21 Jörg Ott | GBS | IN 0009 54


Chair of Connected Mobility
Department of Informatics
Technische Universität München

Kapitel 08

Grundlagen Betriebssysteme und Systemsoftware


Ein- / Ausgabe

Prof. Dr.-Ing. Jörg Ott


Lehrstuhl Connected Mobility

Folien frei nach der Vorlage von Prof. C. Eckert (WS16/17, WS17/18) – danke!

© 2018-21 Jörg Ott | GBS | IN 0009 1


Fragen
• Wie werden Daten mit Geräten ausgetauscht?

• Wie wird ein Zoo verschiedener Geräte einheitlich organisiert?

• Was tut (m)ein Network-Attached-Storage-System (NAS)?

• Wie findet „Hello, world“ den Weg auf den Bildschirm?

• Wie funktioniert login per ssh(1)?

© 2018-21 Jörg Ott | GBS | IN 0009 2


Einführung
• Eine der Hauptaufgaben eines Betriebssystems
• Überwachen und steuern der Ein-/Ausgabegeräte (E/A)

• Betriebssystem
• Sendet Kommandos an Geräte
• empfängt Unterbrechungsereignisse
• führt Fehlerbehandlungen durch
• stellt für andere Systemteile eine einfach zu nutzende Schnittstelle zu
den Geräten bereit
• Diese Schnittstelle sollte Geräte-unabhängig sein

• Grobe Klassifikation:
blockorientierte und zeichenorientierte E/A-Geräte
• Nicht alle Geräte passen gut in dieses Schema

© 2018-21 Jörg Ott | GBS | IN 0009 3


Arten von Geräten
• Blockorientierte Geräte (block devices)
• Inhalte sind adressierbar
• Daten in Blöcken fester Größe von 29 Byte bis 216 Byte gespeichert
• Freier Zugriff (Random access) auf jeden Block möglich
• Beispiele: Blu-ray-Disk, Festplatte, SSD

• Zeichenorientierte Geräte (character device)


• serieller Datentransfer
• Inhalte sind nicht adressierbar
• Zeichenströme werden gesendet und/oder empfangen
• Beispiele: Maus, Tastatur, Drucker, (Netzkarte)

• Andere Geräte
• Uhr (erzeugt Unterbrechungen), Bildschirm

© 2018-21 Jörg Ott | GBS | IN 0009 4


Ein generisches Gerät

CPU

Hauptspeicher
Systembus

Geräte-
“Kabel”
Steuereinheit Steuerelektronik
(Device Controller)

© 2018-21 Jörg Ott | GBS | IN 0009 5


Geräte-Controller
• E/A-Geräte bestehen aus einer mechanischen und einer elektronischen
Komponente, dem Geräte-Controller
• Controller besitzt Hardware-Schnittstelle zum Gerät
• SCSI, USB, Firewire, Funk, ...

• Übertragung eines Bitstroms vom/zum Gerät


• z.B. bei Festplatte: Serieller Bitstrom wird in Blöcke konvertiert,
Fehlerkorrekturen
• Controller besitzen Register: Kommunikation mit CPU
• Übertragung von Daten an das Gerät: BS schreibt in Register
• Zustand des Geräts erfragen: BS liest Register-Inhalte
• Zusätzlich: Datenpuffer, die das BS lesen und schreiben kann

Steuerregister (Kommandos, Konfiguration)


Statusregister (Zustand)
Datenpuffer (Ein-/Ausgabe)
Interruptleitung (asynchrone Benachrichtigung)
Device Controller
© 2018-21 Jörg Ott | GBS | IN 0009 6
Interaktion mit dem Controller
• I/O-Ports
• Nutzung von speziellen CPU-Instruktionen
• Beispiel: Intel x86: IN, INS, OUT, OUTS
• Memory-Mapped I/O
• Jedem Controller-Register wird eine Adresse im RAM zugewiesen
• Zugriff auf die Register erfordert keine I/O-spezifischen Kommandos
• Geräte müssen wissen, auf welche Adressen sie reagieren sollen
• Konfiguration
• früher: manuell mit „Jumpern“
oder Dip-Schaltern
• Heute: automatisch („Plug & Play“)
• Gilt ebenso für Interrupts

Quelle: Tanenbaum/Bos
© 2018-21 Jörg Ott | GBS | IN 0009 7
Datenaustausch mit dem Controller (1)
• Programmed I/O
• Interaktion wird von der CPU durchgeführt
• Beispiel: Ausgabe auf Drucker
• Daten werden in den Kern kopiert
• Kern sendet Zeichen für Zeichen
• Zeichen N übergeben
• Auf Abnahmebestätigung für
Zeichen N warten
• Weiter mit Zeichen N+1
• Entspricht Busy waiting
• CPU kann keine anderen
Aufgaben durchführen, bevor
die E/A-Operation
abgeschlossen ist
• Ok für kurze Interaktionen
• Ein/wenige Zeichen lesen
oder schreiben
• Uhrzeit, Gerätekonfiguration Quelle: Tanenbaum/Bos
• Ggf. wenn exaktes Timing wichtig ist
• Sonst besser: Interaktion anstoßen und bei Abschluss benachrichten lassen

© 2018-21 Jörg Ott | GBS | IN 0009 8


Datenaustausch mit dem Controller (2a)
• Interrupts
• Gerät meldet über ein Signal die Beendigung einer E/A-Aktivität
• Interrupt-Controller-Chip erkennt das Signal, informiert die CPU
• BS unterbricht aktuellen Prozess, wechselt in Kernel-Modus
• Führt die Unterbrechungsbehandlungsroutine im Kern aus
• Bestandteil des Geräte-Treibers
• Zuordnung erfolgt über Interrupt-Vektor
• Handler signalisiert Beendigung der Ausführung der Routine
• BS setzt den auf E/A wartenden Prozess auf rechenwillig

Quelle: Tanenbaum/Bos
© 2018-21 Jörg Ott | GBS | IN 0009 9
Datenaustausch mit dem Controller (2b)
• Interrupts: Ablauf
• Aufteilung in zwei Teile
• Synchroner Systemcall mit Übergabe der E/A-Parameter
• Stößt die Bearbeitung an und wartet dann auf deren Abschluss
• Legt sich schlafen und gibt die CPU frei
• Asynchron aufgerufener Interrupt-Handler des Geräts
• Führt den E/A-Vorgang schrittweise fort
• Wenn abgeschlossen: weckt den wartenden Prozess wieder auf

Systemcall Interrupt-Handler

Quelle: Tanenbaum/Bos

• CPU kann andere Aufgaben durchführen, während das Gerät arbeitet


• Aber: potentiell viele Interrupts (aufwendig!)
• CPU kopiert die Daten immer noch selbst
© 2018-21 Jörg Ott | GBS | IN 0009 10
Datenaustausch mit dem Controller (3)
• Direct Memory Access (DMA)
• Problem: Übertragung via Register als Zwischenspeicher kostet viele Zyklen
• Lösung: DMA-Controller: Zugriff auf Speicher unabhängig von CPU
• Ablauf: CPU initiiert DMA
• Programmiert DMA-Register (Speicher- und Gerätadressen, Parameter)
• Disk-Controller muss Daten in Puffer bereitstellen
• DMA-Controller iniiert die Übertragung von Disk in RAM
• Disk-Controller meldet (Ack) Beendigung der Übertragung
• BS kann dann die Daten im Speicher weiterverarbeiten bzw. weitergeben
• Abschluss wird über
Interrupt signalisiert
• Weniger Interrupts
• 1x pro Transfer
statt 1x pro Datum
• CPU muss nicht
selbst kopieren

© 2018-21 Jörg Ott | GBS | IN 0009 Quelle: Tanenbaum/Bos 11


Puffern von Daten
• Entkopplung von Nutzerprogramm und Gerät
• Ohne Puffer
• Puffer im Nutzerprozess muss für E/A im Speicher (eingelagert) sein
• Prozess muss Daten schnell genug abnehmen
• Einfacher Puffer
• Prozess muss Daten schnell genug abnehmen, damit der Puffer wieder frei wird
Schlichter, TU München 8.3. GERÄTEVERWALTUNG
• Doppelter Puffer
• Ein Puffer wird geleert während der andere gefüllt wird
• Leerung muss schnell genug sein
• Zirkulär (Ringpuffer) Prozess Prozess Prozess Prozess
• Verallgemeinerung des doppelten
BS
Puffers auf k Puffer
• Ggf. ohne feste Grenzen
• Kann Last und unterschiedliche
Verarbeitungsgeschwindigkeiten
flexibel abfedern
Gerät Gerät Gerät Gerät

• Ggf. mehrere Stufen von Puffern ohne einfach doppelt zirkulär

• Nutzerprozess, Kern, Gerätetreiber, Gerätecontroller, … Quelle: Schlichter


• Ineffizienz durch wiederholtes Kopieren undPufferung
Falls keine Wartenerfolgt, muss sichergestellt werden, dass der von der E/A
betroffene Teil des virtuellen Adressraums des Prozesses nicht ausgelagert wird,
© 2018-21 Jörg Ott | GBS | IN 0009 12 da der
ansonsten kann es passieren, dass das Gerät die E/A nicht ausführen kann,
benutzerseitige Puffer gerade auf die Festplatte ausgelagert wurde.
Struktur eines E/A-Systems
Schlichter, TU München 8.2. SCHICHTEN EINES E/A-SYSTEMS
1. Controller: Bestandteil der Geräte-Hardware; Schnittstelle zur CPU
2. Interrupt-Handler: Behandlung der Geräte-Rückmeldungen
einheitliches Benennungsschema für die Geräte. Der Name sollte aus einer
3. Gerätetreiber: Ausführung der geräteabhängigen
Zeichenkette oder NummerSteuersoftware;
bestehen, und nicht von der Art des Gerätes
abhängen.
Treiber greift über die Controller auf die Geräte zu
4. Geräteunabhängige Software: belegen
8.2 Schichteneines eines
Geräts, puffern von Daten
E/A-Systems
5. User-Level-Software: Bibliotheksroutinen für E/A, Spooling
Ein E/A-System eines BS ist typischerweise in mehrere Schichten unterteilt:

Benutzerprozess Benutzer Modus

geräteunabhängige BS-Software System Modus

Gerätetreiber
Betriebssystem

Unterbrechungsroutinen

Controller

Hardware
Gerät

Quelle: Tanenbaum/Bos Quelle: Schlichter

© 2018-21 Jörg Ott | GBS | IN 0009 • Unterbrechungsroutinen: Handhabung der Rückmeldungen vom 13 Geräte-
Controller, z.B. nach Beendigung eines Druckauftrags. Die Rückmeldung er-
Geräte-Treiber
• Software-Module
• Gerätetyp-spezifisch
• Kennen den Befehlssatz des zugehörigen Geräts
• Ein Treiber mehrere Geräte einer Klasse
• z.B. USB-Treiber für USB-Geräte

• Interagieren mit der Hardware zur Gerätesteuerung (Controller)


• Gerätezustand abfragen
• Befehle an das Gerät zu übermitteln
• Daten mit dem Gerät auszutauschen
• I. A. Bestandteil des BS-Kerns
• Früher: statisch mit dem Kern verlinkt
• Heute: dynamisch geladen
• Selten: eigenständige Prozesse

• Unterstruktur möglich (z.B. USB)


• Hierarchie von Treibern
• Unten: Austausch von Bits über USB
• Mitte: Gemeinsame Kommandos, größere Dateneinheiten
• Oben: Geräte-spezifische Funktionen (Disk vs. Kamera vs. Tastatur)
© 2018-21 Jörg Ott | GBS | IN 0009 14
Geräte-Treiber (2)

© 2018-21 Jörg Ott | GBS | IN 0009 15


Geräte-Treiber (3)
• Aufgaben von Geräte-Treibern
• definiert das Gerät gegenüber dem BS, aktiviert das Gerät
• initialisiert den Controller und das Gerät beim Systemstart
• wandelt E/A-Anforderungen in gerätespezifische Befehle um
• antwortet auf Hardwaresignale des Geräts bzw. des Controllers
• meldet Geräte- und Controller-Fehler
• überträgt Daten und Zustandsinformation vom/zum Gerät
• puffert Daten bei Ein- und Ausgabe

• Zusammenspiel Treiber und Geräte-Controller


• Treiber schickt Kommandos zum Controller und blockiert sich
• Controller signalisiert das Ende des Datenaustausches
• Der Interrupt-Handler entsperrt den Treiber (z.B. Semaphore)
• Treiber verarbeitet empfangene Daten bzw. schickt weitere Daten

© 2018-21 Jörg Ott | GBS | IN 0009 16


Geräte-unabhängige Software
• Ziele
• Vereinfachte Treiber-Programmierung
• Einfache Einbindung neuer Treiber-Software

• Aufgaben
• Bereitstellung einer einheitlichen Schnittstelle zwischen Gerätetreibern und
dem Rest des Betriebssystems
• Puffern (sofern nicht im Treiber geschehen),
• Fehlerbehandlung (zusätzlich zur Fehlerbehandlung im Treiber)
• Festlegung geräteunabhängiger Parameter
• Z.B. Blockgröße bei Blockgeräten
• Einheitliche Schnittstelle (interface) für Geräte-Treiber
• Geräte unterstützen unterschiedliche Kommandos, Register usw.
• Individuelle Schnittstelle für jedes Gerät
• (a) erfordert individuelle BS-Schnittstelle für jedes Gerät: Aufwand!
• Programmierung im Betriebssystem (skaliert auch nicht bei vielen Geräten)
• einheitliche Schnittstelle, die die Treiber unterstützen müssen
• (b) einfache Einbindung neuer Treiber
• Programmierung im Treiber durch Geräteanbieter

© 2018-21 Jörg Ott | GBS | IN 0009 17


Spezifische vs. Einheitliche Schnittstelle
• Interface
• Menge von Funktionen, z.B. read/write
• Einheitliche Benennung, z.B. Unix: /dev/disk0
• Dateitypen (Block/Character Device) und i-nodes für Geräte
• Pufferung zur Synchronisation

(a) Geräte-spezifische Schnittstellen (b) Einheitlich Schnittstelle


© 2018-21 Jörg Ott | GBS | IN 0009 Quelle: Tanenbaum/Bos 18
8.3 Geräteverwaltung
Eine Hauptaufgabe des BS ist die einheitliche Darstellung der unterschiedlichen
Zusammenspiel Treiber und E/A-System
E/A-Geräte und Treiber.
Zuordnung von logischen Kanälen zu physischen Geräten.

E/A-System xxTreiber

create() xxcreate()
open() xxopen()
Anwendung Controller
close() xxclose()
Gerät
read() xxread()
Logischer write() xxwrite()
Kanal ioctl() xxioctl()

logische
Kanalnummer Treibertabelle

create open close read write ioctl


0
1 xxcreate xxopen xxclose xxread xxwrite xxioctl
2

Quelle: Schlichter

8.3.1 Gerätetreiber
© 2018-21 Jörg Ott | GBS | IN 0009 19
Beispiel: UNIX / Linux
• Zugriff auf E/A-Geräte über Funktionen des Dateisystems
• Vor dem Zugriff auf ein Gerät muss dieses geöffnet werden: open
• Je nach Gerät weitere Dateisystem-Funktionen zur Interaktion
• Verwaltung der Geräte im Dateisystem unter /dev
• Zustandsabfrage und Konfiguration ggf. unter /proc möglich
• Dateiname weist auf den jeweiligen Typ des E/A-Geräts hin
• Verbindlich sind aber die im i-Node vermerkten Gerätekennungen
• Beispiele
• /dev/tty0: physische serielle Schnittstelle
• /dev/USBtty1: abstrakte serielle Schnittstelle
• /dev/sd0: Festplatten (sd steht für SCSI Disk)
• /dev/null: Pseudogerät
• /dev/zero : Pseudogerät

• i-Node einer Geräte-Datei enthält


• Major Device Number: Gerätetreiber
• Minor Device Number: Gerät, auf das zugegriffen werden soll
© 2018-21 Jörg Ott | GBS | IN 0009 20
E/A-Funktionen aus Nutzersicht
• E/A-Programmierschnittstelle
• i.d.R. Teil einer Systembibliothek
• Typische generische E/A-Funktionen sind
• open () Eröffnet einen logischen Kanal zu einem Gerät; liefert
einen Deskriptor (auch Handle) für die weitere Nutzung
• close () Ein vorher geöffneter Kanal wird geschlossen, die
die zugehörige Systemdatenstruktur wird freigegeben
• read () Liest eine Anzahl von Byte (als Bytestrom) vom Gerät ein
• write () Gibt eine Anzahl von Byte an das Gerät aus
• ioctl () Betriebsart des Geräts ändern;
z.B. die Übertragungsrate bei serieller Schnittstelle

• Neben den Standardbibliotheken gehört auch das Spooling-


System zur E/A-Software auf der Nutzer-Ebene

© 2018-21 Jörg Ott | GBS | IN 0009 21


Spooling
• Spooling (Simultanous Peripherial Operations Online)
• Einfache Verwendung exklusiv nutzbarer Geräte (z.B. Drucker)
• Erinnerung: Synchronisation beim Zugriff auf gemeinsame Ressourcen
• Prozesse greifen nichtSpooling
direkt auf das Gerät zu, sondern geben Austräge an
den Spoolerdämon
Spooling ermöglicht die einfache Verwendung exklusiv nutzbarer Geräte im
• Nur Spoolerdämon interagiert direkt mit z.B.
Mehrprogrammbetrieb, dem GerätProzesse
Drucker. über den Gerätetreiber
greifen nicht direkt auf das Gerät
• Aufträge der Benutzerprozesse werden
zu, sondern geben den im Spooling
Auftrag an den Verzeichnis
Spoolerdämon; nur gespeichert
der Spoolerdämon
• Nur für bestimmte Arten von Geräten
interagiert direkt mit geeignet
dem Gerät über den Gerätetreiber.

Benutzerprozesse
• Beispiele: in /var/spool
• lpq: Druckerwarteschlange P1 Systemprozess
• mqueue: interne sendmail-
Funktionsaufrufe E/A-System
Ausgangswarteschlange für Gerät Treiber
• news: für Nachrichten Spooler
Pn
• cron: zu bestimmten Zeiten Dämon
auszuführende Programme
Spooling Controller
Verzeichnis Gerät

Aufträge der Benutzerprozesse werden im Spooling Verzeichnis gespeichert,


© 2018-21 Jörg Ott | GBS | IN 0009 22
bevor sie der Spoolerdämon dann ausführt. Die Koordination der Zugriffe auf die
Zusammenfassung (1)
• Vielschichtiges Zusammenspiel verschiedener Software-
und Hardwarekomponenten beim Zugriff auf Geräte

Quelle: Tanenbaum/Bos

© 2018-21 Jörg Ott | GBS | IN 0009 23


Schlichter, TU München 8.2. SCHICHTEN EINES E/A-SYSTEMS

Zusammenfassung (2)
E/A Request Benutzerprozess E/A Ende, Daten
(read) verfügbar

Systemaufruf
Übertrage Daten in Prozess-
Kann ja BS-Kern Adressraum, melde
Request erledigt
Geräteunabhängige Ergebniscode (Erfolg oder
werden
BS Software Fehlercode)
nein

Send Request zu
BS-Kern
Gerätetreiber
Geräteunabhängige
Blockiere Prozess, falls
BS Software
notwendig

Reserviere Puffer, Bestimme E/A Request,


Sende Kommandos an Gerätetreiber signalisiere E/A-Ende an
Controller BS-Kern

Controller Speichere Daten in Puffer des


Kommandos Gerätetreibers, signalisiere
die Blockierung des Treibers
aufzuheben

Unterbrechung

Steuere Gerät, führe Gerätecontroller


E/A Ende,
Datentransfer durch,
Erzeuge Unterbrechung
unterbreche bei E/A Ende

Quelle: Schlichter
© 2018-21 Jörg Ott | GBS | IN 0009 24
Beispiele für Geräte

© 2018-21 Jörg Ott | GBS | IN 0009 25


Festplatten
• Block-Gerät
• Übereinandergestapelte Platten (k)
• Je beidseitig beschreibbar (2k)
• Konzentrische Zylinder
• Konzentrische Tracks pro Platte
• Track = f (Zylinder, Platte, Seite)
• Sektoren (512 Bytes) pro Track
• Ggf. weniger Sektoren weiter innen
• Mechanische Schreib-/Lesekköpfe (2k)
• Beispieldaten (300 GB-Platte, 10 kRPM)
• Seek time (Nachbarzylinder): 0,7ms
• Seek time (durchschnittlich): 6ms
• Transferzeit pro Sektor: 1,4us

© 2018-21 Jörg Ott | GBS | IN 0009 26


Sektoren auf der Festplatte (1)
• Einfaches Beispiel für unterschiedliche Sektoren pro Track
• Controller führt Abbildung von/nach regelmäßiger Geometrie durch

• Virtuelle Festplattengeometrie
• x Zylinder, y Köpfe, z Sektoren pro Track
• Historische Einschränkung: 16-, 4- und 6-Bit-Felder
• Lösung: lineare Adressierung logischer Blöcke
© 2018-21 Jörg Ott | GBS | IN 0009 27
Sektoren auf der Festplatte (2)
• Ein Sektor Präambel Daten ECC
• Präambel: Synchronisations-Bits, Track- und Sektornummer
• Daten: typischerweise 512 Bytes
• ECC: Error Correcting Code
• +Inter-Sector-Gap
• Cylinder Skew
• Bewegen des Schreib-/Lesekopfes
benötigt Zeit (z.B. 0,7ms)
• Festplatte dreht sich weiter
• 10.000 RPM = 6ms pro Umdrehung
• Bei 300 Sektoren pro Track und
20us pro Sektor: 35 Sektoren
• Für kontinuierliches Lesen von
Sektoren über Zylindergrenzen hinweg
• Formatierung mit Versatz der Sektoren
• Head Skew
• Umschalten des Schreib-/Lesekopfes dauert auch
• Skew aber normalerweise weniger als ein Sektor

© 2018-21 Jörg Ott | GBS | IN 0009 28


Sektoren auf der Festplatte (3)
• Controller lesen oft einen ganzen Track am Stück
• Genügend Speicher zum Puffern erforderlich
• Falls nicht vorhanden: Formatierung mit Interleaving
• Sektoren werden nicht sequentiell angelegt: 1, 2, 3, 4, 5, 6, …, 15
• Sondern verschränkt: 1, 4, 7, 10, 13, 2, 5, 8, 11, 14, 3, 6, 9, 12, 15
• Einen Sektor N lesen, dann Daten an Hauptspeicher übertragen
• Übertragung fertig, bevor Sektor N+1 sich unter den Kopf bewegt

• Redundanzen
• Sektoren können defekt sein
• Low-level-Formatierung sieht Reserven vor
• Reserve-Sektoren ersetzen defekte bei Bedarf
• Abbildung und Umsetzung durch Controller
• Auch das BS kann defekte Sektoren ausblenden
• Wenn die Mechanismen von Controller/Festplatte nicht mehr ausreichen

© 2018-21 Jörg Ott | GBS | IN 0009 29


Sektoren lesen/schreiben
• Seek time vor dem Zugriff
• Bis der Zylinder erreicht ist und der Sektor den Kopf erreicht
• Zugriffe von den Prozessen (via Dateisystem) beliebig
• Erfordern wiederholtes Positionieren des Schreib-/Lesekopfes
• Beispiel
• Aktuelle Position: Zylinder 11
• Anfragefolge: Zylinder 1, 36, 16, 34, 9, 12
• FCFS
• Bewegungen von 10, 35, 20, 18, 25, 3 = 111 Zylinder
• Shortest Seek First (SSF)
• Minimieren der Entfernungen
• Fairness-Problem
• Elevator algorithm (Fahrstuhl-Algorithmus)
• Inspiriert von Aufzugsteuerungen
• Bewegungsrichtung beibehalten bis zum Ende
• Jeweils die nächsten Anfragen auf dem Weg in dieser Richtung abarbeiten
• Insgesamt weniger efficient als SSF: aber fair

© 2018-21 Jörg Ott | GBS | IN 0009 30


Sektoren lesen/schreiben (2)
• Shortest Seek First

• Fahrstuhl-Algorithmus

© 2018-21 Jörg Ott | GBS | IN 0009 31


RAID-Systeme
• RAID: Redundant Array of Inexpensive (Independent) Disks
• Idee
• Erhöhen der Kapazität, Ausfallsicherheit, Lese-/Schreibgeschwindigkeit
• Ansatz: Zusammenfassung von mehreren, kleinen ähnlichen oder
baugleichen Festplatten zu einem großen virtuellen Laufwerk

• Aus Sicht des Betriebssystems


• RAID-System wie eine einzelne Festplatte eingebunden
• Keine Änderung an Anwendungssoftware notwendig
• Festplattencontroller wird durch einen RAID-Controller ersetzt
• Daten werden über die Platten verteilt, parallele Verarbeitung
• Höhere Zuverlässigkeit durch Redundanz

• Unterscheidung zwischen RAID Level 0 bis RAID Level 6

© 2018-21 Jörg Ott | GBS | IN 0009 32


RAID-Systeme (2)
• RAID Level 0
• Aufteilen des Speicherbereichs der virtuellen Festplatte in gleich große
Abschnitte (Strips)
• z.B. 1 Block oder 1 Sektor.
• Verteilung der Strips nach Round-Robin-Strategie auf die physischen
Platten
• Falls ein Datenpuffer mehr als einen Strip umfasst: Verteilung auf
mehrere Platten
• Gut geeignet für große Anfragen für mehrere Strips: Parallelität
• Keine Redundanz: RAID 0, keine Erhöhung der Zuverlässigkeit

Strip 0 Strip 1 Strip 2 Strip 3


Strip 4 Strip 5 Strip 6 Strip 7
Strip 8 Strip 9 Strip 10 Strip 11
Platte 1 Platte 2 Platte 3 Platte 4
© 2018-21 Jörg Ott | GBS | IN 0009 33
RAID-Systeme (3)
• RAID Level 1
• Platten werden verdoppelt, z.B. 2 Backup-Platten (Spiegelplatten)
• Schreiben
• Auf Haupt- und Backup-Platte
• Lesen
• Beide Platten können genutzt werden
• Gute Ausfallsicherheit und paralleles Lesen

Strip 0 Strip 1 Strip 0 Strip 1


Strip 2 Strip 3 Strip 2 Strip 3
Strip 4 Strip 5 Strip 4 Strip 5
Platte 1 Platte 2 Platte 3 Platte 4

• Kombinationen von RAID Level sind möglich


• RAID10 = RAID 0+1: Performanz- und Zuverlässigkeitsgewinn

© 2018-21 Jörg Ott | GBS | IN 0009 34


RAID-Systeme (3)
• RAID Level 2
• Striping erfolgt auf Bitebene mit zusätzlichen Parity-Platten
• z.B. jedes Byte in 4-Bit Paare unterteilt plus 3-Bit Hamming-Code:
Speicherung als 7-bit-Worte
• Erkennen und korrigieren von Bitfehlern.
• Alle Platten müssen synchron arbeiten
• Sehr gute Ausfallsicherheit mit weniger Platten als bei RAID Level 1

Bit 0 Bit 1 Bit 2 Bit 3 Parity 0 Parity 1 Parity 2


Bit 4 Bit 5 Bit 6 Bit 7 Parity 0 Parity 1 Parity 2

Platte 1 Platte 2 Platte 3 Platte 4 Platte 5 Platte 6 Platte 7

Daten-Bits Parity-Bits

(Effektive Bitfolge: P0 – P1 – B0 – P1 – B1 – B2 – B3 – B4)


© 2018-21 Jörg Ott | GBS | IN 0009 35
RAID-Systeme (4)
• RAID Level 3
• Wie Level 2, aber nur ein Parity Bit
• Striping erfolgt auf Bitebene mit einer zusätzlichen Parity-Platte
• Erkennen und korrigieren von einzelnen Bitfehlern
• Wenn die Position bekannt ist, also etwa eine Platte ausfällt
• Alle Platten müssen nachwievor synchron arbeiten

Bit 0 Bit 1 Bit 2 Bit 3 Parity Parity = XOR (B0, …, B3)

Bit 4 Bit 5 Bit 6 Bit 7 Parity Parity = XOR (B4, …, B7)

Platte 1 Platte 2 Platte 3 Platte 4 Platte 5

Daten-Bits Parity-Bit

© 2018-21 Jörg Ott | GBS | IN 0009 36


RAID-Systeme (5)
• RAID Level 4
• Wie Level 3, aber jetzt mit Strips statt Bits als Dateneinheit
• Striping erfolgt auf Strips mit einer zusätzlichen Parity-Platte
• Erkennen und korrigieren von fehlerhaften Strips
• Platten müssen nicht mehr synchron arbeiten

Strip 0 Strip 1 Strip 2 Strip 3 P0-3 Parity = XOR (S0, …, S3)

Strip 4 Strip 5 Strip 6 Strip 7 P4-7 Parity = XOR (S4, …, S7)

Strip 8 Strip 9 Strip 10 Strip 11 P8-11


Platte 1 Platte 2 Platte 3 Platte 4 Platte 5

Daten-Strips Parity-Strips

© 2018-21 Jörg Ott | GBS | IN 0009 37


RAID-Systeme (6)
• RAID Level 5
• Wie Level 4, aber Verteilen der Parity-Strips über alle Festplatten
• Beim Schreiben eines Strips muss jeweils auch der Parity-Strip gelesen,
Parity neu berechnet und dann beiden Strips geschrieben werden
• Vermeidet starke Belastung der Parity-Platte
• Diese konnte vorher zum Flaschenhals des Systems werden
• War ggf. stärkerer Abnutzung ausgesetzt

Strip 0 Strip 1 Strip 2 Strip 3 P0-3


Strip 4 Strip 5 Strip 6 P4-7 Strip 7
Strip 8 Strip 9 P8-11 Strip 10 Strip 11
Strip 12 P12-15 Strip 13 Strip 14 Strip 15
P16-19 Strip 16 Strip 17 Strip 18 Strip 19
Platte 1 Platte 2 Platte 3 Platte 4 Platte 5

• RAID Level 6: wie Level 5 aber mit 2 Parity-Strips


© 2018-21 Jörg Ott | GBS | IN 0009 38
RAID-Zusammenfassung

Quellen: https://commons.wikimedia.org/wiki/File:RAID_3.svg
https://commons.wikimedia.org/wiki/File:RAID_0.svg https://commons.wikimedia.org/wiki/File:RAID_4.svg
https://commons.wikimedia.org/wiki/File:RAID_1.svg https://commons.wikimedia.org/wiki/File:RAID_5.svg
https://commons.wikimedia.org/wiki/File:RAID2_arch.svg https://commons.wikimedia.org/wiki/File:RAID_6.svg
© 2018-21 Jörg Ott | GBS | IN 0009 39
Uhr, Timer
• Taktgeber für die Hardware
• Verschiedene Aufgaben für das Betriebssystem

• Hardware-Uhr (Chip)
• Quarz als Taktgeber
• Zähler, wird bei jedem Takt dekrementiert
• Generiert einen Interrupt, wenn 0
• Register zum (wiederholten) Setzen
des Zählers auf einen Startwert Kristalloszillator (Quarz)
• Steuerung der Interrupt-Frequenz via S/W
• (Uhr im System mit Batteriepufferung)
• Uhrzeit auch bei abgeschaltetem
System aktualisieren Zähler
• Setzen der Uhrzeit durch Kommandos
• Achtung: Zeitzone, Sommerzeit usw.
Holding-
• Automatisches Aktualisierung durch NTP
Register
(Network Time Protocol) o.ä.

© 2018-21 Jörg Ott | GBS | IN 0009 40


Uhr / Timer (2)
• Aufgaben im Betriebssystem
• Tageszeit und Datum verwalten
• Prozesse unterbrechen und umschalten (Scheduling)
• Rechenzeitverbrauch eines Prozesses messen
• Zeitschaltuhren den Anwendungen zur Verfügung stellen
• Funktionsfähigkeitsüberwachung (watchdog timer)
• Profiling, Monitoring, Statistik
• Viele Aufgaben für eine (oder wenige) Uhren
• Interne Verwaltung der Timeouts durch das Betriebssystem
• Z.B. verkettete Liste sortiert nach Eintrittszeitpunkt
• mit relativen Zeiten (in Ticks)

© 2018-21 Jörg Ott | GBS | IN 0009 41


Uhr / Timer (3)
• Timer für Programme
• Hardware-Timer
• Systeme haben often eine zweite frei programmierbare Uhr
• Generiert Interrupt, wenn der Timer abgelaufen ist
• Aber: Interrupts sind oft teuer
• Kontext-Wechsel, User-Kernel-User-Mode
• Zu viele können Ablauf der Programm stören bzw. verlangsamen
• Soft-Timer (Software-basierte Time)
• Idee: nur dann aktiv werden, wenn System im Kernel-Mode ist
• kein extra Kontext-Wechsel erforderlich
• Vor dem Wechsel in User-Mode: BS fragt die Echtzeituhr ab
• Überprüfen, ob ein Soft-Timer abgelaufen ist
• Ggf. Behandlung des entsprechenden Events
• Messungen zeigen, dass User-Kernel-Übergang oft genug stattfindet
• 2 – 18 usec auf verschiedenen Systemen
• Z.B. Systemcalls, Seitenfehler, I/O-Interrupts, CPU im Leerlauf, ...
• Ausreichend für eine Granularität von O(10us)
• Bei gelegentlicher leichter Verpätung
• Akzeptabel für viele Anwendungen
• Ggf. absichern durch HW-Timeout jede 1ms
© 2018-21 Jörg Ott | GBS | IN 0009 42
Nutzereingaben
• Maus, Trackball, Trackpad, Stick, …
• Bewegungen erfasst durch Sensoren (heute meist Photodioden)
• Relative Bewegungen pro Zeiteinheit
• Tasten (betätigen, loslassen)
• Scrollräder
• Microcontroller transformiert Eingaben in Bit-/Bytestrom
• Z.B. USB, Funk (z.B. Bluetooth), RS-232, RS-4xx
• Tastatur
• Erfasst das Drücken und Loslassen von einzelnen Tasten
• Scan-Codes: z.B. 7 Bit für die Taste und 1 Bit für drücken vs. loslassen
• Microcontroller transformiert Eingaben in Bit-/Bytestrom
• Z.B. USB, Funk, RS-232, RS-4xx
• Low-level-Treiber wandelt diese Sequenzen dann in Zeichen um
• Realisiert Zusatzfunktionen: Caps-Lock, Zeichenwiederholung
• Beispiele

© 2018-21 Jörg Ott | GBS | IN 0009 43


Terminals (1)
• Text-basierte Interaktion des Nutzers (via Shell)
• Früher: Teletypewriter, Hardware-Terminals, …
• Heute: Console, xterm, SSH-Clients, …

• Interaktion über verschiedene Hardware-Schnittstellen


• Historisch: Serielle Leitungen
• Tastatur/Maus (über USB, Bluetooth) und Grafikkarte
• Entfernter Zugriff über SSH (TCP/IP)
•…

• Treiberhierarchie
• Dynamische Komposition von mehreren Treibern
• Oben: Einheitliche Schnittstelle zum E/A-Subsystem des BS
• Mitte: Bearbeitungsmodul für Ein- und Ausgaben
• Unten: Abbildung verschiedene physische Geräte

© 2018-21 Jörg Ott | GBS | IN 0009 44


Terminals (2)
• Treiberhierarchie

Prozess Prozess

/dev/tty

LDISC 1 Line discipline LDISC 2

Gerätetreiber 1 Gerätetreiber 2 Gerätetreiber 3

• Character Device (/dev/tty – Controlling Terminal eines Prozesses)


• Einheitliche Schnittstelle, Pufferung
• Sitzungssteuerung (Job Control)
• Multiplexen eines Terminals zwischen mehreren Prozessen
• Vorder- und Hintergrundprozesse

© 2018-21 Jörg Ott | GBS | IN 0009 45


Terminals (3)
• Line Discipline
• Cooked Mode (Canonical Mode): zeilenorientiert
• Optionale Vorverarbeitung von Eingaben
• Beispiel: fgets (buffer, len, stdin)

• Echo, Editieren (Backspace) usw.

• Raw Mode (Noncanonical Mode): zeichenorientiert


• Keine Vorverarbeitung: Prozess erhält die Zeichen ungefiltert
• Sobald eine bestimmte Anzahl von Zeichen gesammelt wurde oder nach Timeout
© 2018-21 Jörg Ott | GBS | IN 0009 46
Text-Fenster (Terminal)
• Einfach für einfache Ausgaben
• Zeichen für Zeichen, Zeile für Zeile
• Besonderheit
• Repräsentation von Zeilenende: CR vs LF vs CRLF
• Wraparound am Zeilenende, Scrolling (Bildschirmdimensionen)
• Komplexere Ausgaben (z.B. Line-Editing, Text-Editoren)
• Cursor muss positioniert warden ➜ Steuerkommandos
• “Escape-Sequenzen” – weil sie mit ESC (ASCII 27, 0x1b) beginnen
• Backspace
• ESC [ 1 D _ ESC [ 1 D
• Color
• ESC [ <n> m
• FG: n=30-37, 90-97
• ESC [ 38 …
• BG: n=40-47, 100-107
• ESC [ 38 …
• 8-bit: ESC [ 38;5;(c) m
• 24-bit: ESC [38;2;(r);(g);(b) m

© 2018-21 Jörg Ott | GBS | IN 0009 https://en.wikipedia.org/wiki/ANSI_escape_code 47


Pseudo Terminals
• Realisierung von Remote Login

© 2018-21 Jörg Ott | GBS | IN 0009 48


Network Interface Card (NIC)

© 2018-21 Jörg Ott | GBS | IN 0009 49


Weitere Geräte
• CPU-/Power-Management

• Akku-Informationen

© 2018-21 Jörg Ott | GBS | IN 0009 50


Chair of Connected Mobility
Department of Informatics
Technische Universität München

Kapitel 09

Grundlagen Betriebssysteme und Systemsoftware


Virtualisierung

Prof. Dr.-Ing. Jörg Ott


Lehrstuhl Connected Mobility

Folien frei nach der Vorlage von Prof. C. Eckert (WS16/17, WS17/18) – danke!

© 2018-21 Jörg Ott | GBS | IN 0009 1


Übersicht
• Abstraktionsebenen

• Anforderungen an Virtualisierung

• System Virtual Machines


• Type 1 Hypervisors vs. Type 2 Hypervisors
• Full virtualization vs. Paravirtualization
• CPU-Virtualisierung
• Speicher-Virtualisierung
• I/O-Virtualisierung

• Process Virtual Machines


• Container

• Beispiele
© 2018-21 Jörg Ott | GBS | IN 0009 2
Fragen…
• Warum überhaupt (noch mehr) Virtualisierung?

• Was passiert in einem Data Center (= Cloud-Infrastruktur)?


• Z.B. Platform as a Service (PaaS), Infrastructure as a Service (IaaS)

• Was muss alles virtualisiert werden? Und wie?

• Was tut VirtualBox?

• Wie funktioniert Docker?

© 2018-21 Jörg Ott | GBS | IN 0009 3


Einführung
• Abstraktionen, Abstraktionsschichten
• Komplexe Systeme können durch Abstraktionsschichten besser
beschrieben werden.
• Für eine Schicht irrelevante Funktionalität wird abstrahiert
• Abstraktionen erlauben dem Betrachter sich auf relevante Bereiche zu
konzentrieren
• Abstraktionsschichten durch Schnittstellen (Interfaces) voneinander
getrennt
• Details der Realisierung der unteren Schichten dadurch verborgen (Black Box)

• Beispiel: Systemcalls
• Systemcalls können als Abstraktion ihrer Low-level-Implementierung
innerhalb des BS-Kerns angesehen werden
• Implementierungsdetails durch das System Call Interface verborgen

• Hardware-Details können durch Interfaces abstrahiert werden


• Das Interface definiert die Software-Sicht auf die Hardware
• Siehe (Hierarchien von) Treiber(n)
➜Hardware-Funktionalität kann durch Software simuliert/emuliert werden

© 2018-21 Jörg Ott | GBS | IN 0009 4


Einführung (2)
• Die Sicht auf ein Hardware-System wird durch unterschiedliche
Schnittstellen definiert
• Instruction Set Architecture (ISA): Interface zwischen dem BS und Hardware
• Die ISA besteht aus User- und System-ISA
• Application Binary Interface (ABI): Interface zwischen Anwendungen und dem
Betriebssystem
• Das ABI besteht aus dem System Call Interface und der User ISA
➜ Die Sicht auf das System hängt von der Software-Perspektive ab

Applications Applications
Syscall Interface
ABI
OS
System ISA User ISA User ISA
ISA

Machine Machine

System definiert durch das ISA-Interface System definiert durch das ABI-Interface
Quelle: Jim Smith, Virtual Machines: Versatile Platforms for Systems and Processes
© 2018-21 Jörg Ott | GBS | IN 0009 5
Einführung (3)
• Virtuelle Laufzeitumgebung
• Ein Hardware-System (physische Maschine) bietet eine
Laufzeitumgebung für die darüberliegende Software
• BS virtualisiert bereits: Prozesse, virtueller Speicher und Abstraktionen
• Eine Virtuelle Maschine implementiert eine virtuelle Laufzeitumgebung
• Abbilden von virtuellen auf physische Ressourcen
• CPU-Zustand, Hardwaregeräte, etc.
• Emulieren der virtuellen ABI bzw. ISA

• Altbekannte Konzepte seit rund 20 Jahren neu entdeckt


• Ursprünge in der 1960er Jahren (IBM)
• VMware seit Ende der 1990er Jahre für x86
• Abhängig davon, welche Sicht auf das System die
Laufzeitumgebung implementiert, unterscheidet man
• System Virtual Machines
• Process Virtual Machines
© 2018-21 Jörg Ott | GBS | IN 0009 6
Anforderungen an Virtualisierung
• Equivalence / Fidelity
• Betriebssysteme und Anwendungen funktionieren ohne Änderungen
• Ggf. minimale Änderungen / Ergänzungen am Gast-BS
• Verhalten sich genauso wie auf einem nativen System

• Resource Control / Safety (Isolation)


• Hypervisor muss in Kontrolle sein
• Hypervisor schützt Ressourcen vor und Gast-BS gegeneinander

• Efficiency / Performance
• Die meisten Instruktionen müssen ohne Intervention des Virtualisierungs-
systems ausgeführt werden
• Virtualisierungssystem fügt eine weitere Software-Schicht hinzu (Overhead)
• Wie auch ein BS versucht das Virtualisierungssystem den Overhead zu minimieren
• Beispiele für VMware (nach Alex Snoeren, CSE 120, Lecture 17)
• CPU-intensive Anwendungen: 2-10% Overhead
• I/O-intensive Anwendungen: 25-60% Overhead

Nach: Popek, G. J.; Goldberg, R. P. (July 1974). "Formal requirements for virtualizable third generation architectures".
Communications of the ACM. 17 (7): 412–421. doi:10.1145/361011.361073
© 2018-21 Jörg Ott | GBS | IN 0009 7
System Virtual Machines
• Virtual Machine Monitor (VMM) – Hypervisor – bietet eine
Laufzeitumgebung für Betriebssysteme
• Typ 1 Hypervisor: Direkt auf der Hardware ausgeführt
• z.B. Xen, Hyper-V, VMware ESX
• Typ 2 Hypervisor: Verwendet Dienste des Host-BS
• z.B. KVM, VirtualBox, VMware Workstation

Guest Applications
Syscall Interface

Guest Applications Guest OS


Syscall Interface System ISA User ISA
Source
ISA
Guest OS
System ISA User ISA VMM
Source
ISA

VMM OS
Target Target
ISA ISA

Hardware Hardware

Native System VM (Typ 1) Hosted System VM (Typ 2)

© 2018-21 Jörg Ott | GBS | IN 0009 8


System Virtual Machines
• Der Hypervisor implementiert eine virtuelle ISA
• Virtuelle (Source) ISA besteht aus der User- und System-ISA
• Source ISA kann (muss aber nicht) der Target-ISA des Systems entsprechen
• Aus der Sicht des Gast-Betriebssystems wird das “System” durch die
Hardware unterhalb der ISA-Schnittstelle charakterisiert
• VMM virtualisiert die gesamte physische Maschine
• Schnittstelle ist die (virtualisierte) Hardware
• Gast-BS arbeitet auf dieser
• Illusion, dass das Gast-BS vollständige Kontrolle über die HW hat
• VMM behält natürlich die Kontrolle
• Gast-BS ist “Anwendung” aus Sicht des VMM

• Implikationen
• Eine VM kann ein beliebiges BS ausführen
• Mehrere Instanzen des gleichen/verschiedener BS können gleichzeitig laufen
• Praktischer Nutzen siehe Linux-VM in VirtualBox

© 2018-21 Jörg Ott | GBS | IN 0009 9


Gründe für System-VMs
• Emulation
• Betriebssysteme können auf verschiedenen ISAs ausgeführt werden
• Debuggen von BS in Virtuellen Maschinen ist oft bequemer als auf der echten
Hardware („Bare-Metal“)
• ISA-Design: eine ISA ist einfacher in SW zu implementieren als in HW
• Isolation
• Verschiedene BS laufen isoliert in einer VM auf der gleichen HW
• Sandboxing von Gast-Betriebssystemen
• Ein kompromittiertes Gast-BS kann weder den Zustand weiterer VMs auf dem
System noch den Hypervisor selbst manipulieren
• Sicherheit
• Security-Mechanismen im BS können durch Malware umgangen oder
ausgeschaltet werden
• Hypervisor ist leichter zu sichern (kleiner, höhere Privilegien)
• Sicherheitsmechanismen für Gast-BS können im Hypervisor plaziert werden
• Ressourcennutzung
• Hardware-Ressourcen können besser (flexibler) ausgeschöpft werden
© 2018-21 Jörg Ott | GBS | IN 0009 10
Herausforderungen
• Der Hypervisor kontrolliert und virtualisiert Hardware
Ressourcen des Systems
• CPU-Virtualisierung
• Speicher-Virtualisierung
• I/O-Virtualisierung

• Ressourcen werden gemultiplext und unter allen VMs


aufgeteilt
• Jede Gast VM erhält virtuelle Hardware-Ressourcen
• Der Gast darf nicht in der Lage sein, auf andere als die ihm zugeteilten
Ressourcen zuzugreifen
• Der Hypervisor vermittelt dem Gast-BS die Illusion, alleine auf dem
System ausgeführt zu werden

© 2018-21 Jörg Ott | GBS | IN 0009 11


CPU-Virtualisierung
• Paravirtualization
• Modifiziertes Betriebssystem in VM; BS ist bewusst, dass es virtualisiert wird
• Dedizierte Geräte Treiber kommunizieren mit dem Hypervisor durch sog.
Hypercalls
• Kooperation zwischen dem BS in der Gast VM und dem Hypervisor

• Binary Translation
• Unmodifiziertes BS kann ausgeführt werden
• Ggf. auf verschiedenen Architekturen
• Hypervisor interpretiert/emuliert (Teile des) Binärcode(s) der Gast-VM in
Software: Performance-Overhead
• Reduziert durch Caching, Beschränkung auf Code vom Gast-BS
• Ggf. effizienter als Traps
• Hohe Komplexität im Hypervisor

• Hardware-assisted Virtualization
• Hardware-unterstützte Virtualisierung von unmodifizierten Betriebssystemen
• Hardware Virtualization Extensions: Intel VT-x, AMD-v, ARM
• Ermöglichen das Implementieren von effizienten VMs
© 2018-21 Jörg Ott | GBS | IN 0009 12
CPU-Virtualisierung (2)
• System und User Mode
• Man unterscheidet zwischen dem hochprivilegierten System Mode und dem
User Mode
• Nicht zu verwechseln mit Kernel Space und User Space des BS
• Der Hypervisor wird im System Mode ausgeführt (z.B. Intel VMX root)
• Gast-Betriebssystem wird im User Mode ausgeführt (z.B. Intel VMX non-root)
• Bestimmte Instruktionen, die im User Mode ausgeführt werden, werden
vom Hypervisor im System Mode abgefangen
• Hypervisor behält somit die Kontrolle über die VM

Quelle: Tanenbaum/Bos
© 2018-21 Jörg Ott | GBS | IN 0009 13
CPU-Virtualisierung (3)
• Instruktionsklassen
• Unterteilung der Instruktionen einer ISA in 3 Klassen (Popek & Goldberg)
• Privileged Instructions
• Können nur im System-Mode ausgeführt werden
• Werden im System-Mode abgefangen, wenn sie im User-Mode ausgeführt
werden: Trap
• Sensitive Instructions
• Control-Sensitive Instructions
• Modifizieren die System-Konfiguration (z.B. Page Tables)
• Behaviour-Sensitive Instructions
• Verhalten sich anders, wenn sie im User-Mode ausgeführt werden
• Innocuous Instructions
• Nicht priviligierte oder sensitive Instruktionen (alle anderen)
• Für Virtualisierung müssen sensitive Instruktionen eine strikte
Untermenge der privilegierten Instruktionen sein
• Gegenbeispiel bei x86: POPF (Flags-Register vom Stack in die CPU laden)
• Flags umfassen das Interrupt-Bit (enable/disable): wird im User-Mode nicht modifiziert
© 2018-21 Jörg Ott | GBS | IN 0009 14
CPU-Virtualisierung (4)
• Virtualisierungsechnologien (VT) in CPUs seit 2005
• (AMD Secure Virtual Machine, SVM) – IBMs seit den 1960ern
• Gast-BS läuft in einem “Container” (≠ Docker, dazu später mehr)
• Hypervisor definiert eine Bitmap mit nicht zugelassenen Instruktionen
• Jede dieser Instruktionen führt zu einem Trap
• Trap-and-Emulate wird möglich
• Hypervisor inspiziert die Instruktion und führt dann die entsprechenden
Schritte (nach vorheriger Prüfung durch)

• Und vorher? (VMware ist aus den 1990ern)


• Dynamisches Umschreiben von Instruktionen (on-the-fly)
• Ersetzen von privilegierten/sensitiven Instruktionen im Binärcode durch
Traps
• Normalerweise auf das Gast-BS beschränkt (keine Anwendungen)
• Die meisten Instruktionen müssen nicht angepasst werden
• Prüfung der Operationen und dann Emulation
• Binary Translation
© 2018-21 Jörg Ott | GBS | IN 0009 15
Speicher-Virtualisierung
• Betriebssystem hat normalerweise uneingeschränkte
Kontrolle über den physischen Speicher
• Verwalten virtuellen Speicher für Prozesse
• Seitentabellen zur Abbildung auf den physischen Speicher

• Durch Virtualisierung konkurrieren plötzlich mehrere BS


• Hypervisor ist die übergeordnete Instanz

© 2018-21 Jörg Ott | GBS | IN 0009 16


Beispiel

© 2018-21 Jörg Ott | GBS | IN 0009 17


Speicher-Virtualisierung
• Betriebssystem hat normalerweise uneingeschränkte
Kontrolle über den physischen Speicher
• Verwalten virtuellen Speicher für Prozesse
• Seitentabellen zur Abbildung auf den physischen Speicher
• Durch Virtualisierung konkurrieren plötzlich mehrere BS
• Hypervisor ist die übergeordnete Instanz
• Hypervisor teilt den physischen Speicher zwischen VMs auf
• BS darf nicht auf beliebige Seiten im physischen Speicher zugreifen
• BS soll nur den Speicher “sehen”, den der Hypervisor zur Verfügung
gestellt hat
• Hypervisor muss den Zugriff des BS auf Seitentabelle überwachen
• Verschiedene Virtualisierungsansätze
• Shadow Page Tables (SPT)
• Hardware-unterstützte Second Level Address Translation (SLAT)

© 2018-21 Jörg Ott | GBS | IN 0009 18


Shadow Page Tables (SPT)
• Drei Abstraktionsebenen für Speicher
• Physischer Speicher im System (Host-Physische Adressen, HPA)
• z.B. 32 GB
• Abstraktion des physischen Speichers durch den Hypervisor
• Gast-Physische Adressen: Der Speicher, den ein Gast-BS sieht
• z.B. 8 GB kontinuierlicher Speicher
• (nicht unbedingt kontinuierlich im physischen Speicher)
• Virtueller Speicher: wie zuvor für Prozesse besprochen
• 4 GB Standardadressbereich
• Das Gast-Betriebssystem verwaltet eigene Seitentabellen (Gast-PT)
• Diese Gast-Seitentabellen werden nicht von der MMU verwendet
• Hypervisor verwaltet eine Shadow Page Table pro Prozess
• SPT bildet virtuelle Adressen der Gast-VM auf physische Adressen ab
• Änderungen in der Gast-PT müssen mit SPT synchronisiert werden
• Der Hypervisor gewährt der Gast VM Nur-Lese-Zugriff auf die Page Tables (read-only)
• Jeder Schreibversuch wird vom Hypervisor abgefangen ➜ Trap!
• Änderungen werden sowohl in der Gast-PT als auch in der SPT übernommen
➜ Problem: Sehr komplexe Verwaltung in Software und hoher Overhead

© 2018-21 Jörg Ott | GBS | IN 0009 19


Shadow Page Tables (2)
• Beispiel

© 2018-21 Jörg Ott | GBS | IN 0009 20


Second Level Address Translation (SLAT)
• Hardwareunterstützung in der CPU
• Zweite Stufe der Adressabbildung über SLAT-Tabellen
• Bildet Gast-Physische-Adressen (GPA) auf Host-Physische-Adressen (HPA) ab
• Hypervisor fängt Zugriffe auf Speicherbereiche ab, die nicht in den SLAT-
Tabellen abgebildet sind
• Beispiele: Intel Extended Page Tables (EPT), AMD Nested Page Tables (NPT)

© 2018-21 Jörg Ott | GBS | IN 0009 21


Second Level Address Translation (2)
• Abbildung im Detail

© 2018-21 Jörg Ott | GBS | IN 0009 22


Speicherverwaltung für VMs
• Wieviel Speicher soll eine VM bekommen?
• Gleiche Fragestellung wie für Prozesse
• Statische Allokation
• Inflexibel, bindet Ressourcen
• Dynamische Allokation
• Gleiches (optimistisches) Prinzip: Overcommitment
• Annahme: nicht alle VMs benötigen gleichzeitig ihren gesamten Speicher
• Einfach: Speicher bei Bedarf zuweisen
• Schwierig: Speicher wieder wegnehmen, wenn nicht mehr benötigt
• Paging? – Hypervisor weiß nicht, welche Seiten wichtig/unwichtig sind
• Lösung: Ballooning (“balloon driver”)
• Software-Komponente innerhalb der Gast-VM kommuniziert mit Hypervisor
• Alloziert Seiten (Ballon bläht sich auf), wenn der Hypervisor Speicher braucht
• Gibt Seiten frei (Ballon schrumpft), wenn der Hypervisor Speicher zur Verfügung hat
• Gast-BS trifft die Entscheidungen über Ein-/Auslagerungen
• Orthogonal: Seiten VM-übergreifend nutzen
• “Deduplication” – Identische Seiten erkennen ➜ teilen + copy-on-write
© 2018-21 Jörg Ott | GBS | IN 0009 23
I/O-Virtualisierung
• Ziele
• I/O-Geräte allen VMs/Gast-BS zur Verfügung stellen
• Zugriff auf I/O-Geräte entweder durch SW oder HW gemultiplext
• Verhindern, dass Gast-VMs die Kontrolle über I/O-Geräte übernehmen
I/O-Virtualisierungstechniken
• Full Virtualization/Emulation
• Hypervisor multiplext oder emuliert virtuelle I/O-Geräte in Software
• Gast-I/O-Anfragen vom Hypervisor abgefangen und an das I/O-Gerät
geleitet
• Vorteile
• Gemultiplexte I/O-Geräte sind effizient
• Transparentes Geräte-Management
• Probleme
• Hohe Komplexität in Software
• Hypervisor benötigt Treiber für viele I/O-Geräte
• Falls Geräte emuliert werden müssen, so entsteht ein hoher Overhead
© 2018-21 Jörg Ott | GBS | IN 0009 24
I/O-Virtualisierung (2)
• Full Virtualization / Emulation
• Praktische Beispiele
• Virtuelle Ethernet-Schnittstelle pro VM
• Eigene Adressen, volle Kontrolle durch die VM
• Ethernet-Switch im Hypervisor zum Verbinden aller VMs mit der Außenwelt
• Emulation von Festplatten, CD/DVD-Laufwerken in der VM
• Abbildung auf Dateien im Host-BS

• Paravirtualization
• Verwendet eine Split-Driver-Architektur
• Backend-Treiber: Dedizierte privilegierte VM greift direkt auf Geräte zu
• Frontend-Treiber in Gast-VMs kommuniziert mit dem Backend-Treiber
• Vorteile
• Geringer Overhead
• Im Vergleich zu Full Virtualization leichter zu implementieren
• Adaption für Gast-BS: z.B. neue Geräte mittels bestehender Treiber anbieten
• Probleme
• Benötigt Modifikationen/Treiber im Gast-Betriebssystem

© 2018-21 Jörg Ott | GBS | IN 0009 25


I/O-Virtualisierung (3)
• Direct I/O
• Hardware-unterstütztes Multiplexing von I/O Geräten
• Dedizierte I/O-MMU verwaltet Geräte-Speicher in Gast VMs
• Bildet I/O-Adressen, Interrupts usw. ab
• Isoliert DMA-Zugriffe
• Beispiele: Intel VT-d, Intel VT-c , AMD IOMMU , ARM System MMU
• Vorteile
• Gast-VMs greifen direkt auf die Hardware zu: Effizient
• Hardware übernimmt Teile des Multiplexings: Leicht zu implementieren

• Device Domains
• Eine VM dient als Schnittstelle zu allen Geräten (Domain 0 bzw. “dom0” bei Xen)
• Andere VMs greifen über diese VM zu
• In Kombination mit Paravirtualisierung: semantische Kommandos (lese Block
1507) statt Sequenzen von Registerkommandos
• Singe Root I/O Virtualization (SR-IOV)
• Direktes Zuweisen von Hardware zu einer VM skaliert nicht
• Hypervisor beim I/O-Zugriff umgehen
• Geräte unterstützen Virtualisierung direkt
• Erscheinen als mehrere Instanzen
• Jede steht einem Gast-BS exklusiv zur Verfügung
• Physical Funtions (PF) für den Hypervisor (voller Zugriff)
• Virtual Functions (VF) für die Gast-VMs (eingeschränkter Zugriff)

© 2018-21 Jörg Ott | GBS | IN 0009 26


Process Virtual Machines
• Ansatz
• Runtime implementiert eine virtuelle Laufzeitumgebung für User-Space-Prozesse
• Die Runtime implementiert das ABI-Interface bestehend aus dem Systemcall-Interface
und der User-ISA (Plattform)
• Aus der Applikationssicht wird das “System” durch das ABI-Interface charakterisiert

Guest Application
Syscall Interface User ISA
Source
ABI

Runtime
Target
ABI

OS

Hardware

• Gründe für Process VMs


• Emulation: Programme können auf verschiedenen ISAs ausgeführt werden
• Plattform-Unabhängigkeit: Programme können auf verschiedenen BS ausgeführt werden
• Performance-Optimierung: Binary Optimizer optimieren den Code während der Laufzeit
© 2018-21 Jörg Ott | GBS | IN 0009 27
Process Virtual Machines (2)
• Virtuelle Umgebungen für einen (oder mehrere) Prozesse
• Anwendungen auf verschiedenen Plattformen ausführen
• Beispiel: Intel IA-32 Execution Layer (IA-32 EL) erlaubt es, x86-32-Bit-
Anwendungen auf 64-bit-Itanium auszuführen

• High-Level-Language (HLL) VMs


• HLL VMs definieren eine Plattform-unabhängige virtuelle ISA
• Verhindert Abhängigkeiten zum BS und zur Hardware-Architektur
• Beispiel: Java Virtual Machine (JVM) interpretiert Java-Bytecode

• Und mehrere (interagierende) Prozesse?


• OS-level Virtualization: Container

© 2018-21 Jörg Ott | GBS | IN 0009 28


OS-level-Virtualization
• Container
• Leichtgewichtige Virtualisierungsmöglichkeit
• Container stellen eine Laufzeitumgebung für User-Space-Prozesse bereit
• Prinzipiell beliebig viele Prozesse
• Verwenden Services des BS-Kerns
• Container verwenden somit dieselbe ISA wie der Host
• Der BS-Kern wird zwischen dem Host und Gast geteilt
• D.h. BS wird nicht virtualisiert
• Beispiele Solaris Zones, FreeBSD Jails, Linux Containers (LXC), Docker, rkt

Guest Guest …
Guest
App App App

Container
OS
Hardware
• Probleme?

© 2018-21 Jörg Ott | GBS | IN 0009 29


Container
• Isolation von Prozessen
oder Prozessgruppen
• Kontrolle (einschränken)
der verfügbaren Ressourcen
• Illusion, die Ressourcen
exklusiv zu nutzen

Anw. Anw. Anw. Anw.


OS
Hardware

© 2018-21 Jörg Ott | GBS | IN 0009 30


Minimale OS-Virtualisierung?
• chroot
• Verändern des Root-Verzeichnisses
• Einschränkung des Zugriffs auf das Dateisystem
• Begrenzte Isolation (nicht sicher)

© 2018-21 Jörg Ott | GBS | IN 0009 31


Container (2)
• Bestandteile von Containern unter Linux:
• Linux Namespaces
• https://lwn.net/Articles/531114/
• Linux Control Groups (Cgroups)
• https://lwn.net/Articles/604609/
• Secure Computing Mode (Seccomp)
• https://lwn.net/Articles/656307/

• Weitere Copy-on-Write Filesystem-Features (nicht behandelt)


• Erlauben “sehr schnelle” Erstellung von Containern

© 2018-21 Jörg Ott | GBS | IN 0009 32


Linux Namespaces
• Namensräume zur Benennung und Adressierung von
Ressourcen

• In traditionellen (Unix-basierten) Systemen werden einige


Ressourcen global verwaltet
• Eindeutige PIDs pro Prozess
• Eindeutige User IDs
• Host- und NIS-Domainnamen, IP-Adressen, ...
• Werden vom Kernel in einer globalen Liste verwaltet
• User Prozesse können sich gegenseitig “sehen”
➜ Problem: Ein Prozess mit root-Privilegien, kann andere Prozesse
beeinflussen
• Wie kann ein Cloud-Provider Kunden vollen Zugriff auf ein
System geben?
• Ohne dabei andere Sicherheitsrisiken für andere Kunden zu schaffen?
© 2018-21 Jörg Ott | GBS | IN 0009 33
Linux Namespaces (2)
• Namespaces bilden die Grundlage für Container
(leichtgewichtige Virtualisierung)
• Namespaces abstrahieren die Sicht auf globale Ressourcen des
Betriebssystems
• z.B. Filesystem-Mount-Points, Netzressourcen, PIDs, etc.

• Prozesse durch Namespaces vom Rest des Betriebssystems isoliert


• Eine Gruppe von Prozessen hat die Illusion alleine auf dem System
ausgeführt zu werden

• Linux-Namespaces sind ähnlich zu Solaris Zones und FreeBSD Jails

• Namespaces werden als „Wrapper“ für die zuvor globalen Ressourcen


implementiert
➜ Jede Ressource ist eindeutig innerhalb eines Namespace-Containers

© 2018-21 Jörg Ott | GBS | IN 0009 34


Linux Namespaces (3)
• Linux unterstützt 6 unterschiedliche Typen von Namespaces
• UTS: Unix Time Sharing (System)
• Isolieren den Host- und Domainnamen
• IPC: Inter-Process Communication
• Isolieren IPC Ressourcen (z.B. POSIX Message Queues)
• Network
• Isolieren Netzressourcen
• PID: Process Identifier
• Isolieren den PID-Raum
• Mount
• Isolieren Mount-Points des Dateisystems
• User
• Isolieren User- und Group-ID-Räume
• Unterscheidung: hierarchische und nicht-hierarchische Namespaces

© 2018-21 Jörg Ott | GBS | IN 0009 35


UTS-Namespaces
• Isolieren System-Identifier
• Prozesse in unterschiedlichen UTS-Namespaces können verschiedene eigene
Host- und NIS Domainnamen, Architekturtypen, etc. haben
• siehe struct new_utsname
• UTS wurde vom struct utsname abgeleitet
11.4 Linux Namespaces
• Diese Struktur hält die System-Identifier
Technische
Universität
München
UTS Namespaces: Beispiel
• struct utsname wird nicht mehr global, sondern pro Namespace verwaltet
1 #define STACK_SIZE (1024 * 1024)
2 #define hostname "safe(name)space"
3 #define domainname "safe.name.space.de"
4
5 static char stack[STACK_SIZE]; 1 static int child_function(void *arg)
6 2 {
7 int main() 3 sethostname(hostname, strlen(hostname));
8 { 4 setdomainname(domainname, strlen(domainname));
9 /* Create child in new UTS namespace. */ 5
10 pid_t pid = clone(child_function, stack+STACK_SIZE, 6 printf("NS: PID = %ld\n", (long)getpid());
CLONE_NEWUTS|SIGCHLD, NULL); 7 printf("NS: PPID = %ld\n", (long)getppid());
11 8
12 printf("Child PID: %ld\n", (long)pid); 9 /* Start a new shell. */
13 10 execlp("/bin/bash", "/bin/bash", (char *)NULL);
14 /* Wait for child to finish. */ 11 }
15 waitpid(pid, NULL, 0);
16
17 exit(EXIT_SUCCESS);
18 }

© 2018-21 Jörg Ott | GBS | IN 0009 36


PID-Namespaces
• PID-Namespaces isolieren PID-Räume
• Prozesse in unterschiedlichen PID-Namespaces können dieselbe PID
haben
• PIDs innerhalb eines PID-Namespace sind eindeutig
• PIDs beginnen jeweils bei 1 und werden sequenziell hochgezählt
• PID 1 ist dem init-Prozess zugeordnet
• Jeder Prozess hat neben seiner PID im PID-Namespace eine PID im
Parent-Namespace
• Beispiel: Ein Prozess mit PID 1 im PID-Namespace trägt die PID 31374 im
Parent-Namespace

➜ PID Namespaces erlauben Container auf andere Systeme zu


migrieren, ohne dass sich dabei die PIDs der Prozesse ändern.

• Frage: Welche PPID besitzt ein Prozess mit PID 1 im PID-


Namespace?

© 2018-21 Jörg Ott | GBS | IN 0009 37


PID-Namespaces (2)
• init-Prozess im PID-Namespace
• Der erste Prozess in einem PID-Namespace erhält die PID 1
• Der init-Prozess hat hier eine ähnliche Rolle wie der unter Linux
• Zuständig für die Initialisierung des PID0Namespaces (z.B. Starten von
weiteren Prozessen)
• Wird Elternprozess für alle verwaisten Prozesse im PID-Namespace

• Kommunikation durch Signale


• Signal-Handler ermöglichen dem init-Prozess Kommunikation mit
• Prozessen in demselben PID-Namespace
• Prozessen in einem verwandten, hierarchisch übergeordneten Namespace
• dem Betriebssystem-Kern
• init-Prozess im PID-Namespace soll nicht durch bestimmte Signale
unterbrochen werden ➜ ignorieren (z.B. SIGTTOU)
• BS-Kern und Prozesse in hierarchisch übergeordneten Namespaces
können durch die Signale SIGKILL und SIGSTOP den init-Prozess
zwingen, sich zu beenden
© 2018-21 Jörg Ott | GBS | IN 0009 38
PID-Namespaces (3)
• PID-Namespaces formen weitere Hierarchieebenen
• Es können verschachtelte (engl. nested) PID-Namespaces erstellt
werden
• Prozesse können nur die Prozesse innerhalb desselben PID-
Namespaces und der Kind-Namespaces der nächsten
untergeordneten Ebene “sehen”

• Frage: Wie viele PIDs werden einem Prozess zugeordnet, der in der
dritten PID Namespace Hierarchieebene erstellt wurde?

• Problem: Programme, wie z.B. ps, verwenden das /proc Filesystem, um


Informationen über alle Prozesse im System/Namespace zu sammeln

© 2018-21 Jörg Ott | GBS | IN 0009 39


IPC- und Network-Namespaces
• IPC-Namespaces isolieren IPC-Ressourcen
• IPC-Objekte in System V und POSIX IPC werden nicht durch Pfade im
Dateisystem identifiziert
• Jeder IPC Namespace verwaltet
• Eine Menge von System V IPC-Bezeichern (IPC Identifiers)
• Ein POSIX-Message-Queue-Filesystem: /dev/mqueue
• Shared-Memory-Bereiche

• Network-Namespaces isolieren Netzressourcen


• Network-Namespaces erlauben Prozessen unterschiedliche
Netzkonfigurationen im selbem Kern
• Beispiele: Firewallkonfiguration, IP-Adressen (und Portnummern), Routen
• Physische NICs können nicht einem Network-Namespace zugeordnet werden
• Stattdessen müssen virtuelle Geräte verwendet werden

© 2018-21 Jörg Ott | GBS | IN 0009 40


Mount-Namespaces
• Mount-Namespaces isolieren Mount-Points des
Dateisystems
• Mount-Namespaces waren der erste Namespaces-Typ unter Linux
• Prozesse in unterschiedlichen Mount-Namespaces haben
verschiedene Sichten auf das Dateisystem
• Jeder Mount-Namespace verwaltet eine eigene Liste von Mount-
Points, die individuell durch mount und umount verwaltet wird

• Problem: Zu starke Isolation von Mount-Points zwischen


Mount Namespaces
• Dateisysteme müssen explizit in jedem Mount-Namespace gemounted
werden

© 2018-21 Jörg Ott | GBS | IN 0009 41


Mount-Namespaces (2)
• Shared Subtrees bieten 4 unterschiedliche Mount-Typen
• Shared Mount
• Mount- und Unmount-Events werden unter Peer Groups propagiert
• Private Mount
• Der Mount-Point empfängt und leitet keine Events zu Peer Groups weiter
• Slave Mount
• Slave-Mount-Points empfangen Events von einer Master Peer Group.
• Unbindable Mount
• Ist ein Private Mount, der nicht gebunden (Bind Mount) werden kann.
• Peer Groups
• Menge von Mount-Points, die Mount- und Unmount-Events untereinander
propagieren
• Shared Mount-Points werden beim Erzeugen eines Mount Namespaces zu
einer Peer Group hinzugefügt
• Bind Mounts
• Ein Bind Mount wird verwendet, um eine Datei/ein Verzeichnis in einer
anderen Stelle des Filesystems sichtbar zu machen
• Bind Mounts sind unabhängig vom Dateisystem
© 2018-21 Jörg Ott | GBS | IN 0009 42
User-Namespaces
• User-Namespaces isolieren User- und Group-IDs
• Prozesse können innerhalb von User-Namespaces andere Privilegien als auf
dem Host System besitzen
• Z.B. können unprivilegierte Prozesse root-Privilegien in User-Namespaces erhalten
• Erhöhte Privilegien sind nur innerhalb des User Namespace gültig
• Falls ein root-Prozess eines User-Namespace auf Ressourcen zugreifen möchte, die
das gesamte System beeinflussen, so prüft der BS-Kern, ob der Prozess
entsprechende Privilegien außerhalb des Namespaces besitzt
• Ähnlich zu PID-Namespaces, können auch verschachtelte User-Namespaces
erstellt werden
• Ein Prozess kann unterschiedliche User- und Group-IDs auf jeder Ebene haben
• Privilegierte Operationen, die von User-Namespaces nicht unterstützt werden,
können nicht ausgeführt werden
• Beispiele: Kernel Module laden, Systemzeit verändern, System rebooten, etc.

• Aber: User Namespaces sind sehr komplex, erweitern den Angriffsvektor


• Mehrere CVEs (common vulnerabilities and exposures) sind kurz nach der
Veröffentlichung der User-Namespaces entstanden
➜ In vielen Linux-Derivaten per Default deaktiviert

© 2018-21 Jörg Ott | GBS | IN 0009 43


Linux Control Groups (Cgroups)
• Cgroups unterteilen Prozesse in hierarchische Gruppen
• Allozieren und verteilen Systemressourcen in Prozessgruppen
• CPU-Zeit, CPU-Cores
• Speicher
• Festplatten- und Netz-Bandbreite
• Ressourcen durch unabhängige Cgroup-Subsysteme repräsentiert
• Cgroup-Subsysteme (Resource Controller) steuern das Verhalten von
Prozessgruppen
• Systemressourcen können begrenzt werden und werden überwacht
• Jedes Subsystem verwaltet eine Hierarchie an Prozessgruppen

• Cgroup-Subsysteme
• blkio, cpu, cpuacct, cpuset, debug, devices, freezer, memory
• net_cls, net_prio, pids
• ...

© 2018-21 Jörg Ott | GBS | IN 0009 44


Linux Control Groups (2)
• Accounting
• Überwacht Seiten, die von den Prozessgruppen verwendet werden
• Anonymous Pages: z.B. Stack und Heap
• Active Pages: vor kurzem verwendete Pages
• Inactive Pages: Kandidaten zum Auslagern
• Seiten können unter mehreren Gruppen unterteilt werden.
• In dem Fall werden die “Kosten” auf die Gruppen verteilt

• Kontrolle
• Jede Prozessgruppe kann weiche und harte Speichergrenzen besitzen
• Weiche Grenzen sorgen dafür, dass Pages wieder zurückgegeben werden
(kein Forcieren)
• Harte Grenzen triggern einen (ggf. angepassten) Out-of-Memory-Killer
• Alle Prozesse in der Gruppe werden eingefroren
• Out-of-Memory-Killer kann Prozesse beenden oder Speichergrenzen anpassen
• Wird die Grenze wieder unterschritten, können Prozesse fortgesetzt werden
• Speichergrenzen können z.B. für Kern- oder physischen Speicher gesetzt
werden

© 2018-21 Jörg Ott | GBS | IN 0009 45


Secure Computing Mode (Seccomp)
• Mechanismus im Linux-Kern, um Systemcalls für Prozesse
einzuschränken
• 3 Modi: Disabled, Strict und Filter
• Modus in /proc/PID/status unter dem Eintrag Seccomp erkennbar
• Aktiviert durch die Systemcals: prctl() oder seccomp()
• Eingesetzt u.a. in Docker, Chrome Browser, OpenSSH und Firefox OS

• Strict Mode: SECCOMP_MODE_STRICT


• Schränkt den Prozess auf vier Systemcalls ein
• read(), write(), exit() und sigreturn()
• Alle weiteren Systemcalls triggern ein SIGKILL Signal.
• Beachte: open() nicht erlaubt
• D.h. Dateien müssen im voraus geöffnet werden

• Filter Mode: SECCOMP_MODE_FILTER


• Steuert, welche Systemcalls für den Prozess erlaubt sind
• Filter basiert auf dem Berkeley Packet Filter (BPF)

© 2018-21 Jörg Ott | GBS | IN 0009 46


Secure Computing Mode (2)
• Berkeley Packet Filter (BPF)
• Implementiert als Virtuelle Machine bzw. Interpreter im Linux Kernel
• Interpretiert eine sehr kleine Instruction Set Architecture (ISA)
• Feste Instruktionsgröße
• Filter werden in Form von kleinen BPF-Programmen realisiert
• Ursprünglich als Paketfilter für Netze u.a. in tcpdump eingesetzt
• Effizientes Filtern von Netzpaketen im Kernel Space
• Ungewollte Pakete werden früh (im Kernel) verworfen, also gar nicht erst an
den User Space übergeben
• Heute auch eingesetzt für: Container Security, System Tracing, Paketfilter, ...

• BPF in Seccomp
• Jeder Systemcall wird gegen installierte Filter getestet
• Filtert nach Systemcall-Nummern und Argument-Werten
• Installierte Filter können nicht deaktiviert werden

© 2018-21 Jörg Ott | GBS | IN 0009 47


Schlussbemerkung
• Virtualisierung: praktische Vorteile
• Unabhängigkeit verschiedener Anwendungen auf demselben System
• Bessere Nutzung von HW-Ressourcen (Multiplexing)
• Outsourcing, Skalierung (scale-up, scale-out)
• Robustheit und Maintenance
• Vorausetzungen
• Equivalence / Fidelity
• Resource Control / Safety (Isolation)
• Efficiency / Performance
• Verschiedene Ansätze
• System vs. Process vs. OS-level virtualization (Container)
• Verschiedene Realisierungsformen
• Full virutalization vs. Paravirtualization
• CPU(s), Speicher, Geräte, ... – mit unterschiedlicher HW-Unterstützung
• Herausforderungen
• Management von virtualisierten Umgebungen
• Plazierung und Migration von VMs

© 2018-21 Jörg Ott | GBS | IN 0009 48


Chair of Connected Mobility
Department of Informatics
Technische Universität München

Kapitel 10

Grundlagen Betriebssysteme und Systemsoftware


Betriebssystem-Sicherheit

Prof. Dr.-Ing. Jörg Ott


Lehrstuhl Connected Mobility

Folien frei nach der Vorlage von Prof. C. Eckert (WS16/17, WS17/18) – danke!

© 2020-21 Jörg Ott | GBS | IN 0009 1


Aktuelle Infos
• Linker & Loader…
• Zusammenfassung

• Repetitorium: 22.02.2020, 9 – 17 Uhr, BBB


• https://bbb.rbg.tum.de/mar-dff-d8b-mgq
• Siehe auch Moodle

• Klausur: 04.03.2021, 14:15 – 15:45

© 2020-21 Jörg Ott | GBS | IN 0009 2


Fragen
• Worauf basiert Sicherheit?

• Was ist ein Zertifikat?

• Wie funktionieren eigentlich Angriffe auf Computer?

© 2020-21 Jörg Ott | GBS | IN 0009 3


Übersicht
• Schutzziele

• Sicherheitskern (Trusted Computing Base)

• Kryptographie

• Authentifizierung

• Zugriffskontrolle

• Speicherschutz (Robustheit)

• Secure Boot

• Angriffsmethoden

© 2020-21 Jörg Ott | GBS | IN 0009 4


Einführung: Schutzziele
• Bedeutung von Daten
• Daten sind ein wertvolles, schützenswertes Gut
• IT-Systeme werden basierend auf Daten zur Steuerung kritischer Abläufe
eingesetzt, z.B. Energieversorgung
• Bedrohungen durch Angreifer (threats)
• Wichtige Schutzziele
• Prüfung der Korrektheit der Identität der Akteure: Authentizität (engl. authenticity)
• Schutz der Daten gegen Manipulation: Daten-Integrität (engl. integrity)
• Schutz vor unberechtigten Zugriffen, Vertraulichkeit (engl. confidentiality)
• Nicht-Abstreitbarkeit von durchgeführten Aktionen (engl. non-repudiation)
• Verwandt: Accountability
• Gewährleistung der Verfügbarkeit (engl. availability) von IT-Diensten
• BS muss Schutzziele gewährleisten und dafür generische Konzepte und
Kontrollfunktionen zur Verfügung stellen
• Aber: Sehr viele „Einfallstore“, sehr viele Verwundbarkeiten, komplexe Systeme
• Linux Kernel mehr als 27 Millionen SLOC
• Windows 10 etwa 50 Millionen SLOC

© 2020-21 Jörg Ott | GBS | IN 0009 5


Schutzmaßnahmen des BS (1)
• Authentizität
• Konzepte zur Identifizierung von Prozessen, Benutzern, Diensten etc.
• Authentifizierung: Identitätsüberprüfung
• Beispiel: Nachweis der Kenntnis eines Passwortes, einer PIN
• Sichere Speicherung von Identifizierungsinformationen, z.B. Passwort

• Datenintegrität
• Rechtevergabe: wer darf welche Operationen auf welchem Objekt
durchführen?
• Zugriffskontrolle: Kontrolle gemäß festgelegter Rechtevergabe
• Isolierung (u.a. Prozessadressräume, Virtuelle Maschinen), Arbeitsmodi
• Speicherschutz
• Data Execution Prevention (DEP), Address Space Layout Randomization
(ASLR), Stack-Shield
• Prüfsummen von Daten mit kryptographischen Hashfunktionen

© 2020-21 Jörg Ott | GBS | IN 0009 6


Schutzmaßnahmen des BS (2)
• Informations-Vertraulichkeit
• Zugriffskontrolle, Isolierung, Virtualisierung
• Verschlüsselte Speicherung von Daten auf der Festplatte.
• Anbindung spezieller Sicherheits-Chips: sichere Speicherung
kryptographischer Schlüssel etc.
• Beispiele
• Sicherheits-Chip im Personalausweis
• TPM-Chip (in allen gängigen Laptops, PCs)

© 2020-21 Jörg Ott | GBS | IN 0009 7


Ideal-Architektur: Sicherheitskern
• Sicherheitskern-Ansatz: Trusted Computing Base
• Idealerweise enthält ein Rechensystem einen Sicherheitskern, der die
sicherheitskritischen Funktionen von HW und BS zusammenfasst
• Idealerweise ist dieser Kern klein und verifiziert
• Eine solche ideale Basis heißt TCB (Trusted Computing Base)
• TCB besteht aus
• Großteil der HW (außer E/A-Geräte, die die Sicherheit nicht beeinflussen)
• Teile des Kerns oder der ganze Kern
• Im Kern: Prozesswechsel, Speicherverwaltung und Teile des E/A-Management
• Alle Programme mit Superuser-Rechten (z.B: setuid-root-Programme)
• TCB sollte so klein wie möglich gestaltet werden, um verifizierbar zu bleiben

Quelle: Tanenbaum/Bos
© 2020-21 Jörg Ott | GBS | IN 0009 8
Ideal-Architektur: Sicherheitskern (2)
• Aber: heutige BS entsprechen diesem Idealbild leider nicht!
• BS ist i.d.R. sehr groß und nicht verifiziert
• z.B. unsichere Gerätetreiber Dritten werden eingebunden (vertrauenswürdig?)
• In heutigen BS sind sicherheitskritische Bereiche i.d.R. nicht von
unkritischen Bereichen abgeschottet
• Bei monolithischen BS besteht das BS aus einer Menge von Routinen, die alle
mit Kernel-Privilegien ausgeführt werden. Keine Isolierung
• Heutige BS erlauben das dynamische Nachladen von Kernmodulen:
erfordert eine Art inkrementelle Verifikation
• Sichere Systeme nutzen deshalb Sicherheitshardware (Hardware-
Sicherheitsmodul, HSM, Secure Element) als Sicherheitsanker,
• z.B. zum sicheren Booten, als sicherer Speicher für (wenige) vertrauliche Daten

• In verteilten Systemen ist eine Kontrolle der eigenen Objekte meist nur
schwer möglich, entfernte Nutzungskontrolle ist noch nicht weit verbreitet
• Gilt z.B. für die Cloud

© 2020-21 Jörg Ott | GBS | IN 0009 9


Angreifer
• Attacker, Intruder, Adversary

© 2020-21 Jörg Ott | GBS | IN 0009 10


Kryptographie
• Wichtige Basis für die Realisierung von Schutzzielen

• Verschlüsselung
• Symmetrisch
• Asymmetrisch

• Hashfunktionen (Einwegfunktionen)

• Digitale Signatur

• (Zertifikate)

© 2020-21 Jörg Ott | GBS | IN 0009 11


Verschlüsselung allgemein
• Vertraulichkeit durch Verschlüsselung

Einfaches Beispiel (Substitutionschiffre)


KE: A → X, B → Y, C → Z, ..., W → T, X → U, Y → V, Z → W
KD: A → D, B → E, C → F, ..., W → Z, X → A, Y → B, Z → C

Klartext: VERSCHLUESSELUNG ALLGEMEIN


Chiffrierter Text: SBOPZEIRBPPBIRKD XIIDBJBFK

© 2020-21 Jörg Ott | GBS | IN 0009 12


graphie Tech
Univ
Mün
metrische Verfahren
Symmetrische Kryptographie
ch Verschlüsselung
• Verschlüsselung und Entschlüsselung mit demselben geheimen
Kryptographie:
Schlüssel k
elung und Entschlüsselung mit dem selben, geheimen Schlüssel k.
• Prinzip

k k

f c f
m -1
m
m: Klartext
c: Chifre
Verschlüsselung k: Schlüssel Entschlüsselung
c = f(k,m) f: Verschlüsselungsfunktion m = f -1(k,c)
f -1: Entschlüsselungsfunktion

Abbildung: Symmetrische Verschlüsselung - Prinzip


• Bekannte Verfahren: DES, AES, A5/3 (Mobilfunk), ChaCha20
Verfahren: DES, AES, A5/3 (Mobilfunk), ChaCha20
• Problem: Schlüsselaustausch
chlüsselaustausch
© 2020-21 Jörg Ott | GBS | IN 0009 13
asymmetrische Verfahren

t durch Verschlüsselung (Forts.)


rischeAsymmetrische
Kryptographie Kryptographie
hlüsselung und Entschlüsselung
• Verschlüsselung mit unterschiedlichen
und Entschlüsselung Schlüsseln.
mit unterschiedlichen Schlüsseln
ip: • Prinzip
Köf Kpriv

f c f
m -1
m
m: Klartext
c: Chifre
Verschlüsselung Köf: öfentlicher Schlüssel Entschlüsselung
c = f(Köf,m) m = f -1(Kpriv,c)
Kpriv: privater Schlüssel
f: Verschlüsselungsfunktion
f -1: Entschlüsselungsfunktion

Abbildung: Asymmetrische Verschlüsselung - Prinzip


• Asymmetrisch: ein Schlüsselpaar pro Kommunikationspartner A bzw. B
• privater Schlüssel Kpriv (nur A bekannt) und
ein Schlüsselpaar
metrisch:• öffentlicher Schlüssel Kpub pro Kommunikationspartner A bzw B
er Schlüssel
• BekannteKpriv Verfahren:
(nur A bekannt) und Elliptic Curve Cryptography (ECC)
RSA, El-Gamal,
licher Schlüssel Kpub
nte Verfahren: RSA, El-Gamal, ECC
© 2020-21 Jörg Ott | GBS | IN 0009 14
Kombination beider Verfahren
• Asymmetrische Kryptographie ist aufwendig!
• Mehrere Größenordnungen komplexer als symmetrische
• Praktischer Ansatz: Kombination beider
• Symmetrisch verschlüsseln und symmetrischen Schlüssel zum Austausch asymmetrisch
verschlüsseln
A B

Asymmetrische Verschlüsselter Asymmetrische


Kpub(B) Kpriv(B)
Verschlüsselung Schlüssel k Entschlüsselung

Zufälliger k
Schlüssel k

Symmetrische Symmetrische
m c c m
Verschlüsselung Entschlüsselung

• Eigenschaften
• Ver-/Entschlüsselung der Daten ist schnell
• Asymmetrische Kryptographie wird nur zum Austausch der symmetrischen Schlüssel
(d.h. für geringe Datenmengen) verwendet
• Dadurch Kombination von Vorteilen beider Varianten
• Austausch eines neuen Schlüssels pro neuer Nachricht möglich
© 2020-21 Jörg Ott | GBS | IN 0009 15
Kryptographische Hashfunktion
Kryptographie Technische
Universität
München

• Durchsetzung von Integrität: Kryptographische Hashfunktionen:


Message Digest
setzung •von Integrität: Kryptographische Hashfunktionen Message Digest
Prinzip
m: Nachricht
n: Message Digest
h: Hashfunktion
m h n

Hashen
n = h(m)

Abbildung: Kryptographische Hashfunktionen - Prinzip


• Nachricht beliebiger Länge wird auf Hash konstanter Länge abgebildet
• Kleine Änderungen in der Nachricht führen zu großen Änderungen im Hash
achricht beliebiger Länge Einwegeigenschaft,
• Anforderungen: wird auf Hash konstanter Länge abgebildet.
Kollisionsresistenz
• Spezialisierung
eine Änderungen Passworthashverfahren
in der Nachricht (gezieltes
führen zu großen Verlangsamen
Änderungen imoder
Hash.
mehrfaches Hashen)
nforderungen: Einwegeigenschaft, Kollisionsresistenz
• Bekannte Verfahren: MD5, SHA1, SHA2-Familie, SHA3, Bcrypt, Argon2
pezialisierung Passworthashverfahren (gezieltes Verlangsamen oder mehrfaches
© 2020-21 Jörg Ott | GBS | IN 0009 16
Hashe
Kryptographie Technis
Univers
Münche
zität (und Integrität)
HMAC
setzung der Daten-Authentizität: HMAC oder Signatur
• Durchsetzung der Daten-Authentizität (1)
k m: Nachricht
mac: Message Digest
H: MAC-Funktion
m H mac k: Schlüssel

MAC
mac = H(k,m)

• Message Abbildung:
Authentication Codes:Authentication
Message (z.B. HMAC RFC2104, symmetrisch)
Code - Prinzip
• Kopplung eines kryptographischen Hashes an einen Schlüssel
• HMAC als „Wrapper“ um existierendes Hash-Verfahren
essage Authentication
H: HMAC(M;K)Codes:
= H(K || (z.B.
H(K || HMAC
M)) RFC2104, symmetrisch)
� Kopplung eines kryptographischen Hashes an einen Schlüssel.
HMAC K(M) = H ( (K ⊕ opad) || H((K ⊕ ipad) || M) )
� HMAC als “Wrapper” um existierendes Hash-Verfahren H: HMAC(M, K) = H(K�H(K�M
• Schlüssel K und Nachricht M werden durch inneren u äußeren Hash kombiniert
K (M) = H�(K ⊕ opad) �� H�(K ⊕ ipad) �� M��
• Empfänger kann mit Schlüssel
HMAC K die Authentizität und Integrität überprüfen
• Kein Nachweis der Urheberschaft gegenüber einem Dritten möglich
� Schlüssel(Symmetrische
K und Nachricht M werden mittels innerem und äußerem Hash kombiniert.
Signatur)
� Empfänger kann mit Schlüssel K die Authentizität und Integrität überprüfen.
� Kein©Nachweis
2020-21 Jörg Ottder
| GBSUrheberschaft
| IN 0009 gegenüber einem Dritten möglich. (Symmetrische
17 Si
HMAC (2)

opad = { 0x5c, … }
ipad = { 0x36, … }
zpad = { 0x00, … }

Quelle: wikipedia.org

© 2020-21 Jörg Ott | GBS | IN 0009 18


yptographie
Digitale Signatur Te
Un

und Integrität)
• Durchsetzung der Daten-Authentizität (2)
gnatur • Digitale Signatur (asymmetrisch):
(asymmetrisch): Basiert auf asymmetrischer
Basiert auf asymmetrischer Kryptographie
Kryptographie
er Schlüssel wirdSchlüssel
• Privater zum signieren verwendet.
wird zum signieren verwendet
ann Signatur
• Jedermit
kannöffentlichem Schlüssel
Signatur mit öffentlichem prüfen.
Schlüssel prüfen
• Nur der Eigentümer des privaten Schlüssels kann die Signatur erstellen
er Eigentümer des privaten Schlüssels kann die Signatur erstellen.
• Daher Nachweis der Urheberschaft gegenüber einem Dritten möglich
Nachweis •derUndUrheberschaft gegenüber
auch Unabstreitbarkeit einem Dritten möglich.
durch den Urheber

Kpriv Köf

s m, sig v
m ja/nein
m: Klartext
Signieren sig: Signatur VerFzieren
sig = s(Kpriv,m) Köf: öfentlicher Schlüssel m = v(Köf,m,sig)
Kpriv: privater Schlüssel
s: Signierfunktion
v: VeriFkationsfunktion

Abbildung: Signaturen - Prinzip


© 2020-21 Jörg Ott | GBS | IN 0009 19
Zertifikate (1)
• Fragen
• Wie wird ein öffentlicher Schlüssel einer Instanz zugeordnet?
• Wie wird sichergestellt, dass es sich um den richtigen Schlüssel handelt?
• Wie wird sichergestellt, dass der Schlüssel noch aktuell ist?

• Verschiedene Approximationen
• Veröffentlichung auf Webseite
• Fingerprints in E-Mails
•…

• Lösung durch Zertifikate (certificates) und Zertifizierungsstellen


(certificate authorities, CA)
• Nutzer erstellt ein Schlüsselpaar (öffentlich, privat) oder lässt erstellen
• Eine vertrauenwürdige Stelle validiert die Identität des Nutzers usw.
• Erstellt ein Dokument mit Identität, öffentlichem Schlüssel u.v.m.
• Signiert dieses Dokument digital und händigt es dem Nutzer aus
➜ Zertifikat
• Nutzer kann dieses veröffentlichen, bei Bedarf übertragen

© 2020-21 Jörg Ott | GBS | IN 0009 20


Zertifikate (2)

© 2020-21 Jörg Ott | GBS | IN 0009 21


Zertifikate (3)
Root CA-1 issues
CA-1.3 cert Root Certificate = Trusted Anchor
User identity
Public key
CA-1.3 issues
Lifetime
user cert Intermediate Certificate ü
User identity Signature
Public key Signer-ID
Lifetime ü
User certificate
User identity Signature
Public key Signer-ID
Lifetime ü
Signature
Signer-ID

• Zertifikate von CAs in Browser vorinstalliert; andere können importiert werden


© 2020-21 Jörg Ott | GBS | IN 0009 22
Authentifizierung (authentication)
• Wichtige Aufgabe des BS: Authentifizierung
• Eindeutige Identifikation und Nachweis der Identität
• Abwehr von Identitätsdiebstahl, Spoofing-Angriffen
• 3 Klassen: Authentisierung basierend auf
• Wissen: z.B. password, PIN, Krypto-Schlüssel
• Besitz: z.B. Smartcard, USB Token, SIM Karte
• Person (Biometrie): z.B. Fingerabdruck, Retina
• Kombination ➜ Multi-Faktor-Authentisierung
• Beispiel: 2-Faktor-Authentisierung
• GSM/UMTS: PIN (Wissen) und SIM-Karte (Besitz)
• Bank: Bankkarte und PIN, Id/Password und registrierte App

• Heutige gängige BS noch immer i.d.R. wissensbasiert


• Login-Namen und Passwort
• Frage: Wie können Passwörter sicher gespeichert bzw. aufbewahrt
werden?
© 2020-21 Jörg Ott | GBS | IN 0009 23
Authentifizierung
• Anforderung
• Selbst mit Zugriff auf die Passwort-Liste hat, soll sich ein Angreifer weder
einloggen noch die gespeicherten Passwörter auslesen können
• Vorgehen
• Einwegfunktion (Hash)
• Ggf. wiederholt anwenden
• Ein Passwort wird vom BS mit einem Salz kombiniert, gehasht und der
Hashwert in einer Systemdatei abgespeichert (z.B. /etc/shadow)
• kryptographische Hashfunktion ist nicht umkehrbar
• Hash erlaubt keinen Rückschluss auf das Passwort
• Durch Salz haben gleiche Passworte unterschiedlicher Nutzer verschiedene Hashes
• Salz verhindert, dass ein Angreifer Hashwerte für alle gängigen Passwörter
vorberechnen kann (Rainbow Tables) ➜ zu aufwendig
• Beispiel: 8 Zeichen Salt ➜ ~1014 Kombination bei 60 zulässigen Zeichen

root:$6$e3mP3V5B$9y.yll/ ... /vtVVTPshNDDhy.:17091:0:99999:7:::

root:$6$e3mP3V5B$9y.yll/ao04xNjORmTkU5B17BzkYFnHZ2CZmhgNoHCsjOtvjS/btAaPjFKxQ2wwPL6EOTL4/vtVVTPshNDDhy.:17091:0:99999:7:::
student:$6$MzwgCm3c$irHT.AnxodVFzr3drXuu3F7qTEfRg/TEfNX5mY6.mteonwHZJRntw5g6XmH3w5fY/LJHqXfbQxgpx1pT0IIs9.:17091:0:99999:7:::

© 2020-21 Jörg Ott | GBS | IN 0009 24


10.5 Authentifizierung
Authentifizierung (3) Technische
Universität
München
Authentifizierung

Passwort User ID Salt Hashwert

Hashfunktion
Salt

Passwortdatei

Eintragen eines Passworts

Passwort

User ID Salt Hashwert


User ID
Hashfunktion

Vergleich

Überprüfen eines Passworts beim Login

C. Eckert Kapitel 10 — Betriebssystem-Sicherheit 15 / 33

© 2020-21 Jörg Ott | GBS | IN 0009 25


Zugriffskontrolle
• Zugriffskontrolle erfordert Festlegungen
• Was ist zu schützen?
• Wem ist erlaubt, was zu tun?

• Das BS bietet hierfür Konzepte


• Objekte: die zu schützenden Ressourcen
• z.B. Dateien, einzelne Speicherseiten, Geräte
• Objekte werden im BS eindeutig identifiziert und beschrieben
• z.B. i-node einer Datei
• BS legt fest, welche Operationen auf dem Objekt ausführbar sind
• z.B. read, write auf Dateien, up/down auf Semaphoren
• Subjekte sind die agierenden Instanzen
• z.B. Prozesse im Auftrag von Benutzern, oder Systemprozesse.
• Subjekte sind eindeutig im Kern identifizierbar
• Prozess: PID, Nutzer: UID
• Rechtevergabe: Subjekte erhalten Rechte zur Ausführung von Operationen auf
Objekten
• Implementiert in der Regel mit Zugriffskontrolllisten (ACLs) oder Capabilities

© 2020-21 Jörg Ott | GBS | IN 0009 26


Zugriffskontrolle (2)
• Protection Domain (Rechteumgebung)
• Regelt die Rechtevergabe
• Jeder Prozess gehört zu jedem Zeitpunkt einer Protection Domain an
• Kann im Laufe der Zeit wechseln
• User Mode vs. Kernen Mode, exec() von Programmen mit SETUID-Bit
• Übergang von einer Domain zur anderen auch durch Rechte geregelt
• Abstrakt: Matrix von Rechten für alle Objekte in allen Domains

• Rechtevergabe
• Nach Spalten: Berechtigungen werden mit den Objekten assoziiert
• Nach Zeilen: Berechtigungen werden den Domänen assoziiert
© 2020-21 Jörg Ott | GBS | IN 0009 27
Zugriffskontrolle (3)
• Capabilities

• Access Control
Lists

© 2020-21 Jörg Ott | GBS | IN 0009 28


Zugriffskontrolle
0.6 Zugriffskontrolle (4) Technische
Universität
München

• Beispiel: Unix-artige Systeme (Unix, Linux, FreeBSD etc.)


• Rechteumgebung
eispiel: Unix-artige eines
Systeme (Unix, Prozesses
Linux, FreeBSDdefiniert
etc.) durch UID und GUID des
� Die Rechteumgebung
assoziierteneines
Nutzers
Prozesses ist definiert durch UID und GUID des assoziierten
Nutzers.• Beim Login erhält der Login-Prozess die UID, GUID des Nutzers
� Beim Login • (idR
in derEingabe
Passwort-Datei des BS erhält
des Passworts) hinterlegt
der Login-Prozess die UID, GUID des
Nutzers,• diese
Zugriffsrechte
Informationwerden an Passwort-Datei
ist in der Nutzer, bzw. deren UID,
des BS GUIDs vergeben
hinterlegt.
� Zugriffsrechte werden an Nutzer, bzw. deren UID, GUIDs vergeben.

Abbildung: UNIX-Rechtevergabe
©
C. Eckert 2020-21 Jörg Ott | GBS | IN 0009 Kapitel 10 — Betriebssystem-Sicherheit 29 17 / 33
Zugriffskontrolle (5)
• Beispiel: Unix-artige Systeme (Forts.)
• System-Call: Prozess wechselt in den Kernel-Mode: Wechsel der
Rechteumgebung
• Kernel-Umgebung umfasst andere Berechtigungen
• z.B. Zugriff auf alle Seiten im RAM
• Aufruf einer Datei mit gesetztem SETUID- oder SETGID-Bit
• Wechsel der Rechteumgebung: der Prozess erhält eine andere UID und
damit die Rechte, des Eigentümers der Datei

• Beispiel: SETUID-Nutzung
• Wechseln des Passwortes erfordert Schreibzugriff auf /etc/shadow
• Schreibrechte an dieser Datei besitzt nur Root (Superuser)
• Setzen des SETUID-Bits für das Programm /bin/passwd
• Bei Ausführung des Kommandos: Zugriff auf die Datei /etc/shadow
• Prozess erhält temporär root-Rechte, so dass ein Schreibzugriff erlaubt ist
• Probleme?

© 2020-21 Jörg Ott | GBS | IN 0009 30


Speicherschutz
• Ausgangspunkt
• Die meisten BS und Sytemprogramme sind in C/C++ implementiert
• C/C++ sind nicht Typ-sicher (type-safe)
• Programmierer ist für sicheres Programmieren verantwortlich
• Beispiel: Nutzung von Zeichenstrings
int x = 1;
char mystring[20] = "This is my string";
printf("%s", mystring);
• Programmierer definiert String mystring der Länge 20
• Im Speicher wird dafür Speicherbereich reserviert
• Compiler prüft nicht, ob nur max 20 Zeichen in mystring gespeichert
werden
• Nur einfache Fälle werden zur Compile-Zeit erkannt
• Es kann zu einem Puffer-Überlauf (buffer overflow) kommen
• Ab dem 21. Zeichen werden benachbarte Variablen (z.B. x) auf dem Stack
und auch die Rücksprungadresse überschrieben
© 2020-21 Jörg Ott | GBS | IN 0009 31
Puffer-Überlauf
• Buffer-Overflow-Angriffe: (BO)
• Angreifer schleust gezielt eine längere Eingabe als erwartet ein
➜ Buffer-Overflow
• Die Eingabe des Angreifers enthält z.B. ausführbaren Code
• Der Code wird mit den Rechten des Prozessen ausgeführt
• Sicherheitsprobleme durch BOs
• Überschreiben von Daten: Integrität
Speicherschutz •

Auslesen von Daten: Vertraulichkeit
Absturz von Programmen: Verfügbarkeit
Technische
Universität
München
erlauf–Schutz
• Aneignung von Zugriffsrechten: Authentizität

• Beispiel (BO)
Overflow-Angriffe: 1
2
void a(){
// reserve a 128 buffer on the stack
• Angreifer
greifer schleust platziert
gezielt in PufferEingabe
eine längere B seinen 3 char B[128];

erwartet ein.Shell-Code 4 printf("Type message: ");

• Return-Adresse wird mit Adresse des5


kommt zumAngreifer-Codes
Buffer-Overflow.
überschrieben
6 // read message from stdin into B
7 gets(B);
e Eingabe des Angreifers
• Beim return enthält
aus der z.B.
Funktion a() wird
8
der eingeschleuste Code ausgeführt 9
sführbaren Code. puts(B);
10 }
r Code ©wird mit
2020-21 Jörgden Rechten
Ott | GBS | IN 0009 des Prozessen 32
Puffer-Überlauf
10.7 Speicherschutz (2) Technische
Universität
München
Puffer-Überlauf–Schutz

0x7FFF...
Stack Stack Stack
main: lokale Variablen main: lokale Variablen main: lokale Variablen
Stack Pointer
Rücksprung Adresse Rücksprung Adresse

a: lokale Variablen
B a: lokale Variablen
B

Heap Heap Heap


Dynamisch allokierter Speicher (zB.: malloc/free) Dynamisch allokierter Speicher (zB.: malloc/free) Dynamisch allokierter Speicher (zB.: malloc/free)

BSS BSS BSS


Unitialisierte statische Variablen Unitialisierte statische Variablen Unitialisierte statische Variablen

Data Data Data


Initialisierte statische Variablen Initialisierte statische Variablen Initialisierte statische Variablen

Text Text Text


Binäres Abbild des Prozesses Binäres Abbild des Prozesses Binäres Abbild des Prozesses

0x0000

C. Eckert Kapitel 10 — Betriebssystem-Sicherheit 21 / 33

© 2020-21 Jörg Ott | GBS | IN 0009 33


Schutzmaßnahme:
10.7 Speicherschutz
Schutzmaßnahme - Stack Canaries
Stack Shielding Technische
Universität
München

• z.B. Stack Canary


Schutzmaßnahme:
Stack-Shielding, z.B. Stack Canary 0x7FFF...
Stack
� Bei Funktionsaufrufen
• Funktionsprinzip main: lokale Variablen
wird ein zufälliger Rücksprung Adresse
• Einfügen
Canary-Wert einesden
zwischen zufälliger
lokalenCanary-Werts
Variablen Stack Canary
• zwischenFunktion
der aufgerufenen den lokalen
undVariablen
der und der
a: lokale Variablen
gespeicherten
gespeicherten Rücksprung
Rücksprung Adresse Stack Pointer
Adresse einfügt.
� Vom Compiler
• Code vom Compiler
eingefügt, vomeingefügt
BS geprüft:
• Vor return wird der Canary-Wert mit

Vor dem Return wird der Canary-Wert
einem Referenzwert verglichen mit Heap
Dynamisch allokierter Speicher (zB.: malloc/free)
einem• Referenzwert verglichen.verändert
Wurde der Canary-Wert
� Wurde der Canary-Wert verändert, so wird BSS
➜ Programm terminieren Unitialisierte statische Variablen
das Programm terminiert.
• Verhindert Überschreiben der
� Verhindert Rücksprungadresse
Data
Überschreiben der nicht Initialisierte statische Variablen
• Aber man durch
Rücksprungadresse kann ihn erkennen nicht,
BO-Angriff Text
• Minimal Integritätsprüfung des Stacks Binäres Abbild des Prozesses
aber man kann ihn erkennen.
• (Hilft auch beim Debuggen)
� Stack-Shields: in allen heute gängigen BS.
0x0000

C. Eckert
• Stack-Shields: in allen heute gängigen BS
Kapitel 10 — Betriebssystem-Sicherheit 22 / 33

© 2020-21 Jörg Ott | GBS | IN 0009 34


Data Execution Prevention (DEP)
• Problem: Solange der Stack ausführbar ist,
10.7kann
Speicherschutz
ein Angreifer Code einschleusen und ausführen
Technische
Universität
München
Data Execution Prevention (DEP)
• Konsequenz: nur .text-Segment sollte ausführbar sein
Problem: Solange der Stack ausführbar ist, kann der 0x7FFF... rw-
• Lösung: Data Execution Prevention Stack
Angreifer Code einschleusen und ausführen. main: lokale Variablen
(DEP) Stack Pointer
� Deshalb: nur .text Segment sollte ausführbar
• CPU-Feature NX-bit (No-eXecute)
sein.
ermöglicht es, Seiten als nicht ausführbar
Lösung:zuData Execution Prevention (DEP)
markieren
� CPU-Feature
• ZusätzlichNX-bit (No-eXecute)
sollten ausführbareermöglicht
Seiten
es, Seiten als nicht ausführbar
nicht schreibbar sein zu markieren rw-

� Zusätzlich
Heap
sollten (W
• WˆX-Policy ausführbare
exklusivesSeiten
Oder nicht
X) Dynamisch allokierter Speicher (zB.: malloc/free)

schreibbar sein:
• DEP verhindert, dass ein Angreifer seinen rw-
BSS
� WˆX-Policy (W exklusives Oder X) Unitialisierte statische Variablen
Shell-Code zur Ausführung bringen kann
� DEP verhindert, dass ein Angreifer seinen
rw-
Data
Initialisierte statische Variablen
Shellcode zur Ausführung bringen kann r-x
� DEP verhindert bisher vorgestellte Angriffe,
Text
Binäres Abbild des Prozesses

aber . . . 0x0000

• DEP verhindert bisher vorgestellte Angriffe, aber . . .


C. Eckert Kapitel 10 — Betriebssystem-Sicherheit 23 / 33
© 2020-21 Jörg Ott | GBS | IN 0009 35
Code-Reuse-Angriffe
• Bislang
• DEP verhindert Ausführung von eingeschleustem Code
• Stack-Canaries erschweren das Überschreiben von Rücksprungadressen
(aber können es eben nicht verhindern)
• Aber: Angreifer kann immer noch zu vorhandenen Code im Speicher springen
• Code Reuse Angriffe
• Einfachste Form: return to libc
• Die meisten Programme nutzen die Bibliothek libc.
• Angreifer kann Rücksprungadressen mit einer Funktionsadresse aus libc
überschreiben
• Häufiges Ziel ist die system()-Funktion: führt angegebenen Befehl aus
• Generalisierte Form: Return-Oriented Programming (ROP)
• Rücksprung nicht nur zum Funktionsanfang, sondern zu beliebigen Instruktionen in
einer Funktion, die mit einem Return enden (ROP-Gadgets)
• Die Ausführung wird bis zur nächsten Return-Instruktion (ret) fortgeführt.
• Angreifer kann mehrere ROP-Gadgets zu ROP-Chains verknüpfen.
• Aus kleinen Code-Stücken kann beliebige Funktionalität konstruiert werden
• Langsam, aber effektiv
• Umständlich / mühsam, aber es gibt Werkzeuge (bis hin zu Compilern)
© 2020-21 Jörg Ott | GBS | IN 0009 36
Beispiel (1): return-to-libc

© 2020-21 Jörg Ott | GBS | IN 0009 37


0.7 Speicherschutz
Beispiel (2): ROP & Gadgets
Technische
Universität
München
rn-Oriented Programming

Ausgeführte Code-Stücke:
&gadget C 1 pop rdx ; gadget A
1 2 pop rsi
&gadget B
Stack
3 pop rdi
2
0x7fffffffffff
4 ret
512
&gadget A
1 pop rax ; gadget B
2 ret

gadget C 1 syscall ;gadget C


syscall

Registerinhalte vor der syscall-Instruktion:


ret
gadget B
rop rax
rax = 1 ; Syscall Nr 1
Text
rdi = 2 ; arg 0
ret
pop rdi
rsi = 0x7fffffffffff ; arg 1
gadget A
pop rsi
pop rdx
rdx = 512 ; arg 2

C. Eckert Frage: Welche Funktionalität


Kapitel 10ergibt das?
— Betriebssystem-Sicherheit 25 / 33

© 2020-21 Jörg Ott | GBS | IN 0009 38


Address Space Layout Randomization
0.7 Speicherschutz
• ROP-Angriff Technische
Universität
München
ddress Space Layout Randomization
• Angreifer muss die(ASLR)
Rücksprung-
Adressen der ROP-Gadgets bestimmen
ROP-Angriff:
� Angreifer
• BS-Schutz gegen ROP-Angriffe 0x7FFF... Zufälliger
muss die Rücksprung-Adresse der Abstand

• Address
ROP-Gadgets Space Layout Randomization
bestimmen. Stack
lokale Variablen
(ASLR) Stack Pointer

ösung: BS-Schutz gegen ROP-Angriffe.


• Randomisierung der Adressen von
Zufälliger
Abstand

� Address Space Layout Randomization (ASLR)


• Stack mmap Segmente
Datei/Speicher Mapppings

� Randomisierung
dynamische Bibliotheken
• Heap
der Adressen von Stack,
• Bibliotheksfunktionen
Heap und Bibliotheksfunktionen
• individuell individuell
für jeden Programmstart
für jeden• Programmstart.
Aber: Rücksprung in Text-Segment
� Aber: Rücksprung
Heap
in möglich
immer noch Text-Segment immer Dynamisch allokierter Speicher (zB.: malloc/free)

noch möglich. Zufälliger

• Erweiterte Form von ASLR BSS


Abstand

rweiterte Form von ASLR:


• Position Inpendent Executable (PIE) Unitialisierte statische Variablen

� Position •Inpendent
Data
Text-Segment wird an(PIE)
Executable zufällige Initialisierte statische Variablen

� Text-Segment
Adresse
wirdpositioniert
Text
an zufällige Adresse 0x0000
Binäres Abbild des Prozesses

positioniert.
© 2020-21 Jörg Ott | GBS | IN 0009 39
C. Eckert Kapitel 10 — Betriebssystem-Sicherheit 26 / 33
nhang: Weitere Angriffsmöglichkeiten
Unvollständige Randomisierung Technische
Universität
München
Address Space Layout Randomization
• Geringe Entropie auf 32-bit Systemen, da nicht alle Bits des Stacks
apitels: randomisiert werden können
• Angreifer
wählte weitere kann Schutz per Brute-Force
Angriffsmöglichkeiten umgehen
für Interessierte zum Nachlesen.
rüfungsrelevanter Stoff.
• Schutz kann per Informations- 1 void c(){
2 char name[100] = {0};
Leak ausgehebelt werden
ndige Randomisierung: 3 int i;
e Entropie •auf
Beispiel: Durch Eingabe eines
32-bit Systemen, da nicht alle 4
negativen Index altekönnen.
s Stacks randomisiert werden Stack-Inhalte 5 printf("Enter your Name: ");
6 scanf("%99s", name);
ausgelesen werden
ngreifer kann Schutz per Brute-Force umgehen. 7 printf("Enter the index: ");
• Mit diesen Adressen können 8 scanf("%d", &i);
kann per Informations-Leak ausgehebelt
ggf. Adressen von Puffern bzw. 9
n: Funktionen berechnet werden 10 if(i < 100) {
printf("ASCII at %d: %x\n", i, name[i]);
Beispiel können per Eingabes eines negativen 11
12 }
dex alte Stack-Inhalte ausgeben werden. 13 else {
it diesen Adressen kann gegenfalls Adresse von 14 puts("Out of range");
ffer bzw. Funktionen berechnet werden 15 }
16 }

© 2020-21 Jörg Ott | GBS | IN Kapitel


0009 10 — Betriebssystem-Sicherheit 28 / 40
33
Non-control flow-diverting attacks
• Bisherige Angriffe haben den Kontrollfluss des Programms modifiziert
• Auch Daten können interessante Angriffsziele sein
void a() {
• Beispiel int authorized;
• Angreifer ist nicht autorisiert char command [128];
und check_auth gibt 0 zurück
// returns 0 if not authorized
• Allerdings können die Inhalte authorized = check_auth(...);
des Puffers command überlaufen
und somit authorized mit Wert ≠ 0 // can be overflowed till we to write
// into the variable authorized
überschrieben werden gets(command);
• Rücksprungadresse wird nicht
überschrieben if(authorized) {
• Aber das Programm gibt puts("Showing secret data:");
...
geschützte Informationen aus }
}

• Frage: Warum bieten die bisher vorgestellten Maßnahmen keinen


Schutz gegen diese Art von Angriffen?
© 2020-21 Jörg Ott | GBS | IN 0009 41
Formatstring-Angriffe
• Weiterer Memory-Corruption-Angriff int main(int argc, char *argv[])
{
• Angreifer kann Formatstring der Funktion char s[100] = {0};
printf() kontrollieren scanf("%99s", s);
• Gibt statt normaler Strings
Formatstring-Platzhalter, wie // print a format string
// controlled by the user
%d , %s , %x . . . ein
printf(s);
• “%08p,%08p,%08p,... ” gibt
Register und beliebige Stack-Inhalte aus return EXIT_SUCCESS;
• Kann zum Aushebeln von ALSR }
genutzt werden (Informations-Leak)
// Beispiel: Nutzung von %n
int main(int argc, char *argv[])
• Der Platzhalter %n erlaubt beliebige {
Daten zu schreiben int n = 0;
// %n stores into n
• %n speichert die Anzahl der bisher printf("GBS %n\n", &n);
ausgegeben Zeichen an der spezifizierten printf("n=%d\n", n); // n=4
Adresse
• Angreifer kontrolliert die Anzahl der return EXIT_SUCCESS;
}
ausgegeben Zeichen und kann so die
schreibende Adresse und den Inhalt über den Formatstring spezifizieren
© 2020-21 Jörg Ott | GBS | IN 0009 42
Integer-Overflow-Angriffe
• C nutzt Ganzzahlarithmetik // ./a.out 1073741824 # 2^32/4
mit fixen Längen (8, 16, 32, 64 bit) // Memory size: 0 # crashes

int main(int argc, char *argv[])


• Summieren oder Multiplizieren {
zweier Zahlen kann den darstellbaren unsigned int i;
Wertebereich überschreiten unsigned int leng = atoi(argv[1]);

➜ Ganzzahlüberlauf (Integer Overflow) // integers take up 4 bytes


printf("Memory size: %u\n",
length * s4);
• Wird das Ergebnis dann zur int *buf = (int *)
Speicher-Allokation genutzt, wird malloc(length * 4);
ggf. ein zu kleiner Puffer alloziiert if (buf) {
for (i = 0; i < len; i++){
• Dies kann wieder zu einem möglichen }
buf[i] = 0x1337;

Pufferüberlauf-Angriff führen }
return EXIT_SUCCESS;
}

© 2020-21 Jörg Ott | GBS | IN 0009 44


Command-Injection-Angriffe
• Verwundbares Programm ermöglicht es
Befehle einzuschleusen und auszuführen
int main(int argc, char *argv[])
• Beispielprogramm {
• Liest einen Hostnamen von der Konsole char hostname [32] = {0};
• Testet, ob dieser erreichbar ist char command [128] = {0};
int alive = 0;
• Die konstruierte Kommandozeile für den
ping-Befehl wird system() ausgeführt scanf ("%31s", hostname);
• Eingabe: “tum.de” sprintf (command, "ping -c 1 %s",
hostname);
• Shell führt “ping -c 1 tum.de” aus
alive = system(command) == 0;
• Problem: es ist möglich, weitere if (alive) {
puts("Host alive!");
Befehle anzuhängen } else {
• z.B. “A; rm -rf /” puts("Host down!");
}
return EXIT_SUCCESS;
}

© 2020-21 Jörg Ott | GBS | IN 0009 45


von Anfang an gegen Manipulation geschützt werden.
Boot mit TPM oder
Secure mittels UEFI Secure Boot
Boot
• Das Betriebssystem muss von Anfang an gegen TPM
Manipulation geschützt werden
• Typische
ntegrität Beispiele:Komponente.
der nächsten Secure Boot mit TPM oder
Firmware
mittels UEFI Secure Boot (UEFI)
e in der Hardware verankert (Firmware
• Idee: Iterativer Check der Integrität der
jeweils nächsten Komponente Bootloader
e Signatur desder
• Beginn Bootloaders.
Vertrauenskette in HW verankert
(Firmware oder TPM).
ft die Signatur des Betriebsystem-Kernels.
• Firmware überprüft Signatur des Bootloaders Betriebsystem
Kernel
icht korrekt,
• Dieserwird der Bootprozess
wiederum überprüft Signatur des
Betriebsystem-Kerns
System
• Ist bei UEFI die Signatur nicht korrekt, Bibliotheken
re verwendet
wird derwerden.
Bootprozess abgebrochen
• TPM kann als Schlüsselstore verwendet werden
Weitere
Anwendungen

© 2020-21 Jörg Ott | GBS | IN 0009


Kapitel 10 — Betriebssystem-Sicherheit 27 /46
33
Chair of Connected Mobility
Department of Informatics
Technische Universität München

Kapitel 12

Grundlagen Betriebssysteme und Systemsoftware


Wrapup

Prof. Dr.-Ing. Jörg Ott


Lehrstuhl Connected Mobility

Folien frei nach der Vorlage von Prof. C. Eckert (WS16/17, WS17/18) – danke!

© 2018-21 Jörg Ott | GBS | IN 0009 1


Übersicht
00 Organisatorisches
01 Einführung und Einordnung
02 Prozesse und Prozessorverwaltung
03 Parallelle Susteme und Synchronisation
04 Modellierung paralleler Systeme
05 Prozesskommunikation
06 Speicherverwaltung
07 Dateisysteme ~630 Folien
08 Ein- / Ausgabe
09 Virtualisierung
10 Betriebssystem-Sicherheit
11 Linker / Loader
12 Wrap-Up

© 2018-21 Jörg Ott | GBS | IN 0009 2


Einbettung des BS in ein Rechensystem
Allgemeine Schichtenstruktur und Einordnung des Betriebssystems

Betriebssystem

Quelle: Schlichter

Optional: Virtualisierung mehrerer Betriebssystem inkl. virtueller Hardware


© 2018-21 Jörg Ott | GBS | IN 0009 3
Das Betriebsystem
• Grobe Struktur

• Management-Sicht
• Prozessverwaltung
• Speicherverwaltung
• Dateisysteme
• E/A-Geräte

• Zugangskontrolle
• Login

© 2018-21 Jörg Ott | GBS | IN 0009 4


Hauptaufgaben des BS
• Abstraktion und Virtualisierung
• Prozessor: Prozess-, Thread-Konzepte
• Arbeitsspeicher: virtueller Prozess-Adressraum
• Persistenter Speicher: Datei
• Peripherie-Geräte (I/O): Spezielle Dateien, I/O-Subsystem
• Kommunikation: u.a. Pipe, Sockets

• Steuerung und Kontrolle von nebenläufigen Abläufen


• Konzepte für den wechselseitigen Ausschluss
• Deadlock-Behandlung
• Kooperations- und Kommunikationskonzepte: IPC
• Modi und Privilegien, kontrollierte Übergänge: Systemcalls

© 2018-21 Jörg Ott | GBS | IN 0009 5


Hauptaufgabe des BS (2)
• Ressourcenverwaltung
• Kriterien: Fairness, Auslastungsgrad, kurze Verweilzeit, schnelle
Antwortzeiten, ...
• Prozess-Scheduling
• Segmentierung, Paging, Working-Set
• I/O: Spooling, Disk-Scheduling

• Daten- und Informationsschutz: IT-Sicherheit


• Zugangskontrolle: Identifizierung und Authentisierung
• Zugriffskontrolle: Rechte, Isolation
• Vertraulichkeit: Verschlüsseln, Schlüsselmanagement
• Integritäts-Prüfung und Speicherschutz

© 2018-21 Jörg Ott | GBS | IN 0009 6


BS-Architekturen
• Monolithisch vs. Microkernel
• Verschieden stark ausgeprägte Modularität
1.5 Betriebssystem-Architekturen
Mikrokerne

Benutzer-
Memoryserver Netzwerkserver
programm
Benutzerm
(User-Mo

Prozessserver Fileserver Displayserver

Antwort

Antwort

Antwort
Anfrage

Anfrage

Anfrage
Antwort

Antwort

Antwort
Anfrage

Anfrage

Anfrage
Systemmo
Mikrokern
(Kernel-M

Hardware

Abbildung: Übersicht über Mikrokernel Architektur

C. Eckert Kapitel 01 — Grundlagen

© 2018-21 Jörg Ott | GBS | IN 0009 7


BS-Architekturen (2)
• Virtualisierungsansätze
Guest Applications
• System Virtual Machine: Hypervisor Syscall Interface

Guest OS
System ISA User ISA
Guest Applications Source
ISA
Syscall Interface
VMM
Guest OS
System ISA User ISA
Source
ISA
OS
Target
VMM ISA
Target
ISA
Hardware
Hardware
Hosted System VM (Typ 2)
Native System VM (Typ 1)

Guest Guest … Guest


• Process Virtual Machines App App App
Container
OS
• OS-Level-Virtualisierung (Container) Hardware
© 2018-21 Jörg Ott | GBS | IN 0009 8
BS, Assembler, Maschinenebene
• Vom Programm (z.B. in C) zum ausführbaren Code:
Transformationen

• Compiler
• Übersetzer von C in Assembler
• Assembler
• Übersetzer von Maschinensprache
in die Instruction Set Architecture (ISA)
• Linker (Binder)
• einzelne Module binden
• Liefert ausführbare Datei
(Executable)
• Loader
• Laden der gebundenen
Objekte in den Speicher

© 2018-21 Jörg Ott | GBS | IN 0009 Quelle: Tanenbaum 9


Prozesse und Prozessorverwaltung
• Prozess ist ein Programm in Ausführung
• Benötigt Ressourcen, um seine Aufgabe zu erfüllen
• Konkurrenz beim Zugriff auf Ressourcen
• Koordination mit anderen Prozessen (Synchronisation)
• Interaktion mit anderen Prozessen (Prozesskommunikation, IPC)

• Verwaltung durch das BS


• Prozesskontext im BS
• Abstraktion der Ressourcen durch das BS
• Anteilige Nutzung der CPU(s)
• Eigener Adressraum
• Gerätezugriff
• Prozesse vs. Threads

• Parallele Systeme, Multiprogramming


• Prozesszustand, Scheduling
© 2018-21 Jörg Ott | GBS | IN 0009 10
Prozesse und Prozessorverwaltung (2)
• Abstraktionskonzepte
• Prozess, Thread (user-level, kernel-level Imlementierung)

• Realisierungs-Datenstrukturen
• Prozess-Kontrollblock (PCB): Verwaltungsinfo/Prozess
• Kernel-Tabellen, Warteschlangen, Listen

• Prozessorzuteilungsstrategie: Scheduling
• Abhängig von Leistungskriterien: z.B geringe Verweilzeit
• FCFS, Shortest Jobs, Shortes Remaining time, RR , Priorität
• Echtzeit: Raten monoton, earliest deadline first

• Prozessor-Bindung: Dispatching
• Kontextwechsel, Zustandsänderung

© 2018-21 Jörg Ott | GBS | IN 0009 11


de Betriebssysteme-Konzepte Technische
Universität
München

Systemcalls
(Niedrige Adressen) 0x00000000

f, z.B. Rückkehr zum aufrufenden Programm


9
Aufruf Kernel Bibliotheksfunktion read
Setzen der Nummer für Systemaufruf read 5
ft den
10
l auf. Benutzermodus 4
Inkrementierung Stack Pointer 11
urch Aufruf Bibliotheksfunktion read
Aufruf von read
Push fd 3
im Programm
Push &buffer 2

Push nbytes 1

0xc0000000

m Kernelmodus
Dispatch
7 8
Syscall
(Betriebssystem) Handler
rt.
(Hohe Adressen) 0xffffffff

Abbildung: Ablauf eines Systemcalls (Quelle: A. Tanenbaum)


© 2018-21 Jörg Ott | GBS | IN 0009 12
Koordination nebenläufiger Prozesse
• Basis: Modellierung des Verhaltens nebenläufiger Prozesse
• Ziel
• Charakterisierung von gewünschten Eigenschaften
• Steuerung der Prozess-Ausführungen, um gewünschte Eigenschaften
zu gewährleisten
• Gewünschte Eigenschaften: generell für parallele Systeme
• Störungsfreiheit (Bernsteinbedingungen)
• Wechselseitiger Ausschluss kritischer Abschnitte
• Deadlockfreiheit und Lebendigkeit (kein Verhungern)
• Modellierungsansätze
• Ereignisse, Aktionsstrukturen, kausale Abhängigkeiten, Traces
• Zustände/Veränderungen: Petri-Netze, Schaltregeln

© 2018-21 Jörg Ott | GBS | IN 0009 13


Koordination nebenläufiger Prozesse (2)
• Ziel: wechselseitig ausgeschlossene Ausführung kritischer
Abschnitte

• Anforderungen an Lösungskonzepte
• 4 Bedingungen

• Lösungskonzepte
• Basis: atomare Operationen
• Hardware-Ebene
• Unterbrechungssperre,
• Maschinenbefehle (u.a. Test-and-Set-Operation)
• Einfache Betriebssystemdienste
• Sleep & Wake-up
• Betriebssystemkonzepte auf höherem Abstraktionsniveau
• Semaphor-Konzept, Mutex
• Monitor-Konzept

© 2018-21 Jörg Ott | GBS | IN 0009 14


Koordination nebenläufiger Prozesse (3)
• Ziel: Deadlockfreiheit

• Modellierung: Belegungs- Anforderungsgraph

• Lösungsansätze
• 4 notwendige und hinreichenden Bedingungen für das Auftreten von
Deadlocks

• Strategien zum Umgang mit Deadlocks


• Ignorieren, Vogel-Strauß Methode
• Deadlock-Detection (Erkennung): Algorithmen hierzu
• Deadlock-Prevention (Verhinderung): eine der vier Bedingung wird
ausser Kraft gesetzt
• Deadlock-Avoidance (Vermeidung): Bankiers-Algorithmus

© 2018-21 Jörg Ott | GBS | IN 0009 15


Interprozess-Kommunikation (IPC)
• Datenvolumen
• Breit- vs. Schmalbandig
• Implizit
• Shared Memory
• Explizit
• Message passing
• Kopplungsart
• Synchron
• Asynchron
• Konzepte
• Ports, Sockets
• Streams, Pipes

© 2018-21 Jörg Ott | GBS | IN 0009 16


Speicherverwaltung
• Abstraktionskonzepte
• Logischer, virtueller Adressraum, virtueller Speicher

• Adress-Abbildung
• Direkt, Basis, Segment, Page

• Verwaltung freier Speicherbereiche: freie und belegte


Blöcke
• Datenstrukturen
• Bitmap, verkettete Liste
• Strategien: Ziel: geringe Fragmentierung, schnelle Suche
• First, Best-,Worst-Fit
• Buddy-Verfahren: Kompromiss: dynamische Blockgröße, schnelle Suche,
rel. Geringe Fragmentierung

© 2018-21 Jörg Ott | GBS | IN 0009 17


Speicherverwaltung (2)
• Virtueller Speicher: Abstraktion von Größe des Hauptspeichers

• Page-Rasterung
• Adress-Abbildung
• MMU, TLB
• Page-Table
• Page-Deskriptor
(Tabellen-Eintrag)

• BS-Aufgabe
• Seite einlagern
• Seitenfehler
• Seitenersetzung

© 2018-21 Jörg Ott | GBS | IN 0009 18


Speicherverwaltung (3)
• Virtueller Speicher: Abstraktion von Größe des Hauptspeichers
• Seitenersetzungsstrategie
(Paging)

• Auswahl-Kriterien
• Zugriffshäufigkeit,
• zukünftige Zugriffe,
• Einlagerungszeit
• ...

• Demand-Paging
• FIFO (Anomalie!),
• 2nd Chance, Clock
• LRU, NFU/Aging

• Pre-Paging
• Working-Set: Seitenflattern vermeiden
© 2018-21 Jörg Ott | GBS | IN 0009 19
Dateisysteme
• Datei-Konzept
• Virtualisierung von persistenten Speichermedien (z.B. Festlatte)

• BS-Aufgabe
• Benennungsschema
• Uniforme Menge von Operationen: z.B. read, open
• Strukturierungskonzept: Verzeichnisse, Pfadenamen

• Dateiverwaltung
• Datei-Deskriptor: Meta-Daten, z.B. inode
• Datenblock-Verwaltung: zusammenhängend, FAT, inode
• Speicherung auf Festplatte: Plattenlayout
• Zuverlässigkeit: Journaling: Protokollieren, Wiederherstellen

© 2018-21 Jörg Ott | GBS | IN 0009 20


Schlichter, TU München 8.2. SCHICHTEN EINES E/A-SYSTEM

einheitliches Benennungsschema für die Geräte. Der Name sollte aus eine

Ein-/Ausgabe Zeichenkette oder Nummer bestehen, und nicht von der Art des Geräte
abhängen.

• Abstraktion von realen Geräten: über mehrere Schichten


8.2 Schichten eines E/A-Systems
• Hardware Ein E/A-System eines BS ist typischerweise in mehrere Schichten unterteilt:
• Controller, I/O-Speicher
Benutzer Modus
• Interrupts Benutzerprozess

• DMA System Modus


geräteunabhängige BS-Software

• BS-Low-level: Treiber-SW Gerätetreiber


Betriebssystem

Unterbrechungsroutinen
• Uniforme Schnittstelle
„nach unten“ zum Treiber Controller

Hardware
Gerät
• Standardbibliothek
„nach oben“ zum Nutzer
• Unterbrechungsroutinen: Handhabung der Rückmeldungen vom Geräte
• Fallbeispiele: Festplatte, Uhr, Terminal
Controller, z.B. nach Beendigung eines Druckauftrags. Die Rückmeldung er
zeugt eine Unterbrechung, die von der zugehörigen Unterbrechungsroutine be
© 2018-21 Jörg Ott | GBS | IN 0009 handelt wird. Der gerade laufende Prozess wird unterbrochen und
21sein Zustan
wird gerettet. Der Prozess, der auf die Rückmeldung des E/A-Gerätes wartet
Sicherheit
• Kryptographische Basis-Funktionen
• Vertraulichkeit: Symm., asymmetrische Verschlüsselung
• Integrität: kryptographische Hashfunktion
• Ursprungsnachweis: Message Authentication Code, digitale Signatur

• Zugangskontrolle: Login, i.d.R. wissensbasiert, Passwort


• Sichere Password-Speicherung (idR Hashwert
• Identitäts-Kontrolle: z.B. auch wiederholt

• Zugriffskontrolle
• Festlegen von Zugriffsrechten, Schutzdomänen, Kontrollen
• Modi (Kernel, user) mit unterschiedlichen Privilegien

• Speicherschutz: Stack-Shield, DEP, ASLR

• Virtualisierung, VMs: Isolierung


© 2018-21 Jörg Ott | GBS | IN 0009 22
Referenzen (1)
00 Organisatorisches
01 Einführung und Einordnung
Schlichter 2.; Tanenbaum/Bos 1.

02 Prozesse und Prozessorverwaltung


Schlichter 4., 3.4; Tanenbaum/Bos 2.1, 2.2

03 Parallelle Systeme und Synchronisation


Schlichter 3.1, 3.2, 3.5, 3.6; Tanenbaum/Bos 2.3, 2.5, 6.

04 Modellierung paralleler Systeme


Schlichter 3.3

05 Prozesskommunikation
Schlichter 6.

© 2018-21 Jörg Ott | GBS | IN 0009 23


Referenzen (2)
06 Speicherverwaltung
Schlichter 5.; Tanenbaum/Bos 3. (- 3.6)

07 Dateisysteme
Schlichter 7.; Tanenbaum/Bos 4. (- 4.4), 10.6

08 Ein- / Ausgabe
Schlichter 8. (- 8.5); Tanenbaum/Bos 5. (- 5.6.1)

09 Virtualisierung
Tanenbaum/Bos 7. (ohne 7.8, 7.9, 7.10, 7.11, 7.13)

10 Betriebssystem-Sicherheit
Tanenbaum/Bos 9. (- 9.7)

11 Linker / Loader
Schlichter 2.3; Tanenbaum/Bos 1.8
© 2018-21 Jörg Ott | GBS | IN 0009 24
Noch etwas Werbung…

© 2018-21 Jörg Ott | GBS | IN 0009 25


Lehrveranstaltungen
• Grundlagen Rechnernetze und verteilte Systeme

• Praktikum: Advanced Systems Programming in C/Rust


(IN0012, IN2106, IN2128)

• Praktikum: Edge Computing and the Internet of Things

© 2018-21 Jörg Ott | GBS | IN 0009 26


Tutoren
gesucht
(nicht nur für GBS im nächsten Winter)

Martin Uhl: uhl@in.tum.de


Registrierung
https://tutorbetrieb.in.tum.de/tutor/#login

© 2018-21 Jörg Ott | GBS | IN 0009 27


Connected Mobility (I11)
www.cm.in.tum.de

© 2018-21 Jörg Ott | GBS | IN 0009 28


VIELEN DANK
und

VIEL ERFOLG

© 2018-21 Jörg Ott | GBS | IN 0009 29