• 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:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

A Thread question from JQuest

 
Ranch Hand
Posts: 43
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
Bartender
Posts: 2205
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Sheriff
Posts: 5782
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Acetylsalicylic acid is aspirin. This could be handy too:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic