Die Funktionen msgctl() , msgget() , msgrcv() , und msgsnd() sind die Nachrichtenwarteschlangenfunktionen von 'System V IPC'. Sie werden für Sie arbeiten, aber sie sind ziemlich schwer. Sie werden von POSIX standardisiert.
POSIX bietet auch einen moderneren Satz von Funktionen, mq_close() , mq_getattr() , mq_notify() , mq_open() , mq_receive() , mq_send() , mq_setattr() , und mq_unlink() was besser für Sie sein könnte (so eine Verlegenheit des Reichtums).
Sie müssen jedoch überprüfen, welches, falls vorhanden, standardmäßig auf Ihren Zielplattformen installiert ist. Besonders in einem eingebetteten System kann es sein, dass Sie sie konfigurieren oder sogar installieren müssen, weil sie standardmäßig nicht vorhanden sind (und dasselbe gilt möglicherweise für Shared Memory und Semaphore).
Der Hauptvorteil beider Nachrichtenfunktionen besteht darin, dass sie (wahrscheinlich) vorab debuggt sind und daher Parallelitätsprobleme bereits gelöst sind. Wenn Sie es jedoch mit Shared Memory und Semaphoren selbst tun, haben Sie eine Menge Arbeitsaufwand, um das gleiche Funktionsniveau zu erreichen.
Also, (wieder)verwenden, wenn du kannst. Wenn es eine Option ist, verwenden Sie eines der beiden Nachrichtenwarteschlangensysteme, anstatt Ihr eigenes neu zu erfinden. Wenn Sie schließlich feststellen, dass es einen Leistungsengpass oder etwas Ähnliches gibt, können Sie versuchen, Ihre eigenen Alternativen zu schreiben, aber bis dahin – wiederverwenden!
System-V-Nachrichtenwarteschlangen (die von den msg*-Systemaufrufen manipuliert werden) haben viele seltsame Macken und Fallstricke. Für neuen Code empfehle ich dringend die Verwendung von UNIX-Domain-Sockets.
Abgesehen davon würde ich auch dringend empfehlen, IPC über Shared-Memory-Schemata zu übermitteln. Gemeinsam genutzter Speicher ist viel leichter fehleranfällig und neigt dazu, viel katastrophaler schief zu gehen.
Message Passing eignet sich hervorragend für kleine Datenblöcke und dort, wo Unveränderlichkeit aufrechterhalten werden muss, da Nachrichtenwarteschlangen Daten kopieren.
Ein Shared-Memory-Bereich kopiert keine Daten beim Senden/Empfangen und kann für größere Datenmengen auf Kosten eines weniger sauberen Programmiermodells effizienter sein.