Race Condition einfach erklärt

Eine Race Condition entsteht, wenn das Ergebnis gleichzeitig laufender Abläufe von ihrer zeitlichen Reihenfolge abhängt. Gleichzeitig laufend bedeutet hier nebenläufig: Die Abläufe sind im selben Zeitraum aktiv. Ihre Einzelschritte müssen nicht im exakt selben Augenblick stattfinden.

Wir nennen zwei Abläufe A und B. Jeder behält seine eigene Schrittfolge bei. Trotzdem können sich Schritte von A und B abwechseln. Diese Überlappung ihrer Schrittfolgen heißt Verschachtelung.

Im folgenden Modell gibt es eine gemeinsame Anzeige mit genau einem Textfeld. Jeder Schreibschritt ersetzt den bisherigen Text vollständig. Nach beiden Schreibschritten wird der Text abgelesen. Allein der Zugriff auf gemeinsame Daten reicht als Erklärung einer Race Condition noch nicht: Entscheidend ist, dass die Reihenfolge das Ergebnis beeinflusst.

Ein Update ist eine Änderung eines gespeicherten Werts. Im ausgedachten Rechenmodell bearbeiten A und B einen gemeinsamen Punktestand. Er startet bei 12. A soll ihn um 4 erhöhen, B um 7. Beide Erhöhungen sollen genau einmal eingehen. Erwartet sind danach 23 Punkte.

Jede Erhöhung besteht im Modell aus drei Schritten: den gemeinsamen Wert lesen, mit dem gelesenen Wert rechnen und das Ergebnis zurückschreiben. Beim Lesen legt jeder Ablauf einen eigenen Zwischenwert an. Dieser lokale Wert gehört nur diesem Ablauf. Das Rechnen verändert zunächst diesen Zwischenwert; erst das Zurückschreiben verändert den gemeinsamen Punktestand. Schreibt der andere Ablauf inzwischen etwas zurück, ändert das einen bereits gelesenen Zwischenwert nicht.

Innerhalb jedes Ablaufs bleibt die Reihenfolge Lesen, Rechnen, Schreiben erhalten. Andere Zugriffe gibt es im Modell nicht. Die erste Tabelle zeigt A vollständig vor B. Die zweite zeigt eine Verschachtelung. „Kein Schritt“ bedeutet, dass der betreffende Ablauf in dieser Zeile keinen Schritt ausführt.

In der zweiten Tabelle rechnen beide mit 12. B schreibt zuletzt 19 und überschreibt damit As Ergebnis 16. As Erhöhung um 4 fehlt im Endwert. Das ist hier ein verlorenes Update. Das Beispiel zeigt eine mögliche fehlerhafte Reihenfolge; andere Reihenfolgen können zum erwarteten Ergebnis führen.

Im Rechenmodell muss die zusammengehörige Folge aus Lesen, Verändern und Zurückschreiben geschützt werden. Sie bildet hier den kritischen Abschnitt. Würde ein anderer Ablauf dazwischen denselben Wert bearbeiten, könnte er einen veralteten Zwischenwert verwenden.

Eine Sperre regelt in unserem Modell den Zugang: Höchstens einer der beiden Abläufe kann dieselbe Sperre zur selben Zeit besitzen. Der andere wartet vor dem geschützten Abschnitt. Er darf diesen erst beginnen, nachdem die Sperre freigegeben und von ihm erworben wurde.

Beide Abläufe müssen dieselbe Sperre vor dem Lesen erwerben und erst nach dem Zurückschreiben freigeben. Dann liest der zweite Ablauf den bereits aktualisierten gemeinsamen Wert. Unter diesen Voraussetzungen verhindert die Sperre im Rechenmodell verlorene Updates. Sie legt dabei nicht fest, welcher Ablauf zuerst an die Reihe kommt.

Eine Sperre nur um das Zurückschreiben reicht hier nicht: Beide Abläufe könnten vorher denselben alten Wert lesen. Verschiedene Sperren für A und B würden ebenfalls nicht verhindern, dass beide vor dem ersten Zurückschreiben denselben alten Wert lesen.

Ein Test führt ein Programm mit bestimmten Eingaben aus und prüft dabei ein erwartetes Ergebnis. Ein bestandener Test zeigt hier, dass der beobachtete Ablauf den geprüften Endwert geliefert hat. Daraus folgt nicht, dass andere mögliche Schrittfolgen ebenfalls richtig enden.

Auch ohne Sperre können die Schritte zufällig günstig liegen: A kann seine Änderung abschließen, bevor B liest. Ein korrekter Endwert beweist deshalb auch nicht, dass eine wirksame Sperre vorhanden ist. Viele erfolgreiche Wiederholungen schließen eine Race Condition nicht aus, solange andere mögliche Reihenfolgen ungeprüft bleiben.

Zusätzliche Protokollausgaben, also Ausgaben über den Programmablauf, können das zeitliche Verhalten verändern. Dadurch können Fehlersymptome beim Testen verschwinden. Das Verschwinden ist kein Beweis, dass die Ursache behoben wurde.

Tests mit unterschiedlichen möglichen Reihenfolgen können Fehler sichtbar machen. Ein einzelner beobachteter Ablauf beweist aber keine allgemeine Fehlerfreiheit. Für das Sperrmodell muss zusätzlich begründet werden, warum beide Abläufe dieselbe Sperre um die gesamte Folge aus Lesen, Rechnen und Schreiben verwenden.