[concurrency-interest] Propagation of signals to non-interruptedthread

David Holmes davidcholmes at aapt.net.au
Sun Nov 13 17:39:33 EST 2011


Hi Doug,

Doug Lea writes:
> 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).

I assume the "official" tests are the JCK tests that have to test compliance
with the spec. But we should be able to have additional tests that test the
actual JDK implementation classes - which could check for these stronger
guarantees.

> 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.

I'd also be concerned that in the absence of any definitive testing
mechanism to ensure these guarantees hold, that bug fixes or performance
tweaks might also inadvertently break something.

David

> -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
>
> _______________________________________________
> 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