Monitor in der Informatik: Synchronisation verstehen

Ein Thread ist ein Ablauf innerhalb eines Programms. Mehrere Threads können dieselben Daten benutzen. Ein kritischer Abschnitt ist eine Ansammlung von Programmanweisungen, in der sich zu einer Zeit nur ein einziger Thread aufhalten darf. Er besteht aus mehreren Einzelanweisungen. Deren Zwischenergebnisse sind inkonsistente Zustände, auf die andere Threads keinen Zugriff erhalten dürfen. Nach außen darf das Ergebnis nur als eine unteilbare Einheit sichtbar werden.

Wenn sich ein Thread in einem kritischen Abschnitt bezüglich eines Betriebsmittels befindet, darf kein anderer Thread in einen kritischen Abschnitt bezüglich desselben Betriebsmittels gelangen. Das nennt man wechselseitigen Ausschluss. Eine strenge Reihenfolge der Nutzung ist dafür nicht nötig.

Ein Monitor ist ein Modul (zum Beispiel eine Klasse), in dem die gemeinsam genutzten Daten und ihre Zugriffsprozeduren zu einer Einheit zusammengeführt sind. Zugriffsprozeduren mit kritischen Abschnitten werden als Monitor-Operationen gekennzeichnet. Sie laufen unter wechselseitigem Ausschluss, ohne dass im Programmcode Synchronisationsanweisungen stehen müssen. Ruft ein Prozess A eine Monitor-Operation auf, während diese oder eine andere Monitor-Operation schon von einem Prozess B ausgeführt wird, wird A blockiert. Man stellt sich den Monitor oft als Raum vor, in dem nur ein Akteur Platz findet.

Manchmal stellt ein Prozess in einer Monitor-Operation fest, dass die Daten gerade in einem Zustand sind, in dem er nicht sinnvoll weitermachen kann. Ohne weitere Mittel müsste er die Operation beenden, den Monitor verlassen und später erneut anfragen. Das führt zu unerwünschtem mehrfachem Prüfen und Warten.

Deshalb gibt es Bedingungsvariablen. Sie stehen für Bedingungen, die erfüllt sind oder nicht. Auf einer Bedingungsvariablen b gibt es zwei Operationen: wait() und signal(). Ruft ein Prozess in einer Monitor-Operation wait() an b auf, wird er blockiert und außerhalb des Monitors in eine Warteschlange zu b eingefügt. Jetzt ist kein Prozess mehr im Monitor aktiv, ein anderer Prozess kann den Monitor von außen betreten.

Ruft ein anderer Prozess in einer Monitor-Operation signal() an b auf, wird der blockierte Prozess deblockiert. Wartet zum Zeitpunkt des Aufrufs kein Prozess an b, ist der Aufruf ohne Auswirkung. Ein Monitor hat oftmals eine Monitor-Warteschlange, und jede Bedingungsvariable hat eine eigene Warteschlange.

Nach einem signal() gibt es ein Problem. Der deblockierte Prozess könnte an der Stelle weitermachen, an der er wait() aufgerufen hat. Aber der signalisierende Prozess ist ja noch im Monitor. Dafür wurden zwei Formen entwickelt.

Beim Hoare-Typ prüft signal zuerst, ob die Warteschlange der Bedingungsvariablen Prozesse enthält. Ist sie nicht leer, wird der signalisierende Prozess blockiert und in die Monitor-Warteschlange eingetragen. Ein Prozess aus der Warteschlange der Bedingungsvariablen wird deblockiert. Der signalisierende Prozess wird in der Regel erst fortgesetzt, nachdem der deblockierte Prozess den Monitor verlassen hat. Man nennt das auch Signal and Wait.

Beim Mesa-Typ blockiert signal den signalisierenden Prozess nicht. Er wird stets fortgesetzt. signal reiht stattdessen einen Prozess von der Warteschlange der Bedingungsvariablen in die Monitor-Warteschlange um. Man nennt das auch Signal-and-Continue (etwa: signalisieren und fortfahren).

In Java hat prinzipiell jedes Objekt Monitorfähigkeiten. Methoden, die kritische Abschnitte auf Attributen enthalten, kennzeichnest du mit dem Schlüsselwort synchronized als Monitor-Operationen. Jedes Objekt der Klasse ist dann der Monitor für seine Attribute. Rufen mehrere Threads synchronized-Methoden am selben Objekt auf, läuft zu jedem Zeitpunkt höchstens ein Thread in einer solchen Methode. Der Monitor hat einen Monitor-Lock (Sperre) und eine Warteliste für ausgesperrte Threads. Endet eine synchronized-Methode oder ein synchronized-Block, wird die Sperre aufgehoben und der nächste Thread kommt zum Zug.

Java sieht keine Bedingungsvariablen vor. Für die Bedingungssynchronisation gibt es in der Klasse Object diese Methoden: wait() blockiert den aufrufenden Thread und gibt den Monitor frei. notify() entblockiert irgendeinen an diesem Monitor blockierten Thread, der weiterlaufen kann, sobald der Monitor frei ist. Dieses Verhalten ist nicht „fair“. notifyAll() entblockiert alle an diesem Monitor blockierten Threads.

Wegen der fehlenden Bedingungsvariablen muss ein deblockierter Thread seine Bedingung erneut prüfen. Sie könnte noch nicht gültig sein oder schon durch schnellere Threads wieder ungültig gemacht worden sein. Als Pseudocode (kein Java) sieht das so aus: solange ( nicht bedingung ) wait(). Das setzt voraus, dass beim Ändern der Variablen, auf die sich die Bedingung bezieht, stets notify aufgerufen wird.