<p dir="ltr"></p>
<p dir="ltr">On Sep 23, 2016 9:17 AM, "Gedare Bloom" <<a href="mailto:gedare@rtems.org">gedare@rtems.org</a>> wrote:<br>
><br>
> On Fri, Sep 23, 2016 at 5:19 AM, Sebastian Huber<br>
> <<a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-brains.de</a>> wrote:<br>
> > Hello,<br>
> ><br>
> > due to the new thread priority management, the<br>
> > Thread_Control::resource_count is no longer needed to maintain the thread<br>
> > priority. The only relevant user of the thread resource count is<br>
> ><br>
> > static void _Thread_Make_zombie( Thread_Control *the_thread )<br>
> > {<br>
> >   if ( _Thread_Owns_resources( the_thread ) ) {<br>
> >     _Terminate(<br>
> >       INTERNAL_ERROR_CORE,<br>
> >       false,<br>
> >       INTERNAL_ERROR_RESOURCE_IN_USE<br>
> >     );<br>
> >   }<br>
> > [...]<br>
> > }<br>
> ><br>
> > which issues a fatal error in case a thread terminates with a non-zero<br>
> > resource count.<br>
> ><br>
> > The question is now: should we maintain the resource count solely for this<br>
> > diagnostic purpose (the resource count increment/decrement is in the hot<br>
> > path of the mutex obtain/release)?<br>
> ><br>
> It could be made conditional on DEBUG.<br>
><br>
> Rather than using refcnts, is there a costlier method (e.g. iterating<br>
> some structures) to discover a thread is holding a mutex at this point<br>
> of thread destruction that makes sense to use instead?</p>
<p dir="ltr">I like the idea of DEBUG. It keeps it as a potential check. </p>
<p dir="ltr">FWIW we should promote the debug checks more for folks during development.  Perhaps even be more aggressive. I have added a temporary printk on the object allocator failing. Everything the computer can automatically check for you is a goos thing during development.<br></p>
<p dir="ltr">> > Terminating threads which own mutexes make these mutexes indestructible or<br>
> > lead to surprises in case the thread control block is re-used by a new<br>
> > thread. The current fatal error is new in 4.11, previous RTEMS didn't detect<br>
> > this situation.<br>
> ><br>
> > If we decide to keep the resource count, then I suggest to use it for the<br>
> > no-protocol mutexes as well. This leads to code re-use with the priority<br>
> > inheritance mutexes.<br>
> ><br>
> > --<br>
> > Sebastian Huber, embedded brains GmbH<br>
> ><br>
> > Address : Dornierstr. 4, D-82178 Puchheim, Germany<br>
> > Phone   : +49 89 189 47 41-16<br>
> > Fax     : +49 89 189 47 41-09<br>
> > E-Mail  : <a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-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>
> > _______________________________________________<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">http://lists.rtems.org/mailman/listinfo/devel</a><br>
> _______________________________________________<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">http://lists.rtems.org/mailman/listinfo/devel</a><br></p>