[PATCH 1/2] score: Implement scheduler helping protocol

[Joel Sherrill]

On 7/8/2014 10:05 AM, Sebastian Huber wrote:

I reviewed the code and didn't spot anything obvious.

Does the Doxygen have any warnings or do we need to wait
to see the automated build?

I am sure once the SMP dust settles, we will have to work
on coverage with SMP enabled. 

> diff --git a/doc/user/smp.t b/doc/user/smp.t
> index dd84c37..239a544 100644
> --- a/doc/user/smp.t
> +++ b/doc/user/smp.t
> @@ -147,6 +147,79 @@ another processor.  So if we enable interrupts during this transition we have
>  to provide an alternative task independent stack for this time frame.  This
>  issue needs further investigation.
>
> + at subsection Scheduler Helping Protocol
> +
> +The scheduler provides a helping protocol to support locking protocols like
> + at cite{Migratory Priority Inheritance} or the @cite{Multiprocessor Resource
> +Sharing Protocol}.  Each ready task can use at least one scheduler node at a
> +time to gain access to a processor.  Each scheduler node has an owner, a user
> +and an optional idle task.  The owner of a scheduler node is determined a task
a -> at
> +creation and never changes during the life time of a scheduler node.  The user
> +of a scheduler node may change due to the scheduler helping protocol.  A
> +scheduler node is in one of the four scheduler help states:
> +
> + at table @dfn
> +
> + at item help yourself
> +
> +This scheduler node is solely used by the owner task.  This task owns no
> +resources using a helping protocol and thus does not take part in the scheduler
> +helping protocol.  No help will be provided for other tasks.
> +
> + at item help active owner
> +
> +This scheduler node is owned by a task actively owning a resource and can be
> +used to help out tasks.
> +
> +In case this scheduler node changes its state from ready to scheduled and the
> +task executes using another node, then an idle task will be provided as a user
> +of this node to temporarily execute on behalf of the owner task.  Thus lower
> +priority tasks are denied access to the processors of this scheduler instance.
> +
> +In case a task actively owning a resource performs a blocking operation, then
> +an idle task will be used also in case this node is in the scheduled state.
> +
> + at item help active rival
> +
> +This scheduler node is owned by a task actively obtaining a resource currently
> +owned by another task and can be used to help out tasks.
help out other(?) tasks which...?
> +The task owning this node is ready and will give away its processor in case the
> +task owning the resource asks for help.
> +
> + at item help passive
> +
> +This scheduler node is owned by a task obtaining a resource currently owned by
> +another task and can be used to help out tasks.
> +
> +The task owning this node is blocked.
> +
> + at end table
> +
> +The following scheduler operations return a task in need for help
> +
> + at itemize @bullet
> + at item unblock,
> + at item change priority,
> + at item yield, and
> + at item ask for help.
> + at end itemize
> +
> +A task in need for help is a task that encounters a scheduler state change from
> +scheduled to ready or a task that cannot be scheduled in an unblock operation.
> +Such a task can ask tasks which depend on resources owned by this task for
> +help.
> +
> +In case it is not possible to schedule a task in need for help, then
> +the corresponding scheduler node will be placed into the set of ready
> +scheduler nodes of the scheduler instance.  Once a state change from
> +ready to scheduled happens for this scheduler node it may be used to
> +schedule the task in need for help.
> +
> +The ask for help scheduler operation is used to help tasks in need for help
May want to use @code{ask for help} where appropriate to clearly
indicate a method.
> +returned by the operations mentioned above.  This operation is also used in
> +case the root of a resource sub-tree owned by a task changes.
> +
>  @subsection Critical Section Techniques and SMP
>
>  As discussed earlier, SMP systems have opportunities for true parallelism
> --
> 1.7.7
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985