Welche Linux IPC-Technik soll verwendet werden?

73

Wir befinden uns noch in der Entwurfsphase unseres Projekts, denken jedoch an drei separate Prozesse auf einem eingebetteten Linux-Kernel. Einer der Prozesse ist ein Kommunikationsmodul, das die gesamte Kommunikation zum und vom Gerät über verschiedene Medien abwickelt.

Die beiden anderen Prozesse müssen in der Lage sein, Nachrichten über den Kommunikationsprozess zu senden / empfangen. Ich versuche, die von Linux bereitgestellten IPC-Techniken zu bewerten. Die Nachricht, die die anderen Prozesse senden, ist unterschiedlich groß, von Debug-Protokollen bis hin zu Streaming-Medien mit einer Rate von ~ 5 Mbit. Außerdem können die Medien gleichzeitig ein- und ausgehen.

Welche IPC-Technik würden Sie für diese Anwendung vorschlagen? http://en.wikipedia.org/wiki/Inter-process_communication

Der Prozessor läuft zwischen 400 und 500 MHz, wenn sich dadurch etwas ändert. Muss nicht plattformübergreifend sein, nur Linux ist in Ordnung. Die Implementierung in C oder C ++ ist erforderlich.

RishiD
quelle
36
Der Linux-Kernel bietet die folgenden IPC-Mechanismen: Signale, anonyme Pipes, Named Pipes oder FIFOs, SysV-Nachrichtenwarteschlangen, POSIX-Nachrichtenwarteschlangen, gemeinsam genutzter SysV-Speicher, gemeinsam genutzter POSIX-Speicher, SysV-Semaphoren, POSIX-Semaphoren, FUTEX-Sperren, dateibasierte und anonymisierte gemeinsam genutzte Speicher mit mmap, UNIX-Domänen-Sockets, Netlink-Sockets, Netzwerk-Sockets, Inotify-Mechanismen, FUSE-Subsystem, D-Bus-Subsystem. Für die meisten meiner Bedürfnisse benutze ich Steckdosen.
Enthusiastgeek
2
@enthusiasticgeek D-Bus wird vollständig im Benutzerbereich ausgeführt. Einige Kernel-Leute arbeiten an kdbus, aber es ist noch in Arbeit.
new123456
Auf einem arm926ejs 200-MHz-Prozessor verbraucht ein Methodenaufruf und eine Antwort mit zwei uint32-Argumenten zwischen 0 und 15 ms. durchschnittlich 6 ms. Wie sehen andere Leute auf anderen Prozessoren?
Minghua
1
Mögliches Duplikat des Vergleichs von Unix / Linux-IPC Dieser ist möglicherweise zu breit und neigt dazu, zu diesem zu degenerieren.
Ciro Santilli 3 冠状 病 六四 事件 3
Eine Übersicht über "klassische" Linux-IPC-Mechanismen finden Sie hier
Reblochon Masque

Antworten:

33

Ich würde mich für Unix Domain Sockets entscheiden: weniger Overhead als IP-Sockets (dh keine Kommunikation zwischen Maschinen), aber ansonsten der gleiche Komfort.

jldupont
quelle
Ich probiere das aus, aber ich bekomme gemischte Ergebnisse. Wenn einige Prozesse versuchen, mit meinem IPC-Server (Unix-Socket-Server) zu kommunizieren, muss ich dann Multiplexing durchführen?
User9102d82
@ User9102d82: Ja, verwenden Sie die select()(oder poll()) Funktionen, um dies zu erreichen. Diese können mehrere Dateideskriptoren (z. B. Ihre Client-Sockets) überwachen und blockieren, bis Daten zum Lesen verfügbar sind. Eine gute Übersicht finden Sie unter notes.shichao.io/unp/ch6 .
Sigma
66

Bei der Auswahl Ihres IPC sollten Sie Ursachen für Leistungsunterschiede berücksichtigen, einschließlich Übertragungspuffergrößen, Datenübertragungsmechanismen, Speicherzuweisungsschemata, Implementierungen von Sperrmechanismen und sogar Codekomplexität.

Von den verfügbaren IPC-Mechanismen hängt die Wahl der Leistung häufig von Unix-Domain-Sockets oder Named Pipes (FIFOs) ab . Ich habe einen Artikel über die Leistungsanalyse verschiedener Mechanismen für die Kommunikation zwischen Prozessen gelesen , in dem angegeben wird, dass Unix-Domain-Sockets für IPC möglicherweise die beste Leistung bieten. Ich habe an anderer Stelle widersprüchliche Ergebnisse gesehen , die darauf hinweisen, dass Rohre möglicherweise besser sind.

Beim Senden kleiner Datenmengen bevorzuge ich aufgrund ihrer Einfachheit Named Pipes (FIFOs). Dies erfordert ein Paar benannter Pipes für die bidirektionale Kommunikation. Unix-Domain-Sockets benötigen etwas mehr Aufwand für die Einrichtung (Socket-Erstellung, Initialisierung und Verbindung), sind jedoch flexibler und bieten möglicherweise eine bessere Leistung (höherer Durchsatz).

