What is the difference, if any, of the Read(Int64) method of the .NET system classes System.Threading.Volatile and System.Threading.Interlocked?
Specifically, what are their respective guarantees / behaviour with regard to (a) atomicity and (b) memory ordering.
Note that this is about the Volatile class, not the volatile (lower case) keyword.
The MS docs state:
Volatile.Read Method
Reads the value of a field. On systems that require it, inserts a memory barrier that prevents the processor from reordering memory operations as follows: If a read or write appears after this method in the code, the processor cannot move it before this method.
...
Returns
Int64The value that was read. This value is the latest written by any processor in the computer, regardless of the number of processors or the state of processor cache.
vs.
Interlocked.Read(Int64) Method
Returns a 64-bit value, loaded as an atomic operation.
Particularly confusing seems that the Volatile docs do not talk about atomicity and the Interlocked docs do not talk about ordering / memory barriers.
Side Note: Just as a reference: I'm more familiar with the C++ atomic API where atomic operations always also specify a memory ordering semantic.
The question link (and transitive links) helpfully provided by Pavel do a good job of explaining the difference / ortogonality of volatile-as-in-memory-barrier and atomic-as-in-no-torn-reads, but they do not explain how the two concepts apply to these two classes.
Volatile.Read make any guarantees about atomicity?Interlocked.Read (or, really, any of the Interlocked functions) make any guarantees about memory order?Interlocked.Read translates into a CompareExchange operation:
public static long Read(ref long location)
{
return Interlocked.CompareExchange(ref location, 0, 0);
}
Therefore it has all the benefits of CompareExchange:
Volatile.Read on the other hand has only acquire semantics. It helps you ensuring the execution order of your read operations, without any atomicity or freshness guarantee.