[concurrency-interest] Semaphore doc bug [Was: Enforcing ordered execution of critical sections?]

Doug Lea dl at cs.oswego.edu
Tue Dec 23 19:42:42 EST 2014

On 12/23/2014 04:51 PM, David Holmes wrote:

> I still need to go back and check historical notes but this all seems wrong
> to me.

I'm confident about the original intention/spec of this method.
But I'm also sympathetic about exploring new methods/classes
so that people don't try to abuse a method designed to help
people avoid backout mechanics as if it were a priority-semaphore
or a way to cause N wakeups per release.

>>        * <p>Acquires the given number of permits, if they are available,
>>        * and returns immediately, reducing the number of available permits
>>        * by the given amount. This method has the same effect as the
>>        * loop {@code for (int i = 0; i < permits; ++i) acquire();} except
>>        * that it atomically acquires the permits all at once:
> To me the "except" part nullifies the initial statement. What does it mean
> to acquire the permits atomically rather than in a loop?

One way to think about it is that there is a queue of "holes"
that can be filled with permits, and that you've reserved a
consecutive range of them. But you don't know where that range lies
unless semaphore is fair and you know the invocation order.

> Again the example seems wrong to me. If the Semaphore is unfair then all
> permits are available to any acquirer.

But unfair just means "the implementation picks the ordering".


More information about the Concurrency-interest mailing list