Gobzo KoblerЕсли асинхронные вызовы все равно выполнаются в текущей нитке, в чем глубокий смысл?

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

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

Gobzo KoblerРаботаю с несколькими чужими веб проектами где везде суют асинхронное исполнение. Накой? Все равно браузеру ждать ответа.

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

А «Все равно браузеру ждать ответа» это верно, быстрее работа с СУБД или файлами от этого не станет, но драгоценные ресурсы при этом экономятся. Т.е. другими словами, клиенты не ждут, когда освободится поток, который тупо ждёт когда там база данных раздуплится.

Gobzo KoblerИ чё мы выиграли?

В данном случае мы видим, что мы пишем в XmlWriter, но маленькими порциями, это не значит, что все эти операции обязательно будут I/O операциями, данные пишутся в буффер, когда буффер наполнится, он скидывается на диск, и только в этот момент происходит I/O операция, которую не хотелось бы ждать и блокировать поток. Проблема в том, что мы не знаем КОГДА этот буфер наполнится, а управлять буффером вручную не хотелось бы. Поэтому ВСЕ эти маленькие операции должны выполняться с помощью конструкций асинхронного вызова.

Фишка в том, что ты не можешь в методе, который был вызван синхронно (т.е. без await), выполнить асинхронный вызов через await когда тебе вздумается, и чтобы это имело под собой обозначенный профит. Нет, не можешь. Поэтому ВЕСЬ код, который собирается выполнять I/O операции хоть где-то, должен быть async. Конечно, ты можешь в любой момент вернуться с одной из старых моделей для асинхронных вызовов, от чего как раз все уходят. На событиях, делегатах, специальных интерфейсах :)

Модератор: Тема перенесена из форума "Программирование".

Petro123Код действительно некрасивый.
Нужно делать асинронным сам объект.

Что некрасивого? Можно прокидывать делегат с синхронным кодом внутрь асинхронного, но нафига эти костыли?

Petro123Нужно без этого слова но асинхронно.

код в студию

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

не могут, не передаётся CancellationToken

Petro123Он тот же без слов await в каждой строке.
Сам класс xmlWriter внутри накапливает в буфер и другим потоком выполняет.
Т.е. 15 строк пробегут мгновенно.
Больше ничего не надо. Всё внутри xmlWriter.

угу, вместо одного, ты два потока сожрёшь. ясно

Gobzo KoblerКакую-такую "другую работу"? Обрабатывается HTTP запрос, ему нужен XML созданный обработчиками. Что еще он может "делать" пока создается XML по кусочкам?

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

Gobzo KoblerНе на диск, а в Response.

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

Gobzo KoblerhVostt,

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

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

Gobzo Koblerа следовательно HttpRequest и XmlWriter, поддержанные "в заду" MemoryStream, все равно в моем примере будут полоть процессор и никакого выигрыша от асинхронности не будет. по моему все таки разрабам надо думать головой, а не тухесом и отличать ожидание ответа накопителя или сетевого адаптера от пересылки байтов из буфера в буфер.

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

следовательно, XmlWriter у вас никуда не пишет чтоли? нет асинхронных операций там? фейк и финт ушами с мемористрим?

думать головой надо, с этим сложно не согласиться. только мало говорить о том, что надо думать головой. надо ещё и думать головой :)

Petro123это забота другого уровня. Причём тут прикладной код?
Веб сервер, если идёт запрос и нет свободного потока запускает новый).
Ты тут со своим кодом причём?

при том, что ты не понимаешь о чём речь. может пойдёшь и почитаешь? )

ВМоисеевЕсли ...async Task... есть метод UserControl, то Вы считаете, что нельзя удалить uc, вызвав Children.Remove(uc) в обработчике Click?

и каким образом процесс прервётся?

ВМоисеевНе будет объекта с методом - некому будет выполнять работу.

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

Petro123ну дак и ты не врубаешься)

во что, в твои фантазии? ))


Petro123именно. Тут АСИНХРОННЫЕ ОПЕРАЦИИ НЕ НУЖНЫ.
Поэтому выигрыша не будет.

Petro123там есть. А снаружи нет и не нужно.
Инкапсуляция ООП.

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

давай не тупи.

maytonТут кейс неудачный. Вот если-б было 2 DAO. И мы ожидаем отклика от обоих что данные значить
агрегировать и отдать на UI. Тогда и польза была-б очевидна. Наподобие Callable/Future в Java.

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

Petro123Может на пальцах дойдёт?
Тебе ТС сказал что Ослик ждёт ответа, к примеру 0,2 сек.
За это время твой код должен сформировать XML и отдать в выходной поток.
Тут не нужна асинхронность).
Или ты XML клеишь за пол часа?

хотел было ответить на глупость, но..

Petro123заставь дурака богу молиться.

ты сам себе ответил. долбись лбом об стену дальше )

ВМоисеевФормулировка вопроса - Если асинхронные вызовы все равно выполнаются в текущей нитке, в чем глубокий смысл?

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

ВМоисеев


**ТЬ, это НЕ АСИНХРОННО. это засрать ещё +1 поток, вы чё издеваетесь? за это время можно было уже 2 языка программирования выучить, дом построить, детей вырастить. а вы всё простую концепцию осилить не можете.

может смените профиль? ну не ваше, ну не даётся математика 2+2 вам.

ВМоисеев,

то, что вы делаете, а это запуск параллельного потока с ожиданием в потоке, делается с помощью BackgroundWorker, за каким хреном вы сюда тащите async/await, если вы не эвейтите IO операции, а тупейшим образом создаёте ожидание в отдельном потоке.

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