Synchronizers: latches, barriers, semaphores question 47 of 180 junior
What does a Semaphore actually protect?
- A single critical section, like a lock
- Correct: A count of concurrent users of a resource, which is a different question from mutual exclusion
- The order in which threads run
- Memory visibility only
A lock answers "one at a time". A semaphore answers "at most N at a time", which is what you want when the constraint lives outside your process: a downstream service that tolerates 50 concurrent calls, a pool of 20 connections, a licence for 4 decoders.
Semaphore permits = new Semaphore(50);
permits.acquire();
try {
callDownstream();
} finally {
permits.release();
}
Two things interviewers probe. A binary semaphore (new Semaphore(1)) is not a lock: it has no owner,
so any thread can release it, and it is not reentrant, so the same thread acquiring twice deadlocks.
That ownerless property is occasionally exactly what you want, when one thread signals and another
proceeds. And permits are just a count: releasing more than you acquired silently inflates the limit,
which is a bug that surfaces as an overloaded dependency weeks later.
Quiz yourself on Synchronizers: latches, barriers, semaphores Suggest a correction