C＃またはJohn Skeet対Jeffrey Richterのスレッドセーフイベント

「多数のスレッドが常にイベントをサブスクライブおよびサブスクライブ解除している場合、C＃でスレッドセーフなイベントコールを編成する方法は？」

「多数のスレッドが常にイベントをサブスクライブおよびサブスクライブ解除している場合、C＃でスレッドセーフなイベントコールを編成する方法は？」

ジェフリー・リヒターの道

public event Action MyLittleEvent; ... protected virtual void OnMyLittleEvent() { if (MyLittleEvent != null) MyLittleEvent(); } 

展開する

 protected virtual void OnMyLittleEvent() { Action tempAction = MyLittleEvent; // ""      //   tempAction     ,      null     if (tempAction != null) tempAction (); } 

 protected virtual void OnMyLittleEvent() { //      Action tempAction = Volatile.Read(ref MyLittleEvent); if (tempAction != null) tempAction (); } 

スレッドセーフなイベント呼び出しを確実にするには、イベントをローカル変数にコピーして現在のサブスクライバーのリストを「フリーズ」し、受信したリストが空でない場合、「フリーズ」リストからすべてのハンドラーを呼び出します。 したがって、可能性のあるNullReferenceException.を取り除きNullReferenceException.

展開する

StackOverflowは何について話しているのですか？

ローカル変数に関するこの誇大広告はすべて、 Cargo Cult Programmingに他ならないように思えます。 多数の人々がこの方法でスレッドセーフイベントの問題を解決しますが、 完全なスレッドセーフを実現するにはさらに多くの作業が必要です。 このようなチェックをコードに追加しない人は、コードなしでも実行できると自信を持って言えます。 この問題は、シングルスレッド環境には存在しません。オンラインコード例のvolatileキーワードを満たすことはめったにないことを考えると、この追加チェックは無意味かもしれません。 NullReferenceExceptionを追跡することが目標の場合、クラスオブジェクトの初期化中に空のdelegate { }イベントに割り当てることで、 nullをまったくチェックせずに実行できますか？

 public event Action MyLittleEvent = delegate {}; 

 public event Action MyLittleEvent = delegate {}; protected virtual void OnMyLittleEvent() { // ,   MyLittleEvent(); } 

ジョン・スキートの道

 SomeEventHandler someEvent; readonly object someEventLock = new object(); public event SomeEventHandler SomeEvent { add { lock (someEventLock) { someEvent += value; } } remove { lock (someEventLock) { someEvent -= value; } } } protected virtual void OnSomeEvent(EventArgs e) { SomeEventHandler handler; lock (someEventLock) { handler = someEvent; } if (handler != null) { handler (this, e); } } 

はい、すべてのコストでNullReferenceExceptionを防止しようとすることについて、このNullReferenceExceptionを本当に理解しました。 私たちの特定のケースでは、別のスレッドがイベントのサブスクライブを解除している場合にのみNullReferenceExceptionが発生する可能性があることを話しています。 そして彼は、 イベントを二度と受け取らないようにするためだけにこれを行います。実際、ローカル変数のチェックを使用する場合、これは達成されません 。 レースの状態を非表示にする場合、それを開いて結果を修正できます 。 NullReferenceException使用NullReferenceExceptionと、イベントの不適切な処理の瞬間を判断できNullReferenceException 。 一般に、このコピーとチェックの手法は、コードに混乱とノイズを追加する単純なカーゴカルトプログラミングであると主張しますが、マルチスレッドイベントの問題はまったく解決しません。

ジョン・スキートvs.ジェフリー・リヒター

JITコンパイラーには、条件があるため、デリゲートへのローカル参照を最適化する権利がありません。 この情報はしばらく前に「投げられた」が、これは真実ではない（Joe DuffyまたはVance Morrisonのいずれかでこの質問を明確にした）。 volatileないと、デリゲートへのローカル参照が少し古くなる可能volatileだけです。 これにより、 NullReferenceExceptionは発生しません。

そして、はい、間違いなく競合状態にあります、あなたは正しいです。 しかし、常に存在します。 nullチェックを削除して、次のように書くとしましょう。

 MyLittleEvent(); 

サブスクライバーのリストが1000人のデリゲートで構成されていると想像してください。 サブスクライバーの1人がイベントのサブスクリプションを解除する前に、イベントのトリガーを開始する可能性があります。 この場合、古いリストに残るため、呼び出されます（デリゲートが不変であることを忘れないでください）。 私の知る限り、これは完全に避けられません。
空のdelegate {};を使用するdelegate {}; nullのイベントをチェックする必要がnullが、これはレースの次の状態から私たちを救いません。 さらに、このメソッドは、イベントの最新バージョンを使用することを保証しません。

JITコンパイラーはローカルのtempAction変数を最適化することで誤って何ができるかを知っているため、 Volatile.Readを使用したバージョンを使用することをお勧めしますが、 オプション2は省略できます。 理論的には 、これは将来変更される可能性があるため、 オプション3を使用することをお勧めします。 しかし、実際には、 Microsoftがこのような変更を行うことはほとんどありません。これは、既製の膨大な数のプログラムを破壊する可能性があるからです。

最後に何がありますか

• 最も一般的な方法は、不等式をチェックした後にデリゲートをnullにする可能性があるため、 スレッドセーフではありません 。 NullReferenceException危険があります
  

   public event Action MyLittleEvent; ... protected virtual void OnMyLittleEvent() { if (MyLittleEvent != null) //  NullReferenceException MyLittleEvent(); } 

  
  
• SkeetおよびRichterのメソッドはNullReferenceExceptionを回避するのに役立ちますが、まだ未登録のハンドラーを呼び出す可能性があるため 、 スレッドセーフではありません 。
  
  スキート法

   SomeEventHandler someEvent; readonly object someEventLock = new object(); public event SomeEventHandler SomeEvent { add { lock (someEventLock) { someEvent += value; } } remove { lock (someEventLock) { someEvent -= value; } } } protected virtual void OnSomeEvent(EventArgs e) { SomeEventHandler handler; lock (someEventLock) { handler = someEvent; } if (handler != null) { handler (this, e); } } 

  
  
  
  
  リヒター法

   protected virtual void OnMyLittleEvent() { //      Action tempAction = Volatile.Read(ref MyLittleEvent); if (tempAction != null) tempAction (); } 

  
  
  
  
• 空のdelegate {};メソッドdelegate {}; イベントがnullに変わることはないため、 NullReferenceExceptionを取り除くことができますが、すでにサブスクライブされていないハンドラーを呼び出す可能性があるため、 スレッドセーフではありません 。 さらに、 volatileなしで、イベントが呼び出されたときにデリゲートの最新バージョンを取得する機会があります。
  
• lockでイベントの追加、削除、呼び出しをラップすることはできません。これはデッドロックの危険を引き起こすからです。 技術的には、これにより、サブスクライブされていないハンドラーの呼び出しを省くことができますが、イベントからサブスクライブする前にサブスクライブするオブジェクトがどのアクションを実行したかを確認できないため、「破損」オブジェクトにObjectDisposedException ） このメソッドはスレッドセーフでもありません 。
  
• ローカルの「フリーズ」イベント後にサブスクライブしていないデリゲートをキャッチする試みは無意味です-多数のサブスクライバーでは、（イベントコールの開始後に）サブスクライブしていないハンドラーを呼び出す確率は、ローカルの「フリーズ」よりも高くなります。
  

サブスクライブされていないサブスクライバーのハンドラーを呼び出す可能性が常にあるため、マルチスレッド環境でスレッドセーフイベント呼び出しを提供することは不可能です。 この不確実性は、「スレッドセーフティ」という用語の定義、特に条項と矛盾しています

実装は、複数のスレッドから同時にアクセスされたときに競合状態がないことが保証されています。

追加の読書

• C＃経由のCLR（Jeffrey Richter）
• ジョンスキートが競合状態の不可避性について話すSOに関する質問。 イベントコールの時間の比較テストの結果もあります。
• イベントを呼び出すさまざまな方法の欠点を明確かつ慎重に説明する小さな記事（古い）
• C＃の詳細-デリゲートとイベント（Jon Skeet）
• スレッドセーフはハンドラーの仕事であると述べている有用な記事
• 別のアプローチを使用したイベント呼び出し時間の別の比較分析
• 空のデリゲートの詳細
• メモリーバリアと揮発性について少し（Joe Albahari）
• 揮発性についてもう少し
• 参照型を使用した操作の原子性について
• 擬似スレッドセーフイベントトリガーの拡張メソッド
• 一言で言えばC＃5.0（まだC＃のお気に入りの本、強くお勧めします）