Gotcha regarding the DEBUGASSERT. I can open up a GitHub issue to document
this discussion so it can be fixed?
Yeah regarding the critical section for sched_lock() I agree that atomicity
is needed too for the RMW. What are your thoughts on the existing mutex and
semaphore functions without barrie
On 8/28/2024 7:15 PM, Daniel Appiagyei wrote:
Hi Gregory, thank you for the quick response!
RE: 'lockcount' needing to be in a critical section:
That's good information to know, I wasn't aware before. I'm searching nuttx
for exact matches of the string 'sched_lock();' to find occurrences and
s
Actually, let me correct my previous statement that mutexs and semaphores
need critical sections, I think they just need memory barriers. We can look
at how the Linux kernel does it to double check our knowledge. Here’s s
quick stack overflow link, for what it’s worth.
https://stackoverflow.com/que
Hi Gregory, thank you for the quick response!
RE: 'lockcount' needing to be in a critical section:
That's good information to know, I wasn't aware before. I'm searching nuttx
for exact matches of the string 'sched_lock();' to find occurrences and
seeing this is not always done. Yeah a critical sec
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:
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 cri
