揮発性vs.インターロックvs.ロック

クラスに、public int counter複数のスレッドによってアクセスされるフィールドがあるとしましょう。これintは、増分または減分されるだけです。

このフィールドをインクリメントするには、どのアプローチを使用する必要がありますか。その理由は何ですか。

• lock(this.locker) this.counter++;、
• Interlocked.Increment(ref this.counter);、
• のアクセス修飾子をcounterに変更しますpublic volatile。

私が発見したvolatileので、私は多くのlockステートメントとの使用を削除してきましたInterlocked。しかし、これを行わない理由はありますか？

最悪（実際には機能しない）

のアクセス修飾子counterをpublic volatile

他の人々が述べたように、これだけでは実際にはまったく安全ではありません。ポイントはvolatile、複数のCPUで実行されている複数のスレッドがデータをキャッシュし、命令を並べ替えることです。

そうでない volatile場合、CPU Aが値をインクリメントすると、CPU Bは実際にはしばらくしてからインクリメントされた値を確認できないため、問題が発生する可能性があります。

である場合volatile、これは2つのCPUが同時に同じデータを参照することを保証するだけです。それはあなたが回避しようとしている問題であるそれらの読み取りと書き込み操作をインターリーブすることを彼らにまったく止めません。

次善：

lock(this.locker) this.counter++;

これは安全です（lockアクセスする他のすべての場所を覚えている場合this.counter）。他のスレッドがによって保護されている他のコードを実行するのを防ぎますlocker。また、ロックを使用すると、マルチCPUの並べ替えの問題が上記のように防止されます。

問題は、ロックが遅いことであり、locker実際には関係のない他の場所でを再利用すると、理由もなく他のスレッドをブロックしてしまう可能性があります。

ベスト

Interlocked.Increment(ref this.counter);

これは、中断できない「1ヒット」で読み取り、増分、書き込みを効果的に行うため、安全です。このため、他のコードには影響せず、他の場所でロックすることを覚えておく必要もありません。また、非常に高速です（MSDNによると、最近のCPUでは、これは文字通り単一のCPU命令であることがよくあります）。

ただし、他のCPUが順序を変更する問題を回避できるのか、あるいはvolatileとインクリメントを組み合わせる必要があるのか​​は、完全にはわかりません。

インターロックされたメモ：

1. インターロックされたメソッドは、任意の数のコアまたはCPUで同時に安全です。
2. インターロックされたメソッドは、実行する命令の周囲に完全なフェンスを適用するため、並べ替えは発生しません。
3. インターロックされたメソッドは、揮発性フィールドへのアクセスを必要とせず、サポートもしません。

脚注：揮発性が実際に何に適しているか。

などvolatileのためにそれを何、マルチスレッドの問題のこれらの種類を防ぐことはできませんか？良い例は、2つのスレッドがあることです。1つは常に変数に書き込み（たとえばqueueLength）、もう1つは常に同じ変数から読み取ります。

queueLengthが揮発性でない場合、スレッドAは5回書き込みを行う可能性がありますが、スレッドBはそれらの書き込みが遅延している（または誤った順序である可能性さえある）と見なす場合があります。

解決策はロックすることですが、この状況ではvolatileを使用することもできます。これにより、スレッドAが書き込んだ最新のものがスレッドBに常に表示されるようになります。ただし、このロジックが機能するのは、読み取りを行わないライターと書き込みを行わないリーダーがあり、作成しているものがアトミック値である場合のみです。単一の読み取り-変更-書き込みを行うとすぐに、インターロックされた操作に移動するか、ロックを使用する必要があります。

EDIT：コメントで述べたように、これらの日、私が使用して満足しているInterlockedの例のための単一の変数、それはです明らかに大丈夫。さらに複雑になっても、ロックに戻ります...

volatileインクリメントする必要がある場合は、使用しても効果がありません。読み取りと書き込みは別々の命令であるためです。別のスレッドは、あなたが読んだ後、あなたが書き戻す前に値を変更することができます。

