Cc: Stefan Richter <stefanr@...>, Christoph Lameter <clameter@...>, Chris Snook <csnook@...>, Linux Kernel Mailing List <linux-kernel@...>, <linux-arch@...>, Linus Torvalds <torvalds@...>, <netdev@...>, Andrew Morton <akpm@...>, <ak@...>, <heiko.carstens@...>, <davem@...>, <schwidefsky@...>, <wensong@...>, <horms@...>, <wjiang@...>, <cfriesen@...>, <zlynx@...>, <rpjday@...>, <jesper.juhl@...>, <segher@...>, Herbert Xu <herbert@...>, Paul E. McKenney <paulmck@...>
[ Bill tells me in private communication he gets this already, but I
think it's more complicated than the shoddy explanation I'd made
earlier so would wish to make this clearer in detail one last time,
for the benefit of others listening in or reading the archives. ]
On Thu, 16 Aug 2007, Satyam Sharma wrote:
Casts don't produce lvalues, and the cast ((volatile int)a) does not
produce the object-int-a-qualified-as-"volatile" -- in fact, the
result of the above cast is whatever is the _value_ of "int a", with
the access to that object having _already_ taken place, as per the
actual type-qualification of the object (that was originally declared
as being _non-volatile_, in fact). Hence, defining atomic_read() as:
#define atomic_read(v) ((volatile int)((v)->counter))
would be buggy and not give "volatility" semantics at all, unless the
"counter" object itself isn't volatile-qualified already (which it
isn't).
The result of the cast itself being the _value_ of the int object, and
not the object itself (i.e., not an lvalue), is thereby independent of
type-qualification in that cast itself (it just wouldn't make any
difference), hence the "cast to a qualified type has the same effect
as a cast to an unqualified version of that type" bit in section 6.5.4:4
of the standard.
Dereferencing using the *(pointer-type-cast)& construct, OTOH, serves
us well:
#define atomic_read(v) (*(volatile int *)&(v)->counter)
Firstly, note that the cast here being (volatile int *) and not
(int * volatile) qualifies the type of the _object_ being pointed to
by the pointer in question as being volatile-qualified, and not the
pointer itself (6.2.5:27 of the standard, and 6.3.2.3:2 allows us to
convert from a pointer-to-non-volatile-qualified-int to a pointer-to-
volatile-qualified-int, which suits us just fine) -- but note that
the _access_ to that address itself has not yet occurred.
_After_ specifying the memory address as containing a volatile-qualified-
int-type object, (and GCC co-operates as mentioned below), we proceed to
dereference it, which is when the _actual access_ occurs, therefore with
"volatility" semantics this time.
Interesting.
Satyam
-
