SynchronizationContext(同步上下文)综述

时间 2020-02-05

标签 synchronizationcontext 同步上下文综述繁體版

原文原文链接

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

1. 概述

不管是什么平台（ASP.NET 、WinForm 、WPF 等），全部 .NET 程序都包含 同步上下文 概念，而且全部多线程编程人员均可以经过理解和应用它获益。react

2. 同步上下文的必要性

2.1. ISynchronizeInvoke 的诞生

原始多线程web
- 多线程程序在 .NET Framework 出现以前就存在了。
- 这些程序一般须要一个线程将一个工做单元传递给另外一个线程。
- Windows 程序围绕消息循环进行，所以不少编程人员使用这一内置队列传递工做单元。
- 每一个要以这种方式使用 Windows 消息队列的多线程程序都必须自定义 Windows 消息以及处理约定。
ISynchronizeInvoke 的诞生数据库
- 当 .NET Framework 首次发布时，这一通用模式是标准化模式。
- 那时 .NET 惟一支持的 GUI 应用程序类型是 WinFrom。
- 不过，框架设计人员期待其余模型，他们开发出了一种通用的解决方案，ISynchronizeInvoke 诞生了。
ISynchronizeInvoke 的原理编程
- 一个“源”线程能够将一个委托列入“目标”线程队列。
- ISynchronizeInvoke 还提供了一个属性来肯定当前代码是否已在目标线程上运行。
- WinForm 提供了单例的 ISynchronizeInvoke 实现，而且开发了一种模式来设计异步组件。

2.2. SynchronizationContext 的诞生

ASP.NET 异步页面
- .NET Framework 2.0 版包含不少重大改动。其中一项重要改进是在 ASP.NET 体系结构中引入了异步页面。
  - 在 .NET Framework 2.0 以前的版本中，每一个 ASP.NET 请求都须要一个线程，线程会直到该请求完成。
  - 这会形成线程利用率低下，由于建立网页一般依赖于数据库查询和 Web 服务调用，而且处理请求的线程必须等待，直到全部这些操做结束。
  - 后来使用异步页面，处理请求的线程能够开始每一个操做，而后返回到 ASP.NET 线程池；当操做结束时，ASP.NET 线程池的另外一个线程能够完成该请求。
- ISynchronizeInvoke 不太适合 ASP.NET 异步页面体系结构。
  - 使用 ISynchronizeInvoke 模式开发的异步组件在 ASP.NET 页面内没法正常工做，由于 ASP.NET 异步页面不与单个线程关联。
  - 须要设计出，无须将工做排入原来的线程队列，异步页面只需对未完成的操做进行计数以肯定页面请求什么时候能够完成。
通过精心设计， SynchronizationContext 取代了 ISynchronizeInvoke 。

3. 同步上下文的概念

ISynchronizeInvoke 知足了两点需求：安全

肯定是否必须同步
使工做单元从一个线程列队等候另外一个线程。

设计 SynchronizationContext 是为了替代 ISynchronizeInvoke ，但完成设计后，它就不只仅是一个替代品了。服务器

一方面， SynchronizationContext 提供了一种方式，可使工做单元列队并列入上下文。
- 请注意，工做单元是列入上下文，而不是某个特定线程。
- 这一区别很是重要，由于不少 SynchronizationContext 实现都不是基于单个特定线程的。
- SynchronizationContext 不包含用来肯定是否必须同步的机制，由于这是不可能的。
  - WPF 中的Dispatcher.Invoke是将委托列入上下文，不等委托执行直接返回
  - WinForm 中的txtUName.Invoke会启动一个process，等到委托执行完毕后返回
另外一方面，每一个线程都有当前同步上下文。
- 线程上下文不必定惟一；
- 其上下文实例能够与多个其余线程共享。
- 线程能够更改其当前上下文，但这样的状况很是少见。
第三个方面，保持了未完成操做的计数。
- 这样，就能够用于 ASP.NET 异步页面和须要此类计数的任何其余主机。
- 大多数状况下，捕获到当前 SynchronizationContext 时，计数递增；
  - 捕获到的 SynchronizationContext 用于将完成通知列队到上下文中时，计数递减 void OperationCompleted()。
其余一些方面，这些对大多数编程人员来讲并不那么重要。

// SynchronizationContext API的重要方面
class SynchronizationContext
{

  // 将工做分配到上下文中
  void Post(..); // (asynchronously 异步)

  void Send(..); // (synchronously 同步)

  // 跟踪异步操做的数量。
  void OperationStarted();

  void OperationCompleted();

  // 每一个线程都有一个Current Context。
  // 若是“Current”为null，则按照惯例，
  // 最开始的当前上下文为 new SynchronizationContext()。
  static SynchronizationContext Current { get; }

  //设置当前同步上下文
  static void SetSynchronizationContext(SynchronizationContext);
}

4. 同步上下文的实现

不一样的框架和主机能够自行定义上下文多线程

经过了解这些不一样的实现及其限制，能够清楚了解 SynchronizationContext 概念能够和不能够实现的功能并发

4.1. WinForm 同步上下文

位于：System.Windows.Forms.dll:System.Windows.Forms框架

WinForm

WinForm应用程序会建立并安装一个 WindowsFormsSynchronizationContext
- 做为建立 UI Control 的每一个线程的当前上下文
- 一个 WinForm 应用程序对应一个同步上下文
这一 SynchronizationContext 使用 UI Control 的 Invoke 等方法(ISynchronizeInvoke派生出来的)，该方法将委托传递给基础 Win32 消息循环
WindowsFormsSynchronizationContext 的上下文是一个单例的 UI 线程
在 WindowsFormsSynchronizationContext 列队的全部委托一次一个地执行
- 这个已排序的委托队列，被一个特定 UI 线程执行完

4.2. Dispatcher 同步上下文

位于：WindowsBase.dll:System.Windows.Threading

WPF

委托按“Normal”优先级在 UI 线程的 Dispatcher 中列队
当一个线程经过调用 Dispatcher.Run 开启 循环调度器 时，将这个初始化完成的 同步上下文 安装到当前上下文
DispatcherSynchronizationContext 的上下文是一个单独的 UI 线程。
排队到 DispatcherSynchronizationContext 的全部委托均由特定的UI线程一次一个按其排队的顺序执行
当前实现为每一个顶层窗口建立一个 DispatcherSynchronizationContext，即便它们都使用相同的基础调度程序也是如此。

4.3. Default 同步上下文

调度线程池线程的同步上下文。

位于：mscorlib.dll:System.Threading

Default SynchronizationContext 是默认构造的 SynchronizationContext 对象。

根据惯例，若是一个线程的当前 SynchronizationContext 为 null，那么它隐式具备一个Default SynchronizationContext。
Default SynchronizationContext 将其异步委托列队到 ThreadPool ，但在调用线程上直接执行其同步委托。
所以，Default SynchronizationContext涵盖全部 ThreadPool 线程以及任何调用 Send 的线程。
这个上下文“借助”调用 Send 的线程们，将这些线程放入这个上下文，直至委托执行完成
- 从这种意义上讲，默认上下文能够包含进程中的全部线程。
Default SynchronizationContext 应用于 线程池 线程，除非代码由 ASP.NET 承载。
Default SynchronizationContext 还隐式应用于显式子线程（Thread 类的实例），除非子线程设置本身的 SynchronizationContext 。

所以，UI 应用程序一般有两个同步上下文：

包含 UI 线程的 UI SynchronizationContext
包含 ThreadPool 线程的Default SynchronizationContext

4.4. 上下文捕获和执行

BackgroundWorker运行流程

首先BackgroundWorker 捕获并使用调用 RunWorkerAsync 的线程的 同步上下文
而后，在Default SynchronizationContext中执行DoWork
最后，在以前捕获的上下文中执行其 RunWorkerCompleted 事件

UI同步上下文 中只有一个 BackgroundWorker ，所以 RunWorkerCompleted 在 RunWorkerAsync 捕获的 UI同步上下文中执行（以下图）。

UI同步上下文中的嵌套 BackgroundWorker

