accept可以多线程

xiao__xiao 发布于 2016/09/14 09:21
阅读 767
收藏 1
accept能在不加锁的前提下多线程处理不?
加载中
0
乌龟壳
乌龟壳
如果你说的是系统api层面的accept,是可以的。如果是别人封装过的accept,那就要看封装得是否线程安全了。
0
x
xiao__xiao

引用来自“乌龟壳”的评论

如果你说的是系统api层面的accept,是可以的。如果是别人封装过的accept,那就要看封装得是否线程安全了。
不会有一些资源竞争的问题发生吗?针对accept,在系统里面不是维护一个链表吗 ?我在想多线程accept就是客户端同时访问很多的时候用
0
乌龟壳
乌龟壳

引用来自“乌龟壳”的评论

如果你说的是系统api层面的accept,是可以的。如果是别人封装过的accept,那就要看封装得是否线程安全了。

引用来自“xiao__xiao”的评论

不会有一些资源竞争的问题发生吗?针对accept,在系统里面不是维护一个链表吗 ?我在想多线程accept就是客户端同时访问很多的时候用

accept是系统调用,它也没用你程序里的公共内存,所以和多进程一样系统会处理好并发的。

不过最好的办法是开一个线程专门accept,然后accept到socket交给其它线程处理。

因为低版本的linux内核,多进程多线程同时accept效率不高。

0
x
xiao__xiao

引用来自“乌龟壳”的评论

引用来自“乌龟壳”的评论

如果你说的是系统api层面的accept,是可以的。如果是别人封装过的accept,那就要看封装得是否线程安全了。

引用来自“xiao__xiao”的评论

不会有一些资源竞争的问题发生吗?针对accept,在系统里面不是维护一个链表吗 ?我在想多线程accept就是客户端同时访问很多的时候用

accept是系统调用,它也没用你程序里的公共内存,所以和多进程一样系统会处理好并发的。

不过最好的办法是开一个线程专门accept,然后accept到socket交给其它线程处理。

因为低版本的linux内核,多进程多线程同时accept效率不高。

那这样的话,还是一个acceot,如果10万以上或者20万以上客户端连接的话,一个accept不会有延迟或者客户端连接不上的问题吗?
0
乌龟壳
乌龟壳

引用来自“乌龟壳”的评论

引用来自“乌龟壳”的评论

如果你说的是系统api层面的accept,是可以的。如果是别人封装过的accept,那就要看封装得是否线程安全了。

引用来自“xiao__xiao”的评论

不会有一些资源竞争的问题发生吗?针对accept,在系统里面不是维护一个链表吗 ?我在想多线程accept就是客户端同时访问很多的时候用

accept是系统调用,它也没用你程序里的公共内存,所以和多进程一样系统会处理好并发的。

不过最好的办法是开一个线程专门accept,然后accept到socket交给其它线程处理。

因为低版本的linux内核,多进程多线程同时accept效率不高。

引用来自“xiao__xiao”的评论

那这样的话,还是一个acceot,如果10万以上或者20万以上客户端连接的话,一个accept不会有延迟或者客户端连接不上的问题吗?

假设场景:

  1. 已经开始listen了
  2. 设置了操作系统可以缓冲10万个未accept的连接
  3. 等10万个连接都和操作系统建立完成了

那么,这个时候,你开始用单线程循环accept,直到处理完这10万个连接,其实一秒都不用就完成了。

因为建立连接的整个流程都是操作系统的事,accept只是接收操作系统已经处理完成的那些建立好的连接。只要accept线程拿到socket后直接丢给其它线程就进行下一处accept,那么这个不应会成为瓶颈。

另外,可能以你现在的熟悉程度,处理好10万20万连接这个问题有点困难,因为这不止是连接的事。建议深入学习一下。

0
x
xiao__xiao

引用来自“乌龟壳”的评论

引用来自“乌龟壳”的评论

引用来自“乌龟壳”的评论

