How to Fix Race Condition in C#

Few things halt development faster than an unexpected race condition in C#. The good news is this is a well-understood problem with a clear solution. Let's get you back on track.

Understanding Race Conditions

A race condition in C# occurs when two or more concurrent operations access shared state, and the outcome depends on their execution timing. This leads to intermittent bugs that are notoriously difficult to reproduce because they depend on specific timing that may rarely occur in testing but frequently occurs under production load.

The Fix

private static readonly SemaphoreSlim _semaphore = new(1, 1);

public async Task<int> UpdateCounterAsync(int id)
{
    await _semaphore.WaitAsync();
    try
    {
        var counter = await _db.Counters.FindAsync(id);
        if (counter == null) throw new KeyNotFoundException();
        counter.Value++;
        await _db.SaveChangesAsync();
        return counter.Value;
    }
    finally
    {
        _semaphore.Release();
    }
}

Use SemaphoreSlim for async-compatible locking in C#. Always release in a finally block to prevent deadlocks.

Detection Strategies

• Add structured logging with timestamps around critical sections to identify interleaving
• Use stress testing and concurrent load testing to increase the probability of reproducing the race
• Review all shared mutable state that is accessed from async code paths or multiple threads
• Consider database-level locking (SELECT FOR UPDATE, optimistic locking) for distributed systems

Prevention

• Prefer immutable data structures where possible
• Use atomic operations for simple counters and flags
• Design APIs to be idempotent so duplicate executions are harmless

Race conditions are among the hardest bugs to catch in testing. [Bugsly](https://bugsly.dev) helps by correlating error timing patterns and identifying failures that cluster under high concurrency in your C# application.