std:: memory_order

std::memory_order определяет, каким образом операции с памятью, включая обычные неатомарные обращения к памяти, должны упорядочиваться относительно атомарной операции. При отсутствии ограничений в многопроцессорной системе, когда несколько потоков одновременно читают и записывают несколько переменных, один поток может наблюдать изменение значений в порядке, отличном от порядка, в котором другой поток их записывал. Более того, видимый порядок изменений может различаться даже между несколькими потоками-читателями. Некоторые схожие эффекты могут возникать даже в однопроцессорных системах из-за преобразований компилятора, разрешённых моделью памяти.

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

Константы

Формальное описание

Межпоточная синхронизация и упорядочение памяти определяют, как вычисления и побочные эффекты выражений упорядочиваются между различными потоками выполнения. Они определяются следующими терминами:

Упорядочено-перед

В рамках одного потока вычисление A может быть sequenced-before вычислением B, как описано в разделе evaluation order .

Порядок модификации

Все изменения любого конкретного атомарного переменного происходят в полном порядке, который специфичен именно для этой одной атомарной переменной.

Следующие четыре требования гарантируются для всех атомарных операций:

Последовательность освобождения

После выполнения операции освобождения A над атомарным объектом M, самая длинная непрерывная подпоследовательность порядка модификации M, состоящая из:

Известно как release sequence headed by A .

Синхронизируется с

Если атомарная запись в потоке A является операцией освобождения (release operation) , атомарное чтение в потоке B из той же переменной является операцией захвата (acquire operation) , и чтение в потоке B получает значение, записанное операцией записи в потоке A, тогда запись в потоке A синхронизируется-с (synchronizes-with) чтением в потоке B.

Кроме того, некоторые вызовы библиотечных функций могут быть определены для синхронизации-с другими вызовами библиотечных функций в других потоках.

Межпоточное отношение happens-before

Между потоками, вычисление A межпоточно предшествует вычислению B, если выполняется любое из следующих условий:

Сильно предшествует (Strongly happens-before)

Независимо от потоков, вычисление A строго предшествует вычислению B, если выполняется любое из следующих условий:

Видимые побочные эффекты

Побочный эффект A над скаляром M (запись) является видимым по отношению к вычислению значения B над M (чтение), если выполняются оба следующих условия:

Если побочный эффект A виден относительно вычисления значения B, то наибольшее непрерывное подмножество побочных эффектов в M, в порядке модификации , где B не происходит-до него, известно как видимая последовательность побочных эффектов (значение M, определяемое B, будет значением, сохранённым одним из этих побочных эффектов).

Примечание: синхронизация между потоками сводится к предотвращению состояний гонки (путем установления отношений happens-before) и определению того, какие побочные эффекты становятся видимыми при каких условиях.

Операция потребления

Атомарная загрузка с memory_order_consume или более строгим порядком является операцией потребления. Заметьте, что std::atomic_thread_fence накладывает более строгие требования синхронизации, чем операция потребления.

Операция Acquire

Атомарная загрузка с memory_order_acquire или более строгим порядком является операцией захвата. Операция lock() на Mutex также является операцией захвата. Обратите внимание, что std::atomic_thread_fence накладывает более строгие требования синхронизации, чем операция захвата.

Операция освобождения

Атомарная запись с memory_order_release или более строгим порядком является операцией освобождения. Операция unlock() на Mutex также является операцией освобождения. Обратите внимание, что std::atomic_thread_fence накладывает более строгие требования синхронизации, чем операция освобождения.

Объяснение

Ослабленное упорядочение

Атомарные операции с тегом memory_order_relaxed не являются операциями синхронизации; они не накладывают порядок на параллельные обращения к памяти. Они гарантируют только атомарность и согласованность порядка модификаций.

Например, при x и y изначально равных нулю,

// Поток 1:
r1 = y.load(std::memory_order_relaxed); // A
x.store(r1, std::memory_order_relaxed); // B
// Поток 2:
r2 = x.load(std::memory_order_relaxed); // C 
y.store(42, std::memory_order_relaxed); // D

разрешено получать r1 == r2 == 42 потому что, хотя A sequenced-before B в потоке 1 и C sequenced before D в потоке 2, ничто не мешает D появиться перед A в порядке модификации y , а B появиться перед C в порядке модификации x . Побочный эффект D на y может быть видим для загрузки A в потоке 1, в то время как побочный эффект B на x может быть видим для загрузки C в потоке 2. В частности, это может произойти, если D завершается до C в потоке 2, либо из-за переупорядочивания компилятором, либо во время выполнения.

// Thread 1:
r1 = y.load(std::memory_order_relaxed);
if (r1 == 42)
    x.store(r1, std::memory_order_relaxed);
// Thread 2:
r2 = x.load(std::memory_order_relaxed);
if (r2 == 42)
    y.store(42, std::memory_order_relaxed);

Типичное использование ослабленного порядка памяти — инкрементирование счетчиков, таких как счетчики ссылок std::shared_ptr , поскольку это требует только атомарности, но не упорядочивания или синхронизации (обратите внимание, что декрементирование std::shared_ptr счетчиков требует синхронизации acquire-release с деструктором).

#include <atomic>
#include <iostream>
#include <thread>
#include <vector>
std::atomic<int> cnt = {0};
void f()
{
    for (int n = 0; n < 1000; ++n)
        cnt.fetch_add(1, std::memory_order_relaxed);
}
int main()
{
    std::vector<std::thread> v;
    for (int n = 0; n < 10; ++n)
        v.emplace_back(f);
    for (auto& t : v)
        t.join();
    std::cout << "Final counter value is " << cnt << '\n';
}

Final counter value is 10000

Упорядочение Release-Acquire

Если атомарная запись в потоке A помечена тегом memory_order_release , атомарное чтение в потоке B из той же переменной помечено тегом memory_order_acquire , и чтение в потоке B получает значение, записанное операцией записи в потоке A, тогда запись в потоке A синхронизируется-с чтением в потоке B.

Все записи в память (включая неатомарные и релаксированные атомарные), которые happened-before атомарной записи с точки зрения потока A, становятся visible side-effects в потоке B. То есть, как только атомарное чтение завершено, поток B гарантированно видит всё, что поток A записал в память. Это обещание действует только если B фактически возвращает значение, которое сохранил A, или значение из более поздней части последовательности выпуска.

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

На системах с сильной упорядоченностью — x86, SPARC TSO, мейнфреймы IBM и т.д. — упорядочение release-acquire является автоматическим для большинства операций. Для этого режима синхронизации не генерируются дополнительные инструкции процессора; затрагиваются только определенные оптимизации компилятора (например, компилятору запрещено перемещать неатомарные записи после атомарной store-release или выполнять неатомарные чтения раньше атомарной load-acquire). На системах со слабой упорядоченностью (ARM, Itanium, PowerPC) используются специальные инструкции процессора для загрузки или барьеров памяти.

Мьютексы, такие как std::mutex или атомарный спинлок , являются примером синхронизации по схеме освобождение-захват: когда блокировка освобождается потоком A и захватывается потоком B, все, что происходило в критической секции (до освобождения) в контексте потока A, должно быть видно потоку B (после захвата), который выполняет ту же критическую секцию.

#include <atomic>
#include <cassert>
#include <string>
#include <thread>
std::atomic<std::string*> ptr;
int data;
void producer()
{
    std::string* p = new std::string("Hello");
    data = 42;
    ptr.store(p, std::memory_order_release);
}
void consumer()
{
    std::string* p2;
    while (!(p2 = ptr.load(std::memory_order_acquire)))
        ;
    assert(*p2 == "Hello"); // никогда не срабатывает
    assert(data == 42); // никогда не срабатывает
}
int main()
{
    std::thread t1(producer);
    std::thread t2(consumer);
    t1.join(); t2.join();
}

