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

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

  1. Я использовал переменную x и увеличил ее, используя унарный оператор ++ x
  2. Я использовал переменную x и увеличил, используя x = x + 1

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

2
Ваши переменные атомарны? Например, типа std :: atomic в C ++.
добавлено автор Daniel Langr, источник
Неважно, является ли какая-то инструкция атомарной, правильная синхронизация или гонка.
добавлено автор Baum mit Augen, источник
Я подозреваю, что везде, где вы читали, слово «атомарный» использовалось в ином смысле, чем то, которое использовалось в контексте параллелизма. Либо это, либо они были совершенно не правы, и вы не должны доверять всему, что видели там.
добавлено автор molbdnilo, источник
Продолжение самому себе: до того, как параллелизм был повсюду, можно сказать, что префикс ++ «атомарно увеличивает переменную и возвращает ее новое значение», но «атомарно» означает, что она синтаксически - это всего лишь одна операция, а не то, что она неделима.
добавлено автор molbdnilo, источник
То, что ++ x является атомарным, не означает, что x = x + 1 нет? (С логической точки зрения я сомневаюсь, что ++ x всегда атомарен)
добавлено автор Ctx, источник
Данная переменная может находиться в памяти и, следовательно, требовать нескольких инструкций (загрузить, добавить, сохранить), они не являются автоматически атомарными.
добавлено автор Simon F, источник

7 ответы

Где-то я читал, что унарные операторы являются атомарными по своей природе, и поэтому их можно использовать как в многопоточной среде. </Р>

That source is completely wrong. You need to use std::atomic (or the C equivalent) to achieve atomicity – unary operations are not special.


Я сравнил разборку обеих программ и не обнаружил разницы

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

8
добавлено

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

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

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

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

3
добавлено
Ты одинарный.
добавлено автор Sombrero Chicken, источник

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

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

2
добавлено

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

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

1
добавлено

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

На этот вопрос нет единого общего ответа.

1
добавлено
Хороший ответ (хотя и немного краткий), поскольку он не утверждает, что он никогда не может быть атомарным (как это делают другие). Но есть «единый общий ответ» на вопрос: «Нет, унарные операторы не атомарны по своей природе ».
добавлено автор Ctx, источник

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

In your case this supposes the target processor has the instruction inc

and the compiler will produce it.
0
добавлено

When writing cross platform C++, you only have atomic behavior when using std::atomic<>.

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

Using std::atomic might be a bit more work to write, however, it does guarantee that everything behaves atomically (on every platform) by either falling back to the platform requirements (std::atomic::is_lock_free), or by explicitly putting a lock around the access. It as well insert guards in order to make sure that the caches of the other processor cores are invalidated (if the platform requires this).

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

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

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

0
добавлено
pro.cxx
pro.cxx
3 049 участник(ов)

C/C++ chat 0. Простые вопросы, лабы и о IDE — в чат новичков @supapro 1. Не хамим, не переходим на личности, не вбрасываем утверждения без доказательств 2. No Ads, offtop, flood Объявления о вакансиях и евенты - в лс @AlexFails https://t.me/ProCxx/259155

supapro.cxx
supapro.cxx
1 925 участник(ов)

Чат для тех, кто немного знает C++, простые вопросы по реализации, синтаксису и ide – сюда, а для другого есть: /Главный чат по серьезным вопросам — @ProCxx /Чат по обсуждению всего — @fludpac

C++ Russia
C++ Russia
384 участник(ов)

Сообщество разработчиков C++ в Telegram.

cxx.Дискуссионная
cxx.Дискуссионная
298 участник(ов)

это не двач, общайтесь вежливо; разговор на почти любые темы; Не согласны с баном? В лс @AlexFails, @ivario

C++ для маленьких и тупых
C++ для маленьких и тупых
105 участник(ов)

Лоу левел (по среднему IQ участников) чатик ExtremeCode @extremecode Флудилка @extremecode_rest