Hi all, Looking at sched_lock.c ( https://github.com/apache/nuttx/blob/master/sched/sched/sched_lock.c#L187), , specifically at the non-SMP sched_lock() implementation, how do we ensure that: 1. There's no data-race when incrementing the lock count: 'rtcb->lockcount++;', (given that no mutex or critical section is surrounding that code so other tasks or IRQs are free to interrupt the assembly instructions), and 2. The scheduler is 100% prevented from allowing a different task to run after lock_count is incremented given that we don't use a data memory barrier or data synchronization barrier to ensure the write to 'lock_count' is visible to the rest of the system in memory?
For 1, see cppreference 'Threads and data races' on data races being undefined behavior (https://en.cppreference.com/w/c/language/memory_model). Best, Daniel -- *Daniel Appiagyei | Embedded Software Engineer *Email: daniel.appiag...@braincorp.com <bog...@braincorporation.com>*Brain* * Corp™ *10182 Telesis Ct, Suite 100 San Diego, CA 92121 (858)-689-7600 www.braincorp.com
