BTW, https://github.com/apache/nuttx/pull/5070 report that the system will
crash if the priority inheritance enabled semaphore is waited or posted
from different threads.
True. sem_post should fail if priority inheritance is enabled and the
caller is not a holder of a semaphore count. That
Same problem as
https://nuttx.yahoogroups.narkive.com/3hggphCi/problem-related-semaphore-and-priority-inheritance
On 3/31/2023 2:19 PM, Xiang Xiao wrote:
When the priority inheritance is enabled on a semaphore, sem_wait will add
the current thread to the semaphore's holder table and expect that
When the priority inheritance is enabled on a semaphore, sem_wait will add
the current thread to the semaphore's holder table and expect that the same
thread will call sem_post later to remove it from the holder table.
If we mess this fundamental assumption by waiting/posting from different
threads
Xiang Xiao, is that still true for the latest code in master branch?
And by "system will
crash if the priority inheritance enabled semaphore is waited or posted
from different threads" do you mean at the point of sem_post/sem_wait or
some system instability in general?
Best regards,
Petro
On Fri
BTW, https://github.com/apache/nuttx/pull/5070 report that the system will
crash if the priority inheritance enabled semaphore is waited or posted
from different threads.
On Sat, Apr 1, 2023 at 3:20 AM Xiang Xiao wrote:
>
>
> On Sat, Apr 1, 2023 at 12:34 AM Gregory Nutt wrote:
>
>> On 3/31/202
On Sat, Apr 1, 2023 at 12:34 AM Gregory Nutt 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 rig
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 prohib
> On Mar 30, 2023, at 3:23 PM, Gregory Nutt 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 Docu
On Fri, Mar 31, 2023 at 6:31 PM Nathan Hartman wrote:
> In "[Breaking change] Move nxmutex to sched" there was a more general
> discussion about our development priorities: What is most important to
> us about NuttX?
>
> I'm pulling out this part of the discussion to a new thread, to avoid
> cloggi
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
In "[Breaking change] Move nxmutex to sched" there was a more general
discussion about our development priorities: What is most important to
us about NuttX?
I'm pulling out this part of the discussion to a new thread, to avoid
clogging up the nxmutex discussion...
For context, with my replies bel
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
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 ac
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. Her
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 activi
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
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
Yes and No. For counting semaphores we have multiple holders for example
with priorities 10, 50 and 90. Now a task with priority 100 comes and wants
to take a semaphore. Priority which of the holders should be increased? The
lowest or the highest holder? With a real-time point of view it should
Yes and No. For counting semaphores we have multiple holders for example
with priorities 10, 50 and 90. Now a task with priority 100 comes and wants
to take a semaphore. Priority which of the holders should be increased? The
lowest or the highest holder? With a real-time point of view it should be
Migration to nxmutex is quite a big effort and unfortunately recently I
didn't have much time to deep dive into this. In general I support an
initiative and do not see a use case for priority inheritance for regular
semaphores, so I think we should clean-up priority inheritance code for the
reg
Hello,
Migration to nxmutex is quite a big effort and unfortunately recently I
didn't have much time to deep dive into this. In general I support an
initiative and do not see a use case for priority inheritance for regular
semaphores, so I think we should clean-up priority inheritance code for the
Hi
I still have problems by compiling a NuttX project using the exported
libraries and the Makefile usually used to compile other targets under
pysimCoder.
I've recompiled the .ld files as ld.tmp and the I changed the name to
.ld again in order to find them in my Makefile... I don't know if
22 matches
Mail list logo
