pussuw opened a new pull request, #15566: URL: https://github.com/apache/nuttx/pull/15566
## Summary The load/compare and RMW to wait_count need protection. Bumping the counter can be done by atomic_fetch_add as there is no race here. However reading the counter when signaling needs to take a lock so that if multiple threads signal at the same time, only one has exclusive access to the counter. NOTE: The assumption that the user will call pthread_cond_signal / pthread_cond_broadcast with the mutex given to pthread_cond_wait held is simply not true. It MAY hold it, but it is not forced. Thus, using the user space lock for protecting the wait counter as well is not valid! ## Impact This fixes regression from https://github.com/apache/nuttx/pull/14581 and https://github.com/apache/nuttx/pull/14786 ## Testing MPFS with multiple threads using pthread_cond. rv-virt:smp64 Direct reference from POSIX: The pthread_cond_signal() or pthread_cond_broadcast() functions may be called by a thread whether or not it currently owns the mutex that threads calling pthread_cond_wait() or pthread_cond_timedwait() have associated with the condition variable during their waits; however, if predictable scheduling behaviour is required, then that mutex is locked by the thread calling pthread_cond_signal() or pthread_cond_broadcast(). [1] https://pubs.opengroup.org/onlinepubs/7908799/xsh/pthread_cond_signal.html -- 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: commits-unsubscr...@nuttx.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
