Question

I am reading the book Java Concurrency in Practice. In a section about java.util.concurrent.Semaphore, the below lines are present in the book. It is a comment about its implementation of “virtual permit” objects

The implementation has no actual permit objects, and Semaphore does
not associate dispensed permits with threads, so a permit acquired in
one thread can be released from another thread. You can think of
acquire as consuming a permit and release as creating one; a
Semaphore is not limited to the number of permits it was created with.

Can somebody explain this? I am having trouble understanding this. If we create a pool of fixed size, we create a fixed number of “permits”. From the above statement, it looks like the “permits” can keep growing. Why is it designed this way?

Answer 1

Instead of “handing out” permit objects, the implementation just has a counter. When a new permit is “created” the counter is increased, when a permit is “returned” the counter is decreased.

This makes for much better performance than creating actual objects all the time.

The tradeoff is that the Semaphore itself cannot detect certain kinds of programming errors (such as unauthorized permit cash-ins, or semaphore leaks). As the coder, you have to make sure to follow the rules on your own.