.NET thread safety

Question

List.Add is an instance member. That means it's not guaranteed to be thread-safe. What does this mean?

Possibility 1. That if two threads invoke .Add on different instances, there could be an unexpected result depending on the phase of the moon?

Possibility 2. That if two threads invoke .Add on the same instance, there could be an unexpected result depending on the phase of the moon and if the instances are different there is no potential problem.

Possibility 3. Microsoft doesn't want people to use threading at all so they wrote .NET to be ambiguous.

Answer 1

Possibility 1 is not the case. It would be so unusual for an instance method to cause problems for other instances that this would be documented clearly (not just with a statement pointing this out, but also with some justification as this would generally be a sign of very bad coding, so if there was a good reason for it, it would be pointed out).

Possibility 3 is not the case, as they've just documented the threading behaviour.

Possibility 2 is partly the case. However, the interaction can also be with one thread calling Add and another calling a different non-threadsafe instance method.

The majority of mutable classes supplied by the framework are threadsafe for static members and non-threadsafe for instance methods. This is with good reason.

1. If a static method is not thread-safe, it is very difficult to make calls to that method in a thread-safe manner, especially if the class may be used by different layers of code written by different people. This makes the effort of making such methods threadsafe almost always justified. Most such members are also relatively easy to make threadsafe anyway (if one avoids having mutable static state, which is always a good thing to avoid).

2. Much use of individual objects will be by one thread at a time, with no prospect of it being accessed by another thread. This makes the difficulty of ensuring correctness, with the risk of deadlock if it goes wrong, and the overhead imposed on performance, hard to justify. It is also relatively easy for the person using the class to ensure that an instance that is used by multiple threads, is used in a threadsafe manner.

There's a heavy emphasis on the "relatively" there, as writing threadsafe code is not always easy. Sometimes its pretty easy (immutable classes take a bit of work to make non-threadsafe!), but more often it's very hard (hence many questions on the topic here and elsewhere).

Yet this is precisely why the burden should be put on the user in such cases. To make such a class entirely threadsafe is so difficult (indeed, sometimes provably impossible) that the results would be unacceptable to most users, who are the people in the best position to judge just what protection is needed in a given case.

Answer 2

If two different threads modify the same list without synchronization/locking, that could cause issues. Two threads working with different lists will be fine. The same goes for most classes -- there are actually very, very few classes that explicitly state "this class is thread safe.", but almost all of them are safe if you're not sharing (access to) instances between threads. If a class breaks even when threads aren't sharing instances, the docs will say so -- but that's such an ugly situation that i'd hope MS would keep it out of the API.

Microsoft says and does things the way they do (thread safety wise) for one huge reason:

Thread safety is hard.

There is no way to synchronize things that will work for everyone. And locking and synchronizing when you don't have to can kill performance and possibly even stability. The all-around best solution is to have the code just do what it's supposed to do, sans synchronization, and let the people who need thread safety arrange it themselves.

Answer 3

If two threads simultaneously try to do different things to the same instance of a List, bad things may happen. The only situation where it is safe for multiple threads to simultaneously do different things with a list is when all threads are reading. I think that's safe with a list, though even that might not necessarily be safe with all container classes.

Collections like Lists in .net are generally stored in arrays; if a collection gets too big for its array, a larger array will be allocated. If multiple threads are dealing with the same collection and don't have any interlocks, it would be possible for one thread to add something that would grow a list, and then for other threads to attempt to change the list between the time the list was copied and the time the collection started using the new list. This could cause changes to get lost, or cause other bad things to happen.

Answer 4

I think, List.Add is a bad example. List.Remove is way better, because there actually are noteworthy threading problems. One thread could try to access an item, whereas a different thread would try to call List.Remove on it. Now, it could happen that the item gets removed when it's tried to get accessed, which results in a NullReferenceException. In general though, this is mostly a disclaimer to be aware of it, as there are no locking mechanisms in place. Just remember to lock whenever two threads could try to access the same object or same piece of code to prevent such issues.

Answer 5

Because there is no locking mechanism implemented on instance members so they put that disclaimer on the MSDN website.

See also Statics and Thread Safety

and Statics and Thread Safety: Part II