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

Ulf Zibis Ulf.Zibis at CoSoCo.de
Fri May 29 16:48:28 UTC 2015

Thanks for your hint David. That's the only reason I could imagine too.
Can somebody tell something about the cost for recursive lock acquisition in comparison to the whole 
call, couldn't it be eliminated by Hotspot?

As I recently fell into the trap of forgetting the synchronized block around a single notifyAll(), I 
believe, the current situation is just errorprone.

Any comments about the Javadoc issue?


Am 28.05.2015 um 18:27 schrieb David M. Lloyd:
> Since most of the time you have to hold the lock anyway for other reasons, I think this would 
> generally be an unwelcome change since I expect the cost of recursive lock acquisition is nonzero.
> On 05/28/2015 11: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.
>> 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. /
>> Cheers,
>> Ulf

More information about the core-libs-dev mailing list