从后台线程更新UI

Question

I have a background task that sits in a loop reading data from an external hardware device. The device exposes a "counter" that increments every 100ms - when this value changes I fetch the next data value from the device and raise an event. Psuedo-code:-

public event HasDataEventArgs DataReceived;

while (some condition)
{
    // Wait for device counter to increment
    while (DeviceCounterValue == _lastDeviceCounterValue)
    {
       Thread.Sleep(3);
    }
    _lastDeviceCounterValue = DeviceCounterValue;

    // Read data value from device
    var data = GetDataFromDevice();

    // Raise my event
    DataReceived(this, new HasDataEventArgs(data)); 
}

I also have a UI view that subscribes to this event. The event handler plots the data value on a chart and sets a number of bound properties.

Most of the time this all works fine, but if I (say) drag a window around or open a modal dialog, it can occasionally result in data being missed. What seems to happen is that the external device counter carries on incrementing, but the 'while' loop has effectively stalled briefly, so misses those changes. Very occasionally I'll see the same effect even when I'm not messing around with anything in the UI.

The event handler in the view isn't doing much, but this is a complex desktop application with other background threads updating other bound controls. Perhaps this particular process is just tipping things over the edge performance-wise, especially once I start dragging windows around?

I was wondering if I could wrap the event handler code in a Task.Run() , which (I assume) would result in it returning control to the while loop immediately, rather than have to wait for the event handler to do its thing. It sounds hacky though - am I asking for trouble with something like this, especially given the frequency that the event handler will be called (every 100ms)?

Answer 1

You left out some details, mainly what the eventhandler does to get on the GUI thread. Invoke or BeginInvoke etc.

But there is another option, if safeguarding your data matters most: push the new data into a ConcurrentQueue. Raising a Received event is then OK but optional, you probably won't need it.

The Main thread can empty the queue in its own time. For example with a Timer.

Your screen updates will still stutter but you shouldn't lose data anymore.

Answer 2

You have to split (thread-wise) two things: the background work and the plotting work. This is, in general, the way how to do such things, but to be concrete - if your plotting requires time, then there are chances that your working thread is not able to handle the incoming data on time and you can get some data lost/omitted (that's what you're actually observing).

Here's one way how to do it (the method must be a member of a UI class - Window, user control, etc.):

void OnDataReceived(object sender, DataEventArgs e)
{
    // here we're in the context of the working thread

    // this call will return immediately giving control back to the working thread
    Dispatcher.BeginInvoke(
        DispatcherPriority.Normal,
        (Action)delegate
        {
            // here we are in the context of the UI thread
        });
}