• Post Reply Bookmark Topic Watch Topic
  • New Topic

Thread's start( ) method

 
Ajit B
Greenhorn
Posts: 28
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi all.......
when the thread finishes it's execution why can't we start it all over again? can any one explain me why can't we call the thread's 'start' method more than once? whats the concept behind this?
thx in advance..........Ajit


 
Peter den Haan
author
Ranch Hand
Posts: 3252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Because the Thread class represents an operating system thread (in a native thread JVM). You don't want the Thread to hold on to a valuable resource such as an OS thread until it is garbage collected, so the OS thread is junked once you exit the run() method.
If you want to be able to restart your code, don't extend Thread, implement Runnable.
- Peter
 
Ajit B
Greenhorn
Posts: 28
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi Peter
thanks for replying......

i have understood that we can't hold the OS resources till the object which was pointing to a thread gets garbage collected. So as soon as the thread finishes its run method , it frees the OS resources. but my question is we still have object alive which was pointing to Thread (with which we earlier called start() method and started the Thread). This object is still there in memory and is not garbage collected even after complete execution of thread. so again when i say threadObject.start() , shouldn't it start new Thread( )? ( OS resources will be freed after its complete execution thats different issue.)
ok and my second question is why there is this difference between Thread and Runnable? why its that when we implement Runnable we can start thread again but the same is not possible if we extend Thread.
eagerly waiting for your reply

........... Ajit
 
dan moore
Ranch Hand
Posts: 68
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi Ajit,

but my question is we still have object alive which was pointing to Thread (with which we earlier called start() method and started the Thread). This object is still there in memory and is not garbage collected even after complete execution of thread. so again when i say threadObject.start() , shouldn't it start new Thread( )?

i guess the easy answer is: no, because Thread is not defined to work that way.
as it says in the javadocs for java.lang.Thread "All threads...have died, either by returning from the call to the run method or by throwing an exception that propagates beyond the run method.". i think the docs could be clearer about the lifecycle of the Thread, but it is sort of stated - once the thread, started by start(), returns from run(), the thread dies.
theoretically Thread could be defined to behave differently, so that a new thread (actual thread of execution, not a Thread instance) could be created if you called threadObject.start() again, but that is just not what happens. (there are probably some good reasons for this behaviour, i have not thought it through to be honest).


ok and my second question is why there is this difference between Thread and Runnable? why its that when we implement Runnable we can start thread again but the same is not possible if we extend Thread.

the fact is you cannot start a thread again once it has died. to start a dead thread again is not possible from the definition of a thread dying. in fact Peter does not say you can start a thread again if you implement Runnable:

If you want to be able to restart your code, don't extend Thread, implement Runnable. - Peter

i think Peter is referring to the fact that if you implement Runnable instead of extending Thread, you can run the code again with as many threads as you like, using something like:

you can retain your runnableObject, run it, and then run it again on a new thread even after the first thread has died. but you will not actually be restarting the first thread, merely running the code with another thread. this makes things clearer if you are going to use more than one thread, because it separates out the code you want to run (in your runnableObject) from the threads that will actually be calling it.
in a way i think this part of the confusion of having run() as part of the Thread class (for instance the threadObject.run() method can be run by threads other than the thread represented by the threadObject - well i find it confusing, anyway).
in fact if you want really confusing, you could actually restart your code in your Thread-extended threadObject by using the same syntax:

which will now be running your threadObject with a new thread (represented by the newThread object), not the thread represented by threadObject! i think this is why it is best to implement Runnable and separate out the creation of threads from the instantiation of the object you wish to run.
you could actually do some work to retain a thread and get it to call your run() method as many times as you like, the code would look something like:

oh blimey, is there an easy way to explain this? hope that helps.
cheers, dan.
 
Ajit B
Greenhorn
Posts: 28
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi dan ........
thanks for your reply......... ya you are right i took the wrong meaning of what Peter was saying.
If you want to be able to restart your code, don't extend Thread, implement Runnable. - Peter

ok so the conclusion is "Thread behave like this cause they are defined in that particular way."
once again thanks for the pain you have taken to answer my query and for your innovative examples.
......... Ajit

 
Peter den Haan
author
Ranch Hand
Posts: 3252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Dan, spot on - thanks. One minor addition:
theoretically Thread could be defined to behave differently, so that a new thread (actual thread of execution, not a Thread instance) could be created if you called threadObject.start() again, but that is just not what happens. (there are probably some good reasons for this behaviour, i have not thought it through to be honest).
It could behave like that, but then it would no longer be a simple abstraction of an operating system Thread. It would be (say) a ThreadRunner. Ultimately it's a design choice: Thread represents an OS thread.
- Peter
 
Mo Ibrahim
Greenhorn
Posts: 28
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ajit,
To completely understand threads, take a look at this http://www.javaranch.com/ubb/Forum27/HTML/000131.html . A good amount of information is available for you.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!