iRumba 10 фев 2017 в 05:18

События и потоки. Часть 1

6 мин

23K

.NET * C# *

+10

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

mayorovp 10 фев 2017 в 07:20

И в чем же преимущество EventHandler<> над Action или MyDelegate?

Есть и еще способ — создать новый класс, унаследованный от Delegate или MulticastDelegate, но это уже для совсем специфичных случаев. Фактически, способ 2 это и делает за кулисами.

Как вы вообще это себе представляете?
error CS0644: 'ExampleHandler' cannot derive from special class 'MulticastDelegate'

iRumba 10 фев 2017 в 07:26

Я ведь в конце об этом написал. Смотрите на класс AsyncEventsHelper. Такой фокус бы не удался при использовании Action или MyDelegate. А в большинстве случаев (по моим личным наблюдениям) данный способ оповещения вполне подходит.

Считайте это упрощением работы событий для частного случая. Но дело в том, что этот частный случай встречается чаще других при разработке.

mayorovp 10 фев 2017 в 07:29

При использовании Action<> с одним параметром такой фокус делается столь же просто.

iRumba 10 фев 2017 в 07:30

Да, а что если одно событие у вас принимает string, а другое int?

mayorovp 10 фев 2017 в 07:32

Если событие что-то возвращает — то у него, во-первых, не может быть более 1 подписчика — а во-вторых, нам в любом случае надо дождаться результата. В итоге никакой AsyncEventsHelper попросту не нужен.

werwolfby 10 фев 2017 в 07:42

Может быть несколько подписчиков, просто результут вернётся только из последнего

mayorovp 10 фев 2017 в 07:45

Неявно забытое возвращаемое значение — это ошибка. Если его старались-возвращали — значит, оно кому-то было нужно.

werwolfby 10 фев 2017 в 07:48

Оно не забытое оно потерянное :)
Но конечно впринципе использовать события для возврата значения хоть и известная практика, но она плохая именно по этой причине.

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

iRumba 10 фев 2017 в 07:46

я же исправил. принимает а не возвращает… или имеет аргументы если хотите…

mayorovp 10 фев 2017 в 07:47

Я ответил до того как вы исправили.

lair 10 фев 2017 в 07:33

Дженерик же.

iRumba 10 фев 2017 в 07:45

Ну хорошо, а если надо больше аргументов события? В этом случае вам придется либо на каждое количество аргументов писать отдельный дженерик метод, либо делать свою собственную реализацию EventArgs, но зачем, если она уже есть?

mayorovp 10 фев 2017 в 07:49

Реализация EventArgs:

[Serializable]
[System.Runtime.InteropServices.ComVisible(true)]
public class EventArgs {
    public static readonly EventArgs Empty = new EventArgs();

    public EventArgs() 
    {
    }
}

Да, действительно, написать свой собственный аналог этого класса — так сложно!

Вы понимаете, что у приведенного вами же класса MyEventArgs можно "оторвать" базовый тип — и от этого ничего не изменится (после перехода на Action)?

iRumba 10 фев 2017 в 07:57

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

mayorovp 10 фев 2017 в 07:58

Вообще-то, это был мой вопрос.

А зачем? Зачем использовать EventHandler-то?

iRumba 10 фев 2017 в 07:59

Ну да… это как вопрос «а зачем мне использовать готовый велосипед, я изобрету свой»… Да пожалуйста

mayorovp 10 фев 2017 в 08:01

Почему стандартный класс Action<> называется велосипедом? С каким пор ключевое слово delegate стало признаком велосипеда?

iRumba 10 фев 2017 в 08:10

Класс Action<> не является велосипедом. Только в данном случае он неуместен. Это как «string1» + «string2» + «string3».

lair 10 фев 2017 в 08:11

Класс Action<> не является велосипедом. Только в данном случае он неуместен.

Почему?

lair 10 фев 2017 в 07:58

Чтобы не писать EventHandler вокруг одного строкового значения.

lair 10 фев 2017 в 07:52

Ну хорошо, а если надо больше аргументов события?

Берется любой класс, в чем проблема-то?

iRumba 10 фев 2017 в 07:58

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

lair 10 фев 2017 в 08:00

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

Задача неполна, поэтому и решения ей быть не может. Если вам надо fire-and-forget — берете очередь и пишете в нее, все остальное вас не волнует.

iRumba 10 фев 2017 в 08:13

Так… Задача вполне конкретна. у меня есть генератор событий, который принимает хандлер типа EventHandler TEventArgs и с ним работает. А в случае с Action<> у вас будет 19 таких генераторов по количеству разновидностей Action. То есть
для Action

для Actionдля Action<T, T>
и тд до 18 аргументов

lair 10 фев 2017 в 08:16

Задача вполне конкретна. у меня есть генератор событий, который принимает хандлер типа EventHandler и с ним работает. А в случае с Action<> у вас будет 19 таких генераторов по количеству разновидностей Action.

Неа. Я просто ограничу "события" Action<T> и все.

(собственно, в Rx так и сделано)

iRumba 10 фев 2017 в 08:17

А что у вас будет в качестве T?

lair 10 фев 2017 в 08:19

В смысле "будет ли он ограничен"? Нет, не будет. Зачем?

