PCP implementation

[Till Straumann]

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


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