Linus Torvalds wrote:
On Wed, 8 Aug 2007, Chris Snook wrote:
Some architectures currently do not declare the contents of an atomic_t to be
volatile. This causes confusion since atomic_read() might not actually read
anything if an optimizing compiler re-uses a value stored in a register, which
can break code that loops until something external changes the value of an
atomic_t.
I'd be *much* happier with "atomic_read()" doing the "volatile" instead.
The fact is, volatile on data structures is a bug. It's a wart in the C
language. It shouldn't be used.
Volatile accesses in *code* can be ok, and if we have "atomic_read()"
expand to a "*(volatile int *)&(x)->value", then I'd be ok with that.
But marking data structures volatile just makes the compiler screw up
totally, and makes code for initialization sequences etc much worse.
Linus
Fair enough. Casting to (volatile int *) will give us the behavior people
expect when using atomic_t without needing to use inefficient barriers.
While we have the hood up, should we convert all the atomic_t's to non-volatile
and put volatile casts in all the atomic_reads? I don't know enough about the
various arches to say with confidence that those changes alone will preserve
existing behavior. We might need some arch-specific tweaking of the atomic
operations.
-- 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
