>>回傳《C# 并發編程》

1. 簡介
2. 同步異步對比
3. 背景關系的捕獲和恢復
4. Flowing ExecutionContext vs Using SynchronizationContext
5. 如何適用于 async/await
- 5.1. 實作方式
  - 5.1.1. ExecutionContext
  - 5.1.2. SynchronizationContext
- 5.2. 執行程序
  - 5.2.1. SynchronizationContext 使用和控制
  - 5.2.2. ExecutionContext 的流動無法控制
6. 兩者的關系
7. 說明
- 7.1. 示例
  - 7.1.1. 運行程序決議
  - 7.1.2. 帶來的思考

1. 簡介

注意: 本篇文章講述的是在 .Net Framework 環境下的分析，但是我相信這與 .Net Core 設計思想是一致，但在實作上一定優化了很多，

下面開始本次講述：

ExecutionContext 實際上只是執行緒相關其他背景關系的容器，

有些背景關系起輔助作用
有些背景關系對 .Net 執行模型至關重要

ExecutionContext 與周圍環境的資訊有關，這意味著，代碼正在運行時，它存盤了與 當前環境 或 “context” 有關的資料，

周圍環境: 代碼執行處，可以訪問到的變數、方法、屬性等等，

2. 同步異步對比

在同步世界：

在許多系統中，此類“周圍”的資訊在執行緒本地存盤（TLS）中維護，例如在 [ThreadStatic] 欄位或 ThreadLocal<T> 中，
- 在同步世界中，這樣的 thread-local 資訊就足夠了，
  - 任何事情發生在該執行緒上，也就是不管在該執行緒上所處的堆疊結構是什么，正在執行什么方法，等等，
  - 所有在該執行緒上運行的代碼都可以查看和影響該執行緒特有的資料，

在異步世界，TLS變得無關緊要，同步異步對比：

同步
- 例如：
  - 如果我先執行操作 A
  - 然后執行操作 B
  - 然后執行操作 C
- 則所有這三個操作都在同一執行緒上發生
- 因此所有這三個操作都受該執行緒上存盤的周圍環境資料的影響，
異步
- 例如：
  - 我可能在一個執行緒上啟動 A
  - 然后在另一個執行緒上完成它
    - 這樣操作 B 可以在不同于 A 的執行緒上啟動或運行
    - 并且類似地使 C 可以在不同于 B 的執行緒上啟動或運行，
- 這意味著我們用來控制執行細節的周圍環境context不再可行，因為TLS不會“流”過這些異步點，
- Thread-local 存盤特定于執行緒，這些異步操作并不與特定執行緒相關聯，
- 但是，通常存在邏輯控制流，我們希望這些周圍環境的資料與該控制流一起流動，以使周圍環境的資料從一個執行緒移動到另一個執行緒
- 這就需要 ExecutionContext 來完成這些操作，

3. 背景關系的捕獲和恢復

ExecutionContext 實際上是一個 state 包

用于從一個執行緒上捕獲所有 state
然后在控制邏輯流的同時將其還原到另一個執行緒

ExecutionContext 是使用靜態方法 Capture 捕獲的：

// 周圍環境的 state 捕獲到 ec 中
ExecutionContext ec = ExecutionContext.Capture();

通過靜態方法 Run ，在委托(Run方法的引數)呼叫時恢復 ExecutionContext

ExecutionContext.Run(ec, delegate
{
    … // 這里的代碼將上述 ec 的狀態視為周圍環境
}, null);

所有派生異步作業的方法都以這種方式捕獲和還原 ExecutionContext 的，

帶有“Unsafe”字樣的方法除外，它們是不安全的，因為它們不傳播 ExecutionContext

例如：

當您使用 Task.Run 時，對 Run 的呼叫將從呼叫執行緒中捕獲 ExecutionContext ，并將該 ExecutionContext 實體存盤到 Task 物件中
當提供給 Task.Run 的委托作為該 Task 執行的一部分被呼叫時，它是使用存盤的 ExecutionContext 通過 ExecutionContext.Run 來完成的

以下所有異步API的執行都是捕獲 ExecutionContext 并將其存盤，然后在呼叫某些代碼時再使用存盤的 ExecutionContext，

Task.Run
ThreadPool.QueueUserWorkItem
Delegate.BeginInvoke
Stream.BeginRead
DispatcherSynchronizationContext.Post
任何其他異步API

當我們談論“flowing ExecutionContext”時，我們實際上是在討論：

在一個執行緒上獲取周圍環境狀態
在稍后的某個時刻將該狀態恢復到另一個執行緒上(需要執行提供的委托的執行緒)，

4. Flowing ExecutionContext vs Using SynchronizationContext

前面我們介紹了 SynchronizationContext 是如何調度執行緒的，現在，我們要進行進行一次對比：

