C++ volatile keyword with global shared variable accessed by function

Question

Hi,

I have a multi-threaded C++ application.

Now I know that for global shared variables, you should use volatile in some cases while checking the state of the variable or else the compiler could assume that the variable's value never changes (in that thread).

What if, however, instead of checking the status of a variable I call a method that returns the value of the variable? For instance:

static int num = 0;

...

void foo()
{
   while(getNum() == 0)
   {
      // do something (or nothing)
   }
}

Would I still have to make num a volatile variable? or does the compiler recognize that since I'm using a method to access that variable num it won't cache the result?

Anyone got any ideas?

Thanks in advance,

~Julian

edit: inside my while loop I removed the sleep call and replaced it with something generic such as a comment to do something (or nothing)

Answer 1

No, volatile is never needed as long as you're doing the necessary synchronization.

Calling thread library synchronization functions, whatever they are on your platform, should take care of invalidating locally "cached" values and making the compiler reloads globals.

In this particular case, sleep is likely to have such an effect, but it's not a good implementation anyway. There should be a condition variable on num, protect it with a setter function, and have the setter function send a signal to foo.

As to the specific question, whether the function hides the access from optimization is extremely implementation- and situation-dependent. Your best bet is to compile the getter function in a separate invokation of the compiler, but even then, there's no way to guarantee that interprocedural optimization doesn't occur. For example, some platforms may put IR code in the .o files and perform code generation in the "linker" stage.

Disclaimer.

Key words above: 1. as long as you're doing the necessary synchronization and 2. likely to have such an effect.

1: sleep or an empty busy-loop are not "necessary synchronization." That is not the correct way to write a multithreaded program, period. So, volatile may be needed in such cases.

2: Yes, sleep may not be counted by the implementation an I/O function, and may even be labeled as pure and free of side-effects. In that case, volatile on the global would be necessary. However, I doubt any implementations have really been distributed which would break sleep loops like that, since they are unfortunately common.

Answer 2

technically it does need to be marked volatile. Compilers are free to do what they want in order to optimise code as long as it continues to conform to the c++ abstract machine spec. A conforming compiler, with enough resources, could inline all instances of getNum, move the value of num into a register (or simply, noticing that its never actually changed by any code, treat it as a constant) for the entire lifetime of the program.

Practically speaking, no (current) CPU has enough free registers that even the most agressive optimizing compiler would choose to do that. But if correctness is desired - volatile is required.

Answer 3

What you propose is basically a misuse of "volatile", its real purpose is to tell the compiler that the variable may be modified by external hardware or another process in the system, therefore, it needs to be really read from memory everytime its used.

It will not protect you from thread collisions etc. within your program, although in your case it looks like you are using the flag to signal a shutdown request.

Its actually OK to do this without synchronising etc. provided you know that only a single controlling thread will update the variable. Also I would use a bit manipulation to set the flag as this is more likely to be "atomic" on more hardware.

num && x'00000001' 

Answer 4

Unfortunately volatile semantics are kinda wishy-washy. The concept of volatile wasn't really meant to be used for threading.

Potatoswatter is correct that calling the OS synchronization primitives will normally prevent the optimizing compiler from hoisting the read of num from the loop. But it works for sorta the same reason that using an accessor method works... by accident.

The compiler sees you calling a function that isn't immediately available for inlining or analysis, so it has to assume that any variable that could be used by some other function might be read or altered in that opaque function. So before doing the call, the compiler needs to write all those "global" variables back to memory.

At corensic, we added an inline function to jinx.h that does this in a more direct way. Something like the following:

 inline void memory_barrier() { asm volatile("nop" ::: "memory"); }

This is rather subtle, but it effectively tells the compiler (gcc) that it can't get rid of this chunk of opaque asm and that the opaque asm can read or write any globally visible piece of memory. This effectively stops the compiler from reordering loads/stores across this boundary.

For your example:

memory_barrier(); while (num == 0) { memory_barrier(); ... }

Now the read of num is stuck in place. And potentially more importantly, it's stuck in place with relation to other code. So you could have:

 while (flag == 0) { memory_barrier(); }  // spin
 process data[0..N]

And another thread does:

 populate data[0..N]
 memory_barrier();
 flag = 1;

PS. If you do this type of thing (essentially creating your own synchronization primitives) the perf wins can be big but the quality risk is high. Jinx is particularly good at finding bugs in these lock-free structures. So you might want to use it or some other tool to help test this stuff.

PPS. The linux community has a nice post about this called "volatile considered harmful", check it out.