两个线程并行执行select,等待相同的100个socket,可以吗,会有什么问题?
10 个解决方案
#1
up
#2
只要socket的事件没有消失,select就会成功,所以你的各个线程要处理这个race condition
例如,socket a 有read事件,线程1select返回后,在调用处理这个read事件前,线程2可能
也会在a上select,它同样会得到read事件,如果它也去处理,就产生了race condition,
先处理read事件的线程pass,后面一个可能就会组塞了
不明白你为什么用多个线程去select同一堆socket?
或许应该让不同的线程负责不同的sockets,避免这种race condition?
例如,socket a 有read事件,线程1select返回后,在调用处理这个read事件前,线程2可能
也会在a上select,它同样会得到read事件,如果它也去处理,就产生了race condition,
先处理read事件的线程pass,后面一个可能就会组塞了
不明白你为什么用多个线程去select同一堆socket?
或许应该让不同的线程负责不同的sockets,避免这种race condition?
#3
楼上说的有道理,还有select可以在100个socket上执行吗?好像有最大限制的
#4
领导说要多个线程recv,send.不可违。
我觉得只要不是几十个cpu,单个线程poll之后recv 和 多个线程poll recv是一样的,
因为recv不会阻塞,仅仅是一个内存拷贝。
看来只好用两个线程分别处理不同的socket组了。
至于send,就同步一下,每次send前,先锁一下这个socket对应的互斥锁。
我觉得只要不是几十个cpu,单个线程poll之后recv 和 多个线程poll recv是一样的,
因为recv不会阻塞,仅仅是一个内存拷贝。
看来只好用两个线程分别处理不同的socket组了。
至于send,就同步一下,每次send前,先锁一下这个socket对应的互斥锁。
#5
》我觉得只要不是几十个cpu,单个线程poll之后recv 和 多个线程poll recv是一样的,
》因为recv不会阻塞,仅仅是一个内存拷贝。
当然会阻塞,你第一次recv后就把接收缓冲里的东西可能收完了
下次再recv就要阻塞了
》因为recv不会阻塞,仅仅是一个内存拷贝。
当然会阻塞,你第一次recv后就把接收缓冲里的东西可能收完了
下次再recv就要阻塞了
#6
to zeusnchen:
我不是用阻塞方式.
我用的poll或者select的非阻塞模型,有数据才会调用recv函数,没有数据就在poll或者select函数上等待
我不是用阻塞方式.
我用的poll或者select的非阻塞模型,有数据才会调用recv函数,没有数据就在poll或者select函数上等待
#7
sorry,偶以为你用的阻塞方式
那样的话,也会有问题三
你没法控制哪个thread收哪些数据了
当然要看你的目的了
呵呵
那样的话,也会有问题三
你没法控制哪个thread收哪些数据了
当然要看你的目的了
呵呵
#8
领导说要多个线程recv,send.不可违
??
一般是多个线程处理多组不同的 fd
然后把数据线程内预处理
需要交互的再集中处理
??
一般是多个线程处理多组不同的 fd
然后把数据线程内预处理
需要交互的再集中处理
#9
同意楼上.
#10
只要互斥处理好了,应该没什么问题。
#1
up
#2
只要socket的事件没有消失,select就会成功,所以你的各个线程要处理这个race condition
例如,socket a 有read事件,线程1select返回后,在调用处理这个read事件前,线程2可能
也会在a上select,它同样会得到read事件,如果它也去处理,就产生了race condition,
先处理read事件的线程pass,后面一个可能就会组塞了
不明白你为什么用多个线程去select同一堆socket?
或许应该让不同的线程负责不同的sockets,避免这种race condition?
例如,socket a 有read事件,线程1select返回后,在调用处理这个read事件前,线程2可能
也会在a上select,它同样会得到read事件,如果它也去处理,就产生了race condition,
先处理read事件的线程pass,后面一个可能就会组塞了
不明白你为什么用多个线程去select同一堆socket?
或许应该让不同的线程负责不同的sockets,避免这种race condition?
#3
楼上说的有道理,还有select可以在100个socket上执行吗?好像有最大限制的
#4
领导说要多个线程recv,send.不可违。
我觉得只要不是几十个cpu,单个线程poll之后recv 和 多个线程poll recv是一样的,
因为recv不会阻塞,仅仅是一个内存拷贝。
看来只好用两个线程分别处理不同的socket组了。
至于send,就同步一下,每次send前,先锁一下这个socket对应的互斥锁。
我觉得只要不是几十个cpu,单个线程poll之后recv 和 多个线程poll recv是一样的,
因为recv不会阻塞,仅仅是一个内存拷贝。
看来只好用两个线程分别处理不同的socket组了。
至于send,就同步一下,每次send前,先锁一下这个socket对应的互斥锁。
#5
》我觉得只要不是几十个cpu,单个线程poll之后recv 和 多个线程poll recv是一样的,
》因为recv不会阻塞,仅仅是一个内存拷贝。
当然会阻塞,你第一次recv后就把接收缓冲里的东西可能收完了
下次再recv就要阻塞了
》因为recv不会阻塞,仅仅是一个内存拷贝。
当然会阻塞,你第一次recv后就把接收缓冲里的东西可能收完了
下次再recv就要阻塞了
#6
to zeusnchen:
我不是用阻塞方式.
我用的poll或者select的非阻塞模型,有数据才会调用recv函数,没有数据就在poll或者select函数上等待
我不是用阻塞方式.
我用的poll或者select的非阻塞模型,有数据才会调用recv函数,没有数据就在poll或者select函数上等待
#7
sorry,偶以为你用的阻塞方式
那样的话,也会有问题三
你没法控制哪个thread收哪些数据了
当然要看你的目的了
呵呵
那样的话,也会有问题三
你没法控制哪个thread收哪些数据了
当然要看你的目的了
呵呵
#8
领导说要多个线程recv,send.不可违
??
一般是多个线程处理多组不同的 fd
然后把数据线程内预处理
需要交互的再集中处理
??
一般是多个线程处理多组不同的 fd
然后把数据线程内预处理
需要交互的再集中处理
#9
同意楼上.
#10
只要互斥处理好了,应该没什么问题。