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

Stuart Marks stuart.marks at oracle.com
Fri Aug 11 18:25:46 UTC 2017

This is an old spec bug. The Object.wait spec lists several different reasons a 
thread could be awakened, but it omits spurious wakeup -- even though spurious 
wakeup is described later on. The fix is simply to add spurious wakeup to the list.

There is some discussion in the original bug report:


Patch appended below.



# HG changeset patch
# User smarks
# Date 1502475871 25200
#      Fri Aug 11 11:24:31 2017 -0700
# Node ID ebd66cd27b298d5bbbdfd348164505ef1195f90e
# Parent  27b08ab97a607df3a4abff83d8d1a2a1882e5bf1
6344935: Clarify Object.wait javadoc with respect to spurious wakeups
Reviewed-by: XXX

diff -r 27b08ab97a60 -r ebd66cd27b29 
--- a/src/java.base/share/classes/java/lang/Object.java	Thu Aug 03 09:04:47 2017 
+++ b/src/java.base/share/classes/java/lang/Object.java	Fri Aug 11 11:24:31 2017 
@@ -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:
       * <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

More information about the core-libs-dev mailing list