Rechnerarchitektur und Betriebssysteme (CS201): Semaphor, Monitor, Deadlocks, Re-Entrance

Transkript

1 Rechnerarchitektur und Betriebssysteme (CS201): Semaphor, Monitor, Deadlocks, Re-Entrance 5. November 2013 Prof. Dr. Christian Tschudin Departement Mathematik und Informatik, Universität Basel Repetition und Diskussion Was bedeutet nebenläufig? Wo wird bei einer Pipe (zum Beispiel: ls wc ) die Nebenläufigkeit sichtbar? Was ist eine race condition? Erkläre die Semantik der test-and-set -Anweisung. Was ist ein Semaphor? c Christian Tschudin CS201 Rechnerarchitektur und Betriebssysteme, , 2/14

2 Uebersicht OSC Chapter 6: Semaphore Klassische Synchronisationsprobleme Bounded Buffer, Reader/Writer, Dining Philosophers Monitor Aequivalenz von Synchronisationsprimitiven c Christian Tschudin CS201 Rechnerarchitektur und Betriebssysteme, , 3/14 Monitor Synchronisationskonzept auf Prog-Sprachebene: Monitor Semaphor-Programmierung kann leicht zu Fehler führen (Mutex anfordern, aber nicht mehr freigeben; Reihenfolge) Deshalb: andere Art, Synchronisation auszudrücken, gekoppelt mit bekanntem Programmierkonzept: Prozeduraufruf Compiler (!) übersetzt Prozeduraufruf mit den zusätzlich nötigen Synchronisationsaktionen. c Christian Tschudin CS201 Rechnerarchitektur und Betriebssysteme, , 4/14

3 Monitor mit Semaphoren implementieren Semaphore dienen hier als Warteschlangen. Für Code (Monitorimplementierung mit Semaphoren), siehe OSC-Slides Kap 6, c Christian Tschudin CS201 Rechnerarchitektur und Betriebssysteme, , 5/14 UNIX Kernel und Monitor-Semantik Der UNIX Kernel verhält sich wie ein Monitor: Monitor-Methode/Prozedur = UNIX Systemcall Statt compiler-generierte Instruktionen: Trap Nur 1 Prozess ist jeweils im Kernel aktiv (heute für Linux nur noch beschränk gültig) Blockieren im Kernel: explizite Warteschlange für Konditionen (z.b. Gerät bereit) Ein Unterschied in UNIX: Falls ein Ereigniss signalisiert wird, werden dort alle wartenden Prozesse geweckt. c Christian Tschudin CS201 Rechnerarchitektur und Betriebssysteme, , 6/14

4 Shared Memory vs. Message Passing Semaphor, Monitor: Benötigt Zugriff auf gemeinsame Speicherzone für: Koordination (Aendern des Semaphor-Zählers etc) Datenaustausch (Grund, weshalb wir den Zugriff koordinieren) mögicherweise auch gemeinsamer Code (im Fall des Monitors) Wie kooperieren nebenläufige Prozesse ohne gemeins. Speicher? Meldungsaustausch via einen Mediator (oder Medium): via das Betriebssystem (Einzel-CPU) Datenbus (Multiprozessorenrechner) Datennetz (Ethernet) c Christian Tschudin CS201 Rechnerarchitektur und Betriebssysteme, , 7/14 Meldungsaustausch send() und receive() Ueblicherweise sind dies blockierende Dienste Wegen möglichem Blockieren: send/receive kann zur Synchronisation verwendet werden. Dies ist auch die Lösung des Prod/Cons-Szenarios in Unix: Prod: (blocking) write() Cons: (blocking) read() c Christian Tschudin CS201 Rechnerarchitektur und Betriebssysteme, , 8/14

5 Equivalenz der Synchronisations-Primitive Semaphor, Monitor und Meldungsaustausch habe die gleiche Mächtigkeit (in einer Umgebung mit gemeinsamen Speicher): Durch zirkuläre Implementierbarkeit begründet. Meldungs austausch implementierbar mit Monitor implementierbar mit Semaphor implementierbar mit Fall 1: Implementierung von Meldungsaustausch mit Monitor: Baue Buffer-Manager-Monitor mit send/receive-methoden. Fall 2: Implementierung eines Monitors mit Semaphoren: durch Konstruktion. c Christian Tschudin CS201 Rechnerarchitektur und Betriebssysteme, , 9/14 Implement. von Semaphoren with Meldungsaustausch (Fall 3) Ansatz: Erzeuge einen Prozess S, der wait/signal -Anfragen abarbeitet wir setzen blockierende send/receive-primitive voraus wait(mutex) send(s, WAIT_REQUEST); receive(s, CONFIRMATION); signal(mutex) send(s, SIGNAL_REQUEST); receive(s, CONFIRMATION); c Christian Tschudin CS201 Rechnerarchitektur und Betriebssysteme, , 10/14

