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

Segher Boessenkool wrote:
Historically this has been
+accomplished by declaring the counter itself to be volatile, but the
+ambiguity of the C standard on the semantics of volatile make this practice
+vulnerable to overly creative interpretation by compilers.

It's even worse when accessing through a volatile casted pointer;
see for example the recent(*) GCC bugs in that area.

(*) Well, not _all_ that recent. No one should be using the 3.x
series anymore, right?

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. 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. We try to be compatible with plausibly correct compilers, but if they're completely broken, we're screwed no matter what.

-- Chris
-
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/

Relevant Pages

  • Re: Boolean Buyers Beware ... AIX compiler bug --- PMR 26241,756
    ... and thus the compiler is fine. ... the standard says nothing about that. ... Everyone knows how volatile is supposed to work in C; ... It is true that the only way you can observe such optimizations ...
    (comp.programming.threads)
  • Re: A basic question question about volatile use
    ... compiler would not be able to prevent all bytes being aed. ... But it shows some of the limitations the C Standard has ... chips, ... with a volatile bitfield member of a struct). ...
    (comp.lang.c)
  • Re: volatile Keyword Question
    ... I thought the compiler was required to read the ... volatile because it was volatile? ... the behaviour of the code may be a grey area as ... The standard is quite explicit that ...
    (comp.lang.c)
  • Re: volatile in statements (memset_s)
    ... the keyword "volatile", to be used also on statements: ... to tell compiler not to remove or move the following statement. ... call (including all side-effects) if it improperly determines that the ... The "outside the program" part could be difficult to specify in standard, ...
    (comp.std.c)
  • Re: out of order execution / reoredering of instructions
    ... command-line options that make it do what you want currently (I'm not ... Now, my question is that, is it possible that compiler ... the POSIX threading standard requires pthread_mutex_lockto ... nowhere any variable is declared to be volatile. ...
    (comp.lang.c)
Loading