> 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.
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.