On Wed, May 21, 2014 at 11:08 AM, Sebastian Huber
<sebastian.hu...@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.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