如果你说的是系统api层面的accept,是可以的。如果是别人封装过的accept,那就要看封装得是否线程安全了。

引用来自“xiao__xiao”的评论

不会有一些资源竞争的问题发生吗?针对accept,在系统里面不是维护一个链表吗 ?我在想多线程accept就是客户端同时访问很多的时候用

accept是系统调用,它也没用你程序里的公共内存,所以和多进程一样系统会处理好并发的。

不过最好的办法是开一个线程专门accept,然后accept到socket交给其它线程处理。

因为低版本的linux内核,多进程多线程同时accept效率不高。

引用来自“xiao__xiao”的评论

那这样的话,还是一个acceot,如果10万以上或者20万以上客户端连接的话,一个accept不会有延迟或者客户端连接不上的问题吗?

假设场景:

  1. 已经开始listen了
  2. 设置了操作系统可以缓冲10万个未accept的连接
  3. 等10万个连接都和操作系统建立完成了

那么,这个时候,你开始用单线程循环accept,直到处理完这10万个连接,其实一秒都不用就完成了。

因为建立连接的整个流程都是操作系统的事,accept只是接收操作系统已经处理完成的那些建立好的连接。只要accept除了建立连接后丢给其它线程,那么这个不应会成为瓶颈。

另外,可能以你现在的熟悉程度,处理好10万20万连接这个问题有点困难,因为这不止是连接的事。建议深入学习一下。

????? 不懂了,深入学习指的是什么 ?
乌龟壳
乌龟壳
还有这代码为啥要你自己写,还有你是否想多了,其实你遇到的问题只是1000个连接而已?我觉得你对这个不熟,所以尽量别走太快,摸着石头过河比较好。先把程序做出来再优化,而不是一口气考虑十万二十万的连接问题。
乌龟壳
乌龟壳
10万连接如果只是连上来一点价值都没有,要处理它必然会遇到单机的性能瓶颈。还有连接数太多就要换更底层的思路,用lvs等负载均衡去处理。
乌龟壳
乌龟壳
socket相关的API,和在操作系统里的实现,还有分布式系统的设计。
0
x
xiao__xiao

引用来自“乌龟壳”的评论

引用来自“乌龟壳”的评论

引用来自“乌龟壳”的评论

如果你说的是系统api层面的accept,是可以的。如果是别人封装过的accept,那就要看封装得是否线程安全了。

引用来自“xiao__xiao”的评论

不会有一些资源竞争的问题发生吗?针对accept,在系统里面不是维护一个链表吗 ?我在想多线程accept就是客户端同时访问很多的时候用

accept是系统调用,它也没用你程序里的公共内存,所以和多进程一样系统会处理好并发的。

不过最好的办法是开一个线程专门accept,然后accept到socket交给其它线程处理。

因为低版本的linux内核,多进程多线程同时accept效率不高。

引用来自“xiao__xiao”的评论

那这样的话,还是一个acceot,如果10万以上或者20万以上客户端连接的话,一个accept不会有延迟或者客户端连接不上的问题吗?

假设场景:

  1. 已经开始listen了
  2. 设置了操作系统可以缓冲10万个未accept的连接
  3. 等10万个连接都和操作系统建立完成了

那么,这个时候,你开始用单线程循环accept,直到处理完这10万个连接,其实一秒都不用就完成了。

因为建立连接的整个流程都是操作系统的事,accept只是接收操作系统已经处理完成的那些建立好的连接。只要accept线程拿到socket后直接丢给其它线程就进行下一处accept,那么这个不应会成为瓶颈。

另外,可能以你现在的熟悉程度,处理好10万20万连接这个问题有点困难,因为这不止是连接的事。建议深入学习一下。

