在我的印象中，当谈到提高 IPC 性能或降低所涉及的延迟时，上下文切换似乎是最重要的因素。但我一直想知道为什么我从来没有听说过可运行进程的数量也是一个因素？
如果我理解正确的话，大多数现代 CPU 都可以通过硬件执行上下文切换，这应该会大大减少浪费的时间。另一方面，CPU 时间由系统中所有可运行的进程共享。系统中可运行的进程越多，进程获得 CPU 控制权的频率就越低。（虽然一般来说大部分进程大部分时间都应该处于睡眠状态，但这只是系统的一个不合理的假设，不能适用于我认为的所有可能的情况。）
例如，假设一个系统被配置为具有循环调度器、1ms 的时间片和 7 个具有相同优先级的可运行进程，如下所示：
P1 P2 P3 P4 P5 P6 P7
根据循环调度的定义，上下文切换顺序应该是：
P1 -> P2 -> P3 -> P4 -> P5 -> P6 -> P7 -> P1 -> P2 -> ... -> P6 -> P7 -> P1 -> P2 -> ... -> P7 -> P1 -> ... and so on
由于上面的上下文切换顺序，如果 P1 尝试通过某种 IPC 机制向 P5 发送消息，则消息将在 3ms 后由 P5 处理。这是因为 P5 需要等待 P2、P3 和 P4 用完自己的时间片，所以 P5 最终被安排运行并处理 P1 发送的消息。因此，在这种情况下，IPC 延迟至少为 3ms，与上下文切换所需的时间（通常为 µs 数量级）相比要大得多！如果 P5 想要对 P1 发送的消息进行回复，又浪费了 2ms，因为 P6 和 P7 必须提前完成轮到。往返延迟时间（https://en.wikipedia.org/wiki/Round-trip_delay_time）应该是：3ms + 2ms = 5ms！
如果可运行进程的数量增加如下：
P1 P2 P3 ... P99 P100
从 P13 发送到 P57 的消息的 IPC 延迟将为：(57 - 13 - 1)ms = 43ms
总而言之……上述问题真的存在吗？在测试或测量 IPC 性能时是否会考虑可运行进程的数量？或者为什么系统中可运行进程的数量与 IPC 性能/延迟无关？