Dlaczego kod mutujący zmienną współdzieloną w wątkach najwyraźniej NIE cierpi z powodu wyścigu?

Używam Cygwin GCC i uruchamiam ten kod:

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

Zestawione z linii: g++ -Wall -fexceptions -g -std=c++14 -c main.cpp -o main.o.

Drukuje 1000, co jest poprawne. Spodziewałem się jednak mniejszej liczby z powodu wątków nadpisujących poprzednio zwiększoną wartość. Dlaczego ten kod nie podlega wzajemnemu dostępowi?

Moja maszyna testowa ma 4 rdzenie i nie stawiam żadnych ograniczeń programowi, który znam.

Problem utrzymuje się przy zamianie treści udostępnionej na foocoś bardziej złożonego np

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

foo()jest tak krótka, że ​​każdy wątek prawdopodobnie kończy się, zanim następny w ogóle się pojawi. Jeśli dodasz sen na losowy czas foo()przed u++, możesz zacząć widzieć, czego się spodziewasz.

Ważne jest, aby zrozumieć, że sytuacja wyścigu nie gwarantuje, że kod będzie działał niepoprawnie, a jedynie, że może zrobić cokolwiek, ponieważ jest to niezdefiniowane zachowanie. W tym bieganie zgodnie z oczekiwaniami.

Szczególnie na maszynach X86 i AMD64 warunki wyścigu w niektórych przypadkach rzadko powodują problemy, ponieważ wiele instrukcji jest atomowych, a gwarancje spójności są bardzo wysokie. Gwarancje te są nieco ograniczone w systemach wieloprocesorowych, w których przedrostek blokady jest wymagany, aby wiele instrukcji było atomowych.

Jeśli inkrementacja na twoim komputerze jest atomową operacją, prawdopodobnie będzie działać poprawnie, mimo że zgodnie ze standardem językowym jest to niezdefiniowane zachowanie.

W szczególności spodziewam się, że w tym przypadku kod może być kompilowany do atomowej instrukcji Pobierz i dodaj (ADD lub XADD w zestawie X86), która jest rzeczywiście atomowa w systemach jednoprocesorowych, jednak w systemach wieloprocesorowych nie ma gwarancji, że będzie to atomowa i blokada byłby do tego zobowiązany. Jeśli korzystasz z systemu wieloprocesorowego, pojawi się okno, w którym wątki mogą zakłócać działanie i generować nieprawidłowe wyniki.

W szczególności skompilowałem twój kod do asemblera przy użyciu https://godbolt.org/ i foo()kompiluję do:

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

Oznacza to, że wykonuje wyłącznie instrukcję dodawania, która dla pojedynczego procesora będzie atomowa (chociaż, jak wspomniano powyżej, nie dotyczy to systemu wieloprocesorowego).

Myślę, że nie chodzi o to, że kładziesz się spać przed lub po u++. Chodzi raczej o to, że operacja u++przekłada się na kod, który jest - w porównaniu z narzutem związanym z tworzeniem się wątków, które wywołują foo- bardzo szybko wykonywany w taki sposób, że jest mało prawdopodobne, aby został przechwycony. Jeśli jednak „przedłużysz” operację u++, stan wyścigu stanie się znacznie bardziej prawdopodobny:

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

wynik: 694

BTW: też próbowałem

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

i dawało mi to większość razy 1997, ale czasami 1995.

Cierpi na stan wyścigu. Umieścić usleep(1000);zanim u++;się fooi widzę inny wyjściowy (<1000) za każdym razem.

1. Przewidywany odpowiedź dlaczego wyścigu nie manifest dla ciebie, choć nie istnieje, jest to, że foo()jest tak szybki, w porównaniu do czasu potrzebnego do rozpoczęcia wątku, że każdy kończy gwint przed następnym mogę nawet zacząć. Ale...

2. Nawet w przypadku oryginalnej wersji wynik różni się w zależności od systemu: wypróbowałem ją na (czterordzeniowym) Macbooku i po dziesięciu uruchomieniach uzyskałem 1000 trzy razy, 999 sześć razy i 998 raz. Tak więc rasa jest dość rzadka, ale wyraźnie obecna.

3. Skompilowałeś z '-g', który ma sposób na znikanie błędów. Ponownie skompilowałem Twój kod, wciąż niezmieniony, ale bez znaku '-g', i wyścig stał się znacznie wyraźniejszy: dostałem 1000 raz, 999 trzy razy, 998 dwa razy, 997 dwa razy, 996 raz i 992 raz.

4. Re. sugestia dodania uśpienia - to pomaga, ale (a) ustalony czas uśpienia sprawia, że ​​wątki są nadal wypaczone przez czas rozpoczęcia (zależnie od rozdzielczości timera), oraz (b) losowy sen rozciąga je, gdy chcemy przyciągnij je bliżej siebie. Zamiast tego zakodowałbym je, aby czekały na sygnał startu, więc mogę je wszystkie utworzyć, zanim pozwolę im zabrać się do pracy. W tej wersji (z lub bez '-g') otrzymuję wyniki we wszystkich miejscach, tak niskie, jak 974, ale nie wyższe niż 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;
   }