[PATCH 10/12] scheduler: Simplify simple scheduler

Gedare Bloom gedare at rtems.org
Thu Jun 13 18:45:31 UTC 2013


On Thu, Jun 13, 2013 at 2:35 PM, Sebastian Huber
<sebastian.huber at 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 <gedare at rtems.org> wrote:
>>>>
>>>> On Wed, Jun 12, 2013 at 11:29 AM, Sebastian Huber
>>>> <sebastian.huber at 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".

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




More information about the devel mailing list