Übung zu Grundlagen der Betriebssysteme. 9. Übung

Transkript

1 Übung zu Grundlagen der Betriebssysteme 9. Übung

2 Wechselseitiger Ausschluss Wechselseitiger Ausschluss: 1) Softwareansätze Dekker-Algorithmus Peterson-Algorithmus 2) Unterstützung durch Hardware Interrupt-Sperrung Spezielle Maschinenbefehle 3) Semaphore 4) Monitore

3 Wechselseitiger Ausschluss Wechselseitiger Ausschluss: 1) Softwareansätze Dekker-Algorithmus komplexe Programmierung Peterson-Algorithmus Verhungern ist möglich P1 P2 aktives Warten

4 Wechselseitiger Ausschluss 2) Unterstützung durch Hardware Interrupt-Sperrung while(true){ Funktioniert nur mit Einprozessorrechner Verhungern ist möglich /* Interrupts sperren */ /* kritischer Abschnitt*/ /* Interrupts freischalten */ /* sonstiges */ Prozessor wird eingeschränkt die Prozesse im Wec Spezielle Maschinenbefehle single atomic (non-interruptable) Auf Hardwareebene wird der Zugriff auf eine Speicherstelle verhindert, wenn bereits Zugriff auf diese Speicherstelle erfolgt. zwei Aktionen auf einer einzelnen Speicherzelle werden atomar und nur mit einem Befehlszyklus durchgeführt. (z.b.: Lesen+Schreiben, Lesen+Prüfen) test-and-set compare-and-swap aktives Warten Verhungern ist möglich es kann trotzdem noch zu Verklemmungen kommen

5 Wechselseitiger Ausschluss 3) Semaphore Zeichenträger bestehen im wesentlichen aus: - einer Zählvariable (COUNT), - Warteschlange für Prozesse, - Mechanismus des Schlafens und Aufweckens (DOWN oder P(); UP oder V()).

6 Wechselseitiger Ausschluss 3) Semaphore COUNT => gibt Wert des Semaphors an. = 0 kein Wecksignal ist zu berücksichtigen DOWN => P()-Operation Verallgemeinerung von sleep() atomare Aktion wenn COUNT > 0 wird um 1 verringert. wenn COUNT = 0 ausführender Prozess wird schlafen gelegt UP => V()-Operation Verallgemeinerung von wakup() atomare Aktion falls es schlafende Prozess gibt, wird einer ausgewählt und dessen DOWN- Operation beendet

7 Wechselseitiger Ausschluss UNIX/Linux C-Bibliotheken für Semaphore: Unter Unix/Linux gibt es zwei verschiedene System-Bibliotheken für Semaphore: POSIX und System V. Beide haben die selbe Funktion: den wechselseitigen Ausschluss ermöglichen. Die System V Variante wird von älteren Unix-basierten Systemen unterstützt. Diese Variante ist etwas komplizierter zu implementieren. Man findet Sie aber häufig in Code-Beispielen in denen mehrere Prozesse (fork) auf einen kritischen Bereich zugreifen. Aktuelle Linux-Systeme unterstützen normalerweise POSIX und System V Bibliotheken. Die POSIX-Bibliothek wird häufig in Code-Beispielen verwendet, in denen mehrere Threads eines Prozesses auf einen krititschen Bereich zugreifen wollen.

8 Wechselseitiger Ausschluss UNIX/Linux System-Bibliotheken für Semaphore: Bsp. System V Semaphor sharedmemsemsysv.c (man semget, man semop, ) #include <sys/sem.h> semget legt eine neue Semaphorengruppe an oder greift auf eine bereits bestehende Gruppe zu. semop ändert die Werte der Semaphore einer Gruppe semctl führt verschiedene Steuerungsfunktionen auf Semaphoren durch

