Threads Self Test (Kathy & Bert SCJP 6)

[Eduardo Fierabras]

Hi, I got a doubt about the next Self Test question: (page 777)

9. Given:

public static synchronized void main(String[] args) throws InterruptedException {
       Thread t = new Thread();
       t.start;
       System.out.print("X");
       t.wait(10000);
       System.out.print("Y");
}

What is the result of this code?

A. It prints X and exits
B. It prints X and never exits
C. It prints XY and exits almost immediately
D. It prints XY with a 10 seconds delay between X and Y
E. It prints XY with a 10000 seconds delay between X and Y
F. The code does not compile
G. An exception is thrown at runtime

Answer:
G is correct. The code does not acquire a lock on t before calling t.wait(), so it throws an IllegalMonitorStateException. The method is synchronized, but it's not synchronized on t, so the exception will be thrown. If the wait() were placed inside a synchronized(t) block, then the answer would have been D.

Ok, I can understand the answer, but there is something in the code that I wonder about.
Thread t = new Thread(); creates a Thread instance, instead of create an object that extends Thread, to override the run() method.
The Thread class original run() methot does nothing if the thread object wasn't constructed using a separate Runnable run object (as said in the API Javadoc).
Then, when the scheduler select the t thread to pass it from runnable to running, how is that the code executed is the statements following t.start();
I thought that when a thread goes into running state, the code in the run() method is executed. In this case the run() method is empty, or not?

Any help will be greatly appreciated.
Thanks a lot, and sorry for my bad english!!!

[Henry Wong]

Eduardo Fierabras wrote:
Then, when the scheduler select the t thread to pass it from runnable to running, how is that the code executed is the statements following t.start();
I thought that when a thread goes into running state, the code in the run() method is executed. In this case the run() method is empty, or not?

The default run() method is not exactly empty, but yea, it won't do anything noticeable. Just quickly do something and done -- pretty much as if the run() method was empty.

Henry

[Eduardo Fierabras]

Hi Henry, thanks for your quickly answer.

I know that the original run() method isn't totally empty. What I mean is that it haven't any code written by me.
The API javadoc says that the run() method of the Thread class will call the run() method of the runnable object passed to the Thread constructor.
If the Thread object wasn't created passing a runnable object, the original run() method (not overriden) does nothing.
Perhaps the correct rule is the following: In the book example of code, the main thread creates a new thread (t), and t starts running the remaining code of the main() method.
And when t will terminate his job, the program will be finished, and the main thread that was executing the main() method is dead.
But what if the scheduler put thread t back to runnable before it has terminated his job? Then, the main thread can be put running again? And if so, at what point continues his job?

Thanks again.

[Henry Wong]

Eduardo Fierabras wrote:
Perhaps the correct rule is the following: In the book example of code, the main thread creates a new thread (t), and t starts running the remaining code of the main() method.
And when t will terminate his job, the program will be finished, and the main thread that was executing the main() method is dead.
But what if the scheduler put thread t back to runnable before it has terminated his job? Then, the main thread can be put running again? And if so, at what point continues his job?

Sorry, read what you wrote three times. Don't have a clue on the point you are making.

How is an empty run() method that different from a run() method does something insignificant, that the threading engine has to do something different?

Henry

[Henry Wong]

Eduardo Fierabras wrote:
Perhaps the correct rule is the following: In the book example of code, the main thread creates a new thread (t), and t starts running the remaining code of the main() method.

When the main thread creates and starts the new thread, then there will be two threads. Thread t will do the initialization code, then run() method, then teardown code for its thread. And the main thread will continue running "the remaining code of the main() method". After which, it will do the teardown code for the main thread.

Eduardo Fierabras wrote:
And when t will terminate his job, the program will be finished, and the main thread that was executing the main() method is dead.

When thread t, or the main thread finishes, *and* it is the last thread, then the program is finished. As long as there is an user thread running, the program is not finished.

Henry

[Eduardo Fierabras]

Thanks Henry, sorry to be so stupid.

    
 public static synchronized void main(String[] args) throws InterruptedException {  
        Thread t = new Thread();  
        t.start;  
        System.out.print("X");  
        t.wait(10000);  
        System.out.print("Y");  
 }  

The t thread can't do anything because his run() method does nothing. The main thread continues his job, the main() method, at line 5. At this point, t is dead.

[Jim Hoglund]

Henry : Does using "synchronized" on main() have any effect on the
user application? I would guess not, but what does the JVM do with it?

Jim... ...

[Ankit Garg]

Synchronization on static methods make effect if they are called multiple times within the same JVM by multiple threads. The main thread is called by the JVM when the program starts. After that if you call it yourself using multiple threads, then it will make an effect (but your program can easily go into an infinite recursion if you do something like that)...

[Jim Hoglund]

Thanks Ankit. Recursive calls to main() does indeed sound
risky. If static main() is synchronized, I suppose the class
object lock would be used.

Jim ... ...

[Abimaran Kugathasan]

Henry Wong wrote:

Eduardo Fierabras wrote:
Then, when the scheduler select the t thread to pass it from runnable to running, how is that the code executed is the statements following t.start();
I thought that when a thread goes into running state, the code in the run() method is executed. In this case the run() method is empty, or not?

The default run() method is not exactly empty, but yea, it won't do anything noticeable. Just quickly do something and done -- pretty much as if the run() method was empty.

Henry

Have a look on this