I/O Completion Port(I/O完成对象)的原理与实现

转自：http://blog.sina.com.cn/s/blog_6c12a0110100oklh.html

在看《Win32多线程程序设计》第6章中关于I/O Completion Port的内容时，遇到一些问题，在网上找到两篇较好的文章：

第一篇：

理解I/O Completion Port

欢迎阅读此篇IOCP教程。我将先给出IOCP的定义然后给出它的实现方法，最后剖析一个Echo程序来为您拨开IOCP的谜云，除去你心中对IOCP的烦恼。OK，但我不能保证你明白IOCP的一切，但我会尽我最大的努力。以下是我会在这篇文章中提到的相关技术：
　　I/O端口
　　同步/异步
　　堵塞/非堵塞
　　服务端/客户端
　　多线程程序设计
　　Winsock API 2.0

　　在这之前，我曾经开发过一个项目，其中一块需要网络支持，当时还考虑到了代码的可移植性，只要使用select,connect,accept,listen,send还有recv,再加上几个#ifdef的封装以用来处理Winsock和BSD套接字[socket]中间的不兼容性，一个网络子系统只用了几个小时很少的代码就写出来了，至今还让我很回味。那以后很长时间也就没再碰了。

　　前些日子，我们策划做一个网络游戏，我主动承担下网络这一块，想想这还不是小case,心里偷着乐啊。网络游戏好啊，网络游戏为成百上千的玩家提供了乐趣和令人着秘的游戏体验，他们在线上互相战斗或是加入队伍去战胜共同的敌人。我信心满满的准备开写我的网络，于是乎，发现过去的阻塞同步模式模式根本不能拿到一个巨量多玩家[MMP]的架构中去，直接被否定掉了。于是乎，就有了IOCP，如果能过很轻易而举的搞掂IOCP，也就不会有这篇教程了。下面请诸位跟随我进入正题。


什么是IOCP？
先让我们看看对IOCP的评价
I/O完成端口可能是Win32提供的最复杂的内核对象。
[Advanced Windows 3rd] Jeffrey Richter
这是[IOCP]实现高容量网络服务器的最佳方法。
[Windows Sockets2.0:Write Scalable Winsock Apps Using Completion Ports] 
Microsoft Corporation
完成端口模型提供了最好的伸缩性。这个模型非常适用来处理数百乃至上千个套接字。
[Windows网络编程2nd] Anthony Jones & Jim Ohlund
I/O completion ports特别显得重要，因为它们是唯一适用于高负载服务器[必须同时维护许多连接线路]的一个技术。Completion ports利用一些线程，帮助平衡由I/O请求所引起的负载。这样的架构特别适合用在SMP系统中产生的”scalable”服务器。
[Win32多线程程序设计] Jim Beveridge & Robert Wiener 


看来我们完全有理由相信IOCP是大型网络架构的首选。那IOCP到底是什么呢？

　　微软在Winsock2中引入了IOCP这一概念 。IOCP全称I/O Completion Port，中文译为I/O完成端口。IOCP是一个异步I/O的API，它可以高效地将I/O事件通知给应用程序。与使用select()或是其它异步方法不同的是，一个套接字[socket]与一个完成端口关联了起来，然后就可继续进行正常的Winsock操作了。然而，当一个事件发生的时候，此完成端口就将被操作系统加入一个队列中。然后应用程序可以对核心层进行查询以得到此完成端口。

　　这里我要对上面的一些概念略作补充，在解释[完成]两字之前，我想先简单的提一下同步和异步这两个概念，逻辑上来讲做完一件事后再去做另一件事就是同步，而同时一起做两件或两件以上事的话就是异步了。你也可以拿单线程和多线程来作比喻。但是我们一定要将同步和堵塞，异步和非堵塞区分开来，所谓的堵塞函数诸如accept(…)，当调用此函数后，此时线程将挂起，直到操作系统来通知它，”HEY兄弟，有人连进来了”，那个挂起的线程将继续进行工作，也就符合”生产者-消费者”模型。堵塞和同步看上去有两分相似，但却是完全不同的概念。大家都知道I/O设备是个相对慢速的设备，不论打印机，调制解调器，甚至硬盘，与CPU相比都是奇慢无比的，坐下来等I/O的完成是一件不甚明智的事情，有时候数据的流动率非常惊人，把数据从你的文件服务器中以Ethernet速度搬走，其速度可能高达每秒一百万字节，如果你尝试从文件服务器中读取100KB，在用户的眼光来看几乎是瞬间完成，但是，要知道，你的线程执行这个命令，已经浪费了10个一百万次CPU周期。所以说，我们一般使用另一个线程来进行I/O。重叠IO[overlapped I/O]是Win32的一项技术，你可以要求操作系统为你传送数据，并且在传送完毕时通知你。这也就是[完成]的含义。这项技术使你的程序在I/O进行过程中仍然能够继续处理事务。事实上，操作系统内部正是以线程来完成overlapped I/O。你可以获得线程所有利益，而不需要付出什么痛苦的代价。

