Kap4

100

Stichworte

Notizen

Prof. W. Burkard 100

Interprozess-Kommunikation

Durch Nutzung gemeinsamen Speichers (egal, ob Hauptspeicher oder Plattenplatz) könnenProzesse miteinander kommunizieren, indem sie Daten austauschen.

Problem: hierbei entstehen zeitkritische Abläufe (race conditions)

Def.: Eine Situation, in der mindestens zwei Prozesse auf gemeinsam genutzte Daten zugreifen,und die Ergebnisse von der zeitlichen Reihenfolge des Zugriffs abhängen, nennt man zeitkritischen Ablauf (race condition)

Beispiel: gespoolte DruckausgabeIdee: in einer Tabelle stehen alle zu druckenden Dateien, Variable out zeigt auf die nächste zu druckende Datei, Variable in zeigt auf nächsten freien Tabellenplatz. Zwei ProzesseA und B wollen nahezu gleichzeitigetwas ausdrucken.Katastrophe: BS wechselt von A nach BVOR dem vollständigen Ende des Zugriffs !!!

1 2 test.c 3 note.xls4 dipl.doc5 kase.xls6 folie.ppp7 8

out = 2in = 5

Prozeß A

Prozeß B

Spooler

101

Stichworte

Notizen


Race conditions an einem Beispiel

In einer Warteschlange des BS seien mehrere Prozesse eingehängt und warten auf eineBearbeitung:

Für das Einhängen des Prozesses A gilt:• Lese den Anker: PointToB• Setze den NextZeiger: Point ToB• Setze den Anker: Point ToA

Was passiert, wenn die Operationen nicht in einem Stück durchgeführt werden ?

Für das Entfernen von B gilt:• Lese den Anker: PointToB• Lese den NextZeiger: PointToC• Setze den Anker: PointToC

Jonas

Typewriter

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

Edited by Foxit Reader Copyright(C) by Foxit Software Company,2005-2007 For Evaluation Only.

102

Stichworte

Notizen


zeitkritische Bereiche

Def: Derjenige Teil eines Prozesses, in dem der Zugriff auf gemeinsam benutzten Speicher stattfindet, wird als (zeit-)kritischer Bereich des Prozesses bezeichnet.

Idee: Probleme mit zeitkritischen Abläufen lassen sich vermeiden, wenn sich niemals zwei oder mehr Prozesse gleichzeitig in einem kritischen Bereich befinden.

==> wechselseitiger Ausschluß <==

Für ein funktionierendes System fordern wir also:

1. nur ein Prozeß darf sich zu einem Zeitpunkt in einem kritischen Bereich befinden

2. Nur durch das Eintreten in einen kritischen Bereich blockiert ein Prozeß andere Prozesse

3. Kein Prozeß soll unendlich lange warten müssen, bis er in seinen kritischen Bereich darf

4. kein Prozeß darf Annahmen über Prozessoranzahl oder Ausführungsgeschwindigkeit seiner selbst oder anderer Prozesse machen

103

Stichworte

Notizen


aktives Warten

= (schlechte) Lösung des Problems des wechselseitigen Ausschlusses

Ansatz 1: Sperren aller Unterbrechungen beim Eintritt in einen kritischen Bereich- sinnvolle Lösung für diverse Prozesse des Betriebssystems- gefährliche Lösung, bei Nutzung durch Anwenderprozesse

Ansatz 2: Eine globale Sperrvariable kann die Werte 0 oder 1 annehmenNur wenn Sperrvariable=0 geht ein Prozeß in den kritischen Bereichund setzt als erstes die Variable auf 1.Problem: siehe Beispiel “gespoolte Druckausgabe”

Ansatz 3: striktes Alternieren durch aktives Warten: Jeder Prozeß hat einen Kennwert W und wartet darauf, daß die Schaltvariable SV diesen Wertannimmt. Nach Beenden des kritischen Bereiches wird SV weitergeschaltet,

also: warten, bis SV == WEintreten in krit. Bereich....Austreten aus kritischem BereichSV weiterschalten

Jonas

Highlight

= Interrupt


Jonas

Highlight

= Deadlock

Jonas

Typewriter

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

104

Stichworte

Notizen


Erster Versuch zur Prozess-Synchronisation

Die einfachste Idee zur Erreichung eines gegenseitigen Ausschlusses besteht darin, einen Prozess beim Eintreten in einen kritischen Abschnitt so lange 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.

Wo ist das Problem ?Beide Prozesse können nur abwechselnd in den kritischen Bereich !

� Ein Prozess hindert sich eventuell selbst daran, ein zweites Mal in den krit. Bereich zu gehen!!!

105

Stichworte

Notizen


Zweiter Versuch zur Prozess-Synchronisation

Wir wollen beide Prozesse in beliebiger Reihenfolge synchronisierenEin Prozess achte also nur darauf, dass der andere nicht drin ist.

Die Variablen drin1 und drin2 seien beide mit false initialisiert.

Wo ist jetzt das Problem ?Jetzt gehen eventuell BEIDE gleichzeitig in den kritischen Abschnitt ! Warum ?Hilft es die beiden Zeilen des ersten grauen Bereiches zu vertauschen?

106

Stichworte

Notizen


Wie kommt ein Prozess voran, wenn der andere kein Interesse bekundet hat ?

Wie ist der Ablauf, wenn beide nahezu zeitgleich (im ersten grauen Bereich) Interesse bekunden ?

aktives Warten: Petersons Lösung (von 1981)

● Die Variablen Interesse1 und Interesse2 sowie dran sind globale, gemeinsame Variablen● Die Variablen Interesse1 und Interesse2 sind beide mit false initialisiert.

107

Stichworte

Notizen


Petersons Lösung in Java / C / C++#define FALSE O #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 */

}

void leave_region (int prozess) /* prozess, der den Bereich verläßt */{

interessiert[prozess] = FALSE; /* gibt das Verlassen des krit. Bereiches bekannt */}

Jonas

Oval

Jonas

Line

Jonas

Typewriter

Wenn ein Prozess in diese Schleife kommt, bleibt er "ewig" 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.


108

Stichworte

Notizen


Sleep und Wakeup

wichtige Erkenntnis: Durch aktives Warten wird Prozessorzeit verschwendet!(Prozesse prüfen aktiv in einer Schleife das Eintreffen einer Änderung)

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 rechenbereiten Prozeß H stets vorzieht => L kommt nicht mehr zum Zug und damit nicht aus dem kritischen Bereich

Neue Idee: wartende Prozesse “gehen schlafen” (werden in den Zustand “blockiert” gesetzt) und lassen sich nach Verbesserung der Lage wieder wecken:

Aufrufender Prozeß geht schlafen ==> Funktion sleep()Prozeß mit der Nr. <n> soll aufwachen ==> Funktion wakeup(xyz)

109

Stichworte

Notizen


das Erzeuger-Verbraucher-Problem

... oder: das Ärgernis mit den verlorenen Weckrufen

Zwei Prozesse benutzen einen Ringpuffer, der eine schreibt Daten hinein, der andere ließt diese aus.

Ist der Puffer voll und der Schreiber hat etwas zum eintragen, legt er sich schlafen und läßt sich vom Verbraucher wecken, wenn jener ein Element entfernt hat. (Denn dann ist wieder Platz im Ring)

Ist der Puffer leer und der Leser soll etwas lesen, legt er sichschlafen und läßt sich vom Schreiber wecken, wenn der etwas eingetragen hat.

N Elementemaximalim Ring

PROBLEM: Eine gemeinsam benutzte Variable ANZAHL nennt die Anzahl der im Puffer befindlichen Elemente. Der Zugriff auf diese Variable ist kritisch !!

Jonas

Line

Jonas

Line

Jonas

Typewriter

n


110

Stichworte

Notizen


das Erzeuger-Verbraucher-Problem

Erzeuger-Algorithmus:1. Nimm nächstes Element2. Lies die Variable Anzahl3. Wenn Puffer voll, dann “Schlafen-gehen”4. Element in den Puffer eintragen5. Anzahl um 1 erhöhen6. Wenn die Anzahl jetzt 1 lautet, “Leser-wecken”

Leser-Algorithmus:1. Lies die Variable Anzahl2. Wenn Puffer leer, “Schlafen-gehen”3. Element lesen4. Anzahl um 1 erniedrigen5. Wenn Puffer jetzt einen freien Platz hat, “Erzeuger-wecken”

Die beiden“gefährlichen”Stellen, hierdarf derScheduler nichtden Prozeßwechseln, sonstbricht dieSynchronisation

111

Stichworte

Notizen


das Leser-Schreiber-Problem

● auf eine Datei dürfen gleichzeitig mehrere Prozesse lesend zugreifen, ABER:● wenn ein Prozeß schreibend zugreift, darf kein anderer Prozeß (lesend oder schreibend)

agieren.Lösung 1: (Bevorzugt die Leser-Prozesse)Schreiber: Sperrt Datei, schreibt Daten, gibt Datei freiLeser: (Nur der erste Leser!! :) sperrt die Datei

ließt die Daten (Nur der letzte Leser!! :) gibt Datei wieder frei

Lösung 2: (Bevorzugt Schreiber-Prozesse)grundlegendes Konzept:

Prozesse mit Lesewunsch überprüfen die Existenz von schreibenden bzw. schreibwilligen Prozessen und blockieren, bis die Schlange der Schreiber leer ist.

112

Stichworte

Notizen


Semaphore: die IdeeIdee 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)

WICHTIG:● Das Überprüfen auf 0, ● das Verändern des Wertes von s ● und das Schlafengehen bzw. „Task wecken“ sindeine untrennbare, atomare Aktion des Betriebssystems!!

Struktur einesSemaphors Zähler

Zeiger auf wartende Threads/Tasks

113

Stichworte

Notizen


Semaphore: die Implementierung

Jonas

Highlight

!!!


114

Stichworte

Notizen


wechselseitiger Ausschluß mit Semaphoren

Zwei Prozesse 1 und 2 konkurrieren um den Eintritt in einen kritischen Bereich.Semaphor s ist initial auf 1 gesetzt

Prozeß 1:... beliebige Aktionen ...down(s) <= Eintritt in kritischen Bereich...kritischer Bereich ...up(s) <= Austritt aus dem kritischen Bereich

Prozeß 2:... beliebige Aktionen ...down(s) <= Eintritt in kritischen Bereich...kritischer Bereich ...up(s) <= Austritt aus dem kritischen Bereich

115

Stichworte

Notizen


Er zeuger - Pr ozess:

LOOPpr oduzi er e( ei nEl ement ) ;P( f r ei ) ;P( mut ex) ;f uel l eI nPuf f er ( ei nEl ement ) ;V( mut ex) ;V( bel egt ) ;

END

Erzeuger-Verbraucher-Problem gelöst mit Semaphoren

Zwei Semaphore „f r ei “ und „bel egt “ werden benutzt um zwischen den Prozessen die Zustände des Puffers zu signalisieren. Der Semaphor „mut ex“ dient nur dazu, den Zugriff auf den Puffer exklusiv zu machen. Der Puffer fasst N Elemente. Initial gilt:

Semaphor frei = N, belegt = 0, mutex = 1;

Ver br aucher - Pr ozess:

LOOPP( bel egt ) ;P( mut ex) ;hol eAusPuf f er ( ei nEl ement ) ;V( mut ex) ;V( f r ei ) ; ver ar bei t e( ei nEl ement ) ;

END

Jonas

Typewriter

mutex = mutual exchusion = gegenseitiger / wechselseitiger Ausschluss


Jonas

Typewriter

P = DOWN V = UP

116

Stichworte

Notizen


Leser-Schreiber-Problem gelöst mit Semaphoren

Hier Bevorzugung der Leser: ein gemeinsamer Zähler „Anzahl Leser “ zählt die Anzahl der Leser im kritischen Abschnitt. Ein Semaphor „LeseSem“ schützt diesen Zähler, ein zweiter Semaphor „ l ock “ schützt den exklusiven Zugang zum Lesen/Schreiben. Initial gilt:Anzahl Leser = 0; l ock = 1; Zaehl er Semaphor = 1;

Leser - Pr ozess:

{ . . . / / t ue i r gendwas ander es

P( Zaehl er Semaphor ) ;

Anzahl Leser ++;

i f ( Anzahl Leser ==1) t hen P( l ock) ;V( Zaehl er Semaphor ) ;

. . . l eseDi eDat en( ) ; . . .

P( Zaehl er Semaphor ) ;

Anzahl Leser - - ;

i f ( Anzahl Leser ==0) t hen V( l ock) ;

V( Zaehl er Semaphor ) ;. . . / / t ue i r gendwas ander es

}

