Race-Condition-Detektor

Das Problem

Race Conditions sind die heimtueckischsten Fehler in Software — sie funktionieren 99% der Zeit und versagen unvorhersehbar unter Last. Sie koennen mit einem Debugger nicht zuverlaessig reproduziert werden, da das Debugging selbst das Timing veraendert. Zwei Threads schreiben in dieselbe Variable, zwei API-Aufrufe aktualisieren denselben Datensatz — das Ergebnis haengt davon ab, wer das Rennen gewinnt.

Der Prompt

Du bist ein Nebenlaeufigkeits-Debugging-Spezialist. Analysiere diesen Code auf Race Conditions, Deadlocks und Timing-Risiken:

CODE:
[nebenlaeufigen/asynchronen Code einfuegen — alle Zugriffspunkte auf geteilten Zustand einbeziehen]

RUNTIME: [z.B. Node.js Event Loop, Java Threads, Python asyncio, Browser-JS, Go Goroutines]
SYMPTOM: [z.B. "sporadisch falsche Summen", "gelegentlicher Deadlock", "doppelte Datensaetze"]
HAEUFIGKEIT: [z.B. "1 von 100 Requests", "nur unter Last", "zufaellig"]

Fuehre eine Nebenlaeufigkeits-Gefahrenanalyse durch:
1. **Inventar geteilter Zustaende**: Liste jedes Stueck geteilten veraenderbaren Zustands und wer es liest/schreibt.
2. **Karte kritischer Abschnitte**: Identifiziere alle Codebereiche, in denen ohne korrekte Synchronisierung auf geteilten Zustand zugegriffen wird.
3. **Race-Szenario-Konstruktion**: Konstruiere fuer jeden kritischen Abschnitt die exakte Verschraenkung der Operationen, die den Fehler produziert.
4. **Deadlock-Graph**: Falls mehrere Locks/Ressourcen existieren, zeichne den Abhaengigkeitsgraphen und identifiziere Zyklen.
5. **Timing-Fenster**: Wie gross ist das Race-Fenster? Nanosekunden, Millisekunden oder Sekunden?
6. **Fix mit Beweis**: Liefere den Fix und beweise, dass er die Race eliminiert, indem dieselbe Verschraenkung nun korrekte Ergebnisse liefert.
7. **Stresstest**: Generiere einen Test, der das Race-Fenster vergroessert, um den Fehler zuverlaessig reproduzierbar zu machen.

Beispiel-Ausgabe

Geteilter Zustand: `orderTotal` (gleichzeitig von addItem und applyDiscount geschrieben)
Kritischer Abschnitt: Zeilen 23-25 — Total lesen, neues Total berechnen, Total schreiben (nicht atomar)
Race-Szenario: Thread A liest Total=100 → Thread B liest Total=100 → A schreibt 120 → B schreibt 90 (ueberschreibt A)
Timing-Fenster: ~2ms (Datenbank-Roundtrip zwischen Lesen und Schreiben)
Fix: In Transaktion mit SELECT FOR UPDATE einwickeln oder atomares Inkrement verwenden

Wann verwenden

Diesen Skill einsetzen bei sporadischen Fehlern, die beim Debuggen oder Hinzufuegen von Logging verschwinden, bei gelegentlich inkonsistenten Daten unter gleichzeitigem Zugriff, oder wenn die Anwendung unter bestimmten Lastmustern blockiert. Kritisch fuer jedes Multi-Thread-, Async- oder verteilte System.

Profi-Tipps

• Ein Sleep macht es reproduzierbar — await sleep(100) zwischen Lesen und Schreiben des geteilten Zustands einfuegen, um das Race-Fenster zum Testen kuenstlich zu vergroessern.
• Logging kann Races VERBERGEN — I/O-Operationen wie console.log fuehren Synchronisationspunkte ein, die das Timing aendern. Wenn Logs den Fehler verschwinden lassen, liegt definitiv eine Race Condition vor.
• Datenbank-Isolationslevel pruefen — die meisten Race Conditions in Web-Apps sind Datenbank-Races. READ COMMITTED erlaubt Phantom-Reads; SERIALIZABLE oder explizite Locks fuer kritische Abschnitte verwenden.
• Das TOCTOU-Muster — Time-Of-Check-To-Time-Of-Use ist die haeufigste Race: Bedingung pruefen und darauf reagieren sind nicht atomar.