From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23000 invoked by alias); 16 Aug 2007 20:22:35 -0000 Received: (qmail 22882 invoked by uid 22791); 16 Aug 2007 20:22:34 -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; Thu, 16 Aug 2007 20:22:30 +0000 Received: from lunn by londo.lunn.ch with local (Exim 3.36 #1 (Debian)) id 1ILlrO-0000ED-00; Thu, 16 Aug 2007 22:22:26 +0200 Date: Thu, 16 Aug 2007 20:22:00 -0000 From: Andrew Lunn To: Alois Zoitl Cc: eCos Disuss Message-ID: <20070816202226.GO8904@lunn.ch> Mail-Followup-To: Alois Zoitl , eCos Disuss References: <20070807140234.264490@gmx.net> <20070807144047.GF14598@lunn.ch> <20070808075810.250840@gmx.net> <20070808081015.GB29246@lunn.ch> <46C4ADE6.9080101@gmx.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46C4ADE6.9080101@gmx.at> 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/msg00081.txt.bz2 On Thu, Aug 16, 2007 at 10:04:54PM +0200, Alois Zoitl wrote: > Hi, > > thanks you definitely pointed me into the right direction. The problem is > located with the mutexes. I removed all mutexes in questions and set my > timing measurement points directly after the semaphore that is in charge of > activating my threads.After making more measurements and playing a little > bit around I found it that when I set the priority inversion protocol to > none (using cyg_mutex_set_protocol). The timing is as expected. So I > thought it could be that before I was using priority ceiling which would be > an explanation for the delay as every time a mutex is gathered the thread > will get priorty 0. So I changed to priority inheritance. This from my > point of view should do the job as I like to have it done. > But when using priority inheritance I get the same bad timing as in the > beginning. > > And as longer I think I don't know why the tread activation of the highest > priority thread is prolonged by threads holding a mutex with priority > inheritance where each of the treads that my also get this mutex has a > lower priority. So I'm completly confuesed. Any Ideas what could be the > problem or what I could do? > > For my current tests no priority inversion protocol is just fine, but for > further more complected tests I think i will need something like priority > inheritance so it would be nice to have it. How many mutex's does your lower priority thread hold? From packages/kernel/current/src/sched/sched.cxx void Cyg_SchedThread::clear_inherited_priority() { CYG_REPORT_FUNCTION(); #ifdef CYGSEM_KERNEL_SYNCH_MUTEX_PRIORITY_INVERSION_PROTOCOL_SIMPLE // A simple implementation of priority inheritance/ceiling // protocols. The simplification in this algorithm is that we do // not reduce our priority until we have freed all mutexes // claimed. Hence we can continue to run at an artificially high // priority even when we should not. However, since nested // mutexes are rare, the thread we have inherited from is likely // to be locking the same mutexes we are, and mutex claim periods // should be very short, the performance difference between this // and a more complex algorithm should be negligible. The most // important advantage of this algorithm is that it is fast and // deterministic. Does this explain what you see? 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