Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / First Aid / March 2004

Tip: Looking for answers? Try searching our database.

Thread behaviour

Thread view: 
lonelyplanet999 - 06 Mar 2004 07:15 GMT
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
programmer exam web site that said the reverse.

Below program compiled & ran without error. But I would like to ask if
public void start() was replaced by public void run(), how the
program's behaviour got changed ? Did the difference laid at separate
stacks being created for thread instances 'first' & 'second' if public
void run() implemented instead of public void start() ? From program
execution output I didn't see the difference. :)

public class Holt extends Thread {
 private String sThreadName;
 public static void main(String argv[]) {
   Holt h = new Holt();
   h.go();
 }
 Holt() {}
 Holt(String s) {
   sThreadName = s;
 }
 public String getThreadName() {
   return sThreadName;
 }
 public void go() {
   Holt first = new Holt("first");
   first.start();
   Holt second = new Holt("second");
   second.start();
 }
 public void start() {
   for (int i=0; i<2; i++) {
     System.out.println(getThreadName()+i);
     try {
       Thread.sleep(100);
     } catch (InterruptedException e) {
       System.out.println(e.getMessage());
     }
   }
 }
}
Thorsten Seelend - 06 Mar 2004 09:53 GMT
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
Steve Horsley - 06 Mar 2004 13:03 GMT
> 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


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.