Node (およびおそらく twisted など) の主な利点の 1 つは、従来のスレッド サーバーに対する、イベント ループ モデルによって実現される非常に高い同時実行性であると言われています。これの最大の理由は、各スレッドのメモリ フットプリントが大きく、コンテキストのスワッピングに比較的コストがかかることです。何千ものスレッドがある場合、サーバーはほとんどの時間をスレッドからスレッドへのスワップに費やします。
私の質問は、オペレーティング システムまたは基盤となるハードウェアが、より軽量なスレッドをサポートしないのはなぜですか? もしそうなら、プレーンスレッドで 10k 問題を解決できますか? できない場合、それはなぜですか?
最新のオペレーティング システムは、非常に多数のスレッドの実行をサポートできます。
より一般的には、ハードウェアは高速化を続けています (最近では、シングルスレッドのイベント ループよりもマルチスレッドやマルチプロセッシングに適した方法で高速化しています。シングルコア）。今日はスレッドのオーバーヘッドを許容できない場合でも、明日には許容できる可能性があります。
Twisted (およびおそらく Node.js など) の協調マルチタスク システムがプリエンプティブ マルチスレッド (少なくとも pthread の形で) よりも優れているのは、プログラミングの容易さです。
マルチスレッドを正しく使用するには、シングル スレッドを正しく使用するよりも注意が必要です。イベント ループは、単一のスレッドを超えずに複数の処理を実行するための手段にすぎません。
並列ハードウェアの普及を考えると、マルチスレッド化またはマルチプロセッシングがより簡単に (そしてより正確に) 実行できるようになることが理想的です。アクター、メッセージ パッシング、さらにはペトリ ネットでさえ、人々がこの問題を解決しようとしてきたソリューションの一部です。主流のマルチスレッド アプローチ (pthreads) と比較すると、それらはまだ非常に重要ではありません。もう 1 つのアプローチは、複数のスレッドを使用して複数のイベント ループを実行する SEDA です。これも定着していません。
そのため、イベント ループを使用する人々はおそらくプログラマーの時間は CPU 時間よりも価値があると判断し、pthreads を使用する人々はおそらくその反対を決定し、アクターなどを研究する人々は両方の種類の時間をより高く評価したいと考えています (明らかにそれがおそらく誰も彼らの話を聞いていない理由です）。
問題は、スレッドがどれほど重いかではなく、正しいマルチスレッドコードを作成するには共有アイテムのロックが必要であり、スレッドがお互いにロックを取得するのを待ってしまうため、スレッドの数に応じてスケーリングできないという事実です。スレッドを追加しても効果がないか、ロックの競合が増えるにつれてシステムの速度が低下するまで、急速に到達します。
多くの場合、ロックを回避できますが、正しく行うのは非常に難しく、単にロックが必要な場合もあります。
したがって、スレッドの数が少ない場合は、リソースをロックする必要があるというオーバーヘッドを取り除くか、それについて考えると、スレッドの数に関係なく、シングルスレッドプログラムがマルチスレッドプログラムよりも高速になることがわかります。追加。
基本的に、ロックは（プログラムによっては）非常にコストがかかる可能性があり、数スレッドを超えてプログラムのスケーリングを停止する可能性があります。そして、ほとんどの場合、何かをロックする必要があります。
問題となるのはスレッドのオーバーヘッドではなく、スレッド間の同期です。スレッドを即座に切り替えることができ、無限のメモリを持っていたとしても、各スレッドが共有リソースで順番を待つことになった場合、それは役に立ちません。