(at least on commodity desktop Linux with stock settings)
This is a followup to the previous post about spinlocks. The gist of the previous post was that spinlocks has some pretty bad worst-case behaviors, and, for that reason, one shouldn’t blindly use a spinlock if using a real mutex or avoiding blocking altogether is cumbersome.
In the comments, I was pointed to this interesting article, which made me realize that there’s another misconception, "For short critical sections, spinlocks perform better".
Until today, I haven’t benchmarked any mutexes, so I don’t know for sure. However, what I know in theory about mutexes and spinlocks makes me doubt this claim, so let’s find out.
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 in Rust with #[no_std],
- priority inversion,
- CPU interrupts,
- and a couple of neat/horrible systemsy Rust hacks.
View all tags