2015-09-09 13 views
20

So, hier ist das Szenario:Wenn ich eine asynchrone Methode erwarte, wird sie synchron?

static async void Main(string[] args) 
{ 
    await AnAsyncMethod(); 
} 

private static async task<bool> AnAsyncMethod() 
{ 
    var x = await someAsyncMethod(); 
    var y = await someOtherAsyncMethod(); 

    return x == y; 
} 

Ist „someAsyncMethod“ und „someOtherAsyncMethod“ synchron laufen, weil wir await verwenden, oder sie sind beide asynchron in der Reihenfolge ausgeführt, dass sie ausgeführt werden?

UPDATE

die Antwort unter die besagt, dass die erwartete Asynchron-Methoden laufen nacheinander gegeben, was der Zweck in erster Linie asynchrone Aufrufe der Vornahme dieser Methode wäre, wenn wir gehen, um nur die Ausführung zu stoppen und warten Sie die Rückgabewerte der Methode? Ich habe gesehen, dass native Apps in der Vergangenheit auf async warten, um den UI-Thread freizugeben, aber gibt es noch andere Gründe, warum dieses Design wünschenswert wäre?

+5

kleine Bemerkung am Rande 'Main' kann' nicht await' verwenden als sich als 'async' – Jamiec

+0

oben auf @Jamiec Kommentar nicht markiert, wenn Sie eine andere eine andere Klasse erstellen und dort, dass die Asynchron-Methode setzen, können Sie dann rufen in Ihrer Main-Methode, 'new SomeClass(). AnAsyncMethod.Wait();' und es wird asynchron passieren –

+1

Mein Verständnis ist, dass someAsyncMethod vollständig fertig wäre, bevor SomeOtherAsyncMethod würde beginnen. – Biscuits

Antwort

27

Sie laufen asynchron, aber sequentiell. someOtherAsyncMethod wird erst aufgerufen, wenn someAsyncMethod beendet ist.

Wenn Sie sie parallel ausführen möchten, haben Sie mehrere Möglichkeiten

var taskA = MethodA(); 
var taskB = MethodB(); 

var a = await taskA; 
var b = await taskB; 

// or 

var results = await Task.WhenAll(MethodA(), MethodB()); 

Follow-up-Frage:

ich native Anwendungen in der Vergangenheit Gebrauch gesehen erwarten/async als Mittel, um den UI-Thread freizugeben, aber gibt es noch andere Gründe, warum dieses Design wünschenswert wäre?

In einer ASP.NET-Anwendung, wollen Sie diese verwenden, um dem aktuelle Thread zu ermöglichen, an den Thread zurück zu gehen und andere eingehende Anfragen dienen, während MethodA/MethodB ausgeführt werden - wenn diese Methoden wahr machen asynchrone E/A. Das ist im Grunde der einzige Grund, warum Sie das in einer ASP.NET-App tun würden.

Sie könnten auch Stephen Cleary lesen möchten:

+2

Beachten Sie, dass Sie Task.WhenAll mit mehreren EF-Aufrufen für denselben Kontext nicht verwenden können. Das hat mich schon vorher gebissen. –

+4

Und nicht nur in ASP.NET - in jeder Mehrbenutzer-Server-Anwendung profitieren Sie davon, die Anzahl der Threads gering zu halten. Jeder Thread bedeutet nicht zu vernachlässigenden Speicher und CPU-Auslastung - wenn Sie 4000 Threads haben, haben Sie 4 GiB Speicher (hoffentlich nicht verpflichtet, zumindest) nur auf den Standard-Thread-Stacks verloren. Und da du nur wirklich so viele Threads hast wie du CPU-Cores hast, gib oder nimmst, ist das eine absolut unnötige Verschwendung. Dies gilt insbesondere für eine 32-Bit-Anwendung, bei der sogar die Menge an * virtuellem * Speicher begrenzt ist. – Luaan

+0

@Luaan Danke für den Nachtrag, sehr nützlich! – dcastro

Verwandte Themen