469,613 Members | 1,355 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,613 developers. It's quick & easy.

Thread.Abort issue

I want to abort a running thread, so I call MyThread.abort() function. My problem is this thread runs "almost" like a while(true) loop and I don't want the Abort() function interrupts the thread at any point in the thread. In fact, I have a section of code needs to be "protected" from being interrupted. How can I make sure Abort() will not land anywhere winthin this block? In other words, the Abort() must wait until this block of code is done before it actually stop the thread

Thanks.
Nov 16 '05 #1
7 3033
I seem to remember that abort only works when the thread is in
wait/sleep/join state (i.e. doing some kind of wait operation) Not sure if
..Net thread wrapper changes that model or not. That said, aborting is
rather prute force. From your description, a better approach may be to have
your thread loop check a sync'd bool (or other) for stopped state. I
normally setup an State enum like Running, Stopped, Paused, etc. and check
that at the top of my loop. Then you can clean up and exit nicely. If your
thread still does not stop after some period of time (ie. 5 sec, etc) then
abort it and join with wait. I am not clear on what condition would cause
the thread not to respond to both your stop signal and the thread abort, but
things do go bump in the night, so may need to abort and wait, abort and
wait for some max times. At some point, you just have to give up and exit
with fatal error as something must be really wrong at that point.

--
William Stacey, MVP

"Morris" <an*******@discussions.microsoft.com> wrote in message
news:F9**********************************@microsof t.com...
I want to abort a running thread, so I call MyThread.abort() function. My problem is this thread runs "almost" like a while(true) loop and I don't
want the Abort() function interrupts the thread at any point in the thread.
In fact, I have a section of code needs to be "protected" from being
interrupted. How can I make sure Abort() will not land anywhere winthin this
block? In other words, the Abort() must wait until this block of code is
done before it actually stop the thread.
Thanks.


Nov 16 '05 #2
> "Morris" <an*******@discussions.microsoft.com> wrote in message
news:F9**********************************@microsof t.com...
I want to abort a running thread, so I call MyThread.abort() function.
My problem is this thread runs "almost" like a while(true) loop and I don't
want the Abort() function interrupts the thread at any point in the thread. In fact, I have a section of code needs to be "protected" from being
interrupted. How can I make sure Abort() will not land anywhere winthin this block? In other words, the Abort() must wait until this block of code is
done before it actually stop the thread.
"William Stacey [MVP]" <st***********@mvps.org> wrote in message
news:eG**************@TK2MSFTNGP10.phx.gbl... I seem to remember that abort only works when the thread is in
wait/sleep/join state (i.e. doing some kind of wait operation) Not sure if

That is not true. Thread.Interrupt raises a ThreadInterruptedException on
the thread if the thread is in a join, wait or sleep state. Thread.Abort
will raise a ThreadAbortedException in all cases, except if the thread is
executing interop-code or unmanaged code in which case the exception will be
re-thrown as soon as the thread starts executing managed code again.
.Net thread wrapper changes that model or not. That said, aborting is
rather prute force. From your description, a better approach may be to have

Agreed. Currently, a ThreadAbortedException will leave a finally block if
the thread is executing it at that time. That is not very nice. I've heard
rumours that this could change in future versions of .NET.
your thread loop check a sync'd bool (or other) for stopped state. I
normally setup an State enum like Running, Stopped, Paused, etc. and check
that at the top of my loop. Then you can clean up and exit nicely. If your

That is one way. If the OP waits a lot using WaitHandle.WaitOne,
WaitHandle.WaitAll or WaitHandle.WaitAny then I suggest using
Thread.Interrupt on the thread that needs to be shut down. If not then the
OP could always check a volatile bool but he should not forget that polling
isn't very cpu-friendly. So he should leave some time (read: iterations) in
between checks.
thread still does not stop after some period of time (ie. 5 sec, etc) then
abort it and join with wait. I am not clear on what condition would cause
the thread not to respond to both your stop signal and the thread abort, but things do go bump in the night, so may need to abort and wait, abort and
wait for some max times. At some point, you just have to give up and exit
with fatal error as something must be really wrong at that point.
William Stacey, MVP


The only time that a thread would not repond to an Abort call is when the
thread is executing interop code or unmanaged code, and that the interop
code or unmanaged code blocks indefinitely or does not respond to the
ThreadAbortException.

Cheers,
---
Tom Tempelaere
Nov 16 '05 #3
That is one way. If the OP waits a lot using WaitHandle.WaitOne,
WaitHandle.WaitAll or WaitHandle.WaitAny then I suggest using
Thread.Interrupt on the thread that needs to be shut down. If not then the
OP could always check a volatile bool but he should not forget that polling isn't very cpu-friendly. So he should leave some time (read: iterations) in between checks.
Yes but that is not polling per se. That is checking status at the top of
the loop before a wait - and the loop needs to be done anyway. The var
should be checked again after an top wait completes or timesout (i.e.
waiting on an empty queue, etc.)
The only time that a thread would not repond to an Abort call is when the
thread is executing interop code or unmanaged code, and that the interop
code or unmanaged code blocks indefinitely or does not respond to the
ThreadAbortException.


