Widzę wiele osób idących w kierunku metody rozszerzania tego ...

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);   
  }   
}

To daje ładniejszą składnię do wywołania zdarzenia ...

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

A także usuwa lokalną kopię, ponieważ jest przechwytywana w czasie wywołania metody.

"Dlaczego explicit-null-check 'standard pattern'?"

Podejrzewam, że powodem tego może być to, że null-check jest bardziej wydajny.

Jeśli zawsze subskrybujesz pustego delegata do swoich wydarzeń podczas ich tworzenia, będą pewne koszty ogólne:

• koszt budowy pustego delegata.
• koszt budowy łańcucha delegatów do jego przechowywania.
• koszt wywołania bezsensownego delegata za każdym razem, gdy zdarzenie jest podniesiony.

(Należy pamiętać, że kontrolki interfejsu często mają dużą liczbę zdarzeń, z których większość nigdy nie jest subskrybowana. Konieczność stworzenia pozornego Abonenta dla każdego zdarzenia, a następnie wywołania go, prawdopodobnie byłaby znaczącym uderzeniem W wydajność.)

Zrobiłem pobieżne testy wydajności, aby zobaczyć wpływ podejścia subscribe-empty-delegate, a oto moje wyniki: {]}

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

Zauważ, że w przypadku zero lub jeden abonentów (wspólne dla kontrolek UI, gdzie zdarzenia są obfite), Zdarzenie wstępnie zainicjowane pustym delegatem jest wyraźnie wolniejsze (ponad 50 milionów iteracji...)

Aby uzyskać więcej informacji i kodu źródłowego, odwiedź ten wpis na blogu . Net Event invocation thread safety , który opublikowałem dzień przed tym pytaniem (!)

(moja konfiguracja testowa może być wadliwa, więc możesz pobrać kod źródłowy i sprawdzić go samodzielnie. Wszelkie opinie są bardzo mile widziane.)

Naprawdę podobała mi się ta lektura - nie! Mimo, że potrzebuję go do pracy z funkcją c# o nazwie events!

Dlaczego nie naprawić tego w kompilatorze? Wiem, że są osoby z MS, które czytają te posty, więc proszę nie palić tego!

1 - Problem Null ) Dlaczego nie uczynić zdarzeń takimi .Pusty zamiast null? Ile linii kodu zostałoby zapisanych do sprawdzenia null lub konieczności przyklejenia = delegate {} do deklaracji? Niech kompilator zajmie się pustą sprawą, czyli nic nie robi! Jeśli to wszystko ma znaczenie dla twórcy wydarzenia, mogą sprawdzić .Opróżnij i zrób z tym, co im zależy! W przeciwnym razie wszystkie null checks / delegate adds to hacki wokół problemu!

Szczerze mówiąc jestem zmęczony koniecznością robienia tego z każdym wydarzeniem-aka boilerplate code!

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 - Problem z race condition ) przeczytałem Post Erica na blogu, zgadzam się, że H (handler) powinien sobie poradzić, gdy się wycofa, ale czy nie można zrobić zdarzenia niezmiennego / wątku bezpiecznego? IE, Ustaw blokadę flaga na jego utworzenie, tak, że kiedykolwiek jest wywoływany, to blokuje wszystkie subskrybowanie i un-subskrybowanie do niego podczas jego wykonywania?

Wnioski ,

Według Jeffreya Richtera w książce CLR via C#, poprawną metodą jest:

// 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);

Ponieważ wymusza kopię odniesienia. Aby uzyskać więcej informacji, zobacz jego dział wydarzenia w książce.

Używam tego wzorca projektowego, aby upewnić się, że procedury obsługi zdarzeń nie są wykonywane po ich wypisaniu. Do tej pory działa całkiem dobrze, chociaż nie próbowałem żadnego profilowania wydajności.

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);
  }
}

W dzisiejszych czasach pracuję głównie z Mono dla Androida, a Android nie podoba się, gdy próbujesz zaktualizować Widok po wysłaniu jego aktywności do tła.

Ta praktyka nie polega na egzekwowaniu określonej kolejności operacji. Chodzi o unikanie wyjątku null reference.

Rozumowanie ludzi dbających o wyjątek null reference, a nie o stan rasy, wymagałoby głębokich badań psychologicznych. Myślę, że ma to coś wspólnego z faktem, że naprawienie problemu null reference jest znacznie łatwiejsze. Gdy to naprawią, powieszą duży baner "Misja zakończona" na swoim kodzie i rozpakują swój lot Garnitur.

