On Wed, Jul 5, 2017 at 8:40 PM, Rhodri James <rho...@kynesim.co.uk> wrote: > On 05/07/17 09:26, Chris Angelico wrote: >> >> On Wed, Jul 5, 2017 at 5:56 PM, pozz <pozzu...@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 -- https://mail.python.org/mailman/listinfo/python-list
