Concurrency & Synchronization

A deadlock is when threads wait forever on locks the others already hold, so none can proceed. Thread A takes lock 1 then wants lock 2; thread B takes lock 2 then wants lock 1. Each holds what the other needs, so both block forever.

Lock on a private readonly object that only your class can see. lock(this) publishes the lock, so outside code holding your instance can take it and deadlock you. lock("key") is worse: literals are interned, so that lock is process-wide.

A race condition means the result depends on the unsynchronized interleaving of threads. count++ is not one operation — it reads, adds one and writes back. Two threads can read the same value, both add one and both write back, losing an increment.

Without a lock two threads can interleave inside a read-modify-write and leave the state inconsistent. lock gives mutual exclusion — only one thread at a time holds a given lock object — and it also publishes writes to the next holder.

The thread pool is a runtime-managed set of reusable worker threads. Task.Run queues work onto it, so you skip thread creation and the pool bounds concurrency. Each new Thread costs about 1 MB of stack plus OS setup.

ConcurrentDictionary stripes locks across buckets, so writers on different keys rarely contend and reads take no lock, while a locked Dictionary serializes all access. But GetOrAdd's factory runs outside the lock and can run twice for one key.

lock is sugar for Monitor.Enter/Monitor.Exit in a try/finally; both are in-process and reentrant for the same thread. Monitor adds TryEnter with a timeout plus Wait/Pulse. Mutex is a slower kernel object, shared across processes.

Parallel.ForEach partitions CPU-bound work across pool threads and blocks the caller until it finishes — right for crunching data, wrong for I/O, where it burns a pool thread per operation while await holds none. Its body must be thread-safe.

All four must hold at once: mutual exclusion, hold-and-wait, no preemption, and circular wait. Break any single one and a deadlock cannot form. A global lock ordering removes circular wait; Monitor.TryEnter with a timeout removes hold-and-wait.

Both make the increment atomic. Interlocked.Increment is one lock-free CPU instruction with a full memory barrier — no blocking, no context switch — so it is far cheaper under contention. But it covers one variable only, where a lock covers many.

SemaphoreSlim admits up to N holders, throttling concurrency instead of serializing it to one. Its WaitAsync yields the thread rather than blocking, so it can be held across an await — which lock forbids. It is not reentrant.

BlockingCollection<T> wraps a concurrent collection and blocks a thread in Take() when empty or Add() when full. Channel<T> is the async equivalent: ReadAsync/WriteAsync yield the thread, and a bounded channel makes writers await.

SynchronizationContext is captured at an await, and the continuation is posted back to a UI message loop or ASP.NET's request context. ConfigureAwait(false) skips that capture, so the continuation resumes on a pool thread: no hop, no deadlock.

.Result blocks the UI thread, while the await in FetchAsync captured the dispatcher's SynchronizationContext and posts its continuation back to that blocked loop. Fix it by going async all the way: await the task in an async handler.

Starvation is work queued faster than the pool has threads to run it. Blocking calls — .Result, SemaphoreSlim.Wait(), sync I/O, a blocking Parallel.ForEach body — park pool threads. Past its minimum it adds threads slowly and latency collapses.

Both give every thread its own copy of a value. [ThreadStatic] has no per-thread initializer and starts at default; ThreadLocal<T> takes a factory and initializes lazily. Pool threads are reused, so a stale value leaks into the next work item.

On a new Thread or pool callback an unhandled exception is fatal — the CLR kills the process. Inside a Task it is captured: .Wait()/.Result rethrow it in an AggregateException, await unwraps it, and an unobserved task drops it.

volatile gives ordering, not atomicity: reads have acquire semantics and writes release semantics, so no access moves across them and a write becomes visible to other threads. It does not make count++ atomic — use Interlocked or lock.