File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
Win a copy of Soft Skills: The software developer's life manual this week in the Jobs Discussion forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

A Thread question from JQuest

 
guo mark
Ranch Hand
Posts: 43
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Rob Ross
Bartender
Posts: 2205
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Ajith Kallambella
Sheriff
Posts: 5782
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Rob Ross
Bartender
Posts: 2205
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 43
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Don't get me started about those stupid light bulbs.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic