Question

I have a winform with a form called MainForm.
I have a static class called ObjMgr.
In ObjMg, I have several other static classes, values, but Its not important now.

In the ObjMgr class, I also have a static void Pulse() method, that I populate my other static classes in the ObjMgr. This pulse method have to run very often, like 0,033 secs.

On MainForm I placed a start button, that on click event, starts pulsing my ObjMgr on another thread.

Pulser = new System.Threading.Thread(new System.Threading.ThreadStart(ObjMgr.StartPulsing));
Pulser.IsBackground = true;
Pulser.Start();

My ObjMgr.StartPulsing method source:

        while(true)
        {
            ObjMgr.Pulse();
            System.Threading.Thread.Sleep(30);
        }

My Pulser method source :

        //here I update all my data in ObjMgr
        // Its need to be fast, I have some while, and switch statements here.
        // complicated code here :D The main thing is, its populating my classes with data.

Now I have my pulser running , and keeping my static class data fresh.
Its very nice. Next step, I would like to show some data on my form (UI), from the updated ObjMgr classes. On my form I have about ~20 labels, 2 ProgressBar values, I want to update often, like the Pulsator. (0,033sec)

It would be obvious to update my labels, from the Pulsator method it self, but Iam afraid it would slow down my Pulsator, and I dont want it. So, I need some tips, how to do this thing. I was thinking, and I implented timer, that I set the interval to 30, then on tick event I read my data from the ObjMgr, and show modify the labels. It working okey, but little buggy, because some synchron problems. If you understand my problem could you give me some feedback, or tips how to make this better?

IF I would try to update my labels from the Pulse() method itself, would It slow my Pulse() method? If not, how could I update 20 labels on MainForm, from another thread?

Answer 1

Considering the timing criteria of your situation I would avoid initiating the UI updates from the worker thread. The reason is two fold. First, it is likely to have some impact on the timing characteristics of thread. Second, you would have to use an expensive marshaling operation (via Control.Invoke) to transfer the UI updating operation onto the UI thread.

Your best bet in this situation is package all of the information needed to perform the UI update in a single class and then store it in a shared variable. Then have your UI thread poll this shared variable at an interval appropriate for you application.¹

This approach has several advantages.

• The UI and worker threads remain loosly coupled as opposed to the Control.Invoke or Control.BeginInvoke approach which tightly couples them.
• The UI thread will not impede the progress of the worker thread.
• The worker thread cannot dominate the time the UI thread spends updating.
• The intervals at which the UI and worker threads perform operations can remain independent.
• The worker thread cannot overrun the UI thread’s message pump.

¹_{Updating the UI as quickly as you propose does not sound like a good idea. The UI is meant for human interaction and as such no human will care or even notice that it updates that quickly.}