Крупнейшие недостатки очереди сообщений POSIX:
- Очередь сообщений POSIX не предъявляет требования для совместимости с
select(). (В Linux она работает с select(), но не в системе Qnx)
- Есть сюрпризы.
Сокет Unix Datagram выполняет ту же задачу, что и очередь сообщений POSIX. И сокет Unix Datagram работает на уровне сокетов. Можно использовать его с select() / poll() или другими методами IO-wait. Использование select() / poll() имеет преимущество при разработке основанной на событиях системы. Таким образом можно избежать занятого цикла.
В очереди сообщений есть сюрприз. Подумайте о mq_notify(). Используется для получения receive-event. Похоже, мы можем что-то уведомить об очереди сообщений. Но на самом деле он регистрируется для уведомления, а не для уведомления.
Еще большее удивление в отношении mq_notify() заключается в том, что он должен вызываться после каждого mq_receive(), что может вызвать состояние гонки (когда какой-то другой процесс / поток вызывает mq_send() между вызовами mq_receive() и mq_notify()).
И у него есть целый набор mq_open, mq_send(), mq_receive() and mq_close() со своим собственным определением, которое является избыточным и в некоторых случаях несовместимым со спецификацией метода сокета open(),send(),recv() and close().
Я не думаю, что очередь сообщений должна использоваться для синхронизации. eventfd и signalfd подходят для этого.
Но it (очередь сообщений POSIX) имеет некоторую поддержку в реальном времени . Имеет приоритетные функции.
Messages are placed on the queue in decreasing order of priority, with newer messages of the same priority being placed after older messages with the same priority.
Но этот приоритет также доступен для сокета как внеполосных данных!
Наконец, для меня очередь сообщений POSIX является устаревшим API. Я всегда предпочитаю сокет Unix Datagram вместо очереди сообщений POSIX, если функции реального времени не нужны.