Why is it dangerous to get rid of volatile?

Question

Hello guys,

In C++, volatile is treated the same way const is: passing a pointer to volatile data to a function that doesn't want the volatile modifier triggers a compile error.

int foo(int* bar) { /* snip */ }

int main()
{
    volatile int* baz;
    foo(baz); // error: invalid conversion from ‘volatile int*’ to ‘int*’
}

Why is it dangerous? It's obvious for the const modifier that removing it can break const correctness; but is there such a thing as "volatile correctness"? I can't figure out how passing a pointer to volatile data as a pointer to non-volatile data could cause problems.

EDIT Just so you guys know why I was using volatile in the first place: many of Mac OS X's OSAtomic family of functions (for atomic increments, decrements, additions, subtractions, compare and swap, etc.) takes volatile arguments.

Answer 1

Well, in foo() the compiler no longer knows that baz (or more strictly bar) is volatile and so may attempt to apply some inappropriate optimisations.

Answer 2

Because the volatile modifier means that the compiler must take care to actually perform each read/write of the volatile data item exactly as the C standard's 'abstract machine' specifies.

When the volatile modifier is stripped away, the data accesses can be optimized away as long as the program behaves 'as if' the access occurred as far as the single-threaded viewpoint of the program flow of control is concerned. In other words, the compiler can treat a non-volatile piece of data as if the compiler and only the compiler can see and can modify the data item (which is the case in the vast majority of cases).

The volatile keyword tells the compiler that something else (hardware or another thread of execution) can modify or see that data item, so the compiler isn't permitted to optimize away accesses.

If you could pass a pointer to a volatile piece of data to a function that took a non-volatile pointer without warning, the function might not see a change in the data that might occur. If you don't care about that, you might be able to code up a nice, portable workaround (depending on what foo() does with the data):

int foo(int* bar) { /* snip */ }

int main()
{
    volatile int* baz;

    int tmp = *baz;
    foo(&tmp);
    *baz = tmp;
}

Answer 3

The volatile keyword means that the value should be loaded and stored from/to memory every time.

Consider the code:

int foo(int* bar) { 
    while(*bar){ 
        //Do something...
    }
}

int main()
{
    volatile int num = 1;
    volatile int* baz = #
    //Start a seperate thread to change *baz evenutally... 
    foo(baz);
}

When the compiler sees the while loop, and knows that what is pointed to by bar is always going to be 1. Why should it have to check every time? It would be extremely wasteful to check every time. volatile makes sure that the compiler does do this check every time, so when the other thread changes the value, the while loop exits.

Answer 4

Not only can the compiler optimize away access to non-volatile variables, it can update them predictively/speculatively, as long as the sequential execution of the program is unaffected.

If spurious writes to your volatile variable don't break your design, it probably didn't need to be volatile in any context.