From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21957 invoked by alias); 17 Aug 2007 07:34:03 -0000 Received: (qmail 21902 invoked by uid 22791); 17 Aug 2007 07:34:02 -0000 X-Spam-Check-By: sourceware.org Received: from mail.gmx.net (HELO mail.gmx.net) (213.165.64.20) by sourceware.org (qpsmtpd/0.31) with SMTP; Fri, 17 Aug 2007 07:33:57 +0000 Received: (qmail 1341 invoked by uid 0); 17 Aug 2007 07:33:54 -0000 Received: from 128.131.86.182 by www161.gmx.net with HTTP; Fri, 17 Aug 2007 09:33:54 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 17 Aug 2007 07:34:00 -0000 From: "Alois Z." Message-ID: <20070817073354.22100@gmx.net> MIME-Version: 1.0 To: ecos-discuss@ecos.sourceware.org X-Authenticated: #979605 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) Content-Transfer-Encoding: 8bit X-GMX-UID: Vn38fpQ9YW0tRfGBb2Zp0Wl8amthcxsF 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/msg00082.txt.bz2 Hi, > > 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? > I should have always only one mutex claimed per thread. And always only for a very short period. What if several threads waiting for one mutex with priorities from 2 to 6 and the tread with priority 7 is holding the mutex. First of all will there be a reschedule after the mutex is realeased? Alois -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss