From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30157 invoked by alias); 7 Aug 2007 14:41:01 -0000 Received: (qmail 30045 invoked by uid 22791); 7 Aug 2007 14:40:59 -0000 X-Spam-Check-By: sourceware.org Received: from londo.lunn.ch (HELO londo.lunn.ch) (80.238.139.98) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 07 Aug 2007 14:40:50 +0000 Received: from lunn by londo.lunn.ch with local (Exim 3.36 #1 (Debian)) id 1IIQEp-0005CH-00; Tue, 07 Aug 2007 16:40:47 +0200 Date: Tue, 07 Aug 2007 14:41:00 -0000 From: Andrew Lunn To: "Alois Z." Cc: ecos-discuss@ecos.sourceware.org Message-ID: <20070807144047.GF14598@lunn.ch> Mail-Followup-To: "Alois Z." , ecos-discuss@ecos.sourceware.org References: <20070807140234.264490@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070807140234.264490@gmx.net> User-Agent: Mutt/1.5.16 (2007-06-11) X-IsSubscribed: yes Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: Re: [ECOS] Thread activation disturbed by lower priority threads] X-SW-Source: 2007-08/txt/msg00033.txt.bz2 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? 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 -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss