Consider the following sample code:
class MyClass
{
public long x;
public void DoWork()
{
switch (x)
{
case 0xFF00000000L:
// do whatever...
break;
case 0xFFL:
// do whatever...
break;
default:
//notify that something going wrong
throw new Exception();
}
}
}
Forget the uselessness of the snippet: my doubt is about the behavior of the switch statement.
Suppose that the x field could have only two values: 0xFF00000000L or 0xFFL. The switch above should not fall into the “default” option.
Now imagine that one thread is executing the switch with “x” equal to 0xFFL, thus the first condition won’t match. At the same time, another thread modifies the “x” variable to 0xFF00000000L. We know a 64-bit operation is not atomic, so that the variable will have the lower dword zeroed first, then the upper set afterward (or vice versa).
If the second condition in the switch will be done when the “x” is zero (i.e. during the new assignment), will we fall into the undesired “default” case?
You’re actually posting two questions.
Is it threadsafe?
Well, obviously it is not, another thread might change the value of X while the first thread is going into the switch. Since there’s no lock and the variable is not volatile you’ll switch based on the wrong value.
Would you ever hit the default state of the switch?
Theoretically you might, as updating a 64 bits is not an atomic operation and thus you could theoretically jump in the middle of the assignment and get a mingled result for x as you point out. This statistically won’t happen often but it WILL happen eventually.
But the switch itself is threadsafe, what’s not threadsafe is read and writes over 64 bit variables (in a 32 bit OS).
Imagine instead of switch(x) you have the following code:
now the switch is made over a local variable, and thus, it’s completely threadsafe. The problem, of course, is in the
myLocal = xread and its conflict with other assignments.