Dima TЯ консольные утилиты пишу, хотел поюзать async/await, но не придумал где, зато пришлось наоборот поискать как синхронно запустить xxxAsync().

Ну ясно. Если практика этим заканчивается, async/await вообще здесь не к месту.

LRеще раз (а лучше два или три) перечитываем (эту гребаную) документацию
https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/await An await expression does not block the thread on which it is executing...
и думаем...думаем...думаем...

Это бессмысленно. Если человек себе что-то в голову вбил, и забил на документацию, это бессмысленно.

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

kealon(Ruslan)банальная фраза, она говорит что когда твоя задача занята ожиданием в await, нет никаких гарантий что она блокирует исполняющий её поток и он не может в это время заниматься какими-то другими делами

судя по формулировке "занята ожиданием" пока дошло не до конца :)


kealon(Ruslan)достаточно посмотреть в отладчике нативные вызовы WinRT что бы всё встало на свои места

а уж потом изучать патерны

при чём тут ваши нативные вызовы из WinRT, если async/await это конструкция языка, вы в отладчике await собрались искать?

Dima TТопик ушел в сторону обсуждения реализации async/await в .net, как оно на других ЯП никто не пишет, поэтому топик переезжает в профильный форум.

а так-то однопоточный JavaScript напрямую противоречит первому же ответу в топике
но.. топик охватывает все языки, реализующие паттерн async/await.

Dima TТ.е. ты признаешь что async/await не везде уместны? Тогда уточни где они уместны. Я один кейс обозначил - гуй, а еще где?

В гуе тоже постольку поскольку.

Уместны там, где интенсивно и в большом количестве используются асинхронные операции: доступ к БД, веб-запросы, работа с файлами.

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

На собственном примере, у нас года 3 назад было разработано веб-приложение. В период пиковых нагрузок оно падало на одном сервере. Пришлось масштабировать его на несколько серверов, чтобы решить проблему.

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

Это из практики.

Всё это хорошо, за исключением обозначенных мною проблем в начале топика.

SiemarglА ты уверен, что в текущих ОС, концепция async/await реализуема без многопоточки ?

А при чём тут многопоточка? Один или много потоков, async/await позволяет не блокировать их на время работы i/o операций, в этом основной смысл.


SiemarglМне кажется, что на этом шатком основании ты пытаешься что то доказать.

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

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

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

ВМоисеевзапрос выполняется параллельно с демонстрацией прогресбара

Запрос выполняется синхронно в параллельном потоке. Так как у вас десктопное приложение, которое выполняется монопольно для одного единственного пользователя, вы можете использовать потоки для реализации асинхронного поведения при запросах к БД, при условии, что их относительно не много, и нисколько не пострадать от этого.

SiemarglТы плачешь, что синтакс сахар недостаточно сладкий?!

Я вроде озвучил проблемы в начале топика.

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

Например представь, что он попытается параллелить все операции (а почему бы и нет - выч блоков то у ЦПУ много)

Он не пытается распараллелить async/await, это про другое.

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

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

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

kealon(Ruslan)А вы сходства не видите между WinRT и Net? подставка кода под неочевидные конструкции языка называется compiler magic.
под отладчиком я понимаю WinDbg.

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

kealon(Ruslan)профит получили, а откуда не поняли
тут очень хорошо разжёвывают за счёт чего работают такие вещи

Достали вы меня, в C++ есть async/await? Нету. В С++ можно писать асинхронный код? Можно. И в C# можно было до появления async/await. Вы до сих пор не удосужились почитать ни одного материала по async/await, всё продолжаете смачно фантазировать и отнимать у людей время своими бессмысленными набросами.

Можете ясно и чётко выразить свою мысль? Вы чего хотите донести? Я исходные данные в начале топика озвучил, при чём тут ваша отладка, при чём тут C++?

Вы хотите сказать, что async/await это бессмысленная конструкция? Помятуя ответ в этом топике от MasterZiv, на который вы неоднократно ссылались, это выглядит так. Ну тогда для чего этот паттерн ввели в нескольких языках? Может они просто тупые и вас забыли спросить? Ну не смешите людей уже своими глупостями. Либо выражайтесь яснее, либо не отнимайте время у людей.

kealon(Ruslan)никак не противоречит, но об этом пока говорить рано

Рано, потому что вы ещё не почитали и не ознакомились с информацией? Ну подождём, че уж.

kealon(Ruslan)PS: Вера это конечно прикольно, но при споре об устройстве системы с системщиком её одной мало. Cкрины из системного отладчика были бы гораздо убедительнее

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

Petro123у меня не вышло оставить логику.
Унаследованный проект и вызов бд, сервиса был глубоко в стеке из 10 методов.

Древний легаси исправить на использование a/a почти невозможно, нужно всё переписывать :)

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

Сейчас проекты пишутся async-first. Всё хорошо. Раньше использовать асинхронность было тяжело из-за неудобного апи, поэтому большинство забило на это болт и просто запускали потоки. Сейчас стало возможно писать такой код в полный рост, но вылезли две проблемы, о которых я напомню:

1. слишком частое употребление ключевого слова await, где я пока не вижу причин, почему компилятор не мог бы вывести его сам (в async-блоке это просто явно и очевидно).

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

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