<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 19, 2017 at 9:40 AM, Gedare Bloom <span dir="ltr"><<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On Tue, Sep 19, 2017 at 10:09 AM, Joel Sherrill <<a href="mailto:joel@rtems.org">joel@rtems.org</a>> wrote:<br>
><br>
><br>
> On Tue, Sep 19, 2017 at 8:16 AM, Sebastian Huber<br>
> <<a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-<wbr>brains.de</a>> wrote:<br>
>><br>
>> Hello,<br>
>><br>
>> we have to make some trade-offs in the implementation with respect to the<br>
>> error checking. The operations get a pointer to the synchronization object,<br>
>> e.g.<br>
>><br>
>> int sem_post(sem_t *sem);<br>
>><br>
>> int pthread_mutex_lock(pthread_<wbr>mutex_t *mutex);<br>
>><br>
>> Do we want to check for NULL pointers?<br>
><br>
><br>
> Is newlib consistently using the non-NULL declaration on the argument?<br>
><br>
> Newlib/Cygwin folks have been pretty insistent that they do not want to<br>
> check for NULL on the shared methods.<br>
><br>
> Personally I hate to delete NULL argument pointer checks. Would a<br>
> long-term compromise be to move them to argument checking macros<br>
> that are enabled with --enable-rtems-debug?<br>
><br>
>><br>
>><br>
>> Do we want to check for other obviously invalid pointer values, e.g.<br>
>> SEM_FAILED?<br>
><br>
><br>
> IMO Yes<br>
><br>
>><br>
>> Do we want to check if the object has been initialized?<br>
><br>
><br>
> Yes. We want to have predictable behavior.<br>
><br>
>><br>
>><br>
>><br>
>><br>
>> glibc uses no checks at all.<br>
><br>
><br>
> Performance over correctness? That doesn't seem like a good trade.<br>
><br>
</span>It's actually performance assuming correctness. In modern multicore<br>
software the lock acquire is a serious critical path. I don't know<br>
that RTEMS is quite to the point it matters so much, but eventually<br>
even some targets will prefer the optimized fast path of lock acquire.<br>
It's up to the caller to check that previous calls to create/init the<br>
object succeeded, and the main complication then is if the<br>
synchronization object is used after it is destroyed.<br>
<br>
If possible we should provide control over the trade-off, e.g., with a<br>
debug flag for some checks.<br>
<span class="gmail-"><br>
>><br>
>><br>
>> FreeBSD checks that the object has been initialized. For this purpose it<br>
>> embeds a magic value field in the object structure. The drawback is that if<br>
>> we also do this, the objects are not zero-initialized and thus cannot reside<br>
>> in the BSS section.<br>
><br>
><br>
> This is an impossible trade. Some systems have big Flash and small RAM.<br>
> Others are the opposite.<br>
><br>
> I would rather follow the FreeBSD model and know the object is initialized.<br>
><br>
</span>zero-initialized should also be check-able?<br>
<span class="gmail-"><br>
>><br>
>><br>
>> Destruction of synchronization objects in use is undefined behaviour<br>
>> according to POSIX. Do we want to flush waiting threads during destruction?<br>
>> This is a complex operation.<br>
><br>
><br>
> We have over 20 years of defined behavior in this case. I think<br>
> we flush and return the same error we always did. Otherwise,<br>
> we get a deadlock.<br>
><br>
</span>Is this true for all current synchronization objects we have? Where in<br>
the code does this happen?<br></blockquote><div><br></div><div>_Thread_queue_Flush() is the method you are looking for and it is invoked</div><div>in the Destroy path of core synchronization objects as well as other places.</div><div><br></div><div>[joel@localhost cpukit]$ grep -rl _Thread_queue_Flush .</div><div>./rtems/src/semdelete.c</div><div>./rtems/src/semflush.c</div><div>./score/include/rtems/score/threadqimpl.h</div><div>./score/include/rtems/score/corebarrierimpl.h</div><div>./score/include/rtems/score/coresemimpl.h</div><div>./score/src/condition.c</div><div>./score/src/corebarrierrelease.c</div><div>./score/src/coremsgclose.c</div><div>./score/src/coremsgflush.c</div><div>./score/src/coremsgflushwait.c</div><div>./score/src/corerwlockrelease.c</div><div>./score/src/futex.c</div><div>./score/src/mpci.c</div><div>./score/src/threadqflush.c</div><div>./score/src/threadrestart.c</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
If the destroyed object is easily identifiable, then waiting threads<br>
can be denied the acquire without having to flush at time of object<br>
destruction. (What about threads in the critical section of non-mutex<br>
locks, e.g., counting semaphores?)<br></blockquote><div><br></div><div>This is just for threads blocked waiting to acquire. The behavior</div><div>for holding an object when it is deleted is object specific. I think</div><div>some mutex flavors can't be deleted while a thread holds them.</div><div><br></div><div>If they are not acquired when deleted, when would they ever be</div><div>unblocked?</div><div><br></div><div>--joel </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="gmail-HOEnZb"><div class="gmail-h5"><br>
>><br>
>><br>
>> What you think?<br>
>><br>
>><br>
>> --<br>
>> Sebastian Huber, embedded brains GmbH<br>
>><br>
>> Address : Dornierstr. 4, D-82178 Puchheim, Germany<br>
>> Phone : <a href="tel:%2B49%2089%20189%2047%2041-16" value="+4989189474116">+49 89 189 47 41-16</a><br>
>> Fax : <a href="tel:%2B49%2089%20189%2047%2041-09" value="+4989189474109">+49 89 189 47 41-09</a><br>
>> E-Mail : <a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-<wbr>brains.de</a><br>
>> PGP : Public key available on request.<br>
>><br>
>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.<br>
>><br>
>> ______________________________<wbr>_________________<br>
>> devel mailing list<br>
>> <a href="mailto:devel@rtems.org">devel@rtems.org</a><br>
>> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/<wbr>mailman/listinfo/devel</a><br>
><br>
><br>
><br>
> ______________________________<wbr>_________________<br>
> devel mailing list<br>
> <a href="mailto:devel@rtems.org">devel@rtems.org</a><br>
> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/<wbr>mailman/listinfo/devel</a><br>
</div></div></blockquote></div><br></div></div>