从2004年使用iocp开始,尝试过很多种client生存期管理,最初使用
一个锁userlock,在sendcomp和recvcomp以及senddata等都用一个锁,而且是
进去的地方就开始锁,这种方式最简单,也产生了最初的版本,之后为
追求更高效率,慢慢演变为使用两个锁,readlock和writelock,再之后
演变为send使用一个锁,recv使用interlockedxxx,再之后演变为
send使用一个cs锁和一个sending,recv使用一个ref,经历了如此多种演变。

1、一个锁userlock, sendcomp recvcomp senddata都用这个锁。
2、两个锁,userlock, sendlock
3、一个锁userlock+socket查找,锁范围比1小,多一次全局查找操作。
4、一个锁sendlock,一个ref(InterlockedXXX)
   wsasend wsarecv 对象生存期等都用ref计数
5、一个锁sendlock和一个sending(InterlockedXXX),一个ref(InterlockedXXX)
   wsasend用sending计数,wsarecv等用ref计数

历经如此几个版本的修改,锁的范围越来越小,interlocked次数越来越少,反应自然
越来越快。
今天为了写总结文章,拿1 4 5进行了一次比较,1除了大量连接的时候比4 5 反应
慢了很多之外在cpu mem等占用方面几乎和4 5 相当,也就是说除了实时性方面差一些
其他方面没有太大差别。
但4 5都是用到了线程级别的内存池,1的测试例程还是用老的内存池,这个差别也
很大,所以综合地看,虽然做了很多优化却是花费80%的时间,做了20%的鸟事。

Posted on 2010-10-03 14:12 袁斌 阅读(232) 评论(0)  编辑 收藏 引用

只有注册用户登录后才能发表评论。
网站导航: 博客园   IT新闻   BlogJava   博问   Chat2DB   管理