std:: memory_order

std::memory_order は、アトミック操作を中心としたメモリアクセス（通常の非アトミックメモリアクセスを含む）の順序付け方法を指定します。マルチコアシステムにおいて制約がない場合、複数のスレッドが同時に複数の変数を読み書きすると、あるスレッドが値の変更を別のスレッドが書き込んだ順序とは異なる順序で観測することがあります。実際、変更の見かけ上の順序は複数のリーダースレッド間でも異なる可能性があります。メモリモデルによって許可されるコンパイラ変換により、ユニプロセッサシステムでも同様の効果が発生することがあります。

C++標準ライブラリにおける全てのアトミック操作のデフォルト動作は、 逐次一貫性順序 を提供します（以下の議論を参照）。このデフォルト設定はパフォーマンスに悪影響を及ぼす可能性がありますが、ライブラリのアトミック操作には追加の std::memory_order 引数を指定することで、原子性を超えた正確な制約をコンパイラとプロセッサに強制させることができます。

定数

形式的記述

スレッド間同期とメモリ順序付けは、異なる実行スレッド間で式の 評価 と 副作用 がどのように順序付けられるかを決定します。これらは以下の用語で定義されます：

シーケンス前に

同一スレッド内では、評価Aが評価Bに対して sequenced-before の関係を持つ場合があり、これは evaluation order で説明されています。

変更順序

特定のアトミック変数に対するすべての変更は、そのアトミック変数に固有の全順序で発生します。

以下の4つの要件は、すべてのアトミック操作に対して保証されています：

解放シーケンス

アトミックオブジェクト M に対して release operation A が実行された後、M の modification order の中で最も長い連続部分列であり、以下から構成されるもの：

Aによって先頭とされるリリースシーケンス として知られています。

同期対象

スレッドAにおけるアトミックストアが release操作 であり、スレッドBにおける同じ変数からのアトミックロードが acquire操作 であり、かつスレッドBのロードがスレッドAのストアによって書き込まれた値を読み取る場合、スレッドAのストアはスレッドBのロードと synchronizes-with の関係が成立します。

また、一部のライブラリ呼び出しは、他のスレッド上の別のライブラリ呼び出しと synchronize-with 関係を持つように定義されている場合があります。

スレッド間 happens-before

スレッド間では、以下のいずれかが真である場合、評価Aは inter-thread happens before 評価Bとなります：

強く発生する順序 (Strongly happens-before)

スレッドに関係なく、以下のいずれかが真である場合、評価Aは評価Bに対して strongly happens-before します：

可視副作用

スカラーMに対する副作用A（書き込み）は、以下の両方が真である場合、Mに対する値計算B（読み取り）に関して 可視 である：

副作用Aが値計算Bに対して可視である場合、Mに対する副作用の最長連続部分集合で、 変更順序 においてBがそれに 先行発生 しないものは、 可視副作用列 として知られる（Bによって決定されるMの値は、これらの副作用のいずれかによって格納された値となる）。

注意: スレッド間同期は、データ競合の防止（happens-before関係の確立による）と、どの副作用がどの条件下で可視化されるかを定義することに帰着します。

Consume操作

memory_order_consume またはそれより強いメモリ順序でのアトミックロードはコンシューム操作です。 std::atomic_thread_fence はコンシューム操作よりも強い同期要件を課すことに注意してください。

Acquire操作

memory_order_acquire またはそれ以上のメモリ順序を持つアトミックロードはacquire操作です。 Mutex に対する lock() 操作もacquire操作です。 std::atomic_thread_fence はacquire操作よりも強い同期要件を課すことに注意してください。

リリース操作

memory_order_release またはそれ以上のメモリ順序を持つアトミックストアはリリース操作です。 Mutex の unlock() 操作もリリース操作です。 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 が生成されることが許容されます。なぜなら、スレッド1内ではAがBより sequenced-before であり、スレッド2内ではCがDより sequenced before であるものの、 y の変更順序においてDがAより前に現れることや、 x の変更順序においてBがCより前に現れることを妨げるものは何もないからです。スレッド1のロードAに対して y へのDの副作用が見える可能性があり、同時にスレッド2のロードCに対して x へのBの副作用が見える可能性があります。特に、コンパイラのリオーダリングまたは実行時において、スレッド2でDがCより先に完了する場合にこれが発生し得ます。

// 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のロードと synchronizes-with 関係を確立します。

スレッドAの観点からアトミックストアの前に発生したすべてのメモリ書き込み（非アトミックおよび緩和アトミックを含む）は、 happened-before 関係により、スレッドBにおいて visible side-effects となります。つまり、アトミックロードが完了すると、スレッドBはスレッドAがメモリに書き込んだすべての内容を確実に認識します。この保証は、Bが実際にAが格納した値、またはリリースシーケンスでそれ以降の値を返す場合にのみ有効です。

同期は、同じアトミック変数を releasing するスレッドと acquiring するスレッドの間でのみ確立されます。他のスレッドは、同期されたスレッドの一方または両方とは異なるメモリアクセスの順序を観測する可能性があります。

強く順序付けられたシステム（x86、SPARC TSO、IBMメインフレームなど）では、リリース-取得順序付けはほとんどの操作で自動的に行われます。この同期モードでは追加のCPU命令は発行されず、特定のコンパイラ最適化のみが影響を受けます（例えば、コンパイラは非アトミックストアをアトミックストア-リリースを超えて移動したり、非アトミックロードをアトミックロード-取得より早く実行したりすることが禁止されます）。弱く順序付けられたシステム（ARM、Itanium、PowerPC）では、特別なCPUロードまたはメモリフェンス命令が使用されます。

相互排他ロック、例えば std::mutex や atomic spinlock は、release-acquire同期の一例です：スレッド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"); // never fires
    assert(data == 42); // never fires
}
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 でタグ付けされたアトミック操作は、リリース/アクquire順序と同じ方法でメモリを順序付けるだけでなく（1つのスレッドでストアの前に発生したすべてのことが、ロードを行ったスレッドで可視的な副作用となる）、このようにタグ付けされたすべてのアトミック操作の単一の全順序変更順序を確立します。

// 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

シーケンシャルな順序付けは、すべてのコンシューマがすべてのプロデューサのアクションを同じ順序で観測する必要がある、マルチプロデューサ-マルチコンシューマの状況で必要となる場合があります。

トータル・シーケンシャル・オーダリングは、すべてのマルチコアシステムにおいて完全なメモリフェンスCPU命令を必要とします。これは、影響を受けるメモリアクセスがすべてのコアに伝搬することを強制するため、パフォーマンスのボトルネックとなる可能性があります。

#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 を通じたアクセス（読み書き）は、同じスレッド内で sequenced-before または sequenced-after の関係にある観測可能な副作用（他のvolatileアクセスを含む）を越えて並べ替えることはできません。しかし、この順序は他のスレッドから観測されることが保証されていません。なぜならvolatileアクセスはスレッド間同期を確立しないからです。

さらに、volatileアクセスはアトミックではありません（同時読み書きは data race となります）また、メモリ順序を保証しません（非volatileメモリアクセスはvolatileアクセスの周りで自由に並べ替えられる可能性があります）。

注目すべき例外はVisual Studioであり、デフォルト設定では、すべてのvolatile書き込みはリリースセマンティクスを持ち、すべてのvolatile読み取りはアクワイアセマンティクスを持ちます（ Microsoft Docs ）。したがって、volatileはスレッド間同期に使用される可能性があります。標準的な volatile セマンティクスはマルチスレッドプログラミングには適用できませんが、同じスレッドで実行される std::signal ハンドラとの通信などには十分です（ sig_atomic_t 変数に適用される場合）。コンパイラオプション /volatile:iso を使用して標準に準拠した動作を復元することができ、これはターゲットプラットフォームがARMの場合のデフォルト設定です。

関連項目

外部リンク