ExecutionContext(執行上下文)綜述

来源:https://www.cnblogs.com/BigBrotherStone/archive/2020/02/16/12316599.html
-Advertisement-
Play Games

" 返回《C 併發編程》" "1. 簡介" "2. 同步非同步對比" "3. 上下文的捕獲和恢復" "4. Flowing ExecutionContext vs Using SynchronizationContext" "5. 如何適用於 async/await" "5.1. 實現方式" "5.1 ...


>>返回《C# 併發編程》

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

asyncawait 關鍵字背後的框架支持會自動與 ExecutionContextSynchronizationContext 交互。

每當代碼等待一個可等待項(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 會被編譯成執行碼

並且這些構建器可確保 ExecutionContextawait 點流動,無論使用哪種可等待項(awaitable)

相反,對 SynchronizationContext 的支持內置在 awaiting 的且已經構建好的TaskTask<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) 來控制它。

  • 大多數情況,等待 TaskTask<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 能夠帶著所有的上下文(例如 SecurityContextHostExecutionContextCallContext 等)流動
    • 確實也包括 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 = await DownloadAsync();
        return Compute(data);
    });
}

7.1.1. 運行過程解析

  • 用戶單擊 button1 ,導致UI框架在UI線程上調用 button1_Click 事件;
  • 然後,代碼啟動一個 WorkItemThreadPool 上運行(通過Task.Run);
    • WorkItemThreadPool介紹-非同步調用方法 中提到;
    • 這個 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 = 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


