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

Transkript

1 1 Technische Informatik II (TI II) (7) Synchronisation Sebastian Zug Arbeitsgruppe: Embedded Smart Systems

2 2 Fragen an die Veranstaltung Warum bedarf es weitergehender Ansätze als die in der vergangenen Vorlesung beschriebenen Hard- und Softwaremethoden zum Schutz kritischer Abschnitte? Wo liegen die Nachteile des Semaphorkonzepts? Welche Formen des Semaphors sind Ihnen bekannt? Welchen Unterschied sehen Sie zwischen dem Konzept des Semaphors und dem des Monitors? Unter welchen Bedingungen kann ein Deadlock auftreten? Erläutern Sie die 4 Kriterien anhand eines alltäglichen Beispiels! Erläutern Sie das Vorgehen bei der Anwendung des Bankier-Algorithmus. Was beschreiben die verwendeten Matrizen? Welche Varianten werden bei der Deadlockerkennung und Deadlockvermeidung angewandt? Was versteht man unter einem sicheren/unsicheren Zustand? Welcher Idee folgt der Ansatz der Ressourcenspur? Wie lässt sich damit ein möglicher Deadlock erkennen?

3 3 Literatur Bücher Operating Systems Internals and Design Principles, Seventh Edition, William Stallings Modern Operating Systems (3rd Edition), Andrew Tanenbaum Webseiten

4 4 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 unterbricht P 1 P 0 möchte KA betreten, der von P 1 gesperrt ist. P 0 geht in seine aktive Warteschleife und verhindert, dass P 1 jemals den KA verlässt. P 1, niedrige Priorität Prioritätsumkehr P 1 betritt kritischen Abschnitt

5 5 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 (C.A.R.) Hoare, 1934)

6 6 Semaphor Tour du telegraphe Chappe Saverne Winkeralphabet "Semaphor griech. von sema (Zeichen) und pherein (tragen) Formsignale Eisenbahn

7 7 Semaphor als Schutzmechanismus Eingeführt durch Edsger Wybe Dijkstra (1965) Gleichermaßen für Reihenfolgensynchronisation und wechselseitigen Ausschluss geeignet Abbildung der verfügbaren Ressourcen auf eine integer Variable Wert kann auf nichtnegative Zahl initialisiert werden zwei atomare Operationen: - P() (hol. prolaag, erniedrige ) (auch wait, down oder acquire) verringert Wert um 1 falls Wert < 0: Thread blockieren - V() (hol. Verhoog, erhöhe ) (auch signal, up oder release) erhöht Wert um 1 falls Wert 0: einen blockierten Thread wecken zuteilen (dispatching) Aktivierung (activation) bereit unterbrechen (preemtion) ausführend Ende V(S) (signal S) blockiert P(S) (wait S)

8 8 Semaphore Initialisierung mit einem Wert 0: S=1 Operation wait (P): verringert den Wert eines Semaphors. S= S-1 Ist S < 0, wird der Prozess blockiert. signal (V): erhöht den Wert des Semaphors. S= S+1 Ist S 0, wird ein durch wait blockierter Prozess freigegeben. signal und wait sind atomare Operationen. Wert eines Semaphors: positiver Wert: Anzahl der zur Verfügung stehenden Betriebsmittel. negativer Wert: Anzahl der wartenden Prozesse.

9 9 sem 1 1 wait(sem) 0 A B C Wechselseitiger Ausschluss mit einem Semaphor 10-1 B wait(sem) -2 B C 10-2 BC C wait(sem) 10-1 signal(sem) Für jedes Betriebsmittel gibt es genau 1 Semaphor! 100 C signal(sem) 101 C signal(sem)

10 10 Semaphoroperationen struct Semaphor { int count; ThreadQueue queue; } Ressourcenvariable Queue der durch den kritischen Abschnitt blockierten Tasks void P(Semaphor &s) { s.count ; if (s.count < 0) { Thread in s.queue einlagern; Thread blockieren; } } void V(Semaphor &s) { s.count++; if (s.count <= 0) { Thread T aus s.queue entnehmen; Thread T als bereit markieren; } } Hinweis: Tanenbaum definiert Semaphore etwas anders (Zähler zählt höchstens bis 0 herunter) Abbildung der blockierten Threads

11 11 Semaphore Anwendung für Mutual Exclusion T 1 T 2 (P, wait, down) (V, signal, up) Wait (S k ) use resource S k signal (S k ) Ressource R k Wait (S k ) use resource S k signal (S k )

12 12 Semaphore Anwendung für Abhängigkeiten T 1 T 2 (V, signal, up) Erzeugen einer Datei signal (S k ) Datei Wait (S k ) Schreiben in Datei