你说的这个我明白,无非就是三次握手完成后,会放到accept的完成链表中,从链表中取数据,那你要循环去取,去发送给工作线程,难道一个accept不会有瓶颈?我一个单纯的for循环,只是send一个数字到标准数据,完成都是细微的时间差
乌龟壳
乌龟壳
回复 @xiao__xiao : send是填充数据,accept是数据准备好了直接拿。其实我觉得我能发表的个人观点都发表了。其它扩展开来的就不讨论了吧
x
xiao__xiao
回复 @乌龟壳 :额,你说的是宽带啊,一台机器很难支持100多万,一般需要考虑负载均衡,多服务器的
x
xiao__xiao
回复 @乌龟壳 : 1、本来就是长连接 2、printf是慢,但是send到标准输出跟send一个socket句柄是一样的啊
乌龟壳
乌龟壳
你提到的确实存在,如果问题规模不断扩大,可能就要多线程一起accept才能保证性能了,比如每秒有100多万个新连接等。但是把问题抛出来是简单,实际又是另一回事,你有那么大的带宽支持每秒一百多万新连接吗?为什么一定要tcp?长连接不行吗?等等一系列问题。
乌龟壳
乌龟壳
accept只是和内核数据交换,打印到stdout做得事情就比较多,你可以试试把stdout重定向到/dev/null,速度就快一些了,但仍然比accept要复杂。
0
刘大神
刘大神

引用来自“乌龟壳”的评论

引用来自“乌龟壳”的评论

引用来自“乌龟壳”的评论

如果你说的是系统api层面的accept,是可以的。如果是别人封装过的accept,那就要看封装得是否线程安全了。

引用来自“xiao__xiao”的评论

不会有一些资源竞争的问题发生吗?针对accept,在系统里面不是维护一个链表吗 ?我在想多线程accept就是客户端同时访问很多的时候用

accept是系统调用,它也没用你程序里的公共内存,所以和多进程一样系统会处理好并发的。

不过最好的办法是开一个线程专门accept,然后accept到socket交给其它线程处理。

因为低版本的linux内核,多进程多线程同时accept效率不高。

引用来自“xiao__xiao”的评论

那这样的话,还是一个acceot,如果10万以上或者20万以上客户端连接的话,一个accept不会有延迟或者客户端连接不上的问题吗?

假设场景:

  1. 已经开始listen了
  2. 设置了操作系统可以缓冲10万个未accept的连接
  3. 等10万个连接都和操作系统建立完成了

那么,这个时候,你开始用单线程循环accept,直到处理完这10万个连接,其实一秒都不用就完成了。

因为建立连接的整个流程都是操作系统的事,accept只是接收操作系统已经处理完成的那些建立好的连接。只要accept线程拿到socket后直接丢给其它线程就进行下一处accept,那么这个不应会成为瓶颈。

另外,可能以你现在的熟悉程度,处理好10万20万连接这个问题有点困难,因为这不止是连接的事。建议深入学习一下。

引用来自“xiao__xiao”的评论

你说的这个我明白,无非就是三次握手完成后,会放到accept的完成链表中,从链表中取数据,那你要循环去取,去发送给工作线程,难道一个accept不会有瓶颈?我一个单纯的for循环,只是send一个数字到标准数据,完成都是细微的时间差
@乌龟壳 说的很有道理,accept属于系统级api 那么这个api的处理瓶颈一般不会是出现在系统上面,你说的多线程处理,就得看安全机制了,是系统的安全机制还是你自己定义的安全机制;处理问题都是已最优为采纳方式的,如果真的有百万的连接,那么单纯的accept可能就不会满足需求了,就需要去寻找等同的替代方式,本人没做过百万级的accept,不好发表意见;系统级api很少有瓶颈,百分之80的情况,系统都已经处理的很好了
0
x
xiao__xiao
我先问的关键就是accept如果多线程,加锁,会不会有问题?是不是安全的?因为这个地方我不是很清楚,所以问出来学习一下
乌龟壳
乌龟壳
不会
0
x
xiao__xiao

引用来自“xiao__xiao”的评论

我先问的关键就是accept如果多线程,加锁,会不会有问题?是不是安全的?因为这个地方我不是很清楚,所以问出来学习一下
打错了,accept如果多线程,不加锁,会不会有问题?
返回顶部
顶部