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 Q9 page765, Threads : another possibility ? 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 "Q9 page765, Threads : another possibility ?" Watch "Q9 page765, Threads : another possibility ?" New topic

Q9 page765, Threads : another possibility ?

Rahul Sudip Bose
Ranch Hand

Joined: Jan 21, 2011
Posts: 637

Here is the question :


This is the answer : G. An exception is thrown at runtime
And the book says why : G is correct. The code does not acquire a lock on t before calling t.wait(), so it throws an IllegalMonitorStateException. The method is synchronized, but it's not synchronized on t so the exception will be thrown. If the wait were placed inside a synchronized(t) block, then the answer would have been D.

Even if we make the above correction, is the below possible ?
The run() method of t contains nothing, so it can probably complete in a nano-second. Assuming that the jvm decides to move it from runnable to running immediately after start() ,
it might just complete before main can print X. Then we are trying to call wait on a dead thread...could that cause an exception ? If there is some misconception , please point it out.


SCJP 6. Learning more now.
Deepak Bala

Joined: Feb 24, 2006
Posts: 6662

Then we are trying to call wait on a dead thread...

You wait on an Object which may or may not be a thread. So its "running" state is not up for questioning.

could that cause an exception ?

What happened when you tried ? You can always join() and then wait on the thread.

SCJP 6 articles - SCJP 5/6 mock exams - More SCJP Mocks
I agree. Here's the link:
subject: Q9 page765, Threads : another possibility ?
It's not a secret anymore!