一个困扰我n久的同步问题，大家帮忙啊!!!

clicksoft 2005-01-07 01:19:22

一个网络服务端采用异步IO

流程如下：

服务端有一个死循环采用 select 逐个检查每个套接字(tcp)的可读，可写性
一个套接字对应一个link

服务端在某个套接字上读到数据后转交到该套接字所对应的link来处理

link 从他自己的接收缓冲中分析出一条或多条命令然后将这些命令挂到一个专门的
命令处理线程处理该线程处理完后将要回送的数据写到该link的发送缓冲中
等待link 所对应的套接字在服务端死循环中在可写时被发送出去

问题就在如何处理服务端死循环发送某套接字数据和命令处理线程向某套接字发送缓冲写数据时的同步!!!

假如对每个套接字都用关键段那么服务端假如有很多的连接的话可以承受得了吗？？

如果用一个关键段老同步所有的操作又显得效率底下了

套接字的发送缓冲为一个队列

在此向大家请教！！！！！

...全文

326 23 打赏收藏转发到动态举报

写回复

用AI写文章

23 条回复

切换为时间正序

请发表友善的回复…

发表回复

CompletionPort 2005-01-31

打赏
举报

追求完美设计的结果。

clicksoft 2005-01-31

打赏
举报

顶

clicksoft 2005-01-24

打赏
举报

顶

clicksoft 2005-01-22

打赏
举报

to flashboy(爱写程序的小绵羊)

照楼主所讲只要内存够大几千个 CRITICAL_SECTION 小case 喽

gdy119 2005-01-21

打赏
举报

设计结构就有问题，

clicksoft 2005-01-21

打赏
举报

顶

flashboy 2005-01-21

打赏
举报

明白你的意思了，“每个套接字都用关键段那么服务端假如有很多的连接的话可以承受得了吗？？”

这个就看你要一台服务器带多少个用户了，不过我看你使用的SELECT模型，估计也不会带太多，应该会少于1000。另外不知道你的服务器配置是什么？如果有2CPU，1G以上内存，那是绰绰有余啊。因为我在的2CPU，2G内存上使用完成端口模型，带5000用户都没什么问题，关键是内存要大，资源不算什么。

clicksoft 2005-01-21

打赏
举报

to gdy119(夜风微凉)

那这样的问题该怎样设计流程呢？？

clicksoft 2005-01-18

打赏
举报

to hohai(gg) 和 ilovevc(ilovevc)

在pop、push的时侯加个锁就可以了，反正你的缓冲是LINK单独的，

那假如有1000 个缓冲不就有1000个锁了吗？？

加1000个锁是不是太恐怖拉

如果只用一个锁那是否效率又显的太低了

hohai 2005-01-12

打赏
举报

是啊，在pop、push的时侯加个锁就可以了，反正你的缓冲是LINK单独的，

ilovevc 2005-01-12

打赏
举报

我的意思是说服务端死循环发送某套接字数据时
从该套接字对应的link的发送缓冲 queue 中pop一项然后调用 send(sock,data...)
但可能命令处理线程向该套接字的link queue 中 push 一个数据

; 这里你根本无需同步，pop时你要拷贝这个queue的top结点内容到一个服务端循环线程的局部buffer中，然后再发送。如果命令处理线程向该套接字的link queue 中 push 一个数据，也不会影响。
这样，在pop、push的时侯加个锁就可以了。

clicksoft 2005-01-12

打赏
举报

temp3000 2005-01-12

打赏
举报

客户大量时，select 模型本身是瓶颈

clicksoft 2005-01-10

打赏
举报

to: wwwllg(wwwllg)
其实问题就是buff很多如果每个buff都有一个同步变量的话是否负担太重

而用一个同步变量的话效率有太低

这样的问题如何解决在两者间找到一个合适点

或者整个流程设计有问题那该如何设置异步tcp服务器的处理流程]
请高手指教

UDX协议 2005-01-08

打赏
举报

1.对于同一个sock,你只能保证同一时刻只能有一个线程，处于read或write。
2。对于同一个buff,你需要转发给每个client sock的时候，需要在add sock,或remove sock的时候同步。
3.在轮循转发给每一个sock后，需要同步delete shared buffer.
4.在每次同步的时候，不能阻塞sock 的read ,write事件。如果阻塞时间长于一段时间（10秒左右，经验值）将不能收到网络事件。

clicksoft 2005-01-08