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 <[EMAIL PROTECTED]> > An: "Alois Z." <[EMAIL PROTECTED]> > CC: [email protected] > 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
