更新

C＃6以降、この質問に対する答えは次のとおりです。

SomeEvent?.Invoke(this, e);

私は頻繁に次のアドバイスを聞いたり読んだりします：

確認して実行する前に、必ずイベントのコピーを作成してくださいnull。これにより、nullnullを確認する場所とイベントを発生させる場所の間にイベントが発生する、スレッドに関する潜在的な問題が解消されます。

// Copy the event delegate before checking/calling
EventHandler copy = TheEvent;

if (copy != null)
    copy(this, EventArgs.Empty); // Call any handlers on the copied list

更新：最適化について読んだことから、これにはイベントメンバーも揮発性である必要があるかもしれないと思いましたが、ジョンスキートは彼の回答でCLRはコピーを最適化しないと述べています。

しかし、その間、この問題が発生するためには、別のスレッドが次のようなことをしている必要があります。

// Better delist from event - don't want our handler called from now on:
otherObject.TheEvent -= OnTheEvent;
// Good, now we can be certain that OnTheEvent will not run...

実際のシーケンスは次のようになります。

// Copy the event delegate before checking/calling
EventHandler copy = TheEvent;

// Better delist from event - don't want our handler called from now on:
otherObject.TheEvent -= OnTheEvent;    
// Good, now we can be certain that OnTheEvent will not run...

if (copy != null)
    copy(this, EventArgs.Empty); // Call any handlers on the copied list

要点はOnTheEvent、作成者が購読を解除した後でありますが、それが発生しないように、特に購読を解除しただけです。確かに本当に必要なのは、addとremoveアクセサで適切に同期するカスタムイベントの実装です。さらに、イベントが発生したときにロックが保持されると、デッドロックが発生する可能性があるという問題があります。

それでは、このカーゴカルトプログラミングですか？それはそのようです-マルチスレッド設計の一部として使用できるようになる前に、実際にはイベントはこれよりもはるかに注意を必要とするように思えますが、多くの人々はコードを複数のスレッドから保護するためにこのステップを踏まなければなりません。その結果、その追加の注意を払っていない人々はこのアドバイスを無視するかもしれません-それは単にシングルスレッドプログラムの問題ではありません、そして実際、volatileほとんどのオンラインサンプルコードに欠けているとすれば、アドバイスはないかもしれませんまったく効果。

（そして、最初delegate { }にチェックする必要がないように、メンバー宣言に空を割り当てるだけの方がずっと簡単ではないnullですか？）

更新しました：不明確な場合でも、私はアドバイスの意図を理解しました。あらゆる状況でnull参照例外を回避するためです。私のポイントは、この特定のnull参照例外は、別のスレッドがイベントから登録解除されている場合にのみ発生する可能性があることであり、これを行う唯一の理由は、そのイベントを介してそれ以上の呼び出しが受信されないようにすることです。これは、この手法では明らかに達成されません。 。あなたは競合状態を隠しているでしょう-それを明らかにする方が良いでしょう！このnull例外は、コンポーネントの不正使用を検出するのに役立ちます。コンポーネントを不正使用から保護したい場合は、WPFの例に従う-コンストラクターにスレッドIDを格納し、別のスレッドがコンポーネントと直接対話しようとした場合に例外をスローします。または、本当にスレッドセーフなコンポーネントを実装します（簡単な作業ではありません）。

したがって、このコピー/チェックのイディオムを実行するだけでは、カーゴカルトプログラミングであり、コードに混乱やノイズが加わると思います。他のスレッドから実際に保護するには、さらに多くの作業が必要です。

Eric Lippertのブログ投稿に応じて更新：

したがって、イベントハンドラーについて見逃していた重要なことがあります。「イベントハンドラーは、イベントがサブスクライブされた後でも呼び出される前に堅牢である必要がある」ため、イベントの可能性のみを考慮する必要があります。委任null。イベントハンドラーの要件はどこかに文書化されていますか？

そして、「この問題を解決する方法は他にもあります。たとえば、ハンドラーを初期化して、削除されない空のアクションを設定します。ただし、nullチェックを行うのが標準的なパターンです。」

だから私の質問の残りの断片は、なぜ「標準パターン」を明示的にヌルチェックするのですか？代わりに、空のデリゲートを割り当てる= delegate {}と、イベント宣言に追加するだけで済みます。これにより、イベントが発生するすべての場所から、これらの小さな臭い儀式の山がなくなります。空のデリゲートをインスタンス化するのが安価であることを確認するのは簡単です。または、まだ何か不足していますか？

確かにそれは（Jon Skeetが示唆したように）これは2005年に行われるはずだった、消えていない.NET 1.xのアドバイスにすぎないのでしょうか？

