Linux-insides: Queued spinlocks in the Linux kernel
1–6 of 6 posts
Re: Linux-insides: Queued spinlocks in the Linux kernel
#2I've tried to read several entries in this series, but the typos, grammatical errors, and generally poor visual styling turn me off each time. :(
It's a shame, because there's obviously oodles of great content here, but I just can't get past the presentation.
I suppose I should do some editing and send PRs, but that's not my idea of a fun Sunday anymore. shrug
Re: Linux-insides: Queued spinlocks in the Linux kernel
#3I really enjoy this series. As someone who has begun writing kernel code somewhat recently, it's been immensely helpful. I hope that the author continues to writes these, and I'm looking forward to the coverage of the RCU.
Re: Linux-insides: Queued spinlocks in the Linux kernel
#4I've tried to read several entries in this series, but the typos, grammatical errors, and generally poor visual styling turn me off each time. :( It's a shame, because there's obviously oodles of great content here, but I just can't get past the presentation. I suppose I should do some editing and send PRs, but that's not my idea of a fun Sunday anymore. shrug
There are some pretty glaring factual errors too. Found this one (extra "not") just glancing through, although someone not familiar with the idea might get mislead:
So if the first thread started to execute this instruction, second thread will wait until the first processor will not finish.
Re: Linux-insides: Queued spinlocks in the Linux kernel
#5I've tried to read several entries in this series, but the typos, grammatical errors, and generally poor visual styling turn me off each time. :( It's a shame, because there's obviously oodles of great content here, but I just can't get past the presentation. I suppose I should do some editing and send PRs, but that's not my idea of a fun Sunday anymore. shrug
There are some pretty glaring factual errors too. Found this one (extra "not") just glancing through, although someone not familiar with the idea might get mislead: So if the first thread started to execute this instruction, second thread will wait until the first processor will not finish.
Submit a PR, maybe? :)
Re: Linux-insides: Queued spinlocks in the Linux kernel
#6I really enjoy this series. As someone who has begun writing kernel code somewhat recently, it's been immensely helpful. I hope that the author continues to writes these, and I'm looking forward to the coverage of the RCU.
I also started writing Linux kernel code a while ago and the one thing that I found really hard to follow was the locking hierarchies. It's not completely clear what protects what, and especially when you have two mutually exclusive locks (like a global lock and a lock for a specific variable) and you have to make sure you only grab one. RCU was much simpler to use. But my main worry with series like these is that they'll get out of date very quickly, but I mainly read them to understand the context of "how does this code differ in execution context to userspace code?". This series is very helpful in this regard.