PCP implementation

[Joel Sherrill]

Till Straumann wrote:

> I agree and I consider this a major design flaw.
> Indeed: by looking at the source code and testing
> your example I can confirm the documented
> behavior.
> Note that priority-inheriting binary semaphores
> exhibit the same flaw.
>
> When surrendering a priority-ceiling or -inheriting
> mutex the executing task priority should be changed
> to the highest priority (ceiling or inherited) of all currently
> held mutexes.
>
This is the designed and documented behavior.  To implement otherwise
would require maintaining information on the set of held resources and
analyzing that set each time a mutex is released.  The current design is
an engineering tradeoff assuming that you don't nest lots of PCP/PI mutexes
and don't hold them for lengthy periods of time.

I recently thought about this and think  the "resources held set" could be
cheaply maintained but how you determine the appropriate priority when
you release a mutex is still painful.  Even if you maintain the set as a
stack/LIFO and imposed and enforced the rule that
PCP/PI mutexes were released in the opposite order of acquisition,
I still think you would have to scan the set when you released a mutex
to find out what the highest priority to inherit is.

Any thoughts on an efficient way to implement the set management
required is appreciated.  I have trouble seeing it as something that is
constant order execution time.

--joel

> -- Till
>
>
> Martin Molnar wrote:
>
>> Hi,
>>
>> Could anybody explain me how exactly Priority Ceiling Protocol (PCP) 
>> is implemented in RTEMS? I think it works differently than PCP 
>> described in technical books.
>>
>> Example:
>> 1.Task1 (current priority 10) obtains the mutex SEM1 and its priority 
>> is raised to the mutex ceiling (9).
>> 2.Task1 ( current priority 9) obtains the mutex SEM2 and its priority 
>> is raised to the mutex ceiling (5).
>> 3.Task1 ( current priority 5) releases the mutex SEM2. I would expect 
>> the priority to be changed to value 9. However, the priority remains 
>> unchanged. From RTEMS documentation: Only when the task releases ALL 
>> of the binary semaphores it holds will its priority be restored to 
>> the normal value.
>>
>> I am not sure, whether RTEMS PCP(and also Priority Inheritance 
>> Protocol) is correct. Because,now Task1 can block for example TAsk2 
>> with priority 6.
>>
>>
>> Thanks for explanation
>>
>>  Martin Molnar
>>
>