Console/Win服務應用程序中不需要ConfigureAwait（false），對吧？

我一直在使用異步/等待，但最近深入研究，並閱讀了很多最佳實踐技巧，默認情況下總是使用ConfigureAwait（false）來防止死鎖並提高性能。只是想確保我不會錯過某些東西，當我認爲這隻適用於當前正在播放的實際當前SynchronizationContext或TaskScheduler時，是正確的？如果我有一個響應消息/命令/等的Windows服務應用程序。異步地，它總是使用默認調度程序=可能是相同的線程池線程，等待完成的線程將執行延續，因此使用ConfigureAwait（false）時沒有死鎖和性能差異，是正確的嗎？這不是我不能把它放在那裏，但我討厭這麼多噪音代碼...Console/Win服務應用程序中不需要ConfigureAwait（false），對吧？

來源

2014-09-12 Martin Sykora

最好你應該編寫模塊化的代碼，並不在乎它是否在控制檯，windows服務，ASP.NET網站或窗口項目中運行（所以你應該把它放在因爲你的代碼可以在需要它的情況下運行），但有時你會知道它不會在這些情況下使用（所以不可以，你不應該把它放進去）。它是編碼風格的問題。 – 2014-09-12 22:23:28

一般來說，這是真的。在控制檯或服務方案中工作時，沒有安裝SynchronizationContext（默認爲），因此ConfigureAwait中的continueOnCapturedContext選項將不起作用，這意味着您可以在不更改運行時行爲的情況下安全地將其刪除。

但是，可能會有例外，所以我經常會建議在適當的時候編寫代碼，包括ConfigureAwait(false)。

包括本即使在控制檯或服務應用程序的主要優點是：

的代碼變爲在其他應用中可重複使用後。如果您選擇重複使用此代碼，則無需追蹤由於不包含此問題而導致的錯誤。
如果您正在運行時安裝（或使用安裝庫）SynchronizationContext，則方法的行爲不會改變。

來源

2014-09-12 22:26:15

Console/Win服務應用程序中不需要ConfigureAwait（false），對吧？

回答

相關問題