How do I abort a specific thread that is already running?

Question

4.00/5 (1 vote)

See more:

I have a problem with threading. I want to have a processThread that I can reuse as many times as possible and also gives the ability of stopping an already running thread, dispose the running thread and start a new one in the same thread!

I have tried alot with just Thread and Task but can't get it work as I want.

The reason I want this is to simulate a RealTime calculation from a textbox field, there the thread will be called on KeyUp. And when the user continues to type in the same textbox the Thread that was called from the KeyUp should be restarted. This is connected to a special validation which includes some characters and therefore the process has to be restarted/aborted.

In this method I want to use Thread.Sleep(1500) just to make sure that the user has stopped typing.
The code is as following and this little code gives the error shown in the bottom:

if(processThread.IsAlive)
   {
       processThread.Abort();
   }

Code:

private Thread processThread;

private void incomeTBX1FP_KeyUp(object sender, KeyEventArgs e)
{
    bool processSucceed = false;
    if(processThread.IsAlive)
    {
        processThread.Abort();
    }

    Thread.Sleep(1500);
    processThread = new Thread((ThreadStart)delegate
        {
            ProcessValidationAndMemory(incomeTBX1FP.Text, income1LblFP.Text, 501, 1, out processSucceed);
            if (!processSucceed)
            {
                MessageBox.Show(incomeTBX1FP.Text + "innehåller ett felaktigt värde", "Ett fel har uppstått", MessageBoxButtons.OK, MessageBoxIcon.Error);
                incomeTBX1FP.Focus();
                incomeTBX1FP.SelectAll();
            }
        });
    processThread.Name = "InputThread";
    processThread.Start();

}


private void ProcessValidationAndMemory(string inputString, string inputLabel, short labelIndex, short incomeIndex, out bool processSucceed)
{
    double moneyValue;
    if (InputUtility.GetIncome(out moneyValue, inputString))
    {
        incomeArray[incomeIndex] = moneyValue;
        allLabels[labelIndex] = inputLabel;
        MessageBox.Show(incomeArray[incomeIndex].ToString() + " kr " + allLabels[labelIndex].ToString(), "TEST", MessageBoxButtons.OK);
        processSucceed = true;
    }
    else
    {
        processSucceed = false;
    }
}

Error Message:

System.NullReferenceException was unhandled
Message=Object reference not set to an instance of an object.
Source=My Economy Lite
StackTrace:
at My_Economy_Lite.MainWindows.incomeTBX1FP_KeyUp(Object sender, KeyEventArgs e) in C:\Users\Michael\documents\visual studio 2010\Projects\My Economy Lite\My Economy Lite\MainWindows.cs:line 39
at System.Windows.Forms.Control.OnKeyUp(KeyEventArgs e)
at System.Windows.Forms.Control.ProcessKeyEventArgs(Message& m)
at System.Windows.Forms.Control.ProcessKeyMessage(Message& m)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.TextBoxBase.WndProc(Message& m)
at System.Windows.Forms.TextBox.WndProc(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.DebuggableCallback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG& msg)
at System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(IntPtr dwComponentID, Int32 reason, Int32 pvLoopData)
at System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context)
at System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context)
at System.Windows.Forms.Application.Run(Form mainForm)
at My_Economy_Lite.Program.Main() in C:\Users\Michael\documents\visual studio 2010\Projects\My Economy Lite\My Economy Lite\Program.cs:line 18
at System.AppDomain._nExecuteAssembly(RuntimeAssembly assembly, String[] args)
at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args)
at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean ignoreSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.ThreadHelper.ThreadStart()
InnerException:

Posted 8-Mar-11 0:05am

User 7115037

Add a Solution

2 solutions

Solution 2

Try this :

C#

if(processThread!=null && processThread.IsAlive)
   {
       processThread.Abort();
   }

also stop thread before abort it

Posted 8-Mar-11 0:26am

Piccadilly Yum Yum

Updated 8-Mar-11 0:34am

v2

Comments

Sergey Alexandrovich Kryukov 8-Mar-11 11:30am

This is acceptable in certain cases and with certain.
I voted 3 not because this is unacceptable (in some situations this is unavoidable), but becuase you should have explained that correct handling of this situation should be based on handling ThreadAbortException inside thread. Without and good understanding how to handle it this step you suggestion is really bad.

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Olivier Levrey · Accepted Answer · 2011-03-08T00:25:00

Solution 1

In addition to Piccadilly's answer, there are several problems with your code:

1- Calling Abort is not recommanded. It is not a clean way to stop a thread. Besides, you need to handle the exception that will be raised from the running thread.
Instead I would recommand to use a BackgroundWorker, and use CancelAsync method (you will then need to check regularly the CancellationPending property from within the thread function).
One other important advantage about using a BackgroundWorkers is you can re-use it as many times as you want.

2- You are accessing UI objects from the thread (Text property, Focus method, and so on). Don't do that. Have a look to the InvokeRequired property, Invoke and BeginInvoke methods from MSDN to know more about that.
Instead, send arguments to your thread function.

