ExecutionContext(执行上下文)综述

时间 2020-02-17

标签 executioncontext 执行上下文综述繁體版

原文原文链接

>>返回《C# 并发编程》html

1. 简介

注意: 本篇文章讲述的是在 .Net Framework 环境下的分析，可是我相信这与 .Net Core 设计思想是一致，但在实现上必定优化了不少。编程

下面开始本次讲述：安全

ExecutionContext 实际上只是线程相关其余上下文的容器。架构

有些上下文起辅助做用
有些上下文对 .Net 执行模型相当重要

ExecutionContext 与周围环境的信息有关，这意味着，代码正在运行时，它存储了与 当前环境 或 “context” 有关的数据。并发

周围环境: 代码执行处，能够访问到的变量、方法、属性等等。框架

2. 同步异步对比

在同步世界：异步

在许多系统中，此类“周围”的信息在线程本地存储（TLS）中维护，例如在 [ThreadStatic] 字段或 ThreadLocal<T> 中。
- 在同步世界中，这样的 thread-local 信息就足够了。
  - 任何事情发生在该线程上，也就是无论在该线程上所处的堆栈结构是什么，正在执行什么方法，等等。
  - 全部在该线程上运行的代码均可以查看和影响该线程特有的数据。

在异步世界，TLS变得可有可无，同步异步对比：async

同步
- 例如：
  - 若是我先执行操做 A
  - 而后执行操做 B
  - 而后执行操做 C
- 则全部这三个操做都在同一线程上发生
- 所以全部这三个操做都受该线程上存储的周围环境数据的影响。
异步
- 例如：
  - 我可能在一个线程上启动 A
  - 而后在另外一个线程上完成它
    - 这样操做 B 能够在不一样于 A 的线程上启动或运行
    - 而且相似地使 C 能够在不一样于 B 的线程上启动或运行。
- 这意味着咱们用来控制执行细节的周围环境context再也不可行，由于TLS不会“流”过这些异步点。
- Thread-local 存储特定于线程，这些异步操做并不与特定线程相关联。
- 可是，一般存在逻辑控制流，咱们但愿这些周围环境的数据与该控制流一块儿流动，以使周围环境的数据从一个线程移动到另外一个线程
- 这就须要 ExecutionContext 来完成这些操做。

3. 上下文的捕获和恢复

ExecutionContext 其实是一个 state 包post

用于从一个线程上捕获全部 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