Technische Informatik II (TI II) (6) Synchronisation. Sebastian Zug Arbeitsgruppe: Embedded Smart Systems

Transkript

1 Jun-Prof Dr Sebastian Zug Technische Informatik II (TI II) (6) Synchronisation Sebastian Zug Arbeitsgruppe: Embedded Smart Systems

2 Jun-Prof Dr Sebastian Zug Fragen an die Veranstaltung Beschreiben Sie Beispiele, die eine Synchronisation nebenläufiger Prozesse erfordern Erklären Sie die Notwendigkeit für zwei Kontrollvariablen im Algorithmus von Dekker Beschreiben Sie die Vorgänge beim Livelock, Deadlock, beim Verhungern eines Prozesses und beim Blockieren Fassen Sie die Nachteile der intuitiven Lösungen, wie sie beim Einführungsbeispiel und bei der Diskussion zum Schutz der kritischen Abschnitte genannt wurden, zusammen Welche Anforderungen werden an eine Test&Set-Methode gestellt, die helfen soll, einen kritischen Abschnitt zu schützen Welche Nachteile gehen mit der notwendigen Einführung kritischer Abschnitte einher?

3 Jun-Prof Dr Sebastian Zug Literatur Bücher Operating Systems Internals and Design Principles, Seventh Edition, William Stallings Modern Operating Systems (3rd Edition), Andrew Tanenbaum Webseiten Dr David Sabel (Goethe-Universität, Frankfurt am Main)

4 Jun-Prof Dr Sebastian Zug Who will buy the milk? Einführendes Beispiel (WG-Szenario): Alice und Bob teilen sich einen Kühlschrank Sie wollen, dass stets genug Milch im Kühlschrank ist Es gilt aber auch zu viele Milchflaschen im Kühlschrank zu vermeiden Kooperativer Ansatz: Wer bemerkt, dass keine Milch mehr da ist, macht sich auf den Weg in den Supermarkt Zeit Alice Bob 17:00 Kommt nach Hause 17:05 Bemerkt fehlende Milch 17:10 Geht zum Einkaufsmarkt 17:15 Kommt nach Hause 17:20 Bemerkt fehlende Milch 17:25 Geht zum Einkaufsmarkt

5 Jun-Prof Dr Sebastian Zug Who will buy the milk? Lösungskonzept: Alice und Bob stimmen sich über Notizen am Kühlschrank ab Annahmen: nicht nur eine Person darf einkaufen gehen Alice und Bob können sich nicht sehen, dh sie kommunizieren nur über die Notizen

6 Jun-Prof Dr Sebastian Zug 1 Lösungsversuch Algorithmus: Wenn keine Notiz am Kühlschrank und keine Milch im Kühlschrank ist, dann schreibe Notiz an den Kühlschrank, gehe Milch kaufen, stelle die Milch in den Kühlschrank und entferne danach die Notiz Problem: Ergebnis: A1 A2 B1 B2 zu viel Milch

7 Jun-Prof Dr Sebastian Zug 2 Lösungsversuch Algorithmus: Hinterlasse als erstes eine Notiz am Kühlschrank, dann prüfe ob eine Notiz des anderen vorhanden ist Nur wenn keine weitere Notiz vorhanden ist, prüfe ob Milch vorhanden ist und gehe Milch kaufen, wenn keine Milch vorhanden ist Danach entferne die Notiz Problem: Ergebnis: A1 B1 A2 B2 Blockieren (Livelock) Möglicherweise wird keine Milch gekauft

8 Jun-Prof Dr Sebastian Zug 3 Lösungsversuch Alice: Schreibe Notiz, wenn keine Notiz von Bob, prüfe ob Milch vorhanden und gehe Milch kaufen Entferne Notiz Bob: Schreibe Notiz, warte bis keine Notiz von Alice am Kühlschrank hängt, dann prüfe, ob Milch leer ist, gehe Milch kaufen, entferne eigene Notiz Problem: Ergebnis: A1 - B1 - B2 - A2 - A5 - A1 - B2 beliebig oft Möglicherweise wird keine Milch gekauft A B Milchholer X Alice dc Bob dc = dont care

