Re: [Breaking change] Move nxmutex to sched

Hi, just to add that in the normal case obviously the correct process *is* running when the semaphore is accessed (sem_wait(), sem_post()), but there is one exception: sem_waitirq() which is called either by the watchdog ISR or by the signal dispatch logic. In this case most likely the correct

Re: [Breaking change] Move nxmutex to sched

I believe that all of the lists and structures that you are concerned with are already allocated from kernel space memory, but I have not The lists do exist in user memory, although I agree that they should not. Then that is a bug.  It is a serious security error if OS internal data struct

Re: [Breaking change] Move nxmutex to sched

Hi, just to add that in the normal case obviously the correct process *is* running when the semaphore is accessed (sem_wait(), sem_post()), but there is one exception: sem_waitirq() which is called either by the watchdog ISR or by the signal dispatch logic. In this case most likely the correct proc

Re: [Breaking change] Move nxmutex to sched

Hi, thanks again for the responses and bearing with me > I believe that all of the lists and structures that you are concerned > with are already allocated from kernel space memory, but I have not The lists do exist in user memory, although I agree that they should not. > verified that it all c

Re: [Breaking change] Move nxmutex to sched

However, as I said, there are some things in the sem_t structure whose usage is ubiquitous and I don't know if the scalar access macros will be enough, i.e. I don't fully understand how they work / are supposed to work. ... I believe that all of the lists and structures that you are concern

Re: [Breaking change] Move nxmutex to sched

On 4/19/2023 3:33 AM, Ville Juven wrote: However, as I said, there are some things in the sem_t structure whose usage is ubiquitous and I don't know if the scalar access macros will be enough, i.e. I don't fully understand how they work / are supposed to work. ... I believe that all of the list

Re: [Breaking change] Move nxmutex to sched

Hi, Thanks for the responses. The scalar read / write functions will work when accessing singular fields from the semaphore, and such an access will (or at least should be) always be correctly aligned so there is no risk in the scalar value being split by a page boundary -> no extra work is requir

Re: [Breaking change] Move nxmutex to sched

On 4/18/2023 6:58 AM, Nathan Hartman wrote: On Tue, Apr 18, 2023 at 8:52 AM spudaneco wrote: Perhaps you could use accessor functions to read/write 8, 16 32, 64 bit values. Each scalar value will be properly aligned and, hence, will lie within a page. And those accessor functions could be

Re: [Breaking change] Move nxmutex to sched

On Tue, Apr 18, 2023 at 8:52 AM spudaneco wrote: > Perhaps you could use accessor functions to read/write 8, 16 32, 64 bit > values. Each scalar value will be properly aligned and, hence, will lie > within a page. And those accessor functions could be macros in FLAT builds where functions are

Re: [Breaking change] Move nxmutex to sched

Subject: Re: [Breaking change] Move nxmutex to sched Hi,Sorry for the spamfest. Forget what I said about the alignment being asolution. It is not. Any object allocated from heap that contains a sem_tstructure cannot guarantee that the alignment of sem_t is correct.So I was just being dumb..Br

Re: [Breaking change] Move nxmutex to sched

Hi, Sorry for the spamfest. Forget what I said about the alignment being a solution. It is not. Any object allocated from heap that contains a sem_t structure cannot guarantee that the alignment of sem_t is correct. So I was just being dumb.. Br, Ville Juven On Tue, Apr 18, 2023 at 11:39 AM Juk

Re: [Breaking change] Move nxmutex to sched

Hi, I like the alignment idea, thanks for bringing it up! I think forcing the alignment for the semaphore, and accessing it directly via page pool from the kernel is the simplest and most trivial thing. It implements what also Greg suggested + fixes the issue of semaphore being on the page bo

Re: [Breaking change] Move nxmutex to sched

Hi all, As Tomek said, whatever you choose to do, please make sure everything of this is absolutely kept optional, at least during the merge and community validation phase. I dont think connecting these proposals to CONFIG_BUILD_KERNEL is granular enough. Thanks, Sebastien Le 18/04/2023

Re: [Breaking change] Move nxmutex to sched

Hi all, Sorry, this is going a bit off topic. One wild solution specifically to solve my/our problem (CONFIG_BUILD_KERNEL) might be to force a "next power-of-two alignment" for the semaphore. This would ensure that the semaphore ALWAYS fits within a single page and remove the need for cross page

