In response to my blog post on ViewState backed properties and the Null Coalescing operator, Scott Watermasysk expresses a worry that the null coalescing operator opens one up to a race condition in the comments of his blog post.
He provides a code example of a thread safe means of reading the
ViewState that copies the value from the
ViewState into a local variable before performing the null check.
That got me worried as well. Not so much about the
ViewState but about applying the null coalescing operator against the
Session. These are classes where you are more likely to run into thread contention. Take a look at this method.
public void Demo(ref object obj)
Console.WriteLine((int)(obj ?? "null"));
The worry is that it might be possible for another thread to set value of the reference to
obj to null in between the null coalescing operator’s check for null and returning it to the cast operation, potentially causing a
However, looking at the generated IL (with my comments interspersed), it seems to me (and I am no IL expert so correct me if I am wrong) that everything is just fine. It seems to copy the value before it performs the null check. So it looks like the null coalescing operator is roughly equivalent to the code Scott uses.
.method public hidebysig instance void Demo(object& obj)
L_0003: dup //copy value to stack
L_0004: brtrue.s L_000c //jump to L_000c if value isn’t null
L_0007: ldstr "null"
L_000c: unbox.any int32
L_0011: call void [mscorlib]System.Console::WriteLine(int32)
So it looks like this is a thread safe operation to me. I look forward to any IL experts informing me if I happen to be missing something.