События C# и потокобезопасность

Question

События C# и потокобезопасность

Возможно, вы изменили значение отступа на вкладке. Посмотрите на строку состояния (внизу справа) и посмотрите, сколько пробелов установлено на вашей вкладке. Вы можете нажать на строку состояния, чтобы изменить ее, или нажать cmd + shift + p (OS X) или ctrl + shift + p (Windows), чтобы открыть команду pallete, и набрать Indent, чтобы найти опцию Indent Using Spaces и установить для нее 4 (или [ 113], как хотите).

230

multithreading c# events

задан DaveInCaz 20 February 2019 в 02:54

8 ответов

Я никогда не думал, что это большая проблема, потому что я, как правило, защищаю только от такого рода потенциальных проблем с потоками в статических методах (и т. Д.) На моих повторно используемых компонентах, и я не делать статические события.

Я делаю это неправильно?

0

ответ дан 23 November 2019 в 03:41

для однопоточных приложений, вы исправляете это не проблема.

Однако, если вы создаете компонент, который отображает события, нет гарантии, что потребитель вашего компонента не собирается использовать многопоточность, и в этом случае вам нужно подготовиться к худшему.

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

Вы правы в том, что пользователь пытается отменить подписку, чтобы это произошло, но если они сделали это после временной копии, то рассмотрите сообщение, уже находящееся в пути.

Если вы не используете временную переменную, и не используйте пустой делегат, и кто-то отписывается, вы получаете исключение нулевой ссылки, которое является фатальным, поэтому я думаю, что цена того стоит.

0

ответ дан 23 November 2019 в 03:41

Я вижу, что многие люди идут к расширенному методу выполнения этого ...

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

А также избавляет от локальная копия, поскольку она захватывается во время вызова метода.

50

ответ дан 23 November 2019 в 03:41

Эта практика не о применении определенного порядка операций. На самом деле речь идет о том, чтобы избежать исключения с нулевой ссылкой.

Причины, по которым люди заботятся о исключении с нулевой ссылкой, а не о состоянии гонки, потребуют глубоких психологических исследований. Я думаю, что это как-то связано с тем, что решить проблему нулевых ссылок гораздо проще. Как только это будет исправлено, они вешают большой код «Миссия выполнена» на свой код и расстегивают молнию на своем летном костюме.

Примечание:

1

ответ дан 23 November 2019 в 03:41

Так что я немного опоздал на вечеринку здесь. :)

Что касается использования нулевого, а не нулевого шаблона объекта для представления событий без подписчиков, рассмотрим этот сценарий. Вам нужно вызвать событие, но создание объекта (EventArgs) нетривиально, и в общем случае ваше событие не имеет подписчиков. Было бы полезно, если бы вы могли оптимизировать свой код, чтобы проверить, есть ли у вас какие-либо подписчики, прежде чем вы предпримете обработку для построения аргументов и вызова события.

Учитывая это, решение состоит в том, чтобы сказать, «ну, нулевые подписчики представлены нулем». Затем просто выполните нулевую проверку перед выполнением дорогостоящей операции. Я полагаю, что другим способом сделать это было бы иметь свойство Count для типа Delegate, так что вы Выполнять дорогостоящую операцию можно только в том случае, если myDelegate.Count> 0. Использование свойства Count является несколько приятным шаблоном, который решает исходную проблему разрешения оптимизации, а также обладает хорошим свойством возможности вызываться, не вызывая исключение NullReferenceException.

Имейте в виду, однако, что, поскольку делегаты являются ссылочными типами, они могут быть нулевыми. Возможно, просто не было хорошего способа скрыть этот факт под прикрытием и поддерживать только шаблон нулевого объекта для событий, поэтому альтернатива могла заставить разработчиков проверять как на нулевых, так и на нулевых подписчиков. Это было бы даже хуже, чем нынешняя ситуация.

Примечание: это чистая спекуляция. Я не связан с языками .NET или CLR.

Использование свойства Count - это довольно приятный шаблон, который решает исходную проблему разрешения оптимизации, и он также обладает хорошим свойством возможности вызываться, не вызывая NullReferenceException.

Однако имейте в виду, что, поскольку делегаты являются ссылочными типы, они могут быть нулевыми. Возможно, просто не было хорошего способа скрыть этот факт под прикрытием и поддерживать только шаблон нулевого объекта для событий, поэтому альтернатива могла заставить разработчиков проверять как на нулевых, так и на нулевых подписчиков. Это было бы даже хуже, чем нынешняя ситуация.