This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Re: Thread activation disturbed by lower priority threads]
- From: "Alois Z." <alois at gmx dot at>
- To: ecos-discuss at ecos dot sourceware dot org
- Date: Fri, 17 Aug 2007 09:33:54 +0200
- Subject: Re: [ECOS] Thread activation disturbed by lower priority threads]
Hi,
>
> How many mutex's does your lower priority thread hold? From
> packages/kernel/current/src/sched/sched.cxx
>
> void Cyg_SchedThread::clear_inherited_priority()
> {
> CYG_REPORT_FUNCTION();
>
> #ifdef CYGSEM_KERNEL_SYNCH_MUTEX_PRIORITY_INVERSION_PROTOCOL_SIMPLE
>
> // A simple implementation of priority inheritance/ceiling
> // protocols. The simplification in this algorithm is that we do
> // not reduce our priority until we have freed all mutexes
> // claimed. Hence we can continue to run at an artificially high
> // priority even when we should not. However, since nested
> // mutexes are rare, the thread we have inherited from is likely
> // to be locking the same mutexes we are, and mutex claim periods
> // should be very short, the performance difference between this
> // and a more complex algorithm should be negligible. The most
> // important advantage of this algorithm is that it is fast and
> // deterministic.
>
> Does this explain what you see?
>
I should have always only one mutex claimed per thread. And always only for a very short period. What if several threads waiting for one mutex with priorities from 2 to 6 and the tread with priority 7 is holding the mutex. First of all will there be a reschedule after the mutex is realeased?
Alois
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss