Thanks. I will pass this along and resubmit a patch to at least add a comment and fix formatting issues.
Do we have a good place to add this information to the documentation? On Tue, Nov 21, 2023, 5:35 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > On 20.11.23 18:42, Joel Sherrill wrote: > > The loop that waits for another thread to complete the once > > initialization was flagged as a potential infinite loop. > > This is because there was no way to break out of the loop > > inside the loop. The solution is to make the state variable > > volatile which indicates it may be modified by another thread > > of execution. > > > > This was flagged by a user Coverity Scan run which apparently is > > configured differently from the instance provided by Coverity to > > open source projects. > > This is a configuration issue of Coverity Scan. You have to teach > Coverity Scan something about: > > _Atomic_Fence( ATOMIC_ORDER_ACQUIRE ); > _Atomic_Fence( ATOMIC_ORDER_RELEASE ); > > rtems_mutex_lock(); > rtems_condition_variable_wait(); > rtems_mutex_unlock(); > > Using "volatile" for multi-threaded synchronization is not correct in > C11 or later. This keyword is for device access. For multi-threaded > synchronization you need atomic operations or mutexes, etc. From my > point of view, Coverity Scan should warn if you use volatile for > multi-threaded synchronization. > > -- > embedded brains GmbH > Herr Sebastian HUBER > Dornierstr. 4 > 82178 Puchheim > Germany > email: sebastian.hu...@embedded-brains.de > phone: +49-89-18 94 741 - 16 > fax: +49-89-18 94 741 - 08 > > Registergericht: Amtsgericht München > Registernummer: HRB 157899 > Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler > Unsere Datenschutzerklärung finden Sie hier: > https://embedded-brains.de/datenschutzerklaerung/ >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
