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.
I understand all that. What I don't understand is the difference between
the hardware FIFO case which Alexander said is permissible. Won't
PCI/northbridge and not in the CPU itself.