czekają vs Task.Wait - Deadlock?

Nie do końca rozumiem różnicę między Task.Waiti await.

Mam coś podobnego do następujących funkcji w usłudze WebAPI ASP.NET:

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
    }
}

Gdzie Getbędzie impas.

Co może to powodować? Dlaczego nie powoduje to problemów, gdy używam oczekiwania blokującego zamiast await Task.Delay?

Waiti await- choć podobne koncepcyjnie - są w rzeczywistości zupełnie inne.

Waitbędzie synchronicznie blokować do momentu zakończenia zadania. Tak więc bieżący wątek jest dosłownie zablokowany, czekając na zakończenie zadania. Zasadniczo powinieneś używać „do asyncsamego końca”; to znaczy nie blokuj asynckodu. Na moim blogu szczegółowo omawiam, w jaki sposób blokowanie kodu asynchronicznego powoduje zakleszczenie .

awaitbędzie asynchronicznie czekać na zakończenie zadania. Oznacza to, że bieżąca metoda jest „wstrzymana” (jej stan jest przechwytywany), a metoda zwraca swojemu rozmówcy niepełne zadanie. Później, gdy awaitwyrażenie zostanie zakończone, pozostała część metody jest planowana jako kontynuacja.

Wspomniałeś także o „bloku kooperacyjnym”, przez który zakładam, że masz na myśli zadanie, które Waitwykonujesz w oczekującym wątku. Są sytuacje, w których może się to zdarzyć, ale jest to optymalizacja. Istnieje wiele sytuacji, w których nie może się to zdarzyć, na przykład jeśli zadanie jest dla innego programu planującego lub jeśli zostało już uruchomione lub jeśli nie jest to zadanie kodowe (na przykład w twoim kodzie: Waitnie można wykonać Delayzadania bezpośrednio, ponieważ nie ma kodu dla tego).

Pomocne może okazać się moje async/ awaitwprowadzenie .

Na podstawie tego, co przeczytałem z różnych źródeł:

awaitWyrażenie nie blokuje nić, na której jest wykonywany. Zamiast tego powoduje, że kompilator zarejestruje resztę asyncmetody jako kontynuację oczekiwanego zadania. Kontrola następnie powraca do obiektu wywołującego asyncmetodę. Po zakończeniu zadania wywołuje jego kontynuację, a wykonywanie asyncmetody jest wznawiane od miejsca, w którym zostało przerwane.

Aby poczekać na taskukończenie jednego , możesz wywołać jego Task.Waitmetodę. Wywołanie Waitmetody blokuje wątek wywołujący, dopóki instancja jednej klasy nie zakończy wykonywania. Metoda bez parametrów Wait()służy do bezwarunkowego oczekiwania na zakończenie zadania. Zadanie symuluje pracę, wywołując Thread.Sleepmetodę uśpienia na dwie sekundy.

Ten artykuł jest również dobrą lekturą.

Niektóre ważne fakty nie zostały podane w innych odpowiedziach:

„async oczekuje” jest bardziej złożony na poziomie CIL, a zatem kosztuje pamięć i czas procesora.

Każde zadanie można anulować, jeśli czas oczekiwania jest niedopuszczalny.

W przypadku „asynchronicznego oczekiwania” nie mamy modułu obsługującego takie zadanie, aby je anulować lub monitorować.

Korzystanie z zadania jest bardziej elastyczne niż „asynchroniczne czekanie”.

Każda funkcja synchronizacji może być zapakowana przez asynchronię.

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

„async oczekuje” generuje wiele problemów. Nie oczekujemy teraz, że instrukcja zostanie osiągnięta bez debugowania środowiska wykonawczego i kontekstu. Jeśli pierwsze oczekiwanie nie zostanie osiągnięte, wszystko jest zablokowane . Czasami zdarza się, że zdarzenie, które oczekuje, wciąż się kończy, ale wszystko jest zablokowane:

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

Nie rozumiem, dlaczego muszę żyć z duplikacją kodu dla metody synchronizacji i asynchronizacji lub używania hacków.

Wniosek: Utwórz zadanie ręcznie i kontroluj je, jest znacznie lepsze. Handler to Task daje większą kontrolę. Możemy monitorować zadania i zarządzać nimi:

https://github.com/lsmolinski/MonitoredQueueBackgroundWorkItem

Przepraszam za mój angielski.