9 Jun-Prof Dr Sebastian Zug Korrekte Lösung Algorithmus: Zweite Variable, die jeweils kreuzweise geschrieben und gelesen wird

10 The computer science and engineering research study, MIT Press, 1980 Technische Informatik II Jun-Prof Dr Sebastian Zug Konsequenzen für ein Rechnersystem Prozessinteraktion funktionale Aspekte wie findet der Informationsaustausch statt? - Nachrichtenorientiert - gemeinsamer Speicher zeitliche, ablaufspezifische Aspekte wie wird der Informationsaustausch synchronisiert? wie werden generell nebenläufige Aktivitäten synchronisiert? Kommunikation + Koordination = Kooperation Designing correct routines for controlling concurrent activities proved to be one of the most difficult aspects of systems programming The ad hoc techniques used by programmers [ ] were always vulnerable to subtle programming errors whose effects could be observed only when certain relatively rare sequences of actions occurred

11 Jun-Prof Dr Sebastian Zug pthreads_without_mutualexclusionc #include<stdioh> #include<stringh> #include<pthreadh> #include<stdlibh> #include<unistdh> pthread_t tid[2]; int counter; int maxcount= ; int value; void* dosomething(void *arg){ unsigned long i = 0; counter += 1; printf("job %d started\n", counter); for(i=0; i<(maxcount);i++){ value++; printf("job %d finished\n", counter); return NULL; int main(void){ int i = 0; int err; while(i < 2) { err = pthread_create(&(tid[i]), NULL, &dosomething, NULL); if (err!= 0) printf("%s", strerror(err)); i++; pthread_join(tid[0], NULL); pthread_join(tid[1], NULL); printf("\n Value of value \n"); printf (intended %d): %d\n", i*maxcount, value); return 0;

12 Jun-Prof Dr Sebastian Zug Ergebnis gcc -o pthreads_without_mutualexclusion pthreads_without_mutualexclusionc -lpthread /pthreads_without_mutualexclusion Job 1 started Job 2 started Job 2 finished Job 2 finished Resulting value of value (intended ): Problem: Nebenläufigkeit + Nutzung gemeinsamer Daten, dh die Prozesse interagieren miteinander-> Asynchronität durch mehrere Prozessoren oder durch systembezogene Unterbrechungen Gefordertes Verhalten: Die Ergebnisse eines Prozesses müssen unabhängig von der eigenen Ausführungsgeschwindigkeit und der anderer nebenläufiger Prozesse sein Mechanismus: Synchronisation

13 Serialisierung der Ausführung Intuitiver Gedanke: Der Bereich des Programmes, der für den Zugriff auf die Ressource globale Variable verantwortlich ist, wird koordiniert Lediglich ein Programm darf zeitgleich Lese- oder Schreiboperationen ausführen Wechselseitiger Ausschluss (Mutual Exclusion) #include<stdioh> #include<stringh> #include<pthreadh> #include<stdlibh> #include<unistdh> Jun-Prof Dr Sebastian Zug pthreads_without_mutualexclusionc pthread_t tid[2]; int counter; int maxcount= ; int value; void* dosomething(void *arg){ unsigned long i = 0; counter += 1; printf("job %d started\n", counter); for(i=0; i<(maxcount);i++){ value++; printf("job %d finished\n", counter); return NULL;

14 Jun-Prof Dr Sebastian Zug Resultierende Herausforderungen Blockieren Prozess P 1 belegt ein Betriebsmittel, ein zweiter Prozess P 2 benötigt dasselbe Betriebsmittel und blockiert P 1 Verhungern (Starvation) Ein Prozess ist rechenbereit, gelangt aber nicht zur Ausführung, andere Prozesse werden aber vorgezogen (höherer Priorität) Deadlock Zwei oder mehr Prozesse halten Ressourcen belegt und versuchen weitere zu erlangen Liegt ein Zyklus von Abhängigkeiten vor, so kommt das System zum Stillstand

15 Jun-Prof Dr Sebastian Zug Interaktionsformen

