How is data race avoided!!

[Saurabh Gadia]

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 <gadia at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20150727/368314d0/attachment.html>