¿Qué técnica de Linux IPC usar?

Todavía estamos en la fase de diseño de nuestro proyecto, pero estamos pensando en tener tres procesos separados en un núcleo Linux embebido. Uno de los procesos es un módulo de comunicaciones que maneja todas las comunicaciones hacia y desde el dispositivo a través de varios medios.

Los otros dos procesos necesitarán poder enviar / recibir mensajes a través del proceso de comunicación. Estoy tratando de evaluar las técnicas de IPC que proporciona Linux; el mensaje que enviarán los otros procesos variará en tamaño, desde los registros de depuración hasta los medios de transmisión a una velocidad de ~ 5 Mbit. Además, los medios podrían estar entrando y saliendo simultáneamente.

¿Qué técnica de IPC recomendaría para esta aplicación? http://en.wikipedia.org/wiki/Inter-process_communication

El procesador corre alrededor de 400-500 Mhz si eso cambia algo. No necesita ser multiplataforma, Linux solo está bien. Implementación en C o C ++ es requerida.

Me gustaría utilizar los Sockets de dominio de Unix: menos sobrecarga que los sockets de IP (es decir, sin intercomunicadores) pero la misma conveniencia de lo contrario.

Al seleccionar su IPC, debe considerar las causas de las diferencias de rendimiento, incluidos los tamaños de búfer de transferencia, los mecanismos de transferencia de datos, los esquemas de asignación de memoria, las implementaciones de mecanismos de locking e incluso la complejidad del código.

De los mecanismos de IPC disponibles, la elección del rendimiento a menudo se reduce a los sockets de dominio de Unix o pipes con nombre (FIFO) . Leí un documento sobre el Análisis de rendimiento de varios mecanismos para la comunicación entre procesos que indica que los sockets de dominio de Unix para IPC pueden proporcionar el mejor rendimiento. He visto resultados conflictivos en otros lugares que indican que las tuberías pueden ser mejores.

Cuando envío pequeñas cantidades de datos, prefiero los pipes con nombre (FIFOs) por su simplicidad. Esto requiere un par de tubos con nombre para la comunicación bidireccional. Los sockets de dominio Unix requieren un poco más de sobrecarga para la configuración (creación de socket, inicialización y conexión), pero son más flexibles y pueden ofrecer un mejor rendimiento (mayor rendimiento).

Es posible que necesite ejecutar algunos puntos de referencia para su aplicación / entorno específico para determinar qué funcionará mejor para usted. Según la descripción proporcionada, parece que los sockets de dominio Unix pueden ser los más adecuados.


La Guía de Beej para Unix IPC es buena para comenzar con Linux / Unix IPC.

No puedo creer que nadie haya mencionado dbus.

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

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

Podría ser un poco exagerado si su aplicación es arquitectónicamente simple, en cuyo caso, en un entorno integrado controlado donde el rendimiento es crucial, no puede superar la memoria compartida.

Si el rendimiento realmente se convierte en un problema, puede usar la memoria compartida, pero es mucho más complicado que los otros métodos. Necesitará un mecanismo de señalización para indicar que los datos están listos (semáforo, etc.) y lockings para evitar el acceso simultáneo a las estructuras mientras están siendo modificados.

Lo bueno es que puede transferir una gran cantidad de datos sin tener que copiarlos en la memoria, lo que definitivamente mejorará el rendimiento en algunos casos.

Quizás haya bibliotecas utilizables que proporcionan primitivas de nivel superior a través de la memoria compartida.

Generalmente, la memoria compartida se obtiene mapeando el mismo archivo usando MAP_SHARED (que puede estar en un tmpfs si no desea que persista); muchas aplicaciones también usan la memoria compartida de System V (en mi humilde opinión por estúpidas razones históricas, es una interfaz mucho menos agradable para la misma cosa)

Para una revisión de los mecanismos “clásicos” de IPC de Linux: mira aquí .

Al escribir estas líneas (noviembre de 2014), Kdbus y Binder han abandonado la twig de etapas del kernel de Linux. No hay garantía en este punto de que lo haga, pero la perspectiva es algo positiva para ambos. Binder es un mecanismo liviano de IPC en Android, Kdbus es un mecanismo de IPC tipo dbus en el núcleo que reduce el cambio de contexto, lo que acelera enormemente la mensajería.

También existe la “Comunicación entre procesos transparente” o TIPC, que es robusta, útil para la creación de clústeres y la creación de múltiples nodos; http://tipc.sourceforge.net/