Messages in this thread | | | Date | Sat, 8 Jul 2006 13:11:01 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: [patch] spinlocks: remove 'volatile' |
| |
On Sat, 8 Jul 2006, Albert Cahalan wrote: > > > > 1. The volatile implementation of gcc is correct. The standard does not > > talk about busses, not even about SMP. > > The standard need not. An implementation must deal > with whatever odd hardware happens to be in use.
Not really.
The fact is, "volatile" simply doesn't inform the compiler enough about what the effect of an access could be under various different situations.
So the compiler really has no choice. It has to balance the fact that the standard requires it to do _something_ different, with the fact that there's really not a lot of information that the user gave, apart from the one bit of "it's volatile".
So the compiler really has no choice.
Btw, I think that the whole standard definition of "volatile" is pretty weak and useless. The standard could be improved, and a way to improve the definition of volatile would actually be to say something like
"volatile" implies that the access to that entity can alias with any other access.
That's actually a lot simpler for a compiler writer (a C compiler already has to know about the notion of data aliasing), and gives a lot more useful (and strict) semantics to the whole concept.
So to look at the previous example of
extern int a; extern int volatile b;
void testfn(void) { a++; b++; }
_my_ definition of "volatile" is actually totally unambiguous, and not just simpler than the current standard, it is also stronger. It would make it clearly invalid to read the value of "b" until the value of "a" has been written, because (by my definition), "b" may actually alias the value of "a", so you clearly cannot read "b" until "a" has been updated.
At the same time, there's no question that
addl $1,a addl $1,b
is a clearly valid instruction sequence by my simpler definition of volatile. The fact that "b" can alias with itself is a tautology, and is true of normal variables too, so any combination of ops on one variable (any variable always aliases _itself_) is by definition clearly always valid on a "volatile" variable too, and thus a compiler that can do the combination of "load + increment + store" on a normal variable should always do so on a volatile one too.
In contrast, the current C standard definition of "volatile" is not only cumbersome and inconvenient, it's also badly defined when it comes to accesses to _other_ data, making it clearly less useful.
I personally think that my simpler definition of volatile is actually a perfectly valid implementation of the current definition of volatile, and I suggested it to some gcc people as a better way to handle "volatile" inside gcc while still being standards-conforming (ie the "can alias anything" thing is not just clearer and simpler, it's strictly a subset of what the C standard allows, meaning that I think you can adopt my definition _without_ breaking any old programs or standards).
But there really is no way to "fix" volatile. You will always invariably need other things too (inline assembly with "lock" prefixes etc) to actually create true lock primitives. The suggested "can alias anything" semantics just clarify what it means, and thus make it less ambiguous. It doesn't make it fundamentally more useful in general.
Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |