windows - I/O完成端口的优缺点

Question

为什么很多人说I/O完成端口是一个又快又好的模型？
I/O完成端口的优缺点是什么？

我想知道使 I/O 完成端口比其他方法更快的一些要点。

如果能和其他模型(select、epoll、传统的多线程/多进程)进行对比说明，那就更好了。

Answer 1

I/O 完成端口很棒。没有更好的词来形容他们。如果 Windows 中有任何事情做得对，那就是完成端口。

您可以创建一定数量的线程(多少并不重要)并使它们全部阻塞在一个完成端口上，直到发生事件(您手动发布的线程，或来自 a timer 或 异步 I/O，或其他)到达。然后完成端口将唤醒一个线程来处理事件，直到达到您指定的限制。如果您未指定任何内容，它将假定“最多 CPU 内核数”，这非常好。

如果已经有超过最大限制的线程处于事件状态，它将等待其中一个完成，然后在进入等待状态后立即将事件传递给线程。此外，它始终会按 LIFO 顺序唤醒线程，因此缓存很可能仍然是热的。

换句话说，完成端口是一个简单的“事件轮询”以及“尽可能多地填充 CPU”的解决方案。

您可以在完成端口、套接字或任何其他可等待的地方抛出文件读取和写入。而且，您可以根据需要发布自己的事件。每个自定义事件至少有一个整数和一个指针值的数据(如果您使用默认结构)，但您并不仅限于此，因为系统也很乐意接受任何其他结构。

此外，完成端口非常快。曾几何时，我需要从另一个线程通知一个线程。碰巧的是，该线程已经有一个用于文件 I/O 的完成端口，但它没有发送消息。所以，我想知道我是否应该硬着头皮使用完成端口来简单起见，尽管发布线程消息显然会更有效率。我犹豫不决，所以我进行了基准测试。令人惊讶的是，完成端口的速度大约快了 3 倍。所以...更快、更灵活，这个决定并不难。