[PATCH rtems v2] once.c, onceimplh.h: Make synchronization variable volatile

[Joel Sherrill]

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.huber at 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.huber at 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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20231121/cc4999e0/attachment-0001.htm>