The count is the contract: what semaphores still teach

Our engineers worked through Downey’s Little Book of Semaphores end to end and implemented every pattern in it twice, once in a language where the primitive is forgiving and once against the POSIX interface where it is not. Rendezvous, mutual exclusion, bounded concurrency, single-use and reusable barriers, the pre-loaded turnstile, the leader and follower queue, and the exclusive variant.

It is an odd thing for a commercial software firm to spend time on, and we would defend it on one ground: it is the shortest path we know to reading concurrent code accurately, and reading concurrent code accurately is what separates a plausible diagnosis of a production race from a correct one.

The primitive, and what makes it interesting¶

A semaphore is an integer with two operations. One decrements it and blocks while it would go negative. The other increments it and wakes a waiter if any are blocked. That is the entire interface, and the surprise is how much policy fits inside the choice of starting value.

The same two operations, three completely different coordination contracts, distinguished by one integer. Once you can see that integer as the policy rather than as an implementation detail, a great deal of concurrent code becomes readable that previously had to be taken on trust.

Below, every pattern in the book runs on one primitive. Switch between them and the only thing that changes is the starting count and where the waits sit; the deadlock scenario is the same code with two of them inverted.

The mistake that produces most self-inflicted deadlocks¶

Signal, then wait. Never wait, then signal. Roughly half the deadlocks introduced while learning these patterns come from inverting that order, and the reason is easy to state: the participant you are coordinating with cannot wake you on something it has not yet been told to send. Both threads sit in the wait, and each is waiting for a signal the other will send immediately after it stops waiting.

Written out, it is obvious. In code, with the two halves of the pattern a hundred lines apart in different files, it is not obvious at all, and it is a recognizable shape rather than a puzzle to be solved fresh each time.

aArrived = Semaphore(0)bArrived = Semaphore(0) def A():    print("Drone A: Picked up the package.")    bArrived.release()       # tell B I’m here    aArrived.acquire()       # wait for B def B():    bArrived.acquire()       # wait for A    print("Drone B: Arrived at the rendezvous point.")    aArrived.release()       # tell A I’m here

The barrier, and why the naive one only works once¶

A barrier holds N participants until all N have arrived, then releases them together. Built from a counter, a lock and a semaphore, the direct implementation is correct on its first use and broken on its second, because a fast participant can loop around and re-enter before the slow ones have finished leaving.

The standard fix is a two-phase turnstile: one gate to leave the previous round and a second to enter the next, so no participant can lap another. There is a cleaner variant that pre-loads the first turnstile and avoids one of the gates entirely. Neither is difficult once seen. Neither is something we would want an engineer deriving under deadline pressure at midnight while a client’s job queue is stuck, which is exactly when the problem presents itself.

mutex      = Semaphore(1)turnstile  = Semaphore(0)   # phase 1: shut until the last party arrivesturnstile2 = Semaphore(1)   # phase 2: open, so the barrier can be re-entered with counted(mutex, +1) as n:    if n == PARTIES:        turnstile2.acquire()    # shut the exit before opening the entrance        turnstile.release()

sem_t multiplex;sem_t countsem; void count(int thread_id) {    sem_wait(&multiplex);    // ... critical section, guarded separately by countsem ...    sem_post(&multiplex);} int main() {    sem_init(&multiplex, 0, 3);   // capacity 3: the policy, stated once    sem_init(&countsem, 0, 1);    // ... spawn / join 20 threads ...    sem_destroy(&multiplex);    sem_destroy(&countsem);}

The move that explains condition variables¶

In the exclusive queue pattern, where participants pair up before proceeding, the elegant implementation deliberately does not release the mutex on handoff. The partner inherits it. That looks like a violation of every rule about balanced acquisition and release, and it is exactly what a condition variable does internally when it signals.

Having written that by hand once, condition-variable code reads differently ever afterward. This is the general return on the exercise: not that you will use these primitives, but that the higher-level tools stop being magic. A channel, a mutex with a condition variable, an async runtime’s scheduler, all of them are a count, a wait and a signal underneath.

What we actually use in production¶

Almost never a raw semaphore. A channel, a queue with a bounded capacity, a mutex paired with a condition variable, or a task runtime is clearer at the call site and easier to review, and clarity at the call site is worth a great deal more than cleverness.

But production concurrency bugs do not present as concurrency bugs. They present as a job that ran twice, a report with a number nobody can reproduce, a queue that stalls under load once a week, or an integration that duplicates a record when the network is slow. Diagnosing those means reading code written by someone else, under a deadline, and deciding whether a specific interleaving is possible. That skill is built by writing the small versions, and it does not transfer from reading about them.