Literatur. Betriebssysteme WS 2015/16 - Teil 8/Synchronisation I

Transkript

1 Literatur [8-1] Werner, Dieter: Theorie der Betriebssysteme. Hanser, 1992 [8-2] Dannegger, Christian; Geugelin-Dannegger, Patricia: Parallele Prozesse unter UNIX. Hanser, 1991 [8-3] Siegert, Hans-Jürgen; Baumgarten, Uwe: Betriebssysteme. 5. Auflage, Oldenbourg, 2001 [8-4] Tanenbaum, Andrew: Moderne Betriebssysteme. 2. Auflage, Hanser, 1995 [8-5] 2

2 Übersicht Grundbegriffe enter und leave Dekker's Algorithmus lock und unlock 3 Hinführung I In diesem Teil werden grundsätzliche Prinzipien bzw. Probleme von Parallelität von Operationen auf gemeinsam benutzte Betriebsmittel, insbesondere RAM betrachtet. Bisher gingen wir von folgender Struktur aus: CPU IO 1 IO 2 IO n Bus RAM Alle Geräte (IO N ) können per DMA auf den RAM zugreifen und Interrupts senden. 4

3 Hinführung II Nun verallgemeinern wir auf beliebig viele CPUs: CPU 1 CPU 2 CPU n IO 1 IO 2 IO n Bus RAM Der RAM zusammen mit dem Bus bietet atomare, also unteilbare Lese/Schreib-Operationen an, die nur sequentiell ablaufen. D.h. zu einem Zeitpunkt kann immer nur eine CPU/Gerät auf den RAM zugreifen. Alle anderen Geräte/CPUs müssen auf die Zuteilung des Busses warten. 5 Annahmen I - CPU Keine Instruktion der CPUs ist durch Interrupts unterbrechbar, d.h. wenn eine CPU einen Interrupt feststellt, so führt sie die aktuelle Instruktion vollständig zu Ende aus bevor sie mit der Behandlung des Interrupts beginnt. Während der Ausführung einer Instruktion mit Speicherzugriff hat die CPU als einzige die volle Kontrolle über den Bus und damit auf den RAM, d.h. niemand kann den Bus einer CPU wegnehmen noch ihn parallel benutzen. Dass heißt: Für 1-CPU-Maschinen: Nur zwischen den Instruktionen kann ein Threadwechsel stattfinden, keine Parallelität. Für N-CPU-Maschinen: Bei jeder CPU einzeln kann nur zwischen den Instruktionen ein Threadwechsel stattfinden, also für jede CPU ist alles sequentiell, aber untereinander haben alle CPUs volle Parallelität. Hinweis: Per Timer-Interrupt kann ein Thread seine CPU verlieren. 6

4 Annahmen II - Geräte Für DMA-fähige Geräte gilt folgendes: Der Vorgang des Kopierens von Blöcken in oder aus dem RAM wird in Teile zerlegt. Nach dem Kopieren eines Blocks wird der Bus abgegeben. Aber für jeden Teil erhält das Gerät wie die CPUs den Bus atomar. Grund: Wenn der vollständige DMA-Vorgang den Bus belegen würde, würden die Wartezeiten der anderen Geräte/CPUs auf den Bus zu lange dauern. Nicht-DMA-fähige Geräte brauchen wir hier nicht zu betrachten, denn diese greifen nicht auf den RAM zu. Aus Gründen der Vereinfachung betrachten wir in diesem Teil nur die Zugriffe auf den RAM. Dieselben Probleme treten aber auch beim Zugriff auf Plattenblöcke etc. auf: Mehrere Threads können in Wettlaufsituationen Blöcke auf die Platte schreiben. 7 Hinführung III Thread A a:= 1; IF a!= 0 THEN b:= c/a; FI. Kritische Abschnitte Falls vorher a = 1 war... Zugriff Thread B. b:= a; b:= b-1; a:= b;. Variable a 8

