Useful resources on memory models

A list of resources on memory models and accompanying topics.

Contents
  1. General
  2. C
  3. C++
  4. Rust
  5. Java

General

Non-language-specific resources:

C

Specification-like resources:

Free-form resources:

C++

Specification-like resources:

Rust

Specification-like resources:

Free-form resources:

Tools:

  • Loom—a testing tool for concurrent Rust code.
  • ThreadSanitizer—a data race detection tool.

Java

Specification-like resources:

Free-form resources:

Tools:

  • Lincheck—a framework for testing concurrent data structures for correctness.
  • jcstress—an experimental harness and a suite of tests to aid the research in the correctness of concurrency support in the JVM, class libraries, and hardware.
  • JPF—an extensible software model-checking framework.
  1. These resources are about consistency models of distributed systems and not about hardware / programming language memory models (the latter is just a "hardware" memory model of an abstract machine—an imaginary computer for which a programming language is defined). However, conceptually these are the same thing, as one can always treat memory subsystems and processor caches, registers as a distributed system with unusually strong guarantes: synchronous "network", no message loss, infallible "nodes". Interestingly, when you look at things this way, it becomes obvious that the choice in favour of a weaker consistency model is not always about the availability–consistency trade-off as in CAP, but also (in case of memory models—only) about the latency–consistency trade-off as in PACELC

  2. "C just copies the C++ memory model; and C++11 was the first version of the model but it has received some bugfixes since then." The C++ memory model was influenced by the Java memory model. 

  3. There is not much info there, and it will likely stay that way for the foreseeable future. "Rust pretty blatantly just inherits the memory model for atomics from C++20." It may be worth mentioning here tangentially related "The Rustonomicon" and "Unsafe Code Guidelines Reference"

  4. So C++ "stole" from Java, C and Rust—from C++, Java "stole" access modes and fences from C++, the circle is complete. 

  5. There is no compiler, a.k.a. signal, fence similar to those in C, C++, Rust because Java code is not supposed to handle signals, a.k.a. hardware and software interrupts

  6. Instead of individual Java SE contributors publishing memos like that, the Java memory model needs to be updated. Any decade now…