xiaoxiang781216 commented on issue #10981: URL: https://github.com/apache/nuttx/issues/10981#issuecomment-1772145810
> I have some questions about enter_critical_section. > > First. When I wrote spinlock code, I found spinlock_irqsave can disable interrupt. Why we need to use enter_critical_section in [mm_alloc](https://github.com/apache/nuttx/blob/a521fd7b82dec43871b4f56a6ae0d85d124158e9/mm/mm_heap/mm_malloc.c#L50) instead of spinlock_irqsave? The operation is very light. And I have read [#2213 (comment)](https://github.com/apache/nuttx/issues/2213#issuecomment-731052528), enter_critical_section may make caller sleep and cause delay. > Yes, it should be replaced with spinlock. Actually, we have an issue track this: https://github.com/apache/nuttx/issues/1144. > Second. And there is a [archive](https://www.mail-archive.com/dev@nuttx.apache.org/msg04078.html) describe `the critical section is left automatically when the context switch occurs` but I can't find any code about this description. > Because the irq status is part of per thread register context, the irq status is automatically restored when arch specific code restores CPU context register. Only SMP case has the special code to restore the additional context: https://github.com/apache/nuttx/blob/master/sched/irq/irq_csection.c#L717 > Three. The critical section is in oder to resolving some architecture can't disable global interrupt. But why other RTOS projects don't have this feature? > > Finally, what is the difference between semaphore and enter_critical_section? You can't use semaphore to protect the resource shared/accessed by irq handler, which mean you can call sem_post, but not sem_wait in the irq handler. > What condition we should use semaphore instead of enter_critical_section? What condition we should use enter_critical_section instead of semaphore? From the real time perspective, it's better to use semaphore as much as possible, but we found that semaphore is much slower than the critical section. So, we need find the balance here. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@nuttx.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
