Live data from Hacker News

Rust Atomics and Locks: Low-Level Concurrency in Practice

marabos.nl

1–10 of 48 posts

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

#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, 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

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

#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 algorithm below for sending messages between threads.

I want my async/await tasks to be eager and run in their own threads. So if I do this

  handle1 = async task1();
  handle2 = async task2();
  handle3 = async task3();
  // at this point in time, the token ring thread pool shall be running 3 tasks in parallel
  return1 = await handle1;
  return2 = await handle2;
  return3 = await handle3;
I believe other languages do not run CPU bound async/await computations on a thread except for IO.

I wrote an unrolled state machine for my async/await in Java. This models a simple async/await program and runs tasks on other threads - without locks. I use a design I call token ring parallelism, where threads take turns and are linked together in a ring structure. A semaphore communicates write status along the ring. The plan is to write a transpiler to generate the switch statements automatically. Then any language with threading can have async await support even if it is not native.

https://github.com/samsquire/multiversion-concurrency-contro...

I wrote a own lock free algorithm here that I use to do message passing between actor threads. My goal is high throughput performance and low latency.

https://github.com/samsquire/multiversion-concurrency-contro...

With 11 threads (on a 12 core processor, deliberately left one core for Windows) I get

This code with 100 threads, gets 114657500 total requests 22079241.286347 requests per second Time taken: 5.193000

166512180 total requests 33249237.220447 requests per second Time taken: 5.008000

For a lock based benchmark with 100 threads, I get:

16307090 total requests 3246484.172805 requests per second

With 11 threads, the lock benchmark gets

178770160 total requests 35732592.444533 requests per second Time taken: 5.003000

Each request is a synchronization event that sends 10 messages in a loop or adds 10 to a counter to represent the synchronization event.

There's probably problems with my measuring methodology, I am doing the simplest possible thing that shall work. I am trying to show that my lock free algorithm scales even with heavy contention.

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

#6
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

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

#8
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…

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

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

#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 safety mechanisms, so I don't need to ever know about atomics or locks.

Post reply on HN