I was learning about threads in C#. When I was writing some code, I learned to pause a thread, I should call the Thread.Sleep() function. It will pause the thread for the time I passed as parameter.
But to abort or start the thread, I need to use
Thread.CurrentThread.Abort()
Thread.CurrentThread.Start()
CurrentThread is also a Thread. So, I was expecting something like this
Thread.Sleep()
Thread.Start()
Thread.Abort()
or
Thread.CurrentThread.Abort()
Thread.CurrentThread.Start()
Thread.CurrentThread.Sleep()
Why is it different? What is the principle behind this?
I am not sure if it is a valid question or not. If It seems an invalid question to you please let me know, I will remove this question.
Abort() and Start() are instance methods of class Thread. You use them to interact with an existing Thread instance from the outside e.g. main thread.
Sleep() is a static method. You call it from within the running thread's context to cause it to pause.
Related
How InvokeRequired and Invoke let us make our apps thread safe.
Let's consider such code:
private void ThreadSafeUpdate(string message)
{
if (this.textBoxSome.InvokeRequired)
{
SetTextCallback d = new SetTextCallback(msg);
this.Invoke
(d, new object[] { message });
}
else
{
// It's on the same thread, no need for Invoke
this.textBoxSome.Text = message;
}
}
Is it possible to change state of InvokeRequired after InvokeRequired and before Invoke? If not, then why?
How does Invoking make it thread safe?
If InvokeRequired illustrate is current thread owning control, how would the thread know that it is or it is not the owner.
Let's consider that SomeMethod() is currently running on Thread1. We would like to call it from Thread2. Internally this method updates some field. Does Method.Invoke contain some kind of lock mechanism internally?
What if SomeMethod() takes very long time and we would like to run something other on the control owner thread. Does Invoking lock the owner thread or is it some kind of a background thread safe task?
ThreadSafeUpdate() //takes 5 minutes in Thread2
ThreadSafeUpdate() //after 2 minutes, we are running it in other thread2
ThreadSafeUpdate() //next run from Thread3
I think it is some kind of general pattern which can be implemented outside of winforms, what's its name?
Is it possible to change state of InvokeRequired
Yes, and it is a pretty common occurrence. Either because you started the thread too soon, before the form's Load event fired. Or because the user closed the window just as this code is running. In both cases this code fails with an exception. InvokeRequired fails when the thread races ahead of the window creation, the invoked code fails when the UI thread races ahead of the thread. The odds for an exception are low, too low to ever diagnose the bug when you test the code.
How Invoking make it thread safe?
You cannot make it safe with this code, it is a fundamental race. It must be made safe by interlocking the closing of the window with the thread execution. You must make sure that the thread stopped before allowing the window to close. The subject of this answer.
how would he know that he is or he is not owner.
This is something that can be discovered with a winapi call, GetWindowsThreadProcessId(). The Handle property is the fundamental oracle for that. Pretty decent test, but with the obvious flaw that it cannot work when the Handle is no longer valid. Using an oracle in general is unwise, you should always know when code runs on a worker thread. Such code is very fundamentally different from code that runs on the UI thread. It is slow code.
We would like to call it from Thread2
This is not in general possible. Marshaling a call from one thread to a specific other thread requires that other thread to co-operate. It must solve the producer-consumer problem. Take a look at the link, the fundamental solution to that problem is a dispatcher loop. You probably recognize it, that's how the UI thread of a program operates. Which must solve this problem, it gets notifications from arbitrary other threads and UI is never thread-safe. But worker threads in general don't try to solve this problem themselves, unless you write it explicitly, you need a thread-safe Queue and a loop that empties it.
What's if SomeMethod() takes very long time
Not sure I follow, the point of using threads is to let code that takes a long time not do anything to harm the responsiveness of the user interface.
I think it is some kind of general pattern
There is, it doesn't look like this. This kind of code tends to be written when you have an oh-shoot moment and discover that your UI is freezing. Bolting threading on top of code that was never designed to support threading is forever a bad idea. You'll overlook too many nasty little details. Very important to minimize the number of times the worker thread interacts with the UI thread, your code is doing the opposite. Fall in the pit of success with the BackgroundWorker class, its RunWorkerCompleted event gives a good synchronized way to update UI with the result of the background operation. And if you like Tasks then the TaskScheduler.FromCurrentSynchronizationContext() method helps you localize the interactions.
Usually, no. But it could happen if you're using await between the InvokeRequired check and Invoke call without capturing the execution context. Of course, if you're already using await, you're probably not going to be using Invoke and InvokeRequired.
EDIT: I just noticed that InvokeRequired will return false when the control handle hasn't been created yet. It shouldn't make much of a difference, because your call will fail anyway when the control hasn't quite been created yet, but it is something to keep in mind.
It doesn't make it thread-safe. It just adds the request to the control's queue, so that it's executed the next available time on the same thread the control was created on. This has more to do with windows architecture than with general thread-safety. The end result, however, is that the code runs on a single thread - of course, this still means you need to handle shared state synchronization manually, if any.
Well, it's complicated. But in the end, it boils down to comparing the thread ID of the thread that created the control, and the current thread ID. Internally, this calls the native method GetWindowThreadProcessId - the operating system keeps track of the controls (and more importantly, their message loops).
Invoke cannot return until the GUI thread returns to its message loop. Invoke itself only posts the command to the queue and waits for it to be processed. But the command is run on the GUI thread, not the Invoke-caller. So the SomeMethod calls in your example will be serialized, and the Invoke call itself will wait until the second call finishes.
This should already be answered. The key point is "only run GUI code on the GUI thread". That's how you get reliable and responsive GUI at all times.
You can use it anywhere you've got a loop or a wait on some queue. It probably isn't all that useful, although I have actually used it already a few times (mostly in legacy code).
However, all of this is just a simple explanation of the workings. The truth is, you shouldn't really need InvokeRequired... well, ever. It's an artifact of a different age. This is really mostly about juggling threads with little order, which isn't exactly a good practice. The uses I've seen are either lazy coding, or hotfixes for legacy code - using this in new code is silly. The argument for using InvokeRequired is usually like "it allows us to handle this business logic safely whether it runs in the GUI thread or not". Hopefully, you can see the problem with that logic :)
Also, it's not free thread-safety. It does introduce delays (especially when the GUI thread is also doing some work that isn't GUI - very likely in code that uses InvokeRequired in the first place). It does not protect you from accesses to the shared state from other threads. It can introduce deadlocks. And don't even get me started on doing anything with code that uses Application.DoEvents.
And of course, it's even less useful once you take await into consideration - writing asynchronous code is vastly easier, and it allows you to make sure the GUI code always runs in the GUI context, and the rest can run wherever you want (if it uses a thread at all).
I am writing a library, and would like to be able to fire a callback on a specified thread, so the end-user does not have to worry about thread-safety.
I tried using ExecutionContext, but that didn't work out too well, it would fire in the specified context (a new thread), but not on the thread that originally called the function.
The code should work like this:
void Connect() {
// This should be in the same thread ..
SocketAsyncEventArgs.Completed += eventHandler;
Socket.ConnectAsync(SocketAsyncEventArgs)
}
void eventHandler() {
// .. as this
}
You can't just run your code on some existing thread. That thread is already executing other code. But, it can provide you some way to run your code on it. The main thread in a WPF application does this using Dispatcher.Invoke(). The main thread of a WinForms application uses Control.Invoke().
There is a more general way to do this: use Synchronization.Context.Current. This would work for the main thread of WPF or WinForms application, but would execute the callback on a thread pool thread otherwise. (Unless there is some sort of custom synchronization context, which I think is very rare.)
But this is the best you can do. Like I said, you can't run your code on some other thread when you want. The code in that other thread has to allow you to do that.
That's the thing about asynchronous functions -- you can't guarantee when you'll get called back, or what thread will be running your callback function. Consider that the cost of being able to "set it and forget it".
There's usually no need for that much control anyway. If you "need" to have a specific thread run your callback, what you really need is to review why that's necessary. If it's something that needs to run on the UI thread, there's Control.Invoke. (The UI thread anticipates needing to be handed stuff to do, because of how the architecture works, so controls have a way to pass callbacks to run on that thread. You can't just up and do that with arbitrary threads -- they have to be expecting to be passed a callback like that.) Otherwise, if you have an issue with locks or something, chances are you're trying to use asynchronous functionality to do stuff that should really be done synchronously in a separate thread.
I'm making several HttpWebRequest.BeginGetResponse calls, and in the callback method of the BeginGetResponse, I'm invoking an EventHandler. In the EventHandler, there is logic to test if the download was successful. If not, it tries to redownload the Html. I'm noticing lots of threads being generated especially when there are errors. So, on which thread do the Async Callbacks run?
Is there anyway I can invoke the EventHandler on the original thread? If that is not posible, can I invoke it on the UI thread?
Thanks!
Callbacks are made on a threadpool thread. There is no mechanism in .NET to make code run on a specific thread. That is very hard to come by, you can't just interrupt a thread while it is busy and make it run some code. That causes horrible re-entrancy problems that a lock cannot solve.
A thread must be in an idle state, not actively mutating the state of the program. There's one kind of thread that behaves that way, the UI thread in a Winforms or WPF app. That's also the thread that has to deal with objects that are fundamentally thread-unsafe, anything related to the UI. This is not a coincidence.
Both class libraries make it possible to marshal a call from a worker thread to the UI thread, specifically to help getting the UI updated in a thread-safe way. In Winforms you use Control.Begin/Invoke(), in WPF you use Dispatcher.Begin/Invoke(). BackgroundWorker is a handy class to get this done without explicitly managing the marshaling. But isn't suitable for I/O completion callbacks.
What do you mean by "on the original thread"? Which original thread? You can marshal to the UI thread using Control.BeginInvoke or Dispatcher.BeginInvoke. You can't marshal to an arbitrary thread - it has to have something like a message pump waiting for work.
As for which thread HttpWebRequest async callbacks are executed on - I would expect either a general thread pool worker thread, or possibly an IO completion port thread.
Using the Begin/End Async pattern, be aware that it's possible for many kinds of tasks to complete on the thread they were called from. When you call BeginXXX, it returns a boolean that signifies if the task was completed on the calling thread or not.
The basic answer is, it could be any thread.
If you are using WPF you can use the Dispatcher to invoke your logic on the UI thread.
Otherwise, (if not in WPF) you could use a SyncrhronizationContext to accomplish the same thing.
I'm creating a new thread and within the background thread method I do work and then call another method to do work.
myThread = new Thread(new ThreadStart(doWork));
myThread.Start();
The problem is that when I leave the background worker method to go to another method and execute this :
browser.SelectList(Find.ById("selStartYear")).SelectByValue(startYear);
I get an InvalidCastException.
When my background worker method is finished do I need to do something with the thread? I see that I started the thread, but calling abort on it in the new method it calls just suspends the program.
Edit: I'm using WakiN and created new IE in the global scope:
IE browser = new IE("http://www.website.com/");
My worker method references this as does the failing method.
No, you do not need to do any cleanup on a thread that has finished executing. You should actually strive never to call Abort, as that's a destructive method and providing a more "polite" means of signaling the thread that it should exit immediately is preferred to ending it violently with Abort.
Also, if your job is not particularly long-running, then you should probably be using either the new Task class available in System.Threading.Tasks or using System.Threading.ThreadPool.QueueUserWorkItem() instead of spinning up your own thread.
That being said, you aren't providing enough information to answer your InvalidCastException issue. What is the cast it's trying? What is the relation (if any) between the body of doWork and the values being used in your failing statement?
Adam provided a complete answer on threading issue. I just another hint. Your thread (as I see in sample code) is not a background thread. Also I think all multi-thread applications needs a plan for a graceful exit (consider a system shutdown).
To find out what's the source of casting error, I suggest breaking that line of code into 3 lines, since one of the parameters is not in the right type.
What does that method do exactly? I was thinking that it maybe went out into a separate thread, but handled things like control updating on the correct thread. But now I am starting to think that it maybe just runs on the UI thread. Which means that calling BeginInvoke on a control from the UI is pretty much the same as calling Invoke? Or?
It basically adds the delegate to a queue of "tasks to execute". The UI thread runs those tasks in order.
The difference between Control.Invoke and Control.BeginInvoke is basically that Control.Invoke block the worker thread until the task has executed on the UI thread, whereas BeginInvoke doesn't. I'm not sure offhand whether there's any difference between BeginInvoke and Invoke when you call it from the UI thread.
I'm not 100% sure I get that last sentence.
It contains "from the UI...", does that mean "you call BeginInvoke from the same thread the UI is living on?" or "on a control from the UI", that is, a control which is part of the UI?
Anyway, both methods ends up running the delegate in question on the same thread the UI lives on. The difference is of course that Invoke blocks, and BeginInvoke doesn't. The blocking relates to the thread that does the calling.
Control.BeginInvoke is generally used to update the UI/Control on the thread that created the UI. UI elements have a design constraint that they can only be updated from the creating thread.
Hence to update the UI from a different (worker / threadpool) thread, you have to switch to the right thread. Control.BeginInvoke does that for you - asynchronously (in that you dont block till the delegate is executed). Invoke does the same thing except that you block till the delegate has been executed.
1st google result - WinForms UI Thread Invokes: An In-Depth Review of Invoke/BeginInvoke/InvokeRequred
Note that if you use Control.BeginInvoke to invoke a delegate that returns something, you can then use Control.EndInvoke to access the returned value. If the delegate hasn't executed yet, EndInvoke will block until it has returned.