Perché il codice che muta una variabile condivisa tra i thread apparentemente NON soffre di una condizione di competizione?

Sto usando Cygwin GCC ed eseguo questo codice:

#include <iostream>
#include <thread>
#include <vector>
using namespace std;

unsigned u = 0;

void foo()
{
    u++;
}

int main()
{
    vector<thread> threads;
    for(int i = 0; i < 1000; i++) {
        threads.push_back (thread (foo));
    }
    for (auto& t : threads) t.join();

    cout << u << endl;
    return 0;
}

Compilato con la linea: g++ -Wall -fexceptions -g -std=c++14 -c main.cpp -o main.o.

Stampa 1000, che è corretto. Tuttavia, mi aspettavo un numero inferiore a causa dei thread che sovrascrivono un valore precedentemente incrementato. Perché questo codice non soffre di accesso reciproco?

La mia macchina di prova ha 4 core e non metto restrizioni al programma che conosco.

Il problema persiste quando si sostituisce il contenuto del condiviso foocon qualcosa di più complesso, es

if (u % 3 == 0) {
    u += 4;
} else {
    u -= 1;
}

foo()è così breve che probabilmente ogni thread finisce prima che venga generato il successivo. Se aggiungi un sonno per un tempo casuale foo()prima del u++, potresti iniziare a vedere cosa ti aspetti.

È importante capire che una condizione di competizione non garantisce che il codice verrà eseguito in modo errato, ma semplicemente che potrebbe fare qualsiasi cosa, poiché è un comportamento indefinito. Compreso l'esecuzione come previsto.

Soprattutto su macchine X86 e AMD64 le condizioni di gara in alcuni casi raramente causano problemi poiché molte delle istruzioni sono atomiche e le garanzie di coerenza sono molto alte. Queste garanzie sono in qualche modo ridotte sui sistemi multiprocessore in cui il prefisso di blocco è necessario affinché molte istruzioni siano atomiche.

Se sulla tua macchina l'incremento è un'operazione atomica, probabilmente funzionerà correttamente anche se secondo lo standard del linguaggio è un comportamento indefinito.

In particolare, mi aspetto che in questo caso il codice possa essere compilato in un Fetch and Add atomico (ADD o XADD nell'assembly X86) che è effettivamente atomica nei sistemi a processore singolo, tuttavia su sistemi multiprocessore non è garantito che sia atomica e un blocco sarebbe necessario per farlo. Se si esegue su un sistema multiprocessore, ci sarà una finestra in cui i thread potrebbero interferire e produrre risultati errati.

Nello specifico ho compilato il tuo codice per l'assemblaggio usando https://godbolt.org/ e foo()compila per:

foo():
        add     DWORD PTR u[rip], 1
        ret

Ciò significa che sta eseguendo solo un'istruzione di aggiunta che per un singolo processore sarà atomica (sebbene come menzionato sopra non sia così per un sistema multi processore).

Penso che non sia tanto la cosa se metti un sonno prima o dopo il u++. È piuttosto che l'operazione si u++traduce in codice che, rispetto al sovraccarico di spawn dei thread che chiamano foo, viene eseguito molto rapidamente in modo tale che è improbabile che venga intercettato. Tuttavia, se "prolunghi" l'operazione u++, la race condition diventerà molto più probabile:

void foo()
{
    unsigned i = u;
    for (int s=0;s<10000;s++);
    u = i+1;
}

risultato: 694

BTW: ho anche provato

if (u % 2) {
    u += 2;
} else {
    u -= 1;
}

e mi ha dato la maggior parte delle volte 1997, ma a volte 1995.

Soffre di una condizione di gara. Metti usleep(1000);prima u++;in fooe vedo output diverso (<1000) di volta in volta.

1. La risposta probabilmente il motivo per cui la condizione di competizione non ha manifestato per voi, anche se non esiste, è che foo()è così veloce, rispetto al tempo necessario per avviare un thread, che ogni thread termina prima del prossimo può anche iniziare. Ma...

2. Anche con la versione originale, il risultato varia a seconda del sistema: l'ho provato a modo tuo su un Macbook (quad-core) e in dieci esecuzioni ho ottenuto 1000 tre volte, 999 sei volte e 998 una volta. Quindi la gara è piuttosto rara, ma chiaramente presente.

3. Hai compilato con '-g', che ha un modo per far sparire i bug. Ho ricompilato il tuo codice, ancora invariato ma senza il '-g', e la corsa è diventata molto più pronunciata: ho ottenuto 1000 una volta, 999 tre volte, 998 due volte, 997 due volte, 996 una volta e 992 una volta.

4. Ri. il suggerimento di aggiungere un sonno - che aiuta, ma (a) un tempo di sonno fisso lascia i thread ancora distorti dall'ora di inizio (soggetto alla risoluzione del timer) e (b) un sonno casuale li distribuisce quando ciò che vogliamo è avvicinarli insieme. Invece, li codificherei per attendere un segnale di avvio, così posso crearli tutti prima di lasciarli lavorare. Con questa versione (con o senza '-g'), ottengo risultati ovunque, a partire da 974 e non superiori a 998:

   #include <iostream>
   #include <thread>
   #include <vector>
   using namespace std;
   
   unsigned u = 0;
   bool start = false;
   
   void foo()
   {
       while (!start) {
           std::this_thread::yield();
       }
       u++;
   }
   
   int main()
   {
       vector<thread> threads;
       for(int i = 0; i < 1000; i++) {
           threads.push_back (thread (foo));
       }
       start = true;
       for (auto& t : threads) t.join();
   
       cout << u << endl;
       return 0;
   }