Я работаю над очередью сообщений, используемой для связи между процессами во встроенном 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() что может быть лучше для вас (такое смущение от богатства).
Однако вам нужно будет проверить, какой из них установлен на ваших целевых платформах по умолчанию. Особенно во встроенной системе может случиться так, что вам придется их настроить или даже установить, потому что их нет по умолчанию (и то же самое может быть верно для общей памяти и семафоров).
Основное преимущество любого из наборов средств обработки сообщений заключается в том, что они предварительно отлажены (вероятно) и, следовательно, в них уже решены проблемы параллелизма, в то время как если вы собираетесь делать это самостоятельно с общей памятью и семафорами, у вас есть много возможностей. работы, чтобы достичь того же уровня функциональности.
Итак, (повторно) используйте, когда можете. Если есть возможность, используйте одну из двух систем очередей сообщений, а не изобретайте собственную. Если вы в конечном итоге обнаружите, что есть узкое место в производительности или что-то подобное, вы можете изучить возможность написания собственных альтернатив, но до тех пор используйте повторно!
Очереди сообщений System V (те, которыми манипулируют системные вызовы msg*) имеют множество странных особенностей и подводных камней. Для нового кода я настоятельно рекомендую использовать сокеты домена UNIX.
При этом я также настоятельно рекомендую IPC с передачей сообщений по схемам с общей памятью. В общей памяти гораздо легче ошибиться, и она имеет тенденцию к гораздо более катастрофическим последствиям.
Передача сообщений отлично подходит для небольших фрагментов данных и там, где необходимо поддерживать неизменность, поскольку очереди сообщений копируют данные.
Область общей памяти не копирует данные при отправке/получении и может быть более эффективной для больших наборов данных за счет менее чистой модели программирования.
shm, но не блокировали бы его с помощью sem? Вы бы написали shm, а затем передали сообщение ipc, чтобы объявить, что данные готовы? 16.12.2014 Недостатки очередей сообщений минимальны — некоторые системные вызовы и накладные расходы на копирование — которые для большинства приложений ничего не значат. Преимущества намного перевешивают эти накладные расходы. Синхронизация происходит автоматически, и их можно использовать по-разному: блокируя, не блокируя, а поскольку в Linux типы очередей сообщений реализованы в виде файловых дескрипторов, их можно даже использовать в select() вызовах для мультиплексирования. В разновидности POSIX, которую вы должны использовать, если у вас нет действительно острой необходимости использовать очереди SYSV, вы даже можете автоматически генерировать потоки или сигналы для обработки элементов очереди. И лучше всего они полностью отлажены.
Очередь сообщений и разделяемая память отличаются. И это зависит от программиста и его требований, чтобы выбрать, что использовать. В общей памяти вы должны быть немного осторожны при чтении и записи. И процессы должны быть синхронизированы. Таким образом, порядок выполнения очень важен в разделяемой памяти. В разделяемой памяти невозможно определить, является ли считываемое значение новым записанным значением или более старым. И нет явного механизма ожидания.
Очередь сообщений и разделяемая память отличаются. И это зависит от программиста и его требований, чтобы выбрать, что использовать. Существуют предопределенные функции, облегчающие вашу жизнь в очереди сообщений.
