Only Paranoid Can Survive

在前一篇中我们看到通过使用PowerThreading中的AsyncResult<T>类，我们可以很方便的将一个同步操作封装成异步的方式。同时使用这种方法和PInvoke，我们也可以为现有的C++设备库，如蓝牙设备提供一个.Net的异步类库。这样我们可以实现大部分对设备访问的.Net异步类库。

但当我们有特殊要求时，如果调整LCD亮度时，就需要调用Window API中的DeviceIoControl函数。PInvoke加上使用IO完成端口是件繁琐且容易出错的事情，幸运地是，我们有Richard，通过使用PowerThreading中的DeviceIO类，我们可以很方便的实现一个异步设备操作类。下面通过实现一个简单的异步打开光驱的方法，来看看如何使用Wintellect.IO.DeviceIO。

获得光驱句柄

在Win32中要访问一个设备，首先我们要调用CreateFile方法来获得该设备的文件句柄。PowerTheading中DeviceIO类对CreateFile进行了封装。我们可以容易通过创建一个DeviceIO对象来代表光驱。如下例：

DeviceIO有两个构造函数，主要区别在于第一个参数。我们可以传入文件路径，或者传入一个已获得的文件句柄。如果文件路径不对，或者访问方式不对，会抛出Win32Exception的异常。DeviceIO实现了IDisposable接口，当不需要使用时可以调用Dispose方法来释放文件句柄。CDDrive也实现了IDisposable接口，及Finalizer以确保光驱的句柄能够释放。

设备操作控制码

在Win32中，如果我们要向IO设备发出指令，需要调用DeviceIoControl方法。该方法需要设备文件句柄，操作控制码，传入数据及返回数据的Buffer。文件句柄在前面已经获得，而这个操作控制码在Win32中，是一个DWORD类型，代表了不同的操作，如打开光驱，调亮LCD等等。PowerThreading库中的DeviceControlCode 类可以帮助我们创建一个托管的结构。如弹出光驱的操作控制码IOCTL_STORAGE_EJECT_MEDIA定义如下：

操作控制码分为4个部分：设备类型，操作，设备方法及访问方式。这个与WinSDK中Winioctl.h中定义相同，我们可以根据这个头文件很容易的创建对应的DeviceControlCode结构。下面是IOCTL_STORAGE_EJECT_MEDIA在头文件中的定义：

在上面的IoControlCode静态类中，定义了4个操作控制码。这是因为如果我们弹出光驱或Eject可移动媒体，我们不能简单发出IOCTL_STORAGE_EJECT_MEDIA操作控制码，首先我们得发出FSCTL_LOCK_VOLUME锁住光驱以防止其他人写入，在发出FSCTL_DISMOUNT_VOLUME卸载卷，在发出IOCTL_STORAGE_MEDIA_REMOVAL移除媒体，最后才发出IOCTL_STORAGE_EJECT_MEDIA弹出光驱。具体可参考Microsoft KB 165721

发出设备操作

在第一步中，通过创建DeviceIO对象，我们已经获得了光驱的文件句柄。DeviceIO类提供了同步和异步的两套3个方法，来帮助我们发送操作到设备。同步方法内部实际调用的异步方法，所以下面我们看看3个异步方法：

如果操作不需要返回数据时，可以使用BeginControl；如有返回数据可调用BeginGetObject，TResult对应返回数据的类型；而当返回的数据是数组是可使用BeginGetArray，TElement是返回数组的元素类型。我们可以在http://pinvoke.net/ 网站或google上查找TResult和TElement对应的托管类型定义。下面是弹出光驱的代码：

上面的代码中，我们只使用了Control方法，其中IOCTL_STORAGE_MEDIA_REMOVAL需要传入数据。GetObject和GetArray的使用方法类似。

由于我们得循环的检查Lock是否成功，我们不得不使用线程池中的线程顺序的发出操作指令，因而该线程并没有最优化。如果我们都采取异步方式，我们不得不写很多回调或匿名函数，代码将变得很难看。这也是APM代码很麻烦的一个原因。后面的文章我们在来看看有没有更好的办法。

参考：

Asynchronous Device Operations by Jeffery Richard

KB165721: How To Ejecting Removable Media in Windows NT/Windows 2000/Windows XP by Microsoft

Note: 本篇主要内容来自Jeffery Richard的Implementing the CLR Asynchronous Programming Model，看过的同学可以略过。

在前一篇中介绍了使用APM开发多线程程序的有点，同时关于如何使用APM方式的文章也很多了。所以，这篇主要想看看如何使用Jeffery Richard的Power Threading类库，来开发一个支持APM的类。

为什么要自己实现APM

前一篇中，提到了受计算约束（Computing-Bound）与受I/O约束（I/O-Bound）的区别。如果我们是一个受计算约束类型的任务，完全可以将这个方法变成委托(Delegate）的形式，然后通过BeginInvoke/EndInvoke来实现APM；另外，FCL本身也封装了大量对I/O异步操作的类，如FileStream，NetworkStream等，那我们为什么还要自己实现APM呢。Jeffery Richard列举了4个原因：

1. 尽管FCL提供很多与设备通讯的异步类，但仍有部分未提供，如并口；或者FCL提供的功能不够
2. 对现有的I/O类库添加功能，如我们在WebHttpRequest可以开发一个HTTP的过滤类等
3. 实现受计算约束的APM
4. 对不支持异步模式设备提供异步访问方式

PowerThreading类库中的AsyncResult和AsyncResult<T>

APM的核心就是IAsyncResult接口。当调用类异步方式BeginXxx时，返回IAsyncResult的对象。为了返回满足这个接口的对象，我们的类需要维护的一个 是否完成的状态IsCompleted；一个ManuelResetEvent对象及一个委托保持回调函数。这些虽然比较简单，但很麻烦。使用PowerThreading类库中AsyncResult和AsyncResult<T>，我们可以非常容易的实现支持APM的类。

AsyncResult用于没有返回值，而AsyncResult<T>用于返回类型为T的任务。下面的例子中，我们看看如何使用AsyncResult<T>。

首先，我们准备实现一个能够过滤Stream对象的类，类定义如下：

Parse()是同步访问接口，执行主要的任务，而BeginParse()和EndParse()是对应的异步接口。下面是使用AsyncResult<T>后的代码

比较重要的是ParseHelper函数，这个函数在新的线程中执行，通过ar.SetAsCompleted来更新状态。 如果结合匿名方法或者Limbda表达式，代码可以变得更加的紧凑。

参考：

Implementing the CLR Asynchronous Programming Model by Jeffery Richard

Power Threading类库

在上一篇中我们分析了Win32和WinForm编写GUI应用程序会面对的主要问题。总结下来最重要的就是：如何高效的从Worker线程中更新界面。所以首先让我们看看WPF中是如何达到这个目的的。

DispatcherObject的使用

DispatcherObject类有两个成员方法，CheckAccess和VerifyAccess。CheckAccess功能和WinForm中Control.InvokeRequired属性相同，当调用线程与对象的创建线程不是同一个实例时，返回False。VerifyAccess则是抛出异常。

DispatcherObject还有一个Dispatcher的属性，返回控件的创建Dispatcher。通过其Invoke方法，我们可以将界面更新的操作Marshal到控件的创建线程。如下例：

CheckAccess()的实现方法类似于上篇的最后一个例子，通过比较两个线程实例，因而速度很快，只需要几个IL指令。继承DispatcherObject的类，在内部都调用VerifyAccess来做判断，因而当非创建线程调用时，就会抛出异常。这样的好处是我们可以较早的发现代码的问题，不像WinForm那样不确定的发生。

好了，下面我们来看看真正做事情的Dispatcher类，在这之前让我们再回顾一个Win32的消息循环。

Win32 消息循环

在Win32中，消息Pump的建立是通过循环的调用GetMessage，当收到WM_Quit类型的消息是，退出。而我们对窗口或控件属性的修改，如颜色，位置都实际都是调用PostMessage或SendMessage。当调用线程与窗口的Owner线程是同一个，则SendMessage直接调用窗口函数；如不同则将消息放置在窗口对应的消息队列中，由GetMessage取出并进行处理。WinForm实际是建立在Win32的基础上，所以当我们写lable.Text = "Hello World"时，实际是调用了PostMessage等方法。

下面我们看看Win32消息队列的特点和限制：

1. 任劳任怨的从消息队列中拿出消息，并调用对应的窗口处理函数
2. 当消息Post进队列后就无法控制了
3. 消息的处理支持有限的优先级，但都由OS控制，用户代码不能控制和改变优先级
4. Application.DoEvents只有在处理完消息队列中所有消息后才返回，当然Win32没有这个限制，因为Message Pump就是用户创建的
5. 可以添加钩子，偷偷的干些坏事

WPF中的Dispatcher的主要功能类似于Win32中消息队列，当并不是替换消息循环，而是建立在消息循环之上。首先，让我们看看Dispatcher的结构：

线程相关的Dispatcher的创建

当我们在一个线程上第一次创建WPF对象时，DispatcherObject构造函数会调用Dispatcher.CurrentDispatcher赋值给私有变量_dispatcher。Dispatcher.CurrentDispatcher通过Thread.CurrentThread来找到该线程对应的Dispatcher实例，如不存在则创建一个。Dispatcher的构造函数，首先创建了一个具有11个级优先级（DispatcherPriority）的优先队列PriorityQueue，这个优先队列用来保存不同优先级的操作。然后调用Win32 API RegisterClassEx注册窗口处理函数，并调用CreateWindowEx创建一个不可见的窗口。

Dispatcher有两个静态方法用来建立消息循环，定义如下：

尽管是静态方法，实际上是调用当前线程对应的Dispatcher实例的方法。Application.Run()内部实际就是调用了Dispatcher.Run()，进而调用Dispatcher.PushFrame(…)。当我们创建一个WPF项目时，VS自动生成的App.xaml，编译后的代码为

当调用PushFrame()或Run()后，内部开始循环调用Win32 GetMessage方法，而建立消息循环。如下面的例子中，在VS缺省的WPF项目中，创建了一个新的线程，在该线程中创建一个新的WPF窗口，并启动消息循环：

消息循环的控制

上个例子中，我们也可以使用PushFrame方法。相比于Run()，我们可以通过PushFrame的参数DispatcherFrame对象来控制什么时候退出消息循环。如需退出当前层的循环，只需将对应的DispatcherFrame.Continue赋值false。我们可以嵌套的调用PushFrame，这点上类似Application.DoEvents，更具灵活性，但我们仍不能只要求处理特定优先级的消息。

另外可以调用Dispatcher.ExitAllFrames方法退出当前线程的所有消息循环。Dispatcher还提供一个方法DisableProcessing，该方法可以暂停消息循环处理消息。下面是这个方法的使用方法:

该方法返回的DispatcherProcessingDisabled对象实现了IDisposable接口，在Dispose中恢复消息循环。该方法也可以嵌套的调用。

下面我们来看看如何投递消息，及Dispatcher如何处理的。

Dispatcher优先队列

Dispatcher的Invoke和BeginInvoke方法，用来向Dispatcher的优先队列放置任务，前者是同步方法，后者是异步。这两个方法，第二个参数是个delegate对象，代表要执行的任务。第一个参数定义任务的优先级，具体定义可以看DispatcherPriority枚举类型。总的来说，我们可以划分为两类，Background和Foreground，另一个比较特殊的是DispatcherPriority.Send。

当在Invoke中指定Send时，且CheckAccess为真，则Invoke直接调用delegate执行任务。如果不是，则调用BeginInvoke，并等待结果，或超时。

BeginInvoke执行时，首先将该任务封装成DispatcherOperation对象，并放置在对应的优先队列中。然后判断是Background还是Foreground，如果是Foreground，则调用PostMessage往Win32消息队列中投递一条消息，然后返回。如果是Background，则检查是否有Timer，如没有则创建一个Timer，Timer会不断循环的投递消息到Win32消息队列，来触发消息的处理。当有Foreground消息是，则删掉Timer。通过这种方式，系统在空闲的时候可以处理Background消息。

当有Win32消息投递到Win32队列时，注册的窗口函数被执行，从优先队列中取出一个DispatcherOperation来执行。完成后，则投递新的Win32消息来触发下次执行，或等待Timer消息。

BeginInvoke的返回值则为DispatcherOperation对象，通过她我们可以取消，等待，或者调整该任务的优先级。在后面的系列中，我们在具体看不同Foreground优先级的使用。

优先队列钩子Hook

与Win32类似，我们也可以对消息的处理添加Hook，可以添加下面的Event Handler：

1 Dispatcher.CurrentDispatcher.Hooks.OperationAborted += new DispatcherHookEventHandler(Hooks_OperationAborted); 
2 Dispatcher.CurrentDispatcher.Hooks.OperationCompleted += ; 
3 Dispatcher.CurrentDispatcher.Hooks.OperationPosted += ; 
4 Dispatcher.CurrentDispatcher.Hooks.OperationPriorityChanged +=  

Event Handler的参数中，我们可以获得对应的Dispatcher和DispatcherOperation对象。通过这种办法，我们可以过滤，查询或改变任务的优先级等操作。

DispatcherTimer

DispatcherTimer类似WinForm中的Timer。我们可以在构造函数中指定优先级，Dispatcher实例等等。

总结

总的来说，与Win32比较，如果给WPF中的线程和消息循环的机制打分的话，我觉得可以打4分的高分。WPF解决了Win32中没有优先级，跨线程调用性能的问题，友好的编程接口。如果说不足的话，如果PushFrame可以支持优先级，对Reentrancy的问题，可能能更好的控制；另外，DispatcherOperation无法获得名字，如我们要开发一个队列监视程序的话很不方便。这些我认为可以扣0.5分，那另外0.5分是什么呢？

最后，如果我们看这些类的话，全部都在Windowsbase.dll中，也就是说System.Windows.Threading中的类，如DispatcherObject，Dispatcher也可以用于其他系统中。我们甚至可以利用这些在我们的系统中。

用Reflector分析WPF时，发现几乎所有的类的继承自DispatcherObject类。而该类非常简单，只有CheckAccess和VerifyAccess两个方法，一个Dispatcher只读属性和一个私有成员变量。正是由于继承了这个类，使WPF中其他类具有了多线程处理的能力。

在分析DispatcherObject前，我们先看看一般Win32或WinForm GUI应用程序中存在的问题和解决办法。

"没有响应"：Message Pump被阻塞

使用Windows时，最常碰到的问题就是窗口没有响应的。OS发现一个窗口一定时间内没有处理消息队列时，OS就会显示该窗口"没有响应"。

消息队列是OS为窗口创建的一个线程相关的内部结构。所有对窗口的操作，如鼠标移到，键盘输入等，最终都是在该队列中添加了一条消息。一般我们称创建主窗口的线程为UI线程，该线程创建Message Pump，负责不断的从消息队列中读取消息事件，并执行相应的窗口函数。

在Win32中，是通过调用GetMessage或PeekMessage来读取队列中的消息，并执行窗口处理函数WinProc。WinFom是对Win32 API封装，Application.Run()建立了Message Pump，从队列中读取消息，并调用对应的Event Handler。正是由于Windows这样的设计，如果Event Handler耗时很长时，UI线程无法继续处理消息队列中的其他消息（如WM_Paint），从而窗口没有响应或更新。这就是GUI应用程序中常碰到的Message Pump被阻塞的问题。

如下面的例子，在Button.Click Event Handler中，我们从数据库或文件中读出数据，并将每条记录加入List列表中。由于Message Pump被阻塞，UI线程无法处理WM_Paint消息，因而List只有在所以数据都加入后，才会更新显示。

解决办法之一：Application.DoEvents

既然问题是由于没有处理消息队列造成的，那么比较直接的一个办法就是调用GetMessage或PeekMessage。WinForm中对于的函数就是Application.DoEvents()方法。

似乎这样就解决问题了，但是上面的方法实际上引入了一个更严重的问题：Reentrancy。

运行上面的程序，我们先点击一次按钮，button1_Click被调用，listBox1.Items.Clear()清空列表，然后开始添加数据到列表。如果这个时候，我们再次点击按钮，一个Button Click消息被加入到消息队列。在没有调用Application.DoEvents时，这条新的消息只有在button1_Click处理完后，才会被调用。这样尽管界面有段时间没有响应，但list中的数据仍能保持完整。当我们加入Application.DoEvents()后，在第一次处理button1_Click过程中，新的消息再次被处理，button1_Click第二次被调用，同样listBox1被清空。但是由于第一次的button1_Click还执行完，后面的Add动作仍会在第二次button1_Click都执行完成后执行，List就变成了1,2,3,4,5,6,4,5,6。而这种行为造成程序不稳定性，有时候数据是好的，有时候又有重复的数据。

造成Reentrancy问题原因是由于DoEvents会处理消息队列中的所有消息，如果DoEvents能够提供只处理WM_Paint事件的话，就不会有这个问题。但是由于消息队列结构的设计不完全支持优先级，所以Win32或WinForm没法解决这个问题。

解决办法之二：拆分复杂的操作

另一个解决办法就是把复杂的操作拆分成很多小的操作，每次只执行一部分。这种办法主要有两个问题：不易拆分或增加了代码的难度，如何调用这些小的操作。如上面的例子中，我们在button1_Click中，我们创建一个System.Windows.Forms.Timer对象，在Tick事件中来添加list的Item。

这种办法有比较大的局限，而且同样会存在Reentrancy的问题。

解决办法之三：多线程

在看多线程前，让我们看看创建一个线程的消耗：

1. 创建Thread核心对象（128K?），保留1M的Thread Stack地址空间
2. CPU Task Manager多一个Task
3. 线程切换非常耗时

是的，如果是单CPU的机器，多线程就意味着性能降低，因为CPU增加了额外的工作。我们需要多线程的原因就是因为UI线程必须能够释放出来去处理消息队列。

在Win32开发中，我们可以调用CreateThread来创建一个线程(Worker线程)，来处理耗时的操作，在.Net中对应的就是创建一个Thread对象。这种办法的问题是，每次创建一个Thread，OS都会创建Thread对象，而使用完后该Thread就会被销毁。创建销毁线程对象都是耗时的工作。.Net提供了线程池，可以重复利用线程来提高性能。我们可以用ThreadPool类，或者Delegate的BeginInvoke来使用.Net线程池。

于是，上面的代码很自然的就改为：

于是编译执行上面的代码，噢，没有问题。但是当你发布给用户时，用户就会抱怨，这个程序有时候突然就没了，于是噩梦就开始了。造成这个问题的原因就是由于Worker线程访问了控件，窗口等GDI对象。为了帮助找到这种问题，在用VS2008调试上面程序时，程序会报Cross-Operation的异常。但是，在Release版本中，程序就会崩溃，并且没有好的工具或方法能够找到这个问题。所以，在设计代码时，就一定注意避免Worker线程访问控件。

为什么Windows会有这样的限制呢？我想这个主要是由于性能的考虑。如果Windows GDI对象要支持多线程的访问，则每次访问时都需要lock来保证数据的完整性，不然界面的行为就会很怪异，每次GDI操作都判断lock的话，界面将会非常非常的慢。如果不用lock的方式，而采用判断Thread.ID的方式，那么每个对象都必须在创建时有个成员变量来保存Thread ID。在Windows 32的时代，内存是很宝贵的资源，所以Windows选择了忽略这个问题也是可以理解的。

那么，我们如何可以解决这个问题呢？在WinForm中，定义了一个ISynchronizeInvoke的接口，Control实现了这个接口。该接口中InvokdRequired属性，用来判断调用线程是否是Control的创建线程，而BeginInvoke和Invoke方法，这是会发消息到Control对应的消息队列，来告诉UI线程来更新Control。于是，上面的代码就变成：

一切似乎很完美了，当在Worker线程上调用updateList时，listBox1.InvokeRequried返回True，调用listBox1.Invoke()，Worker线程会等待Invoke()返回，而Invoke()则会调用Win32 API SendMessage()给UI线程的消息队列，UI线程再次调用UpdateList更新ListBox后返回。

当然，如果我们不想Worker线程被阻塞的话，可以通过调用BeginInvoke()和EndInvoke()的异步方法。不过，不管那种方式，代码都会变得比较难看。而且，尽管InvokeRequired是个属性，实际上，会执行很多操作。InvokeRequired拿到调用线程的ID，然后尝试去得到Control的创建线程ID。而得到Control的创建线程ID会是一个耗时的操作。因为Control创建时并没有保存线程ID到成员变量中。所以InvokeRequired会遍历Control的父Control，一层层，直到找到最外面的父窗口。因而InvokeRequired是一个耗时的操作。

为了解决InvokeRequired的性能问题，我们可以在创建窗口的时候，保存一个Thead的引用，然后再来判断，于是代码变为：

 1 public partial class Form1 : Form
 2 {
 3    private Thread ownerThread;
 4    public Form1()
 5    {
 6       InitializeComponent();
 7       updateList = new UpdateUICallBack(UpdateList);
 8       ownerThread = Thread.CurrentThread;
 9    }
10 
11    private Boolean CheckAccess()
12    {
13       return ownerThread == Thread.CurrentThread;
14    }
15 
16    private void VerifyAccess()
17    {
18       if (!CheckAccess())
19          throw new Exception("Invoke Needed");
20    }
21 
22    private void UpdateList(Int32 value)
23    {
24       if (!CheckAccess())
25          listBox1.Invoke(updateList, new Object[] { value });
26       else
27          listBox1.Items.Add(value);
28    }
29 }

好了，上面差不多分析了当前WinForm或Win32 GDI编程的主要问题，下一个Post，让我们来看看WPF是如何解决这些问题的。