Race Conditions

Race Condition: das Ergebnis hängt von der zeitlichen Verschränkung nebenläufiger Zugriffe ab. Beispiel: zwei Threads inkrementieren denselben Zähler ohne Sync und verlieren Updates.

Gegenmittel: atomare Operationen, Locks, unveränderliche Daten.

$$\texttt{count++}=\mathrm{load};\,\mathrm{add};\,\mathrm{store}$$

Wo gebraucht

Jeder gemeinsame Zähler, Cache oder Collection ohne Happens-Before ist ein Produktionsbug unter Last. Flaky Tests sind oft Races.

Vertiefung

Eine Race Condition liegt vor, wenn das Ergebnis von der zeitlichen Überlagerung konkurrierender Zugriffe abhängt. Schon count++ besteht aus Lesen, Berechnen und Schreiben. Zwei Threads können denselben alten Wert lesen und eine Erhöhung verlieren.

Korrektheit verlangt, zusammengehörige Operationen atomar oder unter einer passenden Synchronisationsregel auszuführen. Entscheidend ist nicht nur gegenseitiger Ausschluss, sondern auch Sichtbarkeit: Änderungen eines Threads müssen nach der Synchronisation für andere beobachtbar sein.

Schwierigkeitsstufen

1. Eine verlorene Aktualisierung in Einzelschritte zerlegen.
2. Kritische Abschnitte anhand gemeinsamer Invarianten bestimmen.
3. Ausschluss und Speichersichtbarkeit gemeinsam begründen.

Fallstricke

Seltene Reproduktion ist kein Beleg für Sicherheit. Logging oder Debugging kann das Timing verändern und den Fehler verdecken. Auch mehrere einzeln threadsichere Methoden bilden zusammen nicht automatisch eine atomare Gesamtoperation.