AGGIORNARE

A partire da C # 6, la risposta a questa domanda è:

SomeEvent?.Invoke(this, e);

Spesso ascolto / leggo i seguenti consigli:

Fai sempre una copia di un evento prima di controllarlo nulle attivarlo. Ciò eliminerà un potenziale problema con il threading in cui l'evento diventa nullnella posizione giusta tra dove si verifica la presenza di null e dove si genera l'evento:

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

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

Aggiornato : dalla lettura delle ottimizzazioni ho pensato che ciò potrebbe richiedere la volatilità del membro dell'evento, ma Jon Skeet afferma nella sua risposta che il CLR non ottimizza la copia.

Ma nel frattempo, per far sì che questo problema si verifichi, un altro thread deve aver fatto qualcosa del genere:

// 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...

La sequenza effettiva potrebbe essere questa miscela:

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

Il punto è che OnTheEventcorre dopo che l'autore ha annullato l'iscrizione, eppure ha appena annullato l'iscrizione in modo specifico per evitare che ciò accada. Sicuramente ciò che è veramente necessario è un'implementazione di eventi personalizzati con un'adeguata sincronizzazione negli accessor adde remove. Inoltre, esiste il problema di possibili deadlock se si tiene un blocco mentre viene generato un evento.

Quindi è questa programmazione Cult Cargo ? Sembra in questo modo: molte persone devono fare questo passo per proteggere il loro codice da più thread, quando in realtà mi sembra che gli eventi richiedano molta più attenzione di questo prima che possano essere utilizzati come parte di un design multi-thread . Di conseguenza, le persone che non stanno prestando ulteriore attenzione potrebbero anche ignorare questo consiglio: semplicemente non è un problema per i programmi a thread singolo e, in effetti, data l'assenza della volatilemaggior parte del codice di esempio online, il consiglio potrebbe non avere effetto a tutti.

(E non è molto più semplice assegnare il vuoto delegate { }sulla dichiarazione del membro in modo da non dover mai cercare nullin primo luogo?)

aggiornato:Nel caso in cui non fosse chiaro, ho colto l'intenzione del consiglio: evitare un'eccezione di riferimento nulla in ogni circostanza. Il mio punto è che questa particolare eccezione di riferimento null può verificarsi solo se un altro thread sta cancellando dall'evento e l'unico motivo per farlo è quello di garantire che non vengano ricevute ulteriori chiamate tramite quell'evento, che NON è chiaramente raggiunto da questa tecnica . Nasconderesti una condizione di razza - sarebbe meglio rivelarla! Tale eccezione nulla aiuta a rilevare un abuso del componente. Se vuoi che il tuo componente sia protetto dagli abusi, potresti seguire l'esempio di WPF: memorizzare l'ID del thread nel costruttore e quindi generare un'eccezione se un altro thread tenta di interagire direttamente con il componente. Oppure implementa un componente veramente thread-safe (non un compito facile).

Quindi sostengo che semplicemente fare questo idioma di copia / controllo sia una programmazione di culto del carico, aggiungendo confusione e rumore al tuo codice. Per proteggere effettivamente contro altri thread richiede molto più lavoro.

Aggiornamento in risposta ai post del blog di Eric Lippert:

Quindi c'è una cosa importante che mi mancava per i gestori di eventi: "I gestori di eventi devono essere robusti di fronte al fatto di essere chiamati anche dopo che l'evento è stato cancellato", e ovviamente quindi dobbiamo solo preoccuparci della possibilità dell'evento essere delegato null. Tale requisito sui gestori di eventi è documentato ovunque?

E così: "Esistono altri modi per risolvere questo problema; ad esempio, inizializzare il gestore in modo che un'azione vuota non venga mai rimossa. Ma fare un controllo nullo è il modello standard".

Quindi l'unico frammento rimasto della mia domanda è, perché è esplicito-null-check il "modello standard"? L'alternativa, assegnando il delegato vuoto, richiede solo = delegate {}di essere aggiunta alla dichiarazione dell'evento, e questo elimina quelle piccole pile di puzzolenti cerimonie da ogni luogo in cui l'evento viene generato. Sarebbe facile assicurarsi che il delegato vuoto sia economico da istanziare. O mi manca ancora qualcosa?

Sicuramente deve essere che (come suggerì Jon Skeet) questo è solo un consiglio .NET 1.x che non si è spento, come avrebbe dovuto fare nel 2005?

