-----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 
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,
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

Reply via email to