Может ли num ++ быть атомарным для int num?

Это абсолютно то, что C ++ определяет как гонку данных, которая вызывает неопределенное поведение, даже если один компилятор создал код, который сделал то, что вы надеялись, на какой-то целевой машине. Вам нужно использовать std::atomic для надежных результатов, но вы можете использовать его с memory_order_relaxed, если вас не волнует изменение порядка. Ниже приведен пример кода и вывода asm с использованием fetch_add.

Но сначала ассемблерная часть вопроса:

Поскольку num ++ - это одна инструкция (add dword [num], 1), можем ли мы сделать вывод, что num ++ в этом случае является атомарным?

Инструкции назначения памяти (кроме чистых хранилищ) - это операции чтения-изменения-записи, которые выполняются в несколько внутренних шагов . Никакой архитектурный регистр не изменяется, но ЦП должен хранить данные внутри, пока он отправляет их через свой ALU . Фактический файл регистров - это лишь небольшая часть хранилища данных даже в простейшем ЦП, с защелками, удерживающими выходы одного каскада в качестве входов для другого каскада и т. Д.

Операции с памятью других ЦП могут стать глобально видимыми между загрузкой и сохранением. Т.е. два потока, выполняющие add dword [num], 1 в цикле, будут наступать на хранилища друг друга. (См. ответ @ Margaret для приятного диаграмму). После увеличения на 40 КБ для каждого из двух потоков счетчик мог бы увеличиться только на ~ 60 КБ (не 80 КБ) на реальном многоядерном оборудовании x86.

«Атомный» от греческого слова, означающего «неделимый», означает, что ни один наблюдатель не может видеть операцию как отдельные шаги. Выполнение физически / электрически мгновенно для всех битов одновременно - это всего лишь один из способов добиться этого для загрузки или сохранения, но это невозможно даже для операции ALU. Я подробно рассмотрел чистые нагрузки и чистые хранилища в мой ответ на атомарность на x86 , в то время как этот ответ посвящен на чтение-изменение-запись.

Префикс lock может применяться ко многим операциям чтения-изменения-записи (память destination), чтобы сделать всю операцию атомарной относительно всех возможных наблюдателей в системе (других ядер и устройств прямого доступа к памяти, а не осциллографа, подключенного к выводам ЦП). Вот почему он существует. (См. Также этот вопрос и ответ) .

Итак, lock add dword [num], 1 является атомарным . Ядро ЦП, выполняющее эту инструкцию, будет удерживать строку кэша закрепленной в состоянии Modified в своем частном кэше L1 с момента, когда загрузка считывает данные из кеша, до тех пор, пока хранилище не зафиксирует свой результат обратно в кеш. Это препятствует тому, чтобы любой другой кеш в системе имел копию строки кеша в любой момент от загрузки до хранилища в соответствии с правилами Протокол согласованности кэша MESI (или его версии MOESI / MESIF, используемые многоядерными процессорами AMD / Intel, соответственно). Таким образом, операции других ядер происходят либо до, либо после, а не во время.

Без префикса lock другое ядро ​​могло бы стать владельцем строки кэша и изменить ее после нашей загрузки, но до нашего хранилища, чтобы другое хранилище стало глобально видимым между нашей загрузкой и хранилищем. Некоторые другие ответы ошибаются и утверждают, что без lock вы получите конфликтующие копии одной и той же строки кэша. Этого никогда не может произойти в системе с согласованными кешами.

(Если инструкция lock ed работает с памятью, занимающей две строки кэша, требуется гораздо больше работы, чтобы убедиться, что изменения в обеих частях объекта остаются атомарными, поскольку они распространяются на всех наблюдателей, поэтому ни один наблюдатель не может видеть Разрыв. ЦП, возможно, придется заблокировать всю шину памяти, пока данные не попадут в память. Не переключайте атомные переменные!)

Обратите внимание, что префикс lock также превращает инструкцию в полный барьер памяти (например, MFENCE ), останавливая все переупорядочивание во время выполнения и, таким образом, обеспечивая последовательную согласованность. (См. отличную запись в блоге Джеффа Прешинга. Его другое все сообщения тоже превосходны и ясно объясняют много хороших вещей о программирование без блокировок, от x86 и других деталей оборудования до правил C ++.)

На однопроцессорной машине или в однопоточном процессе один Инструкция RMW на самом деле является атомарной без префикса lock. Единственный способ для другого кода получить доступ к общей переменной - это для ЦП переключение контекста, чего не может произойти в середине инструкции. Таким образом, простой dec dword [num] может синхронизироваться между однопоточной программой и ее обработчиками сигналов или в многопоточной программе, работающей на одноядерной машине. См. вторую половину моего ответа на другой вопрос и комментарии под ним, где я объясняю это более подробно.

Вернемся к C ++:

Совершенно бессмысленно использовать num++, не сообщая компилятору, что он вам нужен для компиляции в единственную реализацию чтения-изменения-записи:

;; Valid compiler output for num++
mov   eax, [num]
inc   eax
mov   [num], eax

Это очень вероятно, если вы используете значение num позже: компилятор сохранит его в регистре после увеличения. Так что даже если вы проверите, как num++ компилируется сам по себе, изменение окружающего кода может повлиять на него.

