> victor yodaiken wrote a nice article on why priority inheritance as a > way of handling priority inversion isn\\\'t a particularly attractive > solution.
I read this article, but I am not convinced. The only argument against using priority inheritance is that it is supposed to have poor performance. If that is true, then perhaps using priority ceiling is better. For audio applications this would probably be easy, since they are not that complex. An examples situation for using priority inheritance might be porting a read/write audio i/o application to a callback based interface without too much effort. This can\\\'t in the general case be done without adding latency, if there is no blocking allowed in the callback function. But why not block? It takes time , but it has a worst case bounded execution time. Yet only if there is no priority inversion. And the only way to prevent that, without knowing the priority of the callback function, is using priority inheritance. (of course the read/write thread might want to be running high priority SCHED_FIFO already in which case a normal mutex would work also). I think the article has some good examples of when not to use priority inheritance, but there are still situation where using it is ok. What do we have now to handle priority inversion in Linux? We haven\\\'t got priority ceiling or priority inheritance. Should we set a high priority just before acquiring a mutex that is used by a high priority thread and lower the priority after it is released? Is this as efficient as priority ceiling? Is any design where a high and a low priority thread share access to some resource flawed? If the article is saying the programmer should be protected from missuse of priority inheritance by not supplying it, isn\\\'t that like Pascal? (I never liked Pascal). --martijn Powered by ASHosting
