Который Linux метод IPC для использования?
Мы находимся все еще в стадии проектирования нашего проекта, но мы думаем о наличии трех отдельных процессов на встроенном ядре Linux. Один из процессов с быть модулем связи, который обрабатывает всю связь к и от устройства до различного носителя.
Другие два процесса должны будут смочь отправить/получить сообщения посредством процесса связи. Я пытаюсь оценить методы IPC, которые обеспечивает Linux; сообщение, которое будут отправлять другие процессы, будет варьироваться по размеру от журналов отладки до потоковых медиа на уровне на ~5 Мбит. Кроме того, медиа могли передавать потоком в и одновременно.
Какой метод IPC был бы Вы предложение для этого приложения? http://en.wikipedia.org/wiki/Inter-process_communication
Процессор обтекает 400-500 МГц, если это изменяет что-нибудь. Не должно быть межплатформенным, Linux только прекрасен. Реализация в C или C++ требуется.
4 ответа
Я бы выбрал доменные сокеты Unix: меньше накладных расходов, чем IP-сокеты (т.е. без межмашинной связи), но такое же удобство в остальном.
При выборе IPC следует учитывать причины различий в производительности, включая размер буфера передачи, механизмы передачи данных, схемы распределения памяти, реализацию механизма блокировки и даже сложность кода.
Из доступных механизмов IPC выбор производительности часто сводится к сокетам домена Unix или именованным трубам (FIFO). Я читал статью Performance Analysis of Various Mechanisms for Inter-process Communication, в которой говорится, что сокеты домена Unix для IPC могут обеспечить наилучшую производительность. Я видел противоречивые результаты в других местах, которые указывают, что трубы могут быть лучше.
При отправке небольших объемов данных я предпочитаю именованные трубы (FIFO) из-за их простоты. Для двунаправленной связи требуется пара именованных труб. Сокеты домена Unix требуют немного больше накладных расходов на настройку (создание сокета, инициализация и соединение), но они более гибкие и могут обеспечить лучшую производительность (более высокую пропускную способность).
Вам может потребоваться провести несколько сравнительных тестов для вашего конкретного приложения/среды, чтобы определить, что будет работать лучше для вас. Из приведенного описания следует, что лучше всего подходят сокеты домена Unix.
Beej's Guide to Unix IPC хорошо подходит для начала работы с Linux/Unix IPC.
Если производительность действительно становится проблемой, можно использовать разделяемую память - но это намного сложнее, чем другие методы: вам понадобится механизм сигнализации о готовности данных (семафор и т.д.), а также блокировки для предотвращения одновременного доступа к структурам во время их изменения.
Плюсом является то, что вы можете передавать большое количество данных без необходимости копировать их в память, что определенно повысит производительность в некоторых случаях.
Возможно, существуют полезные библиотеки, которые предоставляют примитивы более высокого уровня через общую память.
Общую память обычно получают с помощью mmaping одного и того же файла, используя MAP_SHARED (который может находиться на tmpfs, если вы не хотите, чтобы он сохранялся); многие приложения также используют общую память System V (IMHO по глупым историческим причинам; это гораздо менее приятный интерфейс для того же самого)
.Не могу поверить, что никто не упомянул dbus.
http://www.freedesktop.org/wiki/Software/dbus
http://en.wikipedia.org/wiki/D-Bus
Может показаться немного преувеличенным, если ваше приложение архитектурно просто, и в этом случае - в контролируемой встроенной среде, где производительность имеет решающее значение - вы не сможете превзойти общую память.