　　完成端口中所谓的[端口]并不是我们在TCP/IP中所提到的端口，可以说是完全没有关系。我到现在也没想通一个I/O设备[I/O Device]和端口[IOCP中的Port]有什么关系。估计这个端口也迷惑了不少人。IOCP只不过是用来进行读写操作，和文件I/O倒是有些类似。既然是一个读写设备，我们所能要求它的只是在处理读与写上的高效。在文章的第三部分你会轻而易举的发现IOCP设计的真正用意。


IOCP和网络又有什么关系？

int main()
{
    WSAStartup(MAKEWORD(2, 2), &wsaData);
    ListeningSocket = socket(AF_INET, SOCK_STREAM, 0); 
    bind(ListeningSocket, (SOCKADDR*)&ServerAddr, sizeof(ServerAddr));
    listen(ListeningSocket, 5);
    int nlistenAddrLen = sizeof(ClientAddr);
    while(TRUE)
    {
        NewConnection = accept(ListeningSocket, (SOCKADDR*)&ClientAddr, &nlistenAddrLen);
        HANDLE hThread = CreateThread(NULL, 0, ThreadFunc, (void*) NewConnection, 0, &dwTreadId);
        CloseHandle(hThread);
    }
    return 0;
}

　　相信只要写过网络的朋友，应该对这样的结构在熟悉不过了。accept后线程被挂起，等待一个客户发出请求，而后创建新线程来处理请求。当新线程处理客户请求时，起初的线程循环回去等待另一个客户请求。处理客户请求的线程处理完毕后终结。

　　在上述的并发模型中，对每个客户请求都创建了一个线程。其优点在于等待请求的线程只需做很少的工作。大多数时间中，该线程在休眠[因为recv处于堵塞状态]。

　　但是当并发模型应用在服务器端[基于Windows NT]，Windows NT小组注意到这些应用程序的性能没有预料的那么高。特别的，处理很多同时的客户请求意味着很多线程并发地运行在系统中。因为所有这些线程都是可运行的[没有被挂起和等待发生什么事]，Microsoft意识到NT内核花费了太多的时间来转换运行线程的上下文[Context]，线程就没有得到很多CPU时间来做它们的工作。

　　大家可能也都感觉到并行模型的瓶颈在于它为每一个客户请求都创建了一个新线程。创建线程比起创建进程开销要小，但也远不是没有开销的。

　　我们不妨设想一下：如果事先开好N个线程，让它们在那hold[堵塞]，然后可以将所有用户的请求都投递到一个消息队列中去。然后那N个线程逐一从消息队列中去取出消息并加以处理。就可以避免针对每一个用户请求都开线程。不仅减少了线程的资源，也提高了线程的利用率。理论上很不错，你想我等泛泛之辈都能想出来的问题，Microsoft又怎会没有考虑到呢?!

　　这个问题的解决方法就是一个称为I/O完成端口的内核对象，他首次在Windows NT3.5中被引入。

　　其实我们上面的构想应该就差不多是IOCP的设计机理。其实说穿了IOCP不就是一个消息队列嘛！你说这和[端口]这两字有何联系。我的理解就是IOCP最多是应用程序和操作系统沟通的一个接口罢了。

　　至于IOCP的具体设计那我也很难说得上来，毕竟我没看过实现的代码，但你完全可以进行模拟，只不过性能可能…，如果想深入理解IOCP， Jeffrey Ritchter的Advanced Windows 3rd其中第13章和第14张有很多宝贵的内容，你可以拿来窥视一下系统是如何完成这一切的。


实现方法

Microsoft为IOCP提供了相应的API函数，主要的就两个，我们逐一的来看一下：
HANDLE CreateIoCompletionPort (
    HANDLE FileHandle,              // handle to file
    HANDLE ExistingCompletionPort,  // handle to I/O completion port
    ULONG_PTR CompletionKey,        // completion key
    DWORD NumberOfConcurrentThreads // number of threads to execute concurrently
);

