Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Why is it dangerous to get rid of volatile?

Tags:

c++

volatile

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.

like image 865
zneak Avatar asked Aug 04 '10 23:08

zneak


2 Answers

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;
}
like image 161
Michael Burr Avatar answered Oct 14 '22 18:10

Michael Burr


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.

For example, it is perfectly legal for the C++03 compiler to transform

int result;
void sum_if_all_positive( std::array<N> ary )
{
    int sum = 0;
    result = -1;
    for( int i = 0; i < N; ++i ) {
        if (ary[i] < 0) return;
        sum += ary[i];
    }
    result = sum;
}

into

int result;
void sum_if_all_positive( std::array<N> ary )
{
    result = 0;
    for( int i = 0; i < N; ++i ) {
        if (ary[i] < 0) { result = -1; return; }
        result += ary[i];
    }
}

(Although such a change would provide better performance than enregistering sum only on a few architectures with cheap memory access and very few registers. The Microchip PIC architecture comes to mind.)

like image 20
Ben Voigt Avatar answered Oct 14 '22 17:10

Ben Voigt