GIL
Global interpreter lock (GIL) is a mechanism used in interpreters to ensures that only one thread runs in the interpreter at once. On multi-core systems, it means that multiple threads can’t effectively make use of multiple cores.

Applications running on implementations with a GIL can be designed to use separate processes to achieve full parallelism, as each process has its own interpreter and in turn has its own GIL. Otherwise, the GIL can be a significant barrier to parallelism.

Reasons for employing GIL

• increased speed of single-threaded programs (no necessity to acquire or release locks on all data structures separately)
• easy integration of C libraries that usually are not thread-safe
• ease of implementation (having a single GIL is much simpler to implement than a lock-free interpreter or one using fine-grained locks)

Drawbacks
Use of a global interpreter lock in a language effectively limits the amount of parallelism reachable through concurrency of a single interpreter process with multiple threads. If the process is almost purely made up of interpreted code and does not make calls outside of the interpreter for long periods of time (which can release the lock on the GIL on that thread while it processes), there is likely to be very little increase in speed when running the process on a multiprocessor machine. Due to signaling with a CPU-bound thread, it can cause a significant slowdown, even on single processors.

Note
GIL is only really an issue for CPython. In fact, as a Python developer, you don’t generally come across the GIL unless you’re writing a C extension. C extension writers need to release the GIL when their extensions do blocking I/O, so that other threads in the Python process get a chance to run.

Fix

• Other interpreter such as Jython and IronPython
• Use multiprocessing
• Use ctypes to write some code instead of Python
• Grumpy by Google