flowing ExecutionContext 在語意上與 capturing and posting to a SynchronizationContext 完全不同，
當 ExecutionContext 流動時，您是從一個執行緒捕獲 state ，然后還原該 state
- 使提供的委托執行時處于周圍環境 state
當您捕獲并使用 SynchronizationContext 時，不會發生這種情況，
- 捕獲部分是相同的，因為您要從當前執行緒中獲取資料，但是隨后用不同方式使用 state
- SynchronizationContext.Post 只是使用捕獲的狀態來呼叫委托，而不是在呼叫委托時設定該狀態為當前狀態
  - 該委托在何時何地以及如何運行完全取決于Post方法的實作

5. 如何適用于 async/await

async 和 await 關鍵字背后的框架支持會自動與 ExecutionContext 和 SynchronizationContext 互動，

每當代碼等待一個可等待項(awaitable)，該可等待項(awaitable) 的 等待者(awaiter) 說尚未完成時

即等待者(awaiter) 的 IsCompleted 回傳 false

則該方法需要暫停，并通過等待者(awaiter) 的 continuation 來恢復，

等待者(awaiter) : 可以理解為 await 產生的 Task物件，

5.1. 實作方式

5.1.1. ExecutionContext

前面已經提到過了， ExecutionContext 需要從發出 await 的代碼一直流到 continuation 委托的執行，
- 這是由框架自動處理的
- 當 async 方法即將掛起時，基礎設施將捕獲 ExecutionContext
- 得到的委托交給等待者(awaiter) ，而且此等待者(awaiter) 具有對此 ExecutionContext 實體的參考，并將在恢復該方法時使用它，
由 ExecutionContext 帶領，啟用重要的周圍環境資訊，去流過 awaits ，

5.1.2. SynchronizationContext

該框架還支持 SynchronizationContext ，前述對 ExecutionContext 的支持內置于表示 async 方法的“構建器”中

例如 System.Runtime.CompilerServices.AsyncTaskMethodBuilder
即 await / async 會被編譯成執行碼

并且這些構建器可確保 ExecutionContext 跨 await 點流動，無論使用哪種可等待項(awaitable)，

相反，對 SynchronizationContext 的支持內置在 awaiting 的且已經構建好的Task 和 Task<TResult>中

自定義的等待者(awaiter) (比如 new Task(...))可以自己添加類似的邏輯，但是不會自動獲得實體化時的SynchronizationContext

這是設計使然，因為能夠自定義何時以及如何呼叫 continuation 是自定義Task有用的一部分原因，

5.2. 執行程序

5.2.1. SynchronizationContext 使用和控制

當您 await 一個 task 時，默認情況下，等待者(awaiter) 將捕獲當前的 SynchronizationContext(如果有的話)
在 task 完成時將 Post 這個前面提供的 continuation 委托并回到該 context 進行執行
- 運行委托的：不是在完成了 task 的執行緒上，也不是在 ThreadPool 的執行緒上

如果開發人員不希望這種封送處理行為，則可以通過更改在那里使用的 可等待項(awaitable) / 等待者(awaiter) 來控制它，

大多數情況，等待 Task 或 Task<TResult> 就時采用上述方式
可以通過 await 方法 task.ConfigureAwait(…)的回傳值來修改這種封送處理行為
- ConfigureAwait() 回傳一個 可等待項(awaitable)，它可以抑制此默認的封送處理行為，
- ConfigureAwait() 的唯一 bool 型別引數 continueOnCapturedContext
  - 為 true ，那么將獲得默認行為；
  - 為 false ，則等待者(awaiter) 不檢查 SynchronizationContext ，就像沒有一樣
- 注意: 當等待的任務完成時，無論 ConfigureAwait 如何，在恢復執行的執行緒上，運行時都會檢查當前的 context ，以確定：
  - continuation 是否可以在此處同步運行
  - continuation 是否必須從此處開始異步調度(scheduled asynchronously)

5.2.2. ExecutionContext 的流動無法控制

盡管 ConfigureAwait 提供了，用于改變 SynchronizationContext 行為的、顯示的、與 await 相關的編程模型，但是沒有用于抑制 ExecutionContext 流動的、與 await 相關的編程模型支持，

這是故意的；
開發人員在撰寫異步代碼時不必擔心 ExecutionContext ；
它在基礎架構級別上的支持，有助于在異步環境中模擬同步方式的語意（即TLS）；

6. 兩者的關系

7. 說明

SynchronizationContext 不是 ExecutionContext 的一部分嗎？

ExecutionContext 能夠帶著所有的背景關系(例如 SecurityContext ， HostExecutionContext ， CallContext 等)流動
- 確實也包括 SynchronizationContext
我個人認為，這是API設計的一個錯誤，自從它在許多版本的.NET中提出以來，就引起了一些問題
注意這個問題在 .Net Core 已經解決
- .Net Core 中的 ExecutionContext 已不包含任何其他 context

當您呼叫公共 ExecutionContext.Capture() 方法時，它將檢查當前的 SynchronizationContext ，如果有，則將其存盤到回傳的 ExecutionContext 實體中，然后，當使用公共 ExecutionContext.Run(...) 方法時，在提供的委托執行期間，該捕獲的 SynchronizationContext 被恢復為 Current ，

