Запуск события из фонового потока для взаимодействия с основным

Доброго всем времени суток!

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

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

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

Буду признателен за любой совет!

0

amr-now, речь не о том где выполнится задача в await, а в том, что будет в это время с методом в котором этот await присутствует. А будет только одно: метод не будет исполняться, пока задача в await не завершится. Параллельное же исполнение не заставляет метод ожидать окончания запущенной задачи.

0

Сообщение от Usaga в том, что будет в это время с методом в котором этот await присутствует

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

0

amr-now, так я и не говорил, что прибита.

0

Сообщение от Usaga Да. Просто запускается поток. Код в этом методе не будет дожидаться завершения этого потока. Это параллельность, не асинхронность.

Вы назвали метод, который гарантированно выполняется в 1 потоке, параллельным. Ваша терминология - мутная .

Сообщение от Usaga Никакой ошибки. Асинхронный код не параллельный.

Одно другому не мешает.

Сообщение от amr-now Товарищи, я единственный не вижу разницы между двумя методами?

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

Назначение второго метода - создать "горячую" таску. Когда этот метод возвращает управление, есть гарантия, что эта задача уже создана. Поэтому я назвал его синхронным.

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

Зачем вызывающему знать про синхронность/асинхронность метода? Чтобы, например, писать такой код:
Или такой:
Причем первый вариант нельзя использовать, если WriteString обладает свойством асинхронности. То есть имеет хоть малейший шанс вернуть управление до вывода своей строки.

Сообщение от Usaga Не обратил внимание на TaskScheduler.FromCurrentSynchronization Context(). Лямбда выполнится в текущем потоке ПОСЛЕ того как завершится обработчик метода.

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

0

Сообщение от TopLayer Вы назвали метод, который гарантированно выполняется в 1 потоке, параллельным. Ваша терминология - мутная

Я не сразу увидел настройку для шедулера. Я потом на это указал.

Сообщение от TopLayer Одно другому не мешает.

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

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

У вас два метода идентичны и только названием отличаются) Вопрос был именно об этом)

Сообщение от TopLayer Я знаю когда что выполнится. Вы дайте ответ на вопрос об асинхронности этого метода. Судя по вашему определению, он не является асинхронным, но и гарантии, которые дает синхронный код, он тоже не предоставляет. Может, из практических соображений, вы измените свое определение асинхронности?

Этот метод не асинхронный. Всё, что он гарантирует - что лямбда выполнится в этом же потоке, но уже после этого метода и бог знает когда.

0

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

0

Usaga, https://en.wikipedia.org/wiki/... rogramming)

Asynchrony, in computer programming, refers to the occurrence of events independent of the main program flow and ways to deal with such events. These may be "outside" events such as the arrival of signals, or actions instigated by a program that take place concurrently with program execution, without the program blocking to wait for results.

И что я сразу не догадался загуглить определение

0

TopLayer, гуглоперевод доставляет.

Обычный способ борьбы с асинхронностью

Да-да. Именно этим мы и занимаемся

Добавлено через 2 минуты
----
Хотя в английской Википедии определение явно плохое и не соответствует описанию ситуации.

0

Сообщение от amr-now Хотя в английской Википедии определение явно плохое и не соответствует описанию ситуации.

Поясните

0

Что-то нашел.
C# 6.0
IN A NUTSHELL
Joseph Albahari & Ben Albahari

What is Asynchronous Programming? The principle of asynchronous programming is that you write long-running (or potentially long-running) functions asynchronously. This is in contrast to the conventional approach of writing long-running functions synchronously and then calling those functions from a new thread or task to introduce concurrency as required. The difference with the asynchronous approach is that concurrency is initiated inside the long-running function, rather than from outside the function.

То есть по мнению Албахари примерно так: конкурентность = параллелизм + асинхронность.

Есть "long-running function" - "рабочий код".
И есть авианосец, с которого взлетает этот "рабочий код".
В new Thread() и в Task.Run() мы этот авианосец расписываем в открытом виде, пиная рабочий код в отдельный thread.
А с помощью await мы запускач "рабочего кода" тщательно маскируем.

Но это всё равно не совсем полное определение. Потому что существует Event-based Asynchronous Pattern, который обходится без await. И при этом он истинно асинхронный в самом догматическом понимании.

Добавлено через 11 минут
----
Грубо говоря, общая проблема в наши дни не в определении формулировки.
А в том, что "рабочий код" возвращает единственный результат и генерит единственное событие своего завершения, на которое подписывается await.
Второй вариант - есть гипотетическая цепочка событий, состоящая из конечного числа элементов (что-то где то завершилось или вернуло результат).
Третий вариант - гипотетическая цепочка событий, состоящая из бесконечного числа элементов, не планирующая никогда по своей воле завершаться.
Вот как раз третью цепочку целиком не дождешься. Два предыдущих варианта полностью дождаться можно.

Добавлено через 12 минут
-----------
Показали пример, что на событие завершения Task можно повесить несколько подписчиков. Прикольно.
А await приспособлен для единственного подписчика.

0

Сообщение от amr-now конкурентность = параллелизм + асинхронность.

Не, мне кажется не так, concurrency с англ. - и есть параллельность, параллелизм.
Асинхронность - отсутствие ожидания = то есть это либо синхронное выполнение (если кусок логики достаточно короткий) + либо параллельное, если задача действительно занимает поток на достаточное долгое время , а нам нельзя по каким-то причинам его долго занимать на эту задачу

is that concurrency is initiated inside the long-running function

Добавлено через 1 минуту
Если авианосцу плыть достаточно близко, то он сам поплывет, если далеко, то он пнет какой-нибудь истребитель.
Лично я так вижу эту картину, надо как-нибудь поглубже покопаться в TPL, чтобы уж действительно в деталях.

0

На Хабре спрашивают: "А почему в рунете отсутствует формулировка конкурентности?"
Ответ: "Да просто забили. Не надо никому было."
Хотя буржуи очень даже отличают конкурентность от параллелизма.
https://wiki.haskell.org/Paral... oncurrency

Хотя интересная картина маслом, оказывается можно использовать технологию, в принципе никак её не называя.

1