JITは、条件のため、最初の部分で説明している最適化を実行できません。これは少し前に妖怪として提起されたことは知っていますが、有効ではありません。（私は少し前にJoe DuffyかVance Morrisonのどちらかでそれをチェックしました;私はどちらを思い出せませんか。）

volatile修飾子がないと、取得されたローカルコピーが古くなる可能性がありますが、それだけです。は発生しませんNullReferenceException。

もちろん、競合状態は確かにありますが、常に存在します。コードを次のように変更するとします。

TheEvent(this, EventArgs.Empty);

次に、そのデリゲートの呼び出しリストに1000のエントリがあるとします。別のスレッドがリストの終わり近くにあるハンドラーをサブスクライブ解除する前に、リストの最初のアクションが実行される可能性は完全にあり得ます。ただし、そのハンドラーは新しいリストになるため、引き続き実行されます。（デリゲートは不変です。）私が見る限り、これは避けられません。

空のデリゲートを使用すると、nullityチェックは確実に回避されますが、競合状態は修正されません。また、変数の最新の値が常に「表示」されることも保証されません。

多くの人がこれを行う拡張方法に向かっているのを見ています...

public static class Extensions   
{   
  public static void Raise<T>(this EventHandler<T> handler, 
    object sender, T args) where T : EventArgs   
  {   
    if (handler != null) handler(sender, args);   
  }   
}

それはあなたにイベントを発生させるより良い構文を与えます...

MyEvent.Raise( this, new MyEventArgs() );

また、メソッドの呼び出し時にキャプチャされるため、ローカルコピーも不要です。

「なぜ「標準パターン」を明示的にヌルチェックするのですか？」

この理由は、nullチェックの方がパフォーマンスが高いためだと思います。

イベントの作成時に常に空のデリゲートをイベントにサブスクライブすると、いくつかのオーバーヘッドが発生します。

• 空のデリゲートを構築するコスト。
• それを含むデリゲートチェーンを構築するコスト。
• イベントが発生するたびに無意味なデリゲートを呼び出すコスト。

（UIコントロールには多数のイベントが含まれることが多く、そのほとんどがサブスクライブされないことに注意してください。各イベントにダミーサブスクライバーを作成して呼び出す必要があると、パフォーマンスが大幅に低下する可能性があります。）

私はいくつかの大まかなパフォーマンステストを行って、subscribe-empty-delegateアプローチの影響を確認しました。これが私の結果です。

Executing 50000000 iterations . . .
OnNonThreadSafeEvent took:      432ms
OnClassicNullCheckedEvent took: 490ms
OnPreInitializedEvent took:     614ms <--
Subscribing an empty delegate to each event . . .
Executing 50000000 iterations . . .
OnNonThreadSafeEvent took:      674ms
OnClassicNullCheckedEvent took: 674ms
OnPreInitializedEvent took:     2041ms <--
Subscribing another empty delegate to each event . . .
Executing 50000000 iterations . . .
OnNonThreadSafeEvent took:      2011ms
OnClassicNullCheckedEvent took: 2061ms
OnPreInitializedEvent took:     2246ms <--
Done

サブスクライバーがゼロまたは1つの場合（イベントが豊富なUIコントロールでよく見られる）は、空のデリゲートで事前に初期化されたイベントは著しく遅い（5000万回を超える繰り返し）ことに注意してください。

詳細とソースコードについては、この質問をする前日に公開した.NETイベント呼び出しスレッドの安全性に関するこのブログ投稿をご覧ください（！）

（私のテスト設定には欠陥があるかもしれないので、自由にソースコードをダウンロードして自分で検査してください。どんなフィードバックでも大歓迎です。）

私はこれを本当に楽しんだ-そうではない！イベントと呼ばれるC＃機能を使用するために必要なのに！

コンパイラでこれを修正しないのはなぜですか？私はこれらの投稿を読んでいるMSの人々がいることを知っているので、これを非難しないでください！

1-Nullの問題）そもそもなぜイベントをnullの代わりに.Emptyにしないのですか？nullチェックのために何行のコードが保存されるか、または= delegate {}宣言に固執する必要がありますか？コンパイラーが空のケースを処理するようにします。IEは何もしません。イベントの作成者にとってそれがすべて重要である場合、彼らは.Emptyをチェックし、気になっていることを何でも行うことができます！それ以外の場合、すべてのnullチェック/デリゲートの追加は問題のハックです！

正直なところ、私はすべてのイベントでこれを行う必要があることにうんざりしています-別名定型コード！

