Welcher Code wird tatsächlich "multi-threaded" in async/await-Muster ausgeführt?

Question

In diesem Code:

public async Task v_task() 
{ 
    await Task.Run(() => Console.WriteLine("Hello!")); 
} 

public async void v1() 
{ 
    await v_task(); 
    // some other actions... 
} 

public void ButtonClick() 
{ 
    v1(); 

    Console.WriteLine("Hi!"); 
} 

Welche obigen Verfahren tatsächlich parallel ausgeführt werden, in dem Asynchron/await unteren Thread-Pool generiert, wenn Button genannt wird?

Ich meine, was sollte meine Bedenken über Race Conditions mit async arbeiten/erwarten? Alle Async-Methoden müssen im Thread des gleichen Aufrufers ausgeführt werden. Sollte ich Mutex für einen möglichen gemeinsamen Status verwenden? Wenn ja, wie könnte ich feststellen, was die gemeinsam genutzten Zustandsobjekte sind?

Answer 1

Welche der oben genannten Methoden werden parallel im async/away generiert, wenn ButtonClick aufgerufen wird?

Nur die innerhalb der Task.Run.

Ich meine, was sollte meine Bedenken über Race Conditions mit async arbeiten/erwarten?

Ich schlage vor, Sie beginnen mit meinem async intro lesen, die erklärt, wie await tatsächlich funktioniert.

Zusammenfassend, async Methoden werden in der Regel in einer seriell asynchronen Mode geschrieben. Nehmen Sie diesen Code zum Beispiel:

CodeBeforeAwait(); 
await SomeOtherMethodAsync(); 
CodeAfterAwait(); 

Sie immer sagen können, dass CodeBeforeAwait ersten bis zum Abschluss ausgeführt wird, dann SomeOtherMethodAsync aufgerufen.Dann wartet unsere Methode (asynchron) auf SomeOtherMethodAsync, um abzuschließen, und erst danach wird CodeAfterAwait aufgerufen.

So ist es seriell asynchron. Es wird seriell ausgeführt, so wie Sie es erwarten, aber auch mit einem asynchronen Punkt in diesem Fluss (await).

Nun, sie kann nicht sagen, dassCodeBeforeAwait und CodeAfterAwait im selben Thread ausgeführt werden, zumindest nicht ohne mehr Kontext. await wird standardmäßig im aktuellen SynchronizationContext (oder dem aktuellen TaskScheduler, wenn es kein SyncCtx gibt) fortgesetzt. Wenn also die obige Beispielmethode im UI-Thread ausgeführt wurde, wissen Sie, dass CodeBeforeAwait und CodeAfterAwait beide im UI-Thread ausgeführt werden. Wenn es jedoch ohne einen Kontext ausgeführt wurde (d. H. Von einem Hintergrundthread oder einem Console-Hauptthread), kann CodeAfterAwait in einem anderen Thread ausgeführt werden.

Beachten Sie, dass selbst wenn Teile einer Methode in einem anderen Thread ausgeführt werden, die Runtime dafür sorgt, dass Barrieren gesetzt werden, bevor die Methode fortgesetzt wird.

Beachten Sie auch, dass Ihr ursprüngliches Beispiel Task.Run verwendet, die explizit Arbeit auf dem Thread-Pool platziert. Das ist ganz anders als async/await, und Sie werden das Multithread definitiv behandeln müssen.

Sollte ich Mutex auf möglichen gemeinsamen Zustand verwenden?

Ja. Wenn Ihr Code beispielsweise Task.Run verwendet, müssen Sie dies als separaten Thread behandeln. (Beachten Sie, dass es mit awaitLos einfacher ist, den Status überhaupt nicht mit anderen Threads zu teilen - wenn Sie Ihre Hintergrundaufgaben sauber halten können, sind sie viel einfacher zu arbeiten).

Wenn ja, wie kann ich feststellen, was die gemeinsam genutzten Statusobjekte sind?

Gleiche Antwort wie bei jeder anderen Art von Multi-Thread-Code: Code-Inspektion.

Answer 2

Wenn Sie eine asynchrone Funktion aufrufen, wird Ihr Thread diese Funktion ausführen, bis eine Wartezeit erreicht wird.

Wenn Sie async-await nicht verwenden, wird der Thread verarbeitet, bis der erwartete Code beendet ist, und mit der Anweisung nach dem await fortfahren.

Aber wie Sie async-await verwenden, haben Sie dem Compiler gesagt, dass, wenn der Thread auf etwas warten muss, Sie andere Dinge tun können, anstatt zu warten. Der Thread wird diese anderen Dinge tun, bis Sie sagen: Jetzt warte bis deine ursprüngliche Sache beendet ist.

Aufgrund des Aufrufs einer asynchronen Funktion sind wir sicher, dass irgendwo drinnen ein warten sollte. Beachten Sie, dass Sie eine Compiler-Warnung erhalten, dass die Funktion synchron ausgeführt wird, wenn Sie eine asynchrone Funktion aufrufen, die nicht wartet.

Beispiel:

private async void OnButton1_clickec(object sender, ...) 
{ 
    string dataToSave = ...; 
    var saveTask = this.MyOpenFile.SaveAsync(dataToSave); 

    // the thread will go into the SaveAsync function and will 
    // do all things until it sees an await. 
    // because of the async SaveAsync we know there is somewhere an await 
    // As you didn't say await this.MyOpenfile.SaveAsync 
    // the thread will not wait but continue with the following 
    // statements: 

    DoSomethingElse() 
    await saveTask; 

    // here we see the await. The thread was doing something else, 
    // finished it, and now we say: await. That means it waits until its 
    // internal await is finished and continues with the statements after 
    // this internal await. 

Beachten Sie, dass, auch wenn die await irgendwo in SaveAsync fertig war, wird der Faden nicht die nächste Anweisung ausführen, bis Sie SaveTask erwarten. Dies hat zur Folge, dass DoSomethingElse nicht unterbrochen wird, wenn das Warten auf SaveAsync abgeschlossen ist.

Daher ist es normalerweise nicht sinnvoll, eine asynchrone Funktion zu erstellen, die weder einen Task noch eine Task zurückgibt < TResult> Die einzige Ausnahme ist ein Event-Handler. Die GUI muss nicht warten, bis der Event-Handler fertig ist.