Зачем нужны async/await? В чём вообще смысл асинхронности? Т.е я понимаю:

есть GUI, который работает в основном потоке. Есть кнопка, при нажатии на которую происходит вызов метода HardWork(). Без многопоточности и вызова HardWork() в новом потоке GUI бы зависал на время выполнения HardWork(). Тут всё понятно. Есть более высокоуровневая оболочка в виде класса Task(ну и ещё эффективней использует потоки, берёт их из пула и прочие прелести). Позволяет писать +- адекватный код, в котором нет разделяемых состояний. Окей. Ключевое слово async пишут, чтобы await не путался с идентификатором. конструкция await SomeMethodAsync() разворачивается в var awaiter = SomeMethodAsync().GetAwaiter(); awaiter.OnCompleted{ var result = awaiter.GetResult(); ... остальные операторы }. Тут тоже всё понятно. Но такой вопрос, зачем это всё? Ведь по сути все уже "готовые" асинхронные функции нужно ждать сразу же. Ну например HttpResponseMessage response = await client.GetAsync("uri"); Может быть могли бы обьяснить? Привести примеры, где ждать не нужно.

Чтобы не зависала твоя программа

Ты можешь и не ждать, или ждать в другом месте

Не могли бы вы привести пример, когда можно не ждать? Единственное, что у меня в голове сходится это методы с возвращаемым значением void, но для них можно просто вызвать было бы Task.Run(() => Method()) и забыть. И что на счёт ждать в другом месте?

Когда таски друг на друга не влияют, в разной области. Тогда можно например запустить 2 таски и ждать потом var a = Run1(); var b = Run2(); var t1 = await a; var t2 = await b;

Ага, спасибо. Стало немного понятней.

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

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

Спасибо большое )

Даже не асинхронные методы контролеров будут работать при одновременном получении нескольких запросов от разных клиентов)

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

Ооо, хороший кстати пример

Почему ждать сразу же. Есть Task.WhenAny и Task.WhenAll, например. Ну и там соль не столько GetAwaiter и OnCompleted, там SynchronizationContext.Current.Post() В зависимости от реализации контекста либо в тот же поток уходит продолжение, либо в тред пул, либо создаётся новый, либо напиши свой. Таким образом, есть высокоуровневый API, не зависящий от реализации работы с потоками, плюс синтаксический сахар, чтобы без callback-hell'ов.

Спасибо большое! Про контекст синхронизации нужно побольше значит почитать, потому что не очень понял вообще зачем он. WhenAny вообще странная штука. Запускаешь 5 тасков и извлекаешь результат из той, которая выпонилась первая. Ничего кроме как запустить несколько методов, которые делают одно и тоже, но по-разному реализованы я больше не придумал (и то на стадии разработки). А про контекст синхронизации нужно лучше значит будет почитать, потому что в книге об этом не было ничего вроде бы )

https://docs.microsoft.com/en-us/archive/msdn-magazine/2011/february/msdn-magazine-parallel-computing-it-s-all-about-the-synchronizationcontext Вот статья, которую все рекомендуют. WhenAny очень нужная штука, когда есть большая очередь задач, и нужно их выполнять "максимально параллельно" (с лимитом по количеству одновременно выполняемых или занимаемой памяти, например). Ждёшь, когда любая выполнилась, смотришь не превышен ли лимит, достаёшь ещё одну из закромов и ставишь на выполнение.

А, да. Хороший пример) Понятно теперь зачем Task.WhenAny. Извините возможно за глупые вопросы, я только учусь и ещё даже нигде не работал в этом направлении. Поэтому с реальными примерами туговато )

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