下面图分别简易说明三种较常用的任务处理线程模型。

 

 

 

先说说为什么会来比较这三种任务线程模型，主要还得来于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快不少，但由于特定使用情况，也不能过分的教条。