8 ms·

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

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 https://marabos.nl/atomics/foreword.html

seanhunter 4y ago
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 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.01c.pdf http://www.rdrop.com/users/paulmck/RCU/rclock_OLS.2001.05.01... if you want the good stuff
- cwzwarich 4y ago
  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/p2545r1.pdf 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.
  - throwaway17_17 4y ago
    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.
    - cwzwarich 4y ago
      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/p0098r1.pdf https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p00... https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0190r3.pdf https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p01... https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0462r1.pdf https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p04... https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0735r1.html 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.
      - zozbot234 4y ago
        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.
- chandlore 4y ago
  He also wrote a good introduction to parallel programming that's freely available as well: https://mirrors.edge.kernel.org/pub/linux/kernel/people/paulmck/perfbook/perfbook.html https://mirrors.edge.kernel.org/pub/linux/kernel/people/paul...
bonzini 4y ago
The combination of Mara as the author and Paul McKenney writing a foreword is already a good reason to read the book. :)
mrkeen 4y ago
> 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.
- echelon 4y ago
  > 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?
  - peoplefromibiza 4y ago
    > 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.
    - estebank 4y ago
      Someone has to implement those frameworks, and those people need to understand pretty much everything covered by this book :)
      - peoplefromibiza 4y ago
        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.
penguin_booze 4y ago
Also from Paul: The Perf Book: https://mirrors.edge.kernel.org/pub/linux/kernel/people/paulmck/perfbook/perfbook.html https://mirrors.edge.kernel.org/pub/linux/kernel/people/paul....

seanhunter 4y ago

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 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.01c.pdf http://www.rdrop.com/users/paulmck/RCU/rclock_OLS.2001.05.01... if you want the good stuff

cwzwarich 4y ago
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/p2545r1.pdf 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.
- throwaway17_17 4y ago
  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.
  - cwzwarich 4y ago
    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/p0098r1.pdf https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p00... https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0190r3.pdf https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p01... https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0462r1.pdf https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p04... https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0735r1.html 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.
    - zozbot234 4y ago
      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.
chandlore 4y ago
He also wrote a good introduction to parallel programming that's freely available as well: https://mirrors.edge.kernel.org/pub/linux/kernel/people/paulmck/perfbook/perfbook.html https://mirrors.edge.kernel.org/pub/linux/kernel/people/paul...

bonzini 4y ago

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

mrkeen 4y ago

> 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.

echelon 4y ago
> 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?
- peoplefromibiza 4y ago
  > 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.
  - estebank 4y ago
    Someone has to implement those frameworks, and those people need to understand pretty much everything covered by this book :)
    - peoplefromibiza 4y ago
      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.

penguin_booze 4y ago

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