But the main question is: do you really need a thread to do what you want to do? Can't you do all that in the event handler?

Posted 8-Mar-11 0:25am

Olivier Levrey

Updated 8-Mar-11 0:29am

v3

Comments

[no name] 8-Mar-11 6:59am

As I said, it is send to a special validation that will include three characters (optional of course, it is a kind of coding system). What I want is when you have stopped typing the ProcessValidationAndMemory is called. I don't know how to do that without Threading.

1- sounds good, is worth a try.

2- I'm not sure that I can do that though I will use same method against 40 textboxes...

johannesnestler 8-Mar-11 7:31am

Very good answer Olivier Levrey!
@ mysoft: Use all the advices Olivier gave you. I can just repeat it. But the most important thing is, I don't think you need threads to do that. How expensive is a call to ProcessValidationAndMemory? Simple validation after input will maybe do. Have a look at your error handling too - You want 40 Threads to show MessageBoxes if something goes wrong? My advice: stop fiddling around with threading - rethink your design - and if you come to the conclusion threading is needed (long running validation, I can't believe it) - do it with BackgroundWorker and proper marshalling to the GUI thread (Invoke...) Good luck!

Olivier Levrey 8-Mar-11 7:34am

You can pass a parameter to your thread function, this parameter can be the text from the text box for example. If you need more arguments, then you can pass an array or a class with all necessary things.

Sergey Alexandrovich Kryukov 8-Mar-11 11:39am

Olivier, my 4 (not 5 because there is a problem of explanation of Abort).

You should have mentioned ThreadAbortException or better provide a sample. This this is not trivial. Also, I can list some important cases when Abort in unavoidable. The technology behind is very cunning and is based on exception seeding. This is not your old and dirty Terminate thread: through proper handling ThreadAbortException allowes to perform post-mortal clean up in the thread cleanly.

I would say not that it is not a clean way. I would prefer to say it requires expert understanding of threading to use it correctly (and when it is really unavoidable or beneficial). In particular, it should be calculated out what happens with inter-thread communication primitive and how other communicated threads shall behave in such orphaned situation.

I use it in many my applications, but those my applications are extremely exotic.

--SA

Olivier Levrey 8-Mar-11 11:54am

I "grew up" with the old WIN32 API, so you are right assuming I make no difference between TerminateThread and Abort. My mind is still stucked with "don't terminate a thread or a process from an external source. Always use a quit request and let it quit by itself". So I've never investigated deeper in using Abort...

Sergey Alexandrovich Kryukov 8-Mar-11 14:24pm

I've put an interesting (!!) comment on that but misplaced it. Please see -- below.
--SA

Sergey Alexandrovich Kryukov 8-Mar-11 14:23pm

It was a cunning technique invented by one Microsoft man. Seeding exception! Now to my joy it is available in .NET. It worked even on native (I had my own implementation). You pause the thread for a short time. Windows has an accessible record where the swapped CPU status is saved, perfectly documented but not compatible between different CPU architecture. Then you modify Instruction Pointer (saved IP register). As the thread is paused, it's completely safe. When you continue thread it will jump to the address pointed to that new IP value unconditionally. It will come there with messed-up stack. Not too worry... There is exactly on case when it does not matter. When? If course when the first statement will throw exception. Which one? ThreadAbortException, of course. So the stack will be unwound to where you registered "try" and handle this exception. That's why you crew up if you not handle exception in thread.
Very few people really know how it really works. How about that?
--SA

Olivier Levrey 9-Mar-11 3:27am

I didn't know either this mechanism. I had a look to ThreadAbortException examples and it is true it is not as dirty as I supposed. And I'd rather use that instead of exception seeding! Thanks for these interresting explanations ;)

Sergey Alexandrovich Kryukov 9-Mar-11 3:41am

You hardly can used low-level exception seeding with the managed. But, in case I was not clear: this is how Abort works in .NET. Exception seeding is done safely because .NET core is unmanaged library with hardware-specific implementation in each version, so hardware-dependent exception seeding is done once per hardware architecture and quite safe. On the managed platform it is compatible, because JITed native code works differently per each hardware architecture. Quite neat, isn't it?
--SA

Sergey Alexandrovich Kryukov 17-Apr-11 17:44pm

I come across another C++ Question where this approach can be useful.
So, I put this solution in some more detail: http://www.codeproject.com/Answers/182968/Close-correcly-the-thread-inside-a-dll.aspx
Take a look -- interesting; and there is enough information to implement it at once.
--SA

[no name] 11-Mar-11 12:20pm

Well, first I would like to thank you all for your comments, but here lies my problem and it can be solved in two different ways:

1, first i solve this problem as I tried with this approach by using threading. Unfortunately I haven't had enough time to try this with BackgroundWorker but it might work.

2, another way to solve this is create a script that listens if the user have stopped typing and runs ProcessValidationAndMemory afterwards. The timeout for listening should be around 2 seconds or so. The problem is that I don't know how to create such a script, therefore I tried with threading.

[no name] 16-Mar-11 9:19am

Problem solved, thank you.

Olivier Levrey 16-Mar-11 9:31am

You are welcome.