Self-contained POSIX synchronization objects for RTEMS 4.12?

Joel Sherrill joel at
Tue Sep 19 14:09:12 UTC 2017

On Tue, Sep 19, 2017 at 8:16 AM, Sebastian Huber <
sebastian.huber at> wrote:

> Hello,
> we have to make some trade-offs in the implementation with respect to the
> error checking. The operations get a pointer to the synchronization object,
> e.g.
> int sem_post(sem_t *sem);
> int pthread_mutex_lock(pthread_mutex_t *mutex);
> Do we want to check for NULL pointers?

Is newlib consistently using the non-NULL declaration on the argument?

Newlib/Cygwin folks have been pretty insistent that they do not want to
check for NULL on the shared methods.

Personally I hate to delete NULL argument pointer checks. Would a
long-term compromise be to move them to argument checking macros
that are enabled with --enable-rtems-debug?

> Do we want to check for other obviously invalid pointer values, e.g.


> Do we want to check if the object has been initialized?

Yes. We want to have predictable behavior.


> glibc uses no checks at all.

Performance over correctness? That doesn't seem like a good trade.

> FreeBSD checks that the object has been initialized. For this purpose it
> embeds a magic value field in the object structure. The drawback is that if
> we also do this, the objects are not zero-initialized and thus cannot
> reside in the BSS section.

This is an impossible trade. Some systems have big Flash and small RAM.
Others are the opposite.

I would rather follow the FreeBSD model and know the object is initialized.

> Destruction of synchronization objects in use is undefined behaviour
> according to POSIX. Do we want to flush waiting threads during destruction?
> This is a complex operation.

We have over 20 years of defined behavior in this case. I think
we flush and return the same error we always did. Otherwise,
we get a deadlock.

> What you think?
> --
> 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
> PGP     : Public key available on request.
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> _______________________________________________
> devel mailing list
> devel at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the devel mailing list