linux - Linux 上是否还存在 Thundering Herd 问题？

Question

许多 linux/unix 编程书籍和教程都谈到了 "Thundering Herd Problem"当在等待监听套接字的可读性的 select() 调用上阻塞了多个线程或 fork 时，就会发生这种情况。当连接进入时，所有线程和 fork 都被唤醒，但只有一个“获胜”并成功调用“accept()”。与此同时，大量的 cpu 时间被无缘无故地唤醒了所有的线程/ fork 。

我注意到 project它为 linux 内核中的这个问题提供了一个“修复”，但这是一个非常古老的补丁。

我认为有两种变体；一种是每个 fork 执行 select() 然后 accept()，另一种是只执行 accept()。

现代 unix/linux 内核在这两种情况下是否仍然存在 Thundering Herd Problem 或只有“select() then accept()”版本？

Answer 1

多年来，大多数 unix/linux 内核将响应序列化到 accept(2)，换句话说，如果多个线程在 accept(2) 上阻塞单个打开的文件描述符，则只有一个线程被唤醒。

OTOH，正如您所描述的，许多(如果不是全部)内核在选择接受模式中仍然存在雷鸣般的羊群问题。

我写了一个简单的脚本(https://gist.github.com/kazuho/10436253)来验证问题的存在，发现问题存在于linux 2.6.32和Darwin 12.5.0(OS X 10.8.5)上。