locked
Worker threads and Observable collections RRS feed

  • Question

  • Many of you will know that an ObservableCollection<T> has a big weakness - the collection cannot be modified by a worker or IOCP thread if any GUI items are bound to the collection.

    So if you want to create a Store app that renders data which is being accumulated asynchronously via worker or IOCP threads, you're in trouble (if you use ObservableCollection<T>).

    Now I've already solved this problem by creating a more sophisticated collection class, one that derives from ObservableCollection<T> but leverages the dispatcher object that makes it safe and updatable from any thread while still being able to bind GUI items to it - this class supports execution on Desktop, Store and Phone 8 too.

    So my question today is do I still need this with Windows 8.1, .Net 4.5.1 and Visual Studio 2013? Has this problem been solved by Microsoft in this latest release or must I still rely on my own collection class?

    If its been addressed then I'd prefer to leverage Microsoft's solution assuming it runs on all three platforms.

    Thanks

    Cap'n


    Monday, October 21, 2013 7:28 PM

Answers

  • This is expected behavior. GUI objects have thread affinity and need to be called on their dispatcher thread. If you need to manipulate them from another thread then you will need to use a dispatcher to marshal the call to the dispatcher thread. For general use you wouldn't want to marshal every call separately but would batch related calls when necessary. If that doesn't apply to your specific case then wrapping the calls in your custom object may be a good solution for that case.

    --Rob

    Tuesday, October 22, 2013 12:07 AM
    Moderator

All replies

  • This is expected behavior. GUI objects have thread affinity and need to be called on their dispatcher thread. If you need to manipulate them from another thread then you will need to use a dispatcher to marshal the call to the dispatcher thread. For general use you wouldn't want to marshal every call separately but would batch related calls when necessary. If that doesn't apply to your specific case then wrapping the calls in your custom object may be a good solution for that case.

    --Rob

    Tuesday, October 22, 2013 12:07 AM
    Moderator
  • This is expected behavior. GUI objects have thread affinity and need to be called on their dispatcher thread. If you need to manipulate them from another thread then you will need to use a dispatcher to marshal the call to the dispatcher thread. For general use you wouldn't want to marshal every call separately but would batch related calls when necessary. If that doesn't apply to your specific case then wrapping the calls in your custom object may be a good solution for that case.

    --Rob

    Right so no such enhanced collection class has been added recently and I should therefore continue to use my dispatcher aware observable collection.

    Given the desire to loosely couple the View from the ViewModel in the MVVM pattern this strict dependency on a dispatcher kind of breaks this because the ViewModel collections must refer to the dispatcher which belongs wholly in the View domain.

    Here is an article about this, and I think its a rather glaring omission that Microsoft still don't provide such a collection class out of the box, after all in the general case data in the Model will change asynchronously in any real world application where we have networks, push notifications, timers etc.

    http://michlg.wordpress.com/2009/08/14/dispatchingobservablecollection-thread-save-observablecollection/

    As currently packaged the MVVM pattern heavily pushed by Microsoft for WinRT and WinPRT is difficult to implement in the general case unless one implements dispatcher aware observable collections so why don't Microsoft just provide such a class?

    This problem arose within hours of me experimenting with UPnP (because UPnP "events" manifest as asynchronously received HTTP messages) and I had to spend ages digging into dispatchers and their different semantics on different platforms - all I wanted was to have my GUI update as and when UPnP devices on the network change state but what should have been almost trivial became a sub-project greatly distracting from my actual goal of just creating an MVVM app.

    If Microsoft want lots of developers to write lots of apps then they should eliminate this elephant in the room.

    Cap'n


    Tuesday, October 22, 2013 3:38 AM