Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

[インデックス 16341] ファイルの概要

このコミットは、Goランタイムにおけるシステムコールからの復帰後のGoroutine (G) の状態設定に関する修正です。具体的には、runtime·exitsyscall 関数内で、システムコールから戻ったGoroutineのステータスを適切にGrunningに設定し、スケジューラのティックをインクリメントすることで、ランタイムの正確な動作を保証します。

コミット

commit fee1d1cda04e6a936d62be6d06c838150a03d2de
Author: Dmitriy Vyukov <dvyukov@google.com>
Date:   Sun May 19 19:35:09 2013 +0400

    runtime: properly set G status after syscall

GitHub上でのコミットページへのリンク

https://github.com/golang/go/commit/fee1d1cda04e6a936d62be6d06c838150a03d2de

元コミット内容

    runtime: properly set G status after syscall
    
    R=golang-dev, r, dave
    CC=golang-dev
    https://golang.org/cl/9307045

変更の背景

Goランタイムは、Goroutineのスケジューリングとシステムコール（syscall）のハンドリングを効率的に行うために複雑なメカニズムを持っています。Goroutineがシステムコールを実行する際、そのGoroutineは実行中の状態（Grunning）からシステムコール待ちの状態（Gsyscallなど）に遷移します。システムコールが完了し、Goroutineが実行を再開する準備ができたとき、ランタイムはGoroutineの状態を再びGrunningに戻す必要があります。

このコミットが行われた背景には、システムコールから復帰したGoroutineの状態が適切に設定されていない、あるいはスケジューラのティックが更新されていないという問題があった可能性があります。これにより、スケジューラがGoroutineの正確な状態を認識できず、デッドロック、パフォーマンスの低下、あるいは予期せぬ動作を引き起こす可能性がありました。特に、GoのスケジューラはM（OSスレッド）とP（プロセッサ）の概念を用いてGoroutineを効率的に管理しており、これらの状態管理の不備はシステム全体の安定性に影響を与えます。

この修正は、システムコールから戻ったGoroutineがすぐに実行可能な状態であることをランタイムに正確に伝え、スケジューラの健全性を保つことを目的としています。

前提知識の解説

このコミットを理解するためには、以下のGoランタイムの概念と動作メカニズムを理解しておく必要があります。

  1. Goroutine (G): Goにおける軽量な実行単位です。OSスレッドよりもはるかに軽量で、数百万個のGoroutineを同時に実行できます。各Goroutineは独自のスタックを持ち、Goランタイムによってスケジューリングされます。
  2. Machine (M): OSスレッドを表します。Goランタイムは、Goroutineを実行するためにMを使用します。MはOSのスケジューラによって管理されます。
  3. Processor (P): 論理プロセッサを表します。PはMとGoroutineの間の仲介役として機能します。MはPを取得し、Pに紐付けられたローカルキューからGoroutineを取得して実行します。Pの数は通常、CPUのコア数に設定され、並列実行可能なGoroutineの数を制限します。
  4. Goroutineの状態 (G status): Goroutineはライフサイクルの中で様々な状態を遷移します。主要な状態には以下のようなものがあります。
    • Grunning: GoroutineがM上で実行中である状態。
    • Grunnable: Goroutineが実行可能であり、PのローカルキューまたはグローバルキューでMにピックアップされるのを待っている状態。
    • Gsyscall: Goroutineがシステムコールを実行中で、OSスレッド（M）がシステムコールから戻るのを待っている状態。この間、Mはブロックされますが、Pは解放され、他のGoroutineを実行するために利用できます。
    • Gwaiting: Goroutineがチャネル操作、ミューテックスのロック、ネットワークI/Oなど、何らかのイベントを待っている状態。
  5. システムコール (Syscall): プログラムがOSの機能（ファイルI/O、ネットワーク通信など）を要求する際に使用するインターフェースです。GoのGoroutineがシステムコールを実行すると、そのGoroutineをホストしているM（OSスレッド）はシステムコールが完了するまでブロックされます。Goランタイムは、このブロック中にPを解放し、他のGoroutineを別のMで実行できるようにすることで、OSスレッドのブロックがGoプログラム全体の並列性を損なわないようにします。
  6. Goスケジューラ (GMPモデル): Goランタイムのスケジューラは、G（Goroutine）、M（Machine/OSスレッド）、P（Processor）の3つのエンティティで構成されるGMPモデルを採用しています。このモデルにより、Goは効率的な並行処理を実現しています。
    • GoroutineはPに割り当てられ、PはMによって実行されます。
    • システムコールが発生すると、GoroutineはGsyscall状態になり、Mはブロックされます。このとき、PはMから切り離され、別のMがPを取得して他のGoroutineを実行できます。
    • システムコールが完了すると、Goroutineは再び実行可能になり、Pに再割り当てされる必要があります。

技術的詳細

このコミットは、Goランタイムのsrc/pkg/runtime/proc.cファイル内のruntime·exitsyscall関数に焦点を当てています。この関数は、Goroutineがシステムコールから正常に復帰した際に呼び出される重要なフックです。

システムコールから復帰する際、Goランタイムは以下の処理を行う必要があります。

  1. システムコールを実行していたGoroutine (g) を再び実行可能な状態にする。
  2. そのGoroutineが実行されるM (m) に関連付けられたP (p) の状態を更新する。特に、Pのティックカウンターをインクリメントすることは、スケジューラの負荷分散やプリエンプションの判断に影響を与える可能性があります。

