私はErlangの研究を始めましたが、BEAMランタイム環境が魅力的であることがわかりました。Erlangでは、プロセスはOS（ランタイムを意味し、この場合はBEAMを意味します）ではなく言語に属すると一般的に言われています。これらは、Erlangが有名になりつつある軽量の「グリーンプロセス」です。さらに、BEAMはCPUコアごとに1つのOSスレッドをスケジューリングに使用し、別のOSスレッドをI / Oに使用すると述べています（このペーパーの5ページ）。だから私は疑問に思います：Erlangコードを実際に実行するために必要なCPUサイクルはどのスレッドから来ていますか？
さらに、デュアルコアマシンで実行している場合、これまでに読んだ内容に基づいて、BEAMプロセスで実行されている3つのスレッド（2つのスケジューラー（コアごとに1つ）と1つのI/Oスレッド。しかし、私は10を見ます。時々11。時々それは13で始まり、高品質のアンプのように、11に行きます。
よくわかりません。任意の洞察をいただければ幸いです。
@ user425720のアドバイスに従って、erlang-questionsLISTSERVで質問しました。Googleグループとしても利用できます。TriforkのKrestenKrabThorupは、ほぼすぐに私に答えました。クレストンに出かけてくれてありがとう。これが彼の答えです。（Parentheticalsと強調は私のものです。）
基本的なシナリオであるAFAIKは次のとおりです。
Erlangコードは、プロセスと同じ数の「グリーンスレッド」で実行されます。プロセス制限は、+ P（コマンドライン）フラグによって制御されます。
緑のスレッドはSスレッドにマップされます。ここで、Sはコア/CPUの数です。これらのスレッドがスケジューラーとも呼ばれるという事実は 、やや混乱しているように見えるかもしれませんが、VMの観点からはそうです。 開発者の観点からは、これらはerlangコードを実行するスレッドです。数値Sは、erlコマンドラインの+Sオプションで制御できます。
これに加えて、いわゆる「非同期スレッド」がいくつかあります。これは、ドライバーでリンクされていると呼ばれるI / Oプロセスが、選択/ポーリングなどに反応するために使用するスレッドプールです。非同期スレッドの数は動的ですが、+Aフラグによって制限されます。
したがって、デュアルコアに表示される11個のスレッドは、2個のスケジューラーと9個の非同期スレッドである可能性があります。例えば。
フラグの詳細については、こちらをご覧ください。
Javaではスレッドが緑色であるため、Erlangプロセスは「緑色」ではありません。Erlangプロセスはメモリを共有しない構造であり、ErlangVMによって維持されます。
奇妙に聞こえるかもしれませんが、この論文は「古い」可能性があります（2007年のバイオですが）。ランタイムキューのまったく新しい処理（動的バランシングやその他の機能を使用）を取得したとき、R13リリースの前後ですべてが変更されました。これは、UlfWigerによるそれに関するプレゼンテーションですhttp://ulf.wiger.net/weblog/2009/01/23/erlang-programming-for-multicore/
要約すると、プロセスは完全に透過的であり、ランタイムキューとスケジューラの数を調整できますが、OSの実現は損なわれていません。なぜスレッドが11個あるのか推測したくありません。
編集：私はOSについて少し間違っています：
+S Schedulers:SchedulerOnlineSMPサポートが有効になっている場合に、作成するスケジューラスレッドとオンラインで設定するスケジューラスレッドの数を設定します。
両方の値の有効な範囲は1〜1024です。Erlangランタイムシステムが構成された論理プロセッサーと使用可能な論理プロセッサーの量を判別できる場合、スケジューラーはデフォルトで構成された論理プロセッサーになり、
SchedulersOnlineデフォルトで使用可能な論理プロセッサーになります。それ以外の場合、デフォルト値は1になります。そうでない場合:SchedulerOnlineはスケジューラーを省略でき、その逆も可能です。オンラインのスケジューラーの数は、実行時にを介して変更できますerlang:system_flag(schedulers_online, SchedulersOnline)。..。
エミュレータでSMPサポートが有効になっていない場合、このフラグは無視されます（
-smpフラグを参照）。
ここから：http ：//www.erlang.org/doc/man/erl.html
EDIT2：多くのVMと多くのスケジューラーの長所と短所に関するerlang-questionメーリングリストに関する興味深い議論。残念ながら、これも2008年のものであり、新しいOTPリリースの大幅な改善により有効にならない可能性があります。http://www.erlang.org/cgi-bin/ezmlm-cgi?4:mss:38165:200809:nbihpkepgjcfnffkoobf