On 13/06/13 20:45, Gedare Bloom wrote:
On Thu, Jun 13, 2013 at 2:35 PM, Sebastian Huber
<sebastian.hu...@embedded-brains.de> wrote:
>On 13/06/13 20:21, Sebastian Huber wrote:
>>
>>On 13/06/13 18:06, Gedare Bloom wrote:
>>>
>>>On Thu, Jun 13, 2013 at 12:01 PM, Gedare Bloom<ged...@rtems.org> wrote:
>>>>
>>>>On Wed, Jun 12, 2013 at 11:29 AM, Sebastian Huber
>>>><sebastian.hu...@embedded-brains.de> wrote:
>>>>>
>>>>>Add and use _Scheduler_simple_Insert_as_first_order(),
>>>>>_Scheduler_simple_Insert_as_last_order(),
>>>>>_Scheduler_simple_Insert_as_first() and
>>>>>_Scheduler_simple_Insert_as_last().
>>>>>---
>>>>> .../score/inline/rtems/score/schedulersimple.inl | 46
>>>>>++++++++++++++++++++
>>>>> .../score/src/schedulersimplereadyqueueenqueue.c | 21 +--------
>>>>> .../src/schedulersimplereadyqueueenqueuefirst.c | 26 +----------
>>>>> 3 files changed, 50 insertions(+), 43 deletions(-)
>>>>>
>>>>>diff --git a/cpukit/score/inline/rtems/score/schedulersimple.inl
>>>>>b/cpukit/score/inline/rtems/score/schedulersimple.inl
>>>>>index e67fc3c..1b58c85 100644
>>>>>--- a/cpukit/score/inline/rtems/score/schedulersimple.inl
>>>>>+++ b/cpukit/score/inline/rtems/score/schedulersimple.inl
>>>>>@@ -48,6 +48,52 @@ RTEMS_INLINE_ROUTINE void
>>>>>_Scheduler_simple_Ready_queue_requeue(
>>>>> _Scheduler_simple_Ready_queue_enqueue( the_thread );
>>>>> }
>>>>>
>>>>>+RTEMS_INLINE_ROUTINE bool _Scheduler_simple_Insert_as_first_order(
>>>>>+ const Chain_Node *to_insert,
>>>>>+ const Chain_Node *next
>>>>>+)
>>>>>+{
>>>>>+ const Thread_Control *thread_to_insert = (const Thread_Control *)
>>>>>to_insert;
>>>>>+ const Thread_Control *thread_next = (const Thread_Control *) next;
>>>>>+
>>>>>+ return thread_to_insert->current_priority <=
>>>>>thread_next->current_priority;
>>>>>+}
>>>>>+
>>>>>+RTEMS_INLINE_ROUTINE bool _Scheduler_simple_Insert_as_last_order(
>>>>>+ const Chain_Node *to_insert,
>>>>>+ const Chain_Node *next
>>>>>+)
>>>>>+{
>>>>>+ const Thread_Control *thread_to_insert = (const Thread_Control *)
>>>>>to_insert;
>>>>>+ const Thread_Control *thread_next = (const Thread_Control *) next;
>>>>>+
>>>>>+ return thread_to_insert->current_priority <
>>>>>thread_next->current_priority;
>>>>>+}
>>>>>+
>>>>>+RTEMS_INLINE_ROUTINE void _Scheduler_simple_Insert_as_first(
>>>>>+ Chain_Control *chain,
>>>>>+ Thread_Control *to_insert
>>>>>+)
>>>>>+{
>>>>>+ _Chain_Insert_ordered_unprotected(
>>>>>+ chain,
>>>>>+ &to_insert->Object.Node,
>>>>>+ _Scheduler_simple_Insert_as_first_order
>>>>>+ );
>>>>>+}
>>>>>+
>>>>>+RTEMS_INLINE_ROUTINE void _Scheduler_simple_Insert_as_last(
>>>>>+ Chain_Control *chain,
>>>>>+ Thread_Control *to_insert
>>>>>+)
>>>>>+{
>>>>>+ _Chain_Insert_ordered_unprotected(
>>>>>+ chain,
>>>>>+ &to_insert->Object.Node,
>>>>>+ _Scheduler_simple_Insert_as_last_order
>>>>>+ );
>>>>>+}
>>>>
>>>>For these functions _Scheduler_simple_Insert_as_first() and
>>>>_Scheduler_simple_Insert_as_last() the name means they break priority
>>>>ties by FIFO and LIFO semantics? Before I read the code, I thought it
>>>>meant break ties by inserting to the first or last position of ties,
>>>>which is the opposite. I would prefer to have
>>>>_Scheduler_simple_Insert_as_fifo()/lifo() instead for added clarity.
>>>>
>>>I guess saying fifo/lifo could be confusing also, since the insert is
>>>not fifo/lifo, just how priority ties are broken. So maybe
>>>_Scheduler_simple_Insert_priority_fifo()/lifo()?
>>
>>
>>Suppose we have 0 < 5_0 <= 5_1 < 10, then insert 5_2 as first will yield
>>
>>0 < 5_2 <= 5_0 <= 5_1 < 10
>>
>>and insert 5_2 as last will yield
>>
>>0 < 5_0 <= 5_1 <= 5_2 < 10
>>
>>I will use your suggestions.
>>
>
>Now I think that the LIFO/FIFO talks to much about a particular use case.
>What about
>
>_Scheduler_simple_Insert_as_first_of_priority_group()
>
That would be acceptable if you prefer. It is usual to specify whether
ties are broken by lifo/fifo. A priority queue that breaks ties with
FIFO is called "stable".
Ok, the name is also a bit long. Is it useful to change the scheduler
operation methods as well, e.g. _Scheduler_Enqueue() ->
_Scheduler_Enqueue_fifo()?
--
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
