Threads k&B page 720

[Armel Moukoss]

hi,

I need your help, I don't understand the way this code works.
I thought that after writting b.start(); the code within the run() method
will be excuted.But it's excuted only later in synchronized.why ?

 
public class ThreadA {
public static void main(String[] args){
ThreadB b = new ThreadB();
System.out.println("total value before the start method :" + b.getTotal());
b.start(); // I thought it will execute the code within run method here
System.out.println("total value after the start method :" + b.getTotal());
synchronized(b){
try{
System.out.println("Waiting for b to compl�te ..");
b.wait();
System.out.println("After the wait");
}catch (InterruptedException e){}
System.out.println("Total is : " + b.total);
}
}

}
 
public class ThreadB extends Thread {
public int total;
public int getTotal(){
return total;
}
public void run(){
System.out.println("***********In the run method****************");
synchronized(this){
for (int i=0;i<100;i++){
total +=i;
}
notify();
}
System.out.println("***************End of the run method******************");
System.out.println("total value in synchronized method :" + getTotal());
}
}   

This is the output :

total value before the start method :0
total value after the start method :0
Waiting for b to compl�te ..
***********In the run method****************
After the wait
Total is : 4950
***************End of the run method******************
total value in synchronized method :4950

I have looked for in the old posts and i find one about this problem but the answer wasn't clear. Thank you for your help.

Armel

[chintan ramavat]

Threading behavior is JVM dependent and underlying OS.In this program, by seeing output it seems like Service thread main keeps running and gets the lock on Object B then after the flow hits the wait() method where it releases the lock and goes back to runnable state where it waits until somebody notifies it(in this case the Thread B does this work). the Thread which has began by invoking .START() gets it, completes the loop and hits the notify(), then after main gets it, and completes the following statements.

- the point is , b.start() does not guarantee that it will make thread running

- chintan

[marc weber]

Originally posted by Armel Moukoss:
...I thought that after writting b.start(); the code within the run() method will be excuted. But it's excuted only later in synchronized. why? ...

Once start() is called, it's up to the (platform-dependent) thread scheduler to decide when the new thread is given a chance to run. It's unlikely that the new thread's run method will be executed immediately after start is called.

If you run this program repeatedly, you will likely see different results. In this particular example, the output indicates that after calling start, the main thread continues running. It executes the println, then enters the synchronized block and obtains b's instance lock, then executes another println before calling wait.

Important: Note that wait() is an instance method defined in Object (not Thread) that causes the current thread to wait. In this case, the Thread instance b is used to invoke the instance method wait(), but it's the current thread -- not b -- that waits.

Waiting releases the main thread's hold on b's object lock. This allows b's run method to execute and obtain the object lock in its own synchronized block. After it's completed summing 1 through 99, it calls notify and leaves the synchronized block, releasing the lock.

notify() allows the original thread (main) to stop waiting and resume its execution -- but again, it's up to the thread scheduler to decide exactly when this happens. In this particular example, the main thread obtained b's lock again and resumed execution. After the main thread finished, the thread scheduler allowed b to execute its println statements.

I ran this example a few times (on a Windows machine), and occasionally saw b complete before the main thread was given a chance to resume. This illustrates how (platform-dependent) thread scheduling is unpredictable.

[dolly shah]

If you read carefully the description of this code in book you will get idea.

When you start b, it doesn't mean, that thread will start immediately. In class ThreadA main method is also a thread. So it is possible that main can starts before thread b. So that they use synchronized code to take a lock of b object & put the current thread(main thread) in wait. At line 9 b.wait release lock, so now code executes run method. After notify, wait thread wakes up & prints Total.
I think you will get now.

[Manfred Klug]

Originally posted by chintan ramavat:
after the flow hits the wait() method where it releases the lock and goes back to runnable state where it waits until somebody notifies it

Only for correctness. The thread goes into the waiting state.

[Armel Moukoss]

thank you guys for your help !!!

Armel

[Armel Moukoss]

I have another question if i delete the notify() method in class ThreadB i have the same result. I thought that without notify in class ThreadB, the class ThreadA will still wait. ThreadA complete his synchronized code without any problems.

Do you have any answer for this question ? Thank you.

Armel

[marc weber]

Interestingly, I just ran this several times on a Mac, and it's deadlocked every time with the following output...

total value before the start method :0
***********In the run method****************
***************End of the run method******************
total value in synchronized method :4950
total value after the start method :4950
Waiting for b to compl�te ..

As demonstrated in a previous example, the Mac thread scheduler seems much more eager to share CPU time among threads. As the output above indicates, b's run method begins executing immediately after start is called (as the original poster expected).

In other words, as soon as the other thread is ready to run, the Mac thread scheduler gives it CPU time instead of continuing on with the current thread. This illustrates a serious flaw in the above code, which seems to assume that the thread scheduler will be lazy, allowing the main thread into its synchronized block to call wait() before b's run method enters its synchronized block and calls notify().

[Manfred Klug]

Originally posted by Armel Moukoss:
I have another question if i delete the notify() method in class ThreadB i have the same result. I thought that without notify in class ThreadB, the class ThreadA will still wait. ThreadA complete his synchronized code without any problems.

Do you have any answer for this question ? Thank you.

Armel

At least with the JRE from Sun, notify() is used internally. Whenever a thread dies, it does a notifyAll() on itself. This is the reason why you don't see a deadlock.

[Armel Moukoss]

Thank you Manfred Klug for your help.

Armel