【转帖】wpf线程处理模型

huangyhg

http://blog.csdn.net/iwteih/article/details/4646620
  http://msdn.microsoft.com/zh-cn/library/ms741870.aspx
   Windows Presentation Foundation
   线程处理模型
      
  
   更新：2007 年 11 月
  
    Windows Presentation Foundation (WPF) 旨在帮助开发人员解决线程处理的难题。这样，大多数 WPF 开发人员就不必编写使用多个线程的接口。由于多线程程序很复杂且难以调试，因此只要存在单线程解决方案，就应避免使用多个线程。
  
   但是，无论体系结构多么完善，没有任何 UI 框架能够为每一类问题提供单线程解决方案。WPF  接近这一目标，但是在某些情况下，仍然可通过采用多个线程来提高 用户界面 (UI)  响应度或应用程序性能。在讨论了一些背景材料后，本文将探讨其中一些情况，最后从较低层次进行一些详细讨论。
  
   
  
   本主题包括下列各节。
  
   

• 概述和调度程序
  
• 操作中的线程：示例
  
• 技术细节和难点
  
• 相关主题
  

概述和调度程序
    通常，WPF 应用程序从两个线程开始：一个用于处理呈现，一个用于管理 UI。呈现线程有效地隐藏在后台运行，而 UI  线程则接收输入、处理事件、绘制屏幕以及运行应用程序代码。大多数应用程序都使用一个 UI  线程，但在某些情况下，最好使用多个线程。我们将在后面举例说明这一点。
  
   UI 线程对一个名为 Dispatcher</a> 的对象内的工作项进行排队。Dispatcher 基于优先级选择工作项，并运行每一个工作项，直到完成。每个 UI 线程都必须至少有一个 Dispatcher，并且每个 Dispatcher 都只能在一个线程中执行工作项。
  
   要构建响应速度快、且用户友好的应用程序，诀窍是减小工作项，以最大限度地提高 Dispatcher 吞吐量。这样，工作项将永远不会因为在 Dispatcher 队列中等待处理而失效。输入与响应之间的任何可察觉的延迟都会使用户不快。
  
   那么，WPF 应用程序应如何处理大型操作呢？如果您的代码涉及大型计算，或者需要查询某台远程服务器上的数据库，应怎么办呢？通常的办法是在单独的线程中处理大型操作，而专门让 UI 线程来负责处理 Dispatcher 队列中的工作项。当大型操作完成时，可以将结果报告给 UI 线程来显示。
  
   一直以来，Windows 只允许创建 UI  元素的线程访问这些元素。这意味着负责某项长时间运行任务的后台线程无法更新已完成的文本框。Windows 这样做是为了确保 UI  组件的完整性。如果列表框的内容在绘制过程中被后台线程更新，那么该列表框看上去将会很奇怪。
  
   WPF 使用一种内置互斥机制来强制执行这种协调。WPF 中的大多数类都派生自 DispatcherObject。DispatcherObject 在构造时存储对链接到当前所运行线程的 Dispatcher 的引用。实际上，DispatcherObject 与创建它的线程关联。在程序执行过程中，DispatcherObject 可以调用它的公共 VerifyAccess 方法。VerifyAccess 检查与当前线程关联的 Dispatcher，并将它与构造过程中存储的 Dispatcher 引用进行比较。如果两者不匹配，VerifyAccess 将引发异常。VerifyAccess 用于在每个属于 DispatcherObject 的方法的开头调用。
  
   如果只有一个线程可以修改 UI，那么后台线程如何与用户交互呢？后台线程可以请求 UI 线程代表它执行操作。这是通过向 UI 线程的 Dispatcher 注册工作项来完成的。Dispatcher 类提供两个注册工作项的方法：Invoke 和 BeginInvoke。这两个方法均调度一个委托来执行。Invoke 是同步调用，也就是说，直到 UI 线程实际执行完该委托它才返回。BeginInvoke 是异步的，将立即返回。
  
   Dispatcher 按优先级对其队列中的元素进行排序。向 Dispatcher 队列中添加元素时可指定 10 个级别。这些优先级在 DispatcherPriority 枚举中维护。有关 DispatcherPriority 级别的详细信息可以在 Windows SDK 文档中找到。