patacongo opened a new issue, #9531: URL: https://github.com/apache/nuttx/issues/9531
@MasayukiIshikawa @masayuki2009 I was just looking at the implementation of spin_lock_irqsave(). spin_lock_irqsave() basically just: 1. Calls irqsave() to disable local interrupts, and 2. Calls spin_lock() to lock the spinlock. The waiting thread then holds the lock and the following code section is protected. However, isn't it possible that another thread running on a different CPU could cause a higher priority thread to be started and that could cause the thread holding the spinlock to be blocked? It looks like that could happen and, if so, that would be bad. Am I missing something. A simple solution would be to call sched_lock() from spin_irq_lock() while holding the spinlock and call sched_unlock() when the spinlock is unlocked. That is reasonably lightweight and should guarantee that the thread holding the spinlock runs on the CPU until it relinquishes the spinlock. I suppose that issue would not be unique to spin_lock_irqsave() but would really apply to all use of spinlocks. This is similar to another issue that added a call to sched_lock() in enter_critical_section because the thread holding the critical section was being suspended. In that case, there is not real error, but the results could be confusing and counterintuitive. This seems like the same problem but the results could be a real problem in certain cases. -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