6 Semaphor mit Meldungdsaustausch (Forts), Server int cnt = 1; /* initial sempahore value */ for (;;) { p = receive(*, &msg); if (msg == WAIT_REQUEST) { if (cnt-- > 0) send(p, CONFIRMATION); else insert_in_queue(p); } else if (msg == SIGNAL_REQUEST) { send(p, CONFIRMATION); if (cnt++ < 0) send(remove_from_queue(), CONFIRMATION); } } c Christian Tschudin CS201 Rechnerarchitektur und Betriebssysteme, , 11/14 Programmierung mit Nebenläufigkeit Unterschiedliche Unterstützung der Nebenläufigkeit: Hardware: Multi-Prozessor, d.h. mehrere CPUs Prozess: Multitasking: 1 Computer wird von N Prozessen geteilt z.b. Time-Sharing Systeme Sub-process Ebene: unabhängige Aktivitäten innerhalb eines Prozess e.g., Multimedia-Applikation: Video-Ausgabe, Icon auffrischen c Christian Tschudin CS201 Rechnerarchitektur und Betriebssysteme, , 12/14

7 Thread = leichtgewicht Prozess Ein Thread ist eine abstrakte CPU Aktivität: mit eigenem Instruktionszähler (PC) mit eigenem Datenstack mit eigenem Register-Set Mehrere Threads können den gleichen Code ausführen Threads gehören einem (schwergewichts)-prozess an, der alle OS-Ressourcen bündelt Code Datenspeicher OS Ressourcen (Konsole, Datei, Ausführungsrechte etc) c Christian Tschudin CS201 Rechnerarchitektur und Betriebssysteme, , 13/14 Unterschiede in Thread Typen/Implementierung Standard UNIX: keine Unterstützung für Threads User space: simulierte Threads, z.b. pthread-library Kernel threads: OS kann einzelne User-space-threads blockieren c Christian Tschudin CS201 Rechnerarchitektur und Betriebssysteme, , 14/14

8 Synchronisation, Kritische Region, Deadlock Synchronisations-Instrumente ermöglichen koordinierten Zugriff auf kritische Ressourcen, kritische Region. Durch Synchronisations-Instrumente kann aber ein System in einen blockierten Zustand (Deadlock) geraten. Beispiel: Reservation zweier Mutex in der falschen Reihenfolge. c Christian Tschudin CS201 Rechnerarchitektur und Betriebssysteme, , 15/14 Beschreibung von Deadlock Eine Menge von Prozessen ist in einem Deadlock Zustand, falls alle Prozesse der Menge warten auf eine Liste von Ereignissen, 2. jedes dieser Ereignisse kann nur durch einen Prozess dieser Menge erzeugt werden. Unterschied zu Life-lock : das nebenläufige System ist nicht blockiert, aber es kann keinen Fortschritt machen c Christian Tschudin CS201 Rechnerarchitektur und Betriebssysteme, , 16/14

9 Bedingungen für Deadlocks Die vier Bedingungen für Deadlocks: 1. Ressourcen mit exklusivem Zugriff (nicht-geteilt) 2. Inkrementelle Allokation der Ressourcen 3. Keine Wegnahme einmal vergebener Ressourcen (preemption) 4. Zirkuläre Warte-Situation innerhalb des Ressourcen-Allokations-Graphs c Christian Tschudin CS201 Rechnerarchitektur und Betriebssysteme, , 17/14 Strategien betreffend Deadlocks Deadlock Verhinderung: sicherstellen, dass eine der 4 Bedingungen nicht eintreten kann z.b.: alle Ressourcen in einer Aktion allozieren Deadlock Vermeidung: z.b. zur Allokationszeit auf zirkuläre Wartebeziehung prüfen Deadlock Erkennung: nur im Verdachtsfall die Wartebeziehungen prüfen Problem ignorieren; nichts tun, weil Deadlocks selten sind ( UNIX) c Christian Tschudin CS201 Rechnerarchitektur und Betriebssysteme, , 18/14

10 Reentrance Verbreiteter Fehler der Nebenläufigkeitsprogrammierung: non-reentrant code Definition: Eine Prozedur ist re-entrant falls die Prozedur das gleiche Resultat liefert, unabhängig von der Anzahl (gleichzeitiger) Aufrufe. Globale Variablen als häufige Fehlerquelle. Beispiel: int tmp; void swap(int *a, int *b) { tmp = *a; *a = *b; *b = tmp; } Java hat keine globalen Variablen (allerdings: Klassenvariablen) c Christian Tschudin CS201 Rechnerarchitektur und Betriebssysteme, , 19/14 Reentrance (Forts.) Non-reentrant Code existiert an überraschend vielen Orten: Library-Code ist oft nicht multi-thread safe (Einführung von LWP in SunOS bedingte substanzielles Rewrite) Ergebnis-Werte errno in C Statische Ergebnis-Puffer asctim() in C Lektion: Globale Variablen vermeiden! Bzw den Zugriff auf solchen Code/Daten durch mutex schützen. c Christian Tschudin CS201 Rechnerarchitektur und Betriebssysteme, , 20/14