问题标签 [gil]

所以我刚刚看完了关于 Python Global Interpreter Lock (GIL) http://blip.tv/file/2232410的演讲。

它的要点是 GIL 对于单核系统来说是一个非常好的设计（Python 基本上将线程处理/调度留给了操作系统）。但这在多核系统上可能会严重适得其反，最终导致 IO 密集型线程被 CPU 密集型线程严重阻塞、上下文切换的代价、ctrl-C 问题 [*] 等等。

因此，由于 GIL 限制我们基本上只能在一个 CPU 上执行 Python 程序，我的想法是为什么不接受这一点并简单地使用 Linux 上的任务集来将程序的亲和性设置为系统上的某个核心/cpu（尤其是在在多核系统上运行多个 Python 应用程序）？

所以最终我的问题是：有没有人尝试过在 Linux 上使用带有 Python 应用程序的任务集（尤其是在 Linux 系统上运行多个应用程序时，以便可以将多个内核与绑定到特定内核的一个或两个 Python 应用程序一起使用），如果是这样的话结果是什么？值得吗？对于某些工作负载，它会使情况变得更糟吗？我计划这样做并对其进行测试（基本上是看看程序是否需要更多或更少的时间来运行），但我很想听听其他人的经验。

补充：David Beazley（在链接视频中发表演讲的人）指出，一些 C/C++ 扩展手动释放 GIL 锁，如果这些扩展针对多核（即科学或数字数据分析等）进行了优化，那么而不是获得多核的好处来处理数字，扩展将被有效地削弱，因为它仅限于单核（因此可能会显着减慢您的程序速度）。另一方面，如果您不使用这样的扩展

我不使用多处理模块的原因是（在这种情况下）程序的一部分是严重的网络 I/O 绑定（HTTP 请求），因此拥有一个工作线程池是一种很好的方式来提高性能，因为一个线程触发一个 HTTP 请求，然后因为它在等待 I/O 放弃了 GIL，另一个线程可以做到这一点，所以程序的一部分可以轻松运行 100 多个线程而不会对 CPU 造成太大伤害，让我实际使用可用的网络带宽。至于无堆栈 Python/etc，我对重写程序或替换我的 Python 堆栈并不太感兴趣（可用性也是一个问题）。

[*] 只有主线程可以接收信号，所以如果你发送一个 ctrl-C，Python 解释器基本上会尝试让主线程运行以便它可以处理信号，但是因为它不直接控制运行哪个线程（这留给操作系统）它基本上告诉操作系统继续切换线程，直到它最终到达主线程（如果你不走运可能需要一段时间）。

我希望有人可以提供一些关于 Java 虚拟机的根本不同之处的见解，它允许它很好地实现线程而不需要全局解释器锁 (GIL)，而 Python 需要这样一个邪恶。

有人知道 Python 3.1 中 Global Interpreter Lock 对 C++ 多线程集成的命运吗

什么是全局解释器锁，为什么会出现问题？

从 Python 中删除 GIL 引起了很多争论，我想了解为什么这如此重要。我自己从来没有写过编译器或解释器，所以不要吝啬细节，我可能需要他们理解。

我有一个用 C++ 编写的库，我使用 SWIG 包装并在 python 中使用。通常只有一个类，方法很少。问题是调用这些方法可能很耗时——它们可能会挂起我的应用程序（调用这些方法时不会释放 GIL）。所以我的问题是：

为这些方法调用释放 GIL 的最简单方法是什么？

（我知道如果我使用 C 库，我可以用一些额外的 C 代码来包装它，但这里我使用 C++ 和类）

我经常看到人们说 GIL 是基于 Python 解释器的（即使在 stackoverflow 上也是如此）。

但是我在源代码中看到的似乎是 GIL 是一个全局变量，因此每个 python 进程中的所有解释器都有一个 GIL。我知道他们这样做是因为没有像 lua 或 TCL 那样传递的解释器对象，只是一开始设计得不好。并且线程本地存储对于 python 家伙来说似乎是不可移植的。

它是否正确？我在这里简要了解了我在项目中使用的 2.4 版本。

这在以后的版本中是否发生了变化，尤其是在 3.0 中？

python GIL 的存在是否意味着在 python 多线程中相同的操作与在单个线程中重复它没有太大区别？

例如，如果我需要上传两个文件，那么在两个线程中进行而不是一个接一个地上传它们有什么好处？

我尝试了两种方式的大型数学运算。但它们似乎需要几乎相同的时间才能完成。

这对我来说似乎不清楚。有人可以帮我吗？谢谢。

我刚刚在 Hacker News 上看到了 Unladen Swallow 文档的这一部分。基本上，是谷歌工程师说他们对删除 GIL 并不乐观。然而，似乎有关于垃圾收集器的讨论穿插在关于 GIL 的讨论中。有人可以和我解释一下这种关系吗？

我正在阅读有关在 Python 3.2 中找到/将要找到的新 GIL 的此页面，我想知道它是否是触发从 Python 2.x 过渡到 3.x 的“杀手级功能”。

你们有什么感想？

在 Python C 扩展中操作 GIL 的最简单方法是使用提供的宏：

这很好用，让我为我的大部分代码释放 GIL，但为需要它的少量代码重新获取它。

问题是当我用 gcc 编译它时，我得到：

因为 Py_BEGIN_ALLOW_THREADS 是这样定义的：

所以，三个问题：

1. 是否可以抑制 gcc 的警告，
2. 有谁知道为什么 gcc 认为_save可能未初始化使用，因为它是在声明后立即分配的，并且
3. 为什么没有定义宏来在一个语句中声明和初始化变量以避免该问题？

（最后两个真的只是为了我自己的好奇心）。

我可以通过不使用宏并自己做所有事情来避免这个问题，但我宁愿不这样做。