Question

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

package main

func print() {
}

func main() {
    go print()
}

转到子例程的痕迹

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)                           = ?

可以观察到，有3次克隆系统调用调用了单个子例程，但堆栈大小很小，如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的痕迹

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) = ?

为什么要为单行子程序调用多个克隆系统调用？因为在程序中仅创建了一个子例程，就像在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能够使用 no 克隆调用创建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 +++

（这并不奇怪，Goroutine不是线程）。

运行时（运行1.11 / 12版）

您要求提供其他详细信息in comments。当前系统有一个design document（如果尚未安装，无疑会过时），当然还有Go runtime source itself。

proc.go顶部有一个非常有启发性的（且很大的）注释，它讨论了goroutines（“ G”）如何映射到具有处理器资源的工作线程（“ M”）中。 P”）。这仅与为什么最初要进行三个OS clone调用（导致总共有4个线程）间接相关，但这很重要。请注意，如果看起来有用，则可以在以后创建其他OS级线程，尤其是当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，因此这可能是第二个P。但是，有一个初始的m0对象，因此它可能不是第二个clone-尚不清楚。
在sigqueue.go中，signal_enable调用sigenable（在signal_unix.go中），具体取决于sigtable中的值（来自sigtab_linux_generic.go ）绝对正确，最后会调用ensureSigM（也在signal_unix.go中），后者也会调用LockOSThread，以确保我们将创建另一个M。（其中的go ensureSigM中的闭包创建了G，使其绑定到此新的锁定到OS线程M。）由于这些调用是从init函数触发的，我认为它们发生在startTheWorldWithSema之前以便在上述循环中创建额外的M。它们可能是在开始世界之后发生的，但在那种情况下，仍然需要在输入main之前创建M。

所有这些肯定占了两个线程：一个用于运行sysmon，另一个用于处理信号。它可以考虑也可以不考虑第三线程。都是基于读取代码，而不是实际运行和测试代码，因此可能包含错误。

为什么多个克隆系统调用需要单行子例程？

1 个答案:

运行时（运行1.11 / 12版）