Thanks for the clarifications. Cheers,

--
William Stacey, MVP

Nov 16 '05 #4
"William Stacey [MVP]" <st***********@mvps.org> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...
That is one way. If the OP waits a lot using WaitHandle.WaitOne,
WaitHandle.WaitAll or WaitHandle.WaitAny then I suggest using
Thread.Interrupt on the thread that needs to be shut down. If not then the OP could always check a volatile bool but he should not forget that

polling
isn't very cpu-friendly. So he should leave some time (read: iterations)

in
between checks.


Yes but that is not polling per se. That is checking status at the top of
the loop before a wait - and the loop needs to be done anyway. The var
should be checked again after an top wait completes or timesout (i.e.
waiting on an empty queue, etc.)


Checking a variable is double work. When you call Thread.Interrupt and the
thread is sleeping, joining or waiting then an exception is thrown to
unblock it. The exception itself tells you that the thread should stop
executing.

The only problem with this pattern is generic catch handlers. It will catch
all ThreadInterruptedException exceptions and your thread would not repond
in that case. So one should be cautious with generic catch-handlers vs
thread interruption.

This is not true for a ThreadAbortedException exception; it will be rethrown
at the end of each catch-handler it is caught in. If you call
Thread.ResetAbort (static) when you catch the ThreadAbortedException then
that exception will no longer be rethrown.
The only time that a thread would not repond to an Abort call is when the thread is executing interop code or unmanaged code, and that the interop
code or unmanaged code blocks indefinitely or does not respond to the
ThreadAbortException.


Thanks for the clarifications. Cheers,
--
William Stacey, MVP


No probs.

Cheers,
---
Tom Tempelaere
Nov 16 '05 #5
> Checking a variable is double work. When you call Thread.Interrupt and the
thread is sleeping, joining or waiting then an exception is thrown to
unblock it. The exception itself tells you that the thread should stop
executing.


I see your points, but do not agree it is "double" the work. A simple "if"
test is about the fastest thing you can do. Very quick. You also may need
to check var for different values such as Stopped, Paused, etc. Exceptions
are expensive in terms of how long they take. I would not use exceptions to
handle normal processing like this. Exceptions should be used for things
that can not be handled normally. This pattern of checking a var is seen in
many server designs, however the contrary is not seen so much AFAICT. It is
interesting, however, and probably has value for certain designs.

--
William Stacey, MVP
Nov 16 '05 #6
Well, I'm glad my question entertained you, but I am still searching for a good solution here. :) Please

In my case, I cannot
1/ Cannot handle Interupt or Abort exception: b/c that basically "interrupts" the block of code that needs to be completed before anything else may happen. That's why I said I had a "protected" section of code need to be blocked out (uninterruptable). Unless I can get something like "Resume Next" as saying below

2/ Cannot polling too long for the next "ready" time: b/c this thread is spawned by a window service and is aborted when OnStop() is called by SCM. As you may know, OnStop won't give you much time to poll for when the thread can be aborted

Ideally, I am looking for either of this
1/ A way to NICELY return the SCM's OnStop call and keep the service running if the thread cannot be aborted. I can check thread's status to return approriately

2/ Set the block of code protected from thread's abort/interrupt or (like VB) Resume Next when the exception happens (and deal with it after the code is complete

Any ideas? Thanks a bunch.
Nov 16 '05 #7
Lets see the basic worker loop your using. Remove anything not needed for
our purposes here.

--
William Stacey, MVP

"Morris" <an*******@discussions.microsoft.com> wrote in message
news:20**********************************@microsof t.com...
Well, I'm glad my question entertained you, but I am still searching for a good solution here. :) Please!
In my case, I cannot:
1/ Cannot handle Interupt or Abort exception: b/c that basically "interrupts" the block of code that needs to be completed before anything
else may happen. That's why I said I had a "protected" section of code need
to be blocked out (uninterruptable). Unless I can get something like "Resume
Next" as saying below.
2/ Cannot polling too long for the next "ready" time: b/c this thread is spawned by a window service and is aborted when OnStop() is called by SCM.
As you may know, OnStop won't give you much time to poll for when the thread
can be aborted.
Ideally, I am looking for either of this:
1/ A way to NICELY return the SCM's OnStop call and keep the service running if the thread cannot be aborted. I can check thread's status to
return approriately.
2/ Set the block of code protected from thread's abort/interrupt or (like VB) Resume Next when the exception happens (and deal with it after the code
is complete.
Any ideas? Thanks a bunch.


Nov 16 '05 #8

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

14 posts views Thread by Daisy | last post: by
20 posts views Thread by Doug Thews | last post: by
18 posts views Thread by Urs Vogel | last post: by
5 posts views Thread by Soren S. Jorgensen | last post: by
3 posts views Thread by Raj Wall | last post: by
reply views Thread by =?Utf-8?B?aGVyYmVydA==?= | last post: by
5 posts views Thread by andrew | last post: by
18 posts views Thread by =?Utf-8?B?VGhlU2lsdmVySGFtbWVy?= | last post: by
reply views Thread by devrayhaan | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.