PCP implementation

[Till Straumann]

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.

-- 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
>