[转载]IOCP编程之基本原理

原文地址：http://gamebabyrocksun.blog.163.com/blog/static/57153463201036104134250/

要想彻底征服IOCP，并应用好IOCP这个模型，首先就让我们穿越到遥远的计算机青铜器时代（以出现PC为标志），那时候普通的PC安装的还是DOS平台，微软公司主要靠这个操作系统在IT界的原始丛林中打拼，在DOS中编写程序，不得不与很多的硬件直接打交道，而最常操作的硬件无非是键盘、声显卡、硬盘等等，这些设备都有一个特点就是速度慢，当然是相对于PC平台核心CPU的速度而言，尤其是硬盘这个机械电子设备，其速度对于完全电子化得CPU来说简直是“相对静止”的设备。很多时候CPU可以干完n件（n>1000）事情的时间中，这些硬件可能还没有完成一件事情，显然让CPU和这些硬件同步工作将是一种严重的浪费，并且也不太可能，此时，聪明的硬件设计师们发明了一种叫做中断的操作方式，用以匹配这种速度上的严重差异。中断工作的基本原理就是，CPU首先设置一个类似回调函数的入口地址，其次CPU对某个硬件发出一个指令，此时CPU就去干别的活计了，最后那个慢的象蜗牛一样的硬件执行完那个指令后，就通知CPU，让CPU暂时“中断”手头的工作，去调用那个“回调函数”。至此一个完整的中断调用就结束了。这个模型曾经解决了显卡与CPU不同步的问题，最重要的是解决了硬盘速度与CPU速度严重不匹配的问题，并因此还派生出了更有名的DMA（直接内存访问技术，主要是指慢速硬件可以读写原本只能由CPU直接读写的内存）硬盘IO方式。（注意这里说的中断工作方式只是中断工作方式的一种，并不是全部，详细的中断原理请参阅其它专业文献。）

其实“中断”方式更像是一种管理模型，比如在一个公司中，如果要老板时时刻刻盯着员工作事情，那么除非是超人，否则无人能够胜任，同时对于老板这个稀缺资源来说也是一种极起严重的浪费。更多时候老板只是发指令给员工，然后员工去执行，而老板就可以做别的事情，或者干脆去打高尔夫休息，当员工完成了任务就会通过电话、短信、甚至e-mail等通知老板，此时老板就去完成一个响应过程，比如总结、奖罚、发出新指令等等。由此也看出如果一个公司的“老板占用率”（类似CPU占用率）太高，那么就说明两种情况：要么是它的员工很高效，单位时间内完成的指令非常多；要么是公司还没有建立有效的“中断”响应模型。如果你的公司是后者，那么你就可以试着用这个模型改造公司的管理了，由此你可以晋升到管理层，而不用再去管你的服务端程序有没有使用IOCP了，呵呵呵。

如果真的搞明白了这个传说中的“中断”操作方式，那么理解IOCP的基本原理就不费劲了。

结束了计算机的青铜时代后，让我们穿越到现在这个“计算机蒸汽”时代，（注意不是“计算机IT”时代，因为计算机还没法自己编写程序让自己去解决问题）。在现代，Windows几乎成了PC平台上的标准系统，而PC平台上的几大件还是没有太大的变化，除了速度越来越快。而因为操作系统的美妙封装，我们也不用再去直接同硬件打交道了，当然编写驱动程序的除外。

在Windows平台上，我们不断的调用着WriteFile和ReadFile这些抽象的函数，操作着“文件”这种抽象的信息集合，很多时候调用这些函数时，是以一种“准同步”的方式操作硬件的，比如要向一个文件中写入1M的信息，只有等到WriteFile函数返回，操作才算结束，这个过程中，我们的程序则类似死机一样，等待硬盘写入操作的结束（实际是被系统切换出了当前的CPU时间片）。于此同时，调用了WriteFile的线程则无法干别的任何事情。因为整个线程是在以一种称为过程化的模型中运行，所有的处理流程全部是线性的。对于程序的流畅编写来说，线性化的东西是一个非常好的东西，甚至几乎早期很多标准的算法都是基于程序是过程化得这一假设而设计的。而对于一些多任务、多线程环境来说，这种线性的工作方式会使系统严重低效，甚至造成严重的浪费，尤其在现代多核CPU已成为主流的时候，显然让一个CPU内核去等待另一个CPU内核完成某事后再去工作，是非常愚蠢的一种做法。

