Search code examples
c#.netmultithreadingconcurrencyconcurrent-collections

Updating concurrent collection

I am working on a multi-thread application, where I load data from external feeds and store them in internal collections. These collections are updated once per X minutes, by loading all data from the external feeds again. There is no other adding/removing from these collection, just reading.

Normally I would use locking during the updating, same as everywhere I am accessing the collections.

Question:

Do the concurrent collections make my life easier in this case? Basically I see two approaches

  1. Load the data from external feed and then remove the items which are not present anymore, add the missing, and update the changed - I guess this is a good solution with help of concurrent collection (no locking required, right?), but it require too much code from my side.

  2. Simply override the old collection object with a new one (e.g. _data = new ConcurentBag(newData). Here I am quite sure that using the concurrent collections have no advantage at all, am I right? Locking mechanism is required.

Is there out of the box solution I can use, using the concurrent collections? I would not like to reinvent the wheel again.

Solution

  • Yes, for concurrent collections the locking mechanism is stored inside the collections, so if you new up a collection in place of the old one, that just defeats the purpose. They are mostly used in producer-consumer situations, usually in combination with a BlockingCollection<T>. If your producer does more than just add data, it makes things a bit more complicated.

    The benefit to not using concurrent collections is that your locking mechanism no longer depends on the collection - you can have a separate synchronization object that you lock on, and inside the critical section you're free to assign another instance like you wanted.

    To answer your question - I don't know of any out-of-the-box mechanism to do what you want, but I wouldn't call using a simple lock statement "reinventing the wheel". That's a bit like saying that using for loops is reinventing the wheel. Just have a separate synchronization object alongside your non-concurrent collection.