問題タブ [memory-fences]

C11* アトミックを使用して、いくつかのスレッド間で状態列挙を管理しています。コードは次のようになります。

これは (ARM Cortex-M4 の場合) 次のようにアセンブルします。

リリース前と取得後にフェンスが配置されるのはなぜですか? 私のメンタル モデルでは、リリースの後(格納されている変数と他のすべてのストアを他のスレッドに "伝達" するため)、および取得の前(他のスレッドから以前のすべてのストアを受け取るため) にバリアが配置されると想定していました。

*この特定の例は C11 で示されていますが、C++11 でも状況は同じです。メモリの順序付けに関しては、2 つが同じ概念 (さらには同じ列挙型) を共有しているためです。この状況で同じマシンコードを発行しますgcc。http://en.cppreference.com/w/c/atomic/memory_orderおよびhttp://en.cppreference.com/w/cpp/atomic/memory_orderg++を参照してください。

2 つの質問があります。1 つは共有データを変更し、もう 1 つは共有データを操作する 2 つのスレッドについて考えてみましょう。どちらのスレッドも、データを処理する前にミューテックスを取得します。

データを操作するスレッドが、最初のスレッドによって行われた変更を常に確認できるようにするにはどうすればよいですか? 一連の取得/解放フェンスが必要ですか、それともミューテックスを使用してスレッドを暗黙的に同期しますか? ミューテックスを使用しない場合 (ただし、排他的アクセスを保証する場合) はどうなりますか?

そして：フェンスは、インターリーブ/フォローアップのアトミック操作なしで実際に何かをしますか（atomic_boolにフラグを格納する、「準備完了」などを通知するなど）？

ユースケースは次のとおりです。

フェンスが実際にコードの同期を強制する方法を理解するのに苦労しています。

たとえば、このコードがあるとします

リリース フェンスの後にアトミック ストア操作が続き、取得フェンスの前にアトミック ロードがあるため、すべてが想定どおりに同期され、アサートは発生しません。

しかし、yがこのようなアトミック変数ではなかった場合

その場合、データ競合が発生する可能性があると聞きました。しかし、それはなぜですか？コードを適切に同期させるために、リリース フェンスの後にアトミック ストアが続き、取得フェンスの前にアトミック ロードが必要なのはなぜですか?

また、データ競合によってアサートが発生する実行シナリオを誰かが提供できれば幸いです

を使用せずに完全なメモリ フェンスをトリガーすることに興味がありsun.misc.Unsafeます。

次の Java コードはフル メモリ フェンスをトリガーしますか?

次の Java コードもフル メモリ フェンスをトリガーしますか?

• 参照: Java 8 Unsafe: xxxFence() 命令
• 参照: http://openjdk.java.net/jeps/171

OpenMP 仕様 (v4.0) によると、次のプログラムには、非同期の読み取り/書き込みによるデータ競合の可能性が含まれていますi。

私の頭に浮かんだ可能な解決策は、コメントとしてコードに示されています。

1. の書き込みと読み取りを保護するにiは#pragma omp atomic write/read、
2. の書き込みと読み取りを保護するにiは#pragma omp atomic write/read seq_cst、
3. のタイプとしてのstd::atomic<int>代わりに使用します。inti

x86_64 でコンパイラが生成した命令を次に示します (-O2すべての場合)。

#pragma omp atomic私が疑問に思っているのは、GNU/clang コンパイラが書き込み用の特別な命令を生成しない理由です。と同様の指示std::atomic、つまり または のいずれかMOV+MFENCEを期待しますXCHG。説明はありますか？

アップデート

g++ 5.3.0 はMFENCEfor を生成し#pragma omp atomic write seq_cstます。それが正しい振る舞いだと私は信じています。がなければ、非 SC 原子性には十分なseq_cstplain が生成されます。MOV

私の Makefile にはバグがあり、g++ 4.9.2 はMFENCECS アトミック書き込み用にも生成されます。申し訳ありません。

Clang 3.5.0 は OpenMP SC アトミックを実装していません。これを指摘してくれた Hristo Iliev に感謝します。

これが新しい問題ではないことはわかっていますが、C++11 メモリ フェンスについて読んだ後、混乱しました。

1 つのリーダー スレッドと 1 つのライター スレッドがあるとします。
普通に使えますintか？

この動作は未定義ですか?
リーダー スレッドで未定義の値を取得できますか? または、 or ?
を使用するようなものです。したがって、値は最終的にリーダースレッドに到達します。std::atomic_uint_fast32_tstd::atomic<int>

答えは使用しているプラ​​ットフォームによって異なりますか? （たとえばx86）、通常のロード/ストアintは1つのCPU命令ですか？

両方の動作が似ている場合、両方のタイプで同じパフォーマンスを期待できますか?

C# に次のコードがあるとします。

MemoryBarriers書き込み命令が読み取りの前に行われることを確認してください。ただし、あるスレッドの書き込みが他のスレッドの読み取りによって認識されることが保証されていますか? 言い換えれば、少なくとも 1 つのスレッドが印刷される、1または両方のスレッドが印刷されることが保証されているの0でしょうか?

thisやthisのように、「鮮度」やMemoryBarrierC# に関連するいくつかの質問が既に存在することを知っています。ただし、それらのほとんどは、書き込み解放および読み取り取得パターンを扱っています。この質問に投稿されたコードは、命令が順番に保持されているという事実に加えて、読み取りによって書き込みが表示されることが保証されているかどうかに非常に固有のものです。