Uwaga: naprawienie warunku wyścigu prawdopodobnie polega na użyciu synchronicznego toru flagi, czy opiekun powinien uruchomić

Więc jestem trochę spóźniony na imprezę tutaj. :)

Jeśli chodzi o użycie null zamiast wzorca obiektu null do reprezentowania zdarzeń bez subskrybentów, rozważ ten scenariusz. Musisz wywołać zdarzenie, ale konstruowanie obiektu (EventArgs) jest nietrywialne i w powszechnym przypadku twoje zdarzenie nie ma subskrybentów. Byłoby to korzystne dla Ciebie, jeśli można zoptymalizować kod, aby sprawdzić, czy masz żadnych subskrybentów w ogóle przed podjęciem wysiłku przetwarzania do konstruowania argumenty i wywołanie zdarzenia.

Mając to na uwadze, rozwiązaniem jest stwierdzenie " cóż, zero subskrybentów jest reprezentowane przez null."Następnie po prostu wykonaj kontrolę zerową przed wykonaniem kosztownej operacji. Przypuszczam, że innym sposobem na zrobienie tego byłoby posiadanie właściwości Count na typie delegata, więc wykonałbyś tylko kosztowną operację, jeśli myDelegate.Count > 0. Korzystanie z właściwości Count jest dość ładnym wzorcem, który rozwiązuje pierwotny problem pozwalający na optymalizację i ma również właściwość nice polegającą na tym, że można ją wywoływać bez powodowania wyjątku NullReferenceException.

Należy jednak pamiętać, że ponieważ delegaty są typami referencyjnymi, mogą być null. Być może po prostu nie było dobrego sposobu na ukrycie tego faktu pod przykrywką i wspieranie tylko wzorca obiektu null dla zdarzeń, więc alternatywa mogła zmuszać deweloperów do sprawdzania zarówno dla null, jak i dla zerowych subskrybentów. To byłoby jeszcze brzydsze niż obecne sytuacja.

Uwaga: to czysta spekulacja. Nie jestem zaangażowany w języki. NET lub CLR.

W C # 6 i wyżej, kod można uprościć używając nowego {[0] } jak w TheEvent?.Invoke(this, EventArgs.Empty);

Https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/operators/null-conditional-operators{[6]

Dla aplikacji z pojedynczym gwintem, jesteś correc to nie jest problem.

Jednakże, jeśli tworzysz komponent, który eksponuje zdarzenia, nie ma gwarancji, że konsument twojego komponentu nie przejdzie wielowątkowości, w którym to przypadku musisz przygotować się na najgorsze.

Użycie pustego delegata rozwiązuje problem, ale również powoduje uderzenie wydajności przy każdym wywołaniu zdarzenia i może mieć wpływ na GC.

Masz rację, że konsument trie Dto wypisać się, aby to się stało, ale jeśli udało im się przejść przez kopię tymczasową, a następnie rozważyć wiadomość już w tranzycie.

Jeśli nie używasz zmiennej tymczasowej i nie używasz pustego delegata, a ktoś anuluje subskrypcję, dostajesz wyjątek null reference, który jest fatalny, więc myślę, że koszt jest tego wart.

Nigdy tak naprawdę nie uważałem tego za duży problem, ponieważ generalnie chronię tylko przed tego rodzaju potencjalną wadą wątku w metodach statycznych (etc) na moich komponentach wielokrotnego użytku i nie robię zdarzeń statycznych.

Czy robię to źle?

Przełącz wszystkie wydarzenia na budowę i zostaw je w spokoju. Konstrukcja klasy delegata nie może obsługiwać poprawnie żadnego innego użycia, jak wyjaśnię w ostatnim akapicie tego postu.

Po pierwsze, nie ma sensu próbować przechwycić powiadomienie o zdarzeniu , gdy Obsługa zdarzenia {4]} musi już podjąć zsynchronizowaną decyzję o tym, czy/jak odpowiedzieć na powiadomienie .

Wszystko, co może być zgłoszone, powinno bądź powiadomiony. Jeśli Twoje podmioty zajmujące się obsługą zdarzeń prawidłowo obsługują powiadomienia (tzn. mają dostęp do autorytatywnego stanu aplikacji i odpowiadają tylko wtedy, gdy jest to właściwe), dobrze będzie powiadomić je w dowolnym momencie i zaufać, że odpowiedzą poprawnie.

