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

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

Reply via email to