Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
From: Satyam Sharma <hidden>
Date: 2007-08-16 05:08:45
Also in:
linux-arch, lkml
Hi Bill, On Wed, 15 Aug 2007, Bill Fink wrote:
On Wed, 15 Aug 2007, Satyam Sharma wrote:quoted
(C) $ cat tp3.c int a; void func(void) { *(volatile int *)&a = 10; *(volatile int *)&a = 20; } $ gcc -Os -S tp3.c $ cat tp3.s ... movl $10, a movl $20, a ...I'm curious about one minor tangential point. Why, instead of: b = *(volatile int *)&a; why can't this just be expressed as: b = (volatile int)a; Isn't it the contents of a that's volatile, i.e. it's value can change invisibly to the compiler, and that's why you want to force a read from memory? Why do you need the "*(volatile int *)&" construct?
"b = (volatile int)a;" doesn't help us because a cast to a qualified type has the same effect as a cast to an unqualified version of that type, as mentioned in 6.5.4:4 (footnote 86) of the standard. Note that "volatile" is a type-qualifier, not a type itself, so a cast of the _object_ itself to a qualified-type i.e. (volatile int) would not make the access itself volatile-qualified. To serve our purposes, it is necessary for us to take the address of this (non-volatile) object, cast the resulting _pointer_ to the corresponding volatile-qualified pointer-type, and then dereference it. This makes that particular _access_ be volatile-qualified, without the object itself being such. Also note that the (dereferenced) result is also a valid lvalue and hence can be used in "*(volatile int *)&a = b;" kind of construction (which we use for the atomic_set case). Satyam