permaculture playing cards
The moose likes Threads and Synchronization and the fly likes Calling after Thread.start ! Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of Java Interview Guide this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "Calling after Thread.start !" Watch "Calling after Thread.start !" New topic

Calling after Thread.start !

Gagan Indus
Ranch Hand

Joined: Feb 28, 2001
Posts: 346

Consider the following code plz :

The output of above code as it is :
World15 World14 World13 World12 World11 World10 World9 Hello0 World8 Hello1 Worl
d7 Hello2 World6 Hello3 World5 Hello4 World4 Hello5 World3 World2 World1 main()

tht is , 15 times "World" , n 6 times "Hello"
Now Try changing the LINE#1 in above code to ";" , and the output changes to :
World15 World14 World13 World12 World11 World10 World9 World8 World7 World6 Worl
d5 World4 World3 World2 Hello0 World1 Hello1 Hello0 Hello2 Hello1 Hello3 Hello2
Hello4 Hello3 Hello5 Hello4 Hello5 main() Ending

This is 15 times "World" n 12 times "Hello"
So wht exactly is wrong here? is supposed to call implicitly , as test was passed as a Runnable to t's constructor?
( as sugested by run()'s implementation in Thread class :

public void run() {
if (target != null) {;
I experimented with the code a lot , placing lots of join() , isAlive() , run()s etc , and moving them up n down the code , and a strange observation is " Once the thread t actually gets running , the direct call to t's run() ( like ) is simply being ignored ! "
Is any such norm tht we can not call run() explicitly , while the thread in q is actually running ? As far as i knw , NO such norm , becoz other code relating to this give expected outputs
(or are we dealing wid some probable bug of JVM ?! )
DO anyone hav any idea , thought , suggestion about this?
plz help , do comeup with anything u hav in ur mind , on this topic ...

Gagan (/^_^\)

Gagan (/^_^\) SCJP2 SCWCD IBM486 <br />Die-hard JavaMonk -- little Java a day, keeps you going.<br /><a href="" target="_blank" rel="nofollow">My Blog</a>
Peter den Haan
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
The solution is quite simple. Let's look again at that bit of code in java.lang.Thread you quoted:

Given that is not being called when you expect it to, the issue must be that target has been set to null. A little rummage in the code leads me to the following:

Evidently, as soon as a thread has finished executing, the target field gets set to null and no longer invokes the target's run() method. Other than what you suspected, run() is still called as after the thread has started, but it is no longer called as soon as the thread has finished. This seems to fit well with observed output.
I would agree that Sun should've updated the javadoc for
- Peter
Gagan Indus
Ranch Hand

Joined: Feb 28, 2001
Posts: 346
Thankx Peter !
wow , yes it was indeed simple as u said . Never bothered to check da private exit() method , tho i was suspecting tht target!=null comparision is being failed somehow .
I experimented wid the code with this-new point in mind , and the output seen to second the code-functionality expected . After Thread t finishes , target is made null ( Aggressively null-ing a object , as api-doc says ) , n so call to t's run do NOT leads to a implicit call to
Thankx once again !
Happy Coding !
Gagan (/^_^\)
Andrew Trumper

Joined: Sep 08, 2001
Posts: 12
Why didn't you just do
rajashree ghatak
Ranch Hand

Joined: Mar 10, 2001
Posts: 151
Hi Gagan,
Thanx for ur post to my query.Read this post but i want to know where is the run() impleamention of Thread class given which u quoted?i have checked Thread class in APIs for this purpose but in vain.
public void run() {
if (target != null) {;
Also is the reason mentioned by Peter den Haan as to why doesn't implicitly call after t.start() is executed
also the reason why we cannot call start() method on the same thread twice?Once the first t.start() is executed target is set to null and hence the secondt.start() doesn't yeild anything.

I agree. Here's the link:
subject: Calling after Thread.start !
It's not a secret anymore!