The problem with C's volatile qualifier

January 3, 2007

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.)

Written on 03 January 2007.
« My current views on webmail providers
The scars of my NPTL experience »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Wed Jan 3 23:33:28 2007
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.