On Tue, Apr 2, 2013 at 9:58 PM, Johannes Weiner <hannes@xxxxxxxxxxx> wrote:
> On Tue, Apr 02, 2013 at 09:25:40PM -0700, David Rientjes wrote:
>
>> As stated, it doesn't. I made the comment "for what it's worth" that
>> ACCESS_ONCE() doesn't do anything to "prevent the compiler from
>> re-fetching" as the changelog insists it does.
>
> That's exactly what it does:
>
> /*
> * Prevent the compiler from merging or refetching accesses.
>
> This is the guarantee ACCESS_ONCE() gives, users should absolutely be
> allowed to rely on this literal definition. The underlying gcc
> implementation does not matter one bit. That's the whole point of
> abstraction!
If the definition of ACCESS_ONCE is indeed
#define ACCESS_ONCE(x) (*(volatile typeof(x) *)&(x))
then its behaviour is compiler-specific.
The C language standard only describes how access to
volatile-qualified objects behave. In this case x is (presumably) not
a volatile-qualifed object. The standard never defines the behaviour
of volatile-qualified pointers. That might seem like an oversight,
but it is not: using a non-volatile-qualified pointer to access a
volatile-qualified object is undefined behaviour.
In short, casting a pointer to a non-volatile-qualified object to a
volatile-qualified pointer has no specific meaning in C. It's true
that most compilers will behave as you wish, but there is no
guarantee.
If using a sufficiently recent version of GCC, you can get the
behaviour that I think you want by using
__atomic_load(&x, __ATOMIC_RELAXED)
Ian
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>