Self-contained POSIX synchronization objects for RTEMS 4.12?

[Gedare Bloom]

On Tue, Sep 19, 2017 at 10:09 AM, Joel Sherrill <joel at rtems.org> wrote:
>
>
> On Tue, Sep 19, 2017 at 8:16 AM, Sebastian Huber
> <sebastian.huber at embedded-brains.de> 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.
>> SEM_FAILED?
>
>
> IMO Yes
>
>>
>> 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.
>
It's actually performance assuming correctness. In modern multicore
software the lock acquire is a serious critical path. I don't know
that RTEMS is quite to the point it matters so much, but eventually
even some targets will prefer the optimized fast path of lock acquire.
It's up to the caller to check that previous calls to create/init the
object succeeded, and the main complication then is if the
synchronization object is used after it is destroyed.

If possible we should provide control over the trade-off, e.g., with a
debug flag for some checks.

>>
>>
>> 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.
>
zero-initialized should also be check-able?

>>
>>
>> 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.
>
Is this true for all current synchronization objects we have? Where in
the code does this happen?

If the destroyed object is easily identifiable, then waiting threads
can be denied the acquire without having to flush at time of object
destruction. (What about threads in the critical section of non-mutex
locks, e.g., counting semaphores?)

>>
>>
>> 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 embedded-brains.de
>> PGP     : Public key available on request.
>>
>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>>
>> _______________________________________________
>> devel mailing list
>> devel at rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
>
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel