Thread.Abort vs Thread.Interrupt

Question

If I need to cancel some operation on a thread, when should I use Thread.Abort vs Thread.Interrupt. I read the documentation on it but not sure which scenario should I use a particular call between two.

If there is any third way of doing it, please let me know about it too with pros and cons.

Carrel

Why do you want to kill a thread in the first place? Murder is bad, make it commit suicide. – Lippi

Isn't the better solution to actually cancel the operation on the thread, rather than trying to killing the thread? – Contestant

actually its related to other question that i asked in different thread #5943188 – Carrel

Answer 1

I would avoid using Thread.Abort at all costs. Its behavior is much safer and predictable since .NET 2.0, but there are still some pretty serious pitfalls with it. Most of the aborts inside managed code can be made safe, but not all of them. For example, I believe there are some subtle problems if an abort request is triggered during the processing of a static constructor. Nevermind, the fact that the out-of-band exception can occur at anytime giving you little control over defining where the safe points for shutdown are located.

There are several acceptable ways to terminate a thread gracefully.

• Use Thread.Interrupt
• Poll a stopping flag
• Use WaitHandle events
• Specialized API calls

I discuss these methods in my answer here.

Rating

"if you abort a thread while it is in unmanaged code" I'm pretty sure Thread.Abort waits until you're back in managed code. Just like a thread that's in a finally block won't terminate until it has finished the finally. – Lippi

@CodeInChaos: Ah...maybe it is more safe than I realize. I'll look that up. – Rating

@CodeInChaos: Yup, says it right here msdn.microsoft.com/en-us/library/74169f59.aspx in the last paragraph. Nice catch! – Rating

@Brian: In the question comments above I added link to give you better picture of the context of where i need aborting this thread . Since this thread is calling a web-service, from your list of acceptable ways, seem like Thread.Interrupt is the only possible solution I can use. Since this thread is just calling an API from web-service and user wants to cancel this operation there is nothing much you can do except shutdown thad thread. Do you agree? – Carrel

@Silverlight: In that case you may be able to close the underlying web service channel. Hopefully, that will cause the call to return or throw an exception immediately. This would fall under the 4th option of specialized API calls. – Rating

@Brian: How can that be done? Its an external service hosted by somebody else. All I know is a web-method API that I call. That's it. I don't see what I can do except Abort or Interrupt on that thread. – Carrel

"out-of-band exception"? The thread has run out of elastic bands to flick other threads with? – Leveret

@Pharap: Haha...it's synonymous (or perhaps slang) for asynchronous exception. It's an exception that gets injected into the thread at an unpredictable point. You can see my answer here for details on how this happens. – Rating

Answer 2

Most suggestions are already done, but here's an example how i would do it:

    ManualResetEvent _requestTermination = new ManualResetEvent(false);
    Thread _thread;

    public void Init()
    {
        _thread = new Thread(() =>
         {

             while (!_requestTermination.WaitOne(0))
             {
                 // do something usefull

             }

         }));

        _thread.Start();
    }

    public void Dispose()
    {
        _requestTermination.Set();

        // you could enter a maximum wait time in the Join(...)
        _thread.Join();
    }

This way the dispose will wait until the thread has exited.

---

If you need a delay within the thread, you shouldn't add Thread.Sleep. Use the WaitOne(delayTime). This way you will never have to wait to terminate it.

Erepsin

Answer 3

I wouldn't use Thread.Abort ever. It causes an exception at an almost arbitrary time.

Lippi

Can you elaborate the arbitary time here. It doesn't try to kill the thread right at the point when Abort call is been made? Any links as reference to your statement will help too. – Carrel

It will not abort inside a finally clause, inside a try clause it will jump to the finally directly, it can be caught temporarily but will be rethrown at the end of the catch block, and since .net 4 the lock statement works as expected. But it can break the using statement. Which for me is enough to never use it. – Lippi

Answer 4

Be careful with Thread.Interrupt. If you don't build in some waiting or sleeping time the thread won't be interrupted.

Be careful with Thread.Abort. If you catch the ThreadAbortException your thread will terminate right after catch + finally.

(I like to use those methods to send a signal to my thread so that it knows it's terminating time, then clean up and exit.)

Morphophoneme

In the catch-block you have to call Thread.ResetAbort(). Just for sake of completeness. – Beginning

@PaulKertscher No, you don't have to. When you use Abort you can use ResetAbort to refuse abortion or continue with extra code after catch + finally (and your loop). – Morphophoneme