16 Jun-Prof Dr Sebastian Zug Datenkohärenz (Bindungen) Buchführungsprogramm: Verhältnis zwischen a und b soll aufrecht erhalten werden Ausführungsreihenfolgen: P1: a = a + 1 b = b + 1 P2: b = 2 * b a = 2 * a a = a + 1 b = b + 1 b = 2 * b a = 2 * a b = 2 * b a = 2 * a b = b + 1 a = a + 1 a = a + 1 b = 2 * b b = b + 1 a = 2 * a Für jede Variable wird der wechselseitige Ausschluss befolgt Trotzdem entspricht das Ergebnis keinem Ergebnis, das ohne Nebenläufigkeit erzielt werden kann!

17 Wechselseitiger Ausschluss (Mutual Exclusion) Jun-Prof Dr Sebastian Zug Zielstellung: Konsistenz einer Ausführung Das Ergebnis einer Ausführung von nebenläufigen, unabhängigen Prozessen ist konsistent, wenn es durch irgendeine strikt aufeinanderfolgende Ausführung der Prozesse erreicht wird Forderung: Garantieren des exklusiven Zugriffs für längere Befehlssequenzen -> Konzept des kritischen Abschnitts ist ein Codeabschnitt, der zu einer Zeit nur durch einen Prozess oder Thread durchlaufen und in dieser Zeit nicht durch andere nebenläufige Prozesse oder Threads betreten werden darf

18 Jun-Prof Dr Sebastian Zug Kritischer Abschnitt /* Programm Wechselseitiger Ausschluss */ const int n /* Anzahl der Prozesse */ void P(int i) { while (true) { entercritical (i); /* Prolog zur Steuerung der Zugangskontrolle */ /* kritischer Abschnitt */; exitcritical (i); /*Epilog zur Steuerung der Zugangskontrolle*/ / * Restliche Programmzeilen * /; void main ( ) { parbegin (P 1, P 2,, P n );

19 Jun-Prof Dr Sebastian Zug Mutual Exclusion Bedingungen und Lösungsansätze 1Nur ein Prozess darf den kritischen Bereich zu einem Zeitpunkt betreten haben 2Das Verhalten eines Prozesses im nicht-kritischen Bereich darf die anderen Prozesse nicht beeinflussen 3Es werden keine Annahmen über die relative Ausführungsgeschwindigkeit der Prozesse, ihre Anzahl oder die Anzahl der Prozessoren gemacht Lösungsansätze: Interrupts sperren Softwarekonzepte für das Setzen und Sperren kritischer Abschnitte Hardwareunterstützung durch spezielle Maschinenbefehle 4Ein Prozess bleibt nur endliche Zeit in einem KA 5Wenn sich kein anderer Prozess im KA befindet, muss der Zugang ohne Verzögerung gewährt werden

20 Jun-Prof Dr Sebastian Zug Interrupts sperren while (1){ /* non-critical section */ /* disable interrupts */ local_irq_disable(); /* critical section */ local_irq_enable() /* enable interrupts */ /* disable interrupts */ /* remainder */ Prinzip: Stoppen aller Unterbrechungen Probleme: Verpassen von Interrupts notwendige Nutzerrechte problematisch Beschränkte Effizienz des Prozessors nicht anwendbar bei Multiprozessoren

21 Jun-Prof Dr Sebastian Zug Softwarelösung Versuch 1 Globale Variable zur Kontrolle des Zuganges: int turn /* Prozess 0 */ while (turn!=0) */ do nothing*/; /* critical section */ turn = 1; /* Prozess 1 */ while (turn!=1) */ do nothing*/; /* critical section */ turn = 0; Prinzip: Freiwillige Abgabe der Kontrolle über den kritischen Abschnitt Probleme: Aktives Warten, Streng alternierend; langsamer Prozess bestimmt die Periode Bei Ausfall eines Prozesses (auch außerhalb des kritischen Abschnitts) kann der kritische Abschnitt nicht mehr betreten werden

22 Jun-Prof Dr Sebastian Zug Softwarelösung Versuch 2 Globale Variable : enum boolean {false = 0; true = 1 boolean flag[2] = {false, false /* Prozess 0 */ while (flag[1]) */ do nothing*/; flag[0]= true; /* critical section */ flag[0]= false; /* Prozess 1 */ while (flag[0]) */ do nothing*/; flag[1]= true; /* critical section */ flag[1]= false; Prinzip: selbstbestimmte Reihenfolge der Ressourcenanforderung Probleme: kein wechselseitiger Ausschluss gewährleistet!

23 Jun-Prof Dr Sebastian Zug Softwarelösung Versuch 2 /* Prozess 0/1 */ while (flag[1/0]) */ do nothing*/; flag[0/1] = true; /* critical section */; flag[0/1] = false; flag 0 flag 1 Flag des anderen Prozesses lesen und das eigene ändern geschieht nicht atomar! true false

24 Jun-Prof Dr Sebastian Zug Softwarelösung - 3 Versuch gemeinsam benutzte globale Variable: enum boolean {false = 0; true = 1 boolean flag[2] = {false, false /* Prozess 0 */ flag[0]=true; while (flag[1]) */ do nothing*/; /* critical section */ flag[0]= false; /* Prozess 1 */ flag[1]=true; while (flag[0]) */ do nothing*/; /* critical section */ flag[1]= false; Prinzip: Flag-Überprüfung innerhalb des kritischen Bereiches Probleme: Bei Ausfall innerhalb des kritischen Abschnitts: Blockade Falls beide Prozesse die Flags auf "true" setzen: Deadlock (Verklemmung)

25 Jun-Prof Dr Sebastian Zug Softwarelösung - 3 Versuch while (flag[1]) /* do nothing*/ while (flag[0]) /* do nothing*/ /* Prozess 0/1 */ flag[0/1] = true; while (flag[1/0]) */ do nothing*/; /* critical section */; flag[0/1] = false; flag 0 flag 1 true false

26 Jun-Prof Dr Sebastian Zug Softwarelösung 4 Versuch gemeinsam benutzte globale Variable: enum boolean {false = 0; true = 1 boolean flag[2] = {false, false /* Prozess 0 */ flag[0]=true; while (flag[1]) { flag[0]=false; */ delay*/; flag[0]=true; /* critical section */ flag[0]= false; /* Prozess 1 */ flag[1]=true; while (flag[0]) { flag[1]=false; */ delay*/; flag[1]=true; /* critical section */ flag[1]= false; Prinzip: Zufällige Auflösungen von Deadlocks mit Timerablauf Probleme: Bei Ausfall innerhalb des kritischen Abschnitts: Blockade Falls kein Prozesse "nachgibt": Lifelock (Dynamische Verklemmung)

27 Jun-Prof Dr Sebastian Zug Softwarelösung 4 Versuch flag 0 flag 1 /* Prozess 0/1 */ flag[0/1] = true; while (flag[1/0]) { flag[0/1] = false; /* delay */; flag[0/1] = true; /* critical section */; flag[0/1] = false; true false

28 Jun-Prof Dr Sebastian Zug Dekkers Algorithmus boolean flag [2]; int turn; void main 0 { flag [0] = false; flag [1] = false; turn = 1; parbegin (P0, Pl); void P0() { while (true) { flag [0] = true; while (flag [1]) if (turn == 1) { flag [0] = false; while (turn == 1) / * do nothing */ flag [0] = true; /* kritischer Abschnitt turn = 1; flag [0] = false; / * Restliche Programmzeilen * /; void P1() { while (true) { flag [1] = true; while (flag [0]) if (turn == 0) { flag [1] = false; while (turn == 0) / * do nothing */ flag [1] = true; / * kritischer Abschnitt turn = 0; flag [1] = false; / * Restliche Programmzeilen

29 Jun-Prof Dr Sebastian Zug Dekker's Algorithmus flag 0 flag 1 1 turn true false

30 Jun-Prof Dr Sebastian Zug Dekker's Algorithmus flag 0 flag 1 10 turn true false

31 Jun-Prof Dr Sebastian Zug Dekker's Algorithmus flag 0 flag 1 10 turn true false

32 Jun-Prof Dr Sebastian Zug Dekkers Algorithmus [Theodorus Dekker] niederländischer Mathematiker Historisch der erste Algorithmus, der eine vollständige Lösung des wechselseitigen Ausschlusses umsetzt gegenseitige Blockierung und Monopolisierung des kritischen Abschnitts durch einen Prozess wird verhindert Problem: Erweiterung auf n Prozesse Verbesserung durch den Petterson und Kessel Algorithmus Gebraucht wird ein Algorithmus wie der Peterson-Algorithmus eigentlich nur zur Realisierung von wechselseitigem Ausschluss auf einem Computersystem mit zwei Prozessoren, die keine Instruktion wie Test-andset oder Compare-and-swap haben

33 Jun-Prof Dr Sebastian Zug Hardwareunterstützung Herausforderung: static int lock_var; int main(){ while (lock_var!= 0); lock_var = 1; /* kritischer Abschnitt */ /* */ 0x4004ed <+0>: push %rbp 0x4004ee <+1>: mov %rsp,%rbp 0x4004f1 <+4>: nop 0x4004f2 <+5>: mov 0x200b44(%rip),%eax # 0x60103c <lock_var> 0x4004f8 <+11>: test %eax,%eax 0x4004fa <+13>: jne 0x4004f2 <main+5> 0x4004fc <+15>: movl $0x1,0x200b36(%rip) # 0x60103c <lock_var> 0x <+25>: pop %rbp 0x <+26>: retq Gesucht: Varianten: Möglichkeit zur Umsetzung innerhalb einer nichtunterbrechbaren Operation TAS Befehle Test & Set, Compare & Swap, Exchange (x86)

34 void main(){ flag = 0; parbegin (P(1), P(2),,P(n)); Technische Informatik II Wechselseitiger Ausschluss mit Test and Set const int n = int flag; Jun-Prof Dr Sebastian Zug /* number of processes*/ boolean testset (int *i){ if (*i==0){ *i = 1; return true; else{ return false; /* als atomar angenommen!*/ void P(int i){ while (true){ while (!testset (&flag)) /* do nothing */; /* critical section*/ flag = 0; /* remainder*/

35 Wechselseitiger Ausschluss mit Exchange xchg src, dest The xchg instruction swaps the src operand with the dest operand If one of the operands is a memory address, then the operation has an implicit LOCK prefix, that is, the exchange operation is atomic This can have a large performance penalty It's also worth noting that the common NOP (no op) instruction, 0x90, is the opcode for xchgl %eax, %eax const int n = int flag; Jun-Prof Dr Sebastian Zug /* number of processes*/ void exchange(int *register, int *memory){ int temp; temp = *memory; *memory = *register; *register = temp; /* als atomar angenommen!*/ void P(int i){ int keyi = 1; while (true){ do exchange(&keyi, &flag) while (keyi!= 0); /* critical section*/ flag = 0; /* remainder*/ void main(){ flag = 0; parbegin (P(1), P(2),,P(n));

36 Jun-Prof Dr Sebastian Zug Was wurde bisher erreicht? Ziel: Erhaltung der Konsistenz von Daten trotz nebenläufigen Zugriffs, sei es durch Multiprogramming oder Multiprocessing Zur Manipulation der Daten müssen Befehlssequenzen (und nicht nur einzelne Befehle) atomar ausgeführt werden Die Algorithmen von Dekker und Peterson bieten korrekte Lösungen Hardwareunterstützung vereinfacht und verbessert die reinen Softwarelösungen Probleme?

37 Jun-Prof Dr Sebastian Zug Probleme der bisherigen Lösungen aktives Warten vollständig auf Anwendungsebene konzipierter Mechanismus keine Garantie gegen Verhungern Verklemmungen können auftreten P 0, hohe Priorität P 0 möchte KA betreten, der von P 1 gesperrt ist P P 0 unterbricht P 0 geht in seine 1 aktive Warteschleife und verhindert, dass P 1 jemals den KA verlässt P 1, niedrige Priorität P 1 betritt kritischen Abschnitt

38 Jun-Prof Dr Sebastian Zug Weitergehende Zielstellungen Einbettung des Konzepts in das Betriebssystem oder in die Programmiersprache Allgemeiner Mechanismus für die "Kooperation sequentieller Prozesse" Kein aktives Warten mehr Leicht zu verstehen und zu handhaben Semaphore (1965, Edsger W Dijkstra, ) Monitore (1974, Sir Charles Antony Richard (CAR) Hoare, 1934)

39 Jun-Prof Dr Sebastian Zug Bis zur nächsten Woche