[PATCH v2] score: PR2136: Fix _Thread_Change_priority()

[Gedare Bloom]

On Mon, Aug 12, 2013 at 9:12 AM, Sebastian Huber
<sebastian.huber at embedded-brains.de> wrote:
> On 2013-08-12 16:11, Gedare Bloom wrote:
>>
>> On Fri, Aug 9, 2013 at 2:35 AM, Sebastian Huber
>> <sebastian.huber at embedded-brains.de> wrote:
>> <snip>
>>>
>>> @@ -59,10 +60,12 @@ void _Scheduler_Handler_initialization( void );
>>>    *
>>>    * This kernel routine implements the scheduling decision logic for
>>>    * the scheduler. It does NOT dispatch.
>>> + *
>>> + * @param[in] thread The thread which state changed previously.
>>>    */
>>> -RTEMS_INLINE_ROUTINE void _Scheduler_Schedule( void )
>>> +RTEMS_INLINE_ROUTINE void _Scheduler_Schedule( Thread_Control *thread )
>>>   {
>>> -  _Scheduler.Operations.schedule();
>>> +  _Scheduler.Operations.schedule( thread );
>>>   }
>>>
>> Can this "thread" parameter be used to "Update" the per-thread
>> scheduler metadata and obviate the call to _Scheduler_Update?
>>
>> -Gedare
>>
>
> An optimized version of the current scheduler will use this thread parameter
> to get some state information.
>
OK. I will look at this when I have some time also. I have never been
happy with the per-thread metadata that adds the "allocate, update,
free" hooks to the scheduler operations table. Mostly I dislike that
the hooks are needed for the priority scheduler but not for most other
(any?) schedulers. My question is wondering if we can make "update"
part of schedule() when a state change occurs (especially when a
thread changed priority).

>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax     : +49 89 189 47 41-09
> E-Mail  : sebastian.huber at embedded-brains.de
> PGP     : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.