[Python-Dev] Bugs in thread_nt.h
Paul Du Bois
paul.dubois at gmail.com
Thu Mar 10 09:07:03 CET 2011
More information about the Python-Dev mailing list
Thu Mar 10 09:07:03 CET 2011
- Previous message: [Python-Dev] Bugs in thread_nt.h
- Next message: [Python-Dev] Bugs in thread_nt.h
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: [Python-Dev] Bugs in thread_nt.h
- Next message: [Python-Dev] Bugs in thread_nt.h
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-Dev mailing list