What to do with Thread_Control::resource_count?

Joel Sherrill joel at rtems.org
Fri Sep 23 14:26:47 UTC 2016


On Sep 23, 2016 9:17 AM, "Gedare Bloom" <gedare at rtems.org> wrote:
>
> On Fri, Sep 23, 2016 at 5:19 AM, Sebastian Huber
> <sebastian.huber at embedded-brains.de> wrote:
> > Hello,
> >
> > due to the new thread priority management, the
> > Thread_Control::resource_count is no longer needed to maintain the
thread
> > priority. The only relevant user of the thread resource count is
> >
> > static void _Thread_Make_zombie( Thread_Control *the_thread )
> > {
> >   if ( _Thread_Owns_resources( the_thread ) ) {
> >     _Terminate(
> >       INTERNAL_ERROR_CORE,
> >       false,
> >       INTERNAL_ERROR_RESOURCE_IN_USE
> >     );
> >   }
> > [...]
> > }
> >
> > which issues a fatal error in case a thread terminates with a non-zero
> > resource count.
> >
> > The question is now: should we maintain the resource count solely for
this
> > diagnostic purpose (the resource count increment/decrement is in the hot
> > path of the mutex obtain/release)?
> >
> It could be made conditional on DEBUG.
>
> Rather than using refcnts, is there a costlier method (e.g. iterating
> some structures) to discover a thread is holding a mutex at this point
> of thread destruction that makes sense to use instead?

I like the idea of DEBUG. It keeps it as a potential check.

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.

> > Terminating threads which own mutexes make these mutexes indestructible
or
> > lead to surprises in case the thread control block is re-used by a new
> > thread. The current fatal error is new in 4.11, previous RTEMS didn't
detect
> > this situation.
> >
> > If we decide to keep the resource count, then I suggest to use it for
the
> > no-protocol mutexes as well. This leads to code re-use with the priority
> > inheritance mutexes.
> >
> > --
> > 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/20160923/7ca6bfb1/attachment.html>


More information about the devel mailing list