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 barriers or critical sections? Would you agree that it is a bug currently? *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 On Wed, Aug 28, 2024 at 7:22 PM Gregory Nutt <spudan...@gmail.com> wrote: > > 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 > > seeing this is not always done. > > It should always be done. Sometimes it is not so easy to determine if > you are in a critical section or not by inspecting the code. The old > BSD file headers had an "Assumptions" section where that was documented > in comments. It would state if being in a critical section was an entry > requirement or not. But those file headers were removed when NuttX > became Apache. > > It would be a good exercise to verify that the critical section is > always in place and fix any oversights. > > The critical section is needed not just for the memory barrier. > lockcount++ is a read modify write operation on most CPUs and must be > made atomic. > > >
