Re: [PATCH 1/24] make atomic_read() behave consistently on alpha

On Thu, Aug 09, 2007 at 12:36:17PM -0400, Chris Snook wrote:
Paul E. McKenney wrote:
The compiler is within its rights to read a 32-bit quantity 16 bits at
at time, even on a 32-bit machine. I would be glad to help pummel any
compiler writer that pulls such a dirty trick, but the C standard really
does permit this.

Yes, but we don't write code for these compilers. There are countless
pieces of kernel code which would break in this condition, and there
doesn't seem to be any interest in fixing this.

Use of volatile does in fact save you from the compiler pushing stores out
of loops regardless of whether you are also doing reads. The C standard
has the notion of sequence points, which occur at various places including
the ends of statements and the control expressions for "if" and "while"
statements. The compiler is not permitted to move volatile references
across a sequence point. Therefore, the compiler is not allowed to
push a volatile store out of a loop. Now the CPU might well do such a
reordering, but that is a separate issue to be dealt with via memory
barriers. Note that it is the CPU and I/O system, not the compiler,
that is forcing you to use reads to flush writes to MMIO registers.

Sequence points enforce read-after-write ordering, not write-after-write.
We flush writes with reads for MMIO because of this effect as well as the
CPU/bus effects.

Neither volatile reads nor volatile writes may be moved across sequence
points.

And you would be amazed at what compiler writers will do in order to
get an additional fraction of a percent out of SpecCPU...

Probably not :)

In short, please retain atomic_set()'s volatility, especially on those
architectures that declared the atomic_t's counter to be volatile.

Like i386 and x86_64? These used to have volatile in the atomic_t
declaration. We removed it, and the sky did not fall.

Interesting. You tested all possible configs on all possible hardware?

Thanx, Paul
-
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: out of order execution / reoredering of instructions
    ... The nearest existing thing is a partial ordering on memory access. ... the compiler how it should translate your code. ... the device registers in some specific sequence. ... All access to those should be qualified as volatile (use volatile ...
    (comp.lang.c)
  • 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: Is the following code MT-Safe?
    ... the assert (which is a fundamental design error: ... and almost always leads to either major synchronization failures ... >Does _bRunning need to be tagged as volatile? ... compiler to cache values, but only during the execution of a function; ...
    (microsoft.public.vc.mfc)
  • Re: Volatile + multithreading
    ... The volatile keyword has little use in multithreaded programming. ... > field or global seems to have no impact because it seems the compiler will ... operations as "special" and suppress optimizations around them. ... > majority of the multithreading issues that could have resulted from ...
    (microsoft.public.vc.language)
  • 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)