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