iRumba 10 фев 2017 в 08:27

в смысле какого типа аргумент будет иметь ваше событие

lair 10 фев 2017 в 08:34

Ну так от события зависит. Если у меня конкретное событие принимает строку, будет Action<string>, если http-запрос — Action<HttpRequestMessage>, ну и так далее.

iRumba 10 фев 2017 в 09:42

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

Action<object, MyClass>

Action — это тоже делегат. и казалось бы, почему бы тогда не использовать его?

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

SomeNetEventHandler: EventHandler<SomeNeteventArgs>

и тут мой универсальный метод будет кстати. Я ответил на ваш вопрос?

lair 10 фев 2017 в 09:52

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

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

Action<object, MyClass>

Достаточно Action<T>, где T определяется каждым событием, либо Action<TSource,TArgs>, если я хочу передавать источник.

Вы, кстати, не представляете себе, как меня достал object sender в стандартных событиях.

Что, если вы захотите породить событие, описанное где то в дебрях фрэймворка?

Напишу адаптер: (Action<T>) (T args) => handler(this, args).

Другое дело, что не захочу.

Я ответил на ваш вопрос?

Эээ, простите, какой вопрос?

iRumba 10 фев 2017 в 10:06

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

Само собой, но можно вообще не дать никаких данных тогда. Сказать что чего то изменилось, пусть обработчик сам выясняет что именно. :)

Достаточно Action<T>, где T определяется каждым событием, либо Action<TSource,TArgs>, если я хочу передавать источник.

Вы, кстати, не представляете себе, как меня достал object sender в стандартных событиях.

Почему же не представляю? Представляю. Но иногда за универсальность приходится платить.
Иногда один обработчик может использоваться для аналогичных событий разных типов. И если породитель события нам в данном случае не интересен, то object sender мы оставим без внимания, а вместо этого обработаем аргументы события.

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

lair 10 фев 2017 в 10:08

Но иногда за универсальность приходится платить.

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

werwolfby 10 фев 2017 в 07:23

Вы же вкурсе что на каждый Begin<Method> должен быть свой End<Method>? ;)

iRumba 10 фев 2017 в 07:30

Я в курсе, что есть такой функционал. Нужно это для ожидания завершения и получения результата. Но ИвентХандлеры возвращают void. Поэтому, если дожидаться выполнения работы обработчика нам не нужно, использовать EndInvoke незачем.

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

mayorovp 10 фев 2017 в 07:35

Вообще-то, метод EndInvoke еще и освобождает ресурсы!

Если вам не нужен результат — то существует очень простое решение:

var d = (EventHandler<T>)delegates[i];
d.BeginInvoke(sender, e, d.EndInvoke, null);

А пропускать вызов End-метода не следует.

iRumba 10 фев 2017 в 08:31

Согласен. Спасибо за инфу. Сейчас поправлю статью.

lair 10 фев 2017 в 07:37

Поэтому, если дожидаться выполнения работы обработчика нам не нужно, использовать EndInvoke незачем.

Угу.

"No matter which technique you use, always call EndInvoke to complete your asynchronous call." (MSDN)

werwolfby 10 фев 2017 в 07:38

Для начала можно почитать документацию: https://msdn.microsoft.com/en-us/library/2e08f6yc(v=vs.110).aspx
Вот цитата с доки:

No matter which technique you use, always call EndInvoke to complete your asynchronous call.

Далее если спросить у гугла, то вам явно ответят на stakcoverflow, что таки да, вы ОБЯЗАНЫ вызывать EndInvoke.

Есть исключение в WinForms приложенях, там вызывать EndInvoke не обязательно, но об этом тоже явно написано в документации.

lair 10 фев 2017 в 07:32

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

Круто, а теперь ответьте на свой же вопрос: в каком потоке выполняется событие?

Вот, значит, кто-то подписал на ваше событие две сотни обработчиков. Сколько будет потоков? Откуда они возьмутся? А откуда они возьмутся при втором вызове того же события?

Колбэк в данном примере нам не нужен.

Агу. А что будет, если в обработчике возникнет ошибка (exception кто-то бросит)?

iRumba 10 фев 2017 в 07:38

Круто, а теперь ответьте на свой же вопрос: в каком потоке выполняется событие?

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

Вот, значит, кто-то подписал на ваше событие две сотни обработчиков. Сколько будет потоков? Откуда они возьмутся? А откуда они возьмутся при втором вызове того же события?

Я на старте еще написал, что речь тут не про потоки, а про события в контексте потоков. Я тут не занимался разруливанием потоков. Если вам необходимо рулить пулом, шелдером или еще чем, поищите информацию сами. Я лишь дал идею.

Агу. А что будет, если в обработчике возникнет ошибка (exception кто-то бросит)?

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

        static void Raiser_CounterChanged(object sender, EventRaiserCounterChangedEventArgs e)
        {
            Console.WriteLine(string.Format("OldValue: {0}; NewValue: {1}", e.OldValue, e.NewValue));
        }

lair 10 фев 2017 в 07:44

Так вот в моем примере каждый обработчик выполняется в отдельном потоке.

Так в каком же?

