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

[Andrew Lunn <andrew@lunn.ch>]

On Wed, Aug 08, 2007 at 09:58:10AM +0200, Alois Z. wrote:
> 
> -------- Original-Nachricht --------
> Datum: Tue, 7 Aug 2007 16:40:47 +0200
> Von: Andrew Lunn <andrew@lunn.ch>
> An: "Alois Z." <alois@gmx.at>
> CC: ecos-discuss@ecos.sourceware.org
> Betreff: Re: [ECOS] Thread activation disturbed by lower priority threads]
> 
> > On Tue, Aug 07, 2007 at 04:02:34PM +0200, Alois Z. wrote:
> > > Hi, 
> > > 
> > > as I got no response to me questions (see below) I may have to add a
> > > few things for clarification.
> > >
> > > First of all I'm running an an AT91M5580A processor (thy phytec
> > > board). I changed the ecos settings so that the timer tick is now
> > > 1ms. The reason for this is that I need such a small tick for my
> > > application. Does this anyhow influence the scheduling
> > > algorithm. Are there settings that need to be adjusted appart from
> > > denominator, nominator and timesclice value?
> > > 
> > > I did more measurements and found out that the timer DSR is really
> > > stable. even more stable than on some other systems (non ecos) I'm
> > > using. The problem is that the time between posting on the semaphore
> > > (the thread is waiting on) until the thread starts executing is
> > > varying largly. It seems that it is prolonged by other execution
> > > elements. And this even when the thread under question is the thread
> > > with the highest priority.  would be great if this clearifies my
> > > problem a little bit more.
> > 
> > If it is the highest priority runnable thread, as soon as the DSR
> > finished it should get to run. The only exception i can think of is if
> > some other thread has the scheduler locked. This would prevent a
> > context switch until the scheduler was unlocked.
> > 
> > How to you do your timing between the DSR timer and thread running? 
> 

> I just set bits in both and can than see the timing on an
> oscilloscope. This works really good and I did the same measurements
> on different boards.

Do you set the bits just after the semaphore operations, or later,
when it does the real work? I'm just thinking about the mutex issue.
 
> > Does this high priority thread need to acquire a mutex etc? It could
> > be that something else has the mutex. So it has to wait for it to be
> > released. Priority inversion then happens. The lower priority thread
> > which holds the mutex gets boosted in priority to the priority of the
> > waiting thread. This should allow the low priority thread to finish
> > what it is doing and release the mutex. However there is one
> > wrinkle. eCos only undoes priority inversion when the thread releases
> > all its mutex, not just the mutex of interest. 
> > 
> >     Andrew
> > 

> There is may be a mutex the high priority thread has to wait for. It
> is just one and typically the lock time is rather
> short. Unfortunatly every thread will use this mutex so maybe thats
> the reason for my problem. As I think now of it it may be a bad
> design, but because of other constraints it will not be possible to
> remove this mutex. By the way it works on other real-time operating
> systems (e.g. ThreadX). So I should think on the riority inversion
> protocol for the mutexes, i'm right?

Just for the purpose of testing a theory, take out the mutex. If the
timing gets better, you know the mutex is the problem. 

You might also want to look at kernel instrumentation. 
http://ecos.sourceware.org/docs-latest/user-guide/kernel-instrumentation.html

        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