個人的に私はほとんど常にロックするだけです- ボラティリティやインターロックよりも明らかに正しい方法で正しい方が簡単です。私に関する限り、ロックフリーのマルチスレッド化は、実際のスレッド化の専門家のためのものです。Joe Duffyと彼のチームが、自分が構築したものと同じくらいロックせずに物事を並列化する素晴らしいライブラリを構築する場合、それは素晴らしいことです。そして、それをハートビートで使用します。複雑にしないでおく。

「volatile」は置き換えられませんInterlocked.Increment。変数がキャッシュされず、直接使用されることを確認するだけです。

変数をインクリメントするには、実際には3つの操作が必要です。

1. 読んだ
2. インクリメント
3. 書く

Interlocked.Increment 3つの部分すべてを1つのアトミック操作として実行します。

ロックまたはインターロックされた増分のいずれかが、あなたが探しているものです。

揮発性は間違いなくあなたが求めているものではありません-現在のコードパスでコンパイラがメモリからの読み取りを最適化できない場合でも、変数を常に変更するものとして扱うようコンパイラーに指示するだけです。

例えば

while (m_Var)
{ }

別のスレッドでm_Varがfalseに設定されているが、それがvolatileとして宣言されていない場合、コンパイラーは、CPUレジスター（たとえば、 m_Varのメモリの場所に別の読み取りを発行する代わりに、m_Varが最初からフェッチされたもの（これはキャッシュされる可能性があります-不明であり、気にしていません。これがx86 / x64のキャッシュ一貫性のポイントです）。命令の並べ替えについて言及した他の人による以前のすべての投稿は、単にx86 / x64アーキテクチャを理解していないことを示しています。揮発性ではありません以前の投稿で暗示されているように、「並べ替えを妨げる」と読み書きバリアを発行します。実際、MESIプロトコルのおかげで、実際の結果が物理メモリにリタイアされたか、単にローカルCPUのキャッシュに常駐しているかに関係なく、読み取った結果がCPU全体で常に同じであることが保証されます。詳細についてはあまり触れませんが、これがうまくいかない場合は、Intel / AMDがプロセッサのリコールを発行する可能性があるのでご安心ください。これはまた、順不同の実行などを気にする必要がないことも意味します。結果は常に順番にリタイアすることが保証されます-そうでなければ、詰め込まれます！

Interlocked Incrementを使用すると、プロセッサは出て行き、指定されたアドレスから値をフェッチしてからインクリメントして書き戻す必要があります。その間、キャッシュライン全体（lock xadd）の排他的所有権を持ち、他のプロセッサが変更できないようにします。その価値。

volatileを使用しても、1つの命令しか得られません（JITが効率的であると想定）-inc dword ptr [m_Var]。ただし、プロセッサ（cpuA）は、インターロックされたバージョンで行ったすべてを実行している間、キャッシュラインの排他的な所有権を要求しません。ご想像のとおり、これは、cpuAによって読み取られた後、他のプロセッサーが更新された値をm_Varに書き戻すことができることを意味します。したがって、値を2回インクリメントする代わりに、結果は1回だけになります。

これで問題が解決することを願っています。

詳細については、「マルチスレッドアプリでのローロックテクニックの影響について」-http ://msdn.microsoft.com/en-au/magazine/cc163715.aspxを参照してください。

psこの非常に遅い返信のきっかけは何ですか？すべての返信は非常に露骨に不正確であり（特に回答としてマークされたもの）、説明を他の人が読んでいる人のためにそれを明確にする必要がありました。肩をすくめる

ppsターゲットはIA64ではなくx86 / x64であると想定しています（メモリモデルが異なります）。MicrosoftのECMA仕様は、最も強いメモリモデルではなく最も弱いメモリモデルを指定するという点で台無しになっていることに注意してください（プラットフォーム間で一貫性があるように、最も強いメモリモデルに対して指定することを常にお勧めします。それ以外の場合、x86 /で24〜7で実行されるコードIntelが同様に強力なメモリモデルをIA64に実装している場合でも、x64はIA64でまったく実行されない可能性があります）-Microsoft自身もこれを認めています-http ://blogs.msdn.com/b/cbrumme/archive/2003/05/17/51445.aspx。

