Каковы недостатки очередей сообщений Linux?
Я работаю над очередью сообщений, используемой для связи между процессами на встроенном Linux. Мне интересно, почему я не использую очереди сообщений, предоставляемые Linux, следующим образом:
msgctl, msgget msgrcv, msgsnd.
вместо создания общей памяти и синхронизации с семафором?
В чем недостаток использования этого набора функций непосредственно для бизнес-встраиваемого продукта?
5 ответов
Это функции очереди сообщений 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 для передачи сообщений по схемам с общей памятью. Совместно используемую память намного легче ошибиться, и она может пойти не так, как надо, гораздо более катастрофически.
Передача сообщений отлично подходит для небольших порций данных, где необходимо поддерживать неизменность, поскольку очереди сообщений копируют данные.
Область совместно используемой памяти не копирует данные при отправке / получении и может быть более эффективной для больших наборов данных за счет менее чистой модели программирования.
Недостатки очереди сообщений незначительны - некоторые системные вызовы и накладные расходы на копирование - которые для большинства приложений ничего не значат. Преимущества намного перевешивают эти накладные расходы. Синхронизация является автоматической, и их можно использовать различными способами: блокировать, неблокировать, и, поскольку в linux типы очереди сообщений реализованы в виде файловых дескрипторов, они могут даже использоваться в select() призывает к мультиплексированию. В разновидности POSIX, которую вы должны использовать, если у вас нет действительно насущной необходимости использовать очереди SYSV, вы даже можете автоматически генерировать потоки или сигналы для обработки элементов очереди. И лучше всего они полностью отлажены.
Очередь сообщений и общая память разные. И это зависит от программиста и его требования, чтобы выбрать, какой использовать. В общей памяти вы должны быть немного осторожны при чтении и письме. И процессы должны быть синхронизированы. Так что порядок выполнения очень важен в разделяемой памяти. В разделяемой памяти нет способа определить, является ли значение чтения новым записанным значением или старым. И нет явного механизма ожидания.
Очередь сообщений и общая память разные. И это зависит от программиста и его требования, чтобы выбрать, какой использовать. Есть предопределенные функции, чтобы сделать вашу жизнь проще в очереди сообщений.