Was haben wir kennengelernt? Wir haben den Monitor kennengelernt. Den haben wir als abstrakten

Datentypen mit impliziten Synchronisationseigenschaften verstanden, wo wir denn einerseits die mehrseitige

Synchronisation von den Monitorprozeduren halt haben und dann die einseitige Synchronisation

durch Bedingungsvariablen innerhalb des Monitors zum Austausch bringen können.

Die Architektur von so einem Monitor kann sehr unterschiedlich sein und damit bekommt

man noch sehr unterschiedliche Ausführungsarten mit unterschiedlichen Semantiken, die gerade

mit den Bedingungsvariablen verbunden sind.

Wir haben gesehen, dass es Monitore gibt, wo denn die Bedingungsvariablen beidseitig durchaus

blockieren oder nur einseitig.

Also beidseitig bedeutet, Weight und Signal führt dazu, dass ein Prozess praktisch den

Monitor freigibt und einseitig führt dazu, dass nur die Weight-Operation dazu führt,

einen Prozess logisch zu blockieren.

Im Endeffekt darauf, dass eine bestimmte Bedingung eintreten muss und der dann mit natürlich

Implizit den Monitor freigeben muss.

Dann gibt es aber die Hauptunterschiede in der Semantik der Signalisierung.

Da haben wir eine ganze Reihe gehabt, wir haben gesehen, dass die Signalisierung blockierend

oder nicht blockierend für den Prozess wirken kann, der so ein Ereignis signalisiert, also

anzeigt.

Es kann so sein, dass die Signaloperation dazu führt, dass nur ein Prozess oder eben

alle Prozesse, die auf dieses Ereignis warten, deblockiert werden.

Es kann so sein, dass die Wartepedingung für einen Prozess, der signalisiert worden ist,

nach Rückkehr aus der Weight-Operation garantiert ist oder dass die nicht mehr garantiert werden

kann.

Es kann eben auch so sein, dass die Auswertung der Wartepedingung, nachdem man aus einer Weight-Operation

rausgekommen ist und die Ausführung wieder aufnimmt, dass diese erneute Auswertung der

Wartepedingung notwendig ist oder dass die nicht notwendig ist.

Und wir haben auch gesehen, dass es sein kann, dass falsche Signalisierung vorgebeugt werden

kann durch bestimmte Arten von Monitoren oder dass man intolerant gegenüber ist, dass man

so konkret und sauber programmieren muss, um sicherzustellen, dass natürlich hier das

nicht sequenzielle Programm, das dieser Monitor repräsentiert, korrekt abläuft.

Wir haben auch kurz erwähnt, Java kennt man ja aus dem ersten Semester, dass eben so eine

Java-Objekte eigentlich keine Monitore sind.

Sie können aber als solche verwendet werden.

Java bietet nicht solche Monitor-Objekte an, aber es bietet spezielle Konstrukte an, wie

der Synchronized-Konstrukt, um Prozeduren, Monitor-Eigenschaften im Sinne von Monitor-Prozeduren

denn letztendlich zu geben.

Allen gemeinsam ist es, dass es ein Programmiersprachenmittel ist.

Das heißt, wir haben spezielle Programmiersprachen, mit denen wir nicht sequenzielle Programme

schreiben können, wo man Monitore zum Ausdruck bringen kann, wie Signalisierung und Wartepedingungen

entsprechend zum Ausdruck bringen kann.

Das sind dann alles spezielle Keywords in unserer Sprache.

Und wir haben einen Compiler, der einfach aus diesen Schlüsselworten und aus diesen Konzepten

dann automatisch den Code generiert.

Insbesondere haben wir also Compiler, die für die Monitor-Prozeduren automatisch die kritischen

Abschnitte, den Schutz dieser Abschnitte definiert und dafür die entsprechenden mehrseitigen

Synchronisationsprimitiven generiert.

Und das führt dann letztendlich dazu, dass man eigentlich ein schönes Hilfsmittel hat

und schöne Konzepte eben doch bekommt, um nicht sequenzielle Programme, insbesondere

größere, nicht sequenzielle Programme, sauber und recht korrekt formulieren zu können.