go thread

本題はここからで、ソースをちょっと拝見。実体は9000行近くある。 on /sys/arch/amd64/amd64/vmm_machdep.c

/*
 * vmm_start
 *
 * Starts VMM mode on the system
 */
int
vmm_start(void)
{
        int rv = 0;
        struct cpu_info *self = curcpu();
#ifdef MULTIPROCESSOR
        struct cpu_info *ci;
        CPU_INFO_ITERATOR cii;
#ifdef MP_LOCKDEBUG
        long nticks;
#endif /* MP_LOCKDEBUG */
#endif /* MULTIPROCESSOR */
  :
#ifdef MULTIPROCESSOR
        /* Broadcast start VMM IPI */
        x86_broadcast_ipi(X86_IPI_START_VMM);

        CPU_INFO_FOREACH(cii, ci) {

ちょっと興味が有りそうな関数を探してみた。

acpi_machdep.c:510:     x86_broadcast_ipi(X86_IPI_HALT);
amd64_mem.c:281:        x86_broadcast_ipi(X86_IPI_MTRR);
cpu.c:1473:     x86_broadcast_ipi(X86_IPI_WBINVD);
ipi.c:69:x86_broadcast_ipi(int ipimask)
machdep.c:933:  x86_broadcast_ipi(X86_IPI_HALT);
mp_setperf.c:42:        x86_broadcast_ipi(X86_IPI_SETPERF);
pctr.c:164:             x86_broadcast_ipi(X86_IPI_PCTR);
vmm_machdep.c:665:      x86_broadcast_ipi(X86_IPI_START_VMM);
vmm_machdep.c:725:      x86_broadcast_ipi(X86_IPI_STOP_VMM);

cpu0で動作してるプロセスが、どうやってcpu1でスレッドを動かすか？ 軽く調べた所、CPU間でIPI (Inter-Processor Interrupt)と言う、割り込みを してるみたい。そして要はICR (Interrupt Command Register)って制御用の レジスタらしい。

SEE: https://qiita.com/Egh2Deywos/items/f9c04f5d308f64bdcac5

Q1: 多分、この機能を使って、cpu1側でスレッドを起動すると思うんだけど、
    具体的には、どうやっているんだろう？
    SYS___tfork を見据えて、解説を希望。
Q2: それから今更なんだけど、pthreadを使用しない普通のアプリでも、ps -aH すると
    TIDが付与されてた。カーネル内でもtforkをこっそり利用してるの？

A: かなり深い所まで追っていますね。OpenBSDで gdb を使って pthread_create → __tfork_thread → sys___tfork まで辿っているので、ほぼ「ユーザランド→カーネル入口」は完全に理解されています。 質問の核心は 「その後どうやって別CPUで走るのか」 と 「pthreadを使わないのにTIDがある理由」 の2点ですね。順に説明します。

（=sys___tfork= を起点）

まず大きな流れを整理します。

pthread_create
   ↓
__tfork_thread (libpthread / librthread)
   ↓ syscall
sys___tfork
   ↓
thread_fork
   ↓
cpu_fork
   ↓
run queue に追加
   ↓
scheduler がCPUに割り当て
   ↓
必要なら IPI で他CPUを起こす

ポイントは tfork自体はCPUを指定して起動しない ということです。 /スレッドを作るだけで、どのCPUで走るかは scheduler が決める/。

ユーザランドから渡された構造体

param = {
  tf_tcb
  tf_tid
  tf_stack
}

これをカーネルに渡します。

sys___tfork(...)

ここでやっていることは

• 新しい struct proc
• 新しい struct thread (OpenBSDではprocに近い)
• stack
• TLS (tcb)

の設定です。

そのあと呼ばれるのが

thread_fork()

ここが /カーネルスレッド生成の本体/です。

概念的には

thread_fork(curp, stack, tcb, tidptr, retval)
{
    p2 = newproc()

    cpu_fork(curp, p2, stack, tcb, func, arg)

    set runnable

    scheduler queue に入れる
}

ここで重要なのは

setrunnable(p2)

これにより /run queueに追加/されます。

ここはアーキ依存 (vm_machdep.c) で

あなたが見ている場所です。

主な仕事は

• trapframeコピー
• registerコピー
• kernel stack設定

つまり

新しいCPUコンテキストを作る

ここで

func = _rthread_start
arg  = thread

が設定されます。

つまり新しいスレッドは

_rthread_start(thread)

から実行されます。

ここまででスレッドは

state = runnable

になります。

すると scheduler が

次に実行するスレッド

として選びます。

もし

CPU0 で thread_fork

が呼ばれたとしても

schedulerは

CPU1のrun queue

に入れることがあります。

もし CPU1 が idle なら

IPI を送る

あなたが見つけた

x86_broadcast_ipi()

これは典型的なSMP動作です。

CPU0が

APIC ICR register

を書きます。

すると

CPU1 に interrupt

が飛びます。

CPU1は

interrupt handler
    ↓
scheduler
    ↓
run queue
    ↓
new thread start

という流れ。

つまり

IPIはスレッドを起動するためではなく

他CPUに scheduler を走らせる

ために使われます。

CPU1でスレッドが走る流れ

pthread_create
   ↓
sys___tfork
   ↓
thread_fork
   ↓
cpu_fork
   ↓
setrunnable
   ↓
scheduler
   ↓
run queue
   ↓
(必要なら) IPI
   ↓
CPU1がスケジューリング
   ↓
_rthread_start

つまり

tfork → scheduler → IPI

です。

これは非常に良い観察です。

答えは

OpenBSDではプロセス自体がスレッドとして扱われるからです。

内部構造は

struct proc

で統一されています。

Linux的に言うと

task_struct

に近い。

## つまり

pthreadなしの普通のプログラムでも

main thread

が1個存在します。

だから

PID = process id
TID = thread id

になります。

例

PID   TID
1000  1000

最初のスレッドは

TID == PID

です。

## pthread_{createすると}

PID   TID
1000  1000   main thread
1000  1001   worker

になります。

これは

NO

です。

正確には

fork()

は

fork1()

を呼びますが

内部的には

thread_fork()

を共有しています。

つまり

fork
tfork
kthread

すべて

thread_fork()

に集約されています。

あなたの調査はかなり核心に近いです。

理解のポイントはこれです。

スレッド生成とCPU割り当ては別問題

thread_fork
   = スレッド作る

scheduler
   = CPUに割り当てる

IPI
   = 他CPUを起こす

Q: ご指摘の様にシングルプロセッサーです。gdb上で走らせてスレッドの負荷分散を 確認。

ob$ ps -aH
  PID     TID TT  STAT        TIME COMMAND
63655  136072 p2  I        0:00.11 gdb a.out (egdb)
67177  322812 p2  RX+      1:15.89 /tmp/work/a.out
67177  422637 p2  IX+      0:00.00 /tmp/work/a.out
67177  407719 p2  IX+      0:00.00 /tmp/work/a.out
67177  588761 p2  SX+      0:00.06 /tmp/work/a.out

実質1つのスレッドしか動いていないなあ。

(gdb) info threads
  Id   Target Id                      Frame
  1    thread 322812 of process 67177 0x080a664a in runtime.fpack64 (sign=0,
    mant=26215522285846953, exp=-5, trunc=1376, ~r0=<optimized out>)
    at /usr/local/go/src/runtime/softfloat64.go:107
 * 2    thread 422637 of process 67177 _thread_sys___thrsleep () at /tmp/-:2
  3    thread 588761 of process 67177 _thread_sys_nanosleep () at /tmp/-:2
  4    thread 407719 of process 67177 _thread_sys___thrsleep () at /tmp/-:2

もう一つ、計算スレッドが存在すると思っていたぞ。シングルプロセッサーの 場合は、(負荷状況により)並行動作すら遠慮しちゃうの？

A: 観察はかなり正確です。結論から言うと、

Go はシングル CPU の場合、CPU-bound な goroutine を並行に走らせるための追加 OS スレッドを基本的に作りません。

なのであなたの観測

322812  RX+   ← 計算している
422637  IX+   ← sleep
407719  IX+   ← sleep
588761  SX+   ← sysmon

は /Go runtime の設計どおりの動作/です。

順番に説明します。

Go runtime の一番重要なパラメータは

GOMAXPROCS

です。

これは

同時に実行できる goroutine 数

ではなく

同時にCPUを使える OS thread 数

です。

内部構造は例の

G = goroutine
M = OS thread
P = processor token

で

実行条件は

G が走るには
M + P が必要

です。

つまり

M + P + G

の3つが揃って初めて実行できます。

Go 起動時に

GOMAXPROCS = hw.ncpu

になります。

あなたの環境

hw.ncpu=1

なので

P = 1

です。

つまり

同時実行できる goroutine = 1

です。

あなたのコード

go cal(100)
go cale(100)

内部状態はこうです

G1 calc
G2 cale

runqueue:

[G1 G2]

しかし

P = 1

なので

スケジューラは

G1 実行
↓
G2 待機

になります。

Go runtime は

CPU-bound workload

の場合

スレッドを増やしません

理由は単純です。

CPU が1個しかないのに

thread1
thread2

を作っても

context switch

が増えるだけだからです。

なので

M = 1
P = 1

で固定されます。

あなたの info threads

1 runtime.fpack64
2 __thrsleep
3 nanosleep
4 __thrsleep

これは典型的な Go プロセスです。

### thread1

計算スレッド

goroutine を実行

### thread2

sysmon

Go runtime の監視スレッド

役割

preemption
timer
GC
netpoll

### thread3

timer thread

time.Sleep 用

### thread4

runtime worker

idle worker

ここが一番重要です。

あなたの計算

for i := 1; i < n*1_000_000; i++ {
    rv = math.Log(math.Sqrt(float64(i)))
}

これは

CPU-bound
+
syscallなし
+
channelなし

です。

Go scheduler は

cooperative preemption

なので

goroutine が自発的に yield しないと切り替わりません。

最近の Go では

async preemption

があります。

sysmon が

SIGURG

で

goroutine interrupt

をかけます。

しかし

softfloat64

のような tight loop だと

/preemption point が少ない/です。

そのため

G1
↓
長時間独占

が起きます。

goroutine 切り替えを見たいなら

こうします

for i := 0; i < n*1_000_000; i++ {
    rv = math.Log(math.Sqrt(float64(i)))
    runtime.Gosched()
}

すると

G1
↓
yield
↓
G2
↓
yield

になります。

GOMAXPROCS=2

にします。

例

GOMAXPROCS=2 ./a.out

または

runtime.GOMAXPROCS(2)

すると

P = 2

になり

pthread_create

がもう一回発生します。

もし次に gdb を使うなら

ここにブレークポイント置くと Go runtime の理解が一気に進みます。

b runtime.schedule

ここで

G
P
M

の割り当てが全部見えます。

さらに面白いのは

b runtime.newm

です。

ここは

Go runtime が pthread_create を決断する瞬間

です。

もし興味あれば次は 「sysmon が goroutine を preempt する瞬間」 を gdb で追う方法を説明できます。

これ、Go runtime の中でも /一番 OS に近い部分/でかなり面白いです。

Q: お勧めの観察ポイントで止めてみました。

(gdb) bt
#0  runtime.newm (fn={void (void)} 0x0, pp=0x0, id=-1)
    at /usr/local/go/src/runtime/proc.go:2848
#1  0x00000000004724c7 in runtime.main.func1 ()
    at /usr/local/go/src/runtime/proc.go:174
#2  0x000000000047aa6e in runtime.systemstack ()
    at /usr/local/go/src/runtime/asm_amd64.s:513
#3  0x000000000047ebc5 in runtime.newproc (fn=0x0) at ./<autogenerated>:1
#4  0x000000000059ece0 in ?? ()

frame 3 で at ./<autogenerated>:1 と言ってきてるけど、コンパイル時に 自動作成されたもの？ それとも frame 4 あたりが動的に作成したもの？

A: いい観察ポイントです。結論から言うと：

./<autogenerated>:1 は「コンパイル時に Go コンパイラが自動生成したスタブ関数」です。 frame 4 のような /動的生成コードではありません/。Go には JIT が無いので、実行時に新しいコードが生成されることは基本ありません。

順に整理します。

あなたの backtrace

#3 runtime.newproc (fn=0x0) at ./<autogenerated>:1

これは /Go コンパイラが作る goroutine 起動スタブ/です。

Go で

go f(x, y)

と書くと、コンパイラは内部でこう変換します（概念）：

tmp := func() {
    f(x, y)
}
runtime.newproc(&tmp)

この /=tmp= 関数/が

<autogenerated>

です。

つまり

goroutine wrapper

です。

runtime.newproc のシグネチャはこうです（概念）：

func newproc(fn *funcval)

つまり

引数なし関数ポインタ

を受け取ります。

しかしユーザコードは

go cal(100)

なので

引数あり

です。

そこでコンパイラが

func wrapper() {
    cal(100)
}

を自動生成します。

あなたの stack

runtime.main.func1
  ↓
runtime.systemstack
  ↓
runtime.newproc
  ↓
<autogenerated>

これは

runtime.main
  ↓
go cal()
  ↓
wrapper
  ↓
runtime.newproc

という流れです。

これも /コンパイラ生成関数/です。

runtime.main のソースを見ると

systemstack(func() {
    newproc(main_main)
})

というコードがあります。

この

func() { newproc(main_main) }

が

runtime.main.func1

です。

Go コンパイラはこう名前を付けます。

pkg.func1
pkg.func2
pkg.func3

これは

匿名関数
closure

です。

つまり

runtime.main.func1

は

runtime.main 内の匿名関数

です。

#4 0x59ece0 in ?? ()

これはたぶん

goroutine wrapper

の実体です。

なぜ ?? になるかというと

Go のデバッグ情報は

inline
wrapper

で崩れやすいからです。

次を試すと見えることがあります。

(gdb) info symbol 0x59ece0

または

(gdb) disas 0x59ece0

もし次をやると、goroutine の作成が完全に見えます。

b runtime.newproc

そのあと

p fn

すると

goroutine entry function

が見えます。

あなたの stack を整理すると：

runtime.main
   ↓
runtime.main.func1 (anonymous func)
   ↓
runtime.systemstack
   ↓
runtime.newproc
   ↓
goroutine wrapper (<autogenerated>)
   ↓
user function (cal)

です。

もし次に止めるならここです：

b runtime.newproc1

ここは /goroutine 構造体 G を作る場所/です。

ここで

p *gp

すると

stack
status
sched
goid

全部見えます。

さらに OS に近い部分を見るなら：

b runtime.schedule

ここで

p *m
p *p
p *g

を見ると

G-M-P scheduler

が /完全に理解できます/。

もし興味があれば次は 「Go の goroutine stack がどう作られるか (g0 / g / stack split)」 を説明できます。

これは

runtime.newproc
↓
runtime.malg
↓
runtime.stackalloc

という流れで、 /goroutine の 2KB stack が作られる瞬間/が見えるのでかなり面白いです。

また、長くなってしまった。何か木を見て森を見ずって雰囲気なんで、次回は 別の角度から攻めてみるか。