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

David Holmes david.holmes at oracle.com
Sun May 31 04:31:25 UTC 2015

On 30/05/2015 2:48 AM, Ulf Zibis wrote:

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?

There are a number of fast paths related to recursive locking. Not sure if inlining allows lock elision that something for the compiler folk.

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

How is it errorprone? You forgot to acquire the lock and you got an IllegalMonitorStateException when you did notifyAll. That's pointing out your error.

Any comments about the Javadoc issue?

I did comment - I don't see any issue.

David H.

-Ulf

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