ОНОВЛЕННЯ

Відповідно до C # 6, відповідь на це питання:

SomeEvent?.Invoke(this, e);

Я часто чую / читаю такі поради:

Завжди робіть копію події, перш ніж перевірити її nullта запустити її. Це дозволить усунути потенційну проблему з нанизуванням, де подія стає nullв точці розташування між місцем, де ви перевіряєте на нуль, і де ви запускаєте подію:

// 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 це?)

Оновлено:Якщо це не було зрозуміло, я зрозумів намір поради - уникати нульового виключення за будь-яких обставин. Моя думка полягає в тому, що цей конкретний нульовий посилання на виняток може виникнути лише в тому випадку, якщо інший потік відхиляється від події, і єдиною причиною цього є забезпечення того, щоб додаткові дзвінки не надходили через цю подію, що очевидно НЕ досягається цією технікою . Ви б приховували умову гонки - краще було б розкрити її! Цей нульовий виняток допомагає виявити зловживання вашим компонентом. Якщо ви хочете, щоб ваш компонент був захищений від зловживань, ви можете наслідувати приклад WPF - зберігайте ідентифікатор потоку у своєму конструкторі, а потім кидайте виняток, якщо інший потік намагається взаємодіяти безпосередньо з вашим компонентом. Або ж реалізуйте справді безпечний для компонентів компонент (завдання не з легких).

Тому я стверджую, що просто виконувати цю ідіому копіювання / перевірки - це культове програмування вантажу, додаючи безлад та шум у ваш код. Щоб реально захиститись від інших ниток, потрібно набагато більше роботи.

Оновлення у відповідь на повідомлення в блозі Еріка Ліпперта:

Тож є головне, що я пропустив у обробниках подій: "Обробники подій повинні бути надійними, якщо вони можуть бути викликані навіть після відмови від підписки", і, очевидно, тому нам потрібно дбати лише про можливість події. делегат буття null. Чи є ця вимога до обробників подій документована де-небудь?

І так: "Є й інші способи вирішити цю проблему; наприклад, ініціалізація обробника на порожню дію, яка ніколи не видаляється. Але проведення нульової перевірки є стандартною схемою".

Отже, один з фрагментів мого запитання полягає в тому , чому явна перевірка нуля перевіряє "стандартний зразок"? Альтернатива, призначаючи порожній делегат, вимагає лише= delegate {} додавати до декларації події, і це виключає ті маленькі купи смердючої церемонії з усіх місць, де відбулася подія. Було б легко переконатися, що порожній делегат дешевий для отримання екземпляра. Або я все-таки щось пропускаю?

Безумовно, що так (як запропонував Джон Скіт), це просто .NET 1.x порада, яка не вимерла, як це слід було зробити в 2005 році?

Через JIT не дозволяється виконувати оптимізацію, про яку ви говорите в першій частині. Я знаю, що це було зроблено як привид деякий час тому, але це не вірно. (Я перевірив це чи Джо Даффі, чи Венсом Моррісоном деякий час тому; я не можу пригадати, який.)

Без змінного модифікатора можливо, що зроблена локальна копія застаріла, але це все. Це не спричинитьNullReferenceException .

І так, безумовно, є умова гонки - але завжди буде така. Припустимо, ми просто змінимо код на:

TheEvent(this, EventArgs.Empty);

Тепер припустимо, що список викликів для цього делегата містить 1000 записів. Цілком можливо, що дія на початку списку буде виконана до того, як інший потік скасувати підписку обробника в кінці списку. Однак цей обробник все одно буде виконуватися, оскільки це буде новий список. (Делегати незмінні.) Наскільки я бачу, це неминуче.

Використання порожнього делегата, безумовно, дозволяє уникнути перевірки недійсності, але не виправляє умову гонки. Це також не гарантує того, що ви завжди "бачите" останнє значення змінної.

Я бачу, що багато людей йде до методу розширення, роблячи це ...

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 перевіряє" стандартний шаблон "?"

Я підозрюю, що причиною цього може бути те, що нульова перевірка є більш ефективною.

Якщо ви завжди підписуєте порожній делегат на свої події, коли вони створюються, будуть деякі накладні витрати:

