What does volatile mean in C#, and how do Volatile.Read and Volatile.Write differ from Interlocked?

1. What the hardware actually does

On x64, volatile mostly constrains the JIT (no hoisting, no reordering). On Arm64, it also emits ordering instructions. Either way, write the code against the memory model, not the CPU you test on.

2. The JIT hoisting case

private bool _stop;
public void Run() { while (!_stop) { DoTinyWork(); } }   // may be compiled as: if (!_stop) while (true) DoTinyWork();

The optimiser is allowed to assume no other thread changes _stop unless told otherwise. volatile bool _stop or Volatile.Read(ref _stop) forbids that hoisting. In real code, a CancellationToken is clearer.

3. Store → load reordering (why volatile isn't enough for Dekker)

// Thread A                    // Thread B
Volatile.Write(ref _a, 1);     Volatile.Write(ref _b, 1);
int rb = Volatile.Read(ref _b); int ra = Volatile.Read(ref _a);
// Both ra and rb can be 0!  Each core's store sits in its store buffer while its load executes.

Fix: Interlocked.Exchange for the writes, or Interlocked.MemoryBarrier() between write and read, or a lock.

4. Publishing immutable objects

private Config? _config;

public void Publish(Config c) => Volatile.Write(ref _config, c);   // release: c's fields are visible first
public Config? Current => Volatile.Read(ref _config);               // acquire

This pattern needs no flag. The object must be immutable after publication; if readers might mutate it, you need more.

5. The .NET memory model

The runtime team documents the .NET memory model (in the dotnet/runtime repository) to specify guarantees across platforms: aligned reads and writes up to pointer size are atomic, object reference writes aren't torn, volatile operations have acquire/release semantics, and Interlocked operations are full fences. Some additional guarantees (such as around publishing freshly constructed objects) exist, but code that depends on subtle implicit guarantees is fragile. Prefer explicit Volatile, Interlocked, Lazy<T> or locks.

6. Version notes

7. Try it yourself

1. Run the code example.
2. Write the while (!_stop) loop without volatile in a Release build, run it, and see whether it ever stops (JIT-dependent); then add Volatile.Read.
3. Implement the Dekker test (two threads, two flags) with Volatile and count how often both read 0 over millions of runs; then add Interlocked.MemoryBarrier().
4. Run a publication stress test with plain writes on an Arm64 machine (Apple Silicon or a cloud Arm VM) and compare with x64.
5. View Volatile.Read and Interlocked.Increment in SharpLab's JIT Asm view for x64 and Arm64.

using System.Threading;

var publisher = new Publisher();
var reader = Task.Run(() =>
{
    while (!publisher.TryRead(out var config)) Thread.SpinWait(10);
    Console.WriteLine($"Read config: {publisher.Current!.Name}");
});

Thread.Sleep(50);
publisher.Publish(new Config("prod"));
await reader;

var worker = new StoppableWorker();
var loop = Task.Run(worker.Run);
Thread.Sleep(100);
worker.Stop();
await loop;
Console.WriteLine("Worker stopped");

public sealed record Config(string Name);

public sealed class Publisher
{
    private Config? _current;
    private bool _ready;

    public Config? Current => _current;

    public void Publish(Config c)
    {
        _current = c;                     // 1. write data
        Volatile.Write(ref _ready, true); // 2. release: data visible before flag
    }

    public bool TryRead(out Config? c)
    {
        if (Volatile.Read(ref _ready))   // acquire: later read sees data
        {
            c = _current;
            return true;
        }
        c = null;
        return false;
    }
}

public sealed class StoppableWorker
{
    private volatile bool _stop;          // every access is volatile
    public void Stop() => _stop = true;
    public void Run() { while (!_stop) Thread.SpinWait(100); }
}