Initially Locked Priority Ceiling Semaphores

Gedare Bloom gedare at rtems.org
Wed May 21 15:35:35 UTC 2014


On Wed, May 21, 2014 at 11:08 AM, Sebastian Huber
<sebastian.huber at embedded-brains.de> wrote:
> On 2014-05-21 17:01, Gedare Bloom wrote:
>>>
>>>    if ( initially_locked ) {
>>> >     the_mutex->nest_count = 1;
>>> >     the_mutex->holder     = executing;
>>> >     if ( _CORE_mutex_Is_inherit_priority( &the_mutex->Attributes ) ||
>>> >          _CORE_mutex_Is_priority_ceiling( &the_mutex->Attributes ) ) {
>>> >
>>> >       if ( executing->current_priority <
>>> >              the_mutex->Attributes.priority_ceiling )
>>> >        return CORE_MUTEX_STATUS_CEILING_VIOLATED;
>>
>> Looks like this check ensures the executing thread has got priority at
>> least at the priority_ceiling. If it does not, the mutex is not
>> initialized.
>
>
> Yes, this is the error case.   In the good case the priority is not changed
> to the ceiling priority like for a normal rtems_semaphore_obtain() (see
> _CORE_mutex_Seize_interrupt_trylock_body()).
>
Ah. Then I think your suspicion is correct. Probably the executing
thread should be given the priority_ceiling, otherwise there can be
some priority inversion while the initial lock is held.

>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax     : +49 89 189 47 41-09
> E-Mail  : sebastian.huber at embedded-brains.de
> PGP     : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.




More information about the devel mailing list