13 13 Semaphor-Varianten Binäre Semaphore: Genau 1 Prozess darf in den KA eintreten. Alle anderen Prozesse werden in eine WS eingeordnet. Semaphor wird mit 1 initialisiert. struct binary_semaphore{ enum (ZERO, ONE) value; queuetype queue; }; void wait(binary_semaphore s){ if (s.value == ONE) s.value = ZERO; else{ diesen Prozess in s.queue ablegen; diesen Prozess blockieren;} } void signal(semaphore s){ if (s.queue.is empty()) s.value = ONE; else{ einen Prozess P aus s.queue entfernen; Prozess P in Liste bereiter Prozesse ablegen; } } Zählende Semaphore: Mehrere Prozesse dürfen in einen KA eintreten. Semaphor wird mit n initialisiert. Wird n überschritten, werden Prozesse in eine WS eingeordnet. struct semaphore{ int count; queuetype queue; }; void wait(semaphore s) { s.count--; if (s.count < 0) { diesen Prozess in s.queue ablegen; diesen Prozess blockieren } } void signal(semaphore s){ s.count++; if (s.count <= 0) { einen Prozess P aus s.queue entfernen; Prozess P in Liste bereiter Prozesse ablegen; } }

14 14 Semaphoren auf der Betriebssystemebene Eng verbunden mit Thread- Implementierung Bei Kernel-Threads: - Implementierung im BS- Kern - Operationen sind Systemaufrufe - atomare Ausführung durch Interrupt-Sperre und Spinlocks gesichert Zum Beispiel im Posix-Standard für Mutex-Operationen hinterlegt: // Initialisation pthread_mutex_init (mutex,attr), pthread_mutex_destroy (mutex) // Locking and Unlocking Mutexes pthread_mutex_lock (mutex), pthread_mutex_trylock (mutex) pthread_mutex_unlock (mutex) // Conditionen int pthread_cond_init (pthread_cont_t *cond, pthread_condaddr_t *attr); int pthread_cond_wait (pthread_cond_t *cond, pthread_mutex_t *mutex);

15 pthreadssemaphor.c #include<stdio.h> #include<string.h> #include<pthread.h> #include<stdlib.h> #include<unistd.h> pthread_t tid[2]; int counter; int maxcount= ; int value; pthread_mutex_t lock; void* dosomething(void *arg){ unsigned long i = 0; pthread_mutex_lock(&lock); counter += 1; printf("job %d started\n", counter); for(i=0; i<(maxcount);i++){ value++; } printf("job %d finished\n", counter); pthread_mutex_unlock(&lock); return NULL; } int main(void){ int i = 0; int err; } Technische Informatik II if (pthread_mutex_init(&lock, NULL)!= 0){ printf("mutex init failed\n"); return 1; } 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; 15

16 16 Ergebnis gcc -o pthreadssemaphorextern pthreadssemaphor.c lpthread Job 1 started Job 1 finished Job 2 started Job 2 finished Resulting value of value (intended ): Die beiden Threads werden korrekt ausgeführt! Die Ausführungsdauer liegt im Mittel bei 0.55s

17 pthreadssemaphor.c #include<stdio.h> #include<string.h> #include<pthread.h> #include<stdlib.h> #include<unistd.h> Technische Informatik II 17 pthread_t tid[2]; int counter; int maxcount= ; int value; pthread_mutex_t lock; void* dosomething(void *arg){ unsigned long i = 0; counter += 1; printf("job %d started\n", counter); for(i=0; i<(maxcount);i++){ pthread_mutex_lock(&lock); value++; pthread_mutex_unlock(&lock); } printf("job %d finished\n", counter); return NULL; } Probleme: 1. Overhead durch den Moduswechsel in den Kernel, bei jedem Aufruf der Mutex-Funktionen. 2. Counter Variable ist nicht mehr geschützt

18 18 Beurteilung Semaphore Zusammenfassung Allgemeines, leistungsfähiges Konzept zur Koordinierung nebenläufiger Prozesse. Kontrolle über die Anzahl von Prozessen, die eine Ressource nutzen wollen. Spezialfall: wechselseitiger Ausschluss. Kritik: wait und signal sind low level Programmierkonstrukte wait und signal können über das ganze Programm verteilt sein schwer zu kontrollieren Korrektheit schwer nachzuweisen

19 19 Monitore ist ein Modul, in dem die von Prozessen gemeinsam genutzten Daten und ihre Zugriffsprozeduren (oder Methoden) zu einer Einheit zusammengeführt sind. Zugriffsprozeduren mit kritischen Abschnitten auf den Daten werden als Monitor-Operationen speziell gekennzeichnet. Monitor-Operationen werden unter wechselseitigem Ausschluss ausgeführt, ohne dass im Programmcode Synchronisationsanweisungen notiert werden müssen. - bei erfolgreichem Prozeduraufruf sperrt der Monitor - bei Prozedurrückkehr wird der Monitor wieder entsperrt - ein Kompiler setzt die dafür notwendigen Anweisungen ab Vorteil: Keine direkte Adressierung von Schutzmechanismen im Programmcode

