What is SpinLock, and when (if ever) should you use it instead of lock?

1. How SpinLock.Enter works

Enter(ref taken):
  try CompareExchange(owner, me, free)        -> success: taken = true, return
  loop:
     SpinWait.SpinOnce()                        -> early: spin with CPU pause instructions
                                                -> later: Thread.Yield / Sleep(0) / Sleep(1)
     retry CompareExchange

SpinWait adapts: it spins a few iterations, then starts yielding the time slice, and eventually sleeps, so a long wait degrades gracefully, but you've still paid for the spinning.

2. lock already spins

Monitor.Enter and Lock.Enter both spin adaptively for a short time before blocking on a kernel wait. The runtime tunes the spin count based on processor count and recent success. For most code this hybrid gives the same uncontended speed as a spin lock and far better behaviour under real contention.

3. The copy problem, concretely

private readonly SpinLock _s = new(false);   // BUG

public void Add()
{
    bool taken = false;
    _s.Enter(ref taken);   // compiler makes a defensive copy of the readonly struct -> locks the copy
    _count++;              // unprotected
    _s.Exit();             // exits another copy
}

Correct:

private SpinLock _s = new(enableThreadOwnerTracking: false);   // mutable field, accessed directly

Analyzers/IDE warnings can flag defensive copies; code review should too.

4. Why removing contention usually wins

// Striped counters: one slot per CPU-ish index, padded to avoid false sharing
private readonly PaddedLong[] _slots = new PaddedLong[Environment.ProcessorCount];

public void Increment()
{
    int i = Thread.GetCurrentProcessorId() % _slots.Length;
    Interlocked.Increment(ref _slots[i].Value);
}

public long Total() => _slots.Sum(s => Volatile.Read(ref s.Value));

[StructLayout(LayoutKind.Explicit, Size = 128)]
struct PaddedLong { [FieldOffset(64)] public long Value; }

No lock, little sharing between cores, and no false sharing thanks to padding.

5. Measuring correctly

• BenchmarkDotNet with realistic thread counts (including more threads than cores).
• Record CPU time, not just throughput or latency.
• Use [ThreadingDiagnoser] for lock contention counts and work-item counts.
• Test on the production core count; spin locks behave very differently on 4 vs 64 cores.

6. Version notes

7. Try it yourself

1. Run the code example; then make _spin readonly and see the total come out wrong.
2. Benchmark lock, Lock, SpinLock and Interlocked.Add for 8 threads incrementing a counter.
3. Add Thread.Sleep(0) inside the critical section and compare CPU usage between lock and SpinLock.
4. Run with 4× more threads than cores and observe SpinLock degrade.
5. Enable owner tracking and re-enter to see LockRecursionException.
6. Implement the striped counter and compare with all of the above.

using System.Threading;

var counter = new HotCounter();
await Task.WhenAll(Enumerable.Range(0, 8).Select(_ => Task.Run(() =>
{
    for (int i = 0; i < 100_000; i++) counter.Add(1);
})));
Console.WriteLine(counter.Total); // 800000

public sealed class HotCounter
{
    // NOT readonly: a readonly struct field would be copied on each call.
    private SpinLock _spin = new(enableThreadOwnerTracking: false);
    private long _total;

    public long Total => Interlocked.Read(ref _total);

    public void Add(long value)
    {
        bool taken = false;
        try
        {
            _spin.Enter(ref taken);
            _total += value; // a few instructions only
        }
        finally
        {
            if (taken) _spin.Exit(useMemoryBarrier: false);
        }
    }
}
// In real code, Interlocked.Add(ref _total, value) is simpler and faster here.