<div dir="ltr"><div>ohh. We acquire lock over the_thread!! Sorry for that. <br><br>    _Thread_Lock_release( lock, &lock_context );<br><br>    _Scheduler_Acquire( the_thread, &lock_context );<br><br>    if ( the_thread->priority_generation == my_generation ) {<br><br></div>and generation is only important if  its value changed after release and before checking my_generation==the_thread->priority_generation by some other thread.<br></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr">Thanks,<div><br></div><div>Saurabh Gadia</div></div></div></div>
<br><div class="gmail_quote">On Mon, Jul 27, 2015 at 9:10 AM, Saurabh Gadia <span dir="ltr"><<a href="mailto:gadia@usc.edu" target="_blank">gadia@usc.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>hi,<br><br></div>I was going through the code in _thread_change_priority(){..} (threadchangepriority.c) and had doubt. below is the code snippet.<br><br><br>  _Atomic_Fence( ATOMIC_ORDER_ACQ_REL );<br><br>  /*<br>   *  Do not bother recomputing all the priority related information if<br>   *  we are not REALLY changing priority.<br>   */<br>  if ( ( *filter )( the_thread, &new_priority, arg ) ) {<br>    uint32_t my_generation;<br><br>    my_generation = the_thread->priority_generation + 1;<br>    the_thread->current_priority = new_priority;<b><br>    the_thread->priority_generation = my_generation;</b><br><br>    ( *the_thread->Wait.operations->priority_change )(<br>      the_thread,<br>      new_priority,<br>      the_thread->Wait.queue<br>    );<br><br></div>how is the data race problem avoided while setting the_thread->priority_generation?<br><div><br><br clear="all"><div><div><div><div><div dir="ltr">Thanks,<div><br></div><div>Saurabh Gadia</div></div></div></div>
</div></div></div></div>
</blockquote></div><br></div>