Re: [Breaking change] Move nxmutex to sched
Hi, All: The main purpose of this PR is to separate mutex and semaphore and to improve the performance of mutex. Regarding the issues mentioned in the email , here is a summary: 1. The number of system calls will increase. After separating mutex and semaphore, futex support will be added in the next step, which can reduce the number of system calls. 2. Code size will increase. The increase in code size is a drawback of this modification, but the mutex performance has improved by 200 cycles. I think code size can be considered as a potential optimization item in the future. 3. Removing semaphore priority inheritance will affect real-time performance. Semaphore priority inheritance will be retained. After separating mutex and semaphore, they will have their own priority inheritance handling. Choose which one to enable according to your needs. Thanks. Yuan.
Re: [Breaking change] Move nxmutex to sched
Oh my God! That sounds terrible! Does this change actually do /anything /positive. Duplicating the internal implementation of Linux is /NOT /positive. It is irrelevant. Adopting GNU/Linux interfaces as a functional specification made since. But duplicating the ibnternal implementation of Linux is the dumbest thing I have ever heard. Losing any real time performance is /catastrophic /for an RTOS. Significantly increasing code size is /catastrophic /for an embedded OS. This is a very bad change that should never come into the repository. My recommendation is that you quietly close the PR without merge and be done with it. The solution that we want is: * One that conforms to interface standards * Results in the smallest footprint possible * Gives the best real time behavior possible. Nothing else should be accepted. On 4/6/2023 5:27 AM, zyfeier wrote: Hi, All: The main purpose of this PR is to separate mutex and semaphore and to improve the performance of mutex. Regarding the issues mentioned in the email , here is a summary: 1. The number of system calls will increase. After separating mutex and semaphore, futex support will be added in the next step, which can reduce the number of system calls. 2. Code size will increase. The increase in code size is a drawback of this modification, but the mutex performance has improved by 200 cycles. I think code size can be considered as a potential optimization item in the future. 3. Removing semaphore priority inheritance will affect real-time performance. Semaphore priority inheritance will be retained. After separating mutex and semaphore, they will have their own priority inheritance handling. Choose which one to enable according to your needs. Thanks. Yuan.
Re: [Breaking change] Move nxmutex to sched
I agree with Greg! If we can have stable operation of priority inheritance with semaphores then we can build mutex as a macro based wrapper (mostly as it is now). One thing that I can think of is adding a "mutex" attribute to a semaphore and creating a separate task list for faster scheduling, but even that is up to discussion with the community. Best regards, Petro чт, 6 квіт. 2023 р. о 15:58 Gregory Nutt пише: > Oh my God! That sounds terrible! Does this change actually do > /anything /positive. > > Duplicating the internal implementation of Linux is /NOT /positive. It > is irrelevant. > > Adopting GNU/Linux interfaces as a functional specification made since. > But duplicating the ibnternal implementation of Linux is the dumbest > thing I have ever heard. > > Losing any real time performance is /catastrophic /for an RTOS. > > Significantly increasing code size is /catastrophic /for an embedded OS. > > This is a very bad change that should never come into the repository. > My recommendation is that you quietly close the PR without merge and be > done with it. > > The solution that we want is: > > * One that conforms to interface standards > * Results in the smallest footprint possible > * Gives the best real time behavior possible. > > Nothing else should be accepted. > > On 4/6/2023 5:27 AM, zyfeier wrote: > > Hi, All: > > > > The main purpose of this PR is to separate mutex and semaphore and to > improve the performance of mutex. > > Regarding the issues mentioned in the email , here is a summary: > > > > 1. The number of system calls will increase. > > > > After separating mutex and semaphore, futex support will be added in the > next step, which can reduce the number of system calls. > > > > 2. Code size will increase. > > > > The increase in code size is a drawback of this modification, but the > mutex performance has improved by 200 cycles. I think code size can be > considered as a potential optimization item in the future. > > > > 3. Removing semaphore priority inheritance will affect real-time > performance. > > > > Semaphore priority inheritance will be retained. After separating mutex > and semaphore, they will have their own priority inheritance handling. > Choose which one to enable according to your needs. > > > > > > Thanks. > > Yuan. > > >
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. > > Duplicating the internal implementation of Linux is /NOT /positive. It > is irrelevant. > > Adopting GNU/Linux interfaces as a functional specification made since. > But duplicating the ibnternal implementation of Linux is the dumbest > thing I have ever heard. > > Losing any real time performance is /catastrophic /for an RTOS. > > Significantly increasing code size is /catastrophic /for an embedded OS. > > This is a very bad change that should never come into the repository. > My recommendation is that you quietly close the PR without merge and be > done with it. > > The solution that we want is: > > * One that conforms to interface standards > * Results in the smallest footprint possible > * Gives the best real time behavior possible. > > Nothing else should be accepted. Very strong +1 :-) No long stories here, but I know Linux is usually a first contact with the Open-Source world, on the other hand its also known to be a self-incompatible long term maintenance nightmare mainly because of "enforced changes ideology" (that comes from Microsoft) or "new is better" approach, so following Linux is like never ending chasing the rabbit story (i.e. look at changing kernel API every minor release that forces you to constantly update something that is already out there working fine, or lots of Linuxisms in the open source software that makes it hardly portable along other POSIX OS while you will always hear "works for me" or "not my fault" or "switch to Linux" viral mantras). Its like JavaScript frameworks that have lifespan shorter than a yogurt, would you build on top of that amazingly popular "solutions" yourself? Lets stick to good old Unix fashion that works for for decades already and will hopefully fork for decades ahead providing simple coherent long term maintainable building blocks. Lets keep NuttX Unix in the RTOS world :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: [Breaking change] Move nxmutex to sched
On 4/6/2023 9:03 AM, Petro Karashchenko wrote: Yes. The main "mutex" attribute differentiating it from a binary semaphore is that it can be released only by a holder thread (even if priority inheritance is not enabled). And that is for the basic mutex, but recursive mutex also allows nested "obtain". So "recursive mutex" is not 1-to-1 the same as binary semaphore. It is implemented some very simple, trivial logic on top of a binary semaphore. I see that more as an add-on behavior to the basic locking operation. I don't think it generates a different class of lock.
Re: [Breaking change] Move nxmutex to sched
On 4/6/2023 9:09 AM, Petro Karashchenko wrote: Also pthread_mutex is a solution for user space, but would be good to have something similar for kernel space. During adding nxmutex wrapper to the code many misuse issues were identified, so it is adding safety during coding and does not allow misuse. Of course a binary semaphore is a solid building block, but leaving it alone just increases the probability of errors in code. Otherwise POSIX would not add pthread_mutex and would extend semaphores. I mean that the need of it seems to be obvious since pthread_mutex are a part of POSIX side by side to semaphores and it would be good to have something like pthread_mutex for kernel. That is not a very compelling argument. All of the pthread interfaces exist only because they operate on pthreads and require pthread_t to identify the pthread. The pthread IDs only exist within a "process." semaphores have no inherent identification associated with them and have a global scope that can work across different "processes." There are no "processes" in NuttX; we emulate them in the FLAT build with tasks. A task is just a thread. In NuttX, we use "heavy weight" threads: A pthread is really the same as a task; it bound to the task group only via the shared group_s structure. It is all smoke and mirrors to get POSIX compatibility. Underneath, a pthread and a task is the same; a mutex and a semaphore is the same. Trying to make distinctions internally when there are none cannot lead to good design decisions. [Linux, uses light weight threads which are something very different] Trying to force them to be different is very artificial. It is similar to the artificial designation of some task as threads. But at least that was done to meet the functional interface specification. Mutexes are, similarly, just semaphores. Again the exist only to meet POSIX requirements for pthread interfaces to go with the fake pthreads. There is absolutely no reason to make some implementation distinction between them other than to meet the letter of the POSIX requirement. Building another fake internal infrastructure does not seem like something that is in our best interest.
Error by make export by extensa ESP32
Hi I've finally reached to generate code for ESP32 using pysimCoder. My board is a OLIMEX ESP32-POE board, Starting from the esp32-devkitc:wifinsh configuration we set CONFIG_ARCH_CHIP_ESP32WROOM32=y and the generation of the nuttx code is ok. The problems start when I do a "make export": The exported file doesn't contain the libraries provided under nuttx/arch/xtensa/src/esp32/esp-wireless-drivers-3rdparty/libs/esp32/ and the Make.defs script doesn't integrate these libraries in the link. After setting these libs manually and after defining HEAD_OBJ = esp32_start.o esp32_wdt.o in Make.defs, the generation of the binary file seems to be ok (not tested yet on the processor) Ciao Roberto
