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

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

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

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

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

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

0

NapalmRain, что у WinForms, что у WPF для этого есть встроенные средства: Control.Invoke и Dispatcher.Invoke.

0

Сообщение от Usaga что у WinForms, что у WPF для этого есть встроенные средства: Control.Invoke и Dispatcher.Invoke.

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

0

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

Не хотите обращаться к контролами через Invok, есть другой, менее известный, подход - SynchronizationContext. Получаете текущий контекст (в GUI потоке), передаёте его коду, который должен что-то выполнить в GUI-потоке. Всё. Никакой завязки на UI.

1

Usaga, премного благодарен за разъяснения

0

NapalmRain, изучите интерфейс IProgress с классом Progress. И тогда не надо тяжких мучений.
https://docs.microsoft.com/ru-... attern-tap

Microsoft предложила всему мировому сообществу программистов на удивление правильную идею Task Asynchronous Pattern.
Так что чем больше прочитаете в блогах авторов данного паттерна (Стивен Тауб, Стивен Клири и другие),
тем больше будет понимания в смысле вот этого вот всего. Самое смешное, что придет понимание и в других языках программирования.

0

amr-now, асинхронность не заменяет многопоточности. Всё-таки разные вещи. А вот что класс Progress умеет имеет ивенты вызывать в контексте синхронизации я не знал.

0

Usaga, а Вы можете слёту дать определение асинхронности?

Чем больше думаю об этом, тем больше склоняюсь к определению, что асинхронность - разрыв единой непрерывной ленты исполнения инструкций на отдельные независимые куски. Каждый отдельный кусок называю "рабочий код". Кто-то называет "Job".
А как конкретно выполнять эти куски кода, имеет меньшее значение.
Можно:
- рядом на одной машине одновременно.
- на разных машинах одновременно.
- на одной машине как попало по очереди.

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

0

amr-now, это разделение потока исполнения на последовательность блоков кода, исполняющихся строго в том же порядке, в котором они идут в коде, как будто синхронно. Эти блоки могут исполнять в одном потоке (последовательно), но с разнесением по времени, или в другом потоке, но с сохранением порядка исполнения.

Смотрите на это как на событийную модель. По факту, это оно и есть. У вас работает код, встречает инструкцию await, запускает другую задачу (это не обязательно будет отдельный поток), подписывается на её завершение, сохраняет текущий контекст (в полях специально сгенерированного компилятором автомата) и отправляется выполнять какие-то другие дела. Когда запущенная задача завершится, на свет божий поднимется озвученный ранее автомат в котором сохранено прошлое состяние и исполнение продолжится с места, где мы преравлись ранее.

Т.е. это будет выглядеть так:
Ваш код А -> другая задача -> Ваш код Б -> Другая задача -> Ваш код В.

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

Почему это не подходит для задачи озвученной ТС-ом? Потому, что запускаемая задача должна завершиться полностью прежде, чем асинхронный метод сможет продолжить работу. У ТС-а же долгоиграющая задача, которой нужно репортовать о прогрессе своей работы. Это значит, что не можно сделать над такой задачей await, нарисовать её прогресс на UI, а потом продолжить await'ить тот же самый кусок кода.

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

Примерно:
Станет таким:
Как видите, код сильно изменится и не в лучшую сторону. И это только при работе ОДНОГО фонового потока. Если их будет несколько, то начнётся возня с объединением Task'ов и await'ы уже этого дела.

Более того, await'ы в циклах не есть хорошо. Это не бесплатная операция.

Асинхронный код хорош своей краткостью и чистотой решений. А такая чистота достигается, когда вам из UI (или потока из пула ASP.NET) надо дёрнуть атомарную задачу, которая отработает и уйдёт в закат. Без всяких возобновляемых состояний.

Т.е. асинхронность никак и ничем не заменяет распараллеливание. Просто некоторые сценарии становится возможно исполнять более элегантно. С фоновыми задачами асинхронность никак не дружит и насильно их сдруживать не надо.

2

Сообщение от Usaga на свет божий поднимется

0

Usaga, сейчас перечитал Ваше сообщение. Мы с Вами пока одинаково очень плохо понимаем формулировку асинхронности.
Пытаюсь понять. Действительно, очень много переплетено с механизмом событий. Говоря философским языком, async/await и события являются изнанкой друг друга.
Народ всё пытается нащупать что и где лучше применить - TPL Dataflow, Rx или накостылить то же самое с async/await, или попытаться найти применение для AsyncEnumerator.
Очень много споров на эту тему и на Хабре и т.д.

0

amr-now, я действительно не смогу дать чёткое определение. Но

Сообщение от amr-now TPL Dataflow, Rx или накостылить то же самое с async/await

