SynchronizationContext综述.docxVIP

多线程编程相当困难，而且要进行多线程编程需要了解无数概念和工具。???为此，Microsoft .NET Framework 提供了 SynchronizationContext 类。???很遗憾，很多开发人员甚至不知道这个有用的工具。 无论是什么平台（ASP.NET、Windows 窗体、Windows Presentation Foundation (WPF)、Silverlight 或其他），所有 .NET 程序都包含 SynchronizationContext 概念，并且所有多线程编程人员都可以通过理解和应用它获益。 SynchronizationContext 的必要性 多线程程序在 .NET Framework 出现之前就存在了。???这些程序通常需要一个线程将一个工作单元传递给另一个线程。???Windows 程序围绕消息循环进行，因此很多编程人员使用这一内置队列传递工作单元。???每个要以这种方式使用 Windows 消息队列的多线程程序都必须定义自己的自定义 Windows 消息以及处理约定。 当 .NET Framework 首次发布时，这一通用模式是标准化模式。???那时，.NET 唯一支持的 GUI 应用程序类型是 Windows 窗体。???不过，框架设计人员期待其他模型，他们开发出了一种通用的解决方案。?ISynchronizeInvoke 诞生了。 ISynchronizeInvoke 的原理是，一个“源”线程可以将一个委托列入“目标”线程队列，选择等待该委托完成。?ISynchronizeInvoke 还提供了一个属性来确定当前代码是否已在目标线程上运行；这样，就不必使委托继续排队。???Windows 窗体提供了唯一的 ISynchronizeInvoke 实现，并且开发了一种模式来设计异步组件，这样皆大欢喜。 .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。 SynchronizationContext 的概念 ISynchronizeInvoke 满足了两点需求：确定是否必须同步，使工作单元从一个线程列队等候另一个线程。???设计 SynchronizationContext 是为了替代 ISynchronizeInvoke，但完成设计后，它就不仅仅是一个替代品了。 一方面，SynchronizationContext 提供了一种方式，可以使工作单元列队列入上下文。??请注意，工作单元是列入?上下文?，而不是某个特定线程。???这一区别非常重要，因为很多 SynchronizationContext 实现都不是基于单个特定线程的。??SynchronizationContext 不包含用来确定是否必须同步的机制，因为这是不可能的。 SynchronizationContext 的另一方面是每个线程都有“当前”上下文。???线程上下文不一定唯一；其上下文实例可以与多个其他线程共享。???线程可以更改其当前上下文，但这样的情况非常少见。 SynchronizationContext 的第三个方面是它保持未完成操作的计数。???这样，就可以使用 ASP.NET 异步页面和需要此类计数的任何其他主机。???大多数情况下，捕获到当前 SynchronizationContext 时，计数递增；捕获到的 SynchronizationContext 用于将完成通知列队到上下文中时，计数递减。 SynchronizationContext 还有其他一些方面，但这些对大多数编程人员来说并不那么重要。???图 1???中列出了一些最为重要的方面。 图 1???Synchroni