Я на старте еще написал, что речь тут не про потоки, а про события в контексте потоков. Я тут не занимался разруливанием потоков. Если вам необходимо рулить пулом, шелдером или еще чем, поищите информацию сами. Я лишь дал идею.

Так вот, без знания ответов на эти вопросы ваша идея опасна.

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

Так что же будет, если обработчик не обработает ошибку, и она из него вылетит?

iRumba 10 фев 2017 в 07:50

Так в каком же?

В новом

Так вот, без знания ответов на эти вопросы ваша идея опасна.

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

Так что же будет, если обработчик не обработает ошибку, и она из него вылетит?

Тут все зависит от того, пытается ли обработчик лезть в другие потоки. Если он тихонечко работает в своем конткесте, то с больше долей вероятности он просто упадет и никому об этом не расскажет :)
Если вам все таки хочется об этом узнать, оборачивайте операции обработчика в try catch

lair 10 фев 2017 в 07:57

В новом

Откуда он взялся? Какой у него оверхед?

Есть такое правило большого пальца, что постоянное создание новых потоков — это большое зло.

Идея тут не может быть опасна.

Может, может (я даже не буду приводить очевидные примеры). В вашем случае идея выглядит как "а давайте запустим все обработчики каждый в своем потоке". Первый же вопрос к это идее — это что делать, если обработчиков очень много.

Тут все зависит от того, пытается ли обработчик лезть в другие потоки.

Почему? Какая разница?

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

Так с большой долей вероятности или гарантированно? А не может так случиться, что он упадет и погребет все приложение?

iRumba 10 фев 2017 в 08:18

Есть такое правило большого пальца, что постоянное создание новых потоков — это большое зло.

Я с вами согласен, но к теме данной статьи это не относится

Может, может (я даже не буду приводить очевидные примеры). В вашем случае идея выглядит как «а давайте запустим все обработчики каждый в своем потоке». Первый же вопрос к это идее — это что делать, если обработчиков очень много.

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

Почему? Какая разница?

Потому что это не обсервер

Так с большой долей вероятности или гарантированно? А не может так случиться, что он упадет и погребет все приложение?

Не имеет значение… обработка ошибок обработчика событий — дело обработчика событий а не их генератора.

lair 10 фев 2017 в 08:20

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

iRumba 10 фев 2017 в 10:33

Да не продвигаю я в статье никакой подход. Я только на конкретном примере показываю, как все это работает. Прочитав данную статью, человек, который никогда не задумывался о том, где выполняются обработчики событий, должен это понять. А как использовать это знание — уже его дело.

lair 10 фев 2017 в 10:41

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

Для этого достаточно двух фраз: "Обработчики событий — это делегаты. Делегаты выполняются там, откуда их вызвали".

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

Sane 10 фев 2017 в 07:35

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

mayorovp 10 фев 2017 в 07:37

BeginInvoke на делегате тоже использует поток пула, нет никакого отличия от ThreadPool.QueueWorkItem

Запоминание SynchronizationContext в событиях — отдельная проблема, решение которой больше этого поста раза в два :)

iRumba 10 фев 2017 в 07:40

Я уже ответил на прошлый коммент по этому поводу. Пул потоков не относится к теме данной статьи. Вы можете рулить задачами с шелдером… да чем угодно. Я только предложил идею, как универсализировать систему событий и объяснил где и как работают обработчики

ijsgaus 10 фев 2017 в 07:50

Использовать механизм event в многопоточной среде… Скажем так, один из лучших способов стрельнуть себе даже не в ногу, а в голову. На мой взгляд, event — введенный в язык сахар для обслуживания ui. Более безопасный и управляемый способ — IObservable (+ Reactive Extensions FromEventPattern как переходник). После этого имеем все радости управляемой многонитевой подписки с реактивным потоком событий.

iRumba 10 фев 2017 в 07:53

События и обсерверы имеют разные области применения. Использовать паттерн «наблюдатель», на мой взгляд, имеет смысл, когда генератору событий нужно знать, кто ожидает оповещений и/или выбирать, кому отправить данное оповещение, а кому нет. Мне вот сбербанк отправляет информацию о моих операциях, а вам о моих не отправляет… зато отправляет о ваших… Вот хороший пример обсервера.

lair 10 фев 2017 в 07:57

Использовать паттерн «наблюдатель», на мой взгляд, имеет смысл, когда генератору событий нужно знать, кто ожидает оповещений и/или выбирать, кому отправить данное оповещение, а кому нет.

Вообще-то в Observables источник данных понятия не имеет, кто на него подписан.

iRumba 10 фев 2017 в 08:24

Вообще-то в Observables источник данных понятия не имеет, кто на него подписан.

Не в случае с .net

https://msdn.microsoft.com/ru-ru/library/dd990377(v=vs.110).aspx

mayorovp 10 фев 2017 в 08:29

И что вы хотели этим сказать? Да, разумеется, поставщик имеет ссылки на всех подписчиков. Но он не может отличать их друг от друга. Точно так же как и в делегатах. Отличие-то в чем?

iRumba 10 фев 2017 в 14:55

Может. Точнее имеет возможность. Это уже вопрос реализации. У IObserver нет метода Subscribe. А это значит что способ подписки остается на усмотрение программиста.

lair 10 фев 2017 в 14:59

