While ‘Winter is coming’ for a while, atomics.net project is going to RTM soon.
A couple of months ago I’ve started experiments with C++ atomic API alike implementation on top of .NET Framework. This resulted into atomics.net project.
Memory Model of CLI is described in 12.6 Memory model and optimizations. This model is considered
harmful weak. CLR 2.0 introduced new one, which is x86-compatible.
Why C++ 11 atomics?
I like the design of
std::atomic classes: they have clear API and support several memory ordering modes.
How this could be achieved on CLI, especially .NET?
Well, we need to go deeper. First of all, there are two kinds of MM: hardware (i.e. CPU’s architecture itself) and software (language, framework, etc.). Each one makes some guarantees and establishes possible features it supports.
If everything is clear with C++ world (I hope), the CLI doesn’t have a detailed spec. Really!
There are a lot of interesting blog posts, articles, guides, but almost all of them are covering the worst by performance examples (paires of full memory barriers are used for acquire reads even on x86).
Some platforms, like ARM, require uses of DMB (Data Memory Barrier) for acquire/release operations, while x86 is acquire/release by default. So the performance-hit techniques are needed only on ARM, Itanium (in a fewer cases) and Ecma CLI-only compatible implementations (running on abstract CPU).
.NET’s ARM and Itanium JITs are emitting x86 behaviour compatible code for some ops already (like volatile fields, restricting from more aggressive instructions reordering).
As a result, combining manual usage of barriers/fences with guarantees from CLI we get implementation of
AcquireRelease and even
Sequential consistent memory orderings.