python - 为什么线程分布在 CPU 之间？

Question

我正在努力了解线程与 CPU 使用率的关系。有很多关于线程与多处理的讨论(一个很好的概述是 this answer )所以我决定通过在运行 Windows 10、Python 3.4 的 8 CPU 笔记本电脑上启动最大线程数来测试这一点。

我的假设是所有线程都将绑定(bind)到一个 CPU。

编辑:事实证明这不是一个好的假设。我现在明白，对于多线程代码，一次只能一个 python 代码运行(无论在哪里/在哪个内核上)。这与多处理代码不同(其中进程是独立的并且确实是独立运行的)。
当我读到这些差异时，它是 one answer这实际上澄清了这一点。

我认为这也解释了下面的 CPU View :它是分布在许多 CPU 上的许多线程的平均 View ，但只有其中一个在给定时间运行(对所有运行所有线程的“平均”)时间)。

它不是链接问题的副本(它解决了相反的问题，即一个核心上的所有线程)，我会把它挂起来，以防有一天有人有类似的问题，并希望能得到我的启发。

---

代码

import threading
import time


def calc():
    time.sleep(5)
    while True:
        a = 2356^36

n = 0
while True:
    try:
        n += 1
        t = threading.Thread(target=calc)
        t.start()
    except RuntimeError:
        print("max threads: {n}".format(n=n))
        break
    else:
        print('.')

time.sleep(100000)

导致启动了 889 个线程。

然而，CPU 上的负载是分散的(对于纯 CPU 计算来说，负载低得惊人，否则笔记本电脑在不运行我的脚本时会空载):

为什么会这样？线程是否作为一个包在 CPU 之间不断移动，而我看到的只是一个平均值(实际情况是在给定时刻所有线程都在一个 CPU 上)？或者它们确实是分布式的？

Answer 1

时至今日，“一个线程拥有 GIL”的情况仍然存在。因此一次运行一个线程。

线程在操作系统级别进行管理。发生的情况是每 100 个“滴答”(=解释器指令)运行的线程释放 GIL 并重置滴答计数器。

因为本例中的线程进行连续计算，很快就达到了 100 条指令的节拍限制，导致 GIL 几乎立即释放，并且线程之间的“战斗”开始获取 GIL。

因此，我的假设是您的操作系统的负载高于预期，因为(太)快速的线程切换 + 几乎连续释放和获取 GIL。操作系统花在切换上的时间比实际做任何有用的计算都多。

正如您自己提到的，要一次使用多个内核，最好查看多处理模块(joblib/Parallel)。

有趣的阅读: http://www.dabeaz.com/python/UnderstandingGIL.pdf