What is the GIL (Global interpreter Lock) Globe interpreter lock in Python? __python

The article welcomes reprint, but when reprint, please keep this paragraph text, and put in the article top author: Lu Junyi (Cenalulu)
This article original address: http://cenalulu.github.io/python/gil-in-python/ Gil is what

The Gil is not a Python feature, it is a concept introduced when implementing the Python parser (CPython). Just like C + + is a set of language (syntax) standards, but can be compiled into executable code with different compilers. Well-known compilers such as Gcc,intel c++,visual C + +. As with Python, the same piece of code can be executed through different Python execution environments such as Cpython,pypy,psyco. Like Jpython, there's no Gil. However, because CPython is the default Python execution environment in most environments. So in a lot of people's concept CPython is Python, and it's also taken for granted that Gil is a flaw in the Python language. So here's the thing to be clear: Gil is not a Python feature, and Python can be completely independent of Gil

So what is the Gil in the CPython implementation? Gil full name Global interpreter lock to avoid misleading, let's look at the official explanation:

In CPython, the global interpreter lock, or GIL, are a mutex that prevents multiple native threads from executing Python by Tecodes at once. This lock is necessary mainly because CPython ' s memory management are not thread-safe. (However, since the GIL exists, features have grown to depend on the guarantees, it enforces.)

A mutex that prevents multithreading from executing machine code concurrently. Why would there be Gil?

Python starts to support multithreading in order to take advantage of multi-core. The easiest way to solve the data integrity and state synchronization between multithreading is to lock it. So with the Gil this super lock, and as more and more code base developers accept this setting, they start to rely heavily on this feature (that is, the default Python internal object is Thread-safe, without having to consider additional memory locks and synchronizations when implemented).

Slowly this realization was found to be a sore and inefficient egg. But when people tried to split and remove Gil, it was hard to get rid of a large number of library code developers who relied heavily on the Gil. the impact of Gil

Even almost equals Python is a single-threaded program.

The presence of the Gil causes multithreading to not be as good as the instant multi-core CPU's concurrent processing capability.

Python multithreading on multi-core CPUs only has a positive effect on IO-intensive computing, and when at least one CPU-intensive thread is present, the multiple-threading efficiency is significantly reduced due to the Gil. how to avoid being affected by the Gil

Said so much, if not to say the solution is just a popular science post, but the egg. Gil is so rotten, there's no way around it. Let's take a look at the ready-made options. replacing thread with multiprocessing

The multiprocessing library is largely designed to compensate for the low efficiency of the thread library because of Gil. It fully replicates a set of thread-provided interfaces for easy migration. The only difference is that it uses multiple processes rather than multithreading. Each process has its own independent Gil, so there is no Gil scramble between processes.

Of course, multiprocessing is not a panacea. Its introduction will increase the difficulty of data communication and synchronization between threads during program implementation. Take the counter to give an example, if we want multiple threads to accumulate the same variable, for thread, declare a global variable, with thread. The lock context wraps around three lines and it's done. Multiprocessing because the process can not see each other's data, only through the main thread to declare a queue,put to get or use share memory method. This extra implementation cost makes it painfully easy to encode multithreaded programs that are inherently painful. Specific difficulties where interested readers can expand the reading of this article with other parsers

It was also mentioned earlier that since Gil is a product of CPython, other parsers are better. Yes, parsers like Jpython and IronPython do not need Gil's help because they implement language features. However, with the use of java/c# for parser implementations, they also lost the opportunity to take advantage of the features of many of the community's C-language modules. So these parsers have always been relatively small. After all, function and performance everyone will choose the former in the early days, the is better than perfect.