Any guideline on which atomic ordering to choose?

findmyway · November 25, 2021, 10:56am

In the upcoming Julia@v1.7 Per-field atomics, it mentions several atomic orderings: (:monotonic, :acquire, :release, :acquire_release, or :sequentially_consistent). Do you have any general suggestions for which one to use?

woclass · November 25, 2021, 11:14am

The basic premise is: do not use anything other than std::memory_order_seq_cst (the default) unless (a) you really really know what you are doing, and can prove that the relaxed usage is safe in all cases, and (b) your profiler demonstrates that the data structure and operations you are intending to use the relaxed orderings with are a bottleneck.

Specific details of the memory model and other details of the design are written in the Julia Atomics Manifesto, which will later be published formally.

Julia Atomics Manifesto

These memory orderings can be any of the following symbols. More precise definitions can be found elsewhere (in particular, at https://llvm.org/docs/Atomics.html#atomic-orderings), so here we give only the particulars of how they will be mapped inside the Julia runtime.

not_atomic: single-threaded usage only, or inside a lock. This is the default behavior for most operations. This cannot be used to down-grade an atomic write, but simply names the default parameterization for a non-atomic access. And when applied to an atomic field, it’ll be automatically upgraded to a monotonic read.

monotonic: This ensures atomicity of the operation, but otherwise does not ensure the code makes forward progress (do not use in a loop), but only ensures that the operations are seen monotonically making progress within a thread.

acquire: This is an error to specify on a store.

release: This is an error to specify on a load.

acquire_release: This is an error to specify on an operation that doesn’t both read and write memory (so it’s an error to specify on a load or store, and the release will be ignored for a replacefield! failure).

sequentially_consistent: Sequential consistency is the default behavior for @atomic when the ordering is not specified.

The specification and constraints on how these apply to individual operations is particularly nicely described here: https://doc.rust-lang.org/std/sync/atomic/struct.AtomicI8.html

gist.github.com

https://gist.github.com/vtjnash/11b0031f2e2a66c9c24d33e810b34ec0

JuliaAtomics.md

# Introduction
This proposal aims to define the memory model of Julia and to provide certain guarantees in the presence of data races, both by default and through providing intrinsics to allow the user to specify the level of guarantees required. This should allow native implementation in Julia of simple system primitives (like mutexes), interoperate with native system code, and aim to give generally explainable behaviors without incurring significant performance cost. Additionally, it strives to be general-purpose and yet clear about the user's intent—particularly with respect to ensuring that an atomic-type field is accessed with proper care for synchronization.

The last two points deserve particular attention, as Julia has always provided strong reflection and generic programming capabilities that has not been seen—in this synergy combination—in any other language. Therefore, we want to be careful to observe a distinction between the asymmetries of reading vs. writing that we have felt is often not given attention.

# Motivation
In Julia today, multi-threaded code can only be written to perform limited tasks, or in ignorance of the true weakness of the guarantees provided by our current semantics. Additionally some necessary system primitives can also only be implemented by inlining a complicated llvmcall, which can be brittle and limiting. This proposal aims to change that by adopting some more sane defaults for shared variables and exposing new functionality in the builtin functions by adding a specification of memory synchronization ordering for them.

One such aspect is guaranteeing that any data written in the struct initializer is always visible to any place where the struct pointer can be seen, as is already the guarantee for single-threaded execution. This is particularly relevant for ensuring the type-tag of the object is always valid and that the fields of immutable objects (or simply constant fields) always are seen to have their correct value. This implies a release barrier must exist between the end of the constructor and the first time the object is stored to a shared location from a given thread. This has some subtleties to explore later when we discuss the new defaults.

This file has been truncated. show original

BioTurboNick · July 22, 2023, 2:33pm

This is useful information that should probably be in the official docs. At least there was no discussion of these settings here: Multi-Threading · The Julia Language