問題タブ [memory-fences]

データが使用される関数ではなく、サブ関数にメモリ フェンスを配置した場合、スレッド セーフに違いはありますか。一番下の例には、両方のバージョンが含まれています。私が気づいていない違いがあるのだろうか。関数A_functionとB_function同様にスレッドセーフですか?.

http://www.boost.org/doc/libs/1_58_0/doc/html/atomic/usage_examples.html

上記ブーストの例の「ロック パターンをダブルチェックしたシングルトン」の例では、_instance の 2 回目の読み込みに memory_order_consume と _instance のストアに memory_order_release が必要ですか? scoped_lock には既にセマンティクスの取得と解放があり、_instance の最初のロードには同期モード memory_order_consume があると思いました。

いくつかの変数 (int と double) にアクセスする 2 つのスレッド t1 と t2 があり、それらを a、b、c と呼びます。t1 は私のクリティカル パス上にあり、高価な比較交換を介してこれらの変数を増減します。

t2 はめったに発生しませんが、発生すると、上記の変数が一緒に追加されます。

現時点では、アトミックを使用しています。99.999% の確率で変数が同じスレッドからインクリメントされ、「まれなスレッド」で変数を非アトミックとして宣言できる方法はありますかa + b - c? " スレッドの書き込みが終了した店舗はありますか?

これにより、まれなスレッドが実行されるまれな状況でのみレイテンシを追加できます。

基本的に私は次のような状況にあります：

別のスレッドは次のようなことを行うことができます:

「Obj」のようなオブジェクトは 1 回だけ書き込まれ、その後複数のスレッドによって (複数回) 読み取られます。

Obj が両方のスレッドで null になることはありません。「this.Obj」の同期も気にしません。私が気にかけているのは、参照を読んだらtmp = Obj、その内容 (たとえばAとB) も有効であるということです。

私の質問は次Thread.MemoryBarrier();のとおりです。上記のマークされた位置にメモリバリア（例：）が必要ですか、それとも常に暗黙的にOKですか？

人々はこの質問を嫌うようです。

私の質問は以下から来ています。私はメモリフェンスについて調べましたが、彼らは次のことを保証しています：（引用）

現在のスレッドを実行しているプロセッサは、MemoryBarrier の呼び出し前のメモリ アクセスが、MemoryBarrier の呼び出しに続くメモリ アクセスの後に実行されるように命令を並べ替えることができません。

コードを見ると、CPU / コンパイラがコードを書き直すことができる可能性があります。

さらに悪いことに：

別のスレッドが最後のケースを取得した場合、this.Objメモリから読み取ることができますがA、Bデフォルト値は保持されます。

コンパイラが何を並べ替えることができるかだけの問題ではないことに注意してください。また、CPU が何を並べ替えることができるかの問題でもあります。

言い換えれば：（ありがとう@MattBurland）

tmp1 が割り当てられる前にオブジェクト初期化子が実行されることが保証されていますthis.Objか? または、メモリフェンスを使用してこれを手動で確認する必要がありますか?

atomic_uintmemory_order_relaxed を使用した an の値の読み取りと、a の値の読み取りvolatile unsigned int(揮発性操作がアトミックであると仮定)の違いは何ですか?

具体的には、次のように定義しましょう。

解決策 1

1. 「ライター」スレッドはatomic_uint(memory_order_relaxed から memory_order_seq_cst までの任意のメモリ順序修飾子を使用して) に書き込みます。
2. 「リーダー」スレッドは、同じ上でアトミックなリラックスした読み取りを行いますatomic_uint

解決策 2

1. 「ライター」スレッドは、volatile unsigned int
2. 「リーダー」スレッドはその値を読み取ります

現状では、どちらの場合も、ライターによって書き込まれた値をリーダーが読み取る能力に関して何の保証も提供しないことを私は知っています。私が理解しようとしているのは、揮発性読み取りとリラックスしたアトミック読み取りの違いです。書き込み後の読み取りの一貫性を考慮するとき、一方が提供し、他方が提供しないものは何ですか?

私が見る唯一の違いは次のとおりです。

• 揮発性操作はそれらの間で並べ替えることはできませんが、アトミックロードは他のアトミック操作で並べ替えることができます

他に何かありますか？

シングルトン パターンを含まない DCL に関する議論を見つけるために、しばらくの間インターウェブを検索してきました。その代わりに、私が知りたいことを正確に尋ねるつもりです。

ここで DCL は適切ですか?

*mybool_smart_ptrロックフリーでこれを行うすべてのライター。生成されたスレッドが行う作業は、オール オア ナッシングです。それがスレッドの待ち受けです。

私は持っていstd::atomic<int>* key, *valます;

両方書きたい。これらの値を同時に読み取る複数のスレッドがあります。val が key の前に書き込まれるようにしたい。つまり、読者が key の新しい値を確認した場合、val の新しい値も確認する必要があります。古いキーで新しい val を確認することも、古い値の両方を確認することも問題ありません。コードは、緩和されたプロセッサ アーキテクチャ (ARM) で動作する必要があります。

通常は (in-order) を実行して (in-order)val->store(x, relaxed), key->store(y, release)でロードするだけで十分key->load(acquire), val-load(relaxed)です。ARM では、取得はロード バリアを挿入し、リリースはストア バリアを挿入すると考えています。ただし、さまざまな理由から、val の読み取りにアトミックを使用していません。すべての読み取りアクセスでバリアを使用するとコストがかかりすぎます。

2 つのストア間でストア バリア (x86 のフェンス) だけを使用して順序を強制することはできますか? key と val の古い値が表示されてもまったく問題ありません。確実にしたいのは、キーの新しい値が別のコアによって認識された場合、val の新しい値も認識される必要があることだけです。リーダーは常にキーを最初に読み取り、val の読み取りはキーの値に依存します (メモリ アドレスであっても)。キーの前に読みます。val を探す場所を知るために、key を読み取る必要があります。コードが負荷バリアなしで動作できるようにするのは、このプロパティだと思います。

私は正しいですか？

x86-64 では、クリティカル セクションに単純なスピンロックを使用します。

cs を終了するには:

クリティカル セクション内のストア操作がフラッシュされるように、ロックを解除する前にフェンス命令が必要ですか?