Warten gegen Task.Warten - Deadlock?

Ich verstehe den Unterschied zwischen Task.Waitund nicht ganz await.

Ich habe etwas Ähnliches wie die folgenden Funktionen in einem ASP.NET-WebAPI-Dienst:

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

Wo Getwird Deadlock.

Was könnte das verursachen? Warum verursacht dies kein Problem, wenn ich eine blockierende Wartezeit anstelle von verwende await Task.Delay?

Waitund await- obwohl konzeptionell ähnlich - tatsächlich völlig unterschiedlich sind.

Waitwird synchron blockiert, bis die Aufgabe abgeschlossen ist. Der aktuelle Thread wird also buchstäblich blockiert, bis die Aufgabe abgeschlossen ist. In der Regel sollten Sie " asyncganz nach unten" verwenden. Blockieren Sie also keinen asyncCode. In meinem Blog gehe ich auf die Details ein, wie das Blockieren von asynchronem Code zu einem Deadlock führt .

awaitwartet asynchron, bis die Aufgabe abgeschlossen ist. Dies bedeutet, dass die aktuelle Methode "angehalten" ist (ihr Status wird erfasst) und die Methode eine unvollständige Aufgabe an ihren Aufrufer zurückgibt. Später, wenn der awaitAusdruck abgeschlossen ist, wird der Rest der Methode als Fortsetzung geplant.

Sie haben auch einen "kooperativen Block" erwähnt, mit dem Sie vermutlich eine Aufgabe meinen, die Sie Waitim wartenden Thread ausführen können. Es gibt Situationen, in denen dies passieren kann, aber es ist eine Optimierung. Es gibt viele Situationen, in denen dies nicht möglich ist, z. B. wenn die Aufgabe für einen anderen Scheduler bestimmt ist oder wenn sie bereits gestartet wurde oder wenn es sich um eine Nicht-Code-Aufgabe handelt (wie in Ihrem Codebeispiel: WaitDie DelayAufgabe kann nicht inline ausgeführt werden, da kein Code vorhanden ist dafür).

Sie können mein async/ awaitIntro hilfreich finden.

Basierend auf dem, was ich aus verschiedenen Quellen gelesen habe:

Ein awaitAusdruck blockiert nicht den Thread, auf dem er ausgeführt wird. Stattdessen veranlasst es den Compiler, den Rest der asyncMethode als Fortsetzung der erwarteten Aufgabe anzumelden. Die Steuerung kehrt dann zum Aufrufer der asyncMethode zurück. Wenn die Aufgabe abgeschlossen ist, ruft sie ihre Fortsetzung auf und die Ausführung der asyncMethode wird dort fortgesetzt, wo sie aufgehört hat.

Um auf den Abschluss eines einzelnen taskzu warten , können Sie dessen Task.WaitMethode aufrufen . Ein Aufruf der WaitMethode blockiert den aufrufenden Thread, bis die Ausführung der einzelnen Klasseninstanz abgeschlossen ist. Die parameterlose Wait()Methode wird verwendet, um bedingungslos zu warten, bis eine Aufgabe abgeschlossen ist. Die Aufgabe simuliert die Arbeit, indem die Thread.SleepMethode zwei Sekunden lang in den Ruhezustand versetzt wird.

Dieser Artikel ist auch eine gute Lektüre.

Einige wichtige Fakten wurden in anderen Antworten nicht angegeben:

"async await" ist auf CIL-Ebene komplexer und kostet daher Speicher und CPU-Zeit.

Jede Aufgabe kann abgebrochen werden, wenn die Wartezeit nicht akzeptabel ist.

Für den Fall "async await" haben wir keinen Handler für eine solche Aufgabe, um sie abzubrechen oder zu überwachen.

Die Verwendung von Task ist flexibler als "asynchrones Warten".

Jede Synchronisierungsfunktion kann asynchron umbrochen werden.

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

Ich verstehe nicht, warum ich mit der Codeduplizierung für die Synchronisierungs- und Asynchronisierungsmethode oder mit Hacks leben muss.