public event Action<thisClass, string> Some;
protected virtual void DoSomeEvent(string someValue)
{
  var e = Some; // avoid race condition here! 
  if(null != e) // avoid null condition here! 
     e(this, someValue);
}

2-競合状態の問題）私はエリックのブログ投稿を読みましたが、H（ハンドラー）がそれ自体を逆参照するときに処理することに同意しますが、イベントを不変/スレッドセーフにすることはできませんか？IEは、作成時にロックフラグを設定します。これにより、呼び出されるたびに、実行中にすべてのサブスクライブとアンサブスクライブがロックされますか？

まとめ、

私たちにとって、現代の言語はこのような問題を解決するはずではありませんか？

C＃6と、上記のコードは、新しい使用簡略化することができた?.とオペレータが：

TheEvent?.Invoke(this, EventArgs.Empty);

こちらがMSDNのドキュメントです。

書籍CLR via CLRの Jeffrey Richterによると、正しい方法は次のとおりです。

// Copy a reference to the delegate field now into a temporary field for thread safety
EventHandler<EventArgs> temp =
Interlocked.CompareExchange(ref NewMail, null, null);
// If any methods registered interest with our event, notify them
if (temp != null) temp(this, e);

それは参照コピーを強制するからです。詳細については、本の彼のイベントセクションを参照してください。

このデザインパターンを使用して、サブスクライブ解除後にイベントハンドラーが実行されないようにしています。これまでのところ、かなりうまく機能していますが、パフォーマンスのプロファイリングは試していません。

private readonly object eventMutex = new object();

private event EventHandler _onEvent = null;

public event EventHandler OnEvent
{
  add
  {
    lock(eventMutex)
    {
      _onEvent += value;
    }
  }

  remove
  {
    lock(eventMutex)
    {
      _onEvent -= value;
    }
  }

}

private void HandleEvent(EventArgs args)
{
  lock(eventMutex)
  {
    if (_onEvent != null)
      _onEvent(args);
  }
}

最近は主にMono for Androidを使用していますが、アクティビティがバックグラウンドに送信された後でビューを更新しようとすると、Androidが気に入らないようです。

これは、特定の順序の操作を強制することではありません。これは、実際にはnull参照例外を回避するためのものです。

競合状態ではなくnull参照例外を気にする人々の背後にある推論には、いくつかの深い心理学的研究が必要です。null参照の問題を修正する方がはるかに簡単であるという事実と関係があると思います。それが修正されると、彼らは大きな "Mission Accomplished"バナーをコードにぶら下げ、フライトスーツを解凍します。

注：競合状態の修正には、ハンドラーを実行するかどうかの同期フラグトラックの使用が含まれる可能性があります

だから私はここのパーティーに少し遅れる。:)

サブスクライバーなしでイベントを表すためのnullオブジェクトパターンではなくnullの使用については、このシナリオを検討してください。イベントを呼び出す必要がありますが、オブジェクト（EventArgs）の作成は簡単ではなく、一般的なケースでは、イベントにサブスクライバーがありません。引数を作成してイベントを呼び出す処理をコミットする前に、コードを最適化してサブスクライバーがまったくいないかどうかを確認できると便利です。

これを念頭に置いて、解決策は、「まあ、ゼロの加入者はnullで表される」と言うことです。次に、高価な操作を実行する前に、nullチェックを実行します。これを行う別の方法は、DelegateタイプにCountプロパティを設定することだったと思います。そのため、myDelegate.Count> 0の場合にのみ、高価な操作を実行します。Countプロパティの使用は、元の問題を解決するやや良いパターンです最適化を許可し、NullReferenceExceptionを発生させずに呼び出すことができるという優れた特性もあります。

ただし、デリゲートは参照型であるため、nullを許可されていることに注意してください。おそらく、この事実を隠蔽してイベントのnullオブジェクトパターンのみをサポートする良い方法は単になかったので、代替策として、開発者にnullとゼロのサブスクライバーの両方をチェックするように強制している可能性があります。それは現在の状況よりも醜いでしょう。

注：これは純粋な推測です。.NET言語やCLRには関与していません。

シングルスレッドアプリケーションの場合、これは問題ではありません。

ただし、イベントを公開するコンポーネントを作成している場合、コンポーネントのコンシューマーがマルチスレッド化しないという保証はありません。その場合、最悪の事態に備える必要があります。

空のデリゲートを使用すると問題は解決しますが、イベントを呼び出すたびにパフォーマンスが低下し、GCに影響する可能性があります。

これが発生するために、コンシューマがサブスクライブを解除することは正しいですが、一時コピーを通過した場合は、メッセージがすでに転送中であることを考慮してください。

