Why isn't Object.notify() a synchronized method?

David Holmes david.holmes at oracle.com
Fri May 29 02:10:38 UTC 2015


On 29/05/2015 2:08 AM, Ulf Zibis wrote:
> Hi all,
>
> in the Javadoc of notify(), notifyAll() and wait(...) I read, that this
> methods should only be used with synchronisation on it's instance.
> So I'm wondering, why they don't have the synchronized modifier out of
> the box in Object class.

Because, as others have said, the way you use a monitor is to acquire 
the monitor lock, then inspect/modify mutable object state, then do a 
wait/notify/notifyAll as appropriate, and finally release the monitor. 
Making the methods themselves synchronized would be useless from a 
synchronization correctness perspective and would prevent coding errors 
from resulting in IllegalMonitorStateException.

> Also I think, the following note should be moved from wait(long,int) to
> wait(long):
> /The current thread must own this object's monitor. The thread releases
> ownership of this monitor and waits until either of the following two
> conditions has occurred://
> /
>
>   * /Another thread notifies threads waiting on this object's monitor to
> wake up either through a
>     call to the notify method or the notifyAll method./
>   * /The timeout period, specified by timeout milliseconds plus nanos
> nanoseconds arguments, has
>     elapsed. /

Why would you move it when wait(long) already has the more detailed:

  * <p>
  * The current thread must own this object's monitor.
  * <p>
  * This method causes the current thread (call it <var>T</var>) to
  * 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:
  ...


David
-----

>
>
> Cheers,
>
> Ulf
>



More information about the core-libs-dev mailing list