Anthony Williams は、著書「C++ Concurrency in Action」の中で次のように書いています (309 ページ)。
たとえば、x86 および x86-64 アーキテクチャでは、タグ付けされた memory_order_relaxed または memory_order_seq_cst に関係なく、アトミック ロード操作は常に同じです (セクション 5.3.3 を参照)。つまり、緩和されたメモリー順序付けを使用して記述されたコードは、x86 アーキテクチャーのシステムでは機能する可能性がありますが、SPARC などのより粒度の細かいメモリー順序付け命令セットを使用するシステムでは失敗します。
x86 アーキテクチャではすべてのアトミック ロード操作がmemory_order_seq_cst. さらに、cppreference std::memory_orderサイトでは、x86 では release-aquire の順序付けが自動であると記載されています。
この制限が有効な場合、順序付けはコンパイラの最適化に適用されますか?
もちろん、コンパイラは、実行するハードウェアが何であれ、言語の規則に従わなければなりません。
彼が言っているのは、x86 では順序付けが緩和されていないため、要求しなくてもより厳密な順序付けが行われるということです。これは、x86 でテストされたコードが、順序付けが緩和されたシステムでは正しく機能しない可能性があることも意味します。
x86 では、ロード リラックスと seq_cst ロードが同じ命令にマップされる場合がありますが、それらは同じではないことに注意してください。緩和されたロードは、メモリ操作全体でコンパイラによって自由に並べ替えられ、異なるメモリ位置に移動できますが、seq_cst ロードは、他のメモリ操作全体で並べ替えられません。
x86 アーキテクチャではすべてのアトミック ロード操作が
memory_order_seq_cst.
(プログラムの、プログラム内の一部のスレッド間可視操作の) 実行のみを順次実行できます。単一の操作は、それ自体が連続したものではありません。
単一の分離された操作の実装がシーケンシャルかどうかを尋ねることは、無意味な質問です。
何らかの保証を必要とするすべてのメモリ操作の変換は、その保証を可能にする戦略に従って行う必要があります。さまざまなコンパイラの複雑さのコストとランタイム コストを持つさまざまな戦略が存在する可能性があります。
[仮想関数を実装するためのさまざまな戦略があるということです: 唯一問題ない (速度、予測可能性、および単純さに対するすべての期待に適合する) のは、vtable の使用です。そのため、すべてのコンパイラは vtable を使用しますが、仮想関数は定義されていません。 vtableを通過するように。]
実際には、特定の CPU (私が知っている) で操作を実装するために使用される、大きく異なる戦略はありません。コンパイラ間の違いは小さく、バイナリ互換性を妨げません。しかし、潜在的な違いがあり、マルチスレッド プログラムの高度なグローバル最適化により、アトミック操作のためのより効率的なコード生成の新しい機会が開かれる可能性があります。memory_order_seq_cst
memory_order_seq_cstコンパイラによっては、オブジェクトの緩和されたロードと変更のみを含むプログラムはstd::atomic<>、厳密に順序付けされた CPU であっても、シーケンシャルな動作のみを示す場合と示さない場合があります。