On Mon, Jul 9, 2018 at 2:11 AM, Marko Rauhamaa <ma...@pacujo.net> wrote: > MRAB <pyt...@mrabarnett.plus.com>: >> On 2018-07-08 14:38, Steven D'Aprano wrote: >>> On Sun, 08 Jul 2018 14:11:58 +0300, Marko Rauhamaa wrote: >>> >> [snip] >>>> More importantly, this loop may never finish: >>>> >>>> # Initially >>>> quit = False >>>> >>>> # Thread 1 >>>> global quit >>>> while not quit: >>>> time.sleep(1) >>>> >>>> # Thread 2 >>>> global quit >>>> quit = True >>> >>> Assuming that thread 2 actually runs *at some point*, I don't see how >>> that can't terminate. Neither thread sets quit to False, so provided >>> thread 2 runs at all, it has to terminate. >>> >> [snip] >> >> The compiler could look at the code for thread 1 and see that 'quit' is >> never assigned to, meaning that it could be "optimised" to: >> >> global quit >> if not quit: >> while True: >> time.sleep(1) >> >> In C you'd declare 'quit' as 'volatile' to tell the compiler that it >> could change unexpectedly, so don't make that assumption. > > C is an even tougher case. Even if the compiler kept on checking a > volatile value, the CPU might never propagate the cache content to the > other core. You'd need a memory barrier. In Java, "volatile" effectively > creates a memory barrier, but in C (and C++) it does not. In C you need > something like a mutex to see the effects of other threads running. > > (BTW, I think that's a terrible thing for the C standards committee to > specify.)
None of this has any impact on Python whatsoever. ChrisA -- https://mail.python.org/mailman/listinfo/python-list