20 20 Monitor - Bedingungsvariablen Notwendig für die Reihenfolgensynchronisa tion zwischen Monitorprozeduren Definition eines Regelsatzes zur Entwurfszeit

21 21 Probleme Deadlock Verhungern eines Prozesses P Starvation = Verhungern = Ausführung von P undefiniert verzögert Es besteht Hoffnung P wird nicht zur Ausführung kommen, sofern kein Eingriff erfolgt Es besteht keine Hoffnung

22 22 Die speisenden Philosophen /* globaler semaphor initialisiert mit 1 */ Semaphor binsem = 1; /* Philosoph(i) (i=1...n, N=5 */ philosopher(i) { philosophise(); down(binsem); take_fork(i); take_fork((i + 1) % N); eat(); put_fork(i); put_fork((i + 1) % N); up(binsem); }

23 23 Typische Deadlock Situation im Straßenverkehr Deadlock möglich

24 24 Typische Deadlock Situation im Straßenverkehr Deadlockgefahr

25 25 Deadlockgefahr

26 26 Typische Deadlock Situation im Straßenverkehr Deadlock noch zu verhindern

27 27 Typische Deadlock Situation im Straßenverkehr Deadlock

28 28 Bedingungen für Deadlocks Wechselseitiger Ausschluss Jede Ressource ist entweder von exakt einem Prozess besetzt oder verfügbar. Behalten und Warten (Hold & Wait) Prozesse, die bereits bestimmte Ressourcen belegen, können weitere nachfordern. Keine Unterbrechung Ein Prozess kann eine Ressource nur freiwillig wieder abgeben, es ist kein Entzug von Ressourcen von außen möglich Zyklisches Warten Zwei Prozesse fordern Ressourcen an, die vom jeweils anderen belegt sind. Designentscheidungen dynamisch entstehende Situation

29 29 Typische Deadlock Situation im Straßenverkehr Deadlock

30 30 Modellieren von Deadlocks mittels Graphen A hält die Ressource R B fordert die Ressource S an Deadlock

31 31 Beispiel Processes Ressourcen Deadlock! Deadlock frei!

32 Source: Technische Informatik II 32 Strategien zum Umgang mit Deadlocks 1.Ignorieren (Vogel-Strauß-Ansatz) 2.Erkennen und Behandeln. 3.Dynamisch vermeiden durch vorsichtige Belegung von Ressourcen. 4.Verhindern, indem man erreicht, dass eine der 4 Bedingungen nicht eintreten kann.

33 33 2a Deadlocks erkennen Eine Ressource pro Typ Zyklusidentifikation mittels Baumsuche: 1. Initialisiere eine Liste der bereits erreichten Knoten L 2. Vermerke alle Kanten als unmarkiert 3. Wiederhole bis ein Knoten mehrmals in der Liste vorkommt oder alle Kanten markiert sind: a) Schreibe den aktuellen Knoten in L b) Überprüfe ob vom aktuellen Knoten unmarkierte Kanten wegführen c) Wenn ja, wähle zufällig eine aus und markiere sie. Der folgende Knoten wird zum aktuellen Knoten.

34 34 2a Deadlocks erkennen Mehrere Ressourcen pro Typ M Ressourcen, n Prozesse Ressourcenvektor Verfügbarkeitsvektor Ressource 1 Belegungsmatrix (C) Ressource m Prozess 1 Anforderungsmatrix (R) Prozess n Invariante für die Ressourcenverteilung: n i=1 C ij + A j = E j

35 35 Beispiel - Beziehungen Ressourcenvektor (E) P1 P2 Belegungsmatrix Anforderungsmatrix R1 R2 R3 R1 R2 R P P Verfügbarkeitsvektor (A) Zuteilungsvektor n i=1 C ij + A j = E j i: Prozess j: Ressource SC i,1 + A 1 = 3 +1 = E 1 = 4 SC i,2 + A 2 = 6 +0 = E 2 = 6 SC i,3 + A 3 = 2 +0 = E 3 = 2

36 36 2a Deadlock-Erkennungsmechanismus Sei die Relation auf der Menge der Vektoren definiert als: A B genau dann wenn A i B i für alle i mit 1 i n Der Deadlock-Erkennungsalgorithmus läuft folgendermaßen ab: 1. Suche einen unmarkierten Prozess P i, für den die i-te Zeile von R kleiner oder gleich A ist. 2. Wenn ein solcher Prozess existiert, addiere die i-te Zeile von C zu A, markiere den Prozess und gehe zu Schritt Andernfalls beende den Algorithmus. Wenn der Algorithmus beendet ist, sind alle nicht markierten Prozesse an einem Deadlock beteiligt.

