28

I've been reading from many sources that the volatile keyword is not helpful in multithreaded scenarios. However, this assertion is constantly challenged by atomic operation functions that accept volatile pointers.

For instance, on Mac OS X, we have the OSAtomic function family:

SInt32 OSIncrementAtomic(volatile SInt32 *address);
SInt32 OSDrecrementAtomic(volatile SInt32 *address);
SInt32 OSAddAtomic(SInt32 amount, volatile SInt32 *address);
// ...

And it seems that there is a similar usage of the volatile keyword on Windows for Interlocked operations:

LONG __cdecl InterlockedIncrement(__inout LONG volatile *Addend);
LONG __cdecl InterlockedDecrement(__inout LONG volatile *Addend);

It also seems that in C++11, atomic types have methods with the volatile modifier, which must somehow mean that the volatile keyword has some kind of relationship with atomicity.

So, what am I missing? Why do OS vendors and standard library designers insist on using the volatile keyword for threading purposes if it's not useful?

Community
  • 1
  • 1
zneak
  • 134,922
  • 42
  • 253
  • 328

4 Answers4

22

Volatile isn't useless for shared access by multiple threads - it's just that it's not necessarily sufficient:

  • it doesn't necessarily provide the memory barrier semantics that might be required;
  • it doesn't provide guarantees of atomic access (for example if the volatile object i s larger than the platform's native memory word size)

Also, you should also note that the volatile qualifier on the pointer arguments to the APIs in your example really only really adds the ability for the APIs to receive pointers to volatile objects without complaint - it doesn't require that the pointers point to actual volatile objects. The standard allows a non-qualified pointer to be automatically converted to a qualified pointer. Automatically going the other way (qualified pointer to non-qualified) isn't provided for in the standard (compilers typically allow it, but issue a warning).

For example, if InterlockedIncrement() were prototyped as:

LONG __cdecl InterlockedIncrement(__inout LONG *Addend);  // not `volatile*`

The API could still be implemented to work properly internally. However, if the user had a volatile obeject that he wanted to pass to the API, a cast would be required to keep the compiler from throwing a warning.

Since (necessary or not), these APIs are often use with volatile qualified objects, adding the volatile qualifier to the pointer argument prevents useless diagnostics from being generated when the API is used, and harms nothing when the API is used with a pointer to a non-volatile object.

Michael Burr
  • 333,147
  • 50
  • 533
  • 760
18

It suddenly came to me that I simply misinterpreted the meaning of volatile*. Much like const* means the pointee shouldn't change, volatile* means that the pointee shouldn't be cached in a register. This is an additional constraint that can be freely added: as much as you can cast a char* to a const char*, you can cast an int* to a volatile int*.

So applying the volatile modifier to the pointees simply ensures that atomic functions can be used on already volatile variables. For non-volatile variables, adding the qualifier is free. My mistake was to interpret the presence of the keyword in the prototypes as an incentive to use it rather than as a convenience to those using it.

zneak
  • 134,922
  • 42
  • 253
  • 328
  • It also makes `volatile` useful for preventing you from accidentally passing a shared variable by reference to a function that isn't thread-aware. – Ben Voigt Aug 19 '13 at 18:19
2

C++11 has atomics for both volatile and non-volatile variables.

If the compiler intrinsics take a pointer to volatile int, that means you can use it even if the variable is volatile. It doesn't stop you from using the function on non-volatile data.

Bo Persson
  • 90,663
  • 31
  • 146
  • 203
1

Well, the keyword 'volatile' makes sure the compiler always loads/stores the value of a variable from/to memory everytime the variable shows up in your code.
This prevents certain optimizations e.g. that the value is simply loaded into a register once and then used multiple times.
It is useful when you have multiple threads that can modify 'shared' variables between the threads. You will have to make sure to always load/store the value from/to memory in order to check for its value that can have been modified by another thread. If volatile was not used the other thread might not have written the new value to memory (but put it into a register or some other sort of optimization might have taken place) and the first thread would not notice any change of value.

In your cases 'volatile SInt32 *address' tells the compiler that the memory pointed to by address is a subject to change by any source. Hence the need for an atomic operation.

iolo
  • 1,090
  • 1
  • 9
  • 20
  • Your answer too goes in almost direct contradiction with the [blog post from Arch Robinson](http://software.intel.com/en-us/blogs/2007/11/30/volatile-almost-useless-for-multi-threaded-programming/), architect of Threading Building Blocks at Intel, to which I linked in my question. – zneak Jun 18 '11 at 17:47
  • @zneak Actually no. I never mentioned that 'code reordering' would be prevented. It just makes sence to flag 'SInt32 *address' with 'volatile' since it might be subject to change by any outside impact. The atomic operations need to deal with this in order to maintain atomicity. Hence volatile is the correct way to flag this behaviour. – iolo Jun 18 '11 at 17:54