[PATCH 1/8] score: Update _Thread_Heir only if necessary

[Joel Sherrill]

On 3/4/2015 12:55 PM, Sebastian Huber wrote:
> On 04/03/15 16:44, Gedare Bloom wrote:
>> On Wed, Mar 4, 2015 at 10:42 AM, Joel Sherrill
>> <joel.sherrill at 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.
> Yes, can we please avoid parentheses in case, since the comma operator 
> has the weakest precedence.
Give Gedare a vote and we will go 2 out of 3. :)
>>> 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.
> Since we started this discussion. It seems that the MPCI thread is the 
> only thread with a priority of 0. Should this be #ifdef 
> RTEMS_MULTIPROCESSING? Looks otherwise like dead code. It is possible to 
> gain a priority of 0 via the priority ceiling protocol. Is this a bug?
>
No. The timer server has a default priority of 0 also.

I suppose if code called from the timer server used a priority ceiling
mutex,
then it could get an error. But you have to be careful of timer service
routines
anyway.

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985