Multithreading oder Multiprocessing

Beide können auf ihre Art kompliziert und komplex sein.

Sie können beides tun. In dem großen Schema der Dinge mag es egal sein, wen du wählst. Was zählt ist, wie gut Sie sie tun. Deshalb:

Mach, was du am meisten erlebt hast. Oder wenn Sie ein Team leiten, tun Sie, was das Team am meisten erlebt hat.

--- Threading! ---

Ich habe eine Menge von Thread-Programmierung gemacht, und ich genieße Teile davon, und Teile davon genieße ich nicht. Ich habe viel gelernt und kann jetzt eine Multithread-Anwendung ohne allzu große Schmerzen schreiben, aber es muss auf eine sehr spezifische Art und Weise geschrieben werden. Nämlich:

1) Es muss mit sehr klar definierten Datengrenzen geschrieben werden, die 100% threadsicher sind. Ansonsten, was auch immer passieren mag, wird passieren, und es ist vielleicht nicht, wenn Sie einen Debugger herumliegen haben. Das Debuggen von threaded Code ist wie in Schrodingers Box zu schauen ... Wenn Sie hineinschauen, haben andere Threads vielleicht oder auch nicht hatte Zeit, mehr zu verarbeiten.

2) Es muss mit Testcode geschrieben werden, der die Maschine belastet. Viele Multi-Threaded-Systeme zeigen nur ihre Fehler, wenn die Maschinen stark beansprucht werden.

3) Es muss eine sehr schlaue Person geben, die den Datenaustausch-Code besitzt. Wenn es einen Weg für eine Verknüpfung gibt, wird wahrscheinlich ein Entwickler es schaffen, und Sie werden einen fehlerhaften Bug haben.

4) Es muss alle Situationen geben, die die Anwendung mit minimalem Aufwand zurücksetzen. Dies ist für den Produktionscode, der wegen eines Threading-Problems unterbrochen wird. Kurz gesagt: Die Show muss weitergehen.

--- Cross-Process! ---

Ich habe weniger Erfahrung mit prozessorientiertem Threading, habe aber kürzlich einige prozessübergreifende Sachen in Windows gemacht (wo der IPC Webservice-Aufrufe ... WOO!), und es ist relativ sauber und einfach, aber ich Befolgen Sie auch hier einige Regeln. Im Großen und Ganzen wird Interprozesskommunikation viel fehlerfreier sein, da Programme sehr gut von der Außenwelt empfangen werden. Diese Transportmechanismen sind normalerweise asynchron. Wie auch immer ...

1) Definieren Sie klare Prozessgrenzen und Kommunikationsmechanismen. Message / Evening über, sagen wir, TCP oder Web-Services oder Pipes oder was auch immer, ist in Ordnung, solange die Grenzen klar sind, und es gibt eine Menge Validierung und Fehlerprüfung Code an diesen Grenzen.

2) Seien Sie auf Engpässe vorbereitet. Code-Vergebung ist sehr wichtig. Damit meinst du, manchmal wirst du nicht in der Lage sein, in diese Pfeife zu schreiben. Sie müssen diese Nachrichten erneut anfordern und wiederholen können, ohne dass die Anwendung eine Ausnahme blockiert / auswirft.

3) Im Allgemeinen wird es viel mehr Code geben, da der Transport von Daten über Prozessgrenzen hinweg bedeutet, dass Sie sie auf irgendeine Weise serialisieren müssen. Dies kann zu Problemen führen, insbesondere wenn Sie mit der Pflege und Änderung dieses Codes beginnen.

Hoffe, das hilft.

Hängt davon ab, welche Programmiersprache Sie verwenden möchten (und welche Bibliotheken). Persönlich würde ich Multithreading wählen, da ich die mit Threads verbundenen Probleme kenne (und wie man sie löst).

