77

有人可以解释epoll,poll和线程池之间的区别吗？

  • 有什么优点/缺点？
  • 对框架有什么建议吗？
  • 对简单/基本教程有什么建议吗？
  • 似乎epoll并且poll是特定于 Linux 的...... Windows 是否有等效的替代方案？
4

1 回答 1

220

线程池与 poll 和 epoll 并不真正属于同一类别，因此我假设您指的是线程池，如“线程池处理多个连接，每个连接一个线程”。

优点和缺点

  • 线程池
    • 对中小型并发相当有效，甚至可以胜过其他技术。
    • 使用多个核心。
    • 尽管某些系统（例如 Linux）原则上可以很好地调度 100,000 个线程，但其扩展性不会超过“数百个”。
    • 幼稚的实现表现出“雷霆万钧”的问题。
    • 除了上下文切换和雷鸣般的羊群之外，还必须考虑记忆。每个线程都有一个堆栈（通常至少一个兆字节）。因此，一千个线程仅占用一千兆字节的 RAM 用于堆栈。即使没有提交该内存，它仍然会占用 32 位操作系统下的大量地址空间（在 64 位下不是真正的问题）。
    • 线程实际上可以epoll使用，虽然显而易见的方法（所有线程阻塞 on epoll_wait）是没有用的，因为 epoll 会唤醒每个等待它的线程，所以它仍然会有同样的问题。
      • 最优方案：单线程监听epoll，做输入复用，将完成的请求交给线程池。
      • futex是你的朋友吗，结合每个线程的快进队列。尽管文档记录不充分且笨拙，但futex提供了所需的内容。epoll一次可能会返回多个事件，并futex让您以精确控制的方式有效地一次唤醒N个阻塞线程（N 是min(num_cpu, num_events)理想的），并且在最好的情况下它根本不涉及额外的系统调用/上下文切换。
      • 实施起来并不简单，需要注意。
  • fork（又名旧时尚线程池）
    • 对中小型并发相当高效。
    • 无法扩展到“几百”之外。
    • 上下文切换要昂贵得多（不同的地址空间！）。
    • 在 fork 成本更高（所有页面的深拷贝）的旧系统上扩展得更糟。即使在现代系统fork上也不是“免费的”，尽管开销主要由写时复制机制合并。在也被修改的大型数据集上，大量的页面错误fork可能会对性能产生负面影响。
    • 然而，证明可以可靠地工作超过 30 年。
    • 非常容易实现并且坚如磐石：如果任何进程崩溃，世界不会结束。（几乎）没有什么是你可以做错的。
    • 很容易出现“雷声”。
  • poll/select
    • 两种风格（BSD 与 System V）或多或少是相同的东西。
    • 有点旧和慢，有点尴尬的用法，但几乎没有不支持它们的平台。
    • 等待直到在一组描述符上“发生某些事情”
      • 允许一个线程/进程一次处理多个请求。
      • 没有多核使用。
    • 每次等待时都需要将描述符列表从用户复制到内核空间。需要对描述符执行线性搜索。这限制了它的有效性。
    • 不能很好地扩展到“数千”（事实上，在大多数系统上硬限制在 1024 左右，或者在某些系统上低至 64）。
    • 使用它是因为如果您无论如何只处理十几个描述符（那里没有性能问题），或者如果您必须支持没有更好的平台，它是可移植的。请勿使用其他方式。
    • 从概念上讲，服务器变得比分叉的服务器稍微复杂一些，因为您现在需要为每个连接维护许多连接和一个状态机，并且您必须在请求进入时在请求之间进行多路复用、组装部分请求等。一个简单的分叉服务器只知道一个套接字（嗯，两个，计算监听套接字），读取直到它有它想要的或者直到连接半关闭，然后写它想要的任何东西。它不担心阻塞、就绪或饥饿，也不担心一些不相关的数据进入，这是其他进程的问题。
  • epoll
    • 仅限 Linux。
    • 昂贵修改与高效等待的概念：
      • 添加描述符时将有关描述符的信息复制到内核空间 ( epoll_ctl)
        • 这通常是很少发生的事情。
      • 等待事件时不需要将数据复制到内核空间（epoll_wait）
        • 这通常是经常发生的事情。
      • 将等待者（或者更确切地说是它的 epoll 结构）添加到描述符的等待队列中
        • 因此，描述符知道谁在听，并在适当的时候直接向服务员发出信号，而不是让服务员搜索描述符列表
        • 相反的poll工作方式
        • O(1) 在描述符数量方面具有小 k（非常快），而不是 O(n)
    • timerfd与and配合得非常好eventfd（令人惊叹的计时器分辨率和准确性，也是）。
    • 与 配合得很好signalfd，消除了对信号的笨拙处理，以一种非常优雅的方式使它们成为正常控制流的一部分。
    • 一个 epoll 实例可以递归地托管其他 epoll 实例
    • 该编程模型所做的假设：
      • 大多数描述符大部分时间都是空闲的，很少有事情（例如“收到数据”，“连接关闭”）实际上发生在少数描述符上。
      • 大多数时候，您不想从集合中添加/删除描述符。
      • 大多数时候，你都在等待某事发生。
    • 一些小陷阱：
      • 级别触发的 epoll 唤醒所有等待它的线程（这是“按预期工作”），因此将 epoll 与线程池一起使用的天真方式是没有用的。至少对于 TCP 服务器来说，这不是什么大问题，因为无论如何都必须先组装部分请求，所以天真的多线程实现不会做任何一种方式。
      • 对于文件读/写（“始终准备好”），不能像预期的那样工作。
      • 直到最近才能与 AIO 一起使用，现在可以通过eventfd，但需要（迄今为止）未记录的功能。
      • 如果上述假设不成立，则 epoll 可能效率低下，poll但性能可能相同或更好。
      • epoll不能做“魔术”，即就发生的事件数量而言，它仍然必然是 O(N) 。
      • 但是，epoll与新的recvmmsg系统调用配合得很好，因为它一次返回多个就绪通知（尽可能多的可用，直到您指定的任何内容maxevents）。这使得在繁忙的服务器上通过一个系统调用接收例如 15 条 EPOLLIN 通知成为可能，并通过第二个系统调用读取相应的 15 条消息（系统调用减少了 93%！）。不幸的是，一个调用上的所有操作都recvmmsg引用同一个套接字，因此它对于基于 UDP 的服务非常有用（对于 TCP，必须有一种recvmmsmsg系统调用，它也需要每个项目的套接字描述符！）。
      • 描述符应始终设置为非阻塞，EAGAIN即使在使用时也应检查，epoll因为存在epoll报告准备就绪和后续读取（或写入）仍会阻塞的特殊情况。poll某些内核上的/也是这种情况select（尽管它可能已被修复）。
      • 使用简单的实现，慢速发送者的饥饿是可能的。当在收到通知后盲目读取直到EAGAIN返回时，可能会无限期地从快速发送方读取新传入数据，同时完全饿死慢速发送方（只要数据保持足够快，您可能会很长时间看不到EAGAIN！ ）。以同样的方式适用于poll/ 。select
      • 边缘触发模式在某些情况下有一些怪癖和意外行为，因为文档（手册页和 TLPI）含糊不清（“可能”、“应该”、“可能”）并且有时会误导其操作。
        文档指出，在一个 epoll 上等待的多个线程都已发出信号。它进一步指出，通知告诉您自上次调用以来是否发生了 IO 活动epoll_wait（或者自打开描述符以来，如果没有先前的调用）。
        边缘触发模式下真实的、可观察的行为更接近于“唤醒第一个调用的线程，epoll_wait表明自从任何人最后一次调用或 epoll_wait 描述符上的读/写函数，然后只向下一个调用或已经阻塞的线程再次报告准备情况，对于任何 人epoll_wait在描述符上调用读（或写）函数之后发生的任何操作“。这有点道理，也......这并不完全是文档所建议的。
  • kqueue
    • BSD类比epoll，不同的用法，类似的效果。
    • 也适用于 Mac OS X
    • 据说更快（我从未使用过它，所以无法判断这是不是真的）。
    • 在单个系统调用中注册事件并返回结果集。
  • IO 完成端口
    • Windows 的 epoll，或者更确切地说是类固醇上的 epoll。
    • 以某种方式与所有可等待或可警报的事物无缝协作（套接字、可等待计时器、文件操作、线程、进程）
    • 如果微软在 Windows 中做对了一件事，那就是完成端口：
      • 使用任意数量的线程，开箱即用无忧
      • 没有雷鸣般的牛群
      • 以 LIFO 顺序一一唤醒线程
      • 保持缓存温暖并最大限度地减少上下文切换
      • 尊重机器上的处理器数量或提供所需数量的工人
    • 允许应用程序发布事件，这有助于实现非常简单、故障安全和高效的并行工作队列实现（在我的系统上每秒调度超过 500,000 个任务）。
    • 次要缺点：添加后不容易删除文件描述符（必须关闭并重新打开）。

