If volatile is useless for threading, why do atomic operations require pointers to volatile data?

Question

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?

Answer 1

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.