5.3.6. Упорядочение неатомарных операций с помощью атомарных
Если заменить тип переменной x в листинге 5.12 обычным неатомарным типом bool (как в листинге ниже), то гарантируется точно такое же поведение, как и раньше.
Листинг 5.13. Принудительное упорядочение неатомарных операций
#include <atomic>
#include <thread>
#include <assert.h>
bool x = false; ←┐ Теперь x — простая
std::atomic<bool> y;│ неатомарная
std::atomic<int> z; │ переменная
void write_x_then_y() { (1) Сохранение x
x = true; ←┘ перед барьером
std::atomic_thread_fence(std::memory_order_release);
y.store(true, std::memory_order_relaxed);←┐ Сохранение y
} (2) после барьера
void read_y_then_x() (3) Ждем, пока не
{ │ увидим значение,
while (!y.load(std::memory_order_relaxed));←┘ записанное в 2
std::atomic_thread_fence(std::memory_order_acquire);
if (x) ←┐ Здесь будет прочитано
++z; (4) значение, записанное в 1
}
int main() {
x = false;
y = false;
z = 0;
std::thread a(write_x_then_y);
std::thread b(read_y_then_x);
a.join();
b.join(); (5) Это утверждение
assert(z.load() != 0);←┘ не сработает
}
Барьеры по-прежнему обеспечивают упорядочение сохранения x (1) и y (2) и загрузки y (3) и x (4), и, как и раньше, существует отношение происходит-раньше между сохранением x и загрузкой x, поэтому утверждение (5) не сработает. Сохранение y (2) и загрузка y (3) тем не менее должны быть атомарными, иначе возникла бы гонка за y, но барьеры упорядочивают операции над x после того, как поток-читатель увидел сохраненное значение y. Такое принудительное упорядочение означает, что гонки за x нет, хотя ее значение модифицируется в одном потоке, а читается в другом.
Но не только с помощью барьеров можно упорядочить неатомарные операции. Эффект упорядочения мы наблюдали также в листинге 5.10, где пара memory_order_release / memory_order_consume упорядочивала неатомарные операции доступа к динамически выделенному объекту. Многие примеры из этой главы можно было бы переписать, заменив некоторые операции с семантикой memory_order_relaxed простыми неатомарными операциями.
Упорядочение неатомарных операций с помощью атомарных — это та область, где особую важность приобретает аспект расположено-перед отношения происходит-раньше. Если неатомарная операция расположено-перед атомарной, и эта атомарная операция происходит-раньше какой-либо операции в другом потоке, то и неатомарная операция также происходит-раньше этой операции в другом потоке. Именно из этого вытекает упорядочение операций над x в листинге 5.13, и именно поэтому работает пример из листинга 5.2. Этот факт также лежит в основе таких высокоуровневых средств синхронизации в стандартной библиотеке С++, как мьютексы и условные переменные. Чтобы понять, как это работает, рассмотрим простой мьютекс-спинлок из листинга 5.1.
В функции lock() выполняется цикл по flag.test_and_set() с упорядочением std::memory_order_acquire, а функция unlock() вызывает операцию flag.clear() с признаком упорядочения std::memory_order_release. В момент, когда первый поток вызывает lock(), флаг еще сброшен, поэтому первое обращение к test_and_set() установит его и вернет false. Это означает, что поток завладел блокировкой, и цикл завершается. Теперь этот поток вправе модифицировать любые данные, защищенные мьютексом. Всякий другой поток, который вызовет lock() в этот момент, обнаружит, что флаг уже поднят, и потому будет заблокирован в цикле test_and_set(). Когда поток, владеющий блокировкой, закончит модифицировать защищенные данные, он вызовет функцию unlock(), которая вызовет flag.clear() с семантикой std::memory_order_release.
Это приводит к синхронизации-с (см. раздел 5.3.1) последующим обращением к flag.test_and_set() из функции lock() в другом потоке, потому что в этом обращении задана семантика std::memory_order_acquire. Так как модификация защищенных данных обязательно расположена-перед вызовом unlock(), то эта модификация происходит-раньше вызова unlock() и, следовательно, происходит-раньше последующего обращения к lock() из другого потока (благодаря наличию отношения синхронизируется-с между unlock() и lock()) и происходит-раньше любой операции доступа к данным из второго потока после того, как он захватит блокировку.
В других реализациях мьютексов используются иные внутренние операции, но принцип остается неизменным: lock() — это операция захвата над некоторой внутренней ячейкой памяти, a unlock() — операция освобождения над той же ячейкой памяти.