У IObserver нет метода Subscribe. А это значит что способ подписки остается на усмотрение программиста.

… способ подписки в Rx вполне известен: observable.Subscribe(observer). Никакого "усмотрения программиста".

Но какое это имеет отношение к тому, знает ли источник данных о том, кто на него подписан?

lair 10 фев 2017 в 08:33

… и чем это отличается от обычных событий? Тем, что делегатов три, а не один?

(Не говоря уже о том, что типовой случай работы с Observable — это функциональное преобразование, где финальные подписчики никому никогда видны не будут.)

Вот, значит, мой код (который источник данных):

    private Subject<string> _messageReceived = new Subject<string>();

    public IObservable<string> MessageReceived => _messageReceived.AsObservable();

    public void ReceiveMessage(string message)
    {
        _messageReceived.OnNext(message);
    }

А вот потребитель:

messager.MessageReceived.Where(s => s.Length > threshold).Throttle(..)...

И много у источника данных возможностей узнать, что с сообщением происходит?

iRumba 10 фев 2017 в 14:56

Зачем вы привели пример, в котором не дали эту возможность? :)

lair 10 фев 2017 в 15:00

Затем, что это один из стандартных способ работы с observables в .net. И, что характерно, все остальные тоже устроены так, что источник данных (observable) отвязан от получателя (observer) и знает о нем только и исключительно интерфейс.

Так что ну да, попробуйте привести другой пример, где observable будет как-то различать своих подписчиков.

mayorovp 10 фев 2017 в 08:00

Вы путаете шаблоны "наблюдатель" и "публикация/подписка".

iRumba 10 фев 2017 в 08:25

Вы путаете шаблоны «наблюдатель» и «публикация/подписка»

Я как раз их не путаю

MonkAlex 10 фев 2017 в 08:53

А зачем по потоку на события? Обычно обработка события в одном потоке — наоборот ожидаемое поведение.
Единственное логичное исключение — UI. Но тогда всегда можно явно запустить событие в диспатчере от UI потока.

iRumba 10 фев 2017 в 09:48

Незачем. В универсальном методе, который я предложил, для этого можно не BeginInvoke вызывать, а создать новый поток, в котором вызывать Invoke. Я же написал, статья не про работу с потоками, а про то, в контексте каких потоков выполняются события. К сожалению не все знают ответ на этот вопрос

lair 10 фев 2017 в 09:54

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

Вообще-то, на этот вопрос нет формально верного ответа. События выполняются в том потоке, в котором вызывающая сторона сочла нужным их вызвать. Или вы спрашиваете, в каком потоке выполняется делегат во время вызова? Ну так это, в общем-то, очевидно: при вызове Invoke — в вызывающем потоке. При вызове BeginInvoke… на этот вопрос и вы ответа не дали пока.

iRumba 10 фев 2017 в 10:14

Вообще-то, на этот вопрос нет формально верного ответа. События выполняются в том потоке, в котором вызывающая сторона сочла нужным их вызвать.

В статье сказано:

В общем обработчики события в примере выше выполняются в потоке, порожденном в методе DoWork(). То есть при генерации события, поток, который его сгенерировал таким образом, дожидается выполнения всех обработчиков.

То есть я указал на приведенный мною пример. Я не стал обобщать, потому что именно различные реализации этого примера я чаще всего вижу в чужом коде. И вот это обобщение, которое вы привели — верное, но без разбора конкретного примера не всем будет понятно. Джуниоров намного больше, чем мидлов и сеньеров. И кода в общем объеме они выдают больше.

Или вы спрашиваете, в каком потоке выполняется делегат во время вызова? Ну так это, в общем-то, очевидно

К сожалению не для всех это очевидно.

При вызове BeginInvoke… на этот вопрос и вы ответа не дали пока.

Как не дал то? написал же что порождаются новые потоки.

lair 10 фев 2017 в 10:16

К сожалению не для всех это очевидно.

Знаете, людям, которым неочевидно, в каком потоке вызывается делегат, надо идти обратно учиться. Простите за прямоту.

Как не дал то? написал же что порождаются новые потоки.

Вот только это неправильный ответ.

Я повторю свой пример: вот у нас есть событие, на него подписано двести обработчиков. Мы дважды вызвали это событие. Сколько потоков будет создано?

iRumba 10 фев 2017 в 10:29

Знаете, людям, которым неочевидно, в каком потоке вызывается делегат, надо идти обратно учиться. Простите за прямоту.

Согласен. Нас вот в универе не учили работе с потоками. Выходит, приходится заниматься самообразованием. Для этого есть курсы, книги и подобные статьи.

Вот только это неправильный ответ.

Я повторю свой пример: вот у нас есть событие, на него подписано двести обработчиков. Мы дважды вызвали это событие. Сколько потоков будет создано?

Почему не правильный то?

Количество потоков будет равно Количеству подписчиков умноженному на количество вызовов. В случае с вашими цифрами их будет 400.

Но к чему вообще этот вопрос?

lair 10 фев 2017 в 10:38

Нас вот в универе не учили работе с потоками.

Так это не вопрос работы с потоками, это вопрос работы с делегатами. И это описано в любой книжке про C# и/или CLR.

Почему не правильный то?

