On 04/03/18 22:09, Passas, Stavros wrote:


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?


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.hu...@embedded-brains.de
PGP     : Public key available on request.

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

devel mailing list

Reply via email to