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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
