question from Jquest on Threads

[Minakshi]

========================================================================
Read the following snippet carefully
1. public synchronized void someMethod() {
2. //lots of code
3. try {
4. Thread.sleep(500);
5. } catch(InterruptedException e) {
6. //do some things here.
7. }
8. //more and more code here
9. }
Select all correct answers
a. The code causes compilation error - sleep cannot be called inside synchronous methods
b. The thread sleeps for atleast 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.
=======================================================================
The answer is given as 'c' and 'd' which seems contradictory to me. I think it should be 'b' and 'c'
Please clarify.

[Sahir Shah]

C is wrong. Is probably a typo .
A sleeping thread does not lose ownership of any monitors it had aquired. What is JQuest? Is this a mock exam? If so it would
help other candidates if you post this at the mock exam errata forum.
Rgds
Sahir

[Randall Twede]

the correct answers are b and d.
the exam is wrong.

[deekasha gunwant]

hi minakshi,
randall is right.only b,d are correct.
anbd c must be a typo as sleeping thread does not releases any locks.
regards
Deekasha

[bill bozeman]

As everyone else said, b and d are correct.
I am moving this to the mocks errata forum.
Bill

[Minakshi Jain]

Thanks for clarifying.
Minakshi

[sirisha parimi]

hi,
i think b , cand d are correct .
c---
as if any thread wants to access , it can only when it gets the lock.
b--
it has to sleep for min of 500ms untill
it is interrupted.
d--
unless another thread is there waiting it gets notified.otherwise it sleeps.

[This message has been edited by sirisha parimi (edited December 19, 2000).]

[bill bozeman]

sleep() method doesn't release the lock, so C is not a correct answer.
Bill

[urja patel]

Actually the reply is
b and c..
b) because,it sleep for atleast 500 milliseconds.
Not less than it.
c) because,as it is in synchronized block,it releases
lock as soon as it goes to sleep.

[bill bozeman]

urja, that is not correct.
Sleeping threads DO NOT release the locks.
Here is an example to prove my point:

class ThreadLock implements Runnable
{
    synchronized public void aMethod()
    {
        for (int i = 0; i < 10; i++)
        {
            System.out.println("Thread " + Thread.currentThread().getName() + " " + i);
            try
            {
            Thread.sleep(5000);
            } catch (InterruptedException e) {}
        }
    }
    
    public void run()
    {
        aMethod();
    }
}
class TestThreadLock
{
    public static void main(String args[])
    {
        ThreadLock ttl = new ThreadLock();
        Thread t = new Thread(ttl);
        Thread t1 = new Thread(ttl);
        t.setPriority(5);  
        t1.setPriority(5);
        t.start();
        t1.start();
    }
}

The second thread will never start until the first thread is finished because the first thread gets the lock and doesn't give it up. Change sleep() to wait() and you will see that the new thread will start right after the first thread hits wait(). The program will deadlock on you since both threads are waiting and there is no notify() statement, but it still gets the point across.
Bill