Bah.
If we have a case where we _really_ care about the value being stable, I
_still_ claim that that is the one that we need to protect. Not waving
some magic wand over the thing, and saying that "volatile" makes an
unstable value ok.
"volatile" (in the data sense, not the "asm volatile" sense) is almost
always a sign of a bug. If you have an algorithm that depends on the
(compiler-specifi) behaviour of "volatile", you need to change the
algorithm, not try to hide the fact that you have a bug.
Now, the change of algorithm might be something like
/*
* We need to get _one_ value here, because our
* state machine ....
*/
unsigned long stable = *(volatile unsigned long *)ptr;
switch (stable) {
....
}
where the volatile is in the place where we care, and the volatile is
commented on WHY it actually is the correct thing to do.
The C standard doesn't say crap about volatile. It leaves it up to the
compiler to do something about it.
This is _doubly_ true of multi-word data structures like "xtime". The
meaning of "volatile" on the data structure is so unclear that it's not
even funny.
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/