Both C and C++ defines volatile as something like "Access to volatile objects are evaluated strictly according to the rules of the abstract machine." (exact wording from some old draft of C++0x I have here) with C explicitly noting that "What constitutes an access to an object that has volatile-qualified type is implementation-defined." (ISO 9899 6.7.3.6). So there is not many to say about what volatile means without knowing exact implementation (and implementation should document what volatile exactly means).

I don't see what Microsoft could do to unilaterally change meaning of something that is almost completely implementation-defined.

I'm not so sure that your reading of the standard is correct. From n1256.pdf, the essentially unchanged and freely available draft of the C99 standard:

(5.1.2.3.2): Accessing a volatile object, ..., or calling a function that does any of those operations are all side effects...

(5.1.2.3.3): In the abstract machine, all expressions are evaluated as specified by the semantics. An actual implementation need not evaluate part of an expression if it can deduce that its value is not used and that no needed side effects are produced (including any caused by calling a function or accessing a volatile object).

It does not look like this allows an implementation complete freedom in deciding what constitutes an "access". In fact, I'm pretty certain that 'volatile int i; i;' is required to access i exactly once. (There are plenty of optimizer bugs in this area, but these are bugs.)

(Note that the above has nothing to do with threads and everything with memory-mapped devices. Perhaps you were thinking of threads? These are not part of the C standard, though.)

(6.7.3.6): What constitutes an access to an object that has volatile-qualified type is implementation-defined.

That seems to me like giving 'complete freedom in deciding what constitutes an "access"'. Or almost.

Actually, chapter 4.10 of GCC 4.4 manual documents how is this defined by GCC and explicitly states, that discarding result of read of volatile object does not always cause access to such object.

You are arguing against a straw-man. I wasn't talking about the standard. The behaviour is, as you say, implementation defined. So, Microsoft are perfectly free to implement volatile access from multiple threads as re-formatting the hard-drive or whatever.

What I did say is that Microsoft have chosen to implement volatile access in a way that is incompatible with other compilers. Their choice to put the barriers in for you is certainly well-intentioned, but really just complicates matters.

when talking about different things in different languages I always shudder and have to think about "static", going from java to c++ this was horrible

'static' in C is the worst - it has 2 different meanings within the same language. Does anyone know the reason for this confusing design decision?

Reason for this is that static actually does exactly same thing in both cases: defines global variable without externally accessible name and makes it accessible in enclosing scope. (exact standarteese being "internal linkange with static storage duration")

It's actually quite remarkable the number of places a single keyword can be used. We have

  * Static functions in C
  * Static variables in C
  * Static members in C++
  * Static instance variables in Java
  * Static methods in Java

The strange combination of C++'s namespaces and static begets static members, which almost make sense in context. But then Java stole the syntax and not the rest of the language (thank god), leading to its strange, almost contradictory usage.

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