ExecutionContext(执行上下文)综述

>>返回《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 = 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 = 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