Some tricks can be seen in some of the conversations of the father of Python.
Some listeners asked about global interpreter lock (GIL) and wanted to know more about this problem and how to solve it. Van Rossum smiled and asked: "How much time do you have?" He briefly told the history of GIL. After the birth of Python, multi-core computers appeared. When threads run in different cores, a competition mechanism occurs when two or more processors want to update the same object, especially in the Python garbage collection mechanism.
A reasonable solution is to lock each object, which can protect the data from being damaged by multiple accesses. But the result is that locking and unlocking operations are expensive when there is no contention for the lock. Some experiments have shown that the performance of single-threaded programs that do not require locking will be reduced by a factor of 2. This means that only programs using three or more threads or cores will benefit from this.
Thus, the GIL was born (although the name didn't appear until long after it was added to the interpreter). It is a single lock that effectively locks all objects at once, so that all object accesses are sequenced. The problem now is that in 10 or 15 years multi-core processors will be everywhere and people will want to take advantage of them without having to do multiprocessing (e.g. using independent processes instead of thread communication)
He said that if you want to design a new language today, make it have no mutable objects, or limited mutability. However, "this isn't Python anymore" came from the audience. "You said what I was going to say," agreed Van Rossum. There are many ongoing efforts by developers around the GIL, including PyPy Software Transactional Memory (STM), and PyParallel. Other developers are also scratching their heads trying to figure out a solution. If anyone knows of a way to remove the GIL and keep the language Pythonic, Van and others would love to hear about it.
Because the smaller the granularity of the lock, the more complex it is to implement, and the performance may be reduced due to the lock. Therefore, a global large lock is added.
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
Some tricks can be seen in some of the conversations of the father of Python.
Some listeners asked about global interpreter lock (GIL) and wanted to know more about this problem and how to solve it. Van Rossum smiled and asked: "How much time do you have?" He briefly told the history of GIL. After the birth of Python, multi-core computers appeared. When threads run in different cores, a competition mechanism occurs when two or more processors want to update the same object, especially in the Python garbage collection mechanism.
A reasonable solution is to lock each object, which can protect the data from being damaged by multiple accesses. But the result is that locking and unlocking operations are expensive when there is no contention for the lock. Some experiments have shown that the performance of single-threaded programs that do not require locking will be reduced by a factor of 2. This means that only programs using three or more threads or cores will benefit from this.
Thus, the GIL was born (although the name didn't appear until long after it was added to the interpreter). It is a single lock that effectively locks all objects at once, so that all object accesses are sequenced. The problem now is that in 10 or 15 years multi-core processors will be everywhere and people will want to take advantage of them without having to do multiprocessing (e.g. using independent processes instead of thread communication)
He said that if you want to design a new language today, make it have no mutable objects, or limited mutability. However, "this isn't Python anymore" came from the audience. "You said what I was going to say," agreed Van Rossum. There are many ongoing efforts by developers around the GIL, including PyPy Software Transactional Memory (STM), and PyParallel. Other developers are also scratching their heads trying to figure out a solution. If anyone knows of a way to remove the GIL and keep the language Pythonic, Van and others would love to hear about it.
Because the smaller the granularity of the lock, the more complex it is to implement, and the performance may be reduced due to the lock. Therefore, a global large lock is added.