C++ IPC: Funtion durch IPC in getrenntes Programm legen.

[T_55]

Hallo,

ich hab ein paar Fragen zu IPC womit ich mich nicht auskenne aber was ich gerne mal ausprobieren würde.
Nehmen wir an es gibt zwei seperate Programme von denen das erste beim zweiten zB das Ausführen einer Funktion triggern soll und ein Zeiger übergibt. Vom Ablauf eigentlich so:
- Programm A und B werden geöffnet.
- Programm A kommt an eine Position wo es eine Funktion in Programm B triggern soll und dort wartet bis B fertig ist. Im Prinzip soll B wie eine Funktion funktionieren die von A aufgerufen wird. A sollte B auch ein Zeiger übergeben.
- Programm B führt durch den Trigger von A etwas aus und danach geht es in A wieder weiter.
Die Programme wechseln sich so ab dadurch müsste es auch keine Konflikt bezüglich Zugriff auf Daten des Zeigers geben.
Falls das mit dem Zugriff von B auf Daten von A nicht geht wäre auch ein gemeinsamer Speicherbereich ok wo dann die Daten liegen.

Soweit die gänzlich theoretische Idee Wäre das denn prinzipiell möglich?

Ich habe gelesen, dass shared memory die schnellste Form der IPC ist. Gut wäre auch direkt eine IPC zu nutzen, die für Windows und Linux funktioniert, wäre das bei shared memory der Fall?

Grüße

 

[ph4nt0m]

Eine direkte IPC über shared memory ist nur möglich, wenn deine beiden Prozesse auf demselben Rechner laufen (dann kannst du dir z.B. Boost.Interprocess anschauen). Falls es sich um zwei unabhängige Geräte handelt, muss der Mechanismus z.B. über Netzwerkprokolle gekapselt bzw. simuliert werden (das ist dann keine IPC im eigentlichen Sinne mehr, siehe dafür z.B. Boost.Asio).

Was jedoch in keinem Fall möglich ist, ist einen "nackten" Zeiger zu übergeben. Ein solcher hat immer nur Gültigkeit innerhalb des jeweiligen Prozesses und ein anderer Prozess kann damit nichts anfangen.

Das Aufrufen von entfernten Funktionen ist dann ein Spezialthema für sich und läuft unter dem Begriff RPC (Remote Procedure Call).

 

[T_55]

Danke, ja die Programme laufen auf dem selben Rechner. Was den nackten Zeiger angeht, heißt das dann es muss immer ein gemeinsamer Speicherbereich definiert werden sobald beide Programme auf das gleiche zugreifen möchten?
Das Boost schaue ich mir mal an ansonsten habe ich noch gelesen, dass IPC per Pipes auch cross plattformfähig sind.

Ergänzung (29. Oktober 2016)

und QT scheint auch was zu dem Thema zu haben: https://doc.qt.io/qt-5/ipc.html

 

[ph4nt0m]

Wenn du Daten auf ähnliche Weise lesen und modifizieren willst, wie man es in einem gewöhlichen Programm tut, wäre ein gemeinsamer Speicherbereich (shared memory) wohl das Beste.

Die anderen Ansätze (Pipes und Sockets) fallen unter die nachrichtenbasierte Kommunikation, d.h. du müsstest dich entscheiden, welcher Prozess die Daten verwaltet, und dann die Datenübertragung an den anderen Prozess sowie das Modifizieren der Daten durch den anderen Prozess mithilfe von Nachrichten regeln.

 

[kuddlmuddl]

Bist du sicher, dass du IPC brauchst/willst?
Funktionen extern erledigen lassen geht auch super mit einer Lib die zB mit einem eigenen internen Thread parallel zu deinem Hauptprogramm arbeitet und dir mitteilt, wenn sie fertig ist.
Dann geht nämlich auch einfaches übergeben von Daten bzw Aufgaben in Form von Pointern.

Shared Memory sieht bei Qt aber auch sehr einfach aus.

 

[T_55]

Ja stimmt per dll ist es praktischer aber ich wollte es bewusst mal ausprobieren das zwei wirklich unabhängige Programme effektiv vernetzt werden.
Shared Memory kommt mir etwas so vor wie eine Datenbank nur auf dem RAM. Was ich mich frage, kann das eine Programm das andere direkt triggern oder muss dies immer indirekt geschehen, also per Schleife die alle x Millisekunden ein Wert prüft? Weil dann wäre es wieder nicht so effektiv und hätte so ein bisschen den Datenbankstyle.

 

[Nai]

Rein Implementierungstechnisch gibt es auch Bibliotheken, die eine IPC mit Nachrichten ermöglichen, womit du im prinzip dein "Triggern" hast (MPI zum Beispiel). Ob das ganze allerdings software und hardwaretechnisch letztendlich auf Interrupts, Signale oder auf Polling abgebildet wird, ist wieder ein anderes Bier; spielt aber für die Programmierung idr keine Rolle.

 

[T_55]

Beides wäre eigentlich gut, ein gemeinsamer Speicherbereich wo Programm A etwas reinschreibt und dann oder dabei ein Trigger um Programm B zu sagen jetzt tue etwas damit. Das ganze Performancemäßig möglichst gut, wie wenn es alles in einem Programm wäre.

Was shared memory angeht denke ich boost und qt sind gute Einstiege. MPI gibts auch bei Boost habe ich gesehen insofern ist vielleicht gut entweder alles mit Boost (Boost.MPI und Boost.Interprocess) zu machen oder alles mit QT wenn es sowas wie MPI beherrscht. Es gibt ja Stimmen die sagen Boost wäre langfristig stabiler als QT wo man die Framework Abhängigkeit hat.

 

[Limit]

Eine Frage, die meiner Meinung nach entscheidend ist, hat hier noch niemand gestellt, nämlich warum du das überhaupt machen willst. Du sprichst von unabhängigen Programmen, willst das ganze aber über shared memory realisieren. Das ist ein Widerspruch in sich.

Sollte es dir darum gehen etwas über verteilte Systeme zu lernen, würde ich erst gar nicht mit shared memory anfangen. Verteilte Systeme benutzt man aus verschiedenen Gründen, z.B. wegen Flexibilität, Fehlertolleranz oder einfach Skalierbarkeit. Ein auf shared-memory basierendes System kann das allerdings höchstens im Ansatz liefern, sofern man nicht aufwendige Middleware einsetzt (distributed shared memory), die dann allerdings die Komplexität stark erhöht und sich negativ auf die Performance auswirkt.

Du solltest dir vielleicht mal ein paar Messaging Bibliotheken anschauen, z.B. ZeroMQ oder eine AMQP Implementierung.