【任务处理模型、性能相关】windows上窗口循环、单一线程循环、iocp线程任务处理模型比较
下面图分别简易说明三种较常用的任务处理线程模型。
先说说为什么会来比较这三种任务线程模型，主要还得来于Chromium和手头工作中实际运用的特定问题；这三种任务线程模型在Chromium base的message_loop中都有过实现，且均用在不同的模块中（尽管message_loop中有大部分代码和boost中很像，或者就说直接拷过来的）。不过还是有必要值得讨论下这三种任务线程模型的特点。
- 单一线程循环：
这种模型构造最为简单，除了循环线程外，一般由一个临界、一个事件、和一个可以存放任务的数组或者stl容器组成。
但只可以同一进程内使用，或者经过内存映射后的跨进程通讯（一般没人这么干）。
任何任务的投递均要经历：
1，获取临界
2，往任务池中投递任务
3，激活事件
循环线程一般流程：
1，获取临界
2，取出任务池中的任务/等待事件激活
3，处理任务
对于循环线程可能会产生态变迁位置：
1，获取临界（虽然临界是用户态对象，但有可能会导致线程挂起等） —> 用户态转内核态
2，等待事件 —> 用户态转内核态
3，事件被激活，线程准备恢复执行 —> 内核态转用户态
总结：简单，态切换较少，且可能存在较大的线程时间处于用户态。速度快
- 窗口消息：
*对窗口消息了解不是很多，所以这里只说一下仅有的少量了解。
这种模型构造组成：窗口、消息循环线程、其他辅助（例如要传递一个大内存，可能会用到共享内存等）。
特点：了解windows消息机制就可以用，且可以方便的处理一些和windows消息有关的任务，利用窗口消息分发特点可以很容易的划分任务类型。跨进程。
任何任务的投递均要经历：
1，获取窗口真实句柄
2，投递消息给窗口
循环线程一般流程：
1，等消息
2，取消息
3，分发消息
对于循环线程可能会产生态变迁位置：
1，等消息 —> 用户态转内核态
2，取消息(可能会出现，因为消息队列是用共享内存实现的，不清楚要不要做加锁操作) -> 用户态转内核态
3，分发消息（可能，由于一些消息是默认windows消息，或者是消息钩子链上的消息，需要把消息丢回消息链上，让其他进程进行处理） —> 用户态转内核态
- iocp：
*对iocp了解不是很多，所以这里只说一下仅有的少量了解。
这种模型构造组成：iocp模型、循环线程、其他辅助。
特点：可以方便的处理io相关的任务，内核态会创建一定量的线程数与用户态对应，需要做多次软中断；可跨进程。
任何任务的投递均要经历：
1，获取完成端口真实句柄
2，投递完成端口事件
循环线程一般流程：
1，等事件
2，取事件
3，处理事件
对于iocp线程可能会产生态变迁位置（实际上不全，因为在内核态还需要进行一次APC级别的软中断，iocp这种模型的一个任务流转过程，中断很频繁。详情请参考深入理解windows）：
1，等事件 —> 用户态转内核态
2，取事件 -> 用户态转内核态
3，处理事件
由于手头有份代码，当初的作者可能为了简单或者什么原因，借鉴了boost的iocp模型，并形成一个单线程的底层驱动模型。
早在一年前，刚好要在这个模型上面添加一个及时性要求比较的功能时，发现任务处理的及时性不稳定。有时候任务处理很及时，有时候任务处理延时很重。每个任务的消耗都尽量保持在一个相对平均的水平。
在该模型中频繁堆叠较重的任务后，发现原来是该模型任务处理性能不稳定（被测电脑也是个性能较差的电脑）。后来将及时性任务从该框架中剥离出来以后，问题得到了较好的缓解。
最近在boost，刚好手里有代码，就做个简单的测试。简易代码在这
其中77s对应的图是release下iocp模型，空转1亿次的耗时
其中46s对应的图是release下简单线程模型，空转1亿次的耗时
可见如果只是比较简易线程和iocp模型的话，简易线程的性能会比iocp快不少，但由于特定使用情况，也不能过分的教条。