Defines ACCESS_ONCE(x) macro (XCC)
authorBarret Rhoden <brho@cs.berkeley.edu>
Sat, 4 May 2013 06:41:57 +0000 (23:41 -0700)
committerBarret Rhoden <brho@cs.berkeley.edu>
Sat, 4 May 2013 06:41:57 +0000 (23:41 -0700)
commit4310095ee3abaa72b03a65826ae0a4cb26882cb5
tree0418af3c8ba9ba982366757bf083e7f0c91c93e0
parentdf53d96f66bbeb3552d9af0f7f50a619dc33f51c
Defines ACCESS_ONCE(x) macro (XCC)

This forces a one-time read of the value x.   I've been meaning to do
this for a while - we have a lot of synchronization code that assumes
that data is only loaded once, at a specific point in time.  Eventually
I'll go through older code and start using this.

Check out http://lwn.net/Articles/508991/ for more info.

This will also help with code that wants to force a read-in (say, from
global state to thread state) for performance reasons.

Keep in mind that we continue to need memory barriers, like the wmb(),
wrmb(), etc, since this has nothing to do with the processor's ordering
of operations, and also has nothing to do with writing values.

This is fairly similar to a cmb(), in that both tell the compiler that
memory values may have changed.  One slight difference is that a cmb()
(and rmb/wmb on x86) involves an asm volatile, which should prevent the
compiler from reordering the accesses (I think!).  AFAIK, the compiler
could reorder:

local_x = ACCESS_ONCE(x);
local_y = ACCESS_ONCE(y);

and if it is important to actually read x before y, then you want to do:

local_x = ACCESS_ONCE(x);
rmb(); /* on x86, this is just an asm volatile("" ::: "memory") */
local_y = ACCESS_ONCE(y);

The rmb() orders the x and y reads, and the ACCESS_ONCE prevents the
compiler from trying to read in x in the future when using local_x.

Finally, note that any use of an rwmb() (where we want to enforce the
read happens before the write) will probably want to use an ACCESS_ONCE,
unless we are okay with reading the value again after the write.

Reinstall your kernel header.
kern/include/ros/common.h