PCP implementation

[Joel Sherrill]

Till Straumann wrote:

> I still consider this a design flaw. However,
> vxWorks seems to do the same thing. I couldn't
> test but the manual (semMLib) still (as of
> vxWorks 5.5 says
>
>  "Once the task priority has been
>   elevated, it remains at the higher level until all
>   mutual-exclusion  semaphores  that  the task owns
>   are released; then the task returns to its normal,
>   or standard, priority."
>
> And a little further down:
>
>   "The task will return to its normal priority only
>    after  relinquishing  all of its mutual-exclusion
>    semaphores that have the inversion-safety option
>    enabled."
>
>

I'm certainly willing to do something more theoretically correct if
we can identify an algorithm that is efficient to implement.

--joel

> -- Till
>
>
> Joel Sherrill wrote:
>
>> 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
>>>>
>>>
>>
>
>