Erlang は多くの軽量プロセスをサポートできることで知られています。これが可能なのは、これらが従来の意味でのプロセスではなく、P スレッドのようなスレッドでもなく、完全にユーザー空間内のスレッドであるためです。
これはまあまあです（実際には素晴らしいです）。しかし、Erlang スレッドはマルチコア/マルチプロセッサ環境でどのように並列実行されるのでしょうか? 別々のコアで実行するには、どうにかしてカーネル スレッドにマップする必要がありますか?
それが事実であると仮定すると、これはどのように行われますか？多くの軽量プロセスが 1 つのカーネル スレッドにマップされていますか?
または、この問題を回避する別の方法はありますか?
受け入れられた回答に記載されている内容に入力を追加したいと思います。
Erlang スケジューラは、Erlang ランタイム システムの重要な部分であり、OS スレッド上の軽量プロセスの概念の独自の抽象化と実装を提供します。
各スケジューラは、単一の OS スレッド内で実行されます。通常、ハードウェア上の CPU (コア) と同じ数のスケジューラーがあります (構成可能ですが、スケジューラーの数がハードウェア コアの数を超えると、当然あまり価値がありません)。スケジューラが OS スレッド間をジャンプしないようにシステムが構成されている場合もあります。
現在、Erlang プロセスが作成されているとき、ライフ サイクルとリソース消費、およびそのメモリ フットプリントなどを管理するのは、完全に ERTS とスケジューラの責任です。
コア実装の詳細の 1 つは、スケジューラが実行キューからそのプロセスを取得するときに、各プロセスに 2000 削減の時間予算があることです。システムの各進捗 (I/O も含む) には、削減予算があることが保証されています。これが、実際に ERTS をプリエンプティブ マルチタスク機能を備えたシステムにしている理由です。
Jesper Louis Andersen によるこのトピックに関する素晴らしいブログ投稿をお勧めしますhttp://jlouisramblings.blogspot.com/2013/01/how-erlang-does-scheduling.html
簡単に言うと、Erlang プロセスは OS スレッドではなく、直接マップされません。Erlang スケジューラは OS スレッド上で実行されるものであり、プログラマーの目に見えない詳細を隠す、よりきめ細かい Erlang プロセスのスマートな実装を提供します。
ここでは純粋に推測していますが、実行のために共通のプロセス プールからプロセスを選択する少数のスレッドがあると想像できます。プロセスがブロッキング操作にヒットすると、それを実行するスレッドはそれを脇に置き、別の操作を選択します。実行中のプロセスによって別のプロセスがブロック解除されると、その新しくブロック解除されたプロセスがプールに配置されます。特定の時点で他のプロセスにサービスを提供するためにブロックされていない場合でも、スレッドがプロセスの実行を停止する可能性があると思います。