当前位置：文江博客话题详情

Python python-internals gil

Cpython中的全球口译员锁（GIL）是什么？

发布于 2025-01-24 12:41:57 字数 105 浏览 1 评论 0 原文

什么是全球口译员锁，为什么是一个问题？

围绕从Python删除GIL的噪音很多，我想了解为什么这么重要。我自己从未写过编译器，也没有写过翻译，所以不要节俭细节，我可能需要他们理解。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

美人骨 2025-01-31 12:41:57

Python的GIL旨在序列化来自不同线程的解释器内部访问。在多核系统上，这意味着多个线程无法有效利用多个内核。（如果GIL没有导致这个问题，大多数人都不会关心GIL - 仅由于多核系统的患病率的增加而被提出为问题。）如果您想详细了解它，您可以查看此视频或查看这套幻灯片。这可能是太多的信息，但是您确实要求提供详细信息:-)

请注意，Python的GIL确实是Cpython（参考实现）的问题。 Jython和Ironpython没有GIL。作为Python开发人员，除非您正在编写C扩展名，否则通常不会遇到GIL。 C扩展作者需要在扩展程序阻止I/O时释放GIL，以便Python过程中的其他线程有机会运行。

回复收藏 0 原文

杯别 2025-01-31 12:41:57

假设您有多个线程，这些线程真的触摸彼此的数据。这些应该尽可能独立执行。如果您有一个“全局锁”，您需要（例如）调用功能，最终可能会成为瓶颈。首先，您可以从多个线程中获得很多好处。

将其置于现实世界中的类比：想象100名在一家只有一个咖啡杯的公司工作的开发人员。大多数开发人员会花时间等待咖啡而不是编码。

这些都不是特定于Python的 - 我不知道Python首先需要GIL的细节。但是，希望它可以使您对一般概念有更好的了解。

回复收藏 0 原文

夏天碎花小短裙 2025-01-31 12:41:57

让我们首先了解Python GIL提供的内容：

任何操作/指令均在解释器中执行。吉尔确保解释器由特定时间的单个线程持有。带有多个线程的Python程序在单个解释器中起作用。在任何特定的时间，此解释器都由一个线程持有。这意味着只有持有解释器的线程在的任何瞬间上运行。

现在为什么是一个问题：

您的计算机可能有多个内核/处理器。并且多个内核允许多个线程同时执行 ie多线可以在任何特定的时间瞬间执行。。
但是，由于解释器是由单个线程持有的，因此其他线程即使可以访问核心也没有做任何事情。因此，您没有获得多个内核提供的任何优势，因为在任何瞬间，即当前持有解释器的线程使用的核心都在使用。因此，您的程序将需要尽可能长时间执行，就好像它是一个线程程序一样。

但是，可能会阻止或长期运行的操作，例如I/O，图像处理和Numpy Number Crunching，发生在GIL之外。取自在这里。因此，对于此类操作，尽管存在GIL，但多线程操作仍然比单个螺纹操作更快。因此，吉尔并不总是瓶颈。

编辑：GIL是Cpython的实施细节。 Ironpython和Jython没有GIL，因此应该在其中进行真正的多线程程序，以为我从未使用过Pypy和Jython，并且不确定。

回复收藏 0 原文

生生不灭 2025-01-31 12:41:57

python 3.7文档

我还想突出显示以下引用 python 螺纹文档：

cpython实现详细信息：在CPYTHON中，由于全局解释器锁定，只有一个线程可以一次执行Python代码（即使某些面向性能的库可能会克服此限制）。如果您的应用程序可以更好地利用多核机的计算资源，建议您使用多处理或 concurrent.futures.futures.processpoolexecutor 。但是，如果您想同时运行多个I/O结合任务，则线程仍然是合适的模型。

这链接到 Globsary for gromsy> code> global interage> gode>全局解释器锁定/code> 解释说GIL意味着Python中的螺纹并行性不适合 CPU绑定任务：

CPYTHON解释器使用的机制确保仅一个线程一次执行Python字节码。通过使对象模型（包括关键的内置类型（例如DICE））隐含地安全防止并发访问来简化CPYTHON实现。锁定整个解释器使解释器更容易被多线程，而牺牲了多处理器机器提供的许多并行性。

然而，某些扩展模块（标准或第三方都可以）设计为在执行计算密集型任务（例如压缩或哈希）时释放GIL。另外，GIL在执行I/O。

时总是会释放

过去为创建“自由线程”的解释器（将数据锁定在更细的粒度上）的努力并没有成功，因为在常见的单处理器案例中性能受到了影响。人们认为，克服这个绩效问题将使实施更加复杂，因此维护更为昂贵。

该报价还意味着dicts，因此可变分配也可以安全地作为CPYTHON实现细节：

python变量分配原子？
python词典中的线程安全

