在 Python 中，threading.Thread 如何产生剩余的量程？

Question

我有一个正在轮询硬件的线程。

while not hardware_is_ready():
    pass
process_data_from_hardware()

但还有其他线程（和进程！）可能有事情要做。 如果是这样，我不想在每隔一条指令检查硬件时消耗CPU。 自从我处理线程以来已经有一段时间了，当我处理线程时，它不是Python，但我相信大多数线程库都有一个yield函数或允许线程告诉调度程序的东西“给其他线程一个机会。”

while not hardware_is_ready():
    threading.yield()          # This function doesn't exist.
process_data_from_hardware()

但我在线程文档中找不到任何类似的参考。 Python 确实有一个 yield 语句，但我很确定那完全是另一回事（与生成器有关）。

这里正确的做法是什么？

Answer 1

time.sleep(0) 足以产生控制——无需使用正 epsilon。 事实上，time.sleep(0) 的意思是“屈服于任何其他可能准备好的线程”。

Answer 2

阅读全局解释器锁 (GIL)。

例如： http://jessenoller.com /2009/02/01/python-threads-and-the-global-interpreter-lock/

另外：http://www.pyzine.com/Issue001/Section_Articles/article_ThreadingGlobalInterpreter.html

如果您必须执行忙等待（例如轮询设备），请在代码中执行此操作）。

time.sleep( 0.0001 )

这将让位于线程调度程序。

另外，我在 http://homepage 中收集了一些注释和参考文献。 mac.com/s_lott/iblog/architecture/C551260341/E20081031204203/index.html

Answer 3

为什么 time.sleep(0) 中的产量可能不够：

我遇到了类似的问题，最终 time.sleep(0) 并非在所有情况下都有效，而 <代码> time.sleep（0.0001）有效。
就我而言，我使用标准的 vanilla cpython - 可以在 python.org 上找到。
查看 C 代码中 sleep 函数的实现，可以发现 sleep(0) 的调用和 sleep(something_other_than_null) 的调用之间存在微小差异。

查看 timemodule.c 中的 pysleep 你会看到在第一种情况下

if (ul_millis == 0 || !_PyOS_IsMainThread()) {
  Py_BEGIN_ALLOW_THREADS
  Sleep(ul_millis);
  Py_END_ALLOW_THREADS
  break;
}

被称为。 “允许线程”释放 GIL，在这种情况下 Sleep(0) 相当于 std::this_thread::yield()，之后 GIL 再次被声明。
在处理非零值的代码中，除了实际的睡眠/等待之外，还有对 PyErr_CheckSignals - 如其文档中所述“检查信号是否已发送到进程，如果是，则调用相应的信号处理程序”。 这可以解释为什么在某些情况下使用硬件时 time.sleep(0) 是不够的。 所以这可能是 cpython 实现方面的一个失误。 这就是为什么 time.sleep(0.0001) 神奇地起作用。

Answer 4

如果您在 *nix 上执行此操作，您可能会发现 select 库很有用。 Kamaela 还有一些您可能会觉得有用的组件，但可能需要进行一些范式更改。