linux - 为什么多个克隆系统调用调用单个 go 子程序？

Question

我创建了一个小示例程序来检查子例程系统调用。

package main

func print() {
}

func main() {
    go print()
}

go 子程序的 straces

clone(child_stack=0xc000044000, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM) = 27010
clone(child_stack=0xc000046000, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM) = 27011
clone(child_stack=0xc000040000, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM) = 27012
futex(0x4c24a8, FUTEX_WAIT_PRIVATE, 0, NULL) = 0
futex(0xc000034848, FUTEX_WAKE_PRIVATE, 1) = 1
exit_group(0)                           = ?

据观察，三次克隆系统调用调用了单个子例程，但堆栈大小如 go 所声称的那样小。你能告诉我为什么三个克隆系统调用需要一个子程序吗？

以类似的方式创建一个 pthread 时调用单次克隆系统调用。但堆栈大小很大。

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h> //Header file for sleep(). man 3 sleep for details.
#include <pthread.h>

void *myThreadFun(void *vargp)
{
        return NULL;
}

int main()
{
        pthread_t thread_id;
        pthread_create(&thread_id, NULL, myThreadFun, NULL);
        pthread_join(thread_id, NULL);
        exit(0);
}

pthread 的 Straces

clone(child_stack=0x7fb49d960ff0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARET_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x7fb49d9619d0, tls=0x7fb49d961700, child_tidptr=0x7fb49d9619d0) = 27370
futex(0x7fb49d9619d0, FUTEX_WAIT, 27370, NULL) = -1 EAGAIN (Resource temporarily unavailable)
exit_group(0) = ?

为什么多个克隆系统调用调用单个 go 子程序？因为在程序中只创建了单个子例程，就像 C 语言的第二个程序中的单个 pthread 一样。其他两个克隆出于什么目的调用？

Answer 1

运行这个空操作程序:

package main

func main() {
}

跟踪克隆调用显示相同的三个 clone 调用:

$ go build nop.go
$ strace -e trace=clone ./nop
clone(child_stack=0xc000060000, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM) = 12602
clone(child_stack=0xc000062000, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM) = 12603
clone(child_stack=0xc00005c000, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM) = 12605
+++ exited with 0 +++

所以你在这里展示的是 Go 能够创建一个没有 克隆调用的 goroutine:

$ cat oneproc.go
package main

func dummy() {
}

func main() {
    go dummy()
}
$ go build oneproc.go
$ strace -e trace=clone ./oneproc
clone(child_stack=0xc000060000, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM) = 13090
clone(child_stack=0xc000062000, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM) = 13091
clone(child_stack=0xc00005c000, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM) = 13092
+++ exited with 0 +++

(这并不奇怪——Goroutines 不是线程)。

Go 运行时(Go 1.11/12-ish)

您要求提供更多详细信息 in comments 。当前系统有一个 design document(如果还没有，毫无疑问会过时)，当然还有 Go runtime source itself。

在 proc.go 的顶部有一个非常有用的(和大的)注释，它讨论了 goroutines(“G”s)如何映射到具有处理器资源(“P”)的工作线程(“M”s)。这与为什么最初有三个 OS clone 调用(总共导致 4 个线程)的原因仅间接相关，但这很重要。请注意，如果和当它看起来有用时，可以并且将在以后创建额外的操作系统级线程，尤其是当 M 阻塞在系统调用中时。

实际的 clone 系统调用发生在 os_linux.go 中的 newosproc 和 newosproc0 中。其他非 Linux 操作系统有自己独立的实现。如果您搜索对 newosproc 的调用，您只会在 proc.go 中的函数 newm1 中找到那个调用。这是从 proc.go 中的另外两个地方调用的:newm 和 templateThread。 templateThread 是一个可能永远不会被使用的特殊助手，并且(我相信)不是三个初始 clone 的一部分，所以我们可以忽略它，只查找对 newm 的调用。其中有 6 个，都在 proc.go 中:

• main 调用 systemstack(func() { newm(sysmon, nil) })。 sysmon也在proc.go中；查看它的作用，部分是为了根据需要触发垃圾收集，部分是为了保持调度程序的其余部分继续运行。

• startTheWorldWithSema，让运行时系统启动，为每个 P 调用 newm(nil, p)。总是至少有一个 P，所以这可能是第二个。但是，有一个初始的 m0 对象，所以这可能不是一个/第二个 clone — 目前还不清楚。

• 在 sigqueue.go 中，signal_enable 调用 sigenable(在 signal_unix.go 中)，这取决于 sigtable(从 sigtab_linux_generic.go 中)中的值绝对正确，最终调用 ensureSigM(也在 signal_unix.go 中)，它调用 LockOSThread，这确保我们将创建另一个 M。 (ensureSigM 闭包中的 go 创建了 G 以绑定(bind)到这个新的锁定到 OS 线程的 M。)因为这些调用是从 init 函数我认为它们发生在 startTheWorldWithSema 之前，因此它在上面提到的循环中创建了额外的 M。它们可能会在启动世界之后发生，但在那种情况下，仍然需要在进入 main 之前创建 M。

所有这一切肯定会导致 两个 线程:一个用于运行 sysmon，一个用于处理信号。它可能会或可能不会解释第三个线程。这一切都是基于阅读代码，而不是实际运行和测试它，因此它可能包含错误。