What to do with Thread_Control::resource_count?

[Gedare Bloom]

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?

> 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