Re: why are some atomic_t's not volatile, while most are?

Jerry Jiang
2007-08-08T02:32:42Z

On Tue, 07 Aug 2007 16:32:23 -0400
Chris Snook <csnook@redhat.com> wrote:

> > It seems like this would fall more into the case of the arch providing
> > guarantees when using locked/atomic access rather than anything
> > SMP-related, no?.
>
> But if you're not using SMP, the only way you get a race condition is if your
> compiler is reordering instructions that have side effects which are invisible
> to the compiler. This can happen with MMIO registers, but it's not an issue
> with an atomic_t we're declaring in real memory.
>

Under non-SMP, some compilers would reordering instructions as they think
and C standard informally guarantees all operations on volatile data
are executed in the sequence in which they appear in the source code,
right?

So no reordering happens with volatile, right?

-- Jerry

> -- Chris