[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] ia64: introduce atomic_{read,write}NN()



On 25/11/2011 08:36, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:

>> Why do you use explicitly ld.acq and st.rel?
>> I think that volatile variables are always accessed using ld.acq and
>> st.rel and they are not required.
> 
> That would imply the compiler would attach these completers, but in
> inline assembly it obviously can't.
> 
>> For example, The implementation of Linux is as follows:
>> 
>> #define atomic_read(v)  (*(volatile int *)&(v)->counter)
>> #define atomic64_read(v) (*(volatile long *)&(v)->counter)
> 
> Indeed - here the compiler is required to use acquire loads and
> release stores. The inline assembly has to mimic this behavior.

I assume Jan was mimic'ing the use of inline asm in the x86 equivalents. I
used asm for those, rather than straightforward volatile casting like in
Linux's ACCESS_ONCE() macro, just to be 100% sure about what is being
emitted by the compiler. It's not an especially compelling argument;
arch/ia64 can implement them whichever way you see fit as far as I'm
concerned.

By the by, I'm also thing about switching the naming round to
{read,write}N_atomic(), to avoid conflict with atomic_*() naming for
manipulations of atomic_t. Then I can implement {read,write}_atomic()
without the caller needing to hardcode the operation size.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.