Sascha Kretzschmann Institut für Informatik Monitore Formatvorlage und deren Umsetzung des Untertitelmasters durch Klicken bearbeiten
Inhalt 1. Monitore und Concurrent Pascal 1.1 Warum Monitore? 1.2 Monitordefinition nach Per Brinch Hansen / Hoare 1.3 Zusammenfassung 1.4 Verwendung in Concurrent Pascal 2. Monitore und Java 2.1 Umsetzung in Java 2.2 Zusammenfassung 3. Beispiel Bounded Buffer 2
Sascha Kretzschmann Institut für Informatik Monitore und Concurrent Pascal Formatvorlage Definition von Monitoren des Untertitelmasters und ihre Umsetzung durch in Klicken Concurrent bearbeiten Pascal
Monitore und Concurrent Pascal Warum Monitore? 4
Warum Monitore? wichtigstes Sicherheitskriterium für nichtsequenzielle Programmierung ist die Gewährleistung von mutual exclusion vor Einführung der Monitore, Semaphore gute Möglichkeit zum Synchronisieren birgt jedoch einige Probleme und Gefahren um sicher mit konkurrierenden Prozessen umgehen zu können und sich als Benutzer nicht um die Umsetzung kümmern zu müssen -> Monitore Per Brinch Hansen und C.A.R. Hoare führte Sie als neues Programmierkonzept ein 5
Monitore und Concurrent Pascal Monitore nach Brinch Hansen / Hoare 6
Vorüberlegung wollte Pascal um nichtsequenzielle Elemente erweitern Sprachkonzept entwickeln, wodurch Prozesse gemeinsame Daten sicher nutzen können Wie können nun Prozesse Daten gemeinsam nutzen, ohne unerwünschte Nebeneffekt (wie zum Beispiel race condition)? 7
Monitore nach Brinch Hansen / Hoare Monitor ist ein Konstrukt, welches parallele Prozesse synchronisiert und ggf. Zugriffreihenfolge kontrolliert definiert Variablen, auf die man nur über Prozeduren zugreifen kann zusätzlich Möglichkeit, Bedingungsvariablen (condition variable) zu definieren auf diese können folgende Operationen ausgeführt werden -> wait(c) -> signal(c) -> signal_all(c) -> empty(c) 9
Monitore nach Brinch Hansen / Hoare (cont.) Prozess kann Prozedur nur ausführen, wenn kein Anderer diese ausführt ist diese gerade belegt, gelangt er in die entry queue und wartet dabei wird zwischen vier verschiedenen Varianten unterschieden: -> signal-and-continue -> signal-and-wait -> signal-and-urgent-wait -> signal-and-return 10
Monitore nach Brinch Hansen / Hoare (cont.) Wie wird nun die interne Abarbeitung der einzelnen Prozesse geregelt Betrachtung zwei verschiedener Typen : Hoare sytle monitor Mesa style monitor 11
Monitore und Concurrent Pascal Zusammenfassung 12
Zusammenfassung 1. Monitore sind historisch das erste nicht triviale Sprachkonzept für Synchronisation. 2. 3. Jede condition varible bringt eine eigene Warteschlange, in der Prozesse separat verzögert werden können, um auf bestimmte Bedingungen zu warten. 4. 5. Wird eine Bedingung erfüllt, bekommen wartende Prozesse ein Signal 6. 7. Dabei gibt es vier verschiedene Varianten des Signalisierens, die Einfluss auf die Ausführungsreihenfolge haben (können). 13
Monitore und Concurrent Pascal Umsetzung in Concurrent Pascal 14
Umsetzung in Concurrent Pascal mit bekannten Mitteln (Monitor, Prozess) ist es möglich, einfache Systeme umzusetzen wollen spooling system nach Brinch Hansen in Concurrent Pascal betrachten zwei Puffer (disk buffer) für die Auslagerung; drei Prozesse jeweils für input und output und zur Bearbeitung (job process) 15
Umsetzung in Concurrent Pascal (cont.) Möglichkeit, system types in kleinere Teile zu unterteilen gibt Puffer die Illusion, dass er seinen eigenen Speicher (disk) besitzt jede virtuelle Disk wird lediglich von einem Puffer benutzt Klassen können nicht gleichzeitig von mehreren anderen Systemkomponenten aufgerufen werden (vgl. Monitor) jedoch Klassenaufruf wesentlich schneller als Monitoraufrufe 16
Umsetzung in Concurrent Pascal (cont.) disk resource regelt Benutzung der Disk durch konkurrierende Prozesse bei Fehlern, Meldung an die virtuellen Konsolen (wiederrum repräsentativ für reale Konsole) 17
Umsetzung in Concurrent Pascal (cont.) Aufbau folgt immer gleichem Schema, nur mit verschiedenen Geräten darum hier noch einmal das Konsolenkonstrukt zur Veranschaulichung: 18
Umsetzung in Concurrent Pascal (cont.) setzen wir alles zusammen, erhalten wir das komplette hierarchische Spooling Systems: 19
Sascha Kretzschmann Institut für Informatik Monitore und Java Formatvorlage Umsetzung des des Monitorkonzepts Untertitelmasters in Java. durch Klicken bearbeiten
Monitore und Java Umsetzung in Java 21
Umsetzung in Java Java benutzt Threads um nichtsequenzielle Programmierung zu ermöglichen Java besitzt kein speparates Sprachkonstrukt zur Erzeugung eines Monitors folgendes beachten, um Monitor Klasse in Java umzusetzen 1. Instanzvariablen der Klasse müssen private deklariert werden 2. Methoden müssen synchronized deklariert werden 3. Benutzung von (bedingter Synchronization mit) wait(), notify(), notifyall() 22
Umsetzung in Java (cont.) es existieren keine Bedingungsvariablen, jedes Objekt hat lediglich einen lock und für den Monitor existiert eine einzige wait queue alle Threads in wait queue verwaltet Java style monitor 23
Umsetzung in Java (cont.) nun kann es sein, dass Threads verzögert werden müssen dafür gibt es die Möglichkeit der bedingten Synchronisation es stehen drei Methoden zur Verfügung (im Folgenden seien T1 und T2 konkurrierende Threads, die sich auf das Objekt o synchronisieren) 1. o.wait(): Lock von o wird freigegeben; aufrufender Thread in Warteschlange 2. o.notify(): weckt Thread auf, der dann wartet, bis er Lock von o bekommt (signal-and-continue) 3. o.notifyall(): wie notify(), nur werden alle Threads aufgeweckt 24
Umsetzung in Java (cont.) Synchronisation erfolgt also über die Objekte Thread eignet (acquire) sich Lock beim Aufruf einer synchronized Methode an danach Freigabe des Locks 25
Monitore und Java Zusammenfassung 26
Zusammenfassung 1. In Java existiert kein Monitorkonstrukt, sowie keine Bedingungsvariablen. 2. 3. Die Umsetzung eines Monitors in Java ist immer eine Variation des Monitores nach Mesa mit signal-and-continue. 4. 5. Bedingungsvariablen können simuliert werden, in dem über das Lock von Objekten synchronisiert wird. 6. 7. Die in 3. beschriebene Methode kommt der klassischen Umsetzung von Monitoren zwar sehr nah, ist jedoch umständlich und fehleranfällig 8. 9. Sind alle Methoden einer Klasse synchronized deklariert, entspricht dies der klassischen Monitorvariante. 27