hwr-notes/Betriebssysteme/Zusammenfassung_IPC.md

Zusammenfassung: IPC

1. Grundlagen und Motivation

Prozesse benötigen häufig einen Informationsaustausch (Beispiel: Ein E-Mail-Programm Mail User Agent sendet Daten an den Mail Transfer Agent). Da jeder Prozess grundsätzlich einen eigenen, isolierten Adressraum besitzt, ist eine direkte Kommunikation nicht trivial. Das Grundprinzip:

• Für die Kommunikation ist gemeinsam genutzter Speicher (Shared Memory) zwingend erforderlich. Dies kann ein Bereich im Kernel-Adressraum sein oder eine Datei auf der Festplatte.
• Moderne Betriebssysteme erlauben es Prozessen, Teile ihres Adressraums explizit für andere freizugeben. Prozesse vs. Threads in der IPC:
• Threads desselben Prozesses teilen sich bereits automatisch den Adressraum.
• Wenn zwei Prozesse einen gemeinsamen Speicherbereich nutzen, verhalten sie sich technisch fast identisch zu zwei Threads.
• Daher gilt der Leitsatz: Interprozesskommunikation ist im Grunde immer Interthreadkommunikation.

2. Das Problem: Race-Conditions (Wettlaufsituationen)

Definition: Eine Race-Condition entsteht, wenn mehrere Prozesse/Threads gleichzeitig auf gemeinsam beschreibbare Ressourcen zugreifen und das Endergebnis von der zufälligen zeitlichen Reihenfolge der Ausführung abhängt. Gefahren:

