PIPES使用什麼機制來「喚醒」收件人？

Question

我有兩個問題就是一個這裏。

在Windows上，我熟悉管道及其工作原理。但是，我很好奇操作系統使用什麼機制來通知接收消息到達的線程。

線程「輪詢&連續睡眠」的數據？操作系統是否檢查線程是否正在睡眠並喚醒它？還是有一些其他機制使用？

具體而言，我想建立一個IPC系統，許多線程需要傳遞消息。我不需要使用管道，但我確實需要知道可能的最有效的通知方法。

Answer 1

開發人員可以決定他們想如何使用管道，他們是否會進行睡眠/輪詢，或者他們想要調用阻塞函數並等待數據可用。

關於管道喚醒進程的機制 - 假設進程處於阻塞讀取調用 - 它不是管道，但操作系統是一個負責任的操作系統，就像其他操作系統一樣調用：它註冊操作並阻塞進程/線程，直到數據可用。當數據可用時，它完成系統調用。

Answer 2

這是Unix的答案。我認爲在Windows上非常相似，因爲解決方案已經存在了很長時間，並且衆所周知它是強大的。細節會有所不同（不同的API調用，語義細節等）

這取決於另一端是否在阻塞或非阻塞模式下使用管道的文件描述符。

在阻塞模式下，進程正在OS內核中等待數據可用。通知發生的方式取決於操作系統。很可能它涉及一系列被認爲是可運行的進程，並且內核可以（很大程度上）控制中斷它的事實，從而簡化了一切。在一個簡單的（單處理器）實現中，你可以做一些微不足道的事情，例如注意寫入管道，其他進程正在等待從管道讀取數據（通過某種「興趣集」），並將讀寫器標記爲可運行在那個時間點（在這個時間點上調度器決定）。

在非阻塞模式下，無論是進程不時輪詢（yuck！），還是使用系統調用如select()或poll()（也有一些更高性能的變體）。這非常類似於Windows調用WaitForMultipleObjects()，並且對於管道來說非常有用。這反過來又回到了可運行的進程隊列，興趣集和調度程序。

由於控制流在讀者和作者之間是非常對稱的，因此它是否因阻塞，因爲管道已滿或管道爲空而無關緊要。 （當然，與數據流不同）