Энтони Уильямс - Параллельное программирование на С++ в действии. Практика разработки многопоточных программ

++z;

}

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();

assert(z.load() != 0); ← (7)

}

Барьер освобождения (2)синхронизируется-с барьером захвата (5), потому что операция загрузки yв точке (4)читает значение, сохраненное в точке (3). Это означает, что сохранение x (1)происходит-раньше загрузки x (6), поэтому прочитанное значение должно быть равно true, и утверждение (7)не сработает. Здесь мы наблюдаем разительное отличие от исходного случая без барьеров, когда сохранение и загрузка xне были упорядочены, и утверждение могло сработать. Отметим, что оба барьера обязательны: чтобы получить отношение синхронизируется-с необходимо освобождение в одном потоке и захват в другом.

В данном случае барьер освобождения (2)оказывает такой же эффект, как если бы операция сохранения y (3)была помечена признаком memory_order_release, а не memory_order_relaxed. Аналогично эффект от барьера захвата (5)такой же, как если бы операция загрузки y (4)была помечена признаком memory_order_acquire. Это общее свойство всех барьеров: если операция захвата видит результат сохранения, имевшего место после барьера освобождения, то барьер синхронизируется-с этой операцией захвата. Если же операция загрузки, имевшая место до барьера захвата, видит результат операции освобождения, то операция освобождения синхронизируется-с барьером захвата. Разумеется, можно поставить барьеры по обе стороны, как в примере выше, и в таком случае если загрузка, которая имела место до барьера захвата, видит значение, записанное операцией сохранения, имевшей место после барьера освобождения, то барьер освобождения синхронизируется-с барьером захвата.

Хотя барьерная синхронизация зависит от значений, прочитанных или записанных операциями до и после барьеров, важно отметить, что точкой синхронизации является сам барьер. Если взять функцию write_x_then_yиз листинга 5.12 и перенести запись в xпосле барьера, как показано ниже, то уже не гарантируется, что условие в утверждение будет истинным, несмотря на то что запись в x предшествует записи в y:

void write_x_then_y() {

std::atomic_thread_fence(std::memory_order_release);

x.store(true, std::memory_order_relaxed);

y.store(true, std::memory_order_relaxed);

}

Эти две операции больше не разделены барьером и потому не упорядочены. Барьер обеспечивает упорядочение только тогда, когда находится между сохранением xи сохранением y. Конечно, наличие или отсутствие барьера не влияет на упорядочения, обусловленные отношениями происходит-раньше, которые существуют благодаря другим атомарным операциям.

Данный пример, как и почти все остальные в этой главе, целиком построен на переменных атомарных типов. Однако реальная польза от применения атомарных операций для навязывания упорядочения проистекает из того, что они могут упорядочивать неатомарные операции и тем самым предотвращать неопределенное поведение из-за гонок за данными, как мы видели в листинге 5.2.

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

Листинг 5.13.Принудительное упорядочение неатомарных операций

#include

#include

#include

bool x = false; ←┐ Теперь x — простая

std::atomic y;│ неатомарная

std::atomic 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.