From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30921 invoked by alias); 27 May 2005 13:29:52 -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 30838 invoked by uid 22791); 27 May 2005 13:29:44 -0000 Received: from 209-87-230-250.storm.ca (HELO exchange.nimcat.corp) (209.87.230.250) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Fri, 27 May 2005 13:29:44 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 27 May 2005 19:32:00 -0000 Message-ID: From: "Stanko Vuleta" To: Subject: [ECOS] Is priority inheritance implemented the right way in eCOS? X-SW-Source: 2005-05/txt/msg00353.txt.bz2 I am doing a bit of research in eCOS and I couldn't find the answer to the following question: how is priority inheritance implemented in eCOS? =20 An explanation: a very well known RTOS that has the majority of the market share nowdays implements priority inheritance in a simple way which gets you high benchmarks when measuring scheduling latency but renders your RTOS "pseudo-real-time" since end result is that low priority tasks can end up stealing CPU time from the high priority ones. Further explanation in words of Tod Litwin picked up from a discussion list:=20 =20 "The problem is that when the low-priority task releases the mutex, the task's elevated priority=20 won't necessarily be lowered back to its proper level right away. This only=20 occurs if the task is still holding other inversion-protected mutexes. The=20 priority will only be returned to its proper level when the last such mutex is=20 released by the task. Until that time it's priority will not be lowered at all,=20 no matter how many times and through how many mutexes it's priority needed to=20 be raised through priority inheritance. (Note that if the task is holding only=20 one inversion-protected mutex at a time, there is no problem.) " =20 An example of how bad this can be, think of e.g. data base code: as soon as a database function is entered, we obtain a semaphore protecting the database. A bit later we decide to read/write to flash. We obtain another semaphore protecting the flash. The conditions for the above problem have been met.=20=20 =20 BTW, this is documented as such in their API and the latest version of the RTOS in question has the problem fixed. =20 Finally, the question: does eCOS lower the priority of the task with inherited priority as soon as the particular semaphore is released or does it wait for all the semaphores it owns to be released? =20 Thanks, =20 Stanko Vuleta -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss