[Python-Dev] Bugs in thread_nt.h

Paul Du Bois paul.dubois at gmail.com
Thu Mar 10 09:07:03 CET 2011


On Wed, Mar 9, 2011 at 8:42 PM, "Martin v. Löwis" <martin at v.loewis.de> wrote:
> As for the volatile marker - I believe the code is also
> correct without it, since the owned field is only accessed
> through initialization and Interlocked operations.

Furthermore, if the code weren't correct, "volatile" would only be
half the solution since
it only restricts compiler-induced reorders. Some sort of CPU fence instruction
would almost certainly be needed as well.

Sturla wrote:
> releasing the time-slice by Sleep(0) for each iteration, it will certainly fail without a volatile qualifier.

In general, your compiler will reload globally-accessible memory after
a function call (or
after a memory store). In fact, it can be quite a job to give them
enough hints that they stop doing so!
This behavior (which "volatile" aggravates) unfortunately makes it
even tougher to find race
conditions. In my experience, volatile should be avoided. I'd even bet
money that some grumpy
person has written a "volatile considered harmful" essay.

I Am Not A memory-model expert so consult your local guru,
p


More information about the Python-Dev mailing list