Sorry for been not clear. Here is a better description: 2 DMA channels accountable by a counting semaphore. The semaphore is posted by DMA completion interrupt. TaskA with priority 10 allocates DMA0 channel and starts DMA activity. TaskB with priority 20 allocates DMA1 channel and starts DMA activity. TaskC with priority 30 wants to allocate a DMA channel, so boosts priority of TaskA and TaskB to 30 (even if that will not lead to fasted DMA operation completion). DMA1 completes and posts semaphore, so TaskC gets it and TaskA and TaskB priorities are restored.
Best regards, Petro On Fri, Mar 31, 2023, 5:26 PM Gregory Nutt <spudan...@gmail.com> wrote: > > > I still see more questions than answers. As semaphores can be posted from > > the interrupt level. Let's take next example: > > The counting semaphore manages DMA channels. > > Task allocates a DMA channels and takes counting semaphore (becomes a > > holder), but posting a semaphore is done from DMA completion can back as > > channel is freed there. The holder task may still do some activities on > the > > background while DMA is working. But current priority boost schema will > > rise it's priority (even if boost will not lead to faster posting of a > > semaphore). This is more theoretical description, but describes the state > > of problem. > > > > I think we can task about inheritance only if take/post are done from > task > > level and currently only mutex ensure that. > > That is not true. Posting from an interrupt never boosts priority and, > hence, never causes inheritance of priority. It can only cause a drop / > restoration in priority. That may result in context switches which can > be done from the interrupt level with no problem. I don't see any > issue. Certainly this works, it is done often and works very well. > > This is an important feature of the real time behavior. We can't lose > this behavior. > > >
