It has a confusing name, suggesting that it is intended to prevent multiple accesses. (Contrast with `pthread_once` for instance: a mechanism for once-only initialization.)<p>In fact, the very example given in the article shows that <i>without</i> the ACCESS_ONCE, the compiler moved the access outside of the loop---thereby ensuring that it's accessed <i>just</i> once, ironically!!! Whereas by using ACCESS_ONCE, we ensure that it's accessed as many times as the loop is iterated, not only once.<p>Basically this just does some kind of volatile access, and so the name should reflect that:<p><pre><code> foo = VOLATILE_READ(bar);
</code></pre>
Then the number of times it is accessed is implied from the agreement between abstract and actual semantics. In the abstract semantics, and expression is evaluated once for each invocation of whatever encloses it. If an expression is unconditionally evaluated in a loop that iterates 100 times, then it is evaluated 100 times. Hoisting it out of the loop would be an optimization which is forbidden by agreement with the abstract semantics.
The silly thing here is that this macro is not guaranteed to accomplish anything. The C standard limits how compilers can optimize accesses to <i>volatile objects</i>, but says nothing about accesses to non-volatile objects which are accessed via volatile-qualified pointers.