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