Asynchronous Multi-threaded ObservableCollection

• Download CollectionMt_updated_2014-04-28.zip - 25.4 KB

Update 2014-04-18

• Updated with .net Framework 4.5 (Now required)
• Support some functionnalities to manage the collection as a recorder of changes (added/removed items): IsRecording, GetCopyOfRecordedItemsNew, GetCopyOfRecordedItemsRemoved
• Support the new .net 4.5 interface: IReadOnlyList
• Support usage of the collection as a stack with: Push and TryPop
• Support usage of the collection as a queue with: Enqueue and TryDequeue (not optimized for queue but works)
• Fixed some minors bugs

Update 2013-01-18 / Important note before usage...

My original implementation had some bugs that could happen in rare circumstances. But it could happen. In fact a real MT ObservableCollection (ObsCollMt) is impossible to my opinion due to this two interdependent points:

- To benefits of MT, you should not wait for any event handlers
- Not waiting for event handlers would compromise the expected behavior --> for example, a ui control implementation (grid) that would receive an event "ItemAdd" would expect the collection to be the same as it was before the event with and only the newly added item, which is not the case in MT.

Because of this. If hi performance is the target and you could live with two constraints : UI view of the obs coll could be readonly and duplicate of item is acceptable (I maintain a list and an observable collection at the ~ same time)... I would highly recommend the usage of: "CollectionMtWithAsyncObservableCollectionReadOnlyCopy" which I made it available here. Some explanation of the usage is available at the beginning of the class definition. I personnally use it at many places with no problem. I changed every usage of ObservableCollectionMt to CollectionMtWithAsyncObservableCollectionReadOnlyCopy. There is impacts but they are low. But don't forget to bind to the ObsColl property instead of binding directly to the instance.

The way CollectionMtWithAsyncObservableCollectionReadOnlyCopy works is modifying an internal list but synchronously add task to the queue of the dispatcher to duplicate the same action (add/remove) on the internal ObsColl. ObsColl will be updated whenever the dispatcher will reach the task. Both collection should be in sync when the dispatcher queue has processed every tasks (verified).

Introduction

ObservableCollections are mainly used in WPF to notify bound UI components of any changes. Those notifications usually translate to UI component updates, normally due to binding. UI component changes could only occur in a UI thread. Whenever you have lengthy work to do, you should do those jobs on a worker thread to improve the responsiveness of the UI. But sometimes, UI updates are very lengthy too. In order to decouple the worker thread from the UI thread, I created a collection which has in its internal 2 collections:

• A list which could be accessed in a multithreaded context. Major properties/functions of a regular collection are supported. Major properties/functions are the same as a regular collection. Some functions that could potentially be thread unsafe are clearly indicated (start with 'Unsafe').
• An ObservableCollection which should be used as read only from the UI. This collection is accessible through the ObsColl property. This ObsColl should be threaded as readonly otherwise it could lead to inconsitent data between both the list and the ObsColl.

Every modifications done to the ObsCollMt are done to the first internal list but are also queued to the dispatcher in the exact same order as they happen in the MT context (lock ensures this). The ObsColl should be an exact copy of the first internal list after UI would have processed all of its messages. But accessing the ObsCollMt would not suffer of waiting UI updates because of usage of Dispatcher.BeginInvoke.

Background

I found a few things but never exactly what I wanted. This is why I’m writing this article now. I took a look at: http://www.codeproject.com/KB/dotnet/MTObservableCollection.aspx (Paul Ortiz solution). And also http://powercollections.codeplex.com/. They weren’t what I expected. I also had some concerns about the first link (explained later).

Details

I decided to write my own multi-threaded ObservableCollection, but I got an unexpected major problem:

• The major one was discovered after few attempts of making an ObservableCollection MT without dual copy of the data. I think, as explained at the beginning, to decouple UI from MT worker thread and keep data coherent, we should have dual list of the data, one for workers and one for UI. Also, the copy used for the UI should not be modify of if so, then is should be not used by any workers.

* An asynchronous update means, as a difference from the Paul Ortiz solution, that the worker thread does not have to wait on the UI to update before continuing to process other things. My solution uses Dispatcher.BeginInvoke instead of Disptacher.Invoke.

I also had a few other problems in testing when I realised that CollectionView had one major constraint and a bug. CollectionView does not support range modification. CollectionView also has a bug in it because it does not use a “using” block around an iterator to ensure that Dispose is called (or use a foreach loop which is fine too). (See: https://connect.microsoft.com/VisualStudio/feedback/details/513500/collectionview-does-not-dispose-sourcecollection-enumerator-synchronously for those who have access.)

This is a list of many problems I had with the actual implementation of the ObservableCollection:

1. Function Clear does not notify
2. Unable to override critical functions
3. No multi-threaded safe access
4. Needs possibility to get blocking and unblocking iterators
5. Possibility to get either “blocking” or “list copy” iterator

Solution

I then decided to program my Swiss army knife collection. In fact, it is one collection for the multi-threaded, and a regular ObservableCollection. When accessing the ObsCollMt, you modify a regular list (with MT safe lock) and add notification to update the regular ObsColl in the UI thread.

The way I did it was a complete writing of the new class “ CollectionMtWithAsyncObservableReadOnlyCopy” not inheriting from Collection, with a “List<T>” member containing every item. The class supports most interface the standard ObservableCollection supports.

I have included a sample with threading access to show the main usage.

Do not forget to bind to "ObsColl" property instead of bind directly to the collection itself.

Hope you will like it.

History

• April, 28, 2014, Made some corrections in text.
• June, 03, 2013, Made a requested correction about verification of "Application.Current" not being null. Removed old source code which is a little bugged to remove confusion and to ensure to only use the new version with copy.
• Mai, 31, 2013, Put code in a little lib, added a little test project, make project for VS2010 instead of VS 2012 (easier for more people to try)
• Jan 18, 2013: Added information about "CollectionMtWithAsyncObservableCollectionReadOnlyCopy"
• Apr 28, 2011: Updated source code. Updated the Introduction section.
• Jun 23, 2011: Updated source code.