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]
On Thu, Aug 16, 2007 at 10:04:54PM +0200, Alois Zoitl wrote:
> Hi,
>
> thanks you definitely pointed me into the right direction. The problem is
> located with the mutexes. I removed all mutexes in questions and set my
> timing measurement points directly after the semaphore that is in charge of
> activating my threads.After making more measurements and playing a little
> bit around I found it that when I set the priority inversion protocol to
> none (using cyg_mutex_set_protocol). The timing is as expected. So I
> thought it could be that before I was using priority ceiling which would be
> an explanation for the delay as every time a mutex is gathered the thread
> will get priorty 0. So I changed to priority inheritance. This from my
> point of view should do the job as I like to have it done.
> But when using priority inheritance I get the same bad timing as in the
> beginning.
>
> And as longer I think I don't know why the tread activation of the highest
> priority thread is prolonged by threads holding a mutex with priority
> inheritance where each of the treads that my also get this mutex has a
> lower priority. So I'm completly confuesed. Any Ideas what could be the
> problem or what I could do?
>
> For my current tests no priority inversion protocol is just fine, but for
> further more complected tests I think i will need something like priority
> inheritance so it would be nice to have it.
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?
Andrew
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss