なぜmemory_order_relaxedで確認するのにmemory_order_seq_cstを使って停止フラグを設定するのでしょうか？

memory_order_relaxed で確認するのに、memory_order_seq_cst を使用して停止フラグを設定するのはなぜですか?

ビデオで、Herb Sutter が次のことについて説明しています。メインスレッドがワーカースレッドを起動する例を含む、アトミックの使用。ワーカーは停止フラグをチェックし、メインスレッドは最終的に、memory_order_seq_cst を使用して停止フラグを true に設定します。 Sutter 氏は、スレッド停止の遅延はそれほど大きくないため、memory_order_relaxed でフラグをチェックすることは許容できると説明しています。

なぜ停止フラグがmemory_order_relaxed ではなくmemory_order_seq_cst で設定されるのかという疑問が生じます。

mo_relaxed は、停止フラグのロードとストアの両方に適しています

このシナリオでは、たとえメモリの変更を確認するレイテンシが長くても、メモリ命令を強化しても意味のあるレイテンシの利点はありません。 stop または keep_running フラグは重要でした。

ISO C 標準では、ストアが表示されるまでの時間や、それに影響を与える可能性があるものについては規定されていません。アトミック操作または同期操作によって割り当てられた最後の値が、有限期間内に他のすべてのスレッドに確実に表示されるように実装することだけが必要です。

スレッド間のレイテンシは主に実装の品質の問題です。標準では物事が大きく開かれたままになります。通常の C 実装は、通常、一部のアーキテクチャでは asm にコンパイルされ、ハードウェアのキャッシュ コヒーレンス プロパティが公開されるため、スレッド間のレイテンシが低くなります。

キャッシュ コヒーレンシを使用する実際のハードウェアでは、ストアまたはロードの異なるメモリ順序は問題になりません。リアルタイムで店舗をより早く表示できるようになります。これらは、ストアがストア バッファーから L1d キャッシュにコミットされるのを待機している間に、後の操作がグローバルに可視になるかどうかを制御します。

より強力な命令や障壁によって、絶対的な意味で物事が早く起こるわけではありません。ストアまたはロードに関連して実行が許可されるまで、他の処理を遅らせます。

ロードにmemory_order_relaxedを使用するパフォーマンスの利点

ロードにmemory_order_relaxedを使用する次のようなパフォーマンス上の利点があります。

• チェックが完了するまでの不必要な待機を回避し、ロードで false が生成された場合にループ反復全体で命令レベルおよびメモリ レベルの並列処理を増やすことができます。
• 一部のアーキテクチャでの 2-way バリア命令など、取得または SC ロードに追加の命令が必要な ISA での追加命令を回避します。

停止フラグが頻繁に設定されないこの特定のシナリオでは、無駄な命令が発生します。誤ったロードによる作業は最小限に抑えられます。したがって、memory_order_relaxed を使用するパフォーマンス上の利点は、潜在的な欠点を上回ります。

以上がなぜmemory_order_relaxedで確認するのにmemory_order_seq_cstを使って停止フラグを設定するのでしょうか？の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。