インターロックされた関数はロックされません。これらはアトミックです。つまり、インクリメント中にコンテキストが切り替わることなく完了することができます。したがって、デッドロックや待機の可能性はありません。

ロックとインクリメントよりも常にそれを好むべきだと私は言うでしょう。

あるスレッドでの書き込みを別のスレッドで読み取る必要があり、オプティマイザーが変数の操作を並べ替えないようにする場合（揮発性は、オプティマイザーが認識していない別のスレッドで発生しているため）に役立ちます。これは、増分方法とは正反対の選択です。

これは、ロックフリーのコードと、それを書くための適切な方法についてもっと知りたい場合、本当に良い記事です。

http://www.ddj.com/hpc-high-performance-computing/210604448

lock（...）は機能しますが、スレッドをブロックする可能性があり、他のコードが同じロックを互換性のない方法で使用している場合、デッドロックを引き起こす可能性があります。

Interlocked。*がそれを行う正しい方法です...最近のCPUがこれをプリミティブとしてサポートしているため、オーバーヘッドがはるかに少なくなります。

volatile自体は正しくありません。変更された値を取得して書き戻しようとするスレッドは、同じことをしている別のスレッドと競合する可能性があります。

理論が実際にどのように機能するかを確認するためにいくつかのテストを行いました：kennethxu.blogspot.com/2009/05/interlocked-vs-monitor-performance.html。私のテストはCompareExchnageに重点を置いていましたが、インクリメントの結果も同様です。マルチCPU環境では、インターロックは必要ありません。これは、2年前の16 CPUサーバーでのインクリメントのテスト結果です。テストには、増加後の安全な読み取りも含まれますが、これは現実の世界では一般的です。

D:\>InterlockVsMonitor.exe 16
Using 16 threads:
          InterlockAtomic.RunIncrement         (ns):   8355 Average,   8302 Minimal,   8409 Maxmial
    MonitorVolatileAtomic.RunIncrement         (ns):   7077 Average,   6843 Minimal,   7243 Maxmial

D:\>InterlockVsMonitor.exe 4
Using 4 threads:
          InterlockAtomic.RunIncrement         (ns):   4319 Average,   4319 Minimal,   4321 Maxmial
    MonitorVolatileAtomic.RunIncrement         (ns):    933 Average,    802 Minimal,   1018 Maxmial

私はJon Skeetの答えを2番目にして、 "volatile"とInterlockedについてもっと知りたいすべての人のために次のリンクを追加したいと思います。

原子性、ボラティリティ、不変性は異なる、パート1-（Eric Lippert's Fabulous Adventures In Coding）

原子性、ボラティリティ、不変性は異なります。パート2

原子性、ボラティリティ、不変性は異なる、パート3

Sayonara Volatile-（2012年に登場したJoe Duffyのウェブログのウェイバックマシンスナップショット）

私は他の回答の違いに言及したに追加したいvolatile、Interlockedとlock：

volatileキーワードは、次のタイプのフィールドに適用できます。

• 参照タイプ。
• ポインタ型（安全でないコンテキスト）。ポインタ自体は揮発性である可能性がありますが、それが指すオブジェクトは揮発性ではないことに注意してください。つまり、「ポインタ」を「揮発性」であると宣言することはできません。
• 以下のような単純型sbyte、byte、short、ushort、int、uint、char、float、とbool。
• 下記塩基のいずれかのタイプと列挙型：byte、sbyte、short、USHORT、intまたはuint。
• 参照型として知られているジェネリック型パラメーター。
• IntPtrとUIntPtr。

doubleおよびを含む他のタイプは、longそれらのタイプのフィールドへの読み取りおよび書き込みがアトミックであることが保証されていないため、「揮発性」としてマークできません。これらのタイプのフィールドへのマルチスレッドアクセスを保護するには、Interlockedクラスメンバーを使用するか、lockステートメントを使用してアクセスを保護します 。