yes I also noticed it. Thanks for the reply, I'll look into it.

Ab.
http://joehacker.blogspot.com

IMO the semantics are exactly the same, in what sense would they be
different?
The JIT compiler generates exactly the same native X86 instructions from the
IL stream as the C compiler back-end does from the C token stream for
volatile field accesses.

That means that following C# snip:

static volatile int v;
int u;
..

v = 0;
// other C# code statements that don't use i
...
u = i;

effectively writes the value 0 to the "memory location" at the point of the
assignment in the source code, and reads the same location back to store the
value in u.

Note that the JIT compiler produces the following X86 stream (comments
added).

xor edx, edx    -> clear edx
mov [0x09122446], edx    -> store edx into location at address 0x09122446
(fictive address)
...// other JITed code
mov eax, [0x09122446]      -> load contents of volatile memory at 0x09122446
into eax
mov [0x0912245a] , eax    -> move value read from volatile field to location
of u.

which is exactly the same as produced by the C++ back-end for the same code
snip.
Note here that the compilers are not allowed to:
- optimize away the first store,
- reuse edx to load the value into u
- to move the first store until after the load of v

So following is not allowed:

...// other JITed code
xor edx, edx    -> clear edx
mov [0x0912245a] , edx    -> don't bother about i and move 0 into u
mov [0x09122446], edx    -> move O into v

while it's perfectly valid for optimized builds when v is not volatile.

Willy.

PS. Note that these kind of optimizations are not (yet) done b the JIT
compiler.