Python 3.1 中的 GIL
有谁知道Python 3.1中全局解释器锁对C++多线程集成的命运
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
有谁知道Python 3.1中全局解释器锁对C++多线程集成的命运
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论（7）
GIL 在 CPython 3.1 中仍然存在； Unladen Swallow 项目的目标（以及许多其他性能提升）最终将其删除，但是它距其目标还有一段距离，并且正在首先开发 2.6，目的是最终将 2.y 版本完成时当前的 x 移植到 3.x。 目前，多处理（而不是线程）仍然是在 CPython 中使用多核的选择方式（IronPython 和 Jython 也很好，但它们目前不支持 Python 3，也不能让 C++ 集成变得那么容易；- ）。
GIL is still there in CPython 3.1; the Unladen Swallow projects aims (among many other performance boosts) to eventually remove it, but it's still a way from its goals, and is working on 2.6 first with the intent of eventually porting to 3.x for whatever x will be current by the time the 2.y version is considered to be done. For now, multiprocessing (instead of threading) remains the way of choice for using multiple cores in CPython (IronPython and Jython are fine too, but they don't support Python 3 currently, nor do they make C++ integration all that easy either;-).
Python 3.2 的 GIL 将发生重大变化。 查看Python 3.2 的新增功能 ，以及在邮件列表中启动它的线程。
虽然这些变化并不意味着 GIL 的终结，但它们预示着潜在的巨大性能提升。
更新
过去 15 年里，人们一直在努力从 CPython 中删除 GIL，但在可预见的未来，它仍将继续存在。
Significant changes will occur in the GIL for Python 3.2. Take a look at the What's New for Python 3.2, and the thread that initiated it in the mailing list.
While the changes don't signify the end of the GIL, they herald potentially enormous performance gains.
Update
Efforts have been made for the last 15 years to remove the GIL from CPython but for the foreseeable future it is here to stay.
GIL 不会影响不使用 python 对象的代码。 在Numpy中，我们发布了用于计算代码（线性代数调用等...）的GIL，底层代码可以自由使用多线程（实际上，那些通常是对python一无所知的第三方库）
The GIL will not affect your code which does not use python objects. In Numpy, we release the GIL for computational code (linear algebra calls, etc...), and the underlying code can use multithreading freely (in fact, those are generally 3rd party libraries which do not know anything about python)
GIL 是个好东西。
只需让您的 C++ 应用程序在执行多线程工作时释放 GIL 即可。 Python 代码将继续在其他线程中运行，不会被破坏。 仅当必须接触 python 对象时才获取 GIL。
The GIL is a good thing.
Just make your C++ application release the GIL while it is doing its multithreaded work. Python code will continue to run in the other threads, unspoiled. Only acquire the GIL when you have to touch python objects.
我想总会有一个GIL。
原因是性能。 使所有低级访问线程安全 - 意味着在每个哈希操作等周围放置互斥体是很繁重的。 请记住，像“Might”这样的简单语句
目前可能已经有至少 3 个（如果 val 是全局的）哈希表查找，如果方法缓存不热（取决于类的继承深度），甚至可能更多，
这是昂贵的 - 那是为什么 Java 放弃了这个想法并引入了不使用监视器调用的哈希表，以摆脱其“Java 很慢”的商标。
I guess there will always be a GIL.
The reason is performance. Making all the low level access thread safe - means putting a mutex around each hash operation etc. is heavy. Remember that a simple statement like
Might already have at least 3 (if val is a global) hashtable lookups at the moment and maybe even much more if the method cache is not hot (depending on the inheritance depth of the class)
It's expensive - that's why Java dropped the idea and introduced hashtables which do not use a monitor call to get rid of its "Java Is Slow" trademark.
据我了解，“brainfuck”调度程序将取代 python 3.2 中的 GIL
BFS bainfuck 调度程序
As I understand it the "brainfuck" scheduler will replace the GIL from python 3.2
BFS bainfuck scheduler
如果 GIL 妨碍，只需使用 multiprocessing 模块。 它生成新进程，但使用线程模型和（大部分）API。 换句话说，您可以以类似线程的方式实现基于进程的并行性。
If the GIL is getting in the way, just use the multiprocessing module. It spawns new processes but uses the threading model and (most of the) api. In other words, you can do process-based parallelism in a thread-like way.