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 and I feel like writing it down explicitly, if only to cement it in my own understanding.)
|
|