Kritischer Abschnitt: Race Conditions verstehen

Stell dir vor, mehrere Threads verändern denselben Zähler. Jeder Thread arbeitet für sich korrekt. Trotzdem kann ein falsches Gesamtergebnis entstehen, wenn ihre Anweisungen ungünstig ineinandergreifen.

Entscheidend sind drei Fragen:

1. Greifen mehrere Threads oder Prozesse auf dieselbe Ressource zu?
2. Verändert mindestens einer von ihnen den gemeinsamen Zustand?
3. Kann eine Operation in mehrere sichtbare Einzelschritte zerfallen?

Wenn alle drei Punkte zutreffen, kann ein kritischer Abschnitt vorliegen.

Ein kritischer Abschnitt muss auch nicht ohne jede Unterbrechung ablaufen. Der Scheduler darf einen Thread pausieren. Währenddessen darf jedoch kein anderer Thread einen korrespondierenden kritischen Abschnitt für dieselbe Ressource betreten.

Eine Race Condition oder Wettlaufbedingung liegt vor, wenn das Ergebnis von der zeitlichen Reihenfolge nebenläufiger Ereignisse abhängt.

Der gemeinsame Zähler beginnt bei 0. Zwei Threads X und Y sollen ihn jeweils einmal erhöhen. Eine Erhöhung besteht aus drei Schritten:

1. gemeinsamen Wert lokal einlesen;
2. lokalen Wert um 1 erhöhen;
3. lokalen Wert zurückschreiben.

Der kritische Abschnitt umfasst hier die gesamte Folge aus Lesen, Erhöhen und Zurückschreiben. Würde man nur den letzten Schreibzugriff schützen, könnten weiterhin beide Threads denselben alten Wert lesen.

Nicht die Schreibweise oder Position des Codes entscheidet über den gemeinsamen Schutz, sondern die betroffene Ressource.

Angenommen, ein Abschnitt erhöht zaehler, während ein anderer ihn verringert. Obwohl die Abschnitte verschiedene Aufgaben haben, verändern beide dieselbe Variable. Sie sind deshalb korrespondierende kritische Abschnitte und benötigen denselben wechselseitigen Ausschluss.

Beispiel mit Java

In Java kann eine synchronisierte Instanzmethode so aussehen: public synchronized void increment() { count++; }

Bei Aufrufen derselben Counter-Instanz führt jeweils nur ein Thread diese synchronisierte Methode aus. Zwei verschiedene Instanzen besitzen dagegen getrennte Monitore und schützen sich nicht gegenseitig.

Eine Sperre verhindert nicht automatisch jedes Problem. Eine Lösung für kritische Abschnitte soll vier Anforderungen erfüllen:

• Wechselseitiger Ausschluss: Höchstens ein Thread befindet sich bezüglich einer Ressource im kritischen Abschnitt.
• Fortschritt: Ein beendeter oder außerhalb seines kritischen Abschnitts stehender Thread darf die übrigen Threads nicht am Fortschritt hindern.
• Begrenzte Wartezeit: Kein wartender Thread darf beliebig lange ausgeschlossen bleiben.
• Geschwindigkeitsunabhängigkeit: Die Lösung darf keine bestimmte relative Ausführungsgeschwindigkeit der Threads voraussetzen.

Als Synchronisationsmittel kommen unter anderem synchronized, Locks, Monitore und Semaphore infrage. Sie ordnen den Zutritt zum kritischen Abschnitt. Welche Lösung passt, hängt vom betroffenen gemeinsamen Zustand und vom benötigten Ausschluss ab.

Warum sollte der geschützte Bereich klein bleiben?

Während ein Thread die passende Sperre hält, müssen andere interessierte Threads warten. Ein unnötig großer kritischer Abschnitt kann deshalb die Leistung verschlechtern. Falsch aufeinander abgestimmte Sperren können außerdem zu einem Deadlock führen, bei dem Threads dauerhaft aufeinander warten.

Klein bedeutet aber nicht unvollständig: Beim Zähler müssen Lesen, Ändern und Schreiben gemeinsam geschützt bleiben. Sonst besteht die Race Condition weiterhin.

Wenn du einen kritischen Abschnitt beurteilst, gehe in dieser Reihenfolge vor: gemeinsame Ressource bestimmen, mehrteilige Zugriffe markieren, mögliche Verschränkung prüfen und anschließend einen gemeinsamen, vollständig abgegrenzten Schutz wählen.