-----Original Message----- From: Sebastian Huber [mailto:sebastian.hu...@embedded-brains.de] Sent: Tuesday, March 6, 2018 10:19 AM To: Passas, Stavros <stavros.pas...@intel.com>; rtems-de...@rtems.org <devel@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
