From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3687 invoked by alias); 31 May 2005 09:14:11 -0000 Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Received: (qmail 3142 invoked by uid 22791); 31 May 2005 09:13:51 -0000 Received: from anchor-post-32.mail.demon.net (HELO anchor-post-32.mail.demon.net) (194.217.242.90) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 31 May 2005 09:13:51 +0000 Received: from calivar.demon.co.uk ([83.104.54.243] helo=xl5.calivar.com) by anchor-post-32.mail.demon.net with esmtp (Exim 4.42) id 1Dd2on-0005aB-6Z; Tue, 31 May 2005 09:13:49 +0000 Received: from xl5.calivar.com (localhost [127.0.0.1]) by xl5.calivar.com (Postfix) with ESMTP id 622962AA70; Tue, 31 May 2005 10:13:48 +0100 (BST) To: "Stanko Vuleta" Cc: References: From: Nick Garnett Original-Sender: nickg@ecoscentric.com Date: Tue, 31 May 2005 19:37:00 -0000 In-Reply-To: Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [ECOS] Is priority inheritance implemented the right way in eCOS? X-SW-Source: 2005-05/txt/msg00366.txt.bz2 "Stanko Vuleta" writes: > Nick, > > Thanks for giving a detailed answer. > > I understand the reasons for choosing the simpler implementation. The > one part that I did not understand was: > "When a thread attempts to lock a mutex, and finds it already owned, it > must attempt to donate its priority to the owning thread. If that thread > is itself already waiting for another mutex we must repeat the process, > and so on until we reach the end of the chain." > > I may be missing something but I don't see why is this necessary. > Scenario: Let Tl, Tm and Th be threads with low, medium and high > priority. Tl owns mutex M1 and Th owns mutex M2. Tl is waiting for a > mutex owned by Th. > Tm attempts to lock mutex M1. It donates its priority to Tl. It is not > necessary to go down the chain here and do anything with M2 or Th. If > Tl continues to be blocked because it is waiting on M2 let it be so - > its newly heightened priority (medium) is not supposed to be higher than > high anyway. Although it may appear that Tm is blocked where it should > not be, this is not so. Tm is not supposed to get CPU time anyway > because Th should be running - it is the higher priority task. Consider the following scenario: Tl locks M1 and attempts to lock M2. M2 is already owned by Tm, so Tl has to wait, there is no priority donation at this point. Now Th runs and attempts to lock M1. It cannot, since Tl owns it, so it donates it priority to Tl. Tl must in turn now donate this new priority to Tm, to prevent Tm blocking Th. This then has to be repeated for any mutex that Tm may be waiting for. These sorts of situations are fairly rare, which is why the simple algorithm is acceptable in most cases. > > Further: > I agree that the business with keeping a linked lists of mutexes owned > by each thread adds to latency uncertainty and the complexity. I would > argue here to limit maximum number of mutexes owned by a thread to a > configurable number like, say 4. It would make things deterministic > again and it would decrease processing time. I'm not sure that would help much. -- Nick Garnett eCos Kernel Architect http://www.ecoscentric.com The eCos and RedBoot experts -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss