Is the ECMA-334 example for volatile fields correct?

[delreluca]

I was trying to understand the precise meaning of volatile. Volatile fields are defined in the ECMA-334 V7 C# spec under section 15.5.4. It talks about how acquire–release semantics of volatile reads and writes can prevent certain instruction reorderings.

The example that is provided illustrates that very well. However it also contains a polling loop checking the volatile field. This is interesting because it concerns another optimisation, namely pulling the flag check out of the loop (hoisting).

If you look at the .NET Core JIT assembly you see that without volatile the flag field is only loaded once. The IL looks the same for both versions though (except for the .volatile parts of course).

The CLR ECMA-335 (5th ed) standard seems to call this out in sections 12.6.4 and 12.6.7:

12.6.4: Conforming implementations of the CLI are free to execute programs using any technology that guarantees, within a single thread of execution, that side-effects and exceptions generated by a thread are visible in the order specified by the CIL. For this purpose only volatile operations (including volatile reads) constitute visible side-effects.

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.
[Rationale: One traditional use of volatile operations is to model hardware registers that are visible through direct memory access. In these cases, removing or coalescing the operations might change the behavior of the program. end rationale]

However the C# specification does not seem to make any of these guarantees for volatile, so I was wondering whether some other part of the standard explains why this code is supposed to work?

In this 2012 MSDN Magazine article about memory models the author poses the same question:

On one hand, the specification states only that volatile fields obey the acquire-release semantics, which doesn’t seem sufficient to prevent hoisting of a volatile field. On the other hand, the example code in the specification does in fact poll a volatile field, implying that the volatile field read can’t be hoisted out of the loop.

[NN---]

.NET implements stricter memory model than ECMA defines.
https://github.com/dotnet/runtime/blob/main/docs/design/specs/Memory-model.md

[delreluca]

Please correct me if I’m wrong, but I don’t see the relation to my question. As shown by the JIT disassembly the volatile read in the example is necessary in current .NET. Also, this is about the example in the C# spec (ECMA 334), not about the CLI spec (ECMA 335) or other additional guarantees by .NET (like the memory model design doc). The C# spec only makes references to the BCL portions (IV) of ECMA-335, whereas the quotations are from partition I.

[CyrusNajmabadi]

@tannergooding @stephentoub

[stephentoub]

The C# spec states "A volatile read has “acquire semantics”; that is, it is guaranteed to occur prior to any references to memory that occur after it in the instruction sequence." Hoisting a read out of a loop would effectively coalesce an arbitrary number of memory reads, reordering them relative to other reads.

[delreluca]

I think this is a possible interpretation, Stephen, however the section talks about reorderings in the instruction sequence without defining the term precisely (at least I was not able to find it; the only thing I was able to deduce is that it’s about the temporal sequence of instructions not the instruction as they are laid out in the code listing).

The question is whether other optimisations leading to non-reordering changes (as a non-benevolent reader might argue that collapsing the reads is not a reordering) are also prohibited.

Funnily, since I had to go through the C# spec again, I found section 7.10 which talks about the preservation of side effects:

Emphasis mine:

7.10 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, 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 (§15.5.4), lock statements (§13.13), and thread creation and termination.

So removing the side effect of the volatile read is not to allowed by the C# spec (just like in the CLI spec) after all. This renders my discussion above moot.

Happy holidays to everyone