.NETのメモリバリアと非ブロッキング同期

はじめに

この記事では、非ブロッキング同期の実装に使用されるいくつかの設計の使用についてお話したいと思います。 volatileキーワード、VolatileRead、VolatileWrite、およびMemoryBarrier関数について説明します。 これらの言語構成要素とその解決策を使用せざるを得ない問題を検討します。 メモリバリアについて説明する際に、.NETメモリモデルについて簡単に確認します。

コンパイラーによって導入された最適化

ノンブロッキング同期を使用するときにプログラマーが遭遇する主な問題は、コンパイラーの最適化と命令のプロセッサー順列です。
コンパイラーがマルチスレッドプログラムに問題を導入する例を見てみましょう。

class ReorderTest { private int _a; public void Foo() { var task = new Task(Bar); task.Start(); Thread.Sleep(1000); _a = 0; task.Wait(); } public void Bar() { _a = 1; while (_a == 1) { } } } 

この例を実行すると、プログラムがフリーズすることを確認できます。 その理由は、コンパイラがプロセッサレジスタに_a変数をキャッシュするためです。
このような問題を解決するために、C＃はvolatileキーワードを提供しています。 このキーワードを変数に適用すると、コンパイラは何らかの方法で変数へのアクセスを最適化できなくなります。

これは、改訂された_a変数宣言の外観です。

 private volatile int _a; 

このキーワードを使用することの効果は、コンパイラの最適化を無効にすることだけではありません。 他の効果については後で説明します。

命令を並べ替える

問題の原因がプロセッサによる命令の再配置である場合を考えてみましょう。
次のコードがあるとします。

 class ReorderTest2 { private int _a; private int _b; public void Foo() { _a = 1; _b = 1; } public void Bar() { if (_b == 1) { Console.WriteLine(_a); } } } 

FooルーチンとBarルーチンは、異なるスレッドから同時に実行されます。
このコードは正しいですか、つまり、プログラムがゼロを出力しないと自信を持って言えますか？ シングルスレッドのプログラムについて話している場合、このコードを確認するには一度実行するだけで十分です。 しかし、マルチスレッドを扱っているため、これだけでは十分ではありません。 代わりに、プログラムが正しく動作することを保証しているかどうかを理解する必要があります。

.NETメモリモデル

既に述べたように、マルチスレッドプログラムの不適切な動作は、プロセッサ上の命令の並べ替えによって発生する可能性があります。 この問題をさらに詳しく考えてみましょう。
最新のプロセッサは、最適化のためにメモリの読み取りおよび書き込み命令を再配置できます。 これを例で説明します。

 int a = _a; _b = 10; 

このコードでは、変数_aが最初に読み取られ、次に_bが書き込まれます。 ただし、このプログラムを実行すると、プロセッサは読み取りおよび書き込み命令を再配置できます。つまり、変数_bが最初に書き込まれ、その後でのみ_aが読み取られます。 シングルスレッドプログラムの場合、この順列は重要ではありませんが、マルチスレッドプログラムの場合、これは問題になります。 これで、順列ダウンロード-レコードを調べました。 他の命令の組み合わせでも同様の順列が可能です。

このような命令の順列規則のセットは、メモリモデルと呼ばれます。 .NETプラットフォームには独自のメモリモデルがあり、特定のプロセッサのメモリモデルから私たちを抽象化します。
これは、.NETメモリモデルの外観です。

順列タイプ	許可された順列
ダウンロード-ダウンロード	はい
レコードをダウンロード	はい
録音ダウンロード	はい
レコード	いや

.NETメモリモデルの観点から例を検討することができます。 順列の書き込み/書き込みが禁止されているため、変数_aへの書き込みは常に変数_bへの書き込みの前に行われ、ここでプログラムは正しく動作します。 問題は、Barプロシージャにあります。 読み取り命令のスワップは禁止されていないため、_aの前に_b変数を読み取ることができます。
置換後、コードは次のように記述されているかのように実行されます。

 var tmp = _a; if (_b == 1) { Console.WriteLine(tmp); } 

