On 04/03/18 22:09, Passas, Stavros wrote:
We have faced RTEMS threads getting locked up when using certain c++
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?
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
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.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
devel mailing list