找回密码
 用户注册

QQ登录

只需一步,快速开始

查看: 3729|回复: 9

关于ACE_SOCKET_STREAM的一个初级的问题

[复制链接]
发表于 2009-3-3 14:05:59 | 显示全部楼层 |阅读模式
看到这样网络客户端的设计,分别使用两个task作为,收发线程,且均为单线程,然后两个线程持有同一个socket句柄,
然后同时进行线程的收发,发线程使用msg_quene进行缓冲,收线程简单的进行while循环,不断的去recv_n。
并且未使用ACE_THREAD_MUTEX进行多线程保护,请问从设计上是否有几率出现灾难性的后果。
前辈们帮忙分析一下,该设计是否存在致命的不足之处。

[ 本帖最后由 modern 于 2009-3-3 14:14 编辑 ]
 楼主| 发表于 2009-3-3 14:32:41 | 显示全部楼层
说白了,就是多线程对同一socket句柄的同事读写,如果不加锁保护是否产生致命的问题,
但是考虑到加锁保护,会不会导致如果服务器某一时刻产生大量的数据过来,接收线程会长期占有锁,
导致客户端的想要发送的信息,不断停在msg_quene里面缓冲着,导致上层调用的超时。
考虑作为客户端,是否考虑使用reacotr事件分离一下,伸缩性会更好一些呢?

[ 本帖最后由 modern 于 2009-3-3 14:39 编辑 ]
发表于 2009-3-3 18:29:34 | 显示全部楼层
我做个实验先。验证我的判断。
 楼主| 发表于 2009-3-5 15:49:00 | 显示全部楼层
老大,有研究结果了么?
发表于 2009-3-5 20:49:28 | 显示全部楼层
不好意思,这两天事情多。没弄呢。
不过先说一下我的理解和经验,然后再验证一下。
    我看过WINSOCK2的代码实现,记得里面是没有锁的。所以如果两个线程同时操作,但是一个读,一个写,就不会有问题-缓冲区独立,全双工操作。如果同时读写,就很可能产生错误。
    为什么我以往没验证或者碰到这个问题呢?很简单,架构设计使得这个问题不存在,绕过去了。
    因为传统上用ACE操作,都用处理队列来进行数据处理。就是说,接收了信息,接收的线程并不处理,而是推入队列中,由其它的线程处理。这样就避免了阻塞。
    你提的这个设计,比较差。
 楼主| 发表于 2009-3-9 11:16:18 | 显示全部楼层
按我理解老大的意思是,由于缓冲区独立,两个线程同时读写一个socket不会产生问题,对吧!
对于写线程,收到消息之后,压入Task线程的一个消息队列去做处理,这样的目的是避免阻塞,是这样吧。
发表于 2009-3-9 15:05:04 | 显示全部楼层
对的。
 楼主| 发表于 2009-3-10 12:58:26 | 显示全部楼层
ok,多谢老大
PS,发帖子竟然有字数限制,但是看超级版主的帖子竟然没有,汗一个~
发表于 2009-3-10 16:42:47 | 显示全部楼层
是么?我也没注意过这个问题,我看看后台吧。有些限制确实恼人,但是不限制又容易被人灌垃圾,也很烦恼啊。
发表于 2009-3-17 09:57:53 | 显示全部楼层
原帖由 modern 于 2009-3-9 11:16 发表
按我理解老大的意思是,由于缓冲区独立,两个线程同时读写一个socket不会产生问题,对吧!
对于写线程,收到消息之后,压入Task线程的一个消息队列去做处理,这样的目的是避免阻塞,是这样吧。 ...
为什么不用Proactor的方式呢
您需要登录后才可以回帖 登录 | 用户注册

本版积分规则

Archiver|手机版|小黑屋|ACE Developer ( 京ICP备06055248号 )

GMT+8, 2024-11-23 03:46 , Processed in 0.016169 second(s), 6 queries , Redis On.

Powered by Discuz! X3.5

© 2001-2023 Discuz! Team.

快速回复 返回顶部 返回列表