命令の順列について話すとき、異なる変数を読み書きする1つのスレッドからの命令の順列を意味します。 異なるスレッドで同じ変数にレコードがある場合、それらの順序はいずれにしてもランダムです。 そして、たとえば次のように、同じ変数の読み取りと書き込みについて話している場合：

 var a = GetA(); UseA(a); 

そして、もちろん、ここでは順列はあり得ない。

記憶の障壁

この問題を解決するには、普遍的な方法-メモリバリア（メモリバリア）を追加します。
メモリバリアには、フル、リリースフェンス、アキュアフェンスのタイプがあります。
完全なバリアは、バリアの前後にあるすべての読み取りと書き込みがバリアの前後で同じように実行されることを保証します。つまり、メモリアクセス命令がバリアを飛び越えることはできません。
次に、他の2つのタイプのバリアを扱います。
Accureフェンスは、バリアに続く指示がバリアの前の位置に移動しないようにします。
リリースフェンスは、バリアの前の指示がバリアの後の位置に移動しないようにします。
用語に関するいくつかの言葉。 揮発性書き込みという用語は、リリースフェンスの作成と併せてメモリに書き込むことを意味します。 揮発性読み取りという用語は、アキュアフェンスの作成と併せてメモリを読み取ることを意味します。

.NETは、メモリバリアを操作するために次のメソッドを提供します。

• Thread.MemoryBarrier（）メソッドは完全なメモリバリアを作成します
• volatileキーワードは、この単語でマークされた変数のすべての操作を、それぞれvolatile書き込みまたはvolatile読み取りに変換します。
• Thread.VolatileRead（）メソッドは揮発性読み取りを実行します
• メソッドThread.VolatileWrite（）は、揮発性書き込みを実行します

例に戻りましょう。 すでに理解したように、読み取り命令の順列により問題が発生する場合があります。 これを解決するには、読み取り_aと_bの間にメモリバリアを追加します。 その後、Barメソッドが実行されるスレッドがエントリを正しい順序で見ることが保証されます。

 class ReorderTest2 { private int _a; private int _b; public void Foo() { _a = 1; _b = 1; } public void Bar() { if (_a == 1) { Thread.MemoryBarrier(); Console.WriteLine(_b); } } } 

ここでは、完全なメモリバリアを使用することは冗長です。 読み取り命令の順列を排除するには、_aを読み取るときにvolatile readを使用するだけで十分です。 これは、Thread.VolatileReadメソッドまたはvolatileキーワードを使用して実現できます。

Thread.VolatileWriteおよびThread.VolatileReadメソッド

Thread.VolatileWriteメソッドとThread.VolatileReadメソッドを詳しく見てみましょう。
VolatileWriteに関するMSDNには、「値をフィールドに直接書き込むため、コンピューターのすべてのプロセッサから見えるようになります」と記述されています。
実際、この説明は完全に正しいわけではありません。 これらのメソッドは2つのことを保証します。コンパイラ^1の最適化と、揮発性の読み取りまたは書き込みプロパティによる命令の並べ替えはありません。 厳密に言えば、VolatileWriteメソッドは、値が他のプロセッサーからすぐに見えることを保証しません。また、VolatileReadメソッドは、値がキャッシュ²から読み取られないことを保証しません。 ただし、コンパイラによるコードの最適化の欠如とプロセッサキャッシュの一貫性のため、MSDNの説明が正しいと仮定できます。

これらのメソッドの実装方法を検討してください。

 [MethodImpl(MethodImplOptions.NoInlining)] public static int VolatileRead(ref int address) { int num = address; Thread.MemoryBarrier(); return num; } [MethodImpl(MethodImplOptions.NoInlining)] public static void VolatileWrite(ref int address, int value) { Thread.MemoryBarrier(); address = value; } 

ここで他に面白いものは何ですか？
まず、完全なメモリバリアを使用します。 先ほど言ったように、volatile書き込みはリリースフェンスを作成する必要があります。 リリースフェンスは完全なバリアの特殊なケースであるため、この実装は正しいが冗長です。 ここにリリースフェンスがインストールされている場合、プロセッサ/コンパイラは最適化の機会が増えます。 .NET開発チームが完全な障壁を介してこれらの機能を実装した理由を説明するのは困難です。 ただし、これらは現在の実装の詳細にすぎず、将来変更されないことを保証するものではないことを覚えておくことが重要です。

