`memory_order_relaxed` でチェックされた停止フラグの設定に `memory_order_seq_cst` を使用する理由

memory_order_relaxed でチェックされている場合、停止フラグの設定にmemory_order_seq_cst を使用する理由

ハーブ・サッター氏は、「原子<>兵器」のプレゼンテーションで次のように紹介しています。アトミック変数の使用法 (シナリオを含む)関連:

• ワーカー スレッドを生成するメイン スレッド

• 停止フラグをチェックするワーカー:

  while (!stop.load(std::memory_order_relaxed))
  {
    // Perform tasks
  }

• メイン スレッドは最終的に stop を true に設定しますusingmemory_order_seq_cst.

Sutter は次のことをアサートします。フラグをチェックするためのmemory_order_relaxedは、スレッド停止遅延への影響が最小限に抑えられるため、許容されます。ただし、停止フラグの設定にmemory_order_seq_cstを採用する理由は不明のままです。

分析:

mo_relaxedは、停止フラグのロードと保存の両方に十分です:

重大な問題はありませんstop または keep_running フラグの変更を観察するレイテンシーが重要である場合でも、より強力なメモリ命令を利用することでレイテンシーの利点が得られます。

なぜ Sutter がストア操作を緩和することを推奨しないのかは不明です。ただし、ISO C 標準では、ストアの可視性のタイミングやそれに影響を与える要因については規定されていません。実装は、有限期間内の可視性を確保することのみが義務付けられています。

スレッド間レイテンシと実装:

スレッド間レイテンシは主に実装によって決まります。実際の C 実装はハードウェア キャッシュ コヒーレンス メカニズムを活用しており、通常、ストアの可視性のレイテンシが低くなります (数十ナノ秒)。

seq_cst もメモリ順序の緩和も、ストアの可視性を早めることはありません。これらは、ストアまたはロードに関連する後続の操作の動作を制御するだけです。強い順序はイベントを加速しませんが、指定された順序が維持されるまで他の操作を遅らせます。

緩和された可視性とハードウェア キャッシュ コヒーレンシー:

キャッシュ コヒーレンシーを持つ実際のハードウェアでは、メモリ注文によって店舗の可視化タイミングが向上するわけではありません。これらは、ストアコミットメントの前に後続の操作がグローバルに表示されるようにする機能のみを管理します。

停止フラグのリラックスしたメモリ順序の利点:

リラックスしたメモリ順序の主な利点停止フラグをチェックするための機能は次のとおりです。

• ロード結果が次の場合、ループ反復全体で並列性が向上します。 false。
• 特に取得または seq_cst ロードに追加の命令が必要な ISA での不要な命令実行の回避 (ARMv7 dmb など)。

結論:

このシナリオでは、memory_order_relaxed は読み込みと読み込みの両方に適しています。停止フラグを格納します。ストアの可視性のタイミングを強化するために、memory_order_seq_cst は必要ありません。代わりに、後続の操作の望ましい順序を強制し、同時書き込みの問題を回避するために使用されます。

以上が`memory_order_relaxed` でチェックされた停止フラグの設定に `memory_order_seq_cst` を使用する理由の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。