When they should naturally be there, eg. locking or the RCU primitives,
I don't like having them scattered in various "just in case" places,
because it makes both the users and the APIs hard to understand and
Especially since several big architectures don't have volatile in their
atomic_get and _set, I think it would be a step backwards to add them in
as a "just in case" thin now (unless there is a better reason).
Oh, I missed that earlier debate. Will go have a look.
As Arnd ponted out, order() is not supposed to be an lvalue, but a
statement like the rest of our memory ordering API.
As to your followup question of why to use it over ACCESS_ONCE. I
guess, aside from consistency with the rest of the barrier APIs, you
can use it in other primitives when you don't actually know what the
caller is going to do or if it even will make an access. You could
also use it between calls to _other_ primitives, etc... it just
seems more flexible to me, but I haven't actually used such a thing
in real code...
ACCESS_ONCE doesn't seem as descriptive. What it results in is the
memory location being loaded or stored (presumably once exactly),
but I think the more general underlying idea is a barrier point.
SUSE Labs, Novell Inc.