微軟開發工具資訊分享

await DoSomethingAsync();

當你寫一行如上的程式碼時，相信大家一看到這一行時都明白背後代表的動機，就是希望這一行程式能以非同步的方式進行．這一行程式碼背後所代表的動作是被 C# compiler 偷偷做掉而大家看不到的．當 C# compiler 遇到這一行時，它會產生一個 “等待器”，這個等待器就是等 DoSomethingAsync() 的結果，此時會有兩種情況，第一種情況是 DoSomethingAsync() 尚未完成，則此等待器將繼續等待，因此下一行的程式碼不會被執行，要一直等到 DoSomethingAsync() 完成之後，才會執行下一行執式碼．另一種情況是 DoSoemthingAsync() 已經完成了，此時等待器便不需要等待，它將會繼續往下一行執行．

相信以上的描述是廣為人知的，接下來將會是有趣的內容．把執行此程式是不是 UI thread 考慮進來的話，將會有一些有趣的討論．先看以下的程式碼:

int a = 1;
await DoSomethingAsync();
int b = 2; 

假設 UI thread 來執行並且 DoSometingAsync() 在等待器還沒開始等待時它本身也完成了，那 int b = 2 會是誰來執行呢 ? 很直覺地想，就是 UI thread．這邊有一個值得討論之處，等待器還沒準備好，為何 DoSomethingAsync() 能完成 ? 是誰去做的 ? 這是 compiler 幫你做的一件隱形工作，它做了 Task Yield，所以有一個來自 ThreadPool 的 thread 去執行了 DoSomethingAsync()．先聲明，這樣子的解釋不太準確，因為還得看 DoSometingAsync() 的內容，但我這邊先假設 DoSomethingAsync() 真的去做了一些 I/O 動作．

假設 UI thread 來執行並且 DoSomethingAsync() 需要好幾秒甚至更久的時間才能完成，此時等待器將等待，而此時 Task 已 Yield 了，所以 UI thread 能去做別的事情．當 DoSomethingAsync() 完成之後，等待器將會決定該如何進行下一步．以預設的動作來說，它會讓 UI thread 過來繼續往下執行，所以 int b = 2 是 UI thread 所執行的．

不論是那一種情況，都是值得討論的．首先，你需要明白的是在 await DoSomethingAsync() 之後由那一個 thread 來執行對你的程式有差嗎 ? 如果你寫的是 Console 程式或是 ASP.NET Core 程式，一般來說沒有什麼差別 (除非你有特殊情況)．如果你寫的是 WinForm/WPF/ASP.NET 4.x 的程式，通常來說會有差別．有沒有差別的原因在於 await DoSomethingAsync() 之後還需不需要和 UI 互動．如果不需要和 UI 互動的話，最好就不要用 UI thread 來執行．如果需要和 UI 互動的話，那得再視情況來決定是否要用 UI thread 或其他 worker thread 繼續執行．

如果 DoSomethingAsync() 真的做了一些 I/O，例如讀寫檔案或是發送 HTTP request 等，如前面說的，在 I/O 發行時，Task 已經 Yield 了，所以 UI thread 是自由的．此時你對 UI 畫面做一些動作，如移動視窗等，這些動作都可以進行，這表示 UI thread 有空幫你完成了那些動作．如果 DoSometingAsync() 並沒有做真的做 I/O，只是做了一些數學運算或甚至是 Thread Sleep()，此時 Task 並沒有 Yield，因此 UI thread 仍在忙於做數學運算或在做 Sleep()，此時你做了移動視窗的動作時，你就會發現整個 UI 介面是沒有反應．也許你會問同樣都是非同步呼叫，怎麼結果不一樣．這若要再講下去就得講到 Windows Kernel 的部份，所以先在此打住．不論是那一種情況，DoSomethingAsync() 總是會完成 (沒有別的意外的話)，完成之後，接下來是由那一個 thread 來執行後面的程式碼，這將是由等待器來決定．

