posix 管道轻量吗？
在 Linux 应用程序中，我使用管道在线程之间传递信息。
使用管道背后的想法是我可以使用 poll(2) 一次等待多个管道。这在实践中效果很好，而且我的线程大部分时间都在休眠。他们只有在有事可做时才会醒来。
在用户空间中，管道看起来就像两个文件句柄。现在我想知道这样的管道在操作系统端使用了多少资源。
顺便说一句：在我的应用程序中，我时不时地只发送单个字节。将我的管道视为简单的消息队列，它允许我唤醒接收线程，告诉它们发送一些状态数据或终止。
In a linux application I'm using pipes to pass information between threads.
The idea behind using pipes is that I can wait for multiple pipes at once using poll(2). That works well in practice, and my threads are sleeping most of the time. They only wake up if there is something to do.
In user-space the pipes look just like two file-handles. Now I wonder how much resources such a pipes use on the OS side.
Btw: In my application I only send single bytes every now and then. Think about my pipes as simple message queues that allow me to wake-up receiving threads, tell them to send some status-data or to terminate.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
不，我不会认为管道是“轻量级”的，但这并不一定意味着它们对于您的应用程序来说是错误的答案。
通过管道发送一个字节至少需要 3 个系统调用（write、poll、read）。使用内存队列和 pthread 操作（mutex_lock、cond_signal）涉及的开销要少得多。打开文件描述符肯定会消耗内核资源；这就是为什么默认情况下进程通常限制为 256 个打开文件（并不是说该限制不能在适当的情况下扩展）。
尽管如此，用于线程间通信的管道/轮询解决方案也确实具有优点：特别是当您需要等待来自多个源（网络+其他线程）组合的输入时。
No, I would not consider pipes "lightweight", but that doesn't necessarily mean they're the wrong answer for your application either.
Sending a byte over a pipe is going to require a minimum of 3 system calls (write,poll,read). Using an in-memory queue and pthread operations (mutex_lock, cond_signal) involves much less overhead. Open file descriptors definitely do consume kernel resources; that's why processes are typically limited to 256 open files by default (not that the limit can't be expanded where appropriate).
Still, the pipe/poll solution for inter-thread communication does have advantages too: particularly if you need to wait for input from a combination of sources (network + other threads).
当您使用 Linux 时，您可以研究并比较
pipe与eventfd的性能。它们在技术上更快、重量更轻，但您会很幸运地在实践中实际看到收益。http://www.kernel.org/doc /man-pages/online/pages/man2/eventfd.2.html
As you are using Linux you can investigate and compare
pipeperformance witheventfd's. They are technically faster and lighter weight but you'll be very lucky to actually see the gains in practice.http://www.kernel.org/doc/man-pages/online/pages/man2/eventfd.2.html
测量一下，您就会知道。 使用管道的完整流程对于许多应用来说足够轻量。其他应用程序需要更轻量级的东西，比如操作系统线程（pthreads 是许多 Unix 应用程序的流行选择），或者超轻量级的东西，比如除了处理 I/O 之外从不进入内核模式的用户级线程包。虽然唯一确定的方法是测量，但管道可能足以容纳最多几十个线程，而一旦达到几十万个线程，您可能需要用户级线程。我不知道使用今天的代码到底应该在哪里划定界限。如果我想知道，我会测量:-)
Measure and you'll know. Full processes with pipes are sufficiently lightweight for lots of applications. Other applications require something lighter weight, like OS threads (pthreads being the popular choice for many Unix apps), or superlightweight, like a user-level threads package that never goes into kernel mode except to handle I/O. While the only way to know for sure is to measure, pipes are probably good enough for up to a few tens of threads, whereas you probably want user-level threads once you get to a few tens of thousands of threads. Exactly where the boundaries should be drawn using today's codes, I don't know. If I wanted to know, I would measure :-)