Will dereferencing pointers always cause memory access?

Question

I wonder whether dereferencing a pointer will always be translated into a machine-level Load/Store instruction, regardless of how optimizing the compiler is.

Suppose we have two threads, one(let's call it Tom) receives user input and writes a bool variable. The variable is read by another(and this is Jerry) to decide whether to continue a loop. We know that an optimizing compiler may store the variable in a register when compiling the loop. So, at run time, Jerry may read an obsolete value that is different from what Tom actually writes. As a result,we should declare the bool variable as volatile.

However, if dreferencing a pointer will always cause memory access, then the two threads can use a pointer to reference the variable. On every write, Tom will store the new value into memory by dereferencing the pointer and writing to it. On each read, Jerry can really read what Tom wrote by dereferencing that same pointer. This seems better than the implementation-dependent volatile

I'm new to multi-threading programming, so this idea may seem trivial and unnecessary. But I'm really curious about it.

Answer 1

Will dereferencing a pointer always cause memory access?

No, for example:

int five() {
    int x = 5;
    int *ptr = &x;
    return *ptr;
}

Any sane optimizing compiler will not emit a mov from stack memory here, but something along the lines of:

five():
  mov eax, 5
  ret

This is allowed because of the as-if rule.

How do I do inter-thread communication through a bool* then?

This is what std::atomic<bool> is for. You shouldn't communicate between threads using non-atomic objects, because accessing the same memory location through two threads in a conflicting way¹⁾ is undefined behavior in C++. std::atomic makes it thread-safe, volatile doesn't. For example:

void thread(std::atomic<bool> &stop_signal) {
    while (!stop_signal) {
        do_stuff();
    }
}

Technically, this doesn't imply that each load from stop_signal will actually happen. The compiler is allowed to do partial loop unrolling like:

void thread(std::atomic<bool> &stop_signal) {
    // only possible if the compiler knows that do_stuff() doesn't modify stop_signal
    while (!stop_signal) {
        do_stuff();
        do_stuff();
        do_stuff();
        do_stuff();
    }
}

An atomic load() is allowed to observe stale values, so the compiler can assume that four load()s would all read the same value. Only some operations, like fetch_add() are required to observe the most recent value. Even then, this optimization might be possible.

In practice, optimizations like these aren't implemented for std::atomic in any compiler, so std::atomic is quasi-volatile. The same applies to C's atomic_bool, and _Atomic types in general.

---

¹⁾ Two memory accesses at the same location conflict if at least one of them is writing, i.e. two reads at the same location don't conflict. See [intro.races]

See Also

• std::atomic on cppreference
• C Atomic types on cppreference
• N4455 No Sane Compiler Would Optimize Atomics
• What exactly is the "as-if" rule?

Answer 2

Some ways of using the lvalue produced by dereferencing a pointer will not result in an access. For example, given int arr[5][4]; int *p; the statement p = *arr; will not dereference any storage associated with arr, but merely cause the compiler to recognize that the lvalue on the right half of the assignment is an int[4] which will decay into an int*.

Outside of such circumstances, the Standard seeks to classify as Undefined Behavior all situations in which the Standard is intended to allow an implementation to process a dereferencing operation by performing an access or not, at its leisure, and its decision would observably affect program behavior.

This philosophy leads to some rather murky corner cases in situations where a program uses some storage to hold a structure of type T, and then a structure of type U, and then a structure of type T again, then makes a copy of the T without having written all of the fields, and finally uses fwrite to output the entire copy of the T. If the compiler knows that a certain field in the original T was written with a certain value, it might generate code which stores that same value into the copy, without regard for whether the underlying storage might have changed. If nothing in the universe will ever care about what the bytes associate with that field hold in the data that was processed via fwrite, this shouldn't pose a problem, and requiring that the programmer ensure that all of the storage associated with the T be written using that type before it's copied as a type T would make it necessary for both the programmer and the computer that's running the program to do extra useless work. The Standard has no way of describing program behavior which would allow an implementation to observably fail to dereference all the fields of the T when copying it, without characterizing the program as invoking Undefined Behavior.

Answer 3

Another case where *p would not result in memory access is with the sizeof operator: sizeof(*p) will simply determine the size of the static type p points to. Note that in C, with variable length arguments, sizeof(*p) actually can require a memory access, but VLAs are a compiler extension in C++.

Answer 4

When working with multi-threading, explicitness is good. So I'm going to break down each and every piece.

"Will dereferencing pointers always cause memory access."

No. Consider the expression statement (void)*p. The *p performs indirection. From [expr.unary.op]:

The unary * operator performs indirection: the expression to which it is applied shall be a pointer to an object type, or a pointer to a function type and the result is an lvalue referring to the object or function to which the expression points.

So the result is an lvalue reference. That, on its own, is not sufficient to cause a "read" of the data pointed to by p. In the above example, I explicitly throw away the result, so there's no reason to read the memory.

Of course, one might argue that the memory of p is read. Just to be pedantic, I'd point out that's one interpretation of the word. However, an optimizing compiler can see that the lvalue pointed to by p is not needed here, so it doesn't actually need to read/write the pointer at all.

Now what about in a multithread environment? The key to this is the "happens-before" relationship in [intro.multithread]. It's incredibly dry formal language, but the basic idea is that event A happens before event B if A is sequenced before B (in a single thread), or if A inter-thread-happens-before B. The latter is the fancy language lawyer speak for a tool used to capture the behavior of both synchronization primitives like mutexes and atomics.

If A does not happens-before B and B does not happens-before A, then the two events are not ordered with respect to eachother. This is what happens on two threads when you don't have anything like mutexes to force an ordering. If one event writes to a memory location and the other reads or writes to that address, the result is a data race. And a data race is undefined behavior: you get what you get. The spec does not have anything to say about what happens when that occurs. It doesn't say anything about whether it triggers a memory access or not... it says absolutely nothing about it.

As an effect of the rules codified in [intro.multithread], the compiler is effectively allowed to optimize its code as if a thread was operating in complete isolation unless a threading primitive (such as a mutex or atomic) forces otherwise. This includes all the usual elisions, such as not reading from memory if you don't have to.