Thread.Abort issue

[Guest]

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.

 

[William Stacey [MVP]]

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

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.

 

[TT \(Tom Tempelaere\)]

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.

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,

 

[William Stacey [MVP]]

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,

 

[TT \(Tom Tempelaere\)]

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.

Thanks for the clarifications. Cheers,

No probs.

Cheers,

 

[William Stacey [MVP]]

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.

 

[Guest]

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.

 

[William Stacey [MVP]]

Lets see the basic worker loop your using. Remove anything not needed for
our purposes here.

--
William Stacey, MVP

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.