Re:Wasp's Nest: A Lock-Free Concurrency Pattern In Python
by samps on Friday May 10, 2013 @07:51PM
(#5689203)
While I agree that it's generally not helpful to rely on implicit atomicity in any Python, the reality is that all the other Pythons have followed CPython's lead and implemented the same memory model for compatibility. PyPy, Jython, and IronPython all have atomic bytecodes. So, for better or for worse, this bytecode atomicity is a de facto part of the language.
<s>one reason you cannot think this way is because the GIL is a CPython concept. if you program with this restriction in mind, you're not writing python, you're writing python targeted to the CPython implementation of python.</s> - edit, this is actually wrong, a comment below explains why.
the other reason is because it is misunderstanding of how the GIL works. the GIL is acquired for each python instruction so no two instructions will race against each other in the interpreter. however, two threads could have any arbitrary ordering of instructions and there is not a strict correspondence of instructions to statements.
CPython uses native threads for python threads so if you make multiple threads, they will race against each other. please don't make any assumptions about how the interpreter and those threads will interact, and just use either locks with good judgement or a lock-free algorithm that is grounded in a very deep understanding of the languages memory model.