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

[Sebastian Huber]

On 2013-08-12 16:19, Gedare Bloom wrote:
> 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).

No, the update has to take place before the enqueue operations.

-- 
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.