Race Condition (Zustand des Rennens)

1. Einführung

In Multithread-Anwendungen ist das Vorhandensein eines race condition eher eine Frage des „wann“ als des „ob“. Selbst wenn du denkst, dein Code ist zuverlässig und du hast nur „zwei kleine Threads“, wo „alles offensichtlich und simpel“ ist, kann sich ein Race Condition an der harmlosesten Stelle der Logik verstecken.

Was genau ist eigentlich ein race condition und warum ist es so schlimm? Stell dir vor, zwei Personen versuchen gleichzeitig dasselbe Blatt Papier zu bearbeiten — einer schreibt, der andere radiert. Manchmal ist alles ok, manchmal entsteht ein unleserliches Chaos. In der Programmierung sind die Folgen noch interessanter: Fehler treten nicht immer auf, sondern nur unter bestimmten, quasi zufälligen Bedingungen.

Race condition (Zustand des Rennens) — eine Situation, bei der das Ergebnis der Programmausführung davon abhängt, welcher Thread zuerst auf eine Ressource zugreift oder eine Aktion ausführt. Dieses Problem tritt nur bei konkurrierendem (multithreaded) Zugriff auf, wenn zwei oder mehr Threads auf gemeinsame Daten oder Ressourcen zugreifen.

Was passiert bei einer Race?

Hier ein einfaches Schema. Stell dir vor, wir haben zwei Threads und eine gemeinsame Ressource (z.B. die Variable X):

     +---------+           +---------+          
     | Thread 1|           | Thread 2|          
     +----+----+           +----+----+          
          |                     |              
          |     Lesen X         |              
          | <-------------------|              
          |                     |              
          |     Erhöhen X       |              
          |-------------------> |              
          |                     |              
          |     Schreiben X     |              
          | <-------------------|              

Wenn beide Threads gleichzeitig den Wert der Variable X lesen, erhöhen und zurückschreiben, wird der eine die Änderung des anderen „überschreiben“ und die Gesamtanzahl der Erhöhungen stimmt nicht mit der Erwartung überein.

2. Klassisches Beispiel für Race Condition

Lass uns ein Beispiel ansehen. Angenommen, wir wollen die Anzahl der Button-Klicks aus verschiedenen Threads zählen oder die Anzahl verarbeiteter Tasks.

Wir nehmen eine einfache Variable und mehrere Threads, die sie erhöhen:

using System;
using System.Threading;

class Program
{
    static int counter = 0; // Gemeinsame Ressource

    static void Main()
    {
        Thread t1 = new Thread(IncrementCounter);
        Thread t2 = new Thread(IncrementCounter);

        t1.Start();
        t2.Start();

        t1.Join();
        t2.Join();

        Console.WriteLine("Erwarteter Wert: 200000");
        Console.WriteLine("Tatsächlicher Wert: " + counter);
    }

    static void IncrementCounter()
    {
        for (int i = 0; i < 100_000; i++)
        {
            counter++; // << Hier kann das Problem entstehen!
        }
    }
}

Was erwarten wir?

Da jeder Thread counter 100000 Mal erhöht, erwarten wir, dass der Endwert 200000 ist.

Was bekommen wir tatsächlich?

Manchmal — ja, 200000. Aber öfter ist der Wert kleiner — manchmal deutlich kleiner. Wiederhole das Experiment, das Ergebnis schwankt!

Warum ist das so?

Die Operation counter++ ist nicht atomar. Sie läuft eigentlich so ab (vereinfacht):

1. Lese den aktuellen Wert von counter (z.B. 0)
2. Erhöhe um 1 (wird 1)
3. Schreibe zurück (counter = 1)

Wenn zwei Threads gleichzeitig den alten Wert lesen, können beide denselben neuen Wert zurückschreiben, und effektiv wurde nur ein Inkrement ausgeführt.

Visualisierung am Beispiel von zwei Threads:

Angenommen, counter = 0.

• Thread 1: liest 0
• Thread 2: liest 0
• Thread 1: rechnet 0 + 1 = 1
• Thread 2: rechnet 0 + 1 = 1
• Thread 1: schreibt 1
• Thread 2: schreibt 1 (überschreibt das Inkrement von Thread 1)

"Glückwunsch", du hast gerade eine Erhöhung verloren! Bei Tausenden oder Millionen von Operationen schwankt das Ergebnis stark.

3. Noch mehr Beispiele: nicht nur Inkrement!

Trubel in der Küche

Um es anschaulicher zu machen: stell dir ein kleines Café vor. Zwei Köche braten Omeletts in derselben Pfanne, aber koordinieren sich nicht:

• Der erste legt ein Omelett hinein, der zweite legt sofort seins darüber — sie vermischen sich gegenseitig;
• Der eine glaubt, „ich habe schon zwei Omeletts gelegt“, der andere denkt dasselbe, in Wirklichkeit sind drei in der Pfanne, aber sie dachten, es wären vier;
• Chaos beginnt...

