[concurrency-interest] Propagation of signals tonon-interrupted thread

Martin Buchholz martinrb at google.com
Fri Nov 11 15:27:56 EST 2011


I am not trying to change the spec for Condition or Object.

I am trying to change the spec for ReentrantLock, ReentrantReadWriteLock,
AQS.ConditionObject, AQLS.ConditionObject to offer more guarantees than
Condition does.

Martin

On Fri, Nov 11, 2011 at 11:47, Dr Heinz M. Kabutz
<heinz at javaspecialists.eu>wrote:

> **
> Remember to also change the Condition documentation:
>
>  * <p>When waiting upon a {@code Condition}, a "<em>spurious
>  * wakeup</em>" is permitted to occur, in
>  * general, as a concession to the underlying platform semantics.
>  * This has little practical impact on most application programs as a
>  * {@code Condition} should always be waited upon in a loop, testing
>  * the state predicate that is being waited for.  An implementation is
>  * free to remove the possibility of spurious wakeups but it is
>  * recommended that applications programmers always assume that they can
>  * occur and so always wait in a loop.
>
> It is also mentioned in all the await() methods.
>
> This does worry me a bit though.  Just because it is not happening in your
> implementation, is it then guaranteed to not happen in *any* implementation?
>
> Regards
>
> Heinz
> --
> Dr Heinz M. Kabutz (PhD CompSci)
> Author of "The Java(tm) Specialists' Newsletter"
> Sun Java Champion
> IEEE Certified Software Development Professionalhttp://www.javaspecialists.eu
> Tel: +30 69 72 850 460
>
> Skype: kabutz
>
>
>
> On 11/11/11 8:50 PM, Martin Buchholz wrote:
>
> My latest spec proposal for ReentrantLock, with stronger disclaimer:
>
>  --- java/util/concurrent/locks/ReentrantLock.java 9 Jun 2011 07:48:44
> -0000 1.96
> +++ java/util/concurrent/locks/ReentrantLock.java 11 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20111111/7befaafe/attachment.html>


More information about the Concurrency-interest mailing list