Re: potential deadlock in _once
On 06/03/18 12:12, Passas, Stavros wrote: -Original Message- From: Sebastian Huber [mailto:sebastian.hu...@embedded-brains.de] Sent: Tuesday, March 6, 2018 10:19 AM To: Passas, Stavros;rtems-de...@rtems.org Subject: Re: potential deadlock in _once 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. Using one dedicated mutex for each pthread_once_t instance would be a longer term and elegant solution. On the other hand, I think we can get away with a much simpler change: The _once implementation uses a single mutex. Currently this mutex protects the whole function, while I believe we protect reads/writes to the once_state variable only. Concurrent tasks finding the state on RUNNING, could just yield until the state becomes ONCE_STATE_COMPLETE. Ok, maybe we could use a condition variable for this. It might be preferable in terms of storage space. The pthread_once_t is currently only one byte. A mutex would increase this to 28 bytes or so. One side problem I noticed is that the _once() returns EINVAL, if a thread finds the state in ONCE_STATE_RUNNING. This is not documented in RTEMS, neither in POSIX. The specs define: "The init_routine is guaranteed to have run to completion when this routine returns to the caller". If this is important for you then I suggest to add tickets and implement and test it. -- 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 devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
RE: potential deadlock in _once
-Original Message- From: Sebastian Huber [mailto:sebastian.hu...@embedded-brains.de] Sent: Tuesday, March 6, 2018 10:19 AM To: Passas, Stavros ; rtems-de...@rtems.org Subject: Re: potential deadlock in _once > 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. Using one dedicated mutex for each pthread_once_t instance would be a longer term and elegant solution. On the other hand, I think we can get away with a much simpler change: The _once implementation uses a single mutex. Currently this mutex protects the whole function, while I believe we protect reads/writes to the once_state variable only. Concurrent tasks finding the state on RUNNING, could just yield until the state becomes ONCE_STATE_COMPLETE. One side problem I noticed is that the _once() returns EINVAL, if a thread finds the state in ONCE_STATE_RUNNING. This is not documented in RTEMS, neither in POSIX. The specs define: "The init_routine is guaranteed to have run to completion when this routine returns to the caller". Best Regards, Stavros -- Intel Research and Development Ireland Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: potential deadlock in _once
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.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
