Is there a data race problem while acquiring a mutex with priority inheritance protocol

[Saurabh Gadia]

As per thread initialization in threadinitialize.c we should acquire
default lock i.e the_thread->Lock.Default. Am I right?

Thanks,

Saurabh Gadia

On Thu, Jul 23, 2015 at 6:58 PM, Saurabh Gadia <gadia at usc.edu> wrote:

> basically every time we try to acquire mutex there should be lock
> acquisition related executing thread.
>
> Thanks,
>
> Saurabh Gadia
>
> On Thu, Jul 23, 2015 at 6:47 PM, Saurabh Gadia <gadia at usc.edu> wrote:
>
>> hi,
>>
>>
>> Scenario:
>> thread t1: current_priority = 5, mutex acquired = m1, m2
>> thread t2: current_priority = 3, mutex_acquired = None
>>
>> flow: thread t1 tries to acquire mutex m3 and thread t2 tries to acquire
>> mutex m1 which is already acquired by thread t1 simultaneously on SMP.
>>
>> Action:
>> thred t1 finds that m3 ->holder==NULL, so following code snippet of
>> coremuteximpl.h executes on one processor:
>>
>> /////
>> RTEMS_INLINE_ROUTINE int _CORE_mutex_Seize_interrupt_trylock_body(
>>   CORE_mutex_Control  *the_mutex,
>>   Thread_Control      *executing,
>>   ISR_lock_Context    *lock_context
>> )
>> {
>>   /* disabled when you get here */
>>
>>   executing->Wait.return_code = CORE_MUTEX_STATUS_SUCCESSFUL;
>>   if ( !_CORE_mutex_Is_locked( the_mutex ) ) {
>>     the_mutex->holder     = executing;
>>     the_mutex->nest_count = 1;
>>     if ( _CORE_mutex_Is_inherit_priority( &the_mutex->Attributes ) ||
>>          _CORE_mutex_Is_priority_ceiling( &the_mutex->Attributes ) ){
>>
>> #ifdef __RTEMS_STRICT_ORDER_MUTEX__
>> /* Doesn't this lead to data race. If the executing thread is holder os
>> some other mutex and its priority is promoted by other
>> thread
>> */
>>        _Chain_Prepend_unprotected( &executing->lock_mutex,
>>                                    &the_mutex->queue.lock_queue );
>>        *the_mutex->queue.priority_before = executing->current_priority;*
>> #endif
>>
>>       executing->resource_count++;
>>     }
>>
>>     if ( !_CORE_mutex_Is_priority_ceiling( &the_mutex->Attributes ) ) {
>>       _Thread_queue_Release( &the_mutex->Wait_queue, lock_context );
>>       return 0;
>>     }
>>
>>
>> //////
>>
>> And thread t2 tries to acquire m1 and following snippet of
>> threadchangepriority.c executes:
>>
>> ///////  (the_thread is holder for mutex m1 and new_priority == priority
>> of thread t2 ==3)
>>  lock = _Thread_Lock_acquire( the_thread, &lock_context );
>>
>>   /*
>>    * For simplicity set the priority restore hint unconditionally since
>> this is
>>    * an average case optimization.  Otherwise complicated atomic
>> operations
>>    * would be necessary.  Synchronize with a potential read of the
>> resource
>>    * count in the filter function.  See also _CORE_mutex_Surrender(),
>>    * _Thread_Set_priority_filter() and _Thread_Restore_priority_filter().
>>    */
>>   the_thread->priority_restore_hint = true;
>>   _Atomic_Fence( ATOMIC_ORDER_ACQ_REL );
>>
>>   /*
>>    *  Do not bother recomputing all the priority related information if
>>    *  we are not REALLY changing priority.
>>    */
>>   if ( ( *filter )( the_thread, &new_priority, arg ) ) {
>>     uint32_t my_generation;
>>
>>     my_generation = the_thread->priority_generation + 1;
>>    * the_thread->current_priority = new_priority;*
>>     the_thread->priority_generation = my_generation;
>>
>>     ( *the_thread->Wait.operations->priority_change )(
>>       the_thread,
>>       new_priority,
>>       the_thread->Wait.queue
>>     );
>> ////
>>
>> So can interleaving of highlighted code result in data race? From my
>> perspective and from JPF model experience this is a data race and we need
>> to have locking on executing thread and holder thread if it exists for
>> mutex while acquiring any mutex.
>> So for 2nd case when there is already holder we do acquire holder lock by
>> calling *lock = _Thread_Lock_acquire( the_thread, &lock_context ); *in
>> 2nd snippet but we should do the same on executing thread when holder==NULL
>> in 1st code snippet.
>> Am I right? or is there something I am missing?
>>
>> Thanks,
>>
>> Saurabh Gadia
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20150723/3ed6ba0d/attachment-0002.html>