windows - Windows 管道用于进程间通信的主要缺点是什么？

Question

假设您正在将一个单一的 Windows 程序拆分为可重用的组件，这些组件可以使用某种 inter-process communication 相互通信(IPC)，并且无论出于何种原因，您都选择匿名管道(例如，启动多个 Process-es 并将 Console.Out 连接到 Console.In 下一个进程，或者仅在命令提示符中使用“|”)。

Dobbs 博士的文章和示例 with named pipes :

与同一台机器中的其他 IPC 方法相比，性能损失是多少？当进程数量或传输的数据量增加时，第一个遇到的问题是什么？

例如如果我们使用文件而不是管道，我们会遇到锁定问题和磁盘速度问题。

请注意，必须序列化正在传输的数据结构已经产生了开销，这是我认为效率损失的基准。

附言。对管道的兴趣是因为它们很容易在每个进程(Console.Readline、Console.WriteLine)中实现，很容易为它们编写 MSMQ 和异步 HTTP 接口(interface)，以及对 Unix 和命令行的热爱。

Answer 1

您可以使用 CreatePipe() Win32 API 调用创建双向匿名管道，因此管道输入/输出不是唯一的方法。您只需获得一个可以提供给其他进程的新文件句柄。

匿名管道基于共享内存，但不支持异步操作(通过ReadFileEx、ReadFileWrite)。因此，性能问题(缺点)是 1) 同步操作，2) 内存复制，3) 进程间同步。通常，“原始”共享内存(没有实际支持文件的内存映射文件)和命名管道会更快，而套接字和窗口消息会更慢(比匿名管道)。

您不能将 I/O 完成端口 (IOCP) 与匿名管道一起使用，相反您必须“轮询”管道，从而导致额外的上下文切换。除了序列化数据之外，还必须在内存中复制序列化数据，因为您不能直接写入共享内存。一个进程还必须等待另一个进程，这意味着另一个进程必须发出进程间同步原语信号。性能在很大程度上取决于消息的大小(读/写调用与发送的数据量的比率)，因为对于每次读/写，进程都必须进行上下文切换，并可能进行自旋/ sleep 。

除了“原始”共享内存之外的所有方法都需要内存复制和某种进程间信号(同步)，因此匿名管道的主要缺点是同步操作。当 CPU 将大部分时间花在上下文切换上时，传输大量消息时您将达到上限。

在性能方面，命名管道更好，因为您可以让工作线程使用 IOCP 处理异步通知，甚至可以通过一次调用接收多条消息，从而减少 API 开销。如果制作您自己的组件，为管道命名所带来的额外麻烦是值得的(您甚至可以跨网络连接)。后来的 Windows 版本为本地套接字实现了特殊的路由，它也支持 IOCP。

最快的方法是直接使用共享内存，但是你必须自己处理进程间同步。可以自己实现无锁管道，但如果您不经常传输数据，您仍然必须使用同步原语来通知/唤醒监听进程。

另请注意，使用文件并不意味着您会受到磁盘速度的限制，因为您可以使用内存映射文件，即使是普通文件，缓存管理器也会处理读/写。其他方法(RPC、剪贴板等)都是基于这些“标准”方法，这意味着它们只是添加了一些额外的协议(protocol)层并且意味着更容易/更有帮助，或者更适合某些编程环境(但不要更快)。