== The problem with C's _volatile_ qualifier

The real problem with C's _volatile_ (well, one of them) is that
_volatile_ only affects the compiler; it doesn't normally make the
compiler do anything to affect the CPU's interaction with memory. On
modern hardware, merely affecting the compiler is not enough; the
CPU/memory interface has its own optimizations, which must be dealt with
too for shared-state code to work right.

From the perspective of history this makes a lot of sense, because
ANSI C mostly predates CPU memory controllers that can do significant
reordering. Back in those days, it made sense to only worry about
the compiler's optimization model; you could assume that loads and
stores would be seen by memory (and IO devices) in the same order that
they appeared in the assembly code, which would be the same order
they appeared in C unless the compiler decided to optimize things. So
_volatile_ could be specified (to the extent that it was specified) as
more or less 'turn off compiler optimizations for this', and it all
worked out.

Unfortunately, modern CPUs have blown vast holes in this assumption
and in the process reduced _volatile_ to being useful for little
more than forcing spinloops to always load values, eg:

>  while (!ready)
>    ;

(Of course a really smart compiler could work out that there is no point
to this loop if it doesn't reload ((ready)) every time through.)

I suspect that no one has tried to make compilers generate explicit
memory barriers because it is a rather complicated field and it's not
obvious what sort of barriers are needed when. (The Linux kernel source
has an enlightening and rather large discussion of the whole issue in
Documentation/memory-barriers.txt.)

(The other problem with generating explicit memory barriers for access
to _volatile_ variables is that it would instantly hose all of the
code using _volatile_ for something other than shared-state variables,
which is probably most of it. Compiler authors are generally opposed to
changes with significant and unnecessary performance impacts for the
majority of the code their compiler compilers.)

(I can't imagine that this is a unique observation, but it bubbled
up in my mind [[recently ../links/ThreadsLibraryProblem]] and I feel
like writing it down explicitly, if only to cement it in my own
understanding.)