In K&B chapter on threads, questions 10 (pages 543-544) and 14 (page 545) have answers marked correct that I feel are wrong. They say essentially the same thing.
Q10. When a thread invokes wait(), it releases its locks. Q14. When a thread is waiting as a result of wait(), it releases its locks.
I believe that the lock that is associated with the object that is used to invoke wait will have its lock released but any other locks the thread owns will remain locked. The following is from the Java 1.4.2 api documentation for wait():
Note that the wait method, as it places the current thread into the wait set for this object, unlocks only this object; any other objects on which the current thread may be synchronized remain locked while the thread waits.
I looked at the K&B errata and did not find any mention of this. Perhaps I have misread something so I would appreciate comments.
Hi Don, you can convince yourself that other locks are not released by coding a little test. The holdsLock() method of Thread is helpful. Here is a document which will someday be a revision to the JLS chapter 17. Section 12.1 says a thread executes the wait method on Object m and performs unlock actions on m. Here [ January 05, 2004: Message edited by: Marlene Miller ]
Hi all, Marlene, do you really think when a thread calls wait() on one object it then releases all its locks on the objects to whose wait sets it's not been added? I've read the Ch. 17 amendments that you gave here, thanks, but haven't seen any mention of such a behaviour. Consider the following example:
This program never completes only because the first running thread retains a lock on sb1 while blocking in sb2's wait set. So, it looks like a wait-blocked thread releases only a lock on the object that wait() was called on.
Hi Vad, thank you for your response, because if I am confusing people, I would like to know. I think the same as you and Don. I did experiments like yours and that is how I convinced myself. When Doug Lea and William Pugh say a thread performs �unlock actions� on an object, I think they mean, when a thread enters (in sequence) N blocks or methods synchronizied on the same object, the thread performs N lock actions on the object. When the thread calls wait(), it performs N unlock actions on the object. Those multiple lock actions are due to multiple synchronized blocks on the same object. Any lock actions on another object are not affected. [ January 06, 2004: Message edited by: Marlene Miller ]
Thanks Vad and Marlene. I have also written experiments like Vad's and I am comfortable that I understand how locks work. But I don't understand how holdsLock() can help here. The holdsLock method determines if the current thread holds the lock on an object. The locks we are interested in knowing about are held by a thread that is waiting. Because it is waiting, it cannot call holdsLock(). Another thread can use holdsLock() to determine whether or not it is the owner of the lock but it can't determine if the lock is held by any other thread. Since it only works with the current thread, I don't see how holdsLock() can help us with this question.
Don, I agree with you. When a threading is waiting, we cannot use holdsLock() to show that the thread is still holding the locks of other objects. That is the reason I also gave you a link to the the upcoming revision of the JLS chapter 17. That link is more recent than the links provided here JSR 133 We can only use holdsLock() to confirm what we already know, namely that a thread is actually holding two locks just before calling wait. (The only usage of holdsLock() that I have seen documented is in the assertions guide. Programming With Assertions, subsection Lock-Status Preconditions) Here is how I might use holdsLock(). It doesn't prove anything.
[ January 07, 2004: Message edited by: Marlene Miller ]
You showed up just in time for the waffles! And this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop