I drafted some optimization in https://github.com/apache/nuttx/pull/8951 I would appreciate some support with that if possible as these days I'm a bit overloaded.
Best regards, Petro сб, 1 квіт. 2023 р. о 23:35 David S. Alessio <david.s.ales...@gmail.com> пише: > > > > On Apr 1, 2023, at 12:54 PM, David S. Alessio <david.s.ales...@gmail.com> > wrote: > > > > > > > >> On Mar 31, 2023, at 9:34 AM, Gregory Nutt <spudan...@gmail.com <mailto: > spudan...@gmail.com>> wrote: > >> > >> On 3/31/2023 8:56 AM, Gregory Nutt wrote: > >>> > >>>> 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. > >>>> > >>> You are right. In this usage case, the counting semaphore is not > being used for locking; it is being used for signalling an event per > https://cwiki.apache.org/confluence/display/NUTTX/Signaling+Semaphores+and+Priority+Inheritance > < > https://cwiki.apache.org/confluence/display/NUTTX/Signaling+Semaphores+and+Priority+Inheritance > > > >>> > >>> In that case, priority inheritance must be turned off. > >>> > >> You example is really confusing because you are mixing two different > concepts, just subtly enough to be really confusing. If a counting > semaphore is used for locking a set of multiple resources, the posting the > semaphore does not release the resource. That is not the way that it is > done. Here is a more believable example of how this would work: > >> > >> 1. TaskA with priority 10 allocates DMA0 channel by calling a DMA > >> channel allocation function. If a DMA channel is available, it is > >> allocated and the allocation function takes the semaphore. TaskA > >> then starts DMA activity. > >> 2. TaskA waits on another signaling semaphore for the DMA to complete. > >> 3. TaskB with priority 20 does the same. > >> 4. TaskC with priority 30 wants to allocate a DMA channel. It calls > >> the channel allocation function which waits on the sempahore for a > >> count to be available. This boost the priority of TaskA and TaskB > >> to 30. > >> 5. When the DMA started by TaskA completes, it signals TaskA which > >> calls the resource deallocation function which increments the > >> counting semaphore, giving the count to TaskC and storing the base > >> priorities. > >> > >> The confusion arises because you are mixing the signaling logic with > the resource deallocation logic. > > > > > > Greg, quite right. But Petro himself pointed out: > >> 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). > > > > > > So what is the problem here for which Priority Inheritance is the > solution? > > > > Technically, there is priority inversion here, but 1) it’s not > unbounded, the channel will be free as soon as DMA completes; and 2) > boosting task priority will not reduce the latency of freeing a DMA channel. > > > > This scenario requires a counting semaphore that’s used as for signaling > HW resource availability; and if there are any blocked callers, the highest > priority caller is unblocked first. > > I should add: the DMA channel should be freed either 1) in the ISR > handling DMA interrupts after cleaning up HW, or if there’s a bit more work > to do in cleanup up after DMA, in a HP worker thread. > > In this way the handing of the DMA channel(s), counting semaphore; and > their blockers is completely independent of the priority of the caller. > > > > >
