Скотт Мейерс - Эффективный и современный С++. 42 рекомендации по использованию С++11 и С++14

// присваивание до присваивания imptValue!

Здесь компиляторы могут изменить порядок присваиваний переменным imptValueи valAvailable, но даже если они этого не сделают, они могут не сгенерировать машинный код, который предотвратит возможность аппаратному обеспечению сделать так, что другие ядра увидят изменение valAvailableдо изменения imptValue.

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

“Нормальная”, “обычная” память обладает тем свойством, что если вы записываете в нее значение, то оно остается неизменным, пока не будет перезаписано. Так что если у меня есть обычный int

int x;

и компилятор видит последовательность операций

auto y = x; // Чтение x

y = x; // Чтение x еще раз

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

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

x = 10; // Запись x

х = 20; // Запись x еще раз

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

auto y = x; // Чтение x

y = x; // Чтение x еще раз

x = 10; // Запись x

х = 20; // Запись x еще раз

то компиляторы могут рассматривать его, как если бы он имел следующий вид:

auto y = x; // Чтение x

х = 20; // Запись x

Чтобы вас не мучило любопытство, кто в состоянии написать такой код с избыточными чтениями и лишними записями (технически известными как избыточные загрузки (redundant loads) и бессмысленные сохранения (dead stores)), отвечу: нет, люди не пишут непосредственно такой код, по крайней мере я очень на это надеюсь. Однако после того как компиляторы получают разумно выглядящий код и выполняют инстанцирования шаблонов, встраивание кода и различные виды переупорядочивающих оптимизаций, в результате не так уже редко получаются и избыточные загрузки, и бессмысленные сохранения, от которых компиляторы могут избавиться.

Такие оптимизации корректны, только если память ведет себя нормально. “Особая” память так себя не ведет. Наиболее распространенным видом особой памяти, вероятно, является память, используемая для отображенного на память ввода-вывода. . Вместо чтения и записи обычной памяти, местоположения в такой особой памяти в действительности сообщаются с периферийными устройствами, например внешними датчиками или мониторами, принтерами, сетевыми портами и т.п. Давайте с учетом этого снова рассмотрим код с, казалось бы, избыточными чтениями:

auto y = x; // Чтение x

y = x; // Чтение x еще раз

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

Похожа ситуация с записями, кажущимися излишними. Например, если в коде

x = 10; // Запись x

х = 20; // Запись x еще раз

переменная x соответствует управляющему порту радиопередатчика, может оказаться, что этот код выполняет некоторые команды с радиопередатчиком, и значение 10 соответствует команде, отличной от имеющей код 20. Оптимизация, убирающая первое присваивание, могла бы изменить последовательность команд, отправляемых радиопередатчику.

Квалификатор volatileпредставляет собой способ сообщить компиляторам, что мы имеем дело с такой особой памятью. Для компилятора это означает “не выполняй никаких оптимизаций над операциями с этой памятью”. Так что если переменная xсоответствует особой памяти, она должна быть объявлена как volatile:

volatileint x;

Рассмотрим влияние этого квалификатора на последовательность нашего исходного кода:

auto y = x; // Чтение x

y = x; // Чтение x еще раз (не может быть устранено)

x = 10; // Запись x (не может быть устранена)

x = 20; // Запись x еще раз

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

Вопрос на засыпку: какой тип у в последнем фрагменте кода: intили volatile int [28] Тип y получается с помощью вывода auto , так что используются правила, описанные в разделе 1.2. Эти правила предписывают, чтобы для объявления типов, не являющихся ссылочными или типами указателей (что и выполняется о случае y ), квалификаторы const и volatile были опущены. Следовательно, типом y является просто int . Это означает, что избыточные чтения и записи y могут быть удалены. В приведенном примере компиляторы должны выполнять и инициализацию, и присваивание y , поскольку x объявлена как volatile , так что второе чтение x может давать другое значение, отличное от первого. ?

Тот факт, что кажущиеся избыточными загрузки и бессмысленные сохранения должны оставаться на месте при работе с особой памятью, объясняет, кстати, почему для такого рода работы не подходят объекты std::atomic. Компиляторам разрешается устранять такие избыточные операции у std::atomic. Код написан не в точности так же, как и для volatile, но если мы на минуту отвлечемся от этого и сосредоточимся на том, что компиляторам разрешается делать, то можно сказать, что концептуально компиляторы могут, получив код

std::atomic<int >x;

auto y = x; // Концептуально читает x (см. ниже)

y = x; // Концептуально читает x еще раз (см. ниже)

x = 10; // Записывает x

х = 20; // Записывает x еще раз

оптимизировать его до

auto y = x; // Концептуально читает x (см. ниже)

x = 20; // Записывает x

Очевидно, что это неприемлемое поведение при работе с особой памятью.

Но если xимеет тип std::atomic, ни одна из этих инструкций компилироваться не будет:

auto y = x; // Ошибка!

y = x; // Ошибка!

Дело в том, что копирующие операции в std::atomicудалены (см. раздел 3.5). И не зря. Рассмотрим, что произошло бы, если бы инициализация у значением x компилировалась. Поскольку xимеет тип std::atomic, тип у был бы также выведен как std::atomic(см. раздел 1.2). Ранее я отмечал, что одна из лучших возможностей std::atomicзаключается в атомарности всех их операций, но чтобы копирующее конструирование yиз xбыло атомарным, компиляторы должны генерировать код для чтения xи записи yкак единую атомарную операцию. В общем случае аппаратное обеспечение не в состоянии это сделать, так что копирующее конструирование типами std::atomicне поддерживается. Копирующее присваивание удалено по той же причине, а потому присваивание xпеременной yтакже не компилируется. (Перемещающие операции не объявлены в std::atomicявно, так что в соответствии с правилами генерации специальных функций, описанных в разделе 3.11, std::atomicне предоставляет ни перемещающего конструирования, ни перемещающего присваивания.)