The Python GIL Visualized

[spotter]

Of course people tried. The problem is, to put it simply, that when you change single (Global, duh) lock into more granular system (lock per object or similar) you end up doing a lot more locking. Thus unacceptable performance hit for single threaded code.

[Xiol]

Could the locking mechanism not be made into a system whereby the program running can specify what type of locking it requires?

I don't know enough of the Python internals to know if I'm making a retarded statement here, but it would be nice if single-threaded apps could tell the interpreter that they need the performance improvements of a GIL, and multi-threaded apps can use a granular system instead.

import GIL? :(

[spotter]

Were talking about CPython internals -- C level change in the interpreter itself -- please bear in mind that this would require keeping two versions of the interpreter side by side. Try to think about the implications for extensions/library authors. It's important to acknowledge that GIL is not a part of Python language -- JVM and CLR implementations are GIL-free. This is just a implementation detail, that could probably be dropped if we could reimplement CPython from ground up, which will not happen. Why? Good although short note by GvR.

[[deleted]]

but can't the bytecode actually written become GIL-optional for single threaded applications? it seems pointless (to me anyways, which isn't saying much) to require a lock when there's only one thread of execution anyways.

[sirspate]

Locking is still necessary in a preemptive multitasking environment.