修正前のコードでは、システムコールから復帰したGoroutineの状態が明示的にGrunningに設定されていませんでした。また、Pのティックカウンターも更新されていませんでした。これにより、以下のような問題が発生する可能性がありました。

  • Goroutineの状態の不整合: Goroutineがシステムコールから戻ったにもかかわらず、ランタイムがそのGoroutineをGrunningとして認識しない場合、スケジューラがそのGoroutineを適切にスケジューリングできない可能性があります。これにより、Goroutineが実行されない、あるいは遅延して実行されるといった問題が発生し得ます。
  • スケジューラの不正確な動作: Pのティックカウンターは、スケジューラがGoroutineの実行時間を追跡し、必要に応じてプリエンプション（強制的な実行中断）を行うための重要な情報です。システムコールからの復帰時にティックが更新されないと、スケジューラがGoroutineの実行状況を誤って判断し、不適切なスケジューリング判断を下す可能性があります。

このコミットは、これらの問題を解決するために、runtime·exitsyscall関数に以下の2行を追加しています。

  1. m->p->tick++;: 現在のMに紐付けられているPのティックカウンターをインクリメントします。これは、PがGoroutineの実行に費やした時間や、Pがアクティブであった期間を追跡するために使用されます。システムコールからの復帰もPがアクティブな状態に戻ることを意味するため、ティックを更新することは理にかなっています。
  2. g->status = Grunning;: システムコールから復帰したGoroutine (g) の状態を明示的にGrunningに設定します。これにより、ランタイムはGoroutineが実行可能であり、M上で実行中であることを正確に認識できます。

これらの変更により、Goランタイムはシステムコールからの復帰をより正確に処理し、Goroutineのスケジューリングの健全性と効率性を向上させます。

コアとなるコードの変更箇所

変更はsrc/pkg/runtime/proc.cファイルのruntime·exitsyscall関数内で行われています。

--- a/src/pkg/runtime/proc.c
+++ b/src/pkg/runtime/proc.c
@@ -1370,6 +1370,8 @@ runtime·exitsyscall(void)\n \t\truntime·unlock(&runtime·sched);\n \t\tif(p) {\n \t\t\tacquirep(p);\n+\t\t\tm->p->tick++;\n+\t\t\tg->status = Grunning;\n \t\t\tg->gcstack = (uintptr)nil;\n \t\t\tg->gcsp = (uintptr)nil;\n \t\t\treturn;\

具体的には、acquirep(p); の呼び出し直後に以下の2行が追加されています。

  • m->p->tick++;
  • g->status = Grunning;

コアとなるコードの解説

runtime·exitsyscall関数は、Goroutineがシステムコールを完了し、ユーザー空間での実行を再開する準備ができたときに呼び出されます。この関数は、システムコール中にブロックされていたM（OSスレッド）が解放され、再びGoroutineの実行に利用可能になったことをランタイムに通知する役割を担います。

追加された2行のコードは、この復帰プロセスにおいて非常に重要です。

  1. m->p->tick++;

    • m は現在のM（OSスレッド）を表します。
    • m->p は、そのMが現在関連付けられているP（プロセッサ）を指します。
    • tick は、PがアクティブにGoroutineを実行している期間を追跡するためのカウンターです。このカウンターは、スケジューラがGoroutineの実行時間を測定し、必要に応じてプリエンプションをトリガーするために使用されます。システムコールから復帰し、Goroutineが再び実行可能になったということは、Pが再び「仕事」を開始したことを意味するため、tickをインクリメントすることは、Pの活動を正確に反映するために必要です。

  2. g->status = Grunning;

    • g はシステムコールから復帰したGoroutineを表します。
    • g->status は、そのGoroutineの現在の状態を示します。
    • システムコール中はGoroutineはGsyscallなどの状態にありましたが、システムコールが完了し、実行を再開する準備ができたため、その状態をGrunningに明示的に設定します。これにより、Goスケジューラは、このGoroutineが現在実行中であるか、または実行可能キューに置かれるべきであることを正しく認識できます。この設定がないと、Goroutineが実行可能な状態であるにもかかわらず、スケジューラがそれを認識せず、デッドロックやスケジューリングの遅延を引き起こす可能性がありました。

これらの変更は、GoランタイムのスケジューラがGoroutineのライフサイクル、特にシステムコールとの相互作用をより正確かつ効率的に管理するために不可欠です。これにより、Goプログラムの並行処理の信頼性とパフォーマンスが向上します。

関連リンク

参考にした情報源リンク

  • Go言語のソースコード（特にsrc/pkg/runtime/proc.c）
  • Go言語の公式ドキュメントおよびブログ記事
  • Goランタイムの内部動作に関する技術ブログや解説記事（一般的なGMPモデルやスケジューラに関する情報）
  • コミットメッセージと関連するGoのコードレビュー（CL）のリンク: https://golang.org/cl/9307045 (このリンクは古いGoのコードレビューシステムのもので、現在はアクセスできない可能性がありますが、当時のコンテキストを示すものです。)
  • GoのIssueトラッカー（関連するバグ報告や議論がある場合）