Является ли приращение целочисленным атомом в x86?

Машинная инструкция увеличения памяти на X86 является атомарной, только если вы используете ее с префиксом LOCK.

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

Я считаю, что С++ 11 предлагает атомарные приращения, и у большинства компиляторов поставщиков есть идиоматический способ вызвать атомарное приращение определенных встроенных целочисленных типов (обычно int и long); см. справочное руководство по вашему компилятору.

Если вы хотите увеличить «большое значение» (скажем, целое число с множественной точностью), вам нужно сделать это с помощью какого-либо стандартного механизма блокировки, такого как семафор.

Обратите внимание, что вам также нужно беспокоиться об атомарном чтении. На x86 чтение 32- или 64-битного значения оказывается атомарным, если оно выровнено по 64-битному слову. Это не будет верно для «большого значения»; снова вам понадобится стандартный замок.

Вот одно доказательство того, что в конкретной реализации (gcc) это не атомарно. Как видите (?), gcc генерирует код, который

1. загружает значение из памяти в регистр
2. увеличивает содержимое регистра
3. сохраняет регистр обратно в память.

Это очень далеко от атомарности.

$ cat t.c
volatile int a;

void func(void)
{
    a++;
}
[19:51:52 0 ~] $ gcc -O2 -c t.c
[19:51:55 0 ~] $ objdump -d t.o

t.o:     file format elf32-i386


Disassembly of section .text:

00000000 <func>:
   0:   a1 00 00 00 00          mov    0x0,%eax
   5:   83 c0 01                add    $0x1,%eax
   8:   a3 00 00 00 00          mov    %eax,0x0
   d:   c3                      ret

Не дайте себя обмануть 0x0 в инструкции mov, там есть место для 4 байтов, и компоновщик заполнит результирующий адрес памяти для a при линковке этого объектного файла.

Поскольку никто не ответил на ваш реальный вопрос и вместо этого показывает вам, как это сделать так, чтобы это всегда работало:

Поток 1 загружает значение 0

Поток 2 загружает значение 0

Поток 1 увеличивает и сохраняет 1

Поток 2 увеличивает свою копию значения локального регистра и сохраняет 1.

Как видите, конечным результатом является значение, равное 1, а не 2. В конце не всегда будет 2.

Это не гарантируется. Вы можете использовать инструкцию lock xadd для достижения того же эффекта, или использовать C++ std::atomic, или использовать #pragma omp atomic, или любое количество других решений для параллелизма, которые были написаны, чтобы избавить вас от необходимости заново изобретать колесо.