Mutexes

A mutex (mutual exclusion lock) has two states, locked and unlocked, and one rule: only the thread that locked it may unlock it. lock() on an unlocked mutex takes it and returns; on a locked one it waits until the owner calls unlock(). That ownership is the difference from a binary semaphore (Semaphores and Condition Variables): because the mutex knows who holds it, it can detect a double-lock by the same thread, refuse an unlock from a stranger, and — with priority inheritance — boost the holder (A Taxonomy of Concurrency Bugs). The mutex is the standard guard for a critical section (Critical Sections).

The contract in every language is the same shape. C++: std::mutex with lock()/unlock(), almost always through std::lock_guard or std::scoped_lock so the unlock happens in the destructor on every exit path, exceptions included. Python: threading.Lock used as with lock:; RLock if the same thread must re-acquire. Go: sync.Mutex with defer mu.Unlock(). Java: synchronized or ReentrantLock. Rust: Mutex<T> where the guard *is* the only way to reach T, so forgetting the lock is a compile error.

JavaScript has no mutex for the shared-memory case because ordinary JavaScript has no shared memory — each realm’s heap is private, and the interleaving points are awaits. When it does share memory, via SharedArrayBuffer between workers, the primitives are Atomics.compareExchange to build a lock word and Atomics.wait/Atomics.notify to sleep and wake on it — a futex, in fact, exposed to the language. Atomics.wait is forbidden on the browser main thread, which must never block.

A naive mutex would be a kernel object and every lock a syscall — 100–300 ns minimum, most of it wasted because most locks are uncontended. Linux’s futex ("fast userspace mutex", 2003) splits the work. The lock is a 32-bit integer in ordinary user memory. lock() is an atomic compare-and-swap (Atomic Operations) from 0 to 1; if it succeeds, the thread owns the mutex and the kernel was never involved — about 20 ns. unlock() is an atomic store of 0. Only when the CAS fails — someone else holds it — does the thread call futex(FUTEX_WAIT), which puts it to sleep on a kernel wait queue keyed by the integer’s address, *after re-checking that the value is still 1* so a wake-up between the check and the sleep is not lost.

The holder, on unlock, must know whether anyone is sleeping, or it would pay a FUTEX_WAKE syscall every time. The standard three-state protocol (Drepper’s "Futexes Are Tricky") encodes it in the same word: 0 unlocked, 1 locked with no waiters, 2 locked with waiters. A contended locker sets 2 before sleeping; an unlocker that sees 2 calls FUTEX_WAKE for one waiter. Uncontended lock and unlock therefore cost two atomics and zero syscalls; contended ones cost a syscall and a context switch each way (a few microseconds), which is the true price of contention.

glibc’s pthread_mutex_t, std::mutex on Linux, Go’s sync.Mutex, Java’s locks under HotSpot and Python’s threading.Lock all reduce to this design. Windows has the same shape with different names: CRITICAL_SECTION spins then waits on a kernel event; SRWLOCK is the leaner modern equivalent; a Mutex handle is the cross-process kernel object and costs a syscall every time. macOS uses os_unfair_lock and ulock.

Waiting has two costs to trade: a spin burns a core but resumes within nanoseconds of the unlock; a sleep frees the core but costs two context switches (~1–5 µs each way) and a wake-up latency that depends on the scheduler. If the holder will be done in 100 ns, sleeping is absurd; if it will be done in 10 ms, spinning is. Most user-space mutexes therefore spin briefly — a few hundred iterations with pause instructions — and then fall back to FUTEX_WAIT. glibc’s PTHREAD_MUTEX_ADAPTIVE_NP adjusts the spin count from recent history; Go’s mutex spins a few times if there are idle cores; Java’s HotSpot does the same.

Pure spinlocks belong in the kernel, where the holder cannot be preempted (the lock disables preemption) and the section is guaranteed short. In user space a spinlock is a trap: if the holder is descheduled — by the timer, or because there are more threads than cores — the spinner burns its whole timeslice waiting for a thread that cannot run *because the spinner is using the core*. The symptom is a process at 100% CPU making no progress — the high-cpu-spin-lock challenge — and the fix is a mutex that sleeps.

A related pathology is the convoy: with a strictly fair (FIFO) lock, every arriving thread queues behind sleeping ones and each handoff requires a wake-up, so the lock’s throughput collapses to one handoff per scheduling latency even though the section is tiny. Unfair locks — where a running thread may grab the lock ahead of a waiter that is still waking — avoid the convoy at the cost of possible starvation; Java’s ReentrantLock(false) and glibc’s default are unfair for exactly this reason.

Two mutexes taken in different orders by two threads is the canonical deadlock (Deadlocks). The discipline is a global lock order — document it, and acquire in that order everywhere — or acquire both at once with std::scoped_lock(m1, m2), which uses a try-lock-and-back-off algorithm that cannot deadlock. Never call unknown code (callbacks, virtual methods on foreign objects, logging with pluggable sinks) while holding a lock; never block on I/O under one (Critical Sections).

Recursive mutexes let the owner re-lock; they exist to paper over designs where a locked function calls another locked function and are usually a smell — the inner function should have an unlocked variant. try_lock returns immediately with failure instead of waiting and is the building block for lock-ordering-free acquisition and for deadlock-avoiding retries. Timed locks (pthread_mutex_timedlock, try_lock_for) turn a hang into an error you can log.

Finally, a mutex is a memory-ordering device as much as an exclusion device: the unlock is a release and the lock an acquire, so everything the previous owner wrote inside the section is visible to the next owner (Atomic Operations). Reading shared data *outside* the lock — "just a quick check" — forfeits that guarantee and reintroduces the visibility bugs of A Taxonomy of Concurrency Bugs.