為什么這有問題？作為 ExecutionContext 的一部分而流動的 SynchronizationContext 更改了 SynchronizationContext.Current 的含義，

應該可以通過 SynchronizationContext.Current 回傳到你最近呼叫 Current 時的環境

因此，如果 SynchronizationContext 流出，成為另一個執行緒的當前 SynchronizationContext ，則 SynchronizationContext.Current 就沒有意義了，所以不是這樣設計的，

7.1. 示例

解釋此問題的一個示例，代碼如下：

private async void button1_Click(object sender, EventArgs e)
{
    button1.Text = await Task.Run(async delegate
    {
        string data = https://www.cnblogs.com/childking/p/await DownloadAsync();
        return Compute(data);
    });
}

7.1.1. 運行程序決議

用戶單擊 button1 ，導致UI框架在UI執行緒上呼叫 button1_Click 事件；
然后，代碼啟動一個 WorkItem 在 ThreadPool 上運行（通過Task.Run）；
- WorkItem 在 ThreadPool介紹-異步呼叫方法中提到；
- 這個 WorkItem 開始一些下載作業，并異步等待其完成；
- 在下載完成之后，ThreadPool 上的 WorkItem 進行一些密集型操作(Compute(data))；
- 回傳結果
WorkItem 執行完成后，導致正在 UI執行緒 上等待的 Task 完成
(下載得到結果，回傳結果)，成為 UI執行緒 等待完成的 ;
然后，UI執行緒 處理 button1_Click 方法的剩余部分: 保存計算結果到 button1.Text 屬性，

7.1.2. 帶來的思考

如果 SynchronizationContext 不作為 ExecutionContext 的一部分流動，我的預期就是有根據的，

如果 SynchronizationContext 流動了，無論如何，我將感到非常失望，

假設：SynchronizationContext 作為 ExecutionContext 的一部分流動：

Task.Run 在呼叫時捕獲 ExecutionContext ，并使用它運行傳遞給它委托，
這就意味著 Task.Run 呼叫時的當前 SynchronizationContext 將流動到 Task 中，而且將在 DownloadAsync 執行和等待結果期間成為當前 SynchronizationContext ，
- 這意味著這個 await 將看到當前 SynchronizationContext ，并 Post 異步方法的其余部分作為一個 continuation 回傳到 UI執行緒 上運行，
這意味著我的 Compute 方法將在 UI執行緒 上運行，而不是在 ThreadPool 上運行，從而導致我的應用程式出現回應性問題，

從實際結果來看這是不對的，假設執行的代碼更像下面的

private async void button1_Click(object sender, EventArgs e)
{
  string data = https://www.cnblogs.com/childking/p/await DownloadAsync();
  button1.Text = Compute(data);
}

實際：現在，我們看看實際是如何處理的：

Task.Run(...) 這種異步Api的實作：

解讀捕獲(Capture)和運行(Run);
- ExecutionContext 實際上有兩個 Capture 方法：
  - 但是只有一個是 public，供外部使用
  - 那個 internal 的方法，是 mscorlib 大多數公開的異步功能(如：Task.Run(...))所使用的一個
    - 這個方法有選擇地允許呼叫方抑制捕獲 SynchronizationContext 作為 ExecutionContext 的一部分；
- 與此相對應的是， Run 方法的 internal 多載也支持忽略存盤在 ExecutionContext 中的 SynchronizationContext
  - 實際上是假裝沒有被捕獲（此外，這也是 mscorlib 中大多數方法使用的多載），
這意味著：
- 在 mscorlib 中幾乎包含所有異步操作的核心實作，這里不會將 SynchronizationContext 作為 ExecutionContext 的一部分流動
- 位于其他地方的，任何異步操作的核心實作，都將使 SynchronizationContext 作為 ExecutionContext 的一部分流動，

標識 async 關鍵字方法的實作：

之前我曾提到，異步方法的 “builders” 是負責在 async 方法中流動 ExecutionContext 所使用的方式
- 這些 builders 確實存在于 mscorlib 中，并且確實使用 internal 的多載做一些事情，
同樣的， SynchronizationContext 不會作為 ExecutionContext 的一部分流動穿過 awaits
- 此外，這與 task awaiters 如何支持捕獲 SynchronizationContext 和將其 Post 回來是分開的
- 實作方式：為了幫助處理 ExecutionContext 帶著 SynchronizationContext 流動的情況， async 方法的基礎設施嘗試忽略由于流動而將 SynchronizationContexts 設定為 Current ，
簡而言之，SynchronizationContext.Current 不會“流動”穿過 await 點，

參考資料：
《ExecutionContext vs SynchronizationContext》 --- Stephen Toub

轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/63613.html

標籤：其他

上一篇：【WPF學習】第四十一章變換

下一篇：IQOS 3 DUO 白燈充不進電的解決辦法

ExecutionContext(執行背景關系)綜述