5 Bemerkungen Um Probleme erkennen zu können, sollte folgendes angenommen werden: Threads können aufgrund von Pausen andere überholen. Threads können unterschiedliche Geschwindigkeiten haben. Zur Prüfung auf Korrektheit müssen auch pathologische Abläufe ausgedacht werden. Gibt es einen einzigen möglichen Ablauf, der zu einem Fehler führt, dann ist die Software fehlerhaft, auch dann, wenn die Wahrscheinlichkeit dafür minimal ist. Kritischer Abschnitt = Bereich im Code, bei dessen Ausführung Probleme mit anderen Threads auftreten können Allgemein: Immer wenn Prozesse/Threads/Tasks auf gemeinsame Betriebsmittel schreibend zugreifen, gibt es Abstimmungsprobleme. 9 Das Problem a:= 1; Thread A IF a!= 0 THEN b:= c/a; FI b:= a; b:= b-1; a:= b; Thread B Bedeutet "Pause" Das kann bei einer wie auch bei mehreren CPUs passieren. 10

6 Kritische Abschnitte II Kritische Abschnitte sind Codebereiche, die (fast) nie gleich sind. Kritische Abschnitte beziehen sich immer auf Betriebsmittel, die einen (Speicher-)Zustand haben: Variablen, Platten etc. Alle kritischen Abschnitte, die sich auf dieselbe Menge von Betriebsmitteln beziehen, werden zu einer Klasse zusammen gefasst. Mit anderen Worten: Wenn an mehreren Stellen auf dieselben Variablen aus verschiedenen Threads zugegriffen wird, so bilden alle diese Stellen jeweils kritische Abschnitte derselben Klasse. Alle kritischen Abschnitte einer Klasse müssen untereinander abgestimmt werden. Kritische Abschnitte verschiedener Klassen brauchen nicht koordiniert zu werden. Threads/Prozesse, die gleichzeitig kritische Abschnitte derselben Klasse betreten könnten, müssen untereinander koordiniert werden. 11 Begriffe - Ganz allgemein Koordination = Abstimmung zwischen Threads, um Datenkonsistenz bei gleichzeitigem Zugriff zu erhalten Datenkonsistenz = Erfüllen der für die Problemlösung notwendigen Bedingungen an Datenwerte die Assertions Synchronisation = Zeitliche Abstimmung hinsichtlich der Benutzung von Ressourcen Herstellen von "Gleichzeitigkeit", von Gleichtakt Ressource = Betriebsmittel = Hier: Adressierbarer Speicher Allgemein: Etwas, was beschrieben oder benutzt werden kann, z.b. CPU, Netz, Platte, Drucker, Ethernet, Video-RAM 12

7 Wechselseitiger Ausschluss Wechselseitiger Ausschluss = Mutual Exclusion = Ergebnis der Koordinierung zur Verhinderung von Problemen bei der gemeinsamen Benutzung von Variablen in kritischen Abschnitten Beim wechselseitigen Ausschluss werden Threads daran gehindert, eine Ressource zu benutzen, wenn diese durch einen anderen Thread benutzt wird. Erst nach Freigabe kann ein anderer Thread die Ressource belegen. Ziel der Synchronisation: Durch Realisierung von wechselseitigen Ausschlüssen wird der Zugriff auf gemeinsam benutzte Betriebsmittel so auf einander abgestimmt, dass die Konsistenz der Daten und damit die Korrektheit der Implementierung sichergestellt wird. 13 Deadlock und Starvation I Deadlock = Warten auf ein Ereignis, das nicht eintreten kann, da die das Ereignis signalisierenden Vorgänge auf eine Aktivität eines Threads warten, der selbst auf das Ereignis wartet. Deadlock ist ein strukturell bzw. logisches Problem, das durch ein zyklenhaftes Warten entsteht: Beispiele: A wartet darauf, dass B etwas tut, während B darauf wartet, dass A etwas tut Beide warten unendlich lange: Dead You-after-you-Problem Verkehrskreuzung mit vier Autos Starvation = Zu langes Warten auf ein mögliches Ereignis als Folge übermäßiger "Ungerechtigkeit" zwischen Prozessen/Threads Starvation ist ein Scheduling-Problem, d.h. ein Problem der Zuweisung von Ressourcen an Threads. 14

