✳flâneur — a map of the web's best reading

Spinlocks Considered Harmful

matklad.github.io · 2,496 words · saved by 1 readers

In this post, I will be expressing strong opinions about a topic I have relatively little practical experience with, so feel free to roast and educate me in comments (link at the end of the post) :-) Specifically, I’ll talk about: I maintain once_cell crate, which is a synchronization primitive. It uses std blocking facilities under the hood (specifically, std::thread::park), and as such is not compatible with #[no_std]. A popular request is to add a spin-lock based implementation for use in #[no_std] environments: #61. More generally, this seems to be a common pattern in Rust ecosystem: For example, the lazy_static crate does this: github.com/rust-lang-nursery/lazy-static.rs/blob/master/src/core_lazy.rs I think this is an anti-pattern, and I am writing this blog post to call it out. A Spinlock is the simplest possible implementation of a mutex, its general form looks like this: Why we need Ordering::Acquire and Ordering::Release is very interesting, but beyond the scope of this articl

Happy new year 🎉! In this post, I will be expressing strong opinions about a topic I have relatively little practical experience with, so feel free to roast and educate me in comments (link at the end of the post) :-) Specifically, I’ll talk about: spinlocks, spinlocks in Rust with #[no_std] , priority inversion, CPU interrupts, and a couple of neat/horrible systemsy Rust hacks. Context I maintain once_cell crate, which is a synchronization primitive. It uses std blocking facilities under the hood (specifically, std::thread::park ), and as such is not compatible with #[no_std] . A popular req

Explore this link on the map →

saved by

related reading