Атомика C ++ 11: имеет ли смысл или даже возможно ли использовать их с вводом / выводом с отображением в памяти?

Question

Атомика C ++ 11: имеет ли смысл или даже возможно ли использовать их с вводом / выводом с отображением в памяти?

Как я понимаю, C volatile и, необязательно, встроенный asm для ограничения памяти использовался для реализации драйвера устройства поверх ввода-вывода с отображением в памяти. Несколько примеров можно найти в ядре Linux.

Если мы забудем о риске неисследованных исключений (если они есть), имеет ли смысл заменить их атомами C ++ 11? Или это вообще возможно?

4

atomic c++c++11 device-driver memory-mapping

Решение

Другие решения

Как я понимаю для чтения ссылок std::atomic предназначен для управления многопоточным доступом к памяти (параллелизм и т. д.). Но, как я знаю, как ты и сказал, volatile предназначен для таких вещей, как ввод-вывод с отображением памяти и обработка сигналов. Так, volatile не влияет на атомарный доступ и не разрешает проблемы многопоточного доступа, такие как атомарный, если используется один. И наоборот — атомики не предоставляют возможности volatile,

Таким образом, краткий ответ на ваш вопрос — НЕТ.

2

Источник

Accepted Answer

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

Что касается ввода / вывода с отображением в памяти, то атомика недостаточно, чтобы:

volatile гарантирует вам, что все обращения к памяти в этой переменной в вашей программе действительно произойдут и что они происходят (в пределах одного потока) именно в указанном вами порядке.
std::atomic только гарантирует, что ваша программа будет вести себя как будто все эти обращения к памяти происходят (в соответствии с моделью памяти C ++, которая не знает о вводе / выводе, отображенном в памяти) и — в зависимости от указанного порядка памяти — как будто они происходят в указанном порядке.

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

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

РЕДАКТИРОВАТЬ: например, Эта бумага показывает несколько возможных (и, возможно, неожиданных) оптимизаций, которые компилятору разрешено применять к переменной атомарного цикла.

2