Hi,
I am not sure whether it is necessary to separate mutex and semaphore
(although I do see the performance gain that it would give for mutex),
but there is another related topic I would like to raise.
Currently, the semaphores don't work (at all) for CONFIG_BUILD_KERNEL.
The simple reason is that the semaphores are allocated from the
user-mapped memory, which is not always available for the kernel while
scheduling or in interrupts. At the time when it is needed, there may be
another memory map active for mmu.
There is also an issue with performance; every semaphore access needs to
go to the kernel through syscall, although in principle the semaphore
counter handling alone doesn't need that if the compiler & hw has the
necessary atomic support.
We are especially interested in having real-time behaviour (priority
based scheduling, priority inheritance...) AND running
CONFIG_BUILD_KERNEL. We have used some methods to circumvent the issue,
but for those I am not going into details as we don't have a publishable
implementation ready.
A tempting way to fix the problem (which we didn't try out yet) would be
separating the semaphores in two parts, kernel side structure and the
user side structure. Something that zyfeier also did with the "futex"
linux-like implementation. But, also this kind of implementation should
be real-time - so when there is access to the semaphore via syscall
(e.g. when the semaphore blocks), or when scheduling, the kernel must
have O(1) access to the kernel side structure - no hashing / allocating
etc. at runtime.
So to summarize, for CONFIG_BUILD_KERNEL the semaphores could *perhaps*
work like this (this is not yet tried out, so please forgive me if
something is forgotten):
- User-side semaphore handle would have the counter and a direct pointer
(handle) to the kernel side structure (which can be passed to kernel in
syscall).
- Kernel side structure would have the needed wait queue and sem holder
structures (and flags?)
- Kernel side structure would be allocated at sem_init (AND if it was
not initialized, allocate it at the time when it is needed?). To achieve
real-time behaviour one should just call sem_init properly at startup of
the application.
- Kernel side structures would be listed in tcb and cleaned up at
task_group exit. Also some hard limit/management for how much kernel
memory can one process eat from kernel heap is needed.
- Counter manipulation can be handled directly in libc in case compiler
supports proper atomic operations, or syscall to kernel when there is no
support available (this would be just performance optimization - next phase)
Whether it is feasible to do it only for CONFIG_BUILD_KERNEL, or as a
common implementation for all build modes, I didn't think of yet. I am
also not sure whether the re-design of semaphore could also lead to
better wrapping of it for mutex use, but this is also possible. In that
case it could *maybe* solve the performance issue zyfeier tried to tackle.
This is just one idea, but somehow the problem of not working semaphores
in CONFIG_BUILD_KERNEL should be tackled. I wonder if this is something
we should experiment with? If someone is interested in such an
experiment, please let me know. Or if someone is interested in doing
this experiment, please let me know as well, so we don't end up doing
duplicate work :)
Br,
Jukka
Ps. I think that in the current implementation the nxmutex code is
inlined everywhere, increasing code size. Not a huge issue for me, but
increasing code size should be managed....
On 7.4.2023 5.18, zyfeier wrote:
Thank you very much for the example you provided. What I want to point
out is that this is not just about " just delete / replace what is
already out there working fine ". Due to the multi-holder of the count
semaphore, the performance of the mutex is much worse than other RTOS
(with a performance gap of 10%), but these operations are not
necessary for the mutex. That's why there is an idea to separate the
mutex and semaphore.
However, if everyone thinks that separating the mutex and semaphore is
a bad idea, then we need to think of other methods. Do you have any
better methods to offer?
从Windows 版邮件 <https://go.microsoft.com/fwlink/?LinkId=550986>发送
*发件人: *Tomek CEDRO <mailto:to...@cedro.info>
*发送时间: *2023年4月6日22:36
*收件人: *dev@nuttx.apache.org
*主题: *Re: [Breaking change] Move nxmutex to sched
On Thu, Apr 6, 2023 at 2:58 PM Gregory Nutt wrote:
> Oh my God! That sounds terrible! Does this change actually do
> /anything /positive.
Look Zyfeier, its not that we oppose development, we want the
development to done the right way that will bring elegant coherent
standard compliant solution as a result :-)
Aside from my previous remark on Linux (along with other commercial
OS) "enforced changes", lets think about Greg's "does this change
actually do /anything /positive" question with another example.
Take a looks at WS2812 RGB Smart LED. They decided to introduce "an
innovation" by changing the Pin1 marking on the casing and put that
mark on pin 3 instead. Whole world use Pin1 marking to quickly align a
component pinout, so at first glance you can see where is the pin 1 of
the component, also most chips use VCC there so you can quickly
measure things, nothing fancy, everyone knows that. Now take a look at
the pcb design footprint (bottom layer mirrored) and the led datasheet.
You can clearly see that putting Pin1 casing mark on pin 3 is a
terrible idea, even more that chip is symmetrical, so it will lead to
bad placing and reversed power supply. Sure, this is some innovation,
but world does not work that way and everyone just gets confused. When
you make such changes to other components a design becomes incoherent
and no one will then know anything, but look how many (fake)
"innovations" just showed up.
This is why solid coherent standardized fundamentals / foundations of
technology is so important. So we "just know" things intuitively, and
we can work together to improve things worldwide in a systematic
fashion, solid brick after solid brick, evolution not revolution. You
cannot just delete / replace what is already out there working fine.
Example above is about electronic component, but with the software is
exactly the same, it is good to stick to well adapted standards, add
your own brick on top of solid inviolable fundamentals / fundation,
not necessarily following the quickly changing fashions and trends
with a lifespan of a yogurt, not spreading bad habits from other
environments, that will result in far better solution that is coherent
and long term maintainable. That results in a solid foundation for a
good system / device / solution / product.
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