Schr ei ber - Pr ozess:

{. . . / / t ue i r gendwas ander esP( l ock) ;. . . modi f i z i er eDi eDat en( ) ; . . .V( l ock) ;. . . / / t ue i r gendwas ander es

}

ein Schreiber im kritischen Abschnitt:� der erste Leser, der kommt,

wird durch l ock blockiert.

Kommen weitere Leser, so warten diese auf Zaehl er Semaphor

117

Stichworte

Notizen



Bevorzugung der Schreiber:

ein Schreiber erhält frühestmöglich Zutritt zum kritischen Abschnitt, d.h. ebenfalls wartenden Lesern wird der Zugriff so lange verwehrt, bis keine Schreiber mehr warten. Die Lösung umfasst:

■ 2 Zähler Anzahl Leser und Anzahl Schr ei ber ,

die die Anzahl der Leser/Schreiber zählen

■ 2 Semaphore Leser Semund Schr ei ber Sem, die diese Zähler schützen

■ 1 Semaphor l ock , der wie vorhin den exklusiven Zugriff auf die Daten schützt

■ 1 Semaphor R erzwingt die Bevorzugung der Schreiber vor den Lesern

■ 1 Semaphor M stellt sicher, dass maximal ein Leser einem Schreiber zuvorkommt, egal

wie der Scheduler agiert! Beispiel: zwei Leser und ein Schreiber greifen fast gleichzeitig zu: im schlimmsten Fall hat dann nur ein Leser die Nase vorn (siehe Folgefolien)

Die Initiliasierung sieht so aus:I nt Anzahl Leser = 0, Anzahl Schr ei ber = 0;

Semaphor Leser Sem=1, Schr ei ber Sem=1, R=1, M=1, l ock=1;

118

Stichworte

Notizen



Der Leserprozess bei Bevorzugung der Schreiber

{ . . . / / t ue i r gendwas ander esP( M) ; / / so kommt auf j eden Fal l nur ei n Leser dur ch!

P( R) ; / / hi er geht ’ s nur wei t er , wenn kei n Schr ei ber akt i v i s tP( Leser Semaphor ) ;

Anzahl Leser ++;i f ( Anzahl Leser ==1) t hen P( l ock) ;

V( Leser Semaphor ) ;V( R) ;

V( M) ;

. . . l eseDi eDat en( ) ; . . . / / di es hi er i s t der kr i t i sche Abschni t t

P( Leser Sem) ;Anzahl Leser - - ;i f ( Anzahl Leser ==0) t hen V( l ock) ; / / kei n Leser mehr da � Fr ei gabe

V( Leser Sem) ;. . . / / t ue i r gendwas ander es

}

119

Stichworte

Notizen



Der Schreiberprozess bei Bevorzugung der Schreiber

{ . . . / / t ue i r gendwas ander esP( Schr ei ber Semaphor ) ;

Anzahl Schr ei ber ++; / / der er st e Schr ei beri f ( Anzahl Schr ei ber == 1) t hen P( R) ; / / sper r t di e Leser

V( Schr ei ber Semaphor ) ;

P( l ock) ; / / Sper r e Dat ei. . . bear bei t eDi eDat en( ) ; . . . / / di es hi er i s t der kr i t i sche Abschni t t

V( l ock) ; / / ent sper r e Dat ei / / es können aber nur ander e Schr ei ber dr an

P( Schr ei ber Semaphor ) ;Anzahl Schr ei ber - - ; / / der l et zt e Schr ei beri f ( Anzahl Schr ei ber == 0) t hen V( R) ; / / gi bt di e Leser wi eder f r ei

V( Schr ei ber Semaphor ) ;. . . / / t ue i r gendwas ander es

}

120

Stichworte

Notizen


Semaphore in Echtzeitsystemen

Durch kritische Abschnitte können Prozessprioritäten verletzt werden, Beispiel:

● P3 macht zuerst das P(S), gewinnt das Rennen um den kritischen Abschnitt

● 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

● Das V(S) von P3 lässt dann P2 weiterlaufen, obwohl der höher priorisierte P1 ebenfalls weiterlaufen könnte...

● Die Lösung: Einreihung der Tasks in die Semaphor-Queue nicht chronologisch sondern nach Prozess-Priorität !

