Я работаю над очередью сообщений, используемой для связи между процессом на встроенной Linux. Мне интересно, почему я не использую очереди сообщений, предоставляемые Linux, следующим образом:
msgctl, msgget msgrcv, msgsnd.
вместо создания разделяемой памяти и синхронизации с семафором?
В чем заключается недостаток использования этого набора функций непосредственно в бизнес-встроенном продукте?
Функции msgctl(), msgget(), msgrcv() и msgsnd() являются сообщением "System V IPC" функции очереди. Они будут работать на вас, но они довольно тяжелые. Они стандартизированы POSIX.
POSIX также предоставляет более современный набор функций, mq_close(), mq_getattr(), mq_notify(), mq_open(), mq_receive(), mq_send(), mq_setattr() и mq_unlink(), что может быть лучше для вас (такое смущение богатства).
Однако вам нужно будет проверить, какой из них, если он установлен, установлен на ваших целевых платформах по умолчанию. В частности, во встроенной системе может потребоваться их настройка или даже их установка, поскольку по умолчанию их нет (и то же самое можно сказать о разделяемой памяти и семафорах).
Основное преимущество любого из наборов сообщений состоит в том, что они предварительно отлажены (возможно) и, следовательно, уже имеют проблемы с параллелизмом - в то время как если вы собираетесь сделать это для себя с общей памятью и семафорами, у вас есть много работы, чтобы достичь того же уровня функциональности.
Итак, (пере) использовать, когда вы можете. Если это вариант, используйте одну из двух систем очереди сообщений, а не изобретайте свою собственную. Если вы обнаружите, что существует узкое место в производительности или что-то подобное, вы можете заняться написанием собственных альтернатив, но до тех пор &— повторно!
Очереди сообщений системы V (те, которые управляются системными вызовами msg *) имеют много странных причуд и ошибок. Для нового кода я настоятельно рекомендую использовать сокеты домена UNIX.
При этом я также настоятельно рекомендую передавать IPC по протоколам общей памяти. Совместная память намного легче ошибиться и имеет тенденцию идти не так уж катастрофически.
Передача сообщений отлично подходит для небольших блоков данных и где необходимо сохранить неизменность, поскольку очереди сообщений копируют данные.
Область общей памяти не копирует данные при отправке/приеме и может быть более эффективной для больших наборов данных при компромиссе менее чистой модели программирования.
Недостатки очередей сообщений являются незначительными - некоторые системные вызовы и накладные расходы на копирование, которые не имеют большого значения для большинства приложений. Преимущества намного перевешивают эти накладные расходы. Синхронизация выполняется автоматически, и их можно использовать различными способами: блокирование, неблокирование, а так как в linux типы очереди сообщений реализованы как файловые дескрипторы, они могут даже использоваться в select() вызовах мультиплексирования. В разновидности POSIX, которую вы должны использовать, если у вас нет реальной необходимости использовать очереди SYSV, вы даже можете автоматически генерировать потоки или сигналы для обработки элементов очереди. И лучше всего они полностью отлажены.
Очередь сообщений и общая память различны. И это зависит от программиста и его требования выбрать, что использовать. В общей памяти вы должны быть осторожны при чтении и письме. И процессы должны быть синхронизированы. Таким образом, порядок выполнения очень важен в общей памяти. В общей памяти невозможно определить, является ли значение чтения новым значением или более старым. И нет явного механизма ожидания.
Очередь сообщений и общая память различны. И это зависит от программиста и его требования выбрать, что использовать. Существуют предопределенные функции, облегчающие вашу жизнь в очереди сообщений.