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
<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.
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
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
