2 ms·
>> I have at least one very concrete example of code that someone assumed to be atomic: request_id = self._next_id self._next_id += 1 To think that is thread
by phkahler 3y ago
>> I have at least one very concrete example of code that someone assumed to be atomic:
request_id = self._next_id
self._next_id += 1
To think that is thread safe is just naive. Once you understand the potential problem you can look at the code and ask "why shouldn't this be unsafe?" Since there is nothing explicitly preventing the problem. After reading TFA (lazily I admit) I still don't know why that code is thread-safe with the GIL.
Python is fun and often forgiving, but a bunch of people who got lucky (because they were never taught about the hazards) are going to learn some new stuff with no-gil. I think it's a long overdue change and worth the (single thread) performance hit and bug surfacing phase.
- toxik 3y agoIt isn’t threadsafe in current Python.
- taway-20230404 3y agoThat example is not thread-safe _behavior-wise_ under the GIL. The block is composed of several individual operations, and the interpreter can preempt a thread between any one of them. On the other hand, it is safe from a memory-access perspective; the read from `self._next_id` will never dereference a partially-mutated invalid pointer or read a partially-mutated value.
- deleted 3y ago[deleted]