• Вартість побудови порожнього делегата.
• Вартість побудови ланцюга делегата для його утримання.
• Вартість виклику безглуздого делегата щоразу, коли подія піднімається.

(Зауважте, що в елементах управління інтерфейсом часто відбувається велика кількість подій, на більшість з яких ніколи не підписано. Необхідно створити підроблений абонент на кожну подію, а потім викликати це, ймовірно, буде значним показником ефективності.)

Я зробив кілька побіжних тестувань продуктивності, щоб побачити вплив підходу «підписатись-порожній-делегат», і ось мої результати:

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

Зауважте, що для нуля або одного абонента (звичайно для елементів управління інтерфейсом, де подій багато), подія, попередньо ініціалізована порожнім делегатом, помітно повільніше (понад 50 мільйонів ітерацій ...)

Для отримання додаткової інформації та вихідного коду відвідайте цю публікацію в блозі про безпеку потоку виклику .NET Event, яку я опублікував за день до того, як це питання було задано (!)

(Моя тестова настройка може бути помилковою, тому сміливо завантажуйте вихідний код і огляньте його самостійно. Будь-який відгук дуже вдячний.)

Мені справді сподобалось це читання - ні! Хоча мені це потрібно для роботи з функцією C # під назвою події!

Чому б не виправити це в компіляторі? Я знаю, що є люди з MS, які читають ці пости, тому, будь ласка, не горіть цим!

1 - Нульовий випуск ) Чому б не зробити події. По-перше, порожніми, а не нульовими? Скільки рядків коду було б збережено для нульової перевірки або необхідності вклеїти a = delegate {}на декларацію? Нехай компілятор обробляє порожній випадок, IE нічого не робить! Якщо це все має значення для творця події, він може перевірити наявність. Порожні та робити все, що їм важливо! Інакше всі нульові перевірки / додавання делегата - це хакі навколо проблеми!

Чесно кажучи, мені набридло робити це з кожною подією - ака-код котла!

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 через C # , правильний метод:

// 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 для Android сьогодні, і Android, здається, не сподобається, коли ви намагаєтесь оновити Перегляд після того, як його активність буде надіслана на другий план.

Ця практика не стосується виконання певного порядку операцій. Йдеться про те, щоб уникнути нульового посилання виключення.

Міркування людей, які піклуються про нульовий вихідний виняток, а не про перегони, потребують глибокого психологічного дослідження. Я думаю, це має щось спільне з тим, що виправити нульову проблему посилання набагато простіше. Після того, як це буде виправлено, вони вивішують великий код "Виконана місія" на своєму коді та розпакують їх льотний костюм.

Примітка: виправлення умови перегонів, ймовірно, передбачає використання синхронної доріжки прапора, чи повинен обробник працювати

Тому я трохи запізнююся на вечірку тут. :)

Щодо використання нульового, а не нульового об'єктного шаблону для представлення подій без підписників, розглянемо цей сценарій. Потрібно викликати подію, але побудова об'єкта (EventArgs) нетривіальна, і в загальному випадку у вашої події немає підписників. Вам було б корисно, якби ви могли оптимізувати свій код, щоб перевірити, чи були у вас підписки взагалі, перш ніж ви доклали зусиль для обробки конструкції аргументів та виклику події.

Зважаючи на це, рішення полягає в тому, щоб сказати, "ну нуль абонентів представлений нулем". Тоді просто виконайте нульову перевірку перед виконанням дорогої операції. Я вважаю, що іншим способом цього було б мати властивість Count типу Delegate, тож дорогу операцію ви виконували б лише, якщо myDelegate.Count> 0. Використання властивості Count - дещо приємний зразок, який вирішує початкову проблему дозволяє оптимізувати, а також має приємне властивість можливості викликати, не викликаючи NullReferenceException.

Майте на увазі, що оскільки делегати є типовими типами, вони можуть бути нульовими. Можливо, просто не було хорошого способу приховувати цей факт під прикриттями та підтримувати лише нульовий шаблон об’єкта для подій, тому альтернатива, можливо, змусила розробників перевіряти як на нуль, так і на нульових абонентів. Це було б навіть гірше, ніж нинішня ситуація.

Примітка. Це чиста спекуляція. Я не пов'язаний з мовами .NET або CLR.

для однопоточних додатків, ви коригуєте це не проблема.

Однак, якщо ви створюєте компонент, який розкриває події, немає гарантії, що споживач вашого компонента не збирається переходити до багатопотокової роботи, і в цьому випадку вам потрібно підготуватися до гіршого.

Використання порожнього делегата вирішує проблему, але також спричиняє враження від продуктивності під час кожного дзвінка на подію і, можливо, може мати наслідки для GC.

Ви маєте рацію, що споживач trie dto скасував підписку, щоб це сталося, але якщо вони пройшли минулу копію, то розгляньте повідомлення, яке вже перебуває в дорозі.

Якщо ви не використовуєте тимчасову змінну і не використовуєте порожній делегат, а хтось скасує підписку, ви отримаєте нульове виняткове посилання, яке є фатальним, тому я думаю, що вартість того варта.

Я ніколи насправді не вважав це великою проблемою, тому що я, як правило, захищаю лише від подібних можливих погіршень нарізання статичними методами (тощо) на своїх багаторазових компонентах, і я не роблю статичних подій.

Чи я це роблю неправильно?

Передайте всі свої події на будівництві та залиште їх у спокої. Дизайн класу Delegate, можливо, не може правильно впоратися з будь-яким іншим використанням, як я поясню в заключному пункті цієї публікації.

Перш за все, немає сенсу намагатися перехопити сповіщення про подію, коли ваші обробники подій вже повинні прийняти синхронізоване рішення про те, чи відповідати на повідомлення .

Все, що може бути повідомлено, повинно бути повідомлено. Якщо ваші обробники подій належним чином обробляють сповіщення (тобто вони мають доступ до авторитетного стану програми та відповідають лише тоді, коли це доречно), тоді буде добре повідомляти їх у будь-який час і вірити, що вони відповідуть належним чином.

Єдиний раз, коли обробник не повинен отримувати повідомлення про те, що подія сталася, це якщо подія насправді не сталася! Тож якщо ви не хочете, щоб обробник отримував сповіщення, припиніть генерувати події (тобто відключіть керування або все, що є відповідальним за виявлення та приведення події в першу чергу).

Чесно кажучи, я вважаю, що клас Delegate незмінний. Злиття / перехід до MulticastDelegate було величезною помилкою, оскільки воно фактично змінило (корисне) визначення події з того, що відбувається в один момент часу, до того, що відбувається за часовий проміжок часу. Така зміна вимагає механізму синхронізації, який може логічно згортати її назад в єдиний момент, але MulticastDelegate не має будь-якого такого механізму. Синхронізація повинна охоплювати весь часовий проміжок або момент, коли відбудеться подія, так що після того, як програма приймає синхронізоване рішення про початок обробки події, вона закінчує обробляти її повністю (транзакційно). З чорною скринькою гібридного класу MulticastDelegate / Delegate це майже неможливодотримуватися використання одноразового абонента та / або реалізувати власний вид MulticastDelegate, який має ручку синхронізації, яку можна вийняти під час використання / модифікації ланцюга обробника . Я рекомендую це, тому що альтернативою було б надмірно реалізувати синхронізацію / транзакційну цілісність у всіх ваших обробниках, що було б смішно / зайво складно.

Погляньте тут: http://www.danielfortunov.com/software/%24daniel_fortunovs_adventures_in_software_development/2009/04/23/net_event_invocation_thread_safety Це правильне рішення, і його завжди слід використовувати замість усіх інших способів вирішення.

"Ви можете гарантувати, що у внутрішньому списку викликів завжди є щонайменше один член, ініціалізуючи його анонімним методом без нічого. Оскільки жодна зовнішня сторона не може мати посилання на анонімний метод, жодна зовнішня сторона не може видалити метод, тому делегат ніколи не буде нульовим »- Програмування .NET Components, 2-е видання, 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);  
}  

Я не вірю, що питання обмежується типом 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конструкторі (об'єкт слухача) я підписався на 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 # можна реалізувати безпечні події.

Що ти думаєш?