Qui Linux CIB est la technique à utiliser?

Question

Nous sommes encore dans la conception de la phase de notre projet, mais nous pensons avoir trois processus distincts sur un Linux embarqué noyau. L'un des processus avec un module de communication qui gère toutes les communications vers et depuis l'appareil par le biais de différents médiums.

Les deux autres processus doivent être en mesure d'envoyer/recevoir des messages à travers le processus de communication. Je suis en train d'évaluer la CIB techniques que Linux offre; le message aux autres processus sera d'envoi varient en taille, de journaux de débogage du contenu multimédia en continu à ~5 Mbit taux. Aussi, les médias pourraient être de streaming dans et à l'extérieur simultanément.

Qui CIB technique auriez-vous des suggestions pour cette application? http://en.wikipedia.org/wiki/Inter-process_communication

Processeur tourne autour de 400 à 500 Mhz si cela change quoi que ce soit. N'a pas besoin d'être multi-plateforme, Linux est très bien. Mise en œuvre en C ou C++ est nécessaire.

Merci pour toutes les suggestions.

Answer 1

Lors de la sélection de votre CIB, vous devriez envisager les causes des écarts de rendement, y compris le transfert des tailles de mémoire tampon, les données des mécanismes de transfert, de la mémoire, les systèmes de répartition, mécanisme de verrouillage implémentations, et même de la complexité du code.

Des mécanismes IPC, le choix de la performance vient souvent vers le bas pour les sockets de domaine Unix ou des canaux nommés (Fifo). J'ai lu un papier sur l'Analyse des Performances des Différents Mécanismes de Communication Inter-processus qui indique les sockets de domaine Unix pour l'IPC peut fournir les meilleures performances. J'ai vu des résultats contradictoires ailleurs qui indiquent des tuyaux peut-être mieux.

Lors de l'envoi de petites quantités de données, je préfère les tubes nommés (Fifo) pour leur simplicité. Cela nécessite une paire de canaux nommés pour la communication bi-directionnelle. Les sockets de domaine Unix prendre un peu plus de surcharge de l'installation (création de la socket, d'initialisation et de connexion), mais sont plus souples et peuvent offrir de meilleures performances (débit élevé).

Vous devrez peut-être exécuter certains tests pour votre application spécifique/environnement, afin de déterminer ce qui fonctionnera le mieux pour vous. À partir de la description fournie, il semble que les sockets de domaine Unix peut être le meilleur ajustement.

---

Beej Guide d'Unix à l'IPC est bon pour le démarrage de Linux/Unix de la CIB.

Answer 2

Je pencherais pour les Sockets de Domaine Unix: moins de frais généraux que les sockets IP (c'est à dire pas d'inter-machine comms) mais même confort autrement.

Answer 3

Ne peux pas croire que personne n'a mentionné dbus.

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

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

Peut-être un peu plus haut si votre application est une architecture simple, dans ce cas - dans des conditions contrôlées en environnement embarqué où la performance est cruciale: vous ne pouvez pas battre la mémoire partagée.

Answer 4

Si la performance devient vraiment un problème, vous pouvez utiliser la mémoire partagée - mais c'est beaucoup plus compliqué que les autres méthodes, vous aurez besoin d'un mécanisme de signalisation pour signaler que les données sont prêtes (sémaphore, etc) ainsi que les verrous pour empêcher l'accès simultané à des structures alors qu'ils sont en cours de modification.

L'avantage est que vous pouvez transférer beaucoup de données sans avoir à le copier dans la mémoire, ce qui va certainement améliorer les performances dans certains cas.

Il existe peut-être utilisable bibliothèques qui fournissent des primitives de plus haut niveau via la mémoire partagée.

La mémoire partagée est généralement obtenu par mmaping le même fichier à l'aide MAP_SHARED (qui peut être sur un système de fichier temporaire si vous ne voulez pas qu'elle persiste); beaucoup d'applications utilisent la mémoire partagée System V (à mon humble avis pour de stupides raisons historiques; elle est beaucoup moins belle interface pour la même chose)

Answer 5

Pour un examen de la "classique" Linux mécanismes IPC: voir ici.