andreycha31 мар 2010 в 15:41

Слабые события в C#

11 мин

83K

.NET *

Перевод

+59

Комментарии 18

mecommayou 31 мар 2010 в 16:28

Цветные диаграмке!

adontz 31 мар 2010 в 17:30

Откуда вы взяли lock(this) в add/remove? Делегаты immutable, а присваивание reference объекта атомарно. lock(this) не просто нет, он не нужен.

ControlFlow 31 мар 2010 в 18:08

К сожалению, Вы ошибаетесь, lock(this) есть и он нужен (в многопоточной среде). Посмотрите на атрибуты акцессоров событий: они отмечены [MethodImpl(MethodImplOptions.Synchronized)], который эквивалентен оборачиванию тела метода в lock(this) { }, однако в C# 4.0 генерируемый код для акцессоров field-like событий изменился, теперь там lock-free реализация подписки/отписки. Не смотря на на то, что делегаты — ref-типы, при подписке два потока могут забрать одну и ту же ссылку, а потом записать свои скомбинированные через Delegate.Combine() делегаты поверх друг друга, поэтому применение += к делегатам не является потокобезопасной операцией.

adontz 31 мар 2010 в 18:14

Смотрю рефлектором и не вижу того, о чём вы говорите. То есть в принципе вы видимо правы, но что-то я с ходу описаной реализации события не нашёл. События FileSystemWatcher, 3.5SP1 есть что.

ControlFlow 31 мар 2010 в 18:20

Определите своё field-like событие и оно там будет, в BCL многие события описаны вручную и не используют синхронизацию, так как по сути многие из них описаны в классам, которые не являются потокобезпасными по спецификации, и им эта синхронизация в акцессорах нафиг не нужна. В случае field-like событий, компилятор C#, по сути, не спрашивая Вас эмитит синхронизацию.

outcoldman 31 мар 2010 в 18:37

По теме
blogs.msdn.com/cburrows/archive/2010/03/05/events-get-a-little-overhaul-in-c-4-part-i-locks.aspx
blogs.msdn.com/cburrows/archive/2010/03/08/events-get-a-little-overhaul-in-c-4-part-ii-semantic-changes-and.aspx
blogs.msdn.com/cburrows/archive/2010/03/18/events-get-a-little-overhaul-in-c-4-part-iii-breaking-changes.aspx
blogs.msdn.com/cburrows/archive/2010/03/30/events-get-a-little-overhaul-in-c-4-afterward-effective-events.aspx

shai_hulud 31 мар 2010 в 17:32

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

andreycha 31 мар 2010 в 17:55

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

ControlFlow 31 мар 2010 в 18:14

К сожалению, действительно всё же существуют ситуации, когда момент отписки не может быть детерминирован и в этих случаях weak events — единственный способ исключить утечки памяти. К примеру, WPF имеет специальные средства для работы со слабыми событиями (см. наследников System.Windows.WeakEventManager), только не сказать что они выглядят удобными :)