Win a copy of Head First Android this week in the Android forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Tim Cooke
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Liutauras Vilda
Sheriffs:
  • Jeanne Boyarsky
  • Rob Spoor
  • Bear Bibeault
Saloon Keepers:
  • Jesse Silverman
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Piet Souris
  • Al Hobbs
  • salvin francis

Wait question from K&B threads chapter

 
Ranch Hand
Posts: 65
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 1392
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
Ranch Hand
Posts: 504
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Marlene Miller
Ranch Hand
Posts: 1392
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
Don Wood
Ranch Hand
Posts: 65
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Marlene Miller
Ranch Hand
Posts: 1392
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
reply
    Bookmark Topic Watch Topic
  • New Topic