alexrp’s blog

ramblings usually related to software

Introducing Atomique

If you’ve read my previous post on .NET atomics, you’ll know I’m not a big fan of those APIs in the .NET Framework. But it’s easy to sit back and complain about things, so I decided to actually try to do something about this sucky situation.

My attempt to sanitize atomics in .NET is Atomique, a library I just released on GitHub and NuGet. It provides atomic operations based on the C++11 memory model, with some stuff removed and simplified for the Common Language Infrastructure.

In particular, Atomique does not support these C++11 std::atomic features:

  • 8-bit and 16-bit add, subtract, and compare-and-exchange operations.
  • AND/OR/XOR atomic read-modify-write operations.
  • Weak (spuriously failing) compare-and-exchange operations.
  • Separate success/failure barriers for compare-and-exchange operations.
  • Signal/compiler memory barriers (i.e. atomic_signal_fence).
  • Load operations with consume semantics (i.e. memory_order_consume).

If you’re curious why these aren’t supported, refer to the

Atomique attempts to make you think about the memory barriers you want by way of method naming: Every atomic operation method ends in Relaxed, Acquire, Release, or Sequential. If you have no idea what these terms mean, going with Sequential is almost always safe.

Atomique will, in some cases, use barriers that are much stronger than strictly necessary. This is a result of the very limited APIs in the .NET Framework. While this can have a negative impact on performance, it won’t be any worse than using the .NET Framework APIs directly. Also, stronger barriers are not actually problematic in terms of semantics; your code will still behave the way you expect it to. So, by using Atomique, you’re just making it clearer in your code what semantics you want. As the .NET Framework and Atomique evolve, your code will just end up being faster when these overly strong barriers are eventually removed, and you won’t have to change anything.

Atomique is built as a Portable Class Library (PCL). It should work on the majority of platforms that aren’t Silverlight-based. It also has no particular processor architecture dependencies, so it’ll just work on e.g. ARM and MIPS.