• Race-Conditions führen zu semantischen Fehlern, die schwer zu finden sind (keine Syntaxfehler!).
• Der Code funktioniert meistens korrekt, stürzt aber sporadisch ab („Heisenbugs").

Beispiel 1: Das Logdatei-Problem (Der Absturz)

Zwei Prozesse (A und B) wollen in dieselbe Logdatei schreiben:

1. Prozess A liest den Status: „Datei ist geschlossen". A setzt intern is_open = false.
2. Kontextwechsel: Die Zeitscheibe von A läuft ab, bevor A die Datei wirklich öffnen kann.
3. Prozess B kommt an die Reihe, liest den Status: „Datei ist geschlossen".
4. Prozess B öffnet die Datei, schreibt hinein und setzt den Status (physikalisch) auf „offen".
5. Kontextwechsel: B wird unterbrochen.
6. Prozess A läuft weiter. Da A intern gespeichert hat is_open = false, prüft es nicht erneut.
7. Fehler: A versucht, die (bereits offene) Datei erneut zu öffnen → Absturz oder Datenverlust.

Beispiel 2: Lost Update (Datenbank)

Zwei Threads wollen einen Zähler (counter = 0) erhöhen. Code: counter = counter + 1; Obwohl der Code logisch aussieht, passiert auf Maschinenebene Folgendes:

1. Thread A lädt Wert 0 in Register.
2. Thread B lädt Wert 0 in Register (bevor A schreibt).
3. A erhöht auf 1 und speichert.
4. B erhöht (seine 0) auf 1 und speichert. → Ergebnis ist 1 statt 2. Ein Update ging verloren.

3. Die Lösung: Der Kritische Bereich

Definition: Der Programmteil, in dem auf den gemeinsam genutzten Speicher zugegriffen wird, nennt sich Kritischer Bereich (Critical Section).

Die 4 zentralen Bedingungen für Synchronisation

Um Race-Conditions zu verhindern, muss das Betriebssystem folgende Regeln garantieren:

1. Gegenseitiger Ausschluss (Mutual Exclusion): Es dürfen sich niemals zwei Prozesse gleichzeitig im kritischen Bereich befinden.
2. Keine Annahmen: Die Lösung darf nicht von der Geschwindigkeit der Prozesse oder der Anzahl der CPUs abhängen.
3. Keine Blockierung von außen: Ein Prozess, der sich außerhalb seines kritischen Bereichs befindet, darf andere Prozesse nicht blockieren.
4. Kein ewiges Warten (No Starvation): Jeder Prozess muss irgendwann die Chance bekommen, in den kritischen Bereich einzutreten.

4. Mechanismus 1: Atomare Operationen

Das Grundproblem ist, dass Hochsprachen-Befehle (wie i++) nicht atomar (unteilbar) sind. Sie bestehen aus mehreren CPU-Befehlen (Load, Increment, Store), die unterbrochen werden können. Lösung auf Hardware-Ebene: Prozessoren bieten spezielle Assembler-Instruktionen, die garantiert nicht unterbrochen werden können. Wären alle Befehle atomar, gäbe es keine Race-Conditions. Wichtige Assembler-Befehle:

• TSL (Test-and-Set-Lock): Liest ein Byte aus dem Speicher in ein Register und schreibt im selben Taktzyklus einen neuen Wert (z.B. 1) an diese Stelle.
• FAA (Fetch-and-Add): Inkrementiert einen Wert im Speicher atomar.
• CAS (Compare-and-Swap): Vergleicht den Speicherinhalt mit einem Erwartungswert und tauscht ihn nur bei Übereinstimmung aus (Basis für lock-free Algorithmen).
• XCHG (Exchange): Tauscht die Inhalte zweier Register oder Speicheradressen atomar.

5. Mechanismus 2: Mutex (Mutual Exclusion)

Konzept: Ein Mutex ist eine Technik und Datenstruktur, die als "Schloss" dient.

• Nur der Thread, der den Mutex "besitzt" (lock), darf in den kritischen Bereich.
• Nur der Besitzer kann den Mutex wieder freigeben (unlock). Ablauf (Code-Schema):

pthread_mutex_lock(&m);   // Versuche Schloss zu holen. Wenn belegt -> Warten.
/* KRITISCHER BEREICH (z.B. Schreiben in Datei) */
pthread_mutex_unlock(&m); // Schloss freigeben.

Verhalten bei belegtem Mutex

Wenn Thread A den Mutex hat und Thread B ihn will, hat B drei Optionen:

1. Passives Warten: B gibt die CPU ab und wird vom OS "schlafen gelegt" (blocked), bis der Mutex frei ist.
2. Aktives Warten (Spinlock): B läuft in einer Schleife und prüft permanent („Ist frei? Ist frei?"). Sinnvoll nur bei sehr kurzen Wartezeiten auf Multi-Core-Systemen.
3. Timeout: B bricht den Versuch nach einer Zeit ab.

6. Mechanismus 3: Signale

Eigenschaften: Signale sind ein sehr altes Konzept (Unix) und stellen eine Software-Unterbrechung (Interrupt) dar. Sie können an Prozesse oder Threads gesendet werden. Funktionsweise:

• Wenn ein Signal empfangen wird, unterbricht der Prozess seine Arbeit sofort.
• Entweder führt er eine ISR (Interrupt Service Routine) aus (benutzerdefiniert) oder die Standardaktion des Kernels (z.B. Prozess beenden).
• Signalmaske: Jeder Thread kann definieren, welche Signale er blockieren/ignorieren möchte. Wichtige POSIX-Funktionen:
• pthread_kill(): Sendet Signal an einen Thread (nicht zwingend tödlich, dient als Benachrichtigung).
• sigwait(): Thread wartet passiv auf ein bestimmtes Signal.

7. Mechanismus 4: Semaphore (nach Dijkstra)

Konzept: Ein Semaphor ist mächtiger als ein Mutex. Er erlaubt den Zugriff einer vordefinierten Anzahl von Threads gleichzeitig.

Datenstruktur

Ein Semaphor besteht aus zwei Elementen:

1. Einem Zähler (Integer).
2. Einer Warteschlange (Queue) für blockierte Threads.

Die zwei Operationen

• P() / wait(): Dekrementiert den Zähler.
  • Ist der Zähler danach ≥ 0: Zugriff erlaubt.
  • Ist der Zähler < 0 (bzw. war 0): Thread wird blockiert und in die Queue geschoben.
• V() / signal(): Inkrementiert den Zähler.
  • Wenn Threads in der Queue warten, wird einer geweckt.

Unterschied zu Mutex

• Ein Mutex muss vom Besitzer freigegeben werden. Ein Semaphor kann von jedem Thread inkrementiert (V) werden (Asynchrone Signalisierung).
• Ein Semaphor mit Zähler = 1 (Binärer Semaphor) verhält sich wie ein Mutex.

Beispiel: Bahnhofsüberwachung (Performance-Begrenzung)

Szenario: Es gibt viele Kameras, aber aus Performance-Gründen dürfen maximal 3 Such-Threads gleichzeitig Bilder analysieren.

• Initialisierung: Semaphore s = new Semaphore(3);
• Thread startet: s.P() (Zähler wird 2... dann 1... dann 0).
• Der 4. Thread muss warten (Zähler bleibt 0, Thread in Queue).
• Thread fertig: s.V() (Zähler wird 1, Wartender darf rein).

8. Mechanismus 5: Monitore

Konzept: Monitore sind ein Konstrukt auf höherer Abstraktionsebene (Sprachunterstützung). Ein Monitor ist ein gekapselter kritischer Bereich (z.B. eine Klasse oder Methode). Eigenschaften:

• Automatische Sicherheit: Der Compiler garantiert, dass immer nur ein einziger Prozess/Thread gleichzeitig im Monitor aktiv ist.
• Programmierer müssen Lock/Unlock nicht manuell schreiben → weniger fehleranfällig. Implementierung in Java:
• Schlüsselwort: synchronized.
• Kann auf Methoden (synchronized void methode()) oder Blöcke (synchronized(this) { ... }) angewendet werden.

Bedingte Synchronisation (Warten im Monitor)

Oft muss ein Thread im Monitor warten, bis eine Bedingung erfüllt ist (z.B. Puffer nicht mehr leer). Dazu gibt es spezielle Methoden:

• wait(): Thread legt sich schlafen und gibt den Monitor frei, damit andere eintreten können.
• notify(): Weckt einen wartenden Thread (zufällig).
• notifyAll(): Weckt alle wartenden Threads (sicherer, um Deadlocks zu vermeiden).

9. Weitere Konzepte

Das volatile Primitiv

• Kennzeichnet Variablen, die sich "außerhalb des Programmflusses" ändern können (z.B. durch Hardware oder andere Threads).
• Effekt: Der Compiler schaltet Optimierungen ab und erzwingt bei jedem Zugriff ein Lesen aus dem Hauptspeicher (statt aus dem schnellen CPU-Cache).
• Achtung: volatile garantiert Sichtbarkeit (Aktualität), aber keine Atomizität. Es ersetzt keinen Mutex bei komplexen Operationen.

Parallele Programmiersprachen

Sprachen wie Occam, Ada oder Erlang besitzen eingebaute Kontrollstrukturen (z.B. PAR für parallele Ausführung oder Kanäle für Kommunikation), um Synchronisation direkt in der Syntax abzubilden, statt externe Bibliotheken zu nutzen.