potential deadlock in _once

[Sebastian Huber]

On 06/03/18 12:12, Passas, Stavros wrote:
> -----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.

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

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