Ich habe seit einiger Zeit async / hazard verwendet, aber in letzter Zeit tiefer geforscht und viele Best-Practice-Tipps gelesen, in denen standardmäßig ConfigureAwait (false) verwendet wird, um Deadlocks zu verhindern und die Leistung zu verbessern. Ich will nur sicher gehen, dass ich etwas nicht verpasse, wenn ich annehme, dass das nur gilt, wenn es sich um einen aktuellen SynchronizationContext oder TaskScheduler im Spiel handelt, richtig? Wenn ich eine Windows-Dienst-App habe, die auf Nachrichten / Befehle / etc reagiert. asynchron verwendet es immer nur den Standard scheduler = wahrscheinlich den gleichen threadpool thread, auf den der supportet on ausgeführt wird, führt die Fortsetzung aus, daher kann kein Deadlock und kein Leistungsunterschied bei der Verwendung von ConfigureAwait (false) auftreten, richtig? Es ist nicht so, dass ich es nicht sagen kann, aber ich hasse Geräuschcode so sehr ...
Im Allgemeinen ist dies wahr. Wenn Sie in einem Console- oder Serviceszenario arbeiten, ist SynchronizationContext nicht installiert ( standardmäßig ), so dass die continueOnCapturedContext -Option in ConfigureAwait keine Auswirkung hat, dh Sie können sie ohne es entfernen Ändern des Laufzeitverhaltens.
Es kann jedoch Ausnahmen geben, daher würde ich oft vorschlagen, Ihren Code inklusive ConfigureAwait(false) bei Bedarf zu schreiben.
Die Hauptvorteile, diese sogar in einer Konsole oder einer Dienstanwendung zu integrieren, sind:
SynchronizationContext installieren (oder eine Bibliothek verwenden, die installiert), ändert sich das Verhalten Ihrer Methoden nicht. Tags und Links c# asynchronous