我有两个问题就在这里。
在Windows上，我熟悉管道及其工作原理。但是，我很好奇操作系统使用什么机制来通知收件人线程的邮件到达。
线程是否连续“轮询和休眠”数据？操作系统是否检查线程是否正在休眠并将其唤醒？或者是否使用了其他机制？
具体来说，我想构建一个IPC系统，其中许多线程需要传递消息。我不需要使用管道，但我确实需要知道最有效的通知方法。
答案 0 :(得分：0)
开发人员可以决定他们如何使用管道，他们是否会睡眠/轮询，或者他们想要调用阻塞函数并等待数据可用。
关于管道用于唤醒进程的机制 - 假设进程处于阻塞读取调用中 - 它不是管道，而是操作系统负责，就像在任何其他OS调用中一样：它注册操作并阻止进程/线程，直到数据可用。当数据可用时，它将完成系统调用。
答案 1 :(得分：0)
这是Unix的答案。由于解决方案已经存在了很长时间，并且众所周知，它在Windows上非常相似。细节会有所不同（不同的API调用，语义细节等）
这取决于另一端是否在阻塞或非阻塞模式下使用管道的文件描述符。
在阻塞模式下，进程正在OS内核中等待数据变为可用。通知的发生方式取决于操作系统。它可能涉及被认为是可运行的进程队列，并且由于内核可以（很大程度上）控制中断它的事实，所以一切都变得更简单。在一个简单的（单处理器）实现中，你可以选择一些简单的操作，就像写入另一个进程正在等待从中读取的管道（通过某种“兴趣集”），并将读者标记为可运行的在那一点（此时由调度员决定）。
在非阻止模式下，要么流程不时轮询（哎呀！），要么他们正在使用select()或poll()之类的系统调用（有一些更高性能的变体太）。这非常类似于Windows调用WaitForMultipleObjects()，并且管道效果很好。这反过来又回到了那个可运行的进程队列，兴趣集和调度程序。
由于管道已满或管道是空的，它是否阻塞也无关紧要，因为控制流程在读取器和编写器之间几乎是对称的。 （当然，与数据流不同。）