Which Notification Mechanism Is Best for High‑Concurrency Message Queues?

High Concurrency Message Queue Notification Mechanisms

Recently I have been researching a high‑performance lock‑free shared‑memory message queue that uses FIFO for notification. Building on the previous article “A Million‑Connection Server Model Based on Pipe Notification”, I summarize the commonly used notification mechanisms.

Typical mechanisms include:

Signal : Send a special signal (e.g., SIGUSR1) to the waiting process, which interrupts its sleep and wakes it. Advantages: no extra eventfd needed; can use real‑time or non‑real‑time signals. Disadvantages: notification is not immediate; signal checking occurs only on interrupt return, depending on OS HZ and jiffies.

Socket : The writer writes a byte to a domain socket; the reader receives a notification via epoll.

FIFO : Similar to socket; the writer writes a byte to a FIFO, and the reader gets notified through epoll.

Pipe : Similar to socket and FIFO.

eventfd/signalfd : Kernel‑assisted FIFO or signal notification, available only in newer kernels. Requires passing handles between processes, making non‑fork implementations more complex.

All these methods share the characteristic that the notifying process must enter kernel mode to deliver the notification. For scenarios with strict performance requirements, minimizing kernel‑mode notifications is advisable. Whether a method is suitable depends on the business scenario and the overhead of sending notifications; if request volume is high and the reader is constantly busy, fewer notifications may be appropriate.