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

Joe Bowbeer joe.bowbeer at gmail.com
Mon Dec 22 14:19:59 EST 2014


Doug,

As I understand your fairness explanation, with acquire(5) waiting for
acquire(7), setting fairness=true will not cause the test to pass.  As
Hanson points out, if the Semaphore is constructed with fair=true, the test
tends to lock up even sooner.

Admittedly, this is a horrible use for a single Semaphore, and if I'd read
the source I would have known that it couldn't work -- but the javadoc
alone did not dissuade me.

I point out a few places where I think the Semaphore javadoc could be
improved below.

1. This comment in the class description needs an even strong warning?

"This class also provides convenience methods to acquire and release
multiple permits at a time. Beware of the increased risk of indefinite
postponement when these methods are used without fairness set true."

In particular, fairness isn't going to mitigate all risk.

2. The acquire(int) documentation needs more clarification.

I think an additional "and" helps readability, even though it is not proper
style.  The problem for the reader is that one of two things has to happen,
but the first thing is actually a combination of three things, all of which
have to happen:

"If insufficient permits are available then the current thread becomes
disabled for thread scheduling purposes and lies dormant until one of two
things happens:

Some other thread invokes one of the release methods for this semaphore,
[and] the current thread is next to be assigned permits and the number of
available permits satisfies this request; or ..."

3. The release(int) documentation should make it clearer that *only* one
waiting thread is selected?

"If any threads are trying to acquire permits, then one is selected and
given the permits that were just released."

4. This statement in the release(int) documentation emboldened me:

"There is no requirement that a thread that releases a permit must have
acquired that permit by calling acquire. Correct usage of a semaphore is
established by programming convention in the application."

I'm not sure what to make of the second sentence.  Would this be a good
place to advise against adding permits that cannot be acquired by any
waiting thread?


bitbucket.org/joebowbeer/semaphorebug

On Mon, Dec 22, 2014 at 9:11 AM, Doug Lea <dl at cs.oswego.edu> wrote:

> On 12/22/2014 11:46 AM, Aleksey Shipilev wrote:
>
>> On 12/22/2014 05:36 PM, Doug Lea wrote:
>>
>>> On 12/21/2014 07:25 PM, Joe Bowbeer wrote:
>>>
>>>> Below is the most concise implementation I can imagine, using a single
>>>> Semaphore, which is legal AFAICT according to the javadoc, but which
>>>> deadlocks
>>>> in my tests.
>>>>
>>>
>  The acquire(n) spec should probably be clarified that it promises
>>> no more than the equivalent of
>>>    for (int i = 0; i < n; ++i) acquire();
>>>
>>
> Sorry, this was too extreme a way of saying it.
>
>
>> Wait, what. If fairness only applies to individual acquire() calls, that
>> definition would mean that even with fair Semaphore two threads can
>> deadlock in:
>>
>
> Suppose you have thread 1 acquire(7), and then thread 2: acquire(5).
> With fairness, thread 2 waits for thread 1 to succeed before
> trying. Without fairness, they could be in any order, but still
> *some* order. So the net effect is not quite the same as
> the above loop, but closer than implying that the semaphore
> somehow sorts waiters by #permits, which it doesn't/can't.
>
> -Doug
>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20141222/a71576bb/attachment.html>


More information about the Concurrency-interest mailing list