core.async goブロック自体がパークしていますか、または「スケジューラ」がありますか？

Question

私が理解しているように、JVMには、n + 2スレッド数のcore.async goブロックに利用可能なスレッドプールがあります。nはマシン上のコア数です。

しかし、多くのgoブロックを同時に1つのスレッドにデプロイすることができます。それぞれは、駐車状態（その計算が進行していないことを意味する）または実行状態（その計算が熱を発生する炉心の周りで鳴っている）のいずれかである。クアッドコアマシンに1000個のブロックがある場合、これらの1000個のブロックのうち最大6個がいつでも実行状態にあると推測します。したがって、他の994ブロックは駐車する必要があります。

フルスレッドはコアにスケジュールされます。 OSスケジューラまたはJVMスーパバイザスレッドによって実行されます。だから、goブロックは駐車状態にどのように出入りしますか？それは、実行中（ブロック）に飽きたときに自分自身をパークするか、ブロックがどのスレッド上で実行され、ラウンドロビンなどのいくつかのスケジューリングアルゴリズムの影響を受けるブロックを決定する「ブロックスケジューラ」として働くスーパバイザスレッドです。

ありがとうございました

Answer 1

goマクロはフォーム全体を歩き、駐車する必要のある場所を見つけ、明示的にこれらの場所にスレッドをパークするコールを入れます。されている一般的なものには次のものがありますasync/thread

にちゃん>!

呼び出しに送信ちゃん<!

から取って他に行くのブロック

の

• スタートこれは、ブロックが関数呼び出しをまたがることができない理由の大きな部分です。コンパイラ/マクロはこれらを正しい場所に配置するためにコードブロック全体を見ることができる必要があります。