「労働者が自分の仕事をうまくやりたいなら、まず自分の道具を研ぎ澄まさなければなりません。」 - 孔子、「論語。陸霊公」
表紙 > プログラミング > `std::atomic` のストアが x86 での逐次一貫性のために XCHG を使用するのはなぜですか?

`std::atomic` のストアが x86 での逐次一貫性のために XCHG を使用するのはなぜですか?

2024 年 11 月 18 日に公開
ブラウズ:173

Why does `std::atomic`\'s store use XCHG for sequential consistency on x86?

std::atomic のストアが逐次一貫性のために XCHG を採用する理由

x86 および x86_64 アーキテクチャの std::atomic のコンテキストでは、シーケンシャル一貫性のあるストア操作 (std::memory_order_seq_cst) は、シーケンシャル リリース セマンティクスを実現する手法として、メモリ バリアを備えた単純なストアの代わりに XCHG を採用します。

シーケンシャル一貫性と xchg

]

シーケンシャル一貫性は、すべてのメモリ操作が何らかのシーケンシャルな順序で実行されるように見えることを示し、この順序はすべてのスレッドで同じです。 XCHG は 2 つのオペランドの値をアトミックに交換する x86 命令であり、本質的にこの逐次一貫性要件を満たします。 XCHG を使用して書き込み操作を実行することにより、std::atomic は、実行順序の特定の時点でストアがすべてのスレッドにグローバルに表示されるようにし、後続の操作での並べ替えを防ぎます。ストア mfence と XCHG

メモリ フェンス (mfence など) が後に続く単純な mov-store は理論的にはリリース セマンティクスを提供できますが、シーケンシャル リリース ストア操作には十分ではありません。メモリ バリアを確立するメモリ フェンス命令である MFENCE は、続行する前に以前の書き込み操作がメモリにコミットされていることを確認します。ただし、後続のロード操作がリリース ストアの前に再順序付けされるのを防ぐことはできません。

パフォーマンスに関する考慮事項

順次リリース用の mov-store mfence と XCHG の選択ストア操作にはパフォーマンスのトレードオフが伴います。

特定の CPU (Intel Skylake など) では、特に同期する必要がある依存コードが周囲にない場合、XCHG は mov-store mfence より効率的です。

    他の CPU では、高スループットのシナリオや周囲のコードがアトミック操作と実行をオーバーラップできる場合には、mov-store mfence の方が望ましい場合があります。
  • 実装の詳細

実際には、逐次一貫性を備えた std::atomic ストアの具体的な実装は、コンパイラとハードウェア アーキテクチャによって異なります。

GCC/ Clang:
    元々は mov-store mfence を使用していましたが、最近 seq-cst ストアに XCHG の使用に切り替えました。
  • インテル コンパイラー:
  • seq-cst ストアに XCHG を使用します。
  • Microsoft Visual C :
  • seq-cst ストアにも XCHG を使用します。
  • Implicit Acquire Fence

x86 のステートメントストアに暗黙的な取得フェンスがあるのは正しくありません。 x86 上のストアには、取得セマンティクスではなくリリース セマンティクスがあります。取得セマンティクスは通常、mfence などのメモリ バリアや std::memory_order_acquire セマンティクスによるアトミック読み取り操作を使用して強制されます。

最新のチュートリアル もっと>

免責事項: 提供されるすべてのリソースの一部はインターネットからのものです。お客様の著作権またはその他の権利および利益の侵害がある場合は、詳細な理由を説明し、著作権または権利および利益の証拠を提出して、電子メール [email protected] に送信してください。 できるだけ早く対応させていただきます。

Copyright© 2022 湘ICP备2022001581号-3