グリーンスレッドとユーザ空間スケジューラの原理

グリーンスレッドとは──カーネルが知らない実行単位

グリーンスレッドとは、OS カーネルではなく 言語ランタイム（ユーザ空間） が生成・スケジュールする軽量な実行単位です。goroutine、Erlang プロセス、各種コルーチン、Java の仮想スレッドがこれにあたります。カーネルから見ると、走っているのは普段どおりの少数の OS スレッドだけで、その内側で何千本もの論理スレッドが多重化されていることをカーネルは一切知りません。

なぜ「軽い」のか。OS スレッドの生成・切替はシステムコールとモード遷移、カーネルのスケジューラ処理を伴います。これに対しグリーンスレッドの切替は ユーザ空間内のレジスタとスタックポインタの退避・復元だけ で済み、カーネルへ落ちません。生成も mmap での大きなスタック予約ではなく、小さなオブジェクト割り当てで足ります。この差が「OS スレッドは数千で頭打ち、goroutine は数十万」という桁違いの密度を生みます。

この多重化は本質的に M:N（M 本の論理スレッドを N 本の OS スレッドへ）であり、汎用 OS のスレッドライブラリでは破綻した方式です（スレッドモデル参照）。ランタイムが成功するのは、I/O を全面的に非ブロッキング化し、ブロック点を自分で管理できる からです。

2種類のスケジューリング──協調とプリエンプティブ

ユーザ空間スケジューラの中核は「いつ実行権を別の論理スレッドへ渡すか」です。

協調的スケジューリング は、論理スレッドが自分で「ここで譲る」と宣言した点でだけ切り替わります。yield、チャネル送受信、I/O 待ち、ロック待ちなどが譲り点です。割り込み機構が要らず、譲り点では状態が静止しているため退避が安全──実装が単純で軽い。弱点は明確で、譲り点を一度も通らない CPU 密集ループ に入った論理スレッドは、他を一切走らせません。最悪、1 本の for {} ループが OS スレッド 1 本を占有し続けます。

プリエンプティブスケジューリング は、ランタイムがこの暴走を外から止めます。鍵は「どこで安全に切れるか」です。任意の機械語命令の途中で切ると、レジスタやスタックが中途半端でガベージコレクタやランタイムが状態を解釈できません。そこで 安全点（safepoint） という、状態が一貫している地点でだけ実際の切替を行います。

ここで効くのが、OS のカーネルプリエンプションと同じ「安全に横取りできる点をどう作るか」という発想です（カーネルプリエンプションと同型の問題）。違いは、カーネルはハードウェアのタイマ割り込みを直接使えるのに対し、ユーザ空間ランタイムはシグナルやコンパイラが埋め込んだチェックという 間接的な仕掛け で割り込みを再現しなければならない点です。

スタック管理──軽さの源泉とトレードオフ

グリーンスレッドの密度を決定づけるのが スタックの持ち方 です。OS スレッドは既定で 1 本あたり 8MiB の仮想アドレスを予約します（実体はデマンドページングで触れた分だけ）。数十万本では仮想空間と管理コストが破綻します。ランタイムはこれを 3 つの方式で回避します。

Go が採る 可変連続スタック は、初期 2KiB 程度で始め、関数プロローグの「スタック不足チェック」が引っかかると倍程度の新領域を確保し、古いスタックの内容を丸ごとコピーして移動 します。スタックが動くため、スタック上を指すポインタを全て新アドレスへ書き換える必要があり、これはランタイムがオブジェクトのレイアウトを完全に把握している（型情報を持つ）からこそ可能です。C のような生ポインタ言語ではスタックを安全に動かせないため、この方式は採れません。

ブロッキングをどう隠すか──ランタイムの肝

最大の設計課題は、論理スレッドがブロッキングシステムコール（ディスク read、同期的ネットワーク I/O など）を呼んだときです。素朴に呼ぶと、それを載せていた OS スレッドごと眠り、同居する他の論理スレッドまで巻き添えで止まります。ランタイムはこれを 2 段で防ぎます。

第一に、ネットワーク I/O は非ブロッキング化 し、内部の I/O 多重化機構（epoll/kqueue）に肩代わりさせます。論理スレッドが read を呼ぶと、ランタイムは裏でノンブロッキング read を発行し、EAGAIN なら その論理スレッドだけを待機キューへ退避 して別の論理スレッドを走らせます。I/O が準備できたら多重化機構が通知し、ランタイムが当該論理スレッドを実行可能列へ戻します。論理スレッドからは普通の同期 read に見えるのに、OS スレッドはブロックされない──これが「同期的に書けて非同期に動く」の正体です。

第二に、避けられない真のブロッキング（一部のファイル I/O や C 呼び出し）には、Go なら新しい OS スレッドを補充して並列度を保ちます。Go ランタイムの G-M-P モデル（G=goroutine、M=OS スレッド／machine、P=論理プロセッサ＝実行コンテキスト）では、システムコールに入った M は持っていた P を手放し、別の M が P を引き継いで他の G を走らせ続けます。

Erlang/BEAM はさらに踏み込み、各スケジューラスレッドが リダクションカウント（関数呼び出し等の実行量カウンタ）を持ち、一定数を消費したら問答無用でプロセスを切り替えます。これによりどれか 1 プロセスが暴走しても全体の応答性が保たれ、ソフトリアルタイム性を担保します。

カーネルスレッドとの対比──適材適所

両者は競合ではなく 階層 です。グリーンスレッドは必ず下層の OS スレッド上で走り、真の並列度は OS スレッド数（≒コア数）で頭打ちになります。グリーンスレッドが効くのは I/O 待ちが多く待機本数が膨大 な領域（多数の同時接続をさばくサーバーなど）で、待機コストをほぼゼロにできます。逆に 純粋な CPU バウンド計算 では、論理スレッドを増やしても並列度は上がらず、OS スレッドやスレッドプールで十分です。

グリーンスレッドの本質は「スケジューラとスタック割り当てをカーネルから取り戻し、自分の都合のいい粒度で並行性を作る」ことです。文脈の退避・復元という機械的な仕組みはコンテキストスイッチと同じですが、それを 誰がどこで判断するか をユーザ空間へ移したことが、密度と書き味の両方を生んでいます。