Kap4

Copyright(C) by Foxit Software Company,2005-2007

Interprozess-Kommunikation Race conditions an einem Beispiel
Durch Nutzung gemeinsamen Speichers (egal, ob Hauptspeicher oder Plattenplatz) können In einer Warteschlange des BS seien mehrere Prozesse eingehängt und warten auf eine
Prozesse miteinander kommunizieren, indem sie Daten austauschen. Bearbeitung:

Problem: hierbei entstehen zeitkritische Abläufe (race conditions) Für das Einhängen des Prozesses A gilt: Für das Entfernen von B gilt:
• Lese den Anker: PointToB • Lese den Anker: PointToB
Def.: Eine Situation, in der mindestens zwei Prozesse auf gemeinsam genutzte Daten zugreifen, • Setze den NextZeiger: Point ToB • Lese den NextZeiger: PointToC
und die Ergebnisse von der zeitlichen Reihenfolge des Zugriffs abhängen, nennt man • Setze den Anker: Point ToA • Setze den Anker: PointToC
zeitkritischen Ablauf (race condition)
Was passiert, wenn die Operationen nicht in einem Stück durchgeführt werden ?
Beispiel: gespoolte Druckausgabe
Spooler 1
Idee: in einer Tabelle stehen alle zu 2 test.c out = 2
Edited by Foxit Reader

druckenden Dateien, Variable out zeigt 3 note.xls in = 5
For Evaluation Only.

auf die nächste zu druckende Datei, 4 dipl.doc
Variable in zeigt auf nächsten
5 kase.xls
freien Tabellenplatz. Zwei Prozesse Prozeß A
A und B wollen nahezu gleichzeitig 6 folie.ppp
etwas ausdrucken. 7
Katastrophe: BS wechselt von A nach B Prozeß B 8
VOR dem vollständigen Ende des Zugriffs !!!
Prof. W. Burkard 100 Prof. W. Burkard 101

Stichworte Stichworte

Computer arbeiten deterministisch. Heißt Eingabe gleich Ausgabe (5+5=10
egal ob es 10h morgens oder 8h abends ist // kalt oder warm ist).

Notizen Notizen

100 101


zeitkritische Bereiche aktives Warten
Def: Derjenige Teil eines Prozesses, in dem der Zugriff auf gemeinsam benutzten Speicher
stattfindet, wird als (zeit-)kritischer Bereich des Prozesses bezeichnet. = (schlechte) Lösung des Problems des wechselseitigen Ausschlusses

Idee: Probleme mit zeitkritischen Abläufen lassen sich vermeiden, wenn sich niemals zwei Ansatz 1: Sperren aller Unterbrechungen beim Eintritt in einen kritischen Bereich
oder mehr Prozesse gleichzeitig in einem kritischen Bereich befinden. - sinnvolle Lösung für diverse Prozesse des Betriebssystems
==> wechselseitiger Ausschluß <== - gefährliche Lösung, bei Nutzung durch Anwenderprozesse

Für ein funktionierendes System fordern wir also: Ansatz 2: Eine globale Sperrvariable kann die Werte 0 oder 1 annehmen
Nur wenn Sperrvariable=0 geht ein Prozeß in den kritischen Bereich
und setzt als erstes die Variable auf 1.

1. nur ein Prozeß darf sich zu einem Zeitpunkt in einem kritischen Bereich befinden
Problem: siehe Beispiel “gespoolte Druckausgabe”

2. Nur durch das Eintreten in einen kritischen Bereich blockiert ein Prozeß andere Prozesse
Ansatz 3: striktes Alternieren durch aktives Warten: Jeder Prozeß hat einen
3. Kein Prozeß soll unendlich lange warten müssen, bis er in seinen kritischen Bereich darf Kennwert W und wartet darauf, daß die Schaltvariable SV diesen Wert
annimmt. Nach Beenden des kritischen Bereiches wird SV weitergeschaltet,
4. kein Prozeß darf Annahmen über Prozessoranzahl oder Ausführungsgeschwindigkeit also: warten, bis SV == W
seiner selbst oder anderer Prozesse machen Eintreten in krit. Bereich....Austreten aus kritischem Bereich
Prof. W. Burkard 102 Prof. W. Burkard
SV weiterschalten 103

Gute Idee, funktioniert aber in der Realität nicht!

Notizen Notizen

102 103

Erster Versuch zur Prozess-Synchronisation Zweiter Versuch zur Prozess-Synchronisation
Die einfachste Idee zur Erreichung eines gegenseitigen Ausschlusses besteht darin, Wir wollen beide Prozesse in beliebiger Reihenfolge synchronisieren
einen Prozess beim Eintreten in einen kritischen Abschnitt so lange Ein Prozess achte also nur darauf, dass der andere nicht drin ist.
warten zu lassen, bis der Abschnitt wieder frei ist.

Für zwei parallel ablaufende Prozesse würde das wie folgt aussehen:

Die gemeinsame Variable dran sei mit 1 initialisiert, so erreichen wir den gegenseitigen Ausschluss. Die Variablen drin1 und drin2 seien beide mit false initialisiert.

Wo ist das Problem ? Wo ist jetzt das Problem ?
Beide Prozesse können nur abwechselnd in den kritischen Bereich ! Jetzt gehen eventuell BEIDE gleichzeitig in den kritischen Abschnitt ! Warum ?
Ein Prozess hindert sich eventuell selbst daran, ein zweites Mal in den krit. Bereich zu gehen!!! Hilft es die beiden Zeilen des ersten grauen Bereiches zu vertauschen?



Notizen Notizen

104 105


aktives Warten: Petersons Lösung (von 1981) Petersons Lösung in Java / C / C++
q Die Variablen Interesse1 und Interesse2 sowie dran sind globale, gemeinsame Variablen #define FALSE O
q Die Variablen Interesse1 und Interesse2 sind beide mit false initialisiert. #define TRUE 1
#define N 2 /* Anzahl der Prozesse */

int dran; /* Wer ist an der Reihe ? */
int interessiert [N]; /* Alle Werte sind anfangs O (FALSE) */

void enter_region (int prozess) /* prozess: wer tritt ein (O oder 1) */
{
int anderer; /* Nummer des anderen Prozesses */

anderer = 1 - prozess; /* Konkurrent des Prozesses */

interessiert[process] = TRUE; /* ich zeige mein Interesse */
dran = prozess; /* setze Marke: ich bin dran! */

while ( dran == prozess /* Wer dran zuletzt setzt, muss warten, */
&& interessiert[anderer] == TRUE) /* wenn auch der andere rein will */
; /* leere Anweisung, NoOP */
}
Wie kommt ein Prozess voran, wenn der andere kein Interesse bekundet hat ?
void leave_region (int prozess) /* prozess, der den Bereich verläßt */
Wie ist der Ablauf, wenn beide nahezu zeitgleich (im ersten grauen Bereich) Interesse bekunden ? {
interessiert[prozess] = FALSE; /* gibt das Verlassen des krit. Bereiches bekannt */
Prof. W. Burkard 106
} Prof. W. Burkard 107


Wenn ein Prozess in diese Schleife kommt, bleibt er quot;ewigquot; in dieser Schleife.
Er kommt erst weiter sobald die Bedingung nicht mehr erfüllt ist und dies geschieht
erst dann wenn der Scheduler erneut auf den Prozess zugreift!
=> Aktives Warten bremst den Rechner aus, in der Zeit in der Gewartet wird,
wird zudem noch unnötig Strom verbraucht.
Notizen Notizen

106 107


Sleep und Wakeup das Erzeuger-Verbraucher-Problem
wichtige Erkenntnis: ... oder: das Ärgernis mit den verlorenen Weckrufen
Durch aktives Warten wird Prozessorzeit verschwendet!
(Prozesse prüfen aktiv in einer Schleife das Eintreffen einer Änderung) Zwei Prozesse benutzen einen Ringpuffer, der eine schreibt
Daten hinein, der andere ließt diese aus.
Dazu kommt das Prioritäteninversionsproblem:
Ein höher priorisierter Prozeß H wartet unendlich lang auf das Verlassen des krit.
Bereiches eines niedriger priorisierten Prozesses L, da der Scheduler den Ist der Puffer voll und der Schreiber hat etwas zum eintragen, N Elemente
rechenbereiten Prozeß H stets vorzieht => L kommt nicht mehr zum Zug und damit legt er sich schlafen und läßt sich vom Verbraucher maximal
nicht aus dem kritischen Bereich wecken, wenn jener ein Element entfernt hat. (Denn dann
ist wieder Platz im Ring) im Ring

Neue Idee: wartende Prozesse “gehen schlafen” (werden in den Zustand

“blockiert” gesetzt) und lassen sich nach Verbesserung der Lage wieder wecken: Ist der Puffer leer und der Leser soll etwas lesen, legt er sich
schlafen und läßt sich vom Schreiber wecken, wenn der
etwas eingetragen hat.
Aufrufender Prozeß geht schlafen ==> Funktion sleep()
n
Prozeß mit der Nr. <n> soll aufwachen ==> Funktion wakeup(xyz)
PROBLEM: Eine gemeinsam benutzte Variable ANZAHL nennt die Anzahl der im Puffer
befindlichen Elemente. Der Zugriff auf diese Variable ist kritisch !!


Notizen Notizen

108 109

das Erzeuger-Verbraucher-Problem das Leser-Schreiber-Problem
Erzeuger-Algorithmus: q auf eine Datei dürfen gleichzeitig mehrere Prozesse lesend zugreifen, ABER:
1. Nimm nächstes Element q wenn ein Prozeß schreibend zugreift, darf kein anderer Prozeß (lesend oder schreibend)
agieren.
2. Lies die Variable Anzahl
Die beiden Lösung 1: (Bevorzugt die Leser-Prozesse)
3. Wenn Puffer voll, dann “Schlafen-gehen”
“gefährlichen” Schreiber: Sperrt Datei, schreibt Daten, gibt Datei frei
4. Element in den Puffer eintragen
Stellen, hier Leser: (Nur der erste Leser!! :) sperrt die Datei
5. Anzahl um 1 erhöhen
darf der ließt die Daten
6. Wenn die Anzahl jetzt 1 lautet, “Leser-wecken”
Scheduler nicht (Nur der letzte Leser!! :) gibt Datei wieder frei
den Prozeß
Leser-Algorithmus:
wechseln, sonst 1. Lies die Variable Anzahl
Lösung 2: (Bevorzugt Schreiber-Prozesse)
bricht die 2. Wenn Puffer leer, “Schlafen-gehen”
grundlegendes Konzept:
Synchronisation 3. Element lesen
Prozesse mit Lesewunsch überprüfen die Existenz von schreibenden bzw.
4. Anzahl um 1 erniedrigen schreibwilligen Prozessen und blockieren, bis die Schlange der Schreiber leer ist.
5. Wenn Puffer jetzt einen freien Platz hat, “Erzeuger-wecken”



Notizen Notizen

110 111


Semaphore: die Idee Semaphore: die Implementierung
Idee des holl. Mathematikers Dijkstra (1965):
Man zähle Wecksignale mit Hilfe einer Integer-Variablen Name: Semaphore

(Semaphore sind Signalmasten in der Seefahrt und bei Eisenbahnnetzen)
Def.: Eine Semaphore s ist eine Integervariable, die (aus Benutzersicht!) nicht negativ
werden kann und auf der nur zwei Operationen DOWN (auch P genannt) und UP (auch
V genannt) definiert sind:
DOWN(s) = P(s) = Reduziere s um 1, wenn s > 0, (sonst geht rufender Prozeß schlafen)
UP(s) = V(s) = Erhöhe s um 1 und wecke einen der schlafenden Threads (falls da)

Struktur eines
Semaphors

Zähler
WICHTIG:
q Das Überprüfen auf 0,
q das Verändern des Wertes von s Zeiger auf wartende Threads/Tasks
q und das Schlafengehen bzw. „Task wecken“ sind
eine untrennbare, atomare Aktion des Betriebssystems!!


Notizen Notizen

112 113

Erzeuger-Verbraucher-Problem

wechselseitiger Ausschluß mit Semaphoren gelöst mit Semaphoren
Zwei Semaphore „frei“ und „belegt“ werden benutzt um zwischen den Prozessen die
Zwei Prozesse 1 und 2 konkurrieren um den Eintritt in einen kritischen Bereich. Zustände des Puffers zu signalisieren. Der Semaphor „mutex“ dient nur dazu, den Zugriff auf
Semaphor s ist initial auf 1 gesetzt den Puffer exklusiv zu machen. Der Puffer fasst N Elemente. Initial gilt:
Semaphor frei = N, belegt = 0, mutex = 1;
Prozeß 1:
... beliebige Aktionen ...
down(s) <= Eintritt in kritischen Bereich Erzeuger-Prozess: Verbraucher-Prozess:
...kritischer Bereich ...
up(s) <= Austritt aus dem kritischen Bereich LOOP LOOP
P = DOWN produziere(einElement); P(belegt);

Prozeß 2: V = UP P(frei); P(mutex);

... beliebige Aktionen ... P(mutex); holeAusPuffer(einElement);
fuelleInPuffer(einElement); V(mutex);
down(s) <= Eintritt in kritischen Bereich V(frei);
V(mutex);
...kritischer Bereich ... V(belegt); verarbeite(einElement);
up(s) <= Austritt aus dem kritischen Bereich END END



mutex = mutual exchusion = gegenseitiger / wechselseitiger Ausschluss

Notizen Notizen

114 115

Leser-Schreiber-Problem Leser-Schreiber-Problem
gelöst mit Semaphoren gelöst mit Semaphoren
Hier Bevorzugung der Leser: ein gemeinsamer Zähler „AnzahlLeser“ zählt die Anzahl der
Leser im kritischen Abschnitt. Ein Semaphor „LeseSem“ schützt diesen Zähler, ein zweiter Bevorzugung der Schreiber:
Semaphor „ lock“ schützt den exklusiven Zugang zum Lesen/Schreiben. Initial gilt:
AnzahlLeser = 0; lock = 1; ZaehlerSemaphor = 1;
ein Schreiber erhält frühestmöglich Zutritt zum kritischen Abschnitt, d.h. ebenfalls
Leser-Prozess: wartenden Lesern wird der Zugriff so lange verwehrt, bis keine Schreiber mehr warten.
Schreiber-Prozess: Die Lösung umfasst:
{ ... // tue irgendwas anderes s 2 Zähler AnzahlLeser und AnzahlSchreiber,
P(ZaehlerSemaphor); {
... // tue irgendwas anderes die die Anzahl der Leser/Schreiber zählen
AnzahlLeser++;
P(lock); s 2 Semaphore LeserSem und SchreiberSem, die diese Zähler schützen
if (AnzahlLeser==1) then P(lock);
... modifiziereDieDaten(); ...
V(ZaehlerSemaphor); s 1 Semaphor lock, der wie vorhin den exklusiven Zugriff auf die Daten schützt
V(lock);
... leseDieDaten(); ... ... // tue irgendwas anderes s 1 Semaphor R erzwingt die Bevorzugung der Schreiber vor den Lesern
P(ZaehlerSemaphor); }
s 1 Semaphor M stellt sicher, dass maximal ein Leser einem Schreiber zuvorkommt, egal
AnzahlLeser--;
wie der Scheduler agiert! Beispiel: zwei Leser und ein Schreiber greifen fast gleichzeitig
if (AnzahlLeser==0) then V(lock);
V(ZaehlerSemaphor); ein Schreiber im kritischen Abschnitt: zu: im schlimmsten Fall hat dann nur ein Leser die Nase vorn (siehe Folgefolien)
... // tue irgendwas anderes
der erste Leser, der kommt,
} wird durch lock blockiert. Die Initiliasierung sieht so aus:
Kommen weitere Leser, Int AnzahlLeser = 0, AnzahlSchreiber = 0;
so warten diese auf ZaehlerSemaphor
Semaphor LeserSem=1, SchreiberSem=1, R=1, M=1, lock=1;


Notizen Notizen

116 117

Leser-Schreiber-Problem Leser-Schreiber-Problem
gelöst mit Semaphoren gelöst mit Semaphoren
Der Leserprozess bei Bevorzugung der Schreiber Der Schreiberprozess bei Bevorzugung der Schreiber

{ ... // tue irgendwas anderes
P(M); // so kommt auf jeden Fall nur ein Leser durch!
P(R); // hier geht’s nur weiter, wenn kein Schreiber aktiv ist { ... // tue irgendwas anderes
P(LeserSemaphor); P(SchreiberSemaphor);
AnzahlLeser++; AnzahlSchreiber++; // der erste Schreiber
if (AnzahlLeser==1) then P(lock); if (AnzahlSchreiber == 1) then P(R); // sperrt die Leser
V(LeserSemaphor); V(SchreiberSemaphor);
V(R);
V(M); P(lock); // Sperre Datei
... bearbeiteDieDaten(); ... // dies hier ist der kritische Abschnitt
... leseDieDaten(); ... // dies hier ist der kritische Abschnitt V(lock); // entsperre Datei // es können aber nur andere Schreiber dran

P(LeserSem); P(SchreiberSemaphor);
AnzahlLeser--; AnzahlSchreiber--; // der letzte Schreiber
if (AnzahlLeser==0) then V(lock); //kein Leser mehr da Freigabe if (AnzahlSchreiber == 0) then V(R); // gibt die Leser wieder frei

V(LeserSem); V(SchreiberSemaphor);
... // tue irgendwas anderes ... // tue irgendwas anderes
} }



