Атомарное поведение унарных операторов приращения

Somewhere I read that unary operators are atomic by nature and so they can be used as it is in multi threaded environment.

Этот источник совершенно неверен. Вам нужно использовать std::atomic (или эквивалент C) для достижения атомарности - унарные операции не являются чем-то особенным.

I compared the disassembly of both programs and found no difference

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

Утверждение, что унарный оператор обязательно атомарен, является мифом.

Например, для ++x требуется чтение и запись в x, что открывает возможность гонки данных.

Тот факт, что ++x компилируется с тем же кодом, что и x = x + 1, не имеет значения.

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

Somewhere I read that unary operators are atomic by nature and so they can be used as it is in multi threaded environment.

Это неправда. x++, например, требует загрузки x, добавления и сохранения x. Эти инструкции не атомарны по своей природе.

Не правда. Даже если бы это было так, какая тогда причина была бы в https://en.cppreference.com/w/cpp/atomic/atomic#Type_aliases?

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

Атомарность операции stronglr зависит от целевой системы. Унарная операция может не быть атомарной в системах RMW, таких как микроконтроллеры RISC.

На этот вопрос нет единого универсального ответа.

При написании кросс-платформенного C++ у вас есть только атомарное поведение при использовании std::atomic<>.

Это правда, что на некоторых платформах, таких как Intel 64bit, процессор гарантирует, что inc является атомарным. Однако, пожалуйста, не пишите код, который зависит от этого! Как ваш будущий отладчик, я хотел бы знать, какие данные предназначены для совместного использования по потокам, а какие нет.

Использование std::atomic<int> может потребовать немного больше работы для написания, однако оно гарантирует, что все будет вести себя атомарно (на каждой платформе) либо путем возврата к требованиям платформы (std :: atomic :: is_lock_free), либо путем явной блокировки доступа. Он также вставляет ограждения, чтобы убедиться, что кеши других ядер процессора недействительны (если этого требует платформа).

На практике для Intel 64bit это должно дать вам ту же сборку, если нет, зарегистрировать ошибку в вашем компиляторе.

В то же время некоторые операции с целыми числами могут не быть атомарными (оператор * =), std::atomic просто не хранит эти операции, требуя от вас правильной работы с ними.

Кстати, ++x и x = x+1 - это разные операции, они могут быть оптимизированы для одной и той же сборки. Учитывая неатомарные требования к платформе, вторая внезапно представляет собой ошибку, на решение которой уходит несколько дней.

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

В вашем случае это предполагает, что целевой процессор имеет инструкцию inc <address>, и компилятор сгенерирует ее.

Вы не указали тип x.

1. Если x - 32-битное целое число, когда платформа - 16- или 8-битная, операция 'x ++' обязательно сделаю несколько операций
2. x может быть даже не базовым типом, x может быть экземпляром класса, где оператор ++ делает гораздо более сложные вещи, чем просто увеличивает целое число

Atomic behavior of unary operators

В C ++ до / после исправления не являются унарные операторы, например & * + - ~ !. но часть унарное выражение. Таким образом, заголовок вопроса не соответствует тексту.

Даже унарный оператор, такой как +, не является атомарным, поскольку доступ к объекту (например, long long) заставляет выполнять несколько операций чтения кода операции.