On Tue, Sep 19, 2017 at 9:40 AM, Gedare Bloom <ged...@rtems.org> wrote:
> On Tue, Sep 19, 2017 at 10:09 AM, Joel Sherrill <j...@rtems.org> wrote: > > > > > > On Tue, Sep 19, 2017 at 8:16 AM, Sebastian Huber > > <sebastian.hu...@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@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.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 > > > > > > > > _______________________________________________ > > devel mailing list > > devel@rtems.org > > http://lists.rtems.org/mailman/listinfo/devel >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
