[concurrency-interest] Propagation of signals tonon-interruptedthread

Doug Lea dl at cs.oswego.edu
Sun Nov 13 17:04:48 EST 2011


On 11/13/11 16:50, David Holmes wrote:
> Martin,
> I still oppose this and see little point in it. Why guarantee something only to
> then say that noone should be acting based on the guarantee? What do you gain by
> this? The ability to change a while loop to an if-statement - and what does that
> gain you, a saving of one comparison and one branch in a code block that
> suspends a thread ???

I think Martin would like stronger guarantees in part so that we can use
stronger unit tests for j.u.c. We do take extra measures in AQS-based
synchronizers to avoid users seeing spurious wakeups, and it would be
nice to ensure that these work as intended in all tests (rather than
only in unofficial tests).

My main reservation is that I can just barely conceive of someday
wanting to re-implementing ReentrantLock etc in a way that does not
preserve this guarantee. While this doesn't seem too likely, we've
been hurt enough times in the past by overspecifiying implementations
for me to advocate changing these.

-Doug

> David
>
>     -----Original Message-----
>     *From:* concurrency-interest-bounces at cs.oswego.edu
>     [mailto:concurrency-interest-bounces at cs.oswego.edu]*On Behalf Of *Martin
>     Buchholz
>     *Sent:* Saturday, 12 November 2011 4:50 AM
>     *To:* David M. Lloyd; Dr Heinz M. Kabutz
>     *Cc:* concurrency-interest at cs.oswego.edu
>     *Subject:* Re: [concurrency-interest] Propagation of signals
>     tonon-interruptedthread
>
>     My latest spec proposal for ReentrantLock, with stronger disclaimer:
>
>     --- java/util/concurrent/locks/ReentrantLock.java9 Jun 2011 07:48:44 -00001.96
>     +++ java/util/concurrent/locks/ReentrantLock.java11 Nov 2011 18:41:22 -0000
>     @@ -467,6 +467,13 @@
>     * but for <em>fair</em> locks favors those threads that have been
>     * waiting the longest.
>     *
>     + * <li>None of the condition {@linkplain Condition#await() waiting}
>     + * methods ever return due to a "<em>spurious wakeup</em>".
>     + * However, as explained in the {@link Condition} documentation,
>     + * application programs should almost never rely on this guarantee.
>     + * A {@code Condition} should generally be waited upon in a loop,
>     + * testing the state predicate that is being waited for.
>     + *
>     * </ul>
>     *
>     * @return the Condition object
>
>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest



More information about the Concurrency-interest mailing list