potential deadlock in _once

[Passas, Stavros]

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