C# enforcing order of statement execution

Question

My question is about order of execution guarantees in C# (and presumably .Net in general). I give Java examples I know something about to compare with.

For Java (from "Java Concurrency in Practice")

There is no guarantee that operations in one thread will be performed in the order given by the program, as long as the reordering is not detectable from within that thread-even if the reordering is apparent to other threads.

So the code

  y = 10;
  x = 5;
  a = b + 10;

may actually assign a=b+10 Before assigning y = 10

And in Java (from the same book)

Everything thread A does in or prior to a synchronized block is visible to thread B when it starts a synchronized block guarded by the same lock.

so in Java

 y = 10;
 synchronized(lockObject) {
     x = 5;
 }
 a = b + 10;

y = 10 and x = 5 are guaranteed to both run before a = b + 10 (I don't know whether y = 10 is guaranteed to run before x = 5).

What guarantees does C# code make for the order of execution for the C# statements

 y = 10;
 lock(lockObject) {
     x = 5;
 }
 a = b + 10;

I am particularly interested in an answer that can provide a definitive reference or some other really meaningful justification as guarantees like this are hard to test because they are about what the compiler is allowed to do, not what it does every time and because when they fail you are going to have very hard to reproduce intermittent bugs when threads hit things in just the wrong order.

Answer 1

I'm worried that you're even asking this but since you asked.

y = 10;
Thread.MemoryBarrier();
x = 5;
Thread.MemoryBarrier();
a = b + 10;
Thread.MemoryBarrier();
// ...

From msdn

Synchronizes memory access as follows: The processor executing the current thread cannot reorder instructions in such a way that memory accesses prior to the call to MemoryBarrier execute after memory accesses that follow the call to MemoryBarrier.

Answer 2

ISO 23270:2006 — Information technology—Programming languages—C#, §10.10 says (and I quote):

10.10 Execution order Execution shall proceed such that the side effects of each executing thread are preserved at critical execution points. A side effect is defined as a read or write of a volatile field, a write to a non-volatile variable, a write to an external resource, and the throwing of an exception. The critical execution points at which the order of these side effects shall be preserved are references to volatile fields (§17.4.3), lock statements (§15.12), and thread creation and termination. An implementation is free to change the order of execution of a C# program, subject to the following constraints:

• Data dependence is preserved within a thread of execution. That is, the value of each variable is computed as if all statements in the thread were executed in original program order. (emphasis mine).

• Initialization ordering rules are preserved (§17.4.4, §17.4.5).

• The ordering of side effects is preserved with respect to volatile reads and writes (§17.4.3). Additionally, an implementation need not evaluate part of an expression if it can deduce that that expression’s value is not used and that no needed side effects are produced (including any caused by calling a method or accessing a volatile field). When program execution is interrupted by an asynchronous event (such as an exception thrown by another thread), it is not guaranteed that the observable side effects are visible in the original program order.

The other CLI standards are likewise available gratis from the ISO at

• ISO 23271:2006 — *Information technology—Common Language Infrastructure (CLI) Partitions I to VI
• ISO 23272:2006 — Information technology—Common Language Infrastructure (CLI)—Technical Report on Information Derived from Partition IV XML File

But if you are worried about multi-threading issues, you'll need to dig deeper into the standards and understand the rules about atomicity. Not every operation is warranted to be atomic. If you are multi-threaded and invoking methods that reference anything but local variables (e.g., instance or class (static) members) without serializing access via lock, a mutex, a semaphore, or some other serialization technique, you are leaving yourself open to race conditions.

Answer 3

What you are looking for is Thread.MemoryBarrier

However they may not be necessary for Microsoft's current implementation of .NET. See this SO question for more details.

Answer 4

Without having read anything about .NET memory model, I can assure you .NET gives you at least those guarantees (i.e. lock behaves like an acquire an unlock like a release), since they are the weakest guarantees that are useful.