Before we get to GIL, we can review the difference between parallelism and concurrency: parallelism: multiple cpus performing multiple tasks at the same time, as if there were two programs that were actually being executed on two different cpus at the same time.

Concurrent: CPU alternating handle multiple tasks, there are still two programs, but only one CPU, deal with these two programs can alternate, rather than execution at the same time, simply because the CPU execution speed too fast, and will make people feel is in “and” execution, execution of the competition depends on the various procedures for time slice resources. We can refer to the physical picture below to understand:

Parallelism and concurrency are both multitasking and are designed to improve CPU efficiency. Here it is important to note that a CPU can never achieve parallel, that is, a CPU can’t run any more programs simultaneously, but it can within the time slice of randomly assigned alternate (concurrent), as if a person can’t see two books, but able to look at the first book half a minute, then look at the second book half a minute, this switch back and forth.

Let’s look at the difference between a process and a thread:

Two threads execute an infinite loop at the same time to check the usage of a single CPU:

Two threads execute an infinite loop at the same time to check the usage of both cpus:

Two processes execute an infinite loop at the same time to check both CPU usage:

That is, multithreading does not fully call on both cpus, but runs as if it were running on one CPU, whereas multithreading completely calls on both cpus, executing simultaneously.

Guido van Rossum created Python with a single-core CPU in mind, and the easiest way to solve data integrity and state synchronization between multiple threads is to lock it, hence the super lock GIL. Because cpython parsing only allows programs to run with a global parser lock on the GIL, it ensures that only one thread can use the CPU at a time. Because so many developers have adopted this mechanism, there is so much code that it is no longer easy to solve this problem in C code.

What is GIL?

The Global Interpreter Lock, or Global Interpreter Lock, requires each thread to obtain the GIL to ensure that only one thread can execute code at a time. In other words, only one thread can use the CPU at a time.

So how do we solve the GIL lock problem?

1. Replace CPython with jPython (not recommended)

2. Use multi-process to complete multi-threaded tasks

3 in the use of multithreading can be used to achieve the C language

Here are a few interview questions that I hope will help you:

Q0: why are threads forced to abandon cpus?

A:

  1. Threads are affected by time slices

  2. The GIL limits the execution time per thread, typically 5 milliseconds

  3. Or restrict threads to execute a fixed number of Bytecodes, typically 1000 bytes

Question 1: When will the Gil lock be released?

A:

  1. The Gil is released in cases where the CPU is idle due to time idle conditions such as I/O operations
  2. Once the value of ticks reaches 100, the Gil lock will be contested between the threads releasing the Gil lock. (Note: the value of ticks can be set to extend or reduce the CPU usage of the thread acquiring the Gil lock.)

Question 2: The relationship between mutex and Gil lock?

  • Gil lock: Ensures that only one thread can use the CPU at a time
  • Mutex: In the case of multiple threads, it ensures orderly modification of shared data without causing data modification chaos

Suppose there is only one process, Thread1 and Thread2, which need to modify the shared data date and have a mutex

Perform the following steps

(1) If Thread1 gets the GIL and can use the CPU, then Thread1 gets the mutex lock, and Thread1 can date the data (but does not start modifying the data).

The Gil lock can be contended when Thread1 loses the Gil lock because of the I/O operation or ticks count up to 100

(3) Thread1 and Thread2 begin to compete for Gil (note: if Thread1 loses Gil because of I/O blocking, Thread2 must get Gil; if Thread1 loses Gil because of ticks when the count reaches 100, Thread1 and Thread2 begin to compete for Gil Thread2 Fair play)

(4) Assume that Thread2 just acquired the GIL, and run the code to change the shared data date. Since Thread1 has a mutex lock, Thread2 cannot change the shared data date. Then Thread2 cedes the GIL lock, and the GIL lock contention occurs again

(5) Suppose Thread1 grabs the GIL again, since it has a mutex Lock, it can continue to modify the shared data data. When Thread1 finishes modifying the data and releases the mutex Lock,Thread2 can modify the data only after obtaining the GIL and Lock

The above describes a relationship between mutex and Gil locks