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 <ga...@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 <ga...@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
>>
>
>
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
