探究SynchronizationContext在.Net异步编程中的地位
Posted lonelyxmas
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了探究SynchronizationContext在.Net异步编程中的地位相关的知识,希望对你有一定的参考价值。
原文:探究SynchronizationContext在.Net异步编程中的地位引言:
多线程编程/异步编程非常复杂,有很多概念和工具需要去学习,贴心的.NET提供Task线程包装类和await/async异步编程语法糖简化了异步编程方式。
相信很多开发者都看到如下异步编程实践原则:
实践原则 | 说明 | 例外情况 | |
① | 避免 Async Void | 最好使用 async Task 方法而不是 async void 方法 | 事件处理程序 |
② | 始终使用 await | 不要混合阻塞式代码和异步代码 | 控制台 main 方法 |
③ | 配置上下文 | 尽可能使用ConfigureAwait(false) | 需要上下文的方法 |
UI 例子:点击按钮触发了一个远程HTTP请求,用请求的返回值修改UI控件, 以下代码会引发deadlock (类似状态出现在Windows Form、WPF)
public static async Task<JObject> GetJsonAsync(Uri uri) { using (var client = new HttpClient()) { var jsonString = await client.GetStringAsync(uri); return JObject.Parse(jsonString); } } // 顶层调用方法 public void Button1_Click(...) { var jsonTask = GetJsonAsync(...); textBox1.Text = jsonTask.Result; }
public static async Task<JObject> GetJsonAsync(Uri uri) { using (var client = new HttpClient()) { var jsonString = await client.GetStringAsync(uri); return JObject.Parse(jsonString); } } // My "top-level" method. public class MyController : ApiController { public string Get() { var jsonTask = GetJsonAsync(...); return jsonTask.Result.ToString(); } }
-
不要混合使用异步、同步代码,始终使用async/await语法糖编写异步代码
-
在等待的异步任务内应用ConfigureAwait(false)方法 (:不再尝试从捕获的同步上下文执行异步编程的后续代码)
-
为什么要有SynchronizationContext 对象
-
阐述await关键字与SynchronizationContext对象交互原理
-
以上代码为什么会有deadlock, 另外ASP.NET Core为什么不会发生以上死锁
1. The Need for SynchronizationContext
提供在各种同步模型中传播同步上下文的基本功能。此类实现的同步模型的目的是允许公共语言运行库的内部异步/同步操作使用不同的同步模型正常运行。
上面的定义给我的印象是:在线程切换过程中保存前置线程执行的上下文环境。
我们大家都知道:Windows Form和WPF都基于类似的原则: 不允许在非UI线程上操作 UI元素
这个时候我们可以捕获当前执行环境SynchronizationContext,利用这个对象切换回原UI线程。
public static void DoWork() { //On UI thread var sc = SynchronizationContext.Current; ThreadPool.QueueUserWorkItem(delegate { // do work on ThreadPool sc.Post(delegate { // do work on the original context (UI) }, null); }); }
SynchronizationContext表示代码正在运行的当前环境,每个线程都有自己的SynchronizationContext,通过SynchronizationContext.Current可获取当前线程的同步上下文。利用该对象,可在线程池线程B执行完成后,尝试切换到原调用线程A执行特定代码。
2. await/async语法糖与SynchronizationContext 的关系?
② 应用await时,框架捕获当前环境, 存储在SynchronizationContext 对象并附加于以上Task;
③ 同时,控制权返回到原上层调用函数,返回一个未完成的Task<int>对象,这个时候需要关注上层调用函数使用 await异步等待还是使用Result/Wait()方式同步等待
④ 异步任务T执行完成,await之后的代码将会成为continuation block, 默认情况下利用捕获的SynchronizationContext 对象执行该continuation block 代码。
内部实际是将continuation block代码放入 SynchronizationContext 的Post方法。
不同的.NET框架因各自独特的需求 有不同的 Post实现(Post是一个虚方法):
- 默认的SynchronizationContext.Post实现是将 委托通过QueueUserWorkItem传递给 ThreadPool。
- Windows Form有WindowsFormSynchronizationContext, Post方法将委托传递给 Control.BeginInvoke
- WPF 有DispatcherSynchronizationContext , Post方法将委托传递给 Dispatcher.BeginInvoke
3.引言代码为什么发生deadlock, 而ASP.NET Core为什么不会发生类似deadlock?
仔细观察引言代码,控制返回到 上层调用函数时, 该调用函数使用Result属性去等待任务结果,Result/Wait()等同步方式会导致调用线程挂起等待任务完成。而在异步方法内部,await触发的异步任务执行完成后,会尝试利用捕获的同步上下文执行剩余代码,而该同步上下文中的线程正同步等待整个异步任务完成,形成死锁。
正因为如此,我们提出:
- 在原调用函数始终 使用 await方法,这样该线程是异步等待 任务完成。
- 在异步任务内部应用ConfigureAwait(false)方法:
MSDN ConfigureAwait(): true to attempt to marshal the continuation back to the original context captured; otherwise, false
另外注意:ASP.NET Core不存在SynchronizationContext , 故不会发生类似的死锁。
总结:
虽然await/async 语法糖让我们在编写.NET 异步程序时得心应手、随心所欲,但是不要忘记了SynchronizationContext 在其中转承起合的作用。
利用能够保存当前执行代码的上下文特性,SynchronizationContext在线程切换后帮我们有能力执行各种骚操作。
以上是关于探究SynchronizationContext在.Net异步编程中的地位的主要内容,如果未能解决你的问题,请参考以下文章
SynchronizationContext.Current 在不同的应用程序域上运行时为空
SynchronizationContext.CreateCopy 的目的
利用SynchronizationContext.Current在线程间同步上下文