Hacker News Reader

Comment by estebank | Hacker News Reader

The foreword by Paul E. McKenney makes a great case to read this book even if you don't care about Rust at all:

> Which brings us to another group of potential readers, the Rust skeptics. While I do believe that most Rust skeptics are doing the community a valuable service by pointing out opportunities for improvement, all but the most Rust-savvy of skeptics would benefit from reading this book. If nothing else, doing so would enable them to provide sharper and better-targeted criticisms.

> Then there are those dyed-in-the-wool non-Rust developers who would prefer to implement Rust's concurrency-related safety mechanisms in their own favorite language. This book will give them a deeper understanding of the Rust mechanisms that they would like to replicate, or, better yet, improve upon.

https://marabos.nl/atomics/foreword.html

View on HN

In case anyone here doesn’t know, Paul McKenney was one of the main contributors to the RCU[1] implementation for the Linux kernel. So the guy knows a thing or two about concurrency.

[1] https://en.wikipedia.org/wiki/Read-copy-update if you just want to know what it is and http://www.rdrop.com/users/paulmck/RCU/rclock_OLS.2001.05.01... if you want the good stuff

Although, somewhat amusingly, neither C++ nor Rust (which basically just copies the C++ atomics and memory model) can be used to correctly express RCU written within the language. The leading proposal for C++ (at least AFAICT) is to just add RCU primitives to the library and make their correctness the implementation's concern:

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p25...

I hope we get a next generation of systems languages with improved memory models that can actually express these things directly.

> Although, somewhat amusingly neither C++ nor Rust [...] can be used to correctly express RCU written within the language.

What do you mean exactly? Of course the required remote memory barrier need to be a primitive as it is provided by the OS, and ultimately the hardware, but AFAIK the asymmetric synchronization needed by RCU can be modelled within the C++ as a signal and a atomic signal fence.

You can't express the equivalent of Linux's rcu_dereference primitive in a way that avoids data races without using memory_order_acquire (or memory_order_consume, which is treated like memory_order_acquire in all implementations, and is fundamentally broken as I link to in my sibling reply). With a memory consistency model weaker than TSO (e.g. ARM, RISC-V, POWER), this imposes unnecessary overhead and eliminates some of the benefits of RCU.

To work around this flaw, you can use inline assembly, implementation-specific "compiler-only" barriers, etc. but that's outside of the language. It also forces the compiler to be much more pessimistic about optimizations than is actually necessary to preserve dependency ordering.

Can you provide any extra information about what is unable to be expressed? I’d like to look into what sort of constructs could be useful in this context.

The keyword to search for is "memory_order_consume", which was C++11's proposed solution to the problem that turned out to not work in practice. Here are some of the C++ WG documents describing the issues:

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p00... https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p01... https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p04... https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p07...

A lot of the problems center around the reliance on data dependencies for ordering, and the difficulty of expressing these requirements in a manner that is compatible with separate compilation and compiler optimizations.

Memory_order_consume was added to the C/C++ memory model to support architectures like the Alpha, where indirecting through memory (which includes array indexing, etc.) need not create a true happens_before relationship. So you can have things like:

Assume: a = 1, p = &a, b = 0

  Thr. 1         | Thr. 2
  b = 1          |
  memory_barrier | i = *p
  p = &b         |

The result can be i = 0

Even though b=1 happens "before" p=&b within Thread 1, it is seen as happening after it by Thread 2. To overcome this, Thread 2 needs a barrier between the load of p from memory and the indirect load that assigns to i. Practically no other architectures have that quirk, and it only happens on Alpha because of its two separate cache banks.

Unfortunately, it has turned out to be infeasible to give memory_order_consume a proper weak semantics setting it apart from memory_order_acquire, given e.g. how common it is for indirections to be altered by compiler optimizations. So Ordering::Consume does not, as of yet, exist in Rust.

