views:

141

answers:

7

I need to implement thread.start() method in my java code. Please let me know through an example of overriding of thread.start() method and how it works?

+9  A: 

You should not. Override run instead

Schildmeijer
+2  A: 

You don't override the start, you override the "run". You can simply implement a thread by:

new Thread() {
  public void run() {
    //your code here
  }
}.start();
//start will call the logic in your run method
Manny
i have to call the logic in my start method.
Anand
so,please let me know how to override start() method with an example.
Anand
Call your logic inside run method.
Rekin
like what I said in the comment above, .start() will call the logic in your "run" method, so you place your code inside the run method AND I assure you it will be called when you call .start().
Manny
like i have commented above i want to ensure that the specific run() method from the start() method is called.In my code there is two run() methods and I want to decide in start() method that which run() would be called.
Anand
why not fork the multiple runs inside the run() method itself? e.g. if (somecondition) super.run() else //do your normal code
Manny
@Anand: If you show some code that will make it easier to help.
Babar
@Anand: No, you don't have to call the logic in the start method.
Christoffer Hammarström
+2  A: 

Actually, you can call run() to run a thread instead of start() to run a thread. But is a little difference.

Suppose you create two threads;

thread t1 = new thread();
thread t2 = new thread();

Case 1 : If you call t1.run() and t2.run() one after another they will start to run t1 and t2 synchronously(Sequencially).

Case 2 : If you call t1.start() and t2.start() one after another they will call their run() methods and start to run t1 and t2 asynchronously(Parellaly).

Namalak
Ofcourse. But what if I want to have one thread,which will run in two different ways. Means have two different run() methods based on different conditions. Then we should have to start a thread with thread.start() method and in that we should have a condition based on that different run() methods should be called.
Anand
+2  A: 

Agree with Schildmeijer, don't override start, override run() instead.

In fact, although start can be overridden (it's not final), it calls the native start0 method which in turn will cause the VM to call the run method (actually from the context of a native thread/process). The native start0 method has private access, so even if you overrode the start, I can't see how you could reproduce the affect.

The client calling start() is within a thread (lets say, the main thread), it's not until the run method has done its thing that another thread will be spawned.

Take a look at the Sun (ahem, Oracle) tutorial on threads at http://download.oracle.com/javase/tutorial/essential/concurrency/index.html, in particular the section on starting threads.

Toby
try{private synchronized void start() { if (threadStatus != 0) throw new IllegalThreadStateException(); group.add(this); start0(); if (stopBeforeStart) { stop0(throwableFromStop); } this.run();} }catch(Exception e){ System.out.println(e);}} private native void start0();
Anand
in ths code its giving an error that start is not resolved. Please let me know that what is the problem in this code.
Anand
+6  A: 

As others said, overriding Thread.start() is not the way to do it. Usually, I wouldn't override Thread.run() either, but use a Runnable.

If you have to decide which method to run after the thread has been spawned, you could do something like this:

final Runnable runnableA = ...;
final Runnable runnableB = ...;

Runnable r = new Runnable() {
    @Override
    public void run() {
        if (...) {
            runnableA.run();
        } else {
            runnableB.run();
        }
    }
}

Thread thread = new Thread(r);
thread.start();

If, as you say, you have a superclass and a subclass where the run() method is overidden, you can just rely on late binding and the proper method will be invoked automatically:

Runnable couldBeAOrB = ...;
Thread thread = new Thread(couldBeAOrB);
thread.start();
Henning
+2  A: 

class Worker implements Runnable{

public void run(){ if("foo"){ runFoo(); } else { runBar(); } }

private void runFoo(){ // something }

private void runBar(){ // else }

}

I'm pretty sure, you needn't to overwrite the start-Method.

By the way: Take al look at java.util.concurrent.Callable

http://download.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/Callable.html

ckuetbach
+3  A: 

You can override start as any other method

    Thread myThread = new Thread() {

        @Override
        public void start() {
            // do something in the actual (old) thread
            super.start();
        }

        @Override
        public void run() {
            // do something in a new thread if 'called' by super.start()
        }
    };

but you must call super.start() to create a new thread and have run() called in that new thread. The original start does some magic (native code) that you hardly can mimic.

If you call run() directly from within your start() (or any other method), it is executed in the actual thread as a normal method, not in a new thread. There is no reason to use a Thread if you don't want to run some code in a new thread.

You must put your decision logic in the run() method, maybe using some variable set in the constructor (or another method, eventually in start) if that is really needed. I can not find any reason for needing this variable, it should be enough to test the condition in run() as already suggested elsewhere.

    class MyThread extends Thread {

        private final boolean flag;

        public MyThread(boolean someCondition) {
            flag = someCondition;
        }

    // alternative  
    //    @Override
    //    public synchronized void start() {
    //        flag = <<someCondition>>
    //        super.start();
    //    }

        @Override
        public void run() {
            if (flag) {
                // do something like super.run()
            } else {
                // do something else
            }
        }
    }

but it would be easier to understand and maintain if you do it like @Henning suggested!
It's also a more object oriented solution...

Carlos Heuberger