9 Wechselseitiger Ausschluss UNIX/Linux System-Bibliotheken für Semaphore: Bsp. POSIX Semaphor sharedmemsemposix.c (man sem_overview, man sem_open, man sem_init, ) sem_t legt ein semaphor an #include <semaphore.h> #include <fcntl.h> sem_open (named semaphores) liefert einen systemweiten Semaphor zurück auf den mehrere Prozesse zugreifen können. sem_init (unamed semaphores) initialisiert einen prozesseigenen Semaphor auf den die Threads eines Prozesses zugreifen können. sem_wait dekrementiert (lock) den übergebenen semaphor sem_post inkrementiert (unlock) den übergebenen Semaphor sem_destroy löscht unamed semaphores sem_close schließt named semaphores sem_unlink löscht unamed semaphores aus dem System

10 Shared Memory Systembefehle für Shared Memory #include <sys/shm.h> shmget (allocates shared memory) legt ein neues Segment an bzw. greift auf ein bestehendes Segment zu. shmat (shared memory attach) hängt ein Shared Memory-Segment an den Adressraum eines Prozesses an. shmdt (shared memory detach) entfernt ein Shared Memory-Segment aus dem Adressraum des aufrufenden Prozesses. shmctl (shared memory control) führt Steuerungsfunktionen auf einem Shared Memory-Segment durch.

11 Monitore Bisherige Synchronisationskonstrukte fordern die Einhaltung der Ablauffolge der Systembefehle. Systembefehle müssen an der richtigen Stelle im Programm stehen sonst Fehleranfällig Sichere Programmierung von Nebenläufigkeit erfordert, dass typische Entwurfsmusster erkannt werden und nach Möglichkeit höhere Bibliothekskonstrukte und Frameworks genutzt werden.

12 Monitore Monitore bestehen aus Prozeduren, Variablen und Datenstrukturen, die als Modul zusammengefasst sind und besitzen die folgenden Eigenschaften: Prozesse können Prozeduren des Monitors aufrufen, aber sie können nicht auf die interne Datenstruktur eines Monitors zugreifen. Nur ein Prozess kann zur selben Zeit in einem Monitor aktiv sein. Monitore sind Konstrukte einer Programmiersprache Höhere Synchronisationsmechanismen Compiler kann mit Monitorprozeduren umgehen und wechselseitigen Ausschluss garantieren! Programmierer muss dafür sorgen das kritische Bereiche in Monitorprozeduren eingebettet sind.

