Python threading and sharing variables

[Chris Angelico]

On Wed, Jul 5, 2017 at 8:40 PM, Rhodri James <rhodri at kynesim.co.uk> wrote:
> On 05/07/17 09:26, Chris Angelico wrote:
>>
>> On Wed, Jul 5, 2017 at 5:56 PM, pozz <pozzugno at gmail.com> wrote:
>>>
>>> It seems it works, but I'm not sure it is the correct way to share the
>>> variable self.cnt. It is only written in the long thread and only read in
>>> the main thread.
>>> Could a single Python instruction be interrupted (in this case, self.cnt
>>> =
>>> i)? Should I use a locking mechanism when reading/writing?
>>>
>>> What about if the variable is more complex, for example a list or
>>> dictionary? Even in this case, is it safe to avoid locking on a shared
>>> variable if the operation on the variable is performed in a single Python
>>> instruction?
>>
>>
>> You can be confident that a single assignment will happen atomically.
>> Even if "self.cnt = i" requires multiple instructions to perform
>> (which it probably doesn't), there's still going to be some moment
>> before the change has happened at all, and then some moment when the
>> change has completely happened, and you won't get a context switch in
>> between.
>
>
> Is there a definition of what is or isn't atomic behaviour anywhere?  As an
> embedded C programmer I definitely wouldn't assume that a high-level
> assignment (in all its ref-counting glory) would be atomic without some hint
> of proof :-)

In CPython, yes, because thread switching always takes place between
Python bytecode instructions.

In other Pythons, I don't know about actual guarantees, but if it's
possible for a simple assignment to NOT be atomic, it would lead to
internal corruption (eg messing with garbage collection and/or memory
pointers), so it would be the job of the interpreter, not the Python
code itself - because there'd be no way to reliably do *anything*
without some sort of lock... including acquiring a lock. So it *has*
to be solved at a lower level.

ChrisA