potential deadlock in _once

[Sebastian Huber]

On 04/03/18 22:09, Passas, Stavros wrote:
>
> Hi,
>
> We have faced RTEMS threads getting locked up when using certain c++ 
> functionality.
>
> Issue happens for example when std::future is combined with std::async.
>
> Investigating deeper, seems like this happens if std::async executes 
> before std::future gets scheduled to run. Both of these create a 
> pthread_once instance. _once uses a common semaphore for all calls, 
> thus the first function (async.get usually) gets the lock, calls its 
> “init” function (which blocks until the second function has completed, 
> while std::future also uses pthread_once to create a new thread, but 
> because the lock is already taken, it blocks, casing a deadlock 
> between these two functions.
>
> Is this a known issue?
>

No.

> If not, should I create a ticket about it?
>

Yes, please open a ticket and provide a test case for the RTEMS test 
suite. Maybe we have to use dedicated mutexes for each pthread_once_t 
object. This is what Linux and FreeBSD do. This would require a Newlib 
update.

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.