Alla JIT non è consentito eseguire l'ottimizzazione di cui stai parlando nella prima parte, a causa della condizione. So che questo è stato sollevato come uno spettro qualche tempo fa, ma non è valido. (L'ho verificato con Joe Duffy o Vance Morrison qualche tempo fa; non ricordo quale.)

Senza il modificatore volatile è possibile che la copia locale presa non sia aggiornata, ma questo è tutto. Non causerà a NullReferenceException.

E sì, c'è sicuramente una condizione di gara - ma ci sarà sempre. Supponiamo di cambiare il codice in:

TheEvent(this, EventArgs.Empty);

Supponiamo ora che l'elenco di invocazioni per quel delegato abbia 1000 voci. È perfettamente possibile che l'azione all'inizio dell'elenco sia stata eseguita prima che un altro thread annulli la sottoscrizione di un gestore vicino alla fine dell'elenco. Tuttavia, quel gestore verrà comunque eseguito perché sarà un nuovo elenco. (I delegati sono immutabili.) Per quanto posso vedere, questo è inevitabile.

L'uso di un delegato vuoto evita certamente il controllo di nullità, ma non corregge le condizioni di gara. Inoltre, non garantisce che "vedi" sempre il valore più recente della variabile.

Vedo molte persone andare verso il metodo di estensione per fare questo ...

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

Questo ti dà una sintassi migliore per aumentare l'evento ...

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

Inoltre elimina la copia locale poiché viene acquisita al momento della chiamata del metodo.

"Perché è esplicito-null-check il 'modello standard'?"

Ho il sospetto che la ragione potrebbe essere che il controllo null è più performante.

Se sottoscrivi sempre un delegato vuoto ai tuoi eventi quando vengono creati, ci saranno alcune spese generali:

• Costo di costruzione del delegato vuoto.
• Costo di costruzione di una catena di delegati per contenerla.
• Costo di invocazione del delegato inutile ogni volta che viene generato l'evento.

(Si noti che i controlli dell'interfaccia utente hanno spesso un gran numero di eventi, molti dei quali non sono mai abbonati. Dover creare un utente fittizio per ciascun evento e quindi invocarlo sarebbe probabilmente un notevole impatto sulle prestazioni.)

Ho fatto alcuni test delle prestazioni in corsivo per vedere l'impatto dell'approccio iscriviti-vuoto-delegato, ed ecco i miei risultati:

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

Si noti che nel caso di zero o uno degli abbonati (comune per i controlli dell'interfaccia utente, in cui gli eventi sono abbondanti), l'evento preinizializzato con un delegato vuoto è notevolmente più lento (oltre 50 milioni di iterazioni ...)

Per ulteriori informazioni e codice sorgente, visitare questo post sul blog sulla sicurezza del thread di invocazione di eventi .NET che ho pubblicato il giorno prima della domanda (!)

(La configurazione del mio test potrebbe essere difettosa, quindi non esitare a scaricare il codice sorgente e controllarlo da solo. Qualsiasi feedback è molto apprezzato.)

Mi è davvero piaciuta questa lettura - no! Anche se ne ho bisogno per funzionare con la funzione C # chiamata event!

Perché non risolvere questo problema nel compilatore? So che ci sono persone con SM che leggono questi post, quindi per favore non dare fuoco a questo!

1 - il problema Null ) Perché non fare in modo che gli eventi siano .Empty anziché null in primo luogo? Quante righe di codice verrebbero salvate per un controllo nullo o se dovessero essere incollate = delegate {}sulla dichiarazione? Lascia che il compilatore gestisca il caso Vuoto, IE non fa nulla! Se tutto ciò che conta per il creatore dell'evento, possono controllare .Svuoto e fare tutto ciò che gli interessa! In caso contrario, tutti i controlli null / aggiunte di delegati sono trucchi per risolvere il problema!

Sinceramente sono stanco di doverlo fare con ogni evento, anche noto come codice boilerplate!

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 - il problema delle condizioni di gara ) Ho letto il post sul blog di Eric, sono d'accordo che l'H (gestore) dovrebbe gestire quando si dereferenzia se stesso, ma l'evento non può essere reso immutabile / thread sicuro? IE, imposta un flag di blocco sulla sua creazione, in modo che ogni volta che viene chiamato, blocca tutte le iscrizioni e le cancellazioni durante l'esecuzione?