8 Deadlock und Starvation II Dining Philosophers I Gabel 3 Philosoph 3 Gabel 2 Philosoph 4 Spaghetti Philosoph 2 Gabel 4 Philosoph 1 Gabel 1 Ein Philosoph isst entweder Spaghetti oder er denkt. Essen und Denken müssen sich abwechseln und nicht zu lange dauern (in beiden Fällen drohen sonst gesundheitliche Schäden). Philosophen benötigen zum Essen zwei Gabeln (Erziehung). Bestimmte Algorithmen der Philosophen führen zu Deadlocks, andere zu Starvation. 15 Demonstrationsbeispiel Dining Philosophers II Alle Philosophen benutzen denselben Algorithmus. Folgendes Verfahren führt zum Deadlock: Jeder nimmt die Gabel rechts Jeder wartet auf die Gabel links Folgendes Verfahren führt zum Verhungern (Starvation): Jeder nimmt die Gabel rechts Wenn die fehlende Gabel nicht verfügbar ist, legt er die rechte Gabel zurück. Es beginnt von vorn. Hinweise Das Beispiel stammt von Edsger Dijkstra (1965) Siehe Ursprünglich war es ein chinesisches Gericht und die Gabeln waren Stäbchen. 16

9 Zeitpunkte der Synchronisation I Eine Wettlauf-Bedingung (Race Condition) liegt dann vor, wenn es Serialisierungen paralleler Abläufe mit unterschiedlichen Wirkungen auf die Ressource gibt. Mindestens eine dieser Wirkungen ist dabei nicht erlaubt. Dies ist eine analoge Formulierung für das oben beschriebene "Ausdenken" aller möglichen, also auch pathologischen Abläufe. Wettläufe werden durch Verbieten der Serialisierungen mit den unerwünschten Effekten verhindert. Dafür gibt es zwei Strategien der Synchronisation: (A) Anhalten von Threads vor kritischen Abschnitten (pessimistische Strategien) (B) Rücknahme von Effekten im Falle von Konflikten bzw. Kollisionen (optimistische Strategien) 17 Zeitpunkte der Synchronisation II Vor dem kritischen Abschnitt ("pessimistische" Strategie) Vor dem Betreten wird sichergestellt, dass später keine Probleme auftreten können. Beispiele: Semaphoren, Lock/Unlock Im kritischen Abschnitt ("optimistische" Strategie) Während der Aktivitäten innerhalb des kritischen Abschnittes wird auf Probleme geprüft. Gibt es sie, werden Verfahren durchgeführt, die den alten Zustand vor dem Konflikt wieder herstellen, und alles beginnt von vorn. Beispiele: Ethernet, Transaktionen (Datenbanken) Wir beschäftigen uns hier nur mit der ersten Gruppe. 18

10 Ebenen der Implementierungen Zusammengesetzte Mechanismen Komplexe Mechanismen Einfache Mechanismen Wir beginnen mit den einfachen Mechanismen und schreiten dann weiter in Richtung Komplexität voran. Einfach sind: Algorithmus nach Dekker Test-and-Set-Instruktionen zusammen mit Busy Waiting 19 Kritischer Abschnitt I Allgemeines Modell Code enter(klassenname);... Code Code... leave(klassenname); Code Prolog Verfahren zur Koordinierung Kritischer Abschnitt (grau) Epilog Verfahren zur Freigabe enter(klassenname): Betreten eines kritischen Abschnitts leave(klassenname): Verlassen eines kritischen Abschnitts 20

