Greetings,
I currently have a multithreaded VB.net application that talks to an embedded controller over an ethernet connection. I have a Tx thread, an Rx thread, a packet receiving thread and a packet creation thread - and of course a main loop thread.
Everything works really well and my processor usage is ~1% while running. The main thread signals the packet creation thread to make a packet, which gets picked up by the Tx thread and sent. Then the Rx thread receives a reply, and it is looked at by the packet receiving thread and sent back to the main loop.
My threads are thread safe as per the MSDN recommended way of making them thread safe. Also, all my threads Sleep(New Timespan(10000)) ' 10ms sleep while looping to ensure they don't hog the CPU.
Now onto my problem.....
Enabling my packet timeout handlers will crash my program if my processor gets bogged down. Unfortunately that is VERY easy to do - dragging a window over the form raises CPU usage to 60% or more!
My packet timeout handlers are just counters that start inside the Rx handler. Periodically the main loop looks at the timer, and if it has expired it throws an error. Well, what happens is I might send the packet, start the timer - then my threads stop getting serviced because the OS is busy.
So in essence, my program's timeout counters expire, even though I might very well have received the packets and they've just not been handled yet.
How do people manage such situations in everyday programs? Do you need to detect when your threads are bogging down, and compensate the timeouts somehow? I know I can't force my threads to run, hell raising them to the highest priority can occasionally lockup my system :/
Furthermore, why in the heck does moving the form window use so much processing power? I do next to nothing in the background threads. Everything in my program is called from a thread I've created, or handled by a delegate subroutine (for cross-thread calls).
Thank you in advance for any help you can provide me with. This software will eventually become a test program for some embedded hardware, and I just can't have it giving false packet timeouts the second a technician opens excel or drags the form around
I currently have a multithreaded VB.net application that talks to an embedded controller over an ethernet connection. I have a Tx thread, an Rx thread, a packet receiving thread and a packet creation thread - and of course a main loop thread.
Everything works really well and my processor usage is ~1% while running. The main thread signals the packet creation thread to make a packet, which gets picked up by the Tx thread and sent. Then the Rx thread receives a reply, and it is looked at by the packet receiving thread and sent back to the main loop.
My threads are thread safe as per the MSDN recommended way of making them thread safe. Also, all my threads Sleep(New Timespan(10000)) ' 10ms sleep while looping to ensure they don't hog the CPU.
Now onto my problem.....
Enabling my packet timeout handlers will crash my program if my processor gets bogged down. Unfortunately that is VERY easy to do - dragging a window over the form raises CPU usage to 60% or more!
My packet timeout handlers are just counters that start inside the Rx handler. Periodically the main loop looks at the timer, and if it has expired it throws an error. Well, what happens is I might send the packet, start the timer - then my threads stop getting serviced because the OS is busy.
So in essence, my program's timeout counters expire, even though I might very well have received the packets and they've just not been handled yet.
How do people manage such situations in everyday programs? Do you need to detect when your threads are bogging down, and compensate the timeouts somehow? I know I can't force my threads to run, hell raising them to the highest priority can occasionally lockup my system :/
Furthermore, why in the heck does moving the form window use so much processing power? I do next to nothing in the background threads. Everything in my program is called from a thread I've created, or handled by a delegate subroutine (for cross-thread calls).
Thank you in advance for any help you can provide me with. This software will eventually become a test program for some embedded hardware, and I just can't have it giving false packet timeouts the second a technician opens excel or drags the form around
