Emulieren Parallelitätsabstraktionen UNIX-Prozesse?

OK, ich habe heute darüber nachgedacht und bin gekommen, um nach völlig subjektiven und voreingenommenen Meinungen zu fragen . Trotzdem denke ich paradoxerweise auch nicht, dass es Flammenkriegsfutter ist. Ich denke, es gibt Raum für perfekt zivilisierte Gespräche - es ist kaum Vim gegen Emacs.

Ich habe viele Parallelitätsabstraktionen verwendet, insbesondere solche, die auf Threads basieren. Es gibt einen großen Trend unter ihnen, ob es sich um Nachrichtenübermittlung, standardmäßig unveränderliche oder standardmäßige Thread-Lokalisierung oder andere handelt.

Der Trend geht dahin, dass sie alle die Idee von Threads umkehren, indem sie den Datenaustausch explizit und nicht implizit machen. Das heißt, alle Daten werden nicht gemeinsam genutzt, sofern nicht anders angegeben. Dies ist das Gegenteil von herkömmlichem Threading in Sprachen wie Java. (Ich weiß, dass Java seine eigenen Parallelitätsabstraktionen auf höherer Ebene unterstützt.) Beispielsweise übergeben Sie Nachrichten explizit. Sie geben explizit an, welche Variablen threadlokal sind. Sie geben explizit an, welche Variablen veränderbar sind. Dies sind nur einige Beispiele, die in einigen Sprachen zu finden sind.

Ich dachte, dieser einfache Stil der Parallelität sei ein modernes Konzept. Ich lag falsch. Ich habe kürzlich angefangen, mit UNIX-Spielzeugen wie fork () und pipe () herumzuspielen, und ich war schockiert zu entdecken, dass es seit dem Start von UNIX mühelose, explizite Parallelitätsmechanismen gibt.

Es ist etwas seltsam zu erkennen, dass C + UNIX aus den 70er Jahren die Parallelität weitaus einfacher macht als viele moderne trendige Threading-Mechanismen.

Also, hier ist was ich mich frage ... versuchen diese modernen Thread-Abstraktionen einfach, Prozesse im UNIX-Stil über Threads zu emulieren, mit all ihren expliziten und nicht standardmäßig geteilten Merkmalen? Ich weiß, dass einige Mechanismen wie STM Dinge wie Transaktionen im DB-Stil bieten, die wirklich eine moderne und innovative Lösung für die Parallelität darstellen, aber die meisten scheinen nur neue Wege zu sein, wie UNIX-Codierer es vor langer Zeit getan haben.

Um nur zu sagen, ich bin kein UNIX-Fan, keine Vorstellungskraft. Ich bin mir bewusst, dass Prozesse auf vielen Plattformen viel langsamer als Threads sind, aber ich spreche konzeptionell darüber.

Gute Beobachtung, es gibt definitiv einen Trend zum expliziten Teilen (ob durch funktionale Sprachen oder Konventionen). Der Kommentar zu Prozessen, die langsamer sind, würde ich ein wenig anpassen: Sie sind schwerer , was bedeutet, dass sie nicht langsamer in der Rohleistung ausgeführt werden, aber jeder Wechsel zwischen ihnen dauert viel länger als der Wechsel zwischen Threads. Sie haben bereits erkannt, dass es einige andere Formen der Parallelität gibt, und haben STM erkannt . Ich möchte nur hinzufügen, dass es (zusätzlich zu explizitem Teilen und STM) auch einen wachsenden Trend zum Thread-Pooling gibt (Aufgabe parallel; Aufgaben den zuvor gestarteten Worker-Threads zuweisen und recyceln): Definitiv der Weg zur Leistung und seltsamerweise ein anderer Ansatz zur expliziten Freigabe, da die gepoolten Threads normalerweise alle in einem Prozess enthalten sind.

Ich denke, es geht weniger darum, X Y zu emulieren, als darum, ein Gleichgewicht zu finden.

Vollständig getrennte Prozesse halten das Leben relativ einfach. Sie machen es ziemlich einfach, Dinge wie Pipelines von Prozessen zu erstellen, die zumindest einige Vorteile mehrerer Prozessoren nutzen. Es gibt jedoch auch einige ziemlich offensichtliche Nachteile - insbesondere mangelnde Flexibilität und einiges an Overhead.

Ein einzelner Prozess mit mehreren Ausführungsthreads, die im Wesentlichen alle Ressourcen gemeinsam nutzen, kehrt diese im Wesentlichen um: geringerer Overhead und viel Flexibilität auf Kosten einer schwierigeren Gestaltung und / oder Stabilität.

Zum größten Teil arbeiten die Leute daran, einen Mittelweg zu finden, der nahezu die Flexibilität und Geschwindigkeit von Threads bietet, mit dem einfacheren Design und dem stabileren Ergebnis separater Prozesse (und ich denke, sie sind größtenteils erfolgreich) zumindest bis zu einem gewissen Grad).