Is a reference assignment threadsafe?

Question

I'm building a multi threaded cache in C#, which will hold a list of Car objects:

public static IList<Car> Cars {get; private set;}

I'm wondering if it's safe to change the reference in a thread without locking ?

e.g.

private static void Loop()
{
  while (true)
  {
    Cars = GetFreshListFromServer();
    Thread.Sleep(SomeInterval);
  }
}

Basically it comes down to whether assigning a new reference to Cars is atomic or not I'd guess.

If it's not I'll obviously have to use a private field for my cars, and lock around getting and settings.

Answer 1

Yes, reference updates are guaranteed to be atomic in the language spec.

5.5 Atomicity of variable references

Reads and writes of the following data types are atomic: bool, char, byte, sbyte, short, ushort, uint, int, float, and reference types. In addition, reads and writes of enum types with an underlying type in the previous list are also atomic. Reads and writes of other types, including long, ulong, double, and decimal, as well as user-defined types, are not guaranteed to be atomic.

However inside a tight loop you might get bitten by register caching. Unlikely in this case unless your method-call is inlined (which might happen). Personally I'd add the lock to make it simple and predictable, but volatile can help here too. And note that full thread-safety is more than just atomicity.

In the case of a cache, I'd be looking at Interlocked.CompareExchange, personally - i.e. try to update, but if it fails redo the work from scratch (starting from the new value) and try again.

Answer 2

In @Marc Gravell's answer, as referenced in the C# Language Spec 5.5 it is important to know what is meant by the term "user-defined type". I haven't found a clear definition w.r.t. this usage in the C# Language Spec. In the UML and in common parlance, a Class is an instance of a Type. But in the context of the C# Language Spec, it's meaning is unclear.

The Visual Basic Language Reference section "User Defined Types" (at https://msdn.microsoft.com/en-us/library/cec05s9z.aspx) says

"Previous versions of Visual Basic support the user-defined type (UDT). The current version expands the UDT to a structure."

so it would seem that a User-defined Type is a structure, not a Class.

But ....

According to the "C# Programming Guide" section "Types" (at https://msdn.microsoft.com/en-us/library/ms173104.aspx):

"A typical C# program uses types from the class library as well as user-defined types"

which implies a Class is a user-defined type. Later, it gives an example of "complex user-defined types:"

MyClass myClass;

which means "MyClass" is a user-defined type. And later it says:

"Each type in the CTS is defined as either a value type or a reference type. This includes all custom types in the .NET Framework class library and also your own user-defined types. "

... which would imply that all Classes created by a developer are a "User Defined Type".

And, finally, there is this Stackoverflow item in which the meaning of this term is debated inconclusively: How do I determine if a property is a user-defined type in C#?

Therefore, to be safe, I am forced to consider all Classes, either those that I create or those found in the .Net Framework, all to be User-defined Types, and therefore Not Thread Safe for assignment, because it says in the C# Language Spec section 5.5:

Reads and writes of ... as well as user-defined types, are not guaranteed to be atomic.

It is unfortunate that a colloquial term is used in a precise specification like the C# Language Specification. Because of this ambiguity, in order to be thread-safe, I may be writing less-optimal code than would be possible if it turns out that "User-defined Type" does not include CLR Classes.

Therefore I am asking for further clarification of this stackoverflow answer as it's current basis for the answer leaves this significant ambiguity. As it stands, the answer to the question "Is a reference assignment threadsafe?" seems to be "NO".