Por que o código que altera uma variável compartilhada entre threads aparentemente NÃO sofre de uma condição de corrida?

Estou usando Cygwin GCC e executo este código:

#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;
}

Compilado com a linha: g++ -Wall -fexceptions -g -std=c++14 -c main.cpp -o main.o.

Ele imprime 1000, o que é correto. No entanto, eu esperava um número menor devido a threads substituindo um valor incrementado anteriormente. Por que este código não sofre de acesso mútuo?

Minha máquina de teste tem 4 núcleos e não coloquei restrições no programa que conheço.

O problema persiste ao substituir o conteúdo do compartilhado foopor algo mais complexo, por exemplo

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

foo()é tão curto que cada thread provavelmente termina antes mesmo de o próximo ser gerado. Se você adicionar um sleep por um tempo aleatório foo()antes de u++, poderá começar a ver o que espera.

É importante entender que uma condição de corrida não garante que o código será executado incorretamente, apenas que ele pode fazer qualquer coisa, pois é um comportamento indefinido. Incluindo a execução conforme o esperado.

Particularmente em máquinas X86 e AMD64, as condições de corrida em alguns casos raramente causam problemas, já que muitas das instruções são atômicas e as garantias de coerência são muito altas. Essas garantias são um tanto reduzidas em sistemas multiprocessadores onde o prefixo de bloqueio é necessário para que muitas instruções sejam atômicas.

Se em sua máquina o incremento for uma operação atômica, provavelmente será executado corretamente, embora de acordo com o padrão da linguagem seja um comportamento indefinido.

Especificamente, espero que neste caso o código possa estar sendo compilado para uma instrução atômica Fetch and Add (ADD ou XADD no assembly X86) que é de fato atômica em sistemas de processador único, no entanto, em sistemas de multiprocessador não é garantido que seja atômico e um bloqueio seria necessário para torná-lo assim. Se você estiver executando em um sistema multiprocessador, haverá uma janela onde os threads podem interferir e produzir resultados incorretos.

Especificamente, eu compilei seu código para montagem usando https://godbolt.org/ e foo()compilar para:

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

Isso significa que ele está apenas executando uma instrução add que, para um único processador, será atômica (embora, como mencionado acima, não seja para um sistema com vários processadores).

Acho que não é tanto a coisa se você colocar um sono antes ou depois do u++. Em vez disso, a operação se u++traduz em código que é - em comparação com a sobrecarga de threads de geração que chamam foo- executado muito rapidamente de modo que é improvável que seja interceptado. No entanto, se você "prolongar" a operação u++, a condição de corrida se tornará muito mais provável:

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

resultado: 694

BTW: eu também tentei

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

e isso me deu na maioria das vezes 1997, mas às vezes 1995.

Ele sofre de uma condição de corrida. Coloque usleep(1000);antes u++;em fooe eu ver uma saída diferente (<1000) a cada vez.

1. A provável resposta de por que a condição de corrida não se manifestou para você, embora não existir, é que foo()é tão rápido, em comparação com o tempo que leva para iniciar uma discussão, que cada segmento termina antes do próximo pode até mesmo começar. Mas...

2. Mesmo com sua versão original, o resultado varia de acordo com o sistema: tentei do seu jeito em um Macbook (quad-core) e, em dez execuções, consegui 1000 três vezes, 999 seis vezes e 998 uma vez. Portanto, a corrida é um tanto rara, mas claramente presente.

3. Você compilou com '-g' , que tem uma maneira de fazer os bugs desaparecerem. Recompilei seu código, ainda inalterado, mas sem o '-g', e a corrida ficou muito mais acentuada: consegui 1000 uma vez, 999 três vezes, 998 duas vezes, 997 duas vezes, 996 uma vez e 992 uma vez.

4. Ré. a sugestão de adicionar um sono - isso ajuda, mas (a) um tempo fixo de sono deixa os fios ainda distorcidos pelo tempo de início (sujeito à resolução do temporizador), e (b) um sono aleatório os espalha quando o que queremos é aproxime-os. Em vez disso, eu os codificaria para aguardar um sinal de início, para que pudesse criá-los todos antes de deixá-los trabalhar. Com esta versão (com ou sem '-g'), obtenho resultados em todos os lugares, tão baixos quanto 974 e não superiores 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;
   }