描述:
这段时间一直在IOCP 和 SELECT上做选择。下定决心用IOCP。IOCP显然是很高效的，但在异步下也能体现这种高效呢。我的思路如下
1：IOCP线程负责消息的接收，然后把消息写入BUFF 这个BUFF对应的是连接，处理合包
2：逻辑线程 读取这个线程下管理的连接的BUFF 依次处理逻辑
在这个过程中 主要是对 BUFF的读写锁 这个会占用多少资源不知道。。只想到这个方案
大家有好的方案吗
我开始想的是 没有逻辑线程 直接在IOCP线程里处理逻辑 感觉这样不好如果逻辑处理比较费时 就容易堵塞住
高手给点建议啊。。有没有做过的
解决方案1:
楼主的想法是对的，接收线程和逻辑处理线程要区分，两者刚好形成消费者模式
对于buff的同步机制，可以采用临界区（critical_section）,
这个消耗的资源和处理效率，还是可以接受的
http://blog.csdn.net/qq752923276/article/details/7674732
解决方案3:
IOCP负责网络数据的收发，把数据接收到缓冲区去之后，由专门的消息队列去分发消息，专门的数据处理线程去处理数据。
其中的消息队列机制也可以用IOCP模型来实现。
我之前做的就是有几个线程利用IOCP接收并将缓冲区放入消息列队，然后有几个逻辑线程处理接收到的缓冲区，然后还需要针对每一个已连接对象建立一个有顺序的列队，当逻辑线程收到了数据后依照编号将其插入该列队，如果该列队头是要读取的数据包就依次处理所有能够处理的包。
这里面IOCP接收线程，逻辑线程甚至消息列队的数量都可以根据需求动态调整。
不过我当时的负载不大，杀鸡用了牛刀，所以也没有测试究竟能有多少吞吐量
如果是怕阻塞才不在IO线程中处理逻辑，那完全没有必要，逻辑处理放到另一线程中，延迟更严重，因为IO线程收到的数据需要加入队列，这个队列则需要加锁，然后逻辑线程取出消息时还要加开锁，再加上如果处理时间长，客户端一样会延迟。
我说的只是理论，但实际上，这些锁对整个系统来说不会有太大的影响。而大多数把逻辑线程与IO线程分开的做法，主要是考虑到程序的条理清晰。 解决方案6:
对于一个网络应用来说它就是应该有一个缓冲区的，也就是一个消息队列。这样做的好处就是可以把网络层独立出去。游戏也是这样的。