On 2013-08-12 16:19, Gedare Bloom wrote:
On Mon, Aug 12, 2013 at 9:12 AM, Sebastian Huber
<sebastian.hu...@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.hu...@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.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
