As someone with a decent level of familiarity, this post was good (even taught me a couple new things). Unfortunately this topic is so difficult that it can only be briefly introduced in a medium sized blog post. Mastering fences, compiler reordering, on-chip reordering, cache coherence protocols is like multiple PhD level if not more. And even that’s not enough to fully master even a mutex (you still need thread yielding/parking). And even then correctly implemented mutices are notorious foot-machine guns.

My high level take is we mostly got concurrency wrong for imperative languages (probably because they were developed before parallel execution and all these optimizations was a thing). Exposing shared mutable memory access to application developers should have been a no-go from the start.

So, even if parallelism is a Wild West, some form of concurrency is a must-have, and ironically the language that caused the least amount of pain was JS, because they chose to keep business logic single threaded. And even for the perf issues with JS, you rarely see the lack of parallel business logic mentioned as a bottleneck. And web workers (the escape hatch), are quite uncommon in practice, which imo validates that the tradeoff was worth its weight in gold.

Here's a tool suite to simulate and run memory model litmus tests (on real hardware): https://github.com/herd/herdtools7

The simulation tool can also generate relation graphs similar to those of the blog.

I have always found this hard to reason about. This was a nice primer! I also like the rustonomicon’s treatment of the subject: https://doc.rust-lang.org/nomicon/atomics.html