What makes instance members thread-unsafe vs public static?

Question

So we've all seen the Threading notification on MSDN for many available generic objects:

"Public static (Shared in Visual Basic) members of this type are thread safe. Any instance members are not guaranteed to be thread safe."

My question is, what is it about being an instance variable vs a public static makes it unsafe?

Answer 1

It's the issue of state. What general makes methods unsafe for multiple threads is they do not access shared state in a thread safe manner. Static methods in general do not access shared state and hence are less likely to run into this problem. It's still possible to have race conditions in static / shared methods if they touch static data but in general static methods do not.

Answer 2

Nothing inbuilt makes static any more-or-less different (re thread-safety) than instance, except:

• static methods are often stateless "pure functional" methods, making them automatically thread-safe
• there is a clear expectation on static members to be thread-safe (since you can't really control what each thread is doing at once) - so it is expected that any static method that could risk thread-safety be made thread-safe

This is not true for instance methods:

• instance methods commonly access state on that instance
• there is no expectation of thread safety unless it is made explicit in the documentation

So in general it is expected that the caller manage thread-safety over instances.

There are exceptions where instances are thread-safe (usually for things that are deeply tied to threading, such as a producer-consumer queue) - but IMO any static member that isn't thread safe is a bug.

Answer 3

This is only true in general.

In general static methods are static because they are not dependant on nor do they access any instance defined data that another thread could also access. In general, the only variables they use are local variables, declared and scoped to the stack frame of that instance of the method. If they did, they could not be static. An Instance method, in contrast, does access some data element (property or field) of the instance.

If, otoh, a static method accesses a static property or field of the class, it is equally non-thread -safe.

There are four conditions needed for a race to be possible.

1. The first condition is that there are memory locations that are accessible from more than one thread. Typically, these locations are global/static variables or are heap memory reachable from global/static variables.
2. The second condition is that there is a property (often called an invariant), which is associated with these shared memory locations that must be true, or valid, for the program to function correctly. Typically, the property needs to hold true before an update occurs for the update to be correct.
3. The third condition is that the invariant property does not hold during some part of the actual update. (It is transiently invalid or false during some portion of the processing).
4. The fourth and final condition that must occur for a race to happen is that another thread accesses the memory while the invariant is broken, thereby causing inconsistent or incorrect behavior.

Answer 4

The problem with methods that are not thread safe is concurrent access to shared resources such as instance variables. If a static method only works on private/local data, it is inherently thread safe. However, there is no guarantee that static methods do that - this must be done explicitly.

Thus for a static method to be thread safe it cannot access static members without using synchronization and it should copy whatever data it receives as input before modifying it.