Was ist eine Rennbedingung?

Question

Beim Schreiben von Multithreading-Anwendungen ist eines der häufigsten Probleme die Race Condition.

Meine Fragen an die Gemeinschaft lauten:

• Was ist die Rennbedingung?
• Wie kann man sie erkennen?
• Wie gehen Sie mit ihnen um?
• Und schließlich: Wie kann man verhindern, dass sie auftreten?

Answer 1

Eine Race Condition tritt auf, wenn zwei oder mehr Threads auf gemeinsame Daten zugreifen können und versuchen, sie gleichzeitig zu ändern. Da der Thread-Planungsalgorithmus jederzeit zwischen den Threads wechseln kann, wissen Sie nicht, in welcher Reihenfolge die Threads versuchen werden, auf die gemeinsamen Daten zuzugreifen. Daher hängt das Ergebnis der Datenänderung vom Thread-Scheduling-Algorithmus ab, d. h. beide Threads "rennen" um den Zugriff auf die Daten bzw. deren Änderung.

Probleme treten häufig auf, wenn ein Thread ein "check-then-act" durchführt (z.B. "check", ob der Wert X ist, dann "act", um etwas zu tun, was davon abhängt, dass der Wert X ist) und ein anderer Thread etwas mit dem Wert zwischen dem "check" und dem "act" macht. Z.B.:

if (x == 5) // The "Check"
{
   y = x * 2; // The "Act"

   // If another thread changed x in between "if (x == 5)" and "y = x * 2" above,
   // y will not be equal to 10.
}

Der Punkt ist, dass y 10 sein könnte, oder irgendetwas, je nachdem, ob ein anderer Thread x zwischen der Prüfung und der Handlung verändert hat. Sie haben keine Möglichkeit, das zu wissen.

Um das Auftreten von Wettlaufsituationen zu verhindern, würden Sie normalerweise eine Sperre um die gemeinsam genutzten Daten legen, um sicherzustellen, dass nur ein Thread gleichzeitig auf die Daten zugreifen kann. Dies würde in etwa so aussehen:

// Obtain lock for x
if (x == 5)
{
   y = x * 2; // Now, nothing can change x until the lock is released. 
              // Therefore y = 10
}
// release lock for x

Answer 2

Eine "Race Condition" liegt vor, wenn Multithreading- (oder anderweitig paralleler) Code, der auf eine gemeinsam genutzte Ressource zugreift, unerwartete Ergebnisse hervorrufen könnte.

Nehmen Sie dieses Beispiel:

for ( int i = 0; i < 10000000; i++ )
{
   x = x + 1; 
}

Wenn Sie 5 Threads hätten, die diesen Code gleichzeitig ausführen, würde der Wert von x NICHT 50.000.000 betragen. Er würde vielmehr bei jedem Durchlauf variieren.

Das liegt daran, dass jeder Thread, um den Wert von x zu erhöhen, Folgendes tun muss: (natürlich vereinfacht)

Retrieve the value of x
Add 1 to this value
Store this value to x

Jeder Thread kann sich jederzeit in einem beliebigen Schritt dieses Prozesses befinden, und sie können sich gegenseitig beeinflussen, wenn eine gemeinsame Ressource betroffen ist. Der Zustand von x kann von einem anderen Thread in der Zeit zwischen dem Lesen und dem Zurückschreiben von x geändert werden.

Angenommen, ein Thread ruft den Wert von x ab, hat ihn aber noch nicht gespeichert. Ein anderer Thread kann auch den dieselbe Wert von x (weil ihn noch kein Thread geändert hat) und dann würden beide den dieselbe Wert (x+1) zurück in x!

Beispiel:

Thread 1: reads x, value is 7
Thread 1: add 1 to x, value is now 8
Thread 2: reads x, **value is 7**
Thread 1: stores 8 in x
Thread 2: adds 1 to x, value is now 8
Thread 2: **stores 8 in x**

Race-Bedingungen können vermieden werden, indem man eine Art von Verriegelung Mechanismus vor dem Code, der auf die gemeinsame Ressource zugreift:

for ( int i = 0; i < 10000000; i++ )
{
   //lock x
   x = x + 1; 
   //unlock x
}

Hier lautet die Antwort jedes Mal 50.000.000.

Weitere Informationen zum Thema Sperren finden Sie unter: mutex, semaphore, critical section, shared resource.

Answer 3

Was ist eine Rennbedingung?