... всё-таки разные вещи. Поддержка асинхронности в языке никак не заменяет многопоточность. Выше я попытался объяснить почему: не все сценарии возможно заасинхронить элегантным образом. Не стоит носиться с этой фичей как с новой приоритетной игрушкой. Если вам нужно какие-то атомарные задачи пинать и чтобы выглядело синхронно? async\await вполне может подойти. Нужна длительная фоновая операция? Асинхронность тут не в кассу.

Всё просто.

0

Это как давать определение текстовому файлу, который под капотом обычный бинарь. У меня свой вариант ->
Асинхронность - свойство кода возвращать управление до завершения вменяемой ему операции. Примеры:
Все три метода асинхронно выполняют операцию по выводу строки на экран. Но асинхронным является только первый метод.

0

TopLayer, асинхронным является только метод CreateHotTask2 ибо последовательность выполняемых инструкций в его коде сохраняется в строгом порядке: сначала код до await, потом код в самом await, потом код после. Т.е всё исполняется как будто синхронно.

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

0

Сообщение от Usaga асинхронным является только метод CreateHotTask2

Ну это по вашему определению...

Сообщение от Usaga То, что они Task возвращают асинхронности им не добавляет.

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

Сообщение от Usaga amr-now, это разделение потока исполнения на последовательность блоков кода, исполняющихся строго в том же порядке, в котором они идут в коде, как будто синхронно. Эти блоки могут исполнять в одном потоке (последовательно), но с разнесением по времени, или в другом потоке, но с сохранением порядка исполнения.

Получается, следующий код не является асинхронным?

Сообщение от Usaga исполняющихся строго в том же порядке, в котором они идут в коде, как будто синхронно.

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

0

Usaga, TopLayer, поэтому я как крымчанка и дочь офицера и говорю, что с параллельным программированием и асинхронным программированием не всё так однозначно.

Эту тему можно годами изучать...

0

Сообщение от TopLayer Ну это по вашему определению...

Не совсем. Первые два метода работают синхронно. Без каких-либо нюансов. Это обычные методы. Последний заменяется компилятором на работу со структурой, представляющую собой автомат и содержащий все состояния этого метода: блоки кода разделённые операторами await. Эта структура эмулирует синхронное выполнение кода в методе, но с переключениями контекста потоков на время выполнения тасок в await. Это и есть асинхронный метод.

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

Ещё раз: в первых двух методах никакой асинхронности нет. Там просто запускается задача в потоке из пула. И задача эта исполняется параллельно коду в этих методах. Просто методы короткие. В последнем же методе, код "останавливается" на всех await'ах, пока задача в этом await'е не закончится. Т.е. код после await запустится по событию завершения задачи (или выбросится исключение, если что пошло не так). Огромная разница между этими методами. Вообще ничего общего.

Сообщение от TopLayer Получается, следующий код не является асинхронным?

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

Сообщение от TopLayer Вот тут ошибка. Это признак отсутствия параллельности, а не критерий асинхронности.

Никакой ошибки. Асинхронный код не параллельный. Так что всё верно. Инструкции в таком методе идут строго в том же порядке, что и описаны в теле метода. Код после await исполнится не раньше, чем завершится операция в операторе await. И не важно в каком потоке она будет исполнена.

amr-now, да, это разные вещи. Они не заменяют друг друга. О чём я и сказал с самого начала. Введение операторов async\await никак не заменяет потоки и потребности в долгих фоновых задачах.

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

0

Товарищи, я единственный не вижу разницы между двумя методами?
Во всех трех методах "рабочий код" () => Console.WriteLine("String") выполняется в виде оторванной бумажки с последовательно исполняемыми инструкциями.
Конкурентность (Concurrency)? Асинхронность? Я пока НЕ понял различия.

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

Без ключевого слова async это самый первичный метод, возвращающий Task.
C ключевым словом async реализуется уже вторичный метод-обертка, метод-декоратор, возвращающий Task.
(Причем оба варианта, вернее четыре с умножением на void, являются составляющими общей концепции Task Asynchronous Pattern.)

На заметку - до первого await любой метод выполняется синхронно. (Опять же - исполнение оторванной бумажки "рабочего кода" не является исполнением метода-запускача этого "рабочего кода").

0

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

У них название разные.

Сообщение от amr-now Конкурентность (Concurrency)? Асинхронность? Я пока НЕ понял различия.

Параллельно с текущим методом или нет. В этом различие.

0

Сообщение от Usaga Параллельно с текущим методом или нет. В этом различие.

Для await абсолютно без разницы, где и когда осуществляется исполнение оторванных бумажек "рабочего кода".
- по очереди в хаотическом порядке.
- одновременно в одном процессе, но в разных threads.
- одновременно в разных процессах одного компьютера.
- одновременно на разных компьютерах.

Но await - это не единственый признак асинхронности. Ещё есть старый добрый Event Asynchronous Pattern (EAP). И даже асинхронный паттерн на функциях обратного вызова, не к ночи они будут упомянуты.

0