Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust Atomics and Locks: Low-Level Concurrency in Practice

marabos.nl

Post reply on HN
Print view View original

31–40 of 48 posts

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

#31

Post by remexre »

gavinray wrote: post #22

I'm curious how folks in Rust implement striped-locking? Striped locking is where you chunk sections of data behind the same lock to improve scalability. So, 1 lock might protect 1,000 items in an array, for example.

First thing that'd come to mind for me would be replacing the unstriped Vec> with some wrapper like:

    struct Striped(Vec>, Mutex>);
I think I'd probably want a wrapper either way to ensure I'm always taking locks in a particular order to avoid deadlocks, anyway.

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

#32

Post by Dopameaner »

samsquire wrote: post #5

Thanks for putting the time and extensive effort into this book. I am deeply interested in concurrency, asynchrony and parallelism I even journal about it everyday on my GitHub journal ideas repository (see my profile) I've been talking on the r/programminglanguages discord about syntax for async/await. I am writing a programming language that has parallelism as a first class citizen. I use this actor2.java lock free…

Out of curiosity, How do you benchmark your algorithms.

> e.g, This is another parallel multithreaded actor model. Run Actor2.java to run it. I get around 1.1 billion requests per second with this model.

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

#33

Post by tick_tock_tick »

gavinray wrote: post #22

I'm curious how folks in Rust implement striped-locking? Striped locking is where you chunk sections of data behind the same lock to improve scalability. So, 1 lock might protect 1,000 items in an array, for example.

Realistically you don't unless you really really need it. If you really need it you drop to unsafe and build a "safe" interface in-front of it.

Rust makes writing very high performance multi-threaded code incredibly hard because most of the tricks to get that last bit of performance out are basically asking to generated races and are near impossible to express in a way that is provably safe. You basically thinking of your data-layout from day one if you need that kind of performance your just going to have to deal with a bunch of unsafe in your codebase.

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

#34

Post by 63 »

I'm interested in the concept of concurrency, but is there anywhere that it would be useful outside of scientific applications and operating systems? It feels like a powerful paradigm to master but I'm just not sure it's worth the investment for the average developer.

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

#37

Post by maxbond »

63 wrote: post #34

I'm interested in the concept of concurrency, but is there anywhere that it would be useful outside of scientific applications and operating systems? It feels like a powerful paradigm to master but I'm just not sure it's worth the investment for the average developer.

For what it's worth, if I hadn't learned about low-level concurrency primitives in Rust, I wouldn't have had the mental framework to succeed in creating a realtime websocket service in Python.

My two cents is that learning is enriching and inspiring. If you learn concepts from one context you can apply them in another in new and surprising ways. Don't put yourself in a box like "I'm just a normal developer, I don't know about that OS stuff"; learn about the things that excite you and worry about applying them later. Specialization is for ants.

But if this advice isn't useful to you, feel free to discard it.

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

#38

Post by kevinossia »

63 wrote: post #34

I'm interested in the concept of concurrency, but is there anywhere that it would be useful outside of scientific applications and operating systems? It feels like a powerful paradigm to master but I'm just not sure it's worth the investment for the average developer.

I've used tons of concurrency in Android apps, iOS apps, Unreal Engine games, C++ code running a Raspberry Pi drone, embedded Android telemetry (Java/C++), and C++ AR/VR high-resolution realtime media streaming systems.

If you can wield concurrency, you can use it anywhere. It's liberating to be able to drastically improve the performance of your code by leveraging the multi-core processors our software runs on these days.

I've never done any OS work nor scientific computing.

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

#39

Post by yazaddaruvala »

63 wrote: post #34

I'm interested in the concept of concurrency, but is there anywhere that it would be useful outside of scientific applications and operating systems? It feels like a powerful paradigm to master but I'm just not sure it's worth the investment for the average developer.

It’s a common misconception but there is a difference between concurrency and parallelism.

Concurrency is very useful across all aspects of the stack including OS code, and even web app code.

Your comment about “usefulness” is likely about Parallelism. Which I agree with you is typically only useful in abstractions like OS code and even web frameworks.

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

#40

Post by seanhunter »

mrkeen wrote: post #10
estebank wrote: 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…

Maybe the book isn't for you then. Not every book has to be.
Post reply on HN