ohh. We acquire lock over the_thread!! Sorry for that.
_Thread_Lock_release( lock, &lock_context );
_Scheduler_Acquire( the_thread, &lock_context );
if ( the_thread->priority_generation == my_generation ) {
and generation is only important if its value changed after release and
before checking my_generation==the_thread->priority_generation by some
other thread.
Thanks,
Saurabh Gadia
On Mon, Jul 27, 2015 at 9:10 AM, Saurabh Gadia <ga...@usc.edu> wrote:
> hi,
>
> I was going through the code in _thread_change_priority(){..}
> (threadchangepriority.c) and had doubt. below is the code snippet.
>
>
> _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
> );
>
> how is the data race problem avoided while setting
> the_thread->priority_generation?
>
>
> Thanks,
>
> Saurabh Gadia
>
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
