My question may not really be about realtime processing, but then again, it may be.
My application has several threads that are far more important than the GUI, BUT, I do want the GUI to at least be usable. I don’t want it locked at all times, and I do want to update the screen given results of processing I am performing.
Currently all my essential items are isolated in separate threads, and I call a delegate to my GUI to display results.
My GUI works, but if I change tabs, or minimize/maximize it, it has been known to hinder my other threads to the point where they can not perform their operations within the 0.1s time limit they are held to.
This is what I am doing to call my delegate:
delegate void FuncDelegate(ResultContainer Result);
FuncDelegate DelegatedDisplay= new FuncDelegate(DisplayResults);
//then later on
Invoke(DelegatedDisplay, Result);
Most of my critical processes are threads that run in continuous loops, pulling from and pushing to various buffers (ArrayLists and normal Lists).
One of my critical threads is launched every time, using:
Thread mythread = new Thread(new ThreadStart(ProcessResults));
mythread.Start();
The reason I thought to do this, instead of just having a thread running in a loop, pulling from lists, is that I thought perhaps the reason I was running out of clock time was that I have a polling loop that I worry consumes too many resources (although I am using Thread.Sleep(5) every time the poll turns up negative).
Does launching a new thread each time I need the concurrent process cost me valuable time? Should this be a loop? Are my loops to blame?
Can I give a thread higher priority than others, or is the use of Thread.Sleep my only option? If I do assign higher thread priorities, how can I be sure other threads can even survive?
Why are simple forms events hampering my other threads so much? Is there a way to give my GUI thread an assigned, lower amount of resources? Can I use a Thread.Sleep somehow to block Form events if the other threads are running out of clock time?
Short of an answer to all my frustrating questions, is there some kind of thread profiler I can be using to help figure my mess out? I tried using “Managed Stack Explorer” but somehow that doesn’t always show what threads my application has.
Any help on this matter would help me greatly.
Well here’s a start:
This means that you are causing the background thread to wait until the UI thread actually performs the drawing operation, then proceed. From the thread’s point of view that’s an eternity. You might want to investigate asynchronous updates to the UI:
That’s equivalent to telling the UI thread “when you have a chance, perform this drawing action”, then proceeding with the work that you were doing.
You should be aware that this may cause thread-safety issues that didn’t occur using
Invoke, though. For example, if the background thread is still modifyingResultwhile the UI is attempting to draw, you might have unexpected race conditions.See Control.Invoke vs Control.BeginInvoke