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: Andrew Lunn <andrew at lunn dot ch>
- To: "Alois Z." <alois at gmx dot at>
- Cc: eCos Disuss <ecos-discuss at ecos dot sourceware dot org>
- Date: Wed, 8 Aug 2007 10:10:15 +0200
- Subject: Re: [ECOS] Thread activation disturbed by lower priority threads]
- References: <20070807140234.264490@gmx.net> <20070807144047.GF14598@lunn.ch> <20070808075810.250840@gmx.net>
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