マルチスレッドJavaScriptランタイム実装を作成することの欠点は何ですか？[閉まっている]

この1週間、マルチスレッドJavaScriptランタイムの実装に取り​​組んでいます。JavaScriptCoreとboostを使用して、C ++で作成した概念実証があります。

アーキテクチャは単純です。メインスクリプトの評価が完了すると、ランタイムは起動してスレッドプールに参加します。スレッドプールは、共有優先度キューからタスクを選択し始めます。2つのタスクが同時に変数にアクセスしようとすると、アトミックとマークされ、アクセスを争います。

問題は、この設計をJavaScriptプログラマーに見せると、非常に否定的なフィードバックが得られ、その理由がわからないことです。非公開でも、JavaScriptはシングルスレッドである必要があり、既存のライブラリを書き換える必要があり、作業を続けるとグレムリンがすべての生物を生成して食べると言う。

私はもともとネイティブのコルーチン実装（ブーストコンテキストを使用）も配置していましたが、それを捨てなければなりませんでした（JavaScriptCoreはスタックについてはしゃれています）。

どう思いますか？JavaScriptはシングルスレッドを対象としていますが、JavaScriptはそのままにしておくべきですか？誰もが同時JavaScriptランタイムのアイデアに反対しているのはなぜですか？

編集：プロジェクトは現在GitHubにあります。自分で試してみて、あなたの考えを教えてください。

以下は、競合なしですべてのCPUコアで並行して実行されるプロミスの図です。

1）マルチスレッドは非常に困難です。残念ながら、これまでこのアイデアを提示してきた方法は、その難しさを厳しく過小評価していることを意味します。

現時点では、単に言語に「スレッドを追加」し、後でそれを修正してパフォーマンスを向上させる方法を心配しているように思えます。特に：

2つのタスクが同時に変数にアクセスしようとすると、アトミックとしてマークされ、アクセスを求めて競合します。
...
アトミック変数がすべてを解決するわけではないことに同意しますが、同期問題の解決に取り組むことが私の次の目標です。

「同期の問題の解決策」なしでJavascriptにスレッドを追加することは、「追加の問題の解決策」なしでJavascriptに整数を追加するようなものです。それは問題の性質にとって非常に基本的であるため、どれほどひどく望むとしても、特定のソリューションを念頭に置いてマルチスレッドを追加する価値があるかどうかを議論することさえ基本的に意味がありません。

さらに、すべての変数をアトミックにすることは、マルチスレッドプログラムのパフォーマンスをシングルスレッド対応のものよりも悪化させる可能性が高い種類のことです。これにより、より現実的なプログラムで実際にパフォーマンスをテストし、何かを得ているかどうかを確認することがさらに重要になります。

また、node.jsプログラマーからスレッドを非表示にしようとしているのか、ある時点でスレッドを公開して、マルチスレッドプログラミング用のJavascriptの新しい方言を効果的に作成しようとしているのかどうかもわかりません。どちらのオプションも興味深い可能性がありますが、どちらを目指しているかまだ決めていないようです。

そのため、現時点では、プログラマーに、シングルスレッド環境から、同期の問題の解決策も実際のパフォーマンスを改善する証拠もないまったく新しいマルチスレッド環境への切り替えを検討するように求めています。

それはおそらく人々があなたを真剣に受け止めない理由です。

2）シングルイベントループのシンプルさと堅牢性は、大きな利点です。

Javascriptプログラマーは、Javascript言語が、すべての真のマルチスレッドプログラミングを悩ませている競合状態やその他の非常に潜んでいるバグから「安全」であることを知っています。彼らが安全を放棄するよう説得するために彼らが強い議論を必要とするという事実は、彼らを閉ざされたものにするのではなく、彼らを責任があるものにします。

その安全性をどうにか維持できない限り、マルチスレッドのnode.jsに切り替えたいと思う人は誰でも、マルチスレッドアプリケーション用にゼロから設計されたGoのような言語に切り替える方が良いでしょう。

3）Javascriptは、スレッド管理をプログラマに直接公開することなく、「バックグラウンドスレッド」（WebWorkers）と非同期プログラミングを既にサポートしています。

これらの機能は、単一のイベントループの安全性をあきらめることなく、現実世界のJavascriptプログラマに影響を与える一般的なユースケースの多くを既に解決しています。

これらの機能では解決できないことや、Javascriptプログラマーが解決策を求めていることを念頭に置いた特定のユースケースはありますか？その場合、その特定のユースケースのコンテキストでマルチスレッドnode.jsを提示することをお勧めします。

PSとは何でしょう説得私をマルチスレッドNode.jsの実装への切り替えをしようとしますか？

Javascript / node.jsで、本物のマルチスレッド化の恩恵を受けると思われる重要なプログラムを作成します。通常のノードとマルチスレッドノードで、このサンプルプログラムのパフォーマンステストを実行します。お使いのバージョンが、バグや不安定性を導入することなく、ランタイムのパフォーマンス、応答性、および複数コアの使用を大幅に改善することを示してください。