Потому что BeginInvoke на делегате выбрасывает делегат в тредпул, а не в новый поток. Со всеми занятными вытекающими.

Количество потоков будет равно Количеству подписчиков умноженному на количество вызовов. В случае с вашими цифрами их будет 400.

… и вы серьезно считаете, что создавать 200 потоков во время вызова события — это нормально? То, что в этот момент вы съели (при настройках по умолчанию) 200мб памяти, вас не смущает?

Но, к счастью, вы не правы. Будет создано не больше потоков, чем задано в тредпуле. А если приложение давно используется, и тредпул уже разогрет — то ни одного.

Но к чему вообще этот вопрос?

К тому, что вы сам, похоже, не понимаете, как работает предлагаемое вами решение.

iRumba 10 фев 2017 в 10:46

Так это не вопрос работы с потоками, это вопрос работы с делегатами. И это описано в любой книжке про C# и/или CLR.

Но статья не про потоки или делегаты!

Потому что BeginInvoke на делегате выбрасывает делегат в тредпул, а не в новый поток. Со всеми занятными вытекающими.

Вы лезете в дебри. Возьмите 200 ядер и ваши потоки выполнятся в раз.

… и вы серьезно считаете, что создавать 200 потоков во время вызова события — это нормально? То, что в этот момент вы съели (при настройках по умолчанию) 200мб памяти, вас не смущает?

Нет я так не считаю, я уже написал об этом раз 10.

К тому, что вы сам, похоже, не понимаете, как работает предлагаемое вами решение.

В работе с потоками я прикрылся за абстракциями. Мне не важно, как отработает пул. Мне важны 2 вещи:
1. Обработчики будут выполняться параллельно (да, на самом деле все не совсем так и одновременных потоков будет по количеству ядер, свободной памяти и тд, но я не раскрываю данную абстракцию в этой статье. Именно поэтому я и говорю, что для вашего примера потоков будет 400, ведь я потребовал от системы генерацию 400 потоков)
2. Породитель событий не будет дожидаться их выполнение и продолжит свою работу.

Зачем вы пытаетесь мне сказать, что я неправильно работаю с потоками, если я в начале статьи сказал, что я неправильно с ними работаю и статья не о них?

lair 10 фев 2017 в 10:56

Но статья не про потоки или делегаты!

А про что же она, если события — это делегаты, и вы рассказываете, как устроены/работают делегаты, и спрашиваете, на каком потоке делегат выполнится?

Вы лезете в дебри.

Это не дебри, это самые что ни на есть азы.

Возьмите 200 ядер и ваши потоки выполнятся в раз.

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

Нет я так не считаю, я уже написал об этом раз 10.

Тогда зачем вы предлагаете такое решение?

В работе с потоками я прикрылся за абстракциями.

Нет, вы написали "BeginInvoke порождает новый поток". Это не абстракция, это конкретное — и ложное — утверждение.

Мне не важно, как отработает пул.

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

Зачем вы пытаетесь мне сказать, что я неправильно работаю с потоками, если я в начале статьи сказал, что я неправильно с ними работаю и статья не о них?

Затем, чтобы (а) вы не понимаете, что неправильно работете с потоками и (б) я не хочу видеть пример неправильной работы с потоками.

Именно поэтому я и говорю, что для вашего примера потоков будет 400, ведь я потребовал от системы генерацию 400 потоков

Это как раз пример того, что вы не понимаете происходящего. Сделав 400 BeginInvoke вы не потребовали от системы генерацию 400 потоков.

Lofer 10 фев 2017 в 11:10

Я бы рекомендовал ознакомиться вот с этим материалом.
MCTS Self-Paced Training Kit (Exam 70-536)
Если мне не изменяет память там было достаточное описание, для основ. (Chapter 7
Threading, Lesson 3: The Asynchronous Programming Model )
После без проблем «поверх ляжет» await & async

iRumba 10 фев 2017 в 15:14

Да вы сами похоже не понимаете что происходит.

Это не дебри, это самые что ни на есть азы.

Так разберитесь с ними сами прежде всего.

Нет, вы написали «BeginInvoke порождает новый поток». Это не абстракция, это конкретное — и ложное — утверждение.

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

Затем, чтобы (а) вы не понимаете, что неправильно работете с потоками и (б) я не хочу видеть пример неправильной работы с потоками.

Это как раз пример того, что вы не понимаете происходящего. Сделав 400 BeginInvoke вы не потребовали от системы генерацию 400 потоков.

Класс Thread в принципе не является потоком. Это обертка. Абстракция.
Говоря поток, я имею ввиду Thread. Говоря «порождает» поток, я имею ввиду создает Thread и дает ему команду «Пуск». Так вот, одновременно (почти) создаются 400 экземпляров Thread. Когда они будут выполняться, генератору событий не важно. Ему даже не важно, будут ли они вообще выполняться, или лягут с ошибкой. Обработка событий не входит в его компетенцию. Вы со своими заумными фразами про потоки забыли про принципы ООП!
Теперь что касается этих 400 потоков. Да, я просто кинул их бездумно в пул. Ну так мне не важно, как, когда и в каком порядке они будут выполняться и программа больше ничего не делает. Я не могу в этом случае рассмотреть каждый случай отдельно, поэтому ПРАВИЛЬНОГО решения тут нет и быть не может! Для случая, когда потребуется соблюдать порядок, я создам очередь из задач (или шелдер). Для случая, когда выполнение других потоков будет важнее, я укажу приоритет для этих событий ниже. Зато, если я не вынесу порождение событий в отдельный от воркера поток, мне придется снижать приоритет всего воркера по отношению к другим потокам. Но это уже тема не для джуниоров и я не стал включать это все в статью!
А вы тут обсуждаете абстрактного коня в вакууме, и при этом ругаетесь на моего коня. Мой конь круче!

