Re: [patch] spinlocks: remove 'volatile'

[Pavel Machek]

Hi!

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

Are you sure?

volatile int a; a=1; a=2;

...under old definition, there's nothing to optimize but AFAICT, your
definition allows optimizing out a=1.

						Pavel
-- 
Thanks for all the (sleeping) penguins.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/