Solution from the article: Don't fiddle with thread priorities.
Solution that works well in real life: Use lock-free (or, better still, wait-free) data structures.
The trick is that, for those of us in the devices and media world, and despite not always using RT schedulers, we generally need (largely) consistently prioritized performance for critical operations. For example, I actually need my device audio buffer callback to be timely to avoid displeasing gaps.
How have whole industries managed to deliver sellable products in these spaces without resorting to RT kernels? In many cases, careful uses of thread priorities and, yes, mutexes, have been involved.
This article feels like it was written by someone half-way through:
Junior engineer: Just use thread priority.
Senior engineer: No! Thread priority is a minefield.
Principal engineer: We're going to carefully walk through this minefield.
It would be nice though if media and games could get soft real time guarantees so as to avoid priority inversions on things like the Spotlight indexer.
I got dinged on a performance review once at Apple for negatively comparing the MacOS process and IO schedulers to Linux while I was working on Final Cut/QuickTime 10 years ago. Apparently "why can't we adapt their algorithm to our stuff, it's not a secret" is not constructive enough.
To be fair, the author says to not fiddle with priorities if possible
> Conclusion: If possible, avoid headaches by just not fiddling around with thread priorities.
I often see developers using complex and potentially dangerous techniques, when there are simpler options available. I imagine that's what the author is warning against
> This article feels like it was written by someone half-way through [...]
You might be right. I'm not a principal engineer. :)
The first solution in the wild we came up with back then when confronted with this problem, actually was to use a lock-free queue. Only later we figured out, that we did not need the prioritizing after all, and our software worked just fine with all threads having the default priority.
Jr./Sr./PE is just a strawman for illustrative purposes. No ranking aspersions intended... In order I've been SDE, Sr. SDE, Senior PE, Sr. SDE, PE... It's pretty meaningless outside of the scope of one company's system.
There are plenty of hardware/software systems out there that leverage thread priority to keep low latency operations humming along (e.g. clearing a hardware FIFO) or keep background operations out of the way (ish) when the system is heavily loaded.
The interactions between threads are often sparse and directional (e.g. producer/consumer) in a reasonably designed system. Needing to play with priority to govern the interaction's between one's own internal thread boundaries can be a bad code smell. Using it to better satisfy external restrictions (e.g. user input, hardware interaction, callback handling) isn't too uncommon if you want to maximize the utility of your hardware.
Solution that works well in real life: Use lock-free (or, better still, wait-free) data structures.
The trick is that, for those of us in the devices and media world, and despite not always using RT schedulers, we generally need (largely) consistently prioritized performance for critical operations. For example, I actually need my device audio buffer callback to be timely to avoid displeasing gaps.
How have whole industries managed to deliver sellable products in these spaces without resorting to RT kernels? In many cases, careful uses of thread priorities and, yes, mutexes, have been involved.
This article feels like it was written by someone half-way through:
Junior engineer: Just use thread priority.
Senior engineer: No! Thread priority is a minefield.
Principal engineer: We're going to carefully walk through this minefield.