Conclusione ,

Le lingue moderne non dovrebbero risolvere problemi come questi per noi?

Con C # 6 e versioni successive, il codice potrebbe essere semplificato utilizzando un nuovo ?.operatore come in:

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

Ecco la documentazione MSDN.

Secondo Jeffrey Richter nel libro CLR via C # , il metodo corretto è:

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

Perché forza una copia di riferimento. Per ulteriori informazioni, consultare la sezione Eventi nel libro.

Ho usato questo modello di progettazione per assicurarmi che i gestori di eventi non vengano eseguiti dopo che sono stati cancellati. Finora funziona abbastanza bene, anche se non ho provato alcun profilo di performance.

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

Attualmente lavoro principalmente con Mono per Android e ad Android non sembra piacere quando tenti di aggiornare una vista dopo che la sua attività è stata inviata in background.

Questa pratica non riguarda l'applicazione di un certo ordine di operazioni. In realtà si tratta di evitare un'eccezione di riferimento null.

Il ragionamento alla base delle persone che si preoccupano dell'eccezione di riferimento nulla e non delle condizioni della razza richiederebbe una profonda ricerca psicologica. Penso che abbia qualcosa a che fare con il fatto che risolvere il problema del riferimento null è molto più semplice. Una volta risolto il problema, appendono sul loro codice un grande striscione "Compiuto missione" e decomprimono la tuta di volo.

Nota: la correzione delle condizioni di gara implica probabilmente l'utilizzo di una traccia di bandiera sincrona se il gestore deve eseguire

Quindi sono un po 'in ritardo alla festa qui. :)

Per quanto riguarda l'uso di null anziché il modello di oggetti null per rappresentare eventi senza abbonati, prendere in considerazione questo scenario. Devi invocare un evento, ma costruire l'oggetto (EventArgs) non è banale e, nel caso comune, il tuo evento non ha abbonati. Sarebbe utile se potessi ottimizzare il tuo codice per verificare se disponevi di abbonati prima di impegnarti a elaborare gli argomenti e a invocare l'evento.

Con questo in mente, una soluzione è dire "beh, zero abbonati è rappresentato da null". Quindi eseguire semplicemente il controllo null prima di eseguire un'operazione costosa. Suppongo che un altro modo di fare ciò sarebbe stato avere una proprietà Count sul tipo Delegato, quindi eseguiresti l'operazione costosa solo se myDelegate.Count> 0. L'uso di una proprietà Count è un modello piuttosto piacevole che risolve il problema originale di consentire l'ottimizzazione, e ha anche la bella proprietà di poter essere invocato senza causare una NullReferenceException.

Tieni presente, tuttavia, che, poiché i delegati sono tipi di riferimento, possono essere nulli. Forse non c'era semplicemente un buon modo per nascondere questo fatto sotto le coperte e supportare solo il modello di oggetti null per gli eventi, quindi l'alternativa potrebbe aver costretto gli sviluppatori a controllare sia gli abbonati null che quelli zero. Sarebbe anche più brutto della situazione attuale.

Nota: questa è pura speculazione. Non sono coinvolto con i linguaggi .NET o CLR.

per le applicazioni a thread singolo, si è corretti, questo non è un problema.

Tuttavia, se stai realizzando un componente che espone eventi, non vi è alcuna garanzia che un consumatore del tuo componente non passerà al multithreading, nel qual caso devi prepararti al peggio.

L'uso del delegato vuoto risolve il problema, ma provoca anche un calo delle prestazioni ad ogni chiamata all'evento e potrebbe avere implicazioni per GC.

Hai ragione, il consumatore deve annullare l'iscrizione affinché ciò accada, ma se ha superato la copia temporanea, considera il messaggio già in transito.

Se non usi la variabile temporanea e non usi il delegato vuoto e qualcuno annulla la sottoscrizione, otterrai un'eccezione di riferimento nulla, che è fatale, quindi penso che ne valga la pena.

Non l'ho mai considerato un grosso problema perché in genere proteggo solo da questo tipo di potenziale threading nei metodi statici (ecc.) Sui miei componenti riutilizzabili e non faccio eventi statici.

Sto sbagliando?

Collega tutti i tuoi eventi alla costruzione e lasciali soli. Il design della classe Delegate non può eventualmente gestire correttamente altri usi, come spiegherò nel paragrafo finale di questo post.

