CPython uses a Global Interpreter Lock. Linux has removed all traces of the Big Kernel Lock. What is the alternative to these locks? How can a system make full use of a truly multi-core or multi-processor system without grinding everything to a halt?
How can an interpretive language avoid using Global Interpreter lock (GIL)?
1.4k Views Asked by rook AtThere are 4 best solutions below

The GIL is process specific, so you can get around it by launching several Python processes. The multiprocessing module provides an easy-to-use API for this.
Another way is to use C-extensions (or write your own) which release the GIL while doing the kind of data processing you need.

You can get rid of the GIL in quite the same way the Linux guys got rid of the Big Kernel Lock: simply add lots of more fine grained locks or use atomic primitives that don't need locks.
The downside and main reason Python doesn't do it, is performance. For example the Tcl interpreter has no GIL but can be compiled threaded and non-threaded, if you use the threaded version, you get around 10-20% less performance than in the single threaded case. So unless you use threads, it is actually slower. There have been Python patches to add smaller locks, but those had even worse performance impacts, so were rejected.
It is just a trade-off, the python devs decided that single thread performance (and backward compatibility with C-extensions) is much more important than the option to use many threads on the python level. You can still use threads freely inside a C-extension, just not meaningfully on the python language level.
A GIL wouldn't be necessary if python used a more advanced Garbage Collector like IBM's Recycler instated of a primitive reference counting method. This is something that Unladen Swallow is doing to improve the performance of python. A more prommising answer is Stackless Python, which uses its own micro-thread implementation instead of relying on the operating system like traditional CPython.