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 operatio

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.