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

Question

Я использую 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; 
} 

Answer 1

foo() настолько короток, что каждый поток, вероятно, завершится до следующих один даже получает породил. Если вы добавляете спать в случайное время в foo() до u++, вы можете начать видеть то, что ожидаете.

Answer 2

Важно понимать, что условие гонки не гарантирует, что код будет работать некорректно, просто чтобы он мог что-либо сделать, поскольку это неопределенное поведение. Включая работу как ожидалось.

В частности, на условиях ракеты X86 и AMD64 в некоторых случаях редко возникают проблемы, так как многие из инструкций являются атомарными, а гарантии согласованности очень велики. Эти гарантии несколько снижаются в многопроцессорных системах, где префикс блокировки необходим для того, чтобы многие инструкции были атомарными.

Если на вашей машине приращение является атомарным оператором, это, скорее всего, будет работать корректно, хотя в соответствии со стандартом языка это неопределенное поведение.

В частности, я ожидаю, что в этом случае код может быть скомпилирован в атомную инструкцию Fetch and Add (ADD или XADD в сборке X86), которая действительно является атомарной в однопроцессорных системах, однако на многопроцессорных системах это не гарантируется как атомарное и для этого потребуется блокировка. Если вы работаете в многопроцессорной системе, появится окно, в котором потоки могут вмешиваться и создавать неверные результаты.

Конкретно я составил код для сборки с помощью https://godbolt.org/ и foo() компилирует:

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

Это означает, что он только выполняет инструкцию надстройку, которая для одного процессора будет атомное (хотя, как отмечалось выше, не так для многопроцессорная система).

Answer 3

Он страдает от состояния гонки. Положите usleep(1000); до u++; в foo и я вижу различный выход (< 1000) каждый раз.

Answer 4

Я думаю, что это не так, если вы спали до или после u++. Скорее, операция u++ переводит на код, который является - по сравнению с накладными расходами на нерестовые потоки, которые вызывают foo - очень быстро выполняется так, что вряд ли его перехватят.Тем не менее, если вы "продлить" операцию u++, то условие гонки будет гораздо больше шансов:

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

результат: 694

---

BTW: Я также попытался

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

и это давало мне чаще всего 1997, но иногда 1995.

Answer 5

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