Rust Atomics and Locks
The Rust programming language is extremely well-suited for concurrency, and its ecosystem has many libraries that include lots of concurrent data structures, locks, and more. But implementing those structures correctly can be very difficult. Even in the most well-used libraries, memory ordering bugs are not uncommon. In this practical book, Mara Bos, leader of the Rust library team, helps Rust programmers of all levels gain a clear understanding of low-level concurrency. You'll learn everything about atomics and memory ordering and how they're combined with basic operating system APIs to build common primitives like mutexes and condition variables. Once you're done, you'll have a firm grasp of how Rust's memory model, the processor, and the roles of the operating system all fit together. With this guide, you'll learn: How Rust's type system works exceptionally well for programming concurrency correctly All about mutexes, condition variables, atomics, and memory ordering What happens in practice with atomic operations on Intel and ARM processors How locks are implemented with support from the operating system How to write correct code that includes concurrency, atomics, and locks How to build your own locking and synchronization primitives correctly
Stats for nerds
18recommend
26mentions
20people
2023–2026years
88% recommend12% neutral
Mentions per year
What Hacker News says
- Rust Atomics and Locks by Mara Bors (https://mara.nl/atomics/) is a very good book and available for free online. It does require knowing Rust at least in a basic level, but it explains things very well.
- I'm in a similar position, I want to learn both eventually but chose to start with Rust because it has several really strong-seeming (like the intro book, or Rust Atomics and Locks), while Zig doesn't have many books yet.
- This post, along with the tutorial links it and the comments contain, provide good insights on the topic of caches, coherence, and related topics. I would like to add a link that I feel is also very good, maybe better:
<https://marabos.nl/atomics/hardware.html>
While the book this chapter is from is about Rust, this chapter is pretty much language-agnostic.
- I'm a little nervous about the correctness of the memory orderings in this project, e.g.
Two acquires back to back are unnecessary here. In general, fetch_sub and fetch_add should give enough guarantees for this file in Relaxed. https://github.com/frostyplanet/crossfire-rs/blob/master/src...
Congest is never written to with release, so the Acquire is never used to form a release chain: https://github.com/frostyplanet/crossfire-rs/blob/dd4a646ca9...
The queue appears to close the channel twice (once per rx/tx), which is discordant with the apparent care taken with the fencing. https://github.com/frostyplanet/crossfire-rs/blob/dd4a646ca9...
The author also suggests an incorrect optimization to Tokio here which suggests a lack of understanding of what the specific guarantees given are: https://github.com/tokio-rs/tokio/pull/7622
The tests do not appear to simulate the queue in Loom, which would be a very, very good idea.
This stuff is hard. I almost certainly made a mistake in what I've written above (edit: I did!). In practice, the queue is probably fine to use, but I wouldn't be shocked if there's a heisenbug lurking in this codebase that manifests something like: it all works fine now, but in the next LLVM version an optimization pass is added which breaks it on ARM in release mode, and after that the queue yields duplicate values in a busy loop every few million reads which is only triggered on Graviton processors.
Or something. Like I said, this stuff is hard. I wrote a very detailed simulator for the Rust/C++ memory model, have implemented dozens of lockless algorithms, and I still make a mistake every time I go to write code. You need to simulate it with something like Loom to have any hope of a robust implementation.
For anyone interested in learning about Rust's memory model, I can't recommend enough Rust Atomics and Locks:
- > Without memory order guarantees enforced by memory barriers, a write to the boolean in thread A is not guaranteed to be observed by thread B.
No, that's not correct. Memory ordering doesn't influence how fast a write is propagated to other cores, that's what cache coherency is for. Memory ordering of an access only matters in relation to accesses on other memory locations. There's a great introduction to this topic by Mara Bos: https://marabos.nl/atomics/memory-ordering.html
- If you haven't seen it, Mara Bos' "Rust Atomics and Locks"[0] is an excellent book on this topic, even if you aren't particularly interested in Rust.
Related
The Rust Programming Language
170 recommend · 257
Rust for Rustaceans
16 recommend · 33
Rust in Action
17 recommend · 41
Programming Rust
64 recommend · 114
2020–2026
Zero To Production In Rust
24 recommend · 39
Cryptonomicon
324 recommend · 847
2019–2022
Atomic Design
2 recommend · 4