Messages in this thread | | | Date | Thu, 16 Aug 2007 01:10:15 +0530 (IST) | From | Satyam Sharma <> | Subject | Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures |
| |
On Wed, 15 Aug 2007, Segher Boessenkool wrote:
> > "Volatile behaviour" itself isn't consistently defined (at least > > definitely not consistently implemented in various gcc versions across > > platforms), > > It should be consistent across platforms; if not, file a bug please. > > > but it is /expected/ to mean something like: "ensure that > > every such access actually goes all the way to memory, and is not > > re-ordered w.r.t. to other accesses, as far as the compiler can take ^ (volatile)
(or, alternatively, "other accesses to the same volatile object" ...)
> > care of these". The last "as far as compiler can take care" disclaimer > > comes about due to CPUs doing their own re-ordering nowadays. > > You can *expect* whatever you want, but this isn't in line with > reality at all. > > volatile _does not_ prevent reordering wrt other accesses. > [...] > What volatile does are a) never optimise away a read (or write) > to the object, since the data can change in ways the compiler > cannot see; and b) never move stores to the object across a > sequence point. This does not mean other accesses cannot be > reordered wrt the volatile access. > > If the abstract machine would do an access to a volatile- > qualified object, the generated machine code will do that > access too. But, for example, it can still be optimised > away by the compiler, if it can prove it is allowed to.
As (now) indicated above, I had meant multiple volatile accesses to the same object, obviously.
BTW:
#define atomic_read(a) (*(volatile int *)&(a)) #define atomic_set(a,i) (*(volatile int *)&(a) = (i))
int a;
void func(void) { int b;
b = atomic_read(a); atomic_set(a, 20); b = atomic_read(a); }
gives:
func: pushl %ebp movl a, %eax movl %esp, %ebp movl $20, a movl a, %eax popl %ebp ret
so the first atomic_read() wasn't optimized away.
> volatile _does not_ make accesses go all the way to memory. > [...] > If you want stuff to go all the way to memory, you need some > architecture-specific flush sequence; to make a store globally > visible before another store, you need mb(); before some following > read, you need mb(); to prevent reordering you need a barrier.
Sure, which explains the "as far as the compiler can take care" bit. Poor phrase / choice of words, probably. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |