Paul E. McKenney wrote:
Why not the same access-once semantics for atomic_set() as
for atomic_read()? As this patch stands, it might introduce
architecture-specific compiler-induced bugs due to the fact that
atomic_set() used to imply volatile behavior but no longer does.
When we make the volatile cast in atomic_read(), we're casting an rvalue to
volatile. This unambiguously tells the compiler that we want to re-load that
register from memory. What's "volatile behavior" for an lvalue? A write to an
lvalue already implies an eventual write to memory, so this would be a no-op.
Maybe you'll write to the register a few times before flushing it to memory, but
it will happen eventually. With an rvalue, there's no guarantee that it will
*ever* load from memory, which is what volatile fixes.
I think what you have in mind is LOCK_PREFIX behavior, which is not the purpose
of atomic_set. We use LOCK_PREFIX in the inline assembly for the atomic_*
operations that read, modify, and write a value, only because it is necessary to
perform that entire transaction atomically.
-- Chris
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
