简单说一个IOCP不好的地方

IOCP是windows下IO事件处理的最高效的一种方式了，结合OVERLAPPED IO可以实现真正的完全异步IO。windows在此种模式下提供了一站式服务，只要你提交一个IO请求，接下来windows替你处理其他所有的工作，你只需要等着接受windows的完成通知就行了。

    响马大叔在他的孢子社区有了一个帖子再谈select, iocp, epoll,kqueue及各种I/O复用机制对此有比较全面的对比介绍了，故而本文不对IOCP这方面的内容再做赘述了，相反说说自己在自己开发过程中认为IOCP不好的地方。

    IOCP不好的地方体现这个地方：一个File/Socket Handle是不能多次调用CreateIoCompletionPort()绑定到不同的IOCP上的，只有第一次是成功的，第二次开始是参数错误失败！因此一旦绑定了一个IOCP就没法迁移到其他的IOCP了，这个是我经过实际的代码测试和分析ReactOS代码实现得出的结论。测试代码如下

 View Code

运行结果

Administrator@attention /e/tinylib/windows/net_iocp
$ iocp.exe
first bind, ret: 60, error: 0
second bind, ret: 0, error: 87

ReactOS-0.3.12-REL-src的代码体现在NtSetInformationFile()中以下代码片段

 View Code

MSDN中也明确提倡开发者启动多个线程使用GetQueuedCompletionStatus()挂在一个IOCP上来处理IO事件，我是如此理解了的，原文如下

NumberOfConcurrentThreads

[in] Maximum number of threads that the operating system allows to concurrently process I/O completion packets for the I/O completion port. If this parameter is zero, the system allows as many concurrently running threads as there are processors in the system.

Although any number of threads can call the GetQueuedCompletionStatus function to wait for an I/O completion port, each thread is associated with only one completion port at a time. That port is the port that was last checked by the thread.

可这对应有另外一个问题：会导致同一个IO handle的完成事件被分散到不同的线程中处理，从而在处理同一个handle的IO事件时会引入额外的并发竞争，对此我也写了代码进行测试确认，如下

 View Code

如此的话，由于这些并发竞争的存在实际上差不多抵消了开多个线程进行并发处理的好处，还不如将所有的IO事件全部放在同一个线程中进行处理，还能省去很多锁的开销。不过现代的程序几乎完全是在多核的CPU上运行的，如果因为IOCP，你让所有相关的工作全部放在一个线程里进行处理，又不能充分利用多核的并行优势。实际上我们在设计并发模型时，经常开多个worker来实现负载均衡，但IOCP以上的限制是与之相冲突的。

linux下的epoll就额外提供了del操作，可以使得一个fd可以随时从当期的epoll中detach出去，又立马add进另外一个epoll，如此的话就可以开多个worker线程开跑多个epoll，可以将不同fd均摊到不同的worker中实现负载均衡，同时又可以随意的将fd从一个线程迁移到另外一个线程进行处理。这种均衡操作在实际的业务中是很常见的，会需要你根据业务逻辑，将不同的fd交给其他的线程来处理，若使用IOCP的话就不太方便了。

这些就算是我对IOCP吐槽的一个地方了。