Notizen Notizen

118 119

Semaphore in Echtzeitsystemen Semaphore in Echtzeitsystemen
Durch kritische Abschnitte können Prozessprioritäten verletzt werden, Beispiel: Problem 2:
q Ein Prozess P3 mit niedrigster Priorität sei im kritischen Abschnitt
q Ein Prozess P1 hoher Priorität wartet am zugehörigen Semaphor
q Was passiert, wenn ein oder mehrere Prozesse P2 mittlerer Priorität nun P3 ständig
verdrängen? Wichtiger Prozess P1 wird unnötig lange ausgestoppt!!

q Lösung: Prioritätsvererbung
= der Prozess im kritischen Abschnitt erhält dynamisch die höhere Priorität eines
anderen Prozesses, der am entsprechenden Semaphor auf Zugang wartet
Bei Verlassen des kritischen Abschnitts fällt der Prozess wieder auf seine alte Priorität

Unnötig!!
q P3 macht zuerst das P(S), gewinnt das Rennen um den kritischen Abschnitt
q P2 und P1 werden durch ihr P(S) blockiert, P2 liegt aber in der Queue der Semaphore S vorne, da
der Task das P(S) früher abschickt als P1
q Das V(S) von P3 lässt dann P2 weiterlaufen, obwohl der höher priorisierte P1 ebenfalls
weiterlaufen könnte...
q Die Lösung: Einreihung der Tasks in die Semaphor-Queue nicht chronologisch sondern nach
Prozess-Priorität !


