Kap4

958 Aufrufe

Veröffentlicht am

Veröffentlicht in: Technologie
0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
958
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
23
Aktionen
Geteilt
0
Downloads
8
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Kap4

  1. 1. 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
  2. 2. Copyright(C) by Foxit Software Company,2005-2007 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. Edited by Foxit Reader 1. nur ein Prozeß darf sich zu einem Zeitpunkt in einem kritischen Bereich befinden Problem: siehe Beispiel “gespoolte Druckausgabe” For Evaluation Only. 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 Stichworte Stichworte Gute Idee, funktioniert aber in der Realität nicht! Notizen Notizen 102 103
  3. 3. 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?   Prof. W. Burkard 104 Prof. W. Burkard 105 Stichworte Stichworte Notizen Notizen 104 105
  4. 4. Copyright(C) by Foxit Software Company,2005-2007 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 */ Edited by Foxit Reader interessiert[process] = TRUE; /* ich zeige mein Interesse */ dran = prozess; /* setze Marke: ich bin dran! */ For Evaluation Only. 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 Stichworte Stichworte 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
  5. 5. Copyright(C) by Foxit Software Company,2005-2007 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 Edited by Foxit Reader Neue Idee: wartende Prozesse “gehen schlafen” (werden in den Zustand For Evaluation Only. “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 !! Prof. W. Burkard 108 Prof. W. Burkard 109 Stichworte Stichworte Notizen Notizen 108 109
  6. 6. 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” Prof. W. Burkard 110 Prof. W. Burkard 111 Stichworte Stichworte Notizen Notizen 110 111
  7. 7. Copyright(C) by Foxit Software Company,2005-2007 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) Edited by Foxit Reader Struktur eines Semaphors For Evaluation Only. 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!! Prof. W. Burkard 112 Prof. W. Burkard 113 Stichworte Stichworte Notizen Notizen 112 113
  8. 8. Erzeuger-Verbraucher-Problem Copyright(C) by Foxit Software Company,2005-2007 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); Edited by Foxit Reader Prozeß 2: V = UP P(frei); P(mutex); For Evaluation Only. ... 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 Prof. W. Burkard 114 Prof. W. Burkard 115 Stichworte Stichworte mutex = mutual exchusion = gegenseitiger / wechselseitiger Ausschluss Notizen Notizen 114 115
  9. 9. 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; Prof. W. Burkard 116 Prof. W. Burkard 117 Stichworte Stichworte Notizen Notizen 116 117
  10. 10. 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 } } Prof. W. Burkard 118 Prof. W. Burkard 119 Stichworte Stichworte Notizen Notizen 118 119
  11. 11. 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 ! Prof. W. Burkard 120 Prof. W. Burkard 121 Stichworte Stichworte Notizen Notizen 120 121
  12. 12. 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 Stichworte Stichworte Notizen Notizen 122 123
  13. 13. 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) Prof. W. Burkard 124 Prof. W. Burkard 125 Stichworte Stichworte Notizen Notizen 124 125
  14. 14. 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 Prof. W. Burkard 126 Prof. W. Burkard 127 Stichworte Stichworte Notizen Notizen 126 127
  15. 15. 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 ); Prof. W. Burkard 128 Prof. W. Burkard 129 Stichworte Stichworte Notizen Notizen 128 129
  16. 16. 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 Prof. W. Burkard 130 Prof. W. Burkard 131 Stichworte Stichworte Notizen Notizen 130 131
  17. 17. 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! Prof. W. Burkard 132 Prof. W. Burkard 133 Stichworte Stichworte Notizen Notizen 132 133
  18. 18. 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 Prof. W. Burkard 134 Prof. W. Burkard 135 Stichworte Stichworte Notizen Notizen 134 135
  19. 19. 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

×