121

Stichworte

Notizen


Semaphore in Echtzeitsystemen

Problem 2:● Ein Prozess P3 mit niedrigster Priorität sei im kritischen Abschnitt● Ein Prozess P1 hoher Priorität wartet am zugehörigen Semaphor● 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!!● 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 wartetBei Verlassen des kritischen Abschnitts fällt der Prozess wieder auf seine alte Priorität

Unnötig!!

122

Stichworte

Notizen


Prioritätsvererbung durch Semaphore

Problem 2 gelöst durchPrioritätsvererbung

P3 erhält die hohe Priorität von P1 � Scheduler wählt NICHT P2 !

P3 fällt auf alte Priorität zurück

P1 erhält nun sofort die CPU,P2 kommt erst danach

123

Stichworte

Notizen


Ereigniszähler

Vermeidung zeitkritischer Abläufe mit Semaphoren = wechselseitiger Ausschluß

Ereigniszähler = Lösung OHNE wechselseitigen Ausschluß

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 EAdvance(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 !!!

124

Stichworte

Notizen


Lösung des Erzeuger-Verbraucher-Problems mit zwei Ereigniszählern

N = ( z.B.) 100 /* Größe des Puffers */Ereigniszaehler rein=0, raus=0; /* zählen die eingefügten/entnommenen Einträge */

Erzeuger:int zaehler=0; /* alle Einträge werden durchnummeriert */Schleife: zaehler inkrementieren

await(raus, zaehler-N); /* warten bis Platz im Puffer ist */Element einfügen ...advance(rein);

Verbraucher:int vzaehler=0;Schleife: vzaehler inkrementieren

await(rein,vzaehler) /* warte bis ein Element im Puffer ist */Element entnehmen...advance(raus)

125

Stichworte

Notizen


Nachrichtenaustausch

Problem aller bisherigen Synchronisationsverfahren: Man braucht einen GEMEINSAMEN Speicherplatz für die partizipierenden Prozesse !!

Erkenntnis: Dann funktionieren diese Verfahren nicht über Rechnergrenzen hinweg !!

Problem: Wir brauchen ein Synchronisationsverfahren auch in verteilten Systemen

Idee: Synchronisation durch Nachrichtenaustausch

Wir definieren zwei Systemfunktionen:

sende(Ziel, Nachricht) Sendet die Nachricht an das angegebene Zielempfange(Quelle, Nachricht) Empfängt eine Nachricht von der Quelle und blockiert,

d.h. wartet, solange keine Nachricht kommt.

126

Stichworte

Notizen


Lösung des Erzeuger-Verbraucher-Problems mit Nachrichten

N = ( z.B.) 100 /* Größe des Puffers */

Erzeuger:

Schleife: empfange(Verbraucher, leere Nachricht)... setze Element in die leere Nachricht ...sende(Verbraucher, Nachricht mit Element)

Verbraucher:

Wiederhole 100 mal: sende(Erzeuger, leere Nachricht)Schleife: empfange(Erzeuger, Nachricht mit Element)

... entnehme Element aus der Nachricht und verarbeite es...sende(Erzeuger, leere Nachricht)

127

Stichworte

Notizen


Monitore, die IdeeProblem: 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);

Idee: man überlasse einem Compiler die richtige Anordnung der Befehle und finde ein höheres, abstrakteres Sprachkonstrukt � den kritischen Bereich (critical region)

Statt: P( s) ; <kr i t i sche Bef ehl e> V( s) ;

Nun: shar ed s;

r egi on s do <kr i t i sche Bef ehl e>;

Der vom Compiler erzeugte Code garantiert, dass nur einer von mehreren Prozessen im kritischen Code arbeitet.

Monitor1973-74 (!!) haben Hansen und Hoare das Konzept erweitert: Man nehme einen ADT (heute Klasse), der die Aufgabe übernimmt

■ alle darin enthaltenen und von außen ansprechbaren Prozeduren ■ und die lokalen Daten, Variablen und Funktionen

■ durch Synchronisationsmechanismen automatisch zu schützen und

■ den wechselseitigen Ausschluss von Prozessen darin zu garantieren.

Diese Klasse nannte man einen MONITOR

Monitor = Zusammenfassung der

gemeinsam genutzten Daten und

