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

思一克

单CPU也不一定总是唤醒一个.

比如,你select pipe描述符, 一有数据就唤醒每一个. 尽管是单CPU.

一个CPU每时间做一个事情和唤醒多个没有矛盾. 说的不是一回事情.

原帖由 信赖CU 于 2007-6-9 11:27 发表

单CPU肯定是唤醒一个。一个CPU只能在同一时间作一件事根本不用跟踪。SMP的就不一样了

[ 本帖最后由 思一克 于 2007-6-9 13:04 编辑 ]

信赖CU

原帖由 思一克 于 2007-6-9 13:02 发表
单CPU也不一定总是唤醒一个.

比如,你select pipe描述符, 一有数据就唤醒每一个. 尽管是单CPU.

一个CPU每时间做一个事情和唤醒多个没有矛盾. 说的不是一回事情.

实际上真正醒的只有一个。

思一克

不要将“已经唤醒的”在运行的进程和此刻才CPU上运行的混淆了。

在一个CPU机器上

1. 
   
2. main()
   
3. {
   
4. int i;
   
5.    for(i = 0; i < 3; i++) fork();
   
6.    for(;;) ;
   
7. }
   

复制代码

这个程序运行后，你top看有几个进程正在运行？是8个以上。但实际每时刻仅仅一个。唤醒所有的进程也是这样。

原帖由 信赖CU 于 2007-6-9 19:22 发表

实际上真正醒的只有一个。

[ 本帖最后由 思一克 于 2007-6-11 08:58 编辑 ]

yulc

原帖由 思一克 于 2007-6-8 21:03 发表
我看了一下apache2.049(?)

在文件docs/manual/misc/perf-tunnng.html.en 中有详细解释lock accept的原因.
文件我记忆不是绝对清楚. 你可以grep -r "accept lock" *  或 grep -r "SINGLE_SOCKE ...

apache源码包中的文档,已经很久没去看过了..
我想是文档已经过时了,
那上面用的例子都是说在p166CPU/128M内存的机器上,内核是2.0.....

空灵静世

我刚刚做了个测试,两个线程都等在同一个socket的read上,当收到客户端的数据的时候,只有一个read返回
会否是因为只有一个线程被唤醒?
或则两个都被唤醒,但其中一个线程锁住了资源
又或则两个都被唤醒,但其中一个线程读的太快,导致另一个没内容可读

[ 本帖最后由 空灵静世 于 2007-8-30 17:41 编辑 ]

flw2

原帖由 空灵静世 于 2007-8-30 17:32 发表
我刚刚做了个测试,两个线程都等在同一个socket的read上,当收到客户端的数据的时候,只有一个read返回

想说明什么？
这个线程没有醒来？

空灵静世

刚刚重新编辑了下,只是想问几个问题
会否是因为只有一个线程被唤醒?
或则两个都被唤醒,但其中一个线程锁住了资源
又或则两个都被唤醒,但其中一个线程读的太快,导致另一个没内容可读

[ 本帖最后由 空灵静世 于 2007-8-30 17:45 编辑 ]

思一克

accept每次只唤醒一个.

recv 应该唤醒多个(没有具体实验)

原帖由 空灵静世 于 2007-8-30 17:42 发表
刚刚重新编辑了下,只是想问几个问题
会否是因为只有一个线程被唤醒?
或则两个都被唤醒,但其中一个线程锁住了资源
又或则两个都被唤醒,但其中一个线程读的太快,导致另一个没内容可读

空灵静世

有个线程就一直停留在read调用上的,
我客户端发送的是6000多个字节,
read的第三个参数都是10000

tclwp

FUTEX_REQUEUE (since Linux 2.5.70)
    This operation was introduced in order to avoid a "thundering herd" effect when FUTEX_WAKE is used and all processes woken up need to acquire another futex. This call wakes up val processes, and requeues all other waiters on the futex at address uaddr2. The arguments timeout and val3 are ignored.