Notizen Notizen

120 121

Prioritätsvererbung durch Semaphore Ereigniszähler
Problem 2 gelöst durchPrioritätsvererbung
Vermeidung zeitkritischer Abläufe mit Semaphoren = wechselseitiger Ausschluß
P3 erhält die hohe Priorität von P1 Scheduler wählt NICHT P2 !

Ereigniszähler = Lösung OHNE wechselseitigen Ausschluß
P3 fällt auf alte Priorität zurück
Def. Ereigniszähler E sind Integervariablen, die nur erhöht werden und auf denen
folgende Operationen definiert sind:
read(E) liefert den aktuellen Wert von E
Advance(E) erhöht den Wert von E um 1 (dies ist eine atomare Funktion)
Await(E,i) wartet bis E mindestens den Wert i erreicht

Merke: Ereigniszähler beginnen immer bei 0 und werden stets nur erhöht !!!

P1 erhält nun sofort die CPU,
Prof. W. Burkard P2 kommt erst danach 122 Prof. W. Burkard 123


Notizen Notizen

122 123

Lösung des Erzeuger-Verbraucher-
Problems mit zwei Ereigniszählern Nachrichtenaustausch
N = ( z.B.) 100 /* Größe des Puffers */
Ereigniszaehler rein=0, raus=0; /* zählen die eingefügten/entnommenen Einträge */
Problem aller bisherigen Synchronisationsverfahren: Man braucht einen GEMEINSAMEN
Speicherplatz für die partizipierenden Prozesse !!
Erzeuger:
int zaehler=0; /* alle Einträge werden durchnummeriert */
Erkenntnis: Dann funktionieren diese Verfahren nicht über Rechnergrenzen hinweg !!
Schleife: zaehler inkrementieren
await(raus, zaehler-N); /* warten bis Platz im Puffer ist */
Element einfügen ... Problem: Wir brauchen ein Synchronisationsverfahren auch in verteilten Systemen
advance(rein);
Idee: Synchronisation durch Nachrichtenaustausch

