The trouble with volatile

Huh? That makes no sense. The *assignment statement* has a value, sure, and that's the value referenced in any outer context. For example:

volatile int   a;
volatile short b;
volatile int   c;

a = b = c;

This code will read 'c' cast it to the type of 'b', and then write it to 'b'. That whole expression, 'b = c', takes on the same value as was written to 'b'. That value gets written to 'a'. You aren't reading 'b' and assigning it to 'a', you're assigning the value of the expression 'b = c', plain and simple. That makes sense. Let's suppose 'b' gets modified by an interrupt handler, and the interrupt happens right after the write to 'b'. The code will always write the same value to 'a' regardless of whether 'b' even takes on the value written to it.

Now, on a compiler that doesn't do register allocation, or for which that's disabled, the value of the expression 'b = c' might get written to a compiler temporary in memory, and the compiler issues writes and reads for that location. I assert it's actually incorrect to read 'b' and write it to 'a' when writing 'a = b = c'.

If all assignments had a hidden read behind them, then Duff's Device probably would never have worked. The motivation for Duff's Device was fast writes through a volatile pointer to a hardware FIFO.

Now, C++ on the other hand... they allow assignments to be lvalues, which causes all sorts of wackiness. And so C++ apparently does behave somewhat as you describe, at least in the 'a = b = c' case. (An assignment in isolation still doesn't have a phantom read.) It bolsters my argument above that they consider this a deviation from how C behaves. Take a peek here.

At any rate, since we're talking about the Linux kernel, we're talking C, not C++.

volatile int a;
void f() {
        a = 2;
}

        movl    $2, a
        ret

What you don't mention (and Linus does) is that volatile can actually produce incorrect (as well as inefficient) code, because the compiler is not necessarily able to produce the right kind of barrier operation. Compilers know about instruction architectures and, maybe, something about which optimisations work best for which processor families, but they aren't oracles on the most appropriate bus synchronisation operations for every system architecture.

I think the inaccuracy and uselessness of this statement is what Linus is really objecting to. With this being inaccurate and useless, the compiler are forced to do useless things as a result. But those are side effects, the real culprit is still the inaccuracy and uselessness.

I believe the inaccuracy of "volatile" is that it says the memory is always changing, which is not really the case. The memory is changed by some other threads, or by some reordering done by some smart CPUs. It is definitely not "changing all the time", with the exception of I/O mapped memory which might.

I think it is mostly useless, because in most cases a simple "volatile" will not do what is intended, and to do what is intended you need something that will make volatile redundant.

E.g., if you are afraid of some other threads changing your variables, you need a lock to prevent that, rather than just an advice to the compiler not to optimize things out; and once you get that, the CPU reordering is dealt with, and the variable is no longer changing at all within the critical region, so you don't want volatile.

Another reply supplies another example: if you do inter-processor communications, "volatile" is not sufficient, because the instruction reordering done by the CPU causes the result to be erratic. You need something like barrier(), rmb(), wmb(), etc. Once you have that, "volatile" is redundant. Yes, those operations are over-general, but at least they work.

What if you really want to do I/O memory mapped read/write? Again, you need memory barriers for the code to work correctly, and once you have them, you don't need volatile.

> Then Linus misinterprets the English word "volatile" and claims that data
> isn't volatile; rather accesses are volatile. The opposite is true.

I agree that it is difficult to characterize an "access" is "volatile" or not, and I admit that I don't quite understand the statement. On the other hand, while "data is volatile" might be true for some time during the execution of the kernel, the "volatile" in the C language does not provide you the abstraction that you need most of the time.

These are the two cases defined by the standard where volatile *must* be used for certain variables. Memory-mapped I/O is the third case it was intended for, but as that's inherently unportable the standard doesn't explicitly mention it. (I think the rationale does.)

Well, more generally, the C and C++ languages themselves do nothing to prevent such problems (unlike Java)--they are blissfully unaware of all concurrency-related issues, and as a consequence, there is nothing you can do about any of it using only language-provided constructs. Some form of assembly-level support is always required.

Note that, fundamentally, it's the same problem afflicting the Double-Checked Locking Pattern (C/C++ version). Scott Meyers' (co-authored) 2004 DDJ article describes the issues quite nicely.

Greg

I want to open a big bracket here and mention that volatile in Java an entirely different beast and is much much more useful. According to the Java memory model, volatile actually has very useful guarantees for memory visibility. (Perhaps Linux should consider Java for the kernel :-)

Or C#... it seems that the .NET platform is even more specific than Java in this sense :-)