在讨论各参数之前，首先要注意该函数实际用于两个截然不同的目的：
1．用于创建一个完成端口对象
2．将一个句柄[HANDLE]和完成端口关联到一起

　　在创建一个完成一个端口的时候，我们只需要填写一下NumberOfConcurrentThreads这个参数就可以了。它告诉系统一个完成端口上同时允许运行的线程最大数。在默认情况下，所开线程数和CPU数量相同，但经验给我们一个公式：
　　线程数 = CPU数 * 2 + 2
要使完成端口有用，你必须把它同一个或多个设备相关联。这也是调用CreateIoCompletionPort完成的。你要向该函数传递一个已有的完成端口的句柄，我们既然要处理网络事件，那也就是将客户的socket作为HANDLE传进去。和一个完成键[对你有意义的一个32位值，也就是一个指针，操作系统并不关心你传什么]。每当你向端口关联一个设备时，系统向该完成端口的设备列表中加入一条信息纪录。

另一个API就是
BOOL GetQueuedCompletionStatus(
    HANDLE CompletionPort,        // handle to completion port
    LPDWORD lpNumberOfBytes,      // bytes transferred
    PULONG_PTR lpCompletionKey,   // file completion key
    LPOVERLAPPED *lpOverlapped,   // buffer
    DWORD dwMilliseconds       　 // optional timeout value
);

第一个参数指出了线程要监视哪一个完成端口。很多服务应用程序只是使用一个I/O完成端口，所有的I/O请求完成以后的通知都将发给该端口。简单的说，GetQueuedCompletionStatus使调用线程挂起，直到指定的端口的I/O完成队列中出现了一项或直到超时。同I/O完成端口相关联的第3个数据结构是使线程得到完成I/O项中的信息：传输的字节数，完成键和OVERLAPPED结构的地址。该信息是通过传递给GetQueuedCompletionSatatus的lpdwNumberOfBytesTransferred，lpdwCompletionKey和lpOverlapped参数返回给线程的。

根据到目前为止已经讲到的东西，首先来构建一个frame。下面为您说明了如何使用完成端口来开发一个echo服务器。大致如下：
　　1.初始化Winsock
　　2.创建一个完成端口
　　3.根据服务器线程数创建一定量的线程数
　　4.准备好一个socket进行bind然后listen
　　5.进入循环accept等待客户请求
　　6.创建一个数据结构容纳socket和其他相关信息
　　7.将连进来的socket同完成端口相关联
　　8.投递一个准备接受的请求
以后就不断的重复5至8的过程
那好，我们用具体的代码来展示一下细节的操作。

　　WOW，程序的代码若是贴在此处，实在大煞风景，又不能CTRL+V还不能F7，如果大家需要源代码可以发信给我o_nono@163.net

　　至此文章也该告一段落了,我带着您做了一趟旋风般的旅游,游览了所谓的完成端口。
　　很多细节由于篇幅的关系无法细细道来。但希望这篇文章能带给您更多的思考。如有任何问题，可以发信至o_nono@163.net。

转自：

http://dev.gameres.com/Program/Control/IOCP.htm

第2篇

Re: [Windows]I/O completion ports如何实现？个人推测，寻求标准答案！

这是对http://www.javaeye.com/topic/102007的一个回帖，颇受好评，得了五星，加了若干分，故收入博客。 

基本没什么大错误，经iunknown指正，对non-blocking IO的理解有误。等闲一点，好好翻翻书再改正吧。 

-------------------------------- 

我来侃一侃我对I/O Completion Ports的理解吧。这是一个比较复杂的话题，下面的描述尽量详细，争取把来龙去脉讲清楚，勿嫌啰嗦。

首先讨论一下I/O Completion Ports试图解决什么样的问题。 

写一个IO Intensive服务器程序，对每一个客户请求生成一个新的child process/worker thread来处理，每个process/thread使用同步IO，这是最经典古老的解法了。在这之上的改进是prefork 多个process 或者使用线程池。（使用process或thread，原理都差不多，thread的context switch花销要比process switch要小。为了论述简单，下面只讨论线程。） 

这种结构的并发性并不高，哪怕你用C++, C甚至汇编来写，效率都不会很高，究其原因，在于两点： 

一．同步IO，每个线程大多数时间在等IO request的结束。IO相对于CPU，那是极极慢的。我翻了翻手里的Computer Architecture, A Quantitative Approach第二版，1996年出的，里面对CPU Register, CPU Cache, RAM, Disk，列的access time如下： 

