Подтвердить что ты не робот

Неужели очереди сообщений устарели в Linux?

Я играл с очередями сообщений (System V, но POSIX тоже должен быть в порядке) в Linux недавно, и они кажутся идеальными для моего приложения, но после прочтения программы программирования Unix я не уверен, действительно ли они хороший выбор.

http://www.faqs.org/docs/artu/ch07s02.html#id2922148

Верхний слой передачи сообщений System V IPC в значительной степени не используется. Нижний уровень, состоящий из разделяемой памяти и семафоров, по-прежнему имеет значительные приложения в ситуациях, когда необходимо выполнить блокировку взаимного исключения и некоторый общий обмен данными между процессами, запущенными на одном компьютере. Эти средства общей памяти System V превратились в API общей общей памяти POSIX, поддерживаемый в Linux, BSD, MacOS X и Windows, но не в классическом MacOS.

http://www.faqs.org/docs/artu/ch07s03.html#id2923376

Объекты System V IPC присутствуют в Linux и других современных Unix. Однако, поскольку они являются унаследованной функцией, они не выполняются очень часто. По всей видимости, версия Linux по состоянию на середину 2003 года имеет ошибки. Кажется, что никто не заботится о том, чтобы исправить их.

Неужели очереди сообщений System V по-прежнему не работают в более поздних версиях Linux? Я не уверен, что автор означает, что очереди сообщений POSIX должны быть в порядке?

Кажется, что сокеты являются предпочтительным IPC почти для любого (?), но я не вижу, как было бы очень просто реализовать очереди сообщений с сокетами или чем-то еще. Или я слишком много думаю?

Я не знаю, связано ли это с тем, что я работаю со встроенным Linux?

4b9b3361

ОТВЕТЫ

Ответ 1

Лично я очень люблю очереди сообщений и думаю, что они, возможно, являются наиболее недоиспользуемыми IPC в мире unix. Они быстрые и простые в использовании.

Несколько мыслей:

  • Некоторые из них - это просто мода. Старые вещи снова становятся новыми. Добавьте сверкающего делателя в очереди сообщений, и они могут быть в следующем году самыми новыми и самыми горячими вещами. Посмотрите Google Chrome, используя отдельные процессы вместо потоков для своих вкладок. Внезапно люди в восторге от того, что когда одна вкладка блокируется, она не сбивает весь браузер.

  • В общей памяти есть что-то вроде гало. Вы не являетесь "настоящим" программистом, если вы не сжимаете последний цикл из машины, а MQ незначительно менее эффективны. Для многих, если не для большинства приложений, это полная бессмыслица, но иногда трудно сломать мышление, как только оно удержит.

  • MQ действительно не подходят для приложений с неограниченными данными. Для этого проще использовать потоковые механизмы, такие как трубы или сокеты.

  • Варианты System V действительно не понравились. Как правило, вы можете использовать POSIX-версии IPC.

Ответ 2

Я фактически не использовал очереди сообщений POSIX, потому что всегда хочу оставить возможность распространять мои сообщения по сети. Имея это в виду, вы можете взглянуть на более надежный интерфейс передачи сообщений, например zeromq или что-то, что реализует AMQP.

Одна из приятных вещей около 0mq заключается в том, что при использовании из одного и того же пространства процесса в многопоточном приложении он использует механизм блокировки без нулей, который выполняется довольно быстро. Тем не менее, вы можете использовать один и тот же интерфейс для передачи сообщений по сети.

Ответ 3

Да, я думаю, что очереди сообщений подходят для некоторых приложений. Очереди сообщений POSIX обеспечивают более удобный интерфейс, в частности, вы можете предоставить имена очередей, а не идентификаторы, что очень полезно для диагностики неисправностей (упрощает просмотр, что есть).

Linux позволяет монтировать очереди сообщений posix как файловую систему и видеть их с помощью "ls", удалять их с помощью "rm", что тоже очень удобно (System V зависит от неуклюжей команды "ipcs" и "ipcrm" )

Ответ 4

Самые большие недостатки очереди сообщений POSIX:

  • Очередь сообщений POSIX не делает ее требованием совместимой с select(). (Она работает с select() в Linux, но не в системе Qnx)
  • У него есть сюрпризы.

Сокет Unix Datagram выполняет ту же задачу в очереди сообщений POSIX. И сокет Unix Datagram работает в сокетном слое. Его можно использовать с помощью select()/poll() или других методов ожидания ввода-вывода. Использование select()/poll() имеет преимущество при разработке системы на основе событий. Таким образом можно избежать цикла занятости.

В очереди сообщений есть неожиданность. Подумайте о mq_notify(). Он используется для получения приема-события. Похоже, мы можем что-то сообщить о очереди сообщений. Но он фактически регистрируется для уведомления, а ничего не уведомляет.

Больше удивления о mq_notify() заключается в том, что он должен вызываться после каждого mq_receive(), что может вызвать условие гонки (когда какой-то другой вызов процесса/потока mq_send() между вызовом mq_receive() и mq_notify() > ).

И он имеет целый набор mq_open, mq_send(), mq_receive() and mq_close() с собственным определением, которое является избыточным и в некоторых случаях несовместимым с спецификацией метода socket open(),send(),recv() and close().

Я не думаю, что очередь сообщений должна использоваться для синхронизации. eventfd и signalfd.

Но он имеет некоторую поддержку в реальном времени. Он имеет приоритетные функции.

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.