File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes thread dies, implicit notifyAll? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "thread dies, implicit notifyAll?" Watch "thread dies, implicit notifyAll?" New topic

thread dies, implicit notifyAll?

Marlene Miller
Ranch Hand

Joined: Mar 05, 2003
Posts: 1391
Would you please explain this sentence from Exam Cram 2 Java 2 Programmer, Chapter 10, page 200
"If a thread that has a lock on one or more objects dies, the JVM removes the locks and does the equivalent of notifyAll for each object locked."
Damien Howard
Ranch Hand

Joined: Apr 01, 2003
Posts: 456
I think basically it means that if a thread dies the system calls a notifyAll() for each object lock the dead thread had so that the threads waiting for the various objects that were locked can return to the runnable pool knowing the locks have been released.
Marlene Miller
Ranch Hand

Joined: Mar 05, 2003
Posts: 1391
When a thread holding the lock of an object dies, other threads waiting on the object do not become runnable. Therefore that could not be what the sentence means.

m1: before wait
[ July 08, 2003: Message edited by: Marlene Miller ]
Jim Yingst

Joined: Jan 30, 2000
Posts: 18671
To be honest, it sounds like the book is just plain wrong here. Your example code is a good illustration. Perhaps add a Thread.sleep(100) between the two start() calls to ensure that things alway happen in the order you expect - but the output makes it fairly clear that t1 was in wait before t2 ran (at least for one run, if not always guaranteed). And the specs (e.g. JLS 17.14) are pretty clear that once a thread calls wait(), it only exits due to an actual notify(), notifyAll(), or timeout. Nothing about an "equivalent to notifyAll()" when a thread dies. But the authors are pretty smart guys, and I don't have a copy to see the full context of this comment, so perhaps there's another meaning that I'm missing.

"I'm not back." - Bill Harding, Twister
Marlene Miller
Ranch Hand

Joined: Mar 05, 2003
Posts: 1391
Thank you Jim for giving my question some thought and looking over my example. Thank you for your time. It helps to know that I am not overlooking something obvious.
Even if it is not literally true, I can't help but wonder what the authors were trying to say.
I have this new idea. Doesn't it sound suspiciously like a description of join()? I propose this paragraph in the section Coordinating Threads with wait and notify belongs in the next section Coordinating Threads with join.
William Brogden
Author and all-around good cowpoke

Joined: Mar 22, 2000
Posts: 13037
I think the intent of that sentence was to cover the situation when a Thread holding locks dies abruptly due to an exception. In that case the JVM unlocks the objects as it unwinds the stack. Obviously it did not turn out right.
That sentence was inherited from the first edition and Marlene is the first person to call attention to the problem! Maybe a career as a tech editor is in order?
Marlene Miller
Ranch Hand

Joined: Mar 05, 2003
Posts: 1391
Thank you Bill.
If I had suspected it was an error in the text, I would not have put it on the forum. I would have sent you an errata note. I thought for sure I just wasn't reading it the way I should be. I apologize.
By the way, I am working through the questions in the text and find them to be very intelligent. You have put a lot of thought into them. Thank you.
I agree. Here's the link:
subject: thread dies, implicit notifyAll?
It's not a secret anymore!