This week's book giveaway is in the Cloud/Virtualization forum.
We're giving away four copies of Learning OpenStack Networking: Build a solid foundation in virtual networking technologies for OpenStack-based clouds and have James Denton on-line!
See this thread for details.
Win a copy of Learning OpenStack Networking: Build a solid foundation in virtual networking technologies for OpenStack-based clouds this week in the Cloud/Virtualization forum!
  • 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 all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Liutauras Vilda
  • Campbell Ritchie
  • Tim Cooke
  • Bear Bibeault
  • Devaka Cooray
Sheriffs:
  • Jeanne Boyarsky
  • Knute Snortum
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Ganesh Patekar
  • Stephan van Hulst
  • Pete Letkeman
  • Carey Brown
Bartenders:
  • Tim Holloway
  • Ron McLeod
  • Vijitha Kumara

Quiz #56  RSS feed

 
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Read the following code, which is a part of a synchronized method of a monitor.

public synchronized void someMethod()
{
//lots of code
try
{
Thread.sleep(500);
}
catch(InterruptedException e)
{
//do some crap here.
}
//more and more code here
}
1. The code causes compilation error - sleep cannot be called inside synchronized methods.
2. The code causes compilation error - sleep is not a static method of java.lang.Thread
3. The Thread sleeps for at least 500 milliseconds in this method.
4. When the thread "goes to sleep" it releases the lock on the object.
5. A Thread which does not have the lock for the object cannot sleep in this method.
Answer given 3,5.
I do not agree with answer 5 for the following reason:-
How can a thread enters this synchronized method without it first acquiring the lock on this object? or am i missing on something!
 
Sheriff
Posts: 5782
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You are right. Because the method is
synchronized, for a thread to enter
this method, it has to first aquire the lock.
However, it does not relinquish the lock
when it sleeps.
Also note that in order for a thread to sleep(..) ,
it is not necessary for the thread to obtain the
objects lock first.
See a related discussion
http://www.javaranch.com/ubb/Forum24/HTML/001255.html
Hope this helps

Ajith

 
Ranch Hand
Posts: 18944
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

MAYBE ...
in the portion which says :
//lots of code
something caused to the thread to release the lock ...
I am just trying to find a reason
Regds.
- satya
 
Anonymous
Ranch Hand
Posts: 18944
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Here even answer 3 confuses me. The Thread sleeps for at least 500 milliseconds in this method.
What my understanding is thread can be Interrupted during it's sleep time and in that case it will again come back to running state. Isn't it true?
 
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
The Code wont be executed until the Object lock is gained. Hence, the thread can actually sleep after it gets the lock. NOTE THAT THIS DOESN'T MEAN THAT LOCK IS REQUIRED FOR SLEEPING. In the present context, only the threads which have the lock sleep.

Regards,
 
Ranch Hand
Posts: 289
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It is true that the object will not sleep in this method unless it has the lock. The emphasis here is on "in this method", and not the sleeping itself. thread will enter this method unless it has the lock, therefore no thread will sleep in this method unless it has the lock.
I also do not agree with the fact that the thread will sleep at least 500 mills. The whole point of catching the InteruptedException is because we are anticipating that this thread might be diturbed from its sleep, before the 500 mills.
I do agree with 4, however, that when the oject goes to sleep, it will release the lock. Executing sleep() causes a thread to go into the waiting state, and surely it can not go in this state together with the lock.
I would suggest 4,5 to be the correct answers.

 
Ajith Kallambella
Sheriff
Posts: 5782
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Herbert,
4 is not the right answer because, when a thread goes
to sleep it does not release the lock if it
has one. Also, for a thread to go to sleep it need not
obtain the lock first, that's why sleep need not be
enclosed within the synchronized code block.
Please see the related discussion, and especially
the contribution from Maha Anna here
http://www.javaranch.com/ubb/Forum24/HTML/001255.html .
Do you agree with me ?

Ajith
[This message has been edited by Ajith Kallambella (edited May 04, 2000).]
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!