最近在研究.net4.5中的有关异步编程的新特性,从自己Google Reader 订阅的一些博客中接触到了两个很陌生的单词ExecutionContext和SynchronizationContext,于是仔细研究了一下,记录下来备忘。
什么是ExecutionContext
在许多系统中thread-local storage(TLS)线程本地存储记录了正在运行的当前环境或者上下文的一些信息,而在CLR中ExecutionContext做了类似的事情.在同步的世界中,所有的一切都发生在当前线程内,线程内有关的所有数据对其内所有代码可见,也同时被所有代码所操纵影响.也就是说假设有方法ABC在当前线程内顺序执行,当前线程环境的一切信息对ABC都是可见的,同时ABC又影响着这些当前线程环境.但是在异步的世界情况变了,还假设有方法ABC,这三个方法有可能运行在不同的线程中,ABC三者是相互见不到对方线程信息的,所以需要在每个异步点传递当前线程环境信息到另一个线程中,另一个线程中的方法才能访问该线程中数据信息并且修改这些信息.完成这个任务就需要ExecutionContext记录当前线程环境然后再另一个线程中restore出来. 情况类似于这样:

// 记录当前的环境信息到ec, 这些信息会在委托调用时通过静态的方法Run恢复出来
ExecutionContext ec = ExecutionContext.Capture(); 


ExecutionContext.Run(ec, delegate 
{ 
… // 在这的代码就能看见ec中的环境信息了。
}, null);

在.Net FrameWork中所有处理异步情况的方法都会通过类似的方法Capture/Restore ExecutionContext(不包括unsafe代码),比如Task.Run,ThreadPool.QueueUserWorkItem,Delegate.BeginInvoke,Stream.BeginRead,DispatcherSynchronizationContext.Post 

比如Task.Run,当我们调用Run时,背后所做的事就是ExecutionContext.Capture()捕获当前线程环境,然后在Run中的delegate方法执行的时候把环境还原。

什么是SynchronizationContext

程序员都很热衷与抽象,对硬编码深恶痛绝,分层和抽象会为我们日后维护和扩展系统带来极大的便利,这也就是为什么会有接口,抽象类,和虚方法。而SynchronizationContext也是一种抽象。打个比方,当我们编写WinForm程序时,为避免后台处理海量数据带来的UI界面假死状态,通常会重开线程或者将这些工作放入线程池等,任务完成之后把处理的结果封送返回给UI线程时,通常会用Control.BeginInvoke方法。但是这种情况如果发生在WPF和Silverlight程序中呢,封送处理又得用Dispatcher.BeginInvoke或者InvokeAsync.ASP.Net又是另一种情况。于是我们使用了不同了方法完成了相同的动作,那么对于不同的UI框架我们怎么处理这些相同事件呢?于是抽象的想法来了,这就是SynchronizationContext。它提供了一个虚方法Post(),这个方法会接收委托方法并且执行它。而对于WinForm的情况会提供WinFormSynchronizationContext,它会覆盖掉虚方法Post(),并且在子类中Post()调用Control.BeginInvoke;对于WPF或者Silverlight,会提供子类DispatcherSynchronizationContext,同样覆盖掉虚方法Post(),并且在子类Post中调用Dispatcher.Run。

public static void DoWork(Control c) 
{ 
ThreadPool.QueueUserWorkItem(delegate 
    { 
..... c.BeginInvoke(delegate { .....//对UI的操作 }); }); } 如果替换成SynchronizationContext去写就成了这样: public static void DoWork(SynchronizationContext sc) { ThreadPool.QueueUserWorkItem(delegate { … // do work on ThreadPool sc.Post(delegate { … // do work on UI }, null); }); }
或者如下
public static void DoWork() { var sc = SynchronizationContext.Current; ThreadPool.QueueUserWorkItem(delegate { … // do work on ThreadPool sc.Post(delegate { … // do work on the original context }, null); }); }

 

ExecutionContext VS SynchronizationContext

对比两者你会发现它们都会在异步操作时捕获当前线程环境上下文,但后续操作不一样,ExecutionContext会调用delegate方法并在执行时在另一个线程中恢复该线程环境状态。而SynchronizationContext仅仅是用当前捕获的环境信息去调用委托方法,这个委托方法怎么什么时候执行,在哪执行,怎么执行都取决于底层的具体实现。

注意:

 以下CodeProject文章中有一点讲得不太准确,根据惯例,如果一个线程的当前 SynchronizationContext 为 null,那么它隐式具有一个默认 SynchronizationContext。默认 SynchronizationContext 将其异步委托列队到 ThreadPool,但在调用线程上直接执行其同步委托。因此,其上下文包含所有 ThreadPool 线程以及调用 Send 的任何线程。此上下文“借用”调用 Send 的线程,将它们放入其上下文,直至委托完成。从这种意义上讲,默认上下文可以包含进程中的所有 线程。所以UI应用程序通常有两个同步上下文,一个是UI线程的SynchronizationContext,另一个是包含ThreadPool线程的默认SynchronizationContext。

 

一般遇到疑问,首先去百度国内论坛,但是继而回去CodeProject相关文章去佐证,好多文章都是从Codeproject上翻译或者浓缩出来的,但这次事件我才发现CodeProject上文章也不靠谱,虽然那上边有好多微软MVP和其他大公司的技术人员,微软的东西还是得去MSDN blog或者 MSDN Magzine上比较靠谱,尤其是看到Anders Hejlsberg, Stephen Toub, Erick Lippert, Herb Sutter审阅,就知道这是质量的保证。备忘完毕,还有半天时间,接着去深挖这块东西。

 

reference:
http://blogs.msdn.com/b/pfxteam/archive/2012/06/15/executioncontext-vs-synchronizationcontext.aspx
http://www.codeproject.com/Articles/31971/Understanding-SynchronizationContext-Part-I
http://msdn.microsoft.com/zh-cn/magazine/gg598924.aspx
http://msdn.microsoft.com/zh-cn/magazine/hh456402.aspx

posted on 2012-06-28 11:47  salomon  阅读(4652)  评论(1编辑  收藏  举报