The problem of the CPU reordering things only exists on architectures like Alpha. However, there's still the problem of the compiler reordering things (which exists on every architecture), and memory_order_consume was intended to solve both. As you can see from the original rationale document from 2010, this RCU use-case was one of the main motivations:

https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1525.htm

He also wrote a good introduction to parallel programming that's freely available as well:

https://mirrors.edge.kernel.org/pub/linux/kernel/people/paul...

The combination of Mara as the author and Paul McKenney writing a foreword is already a good reason to read the book. :)

Also from Paul: The Perf Book: https://mirrors.edge.kernel.org/pub/linux/kernel/people/paul....

> Then there are those dyed-in-the-wool non-Rust developers who would prefer to implement Rust's concurrency-related safety mechanisms in their own favorite language.

The book's called "atomics and locks". What language doesn't already have those? If I'm touching those, doesn't that mean I'm already trying to reimplement my own concurrency-safety mechanisms?

Howabout Rust implements my favourite concurrency-related safety mechanisms, so I don't need to ever know about atomics or locks.

The "About this book" tells you what the book covers. The whole book is available for you to peek at if you don't trust it to correctly summarize itself.

As you would expect, Rust does have concurrency primitives, which is why the book shows you how they are implemented and why they are implemented they way they are. In doing so it also teaches you how to do low level things for when you can't use the language provided primitives, like if you're interacting with FFI boundaries or implementing your own lockless datastructure.

Your comment is like seeing a link to "Learning Rust With Entirely Too Many Linked Lists" and reacting with "what language doesn't have linked lists?"

Edit: I see that you might have meant "why would I reimplement Rust's atomic primitives in another language". Well, some documentation is needed for anyone that will have to implement those language primitives, in existing languages (because there are undressed needs) or in new ones. More documentation and explanation of tricky concepts is good.

What sort of things are "your favourite" and why ought Rust to specifically do things you favour, rather than what anybody else might like ?

Rust got scoped threads (again), that's a rather nice safe concurrency feature, a way to say "This thread shall only live during this object's lifetime". For example you can give a new HttpConnection to a scoped thread, knowing that Rust ensures the thread ends before the HttpConnection ceases to exist. Before scoped threads Rust wouldn't let you (safely) make threads which use outside objects with a finite lifespan, as it can't be sure the thread won't touch an object which no longer exists.

But this sort of book is more aimed at people who are interested in the details you apparently don't care about (or don't want to care about). Somebody has to know how it works to build the higher level mechanisms you desire.

> Howabout Rust implements my favourite concurrency-related safety mechanisms, so I don't need to ever know about atomics or locks.

How on earth are you doing concurrency without touching these two key primitives at some point? Lots of lockless?

> How on earth are you doing concurrency without touching these two key primitives at some point?

using one of the many higher level concepts/frameworks available.

- actor model

- fork join

- CSP

etc.

Someone has to implement those frameworks, and those people need to understand pretty much everything covered by this book :)

not to disagree or antagonize, but the question was

> How on earth are you doing concurrency without touching these two key primitives

and not how to write high level concurrency frameworks.

I wouldn't trust very much a concurrency framework written by someone who just learned about locks and atomics on a book.

I wouldn't even trust myself to write low level concurrent code using locks and atomics.

I have 26 years of experience as a programmer and if there's something I've learned is that low level concurrency is really hard to get right, even when you perfectly understand the underlying concepts, and it's best left to real experts that dedicated their career to it.

edit: I'm sure the book is great and the authors very knowledgeable and I'm really curious to read it.

Sometimes all you need is an atomic counter though (or lock). Like, for the commonly used Prometheus metrics format, you usually just have global, atomic counters, because it's arguably the most efficient/easiest way to do it. Higher level primitives are nice, but even lower level APIs might be "the right choice" for even high-level problems.

They predate rust.

There are many practical instances where an atomic is the simplest solution, e.g., shared counters.

Maybe the book isn't for you then. Not every book has to be.

Maybe I was criticising the quoted text, not the book.

Reply on news.ycombinator.com