， 多处理解释如何通过产卵过程来克服GIL，同时公开类似于螺纹的接口：

多处理是一个软件包，该软件包使用类似于螺纹模块的API支持产卵过程。多处理软件包提供本地和远程并发性，通过使用子过程而不是线程有效地侧向全局解释器锁定。因此，多处理模块允许程序员完全利用给定计算机上的多个处理器。它在Unix和Windows上都运行。

和说明它使用多处理作为后端：

ProcessPoolExecutor类是一个执行人子类，它使用流程库来异步执行呼叫。 ProcessPoolExecutor使用多处理模块，该模块允许其侧键入全局解释器锁定，但也意味着只能执行并返回可挑选对象。

应与其他基类 threadpoolexecutor 形成鲜明对比，使用线程代替过程

threadpoolexecutor是一个执行程序子类，使用线程池异步执行呼叫。

从中，我们得出结论， threadpoolexecutor 仅适用于I/O绑定的任务，而 ProcessPoolExecutor 也可以处理CPU绑定的任务。

处理与线程实验

我已经对Python中的过程与线程进行了实验分析。

结果快速预览：

在其他语言中

该概念似乎也存在于Python之外，也将其应用于Ruby： https://en.wikipedia.org/wiki/wiki/global_inter_inter_interpreter_lock_lock

它提到了预期：

提高了单程读取程序的速度（提高了单程读取的程序的速度（增加速度）无需分别在所有数据结构上获取或释放锁），
简单地集成通常不是线程安全的C库，
易于实现（拥有一个GIL比无锁的解释器或使用Fine Fine更容易实现 - 锁锁）。

但是JVM似乎没有GIL就可以了，所以我想知道这是否值得。以下问题询问为什么吉尔首先存在：为什么全局解释器锁？

Python 3.7 documentation

I would also like to highlight the following quote from the Python threading documentation:

CPython implementation detail: In CPython, due to the Global Interpreter Lock, only one thread can execute Python code at once (even though certain performance-oriented libraries might overcome this limitation). If you want your application to make better use of the computational resources of multi-core machines, you are advised to use multiprocessing or concurrent.futures.ProcessPoolExecutor. However, threading is still an appropriate model if you want to run multiple I/O-bound tasks simultaneously.

This links to the Glossary entry for global interpreter lock which explains that the GIL implies that threaded parallelism in Python is unsuitable for CPU bound tasks:

The mechanism used by the CPython interpreter to assure that only one thread executes Python bytecode at a time. This simplifies the CPython implementation by making the object model (including critical built-in types such as dict) implicitly safe against concurrent access. Locking the entire interpreter makes it easier for the interpreter to be multi-threaded, at the expense of much of the parallelism afforded by multi-processor machines.

However, some extension modules, either standard or third-party, are designed so as to release the GIL when doing computationally-intensive tasks such as compression or hashing. Also, the GIL is always released when doing I/O.

Past efforts to create a “free-threaded” interpreter (one which locks shared data at a much finer granularity) have not been successful because performance suffered in the common single-processor case. It is believed that overcoming this performance issue would make the implementation much more complicated and therefore costlier to maintain.

This quote also implies that dicts and thus variable assignment are also thread safe as a CPython implementation detail:

Next, the docs for the multiprocessing package explain how it overcomes the GIL by spawning process while exposing an interface similar to that of threading:

multiprocessing is a package that supports spawning processes using an API similar to the threading module. The multiprocessing package offers both local and remote concurrency, effectively side-stepping the Global Interpreter Lock by using subprocesses instead of threads. Due to this, the multiprocessing module allows the programmer to fully leverage multiple processors on a given machine. It runs on both Unix and Windows.

And the docs for concurrent.futures.ProcessPoolExecutor explain that it uses multiprocessing as a backend:

The ProcessPoolExecutor class is an Executor subclass that uses a pool of processes to execute calls asynchronously. ProcessPoolExecutor uses the multiprocessing module, which allows it to side-step the Global Interpreter Lock but also means that only picklable objects can be executed and returned.

which should be contrasted to the other base class ThreadPoolExecutor that uses threads instead of processes

ThreadPoolExecutor is an Executor subclass that uses a pool of threads to execute calls asynchronously.

from which we conclude that ThreadPoolExecutor is only suitable for I/O bound tasks, while ProcessPoolExecutor can also handle CPU bound tasks.

Process vs thread experiments

At Multiprocessing vs Threading Python I've done an experimental analysis of process vs threads in Python.

Quick preview of the results:

In other languages

The concept seems to exist outside of Python as well, applying just as well to Ruby for example: https://en.wikipedia.org/wiki/Global_interpreter_lock

It mentions the advantages:

increased speed of single-threaded programs (no necessity to acquire or release locks on all data structures separately),
easy integration of C libraries that usually are not thread-safe,
ease of implementation (having a single GIL is much simpler to implement than a lock-free interpreter or one using fine-grained locks).

