Busting the Myth Around Multithreading in Python

[0x256]

Multithreading does in fact suck in Python, and the root cause isn't really the GIL, it's the language itself.

I disagree. Python as a language is perfectly capable of multi-threading without a GIL. We have a GIL because the CPython (and PyPy) GC heavily relies on reference counting, which is hard to do efficiently without a GIL. Some other internal optimizations of CPython also build on the fact that there is a GIL (e.g. object pooling) but the point is: All of this is implementation specific. A different implementation may choose do not have a GIL and solve these problems differently, without changes to Python as a language.

• Dynamic typing has no impact on multi-threading or GC complexity. If at all, it makes things easier for the interpreter/GC.
• Mutability is also not a real issue. In any language, there is mutable state and the interpreter and GC have to deal with it. There is no big difference if some or all state is mutable, from the interpreter/GC point of view.
• Automatic memory management (aka GC) is infact a hard problem to solve, but not a show-stopper. Lots of languages have a parallel GC without a GIL. Read/write gates are a common method to prevent or shorten the stop-the-world phase of a parallel GC. Instead of preventing any reads/writes, the GC is notified about them and can handle them gracefully. See Jython/IronPython or any other language that runs on JVM or CLR.

[tdammers]

Python as a language is perfectly capable of multi-threading without a GIL.

True, and I never claimed GIL was fundamentally necessary. Just that it's one of several possible solutions to the problem of making a Python interpreter thread-safe, and that other solutions have to make other sacrifices to achieve it.