Question

I’ve developed a data adquisition subsystem as a DLL that captures data using its own thread and published the data using ObservableCollections. I’m facing several problems because the consumers of the events do expensive operations when they receive the ObservableCollection events and that’s making my engine to capture data slower than expected.

I plan to send the events in different threads to avoid this problems but I have several concerns:

public class ObservableCollection2
{
    public void Add()
    {
        _internalObservableCollection.Add();
        new Thread() { => Raise the event }
    }
}

1. Is this an already solved problem with a standard solution? Looks
   like thread contention should be something relatively common.
2. Using Threads wouldn’t reduce badly the performance of the
   application?
3. Using ThreadPool wouldn’t use all the available
   Thread as it’s normal in the subsystem to send from 100 to 200
   notifications per second?

Thanks for your thoughts.

Answer 1

There are several ideas about what can be done is this situation.

1. The clients must not execute heavy code in an event handler — after all, they know that they are blocking the processing. So the clients must just remember that the collection has been changed, and unload the processing into the private thread.
2. Using a new thread for each event is not the best solution. If you go for that anyway, perhaps a thread-pool thread is a better idea.
3. If the messages about the changes are coming so often, perhaps you’d like to throttle the notifications, and send them in bigger packs? I don’t know out-of-the-box solution for that, but maybe Rx extensions can be helpful.
4. ObservableCollection is quite a heavy class. I personally use it only in view models for binding from view, and in the model I resort to a self-made class containing a collection internally, and sending the needed events when needed. This way I have more control over what happens.