Self-contained POSIX synchronization objects for RTEMS 4.12?

[Joel Sherrill]

On Tue, Sep 19, 2017 at 9:40 AM, Gedare Bloom <gedare at rtems.org> wrote:

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

_Thread_queue_Flush() is the method you are looking for and it is invoked
in the Destroy path of core synchronization objects as well as other places.

[joel at localhost cpukit]$ grep -rl  _Thread_queue_Flush  .
./rtems/src/semdelete.c
./rtems/src/semflush.c
./score/include/rtems/score/threadqimpl.h
./score/include/rtems/score/corebarrierimpl.h
./score/include/rtems/score/coresemimpl.h
./score/src/condition.c
./score/src/corebarrierrelease.c
./score/src/coremsgclose.c
./score/src/coremsgflush.c
./score/src/coremsgflushwait.c
./score/src/corerwlockrelease.c
./score/src/futex.c
./score/src/mpci.c
./score/src/threadqflush.c
./score/src/threadrestart.c


>
> 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?)
>

This is just for threads blocked waiting to acquire. The behavior
for holding an object when it is deleted is object specific. I think
some mutex flavors can't be deleted while a thread holds them.

If they are not acquired when deleted, when would they ever be
unblocked?

--joel

>
> >>
> >>
> >> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20170919/f02986b8/attachment-0002.html>