Binary Semaphore vs Counting Semaphore

Binary vs counting semaphore compared: value range, shared wait/signal mechanics, and when to use each, with examples.

mediumQ174 of 224 in Operating Systems Est. time: 5 minsLast updated: July 2026

Expected Interview Answer

A binary semaphore holds only two states, 0 and 1, and is used to guard a single resource much like a mutex, while a counting semaphore holds an integer that can range from 0 up to a configured maximum N, letting up to N threads hold a unit of a resource pool concurrently.

Both are built on the identical wait/signal mechanism — wait atomically decrements the value and blocks the caller if it would go negative, signal atomically increments it and wakes a waiter if the queue is non-empty — the only real difference is the range the counter is allowed to take. A binary semaphore is initialized to 1, so after one wait call the value is 0 and any further wait call blocks, exactly modeling exclusive access to one resource; a counting semaphore is initialized to N, so up to N wait calls can succeed before the value hits 0 and further callers block, modeling a pool of N interchangeable resources like database connections or buffer slots. A subtle but important distinction from a true mutex is that a binary semaphore still has no ownership: any thread can call signal on it, even one that never called wait, which makes it usable for cross-thread signaling patterns (like signaling that an event occurred) that a strict mutex cannot support. Choosing between them is really about the resource shape — exactly one instance versus a fixed-size pool of N — rather than about performance, since the underlying implementation cost is the same.

Binary semaphore models exclusive access to a single resource
Counting semaphore models a fixed pool of N interchangeable resources
Both share identical wait/signal machinery, differing only in value range
Binary semaphore (unlike a mutex) supports cross-thread signaling since it has no ownership

AI Mentor Explanation

A binary semaphore is like a single umpire’s spare stopwatch that only one player at a time can be handed — after it is checked out, the count of spares drops to zero and nobody else can take it until it is returned. A counting semaphore is like a rack of five practice balls the squad shares: up to five players can each take one at once, and only the sixth player has to wait, since the rack tracks a count rather than a single yes/no flag. Both use the same checkout-and-return system underneath; only the starting number of items differs.

Step-by-Step Explanation

Step 1
Choose initial value
Binary semaphore starts at 1 (one resource); counting semaphore starts at N (a pool of N resources).
Step 2
wait (P) decrements
Each successful wait atomically lowers the counter by one; a binary semaphore only allows one success before hitting zero, a counting semaphore allows up to N.
Step 3
Callers block past the limit
Once the value would go negative, further wait calls enqueue the caller and block, regardless of whether it is binary or counting.
Step 4
signal (V) increments and wakes
Each signal raises the counter and wakes a waiter if any are queued, in exactly the same way for both variants.

What Interviewer Expects

Correctly stating binary = 0/1 range, counting = 0..N range
Recognizing both share identical wait/signal implementation underneath
Giving a concrete counting semaphore use case (resource pool)
Noting a binary semaphore still lacks ownership, unlike a true mutex

Common Mistakes

Claiming a binary semaphore and a mutex are exactly the same thing
Thinking counting semaphores need a fundamentally different implementation
Forgetting a counting semaphore can also fully block once it hits zero
Not being able to name a concrete counting-semaphore use case

Best Answer (HR Friendly)

“A binary semaphore is essentially a single yes/no flag for one resource, similar in spirit to a lock, while a counting semaphore is the same mechanism generalized to a number, letting a fixed number of threads share a pool of resources at once. Under the hood they work identically — atomically decrement to take, atomically increment to give back — the only difference is whether that number can only be 0 or 1, or can range up to N.”

Code Example

Binary semaphore vs counting semaphore (POSIX)

#include <semaphore.h>

sem_t binary_sem;     /* models one resource: 0 or 1 */
sem_t counting_sem;   /* models a pool of N resources */

void init_semaphores(void) {
    sem_init(&binary_sem, 0, 1);     /* starts at 1: one holder at a time  */
    sem_init(&counting_sem, 0, 4);   /* starts at 4: up to 4 concurrent holders */
}

void use_single_resource(void) {
    sem_wait(&binary_sem);   /* only one thread proceeds past this line */
    /* ... exclusive access ... */
    sem_post(&binary_sem);
}

void use_pooled_resource(void) {
    sem_wait(&counting_sem); /* up to 4 threads proceed concurrently */
    /* ... access one of 4 interchangeable resources ... */
    sem_post(&counting_sem);
}

Follow-up Questions

Why is a binary semaphore not exactly the same as a mutex?
Give a concrete real-world use case for a counting semaphore.
What happens if a counting semaphore’s value drops below zero — is that allowed?
How would you implement a counting semaphore using a mutex and a condition variable?

MCQ Practice

1. What value range does a binary semaphore take?

2. What is a counting semaphore best used for?

3. How does a binary semaphore differ from a true mutex?

Flash Cards

1 / 4

Binary Semaphore vs Counting Semaphore

Expected Interview Answer

AI Mentor Explanation

Step-by-Step Explanation

Choose initial value

wait (P) decrements

Callers block past the limit

signal (V) increments and wakes