[Animats]

Given that Priority Ceiling Protocol and Priority Inheritance are two common solutions used in real-time schedulers, I would like to understand why priority inversion is not a solved problem.

Because Windows and Linux are not designed for hard real time. There's a "rt_mutex" thing in Linux, which does priority inheritance, but it's not used much.

QNX took this seriously; it has priority inheritance not just for mutexes, but for interprocess messaging and I/O too. But it's a real-time OS. It passes through not only the priority, but the CPU quantum for non hard real time tasks. So a group of rapidly interacting processes are effectively scheduled as if they were one process which happens to cross address spaces.

On most non-real-time OSs, if you have a microservices-type program which is rapidly passing control back and forth between multiple processes, it will work fine as long as there's spare CPU time. If there's no spare CPU time, performance suddenly drops badly. That's because the processes being released by mutex unlocks go to the end of the line for CPU time.

This is something microkernel designers take seriously, because it has a big impact on microkernel performance. Unikernel designers, not so much.

[RossBencina]

I agree, there are operating systems where few guarantees are made about protection from priority inversion, at least not without specific programmer intervention. As a programmer you need to be aware that priority inversion can be a thing.

However, this has no bearing on whether or not priority inversion is a "solved problem". "Solved problem" generally means that there are well known, widely studied technical solutions to a problem. My understanding right now is that priority inversion is a solved problem -- it is a standard topic in any introductory textbook on real-time systems with solutions that I stated. But maybe I'm wrong -- certainly the author seems to think so -- hence my question stands: I would like to understand why priority inversion is not a solved problem.

[MaxBarraclough]

Sorry to double-reply, but the paper I was thinking of was probably [0]

It seems very informative. Doesn't appear to be peer-reviewed, mind.

[0] http://www.cse.uaa.alaska.edu/~ssiewert/a320_doc/Yodaiken-20...

[MaxBarraclough]

> hence my question stands: I would like to understand why priority inversion is not a solved problem.

I believe it's because although complete solutions do exist, they have prohibitive overheads.

Annoyingly I can't find the relevant paper I'm thinking of.

[Dobiasd]

> I would like to understand why priority inversion is not a solved problem.

Maybe I just was not careful enough in choosing this phrasing when writing the article.

Do you think it would make sense if I change "but it's far from being solved once and for all." to "each of them with different upsides and downsides."?

[RossBencina]

Trade offs yes. I think I understand now that you meant that it is common that application-level priority inversion is not automatically avoided by the OS -- programmers still need to worry about it. Even if theoretical solutions exist, they may not be available on your chosen platform, or they may need to be manually configured (e.g. PTHREAD_PRIO_INHERIT).

[Dobiasd]

Thanks. I committed a change (https://github.com/Dobiasd/articles/commit/8ac8db11eb95de688...). Feel free to open a PR if you have a better phrasing in mind. :)

[useerup]

> Because Windows and Linux are not designed for hard real time.

True, although RT kernels have been developed for both.

Windows actually features Autoboost (Priority Inheritance). As Windows also has IO priority, the boost also applies to IO operations, boosting both the thread priority as well as the IO request priority of the lock owner, when a higher-priority thread blocks on a mutex owned by a lower-priority thread.