>My opinion is that we have to respect the requirements for deterministic
>real-time behavior, even though that implies the addition of certain
>non-standard interfaces. Otherwise we lose our identity as a real time
>operating system and the applications I am doing with NuttX (and I'm sure
>many other people) will not be possible.
>
>That said, I also very much like that NuttX strives for standards
>conformance. For me, this means that most non-real-time code can be
>developed and tested on a PC with a faster code-compile-debug cycle than
>embedded and then moved over to embedded when it's ready. This has been a
>huge productivity boost for me (and I'm sure, once again, for many other
>people).
>
>How, then, do we satisfy both needs?
>
>I think the answer is that as long as standard functions behave like the
>standards and practices expect, and deviations from the standards use
>identifiers that do not collide with the standards, both needs are
>satisfied well. Applications that do not utilize our real time "extensions"
>will not notice the difference, and applications that do utilize them will
>meet real time requirements as needed.
>
>I think that in large part we are already doing exactly that, so there
>isn't really a problem that needs fixing here.
>
>I don't know the details of this specific PR yet, so I am just giving my
>opinion about the premise of NuttX in general.
Hi, All:
I have also submitted the code that will be optimized next. The PR is as
follows:
https://github.com/apache/nuttx/pull/8743
The main reasons for removing priority inheritance from the semaphore are as
follows:
1. "Signaling semaphore" does not need to support priority inheritance.
After modification, nxsem only handles signaling semaphore.
Some RTOS I have seen, such as Zephyr, also handle it this way.
2. It is beneficial to optimize the processes related to priority inheritance.
From the results of my optimization, the optimization effect is very
obvious.
Thanks.
Yuan
