Locks, Interlocked and the .NET memory model

Four threads each added 1 to the same counter a million times, and the counter ended at 1,328,193 instead of 4,000,000: 2,671,807 additions vanished without an error. value++ reads the field, adds 1 and writes it back, and another thread can run between those steps.

You will reproduce that race, fix it with locks and with Interlocked, and see what the .NET memory model lets the compiler and the processor do with reads and writes that nothing protects.

value++ is three steps, and another thread can come between them

race.cs starts four threads at the same moment with a barrier, and each adds 1 to one counter a million times: with no lock, inside a lock, and with Interlocked.Increment.

using System.Diagnostics;

// Four threads each add 1 to the same counter a million times, in three ways.
const int Threads = 4;
const int PerThread = 1_000_000;
Console.WriteLine($"{Threads} threads x {PerThread:N0} additions: {Threads * PerThread:N0} expected");

Run("value++, no lock", c => c.AddUnsafe());
Run("lock on a Lock", c => c.AddLocked());
Run("Interlocked.Increment", c => c.AddAtomic());

void Run(string name, Action<Counter> add)
{
    var counter = new Counter();
    using var start = new Barrier(Threads + 1);
    var workers = new Thread[Threads];
    for (int t = 0; t < Threads; t++)
    {
        workers[t] = new Thread(() =>
        {
            start.SignalAndWait(); // every thread starts at the same moment
            for (int i = 0; i < PerThread; i++)
            {
                add(counter);
            }
        });
        workers[t].Start();
    }

    start.SignalAndWait();
    var watch = Stopwatch.StartNew();
    foreach (Thread worker in workers)
    {
        worker.Join();
    }

    int lost = Threads * PerThread - counter.Value;
    Console.WriteLine($"{name,-22} counted {counter.Value,9:N0}, lost {lost,9:N0}, in {watch.ElapsedMilliseconds} ms");
}

sealed class Counter
{
    private readonly Lock gate = new();
    private int value;

    public int Value => Volatile.Read(ref value);

    public void AddUnsafe() => value++; // read, add, write: three steps another thread can come between

    public void AddLocked()
    {
        lock (gate)
        {
            value++;
        }
    }

    public void AddAtomic() => Interlocked.Increment(ref value);
}

4 threads x 1,000,000 additions: 4,000,000 expected
value++, no lock       counted 1,328,193, lost 2,671,807, in 7 ms
lock on a Lock         counted 4,000,000, lost         0, in 74 ms
Interlocked.Increment  counted 4,000,000, lost         0, in 90 ms

The version with no lock finished in 7 ms and lost 2,671,807 additions. That is a race conditionrace condition: A bug whose result depends on which of two or more threads reaches a piece of code first, so runs of the same program give different results. Two threads running value++ on one field is the classic case: an update can be lost.: the result depends on which thread reaches the code first. Step through one lost update:

Both threads read 41 before either wrote, so both wrote 42. Nothing failed and nothing reported the loss, and its size changes from run to run, so a test on one thread never sees it. The two fixed versions counted all 4,000,000, and took tens of milliseconds where the race took 7: being correct costs time.

A lock runs the steps one thread at a time, and Interlocked makes one step atomic

The lock statement lets one thread at a time run its block. On .NET 9 and later, Microsoft’s guidance is to lock a dedicated System.Threading.Lock: the compiler turns lock (gate) on a Lock into using (gate.EnterScope()), and on any other object into Monitor.Enter and Monitor.Exit in a try and finally, so the lock is released even when the block throws. Never lock this, a Type or a string, which other code can lock too. Locks are held by threads, so an await inside one does not compile; async code uses SemaphoreSlim instead, the tool of the lesson on throttling.

Interlocked turns one operation on one variable into a single atomic operationatomic operation: An operation that other threads see either not at all or completely, never half done. The methods of Interlocked, such as Increment and CompareExchange, are atomic operations on one variable; value++ is not.: Increment, Add, Exchange, and CompareExchange, which writes a new value only if the variable still holds the value you expect. Locks protect any number of steps and fields together; Interlocked protects exactly one.

The third piece is the .NET memory model.NET memory model: The rules for which reads and writes of shared memory one thread may see from another, and in which order. Ordinary reads and writes may be reordered or kept in registers; locks, Interlocked and Volatile.Read and Volatile.Write limit that.. Without a lock, the compiler and the processor may keep a value in a register, merge reads or reorder them, as long as one thread cannot tell. volatile and the Volatile.Read and Volatile.Write methods limit that reordering, but never make ++ atomic, while a lock and every Interlocked method bring the ordering they need. The .NET memory model is why “it worked on my machine” proves nothing about code that shares data without them. Side by side, with what race.cs counted:

The parts below go deeper. A deadlockdeadlock: A state in which pieces of work each wait for another to go first, so none of them can go on. Two threads that each hold a lock the other needs are one case; a thread blocked on a task whose continuation needs that same thread is another. More in “SynchronizationContext, ConfigureAwait and deadlocks” is two threads that each hold a lock the other waits for. Lock.TryEnter with a time limit gives up instead of waiting for ever. Lazy<T> builds a shared object once, on first use. Double-checked locking tests a field before and after taking a lock.

Deadlocks from lock order, reproduced and fixed Pro: opens with a Pro, Premium or Ultimate pass

The .NET memory model: reordering, volatile and safe publication Pro: opens with a Pro, Premium or Ultimate pass

A lab: transfers between accounts without races or deadlocks Pro: opens with a Pro, Premium or Ultimate pass

Practise

The self-check covers the first two sections: why value++ races, and which tool fixes which problem. It starts where your answers so far were least sure:

Interview questions

Fresher · Why is count++ not thread-safe in C#?

count++ on a field is three steps: read the value, add 1, write the result back. Two threads can both read the same value before either writes, and then both write the same result, so one addition is lost without any error. How many are lost changes with timing, so the bug shows under load and rarely in tests. Interlocked.Increment(ref count) makes the three steps one atomic operation; a lock around the update lets one thread at a time run it, which you need when several fields change together. Marking the field volatile does not help: it affects the order of reads and writes, not whether ++ is atomic.

Key takeaways

• value++ is a read, an add and a write, so two threads can read the same value and lose an update: race.cs lost 2,671,807 of 4,000,000 additions.
• A lock on a dedicated System.Threading.Lock runs its block on one thread at a time, and Interlocked makes one operation on one variable atomic.
• Under the .NET memory model ordinary reads and writes may be reordered or kept in registers, and volatile limits that without making ++ atomic.