Kritischer Abschnitt: Race Conditions verstehen

Ein Thread ist ein Ablauf, der Programmanweisungen ausführt. Mehrere Threads können dieselben Daten benutzen. Viele Änderungen bestehen aus mehreren Einzelschritten. Zwischen diesen Schritten ist der Zustand der Daten nicht stimmig. Man nennt ihn inkonsistent.

Ein Beispiel ist das Erhöhen eines Zählers um 1. Es wird hier angenommen, dass der Zugriff auf den Zähler nur mit einer Lese- oder einer Schreiboperation möglich ist, nicht mit einer von Haus aus unteilbaren Erhöhung. Dann sind es drei Schritte: den Zähler in eine lokale Variable lesen, die lokale Variable um 1 erhöhen, die lokale Variable in den Zähler schreiben.

Kritische Abschnitte bestehen aus mehreren Einzelanweisungen. Ihre Zwischenergebnisse sind inkonsistente Zustände, auf die andere Threads keinen Zugriff erhalten dürfen. Kritisch ist so ein Abschnitt, wenn er auf ein gemeinsam genutztes Betriebsmittel zugreift, das nur exklusiv benutzt werden darf, zum Beispiel eine gemeinsame Variable, die er verändert. Das Ergebnis darf nur als eine unteilbare Einheit nach außen sichtbar werden. Eine Operation, die als Ganzes abläuft und von anderen nicht unterbrochen werden kann, heißt atomare Operation.

Zwei Threads, X und Y, führen denselben Abschnitt aus: Zähler lesen, um 1 erhöhen, Zähler schreiben. Das Betriebssystem verschränkt die beiden Abläufe zeitlich. Die Threads haben darauf standardmäßig keinen Einfluss.

Im Ablauf der Tabelle lesen beide Threads den Zähler, bevor einer von ihnen schreibt. Beide haben dann den gleichen ursprünglichen Wert als private Kopie. Beide erhöhen ihre eigene Kopie um 1. Danach schreibt erst X und dann Y. Y überschreibt also, was X gespeichert hat. Der Zähler hat am Ende das falsche Ergebnis 1. Wir nehmen hier den Anfangswert 0 an. Dann hätte der Zähler nach zwei Erhöhungen den Wert 2.

Solch eine Situation heißt Race Condition (Wettlaufsituation). Das Ergebnis hängt davon ab, wie die Einzelschritte zeitlich liegen. Solche Fehler sind oft schwer zu finden. Fehler, die nur bei mehreren gleichzeitig laufenden Threads auftreten, zeigen sich möglicherweise unter normalen Betriebsbedingungen überhaupt nicht. Schon zusätzliche Protokollausgaben (Logging) oder ein Debug-Modus, also ein Modus zur Fehlersuche, können die Symptome völlig verschwinden lassen.

Manche Betriebsmittel dürfen ihrer Natur nach nur exklusiv benutzt werden. Betriebsmittel sind zum Beispiel Daten im Speicher, Verbindungen oder Geräte. Verändert ein Thread ein solches Betriebsmittel, darf es für andere Threads nicht zugreifbar sein. Ein Programmabschnitt, in dem so auf ein gemeinsam genutztes Betriebsmittel zugegriffen wird, ist ein kritischer Abschnitt.

Läuft die Ausführung solcher Abschnitte zeitlich verschränkt, führt das zu unvorhersagbaren Ergebnissen oder inkonsistenten Zuständen. Das hast du beim Zähler gesehen. Deshalb gilt: Wenn sich ein Thread in einem kritischen Abschnitt für ein Betriebsmittel befindet, darf kein anderer Thread in einen kritischen Abschnitt für dasselbe Betriebsmittel.

Das gilt auch für verschiedene Abschnitte. Beispiel B: Ein zweiter Abschnitt verringert dieselbe Variable zaehler um 1. Aus Konsistenzgründen darf sich dann zu einer Zeit maximal ein Thread in beiden Abschnitten aufhalten.

Es ist nicht erforderlich, eine strenge Reihenfolge festzulegen. Es reicht ein wechselseitiger Ausschluss: Die Abschnitte laufen nacheinander, in beliebiger Reihenfolge.

Eine Lösung für das Problem des kritischen Abschnitts muss mehrere Anforderungen erfüllen. Der wechselseitige Ausschluss (kurz Mutex, von englisch „mutual exclusion“) ist eine Gruppe von Verfahren, die das Problem lösen. Sie koordinieren den Ablauf so, dass andere Threads vom kritischen Abschnitt ausgeschlossen sind, solange einer darin ist.

Die Anforderungen stehen in der Tabelle. Sind sie erfüllt, kann die Konsistenz der Betriebsmittel gewährleistet werden. Außerdem kommt jeder Thread in endlicher Zeit in seinen kritischen Abschnitt und wird nicht grundsätzlich am Eintritt gehindert.

In Java gibt es dafür eine Standardlösung: den Block synchronized(obj). Jeder andere Thread, der ebenfalls synchronized(obj) aufruft, muss bis zum Ende dieses Abschnitts warten. Bei synchronized-Methoden gilt: Auf die Attribute eines Objekts greift zu jedem Zeitpunkt höchstens ein Thread im Rahmen einer solchen Methode zu.

Achtung: Der gegenseitige Ausschluss birgt die Gefahr von Verklemmungen (Deadlocks). Dabei kann keiner der Prozesse mehr fortfahren, weil jeweils ein Prozess den anderen blockiert.