I don’t think there’s a better person to answer this than Eric Lippert (emphasis in the original):
In C#, “volatile” means not only “make sure that the compiler and the
jitter do not perform any code reordering or register caching
optimizations on this variable”. It also means “tell the processors to
do whatever it is they need to do to ensure that I am reading the
latest value, even if that means halting other processors and making
them synchronize main memory with their caches”.Actually, that last bit is a lie. The true semantics of volatile reads
and writes are considerably more complex than I’ve outlined here; in
fact they do not actually guarantee that every processor stops what it
is doing and updates caches to/from main memory. Rather, they provide
weaker guarantees about how memory accesses before and after reads and
writes may be observed to be ordered with respect to each other.
Certain operations such as creating a new thread, entering a lock, or
using one of the Interlocked family of methods introduce stronger
guarantees about observation of ordering. If you want more details,
read sections 3.10 and 10.5.3 of the C# 4.0 specification.Frankly, I discourage you from ever making a volatile field. Volatile
fields are a sign that you are doing something downright crazy: you’re
attempting to read and write the same value on two different threads
without putting a lock in place. Locks guarantee that memory read or
modified inside the lock is observed to be consistent, locks guarantee
that only one thread accesses a given chunk of memory at a time, and so
on. The number of situations in which a lock is too slow is very
small, and the probability that you are going to get the code wrong
because you don’t understand the exact memory model is very large. I
don’t attempt to write any low-lock code except for the most trivial
usages of Interlocked operations. I leave the usage of “volatile” to
real experts.
For further reading see: