How does an interpretive language avoid using Global Interpreter (GIL) locks?

Question

CPython uses Global Interpreter Lock . Linux has removed all traces of Locking a large kernel . What is the alternative to these locks? How can a system fully utilize a truly multi-core or multi-processor system without interruption?

Answer 1

GIL is not required if python used a more advanced garbage collector, such as IBM Recycler , embedded in a primitive method of reference counting. This is what Unladen Swallow does to improve python performance. More problematic is Stackless Python , which uses its own implementation of microflows instead of relying on an operating system such as traditional CPython.

Answer 2

GIL is process dependent, so you can get around it by running multiple Python processes. The multiprocessing module provides an easy to use API for this.

Another way is to use C extensions (or write your own) that release the GIL, doing the necessary data processing.

Answer 3

Simple They do not have a mutable state, like Haskell and other functional programming languages. Since nothing in the memory needs to be changed, a global lock is not required.

Answer 4

You can get rid of the GIL in the same way that the Linux guys got rid of Big Kernel locks: just add a lot of finer-grained locks or use atomic primitives that don't need locks.

The downside and the main reason that Python doesn't do this is performance. For example, the Tcl interpreter does not have a GIL, but can be compiled with a stream and non-threaded, if you use the stream version, you get 10-20% less performance than in the single-threaded case. Therefore, if you do not use threads, this is slower. There were Python fixes for adding small locks, but they had even worse performance implications, so they were rejected.

This is just a compromise, the python developers decided that the performance of a single thread (and backward compatibility with C-extensions) is much more important than the ability to use many threads at the python level. You can still freely use streams inside the C-extension, not to mention the value of the python language level.