Live data from Hacker News

Rust Atomics and Locks: Low-Level Concurrency in Practice

marabos.nl

11–20 of 48 posts

Re: Rust Atomics and Locks: Low-Level Concurrency in Practice

#11
post #3

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, doin…

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.

Re: Rust Atomics and Locks: Low-Level Concurrency in Practice

#12
post #10
post #3

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, doin…

> 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 s…

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

Re: Rust Atomics and Locks: Low-Level Concurrency in Practice

#13
post #12
post #10

Earlier quoted context omitted.

> 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 s…

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

Re: Rust Atomics and Locks: Low-Level Concurrency in Practice

#14
post #10
post #3

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, doin…

> 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 s…

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.

Re: Rust Atomics and Locks: Low-Level Concurrency in Practice

#15
post #12

Earlier quoted context omitted.

> 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 :)

Re: Rust Atomics and Locks: Low-Level Concurrency in Practice

#17

Earlier quoted context omitted.

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

Re: Rust Atomics and Locks: Low-Level Concurrency in Practice

#18
post #10
post #3

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, doin…

> 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 s…

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.

Re: Rust Atomics and Locks: Low-Level Concurrency in Practice

#19
post #10
post #3

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, doin…

> 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 s…

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