Re: [ECOS] Is priority inheritance implemented the right way in eCOS?

[Nick Garnett <nickg@ecoscentric.com>]

"Stanko Vuleta" <vuleta@nimcatnetworks.com> 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