Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures

From: Segher Boessenkool
Date: Fri Aug 17 2007 - 20:08:48 EST


atomic_dec() writes
to memory, so it _does_ have "volatile semantics", implicitly, as
long as the compiler cannot optimise the atomic variable away
completely -- any store counts as a side effect.

I don't think an atomic_dec() implemented as an inline "asm volatile"
or one that uses a "forget" macro would have the same re-ordering
guarantees as an atomic_dec() that uses a volatile access cast.

The "asm volatile" implementation does have exactly the same
reordering guarantees as the "volatile cast" thing,

I don't think so.

"asm volatile" creates a side effect. Side effects aren't
allowed to be reordered wrt sequence points. This is exactly
the same reason as why "volatile accesses" cannot be reordered.

if that is
implemented by GCC in the "obvious" way. Even a "plain" asm()
will do the same.

Read the relevant GCC documentation.

I did, yes.

[ of course, if the (latest) GCC documentation is *yet again*
wrong, then alright, not much I can do about it, is there. ]

There was (and is) nothing wrong about the "+m" documentation, if
that is what you are talking about. It could be extended now, to
allow "+m" -- but that takes more than just "fixing" the documentation.


Segher

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