SemaphoreSlim.WaitAsync vs lock for asynchronous resource throttling

Direct answer

No. SemaphoreSlim.WaitAsync does not consistently outperform lock. On .NET 8, lock usually has lower average latency when contention is light or moderate because it avoids async state-machine allocation and task resumption. SemaphoreSlim.WaitAsync is the better choice primarily when peak concurrency is high enough to risk thread-pool starvation; it returns the thread to the pool while waiting, which can reduce tail latency at the cost of per-acquisition overhead.

Confirmed behavior versus likely explanation

Confirmed: lock is synchronous, re-entrant, and blocks the executing thread. SemaphoreSlim.WaitAsync is asynchronous, not re-entrant, and releases the thread while a waiter is pending. Both provide mutual exclusion.

Likely explanation for latency spikes: Under heavy contention, threads parked inside lock can exhaust the thread pool, so new requests wait for a thread before they even reach the critical section. That scheduling delay often dominates p99 latency. SemaphoreSlim.WaitAsync removes the thread from the wait, but every wait still carries async state-machine and callback overhead, which can dominate when waits are short and contention is low.

Processing order under extreme contention

SemaphoreSlim admits waiters in FIFO order, but admission order is not the same as completion order. After the semaphore releases, waiting tasks resume through the thread pool, and under heavy load the pool may run them on different threads or delay some callbacks. Treat the order as approximate, not guaranteed. If strict request sequencing is required, use a single-consumer queue such as Channel instead of relying on semaphore fairness.

Steps for this case

1. Measure peak concurrent requests and check whether thread-pool thread count approaches its limit during traffic spikes.
2. If threads are never exhausted, prefer lock for lower overhead and simpler code.
3. If thread-pool starvation is observed, use SemaphoreSlim.WaitAsync, set the initial count to match resource capacity, and release in a finally block.
4. Avoid lock around an await when running on a UI or legacy ASP.NET synchronization context; blocking that context can deadlock.

Verification

Run a scoped comparison in your target environment:

var semaphore = new SemaphoreSlim(initialCount: 1, maxCount: 1);
await semaphore.WaitAsync();
try
{
    // critical section
}
finally
{
    semaphore.Release();
}

Record average and p99 latency for both lock and SemaphoreSlim.WaitAsync while logging available thread-pool threads. Repeat with semaphore counts of 1, 10, and 100 to observe how the limit shapes tail latency.

Missing diagnostic detail: Does this code run on a synchronization context where blocking the thread could deadlock, such as WinForms, WPF, or legacy ASP.NET? If yes, avoid lock around asynchronous waits and use SemaphoreSlim.WaitAsync or a channel-based queue regardless of contention.

Assumptions: .NET 8 runtime. No specific throughput or latency measurements are claimed; verify in your own load profile.