コンパイラーとプロセッサーの最適化

再度注意したいのは、volatileキーワードと、メモリバリアを設定するために考慮される3つの関数すべてが、プロセッサの最適化とコンパイラの最適化の両方に影響することです。
つまり、たとえば、このコードは最初の例で示した問題の完全に正しい解決策です。

 public void Bar() { _a = 1; while (_a == 1) { Thread.MemoryBarrier(); } } 

揮発性の危険性

VolatileWriteメソッドとVolatileReadメソッドの実装を見ると、このような命令のペアを再配置できることが明らかになります。

 Thread.VolatileWrite(b) Thread.VolatileRead(a) 

この動作はvolatile読み取りおよび書き込みという用語の定義に組み込まれているため、これはバグではなく、volatileキーワードでマークされた変数を使用した操作も同様の動作をします。
しかし、実際には、この動作は予期しないものです。
例を考えてみましょう：

 class Program { volatile int _firstBool; volatile int _secondBool; volatile string _firstString; volatile string _secondString; int _okCount; int _failCount; static void Main(string[] args) { new Program().Go(); } private void Go() { while (true) { Parallel.Invoke(DoThreadA, DoThreadB); if (_firstString == null && _secondString == null) { _failCount++; } else { _okCount++; } Console.WriteLine("ok - {0}, fail - {1}, fail percent - {2}", _okCount, _failCount, GetFailPercent()); Clear(); } } private float GetFailPercent() { return (float)_failCount / (_okCount + _failCount) * 100; } private void Clear() { _firstBool = 0; _secondBool = 0; _firstString = null; _secondString = null; } private void DoThreadA() { _firstBool = 1; //Thread.MemoryBarrier(); if (_secondBool == 1) { _firstString = "a"; } } private void DoThreadB() { _secondBool = 1; //Thread.MemoryBarrier(); if (_firstBool == 1) { _secondString = "a"; } } } 

プログラム命令が定義された正確な順序で実行された場合、少なくとも1行は常に「a」に等しくなります。 実際、命令の再配置により、これが常に当てはまるわけではありません。 volatileキーワードを適切なメソッドに置き換えても、予想どおり、結果は変わりません。
このプログラムの動作を修正するには、メモリバリアがいっぱいの行のコメントを外すだけで十分です。

パフォーマンスThread.Volatile *およびvolatileキーワード

ほとんどのプラットフォーム（正確には、死にかけているIA64を除くWindowsでサポートされているすべてのプラットフォーム）では、すべての書き込みと読み取りはそれぞれ揮発性書き込みと揮発性読み取りです。 したがって、実行時に、volatileキーワードはパフォーマンスに影響しません。 それどころか、Thread.Volatile *メソッドは、最初にMethodImplOptions.NoInliningとしてマークされたメソッド呼び出し自体のオーバーヘッドを負担し、2番目に、現在の実装では完全なメモリバリアを作成します。 つまり、パフォーマンスの観点から、ほとんどの場合、キーワードを使用することをお勧めします。

---

参照資料

¹ 514ページJoe Duffyを参照。 Windowsでの並行プログラミング
² 誤って実装されたVolatileWriteを参照

使用された文献：

1. ジョセフ・アルバハリ。 C＃のスレッド化
2. バンス・モリソン マルチスレッドアプリでの低ロック技術の影響を理解する
3. ペドラム・レザエイ。 CLR 2.0メモリモデル
4. MS Connect： VolatileWriteが正しく実装されていません
5. ECMA-335共通言語インフラストラクチャ（CLI）
6. C＃言語仕様
7. ジェフリー・リヒター。 C＃Third Editionを介したCLR
8. ジョー・ダフィー。 Windowsでの並行プログラミング
9. ジョセフ・アルバハリ。 C＃4.0の概要