RFR(xs): 6344935: Clarify Object.wait javadoc with respect to spurious wakeups

mandy chung mandy.chung at oracle.com
Fri Aug 11 18:45:06 UTC 2017


On 8/11/17 11:25 AM, Stuart Marks wrote:
>
> diff -r 27b08ab97a60 -r ebd66cd27b29 
> src/java.base/share/classes/java/lang/Object.java
> --- a/src/java.base/share/classes/java/lang/Object.java    Thu Aug 03 
> 09:04:47 2017 -0700
> +++ b/src/java.base/share/classes/java/lang/Object.java    Fri Aug 11 
> 11:24:31 2017 -0700
> @@ -318,7 +318,7 @@
>       * place itself in the wait set for this object and then to 
> relinquish
>       * any and all synchronization claims on this object. Thread 
> <var>T</var>
>       * becomes disabled for thread scheduling purposes and lies dormant
> -     * until one of four things happens:
> +     * until one of five things happens:
Perhaps to say "until one of the following happens" to avoid the count.
>       * <ul>
>       * <li>Some other thread invokes the {@code notify} method for this
>       * object and thread <var>T</var> happens to be arbitrarily 
> chosen as
> @@ -330,7 +330,9 @@
>       * <li>The specified amount of real time has elapsed, more or 
> less.  If
>       * {@code timeout} is zero, however, then real time is not taken 
> into
>       * consideration and the thread simply waits until notified.
> +     * <li>Thread <var>T</var> is awakened spuriously. (See below.)
>       * </ul>
> +     * <p>
>       * The thread <var>T</var> is then removed from the wait set for 
> this
>       * object and re-enabled for thread scheduling. It then competes 
> in the
>       * usual manner with other threads for the right to synchronize 
> on the
>
Looks fine.

Mandy


More information about the core-libs-dev mailing list