Какой метод Linux IPC использовать? - PullRequest
66 голосов
/ 17 февраля 2010

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

Два других процесса должны будут иметь возможность отправлять / получать сообщения через процесс связи. Я пытаюсь оценить методы IPC, которые предоставляет Linux; сообщение, которое будут отправлять другие процессы, будет различаться по размеру, от журналов отладки до потокового мультимедиа со скоростью ~ 5 Мбит. Кроме того, мультимедиа может одновременно транслироваться и транслироваться.

Какой метод IPC вы бы предложили для этого приложения? http://en.wikipedia.org/wiki/Inter-process_communication

Процессор работает на 400-500 МГц, если это что-то меняет. Не нужно быть кроссплатформенным, только Linux хорошо. Требуется реализация на C или C ++.

Ответы [ 6 ]

61 голосов
/ 17 февраля 2010

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

Из доступных механизмов IPC выбор производительности часто сводится к доменным сокетам Unix или именованных каналов (FIFO) . Я прочитал статью о Анализ производительности различных механизмов межпроцессного взаимодействия , которая указывает, что доменные сокеты Unix для IPC могут обеспечить наилучшую производительность. Я видел противоречивые результаты в других местах , которые указывают, что трубы могут быть лучше.

При отправке небольших объемов данных я предпочитаю именованные каналы (FIFO) для их простоты. Это требует пары именованных каналов для двунаправленной связи. Доменные сокеты Unix требуют немного больше ресурсов при настройке (создание сокетов, инициализация и подключение), но они более гибкие и могут предложить более высокую производительность (более высокую пропускную способность).

Вам может потребоваться запустить некоторые тесты для вашего конкретного приложения / среды, чтобы определить, что будет работать лучше для вас. Из приведенного описания видно, что доменные сокеты Unix лучше всего подходят.


Руководство Beej по Unix IPC хорошо для начала работы с Linux / Unix IPC.

30 голосов
/ 17 февраля 2010

Я бы выбрал доменные сокеты Unix: меньше накладных расходов, чем IP-сокеты (т. Е. Нет межмашинных коммуникаций), но то же удобство в противном случае.

16 голосов
/ 18 февраля 2010

Не могу поверить, что никто не упомянул dbus.

http://www.freedesktop.org/wiki/Software/dbus

http://en.wikipedia.org/wiki/D-Bus

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

11 голосов
/ 18 февраля 2010

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

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

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

Общая память обычно получается путем mmapping того же файла с использованием MAP_SHARED (который может быть в tmpfs, если вы не хотите, чтобы он сохранялся); многие приложения также используют разделяемую память System V (ИМХО по глупым историческим причинам; гораздо менее приятный интерфейс к тому же)

4 голосов
/ 19 августа 2014

На момент написания статьи (ноябрь 2014 г.) Kdbus и Binder покинули промежуточную ветвь ядра Linux. На данный момент нет никаких гарантий, что кто-либо из них это сделает, но перспективы у обоих несколько позитивные. Binder - это облегченный механизм IPC в Android, Kdbus - это механизм, подобный dbus, в ядре, который уменьшает переключение контекста, тем самым значительно ускоряя обмен сообщениями.

Существует также «Прозрачная межпроцессная связь» или TIPC, которая является надежной, полезной для кластеризации и настройки нескольких узлов; http://tipc.sourceforge.net/

0 голосов
/ 27 июня 2019

Доменные сокеты Unix будут соответствовать большинству ваших требований IPC. В этом случае вам не нужен специальный процесс связи, поскольку ядро ​​предоставляет эту возможность IPC. Кроме того, обратите внимание на очереди сообщений POSIX, которые, по моему мнению, являются одним из наиболее малоиспользуемых IPC в Linux, но очень удобны во многих случаях, когда требуется обмен данными n: 1.

...