Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures

!MAILaRCHIVE_VOTE_RePLACE
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Bill Fink <billfink@...>
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@...>
Date: Thursday, August 16, 2007 - 5:25 am

[ 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
-
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
Re: [PATCH 0/24] make atomic_read() behave consistently acro..., Christoph Lameter, (Tue Aug 14, 6:31 pm)
Re: [PATCH 0/24] make atomic_read() behave consistently acro..., Christoph Lameter, (Wed Aug 15, 3:59 pm)
Re: [PATCH 0/24] make atomic_read() behave consistently acro..., Segher Boessenkool, (Thu Aug 16, 4:50 pm)
Re: [PATCH 0/24] make atomic_read() behave consistently acro..., Segher Boessenkool, (Fri Aug 17, 6:34 pm)
Re: [PATCH 0/24] make atomic_read() behave consistently acro..., Segher Boessenkool, (Thu Aug 16, 5:00 pm)
Re: [PATCH 0/24] make atomic_read() behave consistently acro..., Segher Boessenkool, (Fri Aug 17, 6:38 pm)
Re: [PATCH 0/24] make atomic_read() behave consistently acro..., Satyam Sharma, (Thu Aug 16, 5:25 am)
Re: [PATCH 0/24] make atomic_read() behave consistently acro..., Christoph Lameter, (Fri Aug 24, 1:15 pm)
Re: [PATCH 0/24] make atomic_read() behave consistently acro..., Christoph Lameter, (Wed Aug 15, 8:26 pm)
Re: [PATCH 0/24] make atomic_read() behave consistently acro..., Christoph Lameter, (Wed Aug 15, 8:42 pm)
Re: [PATCH 0/24] make atomic_read() behave consistently acro..., Segher Boessenkool, (Wed Aug 15, 10:07 pm)
Re: [PATCH 0/24] make atomic_read() behave consistently acro..., Segher Boessenkool, (Thu Aug 16, 3:39 pm)
Re: [PATCH 0/24] make atomic_read() behave consistently acro..., Christoph Lameter, (Thu Aug 16, 2:54 pm)
Re: [PATCH 0/24] make atomic_read() behave consistently acro..., Christoph Lameter, (Thu Aug 16, 4:20 pm)
Re: [PATCH 0/24] make atomic_read() behave consistently acro..., Segher Boessenkool, (Fri Aug 17, 1:41 pm)
Re: [PATCH 0/24] make atomic_read() behave consistently acro..., Christoph Lameter, (Mon Sep 10, 2:59 pm)
Re: [PATCH 0/24] make atomic_read() behave consistently acro..., Segher Boessenkool, (Mon Sep 10, 10:27 pm)
Re: [PATCH 0/24] make atomic_read() behave consistently acro..., Christoph Lameter, (Mon Sep 10, 5:36 pm)
Re: [PATCH 0/24] make atomic_read() behave consistently acro..., Segher Boessenkool, (Fri Aug 17, 7:17 pm)
Re: [PATCH 0/24] make atomic_read() behave consistently acro..., Segher Boessenkool, (Fri Aug 17, 8:04 pm)
Re: [PATCH 0/24] make atomic_read() behave consistently acro..., Segher Boessenkool, (Fri Aug 17, 10:15 pm)
Re: [PATCH 0/24] make atomic_read() behave consistently acro..., Segher Boessenkool, (Sat Aug 18, 1:18 am)
Re: [PATCH 0/24] make atomic_read() behave consistently acro..., Segher Boessenkool, (Fri Aug 17, 6:09 pm)
Re: [PATCH 0/24] make atomic_read() behave consistently acro..., Arjan van de Ven, (Mon Sep 10, 10:51 am)
Re: [PATCH] Document non-semantics of atomic_read() and atom..., Christoph Lameter, (Tue Sep 11, 3:35 pm)
Re: [PATCH 0/24] make atomic_read() behave consistently acro..., Christoph Lameter, (Mon Sep 10, 2:59 pm)
Re: [PATCH 0/24] make atomic_read() behave consistently acro..., Segher Boessenkool, (Tue Aug 21, 10:59 am)
Re: [PATCH 0/24] make atomic_read() behave consistently acro..., Segher Boessenkool, (Mon Aug 20, 6:07 pm)
Re: [PATCH 0/24] make atomic_read() behave consistently acro..., Paul E. McKenney, (Thu Aug 16, 12:34 pm)
Re: [PATCH 0/24] make atomic_read() behave consistently acro..., Segher Boessenkool, (Fri Aug 17, 6:14 pm)
Re: [PATCH 0/24] make atomic_read() behave consistently acro..., Paul E. McKenney, (Fri Aug 17, 10:31 am)
Re: [PATCH 0/24] make atomic_read() behave consistently acro..., Christoph Lameter, (Wed Aug 15, 10:15 pm)
Re: [PATCH 0/24] make atomic_read() behave consistently acro..., Christoph Lameter, (Wed Aug 15, 10:17 pm)
Re: [PATCH 0/24] make atomic_read() behave consistently acro..., Paul E. McKenney, (Wed Aug 15, 10:35 pm)
Re: [PATCH 0/24] make atomic_read() behave consistently acro..., Christoph Lameter, (Wed Aug 15, 8:59 pm)
Re: [PATCH 0/24] make atomic_read() behave consistently acro..., Christoph Lameter, (Wed Aug 15, 9:41 pm)
Re: [PATCH 0/24] make atomic_read() behave consistently acro..., Paul E. McKenney, (Wed Aug 15, 10:32 pm)
Re: [PATCH 0/24] make atomic_read() behave consistently acro..., Christoph Lameter, (Wed Aug 15, 8:40 pm)
Re: [PATCH 0/24] make atomic_read() behave consistently acro..., Segher Boessenkool, (Wed Aug 15, 2:31 pm)
Re: [PATCH 0/24] make atomic_read() behave consistently acro..., Segher Boessenkool, (Wed Aug 15, 4:42 pm)
Re: [PATCH 0/24] make atomic_read() behave consistently acro..., Paul E. McKenney, (Wed Aug 15, 10:25 am)
Re: [PATCH 0/24] make atomic_read() behave consistently acro..., Segher Boessenkool, (Wed Aug 15, 4:58 pm)
Re: [PATCH 0/24] make atomic_read() behave consistently acro..., Segher Boessenkool, (Wed Aug 15, 5:07 pm)
Re: [PATCH 0/24] make atomic_read() behave consistently acro..., Paul E. McKenney, (Wed Aug 15, 12:08 pm)
Re: [PATCH 0/24] make atomic_read() behave consistently acro..., Christoph Lameter, (Tue Aug 14, 6:51 pm)