Volatile is Evil

In Java there are also static inner classes and static initializers (static code blocks that initialize static data)

"It used to have a very specific purpose - to enure memory operations with external side-effects did not get reordered"

Prevent reordering? I thought thats what memory fences are for.

--

I admit to having a (single) volatile varibale in my C++ codebase, used similarly to the pseudocode below:

    volatile global bool flag = false; // [1]

    thread1 {
        while (whatever) {
            do stuff
        }
        flag = true;
        thread2.wait();
    }
    
    thread2 {
        while (!flag) { // [2]
            do stuff
        }
    }

[1] The variable itself is global, because I read someplace that the C/C++ standard does not allow local volatile variables to be passed to other threads. Logically, this makes sense, if a local goes out of scope before the second thread is finished with it. In my code this cannot happen, but I still make it global anyway.

[2] The important part is that this read is very fast unless the flag has been set (at which point I no longer care about efficiency). I don't mind if this is unsynchronized - if the loop runs an extra few iterations, that is perfectly fine, as long as the flag change is seen eventually (realistically, within a few iterations of the loop). I know that volatile only makes sure the compiler doesn't cache the value in registers and does not mean that the value will be synced or flushed or otherwise ensure it is visible by the other thread. On x86 at least, it will be, eventually.

My logic for using it in this way is as follows:

I do not care about synhronization - if the reader sees a stale value of flag, that is fine, as long as it sees the real value at some point in the future. I use volatile, because otherwise the compiler could simply cache the flag in a register completely isolated form the other thread. I also don't mind if the read is reordered, as long as it is within the loop and the value is used as the loop temrination condition (from what I read on the Intel site[3], the above code guarantees this - but the read may be reordered to appear elsewhere WITHIN the loop instead. This is perfectly fine in my case). I do need the write to appear AFTER the loop in thread1 and before the wait, however - again, afaik I don't need to do anything here, or should I put an sfence before the flag=true to be safe? Since I don't care about performance in the flag is true case, I don't mind adding memory fences in this case.

I wonder if somebody can let me know if my logic is off here (though it works on x86 and x86-64 and, accoridng to something I read on the Intel site[3], is a reasonable approach - however, I may port to ARM at some stage, in which case I will need to re-evaluate this code). My aim here is that the reader always reads the flag from the processor cache, so that its fast, but when the writer sets the flag, the cache is synced over the core interconnect and the second thread will, at some stage, see the new value.

Is this approach reasonable? Is it safe? I believe it is, but..

[3] http://software.intel.com/en-us/blogs/2007/11/30/volatile-al... Tenth comment down, posted by "spud".

This article describes how a volatile variable can be useful when dealing with excess floating-point precision:

http://blog.jagpdf.org/2009/07/avoiding-excess-floating-poin...

[1] I can't for the life of me find where I saw that the standard considers passing local volatile variables to other threads (I suspect it didn't say threads, but rather something else under which threads can be implied).

[2] Implied by the original usage of volatile? It certainly isn't implied now (or at least, people think it is, even though, according to the standard, it really isn't).

Because it does. Are you sure you aren't misunderstanding the meaning of volatile in C99 (and the C++03 standard has the same semantics for volatile as C99, it even refers back to C99 in a footnote)?

The C standard has no notion of the memory hierarchy and therefore does not know or care about the processor cache. Volatile means that reading/writing from/to volatile variables must strictly follow the rules of the abstract machine, and not bypass these rules as an optimization. When people say that volatile means that the value may not be cached, they mean that the variable MUST be written to or read from every time it is accessed. This means it may not be cached in a register or otherwise avoid the actual variable access as an optimization, that is, that it may not bypass interacting with the abstract machine. What this means is that a memory read or write must be issued, but the existance of processor caches (L1, L2, L3) is outside the scope of the abstract machine and is a platform detail.

On x86 and x86-64, reading or writing memory using temporal load and store instructions lets the CPU, if it feels like it, cache the value in the processor cache. As far as C knows or cares, its in memory, but its up to the CPU to decide if it actually is or not. This means that in practice, if the variable is accessed often, it would be in L1 or L2 cache and reading it would be quite fast. When writing to it (since it is volatile, a write is a store to memory instead of a mov to a register), the processor sees that the cache has changed and invalidates it for other cores, so the next read would hit main memory and get the new value.

Note that non of this is visible in the generated ASM (unless the compiler generated non-temporal loads/stores, in which case the rocessor cache would be bypassed), as it is applied transparently by the processor.

For the record, before I wrote this code, I researched it a lot. Also, Arch Robinson, the architect behind Intel Threading Building Blocks, in the comments to his article on volatile, confirmed that this works (at least on intel platforms). Furthermore, nothing I've read in the standard or other articles (such as the one you linked) contradict my assumptions. Note that anywhere I have tested this, it works as expected. I am interested in hearing if I overlooked soemthing fundamental, though, especially when porting to ARM (which, for example, may require additional instructions to make writes visible to other cores, something volatile will NOT do).

The C standard only states:

    An object that has volatile-qualified type may be
    modified in ways unknown to the implementation or have
    other unknown side effects. Therefore any expression
    referring to such an object shall be evaluated strictly 
    according to the rules of the abstract machine, as
    described in 5.1.2.3. Furthermore, at every sequence
    point the value last stored in the object shall agree
    with that prescribed by the abstract machine, except as
    modified by the unknown factors mentioned previously.)
    What constitutes an access to an object that has
    volatile-qualified type is implementation-defined.