面对这种情况，很多程序员的选择是多线程，也就是专门让一个线程去进行读写操作，而别的线程继续工作，以绕开这些看起来像死机一样的函数，但是这个读写线程本身还是以一种与硬盘同步的方式工作的。然而这并不是解决问题的最终方法。我们可以想象一个繁忙的数据库系统，要不断的读写硬盘上的文件，可能在短短的一秒钟时间就要调用n多次WriteFile或ReadFile，假设这是一个网站的后台数据库，那么这样的读写操作有时还可能都是较大的数据块，比如网站的图片就是比较典型的大块型数据，这时显然一个读写线程也是忙不过来的，因为很有可能一个写操作还没有结束，就会又有读写操作请求进入，这时读写线程几乎变成了无响应的一个线程，可以想象这种情况下，程序可能几乎总在瘫痪状态，所有其它的线程都要等待读写操作线程完活。也许你会想多建n个线程来进行读写操作，其实这种情况会更糟糕，因为不管你有多少线程，先不说浪费了多少系统资源，而你读写的可能是相同的一块硬盘，只有一条通道，结果依然是一样的，想象硬盘是独木桥，而有很多人（线程）等着过桥的情形，你就知道这更是一个糟糕的情形。所以说在慢速的IO面前，多线程往往不是“万灵丹”。

面对这种情形，微软公司为Windows系统专门建立了一种类似“青铜时代”的中断方式的模型来解决这个问题。当然，不能再像那个年代那样直接操作硬件了，需要的是旧瓶装新酒了。微软是如何做到的呢，实际还是通过“回调函数”来解决这个问题的，大致也就是要我们去实现一个类似回调函数的过程，主要用于处理来自系统的一些输入输出操作“完成”的通知，相当于一个“中断”，然后就可以在过程中做输入输出完成的一些操作了。比如在IO操作完成后删除缓冲，继续发出下一个命令，或者关闭文件，设备等。实际上从逻辑的角度来讲，我们依然可以按照线性的方法来分析整个过程，只不过这是需要考虑的是两个不同的函数过程之间的线性关系，第一个函数是发出IO操作的调用者，而第二个函数则是在完成IO操作之后的被调用者，。而被调用的这个函数在输入输出过程中是不活动的，也不占用线程资源，它只是个过程（其实就是个函数，内存中的一段代码而已）。调用这些函数则需要一个线程的上下文，实际也就是一个函数调用栈，很多时候，系统会借用你进程空间中线程来调用这个过程，当然前提条件是事先将可以被利用的线程设置成“可警告”状态，这也是线程可警告状态的全部意义，也就是大多数内核同步等待函数bAlertable（有些书翻译做可警告的，我认为应该理解为对IO操作是一种“时刻警惕”的状态）参数被传递TRUE值之后的效果。比如：WaitForSingleObjectEx、SleepEx等等。

当然上面说的这种方式其实是一种“借用线程”的方式，当进程中没有线程可借，或者可借的线程本身也比较忙碌的时候，会造成严重的线程争用情况，从而造成整体性能低下，这个方式的局限性也就显现出来了。注意“可警告”状态的线程，并不总是在可以被借用的状态，它们本身往往也需要完成一些工作，而它调用一些能够让它进入等待状态的函数时，才可以被系统借用，否则还是不能被借用的。当然借用线程时因为系统有效的保护了栈环境和寄存器环境，所以被借用的线程再被还回时线程环境是不会被破坏的。

鉴于借用的线程的不方便和不专业，我们更希望通过明确的“创建”一批专门的线程来调用这些回调函数（为了能够更深入的理解，可以将借用的线程想象成出租车，而将专门的线程想象成私家车），因此微软就发明了IOCP“完成端口”这种线程池模型，注意IOCP本质是一种线程池的模型，当然这个线程池的核心工作就是去调用IO操作完成时的回调函数，这就叫专业！这也是IOCP名字的来由，这就比借用线程的方式要更加高效和专业，因为这些线程是专门创建来做此工作的，所以不用担心它们还会去做别的工作，而造成忙碌或不响应回调函数的情况，另外因为IO操作毕竟是慢速的操作，所以几个线程就已经足可以应付成千上万的输入输出完成操作的请求了（还有一个前提就是你的回调函数做的工作要足够少），所以这个模型的性能是非常高的。也是现在Windows平台上性能最好的输入输出模型。它首先就被用来处理硬盘操作的输入输出，同时它也支持邮槽、管道、甚至WinSock的网络输入输出。