stop a thread

[George2]

Hello everyone,


About using Abort or Interrrupt to stop a thread, I have two questions.

1. What are the pros and cons about Abort v.s. Interrupt?

2. If I program a background thread, compared with normal thread, will there be any special points to take care of (e.g. code in different) if the thread is stopped with Abort (or Interrupt)?


thanks in advance,
George

[Arjay]

Don't use Abort, signal the thread to exit instead. Research the details in msdn.

[George2]

Thanks Arjay,


This is the only issue I found from MSDN about Thread.Abort. Are there any other issues?


http://msdn2.microsoft.com/en-us/lib...ta(VS.80).aspx

--------------------
There is also a chance that a static constructor could be aborted. In rare cases, this might prevent instances of that class from being created in that application domain.
--------------------

Don't use Abort, signal the thread to exit instead. Research the details in msdn.

regards,
George

[Arjay]

Abort is the .Net equivalent of the Win32 api's TerminateThread or TerminateProcess. In general threads and processes should be signalled to exit rather than terminated; otherwise unpredictable things can happen, resources not released, and so on. Read up on these api's in msdn for more info.

[George2]

Thanks Arjay,


You are so knowledgable. But this time I am not caring too much about implementation details about .Net API. :-)

I am wondering,

1. Why Thread.Abort will cause resource leak (e.g. expected finally block or Finalizer is not executed)?

2. How do we avoid such leak?

Abort is the .Net equivalent of the Win32 api's TerminateThread or TerminateProcess. In general threads and processes should be signalled to exit rather than terminated; otherwise unpredictable things can happen, resources not released, and so on. Read up on these api's in msdn for more info.

regards,
George

[Arjay]

George, if you can't find the answer in msdn, you need to roll up your sleeves, write some code, and test your ideas out. With a couple of Console.Write or Debug.Write statements you can find out quick enough.

As far as preventing a resource leak when using Abort, the answer is simple - don't use Abort (or TerminateThread or TerminateProcess). The Msdn documentation pretty much tells you this.

[George2]

Thanks Arjay, :-)


How about Thread.Interrupt, also have some resource leak issues? :-)

In my point of view, if we handle ThreadInterruptException, release resource, then it should be fine and no resource leak.

George, if you can't find the answer in msdn, you need to roll up your sleeves, write some code, and test your ideas out. With a couple of Console.Write or Debug.Write statements you can find out quick enough.

As far as preventing a resource leak when using Abort, the answer is simple - don't use Abort (or TerminateThread or TerminateProcess). The Msdn documentation pretty much tells you this.

regards,
George

[Arjay]

Thanks Arjay, :-)


How about Thread.Interrupt, also have some resource leak issues? :-)

In my point of view, if we handle ThreadInterruptException, release resource, then it should be fine and no resource leak.




regards,
George

See my previous post about rolling up your sleeves, writing some code, and trying it out.

Oh, and what's wrong with everyone's suggestion of just signalling the thread to exit?

[George2]

Thanks Arjay,


My thread is doing some time consuming calculations, how could I receive signal in the midddle? :-)

My idea is, if I have to use signal, I need to check in the middle of calculations, and using the timeout form of WaitOne. But my concern is it will degrate the performance of my calculation (my concern is wait signal timeout). Any suggestions?

See my previous post about rolling up your sleeves, writing some code, and trying it out.

Oh, and what's wrong with everyone's suggestion of just signalling the thread to exit?

regards,
George

[Arjay]

Any suggestions?

Yes. Write it with an event and check the event as often as necessary within the thread.

Then profile the application and MEASURE the difference in performance.

[George2]

Thanks Arjay,


1.

If I set the event in signalled status, then next time, when the thread checks the singal by using WaitOne, it will be blocked, right?

2.

You mean using the timeout form of wait to check event, like this one?

http://msdn2.microsoft.com/en-us/lib...t0(VS.80).aspx

Yes. Write it with an event and check the event as often as necessary within the thread.

Then profile the application and MEASURE the difference in performance.

regards,
George

[Arjay]

Yes, use a timeout of zero to quickly determine if the event has been set.

[George2]

Thanks Arjay,


I am writing code and I have some issues dealing with the exitContext parameter of WaitOne, do you have any ideas?

http://www.codeguru.com/forum/showthread.php?t=451479

Yes, use a timeout of zero to quickly determine if the event has been set.

regards,
George

[Arjay]

George, please don't cross post.

It is my only hope that one day we will respond to a post without getting asked yet one more followup question.