On Sep 23, 2016 9:17 AM, "Gedare Bloom" <ged...@rtems.org> wrote: > > 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?
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.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
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel