While ‘Winter is coming’ for a while, atomics.net project is going to RTM soon.

TL;DR

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.

Preface

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.

More info about new MM gives us Vance Morrison. A few more thoughts and observations you could find in Memory Model 101.

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.

There are several great articles out there by Jeff Preshing, which describes it.

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 Relaxed, Acqure, Release, AcquireRelease and even Sequential consistent memory orderings.