Once more volatile: necessary to prevent optimization?

Question

I've been reading a lot about the 'volatile' keyword but I still don't have a definitive answer.

Consider this code:

class A
{
public:
    void work()
    {
        working = true;

        while(working)
        {
            processSomeJob();
        }
    }

    void stopWorking() // Can be called from another thread
    {
        working = false;
    }
private:
    bool working;
}

As work() enters its loop the value of 'working' is true.

• Now I'm guessing the compiler is allowed to optimize the while(working) to while(true) as the value of 'working' is true when starting the loop.

  • If this is not the case, that would mean something like this would be quite inefficient:

  for(int i = 0; i < someOtherClassMember; i++)
  {
      doSomething(); 
  }
  

  ...as the value of someOtherClassMember would have to be loaded each iteration.

  • If this is the case, I would think 'working' has to be volatile in order to prevent the compiler from optimising it.

Which of these two is the case? When googling the use of volatile I find people claiming it's only useful when working with I/O devices writing to memory directly, but I also find claims that it should be used in a scenario like mine.

Answer 1

Your program will get optimized into an infinite loop^†.

void foo() { A{}.work(); }

gets compiled to (g++ with O2)

foo():
        sub     rsp, 8
.L2:
        call    processSomeJob()
        jmp     .L2

The standard defines what a hypothetical abstract machine would do with a program. Standard-compliant compilers have to compile your program to behave the same way as that machine in all observable behaviour. This is known as the as-if rule, the compiler has freedom as long as what your program does is the same, regardless of how.

Normally, reading and writing to a variable doesn't constitute as observable, which is why a compiler can elide as much reads and writes as it likes. The compiler can see working doesn't get assigned to and optimizes the read away. The (often misunderstood) effect of volatile is exactly to make them observable, which forces the compilers to leave the reads and writes alone^‡.

But wait you say, another thread may assign to working. This is where the leeway of undefined behaviour comes in. The compiler may do anything when there is undefined behaviour, including formatting your hard drive and still be standard-compliant. Since there are no synchronization and working isn't atomic, any other thread writing to working is a data race, which is unconditionally undefined behaviour. Therefore, the only time an infinite loop is wrong is when there is undefined behaviour, by which the compiler decided your program might as well keep on looping.

TL;DR Don't use plain bool and volatile for multi-threading. Use std::atomic<bool>.

_{†Not in all situations. void bar(A& a) { a.work(); } doesn't for some versions.
‡Actually, there is some debate around this.}

Answer 2

Now I'm guessing the compiler is allowed to optimize the while(working) to while(true)

Potentially, yes. But only if it can prove that processSomeJob() does not modify the working variable i.e. if it can prove that the loop is infinite.

If this is not the case, that would mean something like this would be quite inefficient ... as the value of someOtherClassMember would have to be loaded each iteration

Your reasoning is sound. However, the memory location might remain in cache, and reading from CPU cache isn't necessarily significantly slow. If doSomething is complex enough to cause someOtherClassMember to be evicted from the cache, then sure we'd have to load from memory, but on the other hand doSomething might be so complex that a single memory load is insignificant in comparison.

Which of these two is the case?

Either. The optimiser will not be able to analyse all possible code paths; we cannot assume that the loop could be optimised in all cases. But if someOtherClassMember is provably not modified in any code paths, then proving it would be possible in theory, and therefore the loop can be optimised in theory.

but I also find claims that [volatile] should be used in a scenario like mine.

volatile doesn't help you here. If working is modified in another thread, then there is a data race. And data race means that the behaviour of the program is undefined.

To avoid a data race, you need synchronisation: Either use a mutex, or atomic operations to share access across threads.

Answer 3

Volatile will make the while loop reload the working variable on every check. Practically that will often allow you to stop the working function with a call to stopWorking made from an asynchronous signal handler or another thread, but as per the standard it's not enough. The standard requires lock-free atomics or variables of type volatile sig_atomic_t for sighandler <-> regular context communication and atomics for inter-thread communication.