Memory Model: preventing store-release and load-acquire reordering

Question

It is known that, unlike Java\'s volatiles, .NET\'s ones allow reordering of volatile writes with the following volatile reads from another location. When it is a problem

Answer 1

EDIT The conclusions I drew from the C# specs are wrong, see below. END EDIT

I surely am not someone 'authorized', but I think you haven't understood the memory model correctly.

Quoting the C# specification, section §10.10 Execution order, third bullet point on page 105:

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

Volatile reads and writes are defined as "side-effects" and this paragraph states that the ordering of side-effects is preserved.

So it is my understanding that your whole question is based on an incorrect assumption: volatile reads and writes cannot be reordered.

I think you got confused with that fact that with respect to non-volatile memory operations, volatile reads and writes are only half-fences.

EDIT this article: The C# Memory Model in Theory and Practice, Part 2 states exactly the opposite and supports your assertion that volatile reads can move up past an unrelated volatile write. The suggested solution is to introduce a MemoryBarrier where it matters.

Comment by Daniel below also says that the CLI spec is more specific about this than the C# spec and allows this reordering.

Now I find that the C# spec I quoted above is confusing! But given that on x86 the same instructions are used for a volatile memory access and a regular memory access, it makes perfect sense that they are subject to the same half-fence reordering issues. END EDIT