Difference between Interlocked.Exchange and Volatile.Write?

Question

What is the difference between Interlocked.Exchange and Volatile.Write?

Both methods update value of some variable. Can someone summarize when to use each of them?

• Interlocked.Exchange
• Volatile.Write

In particular I need to update double item of my array, and I want another thread to see the freshest value. What is preferred? Interlocked.Exchange(ref arr[3], myValue) or Volatile.Write(ref arr[3], info); where arr is declared as double?

---

Real example, I declare double array like that:

private double[] _cachedProduct;

In one thread I update it like that:

_cachedProduct[instrumentId] = calcValue;
//...
are.Set();

In another thread I read this array like that:

while(true)
{
    are.WaitOne();
    //...
    result += _cachedProduct[instrumentId];
    //...
}

For me it just works fine as is. However to make sure "it will always work" no matter what it seems I should add either Volatile.Write or Interlocked.Exchange. Because double update is not guaranteed to be atomic.

In the answer to this question I want to see detailed comparison of Volatile and Interlocked classes. Why we need 2 classes? Which one and when to use?

---

Another example, from the implementation of a locking mechanism in an in-production project:

private int _guard = 0;

public bool Acquire() => Interlocked.CompareExchange(ref _guard, 1, 0) == 0;

public void Release1() => Interlocked.Exchange(ref _guard, 0);
public void Release2() => Volatile.Write(ref _guard, 0);

Does it make any practical difference if the users of this API call the Release1 or the Release2 method?

Answer 1

the Interlocked.Exchange uses a processor instruction that guarantees an atomic operation.

The Volatile.Write does the same but it also includes a memory barrier operation. I think Microsoft added Volatile.Write on DotNet 4.5 due to support of ARM processors on Windows 8. Intel and ARM processors differs on memory operation reordering.

On Intel, you have a guarantee that memory access operations will be done in the same order they are issued, or at least that a write operation won't be reordered.

From Intel® 64 and IA-32 Architectures Software Developer’s Manual, Chapter 8:

8.2.2 Memory Ordering in P6 and More Recent Processor Families The Intel Core 2 Duo, Intel Atom, Intel Core Duo, Pentium 4, and P6 family processors also use a processor-ordered memory-ordering model that can be further defined as “write ordered with store-buffer forwarding.” This model can be characterized as follows.

On ARM you don't have this kind of guarantee, so a memory barrier is required. An ARM blog explaining this can be found here: http://blogs.arm.com/software-enablement/594-memory-access-ordering-part-3-memory-access-ordering-in-the-arm-architecture/

In your example, as the operation with double is not guaranteed to be atomic, I would recommend a lock to access it. Remember that you have to use the lock on both parts of your code, when reading and setting the value.

A more complete example would be better to answer your question, as it is not clear what happens after these values are set. For a vector, if you have more readers than writers, consider the use of a ReaderWriterLockSlim object: http://msdn.microsoft.com/en-us/library/system.threading.readerwriterlockslim.aspx

The number of threads and the frequency of read/writes can change dramatically your locking strategy.

Answer 2

If you don't care about the old value, and don't need a full memory barrier (including an expensive StoreLoad, i.e. draining the store buffer before later loads), always use Volatile.Write.

Volatile.Write - atomic release store

Volatile.Write is a store with "release" semantics, which AArch64 can do cheaply, and which x86 can do for free (well, same cost as a non-atomic store, except of course for contention with other cores also trying to write the line). It's basically equivalent to C++ std::atomic<T> store(value, memory_order_release).

For example, in the case of a double, Volatile.Write for x86 (including 32-bit and x86-64) could compile to an SSE2 8-byte store directly from an XMM register, like movsd [mem], xmm0, because x86 stores already have as much ordering as MS's documentation specifies for Volatile.Write. And assuming the double is naturally-aligned (which any C# runtime would do, right?) it's also guaranteed to be atomic. (On all x86-64 CPUs, and 32-bit since P5 Pentium.)

The older Thread.VolatileWrite method in practice uses a full barrier, instead of just being a release operation that can reorder in one direction. That makes it no cheaper than Interlocked.Exchange, or not much on non-x86. But Volatile.Write/Read don't have that problem of an overly strong implementation that some software probably relies on. They don't have to drain the store buffer, just make sure all earlier stores (and loads) are visible by the time this one is.

---

Interlocked.Exchange - atomic RMW plus full barrier (at least acq/rel)

This is a wrapper for the x86 xchg instruction, which acts as if it had a lock prefix even if the machine code omits that. That means an atomic RMW, and a "full" barrier as part of it (like x86 mfence).

