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
