並行処理の抽象化はUNIXプロセスをエミュレートしていますか？

さて、私は今日これについて考えていました、そして私はそれについて完全に主観的でバイアスのある意見を求めるようになりました。逆説的に、これにもかかわらず、私はそれが炎戦の飼料でもないと思います。完全に文明化された会話の余地はあると思います-Vim対Emacsはほとんどありません。

私は多くの並行処理の抽象化、特にスレッドの上に構築されたものを使用しました。メッセージパッシング、デフォルトでは不変、デフォルトではスレッドローカル、その他のいずれでも、それらの間には大きな傾向があります。

トレンドは、データ共有を暗黙的ではなく明示的にすることで、スレッドの考え方を逆転させているというものです。つまり、特に指定しない限り、すべてのデータは共有されません。これは、Javaなどの言語で見られる従来のスレッド化とは逆です。（ただし、Javaは独自の高レベルの同時実行抽象化をサポートしていることを知っています。）たとえば、メッセージを明示的に渡します。どの変数がスレッドローカルであるかを明示的に指定します。変更可能な変数を明示的に指定します。これらは、いくつかの言語で見られるほんの一例です。

この並行性の簡単なスタイルは現代のコンセプトだと思いました。間違えた。最近fork（）やpipe（）のようなUNIXのおもちゃをいじり始めましたが、UNIXの開始以来、簡単で明示的な並行処理メカニズムが存在していることを知ってショックを受けました。

70年代のC + UNIXが同時実行性を多くの最新のトレンディなスレッド化メカニズムよりもはるかに簡単にすることを実現することには、少し奇妙な点があります。

だから、ここで私が疑問に思っているのは...これらの現代のスレッド抽象化は、すべての明示性とデフォルトで共有されない特性を備えたスレッド上でUNIXスタイルのプロセスを単にエミュレートしようとしているのでしょうか？STMのようないくつかのメカニズムがDBスタイルのトランザクションのようなものを提供することは確かですが、それは本当に並行性のための現代的で革新的なソリューションですが、ほとんどの場合、UNIXプログラマーが昔行っていたことを行う新しい方法のように見えます。

言うまでもなく、私はUNIXのファンではなく、想像力を伸ばしているわけでもありません。プロセスは多くのプラットフォームで初期化するためにスレッドよりもはるかに遅いことを認識していますが、これは概念的に述べています。

よい観察です。明示的に共有する傾向が確実にあります（関数型言語でも慣習でも）。遅くているプロセスについてのコメントは、私は少し適応になります。彼らはより多くのある重い彼らは生のパフォーマンスで実行して遅くはありませんが、すべてのことを意味し、スイッチそれらの間が長いスレッドの切り替えよりも多くかかります。他の並行性の形式がいくつかあることをすでに認識し、STMを認識しています。（明示的な共有とSTMに加えて）スレッドプーリングへの傾向も高まっていることを付け加えておきます。 （並列タスク;事前に開始されたワーカースレッドにタスクを割り当て、それらをリサイクルする）：プールされたスレッドは通常すべて1つのプロセス内にあるため、明示的に共有するためのパフォーマンスの面と奇妙な異なるアプローチへの確実な道。

XがYをエミュレートすることは、バランスを見つけることよりも問題ではないと思います。

完全に独立したプロセスにより、生活が比較的シンプルになります。それらは、複数のプロセッサの少なくともいくつかの利点を利用するプロセスのパイプラインのようなものを構築することをかなり簡単にします。ただし、明らかな欠点もいくつかあります。特に柔軟性の欠如と、かなりのオーバーヘッドです。

本質的にすべてのリソースを共有する複数の実行スレッドを持つ単一のプロセスは、本質的にそれらを逆転させます：設計の困難さや安定性の維持を犠牲にして、オーバーヘッドを減らし、柔軟性を大幅に高めます。

ほとんどの場合、何が起こっているかというと、人々は、スレッドの柔軟性と速度に近い中間的な地盤を見つけようと取り組んでいることです。少なくともある程度）。