Чому код, що мутує спільну змінну в потоках, очевидно НЕ страждає від стану перегонів?

Я використовую Cygwin GCC і запускаю цей код:

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

Зібраний з лінії: g++ -Wall -fexceptions -g -std=c++14 -c main.cpp -o main.o.

Він друкує 1000, що правильно. Однак я очікував меншої кількості через тему, що перезаписала раніше збільшене значення. Чому цей код не страждає від взаємного доступу?

Мій тестовий апарат має 4 ядра, і я не ставлю обмежень на програму, про яку я знаю.

Проблема зберігається під час заміни вмісту спільного доступу fooчимось складнішим, наприклад

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

foo()настільки короткий, що кожна нитка, ймовірно, закінчується ще до того, як наступна породжується навіть. Якщо додати сон в протягом випадкового часу в foo()перед u++, ви можете почати бачити , що ви очікуєте.

Важливо зрозуміти, що стан гонки не гарантує, що код буде працювати неправильно, лише те, що він може зробити що завгодно, оскільки це не визначена поведінка. Включаючи біг, як очікувалося.

Зокрема, на гоночних умовах X86 та AMD64 в деяких випадках рідко виникають проблеми, оскільки багато інструкцій є атомними, а гарантії на когерентність дуже високі. Ці гарантії дещо знижуються на багатопроцесорних системах, де префікс блокування необхідний, щоб багато інструкцій були атомними.

Якщо на вашій машині приріст є атомним, це, швидше за все, буде працювати правильно, навіть якщо згідно з мовним стандартом це Невизначена поведінка.

Зокрема, я очікую, що в цьому випадку код може бути складений до атомної інструкції Fetch and Add (ADD або XADD у складі X86), яка справді є атомною в однопроцесорних системах, однак для багатопроцесорних систем це не гарантовано є атомним і замком потрібно було б зробити так. Якщо ви працюєте в багатопроцесорній системі, з'явиться вікно, де потоки можуть втручатися і давати неправильні результати.

Зокрема, я зібрав ваш код до складання за допомогою https://godbolt.org/ і foo()компілює:

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

Це означає, що він виконує виключно інструкцію додавання, яка для одного процесора буде атомною (хоча, як було сказано вище, не так для багатопроцесорної системи).

Я думаю, що це не так вже й справа, якщо ви спите до або після u++. Це швидше те, що операція u++перекладається на код, який - порівняно з накладними нерестовими потоками, які викликають foo- дуже швидко виконується таким чином, що навряд чи вдасться перехопитись. Однак, якщо ви "продовжите" операцію u++, стан гонки стане набагато імовірнішим:

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

результат: 694

До речі: Я також спробував

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

і це давало мені більшість разів 1997, але іноді 1995.

Він страждає від перегонів. Покладіть usleep(1000);перед тим u++;в fooі я бачу різний висновок (<1000) кожен раз.

1. Ймовірний відповідь , чому стан гонки не проявляється для вас, хоча це дійсно існує, є те , що foo()так швидко, по порівнянні з часом, який потрібен , щоб почати нитка, що кожна нитка закінчується до наступного може навіть почати. Але ...

2. Навіть у вашій оригінальній версії результат змінюється залежно від системи: я спробував це по-своєму (чотириядерний) Macbook, і за десять запускав я отримав 1000 тричі, 999 шість разів і 998 раз. Тож гонка дещо рідкісна, але явно присутня.

3. Ви компілювали '-g', у якого є можливість зникнути помилки. Я перекомпілював ваш код, як і раніше незмінний, але без '-g', і гонка стала набагато більш вираженою: я отримав 1000 раз, 999 тричі, 998 двічі, 997 двічі, 996 один раз і 992 раз.

4. Re. пропозиція про додавання сну - це допомагає, але (a) фіксований час сну залишає нитки все ще перекошеними до часу запуску (за умови дозволу таймера), і (b) випадковий сон поширює їх, коли ми хочемо потягніть їх ближче один до одного. Натомість я б зашифрував їх, щоб дочекатися стартового сигналу, тому я можу створити їх усі, перш ніж дозволити їм працювати. З цією версією (з або без '-g') я отримую результати в усьому місці, аж до 974 і не вище 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;
   }