それができたら、このアイデアにもっと多くの人が興味を持つようになると思います。

ここで推測して、アプローチの問題を示してください。どこにもリンクがないため、実際の実装に対してテストすることはできません...

これは、不変式が常に1つの変数の値で表されるわけではなく、「1つの変数」では一般的な場合のロックのスコープとなるには不十分だからです。たとえば、不変式a+b = 0（2つの口座を持つ銀行の残高）があるとします。以下の2つの関数は、各関数（シングルスレッドJSの実行単位）の最後に不変式が常に保持されるようにします。

function withdraw(v) {
  a -= v;
  b += v;
}
function deposit(v) {
  b -= v;
  a += v;
}

さて、マルチスレッドの世界では、2つのスレッドが同時に実行されるwithdrawとdepositどうなりますか？ありがとう、マーフィー...

（+ =と-=を特別に扱うコードがあるかもしれませんが、それは役に立ちません。ある時点で、関数にローカル状態があり、不変式が同時に2つの変数を 'ロック'する方法がありません。違反されます。）

編集：あなたのコードがhttps://gist.github.com/thriqon/f94c10a45b7e0bf656781b0f4a07292aのGoコードと意味的に同等である場合、私のコメントは正確です;-)

10年ほど前、Brendan Eich（JavaScriptの発明者）はThreads Suckと呼ばれるエッセイを書きました。これは間違いなく、JavaScriptのデザイン神話の数少ない正規のドキュメントの1つです。

それが正しいかどうかは別の質問ですが、JavaScriptコミュニティが並行性についてどのように考えるかに大きな影響を与えたと思います。

アトミックアクセスは、スレッドセーフな動作に変換されません。

たとえば、ハッシュマップの再ハッシュ（プロパティをオブジェクトに追加するときなど）やグローバル配列の並べ替えなど、更新中にグローバルデータ構造を無効にする必要がある場合です。その間、他のスレッドに変数へのアクセスを許可することはできません。これは基本的に、読み取り/更新/書き込みサイクル全体を検出し、それをロックする必要があることを意味します。更新が些細ではない場合、問題の領域を停止することになります。

Javascriptは最初からシングルスレッド化およびサンドボックス化されており、すべてのコードはこれらの前提を念頭に置いて記述されています。

これは、分離されたコンテキストに関して大きな利点があり、2つの独立したコンテキストを異なるスレッドで実行できます。また、javascriptを書いている人は、競合状態やその他のさまざまなマルチスレッドpitfalsに対処する方法を知る必要がないことも意味しています。

あなたのアプローチはパフォーマンスを大幅に改善しますか？

疑わしい。あなたは本当にこれを証明する必要があります。

あなたのアプローチはコードを書くことをより簡単/より速くするつもりですか？

確かにそうではありませんが、マルチスレッドコードは、シングルスレッドコードよりも適切に動作することが何倍も困難です。

あなたのアプローチはより堅牢になりますか？

デッドロック、競合状態などを修正するのは悪夢です。

実装は、並行性を導入することだけでなく、並行性を実装するための特定の方法、つまり共有可変状態による並行性を導入することでもあります。歴史の中で、人々はこのタイプの並行性を使用してきましたが、これは多くの種類の問題を引き起こしました。もちろん、共有可能な可変状態並行性を使用して完全に機能するシンプルなプログラムを作成できますが、メカニズムの実際のテストはそれができることではありませんが、プログラムが複雑になり、より多くの機能がプログラムに追加されるにつれてスケーリングできます。ソフトウェアは、一度構築して完成した静的なものではなく、時間の経過とともに進化し続け、メカニズムや概念が可能であれば

並行性の他のモデル（例：メッセージの受け渡し）を見て、これらのモデルが提供する利点の種類を理解するのに役立ちます。

これが必要です。ノードjsに低レベルの並行性メカニズムがないため、数学やバイオインフォマティクスなどの分野でのアプリケーションが制限されます。さらに、スレッドでの並行性は必ずしもノードで使用されるデフォルトの並行性モデルと競合しません。uiフレームワーク（およびnodejs）など、メインイベントループのある環境でスレッド化するためのセマンティクスはよく知られていますが、有効な用途があるほとんどの状況では明らかに過度に複雑です。

確かに、あなたの平均的なWebアプリはスレッドを必要としませんが、少し慣習的ではないことを試してみてください。そして、低レベルの同時実行プリミティブが不足していると、すぐにそれを提供する他のものに動揺します。

それは別の強力なアイデアだからだと本当に信じています。あなたは信念体系に反対しています。スタッフは、メリットに基づいてではなく、ネットワークに影響を与えるか、受け入れられます。また、誰も新しいスタックに適応したくありません。人々はあまりにも異なるものを自動的に拒否します。

ありそうにない通常のnpmモジュールにする方法を考え出すことができれば、それを使用している人がいるかもしれません。