On Mon, Aug 12, 2013 at 9:12 AM, Sebastian Huber <[email protected]> wrote: > On 2013-08-12 16:11, Gedare Bloom wrote: >> >> On Fri, Aug 9, 2013 at 2:35 AM, Sebastian Huber >> <[email protected]> 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 : [email protected] > PGP : Public key available on request. > > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. _______________________________________________ rtems-devel mailing list [email protected] http://www.rtems.org/mailman/listinfo/rtems-devel
