Test Question about Threads

[Rafael De la Guetto]

Hi,

This is not a question of an official exam. It is a question extracted from the certification book named "SCJP Sun Certified Programmer for Java 5 Study Guide", and it appears on the page 750.

I thought that when a thread calls wait() over an object, and then someother thread calls notify(), the first one leaved the "waiting" state, and goes to the "locked" state, waiting for the second one to leave the synchronized region, and finally goes to "runnable".

But just when i thought that it was fairly clear, I found a question like this one:

Assume the following method is properly synchronized and called from a thread A on an object B:
wait(2000);
After calling this method, when will the thread A become a candidate to get another turn at the CPU?

A. After object B is notified, or after two seconds.
B. After the lock on B is released, or after two seconds.
C. Two seconds after object B is notified.
D. Two seconds after lock B is released.


Which one is the correct?

The books says that A, but I simply don't get it, to me, there are no correct question.

Help, please!!
Thanks!!

[yogi maheshnath]

Hi,

Beacause its specified in syntax of wait() method in java.lang.Object.

public final void wait(long timeout)throws InterruptedException
when wait() is called, the thread becomes disabled for scheduling and lies dormant until one of four things occur:

1. another thread invokes the notify() method for this object and the scheduler arbitrarily chooses to run the thread
2. another thread invokes the notifyAll() method for this object
3. another thread interrupts this thread
4. the specified wait() time elapses //see this one

So,After calling wait() method, thread A will become a candidate to get another turn at the CPU,after object B is notified, or after two seconds(wait(2000)) in your example.

[Rafael De la Guetto]

Thanks for your answer.

I agree with you, but given that the methods notify() and wait() must be called from a SYNCHRONIZED section, it is "impossible" for a thread to travel from "waiting" to "runnable", because it must visit the "locked" state waiting for the thread that calls the notify() method to abandom the synchronized region in wich it neccessarily is.

What do you think?
Thanks!

[Burkhard Hassel]

Rafael:

...must visit the "locked" state"...

Sorry, did you mean "blocked"?

I don't think the exam cares about the differences about blocking and waiting states. Not sure, though.

Yours,
Bu.
[ January 12, 2008: Message edited by: Burkhard Hassel ]

[Henry Wong]

B. After the lock on B is released, or after two seconds.

Wrong, but debateable. You can release the lock, and not send the notification, and the thread will not wake up. However, you can argue that two seconds later it will wake up, which technically is still *after* the lock is released.

C. Two seconds after object B is notified.

Clearly wrong. If you sleep for 2 seconds, then send the notification, the thread will wakeup immediately (assuming that it can get the lock).

D. Two seconds after lock B is released.

Clearly wrong. If you sleep for 2 seconds, then release the lock, the thread will wakeup immediately -- and not two seconds after. (assuming that it can get the lock).

A. After object B is notified, or after two seconds.

Mostly right. It will wakeup sometime *after* getting the notification. Or it will wakeup sometime *after* 2 seconds. The time to acquire the lock doesn't change that -- it will still be after. Of course, you can argue that the *after* implies *immediately after*...


Which one is the correct?

Now, you have 2 answers that are clearly wrong. One that is wrong, but you can argue that it is right, because one part covers the other. And one that is right, but you can argue that it is wrong, because you imply that the word after assumes immediately.

Given this in a test, which one will you pick?

Henry

[Satya Maheshwari]

I wrote a small program in order to get my understanding of wait/notify validated. It may be helpful for you. Copy paste it and try to run.

  
public class WaitNotify implements Runnable{
    
    Object lock = new Object();
    public WaitNotify() {
    }
    
    public void run() {
        String threadName = Thread.currentThread().getName();
        System.out.println(threadName+":"+"Waiting to get lock");
        synchronized(lock) {
            System.out.println(threadName+":"+"Got the lock");
            System.out.println(threadName+":"+"Start work-1");
            for(int i=0;i<100000;i++)
                ;
            System.out.println(threadName+":"+"Work-1 done");
            try {
                System.out.println(threadName+":"+"Notify others that lock can be taken once free");
                lock.notify();
                System.out.println(threadName+":"+"Free up the lock and start wait to regain it");
                lock.wait();
            } catch (InterruptedException ex) {
                ex.printStackTrace();
            }
            System.out.println(threadName+":"+"Wait over, regained the lock");
            System.out.println(threadName+":"+"Start work-2");
            for(int i=0;i<100000;i++)
                ;
            System.out.println(threadName+":"+"Work-2 done");
            //System.out.println(threadName+":"+"Do not notify others that I am done");
            System.out.println(threadName+":"+"Notify others that lock can be taken once free");
            lock.notify();
        }
        System.out.println(threadName+":"+"Released lock as now out of synchronized block");
    }
    
    public static void main(String[] args) {
        WaitNotify obj = new WaitNotify();
        Thread t1 = new Thread(obj,"thread1");
        Thread t2 = new Thread(obj,"thread2");
        Thread t3 = new Thread(obj,"thread3");
        t1.start();
        t2.start();
        t3.start();
    }
    
}
 

[ March 29, 2008: Message edited by: Satya Maheshwari ]