當程式執行到 await DoSomethingAsync() 時，等待器建立起來後，此時等待器已經記錄 thread 的 SynchronizationContext (如果有的話)．WinForm/WPF/ASP.NET 4.x 有 SynchronizationContext，Console 程式/ASP.NET Core 沒有 SynchronizationContext．這東西是什麼用途呢 ? 簡單的說，這是 UI thread 特別有的 (預設上)，好讓其他 thread 方便和 UI thread 互動，也就是讓其他的 thread 呼叫 UI thread 去做更新畫面的動作．其實說穿了就是一堆 delegate 的運用．所以，UI thread 執行了 await DoSomethingAsync(); ，等這完成後，等待器就會讓 UI thread 繼續執行，因為等待器有了 UI thread 的 SynchronizationContext，等待器會將後面的程式碼包成一個 delegate 送給 UI thread SynchronizationContext 來執行．如果是其他的 worker thread 執行了 await DoSomethingAsync()，預設上來說，worker thread 的 SynchronizationContext 是空的，所以當 DoSomethingAsync() 完成後，等待器則將後續的程式碼丟給 ThreadPool 來處理，所以 ThreadPool 就會依它自己的演算法來決定用那一個 worker thread 來執行後續的程式碼，有可能還是剛剛的 worker thread，也有可能不是，完全由 ThreadPool 來決定．

上一段的說明讓你明白非同步的程式碼放在 WinForm/WPF/ASP.NET Core 與 Console/ASP.NET 4.x 時，你會面臨到不同的狀況．這完全是等待器所導致的結果．

接下來講到這篇文章要講的事情 ConfigureAwait()．看此 method 的名字，你就知道它是用來設定等待器．這是用來設定等待器的種類．如果你輸入的是 ConfigureAwait(true) ，這是建立預設的等待器，此等待器會記錄 calling thread 的 SynchronizationContext．當 SynchronizationContext 不為空時，後續的程式碼將透過 SynchronizationContext 的 Post() 來完成，換句話話，執行後續程式碼的 thread 和 calling thread 是同一個．當 SynchronizationContext 為空時，後續程式碼將由 ThreadPool 來決定用那一個 worker thread 來執行．

如果輸入的是 ConfigureAwait(false)，這是一種 type 為 ConfiguredTaskAwaiter，這種等待器會將後續程式碼一律丟給 ThreadPool 來決定用那一個 worker thread 執行，跟 calling thread 的 SynchronizationContext 存不存在完全沒有關係．換句話說，這種等待器少了和 SynchronizationContext 互動的程式碼．

因此，為了擠出那麼點的效能，如果後續程式碼不需要和 UI 互動，那麼在非同步程式碼後面加上 ConfigureAwait(false) 是有好處的．程式碼就變成

await DoSomethingAsync().ConfigureAwait(false);

文章寫到這邊希望能幫助你了解為何 ConfigureAwait(false) 能幫助你擠出那麼點效能，也讓你明白什麼情況下去使用它．

最後，如果 await 之後的程式碼仍有些地方需要和 UI 互動，那就不使用 ConfigureAwait(false) 了嗎 ? 這個答案還得取決於後續的程式碼做了些什麼．如果後續的程式碼沒有什麼運算了，只是簡單的 UI 更新而己，那麼就不用使用 ConfigureAwait(false)．反之，如果仍有其他可觀的程式碼可以讓 woker thread 執行且讓 UI thread 可以去反應 UI 的動作，則還是把 ConfigureAwait(false) 加上去．等到你需要更新 UI 時，再透過 UI Control 的 BeginInvoke() 或是用 UI thread 的 SynchronizationContext Post() 去進行更新 UI 畫面的動作．如果你是 Visual Studio extension 的開發者，在 VS SDK 裡面有個 JoinableTaskFactory class，它有個 SwitchToMainThreadAsync() 可以幫你快速地從 worker thread 切換到 UI thread 以便進行更新畫面的動作．

Hope it helps,

後記: ASP.NET Core 基本上不用去擔心和 UI 互動是不是會發生 deadlock 的問題．ASP.NET Core 已經沒有 AspNetSynchronizationContext 的設計了，所以任何的非同步呼叫基本上都可以一直採用 ConfigureAwait(false) 來幫你擠出那麼點效能出來．