On 8/28/2024 6:14 PM, Daniel Appiagyei wrote:
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
All places where the lockcount is incremented should be within a
critical section. I believe that is true. But if you find place where
that is not true, that would indeed be a bug.
Perhaps a DEBUGASSERTion that we are in a critical section before
incrementing lockcount would be a good verification of this belief.
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?
Adding a barrier might be a good idea, although I have never seen this
to be an issue. If we are in a critical section, then other threads
will not run at least until the thread blocks or terminates (even in SMP
mode).
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
