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

RMW-операции — не единственная ситуация, в которой применение std::atomic ведет к успешным параллельным вычислениям, а volatile — к неудачным. Предположим, что одна задача вычисляет важное значение, требуемое для второй задачи. Когда первая задача вычисляет значение, она должна сообщить об этом второй задаче. В разделе 7.5 поясняется, что одним из способов, которым один поток может сообщить о доступности требуемого значения другому потоку, является применение std::atomic. Код в задаче, выполняющей вычисление значения, имеет следующий вид:

std::atomic valAvailable(false);
auto imptValue = computeImportantValue(); // Вычисление значения

valAvailable = true;                      // Сообщение об этом
                                          // другому потоку

Как люди, читая этот код, мы знаем, что критично важно, чтобы присваивание imptValue имело место до присваивания valAvailable, но все компиляторы видят здесь просто пару присваиваний независимым переменным. В общем случае компиляторы имеют право переупорядочить такие независимые присваивания. Иначе говоря, последовательность присваиваний (где а, b, x и y соответствуют независимым переменным)

а = b;
x = y;

компиляторы могут переупорядочить следующим образом:

x = y;
а = b;

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

Однако применение std::atomic накладывает ограничения на разрешенные переупорядочения кода, и одно такое ограничение заключается в том, что никакой код, предшествующий в исходном тексте записи переменной std::atomic, не может иметь место (или выглядеть таковым для других ядер) после нее[27]. Это означает, что в нашем коде

auto imptValue = computeImportantValue(); // Вычисление значения
valAvailable = true;                      // Сообщение об этом
                                          // другому потоку

компиляторы должны не только сохранять порядок присваиваний imptValue и valAvailable, но и генерировать код, который гарантирует, что так же поведет себя и аппаратное обеспечение. В результате объявление valAvailable как std::atomic гарантирует выполнение критичного требования к упорядоченности — что значение imptValue должно быть видимо всеми потоками как измененное не позже, чем значение valAvailable.

Объявление valAvailable как volatile не накладывает такое ограничение на переупорядочение кода:

volatile bool valAvailable(false);
auto imptValue = computeImportantValue();
valAvailable = true; // Другие потоки могут увидеть это
                     // присваивание до присваивания 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)), отвечу: нет, люди не пишут непосредственно такой код, по крайней мере я очень на это надеюсь. Однако после того как компиляторы получают разумно выглядящий код и выполняют инстанцирования шаблонов, встраивание кода и различные виды переупорядочивающих оптимизаций, в результате не так уже редко получаются и избыточные загрузки, и бессмысленные сохранения, от которых компиляторы могут избавиться.