Semaphore versus Mutex: Not the Same Primitive

1#include <mutex>
2#include <semaphore>
3 
4std::mutex index_mtx;                       // owned. not reentrant.
5{ std::lock_guard g(index_mtx); mutate(); } // RAII: released on every path
6// index_mtx.unlock() from another thread  -> undefined behaviour
7// index_mtx.lock() twice on one thread    -> undefined behaviour
8std::recursive_mutex rec_mtx;               // the reentrant variant, explicitly
9 
10std::counting_semaphore<1> ready{0};        // no owner. starts empty.
11void loader()  { build_index(); ready.release(); }   // signaller never acquired
12void handler() { ready.acquire(); serve(); }         // different task, legal
13 
14// std::binary_semaphore is counting_semaphore<1>. It is NOT a mutex:
15// no ownership, no reentrancy, no priority inheritance, and no error
16// if a thread that never acquired calls release().

The cleanest separation of the four. std::mutex is explicitly non-reentrant and both misuse cases are undefined behaviour rather than exceptions, so the compiler will not save you.

1import threading
2 
3index_lock = threading.Lock()      # owned-ish: release() from a non-owner raises
4with index_lock: mutate()          # scope-bound
5 
6rec_lock = threading.RLock()       # reentrant: the SAME thread may re-acquire
7with rec_lock:
8    with rec_lock:                 # fine. a plain Lock() would deadlock here.
9        mutate()
10 
11ready = threading.Semaphore(0)     # no owner. any thread may release.
12def loader():  build_index(); ready.release()
13def handler(): ready.acquire(); serve()
14 
15# For readiness that must wake EVERY waiter, a semaphore is wrong:
16ready_evt = threading.Event()      # set() wakes all current and future waiters
17def loader2():  build_index(); ready_evt.set()
18def handler2(): ready_evt.wait(); serve()

Python makes the three cases explicit: Lock for exclusion, RLock when the same thread re-enters, Semaphore for counting or signalling — and Event when readiness must reach all waiters rather than one.

1// No built-in mutex or semaphore, because a synchronous block already
2// runs to completion. What you need is coordination ACROSS awaits.
3 
4// "Mutex": a promise chain. Ownership exists only by convention.
5let tail = Promise.resolve()
6function withLock(fn) {
7  const run = tail.then(fn, fn)
8  tail = run.catch(() => {})        // never let a rejection poison the chain
9  return run
10}
11 
12// Semaphore: a permit count plus a queue of resolvers.
13class Semaphore {
14  #n; #q = []
15  constructor(n) { this.#n = n }
16  acquire() { return this.#n-- > 0 ? Promise.resolve()
17                                   : new Promise(r => this.#q.push(r)) }
18  release() { this.#n++; this.#q.shift()?.() }   // anyone may call this
19}
20 
21// Readiness for many waiters is just a promise everyone awaits:
22const ready = buildIndex()          // one promise, resolved once
23async function handler() { await ready; serve() }

Neither primitive exists natively; both are userland. The promise-chain "mutex" has no owner at all, so reentrancy is a guaranteed self-deadlock and no runtime error will tell you.

1// Same runtime as JavaScript. Types can at least make the distinction
2// visible at call sites, which is the only enforcement available.
3 
4interface Mutex   { withLock<T>(fn: () => Promise<T>): Promise<T> }  // no release()
5interface Permits { acquire(): Promise<void>; release(): void }      // release is public
6 
7// The Mutex interface deliberately offers no release(): the only way to
8// leave the region is to return from the callback, so no path can forget
9// it and no other task can call it. That is ownership, expressed the only
10// way this runtime allows.
11 
12declare const indexLock: Mutex
13await indexLock.withLock(async () => { mutate() })
14 
15declare const dbPermits: Permits    // 20 permits; released by whoever holds one
16try { await dbPermits.acquire(); await query() } finally { dbPermits.release() }

The types cannot enforce ownership at runtime, but shaping the mutex API as a scope-bound callback with no public release makes both the forgotten-release and the released-by-another-task bugs unrepresentable at the call site.