xiaoxiang781216 commented on PR #15705: URL: https://github.com/apache/nuttx/pull/15705#issuecomment-2625243987
> > I hope you read my reply carefully. Which of the following 2 options do you pick? > > ``` > > spin_lock: spin lock > > spin_lock_nopreempt: spin_lock + sched_lock > > spin_lock_irqsave: spin lock + irq save > > spin_lock_irqsave_nopreempt: spin_lock + irq save + sched_lock > > ``` > > > > > > > > > > > > > > > > > > > > > > > > or > > ``` > > spin_lock: spin lock + sched_lock > > spin_lock_preempt: spin_lock > > spin_lock_irqsave: spin lock + irq save + sched_lock > > spin_lock_irqsave_preempt: spin_lock + irq save > > ``` > > In this case, @xiaoxiang781216 , the first option is more intuitive. We can improve the documentation and let it clear that `spin_lock` should not be used when the scheduler and IRQ handler are enabled. It's still usable for our bootloader (for instance). Bootloader is a very short phase in the whole life cycle, we should make the API safe in the most of time. Even in the boot phase, the usage of spinlock is also wrong and give a bad demo and should be removed to avoid the future abuse. So, please review https://github.com/apache/nuttx/pull/15728 which not only remove the bad usage but also simplify the code logic. > Keeping the API coherent seems to be more important in this case. I hope https://github.com/apache/nuttx/pull/15728 will change your mind: the clear and simple spinlock usage is good than keeping it as before. -- 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
