Re: About volatile qualifier
On Mon, 30 Jun 2008 08:30:56 -0500, "Ben Voigt [C++ MVP]"
<rbv@nospam.nospam> wrote:
And access from other threads appears as asynchronous changes to the memory
as well, so it should be valid for purposes of sharing data between threads
as well or between a user-mode thread and an interrupt handler (these are
the same thing for pre-emptive threading systems).
The problem is, the standard doesn't concern itself with "pre-emptive
threading systems" and their issues such as the need to use memory
barriers. While a compiler can make volatile behave the way you'd like it
to, it doesn't have to, and most don't do what VC2005 does WRT adding
memory barrier semantics to volatile access and ordering of non-volatile
access WRT volatile access. For VC2005 and later, volatile should work for
a simple boolean flag, but remember it's non-standard, and it's far from a
general purpose synchronization mechanism such as a mutex. With a mutex,
you can say:
mx.lock();
.... use non-volatile objects, and code can be fully optimized
mx.unlock();
If you try to use volatile instead of a mutex, the would-be critical
section will be anti-optimized to an extreme degree due to inhibitions on
the compiler and the frequent memory barriers on architectures that require
memory barriers, and reasoning about its correctness will be harder,
because the ersatz critical section won't be well-defined.
--
Doug Harrison
Visual C++ MVP