Volatile works correctly on all platforms.

Don't use it as a synchronization primitive, that's not what it's meant to do. You only should use it:

a. If you're reading from HW.

b. If you want to use it like a const marker for member functions.

Here are some other places where volatile is appropriate:

1. Reading or writing shared memory

2. Values which may be modified in signal handlers

3. Implementing atomic types (e.g. boost::atomic)

4. RCU (e.g. ACCESS_ONCE in Linux kernel)

Pretty sure the lack of ordering(memory and execution) semantics for volatile invalidates all of those cases.

Really you should be using the appropriate platform memory and execution barriers in place of volatile 99% of the time.

Barriers are for ordering as you say, which is important, but orthogonal to volatile. Volatile is about enforcing that a particular access occurs.

An illustration:

    static volatile sig_atomic_t interrupted = 0;
    void sigint_handler(int s) { interrupted = 1; }

    void run()
    {
        signal(SIGINT, sigint_handler);
        for (;;)
        {
           if (interrupted) break;
           stuff();
        }
    }

"volatile" is the most precise way to prevent the compiler from hoisting the 'interrupted' access out of the loop. Memory barriers aren't necessary, because the code is single threaded. They may effectively defeat the optimization too, but it's by confusing the compiler instead of informing it.

edit: Oh, and std::atomic is a very bad solution to the above. std::atomic may take locks, which can lead to a deadlock if used in a signal handler!

The way I think of it is that volatile is for making sure the instructions are there and in the right order in the instruction stream. You may need to do other things to get around the processor's side of optimizations like store queues and caches depending on the context.

Thanks for responding here - this is correct. In the case of implementing atomic types (the use case for enkiTS) volatile is a prerequisite but not on its own sufficient - hence I use atomic intrinsics and memory barriers where appropriate. The repository on github notes that I've only implemented these for Windows, Linux and OSX on Intel x86 / x64, but a C++11 branch exists for those who want.

> Reading or writing shared memory

Yeah I was bit by that when writing a shared memory low latency library. When compiled under debug it worked, in release mode values were not being written to the shared memory area. Added some "volatile"-s in there and it worked.

And to be exceedingly pedantic, a signal handler should only modify a 'volatile sig_atomic_t' variable. I assume this is just typedef'd to a machine word on all typical POSIX platforms though.

/volatile the flag is only supported by MSVC as far as I'm aware.

volatile the keyword was not written with the intent of being a memory barrier (edit: or atomicity for that matter) in mind.

In practice, I've created unit tests to catch and fix issues on mobile (specifically iOS - ARM arch, under both GCC and later Clang compilers IIRC) with our "lock free" circular buffer.

It was indeed lock free. And also just plain broken in multi-core scenarios.