синхронизация потоков - деликатный вопрос

Вы должны понимать, что операция приращения на самом деле:

read the value
add 1
write the value back

Вы должны спросить себя, что произойдет, если два из них произойдут в двух независимых потоках одновременно:

static int a = 0;

thread 1 reads a (0)
adds 1 (value is 1)
thread 2 reads a (0)
adds 1 (value is 1)
thread 1 writes (1)
thread 2 writes (1)

Для двух одновременных приращений вы можете видеть, что одно из них может быть потеряно, потому что оба потока читают предварительно увеличенное значение.

Приведенный вами пример усложнен индексом статического цикла, который я сначала не заметил. Поскольку это код C++, стандартная реализация заключается в том, что статические переменные видны всем потокам, поэтому для всех потоков существует только одна переменная подсчета циклов. Разумнее всего было бы использовать обычную переменную auto, потому что каждый поток будет иметь свою собственную переменную, не требующую блокировки.

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

Если i совместно используется несколькими потоками, все ставки сняты. Любой поток может увеличить i практически в любой момент во время выполнения другого потока (в том числе в середине операции увеличения этого потока). Нет смысла рассуждать о содержимом i в приведенном выше коде. Не делай этого. Либо дайте каждому потоку собственную копию i, либо сделайте приращение и сравнение с 10 одной атомарной операцией.

На самом деле это не деликатный вопрос, потому что вы бы никогда не допустили этого в реальном коде, если бы возникла проблема с синхронизацией.

Я просто буду использовать i++ в вашем цикле:

for (static int i=0; i<10; i++)
{
}

Потому что он имитирует a. (Обратите внимание, static здесь очень странно)

Подумайте, приостанавливается ли поток A, как только он достигает i++. Поток B получает i вплоть до 9, переходит в i++ и делает его 10. Если бы ему нужно было двигаться дальше, петля существовала бы. Ах, но теперь Тема А возобновлена! Таким образом, он продолжает с того места, на котором остановился: приращение i! Итак, i становится 11, и ваш цикл прерывается.

Каждый раз, когда потоки обмениваются данными, они должны быть защищены. Вы также можете сделать так, чтобы i++ и i < 10 происходили атомарно (никогда не прерывались), если ваша платформа поддерживает это.

Для решения этой проблемы следует использовать взаимное исключение.

И именно поэтому в многопоточной среде мы должны использовать блокировки.

В вашем случае вы должны написать:

bool test_increment(int& i)
{
  lock()
  ++i;
  bool result = i < 10;
  unlock();
  return result;
}

static a;
for(static int i = -1 ; test_increment(i) ; )
{
   ++a;
   // Point A
}

Теперь проблема исчезает. Обратите внимание, что lock() и unlock() должны блокировать и разблокировать мьютекс, общий для всех потоков, пытающихся получить доступ к i!

Да, возможно, что любой поток может выполнять большую часть работы в этом цикле. Но, как объяснил Dynite, это никогда не будет (и не должно) отображаться в реальном коде. Если синхронизация является проблемой, вы должны обеспечить мьютекс взаимного исключения (Boost, pthread или Windows Thread), чтобы предотвратить такие условия гонки.

Зачем вам использовать статический счетчик циклов?

Это пахнет домашней работой, и плохой.

Оба потока имеют свою собственную копию i, поэтому поведение может быть любым. Это одна из причин, почему это такая проблема.

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

И кто-то, несомненно, укажет, что «volatile не имеет смысла в многопоточности!» но люди говорят много глупостей. Вам не обязательно иметь volatile, но это полезно для некоторых вещей.

Если ваш «int» не является размером слова атомной машины (например, 64-битный адрес + данные, эмулирующие 32-битную виртуальную машину), вы будете "word-tear". В этом случае ваш «int» равен 32 битам, но машина адресует 64 атомарно. Теперь вам нужно прочитать все 64, увеличить половину и записать все обратно.

Это гораздо более серьезная проблема; узнайте больше о наборах инструкций процессора и grep gcc о том, как он реализует «volatile» везде, если вам действительно нужны кровавые подробности.

Добавьте «volatile» и посмотрите, как изменится машинный код. Если вы не смотрите на регистры чипа, просто используйте библиотеки повышения и покончите с этим.

Если вам нужно одновременно увеличить значение с несколькими потоками, найдите «атомарные операции». Для Linux найдите «атомарные операции gcc». На большинстве платформ имеется аппаратная поддержка для атомарного увеличения, добавления, сравнения и замены и т. д. БЛОКИРОВКА БЫЛА БЫ ИЗБЫТОЧНОЙ для этого .... atomic inc на величину быстрее, чем lock inc unlock. Если вам нужно изменить много полей одновременно, вам может понадобиться блокировка, хотя вы можете изменить 128-битные поля за раз с помощью большинства атомарных операций.

volatile — это не то же самое, что атомарная операция. Volatile помогает компилятору понять, когда использовать копию переменной — плохая идея. Среди его применений volatile важно, когда у вас есть несколько потоков, изменяющих данные, которые вы хотели бы прочитать «самую последнюю версию» без блокировки. Volatile по-прежнему не решит вашу проблему с a ++, поскольку два потока могут одновременно считывать значение «a», а затем оба увеличивают одно и то же «a», а затем выигрывает последний, написавший «a», и вы потеряли inc. Volatile замедлит оптимизированный код, не позволяя компилятору хранить значения в регистрах, а что нет.