In der Programmierung führt ein race condition genau so zu „Chaos“: das Ergebnis hängt von einer Kette schneller, unkontrollierter Operationen ab.

Wenn Threads sich gegenseitig stören: gleichzeitiger Datenzugriff

Angenommen, du implementierst eine Banking-Anwendung und ein Kunde bucht gleichzeitig Geld auf und ab von demselben Konto mit zwei Threads (z.B. einer für Online-Transfer, der andere für die Kasse):

account.Balance += 500;    // Thread 1: Einzahlung
account.Balance -= 300;    // Thread 2: Abhebung

Wenn diese Operationen nicht geschützt sind, kann der Endsaldo falsch sein: Teile der Operationen gehen „verloren“, wenn die Threads gleichzeitig arbeiten.

4. Nützliche Nuancen

Warum ist race condition ein Problem?

Schwer zu fangen und zu reproduzieren. Der Fehler kann nur auf einer ausgelasteten Maschine oder unter seltenen Bedingungen auftreten.

Schwer zu debuggen. Beim Debugging verhalten sich Threads oft anders, und der Fehler verschwindet.

Verletzung der Datenintegrität. Du erhältst falsche, beschädigte Daten, manchmal völlig unbemerkt.

Sicherheit. In kritischen Anwendungen können race conditions zu Datenlecks, Datenzerstörung und sogar zu Sicherheitslücken führen.

Diagramm der "Timing-Rennen"

+-----------------------+     +-----------------------+
| Thread 1              |     | Thread 2              |
+-----------------------+     +-----------------------+
| 1. Lese counter       |     |                       |
| 2. Erhöhe counter     |     |                       |
| (aber nicht schreiben)|     |                       |
|                       |     | 1. Lese counter       |
|                       |     | 2. Erhöhe counter     |
|                       |     | 3. Schreibe counter   |
|                       |     | (counter = 1)         |
| 3. Schreibe counter   |     |                       |
| (counter = 1)         |     |                       |
+-----------------------+     +-----------------------+

Beide Threads haben inkrementiert, aber am Ende wurde nur ein Inkrement geschrieben!

Wo Race Conditions häufig vorkommen

• Beliebige globale oder statische Variablen, auf die mehrere Threads zugreifen.
• Listen, Queues, Collections, die von verschiedenen Threads befüllt werden.
• Events und Delegates, wenn Subscribe/Unsubscribe gleichzeitig passieren (z.B. UI + Hintergrundtasks).
• Caching, Dictionaries, Connection-Handling.
• Jegliche Interaktion mit Dateien, Logs, Datenbanken ohne Transaktionen oder Locks.

Wie man Race Conditions vermeidet: kurze Einführung

• Synchronisation! (mehr dazu in den nächsten Vorlesungen).
• Verwende spezielle Sprachkonstrukte und Bibliotheken: lock, Monitor, Mutexes, Semaphoren usw.
• Für einfache Operationen — atomare Methoden (Interlocked.Increment und andere).
• Verwende threadsichere Collections (ConcurrentBag, ConcurrentDictionary).
• Denk immer: „Was passiert, wenn meine zwei Funktionen gleichzeitig aufgerufen werden?“

5. Nützliche Tipps

Tipps zur Suche und Diagnose von Rennen

• Traue selbst den einfachsten Operationen nicht (Inkrement ++, Zuweisung), wenn du mehrere Threads verwendest.
• Vermeide nach Möglichkeit gemeinsamen Zugriff auf Variablen.
• Wenn du „schwankende“ Bugs siehst, Fehler, die schwer zu reproduzieren sind — denk an Rennen!
• Nutze Tools zur Thread-Analyse (dotTrace, Concurrency Visualizer, Thread Sanitizer).
• Führe Lasttests durch — je mehr Threads und Operationen, desto höher die Chance, den Fehler zu finden.

Was man ohne Synchronisation kann und was nicht

Interlocked.Increment

— „Manchmal“ heißt: Wenn nur ein Thread schreibt und alle anderen nur lesen, dann ist es sicher; wenn mehrere Threads schreiben können — immer Race.

6. Typische Fehler und Fallen

Im oben gezeigten Demo-Code sahen wir counter++ als Problem. Eine weitere Falle: Erhöhen oder Prüfen eines Werts in einer Bedingung.

Beispiel: Lustiger Fehler beim „ersten Start“

if (!alreadyStarted)
{
    alreadyStarted = true;
    // Wir machen die Initialisierung...
}

Wenn mehrere Threads diese Bedingung gleichzeitig ausführen, kann jeder von ihnen alreadyStarted == false sehen und hereingehen! Ergebnis — die Initialisierung wird mehrfach ausgeführt, was zu Fehlern führen kann.

1

Umfrage/Quiz

Einführung in Multithreading, Level 55, Lektion 4

Nicht verfügbar

Einführung in Multithreading

Grundlagen von Multithreading in C#

Öffnen