#include <atomic>
#include <cassert>
#include <thread>
#include <vector>
std::vector<int> data;
std::atomic<int> flag = {0};
void thread_1()
{
    data.push_back(42);
    flag.store(1, std::memory_order_release);
}
void thread_2()
{
    int expected = 1;
    // memory_order_relaxed is okay because this is an RMW,
    // and RMWs (with any ordering) following a release form a release sequence
    while (!flag.compare_exchange_strong(expected, 2, std::memory_order_relaxed))
    {
        expected = 1;
    }
}
void thread_3()
{
    while (flag.load(std::memory_order_acquire) < 2)
        ;
    // if we read the value 2 from the atomic flag, we see 42 in the vector
    assert(data.at(0) == 42); // will never fire
}
int main()
{
    std::thread a(thread_1);
    std::thread b(thread_2);
    std::thread c(thread_3);
    a.join(); b.join(); c.join();
}

Упорядочение Release-Consume

#include <atomic>
#include <cassert>
#include <string>
#include <thread>
std::atomic<std::string*> ptr;
int data;
void producer()
{
    std::string* p = new std::string("Hello");
    data = 42;
    ptr.store(p, std::memory_order_release);
}
void consumer()
{
    std::string* p2;
    while (!(p2 = ptr.load(std::memory_order_consume)))
        ;
    assert(*p2 == "Hello"); // never fires: *p2 carries dependency from ptr
    assert(data == 42); // may or may not fire: data does not carry dependency from ptr
}
int main()
{
    std::thread t1(producer);
    std::thread t2(consumer);
    t1.join(); t2.join();
}

Последовательно-согласованное упорядочение

Атомарные операции с тегом memory_order_seq_cst не только упорядочивают память так же, как упорядочение release/acquire (все, что happened-before сохранения в одном потоке, становится видимым побочным эффектом в потоке, выполнившем загрузку), но также устанавливают единый общий порядок модификаций всех атомарных операций, помеченных этим тегом.

// Thread 1:
x.store(1, std::memory_order_seq_cst); // A
y.store(1, std::memory_order_release); // B
// Thread 2:
r1 = y.fetch_add(1, std::memory_order_seq_cst); // C
r2 = y.load(std::memory_order_relaxed); // D
// Thread 3:
y.store(3, std::memory_order_seq_cst); // E
r3 = x.load(std::memory_order_seq_cst); // F

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

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

#include <atomic>
#include <cassert>
#include <thread>
std::atomic<bool> x = {false};
std::atomic<bool> y = {false};
std::atomic<int> z = {0};
void write_x()
{
    x.store(true, std::memory_order_seq_cst);
}
void write_y()
{
    y.store(true, std::memory_order_seq_cst);
}
void read_x_then_y()
{
    while (!x.load(std::memory_order_seq_cst))
        ;
    if (y.load(std::memory_order_seq_cst))
        ++z;
}
void read_y_then_x()
{
    while (!y.load(std::memory_order_seq_cst))
        ;
    if (x.load(std::memory_order_seq_cst))
        ++z;
}
int main()
{
    std::thread a(write_x);
    std::thread b(write_y);
    std::thread c(read_x_then_y);
    std::thread d(read_y_then_x);
    a.join(); b.join(); c.join(); d.join();
    assert(z.load() != 0); // will never happen
}

Связь с volatile

В потоке выполнения обращения (чтения и записи) через volatile glvalues не могут быть переупорядочены относительно наблюдаемых побочных эффектов (включая другие volatile-обращения), которые sequenced-before или sequenced-after в том же потоке, однако этот порядок не гарантирован для наблюдения из другого потока, поскольку volatile-доступ не устанавливает межпоточную синхронизацию.

Кроме того, обращения к volatile не являются атомарными (параллельное чтение и запись представляет собой data race ) и не упорядочивают память (не-volatile обращения к памяти могут свободно переупорядочиваться вокруг volatile обращения).

Одним заметным исключением является Visual Studio, где при настройках по умолчанию каждая запись в volatile имеет семантику освобождения, а каждое чтение volatile — семантику захвата ( Microsoft Docs ), поэтому volatile может использоваться для межпоточной синхронизации. Стандартная volatile семантика не применима к многопоточному программированию, хотя её достаточно для, например, взаимодействия с обработчиком std::signal , который выполняется в том же потоке, когда применяется к переменным типа sig_atomic_t . Опция компилятора /volatile:iso может использоваться для восстановления поведения, соответствующего стандарту, что является настройкой по умолчанию при целевой платформе ARM.

Смотрите также

Внешние ссылки