Does volatile prevent introduced reads or writes?

Question

In C#, volatile keyword ensures that reads and writes have acquire and release semantics, respectively. However, does it say anything about introduced reads or writes?

For instance:

volatile Thing something;
volatile int aNumber;

void Method()
{
    // Are these lines...
    var local = something;
    if (local != null)
        local.DoThings();

    // ...guaranteed not to be transformed into these by compiler, jitter or processor?
    if (something != null)
        something.DoThings(); // <-- Second read!



    // Are these lines...
    if (aNumber == 0)
        aNumber = 1;

    // ...guaranteed not to be transformed into these by compiler, jitter or processor?
    var temp = aNumber;
    if (temp == 0)
        temp = 1;
    aNumber = temp; // <-- An out-of-thin-air write!
}

Answer 1

Here's what the C# spec¹ has to say about Execution Order:

Execution of a C# program proceeds 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 ...

The execution environment is free to change the order of execution of a C# program, subject to the following constraints:

...

The ordering of side effects is preserved with respect to volatile reads and writes ...

I would certainly consider introducing new side effects to be changing the order of side effects, but it's not explicitly stated like that here.

---

Link in answer is to the C# 6 spec which is listed as Draft. C# 5 spec isn't a draft but is not available on-line, only as a download. Identical wording, so far as I can see in this section.

Answer 2

This wording from the C# spec:

The ordering of side effects is preserved with respect to volatile reads and writes...

may be interpreted as implying that read and write introductions on volatile variables are not allowed, but it is really ambiguous and it depends on the meaning of "ordering." If it is referring to relative ordering of existing accesses, then introducing new reads or writes does not change that and so it would not violate this part of the spec. If it is referring to the exact position of all memory accesses in program order, then introducing new accesses would violate the spec.

This article says that reads on non-volatile variables might be introduced but does not say explicitly whether this is not allowed on volatile variables.

This Q/A discusses how to prevent read introduction (but no discussion on write introduction).

In the comments under this article, two Microsoft employees (at the least at the time the comments were written) explicitly state that read and write introductions on volatile variables are not allowed.

Stephen Toub

"read introduction" is one mechanism by which a memory reordering might be introduced.

Igor Ostrovsky

Elsewhere in the C# specification, a volatile read is defined to be a "side effect". As a result, repeating the read of m_paused would be equivalent to adding another side effect, which is not allowed.

I think we can conclude from these comments that introducing a side effect out-of-thin-air in C#, any kind of side effect, anywhere in the code is not allowed.

A related quote from the CLI standard states the following in Section I.12.6.7:

An optimizing compiler that converts CIL to native code shall not remove any volatile operation, nor shall it coalesce multiple volatile operations into a single operation.

As far as I know, the CLI does not explicitly talk about introducing new side effects.