Hello Greg, I already wrote that my example is more theoretical and may be a "bad design", but it illustrates the issue in the current code. Please understand me right, I'm not against having priority inheritance available for semaphores. I just want to have things well defined and possibly prohibit / catch a bad usage. Like mutex usually have a holder field and only a holder of a mutex can release it. That is basically not true for semaphores. I would be happy if: 1. sem_post() would assert on an attempt to call it from interrupt with a semaphore that has priority inheritance enabled. 2. sem_post() would assert if the caller task is not in a holder list of a semaphore that has priority inheritance enabled. But unfortunately that is not true now and currently "nxsem_release_holder" just decrements a holder count of a random holder if caller TCB is not in a holder list.
What I'm trying to say is that calling sem_wait/sem_post from task context is essential for priority inheritance and there is a hole here currently. I'm ok with building a kernel mutex as a wrapper on top of the "fixed" semaphores with priority inheritance that will do some additional checks if needed. Regarding a "pile of shit" and real-time behavior I agree that determinism is a key, but want to use some terms here. The RTOS vs OS difference is that RTOS implements scheduling using rate monotonic scheduling (RMS) and that is mathematically proven by RMA. That is how determinism is achieved. If we get back to the example with counting semaphore and the case of "ALL holders are boosted to the priority of the highest priority waiter". What is the impact on RMS here? The priority inheritance for mutex (a binary semaphore case) was intended to minimize impact on RMS when an exceptional situation happens. So in the case of a few holders, how does creating a pool of concurrent tasks with the same priority improve determinism? Or maybe exactly this makes RTOS a "pile of shit"? Personally I do not have a clear answer and this is more expressing my thoughts here. I really think that at the end of this discussion we will have some good results that will lead to an improvement. Best regards, Petro пт, 31 бер. 2023 р. о 20:56 David S. Alessio <david.s.ales...@gmail.com> пише: > > > > On Mar 30, 2023, at 3:23 PM, Gregory Nutt <spudan...@gmail.com> wrote: > > > > > In his Confluence paper on "Signaling Semaphores and Priority > Inheritance”, Brennan Ashton’s analysis is both thorough and accurate; ... > > > > Minor fix. I wrote the paper, Brennan converted the Confluence page > from an older DocuWiki page > > Hi, Greg, I should have known! > Cheers, > -david > >