Prima di tutto, non ha senso tentare di intercettare una notifica di evento quando i gestori di eventi devono già prendere una decisione sincronizzata sul se / come rispondere alla notifica .

Tutto ciò che può essere notificato, deve essere avvisato. Se i gestori di eventi gestiscono correttamente le notifiche (ovvero hanno accesso a uno stato di applicazione autorevole e rispondono solo quando appropriato), allora andrà bene notificarle in qualsiasi momento e fidarsi che risponderanno correttamente.

L'unica volta in cui un gestore non dovrebbe essere avvisato che si è verificato un evento, è se l'evento in effetti non si è verificato! Quindi, se non si desidera che un gestore venga avvisato, interrompere la generazione degli eventi (ovvero disabilitare il controllo o qualunque cosa sia responsabile del rilevamento e della realizzazione dell'evento in primo luogo).

Onestamente, penso che la classe Delegate sia invalicabile. La fusione / transizione ad un MulticastDelegate è stato un enorme errore, perché ha effettivamente cambiato la (utile) definizione di un evento da qualcosa che accade in un singolo istante nel tempo, a qualcosa che accade in un arco di tempo. Tale modifica richiede un meccanismo di sincronizzazione che può logicamente ripiegarlo in un singolo istante, ma al MulticastDelegate manca tale meccanismo. La sincronizzazione dovrebbe comprendere l'intero periodo di tempo o l'istante in cui si verifica l'evento, in modo che quando un'applicazione prende la decisione sincronizzata di iniziare a gestire un evento, termina di gestirlo completamente (a livello transazionale). Con la scatola nera che è la classe ibrida MulticastDelegate / Delegate, questo è quasi impossibile, quindiaderire all'uso di un singolo abbonato e / o implementare il proprio tipo di MulticastDelegate che ha un handle di sincronizzazione che può essere rimosso mentre la catena di gestori viene utilizzata / modificata . Lo sto raccomandando, perché l'alternativa sarebbe implementare la sincronizzazione / integrità delle transazioni in modo ridondante in tutti i gestori, il che sarebbe ridicolmente / inutilmente complesso.

Dai un'occhiata qui: http://www.danielfortunov.com/software/%24daniel_fortunovs_adventures_in_software_development/2009/04/23/net_event_invocation_thread_safety Questa è la soluzione corretta e deve essere sempre utilizzata al posto di tutti gli altri soluzioni alternative.

“Puoi assicurarti che l'elenco di invocazioni interno abbia sempre almeno un membro inizializzandolo con un metodo anonimo do-nothing. Poiché nessuna parte esterna può avere un riferimento al metodo anonimo, nessuna parte esterna può rimuovere il metodo, quindi il delegato non sarà mai nullo ”- Programming .NET Components, 2nd Edition, di 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);  
}  

Non credo che la domanda sia limitata al tipo di "evento" c #. Rimuovendo tale restrizione, perché non reinventare un po 'la ruota e fare qualcosa del genere?

Solleva il thread degli eventi in modo sicuro - best practice

• Possibilità di iscriversi / annullare l'iscrizione a qualsiasi thread durante un rilancio (condizione di gara rimossa)
• Sovraccarichi dell'operatore per + = e - = a livello di classe.
• Delegato generico definito dal chiamante

Grazie per una discussione utile. Di recente ho lavorato su questo problema e ho reso la seguente classe un po 'più lenta, ma consente di evitare chiamate a oggetti disposti.

Il punto principale qui è che l'elenco di invocazioni può essere modificato anche se viene generato un evento.

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

E l'uso è:

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

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

Test

L'ho provato nel modo seguente. Ho un thread che crea e distrugge oggetti come questo:

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

In un Barcostruttore (un oggetto listener) mi iscrivo a SomeEvent(che è implementato come mostrato sopra) e annulla l'iscrizione in 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;
    }

Inoltre ho un paio di thread che generano eventi in un ciclo.

Tutte queste azioni vengono eseguite simultaneamente: molti ascoltatori vengono creati e distrutti e l'evento viene lanciato contemporaneamente.

Se ci fossero condizioni di gara dovrei vedere un messaggio in una console, ma è vuoto. Ma se uso gli eventi clr come al solito lo vedo pieno di messaggi di avviso. Quindi, posso concludere che è possibile implementare eventi thread-safe in c #.

Cosa ne pensi?