python - linux下Python的time.sleep(0)的行为——它会导致上下文切换吗？

Question

这种模式经常出现，但我找不到直接的答案。

一个非关键的、不友好的程序可能会这样做

while(True):
    # do some work

使用其他技术和平台，如果你想让这个程序热运行(使用尽可能多的 CPU 周期)但要礼貌 - 允许其他热运行的程序有效地减慢我的速度，你会经常写:

while(True):
    #do some work
    time.sleep(0)

我已经阅读了关于后一种方法是否会在 python 上实现我希望在 linux 机器上运行的相互矛盾的信息。是否会导致上下文切换，导致我上面提到的行为？

编辑:值得一提的是，我们在 Apple OSX 中尝试了一个小实验(手边没有 linux 机器)。这个盒子有 4 个内核和超线程，所以我们只用了 8 个程序就创建了一个

while(True):
    i += 1

正如预期的那样，事件监视器将 8 个进程中的每一个显示为消耗超过 95% 的 CPU(显然使用 4 个内核和超线程，您总共得到 800%)。然后我们启动了第九个这样的程序。现在所有 9 个都运行在 85% 左右。现在杀死第九个人并用

启动一个程序

while(True):
    i += 1
    time.sleep(0)

我希望这个过程使用接近 0%，而其他 8 个将运行 95%。但相反，所有九个都运行在 85% 左右。所以在 Apple OSX 上， sleep(0) 似乎没有效果。

Answer 1

我从来没有想过这个，所以我写了这个脚本:

import time

while True:
    print "loop"
    time.sleep(0.5)

只是作为一个测试。使用 strace -o isacontextswitch.strace -s512 python test.py 运行它会在循环中为您提供以下输出:

write(1, "loop\n", 5)                   = 5
select(0, NULL, NULL, NULL, {0, 500000}) = 0 (Timeout)
write(1, "loop\n", 5)                   = 5
select(0, NULL, NULL, NULL, {0, 500000}) = 0 (Timeout)
write(1, "loop\n", 5)                   = 5
select(0, NULL, NULL, NULL, {0, 500000}) = 0 (Timeout)
write(1, "loop\n", 5)                   = 5
select(0, NULL, NULL, NULL, {0, 500000}) = 0 (Timeout)
write(1, "loop\n", 5)  

select()是一个系统调用，所以是的，您是上下文切换(从技术上讲，当您更改到内核空间时，实际上不需要上下文切换，但是如果您有其他进程正在运行，那么您在这里所说的是除非您准备好数据要读取您的文件描述符，其他进程可以在此之前运行)进入内核以执行此操作。有趣的是，延迟在于选择标准输入。如果他们愿意，这允许 python 中断您对诸如 ctrl+c 输入等事件的输入，而不必等待代码超时 - 我认为这非常简洁。

我应该注意到，这同样适用于 time.sleep(0)，只是传入的时间参数是 {0,0}。而且这种自旋锁定对于非常短的延迟来说并不理想 - multiprocessing和 threads提供等待事件对象的能力。

编辑:所以我看看 linux 到底做了什么。 do_select (fs\select.c) 中的实现进行此检查:

if (end_time && !end_time->tv_sec && !end_time->tv_nsec) {
    wait = NULL;
timed_out = 1;
}

if (end_time && !timed_out)
    slack = select_estimate_accuracy(end_time);

换句话说，如果提供了结束时间并且两个参数都为零(!0 = 1 并且在 C 中计算为 true)，则等待设置为 NULL，并且选择被视为超时。但是，这并不意味着该函数会返回给您；它循环遍历您拥有的所有文件描述符并调用 cond_resched，从而可能允许另一个进程运行。换句话说，发生什么完全取决于调度器；如果您的进程与其他进程相比一直在占用 CPU 时间，则可能会发生上下文切换。如果没有，您所在的任务(内核 do_select 函数)可能会继续执行，直到完成。

不过，我要重申，对其他进程更好的最佳方式通常是使用自旋锁以外的其他机制。