gpt4 book ai didi

centos7中的上下文切换延迟

转载 作者:塔克拉玛干 更新时间:2023-11-03 00:14:04 26 4
gpt4 key购买 nike

在我的 C 应用程序中,主进程派生一个子进程,然后休眠十微秒,让子进程有时间做好准备。休眠期结束后,父进程向子进程发送信号,开始监听指定端口。

此代码在 CentOS6 中执行良好,只有少数情况下 sleep 时间不足以让子进程在传递来自父进程的信号之前设置其信号处理程序。然而,当此代码在具有相同系统规范的 CentOS7 中运行时, child 始终未能及时安装其信号处理程序。我必须将 sleep 时间增加到 10 毫秒(长 1000 倍)才能获得与 CentOS6 中相同的性能。

我想知道在相同规范的硬件上,相对于 CentOS 6,在 CentOS 7 中上下文切换如此缓慢的原因可能是什么?

最佳答案

进程/线程调度由操作系统内核自行决定。 CentOS 7 使用与 CentOS 6 不同的内核。

无论如何,这根本不一定是上下文切换问题。上下文切换适用于共享相同 CPU [核心] 的线程/进程,但如今单核 CPU 很少见,至少在您期望找到 CentOS 的机器类别中是这样。事实上,问题可能是 child 最初是否被安排在与 parent 相同的核心上,如果是,则首先从 fork() 返回。

假设,例如,在 CentOS 6 上,子进程和父进程通常最终(最初)安排在同一个核心上,子进程首先获得该核心。在这种情况下,只要子进程在它首先让出 CPU 之前设置好信号处理程序,父进程就根本不需要延迟。另一方面,如果在 CentOS 7 上,子进程通常最初被安排在不同的核心上,并且两个进程都立即进行,那么之前实际上无关紧要的延迟突然变得重要了。顺便说一句,按照大多数衡量标准,这将是一种性能改进。

当然,所有这些都是推测性的。主要问题是您的方法存在严重缺陷。 parent 不应该试图猜测 child 什么时候会准备好。相反,它应该等待 child 宣布它准备好了。 child 可以通过管道或通过向 parent 发送信号来执行此操作,或者更好的是,他们可以通过共享信号量或互斥量(毕竟这些对象的用途)进行同步。

关于centos7中的上下文切换延迟,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/32993386/

26 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com