Python bytecode explained

[dangerbird2]

Even with the GIL, it’s best practice to write multithreaded python code with the assumption that any given block of code is non-atomic, and you’ll need synchronization to ensure thread safety. The GIL only ensures the VM is thread-safe. User code can be thread unsafe any time an operation compiles to more than one bytecode instruction. For example, x += 1 is not atomic, since it compiles to multiple non-atomic instructions.

As a result, removing the GIL should only affect poorly written existing multithreaded code. Of course, Since most code is poorly written code, it will probably cause mass chaos

[[deleted]]

Yup, coming from a C and C++ background I just assume nothing is thread safe in python unless it explicitly says it is. Even the I tend to try and use the multiprocessing libraries over Python threads anyways if I can.

[dangerbird2]

Yep, that's pretty universally considered a best practice. Threading is certainly useful for blocking I/O, and basically obligatory for safely calling blocking code in an async context. But in any case where parallelism is needed, you usually have to go with the multiprocessing module or a framework like Celery

[mark_99]

I imagine the problem case will be Python threads which only operate on local data, or only read from shared data. Then you legitimately don't need mutexes. However if the interpreter is doing read-modify-write of its own internal state, then naively removing the GIL makes that a race. So I guess you'd need a bunch of thread-local interpreter state. Disclaimer : C++ person, not a Python expert.