Re: [Breaking change] Move nxmutex to sched

if it possible to add new functionality as optional feature? -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

Re: [Breaking change] Move nxmutex to sched

> >> 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. > &g

Re: [Breaking change] Move nxmutex to sched

eady 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 t

Re: [Breaking change] Move nxmutex to sched

ilto: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 th

Re: [Breaking change] Move nxmutex to sched

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 cha

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 mis

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 "ob

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

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, bu

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

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 th

Re: [Breaking change] Move nxmutex to sched

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 пише: > > > > On Apr 1, 2023, at 12:54 PM, David S. Alessio > wrot

Re: [Breaking change] Move nxmutex to sched

> On Apr 1, 2023, at 12:54 PM, David S. Alessio > wrote: > > > >> On Mar 31, 2023, at 9: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

Re: [Breaking change] Move nxmutex to sched

> On Mar 31, 2023, at 9: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 right. I

Re: [Breaking change] Move nxmutex to sched

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.  Th

Re: [Breaking change] Move nxmutex to sched

There are two issues that I would like to bring to your attention. #7393 - https://github.com/apache/nuttx/issues/7393 #5973 - https://github.com/apache/nuttx/issues/5973 On Sat, Apr 1, 2023 at 12:07 AM Gregory Nutt wrote: > > > BTW, https://github.com/apache/nuttx/pull/5070 report that the sys

Re: [Breaking change] Move nxmutex to sched

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

Re: [Breaking change] Move nxmutex to sched

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

Re: [Breaking change] Move nxmutex to sched

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

Re: [Breaking change] Move nxmutex to sched

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

Re: [Breaking change] Move nxmutex to sched

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

Re: [Breaking change] Move nxmutex to sched

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

Re: [Breaking change] Move nxmutex to sched

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

Re: [Breaking change] Move nxmutex to sched

> 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

Re: [Breaking change] Move nxmutex to sched

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

Re: [Breaking change] Move nxmutex to sched

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

Re: [Breaking change] Move nxmutex to sched

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

Re: [Breaking change] Move nxmutex to sched

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

Re: [Breaking change] Move nxmutex to sched

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

Re: [Breaking change] Move nxmutex to sched

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

Re: [Breaking change] Move nxmutex to sched

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

Re: [Breaking change] Move nxmutex to sched

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

Re: [Breaking change] Move nxmutex to sched

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

Re: [Breaking change] Move nxmutex to sched

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

Re: [Breaking change] Move nxmutex to sched

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

Re: [Breaking change] Move nxmutex to sched

On Fri, Mar 31, 2023 at 12:23 AM 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 DocuWiki p

Re: [Breaking change] Move nxmutex to sched

> 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 DocuWiki page > In any RTOS, priority inversion happens, and it’s OK, a

Re: [Breaking change] Move nxmutex to sched

I have mixed feelings myself and hope that we get some consensus through dialog. One one hand, it is important to stay faithful to documented standard and undocumented conventions for the use the a POSIX/Unix systems. But on the other hand, unlike other OSs that strive toward standard conforma

Re: [Breaking change] Move nxmutex to sched

All, In his Confluence paper on "Signaling Semaphores and Priority Inheritance”, Brennan Ashton’s analysis is both thorough and accurate; and his conclusion that There should then be no priority inheritance operations on this semaphore that is used for signalling. is unassailable. It’s impor

Re: [Breaking change] Move nxmutex to sched

On Thu, Mar 30, 2023 at 9:49 AM Gregory Nutt wrote: > > >> 3. Move priority inheritance from nxsem to nxmutex, and optimize the > >> performance of priority inheritance; > > > > That will break every a lot of people's code. There is probably a lot > > of application logic that depends on priorit

Re: [Breaking change] Move nxmutex to sched

3. Move priority inheritance from nxsem to nxmutex, and optimize the performance of priority inheritance; That will break every a lot of people's code.  There is probably a lot of application logic that depends on priority inheritance working on counting semaphores.  Removing that will prob

Re: [Breaking change] Move nxmutex to sched

On 3/30/2023 1:57 AM, 奇诺 wrote: Hi, all: I submitted a PR regarding mutex, the changes are as follows: 1. Move some mutex operations to sched;2. Add mutex_clocklock, mutex_set_protocol, and mutex_get_protocol interfaces;3. Remove cancellation point operations in mutex because it is not a cance