the C# compiler, the JIT compiler, or the CPU itself. The guarantees provided by Thread.VolatileRead and Thread.VolatileWrite are a superset of the guarantees provided by the volatile keyword: instead of generating a "half fence" (ie an acquire-fence only prevents instruction reordering and caching that comes before it), VolatileRead and VolatileWrite generate a "full fence" which prevent instruction reordering and caching of that field in both directions. These methods work as follows: The Thread.VolatileWrite method forces the value in the field to be written to at the point of the call. In addition, any earlier program-order loads and stores must occur before the call to VolatileWrite and any later program-order loads and stores must occur after the call. The Thread.VolatileRead method forces the value in the field to be read from at the point of the call. In addition, any earlier program-order loads and stores must occur before the call to VolatileRead and any later program-order loads and stores must occur after the call. The Thread.VolatileRead and Thread.VolatileWrite methods generate a full fence by calling the Thread.MemoryBarrier method, which constructs a memory barrier that works in both directions. In addition to the motivations for using a full fence given above, one potential problem with the volatile keyword that is solved by using a full fence generated by Thread.MemoryBarrier is as follows: due to the asymmetric nature of half fences, a volatile field with a write instruction followed by a read instruction may still have the execution order swapped by the compiler. Because full fences are symmetric, this is not a problem when using Thread.MemoryBarrier. In Fortran VOLATILE is part of the Fortran 2003 standard, although earlier version supported it as an extension. Making all variables volatile in a function is also useful finding aliasing related bugs. integer, volatile :: i ! When not defined volatile the following two lines of code are identical write(*,*) i**2 ! Loads the variable i once from memory and multiplies that value times itself write(*,*) i*i ! Loads the variable i twice from memory and multiplies those values By always "drilling down" to memory of a VOLATILE, the Fortran compiler is precluded from reordering reads or writes to volatiles. This makes visible to other threads actions done in this thread, and vice versa. Use of VOLATILE reduces and can even prevent optimization. References External links Ada Reference Manual C.6: Shared Variable Control Linux kernel: volatile-considered-harmful C