S-type
Нет уж... Я - простой смертный средний программист. И уже написал асинхронную функцию, и она уже прекрасно работает!

Если бы это было так, то, очевидно, не пришлось бы на форуме задавать вопросы
А пока что, видимо, не хватает знаний и сноровки, и шпага таки не проглотилась, а застряла где-то на пол-пути Продолжишь тренировки - несомненно научишься. Конечно если тебе это (асинхронные/параллельные алгоритмы/код) таки необходимо

Всё прекрасно работает. Да, были проблемы на этапе разработки

---

Начал читать книжку Алекса Дэвиса "Асинхронное программирование". Книжка не нравится...

Я совсем не по делу)
Изучать пробовать - это здорово, и правильно.
А так. Модный тренд. Если здраво помыслить, очень редко необходимый.
И то что МС его везде продвигает, это все го лишь их политика.
Которая отчасти сбивает с толку "слабо характерных" программистов.
ИМХО

Аспид
Если здраво помыслить, очень редко необходимый.

На самом деле не "очень" и даже вообще не "редко".

Бэкэнд (серверная часть, сервисы) должен быть асинхронным (чтобы быть более-менее масштабируемым и не жрать ресурсы как не в себя).
Общение фронтэнда (клиентского приложения) с бэкэндом (сервисами, или хотя бы чисто БД) должно быть асинхронным.
И даже чистое WinForms приложение самостоятельно что либо "считающее" и ни с кем "внешним" не общающееся тоже должно быть асинхронным (чтобы не висеть в тупом состоянии "Not Responding" пока проходит любой расчёт).
Через многопоточность (т.е. вручную созданные потоки или хотя бы обёртки типа BackgroundWorker) - да, можно реализовывать - но это более многословно и гораздо менее экономно.

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

Аспид
А так. Модный тренд. Если здраво помыслить, очень редко необходимый.
И то что МС его везде продвигает, это все го лишь их политика.

Не могу согласиться. Та же Гугл продвигает Dart ru.wikipedia.org. С habrahabr.ru взял пример:

Цитата:

someFunction() async {
var someVar = await functionXXL();
if (someVar == someParam) {
// Делаем что-то.
} else {
// Делаем что-то.
}
}

Если не знать, что это Dart, можно подумать - что это C#.

Аспид
Которая отчасти сбивает с толку "слабо характерных" программистов.
ИМХО

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

Была программа (точнее, WEB-сервис), исправно работала. Понадобилось сохранять в файл запросы, отправляемые по SOAP. Если делать синхронно, то пока на диске будет создаваться файл - программа будет ждать. Потому - сделал асинхронно.



Исправлено 1 раз(а). Последнее : S-type, 19.08.17 01:30

По поводу C# 7.1:


Асинхронный Main. Работает!

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

Igor Korolyov
На самом деле не "очень" и даже вообще не "редко".

Игорь, написанное тобой, стандартное "восхваление" await and asinc
И нет спора по поводу

Igor Korolyov
WinForms приложение самостоятельно что либо "считающее"

Ясное дело, повешу надпись, "подождите идет расчет"
Под асинхронностью, часто понимается как многопоточность.
Но асинхронность работает исключительно через Task который от Thread Pool.
И на самом деле просто ставится в очередь, и ждет своей.
И потоки ты не контролируешь. Она просто позволяет делать что то другое, пока выполняется этот поток.

Я наверное больше от asp.net отталкиваюсь.
Вот есть Ajax. И его польза очевидна и понятна.
Так перегружая какую то часть страницы, вывешиваю на это время предупреждение.
Что с await?
Нет сомнений, он полезен. Изредка.
Как правило требуя каких то данных, они мне нужны для дальнейшей работы.
Что делать пока они не получены?

Это 1 аспект. 2й то что эти await здорово грузят клиентский комп.
Не помню уже. Была где то статья, с примерами и критикой.
Не проверял, но поверил)

Я вовсе не против. Я о том, что обдумывать надо.
Наверное модное ныне SPA без этого никуда)
А серьезную вычислительную задачу, надо делать по настоящему многопоточной, с получением результатов, уведомлений от потоков и т.д.

Аспид
Игорь, написанное тобой, стандартное "восхваление" await and asinc

Вовсе нет. Я не восхваляю, я лишь говорю что не "очень редко" это нужно. Конечно же не всегда, и, что ещё более важно, применять нужно с умом и с полным пониманием что к чему и как работает.

Аспид
Ясное дело, повешу надпись, "подождите идет расчет"

Ты не понимаешь... Даже фокс реализует определённую асинхронность в потоке обработки UI - только тяжёлый SQL запрос приведёт к "неотзывчивости" приложения. В шарпе же если ты "пригрузил" основной поток WinForms приложения - всё, прога "висит", окно не рисуется и вообще "всё очень плохо". Без BackgroundWorker или "ручных" потоков по сути нереально было делать приложения - чуть потяжелее расчёт, и всё "висит", юзер пугается, ещё и система норовит снять подвисшее приложение.

Аспид
Под асинхронностью, часто понимается как многопоточность.
Но асинхронность работает исключительно через Task который от Thread Pool.
И на самом деле просто ставится в очередь, и ждет своей.
И потоки ты не контролируешь. Она просто позволяет делать что то другое, пока выполняется этот поток.

Не совсем так... Асинхронность НЕ связана с многопоточностью и с параллельностью. Она МОЖЕТ работать через многопоточность (в зависимости от настроек Task-а, в т.ч. способа его создания и используемого "планировщика"), но может вообще не выходить за рамки одного единственного "основного" потока.
Для асинхронности связанной с IO операциями дополнительные потоки на самом деле не нужны. Мы даём команду драйверу (а через него контроллеру) читать/писать на диск/сеть, и пока он это делает (а делает он это не используя ресурсов CPU), спокойно выполняем другую работу. Потом, когда нам нужен результат, мы опрашиваем состояние - завершилась операция или ещё продолжается - может либо тупо ждать, либо пойти выполнять ещё какую-то работу...
По сути эта асинхронность - это просто перестановка блоков кода - написано в одном порядке, а выполняется - в другом. На await-ах получаются "точки разрыва"...
Но да, есть и CPU bound асинхронность - когда "расчёт" запускается асинхронно - тут действительно будет работать отдельный поток из пула. И да, без явного управления "каким именно" потоком очередной кусок задачи обрабатывается (ну так оно и на самом деле не нужно - для того пул и сделан, чтобы не парится созданием/убиением потоков и прочим low-level управлением).

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

Ставить их обработку в continuation, Карл async паттерн как раз для этого и нужен - "логически" ты пишешь код "строго последовательно", а вот исполняется он совершенно не в том порядке в каком написан! То что после await будет работать тогда, когда "результат готов" - а не сразу же после запуска асинхронной операции.

А "основную нить кода" отпускать. Считай что она уходит на READ EVENTS, а все твои мега-вычисления отпочковались и последовательно будут исполняться где-то "рядом". При том continuation настраивается либо на "независимую" жизнь - в произвольном потоке, без синхронизации, без "контекста". Либо на исполнение в "основном" потоке - если нужно дёргать UI контролы, к примеру.

Аспид
Это 1 аспект. 2й то что эти await здорово грузят клиентский комп.
Не помню уже. Была где то статья, с примерами и критикой.
Не проверял, но поверил)

Как и любой другой шаблон проектирования, async позволяет неопытному разработчику отстрелить себе ногу. Именно поэтому я и не устаю повторять - хочешь это использовать - ТЩАТЕЛЬНО изучи все нюансы. Иначе да, получишь тормознутое, зависающее и уродливое решение.

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

Можно и так, "вручную". Только 90% подобных задач (точнее их "служебной" части - управление потоками, и т.п.) в итоге будут написаны примерно так же как написан в самом фреймворке Task, и его инфраструктура. Правда для этого нужен на порядок более "прошареный" (и потому "дорогой") разработчик, чем для того чтобы просто грамотно использовать TPL и async-и

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