Can a read instruction after an unrelated lock statement be moved before the lock?

This question is a follow-up to comments in this thread.

Let's assume we have the following code:

// (1)
lock (padlock)
{
    // (2)
}
var value = nonVolatileField; // (3)

Furthermore, let's assume that no instruction in (2) has any effect on the nonVolatileField and vice versa.

Can the reading instruction (3) be reordered in such a way that in ends up before the lock statement (1) or inside it (2)?

As far as I can tell, nothing in the C# Specification (§3.10) and the CLI Specification (§I.12.6.5) prohibits such reordering.

Please note that this is not the same question as this one. Here I am asking specifically about read instructions, because as far as I understand, they are not considered side-effects and have weaker guarantees.

Jon Skeet
people
quotationmark

I believe this is partially guaranteed by the CLI spec, although it's not as clear as it might be. From I.12.6.5:

Acquiring a lock (System.Threading.Monitor.Enter or entering a synchronized method) shall implicitly perform a volatile read operation, and releasing a lock (System.Threading.Monitor.Exit or leaving a synchronized method) shall implicitly perform a volatile write operation. See §I.12.6.7.

Then from I.12.6.7:

A volatile read has “acquire semantics” meaning that the read is guaranteed to occur prior to any references to memory that occur after the read instruction in the CIL instruction sequence. A volatile write has “release semantics” meaning that the write is guaranteed to happen after any memory references prior to the write instruction in the CIL instruction sequence.

So entering the lock should prevent (3) from moving to (1). Reading from nonVolatileField still counts as a "reference to memory", I believe. However, the read could still be performed before the volatile write when the lock exits, so it could still be moved to (2).

The C#/CLI memory model leaves a lot to be desired at the moment. I'm hoping that the whole thing can be clarified significantly (and probably tightened up, to make some "theoretically valid but practically awful" optimizations invalid).

people

See more on this question at Stackoverflow