Useful resources on memory models

Posted on 2022-09-25, last updated on 2023-12-31

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… ​