Am 5 Mar 2004 23:15:04 -0800 schrieb lonelyplanet999
<lonelyplanet999@my-deja.com>:
> From textbook, I was told to implement Thread code, the run() method
> need to be overriden. However, I just found below code from one java
[quoted text clipped - 7 lines]
> execution output I didn't see the difference. :)
> ...
Both are right :-))
You do have to override the "run()" method but you do NOT directly call it.
Doing so, the method would be executed in the calling thread (main-thread,
GUI-thread) and the calling method has to wait until run() has finished.
Invoking the "start()" method of your thread does exatly what you needs.
It creates a new thread (technical thread, not an instance of the class
Thread),
enables the run() method to be executed "inside" this new thread
and then immediately returns to the calling method.
On the other side you normally should NOT override the start() method
without
exactly knowing what it is expected to do.
Bye
Thorsten Seelend

Signature
Erstellt mit M2, Operas revolutionärem E-Mail-Modul:
http://www.opera.com/m2/
lonelyplanet999 - 06 Mar 2004 15:11 GMT
> Both are right :-))
>
> You do have to override the "run()" method but you do NOT directly call it.
> Doing so, the method would be executed in the calling thread (main-thread,
> GUI-thread) and the calling method has to wait until run() has finished.
You mean if I don't override "run()" but calling "start()" directly,
no new call stack will be created ? If "start()" do some lengthy job
the calling thread (let say the main-thread) has to wait indefinitely
until "start()" completes ?
> Invoking the "start()" method of your thread does exatly what you needs.
> It creates a new thread (technical thread, not an instance of the class
> Thread),
> enables the run() method to be executed "inside" this new thread
> and then immediately returns to the calling method
If I override "run()" and call "start()" instead of directly calling
"run()", JVM will create a new separate call stack from its calling
thread and start executing the "run()" code ? The sharing of CPU time
(suppose one CPU case) between the calling thread and the newly
created thread being determined by the JVM implementation ? That is,
sometimes I can see the calling thread running while sometimes the
newly created thread running ?
> On the other side you normally should NOT override the start() method
> without
> exactly knowing what it is expected to do.
I will not do that but just curious about the question's
implementation method. Before seeing this question, I don't know
overriding "start()" alone without overriding "run()" is legal.
> Bye
> Thorsten Seelend
> From textbook, I was told to implement Thread code, the run() method
> need to be overriden. However, I just found below code from one java
[quoted text clipped - 37 lines]
> }
> }
You got that from a book??? I think you should burn it.
* You should NEVER override start unless somewhere in there you
call super.start(). Oferriding start() as in the example above
leaves an unstarted thread for the duration of the program.
The above program is not multithreaded in any way. The main thread
creates three (yes three) Thread derivatives, does not start any
of them because the proper start() has been overriden.
Instead, the main thread runs through the printing loops itself,
whichis why you see the first loop finish before the second loop
prints anything.
Please stop extending Thread. It is a bad idea.
Steve