but the JVM seems to do just fine without the GIL, so I wonder if it is worth it. The following question asks why the GIL exists in the first place: Why the Global Interpreter Lock?

回复收藏 0 原文

孤君无依 2025-01-31 12:41:57

Python不允许在单词最真实的意义上进行多线程。它具有多线程包，但是如果您想多线程来加快代码的加快，那么使用它通常不是一个好主意。 Python有一个称为全球口译员锁（GIL）的结构。

https://www.youtube.com/watch?v=ph374fjqfpe

只有一个“线程”可以在任何时候执行。线程获取吉尔，做一些工作，然后将吉尔传递到下一个线程上。这很快就会发生，因此在人的眼中，您的线程似乎在并联执行，但实际上它们只是使用相同的CPU核心进行轮流。所有这些吉尔传递都为执行增加了开销。这意味着，如果您想使代码运行速度更快，那么通常使用线程软件包并不是一个好主意。

有理由使用Python的线程包。如果您想同时运行某些事情，而效率也不关心，那么它就可以完全方便。或者，如果您正在运行需要等待某些东西（例如某些IO）的代码，那么这可能很有意义。但是线程库不会让您使用额外的CPU内核。

可以将多线程外包到操作系统（通过进行多处理），一些调用您的Python代码的外部应用程序（例如，Spark或Hadoop）或一些Python代码调用的代码（例如，您可以拥有Python代码调用C函数，可执行昂贵的多线程功能）。

回复收藏 0 原文

月棠 2025-01-31 12:41:57

每当两个线程访问相同变量时，您都会出现问题。
例如，在C ++中，避免问题的方法是定义一些静音锁，以防止两个线程同时输入对象的设置器。

python中可以进行多线程，但是不能同时执行两个线程
粒度比一份python指令更细。
运行线程正在获得一个名为GIL的全局锁。

这意味着，如果您开始编写一些多线程代码以利用多核处理器，则性能将无法改善。
通常的解决方法包括进行多进程。

请注意，如果您在C中写的方法中，则可以释放GIL。

GIL的使用不是Python固有的，而是其某些解释器，包括最常见的Cpython。
（#edited，请参阅评论）

GIL问题在Python 3000中仍然有效。

回复收藏 0 原文

榕城若虚 2025-01-31 12:41:57

为什么Python（Cpython等）

从。

该锁定是必要的，主要是因为Cpython的内存管理不是线程安全。

如何从Python中删除它？

像Lua一样，也许Python可以启动多个VM，但是Python不这样做，我想还有其他原因。

在Numpy或其他一些Python扩展库中，有时将GIL释放到其他线程可能会提高整个程序的效率。

回复收藏 0 原文

π浅易 2025-01-31 12:41:57

我想分享一本书多线程的示例，以获得视觉效果。因此，这里是经典的死锁状况

static void MyCallback(const Context &context){
Auto<Lock> lock(GetMyMutexFromContext(context));
...
EvalMyPythonString(str); //A function that takes the GIL
...    
}

，现在考虑到序列中的事件，导致了死锁。

╔═══╦════════════════════════════════════════╦══════════════════════════════════════╗
║   ║ Main Thread                            ║ Other Thread                         ║
╠═══╬════════════════════════════════════════╬══════════════════════════════════════╣
║ 1 ║ Python Command acquires GIL            ║ Work started                         ║
║ 2 ║ Computation requested                  ║ MyCallback runs and acquires MyMutex ║
║ 3 ║                                        ║ MyCallback now waits for GIL         ║
║ 4 ║ MyCallback runs and waits for MyMutex  ║ waiting for GIL                      ║
╚═══╩════════════════════════════════════════╩══════════════════════════════════════╝

I want to share an example from the book multithreading for Visual Effects. So here is a classic dead lock situation

static void MyCallback(const Context &context){
Auto<Lock> lock(GetMyMutexFromContext(context));
...
EvalMyPythonString(str); //A function that takes the GIL
...    
}

Now consider the events in the sequence resulting a dead-lock.

╔═══╦════════════════════════════════════════╦══════════════════════════════════════╗
║   ║ Main Thread                            ║ Other Thread                         ║
╠═══╬════════════════════════════════════════╬══════════════════════════════════════╣
║ 1 ║ Python Command acquires GIL            ║ Work started                         ║
║ 2 ║ Computation requested                  ║ MyCallback runs and acquires MyMutex ║
║ 3 ║                                        ║ MyCallback now waits for GIL         ║
║ 4 ║ MyCallback runs and waits for MyMutex  ║ waiting for GIL                      ║
╚═══╩════════════════════════════════════════╩══════════════════════════════════════╝

回复收藏 0 原文

~没有更多了~