Why is C# List<> not thread-safe?

Question

from this site:

http://crfdesign.net/programming/top-10-differences-between-java-and-c

Unfortunately, List<> is not thread-safe (C#’s ArrayList and Java’s Vector are thread-safe). C# also has a Hashtable; the generic version is:

what makes List<> not thread-safe? is it implementation problem on .net framework engineer's part? or are generics not thread-safe?

Answer 1

Why would it be thread-safe? Not every class is. In fact, by default, classes are not thread-safe.

Being thread-safe would mean that any operation modifying the list would need to be interlocked against simultaneous access. This would be necessary even for those lists that will only ever be used by a single thread. That would be very inefficient.

Answer 2

You really need to classify Java's Vector's type of thread safety. Javas Vector is safe to be used from multiple threads because it uses synchronization on the methods. State will not be corrupted.

However, Java's vector's usefulness is limited from multiple threads without additional synchronization. For example, consider the simple act of reading an element from a vector

Vector vector = getVector();
if ( vector.size() > 0 ) { 
  object first = vector.get(0);
}

This method will not corrupt the state of the vector, but it also is not correct. There is nothing stopping another thread from mutating the vector in between the if statement an the get() call. This code can and will eventually fail because of a race condition.

This type of synchronization is only useful in a handfull of scenarios and it is certainly not cheap. You pay a noticable price for synchronization even if you don't use multiple threads.

.Net chose not to pay this price by default for a scenario of only limited usefulness. Instead it chose to implement a lock free List. Authors are responsible for adding any synchronization. It's closer to C++'s model of "pay only for what you use"

I recently wrote a couple of articles on the dangers of using collections with only internal synchronization such as Java's vector.

• http://blogs.msdn.com/jaredpar/archive/2009/02/11/why-are-thread-safe-collections-so-hard.aspx
• http://blogs.msdn.com/jaredpar/archive/2009/02/16/a-more-usable-thread-safe-collection.aspx

Reference Vector thread safety: http://www.ibm.com/developerworks/java/library/j-jtp09263.html

Answer 3

It is simply a design decision to implement the types not thread safe. The collections provide the propertiy SyncRoot of the interface ICollection and the Synchronized() method on some collections for explicitly synchronizing the data types.

Use SyncRoot to lock a object in multithreaded enviroments.

lock (collection.SyncRoot)
{
   DoSomething(collection);
}

Use collection.Synchronized() to obtain a thread safe wrapper for the collection.

Answer 4

For true thread safety, List<> and other collection types would need to be immutable. With the parallel extensions to .NET coming out in .NET 4.0 we'll be seeing thread safe versions of the most commonly used collections. Jon Skeet touches on some of this.

Answer 5

The race-condition possibility JaredPar mentions is the scary consequence of relying on Vector's supposed thread-safety. It's the sort of thing that results in the "every ninth Tuesday the app does something weird"-sort of defect report that will drive you insane.

There are a number of truly thread-safe collections coming in .Net 4, with an interesting side-effect that they allow single-threaded modification of the collection while enumerating, but there's a performance hit that comes with thread-safety, sometimes a pretty big one.

So the logical thing for a framework developer to do is keep the class as performant as possible for the 95% of users who probably won't be doing threading and rely on those who do multi-thread to know what they have to do to keep it safe.

Answer 6

use SynchronizedCollection it also provides a Constructor-Parameter to use a shared sync :)