Java代码 

1. Registers:  2-5 nano seconds  
2. CPU Cache: 3-10 nano seconds  
3. RAM: 80-400 nano seconds  
4. Disk: 5 000 000 nano seconds (5 milli seconds)  

如今CPU又按照摩尔定律发展了十年后，这个硬盘还是机械式的磁头移来移去读写，尽管如今disk controller都有cache，也在发展，但和CPU相比，差距越来越大。（谁有最新数据可以贴上来。） 

二．生成数量大大超过CPU总数的线程。这样做有两个弊端，第一是每个线程要占用内存，Windows底下每个thread自己stack的省缺大小为1M，32位程序下一个用户程序最大能利用的内存也就3G，生成3000个线程，内存就没了。当然有人说64位下面，可以随便浪费，那么，第二个弊端，就无法避免了 ─ 生成大量的线程，CPU必然会花费大量的cpu cycles在线程之间进行切换。如今市场上价格适中的服务器也就2 cpu x 4 core = 8 核而已。生成那么多的线程，CPU在切换线程上花的功夫可能比干正经事还要多。 

明白了原因，就可以寻找改进方法。首先，使用异步IO。现在所有主流OS，都提供异步IO（non-blocking IO），连Java这种跨平台的编程环境都在版本1.4里开始支持异步IO了。但是，光有异步IO，这是不够的。论坛里有人发贴子问过，“我的线程发个IO Request，异步IO，直接返回了，然后我的线程干什么？” 异步IO是操作系统提供的机制，我们还需要设计我们程序的结构，使异步IO和线程结合起来，可以充分利用异步IO带来的好处，同时必须控制同时运行线程的数量，减少thread context switch的开销。 

IO Completion Port, 是微软针对上述思想，在Windows内核级别，提供的解决方案。 

从抽象高度去理解IO Completion Port，可以把它想成一个magic port，一边有一个队列是IO驱动程序处理好的IO数据，另一边是一个小小的线程池，这个port把io数据交给线程池里的线程来处理。同时，别的线程启动了IO异步请求后通知这个port一声，“嘿，注意了，一会儿这个IO handle 会有个数据包传过来要处理。” 这个port回答，“好，我注意一下这个handle。”。 




下面我们具体看一下Io Completion Port这个内核对象以及使用。 

要创建IoCompletionPort，呼叫Win32函数CreateIoCompletionPort。这个函数一身两用，创建IoCompletionPort也是它，往建好的IoCompletionPort里面加device handle也是它。 

Java代码 

1. HANDLE CreateIoCompletionPort(  
2.   HANDLE hfile,  
3.   HANDLE hExistingCompPort,  
4.   ULONG_PTR CompKey,  
5.   DWORD dwNumberOfConcurrentThreads);  
6.   
7. // 创建IoCompletionPort  
8.   
9. HANDLE hCp;  
10. hCp = CreateIoCompletionPort(INVALID_HANDLE_VALUE, NULL, 0, 4);  

创建IoCompletionPort头三个参数都是NULL之类的，只有第四个参数，用来配置这个生成的IoCompletionPort所允许同时运行的最大线程数目。 

创建好的IoCompletionPort kernel object，拥有两个队列。一个是Device List，包含所有通过这个IoCompletionPort管理的异步IO请求 的Device Handle。另外一个是I/O Completion Queue (FIFO)，Device Handle对应的IO驱动程序处理好的IO数据，放在这个队列里。 

  为了能在Device List这个队列里面加个entry，用户程序将再一次使用CreateIoCompletionPort 这个函数。 

Java代码 

1. CreateIoCompletionPort(myHandle, hCp, myKey, 0);  

第一个参数是个IO Handle（Windows不限制handle类型，File, Directory, Serial Port, Parallel port, Mailslot server, Mailslot client, pipe, socket等等都可以），第二个参数是以前创建的IoCompletionPort handle. 这个IO Handle将放到IoCompletionPort handle的Device List那个队列里去。第三个参数是个long整数，是用来identify程序Request Context的。因为现在程序不是一个线程来处理客户Request了，而是不同的线程来处理。在一个线程里按顺序一二三四五来实现程序逻辑的方式是不行了，因此作为程序员你要把逻辑的Context记下来，让不同的线程得到这个Context，根据当前的状态，来执行相关的代码。这个completion key，是找到相映的context的key, index, hash code，pointer, whatever. 

