4 ms·
Python’s GIL does exactly nothing to prevent data races (or any other concurrency issues); it merely protects the runtime from memory corruption stemming from c
by tomp 5y ago
Python’s GIL does exactly nothing to prevent data races (or any other concurrency issues); it merely protects the runtime from memory corruption stemming from concurrency.
Obviously, the fundamental issue with concurrency is programmer’s intent. This statement:
x += 1; y -= 1
can be interpreted in two ways:
atomic {
x += 1
y -= 1
}
or
atomic { x += 1 }
atomic { y -= 1 }
The best the compiler can do would be to alert the programmer of the ambiguity; I know of no compiler that does that.
- deleted 5y ago[deleted]
- dzqhz 5y agoI don't see how it could ever be interpreted the first way.
- verdagon 5y agoThe article isn't trying to claim either interpretation, it's just using it as an example to show that the GIL doesn't actually help protect users from concurrency problems. You'd be surprised how many people think that! I used to think that it did as well, but then my C/Java brain kicked in and realized that couldn't be correct. I wrote this article to help others see it in action.
- matheusmoreira 5y ago> I used to think that it did as well I did too. I even wrote multithreaded test programs to see if it was true: they would always give me consistent results on Python and Ruby but on Java and C data got clobbered as expected.
- tomp 5y agofor example: "move money from one bank account to another bank account" essentially the same operations in the same order, that need to be isolated (i.e. transactional / atomic) from concurrent threads performing the same operations.
- quietbritishjim 5y agoIt could also be interpreted as atomic { tmp = x + 1 } atomic { x = tmp } atomic { tmp = y - 1 } atomic { y = tmp } In fact I would expect this is the most likely possibility, at least for user defined objects.
- michaelrpeskin 5y agoI haven’t looked at the source, but I’ve written similar interpreters and I’d be willing to bet its atomic tmp=x atomic tmp+=1 atomic x=tmp atomic tmp=y atomic tmp-=1 atomic y=tmp
- ajross 5y ago> Python’s GIL does exactly nothing to prevent data races (or any other concurrency issues) That sounds good and authoritative. Unfortunately the Python documentation itself is silent on the subject. And more importantly the Python community is filled with people who believe exactly the opposite. It's a real hole. And the only solution right now is to tell everyone to avoid threads. The Python world simply isn't prepared for them. FWIW: I'm one of a handful of people who have found and fixed race conditions in python scripts. And it was largely because my background is in racey C code and my eyes were primed to see it. And even then, I genuinely thought (based on incorrect advice like the above) that this sort of thing was impossible and kept looking before trying the obvious synchronization solution. And it was only then that I realized what a mess concurrency is in the mind of the modern python developer.
- deleted 5y ago[deleted]