Even more. In my previous example if semaphore is posted from the interrupt we do not know which of TaskA or TaskB is no longer a "holder l" of a semaphore.
Best regards, Petro On Fri, Mar 31, 2023, 5:39 PM Petro Karashchenko < petro.karashche...@gmail.com> wrote: > 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. >> >> >>
