Re: [PATCH 24/24] document volatile atomic_read() behavior

[Segher Boessenkool <segher@kernel.crashing.org>]

>>> Explicit
>>> +casting in atomic_read() ensures consistent behavior across 
>>> architectures
>>> +and compilers.
>> Even modulo compiler bugs, what makes you believe that?
>
> When you declare a variable volatile, you don't actually tell the 
> compiler where you want to override its default optimization behavior, 
> giving it some freedom to guess your intentions incorrectly.  When you 
> put the cast on the data access itself, there is no question about 
> precisely where in the code you want to override the compiler's 
> default optimization behavior.

...except for the small point that this isn't how volatile works.

Rule of thumb: even people who know the semantics of volatile
shouldn't use it.

> If the compiler doesn't do what you want with a volatile declaration, 
> it might have a plausible excuse in the ambiguity of the C standard.  
> If the compiler doesn't do what you want in a cast specific to a 
> single dereference, it's just plain broken.

The other way around.  "volatile" has pretty weak semantics, and
certainly not the semantics you think it has, or that you wish it
had; but *(volatile XX *) doesn't have *any* semantics.  However
much you cast that pointer it still doesn't point to a volatile
object.

GCC will generally take the path of least surprise and perform a
volatile access anyway, but this has only be decided recently (a
year ago or so), and there very likely still are some bugs in
that area.

> We try to be compatible with plausibly correct compilers, but if 
> they're completely broken, we're screwed no matter what.

If you don't know what to expect, you're screwed for sure.


Anyway, what's the supposed advantage of *(volatile *) vs. using
a real volatile object?  That you can access that same object in
a non-volatile way?


Segher