On Fri, Sep 23, 2016 at 5:19 AM, Sebastian Huber
<sebastian.hu...@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.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
