[Python-Dev] Bugs in thread_nt.h

[Sturla Molden]

Den 10.03.2011 11:06, skrev Scott Dial:
> http://www.kernel.org/doc/Documentation/volatile-considered-harmful.txt
>



The important part here (forgive me for being a pedant) is that register 
allocation of the (1) 'owned' field is actually unwanted, and (2) 
Microsoft specify 'volatile' in calls to the Interlocked* API-functions.

I am sorry for misreading 32 bits (4 bytes) as 32 bytes. That is 
obviously very different. If Microsoft's malloc is sufficient, why does 
MSDN tell us to use _aligned_malloc instead of malloc?


The rest is a comment to the link and a bit OT:

Their argument is that (1) volatile supresses optimization; (2) within a 
critical section, access to shared data is synchronized; and thus (3) 
volatile is critical there.

That is true, to some extent.

Volatile is not a memory barrier, nor a mutex. Volatile's main purpose 
is to prevent the compiler from storing  a variable in a register. 
Volatile might be used incorrectly if we don't understand this.

Obvious usecases for volatile are:

- Implementation of a spinlock, where register allocation is detrimental.
- A buffer that is filled from the "outside" with some DMA mechanism.
- Real-time programs and games where order of execution and and timing 
is critical, so optimization must be supressed.

Even though volatile is not needed for processing within a critical 
section, we still need the shared data to be re-loaded upon entering and 
er-written upon leaving. We can use a typecast to non-volatile within a 
critical section, and achieve both data consisitency and compiler 
optimization. OpenMP has a better mechanism for this, where a 
flush-operand (#pragma omp flush) will force a synchronization of shared 
data among threads (write and reload), and volatile is never needed for 
consistency of shared data.

Sturla