¿Qué técnica de Linux IPC utilizar?
(5)
A partir de este escrito (noviembre de 2014), Kdbus y Binder han abandonado la rama de ensayo del kernel de Linux. No hay garantías en este punto de que ninguno de los dos lo logre, pero la perspectiva es algo positiva para ambos. Binder es un mecanismo de IPC ligero en Android, Kdbus es un mecanismo de IPC tipo dbus en el kernel que reduce el cambio de contexto, lo que acelera enormemente la mensajería.
También existe la "Comunicación transparente entre procesos" o TIPC, que es robusta, útil para agrupación y configuraciones de múltiples nodos; http://tipc.sourceforge.net/
Todavía estamos en la fase de diseño de nuestro proyecto, pero estamos pensando en tener tres procesos separados en un kernel de Linux incorporado. Uno de los procesos con ser 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 deberá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 sugerirías para esta aplicación? http://en.wikipedia.org/wiki/Inter-process_communication
El procesador está ejecutando alrededor de 400-500 Mhz si eso cambia algo. No necesita ser multiplataforma, solo Linux está bien. Se requiere implementación en C o C ++.
Al seleccionar su IPC, debe considerar las causas de las diferencias de rendimiento, incluidos los tamaños del búfer de transferencia, los mecanismos de transferencia de datos, los esquemas de asignación de memoria, las implementaciones de mecanismos de bloqueo e incluso la complejidad del código.
De los mecanismos de IPC disponibles, la elección de rendimiento a menudo se reduce a los sockets de dominio Unix o tuberías con nombre (FIFO) . Leí un artículo sobre Análisis de rendimiento de varios mecanismos para la comunicación entre procesos que indica que los sockets de dominio Unix para IPC pueden proporcionar el mejor rendimiento. He visto resultados contradictorios en elsewhere que indican que las tuberías pueden ser mejores.
Al enviar pequeñas cantidades de datos, prefiero canalizaciones con nombre (FIFO) por su simplicidad. Esto requiere un par de tuberías con nombre para la comunicación bidireccional. Los sockets de dominio Unix son un poco más costosos de configurar (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 deba ejecutar algunos puntos de referencia para su aplicación / entorno específico para determinar qué funcionará mejor para usted. De la descripción provista, parece que los sockets de dominio Unix pueden ser el mejor ajuste.
La Guía de Beej para Unix IPC es buena para comenzar con Linux / Unix IPC.
Iría por Unix Domain Sockets: menos sobrecarga que los sockets IP (es decir, sin comunicaciones entre máquinas), pero la misma conveniencia de lo contrario.
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 controlado e integrado 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.), así como bloqueos para evitar el acceso simultáneo a las estructuras. mientras están siendo modificados.
La ventaja 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.
Tal vez hay bibliotecas utilizables que proporcionan primitivas de nivel superior a través de la memoria compartida.
La memoria compartida generalmente se obtiene mediante la creación de un mapa de mm del mismo archivo utilizando MAP_SHARED (que puede estar en un tmpfs si no desea que persista); muchas aplicaciones también usan la memoria compartida de System V (IMHO por razones históricas estúpidas; es una interfaz mucho menos agradable para la misma cosa)