Why isn't Object.notify() a synchronized method? (original) (raw)
Ulf Zibis Ulf.Zibis at CoSoCo.de
Fri May 29 16:48:28 UTC 2015
- Previous message: Why isn't Object.notify() a synchronized method?
- Next message: Why isn't Object.notify() a synchronized method?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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?
-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
- Previous message: Why isn't Object.notify() a synchronized method?
- Next message: Why isn't Object.notify() a synchronized method?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]