您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • 前言 這兩天一番花兩天的時間,重新用python和python圖形化開發工具tkinter,完善了下PDF合併小工具,終於可以發佈了。 工具目前基本功能已經完善,後期如果有反饋可以修複部分bug或完善需求。 這個工具基本具備了一個面向大眾的特性,只要是windows用戶,都可以很容易使用。 PDF合 ...
  • 題目:將你的 QQ 頭像(或者微博頭像)右上角加上紅色的數字,類似於微信未讀信息數量那種提示效果。 類似於圖中效果: 代碼: 效果如下: 原圖: 輸出: 附一個Pillow庫的文檔:https://pillow.readthedocs.io/en/3.1.x/index.html ...
  • 前言 因為昨天重新研究了下python的打包方法,今天一番準備把之前寫的一個pdf合併軟體重新整理一下,打包出來。 但在打包的過程中仍然遇到了一些問題,半年前一番做打包的時候也遇到了一些問題,現在來看,解決這些問題思路清晰多了,這裡記錄下。 問題 打包成功,但運行時提示Failed to execu ...
  • 話不多說直接上代碼: // set添加單個元素 stopwatch.Start(); var isok = RedisCacheHelper.Instance.SetAdd("setkey", "10"); stopwatch.Stop(); Console.WriteLine("set添加單個元素 ...
  • 前面四章介紹了繼承自Shape的類,包括Rectangle、Ellipse、Polygon以及Polyline。但還有一個繼承自Shape的類尚未介紹,而且該類是到現在為止功能最強大的形狀類,即Path類。Path類能夠包含任何簡單形狀、多組形狀以及更複雜的要素,如曲線。 Path類提供了Data屬 ...
  • " 返回《C 併發編程》" "1. 簡介" "2. 非同步下的共用變數" "3. 解析 AsyncLocal" "3.1. IAsyncLocalValueMap 的實現" "3.2. 結論" 1. 簡介 + 普通 共用變數: + 在某個類上用靜態屬性的方式即可。 + 多線程 共用變數 + 希望能將這 ...
  • using System; using System.Collections.Generic; using System.Linq; using System.Text; namespace 回調函數Demo { /* 回調函數的作用,1.分裝;2.非同步;3.擴展具體方法。 * 通過一個委托給出實現 ...
  • StackExchange.Redis 的組件封裝示例網上有很多,自行百度搜索即可。 這裡只演示如何使用Hash類型操作數據: 1 // 在 hash 中存入或修改一個值 並設置order_hashkey有效期1分鐘,過期自動刪除;null為不過期 2 stopwatch.Start(); 3 va ...
一周排行
    -Advertisement-
    Play Games
  • Timer是什麼 Timer 是一種用於創建定期粒度行為的機制。 與標準的 .NET System.Threading.Timer 類相似,Orleans 的 Timer 允許在一段時間後執行特定的操作,或者在特定的時間間隔內重覆執行操作。 它在分散式系統中具有重要作用,特別是在處理需要周期性執行的 ...
  • 前言 相信很多做WPF開發的小伙伴都遇到過表格類的需求,雖然現有的Grid控制項也能實現,但是使用起來的體驗感並不好,比如要實現一個Excel中的表格效果,估計你能想到的第一個方法就是套Border控制項,用這種方法你需要控制每個Border的邊框,並且在一堆Bordr中找到Grid.Row,Grid. ...
  • .NET C#程式啟動閃退,目錄導致的問題 這是第2次踩這個坑了,很小的編程細節,容易忽略,所以寫個博客,分享給大家。 1.第一次坑:是windows 系統把程式運行成服務,找不到配置文件,原因是以服務運行它的工作目錄是在C:\Windows\System32 2.本次坑:WPF桌面程式通過註冊表設 ...
  • 在分散式系統中,數據的持久化是至關重要的一環。 Orleans 7 引入了強大的持久化功能,使得在分散式環境下管理數據變得更加輕鬆和可靠。 本文將介紹什麼是 Orleans 7 的持久化,如何設置它以及相應的代碼示例。 什麼是 Orleans 7 的持久化? Orleans 7 的持久化是指將 Or ...
  • 前言 .NET Feature Management 是一個用於管理應用程式功能的庫,它可以幫助開發人員在應用程式中輕鬆地添加、移除和管理功能。使用 Feature Management,開發人員可以根據不同用戶、環境或其他條件來動態地控制應用程式中的功能。這使得開發人員可以更靈活地管理應用程式的功 ...
  • 在 WPF 應用程式中,拖放操作是實現用戶交互的重要組成部分。通過拖放操作,用戶可以輕鬆地將數據從一個位置移動到另一個位置,或者將控制項從一個容器移動到另一個容器。然而,WPF 中預設的拖放操作可能並不是那麼好用。為瞭解決這個問題,我們可以自定義一個 Panel 來實現更簡單的拖拽操作。 自定義 Pa ...
  • 在實際使用中,由於涉及到不同編程語言之間互相調用,導致C++ 中的OpenCV與C#中的OpenCvSharp 圖像數據在不同編程語言之間難以有效傳遞。在本文中我們將結合OpenCvSharp源碼實現原理,探究兩種數據之間的通信方式。 ...
  • 一、前言 這是一篇搭建許可權管理系統的系列文章。 隨著網路的發展,信息安全對應任何企業來說都越發的重要,而本系列文章將和大家一起一步一步搭建一個全新的許可權管理系統。 說明:由於搭建一個全新的項目過於繁瑣,所有作者將挑選核心代碼和核心思路進行分享。 二、技術選擇 三、開始設計 1、自主搭建vue前端和. ...
  • Csharper中的表達式樹 這節課來瞭解一下表示式樹是什麼? 在C#中,表達式樹是一種數據結構,它可以表示一些代碼塊,如Lambda表達式或查詢表達式。表達式樹使你能夠查看和操作數據,就像你可以查看和操作代碼一樣。它們通常用於創建動態查詢和解析表達式。 一、認識表達式樹 為什麼要這樣說?它和委托有 ...
  • 在使用Django等框架來操作MySQL時,實際上底層還是通過Python來操作的,首先需要安裝一個驅動程式,在Python3中,驅動程式有多種選擇,比如有pymysql以及mysqlclient等。使用pip命令安裝mysqlclient失敗應如何解決? 安裝的python版本說明 機器同時安裝了 ...