lair 10 фев 2017 в 15:26

Говоря «порождает» поток, я имею ввиду создает Thread и дает ему команду «Пуск». Так вот, одновременно (почти) создаются 400 экземпляров Thread.

Круто, а какие-то основания для этих утверждений у вас есть? Потому что "создать экземпляр класса Thread и сказать ему Start" — это и есть создание нового потока.

Когда они будут выполняться, генератору событий не важно. Ему даже не важно, будут ли они вообще выполняться, или лягут с ошибкой. Обработка событий не входит в его компетенцию.

Это если у вас fire-and-forget, что далеко не для всех событий верно. А вы это почему-то считаете поведением по умолчанию.

Вы со своими заумными фразами про потоки забыли про принципы ООП!

… принципы ООП тут ни при чем.

Теперь что касается этих 400 потоков. Да, я просто кинул их бездумно в пул.

Да нет же. Нельзя кинуть потоки в пул.

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

Отнюдь. Я обсуждаю ваш конкретный код.

iRumba 11 фев 2017 в 03:56

Вот я и говорю что вы сами не понимаете что говорите.

Круто, а какие-то основания для этих утверждений у вас есть? Потому что «создать экземпляр класса Thread и сказать ему Start» — это и есть создание нового потока.

Поток при этом не создается. Потоками пул управляет, а не пользователь. После команды старт происходит запрос на запуск потока (или как то так). Я могу стартануть 400 экземпляров Thread, но реально работать будут при этом только 4 из них (на моем железе и среде).

Это если у вас fire-and-forget, что далеко не для всех событий верно. А вы это почему-то считаете поведением по умолчанию.

Ничего не слышал про fire-and-forget для системы событий в .net. Гугл не помог. Подскажите где почитать, потому что в данный момент мне это кажется плохой архитектурой а не особым подходом.

Да нет же. Нельзя кинуть потоки в пул.

Беда с терминологие, походу… я создал 400 экземпляров Thread и сказал им старт.

Отнюдь. Я обсуждаю ваш конкретный код.

Пример с потоками абстрактный… мне, может, нужно было его на псевдо языке написать, чтобы это было понятно?

mayorovp 11 фев 2017 в 04:51

Прочитайте хотя бы документацию!

https://msdn.microsoft.com/ru-ru/library/system.threading.thread(v=vs.110).aspx

Класс Thread
Создает и контролирует поток, задает приоритет и возвращает статус.

lair 11 фев 2017 в 06:52

Поток при этом не создается.

Серьезно? Ссылку на доку вам ниже дали, вот вам еще из Рихтера цитаты.

Во-первых: "So today, a CLR thread is identical to a Windows thread".
Во-вторых: "To actually create the operating system thread and have it start executing the callback method, you must call Thread’s Start method, passing into it the object (state) that you want passed as the callback method’s argument."

Окей, в документацию вы не верите, давайте эксперимент устроим.

