[ECOS] Thread activation disturbed by lower priority threads]

Andrew Lunn andrew@lunn.ch
Wed Aug 8 08:10:00 GMT 2007

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. 


Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

More information about the Ecos-discuss mailing list