Möglicherweise müssen Sie einige Benchmarks für Ihre spezifische Anwendung / Umgebung ausführen, um festzustellen, welche für Sie am besten geeignet sind. Aus der bereitgestellten Beschreibung geht hervor, dass Unix-Domain-Sockets möglicherweise am besten passen.


Beejs Handbuch zu Unix IPC ist gut für den Einstieg in Linux / Unix IPC.

jschmier
quelle
20

Ich kann nicht glauben, dass niemand dbus erwähnt hat.

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

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

Wenn Ihre Anwendung architektonisch einfach ist, ist dies möglicherweise etwas übertrieben. In diesem Fall können Sie in einer kontrollierten eingebetteten Umgebung, in der die Leistung von entscheidender Bedeutung ist, den gemeinsam genutzten Speicher nicht übertreffen.

Ölmessstab
quelle
4
Dbus hat Leistungsprobleme in einer eingebetteten Umgebung. Es entsteht viel Kontextwechsel, da Sie eine Nachricht über dbus erstellen, an den Kernel senden und dann wieder an dbus senden. Es gibt einen Patch, der diese Kontextwechsel mithilfe eines neuen Socket-Typs namens AF_BUS reduziert, aber Red Hat hat den Patch aus irgendeinem Grund nicht angewendet.
Jeremiah
4
Dieses Design vieler Kontextwechsel weist auf das ursprüngliche Ziel von dbus hin, ein Service Discovery Bus und kein IPC-Mechanismus zu sein.
Jeremiah
@jeremiah: Gibt es Einzelheiten zu den Leistungsproblemen in einer eingebetteten Umgebung ? Ich habe einige Profilerstellung und Online-Recherchen durchgeführt und sehe kein ernstes Problem. Siehe hier
Minghua
Es hängt natürlich davon ab, welche Art von Leistung Sie suchen. Dinge wie bluez, die dbus verwenden, drücken anscheinend viele Objekte in die Pipe, wenn sie beispielsweise Audio indizieren. Dies kann viel Verkehr erzeugen und Sie werden wahrscheinlich einen Leistungseinbruch sehen. Als IPC-Mechanismus wird es langsam, zumindest im Vergleich zu anderen POSIX IPC-Mechanismen, die speziell für Embedded entwickelt wurden. kdbus versucht, einige dieser Leistungsprobleme zu lösen, aber es ist immer noch ein neues Projekt.
Jeremiah
12

Wenn die Leistung wirklich zu einem Problem wird, können Sie gemeinsam genutzten Speicher verwenden - dies ist jedoch viel komplizierter als die anderen Methoden. Sie benötigen einen Signalisierungsmechanismus, um zu signalisieren, dass Daten bereit sind (Semaphor usw.), sowie Sperren, um den gleichzeitigen Zugriff auf Strukturen zu verhindern während sie geändert werden.

Der Vorteil ist, dass Sie viele Daten übertragen können, ohne sie in den Speicher kopieren zu müssen, was in einigen Fällen die Leistung definitiv verbessert.

Möglicherweise gibt es verwendbare Bibliotheken, die über den gemeinsamen Speicher übergeordnete Grundelemente bereitstellen.

Der gemeinsam genutzte Speicher wird im Allgemeinen durch mmaping derselben Datei mit MAP_SHARED (die sich auf einem tmpfs befinden kann, wenn Sie nicht möchten, dass sie beibehalten wird) erhalten. Viele Apps verwenden auch gemeinsam genutzten System V-Speicher (IMHO aus dummen historischen Gründen; es ist eine viel weniger schöne Schnittstelle zu derselben Sache).

MarkR
quelle
Wird die Verwendung einer Datei für IPC für mmap die Daten in einen dauerhaften Speicher schreiben?
Abhiarora
Nicht, wenn sich die Datei in einem tmpfs-In-Memory-Dateisystem befindet. Dies wird normalerweise für solche Zwecke verwendet.
MarkR
4

Zum Zeitpunkt dieses Schreibens (November 2014) haben Kdbus und Binder den Staging-Zweig des Linux-Kernels verlassen. Derzeit gibt es keine Garantie dafür, dass einer von beiden es schafft, aber die Aussichten sind für beide etwas positiv. Binder ist ein leichter IPC-Mechanismus in Android, Kdbus ist ein dbus-ähnlicher IPC-Mechanismus im Kernel, der den Kontextwechsel reduziert und so das Messaging erheblich beschleunigt.

Es gibt auch "Transparent Inter-Process Communication" oder TIPC, das robust ist, sich für Clustering und die Einrichtung mehrerer Knoten eignet. http://tipc.sourceforge.net/

jeremiah
quelle
0

Unix-Domain-Sockets erfüllen die meisten Ihrer IPC-Anforderungen. In diesem Fall benötigen Sie keinen dedizierten Kommunikationsprozess, da der Kernel diese IPC-Funktion bereitstellt. Schauen Sie sich auch die POSIX-Nachrichtenwarteschlangen an, die meiner Meinung nach eine der am wenigsten genutzten IPC unter Linux sind, aber in vielen Fällen sehr nützlich sind, in denen n: 1-Kommunikation erforderlich ist.

c0der
quelle
Meinten Sie mit 'n: 1' n Prozesse, die mit einem einzelnen Prozess sprechen? bitte bestätigen.
User9102d82