Verbraucher: Wir definieren zwei Systemfunktionen:
int vzaehler=0;
Schleife: vzaehler inkrementieren sende(Ziel, Nachricht) Sendet die Nachricht an das angegebene Ziel
await(rein,vzaehler) /* warte bis ein Element im Puffer ist */ empfange(Quelle, Nachricht) Empfängt eine Nachricht von der Quelle und blockiert,
Element entnehmen... d.h. wartet, solange keine Nachricht kommt.
advance(raus)



Notizen Notizen

124 125

Lösung des Erzeuger-Verbraucher-
Problems mit Nachrichten Monitore, die Idee
N = ( z.B.) 100 /* Größe des Puffers */ Problem: Alle bisherigen Konzepte sind kompliziert und sehr sensibel bei kleinsten subtilen Fehlern!
Beispiel Semaphore:
Verwechseln von P und V oder Vertauschen von geschachtelten P und V:
P(frei); P(m); doTheCritAction(); V(frei();V(m);
Erzeuger: Idee:
man überlasse einem Compiler die richtige Anordnung der Befehle und finde ein höheres,
Schleife: empfange(Verbraucher, leere Nachricht) abstrakteres Sprachkonstrukt den kritischen Bereich (critical region)

Statt: P(s); <kritische Befehle> V(s);
... setze Element in die leere Nachricht ... M
Nun: shared s;
sende(Verbraucher, Nachricht mit Element) g on
region s do <kritische Befehle>; de eme itor
r d in =
Der vom Compiler erzeugte Code garantiert, ar sa Zu
dass nur einer von mehreren Prozessen im kritischen Code arbeitet. au m sa
f d ge m
Monitor ef nu me
Verbraucher: in tz nf
1973-74 (!!) haben Hansen und Hoare das Konzept erweitert: ie te as
rte n s
Man nehme einen ADT (heute Klasse), der die Aufgabe übernimmt n Da un
Zu te g
Wiederhole 100 mal: sende(Erzeuger, leere Nachricht) s alle darin enthaltenen und von außen ansprechbaren Prozeduren gr n u de
iff n r
Schleife: empfange(Erzeuger, Nachricht mit Element) s und die lokalen Daten, Variablen und Funktionen
sf d
un
kt
... entnehme Element aus der Nachricht und verarbeite es... s durch Synchronisationsmechanismen automatisch zu schützen und io
ne
sende(Erzeuger, leere Nachricht) s den wechselseitigen Ausschluss von Prozessen darin zu garantieren. n
Diese Klasse nannte man einen MONITOR


Notizen Notizen

126 127

Monitore, das Konzept Monitore, die Vorteile
Monitor Monitorname ( Parameter )
Datendeklarationen; /* gemeinsame Daten */
q Gemeinsam (durch mehrere Prozesse) bearbeitete Daten werden explizit in der
Programmstruktur sichtbar gemacht
ENTRY Funktionsname1 ( Parameter ) { Prozedurkörper }
ENTRY Funktionsname2 ( Parameter ) { Prozedurkörper } sie sind in Monitoren organisiert

ENTRY Funktionsname3 ( Parameter ) { Prozedurkörper } q Die bereitgestellten Monitorprozeduren definieren allein
... die Zugriffsalgorithmen zu den Monitordaten.
ENTRY FunktionsnameN ( Parameter ) { Prozedurkörper }
q Ein Umgehen der Monitorprozeduren ist nicht möglich
INIT { Initialisierungsanweisungen } q Monitore kapseln wie Module die gemeinsamen Daten.
END Eine Änderung der monitorinternen Datenstrukturen und Algorithmen bleibt für
Die Initialisierung der Monitordaten erfolgt durch einmaligen Aufruf von Prozesse unsichtbar, solange die Schnittstelle unverändert bleibt information hiding

Monitorname(aktuelle Parameter);
Dadurch wird letztendlich der Initialisierungsteil durchlaufen.
Prozesse benutzen den Monitor durch Aufruf der Monitorprozeduren in der Form:
Monitorname.Funktionsname ( aktuelle Parameter );



Notizen Notizen

128 129

Erzeuger-Verbraucher-Problem Erzeuger-Verbraucher-Problem
gelöst mit einem Monitor gelöst mit einem Monitor
Erzeuger und Verbraucher-Prozesse: Deklaration des Monitors:

Erzeuger Verbraucher

LOOP LOOP
{ {
produziere(Element); Buffer.getFromBuffer(Element);
Buffer.putInBuffer(Element); verarbeite(Element);
} }
END END



Notizen Notizen

130 131

Erzeuger-Verbraucher-Problem Erzeuger-Verbraucher-Problem
gelöst mit einem Monitor gelöst mit einem Monitor
Monitor ist unvollständig ! Was fehlt ?
Implementierung der beiden zentralen Prozeduren!

Die zentralen
Problem: wir brauchen zusätzliche Wartebedingungen zur Kontrolle des Pufferüber-
/unterlaufs Monitor-Prozeduren
Lösung: in Monitoren gibt es Condition-Variable mit nur zwei Operationen:
signal(s) = sendet der Condition-Variable s ein Signal zur Befreiung
der an dieser Condition wartenden Tasks
wait(s) = Task soll an der Condition-Variable s solange warten,
bis ein Signal gesendet wird.

Konsequenz: Der Monitor Buffer muss um zwei Condition-Variable erweitert werden:

VAR frei, belegt: CONDITION

Dann ergeben sich die beiden Monitor-Prozeduren gemäss nächster Folie!



Notizen Notizen

132 133

Ein klassisches IPC-Problem prinzipieller Lösungsansatz für
das Philosophenproblem das Philosophenproblem
(oder: die Rangelei um den exklusiven Zugriff auf begrenzte Betriebsmittel ) q Man muß den Zugriff auf die beiden Gabeln und andere gemeinsame Ressourcen regeln
q Es gibt also eine Semaphore G für den wechselseitigen Ausschluß
Problem: Ein Philosoph ißt oder denkt. (richtig ! Das ist eine seehr starke Abstraktion!!)
q Es sitzen 5 Philosophen am Tisch mit fünf Tellern und fünf Gabeln
q Jeder Philosoph befindet sich in einem von drei Zuständen: denkend, hungrig, essend
q Ein hungriger Philosoph versucht linke und rechte Gabel aufzunehmen, dann ißt er ein
Weilchen, danach legt er die Gabeln zurück und denkt wieder. q Es gibt also je Philosoph i eine Zustandsvariable Z(i) 1<=i<=5 mit den Werten d,h,e

Aufgabe: Man finde für die Philosophen Mittagszeit bei den Philosophen q Ein hungriger Philosoph ist blockiert, wenn er nicht beide Gabeln erhält.
einen funktionierenden Algorithmus !! (mit leerem Magen kann man nicht denken)
q Es gibt somit je Philosoph eine Semaphore S(i) 1<= i<=5
Einfache, aber fehlerhafte Lösung:

Philosoph denkt ... q Hat ein Philosoph seine Mahlzeit beendet, so schaut er, ob seine Nachbarn jetzt essen
nimmt linke Gabel auf könnten und weckt sie gegebenenfalls auf
nimmt rechte Gabel auf
ißt von seinem Teller
legt linke Gabel zurück
legt rechte Gabel zurück



Notizen Notizen

134 135

Alles klar ??
1. Was ist ein zeitkritischer Ablauf ?
2. Zeigen Sie an folgendem Beispiel, daß der Algorithmus SJF bei nicht-gleichzeitigem
Vorliegen der Jobs nicht korrekt arbeitet: Es sollen zum Zeitpunkt 0 zwei Jobs A und B mit
vermuteten Laufzeiten 4 und 8 Min. vorliegen. Nach 5 Minuten kommen drei weitere Jobs
C,D und E mit je 2 Min. Laufzeit dazu. Wie ist die Ausführungsreihenfolge und die
durchschnittliche Verweilzeit? Wie wären die Werte, wenn die Jobs gleichzeitig vorlägen?
3. Was ist der Unterschied zwischen aktivem Warten und Blockieren ?
4. Nennen Sie Argumente für ein kleines bzw. großes Quantum beim Round-Robin.
5. Was passiert, wenn beim Round-Robin ein Prozeß mehrmals in der Schlange steckt ?
Sehen Sie einen Grund, dieses zu gestatten ?
6. In einer Bäckerei verkaufen n Verkäufer Backwaren. Jeder eintretende Kunde zieht eine
Nummer von einem fortlaufend nummerierten Band. Ein Verkäufer ruft die nächste
Nummer auf, sobald er wieder frei ist. So findet jeder Kunde schnellstens den Käufer, der
ihn bedient. Skizzieren Sie die Algorithmen für Kunden und Verkäufer (Lösung mittels
Semaphore)

Prof. W. Burkard 136

Stichworte

Notizen

136

Kap4

Recomendados

Recomendados

Mais conteúdo relacionado

Destaque

Destaque (20)

Kap4