Каковы недостатки очередей сообщений Linux? - PullRequest
13 голосов
/ 05 марта 2012

Я работаю над очередью сообщений, используемой для связи между процессами во встроенном Linux.Мне интересно, почему я не использую очереди сообщений, предоставляемые Linux, следующим образом:

msgctl, msgget msgrcv, msgsnd.

вместо создания общей памяти и синхронизации с семафором?

В чем недостаток использования этого набора функций непосредственно для бизнес-встраиваемого продукта?

Ответы [ 5 ]

9 голосов
/ 05 марта 2012

Это функции очереди сообщений «System V IPC».Они будут работать на вас, но они довольно тяжелые.Они стандартизированы POSIX.POSIX также предоставляет более современный набор функций, mq_close, mq_getattr, mq_notify, mq_open, mq_receive, mq_send, mq_setattr, mq_unlink, которые могут быть лучше для вас (такие каксмущение богатства).Однако вам нужно будет проверить, какой из них, если он установлен, установлен на ваших целевых платформах по умолчанию.В частности, во встроенной системе может потребоваться их настройка или даже их установка, поскольку по умолчанию их нет (и то же самое можно сказать и о разделяемой памяти и семафорах).

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

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

6 голосов
/ 05 марта 2012

Очереди сообщений System V (те, которыми манипулируют системные вызовы msg *) имеют много странных причуд и ошибок. Для нового кода я настоятельно рекомендую использовать доменные сокеты UNIX.

При этом я также настоятельно рекомендую IPC для передачи сообщений по схемам с общей памятью. Совместно используемую память намного легче ошибиться, и она может пойти не так, как надо, гораздо более катастрофически.

2 голосов
/ 05 марта 2012

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

Область общей памяти не копирует данные при отправке / получении и может быть более эффективной для больших наборов данных при компромиссе с менее чистой моделью программирования.

1 голос
/ 05 марта 2012

Недостатки очереди сообщений незначительны - некоторые системные вызовы и издержки копирования - которые для большинства приложений ничего не значат. Преимущества намного перевешивают эти накладные расходы. Синхронизация является автоматической, и их можно использовать различными способами: блокировать, неблокировать, и, поскольку в linux типы очереди сообщений реализованы в виде файловых дескрипторов, они могут даже использоваться в вызовах select() для мультиплексирования. В разновидности POSIX, которую вы должны использовать, если у вас нет действительно насущной необходимости использовать очереди SYSV, вы даже можете автоматически генерировать потоки или сигналы для обработки элементов очереди. И лучше всего они полностью отлажены.

0 голосов
/ 05 марта 2012

Очередь сообщений и общая память различны. И это зависит от программиста и его требования, чтобы выбрать, какой использовать. В общей памяти вы должны быть немного осторожны при чтении и письме. И процессы должны быть синхронизированы. Так что порядок выполнения очень важен в разделяемой памяти. В разделяемой памяти нет способа определить, является ли значение чтения новым записанным значением или старым. И нет явного механизма ожидания.

Очередь сообщений и общая память различаются. И это зависит от программиста и его требования, чтобы выбрать, какой использовать. Есть предопределенные функции, чтобы сделать вашу жизнь проще в очереди сообщений.

...