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() — операция освобождения над той же ячейкой памяти.