C#-async/await-Stolpersteine: Sync-over-Async, async void und ConfigureAwait

Worum es geht

await auf einen unvollständigen Task erfasst den aktuellen SynchronizationContext (oder TaskScheduler) und setzt den Rest der Methode dort fort. Stephen Clearys Best-Practices-Artikel im MSDN Magazine erklärt die Folge: Ist ein UI- oder klassischer ASP.NET-Kontext, der jeweils nur einen Codeabschnitt gleichzeitig ausführt, in Task.Wait() oder .Result blockiert und wartet auf dieselbe Methode, kann die Fortsetzung nie laufen, und das Programm gerät in einen Deadlock; eine Konsolenanwendung gerät nicht in einen Deadlock, weil ihr Kontext, wie der Artikel es formuliert, die Fortsetzung stattdessen im Thread-Pool einplant. ConfigureAwait(false) weist den Awaiter an, nicht im erfassten Kontext fortzusetzen. async void-Methoden haben keinen Task, der eine Ausnahme transportieren könnte, weshalb eine geworfene Ausnahme direkt an den Kontext geht und vom Aufrufer nicht abgefangen werden kann; der Artikel reserviert async void für Event-Handler.

Warum es wichtig ist

ASP.NET Core veröffentlicht keinen SynchronizationContext, was die ConfigureAwait-FAQ als Grund nennt, weshalb ConfigureAwait(false) dort weniger nötig ist, doch Sync-over-Async schadet auf Servern trotzdem: Ein blockierter Thread-Pool-Thread ist nicht verfügbar, und das .NET-Diagnostik-Tutorial beschreibt Thread-Pool-Erschöpfung so, dass der Pool langsam Threads hinzufügt, während Arbeit sich staut und die CPU-Auslastung niedrig bleibt. Entwicklerinnen aus JavaScript, wo das Blockieren auf ein Promise unmöglich ist, und aus Go, wo Blockieren günstig ist, schätzen diese Kosten beide falsch ein.

So wird es angewendet

• Durchgängig asynchron: Sobald eine Methode awaitet, werden ihre Aufrufer bis zum Einstiegspunkt (Controller-Action, Main, Handler) zu async Task. Keinen asynchronen Aufruf in einer synchronen Methode mit .Result einwickeln.
• Task oder Task<T> statt void zurückgeben; async void nur für Event-Handler reservieren, die dann eine Task-zurückgebende Methode mit der eigentlichen Logik awaiten.
• In Bibliothekscode ConfigureAwait(false) bei jedem Await setzen; in Anwendungscode (Controller, UI-Handler, Testmethoden) den Standard belassen. Genau diese Aufteilung nennt die FAQ.
• Task.Run für CPU-gebundene Arbeit verwenden, die vom aufrufenden Thread weg soll, nicht für I/O; die Dokumentation zu asynchronen Szenarien trennt die beiden Fälle.
• Jeden gestarteten Task awaiten; ein fallengelassener Task verbirgt seine Ausnahme. Ein CancellationToken durch jede asynchrone Signatur reichen.

Stolpersteine

Task.Wait und .Result verpacken Ausnahmen in eine AggregateException, während await die erste Ausnahme direkt erneut wirft, wie der MSDN-Artikel zeigt. ConfigureAwait(false) heilt einen Deadlock nicht, wenn irgendein Await in der Kette es nicht gesetzt hat, und die FAQ warnt, dass selbst in ASP.NET Core noch ein eigener Kontext auftauchen kann. Ein async-Lambda, das dort übergeben wird, wo ein Action erwartet wird, wird zu async void. In .NET 9 kennzeichnet das Trace-Event WaitHandleWait Sync-over-Async-Wartezustände, was das Erschöpfungs-Tutorial beschreibt.