Re: Development priorities (was: [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

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: Networking and kernel workers

As far as I know, the network must use the low-priority workers. I can see a comment in arch/arm/src/stm32/stm32_eth.c line 88. But I also remember reading somewhere that the high priority workers may cause dead-locks. But I think that the difference between the two workers is only the... prio

Re: Networking and kernel workers

You said one other thing that caught my attentioni: For example, I have several tasks (that use the network) running at a priority of 100. In a properly turned real time system, you should never have two tasks with the same priority.  That breaks some of the fundamental assumptions that supp

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: Networking and kernel workers

Thank you very much for this explanation. > This is really outside of the scope of the OS. There is no OS imposed > rule about what priorities you should use for your applications or for > the low priority work queue. So I don't think there is a rule or a > correct answer. You just need to expe

Re: Networking and kernel workers

The network API (sockets etc) will be called by the user's task. The network driver will run on the LP worker. The socket calls run at the user priority, but no not actually do the transfers.  The just set up to do the transfer then wait for the transfer to complete. The transfer itself i

Re: Networking and kernel workers

>> Is there any limitation anywhere that dictates the relationship between >> these two priorities? > Since they run synchronously and generally don't overlap in time, I > would say that the answer is no I think this answers my question, thank you. So, It doesn't really matter what the priority o

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: Networking and kernel workers

On 4/1/2023 12:07 PM, Fotis Panagiotopoulos wrote: Is there any limitation anywhere that dictates the relationship between these two priorities? Since they run synchronously and generally don't overlap in time, I would say that the answer is no I think this answers my question, thank you. So,

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