一時変数を使用せず、空のデリゲートを使用せず、誰かがサブスクライブを解除すると、null参照例外が発生します。これは致命的であるため、コストに見合う価値があると思います。

再利用可能なコンポーネントの静的メソッド（など）でこの種の潜在的なスレッド化の悪さから保護するだけであり、静的イベントを作成しないため、これをそれほど問題とは考えていません。

私はそれを間違っていますか？

建設中のすべてのイベントを配線し、そのままにしておきます。この投稿の最後の段落で説明するように、Delegateクラスの設計では、他の使用法を正しく処理できない可能性があります。

まず、イベントハンドラーが通知に応答するかどうか、またはどのように応答するかについて同期した決定を既に行う必要がある場合、イベント通知をインターセプトしようとしても意味がありません。

通知される可能性のあるものはすべて通知する必要があります。イベントハンドラーが通知を適切に処理している（つまり、信頼できるアプリケーションの状態にアクセスでき、適切な場合にのみ応答する）場合は、いつでも通知して、適切に応答すると信頼できます。

イベントが発生したことをハンドラーに通知してはならない唯一の場合は、イベントが実際に発生していない場合です！したがって、ハンドラーに通知を送信したくない場合は、イベントの生成を停止します（つまり、コントロールを無効にするか、最初にイベントを検出して存在させる役割を担うものをすべて無効にします）。

正直なところ、Delegateクラスは救済できないと思います。MulticastDelegateへのマージ/移行は、イベントの（有用な）定義を、ある瞬間に発生するものから、ある期間にわたって発生するものに効果的に変更したため、大きな間違いでした。このような変更には、論理的に1つの瞬間に戻すことができる同期メカニズムが必要ですが、MulticastDelegateにはそのようなメカニズムがありません。同期は、タイムスパン全体またはイベントが発生した瞬間を網羅する必要があります。これにより、アプリケーションは、イベントの処理を開始するという同期の決定を行うと、完全に（トランザクションで）処理を終了します。MulticastDelegate / Delegateハイブリッドクラスであるブラックボックスでは、これはほぼ不可能であるため、単一のサブスクライバーの使用に固執するか、ハンドラーチェーンが使用/変更されている間に取り出すことができる同期ハンドルを持つ独自の種類のMulticastDelegateを実装します。代替手段は、すべてのハンドラーに同期/トランザクション整合性を冗長的に実装することであり、それは途方もなく/不必要に複雑になるため、これをお勧めします。

こちらをご覧ください：http : //www.danielfortunov.com/software/%24daniel_fortunovs_adventures_in_software_development/2009/04/23/net_event_invocation_thread_safety これは正しいソリューションであり、他のすべての回避策の代わりに常に使用する必要があります。

「何もしない匿名メソッドで初期化することにより、内部呼び出しリストに常に少なくとも1つのメンバーが含まれるようにすることができます。外部の当事者は匿名メソッドへの参照を持つことができないため、外部の当事者はメソッドを削除できないため、デリゲートがnullになることはありません。— .NETコンポーネントのプログラミング、第2版、JuvalLöwy

public static event EventHandler<EventArgs> PreInitializedEvent = delegate { };  

public static void OnPreInitializedEvent(EventArgs e)  
{  
    // No check required - event will never be null because  
    // we have subscribed an empty anonymous delegate which  
    // can never be unsubscribed. (But causes some overhead.)  
    PreInitializedEvent(null, e);  
}  

質問がc＃の「イベント」タイプに限定されているとは思わない。その制限を取り除いて、ホイールを少し再発明して、これらの線に沿って何かをしてみませんか？

イベントスレッドを安全に上げる-ベストプラクティス

• レイズ内で任意のスレッドをサブスクライブ/サブスクライブ解除する機能（競合状態が削除されます）
• クラスレベルでの+ =および-=の演算子のオーバーロード
• 一般的な呼び出し元定義のデリゲート

有益な議論をありがとう。私は最近この問題に取り組んでおり、少し遅いが、破棄されたオブジェクトへの呼び出しを回避できるようにする次のクラスを作成しました。

ここでの主なポイントは、イベントが発生した場合でも呼び出しリストを変更できることです。

/// <summary>
/// Thread safe event invoker
/// </summary>
public sealed class ThreadSafeEventInvoker
{
    /// <summary>
    /// Dictionary of delegates
    /// </summary>
    readonly ConcurrentDictionary<Delegate, DelegateHolder> delegates = new ConcurrentDictionary<Delegate, DelegateHolder>();

