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