关于ACE_SOCKET_STREAM的一个初级的问题
看到这样网络客户端的设计，分别使用两个task作为，收发线程，且均为单线程，然后两个线程持有同一个socket句柄，然后同时进行线程的收发，发线程使用msg_quene进行缓冲，收线程简单的进行while循环，不断的去recv_n。
并且未使用ACE_THREAD_MUTEX进行多线程保护，请问从设计上是否有几率出现灾难性的后果。
前辈们帮忙分析一下，该设计是否存在致命的不足之处。
[ 本帖最后由 modern 于 2009-3-3 14:14 编辑 ] 说白了，就是多线程对同一socket句柄的同事读写，如果不加锁保护是否产生致命的问题，
但是考虑到加锁保护，会不会导致如果服务器某一时刻产生大量的数据过来，接收线程会长期占有锁，
导致客户端的想要发送的信息，不断停在msg_quene里面缓冲着，导致上层调用的超时。
考虑作为客户端，是否考虑使用reacotr事件分离一下，伸缩性会更好一些呢？
[ 本帖最后由 modern 于 2009-3-3 14:39 编辑 ] 我做个实验先。验证我的判断。 老大，有研究结果了么？ 不好意思，这两天事情多。没弄呢。
不过先说一下我的理解和经验，然后再验证一下。
我看过WINSOCK2的代码实现，记得里面是没有锁的。所以如果两个线程同时操作，但是一个读，一个写，就不会有问题-缓冲区独立，全双工操作。如果同时读写，就很可能产生错误。
为什么我以往没验证或者碰到这个问题呢？很简单，架构设计使得这个问题不存在，绕过去了。
因为传统上用ACE操作，都用处理队列来进行数据处理。就是说，接收了信息，接收的线程并不处理，而是推入队列中，由其它的线程处理。这样就避免了阻塞。
你提的这个设计，比较差。 按我理解老大的意思是，由于缓冲区独立，两个线程同时读写一个socket不会产生问题，对吧！
对于写线程，收到消息之后，压入Task线程的一个消息队列去做处理，这样的目的是避免阻塞，是这样吧。 对的。 ok，多谢老大
PS,发帖子竟然有字数限制，但是看超级版主的帖子竟然没有，汗一个~ 是么？我也没注意过这个问题，我看看后台吧。有些限制确实恼人，但是不限制又容易被人灌垃圾，也很烦恼啊。 原帖由 modern 于 2009-3-9 11:16 发表 http://www.acejoy.com/bbs/images/common/back.gif
按我理解老大的意思是，由于缓冲区独立，两个线程同时读写一个socket不会产生问题，对吧！
对于写线程，收到消息之后，压入Task线程的一个消息队列去做处理，这样的目的是避免阻塞，是这样吧。 ...
为什么不用Proactor的方式呢
页:
[1]