Re: [ECOS] Thread activation disturbed by lower priority threads]

[Andrew Lunn <andrew@lunn.ch>]

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