Sie haben vor, um 17 Uhr ins Kino zu gehen. Sie erkundigen sich nach der Verfügbarkeit der Karten für 16 Uhr. Der Mitarbeiter sagt, dass sie verfügbar sind. Sie entspannen sich und erreichen die Kasse 5 Minuten vor Beginn der Vorstellung. Sie können sich sicher denken, was passiert: Es ist ein volles Haus. Das Problem lag hier in der Zeitspanne zwischen dem Check und der Aktion. Sie haben sich um 4 Uhr erkundigt und um 5 Uhr gehandelt, und in der Zwischenzeit hat sich jemand anderes die Karten geschnappt. Das ist eine Wettlaufbedingung - genauer gesagt ein "Prüfen-dann-handeln"-Szenario von Wettlaufbedingungen.

Wie kann man sie erkennen?

Religiöse Codeüberprüfung, Multithreading-Unit-Tests. Es gibt keine Abkürzung. Es gibt ein paar Eclipse-Plugins für dieses Thema, aber noch nichts Stabiles.

Wie geht man damit um und wie verhindert man sie?

Am besten wäre es, nebenwirkungsfreie und zustandslose Funktionen zu erstellen und so viel wie möglich immutables zu verwenden. Aber das ist nicht immer möglich. Die Verwendung von java.util.concurrent.atomic, nebenläufigen Datenstrukturen, angemessener Synchronisierung und akteurbasierter Gleichzeitigkeit wird also helfen.

Die beste Ressource für Gleichzeitigkeit ist JCIP. Sie können auch einige weitere Details zur obigen Erklärung hier .

Answer 4

Es gibt einen wichtigen technischen Unterschied zwischen Race Conditions und Data Races. Die meisten Antworten scheinen davon auszugehen, dass diese Begriffe gleichbedeutend sind, aber das sind sie nicht.

Ein Data Race tritt auf, wenn 2 Befehle auf dieselbe Speicherstelle zugreifen, mindestens einer dieser Zugriffe ein Schreibzugriff ist und es keine geschieht vor der Bestellung unter diesen Zugriffen. Was nun eine "happens before"-Reihenfolge ausmacht, ist Gegenstand vieler Debatten, aber im Allgemeinen führen ulock-lock-Paare auf derselben lock-Variable und wait-signal-Paare auf derselben condition-Variable zu einer "happens-before"-Reihenfolge.

Eine Race Condition ist ein semantischer Fehler. Es handelt sich um einen Fehler, der in der zeitlichen Abfolge von Ereignissen auftritt und zu einer fehlerhaften Programmausführung führt. Verhalten .

Viele Wettlaufbedingungen können durch Datenwettläufe verursacht werden (und werden es auch tatsächlich), aber das ist nicht notwendig. Tatsächlich sind Datenrennen und Race Conditions weder die notwendige noch die hinreichende Bedingung füreinander. Diese In diesem Blogbeitrag wird der Unterschied anhand eines einfachen Beispiels für eine Banktransaktion ebenfalls sehr gut erklärt. Hier ist eine weitere einfache Beispiel Das erklärt den Unterschied.

Nachdem wir nun die Terminologie geklärt haben, wollen wir versuchen, die ursprüngliche Frage zu beantworten.

Da Race Conditions semantische Fehler sind, gibt es keine allgemeine Möglichkeit, sie zu erkennen. Das liegt daran, dass es keine Möglichkeit gibt, ein automatisiertes Orakel zu haben, das zwischen korrektem und inkorrektem Programmverhalten im allgemeinen Fall unterscheiden kann. Race Detection ist ein unentscheidbares Problem.

Andererseits haben Datenwettläufe eine genaue Definition, die sich nicht unbedingt auf die Korrektheit bezieht, so dass man sie erkennen kann. Es gibt viele verschiedene Arten von Data-Race-Detektoren (statische/dynamische Data-Race-Detektion, Lockset-basierte Data-Race-Detektion, happens-before-basierte Data-Race-Detektion, hybride Data-Race-Detektion). Ein hochmoderner dynamischer Data-Race-Detektor ist ThreadSanitizer was in der Praxis sehr gut funktioniert.

Der Umgang mit Datenwettläufen erfordert im Allgemeinen eine gewisse Programmierdisziplin, um zwischen den Zugriffen auf gemeinsam genutzte Daten (entweder während der Entwicklung oder sobald sie mit den oben erwähnten Werkzeugen erkannt wurden) Vorgänge auszulösen. Dies kann durch Sperren, Bedingungsvariablen, Semaphoren usw. geschehen. Man kann jedoch auch andere Programmierparadigmen wie Message Passing (anstelle von Shared Memory) verwenden, die Datenrennen von vornherein vermeiden.

Answer 5

Eine Race Condition ist eine Situation bei der gleichzeitigen Programmierung, in der zwei gleichzeitige Threads oder Prozesse um eine Ressource konkurrieren und der resultierende Endzustand davon abhängt, wer die Ressource zuerst erhält.