    /// <summary>
    /// List of delegates to be called, we need it because it is relatevely easy to implement a loop with list
    /// modification inside of it
    /// </summary>
    readonly LinkedList<DelegateHolder> delegatesList = new LinkedList<DelegateHolder>();

    /// <summary>
    /// locker for delegates list
    /// </summary>
    private readonly ReaderWriterLockSlim listLocker = new ReaderWriterLockSlim();

    /// <summary>
    /// Add delegate to list
    /// </summary>
    /// <param name="value"></param>
    public void Add(Delegate value)
    {
        var holder = new DelegateHolder(value);
        if (!delegates.TryAdd(value, holder)) return;

        listLocker.EnterWriteLock();
        delegatesList.AddLast(holder);
        listLocker.ExitWriteLock();
    }

    /// <summary>
    /// Remove delegate from list
    /// </summary>
    /// <param name="value"></param>
    public void Remove(Delegate value)
    {
        DelegateHolder holder;
        if (!delegates.TryRemove(value, out holder)) return;

        Monitor.Enter(holder);
        holder.IsDeleted = true;
        Monitor.Exit(holder);
    }

    /// <summary>
    /// Raise an event
    /// </summary>
    /// <param name="args"></param>
    public void Raise(params object[] args)
    {
        DelegateHolder holder = null;

        try
        {
            // get root element
            listLocker.EnterReadLock();
            var cursor = delegatesList.First;
            listLocker.ExitReadLock();

            while (cursor != null)
            {
                // get its value and a next node
                listLocker.EnterReadLock();
                holder = cursor.Value;
                var next = cursor.Next;
                listLocker.ExitReadLock();

                // lock holder and invoke if it is not removed
                Monitor.Enter(holder);
                if (!holder.IsDeleted)
                    holder.Action.DynamicInvoke(args);
                else if (!holder.IsDeletedFromList)
                {
                    listLocker.EnterWriteLock();
                    delegatesList.Remove(cursor);
                    holder.IsDeletedFromList = true;
                    listLocker.ExitWriteLock();
                }
                Monitor.Exit(holder);

                cursor = next;
            }
        }
        catch
        {
            // clean up
            if (listLocker.IsReadLockHeld)
                listLocker.ExitReadLock();
            if (listLocker.IsWriteLockHeld)
                listLocker.ExitWriteLock();
            if (holder != null && Monitor.IsEntered(holder))
                Monitor.Exit(holder);

            throw;
        }
    }

    /// <summary>
    /// helper class
    /// </summary>
    class DelegateHolder
    {
        /// <summary>
        /// delegate to call
        /// </summary>
        public Delegate Action { get; private set; }

        /// <summary>
        /// flag shows if this delegate removed from list of calls
        /// </summary>
        public bool IsDeleted { get; set; }

        /// <summary>
        /// flag shows if this instance was removed from all lists
        /// </summary>
        public bool IsDeletedFromList { get; set; }

        /// <summary>
        /// Constuctor
        /// </summary>
        /// <param name="d"></param>
        public DelegateHolder(Delegate d)
        {
            Action = d;
        }
    }
}

そして使い方は：

    private readonly ThreadSafeEventInvoker someEventWrapper = new ThreadSafeEventInvoker();
    public event Action SomeEvent
    {
        add { someEventWrapper.Add(value); }
        remove { someEventWrapper.Remove(value); }
    }

    public void RaiseSomeEvent()
    {
        someEventWrapper.Raise();
    }

テスト

以下の方法でテストしました。私はこのようなオブジェクトを作成して破壊するスレッドを持っています：

var objects = Enumerable.Range(0, 1000).Select(x => new Bar(foo)).ToList();
Thread.Sleep(10);
objects.ForEach(x => x.Dispose());

でBar（リスナーオブジェクト）コンストラクタIはを購読SomeEvent（上記のように実施される）中に退会しますDispose。

    public Bar(Foo foo)
    {
        this.foo = foo;
        foo.SomeEvent += Handler;
    }

    public void Handler()
    {
        if (disposed)
            Console.WriteLine("Handler is called after object was disposed!");
    }

    public void Dispose()
    {
        foo.SomeEvent -= Handler;
        disposed = true;
    }

また、ループでイベントを発生させるスレッドがいくつかあります。

これらのアクションはすべて同時に実行されます。多くのリスナーが作成および破棄され、同時にイベントが発生します。

競合状態があった場合、コンソールにメッセージが表示されるはずですが、空です。しかし、いつものようにclrイベントを使用すると、警告メッセージがいっぱい表示されます。したがって、c＃でスレッドセーフイベントを実装することが可能であると結論付けることができます。

どう思いますか？