About priority ceiling semaphores

[Joel Sherrill <joel@OARcorp.com>]

Luís Henriques wrote:
> 
> Hi,
> 
> I'm using RTEMS v. 4.5.0 and I have a question about the use of priority
> ceiling semaphores.
> 
> I have an application that creates two binary semaphores with the following
> attributes:
> 
>  * RTEMS_PRIORITY
>  * RTEMS_BINARY_SEMAPHORE
>  * RTEMS_NO_INHERIT_PRIORITY
>  * RTEMS_PRIORITY_CEILING
>  * RTEMS_LOCAL
> 
> Semaphore A has the priority ceiling set to 15 and semaphore B has the
> priority ceiling set to 10.
> 
> Then, in a task, I obtain semaphore A (and the task priority is set
> 15). Later, still with semaphore A belonging to the task, I obtain
> semaphore B (and the task priority is raised again to 10).
> 
> The question is: what should happen to the task priority after the
> release of semaphore B? I was expecting that the priority would be set
> to 15 again but what really happens is that it is maintained at 10 --
> only after releasing semaphore A the priority is changed again.
> 
> Is this behaviour correct? Or is a problem (probably already fixed in
> later versions) in RTEMS?

It is the intended behavior.  The textbook behavior 
where a task's priority is the highest of the set of 
priority ceiling mutexes it is currently holding requires
a LOT of bookkeeping to implement.  Although not the textbook 
way priority ceiling is described to work for multiple 
acquisitions, it is behaviorially correct and the implementation
is algorithmically simple so is fast. 

The RTEMS algorithm is described here:

http://www.rtems.com/onlinedocs/releases/rtemsdocs-4.6.0/share/rtems/html/c_user/c_user00147.html 


> Thanks in advance.
> 
> --
> Luís Henriques

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985