問題タブ [stdatomic]

memory_order_release緩和されたアトミック操作 (特にandmemory_order_acquireだけでなくmemory_order_consumeand memory_order_relaxed) とデフォルトのを使用した C11/C++11 コードのパフォーマンスを比較するベンチマーク結果を指摘できる人はいますmemory_order_seq_cstか? すべてのアーキテクチャが対象です。前もって感謝します。

私は何をするのかを尋ねる質問 (このようなもの) を見つけました[[carries_dependency]]が、それは私がここで尋ねていることではありません。

私が読んだすべての回答は、このコードをどこにでも貼り付けることができ、魔法のように同等またはより高速なコードを取得できるように聞こえるため、いつ使用してはならないかを知りたいです。コメントの 1 つは、コードは同等または遅くなる可能性があると述べましたが、投稿者は詳しく説明しませんでした。

これを使用する適切な場所は、ポインターまたは参照であり、呼び出し元のスレッド内で渡されるか返される関数の戻り値またはパラメーターであると思います。コールバックまたはスレッドのエントリポイントでは使用しないでください。

誰かが私の理解についてコメントし、一般的に、それをいつ、いつ使用しないかについて詳しく説明できますか?

編集：他の読者が興味を持っている場合、この主題に関する本があることを私は知っています。私の答えが含まれているかもしれませんが、まだ読む機会がありません。

C++11 アトミック ライブラリを使用して seqlock を作成したいと考えています。stackoverflow の seqlock に関するいくつかの質問を読みましたが、誰も助けてくれませんでした。私が使用するアルゴリズムは一般的で、どこにでもあります。それが私のコードです。

B と C で memory_order タグを正しく使用していることを確認します。

AとDでは正しくないと思います。

保護されたデータの読み取りと書き込みを同時に行うことを考えてみてください。D のフラグの読み取り値が古すぎて、write_lock() によって書き込まれた最新の値を読み取っていないのではないかと心配しています。しかし、保護されたデータの最新の値を読み取ります。書き込みスレッドによって書き込まれます (x86 システムでは発生しない可能性がありますが、コードが x86 で実行されているとは想定していません)。読み取りスレッドが保護されたデータの読み取りを終了した後、フラグの読み取り値が古すぎるため、シーケンスが増加したことがわかりません。読み取りスレッドがループから抜け出し、バグが発生します。

(1)で保護されたデータの読み取り値は(4)で書き込まれ、(2)で読み取られたフラグの値は(3)で書き込まれません(前回書き込みロックを解除したときに書き込まれます)。バグがあると思う理由。

しかし、これを修正する方法が本当にわかりません。read_leavee() と write_locke() の間に「同期」関係を作ろうとしました (「read_leave() を write_locke() と同期させたい」)。しかし、ストアはありません。アクションは read_leave() で、失敗しました。

(ああ、C++ の標準仕様は難しすぎて理解できません。私が英語圏ではないことも一因です。)

新しく導入されたスレッド同期プリミティブを使用して緩和されたメモリ順序を利用する C++11 コードを記述する場合、通常、次のいずれかが表示されます。

また

なぜこれが理にかなっているのかは私には明らかです。

私の質問は次のとおりです。組み合わせも意味がvv.store(42, std::memory_order_acquire)ありますか? vv.load(std::memory_order_release)どのような状況でそれらを使用できますか? これらの組み合わせのセマンティクスは何ですか?

私は現在、OpenMP の使用法を学ぼうとしていますが、質問があります。そのようなことをしても安全ですか：

または、使用しますか：

ありがとう ！

編集：配列を使用することを処理する最も簡単な方法を知っていますが、興味があるので尋ねています

何かが発生した回数をカウントする次のコードがあるとします。

現状では、i に明確な競合状態があります。C++11 を使用して、(1) この競合状態を解消するための最も簡単な方法と、(2) できればミューテックスを使用しない最速の方法は何ですか? ありがとう。

更新: アトミックを使用するコメントを使用して、Intel Compiler バージョン 13 でコンパイルされる作業プログラムを取得しました。

私の理解では、アトミック マシン命令は、非アトミック操作より最大 2 桁遅くなる可能性があります。たとえば、与えられた

と

私の理解では、x++通常、よりもはるかに高速に実行されy++ます。(インクリメント操作は基礎となるマシン命令にマップすると仮定しています。正確な比較コストはアーキテクチャごとに異なると確信していますが、経験則について話しています。)

一般的な経験則として、アトミック RMW 操作と非インライン関数呼び出しの相対的なコストに関心があります。たとえば、次の非インライン関数が与えられた場合、

y++への非インライン呼び出しを実行するコストと比較して、のコスト (つまり、アトミック インクリメント)について一般的に言えることは何fですか?

私の動機は、「アトミック操作は非アトミック操作よりもはるかにコストがかかる」という一般的な主張を大局的に捉えようとすることです。そのための 1 つの方法は、アトミックな RMW 操作が非インライン関数の呼び出しと戻りに比べてどれだけコストがかかるかを把握することです。

「知る唯一の方法は測定することです」と返信しないでください。特定のアーキテクチャの特定のコンテキストでのアトミック RMW 操作と関数呼び出しについて質問しているわけではありません。私は、「アトミック命令は高価すぎるので決して使用できない」と考えるかもしれないが、作成することについて二度考えない人々のための議論の基礎として使用できる一般的な経験則について尋ねています。関数呼び出し。

さまざまなロックフリー アルゴリズムには、高速パスでのロードまたはストアの順序付け要件がありません。たとえば、この仕事を盗むhttp://www.cs.rice.edu/~vs3/PDF/ppopp.09/p45-michael.pdfでは、盗む操作にはアトミックな比較と交換が必要ですが、頻繁な操作は(put and take) は特に、順序の制約がまったく必要ないように設計されています。私は他の多くのケースでこの種のパターンに出くわしました。

では、メモリの制約を強制せずに std アトミック変数にアクセスする方法がないのはなぜでしょうか? x-86(-64) では、memory_order_relaxed は CPU バリア命令を挿入しませんが、(少なくとも Visual C++ 2012 の実装で確認できることから) コンパイラの並べ替えを防ぎますが、それでも確実にパフォーマンスが低下します。実際、メモリの順序は実行時のパラメーターであるため、分岐が発生するというペナルティもあります。組み合わせて、それは事態をさらに悪化させます。次の Visual C++ 2012 実装のコードは、switch ステートメントが memory_order_relaxed であると判断した後に、uint32_t 値を atomic_uint32_t に格納します (xatomic.h を参照)。

そこからの memory_order_relaxed を使用したロードは、最終的に実行されます

_InterlockedOr 組み込みが完全な CPU バリア (xatomic.h) であるため、これはさらに悪いことです。

したがって、1) 非メモリ順序付けアクセスが std API の一部ではない理由、および 2) 独自のアトミック API をローリングする以外の回避策は何か、アトミック クラスの醜い reinterpret_cast を非アトミック型に変更し、 sizeof と offsetof のコンパイル時のチェックを行っていますか?

(私がターゲットとするアーキテクチャー上で通常のロードとストアがすでにアトミックである整数型に関心があるため、アトミック アクセスと非アトミック アクセスを混在させることについて話しているわけではないことに注意してください。)