On Wed, Mar 4, 2015 at 10:42 AM, Joel Sherrill <joel.sherr...@oarcorp.com> wrote: > > > On 3/4/2015 9:07 AM, Sebastian Huber wrote: >> Previously, the _Thread_Heir was updated unconditionally in case a new >> heir was determined. The _Thread_Dispatch_necessary was only updated in >> case the executing thread was preemptible or an internal thread was >> unblocked. Change this to update the _Thread_Heir and >> _Thread_Dispatch_necessary only in case the currently selected heir >> thread is preemptible or a dispatch is forced. Move the schedule >> decision into the change priority operation and use the schedule >> operation only in rtems_task_mode() in case preemption is enabled or an >> ASR dispatch is necessary. This is a behaviour change. Previously, the >> RTEMS_NO_PREEMPT also prevented signal delivery in certain cases (not >> always). Now, signal delivery is no longer influenced by >> RTEMS_NO_PREEMPT. Since the currently selected heir thread is used to >> determine if a new heir is chosen, non-preemptible heir threads >> currently not executing now prevent a new heir. This may have an >> application impact, see change test tm04. Document this change in sp04. >> >> Update #2273. > ... >> diff --git a/cpukit/score/src/schedulercbsunblock.c >> b/cpukit/score/src/schedulercbsunblock.c >> index 688253c..bd27aff 100644 >> --- a/cpukit/score/src/schedulercbsunblock.c >> +++ b/cpukit/score/src/schedulercbsunblock.c >> @@ -79,10 +79,10 @@ Scheduler_Void_or_thread _Scheduler_CBS_Unblock( >> _Thread_Heir->current_priority >> ) >> ) { >> - _Thread_Heir = the_thread; >> - if ( _Thread_Executing->is_preemptible || >> - the_thread->current_priority == 0 ) >> - _Thread_Dispatch_necessary = true; >> + _Scheduler_Update_heir( >> + the_thread, >> + the_thread->current_priority == 0 >> + ); > The use of an expression without parentheses seems inconsistent > style-wise. I don't think this type of code is used often but could > you please put parentheses around this? > This conflicts with our coding conventions to avoid excess parens.
> This same pattern is in other places so please do it globally across > this patch. > I think I spotted a total of four places. > > Also since this indicates that the thread is at the pseudo-interrupt > priority, > maybe a macro/static inline with a meaningful name would be even > better. > Yes a macro might be good for this test. > -- > Joel Sherrill, Ph.D. Director of Research & Development > joel.sherr...@oarcorp.com On-Line Applications Research > Ask me about RTEMS: a free RTOS Huntsville AL 35805 > Support Available (256) 722-9985 > > _______________________________________________ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel