Binary Semaphore vs. Mutex: Ownership & Signaling Differences

Medium

Interview Question: "Is a binary semaphore just a mutex? Why or why not? What is a recursive/reentrant mutex, and how do condition variables relate to binary semaphores?"

"Isn't a binary semaphore literally just a mutex initialized to 1?" It's one of the most common traps in systems interviews. They look the same on the surface — both only let one thing through at a time — but they're built for different jobs, and that difference shows up the moment something goes wrong.

---

The analogy: a bathroom key vs. a restaurant pager

• Mutex — the bathroom key. You take the one key, go in, lock the door. You own it. Nobody else is allowed to hand it back in your place.
• Binary semaphore — the restaurant pager. You're handed a buzzer that's currently off (value = 0). You can't sit yet. A completely different customer, somewhere else, finishes eating and leaves — the host presses a button, your buzzer lights up (value = 1), and now you sit.

Mutex

same thread locks & unlocks

Binary Semaphore

any thread can signal

The key difference: with the mutex, the same person who locked it is the one who unlocks it. With the pager, the person waiting and the person who triggers the signal are two totally different people. There's no ownership.

---

Ownership vs. signaling

Dimension	Mutex	Binary Semaphore
What it's for	Protecting shared memory (mutual exclusion)	Coordinating order between threads (signaling)
Ownership	Strict — the thread that locks it must unlock it	None — any thread can wait, any thread can signal
If the wrong thread releases it	Throws an error	Just increments the counter, no questions asked
If the thread holding it dies	Kernel can detect this (it tracks the owner)	No way to know — a waiting thread can sleep forever

---

Two follow-ups worth knowing

1. What if a thread tries to lock something it already holds? With a plain mutex or binary semaphore, it blocks on itself — instant deadlock. A recursive/reentrant mutex (ReentrantLock in Java, PTHREAD_MUTEX_RECURSIVE in C) fixes this by tracking the owning thread plus a counter: the same thread can re-lock it as many times as it wants, and it only actually unlocks once that counter drops back to zero.

2. Why do condition variables usually replace binary semaphores for signaling? A binary semaphore remembers state — if signal() happens before wait(), that signal is still "banked" and the next wait() passes through immediately. That's exactly the problem: it's easy to get a stale signal that doesn't match the actual condition anymore. A condition variable (paired with a mutex) has no memory like that — it re-checks the real condition in a loop (while (!ready) wait(&mutex)), which avoids those stale-signal bugs and safely handles spurious wakeups.

---

Say this in the interview

"A binary semaphore is not a mutex. A mutex has strict ownership — only the locking thread can unlock it — which makes it right for mutual exclusion. A binary semaphore has no ownership, so one thread can wait while a completely different thread signals, which makes it a signaling tool instead."

---

Code: inter-thread signaling

C (sem_t Signaling)

#include <stdio.h>
#include <pthread.h>
#include <semaphore.h>
#include <unistd.h>

sem_t ready_signal;

void* worker(void* arg) {
    printf("[Worker] Doing background work...\n");
    sleep(1);
    printf("[Worker] Work complete! Signaling main thread.\n");
    // Worker signals the semaphore (Notice: worker never called wait!)
    sem_post(&ready_signal);
    return NULL;
}

int main() {
    pthread_t t;
    // Initialized to 0 (Blocking state)
    sem_init(&ready_signal, 0, 0);

    pthread_create(&t, NULL, worker, NULL);

    printf("[Main] Waiting for worker to complete...\n");
    sem_wait(&ready_signal); // Blocks until worker signals
    printf("[Main] Received signal! Proceeding to finish.\n");

    pthread_join(t, NULL);
    sem_destroy(&ready_signal);
    return 0;
}

Python (threading.Event)

import threading
import time

# Event in Python acts as an idiomatic binary signaling mechanism
ready_event = threading.Event()

def worker():
    print("[Worker] Downloading data...")
    time.sleep(1)
    print("[Worker] Download complete! Signaling main thread.")
    ready_event.set() # Signals waiting threads

if __name__ == "__main__":
    t = threading.Thread(target=worker)
    t.start()

    print("[Main] Waiting for worker...")
    ready_event.wait() # Blocks until set() is called by the worker
    print("[Main] Signal received! Processing downloaded data.")
    t.join()

Java (CountDownLatch / Semaphore)

import java.util.concurrent.Semaphore;

public class BinarySignalingDemo {
    public static void main(String[] args) throws InterruptedException {
        // Initialized to 0 permits for signaling
        Semaphore signal = new Semaphore(0);

        Thread worker = new Thread(() -> {
            try {
                System.out.println("[Worker] Crunching numbers...");
                Thread.sleep(1000);
                System.out.println("[Worker] Finished! Signaling main.");
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            } finally {
                // Different thread releases the permit
                signal.release();
            }
        });

        worker.start();
        System.out.println("[Main] Blocked waiting for worker signal...");
        signal.acquire(); // Waits for worker to release
        System.out.println("[Main] Unblocked! Continuing execution.");
    }
}