惊群(thundering herd)问题在linux上可能是莫须有的问题

思一克

在KERNEL中仅仅唤醒一个进程。

原帖由 Sorehead 于 2007-6-7 16:29 发表
个人觉得惊群的问题应该是存在的，只是内核把这个问题给解决了，不在应用层表现出来。
谁看过这方面内核代码，知道具体情况的告知一下真实情况，我也学习一下，谢谢。

思一克

所以我才看KERNEL中的wait_for_connect()唤醒不。就是有同样的疑问

原帖由 converse 于 2007-6-7 16:35 发表


我觉得这个不足以作为证据的.
网络编程第一卷里面说的是那些accept失败的进程会继续阻塞住,也就是说,这些进程应该不会执行后面的这句printf.

converse

还得麻烦思版主也看看select函数是不是也会有惊群问题....前面你看的是accept函数的实现.

思一克

其它的再研究。accept是没有的。

我又看了KERNEL的wake_up_XXXX，它唤醒多个等待某资源（EXCLUSIVE）的进程其中的一个比唤醒全部代价还小，它为什么自己找麻烦唤醒所有的？

原帖由 converse 于 2007-6-7 17:02 发表
还得麻烦思版主也看看select函数是不是也会有惊群问题....前面你看的是accept函数的实现.

思一克

TO converse,

你可以写个程序，让多个进程阻塞在select 同一个sock, 加printf, 看是唤醒多个还是一个。

原帖由 converse 于 2007-6-7 17:02 发表
还得麻烦思版主也看看select函数是不是也会有惊群问题....前面你看的是accept函数的实现.

yulc

版主的专研精神,真是PFPF...
纠正了我很长时间来,在linux中对于多进程服务器设计上的一个细节概念.
由于在Apache2的prefork MPM的模型中,是在accpet前面加锁,所以我潜意识中认为这种设计是更优的.
但却从未考虑过accpet()的"惊群"问题.
原来,这个问题在早期的2.2的kernel中,早就讨论过.至从2.2.9的内核起,这个问题就不复存在了.

在英文中,"惊群"原来是"thundering herd"
http://www.citi.umich.edu/projec ... reports/accept.html

醉卧水云间

各操作系统都不存在这个问题, 太古老了.

思一克

TO yulc,

问题不存在了从2。2。9？ 谢谢你的结论。

估计是早期的什么地方存在。后来的应该不存在了。

因为KERNEL在该唤醒许多PROCESS中的一个时候，它唤醒一个是很简单和自然的事情，为什么不这样？

如果唤醒许多，执行了又回到等待（甚至连KERNEL都没有走出来），那浪费时间空间，又没有意义。所以
从LINUX某版本后，该问题应该没有了。

所以，也不能说权威书是完全错的。对原来可能是对的。

原帖由 yulc 于 2007-6-8 10:03 发表
版主的专研精神,真是PFPF...
纠正了我很长时间来,在linux中对于多进程服务器设计上的一个细节概念.
由于在Apache2的prefork MPM的模型中,是在accpet前面加锁,所以我潜意识中认为这种设计是更优的.
但却从未考虑 ...

flw2

accept来说，资源是EXCLUSIVE
但是select就不是了，一个文件可以读，如果有两个进程要读，那么应该唤醒两个。

flw2

就算唤醒n个进程，如果得不到资源，那么也到不了user态了，马上又阻塞的kernel态