![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjDki4E6dsFie7C-k9X7tuy2Y_MeHQwWZT-1otM0q36KoqIPKLLP688d1HTLXQsoKanW41IAZK8DMNQJaM10XH1_o8LC8-H8dG3sNfKuvn-kpzIbTIYpgu5VezFyMVQ6qe0ZlMO2TU78G4/s200/Lock+Lock.png)
Recently, while inspecting latest python library improvements at v3.0; i stumbled into the Global Interpreter Lock ( aka GIL );
The GIL is being utilized by CPython (C implementation of Python language) in order to synchronize multiple threads access to python bytecode; consequently resulting into only one native thread capable of executing python bytecode.
Apparently this limitation isn't common for all python implementations out there, for example, Jython (Java implementation of Python) and ironPython (.NET implementation of python) don't suffer from this issue.
The GIL is coming to prevent inconsistency which might happen when multiple native threads access the same interpreted code; it's that bad that i can result in erroneous object reference count update when multiple threads are trying to access the same python object.
The REALLY bad news is that the GIL lock is a single lock per interpreter! which means, that even in the case of a multi-threaded app with multiple threads trying to access different objects; all these accesses will finally have to be serialized, since they are going to share the same access LOCK for the different objects.
Consequently, the only way to have multiple locks is going to be by lunching multiple instances of the interpreter.
I have to admit that i was lying a little bit when saying that all threads accesses are gonna be serialized; that reason is that CPython interpreter implementation is doing more in order to mitigate the GIL problem. Whenever the lock is acquire by some thread, the interpreter will try to reschedule other native thread which doesn't need to access the GIL, like a thread which is about to execute an I/O operation.
From one point of view, this might be problematic, since I/O operations are being suddenly priorities upon cpu operations; however, on the the hand, this can be really useful and effective in case of multi-threaded app which is mainly doing I/O processing.
In the next post i am going to evaluate how bad is the GIL for parallel apps and what can be done to avoid it.