为什么父进程中的 printf() 在 fork() 之后几乎总是赢得竞争条件？

如何解决为什么父进程中的 printf() 在 fork() 之后几乎总是赢得竞争条件？

有一个有点著名的 Unix 脑筋急转弯：写一个 if 表达式，让下面的程序在屏幕上打印 Hello,world!。 expr 中的 if 必须是合法的 C 表达式，并且不应包含其他程序结构。

if (expr)
    printf("Hello,");
else
    printf("world!\n");

答案是fork()。

小时候，我只是笑了笑就忘了。但是重新思考它，我发现我无法理解为什么这个程序比它应该的可靠得惊人。无法保证 fork() 之后的执行顺序并且存在竞争条件，但在实践中，您几乎总是看到 Hello,world!\n，而不是 world!\nHello,。

为了证明这一点，我运行了 100,000 轮程序。

for i in {0..100000}; do
    ./fork >> log
done

在 Linux 5.9 (Fedora 32,gcc 10.2.1,-O2) 上，执行 100001 次后，孩子只赢了 146 次，父母获胜概率为 99.9985%。

$ uname -a
Linux openwork 5.9.14-1.qubes.x86_64 #1 SMP Tue Dec 15 17:29:47 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

$ wc -l log
100001 log

$ grep ^world log | wc -l
146

在 FreeBSD 12.2 (clang 10.0.1,-O2) 上的结果是相似的。孩子只赢了 68 次，占 0.00067%，而父母赢了 99.993%。

一个有趣的旁注是 ktrace ./fork 立即将主要结果更改为 world\nHello,（因为仅跟踪父项），证明了问题的 Heisenbug 性质。尽管如此，通过 ktrace -i ./fork 跟踪两个进程会恢复行为，因为两个进程都被跟踪并且同样缓慢。

$ uname -a
FreeBSD freebsd 12.2-RELEASE-p1 FreeBSD 12.2-RELEASE-p1 GENERIC  amd64

$ wc -l log 
100001 log

$ grep ^world log | wc -l
68

独立于缓冲？

一个答案表明缓冲可以影响这种竞争条件的行为。但是从 printf() 中删除 \n 后，该行为仍然存在。

if (expr)
    printf("Hello");
else
    printf("World");

并在 FreeBSD 上通过 stdbuf 关闭 stdout 的缓冲。

for i in {0..10000}; do
    stdbuf -i0 -o0 -e0 ./fork >> log
    echo > log
done

$ wc -l log 
10001 log

$ grep -v "^HelloWorld" log | wc -l
30

为什么在实践中，printf() 之后父级中的 fork() 几乎总是赢得竞争条件？是否与C标准库中printf()的内部实现细节有关？ write() 系统调用？或者 Unix 内核中的进程调度？

解决方法

当fork被执行时，执行它的进程（新的父进程）正在执行（当然），而新创建的子进程则不是。要让子进程运行，要么必须停止父进程并为子进程分配处理器，要么必须在另一个处理器上启动子进程，这需要时间。同时，父进程继续执行。

除非发生一些不相关的事件，例如父级耗尽了它为共享处理器而提供的时间片，否则它会赢得比赛。

当您执行 printf(3) 以将字符串输出到终端（对于任何 tty 设备，这会在 stdio 包内通过 isatty(3) 调用进行检查），{ {1}} 包在行模式缓冲中工作，这意味着在将输出写入终端之前累积输出的内部缓冲区会刷新缓冲区：

如果缓冲区完全填满（这不会发生，因为字符串太短，而缓冲区通常是最佳性能大小或大约 16kb ---这是 BSD unix 中 ufs2 文件系统的值）,或者...
如果输出包含 stdio 行分隔符（这只发生在父代码中，见下文）刷新发生在 \n 的位置。

由于您的父代码（收到子进程的 \n 进程 ID 的代码）是使用包含的 pid_t 字符执行 printf(3) 的代码，因此它的缓冲区在\n 调用的执行时间，而子进程的缓冲区将在 printf() 系统调用时刷新，作为 exit(3) 处理的一部分。您可以通过在父和子中调用 atexit(3)（不调用 at-exit 处理程序的 _exit(2) 版本）来测试这一点，您将看到只有父输出可见在屏幕上。

正如您所说，存在竞争条件，因此如果子进程执行到最后，则在父进程有时间执行其 exit(3) 之前，您可以在最后获得父进程的输出（只需在父代码中，在 printf(3) 之前放置一个 sleep(3) 调用，您就会看到正确的顺序。最重要的是，第一个启动它的 printf(3) 系统调用的进程将成为赢家（因为在执行 write(2) syscal 期间 inode 被锁定，并且输出是有序的）。但是父进程只执行它的代码，中间没有任何系统调用，而子进程的序列是将字符串存储在缓冲区中，并在从 write(2) 返回后调用 atexit(3) 函数列表时刷新它。这可能同时涉及多个系统调用，甚至可能阻塞进程一会儿。

您也可以在子代码中放置一个main()，很可能您可以看到子进程正在被调度并在父进程之前启动\n，尽管父进程仍然有可能将继续获胜，因为它很可能在允许孩子开始之前被安排（这是因为启动 write() 的父级只执行它的第一部分，例如检查创建子级和创建的权限新进程表条目为其提供了从 fork 返回所需的子进程 pid 编号，允许父进程 fork(2) 在子进程 ID 已知后立即返回，同时将内存段分配给新进程和准备它执行是在孩子的 fork(2) 后半部分完成的。这意味着当父母已经以最高速度运行到 fork() 时，孩子很可能会从 fork() 调用返回调用。但你无法控制它。

为什么父进程中的 printf() 在 fork() 之后几乎总是赢得竞争条件？

如何解决为什么父进程中的 printf() 在 fork() 之后几乎总是赢得竞争条件？

独立于缓冲？

解决方法

相关推荐