Это ответ для Unix. Я бы положил хорошие деньги на то, что Windows довольно похожа, поскольку решение существует уже давно и, как известно, является надежным. Детали могут немного отличаться (различные вызовы API, особенности семантики и т. Д.)
Это зависит от того, использует ли другой конец дескриптор файла канала в режиме блокировки или неблокирования.
В режиме блокировки процесс ожидает в ядре ОС получения данных. Способ получения уведомлений зависит от операционной системы. Скорее всего, он включает в себя очередь процессов, которые считаются работоспособными, и все становится проще благодаря тому факту, что ядро может (в значительной степени) контролировать то, что его прерывает. В простой (однопроцессорной) реализации вы могли бы пойти на что-то столь же тривиальное, как отметить при записи в канал, что другой процесс ожидает чтения из него (через некоторый «набор интересов»), и пометить читателя как работоспособного в этот момент (в этот момент решение принимается планировщиком).
В неблокирующем режиме либо процесс время от времени опрашивает (чёрт!), Либо они используют системный вызов, такой как select() или poll() (есть и более высокопроизводительные варианты). Это очень похоже на вызов Windows WaitForMultipleObjects() и прекрасно работает с каналами. Это, в свою очередь, заканчивается в той очереди выполняемых процессов, наборе процентов и планировщике.
Также не имеет особого значения, блокируется ли он, потому что канал заполнен или канал пуст, поскольку поток управления симметричен между читателями и писателями. (В отличие от потока данных, конечно.)