Код

        {
            var info = new ConcurrentBag<ThreadInfo>();

            const int howMany = 400;

            Console.WriteLine("For Thread pool:");
            var handles = Enumerable
                .Range(1, howMany)
                .Select(_ =>
                {
                    var manualResetEventSlim = new ManualResetEventSlim();
                    ThreadPool.QueueUserWorkItem(h =>
                    {
                        info.Add(new ThreadInfo
                        {
                            IsThreadPool = Thread.CurrentThread.IsThreadPoolThread,
                            ThreadId = Thread.CurrentThread.ManagedThreadId
                        });
                        Thread.Sleep(500);
                        ((ManualResetEventSlim)h).Set();
                    }, manualResetEventSlim);
                    return manualResetEventSlim.WaitHandle;
                }).ToArray();

            var threads = Process.GetCurrentProcess().Threads.Count;
            Console.WriteLine($"Threads in process: {threads}");

            //не влезаем в максимально допустимое число в WaitAll
            foreach (var handle in handles)
                handle.WaitOne();

            Console.WriteLine($"Invocations: {info.Count}");
            Console.WriteLine($"Different threads ids: {info.Select(i => i.ThreadId).Distinct().Count()}");
            Console.WriteLine($"Count of thread pool threads: {info.Count(i => i.IsThreadPool)}");

            var threadPoolIds = new HashSet<int>(info.Select(i => i.ThreadId));

            Console.WriteLine();
            Console.WriteLine("For Thread:");
            info = new ConcurrentBag<ThreadInfo>();
            handles = Enumerable
                .Range(1, howMany)
                .Select(_ =>
                {
                    var manualResetEventSlim = new ManualResetEventSlim();
                    var thread = new Thread(h =>
                    {
                        info.Add(new ThreadInfo
                        {
                            IsThreadPool = Thread.CurrentThread.IsThreadPoolThread,
                            ThreadId = Thread.CurrentThread.ManagedThreadId
                        });
                        Thread.Sleep(500);
                        ((ManualResetEventSlim)h).Set();
                    });
                    thread.Start(manualResetEventSlim);
                    return manualResetEventSlim.WaitHandle;
                }).ToArray();

            threads = Process.GetCurrentProcess().Threads.Count;
            Console.WriteLine($"Threads in process: {threads}");

            //не влезаем в максимально допустимое число в WaitAll
            foreach (var handle in handles)
                handle.WaitOne();

            Console.WriteLine($"Invocations: {info.Count}");
            Console.WriteLine($"Different threads ids: {info.Select(i => i.ThreadId).Distinct().Count()}");
            Console.WriteLine($"Matching to thread pool thread ids: {info.Select(i => i.ThreadId).Where(threadPoolIds.Contains).Distinct().Count()}");
            Console.WriteLine($"Count of thread pool threads: {info.Count(i => i.IsThreadPool)}");

            Console.WriteLine("");
            Console.WriteLine("For BeginInvoke:");

            info = new ConcurrentBag<ThreadInfo>();
            handles = Enumerable
                .Range(1, howMany)
                .Select(_ =>
                {
                    Action d = () =>
                    {
                        info.Add(new ThreadInfo
                        {
                            IsThreadPool = Thread.CurrentThread.IsThreadPoolThread,
                            ThreadId = Thread.CurrentThread.ManagedThreadId
                        });
                        Thread.Sleep(500);
                    };
                    return d.BeginInvoke(d.EndInvoke, null).AsyncWaitHandle;
                }).ToArray();

            threads = Process.GetCurrentProcess().Threads.Count;
            Console.WriteLine($"Threads in process: {threads}");

            //не влезаем в максимально допустимое число в WaitAll
            foreach (var handle in handles)
                handle.WaitOne();

            Console.WriteLine($"Invocations: {info.Count}");
            Console.WriteLine($"Different threads ids: {info.Select(i => i.ThreadId).Distinct().Count()}");
            Console.WriteLine($"Matching to thread pool thread ids: {info.Select(i => i.ThreadId).Where(threadPoolIds.Contains).Distinct().Count()}");
            Console.WriteLine($"Count of thread pool threads: {info.Count(i => i.IsThreadPool)}");
        }

А вот результат:

For Thread pool:
Threads in process: 15
Invocations: 400
Different threads ids: 9
Count of thread pool threads: 400

For Thread:
Threads in process: 416
Invocations: 400
Different threads ids: 400
Matching to thread pool thread ids: 0
Count of thread pool threads: 0

For BeginInvoke:
Threads in process: 16
Invocations: 400
Different threads ids: 16
Matching to thread pool thread ids: 9
Count of thread pool threads: 400

Во-первых, хорошо видно, что "создать Thread и сказать ему Start" — это именно "создать новый поток": число тредов увеличилось ровно на запрошенное количество, число разных идентификаторов такое же.

Во-вторых, видно, что пул ведет себя иначе: число потоков выросло на 15, но для работы ему вообще хватило девяти.

В-третьих, видно, что BeginInvoke ведет себя, как и ожидалось, идентично пулу (которым он, согласно источникам, и пользуется).

Потоками пул управляет, а не пользователь.

Это если вы используете ThreadPool. А если вы явно создаете Thread, то вы как раз явно управляете потоком. Он для этого и придуман.

После команды старт происходит запрос на запуск потока (или как то так)

Нет, после команды Start создается новый поток, и ему отдается команда на запуск.

Я могу стартануть 400 экземпляров Thread, но реально работать будут при этом только 4 из них

А вот это уже вопрос того, сколько будет работать параллельно, а не сколько будет создано.

Ничего не слышал про fire-and-forget для системы событий в .net.

Fire-and-forget — это такой подход к организации событий, при котором отправителя не интересует ни было ли событие доставлено, ни было ли оно успешно обработано. Это ровно то, что делаете (делали) вы, не обрабатывая результат делегата.

Беда с терминологие, походу… я создал 400 экземпляров Thread и сказал им старт.

Нет. Вы 400 раз вызвали BeginInvoke — который не создает Thread.

Но если бы вы 400 раз сделали new Thread(d).Start() — вы бы получили именно описанное мной поведение.

Lofer 10 фев 2017 в 10:38

Почему не правильный то?

Полагаю, что нюанс в этом: Dispatcher Class

Dispatcher.BeginInvoke Method (Delegate, DispatcherPriority, Object[])
.NET Framework (current version)

Executes the specified delegate asynchronously with the specified arguments, at the specified priority, on the thread that the Dispatcher was created on.
Namespace: System.Windows.Threading
Assembly: WindowsBase (in WindowsBase.dll)

Нас вот в универе не учили работе с потоками.

Это все есть в документации. Согласен что муторно, то иногда надо :)

iRumba 10 фев 2017 в 15:25