(Если значение в дальнейшем не потребуется, предпочтительнее использовать inc dword [num]; современные процессоры x86 будут выполнять инструкцию RMW назначения памяти не менее эффективно, чем использование трех отдельных инструкций. Интересный факт: gcc -O3 -m32 -mtune=i586 фактически выдаст это, потому что суперскалярное пи (Pentium) P5 peline не декодировал сложные инструкции для множества простых микроопераций, как это делают P6 и более поздние микроархитектуры. Дополнительные сведения см. В таблицах инструкций / руководстве по микроархитектуре Agner Fog, а также в x86 тег wiki для многих полезных ссылок (включая руководства Intel x86 ISA, которые бесплатно доступны в виде PDF )).

Не путайте целевую модель памяти (x86) с моделью памяти C ++.

Разрешено изменение порядка во время компиляции . Другая часть того, что вы получаете с std :: atomic, - это контроль над переупорядочением во время компиляции, чтобы ваш num++ стал глобально видимым только после некоторой другой операции.

Классический пример: сохранение некоторых данных в буфере для просмотра другим потоком, а затем установка флага. Несмотря на то, что x86 действительно получает хранилища загрузки / выпуска бесплатно, вы все равно должны указать компилятору не изменять порядок с помощью flag.store(1, std::memory_order_release);.

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

// flag is just a plain int global, not std::atomic<int>.
flag--;       // This isn't a real lock, but pretend it's somehow meaningful.
modify_a_data_structure(&foo);    // doesn't look at flag, and the compilers knows this.  (Assume it can see the function def).  Otherwise the usual don't-break-single-threaded-code rules come into play!
flag++;

Но этого не произойдет. Компилятор может свободно перемещать flag++ по вызову функции (если он встраивает функцию или знает, что не смотрит на flag). Затем он может полностью оптимизировать модификацию, потому что flag даже не volatile. (И нет, C ++ volatile не является полезной заменой std :: atomic. Std :: atomic действительно заставляет компилятор предполагать, что значения в памяти могут быть изменены асинхронно, как volatile, но есть гораздо больше Кроме того, volatile std::atomic<int> foo не то же самое, что std::atomic<int> foo, как обсуждалось с @Richard Hodges.)

Определение гонок данных для неатомарных переменных как Undefined Behavior - это то, что позволяет компилятору по-прежнему поднимать нагрузки и опускать хранилища из циклов, а также многие другие оптимизации для памяти, на которые могут ссылаться несколько потоков. (Подробнее см. этот блог LLVM о том, как UB обеспечивает оптимизацию компилятора.)

Как я уже упоминал, префикс x86 lock - это полный барьер памяти, поэтому использование num.fetch_add(1, std::memory_order_relaxed); генерирует тот же код на x86, что и num++ (по умолчанию - последовательная согласованность), но он может быть намного более эффективным на других архитектурах (например, ARM). Даже на x86, Relaxed позволяет больше переупорядочивать во время компиляции.

Это то, что GCC на самом деле делает на x86 для нескольких функций, которые работают с глобальной переменной std::atomic.

Смотрите исходный код + язык ассемблера, красиво отформатированный на Godbolt compiler explorer. Вы можете выбрать другие целевые архитектуры, включая ARM, MIPS и PowerPC, чтобы увидеть, какой код на языке ассемблера вы получите от Atomics для этих целей.

#include <atomic>
std::atomic<int> num;
void inc_relaxed() {
  num.fetch_add(1, std::memory_order_relaxed);
}

int load_num() { return num; }            // Even seq_cst loads are free on x86
void store_num(int val){ num = val; }
void store_num_release(int val){
  num.store(val, std::memory_order_release);
}
// Can the compiler collapse multiple atomic operations into one? No, it can't.

# g++ 6.2 -O3, targeting x86-64 System V calling convention. (First argument in edi/rdi)
inc_relaxed():
    lock add        DWORD PTR num[rip], 1      #### Even relaxed RMWs need a lock. There's no way to request just a single-instruction RMW with no lock, for synchronizing between a program and signal handler for example. :/ There is atomic_signal_fence for ordering, but nothing for RMW.
    ret
inc_seq_cst():
    lock add        DWORD PTR num[rip], 1
    ret
load_num():
    mov     eax, DWORD PTR num[rip]
    ret
store_num(int):
    mov     DWORD PTR num[rip], edi
    mfence                          ##### seq_cst stores need an mfence
    ret
store_num_release(int):
    mov     DWORD PTR num[rip], edi
    ret                             ##### Release and weaker doesn't.
store_num_relaxed(int):
    mov     DWORD PTR num[rip], edi
    ret

Обратите внимание, как MFENCE (полный барьер) требуется после сохранения последовательной согласованности. x86 в целом строго заказывается, но изменение порядка StoreLoad разрешено. Наличие буфера хранилища необходимо для хорошей производительности конвейерного ЦП, работающего вне очереди. Джефф Прешинг переупорядочение памяти прямо сейчас < / strong> показывает последствия не использования MFENCE с реальным кодом, показывающим переупорядочение, происходящее на реальном оборудовании.

void multiple_ops_relaxed(std::atomic<unsigned int>& num) {
  num.fetch_add( 1, std::memory_order_relaxed);
  num.fetch_add(-1, std::memory_order_relaxed);
  num.fetch_add( 6, std::memory_order_relaxed);
  num.fetch_add(-5, std::memory_order_relaxed);
  //num.fetch_add(-1, std::memory_order_relaxed);
}

multiple_ops_relaxed(std::atomic<unsigned int>&):
    lock add        DWORD PTR [rdi], 1
    lock sub        DWORD PTR [rdi], 1
    lock add        DWORD PTR [rdi], 6
    lock sub        DWORD PTR [rdi], 5
    ret