Jedyny przypadek, kiedy handler nie powinien być powiadamiany o zdarzeniu, to jeśli zdarzenie w rzeczywistości nie miało miejsca! Więc jeśli nie chcesz, aby obsługa była powiadamiana, przestań generować zdarzenia (np. wyłącz kontrolkę lub cokolwiek innego odpowiada przede wszystkim za wykrycie i wywołanie zdarzenia).

Szczerze, myślę, że Klasa delegata jest nie do przyjęcia. Połączenie / przejście do MulticastDelegate było ogromnym błędem, ponieważ skutecznie zmieniło (użyteczną) definicję zdarzenia z czegoś, co dzieje się w jednej chwili w czasie, do czegoś, co dzieje się w czasie. Taka zmiana wymaga mechanizmu synchronizacji, który może logicznie zwinąć go z powrotem do jednej chwili, ale MulticastDelegate nie ma takiego mechanizmu. Synchronizacja powinna obejmować cały czas lub natychmiast zdarzenie ma miejsce, tak że gdy aplikacja podejmie zsynchronizowaną decyzję o rozpoczęciu obsługi zdarzenia, kończy obsługę go całkowicie (transakcyjnie). Z czarną skrzynką, która jest hybrydową klasą MulticastDelegate/Delegate, jest to prawie niemożliwe, więc stosuj się do używania pojedynczego abonenta i / lub zaimplementuj swój własny rodzaj MulticastDelegate, który ma uchwyt synchronizacji, który można wyjąć podczas używania / modyfikowania łańcucha obsługi. Polecam to, ponieważ alternatywą byłoby zaimplementowanie synchronizacji/transactional-integrity redundantnie we wszystkich swoich manipulatorach, co byłoby śmiesznie / niepotrzebnie skomplikowane.

Proszę spojrzeć tutaj: http://www.danielfortunov.com/software/%24daniel_fortunovs_adventures_in_software_development/2009/04/23/net_event_invocation_thread_safety Jest to właściwe rozwiązanie i powinno być zawsze stosowane zamiast wszystkich innych obejść.

" możesz upewnić się, że wewnętrzna lista wywołań ma zawsze co najmniej jednego członka, inicjując ją anonimową metodą do-nothing. Ponieważ żadna strona zewnętrzna nie może mieć odniesienia do metody anonimowej, nie strona zewnętrzna może usunąć metodę, więc delegat nigdy nie będzie null" - Programowanie komponentów. NET, wydanie 2, Autor: Juval lö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);  
}  

Nie wierzę, że pytanie jest ograniczone do Typu c# "event". Usuwając to ograniczenie, dlaczego nie wymyślić trochę koła i zrobić coś wzdłuż tych linii?

Zwiększ bezpiecznie wątek zdarzeń-najlepsza praktyka

• możliwość sub / wypisania się z dowolnego wątku podczas przebijania (wyścig warunek usunięty)
• przeciążenia operatorów dla + = i - = na poziomie klasy.
• Generic caller-defined delegate

Dzięki za użyteczną dyskusję. Ostatnio pracowałem nad tym problemem i zrobiłem następującą klasę, która jest nieco wolniejsza, ale pozwala uniknąć wywołań do usuniętych obiektów.

Głównym punktem jest to, że lista wywołań może być modyfikowana nawet wtedy, gdy wystąpi zdarzenie.

/// <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;
        }
    }
}

A użycie to:

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

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

Test

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

In a Bar (słuchacz obiekt) konstruktor zapisuję się do SomeEvent (co jest zaimplementowane jak pokazano powyżej) i wypisuję się z 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;
    }

Mam też kilka wątków, które wywołują Zdarzenie w pętli.

Wszystkie te działania są wykonywane jednocześnie: wielu słuchaczy jest tworzonych i niszczonych, a zdarzenie jest wywoływane w tym samym czasie.

Gdyby były warunki wyścigu, powinienem zobaczyć wiadomość w konsoli, ale jest pusta. Ale jeśli używam zdarzeń clr jak zwykle widzę to pełne komunikatów ostrzegawczych. Więc, Ja można wywnioskować, że możliwe jest zaimplementowanie wątku safe events W c#.