37 37 Deadlock Situationen P1 P2 P3 P4 Belegungsmatrix (C) R1 R2 R Anforderungsmatrix (R) R1 R2 R3 P P P P Ressourcenvektor (E) Verfügbarkeitsvektor (A) Deadlock!!

38 38 2b Deadlocks behandeln Ansatz Idee Umsetzbarkeit Unterbrechung eines Prozesses und zeitweiser Entzug von Ressourcen Zurücksetzen und Wiederholen (Rollback) Abbruch eines oder mehrerer Prozesse Manuelles Vorgehen Einführung von Checkpoints, die als Wiedereinsprungstellen dienen Schwierig Overhead notwendig Auswahl eines geeigneten Prozesses schwierig

39 39 3. Deadlockvermeidung Sichere / unsichere Zustände Erkennung sicherer und unsicherer Zustände Def.: Ein sicherer Zustand ist ein Zustand, von dem aus mindestens eine Ausführungsreihenfolge existiert, die nicht zu einem Deadlock führt, d.h. alle Prozesse können bis zum Abschluss ablaufen. Anmerkung: ein unsicherer Zustand muss nicht zwangsläufig in eine Verklemmung führen es müssen ja nicht alle Prozesse (sofort) ihre Maximalforderungen stellen!

40 40 3. Deadlockvermeidung - Ressourcenspur Grafische Darstellung der Belegungssituation einer Ressource über der Zeit. Verbotene Bereiche illustrieren einen mehrfachen Zugriff auf die Ressource Ziel: Gültigen Pfad zwischen Koordinaten Ursprung und rechts oben finden

41 41 3. Deadlockvermeidung Bankieralgorithmus Durch angepassten Matrix-Algorithmus zur Deadlock-Erkennung Der aktuelle Zustand des Systems ist durch E, A und C beschrieben vorhandene, freie und belegte Ressourcen, R beschreibt nun die maximalen zukünftigen Forderungen Der Zustand ist genau dann sicher, wenn der Algorithmus für diese Werte von E, A, C und R keine Verklemmung erkennt. Bankier-Algorithmus (Dijkstra 1965): 1. Suche eine Zeile in R, die kleiner oder gleich A ist. Wenn es keine solche Zeile gibt, kann kein Prozess beendet werden --> unweigerlich Deadlock. 2. Prozess kann alle notwendigen Ressourcen reservieren und terminieren. Markiere den Prozess als beendet und addiere Ressourcen zu A. 3. Wiederholung von 1 und 2 bis alle Prozesse markiert sind oder Deadlocksituation erkannt wird.

42 42 3. Deadlockvermeidung Bankieralgorithmus BS teilt Ressource nur dann zu, wenn dadurch auf keinen Fall ein Deadlock entstehen kann dazu: BS prüft bei jeder Ressourcenanforderung, ob der Zustand nach der Anforderung noch sicher ist falls ja, wird die Ressource zugeteilt falls nein, wird der anfordernde Prozess blockiert sehr vorsichtige (restriktive) Ressourcenzuteilung! Voraussetzung: Der Bankieralgorithmus muss dazu die (maximalen) zukünftigen Forderungen aller Prozesse kennen! in der Praxis i.a. nicht erfüllbar Verfahren nur für spezielle Anwendungsfälle tauglich

43 43 4. Deadlock Verhinderung Problem Wechselseitiger Ausschluss Hold & Wait Ununterbrechbarkeit Zyklisches Warten Versuch der Problemlösung Keine generelle Lösung! Ressourcen alle auf einmal anfordern Ressourcen wegnehmen Ressourcen nummerieren

44 44 Zusammenfassung: Nebenläufigkeit und Synchronisation Interprozesskommunikation (IPC) erfordert Datentransfer und Synchronisation. Wechselseitiger Ausschluss und kritischer Abschnitt. Dekker's Algorithmus als Softwarelösungen und Unterstützung durch unteilbare (Maschinen-) Operationen. Das Semaphorkonzept von Djikstra als leistungsfähiger Synchronisationsmechanismus. Nebenläufigkeitsprobleme Deadlock (Verklemmung) und Starvation (Verhungern). Auslöser: Wechselseitiger Ausschluss, Besitzen und Warten, kein Ressourcenentzug, zyklisches Warten. Erkennung und Vermeidung von Deadlocks. Bankiersalgorithmus und sichere Zustände.

45 45 Bis zur nächsten Woche