Если нас не учили, это не значит, что я не учил. Я говорю про других людей. Опять же я не все знаю и понимаю, но дальше своих знаний я в этой статье не лез. Почти все что тут назвали ошибками является обычной абстракцией (остальное я уже поправил), но я не могу этого объяснить. Слово абстрактный им не знакомо или хотят блеснуть знаниями я не знаю…

Lofer 10 фев 2017 в 10:15

Вроде как за последние лет 20 выработаны достаточно походов к решение многопоточного взаимодействия?
Что-то из уже сделанного не подходит?
Обычно на этапе дизайна уже ищутся ответы на вопросы:

Как должен себя вести родительский поток, если упадет созданный поток ?
Стратегия обработки ошибок ?
Стратегия работы с общими ресурсами ?

Исходя из этого уже и выбирают все events / messages / и т.д.

Полагаю, что проблема тут:

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

Нафига приложение без «TimeOut»? Выжрать все ресурсы в ~~одно рыло~~ один генератор? Так вроде бы вычислительные ресуры то общие (см п3 выше)

А какую проблему то это все должно решить?

iRumba 10 фев 2017 в 10:23

Да, да и еще раз да! Я устал отвечать на одни и те же замечания. Статья не об организации потоков, она просто рассказывает о том, в каких потоках выполняются события. Не все об этом знают. Это для джуниоров. Про организацию потоков я ничего не писал. Для этого одной статьи просто может не хватить из-за количества вариаций.

Lofer 10 фев 2017 в 10:44

в каких потоках выполняются события

Поймите простую штуку: дьявол в деталях.
События не могут «выполняться», события можно вызвать.
А выполняется «Обработчик события».
Это два разных элемента. Когда вы сможете их рассмотреть отдельно, все станет на свои места. Пока Вы будете их рассматривать «связно» вы не получите правильного ответа.
Сам вопрос поставлен не очень корректно: как правильно молотком закручивать шуруп? :)
Правильный ответ: возьмите отвертку.

iRumba 10 фев 2017 в 15:21

Вот, проблемы с терминологией. Заработался, простите. Я то же самое объяснял оратору выше.

lair 10 фев 2017 в 12:01

((EventHandler<T>)delegates[i]).BeginInvoke(sender, e, AsyncCallbackClass<T>.CallBack, null);

//...

static class AsyncCallbackClass<T2> where T2 : EventArgs
        {
            public static void CallBack(IAsyncResult ar)
            {
                var tar = ar as AsyncResult;
                if (tar != null)
                    ((EventHandler<T2>)tar.AsyncDelegate).EndInvoke(ar);
            }
        }

Зачем так сложно, чем вам не угодил прямой вызов EndInvoke?

foreach (EventHandler<EventArgs> handler in h.GetInvocationList())
{
    handler.BeginInvoke(sender, e, handler.EndInvoke, null);
}

mayorovp 10 фев 2017 в 14:10

Более того, его код еще и неверный. Никто не обязывает CLR возвращать какой-то особый публичный AsyncResult...

lair 10 фев 2017 в 14:17

… а если вернут не его, то мы молча пойдем дальше, так и не вызвав EndInvoke. Красота же.

iRumba 10 фев 2017 в 15:18

Спасибо за заметку, сейчас исправлю

lair 10 фев 2017 в 15:27

public static void RaiseEventAsync<T>(EventHandler<T> h, object sender, T e) where T : EventArgs
{
  if (h != null)
  {
    var delegates = h.GetInvocationList();
    for (var i = 0; i < delegates.Length; i++)
      ((EventHandler<T>)delegates[i]).BeginInvoke(sender, e, h.EndInvoke, null);
  }
}

Серьезно?

Yarikz 11 фев 2017 в 03:56

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

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

Более того, ваша реализация упирается в ограничения Thread Pool, и обработчики событий скорее всего выстроятся в очередь, в зависимости от загруженности пула; что еще хуже, пул может начать создавать новые потоки, которые неизбежно снизят производительность.

iRumba 11 фев 2017 в 03:58

Если вам не хочется, чтобы обработчик повесил работу класса, то напишите такой обработчик — это нетрудно.

Генератор события написал я, а обработчик будет делать Вася Пупкин, который ничего не знает про логику работы моего генератора. поэтому, если обработчик будет работать в одном потоке с логикой генератора, это как раз и поставит разработчика в рамки.

mayorovp 11 фев 2017 в 04:53

Да кто такой этот Вася Пупкин, что вы его так боитесь — и одновременно о нем так заботитесь? И что он делает в вашей программе?

Lofer 11 фев 2017 в 09:15

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

Это как раз вас поставит в рамки :) Ваш генератор станет «колом», поскольу ничего не сгенерит, пока обработчик не вернет управление.
Если вы разрабатываете библиотеку «для того парня», вы обязаны продумать API взаимодействия. В частности Вашей задачей будет предоставить и делегаты под обработку и декларацию событий и модель асинхронной работы (Event Based, Task Based и т.д).
В общем случае не ваша забота, как будут обрабатываться ваши события и по какой модели. Даже если вы сделаете «просто один поток» то обработчики сами себе придумают как быстро вернуть управление генератору.
Вопрос только в том — генератору нужен результат «обработчика или нет».

НЛО прилетело и опубликовало эту надпись здесь

Зарегистрируйтесь на Хабре, чтобы оставить комментарий