构架

libevent -- 2.0 版本还支持 Windows 下的完成端口。

ASIO——如果你在你的项目中使用了 Boost，不要再犹豫了：你已经将它作为 boost-asio 提供了。

对简单/基本教程有什么建议吗？

上面列出的框架带有大量文档。Linux文档和 MSDN 广泛解释了 epoll 和完成端口。

使用 epoll 的小教程：

int my_epoll = epoll_create(0);  // argument is ignored nowadays

epoll_event e;
e.fd = some_socket_fd; // this can in fact be anything you like

epoll_ctl(my_epoll, EPOLL_CTL_ADD, some_socket_fd, &e);

...
epoll_event evt[10]; // or whatever number
for(...)
    if((num = epoll_wait(my_epoll, evt, 10, -1)) > 0)
        do_something();

IO 完成端口的迷你教程（注意两次使用不同的参数调用 CreateIoCompletionPort）：

HANDLE iocp = CreateIoCompletionPort(INVALID_HANDLE_VALUE, 0, 0, 0); // equals epoll_create
CreateIoCompletionPort(mySocketHandle, iocp, 0, 0); // equals epoll_ctl(EPOLL_CTL_ADD)

OVERLAPPED o;
for(...)
    if(GetQueuedCompletionStatus(iocp, &number_bytes, &key, &o, INFINITE)) // equals epoll_wait()
        do_something();

（这些 mini-tuts 省略了所有类型的错误检查，希望我没有打错字，但它们在大多数情况下应该可以给你一些想法。）

编辑：
请注意，完成端口（Windows）在概念上与 epoll（或 kqueue）相反。顾名思义，它们发出的信号是完成，而不是准备就绪。也就是说，您触发一个异步请求并忘记它，直到一段时间后您被告知它已经完成（成功或不太成功，并且还有“立即完成”的例外情况）。
使用 epoll，您会一直阻塞，直到您被通知“一些数据”（可能只有一个字节）已经到达并且可用，或者有足够的缓冲区空间以便您可以在不阻塞的情况下执行写入操作。只有这样，您才开始实际操作，然后希望它不会阻塞（与您期望的不同，对此没有严格的保证——因此最好将描述符设置为非阻塞并检查 EAGAIN [EAGAIN和EWOULDBLOCK对于套接字，因为天哪，标准允许两个不同的错误值]）。

于 2011-03-27T14:25:23.037 回答