In general, I think the Interlocked class methods originated as wrappers for x86 instructions with the lock prefix; on x86 it's impossible to do an atomic RMW that isn't a full barrier. There are MS C++ functions with those names, too, so this history predates C#.

The current documentation for Interlocked methods (other than MemoryBarrier) on MS's site doesn't even bother to mention that these methods are a full barrier, even on non-x86 ISAs where atomic RMW operations don't require that.

I'm not sure if the full barrier is an implementation detail rather than part of the language spec, but it's certainly the case currently. That makes Intelocked.Exchange a poor choice for efficiency if you don't need that.

This answer quotes the ECMA-335 spec as saying that Interlocked operations perform implicit acquire/release operations. If that's like C++ acq_rel, that's fairly strong ordering since it's an atomic RMW with the load and store somewhat tied together, and each one prevents reordering in one direction. (But see For purposes of ordering, is atomic read-modify-write one operation or two? - it's possible to observe a seq_cst RMW reordering with a later relaxed operation on AArch64, within the limits allowed by C++ semantics. It's still an atomic RMW, though.)

@Theodor Zoulias found multiple sources online saying that C# Interlocked methods imply a full fence/barrier. For example, Joseph Albahari's online book: "The following implicitly generate full fences: [...] All methods on the Interlocked class". And on Stack Overflow, Memory barrier generators includes all Interlocked class methods in its list. Both of these may just be cataloguing actual current behaviour, rather than what's mandated by the language spec.

I'd assume there's plenty of code that now depends on it, and would break if Interlocked methods changed from being like C++ std::memory_order_seq_cst to relaxed like the MS docs imply by saying nothing about memory ordering wrt. to the surrounding code. (Unless that's covered somewhere else in the docs.)

I don't use C# myself so I can't easily cook up an example on SharpLab with JITted asm to check, but MSVC compiles its _InterlockedIncrement intrinsic to include a dmb ish for AArch64. (Comment thread.) So it seems MS compilers go beyond even the acquire/release guaranteed by the ECMA language spec and add a full barrier, if they do the same thing for C# code.

BTW, some people only use the term "atomic" at all to describe RMW operations, not atomic loads or atomic stores. MS's documentation says the Interlocked class "Provides atomic operations for variables that are shared by multiple threads." but the class doesn't provide pure stores or pure loads, which is weird.

(Except for Read([U]Int64), presumably intended to expose 32-bit x86 lock cmpxchg8b with desired=expected so you either replace a value with itself or load the old value. Either way it dirties the cache line (so contends with reads by other threads just like any other Interlocked RMW operation) and is a full barrier, so you wouldn't normally read a 64-bit integer this way in 32-bit asm. Modern 32-bit code can just use SSE2 movq xmm0, [mem] / movd eax, xmm0 / pextrd edx, xmm0, 1 or similar, like G++ and MSVC do for std::atomic<uint64_t>; this is much better and can scale to multiple threads reading the same value in parallel without contending with each other.)

(ISO C++ gets this right, where std::atomic<T> has load and store methods, as well as exchange, fetch_add, etc. But ISO C++ defines literally nothing about what happens with unsynchronized read+write or write+write of a plain non-atomic object. A memory-safe language like C# has to define more.)

---

Inter-thread latency

Is it possible that the Volatile.Write has some hidden disadvantage, like updating the memory "less instantaneously" (if this makes any sense) than the Interlocked.Exchange?

I wouldn't expect any difference. Extra memory ordering just makes later stuff in the current thread wait until after a store commits to L1d cache. It doesn't make that happen any sooner, since CPUs already do that as fast as they can. (To make room in the store buffer for later stores.) See Does hardware memory barrier make visibility of atomic operations faster in addition to providing necessary guarantees? for more.

Certainly not on x86; IDK if things could be any different on weakly-ordered ISAs where a relaxed atomic RMW could load+store without waiting for the store buffer to drain, and might "jump the queue". But Interlocked.Exchange doesn't do a relaxed RMW, it's more like C++ memory_order_seq_cst.

---

Examples in the question:

In the first example, with .Set() and .WaitOne() on a separate variable, that already provides sufficient synchronization that a plain non-atomic assignment to a double is guaranteed to be fully visible to that reader. Volatile.Write and Interlocked.Exchange would both be entirely pointless.

For releasing a lock, yes you just want a pure store, especially on x86 where that doesn't take any barrier instructions. If you want to detect double-unlocking (unlocking an already-unlocked lock), load the spinlock variable first, before storing. (That can possibly miss double-unlocks, unlike an atomic exchange, but should be sufficient to find buggy usages unless they always only happen with tight timing between both unlockers.)