Multiprocessing kann Ihnen helfen, wenn Sie den Daemon auf mehreren Rechnern ausführen und die Last unter ihnen verteilen wollen, aber ich denke nicht, dass dies ein großes Problem ist.

Sie haben zu viele Details weggelassen. In Bezug auf das, was Sie bereits gesagt haben, ist die Wahl irrelevant und es gibt nichts, was mehr an Multithreading als an Multiprocessing liegt. Sie vermissen, warum diese Techniken solch einen Ruf haben. Wenn Sie keine Daten teilen, gibt es nicht viele Probleme (natürlich können andere Probleme auftreten, aber wir brauchen Details, um darüber zu entscheiden). Es spielt auch eine Rolle, auf welcher Plattform, auf UNIX-ähnlichen Betriebssystemen, die Prozesse sowieso ziemlich leicht sind.

Es gibt jedoch noch andere Punkte, die zu beachten sind? Auf welche Art von System (e) wirst du laufen? Sie möchten auf keinen Fall mehrere Prozesse auf einem Einprozessorsystem hervorbringen, da Sie abhängig von einigen anderen Details, die Sie angeben könnten, nicht viel Nutzen ziehen werden. Wenn Sie die Art des Problems beschreiben, das Sie zu lösen versuchen, können wir Ihnen weiterhelfen.

Wenn Sie Robustheit wünschen, verwenden Sie Multi-Processing.

Die Prozesse teilen die Protokollierungslast zwischen ihnen. Früher oder später wird eine Logging-Anfrage einen Fehler verursachen und den Logger zum Absturz bringen. Bei Multi-Processing verlieren Sie nur einen Prozess und damit nur die eine Logging-Anfrage (die Sie wegen des Fehlers sowieso nicht hätten bearbeiten können).

Multi-Threading ist anfällig für Abstürze, da ein einziger schwerwiegender Fehler den einzelnen Prozess ausschließt.

Mulit-Processing ist in gewisser Weise technisch anspruchsvoller, da Sie die Arbeitslast über Prozesse verteilen müssen, die die Verwendung von gemeinsam genutztem Speicher erfordern.

Müssen Sie Aktualisierungsdaten zwischen den Instanzen teilen, wo die Updates häufig sind und IPC zu teuer wäre? In diesem Fall ist Multithreading wahrscheinlich besser. Ansonsten müssen Sie abwägen, ob Ihnen die Robustheit einzelner Prozesse oder die Einfachheit der Thread-Erstellung / Kommunikation wichtiger ist.

Eine Frage ist, ob es notwendig ist, beides zu tun. Ich kenne die Details Ihrer Anforderungen nicht, aber eine Single-Thread-App, die select(2) verwendet, kann Ihren Anforderungen entsprechen und hat nicht die Nachteile von Prozessen oder Threads. Dies erfordert, dass Sie alle Ihre E / A an einem zentralen Ort zentralisieren können, höchstwahrscheinlich über Callbacks zu anderen Modulen, aber das ist nicht so schwer, es sei denn, Sie haben viele Bibliotheken, die ihr eigenes I machen wollen / O und kann nicht auf diese Weise umstrukturiert werden.

Vielen Dank für Ihr Feedback.

Ich habe mich für eine Multi-Prozess-Architektur entschieden, ähnlich wie der Apache-Webserver. Die Prozesse werden auf Multi-Prozessor / Core-Systemen gut skalieren. Kommunikation wird mit Rohren oder Steckdosen durchgeführt.

Prozesse können in einem Prozess-Pool verwendet werden, sodass keine Prozess-Launch-Kosten anfallen.

Der Performance-Hit wird im Vergleich zu der Robustheit, die ich gewinnen werde, vernachlässigbar sein.

Nun, wir haben es schließlich als ein mehrfach verarbeitetes System mit Pipes für IPC und einen Buchhalter implementiert, der nach Bedarf Prozesse erzeugt. Ähnlich dem Apache httpd. Es funktioniert perfekt.