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

David Holmes davidcholmes at aapt.net.au
Tue Dec 23 16:51:52 EST 2014

Hi Doug,

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

> On 12/23/2014 06:45 AM, Doug Lea wrote:
> > On 12/23/2014 01:19 AM, Joe Bowbeer wrote:
> > Hopefully the doc improvements will prevent this from happening again.
> I committed these to jsr166 CVS, plus the additional clarification in
> acquire(int):
>       * <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? The loop can cause
permits to be "reserved" while an atomic acquire of all the permits at once
would not.

> See
> http://gee.cs.oswego.edu/dl/jsr166/dist/docs/java/util/concurrent/

Again the example seems wrong to me. If the Semaphore is unfair then all
permits are available to any acquirer. So as soon as two permits are
available the acquire(2) can proceed. In contrast a fair Semaphore ensures
only the head waiter can acquire permits.


Concurrency-interest mailing list
Concurrency-interest at cs.oswego.edu

More information about the Concurrency-interest mailing list