13 Monitore Ein Java-Monitor ist ein Objekt, das einerseits mittels einer Sperre (lock) den Schutz kritischer Gebiete ermöglicht, und andererseits über eine oder mehrere Wartelisten das Warten auf Bedingungen (condition) ermöglicht. Das Warten auf eine Bedingung ist im Monitor immer mit der Sperre koordiniert: Während des wartens wird die Sperre freigegeben und muss anschließend wieder erlangt werden. Synchronisationsprimitive in Java synchronized(monitorobject){ geschützter Bereich nur ein einziger Thread darf mit einem Monitorobjekt den mit synchronized geschützten Bereich betreten!

14 Monitore Ein wartender Thread, der aufgeweckt wurde ist noch nicht ausführungsbereit Er kann erst dann fortgesetzt werden, wenn die durch wait() abgegebene Sperre wieder verfügbar ist. Synchronisationsprimitive in Java synchronized(monitorobject){ geschützter Bereich Für das Warten auf Ereignisse definiert die Klasse Object die Methoden Wait, notify und notifyall obj.wait() die Sperre wird freigegeben und der Thread geht in einen Wartezustand obj.notify() weckt einen im Wartezustand befindlichen Thread (falls vorhanden) obj.notifyall() weckt alle Threads

15 Monitore

16 Monitore

17 Monitore Ein Java-Monitor ist ein Objekt, das einerseits mittels einer Sperre (lock) den Schutz kritischer Abschnitte ermöglicht, und andererseits über eine oder mehrere Wartelisten auf Bedingungen (condition) ermöglicht. Das Warten auf eine Bedingung ist im Monitor immer mit der Sperre koordiniert: Während des Wartens wird die Sperre freigegeben und muss anschließend wieder erlangt werden. public synchronized void put (E x) throws InterruptException while(data.size() == maxcount){ wait(); data.add(x) notifyall(); public synchronized E take throws InterruptException while(data.size() == 0){ wait(); notifyall(); data.remove(0)

18 Monitore wait( ): Suspendierung der Ausführung des aufrufenden Prozesses auf der Grundlage der gesetzten Bedingung. Der Montior steht anschließend anderen Prozessen zur Verfügung. send( ): Wiederaufnahme der Ausführung eines Prozesses, der im Anschluss an die Funktion wait() durch dieselbe Bedingung suspendiert wurde. Wenn es mehrere Prozesse dieser Art gibt, wird einer von ihnen ausgewählt. Gibt es hingegen keinen derartigen Prozess, dann wird nichts unternommen.

19 Monitore wait(); Wenn ein Thread für irgendein Objekt x die Methode wait x.wait () aufruft, dann wird er in eine dem Objekt x zugeordnete wait-warteschlange gestellt (wait Set). Außerdem wird der kritische Bereich freigegeben, d.h. der Thread gibt sein Lock auf das Objekt x ab (d.h. der Monitor wird verlassen). notify(); Wenn ein anderer Thread x.notify () aufruft, dann wird ein Thread aus der wait- Warteschlange von x entfernt und wieder lauffähig. Dieser Thread muss sich aber nun um ein Lock für das Objekt x bemühen, um den kritischen Bereich weiter zu durchlaufen. Er muss also mindestens solange warten, bis der notifizierende Thread das Objekt freigegeben hat (d.h. den Monitor verlassen hat). (Bemerkung: Mit der Thread-Instanzmethode interrupt () kann ein spezifischer Thread aus der wait- Warteschlange geholt werden, wobei allerdings die InterruptedException geworfen wird.

20 Monitore notifyall (); Es werden alle Threads aus der wait-warteschlange von x entfernt und wieder lauffähig. Diese Threads müssen sich aber nun um ein Lock für das Objekt x bemühen, um den kritischen Bereich weiter zu durchlaufen. Ein Objekt mit kritischen Bereichen hat also konzeptionell zwei Warteschlangen: eine für den Monitor (d.h. die kritischen Bereiche) (Entry Set) und eine für das wait (Wait Set).

21 Monitore Unterscheidung wait()/send() des Monitorkonzeptes zu P(s)/V(s) des Semaphore-Konzeptes: Ein Monitor unterstützt die Synchronisierung durch die Verwendung von Bedingungsvariablen, die im Monitor enthalten sind und auf die nur von Methoden innerhalb des Monitors zugegriffen werden kann. die beiden Funktionen wait() und send() wirken auf die Bedingungsvariablen. gibt ein Prozess im Monitor ein Signal (send()) ab, so geht das Signal verloren wenn es keine Aufgabe auf der Grundlage der Bedingungsvariable im Wartezustand gibt.

22 Monitore import java.util.arraylist: public class BlockingQueu<E>{ private final ArrayList<E> data = new ArrayList<E>(); private final int maxcount; public BlockingQueue(int maxcount){ this.maxcount = maxcount; public void put(e x) throws InterruptedException{ synchronized(this){ while (data.size() == maxcount) this.wait(); data.add(x); this.notifyall(); public E take() throws InterruptedException{ synchronized(this){ while(data.size==0) this.wait(); this.notifyall(); return data.remove();

23 Monitore import java.util.arraylist: public class BlockingQueu<E>{ private final ArrayList<E> data = new ArrayList<E>(); private final int maxcount; public BlockingQueue(int maxcount){ this.maxcount = maxcount; public synchronized void put(e x) throws InterruptedException{ while (data.size() == maxcount) wait(); data.add(x); notifyall(); public synchronized E take() throws InterruptedException{ while(data.size==0) wait(); notifyall(); return data.remove(); synchronized vor einer Methode erklärt die ganze Methode zum geschützten Bereich (kritisches Gebiet).

24 Monitore Nachbildung eines Original-Monitors mit Java Sprachregeln von Java erlauben es, Klassen zu schreiben, die exakt dem original Monitorkonzept entsprechen Folgende Regeln sind zu beachten: - Alle Instanzvariablen sind privat und nicht von außen zugänglich - Der Körper von allen öffentlichen Methoden ist mit dem this-objekt geschützt (synchronized) - Innerhalb einer Klasse werden nur this.wait() und this.notifyall() aufgerufen. Zusätzlich wird beim Warten innerhalb einer while-schleife das Vorliegender erwarteten Bedingung geprüft. Das Java-Programm auf der vorherigen Folie erfüllt all diesen Punkte!

25 Monitore nested Monitor verschachtelte Monitore void synchronized method(){ /* Anweisungen */ otherobject.synchronizedmethod(); /*weitere Anweisungen */

26 Monitore nested Monitor verschachtelte Monitore void synchronized method(){ /* Anweisungen */ otherobject.synchronizedmethod(); /*weitere Anweisungen */ Thread muss für Ausführung von synchronizedmethod() 2 Objektsperren erhalten Gefahr des Deadlocks Wartet synchronizedmethod() mittels wait(), dann wird zwar die Sperre von otherobject freigegeben, Die Sperre von method() wird von dem wartenden Thread aber festgehalten. Blockierung Bessere Lösung: void method(){ synchronized(this){ /* Anweisungen */ otherobject.synchronizedmethod(); synchronized(this){ /*weitere Anweisungen */

27 wechselseitiger Ausschluss in Java Concurrency-Bibliothek von Java! beinhaltet: einfache atomare Operationen auf Objekten Synchronisationsprimitive (Semaphore, Barrier, Read-Write-Lock, Reentrant-Lock) Mechanismen zur Erzeugung von Threads Mechanismen für die Steuerung der Thread-Bearbeitung - ähnelt der Umsetzung in POSIX-C Bibliothek - kann sehr genau an die jeweiligen Bedürfnisse angepasst werden import java.util.arraylist: Import java.util.concurrent.lock.*; public class BlockingQueu<E>{ private final ArrayList<E> data = new ArrayList<E>(); private final int maxcount; private Lock lock = new ReentrantLock(); private Condition notempty = lock.newcondition(); private Condition notfull = lock.newcondition(); public BlockingQueue(int maxcount){ this.maxcount = maxcount;

28 wechselseitiger Ausschluss in Java public E take() throws InterruptedException{ lock.lock(); try{ while(data.size==0) notempty.await(); notfull.signal(); return data.remove(); finally{ lock.unlock(); Concurrency-Bibliothek von Java public void put(e x) throws InterruptedException{ lock.lock(); try{ while (data.size() == maxcount) notfull.await(); data.add(x); notempty.signal(); finally{ Lock.unlock();

29 Barrieren Synchronisationsmechanismus gestattet mehreren kooperierenden Prozessen, gemeinsam einen konsistenten Zustand zu erreichen. Bsp.: Prozesse erarbeiten Teilergebnisse, die dann von einem weiterführenden Prozess zusammengefügt werden müssen (1) Prozess A und C erreichen die Barriere und werden suspendiert! (2) Prozess B erreicht als letzter die Barriere, woraufhin A und C wieder freigegeben werden. Sperren kritischer Bereiche in Zukunft gerichtet Prozess muss warten bis andere den Bereich verlassen haben. Barrieren in Vergangenheit gerichtet Prozess wartet bis nachfolgende aufgeschlossen haben. Bsp.: Führung durch ein Museum der nächste Ausstellungsraum wird erst betreten wenn alle Teilnehmer der Führung versammelt sind.

30 Barrieren pthreads can participate in a barrier to synchronize to some point in time. Before a barrier can be called, a pthread barrier object must be initialized first: int pthread_barrier_init(pthread_barrier_t *barrier, pthread_barrierattr_t *barrier_attr, unsigned int count); pthread_barrier_t barrier = PTHREAD_BARRIER_INITIALIZER(count); Barrier objects are initialized like mutexes or condition variables, except there is one additional parameter, count. The count variable defines the number threads that must join the barrier for the barrier to reach completion and unblock all threads waiting at the barrier. If default barrier attributes are used (i.e. NULL for the second parameter), one can use the initializer macro with the specified count. int pthread_barrier_wait(pthread_barrier_t *barrier); This function would be inside thread code where the barrier is to take place. Once count number of threads have called pthread_barrier_wait() then the barrier condition is met and all threads are unblocked and progress continues.

31 Synchronisation Notwendige Bedingungen! (Design-Entscheidung des BS) 1) Wechselseitiger Ausschluss (Mutual Exklusion) Zu einem gegebenen Zeitpunkt kann immer jeweils nur ein Prozess eine Ressource nutzen. 2) Besitzen und Warten (Hold & Wait) Ein Prozess kann auf die Zuteilung weiterer Ressourcen warten und darf dabei bereits Ressource besitzen. 3) Kein Ressourcenentzug (Non-Preemption) Ein Prozess, der im Besitz einer Ressource ist, kann diese nicht gewaltsam entzogen werden. Hinreichende Bedingung! (Situation) 4) Zyklisches Warten (Circular Wait) Es existiert eine geschlossene Kette von Prozessen, bei der jeder Prozess mindestens eine Ressource besitzt, die vom nächsten Prozess in der Kette benötigt wird!

32 Synchronisation 1) Wechselseitiger Ausschluss (Mutual Exclusion) Zu einem gegebenen Zeitpunkt kann immer jeweils nur ein Prozess eine Ressource nutzen. Kann im Allgemeinen nicht ausgeschlossen/verhindert werden, da Ressourcen existieren, die nur einen exklusiven Zugriff erlauben. Bsp.: Schreibrecht auf Dateien.

33 Synchronisation 2) Besitzen und Warten (Hold & Wait) Ein Prozess kann auf die Zuteilung weiterer Ressourcen warten und darf dabei bereits Ressource besitzen. Kann dadurch verhindert werden, dass ein Prozess alle von ihm benötigten Ressourcen gleichzeitig anfordern muss. Der Prozess wird solange blockiert bis ihm alle Ressourcen zugeteilt werden können. Wenig effizient ein Prozess blockiert auf längere Zeit Ressourcen ohne diese wirklich zu nutzen. praktisches Problem: in modularer Programmierung + Multithreading-Struktur: Kann ein Prozess wirklich alle je benötigten Ressourcen kennen?

34 Synchronisation 3) Kein Ressourcenentzug (Non-Preemption) Ein Prozess, der im Besitz einer Ressource ist, kann diese nicht gewaltsam entzogen werden. Kann auf mehrere Arten verhindert werden: 1. Wird einem Prozess die Zuweisung einer Ressource verweigert, so muss der Prozess alle Ressourcen in seinem Besitz freigeben und sofern notwendig alle Ressourcen erneut anfordern. 2. Das Betriebssystem unterbricht den zweiten Prozess, der die angeforderte Ressource hält und zwingt ihn zur Freigabe. fordert Priorisierung der Prozesse und die konkurrierenden Prozesse dürfen nicht die gleiche Priorität besitzen. funktioniert nur mit Ressourcen, deren Zustand gesichert und wiederhergestellt werden kann.

35 Synchronisation 4) Zyklisches Warten (Circular Wait) Es existiert eine geschlossene Kette von Prozessen, bei der jeder Prozess mindestens eine Ressource besitzt, die vom nächsten Prozess in der Kette benötigt wird! Kann dadurch verhindert werden, dass eine lineare Ordnung der Ressourcentypen festgelegt wird. Wenn einem Prozess Ressourcen des Typs R zugeteilt wurden, kann er nachfolgend nur Ressourcen eines Typs anfordern, der in der Ordnung auf R folgt. Bsp.: R i steht vor R j in der Reihenfolge (es gilt i < j). Angenommen zwei Prozess P1 und P2 sind verklemmt, da P1 die Ressource R i und P2 R j besitzt. P1 fordert zusätzlich R j an und P2 R i. Dieser Zustand ist ungültig: P2 hätte zuerst R i und dann R j anfordern müssen.

36 Synchronisation Wettstreit um Ressourcen zwischen Prozessen wechselseitiger Ausschluss zwei Steuerungsprobleme bei der Durchsetzung des wechselseitigen Ausschlusses. Deadlock (Verklemmung) Starvation (Verhungern)

37 Starvation (Verhungern) Beispiel: 3 Prozesse P1, P2, P3 greifen auf die Ressource R zu. P1 bekommt nun R zugewiesen und führt seine Aufgabe aus. Nach verlassen des kritischen Gebiets um R, bekommt P3 Zugriff auf R. Noch bevor P3 das kritischen Gebiet verlassen hat benötigt P1 erneut R. Das Betriebssystem entscheidet (womöglich aufgrund des Ergebnisses von P3) das P1 erneut R zugewiesen bekommt. Das Verhalten von P1 und P3 wiederholt sich nun beliebig oft und führt zu jeweils gleichen Entscheidungen des Betriebssystems. P2 bleibt der Zugriff auf R auf unbestimmte Zeit verweigert. Es liegt kein Deadlock vor! P1 und P3 können ihre Aufgabe bearbeiten! nur P2 ist verklemmt und kann nicht weiterarbeiten.

38 Livelock - ebenfalls eine Form der Verklemmung im Gegensatz zum Deadlock verharren die Prozesse nicht in einem Zustand, sondern wechseln ständig zwischen verschiedenen Zuständen. Zustände verharren nicht im Wait-Zustand, sondern sind weiterhin aktiv und wechseln zwischen mehreren Zuständen, können ihre eigentliche Aufgabe aber dennoch nicht bearbeiten. anschaulisches Beispiel: 2 Personen treffen auf einem Gehweg aufeinander und wollen aneinander vorbei gehen. Beide wechseln jedoch immer gleichzeitig die Gehwegseite und blockieren sich so weiterhin gegenseitig. Die beiden Personen sind zwar weiterhin in Bewegung, können sich aber nicht in ihrer eigentlich angestrebten Richtung fortbewegen.

39 Beispiel./twothreads Thread 1 ist nicht im kritischen Gebiet Thread 2 ist nicht im kritischen Gebiet +++1 Thread 1 betritt kritisches Gebiet Thread 1 ist im kritischen Gebiet Thread 1 verlaesst kritisches Gebiet +++ Thread 1 ist nicht im kritischen Gebiet Thread 1 ist nicht im kritischen Gebiet ---1 Thread 2 betritt kritisches Gebiet Thread 2 ist im kritischen Gebiet Thread 2 verlaesst kritisches Gebiet --- Thread 2 ist nicht im kritischen Gebiet Thread 2 ist nicht im kritischen Gebiet +++1 Thread 1 betritt kritisches Gebiet Thread 1 ist im kritischen Gebiet Thread 1 verlaesst kritisches Gebiet +++ Thread 1 ist nicht im kritischen Gebiet Thread 1 ist nicht im kritischen Gebiet ---1 Thread 2 betritt kritisches Gebiet Thread 2 ist im kritischen Gebiet Thread 2 verlaesst kritisches Gebiet --- Thread 2 ist nicht im kritischen Gebiet Thread 2 ist nicht im kritischen Gebiet +++1 Thread 1 betritt kritisches Gebiet Thread 1 ist im kritischen Gebiet Thread 1 verlaesst kritisches Gebiet +++

40 Beispiel Kritisches Gebiet Funktion criticalarea(...) void criticalarea(char* icon, int thread){ printf("%s1 Thread %d betritt kritisches Gebiet %s \n", icon,thread,icon); sleep(1); printf("%s2 Thread %d ist im kritischen Gebiet %s \n", icon,thread,icon); sleep(1); printf("%s3 Thread %d verlaesst kritisches Gebiet %s \n", icon,thread,icon); Definition: kritisches Gebiet / Bereich / Abschnitt Teil eines Prozesses, der auf gemeinsam benutzte Betriebsmittel zugreift.

41 Beispiel 2 Threads greifen beide auf die Funktion criticalarea zu (kritisches Gebiet) void* Thread1(void* a){ while(true){ flag[0] = true; turn = 1; printf("thread 1 ist nicht im kritischen Gebiet\n"); while(flag[1]==true && turn==1){sleep(1); criticalarea("+++",1); //betreten des kritischen Gebietes printf("thread 1 ist nicht im kritischen Gebiet\n"); flag[0]=false; int main(){ //Thread2 //... while(true){ flag[1] = true; turn = 0; printf("thread 2 ist nicht im kritischen Gebiet\n"); while(flag[0]==1 && turn==0){rnd=(rand()%4);sleep(rnd); criticalarea("---",2); //betreten des kritischen Gebietes printf("thread 2 ist nicht im kritischen Gebiet\n"); flag[1]=false;

42 Beispiel 1) Nur ein Prozess (Thread) darf im kritischen Gebiet sein. (Korrektheitseigenschaft). Thread1: flag[0] = true; turn = 1; while(flag[1]==true && turn==1){... criticalarea("+++",1); Thread2: flag[1] = true; turn = 0; while(flag[0]==true && turn==0){... criticalarea("---",2);

43 Beispiel 2) Ein einzelner Prozess, der sich um das kritische Gebiet bewirbt, soll auch hineingelangen. flag[0] = false; flag[1] = false; Thread1: flag[0] = true; turn = 1; while(flag[1]==true && turn==1){... criticalarea("+++",1); Thread2: flag[1] = true; turn = 0; while(flag[0]==true && turn==0){... criticalarea("---",2);

44 Beispiel 3) Bei mehreren Bewerbern um das kritische Gebiet soll schließlich einer hineingelangen. flag[0] = false; flag[1] = false; Thread1: flag[0] = true; turn = 1; while(flag[1]==true && turn==1){... criticalarea("+++",1); flag[0] = false; Thread2: flag[1] = true; turn = 0; while(flag[0]==true && turn==0){... criticalarea("---",2); flag[1] = false;

45 Beispiel 4) Die Ablaufgeschwindigkeiten einzelner Prozesse sollen keinen Einfluss auf obige Bedingungen haben. Thread1: while(flag[1]==true && turn==1){sleep(1); criticalarea("+++",1); //betreten des kritischen Gebietes Thread2: while(flag[0]==1 && turn==0){rnd=(rand()%4);sleep(rnd); criticalarea("---",2); //betreten des kritischen Gebietes

46 Beispiel 5) Keine Aktion von auserhalb hat Einfluss auf das Betreten und Verlassen des kritischen Gebietes.

47 Beispiel Ausgabe:./twothreadsfail Thread 1 ist nicht im kritischen Gebiet +++1 Thread 1 betritt kritisches Gebiet Thread 1 ist im kritischen Gebiet Thread 1 verlaesst kritisches Gebiet +++ Thread 1 ist nicht im kritischen Gebiet Thread 1 ist nicht im kritischen Gebiet +++1 Thread 1 betritt kritisches Gebiet Thread 1 ist im kritischen Gebiet Thread 1 verlaesst kritisches Gebiet +++ Thread 1 ist nicht im kritischen Gebiet Thread 1 ist nicht im kritischen Gebiet +++1 Thread 1 betritt kritisches Gebiet +++ Thread 2 ist nicht im kritischen Gebiet ---1 Thread 2 betritt kritisches Gebiet Thread 1 ist im kritischen Gebiet Thread 2 ist im kritischen Gebiet Thread 1 verlaesst kritisches Gebiet +++ Thread 1 ist nicht im kritischen Gebiet Thread 1 ist nicht im kritischen Gebiet ---3 Thread 2 verlaesst kritisches Gebiet --- Thread 2 ist nicht im kritischen Gebiet +++1 Thread 1 betritt kritisches Gebiet Thread 1 ist im kritischen Gebiet Thread 1 verlaesst kritisches Gebiet +++ Thread 1 ist nicht im kritischen Gebiet Thread 1 ist nicht im kritischen Gebiet

48 Peterson für N Prozesse #define draussen 0 #define N 100 common int marke[n]; common int interessiert[n+1]; P k : betrete_gebiet(int prozess){ int i,j; Lösung für N Prozesse (./manythreads) for (i=1;i<n;i++){ interessiert[prozess]=i; marke[i]=prozess; for(j=1;j<=n;j++){ if(j==prozess) continue; while(interessiert[j] >= i && turn[i]==prozess){ /*kritisches Gebiet*/ verlasse_gebiet(int prozess){ interessiert[prozess]=draussen;