11 Kritischer Abschnitt II In den beiden Routinen enter() und leave() ist jeweils ein Verfahren implementert, das die Synchronisation realisiert. Die Parameter (Klassenname) von enter() und leave() beziehen sich auf die Klasse der kritischen Abschnitte. Implementierung (Ideen): Es gibt ein Modul/Klasse, das die beiden Operationen implementiert. Über den Parameter werden Variablen angesprochen, die für eine bestimmte Klasse stehen. Oder: Für jeden Abschnitt wird eine Klasse instanziiert, wobei dem Konstruktor der Name der Klasse übergeben wird. 21 Implementierungen von enter() und leave() Es gibt verschiedene Versionen für die Realisierungen, die jeweils Stärken und Schwächen haben. Es werden im folgenden zwei betrachtet: Algorithmus von Dekker Arbeiten mit speziellen Instruktionen Dies beginnt mit einer schrittweisen Entwicklung des Algorithmus von Dekker In den ersten Versionen sind Fehler, die in den späteren bereinigt werden. (siehe Bei diesen Algorithmen wird von zwei Threads und nur einem kritischen Abschnitt ausgegangen, so dass die Parameter für enter() und leave() wegfallen können, d.h. es gibt nur eine Klasse. In der Praxis muss für jede Klasse ein abstrakter Datentyp mit eigenen lokalen Variablen etc. benutzt werden. 22

12 Dekker's Algorithmus I 1. Versuch Thread A enter() { WHILE turn = B DO leave() { turn:= B; Thread B enter() { WHILE turn = A DO leave() { turn:= A; turn ist eine globale Variable, die initial auf A gesetzt ist. Jeder Thread gibt seinem Partner nach seiner Arbeit das Recht, den Abschnitt zu betreten echt fair. 23 Dekker's Algorithmus II - Beurteilung Sieht eigentlich ganz gut aus, aber... Problem 1: Wenn ein Thread außerhalb des kritischen Abschnittes terminiert wird, entstehen Deadlocks. Warum? Wenn die Variable turn den Wert A hat und der Thread A nicht mehr existiert, dann kann B nie wieder in den kritischen Abschnitt, denn B wartet auf etwas, was nie eintreten wird, nämlich dass A etwas tut. Die Idee des 2. Versuchs besteht darin, nicht mehr festzulegen, wer als nächstes eintreten kann, sondern wer eingetreten möchte. 24

13 Dekker's Algorithmus III - 2. Versuch Thread A enter() { A-will:= true; WHILE B-will DO leave() { A-will:= false; Thread B enter() { B-will:= true; WHILE A-will DO leave() { B-will:= false; Die beiden boole'schen Variablen A-will und B-will sind die Variablen der betrachteten Klasse; initial sind beide false. Sie können atomar gelesen und geschrieben werden. 25 Dekker's Algorithmus IV - Beurteilung Funktioniert ganz gut, aber... Problem 2: Es entstehen durch exakte Parallelität Deadlocks. A-will:= true; WHILE B-will DO parallel B-will:= true; WHILE A-will DO Idee: Die Deadlocks lassen sich durch zeitweises Zurücknehmen der Willenserklärung auflösen... 26

14 Dekker's Algorithmus V - 3. Versuch Thread A Thread B enter() { A-will:= true; WHILE B-will DO A-will:= false; // Chance für B A-will:= true; leave() { A-will:= false; enter() { B-will:= true; WHILE A-will DO B-will:= false; // Chance für A B-will:= true; leave() { B-will:= false; Wenn beide Threads aufgrund von Parallelität wie im vorherigen Fall - in enter() sind, dann können sie nur dann das Warten beenden, wenn einer von beiden sich im roten Bereich befindet und der andere zur WHILE-Abfrage kommt. 27 Dekker's Algorithmus VI - Beurteilung Bisher beste Lösung, aber... Problem 3: Es kann Verhungern auftreten. Warum? Wenn A viel schneller als B ist, dann nutzt A seine Chance nach der Freigabe durch B aus B muss dann warten. Wenn dann A den Abschnitt verlässt und dann gleich wieder betritt, kann nun auch wieder A sich aufgrund der höheren Geschwindigkeit gegenüber B durchsetzen Starvation für B. Idee: Das bisherige durch die Priorisierung aus dem 1. Versuch kombinieren, d.h. derjenige, der warten muss, hat beim nächsten Mal Priorität 28

15 Dekker's Algorithmus - Die beste Lösung Thread A enter() { A-will:= true; WHILE B-will DO IF turn = B THEN A-will:= false; WHILE turn = B DO A-will:= true; FI; leave() { turn:= B; A-will:= false; Thread B enter() { B-will:= true; WHILE A-will DO IF turn = A THEN B-will:= false; WHILE turn = A DO B-will:= true; FI; leave() { turn:= A; B-will:= false; 29 Bemerkungen Der vorgestellte Algorithmus hat die Eigenschaft, dass er bei N-CPUs funktioniert, d.h. immer jedenfalls unter den oben aufgeführten Annahmen (atomarer RAM-Zugriff etc.) dass der wartende Thread Zeit in einer Schleife vertrödelt dies wird auch hier Busy Waiting genannt. Busy Waiting = Aktives Warten = Vorgang, bei dem eine CPU auf das Eintreten eines Ereignisses dadurch wartet, dass sie in einer Endlos- Schleife abfragt, ob es eingetreten ist. (das gibt es auch bei I/O) Dijkstra hat diesen Algorithmus auf n Prozesse bzw. CPUs verallgemeinert. 30

16 Bemerkungen enter(obj) { lock(obj); leave(obj) { unlock(obj); Die Realisierung von enter() und leave() mit Implementierungen, die mit Busy Waiting arbeiten, werden auch lock() und unlock() genannt, manchmal auch spinlock genannt. Lock-Operation = spinlock = Realisierungen des Eintritts (Prolog) in einen kritischen Abschnitt mit Hilfe von Busy Waiting Neben dem Algorithmus von Dekker gibt es noch weitere Algorithmen, z. B. Bäckerei-Algorithmus von Lamport Peterson-Algorithmus Holländisch-Bier-Algorithmus von Lamport 31 Ununterbrechbare swap-instruktion In der Praxis wird mit speziellen Instruktionen gearbeitet, z.b.: Eine Swap-Operation tauscht den Inhalt zweier Speicherplätze ununterbrechbar durch andere CPUs/Geräte. Instruction Swap(a,b) { temp:= a; a:= b; b:= temp; enter(class) { crit:= true; WHILE crit DO Swap(crit,class); OD leave(class) { class:= false; 32

17 enter()/leave() auf einem 1-CPU-System I Bei 1-CPU-Maschinen kann ein Wechsel der CPU zu einem anderen Thread innerhalb des kritischen Abschnitts nur nach einen Interrupt erfolgen. Zur Erinnerung: Ein Interrupt-Handler kann den Scheduler aufrufen, der dann die CPU einem anderen Thread zuweist. Daher gibt es eine Nahe liegende, aber problematische Implementierung: enter(class) { disable_interrupts(); leave(class) { enable_interrupts(); Durch das Ausschalten der Unterbrechungen behält der aktuell laufende Thread in jedem Falle seine CPU und kann daher ungestört den kritischen Abschnitt durchlaufen. 33 enter()/leave() auf einem 1-CPU-System II Da das Ausschalten von Unterbrechungen zu Problemen aufgrund von Verlust von Interrupts führt, werden gezielt bestimmte Interrupt-Level (Prioritäten) verwendet: Die CPU erhält einen Level. Ein Interrupt kommt nur dann durch, wenn sein Level höher als der der CPU ist. Normalerweise ist der CPU-Level auf 0. Es wird dann nur soviel, wie unbedingt nötig gesperrt. Das Abschalten der Interrupts ist eigentlich falsch, denn es muss ja nur ein Threadwechsel sowie das Ändern von Daten in den kritischen Abschnitten verhindert werden. Und das kann auch durch globale Variablen bzw. Klassen-Variablen realisiert werden. 34

18 Alternative Implementierungen von enter/leave() enter()/leave() Busy Waiting 1..N CPUs Interrupts erlaubt Busy Waiting 1..N CPUs Spezialinstruktionen Interrupts erlaubt Kein Busy Waiting 1 CPU Interrupts verboten Dekker Spezialinstruktionen Disable Interrupts Wenn enter() und leave() mit einer dieser Methoden implementiert werden, so sollen diese Methoden lock() und unlock() genannt werden. 35 Nach dieser Anstrengung etwas Entspannung... 36