Kann ConfigureAwait (false) in einer Bibliothek den Synchronisierungskontext für die aufrufende Anwendung verlieren?

Question

Ich habe den Rat viele Male von Leuten gelesen, die klüger sind als ich, und es hat wenige Vorbehalte: Verwenden Sie immer ConfigureAwait(false) innerhalb der Bibliothek Code. Ich bin mir ziemlich sicher, dass ich die Antwort kenne, aber ich möchte 100% sein. Das Szenario ist Ich habe eine Bibliothek, die einige andere asynchrone Bibliothek dünn umschließt.

Bibliothek Code:

public async Task DoThingAsyc() { 
    // do some setup 
    return await otherLib.DoThingAsync().ConfigureAwait(false); 
} 

Anwendungscode:

// need to preserve my synchronization context 
await myLib.DoThingAync(); 
// do I have my context here or did my lib lose it? 

Answer 1

Nr

Die Erfassung des SynchronizationContext auf await geschieht. ConfigureAwait konfiguriert die spezifischen await.

Wenn die Anwendung eine Async-Methode einer Bibliothek aufruft und sie erwartet, wird der SC an Ort und Stelle erfasst, unabhängig davon, was innerhalb des Aufrufs geschieht.

Nun, da das synchrone Teil des Asynchron-Verfahrens (das ist der Teil vor den ersten await ist) ausgeführt wird, bevor eine Aufgabe abgewartet werden zurückgegeben, können Sie Kampf mit den SynchronizationContext da, aber ConfigureAwait tut das nicht.

---

In Ihrem speziellen Beispiel scheinen Sie das Ergebnis ConfigureAwait von der Asynchron-Methode zurückkehrt zu werden. Das kann nicht passieren, weil ConfigureAwait die Struktur ConfiguredTaskAwaitable zurückgibt. Wenn wir jedoch den Methodenrückgabetyp ändern:

Dann wird erwartet, dass es in der Tat das abwarten Verhalten des aufrufenden Codes beeinflussen wird.

Answer 2

Beispiel von http://blogs.msdn.com/b/pfxteam/archive/2012/01/20/10259049.aspx

... logisch können Sie aus dem folgenden Code denken:

await FooAsync(); 
RestOfMethod(); 

wie in der Natur zu diesem ähnlich ist:

var t = FooAsync(); 
var currentContext = SynchronizationContext.Current; 
t.ContinueWith(delegate 
{ 
    if (currentContext == null) 
     RestOfMethod(); 
    else 
     currentContext.Post(delegate { RestOfMethod(); }, null); 
}, TaskScheduler.Current); 

die bedeutet, dass Sie Ihren Kontext nach derzurück haben solltenAnruf.

Answer 3

Wenn ConfigureAwait(false) inkonsistent in der logischen Kette von Async-Aufrufen verwendet wird, können redundante Kontext-Switches hinzugefügt werden (was normalerweise redundante Thread-Switches bedeutet). Dies kann bei Vorhandensein eines Synchronisationskontextes passieren, wenn einige asynchrone Aufrufe des logischen Stapels ConfigureAwait(false) verwenden und einige nicht (mehr here).

Sie sollten noch ConfigureAwait(false) in Ihrem Code verwenden, aber Sie können in die 3rd-Party-Code spähen möchten Sie anrufen und mildern Unstimmigkeiten mit etwas wie folgt aus:

public async Task DoThingAsyc() { 
    // do some setup 
    await Task.Run(() => otherLib.DoThingAsync()).ConfigureAwait(false); 
    // do some other stuff 
} 

Dies würde einen zusätzlichen Thread hinzufügen wechseln, aber möglicherweise viele andere verhindern.

Außerdem, wenn Sie eine wirklich dünne Hülle sind die Schaffung wie Sie zeigte, können Sie es wie unten zu implementieren, ohne async/await überhaupt:

public Task DoThingAsyc() { 
    // do some setup 
    return otherLib.DoThingAsync(); 
}