жду vs Task.Wait - тупик?

Я не совсем понимаю разницу между Task.Waitиawait .

У меня есть что-то похожее на следующие функции в службе ASP.NET WebAPI:

public class TestController : ApiController
{
    public static async Task<string> Foo()
    {
        await Task.Delay(1).ConfigureAwait(false);
        return "";
    }

    public async static Task<string> Bar()
    {
        return await Foo();
    }

    public async static Task<string> Ros()
    {
        return await Bar();
    }

    // GET api/test
    public IEnumerable<string> Get()
    {
        Task.WaitAll(Enumerable.Range(0, 10).Select(x => Ros()).ToArray());

        return new string[] { "value1", "value2" }; // This will never execute
    }
}

Где Getбудет тупик.

Что может вызвать это? Почему это не вызывает проблемы, когда я использую блокирующее ожидание, а не await Task.Delay?

Waitи await- хотя схожи концептуально - на самом деле совершенно разные.

Waitбудет синхронно блокироваться, пока задача не будет завершена. Таким образом, текущий поток буквально блокируется в ожидании завершения задачи. Как правило, вы должны использовать « asyncвесь путь вниз»; то есть не блокируйте asyncкод. В своем блоге я подробно расскажу о том, как блокировка в асинхронном коде вызывает тупик .

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

Вы также упомянули «кооперативный блок», под которым я предполагаю, что вы имеете в виду задачу, которую вы Waitвыполняете, может выполняться в ожидающем потоке. Есть ситуации, когда это может произойти, но это оптимизация. Есть много ситуаций, когда это не может произойти, например, если задача предназначена для другого планировщика, или если она уже запущена, или если это не кодовая задача (например, в вашем примере кода: Waitневозможно выполнитьDelay задачу встроенным, потому что нет кода для этого).

Вы можете найти мое async/ awaitвступление полезным.

На основании того, что я прочитал из разных источников:

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

Чтобы дождаться taskзавершения сингла , вы можете вызвать его Task.Waitметод. Вызов Waitметода блокирует вызывающий поток до тех пор, пока один экземпляр класса не завершит выполнение. Метод без параметров Wait()используется для безусловного ожидания завершения задачи. Задача имитирует работу, вызывая Thread.Sleepметод для сна в течение двух секунд.

Эта статья также хорошо читается.

Некоторые важные факты не были приведены в других ответах:

«async await» более сложен на уровне CIL и, следовательно, стоит памяти и процессорного времени.

Любая задача может быть отменена, если время ожидания недопустимо.

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

Использование Task более гибкое, чем «async await».

Любые функции синхронизации могут быть упакованы с помощью async.

public async Task<ActionResult> DoAsync(long id) 
{ 
    return await Task.Run(() => { return DoSync(id); } ); 
} 

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

https://github.com/dotnet/runtime/issues/36063

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

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

https://github.com/lsmolinski/MonitoredQueueBackgroundWorkItem

Извините за мой английский.