第二个队列，IO Completion Queue，是由OS往里面插入entry的。OS在处理好了IO异步请求之后，察看一下这个Device handle是否是放在某个Completion Port里面，如果是，OS就在Completion Port的Completion Queue里面加个Entry。这个Entry包括下列数据。 

Java代码 

1. 1．Number of bytes transferred  
2. 2．Completion key  
3. 3．Pointer to I/O request’s OVERLAPPED structure  
4. 4．Error code  

下面来看看IO Completion Port是怎么管理线程的。 

 

前面说Completion Port有个线程池，这种说法并不是很贴切。Completion Port本身并不创建线程，而只是掌管三个thread队列： 

Java代码 

1. 1．Inactive threads waits IO Completion Port  
2. 2．Active running threads  
3. 3．Threads paused by other reasons, like waiting for something else (i.e. calls WaitForSingleObject, or even stupid but valid, calls Sleep).  

线程由程序创建，然后加入第一个队列(waits on IO Completion Port)。为了加入这个队列线程要呼叫一个函数，GetQueuedCompletionStatu s。 

Java代码 

1. BOOL GetQueuedCompletionStatus(  
2.   HANDLE       hCompPort,  
3.   PDWORD       pdwNumBytes,  
4.   PULONG_PTR   CompKey,  
5.   OVERLAPPED** ppOverlapped,  
6.   DWORD        dwMilliseconds);  

第一个参数是handle to Completion Port，线程通知OS本线程要加入这个Completion Port的第一个队列。这个函数会block当前线程，使其处于inactive状态。 

现在再去看看图二的I/O Completion Queue，OS在一份IO异步请求处理好了后，会在这里插入个entry，Completion Port在收到entry后，看看线程池里面有没有空闲没事做的线程，如果有，不要忘记我们创建这个Completion Port时候规定了个最大同时运行线程数量，如果当前运行线程数量小于这个最大值，那么就把这个线程放到第二个（active running）的队列上去，让这个线程运行起来。前面不是说线程在GetQueuedCompletionStatu s上面block了么，现在这个函数返回了，继续运行程序的代码。通过这个最大同时运行线程数量，保证了不会有太多的线程在运行，Viola! 本文开头分析的几个问题全解决了。即是异步IO，又把异步IO和线程池结合了起来，还控制了当前运行线程数量。It’s BEAUTIFUL! 

这个线程处理完程序逻辑后，呼叫一下GetQueuedCompletionStatu s，又回到了第一个队列。有意思的是这个队列的逻辑是Last In First Out。如果又有IO数据等待线程处理，这个线程可以继续执行，不用进行Context Switch，典型的能者多劳啊，越能干的人干的越多。 

这个线程在处理程序逻辑的过程中，可能会因为别的原因而变成inactive，比如在等别的资源（WaitForSingleObject），或者变态一点，自己来了个Sleep，这时线程就给放到第三个队列去了。 

这里有个有趣的现象，假如开始我们在第一个队列里面放三个线程，而最大同时运行线程数量设为2，在两个线程跑起来之后，第三个就不跑了，如果这时运行中的某个线程因为等别的资源而变为inactive，那么第三个线程也开始跑起来，同时运行线程数量还是2，这时那个等别的资源的线程等到资源了，又开始跑了起来，这时同时运行线程数量就是3，比设定的2要大。 

推荐的最大同时运行线程数量一般为CPU的总数，但是如果运行的线程还要等别的资源，建议把这个数目稍微设大一点，这样并发率会更高。 

先写这么多吧，累死了。这个帖子讲述的是IO Completion Port的工作原理，还没有谈到它是如何实现的，也还没有扯到Windows Source Code. 如果对工作原理了解了，也未必要去深究是如何实现的。在没有ＩＯ　Ｃｏｍｐｌｅｔｉｏｎ　Ｐｏｒｔ的系统上，自己实现一个，也未必不可。当然讨论讨论是如何实现的，也是件很有趣的事情。这方面我也没有完全搞个水落石出。让我先攒攒劲，改天再写吧。 

另外搭个顺风车问个问题，我做图的水平很臭，手里就有个Ｖｉｓｉｏ还用不好。本文的图都是在Ｗｏｒｄ里面画的。请问能否推荐个好用的作图软件，免费还是花钱的都可以。要有什么画ＵＭＬ比较好的软件，也推荐推荐，Ｖｉｓｉｏ太不好用了。 

转自：

http://bigpanda.javaeye.com/blog/138658