Paul McKenney once wrote:
Despite such complications, priority inheritance works reasonably well for exclusive locks, and is a major component of Ingo Molnar’s CONFIG_PREEMPT_RT patch. There are strongly held opinions both for and against priority inheritance, for example. http://www.linuxdevices.com/articles/AT7168794919.html
in which Victor Yodaiken considers priority inheritance to be harmful, and, as near as I can tell, soft realtime to be irrelevant. […] The big advantage of priority inheritance is that it is simple for its users. Use of priority inheritance does degrade scheduling latency compared to a carefully hand-crafted solution, and priority inheritance’s implementation is difficult for reader-writer locks, to say nothing of memory allocation or communications primitives.Nevertheless, priority inheritance does seem to have a significant role to play in mainstream “metal hard” realtime. It is not perfect, but, then again, what is?
And I think this is a good summary of the differences between the “soft”( muddle through) and “hard” (design properly) approaches to real-time. In FSMLabs design approach, “simple for users” is good, but not good enough to overcome “doesn’t work reliably”. Priority inheritance itself is not a big deal: we can add it, and have added it, as a more complicated mode for mutexes when needed to make legacy code port. But in our world, correctness is more important than convenience. Perhaps only highly qualified engineers who understand timing should write real-time code directly: others can use pre-made components or automatic tools (like Matlab simulink) or wait until there are more advanced test tools. The idea of using an engineering technique known to be incorrect simply because it is convenient, is I think an indication of the weak state of software engineering. This same caution applies elsewhere: the effects of kernel programmers trying to write web pages or source code management methods on the fly are also not pretty. It would be convenient if I could develop data base systems without understanding data base theory – but I can’t. McKenney’s “despite such complications” follows a note of some of the fatal problems I had covered in the cited article and elsewhere – but a solution to these problems is nowhere found.
The weakness of the soft real-time approach results in the weakness of the PREEMPT_RT systems in Linux (although it is clear that the developers are starting, finally, to copy a working solution – RTLinux and to slowly abandon their design.) Anyways, a draft analysis of what is wrong with PREEMPT_RT can be found here. Although I doubt McKenney is consciously modifying his argument on the basis of the business model of his employer, it is interesting to consider who profits from a technology that requires customers to both purchase large amounts of engineering services (to tune and configure) and to over-specify hardware.