Quelltext der Seite Race Condition

Eine '''Race Condition''' (deutsch etwa '''Wettlaufsituation''') entsteht, wenn das Ergebnis eines Programms davon abhängt, in welcher zeitlichen Reihenfolge mehrere nebenläufige Vorgänge ausgeführt werden. Da Threads, Prozesse oder GPU-Queues nicht bei jedem Lauf exakt gleich geplant werden, kann derselbe Code scheinbar korrekt funktionieren und später sporadisch falsche Ergebnisse liefern.

Race Conditions treten besonders häufig auf, wenn mehrere Ausführungseinheiten gemeinsamen Zustand lesen und verändern, ohne den Zugriff ausreichend zu koordinieren.<ref name="MSRace">Microsoft: [https://learn.microsoft.com/en-us/archive/msdn-magazine/2008/june/tools-and-techniques-to-identify-concurrency-issues Tools and Techniques to Identify Concurrency Issues]. Abgerufen am 6. September 2026.</ref>

== Einfaches Beispiel ==

Zwei Threads erhöhen denselben Zähler. Die scheinbar einzelne Operation <code>Zaehler++</code> besteht intern aus mehreren Schritten:

# aktuellen Wert lesen,
# Wert erhöhen,
# neuen Wert zurückschreiben.

Lesen beide Threads gleichzeitig den Wert 10, berechnen beide 11 und schreiben anschließend 11 zurück. Erwartet wurde 12, tatsächlich ging jedoch eine Erhöhung verloren. Welcher Ablauf eintritt, hängt vom Timing ab.

== Race Condition und Data Race ==

Die Begriffe werden oft gleich verwendet, sind aber nicht vollständig identisch:

* Eine '''Race Condition''' ist allgemein ein Fehler, bei dem das Verhalten von einer unerwünschten Reihenfolge nebenläufiger Ereignisse abhängt. Das kann auch Dateien, Netzwerkvorgänge oder GPU-Arbeit betreffen.
* Ein '''Data Race''' beziehungsweise '''Datenrennen''' bezeichnet enger gefasst unkoordinierte, gleichzeitig stattfindende Speicherzugriffe auf dieselben Daten, wobei mindestens ein Zugriff schreibt.

Ein Data Race ist somit eine häufige Form der Race Condition. Nicht jede Race Condition muss jedoch durch denselben Speicherort verursacht werden.

== Typische Ursachen ==

* mehrere Threads verändern dieselbe Variable oder Datenstruktur;
* ein Objekt wird benutzt, bevor seine Initialisierung abgeschlossen ist;
* ein asynchroner Auftrag veröffentlicht ein Ergebnis zu früh;
* eine Ressource wird freigegeben, obwohl ein anderer Auftrag sie noch verwendet;
* zwei GPU-Queues oder Adapter greifen ohne passende Fence-Abhängigkeit auf zusammengehörige Daten zu;
* die Reihenfolge von Prüfung und anschließender Änderung ist nicht atomar, etwa bei „prüfen, ob frei“ und „reservieren“.

== Vermeidung ==

Race Conditions lassen sich unter anderem verhindern durch:

* '''Mutexe, Critical Sections und Locks''', die einen kritischen Abschnitt nur für einen Ausführungspfad gleichzeitig zugänglich machen;
* '''atomare Operationen''' für einfache, unteilbare Änderungen;
* '''Events, Semaphore und Condition Variables''' zur geregelten Reihenfolge von Arbeiten;
* '''Fences und Barriers''' zur Synchronisation von GPU-Queues, Ressourcenübergängen und Speicherzugriffen;
* unveränderliche Daten, getrennte Zuständigkeiten und Message Queues, wodurch gemeinsam beschreibbarer Zustand reduziert wird.

Windows stellt dafür sowohl Synchronisationsobjekte als auch leichtgewichtige Primitive wie Critical Sections und SRW Locks bereit.<ref name="MSSync">Microsoft: [https://learn.microsoft.com/en-us/windows/win32/procthread/synchronizing-execution-of-multiple-threads Synchronizing Execution of Multiple Threads]. Abgerufen am 6. September 2026.</ref> Synchronisation muss jedoch zur tatsächlich geschützten Ressource passen. Ein GPU-Fence ordnet beispielsweise GPU-Arbeit, ersetzt aber nicht automatisch den Schutz gemeinsam veränderter CPU-Daten.

== Erkennung ==

Race Conditions sind oft schwer reproduzierbar, weil Debug-Ausgaben, Breakpoints oder eine andere Auslastung bereits das Timing verändern können. Hinweise sind seltene falsche Werte, beschädigte Daten, flackernde Ausgaben, sporadische Abstürze oder Fehler, die nur auf Mehrkernsystemen auftreten.

Hilfreich sind Stress- und Wiederholungstests, Thread- und GPU-Debugger, Race-Detector-Werkzeuge sowie klar protokollierte Zustandsübergänge. Die eigentliche Lösung besteht nicht darin, das Timing künstlich zu verändern, sondern die erforderliche Reihenfolge ausdrücklich zu synchronisieren. Auch Speicherreihenfolge und Sichtbarkeit zwischen Prozessorkernen müssen berücksichtigt werden.<ref name="MSOrdering">Microsoft: [https://learn.microsoft.com/en-us/windows/win32/sync/synchronization-and-multiprocessor-issues Synchronization and Multiprocessor Issues]. Abgerufen am 6. September 2026.</ref>

== Abgrenzung zum Deadlock ==

Bei einer Race Condition laufen mehrere Vorgänge weiter, aber ihre unkontrollierte Reihenfolge erzeugt möglicherweise ein falsches Ergebnis. Bei einem '''Deadlock''' warten Vorgänge dagegen dauerhaft aufeinander und kommen nicht mehr voran. Übermäßig oder inkonsistent eingesetzte Locks können Race Conditions beseitigen, zugleich aber neue Deadlocks verursachen.

== Siehe auch ==

* [[UE5 Heterogeneous Multi-GPU]]
* [[Rendering Hardware Interface (RHI) in Unreal Engine 5]]
* [[Render Dependency Graph in Unreal Engine 5]]

== Einzelnachweise ==

<references />

[[Kategorie:Programmierung]]
[[Kategorie:Parallelverarbeitung]]
[[Kategorie:Unreal Engine 5]]