Why isn't Object.notify() a synchronized method?
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
How is it errorprone? You forgot to acquire the lock and you got an
IllegalMonitorStateException when you did notifyAll. That's pointing out
> Any comments about the Javadoc issue?
I did comment - I don't see any 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
>>> /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. /
More information about the core-libs-dev