> and that unsychrnoised concurrent access to data structures will not cause errors
Python doesn't ensure that unsynchornized concurrent access to data structures won't cause errors. As I understand and experience Python multithreading, all the GIL ensures is that of the "load - inc - store" stages running amonst N threads, each separate stage will be locked, but not the overall sequence. So you'll still have data races, even with the GIL, and you still need to use mutexes etc in your Python program, which is why they are there.
Re:The Gilectomy – How's It Going [video]
by chrisseaton on Sunday May 28, 2017 @02:07PM
(#14435426)
I mean it won't cause errors within the basic data structure access operations. I'm not talking about composition. In Java a hash table write can fail with an exception if there is a concurrent write that conflicts. A Python dict write is atomic, because it happens within a single instruction as you say and so will not be interrupted and will never fail. That's what you aren't getting in Java. That expectation is very hard to provide without a GIL. Jython does it with blunt fine grained locking, but that's slow.
Interesting food for thought. So what exactly do you lose in jython?
Golang (informally I think) and Java (more formally) are not specified to provide reference counting semantics and not specified to guarantee that unsychrnoised concurrent access to data structures will not cause errors.
So the languages have different semantics - that's why you can't copy-and-paste the solution from one to another.
Some alternative implementations of Python don't follow the above semantics, like Jython, but then some people aren't happy with that. It may not be acceptable to the community to drop those semantics, even if they were never formally given.