在我的 C 应用程序中，主进程派生出一个子进程，然后休眠 10 微秒，让子进程有时间做好准备。休眠期过后，父进程向子进程发送信号，开始监听指定端口。
这段代码在 CentOS6 中执行良好，只有少数情况下睡眠时间不足以让子进程在传递来自父进程的信号之前设置其信号处理程序。然而，当这段代码在具有相同系统规范的 CentOS7 中运行时，孩子始终未能及时安装其信号处理程序。我必须将睡眠时间增加到 10 毫秒（长 1000 倍）才能获得与 CentOS6 相同的性能。
我想知道在相同规格的硬件上相对于 CentOS 6 在 CentOS 7 中上下文切换如此缓慢的原因可能是什么？
进程/线程调度由操作系统内核决定。CentOS 7 使用与 CentOS 6 不同的内核。
无论如何，这根本不一定是上下文切换问题。上下文切换适用于共享相同 CPU [核心] 的线程/进程，但如今单核 CPU 很少见，至少在您希望找到 CentOS 的机器类别上如此。事实上，问题可能是孩子最初是否被安排在与父母相同的核心上，如果是，则首先从fork().
例如，假设在 CentOS 6 上，孩子和父母通常最终（最初）安排在同一个核心上，孩子首先获得该核心。在这种情况下，只要子进程在第一次让出 CPU 之前设置好它的信号处理程序，父进程就根本不需要延迟。另一方面，如果在 CentOS 7 上，子进程最初通常被安排在不同的核心上，并且两个进程都会立即进行，那么之前实际上并不重要的延迟突然变得重要了。顺便说一句，这将是大多数措施的性能改进。
当然，所有这些都是推测性的。主要问题是您的方法存在严重缺陷。父母不应该试图猜测孩子什么时候准备好。相反，它应该等待孩子宣布准备就绪。孩子可以通过管道或通过向父母发出信号来做到这一点，或者更好的是，他们可以通过共享信号量或互斥锁（毕竟这些对象的用途）进行同步。
不同编译的内核表现不同。你不能依赖时间间隔来处理这些事情。既然您在父母中安装了信号处理程序，为什么不直接反转逻辑：当孩子准备好时，它可以向父母发送信号，然后父母可以开始控制孩子 - 没有人忙着睡觉，一切都是事件驱动的