This customer wanted to increase the performance of their code and the best way to accomplish this is to have multiple threads processing their own data independently of each other. But, again, the class library code base would produce errant results if we did this. To demonstrate the problem, imagine this very simple static class which is indicative of the non-thread safe class library that I'm referring to:
internal static class NonConcurrentAlgorithm
{
private static List<String> s_items = new List<String>();}
public static void Add(String item) { s_items.Add(item); }
public static String[] GetItems() { return s_items.ToArray(); }
If we have two threads using this class simultaneously, the results are unpredictable. For example, let's say we have this code:
ThreadPool.QueueUserWorkItem(o => NonConcurrentAlgorithm.Add("Item 1"), null);
NonConcurrentAlgorithm.Add("Item 2");
Thread.Sleep(1000); // To demonstrate the problem consistently
foreach (var i in NonConcurrentAlgorithm.GetItems())
Console.WriteLine(i);
When this code runs, the console could show:
"Item 2" by itself
"Item 2" followed by "Item 1"
"Item 1" followed by "Item 2"
Clearly, this is not desireable and the problem all stems from the threads sharing the one List<String> object. In fact, the List<T> class is not itself thread-safe and so it is even possible that having multiple threads accessing it simultaneously could result in items disappearing or a single item being inserted multiple times, or worse. It depends on how the List<T> class is internally implemented which is not documented and is subject to change.
Read more: JEFFREY RICHTER'S BLOG