List threading issue

Question

I'm trying to make my application thread safe. I hold my hands up and admit I'm new to threading so not sure what way to proceed.

To give a simplified version, my application contains a list.

• Most of the application accesses this list and doesn't change it but may enumerate through it. All this happens on the UI thread.
• Thread one will periodically look for items to be Added and Removed from the list.
• Thread two will enumerate the list and update the items with extra information. This has to run at the same time as thread one as can take anything from seconds to hours.

The first question is does anyone have a recommend stragy for this.

Secondly I was trying to make seperate copies of the list that the main application will use, periodically getting a new copy when something is updated/added or removed, but this doesn't seem to be working.

I have my list and a copy......

public class MDGlobalObjects
{
    public List<T> mainList= new List<T>();
    public List<T> copyList
    {
        get
        {
            return new List<T>(mainList);
        }
    }
}

If I get copyList, modify it, save mainlist, restart my application, load mainlist and look again at copylist then the changes are present. I presume I've done something wrong as copylist seems to still refer to mainlist.

I'm not sure if it makes a difference but everything is accessed through a static instance of the class.

public static MDGlobalObjects CacheObjects = new MDGlobalObjects();

Answer 1

actly copylist is just a shallow copy of the mainList. the list is new but the refrences of the objects contained in the list are still the same. to achieve what you are trying to you have to make a deep copy of the list something like this

public static IEnumerable<T> Clone<T>(this IEnumerable<T> collection) where T : ICloneable
{
    return collection.Select(item => (T)item.Clone());
}

and use it like

return mainList.Clone();

Answer 2

looking at your ques again.. i would like to suggest an overall change of approach. you should use ConcurrentDictionary() as you are using .Net 4.0. in that you wont hav eto use locks as a concurrent collection always maintains a valid state.
so your code will look something like this.

Thread 1s code --- <br>
var object = download_the_object();
dic.TryAdd("SomeUniqueKeyOfTheObject",object);
//try add will return false so implement some sort of retry mechanism

Thread 2s code
foreach(var item in Dictionary)
{
 var object item.Value;
var extraInfo = downloadExtraInfoforObject(object);
//update object by using Update
dictionary.TryUpdate(object.uniqueKey,"somenewobjectWithExtraInfoAdded",object);
}

Answer 3

This is the gist using a ConcurrentDictionary:

---

public class Element
{
    public string Key { get; set; }
    public string Property { get; set; }

    public Element CreateCopy()
    {
        return new Element
        {
            Key = this.Key,
            Property = this.Property,
        };
    }
}

---

var d = new ConcurrentDictionary<string, Element>();

// thread 1
// prune
foreach ( var kv in d )
{
    if ( kv.Value.Property == "ToBeRemoved" )
    {
        Element dummy = null;
        d.TryRemove( kv.Key, out dummy );
    }
}

// thread 1
// add
Element toBeAdded = new Element();
// set basic properties here
d.TryAdd( toBeAdded.Key, toBeAdded );

// thread 2
// populate element
Element unPopulated = null;
if ( d.TryGetValue( "ToBePopulated", out unPopulated ) )
{
    Element nowPopulated = unPopulated.CreateCopy();

    nowPopulated.Property = "Populated";

    // either
    d.TryUpdate( unPopulated.Key, nowPopulated, unPopulated );

    // or
    d.AddOrUpdate( unPopulated.Key, nowPopulated, ( key, value ) => nowPopulated );
}

// read threads
// enumerate
foreach ( Element element in d.Values )
{
    // do something with each element
}

// read threads
// try to get specific element
Element specific = null;
if ( d.TryGetValue( "SpecificKey", out specific ) )
{
    // do something with specific element
}

---

In thread 2, if you can set properties so that the whole object is consistent after each atomic write, then you can skip making a copy and just populate the properties with the object in place in the collection.

There are a few race conditions in this code, but they should be benign in that readers always have a consistent view of the collection.