7

If a thread is running a function func1 that calls another function func2 inside it...

Then I called thread.Abort()

Will this stop func1 only
OR func1 and func2 and all the functions func1 has called??

Thanks

Edit: Here are more detail:

func1 is called in a new thread, it continuously calls func2 on regular basis...
func2 begin doing some work only if some array is not null.. it finishes it and return

When supervisor wants to save data, it aborts Thread of func1- and then makes array null, saves data, then fill in the array with new one.. and starts Thread with func1 again..

Sometimes exception is raised because array is null in func2.. so func1 abort did not affect func2

Betamoo
  • 14,964
  • 25
  • 75
  • 109
  • When you wrote a test program and tried it, what happened? ;) – Juliet May 24 '10 at 20:15
  • 1
    I surprisingly found that sometimes func2 did not stop!! – Betamoo May 24 '10 at 20:16
  • Is your test program simple enough that you can post it here so we can try to run it? If not, can you try to simplify it down to the simplest possible code that demonstrates the behaviour you witness. – Mark Byers May 24 '10 at 20:38
  • 2
    I've just re-read your question. I think you're assumping that when `Thread.Abort` returns it means the thread has been stopped already. That is not true - it may take some time before the thread stops (or it might never stop). If you want to be sure that the thread has stopped you need to synchronize with it, for example by calling `Thread.Join`. – Mark Byers May 24 '10 at 21:27

4 Answers4

15

Thread.Abort is not guaranteed to stop the thread and you should avoid using it if possible.

Calling this method usually terminates the thread.

Emphasis mine.

What it does is raise a ThreadAbortException in the target thread. If you catch this exception, the code will continue executing until it reaches the end of the catch block, at which point the exception is automatically rethrown. If you don't catch it, it is similar to a normal exception - it propagates up the call stack.

Assuming you don't catch the exception, all the code running in that thread will stop running. Other threads that were started from that thread will not be affected.

Mark Byers
  • 811,555
  • 193
  • 1,581
  • 1,452
  • 4
    As an aside, it's generally a bad idea to use `Thread.Abort()` as means to control thread execution lifetime. One should always strive to write threading code to be sensitive to shutdown conditions and terminate gracefully without requiring calls to `Abort`. – LBushkin May 24 '10 at 20:27
3

Anything started within that thread will be aborted.

Wayne Koorts
  • 10,861
  • 13
  • 46
  • 72
1

You could be facing a race condition, where your main routine nulls the array before the ThreadAbortException reaches the func1 thread but after func2 checks for null array.

As a minimum, your main code and func2 should use a lock around the array. You should also test that the func1 thread is dead before restarting it again. And as everyone else has said, signal a thread to stop rather than relying on Thread.Abort.

I'm not 100% sure from your description that func2 is called from within the func1 thread, but if func2 is run on a different thread that's started from within func1, killing the func1 thread won't affect func2 as all threads exist as children of your parent process, not of the thread that they were started from.

Ed Power
  • 8,310
  • 3
  • 36
  • 42
0

For who cares:
After more debugging I found that the thread is initialized once more before start; causing a thread to run in background...

    Thread T
    T=new Thread(func1);
    // Some code...
    // Start:
    T=new Thread(func1);

This unreferenced one in background is not affected with Abort()... so it will continue working and it tries to use null array...

At the end:
Abort() will end your thread, except in some conditions (mentioned above in other's answer)
Abort() will not end a thread after being unreferenced (obviously)

Thanks!!

Betamoo
  • 14,964
  • 25
  • 75
  • 109
  • 2
    Bear in mind that the ThreadAbortException can also be injected at awkward places, potentially leading to nasty conditions like failing to release a lock or failing to call Dispose (i.e. exception injection after the resource allocation and before the try-finally is entered). A better solution for controlled thread shutdown of threads that might block is Thread.Interrupt(). – Dan Bryant May 24 '10 at 22:01