Verwendung von ZMQ für bidirektionale Inter-Thread-Kommunikation

Question

Ich bin neu bei ZeroMQ. Ich habe die letzten Monate damit verbracht, die Dokumentation zu lesen und mit der Bibliothek zu experimentieren. Ich entwickle gerade eine multi-threaded C++ - Anwendung und möchte ZeroMQ anstelle von Mutex verwenden, um Daten zwischen meinem Hauptthread und einem seiner untergeordneten Knoten auszutauschen.

Der untergeordnete Thread verarbeitet die Kommunikation mit einer externen Anwendung. Daher muss ich/Sockets zwischen dem Hauptthread und seinem Kind einreihen. Eine für ausgehende Nachrichten und eine für eingehende Nachrichten.

Welche zmq-Buchse sollte ich verwenden, um dies zu erreichen.

Vielen Dank im Voraus

Answer 1

Durch Verwendung von Shared Memory und mutexes bewegen zu verwenden ZeroMQ, betreten Sie das Reich der Schauspieler Modellprogrammierung.

Dies ist meiner Meinung nach eine ziemlich gute Sache. Es gibt jedoch einige Dinge zu beachten.

1. Der einzige Grund, warum Mutexe nicht mehr benötigt werden, ist, dass Sie Daten kopieren und nicht teilen. Die "Kosten" bestehen darin, dass das Kopieren vieler Daten viel länger dauert als das Sperren eines Mutex, der auf gemeinsam genutzte Daten verweist. So können Sie mit einem gut aussehenden Actor-Modell-Programm enden, das wie ein Hund im Vergleich zu einem äquivalenten Programm läuft, das Shared Memory/Mutexe verwendet.
2. Ein Nachteil ist, dass auf komplizierten Architekturen wie Intel Xeons mit mehreren CPUs der Zugriff auf gemeinsam genutzte Speicher denkbar ist, dauert genauso lange wie das Kopieren. Dies liegt daran, dass dies (abhängig von Ihrem Glück) bedeuten kann, Transaktionen über den QPI-Bus zu tätigen. Die Programmierung von Actor-Modellen ist ideal für NUMA-Hardwarearchitekturen. Moderne Intel- und AMD-Architekturen sind teilweise/grundlegend NUMA, aber die Protokolle, die sie über QPI/Hypertransport ausführen, "fälschen" eine SMP-Umgebung.
3. Ich würde ZMQ_PAIR Sockets vermeiden, wo immer praktikabel. Sie funktionieren nicht über Netzwerkverbindungen hinweg. Wenn Ihre Anwendung aus irgendeinem Grund über mehrere Computer hinweg skaliert werden muss, müssen Sie Ihren Code neu schreiben. Wenn Sie jedoch von Anfang an unterschiedliche Socket-Typen verwenden, ist eine Erweiterung Ihrer Anwendung nichts anderes als eine Neuverteilung des Codes, ohne ihn zu ändern. FYI Nanomsg PAIRs haben diese Einschränkung nicht.
4. Nicht für einen Moment davon ausgehen, dass Actor-Modell-Programmierung wird alle Ihre Probleme zu lösen. Es bringt eine ganze Reihe von Problemen mit sich. Sie können immer noch Deadlock, Livelock, Spinlock, etc. Das Problem mit Actor-Modell-Programmen ist, dass diese Probleme in Ihrem Code seit Jahren lauern können und nie passieren, bis eines Tages das Netzwerk nur ein bisschen belebter und -bam- Ihr Programm ist hört auf zu laufen ...
5. Allerdings gibt es eine Entwicklung der Actor-Modell-Programmierung namens "Sequentielle Prozesse kommunizieren". Dies löst diese Probleme nicht, aber wenn Sie Ihr Programm mit diesen Problemen geschrieben haben, werden sie garantiert jedes Mal passieren. So entdecken Sie das Problem während der Entwicklung und Tests, nicht fünf Jahre später. Es gibt auch einen Prozess Kalküle für sie, d. H. Sie können algebraisch beweisen, dass Ihr Design problemfrei ist, bevor Sie jemals eine einzige Zeile Code schreiben. ZeroMQ ist kein CSP. Interessanterweise macht CSP ein Comeback - die Rust and Go-Sprachen machen CSP. Sie führen CSP jedoch nicht über Netzwerkverbindungen hinweg aus - es handelt sich um alles, was gerade bearbeitet wird. Erlang macht auch CSP, und AFAIK tut es über Netzwerkverbindungen.
6. Angenommen, Sie haben alles über CSP gelesen und werden weiterhin ZeroMQ verwenden, denken Sie sorgfältig darüber nach, was Sie planen, über die ZeroMQ-Sockets zu senden. Wenn alles in einem Programm auf demselben Rechner läuft, ist das Senden von Kopien von z. B. Ganzzahlenarrays in Ordnung. Sie werden immer noch als Ganzzahlen auf der Empfängerseite interpretierbar sein.Wenn Sie jedoch beabsichtigen, Daten über ZMQ-Sockets an einen anderen Computer zu senden, sollten Sie eine Art von Serialisierungstechnologie in Betracht ziehen. ZeroMQ liefert Nachrichten. Warum machen Sie diese Nachrichten nicht zum Byte-Stream eines Objekt-Serialisierers? Dann können Sie garantieren, dass die empfangene Nachricht nach der Serialisierung auf der Empfängerseite etwas Sinnvolles bedeutet, anstatt Probleme mit der Endlichkeit usw. lösen zu müssen.
7. Zu den bevorzugten Serialisierern für mich gehören Google Protocol Buffers. Es ist sprach-/betriebssystemunabhängig und bietet viele Optionen für ein heterogenes System. ASN.1 ist eine weitere wirklich gute Option, die für die meisten wichtigen Sprachen erhältlich ist, und es verfügt über eine Vielzahl von Drahtformaten (einschließlich XML und, jetzt/bald, JSON, die interessante Interop-Optionen bietet), und tut Constraints (etwas, was Google PBufs nicht tun), aber kostet Geld, wenn man wirklich gute Werkzeuge dafür will. XML kann fast alles verstehen, ist aber aufgebläht. Grundsätzlich lohnt es sich, eine auszuwählen, die Sie nicht dazu bringt, überall C# oder Python zu verwenden.

Viel Glück!