嵌套: BackgroundWorker 从其 DoWork 处理程序启动另外一个 BackgroundWorker
- 嵌套的 BackgroundWorker 不会捕获 UI同步上下文
DoWork 由 线程池 线程使用 默认同步上下文 执行。
- 在这种状况下，嵌套的 RunWorkerAsync 将捕获默认 SynchronizationContext
- 所以它将由一个 线程池 线程而不是 UI线程 执行其 RunWorkerCompleted
- 这样会致使异步执行完后，后面的代码就不在UI同步上下文中执行了（以下图）。

默认状况下，控制台应用程序 和 Windows服务 中的全部线程都只有 Default SynchronizationContext，这会致使一些基于事件的异步组件失败（也就是没有UI同步上下文的特性）

要解决这个问题，能够建立一个显式子线程，而后将 UI同步上下文 安装在该线程上，这样就能够为这些组件提供上下文。
Nito.Async 库的 ActionThread 类可用做通用同步上下文实现。

4.5. AspNetSynchronizationContext

位于：System.Web.dll:System.Web [internal class]

ASP.NET

SynchronizationContext 在线程池线程执行页面代码时安装完成。
当一个委托列入到捕获的 AspNetSynchronizationContext 中时，它设置原始页面的 identity 和 culture 到此线程，而后直接执行委托
- 即便委托是经过调用 Post “异步”列入的，也会直接调用委托。

从概念上讲， AspNetSynchronizationContext 的上下文很是复杂。

在异步页面的生命周期中，该同步上下文历来自 ASP.NET 线程池的一个线程开始。
- 异步请求开始后，该上下文不包含任何线程。
- 异步请求结束时，线程池线程进入该上下文并执行 处理完成的相关工做
这多是启动请求的线程，但更多是操做完成时处于空闲状态的任何线程。
若是同一应用程序的多项操做同时完成， AspNetSynchronizationContext 确保一次只执行其中一项。它们能够在任意线程上执行，但该线程将具备原始页面的 identity 和 culture。

一个常见的示例：

在异步网页中使用 WebClient.DownloadDataAsync 将捕获当前 SynchronizationContext ，以后在该上下文中执行其 DownloadDataCompleted 事件。

当页面开始执行时，ASP.NET 会分配一个线程执行该页面中的代码。
该页面可能调用 DownloadDataAsync ，而后返回；
- ASP.NET 对未完成的异步操做进行计数，以便了解页面处理是否已完成。
当 WebClient 对象下载所请求的数据后，它将在线程池线程上收到通知
- 该线程将在捕获的上下文中引起 DownloadDataCompleted
该上下文将保持在相同的线程中，但会确保事件处理的运行使用正确的 identity 和 culture 运行

5. 同步上下实现类的注意事项

SynchronizationContext 提供了一种途径，能够在不少不一样框架中编写组件
- BackgroundWorker 和 WebClient 就是两个在 WinForm、WPF、Console和 ASP.NET Application中一样应用自如的组件。
在设计这类可重用组件时，必须注意几点:
- 同步上下文的实现们不是平等可比的。
  - 这意味着没有相似 ISynchronizeInvoke.InvokeRequired 的等效项
    - 此属性肯定在对如Concrol对象进行方法调用时，调用方是否必须经过 Invoke 进行调用(传入委托)。
    - 这样的(Control)对象被绑定到特定线程，而且不是线程安全的。
    - 若是要从其余线程调用对象的方法，则必须借助 Invoke 方法将对相应线程调用的委托列队
  - 不过，这不是多大的缺点；代码更为清晰，而且更容易验证它是否始终在已知上下文中执行，而不是试图处理多个上下文。
- 不是全部 同步上下文的实现 均可以保证委托执行顺序或委托同步顺序。
  - UI同步上下文知足上述条件
  - ASP.NET同步上下文只提供同步
  - Default同步上下文 不保证执行顺序或同步顺序
- 同步上下文实例和线程之间没有 1:1 的对应关系
  - WindowsFormsSynchronizationContext 确实 1:1 映射到一个线程（只要不调用 SynchronizationContext.CreateCopy）
    - 任何其余实现都不是这样
  - 通常而言，最好不要假设任何上下文实例将在任何指定线程上运行
- SynchronizationContext.Post 方法不必定是异步的
  - 大多数实现异步实现此方法，但 AspNetSynchronizationContext 是一个明显的例外
  - 这可能会致使没法预料的重入问题

同步上下文实现类的摘要

	使用特定线程执行委托	独占 (一次执行一个委托)	有序 (委托按队列顺序执行)	Send 能够直接调用委托	Post 能够直接调用委托
Winform	能	能	能	若是从UI线程调用	从不
WPF/Silverlight	能	能	能	若是从UI线程调用	从不
Default	不能	不能	不能	Always	从不
ASP.NET	不能	能	不能	Always	Always

6. AsyncOperationManager 和 AsyncOperation

AsyncOperationManager 和 AsyncOperation 类是 SynchronizationContext 抽象类的轻型包装
- AsyncOperation的异步是使用抽象的同步上下文进行封装的
AsyncOperationManager 在第一次建立 AsyncOperation 时捕获当前同步上下文，若是当前同步上下文为null，则使用 Default 同步上下文
AsyncOperation 将委托异步发布到捕获的 同步上下文
大多数基于事件的异步组件都在其实现中使用 AsyncOperationManager 和 AsyncOperation
- 这些对于具备明确完成点的异步操做很是有效
  - 即异步操做从一个点开始，以另外一个点的事件结束
- 其余异步通知可能没有明确的完成点；它们多是一种订阅类型，在一个点开始，而后无限期持续
  - 对于这些类型的操做，当触发了被订阅的事件，在事件处理中直接捕获和使用同步上下文

新组件不该使用基于事件的异步模式

使用基于Task的异步模式
- 组件返回 Task 和 Task 对象，而不是经过同步上下文引起事件
- 基于 Task 的 API 是 .NET 中异步编程的发展方向

7. 同步上下文的Library支持示例

像 BackgroundWorker 和 WebClient 这样的简单组件是隐式自带的
- 隐藏了对同步上下文的捕获和使用。
不少 Libraries 以更可见的方式使用同步上下文
- 经过使用 SynchronizationContext 公开 API，Libraries 不只得到了框架独立性，并且为高级最终用户提供了一个可扩展点。
ExecutionContext
- 是与执行的逻辑线程相关的全部信息提供单个容器。这包括安全上下文、调用上下文和同步上下文
- 任何捕获线程的 ExecutionContext 的系统都会捕获当前同步上下文
- 当恢复 ExecutionContext 时，一般也会恢复同步上下文

7.1. WCF

WCF 有两个用于配置服务器和客户端行为的特性：

ServiceBehaviorAttribute 和 CallbackBehaviorAttribute
- 这两个特性都有一个 Boolean 属性：UseSynchronizationContext
- 此特性的默认值为 true，这表示在建立通讯通道时捕获当前同步上下文，这一捕获的同步上下文用于使约定方法列队。
服务器使用 Default 同步上下文
客户端回调使用相应的 UI 同步上下文
在须要重入时，这会致使问题，如客户端调用的服务器方法回调客户端方法。在这类状况下，将 UseSynchronizationContext 设置为 false 能够禁止 WCF 自动使用同步上下文
- 由于若是这时若是客户端使用的是UI同步上下文，可能形成不可预期的问题

7.2. Workflow Foundation (WF)

WorkflowInstance 类及其派生的 WorkflowApplication 类的SynchronizationContext 属性
若是承载进程建立本身拥有的 WorkflowInstance ，同步上下文也许直接设置了
WorkflowInvoker.InvokeAsync 也使用同步上下文
- 它捕获当前同步上下文并将其传递给其 internal 的 WorkflowApplication
  - 该同步上下文用于 Post 工做流完成事件以及工做流活动

7.3. Task Parallel Library (TPL)

TaskScheduler.FromCurrentSynchronizationContext

TPL 使用 Task 对象做为其工做单元并经过 TaskScheduler 执行。

默认 TaskScheduler 的做用相似于 Defalut 同步上下文，将 Task 在 ThreadPool 中列队。
TPL 队列还提供了另外一个 TaskScheduler ，将 Task 在一个同步上下文中列队
- UI 进度条更新能够在一个嵌套 Task 中完成，以下所示。

UI 进度条更新

private void button1_Click(object sender, EventArgs e)
{
  // 捕获当前 SynchronizationContext 的 TaskScheduler.
  TaskScheduler taskScheduler = TaskScheduler.FromCurrentSynchronizationContext();
  // Start a new task (this uses the default TaskScheduler, 
  // so it will run on a ThreadPool thread).
  Task.Factory.StartNew(() =>
  {
    // We are running on a ThreadPool thread here.
    // Do some work.
    // Report progress to the UI.
    Task reportProgressTask = Task.Factory.StartNew(() =>
    {
      // We are running on the UI thread here.
      // Update the UI with our progress.
    },CancellationToken.None,
      TaskCreationOptions.None,
      taskScheduler);

    reportProgressTask.Wait();
    // Do more work.
  });
}

CancellationToken.Register

CancellationToken 类可用于任意类型的取消操做
为了与现有取消操做形式集成，该类容许注册委托以在请求取消时调用
- 当取消委托被注册后，同步上下文就能够传递了
  - 当发起取消请求时， CancellationToken 将该委托列入 同步上下文 队列，而后才会进行执行

7.4. Reactive Extensions (Rx)

ObserveOn 、 SubscribeOn 和 SynchronizationContextScheduler

Rx 是一个库，它将事件视为数据流

ObserveOn(context) 运算符经过一个同步上下文将事件列队
SubscribeOn(context) 运算符经过一个同步上下文将对这些事件的订阅列队
ObserveOn(context) 一般用于使用传入事件更新 UI，SubscribeOn 用于从 UI 对象使用事件

Rx 还有它本身的工做单元列队方法： IScheduler 接口。

Rx 包含 SynchronizationContextScheduler
- 是一个将 Task 列入指定 同步上下文 的 IScheduler 实现。
- 构造方法: SynchronizationContextScheduler(SynchronizationContext context)

7.5. 异步编程 Async

await 、 ConfigureAwait 、 SwitchTo 和 Progress<T>

默认状况下， 当前同步上下文 在一个 await 关键字处被捕获
此 同步上下文 用于在运行到 await关键字后时恢复
- 也就是 await 关键字后面的执行代码会被列入到 该同步上下文 中执行
  - 仅当它不为 null 时，才捕获当前同步上下文
  - 若是为 null ，则捕获当前 TaskScheduler

private async void button1_Click(object sender, EventArgs e)
{
  // 当前 SynchronizationContext 被 await 在暗中捕获
  var data = await webClient.DownloadStringTaskAsync(uri);

  // 此时，已捕获的SynchronizationContext用于恢复执行，
  // 所以咱们能够自由更新UI对象。
}

ConfigureAwait 提供了一种途径避免 SynchronizationContext 捕获；
- 为 continueOnCapturedContext 参数传递 false 会阻止 await后的代码，在 await 执行前的 同步上下文 上执行
同步上下文实例还有一种扩展方法 SwitchTo
- 使用该方法，任何 async 的方法能够经过调用 SwitchTo 改变到一个不一样的同步上下文上，并 awaiting 结果

报告异步操做进展的通用模式：

IProgress<T> 接口及其实现 Progress<T>
- 该类在构造时捕获 当前同步上下文
- 并在中引起其 ProgressChanged 事件
- 因此实例化时，须要在 UI同步上下文 上执行

返回 void 的 async 方法

在异步操做开始时递增计数
在异步操做结束后递减计数

这一行为使返回 void 的 async 方法相似于顶级异步操做。

8. 限制和功能

了解 同步上下文 对任何编程人员来讲都是有益的
现有跨框架组件使用它同步其事件
Libraries 能够将它公开以得到更高的灵活性
技术精湛的编程人员了解 同步上下文 限制和功能后，能够更好地编写和利用这些类