Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: 2007-08-16 10:43:45
Also in:
linux-arch, lkml
On Thu, Aug 16, 2007 at 12:31:03PM +0200, Stefan Richter wrote:
PS: Just to clarify, I'm not speaking for the volatile modifier. I'm
not speaking for any particular implementation of atomic_t and its
accessors at all. All I am saying is that
- we use atomically accessed data types because we concurrently but
locklessly access this data,
- hence a read access to this data that could be optimized away
makes *no sense at all*.No sane compiler can optimise away an atomic_read per se. That's only possible if there's a preceding atomic_set or atomic_read, with no barriers in the middle. If that's the case, then one has to conclude that doing away with the second read is acceptable, as otherwise a memory (or at least a compiler) barrier should have been used. In fact, volatile doesn't guarantee that the memory gets read anyway. You might be reading some stale value out of the cache. Granted this doesn't happen on x86 but when you're coding for the kernel you can't make such assumptions. So the point here is that if you don't mind getting a stale value from the CPU cache when doing an atomic_read, then surely you won't mind getting a stale value from the compiler "cache".
quoted hunk ↗ jump to hunk
So, the architecture guys can implement atomic_read however they want--- as long as it cannot be optimized away.*
They can implement it however they want as long as it stays atomic. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} [off-list ref] Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt