Thread communication
-
I have an update polling task on a thread that checks an internet server for updates. If an update is available it fires an event. It turns out that the event handler gets executed on the same thread as the task (sound logical). BUT I need the polling thread to die and the handler method to execute on the main thread. How can I do this? I had a similar problem with Threads and Winforms. Only the owner thread can interact with the control. The solution to that one was a simple Control.Invoke().
-
I have an update polling task on a thread that checks an internet server for updates. If an update is available it fires an event. It turns out that the event handler gets executed on the same thread as the task (sound logical). BUT I need the polling thread to die and the handler method to execute on the main thread. How can I do this? I had a similar problem with Threads and Winforms. Only the owner thread can interact with the control. The solution to that one was a simple Control.Invoke().
I had to do something similar to this but because I come from the Win32 C++ world I took an API approach so there may be a better C# way of doing this. Anyway, what I did was an override of the WndProc method on the main thread and used post message from the polling thread. As I recall I was under pressure for a fast workaround and did not have time to thoroughly research an optimal solution. I would be interested in what you come up with.
-
I had to do something similar to this but because I come from the Win32 C++ world I took an API approach so there may be a better C# way of doing this. Anyway, what I did was an override of the WndProc method on the main thread and used post message from the polling thread. As I recall I was under pressure for a fast workaround and did not have time to thoroughly research an optimal solution. I would be interested in what you come up with.
Hey!! :-D That is exactly the first thing that i came up with before I figured out how to do Thread<->Winforms properly. However this is a different problem - there is no WndProc to override. I decided to put the poller on a seperate thread because polling the server can really delay application startup. The application is running from an ApplicationContext. The Init method of the app context calls the Updater.Check() method, which attaches an event handler, kicks off the poller thread, and continues. When the event is fired the handler will execute on the same thread as the poller. This will not work for me because I have no idea how long the update will take. Btw, I have the downloader run on its own thread. Obviously, using the event will not work.
-
I have an update polling task on a thread that checks an internet server for updates. If an update is available it fires an event. It turns out that the event handler gets executed on the same thread as the task (sound logical). BUT I need the polling thread to die and the handler method to execute on the main thread. How can I do this? I had a similar problem with Threads and Winforms. Only the owner thread can interact with the control. The solution to that one was a simple Control.Invoke().
I had a similar problem. However, for me, I wanted to have a task get executed by a "main" background thread rather than in the GUI thread. It's the same problem as above, though. Essentially, I employed a Command Queue design pattern, which the "main" thread monitors in some fashion. Here's an interface:
interface ICommand { void Execute(); }Then I can write some classes that implement the ICommand interface. For your case, the polling thread can construct some relevant object (that has the ICommand interface). This object can then be enqueued in a queue that the main thread monitors. Be sure to use some sort of synchronization on the thread -- it might be as simple as using the Queue.Synchronized() wrapper. So, this queue could be a singleton object, which you might access via WorkQueue.Instance, or you could make it a private member of your MainThread class, and some public method of MainThread could be called from the polling thread, enqueuing the object. And you can use all sorts of techniques to look for any waiting commands in the queue... Anyway, that's what I basically do, and it's pretty flexible for me, even though all I do is use it for executing a "Stop" command. It seems like one of the best ways to get another thread to execute some code. -
I had a similar problem. However, for me, I wanted to have a task get executed by a "main" background thread rather than in the GUI thread. It's the same problem as above, though. Essentially, I employed a Command Queue design pattern, which the "main" thread monitors in some fashion. Here's an interface:
interface ICommand { void Execute(); }Then I can write some classes that implement the ICommand interface. For your case, the polling thread can construct some relevant object (that has the ICommand interface). This object can then be enqueued in a queue that the main thread monitors. Be sure to use some sort of synchronization on the thread -- it might be as simple as using the Queue.Synchronized() wrapper. So, this queue could be a singleton object, which you might access via WorkQueue.Instance, or you could make it a private member of your MainThread class, and some public method of MainThread could be called from the polling thread, enqueuing the object. And you can use all sorts of techniques to look for any waiting commands in the queue... Anyway, that's what I basically do, and it's pretty flexible for me, even though all I do is use it for executing a "Stop" command. It seems like one of the best ways to get another thread to execute some code.Sounds like a good idea but I'm wondering where you would monitor it from. In AK's situation I think he is looking for an event to occur but in your situation you probably have a worker thread that is looping - before it begins another iteration you check to see if it should stop. Since there is no “loop” for AK he would need an event… I do like your approach, though, for workers.
-
Sounds like a good idea but I'm wondering where you would monitor it from. In AK's situation I think he is looking for an event to occur but in your situation you probably have a worker thread that is looping - before it begins another iteration you check to see if it should stop. Since there is no “loop” for AK he would need an event… I do like your approach, though, for workers.
Well, it depends on the structure of AK's main thread. He doesn't need to loop, he could just use a combination of Monitor.Wait (in the main thread) and Monitor.Pulse (in the polling thread). But I don't think you can do the equivalent of Control.Invoke() on some arbitrary thread. You can't tell a thread to interrupt its current code, run some code, and then continue execution as before without the thread explicitly expecting it (such as looping around for it). Control.Invoke() is special -- I imagine it's basically implemented like your WndProc hacks. I imagine that Control.Invoke() calls are queued, and whenever WndProc finds a good time to invoke them, then they are finally executed. But if someone proves me wrong, that would invoke a powerful change in my understanding of threading. :)
-
Sounds like a good idea but I'm wondering where you would monitor it from. In AK's situation I think he is looking for an event to occur but in your situation you probably have a worker thread that is looping - before it begins another iteration you check to see if it should stop. Since there is no “loop” for AK he would need an event… I do like your approach, though, for workers.
-
Well, it depends on the structure of AK's main thread. He doesn't need to loop, he could just use a combination of Monitor.Wait (in the main thread) and Monitor.Pulse (in the polling thread). But I don't think you can do the equivalent of Control.Invoke() on some arbitrary thread. You can't tell a thread to interrupt its current code, run some code, and then continue execution as before without the thread explicitly expecting it (such as looping around for it). Control.Invoke() is special -- I imagine it's basically implemented like your WndProc hacks. I imagine that Control.Invoke() calls are queued, and whenever WndProc finds a good time to invoke them, then they are finally executed. But if someone proves me wrong, that would invoke a powerful change in my understanding of threading. :)
-
You're right, it depends on the structure of his main thread. My feeling is he would not want to block on the Monitor.Wait, though. AK, let us know what you find. You have Arun and me intrested. :)
This is very interesting. I've been searching for something that would work, and it the Monitor class sounds very promising. For now, I just decided to do a quick work around. Basicly the updater lets the poller run. Using a timer the updater checks every minute if an update was found. Still, this thread problem is really puzzling and I would like to figure it out.
-
This is very interesting. I've been searching for something that would work, and it the Monitor class sounds very promising. For now, I just decided to do a quick work around. Basicly the updater lets the poller run. Using a timer the updater checks every minute if an update was found. Still, this thread problem is really puzzling and I would like to figure it out.
I dunno, maybe SendMessage() is the way to go, if you can get a background thread to listen to the message pump...? I happen to like the route you went, though, but mainly because I come from UNIX (C/C++) and Java.