Simplest scenario, the read-increment-write cycle with 2 threads. Even with a mutex, it is still possible to have data race, if the lock is on per operation level.
For the second part, yep, it is a mistake, not processes, but threads.
With GIL, the thread is given the permission to operate on certain interpreter-related data-structures, like reference counts, or free_list like in PyIntObject. What I mean the active thread is free to modify those data structures without fear of data races, and there is no explicit locking required, if it doesn't hold its own copies of those interpreter internal states.
But GIL can only guard the interpreter's own states, not any user program's states. And yes, explicit locking for operating on your own data is still required.
> Simplest scenario, the read-increment-write cycle with 2 threads. Even with a mutex, it is still possible to have data race, if the lock is on per operation level.
What you're describing is not "serialized access with a data race"; it's "multi-thread access that you didn't explicitly control properly".
> For the second part, yep, it is a mistake, not processes, but threads.
Ok, that clarifies things.
> the active thread is free to modify those data structures without fear of data races, and there is no explicit locking required, if it doesn't hold its own copies of those interpreter internal states.
I'm not sure I see why a thread would want to hold copies of those interpreter internal states, since if it did the issue would not be modifying them properly but having the local copies get out of sync with the interpreter's copies, since other threads can also mutate the latter.
Simplest scenario, the read-increment-write cycle with 2 threads. Even with a mutex, it is still possible to have data race, if the lock is on per operation level.
For the second part, yep, it is a mistake, not processes, but threads.
With GIL, the thread is given the permission to operate on certain interpreter-related data-structures, like reference counts, or free_list like in PyIntObject. What I mean the active thread is free to modify those data structures without fear of data races, and there is no explicit locking required, if it doesn't hold its own copies of those interpreter internal states.
But GIL can only guard the interpreter's own states, not any user program's states. And yes, explicit locking for operating on your own data is still required.
https://docs.python.org/3/c-api/init.html#thread-state-and-t...