GeeCON Prague 2014*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes A Thread question from JQuest 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 "A Thread question from JQuest" Watch "A Thread question from JQuest" New topic
Author

A Thread question from JQuest

guo mark
Ranch Hand

Joined: Oct 20, 2001
Posts: 43
a qusetion in JQuest
public synchronized void someMethod(){
//lots of code
try{
Thread.sleep(500);
}catch(InterruptedExcepton e){
//do some things here
}
//more and more code here
}

A:the code causes compilation error - sleep cannot be called inside synchronized methods.
B:the Thread sleeps for at least 500 milliseconds in this method if not interrupted.
C:When the thread "goes to sleep"it releases the lock on the object
D:the "sleeping "Threads always have the lock on the Object

why B is incorrect? And i think the C and D is against each other.If
the thread already released the lock, how can it "always have the lock on the Object ?"

thanks all for interesting first


meet once ,love every while
Rob Ross
Bartender

Joined: Jan 07, 2002
Posts: 2205
My answers are B & D. B looks correct to me. The thread will sleep for at least 500 ms, possibly longer, unless it's interrupted.
D is correct here because Thread.sleep() does not give up any locks - only wait() does that.


Rob
SCJP 1.4
Ajith Kallambella
Sheriff

Joined: Mar 17, 2000
Posts: 5782
Originally posted by Rob Ross:
My answers are B & D. B looks correct to me. The thread will sleep for at least 500 ms, possibly longer, unless it's interrupted.

Why possibly longer? The thread will sleep for at most 500 ms. If it is interrupted before the time expires, it will come out of the sleeping state, otherwise it will sleep for the specified time ie., 500 ms. After coming out, it becomes ready to run again.

D is correct here because Thread.sleep() does not give up any locks - only wait() does that.

Although you are right, IMO answer D is ambiguously worded.
the "sleeping "Threads always have the lock on the Object
If "the" sleeping thread means the thread in question, then the answer is right. However, if "the sleeping threads" mean any thread that is sleeping, then the answer is wrong since we don't know whether the call to sleep() is in a synchronized block.
I don't have access to JQuest. Perhaps guo Mark can verify these answers again to make sure they appear exactly as given in the JQuest exam.


Open Group Certified Distinguished IT Architect. Open Group Certified Master IT Architect. Sun Certified Architect (SCEA).
Rob Ross
Bartender

Joined: Jan 07, 2002
Posts: 2205
Originally posted by Ajith Kallambella:
Why possibly longer? The thread will sleep for at most 500 ms. If it is interrupted before the time expires, it will come out of the sleeping state, otherwise it will sleep for the specified time ie., 500 ms. After coming out, it becomes ready to run again.

The thread scheduler won't schedule the thread for execution until the 500 ms have elapsed. Then the thread will at some point be made eligible for scheduling; however, there's no way to predict how long that will take. And once a thread is eligible to be run, there is no way to predict when it will actually be executed. So after the thread sleeps for 500ms, there will be some additional "scheduling overhead time" that we cannot predict exactly; thus the statement that it will sleep at least 500ms, but in most cases, a little bit more, and sometimes, theoretically, a lot more. It all depends on the scheduler.

Although you are right, IMO answer D is ambiguously worded.
the "sleeping "Threads always have the lock on the Object
If "the" sleeping thread means the thread in question, then the answer is right. However, if "the sleeping threads" mean any thread that is sleeping, then the answer is wrong since we don't know whether the call to sleep() is in a synchronized block.

I agree that the question is a little vague, but in context the answer makes sense. Perhaps they should have written "When Thread.sleep() is called on a thread which holds a lock, that thread maintains its locks while the thread sleeps."
[ February 26, 2002: Message edited by: Rob Ross ]
guo mark
Ranch Hand

Joined: Oct 20, 2001
Posts: 43
thanks all. I will verify it again as Ajith Kallambella said.Its seemed that i hava some trouble in understanding of differents between Thread.sleep and Thread.wait.
 
GeeCON Prague 2014
 
subject: A Thread question from JQuest