在 .NET / .NET Core 中的异步 I/O 期间，线程池的完成端口线程如何表现？

Question

.NET / .NET Core 线程池在内部使用两种不同类别的线程：工作线程和 I/O 完成端口 (IOCP) 线程。两者都只是通常的托管线程，但用于不同的目的。通过不同的 API（例如 Task.Start 或 ThreadPool.QueueUserWorkItem），我可以在工作线程上启动 CPU 密集型异步操作（这不应该阻塞，否则线程池可能会创建额外的工作线程）。

但是执行 I/O 密集型异步操作呢？ IOCP 线程在这些情况下的表现如何？具体来说，我有以下问题：

• 如果我启动异步 I/O 操作（例如，针对文件、管道或网络），我怀疑当前线程分派了异步请求。我也知道（通过“通过 C# 进行 CLR”一书）CLR 注册到用于执行重叠异步 I/O 的 I/O 完成端口。我怀疑这个 IOCP 是绑定到异步操作的，以便稍后可以将异步操作结果排队到线程池中。 因此，我的假设是否正确，即启动异步请求时没有触及 IOCP 线程？
• 我怀疑当异步 I/O 操作的结果通过 CLR 的 I/O 完成端口报告时，这就是 IOCP 线程到位的地方。结果排队到线程池，并使用一个 IOCP 线程来处理它。但是，在阅读一些论坛线程like this one on MSDN 时，我感觉IOCP 线程实际上是用于分派请求然后阻塞直到返回结果。 是这样吗？当 I/O 操作由对方系统处理时，IOCP 线程是否阻塞？
• async await 和 SynchronizationContext 呢？ IOCP 线程是否处理异步 I/O 响应，然后例如在 UI 线程上排队继续（假设未调用 ConfigureAwait(false)）？
• Linux/MacOS X 上的 .NET Core 怎么样？没有 I/O 完成端口 - 它们是否以任何方式模拟？

Answer 1

Damien 和 Hans 为我指出了 cmets 的正确方向，我想在这个答案中总结一下。

Damien 指出Stephen Cleary's awesome blog 的帖子回答了前三点：

• 在调用线程上调度异步 I/O 操作。不涉及 IOCP 线程。
• 因此，在异步 I/O 期间没有 IOCP 线程阻塞。
• 当结果返回给 .NET 应用程序时，会借用一个 IOCP 线程来标记任务完成。延续排队到目标SynchronizationContext 或线程池。

Hans 指出 Linux 中存在与 IOCP 类似的机制（epoll）和 MacOS (kqueue)。