der darauf definierten Zugriffsfunktionen

128

Stichworte

Notizen


Monitore, das KonzeptMoni t or Moni t or name ( Par amet er )

Dat endekl ar at i onen; / * gemei nsame Dat en * /

ENTRY Funkt i onsname1 ( Par amet er ) { Pr ozedur kör per }



. . .

ENTRY Funkt i onsnameN ( Par amet er ) { Pr ozedur kör per }

I NI T { I ni t i al i s i er ungsanwei sungen }

END

Die Initialisierung der Monitordaten erfolgt durch einmaligen Aufruf vonMoni t or name( akt uel l e Par amet er ) ;

Dadurch wird letztendlich der Initialisierungsteil durchlaufen.Prozesse benutzen den Monitor durch Aufruf der Monitorprozeduren in der Form:

Moni t or name. Funkt i onsname ( akt uel l e Par amet er ) ;

129

Stichworte

Notizen


Monitore, die Vorteile

● Gemeinsam (durch mehrere Prozesse) bearbeitete Daten werden explizit in der

Programmstruktur sichtbar gemacht

� sie sind in Monitoren organisiert

● Die bereitgestellten Monitorprozeduren definieren allein

die Zugriffsalgorithmen zu den Monitordaten.

● Ein Umgehen der Monitorprozeduren ist nicht möglich

● Monitore kapseln wie Module die gemeinsamen Daten.

Eine Änderung der monitorinternen Datenstrukturen und Algorithmen bleibt für

Prozesse unsichtbar, solange die Schnittstelle unverändert bleibt � information hiding

130

Stichworte

Notizen


Erzeuger-Verbraucher-Problem gelöst mit einem Monitor

Erzeuger und Verbraucher-Prozesse:

Er zeuger

LOOP{

pr oduzi er e( El ement ) ;Buf f er . put I nBuf f er ( El ement ) ;

}END

Ver br aucher

LOOP{

Buf f er . get Fr omBuf f er ( El ement ) ;ver ar bei t e( El ement ) ;

}END

131

Stichworte

Notizen



Deklaration des Monitors:

132

Stichworte

Notizen



Monitor ist unvollständig ! Was fehlt ?

� Implementierung der beiden zentralen Prozeduren!

Problem: wir brauchen zusätzliche Wartebedingungen zur Kontrolle des Pufferüber-/unterlaufs

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 Taskswait(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 f r ei , bel egt : CONDI TI ON

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

133

Stichworte

Notizen



Die zentralenMonitor-Prozeduren

134

Stichworte

Notizen


Ein klassisches IPC-Problem

das Philosophenproblem

(oder: die Rangelei um den exklusiven Zugriff auf begrenzte Betriebsmittel )

Problem: Ein Philosoph ißt oder denkt. (richtig ! Das ist eine seehr starke Abstraktion!!)● Es sitzen 5 Philosophen am Tisch mit fünf Tellern und fünf Gabeln● 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.

Aufgabe: Man finde für die Philosophen Mittagszeit bei den Philosopheneinen funktionierenden Algorithmus !!

Einfache, aber fehlerhafte Lösung:

Philosoph denkt ...nimmt linke Gabel auf

nimmt rechte Gabel aufißt von seinem Teller

legt linke Gabel zurücklegt rechte Gabel zurück

135

Stichworte

Notizen


prinzipieller Lösungsansatz für

das Philosophenproblem

● Man muß den Zugriff auf die beiden Gabeln und andere gemeinsame Ressourcen regeln● Es gibt also eine Semaphore G für den wechselseitigen Ausschluß

● Jeder Philosoph befindet sich in einem von drei Zuständen: denkend, hungrig, essend● Es gibt also je Philosoph i eine Zustandsvariable Z(i) 1<=i<=5 mit den Werten d,h,e

● Ein hungriger Philosoph ist blockiert, wenn er nicht beide Gabeln erhält. (mit leerem Magen kann man nicht denken)

● Es gibt somit je Philosoph eine Semaphore S(i) 1<= i<=5

● Hat ein Philosoph seine Mahlzeit beendet, so schaut er, ob seine Nachbarn jetzt essen könnten und weckt sie gegebenenfalls auf

136

Stichworte

Notizen


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)

Kap4

Technology

Transcript of Kap4