Почему код, изменяющий общую переменную между потоками, по-видимому, НЕ страдает от состояния гонки?

Я использую 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 условия гонки в некоторых случаях редко вызывают проблемы, поскольку многие инструкции являются атомарными, а гарантии согласованности очень высоки. Эти гарантии несколько снижаются в многопроцессорных системах, где префикс блокировки необходим для того, чтобы многие инструкции были атомарными.

Если на вашем компьютере инкремент является атомарной операцией, он, скорее всего, будет работать правильно, даже если в соответствии со стандартом языка это Undefined Behavior.

В частности, я ожидаю, что в этом случае код может быть скомпилирован для атомарной выборки и добавления инструкцию (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. предложение добавить сон - это помогает, но (а) фиксированное время сна оставляет потоки по-прежнему искаженными по времени начала (в зависимости от разрешения таймера), и (б) случайный сон распределяет их, когда мы хотим, чтобы притянуть их ближе друг к другу. Вместо этого я бы закодировал их так, чтобы они ожидали сигнала запуска, чтобы я мог создать их все, прежде чем позволить им приступить к работе. С этой версией (с или без '-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;
   }