Useful resources on memory models
A list of resources on memory models and accompanying topics.
- "Hardware Memory Models", "Programming Language Memory Models" by Russ Cox
- "Теоретический минимум для понимания Java Memory Model" by Roman Elizarov (the video is in Russian and is currently hidden for some reason, the slides are here)
- "Strong consistency models", "Consistency models"1 by Kyle Kingsbury
- "Modern C" by Jens Gustedt, chapters:
- Memory model
- Memory model3
- Loom—a testing tool for concurrent Rust code.
- Memory model (JMM)
- "Close Encounters of The Java Memory Model Kind" by Aleksey Shipilëv
- "Java 9 VarHandles Best practices, and why?" by Tobi Ajila
- "The JSR-133 Cookbook for Compiler Writers" by Doug Lea
- "What do
Unsafe::putOrdered*actually mean?" by Nitsan Wakart
- "A Formalization of Java's Concurrent Access Modes" by John Bender, Jens Palsberg
- 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.
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.
"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.
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".
So C++ "stole" from Java, C and Rust—from C++, Java "stole" access modes and fences from C++, the circle is complete.
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.
Instead of individual Java SE contributors publishing memos like that, the Java memory model needs to be updated. Any decade now…